Reformat Root Schema To Support Multiple Plan/HIOS/EIN and Less Individual Files

[BobSyracuse]

@shaselton Would it be possible to reformat the root schema to provide an array of In-Plan objects that would allow a single file's In-Network object array to represent multiple plans/HIOS/EIN and file naming convention?

A good number of HIOS/EIN have the same associated provider networks and associated negotiated rates for a provider with the difference being at the member level benefits causing the creation of a different plan and associated HIOS/EIN. This approach would resolve the multitude of in-network rates files being created with 99% of the same data found in the JSON except for the different plan related fields. It would be more efficient for the payor or insurer to generate the file and allow a consumer to have fewer files to download while providing the same information within the schema to support the rule.

It would also resolve the question, In-Network-Rates File: Schema and Definition of Plan Name and HIOS/EIN #44

The modified schema would be (Note: Definitions were trimmed to allow for formatting of the table but should be the full definition as listed in the schema)
In-Network File

Field	Name	Type	Definition	Required
reporting_entity_name	Entity Name	String	The legal name of the entity publishing the file.	Yes
reporting_entity_type	Entity Type	String	The type of entity that is publishing the machine-readable file.	Yes
in_plan	In-Plan	Array	An array of in-plan object types	Yes
in_network	In-Network	Array	An array of in-network object types	Yes
last_updated_on	Last Updated On	String	The date in which the file was last updated.	Yes

In-Plan Object

Field	Name	Type	Definition	Required
plan_name	Plan Name	String	The plan name and name of plan sponsor and/or insurance company.	Yes
plan_id_type	Plan Id Type	String	Allowed values: "EIN" and "HIOS"	Yes
plan_id	Plan Id	String	The 14-digit HIOS or EIN for each plan	Yes
plan_market_type	Market Type	String	Allowed values: "group" and "individual"	Yes

[jonberkery-work]

I would 100% support this recommendation.

[BobSyracuse]

Thoughts @tdfow @angelamarie0975

[shaselton-usds]

@BobSyracuse Definitely makes sense.

Thanks for verifying @BobSyracuse @tdfow @jturan @jonberkery-work. Is it possible to link to (online) any of your multiple plans (different HIOS/EIN) that would have the same in_network object across them?

Seems like this might be common and would be a great optimization to cut down redundant information across files.

RE: file naming. This is tricky. Possible to have dynamic file names that point back to a single file?

[BobSyracuse]

@shaselton-usds I would need to verify with our legal/compliance. I could forward that information via our CMS contact if that would work?

[jonberkery-work]

@shaselton-usds
I want to make sure I am following, in order to help with the discussion....

You are asking me to provide a generic, high-level mapping of unique HIOS\EINs to unique "In-network object" arrays, correct?

If so. Yes, I believe I can put something together that represents my company..... I will also, run it by our legal/compliance area.

[jonberkery-work]

@shaselton @shaselton-usds

First let me say, Thank you for the back and forth discussion on this. I understand there are many different opinions on how best to publish this data. I appreciate your willingness to receive feedback. It doesn't go unnoticed.

Here is a summary of the research for my company ...... I have 5 unique IN Object Array "models".... 16 different HIOSs and 2668 different EINs use "Model 1", 7 different EINs use "Model 2", etc .....

Viewing the breakdown below, you can see the benefit of only storing the 5 extremely large "models", and dynamically generating the plan-id-type (HIOS or EIN), plan-id, and plan-market-type (Group or Individual) on demand for the user\consumer. Otherwise, I would have to store 2,699 extremely large, static, in-network-rates files of virtually the same, identical data.

In Network Object Arrays IDs	Count of Unique HIOSs Using that IN Object Array ID	Count of Unique EINs Using that IN Object Array ID
IN-ObjArr-1	16	2668
IN-ObjArr-2		7
IN-ObjArr-3		2
IN-ObjArr-4		3
IN-ObjArr-5		3
Grand Total	16	2683

