From policy to platform: Your end-to-end architecture guide for CMS-0057-F

The Prior Authorization API is a cornerstone of the CMS-0057-F final rule, designed to fundamentally re-engineer and streamline one of the most burdensome administrative processes in healthcare. Its primary goal is to move the prior authorization process from a manual, often paper-based system involving faxes and phone calls to an integrated, electronic workflow embedded within a provider’s own systems.

The rule mandates that impacted payers—which include Medicare Advantage organizations, state Medicaid and CHIP programs (both FFS and managed care), and QHP issuers on the FFEs—must implement and maintain this API.

Methods: Da Vinci prior authorization support process

Da Vinci prior authorization support process flowchart

1. Core Purpose and Functionality

The Prior Authorization API is not a single, monolithic tool but a set of automated capabilities that, together, create a seamless electronic prior authorization process. It is designed to allow a provider’s electronic health record (EHR) or practice management system to “talk” directly to a payer’s system in real-time. This final rule changes the name of the API from the proposed “PARDD API” (Prior Authorization Requirements, Documentation, and Decision API) to the simpler “Prior Authorization API” to better reflect its comprehensive purpose.

The API must support the following key functions:
Determine if a Prior Authorization is Required	A provider can electronically query the payer’s system to check if a specific item or service requires prior authorization for a particular patient. This eliminates the guesswork and time-consuming manual research providers currently undertake.
Identify Documentation Requirements	The API must be able to specify exactly what clinical documentation and information the payer requires to approve the prior authorization request. This transparency is intended to reduce the number of initial denials that occur simply because of missing or incorrect paperwork.
Facilitate the Request and Response	The API must support a HIPAA-compliant electronic prior authorization request sent directly from the provider’s system. It must then communicate the payer’s decision back to the provider. The decision must clearly state whether the request is: Approved, including the date or circumstances under which the authorization ends. Denied, providing a specific, detailed reason for the denial. A request for more information.

The API must support the following key functions:

Determine if a Prior Authorization is Required

A provider can electronically query the payer’s system to check if a specific item or service requires prior authorization for a particular patient. This eliminates the guesswork and time-consuming manual research providers currently undertake.

Identify Documentation Requirements

The API must be able to specify exactly what clinical documentation and information the payer requires to approve the prior authorization request. This transparency is intended to reduce the number of initial denials that occur simply because of missing or incorrect paperwork.

Facilitate the Request and Response

The API must support a HIPAA-compliant electronic prior authorization request sent directly from the provider’s system. It must then communicate the payer’s decision back to the provider. The decision must clearly state whether the request is:

Approved, including the date or circumstances under which the authorization ends.
Denied, providing a specific, detailed reason for the denial.
A request for more information.

Technical Standards and Implementation Guides (IGs)

To ensure interoperability and a consistent experience across different payers and providers, CMS requires the API to be built on specific technical standards. However, it recommends, rather than mandates, a set of detailed Implementation Guides (IGs) that provide the “how-to” for building these functionalities.

Required Standards
The rule mandates that the Prior Authorization API be conformant with several standards adopted by the Office of the National Coordinator for Health Information Technology (ONC), including:
HL7® FHIR® (Fast Healthcare Interoperability Resources) Release 4.0.1	The foundational data standard for exchanging healthcare information electronically.
HL7 FHIR US Core Implementation Guide (IG) STU 3.1.1	Specifies how to use FHIR to represent common U.S. healthcare data.
HL7 SMART Application Launch Framework IG Release 1.0.0	A security standard that allows third-party applications (like a provider’s EHR) to securely connect to a server (like a payer’s API).

Recommended Implementation Guides (IGs)
CMS strongly recommends that payers use three specific HL7 Da Vinci Project IGs, which are designed to work together to create the end-to-end prior authorization workflow:
Coverage Requirements Discovery (CRD) IG	This guide powers the first step—allowing a provider’s system to ask the payer’s API, “Does this service for this patient need a prior authorization?” and “What are the rules?” The API can use this IG to provide decision support directly within the provider’s workflow at the moment a service is being ordered.
Documentation Templates and Rules (DTR) IG	If a prior authorization is needed, this IG enables the API to provide the provider’s system with electronic, fillable forms or “questionnaires.” The provider’s EHR can then automatically populate these forms with the required clinical data from the patient’s record, replacing the need to manually gather and submit documents.
Prior Authorization Support (PAS) IG	AThis is the final step in the process. The PAS IG enables the provider’s system to assemble the information from the CRD and DTR IGs and transmit the complete prior authorization request to the payer. Crucially, it also handles the return communication of the payer’s decision (approve, deny, or request more information) back to the provider’s system. The PAS IG defines capabilities for managing requests, including checking the status, revising a request, or canceling one.

