CMS Advancing Interoperability and Improving Prior Authorization Processes (CMS-0057-P) - 🇺🇸

The proposed CMS Interoperability Rule (CMS-0057-P) aims to promote greater interoperability, patient access, and innovation in the healthcare industry while also improving the quality and cost-effectiveness of care. Technically these goals are supported by multiple APIs that are required to be provided:

Firely Server aims to support all mandatory requirements out-of-the-box. The following implementation guides build the foundation of the APIs mentioned above.

Firely Server Compliance CMS Interoperability Mandatory IGs

API	FHIR v4.0.1	USCDI & US Core	SMART App Launch	Bulk Data Access
Patient Access API	✅	✅	✅	Not needed
Provider Access API	✅	✅	✅	✅
Provider Directory API	✅	✅	✅	Not needed
Payor-to-Payor API	✅	✅	✅	✅
PARDD API	✅	✅	✅	Not needed

Note

There are additional Implementation Guides strongly recommended by CMS. Not all of them are currently supported by Firely Server.

Patient Access API

Impacted payers (see CMS definition) are required to make claims, encounter and clinical data, including laboratory results available through the Patient Access API. The goal is to make as much data available to patients as possible through the API to ensure patients have access to their data in a way that will be most valuable and meaningful to them. The following information should be provided via Patient Access API using the corresponding implementation guides:

• Claim details and encounters (see CPCDS & CARIN Blue Button)

• Clinical data incl. laboratory data (see USCDI & US Core and Da Vinci Payer Data Exchange)

• Plan Coverage and Formularies (US Drug Formulary)

• Prior Authorization Decisions (Da Vinci Prior Authorization Support)

Note

The Da Vinci Payer Data Exchange Implementation Guide and the CARIN Blue Button Implementation Guide both use the ExplanationOfBenefits. The main difference in usage is that the CARIN profiles make information available about a final claim, whereas PDex aims for sharing prior authorization information. Additional details about the prior authorization decisions can be exposed via the PAS profiles.

To implement a Patient Access API it is necessary to:

1. Enable SMART on FHIR and point Firely Server to an authorization server managing the accounts of the patients - See Access control and SMART on FHIR

2. Expose the Patient record with all its USCDI, CPCDS, and prior authorization data elements

3. Configure the API clients to be allowed to be granted access (read-only) to resources on behalf of the patient - See Configuration of API clients in Firely Auth