4 min ler
Com a evolução da tecnologia, o sector dos cuidados de saúde tem vindo a apostar na integração de software com dispositivos médicos para incorporar a automatização e a precisão na previsão, diagnóstico, prevenção, tratamento e gestão das condições de saúde. A FDA dos EUA há muito que reconheceu o papel que o software pode desempenhar para beneficiar o funcionamento dos dispositivos médicos, mas ainda não tinha apresentado quaisquer orientações ou regras concretas que pudessem ter facilitado os avanços dos investigadores do sector no sentido da saúde digital.
Em 4 de novembro de 2021, a FDA dos EUA publicou um projeto de orientações sobre o "conteúdo das submissões pré-comercialização para funções de software de dispositivos", dando uma ideia concreta aos promotores responsáveis pela preparação do documento e das informações a incluir. Estas informações fornecidas pelos promotores são importantes para a FDA avaliar o software do dispositivo que executa uma ou mais funções e para garantir a segurança e a eficácia ao longo do seu ciclo de vida. As novas orientações são uma recomendação e uma versão preliminar sobre as funções do software dos dispositivos médicos que a FDA se comprometeu a publicar em substituição do documento de orientação com 15 anos de existência, "Guidance for the content of pre-market submission for the software contained in Medical device", publicado em maio de 2005. A FDA manteve a janela para feedback, e quaisquer discussões sobre o mesmo estão abertas até 2 de fevereiro de 2022.
Nesta nova versão, a FDA reconheceu o modo de associação do software a um dispositivo médico e diferenciou-os em SaMD - Software como dispositivo médico e SiMD - Software num dispositivo médico, como subdivisões das funções do software do dispositivo. O software como dispositivo médico ou SaMD é um software que executa ele próprio a tarefa de um dispositivo médico, de acordo com a definição de dispositivo médico mencionada na Secção 201 (h) da Lei FD&C, mas não faz parte de um componente do dispositivo. Por outro lado, o software em SiMD, como o nome sugere, faz parte do componente ou hardware do dispositivo médico utilizado para registar, controlar ou apresentar informações médicas ou não médicas.
O projeto centra-se mais nas expectativas da FDA relativamente à preparação dos documentos necessários para as apresentações pré-comercialização de funções de software de dispositivos. A FDA tem um entendimento claro do que espera ver nos documentos que estabelecem de forma sólida a Especificação de Requisitos de Software (SRS) e as Especificações de Conceção de Software ou Sistema (SDS). A FDA dá ênfase a uma abordagem baseada no risco ao documentar as submissões pré-comercialização das funções de software de dispositivos. Com base neste nível de preocupação ou no risco associado à utilização prevista do dispositivo, o nível de documentação também deve variar como documentação básica e melhorada. Os pontos-chave que cada nível de documentação deve realçar para identificar o nível de preocupação do software associado ao dispositivo médico são
- A visão geral do software dá uma ideia das entradas e saídas
- Especificações dos requisitos de software (SRS), que incluem pormenores da arquitetura do software com um diagrama esquemático de todos os módulos, periféricos, linguagens de programação, sistema operativo, versão do compilador, utilização de qualquer software de base e quaisquer pormenores UI/UX
- As especificações de conceção do software ou do sistema (SDS), que abrangem informações sobre o software desde a fase de conceção, são exigidas aos promotores que apresentam documentação melhorada. Enquanto as SRS descrevem a função pretendida do software, as SDS são informações pormenorizadas sobre a metodologia de implementação dos requisitos mencionados nas SRS. A FDS deve incluir um pormenor de conceção técnica abrangente com informações adequadas sobre a utilidade, o funcionamento que remete para as SRS, se é necessária assistência para operar o software ou se se trata de um sistema CAD treinado construído com base em modelos AI/ML
- A adesão às normas de consenso voluntário reconhecidas pela indústria para submissões regulamentares tornar-se-ia fácil e mais em sintonia com as actuais tendências, práticas e inovações do mercado da saúde digital, de acordo com este novo projeto de diretrizes. Os dispositivos que requerem documentação básica e melhorada têm de estar em conformidade com a versão reconhecida pela FDA da norma ANSI/AAMI IEC 62304 Medical device software- Software lifecycle process. Os documentos melhorados requerem uma descrição adicional da configuração completa com ainda mais pormenores sobre o plano de desenvolvimento e manutenção da conceção no ciclo de vida do software para maior clareza durante a revisão
- Com base na análise de risco, de acordo com os requisitos dos regulamentos relativos ao sistema de qualidade (21 CFR 820), devem também ser incluídas informações relacionadas com a segurança, como o ambiente de funcionamento, a eficácia, a exatidão, o tempo de resposta, o tempo de atraso, a consistência, os limites de funcionamento e o intervalo, bem como qualquer valor de base ou limiar que o software exija para funcionar. Deve ser mencionada a existência de um sistema de vigilância para controlar os dados registados na memória do dispositivo ou no sistema de armazenamento
- Como parte do ciclo de vida do software, a verificação e a validação do software são essenciais, conseguidas através do teste dos componentes do software ao nível do sistema ou da integração. Isto é obrigatório para uma melhor documentação. Além disso, a descrição dos protocolos de teste, juntamente com os resultados esperados ou observados para estabelecer o estado de aprovação/reprovação do sistema, também deve ser discutida
- Qualquer envolvimento de anomalias não resolvidas, como bugs, defeitos que possam afetar o desempenho da função de software deve ser identificado e classificado com base na taxonomia de defeitos, de acordo com a classificação de defeitos em software de saúde da ANSI/AAMI SW91
É necessário apresentar documentação melhorada para dispositivos que sejam produtos combinados ou classificados como dispositivos de alto risco da Classe III ou uma função de software destinada a ser utilizada em aplicações de dádiva de sangue e transfusão de sangue que efectue a avaliação da compatibilidade do dador e do recetor. Os dispositivos que exigem documentação especial devem seguir os requisitos de documentação reforçada. A documentação básica deve resumir a análise de perigos, a atenuação de perigos e os relatórios de justificação de riscos.
De acordo com os compromissos do MDUFA IV, a Agência deve publicar a orientação final dentro de 12 meses após o final do período de comentários do projeto. O FDA declarou hospedar um webinar em 16 de dezembro de 2021, para fabricantes de dispositivos médicos, pesquisadores da indústria de saúde digital e profissionais para discutir este projeto de orientação.
Para saber mais sobre a submissão de funções de software de dispositivos antes da comercialização, contacte um especialista regional em regulamentação como a Freyr. Mantenha-se informado. Mantenha-se em conformidade.
