Logiciel en tant que dispositif médical (SaMD)

Republié par Platon

Suiveurs: 0

posté par Rob Packard on Le 1 juin 2021

Pouvez-vous combiner le cycle de vie du développement logiciel avec des contrôles de conception lorsque vous développez un logiciel en tant que dispositif médical (SaMD) ?

[Contenu intégré]

N'oubliez pas de vous abonner à notre chaine YouTube pour davantage de formation sur la qualité des dispositifs médicaux et la réglementation. Il y a eu une augmentation remarquable du nombre de dispositifs médicaux développés ces dernières années et constitués uniquement de logiciels. L'industrie des dispositifs médicaux qualifie ces produits de logiciel en tant que dispositif médical (SaMD). Parallèlement à l'augmentation du nombre de SaMD sur le marché, on a également constaté une augmentation du nombre d'entreprises qui développent ces SaMD sans aucune expérience préalable dans l'industrie des dispositifs médicaux. Medical Device Academy est spécialisée dans l’aide aux start-ups de dispositifs médicaux, et nous constatons des caractéristiques communes partagées par ces start-ups MedTech. Premièrement, ils réussissent généralement à démontrer la preuve de concept de leur logiciel en quelques mois. Deuxièmement, l'équipe de développement est généralement virtuelle (c'est-à-dire que tout le monde vit dans un État différent, voire dans des pays différents). Troisièmement, l’équipe de développement ne comprend aucune personne ayant une responsabilité en matière de qualité ou de réglementation. Quatrièmement, l’entreprise n’a pas mis en œuvre de contrôles de conception logicielle ni lancé de fichier historique de conception (DHF). Cinquièmement, l'entreprise n'est même pas au courant de l'existence de IEC 62304 (moins cher que d'autres sites) – la norme internationale qui définit les exigences du cycle de vie des logiciels de dispositifs médicaux.

La situation ci-dessus est assez courante, mais ne constitue pas un problème grave. Ces start-ups Medtech ont simplement besoin de conseils sur la manière de se conformer aux réglementations relatives aux dispositifs médicaux sans créer un système qualité trop lourd et une documentation excessive. Dans le même temps, ces entreprises doivent rester petites, agiles et économes. La plupart des gens pensent que le processus de documentation du système qualité et du logiciel ralentit le processus de développement, mais l'intention est d'éviter les erreurs et de vous aider à planifier la conception et le développement de votre SaMD afin que le logiciel résultant soit sûr et fonctionne comme vous le souhaitez (c'est-à-dire efficace). Afin de créer un système qualité et un processus de documentation logicielle simples et efficaces, vous devez éviter certains pièges courants.

Quand faut-il mettre en œuvre un système qualité pour les logiciels en tant que dispositifs médicaux (SaMD) ?

Le moment où un système qualité est requis dépend du marché sur lequel vous lancez votre produit en premier. Si vous lancez votre produit au Canada, vous avez besoin d'un type spécial de certificat de système qualité avant de pouvoir demander un Licence canadienne pour les instruments médicaux (c'est-à-dire le certificat MDSAP pour ISO 13485:2016). MDSAP signifie « programme d'audit unique pour les dispositifs médicaux » et il n'y a que organisations 16 qui peut délivrer ce type de certificat. Si vous lancez votre produit en Europe, vous passerez par votre certification de système qualité ISO 13485 en parallèle avec l'obtention de la certification CE de votre SaMD. Si vous lancez votre produit aux États-Unis, vous n'avez pas besoin que votre système qualité soit complet avant d'avoir obtenu l'autorisation 510(k) et d'être prêt à vous enregistrer et à vous inscrire auprès de la FDA. Vous n’avez pas non plus besoin de certification ISO pour le marché américain. Si votre SaMD est un appareil de classe 1 sur l’un de ces trois marchés, vous pourriez avoir moins d’exigences en matière de système qualité et de réglementation.

Quel que soit le marché sur lequel vous envisagez de lancer votre produit, vous ne devez pas investir dans un système qualité complet pour ensuite développer votre SaMD. Vous devez soit développer les deux en parallèle, soit développer d'abord votre SaMD. Les seuls processus qu'il est vraiment important de mettre en œuvre au début du développement d'un produit sont 1) les contrôles de conception, 2) le développement de logiciels, 3) la gestion des risques et 4) l'ingénierie d'utilisabilité ou les tests de facteurs humains. Vous pouvez attendre de mettre en œuvre plus de 20 autres procédures jusqu'à ce que vous entriez dans la phase de transfert de conception de votre projet de conception et de développement.

Avez-vous besoin de procédures distinctes pour les contrôles de conception, le contrôle des modifications et le développement de logiciels ?

Si vous développez un système complexe comprenant du matériel et des logiciels, vous devriez probablement disposer de trois procédures distinctes. La raison en est qu’il existe différents systèmes de qualité et exigences réglementaires en matière de modifications apportées au matériel et aux logiciels. Si vous développez uniquement SaMD, vous pouvez facilement combiner ces trois processus en une seule procédure. La vidéo au début de ce blog décrit comment combiner ces trois éléments en une seule procédure, mais ce qui suit décrit la documentation logicielle qui doit être couverte à chaque étape de votre processus de conception :

Phase 1 – La planification de la conception nécessite l'identification de la classification des risques logiciels (c'est-à-dire A, B ou C) conformément à la norme CEI 62304, ainsi que le niveau de préoccupation (LoC) de votre logiciel conformément à la norme CEI XNUMX. Directives de la FDA pour la documentation des logiciels. Quelle que soit la LoC de votre SaMD, vous devrez toujours développer la documentation requise pour la classification des risques dans la norme CEI 62304, même si la FDA ne souhaite pas examiner toute cette documentation dans votre soumission 510(k). Vous devrez également identifier la voie réglementaire pour votre SaMD. Votre plan de conception identifiera les membres de l’équipe ainsi que le rôle et la responsabilité de chacun. Cette phase est celle où vous devez documenter votre environnement de développement logiciel, créer un projet de description du logiciel et créer un projet de diagramme d'architecture logicielle.
Phase 2 – Les apports de conception doivent être documentés et approuvés au cours de la deuxième phase. Ces entrées sont des exigences de test. Par conséquent, vous devez développer un plan de test pour votre produit basé sur le parcours réglementaire de ce produit, les normes internationales reconnues ou les spécifications communes, ainsi que tout document d'orientation spécifique à votre type de SaMD. En règle générale, il est recommandé d'examiner votre plan de tests avec un organisme de réglementation lors d'une réunion préalable à la soumission avant d'effectuer vos tests de vérification et de validation, en particulier si des études précliniques sur les animaux ou des études cliniques sur les humains sont nécessaires. Cette phase est celle où vous devez effectuer une analyse des dangers et approuver votre spécification des exigences logicielles (SRS). L’analyse des dangers doit inclure une analyse des risques liés à l’utilisation (URRA) et une analyse des risques de cybersécurité.
Phase 3 – Les résultats de la conception sont développés de manière itérative au cours de la troisième phase. Il s'agit généralement de la phase la plus longue de votre processus de développement, et le « diagramme en cascade » n'est pas une représentation précise de la plupart des processus de développement logiciel. Le « diagramme en V » présenté dans la norme CEI 62304 est une meilleure représentation du processus de développement logiciel car vous répétez continuellement les étapes lorsque vous déboguez votre code et ajoutez des fonctionnalités à votre logiciel. Seul le micrologiciel le plus simple est écrit de manière linéaire, sans plusieurs cycles de débogage et de retest, et les méthodes de développement de produits Lean (c'est-à-dire la programmation Agile) sont destinées à être itératives. Cette phase de développement est terminée lorsque vous effectuez un « gel de la conception » et commencez vos tests de vérification et de validation. En règle générale, les entreprises qui développent SaMD peuvent terminer la plupart de leurs tests unitaires et tests d'intégration avant le gel de la conception, mais la validation du système peut ne pas être effectuée avant la phase 4. Malheureusement, les tests unitaires et les tests d'intégration ne peuvent se poursuivre que si vous avez un système embarqué (c'est-à-dire un logiciel intégré dans du matériel). Si le SaMD nécessite des études cliniques sur des humains, cette validation logicielle est effectuée au cours de la phase 4. La phase 3 est celle où vous devez documenter vos spécifications de conception logicielle (SDS), vos tests unitaires et vos tests d'intégration. Tous les tests formatifs requis pour l'interface utilisateur seraient effectués au cours de cette phase. Les tests formatifs peuvent inclure : 1) l'évaluation des fonctions du logiciel, 2) l'élaboration de modes d'emploi et 3) l'élaboration d'un programme de formation pour les utilisateurs. Vous devez également rédiger des protocoles de test pour la validation du système et les tests d'utilisabilité sommatifs au cours de cette phase. Il est important d'identifier toutes les tâches critiques liées aux risques liés à l'utilisation lors de cette phase et de les documenter. Ces tâches critiques déterminent les tests d’utilisabilité sommatifs requis. C'est également une excellente idée de commencer à rédiger une matrice de traçabilité au cours de cette phase pour garantir que chaque danger et élément SRS est pris en compte dans votre plan de vérification et de validation.
Phase 4 – La vérification de la conception et la validation de votre SaMD sont terminées au cours de cette phase. À la fin de cette phase, vous devez disposer d'une matrice de traçabilité complète, vous devez créer un rapport récapitulatif de vos tests unitaires et de vos tests d'intégration, et vous devez créer un rapport de validation du système – incluant tous les tests de performance sur table, sur animaux ou humains. . Vous devez également créer un document historique des révisions et un rapport de bogues identifiant tous les bogues connus dans le logiciel avec une justification expliquant pourquoi le logiciel peut être publié en toute sécurité avec ces bogues. C’est également à cette phase que vous devez compléter votre dossier de gestion des risques et votre rapport sommatif de tests d’utilisabilité. Enfin, vous devez rédiger une version finale de votre manuel d'utilisation du logiciel qui comprend le mode d'emploi et les indications d'utilisation. Lorsque toute cette documentation est complétée, vous êtes prêt pour votre soumission réglementaire.
Phase 5 – La sortie du produit est la dernière phase de conception et de développement. Une fois que vous avez reçu une autorisation de 510 XNUMX pour votre SaMD, vous pouvez alors commencer la version finale de votre produit. Vous devrez mettre à jour votre écran « splash » ou « à propos » pour que le logiciel inclue un Identificateur de périphérique unique (UDI). Les informations devront être téléchargées sur le GUDID de la FDA. Vous pouvez attribuer le DI pour l'UDI à tout moment, mais les éléments de données GUDID ne peuvent pas être finalisés tant que vous n'avez pas obtenu l'autorisation 510k de la FDA. Vous devrez également gérer les révisions de votre logiciel pour ce changement mineur et revalider le code. Ce type de changement ne nécessitera pas un nouveau 510k, car il s'agit d'une modification mineure de l'appareil. Cependant, vous devrez revoir le Directives de la FDA sur les modifications logicielles pour d'autres types de révisions logicielles que vous effectuerez à l'avenir.

