The January 1, 2027 Prior Authorization API Deadline: What Payers, and the Vendors Selling to Them, Still Have to Build

Federal rules require most Medicare Advantage, Medicaid, CHIP and exchange plans to run four new FHIR APIs by January 1, 2027. That is about seven weeks away, and the APIs are the easy part.

The problem: a hard date, and work that crosses every system

CMS's Interoperability and Prior Authorization final rule (CMS-0057-F) covers what CMS calls "impacted payers": Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and Qualified Health Plan issuers on the federal exchanges. The rule says these payers have until compliance dates "generally beginning January 1, 2027, to meet the API development and enhancement requirements," and that "the exact compliance dates vary by the type of payer" (CMS fact sheet, CMS-0057-F).

There has been no delay. CMS's own rule page, last updated in October 2026, still says payers have "until primarily January 1, 2027" (CMS rule overview page).

For a COO or CTO at a payer, a TPA or a payer-tech vendor, the hard part is not the API itself. It is everything behind it: claims systems, utilization management tools, provider directories and member records never designed to answer real-time questions from outside.

If you sell software to payers, this is your problem too. Your customers will ask whether your product feeds these APIs cleanly, and "it's on the roadmap" will not hold up in a January contract review.

What the rule actually requires

The fact sheet lists four APIs. All four must be live by January 1, 2027 (CMS fact sheet):

• •Patient Access API (expanded). Payers already run this under the 2020 rule. They must now add prior authorization information to it, excluding drugs.
• •Provider Access API (new). Shares claims and encounter data, USCDI clinical data and prior authorization information with in-network providers who have a treatment relationship with the patient. Payers must keep an attribution process that links patients to those providers, and let patients opt out.
• •Payer-to-Payer API (new). When a member switches plans, the new payer can request the member's claims, clinical data and certain prior authorization information covering dates of service within five years of the request. This one is opt-in for patients.
• •Prior Authorization API (new). Publishes the list of covered items and services, shows what documentation each one needs, and accepts and answers prior authorization requests. A response must say whether the request is approved (and when it ends), denied (with a specific reason), or needs more information.

Drugs are excluded from the prior authorization provisions throughout.

The parts that already started

Some of the rule is already in force. Since January 1, 2026, impacted payers (except QHP issuers on the federal exchanges) must send prior authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests. They must also give a specific reason for every denial, however the request came in. The first set of public prior authorization metrics was due by March 31, 2026 (CMS fact sheet).

That matters for planning. If your team met those 2026 timelines with manual workarounds, such as staff watching a queue or spreadsheets tracking deadlines, the 2027 APIs will expose that. An API can only return a decision status that your systems actually record.

The provider side

The rule also adds an "Electronic Prior Authorization" measure for clinicians in MIPS and for hospitals, starting with the 2027 performance period. Clinicians and hospitals must attest that they requested at least one prior authorization electronically through a Prior Authorization API using certified EHR data (CMS fact sheet). Providers will start using these APIs in 2027, and thin data will be noticed.

What the data doesn't tell you

The CMS fact sheet tells you what must exist. It doesn't tell you how ready the industry is. We looked for a reliable, current figure on how many payers are on track and did not find one we could verify, so we are not quoting one.

The fact sheet is also a summary. The exact compliance date for each payer type, and which standards apply to each API, are in the full rule (CMS points to Table H3). This post is a planning guide, not legal advice. Confirm the details for your plan type with your compliance team.

What still has to be built: a practical checklist

With about seven weeks left, the useful question is not "do we have an API?" but "can our data answer the questions the API will be asked?" Here is where to look.

1. Map each API to the systems that feed it

For each of the four APIs, write down which internal systems hold the data: claims, encounters, clinical data, prior authorization records, the provider directory and member eligibility. Delays usually come from one system nobody owns.

2. Get prior authorization data into a structured form

The Prior Authorization API has to say approved, denied with a reason, or more information needed, plus when an approval ends. If denial reasons live in free-text notes, or decisions are recorded in faxed letters, that is your critical path.

3. Build attribution and consent before the endpoints

The Provider Access API needs a patient-to-provider attribution process and an opt-out. The Payer-to-Payer API needs an opt-in. Both are data and workflow problems, not API problems. If you can't answer "which providers is this member attributed to, and have they opted out?" from one place, fix that first.

4. Use the recommended implementation guides

CMS requires FHIR Release 4.0.1, US Core 3.1.1, SMART App Launch, FHIR Bulk Data and OpenID Connect. It "strongly encourages" the Da Vinci guides for coverage requirements discovery, documentation templates and prior authorization support, plus CARIN for patient access (CMS fact sheet). Building to these guides is how your API works with EHRs without one-off integrations for each provider.

5. Decide your X12 position

HHS announced enforcement discretion so that covered entities using an all-FHIR Prior Authorization API, without the X12 278 standard, will not face HIPAA Administrative Simplification enforcement for that choice (CMS fact sheet). FHIR-only, FHIR plus X12, or keeping an X12-only transaction alongside are all on the table. Pick one deliberately, because it decides how much translation work sits in the middle.

6. Test with real provider traffic, not just a sandbox

Run end-to-end tests with at least one provider group or EHR partner before January. A response that passes validation but omits documentation rules creates more phone calls, not fewer.

For vendors selling to payers

If you build utilization management, care management, member portals or claims tools, your customers' deadline is your sales conversation. Three questions will come up:

• •Can your product supply structured prior authorization decisions, including denial reasons and end dates, to the payer's API layer?
• •Does it support the Da Vinci guides, or will the payer need custom mapping?
• •What is your plan for 2027, when providers start attesting to electronic prior authorization and traffic grows?

Clear answers, with documentation, are worth more than a feature list. We covered what health-system buyers look for from vendors in what health system IT buyers actually look for in a vendor security questionnaire; payers will ask many of the same questions about the systems behind these APIs.

Where AI fits, and where it doesn't

These APIs are the data foundation the next wave of AI tools in payer and provider workflows will depend on. An AI agent that drafts a prior authorization request, checks documentation requirements or explains a denial to a member is only as good as the structured data it can read.

What AI should not do is make the coverage decision unsupervised or paper over missing data. Get the data structured and the APIs working first, then automate on top of them. For a wider view of where health software teams should build alongside the big platforms, see Epic is building AI natively: what healthtech startups should build instead.

If your team is short on integration engineers for the final stretch, Ontoborn's full-stack application services team works on exactly this kind of systems-integration build.

FAQ

Has the January 1, 2027 deadline been delayed?

No. As of November 2026, CMS's rule page still says impacted payers have until "primarily January 1, 2027" for the API requirements. The exact date can vary by payer type, so check the full rule for your plan type.

Does the Prior Authorization API cover prescription drugs?

No. CMS excludes drugs from the prior authorization provisions in this rule, including the Prior Authorization API, the decision timeframes and the data shared through the other APIs. Drug prior authorization follows separate processes.

We already have a Patient Access API. Are we mostly done?

Probably not. The existing Patient Access API now needs prior authorization information added, and three more APIs (Provider Access, Payer-to-Payer and Prior Authorization) are new. Most of the remaining work is in the data behind them: attribution, consent and structured decision records.