SUMMARY

DDOD use case to verify the accuracy of data obtained from the HealthCare Finder API after a user identified potential data quality issues.

WHAT IS A USE CASE?

A “Use Case” is a request that was made by the user community because there were no available datasets that met their particular needs. If this use case is similar to your needs, we ask that you add your own requirements to the specifications section.

The concept of a use case falls within the Demand-Driven Open Data (DDOD) program and gives you a formalized way to identify what data you need. It’s for anyone in industry, research, media, nonprofits or other government agencies. Each request becomes a DDOD use case, so that it can be prioritized and worked on.

Use Cases also provide a wealth of insights about existing alternative datasets and tips for interpreting and manipulating data for specific purposes.

PURPOSE

Clarity is needed around how completeness of the data via the HealthFinder API.

• Is it intended to be a complete data set? e.g., does it have every on- and off-exchange plan available in the country?


• If it is not intended to be a complete data set, what fields (eg, plans, issuers, scenarios) are systematically missing in the data?


• Why are there specific cases of known plans that are missing in the data (eg, no Carefirst/BCBS plans in Virgina)?

VALUE

In order for the HealthCare Finder API to be useful, it must be a trusted source and accurate; if there are data gaps, those must be clearly documented. The API is critical in assisting the users to find the best healthcare plans.

USE CASE SPECIFICATIONS & SOLUTION

Information about this use cases is maintained in a wiki: http://hhs.ddod.us/wiki/Use_Case_28:_Verify_accuracy_of_healthcare.gov_P...

It serves as a knowledge base.

USE CASE DISCUSSION FORUM

All communications between Data Users, DDOD Administrators and Data Owners are logged as discussions within GitHub issues: https://github.com/demand-driven-open-data/ddod-intake/issues/28

It aims to provide complete transparency into the process and ensure the same message gets to all participants.

CASE 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. While there is some overlap where many on-exchange plans appear in the dataset, this does not guarantee a comprehensive list of every plan.

The PlanFinder API and website return the same data.

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

SUMMARY

DDOD use case to request access historical label revisions of FDA-approved drugs.

WHAT IS A USE CASE?

A “Use Case” is a request that was made by the user community because there were no available datasets that met their particular needs. If this use case is similar to your needs, we ask that you add your own requirements to the specifications section.

The concept of a use case falls within the Demand-Driven Open Data (DDOD) program and gives you a formalized way to identify what data you need. It’s for anyone in industry, research, media, nonprofits or other government agencies. Each request becomes a DDOD use case, so that it can be prioritized and worked on.

Use Cases also provide a wealth of insights about existing alternative datasets and tips for interpreting and manipulating data for specific purposes.

PURPOSE

Drug manufacturers and distributions submit documentation about their products to FDA in Structured Product Labeling (SPL) that is available via openFDA. However, the approved labeling is a "living document" that is updated over time to reflect increased knowledge about the safety and effectiveness of the drug. The real-time nature of the labeling information makes it difficult to track the historical changes to a product's label and indications.

VALUE

The historical context of a product's label and indications is important in understanding how and why product labeling changes and in evaluating pharmaceutical market access.

USE CASE SPECIFICATIONS & SOLUTION

Information about this use cases is maintained in a wiki: http://hhs.ddod.us/wiki/Use_Case_25:_History_for_structured_product_labels

It serves as a knowledge base.

USE CASE DISCUSSION FORUM

All communications between Data Users, DDOD Administrators and Data Owners are logged as discussions within GitHub issues: https://github.com/demand-driven-open-data/ddod-intake/issues/25

It aims to provide complete transparency into the process and ensure the same message gets to all participants.

CASE STATUS

Closed via DailyMed, which has XML files of historical SPLs

SUMMARY

DDOD use case to link Centers for Medicare and Medicaid Services (CMS) Open Payments dataset to a physician's National Provider Identifier (NPI).

WHAT IS A USE CASE?

A “Use Case” is a request that was made by the user community because there were no available datasets that met their particular needs. If this use case is similar to your needs, we ask that you add your own requirements to the specifications section.

The concept of a use case falls within the Demand-Driven Open Data (DDOD) program and gives you a formalized way to identify what data you need. It’s for anyone in industry, research, media, nonprofits or other government agencies. Each request becomes a DDOD use case, so that it can be prioritized and worked on.

Use Cases also provide a wealth of insights about existing alternative datasets and tips for interpreting and manipulating data for specific purposes.

PURPOSE

Linking the Open Payments dataset to NPI would allow for matching to other datasets which use NPI.

VALUE

A common physician identifier across all datasets would allow for provider cost and quality analytics across datasets.

USE CASE SPECIFICATIONS & SOLUTION

Information about this use cases is maintained in a wiki: http://hhs.ddod.us/wiki/Use_Case_29:_Link_Open_Payments_dataset_to_NPI

It serves as a knowledge base.

USE CASE DISCUSSION FORUM

All communications between Data Users, DDOD Administrators and Data Owners are logged as discussions within GitHub issues: https://github.com/demand-driven-open-data/ddod-intake/issues/29

It aims to provide complete transparency into the process and ensure the same message gets to all participants.

CASE STATUS

Closed, as the legislation that made Open Payments possible explicitly forbids reporting of the NPI.