Les programmes municipaux de santé communautaire occupent une place particulière dans la prestation des soins. Répartis entre les écoles, les visites à domicile et les cliniques locales, principalement assurés par des infirmiers, infirmières et visiteurs de santé, ils relèvent de mandats à l’échelle de la population plutôt que d’indicateurs liés à des épisodes de soins individuels. Lorsqu’une assistance IA à la documentation est introduite dans cet environnement, les critères d’évaluation appliqués dans un cabinet de médecin généraliste ou un service hospitalier ne correspondent pas directement à ce qu’une municipalité doit réellement examiner. Ce guide propose un cadre structuré pour les administrateurs de santé publique abordant cette évaluation pour la première fois, en s’appuyant sur les obligations réglementaires européennes actuelles, les données probantes issues de la mise en œuvre et les réalités pratiques de la prestation de soins communautaires.

Pourquoi les contextes de santé municipale nécessitent un cadre d’évaluation distinct

Les principales données probantes concernant les outils d’assistance IA à la documentation en milieu clinique proviennent des hôpitaux de soins secondaires et, dans une moindre mesure, des cabinets de médecins généralistes. Ces deux contextes partagent des caractéristiques qui ne reflètent pas le fonctionnement des programmes de santé communautaire : salles de consultation fixes, infrastructure informatique dédiée et cliniciens disposant de temps réservé à la documentation.

La prestation de soins de santé communautaire municipaux est généralement assurée par des infirmiers, réalisée dans plusieurs lieux dispersés et structurée autour de rencontres brèves et souvent informelles : un examen de santé scolaire, une visite à domicile auprès d’une nouvelle mère, une séance sans rendez-vous dans un centre communautaire. Le personnel se déplace fréquemment entre les sites, la connectivité est intermittente et la même personne peut exercer simultanément les fonctions de clinicien, de coordinateur de soins et de gestionnaire de cas.

L’évaluation de l’OMS/Europe sur la préparation à l’intelligence artificielle dans les États membres de l’UE a révélé que la préparation de la main-d’œuvre et les structures de gouvernance des données varient considérablement entre les systèmes de santé nationaux et les niveaux de prestation infranationaux. Cela confirme que les administrateurs municipaux ne peuvent pas supposer qu’un outil validé en milieu hospitalier fonctionnera de manière appropriée dans leur contexte.

L’analyse de la Commission européenne sur les obstacles au déploiement de l’IA dans la pratique clinique identifie quatre catégories distinctes de défis : les défis technologiques et liés aux données, la complexité réglementaire, les obstacles organisationnels et financiers, ainsi que les facteurs sociaux et culturels. Dans les programmes municipaux de santé communautaire, ces quatre catégories se manifestent avec une intensité particulière, rendant un cadre d’évaluation adapté indispensable plutôt qu’optionnel.

Une revue systématique des facteurs de mise en œuvre de la santé numérique dans les contextes de soins primaires, secondaires et à domicile a montré que le succès du déploiement dépendait de facteurs agissant simultanément au niveau de la technologie elle-même, du cadre organisationnel externe, du contexte de prestation interne et des professionnels impliqués. Les programmes municipaux de santé couvrent tous ces niveaux d’une manière que les déploiements hospitaliers ne recouvrent généralement pas.

Ce qu’un assistant médical IA fait réellement dans un contexte de santé communautaire

Avant toute évaluation réglementaire ou décision d’achat, les administrateurs ont besoin d’une définition fonctionnelle précise de l’outil évalué. Une mauvaise classification à ce stade entraîne des erreurs de conformité difficiles à corriger par la suite.

Un assistant médical IA en santé communautaire effectue les opérations suivantes :

• Écoute une conversation clinique entre un professionnel de santé et un patient ou un membre de la famille

• Convertit le contenu oral en texte en temps réel à l’aide de la technologie de reconnaissance vocale (reconnaissance automatique de la parole)

• Génère un compte rendu médical ou une synthèse structurée à partir de cette transcription

• Réduit la charge de documentation pour le clinicien en automatisant la création des notes

Ce qu’il ne fait pas, et cette distinction a un poids réglementaire, c’est interpréter les résultats cliniques, suggérer des diagnostics, recommander des traitements ou signaler des risques cliniques. Ces fonctions relèvent de l’aide à la décision médicale, qui implique des obligations réglementaires différentes, tant au titre du règlement européen sur les dispositifs médicaux (RDM) que de la législation européenne sur l’IA.

Le cadre du Lancet Primary Care pour catégoriser les applications d’IA dans les soins primaires utilise la taxonomie des interventions de santé numérique de l’Organisation mondiale de la santé pour établir précisément cette distinction, séparant les outils qui soutiennent la documentation et la communication de ceux qui fournissent des conseils cliniques. Les administrateurs qui confondent ces deux catégories risquent soit de sur-réglementer un outil de documentation, soit, plus dangereusement, de sous-réglementer un outil qui exerce réellement des fonctions cliniques.

Un test pratique : si le retrait de la sortie de l’outil IA d’une consultation ne modifie pas le jugement clinique du professionnel, l’outil fonctionne comme un assistant de documentation. Si la sortie de l’outil influence ce que le clinicien décide de faire ensuite, il fonctionne comme une aide à la décision médicale.

