GDPR and the nutrition clinical record: minimum viable
What to document, what not to store, and how to audit the digital file without paralysing practice
The nutrition clinical record contains health data: anthropometry, conditions, medication, eating habits, and often body photographs. GDPR does not ban digital practice; it requires **transparency, legal basis, security, and traceability**. This guide summarises the minimum any dietitian or centre should have before digitising consultations.
Does GDPR apply to my nutrition practice?
Data controller:
- Self-employed dietitian → you are controller of your records
- Centre/clinic → the centre is usually controller; the clinician acts as processor or authorised user per internal agreement
Processor: the software provider (SaaS) hosting data on your behalf. A data processing agreement (DPA) or equivalent clauses in terms of service must exist.
Legal basis: not everything is «consent»
1. Contract / healthcare provision (Art. 6.1.b + 9.2.h): preparing and following the agreed nutrition plan
2. Legal obligation (Art. 6.1.c): retention of clinical records per national health law
3. Vital interests (Art. 9.2.c): emergencies only (rare in scheduled visits)
4. Explicit consent (Art. 9.2.a): for non-essential processing — e.g. marketing photos, newsletter, sharing with non-health third parties
Privacy acceptance at intake covers data processing for care; it does not replace clinical informed consent for specific procedures (e.g. ISAK assessment with photography).
What the digital record must log (GDPR minimum)
- Privacy policy acceptance (date, time, not pre-checked)
- Identification of controller (professional or centre name)
- Purpose: nutrition service provision
During follow-up:
- Who accessed the record and when (basic audit)
- Specific signed consents (portal, intake, procedures)
- Relevant communications logged (not loose WhatsApp without file copy)
Do not store without need:
- Full ID copies if not mandatory
- Third-party data unrelated to care
- Personal notes about unrelated people
- Passwords or full bank details in free-text notes
Patient rights: responding within 30 days
| Right | Practice |
|-------|----------|
| Access | Copy of their record (PDF export or extract) |
| Rectification | Correct errors (name, allergies…) |
| Erasure | «Right to be forgotten» — limited if legal retention of clinical history applies |
| Restriction | Block non-essential processing while a dispute is resolved |
| Portability | Structured data (CSV/JSON) where technically feasible |
| Objection | Direct marketing; not ongoing clinical care |
Deadline: 1 month (extendable 2 months if complex). Log each request and response internally, even in a spreadsheet initially.
Retention and deletion: how long to keep data
Good practice:
- Written retention policy (even one page)
- Archive discharged patients; do not delete clinical data prematurely
- At end of period: secure deletion or irreversible anonymisation
- Backups: SaaS provider must state retention on backup copies
Deleting a record «because the patient asked» without checking legal obligation can cause more problems than restricted retention.
Minimum technical security (without being IT)
☐ HTTPS on entire application
☐ Password hashing (never plain text)
☐ Session timeout after inactivity
☐ Distinct roles (centre admin vs. clinician vs. patient)
☐ Automatic backups
☐ EU servers or transfer clauses if outside EU
☐ Record access logging
☐ AI: patient name anonymisation when sending data to external APIs
If you use Excel on USB or unencrypted email, the software may be GDPR-ready but your manual workflow is not.
15-minute GDPR checklist for your practice
☐ Non pre-checked acceptance on forms
☐ Contract or terms with SaaS provider (processor)
☐ Written procedure for access/erasure requests
☐ Basic team training: no sharing screens with data on public networks
☐ Record access only for clinicians treating the patient
☐ Paediatrics: legal guardian identified and authorised on portal
☐ Annual review: is policy current? new modules (AI, portal)?
Want a digital record with built-in consent and traceability?
NutriManager records privacy acceptance at intake, controls access by role, and anonymises data in AI modules.
Frequently asked questions
You can, but WhatsApp is not an audited clinical system. For stronger compliance, use patient portal or encrypted email. If you use WhatsApp, document patient preference and avoid unnecessary sensitive data in chat.
They may choose another professional or request limitations. If they accept the service, clinical cloud software with a DPA is common and legitimate. Be transparent about where data is hosted.
NutriManager includes intake consent, access roles, basic audit, and anonymisation in AI modules. Overall compliance also depends on how you configure your centre, your privacy policy, and your relationship with the patient.
No per-visit GDPR log is required. You do need a record of processing activities (ROPA) at controller level, describing purposes, data categories, and retention periods.
Notify the supervisory authority within 72 h if there is risk to individuals' rights, and the patient if risk is high. Your SaaS provider should have an incident procedure; keep it documented.