Réponse courte : L'IA sur les données médicales est un processus en sept questions, et la plupart des échecs proviennent du fait d'en sauter une. D'où viennent les données (un dossier FHIR, des documents, des appareils, les mots du patient) ? Comment le modèle y accède-t-il (une API de contexte qui assemble ce qui est pertinent, un serveur Model Context Protocol, une récupération sur le dossier) ? Qui a décidé que c'était permis (le consentement du patient, limité par l'objectif et la durée, enregistré) ? Qu'est-ce qui protège les personnes qui y figurent (la dé-identification pour tout ce qui quitte le contexte de soins, des données synthétiques pour le développement, la pseudonymisation pour la recherche) ? Chaque résultat peut-il être tracé (provenance des entrées et des sorties) ? Comment savons-nous que cela fonctionne (évaluation par rapport à la vérité clinique, pas à l'intuition) ? Quelles règles s'appliquent (RGPD articles 9 et 22, le MDR si le résultat éclaire des décisions cliniques, le règlement européen sur l'IA, HIPAA) ? Cette page est la carte ; chaque question a sa propre page.
Le pipeline
Le pipeline de l'IA sur les données médicales comporte sept étapes, chacune avec une question : source (d'où proviennent les données), accès (comment le modèle y accède), contrôle (qui a décidé que c'était possible), confidentialité (qu'est-ce qui protège les personnes concernées), traçabilité (si les résultats peuvent être retracés), évaluation (comment le succès est mesuré) et règles (quelles lois s'appliquent).
| Étape | Question | Ce qui est bien | Page |
|---|---|---|---|
| Source | D'où viennent les données ? | Un dossier FHIR avec des codes (LOINC, SNOMED CT, ATC), des documents avec structure extraite, des données d'appareil avec provenance ; pas seulement des captures d'écran et des PDF | FHIR Observation, FHIR DiagnosticReport |
| Accès | Comment le modèle y accède-t-il ? | Une API de contexte ou un serveur MCP qui renvoie une tranche délimitée et étiquetée par provenance du dossier ; récupération avec des filtres structurés, pas un déversement | RAG sur les dossiers médicaux, API de santé pour l'IA, Serveur MCP |
| Contrôle | Qui a décidé que c'était permis ? | Consentement du patient par objectif et durée ; périmètres appliqués côté serveur ; un journal d'accès que le patient consulte ; révocation qui fonctionne | Plateforme de consentement du patient, Qui a consulté mon dossier ? |
| Confidentialité | Qu'est-ce qui protège les personnes ? | Les données identifiées restent dans le contexte de soins ; données dé-identifiées ou synthétiques pour le développement, l'analyse et la formation de modèles ; données pseudonymisées pour la recherche sous permis | Dé-identification, Données patient synthétiques |
| Traçabilité | Les résultats peuvent-ils être tracés ? | Provenance sur chaque entrée (qui l'a enregistrée, quand, d'où) et sur chaque résultat d'IA (modèle, version, entrées utilisées), stockée avec le dossier | Provenance des données médicales |
| Évaluation | Comment savons-nous que cela fonctionne ? | Ensembles de test avec vérité clinique, fidélité aux sources, analyse des erreurs par sous-groupe, surveillance en production, parcours de revue humaine | Évaluation des LLM cliniques |
| Règles | Quelles lois s'appliquent ? | RGPD articles 9 et 22, analyse d'impact relative à la protection des données ; MDR si le résultat éclaire le diagnostic ou le traitement ; le régime de haut risque du règlement sur l'IA pour les dispositifs et les usages listés ; HIPAA aux États-Unis | Le règlement européen sur l'IA et l'IA en santé, Classes de SaMD, RGPD Article 9 |
Trois types d'IA, trois profils de risque
L'IA sur les données médicales se présente en trois types avec trois profils de risque : l'IA d'assistance et administrative, comme les résumés en langage clair et les notes rédigées, où le risque concerne la confidentialité et les erreurs non détectées ; le soutien à la décision, comme le signalement d'interactions ou le triage, où le risque est clinique et le MDR s'applique ; et l'IA pour les populations et la recherche, où les risques sont la ré-identification et les biais.
Assistive et administrative : résumé d'un dossier pour le patient en langage clair, rédaction d'une note de visite à partir d'une transcription pour le clinicien à modifier, réponse à "où est mon dernier bilan sanguin" sur un dossier consenti. Le risque réside dans la confidentialité et dans les erreurs qu'un humain pourrait ne pas détecter ; le MDR ne s'applique pas tant qu'aucune décision clinique n'est éclairée, mais les obligations de transparence du règlement sur l'IA et le RGPD s'appliquent.
Aide à la décision : signalement d'une interaction, suggestion d'un diagnostic différentiel, triage. Le risque est clinique ; le MDR s'applique (généralement classe IIa ou supérieure), le régime de haut risque du règlement sur l'IA suit, et les normes IEC 62304 et l'évaluation clinique sont requises. Voir CDS Hooks expliqué pour savoir comment ces systèmes se connectent à un EHR.
Population et recherche : recherche de schémas dans de nombreux dossiers, signaux de pharmacovigilance, découverte de cohortes. Le risque est la ré-identification et les biais ; les données doivent être anonymisées ou pseudonymisées sous permis, agrégées avec des tailles de cellules minimales, et les méthodes évaluées pour les facteurs de confusion. Voir Utilisation secondaire des données de santé.
Les modes d'échec
Les modes d'échec courants de l'IA sur les données médicales sont l'insertion d'un dossier entier dans une requête, l'injection de requête via des documents, l'inférence silencieuse qui inscrit la supposition d'un modèle dans le dossier comme si un clinicien l'avait fait, l'entraînement sur des données identifiées sans base légale, l'évaluation uniquement sur l'ensemble de démonstration du fournisseur, et les journaux de débogage remplis de données de patients.
- Bourrage de contexte : coller un dossier entier dans une invite. Coûteux, fuite de données, et le modèle se concentre sur les mauvaises parties. Un contexte délimité et classé avec provenance fonctionne mieux et est auditable.
- Injection d'invite via des documents : une lettre numérisée disant "ignorer les instructions précédentes". Traiter tout le contenu du dossier comme des données ; ne jamais le laisser définir la politique. Voir RAG sur les dossiers médicaux.
- Inférence silencieuse : un modèle inférant un diagnostic à partir du comportement et l'écrivant dans le dossier comme si un clinicien l'avait fait. Les résultats sont étiquetés comme générés par l'IA avec provenance et ne deviennent jamais une Condition sans une assertion humaine. Voir FHIR Condition expliqué.
- Entraînement sur des données identifiées sans base : le réglage fin sur les dossiers patients nécessite une base légale au-delà de "nous avions les données" ; les données dé-identifiées ou synthétiques servent généralement.
- Évaluation sur l'ensemble de démonstration du fournisseur : évaluer sur votre population, vos langues, vos types de documents, et continuer à évaluer après le déploiement.
- Journaux remplis de PHI : les invites et les complétions enregistrées pour le débogage deviennent un second dossier, non protégé. Pseudonymiser ou ne pas enregistrer le contenu.
Normes et éléments constitutifs
Les normes et les éléments constitutifs de l'IA sur les données médicales sont FHIR pour le dossier et pour les sorties structurées de l'IA, le Model Context Protocol pour un accès gouverné aux outils et aux données, SMART on FHIR pour l'autorisation, les travaux de HL7 sur le cycle de vie des données IA/ML pour la traçabilité, ISO/IEC 42001 pour la gestion de l'IA, et les normes harmonisées de l'AI Act.
FHIR pour le dossier et pour les sorties structurées de l'IA (Observation avec un derivedFrom, DocumentReference pour les résumés générés, Provenance avec le modèle comme agent) ; le Model Context Protocol pour donner aux assistants un accès gouverné aux outils et aux données ; SMART on FHIR pour l'autorisation ; le Cycle de vie des données IA/ML de HL7 et le travail sur la provenance pour la traçabilité ; ISO/IEC 42001 pour un système de management de l'IA ; les normes harmonisées du règlement sur l'IA au fur et à mesure de leur publication.
Chez Anpheros
Pour l'IA sur les données médicales, Anpheros fournit le dossier FHIR R4 avec les codes et la provenance, une API de contexte qui renvoie une tranche du dossier étiquetée par la provenance dans une limite de jetons, un serveur MCP via lequel les assistants lisent le dossier d'une personne avec le consentement de cette personne, et des journaux de consentement et d'accès que la personne contrôle. Anpheros n'exécute pas d'IA diagnostique.
Anpheros fournit le dossier (FHIR R4, codé, avec provenance), une API de contexte qui renvoie une tranche étiquetée par provenance dans un budget de jetons, un serveur MCP pour que les assistants comme Claude lisent le dossier d'une personne avec le consentement de cette personne, et des journaux de consentement et d'accès que la personne contrôle. Il n'exécute pas d'IA diagnostique et n'inscrit pas les inférences de l'IA dans le dossier comme des faits cliniques. Le site développeur contient les détails : API de santé pour l'IA, Serveur MCP, LLM sur les données de santé.
Pages associées
- RAG sur les dossiers médicaux : comment fonctionne la récupération sur un dossier FHIR
- Le règlement européen sur l'IA et l'IA en santé
- API de santé pour l'IA : contexte patient étiqueté par provenance
- Dé-identification des données de santé
- L'IA et votre dossier médical (pour les patients)
- Utilisation secondaire des données de santé
- Serveur MCP Anpheros (site développeur)
- LLM sur les données de santé (site développeur)
Sources
- Spécification du Model Context Protocol
- HL7 FHIR R4 : Provenance
- Règlement (UE) 2024/1689 (Règlement sur l'IA), EUR-Lex
- ISO/IEC 42001:2023, Système de management de l'IA
- OMS : Éthique et gouvernance de l'intelligence artificielle pour la santé, directives sur les grands modèles multimodaux (2024)
- HL7 SMART App Launch
Questions fréquentes
Puis-je régler finement un modèle sur des dossiers patients ?
Uniquement avec une base légale à cet effet (consentement, ou base de recherche selon l'article 9(2)(j) avec garanties), une analyse d'impact relative à la protection des données et généralement une dé-identification ; les dossiers identifiés ne peuvent pas être utilisés pour l'entraînement parce qu'ils étaient disponibles. Les données synthétiques et dé-identifiées répondent à la plupart des besoins de développement.
Un résumé IA d'un dossier est-il un dispositif médical ?
Non, s'il répète ce que contient le dossier pour le patient ou le clinicien sans l'interpréter pour le diagnostic ou le traitement. Au moment où il suggère ce que signifient cliniquement les résultats, il s'agit d'une aide à la décision relevant du MDR.
Qu'est-ce que MCP et pourquoi est-ce important ici ?
Le Model Context Protocol est une norme ouverte pour connecter les assistants IA à des outils et des sources de données via des serveurs aux capacités définies. Pour les données de santé, il permet à un assistant de lire le dossier d'une personne via un serveur gouverné, avec le consentement de la personne et un enregistrement, au lieu de coller des données dans un chat.
Comment évaluer une fonctionnalité LLM clinique ?
Avec un ensemble réservé de cas réels de votre population étiquetés par des cliniciens, des métriques de correction et de fidélité aux sources, une analyse par sous-groupe et langue, une revue des cas d'échec, et une surveillance après le lancement. Les benchmarks des fournisseurs sont un point de départ, pas une preuve.
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

