972-836-7750 Request a demo Talk to an expert
Talk to an expert Request a demo Call sales 972-836-7750

X12 transaction guide · Healthcare and insurance

EDI 837 Health Care Claim

The X12 document healthcare providers use to submit claims and encounter information to payers, directly or through clearinghouses.

Sent by
Healthcare provider, billing service or clearinghouse
Received by
Health care payer
Standard
ANSI ASC X12

What is an EDI 837?

The EDI 837 Health Care Claim is the ANSI X12 transaction set providers use to submit health care claim billing information, encounter information, or both, to payers, either directly or through billing services and clearinghouses. It is also used between payers with different payment responsibilities when coordination of benefits is required.

In the United States, HIPAA adopts separate 837 implementation guides for professional claims (837P), institutional claims (837I) and dental claims (837D), each in version 5010. Payers acknowledge receipt and report claim status with other transactions, and pay with the 835.

How the EDI 837 worksDiagram of the EDI 837 Health Care Claim. Healthcare provider, billing service or clearinghouse sends it to health care payer. It usually follows 278. It is usually followed by 999, 277 and 835. Inside the ISA, GS and ST envelopes, X12 release 008010 requires, in the heading: BHT (Beginning of Hierarchical Transaction) and detail: the required 2000 loop with HL (Hierarchical Level). 3 optional loops are listed by their first segment.How the EDI 837 worksHealth Care Claim: who sends it, where it fits and what the standard marks required1 WHERE IT FITSUSUALLY FOLLOWS278Health Care ServicesReview InformationEDI 837SENDERHealthcare provider,billing service orclearinghouseRECEIVERHealth care payer997 or 999 acknowledgment back, if the partners agreeUSUALLY FOLLOWED BY999ImplementationAcknowledgment277Health Care InformationStatus Notification835Health Care ClaimPayment/Advice2 WHAT X12 RELEASE 008010 REQUIRESInterchange: sender and receiver IDsISA … IEAFunctional group, ID code HCGS … GETransaction set 837ST … SEHEADINGBHTBeginning of Hierarchical Transaction+ 1 optional loop, starting with:NM1DETAILRequired loop 2000 · repeats many timesHLHierarchical Level+ 2 optional loops, starting with:NM1CLMBlue box: required loop. Optional loops are listed by the segment that starts them; when a loop is used, that first segment is required. Optional segmentsoutside loops are not drawn.Structure: required segments and loops in the X12 008010 listing for the 837. Your trading partner's implementation guide adds its own requirements.
How the EDI 837 worksDiagram of the EDI 837 Health Care Claim. Healthcare provider, billing service or clearinghouse sends it to health care payer. It usually follows 278. It is usually followed by 999, 277 and 835. Inside the ISA, GS and ST envelopes, X12 release 008010 requires, in the heading: BHT (Beginning of Hierarchical Transaction) and detail: the required 2000 loop with HL (Hierarchical Level). 3 optional loops are listed by their first segment.How the EDI 837 worksHealth Care Claim: who sends it, where it fitsand what the standard marks required1 WHERE IT FITSUSUALLY FOLLOWS278Health Care Services ReviewInformationEDI 837SENDERHealthcareprovider, billingservice orclearinghouseRECEIVERHealth carepayer997 or 999 acknowledgment back, if the partnersagreeUSUALLY FOLLOWED BY999Implementation Acknowledgment277Health Care Information StatusNotification835Health Care Claim Payment/Advice2 WHAT X12 RELEASE 008010 REQUIRESInterchange: sender and receiver IDs (ISA… IEA)Functional group, ID code HC (GS … GE)Transaction set 837 (ST … SE)HEADINGBHTBeginning of HierarchicalTransaction+ 1 optional loop, starting with:NM1DETAILRequired loop 2000 · repeatsmany timesHLHierarchical Level+ 2 optional loops, starting with:NM1CLMBlue box: required loop. Optional loops are listedby the segment that starts them; when a loop isused, that first segment is required. Optionalsegments outside loops are not drawn.Structure: required segments and loops in the X12008010 listing for the 837. Your trading partner'simplementation guide adds its own requirements.

How to read this diagram: the top row shows who sends the 837, to whom, and which documents usually come before and after it. The lower part shows what X12 release 008010 itself requires: the envelopes around the 837 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.

Expand diagram Download SVG

When it is used

  • Submitting physician and professional claims (837P)
  • Submitting hospital and facility claims (837I)
  • Submitting dental claims (837D)
  • Coordinating benefits between payers

Where it fits in the document flow

Usually follows 278 Health Care Services Review Information
This document 837 Health Care Claim
Usually followed by 999 Implementation Acknowledgment277 Health Care Information Status Notification835 Health Care Claim Payment/Advice

Structure

Mandatory segments in the 837 (X12 release 008010)

The segments X12 release 008010 marks as mandatory at their level, in order. Segments inside optional loops are needed only when the loop is used. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, adds the optional segments it requires and restricts the values. The requirement status comes from one published X12 reference listing and has not been checked against a second source.

  • ST
  • BHT
  • NM1
  • HL
  • CLM
  • CR7
  • SBR
  • LX
  • LIN
  • SVD
  • LQ
  • FRM
  • SE

Practical example

The 837 in practice

A physical therapy practice completes a day of patient visits. Its practice management system creates an 837P batch with each patient, diagnosis codes, procedure codes and charges, and sends it through a clearinghouse. The payers acknowledge the batch, report accepted and rejected claims with 277s and later pay the accepted claims with 835s.

Implementation

Implementation considerations for the 837

  • Use the correct 837 variant and follow each payer's companion guide.
  • Validate patient, provider and coding data before submission to avoid rejections.
  • Track every claim from submission through acknowledgment, status and payment.

How ECOM helps

Automate the 837 with ECOM

Industry

Healthcare

Secure B2B integration and file transfer for providers, suppliers, distributors and healthcare partners.

Solution

EDI Integration

Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.

Service

Fully Managed EDI

ECOM operates your defined EDI services end to end under a service agreement.

More general questions about EDI are answered in the EDI FAQ.

Related transactions

Related healthcare and insurance documents

All 31 healthcare and insurance documents

Need help with the EDI 837?

ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.

Request a Demo Contact us