Understanding the **EDI 837 file format** is crucial for anyone involved in healthcare billing, from providers to clearinghouses. This comprehensive guide provides a detailed explanation of the **837 file structure**, covering essential **EDI 837 loops and segments**, and offering practical **EDI 837 file format examples**. We will demystify this complex electronic claim submission standard, helping you navigate its intricacies for efficient and accurate healthcare claims. Whether you’re looking for an **EDI 837 sample file** breakdown or a thorough explanation of **what is 837 file**, this post has you covered.
What is an EDI 837 File? Purpose and Importance
An **EDI 837 file** (Electronic Data Interchange Health Care Claim) is the standard electronic format used to submit healthcare claim information between a healthcare provider and a payer (like an insurance company). Governed by HIPAA (Health Insurance Portability and Accountability Act), the **837 file format** ensures a standardized, secure, and efficient way to process claims, reducing manual errors and accelerating reimbursement cycles. This electronic format replaces paper claim forms like the CMS-1500 (for professional claims) and UB-04 (for institutional claims). Understanding its structure, including various **837 loops and segments**, is vital for correct claim filing and minimizing rejections.
The Hierarchical Structure of an EDI 837 File
The **EDI 837 file format** follows a well-defined hierarchical structure, designed to organize complex claim data logically. This structure consists of multiple levels, each serving a specific purpose in the overall transaction set. Understanding these levels is key to comprehending any **EDI 837 sample file**.
- Interchange Control (ISA/IEA): The outermost envelope, identifying the sender and receiver of the entire electronic transmission.
- Functional Group (GS/GE): Contains one or more transaction sets of the same type. For an 837, this typically groups all healthcare claims within the interchange.
- Transaction Set (ST/SE): The actual **EDI 837 Healthcare Claim** transaction. Each ST/SE pair represents a single 837 transaction.
- Loops: Logical groupings of related segments that repeat as needed to convey information (e.g., patient information, subscriber information, claim details). Each loop has a unique ID (e.g., 1000A, 2000B, 2300).
- Segments: Individual lines of data within a loop, each starting with a unique two or three-character identifier (e.g., NM1, REF, SBR, AMT).
- Data Elements: Specific pieces of information within a segment, separated by delimiters.
Key EDI 837 Loops and Segments Explained
Here’s a breakdown of common and critical **837 loops and segments** you’ll encounter in an **EDI 837 file format example**:
Loop 1000A – Submitter Information
- NM1 – Submitter Name: Identifies the entity sending the claim file.
- NM109 – Submitter Identification Code: Contains the unique identifier for the submitter (e.g., a specific trading partner ID assigned by the payer). Many payers utilize a proprietary submitter code for identification. New trading partners typically work with the payer to establish this code prior to implementation.
Loop 2010AB – Pay-To Address Name
- This loop indicates the address where payment should be sent to the Billing Provider. Note that some payers may prioritize the address stored in their backend systems over the address submitted in 2010AB for payment purposes. Providers should verify payer-specific rules regarding this loop.
Loop 2000B – Subscriber Hierarchical Level
- SBR – Subscriber Hierarchical Level: Defines the hierarchical level for the subscriber, indicating their relationship to the policy.
- SBR01 – Payer Responsibility Sequence Number Code: This element is crucial in coordination of benefits (COB) scenarios. It’s not a simple counter but a code (e.g., ‘P’ for primary, ‘S’ for secondary) that signifies the order of responsibility for payment among multiple payers.
Loop 2010BA – Subscriber Name
- NM1 – Subscriber Name: Contains the full name of the subscriber (the policy holder).
- NM109 – Identification Code: Typically holds the subscriber’s unique Member ID assigned by the health plan. Some payers require all members (including dependents) to be treated as subscribers for identification purposes, with their member ID submitted in this element.
Loop 2010CA – Patient Name
- NM1 – Patient Name: Contains the patient’s name if they are different from the subscriber. A critical note from some payers: if the patient is also the subscriber, they may require that only the subscriber’s information (in Loop 2010BA) be submitted. Submitting redundant data in the Patient Loop (2010CA) when the patient is the subscriber can lead to claim rejection. Always refer to specific payer guidelines.
Loop 2300 – Claim Information
- REF – Payer Claim Control Number: Used for referencing an original claim number when submitting adjusted, voided, or replacement claims.
- REF02 – Reference Identification: This element holds the original claim number (or ICN) for adjustments or resubmissions. It works in conjunction with the Claim Frequency Type Code to indicate the claim’s status (e.g., replacement, void, appeal).
- HI01-2 – Occurrence Code: If the claim is related to an accident or employment, the appropriate occurrence code is required here.
- HI01-4 – Date Time Period: The corresponding date for the occurrence code.
Loop 2310E – Service Facility Location Name
- NM1 – Service Facility Location Name: Identifies the facility where services were rendered. For institutional claims, some payers require that the Service Facility Information match the Billing Provider Information, ensuring the payee aligns with the provider submitting the claim.
Loop 2320 – Other Subscriber Information (Coordination of Benefits)
- SBR – Other Subscriber Information: Provides details about other insurance coverage when Coordination of Benefits (COB) applies. This is critical for payers to determine their financial responsibility.
- AMT – COB Payer Paid Amount: Specifies the total amount paid by the other payer(s) at the claim level. This helps the current payer determine the remaining balance.
Loop 2330A – Other Subscriber Name
- NM1 – Other Subscriber Name: Identifies the subscriber under the other insurance plan for COB claims.
Loop 2330B – Other Payer Name
- NM1 – Other Payer Name: Identifies the other insurance company responsible for payment in a COB scenario. This segment is mandatory for COB claims by many payers.
Loop 2430 – Line Adjudication Information
- SVD – Line Adjudication Information: Provides details about how a specific service line was adjudicated by a prior payer in COB claims.
- SVD02 – Monetary Amount: The amount paid by the other payer for this specific service line. This corresponds to the information from Loop 2330B.
- CAS01 – Claim Adjustment Group Code: These codes explain why the billed amount was adjusted. Common codes include:
- CO – Contractual Obligations: Indicates adjustments based on provider contracts with the payer. Used to validate the total amount billed in the SV1 segment.
- PR – Patient Responsibility: Denotes amounts that are the patient’s responsibility, such as deductibles, copayments, or coinsurance. Also used to validate the total amount billed in the SV1 segment (if applicable).
Understanding EDI 837 Transaction Types: REF02 and Frequency Type
The **EDI 837 file format** supports various claim transaction types beyond initial submissions. The **REF02 (Reference Identification)** element within Loop 2300, combined with the claim’s Frequency Type Code, dictates the nature of the claim:
- Original Claims (Frequency Type 1): The first submission for a set of services. REF02 is typically not used here.
- Replacement Claims (Frequency Type 7): Used to correct and resubmit an existing claim. In this case, **REF02 must contain the original payer claim control number** (also known as the Internal Control Number or ICN).
- Void Claims (Frequency Type 8): Used to cancel a previously submitted claim. Similar to replacement claims, **REF02 must include the original payer claim control number**.
- Adjusted/Resubmitted Claims (Frequency Types 2, 3, 4, 5): These types may include claims for late charges, adjusted charges, or a changed payee. While not always mandatory, many payers strongly recommend or require sending the Original Reference Number (Claim Number) in REF02 for these frequency types to facilitate proper processing and linking to the initial claim.
Common Validation Rules and Rejection Reasons
Incorrect data submission within critical **837 loops and segments** is a frequent cause of claim rejections. Adhering to specific payer requirements, even those that deviate from general standards, is crucial. Here are some generalized examples of validation rules and potential rejection reasons:
- Patient Loop Data (2010CA): Many payers will reject claims if data is submitted in the Patient Loop (2010CA) when the patient is identical to the subscriber (Loop 2010BA). They often prefer only the subscriber’s details in such cases.
- Pay-To Address Discrepancies (2010AB): While the **EDI 837 file format** allows for a separate ‘Pay-To’ address, some payers will override this with the address in their internal provider database. Inconsistent information can lead to payment delays, even if not an outright rejection.
- Missing Original Reference Number (REF02): For replacement, void, or certain adjusted claims, failure to submit the original claim control number in REF02 will almost certainly result in rejection.
- Service Facility/Billing Provider Mismatch (2310E): For institutional claims, some payers require that the Service Facility (Loop 2310E) match the Billing Provider information. Mismatches can cause rejections.
- Incomplete COB Information (2320, 2330A, 2330B, 2430): For claims involving Coordination of Benefits, missing segments like Other Subscriber Information (SBR), Other Payer Paid Amount (AMT), Other Subscriber Name (NM1), or Other Payer Name (NM1) will lead to rejections as the payer cannot accurately determine their responsibility.
FAQ: EDI 837 File Format
What is an 837 file?
An **837 file** is a standard electronic transaction format under HIPAA used by healthcare providers to submit claims to insurance companies. It contains all the information typically found on a paper claim form, such as patient demographics, services rendered, diagnoses, and charges, organized into a structured electronic format using **837 loops and segments**.
Can you provide an 837 file example or snippet to illustrate the structure?
While a full **EDI 837 sample file** is extensive, here’s a simplified textual illustration of its hierarchical flow, focusing on the core concept of loops and segments:
ISA*00*…*ZZ*SUBMITTERID*ZZ*PAYERID*…*IEA*1*… (Interchange Control)
GS*HC*SUBMITTERAPP*…*GE*1*… (Functional Group)
ST*837*0001*…*SE*…*0001 (Transaction Set)
~Loop 1000A – Submitter Name~
NM1*41*2*SUBMITTER NAME*****46*SUBMITTERID~
~Loop 2000B – Subscriber Information~
SBR*P*1*…~ (Payer Responsibility)
~Loop 2010BA – Subscriber Name~
NM1*IL*1*DOE*JOHN***MI*…~
~Loop 2300 – Claim Information~
CLM*CLAIMID*100.00***11:B:1*Y*A*Y*…~
REF*87*ORIGINALCLAIMID~ (For Replacement/Void Claims)
~Loop 2400 – Service Line Information~
LX*1~
SV1*HC:99213*75.00*UN*1*…~
This snippet demonstrates how segments (like NM1, SBR, CLM, SV1) are nested within loops (1000A, 2000B, 2300, 2400), which are, in turn, part of the larger transaction and functional group. Each ‘~’ typically represents the end of an EDI segment.