EDI 837 File Format: A Complete Guide to Loops, Segments, and Examples

Meta Description: Master the EDI 837 transaction with our complete guide. Learn about 837 claim file loops, segments, and examples, including where the revenue code goes, the SBR segment, and how to troubleshoot common denials. Optimize your electronic claim submissions today!

EDI 837 File Format: A Complete Guide to Loops, Segments, and Examples

Understanding the 837 transaction is paramount for any healthcare organization aiming for efficient and accurate electronic claim submission. This comprehensive guide will demystify the intricate structure of the EDI 837 file format, breaking down its essential components – loops and segments – to empower your billing team with the knowledge needed to navigate the complexities of electronic data interchange (EDI). From the foundational elements of an 837 claim file to specific segment details like the edi 837 sbr segment and how to find the nm109 segment in 837, we’ll provide a deep dive into the architecture that underpins virtually every medical claim submitted in the United States. By the end of this guide, you’ll have a clear understanding of in healthcare electronic claim submission what are loops and segments, how to interpret an 837 edi file loop format, and practical insights into optimizing your billing processes.

Quick Reference Guide

Navigating the 837 format can be daunting without a quick reference. This table provides a snapshot of critical loops and segments, offering a rapid lookup for common data points within an edi 837 example.

Loop/Segment	Description	Key Data Elements	Purpose
ISA Segment	Interchange Control Header	Authorization Info, Interchange ID, Date/Time	Defines the sender and receiver of the entire EDI transmission.
GS Segment	Functional Group Header	Functional ID Code, Sender/Receiver Code, Date/Time	Identifies the functional group (e.g., 837 transaction) within the interchange.
ST Segment	Transaction Set Header	Transaction Set ID (837), Transaction Set Control Number	Marks the beginning of a single 837 claim file.
Loop 1000A	Submitter Name	NM1 (Name), PER (Contact Info)	Identifies the entity submitting the claim.
Loop 1000B	Receiver Name	NM1 (Name)	Identifies the payer receiving the claim.
Loop 2000A	Billing Provider Hierarchical Level	HL (Hierarchical Level), PRV (Provider Info)	Defines the billing provider’s role and basic information.
Loop 2010AA	Billing Provider Name	NM1 (Name), N3 (Address), N4 (City/State/Zip), REF (Tax ID)	Detailed information about the billing provider.
Loop 2000B	Subscriber Hierarchical Level	HL (Hierarchical Level), SBR (Subscriber Info)	Defines the subscriber’s role and basic insurance information.
Loop 2010BA	Subscriber Name	NM1 (Name), N3 (Address), N4 (City/State/Zip), DMG (Demographics), REF (Member ID)	Detailed information about the insurance subscriber.
Loop 2000C	Patient Hierarchical Level	HL (Hierarchical Level), PAT (Patient Info)	Defines the patient’s role if different from the subscriber.
Loop 2010CA	Patient Name	NM1 (Name), N3 (Address), N4 (City/State/Zip), DMG (Demographics)	Detailed information about the patient.
Loop 2300	Claim Information	CLM (Claim Info), DTP (Service Dates), REF (Prior Auth), K3 (File Info)	Contains overall claim data, including total charges and dates.
Loop 2310B	Rendering Provider Name	NM1 (Name), PRV (Provider Info)	Identifies the provider who actually performed the service.
Loop 2400	Service Line	LX (Line Number), SV1 (Service Line Info), DTP (Service Dates), REF (NDC)	Details for each individual service or procedure performed.
SV1 Segment	Professional Service	Procedure Code, Modifiers, Billed Amount, Quantity, Place of Service	Core data for professional service lines.
SV2 Segment	Institutional Service	Revenue Code, HCPCS, Billed Amount, Quantity, Service Date	Core data for institutional service lines.

Detailed Breakdown

