Le Forum des Dispositifs Médicaux
LAP à marquer CE ou pas ?
Citation de Benoit ROUSSEAU le 17 novembre 2022, 9 h 12 minBonjour,
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,
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
Citation de Martin Brochu le 18 novembre 2022, 9 h 39 minBonjour 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.
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.
Citation de Guillaume Promé le 23 novembre 2022, 15 h 08 min@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
@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
Citation de Benoit ROUSSEAU le 23 novembre 2022, 16 h 27 minMerci @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."
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."
Citation de Benoit ROUSSEAU le 23 novembre 2022, 17 h 10 minSuper 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).
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).
Citation de Guillaume Promé le 25 novembre 2022, 8 h 28 minamha, systèmes et nécessaires = DM physiques dans emballage commun ≠ briques logicielles dans un soft commun
amha, systèmes et nécessaires = DM physiques dans emballage commun ≠ briques logicielles dans un soft commun
Citation de Benoit ROUSSEAU le 25 novembre 2022, 11 h 22 minSi 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 ?
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 ?
Citation de Guillaume Promé le 28 novembre 2022, 9 h 56 minc'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
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