Sujet 8.6 — Recherche et évaluation en conditions réelles

Dans la santé et l'action sociale, une innovation numérique n'est digne de confiance que dans la mesure de la preuve qu'elle fonctionne réellement en pratique — donc vous devez concevoir cette preuve dès le début, à une rigueur proportionnée au risque et aux revendications que vous faites.

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

Chaque produit numérique que vous déployez fait une promesse implicite : ceci aidera les patients, le personnel, ou le système sans causer de dommage. Dans la plupart des secteurs, une promesse non prouvée coûte un client ou un trimestre de revenu. Dans la santé et l'action sociale, elle peut coûter des vies, élargir l'inéquité, ou éroder la confiance publique dont dépend tout le système. L'enthousiasme et une bonne démo ne sont pas des preuves, et un mécanisme plausible n'est pas une preuve de bénéfice.

L'histoire de la santé numérique est pleine d'outils qui semblaient convaincants et ont été adoptés à l'échelle avant que quiconque n'ait montré qu'ils fonctionnaient — et certains ont discrètement causé du dommage, manqué des diagnostics, ou poussé les cliniciens vers des contournements. Les régulateurs, commissionnaires, et cliniciens ont répondu en élevant la barre : ils attendent maintenant une preuve crédible et proportionnée avant, pendant, et après le déploiement. Si vous ne pouvez pas démontrer que votre service livre les résultats que vous revendiquez, vous devriez vous attendre à être défié, définancé, ou retiré — et à juste titre.

La preuve est aussi une question d'équité et de sécurité, pas un obstacle bureaucratique. Un outil qui améliore les résultats moyens peut quand même nuire à un sous-groupe — les exclus numériques, les personnes avec un anglais limité, ou une population sous-représentée dans vos données d'entraînement. Seule une évaluation délibérée révèle cela. Générer de bonnes preuves fait donc partie de votre devoir de soin, votre intendance de l'argent public, et votre crédibilité auprès des personnes que vous servez (voir Sujet 1.3 — Décisions fondées sur les preuves, et Sujet 1.6 — Sécurité clinique et gestion des risques).

Concepts fondamentaux#

Commencez par une distinction qui gouverne tout le reste : la différence entre recherche, évaluation de service, et audit clinique. La recherche vise à générer une connaissance nouvelle et généralisable — des conclusions destinées à être vraies au-delà de votre cadre local. L'évaluation de service demande à quel point ce service fonctionne ici, en utilisant les standards que le service lui-même a adoptés. L'audit clinique compare la pratique actuelle contre un standard existant et convenu et ferme la boucle avec le changement. La distinction n'est pas de la pédanterie académique : elle détermine votre voie de gouvernance. La recherche impliquant des patients, personnel, ou données du National Health Service (NHS) a presque toujours besoin d'une approbation éthique formelle ; la plupart des évaluations de service et audits n'en ont pas besoin. Mal classifier la recherche comme évaluation pour éviter les approbations est un échec de gouvernance sérieux.

En Angleterre, la gouvernance de la recherche passe par la Health Research Authority (HRA), un organisme déconcentré du Department of Health and Social Care. La HRA protège et promeut les intérêts des participants et coordonne les approbations afin qu'une étude soit révisée une fois pour tout le pays. La revue éthique est menée par un Research Ethics Committee (REC) — l'équivalent britannique d'un comité d'examen institutionnel — qui juge si une étude est éthique, proportionnée, et sûre pour les participants. Les demandes sont soumises via l'Integrated Research Application System (IRAS), un portail en ligne unique qui achemine votre projet vers les REC, l'approbation HRA, et autres permissions dont il a besoin. Les outils de décision en ligne de la HRA vous aident à déterminer si votre projet compte comme recherche du tout.

Une grande partie de la preuve de santé numérique est maintenant construite à partir de données du monde réel (RWD) — information rassemblée hors des essais contrôlés, telle que les dossiers de santé électroniques, journaux d'appareils, registres, et données de réclamation — analysée pour produire une preuve en conditions réelles (RWE) sur comment une intervention performe dans des conditions ordinaires. La RWE est puissante car les outils numériques génèrent des données d'utilisation riches comme sous-produit, et car elle reflète la réalité désordonnée que les essais excluent souvent. Elle est aussi fragile : les données observationnelles sont criblées de facteurs de confusion et de biais, donc une comparaison naïve avant-après peut confondre une tendance saisonnière ou un changement concomitant avec votre effet.

