Patient Rights
What patients can do with their data — access, correct, delete, export, and control who sees it.
Overview
Patients are not passive users of the platform. Under GDPR (and HIPAA for US patients), they have enforceable legal rights over their personal data. The platform is built to honor these rights as part of its normal operation — not as an exception process.
Patients exercise their rights against the controller of their data — which, for everything substantive (clinical records, treatment plans, appointments, marketing preferences), is the clinic, not RestartiX. The platform helps route the request and provides self-service tools where it can; the clinic is the legal counterparty. See How Patient Data Is Protected for the full controller/processor model.
Rights and How They Work
Right to access
"Show me all the data you have about me."
Patients can export all their data as a structured file through the platform. This includes their profile, appointment history, form responses, consent records, and treatment plan data.
Right to rectification
"My data is wrong — fix it."
Patients can update their own profile data directly. For clinical records, they can request corrections through clinic staff. All changes — whether made by the patient or by staff — are recorded in the audit trail.
Right to erasure
"Delete my data."
When a patient requests erasure:
- Their personal data is anonymized — all identifying information is removed
- Medical records are anonymized rather than fully deleted, because Romanian and EU law require minimum retention periods for healthcare records. GDPR explicitly allows this under Article 17(3)(c).
- The anonymization is irreversible — once done, the patient cannot be re-identified from the remaining data
- The audit trail records that erasure was performed, when, and by whom
Right to be informed
"Tell me what you're collecting and why."
Each clinic presents its privacy policy during onboarding as a blocking consent form. The policy must explain what data is collected, for what purpose, how long it's kept, and the patient's rights. Consent is recorded with a timestamp, method, and the exact policy version that was presented.
Right to restrict processing
"Stop using my data for this purpose."
Consent can be withdrawn per purpose. Withdrawal takes effect immediately and is recorded in the consent ledger and audit trail.
Withdrawable purposes a patient can toggle from settings:
- Marketing email and SMS
- Pseudonymised analytics
- AI processing of their clinical data
- Telerehab, telemedicine, video recording and biometric capture — each turns off the capability it names, and nothing else
Tier B medical consents (telemedicine, video recording, biometric capture, treatment-specific) are typically withdrawn through the clinic; some can also be withdrawn from the portal. Withdrawing the platform terms of service is structurally equivalent to deleting the account — the portal makes this explicit and triggers the GDPR erasure flow.
For the full mechanics including the three signature modes for Tier B consents, see How Patient Data Is Protected.
Right to data portability
"Give me my data in a format I can take elsewhere."
The data export produces a structured, machine-readable format that the patient can provide to another healthcare provider or platform.
Consent is Per-Clinic
A critical aspect of patient rights on the platform: consent given at one clinic does not extend to another. Each clinic relationship is fully independent.
How it works in practice
1. First visit — patient books at Clinic A
The patient creates an account and gets a portable profile — their basic identity and health facts (name, date of birth, blood type, allergies, insurance). This profile belongs to the patient, not to any clinic.
At the same time, the platform registers that this person is now a patient at Clinic A — and that registration is what gives Clinic A the portable profile. The patient does not re-enter their date of birth or allergies, and there is no separate step in which they hand the profile over: joining the clinic is the act.
Clinic A then presents its consent forms: privacy policy, clinic terms, and any activity-specific consents. These are blocking — the patient must sign before proceeding.
All consent is recorded under Clinic A specifically.
2. Later — same patient books at Clinic B
The platform recognizes the patient already has an account and reuses the same portable profile. But from Clinic B's perspective, this is a brand new patient relationship.
Clinic B presents its own consent forms — under Clinic B's branding and privacy policy. The patient must accept them again, independently, and doing so registers them at Clinic B and gives Clinic B the same portable profile. Nothing about Clinic A travels with it.
3. What each clinic can see
| Data | Visible to the other clinic? |
|---|---|
| Patient name | Always — minimum needed for scheduling |
| Portable profile (date of birth, allergies, blood type, insurance) | Only where the patient is registered — it is the patient's own data, carried by them |
| The other clinic's appointments, forms, reports, prescriptions | Never — clinical records are completely isolated between clinics |
| The other clinic's consent records | Never — consent is recorded per clinic |
This means a patient attending Clinic A and Clinic B has one profile and two entirely separate records, and leaving one clinic ends that clinic's access without touching the other.
How Records Cross Clinics
They don't — by design.
If a patient wants Clinic B to see records from Clinic A, they do it the traditional healthcare way: export or download from Clinic A and provide it to Clinic B themselves.
The platform does not share records between clinics automatically. This is a deliberate design choice — automatically sharing records would classify the platform as a Health Information Exchange (HIE), which carries significantly heavier regulation under both HIPAA and GDPR.
How a DSAR Reaches the Right Place
A Data Subject Access Request (DSAR) is the formal name for the patient exercising one of the rights above — in writing or via a request form. Because the clinic is the controller, DSARs route to the clinic.
In the patient portal, a "Your clinics" page lists every clinic the patient is registered at, with each clinic's data-controller contact info — DPO email, registered address — and a "Make a data subject request" button that pre-fills the right contact and the patient's identity.
For routine requests, the patient does not need to wait for a DSAR response — they can self-serve directly:
| Request | Self-serve? |
|---|---|
| Export my data | Yes — the portal generates the export |
| Update my profile | Yes — the patient edits directly |
| Toggle marketing / analytics / AI processing | Yes — toggles in settings |
| Stop a clinic seeing the portable profile | Yes — by leaving that clinic, which ends the care relationship and its access |
Non-routine requests (erasure beyond what the standard anonymisation flow does, portability in a custom format, complex restrict-processing requests) go to the clinic via the DSAR contact.
If a patient sends a DSAR to RestartiX directly without naming a clinic, the platform acknowledges receipt, identifies the relevant clinic(s), and routes 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. The rare case where a patient cannot identify which clinic they signed up at goes through the documented break-glass path — see How Patient Data Is Protected.
Summary
| Right | What the Patient Does | What Happens |
|---|---|---|
| Access | Requests data export | Receives structured file with all their data |
| Rectification | Updates profile or requests correction | Data updated, change logged in audit trail |
| Erasure | Requests deletion | Data anonymized, medical records preserved without identifiers |
| Information | Reviews privacy policy | Presented during onboarding, consent recorded with policy version |
| Restriction | Withdraws specific consent | Processing stops for that purpose immediately |
| Portability | Requests portable export | Receives machine-readable data file |
For developers
Technical details — anonymization implementation, data export endpoints, consent tracking schema, and GDPR operation logging — are available in the GDPR Compliance reference.