Use Case 28: Verify accuracy of healthcare.gov Plan Finder

From Demand-Driven Open Data
(Redirected from Use Case 28)
Jump to: navigation, search

Want to be notified when this use case or any of its datasets change?
You’re signing up to be notified on changes to this use case and associated data sources
* indicates required

Use Case

Use case summary

  • Title: Verify accuracy of healthcare.gov Plan Finder
  • Work item: https://github.com/demand-driven-open-data/ddod-intake/issues/28
  • Status: Closed. PlanFinder is intended for off-exchange (off FFM) plans only. PlanFinder is not meant to be a comprehensive list of every plan available; it is only intended to display the potential options for consumers looking to purchase insurance off the exchange. See the Solution section for full details.

Description

  • The origination of this use case came because of noted discrepancies between PlanFinder data and known insurance plans. For example, the data pulled back from API calls were checked against Prominent Plans offered in Arlington, VA and state of TX and discrepancies were noted (e.g., CareFirst was missing from VA and TX only returned 4 plans)
  • The original core questions to answer:
  1. How complete is the data set supposed to be? Does it have every on- and off-exchange plan available in the country?
  2. If it's not supposed to be complete, what plans/issuers/scenarios are systematically missing in the data?
  3. Why are there specific cases of known plans missing?
    • (For example: Not getting any Carefirst / BCBS plans returned in Virginia)

Value

  • Value to customer: Needed to assist users to find best plans
  • Value to industry/public: Needed for a For the API to be useful to anyone, it must be trusted for accuracy and must clearly indicate whether there are gaps in data.

Customer

  • Equate Analytics

Current data and limitation

What data is available through the HealthCare API?

All of the data used on the Finder.HealthCare.gov web application is available through the API. There are multiple collections of data available through the API.

PlansForIndividualOrFamily
getIFPPlanQuotes: This request will return a list of plans based on census data, location, and effective date. Results can be filtered, sorted and paginated.


Solution

Completeness

Question: How complete is the Plan Finder API?  Does it have every on- and off-exchange plan available?

Answer: Plan Finder is intended for off-exchange (off FFM) plans only. Plan Finder is not meant to be the comprehensive storage mechanism for all plans; it is only intended to display the potential options for consumers looking to purchase insurance off the exchange. While there is some overlap where many on-exchange plans appear in the dataset, this does not guarantee a comprehensive list of every plan.

On-exchange plans are also available on data.healthcare.gov under the term "QHP" (Qualified Health Plan).

Plan Finder data is the result of self-reported Issuer submissions, which pass several validation steps and a culling process. A plan could be missing from Plan Finder for any of the following reasons:

  1. Issuer chose not attest entirely
  2. Issuer failed validation steps for the plan
  3. Issuer didn’t to update needed data
  4. Issuer didn’t submit within in the time window
  5. CMS/CCIIO has not yet fully validated the plan by the time of query
  6. Certain exceptions apply:
    1. Products not open to enrollment are not required to submit plan information
    2. Large group, association, and “grandfathered” products are not required to submit plans
    3. Non-major medical products are not required to submit plans
  • How on-exchange plans differ from Plan Finder... See on-exchange plans listed at QHP Landscape Individual Market Medical. Approximate row count is 78,000. Last data available as of June 2015 was August, 2014. Plans that are offered on and off exchanges may be similar, but individuals may choose to buy from a limited number of on-exchange plans, due to subsidies available to them or to find coverage despite pre-existing conditions. Some issuers choose not to offer gold and platinum plans on exchanges, due to risk of adverse selection as a result of the guaranteed issue.

 

 

Identifying Missing Plans

Question: Is there another system of record that would be useful in identifying which plans are missing from Plan Finder (for any of the above reasons)?

Answer: There is no complete or up-to-date internal system of record that could be used to identify missing plans.

To get a full list of all plans available in a year (regardless whether they were submitted to Plan Finder), there is a series of datasets that need to be compiled. There are 2 possible starting points: the URR (Unified Rate Review) and FM datasets.

  • URR
    • Location: The URR dataset is published here:  https://data.healthcare.gov/browse?q=URR&sortBy=relevance&utf8=%E2%9C%93
    • Refresh frequency: Release schedules are not currently published, but final refreshes are planned to be posted quarterly, staff permitting
    • Size: Row count: Approx. 65,000.
    • Availability: Last updated on data.healthcare.gov (Socrata portal) November 2014 for 2015 Plan Year.
    • Latency: Data is retrospective, meaning that it does not identify the plans that are currently available, but rather those that were available for the prior period.
      • For example: Data for all Plans for 2014 don’t get fully complied and finalized until end of June 2015.
  • FM:
    • Limitation: Internal to CMS and not published. (This statement still needs to be verified.)
  • These datasets don’t document the exceptions granted to Plans (e.g., Large group, association, and “grandfathered” products)?

Short term workaround

  • If there's enough demand and sufficient CMS resources, users might push for...
    • the URR dataset to be provided with less latency or updated more frequently
    • the FM dataset to be made publicly available


Long term implementation

  • Ideally CMS/CCIIO would create a system of record to hold a complete, up-to-date list of plans. However, there doing so would be challenging and require both substantial development and significant change to existing processes. There are no plans for such a system at this time.

Want to be notified when this use case or any of its datasets change?