Health Care Claim
The HIPAA X12 837 is the electronic claim a provider submits to a payer to request payment for services rendered (professional, institutional, or dental).
In this guide
837 Health Care Claim moves from Provider / Clearinghouse to Payer (Provider → Payer) via AS2, SFTP, API, Clearinghouse. The interactive diagram below traces every business and technical step the message passes through — press Play Flow to watch it travel, or click any step for detail.
How it works
How 837 Health Care Claim Works
Sender
Provider / Clearinghouse
Receiver
Payer
Direction
Provider → Payer
Standard
ANSI ASC X12
Version
(837I)
Transport
AS2 / SFTP / API / Clearinghouse
Business Purpose
Healthcare
Sender — Provider / Clearinghouse
EDI Transmission
837
Health Care Claim
ANSI ASC X12 005010X222A1 (837P) / X223A2 (837I)
Receiver — Payer
Related transaction flows
Need help understanding this EDI flow?
Ask EDI AI →837 Health Care Claim workflow. Steps: Document Encounter, Assemble Claim, Generate 837 EDI, Submit via Clearinghouse, Payer Receives Claim, Adjudicate, Return Status & Payment. Transmitted from Provider / Clearinghouse to Payer via AS2, SFTP, API, Clearinghouse, following ANSI ASC X12 005010X222A1 (837P) / X223A2 (837I).
Overview
Replaces the paper CMS-1500 / UB-04 claim forms with structured data, enabling automated claims intake and adjudication.
Sender
Provider / Clearinghouse
Receiver
Payer
Direction
Provider → Payer
Standard / Version
ANSI ASC X12 005010X222A1 (837P) / X223A2 (837I)
Segment structure
Key segments that make up this transaction set:
| Segment | Name | Purpose |
|---|---|---|
| BHT | Beginning of Hierarchical Transaction | Claim submission purpose and date. |
| NM1 | Individual or Organizational Name | Identifies billing provider, subscriber, and patient. |
| CLM | Health Claim | Claim identifier, total charge amount, and place of service. |
| HI | Health Care Information Codes | Diagnosis codes (ICD-10-CM). |
| SV1/SV2 | Professional/Institutional Service | Procedure code, charge, and units for each service line. |
Interactive example
Click any segment below to see its business meaning.
ST
This is an envelope or control segment. Select a highlighted segment on the left (shown in green) for a full business explanation.
View raw EDI
ST*837*0001*005010X222A1~
BHT*0019*00*CLM-556210*20230918*0800*CH~
NM1*41*2*Riverside Medical Group*****46*1932837465~
NM1*IL*1*DOE*JANE****MI*W123456789~
CLM*CLM-556210*550***11:B:1*Y*A*Y*Y~
HI*ABK:M54.5~
LX*1~
SV1*HC:99214*550*UN*1***1~
DTP*472*D8*20230918~
SE*10*0001~Mapping example
A representative field-level mapping from a common source system into this transaction:
| Source | Source Field | Target Field |
|---|---|---|
| EHR Encounter | encounter.diagnosis_codes[] | HI (Health Care Information Codes) |
| EHR Encounter | encounter.cpt_code | SV101-2 (Procedure Code) |
| EHR Encounter | encounter.charge_amount | SV102 (Line Item Charge Amount) |
Validation rules
- Every SV1/SV2 procedure code must link to at least one diagnosis pointer referencing a code present in the HI segment.
- Billing and rendering provider NPIs must be active and enrolled with the payer for the billed service date.
- CLM02 total charge must equal the sum of all service-line charge amounts.
Common errors & troubleshooting
Claim rejected at clearinghouse (front-end edit)
Cause: Diagnosis pointer on a service line references an HI position that doesn't exist.
Fix: Validate diagnosis pointers against the actual number of HI codes submitted before transmission.
Claim denied for 'provider not eligible'
Cause: Rendering provider's NPI wasn't credentialed with the payer as of the date of service.
Fix: Verify provider enrollment status with each payer before billing, especially for newly hired clinicians.
Frequently asked questions
837P is used for professional claims (physician office visits, outpatient services), while 837I is used for institutional claims (hospital, facility billing) and uses a different loop structure for revenue codes.
Still have questions about 837?
Ask EDI AI →