> ## 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.
# X12 healthcare transaction sets
> X12 transactions commonly used by DSO groups: purpose, direction, where each appears in dental operations, and the 275/277 RFAI attachments pair arriving by 2028.
This page explains the HIPAA-adopted ASC X12N transactions, including what each does, which direction it flows, and where it appears in a dental group's operations.
## The full table
| Transaction | Name | Direction | Purpose |
| ------------ | ----------------------------------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **270** | Eligibility, Coverage or Benefit Inquiry | You → payer | Ask whether a patient is covered, cost-share, remaining annual maximum |
| **271** | Eligibility, Coverage or Benefit Response | Payer → you | Coverage status, plan, deductible remaining, maximum used, coinsurance |
| **276** | Health Care Claim Status Request | You → payer | Ask what happened to a submitted claim |
| **277** | Health Care Claim Status Response | Payer → you | Claim status |
| **277CA** | Health Care Claim Acknowledgment | Payer → you | **Accepted into adjudication, or rejected before it** |
| **277 RFAI** | Request for Additional Information | Payer → you | The standardized information request, part of the attachments standard, in the required set by **May 26, 2028** |
| **275** | Additional Information to Support a Health Care Claim | You → payer | **Attachments**; radiographs, perio charts, narratives; the HIPAA standard payers must support by May 26, 2028 |
| **278** | Health Care Services Review | Both | Authorization review. Rare in dental; predetermination rides the 837D itself, and Medicaid/DHMO preauthorization usually runs through portals |
| **820** | Payroll Deducted and Other Group Premium Payment | Employer → payer | Premium payment. You'll rarely see it. |
| **834** | Benefit Enrollment and Maintenance | Employer/sponsor → payer | Membership enrollment. Awareness only. |
| **835** | Health Care Claim Payment/Advice | Payer → you | **Remittance advice**, what was paid, downgraded, or denied, and why |
| **837D** | Health Care Claim: Dental | You → payer | **Your claim**, and, flagged as such, your predetermination request |
| **837P** | Health Care Claim: Professional | You → payer | Medical claims; in dentistry, the crossover format |
| **837I** | Health Care Claim: Institutional | You → payer | Facility claims, e.g. hospital-OR dentistry billed by the facility |
| **999** | Implementation Acknowledgment | Payer/CH → you | Whether the file was syntactically valid X12 |
| **TA1** | Interchange Acknowledgment | Payer/CH → you | Whether the interchange envelope was readable |
## The ones you touch daily
```mermaid theme={null}
graph LR
A[270] -->|eligibility| B[271]
D[837D] -->|claim| E[TA1 / 999]
E --> F[277CA]
F -->|accepted| G[Adjudication]
G -->|documentation needed| K[Information request / 277 RFAI]
K -->|attachment| G
G --> H[835]
I[276] -->|status check| J[277]
```
Two dental details matter in this flow. A **predetermination** is not a separate transaction: the 837D itself can be sent as a predetermination request, and the estimate returns without payment. The **information-request loop** currently uses a mix of letters, portals, and proprietary attachment services. The 277 RFAI and 275 pair will standardize that exchange on the compliance schedule described below.
## Acknowledgment hierarchy
Three responses can come back after you submit an 837D, and they mean different things.
| | TA1 | 999 | 277CA |
| ----------------------------- | --------------------------- | ------------------------------------- | ------------------------------------------------- |
| **Level** | Interchange envelope | Functional group / transaction syntax | Claim |
| **Answers** | Was the envelope readable? | Was the file valid X12? | Did the payer accept the claim into adjudication? |
| **From** | Receiver | Clearinghouse or payer | Payer |
| **A rejection means** | The file couldn't be opened | The file was malformed | The payer's front end refused the claim |
| **Was anything adjudicated?** | No | No | **No** |
| **Appeal rights?** | None | None | **None** |
**A 277CA rejection is not a denial.** Nothing was adjudicated and no determination was made, so there is nothing to appeal. Correct the data and resubmit as a **new** claim, not as a corrected claim, because there is no original claim in the payer's system to correct.
A **denial**, by contrast, appears in the **835** as a \$0 or reduced payment with a denial CARC and may carry appeal rights. In dental billing, first determine whether the line is a true denial, a downgrade, or a frequency limitation. The latter two may reflect benefit design rather than an appealable determination. See [Claim denials](/concepts/payments/denials-vs-downgrades).
## Versions
Most healthcare transactions currently use the **5010** implementation guides adopted under HIPAA administrative simplification.1 Version identifiers appear in the `GS08` element and the `ST03` element; `005010X224A2` for the 837D, `005010X222A1` for the 837P.
You will see these strings in error messages. They identify which implementation guide the file claims to follow.
The exception is the newly adopted attachments pair, which arrives at version **6020**: the 275 as `006020X314` and the 277 RFAI as `006020X313`.2
## The attachments pair: 275 and 277 RFAI
Dental claims frequently require attachments for crowns, SRP, implants, and other services. In the absence of an adopted standard, the industry developed proprietary repositories and NEA-number workflows. The March 2026 final rule (91 Fed. Reg. 14350) adds the **275** (attachment transmission) and **277 RFAI** (payer request for information) to the standard set, with a **compliance date of May 26, 2028**.2 Proprietary and standard workflows may coexist during the transition. See [Dental attachments](/reference/edi/dental-attachments) for what the rule adopted and omitted.
## Companion guides
The X12 implementation guide defines required, situational, and optional elements. **Payers publish companion guides** specifying how *they* interpret the situational and optional parts, 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.
Two payers can follow the same X12 standard while applying different situational requirements and front-end edits. A clearinghouse helps manage that payer-specific variation. See [What is a clearinghouse?](/concepts/payments/what-is-a-clearinghouse).
## Where each transaction shows up
| Operational moment | Transaction |
| -------------------------------------------- | --------------------------------------------------- |
| Booking an appointment | 270 → 271 |
| Check-in re-verification | 270 → 271 |
| Requesting a predetermination for major work | 837D, flagged as a predetermination request |
| Medicaid/DHMO preauthorization | Usually a portal; 278 where the payer supports it |
| Submitting the claim | 837D (837P for medical crossover) |
| Sending radiographs and charting | Attachment vendor / NEA number today; 275 by 2028 |
| Overnight rejection review | 999, 277CA |
| Payer asks for documentation | Letter or portal today; 277 RFAI by 2028 |
| Chasing an unpaid claim | 276 → 277 |
| Posting payments | 835 |
| Reconciling a deposit | 835 `TRN` segment, matched to the EFT's ACH addenda |
## Automation opportunities
For a multi-location group, these transactions support several useful forms of automation:
| Transaction | Automation opportunity |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **270/271** | Batch eligibility for tomorrow's schedule; auto-flag exceptions; pull remaining annual maximums into treatment-plan estimates |
| **835** | Denial and downgrade analytics by CARC, payer, and PC; underpayment detection against loaded fee schedules, including leased-network repricing |
| **277CA** | Same-day rejection alerting |
| **276/277** | Automated status chasing on aged claims; especially claims pended for attachments |
This work requires **programmatic access** to the transactions, so include it in clearinghouse selection as well as PMS evaluation. Some clearinghouses expose both JSON and X12 interfaces, while others rely on batch file exchange. See [Choose a clearinghouse](/guides/billing/choose-a-clearinghouse).
## PHI
837D, 835, 271, and 277 files all contain protected health information: names, member IDs, dates of service, procedure detail, and attachments are clinical records outright. Encrypt in transit and at rest, access-control them, and cover any analytics store in your BAAs and your security risk analysis. See [HIPAA fundamentals](/concepts/compliance/hipaa-fundamentals).
## Sources
1. HIPAA administrative simplification, 45 C.F.R. pts. 160, 162. 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) and X12N 277 RFAI (006020X313), 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).