Skip to main content
EDI (electronic data interchange) is the structured exchange of business documents between computer systems. X12 is the standards body whose formats HIPAA mandated for healthcare transactions. Together they explain why dental claims still look like a 1970s telegram, and why every payer’s version of the standard is slightly different anyway.

​
Why dentistry runs on this

HIPAA Administrative Simplification requires standard formats for specified electronic health care transactions. The adopted standards use ASC X12N implementation guides, currently the 5010 versions for most transactions. Dental claims use the 837D, and federal code-set rules adopt the ADA’s CDT for dental services.1 Federal rules require these formats when the adopted standards apply. Modern API-based clearinghouses may present simpler interfaces, but they still translate to and from the adopted X12 transactions behind the scenes.

​
Anatomy of an X12 file

Four nested levels: Within segments, elements are separated by delimiters (conventionally *) and composite elements by a sub-delimiter (conventionally :). Loops group related segments that repeat. An annotated snippet from an 837D dental claim:
Reading a few of those:
  • GS*HC*…*005010X224A2: 005010X224A2 identifies the 837D dental implementation guide. The professional 837P uses 005010X222A1.
  • NM1*85*2*BLUEBIRD DENTAL PC*****XX*1234567890: entity identifier 85 marks the billing provider; 2 means an organization; XX identifies the following value as an NPI.
  • CLM*PATACCT001*310.00***11:B:1*Y*A*Y*Y: this segment carries the patient account number, total charge of 310.00, and a composite including office place of service 11.
  • SV3*AD:D2391*310.00****1~: SV3 is a dental service-line segment, while the 837P uses SV1. AD identifies a CDT code, here D2391, with a charge of 310.00.
  • TOO*JP*30*O: the tooth segment identifies tooth 30 and occlusal surface O.
The simplified example does not include a diagnosis segment. ICD-10 requirements on dental claims vary by payer, service, and billing pathway. Most operators will not read raw files often, but the segment vocabulary is useful when a payer or clearinghouse reports an error such as a missing surface in TOO. See 837D file anatomy.

​
The transaction family

Full detail: X12 transaction sets.

​
The attachment gap, closing

Dental payers often require radiographs, periodontal charts, and narratives, but HIPAA previously lacked an adopted electronic attachment standard for this workflow. The industry relied on proprietary repositories and claim references. In March 2026, CMS adopted the X12N 275 for transmitting attachments and the 277 request for additional information, with a compliance date of May 26, 2028.2 Proprietary and standard workflows will coexist during implementation. See CDT & the 837D.

​
Companion guides

A vendor’s statement that it “supports the standard” does not describe how it handles payer-specific requirements. The X12 implementation guide defines required, situational, and optional elements. Payers publish companion guides specifying how they interpret the situational and optional parts: which fields they require, what identifiers they expect, how they want files delivered, and what their front-end edits check. Delta Dental publishes one; UnitedHealthcare publishes a separate one for its dental line; every Medicaid dental benefit administrator has its own.3 Two payers can comply with the same transaction standard while requiring different situational fields or edits. A clearinghouse manages much of that variation. When choosing one, evaluate actual payer connectivity and companion-guide support in addition to basic format support. See What is a clearinghouse?.

​
Requirements for DSO groups

Identifiers must be consistent everywhere. The billing provider NPI, Tax ID, and taxonomy in your 837D must match what the payer has on file from enrollment, exactly. Most first-claim failures are identifier mismatches, not clinical or coding problems. Multi-entity groups have more configuration points. Each billing entity has its own identifiers and payer-specific configuration. Getting one wrong can misidentify the billing provider, rendering provider, location, or participation status. After an acquisition, use the payer’s written assignment, CHOW, TIN/NPI, effective-date, and interim-billing instructions; the purchase agreement cannot authorize a claim. See Acquire a dental practice. Automation needs data access. If you want per-office downgrade analytics across ten PCs, you need programmatic access to 837D and 835 data. Batch-era clearinghouses make this hard; API-first ones make it an integration. See The clearinghouses, compared.
835 files contain protected health information. They carry patient identifiers, procedure detail, and amounts. Treat them as PHI in storage, in transit, and in any analytics pipeline you build. Your BAAs must cover wherever they land. See HIPAA fundamentals.

​
Sources

  1. HIPAA Administrative Simplification, 45 C.F.R. pts. 160, 162; CDT designated as the dental code set at 45 C.F.R. § 162.1002(a)(4) (eCFR). CMS, Administrative Simplification: Transactions. Standards maintained by ASC X12.
  2. Administrative Simplification: Adoption of Standards for Health Care Claims Attachments Transactions and Electronic Signatures, 91 Fed. Reg. 14350 (Mar. 24, 2026), adopting X12N 275 (006020X314), compliance May 26, 2028. Federal Register.
  3. Delta Dental, 837 companion guide (PDF); UnitedHealthcare, 837D companion guide, 005010X224A2 (PDF).
Last modified on August 21, 2026