Quick Summary
This insight explains how our team shipped all four CMS-0057-F FHIR APIs before the January 1, 2027 deadline. It covers what the rule requires, the data groundwork we finished first, and the order we built the APIs in. It also shares how we tested each API and kept evidence, plus lessons other payers can reuse and how the same data can support analytics and AI.
Introduction
For CMS-0057-F FHIR APIs, the deadline is set for January 1, 2027; however, it is getting closer than ever to many payers. There are four APIs that must be ready in time, and each of them depends on the clean data, consent rules, and tested prior authorization workflow. Each lacking element impacts negatively on others.
In our case, we were able to implement all four APIs before the deadline, considering that the primary challenge was seen as data-oriented and not API-focused. In this insight, we will explain our approach in terms of the sequence of implementation and testing of APIs, and will also describe what we would have done differently. We will explain the requirements in the rule, prepare the data for APIs, test each of them, and will describe their potential after compliance implementation.
What the Four CMS-0057-F FHIR APIs Require by January 1, 2027
This rule was published on January 17, 2024, by CMS. This rule applies to Medicare Advantage organizations, state Medicaid/CHIP FFS plans, Medicaid managed care plans, CHIP managed care plans, and QHP issuers on federal Exchanges. The implementation dates for the rule started from January 1, 2026, while the API compliance dates were set as January 1, 2027.
| API | What it provides | Who benefits |
|---|
| Patient Access | Claims, clinical data, and prior authorization status | Members |
| Provider Access | Claims, clinical data, and prior authorization information | In-network providers |
| Payer-to-Payer | Member data that moves when they change plans | Members and new payers |
| Prior Authorization | Standard requests and decisions | Providers and payers |
Since 2026, payers must decide standard requests within seven calendar days and urgent requests within 72 hours (QHP issuers on the federal exchanges are excluded from this timeframe rule). They must also give a specific reason for every denial and publish metrics each year. Drugs are excluded. These timeframes make CMS-0057-F compliance a process question as much as a technology one, and the four CMS-0057-F FHIR APIs sit on top of that process.
Providers are not regulated by the rule, but here is how healthcare providers can prepare for CMS-0057-F compliance: confirm your EHR vendor’s readiness for payer Prior Authorization APIs, and, if you are an eligible clinician or hospital, plan for the 2027 attestation that at least one prior authorization was requested electronically through such an API, unless an exclusion applies. CMS also added electronic prior authorization to its Health Tech Ecosystem in May 2026.
Data Engineering Foundation We Completed Before Building Healthcare APIs
Before we wrote any API code, we started with the data. All four APIs read from the same sources, so one weak record would show up in every API. We treated CMS-0057-F FHIR APIs implementation as a data job first, and we did three things before building anything:
- Source inventory: we listed every system that holds claims, encounters, clinical data, and prior authorization records, and gave each one an owner.
- Member matching and consent: we linked each member to a single identity and captured the choices the rule requires, an opt out for provider access and an opt in for payer to payer exchange.
- FHIR mapping: we mapped legacy fields to FHIR R4 resources and to the US Core profiles the rule names as required standards.
How We Prioritised the CMS-0057-F FHIR APIs Build Order
Implementing all four CMS-0057-F FHIR APIs at once invites rework, because each one depends on data the others also use. We sequenced them by dependency, so every API reused the data layer built for the one before it. That FHIR API implementation order kept the team building forward instead of going back to fix earlier work.
1. Patient Access API: Extend What Already Exists
Payers already run this API under the 2020 rule, so we started here. We added prior authorization status and denial reasons to its data, kept drugs out of scope, and set up the annual usage metrics that CMS requires payers to report from 2026.
2. Provider Access API: Reusing the CMS-0057-F FHIR APIs Data Layer
This API reused the same data and added an attribution process that links each patient to in-network providers with a treatment relationship. It shares claims and encounter data, USCDI data, and prior authorization information, and it honors patient opt outs.
3. Payer-to-Payer API: Managing Consent for CMS-0057-F FHIR APIs
This API moves a member’s data when they change plans. It needs the member’s opt in and covers data with a date of service within five years of the request. Identity matching was the hard part, so we relied on the matching work from the groundwork stage.
4. Prior Authorization API: Wire Up CRD, DTR, and PAS
We built this one last because it touches the most workflows, and it is the most complex of the healthcare FHIR APIs in the rule. It lists covered items and services, states documentation requirements, and returns an approval, a denial with a specific reason, or a request for more information. CMS recommends the Da Vinci CRD, DTR, and PAS guides for it. HHS also allows an all FHIR build without the X12 278 standard, so payers can choose FHIR only or a FHIR and X12 mix.
Final Conformance and Security Checks for CMS-0057-F FHIR APIs
Shipping early only counts if the APIs work under real use and leave proof behind. We tested each CMS-0057-F API integration against the rule’s requirements and kept an evidence file for every one. CMS-0057-F FHIR API implementation before the 2027 deadline rewards teams that collect this proof as they build, because the rule also brings public reporting.
On all four CMS-0057-F FHIR APIs, we checked authentication against the standards the rule names, including SMART App Launch and OpenID Connect. CMS shares a metrics reporting template on its rule page.
| API
|
What we tested | Evidence we kept |
|---|
| Patient Access | Prior authorization data appears, drugs excluded | Test log and sample responses |
| Provider Access | Attribution works, patient opt outs honored | Opt out test cases and access logs |
| Payer-to-Payer | Opt in respected, five year window applied | Consent records and exchange logs |
| Prior Authorization | Approval, denial with reason, and more information paths | Request and response test set |
How CMS-0057-F FHIR APIs Support AI-Ready Clinical Data
Once the four APIs were live, the same pipelines gave us clean, governed, standardized data. CMS-0057-F interoperability data can support analytics and AI, but only if you add the right controls. A standard data layer is a start, not the finish line. We followed five steps before reusing any of it: set an approved purpose, carry over consent and access controls, add data quality rules, track lineage, and keep audit logs.
Step 1: Set an approved purpose.
Payer data is still covered by HIPAA, so we defined why the data would be reused before any model work began. We named one clear use case, listed only the fields it needs, and assigned an owner. Our privacy and compliance teams reviewed the purpose in writing, and we kept that record with the project files.
Step 2: Carry over consent and access controls.
The consent choices from the Provider Access and Payer-to-Payer APIs did not stop at the API layer. We brought those flags into the new datasets and confirmed with the privacy team how each one applies to the new use. We also kept role based access, so only approved people and systems could reach the data.
Step 3: Add data quality rules.
A standard format does not guarantee good data. We set checks for missing values, duplicate records, invalid codes, impossible dates, and failed member matches. Records that failed a check went to a review queue instead of being fixed silently, and the data owners saw the results.
Step 4: Track lineage.
For every field, we recorded the source system, the transformation steps, the FHIR mapping version, and the load date. This lets a team explain where a model input came from and trace an error back to its source in minutes, not days.
Step 5: Keep audit logs.
We logged who accessed each dataset, when it was used for analysis or model training, and what was produced. We reviewed the logs on a set schedule and stored them with the evidence files already kept for the APIs, so one review covers both.
Conclusion
Shipping all four CMS-0057-F FHIR APIs on time required adherence to three key practices: clean up data first, follow dependencies while building, and document the evidence along the way. Given a deadline of January 1, 2027, the data foundation laid by following the above approach will not only make API deployment easy but will also serve as the basis for analytics and AI going forward. Founded in 2011, Bacancy Technology has developed over 200 healthcare solutions so far, thanks to the team of more than 1,050 developers that we have at our disposal. We also have an ISO/IEC 27001:2022 compliant security program.
Frequently Asked Questions (FAQs)
Medicare Advantage organizations, state Medicaid and CHIP fee for service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the federal exchanges. API dates generally begin January 1, 2027 but vary by payer type, and drugs are excluded.
Start with a source inventory and the data each API needs. Build in dependency order, test against the standards the rule names, and keep evidence for each API. Then confirm your compliance date for your payer type
Yes. HHS announced enforcement discretion on February 28, 2024, so covered entities that build an all FHIR Prior Authorization API will not face HIPAA enforcement for skipping X12 278. Payers may also offer an X12 only transaction alongside it.
