Sujet 1.6 — Sécurité clinique et gestion des risques

En une phrase : La sécurité clinique est la pratique disciplinée et étayée qui consiste à trouver les façons dont votre technologie numérique pourrait nuire à un patient et à contrôler ces dangers avant qu'ils n'atteignent quiconque — la sécurité conçue dès la première esquisse, pas ajoutée avant la mise en production.

Pourquoi cela compte dans la santé et l'action sociale#

Dans la plupart des secteurs, un défaut logiciel est un inconvénient : une page ne se charge pas, une commande est dupliquée, un rapport est en retard. Dans la santé et l'action sociale, la même classe de défaut peut tuer. Un champ de médicament qui tronque une décimale, un écran de résultats qui montre le mauvais patient, un algorithme de triage qui cesse discrètement de signaler un symptôme, une intégration qui supprime silencieusement des dossiers d'allergie — chacun est un bogue logiciel, et chacun est aussi un danger clinique capable de causer un préjudice grave ou la mort. C'est pourquoi la sécurité clinique n'est pas un raffinement de qualité ajouté au-dessus d'une bonne ingénierie ; c'est une discipline distincte et réglementée avec ses propres normes, rôles, et preuves.

Les enjeux sont asymétriques et souvent invisibles. Quand un système numérique fonctionne, personne ne voit le préjudice qu'il a prévenu ; quand il échoue, le préjudice peut être catastrophique, retardé, et distribué sur des milliers de patients avant que quiconque ne remarque un motif. Cette combinaison — conséquence élevée, faible visibilité, large rayon d'impact — signifie que vous ne pouvez pas compter sur les utilisateurs pour repérer les problèmes ni sur les incidents pour tout vous enseigner. Vous devez raisonner sur le préjudice de façon proactive, avant le déploiement, et continuer à y raisonner pendant que le système est en production. Au Royaume-Uni, ce raisonnement proactif n'est pas optionnel : les organisations du NHS et leurs fournisseurs sont contractuellement et professionnellement tenus d'appliquer les normes nationales de gestion du risque clinique, et de pouvoir montrer leur travail. Bien faire cela est inséparable de la preuve (voir sujet 1.3 — Décisions fondées sur les preuves), de la gouvernance de l'information et de la cybersécurité (voir sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité), et de comment vous faites fonctionner les services une fois en production (voir sujet 3.8 — Gestion de service et opérations en production).

Concepts clés#

Sécurité des patients et gestion des risques. La sécurité des patients est la prévention, réduction, rapport, et analyse du préjudice aux patients issu des soins. La gestion du risque clinique applique la discipline générale de gestion des risques — identifier, évaluer, prioriser, et contrôler les risques — à la question spécifique de comment un système informatique de santé pourrait contribuer au préjudice patient. Les deux normes nationales qui gouvernent cela en Angleterre sont DCB0129 et DCB0160 (DCB signifie Data Coordination Board ; ce sont des normes du Standardization Committee for Care Information Standards / SCCI mandatées sous le Health and Social Care Act 2012). DCB0129 place des obligations sur le fabricant ou fournisseur d'un système informatique de santé ; DCB0160 place des obligations sur l'organisation de santé déployant et utilisant celui-ci. Elles sont complémentaires : un dossier de sécurité propre d'un fournisseur ne libère pas le devoir d'un trust déployant d'évaluer les dangers introduits par sa propre configuration, son flux de travail, et son contexte.

Le responsable de la sécurité clinique (CSO). Les deux normes exigent un responsable de la sécurité clinique nommé, dûment qualifié et expérimenté — un clinicien enregistré, actuellement en exercice, ayant complété une formation reconnue en sécurité clinique — pour posséder l'activité de gestion du risque clinique et approuver personnellement le dossier de sécurité. Le rôle de CSO est une exigence de compétence, pas un titre de poste que vous pouvez assigner à qui est disponible. Le CSO valide que les dangers ont été identifiés et contrôlés à un niveau acceptable ; c'est un jugement professionnel portant une responsabilité professionnelle.

