Aller au contenu
NEURIXIS

Secteur

L’IA dans un environnement de soin

En santé, l’architecture est décidée par la conformité avant de l’être par la technique. Le statut réglementaire du logiciel, le lieu d’hébergement et le régime du traitement se tranchent au cadrage : découverts en cours de route, ils arrêtent le projet.

Le contexte

La donnée de santé est abondante et hétérogène : comptes rendus en texte libre, codages d’activité, images DICOM, flux HL7 ou FHIR, et une couche de tableurs de service que personne ne revendique. Les identifiants patients ne se recoupent pas d’un logiciel à l’autre, et le chaînage est souvent le vrai sujet technique du projet, avant tout modèle.

L’essentiel de l’information clinique est dans le texte libre, et ce texte est écrit vite : abréviations propres au service, négations, hypothèses, antécédents mêlés aux constats du jour. Un extracteur qui ne traite pas explicitement la négation et l’antériorité transforme « pas d’argument pour » en diagnostic posé. Ce n’est pas un défaut marginal, c’est la première source d’erreur.

Ce qui compte n’est pas la performance moyenne, c’est le comportement sur les cas rares et la capacité du système à ne pas répondre. Un modèle qui produit toujours une sortie, avec la même assurance, n’est pas utilisable dans un parcours de soin. Le refus explicite et la remontée en file humaine sont des fonctionnalités, pas des palliatifs.

Le cloisonnement est réel et voulu : hébergement certifié, pseudonymisation, traçabilité des accès, séparation des finalités de soin et de recherche. Ces contraintes ne s’ajoutent pas en fin de projet, elles déterminent l’architecture dès le premier schéma. Un projet santé bien cadré coûte moins cher qu’un projet mal cadré repris six mois plus tard.

Bloc opératoire équipé de matériel médical de pointe.

Contraintes réglementaires

Trois questions se posent avant l’architecture : où vivent les données, sous quel régime sont-elles traitées, et le logiciel visé est-il un dispositif médical ? Tant qu’elles ne sont pas tranchées, il n’y a pas de projet.

  • Certification HDS

    L’hébergement de données de santé à caractère personnel recueillies pour la prévention, le diagnostic, les soins ou le suivi social et médico-social est soumis à certification, en application du code de la santé publique. Le point que l’on oublie systématiquement : la contrainte porte aussi sur les environnements d’entraînement, les jeux de développement et les sauvegardes, pas seulement sur la production. Un export « pour tester » vers un environnement non couvert est une non-conformité, même temporaire.

  • RGPD, article 9

    Les données concernant la santé relèvent des catégories particulières de l’article 9 : leur traitement est interdit par principe, et suppose à la fois une base légale et l’une des conditions de levée de cette interdiction. La conséquence pratique est peu intuitive : la finalité de soin et la finalité de recherche ne se confondent pas, et la donnée collectée pour l’une ne bascule pas librement vers l’autre. C’est la question qui décide de la faisabilité d’un entraînement sur vos propres données.

  • Cadre CNIL : recherche et entrepôts

    Les traitements de données de santé à des fins de recherche s’appuient sur les méthodologies de référence de la CNIL, auxquelles un responsable de traitement peut déclarer sa conformité, ou à défaut sur une autorisation. La constitution d’un entrepôt de données de santé relève d’un cadre dédié, avec ses propres exigences de gouvernance et d’information des personnes. Choisir entre ces voies est le premier arbitrage du projet : il conditionne le calendrier plus sûrement que le choix du modèle.

  • Règlement dispositifs médicaux (UE) 2017/745

    Un logiciel destiné par son fabricant à une finalité médicale, diagnostic, prévention, pronostic, traitement ou surveillance, est un dispositif médical et relève de la classification et de l’évaluation de conformité prévues par le règlement. La frontière entre outil d’aide à l’organisation et outil d’aide à la décision médicale est parfois ténue dans la discussion, jamais dans ses conséquences : elle décide du coût, du calendrier et des compétences à réunir. Nous la posons à la première réunion, par écrit.

  • AI Act, annexe III

    Certains usages touchant à la santé relèvent du haut risque au titre de l’annexe III, notamment les systèmes destinés au tri dans l’accès aux services d’urgence. Ces obligations s’ajoutent à celles du règlement dispositifs médicaux quand le logiciel est aussi un dispositif : les deux dossiers ont des exigences voisines sur la gestion des risques et la documentation, et il est plus économique de les construire ensemble que de les rattraper séparément, une fois le produit déjà sur le marché.

Classement des systèmes d’IA du plus au moins encadré : risque inacceptable, haut risque, risque limité, risque minimal.Le plus encadréLe moins encadréRisque inacceptableInterdit dans l’UnionHaut risqueAnnexe III, obligations lourdesRisque limitéObligations de transparenceRisque minimalUsage libre

