3. Normes en matière de preuves cliniques

Lorsque les allégations d’efficacité ne sont pas faites directement par le développeur, il peut être nécessaire de fournir des preuves, à la fois par rapport aux avantages énoncés ou insinués de l’application et par rapport au risque de préjudice associé à son utilisation. Comme nous l’avons indiqué à la section Aperçu de l’application, la proportionnalité de la preuve ou de la preuve de certification peut être évaluée avant la nécessité, la pertinence et la qualité de l’application.

La proportionnalité doit être prise en compte, car il n’est pas réaliste d’attendre de toutes les applications qu’elles fournissent les mêmes types de preuves. L’Adapted Evidence Standards Framework (ESF) (cadre adapté sur les normes en matière de preuve) de l’ORCHA tient compte de la complexité fonctionnelle de l’application et du risque de préjudice pour les utilisateurs tout en orientant l’exigence d’éléments de preuve. Par exemple, un niveau de preuve plus élevé est requis pour les applications dont les fonctionnalités sont plus complexes, car elles comportent des risques plus importants (voir la sous-section 3d). Les applications qui ne respectent pas cette exigence quant à la preuve peuvent fournir d’autres documents de validation pour satisfaire aux normes professionnelles de certification. Cette question est examinée au cas par cas. La sous-section 3d fournit aussi plus de renseignements sur d’autres sources de validation.

La nécessité consiste à déterminer si la preuve de l’efficacité est raisonnablement requise au départ et si cette exigence impose un fardeau disproportionné et injuste aux développeurs de ces applications, par rapport aux développeurs de solutions non numériques (comparables). Par exemple, une application qui permet aux personnes souffrant de dépression ou d’anxiété de tenir un journal pour noter leurs pensées. En pareil cas, il convient de se demander si un cahier de notes comparable, acheté dans un magasin local, nécessiterait une telle preuve. Si, selon l’Adapted ESF, « l’application doit fournir des preuves, car son utilisation pose un risque supplémentaire », il devient alors nécessaire de déterminer quel type de preuve est requis : preuve d’efficacité, preuve de sécurité, ou les deux. Par exemple :

• Scénario avec preuve de sécurité. Si une application utilise un calculateur clinique établi, elle peut fournir des preuves indirectes qui démontrent la sécurité d’un calcul ou d’un algorithme donné, mais pas dans le contexte spécifique de l’application. Dans ce cas, nous chercherions à obtenir l’assurance que l’application a reproduit exactement l’algorithme applicable et qu’il fonctionne et produit des résultats d’une manière identique qui n’entraîne pas d’interprétations erronées. 
• Scénario avec preuve d’efficacité I. Si une application déclare ou insinue un avantage précis, comme souligné à la section Aperçu de l’application, nous exigerons des preuves d’efficacité pour étayer l’avantage énoncé ou insinué. 
• Scénario avec preuve d’efficacité II. Si une application dirige les lecteurs vers des preuves indirectes pour étayer les avantages déclarés ou insinués, cela peut être considéré comme suffisant si le mode et la fonction de l’application sont identiques en tous points à la solution identifiée dans les preuves indirectes (voir la sous-section 3b).

La pertinence est déterminée par le fait que les enquêtes ou les recherches concernant l’efficacité ou la sécurité d’une application ont été menées à l’aide d’un échantillon représentatif et des méthodes d’évaluation appropriées. Par exemple, il serait illogique d’exiger un essai contrôlé randomisé (ECR) pour les diagnostics. Le public cible de l’application est identifié dans l’aperçu de l’application, et les preuves doivent démontrer que l’échantillon sélectionné possède les mêmes caractéristiques principales (par exemple, la tranche d’âge, le sexe). Si les preuves ne sont pas obtenues au moyen d’un échantillon ou d’un mécanisme d’évaluation approprié, leur qualité ne peut pas être évaluée.

La pertinence peut aussi être évaluée pour les applications qui ne nécessitent pas de preuves, mais une certification, c’est-à-dire celles dont le profil de risque est beaucoup plus faible (généralement de niveau 2b ou moins aux termes de l’ESF du NICE). L’évaluateur vérifie alors si des cliniciens ont participé au développement de l’application et s’ils étaient suffisamment qualifiés. La pertinence des déclarations, des lignes directrices citées et des informations pertinentes peut aussi être évaluée à ce stade.

