Sujet 4.4 — Appareils connectés, IoT et ingénierie clinique

Dans la santé et l'action sociale, l'appareil connecté est là où le logiciel rencontre le corps du patient, donc comment vous gérez la flotte de pompes, moniteurs, scanners, et objets connectés est une décision de sécurité clinique, de cybersécurité, et de confiance publique, pas une ligne budgétaire d'installations.

Pourquoi c'est important dans la santé et l'action sociale#

Un hôpital moderne fonctionne sur des machines qui touchent les patients directement et parlent constamment au réseau. Les pompes à perfusion dosent les médicaments au microlitre, les ventilateurs maintiennent les gens en respiration, les moniteurs surveillent les signes vitaux, les scanners d'imagerie émettent des radiations ionisantes, et les systèmes de gestion de bâtiment maintiennent la température des réfrigérateurs à vaccins. Une part croissante de ceux-ci sont connectés : ils poussent des données dans les dossiers, tirent la configuration depuis des serveurs, et exposent des interfaces de gestion. Lorsque l'un se comporte de manière inattendue, l'échec n'est pas une panne gênante — cela peut être une erreur de dose, une alarme manquée, ou une image corrompue qui change un diagnostic.

C'est pourquoi la gestion des appareils se situe à l'intersection de trois obligations que vous portez déjà. C'est une obligation de sécurité clinique, car un défaut d'appareil ou un mauvais correctif peut nuire à un patient (voir Sujet 1.6 — Sécurité clinique et gestion des risques). C'est une obligation de cybersécurité, car l'équipement clinique connecté est l'une des plus grandes et moins gouvernées surfaces d'attaque du parc (voir Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité). Et c'est une obligation réglementaire, car les dispositifs médicaux sont des produits réglementés avec des obligations post-commercialisation qui incombent en partie à vous en tant qu'exploitant.

Les enjeux s'élargissent, ne se réduisent pas. Les soins se déplacent vers le domicile à travers les objets connectés et la surveillance à distance, donc le « parc d'appareils » inclut maintenant de l'équipement que vous ne possédez pas sur des réseaux que vous ne contrôlez pas. Les appareils durent bien plus longtemps que le logiciel à l'intérieur, donc un scanner acheté pour une vie clinique de quinze ans peut exécuter un système d'exploitation qui a perdu le support de sécurité après cinq. Les équipes de rançongiciel ont appris que la technologie clinique est fragile, non corrigée, et critique pour la mission — une combinaison rentable. Traiter les appareils connectés comme le problème de quelqu'un d'autre est comment les organisations découvrent, en plein incident, que personne ne les possède.

Concepts fondamentaux#

Un dispositif médical est tout instrument, appareil, ou logiciel destiné par son fabricant à un usage médical — diagnostic, surveillance, traitement, ou prévention — qui n'atteint pas son effet par la pharmacologie. Un dispositif médical connecté ajoute une interface réseau : il envoie ou reçoit des données, ou peut être géré à distance. L'Internet des objets médicaux (IoMT) est l'application santé de l'Internet des objets (IoT) plus large — la population de capteurs et objets quotidiens qui se connectent aux réseaux et échangent des données. Dans un contexte de soins, l'IoMT couvre les moniteurs de chevet, pompes intelligentes, objets connectés portables, capteurs domestiques, et le middleware de grade clinique qui les relie ensemble.

L'ingénierie clinique est la spécialité, se situant dans l'ingénierie biomédicale, responsable de l'usage sûr et efficace de la technologie médicale dans une organisation de santé. Dans le NHS, ces équipes sont souvent appelées ingénierie médicale, physique médicale, ou Electronic and Biomedical Engineering (EBME). La gestion des dispositifs médicaux est leur discipline centrale : maintenir un inventaire précis, une maintenance préventive planifiée, l'étalonnage, la réparation, les alertes de sécurité, la formation, et le désengagement contrôlé en fin de vie.

La technologie opérationnelle (OT) est le matériel et logiciel qui surveille ou contrôle des processus et équipements physiques, distinct de la technologie de l'information (IT) conventionnelle qui traite des données métier. Les appareils cliniques et systèmes de bâtiment sont de l'OT : ils ont de véritables effets physiques, des cycles de vie longs, et des contraintes (temps de fonctionnement, certification, comportement en temps réel) qui rendent la pratique IT ordinaire — redémarrer, corriger, remplacer — risquée ou interdite sans la bénédiction du fabricant. La surface d'attaque (attack surface) est la somme des points où un attaquant pourrait entrer ou affecter un système ; les appareils connectés l'élargissent dramatiquement car chacun est un petit ordinateur, souvent non durci, sur votre réseau.

Deux contrôles reviennent tout au long de ce sujet. La segmentation réseau est la pratique consistant à diviser un réseau en zones isolées afin qu'une compromission dans l'une ne puisse pas se propager librement aux autres — l'atténuation unique la plus efficace pour l'équipement clinique non corrigible. La visibilité des actifs est simplement de savoir ce que vous avez : chaque appareil, son emplacement, firmware, propriété, comportement réseau, et statut de support. Vous ne pouvez pas protéger, corriger, ou retirer ce que vous ne pouvez pas voir.

Enfin, le cadre réglementaire. Au Royaume-Uni, la Medicines and Healthcare products Regulatory Agency (MHRA) réglemente les dispositifs médicaux, et la surveillance post-commercialisation — surveiller la sécurité et la performance après qu'un produit soit sur le marché — est une obligation partagée entre fabricants et les exploitants qui utilisent et rapportent sur les appareils. La technologie portable et la surveillance à distance des patients étendent tous ces concepts au-delà du bâtiment, dans le domicile et la poche du patient.

Bonnes pratiques#

1. Construisez et maintenez un inventaire d'appareils unique et faisant autorité. Vous ne pouvez pas gérer, sécuriser, ou retirer ce que vous n'avez pas compté. Fusionnez la base de données d'actifs de l'ingénierie clinique avec les données de découverte réseau afin que l'inventaire enregistre non seulement la marque, le modèle, et l'emplacement mais aussi la version de firmware, le système d'exploitation, le comportement réseau, les flux de données, la propriété, et le statut de support. Traitez l'inventaire comme un système de sécurité vivant avec un propriétaire nommé, réconcilié continuellement contre ce qui est réellement sur le câble, pas une feuille de calcul rafraîchie une fois par an pour l'audit.

2. Amenez l'IT, l'ingénierie clinique, et la cybersécurité dans un seul forum de gouvernance. Ces appareils tombent entre trois équipes, et les écarts entre elles sont exactement là où vivent les incidents. Établissez un groupe conjoint de sécurité des dispositifs médicaux avec des droits de décision clairs sur l'intégration, le correctif, la segmentation, et le désengagement, et donnez-lui un lien permanent avec la fonction de sécurité clinique. Les ingénieurs cliniques comprennent l'appareil et le risque patient ; l'équipe de sécurité comprend la menace réseau ; ni l'un ni l'autre ne peuvent agir en sécurité sans l'autre.

3. Segmentez le réseau et défaultez vers la moindre connectivité. La plupart des appareils cliniques ne peuvent pas être durcis ou corrigés selon votre calendrier, donc contenez-les à la place. Placez les appareils dans des zones segmentées avec des flux étroitement contrôlés, autorisant seulement les connexions dont un appareil a véritablement besoin et refusant le reste, afin qu'une compromission ne puisse pas traverser le parc. La segmentation est le contrôle qui vous permet de continuer à exploiter un appareil sûr cliniquement mais faible numériquement — il achète du temps que le correctif seul n'achètera jamais.

4. Traitez le correctif comme un changement de sécurité clinique, possédé conjointement avec le fabricant. Un correctif sur un appareil réglementé est un changement à un produit critique pour la sécurité, et appliquer une mise à jour non validée peut être aussi dangereux que laisser un trou ouvert. Suivez les avis de sécurité du fabricant et les avis de sécurité sur le terrain de la MHRA, validez les mises à jour contre les directives du fabricant, et programmez-les via le contrôle de changement clinique avec des plans de repli. Là où un appareil ne peut pas être corrigé, enregistrez le risque résiduel accepté et les contrôles compensatoires plutôt que de prétendre que l'écart n'existe pas.

5. Planifiez le cycle de vie entier, y compris la fin de vie, avant d'acheter. La vie clinique d'un appareil dépasse régulièrement le support logiciel du fournisseur, créant des années de risque non supporté et exposé à internet. À l'achat, exigez une nomenclature logicielle, un engagement de support et de correctif déclaré, des fonctionnalités sécurisées par conception, et une date claire de fin de support, et budgétez le remplacement contre cette date, pas la date mécanique (voir Sujet 6.3 — Achats et commercial). Le désengagement est aussi une étape contrôlée : effacez les données patient, révoquez les identifiants et l'accès réseau, et mettez à jour l'inventaire, car un moniteur oublié dans un placard de stockage est toujours une voie d'accès en direct.

6. Faites entrer les données d'appareil dans le dossier en toute sécurité et de manière significative. La valeur des appareils connectés est réalisée lorsque les lectures circulent dans le dossier clinique précisément, avec le bon patient, les bonnes unités et horodatages, et avec une provenance claire. Utilisez des normes d'interopérabilité reconnues et un middleware d'intégration plutôt que des liens point-à-point sur mesure, et validez qu'une lecture d'appareil correspond au bon patient à chaque fois (voir Sujet 4.3 — Interopérabilité et normes de données). Un signe vital attribué au mauvais patient, ou une unité ambiguë, est un danger de sécurité clinique déguisé en commodité d'intégration.

7. Concevez la surveillance à distance et les objets connectés pour le domicile, pas le service hospitalier. Lorsque les soins se déplacent vers le domicile, vous héritez d'appareils sur un haut débit domestique, partagés par des familles, chargés par intermittence, et utilisés par des personnes malades. Concevez pour les lacunes de connectivité, l'escalade claire lorsque les lectures franchissent des seuils, l'inclusion numérique, et le consentement explicite sur ce qui est collecté et qui agit dessus (voir Sujet 1.9 — Inclusion numérique et accessibilité, et Sujet 3.3 — Services numériques destinés aux patients et citoyens). Soyez honnête sur la responsabilité clinique : un flux de lectures domiciliaires que personne n'est doté en ressources pour regarder est une fausse réassurance, pas un service.

8. Répétez la perte de vos appareils, et rapportez les défauts vers le haut. Supposez qu'une classe d'appareils sera un jour indisponible — par rançongiciel, un rappel, ou une panne réseau — et répétez le repli clinique afin que le personnel n'improvise pas pendant un incident (voir Sujet 3.9 — Continuité d'activité et reprise après sinistre). En parallèle, réinjectez les défauts d'appareil, quasi-incidents, et événements indésirables dans la surveillance post-commercialisation de la MHRA via le schéma Yellow Card, car vos rapports sont comment les défauts systémiques d'appareils sont attrapés avant de nuire à quelqu'un d'autre.

Questions à discuter avec votre équipe#

1. Qui possède réellement la flotte d'appareils connectés à travers sa vie entière — et où sont les écarts entre l'IT, l'ingénierie clinique, et la cybersécurité aujourd'hui ? Cela compte car les appareils non possédés sont ceux qui ne sont pas corrigés, non surveillés, et non cartographiés jusqu'à ce qu'un incident force la question. Dans la plupart des organisations, l'ingénierie clinique possède l'enregistrement d'actifs, l'IT possède le réseau, la sécurité possède la menace, et personne ne possède l'appareil comme un tout connecté, réglementé, orienté patient. Débattez de où se situent les coutures : qui décide qu'un appareil peut rejoindre le réseau, qui valide un correctif, qui valide le désengagement, et qui est responsable lorsqu'un appareil est à la fois un instrument critique pour la sécurité et un ordinateur vulnérable. Considérez si votre forum de gouvernance a de véritables droits de décision et un budget, ou est un lieu de discussion qui escalade tout et ne résout rien. Une bonne réponse honnête nomme le propriétaire responsable pour chaque étape de cycle de vie, admet où aujourd'hui la réponse est « personne », et s'engage à fermer des coutures spécifiques plutôt que de réaffirmer que la collaboration est importante.

2. Quelle part de notre parc connecté pouvons-nous réellement voir, et à quel point sommes-nous confiants dans ce chiffre ? Vous ne pouvez pas segmenter, corriger, ou retirer des appareils que vous n'avez pas comptés, pourtant la plupart des organisations découvrent pendant un incident que leur inventaire sous-estime la réalité par une large marge — appareils fantômes, équipement installé par un fournisseur, équipement oublié dans les salles de stockage, et appareils domiciliaires que personne n'a catalogués. Discutez de comment votre inventaire est construit et réconcilié : est-ce une feuille de calcul statique, ou est-il continuellement comparé à ce que la découverte réseau voit sur le câble ? Sondez l'honnêteté de la confiance de votre équipe — un compte d'apparence précise sans processus de réconciliation est plus dangereux qu'un « nous ne savons pas complètement » admis, car cela engendre une fausse assurance. Considérez les catégories les plus difficiles : systèmes de gestion de bâtiment, équipement géré par un tiers, et appareils dans les domiciles des patients. Une bonne réponse énonce un chiffre de couverture réaliste, décrit comment les écarts sont trouvés et fermés, et traite l'inventaire comme un système critique pour la sécurité avec un propriétaire nommé plutôt qu'un artefact de conformité.

3. Que se passe-t-il cliniquement lorsqu'une classe de ces appareils est indisponible, dangereuse, ou compromise — et l'avons-nous jamais répété ? Les appareils connectés échouent en classe, pas un à la fois : un événement de rançongiciel, un bogue de firmware, un rappel, ou une panne réseau peuvent mettre à terre chaque pompe ou moniteur d'un type simultanément. Discutez de quelles classes d'appareils causeraient le plus de préjudice si perdues, quel est le repli clinique manuel ou alternatif, et si le personnel de première ligne le connaît réellement ou improviserait sous pression. Faites surgir le compromis entre disponibilité et sécurité : la pression de garder un appareil fragile fonctionnel cliniquement versus le risque de laisser un trou connu ouvert, et qui est habilité à prendre cet appel. Considérez si vous détecteriez même un appareil compromis se comportant subtilement mal — un moniteur rapportant des lectures plausibles mais fausses est plus difficile à attraper qu'un qui devient sombre. Une bonne réponse identifie les classes à plus haut préjudice, confirme qu'un repli répété et doté en ressources existe pour chacune, et est franche sur les angles morts de détection qui restent.

4. Achetons-nous et budgétons-nous pour la vie logicielle d'un appareil, ou seulement sa vie mécanique ? Un scanner peut avoir une vie clinique de quinze ans tandis que le système d'exploitation à l'intérieur perd le support de sécurité après cinq, donc une décision d'achat prise aujourd'hui vous engage discrètement dans une décennie de risque non corrigible à moins que quelqu'un ne le planifie. Discutez de si votre processus d'achat traite une nomenclature logicielle, un engagement de correctif déclaré, des fonctionnalités sécurisées par conception, et une date explicite de fin de support comme des conditions contractuelles, ou comme des plus agréables qui disparaissent sous pression de prix. Sondez qui détient le budget de remplacement et contre quelle date il est fixé — le point d'échec mécanique, ou le point de fin de support logiciel qui arrive des années plus tôt. Considérez les cas gênants déjà dans le parc : appareils achetés avant que quiconque ne pose ces questions, maintenant des années après le support, sans financement de remplacement en vue. Faites surgir la tension entre les équipes cliniques qui veulent la dernière capacité, les finances qui veulent des actifs exploités pour leur pleine vie physique, et la sécurité qui voit la responsabilité croissante. Une réponse honnête relie la décision d'achat au coût de vie entier, nomme qui possède le budget de remplacement, et admet où le parc porte déjà un risque d'obsolescence logicielle non financé.

5. Pour les appareils se déplaçant dans les domiciles des patients, qui surveille réellement les lectures — et avons-nous conçu pour les personnes qui les utilisent ? La surveillance à distance et les objets connectés déplacent le parc d'appareils vers un haut débit domestique, partagé avec des familles, chargé par intermittence, et exploité par des personnes malades, donc les hypothèses du service hospitalier sur la connectivité, le contrôle, et le support ne tiennent plus. Discutez de si une équipe clinique nommée et dotée en ressources est responsable d'agir sur les lectures domiciliaires, ou si les données circulent dans un tableau de bord que personne n'est financé pour regarder — une fausse réassurance déguisée en service. Faites surgir la tension d'inclusion numérique : un programme de surveillance domiciliaire peut discrètement exclure ceux sans haut débit fiable, un appareil adéquat, ou la confiance pour en utiliser un, élargissant les inégalités mêmes qu'il visait à réduire (voir Sujet 1.9 — Inclusion numérique et accessibilité). Considérez le consentement et la clarté de la responsabilité — les patients et aidants doivent savoir ce qui est collecté, qui le voit, et ce qui se passe lorsqu'une lecture franchit un seuil. Pesez l'attraction de faire passer ces programmes à l'échelle rapidement contre le devoir de les rendre sûrs et équitables. Une bonne réponse confirme qui surveille et escalade, est franche sur les risques d'inclusion, et traite les appareils domiciliaires comme un service clinique gouverné plutôt qu'un flux de données commode.

6. Lorsqu'une lecture d'appareil atteint le dossier clinique, sommes-nous sûrs que c'est la bonne valeur, dans les bonnes unités, pour le bon patient ? La valeur clinique d'un appareil connecté n'est réalisée que lorsque ses données atterrissent dans le dossier précisément, pourtant chaque intégration est aussi une nouvelle chance d'attribuer un signe vital au mauvais patient ou de perdre les unités et la provenance derrière un chiffre. Discutez de si les données d'appareil circulent via des normes d'interopérabilité validées et un middleware d'intégration avec des vérifications explicites de correspondance de patient, ou via des liens point-à-point sur mesure que personne ne comprend pleinement (voir Sujet 4.3 — Interopérabilité et normes de données). Sondez les modes d'échec qui ressemblent à de la commodité mais sont des dangers de sécurité : une unité ambiguë, une lecture mal chronométrée, une valeur écrite pour le patient précédent encore connecté au chevet. Considérez comment vous détecteriez même une telle erreur, étant donné qu'un chiffre plausible mais faux est bien plus dangereux qu'un écart évident. Faites surgir le compromis entre la vitesse de connexion d'un nouvel appareil et le travail d'assurance qui rend ses données dignes de confiance. Une réponse honnête décrit comment la correspondance de patient et l'intégrité d'unité sont validées de bout en bout, nomme qui possède cette assurance, et traite une lecture mal attribuée comme l'incident de sécurité clinique qu'elle est plutôt qu'une nuisance d'intégration.

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

Le Meadowfield NHS Foundation Trust exploite un hôpital de soins aigus de taille moyenne et, de plus en plus, un service virtuel qui surveille les patients à domicile. Après qu'un trust pair ait subi un incident de rançongiciel qui s'est propagé via des appareils cliniques non gérés, le conseil d'administration de Meadowfield pose une question simple : combien d'appareils connectés avons-nous, et qui les possède ? La réponse honnête est que personne ne peut le dire. La base de données de l'ingénierie clinique liste environ 6 000 actifs ; l'outil de découverte passive de l'équipe réseau en voit environ 9 000 se comportant comme des appareils. L'écart est le problème.

Le trust met en place un groupe conjoint de sécurité des dispositifs médicaux coprésidé par la responsable de l'ingénierie clinique et le responsable de la sécurité de l'information, avec le responsable de sécurité clinique présent. Leur premier livrable est un inventaire réconcilié : ils fusionnent les deux sources de données, traquent les écarts, et trouvent des pompes à perfusion sur le réseau général, un scanner CT exécutant un système d'exploitation trois versions au-delà de la fin de support, et un ensemble de contrôleurs de gestion de bâtiment pour les réfrigérateurs de pharmacie que l'IT n'avait jamais catalogués. Chaque conclusion est consignée avec une notation de risque clinique plutôt que purement technique.

Ils ne peuvent pas remplacer le scanner cette année, donc ils le contiennent : il se déplace dans une zone étroitement segmentée qui permet seulement les flux vers son archive d'imagerie et la passerelle de support du fournisseur, et le risque résiduel accepté est enregistré et validé via la gouvernance clinique. Les pompes sont inscrites dans un cycle de correctifs géré validé contre les avis du fabricant et programmé via le contrôle de changement. Pour le service virtuel, le groupe insiste pour que les appareils de surveillance domiciliaire rapportent dans le dossier via un middleware d'intégration validé avec des vérifications de correspondance de patient, et qu'une équipe clinique nommée soit dotée en ressources pour surveiller et escalader les lectures — pas un tableau de bord que personne ne possède.

Six mois plus tard, un fournisseur émet un avis de sécurité sur le terrain concernant un défaut de firmware de moniteur. Parce que l'inventaire est maintenant précis et réconcilié, Meadowfield identifie chaque unité affectée en une heure, applique le correctif validé via le contrôle de changement, et rapporte son propre quasi-incident lié à la MHRA via le schéma Yellow Card. Le travail était peu glamour — un inventaire, un forum, un projet de segmentation — mais il a transformé un risque invisible et non possédé en un risque géré.

Angles sectoriels#

Startup#

Une startup de santé numérique livrant un objet connecté portable ou un appareil de surveillance domiciliaire est du côté fabricant de la ligne réglementaire, et ses façons de travailler doivent refléter cela dès le premier jour. Construisez sécurisé par conception : firmware signé, un chemin de mise à jour over-the-air, une nomenclature logicielle, et un plan pour corriger les appareils déjà sur le terrain — adapter la sécurité après coup après un tour de financement est bien plus difficile. Comprenez que vous portez des obligations de surveillance post-commercialisation et des obligations MHRA qui ne se réduisent pas pour une petite équipe, et qu'un client hospitalier évaluera votre posture de sécurité avant de laisser votre appareil approcher de son réseau. Votre avantage compétitif n'est pas seulement l'appareil mais la promesse crédible et documentée que vous le soutiendrez et le sécuriserez pour toute sa vie clinique.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite ou une clinique monosite — exploite une flotte modeste mais réelle d'équipement connecté : moniteurs de tension artérielle, unités ECG, capteurs de réfrigérateur à vaccins, spiromètres, et le filet croissant d'objets connectés de patients, tous sur un réseau qu'aucune équipe informatique dédiée ne surveille. Les mêmes obligations MHRA, de cybersécurité, et de sécurité clinique s'appliquent qu'à un grand trust, mais il n'y a aucun département d'ingénierie clinique et souvent aucune informatique interne du tout, donc commencez par simplement savoir ce que vous avez : un inventaire court et honnête avec la marque, le firmware, et le statut de support bat un système élaboré que vous ne pouvez pas maintenir. Appuyez-vous fortement sur vos fournisseurs et partenaires de service géré — insistez pour que les contrats de maintenance, responsabilités de correctif, et dates de fin de support soient écrits, car vous comptez sur eux pour une capacité que vous ne pouvez pas doter en personnel. Utilisez le moment d'achat comme votre point de contrôle principal, car remplacer un appareil obsolète est souvent plus réaliste pour vous que de le durcir en place. Gardez les éléments à plus haut préjudice — un réfrigérateur contenant des vaccins à chaîne du froid, un moniteur en qui un clinicien a confiance — hors du réseau de bureau plat où une compromission pourrait atteindre tout, même si la segmentation complète est hors de votre portée.

Entreprise#

Un grand trust du NHS ou un groupe hospitalier gère des milliers d'appareils de dizaines de fournisseurs à travers un parc tentaculaire et de longue durée, et son défi est la coordination et l'échelle. L'objectif réaliste est un inventaire réconcilié, une segmentation disciplinée, et un forum de gouvernance conjoint couvrant l'ingénierie clinique, l'IT, et la sécurité avec une véritable autorité — pas un correctif parfait partout, que les contraintes de fournisseur rendent impossible. Intégrez la sécurité des appareils dans les achats afin que les engagements de support, fonctionnalités sécurisées par conception, et dates de fin de support soient des conditions contractuelles, et alignez le budget de remplacement sur la vie logicielle, pas la mécanique (voir Sujet 4.0 — Architecture technique, cloud et héritage). À cette échelle, les plus grands gains viennent d'un petit nombre de contrôles à l'échelle du parc faits de manière cohérente, pas d'héroïsme sur des appareils individuels.

Gouvernement#

Un organisme national ou régional — NHS England, un département de santé décentralisé, la MHRA — façonne l'environnement dans lequel chaque exploitant travaille. Il fixe des normes de sécurité d'appareils et cadres d'achat, exploite le renseignement national des menaces et les alertes afin qu'une vulnérabilité trouvée dans un trust protège tous, et réglemente les appareils et leur surveillance post-commercialisation. Son levier est de rendre la sécurité par conception et le support de cycle de vie le défaut du marché via des normes et le pouvoir d'achat, afin que les trusts individuels ne négocient pas chacun la sécurité depuis une position faible. Le gouvernement porte aussi l'obligation d'équité : s'assurer que les programmes de surveillance domiciliaire et d'objets connectés n'élargissent pas la fracture numérique, et que le signalement de sécurité circule vers le haut afin que les défauts systémiques d'appareils soient attrapés nationalement plutôt que redécouverts trust par trust (voir Sujet 9.1 — Travailler avec les gouvernements locaux et nationaux).

Modes d'échec courants#

• L'inventaire qui ment. Une feuille de calcul soignée réconciliée pour la dernière fois il y a un an donne une fausse confiance ; les appareils qui vous nuisent sont ceux qu'elle n'a jamais listés. Réconciliez continuellement contre la découverte réseau.
• Appareils dans le no man's land entre équipes. Quand l'IT dit que c'est l'équipement de l'ingénierie clinique et que l'ingénierie clinique dit que c'est le réseau de l'IT, personne ne le corrige, segmente, ou surveille. Assignez une propriété de bout en bout.
• Paralysie de correctif ou imprudence de correctif. Les deux extrêmes nuisent aux patients — ne jamais mettre à jour laisse des trous connus ouverts ; appliquer des mises à jour non validées peut casser un appareil critique pour la sécurité. Acheminez les correctifs via un contrôle de changement clinique conjoint.
• Acheter pour la vie mécanique, oublier la vie logicielle. Un scanner de quinze ans sur un système d'exploitation supporté cinq ans devient une responsabilité non corrigible. Budgétez le remplacement contre la fin du support logiciel.
• Réseaux plats. Les appareils connectés sur le réseau général laissent une seule compromission atteindre tout. Segmentez par défaut.
• Surveillance domiciliaire avec personne pour regarder. Un flux de lectures d'objets connectés qu'aucun clinicien n'est doté en ressources pour agir dessus est une fausse réassurance et un risque de gouvernance, pas un service.
• Désengagement qui n'en est pas un. Un appareil retiré encore sur le réseau avec d'anciens identifiants et données patient est une voie d'attaque en direct. Effacez, révoquez, déconnectez, et mettez à jour l'inventaire.

Modèle de maturité#

Liste de contrôle#

• Il y a un inventaire d'appareils unique et faisant autorité, réconcilié continuellement contre la découverte réseau, avec un propriétaire nommé.
• Un forum conjoint de l'IT, l'ingénierie clinique, et la cybersécurité a de véritables droits de décision sur l'intégration, le correctif, la segmentation, et le désengagement.
• Les appareils connectés se trouvent dans des zones réseau segmentées qui permettent seulement les flux dont ils ont véritablement besoin.
• Les correctifs et mises à jour de firmware pour les appareils réglementés sont validés et acheminés via le contrôle de changement clinique, avec des plans de repli.
• Les contrats d'achat exigent une nomenclature logicielle, des fonctionnalités sécurisées par conception, et une date déclarée de fin de support.
• Les budgets de remplacement sont alignés sur la vie de support logiciel, pas seulement la vie mécanique.
• Le désengagement efface les données patient, révoque les identifiants et l'accès réseau, et met à jour l'inventaire.
• Les données d'appareil atteignent le dossier clinique via une intégration validée avec des vérifications de correspondance de patient et d'unité.
• Les programmes de surveillance domiciliaire et d'objets connectés ont une escalade clinique dotée en ressources, un consentement explicite, et une inclusion par conception.
• Le repli clinique pour la perte de chaque classe d'appareil à haut préjudice est documenté et répété.
• Les défauts d'appareil, quasi-incidents, et événements indésirables sont rapportés à la MHRA via le schéma Yellow Card.

Sources clés#

• MHRA — Medical devices: guidance for manufacturers, operators and users, and the Yellow Card reporting scheme for adverse incidents and field safety notices.
• NHS England / NHS Digital — Data Security and Protection Toolkit and network/device security guidance for health and care organisations.
• NCSC (National Cyber Security Centre) — guidance on operational technology, network segmentation and securing connected devices.
• NHS England / IEC standards — clinical engineering and medical device management good practice (including IEC 80001 for risk management of IT-networks incorporating medical devices).
• NICE — Evidence Standards Framework for Digital Health Technologies and guidance on remote monitoring and wearables.
• Institute of Physics and Engineering in Medicine (IPEM) — professional guidance for clinical and biomedical engineering.

Références#

1. Medical device — Wikipédia — https://en.wikipedia.org/wiki/Medical_device
2. Internet of things — Wikipédia — https://en.wikipedia.org/wiki/Internet_of_things
3. Clinical engineering — Wikipédia — https://en.wikipedia.org/wiki/Clinical_engineering
4. Biomedical engineering — Wikipédia — https://en.wikipedia.org/wiki/Biomedical_engineering
5. Operational technology — Wikipédia — https://en.wikipedia.org/wiki/Operational_technology
6. Network segmentation — Wikipédia — https://en.wikipedia.org/wiki/Network_segmentation
7. Attack surface — Wikipédia — https://en.wikipedia.org/wiki/Attack_surface
8. Medicines and Healthcare products Regulatory Agency — Wikipédia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
9. Postmarketing surveillance — Wikipédia — https://en.wikipedia.org/wiki/Postmarketing_surveillance
10. Wearable technology — Wikipédia — https://en.wikipedia.org/wiki/Wearable_technology
11. Remote patient monitoring — Wikipédia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
12. Infusion pump — Wikipédia — https://en.wikipedia.org/wiki/Infusion_pump
13. Medicines and Healthcare products Regulatory Agency — Medical devices: guidance and Yellow Card reporting — GOV.UK — https://www.gov.uk/government/organisations/medicines-and-healthcare-products-regulatory-agency
14. National Cyber Security Centre — Guidance on operational technology and device security — NCSC — https://www.ncsc.gov.uk/
15. NHS England — Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
17. Institute of Physics and Engineering in Medicine — Clinical and biomedical engineering guidance — IPEM — https://www.ipem.ac.uk/