CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) - 🇺🇸

The proposed CMS Interoperability Rule (CMS-0057-F) 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 supports all mandatory requirements out-of-the-box. The following implementation guides build the foundation of the APIs mentioned below.

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	✅	✅	✅	✅
Prior Authorization API	✅	✅	✅	Not needed

Firely Server Compliance CMS Interoperability Recommended IGs

Implementation Guide		Patient Access API	Provider Access API	Provider Directory API	Payor-to-Payor API	Prior Authorization API
CARIN for Blue Button® IG Version STU 2.0.0	☑️	✅	✅	⚪	✅	⚪
SMART App Launch IG Release 2.0.0 support Backend Services	☑️	⚪	✅	⚪	✅	⚪
Da Vinci Payer Data Exchange (PDex) IG Version STU 2.0.0		✅	✅	⚪	✅	⚪
Da Vinci PDex US Drug Formulary IG Version STU 2.0.1		✅	⚪	⚪	⚪	⚪
Da Vinci PDex Plan-Net IG Version STU 1.1.0	☑️	⚪	⚪	✅	⚪	⚪
Da Vinci Coverage Requirements Discovery (CRD) IG Version STU 2.0.1		⚪	⚪	⚪	⚪	✅
Da Vinci Documentation Templates and Rules (DTR) IG Version STU 2.0.0		⚪	⚪	⚪	⚪	✅
Da Vinci Prior Authorization Support (PAS) IG Version STU 2.0.1		⚪	⚪	⚪	⚪	✅

☑️ = fully supported in the current release of Firely Server

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 Introduction Access control.

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.

Provider Access API

Impacted payers (see CMS definition) are required to provide information exposed via a Patient Access API to providers who have a contractual relationship with the payer and a treatment relationship with the patient. Providers could access information for an individual patient as well as a group of information, providing further insight into the patient’s care activity at the point of care.

To implement a Provider Access API (Bulk) it is necessary to:

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

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

3. Maintain a member attribution lists for providers. It is necessary to account for patients who opted out of the information sharing process. See Da Vinci - Member Attribution (ATR) List.

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

5. Create access policies to restrict access to a member attribution group based on their Taxpayer Identification Numbers (TINs) and National Provider Identifiers (NPIs). See Permissions (AccessPolicy).

Provider Directory API

Impacted payers (see CMS definition) are required to provide a public-facing Provider Directory API containing data on contracted providers. The API must include provider names, addresses, phone numbers, and specialties, with updates accessible within 30 days. While CMS doesn’t specify how payers should handle API access for contracted networks, they must ensure the API is publicly accessible without requiring authentication. MA organizations offering MA-PD plans must provide pharmacy directory data, with CMS encouraging adherence to the PDex Plan-Net Implementation Guide. Developers accessing the Provider Directory API are not required to register, and its technical standards exclude authentication protocols. Payers need to ensure the API and its documentation are available through a public-facing digital endpoint on their website, with restrictions only allowed for necessary security measures.

To implement a Provider Directory API it is necessary to:

1. Deploy an instance of Firely Server without security measures.

2. Produce FHIR resources compliant with the Da Vinci PDex Plan-Net IG Version STU 1.1.0 Implementation Guide for storage in the unsecured Firely Server instance.

• Extract resources from an existing Firely Server instance and/or generate resources from other payer systems.

• Execute this resource generation process routinely and ensure updates are completed within 30 days of any modifications to the source data.