Groupe consultatif scientifique sur les logiciels à titre d’instruments médicaux (GCS-LIM) - Compte rendu des délibérations - 26 janvier 2018

Membres du groupe : Robert DiRaddo (président), Laith Bustani, Joseph Cafazzo, Eric Cohen, Kimberley Hanson, Christopher Kamel, Ron Parker, Bakul Patel, Catherine Proulx

Présentateurs : Colin Foster, Daniel Yoon (Santé Canada), Bakul Patel (US FDA), Dana O’Born (CCI), Melissa Perri & Anthony Kaul (CloudDX), Graeme Moffat (InteraXon), David Bissessar (Identos) - (au nom du CCI), Monica Magidin (Siemens Healthcare, au nom de MEDEC)

Personnel de Santé Canada : Celia Lourenco, David Boudreau, Sarah Chandler, Colin Foster, Patrice Sarrazin, Andrew Hawel, Ian Glasgow, Kevin Day, Graham Ladner, Hripsime Shahbazian, Daniel Yoon, Yvonne Fallenbuchl, Tyler Dumouchel, Patrick Assouad, Marc Lamoureux, Patrick Fandja, Christine Lefebvre, Anoop Poovadan, Asaad Ahmed

Accueil et mot d’ouverture (Celia Lourenco)

Celia Lourenco, la directrice exécutive principale de la Direction des produits thérapeutiques (DPT) souhaite la bienvenue aux membres et aux présentateurs du Groupe consultatif scientifique.  Elle fournit le contexte de la réunion en faisant remarquer que les logiciels à titre d’instruments médicaux (LIM) constituent un nouveau domaine que Santé Canada trouve stimulant de réglementer. Comme les Canadiens intègrent de plus en plus la technologie médicale dans leur vie quotidienne, Santé Canada (SC) doit assurer une gestion des risques et une surveillance réglementaire appropriées sans étouffer l’innovation technologique et l’accès au  marché. Les conseils éclairés du Groupe sur la façon dont SC peut améliorer les lignes directrices provisoires seront cruciaux pour assurer que SC définit la portée de ce domaine et le réglemente convenablement. Elle explique le processus à utiliser pour la réunion et remercie à nouveau le Groupe de bien vouloir prendre le temps de fournir des conseils à SC. Elle cède ensuite la parole au président du Groupe.

Mot du président (Robert DiRaddo)

Le président réaffirme le mandat du Groupe et réitère les questions posées au Groupe par SC.  Il confirme ensuite l’acceptation du mandat du Groupe et de l’ordre du jour provisoire de la réunion. Il explique que les présentateurs vont s’adresser uniquement au Groupe et qu’il n’y aura aucune discussion entre les présentateurs. Par suite des présentations, les présentateurs quitteront les lieux et le Groupe délibérera sur les propos entendus et formulera des réponses aux questions de SC.  Il invite chaque membre à se présenter brièvement et à indiquer si des changements ont eu lieu depuis que chacun a terminé sa déclaration écrite conformément aux exigences d’adhésion de ce comité.  Aucun autre conflit d’intérêts n’est déclaré. De brèves présentations suivent. Le président demande ensuite aux participants de se présenter avant de commencer les présentations.

Présentations

Santé Canada

Colin Foster offre un aperçu du cadre de réglementation pour les instruments médicaux. Il donne la définition d’un instrument et indique en quoi un logiciel pourrait servir d’instrument médical selon cette définition. Il fait remarquer que de nombreux produits logiciels correspondent à cette définition; par contre, d’autres n’y correspondent pas.  SC aimerait avoir les commentaires du Groupe pour déterminer si ces produits logiciels sont des instruments ou non, et comment les classifier selon le cadre de réglementation actuel. Il explique l’approche fondée sur le risque envers la réglementation des instruments. SC se fie aux règles de classification publiées dans le Règlement sur les instruments médicaux (le Règlement) pour classer les instruments médicaux dans l’une des quatre classes de risques : classe I, II, III ou IV; la classe I représente les instruments présentant le risque le plus faible et la classe IV ceux présentant le risque le plus élevé. Il y a deux ensembles de règles dans le Règlement, un pour les instruments autres que les instruments diagnostiques in vitro (IDIV) et l’autre pour les IDIV. Les fabricants, importateurs et distributeurs d’instruments médicaux sont assujettis à différentes exigences réglementaires selon la classification de risque des instruments qu’ils comptent lancer au Canada. Pour le processus de demande d’homologation pour un instrument médical, SC exige la soumission de différents renseignements selon la classification de risque de l’instrument médical. Il fournit des exemples de types de logiciel actuellement homologués par SC. Les présentes lignes directrices provisoires ont été rédigées pour faciliter la classification des LIM.

Il fait remarquer que les règles de classification actuelles ont été définies au moment de l’entrée en vigueur du Règlement, il y a 20 ans, et ne reflètent pas la technologie actuelle. SC a besoin de lignes directrices provisoires qui abordent la manière de classifier cette nouvelle technologie.

Les questions soulevées par le Groupe et adressées au présentateur comprennent entre autres les suivantes :

  • Définition d’un instrument et étiquetage des produits logiciels. Quand un logiciel est-il considéré comme un instrument et quand ne l’est-il pas?
  • Le même produit peut être considéré comme un instrument si les allégations relatives à l’étiquetage répondent à la définition et peut ne pas être considéré comme un instrument si l’étiquetage n’indique aucune des allégations couvertes par la définition.  Cela laisse une grande place à l’interprétation.
  • Le concept de la qualité médicale est proposé pour distinguer les types de logiciels.
  • On discute des règles de classification aux fins de clarification.
  • La différenciation entre les logiciels médicaux (tels que les logiciels de planification de radiothérapie) et les logiciels à titre de service fait l’objet de questions.
  • La distinction entre les logiciels et le matériel n’est toujours pas claire – quel composant est considéré comme un instrument?
  • La définition de l’IMDRF reflète le concept de logiciel qui ne réside pas au sein du matériel. On peut demander à une tierce partie de fournir le logiciel de planification grâce à une interface pouvant être humaine ou machine.
  • Pour ce qui est de l’étiquetage, où se situe la limite? L’étiquetage indique qui va utiliser l’instrument et à quelle fin?
  • Nous avons besoin d’un équilibre entre la réglementation et la sécurité des patients, et pour permettre le développement et la disponibilité de nouvelles technologies.

Food and Drug Administration des États Unis(US FDA)

Bakul Patel offre un aperçu de la façon dont la US FDA et l’International Medical Device Regulators Forum (IMDRF) traitent cette question. Il décrit trois types de logiciels d’instruments médicaux : les logiciels dans un instrument; les logiciels à titre d’instruments; les logiciels utilisés dans le processus de fabrication d’un instrument. Qu’est qui est un instrument et qu’est-ce qui ne l’est pas? Comment les autorités de réglementation abordent-elles cette catégorie d’instruments? Certains logiciels sont considérés comme des instruments médicaux; d’autres ne répondent pas à la définition d’instruments médicaux.

Il décrit ensuite les activités de l’IMDRF, fournit la définition de LIM élaborée par le groupe de travail de l’IMDRF et explique le cadre d’évaluation des risques des LIM.

Il décrit également un certain nombre des activités de la US FDA dans ce domaine, dont le programme de pré-certification de la FDA, pour une approche de réglementation des LIM simplifiée et axée sur l’entreprise, qui compte sur une culture démontrée de qualité et d’excellence organisationnelle.

Il fait remarquer que nous devons observer la rapidité avec laquelle ces produits évoluent afin de pouvoir créer un processus de réglementation qui ne met pas un frein à ces progrès. Nous devons nous assurer que les fabricants de ces produits sont fiables. Les critères d’évaluation reposent sur cinq principes d’excellence : la sécurité des patients, la qualité des produits, la responsabilité clinique, la cybersécurité et la culture proactive.

La FDA examine actuellement neuf entreprises qui participent à ce programme volontaire.

Les questions soulevées par le Groupe et adressées au présentateur comprennent entre autres les suivantes :

  • Du point de vue des logiciels, le cadre de réglementation pourrait devoir examiner les interfaces pour comprendre où sont les limites.
  • Ne serait-il pas mieux d’inclure la pré-certification dans l’organisation de type ISO pour que toutes les entreprises puissent l’appliquer et qu’elle soit ainsi reconnue par tout le monde?
  • SC envisage-t-il de participer à un processus semblable pour inclure les entreprises canadiennes?

Conseil Canadienne des Innovateurs

Représenté par Dana O’Born, Melissa Perri, Anthony Kaul, Graeme Moffat, David Bissessar

La présentation du CCI comprend un aperçu des LIM et des défis du marché. Les membres ont examiné l’approche de l’IMDRF envers les LIM et font remarquer que de nombreuses définitions dans les documents de l’IMDRF n’ont pas encore été mises à l’essai dans le monde réel. Les catégories de l’IMDRF sont axées sur le produit plutôt que sur l’entreprise. La gestion des modifications logicielles est mal abordée par l’IMDRF. La résidence des données est une préoccupation : qui possède les données? Ils énumèrent un certain nombre de possibilités pour le Canada.

Les membres discutent également des activités aux États-Unis. À quoi attribuer l’excellence des excellentes entreprises de logiciel? Pouvons-nous présumer que « de bonnes pratiques en matière de LIM » sont égales à « de bonnes pratiques en matière de logiciel »?

Ils font remarquer que les logiciels et les instruments médicaux évoluent à différentes échelles de temps. Il existe un certain nombre de préoccupations :

  • Gestion des modifications
  • Contrôle de versions

Le développement de logiciel agile est une pratique standard :

  • Itération rapide, pas de version fixe au lancement
  • L’approche privilégiée dans les logiciels connectés au nuage (améliorations régulières)
  • Point abordé dans le guide AAMI TIR45 (2012)

La réglementation de l’apprentissage machine dans les LIM est toujours très incertaine à l’échelle mondiale.

On fait remarquer que le changement de comportement de l’utilisateur est une autre préoccupation.

Dans le cas des logiciels axés sur les patients :

  • Comment pouvons-nous évaluer la « technophilie » au sein des groupes de patients?
  • La surutilisation a-t-elle des conséquences sur la santé/la santé mentale?
  • Certains utilisateurs exploreront tout l’espace permis par le logiciel – quelles en sont les conséquences?

Dans le cas des logiciels axés sur le changement de comportement :

  • Les utilisateurs suivront le logiciel là où il les mène – comment le logiciel mesure-t-il les résultats et les comportements à adapter?

Logiciel d’aide à la décision pour les professionnels de la santé :

  • Les utilisateurs suivront le logiciel là où il les mène – quelles sont les conséquences de la dépendance à l’égard des logiciels cognitifs sur les décisions?
  • Quelles sont les conséquences de la non-adoption sur les résultats en matière de santé?

Le programme de pré-certification de la FDA est décrit. On fait remarquer que le Canada a un marché beaucoup plus petit et devrait s’employer à harmoniser les réglementations de l’US FDA et du Canada pour améliorer l’accès aux patients et l’accès aux marchés. Normaliser les définitions pratiques pour réduire l’incertitude sur le marché.

Les questions soulevées par le Groupe et adressées au présentateur comprennent entre autres les suivantes :

  • Les technologies agiles ne sont pas nouvelles. La différence réside dans la transparence plutôt que dans la façon dont la technologie logicielle est développée.
  • Pas d’accord avec l’hypothèse selon laquelle « de bonnes pratiques en matière de LIM » sont égales à « de bonnes pratiques en matière de logiciel ». Il y a beaucoup de logiciels médiocres sur le marché. Les entreprises de logiciel ont besoin d’adopter de bonnes pratiques de développement de logiciel. Le niveau de rigueur requis pour valider les logiciels n’est pas le même que celui qui s’applique aux instruments médicaux.
  • Il y a peu de directives sur la façon dont un médecin traite les données produites par les patients durant le diagnostic. Les algorithmes proposés pourraient être inexacts et causer des problèmes.
  • Nous disposons d’un assez grand nombre de développements logiciels par du personnel hautement qualifié (PHQ) pour satisfaire à un programme de diplôme. Nous avons besoin de faciliter la tâche à certains de ces membres du PHQ pour développer leur produit. Nous ne pouvons pas toujours compter sur les grandes entreprises.
  • À l’instar de la US FDA, nous devons encourager les employés de SC à venir au laboratoire de développement de logiciel et à acquérir de l’expérience dans ce domaine - une invitation à visiter les laboratoires du Conseil national de recherches pour acquérir de l’expérience et observer le processus est lancée par le président aux employés de SC.

