Blog ·
Zero-knowledge sync, explained for clinicians
Every practice-management vendor with a sync feature asks you to accept the same bargain: to see your records on two devices, a copy of those records lives in the vendor's database, readable by the vendor. The bargain is so universal that most clinicians have stopped noticing it is a bargain at all. SideClick's Practice editions refuse it — and the refusal is mechanical, not contractual. This post explains the machinery in clinician's terms.
The relay only ever sees ciphertext
When your laptop syncs with your clinic desktop, changes travel through a relay server — but they are encrypted before they leave your device, with keys that exist only on devices you have enrolled. The relay stores and forwards sealed envelopes. It cannot open them. Neither can we, and neither can anyone who compromises, buys or subpoenas the relay: there is no key on the server side to steal, and no plaintext to disclose.
Contrast that with the standard architecture, where 'encrypted in transit and at rest' — a phrase that appears on every vendor's security page — describes a database the vendor decrypts routinely to operate its product. Encryption where the operator holds the key protects against outsiders. It does nothing about the operator, its staff, its acquirer or its legal exposure. Zero-knowledge is the difference between locking the cabinet and giving someone else the only key versus keeping it.
Simultaneous edits don't fight
Sync uses CRDTs — data structures designed to merge concurrent changes deterministically. Two clinicians updating the same record on different machines converge to the same result on both, without a server adjudicating (the server, remember, cannot even read the changes). The rare genuine conflict — two people editing the same field in opposite directions — is surfaced to a human instead of silently overwritten. In practice, a front desk rescheduling while a clinician documents is a normal Tuesday, not a support ticket.
Devices are trusted explicitly
- Each device is enrolled deliberately — a seat includes three
- A lost or stolen device is revoked in about a minute, cutting its sync access immediately
- Its local database stays encrypted regardless — losing hardware isn't disclosing records
- Enrolment and revocation are practice-side actions; no support ticket, no waiting
Explicit device trust is the unglamorous half of the design, and arguably the half that matters more day to day. Breaches of small practices rarely look like movie hacking; they look like a laptop left on a train. In this architecture that event is an inconvenience with a checklist.
What zero-knowledge costs
Honesty requires the other column. Because we cannot read your data, we also cannot reset a lost practice key from a helpdesk, mine your records to build features, or run server-side search over your notes. Recovery is built on practice-held backups and multi-device redundancy instead of vendor omniscience. We think that trade is obviously right for clinical records; you should make it knowingly.
The question to ask any vendor
If you take one thing from this post, take the question: 'Can your servers read my patient records?' There are only two honest answers, and one of them should end the conversation. Ours is: the servers store ciphertext, and the keys never leave your practice.