Les artefacts de gestion du risque clinique. Trois documents ancrent la discipline. Le dossier de gestion du risque clinique est le conteneur pour toute la preuve de sécurité d'un système. Le journal des dangers est le registre vivant de chaque danger identifié, ses causes, conséquences, évaluation du risque, contrôles, et risque résiduel. Le dossier de sécurité clinique est l'argument structuré, soutenu par la preuve, que le système est raisonnablement sûr pour son usage prévu dans son contexte prévu — accompagné d'un rapport de dossier de sécurité qui résume l'argument pour approbation. Ce ne sont pas de la paperasse pour elle-même ; c'est ainsi que le raisonnement de sécurité est rendu explicite, révisable, et durable.

L'analyse des dangers : identification, analyse, évaluation, contrôle. La boucle centrale est : l'identification des dangers (imaginer systématiquement comment le système pourrait contribuer au préjudice — par des ateliers, des parcours cliniques, une analyse des modes de défaillance), l'analyse du risque (estimer la gravité du préjudice et la probabilité qu'il se produise), l'évaluation du risque (comparer le risque estimé aux critères d'acceptabilité), et le contrôle du risque (introduire des mesures — changements de conception, alertes, formation, procédures — pour réduire le risque inacceptable, puis réévaluer le risque résiduel). Le risque est réduit autant que raisonnablement praticable (ALARP) : vous continuez à contrôler jusqu'à ce qu'une réduction supplémentaire serait grossièrement disproportionnée par rapport au bénéfice obtenu.

Réglementation des dispositifs médicaux, la MHRA, et Software as a Medical Device (SaMD). Certaines technologies de santé numérique sont des dispositifs médicaux réglementés. Un logiciel qui a un but médical — diagnostiquer, prévenir, surveiller, prédire, traiter — peut lui-même être un dispositif médical : Software as a Medical Device (SaMD). Au Royaume-Uni, la Medicines and Healthcare products Regulatory Agency (MHRA) réglemente les dispositifs médicaux, y compris le SaMD, et la norme de cycle de vie logiciel IEC 62304 gouverne comment un tel logiciel doit être développé. Décider si votre technologie est un dispositif réglementé est une question de seuil avec de grandes conséquences, et c'est séparé de — bien que placé à côté de — la gestion du risque clinique DCB0129/0160.

Le Digital Technology Assessment Criteria (DTAC). Le DTAC est la base nationale que les organisations du NHS et de l'action sociale utilisent pour évaluer les produits numériques avant l'achat, couvrant la sécurité clinique (preuve de conformité DCB0129), la protection des données, la sécurité technique, l'interopérabilité, et l'utilisabilité. Il ne remplace pas la gestion du risque clinique ; il vérifie qu'un fournisseur l'a faite.

Facteurs humains et culture de sécurité. Les facteurs humains (ergonomie) sont l'étude scientifique de comment les personnes interagissent avec les systèmes dans des conditions réelles — fatigue, interruption, charge cognitive, fatigue d'alarme. La plupart des préjudices numériques ne surgissent pas d'un code qui est « faux » mais de conceptions qui rendent l'action sûre difficile et l'action non sûre facile. La culture de sécurité est l'engagement organisationnel à faire surgir, rapporter, et apprendre du risque sans blâme — la différence entre une équipe qui cache les incidents évités de justesse et une qui les exploite pour l'amélioration.

Rapport d'incident et apprentissage. En Angleterre, Learn from Patient Safety Events (LFPSE) est le service national pour enregistrer les événements de sécurité des patients, et le Patient Safety Incident Response Framework (PSIRF) énonce comment les organisations du NHS répondent aux incidents et en apprennent — mettant l'accent sur une analyse des causes profondes proportionnée et fondée sur les systèmes plutôt que sur le blâme. Les systèmes en production génèrent de nouveaux dangers, donc la sécurité clinique continue après la mise en production par le retour d'incident dans le journal des dangers.

Bonnes pratiques#

1. Nommez un responsable de la sécurité clinique compétent et donnez-lui une autorité réelle. Nommez un clinicien enregistré et en exercice avec une formation reconnue en sécurité clinique comme CSO pour chaque système dans le périmètre, et assurez-vous que sa validation soit une véritable porte, pas un tampon en caoutchouc atteint la veille du lancement. Le CSO doit pouvoir dire « pas encore » et être entendu — ce qui signifie protéger son temps, son indépendance, et sa position auprès du comité de pilotage du programme. Un CSO qui est outrepassé par la pression de livraison est une fiction de gouvernance.