C'est pourquoi la conception d'évaluation compte. La conception la plus forte pour les revendications causales reste l'essai contrôlé randomisé (RCT), qui réduit le biais en allouant les participants au hasard. Les contextes numériques favorisent souvent des variantes pragmatiques — les essais randomisés en grappes, et l'essai en coin échelonné, dans lequel les sites passent du contrôle à l'intervention en vagues randomisées, correspondant à un déploiement échelonné que vous alliez faire de toute façon. Là où la randomisation est impraticable, les conceptions quasi-expérimentales aident : l'analyse de série temporelle interrompue (ITS) suit un résultat à travers de nombreux points avant et après la mise en production pour détecter des changements de niveau et de tendance, et est souvent la meilleure conception faisable pour un changement numérique à l'échelle du système. La comparaison avant-après simple est la plus faible et la plus trompeuse, car elle ne peut pas séparer votre effet de tout le reste qui a changé.

Deux ancres supplémentaires façonnent le travail. La barre de preuve pour la santé numérique en Angleterre est fixée par l'Evidence Standards Framework for Digital Health Technologies, publié par le National Institute for Health and Care Excellence (NICE) : il classe les outils par risque potentiel et spécifie la force de preuve attendue pour chaque niveau. Et une distorsion persistante à garder est le biais de publication — la tendance à partager les résultats positifs et enterrer les négatifs, ce qui flatte tout le domaine et laisse les outils inefficaces se répandre.

Bonnes pratiques#

1. Classifiez votre projet avant de le concevoir. Utilisez les outils de décision de la HRA pour déterminer si votre travail est recherche, évaluation de service, ou audit, et enregistrez le raisonnement. Cette étape unique fixe votre voie de gouvernance, votre calendrier, et vos permissions. Trompez-vous dans la direction optimiste et vous risquez d'exécuter une recherche non approuvée sur des patients ; trompez-vous dans la direction prudente et vous chargez une évaluation simple de mois de processus inutile.

2. Construisez l'évaluation dès le début, pas comme un ajout. Décidez ce que « fonctionner » signifie, et comment vous le mesurerez, pendant la découverte — avant une ligne de code de production (voir Sujet 3.4 — Phases de découverte). Capturez une base avant la mise en production, car vous ne pourrez jamais la reconstruire après, et instrumentez le produit pour émettre les données de résultat et d'utilisation dont votre conception a besoin. Adapter rétroactivement l'évaluation sur un service en direct produit presque toujours une preuve plus faible à coût plus élevé, et souvent aucune base utilisable du tout.

3. Faites correspondre la rigueur au risque et à la revendication. Un outil de réservation qui réordonne une liste d'attente a besoin de moins de poids probant qu'un algorithme qui trie la douleur thoracique. Utilisez le NICE Evidence Standards Framework pour localiser le niveau de risque de votre outil, et faites des revendications que votre preuve peut porter : si vous avez une série temporelle interrompue montrant des taux de non-présentation réduits, dites cela — n'impliquez pas un bénéfice de mortalité. La proportionnalité protège les patients du risque sous-étayé et vous protège de gaspiller de l'effort à sur-prouver des outils à faible enjeu.

4. Choisissez la conception la plus forte qui soit faisable, et nommez ses limites. Tendez vers la randomisation quand vous le pouvez, et considérez une conception en coin échelonné quand un déploiement échelonné rend un groupe de contrôle simultané impossible. Quand la randomisation est véritablement infaisable, préférez la série temporelle interrompue à l'avant-après naïf, et pré-spécifiez votre analyse pour résister à la tentation de pêcher un résultat favorable. Chaque conception a des faiblesses ; énoncez les vôtres clairement afin que les lecteurs puissent peser la preuve honnêtement.

