Sovereign Digital Healthcare: The Layer Nobody Writes Press Releases About
A Swiss watchmaker’s reputation rests on what you cannot see. The visible gears that move the hands of a fine timepiece are not what separates a precision instrument from a toy. They are necessary, they are beautifully finished, and a knowledgeable buyer will inspect them. But they are not the watch.
The watch is the escapement. That small, precisely engineered mechanism converts the stored energy of the mainspring into regulated, measurable motion. It ticks behind the dial, hidden from the wearer, doing the one job that everything else depends on. Remove it, and the most beautifully decorated movement becomes scrap metal.
The same principle holds for sovereign digital infrastructure. The visible components — the platform, the cloud provider, the containerised workloads, the data centre on home soil — are necessary and impressive. They are also the easier part to talk about, and the easier part to put in a press release. But they are the gears and the hands.
Sovereign compute is necessary. It is not sufficient.
Why HIN’s Choices Are a Blueprint, Not a Case Study
HIN — Health Info Net — sits behind roughly 90% of Swiss healthcare stakeholders. Doctors, hospitals, pharmacies, insurers, laboratories. When HIN modernises, it is not running a pilot. It is moving the trust substrate of an entire national sector.
So when Red Hat announced at its Summit in Atlanta in May 2026 that HIN had migrated to Red Hat OpenShift, running on two sovereign Swiss clouds — Cloudscale and Exoscale — and managed 24×7 by VSHN with a target availability of 99.99%, that was not a routine vendor win. It was a regulated sector betting its operational future on an open architecture, deliberately split across two providers so that no single vendor controls the dial tone of Swiss digital healthcare.
The work was serious, and the people doing it deserve naming. Aarno Aukia, co-founder of VSHN, described the architectural choice plainly: “We chose Red Hat OpenShift to meet HIN’s security and multitenancy requirements. The solution provided the right foundation to build out the appropriate security architecture.” His team stood up the new environment in 36 hours. Mohammad Alavi, CTO of HIN, described what the migration changed inside his own organisation: “We’ve never had a rapid experimentation approach before, and our legacy environment did not enable us to use automation. It was an amazing experience to switch to DevOps and empower our developers with a whole new culture.”
Richard Zobrist, Red Hat’s Switzerland Country Manager, put the strategic frame on it: “Digital sovereignty requires operational control over technology, strategic flexibility and trust.”
But the case study mentions one service almost in passing. Encrypted messaging for doctor-patient communications. That single phrase is where the more interesting story begins.
Sovereign Infrastructure Stores Data. Trust Infrastructure Moves It.
There are at least two very different things that “encrypted messaging” can mean, and most discussions in our industry conflate them so completely that the more important meaning disappears from the conversation entirely.
The easy version is TLS in transit. Bytes are scrambled between the user’s device and the platform’s servers, and again between the platform and the recipient. This is table stakes. Every modern messaging system does this. It protects against passive eavesdroppers on the wire and against unsecured public WiFi. It does not, in any structural sense, protect against the platform itself. The platform operator sits in the middle, holds the keys, and reads, indexes and re-keys the message at will. The lock is real. The platform has a copy of the key.
The harder version is end-to-end verified exchange. Sender and recipient identities are cryptographically asserted at the moment of exchange, by the participants themselves, not delegated to a platform operator. The content is confidential by construction, not confidential by policy. A doctor can prove that a message arrived intact and was opened by the intended patient. The platform cannot read it, cannot rewrite it, and cannot quietly substitute one recipient for another.
This distinction matters more in healthcare than almost anywhere else. A doctor and a patient communicating through a platform-mediated channel are, by default, trusting the platform with information that legally and ethically must not be shared. Swiss data residency tells you where the bytes physically sit. It tells you nothing about who can read them in motion.
Sovereign infrastructure is necessary. It does not, by itself, answer the question of who can read the message.
HIN understood this. Which is why their infrastructure modernisation was not a single-layer project.
A Locked Vault With a Screen Door
Think of regulated-sector digital infrastructure as a building with two distinct security properties. The first is the vault — where the data lives. The second is the door — how the data moves in and out, and who can pass through.
The Red Hat and VSHN work addresses the vault. Where does the data live? In sovereign Swiss clouds, on an open platform, operated by people who answer to Swiss law and Swiss customers, with no single-vendor dependency and a target availability that means real continuity for real patients. The press release lands at Red Hat Summit because this is a genuine achievement. Building a multitenant, sovereign, dual-cloud OpenShift environment that meets healthcare-grade security and operational requirements is genuinely hard. The people who did it deserve the visibility they are getting.
Layer one is solved. But layer two is where the regulated sectors have been improvising for thirty years.
The encrypted messaging layer addresses the door. How does data move from one organisation to another, under what identity guarantees, with what auditability, with what assurance that the platform operator is structurally unable to compromise the exchange? This question is independent of the infrastructure layer. You can run a perfectly sovereign cloud and still route every doctor-patient message through a trust model controlled by someone else.
Sovereign compute plus cryptographically verified communication produces something the regulated sectors have been chasing for thirty years: an infrastructure that is trustworthy by architecture, not by policy.
The case study notes that HIN is among the first Swiss companies to adopt a zero trust architecture. Zero trust starts from a simple premise: assume that some part of the infrastructure will be breached. Design for that. If you take that premise seriously, the communication layer cannot be an afterthought, because it is precisely the layer that has to keep working when the assumption holds.
Layer one is solved.
HIN is not improvising. And that matters well beyond Switzerland.
A Blueprint for What Comes Next
The European Health Data Space mandates cross-border exchange of health data across 27 member states. Switzerland’s DigiSanté programme is building the national counterpart. Every one of these initiatives, sooner or later, has to answer the same architectural question that HIN has now answered in production: sovereign infrastructure, plus what?
The HIN deployment is the earliest working blueprint for regulated-sector digital infrastructure done properly. Open platform on sovereign clouds, operated under Swiss law, with end-to-end verified communication carrying the most sensitive content. Not as a roadmap slide. As running services, in production, today, for the people who actually deliver healthcare in Switzerland.
Aarno Aukia, again: “Healthcare is a cautious industry, but it’s also one that has a real impact on citizens’ lives.” That impact is exactly why the boring, invisible layer matters. The hard question for any country, any sector, any institution that handles communications it cannot afford to expose is not whether your data is stored in the right country. It is whether the people who are supposed to be communicating are actually the ones doing the talking.
That answer is not in the gears. It is in the escapement.
