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

Cadre d’évaluation des applications de santé mentale

4. Normes en matière de sécurité clinique

Les fonctionnalités de tout produit logiciel et la façon dont celui-ci est représenté ou étiqueté en vue de son utilisation déterminent s’il peut être considéré comme un instrument médical en vertu de la Loi sur les aliments et drogues et du Règlement sur les instruments médicaux, administré par Santé Canada.

Un logiciel qui n’a pas d’incidence directe sur le diagnostic, le traitement ou la gestion de la maladie, du trouble, de l’état physique anormal ou des symptômes d’une personne ne serait pas assujetti au Règlement sur les instruments médicaux. Le document Lignes directrices : Logiciels à titre d’instruments médicaux de Santé Canada peut aider les fabricants à déterminer si leur produit est un instrument médical.

Si un produit logiciel est identifié comme un instrument médical, sa classe de risque doit aussi être déterminée pour connaître les exigences réglementaires qui s’appliquent. (Les instruments médicaux se classent en quatre classes, de la classe I, représentant le risque le plus faible, à la classe IV, représentant le risque le plus élevé.) Par exemple, pour pouvoir être vendus au Canada, les instruments de classe I n’ont pas besoin d’être homologués, mais les instruments de classe II, III et IV doivent l’être. (Remarque : les fabricants, importateurs ou distributeurs de classe I sont également assujettis à des exigences réglementaires).

Plusieurs applications de santé mentale remplissent des fonctions susceptibles de les assujettir au Règlement sur les instruments médicaux au Canada. Ces fonctions comprennent les applications qui pourraient aider à traiter, atténuer, diagnostiquer ou prévenir des symptômes liés à la santé mentale. Ces paramètres pourraient avoir un impact sur bon nombre des principales applications dans ce domaine, et les exclure de ce cadre en limiterait fortement la portée.

L’approche généralement adoptée dans des pays comme le Royaume-Uni et dans l’Union européenne consiste à s’assurer que le cadre applicable peut déterminer si une application est considérée ou non comme un instrument médical en vertu des règlements locaux applicables et, si c’est le cas, à assurer qu’elle a été certifiée ou autorisée de manière appropriée en vertu de ces règlements.

Cette approche ne consiste pas à contourner le processus de certification ou d’autorisation applicable, mais bien à vérifier si ce processus a déjà été complété par l’établissement d’un symbole, d’un certificat ou d’une autorisation appropriée (c’est-à-dire, dans le contexte canadien, l’homologation comme instrument médical).

C’est l’approche que nous proposons pour le présent cadre d’évaluation. Une telle stratégie permettrait de classer les applications comme des instruments médicaux et d’identifier celles qui ne disposent pas des autorisations appropriées. Toute application considérée comme un instrument médical qui n’aurait pas été autorisée par Santé Canada serait rejetée du processus du cadre et transmise à Santé Canada en vue d’une résolution.

La seule autre solution pratique pour éviter le risque d’inclure par inadvertance des instruments médicaux non autorisés dans le processus du cadre serait d’exclure explicitement dès le départ les applications ayant certaines fonctions. Toutefois, comme nous l’avons indiqué, cela limiterait considérablement les types de produits qui pourraient être évalués à l’aide du cadre. Le processus étape par étape que nous proposons de suivre tout en admettant les applications pertinentes dans le processus (y compris les critères) serait le suivant :

Si l’application de santé mentale est utilisée « à des fins médicales », elle est alors assujettie au Règlement sur les instruments médicaux et nécessite une autorisation réglementaire appropriée de Santé Canada. Pour déterminer si une autorisation réglementaire est requise, les critères suivants doivent être respectés :

 CritèresOrigine du critère
4a, Q1

L’application est-elle un instrument médical assujetti au Règlement sur les instruments médicaux selon le document Lignes Directrices : Logiciels à titre d’instruments médicaux de Santé Canada?

Si la réponse à la question 4a, Q1 est « Non » (l’application n’est pas destinée à une ou plusieurs fins médicales), il n’est pas nécessaire de répondre à la question 4a, Q2.

ORCHA
4a, Q2

Si l’application répond aux critères d’un instrument médical de classe II ou plus, sa vente est-elle autorisée au Canada?

  • La Liste des instruments médicaux homologués en vigueur (MDALL) de Santé Canada peut être consultée pour déterminer si l’homologation d’un produit est active.
  • Une Licence d’établissement d’instruments médicaux[1] (LEIM) est requise pour les fabricants, les importateurs et les distributeurs d’instruments médicaux de classe 1. Cette licence n’est pas propre à un produit et ne représente pas une évaluation propre à un produit par Santé Canada.
CSMC

