4. Normes en matière de sécurité clinique
Navigation
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ères | Origine 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?
| 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 |