FHIR PAS to X12 278 Mapping Guide

Try the PAS → 278 Converter

The Pipeline

FHIR Claim
     ↓
DSL Mapping Engine
     ↓
RMap Canonical Model
     ↓
X12 278 Request

Providers submit prior authorization requests using FHIR bundles. Payers must translate those bundles into X12 278 transactions before processing them in existing authorization systems.

Step 1: Understand the FHIR PAS Bundle Structure

A Da Vinci PAS request is a FHIR Bundle containing a primary Claim resource plus supporting resources referenced by the Claim:

Bundle (type: transaction)
 └── Claim (primary resource)
 │    └── identifier          → Transaction ID
 │    └── created             → Request date/time
 │    └── type                → professional / institutional
 │    └── use                 → preauthorization
 │    └── insurer             → Reference → Organization
 │    └── provider            → Reference → Practitioner
 │    └── patient             → Reference → Patient
 │    └── insurance[0]        → Reference → Coverage
 │    └── careTeam[]          → Provider references + roles
 │    └── diagnosis[]         → Reference → Condition
 │    └── item[]              → Service lines (procedure, quantity, dates)
 │    ┌── extension[]         → requestType, certificationType, serviceType
 │
 └── Organization (insurer)
 └── Practitioner (provider)
 └── Patient (subscriber)
 └── Coverage (insurance info)
 ┌── Condition (diagnosis)

The key challenge: FHIR uses references between resources. The Claim doesn’t contain the patient’s name directly — it contains "patient": {"reference": "Patient/acc6cdd8-..."} which points to a separate Patient resource in the bundle.

Any FHIR-to-X12 mapping engine must resolve references before it can populate X12 segments.

Step 2: Understand the X12 278 Request Structure

The X12 278 prior authorization request maps to these loops and segments:

Step 3: Map the Core Fields

Transaction Identification

FHIR input:

{
  "identifier": [{"value": "A12345"}],
  "created": "2005-05-02T11:01:00Z"
}

X12 output:

BHT*0007*RU*A12345*20050502*1101~

Insurer (UMO) — Reference Resolution

The insurer is not stored inline. The Claim references an Organization:

FHIR input:

// Claim
"insurer": {"reference": "Organization/8e377d0c-..."}

// Referenced Organization
{
  "resourceType": "Organization",
  "name": "MARYLAND CAPITAL INSURANCE COMPANY",
  "identifier": [{"value": "789312"}]
}

The mapping engine must:

1. Follow the reference from Claim.insurer
2. Find the Organization in the bundle
3. Extract name and identifier[0].value

X12 output:

NM1*X3*2*MARYLAND CAPITAL INSURANCE COMPANY*****46*789312~

The X3 qualifier identifies this as the UMO (Utilization Management Organization). 46 indicates an ETIN (Electronic Transmitter Identification Number).

Provider (Requester) — Reference Resolution

Same pattern — the Claim references a Practitioner:

FHIR input:

// Claim
"provider": {"reference": "Practitioner/b8ec2ff5-..."}

// Referenced Practitioner
{
  "resourceType": "Practitioner",
  "name": [{"family": "GARDENER", "given": ["JAMES"]}],
  "identifier": [{"system": "http://hl7.org/fhir/sid/us-npi", "value": "8189991234"}]
}

X12 output:

NM1*SJ*1*GARDENER*JAMES****24*8189991234~

SJ = Submitting Provider. 1 = Person. 24 identifies the provider identifier type (commonly used for NPI in healthcare transactions).

Subscriber — Demographics from Patient Reference

FHIR input:

// Claim
"patient": {"reference": "Patient/acc6cdd8-..."}

// Referenced Patient
{
  "resourceType": "Patient",
  "name": [{"family": "SMITH", "given": ["JOE"]}],
  "identifier": [{"value": "12345678901"}]
}

X12 output:

NM1*IL*1*SMITH*JOE****MI*12345678901~
DMG*D8*19670101*M~

IL = Insured or Subscriber. MI = Member Identification Number.

Step 4: Map Extensions (The PAS-Specific Part)

Da Vinci PAS uses FHIR extensions for fields that don’t exist in base FHIR. These map to the X12 UM segment:

FHIR input:

"extension": [
  {
    "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-requestType",
    "valueCodeableConcept": {
      "coding": [{"code": "SC"}]
    }
  },
  {
    "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-certificationType",
    "valueCodeableConcept": {
      "coding": [{"code": "I"}]
    }
  },
  {
    "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceType",
    "valueCodeableConcept": {
      "coding": [{"code": "3"}]
    }
  }
]

