+150 XP

Cartographier le paysage réglementaire de l'IA hospitalière

Un outil de prédiction du sepsis signale le patient du lit 12 comme à haut risque. Cette seule alerte vient de toucher quatre régimes réglementaires différents. La FDA s'intéresse à savoir si l'algorithme est un dispositif médical autorisé. HIPAA s'intéresse à la façon dont les données du patient ont circulé pour l'entraîner et le faire tourner. Les règles de transparence de l'ONC s'intéressent à la capacité du clinicien de voir comment le score a été construit. Et la Joint Commission s'intéresse à la façon dont votre hôpital a gouverné l'ensemble.

Personne ne vous remet une carte indiquant quelle règle s'applique à quelle partie. Cette leçon la dessine.

Les quatre régimes en un coup d'œil

Imaginez quatre cercles qui se recoupent, chacun sous la responsabilité d'une instance différente.

  • FDA (Food and Drug Administration) : régule le logiciel lui-même lorsqu'il se qualifie comme dispositif médical.
  • HHS Office for Civil Rights : applique HIPAA (Health Insurance Portability and Accountability Act), les règles de confidentialité et de sécurité des données patients.
  • ONC (Office of the National Coordinator for Health IT) : fixe les exigences de transparence algorithmique au sein des logiciels de dossier patient informatisé (EHR) certifiés.
  • La Joint Commission : le principal organisme d'accréditation hospitalière. Ce n'est pas une agence gouvernementale, mais perdre son accréditation peut mettre fin aux paiements Medicare, donc les hôpitaux la considèrent comme contraignante.

Ils se recoupent. Un seul déploiement peut déclencher les quatre. Toute l'astuce consiste à savoir quel déclencheur s'active et quand.

FDA : votre outil sepsis est-il un dispositif régulé ?

Le domaine de la FDA, c'est le SaMD (Software as a Medical Device) : un logiciel qui remplit une fonction médicale sans faire partie d'un dispositif matériel.

La question clé : le logiciel diagnostique-t-il, traite-t-il ou pilote-t-il une décision clinique ? Un modèle de sepsis qui produit un score de risque pour orienter le traitement est très probablement un SaMD. Un outil qui se contente de résumer des notes existantes du dossier pour lecture par un clinicien, peut-être pas.

La plupart des outils cliniques prédictifs obtiennent leur autorisation FDA via la voie 510(k), qui démontre que le dispositif est « substantiellement équivalent » à un dispositif déjà commercialisé. Les outils à risque plus élevé peuvent nécessiter les voies plus strictes De Novo ou PMA (Premarket Approval).

Deux pièges pour les hôpitaux :

  1. Les modèles développés en interne. Si votre équipe data science construit un modèle de sepsis en interne et ne l'utilise qu'au sein de votre propre hôpital, la FDA a historiquement exercé son enforcement discretion, c'est-à-dire qu'elle n'exige souvent pas d'autorisation. Achetez la même capacité auprès d'un éditeur et il faut généralement une autorisation. Mêmes calculs, règle différente, parce que le déclencheur est la distribution commerciale.
  1. Le modèle qui continue d'apprendre. L'autorisation traditionnelle suppose un algorithme figé. Pour les modèles qui évoluent dans le temps, la FDA a introduit le Predetermined Change Control Plan (PCCP) : vous déclarez à l'avance ce que le modèle est autorisé à modifier et comment vous le validerez, de sorte que le réentraînement n'exige pas un nouveau dossier chaque fois.

Vous pouvez consulter les dispositifs d'IA autorisés dans la liste publique de la FDA des dispositifs médicaux dotés d'IA.

HIPAA : les données en dessous

HIPAA ne se soucie pas de savoir si votre modèle est ingénieux. Elle se soucie des PHI (Protected Health Information) : les données patients identifiables.

