Un logiciel d’aide à la prescription médicale est un dispositif médical

image_pdfimage_print

Les logiciels  d’aide à la prescription médicale sont des dispositifs médicaux selon la CJUE

Le 7 décembre 2017, la Cour de Justice de l’Union Européenne (“CJUE”) a rendu un arrêt important pour les logiciels d’aide à la prescription médicale dans l’Affaire C-329/16 – SNITEM et Philips c. Premier Ministre des Affaires sociales et de la Santé. Une première jurisprudence qui suit les conclusions de l’avocat général du 28 juin 2017 et qui clarifie enfin les conditions permettant de considérer un logiciel comme dispositif médical.

Ainsi, la CJUE a considéré que la fonctionnalité d’un logiciel d’aide à la prescription médicale et qui permet “l’exploitation de données propres à un patient, aux fins, notamment, de détecter les contre-indications, les interactions médicamenteuses et les posologies excessives” est un dispositif médical (DM), cela même sans action directe dans ou sur le corps humain. Les fonctionnalités de ce logiciel qui visent un tel but sont dès lors soumises à la réglementation sur les dispositifs médicaux et doivent répondre aux exigences de la Directive 93/42/CEE. Par contre, les fonctionnalités de ce même logiciel qui ne répondraient pas à ces conditions ne pas sont soumises à la Directive.

__________________

Le marquage CE est suffisant

La Cour ajoute qu’une fois que le logiciel a obtenu l’apposition du “marquage CE“, une autorité nationale ne peut pas exiger de certification supplémentaire, puisque le marquage CE remplit déjà cette fonction.

Dans cette affaire française, un décret imposait l’obligation de certification pour les logiciels d’aide à la prescription (LAP) et à la dispensation médicale (LAD) prévue à l’article L.161-38 du code de la sécurité sociale (CSS). L’autorité française exigeait une certification spécifique, car elle considérait que les LAP et LAD n’entraient pas dans la catégorie des DM. Faux, a considéré la CJUE en balayant ce raisonnement et rappelant que la volonté de Philips de commercialiser son logiciel ICCA avait clairement une finalité médicale.

Il s’agit d’un arrêt important pour les éditeurs de logiciels actifs dans les logiciels ou les applications mobiles de santé qui souhaitent les mettre sur le marché en Europe, mais également en Suisse. En effet, si dans ses conclusions la Cour rappelle qu’il est obligatoire que le logiciel porte le marquage CE (art. 17 par. 1 de la Directive 93/42/CEE), elle précise toutefois qu’une fois fait, un tel logiciel de santé “peut être mis sur le marché et circuler librement dans l’Union sans aucune autre procédure supplémentaire, telle une nouvelle certification“.

Cet arrêt européen est un allègement qui sert l’industrie et permet de gagner du temps pour la mise sur le marché. Par cette clarification, on permet d’éviter de dépenser, dans le doute, des frais supplémentaires en vue d’une certification complémentaire pour les fonctionnalités bénéficiant déjà du marquage CE. On évite l’étape de la conformité préventive ou par précaution. D’un point de vue juridique, il faudra aussi se demander s’il est possible de se faire rembourser les frais  liés à l’obtention d’une certification inutile, voire illégale en cas d’annulation ou de modification de ce décret. En effet, cette décision est très probablement transposable à d’autres logiciels et potentiellement à d’autres Etats Membres de l’Union européenne.

__________________

Portée de cette décision

Quelle est la portée de cette décision?

D’abord, elle s’applique clairement aux logiciels d’aide à la prescription médicale. Mais pas seulement: cet arrêt clair de la CJUE s’étend potentiellement par analogie à tous les logiciels de santé ou applications mobiles de santé ayant une finalité médicale et qui produisent une action médicale, cela même si ce n’est pas dans ou sur le corps humain. Il est néanmoins nécessaire de procéder à une analyse pour chaque cas de figure.

Ensuite, cette décision s’applique aussi aux hôpitaux qui développent des logiciels ou des applications mobiles de santé, car ils sont considérés comme des fabricants de logiciels, même sans commercialisation, au même titre que le responsable de première mise sur le marché. Il sera dès lors nécessaire pour les établissements de soins qui développent des logiciels de procéder à une analyse des fonctionnalités avant d’être mis sur le marché ou déployé et, cas échéant, apposer le marquage CE.

D’un point de vue territorial, cette décision, bien qu’européenne, s’applique à la Suisse. En effet, la législation sanitaire suisse et Swissmedic renvoient aux Directives européennes et la Suisse reconnaît les logiciels mis sur le marché lorsqu’ils sont au bénéfice du marquage CE.