La qualité est aussi liée au fait que les preuves ou les certifications sont considérées comme étant appropriées. Si l’application doit fournir des preuves d’efficacité, et que le seuil pour le type de preuve requis est atteint, alors la qualité de ces preuves peut être évaluée. Par exemple :

• Dans le cas des thérapies numériques, la qualité est évaluée au moyen de valeursp significatives (p < 0,05) et de comparateurs ou de comparateurs validés (comme indiqué dans les critères ci-dessous).
• Dans le cas des diagnostics, on utilise aussi la détermination d’améliorations ou de réductions négligeables de l’exactitude du diagnostic sur le plan du chevauchement des intervalles de confiance et de l’aire sous la courbe ROC (critères de sensibilité et de spécificité).

Bien qu’il s’agisse des indicateurs de qualité les plus utilisés, la qualité est évaluée au cas par cas pour assurer qu’elle est proportionnelle à ce que l’application fait ou recherche.

Comme nous l’avons mentionné, lorsque les preuves de diagnostic et de traitement sont prises en compte, des valeurs p de < 0,05 peuvent être inappropriées. Les preuves, ici, sont examinées au cas par cas, mais les thèmes habituels qui démontrent la sécurité comprennent des niveaux élevés de sensibilité ou de spécificité ou des niveaux similaires de respect à l’égard de l’expertise d’un clinicien qualifié.

Si une application a recours à des techniques acceptées de changement de comportement qui reposent déjà sur une solide base de données probantes, le développeur peut choisir de ne pas financer de recherches supplémentaires. Par exemple, si une application intègre la thérapie comportementale dialectique (une technique de changement de comportement), le développeur peut choisir de s’appuyer sur la solide base de données probantes sur cette thérapie au lieu de mener ses propres recherches.

L’aval des professionnels renvoie à la preuve qu’un professionnel approprié a participé à la conception et au développement d’une application. Le professionnel compétent variera selon le contexte. Par exemple, pour une application de méditation simple, un instructeur de méditation qualifié serait considéré comme un professionnel approprié. Pour une solution clinique complexe, comme une application qui prétend traiter la dépression, un clinicien compétent qualifié serait nécessaire.

L’aval des professionnels peut être déduit si l’application a été accréditée par un organisme externe. Les organismes externes d’accréditation peuvent être très variés, allant des organismes de santé nationaux aux organismes caritatifs. Tout comme le professionnel doit être approprié, il est également essentiel que l’accréditation provienne d’un organisme approprié et pertinent pour l’application. Remarque : si les critères ci-dessous concernent la certification professionnelle, les questions 9 à 14 mettent également l’accent sur les efforts du développeur pour garantir que l’application est sécuritaire.

Chaque application est censée fournir un certain niveau de preuve ou de certification. Il a été convenu que ce niveau de preuve et de certification devait rester proportionnel aux fonctionnalités et aux déclarations de l’application.

Ce cadre s’appuie sur l’Adapted Evidence Standards Framework (Adapted ESF) de l’ORCHA, une version de l’ESF original du NICE qui a été modifiée afin de rendre les exigences équitables pour les applications de santé mobile.

L’Adapted ESF attribue à chaque application un « niveau ESF » selon sa fonctionnalité. Le niveau ESF détermine ensuite le niveau de preuve à fournir. La satisfaction, par l’application, de l’exigence associée à son niveau de preuve et de certification a un effet positif sur son évaluation.

Le niveau ESF d’une application est déterminé en fonction de ce qu’elle offre.

Le niveau 3b serait attribué à une application qui :

• pose des diagnostics de problème de santé mentale (« Oui » à la question 1e, Q2);
• comporte un nouveau calculateur clinique qui a une incidence sur les soins, le traitement ou le diagnostic (« Oui » à la question 1e, Q11);
• mesure ou consigne automatiquement des données sur le problème de santé mentale particulier d’un utilisateur et les transmet à un professionnel de la santé, un soignant ou un organisme tiers sans aucune intervention de la part de l’utilisateur (« Oui » à la question 1g, Q7);
• fournit un traitement (« Oui » à la question 1e, Q15);
• oriente le traitement d’un problème de santé mentale (« Oui » à la question 1e, Q17);
• atténue les symptômes d’un problème de santé mentale existant (« Oui » à la question 1e, Q25).

