GDPR for Medical Practices and Therapists: 8 Obligations

Main article: Special category data under Art. 9 GDPR (glossary) — an overview of the general prohibition on processing and its narrow exceptions.

Who is covered by what: The purely GDPR-based obligations — sections 1, 2 and 7 (there without the competence details under § 40(1) and § 9(1) BDSG), the one-month period in section 5 and the table of GDPR deadlines, plus the references to Art. 28 and Art. 30 in sections 3, 6 and 8 — attach to the processing of health data, not to a job title; they apply to medical practices and therapists alike. Alongside them stand German sector-specific rules: § 203 StGB (section 4), § 630g and § 630f BGB (sections 5 and 6), Book V of the German Social Code (SGB V) for the telematics infrastructure (section 3) and the connection to the Association of Statutory Health Insurance Physicians (section 8). Practitioner recommendation for therapists and other health professions: check in three steps which of these rules cover your profession — first, whether the professional secrecy obligation under § 203 StGB applies to your profession (a legal question — have it clarified by a lawyer); second, whether your professional act contains its own confidentiality and documentation obligations; third, whether your practice is connected to the telematics infrastructure and to the Association of Statutory Health Insurance Physicians (sections 3 and 8). Record the outcome in writing — the GDPR obligations in this article apply regardless. For Austria, the Austria section names the Physicians Act and the respective professional acts.

1. Patient data = Art. 9

Patient data are special categories of personal data: their processing is generally prohibited under Art. 9(1) GDPR and is permitted only where an exception under Art. 9(2) GDPR applies. Legal basis: Art. 9(2)(h) (health care).

The assessment has two stages. In addition to the exception under Art. 9(2) GDPR, every processing operation also needs a legal basis under Art. 6(1) GDPR; that provision names six grounds for lawful processing (consent, contract, legal obligation, vital interests, public interest, legitimate interests). Where you obtain consent, you must be able to demonstrate that it was given (Art. 7(1) GDPR); it can be withdrawn at any time and withdrawal must be as easy as giving consent (Art. 7(3) GDPR).

Each of these processing operations belongs in the record of processing activities. The exemption in Art. 30(5) GDPR does not relieve practices: it requires cumulatively fewer than 250 employees, no risk to the rights and freedoms of data subjects, no regular processing and no processing of special categories — the regular processing of health data rules it out.

2. Hospital and practice software: processing on behalf of the practice

For practice software and hospital information systems (HIS), a processing agreement under Art. 28 GDPR is required as soon as the provider processes patient data on behalf of the practice — for example in operation, hosting or maintenance. This applies regardless of the provider — to CompuGroup, x.dental and Medatixx just as to any other solution in use: ask for the processing agreement before concluding the contract and compare it against the minimum content of Art. 28(3) GDPR. Practitioner recommendation: prefer hosting in the EU; if the hosting location is outside the EU, the Third Country transfer together with its transfer basis — for example the Data Privacy Framework (adequacy decision), standard contractual clauses or binding corporate rules — belongs in the record of processing activities as a separate entry (Art. 30(1) GDPR). In our practical experience, a missing Third Country reference for US services is one of the common documentation errors.

Art. 28(1) GDPR permits cooperation only with processors that provide sufficient guarantees of appropriate technical and organisational measures. Under Art. 28(3) GDPR, the contract must set out at least the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects and the obligations and rights of the Controller. Check the provider contract point by point against this minimum content — each of these items must appear in the contract text — and request missing items in writing; under Art. 28(1) GDPR the Controller remains responsible for the selection, even where the contract text comes from the provider.

In our practical experience (not a statutory requirement), supervisory authorities often check in this order: record of processing activities, processing agreement, technical and organisational measures concept, DPIA — gaps therefore show up at the very first step. Practitioner recommendation: link every service provider with access to patient data in the record of processing activities to the corresponding processing agreement — no entry without an agreement, no agreement without an entry.

3. E-prescription and telematics infrastructure

For the connection to the telematics infrastructure, the requirements of SGB V and the gematik specifications apply in Germany. A connector, an electronic practitioner card (eHBA) and an institution card (SMC-B) are used; the security requirements follow SGB V (§ 311(6), § 325, § 327 SGB V) and the gematik specifications, and BSI-certified components are used. Under data protection law, the e-prescription is also a processing of patient data: it belongs in the record of processing activities as a separate entry with its purpose, data categories, categories of recipients and erasure period (Art. 30(1) GDPR). Practitioner recommendation: set out in writing which person keeps which card and which PIN, and include this allocation in the technical and organisational measures concept under Art. 32 GDPR (section 4). For the connector: set out responsibility for location, access and updates in writing and include it in the technical and organisational measures concept under Art. 32 GDPR.

Under data protection law, the role of the service provider is decisive: if an IT or telematics service provider processes patient data on behalf of the practice, section 2 applies with the minimum content of a processing agreement under Art. 28(3) GDPR; the distinction from bodies that process under their own responsibility is set out in section 8.

