19 de janeiro de 2023
Em setembro de 2022, a (FDA) divulgou rascunho de orientação sobre garantia de sistemas de computador (CSA) Esclarecendo os requisitos de validação de software para fabricantes de dispositivos médicos. A orientação reduz significativamente a carga de validação dos fabricantes e cria maior potencial para acelerar a adoção de tecnologias digitais.
A orientação da CSA baseia-se em 21 CFR Part 820, que regulamenta amplamente o software utilizado em sistemas de produção e qualidade. Por esse motivo, vamos analisar como a CSA difere da validação de software (CSV) e o que consta nas novas diretrizes.
O que é Computer Software Assurance (CSA)?
Pela definição da FDA, CSA é “uma abordagem baseada em risco para estabelecer e manter a confiança de que o software é adequado para o uso pretendido”.
Além disso, a abordagem CSA considera os riscos à segurança e/ou à qualidade do dispositivo caso o software não funcione conforme o esperado. Portanto, o nível de garantia e as atividades relacionadas utilizadas para estabelecer a confiança no software baseiam-se nesses riscos. abordagem menos onerosa, as atividades de garantia são a quantidade mínima de informações necessárias para abordar o risco.
Em última análise, a orientação da CSA para sistemas de qualidade visa reduzir obstáculos desnecessários que atrasariam a comercialização de dispositivos médicos para garantir que os pacientes tenham acesso oportuno aos produtos.
Onde a nova orientação se encaixa
Atualmente, Regulamento do Sistema de Qualidade 21 CFR 820.70(i) exige que os fabricantes validem o software utilizado como parte do sistema de produção ou de qualidade. Isso inclui software de sistema de gestão da qualidade (SGQ).
Desde a publicação do 21 CFR 820.70(i), o FDA participou de diversos documentos de orientação relacionados à validação de software. Estes incluem o documento da agência Princípios Gerais de Validação de Software (GPSV) e a Sociedade Internacional de Engenharia Farmacêutica (ISPE) Abordagem baseada em risco para sistemas computadorizados compatíveis com GxP (GAMP 5).
A orientação do CSA complementa o GPSV, substituindo apenas a Seção 6. É baseada no Estrutura GAMP 5, que reconhece diferentes níveis de risco associados a diferentes tipos de software.
Compreendendo a Orientação CSA para Abordagem de Sistemas de Qualidade
Durante décadas, os fabricantes aplicaram os princípios de validação de software a todos os softwares utilizados, independentemente dos riscos à segurança. No entanto, o GPSV recomenda a garantia da qualidade do software para prevenir defeitos no desenvolvimento de software, incluindo uma abordagem baseada em risco para demonstrar que o software funciona corretamente.
A nova orientação da CSA para garantia de software abrange recomendações para computadores ou softwares utilizados em sistemas de produção ou de qualidade. Portanto, a orientação é aplicável a softwares de SGQ.
Felizmente, o CSA permite mais flexibilidade na conformidade com 21 CFR 820.70(i), permitindo que os fabricantes aproveitem atividades como:
- Testes baseados em risco – analisar riscos com base na complexidade do software, criticidade do negócio, frequência de uso e prováveis áreas de defeitos
- Testes sem script – menos demorado do que os scripts de teste tradicionais; reservado para recursos e sistemas de baixo a médio risco
- Monitoramento contínuo de desempenho – o processo de avaliação contínua de como o software funciona de acordo com as expectativas
- Monitoramento de dados – identificar claramente como a qualidade dos dados atenderá aos seus objetivos declarados
- Atividades de validação – conforme concluído por outras partes, como fornecedores de software
A Estrutura de Orientação de Risco da CSA
A estrutura de risco do CSA concentra-se em quatro etapas distintas:
- Identificar o uso pretendido do recurso ou função do software
- Determinando a abordagem baseada em risco
- Determinar as atividades de garantia correspondentes que precisam ser executadas
- Criar o registro apropriado documentando O QUÊ
1. Identificando o uso pretendido
O 21 CFR 820.70(i) exige que os fabricantes validem softwares que façam parte de sistemas de produção ou de qualidade para o uso pretendido. Isso inclui softwares para automatizar processos de qualidade, coletar e processar dados de qualidade ou manter registros de qualidade.
Às vezes, o software utilizado em sistemas de produção ou de qualidade pode ter diversos recursos, funções e operações com um ou mais usos pretendidos. Nesse caso, a FDA recomenda analisar os usos pretendidos de cada recurso e função para determinar as atividades de garantia apropriadas.
Por exemplo, um software comercial pronto para uso (COTS) é usado para documentar dados de tempo e temperatura para um processo de cura. Como o software permite a manutenção de registros de qualidade, manter um estado validado pode não exigir atividades de garantia além de:
- O que o desenvolvedor já fez em termos de validação
- Realizando uma avaliação de fornecedores
- Instalação e configuração de software
Por outro lado, se uma fórmula personalizada calcular estatísticas para monitorar o processo de cura, poderá ser necessária validação adicional.
2. Determinando a abordagem baseada em risco
Após determinar que o software faz parte de sistemas de produção ou de qualidade, a próxima etapa é uma análise baseada em riscos para determinar as atividades de garantia. Essa abordagem baseada em riscos inclui:
- Identificação de falhas de software razoavelmente previsíveis
- Determinar se cada falha representa um alto risco de processo
- Selecionar e executar atividades de garantia compatíveis com o risco do dispositivo médico ou do processo, conforme aplicável
Além disso, a análise baseada em risco deve analisar fatores que podem afetar o funcionamento esperado do software, incluindo:
- Configuração ou gerenciamento do sistema
- A segurança do sistema
- Armazenamento e transferência de dados
- erro do operador
Para falhas razoavelmente previsíveis, esta análise deve examinar o risco resultante, incluindo (1) risco de processo e (2) risco de dispositivo médico. A FDA define esses riscos da seguinte forma:
- Risco de processo: Potencial para comprometer a produção ou o sistema de qualidade
- Risco de dispositivos médicos: Potencial para causar danos ao paciente
Alto risco de processo ocorre quando uma falha de software pode resultar em um problema de qualidade que pode aumentar o risco do dispositivo médico. Alternativamente, se a falha de software não representa um risco para o dispositivo médico, não é considerada um alto risco de processo. Portanto, funções do SGQ, como Gerenciamento de reclamacoes, controle de mudanças e gerenciamento de documentos não são considerados de alto risco.
A orientação da FDA diz que a agência está "principalmente preocupada com a revisão e garantia dos recursos, funções e operações de software que apresentam alto risco de processo, porque uma falha também representa um risco para o dispositivo médico".
Na prática, muitos fabricantes utilizam gestão de risco Ferramentas que abrangem uma gama de riscos intermediários. Neste caso, como a FDA considera apenas alto risco/não alto risco, os riscos intermediários também são considerados de baixo risco. Para aqueles que se enquadram no alto risco de processo, o próximo passo lógico é avaliar o risco do dispositivo médico.
3. Determinação das atividades de garantia apropriadas
A orientação da CSA recomenda que, para problemas de qualidade com alto risco de processo, as atividades de garantia sejam correlacionadas ao risco do dispositivo médico. Por outro lado, quando um problema de qualidade não for considerado de alto risco de processo, o nível das atividades de garantia deve corresponder ao risco do processo.
Por exemplo, a FDA utiliza um recurso que registra dados de processo para revisão, o que representa um risco menor para o processo. No entanto, o risco é maior quando os dados de processo ajudam a determinar a aceitabilidade do produto antes da revisão.
Recursos de software de alto risco normalmente exigem atividades de garantia mais rigorosas, como testes com script ou testes com script limitado. Risco de processo baixo, por outro lado, normalmente significa gerar evidências menos objetivas. Por exemplo, atividades de garantia de risco de processo baixo podem incluir métodos de teste sem script (como testes ad-hoc, suposição de erros ou testes exploratórios).
Além dos recursos de software, os fabricantes de dispositivos devem revisar outros controles dentro do sistema de qualidade, aproveitando trabalhos como:
- Atividades de controle de produção, incluindo procedimentos de integridade de dados
- Processos de seleção de fornecedores
- Trabalho de validação já realizado pelo fornecedor do software
- Dados de monitoramento contínuo para detecção de problemas de desempenho de software
- Ferramentas CSV, como rastreamento de bugs e testes automatizados
Embora as ferramentas utilizadas possam variar, o importante é que o fabricante garanta que o software mantenha um estado validado.
4. Criando o Registro
A orientação da FDA estabelece que os fabricantes devem criar um registro das atividades de garantia. Para cada software apresentado, o registro deve incluir o uso pretendido, a determinação de risco e a documentação das atividades de garantia realizadas, incluindo:
- Descrição do teste
- Quaisquer problemas encontrados e o que foi feito para resolvê-los
- Conclusão afirmando a aceitabilidade dos resultados
- Data do teste e pessoa que o conduziu
- Assinatura e data da pessoa que revisou o registro
Conexão do Sistema de Gestão da Qualidade com a Orientação CSV
Software QMS Geralmente, se enquadra na categoria 4 ou 5 de software, de acordo com a diretriz GAMP 5, dependendo da adição ou não de recursos personalizados. A categoria 4 é o software mais utilizado no setor. Em comparação com o uso de software pronto para uso, ela fornece ferramentas validadas para configurar o software sem codificação para atender aos requisitos de negócios. Isso se compara ao software da categoria 5, que possui níveis adicionais de personalização que exigem alterações no código.
O processo de Abordagem CSA Reduz significativamente as necessidades de validação quando o fornecedor do software já realizou a validação completa. Para alguns recursos, as empresas podem simplesmente utilizar a documentação do fornecedor, demonstrando o funcionamento do software em um cenário de teste de caso de uso de ponta a ponta. As empresas devem avaliar a documentação técnica do fornecedor, bem como os modelos de validação para os recursos do QMS configurados.
Conclusão
A mudança da validação de sistemas computacionais para a ASC pode reduzir drasticamente o tempo e os custos associados à implementação de software automatizado. De fato, o Fórum de Casos para a Qualidade do Consórcio de Inovação em Dispositivos Médicos (MDIC) de 2020 observa uma redução de 50% ou mais no tempo de validação com essa abordagem.
Com base nas regulamentações e orientações existentes, a CSA representa um caminho simplificado para manter o software validado. Para os fabricantes, ela reduz as barreiras à adoção de novas tecnologias que podem melhorar a segurança do paciente, incluindo softwares de SGQ. Com a mudança, as empresas podem economizar tempo e dinheiro, aumentando a produtividade e a eficiência.
Sobre o autor
Stephanie Ojeda Stephanie é Diretora de Gestão de Produtos para o setor de Ciências Biológicas na AssurX. Stephanie traz mais de 15 anos de experiência em funções de liderança em garantia de qualidade em diversos setores, incluindo farmacêutico, biotecnologia, dispositivos médicos, alimentos e bebidas e manufatura.