2. Faites l'identification des dangers tôt, avec des cliniciens dans la salle. Commencez les ateliers de dangers en découverte et conception, pas avant la mise en production, car les contrôles les moins chers et les plus efficaces sont des changements de conception faits avant que quoi que ce soit ne soit construit (voir sujet 3.5 — Cycles de vie de livraison). Amenez des cliniciens de première ligne, pas seulement des analystes, car ils savent comment le travail se déroule réellement — les interruptions, les contournements, la façon dont un écran est lu à 3h du matin. Parcourez des scénarios cliniques réalistes et demandez sans relâche : « comment ce système pourrait-il contribuer à ce qu'un patient soit lésé ? »

3. Tenez un journal des dangers vivant, pas un document du jour de lancement. Traitez le journal des dangers comme un registre persistant qui s'ouvre à la découverte et ne se ferme jamais tant que le système est en production. Chaque danger enregistre ses causes, préjudice potentiel, évaluation initiale du risque, les contrôles appliqués, et le risque résiduel après contrôles. Quand un incident, un changement, ou un incident évité de justesse révèle un nouveau danger, il entre dans le journal et est traité à travers la même boucle — le journal est la mémoire de votre raisonnement de sécurité.

4. Faites en sorte que l'organisation déployante possède le DCB0160, même avec un fournisseur conforme. Le dossier de sécurité DCB0129 d'un fournisseur couvre le produit tel que construit ; il ne peut pas couvrir comment vous le configurez, quels flux de travail vous enveloppez autour de lui, ou lesquelles de vos populations l'utilisent. Menez votre propre évaluation DCB0160 pour les dangers locaux — intégration avec vos autres systèmes, votre qualité de données, vos parcours cliniques — et tenez votre propre journal des dangers. Supposer que l'assurance du fournisseur couvre votre contexte est un raccourci commun et dangereux.

5. Rendez le contrôle du risque proportionné et préférez la conception aux avertissements. Classez les contrôles par force : concevoir le danger hors du système (contraintes, valeurs par défaut, fonctions forçantes) bat une alerte à l'écran, qui bat une ligne dans un manuel de formation. Réservez l'assurance la plus lourde aux dangers de plus haute conséquence et appliquez un processus plus léger et plus rapide aux changements véritablement à faible risque — la proportionnalité est ce qui permet à la sécurité de suivre le rythme de la livraison. Réduisez le risque à ALARP et consignez pourquoi le risque résiduel est acceptable.

6. Concevez pour les facteurs humains, et respectez la fatigue d'alarme. Supposez que les utilisateurs sont occupés, interrompus, et reconnaissant des motifs, et concevez afin que l'action sûre soit l'action facile et par défaut. Prémunissez-vous contre la surcharge d'alertes : une alerte qui se déclenche trop souvent est ignorée, donc chaque avertissement supplémentaire doit gagner sa place ou il dégrade ceux qui comptent. Les tests d'utilisabilité dans des conditions réalistes sont une activité de sécurité clinique, pas seulement un raffinement de conception.

7. Déterminez votre statut réglementaire délibérément. Demandez tôt si votre logiciel répond à la définition d'un dispositif médical ou SaMD, et si oui, engagez les exigences de la MHRA et l'IEC 62304 dès le départ plutôt que de découvrir l'obligation tard. Se tromper sur la classification est coûteux dans les deux directions — un dispositif non enregistré est un échec légal et de sécurité, tandis que sur-classifier un outil simple gaspille une capacité d'assurance rare. En cas de doute, demandez un avis réglementaire et documentez le raisonnement.

8. Utilisez le DTAC comme un plancher, pas une ligne d'arrivée. Traitez le Digital Technology Assessment Criteria comme la vérification d'entrée minimale pour tout produit numérique acheté, confirmant que la sécurité clinique, la protection des données, la sécurité, l'interopérabilité, et l'utilisabilité ont été traitées. Passer le DTAC signifie qu'un fournisseur a fait le travail ; cela ne signifie pas que le produit est sûr dans votre contexte, donc associez-le à votre propre évaluation DCB0160 et surveillance en production.

9. Fermez la boucle des incidents en production vers le journal des dangers. Câblez votre rapport d'incident — soumissions LFPSE, enquêtes PSIRF, rapports locaux d'incidents évités de justesse — de retour vers la gestion du risque clinique afin que le préjudice réel et les incidents évités de justesse mettent à jour vos dangers et contrôles. Un dossier de sécurité jamais revisité après la mise en production pourrit, car les systèmes en production, intégrations, et pratique clinique dérivent tous (voir sujet 3.8 — Gestion de service et opérations en production). L'apprentissage est fondé sur les systèmes et conscient du blâme, pas une recherche de quelqu'un à punir.

10. Construisez une culture de sécurité juste et de rapport. Rendez sûr et attendu de rapporter les incidents évités de justesse et de contester un lancement sur des motifs de sécurité, car les dangers dont vous n'entendez jamais parler sont des dangers que vous ne pouvez pas contrôler. Les dirigeants fixent ce ton en répondant à une mauvaise nouvelle avec curiosité et amélioration plutôt que blâme, et en traitant la prudence du CSO comme précieuse plutôt qu'obstructive. La culture est le substrat sur lequel chaque autre pratique ici dépend.

Questions à discuter avec votre équipe#

1. Où dans notre portefeuille actuel comptons-nous sur l'assurance de sécurité d'un fournisseur pour couvrir des risques qui sont en réalité les nôtres à posséder ? Cette question sonde la division DCB0129/DCB0160, que les équipes brouillent régulièrement. Le dossier de sécurité DCB0129 d'un fournisseur traite le produit tel que fabriqué, mais au moment où vous le configurez, le connectez à vos autres systèmes, enveloppez des flux de travail locaux autour de lui, et le pointez vers votre population de patients spécifique, vous introduisez des dangers que le fournisseur n'a jamais évalués et n'aurait pas pu évaluer. Le tiraillement honnête est que mener votre propre évaluation DCB0160 coûte un temps clinique et analytique rare, et il est tentant de traiter l'assurance propre d'un fournisseur et un passage DTAC comme suffisants. Travaillez sur un déploiement en production ou imminent et demandez concrètement : qui est notre CSO nommé pour cela, avons-nous notre propre journal des dangers, et quels dangers surgissent purement de notre contexte local plutôt que du produit lui-même ? Une bonne réponse nomme des systèmes précis où l'évaluation locale est mince, distingue les dangers du produit des dangers de déploiement, et s'engage à posséder ces derniers plutôt que de supposer qu'ils sont couverts.

2. À quel point notre processus de sécurité clinique est-il proportionné — enterrons-nous des changements à faible risque dans la paperasse tandis que des changements à haute conséquence glissent par élan ? Le sujet soutient que l'assurance devrait s'échelonner avec le risque clinique : examen le plus lourd pour les dangers de plus haute conséquence, processus plus léger et plus rapide où le risque est véritablement faible. Cette question teste si votre organisation calibre réellement, ou applique un réglage uniforme et rigide. Les deux directions d'échec sont réelles et coûteuses — un processus uniformément lourd entraîne les équipes à voir la sécurité clinique comme une taxe bureaucratique et à la contourner, tandis qu'un processus uniformément léger laisse un changement à un calcul de dosage médicamenteux passer avec le même effort qu'un changement à une page d'aide. Le danger plus subtil est que l'élan, pas le risque, décide de l'examen : un programme phare avec attention exécutive peut acquérir une aura d'inévitabilité qui décourage le CSO de dire « pas encore ». Examinez deux ou trois changements récents de risque clairement différent et demandez si l'effort dépensé correspondait au potentiel de préjudice, et si quelqu'un s'est senti capable de ralentir celui à haut profil. Une réponse honnête admet où le processus est mal calibré dans un sens ou dans l'autre et traite la proportionnalité comme un jugement défendable et explicite plutôt qu'un réflexe.