Devriez-vous externaliser la documentation logicielle pour le logiciel en tant que dispositif médical (SaMD) ?

Vous pouvez externaliser toute la documentation de votre logiciel pour un SaMD, mais la ou les personnes créant cette documentation auront toujours besoin des documents mentionnés dans la phase 2. Si vous ne fournissez aucune documentation sur les dangers, une description du logiciel ou une esquisse grossière de l'architecture de votre logiciel, il sera presque impossible pour quiconque de créer la documentation de votre logiciel. Il est également extrêmement coûteux d’externaliser la documentation des logiciels. Même si vous externalisez cette tâche, vous devrez quand même examiner et approuver cette documentation. La plupart des gens sous-traitent des tâches parce qu'ils ne savent pas comment le faire, mais il est essentiel que les entreprises de dispositifs médicaux apprennent à documenter le développement de leurs logiciels, car elles devront conserver cette documentation lorsque le logiciel est mis à jour pour corriger un bug logiciel ou pour corriger les faiblesses de la cybersécurité. Toute personne développant un logiciel pour un SaMD doit recevoir une formation de base sur les exigences de la norme CEI 62304 dès le début de votre projet. Votre équipe n'a pas besoin d'être un expert de la CEI 62304, mais vous devez créer des projets de documents que vous pouvez présenter aux experts pour obtenir leurs commentaires. Votre équipe doit également examiner les quatre documents d'orientation publiés par la FDA pour la documentation des logiciels :

La création de votre documentation est la partie la plus difficile que votre équipe devrait accomplir, tandis que la révision et la modification de votre documentation sont une tâche formidable pour embaucher un consultant expert pour votre premier projet SaMD. Cela garantira que votre équipe rédige la documentation du logiciel avec le niveau de détail correct et que vous ne manquerez rien d'essentiel. Des consultants experts peuvent également vous fournir modèles pour la documentation de votre logiciel.

Le logiciel en tant que dispositif médical (SaMD) nécessite-t-il un système électronique de gestion de la qualité (eQMS) ?

Il existe deux types de systèmes qualité : 1) sur papier et 2) électronique. La plupart des start-ups ont choisi l'option papier parce qu'elles ne veulent pas avoir à valider un système électronique. Cependant, si votre entreprise est suffisamment intelligente pour valider SaMD, vous êtes également suffisamment intelligente pour valider les logiciels de votre système qualité. La norme applicable pour la validation des outils logiciels est ISO/TR80002-2:2017. Vous pouvez également acheter des modèles pour la validation des outils logiciels de l'Académie des dispositifs médicaux. Les entreprises demandent toujours une référence pour savoir quel système eQMS acheter. Le problème est que chaque année, les logiciels ont plus de fonctionnalités et coûtent moins cher. Par conséquent, mon conseil général est de ne jamais payer plus de 10,000 XNUMX $ pour un eQMS en tant que start-up et d’envisager de commencer avec un logiciel de base de données gratuit pour organiser toute la documentation contenue dans votre matrice de traçabilité. Vous pouvez migrer les données vers un eQMS ultérieurement en mappant votre base de données gratuite à la nouvelle base de données du logiciel eQMS.