The EDI 837 file format is a hierarchical structure, much like a tree, where information is organized into logical groupings. To truly understand in healthcare electronic claim submission what are loops and segments, we must dissect this structure. Loops are repeating blocks of related segments, and segments are individual lines of data, each containing specific data elements. This hierarchical arrangement allows for efficient and standardized communication between providers, payers, and clearinghouses. (Image Suggestion: A diagram illustrating the hierarchical structure of an 837 file, showing ISA -> GS -> ST -> Loops (1000A, 2000A, 2000B, 2300, 2400) and their nested segments.)

The Envelope: ISA, GS, and ST Segments

Every 837 transaction begins with a series of “envelope” segments that define the transmission itself.

ISA Segment: Interchange Control Header

The ISA segment is the outermost envelope, identifying the sender and receiver of the entire interchange. It’s like the mailing label on a package. It contains information such as the interchange sender ID (ISA06), receiver ID (ISA08), and the date and time of creation. This segment is crucial for routing the 837 claim file to the correct destination.

GS Segment: Functional Group Header

Nested within the ISA, the GS segment identifies a functional group of transaction sets. For medical claims, the functional ID code (GS01) will typically be “HC” for healthcare claims. It also contains sender and receiver application codes (GS02, GS03) and a functional group date and time.

ST Segment: Transaction Set Header

The ST segment marks the beginning of a single 837 transaction (a single claim or batch of claims). The transaction set identifier code (ST01) for a healthcare claim is always “837”. This segment also includes a unique transaction set control number (ST02) that links it to the SE (Transaction Set Trailer) segment at the end of the claim.

The Information Hub: Loops and Their Segments

The core of the 837 edi file loop format lies in its loops, which group related information.

Loop 1000A: Submitter Name

This loop identifies the entity that is physically sending the 837 claim file. This could be the provider’s billing office, a third-party billing service, or a clearinghouse.

NM1 Segment (Submitter Name): Contains the name (NM103) and identification code (NM109) of the submitter. The NM109 is often the submitter’s Tax ID or a specific identifier assigned by the payer.

PER Segment (Submitter Contact Information): Provides contact details for the submitter, including name, telephone number, and email.

Loop 1000B: Receiver Name

This loop identifies the entity that is receiving the 837 transaction, typically the payer or a clearinghouse acting on behalf of the payer.

NM1 Segment (Receiver Name): Contains the name (NM103) and identification code (NM109) of the receiver. The NM109 here is usually the payer’s NAIC code or a specific payer ID.

Loop 2000A: Billing Provider Hierarchical Level

This loop establishes the billing provider’s role within the claim.

HL Segment (Hierarchical Level): Defines the hierarchical level (e.g., “20” for billing provider) and indicates if this is the highest level in the hierarchy.

PRV Segment (Billing Provider Specialty Information): Specifies the billing provider’s specialty code (PRV03).

Loop 2010AA: Billing Provider Name

This loop provides detailed information about the billing provider. This is the entity (individual or organization) that is submitting the bill for services.

NM1 Segment (Billing Provider Name): Contains the billing provider’s name (NM103) and NPI (NM109). This is a critical segment, and knowing how to find nm109 segment in 837 for the billing provider is essential for correct claim processing.

N3 Segment (Billing Provider Address): The street address of the billing provider.

N4 Segment (Billing Provider City, State, Zip): The city, state, and zip code.

REF Segment (Billing Provider Tax Identification Number): The billing provider’s federal tax ID (REF02).

PER Segment (Billing Provider Contact Information): Contact details for the billing provider.

Loop 2000B: Subscriber Hierarchical Level

This loop identifies the insurance subscriber (the policyholder).

HL Segment (Hierarchical Level): Defines the subscriber’s hierarchical level (e.g., “22”).

SBR Segment (Subscriber Information): The edi 837 sbr segment is crucial. It contains the payer responsibility sequence number (SBR01, e.g., “P” for primary, “S” for secondary), the individual relationship code to the subscriber (SBR02, e.g., “18” for self), and the group policy number (SBR03). This segment tells the payer about the subscriber’s relationship to the policy and the order of benefits.

