Most US hospital interfaces still hand HL7v2 messages off over MLLP, a thin framing protocol that has been carrying ADT, ORM, and ORU feeds across hospital networks since the late 1990s. HTTPS is the obvious alternative on paper, and a handful of newer integration engines now accept HL7v2 over HTTPS in addition to MLLP. The honest question for a US integration team in 2026 is not which transport is technically nicer, but which one the upstream EHR will actually emit, and what each transport costs to operate at the receiving end.
The short version: MLLP wins on EHR compatibility and operational reach, HTTPS wins on TLS hygiene and developer ergonomics, and the production answer is usually "both, with MLLP doing the heavy lifting and HTTPS as the auxiliary path for newer feeds." For surrounding context, the rest of our FHIR coverage covers adjacent transport and terminology topics.
Where MLLP Still Wins
MLLP rides directly on TCP, with a single start-of-block and end-of-block framing pair and no application-layer overhead. It is what every hospital interface engine has spoken for two decades, which means the integration team is rarely arguing about whether the EHR can emit it; the EHR can. Mirth Connect, Rhapsody, Cloverleaf, and InterSystems IRIS for Health all ship MLLP listeners as the default HL7v2 inbound surface.
The other thing MLLP has going for it is statefulness. The TCP connection stays open across many messages, ACK and NAK come back on the same channel, and the receiving side can pace the sender by holding ACK timing under load. In practice, a hospital pumping out 500 ADT messages a minute across a sustained TCP session is a much calmer load shape than the same flow arriving as 500 individual HTTPS requests.
The downside is the one everyone knows: vanilla MLLP runs in the clear. MLLP-over-TLS exists and is the right baseline for any feed that crosses a security boundary, but the operational reality is that some US hospitals still expect cleartext MLLP inside an IPsec tunnel rather than MLLP-over-TLS. That puts the security responsibility on the network team rather than the integration team.
Where HTTPS Wins
HTTPS as the HL7v2 transport sidesteps the cleartext problem entirely. The connection is encrypted by default, certificate management lives in the operating system or the load balancer rather than in the integration engine, and any modern observability stack can pick up HTTPS metrics without bespoke MLLP instrumentation. For US health systems that already terminate inbound TLS at a managed gateway, adding an HL7v2-over-HTTPS endpoint is a small change.
The honest cost is the request-per-message model. HTTPS does not naturally carry a long-running stateful session the way MLLP does, and each message pays the connection-setup cost unless the sender uses HTTP/2 multiplexing or persistent connections aggressively. Engines built around at-least-once delivery with a built-in __errors queue (Interbox is one example) tend to scale better in this shape, because the retry behavior survives a transient HTTPS failure without losing the message.
There is also the small matter of which EHRs will actually post HL7v2 to an HTTPS endpoint. The answer in 2026 is: very few do it natively. Most HTTPS-based HL7v2 ingestion happens through a sidecar that the integration team operates on the EHR side, converting an outbound MLLP feed into an HTTPS POST. That is fine, but it means HTTPS rarely replaces MLLP at the source; it shifts the boundary.
How Production Teams Actually Split the Two
The pattern that holds up in US deployments is MLLP at the hospital boundary, HTTPS inside the integration platform. The receiving MLLP listener accepts the EHR feed, the engine converts the framing, and the downstream pipeline runs over HTTPS or a queueing protocol the team prefers. That keeps the EHR side comfortable, gives the cloud-hosted side TLS-by-default, and avoids the worst of both transports.
The HAPI vs Smile Digital Health comparison covers the receiving side of that pattern in more depth, and the dedicated terminology servers vs EHR built-in code tables piece is useful background for the terminology lookups that follow ingestion.
The Practical Recommendation
Run MLLP, with TLS where the security boundary requires it, on the inbound edge that faces the EHR. Run HTTPS internally where the integration platform talks to itself. Do not try to push HTTPS as the inbound transport unless the upstream EHR vendor has explicitly committed to emitting HL7v2 over it, which most have not. The transport choice that ages well in a US hospital integration is the one that does not require the EHR vendor to do anything new.
Sources
- HL7 INM WG - Transport Specification: MLLP Release 1 (Spronk) — framing protocol authoritative spec