Qui devrait être responsable de la qualité et de la réglementation si votre appareil est un logiciel en tant que dispositif médical (SaMD) ?

La qualité et la réglementation sont deux fonctions différentes, et il n'est pas toujours logique qu'une seule personne soit responsable des deux exigences. Les deux principales normes applicables à l'assurance qualité de SaMD sont 1) CEI 62304 et 2) ISO 13485. Toute personne que vous envisagez pour le poste de responsable qualité doit être familiarisée avec les deux normes et doit s'assurer que votre développement L'équipe documente la vérification et la validation du logiciel au fur et à mesure que vous progressez dans le processus de développement logiciel itératif typique des équipes de développement logiciel Agile. La personne n'a pas besoin d'être capable de coder un logiciel, mais elle doit être en mesure d'aider à réviser la documentation du logiciel et de suggérer des modifications. Le rôle de cette personne est extrêmement important pour s'assurer que les révisions logicielles sont correctement gérées, votre logiciel n'est publié que lorsque toutes les validations et revalidations sont terminées. Cette personne devrait également être en mesure de déterminer si un nouveau 510(k) est requis pour les modifications logicielles.

Le processus réglementaire consiste en la préparation de la soumission 510k et les communications avec la FDA. C’est une activité que vous devrez probablement réaliser une fois tous les deux ans. Les exigences de la FDA pour un 510k changent plus fréquemment qu'une fois tous les deux ans, et il est extrêmement difficile de devenir compétent lorsque vous remplissez si rarement des formulaires gouvernementaux. Pour ces raisons, il est recommandé de travailler avec un consultant expert en réglementation ayant une expérience SaMD jusqu'à ce que votre entreprise dispose de suffisamment de produits logiciels et de révisions pour que vous ayez besoin de déposer plusieurs soumissions 510 XNUMX chaque année. Par conséquent, un responsable qualité moins expérimenté peut apprendre progressivement les exigences réglementaires au fil du temps et aura moins besoin de l’aide d’un consultant en réglementation chaque année.

Avez-vous besoin d'un bureau d'entreprise?

De nombreuses entreprises MedTech sont des entreprises virtuelles, mais la FDA exigera une adresse physique à visiter pour une inspection de la FDA. Les inspecteurs de la FDA ont visité le domicile du fondateur de l'entreprise dans d'autres entreprises, mais vous serez probablement plus à l'aise avec un espace de bureau que l'inspecteur de la FDA pourra visiter. Il est peu probable que la FDA visite votre entreprise au cours de la première année suivant l’enregistrement initial de votre produit. Une inspection est plus probable au cours de la deuxième année suivant l'enregistrement et l'inscription initiaux. Par conséquent, vous pourriez envisager de louer un espace de coworking où vous pourrez réserver une salle de conférence en cas de visite d'un inspecteur de la FDA. Si vous n'avez pas les fonds nécessaires pour payer le loyer avant le lancement de votre produit, ne vous inquiétez pas. Il est peu probable que les inspecteurs de la FDA se rendent si tôt, et s’ils le font, détendez-vous et soyez honnête sur la situation. Tu n'es pas seul.

À propos de l’auteur

Robert Packard est un consultant en réglementation avec plus de 25 ans d'expérience dans les secteurs des dispositifs médicaux, pharmaceutiques et biotechnologiques. Il est diplômé de l'UConn en génie chimique. Robert était cadre supérieur dans plusieurs sociétés d'appareils médicaux, y compris le président-directeur général d'une société d'imagerie laparoscopique. Son expertise en matière de système de gestion de la qualité couvre tous les aspects du développement, de la formation, de la mise en œuvre et du maintien des certifications ISO 13485 et ISO 14971. De 2009 à 2012, il a été auditeur principal et instructeur pour l'un des plus grands organismes notifiés. La spécialité de Robert est les soumissions réglementaires pour les dispositifs médicaux à haut risque, tels que les implants et les produits combinés médicament/dispositif pour les applications de marquage CE, les demandes de dispositifs médicaux canadiens et les soumissions 510(k). La partie la plus préférée de son travail consiste à former les autres. Il est joignable par téléphone au 802.258.1881 ou email. Vous pouvez également le suivre sur Google+, LinkedIn or Twitter.

Publié dans: Autres

Source : https://medicaldeviceacademy.com/software-as-a-medical-device/

Horodatage: Le 1 juin 2021