Proven with Industry Leaders
The four CMS-0057-F APIs, plus the provider directory
Each API serves a different caller and follows its own HL7 implementation guides. Our check covers all five.
| API | Who calls it | What it must provide | Implementation guides |
|---|---|---|---|
| Patient Access | Members, through apps they choose | Claims and clinical data. CMS-0057-F adds prior authorization information, excluding drugs. | CARIN Blue Button, US Core, Da Vinci PDex, SMART App Launch |
| Provider Access | In-network providers with a treatment relationship, for attributed patients | Claims and encounter data without remittances or cost sharing, USCDI data, and prior authorization information excluding drugs. Patients can opt out. | Da Vinci PDex, US Core, Bulk Data, SMART Backend Services |
| Payer-to-Payer | A member's new plan, with the member's opt-in | The same data, for dates of service within five years of the request. | Da Vinci PDex, Bulk Data |
| Prior Authorization | Providers and their EHRs | Which items and services need authorization, the documentation required, and requests and responses: approved, denied with a specific reason, or more information needed. | Da Vinci CRD, DTR and PAS |
| Provider Directory | Members and the public | The existing directory API for network providers. Not new in CMS-0057-F, but included in our check. | Da Vinci PDex Plan-Net |
Required standards include FHIR R4, US Core 3.1.1, SMART App Launch, Bulk Data and OpenID Connect. CMS strongly encourages the Da Vinci, CARIN and Plan-Net guides listed. API requirements generally begin January 1, 2027, and exact dates vary by type of payer. Source: CMS fact sheet on CMS-0057-F.
Where payer FHIR API builds stall
The endpoints are the easy part. The work sits behind them, in systems that were never built to answer an API call.
Prior authorization lives in a system with no FHIR interface
Utilization management systems were built for fax, portals and X12. The Prior Authorization API has to sit in front of that system and translate in both directions, without changing how reviewers work.
Member matching, attribution and consent
Payer-to-payer exchange depends on matching a member across plans and recording their opt-in. Provider access depends on attributing patients to providers and honoring opt-outs. Most of the effort is here, not in the endpoint.
Access for apps and systems you do not control
SMART on FHIR, backend services and OpenID Connect have to work for member apps, provider EHRs and other plans. Authorization is where many test runs fail first.
Test kits that are still maturing
Several of the official test kits for these guides are early versions. A clean automated run is not the whole picture, so someone has to read each failure against the guide itself.
What you get from the check
We point the open-source Inferno test kits at your test system, read every failure against the guide, and write it up in three parts.
Findings
A one-page summary for your sponsor with the status of each API and the top five fixes. Then the detail per API: the test kit and version, what passed and failed, the request and response behind each failure, the guide requirement it breaks, and how serious it is. Each result says whether it came from an automated test or our review.
Remediation plan
For each serious finding, how to fix it on your platform, the order to fix them in, what can wait until after go-live, effort ranges, and how the retest will confirm each fix. Included in the check at no cost.
Quote, if you want one
A fixed price to fix the gaps and redeploy, and support after go-live. Sent as a separate document, so the findings can go to your compliance team on their own.
Not included: a compliance opinion or attestation, the rule's operational requirements (decision timeframes and metrics reporting), production systems, patient data, and X12 278 transactions.
Test what you have, or plan what you need
If your APIs run in a test system or in production, start with the check. If there is nothing to test yet, start with the build plan.
- FHIR API check: free for one test environment and up to five APIs, up to $3,000 for more environments or an end-to-end prior authorization walk-through. Written report within five business days after test access, and one retest within 30 days.
- Build plan: free. Which APIs to build first, platform options, what can be live by your deadline, and a quote for the build, within five business days.
- Your data stays put: test data only, never patient data.
CMS-0057-F APIs, answered plainly.
What is CMS-0057-F?
CMS-0057-F is the CMS Interoperability and Prior Authorization Final Rule. It requires impacted health plans to run four FHIR APIs (Patient Access, Provider Access, Payer-to-Payer and Prior Authorization) and sets process requirements for prior authorization decisions, denial reasons and public reporting.
Which health plans does it apply to?
According to CMS, the rule applies to 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.
When are the APIs due?
CMS says the API requirements generally begin January 1, 2027, and the operational provisions generally began January 1, 2026. The exact dates vary by type of payer, so check yours against the rule.
Does the FHIR API check tell us we are compliant?
No. The check is a technical test of your APIs against the HL7 implementation guides. Compliance depends on more than API conformance, and it is a judgment for your compliance and legal teams. The report gives them technical evidence, not an opinion.
What do you need from us for the check?
The test address and capability statement for each API, test credentials for an outside app or system, and synthetic test members. No patient data. We run the open-source Inferno test kits in our own environment against your test system. If your policy requires an NDA, we sign yours.
Do we have to use WSO2?
No. We test and build on the platform you run, whether that is your core platform vendor, a cloud FHIR service, a custom build or WSO2. Where it fits, the build plan may recommend the WSO2 Accelerator for Healthcare as one option.