Twenty minutes into a first call with a Trust, the IG lead asks the only question they came for: does our data leave our environment? Everything before that was preamble. For a lot of vendors the call effectively ends there, because their architecture assumes one shared cloud and there is no honest way to answer.
It is a fair question. It also has three different answers, and most procurement conversations never establish which one is being asked.
In brief
"Keep the data inside our walls" is not a single requirement. It covers three genuinely different postures: an outbound-only component inside your own environment, a single-tenant cloud deployment in a chosen region, and a fully self-hosted, air-gapped install. Working out which one your workload actually requires is most of the decision. Defaulting to the strictest option costs your team real operational effort and buys you nothing if the underlying constraint was jurisdictional all along.
The question that ends vendor calls early
The question lands early because for a meaningful share of Trusts it is not negotiable. An IG lead with a DSPT submission to defend, or a Head of Digital who has already been through one data residency argument with a board, is not looking for reassurance. They are looking for a description of where the payload physically sits and what crosses the boundary.
What usually happens next is the problem. The vendor says "yes, it's secure", the IG lead writes that down, and nobody establishes whether "secure" meant UK region, meant no inbound connections, or meant no connectivity at all. Six months later the integration architect discovers the answer was the first one and the policy required the third.
Three footprints, not three tiers
Name them plainly, and resist the instinct to rank them.
A hybrid, outbound-only footprint puts a lightweight component inside your environment. It initiates every connection outward and sends only operational metadata to a managed control plane. The clinical payload is processed locally and stays there.
A single-tenant cloud deployment runs the full platform in a dedicated instance in a region you choose, isolated from other customers, but still on a cloud provider's infrastructure.
A fully self-hosted, air-gapped deployment runs entirely inside your own infrastructure with no route to the public internet at all.
These are not three rungs of the same ladder. They answer three different versions of the question, and your Trust needs to know which version it is asking before it can judge whether a vendor's answer is good enough.
What outbound-only, metadata-only actually means
This middle option gets misread in both directions, so it is worth being precise.
Outbound-only means nothing external ever initiates a connection inward. No inbound firewall rule, no listening port exposed to a vendor, no standing route into your network. For the network team that is usually the single most important property on the page, because it removes the thing they would otherwise have to defend at every review.
Metadata-only means what travels outward is operational: queue depth, run status, error codes, timing. The HL7 message body and the FHIR resource stay inside your environment and are processed there.
It is a genuine middle ground. It is not air-gapping, and any vendor description should be specific enough that your IG lead can tell the difference without asking a follow-up question.
What air-gapped actually costs your team
The strictest option has real running costs, and they are worth naming before you commit to it.
Updates stop being something that happens to you and become something you schedule. Someone on your side receives an offline bundle, verifies its checksum, tests it in a non-production environment and signs off the change. That is a change advisory board item every time, not a background task.
Support looks different too. Nobody outside the perimeter can observe a disconnected system, so when a transform fails at 02:00 the diagnostic material is whatever your own logging captured. If your team cannot export an anonymised trace and read it themselves, air-gapping will hurt more than it protects.
None of this makes it the wrong choice. For workloads where policy genuinely rules out external connectivity, it is the only acceptable one. It just needs choosing deliberately rather than by reflex.
Where HSCN fits
HSCN is a network property, not a security posture, and the two get conflated constantly. HSCN-compatible means the deployment can be reached over the Health and Social Care Network rather than the public internet. It says nothing about whether the system has external connectivity at all.
A deployment can be HSCN-compatible and still call out for management traffic. It just does not do so over the open internet. If your requirement is "traffic must route over HSCN", say that. If it is "no external connectivity in any form", say that instead. They are different requirements and they lead to different architectures.
Choosing honestly
Work backwards from the actual constraint.
If the constraint is jurisdictional, single-tenant cloud in a UK region answers it with the least operational overhead. If the constraint is specifically that the clinical payload never leaves, an outbound-only, metadata-only footprint answers it while keeping central monitoring. If the constraint is a genuine policy ban on any external connectivity, self-hosted and air-gapped is the only honest answer, and your team absorbs the patching and monitoring burden that comes with it.
WeHub runs three deployment footprints for exactly this reason: Runner (outbound-only, metadata-only, inside your environment), Managed (single-tenant, Azure UK South) and Self Hosted (air-gapped, HSCN-compatible). The names matter less than the discipline of matching the footprint to the constraint rather than to the anxiety.
The bottom line
Before your next vendor call, write the constraint down in one sentence and be specific about which kind it is: jurisdictional, payload-specific, or a genuine ban on external connectivity. Take that sentence into the call and ask the vendor to answer it directly. If they respond with "yes, it's secure", you have learned everything you need to know about how the rest of the engagement will go.
