EDI Core Live preview

EDI that tells you what broke.

Electronic Data Interchange is one of those things that is everywhere and invisible. Every time a claim moves from a hospital to an insurer, an enrollment changes at a health plan, or a provider checks whether a patient is covered before a procedure. That's EDI.1 Specifically, it's X12: a set of standards that have been governing business-to-business data exchange since the 1970s, and that the United States government baked into law through HIPAA Administrative Simplification.2

We ran into it building machine learning models for insurance claims: fraud detection, waste and abuse patterns, predictive outcome models. All of it depended on the same formats: 837s for claims, 834s for enrollment, 270/271 pairs for eligibility.3 We needed to parse and transform millions of these files fast, inside real pipelines, with enough structure preserved that field values could flow into the models without losing their meaning.

So we looked for a library. There are options. Most were thick desktop translators built for a previous era of middleware. Others were single-stack libraries that would lock us to one runtime. Some were hosted services that handed us an API and kept the parsing somewhere else. Nothing was fast, portable, and honest about failures at the same time.

That last part kept coming up. In health care, malformed files aren't the exception; they're normal. Payer implementations vary. Real-world EDI doesn't always look like the spec. When something breaks in your pipeline at 2am, you need a parser that names the exact segment, field, and violation. Not one that returns a byte offset and calls it done.

So we built edi‑core.

The design decision that makes it different: instead of hand-writing a parser for each transaction type, we wrote a program that generates parsers from specs. Define the transaction spec once. Get a complete, conformant parser from it. The approach borrows from programming language tooling: write the grammar, derive the parser. Tree-sitter is the canonical example. We applied the same idea here. One spec definition, one generated parser, consistent behavior across every runtime. Hand-written rules drift; generated ones don’t.

The core is written in Rust, which is fast and memory-safe in ways that matter when you’re processing high-volume medical data. From there it ships as direct native bindings for Node, Python, Java, .NET, C++, PHP, and Swift, and compiles to WebAssembly for browser use — which is how this playground works. And because each parser is derived from its schema, it knows exactly what valid looks like. When something breaks, the diagnostic names the segment, field, and violation.

Transforms are part of the same library. Parse to JSON, XML, FHIR, or any custom format you wire in. One dependency, one thing to reason about, the whole chain from raw X12 to structured data.

Auto-detects the file

Reads the interchange header to determine delimiters and transaction type. No configuration, no schema files to manage up front.

Rebuilds the hierarchy

X12 loops are implicit in the flat segment stream. The parser reconstructs that structure so you can navigate by loop, not by line number.

Names the failure

Diagnostics point at the exact segment, field, and violation. In language a person can read. Not a byte offset. The actual problem.

Compiles to your stack

Node, Python, Java, .NET, C++, PHP, Swift, and browser via WebAssembly. One core library, no HTTP hop, no subprocess.

Throughput

2,823,692 claims parsed and validated in under 9 seconds.

That's a 10 GB X12 837 EDI file processed in the time it takes to sip your coffee. In our latest comparison, edi-core's multi-threaded run measured 1,060 MiB/s, more than 25x the next fastest third-party library tested.

Speed was not the original goal. Correctness and implementation simplicity were. The speed came from the architecture: a schema-specific parser generated for the transaction spec, with validation built into the parse path instead of bolted on afterward.

EDI parser throughput
MiB/s

Siua edi-core

multi-thread · parse + validate

1060

Siua edi-core

single-thread · parse + validate

269

edireader

parse + validate

43

staedi

parse + validate

19

edx12

parse + validate

5

pyx12

parse + validate

4

badx12

parse only

0.59

Benchmark scope: 100 MB real 837D claims for third-party libraries; single-threaded parse + validate unless noted.

Siua edi-core top rows are 10 GB real 837D claims with single-pass inline schema validation: required fields, lengths, code sets, X12 syntax, and loop order/cardinality. badx12 is parse-only.

If you don't live in X12 every day.

HIPAA Administrative Simplification standardizes how electronic health care transactions are structured and exchanged in the United States.4 X12 is the standards body behind the format, and their work goes well beyond health care into finance, supply chain, transportation, logistics, and defense.5 The transactions below are the health care ones we focused on first.

837 CMS ↗

Health care claims

Used to submit a claim for payment or report an encounter. Professional, institutional, and dental variants.

834 CMS ↗

Enrollment and disenrollment

Establishes, changes, reinstates, or terminates coverage between a sponsor and a health plan.

270 / 271 CMS ↗

Eligibility inquiry and response

The pair used to ask whether a member has coverage for a given service and receive the answer.

X12 CMS ↗

Bigger than health care

X12 standards cover finance, insurance, supply chain, transportation, logistics, defense, and more.

Notes

1CMS maintains an overview of HIPAA-standardized electronic transactions at cms.gov.

2CMS HIPAA Administrative Simplification overview: cms.gov.

3Official CMS descriptions: 837, 834, 270/271.

4CMS Administrative Simplification overview: cms.gov.

5X12 by industry: x12.org.

FAQ

Common questions.

Short answers for teams evaluating EDI Core as a parser, validator, or browser-based inspection tool.

What is edi-core?

edi-core is a local-first EDI/X12 parser focused on healthcare 834 and 837 workflows, readable diagnostics, portable bindings, and structured JSON, XML, and FHIR output.

Does the EDI playground upload my data?

No. The public playground runs in the browser through WebAssembly, so parsing happens locally on the device.

What transactions does edi-core support today?

The current public preview focuses on 834 benefit enrollment and 837 healthcare claims, with more healthcare transaction types planned.

How fast is edi-core on 837 claim files?

The latest benchmark processed 2,823,692 837D claims from a 10 GB file in under 9 seconds, with multi-threaded throughput measured at 1,060 MiB/s.

Need to work with X12 without losing a week to it?

The browser preview is live. If you want to use the parser in your own stack, email us. We will tell you where it is solid, where it is still moving, and whether it is actually a fit.

hello@siua.io