Cas d’usage

  • Structuration des comptes rendus

    Le problème
    L’information clinique est enfermée dans du texte libre. Le codage, la constitution de cohortes et les extractions pour la recherche se font à la main, sur relecture, avec un délai qui décourage l’usage.
    L’approche
    Extraction d’entités et de relations avec traitement explicite de la négation, de l’incertitude, de l’antériorité et du sujet (patient ou proche). Modèle de langue exécuté sur infrastructure certifiée HDS ou sur site, jamais sur une interface tierce. Sortie contrainte par un schéma, pour être vérifiable plutôt que plausible.

    Critère de succès

    Précision et rappel par type d’entité sur un jeu annoté par deux cliniciens indépendants, avec mesure de leur accord. Cet accord est le plafond de performance atteignable : en dessous, aucune conclusion n’est possible, et le premier livrable utile est parfois l’amélioration du protocole d’annotation lui-même.

  • Recherche documentaire interne assistée

    Le problème
    Protocoles, procédures et recommandations vivent dans un intranet, des PDF et des classeurs. Plusieurs versions coexistent, parfois contradictoires, et la réponse dépend de la personne interrogée.
    L’approche
    Indexation avec contrôle de version des documents, recherche hybride lexicale et vectorielle, reclassement des passages, réponse systématiquement citée avec renvoi au passage source et à sa date de version, refus explicite quand la base ne contient pas la réponse, et journalisation des questions pour réviser le corpus.

    Critère de succès

    Taux de réponses correctement sourcées et taux de refus à bon escient, sur un jeu de questions écrit par les professionnels eux-mêmes. Et taux d’affirmations non étayées par un passage cité : ce chiffre doit être nul sur le jeu de qualification avant toute mise en service, sans négociation.

  • Prévision d’activité et de charge

    Le problème
    La planification des lits, des blocs ou des équipes repose sur l’historique et l’intuition. Sur-effectif un jour, tension le lendemain, sans que personne puisse dire à l’avance lequel des deux arrive.
    L’approche
    Séries temporelles à saisonnalités multiples, heure, jour, semaine, périodes scolaires, saison épidémique, avec production d’un intervalle de prédiction plutôt que d’une valeur unique. La décision d’armement se prend sur le haut de l’intervalle, pas sur la moyenne : c’est le point que les tableaux de bord ratent le plus souvent.

    Critère de succès

    Erreur absolue par créneau sur une période postérieure à l’entraînement, comparée à une référence naïve saisonnière et à la planification en place. Et couverture empirique des intervalles : un intervalle annoncé à 90 % doit contenir la valeur observée dans neuf cas sur dix, sinon il est décoratif.

  • Contrôle de cohérence du codage et de la facturation

    Le problème
    Le codage alimente la facturation et le suivi d’activité. Les écarts sont détectés tard, en contrôle, quand la correction coûte le plus cher et mobilise du temps médical déjà rare.
    L’approche
    Classification sur codage historique combinée à des règles métier explicites, positionnée en détection d’écart et jamais en codage automatique. La sortie est une file de dossiers à revoir, ordonnée par probabilité d’écart, avec les éléments qui ont déclenché le signalement et l’écart estimé.

    Critère de succès

    Précision en tête de file : part des dossiers signalés dans lesquels un contrôleur confirme un écart réel, mesurée sur les premiers dossiers de la file, à charge de contrôle constante. C’est le seul chiffre qui intéresse le service, et c’est celui que nous nous engageons à produire.

Matrice deux par deux croisant l’effort d’intégration et le gain annuel estimé, avec quatre quadrants nommés.Quick winGain fort, effort faibleChantier structurantGain fort, effort fortGadgetGain faible, effort faiblePiègeGain faible, effort fortGain annuel estiméfortfaibleEffort d’intégrationfaiblefort

Ce qui fait échouer les projets

Les projets d’IA en santé échouent rarement sur le modèle. Ils échouent sur le cadrage, l’accès aux données et le poste de travail.

  • Le projet démarre sans avoir écrit le statut réglementaire du logiciel visé. Six mois plus tard, la finalité retenue en fait un dispositif médical. Le calendrier et le budget n’ont plus rien à voir avec ce qui a été présenté.
  • Un extrait de données quitte l’établissement « juste pour tester » vers un environnement non couvert. Le projet s’arrête, et il a raison de s’arrêter. Ce point se traite avant, avec le DPO et le RSSI, jamais après avec des excuses.
  • Le modèle est évalué sur un jeu issu du même service, de la même période et du même logiciel métier que le jeu d’entraînement. Il ne tient pas sur le service voisin, et personne ne l’avait testé sur le service voisin.
  • Aucun clinicien n’a co-écrit le protocole d’évaluation. Le modèle optimise alors un critère techniquement propre que le métier ne reconnaît pas comme la mesure de son problème.
  • L’outil est bon mais il ajoute deux clics dans un logiciel où le temps par patient est déjà contraint. Il n’est pas utilisé. L’intégration au poste de travail existant décide de l’adoption, et elle se conçoit au début.
  • La pseudonymisation est traitée comme un remplacement d’identifiants dans une base, alors que le texte libre contient des noms, des dates, des adresses et des noms de praticiens. Il faut la traiter dans le texte lui-même, puis la vérifier sur un échantillon relu.
