Loading...
Loading...
The organizational layout of every 837 electronic file follows a standard format. The format strategically places each control segment in a specific order because each control segment specifies the type of data that can be transmitted within that control segment. The control segment headers always identify when new segments of information are going to begin, while the control segment trailers always identify when the data within a control segment is finished. The diagram below details the standard format and placement of each control segment in an 837 electronic file.
Some of the actual data submitted in these control segments may be different depending on the type of 837 file, the type of information that the control segments specify are the same for each 837 file (Professional, Institutional, and ADA).
The Interchange Envelope contains the control data for the entire electronic file.
The ISA segment always begins an 837 electronic file. There is only one ISA segment in an 837 and the only type of data that can be transmitted is EDI control data. The EDI control data is required and includes the following:
| Data Type | Description | File Position |
|---|---|---|
| Authorization Information Qualifier | Identifies the type of information in the authorization information. This information is set up in the submitter profile. | ISA01 |
| Authorization Information | Additional identification or authorization information for the interchange sender or the data in the interchange. This information is set up in the submitter profile. | ISA02 |
| Security Information Qualifier | Code that identifies the type of information in the security information. This information is set up in the submitter profile. | ISA03 |
| Security Information | Identifies the security information about the interchange sender or the data in the interchange. This information is set up in the submitter profile. | ISA04 |
| Interchange ID Qualifier | Designates the system or method of code structure used to designate the sender or receiver ID element being qualified. This information is set up in the submitter profile. | ISA05 |
| Interchange Sender ID | Identification code used by the sender for other parties to use as the receiver ID to route data to them. This information is set up in the submitter profile. | ISA06 |
| Interchange ID Qualifier | Designates the system or method of code structure used to designate the sender or receiver ID element being qualified. This information is set up in the submitter profile. | ISA07 |
| Interchange Receiver ID | An identification code that is published by the receiver of the data. When sending data, the sender uses this ID as his/her sending ID to a receiver. When the receiver sends back to the sender, he/she uses this ID as the receiver ID. This information is set up in the submitter profile. | ISA08 |
| Interchange Date | Date the electronic file/interchange is sent. This information does not require any set up; it is automatically populated to the 837 file. | ISA09 |
| Interchange Time | Time of the interchange. This information does not require any setup; it is automatically populated to the 837 file. | ISA10 |
| Interchange Control Standards Identifier | Code identifying the agency responsible for the control standard used by the message that is enclosed in the interchange header and trailer. This information does not require any set up; it is automatically populated to the 837 file | ISA11 |
| Interchange Control Version Number | Number that covers the interchange control segments. This information does not require any set up; it is automatically populated to the 837 file. | ISA12 |
| Interchange Control Number | A control number assigned by the interchange sender. This information does not require any set up; it is automatically populated to the 837 file. | ISA13 |
| Acknowledgement Requested | Code sent by the sender requesting an Interchange Acknowledgement (TA1). This information is set up in the submitter profile. | ISA14 |
| Usage Indicator | Identifies to the receiver whether the data enclosed in the Interchange Envelope is test or production. This information does not require any set up; it is automatically populated to the 837 file. | ISA15 |
The IEA segment always ends an 837 electronic file. There is only one IEA segment in an 837 and the only type of data that can be transmitted is EDI control data. The EDI control data is required and includes the following:
| Data Type | Description | File Position |
|---|---|---|
| Number of Included Functional Groups | A sum of the number of functional groups included in the electronic file. This information does not require any set up; it is automatically calculated and populated to the 837 file. | IEA01 |
| Interchange Control Number | A control number assigned by the interchange sender. This control number must match the control number in the ISA Segment. This information does not require any set up; it is automatically populated to the 837 file. | IEA02 |
The Functional Groups contain the control data for the transaction sets (ST/SE segments) that are imbedded in the Functional Group Control Segments (GS/GE). There can be multiple Functional Groups within the electronic file and they always fall between the ISA/IEA segments.
The GS segment always begins a Functional Group Control Segment. There can be multiple GS segments in an 837 file. However, a GS segment is always followed by its associated GE segment before another GS segment can start. The only types of data that can be transmitted in a GS segment are identifiers that define the type of transaction sets (ST/SE) that are included within the functional group. This data is required and includes the following:
| Data Type | Description | File Position |
|---|---|---|
| Functional Identifier Code | Code that identifies a group of related transaction sets. This information does not require any set up; it is automatically populated to the 837 file. | GS01 |
| Application Sender’s Code | Code that identifies the entity sending the transmission. This code is agreed on with the trading partner. This information is set up in the submitter profile. | GS02 |
| Application Receiver’s Code | Code that identifies the entity receiving the transmission. This code is agreed on with the trading partner. This information is set up in the submitter profile. | GS03 |
| Date | The date the functional group was created. This information does not require any set up; it is automatically populated to the 837 file. | GS04 |
| Time | The time the functional group was created. This information does not require any set up; it is automatically populated to the 837 file. | GS05 |
| Group Control Number | A number that is assigned and maintained by the sender. This number must be the same as the Group Control Number in the GE segment (GE02). This information does not require any set up; it is automatically populated to the 837 file. | GS06 |
| Responsible Agency Code | Code that identifies the issuer of the standard. This information does not require any set up; it is automatically populated to the 837 file. | GS07 |
| Version / Release / Industry Identifier Code | Code identifying the version, release, sub release, and industry identifier of the EDI standard being used. This information does not require any set up; it is automatically populated to the 837 file. | GS08 |
The GE segment, which indicates the end of the functional group, always follows the final transaction set (ST/SE) that is imbedded in the functional group. The only type of data that can be transmitted in this segment includes:
| Data Type | Description | File Position |
|---|---|---|
| Number of Transaction Sets Included | A sum of the number of transaction sets (ST/SE segments) that are included in the Functional Group Control Segment transmission. This information does not require any set up; it is automatically calculated and populated to the 837 file. | GE01 |
| Group Control Number | A number that is assigned and maintained by the sender. This number must be the same as the Group Control Number in the GS segment (GS06). This information does not require any set up; it is automatically populated to the 837 file. | GE02 |
The Transaction Sets contain the control data for the Loop Control Segments (LS/SE segments) that are imbedded in the Transaction Sets Control Segments (ST/SE). There can be multiple Transaction Sets within the electronic file and they will always fall between the GS/GE Functional Group Control Segments.
The ST segment always indicates the start of a transaction set. There can be multiple ST segments in an 837 file. However, each ST segment will always end with its associated SE segment before another ST segment can start. The ST segment and its data are required. The only type of data that can be transmitted in this segment includes:
| Data Type | Description | File Position |
|---|---|---|
| Transaction Set Identifier Code | Code that uniquely identifies a transaction set. This information does not require any set up; it is automatically populated to the 837 file. | ST01 |
| Transaction Set Control Number | Identifying control number that is unique within the transaction set functional group. This information does not require any set up; it is automatically populated to the 837 file. | ST02 |
In addition to these data elements, each ST segment in the 837 file must include two unique data segments: Beginning of Hierarchical Transaction (BHT) and Transmission Type Identification (REF).
The BHT segment is used to define the business hierarchical structure of the transaction set (ST/SE segment).
| Data Type | Description | File Position |
|---|---|---|
| Hierarchical Structure Code | Code that defines the hierarchical structure of the transaction set, for example, information source, subscriber, dependent, etc. This information does not require any set up; it is automatically populated to the 837 file. | BHT01 |
| Transaction Set Purpose Code | Code that identifies the purpose of the transaction set, for example, an original transmission or the re-submission of a transmission. This information is set up in the submitter profile. | BHT02 |
| Reference Identification | A number that can be assigned by the sender/originator of the file to define the transaction set. Typically, this number acts as a batch control number. This information is set up in the submitter profile. | BHT03 |
| Date | The transaction set creation date. This information does not require any set up; it is automatically populated to the 837 file. | BHT04 |
| Time | The transaction set creation time. This information does not require any set up; it is automatically populated to the 837 file. | BHT05 |
| Transaction Type Code | Code that specifies the type of transaction being submitted: for example, CH is generally used for claims and RP is used for encounters. However, if the ST/SE segment contains both claims and encounters, then use CH. This information is set up in the submitter profile. | BHT06 |
The REF segment is used to specify identifying information, which includes:
| Data Type | Description | File Position |
|---|---|---|
| Reference Identification Qualifier | Code that qualifies the Reference Identification. This information does not require any set up; it is automatically populated to the 837 file. | REF01 |
| Reference Identification | A reference identification that defines the type of transaction being transmitted. For example, if the transaction is a test transmission, then the reference identification will be 004010X098D for HCFA claim forms, 004010X097D for ADA claim forms, and 004010X096D for UB92 claim forms. However, if the transaction set is production, then the reference identification will be 004010X098 for HCFA claim forms, 004010X097 for ADA claim forms, and 004010X096 for UB92 claim forms. This information is set up on the 837 Electronic File Creation window. | REF02 |
The SE segment, which indicates the end of the transaction set, always follows the final Loop Control Segment (LS/LE) that is imbedded in the transaction set. The only type of data that can be transmitted in this segment includes:
| Data Type | Description | File Position |
|---|---|---|
| Number of Included Segments | The sum of the number of transaction sets (ST/SE segments) that are included in the transaction set. This information does not require any set up; it is automatically calculated and populated to the 837 file. | SE01 |
| Transaction Control Number | A number that is assigned and maintained by the sender. This number must be the same as the Transaction Set Control Number in the ST segment (ST02). This information does not require any set up; it is automatically populated to the 837 file. | SE02 |
The Loop Control Segments contain the data that identify the specific claim information. The Loop data segments that are imbedded within a transaction set (ST/SE) have been standardized with a name and a number (for example, 1000A Submitter Information and 1000B Receiver Information).
In addition, within these loop data segments there are data elements that are used to specify the same type of information within different loops. These elements have specific naming conventions which signify the type of information they define (for example, the element NM1 always specifies Individual or Organizational Name and PER is always Administrative Communications Contact Information, regardless of the segments they are used in).
The first table below outlines the repeating elements and defines the type of information they specify, while the second table outlines each loop data segment and the elements that are associated with the loop.
| Element Name | Description |
|---|---|
| AMT | Monetary Amount |
| CAS | Claims Adjustment |
| CLM | Health Claim (identifies data about the claim) |
| DMG | Demographic Information |
| DTP | Date or Time or Period |
| HI | Health Care Information Codes |
| HL | Hierarchical Level (identifies levels of detailed information using a hierarchical structure, such as relating dependents to a subscriber) |
| LX | Assigned Number (this element specifically specifies service lines in Loop 2400 Service Line) |
| N2 | Additional Name Information |
| N3 | Address Information (street address) |
| N4 | Geographic Location (city, state, and zip code) |
| NM1 | Individual or Organizational Name |
| NTE | Note/Special Instructions (identifies when notes or special instructions are being sent in the 837 file) |
| PAT | Patient Information (identifies information relating to the patient) |
| PER | Administrative Communications Contact Information (identifies a person or office to where communications should be directed) |
| PRV | Provider Information (specifies the identifying characteristics of a provider) |
| PWK | Paperwork (indicates supporting information for a claim, if not being sent in the 837 ST/SE segment) |
| REF | Reference Identification (specifies identifying information) |
| SBR | Subscriber Information (identifies information relating to the subscriber) |
| SV1 | Professional Service (claim service detail for a health care professional) |
The loop data segments that are outlined in this table are the loops that are required to be in the 837 electronic file. There are more loops than are listed here; however, they are not required and are dependent upon the nature of the claim/encounter. Non-required loop data segments are automatically included in the 837 by the application when necessary.
| Loop Number and Name | Associated Elements |
|---|---|
| 1000A Submitter Name | NM1, N2, PER |
| 1000B Receiver Name | NM1, N2 |
| 2000A Billing/Pay-To Provider Hierarchical Level | HL, PRV |
| 2010AA Billing Provider Name | NM1, N2, N3, N4 |
| 2000B Subscriber Hierarchical Level | HL, SBR, PAT |
| 2010BA Subscriber Name | NM1, N2, N3, N4, DMG |
| 2010BB Payer Name | NM1, N2, N3, N4 |
| 2300 Claim Level Information | CLM, DTP, AMT |
| 2400 Service Line | LX, SV1 |