3. Quand quelque chose a failli mal tourner avec l'un de nos systèmes numériques, qu'est-il réellement arrivé ensuite — et un clinicien de première ligne dirait-il que c'était sûr de le signaler ? Cette question examine la culture de sécurité et la boucle d'apprentissage des incidents, où les engagements affichés rencontrent la réalité. La sécurité clinique dépend d'entendre parler des incidents évités de justesse, mais les gens ne rapportent que quand rapporter semble sûr et utile, et quand ils voient que cela mène au changement plutôt qu'au blâme. Le tiraillement est que sous pression de livraison et réputationnelle, l'instinct est d'expliquer un incident évité de justesse, de le clore rapidement, et de passer à autre chose — surtout si le faire pleinement surgir retarderait un lancement ou embarrasserait un sponsor senior. L'approche fondée sur les systèmes et consciente du blâme de PSIRF existe précisément parce que chercher un individu à faute supprime le rapport dont vous avez besoin et manque les vraies causes systémiques. Ancrez la discussion dans un incident évité de justesse ou un incident récent spécifique : a-t-il été journalisé, a-t-il atteint le journal des dangers, une enquête proportionnée a-t-elle été menée, et quelque chose a-t-il réellement changé ? Une bonne réponse est franche sur si rapporter semblait sûr, distingue l'apprentissage véritable de la clôture de paperasse, et nomme des comportements concrets que les dirigeants adopteront afin que la prochaine personne qui repère un danger parle.

4. Avons-nous honnêtement déterminé lesquels de nos produits sont des dispositifs médicaux réglementés — et qui est responsable de cette décision ? Le statut réglementaire est une question de seuil aux conséquences démesurées, et il est facile de la laisser sans réponse car y répondre peut être gênant. Un logiciel qui diagnostique, prédit, surveille, ou traite peut lui-même être Software as a Medical Device, entraînant des obligations MHRA et la norme de cycle de vie IEC 62304 — séparées de, et en plus de, la gestion du risque clinique DCB0129/0160. Le tiraillement va dans les deux sens : sous-classifier vous laisse livrer un dispositif non enregistré, un échec légal et de sécurité qui peut surgir de façon catastrophique à l'échelle, tandis que sur-classifier un outil administratif simple brûle une capacité d'assurance rare dont vous aviez besoin ailleurs. Le danger est que la classification tombe entre les rôles — les cliniciens supposent que les ingénieurs ont décidé, les ingénieurs supposent que l'équipe réglementaire ou commerciale a décidé, et personne n'a réellement écrit le raisonnement. Regardez concrètement les produits de votre portefeuille qui se situent le plus près de la ligne — tout avec une règle de triage, un score de risque, un algorithme d'alerte — et demandez qui a fait la détermination de dispositif, sur quelle base, et si c'est documenté et revisité à mesure que les fonctionnalités changent. Une réponse honnête nomme les produits limites, pointe vers un raisonnement enregistré et défendable pour chacun, et est franche là où la décision n'a jamais vraiment été prise.

5. Concevons-nous les dangers hors du système, ou accumulons-nous discrètement des alertes et avertissements que nos cliniciens ont déjà appris à ignorer ? Le sujet classe les contrôles par force — concevoir le danger hors du système bat une alerte à l'écran, qui bat une ligne dans un manuel de formation — pourtant les alertes sont le chemin de moindre résistance, car ajouter un avertissement est rapide et semble responsable tandis que reconcevoir un flux de travail est lent et contesté. Avec le temps, ce biais s'accumule en fatigue d'alarme : tant d'avertissements se déclenchent que les cliniciens reconnaissent des motifs au-delà de tous, y compris celui qui compte, donc chaque nouvelle alerte peut réellement réduire la sécurité. Le vrai tiraillement est que chaque alerte inutile a un sponsor qui l'a ajoutée de bonne foi après un certain incident, ce qui rend les avertissements politiquement difficiles à retirer même quand ils dégradent le système. Les facteurs humains sont la discipline ici — concevoir afin que l'action sûre soit l'action facile et par défaut pour un utilisateur occupé et interrompu lisant un écran à 3h du matin — et les tests d'utilisabilité dans des conditions réalistes sont une activité de sécurité clinique, pas un raffinement de conception. Examinez un système que vos équipes utilisent réellement et demandez combien d'alertes un clinicien rencontre dans une tâche typique, lesquelles changent véritablement le comportement, et où une fonction forçante ou un meilleur défaut aurait pu remplacer entièrement un avertissement. Une bonne réponse résiste au réflexe d'ajouter une autre alerte, traite la charge d'alertes comme un danger mesurable en soi, et est prête à retirer des avertissements qui ne gagnent plus leur place.

