File naming convention- proposal to use index files at payer level (and reference files)

[Devyandu]

Here is a proposal to use index files inspired from existing CMS QHIP machine readable file regulations.

Introduce a new payer based index file which has the pointer to all the plans for that payer and their respective files.

Index file naming convention

<yyyy-mm-dd>-<Payer-Name>-index.json

Sample Index File

{
  "reporting_entity_name": "medicare",
  "reporting_entity_type": "medicare",
  "reporting_structure":[
  {
	   "reporting_plans": [{
		"plan_name": "medicaid",
		"plan_id_type": "hios",
		"plan_id": "11111111111",
		"plan_market_type": "individual"
	  },{
		"plan_name": "medicare",
		"plan_id_type": "hios",
		"plan_id": "0000000000",
		"plan_market_type": "individual"
	  }],
	  "in_network_file_list": [{
		"description": "National network file",
		"file": "./somepath/1234567890ABCD.JSON"   /* Or absolute path e.g. https://someserver/somepath/somefile.JSON */
	  },{
		"description": "Behavioral Health File",
		"file": "./somepath/987654320ABC.JSON"
	  }],
	  "allowed_amount_file_list": [{
		"description": "National network file",
		"file": "./somepath/999977776666.JSON"
	  },{
		"description": "Behavioral Health File",
		"file": "./somepath/444455556666.JSON"
	  }]
  }
  ]
}

Concepts

1. One index file payer payer
2. A payer can list all those plans in an array which have the same "reporting structure". As-in, same provider contracts.
3. The in-network files for one "reporting structure" can be a list of files. This solves a fairly large problem that many payers are currently facing. Many payers use leased networks for out-of-state coverage (also for certain types of coverage e.g. Behavioral Health). The current regulation would force us to ingest huge files from our leased networks and merge that data with our own pricing contracts to produce a plan level file. This proposal would allow the payer to publish all files that make up their complete "in-network" as an array of files. This is a huge processing and storage efficiency since we can simply publish files from multiple vendors without processing and merging them.
4. No need for file name convention outside the index file. The index file has pointers to the individual files.
5. This proposal ensures saving of compute and storage resources as well as provides flexibility so every payer can decide how best to combine as per their data. The consumption is data is slightly more complicated since data could be in multiple files but overall this helps.
6. We would need a small change in the in-network and allowed amount files. They no longer need the root node.

Thanks
Dev

[Devyandu]

@shaselton-usds Hi Scott - Tagging you for your attention.
This flexible approach, solves file naming convention, is in-line with earlier CMS Machine Readable file rules and avoids payers having to merge a large amounts of data.

[angelamarie0975]

@BobSyracuse @Devyandu thank you for the responses in the other post. I figured my response best fit this post. The idea of using this index file wouldn't be required for everyone, would it?

We don't have any ASO groups where we are not the reporting entity or hosting on our site, so that is why I am having a hard time understanding how this index file would benefit us specifically. I don't know how that would work for us as we are the reporting entity and the host as well. We still have to produce the product plan files and those are associated to more than just the ASO groups - they include standard group plans as well as individual plans. I am just not understanding the benefit this solution is providing exactly - at least for our company because I don't see how that would work for us to reference a file instead of just adding those ASO groups to our plan array. If that makes sense?

[BobSyracuse]

@Devyandu So it would be in essence the carving out of the of the INN/OON array, as in the case of the In-Networks Rate file

in_network	In-Network Negotiated Rates	Array	An array of in-network object types	Yes

and allowing for multiple In-Network Negotiated Rates arrays similar to the post from @jonberkery-work, In Network Rates - Schema Update - In Network Object - 2 dimensional Array? #223, but instead each array would be a file reference of

{
"description": "National network file",
"file": "./somepath/1234567890ABCD.JSON"
}

This would resolve the issue being asked for functionality to allow for a file reference as found in the post from @vijayanandramamoorthy, In-Network file for plans with national networks. #222, and others.

@shaselton The post by @Devyandu calls out a common theme, similar to other posts, in the aspect of needing a mechanism within the publishing of the MRF files to allow for the ability to reference data/files allowing for savings in storage/egress for producer and consumers when the In-Network Negotiated Rates/Out of Network array is duplicated across multiple plan files.

@taylorpatriciab Could you comment if possible for Scott on the potential for data duplication for the In-Network Rates file and how the ability to have a file reference would prove beneficial for payors/plans in reducing file size?

