Designing privacy into health apps

A health application earns its users’ trust or loses it in the design phase. Once data has been collected without a clear purpose, copied into analytics tools and backed up indefinitely, no privacy policy can put it back. Privacy by design means treating the protection of personal data as a requirement with the same standing as clinical safety and performance: specified, built, tested and maintained in code, not left to a document that developers never read.

Know what makes health data special

Most data protection frameworks treat health information, genetic data and biometric data used to identify a person as special categories requiring stronger justification and stronger safeguards. In practice this means a lawful basis must be identified for each purpose, access must be tightly limited, and the consequences of a breach are judged more severely. ISO 27799 provides guidance on applying information security controls in health settings and is a useful companion to an ISO 27001 management system. Treat biometric data with particular care: a fingerprint or face template cannot be changed if it is exposed. Location data, appointment histories and even the fact that a person uses a particular app can reveal a health condition, so treat them with the same care as clinical records. When in doubt, classify upwards.

Consent before capture

Where consent is the basis for processing, it must be obtained before the data is captured, not inferred afterwards. Present each purpose separately and in plain language, in the languages your users read. Care, research and service improvement are different purposes and should not be bundled into a single checkbox. Record consent as structured data with the version of the wording shown, the time and the scope, so that every downstream process can check it. Make withdrawing consent as easy as giving it, and make sure withdrawal actually stops processing. Think carefully about consent on shared devices and for people who cannot read, are minors, or are acting on behalf of a relative; each needs a defined process rather than an assumption. Where a community health worker records data on a patient’s behalf, the app should make clear whose consent is being captured and how it was obtained, and record that alongside the consent itself.

• Store consent as a first-class record that services query, not as a flag buried in a profile.
• Block features that depend on a purpose until consent for that purpose exists.
• Re-ask when the purpose or wording changes materially.
• Distinguish clearly between consent and other lawful bases, such as the provision of care, so users are not misled.

Collect less

Data minimisation is the most effective privacy control because data that was never collected cannot be breached, misused or demanded. For every field, ask what decision or service depends on it. Prefer derived values to raw ones where they suffice: an age band instead of a date of birth, a district instead of a full address. Keep identifying details separate from clinical data and link them with internal identifiers, so that most services can work with pseudonymised records. Be especially careful with analytics, crash reporting and logging tools, which can quietly capture health information in URLs, screen names and error messages. Review third-party software development kits before including them, because many transmit device and usage data by default.

Retention and deletion enforced in code

A retention schedule that lives only in a policy is not enforced. Define retention periods for each category of data, agreed with clinical, legal and records staff, and implement them as scheduled jobs that delete or anonymise records when their period ends. Make the jobs observable: log what they removed and alert when they fail. Remember the copies: replicas, exports, caches, search indexes and backups all hold personal data, and each needs its own rule, even if backups are handled by expiry rather than targeted deletion. Users and regulators may ask for personal data to be erased, subject to legal obligations to retain clinical records. Design for deletion from the start by knowing where every piece of personal data lives. Maintain a data map that lists each store, what it holds and how deletion is applied there. Where clinical records must be kept, restrict access to them and stop using them for secondary purposes rather than claiming they were deleted. Test deletion end to end, including third-party processors, and keep evidence that it happened.

A retention schedule that lives only in a policy is not enforced.

Log every access and every exchange

In health systems, one of the hardest privacy failures to detect is not an outside attack but an authorised user looking at records they have no reason to see. Record who accessed which record, when, from where and for what declared purpose, in a log that the users being monitored cannot alter. Review it, both automatically for patterns such as staff viewing records of colleagues or public figures, and on request when a patient asks who has seen their information. Access logs should themselves be protected, since they reveal who is being treated. Exchanging data with other systems is often essential to care, and standards such as HL7 FHIR make it far easier. FHIR resources can carry consent, provenance and security labels, but those mechanisms only help if the receiving and sending systems respect them. Scope each integration to the minimum resources and fields it needs, authenticate every connection, and log every exchange.

Do the impact assessment early

• Carry out a data protection impact assessment while the design can still change, not after launch.
• Describe the data flows, purposes, lawful bases, risks to individuals and the controls that address them.
• Involve clinicians, security staff and, where possible, representatives of the people whose data is processed.
• Revisit the assessment whenever a new purpose, data type or processor is added, and keep each version as a record of the reasoning behind the design.

Privacy designed in this way is not a constraint on a good health application. It is part of what makes it one: patients share more accurately with services they trust, and that accuracy is what makes care safer.