Healthcare EDI runs on four transactions, and none of them forgive sloppy tooling. Retail EDI moves boxes: an 850 orders them, an 856 says they shipped, an 810 asks to be paid. Healthcare EDI moves money for care already delivered, and the documents carry the proof. The 837 is the claim — the bill a provider sends a payer. The 835 is the remittance — the payer's answer, with the check attached. The 270 asks whether a patient is covered; the 271 answers. If you build integrations for clinics, billing companies, or health-tech products, these four messages are your whole world. Here is what actually happens on the wire.
The 837: a bill with a hundred ways to be wrong
The 837 claim comes in three flavors that share a name and almost nothing else: 837P for professional claims (the doctor's office), 837I for institutional claims (the hospital), and 837D for dental. Same envelope, different loops inside. A professional claim carries the billing provider in the 2000A loop, the subscriber in 2000B, and each patient — when the patient isn't the subscriber — in 2000C. The money lines live in the 2400 service-line loop, where each procedure shows up with its charge and units.
What gets 837s rejected is rarely the headline data. It's the mismatches nobody eyeballs: a service-line charge that doesn't sum to the claim total in the CL2 or SV1 segments, a diagnosis pointer that references a diagnosis that isn't listed, a rendering provider NPI that the payer has on file under a different taxonomy. Payers publish companion guides — hundreds of pages of "the standard allows this, we require that" — and every payer's guide differs in the details that matter. An 837 that sails through one payer bounces off another for a situational element they made required. Validation that stops at "valid X12" is validation that stops one payer too early.
The 835: the answer, with the denial codes attached
The 835 remittance advice is healthcare's version of the three-way match, except the payer does the matching and tells you where you lost. The BPR segment carries the total payment. Below it, claim-level CLP segments show what was charged, what was allowed, and what was actually paid — three numbers that agree only in the happiest cases. The difference is explained in CAS segments with claim adjustment reason codes, and this is where revenue is quietly won or lost: a CO-45 (charge exceeds the contracted fee schedule) is expected and fine; a CO-97 (bundled into another service) or a PR-1 (patient deductible) sends the balance down two completely different paths — write it off or bill the patient.
Line-level adjustments in the SVC segments frequently contradict the claim-level ones, and the 835 still balances, because balancing only proves the arithmetic adds up — not that the adjudication was right. Systems that post 835s automatically and skim the totals miss the denied lines aging in the details. The denial codes are the payload. Treat an 835 like an API error response you'd actually read, not a receipt you'd file.
The 270/271: eligibility is a handshake, not a lookup
The 270 eligibility inquiry and 271 response are the closest thing healthcare EDI has to a real-time API. A 270 asks one question — is this patient covered, for this service, on this date? The 271 answers in EB segments, one per benefit: EB01 says active, inactive, or active-with-conditions; the segments below it carry copays, deductibles, and remaining amounts.
The trap is reading "active coverage" as "this will be paid." The 271 describes the plan as of the response date; it says nothing about whether the service is covered under that plan, whether authorization was required, or whether the deductible math in the response reflects claims still in flight. Eligibility checks fail silently in production more than any other healthcare transaction, because the answer looks like a yes. It is a yes about membership. Payment is a different question, answered weeks later by an 835 with a denial code on it.
The plumbing underneath: acknowledgments and natural keys
Three patterns tie the four transactions together, and API developers will recognize all of them. First, layered acknowledgment: a TA1 confirms the envelope arrived, a 999 confirms the claim was syntactically acceptable, and the 835 confirms it was adjudicated. Received, valid, and paid are three different states, and conflating them is how claims vanish — the same ack-versus-processing mistake that haunts webhook design everywhere else. Second, natural idempotency keys: the ST/SE control numbers and claim-level trace numbers mean a retransmitted 837 is a duplicate a payer can detect, not a second bill — provided you don't regenerate control numbers on retry, which is the healthcare equivalent of minting a fresh idempotency key on every attempt. Third, partner-specific validation: every payer is a trading partner with its own companion guide, its own enrollment paperwork before you may submit at all, and its own interpretation of situational segments. There is no spec compliance without partner compliance.
Healthcare EDI is unforgiving because the feedback loops are slow — a mapping mistake made today surfaces as denials thirty days from now. That's the work we built SignalEDI for: healthcare transaction sets, payer-specific validation, and acknowledgment tracking are in every plan, because a claim you can't trace is a claim you can't defend. I'm Chris, founder of SignalEDI — tomorrow: error handling and retries, and why clearinghouses treat your retry storm as a duplicate-claims attack.
Top comments (0)