X12 output:

UM*SC*I*3~

Without extensions, the mapping engine must fall back to code mappings. For example, if requestType is absent, the engine maps Claim.type.coding[0].code:

professional → SC
institutional → HS
pharmacy → AR

Step 5: Map Repeating Structures (Loops)

Diagnoses

FHIR stores diagnoses as references to Condition resources:

FHIR input:

"diagnosis": [
  {
    "diagnosisReference": {"reference": "Condition/409cda2e-..."},
    "sequence": 1
  }
]

// Referenced Condition
{
  "resourceType": "Condition",
  "code": {
    "coding": [{"code": "41090", "system": "http://hl7.org/fhir/sid/icd-9-cm"}]
  }
}

The coding system determines the X12 qualifier:

X12 output:

HI*BF:41090~

Service Lines

Each Claim.item[] entry becomes a service line:

FHIR input:

"item": [
  {
    "productOrService": {
      "coding": [{"code": "99213", "system": "http://www.ama-assn.org/go/cpt"}]
    },
    "quantity": {"value": 1},
    "unitPrice": {"value": 25.00}
  }
]

X12 output:

SV1*HC:99213*25*UN*1~

The procedure qualifier is derived from the coding system:

Step 6: The Provider Identity Problem

This is where most PAS implementations get stuck.

The careTeam[] array references providers by role. But each reference points to a Practitioner (or PractitionerRole, which chains further to Practitioner and Organization). The mapping engine must:

1. Iterate over careTeam[]
2. Follow each provider.reference
3. Determine entity type (person vs. organization)
4. Extract name, NPI, and role qualifier

FHIR input:

"careTeam": [
  {
    "provider": {"reference": "Practitioner/b8ec2ff5-..."},
    "role": {"coding": [{"code": "primary"}]},
    "sequence": 1
  }
]

X12 output (one NM1 per careTeam entry):

NM1*SJ*1*GARDENER*JAMES****24*8189991234~

For 278 responses, the provider chain gets even more complex — the authorized provider may come from a PractitionerRole resource, requiring the engine to follow .practitioner and .organization chains before it can extract the NM1 fields.

Step 7: Putting It All Together

Combining these mappings produces the following complete X12 278 request from the FHIR PAS bundle shown above:

ISA*00*          *00*          *ZZ*789312         *ZZ*8189991234     *050502*1101*^*00501*000000001*1*T*:~
GS*HI*789312*8189991234*20050502*1101*000000001*X*005010X217~
ST*278*0001*005010X217~
BHT*0007*RU*A12345*20050502*1101~
UM*SC*I*3~
NM1*X3*2*MARYLAND CAPITAL INSURANCE COMPANY*****46*789312~
NM1*SJ*1*GARDENER*JAMES****24*8189991234~
NM1*IL*1*SMITH*JOE****MI*12345678901~
HI*BF:41090~
SV1*HC:99213*25*UN*1~
SE*10*0001~
GE*1*000000001~
IEA*1*000000001~

In this example, each output field traces back to a specific FHIR resource and path.

Visualize the Mapping

Seeing the mapping as a diagram makes the relationship between FHIR fields, mapping rules, and X12 output much clearer.

The Redix DSL Mapping Viewer shows the first half of the pipeline — the FHIR-to-RMap mapping — interactively:

• Left panel: FHIR resource tree (Claim, Patient, Organization, etc.)
• Center: Connection lines between source and target fields
• Right panel: RMap segments with X12 loop annotations
• Click any segment to see the DSL mapping rule and an example value trace

The viewer covers the FHIR → RMap stage of the pipeline. The second stage — RMap → X12 278 — is handled by the IFD/OFD engine, which uses the same canonical model to generate the final X12 output. Together, the two stages produce the complete FHIR PAS to X12 278 conversion shown in this article.

Why an Intermediate Representation Matters

Direct FHIR-to-X12 mapping seems straightforward, but at scale it creates a maintenance problem. If you support multiple FHIR profiles and multiple X12 transaction types, the number of mappings grows as N × M.

The Redix approach uses a canonical intermediate model (RMap):

FHIR Claim
    ↓  (DSL mapping)
RMap Canonical Model
    ↓  (IFD/OFD engine)
X12 278

Instead of writing a separate mapping for every format pair, the mapping is written once in each direction: FHIR → RMap, and RMap → X12. This reduces mapping complexity from N × M to N + M. Each new FHIR profile needs one mapping to RMap. Each new X12 format needs one mapping from RMap. The intermediate layer stays stable even as FHIR versions and X12 implementation guides evolve.

Frequently Asked Questions