The Interoperability and Patient Access Proposed Rule outlines opportunities to make patient data more useful and transferable through open, secure, standardized, and machine-readable formats while reducing restrictive burdens on healthcare providers. A core policy principle we aim to support across all proposals in this proposed rule is that every American should be able, without special effort or advanced technical skills, to see, obtain, and use all electronically available information that is relevant to their health, care, and choices—of plans, providers, and specific treatment options. This includes two types of information: Information specifically about the individual that requires appropriate diligence to protect the individual’s privacy, such as their current and past medical conditions and care received, as well as information that is of general interest and should be widely available, such as plan provider networks, the plan’s formulary, and coverage policies. You can read the proposed rule here.
- View a summary of the proposed rule
- View a diagram showing the journey that CMS presented at HIMSS 2019
Patient Access Through APIs
The MyHealthEData initiative empowers patients by ensuring access and use of their healthcare data while keeping it safe and secure. Having timely electronic access to health information makes it easier for people to make more informed decisions about their healthcare needs.
Last year, we launched the Blue Button 2.0 application programming interface (API) in Medicare fee-for-service (FFS), allowing beneficiaries to access their health claims information electronically through the application of their choosing. CMS currently has over 1,800 application developers building tools with this API. Because health information is useful to patients, and we are interested in providing individuals with access to their health information, similar to CMS’ approach to Blue Button 2.0, in the proposed rule, we are proposing to require Medicare Advantage (MA) organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs to implement, test, and monitor an openly-published Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®)-based APIs to make patient claims and other health information available to patients through third-party applications and developers. You can checkout the FHIR Implementation Guide used by Blue Button 2.0 and learn more about the Explanation of Benefits FHIR resource here.
The Carin Alliance in collaboration with CMS and private payers have been working on the CARIN Blue Button Framework and Common Payer Consumer Data Set (CPCDS). This effort builds upon the initial Blue Button 2.0 Implementation Guide work to deliver a standard for the industry.
The Da Vinci project in collaboration with CMS and private payers have also been working on a FHIR Implementation Guide and Reference Implementation for Plan Coverage and Formularies.
The Reference Implementation for the draft Plan Coverage and Formularies Implementation Guide can be found here:
- Server Reference Implementation
- Client Reference Implementation demo
- Client Reference Implementation source code
Health plan provider directories help patients find in-network providers and allow healthcare professionals to locate other providers for access to medical records, referrals, transitions of care, and care coordination. To ensure patients and providers have easy access to this information, in the proposed rule, we are proposing to require MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to make their provider networks available to enrollees and prospective enrollees through API technology. APIs ensure that up to date information for all providers is available for use by developers building tools to support beneficiaries. Because QHP issuers on the Federally Funded Exchanges are already required to make provider directory information available in a specified, machine-readable format, we are not proposing these requirements for QHP issuers at this time.
You can view the continuous build for the Validated Healthcare Directory Implementation Guide here.