The 2027 payer API deadline is a test of the whole standards stack

The 2027 payer API deadline is a test of the whole standards stack. By January 2027, the payers CMS regulates, from Medicare Advantage plans to state Medicaid programs, must run 4 FHIR APIs under CMS’s 2024 interoperability and prior authorization rule. Each API has a mature implementation guide behind it, written and tested by HL7 communities over several years.

What lacks a required standard is the space between the guides. A provider asking for a patient’s data has to be recognized as that patient’s provider. A request has to find the right endpoint at the right payer, and the system sending it has to be trusted there. CMS’s rule leaves most of that to each payer. Its April 2026 proposal would make the guides mandatory from October 2027 and asked for comment on the connective standards, without proposing to require them.

The case made here is for a public, end-to-end test of every payer’s APIs in the fall of 2026, while there is still time to fix what fails.

Key takeaways

• Payers owe 4 APIs in January 2027. Patient access gains prior authorization data, and in-network providers gain access to their patients’ data. Payer-to-payer exchange and a prior authorization API complete the set.
• Only the base standards are required. CMS requires FHIR Release 4 and a small set of base specifications. The guides written for each API are recommended, not required.
• The guides become mandatory later. CMS’s April 2026 proposal would require them from October 1, 2027, after the APIs go live.
• The connective standards are still optional. CMS asked for comment on 3 of them for future rulemaking, including the Da Vinci guide for member attribution.
• Readiness is uneven. Payers in a February 2026 WEDI survey named delegated third parties as a top challenge. A quarter of respondents expected costs above $5 million.
• Test the stack in public before January. A dress rehearsal with synthetic members across payers’ production APIs would surface failures while there is still time to fix them.

What is due in January 2027

CMS finalized the requirements in January 2024, in CMS-0057-F. The operational provisions, such as decision timeframes and denial reasons, began in January 2026. The API requirements generally apply from January 1, 2027, with exact dates varying by payer type.

From CMS’s fact sheet on CMS-0057-F (January 2024). Drugs are excluded from the prior authorization provisions.

The familiar API and the new ones

The Patient Access API is not new. Payers have run it since 2021 under an earlier CMS rule. The 2027 change adds prior authorization information, and payers began reporting usage of the API to CMS in 2026.

The Provider Access API is the largest change. For the first time, payers must make patient data available to the providers treating their members at scale. Payers must maintain an attribution process to decide which providers have a treatment relationship with which patients, and they must let patients opt out. The rule uses the Bulk Data standard, so a provider organization can request data for a whole population of attributed patients at once.

The Payer-to-Payer API moves data when a patient changes plans, if the patient opts in. Our analysis of payer-to-payer continuity described how it can carry prior authorization history forward. The Prior Authorization API is the subject of our review of HTI-4. Decisions sent through it must say whether a request is approved or denied, and a denial must give a specific reason. HHS has said it will not enforce the HIPAA X12 requirement against payers that run a FHIR-only prior authorization API, according to the CMS fact sheet.

Readiness so far

The best recent view of readiness comes from WEDI, the industry group that advises HHS on health data standards. Its survey in February 2026 drew 86 responses, about half from payers and nearly a third from vendors. Among respondents, 10% had not started work on the APIs. A quarter expected implementation costs above $5 million, up from 15% in an earlier round. Another 28% expected costs between $1 million and $5 million.

Payers ranked connecting delegated third parties with different systems as a leading challenge. Digitizing prior authorization policies ranked high as well, with funding close behind. The first of those is a stack problem. A plan that delegates imaging review to one vendor and post-acute review to another has to make both look like a single API to the outside world.

Intermediaries expect to carry much of the load. In the survey, 60% of clearinghouses said they plan to perform API exchanges for payer customers. Among vendors, 82% said they plan to help payers and providers comply. That spreads the work, and it adds more parties to every exchange that has to be tested.

The standards CMS requires and recommends

The 2024 rule draws a clear line. It requires a set of base standards that every API shares. It recommends, without requiring, the guides that define what each API actually says.

From the CMS fact sheet on CMS-0057-F (January 2024). Payers may use updated versions approved by ONC if end users can still reach the required data.

The split matters. A payer can comply with the rule using its own profiles on top of FHIR. A provider system built to the recommended guide may then fail to work with it, even though both sides followed the rules that bind them.

Versions add a second problem. EHRs certified under HTI-4 use version 2.1.0 of the 3 Da Vinci prior authorization guides. CMS’s 2024 rule recommended earlier versions. A payer that built to the recommended version and an EHR certified to the newer one may need work to talk to each other.

