Overview
The 837 file is the electronic data interchange format standardized by the Accredited Standards Committee X12N, mandated under HIPAA for electronic healthcare claim submission. It replaced paper CMS-1500 (professional) and UB-04 (institutional) forms for electronic submission and is the de facto standard for claim transport between providers, clearinghouses, and payers across the United States.
The 837 has three variants corresponding to the paper forms it replaced: 837P (professional, equivalent to CMS-1500), 837I (institutional, equivalent to UB-04), and 837D (dental). Each variant has its own Implementation Guide — formally the ASC X12N Technical Report Type 3 (TR3) — that specifies mandatory loops, segments, and elements. Current versions are TR3 837 5010. A migration to 7030 has been under ongoing regulatory consideration but is not yet mandated.
Structurally, an 837 file is a hierarchy of loops — ISA/GS envelopes, then header loops describing the submitter, receiver, billing provider, and subscriber, then encounter loops containing service lines. Each service line carries CPT/HCPCS, ICD-10 diagnoses, service dates, charge amounts, modifiers, and rendering provider NPIs. A single 837 file can contain thousands of claims, each with dozens of service lines, so the file can run megabytes and tens of thousands of lines of EDI syntax.
Claim generation is a software function. The practice management system or hospital information system produces 837 output from its internal charge tables, encounter data, and payer rules. A clearinghouse then validates the file against payer companion guides, corrects obvious errors, and routes to the correct payer. Payers respond with 277CA (claim acknowledgment), 999 (functional acknowledgment), 835 (remittance advice), and eventually 276/277 (claim status).
Operational pain points with 837 files cluster in three areas. Format conformance — every payer has subtle companion-guide variations beyond the TR3 baseline, and missing one causes rejections. Data completeness — the 837 requires billing taxonomy, NPI, and subscriber information that must be collected and kept current. Code alignment — CPT, HCPCS, ICD-10, modifier combinations must match payer edit rules, or the claim rejects before adjudication. Each of these is a RCM operational discipline in its own right.
In day-to-day revenue-cycle operations, 837 File (Healthcare Claim) is most useful as a diagnostic — a sudden move in 837 File (Healthcare Claim) almost always points upstream to a front-end workflow that has drifted: eligibility coverage, scheduling, registration, charge capture, or coding turnaround. Reviewers on this site therefore pair every 837 File (Healthcare Claim) reading with era 835 and clearinghouse in the same weekly dashboard view, so the story a single metric tells cannot hide a broader pattern. The most common mistake teams make with 837 File (Healthcare Claim) is reacting to the headline number rather than decomposing it by payer, provider, and specialty; once the outlier segments are visible, the remediation step is usually obvious and cheap.
Industry benchmark
ASC X12N TR3 837 5010. CAQH CORE Committee operating rules for electronic claim submission. Clean-claim rate benchmarks tied to 837 compliance: HFMA healthy 95%+ first-pass acceptance at clearinghouse and payer edit gates.
Worked example
A practice management system generates an 837P file containing 1,240 claims with 3,800 total service lines from a day's encounters. The file is transmitted to Change Healthcare (clearinghouse) via SFTP. Change Healthcare returns a 277CA within two hours accepting 1,215 claims and rejecting 25 for missing subscriber birth dates. The accepted claims are forwarded to their respective payers; the rejections are returned to the PMS with reject-reason codes for correction and resubmission.
Frequently asked questions — 837 File (Healthcare Claim)
What are 837P, 837I, and 837D?
Three variants of the 837 standard. 837P carries professional claims (physician services, CMS-1500 equivalent). 837I carries institutional claims (hospital, facility, UB-04 equivalent). 837D carries dental claims. Each uses the same envelope structure with different specific loops.
What is the difference between 837 and 835?
The 837 flows from provider to payer with claims. The 835 flows from payer to provider with payments and adjustments (ERA — electronic remittance advice). Together they represent the two halves of the electronic billing cycle.
Do small practices generate 837 files directly?
Rarely. Most use a practice management system that generates 837 files behind the scenes and routes them to a clearinghouse. Direct payer submission via SFTP exists but is operationally intensive; clearinghouses exist to absorb the complexity.
What triggers 837 rejections at the clearinghouse?
Missing required loops, invalid enumerations (e.g., wrong claim-frequency code), subscriber data missing or invalid, NPI mismatch, code combinations flagged by edits, taxonomy missing. Clearinghouses typically stop most of these before reaching the payer to avoid adjudication-gate rejections.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.