Le numérique transforme le secteur de la santé à grande vitesse : téléconsultation, suivi patient à distance, dossiers médicaux partagés, objets connectés… Mais développer une application qui manipule des données de santé, ce n’est pas comme lancer une app classique. Le cadre réglementaire est strict, et à juste titre : il protège les informations les plus sensibles de vos utilisateurs.
Que vous soyez fondateur d’une startup e-santé, directeur d’établissement ou DSI, ce guide vous donne les clés pour comprendre vos obligations et structurer votre projet en toute conformité.
L’hébergement de données de santé (HDS) : une obligation légale
En France, toute structure qui héberge des données de santé à caractère personnel pour le compte d’un tiers doit être certifiée HDS (Hébergeur de Données de Santé). Ce n’est pas une recommandation — c’est une obligation inscrite dans le Code de la santé publique (article L.1111-8).
Ce que cela implique concrètement
- Vous ne pouvez pas héberger des données de santé sur n’importe quel serveur. Un hébergement cloud classique (même performant) ne suffit pas s’il n’est pas certifié HDS.
- La certification couvre deux périmètres : l’hébergeur d’infrastructure physique et l’hébergeur infogéreur. Selon votre architecture, vous pouvez avoir besoin de l’un, de l’autre, ou des deux.
- Les principaux hébergeurs certifiés HDS en France incluent OVHcloud, Scaleway, Azure (régions françaises), AWS (sous conditions), et des acteurs spécialisés comme Cegedim ou Claranet.
Avant de choisir votre hébergeur, vérifiez la validité de sa certification sur le site de l’ANS (Agence du Numérique en Santé) et assurez-vous que le périmètre certifié couvre bien votre cas d’usage.
Les erreurs fréquentes
Beaucoup de porteurs de projet découvrent l’obligation HDS tardivement, ce qui entraîne des migrations coûteuses. Intégrez ce paramètre dès la phase de conception technique.
Le RGPD dans le contexte santé : un régime renforcé
Le RGPD s’applique à toutes les données personnelles, mais les données de santé bénéficient d’un statut particulier. Elles font partie des données sensibles (article 9 du RGPD), dont le traitement est par défaut interdit, sauf exceptions strictement encadrées.
Les points clés à maîtriser
- Le consentement explicite est généralement requis pour traiter des données de santé. Il doit être libre, spécifique, éclairé et univoque. Un simple bandeau cookie ne suffit pas.
- La nomination d’un DPO (Délégué à la Protection des Données) est fortement recommandée, voire obligatoire si vous traitez des données de santé à grande échelle.
- L’analyse d’impact (AIPD) est obligatoire pour tout traitement susceptible d’engendrer un risque élevé pour les droits des personnes. Dans la santé, c’est quasi systématique.
- La durée de conservation des données doit être définie et justifiée. Les données médicales suivent des règles spécifiques (souvent 20 ans pour un dossier médical).
Le RGPD dans la santé n’est pas qu’un sujet juridique. Il influence directement l’architecture technique de votre application : cloisonnement des données, gestion fine des droits d’accès, pseudonymisation.
Relation avec le patient
Le patient doit pouvoir exercer ses droits facilement : accès, rectification, suppression, portabilité. Votre application doit prévoir ces fonctionnalités dès la conception — c’est le principe du privacy by design.
Interopérabilité : les normes HL7 et FHIR
Une application santé ne fonctionne jamais en silo. Elle doit communiquer avec d’autres systèmes : logiciels de gestion hospitalière, laboratoires, DMP (Dossier Médical Partagé), plateformes de télémédecine…
Les standards à connaître
- HL7 (Health Level 7) est le standard historique d’échange de données de santé. Il définit les formats de messages entre systèmes.
- FHIR (Fast Healthcare Interoperability Resources) est la norme moderne, basée sur les API REST et le format JSON. Elle est de plus en plus exigée par les institutions.
- Le CI-SIS (Cadre d’Interopérabilité des Systèmes d’Information de Santé), défini par l’ANS, précise les standards à respecter en France.
Si vous développez une application qui s’intègre dans l’écosystème de santé français, la conformité au CI-SIS et l’adoption de FHIR ne sont pas optionnelles — elles conditionnent votre capacité à être référencé et à vous connecter aux services publics de santé.
Sécurité : les bonnes pratiques incontournables
Au-delà des obligations réglementaires, la sécurité des données de santé exige des mesures techniques robustes. Une faille peut avoir des conséquences graves, tant pour les patients que pour votre responsabilité juridique.
Les mesures essentielles
- Chiffrement des données : au repos (AES-256) et en transit (TLS 1.2 minimum). Les données de santé ne doivent jamais circuler ou être stockées en clair.
- Authentification forte : double facteur (2FA) pour les professionnels de santé, voire utilisation de la carte CPS (Carte de Professionnel de Santé) ou de Pro Santé Connect.
- Gestion des accès : appliquez le principe du moindre privilège. Chaque utilisateur ne doit accéder qu’aux données strictement nécessaires à sa fonction.
- Journalisation des accès : chaque consultation ou modification de donnée doit être tracée avec horodatage et identifiant de l’utilisateur. Ces logs doivent être conservés et protégés contre toute altération.
- Tests d’intrusion réguliers : faites auditer votre application par des experts en sécurité au moins une fois par an, et après chaque évolution majeure.
La sécurité n’est pas une couche qu’on ajoute après coup. Elle se pense dès l’architecture, se teste en continu, et s’adapte aux menaces actuelles.
Structurer un projet santé conforme dès le départ
La conformité réglementaire ne doit pas être un frein à l’innovation — mais elle doit être intégrée dès les premières étapes du projet. Voici une approche pragmatique :
- Phase de cadrage : identifiez les données traitées, leur nature (données de santé ou non), et les flux de données. Consultez un juriste spécialisé en droit de la santé numérique.
- Choix de l’hébergement : sélectionnez un hébergeur certifié HDS avant de poser la première ligne de code. Ce choix influence l’architecture technique.
- Privacy by design : intégrez le RGPD dans les spécifications fonctionnelles. Consentement, droits des patients, durées de conservation — tout doit être pensé en amont.
- Architecture sécurisée : chiffrement, authentification forte, cloisonnement des données, journalisation. Documentez vos choix techniques.
- Interopérabilité : si votre application doit s’intégrer dans l’écosystème de santé, adoptez FHIR et respectez le CI-SIS dès la conception.
- Audits et amélioration continue : planifiez des audits de sécurité, des revues de conformité RGPD, et une veille réglementaire active.
Un projet santé bien structuré dès le départ évite les refontes coûteuses et accélère la mise sur le marché. La conformité devient un avantage concurrentiel, pas un obstacle.
Vous avez un projet santé ? Parlons-en.
Développer une application santé conforme demande une expertise technique et réglementaire pointue. Chez Shortcut, nous accompagnons les acteurs de la santé — startups, établissements, industriels — dans la conception et le développement d’applications qui respectent les plus hauts standards de conformité.
Découvrez notre expertise santé ou contactez-nous pour discuter de votre projet. Nous vous aiderons à transformer vos contraintes réglementaires en fondations solides pour votre application.