Le niveau 3a serait attribué à une application qui ne remplit aucune des conditions énumérées ci-dessus, mais qui :

• est une application d’autogestion complexe (option sélectionnée à la question 1g, Q4);
• inclut un changement de comportement préventif (option sélectionnée à la question 1g, Q10);
• comporte un calculateur clinique reconnu (et non un nouveau) (« Oui » à la question 1e, Q11 et mention d’un calculateur clinique établi à la question 1e, Q12).

Wysa est une application de soutien à la santé mentale qui propose aux utilisateurs de discuter avec un assistant virtuel de tous les sujets, du sommeil au stress. Il s’agit d’une application d’autogestion complexe qui se verrait attribuer le niveau 3a ou 3b, selon ses autres fonctionnalités. Elle permet également aux utilisateurs d’autoévaluer leurs symptômes au moyen de tests de dépistage de la dépression (QSP-9) et de l’anxiété (GAD-7). Ces tests seraient considérés comme des calculateurs cliniques, mais comme il s’agit de ressources largement reconnues et établies, l’application ne serait pas élevée au niveau 3b. Cette application demeure de niveau 3a en raison de sa gestion complexe et de son utilisation liée spécifiquement à un problème de santé mentale.

Une application comportant un nouveau calculateur clinique unique ne serait pas considérée comme un outil établi et ne serait probablement pas aussi reconnue ou citée. Une telle application ferait donc l’objet d’un contrôle plus rigoureux et serait considérée comme étant de niveau 3b.

Le niveau 2b serait attribué à une application qui ne remplit aucune des conditions énumérées pour les niveaux 3b et 3a et qui est considérée comme une application d’autogestion standard (option sélectionnée à la question 1g, Q4).

Le niveau 2a serait attribué à une application qui ne remplit aucune des conditions énumérées pour les niveaux 3b, 3a et 2b, mais qui :

• fournit des renseignements ou des conseils (« Oui » à la question 1d, Q1) ou permet aux professionnels de la santé – et non à l’application comme telle – de donner des conseils cliniques (« Oui » à la question 1g, Q3);
• fournit des renseignements, des ressources ou des activités au public, aux utilisateurs ou aux cliniciens, que ce soit concernant un problème de santé mentale donné ou la santé et le mode de vie en général (« Oui » à la question 1d, Q5);
• permet une communication bidirectionnelle entre les utilisateurs, les citoyens ou les professionnels de la santé (« Oui » à la question 1l, Q4) ou est une application d’autogestion simple (option sélectionnée à la question 1g, Q4).

Moodbeam est une application qui aide les utilisateurs à consigner comment ils se sentent. Elle permet à l’utilisateur d’indiquer, à l’aide de deux boutons simples, quand il ressent un haut ou un bas et, ainsi, de dégager des schémas et des tendances au fil du temps. Cette application est un bon exemple d’autogestion simple, ce qui correspond au niveau 2a.

Une application d’autogestion simple permet à l’utilisateur de surveiller des données non spécifiques à son problème de santé mentale, qui peuvent ensuite lui être présentées dans un format simple. Comme l’application Moodbeam permet à l’utilisateur de faire le suivi son humeur et ses sentiments et de voir ses données sous la forme d’un graphique simple, elle est considérée comme un outil d’autogestion simple, elle est donc appropriée pour le niveau 2a.

Si cette application permettait à l’utilisateur de surveiller des données propres à un problème de santé mentale (par exemple, si elle l’invitait à indiquer les moments où il ressent une dépression clinique ou une anxiété généralisée), elle ne relèverait plus du niveau 2a. Quand une application permet de surveiller des données propres à un problème de santé mentale et présente ces données sous la forme d’un graphique simple, elle est considérée comme un outil d’autogestion standard, elle est donc appropriée pour le niveau 2b.

Le niveau 1 serait attribué à une application qui ne remplit aucune des conditions énumérées pour les niveaux 3b, 3a, 2b et 2a et qui ne fournit aucun résultat à l’utilisateur. Par exemple, une application administrative qui aide à fournir des systèmes ou des services liés à la santé, ou une application de maintenance qui signale et corrige des problèmes en milieu hospitalier.