It is important to note that while these IGs are highly recommended for standardization, the rule provides flexibility, acknowledging that the standards are continuously evolving.

Compliance Timeline and Provider Adoption
Payer Compliance	Impacted payers are required to implement and maintain their Prior Authorization API by January 1, 2027 (or the rating/plan year beginning on or after that date for managed care and QHP issuers).
Provider Adoption	The rule does not mandate that providers use the API. However, to incentivize adoption, CMS is adding a new “Electronic Prior Authorization” measure to the Merit-based Incentive Payment System (MIPS) and the Medicare Promoting Interoperability Program. Beginning in 2027, eligible clinicians and hospitals will be required to attest to whether they have used an API to submit at least one prior authorization request.

Compliance Timeline and Provider Adoption

Payer Compliance

Impacted payers are required to implement and maintain their Prior Authorization API by January 1, 2027 (or the rating/plan year beginning on or after that date for managed care and QHP issuers).

Provider Adoption

The rule does not mandate that providers use the API. However, to incentivize adoption, CMS is adding a new “Electronic Prior Authorization” measure to the Merit-based Incentive Payment System (MIPS) and the Medicare Promoting Interoperability Program. Beginning in 2027, eligible clinicians and hospitals will be required to attest to whether they have used an API to submit at least one prior authorization request.

Key Resources & Official Documentation
Your technical team must use the official specifications as the source of truth.
HL7 Da Vinci Project IGs	https://confluence.hl7.org/display/DVP/Da+Vinci+Implementation+Guides CRD IG: https://build.fhir.org/ig/HL7/davinci-crd/ DTR IG: https://build.fhir.org/ig/HL7/davinci-dtr/ PAS IG: https://build.fhir.org/ig/HL7/davinci-pas/
ONC Standards Regulations	https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170
HL7 FHIR R4 Specification	https://www.hl7.org/fhir/R4/

2. Required New Components & Capabilities

To deliver the full end-to-end workflow, CareEvolution^® may need to develop the following new, modular components that integrate seamlessly with our core platform.

CRD (Coverage Requirements Discovery) Service
What it is	A new microservice that functions as an HL7 CDS Hooks server.
How it works	It will expose an order-select endpoint that provider EHRs can call. Upon receiving a request, it will query (CE/payer) Rules Engine to determine if a prior authorization is needed and construct the appropriate CDS “Card” response, including the link to launch the DTR application.

Rules Engine & Digitization Module
What it is	This is the “brain” of the operation and the most critical new component. It is a sophisticated engine that executes machine-readable clinical policies.
How it works	This module will have two parts: A Configuration & Translation UI: A portal for payers to translate their existing, often text-based, clinical policy documents into structured, executable rules. This is the “rules digitization” process. An Execution Engine: The CRD and PAS services will call this engine to evaluate a given request against the digitized ruleset to determine necessity and medical appropriateness.

Rules Engine & Digitization Module

What it is

This is the “brain” of the operation and the most critical new component. It is a sophisticated engine that executes machine-readable clinical policies.

How it works

This module will have two parts:

A Configuration & Translation UI: A portal for payers to translate their existing, often text-based, clinical policy documents into structured, executable rules. This is the “rules digitization” process.
An Execution Engine: The CRD and PAS services will call this engine to evaluate a given request against the digitized ruleset to determine necessity and medical appropriateness.

DTR (Documentation Templates & Rules) SMART App
What it is	A web-based SMART on FHIR application, launched from the provider’s EHR.
How it works	When launched, the app will retrieve the appropriate FHIR Questionnaire from our FHIR server. It will then securely query the provider’s own EHR FHIR endpoint to pre-populate answers with available data (e.g., patient demographics, diagnoses, lab results). The final, completed QuestionnaireResponse is a key output.
How patients benefit	Enables safer, faster, and more personalized care. Provides real-time, standardized health data to support accurate and timely clinical decisions, reducing errors and improving outcomes. Supports personalized treatment recommendations and visual tools that help patients better understand their health, leading to greater engagement. Ensures continuity of care across different systems while protecting patient privacy.