[rakeshkatte]

Hi @shaselton-usds, is there any update on the suggestions made above? This is a huge problem for us too. Making the changes to the schema suggested above would greatly improve the efficacy of the dataset, both from a production and consumption perspective.
I have not seen anymore comments on the file naming convention or the table of contents idea mentioned above by @BobSyracuse, I was thinking, we could generate a "summary of content" file that summarizes the in-network files generated by the payer / insurer for the month, containing a list of each of the planIds and the corresponding filename where the rates could be found. And remove the planname from the in-network file name.
@jonberkery-work @tdfow

[MMath19103]

Great Idea. This would be welcomed and would reduce the number of files considerably

[jturan]

Based on numerous conversations I've been on recently with our clients and vendor partners asking for guidance on the machine-readable files, this is becoming one of their top concerns. Take for example a nationwide PPO with a large insurer like United or Aetna. Those PPOs are used with thousands of fully-insured and self-insured employers, and the rates are the same for each. Under the current spec, that PPO file would have to be duplicated for every single employer, thus causing a massive data redundancy issue on a monthly basis. Per the suggestion above, if Plan IDs could be stored as an array, then that would significantly reduce this problem.

[geekay2015]

This is really a great idea, would support this. recommendation!!

[mmorri05]

Do plans such as United have individual/unique 5-digit HIOS IDs for their various PPO employer groups?

[MMath19103]

Has anyone wondered whether the intent was to report "Product Name" and not "Plan Name"?

[angelamarie0975]

The way that we understood the CMS schema originally was at plan level - assuming this was their intent because they are asking for the HIOS/EIN numbers and those are not available at our product level. But the further we got into this, we started to wonder the same thing. This is why we were trying to see if if we could report at the product level because each of our group/individual benefit plans all roll up to our products and that's where the all of the negotiated rates come from - the networks that coincide with those products. From what I can tell, the hospitals created their cost transparency files based on the product networks as well - they didn't produce their files at the benefit plan level, which is what CMS appears to be asking for here. I think there are definitely 2 different ideas of the term plan when it comes to issuers - the benefit plan and the product plans - at least that's the way I see it and I am wondering if the terminology is just getting mixed up?

What CMS is asking - to have individual files for each plan/HIOS/EIN - this means over a thousand files will be produced by us - times 3 and this just seems like it's not at the right hierarchy for reporting the negotiated rates. These thousands of files are all going to end up containing the same provider network negotiated rates - so the data is really going to just be duplicated across all of the plans per our products. If we could just provide at the product level, including the plan names and HIOS/EINs in an array, this would alleviate this concern. At least this is our opinion. :/

[MMath19103]

completely agree @angelamarie0975

[BobSyracuse]

@MMath19103 @angelamarie0975 Agree!

[bryanbriegel]

CMS defines a product as "A product is a discrete package of health insurance coverage benefits that are offered using a particular product network type (such as Health Maintenance Organization (HMO), Preferred Provider Organization (PPO),Exclusive Provider Organization (EPO), Point Of Service (POS) or indemnity) within a service area." - and "Any set of plans that share a network type and a set of benefits is a product." - and notes Plans are: "Plans, with respect to a product, are the pairing of the health insurance coverage benefits under the product with a particular cost sharing structure, provider network and service area that are offered to a consumer" - this to me suggests reporting at the product level where rates are negotiated as you state above , with the associated plans as an array as noted, would meet CMS's objective. Plan level is related to member cost share for the rates, vs the rates themselves - per CMS definitions.

[angelamarie0975]

So now we just wait to see what CMS says...hopefully we will get an answer soon and be able to put this discussion to rest!!

patiently waiting (insert 'loading' meme here) LOL

[DouglasAllanMN]

We are really looking for some clarification here from CMS. I agree with @angelamarie0975

