Mostly about building products, healthcare tech, and lessons learned along the way.
HL7v2 is how most hospitals have moved clinical data for 30+ years. How it works, why it's still everywhere despite being a 1980s standard, and what you need to know before you start integrating.
Next in HL7 & Mirth from zero · Part 2 of 3Mirth Connect: Part 1 - Getting Started with 🐳 Docker →
The standard that runs hospitals and confuses everyone
Imagine spending your career building modern applications, using the latest tools and frameworks that fit nicely into your toolbox. Then one day, your boss asks you to connect your software product to a system with patient records 😬.
This is how most of us land in healthcare data, and some of us never escape. Welcome to HL7v2: the workhorse behind healthcare interoperability.
EHRs transformed healthcare data management by replacing paper records with digital storage and retrieval. Care teams at any point of service can access timely, comprehensive patient information instead of hunting down physical charts.
The connectivity problem is still real, though. A typical health organization runs more than a dozen distinct EHR platforms, and most of them don't share data with each other. Integration efforts happen, but they're frequently limited to systems from the same vendor or systems enrolled in a specific network. For everyone outside those arrangements, HL7v2 is often the first or only data access option — and for many use cases, it's still the most reliable path.
HL7 (Health Level Seven) Version 2 is a messaging standard for clinical and administrative data exchange between healthcare software systems. The numbers tell the story:
95% of US healthcare organizations are using HL7 v2.x to exchange clinical information More than 35 countries have HL7 V2.x implementations
HL7 "HL7 Version 2 Product Suite"
Newer standards like HL7 v3 and FHIR exist, but HL7v2 persists for concrete reasons. It's been in production since the late 1980s, which means the healthcare market has had 30+ years to build systems around it. Replacing those systems costs money and effort: new interfaces, staff retraining, potential system replacements for anything that can't adapt. Many institutions simply haven't had the budget or appetite for that transition.
There's also the stability argument. Decades of production use means most edge cases and failure modes are well understood. That's a real advantage in healthcare, where surprises in data exchange can have patient safety implications. HL7v2's flexibility — often criticized for creating variability between implementations — has also let individual organizations customize it to their specific workflows without waiting for a standards body.
FHIR offers real advantages: modern web compatibility, cleaner data structures, better REST API support. But FHIR deployments in production still need to interface with HL7v2 systems, because that's what the existing infrastructure runs. HL7v2 isn't going away soon. The realistic path forward is FHIR sitting on top of HL7v2 foundations, not replacing them.
Five things will shape your first HL7v2 integration:
Pick the right tooling. The landscape is steep. Your team's existing skills matter more than which tool is theoretically best — a Java team that knows Mirth Connect will move faster than one trying to learn a Python-first solution.
Understand the infrastructure. HL7v2 typically runs over a raw TCP/IP socket with no built-in security. Modern cloud architectures assume HTTPS. Bridging that gap requires VPN tunneling or an on-premise gateway, which means infrastructure work before you write a line of integration logic.
Security layers on separately. HL7v2 predates the security-conscious internet. The standard approach is to lock down the network layer behind a VPC and tunnel over IPSec with IKE. That's functional, but it often adds weeks of stakeholder coordination and networking configuration to an otherwise straightforward integration timeline.
Message routing needs explicit design. Not every incoming message should go everywhere. ADT A08 Update messages, for example, can flood downstream systems if you're not filtering aggressively. Define your routing rules before you start, not after.
It's not JSON. Mapping HL7v2 to any modern format is manual, time-consuming, and typically driven by spreadsheets rather than API specs. Both HL7v2 (via Z segments) and FHIR (via extensions) support custom data, which helps — but it doesn't eliminate the mapping work.
| Name | Language | Difficulty | Cost | On premise | DevOps |
|---|---|---|---|---|---|
| Mirth Integration Engine | Java | High | Varies (owned by NextGen Healthcare); Community Edition available | Sits behind your existing Cloud infrastructure VPN, requires configuration. | Yes |
| Google Cloud Healthcare API | API based | Moderate | Based on GCP Pricing; Limited free tier available | Links to your existing Cloud infrastructure VPN. | Yes |
| Rhapsody | Proprietary | High | Contact sales for pricing; No free version | On Premise Gateway | Yes |
| Jitterbit | GUI based | Moderate | Varies by edition and usage; Community Edition available | On Premise Gateway | Yes |
| Redox | API based | Moderate | Contact sales for pricing; No free version | On Premise Gateway | Yes |
| Iguana | Lua (for transformations) | Moderate | Contact sales for pricing; Demo available | On Premise Gateway | Yes |
| MuleSoft | Java, options for scripting/connectors | High | Varies by edition and usage; Community Edition available | Yes | Yes |
| Amazon HealthLake | AWS based | Moderate | Based on AWS Pricing; AWS services have a free tier | Sits behind AWS site to site VPN, requires configuration. | Yes |
| Retrohook (Beta) | GUI Based (Web) | Low | Contact Sales, free trial version | Yes (Web based GUI) | No |