Classification RDM : ce que les administrateurs municipaux doivent déterminer en premier

La classification au titre du RDM (Règlement 2017/745) est la première décision formelle à prendre avant toute décision d’achat. Se tromper expose la municipalité à une responsabilité juridique et, plus important encore, à un risque pour la sécurité des patients.

La question centrale est de savoir si l’assistant médical IA répond à la définition du RDM d’un dispositif médical, en particulier s’il est destiné au diagnostic, à la prévention, à la surveillance, au traitement ou au soulagement d’une maladie. Un outil qui se limite à capturer et structurer des conversations cliniques, sans interpréter leur contenu, se situe généralement hors du champ d’application du RDM. Un outil qui génère des recommandations cliniques, des scores de risque ou des suggestions de diagnostic y est soumis.

La convergence du RDM, du Règlement général sur la protection des données (RGPD) et de la législation européenne sur l’IA signifie que même un outil non classé comme dispositif médical peut comporter des obligations au titre de la loi sur l’IA s’il est considéré comme un système d’IA à haut risque, par exemple s’il est utilisé d’une manière qui influence les décisions cliniques affectant la sécurité des patients.

Lorsqu’un outil est classé comme dispositif médical :

• Le fabricant doit détenir le marquage CE en vertu du RDM

• Une évaluation de conformité doit avoir été réalisée, impliquant potentiellement un organisme notifié

• La documentation technique, la surveillance post-commercialisation et les obligations de déclaration d’incident s’appliquent

• La municipalité, en tant que déployeur, assume des obligations spécifiques en tant qu’opérateur économique

L’analyse des implications de la législation européenne sur l’IA pour les soins de santé souligne qu’il existe un goulot d’étranglement pratique dans la disponibilité des organismes notifiés capables d’évaluer les dispositifs médicaux basés sur l’IA. Les administrateurs doivent demander directement aux fournisseurs l’état actuel de leur évaluation de conformité et ne pas supposer que le marquage CE est imminent s’il n’a pas encore été accordé.

Les administrateurs devraient demander à tout fournisseur :

• Une déclaration écrite de l’usage prévu

• La confirmation de la classification RDM et sa justification

• La documentation du marquage CE le cas échéant, ou une explication claire de la raison pour laquelle l’outil se situe hors du champ d’application du RDM

• La preuve de toute implication d’un organisme notifié

RGPD et hébergement des données : questions clés pour les municipalités traitant des données de patients

Un assistant médical IA traite des données personnelles de catégorie spéciale au sens du RGPD, en particulier des données de santé concernant des personnes identifiables. Cela déclenche le niveau le plus strict d’obligations RGPD, et les municipalités, en tant que responsables du traitement, portent la responsabilité principale de garantir que ces obligations sont respectées.

Les questions clés du RGPD que les administrateurs municipaux doivent résoudre avant l’achat sont :

Base légale : Les programmes de santé communautaire s’appuient généralement sur l’article 9(2)(h), traitement nécessaire à des fins de médecine préventive ou professionnelle, de diagnostic médical ou de prestation de soins de santé, combiné à l’article 6(1)(e) pour mission d’intérêt public. Les administrateurs doivent confirmer avec leur délégué à la protection des données (DPD) que cette base est correctement documentée.

Accord de traitement des données : Lorsqu’un fournisseur traite des données de patients pour le compte de la municipalité, un accord de traitement des données (ATD) conforme à l’article 28 du RGPD doit être en place avant tout traitement. L’ATD doit préciser l’objet, la durée, la nature et la finalité du traitement, le type de données personnelles et les catégories de personnes concernées, ainsi que les obligations et droits du responsable du traitement.

Hébergement des données : Les exigences d’hébergement des données au sein de l’UE pour les données de santé constituent un critère important lors de l’achat. Les municipalités doivent exiger que les données des patients soient stockées et traitées au sein de l’UE/Espace économique européen (EEE), et obtenir des garanties contractuelles en ce sens. Lorsqu’un fournisseur fait appel à des sous-traitants, par exemple des prestataires d’infrastructure cloud, l’emplacement de chaque sous-traitant doit être divulgué et évalué.

Transparence des sous-traitants : Les fournisseurs doivent être en mesure de fournir une liste complète des sous-traitants impliqués dans le traitement des données des patients, avec leurs emplacements et les garanties en place pour tout transfert hors UE/EEE.

Minimisation et conservation des données : Les administrateurs doivent confirmer quelles données l’outil conserve après une consultation, pendant combien de temps et selon quelle politique de suppression ou d’anonymisation.

L’Espace européen des données de santé (EEDS), entré en vigueur en 2025, ajoute une couche supplémentaire d’obligations de gouvernance des données que les municipalités des États membres de l’UE doivent prendre en compte dans leur évaluation, en particulier lorsque les données des patients peuvent être accessibles au-delà des frontières.

Évaluation de la posture de sécurité du fournisseur : quelles certifications et contrôles rechercher

