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:
Important
Firely Server supports all mandatory requirements out-of-the-box. The following implementation guides build the foundation of the APIs mentioned below.
API |
FHIR v4.0.1 |
|||
|---|---|---|---|---|
Patient Access API |
☑️ |
☑️ |
☑️ |
Not applicable |
Provider Access API |
☑️ |
☑️ |
☑️ |
☑️ |
Provider Directory API |
☑️ |
☑️ |
☑️ |
Not applicable |
Payor-to-Payor API |
☑️ |
☑️ |
☑️ |
☑️ |
Prior Authorization API |
☑️ |
☑️ |
☑️ |
Not applicable |
Note
There are additional Implementation Guides strongly recommended by CMS. We provide guidance on how to implement these Implementation Guides with Firely Server in the sections below.
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 |
☑️ |
☑️ |
Not applicable |
☑️ |
Not applicable |
SMART App Launch IG Release 2.0.0 support Backend Services |
Not applicable |
☑️ |
Not applicable |
☑️ |
Not applicable |
Da Vinci Payer Data Exchange (PDex) IG Version STU 2.0.0 |
☑️ |
☑️ |
Not applicable |
☑️ |
Not applicable |
Da Vinci PDex US Drug Formulary IG Version STU 2.0.1 |
☑️ |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
Da Vinci PDex Plan-Net IG Version STU 1.1.0 |
Not applicable |
Not applicable |
☑️ |
Not applicable |
Not applicable |
Da Vinci Coverage Requirements Discovery (CRD) IG Version STU 2.0.1 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
☑️ |
Da Vinci Documentation Templates and Rules (DTR) IG Version STU 2.0.0 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
☑️ |
Da Vinci Prior Authorization Support (PAS) IG Version STU 2.0.1 |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
☑️ |
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 Payer Data Exchange)
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:
Enable SMART on FHIR and point Firely Server to an authorization server managing the accounts of the patients. See Introduction Access control.
Expose the Patient record with all its USCDI, CPCDS, and prior authorization data elements
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.
Additionally, CMS requires to collect metrics on the usage of Patient Access API. See section I.C Patient Access API Metrics of the final rule. The API usage can be derived from AuditEvents generated by Firely Server.
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:
Enable SMART on FHIR and point Firely Server to an authorization server managing the accounts of the providers. See Introduction Access control.
Expose the Patient records with all its USCDI, CPCDS, and prior authorization data elements
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.
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.
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:
Deploy an instance of Firely Server without security measures.
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.