The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires impacted payers — Medicare Advantage plans, Medicaid FFS, CHIP, and QHP issuers — to implement a FHIR R4 Prior Authorization API that returns decisions in near real time. The deadline was January 1, 2026.
Most payer infrastructure wasn’t built for this. Prior authorization requests arrive as ASC X12 278 transactions. Decisions flow back as X12 278 responses. The entire PA workflow — from intake to adjudication to notification — was designed around EDI, not FHIR. And the platforms that run it — TriZetto Facets, QNXT, eviCore, ClaimLogiq, Jiva — speak proprietary APIs or X12, not the Da Vinci PAS implementation guide.
The compliance gap isn’t a clinical problem or a policy problem. It’s an integration problem. You have structured data in one format and a regulatory requirement to expose it in another. A Naftiko capability specification is the bridge.
What CMS-0057-F Actually Requires
The rule requires three FHIR APIs built on the Da Vinci implementation guides:
Prior Authorization API — based on the Da Vinci PAS (Prior Authorization Support) IG. Providers submit PA requests as FHIR Claim resources. The payer responds with a FHIR ClaimResponse indicating approved, denied, pended, or more information needed. The response must be returned in near real time for standard requests.
Provider Access API — based on the Da Vinci PDex (Payer Data Exchange) IG. In-network providers can query claims, encounters, and PA data for their attributed patients via FHIR ExplanationOfBenefit, Coverage, and related resources.
Payer-to-Payer Data Exchange — when a member moves from one plan to another, the prior plan must transmit clinical and claims data to the new plan via FHIR.
The core translation problem is this: the X12 278 that arrives at your EDI intake today carries all the information required to produce a compliant FHIR Claim resource. The decision your adjudication engine makes can be expressed as a FHIR ClaimResponse. But nothing in your current stack does that translation — and building a custom integration between your X12 infrastructure and a new FHIR endpoint means writing code that you’ll own forever.
The Capability Spec Approach
A Naftiko capability specification defines two things: what your capability consumes (the data sources and APIs it reads from) and what it exposes (the governed interface that downstream systems — providers, AI agents, other payers — can call).
For the X12 278 → FHIR PA translation, the spec consumes from your existing EDI infrastructure and exposes a FHIR-compliant endpoint. Here’s what that looks like:
naftiko: "1.0.0-alpha1"
info:
title: "Prior Authorization — X12 278 to FHIR PAS"
description: >
Bridges X12 278 prior authorization transactions to Da Vinci PAS-compliant
FHIR R4 endpoints. Consumes from EDI clearinghouse and payer adjudication
platform; exposes FHIR Claim (PA request) and ClaimResponse (PA decision)
resources per CMS-0057-F requirements.
capability:
consumes:
- namespace: edi-clearinghouse
type: http
baseUri: "https:///api/v1"
authentication:
type: bearer
token: ""
resources:
- name: transactions
path: "/transactions"
operations:
- name: get-278-request
method: GET
description: "Retrieve an inbound X12 278 prior authorization request by transaction ID"
inputParameters:
- name: transactionId
in: path
type: string
required: true
- name: tradingPartnerId
in: query
type: string
required: true
- namespace: payer-adjudication
type: http
baseUri: "https:///api"
authentication:
type: bearer
token: ""
resources:
- name: prior-auth-decisions
path: "/prior-auth/decisions"
operations:
- name: get-pa-decision
method: GET
description: "Retrieve prior authorization decision from adjudication engine"
inputParameters:
- name: authorizationNumber
in: query
type: string
required: true
exposes:
- type: mcp
address: "0.0.0.0"
port: 3020
namespace: prior-auth-fhir
description: "Da Vinci PAS-compliant prior authorization tools for CMS-0057-F"
tools:
- name: submit-prior-auth
description: "Accept a FHIR Claim PA request, translate to X12 278, submit to payer system, and return FHIR ClaimResponse"
hints:
readOnly: false
destructive: false
idempotent: false
inputParameters:
- name: claim
type: object
required: true
description: "FHIR R4 Claim resource (PA request per Da Vinci PAS IG)"
- name: memberId
type: string
required: true
- name: providerId
type: string
required: true
description: "NPI of requesting provider"
call: payer-adjudication.get-pa-decision
with:
authorizationNumber: ""
outputParameters:
- type: object
description: "FHIR R4 ClaimResponse resource with PA decision"
properties:
resourceType:
type: string
mapping: "ClaimResponse"
outcome:
type: string
mapping: "$.outcome"
description: "queued | partial | complete | error"
disposition:
type: string
mapping: "$.disposition"
description: "Approved | Denied | Pended | More Information Needed"
- name: get-prior-auth-status
description: "Check the status of a pending prior authorization request"
hints:
readOnly: true
destructive: false
idempotent: true
inputParameters:
- name: authorizationNumber
type: string
required: true
- name: memberId
type: string
required: true
call: payer-adjudication.get-pa-decision
with:
authorizationNumber: ""
outputParameters:
- type: object
properties:
status:
type: string
mapping: "$.status"
decision:
type: string
mapping: "$.decision"
effectiveDate:
type: string
mapping: "$.effectiveDate"
expirationDate:
type: string
mapping: "$.expirationDate"
Two consumes namespaces. Two exposed tools. No custom integration code between them — the capability spec is the integration contract.
The Terminology Problem
The X12 278 carries ICD-10 diagnosis codes, CPT procedure codes, and NPI provider identifiers. The FHIR Claim resource carries the same information — but expressed as FHIR CodeableConcept resources with explicit system URIs.
An ICD-10 code in a 278 becomes:
outputParameters:
- type: object
properties:
diagnosis:
type: array
mapping: "$.diagnosis"
items:
type: object
properties:
diagnosisCodeableConcept:
type: object
properties:
coding:
type: array
items:
system: "http://hl7.org/fhir/sid/icd-10-cm"
code:
mapping: "$.icd10Code"
CPT codes follow the same pattern with system http://www.ama-assn.org/go/cpt. RxNorm for drugs. LOINC for labs. The capability spec’s output projection handles the terminology mapping — the consuming system gets properly coded FHIR resources without touching the translation logic.
What This Covers and What It Doesn’t
The capability spec above handles the core PA request/response loop. CMS-0057-F compliance also requires:
SMART on FHIR authentication for the Provider Access API. Most payer portals use SAML 2.0 today. The exposes block can specify authentication: type: smart-on-fhir to document the OAuth 2.0 + OpenID Connect requirement, even when the underlying system still uses SAML internally.
Payer-to-Payer exchange requires a second capability spec that consumes from a source payer’s FHIR Patient Access API and exposes a normalized feed to the destination plan. The same consumes-and-exposes pattern applies — the source payer’s FHIR endpoint is a consumed resource, the output is a governed FHIR Bundle.
Public reporting requires aggregating PA decision metrics into FHIR MeasureReport resources. A third capability spec consumes from the adjudication platform’s analytics API and exposes the reporting feed.
One rule. Three capability specs. Each one a governed, discoverable interface that AI agents can also consume — turning compliance infrastructure into AI-ready APIs at no additional cost.
The Naftiko Fleet Connection
The Naftiko Fleet is a collection of shared capability specifications for common enterprise integration patterns. Healthcare payers building CMS-0057-F compliance can use Fleet specs as starting points — the EDI clearinghouse consume pattern, the FHIR expose pattern, and the Da Vinci IG output projections are generalizable across plans.
The PA capability spec you write for your Medicare Advantage plan works with the same pattern for your Medicaid line. The Provider Access capability spec your FHIR team builds this year becomes the payer-to-payer exchange spec next year. Specification-driven integration compounds — each capability you define makes the next one faster to build and the whole portfolio easier to govern.
CMS-0057-F created the compliance requirement. Naftiko provides the specification layer that makes your X12 infrastructure FHIR-compliant without replacing it.
Learn more about capability-driven integration for healthcare compliance at naftiko.io. The Naftiko Fleet shared capability specifications are available at github.com/naftiko/fleet.
