Naming convention for table of contents file seems to be too restrictive

[nmayle]

Several payers have more than one table of contents file on their site with each containing information for some subset of their own (fully insured) plans.

Is this allowed?
There doesn't seem to be any restriction that would disallow it.

If it is allowed, then the naming convention for the table of contents (index) files, needs to be extended to incorporate the possibility of more than one file.

There is a payer that has two table of contents files up with the same name, but different content. In principle they are following the specified naming convention of __index.
and since the payer is the same, both files have the same name. That is clearly not ideal.

There are other payers who have improvised on the naming convention and done things like:

2022-11-01_Excellus-BlueCross-BlueShield-TPA_index.json.gz
2022-11-01_Excellus-BlueCross-BlueShield_index.json.gz
2022-11-01_excellus-blue-ppo-signature-deductible-3_index.json.gz

It would be better to have a convention that cover this structure than a set of ad-hoc solutions.

Thoughts?

[JR-CMS]

Thank you for raising this query. It would be helpful if we could assess this through our formal process. If you believe you are observing a violation of the TiC requirements, please submit a complaint using our form here: https://www.cms.gov/healthplan-price-transparency/contact-us

[bryanbriegel]

@JR-CMS - following on to the concern - to ensure discoverability of the data, and to allow consumers of the MRFs to readily attribute the published rate data to the issuer/group health plan, would you like suggested schema updates/ naming convention updates etc to also be sent to the 'contact us' link above? eg in addition to what has been noted, we have concerns certain fields are defined as "Optional" where they are more explicitly 'Conditionally required' - however they are currently labeled 'Optional' are entirely being omitted. Thank you.

[JR-CMS]

@bryanbriegel We always welcome feedback directly through the contact form on our website. We request that comments/complaints/questions regarding any specific MRF or set of MRFs be directed through our webform (https://www.cms.gov/healthplan-price-transparency/contact-us).

But general suggestions for schema updates or requests to change schema elements are best saved for GitHub, which Scott and I do monitor regularly.

[bryanbriegel]

@JR-CMS - would you please direct me to the "contact form" on your website - I appreciate it. thank you!

[JR-CMS]

@bryanbriegel https://www.cms.gov/healthplan-price-transparency/contact-us

[bryanbriegel]

thank you!

[shaselton-usds]

@nmayle The intent was that there would be a single ToC. Thanks for pointing this out. We'll have to think through if/how a change could be made. At this point, any changes on this front and putting a requirement behind it would most likely be tied to a regulatory process.

As a consumer of the files, there are ways to approach this to avoid duplicate downloading (though the additional steps are admittedly annoying, but not really that difficult to do). There are numerous HTTP headers that can be checked to compare ToC files for non-parity. From timing to size detection to file hash may be leveraged.

In the meantime, feel free to submit your observations on the topic to the web form so we can get an idea on just how much this is actually popping up there in the wild.

[nmayle]

Why would this change require a regulatory process? How is the file naming convention a regulatory issue?

We have technical ways of dealing with deficiencies in the design, but that doesn't mean that they aren't deficiencies that can and should be corrected.

[bryanbriegel]

@shaselton-usds - If I recall, the Regulation does not imagine a Table of Contents file, rather that was a structure established via GitHub to assist in reduction of redundant data. Would it not follow that any update or clarification regarding the implementation of a Table of Contents file would also be delivered via GitHub vs through regulation? Wondering as at Merative, we are tracking this thread and would like to understand if this would be achieved via technical guidance here vs. regulation. Thank you -