Loop 2010BA: Subscriber Name

This loop provides detailed information about the insurance subscriber.

NM1 Segment (Subscriber Name): Contains the subscriber’s name (NM103) and member ID (NM109).

N3 Segment (Subscriber Address): The subscriber’s street address.

N4 Segment (Subscriber City, State, Zip): The city, state, and zip code.

DMG Segment (Subscriber Demographics): Includes date of birth (DMG01) and gender (DMG02).

REF Segment (Subscriber Policy Number): Often repeats the member ID or provides an alternative policy number.

Loop 2000C: Patient Hierarchical Level (If different from Subscriber)

If the patient receiving services is not the subscriber (e.g., a child on a parent’s policy), this loop is used.

HL Segment (Hierarchical Level): Defines the patient’s hierarchical level (e.g., “23”).

PAT Segment (Patient Information): Contains the patient’s relationship to the subscriber (PAT01, e.g., “01” for spouse, “19” for child).

Loop 2010CA: Patient Name (If different from Subscriber)

Detailed information about the patient.

NM1 Segment (Patient Name): Contains the patient’s name (NM103).

N3 Segment (Patient Address): The patient’s street address.

N4 Segment (Patient City, State, Zip): The city, state, and zip code.

DMG Segment (Patient Demographics): Includes date of birth (DMG01) and gender (DMG02).

Loop 2300: Claim Information

This is a critical loop that contains overall information pertaining to the entire claim.

CLM Segment (Claim Information): The heart of the claim. It includes the patient account number (CLM01), total claim charge (CLM02), claim frequency code (CLM05-3, e.g., “1” for original, “7” for replacement), and other claim-level details.

DTP Segment (Claim Date): Specifies various dates related to the claim, such as admission date, discharge date, or statement period start/end dates.

REF Segment (Claim Level Reference Information): Used for prior authorization numbers (REF02 with REF01=”G1″), referral numbers, or other claim-specific identifiers.

K3 Segment (File Information): Can be used to transmit medical record attachments or other supplemental information.

NTE Segment (Claim Note): Allows for free-form text notes relevant to the entire claim.

Loop 2310B: Rendering Provider Name

This loop identifies the individual provider who actually performed the service.

NM1 Segment (Rendering Provider Name): Contains the rendering provider’s name (NM103) and NPI (NM109).

PRV Segment (Rendering Provider Specialty Information): Specifies the rendering provider’s specialty code.

Loop 2400: Service Line

This is a repeating loop, with one instance for each service or procedure performed. This is where the granular details of the services are provided.

LX Segment (Service Line Number): A sequential number for each service line.

SV1 Segment (Professional Service): For professional claims (837P). This segment details the procedure code (SV101-1), modifiers (SV101-2, SV101-3), billed amount (SV102), units (SV104), and place of service (SV105).

SV2 Segment (Institutional Service): For institutional claims (837I). This is where does the rev code go in and 837 file. The revenue code is found in SV201. It also includes the HCPCS/CPT code (SV202-1), billed amount (SV203), and units (SV204).

DTP Segment (Service Line Date): Specifies the date(s) of service for that particular line item.

REF Segment (Service Line Reference Information): Used for National Drug Codes (NDC) for drugs administered (REF02 with REF01=”G2″), or other line-item specific identifiers.

NTE Segment (Service Line Note): Allows for free-form text notes relevant to a specific service line.

(Image Suggestion: A simplified 837 text snippet showing a few key segments and data elements, perhaps highlighting an NM109, SBR, and SV1/SV2 segment.)

The End: SE, GE, and IEA Segments

Just as there’s an opening envelope, there’s a closing one.

SE Segment: Transaction Set Trailer

This segment marks the end of a single 837 transaction. It contains the total number of segments in the transaction set (SE01) and the transaction set control number (SE02), which must match the ST02.

GE Segment: Functional Group Trailer

This segment marks the end of a functional group. It contains the number of transaction sets included in the functional group (GE01) and the functional group control number (GE02), which must match the GS06.