6. À mesure que nos systèmes en production, intégrations, et parcours cliniques dérivent avec le temps, comment savons-nous que notre dossier de sécurité tient toujours ? La sécurité clinique ne se termine pas à la mise en production ; les systèmes en production génèrent de nouveaux dangers, et le monde autour d'un système continue de bouger — une intégration en amont change ses données, un parcours clinique est reconçu, un fournisseur livre une mise à jour, une nouvelle cohorte de patients commence à utiliser l'outil. Un dossier de sécurité approuvé il y a deux ans décrit un système et un contexte qui peuvent ne plus exister, donc la question est si votre journal des dangers est un registre vivant ou un document signé une fois et laissé pourrir (voir sujet 3.8 — Gestion de service et opérations en production). Le tiraillement est que maintenir le raisonnement de sécurité après le lancement rivalise avec la nouvelle livraison pour le même temps rare de CSO et clinique, et la dérive est graduelle et invisible d'une façon qui commande rarement l'attention jusqu'à ce que quelque chose échoue. Les angles concrets incluent un contrôle de changement qui redéclenche l'évaluation des dangers quand la configuration ou les intégrations changent, une revue périodique des dangers de plus haute conséquence, et une surveillance qui détecterait réellement un contrôle se dégradant silencieusement. Choisissez un système en production depuis un an ou plus et demandez quand ses dangers ont été revus pour la dernière fois, ce qui a changé en dessous depuis l'approbation, et qui remarquerait si un contrôle clé cessait de fonctionner. Une réponse honnête distingue les systèmes avec une gestion de sécurité continue véritable de ceux qui roulent sur un dossier de sécurité obsolète, et s'engage sur une cadence de revue proportionnée liée au changement réel plutôt qu'au calendrier seul.

En pratique : un exemple de santé et d'action sociale#

Un système de soins intégrés (ICS) déploie un outil de e-référence partagé qui permet aux médecins généralistes de référer des patients directement vers des services communautaires, avec un ensemble de règles de triage intégré qui achemine les cas urgents vers une file plus rapide. Une approche pilotée par la livraison prendrait le dossier de sécurité DCB0129 du fournisseur, passerait le DTAC, et mettrait en production pour atteindre une date promise au conseil d'administration.

Au lieu de cela, le programme nomme un médecin généraliste en exercice avec une formation en sécurité clinique comme responsable de la sécurité clinique et ouvre un dossier de gestion du risque clinique et un journal des dangers au début de la conception. Les premiers ateliers de dangers avec médecins généralistes, infirmières communautaires, et administrateurs font surgir plusieurs dangers que le dossier au niveau produit du fournisseur n'a jamais touchés — tous surgissant du déploiement local. Le pire : les règles de triage ont été configurées contre les propres définitions de service de l'ICS, et une erreur de mappage pourrait acheminer une référence urgente de cancer de la peau vers une file dermatologique de routine avec une attente de plusieurs semaines. Ce danger est évalué comme gravité élevée, probabilité plausible.

Travaillant la boucle de contrôle du risque, l'équipe préfère la conception aux avertissements. Ils ajoutent une fonction forçante afin qu'un drapeau clinique urgent ne puisse pas être outrepassé silencieusement par la logique de routage, un rapport de réconciliation qu'un clinicien revoit quotidiennement, et — le plus bas dans la hiérarchie — une note de formation. Le risque résiduel est réévalué et jugé acceptable et ALARP ; le CSO consigne pourquoi. Parce que l'outil route seulement et ne diagnostique pas lui-même, l'équipe l'évalue comme ne répondant pas au seuil SaMD, documente ce raisonnement, et le classe. Les tests de facteurs humains capturent un problème séparé : une alerte « référence en double » trop zélée se déclenche si souvent que les médecins généralistes l'ignorent déjà, donc elle est reconçue pour ne se déclencher que sur de véritables doublons.

