Our transparency-first DPIA, assessing the privacy risks of Mediscanner — now including logged-in accounts and the appointment-request flow — and the measures we take to mitigate them.
We conduct this DPIA in the spirit of Art. 35 GDPR. Since v2 the platform now offers logged-in accounts and an appointment-request feature touching health-adjacent data (Art. 9), so we publish this assessment proactively to demonstrate accountability under Art. 5(2).
| Activity | Personal data | Subjects | Storage |
|---|---|---|---|
| Symptom checking | Selected symptoms (non-identifying) | Visitors | On-device only; not transmitted |
| Account / login | Email + hashed password, account dates | Account holders | Netlify Identity (processor, Art. 28) |
| Appointment request | Doctor, hospital, date/time, reason, account email | Account holders | Netlify Forms + a local-only mirror in the user's browser |
| Contact / messages | Name, email, message, topic | Visitors & account holders | Netlify Forms; short retention |
| Site delivery | IP, user-agent (logs) | Visitors | Host logs; rotated |
Sensitive inputs (symptom selection) remain on-device. Account creation and login happen via Netlify Identity. Appointment requests and messages are submitted to Netlify Forms and emailed to our team. A local mirror of submitted requests is kept in the user's browser so they can see their submission history in My data; the user controls this and can wipe it via the deletion option.
We assessed each data element against its purpose and applied data minimisation (Art. 5(1)(c)). Health-adjacent inputs are limited to what's required to schedule a single appointment with a named clinician. We do not request medical history, IDs or financial data. Sensitive matching (symptoms) runs entirely on-device. The processing is therefore proportionate and necessary for the informational and scheduling purposes.
Scored on likelihood × impact (Low / Medium / High) prior to mitigation.
| Risk | Likelihood | Impact | Inherent rating |
|---|---|---|---|
| Exposure of symptom inputs in transit | Low | High | Medium |
| Account credential leakage / weak auth | Low | High | Medium-High |
| Exposure of appointment requests (health-adjacent) | Low | High | Medium-High |
| Misinterpretation of the service as a clinical system | Medium | High | High |
| Excessive log retention | Medium | Low | Low |
| Third-party transfer concerns | Low | Medium | Low |
| Risk | Mitigation | Residual |
|---|---|---|
| Symptom exposure | On-device processing; nothing transmitted or stored | Low |
| Credential leakage | Server-side hashing via Netlify Identity (Art. 28); email-confirmation registration; no passwords in code | Low |
| Appointment data exposure | Explicit consent (Art. 9(2)(a)); minimal fields; HTTPS in transit; processor DPA; user-controlled deletion via My data; clear scoping as "request" not "booking" | Low-Medium |
| Misinterpretation | Prominent disclaimers, "not a medical device" framing (EU MDR), clear "this isn't a clinical system" notice on the appointment form | Medium-Low |
| Log retention | Short rotation by host | Low |
| Transfers | EEA-first hosting; SCCs (Art. 46) where transfers occur | Low |
After mitigation, no residual high risk remains that would require prior consultation under Art. 36. We will reassess if processing changes.
This DPIA will be reviewed at least annually and whenever the nature, scope, context or purposes of processing change. Prior to commercial launch, it will be formally signed off by a DPO or qualified legal counsel, with any EU representative details added.