L’évaluation de la sécurité d’un fournisseur d’assistant médical IA ne se limite pas à un simple exercice de conformité. Elle exige des administrateurs qu’ils examinent à la fois les certifications formelles du fournisseur et les contrôles pratiques mis en place.

ISO 27001 est la certification de base à exiger. Elle atteste que le fournisseur a mis en œuvre un système de gestion de la sécurité de l’information (SGSI) audité de manière indépendante. Les administrateurs doivent demander le certificat actuel, son périmètre et la date du dernier audit de surveillance.

Au-delà de l’ISO 27001, les administrateurs devraient interroger directement les fournisseurs sur :

• Contrôles d’accès : Qui, au sein de l’organisation du fournisseur, peut accéder aux données des patients, dans quelles conditions et avec quelle traçabilité ?

• Chiffrement : Les données sont-elles chiffrées en transit et au repos ? Quelles normes de chiffrement sont appliquées ?

• Journaux d’audit : Les événements d’accès et de traitement sont-ils enregistrés, et la municipalité peut-elle accéder à ces journaux ?

• Notification de violation : Quel est l’engagement contractuel du fournisseur concernant les délais de notification en cas de violation ? Le RGPD exige une notification aux autorités de contrôle dans les 72 heures suivant la prise de connaissance d’une violation, et les fournisseurs doivent être en mesure de respecter ce délai.

• Tests d’intrusion : À quelle fréquence le système est-il testé de manière indépendante pour détecter les vulnérabilités, et les rapports sont-ils disponibles ?

• Sécurité des sous-traitants : Quelles exigences de sécurité le fournisseur impose-t-il à ses sous-traitants, et comment la conformité est-elle vérifiée ?

Les exigences de la législation européenne sur l’IA pour les systèmes d’IA à haut risque incluent des obligations concernant la robustesse, la précision et la cybersécurité, que les fournisseurs d’outils concernés doivent démontrer par leur documentation technique. Les administrateurs doivent demander si l’outil a été évalué au regard de la loi sur l’IA et, le cas échéant, à quelle classification de risque il appartient.

Les cadres nationaux de sécurité des données de santé, tels que ceux mis en place par les agences nationales de cybersécurité en France, en Allemagne ou aux Pays-Bas, peuvent imposer des exigences supplémentaires à l’ISO 27001. Les municipalités doivent vérifier si leur cadre national s’applique aux systèmes de données de santé municipaux et si la certification du fournisseur le couvre.

Adéquation au flux de travail des soins communautaires : pourquoi les outils validés en hôpital peuvent ne pas se transférer directement

Un outil efficace en clinique externe hospitalière ou en cabinet de médecin généraliste peut fonctionner de manière très différente dans un contexte de santé communautaire. Les administrateurs ne doivent pas considérer les validations hospitalières ou en médecine générale comme une preuve suffisante d’adéquation pour un déploiement en santé communautaire.

Les caractéristiques du flux de travail qui distinguent la prestation de soins de santé communautaire comprennent :

• Consultations mobiles et à domicile : Le clinicien n’est pas dans un environnement acoustique fixe. Le bruit de fond, la qualité variable du microphone et la distance par rapport à l’appareil affectent la précision de la transcription, contrairement aux environnements cliniques contrôlés.

• Connectivité intermittente : De nombreuses visites de santé communautaire se déroulent dans des endroits où l’accès à Internet est peu fiable. Les administrateurs doivent déterminer si l’outil nécessite une connexion continue ou peut fonctionner hors ligne avec synchronisation ultérieure.

• Consultations brèves : Les rencontres de santé communautaire sont souvent plus courtes et moins structurées que les rendez-vous hospitaliers ou de médecine générale, avec un langage clinique moins prévisible et davantage d’échanges conversationnels.

• Personnel multifonction : Les travailleurs de santé communautaire et les visiteurs de santé exercent fréquemment des fonctions couvrant l’évaluation clinique, la coordination des soins sociaux et la surveillance de la santé publique. Les modèles de notes et la sortie structurée de l’outil doivent refléter cette diversité.

• Appareils partagés ou personnels : Contrairement aux contextes hospitaliers où les appareils sont généralement fixes et gérés, le personnel de santé communautaire peut utiliser des tablettes partagées ou des appareils personnels, soulevant des questions supplémentaires de sécurité et de contrôle d’accès.

Le cadre du Lancet Primary Care souligne que les outils d’IA dans les soins primaires et communautaires doivent être évalués selon le modèle de prestation réel, et non selon une rencontre clinique généralisée. Les administrateurs doivent demander spécifiquement aux fournisseurs si l’outil a été testé ou déployé dans des contextes de santé communautaire, de visites à domicile ou de santé scolaire, et exiger des données de performance issues de ces contextes plutôt que d’environnements hospitaliers.

Une étude de mise en œuvre multicentrique de l’aide à la décision médicale dans divers contextes de soins primaires a montré que la conception centrée sur l’utilisateur et les tests d’intégration au flux de travail étaient des facteurs critiques de succès pour l’adoption. Ces conclusions s’appliquent directement aux outils de documentation IA en santé communautaire.

Rôles du personnel et exigences de formation dans les services dirigés par des infirmiers et les services de santé scolaire

