Swiss FADP (nDSG) for Clinic Software: What Clinic Owners Must Know

If your clinic stores any patient information in software — even just names, phone numbers and appointment times — you are subject to the revised Swiss Federal Act on Data Protection (FADP), known in German as nDSG, in French as nLPD, and in Italian as nLPD. The new law has been in force since 1 September 2023, and the obligations are stricter, the fines are personal, and "we didn't know" is not a defence.

This guide is for clinic owners — not lawyers. It explains what changed, what you actually have to do, and what you should expect your clinic software to handle for you.

What changed on 1 September 2023

The previous DSG dated from 1992 and was written before electronic patient records existed. The revised FADP modernises the framework and aligns it more closely with the EU GDPR, while keeping a few Swiss-specific rules.

The headline changes that affect clinics:

• Health data is "particularly sensitive personal data" under Art. 5 lit. c FADP, which triggers extra obligations whenever you process it.
• A register of processing activities is now mandatory for most controllers (Art. 12 FADP).
• Privacy by design and by default is a legal requirement, not a best practice (Art. 7 FADP).
• Information duties when collecting personal data have been broadened (Art. 19 FADP).
• Data breaches must be notified to the Federal Data Protection and Information Commissioner (FDPIC / EDÖB / PFPDT) "as soon as possible" (Art. 24 FADP).
• Personal criminal sanctions of up to CHF 250,000 for individuals who intentionally violate certain duties (Art. 60 FADP).

What counts as personal and sensitive data in a clinic

Under Art. 5 FADP:

• Personal data is any information relating to an identified or identifiable natural person — patient name, phone number, email, IBAN, even an appointment slot tied to a name.
• Particularly sensitive personal data includes data on health, religion, political views, biometric data, genetic data, and data on social assistance.

Almost everything a clinic stores about a patient is at least personal data, and the moment a treatment, diagnosis, prescription or referral is recorded, you are processing sensitive data — which means stricter rules on consent, access control and security.

The processing register (Art. 12)

Most clinics now have to keep a register of processing activities. Companies with fewer than 250 employees are exempt only if their processing presents a low risk — and processing health data is, by definition, not low risk.

Your register should list, for each processing activity:

• The purpose (appointments, billing, clinical notes, marketing newsletter, etc.)
• The categories of data subjects (patients, staff, suppliers)
• The categories of personal data
• Recipients (your accountant, your software vendor, your insurer, etc.)
• Retention periods
• A general description of the security measures

A good clinic software vendor will give you a template for this register that already covers the platform-side processing.

Privacy by design and by default (Art. 7)

You must design your processes so that, by default, the minimum amount of personal data is collected and accessed. Concretely:

• Staff see only the patient data they need for their role.
• Old data is deleted or anonymised once retention periods expire.
• New features start with the most privacy-friendly settings and require an active choice to share more.

This is partly your software's job and partly yours. Your software should support role-based access control and configurable retention; you decide who gets which role.

Information duties (Art. 19)

When you collect personal data — at first appointment, on your website form, on a paper intake sheet — you must inform the data subject of:

• The identity and contact details of the controller (your clinic).
• The purpose of processing.
• The recipients (or categories of recipients) the data may be shared with.
• Whether data is transferred abroad, and to which country.

A short, plain-language privacy notice displayed at intake and on your website normally covers this. It does not need to be a 12-page legal document.

Data breach notification (Art. 24)

If a breach is likely to result in a high risk to the personality or fundamental rights of the data subjects, you must notify the FDPIC as soon as possible. The FADP does not impose the GDPR's hard 72-hour deadline, but in practice you should treat 72 hours as your operating ceiling — the FDPIC has confirmed that delays without a good reason will be held against you.

You may also have to inform the affected patients themselves, in clear language, when it is necessary to protect them or when the FDPIC requires it.

The role of the FDPIC (EDÖB / PFPDT)

The Federal Data Protection and Information Commissioner is the supervisory authority. They investigate complaints, audit organisations, and can order corrective measures. Unlike GDPR authorities, the FDPIC cannot directly impose administrative fines — but the cantonal criminal authorities can fine individuals up to CHF 250,000 under Art. 60.

Why hosting in Switzerland matters

Where your patient data physically sits decides which government can lawfully demand access to it.

• Swiss hosting keeps the data under Swiss jurisdiction, with strong constitutional privacy protections and a federal law (BÜPF / LSCPT) that requires judicial oversight for state access.
• EU hosting brings the data under GDPR — strong, but US authorities can still reach EU subsidiaries of US cloud providers via the CLOUD Act.
• US hosting exposes the data to US legal process, including the CLOUD Act and FISA 702.

For a clinic, the practical answer is simple: prefer Swiss hosting; accept EU hosting only if Swiss is not available; avoid US-only hosting for clinical data.

FADP vs GDPR: the short version

If you already comply with GDPR, you are roughly 90% of the way to FADP. Differences worth knowing:

• FADP applies only to data of natural persons; GDPR also covers legal entities in some readings.
• FADP fines are personal and criminal; GDPR fines are organisational and administrative.
• FADP has no formal 72-hour breach deadline, but "as soon as possible" is the standard.
• FADP requires a representative in Switzerland for foreign controllers in some cases (Art. 14).

Clinic-owner checklist

Use this as a Monday-morning to-do list. Each item is a real legal obligation or a strong best practice.

• Map your data. List every system that holds patient data — your clinic software, your accountant's tool, your email, paper folders.
• Write your processing register (Art. 12). One page per system is fine.
• Publish a privacy notice in the languages your patients use, on your website and visibly at reception.
• Sign a data processing agreement with every vendor that touches patient data — including your software, hosting, accountant, and any external transcription service.
• Verify hosting location. Ask your software vendor in writing where data is stored. Get it in the contract.
• Configure role-based access in your software so receptionists do not see clinical notes and vice versa.
• Enable encryption at rest and in transit (AES-256 or equivalent). Most modern clinic software does this automatically — confirm it.
• Define retention periods in writing (typically 10 years post-treatment for adults, 20 years for minors — see the next post).
• Train your team at least once a year on data handling, phishing and breach reporting.
• Have a breach response plan with a named person, a 72-hour mental deadline, and the FDPIC contact form bookmarked.

What this means for your software choice

Your clinic management software is not a neutral tool — it is a data processor under FADP, and the obligations it fulfils (or fails to fulfil) become your obligations. Before signing, check that the platform offers Swiss hosting, AES-256 encryption, role-based access, audit logs, exportable data for patient access requests, and a written data processing agreement.

Compliance is no longer optional. But with the right software and a one-page register, it is also not as heavy as it sounds.