Prior Authorization APIs Due January 2027: What Healthtech Vendors Should Build Now

Prior authorization is one of the most expensive pieces of paperwork in American healthcare, and federal rules are about to turn much of it into APIs. The CMS Interoperability and Prior Authorization final rule, CMS-0057-F, requires impacted payers, including Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the federally facilitated exchanges, to implement several HL7 FHIR APIs. CMS says the API compliance dates generally begin January 1, 2027, with exact dates varying by payer type. The standards behind those APIs were also just refreshed. ONC, on behalf of HHS, finalized updated implementation guides in the FY 2027 IPPS final rule, replacing previously adopted versions as of the rule's effective date, October 1, 2026. If you build software for payers, providers, or patients, the next twelve months will reward teams that are ready.

The four APIs in plain terms

Prior Authorization API. Populated with the payer's covered items and services, it identifies documentation requirements, supports a prior authorization request and response, and communicates approval with an end date or circumstance, denial with a specific reason, or a request for more information. Provider Access API. Shares claims and encounter data, USCDI data, and specified prior authorization information with in-network providers who have a treatment relationship with the patient, with patient opt-out. Payer-to-Payer API. Moves the same classes of data, for dates of service within five years, when a patient changes payers, with patient opt-in. Patient Access API enhancements. Adds prior authorization information, excluding drugs, to the data patients can already access.

The standards you will build against

ONC's fact sheet lists the implementation guides finalized in the FY 2027 IPPS rule, including Da Vinci Coverage Requirements Discovery 2.2.1, Documentation Templates and Rules 2.2.0, Prior Authorization Support 2.2.1, CARIN IG for Blue Button 2.2.0, PDex US Drug Formulary 2.1.0, PDex Plan Net 1.2.0, and Clinical Data Exchange 2.1.0. Earlier versions adopted in HTI-4 were replaced on October 1, 2026. If your roadmap was built on older versions, re-check conformance now.

Prior auth flow (Da Vinci) for a provider-side app
CRD   order-sign hook: is PA required? what docs?
DTR   questionnaire: pre-filled from EHR, clinician completes
PAS   submit request; receive approve / deny+reason / pend
CDex  payer asks for more clinical data
Standards finalized in FY2027 IPPS rule, effective 2026-10-01

Where startups fit

Payers will build or buy the APIs. Around them, there is room for products that make the data useful. Provider-side tools can surface coverage requirements at the moment of ordering, pre-fill documentation from the chart, and track request status without fax or phone. Patient apps can explain pending and denied authorizations in plain language using data from the Patient Access API. Vendors serving smaller payers can offer compliant API layers, attribution services, and opt-in or opt-out management. Each of these needs solid FHIR engineering, not a thin wrapper.

Don't forget the operational rules

Some provisions already apply. Since January 1, 2026, impacted payers other than QHP issuers on the exchanges must send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests, must give a specific reason for denials regardless of channel, and must publicly report prior authorization metrics, with the first set due by March 31, 2026. Products that help payers meet and prove those timelines, or help providers see them, solve a problem customers already have. On the provider side, CMS added an Electronic Prior Authorization measure for MIPS eligible clinicians and for eligible hospitals and critical access hospitals, starting with calendar year 2027 reporting. That gives provider organizations a direct reason to adopt API-based prior authorization next year.

Engineering lessons for healthtech teams

Treat conformance as a product feature. Test against the published implementation guides and reference implementations, and plan for differences between payers, because real implementations vary. Design for authorization and consent from day one: SMART on FHIR scopes, patient opt-in and opt-out state, and attribution of patients to providers are core logic, not edge cases. Keep audit logs that show who accessed which data and why. CMS also notes HIPAA enforcement discretion for FHIR-only prior authorization APIs that do not use the X12 278 standard, so be explicit with customers about which transaction path you support.

Watch what is still proposed

ONC notes that the updated standards were originally proposed in the 2026 CMS Interoperability Standards and Prior Authorization for Drugs proposed rule, CMS-0062-P, and that they are referenced in proposed payer API requirements there. CMS-0057-F excludes drugs from its prior authorization provisions, so drug prior authorization is a separate track to follow. Build on what is final today, design your data model so drug workflows can be added later, and avoid promising customers compliance with requirements that have not been finalized.

Plan for testing with real partners

Conformance testing against implementation guides is necessary but not sufficient. Every payer and EHR will have its own quirks, from authentication setup to which optional elements they populate. Line up pilot partners early, budget time for onboarding each one, and build monitoring that tells you when a partner's API behavior changes. Integration reliability, not feature count, is what customers will judge in 2027.

Founder takeaway

January 1, 2027 is close for payers, and October 1, 2026 already changed the standards. If you build for this market, update your conformance to the newly adopted Da Vinci and CARIN versions, pick one workflow where you can remove real friction, such as coverage discovery at order time or status tracking, and design consent, attribution, and audit into the core. The vendors who are boringly reliable on FHIR will win the next year of buying decisions.