Medical Devices Canada (MEDEC)

Représenté par Monica Magidin

La présentation de MEDEC se concentre sur les différences entre les LIM et les logiciels autres que les LIM.

Elle présente la définition de l’IMDRF des logiciels à titre d’instruments médicaux. Elle fait remarquer qu’un logiciel serait considéré comme un instrument médical s’il répond à la définition d’un instrument. Cependant, le logiciel ne peut pas « agir » seul; il a besoin d’une interface pour accéder aux données, pour traiter les données ou pour produire les données. Certains logiciels ne sont pas considérés comme des instruments. Les LIM subissent de fréquentes modifications une fois mis sur le marché. La réglementation devra clairement énoncer quand une modification apportée à un LIM a besoin d’une approbation pré-commercialisation ou de notifications post-commercialisation. Les modifications liées au LIM pourraient également se rattacher à la cybersécurité.

Les fabricants doivent relever le défi de fournir des données pertinentes et fiables afin de :

  • élargir les indications concernant l’utilisation
  • réaliser des études des suivis cliniques post-commercialisation
  • demander des critères et objectifs de rendement objectifs

Même en tenant compte des techniques novatrices, les LIM doivent viser un but clair comme l’exige la réglementation actuelle. La collecte des données produites par les LIM pourrait servir à appuyer de nouvelles indications ou allégations, si les données sont recueillies de façon appropriée. Les LIM qui modifient la fin médicale par eux-mêmes sans les contrôles des fabricants ne sont pas en contrôle de leur sécurité et de leur efficacité. Leur vérification et validation ferait l’objet de doutes.

Quelle classification devrait-on appliquer aux logiciels? Comme pour tous les autres instruments médicaux, les logiciels requièrent une approche axée sur le risque pour classifier et appliquer la rigueur de la réglementation. Les logiciels peuvent être classifiés selon les cadres de réglementation existants. L’IMDRF fournit un système de stratification pour déterminer le risque connexe des données de sortie d’un LIM. On s’attend à ce que l’évaluation d’un LIM soit itérative et continue.

SC réglemente l’importation et la vente des instruments médicaux. Les fournisseurs de services d’applications (FSA) sont-ils assujettis à la réglementation?

Pour conclure, elle fait remarquer que :

  • Le LIM est un instrument médical « spécial ».
  • L’adoption complète des principes de l’IMDRF pour les LIM, dans la mesure du possible, doit être envisagée afin de favoriser une approche d’harmonisation.
  • La classification des risques associés aux LIM devrait guider vers des activités appropriées pour la conception et la fabrication.
  • On devrait tenir compte de l’approche d’aide à la prise de décision clinique de la US FDA relativement aux LIM.
  • La réglementation ne devrait pas entraver les modifications logicielles de façon à retarder indûment l’avantage pour l’utilisateur.

Les questions soulevées par le Groupe et adressées au présentateur comprennent entre autres les suivantes :

  • L’interprétation du terme « vente » crée une échappatoire qui permet que certains logiciels soient réglementés comme des instruments et que d’autres soient exemptés de cette réglementation.
  • Si quelqu’un loue un instrument, il n’y a pas de vente; par conséquent, il n’est pas réglementé.
  • On fait remarquer qu’aucun logiciel n’est « vendu » selon les définitions normales; on paie plutôt les licences à utiliser (c.-à-d. que l’acheteur ne « possède » pas le logiciel). Cela est perçu comme une importante échappatoire.
  • Les exigences réglementaires concernant les instruments médicaux sont si élevées qu’en tant que jeune fabricant, vous pourriez choisir de ne pas suivre la voie réglementaire.
  • Ceci est un groupe consultatif et les membres du groupe estiment que la définition actuelle ne semble pas permettre à certains de ces produits d’être considérés comme des instruments. Le groupe invite SC à examiner l’interprétation du terme « vente » pour permettre une application uniforme dans toute la gamme de produits. 
  • L’introduction de changements réglementaires prend beaucoup de temps. Dans le cadre de réglementation actuel, SC a besoin de fournir certaines directives concernant ces produits. L’interprétation légale de ce terme dans la Loi est étroite et rend difficile l’inclusion de certains produits.

Après les présentations, les présentateurs externes quittent la séance.

Lignes directrices provisoires

Pour formuler les questions aux fins de discussion en groupe, Daniel Yoon (SC) offre un aperçu des lignes directrices provisoires concernant les LIM. Ces lignes directrices visent à préciser quels LIM sont assujettis à la réglementation et à fournir des directives sur la manière de classifier les LIM. On explique que les recommandations et les conseils émanant de la réunion d’aujourd’hui seront analysés et pris en compte pour réviser les lignes directrices provisoires. SC a l’intention de publier les lignes directrices aux fins de consultation publique à l’été de 2018. Pour conclure, il résume les questions posées au groupe.

