Health apps: how HDS, GDPR and medical device rules change your project

On a health app project, the first question isn’t “React Native or native?”. It’s “what does the app claim to do for its users’ health?”. The answer determines three things: the applicable GDPR framework, whether HDS-certified hosting (health data hosting, France’s certification for hosting health data) is required, and whether the app tips into the medical device regime. These three frameworks weigh more on the budget and timeline than any technical choice.

This guide covers them in the order they come up during scoping, with what they really cost. For an overview of what we build in this sector, see our dedicated health mobile app (in French) page.

Three frameworks, three different questions

These topics are often mixed up. Yet they answer distinct questions, and a single app may be subject to one, two or all three.

The classic mistake is to deal with the first framework and discover the other two three weeks before release. By then, hosting has already been chosen, the architecture is frozen and the store listing is written.

GDPR applied to health data

Health data falls under the special categories of data in Article 9 of the GDPR. Processing it is prohibited in principle, with exceptions — including the person’s explicit consent, or processing necessary for care under the responsibility of a professional bound by professional secrecy.

The notion is broad. A heart rate, a mood diary, a weight tracked over time, a medication intake or simply an appointment with a specialist can be enough to reveal a state of health. A meditation or fitness coaching app is therefore very often concerned, even if nobody in it talks about illness.

What this means concretely for development:

• Explicit, separate consent, distinct from acceptance of the terms and conditions, collected before the first sensitive data point and revocable from within the app.
• A data protection impact assessment (DPIA) in the vast majority of cases, since large-scale processing of sensitive data is covered. It is carried out during design.
• A data protection officer is mandatory if large-scale processing of sensitive data is at the core of your activity.
• Third-party SDKs cut to the strict minimum. An analytics or crash-reporting tool that reports a screen name such as “diabetes-treatment-tracking” is already sending health data to a third party.
• End-to-end encryption across the chain: in transit, at rest, and on the device for anything cached.
• Access logging, to know who viewed what and when.

We covered general compliance in our article on GDPR for mobile apps; everything in it applies here, in a reinforced version.

HDS: who is concerned, and what changes

The obligation to use HDS-certified hosting covers the hosting of personal health data collected during prevention, diagnosis, care or social and medico-social follow-up activities, on behalf of the professional, the institution or the patient themselves.

In practice, situations break down as follows:

The certification applies to the host, not to your app. You aren’t certified: you choose a certified host for the relevant scope — infrastructure only, or up to managed services and backup depending on the contract. The major cloud providers as well as several European players offer certified services; the revised standard also requires that data be hosted within the European Economic Area.

What this changes technically:

• Every component that sees the data must be within scope: database, file storage, backups, message queues, but also ancillary services. An email or notification service that carries medical content falls outside the scope if it isn’t covered.
• Push notifications must be neutral. The content passes through Apple’s and Google’s servers: “You have a new message” rather than “Your test results are available”.
• Test environments never receive real patient data. You need fictitious datasets from the start.
• The hosting contract must include specific clauses, and the choice is made early: migrating from standard hosting to HDS hosting mid-project costs several weeks.

The wellness / medical device line

This is the question with the greatest impact, and it is settled by a criterion that is simple to state but delicate to apply: the medical purpose claimed by the manufacturer.

Software is a medical device when it is intended for the diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of a disease, for an individual patient. It isn’t the technology that counts, it’s what you claim — in the interface, in the App Store and Google Play listing, on the website, in sales materials.

A few concrete reference points:

The last line is the most instructive. Two apps with identical code can have two different statuses depending on what their home page says. That’s why writing the product claims is part of regulatory scoping, just like the architecture.

If the app is a medical device, the classification rule specific to software places most decision-support software in class IIa or above. And from class IIa, a notified body must assess the device before CE marking. Add to that a quality management system (the ISO 13485 standard is the reference), a documented software life cycle (IEC 62304), risk management (ISO 14971), a clinical evaluation and post-market surveillance. If the software includes AI and falls under a notified body, it is also considered a high-risk system under the AI Act.

None of this is insurmountable, but it is no longer an app project: it is a device project, with a responsible manufacturer, a timeline in quarters and a regulatory budget of its own.

What it changes for the budget

The items below match what we see at scoping. They come on top of the usual budget for a full iOS and Android app and are priced via a free quote within 24 hours.

For a medical device, it is honest not to give a single figure. The cost of the quality system, technical documentation, clinical evaluation and notified body depends on the class and on what the company already has in place. It is common for it to equal or exceed the development budget, and part of it isn’t agency work: it belongs to a regulatory consultant and the notified body. Our role is then to produce software whose development, testing and traceability fit into that file.

Maintenance also increases: tracked security updates, access reviews, periodic penetration tests. Plan for a more comprehensive maintenance contract than average, depending on scope.

What it changes for the timeline

On a health app that is not a medical device, the typical schedule stretches by one to one and a half months compared with a standard app, because some steps can’t be run in parallel:

1. Regulatory scoping (1 to 2 weeks). Medical device qualification or not, HDS scope, legal basis, list of data, list of SDKs. This is where the product claims are written.
2. Choosing the host and contracting (2 to 4 weeks, in parallel with design). Commercial lead times for HDS offers are rarely short.
3. DPIA (in parallel with design). Its conclusions often change the architecture: pseudonymisation, separation of identifiers, retention periods.
4. Development with a security review at every delivery, not just at the end.
5. Penetration test and fixes (2 to 3 weeks) before release.
6. Release. Apple and Google ask for additional justifications for medical apps and check consistency between the store listing and the actual use of data.

For a medical device, the order of magnitude changes: between setting up the quality system, documented development and assessment by a notified body, you need to think in terms of 12 to 24 months before CE marking for a class IIa device. Hence, for many project owners, the appeal of launching a non-medical version first — with no diagnosis or monitoring claim — to learn, then building the device version on quality foundations laid from the start.

Cutting cost without taking risks

Four decisions, all to be made at scoping, make most of the difference.

Minimise the data collected. Every medical field removed reduces the scope of the DPIA, the testing and the hosting. The question “do we need it for the main journey?” is the same as for MVP scope, with a higher cost of error.

Separate what is sensitive from what isn’t. The content catalogue, accounts and billing don’t always need to be within the HDS scope. An architecture that isolates the medical core limits the hosting bill.

Write the product claims with the same rigour as the code. If the app isn’t a medical device, its copy must not suggest otherwise. A badly chosen phrase on the store listing costs more than a feature.

Choose compatible SDKs from the start. Replacing an analytics or messaging tool at the end of a project because it transfers data outside the EU is one of the most avoidable delays.

In short

A health app isn’t harder to code than any other. It is more demanding to scope: three regulatory frameworks, two of which can change the order of magnitude of the project. Settle the medical device qualification and the HDS scope before the first mock-up, price compliance as a line item in its own right, and the rest goes back to being a standard mobile project. Our plans and pricing give the baseline; our health mobile app (in French) page details our approach for clinics, practices, medtech and wellness players.

Have a health project and don’t yet know which side of the line it falls on? That’s exactly what a first conversation is for: contact us or call +33 1 59 13 25 55, and we’ll get back to you within 24 hours with a first regulatory and budget assessment.

Sources

• Qu’est-ce ce qu’une donnée de santé ? (in French) — CNIL (France’s data protection authority)
• Certification HDS - Tout savoir (in French) — Agence du Numérique en Santé (ANS)
• Règlement (UE) 2017/745 relatif aux dispositifs médicaux (in French) — EUR-Lex (European Union)
• Règlement (UE) 2024/1689 sur l’intelligence artificielle (AI Act) (in French) — EUR-Lex (European Union)