What CMS proposed in April

On April 10, 2026, CMS released CMS-0062-P, which would close part of the gap. The comment period closed on June 15, according to Crowell & Moring.

From the CMS fact sheet (April 2026) and Crowell & Moring (April 2026).

The proposal moves the stack in the right direction. Required guides and aligned versions would make a certified EHR and a payer API speak the same dialect. A published endpoint list would let anyone see which payers have gone live. Usage metrics would show whether anyone uses the APIs once they exist.

The timing leaves a gap. The APIs go live in January 2027 under the old rule, and the required guides would follow in October 2027 if CMS finalizes them. For most of 2027, the stack will run on recommendations.

The gaps between the guides

CMS named 3 connective standards for comment. FAST Security and the Da Vinci member attribution guide address trust and attribution. The third, a Da Vinci guide for clinical data exchange, covers how payers request records from providers. Each addresses a problem that every API faces and none of the API guides solves alone. Endpoint discovery is a fourth gap, which the April proposal addresses with a central list.

Attribution

The Provider Access API depends on knowing which providers treat which patients. CMS requires each payer to maintain an attribution process, and each payer designs its own. A provider group that sees members of many plans may find itself attributed differently by each one. Some plans will attribute by claims history, others by assigned panels.

Attribution decides what a provider can see. Under the Bulk Data standard, a provider organization requests data for its attributed patients as a group. If a payer’s attribution lags, a patient seen for the first time last week may not be in the group. The provider then receives nothing for that patient. The provider has no standard way to see why.

The Da Vinci member attribution guide gives payers and providers a standard way to exchange attribution lists, and many value-based contracts already need one. Requiring it would not settle how attribution is decided. It would make the result visible to the provider in the same format at every payer.

Trust and registration

SMART App Launch requires each client system to register with each server. For a patient app, that is manageable. For a provider organization pulling data from many payers, or a payer requesting data from another payer, registration at every endpoint becomes a project of its own.

FAST Security, built on the UDAP specifications, lets systems register dynamically using trusted certificates. A provider’s system could present credentials once and be recognized by any payer that trusts the same certificate authorities. Without it, the number of registrations grows with every pair of organizations that need to connect. A health system that exchanges data with 40 payers registers 40 times. A payer with thousands of contracted provider organizations faces the same arithmetic from the other side.

Finding the endpoint

Today a developer often has to find each payer’s FHIR endpoint by reading its website or asking its staff. The April proposal would have payers report their endpoints and capability statements for CMS to publish in a central location, with updates within a week of any change. CMS also floated the national directory’s endpoint profile as an alternative. Until a list exists, discovery depends on each payer’s documentation.

Clinical records on request

The prior authorization guides cover the request and the decision. They do not fully cover the moment a reviewer needs a record the request did not include. Today that request often goes out by fax or portal. The Da Vinci clinical data exchange guide defines a FHIR way to ask for and return those records. HHS separately proposed in April 2026 to use the same guide for HIPAA attachments, according to the CMS fact sheet. CMS asked for comment on requiring it for the APIs.

Matching the member

Payer-to-payer exchange requires the new payer to identify the patient at the old one. The PDex guide uses a member match operation for this. Match quality depends on the demographic data each payer holds, and a failed match means the data never moves. The patient opted in, and nothing happens.

Where national networks fit

National networks could carry some of this load. TEFCA had passed 474 million documents exchanged across about 70,000 sites by February 2026, according to an ASTP presentation. CMS’s interoperability framework has also enlisted networks to become CMS Aligned Networks, as our review of the framework described.

The networks are not part of the 2027 requirement, though. Under TEFCA’s exchange purpose rules updated in December 2025, responding to requests for payment purposes is optional. Our TEFCA status review covers how the network’s rules are evolving. For now, the payer APIs and the national networks are parallel roads that cross in only a few places.

Run the test before the deadline

Standards are usually tested at connectathons, where developers exchange data with test servers over a few days. Compliance with a CMS deadline is usually attested. Neither step tests the stack the way patients and providers will use it. Real use means many payers at once, with real attribution rules and real registration steps.

A deadline that counts APIs stood up will be met. A deadline that counts data delivered is the one that matters.

A national dress rehearsal in the fall of 2026 would fill that space. It could work like this.

Our framework, built on the API requirements in CMS-0057-F.

1. Synthetic members at every payer. Each participating payer enrolls a set of test members with known data in its production environment, flagged so they never mix with real claims.
2. Scripted scenarios for each API. Test teams run the same scenarios at every payer. A patient app retrieves a prior authorization decision. An attributed provider requests data for a panel of members. A member switches plans and opts in to payer-to-payer exchange. A clinician’s system discovers requirements and submits a request.
3. Public results by payer and API. Results show which scenarios passed and which failed, with the date each failure was fixed. A payer that declines to take part is visible by its absence.
4. Retest before January. Failures found in October can be fixed in November. Failures found in January are found by patients.
5. Keep measuring after go-live. CMS’s proposed usage metrics would arrive in 2028. Quarterly reporting during 2027 would show sooner whether the APIs carry data.

The pieces already exist. HL7’s Da Vinci and CARIN communities maintain test scripts for their guides. ONC’s open-source Inferno test kits include server tests that payers can run against their own endpoints. What is missing is a convener and a public scoreboard. CMS could convene it without new rulemaking, because participation would be voluntary. An industry group could also run it.

There are fair objections. Testing in production carries security risk, and synthetic members have to be isolated carefully. Smaller payers and state Medicaid programs have fewer resources, and a public failure can look worse than it is. Each objection argues for careful design, with clear isolation rules and a chance to fix failures before results are published. None argues for leaving the first real test to January.

Where Redlake stands

Redlake builds tools that health plans use in utilization review, so we sit on the payer side of the Prior Authorization API. Our rules shape what that API should carry. A machine can say yes, but only a person can say no, so automated approvals can travel through the API in real time while denials come from clinicians. Every recommendation shows its reasons, which fits the rule’s requirement that a denial give a specific reason. Every decision can be reconstructed, which means the record behind each response should survive any later question about it.

Prior authorization is where most of our work sits, and it is the API most likely to be judged by its failures. A clinician who receives a pended request with no reason will not care whether the payer’s endpoint passed a format test. The reasons have to travel with the decision, in a form the clinician’s system can display.

We support a public dress rehearsal and would want the systems our tools connect to tested in it. A payer API that passes a scripted scenario in October is more useful to a clinician in January than a compliance attestation. The same applies to the connective standards. Attribution lists and trusted registration are not glamorous, but they decide whether the 4 APIs work as a system or as 4 separate projects.

What to watch in the rest of 2026

• The CMS-0062-P final rule. Watch whether CMS finalizes required guides for October 2027, and whether it adds any of the 3 connective standards.
• Payer go-live announcements. Watch which payers publish production endpoints before January, and whether they publish test results with them.
• HTI-5. ASTP’s deregulatory proposal from December 2025 could change the certification baseline that EHRs bring to the exchange.
• CMS Aligned Networks. Watch whether the networks enlisted under CMS’s framework begin carrying payer API traffic, or remain mainly a channel for patient apps.
• Delegated vendors. Many plans delegate prior authorization and other functions to outside vendors. Watch how plans connect those vendors to their APIs, the challenge payers ranked high in the WEDI survey.

About this analysis

Method. The API requirements in CMS-0057-F are compared with the standards CMS required and recommended, and with the changes CMS proposed in April 2026, using CMS fact sheets, a WEDI industry survey and an ASTP presentation on TEFCA.

Data notes. The WEDI survey drew 86 responses in February 2026. About half came from payers, and only a few came from providers, so provider figures are not reported here. The TEFCA figures are as ASTP presented them. CMS-0062-P is a proposal, and its provisions may change. The dress rehearsal is this analysis’s proposal, not a plan announced by CMS or any industry group.

Sources. CMS, CMS-0057-F fact sheet (January 2024) and CMS-0062-P fact sheet (April 2026). Crowell & Moring (April 2026). WEDI, survey release (March 2026). ASTP, TEFCA update presentation (February 2026).

Frequently asked questions

Which APIs must payers have by January 2027?

Under CMS-0057-F, impacted payers must add prior authorization information to their Patient Access API and stand up a Provider Access API. They must also run a Payer-to-Payer API and a Prior Authorization API. Exact dates vary by payer type.

Which standards does CMS require for the payer APIs?

CMS requires FHIR Release 4.0.1 and a small set of base specifications, including US Core for clinical data and SMART App Launch for authorization. The guides written for each API, such as the CARIN and Da Vinci guides, are recommended rather than required.

Will the implementation guides become mandatory?

CMS proposed in April 2026 to require them from October 1, 2027, with versions tied to those adopted in federal health IT regulation. The proposal had not been finalized as of July 2026.

How will providers find a payer’s API endpoint?

Under the April 2026 proposal, payers would report their API endpoints and capability statements for CMS to publish in a central location. Until then, providers rely on each payer’s own documentation.