IEA Segment: Interchange Control Trailer

This segment marks the end of the entire interchange. It contains the number of functional groups included in the interchange (IEA01) and the interchange control number (IEA02), which must match the ISA13.

Real-World Billing Scenarios & Patient Status Changes

Understanding the 837 format in theory is one thing; applying it to real-world scenarios is another. Here’s how specific patient statuses and billing situations translate into the 837 claim file.

Scenario 1: Standard Outpatient Visit (Professional Claim – 837P)

Patient Status: Active, insured, seen for a routine check-up.

Key 837 Elements:

Loop 2000B (Subscriber): HL segment indicates subscriber.

Loop 2010BA (Subscriber Name): NM1 contains subscriber’s name and member ID. DMG contains demographics.

Loop 2000C (Patient): Omitted if patient is the subscriber. If patient is dependent, HL indicates patient, and PAT segment shows relationship (e.g., “19” for child).

Loop 2010CA (Patient Name): If patient is dependent, NM1 contains patient’s name, DMG contains demographics.

Loop 2300 (Claim Information): CLM segment includes total charges, claim frequency code “1” (original).

Loop 2400 (Service Line): LX segment for each service. SV1 segment details CPT code, modifiers, units, and billed amount. DTP segment for date of service.

Scenario 2: Hospital Inpatient Stay (Institutional Claim – 837I)

Patient Status: Admitted to the hospital for several days.

Key 837 Elements:

Loop 2300 (Claim Information):

CLM segment will include the total charges for the inpatient stay.

DTP segments will be crucial: one for admission date (DTP435), and another for discharge date (DTP*096).

K3 segment might be used to reference medical records if required by the payer.

Loop 2400 (Service Line):

Each LX segment will represent a service line.

SV2 segment: This is critical for institutional claims. This is where does the rev code go in and 837 file. Each SV2 segment will contain a revenue code (SV201), a HCPCS/CPT code (if applicable, SV202-1), the billed amount (SV203), and units (SV204). For example, a room and board charge would have a specific revenue code, while a lab test would have another.

DTP segment for the specific service date if different from the overall claim dates.

Scenario 3: Secondary Claim Submission

Patient Status: Has primary and secondary insurance. Primary has processed the claim, now submitting to secondary.

Key 837 Elements:

Loop 2000B (Subscriber Hierarchical Level): This loop will appear twice.

First instance: HL for primary subscriber, SBR segment with SBR01=”P” (Primary).

Second instance: HL for secondary subscriber, SBR segment with SBR01=”S” (Secondary).

Loop 2300 (Claim Information):

CLM segment will include the claim frequency code “1” (original) for the secondary submission.

Other Payer Information (Loop 2320): This crucial loop will contain details about the primary payer’s payment.

AMT Segment: Shows the amount paid by the primary payer (AMTD).

DMG Segment: Details the primary payer’s adjustment reason codes (CARC/RARC).

REF Segment: Includes the primary payer’s claim adjustment group code (e.g., CO, OA, PR).

Loop 2400 (Service Line):

Each service line (LX) will have an ADJ segment (Adjustment) detailing the primary payer’s adjustments for that specific line item, including CARC/RARC codes.

Scenario 4: Corrected/Replacement Claim

Patient Status: Original claim submitted with an error, needs correction.

Key 837 Elements:

Loop 2300 (Claim Information):

CLM segment: The claim frequency code (CLM05-3) must be “7” (Replacement of Prior Claim) or “8” (Void/Cancel of Prior Claim).

REF segment: A REFF8 segment will contain the original claim number assigned by the payer, allowing them to link the corrected claim to the previous submission. This is vital for proper processing.

Common Denial Codes & Step-by-Step Appeal Instructions

Even with a perfectly structured EDI 837 file, denials can occur. Understanding common denial codes and having a clear appeal process is crucial for maintaining a healthy revenue cycle. We’ll reference CARC (Claim Adjustment Reason Code) and RARC (Remittance Advice Remark Code) which are standard codes used by payers to explain claim adjustments and denials.