These thousands of files are all going to end up containing the same provider network negotiated rates - so the data is really going to just be duplicated across all of the plans per our products.

[BobSyracuse]

@DouglasAllanMN If you have not read this question, "In-Network file size and data redundancy concerns" #99 I would suggest it. It should also be considered by CMS to make the file more concise and efficient.

[MMath19103]

Does anyone believe that CMS will respond at the same time as they publish the rules for CAA - July 1? This open question is hindering us from moving forward with our file mapping and development too.

[ryan-thomas-peterson]

@MMath19103 , agree, hopeful for some direction here as well. The volume of redundant data in the specs as currently laid out is enormous.

[BobSyracuse]

@shaselton-usds @shaselton Do you have direction from CMS if this modified schema will be allowed?

Or does a non-response indicate that it is not approved and organizations need to use the schema as published that does not include a array for root field Plan data? Thank you

[BobSyracuse]

@shaselton-usds Since there is now more time prior to the enforcement date of 07/01/22, can this suggestion be reviewed to make use of a modified schema of the Plan field elements into an array?

[keithwoodnc]

@shaselton-usds I also agree with this. There are significant concerns about duplication leading to a massive number of files to be downloaded, which in turn leads to uncontrollable data egress costs when you factor in the no-barriers requirement.

[klomurray]

I also agree with this. I think this will also be an important change for the community looking to consume and leverage these files. Consumers of MRFs aren't going to want to pull down thousands of files with mostly duplicative data. They will likely end up needing to perform a de-duplication process in order to efficiently store the data where they associate multiple plan to a unique negotiated rate. It makes more sense to just simply as described above for everyone involved.

[ryan-thomas-peterson]

Also concur to reduce data footprints. The argument on the other side is that the data users may not know which file to download since file names would become more ambiguous. I think this could be solved for by using a simple crosswalk from EIN/HIOS to filename or some other construct. I have to imagine there is some solution that doesn't result in Petabytes (bigger?) of duplicate data.

[BobSyracuse]

@ryan-thomas-peterson Yes, a TOC file that could provide that level of crosswalk.

[keithwoodnc]

@shaselton-usds It would be great if you could take a look and this idea and let us know your thoughts. There is still great concern around the size of the data to be made public, which at this point is largely due to the requirement to have one file per employer.

[BobSyracuse]

Hi, I was thinking out a possible format for a TOC file since we would still have a naming convention issue and a way for consumers to obtain the data they wanted. My initial approach was to have a monthly TOC file generated with the format of _<carrier/payor name>TOC.json, like 20220701_AcmeInsurance_TOC.json . Each MRF INN JSON file would be named <carrier/payor name>in-network-rates.json, like 20220701_AcmeInsurance_in-network-rates_1.json.

The TOC JSON could look similar to an array of plan/file information objects. The carrier key/value is redundant based on the file naming convention for the TOC, but thought it might be useful for a consumer machine readable application.

[{
"carrier": "Acme Insurance",
"planName": "Simple Silver",
"HIOS": "12345678901234",
"EIN": "",
"innFileName": "20220701_AcmeInsurance_in-network-rates_1.json"
},
{
"carrier": "Acme Insurance",
"planName": "Plantinum Care",
"HIOS": "12345678901234",
"EIN": "",
"innFileName": "20220701_AcmeInsurance_in-network-rates_1.json"
}, {
"carrier": "Acme Insurance",
"planName": "Monster University PPO",
"HIOS": "",
"EIN": "12321312",
"innFileName": "20220701_AcmeInsurance_in-network-rates_3.json"
}
]

Thoughts?

[shaselton-usds]

@BobSyracuse This might work.

In thinking through what the actual name of the file would be that contains multiple plan's information -- I wanted to quickly check an assumption with you (and anyone else). Would there ever be a situation where a file containing multiple plans be from different payers/issuers? I would think "no", but we wouldn't want that to proved wrong. Even if all items/service had identical negotiated rates for the same providers across different payer's plans (this would be very interesting if they knew this before producing the files), they most likely wouldn't be teaming up to produce a single file...

