> ## Documentation Index > Fetch the complete documentation index at: https://mso.getlemma.com/llms.txt > Use this file to discover all available pages before exploring further. # X12 healthcare transaction sets > Every X12 transaction an MSO-PC group touches: purpose, direction, who generates it, and where you'll encounter it. The HIPAA-adopted ASC X12N transaction standards. For each: what it does, which way it flows, and where it shows up in your operation. ## The full table | Transaction | Name | Direction | Purpose | | ----------- | ------------------------------------------------------------ | ------------------------ | --------------------------------------------------------------- | | **270** | Eligibility, Coverage or Benefit Inquiry | You → payer | Ask whether a patient is covered and what their cost-share is | | **271** | Eligibility, Coverage or Benefit Response | Payer → you | Coverage status, plan, deductible remaining, copay, 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** | | **278** | Health Care Services Review, Request for Review and Response | Both | Prior authorization / referral certification | | **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 and why | | **837P** | Health Care Claim: Professional | You → payer | Physician and outpatient claims | | **837I** | Health Care Claim: Institutional | You → payer | Facility claims | | **837D** | Health Care Claim: Dental | You → payer | Dental claims | | **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 | | **275** | Additional Information to Support a Health Care Claim | You → payer | Attachments, where supported | ## The ones you touch daily ```mermaid theme={null} graph LR A[270] -->|eligibility| B[271] C[278] -->|prior auth| C2[278 response] D[837] -->|claim| E[TA1 / 999] E --> F[277CA] F -->|accepted| G[Adjudication] G --> H[835] I[276] -->|status check| J[277] ``` ## Acknowledgment hierarchy, the distinction that matters Three responses can come back after you submit an 837, 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. Conversely, a **denial** appears in the **835** as a \$0 or reduced payment with a denial CARC, and it does have appeal rights. See [Claim denials](/concepts/payments/claim-denials). ## Version 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, for example `005010X222A1` for the 837P. You will see these strings in error messages. They identify which implementation guide the file claims to follow. ## 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. This is why two payers can both be fully standards-compliant and still reject each other's accepted claims, and it is the variation your clearinghouse absorbs. 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 prior authorization | 278, or a portal, or fax | | Submitting the claim | 837P / I / D | | Overnight rejection review | 999, 277CA | | Chasing an unpaid claim | 276 → 277 | | Posting payments | 835 | | Reconciling a deposit | 835 `TRN` segment, matched to the EFT's ACH addenda | ## The ones to build against If you are building automation, these are where the value is: | Transaction | Automation opportunity | | ----------- | ------------------------------------------------------------------------------------------------ | | **270/271** | Batch eligibility for tomorrow's schedule; auto-flag exceptions; drive point-of-care estimates | | **835** | Denial analytics by CARC, payer, and entity; underpayment detection against loaded fee schedules | | **277CA** | Same-day rejection alerting | | **276/277** | Automated status chasing on aged claims | Doing any of this requires **programmatic access** to the transactions, which is a clearinghouse selection criterion rather than an EHR one. API-first clearinghouses expose these as JSON as well as X12; batch-era vendors generally do not. See [Choose a clearinghouse](/guides/billing/choose-a-clearinghouse). ## PHI 837, 835, 271, and 277 files all contain protected health information: names, member IDs, dates of service, diagnosis and procedure detail. Encrypt in transit and at rest, access-control them, and cover any analytics store in your BAAs and your security risk analysis. See [HIPAA for MSO-PC operators](/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/). ## Related topics - [EDI and X12, gently](/concepts/payments/edi-and-x12-basics.md) - [The 837: how claims are told to payers](/concepts/payments/understanding-837s.md) - [The 835: how payers answer](/concepts/payments/understanding-835s.md) - [Submit clean claims](/guides/billing/submit-clean-claims.md) - [Set up EDI, ERA, and EFT with each payer](/guides/enrollment/set-up-edi-era-eft.md) - [837 file anatomy](/reference/edi/837-anatomy.md) - [835 file anatomy](/reference/edi/835-anatomy.md)