5. Utilisez les données du monde réel délibérément, et traitez les facteurs de confusion comme l'ennemi. Les services numériques génèrent d'abondantes RWD, mais l'abondance n'est pas la validité. Planifiez quelles données vous utiliserez, leur qualité et complétude, et les biais qu'elles portent, et impliquez un analyste ou méthodologue tôt plutôt que de miner les journaux après coup. Pré-enregistrez vos résultats et analyse là où possible afin que les données ne puissent pas être torturées pour vous dire ce que vous espériez entendre.

6. Associez-vous à des personnes qui génèrent de la preuve professionnellement. Les universités, le National Institute for Health and Care Research (NIHR), et votre Health Innovation Network régional — les organismes anciennement connus comme Academic Health Science Networks (AHSN) — apportent une rigueur méthodologique, une indépendance, des voies de financement, et une crédibilité que vous ne pouvez pas fabriquer en interne. L'évaluation indépendante porte bien plus de poids auprès des commissionnaires et cliniciens que la propre analyse d'un fournisseur. Engagez-les tôt, car les meilleures conceptions sont fixées avant le déploiement, pas après (voir Sujet 9.0 — Collaborer avec des organisations partenaires).

7. Mesurez les résultats et l'économie, pas seulement l'activité. Les connexions, taux de clic, et scores de satisfaction sont nécessaires mais pas suffisants ; les commissionnaires financent des résultats et de la valeur. Partout où vous le pouvez, liez votre évaluation aux résultats cliniques, signaux de sécurité, équité à travers les sous-groupes, et conséquences de coût, travaillant avec des économistes de la santé pour encadrer le bénéfice en termes que les décideurs utilisent (voir Sujet 6.1 — Économie de la santé). Désagrégez toujours les résultats par population afin qu'un outil qui aide en moyenne mais nuit à un sous-groupe ne puisse pas se cacher derrière la moyenne.

8. Publiez vos résultats — y compris les décevants. Engagez-vous en amont à partager les conclusions, positives ou négatives, via un rapport, un preprint, ou un article à comité de lecture. Publier les résultats négatifs est une obligation professionnelle : cela épargne à d'autres organisations de répéter vos erreurs et contre le biais de publication qui laisse les outils inefficaces proliférer. Une culture qui peut dire « nous avons évalué ceci et cela n'a pas fonctionné, donc nous avons arrêté » est plus digne de confiance, pas moins.

9. Fermez la boucle et agissez sur ce que vous apprenez. Une preuve qui ne change aucune décision est du gaspillage. Réinjectez les conclusions dans votre feuille de route, votre dossier commercial, et vos décisions d'échelonnement — échelonnant ce qui fonctionne, corrigeant ce qui fonctionne à moitié, et mettant hors service ce qui ne fonctionne pas (voir Sujet 8.0 — Échelonner l'innovation). Ensuite réévaluez, car un outil numérique qui a fonctionné à l'échelle pilote dans un cadre peut se comporter différemment à l'échelle nationale ou dans une population différente.

Questions à discuter avec votre équipe#

1. Ce que nous sommes sur le point de faire est-il recherche, évaluation de service, ou audit — et à quel point sommes-nous confiants dans cette réponse ? C'est la première question car la réponse fixe tout votre parcours de gouvernance, et se tromper a des conséquences sérieuses. Discutez de qui sont vos sujets de données, si vous randomisez quoi que ce soit, si vous avez l'intention de produire une connaissance généralisable, et si vous prévoyez de publier — tous des signaux qui poussent un projet vers la « recherche ». Résistez à toute pression d'étiqueter quelque chose comme évaluation simplement parce que la voie d'approbation est plus rapide ; cette pression est exactement là où les échecs de gouvernance commencent. Utilisez l'outil de décision HRA ensemble, dans la pièce, et écrivez votre raisonnement et qui l'a convenu. Une bonne réponse n'est pas juste une étiquette mais un jugement documenté et défendable que vos collègues de gouvernance de l'information et de sécurité clinique ont vu. Si vous n'êtes véritablement pas sûr, le mouvement honnête est de demander à la HRA ou votre bureau R&D plutôt que de deviner dans la direction qui convient à votre calendrier.

