HIPAA X12 5010 transactions, built and run
We build the X12 layer of your healthcare product: parsing and generating 837, 835, 270/271, 276/277, 278 and 834, wrapping them in correct ISA, GS and ST envelopes, following each partner's companion guide, and correlating every TA1, 999 and 277CA back to what you sent.
ISA, GS and ST headers with control numbers your system can trace.
TA1 for the interchange, 999 for syntax, 277CA for claim acceptance.
Eligibility, status or adjudication answered by the payer.
835 payments and adjustments matched to the original claim lines.
The short answer
X12 EDI is how US healthcare moves eligibility, claims, status and payments. HIPAA mandates version 5010 of these transactions for covered entities, and every clearinghouse and payer layers a companion guide on top. We build the parsers, generators, envelopes, acknowledgement handling and correlation logic that let your product send an 837 and know, at every step, whether it was received, accepted, adjudicated and paid. You can inspect any file first with our free EDI Inspector.
X12 transaction sets
These are the transaction sets and implementation guide identifiers your partners will quote. We use the same identifiers in the specification.
| Transaction | Implementation guide | Purpose | What we design for |
|---|---|---|---|
| 270 / 271 | 005010X279A1 | Eligibility and benefit inquiry and response | Service type codes, AAA reject reasons, and EB segments parsed into usable benefits |
| 837P / 837I / 837D | 005010X222A1, X223A2, X224A2 | Professional, institutional and dental claims | Hierarchical loops (2000A to 2400), provider roles, frequency codes 1, 7 and 8 |
| 835 | 005010X221A1 | Health care claim payment and remittance advice | CLP and SVC matching, CAS triplets, PLB provider adjustments, reversals |
| 276 / 277 | 005010X212 | Claim status inquiry and response | Status category codes, polling cadence, and BHT06 DG on payer responses |
| 277CA | 005010X214 | Claim acknowledgement from a clearinghouse or payer front end | Shares ST01 277 with the status response; BHT06 TH tells them apart |
| 278 | 005010X217 | Prior authorization and referral request and response | Payer support, and the FHIR PAS path under CMS-0057-F |
| 834 | 005010X220A1 | Benefit enrollment and maintenance | Full and change files, INS maintenance codes, effective-dated member history |
| 820 | 005010X218 | Premium payment | Remittance detail tied to member and group identifiers |
| 999 and TA1 | 005010X231A1 (999); TA1 is interchange level | Implementation and interchange acknowledgements | IK3, IK4 and IK5 error locations mapped back to the segment that failed |
Envelopes are part of every file: ISA is a fixed 106-character header whose delimiters define the file (ISA11 repetition, ISA16 component), GS groups transactions by functional code and version, and ST opens each transaction with its control number.
What we build
Each workstream ships with a specification, positive and negative test files, and an owner.
X12 5010 read and write for the transactions you need, delimiter detection from ISA, loop and segment validation against the implementation guide, and typed output your code can use.
ISA · GS · ST · SE · GE · IEA · 005010 guides
X12 EDI for developers →Each clearinghouse and payer adds its own rules on top of the standard. We version them per partner so one partner's change never breaks another's files.
Companion guides · payer IDs · per-partner profiles
EDI testing and clearinghouse integration →TA1, 999 and 277CA correlated to the interchange, group, transaction and claim they answer, with IK3 and IK4 errors pointed at the segment and element that failed.
TA1 · 999 IK3/IK4/IK5 · 277CA STC
277 claim status automation →Inbox and outbox tables, control numbers reused on retry, duplicate detection on inbound files, and replay that separates a corrected claim from an accidental resend.
Inbox/outbox · ISA13 · GS06 · ST02 · CLM01
Idempotent EDI processing →An anti-corruption layer that maps 837 and 835 into your own model or FHIR Claim, ClaimResponse and ExplanationOfBenefit, so the rest of your product never parses X12.
FHIR Claim · ClaimResponse · ExplanationOfBenefit · CARIN BB
X12 837 and 835 to FHIR →SFTP upload and polling with each partner's filename rules, API transport where offered, AS2 when a payer requires it, and alerts on missing acknowledgements.
SFTP · REST · AS2 · no-file alerts
Integration monitoring and support →Buyer decisions
The route your X12 takes is a buying decision. We build on each of these, often more than one in the same product.
| Route | Best fit | What you get | What to plan for |
|---|---|---|---|
| Traditional clearinghouse (SFTP batch) | Broad payer reach with one contract | Availity, Waystar, Change Healthcare (Optum), Office Ally and others route to thousands of payers | Batch latency, per-clearinghouse filename and folder conventions, enrollment per payer |
| API-first clearinghouse | Products that want JSON and real-time eligibility | Vendors such as Stedi wrap X12 in JSON APIs | You still own X12 semantics: CAS, status codes and companion rules |
| Direct payer connection | A few high-volume payers, or Medicare through a MAC | No clearinghouse fee on that volume; direct acknowledgements | Separate enrollment, testing and companion guide per payer |
| Integration engine (Mirth, OIE, Rhapsody) | Teams that already run an engine for HL7 | X12 handled beside HL7 and FHIR channels | X12-specific validation and correlation still need building |
| Interoply (our platform) | Products that want X12, HL7 and FHIR behind one API | Per-partner profiles, replay and monitoring built in | Fit with your hosting and data residency rules |
The implementation guide sets the floor; the partner's companion guide decides whether your file is accepted.
Integration boundaries
EDI failures hide between organizations. We name the owner of every layer before the first file moves.
Owns the business data and decisions: what is billed, to whom, and how corrections are approved.
Parsing, generation, envelopes, validation, correlation, replay and alerts. Defects here are ours to fix.
Enrollment, companion guides, front-end edits, adjudication and response timing.
X12 implementation guides are licensed from X12. Your team or ours holds the license needed for the transactions in scope.
Files move over SFTP or TLS, test data is synthetic, and we sign a BAA and work inside our ISO 27001:2022 certified management system.
Deliverables
Everything below lands in your repository and your runbook.
Transactions, guides, partner companion rules, field mappings and annotated sample files.
Versioned code or engine configuration with per-partner profiles held in configuration.
Positive and negative files per transaction, including rejected, corrected, voided and reversed cases.
How ISA13, GS06, ST02, CLM01, TRN and payer claim numbers link every response to its request.
Missing acknowledgement, rejected batch and stalled folder alerts routed to your on-call.
Replay procedure, partner contacts, enrollment status and a checklist for adding the next partner.
Delivery phases
A first transaction family with one clearinghouse typically takes 6 to 12 weeks. Partner testing and enrollment set most of that date.
Weeks 1 to 2
Transactions, companion guides and sample files gathered; enrollment and SFTP access requested
Weeks 2 to 6
Parsers, generators, envelopes and correlation built against the clearinghouse simulator
Weeks 5 to 10
Test files exchanged, 999 and 277CA errors closed, partner sign-off
Weeks 8 to 12
Cutover, first production cycle reconciled, monitoring and runbook handed over
Cost drivers
You get a fixed scope after one scoping call. These are the factors that move it.
Each family (eligibility, claims, status, remittance, enrollment) has its own guide and test cycle.
Reading an 835 is smaller than generating clean 837s that pass every partner's edits.
Each clearinghouse or direct payer adds a companion guide, enrollment and test cycle.
Mapping X12 into your model or FHIR is its own workstream when the product needs it.
SFTP, API and AS2 differ in setup and monitoring effort.
High-volume batch processing and on-call support are scoped per connection.
Proof
Client names are withheld. The code and tools linked here are public.
A drop-in stand-in for a real clearinghouse SFTP connection: 120 scenarios across 270/271, 278, 837, TA1 and 999, 277CA, 835 and 276/277, with your own control numbers, trace numbers and patient control numbers echoed back so correlation code is tested before enrollment finishes.
View the simulator on GitHub →Our browser-based X12 viewer decodes 837, 835, 270/271, 276/277, 277CA and 999 files segment by segment, explains CARC and RARC codes, and never uploads the file anywhere.
Open the EDI Inspector →Built and run for a US behavioral health group: the signed session note becomes the 837P claim, eligibility is checked before every visit, and denials land in a work queue with the payer's own CARC and RARC reason attached. Our first clearinghouse test passed when it should have failed, so every test now takes the exact path production takes.
Our platform runs X12, HL7 v2 and FHIR connectors behind one API, with per-partner configuration, replay and monitoring built in.
See Interoply →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
They are the engineering work that lets a healthcare product exchange HIPAA X12 transactions with clearinghouses and payers: parsing and generating 837, 835, 270/271, 276/277, 278 and 834 files, building ISA, GS and ST envelopes, applying companion guides, handling acknowledgements and reconciling responses to what was sent.
HIPAA adopted version 5010 for eligibility (270/271), claims (837P, 837I, 837D), claim status (276/277), remittance (835), prior authorization and referrals (278), enrollment (834) and premium payment (820). The 999 and 277CA acknowledgements are standard practice that clearinghouses and payers expect.
An 837 is the claim a provider sends to a payer. An 835 is the payer's answer about money: what it paid for each claim and line, and why anything was adjusted, using CAS group codes with CARC and RARC reason codes. The 837 goes out; the 835 comes back and drives payment posting.
Every X12 file is nested. The ISA interchange header is a fixed 106 characters and defines the delimiters and sender and receiver IDs. GS groups transactions of one type and carries the implementation guide version, such as 005010X222A1. ST opens each transaction. Each level has a control number that acknowledgements refer back to.
A TA1 answers the interchange envelope. A 999 reports whether each transaction is syntactically valid against the implementation guide. A 277CA reports whether each claim passed front-end edits and was accepted for adjudication. A file can pass the 999 and still have claims rejected in the 277CA.
Your system sends a 276 inquiry for a claim and the payer returns a 277 with status category and status codes, such as pending, finalized or requests for more information. Payer status does not arrive on its own, so we build an aging schedule that polls claims past their expected turnaround.
A companion guide is the clearinghouse's or payer's own rulebook on top of the X12 implementation guide: required values, identifiers, filename and transport rules, and edits it enforces. A file can be valid X12 and still be rejected for breaking a companion guide rule, so we version these rules per partner.
A clearinghouse gives you thousands of payers through one connection and one enrollment process, which suits most products. Direct connections suit a few high-volume payers or Medicare through a MAC. Many products use a clearinghouse for reach and direct or API connections where speed or cost matters.
Yes. We build a mapping layer that turns 837 and 835 into your own data model or into FHIR Claim, ClaimResponse and ExplanationOfBenefit resources, and turns your model back into valid X12. The rest of your product then works with clean objects while the X12 stays at the edge.
We test against positive and negative files for every transaction, our open-source clearinghouse simulator for the full 837 to 999, 277CA and 835 sequence, and then the partner's test environment. Our free EDI Inspector lets your team read any file segment by segment during testing.
A first transaction family with one clearinghouse typically takes 6 to 12 weeks. Enrollment and partner testing set most of that timeline, so we request access in week one and build against the simulator while it moves. Each additional partner is faster once profiles live in configuration.
Cost depends on the transaction families, whether you read or generate them, how many clearinghouses and payers you connect, mapping into your model or FHIR, the transport and the support level. We give a fixed scope after one scoping call, before you commit.
Next step
Tell us the transactions, partners and volumes. An integration engineer replies with the enrollment you need, the risks in your files and a fixed scope.
Send your details
Tell us the transactions, clearinghouse or payers, current failure point and expected volume. Please do not send real EDI files with patient data.