Common Denial Reasons Related to 837 Structure

1. Missing/Invalid Subscriber ID (CARC CO-16):

Description: “Claim/service lacks information which is needed for adjudication.” Often due to an incorrect or missing member ID in the NM109 segment in 837 for the subscriber (Loop 2010BA).

Troubleshooting: Verify the subscriber’s member ID directly with the patient and/or the payer. Ensure it’s accurately entered in the NM109.

Appeal Steps:

1. Identify Error: Locate the incorrect NM109 in your practice management system and the 837 file. 2. Correct Data: Update the subscriber ID in your system. 3. Resubmit: Create a new 837 transaction with claim frequency code “7” (replacement) and include the original claim number in a REF*F8 segment in Loop 2300. Attach documentation if the payer requires proof of the correct ID. 2. Missing/Invalid Provider NPI (CARC CO-16, M86):

Description: “Missing/incomplete/invalid rendering provider primary identifier.” The NPI (National Provider Identifier) for the billing or rendering provider is incorrect or absent. This typically relates to the NM109 segment in 837 for Loop 2010AA (Billing Provider) or Loop 2310B (Rendering Provider).

Troubleshooting: Confirm the NPI with the provider’s credentialing records and the NPPES NPI Registry.

Appeal Steps:

1. Identify Error: Verify the NPI in the relevant NM109 segment. 2. Correct Data: Update the NPI in your system. 3. Resubmit: Submit a corrected claim (frequency code “7”) with the accurate NPI. 3. Service Not Covered (CARC CO-16, N57):

Description: “Service not covered by this payer/plan.” While not strictly an 837 format error, it can be triggered by incorrect coding or missing authorization.

Troubleshooting: Review the patient’s eligibility and benefits. Check if the service requires prior authorization. Ensure the procedure code (SV101-1 or SV202-1) is appropriate for the diagnosis.

Appeal Steps:

1. Verify Coverage: Re-check patient benefits and medical necessity guidelines. 2. Gather Documentation: Collect medical records supporting the medical necessity of the service. If prior authorization was obtained, include the authorization number in a REF*G1 segment in Loop 2300. 3. Write Appeal Letter: Clearly state why the service is medically necessary and covered, referencing policy language if possible. 4. Submit Appeal: Send the appeal letter, supporting documentation, and a copy of the original claim (or a corrected claim if a minor error was found) to the payer’s appeals department. 4. Duplicate Claim (CARC CO-18):

Description: “Duplicate claim/service.” Occurs when the payer receives what appears to be the same claim multiple times.

Troubleshooting: Often happens when a claim is resubmitted without changing the claim frequency code (CLM05-3) from “1” (original) to “7” (replacement) or “8” (void/cancel) when appropriate.

Appeal Steps:

1. Review Submission History: Check your practice management system and clearinghouse reports to confirm if a duplicate was sent. 2. Identify Original Claim: If a correction was intended, ensure the original claim number was included in REF*F8 in Loop 2300 of the “replacement” claim. 3. Resubmit (if necessary): If the original claim was truly lost and the resubmission was not a duplicate, contact the payer to confirm they did not receive the first. If they did, and you need to make a correction, ensure the frequency code and original claim number are correct. If it was a true duplicate, no appeal is needed, but process improvement is. 5. Missing Prior Authorization (CARC CO-16, RARC N286):

Description: “Missing or invalid prior authorization.” The service required pre-approval, but the authorization number was not included or was incorrect.

Troubleshooting: Ensure the prior authorization number is correctly entered in a REFG1 segment in Loop 2300. Verify the authorization covers the specific services and dates.

Appeal Steps:

1. Verify Authorization: Confirm the authorization number and its validity with the payer. 2. Correct Claim: If the number was simply missing or incorrect, resubmit a corrected claim (frequency code “7”) with the accurate REF*G1 segment. 3. Appeal with Documentation: If the authorization was obtained but the payer denies it, submit an appeal with a copy of the authorization approval and supporting medical records.