Les questions soulevées par le Groupe et adressées au présentateur comprennent entre autres les suivantes :

  • Les fabricants peuvent-ils suivre les lignes directrices pour développer leur produit? La plupart des lignes directrices sont élaborées pour clarifier les règlements. Elles n’abordent pas les aspects de conception et de développement d’un produit.
  • La consultation publique se fait-elle seulement par le biais d’une publication sur le site Web de SC? Étant donné que de nombreux intervenants sont très occupés, la publication sur le Web devrait être complétée par une sollicitation directe auprès des intervenants. Cela doit être un processus actif.
  • Nous pourrions suivre la façon dont les documents de l’IMDRF ont été publiés aux fins de commentaires et dont on a sollicité de la rétroaction; nous avons besoin de prendre contact avec les organisations qui possèdent des réseaux pour distribuer les documents par leur entremise.
  • Ce groupe a une représentation limitée (principalement de l’Ontario); nous avons besoin de recruter des membres dans l’ensemble des provinces et de rejoindre également les consommateurs éloignés.
  • Quelle est la nature des conseils recherchés par SC? Est-ce seulement sur les lignes directrices ou cela comprend-il des définitions?
  • Le public cible indiqué dans les lignes directrices semble limité. Et si vous avez un développeur de logiciel qui n’est pas au courant de cette réglementation? Peut-être qu’elle devrait également inclure les développeurs de logiciels. SC tente d’inclure les carrefours d’innovation pour obtenir leurs commentaires.
  • L’autorité de réglementation surveille-t-elle activement ce qu’on trouve sur le marché? Certaines des applications disponibles semblent être des instruments; tentons-nous de les surveiller? Comment les utilisateurs savent-ils ce qu’ils obtiennent? L’utilisateur devrait-il recevoir un message au sujet d’une application si elle a été approuvée par une autorité de réglementation? Il s’agit d’un des plus gros défis du programme de surveillance post-commercialisation (SPC). Ce programme ne surveille pas activement les applis. SC compte sur les fabricants et les utilisateurs pour signaler les incidents. Nous aimerions avoir des suggestions sur la façon dont nous pourrions surveiller activement ces applis.
  • La plupart des applis (environ 99 %) sur le marché sont distribuées par deux principaux fournisseurs : la boutique d’applis d’APPLE et GOOGLE Play. APPLE est très rigoureuse quant aux applis qu’elle permet. On pourrait peut-être tenir des discussions avec elle si elle regarde les exigences réglementaires de telles applis. Le marché Android n’est pas aussi rigoureux. Environ 1 000 applis/mois sont créées depuis 2013. Cela nécessite une approche différente.
  • SC a besoin d’introduire un processus d’inscription différent et moins coûteux, semblable peut-être aux lignes directrices relatives aux produits de santé naturels. Une description de haut niveau des exigences réglementaires concernant les produits naturels est fournie.
  • Comment pouvons-nous emprunter des éléments des cadres existants pour concevoir différents ensembles d’exigences pour ces produits?
  • Il est important de reconnaître que l’approbation de SC ne déclenche pas toujours l’intérêt des consommateurs. Les consommateurs pourraient obtenir une appli quel que soit son régime d’emploi homologué.
  • Que dire de la prescription d’applis qui vont au-delà de la fabrication et de la vente et qui jouent le rôle d’un instrument médical? Les cliniciens comptent sur cette information. La plupart de ces instruments ont un contexte personnel. Les LIM nous conduisent vers un paradigme différent et sans précédent pour les instruments. Ces types d’applications pourraient augmenter à un rythme auquel nous ne pouvons pas répondre.

Délibération des questions (tous les membres du Groupe)

Le président présente les questions posées par SC et dirige la discussion.

PARTIE 1 : LIGNES DIRECTRICES PROVISOIRES : LOGICIELS À TITRE D’INSTRUMENTS MÉDICAUX (LIM)

Question 1.1

Santé Canada a utilisé la définition des LIM fournie par l’International Medical Device Regulator’s Forum (IMDRF).

  1. La définition donnée dans la section 1.4 des lignes directrices sur les LIM de Santé Canada est-elle suffisamment claire pour l’éventail de fabricants d’instruments médicaux (des jeunes entreprises aux grandes entreprises bien établies) à qui s’adresse le document?
  2. Connaissez-vous des logiciels médicaux qui ne répondent pas à cette définition?
    • La plupart des membres sont d’accord avec la définition de l’IMDRF; il manque toutefois une chose : les changements graduels (modification de la fonctionnalité); comment va-t-on aborder ce point?
    • Et si le logiciel est sur un nuage? Cette définition tient-elle compte du nuage?
    • Dans certains cas, si le logiciel se trouve dans un instrument (électrocardiographe), il pourrait être éteint et un logiciel tiers pourrait être utilisé. Examinerons-nous ce logiciel différemment? Il semblerait que deux logiciels qui offrent la même fonction seraient traités différemment.
    • Quelle est la différence entre un logiciel d’instrument médical et un LIM?
    • Et les logiciels à porter sur soi (comme Fitbit)? Sont-ils considérés comme des instruments? Quand un logiciel devient-il un instrument médical?
    • Apple est en train de développer une appli sur la montre Apple qui mesure le taux de glucose dans le sang. Va-t-elle être considérée comme un instrument? Ce que fait le logiciel et l’endroit où il est utilisé mènent à la définition.
    • De nombreuses applis permettent à l’utilisateur d’exécuter un algorithme et d’obtenir des indications. Quand seront-elles considérées comme un instrument? L’utilisation prévue d’un capteur définira son état en tant qu’appareil.
    • Quelle importance si c’est seulement un logiciel par opposition à un LIM? Le logiciel d’instrument médical sera enregistré avec le périphérique. Le LIM sera enregistré seul à titre d’instrument ayant sa propre classification. Ces deux logiciels subiront un examen semblable.
    • Il faut un certain libellé concernant l’apprentissage machine.
    • Le but dans la définition est médical. Qu’est-ce qui est « médical »? Peut-être devrions-nous utiliser le terme « lié à la santé » plutôt que médical.
    • Nous sommes confrontés à une question de définition et une question de voie réglementaire.
    • Dans le document Software as a Medical Device: Clinical Evaluation de l’IMDRF, page 11, il y a une illustration qui pourrait être incluse dans ce document pour clarifier cette question. Cette illustration aborde ce qui est considéré comme le traitement d’une donnée.

Question 1.2

