The short answer
Four decisions shape everything: what you collect, how identifiers are stored relative to clinical data, how access is granted, and what is logged. Settle those at design time with your data protection lead involved.
This is general guidance. Health data is special category data in many jurisdictions and you should take specific advice for yours.
Collect less
Every field you collect is a field to secure, retain and eventually delete. The instinct to capture everything in case it is useful is the opposite of what the obligation requires.
- Ask what decision each field supports; remove fields with no answer
- Prefer a band to an exact value where the band is sufficient
- Avoid collecting identifiers you do not need to identify anyone
- Question free text fields, which attract more than they should
Separate where you can
| Use case | Approach |
|---|---|
| Direct care | Identified, access by care relationship |
| Service management | Usually aggregate or pseudonymised |
| Research or analysis | Pseudonymised or anonymised, with approval |
| Testing and development | Never production data unmasked |
The last row is the most commonly broken and the easiest to fix. Masking during the copy rather than afterwards removes a whole category of incident.
Access by relationship, not just by role
Role alone is too coarse for health data. A clinician should generally see records for patients in their care rather than every record in the organisation.
Where broader access is needed for legitimate reasons, a break-glass mechanism that requires a reason and generates an alert is a better answer than standing access.
Retention and deletion
Health records have long retention requirements that vary by record type and jurisdiction. Design retention in rather than planning to work it out later, because unpicking it from a schema that assumed indefinite storage is hard.
Deletion needs to be provable as well as done. Evidence that a scheduled deletion ran is what an auditor asks for, not the policy that says it should.