[garysolebc]

Agreed - the references should not be direct or referential file references, but rather URL references. We work with other plans that have their networks in other states - it would be great if we could just reference their published network file rather than embedding it or hosting it ourselves.

[Devyandu]

Good point.
I have updated my original post to clarify that reference can be a relative or an absolute URL.
Yes, it would be great to just reference the out-of-state files network files hosted on a different plan's site.
Thanks!

[BobSyracuse]

What if you had a bad actor that has manipulated the URL reference in a file you would not want to link to or have a consumer download. Just thinking of the old XML External Entity attack and if this would introduce a variation of it. Just thinking out loud.

[taylorpatriciab]

@shaselton At first glance, the proposal to reference vendor or other plan network data would be so much more efficient than embedding the data in files. It would remove the requirement for vendors and other plans to transmit the data and the requirement of the publisher to store and process the data.

[Devyandu]

What if you had a bad actor that has manipulated the URL reference in a file you would not want to link to or have a consumer download. Just thinking of the old XML External Entity attack and if this would introduce a variation of it. Just thinking out loud.

Interesting point. Some thoughts.

• If the bad actor is a payer from whom consumers are downloading MRF then that bad actor payer now has bad data on their site. If they are not a payer then it is no different than a random site having a data file which has a reference to one of your data files. The individual files would be updated every month (and their names likely change) so the bad actor would have to keep up with this.

• If the file that was linked to, is not a file you want a consumer to download at all then that file should not be left public.

• One real problem that a bad actor can cause a host is high egress charge. This is an existing concern and the proposal of index file does not make it any worse.

• One consideration when designing references is not to design anything which can cause a cyclical reference type problem. That is why the links were put in the index file rather than in the in-network file. The references can only be one level deep from the index. (no concept of a referenced file including even more files).

• At some point CMS might want to roll out a "registry" concept where every payer registers their MRF with a central registry. When we reach that point, the index file would be really helpful since only one URL has to be registered. That would make life easy for consumers too since they would not have to rely on web crawling to find MRF.

• The timestamp part of the index file's name could certainly be removed and made a data element inside the index JSON. That would make the file name a static -index.json

Definitely worthy of more thought but at this time this does not appear to make anything worse than it already is.
.

[Devyandu]

Hi @BobSyracuse
Thanks for the excellent analysis. Here are the problems that this proposal will solve.

1. Solves file-naming convention problems now that a single file can have multiple plans
2. Others have asked for way to "Include" files. This proposal solves for that. As I described in my original post, some plans use leased networks and those files need merging with the plan's own files. It would be wonderful to just "reference" a file hosted by the leased network vendor instead of transferring the huge file and merging it's content into multiple plan files which include the leased network.
3. Helps with discoverability of files. A single index file provides the full map of all exposed files. This is inspired from CMS QHP Machine Readable files regulation. In that regulation payers register the index files with CMS so that CMS can crawl and ingest the files.
4. The proposal should not cause a lot of re-work in the work already in progress at payers. Very minor changes would be needed to existing schemas (removal of root node).

Thanks

[shaselton-usds]

@Devyandu

Thank you for this.

Walking through this to be explicit (although you've done a fantastic job of that already) -- also, I took out some columns in the table to allow it to be more viewable in this comment:

Index Root (or some other name)

Field	Type	Definition
reporting_structure	Array	An array of objects for each plan/product per payer/issuer

Reporting Structure

Field	Type	Definition
reporting_plans	Array	An array of reporting plan object types
in_network_file_list	Array	An array of in network file list object types
allowed_amount_file_list	Array	An array of allowed amounts file list object types

Reporting Plans Object

Field	Type	Definition
plan_name	String	The plan name and name of plan sponsor and/or insurance company.
plan_id_type	String	Allowed values: "EIN" and "HIOS"
plan_id	String	...removed to save space...
plan_market_type	String	Allowed values: "group" and "individual"

In Network File List Object

Field	Type	Definition
description	Array	description of the file included in the in_network_file_list array
location	String	A full fully qualified domain name on where the in-network data can be downloaded

Allowed Amounts File List Object

Field	Type	Definition
description	Array	description of the file included in the allowed_amount_file_list array
location	String	A full fully qualified domain name on where the allowed amounts data can be downloaded

This makes sense. The index file would have all of the different plans that they offered split up within reporting_structure array and the reporting_plans array would still allow grouping for plans that have the same negotiated rates (although, this doesn't matter as much now because you could have multiple reporting_structure objects with single reporting_plans that would/could point to the same URL)

I wonder how well validation will work for the URLs -- in the case that the location attribute has a URL that points to something not there or incorrect. This is a concern. Both the TOC/index file and the other INN/OON files would still have to be publicly discoverable.

[BobSyracuse]

@shaselton-usds I agree there would be a concern on the validation of the URLs, but would there not be an issue if someone posted a poorly formatted file in JSON? Could not the same feedback that would have reported the poorly formatted file be the same for a invalid location?

I really like @Devyandu idea of the "registry" since a central registry could easily be walked for a broken link and reported back to the reporting entity to correct and act as a one stop shop for consumers to easily locate this information.

[shaselton-usds]

I hear you RE: registry. Just to signal -- that most likely isn't going to be an iteration that we'll be seeing prior to the implementation date, if at all, so we'll have to work around that assumption.

[BobSyracuse]

@shaselton-usds I understand, but figured it couldn't hurt to ask :-)

[Devyandu]

@shaselton-usds and @BobSyracuse Thank you for your comments.

1. Scott - You bring up a good point. reporting-plans does not have to be an array. Multiple plans could simply reference the same file/URL. This would simplify the proposed schema a little bit. The reporting-structure and reporting-plan could be merged and made into a single object.
2. Yes, there is a possibility of the referenced URL being down/unavailable. This would be an issue with any approach where "references" are used instead of merging the data.
3. The merging of data from "leased national networks" is a big problem and we remain hopeful that we can find a way to use "references" instead of merging terabytes of data into multiple plan files.
4. Your comment on the registry not being on any immediate roadmap is understood.

Is there a chance we could get guidance on file names and references in the upcoming webinar?

[garysolebc]

I provided a similar reference idea here: #231

One of the advantages I see with having references allowed even at a lower level is that it may be we can have files per billing code. This would allow consumers of the files to be able to select specific billing codes they wish to be focused on rather than all 30,000 coming down every time. Only data of interest to clients needs be transmitted. Smaller files will be easier to validate.

[ageitgey]

I appreciate the idea. But in my opinion, splitting up the files at multiple levels makes it hard to download the entire dataset without potentially having to spider through thousands of files. So while it may be more convenient if you only need a specific code, it would be difficult to fetch wider swaths of data.

I would argue that the kind of use case you are describing would be better served by implementing a REST API that let the user fetch data for specific codes. For the use case of downloading the entire file, I would prefer that the data not be split up "too much".

[garysolebc]

Currently, using the approach here where we have a collection of network type files references - my estimate is each file would be between 15Gb and 20Gb - this might have some challenging consequences - breaking it down to billing code level, would leave us with files sizes around 2 Mb each. All of this data is not going to be fetched manually, it will be needed to be scripted in some way. If I have as script in a loop to pull down 30 by 20Gb files or a loop that pulls down 100,000 2Mb files - I still need to script and process it. The 2Mb files will be far easier to hand off to some process than a 20Gb file

[garysolebc]

We were thinking of using a network name for the file. Each file would have the billing codes and providers for that single network. This allows us to have a corresponding out of network file that will relate to all claims that made by members in that network to providers who are not in the network.
For plans or groups that have multiple networks, we would just repeat that plans data in the array in the other file related to that network.

[ageitgey]

We at Turquoise Health are often on the data consumer side. I like this proposal because it solves several practical problems for data consumers (as well as providers):

1. Splitting up the files makes it less likely that consumers will run into issues with web servers that struggle with serving huge files (which is common in practice).
2. The files are not split up too small, so it's still practical to fetch all of them at once.
3. For web servers that support it (most of them), it would be possible to only re-download each sub-file if that specific file had been updated since the last download date (via Etag headers). Over time, that could save a lot of bandwidth for both the server and the consumer because changes to rates in one plan wouldn't require the entire file to be re-downloaded again.

However, if organizations split files into several parts, it's important that downloading all of the files at once doesn't trigger any automated blocking due to the server mistaking the user as an abusive bot. I could see some automated systems noticing that a user is downloading 100+ files and interpreting that as an attacker to block. Blocking users who download the data would of course defeat the purpose of posting the data.