Là où HIPAA mord dans un projet d'IA :

  • Les données d'entraînement. Utiliser de vrais dossiers patients pour entraîner le modèle de sepsis constitue un « usage » de PHI. Cela doit relever du soin, du paiement, des opérations, ou être dé-identifié (dépouillé des 18 identifiants HIPAA tels que le nom, les dates, le numéro de dossier médical).
  • Les fournisseurs. Si un fournisseur touche des PHI, il vous faut un Business Associate Agreement (BAA) : un contrat qui le rend responsable de la protection des données. Pas de BAA, pas de partage de données. Point final.
  • L'inférence dans le cloud. Envoyer les constantes du lit 12 à une API cloud pour scoring est une transmission de PHI. Cela exige du chiffrement et un BAA avec le fournisseur cloud.

Un échec courant : un data scientist injecte des dossiers en temps réel dans un grand modèle de langage généraliste sans BAA pour « tester une idée ». C'est une violation déclarable en attente de se produire.

ONC : la transparence à l'intérieur de l'EHR

L'ONC régule les technologies de santé certifiées, c'est-à-dire les logiciels d'EHR (Epic, Oracle Health et d'autres) dont les hôpitaux dépendent pour les programmes Medicare et Medicaid.

En vertu de la règle HTI-1 (Health Data, Technology, and Interoperability, finalisée en 2024), les EHR certifiés qui affichent des predictive decision support interventions (DSI), c'est-à-dire des recommandations issues d'IA ou d'algorithmes, doivent exposer un ensemble de « source attributes ». En clair, le clinicien (ou l'hôpital) doit pouvoir consulter une sorte d'étiquette nutritionnelle de l'algorithme :

  • Sur quelles données il a été entraîné.
  • Quel résultat il prédit.
  • Comment ses performances ont été validées.
  • Les limites connues et les considérations d'équité.

Donc si votre score de sepsis apparaît dans Epic, HTI-1 gouverne la possibilité pour les utilisateurs d'afficher cette étiquette. Il s'agit de transparence, pas d'approbation. L'ONC ne dit pas que le modèle est bon. Il dit que vous devez pouvoir voir ce qu'il est.

Joint Commission : gouverner le déploiement

La Joint Commission accrédite les hôpitaux et, depuis 2025, a publié des recommandations sur l'usage responsable de l'IA pour les organisations de santé. Son objet n'est pas l'algorithme, c'est votre processus autour de lui :

  • Avez-vous une supervision de gouvernance des outils d'IA ?
  • Surveillez-vous le modèle après la mise en production pour détecter le drift et les biais ?
  • Le personnel sait-il quand une recommandation provient d'une IA ?
  • Existe-t-il un moyen de signaler les événements de sécurité liés à l'IA et d'y donner suite ?

C'est là que les trois autres régimes deviennent opérationnels. La FDA autorise l'outil, HIPAA protège les données, l'ONC expose l'étiquette, et la Joint Commission vérifie que votre hôpital fait effectivement tourner les garde-fous.

Appliqué à un seul outil

Voici le modèle de sepsis, cartographié :

RégimeCe qu'il gouverneDéclencheur
FDAL'algorithme en tant que dispositifVendu par un éditeur, pilote des décisions cliniques
HIPAALes données patients utilisées et déplacéesTout usage de PHI identifiables
ONC HTI-1L'étiquette de transparence dans l'EHRAffiché via une technologie de santé certifiée
Joint CommissionGouvernance et monitoring hospitaliersToute IA utilisée dans des opérations accréditées

À noter : un modèle interne qui contourne l'EHR peut échapper à l'autorisation FDA et à l'étiquetage ONC, mais il reste soumis à HIPAA et à la Joint Commission. Les régimes se recoupent, ils ne se substituent pas.

Une checklist minimale avant déploiement, en pseudo-code :

