CMS recently introduced new interoperability mandates for health plans that must be implemented by July 1, 2021. This rule is designed to make health information more easily available to patients by implementing new industry standards like HL7 FHIR APIs and by deterring information blocking.
As part of the Trump Administration’s MyHealthEData initiative, the Interoperability and Patient Access final rule (CMS-9115-F) is focused on driving interoperability and patient access to health information by liberating patient data using CMS authority to regulate certain health plan issuers on the Federally-facilitated Exchanges (FFEs).
This rule finalizes new policies that give patients access to their health information and moves the healthcare system toward greater interoperability. These new policies include:
Below are a summary of the following topics:
The CMS Interoperability and Patient Access final rule requires CMS-regulated payers to implement and maintain a secure, standards-based Patient Access API (using Health Level 7® (HL7) Fast Healthcare Interoperability Resources® (FHIR) 4.0.1) that allows patients to easily access their claims and encounter information, including cost, as well as a defined sub-set of their clinical information through third-party applications of their choice. This rule also requires MA organizations, Medicaid FFS programs, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to make provider directory information publicly available via a FHIR-based Provider Directory API.
HHS finalized technical and content and vocabulary standards in the ONC 21st Century Cures Act final rule, which were adopted by CMS to support these two API policies. In addition, CMS has been working with HL7 and other industry partners to ensure implementation guides and additional resources are freely available to payers to use, though not mandatory
HHS has finalized three technical standards in the ONC’s 21st Century Cures Act final rule for payers and developers to use and one content and vocabulary standard. These are FHIR, SMART IG/OAuth 2.0, OpenID Connect, and USCDI , respectively.
Below are links to implementation guides for both the Patient Access API and the Patient Directory API that provide valuable guidance to further support sharing the needed data using the required standards. The use of these guides is not mandatory, but using these guides can help payers save both time and resources.
Payers are required to make a patient’s claims and encounter data available via the Patient Access API. To facilitate this, we link to the *CARIN Alliance Blue Button® Framework and Common Payer Consumer Data Set (CPCDS) IG* (Currently in Development)
Payers are also required to make a patient’s clinical data, defined as those data the payer maintains that are included in the USCDI version 1, available via the Patient Access API. To facilitate this, we link to the HL7 FHIR® US Core IG STU 3.1.0.
There are several open source reference implementations and libraries supporting FHIR US Core. HL7 maintains the following list:
Part D Medicare Advantage plans must also make formulary information available via the Patient Access API. And, Medicaid and CHIP FFS and managed care must make preferred drug lists available. To facilitate this, we link to the DaVinci Payer Data Exchange US Drug Formulary IG.
Additional Plan Coverage and Formularies resources:
Under this rule, MA organizations, Medicaid FFS programs, CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities are required to make provider directory information available via the Provider Directory API. This API must be accessible via a public-facing digital endpoint on the payer’s website. To facilitate this, we link to the DaVinci PDEX Plan Net IG.
Additional Provider Directory resources:
This document includes links to useful information and best practices to help payers and developers build and maintain a FHIR-based API, as well as best practices for third-party app developers.
This document provides an overview of what is required to be included in a payer’s patient resource document and some content payers may choose to use to help meet this requirement. Use of this document is not required; this is meant to support payers as they produce patient resources tailored to their patient population.