Enfin, cet arrêt même basé sur la Directive 93/42/CEE conserve sa validité avec l’entrée en vigueur du Règlement UE 2017/745 sur les dispositifs médicaux, qui la remplacera dès le 26 mai 2020.

Cette nouvelle fait écho à mon article de septembre 2016 sur “La réglementation des applications médicales mobiles” qui contient une analyse plus détaillée des conditions de mise sur le marché d’un logiciel de santé mobile aux USA, en Europe et en Suisse. Cette publication contient également des exemples de logiciels et applications mobiles de santé, autre que les logiciels d’aide à la prescription médicale qui peuvent être ou non des DM.

__________________

Plus en détails – Contexte du litige

En France, ce litige est né au sujet du logiciel “Intellispace Critical Care and Anesthesia” (ICCA”) développé par Philips, qui s’oriente vers les technologies de la santé. Ce programme informatique a pour but l’aide à la prescription médicale et a pour domaine d’application “l’anesthésie et la réanimation et fournit au médecin les renseignements dont il a besoin pour prescrire correctement les médicaments, notamment en ce qui concerne leurs éventuelles contre‑indications, les interactions entre les différents médicaments et les posologies excessives”.

Le litige opposait le SNITEM (syndicat national de l’industrie des technologies médicales) et Philips d’une part, au Premier Ministre des Affaires sociales et de la Santé d’autre part.  Philips soutenait  que son logiciel, déjà au bénéfice du marquage CE n’avait pas besoin, contrairement à ce que prétendait l’autorité française, de faire l’objet d’une certification supplémentaire spécifique aux logiciels d’aide à la prescription médicale, tel que le prévoit un décret français. Philips soutenait que le marquage CE était suffisant, et que d’imposer une certification supplémentaire constituerait une “mesure d’effet équivalent à une restriction quantitative à l’importation“. L’autorité française, de son côté, soutenait que le logiciel: (a) n’était pas un dispositif médical, (b) ne pouvait pas être commercialisé sans l’autorisation des autorités nationales et enfin (c) ne peut pas être mis en vente libre sur la base du seul marquage CE.

En clair, Philips considérait que son logiciel est un dispositif médical et que s’il obtient le marquage CE, il peut être commercialisé sans devoir se conformer à d’autres exigences supplémentaires. Philips obtiendra gain de cause sur cette question.

__________________

Enjeux de cette affaire et  premier précédent

La question centrale de cette affaire posée à la CJUE, n’était pas celle de la certification, mais celle de savoir si, au regard de la Directive 93/42/CEE sur les dispositifs médicaux, le logiciel ICCA doit être qualifié de dispositif médical ou non. La question juridique posée à la CJUE peut paraître un peu banale, mais elle ne l’est en fait pas du tout. En effet, les obligations et les contraintes pour les fabricants de logiciels sont très différentes si le logiciel est qualifié de dispositif médical ou non. Alors que la CJUE ne l’avait fait qu’indirectement dans l’affaire allemande Brain Products GmbH c/ BioSemi VOF e.a., la CJUE se prononce enfin sur les critères permettant de qualifier un logiciel de DM. Dans l’affaire précitée, la CJUE avait seulement mentionné que les logiciels de bien-être sportif ou de fitness ne répondaient probablement pas à la qualification de dispositifs médicaux, tandis que le logiciel permettant d’enregistrer l’activité cérébrale humaine oui.

Cet arrêt rappelle également le renvoi au lignes directrices MEDDEV 2.1/6 de l’UE en matière de logiciels de santé qui font office de base pour déterminer si son logiciel de santé doit faire l’objet de la réglementation européenne sur les DM avant la mise sur le marché, comme l’a rappelé l’avocat général dans ses recommandations du 28 juin 2017.

__________________

CONDITIONS ET EXEMPLES 

Deux conditions cumulatives, rappelle la Cour, doivent être réunies pour qu’un logiciel soit considéré comme un dispositif médical.

1. Condition de la finalité: le logiciel doit être destiné par le fabricant à être utilisé chez l’homme à des fins, notamment, de diagnostic, de prévention, de contrôle, de traitement ou d’atténuation d’une maladie, ainsi que de diagnostic, de contrôle, de traitement, d’atténuation ou de compensation d’une blessure ou d’un handicap;

2. Condition de l’action produite: le logiciel doit produire un effet sur l’être humain, mais il importe peu que, pour être qualifiés de dispositif médical, le logiciel agisse directement ou non sur le corps humain, l’essentiel étant que sa finalité soit spécifiquement l’une de celles visées au chiffre 1.