La main-d’œuvre des programmes municipaux de santé communautaire diffère des contextes hospitaliers ou de médecine générale, ce qui a un impact sur les exigences de formation et les structures de responsabilité. Les administrateurs doivent aborder ces différences explicitement avant le déploiement.

Qui utilisera l’outil ? Dans les services dirigés par des infirmiers, les programmes de visites de santé et les équipes de santé scolaire, les principaux utilisateurs sont des infirmiers diplômés, des visiteurs de santé et des travailleurs de santé communautaire, et non des médecins. La formation et la gestion du changement doivent être conçues pour cette main-d’œuvre, et non adaptées à partir de ressources développées pour la médecine générale ou l’hôpital.

Formation technique et renforcement de la confiance : Une enquête transversale auprès de professionnels de santé sur les outils de documentation IA a montré que la familiarité avec les outils d’IA et la connaissance des politiques institutionnelles étaient toutes deux faibles, même parmi les professionnels travaillant dans des contextes où des outils d’IA étaient disponibles. La formation technique, couvrant le fonctionnement de l’outil, est nécessaire mais insuffisante. Le personnel a également besoin d’un accompagnement pour développer la confiance dans la sortie de l’outil et acquérir le jugement critique nécessaire pour identifier quand la note générée par l’IA ne reflète pas fidèlement la rencontre clinique.

Responsabilité de l’exactitude des notes : Lorsqu’un assistant IA génère un compte rendu médical, le clinicien ayant mené la rencontre conserve l’entière responsabilité professionnelle et juridique de l’exactitude de cette note. Cela doit être communiqué clairement et sans ambiguïté à tout le personnel avant le déploiement, et intégré dans les supports de formation. La note générée par l’IA est un brouillon à relire par le clinicien, et non un dossier final.

Gestion du changement : L’évaluation régionale de l’OMS/Europe identifie la préparation de la main-d’œuvre comme l’un des principaux obstacles à l’adoption de l’IA dans les systèmes de santé de la Région européenne. Les administrateurs doivent prévoir un processus structuré de gestion du changement comprenant :

• Consultation du personnel avant le déploiement

• Déploiement progressif avec des adopteurs précoces désignés

• Mécanismes de retour d’information continus

• Responsables cliniques désignés pour la gouvernance et l’assurance qualité

Qualité et exactitude des comptes rendus médicaux : comment évaluer avant de déployer

L’évaluation de l’exactitude ne doit pas être entièrement déléguée aux fournisseurs. Un processus d’évaluation structuré, mené dans le contexte clinique propre à la municipalité, est essentiel avant tout déploiement.

Définir ce que signifie « exact » pour votre contexte. Un compte rendu médical généré lors d’une visite à domicile d’un visiteur de santé a des exigences structurelles différentes d’une note de consultation de médecin généraliste ou d’un compte rendu de sortie hospitalière. Les administrateurs doivent définir à l’avance ce à quoi ressemble une note satisfaisante pour chaque type de rencontre dans leur programme : quels champs doivent être présents, quel langage clinique est approprié et quelles omissions constitueraient une erreur substantielle.

Mener un projet pilote structuré. Avant le déploiement généralisé, un projet pilote à durée limitée avec un groupe défini de personnel et un ensemble précis de types de rencontres permet aux administrateurs d’évaluer l’exactitude dans leur contexte spécifique. Le projet pilote doit inclure :

• Un échantillon de consultations réelles couvrant différents types de rencontres

• Un examen indépendant des notes générées par l’IA par rapport aux notes rédigées par les cliniciens ou au rappel des cliniciens

• Un enregistrement structuré des erreurs, omissions et hallucinations (cas où l’IA génère du contenu qui n’a pas été dit)

• Retour d’information du personnel sur l’utilisabilité et l’adéquation au flux de travail

Définir des seuils d’acceptation. Les administrateurs doivent fixer, avant le début du projet pilote, le niveau d’exactitude acceptable et le taux d’erreur qui entraînerait une décision de ne pas poursuivre. Cela évite de rationaliser a posteriori de mauvais résultats.

Établir un examen continu de la qualité. Le déploiement ne doit pas mettre fin à l’évaluation de l’exactitude. Un examen régulier d’un échantillon de notes générées par l’IA, mené par un responsable de la gouvernance clinique, doit être intégré au cadre de gouvernance du programme dès le départ.

Un essai randomisé en grappes mené en Belgique sur l’aide à la décision médicale dans les soins primaires a montré que des dossiers structurés incomplets étaient une cause majeure de faibles taux d’utilisation du système. Cela souligne l’importance de s’assurer que les notes générées par l’IA répondent aux exigences de données structurées du système de dossiers médicaux de la municipalité avant le déploiement.

Considérations relatives à la langue, au dialecte et à la diversité de la population

Les programmes municipaux de santé communautaire desservent fréquemment des populations linguistiquement diverses. Cela est particulièrement vrai dans les municipalités urbaines avec d’importantes communautés de migrants ou de réfugiés, et dans les régions accueillant des populations de langues minoritaires. Les outils de documentation IA performants en anglais, néerlandais ou allemand standard peuvent être nettement moins efficaces face à la parole accentuée, aux dialectes régionaux ou à l’alternance de langues.

