Sujet 1.0 — Façons de travailler dans la santé et l'action sociale numériques

En une phrase : Les façons de travailler sont les habitudes délibérées et partagées — comment vous organisez les équipes, prenez des décisions, gérez le risque et livrez de la valeur — qui permettent à une organisation de santé et d'action sociale de transformer l'intention en résultats sûrs, équitables et fondés sur les preuves pour les patients et les citoyens.

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

Chaque organisation a des façons de travailler, qu'elles soient choisies ou héritées. Dans la santé et l'action sociale numériques, celles que vous héritez sont généralement inadaptées à la tâche : elles ont été conçues pour des projets de type construction, à périmètre fixe, et non pour des services adaptatifs qui touchent à la sécurité clinique, au devoir statutaire et à l'argent public. Les corriger n'est pas un raffinement administratif ; c'est ce qui distingue un dossier de soins partagé auquel les cliniciens font confiance d'un dossier qui reste inutilisé.

La santé et l'action sociale se distinguent de façons qui façonnent chaque pratique de ce livre. La sécurité est non négociable — un défaut dans un service numérique peut nuire à un patient, donc la gestion du risque clinique (voir sujet 1.6 — Sécurité clinique et gestion des risques) est tissée dans la livraison, pas ajoutée après coup. L'équité compte parce qu'un service qui ne fonctionne que pour les personnes à l'aise avec le numérique aggrave les inégalités de santé ; les populations Core20PLUS5 et les personnes à accès numérique limité doivent être prises en compte dans la conception, pas exclues par elle. Les devoirs statutaires — l'engagement du NHS envers des soins complets, le droit de la protection des données, le devoir de confidentialité — contraignent ce que vous pouvez faire avec les données et comment vous devez consulter. L'argent public exige un contrôle des dépenses proportionné et une valeur démontrable. Et presque rien n'est livré par un seul organisme : le partenariat entre systèmes de soins intégrés (ICS), autorités locales, prestataires d'action sociale et fournisseurs est la condition opérationnelle par défaut.

Ces quatre pressions — sécurité, équité, devoir, argent — expliquent pourquoi vous ne pouvez pas simplement copier un manuel de la tech grand public. Vous avez besoin de façons de travailler à la fois agiles et responsables, rapides et sûres, centrées sur l'utilisateur et équitables pour la population.

Concepts clés#

Les façons de travailler opèrent à trois niveaux. Au niveau de l'équipe, ce sont les pratiques quotidiennes : mêlées, recherche utilisateur, livraison itérative, travail en binôme. Au niveau organisationnel, c'est le modèle opérationnel — comment la stratégie devient des flux de valeur, des capacités, un financement et des droits de décision (voir sujet 1.1 — Le modèle opérationnel). Au niveau du système, c'est la façon dont des organisations indépendantes s'alignent : normes partagées, interopérabilité et gouvernance commune au sein d'un ICS. Ce livre se déplace délibérément à travers ces trois niveaux.

La conception centrée sur l'utilisateur signifie partir des besoins des personnes qui utilisent un service — patients, aidants, cliniciens, administrateurs — plutôt que d'une solution présupposée. Le Government Digital Service (GDS) britannique et le NHS ont codifié cela dans leurs normes de service : comprendre les utilisateurs et leurs besoins avant de construire, et continuer à tester avec de vrais utilisateurs tout au long du processus.

La livraison agile et itérative signifie mettre un service fonctionnel devant de vrais utilisateurs tôt, apprendre et s'adapter — plutôt que tout spécifier à l'avance. Le manuel de service numérique du NHS est explicite : les façons de travailler agiles et centrées sur l'utilisateur réduisent le risque de construire la mauvaise chose. L'agilité est ici autant une stratégie de gestion du risque qu'une méthode de livraison.

Les équipes multidisciplinaires (MDT) rassemblent, dans une seule équipe habilitée, le mélange de compétences dont un service a besoin : gestion de produit et de livraison, recherche utilisateur et conception, ingénierie, expertise clinique et de gouvernance de l'information, et connaissance opérationnelle. La norme de service du NHS exige des équipes incluant des compétences et perspectives multidisciplinaires — y compris l'accès à un avis clinique, juridique ou de politique spécialisé. La MDT est l'atome de la livraison numérique ; la plupart des échecs remontent à une discipline manquante autour de la table.

Le produit plutôt que le projet. Un projet a un début, une fin et une passation ; un produit est financé et géré pour toute sa vie. Le passage d'une logique de projet à une logique de produit (voir sujet 1.1 et sujet 5.0 — Travail piloté par le produit) change le financement, les équipes et la responsabilité, et convient bien mieux aux services de santé — qui sont durables et en évolution continue — que les projets ponctuels.

Bonnes pratiques#

1. Partez des besoins des utilisateurs, étayés par la recherche. Avant de vous engager dans une construction, comprenez qui sont les utilisateurs, ce qu'ils essaient de faire, et où le service actuel les laisse tomber. Financez une découverte (voir sujet 3.4 — Phases de découverte) et traitez « nous avons supposé » comme un signal d'alarme. Les besoins des utilisateurs, pas les préférences internes, sont l'ancre de chaque décision ultérieure.

2. Constituez des équipes multidisciplinaires, habilitées et stables. Rassemblez tout l'éventail de compétences — y compris la sécurité clinique et la gouvernance de l'information — et donnez à l'équipe l'autorité de décider dans des limites claires. Maintenez les équipes ensemble autour d'un service plutôt que de les dissoudre à chaque frontière de projet ; les équipes stables accumulent la connaissance du domaine et de la sécurité qu'exigent les services de santé.

3. Travaillez de façon ouverte et itérez par petits pas. Livrez de fines tranches, mesurez, ajustez. Des versions petites et fréquentes sont plus sûres que des lancements en un seul bloc, car les problèmes apparaissent tant qu'ils sont encore petits, et elles permettent à la revue de sécurité clinique et de gouvernance de l'information de suivre le rythme du changement plutôt que de devenir un verrou final.

4. Faites de la sécurité et de l'équité des priorités absolues dès le premier jour. Menez la gestion du risque clinique (DCB0129/DCB0160) et l'analyse d'égalité et d'inégalités de santé en parallèle de la livraison, pas comme des validations de fin de course. Demandez-vous tôt qui pourrait être exclu ou lésé, et concevez pour les cas les plus difficiles — parcours numériques assistés, accessibilité (WCAG), et solutions de repli hors ligne.

5. Décidez avec des preuves, et consignez la décision. Distinguez les preuves cliniques (est-ce que cela fonctionne et est-ce sûr ?) des preuves de livraison (le construisons-nous bien, et est-il utilisé ?), et tenez un journal de décisions léger pour que le raisonnement survive au turnover du personnel (voir sujet 1.3 — Décisions fondées sur les preuves). Les preuves l'emportent sur l'opinion de la personne la mieux payée.

6. Concevez pour l'interopérabilité et la réutilisation. Les données de santé et d'action sociale doivent circuler en toute sécurité entre organisations ; construisez selon des normes ouvertes (HL7 FHIR, SNOMED CT) et réutilisez des plateformes plutôt que de les réinventer (voir la « plateforme viable la plus mince » du sujet 1.1 et le sujet 4.3 — Interopérabilité et normes de données). Un service qui ne peut pas partager de données est un silo qui attend de devenir un risque.

7. Gouvernez de façon proportionnée. Adaptez le poids de l'assurance au niveau de risque. Les changements cliniques à haut risque méritent un examen approfondi ; les changements de contenu à faible risque ne devraient pas attendre des semaines un conseil d'administration. Une gouvernance proportionnée vous garde à la fois sûr et rapide.

8. Travaillez de façon ouverte. Partagez les plans, décisions, feuilles de route et — lorsque c'est sûr — le code, afin que partenaires, cliniciens et public puissent voir comment et pourquoi les choix sont faits. L'ouverture bâtit la confiance, réduit la duplication dans un système fragmenté, et invite la contestation avant que les erreurs ne se figent en services en production. Dans la santé et l'action sociale, être transparent sur ce qu'un service fait des données, et pourquoi, est en soi une pratique de confiance et de sécurité.

9. Concevez pour le long terme et pour la passation. Les services numériques en santé survivent aux équipes et aux contrats qui les construisent, alors consignez les décisions, évitez le savoir non documenté du « héros », et concevez pour les personnes qui feront fonctionner et évoluer le service pendant des années (voir sujet 10.3 — Gestion des connaissances et documentation). Traitez la durabilité — de l'équipe, de la technologie et du modèle de financement — comme une contrainte de premier ordre, pas comme une réflexion après coup.

Questions à discuter avec votre équipe#

1. Où nos façons de travailler actuelles sont-elles héritées plutôt que choisies, et quelle habitude héritée nous coûte-t-elle le plus en sécurité, en équité ou en dépenses gaspillées ? Cette question force un audit honnête des pratiques que personne n'a décidées mais que tout le monde suit — financement de programme à périmètre fixe, équipes projet dissoutes puis reconstruites, gouvernance consultée seulement à la mise en production. Elle compte parce que les habitudes héritées sont généralement invisibles tant qu'on ne les nomme pas, et dans la santé et l'action sociale elles ont un coût réel : un dossier partagé auquel les cliniciens ne font pas confiance, un service qui exclut les populations Core20PLUS5, ou une reconstruction de la même plomberie de connexion avec de l'argent public. Le tiraillement à débattre est que les façons héritées paraissent souvent sûres précisément parce qu'elles sont familières et auditables, si bien que les abandonner ressemble à prendre un risque plutôt qu'à en retirer un. Ancrez la discussion dans des éléments concrets — examinez vos trois derniers dossiers d'analyse, le turnover de vos équipes entre projets, et le moment où la sécurité clinique a été engagée pour la première fois — plutôt que d'échanger des opinions. Une bonne réponse nomme une ou deux habitudes précises avec des preuves de leur coût, distingue celles qui valent la peine d'être conservées de celles qui nuisent activement aux résultats, et s'engage sur un changement dont un dirigeant senior sera responsable.

2. Nos équipes disposent-elles vraiment de tout l'éventail de compétences multidisciplinaires — y compris la sécurité clinique et la gouvernance de l'information — au sein même de l'équipe, ou ces disciplines sont-elles encore ajoutées comme des verrous de fin de course ? Le sujet soutient que la MDT est l'atome de la livraison numérique et que la plupart des échecs remontent à une discipline manquante autour de la table, donc cette question teste si ce principe est réel dans votre organisation ou simplement aspirationnel. Elle compte parce qu'un responsable de la sécurité clinique ou un Caldicott Guardian engagé seulement à la mise en production force soit une reprise du travail, soit des raccourcis dangereux, alors qu'une personne intégrée dès la première semaine tient un journal des dangers vivant qui cadence la livraison. Le compromis à faire surgir est le coût et la rareté : le temps clinique, juridique et de gouvernance de l'information spécialisé est réellement limité, donc « intégrer tout le monde dans chaque équipe » se heurte à de vraies contraintes de ressources, et l'équipe doit décider où des rôles fractionnaires ou partagés sont acceptables et où ils ne le sont pas. Examinez un service actuel et cartographiez qui est réellement dans l'équipe permanente par rapport à qui est consulté comme une validation externe, et vérifiez si l'équipe a l'autorité de décider dans des limites claires ou doit constamment escalader. Une bonne réponse honnête est précise sur les disciplines manquantes ou empruntées, reconnaît franchement le tiraillement des ressources, et propose un modèle concret — temps plein, fractionnaire ou d'astreinte — pour combler l'écart sans faire semblant que la rareté n'existe pas.

3. Quand avons-nous traité un service numérique comme un projet avec une passation plutôt que comme un produit géré pour toute sa vie, et qu'est-ce que cela nous a coûté en connaissance perdue du domaine et de la sécurité ? Le produit plutôt que le projet est l'un des virages structurants du sujet, et cette question amène l'équipe à confronter où elle finance et dote encore en personnel pour la clôture plutôt que pour la continuité. Elle compte parce que les services de santé sont durables et en évolution continue ; une équipe dissoute à la frontière du projet emporte avec elle exactement la connaissance clinique et opérationnelle accumulée qui garde un service sûr, et le « purgatoire des pilotes » en est le symptôme récurrent. Le vrai tiraillement est financier et structurel : le financement produit exige des budgets permanents et défie le modèle d'appel d'offres annuel et limité dans le temps sur lequel finance et gouvernance sont construites, donc c'est autant une conversation sur l'argent et la responsabilité que sur la livraison. Considérez un service précis qui a subi une passation — retracez ce qui est arrivé à son journal des dangers, sa recherche utilisateur, et son équipe — et pesez cela face à la discipline qu'exige le financement produit. Une bonne réponse identifie un cas concret, quantifie ou au moins caractérise la connaissance perdue, et est franche sur les obstacles organisationnels (cycles de financement, règles de ressourcement, structures de gouvernance) qui devraient bouger pour que des équipes produit permanentes deviennent la norme.

4. Qui risque le plus d'être exclu ou lésé par les services que nous construisons, et pouvons-nous montrer où nous avons conçu pour eux en premier plutôt qu'en dernier ? Le sujet insiste sur le fait que l'équité est non négociable et qu'un service qui ne fonctionne que pour les personnes à l'aise avec le numérique aggrave les inégalités de santé, donc cette question teste si « concevoir pour les cas les plus difficiles » est une pratique vivante ou un slogan. Elle compte parce que l'exclusion dans la santé et l'action sociale n'est pas un inconvénient mais un préjudice de sécurité et d'accès : les populations Core20PLUS5, les personnes à accès numérique limité, à faible littératie en santé, ou sans smartphone sont précisément celles dont les besoins sont les plus grands, et un service qui les exclut concentre le préjudice là où il est le moins supportable. Le tiraillement à faire surgir est que concevoir pour les marges coûte du temps et de l'argent en amont — parcours numériques assistés, accessibilité selon les WCAG, solutions de repli hors ligne et non numériques, traduction — et ces coûts sont faciles à reporter quand une échéance de livraison approche et que la majorité à l'aise peut déjà utiliser la chose. Examinez un service réel et demandez qui figure dans son échantillon de recherche utilisateur, si une analyse d'égalité et d'inégalités de santé a réellement façonné une décision de conception, et ce qui arrive à quelqu'un qui ne peut pas ou ne veut pas se connecter. Une réponse honnête nomme les groupes précis à risque pour ce service, montre au moins un choix de conception concret fait pour eux, et est franche sur les moments où l'équipe a sacrifié l'inclusion sous la pression et sur la façon dont elle défendrait ce compromis la prochaine fois.

5. Où réinventons-nous une plomberie qui existe déjà, et où construire selon des normes ouvertes et réutiliser des plateformes partagées changerait-il vraiment ce que nous livrons ? Concevoir pour l'interopérabilité et la réutilisation est l'une des bonnes pratiques du sujet, et cette question amène l'équipe à confronter la tentation de construire sur mesure plutôt que de réutiliser — la connexion, les notifications, l'intégration au dossier qu'une douzaine d'autres équipes ont aussi construites. Elle compte parce que dans un système fragmenté, chaque composant réinventé est de l'argent public dépensé deux fois et un nouveau silo incapable d'échanger des données en toute sécurité ; à l'inverse, construire selon HL7 FHIR et SNOMED CT et réutiliser la plateforme viable la plus mince est ce qui permet à un service de passer les marchés publics et de partager des données à travers un ICS. Le vrai compromis est que la réutilisation signifie une dépendance : une plateforme partagée peut être plus lente, moins adaptée, ou gouvernée par la feuille de route de quelqu'un d'autre, donc l'équipe doit peser le frein d'un composant partagé face au coût et au risque à long terme d'un silo sur mesure. Examinez une construction actuelle et listez ce qui est vraiment nouveau par rapport à ce qui duplique une plateforme, une norme ou un composant ouvert existant, et vérifiez si « nous ne pouvons pas réutiliser cela » est une contrainte étayée ou une hypothèse non testée. Une bonne réponse distingue les parties qui valent la peine d'être construites de celles qui valent la peine d'être réutilisées, est honnête sur la maturité et la gouvernance des plateformes disponibles, et s'engage sur des normes ouvertes pour tout ce qui doit échanger des données.

6. Comment adaptons-nous le poids de notre gouvernance au niveau de risque, et où l'assurance est-elle actuellement soit trop lourde pour un changement à faible risque, soit trop légère pour un changement à haut risque ? La gouvernance proportionnée est une idée structurante de ce sujet — les changements cliniques à haut risque méritent un examen approfondi tandis que les changements de contenu à faible risque ne devraient pas attendre des semaines un conseil d'administration — et cette question teste si l'organisation calibre l'assurance sur le risque ou applique un processus unique et rigide à tout. Elle compte parce qu'une gouvernance mal calibrée nuit dans les deux sens : un verrou lourd et uniforme pousse les équipes à regrouper les changements et ralentit l'itération même qui garde les services sûrs, tandis qu'une légèreté uniforme laisse passer un changement clinique véritablement à haut risque sans l'examen de sécurité clinique et de gouvernance de l'information dont il a besoin. Le tiraillement est que la proportionnalité exige du jugement, et le jugement est inconfortable pour les conseils d'administration et les auditeurs qui trouvent une liste de contrôle unique et obligatoire plus facile à défendre qu'un parcours hiérarchisé par risque. Examinez comment vos douze derniers changements ont été assurés, classez-les par risque clinique et de données réel, et voyez si l'effort dépensé suivait le risque ou le calendrier. Une réponse honnête identifie des exemples concrets de sur-gouvernance et de sous-gouvernance, propose des critères clairs pour hiérarchiser le changement par risque, et nomme qui détient l'autorité de décider du niveau et d'en être responsable.

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

Un système de soins intégrés veut donner aux cliniciens de trois trusts de soins aigus, des services communautaires et de l'action sociale des autorités locales un dossier de soins partagé. L'ancienne façon consisterait à commissionner un programme à périmètre fixe, à spécifier chaque écran à l'avance, et à intégrer tardivement.

Au lieu de cela, l'ICS forme une équipe multidisciplinaire : un chef de produit, un responsable de livraison, un chercheur utilisateur, un designer d'interaction, deux ingénieurs, un responsable de la sécurité clinique, et un responsable de la gouvernance de l'information, avec accès à un Caldicott Guardian et à un praticien de l'action sociale. Ils mènent une découverte de huit semaines, observant comment une infirmière de secteur, un consultant des urgences et un travailleur social essaient réellement de trouver l'information aujourd'hui. Ils découvrent que la vraie difficulté n'est pas « pas de données » mais « des données dont ils ne peuvent pas faire confiance à l'actualité ».

L'équipe livre un alpha restreint : accès en lecture seule aux allergies, aux médicaments et au statut actuel du plan de soins pour un parcours clinique, avec un horodatage visible de « dernière mise à jour ». La sécurité clinique fonctionne en parallèle ; un journal des dangers est tenu dès la première semaine. Ils mesurent si les cliniciens arrêtent d'appeler d'autres équipes pour confirmer une information. Ce n'est qu'une fois que cette fine tranche s'avère utile et sûre qu'ils élargissent le dossier — financé comme un produit continu, pas comme un projet clos.

Angles sectoriels#

Les mêmes quatre pressions — sécurité, équité, devoir, argent — pèsent sur chaque organisation, mais les façons de travailler qui y répondent varient avec l'échelle, le financement et la responsabilité.

Startup#

Une petite entreprise de santé numérique vit ou meurt par le focus, donc ses façons de travailler sont légères par nécessité : une équipe multidisciplinaire, une prise de décision horizontale, et un contact quotidien avec les utilisateurs. La contrainte est la trésorerie disponible, pas des règles d'effectif, donc la découverte se mesure en semaines et les preuves sont réunies à moindre coût — une poignée d'entretiens cliniques, un prototype cliquable, un journal des dangers honnête tenu par un responsable de la sécurité clinique fractionnaire. Le danger est de sacrifier la rigueur de sécurité et de gouvernance de l'information pour atteindre une échéance d'investisseur ; la discipline qui résiste à l'examen est de traiter le DCB0129 et une analyse d'impact sur la protection des données comme des critères d'entrée pour un pilote, pas comme de la paperasse reportée jusqu'à ce qu'un trust le demande. L'interopérabilité dès le premier jour (FHIR, SNOMED CT) est aussi un atout commercial, car une startup incapable d'échanger des données ne passera jamais les marchés publics du NHS.

Petite entreprise#

Un petit prestataire établi — un cabinet de médecine générale, une pharmacie communautaire, un établissement de soins ou une agence de soins à domicile, une clinique à site unique, ou un modeste fournisseur de technologie de santé passé le stade de pré-revenu — porte les mêmes pressions de sécurité, d'équité, de devoir et d'argent qu'un grand trust mais avec une fraction de la capacité pour y répondre. Les façons de travailler doivent ici être radicalement proportionnées : il n'y a rarement pas d'équipe numérique ou de gouvernance de l'information dédiée, donc « l'équipe multidisciplinaire » est souvent une poignée de personnes portant plusieurs casquettes plus une ressource de sécurité clinique et de protection des données partagée ou externalisée. Le piège est de supposer que les devoirs statutaires s'échelonnent avec la taille de l'organisation — ce n'est pas le cas, donc la sécurité clinique DCB0129/DCB0160, une analyse d'impact sur la protection des données, et l'accessibilité s'appliquent toujours pleinement même quand un seul gestionnaire de cabinet en est responsable. La discipline pratique consiste à s'appuyer fortement sur la réutilisation plutôt que sur la construction : adopter des systèmes accrédités sur étagère, exiger que les fournisseurs respectent le DTAC et les normes ouvertes (FHIR, SNOMED CT), et utiliser les plateformes nationales et fournies par l'ICS afin que sécurité, interopérabilité et gouvernance de l'information soient héritées plutôt que réinventées avec des moyens limités.

Grande entreprise#

Un trust NHS ou un ICS a le problème inverse : un processus abondant et une propriété fragmentée. Les façons de travailler y consistent autant à désapprendre — abandonner les habitudes de programme à périmètre fixe, mettre fin aux équipes projet dissoutes puis reconstruites — qu'à adopter de nouvelles pratiques. La responsabilité est formelle et personnelle (un propriétaire senior responsable, un Caldicott Guardian, une validation de sécurité clinique au niveau du conseil d'administration), donc le gain consiste à intégrer ces rôles dans l'équipe de livraison plutôt qu'à les ajouter comme des verrous. Un grand fournisseur de technologie de santé ou pharmaceutique fait face à l'image inverse : une forte maturité d'ingénierie mais une distance par rapport à la réalité clinique de terrain, que des équipes multidisciplinaires avec du vrai temps clinicien existent pour combler.

Gouvernement#

Un organisme public national ou local — NHS England, le DHSC, l'UKHSA, une autorité locale — fixe les normes selon lesquelles tous les autres travaillent, donc ses façons de travailler se répercutent vers l'extérieur. Sa responsabilité est envers le Parlement et le public, ce qui élève la barre en matière de transparence, de contrôle des dépenses et d'équité : une norme de service, un parcours d'assurance publié, et les devoirs Core20PLUS5 sont des instruments de cette responsabilité, pas des options facultatives. Le risque à cette échelle est de concevoir de façon centralisée pour un citoyen moyen qui n'existe pas et de mandater une solution avant de comprendre le besoin local. Le correctif est la même discipline centrée sur l'utilisateur et itérative que partout ailleurs, appliquée avec un biais vers la définition de normes ouvertes et de plateformes réutilisables sur lesquelles des organisations fédérées peuvent s'appuyer — gouverner le système, pas seulement livrer un service.

Modes de défaillance courants#

• Livraison axée sur la solution en premier. S'engager sur un produit nommé avant de comprendre le besoin. Antidote : financer une découverte et faire des besoins utilisateurs le critère d'entrée pour la construction.
• Gouvernance comme verrou tardif. Sécurité clinique et gouvernance de l'information consultées seulement à la mise en production, forçant une reprise du travail ou des raccourcis dangereux. Antidote : intégrer les deux dans l'équipe dès le premier jour.
• Rotation de projets. Constituer des équipes puis les démanteler, perdant une connaissance du domaine et de la sécurité durement acquise. Antidote : financement produit et équipes permanentes.
• Purgatoire des pilotes. Des pilotes sans fin qui ne passent jamais à l'échelle parce que l'adoption, la formation et le changement métier n'ont jamais été financés (voir sujet 8.1 — Conduite du changement). Antidote : planifier le chemin vers l'échelle avant le pilote.
• Équité comme réflexion après coup. Concevoir pour la majorité à l'aise et exclure les personnes qui ont le plus besoin de soins. Antidote : concevoir pour les cas les plus difficiles en premier.

Modèle de maturité#

Liste de contrôle#

• Chaque service a une équipe multidisciplinaire nommée et stable avec des compétences en sécurité clinique et en gouvernance de l'information.
• Aucune construction ne démarre sans besoins utilisateurs étayés par une découverte.
• La gestion du risque clinique (DCB0129/DCB0160) fonctionne dès le premier jour, avec un journal des dangers vivant.
• Une analyse d'égalité et d'inégalités de santé a été réalisée, et des parcours numériques assistés existent.
• La livraison procède par tranches petites, fréquentes et mesurables.
• Les décisions sont consignées, en distinguant les preuves cliniques des preuves de livraison.
• Les services sont construits selon des normes d'interopérabilité ouvertes et réutilisent des plateformes partagées.
• Le poids de la gouvernance est adapté au risque, et connu de l'équipe.
• Il existe un chemin financé du pilote à l'échelle, incluant formation et conduite du changement.

Sources clés#

• Manuel de service numérique du NHS — NHS service standard et ses points, notamment « utiliser des façons de travailler agiles » et « créer une équipe incluant des compétences et perspectives multidisciplinaires » (service-manual.nhs.uk).
• GOV.UK Service Manual et le Government Service Standard — Government Digital Service (gov.uk/service-manual).
• NHS England / NHSX — Digital Technology Assessment Criteria (DTAC).
• Normes de sécurité clinique DCB0129 et DCB0160 (NHS England / ancien NHS Digital).
• NICE — Evidence Standards Framework for digital health technologies (nice.org.uk).
• NHS England — approche Core20PLUS5 pour réduire les inégalités de santé.

Références#

1. User-centered design — Wikipédia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipédia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipédia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipédia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipédia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipédia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipédia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipédia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipédia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipédia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/