837 EDI Professional Claim (Anthem) Structure Descriptions
837 EDI Professional Claim Structure guidelines given below refer to the 837 EDI Professional Claim used in electronic data interchange by Anthem and its business partners taking part in the process of claims exchange. To avoid mistakes during 837 EDI Professional Claim preparation and electronic submission partners should carefully study technical requirements for 837 transaction.
837 EDI Professional Claim Header
The 837 Claim Header identifies the start of a transaction, the specific transaction set, and its business purpose. Also, when a transaction set uses a hierarchical data structure, a data element in the header, BHT01 (Hierarchical Structure Code) relates the type of business data expected within each level.
837 EDI Professional Claim Detail
The 837 Detail level has a hierarchical level (HL) structure based on the participants involved in the transaction. The three levels for the participant levels include:
- Information Source (Billing/Pay-to Provider)
- Subscriber (Can be the Patient when the Patient is the Subscriber)
- Dependent (Patient when the Patient is not the Subscriber)
837 Claim Detail: Billing/Pay-to Provider Hierarchical Level. The first hierarchical level (HL) of the 837 Claim Detail, Billing/Pay-to Provider HL, identifies the original entity who submitted the electronic claim to the destination payer.
837 Claim Detail Subscriber Hierarchical Level. The second hierarchical level (HL) of the 837 Detail is the Subscriber HL. It is strongly recommended that each interchange (ISA-IEA envelope) be limited to 3000 claims for processing efficiency.
837 Claim Detail Patient Hierarchical Level . The third hierarchical level (HL) of the 837 Claim Detail is the Patient HL. It is strongly recommended that each interchange (ISA-IEA envelope) be limited to 3000 claims for processing efficiency.
837 EDI Professional Claim Enveloping
EDI envelopes control and track communications between partners and Anthem. One envelope may contain many transaction sets grouped into functional groups. The envelope consists of the following:
- Interchange Control Header (ISA)
- Functional Group Header (GS)
- Functional Group Trailer (GE)
- Interchange Control Trailer (IEA)
837 Envelope Control Segments – Inbound
837 Health Care Claim Interchange Control Header (ISA)
The ISA segment is the beginning, outermost envelope of the interchange control structure. Containing authorization and security information, it clearly identifies the sender, receiver, date, time, and interchange control number. Anthem requests all data in the ISA-IEA segment to be entered in UPPER CASE.
837 Health Care Claim Functional Group Header (GS)
The GS segment identifi es the collection of transaction sets that are included within the functional group. More specifically, the GS segment identifies the functional control group, sender, receiver, date, time, group control number and version/release/industry code for the transaction sets. Anthem requests that all data in the GS-GE segment be entered in UPPERCASE.
Transactions must be batched in separate functional group by Application Receiver’s Code (GS03).
Group Control Number (GS06) may not be duplicated by submitter. Files containing duplicate or previously received group control numbers will be rejected.
837 Health Care Claim Functional Group Trailer (GE)
The GE segment indicates the end of the functional group and provides control information.
837 Health Care Claim Interchange Control Trailer (IEA)
The IEA segment is the ending, outermost level of the interchange control structure. It indicates and verifies the number of functional groups included within the interchange and the interchange control number (the same number indicated in the ISA segment).