for tool in ai_deployments:
    if tool.drives_clinical_decision and tool.is_vendor_supplied:
        require FDA_clearance(pathway in [510k, DeNovo, PMA])
    if tool.uses_PHI:
        require de_identification OR (BAA_signed and encryption_enabled)
    if tool.surfaced_in_certified_EHR:
        require HTI1_source_attributes_available
    require JointCommission.governance(monitoring, bias_check, staff_disclosure)

Vérification des acquis

1. Un hôpital déploie un outil qui se contente de compiler et de résumer des notes existantes du dossier pour lecture par un clinicien, sans produire de scores de risque ni d'orientation thérapeutique. Pourquoi cet outil est-il moins susceptible d'être régulé comme SaMD par la FDA ?

2. La leçon note que la Joint Commission « n'est pas une agence gouvernementale, mais les hôpitaux la considèrent comme contraignante ». Quelle est la meilleure explication de cette contradiction apparente ?

3. Une seule alerte de prédiction du sepsis peut impliquer quatre régimes réglementaires à la fois. Quel est le point conceptuel central que fait la leçon à propos de ces régimes ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses. Quelles préoccupations réglementaires seraient déclenchées par un modèle de sepsis qui produit un score de risque à l'intérieur d'un EHR certifié en utilisant des données patients ?

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses. Quelles affirmations décrivent correctement le rôle de la FDA et la voie 510(k) telles que présentées dans la leçon ?

Sélectionnez toutes les réponses correctes.

Là où les équipes trébuchent vraiment

« Ce n'est que de l'aide à la décision, donc la FDA ne s'applique pas. » Parfois vrai, mais si l'outil influence le traitement et provient d'un éditeur, partez du principe qu'il s'agit d'un SaMD jusqu'à preuve du contraire. Le libellé de l'usage prévu dans votre marketing compte autant que le code.

« Nous avons dé-identifié, donc HIPAA est réglé. » La dé-identification doit satisfaire au standard HIPAA (suppression Safe Harbor des 18 identifiants, ou Expert Determination). Retirer seulement le nom du patient ne suffit pas.

« Le fournisseur a une autorisation FDA, donc nous sommes couverts. » L'autorisation couvre le dispositif. Elle ne couvre pas votre monitoring, votre BAA ni votre transparence dans l'EHR. Ceux-là vous appartiennent.

« HTI-1 signifie que le modèle est approuvé. » Non. La transparence ONC porte sur la visibilité, pas sur l'aval. Un modèle qui performe mal peut tout à fait afficher son étiquette.

L'Europe en une ligne

Pour les lecteurs qui déploient de l'autre côté de l'Atlantique : l'EU AI Act (en vigueur depuis 2024, avec des obligations qui entrent progressivement en application jusqu'en 2026 et 2027) classe la plupart des IA cliniques comme à haut risque, superposant une évaluation de conformité aux règles existantes du MDR (Medical Device Regulation). La structure diffère, mais l'intuition est la même : prouver que l'outil est sûr, garder les données licites, et gouverner le déploiement.

Points clés

  • Un outil, quatre régimes. Un modèle de sepsis peut déclencher simultanément la FDA (dispositif), HIPAA (données), l'ONC (transparence) et la Joint Commission (gouvernance). Cartographiez chacun avant la mise en production.
  • Le déclencheur FDA, c'est l'usage prévu plus la distribution. Les outils vendus par un éditeur qui pilotent des décisions cliniques nécessitent généralement une autorisation ; certains outils internes bénéficient de l'enforcement discretion, mais ce n'est pas une permission de faire l'économie de la gouvernance.
  • HIPAA suit les données partout. Entraînement, partage avec les fournisseurs et inférence dans le cloud exigent tous une dé-identification ou un BAA signé avec chiffrement.
  • ONC HTI-1 est une étiquette, pas une approbation. Assurez-vous que les source attributes du modèle sont visibles au sein des EHR certifiés.
  • La Joint Commission relie le tout. Le monitoring post-déploiement, les contrôles de biais et l'information du personnel sont votre responsabilité, peu importe qui a construit le modèle.