> ## Documentation Index
> Fetch the complete documentation index at: https://dso.getlemma.com/llms.txt
> Use this file to discover all available pages before exploring further.

# EDI and X12, gently

> Why dental claims run on 1970s-era electronic data interchange, the anatomy of an X12 file, the family of transactions at a glance, and why 'we support the standard' still means payer-by-payer quirks.

**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.<sup>1</sup>

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:

| Level                | Marked by             | Contains                                             |
| -------------------- | --------------------- | ---------------------------------------------------- |
| **Interchange**      | `ISA` … `IEA`         | The envelope, sender, receiver, date, control number |
| **Functional group** | `GS` … `GE`           | Transactions of one type                             |
| **Transaction set**  | `ST` … `SE`           | One logical document, e.g. one batch of claims       |
| **Segment**          | A line, ending in `~` | One record, e.g. one provider, one service line      |

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:

```text theme={null}
ISA*00*          *00*          *ZZ*SUBMITTERID    *ZZ*PAYERID        *260813*1200*^*00501*000000001*0*P*:~
GS*HC*SUBMITTERID*PAYERID*20260813*1200*1*X*005010X224A2~
ST*837*0001*005010X224A2~
BHT*0019*00*REF123*20260813*1200*CH~
NM1*85*2*BLUEBIRD DENTAL PC*****XX*1234567890~
NM1*IL*1*CHEN*MARGARET****MI*ABC123456789~
CLM*PATACCT001*310.00***11:B:1*Y*A*Y*Y~
LX*1~
SV3*AD:D2391*310.00****1~
TOO*JP*30*O~
DTP*472*D8*20260801~
SE*10*0001~
GE*1*1~
IEA*1*000000001~
```

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](/reference/edi/837d-anatomy).

## The transaction family

| Transaction | Name                                | Direction        | Purpose                                            |
| ----------- | ----------------------------------- | ---------------- | -------------------------------------------------- |
| **270**     | Eligibility inquiry                 | You → payer      | Is this patient covered?                           |
| **271**     | Eligibility response                | Payer → you      | Coverage, maximums, cost-sharing                   |
| **276**     | Claim status inquiry                | You → payer      | What happened to this claim?                       |
| **277**     | Claim status response               | Payer → you      | Status                                             |
| **277CA**   | Claim acknowledgment                | Payer → you      | Accepted into adjudication, or rejected before it  |
| **275**     | Additional information / attachment | You → payer      | The new attachments standard; see below            |
| **834**     | Benefit enrollment                  | Employer → payer | Membership; you'll rarely see it                   |
| **835**     | Remittance advice                   | Payer → you      | What was paid and why                              |
| **837D**    | Dental claim                        | You → payer      | Dental services reported for adjudication          |
| **837P**    | Professional claim                  | You → payer      | Medical claims; in dentistry, the crossover format |
| **837I**    | Institutional claim                 | You → payer      | Facility services, e.g. hospital OR dentistry      |
| **999**     | Implementation acknowledgment       | Payer/CH → you   | Was the file valid X12?                            |
| **TA1**     | Interchange acknowledgment          | Payer/CH → you   | Was the envelope readable?                         |

Full detail: [X12 transaction sets](/reference/edi/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**.<sup>2</sup> Proprietary and standard workflows will coexist during implementation. See [CDT & the 837D](/reference/edi/cdt-and-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.<sup>3</sup>

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?](/concepts/payments/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](/guides/growth/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](/reference/vendors/clearinghouse-comparison).

<Tip>
  **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](/concepts/compliance/hipaa-fundamentals).
</Tip>

## 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](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-J/section-162.1002)). CMS, [Administrative Simplification: Transactions](https://www.cms.gov/medicare/regulations-guidance/administrative-simplification/transactions). Standards maintained by [ASC X12](https://x12.org/).
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](https://www.federalregister.gov/documents/2026/03/24/2026-05676/administrative-simplification-adoption-of-standards-for-health-care-claims-attachments-transactions).
3. Delta Dental, [837 companion guide (PDF)](https://www1.deltadentalins.com/content/dam/ddins/en/pdf/dentists/companion-guide-837.pdf); UnitedHealthcare, [837D companion guide, 005010X224A2 (PDF)](https://www.uhcprovider.com/content/dam/provider/docs/public/resources/edi/EDI-837D-Companion-Guide-Dental-005010X224A2.pdf).