EDI 837 – Healthcare Claim (X12 Version 5010)

What is the EDI 837 Healthcare Claim?

The EDI 837 Healthcare claim is the standardized X12 electronic transaction used by healthcare providers to submit medical billing information to insurance payers, clearinghouses, Medicare, and Medicaid programs. The transaction includes patient information, diagnosis codes, procedures performed, and billing charges required for claim adjudication and reimbursement.

Healthcare providers such as physicians, hospitals, pharmacies, laboratories, and clinics transmit the 837 transaction to insurance companies, health plans, Medicare, Medicaid programs, and managed care organizations. The transaction can also be exchanged between payers when coordination of benefits is required or when regulatory agencies monitor claims activity across healthcare networks.

Within modern healthcare ecosystems, the EDI 837 serves as the standard electronic replacement for paper claim forms, enabling automated claim submission, validation, adjudication, and payment workflows.

What Does the EDI 837 Do?

The purpose of the EDI 837 is to electronically transmit healthcare claim information from providers to insurance payers using a standardized format defined by the X12 format set by the HIPAA (Health Insurance Portability and Accountability Act) for electronic claim submissions. The 837 transaction enables automated claim validation, adjudication, and reimbursement across healthcare payer networks. 

The EDI 837 enables healthcare providers to transmit structured claim data that allows payers to determine (e.g., adjudicate) whether medical services are eligible for reimbursement. 

Structured claim data ensures that healthcare payers can process claims (e.g., adjudicate) and respond electronically without manual intervention, and in that manner, the 837 transaction supports several operational objectives:

Who Uses the EDI 837?

Healthcare providers including physicians, hospitals, laboratories, clinics, and billing services submit EDI 837 claims to insurance companies, government health programs, and managed care organizations. Claims are often transmitted through clearinghouses that validate the transaction format before forwarding the claim to the responsible payer.

Providers typically submit claims through clearinghouses, which validate transaction formatting and ensure compliance with payer requirements before forwarding the claims.

When Is the EDI 837 Required?

Electronic claims submission is required whenever providers transmit healthcare billing information to payers electronically. Healthcare providers frequently rely on the 837 transaction in the following situations:

• Medical treatment reimbursement requests
• Insurance billing for outpatient or inpatient services
• Pharmacy or laboratory claim submission
• Medicare or Medicaid reimbursement processing

Healthcare organizations that operate at scale rely on EDI 837 transactions to manage large volumes of claims across payer networks.

Is the EDI 837 Mandated Under Regulation?

The EDI 837 is mandated under the Health Insurance Portability and Accountability Act (HIPAA) for most healthcare providers when claims are submitted electronically to payers. While healthcare claims can still be filed manually, but the EDI 837 is effectively mandated for most providers under U.S. federal regulation. The nuance comes from HIPAA Administrative Simplification rules and specific exceptions. The EDI 837 format defined by the X12 standard serves as the HIPAA-approved transaction for healthcare claim submission. Compliance ensures interoperability across the healthcare industry while protecting patient data and enabling consistent claim adjudication workflows.

Is EDI 837 required by HIPAA?

Under HIPAA Administrative Simplification rules, healthcare claims transmitted electronically MUST use the X12 837 format. While providers may still submit paper claims in limited circumstances, the EDI 837 is the federally mandated standard for electronic healthcare claim submission in the United States.

How Does the EDI 837 Work in the Business Workflow?

A typical EDI 837 workflow begins when a healthcare provider submits a claim to a clearinghouse or payer. The claim is validated, processed, and adjudicated by the payer. Status responses may be returned using EDI 277 transactions, and payment details are transmitted through the EDI 835 remittance advice.

• Healthcare providers submit claims after services are rendered.
• Clearinghouses validate the claim structure and route the transaction to the payer responsible for reimbursement.
• The payer evaluates the claim against coverage rules and returns either payment or status information.

What transactions follow an EDI 837 claim?

After an EDI 837 claim is submitted, payers may return claim status information using the EDI 277 Claim Status Response and reimbursement details through the EDI 835 Health Care Claim Payment/Advice transaction. These transactions allow providers to track claim processing and reconcile payments.