À la mise en production, le dossier de sécurité DCB0160 est approuvé par le CSO, pas le directeur de programme. Trois semaines plus tard, un rapport LFPSE et un incident évité de justesse signalé par une réceptionniste révèlent un nouveau danger — un champ de texte libre utilisé pour glisser des informations urgentes que le routage ne voit jamais. Sous PSIRF, une revue proportionnée et fondée sur les systèmes est menée, le danger entre dans le journal, un changement de conception est planifié, et un contrôle intérimaire est briefé la même semaine. Le dossier de sécurité est un argument vivant, et le registre montre exactement comment chaque danger a été raisonné — ce dont un inspecteur, un coroner, ou un nouveau CSO dans deux ans aura besoin.

Angles sectoriels#

Tout le monde doit le même devoir de contrôler le risque clinique, mais la machinerie, les incitatifs, et les pressions diffèrent nettement selon l'organisation.

Startup#

Une startup de santé numérique rencontre souvent la sécurité clinique comme une porte d'achat : un acheteur du NHS demande le DTAC et un dossier de sécurité DCB0129, et c'est la course. Le mouvement gagnant est de construire la gestion du risque clinique dès le premier sprint — un journal des dangers aux côtés du backlog, un responsable de la sécurité clinique accessible (souvent sous contrat plutôt qu'employé, mais véritablement compétent et habilité) — car adapter rétroactivement un dossier de sécurité sur un produit fini est lent, coûteux, et peu convaincant. Les fondateurs doivent aussi confronter la question SaMD honnêtement et tôt, car découvrir à mi-échelle que le produit est un dispositif médical non enregistré est un risque légal et de sécurité existentiel. Bien fait, des artefacts de sécurité clinique matures deviennent un atout commercial qui raccourcit les cycles de vente au NHS.

Petite entreprise#

Un petit prestataire établi — un cabinet de médecine générale, une pharmacie communautaire, un établissement de soins, une agence de soins à domicile, une clinique à site unique, ou un petit fournisseur de technologie de santé passé le stade de pré-revenu — porte le même devoir DCB0160 qu'un grand trust quand il déploie et configure des systèmes numériques, mais sans aucune de la capacité disponible pour l'assumer. Il y a rarement un CSO ou analyste de sécurité dédié sur la masse salariale, donc la voie pratique est d'acheter un clinicien compétent et en exercice sur une base contractuelle et de tenir un journal des dangers léger mais véritable plutôt que de prétendre que le devoir ne s'applique pas. Les dangers locaux les plus aigus sont généralement de configuration et de flux de travail — comment le dossier partagé est configuré, comment les drapeaux urgents sont gérés, comment le contournement d'un administrateur à temps partiel devient un risque de routage — exactement les dangers qu'un dossier DCB0129 de fournisseur ne couvre jamais. La proportionnalité est l'amie du petit prestataire ici : concentrez le peu de temps d'assurance que vous avez sur les dangers de plus haute conséquence, utilisez le DTAC et le dossier de sécurité du fournisseur comme un plancher lors du choix des produits, et appuyez-vous sur des ressources partagées telles que le support de sécurité clinique de l'ICS plutôt que d'essayer de construire tout l'appareil seul.

Grande entreprise#

Un trust NHS ou un ICS porte une double responsabilité : il déploie les systèmes d'autres sous DCB0160 et construit ou configure souvent lourdement les siens sous DCB0129. L'échec caractéristique est institutionnel — un programme phare de dossier patient électronique dont la date de mise en production a un poids politique, si bien que la prudence du CSO est discrètement traitée comme un obstacle. Le correctif est structurel : donnez au CSO l'indépendance et un véritable veto, tenez un journal des dangers vivant à travers le parc plutôt qu'une étagère de documents du jour de lancement, et câblez l'apprentissage LFPSE et PSIRF de retour dans la gestion du risque clinique comme un processus permanent. À l'échelle de l'entreprise, les plus grands dangers sont des dangers d'intégration et de configuration, qu'aucune assurance de fournisseur ne couvre, donc la propriété locale est non négociable.

Gouvernement#

Un organisme national — NHS England, la MHRA, le DHSC, NICE — fixe les normes que d'autres doivent satisfaire, donc ses façons de travailler façonnent tout le système : DCB0129/0160, DTAC, et la réglementation SaMD sont des instruments de sécurité à l'échelle de la population. Les décisions ici attirent un examen réglementaire, parlementaire et public, et un système mandaté nationalement qui porte un danger latent distribue ce préjudice à travers des millions de personnes avant que quiconque ne voie le motif. Les obligations sont la proportionnalité rendue explicite dans des normes publiées, la transparence sur le risque résiduel, et le maintien du cadre réglementaire à jour à mesure que la technologie — en particulier l'IA — le dépasse (voir sujet 8.4 — Gouvernance de l'IA et des technologies émergentes). Le risque distinctif à cette échelle est systémique : mandater une technologie à travers le parc sur des preuves de sécurité minces enracine un danger partout à la fois.

