Payer interoperability and prior authorization APIs
Digital Scientists builds FHIR APIs and prior authorization automation for health plans and the vendors that serve them, to the CMS Interoperability and Prior Authorization rule (CMS-0057-F). It's a capability we bring from related delivered work: a FHIR R4 gateway on HAPI FHIR, risk adjustment on Medicare Advantage claims and EHR data, and the systems audit that put CommuniCare Advantage, a special needs plan, back in CMS compliance. Most plans start with a gap check of what their core vendor already covers, so they build only what's missing.
Updated
FHIR APIs the CMS prior authorization rule requires
When most of the API requirements apply
Systems audited for CommuniCare Advantage
RAF improvement from claims and EHR data
What does CMS-0057-F require, and when?
Four FHIR APIs and faster, more transparent prior authorization. Most API requirements apply from January 2027; some operational requirements began in 2026.
CMS-0057-F is the CMS Interoperability and Prior Authorization final rule, published in January 2024. It applies to Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs and managed care plans, and qualified health plan issuers on the federally facilitated exchanges. Medicaid, CHIP and exchange plans often phase in by rating period or plan year, so check the current CMS timeline for your line of business.
This page is about building those APIs and the prior authorization workflow behind them. For the wider picture of how we connect healthcare systems, see healthcare integrations. We haven't yet shipped a CMS-0057-F API for a plan; the work we've delivered that carries over is below.
CMS-0057-F at a glance
| Requirement | What it means | When |
|---|---|---|
| Prior authorization decision times | 72 hours for expedited requests and 7 calendar days for standard requests, for Medicare Advantage, Medicaid and CHIP payers | From January 2026 |
| Specific denial reasons | Every denied prior authorization request comes with a specific reason | From January 2026 |
| Public prior authorization metrics | Approval, denial and turnaround figures posted on the payer's website each year | First report in 2026 |
| Patient Access API usage reporting | Annual counts of members whose data reached an app through the API, reported to CMS | Began in 2026 |
| Provider Access, Payer-to-Payer and Prior Authorization APIs | Three new FHIR APIs, plus prior authorization data added to the existing Patient Access API | Mostly from January 2027 |
Dates are summarized from the final rule.
Which payer APIs does the rule cover, and what does each one do?
Four FHIR APIs: Patient Access, Provider Access, Payer-to-Payer and Prior Authorization. Each one moves claims, clinical and prior authorization data to a different audience.
FHIR is the HL7 API standard built on web resources such as Patient, Claim and Coverage. CMS points payers to HL7 Da Vinci implementation guides for prior authorization: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS). The hard part is rarely the FHIR server. It's mapping claims, encounter and authorization data from the core admin system into resources the guides expect, and matching members across sources. The Payer-to-Payer API adds a second problem: taking in another plan's data and attaching it to the right member. Our status column is honest: this is capability, not a delivered client API.
The CMS-0057-F API set
| API | Who uses it | What it carries | Our status |
|---|---|---|---|
| Patient Access API | Members, through apps they choose | Claims and encounter data, clinical data (USCDI) and, under this rule, prior authorization information | Capability |
| Provider Access API | In-network providers with a treatment relationship | The same data for attributed members; members can opt out | Capability |
| Payer-to-Payer API | The member's new plan, when they switch | Up to five years of claims, clinical and prior authorization data, with the member's opt-in | Capability |
| Prior Authorization API | Providers and their EHRs | Whether an item needs authorization, the documentation required, the request and the decision (Da Vinci CRD, DTR, PAS) | Capability |
| FHIR R4 gateway (HAPI FHIR) | Our own build, for a partner | Standards-based exchange between a care platform and an EHR | Built and tested; waiting on production credentials |
See FHIR and HL7 integration for how we plan standards work, and claims and X12 integration for the transactions behind the claims data.
What does prior authorization automation actually do?
It does the gathering and the paperwork. A person makes the clinical decision. That split is how we design every prior authorization workflow, on the payer side and the provider side.
Check if authorization is needed
At the point of order, the EHR asks the payer's rules (CRD) and gets an answer in the workflow, not a phone call later.
Gather the documentation
A workflow or back-office AI agent pulls the required items from the chart (DTR) and links each one to its source, so a reviewer can check it in seconds.
Submit and track
The request goes out through the Prior Authorization API (PAS), and status comes back the same way. Nobody refreshes a portal.
Prepare the case for review
On the payer side, the agent summarizes the request against the policy for a nurse or physician reviewer. It never issues a denial. The reviewer decides and records a specific reason.
Measure the turnaround
Every step is logged, which gives you the decision times and denial figures the rule asks you to publish.
What have you delivered for health plans that carries over?
The data work underneath payer APIs. We've audited a Medicare Advantage plan's systems, built risk adjustment on its claims and EHR data, extracted HEDIS supplemental data and built a FHIR R4 gateway.
For CommuniCare Advantage, a Medicare Advantage special needs plan, we audited 60+ systems, ran an 11-vendor EHR selection and built the reporting that brought the plan back into CMS compliance. See the CommuniCare Advantage case study.
For CommuniCare Health Services we built a risk adjustment engine, delivered in 2023 and 2024, that read diagnoses, assessments, medications, notes, labs and claims for 20K+ Medicare Advantage patients. It produced $10M+ in RAF improvement at 90%+ accuracy. We also extracted HEDIS MY2023 supplemental data against NCQA specifications and mapped care management workflows to the NCQA SNP Model of Care.
Separately, we built a FHIR R4 gateway on HAPI FHIR, tested and waiting on a partner's production credentials. Matching members across sources, mapping claims to standard codes and keeping every record traceable is the same work a Provider Access or Payer-to-Payer API needs.
Systems audited for CommuniCare Advantage
RAF improvement at 90%+ accuracy
Medicare Advantage patients in the risk adjustment data
Where should a plan start on CMS-0057-F?
With a gap check. Most core admin and interoperability vendors cover part of the rule, so the first job is finding out which part, then building only the gap.
Gap check against your vendors
What your core admin system and FHIR vendor already provide, what data each API needs and where it lives today. Many plans find the data mapping is the real gap.
Start with a map
If nobody can say what you run, start with an inventory and a target-state map. CommuniCare Advantage started the same way. A Blueprint covers it.
A Blueprint for the build
Scope, architecture, the Da Vinci guides you'll implement, user stories and a milestone budget for the APIs and the prior authorization workflow. See Blueprint.
Build on what you have
If you already run a FHIR server, we build the mappings, the prior authorization services and the monitoring on top of it.
Related work for plans
CommuniCare Advantage
Back to CMS compliance in under six months
A Medicare Advantage special needs plan: an audit of 60+ systems, an 11-vendor EHR selection and CMS reporting from a single data mart. The data mapping a payer API needs starts here.
See the work
CommuniCare Health Services
$10M+ RAF improvement at 90%+ accuracy
Risk adjustment on claims and EHR data for 20K+ Medicare Advantage patients, every suggested code linked to its evidence. The same member matching and claims mapping feed payer APIs.
See the work
Congruity Health
7,020 patients tracked
A platform that ingests claims and eligibility data from TPAs and turns it into intervention triggers. The claims pipeline is the source side of a Patient Access or Provider Access API.
See the workTrusted by healthcare leaders.
“Digital Scientists provided immense value to our plan administrators, providers, and patients. The team was able to come in and understand our core needs, while remaining product agnostic. They helped identify the technical debt and pitfalls, and to get us to a point of stabilization and growth.”
Robert Hager
CEO, CommuniCare Advantage
“The team at Digital Scientists was a huge help in not only developing our analytics platform, but understanding the competitive space and defining our true value proposition for our customers.”
Justin Davis
CEO, Congruity Health
Related services
Healthcare integrations
EHR, FHIR, labs, payers, claims and HIPAA cloud.
Healthcare integrations →FHIR and HL7
Standards-based data exchange, planned before the build.
FHIR and HL7 →Claims and X12
Claims, eligibility and remittance data, loaded and matched.
Claims and X12 →Health plans and payers
Software for Medicare Advantage plans, SNPs and ACOs.
Health plans and payers →Back-office AI agents
Agents that do the paperwork while people decide.
Back-office AI agents →RAF and HCC coding
Risk adjustment AI with every code linked to the chart.
RAF and HCC coding →
Questions about payer APIs and prior authorization
What are the CMS-0057-F deadlines?
Most API requirements apply from January 2027: the Provider Access, Payer-to-Payer and Prior Authorization APIs, and prior authorization data in the Patient Access API. Some operational requirements began in 2026, including prior authorization decision times of 72 hours for expedited and 7 calendar days for standard requests, specific denial reasons and public prior authorization metrics. Medicaid, CHIP and exchange plans often phase in by rating period or plan year, so check the current CMS timeline for your line of business.
Can you build on our existing FHIR server?
Yes. If you already run a FHIR server or a vendor's interoperability platform, we build on it: the mappings from your claims, clinical and authorization data, the prior authorization services and the monitoring. We start by checking what it already covers, so you only build the gap. We've built a FHIR R4 gateway on HAPI FHIR ourselves, tested and waiting on a partner's production credentials.
Have you shipped a CMS-0057-F API for a health plan?
Not yet. Payer APIs are a capability for us, built on related work we've delivered: a systems audit and CMS reporting for CommuniCare Advantage, risk adjustment on Medicare Advantage claims and EHR data, HEDIS MY2023 supplemental data extraction and a FHIR R4 gateway on HAPI FHIR. We'd rather tell you that up front.
What are the Da Vinci CRD, DTR and PAS guides?
They're HL7 implementation guides for prior authorization over FHIR. Coverage Requirements Discovery (CRD) tells the provider whether an item needs authorization. Documentation Templates and Rules (DTR) gathers the documentation the payer requires. Prior Authorization Support (PAS) sends the request and returns the decision. CMS recommends them for the Prior Authorization API.
Does AI decide prior authorization requests?
Not in anything we build. An agent or workflow checks requirements, gathers documentation and prepares a summary against the policy. A nurse or physician reviewer makes the decision and records the specific reason the rule requires. Every step is logged, so you can show how each decision was made.
How do you handle member data?
We sign a BAA before we touch PHI. Each client gets a security plan mapped to NIST CSF 2.0 and a security addendum, with encryption, access controls and audit logging designed in from the start. AI runs inside your own cloud account, so member data stays there.
Talk it over
Tell us what you are trying to do. A senior person from our Atlanta team replies within one business day, and you can book a 30-minute call right after you send this.
- We tell you if we're the right fit, and if we're not, who is.
- Most work starts small, so you see how we work before you commit to more.
- We sign a BAA before we touch patient data.