Signer un contrat pour un outil d'IA peut sembler marquer la fin d'un processus d'approvisionnement, mais pour les gestionnaires de cabinets de médecins généralistes, il s'agit plutôt du coup d'envoi. Une fois le contrat signé et l'outil déployé, les obligations cliniques, juridiques et réglementaires liées à ce déploiement incombent entièrement au cabinet, et non au fournisseur. Le déploiement de l'IA va bien au-delà d'une évaluation rigoureuse en conditions réelles et de la réglementation, ce qui crée un risque réel pour les cabinets n'ayant pas effectué une vérification préalable approfondie. Ce guide présente les questions spécifiques que les gestionnaires de cabinets devraient poser, ainsi que les documents à examiner, avant la signature de tout contrat.

L'outil est-il classé comme dispositif médical, et qu'est-ce que cela implique pour vous ?

Tous les outils d'IA utilisés en milieu clinique ne sont pas des dispositifs médicaux, mais beaucoup le sont. Cette distinction a un poids réglementaire important. Au Royaume-Uni, la Medicines and Healthcare products Regulatory Agency (MHRA) classe certains logiciels comme dispositifs médicaux. Si un outil d'IA soutient le diagnostic clinique, les décisions de tri ou les recommandations de traitement, il relève probablement de la définition de Software as a Medical Device (SaMD) et nécessitera un marquage UKCA ou CE en vertu du RDM UE (Medical Device Regulation).

Avant de signer, les gestionnaires de cabinets devraient :

• Consulter la base de données MHRA Product and Registration Database (PARD) pour confirmer si l'outil est enregistré comme dispositif médical

• Demander directement au fournisseur son statut d'enregistrement MHRA et la classe de son dispositif

• Vérifier si l'outil a fait l'objet d'une évaluation NICE, d'un Medtech Innovation Briefing (MIB), d'une Diagnostics Guidance (DG) ou d'une Early Value Assessment (EVA)

• Confirmer si l'outil porte un marquage UKCA ou CE valide s'il est classé comme dispositif médical

Le GP Mythbuster 109 de la CQC sur l'IA, publié en juillet 2025, précise que les inspecteurs vérifieront si les cabinets ont confirmé l'enregistrement MHRA le cas échéant et si l'approvisionnement a été effectué conformément aux normes DCB0160 et Digital Technology Assessment Criteria (DTAC). Les outils qui ne sont pas classés comme dispositifs médicaux ne sont pas exempts de contrôle. Ils comportent toujours des obligations en matière de protection des données, de sécurité clinique et de gouvernance.

Qui détient la responsabilité clinique et juridique en cas de problème ?

C'est l'une des questions les plus importantes dans tout contrat d'outil d'IA. Les accords avec les fournisseurs la rendent fréquemment floue. La position générale dans les soins primaires du NHS est que les organisations du NHS peuvent toujours être tenues responsables des réclamations liées à l'IA, même lors de l'utilisation d'outils tiers. La responsabilité de l'utilisation d'une solution d'IA non conforme incombe à l'organisation déployante ou au clinicien individuel.

Les fournisseurs limitent généralement leur responsabilité au fonctionnement du logiciel tel que décrit dans le contrat. Ils n'acceptent pas la responsabilité des décisions cliniques prises sur la base des résultats de l'IA. Si une note médicale générée par IA contient une erreur qui influence les soins aux patients, le cabinet, et non le fournisseur, est susceptible d'en supporter les conséquences cliniques et juridiques.

Lors de l'examen des conditions contractuelles, les gestionnaires de cabinets devraient rechercher :

• Des déclarations claires sur l'attribution de la responsabilité clinique, et si le fournisseur accepte une quelconque responsabilité pour les résultats générés par l'IA qui entrent dans le dossier patient

• Les clauses d'indemnisation et si l'indemnisation du fournisseur couvre les incidents cliniques ou se limite aux défaillances de performance du logiciel

• Si les conditions du fournisseur exigent que le cabinet maintienne une supervision humaine de tous les résultats de l'IA, et quelle documentation de cette supervision est attendue

