One RPM Platform, Two EHRs: Bi-Directional HL7 Integration with Epic and athenahealth

Executive Summary

A US remote patient monitoring (RPM) provider needed its platform to plug into hospital EHRs two things at once: enroll patients automatically when a clinician decides to monitor them, and push device readings back into the patient's chart where the care team already works — with no separate portal to check.

The catch: hospitals do not agree on what triggers RPM enrollment. We built two bi-directional HL7 and FHIR integration flows on a shared middleware design — one for Epic (order-driven) and one for athenahealth (registration-driven) — so the same RPM application works against both EHRs without changing its own code.

The Challenge: One RPM Platform, Two Very Different EHRs

The RPM platform collects readings from home devices — blood pressure cuffs, pulse oximeters, glucometers, weight scales — and applies clinical alerting. To be useful to a hospital's care team, patients have to be enrolled the moment monitoring is decided, and readings have to land back in the chart automatically.

But the trigger model differs by EHR. In Epic, remote monitoring is a clinical order — a physician prescribes it and Epic emits an ORM (Order Message). In athenahealth, enrollment is registration-driven — a patient registered into a care program fires an ADT^A04 (Register a Patient) event. Same outcome, two different triggers, two different message shapes, two different sets of edge cases.

Solution: Mirth Connect as the Universal Translator

We put Mirth Connect in the middle as the integration engine and gave the RPM application a single, EHR-neutral contract: it receives enrollments as JSON over REST and returns results as JSON. Mirth absorbs every HL7 difference — inbound and outbound — so the RPM product never has to know which EHR it is talking to. This is the custom healthcare software development pattern we use whenever a product has to interoperate with multiple hospital systems.

Use Case 1 — Epic (Order-Driven Enrollment)

In Epic's workflow, enrolling a patient in remote monitoring is a deliberate clinical decision. The ORM message is information-rich: it carries demographics and the order specifics — what is being monitored and by whom.

1. Physician places the order. The treating physician orders remote monitoring — for example, blood-pressure tracking for a hypertensive patient post-discharge.
2. Epic transmits an ORM^O01. The message carries PID (demographics), PV1 (encounter), and ORC/OBR (order specifics) over MLLP.
3. Mirth parses and maps. It extracts MRN, name, DOB, ordering provider, and the monitoring program, then maps HL7 fields to the RPM enrollment schema.
4. Patient enrolled via REST. Mirth calls the RPM API to create the patient, assign devices and program, and activate monitoring.
5. Readings flow back as ORU. The RPM app pushes results as JSON; Mirth converts them to an HL7 ORU^R01 — one LOINC-coded OBX per reading — and delivers them to the Epic chart.

Use Case 2 — athenahealth (Registration-Driven Enrollment)

athenahealth treats enrollment as a registration event rather than a physician order. The ADT^A04 payload is demographics-heavy and includes insurance and guarantor data, which enables billing-eligibility checks at enrollment time.

1. Patient registered to a care program. Staff register the patient into a program that includes remote monitoring — for example, chronic disease management for diabetes or heart failure.
2. athenahealth fires an ADT^A04. The message carries demographics (PID), program and visit info (PV1/PV2), and guarantor/insurance (GT1/IN1) over MLLP.
3. Mirth maps the program identifier. It uses the care-program identifier from PV1 to determine which monitoring program to assign.
4. Patient enrolled via REST. Mirth checks for duplicates by MRN, then creates the profile, assigns devices, and activates monitoring.
5. Readings flow back as ORU. Results return as JSON and are converted to ORU^R01 messages posted to the athenahealth chart.

Epic vs. athenahealth, Side by Side

Two trigger models, one platform. The middleware absorbs the difference so the RPM application keeps a single JSON contract.

Dimension	Epic — ORM	athenahealth — ADT^A04
Onboarding trigger	Physician places an explicit RPM order	Patient registered into a care program
Trigger message	ORM^O01 (Order Message)	ADT^A04 (Register a Patient)
Who initiates	Ordering physician via order entry	Registration / enrollment staff
Intent signal	Order details specify what is monitored	PV1 program identifier sets monitoring type
Demographics	Moderate: PID + PV1 + OBR	High: PID + PV1 + PV2 + GT1 + IN1
Results return	ORU^R01 back to Epic	ORU^R01 back to athenahealth

Built for the Messy Reality

Real integrations fail in predictable ways, so we designed for them up front. Reliability is the difference between a demo and a production healthcare AI solutions workflow that a care team can trust.

• Validation + NACK. Incomplete demographics on an inbound order or registration are rejected with an HL7 NACK and logged for review — nothing half-formed reaches the RPM app.
• Duplicate guard. Duplicate registrations are caught by MRN check before the enrollment call; existing patients are updated, not duplicated.
• Queue + auto-retry. If the RPM app is unavailable, enrollment requests queue and retry automatically once connectivity returns.
• Backoff + dead-letter. Failed result deliveries retry with exponential backoff and escalate to a dead-letter queue after the configured threshold.
• Full audit trail. Every ORM order and ORU result is logged by Mirth — a complete, reviewable integration audit trail.
• Lifecycle sync. Order cancellations and athenahealth A03/A08 events unenroll or update the patient, keeping monitoring status in sync with the source system.

The Outcome

RPM results flow directly into Epic and athenahealth in near real-time — no manual data entry, no separate portal for the care team to check. Because Mirth abstracts the HL7 differences between the two EHRs, the RPM application stays EHR-neutral: the same JSON contract serves both hospitals, and the same channel pattern extends to ADT^A08 updates and A03 discharges for full patient-lifecycle management. Adding the next EHR becomes a middleware exercise, not a rebuild of the product.

• Closed-loop care coordination — readings appear in the chart the care team already uses.
• Trigger-flexible enrollment — order-driven for Epic, registration-driven for athenahealth, one platform.
• EHR-agnostic RPM app — the product speaks JSON; the HL7 lives in the middleware.
• Auditable and resilient — NACKs, retries, dead-letter queues, and a full message log.

Why Nirmitee

Healthcare is the only industry we serve. We have built 100+ AI-enabled healthcare products — production systems, not POCs — with 70+ healthcare-focused engineers. We have EHR integration experience with Epic, Cerner, Allscripts, and athenahealth, are HL7 v2 and HL7 FHIR experienced, and ship on a FHIR R4 native architecture. Nirmitee.io is HIPAA-compliant, SOC 2 Type II, and ISO 27001 certified.

This case study describes Nirmitee.io engineering patterns. It does not include actual Protected Health Information (PHI). All client-data examples are synthetic or de-identified per HIPAA Safe Harbor. Client identity withheld under NDA.