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