Il est intéressant de relever que la CJUE précise que la condition de l’action produite  n’est pas déterminante. Au contraire, exiger que l’action produite ait un effet dans ou sur le corps humain pour qualifier un logiciel de dispositif médical, aurait pour effet que les logiciels n’ayant pas cet effet, mais étant destiné à des fins médicales par le fabricant ne seraient pas soumis à la réglementation sur les dispositifs médicaux, ce qui serait contraire à la volonté du législateur.

EXEMPLES SOUMIS OU NON A LA DIRECTIVE:

  • EST UN DM : un logiciel qui procède au recoupement des données propres du patient avec les médicaments que le médecin envisage de prescrire et est, ainsi, capable de lui fournir, de manière automatisée, une analyse visant à détecter, notamment, les éventuelles contre‑indications, interactions médicamenteuses et posologies excessives, est utilisé à des fins de prévention, de contrôle, de traitement ou d’atténuation d’une maladie et poursuit en conséquence une finalité spécifiquement médicale;
  • PAS UN DM : un logiciel qui, tout en ayant vocation à être utilisé dans un contexte médical, a pour finalité unique d’archiver, de collecter et de transmettre des données, comme un logiciel de stockage des données médicales du patient, un logiciel dont la fonction est limitée à indiquer au médecin traitant le nom du médicament générique associé à celui qu’il envisage de prescrire;
  • PAS UN DM : un logiciel destiné à faire état des contre-indications mentionnées par le fabricant de ce médicament dans sa notice d’utilisation;
  • PAS UN DM: un logiciel à usage général utilisé dans un environnement médical

Dans ce cas précis de logiciels d’aide à la prescription médicale, la CJUE précise encore qu’un tel logiciel “qui procède au recoupement des données propres du patient avec les médicaments que le médecin envisage de prescrire et est, ainsi, capable de lui fournir, de manière automatisée, une analyse visant à détecter, notamment, les éventuelles contre‑indications, interactions médicamenteuses et posologies excessives, est utilisé à des fins de prévention, de contrôle, de traitement ou d’atténuation d’une maladie et poursuit en conséquence une finalité spécifiquement médicale“.

__________________

CE QU’IL FAUT RETENIR

Trois grands principes sont à retenir de cet arrêt SNITEM et Philips c. Ministre des Affaires sociales et de la Santé du 7 décembre 2017:

  • Premièrement, la réglementation sur les dispositifs médicaux s’applique aux logiciels de santé pour les fonctionnalités qui répondent à deux conditions cumulatives que sont la finalité poursuivie, car destinées par le fabriquant à être utilisées comme telle et (2) l’action médicale produite par le logiciel;
  • Deuxièmement, seules les fonctionnalités du logiciel répondant à ces critères sont soumises aux règles sur les dispositifs médicaux, et non le code entier du logiciel;
  • Troisièmement, lorsque le marquage CE a été apposé, le logiciel peut librement circuler au sein de l’Union européenne [et donc en Suisse également] et peut être mis sur le marché sans nécessiter de certification supplémentaire.

__________________

Autres conséquences si un logiciel est un dispositif médical?

Si un logiciel est qualifié de DM, il devra respecter le devoir d’annonce pour les DM de classe I. Pour les DM à risque moyen à élevé (IIa, IIb et III) les obligations envers les autorités sanitaires (autorités nationales européenes ou Swissmedic en Suisse) sont plus strictes.

Suivant les conditions applicables, l’observation des produits (suivi des risques liés au dispositif durant tout son cycle de vie) et  la matériovigilence (notification des incidents graves survenus en Suisse ainsi que les mesures de précaution qui ont été prises) sera également nécessaire par le fabricant de logiciel, tout comme le respect d’exigences supplémentaires en matière de sécurité des produits et de contrôle de la qualité. Pour les produits provenant de l’UE, ceux-ci doivent avoir l’apposition du marquage CE, s’ils veulent bénéficier de la libre circulation et ne pas devoir demander d’autorisation de mise sur le marché.

L’ensemble des normes qui régit les DM établit les exigences nécessaires, selon le degré de risque du logiciel, pour autoriser leur mise sur le marché, cela afin de garantir la libre circulation de ces biens en tant que produits sûrs, garantissant la sécurité et la santé des patients. Cette réglementation européenne est applicable en Suisse, puisque la législation sanitaire (dont notamment la LPTh, ODim, OMéd et LRH) ainsi que Swissmedic s’y réfèrent expressément.

Pour aller plus loin:

__________________

Gabriel Avigdor | NTIC.ch