• Si l'organisation de défense médicale ou le fournisseur d'indemnisation du cabinet a été consulté au sujet de l'utilisation de l'outil

Surrey & Sussex LMCs conseillent aux cabinets de s'engager auprès de leur Integrated Care Board (ICB) pour obtenir des garanties et de s'assurer que tous les résultats générés par l'IA sont vérifiés par un clinicien avant d'entrer dans le dossier patient. Cette exigence d'intervention humaine n'est pas simplement une bonne pratique : c'est une condition de déploiement sûr selon les directives actuelles du NHS.

Où les données des patients sont-elles traitées et stockées ?

L'hébergement des données est une question fondamentale dans tout approvisionnement d'IA clinique. Les réponses des fournisseurs ne sont pas toujours claires. En vertu du Règlement général sur la protection des données (RGPD) du Royaume-Uni et du devoir de confidentialité de common law, les données des patients sont des données de catégorie spéciale. Leur traitement doit être licite, transparent et proportionné. Si les données des patients, y compris les enregistrements audio des consultations, sont transférées en dehors du Royaume-Uni ou de l'UE pour traitement ou stockage, des garanties supplémentaires sont requises.

Les directives du NHS England sur les produits de scribe médical IA confirment qu'une analyse d'impact relative à la protection des données (DPIA) est très probablement une exigence légale avant le déploiement, compte tenu du traitement à grande échelle de données de santé de catégorie spéciale impliqué. Les directives de gouvernance de l'information du NHS Transformation Directorate renforcent cela, notant que les DPIA doivent traiter les types de données traitées (y compris l'audio et les transcriptions), la réutilisation des données par le fournisseur pour l'entraînement de modèles d'IA, et les obligations de transparence envers les patients.

Questions clés à poser aux fournisseurs avant de signer :

• Où les données des patients sont-elles traitées ? Au Royaume-Uni, dans l'UE ou dans un pays tiers ?

• Qui sont les sous-traitants du fournisseur, et où sont-ils situés ?

• Le fournisseur utilise-t-il les données de consultation des patients pour entraîner ou améliorer ses modèles d'IA, et si oui, sur quelle base juridique ?

• Un accord de traitement des données (DPA) est-il inclus dans le contrat, et est-il conforme à l'article 28 du RGPD du Royaume-Uni ?

• Quelle est la distinction entre données anonymisées et pseudonymisées dans le traitement du fournisseur, et quel est le risque résiduel de réidentification ?

Le commentaire juridique de Spencer West LLP note que la distinction entre données anonymisées et pseudonymisées est particulièrement importante ici, car les données pseudonymisées conservent un risque résiduel de réidentification et ne peuvent pas être considérées comme hors du champ d'application de la loi sur la protection des données.

Quelles certifications de sécurité le fournisseur devrait-il détenir ?

Les certifications de sécurité ne sont pas une garantie de sécurité, mais leur absence est un signal significatif sur la maturité d'un fournisseur et son investissement dans la protection des données. Pour les outils d'IA cliniques utilisés dans les soins primaires du NHS, il existe un socle de certifications et d'évaluations qu'un fournisseur crédible devrait pouvoir démontrer.

Les cabinets devraient s'attendre à ce que les fournisseurs détiennent ou travaillent activement à obtenir :

• ISO 27001 (la norme internationale pour les systèmes de gestion de la sécurité de l'information)

• Conformité au NHS Data Security and Protection (DSP) Toolkit (le cadre propre au NHS pour évaluer la sécurité des données, qui est une exigence contractuelle pour les organisations accédant aux données des patients du NHS)

• Cyber Essentials ou Cyber Essentials Plus (la certification de cybersécurité de base du gouvernement britannique)

• Conformité DTAC (le cadre du NHS England couvrant la protection des données, la sécurité technique, l'interopérabilité et la sécurité clinique)

Le guide d'approvisionnement iatroX pour les acheteurs du NHS recommande que les cabinets s'assurent qu'un fournisseur a réussi l'évaluation DTAC avant le déploiement. Les directives du NHS England sur le scribe médical IA signalent également des risques de cybersécurité spécifiques aux grands modèles de langage (LLM), notamment le potentiel d'attaques par injection de prompt et de fuite de données via les résultats du modèle.

Un fournisseur qui ne peut pas produire de preuve de ces certifications, ou qui ne peut pas fournir une soumission actuelle au DSP Toolkit, doit être traité avec prudence, quelle que soit la qualité de sa démonstration de produit.

Comment l'outil s'intègre-t-il à votre système de dossiers médicaux existant ?

La plupart des cabinets de médecins généralistes en Angleterre utilisent soit EMIS Web, soit SystmOne comme système de dossiers médicaux principal. La valeur pratique d'un outil d'IA, en particulier d'un assistant médical IA ou assistant de documentation, dépend fortement de la qualité de son intégration avec le système existant du cabinet. Une intégration qui nécessite un copier-coller manuel du contenu généré par l'IA dans le dossier médical augmente considérablement le risque d'erreurs de transcription et supprime une grande partie du gain d'efficacité.

Avant de signer, les gestionnaires de cabinets devraient établir :

• Si l'outil dispose d'une intégration native et certifiée avec EMIS Web ou SystmOne, ou s'il repose sur une solution de contournement

• Qui est responsable du maintien de l'intégration lorsque le fournisseur du système de dossiers médicaux publie des mises à jour : le fournisseur de l'IA, le fournisseur du système ou le cabinet

• Si l'intégration a été testée dans un environnement de médecin généraliste en conditions réelles, et pas seulement dans un environnement de développement ou de soins secondaires

• Quel est le processus de secours si l'intégration échoue pendant une session clinique

Le guide iatroX des outils d'IA pour les cabinets de médecins généralistes britanniques met en avant l'intégration au système de dossiers médicaux comme l'un des principaux critères d'évaluation pour les assistants médicaux IA, notant que les décisions d'approvisionnement devraient tenir compte du coût total de possession, y compris l'adaptation des flux de travail requise lorsque l'intégration est imparfaite. Les défaillances d'intégration ne sont pas qu'un simple désagrément technique : dans un contexte clinique, elles peuvent créer des lacunes dans le dossier patient ou introduire des erreurs ayant des implications pour la sécurité des patients.

Qu'advient-il de vos données si vous mettez fin au contrat ?

La portabilité et la suppression des données à la fin du contrat sont des domaines où les contrats des fournisseurs sont fréquemment vagues. Les cabinets peuvent se retrouver dans une situation difficile s'ils n'ont pas négocié des conditions claires à l'avance. Les questions à résoudre avant de signer sont :

• Combien de temps le fournisseur conserve-t-il les données des patients après la fin du contrat, et sur quelle base juridique ?

• Le cabinet peut-il exporter une copie complète de toutes les données des patients détenues par le fournisseur avant la fin du contrat ?

• Que signifie réellement « suppression sur demande » ? Cela couvre-t-il toutes les copies, y compris les sauvegardes et les données des sous-traitants ?

• Quel est le délai pour une suppression confirmée, et le fournisseur fournira-t-il une confirmation écrite ?

En vertu du RGPD du Royaume-Uni, les personnes concernées disposent de droits, notamment le droit à l'effacement. Le cabinet, en tant que responsable du traitement des données, est chargé de s'assurer que ces droits peuvent être exercés même après la fin d'une relation avec un fournisseur. La confidentialité et la sécurité tout au long du cycle de vie des données de santé est un domaine de surveillance réglementaire croissant. Les cabinets qui ne peuvent pas rendre compte de l'endroit où sont allées les données des patients après la fin d'un contrat avec un fournisseur peuvent s'exposer à des risques de non-conformité.

Les conditions contractuelles qui permettent aux fournisseurs de conserver les données pendant des périodes prolongées après la fin du contrat à des fins « d'amélioration du produit » ou « d'entraînement du modèle » devraient être signalées pour examen juridique avant la signature.

L'outil d'IA est-il entraîné sur des données cliniques du NHS ou équivalentes ?

Les données d'entraînement utilisées pour développer un outil d'IA ont une incidence directe sur sa précision clinique dans un contexte de soins primaires britanniques. Un outil entraîné principalement sur des données cliniques américaines, par exemple, peut mal fonctionner sur le codage médical spécifique au Royaume-Uni (SNOMED CT tel qu'utilisé dans le NHS), les noms de médicaments et les conventions de dosage, les parcours d'adressage, ou le style de documentation particulier des consultations de médecins généralistes.

Les perspectives des cliniciens sur l'IA dans les soins primaires soulèvent systématiquement des préoccupations concernant les biais introduits par les données d'entraînement. Laranjo et al. dans le Lancet Primary Care ont noté que le déploiement rapide avant une évaluation rigoureuse soulève des inquiétudes quant aux conséquences imprévues sur la qualité des soins. Ce ne sont pas des risques abstraits : ils se traduisent directement par la précision des notes médicales, la pertinence des codes cliniques suggérés et la fiabilité de tout résultat d'aide à la décision.

Lors de l'évaluation des affirmations d'un fournisseur concernant les données d'entraînement, les gestionnaires de cabinets devraient demander :

• Le modèle a-t-il été entraîné sur des données du NHS ou de soins primaires britanniques, et le fournisseur peut-il fournir une documentation à ce sujet ?

• Le modèle a-t-il été validé spécifiquement sur des données de consultation de médecins généralistes britanniques ?

• Le fournisseur publie-t-il une fiche de modèle ou une documentation technique équivalente décrivant les sources de données d'entraînement, les limitations connues et les références de performance ?

• Comment le modèle gère-t-il la terminologie clinique spécifique au Royaume-Uni, les noms de médicaments et les conventions d'adressage ?

Les fournisseurs devraient pouvoir répondre à ces questions avec des preuves documentées, et non de simples affirmations marketing. Lorsqu'un fournisseur ne peut pas fournir ces informations, cela constitue une lacune significative dans sa base de preuves cliniques.

Qui dans le cabinet est responsable de la supervision de l'outil ?

La gouvernance des outils d'IA n'est pas une décision d'approvisionnement ponctuelle. C'est une responsabilité opérationnelle continue. Le GP Mythbuster 109 de la CQC définit ce que les inspecteurs rechercheront, notamment la nomination d'un responsable de la sécurité clinique (CSO), le maintien d'une évaluation des risques et d'un registre des dangers, et la preuve que la supervision humaine des résultats de l'IA est intégrée dans les flux de travail du cabinet.

L'exigence de nommer un CSO au niveau du cabinet est une attente que Surrey & Sussex LMCs reconnaissent comme un défi pratique pour les petits cabinets. C'est une obligation réglementaire, pas une amélioration facultative. Le CSO n'a pas besoin d'être un poste à temps plein, mais le cabinet doit pouvoir identifier une personne nommée qui détient cette responsabilité et peut démontrer qu'elle l'assume.

La documentation de gouvernance que le cabinet devrait maintenir comprend :

• Un dossier de sécurité clinique DCB0160 complété pour le déploiement de l'outil

• Une évaluation des risques et un registre des dangers, examinés régulièrement et mis à jour lorsque l'outil évolue

• Des registres de formation des cliniciens sur l'outil, y compris la sensibilisation à ses limitations

• Un journal de tous les incidents ou quasi-accidents impliquant des résultats générés par l'IA

• La preuve que tout contenu généré par l'IA entrant dans le dossier patient a été examiné par un clinicien

Cette documentation n'est pas seulement pertinente pour l'inspection de la CQC : elle constitue la base de preuves qui protège le cabinet si un incident clinique survient et que des questions sont soulevées sur la manière dont l'outil a été déployé et supervisé.

À quoi ressemblent le support et la réponse aux incidents du fournisseur ?

Un accord de niveau de service (SLA) est un composant standard de tout contrat logiciel, mais pour les outils d'IA cliniques, les enjeux d'une défaillance du support sont plus élevés que pour la plupart des logiciels. Si un assistant médical IA échoue en pleine consultation, ou si une note générée par l'IA contient une erreur systématique qui n'est pas détectée immédiatement, le cabinet doit savoir que le fournisseur répondra rapidement et avec une compréhension clinique.

Avant de signer, les gestionnaires de cabinets devraient examiner :

• Les délais de réponse et de résolution dans le SLA, et si ceux-ci différencient les incidents de sécurité clinique des problèmes techniques généraux

• Si le fournisseur dispose d'un contact dédié pour les cabinets de médecins généralistes, ou si le support est acheminé via un service d'assistance générique

• Quel est le processus du fournisseur pour notifier les cabinets d'un incident de sécurité clinique, y compris la rapidité avec laquelle ils communiqueront et quelles informations seront fournies

• Si le fournisseur dispose d'un processus documenté de signalement des incidents de sécurité clinique conforme aux normes du NHS

Les directives du NHS England sur le scribe médical IA exigent que les arrangements contractuels définissent clairement les rôles, les responsabilités et la responsabilité, y compris la réponse aux incidents. Un fournisseur qui ne peut pas présenter un processus clair de gestion des incidents de sécurité clinique n'est pas prêt pour un déploiement dans un contexte de soins primaires.

L'outil a-t-il été évalué dans un véritable contexte de soins primaires ?

C'est une question à laquelle de nombreux fournisseurs ont du mal à répondre avec des preuves solides. L'écart entre une démonstration convaincante et une évaluation par les pairs dans un environnement de médecin généraliste en conditions réelles est significatif. La recherche sur les scribes médicaux IA dans les soins primaires a commencé à documenter les expériences des professionnels et les préoccupations éthiques dans des contextes réels, mais la base de preuves reste limitée et largement exploratoire.

L'examen de Frontiers in Health Services des cadres d'approvisionnement IA du NHS recommande que la documentation de conformité du fournisseur inclue des preuves cliniques, et pas seulement des certifications techniques. Les gestionnaires de cabinets devraient demander aux fournisseurs de fournir :

• Des études publiées et évaluées par des pairs ou des résultats de pilotes documentés provenant d'environnements de médecins généralistes ou de soins primaires

• Des études de cas provenant de contextes de soins primaires britanniques avec des résultats mesurables (temps de documentation, précision clinique, satisfaction des cliniciens)

• Des preuves d'évaluation par rapport aux flux de travail spécifiques au NHS et aux systèmes de dossiers médicaux

• Toutes les limitations connues ou modes de défaillance identifiés lors des tests en conditions réelles

Les preuves provenant de soins secondaires ou de contextes de soins primaires internationaux ne se transfèrent pas directement à la pratique générale britannique. Les structures de consultation, les conventions de documentation et les exigences réglementaires diffèrent sensiblement. Un outil qui fonctionne bien dans un contexte de consultation externe hospitalière ou de soins primaires américains peut ne pas fonctionner de manière équivalente dans un cabinet de médecin généraliste britannique.

Il existe également une lacune de preuves plus large à reconnaître. Comme Laranjo et al. dans le Lancet le notent, le déploiement de l'IA dans les soins primaires dépasse actuellement l'évaluation rigoureuse nécessaire pour comprendre son impact réel. Cela ne signifie pas que les cabinets devraient éviter les outils d'IA, mais les affirmations des fournisseurs doivent être examinées attentivement et la surveillance post-déploiement est essentielle.

Une liste de vérification pré-signature pour les gestionnaires de cabinets de médecins généralistes

La liste de vérification suivante consolide les principaux points abordés dans cet article. Utilisez-la comme référence pratique avant la signature de tout contrat d'outil d'IA.

Réglementation et sécurité clinique

• [ ] Statut d'enregistrement MHRA et classe de dispositif confirmés (vérifier PARD le cas échéant)

• [ ] Le fournisseur détient la documentation du dossier de sécurité clinique DCB0129

• [ ] Le cabinet a complété ou commencé le dossier de sécurité clinique DCB0160 pour le déploiement

• [ ] Évaluation DTAC complétée et réussie par le fournisseur

• [ ] Évaluation NICE vérifiée (MIB, DG ou EVA) le cas échéant

Protection des données et gouvernance de l'information

• [ ] DPIA complétée avant le déploiement

• [ ] Accord de traitement des données inclus dans le contrat, conforme à l'article 28 du RGPD du Royaume-Uni

• [ ] Hébergement des données confirmé (traitement et stockage au Royaume-Uni ou dans l'UE)

• [ ] Sous-traitants identifiés et évalués

• [ ] Politique du fournisseur sur l'utilisation des données des patients pour l'entraînement de modèles examinée et acceptée

• [ ] Conditions de suppression et de portabilité des données confirmées à la fin du contrat

Sécurité

• [ ] Certification ISO 27001 confirmée

• [ ] Conformité au NHS DSP Toolkit confirmée

• [ ] Cyber Essentials ou Cyber Essentials Plus confirmé

• [ ] Section cybersécurité DTAC réussie

Responsabilité et contrat

• [ ] Attribution de responsabilité clairement définie dans le contrat

• [ ] Clauses d'indemnisation examinées (portée confirmée)

• [ ] Organisation de défense médicale ou fournisseur d'indemnisation consulté

• [ ] Rôles, responsabilités et réponse aux incidents définis dans le contrat

Intégration du système de dossiers médicaux

• [ ] Intégration native avec EMIS Web ou SystmOne confirmée

• [ ] Responsabilité de maintenance de l'intégration définie

• [ ] Testé dans un environnement de médecin généraliste britannique en conditions réelles

Gouvernance

• [ ] Responsable de la sécurité clinique nommé au niveau du cabinet

• [ ] Évaluation des risques et registre des dangers initiés

• [ ] Plan de formation des cliniciens en place

• [ ] Examen humain de tous les résultats de l'IA confirmé comme exigence du flux de travail

Preuves et support

• [ ] Preuves cliniques provenant de contextes de soins primaires britanniques examinées

• [ ] SLA examiné (délais de réponse aux incidents de sécurité clinique confirmés)

• [ ] Contact dédié du fournisseur pour les cabinets de médecins généralistes confirmé

• [ ] Origine des données d'entraînement documentée par le fournisseur

Signer en toute confiance, pas seulement rapidement

L'approvisionnement en IA dans la pratique générale est une décision de gouvernance clinique autant qu'opérationnelle. Les outils disponibles en 2025 et 2026 offrent un potentiel réel pour réduire la charge documentaire et soutenir les cliniciens, mais ce potentiel n'est réalisé en toute sécurité que lorsque le cabinet a vérifié la conformité réglementaire, les obligations de protection des données, l'attribution des responsabilités et les preuves cliniques avant le début du déploiement.

Le reportage de Digital Health sur l'approvisionnement en IA du NHS illustre bien la réalité réglementaire actuelle : les normes existantes n'ont pas été conçues pour les systèmes d'IA évolutifs, et le rythme de l'activité des fournisseurs dans les soins primaires signifie que les cabinets doivent être, selon les mots du Chief Clinical Information Officer national du NHS England, « rigoureux pour s'assurer que ce que nous faisons est sûr, assuré et va apporter des bénéfices ».

Les questions et vérifications de cet article ne sont pas des obstacles à l'adoption. Elles sont le fondement sur lequel une adoption sûre, efficace et défendable se construit. Un fournisseur qui ne peut pas y répondre clairement et avec des preuves documentées n'est pas prêt à être déployé dans un contexte clinique. Un cabinet qui ne les a pas posées assume un risque dont il n'a peut-être pas encore conscience.

Questions fréquemment posées

▶ Un outil d'IA utilisé dans un cabinet de médecin généraliste doit-il être enregistré comme dispositif médical ?

Cela dépend de ce que fait l'outil. S'il soutient le diagnostic clinique, les décisions de tri ou les recommandations de traitement, il est susceptible d'être classé comme Software as a Medical Device par la Medicines and Healthcare products Regulatory Agency et nécessitera un marquage UKCA ou CE en vertu du RDM UE (Medical Device Regulation). Les gestionnaires de cabinets devraient consulter la base de données MHRA Product and Registration Database pour confirmer le statut d'enregistrement d'un outil avant de signer tout contrat. Les outils qui ne sont pas classés comme dispositifs médicaux comportent toujours des obligations en matière de protection des données, de sécurité clinique et de gouvernance.

▶ Qui est responsable si une note médicale générée par l'IA contient une erreur qui affecte les soins aux patients ?

Dans les soins primaires du NHS, la responsabilité des incidents cliniques liés à l'IA incombe généralement à l'organisation déployante ou au clinicien individuel, et non au fournisseur. Les fournisseurs limitent généralement leur responsabilité au fonctionnement du logiciel tel que décrit dans le contrat et n'acceptent pas la responsabilité des décisions cliniques prises sur la base des résultats de l'IA. Les gestionnaires de cabinets devraient examiner attentivement les clauses d'indemnisation, confirmer si leur organisation de défense médicale a été consultée, et s'assurer que tout contenu généré par l'IA est examiné par un clinicien avant d'entrer dans le dossier patient.

▶ Où les données des patients doivent-elles être traitées et stockées lors de l'utilisation d'un outil d'IA clinique ?

Les données des patients sont des données de catégorie spéciale en vertu du RGPD du Royaume-Uni et doivent être traitées de manière licite, transparente et proportionnée. Si les données sont transférées en dehors du Royaume-Uni ou de l'UE, des garanties supplémentaires sont requises. Avant de signer, les cabinets devraient confirmer où le fournisseur traite et stocke les données, qui sont ses sous-traitants, et si un accord de traitement des données conforme à l'article 28 du RGPD du Royaume-Uni est inclus dans le contrat. Le NHS England confirme qu'une analyse d'impact relative à la protection des données est très probablement une exigence légale avant le déploiement.

▶ Quelles certifications de sécurité un fournisseur d'IA clinique devrait-il détenir ?

Les fournisseurs crédibles devraient détenir ou travailler activement à obtenir ISO 27001 (la norme internationale pour la gestion de la sécurité de l'information), la conformité au NHS Data Security and Protection Toolkit, Cyber Essentials ou Cyber Essentials Plus, et la conformité aux Digital Technology Assessment Criteria. Le NHS DSP Toolkit est une exigence contractuelle pour les organisations accédant aux données des patients du NHS. Un fournisseur qui ne peut pas produire de preuve de ces certifications, ou qui ne peut pas fournir une soumission actuelle au DSP Toolkit, doit être traité avec prudence.

▶ Qu'advient-il des données des patients si un cabinet met fin à son contrat avec un fournisseur d'IA ?

C'est un domaine où les contrats des fournisseurs sont fréquemment vagues. Les cabinets devraient confirmer avant de signer combien de temps le fournisseur conserve les données des patients après la fin du contrat, si une exportation complète de toutes les données des patients est possible, et ce que couvre en pratique la « suppression sur demande », y compris les sauvegardes et les données des sous-traitants. En vertu du RGPD du Royaume-Uni, le cabinet en tant que responsable du traitement des données est chargé de s'assurer que les droits des patients, y compris le droit à l'effacement, peuvent être exercés même après la fin d'une relation avec un fournisseur. Les conditions contractuelles permettant aux fournisseurs de conserver les données pour l'entraînement de modèles après la fin du contrat devraient être signalées pour examen juridique.

▶ Est-il important qu'un outil d'IA ait été entraîné sur des données du NHS ou de soins primaires britanniques ?

Oui. Les données d'entraînement ont une incidence directe sur la précision clinique dans un contexte de soins primaires britanniques. Un outil entraîné principalement sur des données cliniques américaines peut mal fonctionner sur le codage médical spécifique au NHS utilisant SNOMED CT, les noms de médicaments et conventions de dosage britanniques, les parcours d'adressage et les styles de documentation des consultations de médecins généralistes. Les cabinets devraient demander aux fournisseurs si le modèle a été entraîné et validé sur des données de consultation de médecins généralistes britanniques, et si le fournisseur publie une fiche de modèle décrivant les sources de données d'entraînement, les limitations connues et les références de performance. Les affirmations marketing ne remplacent pas les preuves documentées.

▶ Qui dans le cabinet est responsable de la supervision d'un outil d'IA une fois déployé ?

Le GP Mythbuster 109 de la Care Quality Commission sur l'intelligence artificielle stipule que les cabinets doivent nommer un responsable de la sécurité clinique, maintenir une évaluation des risques et un registre des dangers, et intégrer la supervision humaine des résultats de l'IA dans les flux de travail cliniques. C'est une obligation réglementaire, pas une étape facultative. Les cabinets devraient également tenir un dossier de sécurité clinique DCB0160 complété, des registres de formation des cliniciens et un journal de tous les incidents impliquant des résultats générés par l'IA. Cette documentation protège le cabinet si un incident clinique survient et que des questions sont soulevées sur la manière dont l'outil a été déployé.

▶ Comment un cabinet devrait-il évaluer si un outil d'IA s'intègre correctement à son système de dossiers médicaux ?

La plupart des cabinets de médecins généralistes en Angleterre utilisent soit EMIS Web, soit SystmOne. Les cabinets devraient confirmer si l'outil dispose d'une intégration native et certifiée avec leur système plutôt qu'une solution de contournement, qui est responsable du maintien de cette intégration lorsque le fournisseur du système de dossiers médicaux publie des mises à jour, et si l'intégration a été testée dans un environnement de médecin généraliste en conditions réelles. Une intégration qui nécessite un copier-coller manuel du contenu généré par l'IA dans le dossier médical augmente le risque d'erreurs de transcription et supprime une grande partie du gain d'efficacité. Les défaillances d'intégration peuvent créer des lacunes dans le dossier patient avec des implications directes pour la sécurité des patients.

▶ Quelles preuves cliniques un fournisseur devrait-il pouvoir fournir avant qu'un cabinet ne signe un contrat ?

Les fournisseurs devraient fournir des études publiées et évaluées par des pairs ou des résultats de pilotes documentés provenant d'environnements de médecins généralistes ou de soins primaires, des études de cas issues de contextes de soins primaires britanniques avec des résultats mesurables, et des preuves d'évaluation par rapport aux flux de travail spécifiques au NHS et aux systèmes de dossiers médicaux. Les preuves provenant de soins secondaires ou de contextes de soins primaires internationaux ne se transfèrent pas directement à la pratique générale britannique. Comme des chercheurs l'ont noté dans le Lancet, le déploiement de l'IA dans les soins primaires dépasse actuellement l'évaluation rigoureuse, ce qui signifie que les affirmations des fournisseurs doivent être examinées attentivement et que la surveillance post-déploiement est essentielle.

▶ Que devrait rechercher un cabinet dans les arrangements de support et de réponse aux incidents d'un fournisseur ?

L'accord de niveau de service devrait différencier les délais de réponse et de résolution entre les incidents de sécurité clinique et les problèmes techniques généraux. Les cabinets devraient confirmer si le fournisseur dispose d'un contact dédié pour les cabinets de médecins généralistes ou achemine le support via un service d'assistance générique, et si le fournisseur dispose d'un processus documenté de signalement des incidents de sécurité clinique conforme aux normes du NHS. Les directives du NHS England sur les produits de scribe médical IA exigent que les arrangements contractuels définissent clairement les rôles, les responsabilités et la responsabilité, y compris la réponse aux incidents. Un fournisseur qui ne peut pas présenter un processus clair de gestion des incidents de sécurité clinique n'est pas prêt pour un déploiement dans un contexte de soins primaires.