Modes de défaillance courants#

• Sécurité ajoutée à la fin. Produire un dossier de sécurité la semaine avant la mise en production pour satisfaire une porte. Antidote : ouvrez le journal des dangers à la découverte ; concevez les plus grands dangers hors du système.
• Assurance du fournisseur confondue avec la sécurité locale. Traiter un dossier DCB0129 et un passage DTAC comme couvrant votre déploiement. Antidote : possédez votre évaluation DCB0160 et journal des dangers local.
• CSO comme tampon en caoutchouc. Un responsable de la sécurité clinique sans temps, indépendance, ou autorité pour dire « pas encore ». Antidote : protégez le rôle et faites de la validation une véritable porte.
• Journal des dangers mort. Un document écrit une fois et jamais revisité après le lancement. Antidote : gardez-le vivant ; alimentez-le avec les incidents et changements.
• Surcharge d'alertes. Tant d'avertissements que les cliniciens les ignorent tous, y compris les vitaux. Antidote : conception des facteurs humains ; chaque alerte doit gagner sa place.
• Culture du blâme. Punir des individus pour des incidents évités de justesse, si bien que le rapport se tarit. Antidote : une culture juste et fondée sur les systèmes alignée avec PSIRF.
• Seuil réglementaire manqué. Livrer un SaMD sans le reconnaître comme un dispositif réglementé. Antidote : évaluez et documentez le statut de dispositif médical tôt.

Modèle de maturité#

Liste de contrôle#

• Un responsable de la sécurité clinique compétent, en exercice, et formé est nommé pour chaque système, avec temps et autorité pour dire « pas encore ».
• Un dossier de gestion du risque clinique, un journal des dangers vivant, et un dossier de sécurité clinique existent pour chaque système dans le périmètre.
• L'identification des dangers a commencé en découverte, avec des cliniciens de première ligne dans la salle.
• L'organisation déployante a mené sa propre évaluation DCB0160, pas seulement accepté le dossier DCB0129 du fournisseur.
• Les contrôles de risque préfèrent la conception hors du système aux alertes, aux alertes à la formation, avec le risque résiduel réduit à ALARP et justifié.
• Le statut de dispositif médical / SaMD a été évalué et documenté, et les obligations MHRA / IEC 62304 engagées où pertinent.
• Le DTAC a été complété comme un plancher, associé à la gestion du risque clinique locale.
• Les tests de facteurs humains et d'utilisabilité dans des conditions réalistes ont été faits ; la charge d'alertes est contrôlée.
• Les incidents en production (LFPSE) et l'apprentissage PSIRF retournent dans le journal des dangers comme un processus permanent.
• Rapporter des incidents évités de justesse et contester un lancement sur des motifs de sécurité est visiblement sûr et attendu.

Sources clés#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — Clinical Safety Officer training et orientations de gestion du risque clinique.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MHRA — orientations Software and Artificial Intelligence (AI) as a Medical Device.
• IEC — IEC 62304 : Medical device software — software life cycle processes.
• ISO — ISO 14971 : Application of risk management to medical devices.
• NHS England — service Learn from Patient Safety Events (LFPSE).
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• World Health Organization — Global Patient Safety Action Plan 2021–2030.

Références#

1. Patient safety — Wikipédia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipédia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipédia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipédia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipédia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipédia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipédia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipédia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipédia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipédia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipédia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan