OpenConnect — HIPAA HL7 IoT Gateway

Why clinical data still gets typed in by hand

A patient monitor already knows the vitals it is measuring. The platform clinicians actually work in knows them only if something carries them across. In a great many hospitals that something is a person — someone reads a value off a screen and enters it into a system, for every patient, on every shift, around the clock.

The gap is not caused by missing data. It is caused by data sitting inside devices that speak a different language to the software downstream, on a network that deliberately does not reach the internet. OpenConnect exists to close it: ingesting clinical data from patient monitors inside hospital networks and routing it into the HealthMosaic platform.

Manual transcription is also where clinical data quality quietly erodes. Every hand-entered value is an opportunity for a transposed digit, a reading missed during a busy period, or a delay between measurement and record. Automating the path removes a class of error that is unusually hard to catch afterwards, because a plausible wrong number looks exactly like a right one.

Three constraints that ruled out the obvious design

It cannot live on the internet. There is no public URL by design — the system runs entirely inside hospital infrastructure, next to the devices it listens to. That single fact removes most of a modern architecture toolkit: no managed cloud services, no third-party observability platform, no remote session when something misbehaves at three in the morning. Whatever the gateway depends on has to exist inside the hospital network, and whatever it does has to be diagnosable there by someone standing in the building.

The devices do not pause. Over 200 monitors emit clinical messages around the clock. There is no maintenance window during which nothing is being measured, no overnight lull to deploy into, and no acceptable version of losing an hour of readings during an upgrade. Continuous emission with no tolerance for loss is a substantially harder target than raw throughput, because it removes the usual escape hatch of catching up later.

The payload is protected health information. HIPAA compliance and HL7/FHIR interoperability are non-negotiable in this environment, and that governs more than the application. What may be written to a log while troubleshooting, where a message may sit while waiting for a retry, and how long anything persists all become design decisions rather than defaults — constraints that bind the operational tooling as tightly as the code.

What the gateway actually does

Sitting next to the devices is the decision everything else follows from. A gateway inside the network can accept a message the moment it is emitted rather than waiting on a link out of the building, which is what makes a delivery guarantee achievable at all. The fragile part of the path becomes bounded and known, and a downstream interruption can be absorbed and retried without the monitors ever being aware there was a problem.

The interoperability layer is where most of the difficulty lives. HL7 is a standard in the sense that everyone implements it and a dialect in the sense that implementations differ — field usage varies by vendor and by device generation, so a parser built against one hospital's traffic will eventually meet a message it rejects for reasons that are not clinical. Translating into FHIR gives the downstream platform one consistent modern shape to consume regardless of what arrived, which is precisely why the translation belongs in a layer between rather than inside HealthMosaic, where every dialect would become the platform's problem forever.

Handling PHI correctly runs through all of it. Clinical payloads cannot be treated as ordinary application data, and the places engineers reach for by reflex — verbose logs, a copy of the request kept for inspection, a buffer that outlives the delivery it was holding — are exactly the places this environment cannot allow. Getting those wrong is a compliance event, not a bug report.

There is a final requirement that shapes the style of the whole thing: the gateway has to be operable by people who did not build it, inside a network its author cannot reach. That biases every choice toward the boring option — predictable behaviour, legible failure, and state somebody on site can inspect without a debugger.

What the numbers mean in this setting

10,000+ clinical messages a day across 200+ monitors is better read as a rate than a total. This is a system that is never idle, sustained indefinitely, in an environment where restarting to clear a problem is not a casual act.

The 99% delivery rate is the figure that matters most, because in clinical data the interesting number is never how much arrived — it is how much did not. A delivery rate is only meaningful if both ends are being measured, which means the system was built to know what it sent and what was acknowledged rather than assuming those were the same thing. That distinction is the difference between a gateway that reports success and one that reports the truth.

95% of manual data entry eliminated is the same achievement stated from the ward instead of the server rack, and the ~$400K/yr estimated savings is what that recovered clinical time is worth to the organisation. Both are downstream of the delivery rate: automation is only worth adopting if the staff who used to do the typing can trust that stopping is safe.

The client's assessment names what made it work — that HIPAA compliance and HL7/FHIR interoperability aren't optional, and that "he doesn't just write code, he thinks like a product owner." In an environment where the requirements come from regulation and hospital operations rather than a product backlog, understanding why a constraint exists is not a soft skill. It is what prevents the wrong thing being built correctly.