PAS (Prior Authorization Support) Adjudication Workflow
What it is	An extension of our FHIR Server’s capabilities, implementing the $submit operation on the Claim resource.
How it works	This service will receive the PAS Bundle containing the preauthorization Claim and all supporting evidence (like the QuestionnaireResponse). It will then trigger an internal adjudication workflow that uses the Rules Engine and the aggregated patient data we have available to make an automated decision (Approve/Deny/Pend). It will then generate the corresponding ClaimResponse with a specific denial reason, if applicable.

PAS (Prior Authorization Support) Adjudication Workflow

What it is

An extension of our FHIR Server’s capabilities, implementing the $submit operation on the Claim resource.

How it works

This service will receive the PAS Bundle containing the preauthorization Claim and all supporting evidence (like the QuestionnaireResponse). It will then trigger an internal adjudication workflow that uses the Rules Engine and the aggregated patient data we have available to make an automated decision (Approve/Deny/Pend). It will then generate the corresponding ClaimResponse with a specific denial reason, if applicable.

3. Data Sources, Types, and Architectural Flow

The data flow is designed to be seamless, moving from the point of care to the payer’s decision-making process and back.

Data Sources
Payer Systems	Clinical policy documents, fee schedules, and member eligibility files.
Provider EHRs	The direct source of the CRD query context (patient, encounter, order) and the source for pre-populating DTR questionnaires.
CareEvolution’s Data Repository	A rich source of aggregated clinical and claims data used to augment the adjudication process.

Data Types
FHIR Resources	The entire process is orchestrated using FHIR R4 resources, including `ServiceRequest, Patient, Questionnaire, QuestionnaireResponse, Claim,` and `ClaimResponse`.
CDS Hooks	The specific JSON structure for CRD request/response “cards.”
X12 278	The system will have the capability to map the FHIR PAS submission to an X12 278 transaction for systems that require it.

Architectural Flow Explained

Architectural Flow Explained
A provider initiates an order in the EHR, which triggers a CRD request to our API Gateway. The CRD Service uses the Rules Engine to determine if a PA is required based on the payer’s digitized policies. A CDS Hooks Card is returned to the EHR, indicating the result and providing a SMART on FHIR link if PA is needed. The user clicks the link, launching the DTR SMART App. The DTR app retrieves the appropriate `Questionnaire` from our FHIR Server and helps the user complete it by pre-populating data from the provider’s EHR. The completed `QuestionnaireResponse` and other evidence are bundled and submitted to the PAS Service endpoint. The PAS service uses the Rules Engine and queries the rich Aggregated Patient Data from the clinical data platform to adjudicate the request automatically. A final `ClaimResponse` (Approved/Denied with specific reasons) is generated and returned to the provider’s system.

A provider initiates an order in the EHR, which triggers a CRD request to our API Gateway.
The CRD Service uses the Rules Engine to determine if a PA is required based on the payer’s digitized policies.
A CDS Hooks Card is returned to the EHR, indicating the result and providing a SMART on FHIR link if PA is needed.
The user clicks the link, launching the DTR SMART App.
The DTR app retrieves the appropriate Questionnaire from our FHIR Server and helps the user complete it by pre-populating data from the provider’s EHR.
The completed QuestionnaireResponse and other evidence are bundled and submitted to the PAS Service endpoint.
The PAS service uses the Rules Engine and queries the rich Aggregated Patient Data from the clinical data platform to adjudicate the request automatically.
A final ClaimResponse (Approved/Denied with specific reasons) is generated and returned to the provider’s system.

Conclusion

The central takeaway from the CMS-0057-F final rule is that the healthcare industry must prepare for a fundamental, technology-driven transformation of the prior authorization process. By January 1, 2027, impacted payers are mandated to implement FHIR-based APIs to automate and streamline these workflows, making the shift from manual, burdensome tasks to an integrated, electronic system an impending reality. This requires proactive preparation from all stakeholders: payers must begin the complex work of digitizing their clinical policies into executable rules, while providers should assess their EHR capabilities and plan for adoption to capitalize on reduced administrative burdens and new MIPS incentives. For a successful transition, organizations can leverage comprehensive, end-to-end solutions, such as the modular platform being developed by CareEvolution, to meet the rule’s complex requirements and unlock the benefits of a more efficient, transparent, and collaborative healthcare ecosystem.