Sujet 1.5 — Paysage réglementaire et conformité

En une phrase : La conformité dans la santé et l'action sociale numériques n'est pas une réflexion juridique après coup mais une carte de devoirs statutaires qui se chevauchent, de normes obligatoires, et d'assurance volontaire que vous devez naviguer délibérément, proportionnellement au risque, avec une propriété claire — car se tromper est un échec de sécurité, d'équité et de confiance publique, pas simplement une amende.

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

Dans la plupart des secteurs, la réglementation fixe un plancher : obéissez-y et vous évitez les pénalités. Dans la santé et l'action sociale, le paysage réglementaire encode des leçons durement apprises sur comment les systèmes numériques nuisent aux personnes quand ils échouent — une dose mal étiquetée, un dossier perdu, un algorithme biaisé, une brèche qui expose les données les plus sensibles qu'une personne possède. La conformité ici est un indicateur de si vous avez pensé à ces préjudices du tout. Un dirigeant qui la traite comme de la paperasse vous dit qu'il ne l'a pas fait.

Le paysage est aussi véritablement encombré, et c'est la difficulté. Une seule application destinée aux patients pourrait simultanément être un dispositif médical réglementé par un organisme, traiter des données personnelles sous le ressort d'un autre, être commissionnée seulement si elle passe une évaluation nationale, faire partie d'un service inspecté par un régulateur de soins, et être construite par des cliniciens responsables devant leurs propres régulateurs professionnels. Personne n'a écrit cette carte comme un tout cohérent ; elle s'est accumulée. Votre travail en tant que dirigeant n'est pas de mémoriser chaque règle mais de tenir la forme du terrain — qui couvre quoi, quels instruments sont obligatoires par rapport à consultatifs, et où votre service spécifique se situe à l'intérieur.

Enfin, c'est de l'argent public et un devoir statutaire. Quand vous déployez un système non conforme, vous n'exposez pas seulement votre organisation à des mesures d'application ; vous pouvez violer des devoirs envers des patients et citoyens, et dépenser des fonds publics sur quelque chose que vous ne pouvez pas légalement faire fonctionner. C'est pourquoi ce sujet cadre les sujets plus détaillés qui suivent sur la sécurité clinique (sujet 1.6 — Sécurité clinique et gestion des risques), la gouvernance de l'information (sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité), l'éthique des données (sujet 1.8 — Éthique des données, consentement et confiance publique), et l'assurance (sujet 6.4 — Gouvernance et assurance). Ce sujet est le navigateur ; ceux-là sont les cartes détaillées.

Concepts clés#

Trois niveaux d'obligation. La distinction la plus utile est entre réglementation statutaire, normes obligatoires, et assurance volontaire. La réglementation statutaire est la loi — appliquée par un régulateur avec des pouvoirs légaux, et non négociable (par exemple, le droit de la protection des données, ou l'exigence d'enregistrer un dispositif médical). Les normes obligatoires sont des exigences contractuelles ou de politique que vous devez satisfaire pour opérer au sein d'un système même là où elles ne sont pas une législation primaire — par exemple, des instruments nationaux du NHS auxquels le commissionnement est conditionnel. L'assurance volontaire est là où vous choisissez de démontrer la qualité contre une référence reconnue pour bâtir la confiance, gagner des marchés publics, ou anticiper une future réglementation. Savoir dans quel niveau une exigence donnée se situe vous dit ce qui arrive si vous la manquez : poursuite, exclusion du marché, ou désavantage réputationnel.

La Care Quality Commission (CQC). La Care Quality Commission est le régulateur indépendant de la santé et de l'action sociale des adultes en Angleterre. Elle enregistre, inspecte, et note les prestataires selon que les services sont sûrs, efficaces, bienveillants, réactifs, et bien dirigés. Les services numériques ne lui échappent pas : là où la technologie fait partie de la prestation de soins, les questions de la CQC sur la sécurité et le leadership atteignent les systèmes que vous faites fonctionner, et son domaine « bien dirigé » sonde de plus en plus la maturité numérique et des données.

La MHRA et les dispositifs médicaux. La Medicines and Healthcare products Regulatory Agency (MHRA) réglemente les médicaments et les dispositifs médicaux au Royaume-Uni. De façon cruciale, un logiciel peut être un dispositif médical : Software as a Medical Device (SaMD) est un logiciel destiné à un but médical — diagnostic, prévention, surveillance, traitement — sans faire partie d'un dispositif matériel. Si votre application calcule une dose, trie un symptôme, ou interprète une image, elle est très probablement un dispositif médical et doit être classée, enregistrée, et porter le marquage de conformité approprié avant d'être mise sur le marché.

Marquage de conformité : UKCA et CE. Un dispositif médical placé sur le marché de Grande-Bretagne a besoin du marquage UKCA (UK Conformity Assessed), l'équivalent britannique post-Brexit du marquage CE (Conformité Européenne). Pour l'instant, les dispositifs marqués CE restent acceptés en Grande-Bretagne sous des arrangements transitoires, et l'Irlande du Nord suit les règles de l'UE — donc le marquage dont vous avez besoin dépend de où vous placez le dispositif. C'est un domaine vivant et changeant ; traitez l'exigence exacte comme quelque chose à confirmer, pas à supposer.

NICE et l'Evidence Standards Framework. Le National Institute for Health and Care Excellence (NICE) produit des orientations sur ce qui fonctionne et ce qui est rentable. Son Evidence Standards Framework (ESF) pour les technologies de santé numérique énonce, proportionnellement au risque, la preuve qu'un produit numérique devrait montrer avant que le système ne l'adopte. NICE n'est pas un gardien de licence comme la MHRA, mais ses jugements façonnent lourdement le commissionnement — passer l'enregistrement MHRA prouve qu'un dispositif est sûr à vendre ; satisfaire les attentes de preuve alignées sur NICE aide à prouver qu'il vaut la peine d'être acheté (voir sujet 1.3 — Décisions fondées sur les preuves).

L'ICO et le droit de la protection des données. L'Information Commissioner's Office (ICO) est le régulateur indépendant du Royaume-Uni pour la protection des données et la liberté d'information. Il applique le General Data Protection Regulation (GDPR) britannique et le Data Protection Act 2018, qui gouvernent comment vous pouvez légalement traiter des données personnelles — et les données de santé sont une « catégorie spéciale » attirant les protections les plus fortes. L'ICO peut enquêter, ordonner des changements, et imposer des amendes significatives. Le fond est couvert au sujet 1.7 ; ici, retenez simplement que l'ICO est votre régulateur de protection des données et que les données de santé portent une barre plus haute.

Instruments obligatoires du NHS. Au-delà de la loi primaire, le NHS fait fonctionner ses propres instruments obligatoires. Le Data Security and Protection Toolkit (DSPT) est l'auto-évaluation annuelle que chaque organisation traitant des données de patients du NHS doit compléter pour démontrer des normes de sécurité des données et de gouvernance de l'information. Le Digital Technology Assessment Criteria (DTAC) est la base qu'une technologie de santé numérique doit satisfaire pour être commissionnée par des organisations du NHS, couvrant la sécurité clinique, la protection des données, la sécurité technique, l'interopérabilité, et l'utilisabilité. Les normes de sécurité clinique DCB0129 (pour les fabricants) et DCB0160 (pour les organisations déployantes) mandatent un processus documenté de gestion du risque clinique — un journal des dangers, un responsable de la sécurité clinique, un dossier de sécurité — et sont l'ossature du sujet 1.6.

Régulateurs professionnels. Les personnes, pas seulement les produits, sont réglementées. Le General Medical Council (GMC) enregistre et fixe des normes pour les médecins, et le Nursing and Midwifery Council (NMC) fait de même pour les infirmières et sages-femmes. Quand des cliniciens conçoivent, approuvent, ou exploitent des services numériques, leurs devoirs professionnels voyagent avec eux — un responsable de la sécurité clinique validant un système agit sous une responsabilité professionnelle, pas seulement un rôle d'organigramme.

Horizon et contexte : le régime de l'UE. Même en dehors de l'UE, l'Artificial Intelligence Act et le Règlement (UE) 2017/745 (le Règlement européen sur les dispositifs médicaux, MDR) comptent — ils fixent la direction de voyage, vous lient si vous servez des marchés de l'UE ou l'Irlande du Nord, et souvent préfigurent où les règles britanniques se dirigent ensuite. Le balayage d'horizon pour un tel changement est en soi une discipline de conformité.

La carte et le registre de conformité. Une carte de conformité liste, pour votre service, chaque obligation applicable à travers les trois niveaux, et un registre de conformité enregistre le statut, le propriétaire, la preuve, et la date de revue pour chacune. Ensemble, elles transforment un paysage diffus en une position gérée et auditable — la différence entre « nous pensons que nous sommes conformes » et « voici le propriétaire nommé et la preuve actuelle pour chaque devoir ».

Bonnes pratiques#

1. Classifiez votre service avant de débattre des contrôles. La première question n'est pas « sommes-nous conformes ? » mais « que sommes-nous, légalement ? » Déterminez tôt si votre produit est un dispositif médical (et sa classe de risque), si vous êtes un contrôleur de données ou un sous-traitant, et quels instruments obligatoires du NHS s'appliquent. Se tromper sur la classification rend chaque décision en aval fausse ; bien la faire vous dit lesquels des niveaux et organismes ci-dessus vous lient réellement.

2. Construisez et maintenez une carte et un registre de conformité vivants. Énumérez chaque obligation applicable pour le service à travers la réglementation statutaire, les normes obligatoires, et l'assurance volontaire, et enregistrez pour chacune un propriétaire, un statut actuel, une preuve à l'appui, et une prochaine date de revue. Gardez-le vivant, revu selon un calendrier, pas un document écrit une fois pour un dossier d'analyse et jamais rouvert. Un bon registre répond, à n'importe quel jour donné, « qui possède ce devoir et où est la preuve ? »

3. Assignez une responsabilité à nom unique pour chaque obligation. La responsabilité diffuse est comment la conformité échoue : tout le monde suppose que quelqu'un d'autre la détient. Donnez à chaque devoir un propriétaire nommé — un Data Protection Officer pour la protection des données, un responsable de la sécurité clinique pour DCB0129/0160, un Senior Information Risk Owner pour le DSPT — et rendez la colonne de propriété de la carte réelle, avec l'autorité et le temps pour l'assumer. Une responsabilité non nommée n'est pas une responsabilité.

4. Soyez proportionné et fondé sur le risque, pas cocher-la-case. La réglementation mérite la même proportionnalité que la preuve (voir sujet 1.3) : concentrez la rigueur là où le risque pour les patients, l'équité, et la confiance est le plus élevé, et gardez le travail à faible risque léger. La conformité cocher-la-case — compléter le formulaire tout en manquant l'intention — est à la fois du gaspillage et dangereuse, car elle fabrique une fausse assurance. Visez à satisfaire le but de chaque exigence, ce qui satisfait généralement aussi la lettre.

5. Traitez les instruments obligatoires du NHS comme des entrées de conception, pas des portes de sortie. Le DTAC, le DSPT, et le DCB0129/0160 sont les moins chers et les plus efficaces quand construits dans la livraison dès le début, pas ajoutés avant la mise en production. Un échec DTAC découvert au lancement peut coûter des mois ; un dossier de sécurité clinique assemblé rétrospectivement est mince et peu convaincant. Intégrez ces instruments dans la découverte et la livraison afin que les satisfaire soit un sous-produit de bien travailler.

6. Balayez l'horizon pour le changement réglementaire et possédez la réponse. La réglementation bouge — les calendriers UKCA changent, l'EU AI Act se déploie par phases, le régime software-as-a-medical-device évolue. Assignez quelqu'un pour suivre les régulateurs et consultations pertinents, maintenez une courte liste de surveillance « changement réglementaire » contre votre carte de conformité, et transformez les signaux en travail planifié avant que les échéances ne deviennent des urgences. Être surpris par un changement de règle connu à l'avance est un échec évitable et auto-infligé.

7. Tenez la preuve continuellement, et rendez-la prête pour l'audit. Les régulateurs, commissionnaires, et évaluateurs « bien dirigé » de la CQC vous demandent de montrer, pas d'affirmer. Gardez les journaux des dangers, évaluations d'impact sur la protection des données, soumissions DSPT, et preuves DTAC à jour et récupérables plutôt que de les reconstruire sous la pression d'une inspection. La preuve continue est aussi moins chère que la course périodique qu'elle remplace.

8. Coordonnez à travers les régulateurs plutôt qu'en silos. Parce qu'un service touche de nombreux organismes, ses fonctions de conformité doivent se parler : les propriétaires de sécurité clinique, de gouvernance de l'information, et de produit devraient partager une vue du service, pas en maintenir trois déconnectées. Un changement qui satisfait la MHRA peut créer un problème de protection des données ; une correction UX peut altérer le profil de risque clinique. Faites fonctionner la conformité comme une image coordonnée, liée à votre gouvernance plus large (sujet 6.4 — Gouvernance et assurance).

Questions à discuter avec votre équipe#

1. Pour notre service numérique phare, pouvons-nous nommer chaque régulateur et norme obligatoire qui s'applique, qui possède chacun, et où vit la preuve actuelle — sans que personne n'ait à aller le découvrir ? Cela teste si vous tenez réellement la carte ou croyez simplement être conforme. Cela compte parce que dans la santé et l'action sociale les obligations se chevauchent véritablement — une application de triage peut être un dispositif médical sous la MHRA, une opération de traitement de données sous l'ICO, une technologie commissionnée nécessitant le DTAC, et partie d'un service inspecté par la CQC tout à la fois — et une lacune dans un seul niveau peut arrêter le service ou nuire aux patients. Le tiraillement à faire surgir est entre le confort de supposer « l'IG s'occupe de ça » ou « le fournisseur est réglementé, pas nous » et l'inconfort de confirmer la propriété nommée et la preuve vivante pour chaque devoir. Travaillez sur le service concrètement : listez les organismes, placez chaque obligation dans son niveau (statutaire, obligatoire, volontaire), et essayez de produire la preuve actuelle pour trois d'entre eux sur-le-champ. Si vous ne pouvez pas, vous avez trouvé votre première lacune. Une bonne réponse honnête est un registre de conformité rempli avec des propriétaires nommés et une preuve datée, et une franchise sur quels devoirs sont actuellement non possédés ou non étayés plutôt qu'un geste confiant vers « nous sommes conformes ».

2. Où faisons-nous de la conformité cocher-la-case — satisfaire le formulaire tout en manquant le point — et où sur-ingénions-nous du travail à faible risque ? Le sujet plaide pour une conformité proportionnée et fondée sur le risque, et cette question vous force à vérifier honnêtement les deux directions d'échec. Cela compte parce que la fausse assurance est activement dangereuse dans un cadre critique pour la sécurité : un DSPT marqué « satisfait » ou un dossier de sécurité clinique assemblé la semaine avant la mise en production peut sembler conforme tout en laissant de vrais dangers non gérés, et pendant ce temps un processus d'assurance lourd étranglant un changement de contenu à faible risque gaspille une capacité rare et engendre du cynisme envers tout le régime. Le compromis à débattre est que la proportionnalité exige du jugement et la confiance de le défendre, ce qui est plus difficile à administrer qu'une règle uniforme qui traite tout comme à haut risque. Prenez deux ou trois éléments actuels — un véritablement à haut risque, un faible — et demandez si la rigueur que vous avez appliquée correspondait au risque pour les patients, l'équité, et la confiance, ou était pilotée par l'habitude et la peur. Considérez si votre travail DTAC et DCB0129/0160 façonne véritablement la conception ou est rétro-conçu pour passer. Une bonne réponse nomme une instance précise de case cochée et une instance précise de sur-ingénierie, et s'engage à calibrer la rigueur sur le risque plutôt qu'à appliquer une norme uniforme partout.

3. Comment saurions-nous si une réglementation qui nous affecte est sur le point de changer — et qui est responsable de transformer ce signal en travail planifié ? Cela sonde le balayage d'horizon, la discipline qui sépare les organisations surprises par les échéances de celles qui les planifient. Cela compte parce que le paysage est inhabituellement vivant en ce moment — les calendriers UKCA et marquage CE, le régime software-as-a-medical-device, l'EU AI Act par phases, l'évolution des instruments du NHS — et un changement de règle que vous saviez venir mais pour lequel vous ne vous êtes pas préparé est une blessure auto-infligée qui peut retirer un service du marché. Le tiraillement est que le balayage d'horizon n'a pas de gain immédiat, donc c'est la première chose abandonnée sous pression de livraison, et son absence est invisible jusqu'à ce que l'échéance arrive. Explorez qui suit actuellement les régulateurs et consultations pertinents, s'il y a une liste de surveillance liée à votre carte de conformité, et comment un signal devient un ticket avec un propriétaire et une date plutôt qu'une inquiétude dans la boîte de réception de quelqu'un. Considérez si vous entendriez même parler d'un changement affectant seulement l'Irlande du Nord ou les parties de votre service tournées vers l'UE. Une bonne réponse nomme la personne ou le rôle qui possède le balayage d'horizon réglementaire, pointe vers une liste de surveillance concrète, et décrit la dernière fois qu'un changement à venir a été transformé en travail planifié avant l'échéance.

4. Avons-nous honnêtement classifié ce que nous sommes — un dispositif médical ou non, un contrôleur ou un sous-traitant — ou avons-nous discrètement choisi l'interprétation qui abaisse notre fardeau ? Cela force la décision la plus lourde de conséquences du sujet au grand jour, car la classification pilote chaque obligation en aval et est l'endroit le plus facile pour vous tromper vous-même. Cela compte parce que les incitatifs tirent tous dans un sens : appeler le produit « une application de bien-être » plutôt que Software as a Medical Device, ou « un sous-traitant » plutôt qu'un contrôleur, esquive le coût, la preuve, et l'examen — mais si l'algorithme interprète des données pour informer une action clinique, ou si vous décidez des finalités du traitement, la classification honnête n'est pas optionnelle et le régulateur l'appliquera indépendamment de votre préférence. Le tiraillement est que la lecture moins chère est souvent assez défendable pour survivre à une conversation interne mais pas à une enquête de la MHRA ou de l'ICO, et la mauvaise classification est la voie la plus rapide vers l'application et un pipeline NHS effondré. Travaillez-le concrètement : énoncez ce que le produit fait réellement, prenez un avis juridique plutôt que l'intuition d'un fondateur, et testez si votre classe déclarée survivrait à un régulateur lisant les mêmes faits. Une bonne réponse honnête montre une classification documentée atteinte tôt avec avis, nomme qui l'a validée, et est franche sur tout appel limite et comment il est gardé sous revue à mesure que le produit change.

5. Quand un changement à notre service touche plusieurs régulateurs à la fois, nos fonctions de conformité voient-elles une image unique et partagée — ou trois déconnectées ? Cela teste la coordination, l'échec contre lequel le sujet met en garde quand sécurité clinique, gouvernance de l'information, et produit détiennent chacun une vue partielle. Cela compte parce qu'un seul service s'étend véritablement à travers des organismes — un changement UX à une application de triage peut altérer son profil de risque clinique, une correction qui satisfait la MHRA peut ouvrir une question de protection des données, et une exigence DTAC peut tirer sur toutes — donc une structure en silos signifie que personne ne possède la position de conformité entière et les changements tombent entre les équipes. Le tiraillement est que les fonctions spécialisées sont organisées par discipline pour de bonnes raisons, pourtant le service est vécu par le patient comme une seule chose, et réconcilier ces vues coûte un effort de coordination que nulle équipe seule n'est incitée à financer. Explorez s'il y a une carte de conformité partagée unique par service ou plusieurs privées, si un changement dans un domaine déclenche fiablement une revue dans les autres, et comment cela se lie à la gouvernance au niveau du conseil d'administration (sujet 6.4). Une bonne réponse pointe vers une vue coordonnée unique de chaque service, décrit un changement récent qui a été évalué à travers tous les régulateurs affectés ensemble, et est honnête sur où les disciplines opèrent encore en silos.

6. Là où notre service dépend d'un fournisseur tiers, savons-nous exactement quels devoirs sont les leurs et lesquels restent les nôtres — ou supposons-nous « ils sont réglementés, donc nous sommes couverts » ? Cela fait surgir l'écart de responsabilité partagée que la mauvaise classification et la propriété diffuse alimentent toutes deux, car acheter un composant réglementé ne transfère pas vos propres devoirs. Cela compte parce qu'un fournisseur peut détenir le marquage de conformité de dispositif médical tandis que vous, en tant qu'organisation déployante, devez toujours un dossier de sécurité clinique DCB0160, restez le contrôleur de données pour vos patients, et répondez devant la CQC de comment le service est géré — et la couture entre « leur conformité » et « la vôtre » est exactement où les obligations se perdent. Le tiraillement est aussi commercial que réglementaire : les fournisseurs préfèrent des contrats qui impliquent qu'ils portent le fardeau, et il est tentant d'accepter ce confort plutôt que de cartographier la frontière précisément. Travaillez sur une vraie relation fournisseur : listez ce que le contrat et leur marquage couvrent réellement, ce qui reste votre devoir statutaire ou obligatoire, et si votre registre enregistre cette division avec des propriétaires nommés de votre côté. Une bonne réponse honnête distingue les obligations du fournisseur des vôtres conservées par écrit, nomme qui possède chaque devoir conservé, et peut montrer la preuve que vous détenez plutôt que la preuve que vous supposez que le fournisseur détient.

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

Un système de soins intégrés (ICS) prévoit de déployer une application smartphone qui permet aux patients avec des conditions de longue durée d'enregistrer des symptômes, et utilise un algorithme pour signaler ceux qui pourraient se détériorer pour une revue clinique. La tentation est de la traiter comme « juste une application » et de la pousser en production.

Au lieu de cela, le directeur numérique commence par la classification. Parce que l'algorithme interprète les données du patient pour informer une action clinique, l'avis juridique confirme que c'est Software as a Medical Device, donc le régime de la MHRA s'applique et le fournisseur doit détenir le marquage de conformité correct pour le marché de Grande-Bretagne — une question UKCA que l'équipe signale à surveiller à mesure que les arrangements transitoires CE évoluent. L'ICS est un contrôleur de données pour les données du patient, donc les devoirs de protection des données de l'ICO le lient, et une évaluation d'impact sur la protection des données est ouverte (alimentant le sujet 1.7). Parce qu'elle est commissionnée par des organismes du NHS, le DTAC s'applique, et parce qu'elle est déployée dans un usage clinique, le DCB0160 exige un dossier de sécurité clinique, un journal des dangers, et un responsable de la sécurité clinique nommé (sujet 1.6).

L'équipe construit une carte de conformité : chaque obligation placée dans son niveau, chacune avec un propriétaire nommé — Data Protection Officer, responsable de la sécurité clinique, Senior Information Risk Owner, responsable produit — et un registre suivant le statut et la preuve. Plutôt que de traiter le DTAC et le dossier de sécurité comme des portes de mise en production, ils les intègrent dans la livraison dès la découverte, afin que le journal des dangers grandisse avec la conception. L'Evidence Standards Framework de NICE façonne quelle preuve d'efficacité ils exigent du fournisseur avant de passer à l'échelle. Une note de balayage d'horizon signale l'EU AI Act comme pertinent pour le futur de l'algorithme et pour toute ambition tournée vers l'UE. Quand la CQC revoit plus tard le leadership du service, l'ICS répond aux questions « bien dirigé » avec un registre vivant et une preuve actuelle plutôt qu'une course. L'application est livrée plus tard que le plan naïf, et légalement.

Angles sectoriels#

Le même paysage impose des fardeaux très différents selon où vous vous situez.

Startup#

Une petite entreprise de santé numérique ressent les régimes de dispositif médical et DTAC le plus vivement, car les satisfaire coûte de l'argent et du temps qu'elle n'a peut-être pas, et la tentation est de sous-classifier — d'insister que le produit est « juste une application de bien-être », pas un dispositif médical — pour esquiver le fardeau. C'est le mouvement le plus dangereux disponible : la mauvaise classification est la voie la plus rapide vers une action d'application et un pipeline de ventes NHS effondré. Le chemin discipliné est de classifier honnêtement et tôt, construire une carte de conformité légère mais réelle, et traiter le DTAC et une posture de protection des données propre comme des atouts de vente qui ouvrent le marché du NHS plutôt que des obstacles à celui-ci. Un propriétaire nommé pour le balayage d'horizon réglementaire peut être un seul fondateur portant une autre casquette, mais la liste de surveillance doit quand même exister.

Petite entreprise#

Un petit prestataire établi — un cabinet de médecine générale, une pharmacie communautaire, un établissement de soins, une clinique à site unique, ou un petit fournisseur de technologie de santé passé le stade de startup — porte les mêmes devoirs statutaires et obligatoires qu'un grand trust mais sans Data Protection Officer, responsable de la sécurité clinique, ou équipe de conformité pour les assumer. Le DSPT doit quand même être complété chaque année, les données patients attirent quand même la barre de catégorie spéciale, et tout logiciel clinique déployé attire quand même le DCB0160, pourtant ceux-ci atterrissent généralement sur un gestionnaire de cabinet ou propriétaire déjà en train de gérer les opérations. Le mouvement réaliste est de rendre la carte de conformité délibérément petite mais réelle, de s'appuyer sur une expertise partagée ou commissionnée — une fédération, une CSU, ou la documentation de sécurité clinique d'un fournisseur — plutôt que de prétendre détenir chaque spécialisme en interne, et d'être scrupuleux sur les devoirs qui ne peuvent pas être délégués, tels que rester le contrôleur de données pour vos propres patients. Traiter l'assurance d'un fournisseur comme couvrant vos devoirs conservés est le piège caractéristique ici : achetez de l'aide, mais gardez la propriété nommée de ce qui est légalement à vous.

Grande entreprise#

Un trust NHS ou un grand ICS détient de nombreux services à la fois, donc son défi est la coordination à l'échelle du portefeuille : des dizaines de systèmes, chacun touchant plusieurs régulateurs, avec des obligations qui ne doivent pas tomber entre les équipes. Le mode de défaillance est les silos organisationnels — sécurité clinique, gouvernance de l'information, et achats détenant chacun une vue partielle, donc personne ne voit la position de conformité entière d'un service donné. Le correctif est une carte de conformité partagée par service, une responsabilité à nom unique liée à la gouvernance au niveau du conseil d'administration (sujet 6.4), et une preuve continue prête pour l'audit afin qu'une revue « bien dirigé » de la CQC ou une enquête de l'ICO soit répondue depuis une position vivante. Une grande entreprise de technologie de santé ou pharmaceutique apporte une machinerie d'affaires réglementaires mature mais doit se prémunir contre la traiter comme une usine de conformité déconnectée de comment les produits sont réellement construits.

Gouvernement#

Un organisme national — NHS England, le Department of Health and Social Care, la MHRA, NICE — est souvent le régulateur ou l'auteur de l'instrument obligatoire, donc ses façons de travailler fixent la barre que tout le système doit franchir, et ses décisions attirent un examen parlementaire et public. Ici, le travail de conformité est une responsabilité à l'échelle de la population : un instrument comme le DTAC ou l'ESF façonne un marché entier, donc la proportionnalité et la clarté dans la norme elle-même sont des devoirs, pas des agréments, car une exigence nationale mal calibrée soit bloque une innovation utile partout, soit laisse passer le risque partout. Les organismes nationaux portent aussi la responsabilité de balayage d'horizon pour le système, anticipant comment l'EU AI Act, le MDR, et les régimes de marquage de conformité devraient façonner la politique britannique. La transparence sur ce qu'une norme exige et pourquoi fait partie du maintien de la confiance publique à l'échelle.

Modes de défaillance courants#

• Mauvaise classification. Insister qu'un produit n'est pas un dispositif médical, ou que vous êtes un sous-traitant et non un contrôleur, pour esquiver un fardeau. Antidote : classifiez honnêtement et tôt, avec avis juridique ; la classification pilote tout le reste.
• Conformité cocher-la-case. Compléter le DSPT ou un dossier de sécurité pour passer, tandis que le risque sous-jacent est non géré. Antidote : satisfaites le but, pas seulement la forme ; testez si l'artefact a réellement façonné la conception.
• Conformité comme porte de mise en production. Découvrir des lacunes DTAC ou de sécurité clinique au lancement. Antidote : intégrez les instruments obligatoires dans la livraison dès la découverte.
• Propriété diffuse. Chaque devoir supposé être celui de quelqu'un d'autre. Antidote : responsabilité à nom unique par obligation dans un registre vivant.
• Régulateurs en silos. Sécurité clinique, IG, et produit détenant des vues déconnectées d'un service. Antidote : une carte de conformité partagée, gouvernance coordonnée.
• Aucun balayage d'horizon. Être surpris par un changement de règle que vous auriez pu voir venir. Antidote : une liste de surveillance possédée liée à la carte de conformité.
• Preuve obsolète. Reconstruire les journaux des dangers et évaluations sous pression d'inspection. Antidote : preuve continue, prête pour l'audit.

Modèle de maturité#

Liste de contrôle#

• La classification légale du service (dispositif médical et classe ; contrôleur/sous-traitant) est confirmée et documentée.
• Une carte de conformité vivante liste chaque obligation à travers les niveaux statutaire, obligatoire, et volontaire.
• Chaque obligation a un propriétaire nommé unique avec l'autorité et le temps pour l'assumer.
• Les instruments obligatoires du NHS (DTAC, DSPT, DCB0129/0160) sont construits dans la livraison, pas ajoutés à la mise en production.
• La rigueur est calibrée au risque pour les patients, l'équité, et la confiance — pas une case uniforme.
• La preuve (journaux des dangers, DPIA, DSPT, DTAC) est actuelle, récupérable, et prête pour l'audit.
• Un propriétaire nommé gère le balayage d'horizon réglementaire contre une liste de surveillance maintenue.
• Les exigences de marquage de conformité (UKCA/CE) pour le marché pertinent sont confirmées, pas supposées.
• Les fonctions de conformité partagent une vue coordonnée de chaque service, liée à la gouvernance (sujet 6.4).
• Le registre est revu selon un calendrier, pas écrit une fois et abandonné.

Sources clés#

• Care Quality Commission — How CQC regulates et le cadre d'évaluation unique (cqc.org.uk).
• MHRA — Medical devices: software applications (apps) et orientations Software and AI as a Medical Device (gov.uk).
• NICE — Evidence Standards Framework for digital health technologies (ESF) (nice.org.uk).
• Information Commissioner's Office — Guide to Data Protection et Guide to the UK GDPR (ico.org.uk).
• NHS England — Data Security and Protection Toolkit (DSPT) (dsptoolkit.nhs.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC).
• NHS Digital / NHS England — normes de gestion du risque clinique DCB0129 et DCB0160.
• GMC — Good medical practice ; NMC — The Code (normes professionnelles).
• GOV.UK — orientations UKCA marking et CE marking pour le marché de Grande-Bretagne.

Références#

1. Regulatory compliance — Wikipédia — https://en.wikipedia.org/wiki/Regulatory_compliance
2. Care Quality Commission — Wikipédia — https://en.wikipedia.org/wiki/Care_Quality_Commission
3. Medicines and Healthcare products Regulatory Agency — Wikipédia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
4. Medical device — Wikipédia — https://en.wikipedia.org/wiki/Medical_device
5. UKCA marking — Wikipédia — https://en.wikipedia.org/wiki/UKCA_marking
6. CE marking — Wikipédia — https://en.wikipedia.org/wiki/CE_marking
7. National Institute for Health and Care Excellence — Wikipédia — https://en.wikipedia.org/wiki/National_Institute_for_Health_and_Care_Excellence
8. Information Commissioner's Office — Wikipédia — https://en.wikipedia.org/wiki/Information_Commissioner%27s_Office
9. General Data Protection Regulation — Wikipédia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
10. Data Protection Act 2018 — Wikipédia — https://en.wikipedia.org/wiki/Data_Protection_Act_2018
11. General Medical Council — Wikipédia — https://en.wikipedia.org/wiki/General_Medical_Council
12. Nursing and Midwifery Council — Wikipédia — https://en.wikipedia.org/wiki/Nursing_and_Midwifery_Council
13. Artificial Intelligence Act — Wikipédia — https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
14. Regulation (EU) 2017/745 (EU Medical Device Regulation) — Wikipédia — https://en.wikipedia.org/wiki/Regulation_(EU)_2017/745
15. How CQC regulates — Care Quality Commission — https://www.cqc.org.uk/about-us/how-we-do-our-job/how-we-regulate
16. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
17. Evidence Standards Framework for digital health technologies (ESF) — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
18. Guide to the UK GDPR — Information Commissioner's Office — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/
19. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
20. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
21. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
22. UKCA marking guidance — GOV.UK — https://www.gov.uk/guidance/using-the-ukca-marking