CSA – Computer Software Assurance e CSV – Computerized System Validation
Introdução
A abordagem CSA foi sugerida pelo FDA (Food and Drug Administrarion – EUA) no Guia Computer Software Assurance for Production and Quality System Software, do qual sugere uma nova abordagem para softwares envolvidos na produção ou no sistema da qualidade, através de considerações específicas de riscos, métodos de teste aceitáveis e geração eficiente e objetiva de evidências.
Importante ressaltar que o documento acima é um guia, do qual traz recomendações e não requisitos regulatórios. As normas atualmente aplicáveis não foram substituídas e devem ser seguidas.
Seja na abordagem CSV ou CSA, o objetivo principal é garantir que o sistema opere sem falhas, de acordo com o uso pretendido, garantindo assim, a qualidade do produto sem risco ao usuário final. Além disso, manter o estado de validado do sistema ao longo do ciclo de vida.
Acredito que, a virada de chave entre a abordagem CSV e CSA é ressaltar que, um sistema computadorizado está seguro, sem a necessidade de construir/manter uma grande quantidade de ‘papel’. E para isso, volto a usar a frase: ‘Quantidade não é Qualidade’.
Além disso, é encorajada que a cultura da empresa seja foco na qualidade e não em auditoria.
Abaixo um resumo dos esforços entre as duas abordagens:
Identificação e Análise de Riscos
O Guia sugere que seja realizada a classificação dos sistemas utilizados na produção e no sistema da qualidade em duas categorias:
- Impacto direto: software que é usado diretamente como parte da produção ou do sistema de qualidade.
- Impacto indireto: software que dá suporte à produção ou ao sistema de qualidade.
Na sequência, o impacto do risco deve ser avaliado, para cada recurso, função e operação, do qual impactará no uso pretendido, ou seja, para o qual o software foi adquirido e será utilizado no processo. Diferente das metodologias FMEA, GAMP5, ISO14971:2019 não considera avaliação de probabilidade e ocorrência. Essa avaliação poderá ser realizada de maneira binária, como: “processo de alto risco” e “ não é um processo de alto risco”.
Recurso, função e operação a serem utilizados no processo, classificados como alto risco tem suas atividades registradas, a fim de evitar risco falhas e impacto na qualidade sem comprometer a segurança do produto. Como exemplo, no Apêndice 1 o FDA sugere os seguintes documentos para softwares classificados como ‘não é um processo de alto risco’:
- o uso pretendido
- a determinação dos riscos
- descrição resumida dos recursos, funções e operações testadas
- os objetivos do teste e se eles passaram ou falharam
- quaisquer problemas encontrados e sua disposição
- uma declaração final que indique que o desempenho da operação é aceitável
- a data em que o teste foi realizado e quem executou o teste.
É fortemente sugerida a utilização da documentação do fornecedor, pois dessa forma diminui os esforços das atividades para a empresa regulada.
Atividades para Garantir a Qualidade do Software
Reduzir a documentação não significa não documentar. A abordagem do CSA apoia o uso eficiente dos recursos. Como o esforço de garantia de software é baseado em risco, ele segue uma abordagem menos onerosa, onde o ônus da validação não é maior do que o necessário para lidar com o risco.
Além dos protocolos de testes tradicionais que já estamos acostumados, foram sugeridos agora, nova abordagem de testes, sendo:
- Unscripted testing / Teste sem roteiro – teste dinâmico em que as ações do testador não são descritas em roteiro de testes;
- Ad-hoc testing / Teste ad-hoc – testes que foram improvisados, que não dependem de documentação para execução dos testes;
- Error-guessing / Adivinhação de erros – teste que são do conhecimento do testador sobre falhas passadas ou conhecimento geral dos modos de falha;
- Exploratory testing / Testes exploratórios – testes baseados na experiência do testador, planeja e executa testes com base no conhecimento do testador;
- Scripted testing / Testes com roteiro – podendo ser dividido entre testes robustos ou limitados, a depender do risco. Risco alto requer documentação mais detalhada, risco médio e baixo podendo ser não roteirizado, como parte do mesmo escopo de documento.
Evidências
Assim como descrito no GAMP5 2nd edition, o Guia Computer Software Assurance for Production and Quality System Software, também encoraja a diminuição das evidências, como print screen ou screen shots e ressalta: “como um método menos oneroso, a FDA recomenda o uso de registros eletrônicos, como logs do sistema, trilhas de auditoria e outros dados gerados pelo software, em oposição à documentação em papel e capturas de tela”.
Conclusão
A abordagem CSA traz uma mudança cultural a nível de robustez de documentação, do qual diminui o esforço da validação do sistema, com documentos mais resumidos, evita a duplicidade de documentos e atividades, incorpora a documentação e testes do fornecedor, ou dos desenvolvedores do software como evidência documental, traz mais agilidade na elaboração dos documentos e execução dos testes.
É importante ressaltar que a cultura CSA é amparada ainda, pelos processos da Garantia da Qualidade da empresa detentora do registro, como: procedimentos, qualificação de fornecedores, robusto controle em processo, monitoramento periódico do sistema afim de evitar falhas.
Não exime o fabricante ao cumprimento dos requisitos regulatórios, apenas diminui o esforço da validação para que a mesma traga menos ônus ao processo.
Referência: Computer Software Assurance for Production and Quality System Software