General Appeal Best Practices

Timeliness: Adhere to payer-specific appeal deadlines.

Documentation: Always provide clear, concise, and relevant supporting documentation (medical records, authorization letters, explanation of benefits from other payers).

Tracking: Keep detailed records of all appeals, including submission dates, reference numbers, and communication with the payer.

Internal Links: For more in-depth strategies on preventing denials, refer to [our guide on claim scrubbing] and [our article on mastering the revenue cycle].

Mastering the 837 transaction is an ongoing process that requires attention to detail, continuous learning, and robust internal processes. By understanding the intricate 837 file format, including its loops and segments, and proactively addressing common denial reasons, your organization can significantly improve its claim submission accuracy, accelerate reimbursements, and maintain a healthy financial outlook.

FAQ: Common Questions Answered

What is an 837 file?

An EDI 837 file is the standardized electronic transaction set used in the United States healthcare system for submitting medical claims to payers. Mandated by HIPAA, it replaces traditional paper claim forms like the CMS-1500 (for professional services) and the UB-04 (for institutional services). At its core, an 837 file is a highly structured digital document, composed of intricate loops and segments, each designed to convey specific pieces of information—from patient demographics and provider details to diagnoses, procedures, and charges. It’s the digital blueprint that enables healthcare organizations to communicate billing information efficiently and accurately with insurance companies, streamlining the reimbursement process and minimizing manual errors.

Can you provide an 837 file example or snippet to illustrate the structure?

While a full 837 file is a long string of alphanumeric characters, its structure is hierarchical and logical. Imagine it as a nested series of envelopes and letters. A simplified conceptual snippet illustrating the beginning of a claim might look like this, referencing the segments discussed in the article:

ISA00...GSHC...ST8370001~
BHT001900*...~
NM1412SUBMITTING PROVIDER NAME46*1234567890~
PERICCONTACT PERSONTE5551234567~
... (further loops for patient, subscriber, claim details)

Here, the ISA segment acts as the outermost envelope, identifying the sender and receiver of the entire transmission. The GS segment specifies the functional group (e.g., all 837 claims within this interchange). The ST segment marks the beginning of a single 837 claim. Within the claim, Loop 1000A (Submitter Name) would contain segments like NM1 for the submitter’s name and PER for their contact information. Each segment is a line of data, and the tilde (~) typically signifies the end of a segment, while asterisks (*) separate individual data elements within that segment. This structured approach ensures that every piece of information is precisely placed and understood by the receiving system.

What are the different types of EDI 837 transactions (Professional, Institutional, Dental)?

The EDI 837 transaction set is versatile and tailored to different types of healthcare services, primarily categorized into three main types:

• 837P (Professional): This is used by physicians, clinics, and other non-institutional providers to bill for professional services. It corresponds to the information typically found on a CMS-1500 paper claim form, covering services like office visits, surgeries, and diagnostic tests.
• 837I (Institutional): This type is used by hospitals, skilled nursing facilities, and other institutional providers to bill for facility-based services. It corresponds to the information found on a UB-04 paper claim form, covering inpatient stays, outpatient hospital services, and emergency room visits.
• 837D (Dental): Specifically designed for dental providers, this transaction set is used to submit claims for dental services, aligning with the information on an ADA (American Dental Association) claim form.

Each type contains specific loops and segments relevant to its respective service category, ensuring that the appropriate clinical and billing data is transmitted for accurate processing and reimbursement.

In healthcare electronic claim submission, what are loops and segments?

Loops and segments are the fundamental building blocks of an EDI 837 file, providing its hierarchical and structured format. Think of them as the chapters and paragraphs of a very detailed digital book:

• Segments:

External Resources & Authority Links

• For more detailed insights, refer to the CMS guidelines.
• For more detailed insights, refer to the AMA CPT coding resources.