Bridging the Healthcare Divide: Building an HL7-to-FHIR Transformation Pipeline with Mirth Connect & Node.js

By Hisham Hussein Alrashdan

In the world of healthcare technology, we are often caught between two eras. On one side, we have legacy Electronic Medical Records (EMR) systems speaking HL7 v2.5—a pipe-delimited text standard from the 1980s. On the other, we have modern cloud platforms, analytics tools, and mobile apps expecting FHIR R4—a robust, RESTful JSON standard.

Bridging this gap usually requires expensive middleware or months of manual integration.

I built InfoGleam Health as a Proof of Concept (PoC) to demonstrate how we can solve this interoperability challenge using open-source tools, modern DevOps practices, and a microservices architecture.

The Problem: The “Tower of Babel” in Hospitals

The core engineering challenge in healthcare interoperability is data normalization.

• Legacy Systems emit streams of cryptic text (HL7) via MLLP (a raw TCP/IP protocol).
• Modern Systems require structured JSON resources via HTTP/S.

Without a bridge, these systems cannot communicate. My goal was to create a Reference Implementation that automates this translation in real-time, is easy to deploy, and separates the parsing logic from the business logic.

The Solution: InfoGleam Health

InfoGleam Health is a lightweight, containerized pipeline that ingests HL7 v2.5 messages and outputs standard FHIR R4 resources.

The architecture is designed around “Separation of Concerns.” Rather than building a monolithic application, I decoupled the message transport from the transformation logic.

High-Level Architecture

The system runs on Docker Compose and consists of three distinct layers:

1. Ingestion Layer (Mirth Connect): An industry-standard integration engine that listens for raw MLLP traffic and parses the HL7 pipes and hat characters.
2. Transformation Layer (Node.js/Express): A microservice that handles the complex logic of mapping raw data into the FHIR schema.
3. Orchestration (Docker): A unified environment that allows the entire stack to spin up with a single command.

Why I Decided to Separate Mirth and Node.js

A common approach is to do everything inside Mirth Connect using its internal JavaScript engine. However, for this project, I made an architectural decision to offload the heavy transformation logic to a dedicated Node.js service.

My reasoning was twofold:

1. Modern Tooling: Node.js allows us to use the rich ecosystem of NPM packages (like FHIR validators) that aren’t easily available inside Mirth’s legacy Java environment.
2. Testability: By isolating the transformation logic in a Node app, I can write standard unit tests, implement CI/CD pipelines, and scale the transformation service independently of the listener.

Technical Implementation: The Data Flow

Here is how the system processes a patient admission event (ADT^A01) in real-time.

Step 1: Ingestion

The hospital system sends a raw HL7 string. To the untrained eye, it looks like noise:

MSH|^~\&|HOSPITAL|INFOGLEAM_REF|...
PID|1||TEST000001||PATIENT^TEST^A||19700101|M|||100 TEST ST||5551234567||...

Step 2: Parsing & JSON Conversion

Mirth Connect catches this message on port 19002. Using a JavaScript transformer I wrote, it extracts specific segments (Patient ID, Name, DOB) and converts them into a raw JSON payload, forwarding it to the Node.js service.

Step 3: FHIR Normalization (The Heavy Lifting)

The Node.js service receives the raw JSON and applies the FHIR R4 schema rules. This is where the engineering complexity lies—handling date formats, mapping gender codes, and structuring arrays.

// The result is a clean, standard FHIR resource
{
  "resourceType": "Patient",
  "id": "patient-1736674245123",
  "identifier": [{"value": "TEST000001"}],
  "name": [{"family": "PATIENT", "given": ["TEST"]}],
  "gender": "male",
  "birthDate": "1970-01-01",
  "address": [{"street": ["100 TEST ST"]}]
}

Developer Experience (DX)

One of my primary goals was usability. Integration engines are notoriously difficult to set up. I utilized Docker to ensure that any developer could spin this project up in under 60 seconds.

No installing Java. No configuring databases. Just:

git clone https://github.com/InfoGleam/infogleam-health-poc
npm start

Disclaimer: From Demo to Production

It is important to note that InfoGleam Health is a Proof of Concept. While the logic is sound, a production environment requires strict adherence to HIPAA/GDPR regulations. To take this from “Demo” to “Live,” the following would be required:

• Security: Implementing TLS 1.3 for all transport layers and OAuth2 for API authorization.
• Persistence: Replacing the in-memory processing with a durable message queue (like RabbitMQ) to ensure no data is lost during a crash.
• Auditing: Comprehensive logging of every data access event.

Conclusion

This project served as a deep dive into the complexities of healthcare interoperability. It demonstrates that by combining legacy-compatible tools like Mirth Connect with modern microservices patterns in Node.js, we can build systems that are robust, testable, and ready for the future of digital health.

You can view the full source code, run the simulation, and check out the documentation on my GitHub.