How Patient Data Is Protected
The complete picture: who is responsible for patient data, how patients give consent, how privacy notices work, and what platform staff can and cannot see.
This is the document to read first if you want to understand how RestartiX handles patient data — at a level that does not require any legal or technical background. It covers the single most consequential design decision in the platform (who is the controller of patient data) and follows it through to the practical consequences for sign-up, booking, marketing toggles, GDPR rights, and the rare cases where platform staff need to look at a clinic's data.
If you are a regulator, an investor, a clinic admin evaluating the platform, or a member of the management team preparing for a due-diligence conversation — this is the page.
For the formal architectural rationale, see Why clinic is controller, platform is processor.
The Core Decision: Who Is Responsible for Patient Data
Under EU data protection law, every party that handles personal data is either a controller (decides why and how the data is used) or a processor (acts on the controller's instructions). Getting this split wrong is one of the most expensive mistakes a healthtech platform can make — for both the platform and the clinics it serves.
RestartiX takes the same position Stripe takes with merchants:
- Each clinic is the controller of its patients' data — the clinic owns the patient relationship, decides what services to offer, what forms to collect, and how patient data is used.
- RestartiX is the processor — it provides the platform under a Data Processing Agreement (DPA), and processes patient data only as the clinic instructs.
- No joint controllership for patient data. Cross-clinic features that would otherwise create joint controllership operate on anonymised data only.
There is one narrow exception: RestartiX is the controller for the thin slice of account-level data it needs to keep the platform working — login credentials, security telemetry on the account itself, fraud prevention. (Stripe makes the same distinction in their privacy policy: merchants are controllers for transaction data; Stripe is controller only for the merchant's own account.)
This is not a presentation choice. It is enforced by the way the platform is built — every feature, every Console page, every cross-clinic capability respects this boundary. Patient data does not flow between clinics. Platform staff cannot browse identifiable patient data across clinics by default. Privacy notices are clinic-owned. DSARs (data subject access requests) route to the clinic.
The rest of this page is the practical consequence of that one decision.
What the Patient Sees: A Two-Tier Consent Surface
Patients encounter consent in two distinct places, and the two are deliberately separated. This is the surface the patient experiences; under the hood, every grant or withdrawal is recorded in a single append-only ledger so the full history is available later.
Tier A — SaaS-style consents (toggleable preferences and acknowledgements)
These are the consents a patient meets the moment they sign up, plus the marketing-style preferences they can toggle from their settings later. They behave like consents on a normal SaaS product.
| Consent | What it is | Withdrawable? | Where it appears |
|---|---|---|---|
| Platform terms of service | The contract with RestartiX itself for using the patient portal | No (revoking = deleting the account) | Sign-up |
| Platform privacy notice | Acknowledgement of the platform's processing for account-level data | No (informational acceptance) | Sign-up |
| Clinic terms of service (if the clinic publishes one) | The contract between the patient and the clinic | No (revoking = leaving the clinic) | Onboarding at the clinic |
| Clinic privacy notice | The clinic's own data-protection disclosure (the patient's main GDPR notice) | No (informational, but the underlying processing has its own legal basis) | Onboarding at the clinic |
| Marketing email / SMS | Used to opt in or out of clinic marketing | Yes — toggle in patient settings | Sign-up checkboxes or settings |
| Analytics | Used to opt in or out of pseudonymised usage analytics | Yes — toggle in patient settings | Sign-up checkboxes or settings |
| AI processing | Used to opt in or out of AI-assisted processing of the patient's clinical data | Yes — toggle in patient settings | Sign-up checkboxes or settings |
When a patient flips a marketing toggle off, the change takes effect immediately — no further marketing emails go out, the toggle is recorded as withdrawn in the ledger, and the audit trail shows who flipped it (the patient themselves, in normal cases).
When a patient wants to revoke the platform terms — the only path is to delete the account. The portal makes this explicit: "to revoke these, delete your account" with a button that triggers the GDPR erasure flow.
Tier B — Form-driven medical consents
These are the consents that ride on the clinic's signed forms — telemedicine acceptance, video recording consent, biometric capture consent, treatment-specific consents, profile-sharing consent. They are signed at booking time or before a specific activity, and they are signed against the clinic's privacy notice — never against the platform's.
Each Tier B consent has three signature modes available, depending on the situation:
- In-portal click — the patient signs from their phone or laptop, anywhere they have an internet connection. Used for telemedicine consents, profile-sharing, and most pre-appointment consent steps.
- Drawn on tablet at the clinic — the patient is at the front desk, the receptionist hands them a tablet, the patient draws their signature with a finger or stylus, and the signed form is saved immediately. No paper, no scanning, no separate app.
- Sent to phone via link — for consents that need to be signed quickly during a phone booking (older patients calling in, for example). The agent generates a one-time link, sends it to the patient's phone, and the patient completes the consent on their own device.
In every mode, the platform records the same proof: who signed, when, from which IP address, on which device, and against which exact version of the form text. Once signed, the form is legally immutable — the system rejects any attempt to alter it.
Withdrawal of Tier B consents is per-purpose. Withdrawing the video-recording consent stops video recordings going forward without affecting the underlying treatment plan or other consents.
Privacy Notices: Clinic-Owned, Platform-Scaffolded
Each clinic publishes its own privacy notice. The platform does not present a generic "RestartiX privacy notice" to patients on behalf of clinics — that would mis-attribute controllership.
Instead, the platform provides versioned templates that the clinic fills in:
- The platform ships a base template (in Romanian and English) drafted to ANSPDCP guidance, covering medical-records processing under GDPR Art. 9(2)(h), retention under Romanian Law 95/2006, patient rights, and the sub-processor list.
- The template has placeholders the clinic fills in: clinic name, registered address, DPO email, legal-basis summary, and so on.
- The template has toggleable sections for processing activities not every clinic does — video recording, biometric capture, cross-border transfer for tele-second-opinion. The clinic admin reviews each section and includes it only if it actually applies to their clinic.
- The clinic admin previews the assembled notice as it will appear to patients, and publishes.
- The published notice becomes the version the clinic's patients see and accept during onboarding.
When the platform updates its template (a regulatory change, a sub-processor change), every clinic gets a "review template update" prompt — but the clinic's existing notice keeps serving until the clinic re-publishes. There is never a moment when the legal artefact is in flux without the clinic explicitly approving it.
A clinic that has not completed and published their privacy notice cannot onboard patients. The "complete your privacy notice" task is part of clinic onboarding for exactly this reason.
What Platform Staff Can and Cannot See: Break-Glass Access
Platform staff (RestartiX support, security, engineering) cannot browse identifiable patient data across clinics by default. The Console — the platform's superadmin app — is built around this constraint. By default, every Console surface is aggregate / processor-scope: organisation list, organisation profile and billing, patient counters, audit metadata (timestamps, actions, status codes), system health.
Identifiable cross-tenant patient data — patient lists per clinic, patient details, audit log content with diffs — requires break-glass elevation.
How break-glass works
When a platform staff member needs to access identifiable patient data at a specific clinic — to investigate a support ticket, respond to a security incident, route a misdirected DSAR, or follow up on fraud — they must:
- Open an elevation session scoped to that one clinic and that one type of access (e.g. "patient detail at Clinic X").
- Provide a justification — a category (
support_ticket,security_incident,dsar_routing,fraud_investigation,platform_engineering) and a free-text reason, plus the ticket or incident reference if any. - Set an expiry — sessions default to 1 hour, capped at 4 hours. There is no "leave it open all day" mode.
- Have the right permission — break-glass scopes are individually permissioned, not blanket. A support engineer might have
break_glass.patient_detailfor one clinic but notbreak_glass.cross_org_lookup.
Once the session is open, every read the staff member makes inside it is logged in the audit trail — not just mutations. The session is closed automatically when it expires, or manually by the staff member or a colleague with break-glass-management permission.
Why clinics get notified, every time
The trade-off that makes break-glass defensible — to clinics, to patients, to regulators — is transparency. The moment a break-glass session opens against a clinic, the clinic admin gets:
- An email, naming who at RestartiX opened the session, when, what scope they elevated to, and the stated reason.
- An in-app banner in the clinic admin UI showing active and recent break-glass sessions against the clinic, with the same metadata.
The clinic always knows when platform staff have looked. There is no silent access path. If a clinic notices a session that does not match a support ticket or incident they were expecting, they have an audit trail to push back on, and the platform's contract obliges it to respond.
What is never break-glass
- Browsing all patients across all clinics — there is no Console page that does this.
- Reading patient clinical records to evaluate treatment plans — that is the clinic's job, not the platform's. RestartiX staff are not clinicians.
- Marketing or product analytics — those run on anonymised data only (see below).
What Clinic Staff Can See: Patient Impersonation
A separate but parallel pattern handles the everyday case of clinic staff acting on a patient's behalf — an elderly patient phoning in for help filling a form, an accessibility-impaired patient who needs the receptionist to book their appointment, a language barrier where bilingual staff translates. This is clinic-internal (clinic staff acting on their own patients) and is therefore not a controller/processor concern, but the same transparency posture applies.
When clinic staff act on behalf of a patient:
- They open a patient impersonation session with a stated reason and a short duration.
- The session is time-bound (default 1 hour, max 4); after expiry, no further actions can be taken under it.
- Every action in the session is logged to the audit trail as performed by the staff member, with the patient identified through the session record. Forms or appointments authored during the session bear patient authorship at the data layer; the audit row is the forensic source of truth for "this staff did this on the patient's behalf."
- The patient sees every session in their access history in the portal — who, when, the reason, how long it lasted, what entities were touched.
The trust posture here parallels break-glass — time-bound, reason-required, audited end-to-end, transparent to the affected party. The differences are deliberate: the affected party is the patient (not the clinic admin), and the access lives within the clinic's controllership boundary. The clinic already trusts the staff member with broader patient access via their core role; impersonation adds the audit and transparency layer on top, not finer-grain permissions.
The Cross-Tenant Anonymisation Rule
Any feature that needs to compute over multiple clinics' patient data — platform analytics, benchmarks, AI training corpus, cross-clinic search — operates on anonymised data only. Once data is irreversibly stripped of identifiers, it stops being personal data, and the controllership question dissolves.
Concrete example: when RestartiX builds a benchmark dashboard showing "average treatment plan adherence across all clinics on the platform", that dashboard is built from data where every patient identifier has been replaced with a one-way hash. The dashboard is useful for clinic admins — they can see how their clinic compares — but it cannot be reversed to identify any individual patient at any clinic.
We never identify your patients across clinics. If a feature genuinely cannot work without identifiable cross-tenant data, that is a deliberate decision requiring a separate architectural review and a documented justification — and the data-classification system enforces this at the egress layer.
How Patient Rights (GDPR DSARs) Are Handled
Patients exercise their GDPR rights — access, rectification, erasure, portability, restrict processing — against the controller. The controller for patient data is the clinic. The platform's role is to help the patient and the clinic complete the request, not to act as the primary recipient.
What the patient sees
In the patient portal, a "Your clinics" page lists every clinic the patient is registered at, with the per-clinic data-controller contact info: the clinic's DPO email, registered address, and a "Make a data subject request" button that pre-fills the right contact details and the patient's identity.
For routine requests the patient already knows how to handle:
- Access — the patient exports their data directly from the portal. The export contains everything the platform holds about them: profile, appointments, forms, consents, treatment plans. Structured and machine-readable.
- Rectification — the patient updates their own profile. For clinical corrections, they request the correction through clinic staff.
- Restrict processing — the patient toggles withdrawable consents directly (marketing, SMS, analytics, AI processing). Effect is immediate.
For non-routine requests:
- Erasure — the patient submits the request to the clinic. The platform supports the erasure flow (anonymisation rather than deletion, because medical-record retention is a legal obligation under Romanian Law 95/2006 — GDPR Art. 17(3)(c) explicitly allows this).
- Portability beyond the standard export — the patient submits the request to the clinic.
- Cross-clinic requests ("delete me everywhere") — each clinic handles the request independently. The platform helps the patient locate every clinic they have ever signed up at.
When a request comes to the platform by mistake
If a patient sends a DSAR to RestartiX directly without naming a clinic, the platform's response is to acknowledge receipt, identify the relevant clinic (or clinics), and route the request to the clinic's controller contact. RestartiX does not act as the primary controller for patient data, and the response makes that clear.
If the patient genuinely cannot identify which clinic they signed up at — the rare orphaned-ex-patient case — break-glass is the documented path: a platform staff member opens a dsar_routing session, locates the clinic, and forwards the DSAR. The clinic gets the same break-glass notification as any other elevated access.
How Consent Is Withdrawn
Withdrawal mechanics differ depending on the legal basis the consent was collected under:
| Consent | How to withdraw | Effect |
|---|---|---|
| Marketing email / SMS, analytics, AI processing | Toggle in patient settings | Immediate. Recorded in the consent ledger and the audit trail. |
| Profile sharing with a specific clinic | Withdraw in settings or through that clinic | The clinic immediately loses access to the portable profile and only sees the patient's name. Clinical records already created at the clinic remain (they are the clinic's records, not the patient's portable data). |
| Tier B medical consents (telemedicine, video recording, biometric capture, treatment-specific) | Withdraw through the clinic; some can be withdrawn from the portal | Immediate for the consent itself. The downstream effect depends on the consent — withdrawing video-recording consent stops new recordings; withdrawing biometric capture disables the camera-based measurement tools. |
| Clinic terms of service | "Leave clinic" flow in the portal | The patient's relationship with that clinic ends; their clinical records at that clinic enter the anonymisation flow per the clinic's retention policy. Other clinics on the platform are unaffected. |
| Platform terms of service | "Delete my account" flow in the portal | The account is closed and all platform-scope data is anonymised. The patient's data at each clinic is handled through that clinic's erasure process. |
Every withdrawal is a row in the consent ledger and a row in the audit trail. Re-granting a previously withdrawn consent creates a new ledger entry — the old withdrawal is preserved, and the full history is queryable later.
Why This Approach
The pre-production cost of getting this right is bounded and known: a consents table, a privacy-notice template machine, a break_glass_sessions table, an elevation modal in the Console, a "your clinics" page in the portal. A few weeks of foundation work.
The post-production cost of getting it wrong is unbounded. Removing a "browse all patients" Console surface after launch is a multi-quarter procurement-review nightmare. Fixing accidental joint controllership is a regulator-action-level event. The Romanian DPA (ANSPDCP) has issued public fines for this exact pattern at other healthtech platforms in the EU.
We build the foundation properly because the alternative is paying the foundation cost cumulatively, every time a new feature is built on top of a wrong shape.
Where to Read More
- GDPR Compliance — the regulatory framing and required documents
- Patient Rights — what each GDPR right looks like in practice
- Audit Trail — what is logged, including break-glass sessions
- Data Isolation — how clinic boundaries are enforced at the database level
- Compliance Checklist — the full launch checklist, by party and phase
- Architectural decision (deep dive) — the formal rationale, alternatives considered, and accepted trade-offs
For developers
The schema, RLS policies, and middleware that enforce all of the above are documented in the foundation implementation plan (sections 1B.9 — Consents Ledger, 1B.10 — Privacy Notice Templates, 1B.11 — Platform Break-Glass Access).