Si vous êtes en état de détresse, veuillez appeler ou texter le 988 n’importe quand. En cas d’urgence, appelez le 9-1-1 ou rendez-vous à votre service d’urgence local.

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é.

 

Critères

Origine du critère

3a, Q1

Quels sont le ou les type(s) de preuves disponibles?

ORCHA

3a, Q2

Donnez les liens vers les preuves publiées ou accessibles au public que le développeur a fournies.

ORCHA

3a, Q3

Pour chaque type de preuve applicable :

  • À quelle catégorie les preuves se rapportent-elles?

ORCHA

3a, Q4

Pour chaque type de preuve applicable :

  • À quel avantage les preuves se rapportent-elles?

ORCHA

3a, Q5i

Pour chaque type de preuve applicable :

  • Quelle est la taille de l’échantillon?

CSMC

3a, Q5ii

  • L’échantillon reflète-t-il le public cible de l’application, comme indiqué par le développeur?

CSMC

3a, Q6

Pour chaque type de preuve applicable :

  • Les preuves trouvées fournissent-elles une valeur p?

ORCHA

3a, Q7

Pour chaque type de preuve applicable :

  • La valeur p démontre-t-elle la significativité statistique (p < 0,05)?

ORCHA

3a, Q8

Pour chaque type de preuve applicable :

  • La valeur p est-elle près du seuil de significativité (p < 0,2)?

ORCHA

3a, Q9

Pour chaque type de preuve applicable :

  • Existe-t-il un comparateur?

ORCHA

3a, Q10

Pour chaque type de preuve applicable :

  • Le comparateur est-il validé?

ORCHA

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.

 

Critères

Origine du critère

3b, Q1

L’application dispose-t-elle de ses propres études de haute qualité?

ORCHA

3b, Q2

L’application fournit-elle des références et des preuves pour sa technique de changement de comportement?

ORCHA

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.

 

Critères

Origine du critère

3c, Q1

L’équipe de développement de l’application compte-t-elle un professionnel dûment qualifié?

ORCHA

3c, Q2

Veuillez énumérer les professionnels de la santé agréés qui ont participé à l’exécution de l’application.


Directives :

Cette question ne s’applique que si un professionnel de la santé a participé à l’exécution de l’application, comme indiqué à la section 1h, Q5.

CSMC

3c, Q3

L’organisme qui chapeaute l’application dispose-t-il des documents de validation pertinents? 

ORCHA

3c, Q4

Existe-t-il des preuves de l’aval d’un organisme compétent?

ORCHA

3c, Q5

L’application est-elle utilisée par des organismes?

ORCHA

3c, Q6

Quel type d’organisme utilise l’application?

CSMC

3c, Q7

Existe-t-il une déclaration indiquant que l’application a été évaluée positivement ou validée par un professionnel de la santé compétent?

ORCHA

3c, Q8

Veuillez préciser qui sont les experts compétents et quelles sont leurs qualifications. 

ORCHA

3c, Q9

Existe-t-il des preuves, dans l’application, que le développeur a validé tous les conseils auprès de sources d’information ou de références fiables et pertinentes? 

ORCHA

3c, Q10

Existe-t-il une déclaration ou des preuves montrant la prise de mesures de protection appropriées concernant le service de soutien par les pairs et les autres fonctions de communication au sein de la plateforme?

  • (Exigence de niveau 2a : vise uniquement les applications qui nécessitent de telles mesures en raison de leurs capacités fonctionnelles ou des fins pour lesquelles elles sont prévues.)

ORCHA

3c, Q11

L’application offre-t-elle un soutien clinique ou par les pairs 24 heures sur 24, 7 jours sur 7?

Directives :

Le soutien peut être offert au moyen d’un clavardage ou d’une consultation sur demande, ou encore d’une autre ressource disponible 24 heures sur 24, 7 jours sur 7? Cette question concerne uniquement les applications qui abordent la question des pensées suicidaires ou qui répondent aux critères du niveau 2b ci-dessus (niveaux ESF).

CSMC

3c, Q12

Le développeur indique-t-il clairement qui doit ou ne doit pas utiliser l’application? 

ORCHA

3c, Q13

Le développeur publie-t-il ses processus de gestion des risques?

ORCHA

3c, Q14

Le développeur indique-t-il clairement les risques liés à l’utilisation de l’application?

ORCHA

3c, Q15

Existe-t-il un moyen, pour l’utilisateur, de confirmer que les données saisies sont exactes?

ORCHA

3c, Q16

L’application dirige-t-elle l’utilisateur vers un site Web gouvernemental (provincial/territorial/fédéral)?

Exemples pertinents au niveau fédéral :

Directives :

Cette question ne s’applique que si l’application ne propose ni de clavardage ou de consultation sur demande ni une autre ressource disponible 24 heures sur 24, 7 jours sur 7.

CSMC

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

 

Critères

Origine du critère

3d, Q1

Quel est le niveau ESF de l’application?

ORCHA

3d, Q2

L’application est-elle de niveau 1?

ORCHA

3d, Q3

L’application est-elle de niveau 2a?

ORCHA

3d, Q4

L’application est-elle de niveau 2b?

ORCHA

3d, Q5

L’application est-elle de niveau 3a?

ORCHA

3d, Q6

L’application est-elle de niveau 3b?

ORCHA

3d, Q7

L’application respecte-t-elle les exigences du niveau 1?

ORCHA

3d, Q8

L’application respecte-t-elle les exigences du niveau 2a?

ORCHA

3d, Q9

L’application respecte-t-elle les exigences du niveau 2b?

ORCHA

3d, Q10

L’application respecte-t-elle les exigences du niveau 3a?

ORCHA

3d, Q11

L’application respecte-t-elle les exigences du niveau 3b?

ORCHA

3d, Q12

L’application apporte-t-elle les preuves appropriées à son niveau ESF?

ORCHA

 

Critères

Origine du critère

3e, Q1

L’échantillon de l’étude de recherche présente-t-il les mêmes caractéristiques pertinentes que les utilisateurs de l’application?

CSMC