In-Network-Rates File: Schema and Definition of Plan Name and HIOS/EIN

[BobSyracuse]

In the in-network-rates schema, the schema lists

• Plan Name as a String defined as "The plan name and name of plan sponsor and/or insurance company."
• Plan ID as a String defined as "The 14-digit Health Insurance Oversight System (HIOS) identifier, or, if the 14-digit HIOS identifier is not available, the 5-digit HIOS identifier, or if no HIOS identifier is available, the Employer Identification Number (EIN)for each plan or coverage offered by a plan or issuer."

There are cases where a single Plan Name can point to multiple Plan ID values. For example there can be a Plan Name of "Just PPO Gold" that can point to multiple unique 14 digit HIOS values.

The current schema to support the 14 digit HIOS would require the Plan ID to be represented as an Array, or looking at the 14 digit HIOS values for the data the first 5 digits of the HIOS are the same. So in this case even though there are multiple unique 14 digit HIOS available and based on the current schema Type of String, should the 5 digit HIOS identifier be used since they are the same value and could be used in the Type of String for Plan ID?

For example using fake information,

Plan Name, Plan ID (14 digit), Plan ID (first 5 digits)
Just PPO Gold, 51236553678932, 51236
Just PPO Gold, 51236879676466, 51236
Just PPO Gold, 51236987667232, 51236

using the existing schema we would use 51236 in the field for Plan ID?

[tdfow]

It is my understanding that if the 14 digit HIOS ID is available and unique then it would be used in reporting, resulting in 3 files in your example. If there is a unique HIOS ID, then wouldn't that indicate some difference, so wouldn't you have to refer to the Plan Name as Just PPO Gold 1 or Just PPO Gold 2 or Just PPO Gold 3--if they had all unique HIOS IDs? In your example, would all the providers and rates being published be the same for the Plan Name Just PPO Gold--regardless of HIOS ID?

[BobSyracuse]

The providers and rates are the same for the plan name of Just PPO Gold (the provider network type being PPO). The only differentiators causing the various HIOS values is because the premium rates may differ, the benefits or cost share or variables (dep 29, Contraceptives, etc) make it unique.

So either

• the Plan ID goes from String to Array
• use the first 5 for a String
• need as you pointed out concatenate a value, like 01, onto the plan name used in the file naming and the Plan Name schema field knowing any Plan Name/HIOS ID submissions to the state or federal agencies would not be exact if they were comparing Plan Names for the HIOS ID

[mmorri05]

Bumping for any new information.
Has the question been resolved regarding how the physical file/s for one plan for any one of the three types be generated?
Is the direction to combine/concatenate all data for a single "reporting_entity_name" into a single physical file as I see it when I read the FR?
Or... is it allowed to split the data into multiple files based on the "plan_id"?
If the latter, where in the FR does it allow that?

[MMath19103]

@BobSyracuse -- sorry about the delay on this one, there is actually a reason for it. What I can say here/now is that we can expect rule guidance on this front (HIOS/EIN) in the near future. Once it is out, I'll point the community to it.

@bryanbriegel is spot on with the HIOS documentation. Thanks for posting that. Here is documentation from CMS on how the ID is broken down if interested, first paragraph: https://www.cms.gov/CCIIO/Resources/Forms-Reports-and-Other-Resources/Downloads/HIOS-Plan-Finder-User-Manual.pdf#page=57

Hi - any updates on the updated rules?

[BobSyracuse]

@MMath19103 I was told by an individual in my organization that a CMS update should be released this week.

[MMath19103]

@MMath19103 I was told by an individual in my organization that a CMS update should be released this week.

Thanks Bob - are we looking for an update just for the EIN/HIOS or for plan / plan id ? I've lost track :-)

[BobSyracuse]

@MMath19103 I would have liked for all the above :-) But having not heard or seen anything this week, I question the validity of the source. I think we are all going to be stuck with what information we have for the 1/1/22 due date.

[RLTx1391]

Has anyone solutioned for cases where a single Plan Name can point to multiple unique 14 digit HIOS values?
@shaselton-usds you mentioned we expect rule guidance on this front in the near future. Is that still the case?

[angelamarie0975]

We have this scenario. Since the plan_id is where the HIOS information is and it is a part of the reporting plans object - a unique record is actually - plan_name + plan_id_type + plan_id + plan_market_type combined, so by having a different HIOS in that combination, it would make for a unique record in that array of plans. They will just happen to all have the same plan name, but their different HIOS or EIN if applicable, making it unique. This was one of the reasons for the TOC file to report these types of plans. Not sure if that helps at all?

[shaselton-usds]

@angelamarie0975 @RLTx1391 @BobSyracuse

There is a change in this PR: #447 that allows reporting at the 10-digit level vs the 14-digit level.

@angelamarie0975 is correct that plan_name + plan_id_type + plan_id + plan_market_type is the composite key for uniqueness in plan reporting -- hopefully the new 10-digit level and using the table of contents can point to a single file to cut down on the duplicate reporting.

[amyxguo]

how come plan_id alone won't be enough to uniquely identify plan reporting?

[JR-CMS]

The plan_id (when reflected as an EIN) is not sufficient to reliably identify the plan sponsor (i.e., employer), because there is no public way to look up an EIN to determine the common name of the entity it represents. In addition, the information disclosed in plan_name attribute is often that of the insurance company and not the plan sponsor. CMS is aware of this issue and is considering solutions to better identify plans in the MRFs.