Cross-Organization HL7 Exchange: VPN, SFTP, TLS, or Direct

Inside your own walls, HL7 interfaces are a solved problem. An engine like Mirth Connect or OIE speaks MLLP, the message types are well understood, and standing up a channel between two systems on the same network is a day of work.

Then the interface needs to cross the property line: results to a referring group, ADT to a partner facility, orders from a clinic on somebody else’s network. The channel logic is the same. Everything around it changes, and a one-day interface becomes a six-week project with a kickoff call.

This post is about the gap between those two numbers.

Where the time goes

The delay is almost never HL7. It is everything wrapped around it.

Gantt chart of where six weeks go on a cross-organization HL7 interface: the actual channel is a lit two-day bar in week one, while security reviews at both organizations, serialized firewall and VPN changes, certificate and credential exchange, and coordinated test windows fill the remaining weeks before go-live

Two organizations on the same ruled ground, each stamped 10.0.0.0/8, with a network address translation block between them carrying the one link that crosses

Two security reviews. Each organization’s security team has to approve a new network path to an outside party. Neither review starts until the other side has produced its paperwork.
Two IT queues. The VPN config or firewall exception is a change request in both organizations, each with its own backlog, change windows, and approvers. These serialize more often than they parallelize.
Address planning. Both networks use private address space, and two hospitals with overlapping 10.0.0.0/8 ranges is common. NAT rules appear, and documentation of the NAT rules usually does not.
Coordinated testing. Two interface teams that share neither a calendar nor a ticketing system have to find a window together, which adds days to every iteration.

Every one of these is a coordination cost, paid in wall-clock time. And they recur: certificate renewal, an IP change on either side, a firewall audit that flags the rule nobody remembers the reason for.

The four patterns

Scorecard of four ways to move HL7 between organizations, each with a glyph and one-to-four dot ratings: site-to-site VPN with MLLP, SFTP batch drops, TLS-wrapped MLLP, and an HIE intermediary, rated on setup effort, latency, standing exposure, and per-partner scaling, where more dots mean more cost

A site-to-site VPN drawn in section as a wide bore between two buildings, dimensioned as everything the tunnel reaches, with the single interface it was built for running as a thin lit line along its floor

Site-to-site VPN. The default answer. An IPsec tunnel joins the networks, and MLLP flows as if local. It works, and it carries the highest coordination cost: everything in the list above, plus a permanent piece of shared network infrastructure that both sides maintain. The tunnel also grants network-level reachability far beyond the one interface, which each security team then constrains with more rules. The per-partner economics are the real problem. Every new trading partner is a new tunnel, so ten partners means ten of everything.

An SFTP drop box taking a lit batch of files through a slot on a schedule, with the return path running back as a dashed line that stops at an empty ring because no acknowledgement comes back

SFTP batch drops. One side runs an SFTP server, and the other pushes or polls files of batched messages. Simple to approve and well understood by security teams. It is also the reason “why is the results feed 20 minutes behind” is a recurring ticket. Real-time semantics are gone: no MLLP ACKs, so delivery confirmation becomes file-level bookkeeping, and failures surface as gaps someone notices later. Adequate for a nightly census. Wrong for anything a clinician is waiting on.

A host block with a recessed standing port and a lit padlock on its face, beside an allowlist card ruled into four entries with a fifth drawn fainter beneath them because it was added later

TLS-wrapped MLLP. Expose an MLLP listener wrapped in TLS, exchange certificates, allowlist the partner’s IPs. Lighter than a VPN, real-time, and cryptographically sound when both sides manage certificates well. In practice it inherits the firewall-exception paperwork, adds certificate lifecycle management across two organizations, and pins both sides to static addressing. It is also still a listening service on the internet, guarded by an allowlist that loosens over time.

The HIE. Where both organizations already participate in a health information exchange that carries the data type in question, the connectivity problem is delegated. When it fits, use it. The constraint is fit: point-to-point operational feeds (a specific results interface to a specific partner, with specific mapping) are often outside what the exchange carries, and onboarding a new use case through an intermediary has its own timeline.

A sealed agreement standing on one side and a rack of firewall rule cards on the other, with a lit dimension line measuring the drift between authorization, which lives in documents, and enforcement, which lives in network config

All four share one weakness. The authorization lives in documents (BAAs, DUAs, change tickets) while the enforcement lives in network config, and the two drift. The firewall rule outlives the agreement. The agreement’s scope is invisible in the tunnel. Ask “what exactly are we sharing with this partner today?” and at most organizations the answer takes a week to assemble.

Making the agreement the interface

The structural fix is to make the governed relationship, rather than the network path, the thing you build. This is OpenShare’s model, and it changes the order of operations.

Swimlane of two organizations connecting through OpenShare: A finds B in the directory and sends a contact request, B accepts and the agreement forms, B publishes its listener and grants it to A, the connection provisions itself, and both engines dial out so HL7 flows engine to engine over an end-to-end encrypted pipe the platform never sees