A parallel NIS2 obligation under the German BSI Act (BSIG), by contrast, does not arise for typical practices: classification under § 28 BSIG requires a type of entity under Annex 1 or Annex 2; the health sector is indeed listed in Annex 1 of the BSIG, but typical practices do not reach the size thresholds attached to it — the figures are given in the FAQ. For practices this means: the registration obligation of the BSIG applies to particularly important entities and important entities as well as to domain name registry service providers (§ 33(1) BSIG), and the notification obligations apply to particularly important entities and important entities (§ 32(1) BSIG) — a practice that does not meet the requirements of § 28 BSIG is not addressed by them.

4. Professional secrecy under § 203 StGB

Medical professional secrecy under § 203 StGB applies in Germany alongside the GDPR and is not replaced by it: a breach can be penalised under criminal law and by the supervisory authority at the same time — a criminal complaint is possible in the event of a breach, and the GDPR fine remains in addition. In Austria there is additionally the data secrecy obligation under § 6 DSG — see the Austria section.

The GDPR fine framework has two tiers; the precise allocation, the supplementary administrative offence under § 43 BDSG and the Austrian administrative penalty under § 62(1) DSG are set out in the FAQ.

Practitioner recommendation: place all staff under a written confidentiality obligation before granting access and put the declaration in the personnel file; grant access rights on a role basis and describe them in the technical and organisational measures concept under Art. 32 GDPR, to which the record of processing activities refers — a separate set of measures for each processing operation is not necessary.

5. Patient right of access

The practice must respond to an access request without undue delay and at the latest within one month of receipt (Art. 12(3) GDPR). Patients additionally have a right to the patient file under § 630g BGB, which exists alongside the right of access under Art. 15 GDPR. A request may therefore be based either on Art. 15 GDPR or on § 630g BGB.

The one-month period applies to all requests under Art. 15 to 22 GDPR, that is also to rectification, erasure and restriction. It can be extended by a further two months — the details are given in the deadline table.

Practitioner recommendation: for every request, record the date of receipt and the legal basis invoked in writing, and treat the request additionally as a request under Art. 15 GDPR — then the one-month period of Art. 12(3) GDPR runs in any event. The period starts on receipt, not on internal processing.

6. Retention

The patient file must be retained for 10 years after the end of treatment, unless other provisions lay down other retention periods (§ 630f(3) BGB). Practitioner recommendation: check for each type of treatment whether a special statutory period applies, and enter a deviating period as a separate data category in the record of processing activities.

Under data protection law it also matters that these periods are documented: the envisaged erasure periods are — where possible — a mandatory entry in the record of processing activities under Art. 30(1) GDPR, and indeed per data category. Where a statutory retention obligation conflicts with a request for erasure under Art. 17 GDPR, that conflict likewise belongs in the record. Missing erasure periods — the entry 'no specific information' — are, in our practical experience, among the common documentation errors.

Practitioner recommendation: review the record annually and additionally on every change; where structures grow continuously, a quarterly review has proven effective. That is a practice rhythm, not a statutory period.

7. Specifics of personal data breaches

Notification to the supervisory authority under Art. 33(1) GDPR: without undue delay and, where feasible, within 72 hours. Where the notification is not made within 72 hours, it must be accompanied by reasons for the delay. With health data, a high risk must regularly be assumed — Art. 34(1) GDPR then additionally requires that the data subject be informed without undue delay. This is dispensed with under Art. 34(3) GDPR only by way of exception: where appropriate technical and organisational protection measures (in particular encryption) were applied beforehand, where the high risk no longer exists as a result of subsequent measures, or where the communication would involve disproportionate effort (in which case a public communication is made). Compensation claims are also possible.

The notification itself has a fixed minimum content (Art. 33(3) GDPR): a description of the breach, the approximate number of data subjects and records concerned, the data categories, the likely consequences, the measures taken to address and mitigate the breach, and the contact details of the data protection officer or the Controller. Irrespective of this, every breach must be documented, including those not notified — where no notification is made, with reasons (Art. 33(5) GDPR). Sending an email containing health data to the wrong recipient is as a rule to be classified as a high-risk case: then notification under Art. 33 GDPR and communication under Art. 34 GDPR.

In Germany, non-public bodies notify the authority competent under the law of the federal state (§ 40(1) BDSG); each federal state operates its own notification portal, in Bavaria, for example, the Bavarian State Office for Data Protection Supervision (BayLDA). The Federal Commissioner for Data Protection (BfDI) is competent only for public bodies of the Federation and certain providers of telecommunications services (§ 9(1) BDSG). The Austrian counterpart is named in the section on Austrian practices.

The following sequence is a practitioner recommendation — only the deadline in Art. 33(1) GDPR is legally binding:

8. Connection to the Association of Statutory Health Insurance Physicians

The data flow to the Association of Statutory Health Insurance Physicians runs over secure channels — KV-SafeNet and the telematics infrastructure. Under data protection law, everything else depends on one preliminary question: in which role does the body receiving the data act?

Assign every external body to one of three roles — Controller (Art. 4 no. 7 GDPR), Data Processor (Art. 4 no. 8 GDPR) or joint controllers (Art. 26 GDPR). What matters is whether the body processes the data on behalf of the practice (Art. 28(1) GDPR) — only then is a processing agreement with the minimum content of Art. 28(3) GDPR required. A body that processes as an independent Controller is not bound by a processing agreement but is recorded as a category of recipient in the record of processing activities: the categories of recipients are a mandatory entry under Art. 30(1) GDPR. Clarify and document this allocation for the Association of Statutory Health Insurance Physicians expressly before the first data flows. Confusing processing on behalf of a Controller with joint controllership is, in our practical experience, one of the common errors in maintaining the record, as are outdated recipient lists with deactivated accesses or changed service providers.

Practitioner recommendation: update recipient, role and transmission channel in the record in the same step whenever a system changes, instead of collecting them for the annual review. For KV-SafeNet, check the operator, the role and the contractual situation as part of this.

Deadlines, prior and documentation obligations at a glance

Six obligations of the practice follow directly from the GDPR — some tied to deadlines, some to be met in advance before processing begins, some as ongoing documentation or accountability obligations. These six rows are not a second count alongside the eight sections above but the cross-cutting GDPR deadlines that appear in several sections. All rows of the table set out GDPR obligations; they apply in Germany and Austria alike. Practice rhythms are set out in the sections above and are marked there as practitioner recommendations.

For the electronic patient file, the data protection impact assessment applies: Art. 35(1) GDPR requires it in advance where processing — in particular using new technologies — is likely to result in a high risk to the rights and freedoms of natural persons; Art. 35(3) GDPR expressly names the large-scale processing of special categories of data. This has a knock-on effect: where processing is subject to a DPIA, a data protection officer must be designated in Germany irrespective of the number of persons involved (§ 38(1) sentence 2 BDSG); the 20-person threshold of § 38(1) sentence 1 BDSG applies alongside it. In Austria there is no numerical threshold (Austria section). Where a data protection officer has been designated, data subjects may contact them under Art. 38(4) GDPR on all matters relating to the processing of their data.

Austria: what is different for practices there

The GDPR applies unchanged in Austria — Art. 9, Art. 15, Art. 33, Art. 34 and Art. 35 GDPR are identical. What differs is the national framework: the supervisory authority is the Austrian Data Protection Authority (Datenschutzbehörde, DSB) under § 18(1) DSG, not a German state data protection authority. The supplementary national law is the DSG instead of the BDSG — Austria has no additional numerical designation threshold for the data protection officer such as § 38(1) BDSG (as a rule at least 20 persons); the designation obligation follows directly from Art. 37 GDPR. Unless Art. 83 GDPR already applies, administrative penalties of up to EUR 50,000 are possible under § 62(1) DSG. The rules named above — § 203 StGB, § 630f and § 630g BGB, KV-SafeNet and the telematics infrastructure — are German law; in Austria, medical confidentiality and documentation obligations follow the Physicians Act and the respective professional acts. The NIS2 transposition is also a different one: in Austria it takes place not through the BSIG but through the Austrian Network and Information Systems Security Act 2026 (NISG 2026); there, too, classification as an essential entity or an important entity requires a type of entity under Annex 1 or Annex 2 (§ 24 NISG 2026) and attaches to the size thresholds of § 25 NISG 2026, which typical practices do not reach — the figures are given in the FAQ.

Supplementary DSG provisions relevant to practice

Four DSG provisions bear directly on everyday practice life: § 6, § 11, § 12 and § 13 DSG. § 6 DSG obliges controllers, processors and their staff to maintain secrecy (data secrecy). § 11 DSG provides for the proportionate application of Art. 83 GDPR, in particular a warning instead of a fine for first-time infringements. Where video surveillance is used, the special rules of §§ 12 and 13 DSG apply: a marking obligation under § 13(5) DSG, and retention lasting longer than 72 hours must be proportionate and must be separately logged and justified (§ 13(3) DSG); image recording for the purpose of monitoring employees is inadmissible (§ 12(4) no. 2 DSG). There is a fifth question the DSG does not answer: it contains no dedicated provision on employee data protection such as § 26 BDSG — what governs here are Art. 6 and Art. 88 GDPR, supplemented by § 96(1) no. 3 of the Austrian Labour Constitution Act (ArbVG) for monitoring measures that affect human dignity. Personal data breaches go to the Austrian Data Protection Authority (dsb.gv.at, Barichgasse 40-42, 1030 Vienna), not to a German authority.