Le Lancet Primary Care identifie l’équité comme un principe fondamental pour l’intégration de l’IA dans les soins primaires et communautaires, notant que les outils qui fonctionnent différemment selon les groupes de population risquent d’amplifier les inégalités de santé existantes plutôt que de les réduire. Pour les programmes municipaux de santé ayant un mandat explicite de santé publique, ce n’est pas une préoccupation abstraite, mais une obligation de gouvernance.

Les administrateurs doivent demander aux fournisseurs :

• Dans quelles langues et variantes linguistiques l’outil a-t-il été validé ?

• Quel est le différentiel d’exactitude documenté entre les variétés de parole standard et non standard dans ces langues ?

• Comment l’outil gère-t-il les consultations menées partiellement ou entièrement par l’intermédiaire d’un interprète ?

• Quelle est la feuille de route du fournisseur pour élargir la couverture linguistique ?

Les tests doivent inclure des consultations avec du personnel et des patients représentatifs de la diversité réelle de la population de la municipalité, et pas seulement du groupe linguistique majoritaire. Si l’outil ne peut pas démontrer une exactitude acceptable dans les principaux groupes linguistiques de la municipalité, il ne doit pas être déployé dans les services desservant ces populations.

Intégration avec les systèmes de dossiers médicaux existants et l’informatique municipale

L’intégration technique est souvent l’étape la plus longue dans le déploiement d’un assistant médical IA. Les administrateurs doivent commencer cette évaluation tôt et ne pas la considérer comme une simple question de mise en œuvre finale.

Les questions d’intégration de base sont :

Compatibilité du système de dossiers médicaux : Avec quels systèmes de dossiers médicaux l’outil s’intègre-t-il actuellement, et par quel mécanisme ? L’intégration directe via une interface de programmation d’application (API), HL7 Fast Healthcare Interoperability Resources (FHIR), ou un connecteur propriétaire implique chacun une complexité de mise en œuvre et des obligations de maintenance différentes.

Contraintes des systèmes existants : L’analyse de la Commission européenne identifie l’infrastructure de données fragmentée et les systèmes existants comme l’un des quatre principaux obstacles au déploiement de l’IA dans les contextes de santé européens. Les environnements informatiques de santé publique municipaux incluent fréquemment des systèmes plus anciens, antérieurs aux normes d’interopérabilité modernes. Les administrateurs doivent obtenir une évaluation technique claire pour savoir si l’outil IA peut fonctionner dans leur infrastructure existante ou nécessite des mises à niveau préalables.

Conformité MyHealth@EU et FHIR : Un tutoriel JMIR sur la conformité à la législation IA dans le cadre MyHealth@EU décrit le double défi de conformité auquel sont confrontés les déployeurs d’IA en santé : contrôles verticaux de sécurité et d’éthique au titre de la loi sur l’IA, et exigences horizontales d’interopérabilité au titre de MyHealth@EU utilisant les normes FHIR/HL7. Les municipalités participant à des programmes d’échange de données de santé transfrontaliers doivent s’assurer que la sortie de l’outil IA est compatible avec ces normes.

Fonctionnalité hors ligne : Pour les contextes de santé communautaire avec une connectivité intermittente, les administrateurs doivent vérifier si l’outil peut capturer et traiter des consultations hors ligne, et comment la synchronisation avec le système central de dossiers médicaux est gérée lors du rétablissement de la connexion.

Cartographie du flux de données : Avant le déploiement, une cartographie complète du flux de données, indiquant où les données sont créées, traitées, stockées et supprimées, doit être produite et examinée par le DPD. Il s’agit à la fois d’une exigence RGPD et d’un outil de gouvernance pratique.

Approvisionnement et gouvernance : construire le dossier interne pour l’approbation

L’approvisionnement municipal d’un assistant médical IA implique plusieurs parties prenantes, et la séquence dans laquelle elles sont mobilisées est importante. Les administrateurs qui abordent l’achat principalement comme une acquisition technologique, plutôt que comme un processus de gouvernance, rencontrent généralement des retards et des objections qui auraient pu être anticipés.

Les parties prenantes internes à impliquer, et la séquence reflétant une bonne pratique de gouvernance, sont :

Délégué à la protection des données : Le DPD doit être impliqué dès le départ, et non consulté en fin de processus. Il doit mener ou superviser une analyse d’impact relative à la protection des données (AIPD) au titre de l’article 35 du RGPD, obligatoire lorsque le traitement est susceptible d’entraîner un risque élevé pour les personnes, comme c’est le cas avec l’IA traitant des données de santé à grande échelle.

Responsable de la gouvernance clinique : Cette personne doit définir les normes de qualité clinique que l’outil doit respecter, superviser l’évaluation pilote et assumer la responsabilité du processus d’examen continu de l’exactitude.

Informatique et sécurité de l’information : Cette équipe doit évaluer la faisabilité de l’intégration technique, l’architecture de sécurité et la compatibilité avec l’infrastructure existante avant toute décision d’achat.

Conseiller juridique : Le conseiller juridique doit examiner les contrats fournisseurs, y compris l’ATD, et évaluer la position de responsabilité de la municipalité au titre du RDM, de la législation IA et du droit national applicable.

Finance et approvisionnement : Cette fonction doit s’assurer que le processus d’achat respecte les règles applicables en matière de marchés publics, ce qui, dans les États membres de l’UE, implique généralement la conformité à la directive sur les marchés publics pour les contrats dépassant les seuils.

Représentants du personnel clinique : Le personnel doit être impliqué dans la définition des exigences et la conception du projet pilote. L’évaluation de l’OMS/Europe identifie l’engagement des parties prenantes comme un facteur clé de réussite de l’adoption de l’IA au niveau du système. Cela s’applique également au niveau du programme.

Le dossier d’affaires pour l’approbation doit aborder :

• Réduction quantifiée de la charge de documentation pour le personnel infirmier et de santé communautaire

• Rétention du personnel et réduction de l’épuisement professionnel comme argument pour la durabilité de la main-d’œuvre

• Conformité réglementaire comme obligation de gestion des risques, et non comme simple amélioration

• Coûts de déploiement incluant la formation, l’intégration et la gouvernance continue

• Risques de l’inaction, y compris la charge de documentation persistante et l’attrition du personnel associée

L’initiative AICare@EU de l’UE et le financement EU4Health peuvent offrir des possibilités de cofinancement pour les municipalités des États membres. Les administrateurs doivent vérifier les critères d’éligibilité en vigueur dans le cadre de l’évaluation financière.

Une liste de contrôle avant le déploiement pour les administrateurs de santé municipaux

La liste de contrôle suivante rassemble les questions d’évaluation clés de chaque section de ce guide. Elle est conçue comme une référence pratique pour les administrateurs passant de l’évaluation à la décision d’achat.

Classification réglementaire

• Le fournisseur a-t-il fourni une déclaration écrite de l’usage prévu ?

• La classification RDM a-t-elle été déterminée, et la base de cette classification est-elle documentée ?

• Si l’outil est marqué CE, le certificat actuel est-il disponible et en cours de validité ?

• La classification de l’outil au titre de la législation européenne sur l’IA a-t-elle été évaluée ?

RGPD et gouvernance des données

• Une AIPD a-t-elle été initiée et confiée au DPD ?

• Un ATD conforme est-il en place ou prêt à être signé avant la mise en service ?

• Le fournisseur a-t-il confirmé l’hébergement des données au sein de l’UE/EEE pour le stockage et le traitement ?

• Une liste complète des sous-traitants a-t-elle été obtenue et examinée ?

• Une cartographie du flux de données est-elle complète et validée ?

Sécurité

• Le fournisseur détient-il une certification ISO 27001 actuelle, et son périmètre couvre-t-il les systèmes concernés ?

• Les contrôles d’accès, la disponibilité des journaux d’audit et les délais de notification de violation ont-ils été confirmés par écrit ?

• Le fournisseur a-t-il communiqué son calendrier de tests d’intrusion et partagé les résultats ?

• Les exigences du cadre national de sécurité des données de santé sont-elles évaluées et respectées ?

Adéquation au flux de travail

• L’outil a-t-il été testé ou déployé dans des contextes de santé communautaire, de visites à domicile ou de santé scolaire ?

• Des données de performance sont-elles disponibles spécifiquement pour ces contextes ?

• L’outil fonctionne-t-il dans des conditions de faible connectivité ou hors ligne ?

• Les modèles de notes et la sortie structurée sont-ils adaptés aux types de rencontres de la municipalité ?

Préparation du personnel

• Un programme de formation adapté à la main-d’œuvre concernée (infirmiers, visiteurs de santé, travailleurs de santé communautaire) est-il en place ?

• La responsabilité de l’exactitude des notes est-elle clairement communiquée et documentée ?

• Un plan de gestion du changement, incluant des responsables cliniques et des mécanismes de retour d’information, est-il en place ?

Qualité des comptes rendus médicaux

• Les seuils d’acceptation pour l’exactitude sont-ils définis avant le début du projet pilote ?

• Un plan de projet pilote structuré, incluant un examen indépendant des notes, est-il en place ?

• Un processus d’examen continu de la qualité est-il intégré au cadre de gouvernance ?

Langue et diversité de la population

• L’outil a-t-il été validé dans les langues et dialectes présents dans la population de la municipalité ?

• L’exactitude a-t-elle été testée avec du personnel et des patients représentatifs de la population réelle ?

• La gestion des consultations par interprète est-elle documentée et évaluée ?

Système de dossiers médicaux et intégration informatique

• La compatibilité du système de dossiers médicaux est-elle confirmée, et le mécanisme d’intégration est-il documenté ?

• Une évaluation technique des contraintes des systèmes existants a-t-elle été réalisée ?

• La compatibilité FHIR/HL7 est-elle confirmée lorsque pertinente pour l’échange de données transfrontalier ?

Gouvernance interne et approvisionnement

• Toutes les parties prenantes internes requises (DPD, gouvernance clinique, informatique, juridique, finance) ont-elles été mobilisées ?

• Le processus d’achat est-il conforme aux règles applicables en matière de marchés publics ?