Find the partner in the directory and send a contact request. Accepting it creates an agreement, the standing relationship between the two organizations.
Grant access to a channel. The receiving organization publishes the listener that will take the partner’s messages and grants that channel to that partner. The grant is the scope: this channel, this partner, revocable at any time. Sending to a partner works the same way in reverse: they publish the listener and grant it to you.
The connection provisions itself. When the grant is approved, a secure connection is established between the two engines. In the app, the connect wizard walks both sides through the sequence and shows live status until the link is up.

The transport underneath resolves the network problem the same way outbound-only remote access does. Each engine’s plugin dials outward, so no inbound firewall change, VPN, or static IP is needed on either side. The messages travel end-to-end encrypted directly between the two organizations. The platform coordinates the introduction and the agreement but cannot read the traffic. Your engine keeps speaking ordinary HL7 to its local systems, and the cross-organization leg is one more channel.

OpenShare connect wizard choosing what to share with a partner organization: send data, receive data, or connect your own servers — The connect wizard: both sides walk through a scoped agreement, then the connection provisions itself.

What this does to the six weeks: the security-review conversation changes from “we are opening a network path to an outside organization” to “our engine makes an outbound connection, and this named channel is shared with this named partner under a revocable grant”. The two IT queues are not consulted, because nothing on either firewall changes. Coordinated testing still involves two teams, but they are looking at the same live connection status in the same interface, which removes the “is it us or them” round-trips. The channel build is unchanged, because that part was never the problem.

An agreement record whose lit row names one channel and one partner, with the connection that grant holds up drawn as a lit link between two engines below it, and a revoked row whose link fades out to an empty ring

The governance question also gets a screen instead of an archive. The agreement lists its grants, and each grant names the channel and the partner. Revoking a grant tears the connection down. Either organization can also cut data movement across the board in one action. The authorization and the enforcement are the same object, so they cannot drift.

What stays true

Some scope, because interface engineers can tell when a product post is overclaiming:

The mapping work is still yours. The partner’s Z-segments, their ADT event quirks, the field they populate differently: that is interface engineering, and no connectivity layer removes it. (Our HL7 integration services team does this for a living if you want the help.)
Both sides participate. The receiving organization accepts the agreement and runs an engine with the plugin. A free account and one server is enough to receive, and the installer version ships OIE with the plugin included.
Batch still has its place. A nightly flat-file drop that works and satisfies everyone does not need replacing for its own sake. The case for a direct connection is real-time feeds, new partners, and everywhere the VPN paperwork is the bottleneck.

A test case

Pick the next partner interface on your roadmap, the one currently waiting on a kickoff call, and price the two paths: weeks of network coordination against an afternoon of agreement, grant, and channel work. Create a free account, or start with the product tour. For the messaging layer itself, our guides on HL7 message types and HL7 vs FHIR cover the content going through the pipe. If the data crossing organizations is imaging rather than messages, the DICOM version of this problem has its own post.

Frequently Asked Questions

What is an HL7 interface?

A configured connection that moves HL7 v2 messages between two systems: a sender, a transport (usually MLLP over TCP, sometimes a file drop), and a receiver that acknowledges every message. Inside one organization an interface is a channel on an engine like Mirth Connect or OIE, and standing one up is a day of work. Between two organizations the same channel also needs a network path both security teams will approve, which is where the weeks go.

How do two hospitals connect their HL7 interfaces?

Traditionally one of four ways: a site-to-site VPN carrying MLLP, an SFTP server one side polls for batch files, a TLS-wrapped MLLP listener behind a firewall exception, or an HIE intermediary both sides already belong to. Each requires network engineering coordinated across both IT departments. The newer alternative is direct engine-to-engine exchange over an outbound-only encrypted connection, which is what OpenShare provides.

Can you send HL7 messages over the internet securely?

Yes, but not bare: MLLP itself has no encryption or authentication, so it must ride inside something. The established options are a VPN tunnel or TLS-wrapped MLLP with exchanged certificates. OpenShare connections carry HL7 end-to-end encrypted between the two engines, with no inbound firewall change on either side.

Why do cross-organization interface projects take so long?

The interface itself is rarely the slow part; a working Mirth channel is a day or two. The weeks go to everything around it: security review and approval of the network path at both organizations, VPN or firewall changes moving through two separate IT queues, certificate or credential exchange, and scheduling test windows across teams that do not share a calendar.

What is a sharing agreement in OpenShare?

The governed relationship between two organizations. One side sends a contact request, the other accepts, and the resulting agreement is the frame inside which channel access is granted. Each grant is scoped to a specific published channel and a specific partner, both sides see exactly what is shared, and any grant, or the whole agreement, can be revoked at any time.

Connecting HL7 Between Two Organizations