What information does an HIOS ID capture?

[felix-hh]

I noticed that the plans are reported at the 10 character HIOS identifier if available, otherwise by the 5 character HIOS Issuer ID and otherwise by the EIN. This is different to how plans are identified in other datasets. Importantly, I am having enormous trouble understanding how the plan_id maps to one or multiple real life plans.

Referencing #500 by @shaselton-usds :

Here is what the 14-digit ID is comprised of:
Issuer’s ID number, (first 5 digits, e.g. 12345)
the Issuer’s state abbreviation, (next 2 digits, e.g. WA)
the Issuer’s three digit Product ID, and (next 3 digits, e.g. 001)
a four digit sequence number that is the “Component ID” (last 4 digits, e.g. 0001)

Here's my questions:

1. When I go to the CMS PUF data website, they have the Plan Attributes file which reports details for specific PlanIDs, for example whether a plan is HMO or PPO, or the level of cost-sharing using the 14 character HIOS id. The in_network and table_of_contents price transparency file use the 10 character HIOS. Does this mean that the negotiated rates for the 10 character HIOS Id (product-level) applies to all of the plan variants within that product?

Here's an example: does the in network file in the image below map to each of the plans in the table, even though some of them are Bronze, others are Silver and others Gold? Note that they all have the same 10 character HIOS ID.

<style> </style>

BusinessYear	IssuerMarketPlaceMarketingName	SourceName	StandardComponentId	PlanMarketingName
2023	Aetna CVS Health	HIOS	18628FL0160025	Bronze S: Aetna network of …
2023	Aetna CVS Health	HIOS	18628FL0160029	Silver 1: Aetna network of …
2023	Aetna CVS Health	HIOS	18628FL0160010	Silver 2: Aetna network of …
2023	Aetna CVS Health	HIOS	18628FL0160034	Silver 3: Aetna network of …
2023	Aetna CVS Health	HIOS	18628FL0160020	Silver S: Aetna network of…
2023	Aetna CVS Health	HIOS	18628FL0160015	Gold S: Aetna network of …
2023	Aetna CVS Health	HIOS	18628FL0160007	Gold: Aetna network of…

Understanding this is mission critical as I cannot do any kind of healthcare economics research if I am unable to know what the plan underlying all of this in_network_rate information actually is. I.e. let's say I want to compare HMOs and PPOs, and see the impact on negotiated rates (somebody did this with Massachusetts claims data and saw HMOs tend to be 5% cheaper compared to PPOs, as seen in this paper). To replicate this / empower other researchers I need to tie the in_network rate information to the plan attributes information.

Similarly, if I want to provide a price transparency tool, I must be able to link the information about the plan coming from the user to actual in_network_rates information. I can't do that if the files are reports for products and not plans!

2. if I understand what I referenced correctly the field is named reporting_plan_id, however, this seems not to be accurate / coherent with 5,10, or 14 digit HIOS - Potential for all to be acceptable? #500. It is a reporting_product_id - which means that many plans are actually represented by the in_network rates file. Am I right? Does this mean I need to look at the reporting_plan_name to distinguish plans within the same product? I have noticed there are multiple plan_names sharing the HIOS ID or EINs and referencing different files...

As a quick note, with the availability of table of contents files that map multiple plans to a single file, it seems that referencing plans directly by the 14 character HIOS ID might be more clear and would not cause redundancy. This data can be incredibly useful but only if we are able to integrate it with other datasets.

Would appreciate clarification to be able to work with the data knowing what it actually means. Many thanks and all the best!

[bryanbriegel]

re: "Here's an example: does the in network file in the image below map to each of the plans in the table, even though some of them are Bronze, others are Silver and others Gold? Note that they all have the same 10 character HIOS ID." - they should. The 10 byte HIOS ID defines the product, the 14 byte defines the specific plan being offered. (Early on there was concern/feedback that contracts are negotiated at the product v plan level and that shaped the requirement to 10 byte HIOS ID from 14) To your question on Metal levels, those represent the actuarial value of the plan to the member - based on member cost share vs rates negotiated with providers. Here's a good CMS reference on Product v Plan - https://www.cms.gov/CCIIO/Resources/Training-Resources/Downloads/product-vs-plan-ppt.pdf

[felix-hh]

OK so some foundation based on what you said and the document you shared, please correct me if I'm wrong

Products vs Metals vs Plans

• Products share benefits covered (dental, pediatric care, gender-affirming care, etc), network type (HMO, PPO, EPO, etc).
• A product is represented by a 10 character HIOS ID.
• A product encompasses different metals which encompass different plans
• Metal level is determined by cost-sharing structure also called actuarial value, as you mention
• A plan is associated with a given product and Metal level and has a 14 character HIOS ID

Plans within a product can have different:

• cost-sharing structures (Metal level)
• provider networks
• service areas

---

This is highly illuminating. Thanks for all the info!