La section 2.1.2 des lignes directrices donne des exemples de LIM.

  1. Ces exemples suffisent-ils à bien différencier les logiciels utilisés à des fins autres que médicales, les logiciels d’instruments médicaux et les LIM?
  2. Quels autres exemples pourrions-nous inclure, aux fins de précision?
    • Rien ne cloche avec ces définitions, c’est plutôt où elles sont placées dans un document. Sans parler de la classification, les exemples fournis n’ont pas beaucoup de sens. Placer les exemples après la classification.
    • Dans quelle classe s’inscriraient les dispositifs sensoriels qui offrent de l’aide aux patients? C’est difficile de classer un produit sans disposer de renseignements précis sur son utilisation prévue.
    • Simplifier le document; songer à supprimer toutes les autres définitions du document. Cela semble créer de la confusion.
    • Le besoin énergétique prête à confusion. Le logiciel est-il réellement un instrument actif? Lorsque ces règles ont été créées, on ne considérait pas le logiciel comme un instrument médical. C’est vrai que le logiciel n’applique pas l’énergie pour atteindre son but; nous utilisons une règle existante pour aborder la classification.
    • La règle de classification 10 ne semble pas être bonne pour les logiciels à titre d’instruments médicaux. Quand est-ce qu’un LIM n’est pas un instrument actif?
    • Il y a d’autres règles de classification qui seront également prises en compte en dehors de la règle concernant l’instrument actif.
    • Certains des exemples (page 15, otoscope, et page 7, tensiomètre) ne semblent pas clairs. L’otoscope utilise un capteur universel indiqué pour l’usage général. Ces exemples ont été mis au point par le comité international; on pourrait peut-être les transformer en foire aux questions.
    • Il pourrait être utile de fournir à titre de référence les décisions prises par le passé concernant les logiciels. La US FDA le fait déjà.
    • Exemple du calculateur de dose à la page 17; et que dire des calculateurs de dose pour l’insuline? Vous faites une distinction entre le patient et le clinicien pour savoir qui est l’utilisateur.
    • La citation d’exemples est un processus continu; cela devrait être un document évolutif.
    • La définition et la voie réglementaire sont deux choses différentes. Nous avons besoin d’une définition simple.

Question 1.3

La classification des instruments autres que des IDIV s’appuie principalement sur les critères suivants : ampleur du pouvoir effractif, exposition des tissus et des organes, potentiel d’infection et exposition à une forme d’énergie.

La classification des IDIV repose principalement sur les critères suivants : application clinique (dépistage, diagnostic, surveillance, pronostic, prédisposition, etc.), expertise de l’utilisateur prévu (essai de laboratoire vs test effectué à la maison), l’importance des renseignements pour le diagnostic, la nature de la maladie et l’effet du résultat de test de diagnostic sur la personne.

  1. Santé Canada envisage de classer les logiciels utilisés à titre d’IDIV en utilisant les règles de classification des IDIV, décrites dans la partie 2 de l’annexe 1 du Règlement. Êtes-vous d’accord avec cette façon de faire?
  2. Santé Canada envisage d’adopter la stratégie de la Therapeutic Goods Administration décrite dans l’annexe pour réglementer les logiciels utilisés comme IDIV. Êtes-vous d’accord avec cette façon de faire?
    • Les logiciels ne peuvent faire aucun tort à eux seuls; ce sont les gestes que pose la personne qui en fait la lecture qui peuvent causer du tort.
    • Les règles de classification pourraient obliger le développeur à suivre une voie différente lorsqu’il développe son produit pour choisir une classification plus faible.
    • On fait remarquer que bien que la classification des IDIV se fonde sur le risque pour la santé publique et la santé individuelle, il pourrait y avoir d’autres risques associés aux logiciels ou à la collecte ou au stockage des données qu’il faudrait également prendre en considération (p. ex. confidentialité des données, questions de cybersécurité mentionnées dans les présentations de la FDA et de MEDEC).
    • Pouvons-nous séparer le risque d’affection sous-jacente du logiciel qui fournit une lecture?
    • Le fait de savoir qui est l’utilisateur d’un logiciel particulier semble avoir une incidence sur sa classification. Il incombe au fabricant de fournir des instructions appropriées pour assurer une utilisation sans danger. Les caractéristiques d’atténuation des risques sont importantes.
    • Si nous n’expliquons pas pourquoi nous utilisons une certaine règle, on posera toujours des questions. Nous devons fournir davantage de contextes quant à la façon dont nous classifions un instrument.
    • La matrice des risques fournit les catégories de risques; cependant, elle ne comprend pas le nombre de personnes qui utiliseraient une application. Beaucoup de renseignements sont intégrés dans le texte (voir les pages 12 et 13).
    • Tenons-nous compte du type de données et de la sécurité des données lorsque nous classons les risques par catégories?
    • La grille de classification n’est pas très claire. Comment un développeur de logiciel qui crée l’algorithme pour la fourniture des paramètres pour un état de santé le classifierait-il?
    • Le fabricant doit être très précis quant aux raisons et aux lieux d’utilisation. Ce n’est pas évident de savoir du logiciel même à quelle fin il est prévu. Le fait de savoir qui est l’utilisateur du logiciel fait toute la différence. Selon l’interface, vous pourriez avoir différentes conséquences.
    • Le document, dans son état actuel, est un peu trop étroit. Nous parlons de « médical » sans expliquer ce que cela signifie.
    • Les fabricants fournissent-ils des modes d’emploi? Certains d’entre eux pourraient être disponibles en ligne.
    • La fin prévue doit être très claire.
    • La gestion des risques doit être prévue par le fabricant.
    • Envisager de solliciter les commentaires de professionnels paramédicaux et d’économistes de la santé.
    • Concernant le document de la TGA, s’il a été approuvé par un autre pays, nous pourrions envisager de l’utiliser au Canada.
    • Y a-t-il une raison quelconque d’envisager cette possibilité? L’exemple fourni explique que la classification des IDIV est décidée séparément de celle des logiciels. La classification devrait se fonder sur le risque de l’instrument selon son utilisation prévue.
    • Le Groupe fait remarquer les problèmes potentiels d’adopter comme critère de classification l’ « utilisation prévue ». La question d’une utilisation non prévue potentielle est soulevée.
    • Les risques de la classe IV pour les IDIV sont fondés sur le niveau de risque pour la population. La classe III représente le risque le plus élevé pour une personne. C’est la raison pour laquelle nous aimerions classifier les logiciels d’une manière semblable à l’approche de la TGA.
    • SC évalue déjà le logiciel s’il fait partie intégrante d’un IDIV.
    • On craint de mettre le traitement avec le principe du diagnostic. Le logiciel n’ajoute pas d’autres risques à la forme d’un traitement. Par exemple, le logiciel de réadaptation conseille la physiothérapie à l’utilisateur.
    • Il y a un éventail de facteurs à prendre en considération; c’est difficile de trouver une seule règle pour tous les cas.

