X12 EDI in Plain English: The Transactions Behind Claims

837, 835, 270/271, 276/277 and 278 explained for healthtech teams, plus the parsing traps and when to use a hosted EDI API.

Originally published on Nirmitee.io: X12 EDI for Healthcare Developers: Every Core Transaction, With 270/271 Eligibility in Depth

X12 EDI is not elegant. It was designed in the 1970s and carries decades of backward compatibility. But it is the standard that moves over $3 trillion a year in US healthcare payments. If your product touches claims, payments or coverage, it touches X12.

Here is a plain-language tour of the transactions that matter, for product and engineering leaders who need to plan the work.

The envelope: like postal mail

Every X12 file follows the same nested structure. The outer envelope (ISA/IEA) says who is sending and who is receiving. The inner envelope (GS/GE) groups transactions of the same type. The letter inside (ST/SE) is the actual business document, such as a claim.

That envelope has strict rules. The ISA segment is always exactly 106 characters, and it defines which characters separate the data. Parsers that guess get it wrong.

The six transaction sets that matter

The original guide walks through each one with real message examples. In short:

• 837, the claim. Sends a claim from the provider to the payer, usually through a clearinghouse. The 837P covers physician and outpatient services (the CMS-1500 paper form). The 837I covers hospital facility services (the UB-04 form). Dental claims have their own version, and each needs its own testing.
• 835, the remittance. Tells you how the payer handled your claim: every payment, denial, adjustment and amount the patient owes. Accurate 835 parsing drives payment posting, underpayment detection and denial management.
• 270/271, eligibility. The 270 asks "Is this patient covered?" and the 271 answers with coverage details.
• 276/277, claim status. The 276 asks "Where is my claim?" and the 277 returns its current status.
• 278, prior authorization. Requests approval for a service before it happens.

Eligibility: the check that saves the most rework

The 270 eligibility inquiry and the 271 response. Source: Nirmitee.io

The 271 response is where the detail lives. It contains benefit segments, and there can be dozens of them: active or inactive coverage, deductibles, coinsurance percentages and more. Each one describes a specific benefit, and the request can ask about specific service types, such as hospital, emergency, pharmacy or mental health.

Getting eligibility right before the visit is what the source post calls the real-time check that prevents the eligibility leak in the revenue cycle.

Where the money trail lives

In an 835, every dollar of difference between what you billed and what you were paid is explained by an adjustment, with a group code that says who is responsible:

• CO (contractual obligation): the provider writes it off, per contract.
• PR (patient responsibility): the patient owes it, such as a deductible, copay or coinsurance.
• OA (other adjustment) and PI (payer initiated) cover the rest.

The math must balance: billed amount equals paid amount plus all adjustments. If it does not, the parser is wrong.

Common traps

From building dozens of X12 integrations, the source post lists the mistakes teams hit most often:

1. Fixed-width fields. Some ISA fields are always exactly 15 characters. Trimming the padding breaks routing.
2. Separators. The segment terminator is not always "~". It is defined inside the ISA, so read it before assuming anything.
3. Loops. The same segment means different things in different places, such as billing provider, subscriber or patient. The parser has to track context.
4. Versions. HIPAA mandates version 5010, but older 4010 files still appear, especially from smaller payers and legacy systems.
5. Test data. Synthetic files miss real-world edge cases. Ask your clearinghouse for sanitized production samples.

Hosted EDI API or your own X12 stack?

An X12 EDI processing pipeline: generate, validate, parse. Source: Nirmitee.io

Most product teams do not need to build X12 parsing, clearinghouse connectivity and payer enrollment from scratch. A hosted EDI API handles the envelope, transport and payer routing, and returns JSON. A custom build gives you full control over data, cost at volume and edge cases, but you own testing, acknowledgements and payer onboarding.

The right choice depends on three questions: which transactions you need, how many payers you must reach, and whether your team can own rejections, acknowledgements and enrollment.

The source compares Stedi, Availity, Optum and SignalEDI with a custom build. A common middle path is to use a hosted API for eligibility and claims transport, and build your own layer for validation, mapping and exception handling. Payer connectivity stays off your plate while your product still controls the data. The full post also maps each transaction to FHIR, useful as payers move toward FHIR APIs.

---

Nirmitee.io builds X12 EDI integrations, clearinghouse connectivity and FHIR-based revenue cycle automation for healthtech and RCM teams. For annotated examples, parsing code and FHIR mappings, read the full guide: X12 EDI for Healthcare Developers on Nirmitee.io.

Dinesh Thorat is Healthtech Growth Partner at Nirmitee.io.

Originally published at nirmitee.io.