Remarque :

  • Santé Canada ne tient pas de liste de produits (p. ex., les instruments médicaux spécifiques) détenteurs d’une LEIM.
  • La LEIM ne constitue pas une approbation d’instruments médicaux importés ou distribués par le titulaire de la LEIM

S’il apparaît que l’application est assujettie au Règlement sur les instruments médicaux (c.-à-d. qu’il s’agit d’un instrument médical), mais qu’elle n’a pas été autorisée par Santé Canada, toute publicité, vente ou distribution de l’application au Canada serait interdite. En pareil cas, le fabricant de l’application pourrait communiquer avec la Direction des instruments médicaux de Santé Canada.

[1] La Licence d’établissement d’instruments médicaux est une licence délivrée à des fabricants d’instruments de classe I ainsi qu’aux importateurs et aux distributeurs d’instruments de toutes les classes afin de les autoriser à importer ou à distribuer un instrument médical au Canada. La LEIM offre à Santé Canada l’assurance que des procédures sont en place pour protéger le public dans l’éventualité où un problème concernant ces instruments serait recensé.

Les développeurs doivent tenir compte des risques associés à la mise au point d’une application de santé mentale, afin de garantir une utilisation sécuritaire de celle-ci. Étant donné que le Canada ne dispose pas de normes officielles pour guider les développeurs dans la création d’applications sécuritaires en matière de santé mentale, le présent cadre propose qu’ils adoptent l’évaluation de la sécurité clinique (OCSA) de l’ORCHA, dont les critères décrivent objectivement les considérations de sécurité auxquelles les développeurs d’applications peuvent adhérer. Les applications conformes aux normes ISO 14971 (un cadre de gestion des risques) et DCB 0129 (un cadre de gestion des risques cliniques) seraient également conformes aux normes OCSA. Non seulement l’OCSA est en phase avec les cadres de gestion des risques établis pour les applications de santé, mais ses critères ont été adaptés au contexte canadien (comme le démontrent les critères ci-dessous).

 

Critères

Origine du critère

4b, Q1

L’application ou la solution est-elle comprise dans la portée de l’évaluation de la sécurité clinique de l’ORCHA (OCSA)?

ORCHA

4b, Q2

Pourquoi l’application est-elle comprise dans la portée de l’OCSA?

ORCHA

4b, Q3

Le développeur a-t-il fourni un résumé complet des raisons pour lesquelles l’application échappe à la portée de l’ORCHA (par exemple, elle est complète et correspond aux fonctions proposées)?

ORCHA

4b, Q4

Quels risques de préjudice à l’utilisateur, le cas échéant, ont été documentés?

ORCHA

4b, Q5

S’il a été déterminé que l’application ou la solution est comprise dans la portée de l’ORCHA, le développeur a-t-il fourni les documents de gestion du risque appropriés?

ORCHA

4b, Q6

Existe-t-il des documents de gestion du risque?

ORCHA

4b, Q7

Le développeur souligne-t-il la nécessité de documents de gestion du risque?

ORCHA

4b, Q8

Les documents de gestion du risque comportent-ils un historique complet des versions et une date de publication?

ORCHA

4b, Q9

Le développeur a-t-il décrit son système de gestion des risques cliniques (par exemple, détermination des membres clés du personnel, de leur rôle et de leurs responsabilités, définition de la structure de gouvernance de la gestion des risques cliniques)?

ORCHA

4b, Q10

L’argumentaire de sûreté fait-il mention d’un sommaire des essais (c’est-à-dire un sommaire de tous les problèmes en suspens liés aux essais et de leur incidence sur la sécurité clinique)?

ORCHA

4b, Q11

Le registre des dangers comporte-t-il un historique complet des versions et une date de publication?

ORCHA

4b, Q12

La liste des dangers est-elle complète?

Directives :

À la lumière des dangers énumérés, est-ce que tous les renseignements requis, dont le nom, l’impact clinique et les évaluations du risque, ont été fournis?

ORCHA

4b, Q13

Les préjudices possibles visent-ils l’utilisateur?

ORCHA

4b, Q14

Les préjudices décrivent-ils l’impact clinique possible pour l’utilisateur?

ORCHA

4b, Q15

Le développeur a-t-il couvert toutes les causes possibles pour chaque danger?

ORCHA

4b, Q16

Les évaluations du risque semblent-elles appropriées ou ont-elles l’air d’avoir été « copiées-collées » pour tous les dangers énumérés?

ORCHA

4b, Q17

Les dangers sont-ils mal répartis entre les préjudices potentiels et réels?

ORCHA

4b, Q18

Le développeur a-t-il mis en œuvre les activités d’analyse des risques cliniques définies dans le plan de gestion des risques cliniques?

ORCHA

4b, Q19

L’analyse du risque clinique est-elle réalisée par un groupe multidisciplinaire?

ORCHA

4b, Q20

Le développeur a-t-il défini la portée clinique du système informatique de santé à mettre en place?

ORCHA

4b, Q21

Le développeur a-t-il défini l’utilisation prévue du système informatique de santé à mettre en place?

ORCHA

4b, Q22

Les documents de gestion du risque indiquent-ils clairement la place de l’application dans le flux de travail clinique?

ORCHA

4b, Q23

Le développeur a-t-il décrit les produits tiers intégrés au système informatique de santé à mettre en place?

ORCHA

4b, Q24

Le développeur qui déploie le système informatique de santé a-t-il réfléchi à l’impact que ce dernier aura sur les méthodes de travail et les processus opérationnels actuels?

ORCHA

4b, Q25

Les preuves liées à la convivialité et au facteur humain sont-elles visées?

ORCHA

4b, Q26

Le développeur a-t-il évalué toute infrastructure nécessaire relevant de son champ d’influence au sein de l’organisme de santé pour soutenir le déploiement du système informatique de santé? (Pour ce faire, le fabricant peut préciser la configuration minimale requise.)

ORCHA

4b, Q27

Le développeur doit-il effectuer une migration des données? (Si le développeur doit effectuer une migration des données, cette dernière doit être incluse dans le champ d’application des activités de gestion des risques cliniques.)

ORCHA

4b, Q28

La migration des données effectuée par le développeur est-elle suffisamment couverte dans la documentation?

ORCHA

4b, Q29

Le développeur a-t-il énuméré les dangers associés à la migration des données qui ont été analysés et atténués de manière appropriée (en collaboration avec l’organisme de santé concerné, le cas échéant)?

ORCHA

4b, Q30

Le développeur a-t-il pris en compte le processus clinique de bout en bout, y compris les fonctionnalités et la manière dont ces dernières sont utilisées?

ORCHA

4b, Q31

Le développeur a-t-il pris en compte les messages entre les systèmes informatiques de santé et à l’intérieur de ceux-ci?

ORCHA

4b, Q32

Le développeur a-t-il évalué l’architecture et la conception du système informatique de santé?

ORCHA

4b, Q33

Une matrice claire est-elle utilisée pour définir les niveaux du risque?

ORCHA

4b, Q34

Pour chaque danger recensé, le développeur a-t-il évalué si le risque clinique initial est acceptable?

ORCHA

4b, Q35

Le développeur a-t-il utilisé les critères d’acceptabilité du risque définis précédemment?

ORCHA

4b, Q36

Le développeur a-t-il défini des mesures appropriées de contrôle du risque clinique pour éliminer tout risque clinique inacceptable?

ORCHA

4b, Q37

Le développeur a-t-il évalué les mesures de contrôle du risque clinique proposées afin de déterminer si ces dernières entraînaient de nouveaux dangers?

ORCHA

4b, Q38

Le développeur a-t-il évalué les mesures de contrôle du risque clinique proposées afin de déterminer leurs effets sur les risques cliniques liés aux dangers précédemment cernés?

ORCHA

4b, Q39

Le développeur gère-t-il les nouveaux dangers ou les risques cliniques accrus?

ORCHA

4b, Q40

Pour chaque danger recensé, le développeur a-t-il évalué si le risque clinique résiduel est acceptable?

ORCHA

4b, Q41

Le développeur a-t-il utilisé les critères d’acceptabilité du risque définis précédemment?

ORCHA

4b, Q42

Si le risque clinique résiduel est inacceptable, le développeur a-t-il prévu des mesures de contrôle du risque clinique supplémentaires pour le réduire?

ORCHA

4b, Q43

Si le développeur a déterminé qu’aucune mesure de contrôle du risque appropriée n’est possible, a-t-il effectué une analyse risques-avantages cliniques?

ORCHA

4b, Q44

L’analyse du développeur a-t-elle démontré que les avantages cliniques de l’utilisation prévue l’emportent sur le risque clinique résiduel?

ORCHA

4b, Q45

Le développeur a-t-il mis en œuvre les mesures de contrôle du risque clinique définies (sauf si ces mesures doivent être mises en œuvre par un autre organisme)?

ORCHA

4b, Q46

Les risques cliniques découlant de tous les dangers cernés ont-ils été pris en compte et acceptés?

ORCHA

4b, Q47

Les réductions des niveaux de danger ont-elles été entièrement justifiées?

ORCHA

4b, Q48

Un professionnel a-t-il pris part au processus de la sécurité clinique?

CSMC

4b, Q49

Le professionnel compétent est-il dûment qualifié?

ORCHA

4b, Q50

Le professionnel compétent détient-il les renseignements nécessaires liés à l’inscription?

ORCHA

4b, Q51

Ces renseignements d’inscription ont-ils joué un rôle actif dans le processus?

ORCHA