Bidirectional Epic Integration for Hospital-at-Home

Healthcare Interoperability Case Study

Overview

A working HL7 v2 + FHIR R4 integration engine that moves admissions, diagnoses, and vitals in and out of Epic — built, demoed live, and tested end-to-end.

2

directions wired

5

FHIR resources

14

tests passing

0

messages dropped

▶ Watch the walkthrough View the code

Video Walkthrough

Full guided tour — architecture, live inbound/outbound demos, reliability and HIPAA posture, and the path to a live Epic connection.

The Problem

Every Hospital-at-Home platform stalls on the same thing: Epic.

A care platform can’t admit a patient, show a vital sign, or bill until it exchanges data with each health system’s Epic — in both directions, reliably, without dropping a message. That’s hard for four reasons:

It’s bidirectional (admissions in, vitals out)
It spans two protocols — HL7 v2 (legacy wire) and FHIR R4 (modern API)
It carries protected health information under HIPAA
Every Epic is configured differently per health system

This project is the layer that solves it — and proves it on a live stack rather than a slide.

What I Built — Thin Transport, Fat Engine

Mirth Connect owns the wire: MLLP framing and the acknowledgment back to Epic. A Python/FastAPI engine owns everything clinical and stateful — parsing, FHIR mapping, idempotency, retries, the audit trail, and the care-coordination domain. It deploys as just another service in a Python/Azure stack.

flowchart LR
    A["<b>Epic EHR</b><br/>HL7 v2 / MLLP<br/>FHIR R4 / OAuth2"] <--> B["<b>Integration Engine</b><br/>Mirth Connect + Python/FastAPI<br/>dedup · retry · dead-letter · audit<br/>PostgreSQL"]
    B <--> C["<b>HaH Platform</b><br/>Care-coord API<br/>React clinician UI<br/>PostgreSQL / Azure"]
    style B fill:#0E7490,color:#fff,stroke:#0E7490

Outcomes — Demonstrated End-to-End on a Live Stack

Metric	Result
Directions wired	Admissions in, vitals out
FHIR resources created & queried	5 (Patient, Encounter, Condition, CarePlan, Observation)
Automated tests passing	14
Dropped or duplicated messages	0

One admit message produces a fully cross-referenced clinical record — Patient, Encounter, Condition, and CarePlan. One vitals message writes four LOINC-coded Observations back, linked to that patient.

Reliability and HIPAA technical safeguards are built into the core. The engine was hardened against real-server failure modes a fake server hides.

What It Unlocks — One Integration Layer, Many Clinical Products

Remote patient monitoring — live vitals streaming from HaH devices into Epic
Care coordination & transitions — automated admit/discharge notifications
Analytics & population health — structured FHIR data feeds for dashboards
AI & agentic clinical workflows — LLM agents grounded in real EHR context
Multi-EHR expansion — architecture generalizes to Cerner, Meditech, and others

Tech Stack

HL7 v2 · FHIR R4 · Mirth Connect · SMART on FHIR · Python · FastAPI · PostgreSQL · Docker · HAPI FHIR · Prometheus · Azure · HIPAA / SOC 2-ready

Explore It

▶ Video Walkthrough

The full guided tour, with live HL7 and FHIR demos.

Watch on YouTube →

◆ Source Code

The runnable engine, Mirth channel, tests, and Docker stack.

Open the repo →

▣ Presentation Deck

Architecture, data flows, and the path to a live Epic connection.

Download slides →

I’m sharing this to get better — if you work in health IT, FHIR, clinical AI, or have shipped an Epic integration before, I’d value your candid take: what’s missing, what you’d do differently, and where this would break at a real Epic go-live.

Email me your thoughts Comment on the video Connect on LinkedIn