X12 EDI quickstart for developers
Step 1 — The 837P is the bill going out
Everything starts with the 837P (Health Care Claim — Professional, version 005010X222A1). When you send a bill, Mindbill writes it as an 837P: an ISA/GS/ST envelope wrapping the NM1 names (submitter, billing provider, subscriber, patient, payer, rendering provider), the CLM claim line, the HI diagnosis codes, and one SV1 per service line. If the bill has a med-legal report attached, a PWK segment references the attachment. You don't choose Carisk, Jopari, or Data Dimensions — Mindbill resolves the route from the claims administrator on the injury and hands the 837P to the right clearinghouse. This is the only transaction that goes outbound; the next four come back to you.
Step 2 — The 999 says the file was syntactically valid
The first thing to come back, usually within minutes, is the 999 (Implementation Acknowledgement, 005010X231A1). It's a file-level pass/fail from the clearinghouse: did the 837P parse as valid X12? The answer lives in the IK5/AK9 segments — A (accepted), R (rejected), or E (errors but acknowledged). A 999 acceptance only means the syntax was clean; it says nothing about whether the payer will accept the claim. Mindbill parses the 999, moves the bill forward on its history timeline, and flags it for you if the file was rejected so you can correct and resend rather than wait for a response that's never coming.
Step 3 — The 277CA tells you the payer accepted (or rejected) the claim
Next comes the 277CA (Claim Acknowledgement, 005010X214) — the payer's own accept/reject decision, made before adjudication even begins. The verdict is in the STC status segment: A1 means accepted into the adjudication system, while R0 or R1 means rejected (for example, a missing or malformed claim number). This is the most important early signal you get — an A1 means the bill is genuinely in front of the payer; an R0 means it bounced and the EOR clock never started. Mindbill reads the STC code, advances or holds the bill accordingly, and surfaces the rejection reason so you can fix the underlying claim.
Step 4 — The 277 reports where the claim stands
While the payer works the claim, you may receive one or more 277s (Health Care Claim Status Response, 005010X212) — a mid-cycle status check, again carried in the STC segment. The codes that matter: F1 (finalized — payment made), F2 (finalized — denied, no payment), P1 (pending — adjudication in process), and P3 (pending — provider documents requested). A P3 is your cue that the payer wants something more (often the report or a declaration); an F2 is an outright denial you'll likely want to dispute. Each 277 is matched to its bill and timestamped on the bill history, so the bill's status reflects the payer's latest word without you polling anyone.
Step 5 — The 835 ERA is where the money — and the adjustments — land
The 835 (Electronic Remittance Advice, 005010X221A1) is the electronic EOR: the actual payment and the per-line detail of how the payer got there. The BPR carries the total EFT amount and payment date, the CLP block holds each claim's charge-versus-paid, and every reduction shows up as a CAS adjustment segment — a group code (CO contractual, OA other, PR patient responsibility) plus a reason code. Two reasons are worth memorizing: CO-45 is a fee-schedule cap (often legitimate against the MLFS), but PR-242 is a PPO/MPN network reduction, which is illegal on a medical-legal bill under CCR §9789.30(d). Mindbill decodes the CAS codes, posts the payment, computes the variance against the Medical-Legal Fee Schedule, and routes an illegal short-pay straight into the Second Review queue instead of letting it pass as 'paid.'
Step 6 — Inspect the raw X12 in the Sandbox and the Reference
You almost never need to read raw EDI — Mindbill handles the round trip — but when you want to, two read-only tools exist under Integrations. The EDI Sandbox (/integrations/edi-sandbox) generates a real 837P or 835 from any existing bill, or lets you paste an EDI file; it parses every segment, surfaces the required envelope segments, and validates against the v5010 implementation guides used by Carisk, Jopari, and Data Dimensions. It does not submit anything to a payer — it's purely for inspecting and validating. Alongside it, the ASC X12 5010 Reference (/integrations/x12-reference) lists every transaction set, key segment, STC status code, and CAS adjustment code that flows through the pipeline — the field guide for when you're staring at a rejection in the Sandbox and need to know what NM1*41 or STC*A1:20:PR actually means.
California workers'-comp e-billing runs on ASC X12 5010: five transaction sets that arrive in a fixed sequence, one bill at a time — 837P out, then 999, 277CA, 277, and 835 back. You never hand-build a segment or pick a clearinghouse in Mindbill; you enter a bill and click Send, and the envelope is generated, routed per payer across Carisk, Jopari, and Data Dimensions, and the inbound acknowledgments are parsed onto the bill for you. But it pays to know what each transaction is, what it tells you, and where it shows up — because that's what lets you read a rejection or a short-pay instead of just seeing a status flip. This article walks the five transactions in order, explains the status and adjustment codes that ride inside them, and points you to the two read-only tools that let you inspect the raw X12: the EDI Sandbox and the X12 Reference.