Your FHIR endpoints exist. Will the data behind them pass validation?
The board asks whether you will be ready on January 1, 2027. The vendor says the endpoints are live. Your team knows what is underneath: the same member with three IDs, legacy codes with no FHIR mapping, prior-auth decisions trapped in fax images — and the 72-hour / 7-day decision clocks already in force since January 2026.
What is CMS-0057-F data readiness?
CMS-0057-F data readiness is the state in which a payer's claims, clinical, and prior-authorization data can be extracted from core systems, matched to the right member, mapped to the required FHIR implementation guides — US Core, CARIN Blue Button, and Da Vinci CRD/DTR/PAS — and served current, passing implementation-guide validation continuously.
The mandated APIs are FHIR; a plan's actual data is X12 transactions, database tables, and flat files. The entire compliance problem is the translation layer between the two — mapping, matching, and data quality.
Four APIs, one deadline — each a different consumer of the same plan data
| Mandated API | Who calls it | What it must return |
|---|---|---|
| Patient Access | The member, via consumer apps | Their claims, clinical data, and prior-authorization decisions |
| Provider Access | In-network clinicians | Data about their patients enrolled in the plan |
| Payer-to-Payer | The member's previous or next insurer | Up to 5 years of history when a member switches plans |
| Prior Authorization | Provider systems (EHRs) | Documentation requirements; accepts requests; returns decisions with reasons — 72 hours urgent / 7 days standard, in force since January 2026 |
Per the 2026 WEDI readiness survey, endpoints exist — but roughly one-third of payers are far behind, and shipped APIs frequently sit on top of broken or unmapped data. After January 1, prior-authorization denial statistics are reported publicly: remediation happens in front of an audience.
If any of these sound familiar, your APIs aren't ready
Your path to January 1, step by step
-
1
Extract claims, clinical, and prior-auth data from core systems — Facets, EDI gateways, PA repositories
-
2
Resolve member identity across systems — one person, one golden record, deterministic plus probabilistic matching
-
3
Map to FHIR resources per the implementation guides — US Core, CARIN Blue Button, Da Vinci CRD/DTR/PAS
-
4
Load your vendor's FHIR store — whichever interoperability platform you run, we feed the store it serves from
-
5
Validate against IG profiles — the same checks the regulator's reviewers and consumer apps will run
-
6
Keep it synchronized daily — freshness monitoring and lineage, so the API answers correctly and stays current
The 30-day audit measures your member-match rates, unmapped code values, and sync freshness against the implementation guides — so you know the size of the gap before you fund the fix.
What ready looks like in practice
Results from Artha's anchor engagement at one of the largest Blue Cross Blue Shield plans. Presented as capability proof from a single client — not industry averages.
CMS-0057-F, answered
A CMS final rule requiring impacted payers — Medicare Advantage, Medicaid, CHIP, and Exchange plans — to expose standardized FHIR APIs (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization) by January 1, 2027, and to meet faster prior-authorization decision timelines already in force since January 2026.
Four: Patient Access (members via consumer apps), Provider Access (in-network clinicians), Payer-to-Payer (up to five years of history when a member switches plans), and Prior Authorization (documentation requirements, request submission, and reasoned decisions).
72 hours for urgent requests and 7 calendar days for standard requests. These timelines took effect in January 2026, ahead of the API deadline.
Because the platform serves whatever it is fed. Unmatched member identities, legacy code values with no FHIR mapping, prior-authorization records held in unstructured formats, and stale synchronization jobs all surface as implementation-guide validation failures.
US Core for baseline clinical data, CARIN Blue Button for consumer-facing claims data, and the Da Vinci family for prior authorization — CRD (is authorization required?), DTR (what documentation is needed?), and PAS (submit the request and return the decision).
Artha's standard path is a 30-day audit followed by a 90-day fix: member-match remediation, implementation-guide mapping, and synchronized pipelines, scoped to the APIs at greatest risk first.
January 1, 2027 is a data deadline
Find out in 30 days whether your APIs will pass — while the answer is still private.
