One interoperability tier, not one integration per device family
Remote patient monitoring only works if physiological data from many different device vendors and formats ends up looking identical by the time a clinical system reads it. This case study covers the interoperability tier built to do that translation once, centrally, instead of scattering device-specific parsing logic across every downstream consumer.
At a glance
- Problem
- Connected medical devices from a third-party device vendor (blood pressure cuffs, glucometers, pulse oximeters, and smart scales) each transmitted physiological telemetry in a proprietary, device-specific format. Neither the clinical microservices platform nor the hospital partner network it fed could ingest that traffic directly, and every new device family risked becoming a one-off, hand-built parser.
- Approach
- A dedicated interoperability host running NextGen Mirth Connect as the single translation point: every device family's proprietary payload is normalized into HL7 v2.5.1 and JSON before it reaches either the internal microservices platform or the external hospital partner feed, so neither side ever has to know the other's format.
- My contribution
- Healthcare interoperability & integration engineering
Key results
How it works
The problem
Connected medical devices from a third-party device vendor (blood pressure cuffs, glucometers, pulse oximeters, and smart scales) each transmitted physiological telemetry in a proprietary, device-specific format. Neither the clinical microservices platform nor the hospital partner network it fed could ingest that traffic directly, and every new device family risked becoming a one-off, hand-built parser.
The architectural solution
A dedicated interoperability host running NextGen Mirth Connect as the single translation point: every device family's proprietary payload is normalized into HL7 v2.5.1 and JSON before it reaches either the internal microservices platform or the external hospital partner feed, so neither side ever has to know the other's format.
- 01 Device posts over HTTPS Blood pressure, glucose, SpO2, and weight readings arrive from the device vendor's cloud gateway as encrypted HTTPS POSTs, in the vendor's own proprietary payload shape.
- 02 TLS termination at the edge An Nginx reverse proxy terminates TLS on the integration host and forwards the request to the interoperability engine over a local, unencrypted hop: the only place decrypted traffic exists is on that single host.
- 03 Channel-based transformation A dedicated Mirth Connect channel per device family maps the vendor payload into HL7 v2.5.1 segments and a normalized JSON representation, logging message state (received, transformed, sent, errored) to a local datastore for audit and replay.
- 04 Dual delivery The transformed message is delivered to the internal microservices platform for real-time processing and, where a care relationship exists, to the partner hospital network in the format its EHR expects.
Every device vendor speaks a different language
Medical IoT devices don't share a wire format. A blood pressure cuff, a glucometer, and a smart scale from the same vendor can each post readings in a different shape, and a device from a different vendor entirely might use raw XML, HL7, or a proprietary binary layout. Healthcare EHR systems and internal clinical platforms, meanwhile, expect data in recognized healthcare interoperability standards: chiefly HL7 v2/v3 and FHIR.
Left unaddressed, that mismatch pushes translation logic outward: every consuming system ends up writing and maintaining its own parser for every device format it needs to understand. That doesn't scale past a handful of integrations, and it means a hospital partner's EHR team would need to understand a device vendor's proprietary schema directly.
Why this needed a dedicated tier, not a library
- New device families are a routine occurrence, not an edge case. A remote patient monitoring program adds device types as clinical programs expand: each one needs its own transformation logic somewhere.
- The hospital partner network only speaks standard formats. An external EHR integration isn't going to accept a vendor-proprietary payload; it expects HL7 or FHIR at the wire level.
- Message state needs to be independently auditable. For a HIPAA-governed telemetry stream, knowing which messages were received, transformed, delivered, or errored has to survive independently of whatever's consuming the message downstream.
A single interoperability host in the request path
[ Medical IoT Device Fleet ]
(BP cuff · Glucometer · Pulse oximeter · Smart scale)
│ HTTPS, vendor-proprietary payload
▼
[ Nginx reverse proxy — TLS termination ]
│ plaintext, localhost only
▼
[ Interoperability engine — per-device-family channels ]
┌─────────────────────────────────────────────┐
│ Parse → Validate → Transform → Track state │
└─────────────────────────────────────────────┘
│ HL7 v2.5.1 + normalized JSON
┌─────┴─────┐
▼ ▼
[ Clinical [ Partner hospital
microservices network (EHR) ]
platform ]Every device family is one channel in the interoperability engine, not one integration in every downstream system. Adding a new device vendor means writing one new channel; it doesn't touch the microservices platform or the hospital partner integration at all.
Implementation notes
- TLS terminates once, at the edge of one host. The reverse proxy in front of the interoperability engine is the only place the connection is ever encrypted-to-plaintext; everything behind it stays on a private, localhost-only listener.
- Message state is tracked independently of delivery. Every message's lifecycle (received, filtered, transformed, sent, errored) is written to a local datastore, so a delivery failure downstream is diagnosable without needing logs from the consuming system.
- The transformation layer, not the devices or the consumers, owns the schema contract. Device vendors and downstream consumers never need to agree on a format directly: they each only need to agree with the interoperability engine.
A silent restart failure after a routine OS patch
During a routine operating-system security patch cycle, the interoperability engine's host rebooted as expected: but telemetry uploads began failing immediately afterward with 502 Bad Gateway at the reverse proxy.
Investigation and root cause
- The reverse proxy's error log showed a connection refusal to the local interoperability engine port, meaning the process wasn't listening at all: not a timeout, an absence.
- Checking the process table confirmed the engine's Java service hadn't started automatically after the reboot.
- The actual cause was a stale lockfile on the local message-tracking database's socket, left behind from the pre-patch shutdown, which blocked the service from acquiring its database connection on startup.
Remediation
- Cleared the stale database socket lock and restarted the local database daemon.
- Manually started the interoperability engine and verified the port was listening before reopening the reverse proxy.
- Verified end-to-end device payload processing before considering the incident closed.
Because the device vendor's own client software queues and retries failed uploads, no telemetry readings from the outage window were lost once the service came back: the fix was to the availability of the pipeline, not to any missing data once it resumed.
Follow-up
A systemd watchdog script was added to detect and clear this same socket-lock condition automatically, so the same failure mode after a future patch cycle would self-heal instead of requiring the same manual diagnosis again.
Questions about this case study?
I'm happy to go deeper on the message-transformation design, the TLS/reverse-proxy setup, or the production incident below.
anupojuprudhvi@gmail.com