4 min de leitura
Com a evolução da tecnologia, o setor da saúde tem vindo a apostar cada vez mais na integração de software com dispositivos médicos, com vista a incorporar automação e precisão na previsão, diagnóstico, prevenção, tratamento e gestão de problemas de saúde. A Comissão de Comércio Federal ( US )FDA há muito que reconhecia o papel que o software pode desempenhar para melhorar o funcionamento dos dispositivos médicos, mas ainda não tinha elaborado quaisquer orientações ou regras concretas que pudessem ter facilitado aos investigadores do setor a realização de avanços no domínio da saúde digital.
A 4 de novembro de 2021, a Agência de Alimentos e Medicamentos dos EUA ( US ,FDA ) publicou um projeto de orientação sobreo «conteúdo dos pedidos de autorização pré-comercialização relativos às funções do software dos dispositivos», fornecendo uma ideia clara aos requerentes responsáveis pela elaboração do documento e sobre as informações a incluir. Estas informações fornecidas pelos requerentes são importantes para que a Agência de Alimentos e Medicamentos dos EUA ( FDA ) avalie 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. A nova orientação é uma recomendação e uma versão preliminar sobre as funções do software de dispositivos médicos, que a FDA se comprometeu a publicar em substituição do documento de orientação com 15 anos de idade intitulado «Orientação sobre o conteúdo dos pedidos de autorização de comercialização relativos ao software contido em dispositivos médicos», publicado em maio de 2005. Foi mantido o prazo para a apresentação de comentários, estando abertas as discussões sobre o mesmo até 2 de fevereiro de 2022.
Nesta nova versão, a Lei de Produtos de Saúde de 2017 ( FDA ) reconheceu o modo de associação do software a um dispositivo médico e diferenciou-os ainda mais 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» ( SaMD ) é um software que, por si só, desempenha a função de um dispositivo médico, de acordo com a definição de dispositivo médico referida na Secção 201 (h) da Lei FD&C, mas que não faz parte de nenhum componente do dispositivo. Por outro lado, o software em SiMD, tal 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 Agência de Alimentos e Medicamentos dos EUA ( FDA ) relativamente à preparação da documentação necessária para os pedidos de autorização de comercialização das funções de software dos dispositivos. A agência definiu claramente o que espera encontrar nos documentos que estabelecem de forma robusta a Especificação de Requisitos de Software (SRS) e as Especificações de Design de Software ou do Sistema (SDS). O documento « FDA » (Guia para a documentação de software de dispositivos médicos) enfatiza uma abordagem baseada no risco na documentação para os pedidos de autorização de colocação no mercado relativos às funções de software de dispositivos. Com base neste nível de preocupação ou no risco associado à utilização pretendida do dispositivo, o nível de documentação também deve variar entre documentação básica e documentação avançada. Os pontos-chave que cada nível de documentação deve destacar para identificar o nível de preocupação do software associado ao dispositivo médico são:
- A visão geral do software, que dá uma ideia das entradas e das saídas
- Especificações de Requisitos de Software (SRS), que incluem detalhes sobre a 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 shell e quaisquer detalhes relativos à IU/UX
- As Especificações de Concepção de Software ou de Sistema (SDS), que abrangem informações sobre o software desde a fase de conceção, são obrigatórias para os patrocinadores que apresentem documentação alargada. Enquanto o SRS descreve a função pretendida do software, o SDS fornece informações aprofundadas sobre a metodologia de implementação dos requisitos mencionados no SRS. O SDS deve incluir detalhes técnicos abrangentes do projeto, com informações adequadas sobre a utilidade e o funcionamento, que se relacionem com o SRS, indicando se é necessária assistência para operar o software ou se se trata de um sistema CAD treinado, baseado em modelos de IA/ML .
- De acordo com este novo projeto de orientação, o cumprimento das normas consensuais voluntárias reconhecidas pelo setor para a apresentação de pedidos de regulamentação tornar-se-ia mais fácil e mais em sintonia com as atuais tendências, práticas e inovações do mercado da saúde digital. Os dispositivos que requerem documentação básica e alargada têm de cumprir a versão reconhecida pelo Instituto de Normas de Saúde da América ( FDA) da norma ANSI/AAMI IEC 62304 «Software para dispositivos médicos — Processo do ciclo de vida do software». A documentação alargada requer uma descrição adicional da configuração completa, com detalhes ainda mais pormenorizados sobre o plano de desenvolvimento e manutenção do projeto 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 do Sistema de Qualidade (21 CFR 820), devem também ser incluídas informações relacionadas com a segurança, tais como o ambiente operacional, a eficácia, a precisão, o tempo de resposta, o tempo de atraso, a consistência, os limites e a gama operacionais, bem como quaisquer valores de base ou limiares necessários ao funcionamento do software. Deve ser mencionada a existência de qualquer sistema de vigilância destinado a acompanhar os dados registados utilizando a memória do dispositivo ou o sistema de armazenamento.
- No âmbito do ciclo de vida do software, a verificação e a validação do software são essenciais, sendo realizadas através do teste dos componentes do software ao nível do sistema ou da integração. Este processo é obrigatório para uma documentação mais completa. Além disso, deve também ser abordada a descrição dos protocolos de teste, juntamente com os resultados esperados ou observados, para determinar se o sistema foi aprovado ou reprovado.
- Qualquer ocorrência de anomalias não resolvidas, tais como erros ou defeitos que possam afetar o desempenho do software, deve ser identificada e classificada com base na taxonomia de defeitos, de acordo com a «Classificação de defeitos em software de saúde» da norma ANSI/AAMI SW91.
É necessário apresentar documentação reforçada para os dispositivos que sejam produtos combinados ou classificados como dispositivos de alto risco da Classe III, ou ainda para funções de software destinadas a ser utilizadas em aplicações de dádiva e transfusão de sangue que realizem a avaliação da compatibilidade entre o dador e o recetor. Os dispositivos que exijam documentação especial devem cumprir os requisitos de documentação reforçada. A documentação básica deve incluir resumos dos relatórios de análise de perigos, mitigação de perigos e justificação de riscos.
De acordo com os compromissos da MDUFA IV, a Agência deverá publicar as orientações finais no prazo de 12 meses a contar do final do período de comentários sobre o projeto. A Associação de Produtores de Dispositivos Médicos ( FDA ) anunciou que irá organizar um webinar a 16 de dezembro de 2021, destinado a fabricantes de dispositivos médicos, investigadores do setor da saúde digital e profissionais da área, para debater este projeto de orientações.
Para saber mais sobre a apresentação pré-comercialização das funções de software dos dispositivos, reach contacteum especialista regional em regulamentação, como a Freyr. Mantenha-se informado. Mantenha-se em conformidade.
