Privacy by design before you build: data minimisation, retention and the DPIA

Minimisation: collect less, and the rest takes care of itself

Data minimisation is the first design decision and the most powerful one, because data you never collected cannot be breached, cannot be subpoenaed, and never shows up in a regulator's report. The NDPA puts it plainly: personal data must be adequate, relevant, and limited to what is necessary for the purpose. So the design question for every field on every form and every screen is narrow. What clinical or administrative decision depends on this, and what happens to the care if the field is blank? If nothing breaks, the field should not exist.

Most hospital intake forms fail this test on first read. A maternity unit does not need a patient's employer to deliver a baby. A pharmacy does not need a home address to dispense. The "complete profile" instinct, where the system insists on filling every box because the developer made them mandatory, is how a clinic ends up holding a richer dossier on a citizen than the bank does. Purpose limitation is the partner rule: data gathered to treat a patient is not, by default, available to feed a marketing list, a research study, or a sister facility, unless that purpose was named when the data was taken. Tie each data category to a stated purpose at design time, and the access model downstream becomes far easier to reason about.

Retention: a clock on every record, and a deletion that actually fires

Storage limitation is the rule hospitals break most quietly, because keeping data costs nothing visible and deleting it feels reckless. The NDPA requires that personal data is kept no longer than necessary for the purpose it was collected for. The National Health Act and the professional record-keeping rules set the floor: certain clinical records must be retained for defined minimum periods, and for a minor that clock can run from the age of majority rather than the date of care. Privacy by design means encoding those periods into the system as a retention schedule, per record type, rather than leaving "delete" to a junior staffer's judgement at year end.

The harder half is making deletion real. A retention policy that nobody enforces is just a document that proves you knew better. Design the deletion to fire automatically when the clock expires, and decide up front what "deletion" means for your backups and archives, because a record purged from the live EHR but sitting in twelve years of nightly backups has not really gone. Where the data still has lawful research or audit value past its clinical life, the answer is usually de-identification, not indefinite retention.

Secondary uses: de-identify before the data leaves the ward of its purpose

Hospitals do legitimately want to reuse patient data: to study readmission patterns, to report to a funder, to train clinical staff. The mistake is reusing the identified record for a purpose it was never collected for. Pseudonymisation and de-identification are the design controls here. Strip or tokenise the direct identifiers (name, hospital number, phone, BVN where it crept in) so the dataset used for analysis cannot be trivially tied back to a named patient, and keep the re-identification key separate and tightly held. Build this as a pipeline the system can run on demand, not a manual spreadsheet exercise a tired registrar does at 9pm.

The same discipline serves data-subject rights, which the NDPA grants and which a well-designed system can answer in minutes instead of weeks. A patient who asks what you hold, or asks for a correction, or withdraws a consent that was the basis for some processing, is exercising a legal right. If the design already maps each data category to its purpose and lawful basis, those requests are queries against a structure you understand. If it does not, every request becomes an archaeology dig. Consent itself should be designed as something specific and revocable, recorded against the purpose it covers, not a single tick on admission that the hospital then treats as permission for everything forever.

The DPIA: the deliverable that precedes procurement

All of the above lands in one document: the data protection impact assessment. The NDPA expects a DPIA where processing is likely to result in high risk to data subjects, and a hospital EHR holding sensitive health data on thousands of Nigerians is squarely in that territory. The point of timing is the whole point. A DPIA written after you have signed the EHR contract is a compliance receipt. A DPIA written before you issue the procurement is a design tool, because its findings can still change what you buy.

A useful DPIA for a hospital maps the data flows end to end (what is collected, by whom, where it is stored, who it is shared with, including the vendor and any sub-processor), identifies the lawful basis and the risks to patients at each step, and records the mitigations the design will carry. From that map, the procurement questions write themselves. Does the system let us mark fields as not-collected rather than mandatory? Can we set retention per record type and have deletion run automatically? Can it produce a de-identified extract without a manual export? Where will our data physically live, and who at the vendor can see it? Those are design-stage questions for the EHR supplier, and they belong in the same conversation as the contract terms a vendor risk programme handles. The DPIA is also your evidence of the NDPA's accountability principle: proof, on paper, that the privacy decisions were made deliberately and before harm could occur.

What to settle before the first record is keyed in

• Justify every field. If no clinical or administrative decision depends on a data point, do not collect it.
• Name a purpose and a lawful basis for each data category, and do not reuse data for purposes outside it.
• Set a retention period per record type, sized to the NHAct floor, and make deletion fire automatically, backups included.
• Build de-identification and consent withdrawal as system functions, not manual end-of-day tasks.
• Complete the DPIA before procurement, and use its data-flow map to write your questions to the EHR vendor.

Privacy by design is not a feature you switch on. It is the set of decisions you make while the system is still cheap to change. Get them on paper before you sign, and the expensive version of this problem never arrives.