Partie 2 : Avenir des logiciels d’instruments médicaux, notamment les LIM et démarche de réglementation de santé canada

Question 2.1

  1. Jugez-vous que Santé Canada devrait réglementer les LIM selon le cadre réglementaire en vigueur ou que Santé Canada devrait modifier ce dernier ou en établir un nouveau afin d’inclure les LIM sous leur forme actuelle? Plus précisément :
  2. Les règles de classification du Règlement sont-elles suffisantes pour classer le risque associé à un LIM?
  3. Les logiciels et les applications peuvent avoir des cycles de développement très courts. Quelles méthodes, initiatives, processus, etc., recommanderiez-vous à Santé Canada pour que le ministère puisse remplir son mandat visant à permettre aux Canadiens d’avoir accès rapidement à des LIM sécuritaires et efficaces?
    • Les cliniciens trouvent qu’il est difficile d’aborder les questions réglementaires; cependant, un nombre moindre de règlements est toujours préférable.
    • Pourquoi la US FDA envisage-t-elle un programme de pré-certification? Le concept de l’équivalence substantielle ne s’applique pas aux logiciels. Il existe une différence technologique. Les logiciels évoluent très rapidement. On compte au moins 1 000 applis/mois et l’autorité de réglementation ne sera pas en mesure de traiter un tel volume. Cela n’est pas durable. C’est la raison pour laquelle la US FDA examine une approche différente.
    • Les règlements existent pour protéger le public. Traditionnellement, les instruments médicaux comportent un long processus de mise au point. Les logiciels avancent à un rythme beaucoup plus rapide. La réglementation du développeur de logiciel plutôt que des logiciels semble être une approche logique.
    • Dans le monde des logiciels, les mises à jour profitent au public; nous ne pouvons pas empêcher la diffusion de ces mises à jour en introduisant un fardeau réglementaire.
    • Si vous êtes un fabricant d’instruments de la classe II, vous devez certifier vos outils comme étant sécuritaires. Cependant, le fardeau de certifier les outils logiciels est tellement lourd que les outils du processus logiciel (p. ex. examen des codes, intégration continue) ne seront pas intégrés au système de qualité officiel, ou ne seront pas du tout utilisés. Cela permet difficilement de rapprocher les bonnes pratiques de développement logiciel et les systèmes de qualité.
    • Les jeunes entreprises sont généralement rachetées par les plus grosses entreprises parce qu’elles ne peuvent pas gérer le fardeau réglementaire.
    • Les ingénieurs logiciels intègrent des algorithmes qui vérifient le logiciel. Une fois que vous avez les vérifications intégrées, c’est facile de passer à la nouvelle génération de logiciel.
    • Pour que les lignes directrices soient robustes, elles doivent évoluer au fil du temps. Les présentes lignes directrices pourraient être désuètes dans un an.
    • Comment pouvez-vous prioriser les outils d’évaluation? Il faut discuter avec les intervenants, demander au public de fournir des commentaires sur les types d’applis qu’ils utilisent.
    • Est-ce que SC regarde actuellement le code de logiciel lorsqu’il évalue ces types de produits? Nous ne regardons pas le code; nous regardons les rapports à l’appui de la validation du logiciel.
    • Il existe des pratiques exemplaires; si quelqu’un développe un LIM, nous devrions lui fournir de bonnes pratiques à utiliser.
    • La US FDA a examiné cela dans un contexte d’évolution des choses, chaque entreprise utilisant différents processus et une terminologie différente; c’est la raison pour laquelle elle examine les organisations, la façon dont elles développent les logiciels à un niveau plus élevé et les résultats sur le marché.
    • On craint que si une ligne directrice est complexe, les entreprises vont l’ignorer. Nous devons publier quelque chose de simple et robuste et le réexaminer au bout d’un an.
    • Le document de la TGA est très simple. Une communication appropriée et un langage approprié contribueraient grandement.
    • Peut-être que si on examinait l’impact clinique d’un logiciel, on pourrait l’aborder en conséquence et l’évaluer différemment.
    • Au Canada,  il y a des comités éthiques qui exigent que les produits soient approuvés par SC avant qu’on envisage leur utilisation. Dans la pratique clinique, le clinicien assume le risque. Comment SC peut-il réduire le risque d’utilisation de ces produits en exerçant une diligence raisonnable sur le produit logiciel?
    • Pourquoi pose-t-on cette question? Elle ne se rapporte pas à la ligne directrice fournie aux fins d’examen. Si vous cherchez vraiment des commentaires, vous devriez le faire avant d’élaborer le document. Vous devez demander avec quoi vous êtes aux prises. Quelles sont vos préoccupations réglementaires?
    • Les questions sont divisées en deux parties; la première partie se concentre sur le document et cherche des commentaires à son sujet, la deuxième consiste à obtenir de la rétroaction sur les lacunes et sur la manière d’aborder ces préoccupations. Cela est décrit dans le préambule des questions qui les met en contexte.
    • Dans le cas des jeunes entreprises, satisfaire aux règlements est très complexe. Ce n’est pas très facile de comprendre les règlements et les règles. Donc la plupart les ignoreraient tout simplement.
    • Peut-être que SC a besoin d’un bureau pour fournir des directives à l’industrie?
    • Les instruments médicaux traditionnels comportent déjà une voie de développement; le développement de logiciel est assez différent. Les logiciels médicaux ne constituent qu’une petite partie des logiciels en général. Nous pourrions examiner d’autres applications et développements logiciels (comme la sécurité des transports) et tirer des leçons de cette expérience. Nous pourrions examiner l’industrie aérienne (navigabilité).
    • Personal Connected Health Alliance vise à faire de la santé et du mieux-être des éléments s’intégrant facilement dans la vie quotidienne. Elle se concentre sur les interfaces avec logiciel. Elle a de nombreux exemples qui pourraient être utiles.
    • Il faut examiner le champ d’application du Bureau des matériels médicaux. Les problèmes que nous tentons de régler sont différents de ceux dans d’autres industries. Nous pouvons toutefois en tirer des leçons.
    • Le sujet de la vie privée des patients serait pertinent pour la deuxième partie de la question. Comment les données sur les patients seraient-elles utilisées par les entreprises? Le niveau de protection serait important.