2. Qu'est-ce qui compterait comme preuve convaincante que ceci fonctionne — et pour qui ? Différentes audiences exigent différentes preuves : un clinicien veut des données de sécurité et de résultat, un commissionnaire veut le coût et la valeur, un régulateur veut voir le niveau NICE approprié satisfait, et un patient veut savoir que c'est sûr et équitable pour des personnes comme lui. Débattez de ce que « fonctionner » signifie réellement pour votre outil, et quel résultat vous ferait arrêter — car une équipe qui ne peut pas articuler une condition d'arrêt n'évalue pas réellement. Considérez quelle conception est faisable étant donné votre plan de déploiement, vos données, et votre budget, et soyez honnête sur le compromis entre rigueur et vitesse. Discutez de si vous avez besoin d'une évaluation indépendante pour être cru, et si oui, qui devrait la faire. Une bonne réponse nomme les décideurs, les résultats qui les mouveraient, la conception qui peut produire de manière crédible ces résultats, et le seuil auquel vous conclurez que l'outil a échoué.

3. Comment gérerons-nous un résultat négatif ou décevant ? Demandez cela avant d'avoir le résultat, car la réponse est bien plus honnête à l'avance. Explorez ce que vous feriez si l'évaluation montrait aucun bénéfice, ou un bénéfice pour la majorité mais un dommage pour un sous-groupe exclu, et qui aurait besoin de l'entendre. Faites surgir les véritables pressions : coût irrécupérable, relations fournisseurs, inquiétude réputationnelle, et les incitations de carrière qui font que les gens veulent de bonnes nouvelles. Discutez de votre engagement préalable à publier peu importe le résultat, et quelle gouvernance vous tiendrait à cette promesse quand le résultat est embarrassant. Une bonne réponse traite une évaluation bien exécutée qui produit un résultat négatif comme un succès de processus, pas un échec de l'équipe — et a un plan concret pour mettre hors service avec grâce, communiquer franchement, et protéger les personnes qui ont livré la conclusion honnête.

4. Que devons-nous capturer et instrumenter avant la mise en production — et l'avons-nous réellement construit ? Une évaluation n'est aussi bonne que la base et les données sur lesquelles elle peut puiser, et les deux sont bien moins chères à sécuriser avant le lancement qu'après. Travaillez sur quel état « avant » vous avez besoin — taux d'admission, temps d'attente, taux d'erreur, coûts de parcours actuels — et confirmez qu'il est enregistré maintenant, désagrégé par les sous-groupes qui vous importent, car vous ne pourrez jamais reconstruire une base que vous avez manqué de capturer. Vérifiez si le produit lui-même émettra les données de résultat et d'utilisation dont votre conception choisie a besoin, ou si cette instrumentation est encore un souhait de backlog. Débattez de la tension de calendrier : la pression de livrer dépouille souvent la mesure pour atteindre une date, et chaque telle coupe affaiblit discrètement la preuve qu'on vous demandera plus tard de produire. Impliquez un analyste ou méthodologue tandis que la conception est encore malléable, pas une fois que les journaux coulent déjà. Une bonne réponse est une liste concrète de ce qui est capturé, depuis quand, à quelle granularité, et qui a confirmé que c'est en direct — pas une intention de le régler après le déploiement.

5. À quel point les données sur lesquelles nous prévoyons de dépendre sont-elles bonnes, et qu'est-ce qui pourrait confondre notre conclusion ? Les données du monde réel sont abondantes mais rarement propres, et un graphique plausible peut cacher la saisonnalité, un changement de service concomitant, une régression vers la moyenne, ou un changement de codage qui n'a rien à voir avec votre outil. Interrogez la provenance, la complétude, et la qualité de chaque source que vous prévoyez d'utiliser, et nommez les biais que chacune porte — qui manque des dossiers électroniques, quels champs sont peu fiables, à quel point un code est appliqué de manière cohérente. Demandez ce qui a changé d'autre dans la même fenêtre que votre mise en production, car une série temporelle interrompue ou avant-après qui ignore ces événements créditera votre outil des effets d'autres personnes. Décidez à l'avance quelle comparaison ou conception vous donne le contrefactuel le plus juste, et pré-spécifiez l'analyse afin que les données ne puissent pas être discrètement remodelées pour flatter le résultat. Une bonne réponse montre que vous avez cartographié les faiblesses des données honnêtement et choisi une conception qui peut survivre à un sceptique tirant sur chacune d'elles.