Thoughts?

[BobSyracuse]

@shaselton I would say not very probable as that would imply as you said that items/service had identical negotiated rates for the same providers for multiple payors/insurers and for one of the payors/insurers listed in the plan array to work in conjunction with the file producer to provide their related plan information like HIOS/EIN.

So my answer would be no also.

The root schema field of

reporting_entity_name	Entity Name	String	The legal name of the entity publishing the machine-readable file.

could be a part of the file name as it is not plan specific?

[shaselton-usds]

@BobSyracuse et al --

This is a fantastic suggestion given the amount of plans with the same information. Updates can be viewed here: v0.2...v0.3

We still have to figure out naming of the files, but I don't want that to stop the implementation of this at the moment.

Thanks again for the patiences.

[MMath19103]

Thank you! @BobSyracuse thank you for the tenacity! This is great news.

[BobSyracuse]

@shaselton-usds Thank you! And the community appreciates your effort to help herd this change with CMS.

[angelamarie0975]

@shaselton-usds - amazing news!! Thanks so much!

@BobSyracuse - thank you also for following through and your suggestions - I know that this schema adds to the file size and in some cases, may be hundreds deep in the array, but still better to have 1 file for 500 files instead of 500 separate files.

Thank you both so much for this!! I had already come up with a solution for our company, but this makes it even better and I just have to update our requirements for the new schema changes - which goes along nicely with the solution that I had already come up with for our data - now I just have to add one more grouping! Such awesome news!!

[tdfow]

@shaselton-usds @shaselton Was there any consideration on adding a 'reporting_plan_name' field to the schema to address the naming standard for the file? For example:

reporting_entity_name	Entity Name	String	The legal name of the entity publishing the machine-readable file.	Yes
reporting_entity_type	Entity Type	String	The type of entity that is publishing the machine-readable file (a group health plan, health insurance issuer, or a third party with which the plan or issuer has contracted to provide the required information, such as a third-party administrator, a health care claims clearinghouse, or a health insurance issuer that has contracted with a group health plan sponsor).	Yes
reporting_plan_name	Entity Type	String	The name used to represent the reporting plan name for the reporting_plans data	Yes
reporting_plans	In-Network Plans	Array	An array of reporting plan object types	Yes

[Devyandu]

Scott @shaselton-usds , Yes, there could be a file with the same contracted rates but across multiple payers. It is not a matter of multiple payers teaming together, the scenario would be a single health plan producing the files for their several self-insured accounts (often 100s). Each self insured account would be considered a separate payer in this scenario with their own TIN#s. I support the idea of plans as an array, just need to think through the file naming convention. An index file per payer would work great to solve the issue. The file name coule be <date>-<payer-name>-index.json Inside this index file, we could have an array of all plans and the path to the plan's respective IN and OON files. Thanks for your support !! Dev

…

On Mon, Oct 25, 2021 at 5:42 PM Scott Haselton ***@***.***> wrote: @BobSyracuse <https://github.com/BobSyracuse> This might work. In thinking through what the actual name of the file would be that contains multiple plan's information -- I wanted to quickly check an assumption with you (and anyone else). Would there ever be a situation where a file containing multiple plans be from different payers/issuers? I would think "no", but we wouldn't want that to proved wrong. Even if all items/service had identical negotiated rates for the same providers across different payer's plans (this would be very interesting if they knew this before producing the files), they most likely wouldn't be teaming up to produce a single file... Thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#93 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADVHEXM55NWHW245C36ONB3UIXFKTANCNFSM45HZMA6A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[BobSyracuse]

@Devyandu You are correct about the self insured. In our design we have a driver table that indicates which are our self insured plans and we generate them as a separate IN and OON files exclusive of the other files we produce for ourselves. The driver table is also used for other files we produce as as a multi payer organization, outside of the self funded, to generate the correct set of IN and OON files for the correct payer "hat".

I didn't even think of that scenario since we consider them as you said their own payer and would not include them in the Plan array, but instead consist of a single Plan array element per our requirements on self funded/payer to support their individual publishing on the web for each payer.

Great call out!

[Devyandu]

@Devyandu You are correct about the self insured. In our design we have a driver table that indicates which are our self insured plans and we generate them as a separate IN and OON files exclusive of the other files we produce for ourselves. The driver table is also used for other files we produce as as a multi payer organization, outside of the self funded, to generate the correct set of IN and OON files for the correct payer "hat".

I didn't even think of that scenario since we consider them as you said their own payer and would not include them in the Plan array, but instead consist of a single Plan array element per our requirements on self funded/payer to support their individual publishing on the web for each payer.

Great call out!

@BobSyracuse
Hi Bob,
I have posted an idea in a new thread which will solve this problem. Please comment on that thread and let me know what you think.
#260
tx
Dev

[angelamarie0975]

@BobSyracuse - Quick question - the self insured groups - what are you putting as the reporting entity name and reporting entity type if you are splitting these files out? For us, we were keeping the reporting entity name the same as our other group or individual plans. Since each of the ASO groups would have their own EIN, why wouldn't they be included in the same file as the other plans in the array if they use the same network? We have some ASO groups that have multiple plans, so we were under the interpretation that the ASO group plans could just be included in the plan array for each of the plans since it is still the same reporting entity. If we separate these out individually, we are back to producing the mass number of files that this plan array was supposed to be a solution for - well not AS many files, but still quite a bit more than if we just went by the plan itself.

As for the naming convention - even if we do the index file, the individual plan files still have to be named something. Are we trying to use the index file, so that if we split out the numerous self insured plans into their own file, that file will just be a 'header' file and will point to the actual provider rates based on the file names in the index? I am having a hard time trying to understand this - it seems like it's adding a bit more complexity to this file. Maybe I am just having a hard time understanding based on my questions above.

[Devyandu]

self

@angelamarie0975
The idea is that there is one index file per payer. So each ASO account will have their own index file.
Within that index file there will be plans array as well as files (pointer) array.

[BobSyracuse]

@angelamarie0975 This is similar to the question I asked on the reporting entity name, Schema Field reporting_entity_name Clarification #36

[Paul-Sousa]

Could a very generic field like “unique_identifier”be added to the header (and naming convention)? That would give publishers flexibility in how they “tag” each file (i.e. PPO, PPO Self Insured, etc). Hoping there’s a simple solution for this. Sent from ProtonMail for iOS

…

On Tue, Oct 26, 2021 at 6:46 AM, Bob Krause ***@***.***> wrote: ***@***.***(https://github.com/Devyandu) You are correct about the self insured. In our design we have a driver table that indicates which are our self insured plans and we generate them as a separate IN and OON files exclusive of the other files we produce for ourselves. The driver table is also used for other files we produce as as a multi payer organization, outside of the self funded, to generate the correct set of IN and OON files for the correct payer "hat". I didn't even think of that scenario since we consider them as you said their own payer and would not include them in the Plan array, but instead consist of a single Plan array element per our requirements on self funded/payer to support their individual publishing on the web for each payer. Great call out! — You are receiving this because you are subscribed to this thread. Reply to this email directly, [view it on GitHub](#93 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AUM6ABAU5G7GMIVS7JQTFF3UI2BKDANCNFSM45HZMA6A). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).

[skochin]

We agree - some type of identifier (i.e. a product line or other grouping of plans) in the header of the file as well as the file naming convention would make sense. It would be flexible to let each reporting entity to come up with a meaningful name for the group represented within the file.

[Devyandu]

Here is a proposal for exactly the problem you mention. This will allow payers flexibility in how they want to report.
#260