Same PlanID but different values in Plans.json

[raychungcigna]

Hi,

We have plans that will have different values between 2016 and 2017 such as the summary URLs, marketing URLs, marketing names, copay, etc, but they will have the same plan IDs in both years. The current schema does not seem like it can support such cases due to lack of arrays in some of those data elements. We want to see if we can treat them as separate plans in the json file but they will have the same plan IDs. For example:

[
{
"plan_id_type": "HIOS-PLAN-ID",
"plan_id": "97667AZ0110003",
"years": [2016],
"marketing_name": " Cigna Connect HSA Bronze 6000",
"summary_url": "http://www.cigna.com/individuals-families/2016-plans/sbc/arizona/connect-hsa-bronze-6000",
"marketing_url": "http://www.cigna.com/individuals-families/2016-plans/sob/arizona/connect-hsa-bronze-6000",
"formulary_url": "http://url/to/formulary/information",
}
{
"plan_id_type": "HIOS-PLAN-ID",
"plan_id": "97667AZ0110003",
"years": [2017],
"marketing_name": "Cigna Connect HSA 6000",
"summary_url": "http://www.cigna.com/2017/sbc/cigna-connect-hsa-6000-az",
"marketing_url": "http://www.cigna.com/2017/sob/cigna-connect-hsa-6000-az",
"formulary_url": "http://url/to/formulary/information",
}

],

This would allow for the differing Marketing Name, associated URL’s, and other data to be captured while maintaining the integrity of the schema.Is it possible? Or do you have any other ideas? '

Thanks,
Raymond

[greggersh]

Hi @raychungcigna take a look at this: e1876ac...2017-changes

I think it should address your issue, by adding the ability to specify a year for the plan.

[raychungcigna]

Hi Greg,

Thanks for the feedback. Please accept my apology in advance if I misunderstood you. But the issue we are having is that although we have the same planID for both 2016 and 2017, the plan's information differ between the years. So how should we handle this? If we treat the plan as two separate plans like the example above, would that cause any issues?

[Nick-HealthJoy]

Hello, @greggersh,

I think that @raychungcigna is correct here, because health plans with the same ID for different years is a big problem. I guess that Plan ID supposed to be unique year to year by design, but the real situation on carriers side is pretty different.
Adding an array of years causes trouble for the support of different properties like a formulary URL or plan name.

Look at the real situation with doctors: the same doctor can be in network for 2016 and out of network for 2017. This may cause problems for users buying the wrong plan on HealthCare.gov, as they think, for example, that their family practice doctor is in network for the plan they are going to use for the whole following year.

So it would be nice to switch from Plan IDs to Network IDs in providers.json file (+ having networks.json, as @dportnoy mentioned in #12 ). Network ID is already used in CMS PUF files, but they are not unique and can be identified only by issuer + network id + year. A carrier may have several issuers in different states, but one MRF source for all, like big corporations do.

So, if you get the structure proposed by @raychungcigna for plans.json
AND in providers.json instead of this:
"plans": [ { "plan_id_type": "HIOS-PLAN-ID", "plan_id": "12345XX9876543", "network_tier": "PREFERRED" },

this one will be used:
"networks": [ { "issuer_id": 12345, "network_id": "IL005", "network_year": 2016 },

the result will be very nice.

With these changes:

1. It is possible to have different plan objects for each year with the same plan ID, so no problems for carriers and developers who use this data;

2. Plan object is connected with Network object. Unique Plan or Network object is defined by ISSUER + ID + YEAR

3. A provider is connected to a unique Network object, so this removes problems for those who will use systems based on this data. This will also decrease sizes of JSON files and simplify its processing.

Thanks!