Swiss chat for the medical practice: what applies before you choose one
Messages are the fastest way to settle a question, and the shortest route to a breach of professional secrecy. What the law requires of a messenger in a practice, and how to tell whether a service meets it.
In almost every practice, part of the communication runs through a messenger that was never chosen for the job. The assistant sends a colleague a photo of a wound because it is quicker than describing it on the phone. A referring doctor asks briefly about a finding. On Sunday evening a patient sends a picture and asks whether she should come in on Monday. None of this is carelessness — it is the fastest available answer to a real question.
The problem starts afterwards. These messages contain health data, and different rules apply to it than to arranging who brings the cake. Anyone running a practice does not need to know those rules by heart, but does need to know which questions to put to the provider.
What the law actually requires
The revised Data Protection Act has been in force since 1 September 2023. It lists health data explicitly as sensitive personal data (Art. 5 lit. c FADP). Everything else follows from that: such data requires explicit consent wherever processing is not already covered by the treatment contract, and the security requirements are higher than for the rest.
On top of that comes professional secrecy under Art. 321 of the Swiss Criminal Code. It binds not only the doctor but expressly also their auxiliaries — that is, the entire team. Sending a photo of a patient through a service that is permitted to analyse it discloses a secret, regardless of whether anyone actually reads it.
Why the server location alone decides nothing
"Servers in Switzerland" is the most advertised argument and the weakest one. What counts is not where the disk sits but which law governs the company operating it. Under the US CLOUD Act, a US corporation must hand over data it controls — including data held in Zurich. The location changes nothing about that; corporate ownership does.
The reverse also holds: a service with servers in the EU is not automatically a problem. Art. 16 FADP permits disclosure abroad where adequate protection exists, and the Federal Council maintains a list of those states. So the question is not "Switzerland or not" but: who can legally access this data, and on what grounds.
End-to-end encryption protects the content of a message. It does not stop a provider from knowing who wrote to which practice, and when.
The second common misconception concerns encryption. It is necessary and it is not sufficient. Metadata — who, when, how often, with whom — accrues even with perfect encryption, and in a medical context it is revealing: the fact that a number regularly messages an oncology practice is already information about a state of health.
Six questions to settle before choosing
- 1
Who owns the company, and which law governs it?
Not where the servers stand, but who controls them. For a subsidiary, the parent group counts. That information is in the commercial register, not in the marketing copy.
- 2
Is there a data processing agreement?
Art. 9 FADP requires processing by third parties to be governed by contract. A provider who cannot produce one is unusable for patient data, however good the product is.
- 3
What metadata accrues, and how long does it stay?
Ask about the retention period for connection data. A solid answer is a number of days. "We only store what is necessary" is not one.
- 4
Does communication run through private phone numbers?
A service that needs the address book of a private phone mixes practice and private life. When a team member leaves, the messages go with them.
- 5
Can patients take part without installing anything?
A channel only half of them use pushes the other half back to WhatsApp. This question decides more about success than any feature list.
- 6
Does the message reach the patient record?
What stays in the messenger is not documented. Either the service writes back into the primary system, or somebody retypes it — and then the time saved is gone again.
What this means day to day
Experience from such changeovers is unspectacular: the legal part is settled in an afternoon, the hard part is habit. A team does not change channel because a memo says so, but because the new route is faster in the case at hand. If it is not, WhatsApp keeps running — in parallel, invisibly, and precisely where nobody is looking.
So the most useful question before choosing is not which service can do the most, but which one covers the three or four situations in which people reach for their phone today. Usually those are: a quick question within the team, an image to the referring doctor, and moving an appointment with a patient.
What is actually in use in Swiss practices
Three services come up again and again in Swiss practices and hospitals, and all three deserve to be taken seriously. They simply answer different questions.
| Service | Company domicile | Built for | Patient contact |
|---|---|---|---|
| Threema Work | Switzerland | Secure team messaging, any industry | Only if the other side installs the app |
| Signal | USA, non-profit foundation | Private communication with strong encryption | Only with the app and a phone number |
| Beekeeper | Switzerland | Internal communication for large teams without a fixed desk | Not built for it |
| USA, Meta | Private communication | Widespread, but not legally tenable |
For communication within the team, Threema Work and Beekeeper are tenable answers, and Signal is technically beyond doubt — even though the foundation behind it sits in the USA and there is no data processing agreement, which rules it out for patient data. The real gap lies elsewhere: all three stop at the practice door. As soon as a patient is to be included without installing an app, or a message has to end up in the patient record, none of them answers the question. They were not built for it.
Where Unomed stands in this
The Unomed Messenger is built for exactly this purpose: a Swiss company, data in Switzerland, a data processing agreement as standard, patients taking part through the guest portal without installing anything, and messages that can be written back into the existing practice system instead of retyped.
That does not make it the right choice for every practice. Anyone already running a service that answers the six questions above cleanly has no reason to switch. Anyone who cannot answer them has one.
