The global digital health market is worth $274 billion in 2025, with annual growth of 16% expected through 2030 (Mordor Intelligence). In France, 23 million people actively use Mon espace santé, and 42.8 million medical documents were shared on the platform in October 2025. The opportunity is enormous—but so is the regulatory framework surrounding it.
Developing a healthcare application that incorporates AI in France means navigating GDPR, HDS certification, the French Public Health Code, the CNIL's reference methodologies and, since March 2025, the European Health Data Space (EHDS) regulation simultaneously. Overlooking any of these regulatory layers exposes you to penalties of up to €20 million or 4% of revenue.
This article explains each regulatory constraint, shows how to incorporate it from the design stage of a custom project, and provides a technical roadmap for delivering a compliant healthcare application without sacrificing timelines.
TL;DR: A healthcare application handling patient data must comply with the GDPR's stricter rules for sensitive data, use an HDS-certified hosting provider, incorporate privacy by design into its architecture, and prepare for the EHDS regulation. This guide covers legal obligations, infrastructure choices, compliant development patterns and pitfalls to avoid.
France's Healthcare Regulatory Framework: Three Layers to Master Simultaneously
GDPR and Health Data: A Special Regime
Health data falls within the category of sensitive data under Article 9 of the GDPR. Processing it is prohibited in principle, except in a strictly defined set of circumstances: the patient's explicit consent, necessity for healthcare, public interest in the area of public health, or scientific research subject to appropriate safeguards.
In France, the CNIL adds another layer. The French Data Protection Act retains specific prior formalities for processing health data. Depending on the type of processing, the controller will need to obtain CNIL authorization, comply with a reference methodology (MR-001 to MR-006), or carry out a data protection impact assessment (DPIA).
Failure to meet these obligations has tangible consequences. In 2024, the CNIL imposed 87 sanctions totaling more than €55 million in fines. In the healthcare sector specifically, Cegedim Santé received an €800,000 fine for processing health data without authorization—with the CNIL emphasizing the fundamental distinction between pseudonymization and anonymization.
HDS Certification: A Legal Requirement, Not an Option
Health data hosting—Hébergement de Données de Santé, or HDS—is governed by Article L.1111-8 of the French Public Health Code. Any organization hosting personal health data on behalf of a third party must hold HDS certification.
The updated HDS framework, published in France's Official Journal on May 16, 2024, strengthens the requirements. It is based on ISO 27001:2022 and introduces healthcare-specific controls. All providers already certified have a transition period until May 16, 2026, to comply with the new version.
The framework identifies six certifiable activities, grouped into two types of certificate:
| Certificate type | Activities covered |
|---|---|
| Physical infrastructure hosting provider | Provision of physical hosting premises; provision and maintenance of hardware infrastructure |
| Managed hosting provider | Provision of virtual infrastructure; provision of an application software platform; administration and operation of healthcare information systems; outsourced backups |
In practice, if your application handles patient data—even temporarily—the server storing it, the provider administering it and the service performing backups must all be HDS-certified. Certified solutions cost an average of three to four times as much as standard cloud hosting, with prices ranging from €300 to €1,000 per month for a single server.
The EHDS Regulation: A New European Landscape
Regulation (EU) 2025/327 on the European Health Data Space was published in the Official Journal of the EU on March 5, 2025. It will be rolled out progressively between March 2027 and March 2035.
The regulation introduces two distinct uses of health data. Primary use (MyHealth@EU) concerns data exchange between healthcare professionals for direct patient care. Secondary use (HealthData@EU) concerns reusing data for research, innovation or health policy.
For healthcare application developers, the EHDS means designing systems now that can interoperate with European standards—patient summaries, e-prescriptions and e-dispensations—whose rollout will begin in March 2029.
Mapping Health Data in Your Application
What Legally Qualifies as Health Data
The definition of health data is broader than many people realize. It encompasses three distinct categories.
Data that is inherently health-related: medical histories, diagnoses, treatments, test results, prescriptions, genetic data and biometric data used for medical purposes.
Data that becomes health data when combined: a name associated with an appointment in an oncology department, a patient identifier linked to a prescription, or even an IP address combined with a visit to a website specializing in a particular condition.
Data that reveals a health condition through the purpose for which it is used: data collected by a connected wristband as part of medical monitoring, answers to a symptom questionnaire, or geolocation data in a medical emergency.
The Preliminary Audit: Identify Every Sensitive Data Flow
Before writing a single line of code, you need to audit your data flows. Every point at which health data enters, is processed, is stored or leaves the system must be mapped. This work directly feeds into the record of processing activities required by GDPR and the impact assessment (DPIA) that will probably be necessary.
The key questions for this audit are:
- What health data does the application collect, directly or indirectly?
- What is the legal basis for each processing activity: consent, necessity for care or public interest?
- Where is each piece of data stored, and is the hosting provider HDS-certified?
- Which third parties access the data, and in what capacity: processor or joint controller?
- How long is each piece of data retained, and how is it deleted?
- Do data flows cross borders, including transfers to cloud services whose servers are outside the EU?
That last point is critical. The updated 2024 HDS framework strengthens data sovereignty requirements. Using an HDS-certified US cloud provider remains possible, but requires additional safeguards concerning the data's actual location and protection against extraterritorial legislation such as the CLOUD Act.
Privacy by Design: Building Compliance into the Technical Architecture
The Seven Principles of Privacy by Design Applied to Healthcare
Privacy by design, enshrined in Article 25 of the GDPR, requires data protection to be incorporated from the system's design stage. In February 2025, the CNIL published new AI-specific recommendations that reinforce this requirement for applications using artificial intelligence models.
Applied to healthcare application development, privacy by design principles translate into concrete architectural decisions:
Data minimization. Collect only what is strictly necessary for the stated purpose. If your AI diagnostic support application only needs medical imaging, it should not access the patient's entire record. You must be able to justify every field collected to the CNIL.
Storage limitation. Define retention periods for each data type and automate deletion. Medical records must be kept for 20 years after the patient's last visit (Article R.1112-7 of the French Public Health Code), but technical application logs do not need to follow that same period.
Pseudonymization by default. Separate direct identifiers—surname, first name and French national identification number (NIR)—from clinical data at the ingestion layer. Use non-reversible technical identifiers for internal processing. In its Cegedim Santé sanction, the CNIL reiterated that pseudonymization is not equivalent to anonymization—a frequently misunderstood distinction.
End-to-end encryption. Encrypt data at rest using at least AES-256, and in transit using TLS 1.3. For applications incorporating AI, encryption must also cover the data fed into models and the outputs they produce.
Environment segregation. The 2024 HDS framework requires strict separation between development, test and production environments. Real health data must never appear in development or test environments—use synthetic datasets instead.
A Typical Technical Architecture for a Compliant Healthcare Application
An architecture that meets GDPR and HDS requirements relies on several layers of protection:
| Layer | Requirement | Implementation |
|---|---|---|
| Infrastructure | HDS-certified hosting provider | Sovereign cloud (OVHcloud, Scaleway) or certified hyperscaler (Azure, AWS), with EU data residency |
| Network | Isolation and encryption | Site-to-site VPN, network segmentation, WAF, mandatory TLS 1.3 |
| Storage | Encryption at rest | AES-256, separate key management (HSM), automatic rotation |
| Application | Granular access control | RBAC/ABAC, strong authentication (MFA), comprehensive logging |
| Data | Pseudonymization | Separation of identifiers and clinical data, tokenization |
| AI / ML | Model protection | Anonymized training data, federated learning where possible |
| Backup | HDS-certified provider | Encrypted backups, regular restoration tests |
The Non-Sovereign Cloud Pitfall
Using a US cloud service to host French health data has raised major legal questions since the invalidation of Privacy Shield in the Schrems II judgment. Even though AWS, Google Cloud and Azure offer HDS-certified services with data located in Europe, the US CLOUD Act theoretically allows US authorities to access data hosted by companies governed by US law, regardless of where it is stored.
The updated 2024 HDS framework strengthens transparency on this point: hosting providers must now explicitly inform their customers of risks arising from extraterritorial legislation. For the most sensitive projects—genomic research, psychiatric data or minors' data—choosing a provider governed by European law reduces this risk.
Developing with AI While Complying with Healthcare GDPR Requirements
The CNIL's 2025 Recommendations on AI and Health Data
In February 2025, the CNIL published its finalized recommendations on developing GDPR-compliant AI systems. They cover the entire lifecycle: collecting training data, developing the model, deploying it and operating it.
Three points directly affect AI healthcare application development:
The legal basis for processing. Training an AI model on health data requires a specific legal basis. Patients' explicit consent is often required, unless the processing falls within public health research governed by a CNIL reference methodology.
The right to erasure and “unlearning.” GDPR guarantees the right to have personal data erased. Yet AI does not forget easily: training data leaves traces in a model's weights. The CNIL asks developers to document the technical procedures that make it possible to respond to an erasure request—even though machine unlearning remains a major technical challenge.
Algorithmic transparency. Patients must be informed when a decision about them is made or assisted by an AI system. Article 22 of the GDPR governs automated decisions and establishes a right to obtain human intervention.
Compliant Development Patterns for Healthcare AI
Developing a healthcare application that incorporates AI requires specific patterns that differ from standard machine learning practices.
Federated learning. Instead of centralizing patient data on a single server to train the model, federated learning sends the model to the data. Each institution trains the model locally on its own data, and only the updated parameters—not the data—are then aggregated. This pattern significantly reduces regulatory risks because health data never leaves the institution's infrastructure.
Differential privacy. This mathematical technique adds calibrated noise to data or model outputs so that it is impossible to determine whether a specific individual was part of the training dataset. Combined with federated learning, it provides formal privacy guarantees.
Synthetic data for development. Generating statistically representative synthetic datasets that contain no real patient data makes it possible to develop, test and debug without ever exposing sensitive information. Open-source tools such as Synthea for patient records, or specialized GANs, can produce these datasets.
Built-in explainability. Incorporate explainability mechanisms—SHAP, LIME and attention maps for imaging—from the model's design stage, rather than at the end of the project. GDPR requires transparency in automated decisions, and healthcare practitioners need to understand AI recommendations in order to validate them.
The HDS Certification Process: What the Project Owner Needs to Know
Choosing an HDS Hosting Provider: Selection Criteria
Your choice of HDS hosting provider determines the technical architecture, operating costs and level of compliance. More than 200 hosting providers are currently certified in France, but not all cover the framework's six activities.
Here are the criteria to assess systematically:
Certification scope. A hosting provider may be certified for one, two or all six activities. If your provider only covers physical infrastructure (certificate 1), you will need a second provider with managed hosting certification for administration and operations. Check that the certified scope matches your actual needs.
Data location. Require a contractual guarantee that data is located in France or the EU, including backups, logs and metadata.
Compliance with the updated framework. Check whether the hosting provider is already certified under the 2024 framework or is still using the previous version, with mandatory transition before May 16, 2026. Choosing a provider that has already migrated avoids having to switch providers during the project.
SLA and continuity plan. The HDS framework sets requirements for availability and disaster recovery planning. Check SLA commitments—a minimum of 99.9% for a patient care application—RPO/RTO targets and restoration test results.
Regulatory support. Some HDS hosting providers offer regulatory assistance, such as help drafting a GDPR data processing agreement or preparing compliance documentation. This service has real value when you are undertaking your first healthcare project.
The Real Costs of HDS Hosting
The additional cost of HDS hosting compared with standard cloud hosting is often underestimated in project budgets. Here is a rough estimate for a medium-sized healthcare application:
| Item | Standard cloud | HDS-certified cloud | Multiplier |
|---|---|---|---|
| Application server | €80–200/month | €300–600/month | 3–4x |
| Managed database | €100–300/month | €400–1,000/month | 3–4x |
| Outsourced backup | €50–100/month | €150–400/month | 3–4x |
| Support and managed services | €200–500/month | €500–1,500/month | 2–3x |
| Estimated monthly total | €430–1,100 | €1,350–3,500 | 3x |
These costs must be included from the budget-scoping stage. A healthcare MVP hosted in an HDS environment will cost between €15,000 and €40,000 per year for infrastructure alone, excluding development.
Building a Compliant Healthcare Project: A Step-by-Step Methodology
Phase 1 — Regulatory Scoping (Weeks 1–2)
Before any technical design work, regulatory scoping must answer four questions:
Data classification. Does the application process health data within the meaning of Article 4(15) of the GDPR? The analysis must cover direct data, combined data and data that reveals health information through its purpose.
Legal basis. What legal grounds authorize each processing activity? For a patient monitoring application, explicit consent will probably be required. For a medical decision support tool, necessity for healthcare may suffice.
CNIL formalities. Does the processing fall under a reference methodology (MR), or does it require specific authorization? The methodologies cover common cases such as health research and observational studies, but innovative processing involving AI may require an ad hoc authorization request.
HDS requirement. Is the hosting subject to HDS certification? The answer is yes as soon as a third party hosts personal health data collected during prevention, diagnosis, care or medical and social support activities.
Phase 2 — Compliant Architecture (Weeks 2–3)
The technical architecture is built on the findings of the regulatory scoping phase. The key decisions are as follows.
Choosing the HDS hosting provider. Select a certified provider covering the necessary activities, ideally already compliant with the 2024 framework.
Data separation. Design an architecture that physically separates patient identifiers, held in an encrypted vault, from clinical data, held in the application database. The join is performed only when the data is displayed, under strict access control.
Logging and traceability. Implement an immutable logging system that tracks every access, modification and export of health data. The HDS framework and the French Public Health Code require complete traceability.
Consent management. Develop a consent management module compliant with Article 7 of the GDPR: consent must be granular by purpose, revocable, documented and timestamped.
Phase 3 — Secure Development (Weeks 3–8)
Development follows secure by design principles, with practices specific to healthcare.
Strong authentication. Implement multifactor authentication (MFA) for all users accessing health data. For healthcare professionals, the French Digital Health Agency recommends using the CPS professional smart card (Carte de Professionnel de Santé) or Pro Santé Connect.
Testing with synthetic data. Never use real patient data in development or test environments. Generate realistic synthetic datasets with dedicated tools.
Continuous security review. Incorporate static and dynamic application security testing tools (SAST and DAST) into the CI/CD pipeline. Scan dependencies for known vulnerabilities (CVEs).
Integrated GDPR documentation. Keep the record of processing activities, DPIA documentation and data processing agreements up to date during every sprint, rather than at the end of the project.
Phase 4 — Validation and Production Release (Weeks 8–10)
Taking a healthcare application into production requires several specific validations.
A GDPR compliance audit checks that the DPIA is complete, consent mechanisms work, individuals' rights—access, rectification, erasure and portability—are actually implemented, and retention periods are respected.
A penetration test validates the application's technical security. For a healthcare application, this test must specifically cover scenarios involving unauthorized access to patient data, data exfiltration and access control bypasses.
The HDS verification confirms that the entire hosting chain—infrastructure, administration and backups—is covered by valid, up-to-date HDS certifications.
Costly Mistakes: Lessons from the Field
Mistake #1 — Treating Compliance as a Final Step
The most common mistake is to develop the application first and “deal with compliance later.” This approach consistently leads to extensive architectural rework. Discovering at the end of a project that the hosting provider is not HDS-certified, that the AI model was trained on data without consent, or that pseudonymization is missing can delay a launch by several months and double the budget.
Mistake #2 — Confusing Pseudonymization with Anonymization
The €800,000 fine imposed on Cegedim Santé in September 2024 illustrates this risk. The company believed it had anonymized the data, but the CNIL demonstrated that it had merely pseudonymized it—the data remained indirectly identifying. This distinction has direct consequences: pseudonymized data remains subject to GDPR, whereas truly anonymized data no longer falls within its scope.
Mistake #3 — Underestimating the Scope of HDS
HDS certification does not concern only the main server. It covers the entire chain: the physical data center, virtual infrastructure, application platform, administration, operations and backups. A project that uses an HDS-certified provider for its database but stores logs containing health data with an uncertified provider is in breach of the rules.
Mistake #4 — Overlooking Flows to Third-Party Services
Third-party APIs—notification services, analytics tools and monitoring platforms—can receive health data without the technical team realizing it. A push notification saying “Reminder: your cardiology appointment is tomorrow at 2 p.m.” constitutes health data. Every outbound flow must be audited.
Mistake #5 — Ignoring the Right to Data Portability
GDPR guarantees patients the right to retrieve their data in a structured, interoperable format. The EHDS regulation will strengthen this requirement from 2027. Designing an application that traps data in a proprietary format means accumulating technical and regulatory debt.
Preparing for the EHDS Regulation Now
What Changes for Healthcare Application Developers
The EHDS regulation entered into force on March 26, 2025, and will become applicable progressively between 2027 and 2035. Its implications for ongoing projects are significant.
Mandatory interoperability. Healthcare applications will need to exchange data according to harmonized European standards. The first priority categories—patient summaries and e-prescriptions—must be interoperable across all Member States from March 2029.
Software certification. The EHDS introduces a certification framework for publishers of medical software and digital applications, facilitating access to the European single market while imposing additional compliance requirements.
Data governance. The creation of Health Data Access Bodies (HDABs) in each Member State will structure access to health data for secondary uses such as research and innovation. Developers of applications that produce or aggregate health data will be affected.
Technical Choices to Make Today
Even though full implementation of the EHDS regulation lies in the 2029–2035 timeframe, certain technical choices made today will determine your ability to comply in the future:
- Adopt HL7 FHIR standards for structuring health data.
- Implement APIs that comply with the French Health Information Systems Interoperability Framework (CI-SIS), published by the French Digital Health Agency.
- Provide mechanisms for exporting data in standardized formats.
- Document data models using recognized medical ontologies and classifications: SNOMED CT, ICD-11 and LOINC.
FAQ
Does a startup developing a patient monitoring application have to use an HDS-certified hosting provider? Yes, if the application hosts personal health data on behalf of third parties such as patients or healthcare institutions. This obligation applies regardless of company size. Non-compliance is punishable by three years' imprisonment and a €150,000 fine under Article L.1115-1 of the French Public Health Code.
Can AWS or Azure be used to host health data in France? Yes, provided that the service used is covered by a valid HDS certification and the data is located in the EU. AWS's Paris and Frankfurt regions and Azure's France regions offer HDS-certified services. However, the updated 2024 framework requires greater transparency about risks arising from extraterritorial legislation.
What are the penalties for GDPR non-compliance in a healthcare application? CNIL penalties can reach €20 million or 4% of annual worldwide revenue. In 2024, the CNIL imposed 87 sanctions totaling €55 million. The EHDS regulation provides for equivalent penalties. Absence of HDS certification carries separate criminal penalties.
How can an AI model be trained on health data compliantly? Three approaches are compliant: obtaining patients' explicit consent, operating under a CNIL reference methodology—MR-004 for studies involving data from France's National Health Data System (SNDS)—or using truly anonymized data. Federated learning and synthetic data provide technical alternatives that limit regulatory exposure.
What is the difference between pseudonymization and anonymization under GDPR? Pseudonymized data, where identifiers have been replaced with codes but re-identification remains possible using a correspondence table, is still personal data subject to GDPR. Anonymized data, for which no re-identification is possible, even indirectly, falls outside GDPR's scope. The CNIL assesses anonymization against three criteria: singling out, linkability and inference.
Does the EHDS regulation apply to new healthcare applications from 2025? The regulation entered into force on March 26, 2025, but its application is progressive. The first concrete obligations—interoperability of patient summaries and e-prescriptions—will apply from March 2029. Planning for these requirements when designing a project launched in 2025–2026 avoids a costly overhaul in the medium term.
AI Coder Squad: Compliant Healthcare Applications, Delivered Without Compromising Timelines
Developing a healthcare application that complies with GDPR and HDS requires two capabilities that are rarely found together: mastery of secure architectures and a detailed understanding of healthcare regulation. These projects leave no room for approximation—in compliance or in time to market.
AI Coder Squad designs custom applications and AI agents for businesses that want to move fast without sacrificing quality—with senior developers and an AI-powered approach.
→ Start your project and discover how AI Coder Squad can accelerate your next development project.