CMS Interoperability and Patient Access final rule

Just Announced:

The Interoperability and Patient Access final rule includes policies that impact a variety of stakeholders. Recognizing that hospitals, including psychiatric hospitals, and critical access hospitals, are on the front lines of the COVID-19 public health emergency, CMS is extending the implementation timeline for the admission, discharge, and transfer (ADT) notification Conditions of Participation (CoPs) by an additional six months. In the version of the rule displayed on March 9, 2020 on the CMS website, it stated these CoPs would be effective 6 months after the publication of the final rule in the Federal Register. We have changed this in the final rule now displayed on the Federal Register to state that the new CoPs at 42 CFR Parts 482 and 485 will now be effective 12 months after the final rule is published in the Federal Register.

CMS also finalized the Patient Access API and Provider Directory API policies for Medicare Advantage (MA), Medicaid, and the Children’s Health Insurance Program (CHIP) effective January 1, 2021. CMS will exercise enforcement discretion for a period of six months in connection with these two API provisions. Therefore, as a result of COVID-19, and to provide additional flexibility to payers, CMS will not enforce the new requirements under 42 CFR Parts 422, 431, 438, and 457 until July 1, 2021.

Finally, CMS finalized the Patient Access API for Qualified Health Plan (QHP) issuers on the individual market Federally-Facilitated Exchanges (FFEs) beginning with plan years beginning on or after January 1, 2021.  CMS will not enforce the new requirements under 45 CFR Part 156 until July 1, 2021. 

Other policies contained in the final rule will be implemented and enforced on schedule.

Applicability of Administrative Procedure Act:

Due to the public health emergency posed by COVID-19, CMS is exercising the enforcement discretion that is described above to adopt a temporary policy of relaxed enforcement in connection to implementation of the Interoperability and Patient Access final rule. We believe that the announcement of the exercise of enforcement discretion is a statement of agency policy not subject to the notice and comment requirements of the Administrative Procedure Act (APA).  5 U.S.C. § 553(b)(A).  For the same reasons explained above, CMS finds that even if this announcement of the exercise of enforcement discretion were subject to the public participation provisions of the APA, prior notice and comment would be impracticable and/or contrary to the public interest, and there would therefore be good cause to issue this statement of enforcement discretion without prior public comment and without a delayed effective date.  5 U.S.C. § 553(b)(B) & (d)(3).

Questions? E-mail the CMS Health Informatics and Interoperability Group (HIIG) (previously known as the Health Informatics Office): (CMSHealthInformaticsOffice@cms.hhs.gov).

Overview:

The Interoperability and Patient Access final rule (CMS-9115-F) delivers on the Administration’s promise to put patients first, giving them access to their health information when they need it most and in a way they can best use it. As part of the Trump Administration’s MyHealthEData initiative, this final rule is focused on driving interoperability and patient access to health information by liberating patient data using CMS authority to regulate Medicare Advantage (MA), Medicaid, CHIP, and Qualified Health Plan (QHP) 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:

  • Patient Access API (applicable January 1, 2021)
  • Provider Directory API (applicable January 1, 2021)
  • Payer-to-Payer Data Exchange (applicable January 1, 2022)
  • Improving the Dually Eligible Experience by Increasing the Frequency of Federal-State Data Exchanges (applicable April 1, 2022)
  • Public Reporting and Information Blocking (applicable late 2020)
  • Digital Contact Information (applicable late 2020)
  • Admission, Discharge, and Transfer Event Notifications (applicable spring 2021)

Read the Fact Sheet to learn more about these new policies.

To view the CMS Interoperability and Patient Access final rule (CMS-9115-F) in the Federal Register, visit https://www.federalregister.gov/.

To view the ONC 21st Century Cures Act final rule, visit https://www.healthit.gov/curesrule.

For Payers & Developers:

In this section you can find:

  • Information and tools to help implement the Patient Access API and Provider Directory API
  • Best Practices for payers and developers sharing and receiving patient data via FHIR-based APIs
  • Information to support payers as they produce patient education resources tailored to their patient population

Information & Tools