Question 2.2

  1. Selon vous, les logiciels d’instruments médicaux et les LIM constituent-ils la plus grande tendance émergente?
  2. Quelle sera la plus grande difficulté avec laquelle devra composer Santé Canada dans la réglementation des logiciels d’instruments médicaux et des LIM, dans l’optique de son mandat visant à aider les Canadiens à maintenir et améliorer leur santé?
    • À l’heure actuelle, 99 % des technologies de la santé sont dans les dossiers de santé électroniques (DSE); les applis gratuites représentent une très petite tranche de celles-ci.
    • Vous devez examiner la définition de LIM et déterminer si un DSE quelconque y répond. Le volume d’applis augmentera au fil du temps. La production de données va être importante et mènera vers encore plus d’applications de LIM.
    • On s’interroge sur la propriété d’un produit : il n’y a pas toujours un seul fabricant évident (p. ex. logiciel ouvert). Nous devons créer un environnement qui permet de réaliser ces progrès de manière sécuritaire.
    • Les patients deviennent des experts de leurs propres soins de santé. La quantité d’information à laquelle les patients ont accès est énorme. On lutte pour obtenir des renseignements utiles de ces registres de données.
    • Des applis pour la population négligée (aînés, santé mentale, maladies chroniques). 
    • Des applis pour les personnes intéressées par l’autodiagnostic.
    • Malgré les nombreuses applis sur le marché, on n’y accède pas aussi fréquemment. L’apprentissage machine sera complémentaire aux cliniciens; cependant, il ne remplace pas les cliniciens et il est très coûteux.
    • Le besoin existe de déplacer les ressources des activités pré-commercialisation vers les activités post-commercialisation. Il existe un bon nombre d’applis; nous devons assurer une surveillance post-commercialisation de la performance de ces produits. SC n’en est peut-être pas conscient; il existe toutefois une foule de renseignements sur le marché qu’il pourrait être très utile de connaître pour déterminer lesquels offrent une bonne performance.
    • La plupart de ces développeurs de logiciels sont de jeunes entreprises. La plupart d’entre eux ne connaissent rien au sujet des soins de santé.
    • Besoin d’un document à court terme qui traite des besoins à court terme et qui évolue au fil du temps.
    • Le public canadien n’attend personne; il utilise les applis de son choix quel que soit le statut d’approbation.
    • Nous disposons d’un certain nombre de systèmes de DSE qui sont autonomes; ces systèmes ne se parlent pas entre eux. Ce sera donc très difficile de les réglementer.
    • La plupart des hôpitaux universitaires possèdent un centre d’innovation. La nouvelle technologie est développée plus rapidement que nous le pensons.
    • En tant qu’autorité de réglementation, il faut que nous sortions du cadre de réglementation actuel.
    • Il y a un énoncé de mission qu’il nous faut examiner.

Question 2.3

À l’heure actuelle, les logiciels d’analyse de données infonuagiques à partir des plateformes de séquençage à haut débit, les logiciels Web de planification de la radiothérapie et les calculateurs Web relatifs aux implants intraoculaires ne sont pas réglementés par le Règlement et sont considérés comme étant des logiciels-services (SaaS).

Il se pourrait que les logiciels d’instruments médicaux et les LIM deviennent des technologies qui ne sont pas couvertes par le Règlement ou nos lignes directrices provisoires sur les LIM. Pourriez-vous nous donner d’autres exemples de logiciels qui pourraient ne pas s’inscrire dans la portée du Règlement et nous indiquer si Santé Canada doit jouer un rôle dans la réglementation de la commercialisation de ces logiciels pour nous aider à nous assurer qu’ils sont sécuritaires et efficaces pour les Canadiens?

  • Le logiciel-service (SaaS) est un terme de marketing. Aucun logiciel n’est vendu à l’utilisateur; seule une licence d’utilisation est fournie. L’emplacement du logiciel ne fait aucune différence.
  • Oui c’est possible.
  • Tous les logiciels se classent dans cette catégorie.
  • Les cliniques du diabète dans les milieux hospitaliers ont des systèmes qui permettent aux patients d’accéder à leur dossier; le personnel infirmier peut y accéder et fournir à distance aux patients les décisions en lien avec le dosage.
  • Les médecins décident habituellement d’utiliser ce qui fonctionne efficacement pour eux. L’utilisation d’applis de messagerie pourrait permettre le transfert de renseignements personnels.
  • Les patients impriment en 3D leurs propres instruments, ils ne vérifient pas si c’est approuvé ou non.
  • La technologie liée aux TI se fait remarquer seulement si elle sort de votre établissement.
  • Si vous mettez en place des règlements que vous ne pouvez pas surveiller, cela devient inutile.
  • Il pourrait ne pas y avoir de problème à ne pas le réglementer; cependant, ce que nous présentons ce ne sont pas des règles du jeu équitables. Si le logiciel de planification de radiothérapie ne réside pas dans la machine, il est considéré comme un logiciel-service. L’idée du logiciel-service devrait être retirée de la ligne directrice.
  • Est-ce une interprétation juridique du fait qu’aucune vente n’a eu lieu? Le langage ne suppose pas un échange d’argent; le concept de la vente ne signifie pas toujours la vente d’un produit. Le mot « distribuer » décrit la nature de fournir une licence d’utilisation du logiciel.
  • On devrait demander un deuxième examen juridique de cette interprétation. 
  • Les autorités de réglementation devraient demander ce que nous pouvons accomplir de manière réaliste avec les ressources mises à notre disposition. Sommes-nous le bon bureau pour démarrer cette discussion? Peut-être que nous devrions songer à des organismes à l’extérieur de SC, comme les associations médicales, pour discuter et fournir des directives.
  • Les LIM développés dans les hôpitaux sont également couverts dans le cadre du processus de TI, qui est assez transparent.
  • On peut tout prendre, y compris la chirurgie robotisée, qui a un logiciel résidant dans le nuage. Cela pourrait ne pas être une approche réaliste.
  • L’informatique en brouillard au niveau local, pas un simple serveur.
  • Technologie d’identification par radiofréquence (RFID) tentant de suivre quels médicaments sont donnés à la personne.
  • Chaîne de blocs causant une interruption majeure.
  • Que se passe-t-il quand on perd des données utilisées pour la prise de décision fondée sur des données probantes? La distribution des dossiers comporte ses propres problèmes.
  • Si nous examinons les données stockées au sujet du patient, allons-nous aussi examiner d’autres données personnelles disponibles sur Facebook ou d’autres médias sociaux?
  • La plupart des applications comme Alexa sont exécutées à distance.
  • Identification biométrique, intégrée dans une application médicale; quelle est son incidence sur les instruments médicaux?
  • L’apprentissage machine est effectué à titre de service; la puissance de calcul et les exigences en matière de stockage sont tellement énormes que cela ne se fera jamais sur un serveur local. Des personnes ont posé des questions médicales à Siri et certaines des réponses ont été mal fournies. Tout cela est fondé sur l’infonuagique. La plupart de ces services ne sont pas classiques. Ils s’écartent de la définition d’instrument.
  • Si une appli anti-vaccin a une incidence négative sur la santé publique, la réglementons-nous à titre d’instrument?
  • Il y a un véritable changement de paradigme ici. Peut-être devrions-nous prendre du recul et l’examiner à nouveau.
  • Les gens regardent maintenant les médias sociaux pour voir les intentions de suicide.
  • Siri répond aux questions médicales; est-ce un instrument? Les gens ont besoin de comprendre les limites de ces technologies.
  • Facteurs de risque de la TDIV- y a-t-il un consensus à l’égard de l’approche de SC? Cela pourrait être inexact. L’approche suggérée est une bonne approche; cependant, nous devons l’examiner de plus près pour clarifier les catégories de risque de ces produits logiciels. La ligne directrice de la TGA est un bon départ.