• Le dossier d’affaires a-t-il été préparé, abordant à la fois les gains d’efficacité et les obligations de gestion des risques ?

Ce cadre structure la complexité du déploiement de l’assistance IA à la documentation dans les contextes municipaux de santé communautaire en questions évaluables et séquencées que les administrateurs peuvent traiter de manière systématique. L’environnement réglementaire couvrant le RDM, le RGPD et la législation européenne sur l’IA est particulièrement exigeant, et les données probantes de la Région européenne de l’OMS indiquent que les systèmes de santé, à tous les niveaux, développent encore leur capacité de gouvernance pour s’y adapter. Commencer par un cadre clair, plutôt que par une approche centrée sur la technologie, est le chemin le plus fiable vers un déploiement à la fois juridiquement solide et réellement utile au personnel et aux communautés qu’il est destiné à servir.

Foire aux questions

▶ Pourquoi les programmes municipaux de santé communautaire ont-ils besoin d’un cadre d’évaluation distinct pour les outils de documentation IA ?

La plupart des données probantes concernant les outils de documentation IA proviennent d’hôpitaux et de cabinets de médecins généralistes, qui disposent de salles de consultation fixes, d’une infrastructure informatique dédiée et de temps réservé à la documentation. La prestation municipale de soins de santé communautaire est généralement assurée par des infirmiers, répartie dans des lieux dispersés et organisée autour de rencontres brèves et informelles telles que les visites à domicile et les examens de santé scolaire. Le personnel se déplace entre les sites, la connectivité est intermittente et la même personne agit souvent à la fois comme clinicien, coordinateur de soins et gestionnaire de cas. Un outil validé en milieu hospitalier ne peut être présumé fonctionner de manière appropriée dans ce contexte, d’où la nécessité d’un cadre d’évaluation adapté.

▶ Que fait réellement un assistant médical IA dans un contexte de santé communautaire ?

Un assistant médical IA écoute une conversation clinique, convertit le contenu oral en texte à l’aide de la technologie de reconnaissance vocale (reconnaissance automatique de la parole) et génère un compte rendu médical ou une synthèse structurée à partir de cette transcription. Il n’interprète pas les résultats cliniques, ne suggère pas de diagnostics, ne recommande pas de traitements et ne signale pas de risques cliniques. Ces fonctions relèvent de l’aide à la décision médicale, qui implique des obligations réglementaires différentes. Un test pratique : si le retrait de la sortie de l’outil ne modifie pas le jugement du clinicien, il fonctionne comme un assistant de documentation. Si la sortie influence ce que le clinicien décide de faire ensuite, il fonctionne comme une aide à la décision médicale.

▶ Comment le règlement européen sur les dispositifs médicaux (RDM) s’applique-t-il aux outils de documentation IA en santé municipale ?

La question centrale au titre du règlement sur les dispositifs médicaux (Règlement 2017/745) est de savoir si l’outil est destiné au diagnostic, à la prévention, à la surveillance, au traitement ou au soulagement d’une maladie. Un outil qui se limite à capturer et structurer des conversations cliniques, sans interpréter leur contenu, se situe généralement hors du champ d’application du RDM. Un outil qui génère des recommandations cliniques, des scores de risque ou des suggestions de diagnostic y est soumis. Lorsqu’un outil est classé comme dispositif médical, le fabricant doit détenir le marquage CE, réaliser une évaluation de conformité et respecter les obligations de documentation technique et de surveillance post-commercialisation. Les administrateurs doivent demander une déclaration écrite de l’usage prévu et la confirmation de la classification RDM à tout fournisseur avant l’achat.

▶ Quelles obligations du RGPD s’appliquent lorsqu’une municipalité utilise un assistant médical IA pour traiter des données de patients ?

Un assistant médical IA traite des données personnelles de catégorie spéciale au sens du Règlement général sur la protection des données (RGPD), en particulier des données de santé concernant des personnes identifiables. Cela déclenche le niveau le plus strict d’obligations RGPD. Les municipalités, en tant que responsables du traitement, doivent confirmer une base légale pour le traitement, généralement l’article 9(2)(h) combiné à l’article 6(1)(e) pour mission d’intérêt public. Un accord de traitement des données conforme à l’article 28 du RGPD doit être en place avant tout traitement. Les administrateurs doivent également confirmer que les données des patients sont stockées et traitées au sein de l’UE ou de l’Espace économique européen, obtenir une liste complète des sous-traitants et de leurs emplacements, et documenter les politiques de conservation et de suppression des données.

▶ Quelles certifications et contrôles de sécurité les administrateurs devraient-ils exiger des fournisseurs de documentation IA ?

ISO 27001 est la certification de base à exiger. Elle atteste que le fournisseur a mis en place un système de gestion de la sécurité de l’information audité de manière indépendante. Au-delà de cela, les administrateurs doivent obtenir la confirmation écrite que les données des patients sont chiffrées en transit et au repos, que l’accès aux données des patients au sein de l’organisation du fournisseur est contrôlé et tracé, que le fournisseur peut respecter l’exigence RGPD de notifier les autorités de contrôle dans les 72 heures suivant une violation, et que des tests d’intrusion indépendants sont réalisés régulièrement. Les cadres nationaux de sécurité des données de santé, tels que ceux mis en place par les agences de cybersécurité en France, en Allemagne ou aux Pays-Bas, peuvent imposer des exigences supplémentaires à l’ISO 27001.

