Le Forum des Dispositifs Médicaux

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

Exemple de Demande De Modification

Bonjour,

Dans le cas d'un SaMD en maintenance, auriez-vous des exemples de DDM qui ne feraient pas 20 pages ?

D'ailleurs, pouvez-vous m'indiquer quel est le niveau de détail / le nombre d'information attendu dans le cadre du marquage CE (ISO 13485) ?

Les éditeurs gèrent pour la plus part leurs demandes d'évolutions / corrections (NC) dans un ticket management system. J'imagine qu'il est également possible d'utiliser ce type d'outils pour gérer les DDM plutôt qu'un bon vieux Word à convertir en PDF avant signature, le tout pour chaque modification du logiciel ! ! Avec ça, le patient va pouvoir attendre longtemps avant d'avoir sa release, pas de souci ;-)

Bonjour,

Pour les demandes de modification relative au SaMD, en effet vous n'êtes pas obligé d'avoir 20 pages, il suffit de définir les bonnes questions à se poser.

Ces questions doivent permettre à vos équipes d'évaluer l'impact de la modification à tous les niveaux (fonctionnel, clinique, réglementaire, risk....). En gros vous devez présenter cela comme un change control produit.

Vous pouvez gérer votre DDM dans votre outils de ticketing mais faites bien attention d'avoir tous les informations et le worflow d'approbation nécessaire (description de la DDM, analyse de l'impact, autorisation ou non, (priorité), date ou version prévisionnelle de changement).

Souvent, les DDM sont collectées puis mise en stand by jusqu'à la prochaine version. Le développement de cette nouvelle version est généralement lancée soit pour la mise en place de nouveautés, soit suite à un problème important à corriger. D'autres préfèrent faire ceci régulièrement (par ex. tous les ans) ainsi toutes les données sont collectées pendant une période donnée.

Merci pour votre réponse. Très claire !

Dans notre change control, on indique que toutes les DDM doivent être approuvées avant la libération donc on va le faire régulièrement ;-)

En revanche, nous sommes d'accord, pas besoin de DDM pour un simple bug fix ? Uniquement les demandes d'évolutions ou correction de bug qui demande de grosses modifs ?

Selon l'IEC 62304, toute remonté terrain doit faire l'objet d'un rapport de problème:

Chaque RAPPORT DE PROBLÈME doit être évalué afin de déterminer la manière dont il affecte la SÉCURITÉ d’un PRODUIT LOGICIEL diffusé et si une modification du PRODUIT LOGICIEL diffusé est nécessaire pour traiter le problème. [Classes A, B, C]

Puis § 9.2 Etude du problème il est écrit:

d) déclencher la ou les DEMANDES DE MODIFICATION nécessaires pour corriger le problème, ou justifier le fait de n’entreprendre aucune action.

Ce qui implique de faire un DDM, mais votre DDM peut être très simple.

Prenons l'exemple d'une faute d'orthographe détectée => Aucun impact sur la sécurité mais vous allez devoir faire une modification quand même (ou pas selon votre décision car ce qui ne touche pas à la sécurité ne doit pas forcement être modifié).

Vous pouvez alors décrire un process très simple de DDM si pas d'impact sur la sécurité.

  1. Demande de modification sans impact sur la sécurité
  2. Proposition de la resolution
  3. Approbation de la resolution par une personne responsable
  4. Mis en application de la resolution
  5. Test (ici un simple screen shot peut suffir)
  6. Cloture du problème

 

Bonjour,

Je me permets de rebondir sur votre conversation, car je me pose des questions similaires sur la gestion des modifications d'un logiciel SaMD en cours de certification sous MDR. Pour éviter de faire des change control à chaque évolution de versions (très fréquent), pouvons nous considérer qu'une version sortie pour un (ou plusieurs) bugfix(s) (lorsque seul le 3ème chiffre évolue dans le versionning type V.4.1.2) ne nécessite pas de demande et analyse de modification. Un tel changement, par nature, n'impactant pas les performances, la sécurité, les fonctionnalités du logiciel. Est-ce entendable selon vous, ou faut-il tracer une analyse pour chaque bugfix -  qu'ils soient découverts en interne intra-dev ou en externe ?

Merci par avance pour votre aide  !

 

Bonjour @louisep,

Comme indiqué dans les messages précédents, vous n'êtes pas obligé de faire une demande de changement "complète" avec toutes les questions qui vont bien pour chaque bug fix.

Ce que je préconise habituellement, c'est d'avoir un process de résolution des problèmes assez light mais qui contient tout de même les étapes de base : Analyse des causes, évaluation criticité, approbation, vérif & valid, clôture. Ce qui permet d'être conforme à l'IEC 62304.

Ensuite, selon la criticité détectée dans ce process (donc cela peut-être un bug détecté en interne intra-dev ou externe), on déclenche le process de gestion des modifs classique avec toute la panoplie de questions fournit dans tous les guides existants dans le domaine (en privilégiant bien évidemment celui de votre ON préféré).

 

Merci pour votre réponse !

Ok cela me semble déjà plus réalisable :  avec cette idée d'analyse "macro" tracée pour chaque version (même les bugfix) suivie, si seulement il s'agit d'une modif. critique, d'une analyse plus poussée comportant l'ensemble des questions de gestion des changements (impact sur le SMQ? sur le DM? modification substantielle/significative ? etc...)

Idéalement il faudrait pouvoir tracer cette 1ère analyse dans notre outils de développement qui trace déjà l'ensemble des développements réalisés sur le logiciel et leur versioning. Est-ce que vous avez l'habitude de réaliser cette gestion des problèmes/modifications directement sur votre outils de développement, ou il vaut mieux le faire à part ?

Oui bien sûr, gérez cette résolution de bugs directement dans votre outils (Jira, Azure ou tout autre outil de ticket, c'est l'idéal).

Ensuite, il vous reste à décrire ce process dans votre procédure de conception et développement.