Cycle fermé du MLOps : entraîner, déployer, superviser, détecter la dérive, réentraîner.EntraînerDéployerSuperviserDétecter la dériveRéentraîner

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

  • Nous associons le DPO, le RSSI, la DSI et les cliniciens dès la première réunion, avant tout schéma d’architecture.
  • Nous qualifions par écrit le statut réglementaire du logiciel visé et le régime applicable au traitement, et nous en tirons les conséquences sur le périmètre.
  • Nous concevons sur hébergement certifié HDS ou sur votre infrastructure, y compris pour les environnements d’entraînement.
  • Nous traitons la pseudonymisation dans le texte libre, avec une vérification sur échantillon relu, pas seulement dans les colonnes d’identifiants.
  • Nous co-écrivons les protocoles d’évaluation avec les cliniciens et nous mesurons l’accord inter-annotateurs avant d’annoncer une performance.
  • Nous produisons la documentation AI Act et les éléments techniques qui alimentent votre dossier de conformité.

Ce que nous ne faisons pas

  • Nous ne sommes ni hébergeur de données de santé, ni organisme certificateur, ni organisme notifié. Nous concevons pour ces cadres, nous ne les délivrons pas.
  • Nous ne produisons aucun conseil médical et nous ne validons pas une performance clinique à votre place : cette responsabilité reste à vos praticiens et à votre structure.
  • Nous ne prenons pas de projet dans lequel les données ne peuvent pas rester dans un environnement conforme. Il n’existe pas d’aménagement acceptable sur ce point.
  • Nous ne remplaçons pas votre éditeur de logiciel métier et nous ne reprenons pas la maintenance de son produit.
  • Nous sommes deux. Nous ne conduisons pas un déploiement multi-établissements en parallèle, et nous préférons le dire avant la proposition commerciale.

Les autres secteurs

Questions fréquentes

  • Nos données de santé restent-elles sur un hébergement certifié HDS ?

    Oui, y compris pour l’entraînement. La certification HDS ne porte pas que sur la production : elle couvre aussi les environnements d’entraînement, les jeux de développement et les sauvegardes. Un export « pour tester » vers un environnement non couvert est une non-conformité, même temporaire. Nous concevons sur hébergement certifié HDS ou sur votre infrastructure, et nous ne prenons pas de projet dans lequel les données ne peuvent pas rester dans un environnement conforme.

  • Votre logiciel sera-t-il un dispositif médical ?

    Cela dépend de la finalité que vous lui donnez, et nous la qualifions par écrit à la première réunion. Un logiciel destiné à une finalité médicale, diagnostic, prévention, pronostic, traitement ou surveillance, relève du règlement dispositifs médicaux et de son évaluation de conformité. La frontière entre outil d’aide à l’organisation et outil d’aide à la décision médicale est parfois ténue dans la discussion, jamais dans ses conséquences : elle décide du coût, du calendrier et des compétences à réunir.

  • Comment gérez-vous la pseudonymisation dans les comptes rendus ?

    Dans le texte lui-même, pas seulement dans les colonnes d’identifiants. Un compte rendu en texte libre contient des noms, des dates, des adresses et des noms de praticiens : traiter la pseudonymisation comme un simple remplacement d’identifiants dans une base laisse fuir tout le reste. Nous la traitons dans le texte, puis nous la vérifions sur un échantillon relu, parce qu’une pseudonymisation non vérifiée n’est qu’une hypothèse.

  • Peut-on entraîner un modèle sur nos données de soin ?

    Cela dépend du régime du traitement, et c’est le premier arbitrage du projet. Les données de santé relèvent des catégories particulières de l’article 9 du RGPD : leur traitement suppose une base légale et l’une des conditions de levée de l’interdiction de principe. La finalité de soin et la finalité de recherche ne se confondent pas, et la donnée collectée pour l’une ne bascule pas librement vers l’autre. Cette question décide de la faisabilité d’un entraînement sur vos propres données, et elle se tranche avec votre DPO avant tout schéma d’architecture.

Parlons de votre cas d’usage.

Une heure suffit pour savoir si votre sujet tient debout. Si ce n’est pas le cas, nous vous le dirons à ce moment-là, pas après trois mois de projet.

Nous contacterRéserver un Workshop Quick Wins IA