Typical Healthcare Claims Workflow

Healthcare claims workflows often involve intermediaries such as Managed Care Organizations (MCOs) and clearinghouses. 

Upstream Transactions

Positioning the EDI 837 EDI at the center of the healthcare workflow, upstream transactions are those transactions that organizations use to collect records (e.g., data) and generate the EDI 837. The following upstream transactions typically precede the EDI 837, these transactions establish the initial commercial transaction and product shipment:

Eligibility verification transactions ensure the patient is covered before services are billed.

Downstream Transactions

Positioning the EDI 837 at the center of the lifecycle, downstream transactions respond to activity reported in the EDI 837 after claim submission, may confirm claim submission or make adjustments or payments to the claim submission.  The EDI 837 supports several downstream activities including transactions that support financial reconciliation and channel accounting in fact several response transactions may occur:

These transactions communicate claim acceptance, rejection, payment, or adjustment details.

End-to-End Workflow Example

The lifecycle of a healthcare claim typically follows a structured sequence:

• A patient receives treatment from a healthcare provider.
• The provider verifies eligibility through EDI 270/271 transactions.
• The provider generates a claim and submits an EDI 837 transaction.
• A clearinghouse validates the claim structure and payer requirements.
• The payer processes the claim and determines reimbursement eligibility.
• The payer sends payment details through an EDI 835 transaction.

Electronic workflows reduce processing time, improve accuracy, and support regulatory compliance.

Industry-Specific Workflow Variations

Different healthcare sectors implement the EDI 837 slightly differently depending on claim type, each variation relies on the same underlying X12 transaction structure.

Types of EDI 837 Claims

How Does PartnerLinQ Use the EDI 837?

PartnerLinQ enables healthcare providers, billing services, clearinghouses, and payers to exchange healthcare claims electronically using the EDI 837 Health Care Claim transaction. The platform supports secure, scalable submission of professional healthcare claims through clearinghouses and payer networks, ensuring providers meet payer requirements while maintaining compliance with Health Insurance Portability and Accountability Act (HIPAA) transaction standards.

The PartnerLinQ platform standardizes connectivity between healthcare providers and insurance organizations—including commercial insurers, Medicare, Medicaid, and state agencies—allowing claims to be transmitted, validated, and processed efficiently across multi-party healthcare ecosystems.

PartnerLinQ also supports the downstream reimbursement workflow by integrating with the EDI 835 Health Care Claim Payment/Advice, enabling automated remittance reporting and financial reconciliation once claims have been adjudicated.

From an operational perspective, PartnerLinQ functions as a claims execution layer that allows healthcare organizations to:

• Connect providers, clearinghouses, and payers through standardized EDI networks
• Orchestrate high-volume healthcare claim submission workflows
• Monitor transaction status and identify processing exceptions in real time
• Automate validation and routing across multiple trading partners
• Ensure secure, HIPAA-compliant healthcare data exchange

Through this approach, PartnerLinQ allows healthcare organizations to manage large volumes of claims with consistent governance, operational visibility, and reliable transaction execution across complex healthcare billing networks.

Where Is the EDI 837 Used?

Designed to be in compliance with and follow the X12 format set by the HIPAA (Health Insurance Portability and Accountability Act) the 837 transaction is common across multiple healthcare environments.

Healthcare networks rely on standardized EDI transactions to maintain interoperability across payer ecosystems. 

Who uses the EDI 837 transaction?

The EDI 837 is used by healthcare providers, hospitals, physician practices, laboratories, billing services, clearinghouses, insurance companies, Medicare, Medicaid programs, and managed care organizations. These organizations exchange healthcare claim information electronically to support reimbursement processing and regulatory reporting.

What Is the Purpose, Key Features, and Business Use Cases of the EDI 837?

Operational Purpose

The EDI 837 allows healthcare providers to electronically communicate claim data needed for reimbursement processing.

Key Features

Key capabilities of the EDI 837 include:

• Hierarchical data structures supporting complex claim relationships
• Detailed patient and subscriber identification
• Diagnosis and procedure coding
• Line-level billing and charge reporting
• Integration with eligibility and payment transactions

Business Use Cases

Industry Applications

Healthcare organizations use the 837 transaction across clinical and administrative workflows.

Operational Visibility

Electronic claim submission allows healthcare organizations to track claim status and payment outcomes.

Compliance Reporting

HIPAA-compliant claim reporting ensures regulatory alignment across payer networks.

Financial Reconciliation

The transaction enables accurate reimbursement and claim reconciliation.

Exception Management

Structured claim data enables automated validation and rejection handling.

What Information Is Required in the EDI 837?

The EDI 837 contains structured data segments that represent participants, medical services, and billing information.

Required Segments

What information is included in an EDI 837 claim?

An EDI 837 claim includes patient demographic information, subscriber insurance details, diagnosis codes, procedure codes, service dates, provider identifiers, and billing amounts. These data elements allow payers to evaluate whether healthcare services qualify for reimbursement under the patient’s insurance policy.

Optional Segments

Required Identifiers

Required Dates

Claim-Level vs Line-Level Detail

The 837 transaction supports both claim-level and service-line detail.

Service line data allows payers to adjudicate reimbursement at the procedure level.

Common Segments

Several segments appear frequently in the EDI 837 transaction structure.

What segments are used in the EDI 837?

Common EDI 837 segments include ST (Transaction Set Header), BHT (Beginning of Hierarchical Transaction), HL (Hierarchical Level), SBR (Subscriber Information), PAT (Patient Information), NM1 (Entity Identification), CLM (Claim Information), HI (Diagnosis Codes), SV1 (Service Line), and SE (Transaction Trailer).

These segments collectively define the claim and ensure that payers receive the information required to adjudicate reimbursement.

What segments are used in the EDI 837?

Common EDI 837 segments include ST (Transaction Header), BHT (Beginning of Hierarchical Transaction), HL (Hierarchical Level), SBR (Subscriber Information), PAT (Patient Information), NM1 (Entity Identification), CLM (Claim Information), HI (Diagnosis Codes), SV1 (Service Line), and SE (Transaction Trailer).

Summary Table of Key Segments

EDI 837 Segment-Level Example (Annotated)

The example below illustrates a simplified EDI 837 Professional Health Care Claim transaction. The sample demonstrates how key segments interact within the hierarchical claim structure used to transmit patient information, insurance details, diagnoses, and service billing data to a payer or clearinghouse.

* for illustrative purposes only (Not from a specific companion guide publication)

This example illustrates a common outpatient claim scenario in which a healthcare provider submits a claim for services rendered to a dependent patient under a subscriber’s insurance policy.

Segment-by-Segment Explanation

EDI 837 Hierarchical Loop Example

The EDI 837 uses the HL (Hierarchical Level) segment to organize claim data into a structured hierarchy. This hierarchy allows the transaction to represent relationships between information sources, subscribers, dependents, and service lines within a single claim submission.

Each HL segment defines a level of the hierarchy and identifies its parent-child relationship with other segments in the transaction.

Example Hierarchical Structure

The following simplified example illustrates the hierarchical relationship used in a typical EDI 837 claim.

HL*1**20*1~
NM1*PR*2*INSURANCE COMPANY*****PI*999996666~

HL*2*1*22*1~
SBR*P*18*******CI~
NM1*IL*1*SMITH*JOHN****MI*123456789~

HL*3*2*23*0~
PAT*19~
NM1*QC*1*SMITH*JANE~

HL*4*3*24*0~
LX*1~
SV1*HC:99213*100*UN*1***1~

* for illustrative purposes only (Not from a specific companion guide publication)

Hierarchical Loop Explanation

What Status and Reason Codes Are Used with the EDI 837?

Status Codes

Status codes typically appear in downstream transactions such as the EDI 277 Claim Status Response.

Reason Codes

Reason codes explain claim denials, adjustments, or corrections.

Industry-Specific Code Sets

Healthcare claims frequently reference external coding systems including:

What Are the Benefits of the EDI 837?