6. Qui devrait exécuter cette évaluation, et à quel point doit-elle être indépendante pour être crue ? Noter votre propre travail est la façon la plus rapide de faire rejeter des conclusions crédibles, donc décidez tôt si une analyse de fournisseur ou interne convaincra l'audience que vous avez réellement besoin de mouvoir. Pesez le coût et le temps d'engager une équipe académique soutenue par NIHR, une université, ou un Health Innovation Network contre la valeur réputationnelle et commerciale d'une preuve indépendante et publiable. Discutez de où siègent les conflits d'intérêts — les personnes qui ont construit ou acheté l'outil sont rarement les bonnes personnes pour juger s'il fonctionne — et comment vous isolerez l'évaluation de la pression de produire de bonnes nouvelles. Considérez ce que les partenaires apportent au-delà de l'indépendance : la rigueur méthodologique, les voies de financement, et la position auprès des commissionnaires et cliniciens que vous ne pouvez pas fabriquer en interne. Une bonne réponse fait correspondre le degré d'indépendance aux enjeux et au scepticisme des décideurs, et sécurise ce partenariat avant que la conception ne soit fixée plutôt qu'après que les résultats déçoivent.

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

Un système de soins intégrés (ICS) commande une application de surveillance à distance pour les patients ayant une insuffisance cardiaque chronique, espérant réduire les admissions non planifiées. Les diapositives du fournisseur montrent une réduction de 30 % ailleurs, et il y a une pression de déployer rapidement à travers les douze arrondissements avant l'hiver.

Le responsable de livraison numérique s'arrête pour classifier le travail. Parce que l'ICS veut des conclusions généralisables et prévoit de publier, et parce qu'il analysera des données patients identifiables pour un nouveau but, c'est de la recherche, pas une évaluation de service — donc une demande IRAS et une revue REC sont nécessaires. Plutôt que de traiter cela comme un blocage, le responsable approche le Health Innovation Network régional et une équipe de recherche soutenue par NIHR d'une université locale, qui aident à concevoir l'étude et co-écrivent la demande. Au lieu d'activer tout à la fois, ils adoptent une conception en coin échelonné : les douze arrondissements entrent en production en vagues randomisées sur neuf mois, donc chaque arrondissement obtient éventuellement l'application tandis que le démarrage échelonné fournit une comparaison juste. Une base de taux d'admission, désagrégée par précarité et ethnicité, est capturée avant la première vague.

En utilisant le NICE Evidence Standards Framework, l'équipe place l'outil dans un niveau qui porte un risque clinique et fixe l'attente de preuve en conséquence, pré-enregistrant les taux d'admission, la mortalité comme signal de sécurité, et le coût par admission évitée comme résultats. Neuf mois plus tard, l'analyse intérimaire est sobre : les admissions globales chutent modestement, mais parmi la cohorte la plus précaire — qui utilise le moins l'application — il n'y a aucun bénéfice et une hausse inquiétante des présentations tardives. L'équipe n'enterre pas cela. Ils le rapportent au conseil d'administration de l'ICS, mettent en pause le déploiement pour ces cohortes, reconçoivent l'intégration et ajoutent un support téléphonique pour les patients numériquement exclus, et publient à la fois le manque et la refonte. Le résultat est un service qui aide véritablement et un conseil d'administration décisionnel qui fait confiance à la preuve car il a vu l'équipe dire la vérité quand cela faisait mal.

Angles sectoriels#

Startup#

