Le Forum des Dispositifs Médicaux
Certifier et classifier un progiciel très paramétrable
Citation de Benoit ROUSSEAU le 29 mars 2022, 16 h 50 minBonjour,
Je travaille sur un logiciel de gestion de dossier patient qui permet à un administrateur de site (type CH ou clinique) de paramétrer beaucoup de choses lui-même, sans que le fabricant ne soit informé.
Par exemple, l'administrateur peut lui même paramétrer un formulaire contenant ce type de données :
Champs de saisie : Poids, taille, âge
Champs de calcul : Dose insuline (Formule basée sur les 3 champs saisis)
Ceci est bien évidemment un exemple qu'un client peut paramétrer mais on peut imaginer que demain, un autre client ajoute des formules plus critiques d'un point de vue médical.
Avez-vous de l'expérience sur ce type de logiciel qui donne quasiment la même flexibilité qu'un fichier Excel avec des macro.. ? Comment faire pour rester dans un cadre certifiable avec une maitrise des risques et surtout d'assurer le suivi du B/R permanent, lorsque les bénéfices et risques sont à la main du client ?
Nous imaginions peut-être une solution en mettant en place un système de worflow qui permettrait au fabricant de recevoir chaque paramétrage client avant leur mise en production. Ainsi, le fabricant pourrait réaliser une analyse des risques, une validation, voir une révision de l'analyse B/R devant chaque paramétrage voulu par le client....
Merci par avance pour vos pistes éventuelles.
Bonjour,
Je travaille sur un logiciel de gestion de dossier patient qui permet à un administrateur de site (type CH ou clinique) de paramétrer beaucoup de choses lui-même, sans que le fabricant ne soit informé.
Par exemple, l'administrateur peut lui même paramétrer un formulaire contenant ce type de données :
Champs de saisie : Poids, taille, âge
Champs de calcul : Dose insuline (Formule basée sur les 3 champs saisis)
Ceci est bien évidemment un exemple qu'un client peut paramétrer mais on peut imaginer que demain, un autre client ajoute des formules plus critiques d'un point de vue médical.
Avez-vous de l'expérience sur ce type de logiciel qui donne quasiment la même flexibilité qu'un fichier Excel avec des macro.. ? Comment faire pour rester dans un cadre certifiable avec une maitrise des risques et surtout d'assurer le suivi du B/R permanent, lorsque les bénéfices et risques sont à la main du client ?
Nous imaginions peut-être une solution en mettant en place un système de worflow qui permettrait au fabricant de recevoir chaque paramétrage client avant leur mise en production. Ainsi, le fabricant pourrait réaliser une analyse des risques, une validation, voir une révision de l'analyse B/R devant chaque paramétrage voulu par le client....
Merci par avance pour vos pistes éventuelles.
Citation de Guillaume Promé le 30 mars 2022, 8 h 34 minLe cas est trop compliqué, vous n'allez pas pouvoir mettre à jour l'analyse du B/R à chaque utilisation, il faudrait l'aval de l'ON pour garder le CE.
Ce qui se fait: prévoir tous les cas d'utilisation, les brider au besoin, les spécifier, les implémenter, vérifier, valider, surveiller.
Le cas est trop compliqué, vous n'allez pas pouvoir mettre à jour l'analyse du B/R à chaque utilisation, il faudrait l'aval de l'ON pour garder le CE.
Ce qui se fait: prévoir tous les cas d'utilisation, les brider au besoin, les spécifier, les implémenter, vérifier, valider, surveiller.
Citation de Benoit ROUSSEAU le 30 mars 2022, 8 h 55 minOk, je vois. Dans ce cas, pourrait-on selon vous envisager de faire un état des lieux de toutes les situations actuelles chez les clients afin de spécifier, vérifier, valider et surveiller l'ensemble des fonctions assurées par le logiciel hérité (implémenter n'a pas de sens puisque ça fonctionne déjà avec du paramétrage).
A partir de cet état des lieux, mettre à jour la DT, analyse des risques, rapport B/R, etc... jusqu'au marquage CE.
Puis, pour chaque nouveau paramétrage demandé par un client, les traiter comme des demandes de modifications du logiciel en reprenant le cycle habituel (spec, vérif, valid, surveillance).
Avec, comme pour chaque modif classique de logiciel, une analyse des risques faite par le RAQA qui évalue la nécessite de demander l'accord de l'ON au préalable (si modif substantielle).
Ok, je vois. Dans ce cas, pourrait-on selon vous envisager de faire un état des lieux de toutes les situations actuelles chez les clients afin de spécifier, vérifier, valider et surveiller l'ensemble des fonctions assurées par le logiciel hérité (implémenter n'a pas de sens puisque ça fonctionne déjà avec du paramétrage).
A partir de cet état des lieux, mettre à jour la DT, analyse des risques, rapport B/R, etc... jusqu'au marquage CE.
Puis, pour chaque nouveau paramétrage demandé par un client, les traiter comme des demandes de modifications du logiciel en reprenant le cycle habituel (spec, vérif, valid, surveillance).
Avec, comme pour chaque modif classique de logiciel, une analyse des risques faite par le RAQA qui évalue la nécessite de demander l'accord de l'ON au préalable (si modif substantielle).
Citation de Guillaume Promé le 30 mars 2022, 9 h 12 minC'est, à mon sens, la bonne approche 👍
C'est, à mon sens, la bonne approche 👍
Citation de Benoit ROUSSEAU le 3 janvier 2023, 16 h 00 minBonjour,
Je me permets de rouvrir cette conversation car je viens d'avoir un éditeur de logiciel qui n'arrive pas être DM et qui aimerait l'être (et oui, ça existe lol).
Il s'agit d'un Middleware qui réalise des traitements de résultats de laboratoires entre les plateformes de matériels d'analyses médicales (eux-mêmes certifiés DMDIV) et les Système d'Information de laboratoire (SIL) qui ne sont pas DM selon l'ANSM.
La plus part des fonctions du logiciel ne sont pas DM car uniquement stockage, communication, affichage, etc...
En revanche, un des modules est un éditeur de règles permettant à l'utilisateur final (un administrateur du client) d'indiquer par exemple si résultat ECBU < 10000 alors mettre dans le champs ECBU = NEGATIF.
Selon l'ANSM, ce module ne peut être considéré comme un DM car l'éditeur fourni / livre un logiciel à vide et c'est l'utilisateur qui défini ses propres règles.
Est-ce que cela vous parle ?
On peut en effet se demander dans ce cas comment revendiquer des risques et bénéfices clinques quand ceux-ci sont définis par les clients eux-mêmes. C'est un peu comme si on livrait Excel et que le client écrivait lui-même ses macros de calculs médicales.
Peut-on considérer que la responsabilité est déportée sur le client (l'hôpital, la clinique ou le laboratoire dans mon cas) lorsque les règles médicales sont gérées, implémentées et validées par eux ?
Bonjour,
Je me permets de rouvrir cette conversation car je viens d'avoir un éditeur de logiciel qui n'arrive pas être DM et qui aimerait l'être (et oui, ça existe lol).
Il s'agit d'un Middleware qui réalise des traitements de résultats de laboratoires entre les plateformes de matériels d'analyses médicales (eux-mêmes certifiés DMDIV) et les Système d'Information de laboratoire (SIL) qui ne sont pas DM selon l'ANSM.
La plus part des fonctions du logiciel ne sont pas DM car uniquement stockage, communication, affichage, etc...
En revanche, un des modules est un éditeur de règles permettant à l'utilisateur final (un administrateur du client) d'indiquer par exemple si résultat ECBU < 10000 alors mettre dans le champs ECBU = NEGATIF.
Selon l'ANSM, ce module ne peut être considéré comme un DM car l'éditeur fourni / livre un logiciel à vide et c'est l'utilisateur qui défini ses propres règles.
Est-ce que cela vous parle ?
On peut en effet se demander dans ce cas comment revendiquer des risques et bénéfices clinques quand ceux-ci sont définis par les clients eux-mêmes. C'est un peu comme si on livrait Excel et que le client écrivait lui-même ses macros de calculs médicales.
Peut-on considérer que la responsabilité est déportée sur le client (l'hôpital, la clinique ou le laboratoire dans mon cas) lorsque les règles médicales sont gérées, implémentées et validées par eux ?
Citation de Guillaume Promé le 4 janvier 2023, 10 h 52 minBonjour @benoit-rousseau et meilleurs vœux.
Si le logiciel laisse toute liberté à l'utilisateur (pas de valeurs prédéfinies, pas de contrôle des saisies) alors c'est en effet à considérer comme une calculatrice non-médicale. Pour tomber dans le DM il faut "précharger" des formules avec une finalité médicale.
Tout comme avec Excel, la responsabilité est alors côté utilisateur, qui - selon le RDM et la v2 des cas borderlines - devient fabricant de DM (il faut donc expliquer aux médecins qu'une étude clinique est nécessaire avant d'utiliser un tableur dans le cadre de leur métier 😅)
Bonjour @benoit-rousseau et meilleurs vœux.
Si le logiciel laisse toute liberté à l'utilisateur (pas de valeurs prédéfinies, pas de contrôle des saisies) alors c'est en effet à considérer comme une calculatrice non-médicale. Pour tomber dans le DM il faut "précharger" des formules avec une finalité médicale.
Tout comme avec Excel, la responsabilité est alors côté utilisateur, qui - selon le RDM et la v2 des cas borderlines - devient fabricant de DM (il faut donc expliquer aux médecins qu'une étude clinique est nécessaire avant d'utiliser un tableur dans le cadre de leur métier 😅)
Citation de Benoit ROUSSEAU le 4 janvier 2023, 11 h 39 minMerci @guillaume pour votre réponse !
Et si on va plus loin et que le client (médecin ou hôpital) délègue le paramétrage au fabricant en lui indiquant je veux que vous me paramétriez mon logiciel comme si, comme ça.
Dans mon précédent exemple, le client demande au fabricant de lui paramétrer la formule : Si ECBU < 10000, alors mettre ECBU = NEGATIF.
Est-ce que vous pensez qu'on reste dans une responsabilité reportée sur le client, qui devient fabricant de DM dans ce cas, en effet ;-)
Merci @guillaume pour votre réponse !
Et si on va plus loin et que le client (médecin ou hôpital) délègue le paramétrage au fabricant en lui indiquant je veux que vous me paramétriez mon logiciel comme si, comme ça.
Dans mon précédent exemple, le client demande au fabricant de lui paramétrer la formule : Si ECBU < 10000, alors mettre ECBU = NEGATIF.
Est-ce que vous pensez qu'on reste dans une responsabilité reportée sur le client, qui devient fabricant de DM dans ce cas, en effet ;-)
Citation de Guillaume Promé le 4 janvier 2023, 13 h 23 minSi le soft implémente un calcul médical, alors c'est un DM. Il est sous la responsabilité du fabricant, il n'y a pas de report possible (comme avec certains instruments de chirurgie et implants : le médecin fait le cahier des charges, mais cela ne suffit pas pour démontrer la conformité)
Si le soft implémente un calcul médical, alors c'est un DM. Il est sous la responsabilité du fabricant, il n'y a pas de report possible (comme avec certains instruments de chirurgie et implants : le médecin fait le cahier des charges, mais cela ne suffit pas pour démontrer la conformité)
Citation de Benoit ROUSSEAU le 4 janvier 2023, 16 h 30 minEn fait, le soft n'inclus par de calcul médical par défaut. Il possède uniquement d'un moteur de règles qui est capable d'affecter à une variable X un nom et de réaliser un test dessus.
Le client demande ensuite au fabricant : je veux une règle avec X = Quel temps fait-il ? si la réponse est X = "Il fait beau" Alors envoi un message "Très bonne nouvelle".
Et je veux une autre règle avec X = Niveau de douleur - Quel est votre niveau de douleur de 1 à 4 ? Si X = 4, envoi un message "Je crois qu'il a mal là.".
Comme l'interface d'administration est un peu technique, c'est le fabricant qui paramètre les règles fournies par le client.
Est-ce que dans ce cas, la responsabilité est au client qui devient fabricant de DM, comme le cas d'une calculatrice ?
Dans quel article ou Annexe du règlement ou v2 du borderline guide peut-on trouver des infos sur la responsabilité de l'utilisateur final ?
Merci pour votre retour d'expérience !
En fait, le soft n'inclus par de calcul médical par défaut. Il possède uniquement d'un moteur de règles qui est capable d'affecter à une variable X un nom et de réaliser un test dessus.
Le client demande ensuite au fabricant : je veux une règle avec X = Quel temps fait-il ? si la réponse est X = "Il fait beau" Alors envoi un message "Très bonne nouvelle".
Et je veux une autre règle avec X = Niveau de douleur - Quel est votre niveau de douleur de 1 à 4 ? Si X = 4, envoi un message "Je crois qu'il a mal là.".
Comme l'interface d'administration est un peu technique, c'est le fabricant qui paramètre les règles fournies par le client.
Est-ce que dans ce cas, la responsabilité est au client qui devient fabricant de DM, comme le cas d'une calculatrice ?
Dans quel article ou Annexe du règlement ou v2 du borderline guide peut-on trouver des infos sur la responsabilité de l'utilisateur final ?
Merci pour votre retour d'expérience !
Citation de Guillaume Promé le 4 janvier 2023, 16 h 58 minRien de précis sur la responsabilité de l'utilisateur, on considère qu'il fait toujours tout très bien, sauf si le fabricant a mal géré l'aptitude à l'utilisation.
Le RDM définit les notions de DM et de fabricant (qui est toujours le responsable légal); le guide sur les cas borderline enfonce le clou pour les calculatrices médicales.
La fonction donnée en exemple ressemble plus à un transfert d'information qu'à un calcul médical
Rien de précis sur la responsabilité de l'utilisateur, on considère qu'il fait toujours tout très bien, sauf si le fabricant a mal géré l'aptitude à l'utilisation.
Le RDM définit les notions de DM et de fabricant (qui est toujours le responsable légal); le guide sur les cas borderline enfonce le clou pour les calculatrices médicales.
La fonction donnée en exemple ressemble plus à un transfert d'information qu'à un calcul médical