Operational Benefits

Electronic claim submission accelerates billing workflows and improves accuracy.

Financial Benefits

Automated claims reduce administrative costs and accelerate reimbursement.

Compliance Benefits

Standardized formats support HIPAA compliance and interoperability.

What Are the Benefits of Automating the EDI 837?

Automation enables healthcare organizations to:

• Reduce claim processing errors
• Accelerate reimbursement cycles
• Improve transaction visibility
• Reduce manual billing effort
• Improve payer communication

Are There Regulatory and Compliance Requirements for the EDI 837?

Yes, Organizations transmitting healthcare claim information electronically must comply with HIPAA requirements for data format, security, and privacy.  The nuance comes from HIPAA Administrative Simplification rules. 

While healthcare claims can still be filed manually, the EDI 837 is effectively mandated for most providers under U.S. federal regulation. The EDI 837 is effectively mandated under the Health Insurance Portability and Accountability Act (HIPAA) for most healthcare providers when claims are submitted electronically to payers 

The EDI 837 format defined by the X12 standard serves as the HIPAA-approved transaction for healthcare claim submission. Compliance ensures interoperability across the healthcare industry while protecting patient data and enabling consistent claim adjudication workflows.

EDI 837 Claim Types

EDI 837 Technical Structure, Format, and Versions

What version of the EDI 837 is used today?

The most widely implemented version of the EDI 837 in the United States is X12 Version 5010, which was mandated for Electronic claim submissions under HIPAA electronic transaction standards. Version 5010 introduced expanded healthcare data requirements and improved claim validation capabilities across healthcare payer systems. 

Hierarchical Loop Structure

The 837 transaction uses hierarchical loops to organize claim information, typical loop structure includes: 

These loops create a structured hierarchy linking payers, subscribers, patients, and services. 

File Format and Delimiters

Using the following Production Delimiters on all EDI transmissions sent to Vendors, Carriers, Trading and Solution partners will enable consistent EDI parsing across trading partners:

• Segment Separator – hex 15 (NAK) or hex 7E (~)
• Element separator – hex 7C (|) or hex 2A (*)
• Sub-element Separator – hex 3E (>)

Version Differences

The most widely implemented version of the healthcare claim transaction is X12 5010, which supports expanded data requirements and improved claim validation capabilities.

What are common challenges with EDI 837 claims?

Common EDI 837 claim challenges include missing patient identifiers, incorrect diagnosis codes, invalid provider identifiers, and payer-specific formatting rules defined in companion guides. These issues often cause claim rejections that must be corrected before the payer can adjudicate reimbursement.

Version or Companion Guide Constraints

Payers frequently impose additional rules through trading partner companion guides.

Jurisdiction-Specific Requirements

Government programs may impose additional claim reporting requirements.

Timing and Frequency Limitations

Claims may be rejected if submitted outside allowable billing windows.

Are Implementation Guidelines and Sample Files Available for the EDI 837?

Healthcare organizations rely on implementation guides and payer companion documents to configure EDI transactions.

These guides specify:

• Required segments
• Code value restrictions
• Payer-specific validation rules
• Claim submission policies

EDI 837 Example File (X12 Sample)

Example simplified EDI 837 structure:

ST*837*0001~
BHT*0019*00*0123*20260306*1200*CH~
HL*1**20*1~
NM1*41*2*PROVIDER CLINIC*****46*123456~
CLM*12345*250***11:B:1*Y*A*Y*I~
HI*BK:25000~
LX*1~
SV1*HC:99213*100*UN*1***1~
DTP*472*D8*20260306~
SE*12*0001~

This example illustrates the hierarchical structure of a healthcare claim submission.

What Are the More Common EDI Errors and Rejection Scenarios for the EDI 837?

Why do EDI 837 claims get rejected?

EDI 837 claims are commonly rejected due to missing patient identifiers, invalid diagnosis codes, incorrect provider identifiers, or payer-specific formatting rules defined in companion guides. Clearinghouses and payers validate claims before adjudication, and errors must be corrected before reimbursement processing can proceed.

