Mapping X12 278 to FHIR for the Prior Authorization API

The Prior Authorization API required by CMS-0057-F is built on the HL7 Da Vinci Prior Authorization Support (PAS) implementation guide. If your organisation already processes X12 278 requests, most of the business data exists. The work is reshaping it into a FHIR Claim bundle, and back again for the response. This guide walks through that mapping at the level an integration team needs.

The shape of a PAS request

A provider system sends a FHIR Bundle to [base]/Claim/$submit. The PAS specification sets a few firm rules:

• The bundle is JSON.
• The first entry is a Claim conforming to the PAS Claim profile, with use fixed to preauthorization and status fixed to active.
• Every resource the Claim references, directly or indirectly, is included in the bundle exactly once: Patient, Coverage, the insurer and requester Organizations, PractitionerRoles, ServiceRequests, Conditions and any supporting documents.
• Supporting information is linked from Claim.supportingInfo, each with a unique sequence. Attachments such as PDFs travel as DocumentReference.

The response is a bundle whose first entry is a ClaimResponse. Resources echoed from the request keep the same fullUrl and identifiers, which is how the client ties decisions back to the items it asked about.

Where the 278 loops land

The X12 278 request (version 5010, 005010X217) is organised in hierarchical loops. In PAS, those loops become references between resources:

A few element-level mappings that teams most often get wrong:

• Request category (UM01) sits on each item as the serviceItemRequestType extension, because PAS carries request details at item level.
• Certification type (UM02) maps to the item's certificationType extension.
• Level of service (UM06) maps to the Claim-level levelOfServiceType extension.
• Item trace number (2000F TRN) maps to the itemTraceNumber extension. Keep it stable: it is how a later status check or update finds the item.
• Diagnoses go in Claim.diagnosis, bound to the X12 278 diagnosis code set. Only the first 12 are sent in X12, so order them deliberately.
• Care team members beyond 14 at claim level, or 10 per item, are not carried into X12.

The response: approved, denied, modified or pended

Each decision comes back on the ClaimResponse as a review action code, which carries the X12 decision values. One value matters more than the rest: pended. It means the payer needs more time or more information, and the final answer will come later.

PAS expects synchronous answers where possible, within about 15 seconds end to end. For pended requests, implementers must support FHIR Subscriptions: the payer sends a notification that something changed, and the client then queries for the updated ClaimResponse. The baseline is id-only notifications, so no clinical data travels in the notification itself.

Status checks use the Claim inquiry operation, a query-by-example that must identify the patient, the requesting provider organisation and the payer.

Two architectures: intermediary or all-FHIR

With an intermediary. The provider sends FHIR. An intermediary such as a clearinghouse converts the bundle into one X12 278, plus X12 275 transactions for attachments, and sends them to the payer. The 278 response is converted back into a FHIR bundle. PAS treats everything past the $submit endpoint as a black box, so the conversion rules are the intermediary's responsibility, including terminology translation such as SNOMED CT to ICD-10.

All-FHIR. HHS has said it will not enforce the X12 278 requirement against covered entities that exchange prior authorization end to end through a FHIR Prior Authorization API under CMS-0057-F. For a payer building fresh, this avoids a second translation layer. For one with a mature 278 pipeline, mapping FHIR to your existing utilisation management system is usually faster.

Most payers will run both for some time, so design your internal model so that the same decision logic serves 278 and FHIR requests.

Traps that fail conformance tests

1. References that point outside the bundle. Every reference must resolve to an entry in the same bundle. This is the most common validation failure.
2. Duplicate resources. The same Practitioner included twice under different fullUrl values breaks matching on the response.
3. Unstable identifiers. If item trace numbers or Claim identifiers change between submit and inquiry, status checks fail.
4. Business errors returned as HTTP errors. Business rejections, the equivalent of X12 AAA segments, belong inside the response bundle. HTTP 4xx with an OperationOutcome is for requests that cannot be processed at all. HTTP 5xx means "try again later".
5. Ignoring the pended path. Teams often test approvals and denials but not pends, then discover subscriptions and inquiry late.

What to build first

If you are a payer working toward the January 2027 deadline:

1. Define the internal prior-auth record your UM system already uses and map it to the PAS Claim and ClaimResponse once. Both 278 and FHIR flows then reuse it.
2. Build $submit with synchronous approvals and denials.
3. Add the pended path with subscriptions and inquiry.
4. Add Coverage Requirements Discovery (CRD) and Documentation Templates and Rules (DTR). These let providers learn what is needed before they submit, which is where most of the time savings come from.

Check the version of the PAS guide your trading partners use. The examples here follow STU 2. A later version was in ballot at the time of writing.

Need help with the mapping? Our CMS-0057-F readiness service starts with a two-week gap report that covers your 278 data, your FHIR plan and the deadline.

Sources: Da Vinci PAS implementation guide, STU 2 and its specification page; CMS-0057-F final rule.

This article is general guidance, not legal advice.