Un projet d’IA médicale n’est pas admissible à la RS&DE du seul fait que le modèle est nouveau, que le jeu de données est volumineux ou que le produit exige une présentation à Santé Canada. La question utile est plus étroite : l’équipe a-t-elle fait face à une incertitude scientifique ou technologique que les connaissances disponibles ne permettaient pas de résoudre, puis a-t-elle mis à l’épreuve des explications possibles par l’expérimentation ou l’analyse?
Cette distinction compte pour l’imagerie, les outils de diagnostic et les logiciels d’aide à la décision clinique, parce qu’un même programme de développement peut comprendre des expériences admissibles, de l’ingénierie courante et des travaux réglementaires.
Partir du point où la méthode attendue a cessé de fonctionner
Imaginons une équipe dont le modèle d’imagerie donne de bons résultats avec les données d’un hôpital, mais perd de la sensibilité sur les images provenant d’un autre appareil d’imagerie ou d’une autre population de patients.
Si les méthodes établies d’étalonnage, de prétraitement et d’entraînement règlent le problème, les travaux peuvent relever de l’ingénierie courante. Si l’équipe ne peut pas expliquer l’échec à l’aide des connaissances qui lui sont raisonnablement accessibles, le problème peut présenter une incertitude technologique.
L’équipe pourrait vérifier si les paramètres d’acquisition, les différences d’annotation, le déséquilibre des classes, les artefacts propres à l’appareil d’imagerie ou l’architecture du modèle expliquent la variation de performance. Chaque expérience doit avoir une raison d’être, un résultat observable et un lien clair avec ce que l’équipe a essayé ensuite.
Les renseignements actuels de l’ARC sur l’admissibilité décrivent la RS&DE comme des travaux visant un avancement scientifique ou technologique et menés au moyen d’une investigation ou d’une recherche systématique, par voie d’expérimentation ou d’analyse. Un objectif de produit, à lui seul, ne répond pas à ce critère.
Les travaux sur les données suivent leur finalité
Les équipes d’IA médicale consacrent beaucoup de temps à étiqueter, nettoyer, harmoniser et revoir des données. Une partie de ce travail peut appuyer directement une expérience admissible. La préparation courante des données et les activités normales sont exclues.
Constituer un autre jeu d’entraînement standard ne devient pas de la RS&DE parce qu’un modèle l’utilisera. Un jeu de données ciblé, constitué pour vérifier pourquoi la performance se dégrade dans une situation clinique précise, peut constituer des travaux de soutien si son ampleur correspond aux besoins de l’expérience.
Gardez le raisonnement visible. Consignez l’échec étudié, la raison pour laquelle les cas retenus permettent de le mettre à l’épreuve, la façon dont la norme de référence a été établie et ce que le résultat a changé. Notre article sur la collecte de données courante explique cette frontière dans le contexte plus large de la recherche médicale.
La preuve réglementaire répond à une autre question
Les lignes directrices actuelles de Santé Canada sur les instruments médicaux fondés sur l’apprentissage machine portent sur la preuve de la sûreté et de l’efficacité tout au long du cycle de vie du produit. Elles traitent de la sélection des données, du développement et de l’entraînement, des essais, de la validation clinique, de la transparence et de la surveillance après la mise en marché. Elles décrivent aussi des plans de contrôle des changements préétablis pour certaines modifications planifiées d’un modèle.
Ces exigences ne déterminent pas l’admissibilité à la RS&DE.
Une étude de validation peut confirmer qu’un modèle achevé respecte une spécification connue. Il peut s’agir d’un travail réglementaire important sans que ce soit du développement expérimental. La question, pour la RS&DE, est de savoir si l’équipe a dû produire de nouvelles connaissances scientifiques ou technologiques parce qu’elle ne savait pas comment atteindre le résultat requis.
Un même protocole peut comprendre les deux types de travaux. Distinguez l’expérience qui s’attaque à l’incertitude des essais de conformité, de la documentation pour la demande d’homologation, du déploiement et de la surveillance courante.
Conserver l’historique des expériences que les cliniciens produisent déjà
Les équipes d’IA médicale disposent souvent de preuves utiles dans les fiches de modèle, les outils de suivi des expériences, l’historique du code, les analyses d’erreurs, les versions du protocole, les consignes d’annotation et les rapports de performance. Ces documents deviennent plus utiles lorsqu’ils montrent la logique qui relie une itération à la suivante.
Qu’est-ce que l’équipe ne pouvait pas accomplir au départ? Quelle explication a-t-elle mise à l’épreuve? Que s’est-il passé? Pourquoi l’expérience suivante a-t-elle changé?
Une liste d’exécutions de modèles sans ce raisonnement peut ressembler à de l’optimisation ordinaire. Un court journal des décisions peut montrer comment l’équipe a mis ses hypothèses à l’épreuve et ce qu’elle a appris, y compris pourquoi une approche a échoué.
Le succès n’est pas exigé. Les lignes directrices de l’ARC précisent que la réussite ou l’échec dans l’atteinte de l’objectif du projet ne détermine pas si les travaux satisfont à l’exigence d’avancement. Les travaux doivent tout de même comporter l’incertitude, la démarche expérimentale et les preuves à l’appui.
Si votre équipe développe des logiciels d’IA médicale, de diagnostic ou d’imagerie, un examen de la RS&DE pour les entreprises de technologies médicales peut aider à distinguer les travaux expérimentaux des travaux d’ingénierie et réglementaires qui les entourent. Pour discuter des faits d’un projet, communiquez avec MITRAS au moyen du formulaire de consultation.