Le Forum des Dispositifs Médicaux

Veuillez pour créer des messages et des sujets de discussion.

LAP à marquer CE ou pas ?

Bonjour,

Je relance ce sujet qui continuent, comme depuis de nombreuses années, à rester dans un flou règlementaire. Je parle bien sûr de nos amis éditeurs de LAP : Logiciel d'Aide à la Prescription.

D'après la CJUE et tout le monde, un LAP est bien considéré comme un DM car il intègre des fonctions de contrôles des interactions médicamenteuses entre les produits prescrits et l'état physiologique d'un patient individuel (ex: doliprane selon l'allergie du patient..). En fonction du résultat de l'analyse, des alertes sont affichées au professionnel de santé.

Jusque là, pas de soucis, ils sont DM. En revanche, voici là où ça se complique.

Ces éditeurs de LAP intègrent pour réaliser ces fonctions d'analyses et d'alertes une API fournie par les créateurs des base de données de médicaments (Vidal ou BCB pour ne citer qu'eux).

Ces API réalisent toutes ces fonctions d'analyses de données et renvoie un fichier HTML tout prêt avec le résultat de ces analyses ainsi que les alertes à afficher.

Ces API vont être marquées CE.

La question est donc, est-ce que le LAP qui intègrent ces API doit également être marqué CE ?

Sachant que si l'on applique le MDCG 2019-11 sur les modules, on peut considérer que le module qui assurent les fonctions DM est bien séparé (puisque contenu dans cette fameuse API).

Dans le LAP, il ne reste plus que des fonctions de stockage de données patient, de transfert de ces données à l'API et d'affichage des données (ou cosmétiques si on reprend les termes des guides ;-).

Nous sommes dans des cas assez borderline donc je suis preneur de votre avis ou retour d'expérience sur le sujet ..

Merci par avance !

Benoit

 

 

 

 

 

Bonjour Benoit,

comme vous l'avez dit nous sommes dans un cas non encore bien défini par la réglementation, je vous partage donc comment je le traiterais s'il se présentait à moi.

j'utiliserai l'article 22 sur les systèmes et nécessaires:

l'API est maqué CE et incluse dans un système de logiciel, les autres briques logiciels sont conformes à la législation qui leurs sont applicables, et leur présence est justifiée pour faciliter la gestion des données par le médecin et la sauvegarde de l'historique du patient.

Par contre vos autres logiciels ne portant pas de marquage CE, vous allez être dans le cas de l'alinea 4 de l'article 22, et votre système est considéré comme un dispositif à part entière et doit faire l'objet de la procédure d'évaluation de la conformité applicable.

Si vos autres briques logiciels sont toutes marqués CE, vous avez juste une déclaration dans laquelle vous déclarez:

  • avoir vérifié la compatibilité réciproque des dispositifs, conformément aux instructions des fabricants
  • avoir conditionné le système ou le nécessaire et fourni les informations utiles aux utilisateurs, comprenant les informations à fournir par les fabricants des différents dispositifs ou des autres produits qui ont été assemblés.
  • avoir soumis l'association des dispositifs et, le cas échéant, des autres produits sous la forme d'un système ou d'un nécessaire à des méthodes de contrôle, de vérification et de validation appropriées.

@benoit-rousseau cela m'étonne que l'on puisse certifier une API en tant que DM, prise toute seule elle ne sert à rien

Dans le monde du hardware : des composants peuvent avoir un "grade medical" : ils ont respecté toutes les normes applicables, passé les bons tests en labo et la documentation technique a été produite. Mais c'est le fabricant, celui qui intègre les composants dans le produit final, qui porte le marquage CE.

Cela devrait être la même chose pour un logiciel

Merci @m-brochu et @guillaume pour vos réponses.

En fait, pour bien comprendre la situation, dans certains LAP, une seule fonction les font tomber dans la catégorie des DM.

Et cette fonction, comme vous l'imaginez est incluses dans l'API développée et en cours de marquage par le sous traitant.

Je pensais un peu comme Guillaume, comment est-il possible de faire certifier une API seule, en particulier si cette dernière ne se charge pas de la partie affichage des résultats (bref, toute l'IAU). On peut le comprendre afin "d'alléger" ou d'essayer de déporter tout une partie du dossier technique sur le sous traitant avec des contrats cadres signés entre le fabricant de LAP et le sous traitant, fabricant de l'API.

Mais certains jouent un peu sur la règlementation et en particulier, sur la notion de modules décrite dans le MDCG 2019-11 (page 17). qui peuvent être traités séparément (ségrégation justifiée bien évidemment) : ceux concernés par le DM et ceux qui ne le sont pas.

Ainsi, certains éditeurs de LAP décrive leur architecture en indiquant que ce module (API) contient leur unique fonction DM.
Tous les autres modules n'étant pas concernés par le RDM (archivage, stockage ou recherche de données uniquement), ils n'ont pas à ce titre
à se faire certifier.

Selon moi, nous sommes dans le cas d'un logiciel qui influence l'utilisation d'un DM (l'API) et donc de ce fait, le logiciel intégrant cette API est considéré comme un DM de même classe : cf. Chapitre II, §3.3 du RDM :

"Le logiciel commandant un dispositif ou agissant sur son utilisation relève de la même classe que le dispositif."

Super intéressant @m-brochu l'article 22 ! J'ai justement un client qui commercialise des bornes de téléconsultation dans laquelle il intègre différents DM matériels marqués CE. Je te rejoins que ça concerne également les LAP ;-)

