Article 9 — Special Category Data
Clinical discussions, case examples, medical histories, referrals, and verification data almost always involve special category data (data concerning health). This page documents how ChartScribe lawfully processes such data under GDPR Article 9.
Wiki Privacy Notice
Full privacy notice with Article 9 basis
DPO & DPIA
Data Protection Officer & impact assessment
Your Rights
Exercise access, erasure, objection
Article 9 in Plain Terms
Paragraph 1 — General Ban: Processing is prohibited for data revealing health, genetic data, biometric data, racial or ethnic origin, political opinions, religious beliefs, or sex life.
Paragraph 2 — 10 Exemptions: The ban can be lifted if at least one of 10 exemptions applies AND a general Article 6 lawful basis is also satisfied.
Paragraph 3 — Extra Safeguards (for 9(2)(h)): Health data processed under the health care exemption must be processed by or under the responsibility of a professional bound by professional secrecy (or equivalent obligations).
Our Three-Tier Strategy
We use a layered approach combining explicit consent (strongest), health care purposes (most appropriate for clinical content), and public interest (for aggregate/anonymised use). This mirrors how platforms like Doximity and Sermo operate successfully in the EU/UK.
Explicit Consent
"The data subject has given explicit consent to the processing of those personal data for one or more specified purposes…"
How it applies to us
Paired with
Article 6(1)(a) — Consent
Used for
Account creation & verification; Public posting of clinical discussions; Reputation & badge display; Optional AI training inclusion
Health or Social Care Purposes
"Processing is necessary for… the provision of health or social care or treatment or the management of health or social care systems and services… subject to the conditions and safeguards referred to in paragraph 3."
How it applies to us
Paired with
Article 6(1)(f) — Legitimate Interest / Art. 6(1)(b) — Contract
Used for
Displaying discussions that aid clinical decision-making; Moderator review of clinical content; Community safety & professional standards enforcement
Public Interest in Public Health
"Processing is necessary for reasons of public interest in the area of public health… ensuring high standards of quality and safety of health care…"
How it applies to us
Paired with
Article 6(1)(f) — Legitimate Interest (anonymised data)
Used for
Aggregate analytics on clinical discussion trends; Anonymised AI model training (with additional opt-in); Quality improvement reporting
Processing Activity → Exemption Mapping
This table maps every processing activity in the Clinical Wiki to its Article 9 exemption, Article 6 lawful basis, the categories of data involved, and the specific safeguards applied. This is the core compliance document for our Records of Processing Activities (RoPA).
| Processing Activity | Art. 9 Exemption | Art. 6 Basis | Safeguards |
|---|---|---|---|
Account creation & identity verification Name, email, specialty, license document | 9(2)(a) Explicit Consent | 6(1)(b) Contract + 6(1)(a) Consent | AES-256 encryption, 30-day document deletion, hash-only retention, role-based access |
Publication of clinical discussions Posts, answers, comments (health data) | 9(2)(a) Explicit Consent + 9(2)(h) Health Care | 6(1)(f) Legitimate Interest + 6(1)(a) Consent | Pre-publish PHI checklist, keyword auto-flagging, community reporting, easy deletion |
Voting, reputation & badges Vote records, reputation score, badge status | 9(2)(a) Explicit Consent | 6(1)(f) Legitimate Interest | Opt-out available in profile, no automated decision-making, anonymised on account deletion |
Moderator content review Flagged posts, reported content | 9(2)(h) Health Care + 9(2)(a) Consent | 6(1)(f) Legitimate Interest | Professional secrecy agreement signed, view-only access, all actions audited, 48-hour review SLA |
Anonymised AI training Fully anonymised & aggregated post extracts | 9(2)(i) Public Health + 9(2)(a) Consent (opt-in) | 6(1)(f) Legitimate Interest | Pseudonymisation pipeline, aggregation, separate opt-in consent, no individual identification possible |
.care badge display to patients Moderator badge status only | 9(2)(a) Explicit Consent (granular) | 6(1)(a) Consent | Granular opt-in at verification, can be turned off anytime, clear patient-facing explanation |
Audit logging Views, posts, edits, votes (timestamp + action) | 9(2)(h) Health Care (administration) | 6(1)(c) Legal Obligation | 6-year retention (statute), access restricted to DPO & admin, encrypted storage |
Professional Secrecy Safeguards (Art. 9(3))
Article 9(2)(h) requires that health data be processed by or under the responsibility of a professional bound by professional secrecy. We satisfy this through multiple layers:
Moderator Confidentiality Agreement
ImplementedAll moderators sign a binding confidentiality agreement before receiving access. Covers: no downloading of verification docs, no screenshotting, no sharing outside platform, immediate breach reporting.
Terms of Service — Professional Secrecy Clause
ImplementedAll wiki users are bound by a professional secrecy clause in the ToS. By participating, clinicians agree to maintain confidentiality standards equivalent to their professional regulatory body (IMC, GMC, etc.).
Role-Based Access Controls
ImplementedModerators can only access data necessary for their specific task. Verification docs are view-only. No bulk export. No admin override without DPO approval logged.
Audit Trail for All Access
ImplementedEvery view of sensitive data is logged (who, when, what, why). Logs retained for 6 years. Moderators can see their own audit trail.
Annual Secrecy Training
ImplementedAll moderators complete annual training on professional secrecy obligations under GDPR Article 9(3) and their national medical council rules.
Edge Cases & How We Handle Them
Doctor posts identifiable patient data
Handling: Immediate automated flagging + moderator removal within 2 hours. Post redacted or deleted. User warned (Level 2) or restricted (Level 3) depending on severity.
Article 9 note: Even with consent, identifiable patient data breaches professional secrecy and is removed immediately.
AI training on posts
Handling: Only fully anonymised versions used. Separate opt-in consent required. Pseudonymisation + aggregation before any AI pipeline entry. Individual posts never directly used.
Article 9 note: 9(2)(i) public health applies only after strong anonymisation. Additional consent layer for safety.
Patients seeing badges in .care
Handling: Requires separate granular consent at verification + can be turned off anytime. Patient-facing explanation clearly states what the badge means.
Article 9 note: 9(2)(a) explicit consent only — this is a distinct processing purpose requiring its own consent.
Irish Medical Council / GMC social media rules
Handling: ToS requires users to follow their regulatory body rules on social media and online professional conduct. Moderators enforce this.
Article 9 note: Professional regulatory rules supplement GDPR — both must be satisfied.
Exemptions We Do Not Rely On (Documented)
For transparency and audit readiness, we document why the other Article 9(2) exemptions are not applicable to our processing. This demonstrates a considered legal position.
Legal Opinion Note
ChartScribe processes special category personal data (health data) through the Clinical Wiki platform. After reviewing the nature, scope, and purpose of processing, we have determined that the following legal basis applies:
Primary basis: GDPR Article 9(2)(a) — explicit consent, combined with Article 6(1)(a) consent. All users provide explicit, granular consent before their health data is processed for specific purposes.
Secondary basis: GDPR Article 9(2)(h) — health or social care purposes, combined with Article 6(1)(f) legitimate interest. The Clinical Wiki directly supports the provision of health care by enabling peer-to-peer knowledge sharing among verified clinicians. Paragraph 3 safeguards are satisfied: moderators are verified clinicians bound by professional secrecy, and all team members operate under strict confidentiality agreements.
Tertiary basis: GDPR Article 9(2)(i) — public interest in public health, combined with Article 6(1)(f) legitimate interest. Applied only to fully anonymised and aggregated data used for AI training and quality improvement, with additional opt-in consent as a supplementary safeguard.
This layered approach is consistent with industry practice for professional medical networking platforms operating in the EU/UK, and provides robust legal grounds for all processing activities. Residual risk is assessed as Low.
Risk Assessment: Low
With the layered Article 9 approach, strong explicit consent, professional secrecy safeguards, granular controls, and easy erasure tools, the residual risk of this processing is assessed as Low.