The core mappings are 837 to Claim, 835 to ClaimResponse plus PaymentReconciliation, 270/271 to CoverageEligibilityRequest and CoverageEligibilityResponse, 278 to the Da Vinci PAS profiles, and 834 to Coverage plus Patient. The mappings are structurally reliable but semantically lossy in both directions: X12 carries positional, loop-scoped context and payer-specific companion-guide conventions that have no FHIR equivalent, while FHIR expects resolvable references to resources that an EDI transaction only names by identifier.
Guide
Detailed walkthrough
The transaction-to-resource map
Start here, then expect to negotiate the details per trading partner:
276 / 277 → Task or ClaimResponse status, depending on the implementation guide
278 → Da Vinci PAS Claim and ClaimResponse profiles
834 → Coverage, Patient, and RelatedPerson
820 → PaymentNotice and PaymentReconciliation
Where the models genuinely disagree
These are the recurring points where a naive mapping loses meaning:
Loop context: X12 derives meaning from position inside 2000/2300/2400 loops; FHIR requires that context to become explicit references
Repeating identifiers: X12 allows qualifier-keyed repetition that collapses ambiguously into FHIR identifier arrays
Adjustment reasons: CAS group codes plus CARC and RARC have no single FHIR analogue and typically land in ClaimResponse.adjudication with coded extensions
Dates: X12 date qualifiers carry semantics that FHIR expresses through different elements per resource
Companion-guide conventions: payer-specific usage of NTE, REF, and K3 segments has no standard target at all
Round-tripping is the hard requirement
Most real programs need to convert FHIR back to X12 because the downstream adjudication or UM system still speaks EDI. That makes lossy mapping unacceptable. The workable pattern is to preserve the original transaction — or a faithful structured representation of it — alongside the FHIR projection, and to treat the FHIR resource as a view rather than the system of record.
Validation on both sides
Validate the X12 against the implementation guide and the trading partner's companion guide, and validate the FHIR against the applicable profile — US Core, CARIN, or Da Vinci. A payload can be perfectly valid X12 and produce a FHIR resource that fails profile validation on a required element the EDI never carried. Catch that at the boundary, not in the partner's inbox.
Do not persist what you do not need
A mapping layer is a natural place for PHI to accumulate — in staging tables, error queues, and debug logs. Design for zero retention: transform in flight, keep only non-identifying metadata for observability, and make error payloads redacted by default rather than by exception.
How BCP helps
BCP builds and operates the mapping layer as a transaction service. We implement the profile-level mapping, the round-trip path back to X12, dual-sided validation, and observability that proves throughput and error rates without storing PHI — so both the EDI and FHIR sides of the organization can move at their own pace.
Disclaimer: BCP provides technology consulting and implementation support. Regulatory obligations should be reviewed with qualified legal and compliance advisors.
No. X12 remains the mandated HIPAA transaction standard for claims, remittance, eligibility, and prior authorization. FHIR is being layered on top for API-based access — CMS-0057-F's Prior Authorization API, for example, wraps the X12 278 inside the Da Vinci PAS profiles. Plan for both to coexist indefinitely.
Is X12 to FHIR mapping lossless?
Not in either direction without deliberate design. X12 carries loop-positional context and payer companion-guide conventions with no standard FHIR target, and FHIR expects resolvable references that EDI only identifies by number. Preserve the original transaction alongside the FHIR projection when round-tripping matters.
What FHIR version should we target?
FHIR R4, and specifically the profiles named by the relevant implementation guide — US Core for clinical and demographic data, CARIN Blue Button for claims exposed to members, and Da Vinci CRD/DTR/PAS for prior authorization. Targeting base R4 without profiles produces resources that pass generic validation and fail partner conformance testing.
Related resources
More on interoperability & integration
Guides, definitions, and long-form analysis that go deeper on this topic.
Tell us what you are trying to connect, modernize, automate, or govern. BCP will help identify the fastest practical path from fragmented systems to trusted, compliance-aware operations.