Thalamos est une application Web qui aide les professionnels de la santé à remplir et à gérer les formulaires requis en vertu de la Mental Health Act du Royaume-Uni. Il s’agit d’un bon exemple d’application de niveau 1, car elle remplace simplement le papier et le crayon. Comme l’application facilite l’administration et n’a pas de répercussions directes sur les résultats de l’utilisateur, elle ne peut être classée plus haut que le niveau 1.

Une fois le niveau ESF d’une application déterminé, l’objectif suivant est de vérifier si l’application s’y conforme. Pour qu’une application soit conforme à son niveau ESF, elle doit respecter les critères applicables (réponses positives).

Il est important de noter que les exigences sont cumulatives, c’est-à-dire qu’une application de niveau 3a doit satisfaire aussi aux exigences des niveaux inférieurs. Toutefois, si l’application a fait l’objet d’un ECR (ce qui est acceptable au niveau 3b), il n’est pas nécessaire de réaliser une étude observationnelle distincte. Une étude (un ECR) suffirait dans ce cas.

L’application serait conforme aux exigences minimales du niveau 1 si elle respecte les conditions suivantes :

• preuves d’enquête, d’étude pilote, de méta-analyse, d’ECR, d’étude observationnelle ou d’autre essai d’acceptation par l’utilisateur ou d’avantage pour l’utilisateur indiqué (contient au moins un élément de réponse à la question 3a, Q1);

et au moins une des conditions suivantes :

• preuves de la participation d’un professionnel compétent au sein de l’équipe de développement (« Oui » à la question 3c, Q1);
• documents de validation organisationnels pertinents (« Oui » à la question 3c, Q2);
• preuves de l’aval d’un organisme compétent (« Oui » à la question 3c, Q3).

L’application serait conforme aux exigences minimales du niveau 2a si elle respecte les conditions suivantes :

• preuves que le développeur a validé les renseignements, conseils ou indications à l’aide d’études universitaires pertinentes et appropriées ou d’avis d’experts universitaires compétents (« Oui » à la question 3c, Q1; 3c, Q2; ou 3c, Q7);
• preuves claires de la mise en place de mesures de protection pour toutes les fonctions de communication (« Oui » à la question 4b, Q1, le cas échéant);
• preuves d’accréditation par des experts (« Oui » à la question 3c, Q1; 3c, Q2; 3c, Q3; ou 3c, Q5).

L’application serait conforme aux exigences minimales du niveau 2b si elle respecte les conditions suivantes :

• preuves que le développeur a validé les renseignements, conseils ou indications (« Oui » à la question 3c, Q1 ou 3c, Q7);
• preuves claires de la mise en place de mesures de protection pour toutes les fonctions de communication (« Oui » à la question 4b, Q1, le cas échéant);
• preuves d’accréditation par des experts (« Oui » à la question 3c, Q1; 3c, Q2; ou 3c, Q5);
• preuves de l’aval d’un organisme compétent (« Oui » à la question 3c, Q3) ou de méta-analyse ou preuves d’étude observationnelle ou d’ECR avec une valeur p < 0,05 (« Oui » à la question 3a, Q1 et « Oui » à l’un des éléments à la question 3a, Q7).

L’application serait conforme aux exigences minimales du niveau 3a si elle respecte les conditions suivantes :

• preuves d’un ECR (la réponse à la question 3a, Q1 inclut l’essai contrôlé randomisé) ayant une valeur p significative (« Oui » à la question 3a, Q7) ou preuves d’une étude observationnelle (la réponse à la question 3a, Q1 inclut l’étude observationnelle) ayant une valeur p significative (« Oui » à la question 3a, Q7);
• présence d’un comparateur (« Oui » à la question 3a, Q9) ou d’un comparateur validé (« Oui » à la question 3a, Q10).

L’application serait conforme aux exigences minimales du niveau 3b si elle respecte les conditions suivantes :

• preuves d’un ECR (la réponse à la question 3a, Q1 inclut l’ECR) ayant une valeur p significative (« Oui » à la question 3a, Q7);
• présence d’un comparateur validé (« Oui » à la question 3a, Q10).

Si une application a été classée au niveau 3b mais ne dispose pas d’un ECR, elle peut tout de même passer le cadre ESF en utilisant d’autres documents de validation. Bien que chaque application soit examinée au cas par cas, le niveau 3b peut être atteint en fournissant des preuves de qualité issues du monde réel. Par exemple :

• des études observationnelles de haute qualité au lieu d’un ECR
• des preuves concernant son adoption et utilisation