X12 837 claims to FHIR Claim: loops, segments and a mapping that holds up

Direct answer

An X12 837 is the HIPAA-mandated electronic claim in the US, in version 005010: 837P for professional claims, 837I for institutional and 837D for dental. Its claim data lives in loop 2300 (CLM, HI) and its service lines in loop 2400 (SV1 or SV2, DTP). Each of these maps cleanly to a FHIR R4 Claim: CLM02 to Claim.total, HI to Claim.diagnosis, each 2400 line to Claim.item, and the SV107 pointers to Claim.item.diagnosisSequence. The adjudicated result (what an 835 remittance reports) belongs in ClaimResponse or ExplanationOfBenefit, not in Claim.

Which 837, which version

The HIPAA claims standard is in 45 CFR 162.1102. The regulation cites the May 2006 technical reports and their 2007 errata. Payer and Medicare companion guides expect the later June 2010 errata identifiers shown above, so that is what goes in the envelope.

Is a newer version coming? X12 asked NCVHS in 2022 to review the 008020 claim guides (837P 008020X323, 837I 008020X324). NCVHS recommended in June 2023 that HHS not proceed with rulemaking for claims and remittance, and X12 publicly disagreed. As of October 2026 there is no rule replacing 005010 for the 837. The section was amended in December 2024 and August 2025 to move retail pharmacy claims to NCPDP F6; the X12 837 citations stayed the same. Separately, CMS-0053-F (March 2026) adopted X12 275/277 version 6020 for claims attachments, with compliance by 26 May 2028.

Anatomy of an 837P

Three envelopes wrap every claim batch:

• ISA / IEA: interchange. ISA is fixed-width (106 characters including the terminator); ISA13 must equal IEA02.
• GS / GE: functional group. GS01 is HC for claims; GS06 must equal GE02.
• ST / SE: the transaction set. SE01 is the segment count from ST to SE inclusive.

Inside the transaction, hierarchical (HL) loops carry the parties:

A synthetic 837P with two service lines (fake NPI, fake member ID, no real patient):

ISA*00*          *00*          *ZZ*SUBMITTERID    *ZZ*RECEIVERID     *261005*1200*^*00501*000000101*1*T*:~
GS*HC*SUBMITTERID*RECEIVERID*20261005*1200*101*X*005010X222A1~
ST*837*0001*005010X222A1~
BHT*0019*00*BATCH0001*20261005*1200*CH~
NM1*41*2*EXAMPLE BILLING SERVICE*****46*SUB12345~
PER*IC*EDI DESK*TE*5555550100~
NM1*40*2*EXAMPLE PAYER*****46*PAYER01~
HL*1**20*1~
PRV*BI*PXC*207Q00000X~
NM1*85*2*EXAMPLE FAMILY CLINIC*****XX*1234567893~
N3*100 MAIN ST~
N4*ANYTOWN*NY*123451234~
REF*EI*123456789~
HL*2*1*22*0~
SBR*P*18*******CI~
NM1*IL*1*DOE*JANE****MI*XYZ123456789~
N3*1 TEST LANE~
N4*ANYTOWN*NY*12345~
DMG*D8*19800101*F~
NM1*PR*2*EXAMPLE PAYER*****PI*PAYER01~
CLM*PCN-0001*175***11:B:1*Y*A*Y*Y~
HI*ABK:E119*ABF:I10~
LX*1~
SV1*HC:99213*125*UN*1***1:2~
DTP*472*D8*20261001~
LX*2~
SV1*HC:83036*50*UN*1***1~
DTP*472*D8*20261001~
SE*27*0001~
GE*1*101~
IEA*1*000000101~

Reading the claim: SBR02 = 18 means the patient is the subscriber, so there is no 2000C loop. CLM05 = 11:B:1 is place of service 11 (office), qualifier B, frequency 1 (original claim). HI carries ICD-10-CM codes without the decimal point: ABK is the principal diagnosis, ABF an additional one. SV107 = 1:2 points the first line at both diagnoses.

The 837I differs in the places that hurt: CLM05 carries the facility type and frequency (the type of bill) instead of place of service, CL1 adds admission details, SV2 puts the revenue code first, and there is no line-level diagnosis pointer.

Mapping to FHIR R4 Claim

FHIR R4 Claim requires status, type, use, patient, created, provider, priority and at least one insurance. Most of these come straight from the 837.

The first line of the sample, as FHIR:

{
  "resourceType": "Claim",
  "id": "example-837p-pcn-0001",
  "identifier": [{ "system": "urn:example:patient-control-number", "value": "PCN-0001" }],
  "status": "active",
  "type": {
    "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/claim-type", "code": "professional" }]
  },
  "use": "claim",
  "patient": { "reference": "Patient/example-jane-doe" },
  "created": "2026-10-05T12:00:00Z",
  "provider": {
    "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "1234567893" }
  },
  "priority": {
    "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/processpriority", "code": "normal" }]
  },
  "diagnosis": [
    {
      "sequence": 1,
      "diagnosisCodeableConcept": {
        "coding": [{ "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "E11.9" }]
      }
    },
    {
      "sequence": 2,
      "diagnosisCodeableConcept": {
        "coding": [{ "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "I10" }]
      }
    }
  ],
  "insurance": [
    { "sequence": 1, "focal": true, "coverage": { "reference": "Coverage/example-xyz123456789" } }
  ],
  "item": [
    {
      "sequence": 1,
      "diagnosisSequence": [1, 2],
      "productOrService": {
        "coding": [{ "system": "http://www.ama-assn.org/go/cpt", "code": "99213" }]
      },
      "servicedDate": "2026-10-01",
      "locationCodeableConcept": {
        "coding": [
          {
            "system": "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set",
            "code": "11"
          }
        ]
      },
      "quantity": { "value": 1 },
      "net": { "value": 125.0, "currency": "USD" }
    }
  ],
  "total": { "value": 175.0, "currency": "USD" }
}

The second line (83036, 50.00, pointer 1) follows the same shape. The place of service system URI is the one the CARIN IG binds to; use it so downstream EOB profiles validate.

Claim, ClaimResponse or ExplanationOfBenefit?

• Claim is the request: what the provider billed. It maps from the 837.
• ClaimResponse is the payer's answer to a FHIR Claim. Prior authorization in Da Vinci PAS uses this pair.
• ExplanationOfBenefit (EOB) is the adjudicated claim as the payer recorded it: allowed, paid, patient responsibility, adjustment reasons. Its source is the payer's adjudication system, the same data that goes out in an 835 remittance (005010X221A1).

For US payer APIs, consumer-facing EOBs follow the CARIN Blue Button IG (2.2.0, published March 2026, FHIR R4). Da Vinci PDex (2.2.0, August 2026) covers claims-based information without financials, plus clinical data, for provider access and payer-to-payer exchange. CMS-0057-F generally requires the new Provider Access and Payer-to-Payer APIs from 1 January 2027; the Da Vinci prior authorization article covers the dates and payer types. On the clinical side, patients and conditions should conform to US Core.

A practical rule: if you are a provider-side integration converting outbound 837s, produce Claim. If you are a payer exposing history, produce EOB from adjudicated data. Do not try to build an EOB from an 837 alone; the 837 has no paid amounts.

Pitfalls that break claim pipelines

NPI versus taxonomy. The billing provider NPI is NM109 with qualifier XX; the taxonomy code is PRV03. They are different identifiers with different jobs. A Type 2 (organization) NPI in 2010AA with a rendering Type 1 NPI in 2310B is normal. Map NPIs to identifiers and taxonomy to careTeam.qualification or PractitionerRole specialty.

Diagnosis pointers. SV107 points to positions in the HI segment (up to 12 codes on an 837P, up to four pointers per line). Sort, deduplicate or merge diagnoses and every pointer is silently wrong. X12 confirms that not every HI code has to be pointed to. Preserve the original order and map it to diagnosis.sequence.

Decimal points. X12 carries ICD-10-CM without the dot, FHIR terminology expects it. Converting in one direction only produces codes that fail validation on the other side.

Place of service. CLM05-1 is the claim default; SV105 overrides one line. Resolve the effective value per line before mapping.

Units. SV103 UN (units) and MJ (minutes, common for anesthesia) look the same once converted to a bare number. Keep the unit.

Address rules. The 2010AA billing provider address needs a street address and a nine-digit ZIP code in 5010. Sources that store five-digit ZIPs fail at the clearinghouse.

Envelope control numbers. ISA13, GS06 and ST02 must be unique per your trading partner agreement and match their trailers. Regenerating them on retry can create a duplicate claim; reusing them can get a file rejected as a duplicate. Agree the policy with the clearinghouse and log control numbers against CLM01.

Acknowledgments are layered. A TA1 answers the interchange envelope, a 999 (005010X231A1) answers syntax and implementation guide compliance, and a 277CA (005010X214) accepts or rejects each claim. An accepted 999 does not mean the claim was accepted. Payment comes later, in the 835. Store each acknowledgment against the claim and surface 277CA rejections to the billing team.

PHI everywhere. An 837 is PHI end to end, including logs and dead-letter queues. The safeguards in HIPAA for healthcare integration apply to the EDI path as much as to FHIR APIs. If your team also handles clinical feeds, the segment-and-field habits from HL7 v2 sample messages transfer, but the X12 delimiter and envelope rules are stricter.

Build checklist

1. Pin the implementation guide per trading partner (005010X222A1 or 005010X223A2) and load the payer companion guide.
2. Parse envelopes, validate segment counts and control numbers before mapping.
3. Map 2300 and 2400 to Claim with the table above; restore ICD-10-CM decimals and keep HI order.
4. Validate the Claim against your target profile, not just base R4.
5. Wire TA1, 999 and 277CA handling, then 835 reconciliation if you own the revenue cycle.
6. Keep EOB generation on the payer side, from adjudicated data.

If you need an 837 pipeline, a FHIR Claim mapping, or EDI and FHIR running side by side in an EHR integration, see EHR and EMR integration.