▶ Pourquoi un outil de documentation IA validé en hôpital pourrait-il fonctionner différemment dans les contextes de santé communautaire ?

La prestation de soins de santé communautaire présente des caractéristiques de flux de travail qui n’existent pas dans les contextes hospitaliers ou de médecine générale. Les visites à domicile et les examens de santé scolaire impliquent des environnements acoustiques variables, un accès Internet peu fiable et des conversations plus courtes et moins structurées que les rendez-vous hospitaliers. Le personnel exerce fréquemment des fonctions cliniques, sociales et de santé publique au cours d’une même rencontre. Les appareils partagés ou personnels soulèvent des questions de sécurité supplémentaires que les appareils hospitaliers fixes ne posent pas. Les administrateurs doivent demander spécifiquement aux fournisseurs si l’outil a été testé dans des contextes de santé communautaire, de visites à domicile ou de santé scolaire, et exiger des données de performance issues de ces contextes plutôt que d’environnements hospitaliers.

▶ Qui est responsable de l’exactitude des comptes rendus médicaux générés par l’IA dans un service de santé communautaire dirigé par des infirmiers ?

Le clinicien ayant mené la rencontre conserve l’entière responsabilité professionnelle et juridique de l’exactitude de tout compte rendu médical généré par l’IA. Le compte rendu généré par l’IA est un brouillon à relire par le clinicien, et non un dossier final. Cela doit être clairement communiqué à tout le personnel avant le déploiement et intégré dans les supports de formation. Une enquête transversale auprès de professionnels de santé a montré que la familiarité avec les outils d’IA et la connaissance des politiques institutionnelles étaient faibles, même lorsque des outils étaient disponibles. La formation technique sur le fonctionnement de l’outil est nécessaire, mais le personnel doit également bénéficier d’un accompagnement pour développer le jugement critique nécessaire afin d’identifier quand un compte rendu généré par l’IA ne reflète pas fidèlement ce qui s’est passé lors de la consultation.

▶ Comment les administrateurs devraient-ils évaluer l’exactitude de l’outil de documentation IA avant de le déployer dans un programme de santé communautaire ?

Les administrateurs doivent définir à l’avance ce à quoi ressemble une note satisfaisante pour chaque type de rencontre dans leur programme, y compris les champs à renseigner et les omissions qui constitueraient une erreur substantielle. Un projet pilote à durée limitée, avec un groupe défini de personnel et de types de rencontres, doit ensuite être mené, avec un examen indépendant des notes générées par l’IA par rapport aux notes rédigées par les cliniciens ou au rappel des cliniciens, et un enregistrement structuré des erreurs, omissions et hallucinations (cas où l’IA génère du contenu non exprimé). Les seuils d’acceptation pour l’exactitude doivent être définis avant le début du projet pilote, et non après. Un examen continu de la qualité d’un échantillon de notes générées par l’IA, mené par un responsable de la gouvernance clinique, doit être intégré au cadre de gouvernance du programme dès le départ.

▶ Comment les administrateurs devraient-ils évaluer si un outil de documentation IA peut servir des populations de santé communautaire linguistiquement diverses ?

Les programmes municipaux de santé communautaire desservent fréquemment des populations aux langues, dialectes et modes de communication variés, en particulier dans les zones urbaines avec d’importantes communautés de migrants ou de réfugiés. Les outils de documentation IA performants en néerlandais, allemand ou anglais standard peuvent être nettement moins efficaces avec la parole accentuée, les dialectes régionaux ou les consultations menées par l’intermédiaire d’un interprète. Les administrateurs doivent demander aux fournisseurs dans quelles langues et variantes linguistiques l’outil a été validé, quel est le différentiel d’exactitude documenté entre la parole standard et non standard, et comment les consultations par interprète sont gérées. Les tests doivent inclure du personnel et des patients représentatifs de la population réelle de la municipalité, et pas seulement du groupe linguistique majoritaire.

▶ Quelles parties prenantes internes doivent être impliquées dans l’approvisionnement d’un assistant médical IA pour un programme de santé municipal ?

Le délégué à la protection des données doit être impliqué dès le début et mener ou superviser une analyse d’impact relative à la protection des données, obligatoire au titre de l’article 35 du RGPD lorsque l’IA traite des données de santé à grande échelle. Un responsable de la gouvernance clinique doit définir les normes de qualité, superviser le projet pilote et assumer la responsabilité de l’examen continu de l’exactitude. Les équipes informatiques et de sécurité de l’information doivent évaluer l’intégration technique et la compatibilité de l’infrastructure. Le conseiller juridique doit examiner les contrats fournisseurs et la position de responsabilité de la municipalité au titre du règlement sur les dispositifs médicaux, de la législation européenne sur l’IA et du droit national applicable. Les finances et l’approvisionnement doivent garantir la conformité avec les règles en matière de marchés publics. Les représentants du personnel clinique doivent être impliqués dans la définition des exigences et la conception du projet pilote dès le début.