The CMS Interoperability and Patient Access final rule requires CMS-regulated payers – specifically, Medicare Advantage (MA) organizations, Medicaid Fee-For-Service (FFS) programs, CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs), excluding issuers offering only stand-alone dental plans (SADPs) or Federally-facilitated Small Business Health Options Program (SHOP) plans  - 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 as well as 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 if they choose to use them. Use of these implementation guides is not mandatory; however, if payers do choose to use this publicly available guidance, it will limit burden and support consistent, interoperable API development and implementation.

Technical standards:

HHS has finalized technical standards in the ONC’s 21st Century Cures Act final rule for payers and developers to use, including:

FHIR

Health Level 7 (HL7) Version 4.0.1 Fast Healthcare Interoperability Resources (FHIR) Specificatifreadon Release 4, October 30, 2019

FHIR Release 4.0.1 provides the first set of normative FHIR resources. This normative designation means that the future changes will be backward compatible. These resources define the content and structure of core health data, which can be used by developers to build standardized applications.

SMART IG / OAuth 2.0

SMART Application Launch Framework Implementation Guide Release 1.0.0, November 13, 2018

SMART on FHIR provides reliable, secure authorization for a variety of app architectures through the use of the OAuth 2.0 standard. This Authorization Guide supports the four use cases defined for Phase 1 of the Argonaut Project. This profile is intended to be used by app developers that need to access FHIR resources by requesting access tokens from OAuth 2.0 compliant authorization servers. The profile defines a method through which an app requests authorization to access a FHIR resource, and then uses that authorization to retrieve the resource.

OpenID Connect

OpenID Connect Core 1.0 Incorporating Errata Set 1, November 8. 2014

URL: http://openid.net/specs/openid-connect-core-1_0.html

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables clients to verify the identity of the end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. This specification defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of claims to communicate information about the end-user. It also describes the security and privacy considerations for using OpenID Connect.

Content & Vocabulary Standards:

HHS has also finalized content and vocabulary standards in the ONC’s 21st Century Cures Act final rule for payers and developers to use, including:

USCDI

United States Core Data for Interoperability (USCDI), February 2020, Version 1 (v1)

The USCDI is a standardized set of health data classes and component data elements for nationwide, interoperable health information exchange. CMS has required that payers share the USCDI data they maintain with patients via the Patient Access API, and with other payers via the Payer-to-Payer Data Exchange.

Implementation Guidance:

We are providing links to specific implementations guides (IG) and other resources for both the Patient Access API and the Provider Directory API that provide valuable guidance to further support sharing the needed data using the required standards. Use of these implementation guides is not required, but if used these guides will provide information payers can use to meet the requirements of the policies being finalized in this rule without having to develop an approach independently, saving time and resources. And, the reference implementations allow payers to see the APIs in action and support testing and development.

Claims & Encounter Data

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)

Additional resources for the CARIN Blue Button IG:

Clinical Data

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® Da Vinci Payer Data Exchange IG (currently in STU1 ballot) and the HL7 FHIR® US Core IG STU 3.1.0. Either of these IGs is sufficient to satisfy the data requirements of the Patient Access API. The Payer Data Exchange IG is based on the US Core IG, with the following additions designed for payer-related use cases:

  • A MedicationDispense resource has been added to record a member’s prescription drug claims
  • A Device resource has been added to broaden support for devices that are not implantable
  • A payer-specific Provenance resource has been added
  • A Coverage resource has been added that defines the constraints for representing the subscriber information to the Payer. This along with the patient’s first name, last name, date of birth and gender allows the payer to identify the member in their system for which the most responsible physician (MRP) was the performer
  • Additional information to review:

Payer Data Exchange (PDex) IG:

US Core IG:

Additional resources for the US Core IG:

Plan Coverage and Formularies

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:

Provider Directory

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:

Best Practices for Payers and App Developers

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.

Best Practices for Payers and App Developers (PDF)

Patient Privacy and Security Resources – Supporting Payers Educating their Patients

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.

Patient Privacy and Security Resources (PDF)

Questions? E-mail the CMS Health Informatics and Interoperability Group (HIIG) (previously known as the Health Informatics Office): (CMSHealthInformaticsOffice@cms.hhs.gov).

Page Last Modified:
07/17/2020 11:03 AM