Privacy by Design in Health Apps. Why Local-Only Storage Matters for Cancer Patient Companions.

The first design decision in a health application is not which screens to draw. It is where the data lives. That single choice cascades through the legal architecture, the regulatory pathway, the trust relationship with users, and ultimately the long-term survivability of the product. For an application built to support cancer patients through treatment, getting this choice wrong is not a footnote. It is the whole story.

This essay argues, from the perspective of a working solo developer, that local-only data storage is the most defensible starting point for sensitive health applications. Not because it is fashionable, and not because it is convenient. It is neither. But because the alternative requires a much heavier compliance and operational burden than most small teams can carry while still producing a good product.

The category the data falls into

Under the European General Data Protection Regulation, data concerning health is not ordinary personal data. It falls under Article 9 as a special category of data, alongside biometric data, genetic data, and information about sexual orientation. Processing it requires either explicit consent or one of a narrow set of legal bases. Even then, the regulation expects controllers to implement protections proportional to the sensitivity involved.

For a breast cancer companion app, the data involved is unambiguously in this category. Diagnosis dates, treatment regimens, side effects, medication schedules, mental state markers. All of it. The moment such an application starts storing this on a server, the developer becomes a controller of special-category data with all that this entails: a data protection impact assessment, technical and organisational measures, breach notification obligations, and a relationship with supervisory authorities that does not exist if the data never leaves the device.

The architectural choice

Local-only data storage means, in practical terms, that the application reads and writes patient data exclusively to the device’s protected storage. There is no synchronisation to a cloud account. There is no server-side backup. The data is not transmitted to any third party: not for analytics, not for crash reporting, not for AI processing.

This approach has clear costs. Users who lose their device lose their data. Users with multiple devices cannot see the same record across them. Recovery options are limited to whatever the operating system itself offers (iCloud Backup, for example, which is encrypted but happens at a layer outside the application’s control). These are real trade-offs and the user must be told about them clearly.

What is gained is structural. The application is no longer a controller of special-category data in the sense that triggers most of the heavier GDPR obligations. There is no server breach to worry about because there is no server. There is no question of which jurisdiction the data is processed in, because it is processed in only one place: on the user’s own phone. The user is in literal physical possession of their record.

The regulatory dividend

Beyond GDPR, the same architectural choice pays dividends in the medical device regulation pathway. Under the EU Medical Devices Regulation, the classification of an application, and the associated conformity assessment burden, depends in part on the risks the software introduces. An application that never transmits, never aggregates, and never performs any form of processing beyond local logging and visualisation is intrinsically lower-risk than one that does.

This does not mean such an application automatically becomes Class I. The classification depends on the intended purpose. But it does mean that the technical documentation, the risk analysis under ISO 14971, and the clinical evaluation under MDR are all simpler and more honest when there is less to defend. For the regulatory side in detail, see The MDR Pathway for Solo Developers.

The most defensible health application is the one that does the least with the data. And is honest about it.

The trust dividend

There is also a quieter benefit, harder to measure but easy to feel: trust. Patients in active treatment are exhausted, frightened, and sceptical of yet another company asking for their data. A clear statement that the data lives only on their phone, and that no copy exists elsewhere, lands very differently from a paragraph about how data is encrypted in transit and at rest with industry-standard protections.

The first kind of statement is something a user can verify by turning off their phone. The second is something they have to take on faith. For applications used during a serious illness, that difference matters.

What this means in practice

For a small studio building such an application, local-only storage shapes the entire technical stack. On iOS, this means careful use of the platform’s secure storage, attention to which backup mechanisms include the data, and explicit user choice about whether to participate in any optional export feature. It means no third-party analytics SDKs. It means no crash reporting service that ingests user data. It means writing the application as if the developer will never see the data. Because they will not.

This is a more constrained way to build software. It rules out many of the conveniences that small teams normally rely on for product analytics, feature flag testing, and remote debugging. The trade is worth it for one class of application: the kind where the data is so sensitive that the safest place for it is the user’s own pocket.

A short note on what this is not

Local-only data storage is not, in itself, a privacy guarantee. An application can still ship telemetry, request unnecessary permissions, or leak data through poorly designed sharing features. The architecture is a foundation, not a finish. But it is a foundation that makes everything built on top of it easier to defend, easier to verify, and easier for the user to trust.

For a cancer companion app, that foundation is the starting point, not the optimisation.

Frequently asked

What does „Privacy by Design" mean in practice for a health app?

Privacy by Design means that data protection is anchored in the architecture, not in disclaimers added later. For a health app this means patient data is stored exclusively on the user's device, never on a server. No synchronisation, no cloud backup, no transmission to third parties for analytics, crash reporting, or AI processing.

Which GDPR provisions matter most for health apps?

Health data falls under Article 9 GDPR as a special category of personal data. Processing it requires explicit consent or one of a narrow set of legal bases. Controllers must implement protections proportional to the sensitivity involved, conduct a data protection impact assessment under Art. 35, and meet breach notification obligations under Art. 33.

What are the trade-offs of local-only storage in health apps?

Three main costs: users who lose their device lose their data, multi-device use is limited, and recovery depends on what the OS provides (iCloud Backup on iOS). The gain is structural relief from server-breach risk, jurisdictional questions, and many of the heaviest controller obligations under the GDPR.

How does local-only data affect the EU MDR pathway?

An application that never transmits, never aggregates, and performs no processing beyond local logging is intrinsically lower-risk. This improves the risk analysis under ISO 14971 and the clinical evaluation, but does not automatically place the device in Class I. The final classification depends on the intended purpose.