Key Takeaways
- The CMS-0057-F timeline is staggered. Operational provisions, including faster decision timeframes and specific denial reasons, took effect January 1, 2026. The HL7 FHIR-based Prior Authorization API must be operational by January 1, 2027
- The HL7 FHIR Implementation Guides developed through the Da Vinci Project are CMS’s clearly preferred path. These guides translate policy into concrete, testable HL7 FHIR workflows that health plans can implement to meet the standard.”
- The regulatory surface keeps expanding. Patient Access, Provider Access, and Payer-to-Payer APIs, plus follow-on rulemaking such as a separate proposed rule for drug prior authorization, all build on the same HL7 FHIR foundation.
- Spec conformance compounds over time. A conformant build extends more cleanly to future requirements. A minimal build creates rework that accumulates with each new rule.
The Centers for Medicare & Medicaid Services (CMS) Interoperability and Prior Authorization Final Rule (CMS-0057-F) established a clear direction for health plans: build prior authorization application programming interfaces (APIs) based on Fast Healthcare Interoperability Resources—developed by Health Level Seven® (HL7®) International and known as HL7 FHIR®—that meet the standard, or plan for repeated remediation as the regulatory surface keeps expanding.
The January 1, 2027 API deadline is a practical planning milestone, not a distant abstraction. How health plans build toward it will determine how much rework they absorb over the next several rule cycles. For health plan leaders, the question is whether they should meet minimum requirements, or fully build to spec.
What Does CMS-0057-F Require for Compliance?
CMS-0057-F is a staggered rule, and some provisions are already in effect. As of January 1, 2026, impacted health plans must meet faster prior authorization decision timeframes and provide specific denial reasons when requests are denied. The HL7 FHIR API requirements, including the Prior Authorization API, must be operational by January 1, 2027.
That means implementation work should be well underway. The question facing most technical and compliance teams right now isn’t whether to stand up an API, but what level of conformance to build toward. Minimum viable compliance feels efficient in the short term—but it rarely is.
CMS has also been explicit about which technical path it prefers. Its Implementation Guides and Standards page points directly to the Da Vinci Project implementation guides as the mechanism for meeting these requirements.
Get deeper insights and compliance recommendations in our new Guide to CMS-0057-F API Requirements.
How Does CMS-0062-P Build on to Established Standards?
CMS-0062-P, the proposed 2026 Interoperability Standards and Prior Authorization for Drugs rule, builds directly on the Da Vinci foundation established under CMS-0057-F. Where the CMS-0057-F rule strongly recommended the Da Vinci implementation guides, the CMS-0062-P proposal would mandate them —and extend their reach into territory the prior rule left untouched. Older STU 2-era versions are proposed to expire January 1, 2028.
Other key additions proposed under CMS-0062-P are:
- Drug Prior Authorization: For the first time, HL7 FHIR-based prior authorization requirements would extend to medication workflows. CMS-0057-F did not cover drugs.
- Potential HIPAA Elevation: The proposal could add Da Vinci IGs to HIPAA requirements, significantly raising the enforcement weight behind conformance obligations.
CMS-0062-P is still a proposed rule, but it signals that the regulatory floor is rising. The question for health plans is whether their current build will hold up. That distinction— between an API that technically responds and one that fully conforms to the Da Vinci IGs—is where implementation strategy becomes essential.
What Are the Da Vinci Implementation Guides and How Can They Help Support Health Plans?
The Da Vinci Project is a private-sector initiative under HL7 that brings together health plans, providers, and vendors to build standards-based HL7 FHIR workflows for value-based care.
The three implementation guides most directly relevant to CMS-0057-F prior authorization automation are:
- HL7 FHIR® Implementation Guide: Da Vinci Coverage Requirements Discovery (CRD), Version 2.2.1: Allows a provider system to query a health plan at the point of care to determine whether prior authorization is required for a specific service, reducing unnecessary requests before they’re submitted.
- HL7 FHIR® Implementation Guide: Da Vinci Documentation Templates and Rules (DTR), Version 2.2.0: Enables health plans to communicate documentation requirements in a computable format, allowing clinical systems to automatically retrieve and populate relevant patient data.
- HL7 FHIR® Implementation Guide: Da Vinci Prior Authorization Support (PAS), Version 2.2.1: Supports direct submission of prior authorization requests from provider systems to health plan systems using HL7 FHIR, with structured responses that include status, denial reasons, and approval data.
These three guides are designed to work together as an end-to-end workflow. CRD surfaces relevant coverage and documentation requirements in real time within the provider’s workflow, at the point an order is placed — flagging whether prior authorization or other requirements apply before the visit even ends. DTR retrieves the payer-specific questionnaire or template tied to that requirement and pre-populates it using data pulled from the patient’s record, rather than capturing documentation after the fact. PAS then packages the completed documentation into a structured request, submits it electronically to the payer, and returns the decision — approved, denied, or pended for more information — through the same channel.
Implemented together, they create a workflow that reduces manual touchpoints and shortens turnaround times on both sides of the transaction.
The value of building to these guides isn’t just in compliance. At HIMSS25, presenters from MultiCare Connected Care and Regence reported that a standards-based approach resolved 94% of prior authorization inquiries with an immediate response. That’s an operational outcome, not a compliance outcome.
The Case for Full Conformance
There’s a meaningful difference between an API that technically responds to prior authorization requests and an API that conforms to the Da Vinci implementation guides.
Full conformance means your implementation satisfies the capability statements, profiles, and workflow requirements defined in the IGs. Trading partners, including providers and their electronic health record (EHR) vendors, increasingly expect conformant behavior. A system that responds but doesn’t conform creates integration friction every time a new partner connects.
Minimal builds tend to address the requirement at a point in time. They don’t account for how the IGs interact with each other, how trading partner expectations will evolve, or how the next rule will extend the same HL7 FHIR foundation.
Why Do CMS Requirements Keep Expanding?
CMS-0057-F isn’t the end of the interoperability rule cycle. The Patient Access API, Provider Access API, and Payer-to-Payer API requirements are already in effect or phasing in for many plan types. A separate proposed rule addressing drug prior authorization would extend these same HL7 FHIR requirements further into pharmacy workflows.
Each of these requirements builds on the same HL7 FHIR R4 foundation and the same Da Vinci implementation guide ecosystem. A health plan that built its Patient Access API to spec will find that extending to the Prior Authorization API is a coherent engineering exercise. A health plan that took a minimal approach to each prior requirement faces a different situation: each new rule surfaces gaps that require revisiting earlier work.
This is the compounding effect in practice. Not dramatic failure, but accumulated rework that consumes engineering capacity, delays timelines, and raises the total cost of compliance over time. Conformance, by contrast, creates a foundation that absorbs new requirements with fewer interruptions.
How Health Plans Can Assess Prior Authorization Solutions
The most useful question to ask right now is whether your current or planned prior authorization build would pass full conformance testing.
Start with the capability statements, profiles, and workflow requirements defined in the Da Vinci IGs: Has your implementation been tested against real trading partner expectations, or only against internal assumptions? Do you have visibility into where gaps exist before providers surface them in production?
These questions matter because identifying gaps now costs far less than remediating a non-conformant implementation after trading partners surface integration failures — or after the next rule cycle raises the floor.
Health plans working with integrated technology partners that have already built toward Da Vinci conformance start from a position of alignment rather than remediation. Clinical Edge, formerly HealthEdge GuidingCare®, is built with Da Vinci IG conformance as a foundation, positioning health plans to absorb new requirements without revisiting earlier work.
Treating Conformance as Infrastructure
Spec conformance isn’t a compliance checkbox. It’s an infrastructure investment. A conformant build on the Da Vinci CRD, DTR, and PAS guides gives your organization a stable foundation that extends to future requirements without starting over. It also reduces integration cycles with providers and positions your plan as a capable, standards-aligned trading partner in a market where that distinction is increasingly visible.
To learn more about how HealthEdge solutions help support HL7 Da Vinci compliance, visit our data sheet: Future-Proof Your Health Plan with HealthEdge Clinical Edge — FHIR-Driven Solutions Enable Compliance.
HL7® and FHIR® are the registered trademarks of Health Level Seven International, and their use does not constitute an endorsement by HL7.
Frequently Asked Questions
What are the Da Vinci CRD, DTR, and PAS implementation guides?
These are three interrelated HL7 FHIR prior authorization implementation guides developed through the Da Vinci Project. Coverage Requirements Discovery (CRD) identifies whether authorization is required at the point of care. Documentation Templates and Rules (DTR) communicates documentation requirements in a computable format. Prior Authorization Support (PAS) enables structured prior authorization submission and response. Together, they form the end-to-end workflow CMS has identified as the preferred technical approach.
How can health plans test whether their prior authorization API is conformant?
The most practical starting point is evaluating your implementation against the capability statements, profiles, and workflow requirements defined in the Da Vinci IGs. Health plans can also work with an integrated technology partner that has already built toward conformance, reducing the burden of testing and remediation from scratch.
Which plan types are affected by the Prior Authorization API requirements?
CMS-0057-F applies to Medicare Advantage organizations, state Medicaid and CHIP managed care plans, CHIP agencies using fee-for-service delivery, and Qualified Health Plan issuers on the federally facilitated exchanges. Plans should verify their specific applicability against the final rule text on the CMS interoperability policies and regulations page.