Est-ce que vous avez des guideslines, templates ou autres aides sur cette déclaration à faire ? C'est ce qu'on appelle les procedures packs (nécessaires en Français).

 

 

amha, systèmes et nécessaires = DM physiques dans emballage commun ≠ briques logicielles dans un soft commun

Si je comprends @guillaume, on ne peut pas utiliser l'article 22 (systèmes et nécessaires) pour un logiciel qui intègre des briques logicielles ?

Uniquement sur du matériel qui intègre d'autres DM physiques ?

c'est pensé pour les kits utilisés au bloc, pas pour les logiciels, même s'ils ne sont pas exclus

cela pourrait marcher si l'on met sur le marché un "kit de logiciels" DM indépendants et marqués CE, cela ne sembla pas être votre cas

Bonjour,

Je rebondis sur ce message qui a maintenant quelques mois (années).
@benoit-rousseau avez-vous eu entre temps plus de précision ou des éléments de réponses permettant de répondre à votre question ?
Doit-on toujours considérer que l'article 22 ne s'applique pas à l'assemblage de logiciel ? cc @m-brochu @guillaume

Quid dans le cas d'une stratégie de commercialisation d'une API (marquée CE) à un client. Le client développant l'interface. Le client est distributeur ? Le client devient fabricant ?
Je me demande comment l'IAU est validée sur un marquage d'une API seule sans interface (proto, maquette ?) + exigence à détailler lors de l'intégration ?

Merci :)

Bonjour @remirb,

Je n'ai pas eu l'occasion d'avoir de confirmation sur le fait que l'article 22 ne s'appliquait pas à de l'assemblage logiciel mais les situations que j'ai rencontrées confirme bien celà.

En revanche, l'article 22 s'applique si vous avez un système matériel complet (ex: une borne) qui intègre plusieurs DM matériels (stéthoscopes, etc..) + des logiciels (DM ou non).

Je suis également en recherche d'information pour le marquage CE d'une API seule sans IHM, en particulier pour l'IAU. @guillaume, si vous avez déjà rencontré ce cas, je suis également preneur...

Je sais que l'IAU fera l'objet de l'évaluation de l'intégration de l'API chez un éditeur tiers (ou chez le même éventuellement).

Ensuite, je pense qu'il faut dans tous les cas réaliser l'IAU sur une interface de simulation ou de test pour afficher à minima les informations retournées par l'API et faire valider leur compréhension / interprétation par des utilisateurs finaux en évaluation sommative.

 

 

Merci de votre réponse

Je vais avoir prochainement des éléments de réponse sur des marquages d'API sans interface. À l'occasion si vous voulez nous pourrions en discuter quelques minutes @benoit-rousseau

Bonjour Rémi,

Merci pour votre proposition d'échanger sur le sujet ! Je suis toujours intéressé pour partager sur nos expériences respectives.

N'hésitez pas à me contacter via LinkedIn @remirb :

https://www.linkedin.com/in/ailane

Cordialement,

Benoît

 

 

 

Hello,

à priori une API seule ne peut pas avoir de CE médical, pas plus qu'un écrou ou un moteur pas à pas

Par contre, le développeur peut épouser les standards médicaux pour faciliter le dossier technique du DM qui l'intégrera.

L'API possède-t-elle une interface utilisateur (du DM) ? Si oui, il est nécessaire de faire de l'IAU, sinon je ne vois pas quoi éprouver 🤔

Selon mon expérience@guillaume tout code source ayant une indication d'utilisation peut être marqué CE (à part une base de données seule) en appliquant le MDCG 2019-11.

La comparaison avec les DM matériels n'est pas très souvent approprié hélas. Pour le soft, il faut faire preuve d'imagination pour adapter la réglementation DM souvent inadaptée à ce type de produits (je parle des SaMD bien sûr).

D'ailleurs, pour rester dans le sujet de cette conversation, l'API Vidal est déjà marquée CE.

Pour l'IAU, il ne faut pas oublier les éléments en dehors des interfaces utilisateurs. Entre autres, il faut prendre en considération les autres etapes du cycle de vie du logiciel (installation, intégration, etc..). Chaque étape peut contenir des éléments alimentant l'IAU tel que l'intégration de l'API ou la compréhension des manuels utilisateurs, en particulier pour valider les mesures de maîtrise des risques liés à l'IAU.