Add required granularity to providers.json

[dportnoy]

This is the single most important aspect of the proposed schema that must be fixed.

Push the assignment of plan coverage and accepting new patients down to a lower level of granularity.

• All participants in the industry workgroup (comprising of payers, payer-provider intermediaries, providers and consumer facing apps) agreed that the original schema proposed will not address consumer needs, because assigning the core elements to the provider level doesn’t represent how insurance coverage works.
• In reality there are many-to-many relationships between practitioners and facilities, groups or addresses. It’s at these levels that plan coverage and accepting new patients needs to be assigned. This is also the correct level for assigning the specialty (as recognized by the plan) and hours. The actual relationships should look like this:

• Given the late stage in the rulemaking period, the best course now is to add the necessary level of detail as optional fields within the existing JSON entities, rather than more accurately defining new ones. This way, issuers will be able to provide a usable level of detail if they choose. The recommended modifications to providers.json:

Changes to providers.json

• NPI
• Type: INDIVIDUAL, FACILITY, ORGANIZATION
  • Name, address, phone
  • Specialty
  • Gender
• Plans (Array of plans)
  • Plan 1
    • (Array of network affiliations, which is any combination of: individual, facility, organization, and address within this plan)
      • Affiliation 1
        • Facility (NPI)
        • Organization (Group NPI)
        • Address
        • Hours
        • Accepting
        • Specialty (for this Plan, location, etc.)
        • NetworkID
      • Affiliation 2...
      • Affiliation 3...
  • Plan 2...
  • Plan 3...
  • last_updated_on

Explanations

• Items in italics are new fields. The rest are existing fields added to a lower level of granularity.
• Add a concept of Affiliation used to group any combination of individual, facility, organization and address for the purpose of defining a network.
• Add NetworkID as an optional field for describing the coverage relationships. This relationship is demonstrated in CCIIO’s own “Plan Attributes PUF” (see Data Dictionary and PUF data file). By enabling storage of NetworkID, it will be possible in the future to more concisely describe the relationship between insurance products and providers.
• Add Specialty at the level of affiliation, since each plan may classify a provider differently under their coverage.

Reference: Comments on PRA for QHP schema 2015-07-27