HL7 and FHIR Integration Services
We build and repair the interfaces between them. That covers new feeds, FHIR APIs on top of existing systems, and the monitoring that tells you when a message stops arriving.
What breaks today
Dropped messages go unnoticed
An interface engine queues, retries, and eventually discards. Without reconciliation, a missing ADT message shows up as a wrong bed count days later.
Every sender speaks a dialect
HL7 v2 leaves room for local variation. Two systems that both claim to send an ADT^A01 can disagree on field use, and the mapping lives in one person’s head.
FHIR coverage is partial
FHIR resources cover many workflows and miss others. Teams discover the gap after they have committed to a FHIR-only design.
Testing happens in production
Non-production feeds rarely resemble live traffic, so the first real volume arrives on go-live day.
What we build
Scoped during the assessment, then delivered in one to three week increments against your real systems.
HL7 v2 interfaces
ADT, ORU, ORM, SIU, and DFT feeds through your interface engine, with a documented field map for each sender and receiver.
FHIR R4 APIs
Read and, where the source system permits, write access to patient, encounter, appointment, and coverage data, with SMART on FHIR authorization when an app needs it.
Interface engine work
Channel design, filtering, transformation, and error queues in the engine you already run, such as Mirth Connect, Rhapsody, or Cloverleaf.
Reconciliation and monitoring
Message counts compared between sender and receiver, alerts on gaps, and a named owner for each alert.
Test harnesses with realistic traffic
Replayable message sets built from de-identified samples, so volume and edge cases appear before go-live.
What changes
We measure your baseline during the assessment and set targets against it. We do not promise a figure before that number exists.
- Missing messages detected within one reconciliation cycle
- Field mappings documented for every sender and receiver
- FHIR coverage gaps identified in design
- Go-live tested against realistic message volume
Systems this touches
Integration channel is chosen on verified capability in your environment, not on what is easiest to document.
- HL7 v2.x
- FHIR R4
- SMART on FHIR
- Mirth Connect
- Rhapsody
- Cloverleaf
- X12 270/271 and 837/835
Not sure this is the right workflow to start with? The $24,997 assessment exists to answer exactly that, and it frequently points somewhere other than where leadership expected. New to the topic? Read the practical guide to healthcare workflow automation.
Common Questions
What is HL7 integration?
HL7 integration connects healthcare systems by exchanging structured messages in the HL7 standard. A registration system sends an admission message, and the systems that need it, such as billing and the lab, receive it through an interface engine.
Is HL7 still relevant?
Yes. HL7 v2 still carries much of the day-to-day traffic inside hospitals, and FHIR sits alongside it. Most projects need both, so we design them together.
Is HL7 considered an API?
HL7 v2 is a message standard, not a web API. FHIR is the HL7 standard that defines a web API. Many teams expose FHIR APIs in front of systems that still speak v2 internally.
Talk it through with an engineer.
Tell us what this workflow costs you today and we will tell you honestly whether automating it is worth the engagement.
Start with a conversation, not a proposal.
A 45-minute call with a senior engineer. We will tell you honestly whether automation is the right answer for the workflow you have in mind.