Vous ne le savez peut-être pas, mais en mai 2020 tout va changer pour les logiciels médicaux dont la finalité est le suivi, le soin ou la prise en charge des patients. Comme trop souvent, les grands perdants seront les utilisateurs et, in fine, potentiellement les patients eux-mêmes. Explications.
J'aurais pu pour débuter ce billet vous refaire l'historique franco-français des logiciels médicaux, de la certification des LAP (logiciel d'aide à la prescription) par la HAS, de la fin de cette certification due à un jugement de la Cour européenne de justice, mais je ne me lancerais pas là dedans. Cela serait long et ennuyeux (ceux qui auraient besoin d'une séance de rattrapage pourront utiliser leur moteur de recherche favori). Je préfère ici regarder le futur.
Quel est ce futur ? Notez d'abord qu'il est gouverné au niveau européen par 2 textes importants :
- RÈGLEMENT (UE) 2017/745 DU PARLEMENT EUROPÉEN ET DU CONSEIL du 5 avril 2017 relatif aux dispositifs médicaux, modifiant la directive 2001/83/CE, le règlement (CE) no 178/2002 et le règlement (CE) no 1223/2009 et abrogeant les directives du Conseil 90/385/CEE et 93/42/CEE
- MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR October 2019
Vous noterez que le second est une sorte de récapitulatif et d'aide à l'interprétation du premier et des documents antérieurs de références. Si vous souhaitez, fouiller cette page le site de l'ANSM vous offrira un bon point de départ pour trouver tout ce que vous cherchez.
Quelle semble être la problématique ? Les premiers paragraphes du règlement européen vous donneront rapidement le ton : la sécurité.
Vous savez, ce mot à la mode qui permet de justifier absolument tout dans les démocraties modernes, des agissements du genre de ceux dénoncés par des hommes comme Edward Snowden avec de la surveillance de masse, en passant par des lois liberticides, ou encore la répression policière sanglante contre le peuple.
Qui en santé ne voudrait pas plus de sécurité ? Bien évidemment, personne ne peut répondre par la négative dans ce domaine comme dans beaucoup d'autres.
La question n'est donc pas celle du but, mais celle des moyens.
Soyez rassurés, mon discours purement politique s’arrêtera ici. Passons maintenant au concret.
Prenons la page 27 du second document et considérons cet exemple :
"Diagnostic MDSW intended for scoring depression based on inputted data on a patient’s symptoms (e.g. mood, anxiety) should be classified as class IIb under Rule 11(a)"
Je n'ai pas la prétention d'être un grand anglophone, mais je traduirais ceci comme ça :
"Les logiciels médicaux destinés à évaluer la dépression sur la base des données saisies sur les symptômes du patient (par exemple, humeur, anxiété) doivent être classés dans la classe IIb de la règle 11 a)."
En langage clair : un logiciel qui calcule un score de dépression est un dispositif médical de classe IIb. Il doit donc être marqué CE pour cela, avec toutes les conséquences juridiques, administratives et financières que cela comporte avant sa mise sur le marché. Pourquoi IIb ? Parce la règle 11 de classification des DM le fait appartenir à cette catégorie (cf page 144 du règlement).
Ici il faut préciser une chose : d'après le règlement, un logiciel peut être simplement une brique d'un logiciel plus important.
Ainsi de nombreuses briques d'un logiciel ne relèveront souvent pas du statut de dispositif médical. À titre d'exemple, voici ce que dit notre guide européen (p19) sur les logiciels de gestion de dossiers médicaux informatisés (DMI) :
" Electronic patient record systems are intended to store and transfer electronic patient records. They archive all kinds of documents and data related to a specific patient. The electronic patient records should not be qualified as a medical device, i.e. an electronic patient record that simply replaces a patient’s paper file does not meet the definition of a medical device. The modules used with electronic patient record system modules that might be qualified in their own right as medical devices (MDSW) are for example:
• An image viewer with functionality for diagnosis based on digital images;
• A medication module "
" Les systèmes de dossiers de patients électroniques sont conçus pour stocker et transférer des dossiers de patients électroniques. Ils archivent toutes sortes de documents et de données liés à un patient spécifique. Les dossiers de patient électroniques ne doivent pas être qualifiés de dispositifs médicaux, c’est-à-dire qu’un dossier de patient électronique qui remplace simplement le dossier papier du patient ne correspond pas à la définition d’un dispositif médical. Les modules utilisés avec les système de dossier patient électronique pouvant être qualifiés de dispositifs médicaux (MDSW) sont par exemple:
• un visualiseur d'images doté de fonctionnalités de diagnostic basées sur des images numériques;
• un module de médicaments "
Ok, tout ceci pourrait être clair, mais :
- calculer l'âge d'un patient à partir d'une date de naissance est-il un processus relevant d'un DM ?
- et calculer un indice de masse corporel (IMC) ?
- et calculer la date de terme d'une grossesse ?
Je vous entends déjà rire, jaune pour ceux qui entrevoient déjà la finalité de mon propos.
Une erreur sur un âge peut provoquer de nombreux problèmes médicaux.
Pourtant calculer un âge, faire une addition pour calculer un score médical est-elle un processus qui nécessite de sortir le parapluie nucléaire de la certification ? Oui, non ? Sinon, où est la limite ?
Le risque de cette législation est évident : en souhaitant introduire de la sécurité par la certification par un tiers, l'Europe va entraîner toute la filière vers le bas :
- qui va inclure des scores dans ses logiciels si la moindre addition basique relève d'un processus de certification long, coûteux ?
- qui va subir la répercussion du coût ?
- qui va retourner à la feuille papier ou à la calculette faute d'avoir des outils livrés, s'ils le sont un jour, à l'heure ?
Mais attendez, vous n'avez rien vu encore, la suite justifiera pleinement le titre de ce billet.
Il y a quelques semaines, vous avez peut-être vu passer cette info (lien ajouté le 21/11) : un outil statistique utilisé en science et en recherche a été mis en défaut. Le problème : il ne renvoyait pas les mêmes résultats suivant qu'il était utilisé sur l'un ou l'autre des systèmes d'exploitation.
Cela illustre bien là où cette certification est conceptuellement parfaitement stupide : parce qu'elle considère l'outil hors contexte. Il y a dans un ordinateur des millions de raisons pour que 1 + 1 ne fasse pas 2. La certification, elle, considère que parce qu'à un instant T sur un système donné votre code produira 1 + 1 = 2 alors cela sera à jamais officiel, certifié. Mais ce n'est pas vrai !
Faudrait-il auditer alors l'ensemble d'un système, figer sa configuration dans le marbre et n'autoriser son exploitation que dans ce cadre ?
Si la chose est peut-être encore théoriquement possible pour des petits systèmes embarqués, elle est strictement impossible sur des ordinateurs en usage quotidien. La moindre clef USB insérée, le moindre site internet consulté introduisent leur lot d'aléas et d’interactions relevant du bug de catégorie "pas de chance" à celui étiqueté "haute malveillance".
Alors qu'elle est la solution pour plus de sécurité en santé ? C'est la même que partout ailleurs : la transparence.
Dans le monde informatique cela passe par un seul et unique concept : le logiciel libre ou, à défaut, uniquement open source.
C'est cette solution que l'Europe aurait dû exiger des éditeurs : la transparence du code qui produit le résultat apparaissant à l'écran.
Cette transparence implique en effet 2 choses :
- quand on met à nu son produit, on fait tout les efforts pour qu'il soit beau, propre et pas ridicule en comparaison aux autres (en d'autres termes, on ne fait pas un travail de sagouin au prétexte qu'on sera le seul à le savoir).
- quand un produit est nu, transparent, chacun peut en examiner le fonctionnement, chacun devient certificateur et potentiel lanceur d'alerte sur une fonction suspecte.
Pour revenir à notre problématique, quand bien même une brique logiciel serait open source, il faudrait encore que toutes celles sous-jacentes et celles s'exécutant concomitamment le soient également. C'est ce que propose le système d'exploitation Linux par exemple. Mais croyez-vous ici que le petit processus d'une société de certification européenne ira auditer Windows ou macOS qui sont pourtant les principaux vecteurs d'insécurité dans le contexte d'exécution d'un programme informatique ? Non. Personne n'a le droit de regarder le code source de Windows.
Ainsi, en choisissant le modèle de la certification, l'Europe pose un frein majeur à l'innovation en ajoutant des couches administratives qui sont illusoires et risquent de ne servir ni les éditeurs ni les utilisateurs, et finalement, ni les patients. Elle ne répond en rien au problème de sécurité logiciel, négligeant totalement les caractéristiques du produit dont elle traite, produit qui plus que tout autre est majoritairement sujet aux influences des processus frères ou parents sur lesquels il repose dans son environnement d'exécution.
Enfin elle rate un potentiel tournant historique qui aurait pu être de faire de l’univers logiciel santé un monde open-source, seule stratégie valable pour atteindre modestement un début d'objectif sécuritaire, et par la même injecter dans ce secteur toute l'éthique portée par les valeurs européennes (celles sur le papier bien sûr ... pas celles des lobbies qui n'ont probablement pas manqué pour faire aboutir à ces absurdités).
Quel est ce futur ? Notez d'abord qu'il est gouverné au niveau européen par 2 textes importants :
- RÈGLEMENT (UE) 2017/745 DU PARLEMENT EUROPÉEN ET DU CONSEIL du 5 avril 2017 relatif aux dispositifs médicaux, modifiant la directive 2001/83/CE, le règlement (CE) no 178/2002 et le règlement (CE) no 1223/2009 et abrogeant les directives du Conseil 90/385/CEE et 93/42/CEE
- MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR October 2019
Vous noterez que le second est une sorte de récapitulatif et d'aide à l'interprétation du premier et des documents antérieurs de références. Si vous souhaitez, fouiller cette page le site de l'ANSM vous offrira un bon point de départ pour trouver tout ce que vous cherchez.
Quelle semble être la problématique ? Les premiers paragraphes du règlement européen vous donneront rapidement le ton : la sécurité.
Vous savez, ce mot à la mode qui permet de justifier absolument tout dans les démocraties modernes, des agissements du genre de ceux dénoncés par des hommes comme Edward Snowden avec de la surveillance de masse, en passant par des lois liberticides, ou encore la répression policière sanglante contre le peuple.
Qui en santé ne voudrait pas plus de sécurité ? Bien évidemment, personne ne peut répondre par la négative dans ce domaine comme dans beaucoup d'autres.
La question n'est donc pas celle du but, mais celle des moyens.
Soyez rassurés, mon discours purement politique s’arrêtera ici. Passons maintenant au concret.
Prenons la page 27 du second document et considérons cet exemple :
"Diagnostic MDSW intended for scoring depression based on inputted data on a patient’s symptoms (e.g. mood, anxiety) should be classified as class IIb under Rule 11(a)"
Je n'ai pas la prétention d'être un grand anglophone, mais je traduirais ceci comme ça :
"Les logiciels médicaux destinés à évaluer la dépression sur la base des données saisies sur les symptômes du patient (par exemple, humeur, anxiété) doivent être classés dans la classe IIb de la règle 11 a)."
En langage clair : un logiciel qui calcule un score de dépression est un dispositif médical de classe IIb. Il doit donc être marqué CE pour cela, avec toutes les conséquences juridiques, administratives et financières que cela comporte avant sa mise sur le marché. Pourquoi IIb ? Parce la règle 11 de classification des DM le fait appartenir à cette catégorie (cf page 144 du règlement).
Ici il faut préciser une chose : d'après le règlement, un logiciel peut être simplement une brique d'un logiciel plus important.
Ainsi de nombreuses briques d'un logiciel ne relèveront souvent pas du statut de dispositif médical. À titre d'exemple, voici ce que dit notre guide européen (p19) sur les logiciels de gestion de dossiers médicaux informatisés (DMI) :
" Electronic patient record systems are intended to store and transfer electronic patient records. They archive all kinds of documents and data related to a specific patient. The electronic patient records should not be qualified as a medical device, i.e. an electronic patient record that simply replaces a patient’s paper file does not meet the definition of a medical device. The modules used with electronic patient record system modules that might be qualified in their own right as medical devices (MDSW) are for example:
• An image viewer with functionality for diagnosis based on digital images;
• A medication module "
" Les systèmes de dossiers de patients électroniques sont conçus pour stocker et transférer des dossiers de patients électroniques. Ils archivent toutes sortes de documents et de données liés à un patient spécifique. Les dossiers de patient électroniques ne doivent pas être qualifiés de dispositifs médicaux, c’est-à-dire qu’un dossier de patient électronique qui remplace simplement le dossier papier du patient ne correspond pas à la définition d’un dispositif médical. Les modules utilisés avec les système de dossier patient électronique pouvant être qualifiés de dispositifs médicaux (MDSW) sont par exemple:
• un visualiseur d'images doté de fonctionnalités de diagnostic basées sur des images numériques;
• un module de médicaments "
Ok, tout ceci pourrait être clair, mais :
- calculer l'âge d'un patient à partir d'une date de naissance est-il un processus relevant d'un DM ?
- et calculer un indice de masse corporel (IMC) ?
- et calculer la date de terme d'une grossesse ?
Je vous entends déjà rire, jaune pour ceux qui entrevoient déjà la finalité de mon propos.
Une erreur sur un âge peut provoquer de nombreux problèmes médicaux.
Pourtant calculer un âge, faire une addition pour calculer un score médical est-elle un processus qui nécessite de sortir le parapluie nucléaire de la certification ? Oui, non ? Sinon, où est la limite ?
Le risque de cette législation est évident : en souhaitant introduire de la sécurité par la certification par un tiers, l'Europe va entraîner toute la filière vers le bas :
- qui va inclure des scores dans ses logiciels si la moindre addition basique relève d'un processus de certification long, coûteux ?
- qui va subir la répercussion du coût ?
- qui va retourner à la feuille papier ou à la calculette faute d'avoir des outils livrés, s'ils le sont un jour, à l'heure ?
Mais attendez, vous n'avez rien vu encore, la suite justifiera pleinement le titre de ce billet.
Il y a quelques semaines, vous avez peut-être vu passer cette info (lien ajouté le 21/11) : un outil statistique utilisé en science et en recherche a été mis en défaut. Le problème : il ne renvoyait pas les mêmes résultats suivant qu'il était utilisé sur l'un ou l'autre des systèmes d'exploitation.
Cela illustre bien là où cette certification est conceptuellement parfaitement stupide : parce qu'elle considère l'outil hors contexte. Il y a dans un ordinateur des millions de raisons pour que 1 + 1 ne fasse pas 2. La certification, elle, considère que parce qu'à un instant T sur un système donné votre code produira 1 + 1 = 2 alors cela sera à jamais officiel, certifié. Mais ce n'est pas vrai !
Faudrait-il auditer alors l'ensemble d'un système, figer sa configuration dans le marbre et n'autoriser son exploitation que dans ce cadre ?
Si la chose est peut-être encore théoriquement possible pour des petits systèmes embarqués, elle est strictement impossible sur des ordinateurs en usage quotidien. La moindre clef USB insérée, le moindre site internet consulté introduisent leur lot d'aléas et d’interactions relevant du bug de catégorie "pas de chance" à celui étiqueté "haute malveillance".
Alors qu'elle est la solution pour plus de sécurité en santé ? C'est la même que partout ailleurs : la transparence.
Dans le monde informatique cela passe par un seul et unique concept : le logiciel libre ou, à défaut, uniquement open source.
C'est cette solution que l'Europe aurait dû exiger des éditeurs : la transparence du code qui produit le résultat apparaissant à l'écran.
Cette transparence implique en effet 2 choses :
- quand on met à nu son produit, on fait tout les efforts pour qu'il soit beau, propre et pas ridicule en comparaison aux autres (en d'autres termes, on ne fait pas un travail de sagouin au prétexte qu'on sera le seul à le savoir).
- quand un produit est nu, transparent, chacun peut en examiner le fonctionnement, chacun devient certificateur et potentiel lanceur d'alerte sur une fonction suspecte.
Pour revenir à notre problématique, quand bien même une brique logiciel serait open source, il faudrait encore que toutes celles sous-jacentes et celles s'exécutant concomitamment le soient également. C'est ce que propose le système d'exploitation Linux par exemple. Mais croyez-vous ici que le petit processus d'une société de certification européenne ira auditer Windows ou macOS qui sont pourtant les principaux vecteurs d'insécurité dans le contexte d'exécution d'un programme informatique ? Non. Personne n'a le droit de regarder le code source de Windows.
Ainsi, en choisissant le modèle de la certification, l'Europe pose un frein majeur à l'innovation en ajoutant des couches administratives qui sont illusoires et risquent de ne servir ni les éditeurs ni les utilisateurs, et finalement, ni les patients. Elle ne répond en rien au problème de sécurité logiciel, négligeant totalement les caractéristiques du produit dont elle traite, produit qui plus que tout autre est majoritairement sujet aux influences des processus frères ou parents sur lesquels il repose dans son environnement d'exécution.
Enfin elle rate un potentiel tournant historique qui aurait pu être de faire de l’univers logiciel santé un monde open-source, seule stratégie valable pour atteindre modestement un début d'objectif sécuritaire, et par la même injecter dans ce secteur toute l'éthique portée par les valeurs européennes (celles sur le papier bien sûr ... pas celles des lobbies qui n'ont probablement pas manqué pour faire aboutir à ces absurdités).
Crédit photo : Ciocan Ciprian.