Usage of the Provider Reference File?

[brbucher]

How is the provider reference file intended to be referenced?
The Table of Contents file seems like a good location for it. Another object could be added into the "Reporting Structure Object"
Otherwise perhaps it could replace the provider_references object in the In-Network File,
I think that the Table of Contents file would be a more appropriate place as that file is already dedicated to listing external references.
Also, based on this discussion topic (#356) there could be cases where the same provider groups would be applicable across plans which would be easier to indicate in the Table of Contents.

[sharma-TIP]

How is the provider reference file intended to be referenced? The Table of Contents file seems like a good location for it. Another object could be added into the "Reporting Structure Object" Otherwise perhaps it could replace the provider_references object in the In-Network File, I think that the Table of Contents file would be a more appropriate place as that file is already dedicated to listing external references. Also, based on this discussion topic (#356) there could be cases where the same provider groups would be applicable across plans which would be easier to indicate in the Table of Contents.

This will be a great addition to reduce the file sizes! @shaselton-usds

[Devyandu]

I want to introduce a thought which is opposite to the proposal in the original post of this discussion.

We already have the flexibility to use the same provider references in multiple in-network files, all we have to do is include the same provider reference file in multiple in-network files.

Multiple in-network files for the same plan could very well be produced by different vendors who will all have their own provider-group-ids. The in-network file is the right place to define provider references IMHO.

I do not think the provider references should be in the table of contents, the references belong at a lower scope (in-network).

[sharma-TIP]

So the problem we are running into is that a set of pricing associations lets say 30K services in a fee schedule is associated with 2K plans; That mean I have to generate 2K files for the same set of services , rates the only difference is provider reference object . And we do have these associations common for many fee schedules. Basically there should be no dependency of providers on fee schedules - A fee Schedule ( Set of services/ rates) should live on their own and can be attached to multiple providers/plans. And, from the discussions I am presuming that this is what the problem other producers of the file are facing. IMHO.

[shaselton-usds]

@brbucher Thanks for the input.

Your initial question of "how is the provider reference file intended to be referenced?" -- the idea is that provider networks can be defined externally (in their own file -- schema and example) and then referenced from within an in-network file to assign to certain items/services that have contractual rates for those provider networks.

The "assigning" of these external networks to the items/services is dependent on the provider_group_id found in the provider_reference_object within the in-network file.

Moving this information into the table of contents file would introduce some complexity (and potentially lose context in which the networks are to be assigned in the various included in-network files) in the way of having a "foreign key" assigned outside of the file in which it is needed -- this is pushing the complexity limits for a "flat file".

As it stands, in-network files are meant to be self-contained without the need of any external information to make them valid. The table of contents file's intent is to combine many of these self-contained arrangements together that would define the complete plan. I think this suggestion, while valid and worthy of serious consideration, would be best evaluated once implementation has happened to allow for proper analysis to consider if the complexity is worth the addition.