← Back to blog

EDI & Healthcare Integration Demystified

·
healthcareengineering

If you've never worked in healthcare IT, terms like EDI, HL7, and DICOM probably sound like alphabet soup. And honestly, even after years of working with them, the specifications can feel like they were written by a committee of people who'd never met each other. (Because they were.)

But underneath the arcane syntax and the 500-page specifications, healthcare integration is just data transformation and reliable messaging — problems every engineer knows how to solve.

EDI: The Language of Healthcare Transactions

EDI (Electronic Data Interchange) is how healthcare organizations exchange structured data — claims, eligibility checks, payment information. The two most common transaction types I've worked with:

837 (Claims). When a healthcare provider submits a claim for reimbursement, it's an 837 transaction. There are subtypes: 837P (professional), 837I (institutional), 837D (dental). Each has its own layout and rules.

835 (Remittance). When a payer responds to a claim with payment information, it's an 835. This tells the provider what was paid, what was denied, and why.

The format is... not JSON. EDI uses a segment-based format with tildes and asterisks as delimiters. It looks like gibberish at first, but once you understand the structure, it's just a flat, typed data format.

Building an EDI Pipeline

When I built the eligibility platform at Healthfund Solutions, I designed a complete EDI processing pipeline: inbound parsing, validation, transformation, and outbound generation. Here's the architecture that scaled to 500K–1M transactions per day:

Inbound: Files arrive via SFTP. A watcher service picks them up, validates the envelope, and publishes raw segments to a RabbitMQ queue.

Parsing: A parser service consumes raw segments, validates them against the transaction specification, and transforms them into a normalized internal data model. This is where most of the complexity lives — handling variations between payers, dealing with optional segments, validating code sets.

Business Logic: The normalized data flows to domain services that apply business rules — eligibility determination, claims adjudication, whatever the domain requires.

Outbound: Responses are transformed back into EDI format, envelope-wrapped, and delivered via SFTP to the appropriate recipient.

The key design decision: normalize early. Don't let EDI-specific data structures leak into your business logic. Parse it at the boundary, transform it into your domain model, and let the rest of your system work with clean, typed data.

HL7 and DICOM

HL7 is the messaging standard for clinical systems — patient admissions, lab results, orders, updates. It's similar to EDI in concept but targeted at real-time clinical workflows. HL7v2 uses a pipe-delimited format. HL7 FHIR (the modern version) uses JSON/XML and REST APIs.

DICOM is the standard for medical imaging — X-rays, MRIs, CT scans. It defines both the image format and the network protocol for transmitting images between systems.

I've built integration engines for all three. The common thread: they all require careful handling of edge cases, strict validation, and reliable delivery guarantees. A dropped HL7 message could mean a missing lab result. A corrupted DICOM file could mean a lost scan.

Universal Lessons

Even if you never work in healthcare, the principles I've learned building these systems apply everywhere:

  1. Normalize at the boundary. Don't let external data formats infect your internal models.
  2. Validate aggressively. External data is never trustworthy. Validate every field before processing.
  3. Design for variability. Every payer, every hospital, every imaging device has slightly different interpretations of the "standard." Build your system to handle that variability gracefully.
  4. Invest in observability. When you're processing hundreds of thousands of transactions a day, you need to know immediately when something goes wrong.

Healthcare integration isn't glamorous. But it's deeply satisfying work — building the pipes that make the healthcare system function, one transaction at a time.