You said that early on, a 14 character HIOS ID was required, but based on feedback it was discovered that actually a 10 character HIOS ID is enough because plans within a product share negotiated rates hence the last 4 digits generate redundancy so the schema specification changed. So plans within products in theory should have common in_network file info / negotiated prices.

This is already surprising me, because plans within a product can have different provider networks and service areas Let's say you have 2 plans in a product which have different provider networks. How can plans share negotiated prices, if plan A has a network that includes provider x but not y, and plan B a network that includes provider y but not x? Clearly there is something I am missing. I either don't understand the concept of a provider network or 2 plans can't have the same negotiated prices if they use have different networks.

But let's assume that all plans in the same product do indeed share the same in_network file. Then I don't understand why Aetna named the reporting_plan_name "Aetna CVS Silver_51189" when the information also applies to Bronze and Gold plans with the same 10 character HIOS ID. This is highly confusing to me, an it is especially confusing because now I don't know if Aetna is reporting on the entire product line or just a plan. Note that as of now, Aetna has no other reported_plan_name associated with this HIOS ID, even though other plans exist within the same product line.

I see that all plans in a given product share the same Benefits and Network Type, so I should be able to compare HMO vs PPO vs ASO even if I only have the 10 character HIOS id. That's some progress...

[bryanbriegel]

Re: "A product encompasses different metals which encompass different plans" - I would say a plans often have multiple metal levels - same product/benefit offering or benefit package with different share (on average) paid by the health insurance issuer in the case of ACA plans - same plan, 80% gold, 70% silver, 60% bronze AV of the plan. see https://www.qhpcertification.cms.gov/s/Plans%20and%20Benefits%20FAQs and too note the AV of a plan is expressed by bytes 15-16 of the HIOS Plan ID - the max verbosity of an ACA plan is to the 16th digit, not related to the negotiated rates. "Plans are certified at the Standard Component ID level. All cost sharing plan variations, including the Zero Cost Sharing and Limited Cost Sharing plan variations, must meet the QHP certification standards to be certified. On the Cost Sharing Variance worksheet of the Plans and Benefits template, the plan variations are distinguished by adding a code to the Standard Component Plan ID as follows:

• 00 = off-exchange variant
• 01 = on-exchange variant, or standard plan
• 02 = Zero Cost Sharing Plan Variation
• 03 = Limited Cost Sharing Plan Variation
• 04 = 73% AV Level Silver Plan Cost Sharing Reduction (CSR) plan variant
• 05 = 87% AV Level Silver Plan CSR
• 06 = 94% AV Level Silver Plan CSR"

[felix-hh]

Got it, so in HIOS there are 2 more bytes that specify plan variations beyond the "Standard Component ID" which is 14 bytes, and these are variations that CMS standardizes, and which is different from the "metal level" of the plan since it denotes whether a plan is on or off CMS exchange for example. So we have a product (10 byte ID), a plan (14 byte ID) and a plan variant (16 byte ID) as the different levels of specificity for HIOS.

So this gives me a very nuanced understanding of what a plan is. Thank you for the additional information.

But my first question is still unresolved. How do you attribute the rates in a given file to a given plan? In my first example, is Aetna reporting all plans in a given product, HIOS-18628FL016 or is it reporting only Aetna CVS Silver_51189 which is a specific plan?

Because as you mention, the 15th and 16th bits are not related to the negotiated rates. But what about the 11th-14th? After all, plans are allowed to have different provider networks and service areas, which might imply different in_network files...

[bryanbriegel]

re: "How do you attribute the rates in a given file to a given plan?" - this can be nuanced, and not as straightforward as laid out by Regulation and can vary based on interpretation. It may require pulling some files and evaluation if its not clear and ultimately there are cases where contacting the entity that created the files may be required to confirm.

[felix-hh]

Got it, thank you @bryanbriegel .

So there is a high level of ambiguity in mapping a file to a plan, which requires kindly contacting every payer for each of the 50,000+ files available. If this is true, I think it goes highly against the spirit of the TiC Act.

As you mention, in Page 235 of the Final Rule is not updated and still maintains that what should be reported is the 14-digit HIOS ID even if the schema has de-facto changed.

Plans and issuers must include their HIOS ID at the 14-digit product level unless the plan or issuer does not have a HIOS ID at the plan or product level, in which case the plan or issuer must use the HIOS ID at the 5-digit issuer level. If a plan or issuer does not have a HIOS ID, it must use its EIN.

Is this true or are we missing something? I don't see how a developer or researcher can efficiently map a file to one (or multiple) plans if only the 10-byte HIOS ID is reported in the table_of_contents file and the in_network_file.

[EvidentData]

@felix-hh Any more learnings or updates you can share? Currently trying to identify MRFs by plan and map rates for BCBS TX plans.

From what I have gathered Aetna is especially cryptic so that may have been a difficult place to start.

[felix-hh]

Hi @EvidentData my research re: HIOS ID codes is pretty much distilled above, I found it hard to map a file to a specific plan at least when it comes to HIOS ID. I don't have that much experience dealing with BCBS TX. If you have more specific questions lmk and we can compare some notes.