Structural Errors (997 / 999)

Errors occur when transactions fail structural validation.

Data Validation Errors

Missing identifiers or invalid code values often trigger rejection.

Identifier Mismatch Errors

Provider or subscriber identifiers may not match payer records.

Version Compliance Errors

Incorrect implementation versions cause rejection.

Industry-Specific Rejections

Payers frequently reject claims due to incorrect diagnosis codes or missing authorization details.

What Are the Basic Questions for EDI Integration with the 837?

Organizations considering or implementing the EDI 837 typically evaluate:

1. What is the general direction of the transaction?
2. Are inbound or outbound orders required?
3. Are AS2, VAN, or SFTP connections used?
4. Are more than one trading partner exchanging the EDI 837?
5. Are there other interested parties?
6. Which trading partners require claim submission
7. What trading partner requirements apply?
8. Which clearinghouses process claims?
9. What companion guide rules apply?
10. What version is supported?
11. How will claim status monitoring be implemented?
12. What other transactions might these interested parties be a party to?
13. What response to the EDI 837 is expected or sent?
14. Is a response to EDI 837r a timed event?  Are notifications involved/needed?
15. Are there samples and specs of the response transaction available?
16. Are change orders supported?
17. What validation rules apply?
18. How are changes to the EDI 837 business message managed today?
19. Is there automation? (an internal systems trigger) or are EDI 837 business message transactions triggered manually?
20. Are responses and changes automatically triggered? (an internal systems trigger) Or do transactions require human intervention?
21. What systems generate or receive the transaction?
22. How are one-time addresses handled in ERP?
23. Are SKU or UPC identifiers used?
24. What identifiers are required (DEA, NDA, SKU, UPC, GTIN, GLN)?
25. What testing process is required?
26. What validation rules apply?

What Are the Best Practices for Using the EDI 837?

Best practices for healthcare claim processing include:

• Validate eligibility before claim submission

• Maintain accurate provider identifiers

• Implement automated error monitoring

• Align with payer companion guides

• Track claim status through the lifecycle

Healthcare Claim Lifecycle Using EDI Transactions

What Transactions Are Associated with the EDI 837?

Collectively, the transactions below support the full healthcare claim lifecycle.

Companion Transactions in the Healthcare EDI Workflow

Healthcare claim processing involves several standardized EDI transactions that work together to verify eligibility, submit claims, track status, and process payment

Frequently Asked Questions About the EDI 837

What is the EDI 837?

The EDI 837 Health Care Claim is the X12 electronic transaction used by healthcare providers to submit medical billing information to insurance payers, clearinghouses, Medicare, and Medicaid programs.

What does the EDI 837 contain?

The transaction contains patient demographics, subscriber insurance information, diagnosis codes, procedure codes, service dates, and billed charges used by payers to evaluate reimbursement eligibility.

Who sends the EDI 837?

Healthcare providers such as hospitals, physicians, clinics, laboratories, and billing services transmit EDI 837 claims to insurance companies and government healthcare programs.

EDI 837 Explained Simply

The EDI 837 is the electronic format used by healthcare providers to send medical bills to insurance companies. Instead of submitting paper claim forms, providers transmit structured electronic claim data that allows payers to automatically evaluate coverage and determine reimbursement.

Footnotes

1. PartnerLinQ, Inc. – EDI 837 Health Care Claim Implementation Specification (X12 Version 5010). Internal PartnerLinQ technical specification used for trading partner onboarding and EDI development:  Ref: PartnerLinQ 837 v5010 20260306
2. ANSI X12 Standards Committee. X12 Transaction Set 837 – Health Care Claim. Accredited Standards Committee X12 electronic data interchange standard defining the format and data content for healthcare claim transactions.
3. U.S. Department of Health and Human Services (HHS). HIPAA Administrative Simplification – Electronic Transaction Standards. Federal regulations mandating standardized electronic healthcare claim transactions.
4. Centers for Medicare & Medicaid Services (CMS). HIPAA EDI Standards Implementation Guidance for Health Care Claims (837). Regulatory guidance for healthcare claim submission and adjudication.