Fin des délibérations.

Résumé des recommandations :

  • Trop de définitions. Simplifier le document; envisager de supprimer toutes les autres définitions du document.
  • Envisager de supprimer les termes qui pourraient ne pas résister à l’épreuve du temps, p. ex. « nuage ».
  • La règle de classification 10 ne semble pas être bonne pour les logiciels à titre d’instruments médicaux. Quand est-ce qu’un LIM n’est pas un instrument actif?
  • Il y a un éventail de facteurs à prendre en considération; c’est difficile de trouver une seule règle pour tous les cas.
  • Si nous n’expliquons pas pourquoi nous utilisons une certaine règle de classification, on posera toujours des questions. Nous devons fournir davantage de contextes quant à la façon dont nous classifions un instrument.
  • Sans expliquer les règles de classification, les exemples fournis n’ont pas beaucoup de sens. Placer les exemples après la classification.
  • Certains des exemples fournis ne sont pas clairs. La citation d’exemples est un processus continu; cela devrait être un document évolutif. On pourrait peut-être les transformer en foire aux questions.
  • Fournir, à titre de référence, des exemples de décisions prises par le passé concernant les logiciels.
  • Concernant les facteurs de risque de la TDIV- l’approche suggérée est une bonne approche; cependant, nous devons l’examiner de plus près pour clarifier les catégories de risque de ces produits logiciels. La ligne directrice de la TGA est un bon départ.
  • De nombreuses applications pourraient ne pas répondre à la définition de LIM. On peut tout prendre, y compris la chirurgie robotisée, qui a un logiciel résidant dans le nuage. Cela pourrait ne pas être une approche réaliste.
  • Il pourrait ne pas y avoir de problème à ne pas les réglementer; cependant, ce que nous présentons ce ne sont pas des règles du jeu équitables. Si le logiciel de planification de radiothérapie ne réside pas dans la machine, il est considéré comme un logiciel-service. L’idée du logiciel-service devrait être retirée de la ligne directrice.
  • Interprétation juridique de « vente » - le langage ne suppose pas un échange d’argent; le concept de la vente ne signifie pas toujours la vente d’un produit. Le mot « distribuer » décrit la nature de fournir une licence d’utilisation du logiciel. Il faut demander un examen juridique de cette interprétation. 
  • Il y a un véritable changement de paradigme ici. Peut-être devrions-nous prendre du recul et l’examiner à nouveau.
  • Nous avons besoin d’un équilibre entre la réglementation et la sécurité des patients, et pour permettre le développement et la disponibilité de nouvelles technologies.

Santé Canada examinera la rétroaction du Groupe pour réviser le document provisoire. La ligne directrice révisée sera publiée aux fins de consultation à l’été de 2018.

Puisque les commentaires portent sur des lignes directrices provisoires qui ne sont pas accessibles au public, le compte rendu des délibérations sera distribué aux fins d’examen par les membres du Groupe et d’approbation du président. SC avisera les membres avant de publier la ligne directrice révisée.

La FDA a manifesté son intérêt à accéder à la rétroaction du public afin d’en tenir compte lors de la révision des documents de l’IMDRF.

Mot de la fin / levée de la séance (président)

Le président remercie les membres de leur participation. La séance est levée.

[Remarque : Ce compte rendu des délibérations sera présenté et approuvé en anglais par le président du GCS-LIM]

Références :

International Medical Device Regulatory Forum (IMDRF), Software as a Medical Device (SaMD): Key Definitions, groupe de travail sur les LIM de l’IMDRF N10, 2013. (En anglais seulement)

International Medical Device Regulatory Forum (IMDRF), Software as a Medical Device (SaMD): Application of Quality Management, groupe de travail sur les LIM de l’IMDRF, 2015. (En anglais seulement)

International Medical Device Regulatory Forum (IMDRF), “Software as a Device”: Possible Framework for Risk Categorization and Corresponding Considerations, groupe de travail sur les LIM de l’IMDRF, 2014. (En anglais seulement)

International Medical Device Regulatory Forum (IMDRF), Software as a Medical Device Clinical Evaluation, groupe de travail sur les LIM de l’IMDRF, 2017. (En anglais seulement)

Règlement sur les instruments
Signaler un problème ou une erreur sur cette page
Veuillez sélectionner toutes les cases qui s'appliquent :

Merci de votre aide!

Vous ne recevrez pas de réponse. Pour toute question, contactez-nous.

Date de modification :