Santé numériqueMis à jour -4 minutes de lecture

Naviguer dans la conformité des soins de santé dans l'UE : EHDS, NIS2, MDR et la pile réglementaire que chaque équipe informatique de santé doit comprendre

Un guide d'ingénierie axé sur la portée des exigences RGPD, NIS2, MDR/IVDR et EHDS par étapes, avec des sources primaires et des preuves pratiques pour les équipes informatiques de santé.

Ala Ben Aicha

Naviguer dans la conformité des soins de santé dans l'UE : EHDS, NIS2, MDR et la pile réglementaire que chaque équipe informatique de santé doit comprendre

Réponse directe

Pour une équipe informatique de santé, la « conformité des soins de santé dans l’UE » se compose de quatre régimes superposés, et non d’un seul certificat : le RGPD pour les données personnelles (y compris l’article 9 des données de santé), le NIS2 pour la cybersécurité des entités essentielles/importantes, le MDR/IVDR si le logiciel est un dispositif médical et l’EHDS pour l’échange transfrontalier de dossiers selon un calendrier échelonné de 2027 à 2031. Étendez le produit à chaque régime avec des liens vers la loi primaire avant d'écrire des contrôles.

Commencez par la portée, pas par une liste de contrôle technologique

Les logiciels de santé européens peuvent relever de plusieurs régimes différents. Le RGPD concerne le traitement des données personnelles ; NIS2 concerne les entités couvertes et la cybersécurité ; Les MDR et IVDR concernent les dispositifs médicaux éligibles ; L'EHDS introduit des exigences progressives en matière de données de santé et de système de DSE. Aucun de ces labels n'établit à lui seul que chaque obligation s'applique à une application particulière.

Pour un examen pratique, enregistrez d’abord l’organisation, les pays, l’utilisation prévue, les flux de données et le rôle contractuel. Attribuez ensuite à chaque obligation applicable un propriétaire, des preuves à l’appui et une date de révision. Une allégation générique « conforme à l’UE » est moins utile qu’une décision de portée traçable.

RGPD : objectif, autorisation et garanties distincts

Identifiez le fondement de l’article 6 et, pour les données sur la santé, la condition pertinente de l’article 9. Évaluez également les bénéficiaires, les modalités de rétention, d’accès et de transfert. Ni le consentement du patient ni l’hébergement dans l’UE ne constituent un raccourci universel vers la conformité. Utilisez le Texte RGPD comme point de départ.

Deux axes de travail d’ingénierie contribuent à garder cela concret :

Par exemple, une demande de correction et une exigence de conservation des enregistrements ne devraient pas entrer en concurrence via une logique de suppression non documentée. Enregistrez la décision et propagez la correction approuvée sans réécrire silencieusement l’historique clinique.

NIS2 : vérifier la portée de l'entité et la mise en œuvre nationale

La santé et l'administration publique font partie des secteurs abordés par NIS2. Cela ne fait pas de chaque prestataire de soins de santé ou organisme public une entité essentielle. Le type d’entité, sa taille, les règles d’inclusion spécifiques et la mise en œuvre nationale sont importants. Commencez par la Commission Présentation de NIS2 et l'autorité nationale compétente.

Pour une organisation potentiellement couverte, préparez un ensemble de preuves opérationnelles : propriété du système, dépendances des fournisseurs, examens des accès, escalade des incidents, exercices de récupération des sauvegardes et gestion des vulnérabilités. Fixer des délais de reporting à partir des règles applicables et de la classification des incidents ; n’utilisez pas de liste de contrôle générique comme politique de reporting. Le Manuel de l'équipe informatique NIS2 en anglais isole les horloges de l'article 23; le frère/sœur français couvre l’ANSSI et le CERT-FR.

Un exercice d'intégration utile consiste à désactiver un système en aval dans un environnement de test. Vérifiez la détection, l’escalade, la croissance de la file d’attente, la récupération et la réconciliation. Cela révèle des lacunes qu’un document politique ne peut à lui seul mettre en évidence.

MDR et IVDR : établir la finalité médicale envisagée

Une application clinique n’est pas automatiquement un dispositif médical et une étiquette IA n’attribue pas de classe de risque. Évaluez l’objectif visé et chaque module pertinent avant d’appliquer les règles de classification. Les logiciels agissant sur les données de diagnostic in vitro peuvent nécessiter une évaluation IVDR plutôt qu'un examen uniquement MDR. Consulter Conseils sur le logiciel MDCG.

Le Guide du logiciel MDR explique les branches de décision de la règle 11. Gardez les allégations sur les produits, l’analyse des dangers, les exigences et les preuves de validation alignées. Les modifications apportées à l'utilisation prévue nécessitent un examen réglementaire, même lorsque la modification du code semble mineure.

EHDS : distinguer l’entrée en vigueur de l’application

L’EHDS est entrée en vigueur en mars 2025. La Commission identifie mars 2029 et mars 2031 comme des étapes majeures d’application progressive pour différentes catégories de données prioritaires. Les exigences techniques détaillées dépendent des spécifications et des actes d'exécution applicables. Il ne s’agit pas d’une instruction générale pour déployer une API FHIR R4 aujourd’hui. Vérifiez le chronologie officielle de l'EHDS.

Tenir à jour un registre de dépendances versionné pour les formats d'échange, la terminologie, les connexions nationales et les exigences d'intégration. Le guide des échanges transfrontaliers sépare le mécanisme d’échange des décisions d’identité et d’accès.

Transformez l’évaluation en retard de livraison

Flux de travail Preuve d'ingénierie du béton Déclencheur de révision
Protection des données Cartographie des flux de données, matrice d'accès, tests de rétention et de demande de droits Nouvelle finalité, destinataire ou catégorie de données
Cybersécurité Runbook des incidents, inventaire des fournisseurs, exercice de récupération Changement d’infrastructure ou de fournisseur
Évaluation des dispositifs médicaux Déclaration d'utilisation prévue, analyse des risques, traçabilité de validation Modification de l’objectif médical ou de la logique décisionnelle
Interopérabilité transfrontalière Versions de profil, mappages terminologiques, résultats de conformité Nouveau service ou connexion nationale

Ces lignes constituent une aide à la planification technique et non une détermination de l'applicabilité juridique. Pour les fonctionnalités d’IA ou les règles du système de santé spécifiques à un pays, ajoutez une évaluation distincte avant la mise en œuvre plutôt que de supposer que les quatre lignes couvrent tout.

Une prochaine étape pratique

Choisissez un flux de travail critique (par exemple, une commande qui devient un rapport de diagnostic corrigé) et suivez-le de bout en bout. Identifiez chaque système, équipe responsable, décision d’accès et chemin d’échec. Reliez le résultat à l’évaluation juridique et aux tests d’acceptation pertinents. Si vous avez besoin d'aide pour la mise en œuvre, consultez services d'interopérabilité numérique en matière de santé.

Conformité UEEHDSNIS2EU MDRIVDRLoi européenne sur l’IAGDPRRéglementation des soins de santéSanté numériqueCybersécurité

Lectures et services associés

Poursuivons la conversation

Vous avez des questions sur ce sujet ? J'aimerais avoir de vos nouvelles.