Réponse courte : les logiciels qui manipulent des données de santé répondent à quatre familles de règles à la fois. La protection des données indique ce que vous pouvez faire avec les données de santé personnelles : l'article 9 du RGPD dans l'UE, la HIPAA et un ensemble de lois étatiques aux États-Unis. Les règles du système de santé indiquent comment les données doivent circuler et être partagées : l'Espace européen des données de santé (EEDS) dans l'UE, le TEFCA, l'USCDI et les règles sur le blocage de l'information aux États-Unis. La sécurité des produits s'applique lorsque le logiciel a une fonction médicale : le Règlement sur les dispositifs médicaux (RDM) et le Règlement sur les dispositifs de diagnostic in vitro (RDIV) dans l'UE, les règles de la FDA aux États-Unis, avec les normes d'ingénierie et de qualité IEC 62304 et ISO 13485 en arrière-plan. La sécurité établit la base que tout le monde doit respecter : ISO 27001 et 27799, NIS2 pour les secteurs critiques, la Règle de sécurité HIPAA. L'identité (eIDAS et le portefeuille européen d'identité numérique, connexion NHS, cartes d'identité nationales) traverse les quatre.
La carte
La carte de la réglementation des données de santé regroupe les règles applicables aux logiciels manipulant des données de santé par familles : protection des données (RGPD Article 9, HIPAA, lois des États américains), règles du système de santé (EHDS, Cures Act, TEFCA), sécurité des produits (MDR, IVDR, FDA), normes d'ingénierie et de qualité (IEC 62304, ISO 13485), sécurité (ISO 27001, ISO 27799, NIS2, HIPAA Security Rule) et identité (eIDAS 2).
| Famille | Règle | S'applique à | Ce qu'elle demande |
|---|---|---|---|
| Protection des données | RGPD, Art. 9 et Art. 35 | Toute personne traitant des données de santé de résidents de l'UE | Une base légale de l'Art. 9(2), une analyse d'impact relative à la protection des données (AIPD), un délégué à la protection des données (DPD) pour le traitement à grande échelle, des droits, une notification de violation sous 72h |
| Protection des données | HIPAA (Règles de confidentialité, de sécurité, de violation) | Entités couvertes par la HIPAA aux États-Unis et leurs associés commerciaux | Utilisations autorisées, garanties, notification de violation ; ne couvre pas la plupart des applications grand public |
| Protection des données | Lois des États américains (CCPA/CPRA, Washington My Health My Data…) | Entreprises manipulant les données des résidents | Consentement pour les données de santé des consommateurs, droits de suppression, restrictions de vente |
| Système de santé | EEDS, Règlement (UE) 2025/327 | Systèmes de dossiers médicaux électroniques (DME), applications de bien-être prétendant à l'interopérabilité, détenteurs de données, organismes d'accès aux données de santé | Accès et portabilité des patients au format d'échange européen, MyHealth@EU obligatoire, permis d'utilisation secondaire |
| Système de santé | 21st Century Cures Act, règles HTI de l'ONC, TEFCA | Technologies de santé certifiées aux États-Unis, prestataires, réseaux | API FHIR, données USCDI, pas de blocage de l'information, échange à l'échelle nationale |
| Sécurité des produits | RDM 2017/745, RDIV 2017/746 | Logiciels à usage médical pour les patients de l'UE | Classification, évaluation de la conformité, évaluation clinique, surveillance post-commercialisation, marquage CE |
| Sécurité des produits | FDA (21 CFR 820/QMSR, 510(k), De Novo, PMA) | Logiciels en tant que dispositif médical pour les États-Unis | Voie de pré-commercialisation par classe, système qualité, documentation cybersécurité |
| Ingénierie | IEC 62304, IEC 82304-1, ISO 14971 | Équipes de développement de logiciels de dispositifs médicaux | Cycle de vie du logiciel par classe de sécurité, gestion des risques |
| Qualité | ISO 13485 | Fabricants de dispositifs | Un système de management de la qualité couvrant la conception, la production, les plaintes |
| Sécurité | ISO/IEC 27001, ISO 27799, ISO 27701 | Toute organisation ; conseils spécifiques à la santé | Un système de management de la sécurité de l'information, contrôles de santé, extension de la confidentialité |
| Sécurité | NIS2, Directive 2022/2555 | Prestataires de soins de santé, fabricants de dispositifs, fournisseurs de cloud et numériques dépassant certains seuils de taille | Mesures de risque, notification d'incident sous 24/72h, responsabilité de la direction |
| Sécurité | Règle de sécurité HIPAA | Entités couvertes par la HIPAA aux États-Unis et associés commerciaux | Garanties administratives, physiques et techniques ; analyse des risques |
| Identité | eIDAS 2 et le portefeuille européen d'identité numérique | Services qui vérifient l'identité des citoyens de l'UE | Acceptation du portefeuille pour une identification forte à partir de 2026-2027 |
Qui est concerné par quoi
Les règles de données de santé qui s'appliquent dépendent de ce que fait le logiciel. Une application grand public sans allégations médicales relève du RGPD Article 9, d'une analyse d'impact relative à la protection des données (AIPD) et de pratiques de sécurité ; l'ajout d'interprétation en fait un dispositif médical sous le MDR ; une plateforme FHIR est un sous-traitant RGPD et parfois sous NIS2 ; un hôpital couvre tout cela, plus NIS2 en tant qu'entité essentielle.
- Une application de santé grand public sans prétention médicale (un journal de symptômes, un enregistrement de rapports de laboratoire) : RGPD Article 9 avec consentement explicite, une AIPD, une pratique de sécurité au niveau ISO 27001, et l'étiquette d'application de bien-être de l'EEDS si elle prétend se connecter aux systèmes de DME. Pas un dispositif médical, tant que son objectif reste non médical. Aux États-Unis : règles de la FTC et lois étatiques sur la confidentialité de la santé plutôt que la HIPAA.
- La même application avec une fonction d'interprétation ("votre résultat suggère...") : un dispositif médical selon la Règle 11 du RDM, généralement de classe IIa, avec IEC 62304 et ISO 13485 en arrière-plan. Voir Une application de santé est-elle un dispositif médical ? et Classes de SaMD.
- Un fournisseur de plateforme ou d'intégration FHIR : RGPD en tant que sous-traitant (contrats Article 28), ISO 27001, potentiellement NIS2 en tant que fournisseur d'infrastructure numérique ou de services TIC, obligations de l'EEDS lorsqu'il fait partie d'un système de DME, HIPAA en tant qu'associé commercial aux États-Unis.
- Un hôpital : tout ce qui précède en tant que responsable du traitement et opérateur, plus NIS2 en tant qu'entité essentielle, lois nationales sur les dossiers de santé, et les délais de l'EEDS pour la connexion à l'infrastructure nationale.
- Une plateforme de recherche : RGPD Article 9(2)(j) et Article 89, le chapitre sur l'utilisation secondaire de l'EEDS (autorisations d'un organisme d'accès aux données de santé, environnements de traitement sécurisés), et normes d'anonymisation. Voir Utilisation secondaire des données de santé.
Dans quel ordre
La conformité des données de santé est mieux abordée dans un ordre défini : rédigez d'abord l'intention d'utilisation, car elle détermine si le logiciel est un dispositif médical ; puis la protection des données (base légale, AIPD, contrats de sous-traitance) ; ensuite une base de sécurité conforme à la norme ISO 27001 ; puis les mandats d'interopérabilité tels que FHIR et EHDS ou USCDI ; puis le parcours du dispositif, le cas échéant ; enfin les questions transfrontalières.
- Décider de l'objectif visé par écrit. Il détermine si vous êtes un dispositif médical, et tout le reste en découle.
- La protection des données d'abord : base légale, AIPD, contrats de sous-traitance, DPD. Ceux-ci sont nécessaires avant le premier utilisateur réel, dans tous les scénarios. Voir RGPD Article 9 pour les données de santé et AIPD pour une application de santé.
- Base de sécurité : un SMSI conforme à ISO 27001, aligné sur les contrôles de santé de 27799 ; cela répond également à la plupart des exigences de NIS2 et de la Règle de sécurité HIPAA. Voir ISO 27001 vs ISO 27799 et NIS2 pour les hôpitaux et les fournisseurs.
- Mandats d'interopérabilité : FHIR et le format d'échange de votre marché (EEDS, USCDI/US Core) afin que le produit ne soit pas exclu de l'infrastructure nationale. Voir USCDI expliqué et TEFCA expliqué.
- Voie du dispositif, le cas échéant : classification, système qualité, cycle de vie, organisme notifié ou voie FDA. Prévoir un an.
- Transfrontalier : différences HIPAA vs RGPD lors de la desserte des deux marchés (HIPAA vs RGPD), mécanismes de transfert, lieu d'hébergement.
Où se situe Anpheros
Anpheros Daily est un dossier de santé personnel avec un objectif déclaré non médical : il stocke, affiche et partage, et n'interprète ni ne recommande. Anpheros Platform est un backend FHIR R4 proposé aux cliniques et aux développeurs en tant que sous-traitant selon l'article 28 du RGPD, avec consentement et journaux d'accès contrôlés par le patient. Les pages de réglementation de ce cluster décrivent les règles telles qu'elles s'appliquent à tout produit de ce type ; la page de transparence décrit comment Anpheros les applique à lui-même.
Cette page explique la réglementation pour les équipes produit et ingénierie. Il ne s'agit pas d'un avis juridique ; les textes liés sous Sources font autorité, et votre délégué à la protection des données, organisme notifié ou conseiller décide pour votre cas. Dernière révision : octobre 2026.
Pages associées
- Une application de santé est-elle un dispositif médical ? RDM UE Règle 11
- Vos données médicales dans l'UE : RGPD, EEDS et vos droits
- RGPD Article 9 pour les données de santé
- AIPD pour une application de santé
- HIPAA vs RGPD
- NIS2 pour les hôpitaux et les fournisseurs de technologies de la santé
- Normes d'interopérabilité des soins de santé : la carte
- RGPD pour les développeurs (site développeurs)
- Dossiers médicaux électroniques nationaux en Europe et aux États-Unis
- MyHealth@EU et le résumé de patient transfrontalier
- Le règlement européen sur l'IA et l'IA dans la santé
- Utilisation secondaire des données de santé
- Sécurité et identité dans les applications de santé
Sources
- Règlement (UE) 2016/679 (RGPD), EUR-Lex
- Règlement (UE) 2025/327 (Espace européen des données de santé), EUR-Lex
- Règlement (UE) 2017/745 (RDM), EUR-Lex
- Règlement (UE) 2017/746 (RDIV), EUR-Lex
- Directive (UE) 2022/2555 (NIS2), EUR-Lex
- HHS : HIPAA pour les professionnels
- ASTP/ONC : Trusted Exchange Framework and Common Agreement
- ISO/IEC 27001:2022
Questions fréquentes
Le RGPD s'applique-t-il à une entreprise américaine ayant des utilisateurs européens ?
Oui, en vertu de l'article 3(2), dès qu'elle propose des services à des personnes dans l'UE ou surveille leur comportement, indépendamment de l'emplacement des serveurs. Elle a alors besoin d'un représentant dans l'UE, d'une base légale en vertu de l'article 9 et d'un mécanisme de transfert licite.
La HIPAA est-elle plus stricte que le RGPD ?
Ni l'une ni l'autre n'est strictement plus stricte. La HIPAA a une portée plus restreinte (uniquement les entités couvertes et les associés commerciaux) et est plus prescriptive sur les garanties ; le RGPD est plus large (toute personne traitant des données de résidents de l'UE), basé sur les droits et exige une base légale pour chaque utilisation. Un produit desservant les deux marchés doit satisfaire aux deux.
L'EEDS remplace-t-il le RGPD pour les données de santé ?
Non. L'EEDS s'appuie sur le RGPD et ajoute des obligations pour les systèmes de DME, l'accès des patients, l'échange transfrontalier et l'utilisation secondaire. Le RGPD reste la base de toute opération de traitement.
Par où commencer si je n'ai pas d'équipe de conformité ?
Rédigez l'objectif visé, effectuez une AIPD avec un modèle, adoptez une base de sécurité de type ISO 27001, et utilisez FHIR avec les profils de votre marché. Ces quatre étapes couvrent la plupart des points qu'un premier audit ou un premier client hospitalier demandera.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →