Le Forum des Dispositifs Médicaux
Guidance FDA: Off-the-Shelf Software Use in Medical Devices
Citation de Martin Brochu le 19 février 2020, 17 h 01 minBonjour à tous,
je suis à la recherche d'information sur la mise en application du guidance FDA en titre de ce sujet.
Comment avez vous mis en place les requis FDA sur ce sujet, dans le cadre de la préparation d'un dossier américain je nages un peu sur le niveau de granularité que l'on doit mettre en place à ce propos et est ce que cela s'applique à tous les logiciels non DM intégrés à un dispositif medical?
Bonjour à tous,
je suis à la recherche d'information sur la mise en application du guidance FDA en titre de ce sujet.
Comment avez vous mis en place les requis FDA sur ce sujet, dans le cadre de la préparation d'un dossier américain je nages un peu sur le niveau de granularité que l'on doit mettre en place à ce propos et est ce que cela s'applique à tous les logiciels non DM intégrés à un dispositif medical?
Fichiers téléversés :- Vous devez vous connecter pour avoir accès aux fichiers mis en ligne (uploadés).
Citation de Guillaume Promé le 20 février 2020, 10 h 11 minBonjour Martin,
mettre en place les requis FDA
je n'ai pas l'expérience, @mitch : au secours
est ce que cela s'applique à tous les logiciels non DM intégrés à un dispositif medical ?
oui, au moins en phase d'identification, puis le boulot est proportionnel aux risques associés
Bonjour Martin,
mettre en place les requis FDA
je n'ai pas l'expérience, @mitch : au secours
est ce que cela s'applique à tous les logiciels non DM intégrés à un dispositif medical ?
oui, au moins en phase d'identification, puis le boulot est proportionnel aux risques associés
Citation de Martin Brochu le 20 février 2020, 11 h 33 minCitation de Guillaume Promé le 20 février 2020, 10 h 11 minest ce que cela s'applique à tous les logiciels non DM intégrés à un dispositif medical ?
oui, au moins en phase d'identification, puis le boulot est proportionnel aux risques associés
c'est ce que j'ai compris du Guidance,
mais quand le dispositif est installé sur un ordinateur équipé windows 10 cela sous entend de faire l'analyse sur windows 10 ainsi que les drivers des composants du PC.
là ou je m'inquiète c'est devons nous faire une analyse de tous les sous composants de windows (paint, windows courrier etc...) ou juste windows 10 considéré dans son ensemble étant donné que les programmes founris avec Windows 10 n'ont pas d'action dans le fonctionnement du dispositif et n'ont pas a être lancé pour faire fonctionner le logiciel DM.
ma question pour être plus formelle est doit on faire l'analyse de tous les programmes installé sur l'appareil d'origine ou juste sur les programmes servant au fonctionnement du logiciel en tant que DM.
Citation de Guillaume Promé le 20 février 2020, 10 h 11 minest ce que cela s'applique à tous les logiciels non DM intégrés à un dispositif medical ?
oui, au moins en phase d'identification, puis le boulot est proportionnel aux risques associés
c'est ce que j'ai compris du Guidance,
mais quand le dispositif est installé sur un ordinateur équipé windows 10 cela sous entend de faire l'analyse sur windows 10 ainsi que les drivers des composants du PC.
là ou je m'inquiète c'est devons nous faire une analyse de tous les sous composants de windows (paint, windows courrier etc...) ou juste windows 10 considéré dans son ensemble étant donné que les programmes founris avec Windows 10 n'ont pas d'action dans le fonctionnement du dispositif et n'ont pas a être lancé pour faire fonctionner le logiciel DM.
ma question pour être plus formelle est doit on faire l'analyse de tous les programmes installé sur l'appareil d'origine ou juste sur les programmes servant au fonctionnement du logiciel en tant que DM.
Citation de Guillaume Promé le 20 février 2020, 11 h 58 minL'ordinateur n'est pas un DM, le cas échéant : il faut prendre en compte les composants qui impactent les performances du logiciel DM (donc à priori : pas Paint)
l'OS est validé pendant la validation du développement, il faut ensuite valider ses mises à jour
Attention au cas particulier où vous fournissez l'ordi : vous êtes maître des logiciels et des drivers installés, mais généralement on fait cela pour maîtriser des risques : l'analyse des risques vous dit quels composants sont à maîtriser
mais je dis ça avec mon regard d'européen, la FDA a parfois des mœurs étranges 😅
L'ordinateur n'est pas un DM, le cas échéant : il faut prendre en compte les composants qui impactent les performances du logiciel DM (donc à priori : pas Paint)
l'OS est validé pendant la validation du développement, il faut ensuite valider ses mises à jour
Attention au cas particulier où vous fournissez l'ordi : vous êtes maître des logiciels et des drivers installés, mais généralement on fait cela pour maîtriser des risques : l'analyse des risques vous dit quels composants sont à maîtriser
mais je dis ça avec mon regard d'européen, la FDA a parfois des mœurs étranges 😅
Citation de Mohammed TAZER le 11 mars 2020, 16 h 13 minPour avoir traiter de ce genre de situations, l'idée est de prouver que toutes les fonctionnalités de l'OS et autres librairies cachées sont vérifiée et validées lors de la phase varif/valid du dispositif. La quantité de travail sera dimensionnée par leur impact sur les événements menant à un risque identifié. Généralement les lib seront traitées comme SOUP au sens de la 62304 ou COTS au sens de la FDA. La seconde étape, sera le suivi et l’évaluation des mises à jour et leur impact sur le DM.
Pour avoir traiter de ce genre de situations, l'idée est de prouver que toutes les fonctionnalités de l'OS et autres librairies cachées sont vérifiée et validées lors de la phase varif/valid du dispositif. La quantité de travail sera dimensionnée par leur impact sur les événements menant à un risque identifié. Généralement les lib seront traitées comme SOUP au sens de la 62304 ou COTS au sens de la FDA. La seconde étape, sera le suivi et l’évaluation des mises à jour et leur impact sur le DM.