Health data is among the most sensitive data there is. It is also among the most attacked. The numbers are not small, and they are not getting smaller.
The breach reality
In 2024 the Change Healthcare ransomware attack exposed the protected health information of around 190 million people. The figure was later revised to about 192.7 million. It is the largest healthcare data breach on record, anywhere.
That was not an outlier. In 2023, healthcare breaches reported to U.S. regulators exposed more than 113 million records. In 2024, the total topped 275 million records breached. Three years running, U.S. regulators logged more than 700 large breaches each year.
Most of these were hacking and IT incidents, not lost laptops. Attackers go where the data is readable in bulk. An EMR database is exactly that.
Why typical EMR encryption is not enough
Major EMR vendors do encrypt. They protect data in transit with TLS and at rest with strong algorithms such as AES-256. This is real protection and it is required. But the system manages the keys. The application decrypts records to display them, search them and report on them.
That design has a gap. The data is readable to the system at run time. So it is readable to an attacker who reaches the running system, and to an insider with database access. Encryption at rest stops a stolen disk. It does not stop a live database dump or a credential abused from inside.
Encryption at rest is not the same as zero-knowledge. The difference is who can read the plaintext. Our guide on zero-knowledge encryption covers the mechanics.
What zero-knowledge changes at the point of care
In a zero-knowledge EMR, the record is sealed on the clinician's device. It is encrypted before it reaches the server. The server stores ciphertext. The vendor cannot read it. Neither can an attacker who steals the database.
Sharing follows medical consent. A record is opened to another clinician by granting them a key to that record, the way a patient consents to a referral. There is no master view that reads everything. Access is explicit, recorded, and revocable.
The result: a breach of the server yields scrambled data, not patient histories. The clinical workflow is unchanged at the bedside. The exposure window is what shrinks.
What to ask EMR vendors
Key custody. Can you, the vendor, decrypt a patient record without the clinician's keys? If yes, the records are readable to you and to anyone who compromises you.
Breach yield. If the production database is stolen tonight, do attackers get readable records or ciphertext? Ask for this in writing.
The AI data path. This is the new one. Many EMRs now add clinical AI. Ask exactly where patient data goes. Does it send records to a public cloud model run by a third party? Or does the model run inside your boundary on your own hardware? A zero-knowledge claim means nothing if the AI feature ships the plaintext out.
Hosting. Can the system run on your own infrastructure, in your own jurisdiction? For many providers this is a regulatory requirement, not a preference.
- Healthcare breaches now reach hundreds of millions of records a year; Change Healthcare alone hit ~190M in 2024.
- Typical EMR encryption (TLS plus AES-256 at rest) does not stop insiders or a live database dump — the system can still read the data.
- Zero-knowledge seals records on the clinician's device; a server breach yields ciphertext, and sharing follows medical consent.
- Ask vendors about key custody, breach yield, the clinical-AI data path, and self-hosting.
The honest trade-offs
Zero-knowledge is not free. If a vendor pretends otherwise, be careful. The costs are real and you should name them before you commit.
Search and reporting are harder. If the server cannot read the data, server-side full-text search and population analytics need a different design — searchable encryption, client-side indexing, or scoped decryption. This works, but it is more engineering than a plain database query.
Recovery needs discipline. When the vendor cannot reset access, key recovery must be designed carefully — escrow, break-glass procedures, multi-party recovery. Get this wrong and you can lock a clinic out of its own records. It must be planned, tested and documented.
Lock-in deserves a question. Strong encryption can make data harder to move. Ask any vendor, zero-knowledge or not, how you export full records and keys if you leave. A good answer exists; insist on hearing it.
Where this leaves you
The breach numbers argue for sealing records so a stolen database is worthless. The trade-offs argue for going in with eyes open. Both are true at once.
Zeromatics builds toward this with ZeroEMR, a zero-knowledge record sealed at the point of care, on infrastructure you can host yourself. It is one option, not the only one, and the right questions above apply to it as much as to anyone. You can read more on the ZeroEMR product page, the healthcare solutions page and our security architecture.