Une petite entreprise de santé numérique vit ou meurt par la preuve, mais a rarement l'argent ou la méthodologie interne pour la générer seule. Votre voie crédible la plus rapide est le partenariat : un collaborateur académique financé par NIHR ou une évaluation en conditions réelles d'un Health Innovation Network vous donne des conclusions indépendantes que les investisseurs et acheteurs NHS croient réellement, bien plus qu'un livre blanc auto-publié. Soyez discipliné sur les revendications proportionnées — surrevendiquer pour gagner un pilote est la façon la plus rapide d'échouer une évaluation ultérieure et perdre votre réputation. Construisez la capture de données dans votre architecture de produit dès le premier jour, car l'adapter rétroactivement après votre tour d'amorçage est coûteux et produit une base de preuve plus pauvre.

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 adoptant un outil numérique — est censé évaluer ce qu'il déploie, pourtant n'a aucun bureau R&D, aucun méthodologue, et à peine des mains disponibles. Votre mouvement réaliste n'est pas d'exécuter un essai mais d'exécuter une évaluation de service disciplinée : capturez une base simple avant d'activer, convenez d'une poignée de mesures de résultat honnêtes, et enregistrez ce qui change réellement pour vos patients. Appuyez-vous fortement sur l'infrastructure partagée que vous n'avez pas à construire — votre Health Innovation Network, une université locale, ou une fédération ou réseau de soins primaires qui peut mettre en commun les données et l'expertise à travers plusieurs petits sites. Soyez particulièrement prudent d'accepter la revendication vedette d'un fournisseur sur la foi quand vous ne pouvez pas la vérifier indépendamment, et soyez clair que les devoirs de classification s'appliquent toujours à vous même à petite échelle. Une preuve locale proportionnée et bien documentée est à la fois réalisable et suffisante pour justifier de continuer, adapter, ou abandonner l'outil.

Entreprise#

Un grand trust du NHS ou ICS a un bureau R&D, une machinerie de gouvernance de l'information, et des liens académiques existants — des actifs qu'une startup envierait — mais aussi l'inertie de déployer des outils à l'échelle du trust avant de les évaluer. Votre défi est de faire de « évaluer avant d'échelonner » le défaut, et de résister à l'élan d'un contrat d'entreprise signé quand la preuve précoce est faible. Utilisez votre échelle comme un avantage méthodologique : plusieurs sites rendent les conceptions en coin échelonné et randomisées en grappes faisables d'une façon qu'une seule clinique ne peut pas gérer. Méfiez-vous de la politique interne des résultats négatifs, où un grand investissement crée de puissantes incitations à déclarer le succès peu importe quoi.

Gouvernement#

Un organisme national — NHS England, le Department of Health and Social Care, ou un gouvernement décentralisé — fixe les règles que d'autres suivent, donc ses standards de preuve façonnent tout le marché. Son travail est de gérer les cadres (le système de gouvernance HRA, le NICE Evidence Standards Framework, DTAC) et de financer l'infrastructure — NIHR, Health Innovation Networks, environnements de recherche de confiance — qui laisse tout le monde générer de bonnes preuves. Quand le gouvernement achète à l'échelle nationale, les enjeux probants sont énormes : un déploiement mal étayé peut ancrer le dommage à travers des millions de citoyens et est politiquement quasi impossible à inverser. Il devrait donc se tenir à la barre la plus élevée qu'il demande à d'autres, et publier ses propres évaluations, y compris les échecs, pour garder la confiance publique.

Modes d'échec courants#

• Preuve comme réflexion après coup. Déployer d'abord et demander « a-t-il fonctionné ? » plus tard, sans base capturée — vous laissant incapable de faire toute revendication causale crédible.
• Mal classifier la recherche comme évaluation. Choisir l'étiquette « évaluation » pour éviter les approbations HRA et REC, exposant les patients à une recherche non approuvée et votre organisation à une violation de gouvernance sérieuse.
• Avant-après naïf. Comparer deux instantanés et attribuer tout le changement à votre outil, ignorant la saisonnalité, les initiatives concomitantes, et la régression vers la moyenne.
• Métriques de vanité. Rapporter connexions, téléchargements, et satisfaction tout en restant silencieux sur les résultats cliniques, la sécurité, l'équité, et le coût.
• Moyennes qui cachent le dommage. Présenter une amélioration moyenne vedette sans désagréger par population, dissimulant un sous-groupe que l'outil échoue ou lèse.
• Noter votre propre travail. Dépendre uniquement de preuve générée par le fournisseur sans évaluation indépendante, donc aucune audience sceptique ne la croit.
• Enterrer les mauvaises nouvelles. Publier seulement les conclusions positives, alimentant le biais de publication et laissant les outils inefficaces se répandre à travers le système.
• Surrevendication. Étirer un résultat modeste et faiblement conçu en une revendication clinique forte que la preuve ne peut pas soutenir.

Modèle de maturité#

Liste de contrôle#

• Classifiez le projet comme recherche, évaluation de service, ou audit en utilisant les outils de décision HRA, et documentez le raisonnement.
• Si c'est de la recherche, planifiez la demande IRAS et la revue Research Ethics Committee tôt.
• Définissez ce que « fonctionner » signifie, et les résultats qui le prouveraient, pendant la découverte.
• Capturez une base — désagrégée par sous-groupes pertinents — avant la mise en production.
• Localisez le niveau de risque de l'outil dans le NICE Evidence Standards Framework et faites correspondre la rigueur à cela.
• Choisissez la conception faisable la plus forte (RCT, coin échelonné, ou série temporelle interrompue) et enregistrez ses limites.
• Planifiez vos sources de données du monde réel, qualité, et biais ; pré-spécifiez l'analyse.
• Engagez un partenaire indépendant (NIHR, université, Health Innovation Network) là où la crédibilité ou le financement l'exige.
• Incluez les résultats cliniques, signaux de sécurité, équité, et coût — pas seulement les métriques d'activité.
• Engagez-vous en amont à publier les résultats, y compris les négatifs, et nommez où.
• Définissez une condition d'arrêt et un plan de mise hors service gracieux avant de commencer.
• Réinjectez les conclusions dans la feuille de route, le dossier commercial, et les décisions d'échelonnement.

Sources clés#

• NICE — Evidence Standards Framework for Digital Health Technologies (ESF).
• Health Research Authority — "Is my study research?" decision tools, HRA Approval, and research ethics guidance.
• Integrated Research Application System (IRAS) — the single portal for UK health and social care research applications.
• National Institute for Health and Care Research (NIHR) — funding, evaluation support, and research infrastructure.
• Health Innovation Network (formerly Academic Health Science Networks) — real-world evaluation and adoption support.
• Medicines and Healthcare products Regulatory Agency (MHRA) — real-world data guidance and software/AI as a medical device.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MRC/NIHR — Developing and evaluating complex interventions (framework guidance).
• EQUATOR Network — reporting guidelines (CONSORT, STROBE, TRIPOD) for transparent research reporting.

Références#

1. Real world evidence — Wikipédia — https://en.wikipedia.org/wiki/Real_world_evidence
2. Real world data — Wikipédia — https://en.wikipedia.org/wiki/Real_world_data
3. Clinical audit — Wikipédia — https://en.wikipedia.org/wiki/Clinical_audit
4. Health Research Authority — Wikipédia — https://en.wikipedia.org/wiki/Health_Research_Authority
5. Institutional review board — Wikipédia — https://en.wikipedia.org/wiki/Institutional_review_board
6. Randomized controlled trial — Wikipédia — https://en.wikipedia.org/wiki/Randomized_controlled_trial
7. Stepped-wedge trial — Wikipédia — https://en.wikipedia.org/wiki/Stepped-wedge_trial
8. Interrupted time series — Wikipédia — https://en.wikipedia.org/wiki/Interrupted_time_series
9. National Institute for Health and Care Research — Wikipédia — https://en.wikipedia.org/wiki/National_Institute_for_Health_and_Care_Research
10. National Institute for Health and Care Excellence — Wikipédia — https://en.wikipedia.org/wiki/National_Institute_for_Health_and_Care_Excellence
11. Publication bias — Wikipédia — https://en.wikipedia.org/wiki/Publication_bias
12. Evidence Standards Framework for Digital Health Technologies — National Institute for Health and Care Excellence (NICE) — https://www.nice.org.uk/about/what-we-do/digital-health/evidence-standards-framework-for-digital-health-technologies
13. Is my study research? — Health Research Authority — https://www.hra.nhs.uk/approvals-amendments/what-approvals-do-i-need/
14. Integrated Research Application System (IRAS) — Health Research Authority — https://www.myresearchproject.org.uk/
15. National Institute for Health and Care Research — NIHR — https://www.nihr.ac.uk/
16. Health Innovation Network — The Health Innovation Network — https://thehealthinnovationnetwork.co.uk/
17. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
18. Framework for developing and evaluating complex interventions — Medical Research Council / NIHR — https://www.bmj.com/content/374/bmj.n2061
19. Enhancing the QUAlity and Transparency Of health Research (EQUATOR) Network — https://www.equator-network.org/