GAMP5® 2nd edition e CSA FDA: por que podem ser bons para o negócio

Alguns pontos importantes que a segunda edição do GAMP5® e CSA trouxeram e que nos fazem pensar em como serão as validações de sistemas daqui em diante

O intuito deste artigo é consolidar os principais pontos de mudanças entre a primeira e segunda versões do guia GAMP5 e trazer alguns tópicos do guia CSA emitido pelo FDA. Não substitui a leitura de tais guias.

O que é GAMP5®, segunda edição

Empresas de Ciências da Vida, principalmente as biofarmacêuticas e produtos médicos são altamente reguladas e precisam provar que o produto e seu processo de fabricação e desenvolvimento são robustos.

Esse é o papel da validação: gerar evidências documentais para provar que equipamentos, sistemas, planilhas, processos e procedimentos funcionam de forma a proteger o paciente ou consumidor, a qualidade de produto e integridade de dados. A ISPE® (International Society of Pharmaceutical Engineering) desenvolveu o Guia GAMP (Good Automated Manufacturing Practice) para orientar a comunidade de Ciências da Vida a desenvolver validações robustas.

A versão 5 do guia foi lançada em 2008 e recentemente, em 2022, foi lançada a segunda versão da publicação, trazendo insights que podem ser muito úteis ao negócio.

Principais Diferenças entre GAMP5 primeira e segunda edições

 
 

O Guia GAMP5 segunda edição incluiu os seguintes tópicos:

Apêndice D8 – métodos ágeis de desenvolvimento

Esse item resume os princípios de metodologias e frameworks ágeis e ilustra como podem ser implementadas de forma a estarem alinhadas com GAMP5® e princípios BPx (impacto em boas práticas). Em 2021, a ISPE® lançou um guia apêndice intitulado Enabling Innovation que basicamente foi incluído na segunda versão do GAMP5®. Esse item resume os princípios de metodologias e frameworks ágeis e ilustra como podem ser implementadas de forma a estarem alinhadas com GAMP5® e princípios BPx (impacto em boas práticas).

O principal ponto desta literatura é a abordagem iterativa e incremental para o processo de desenvolvimento de software e é uma tendência que vem dominando o mercado como um todo. A larga adoção se explica pela agilidade e flexibilidade que o framework traz para os times de negócio.

Embora o modelo tradicional em cascata (waterfall) ofereça uma série de vantagens e atenda a diversos cenários incluindo o regulatório, este apresenta algumas desvantagens por não se alinhar às urgências e constantes mudanças no mercado atual. Assim, para lidar com essas demandas e atingir melhores resultados em médio e longo prazo, é preciso buscar novas saídas. Adoção deste apêndice pode ajudar seu negócio a desempenhar melhor, atendendo de forma robusta, a conformidade esperada pelos órgãos reguladores.

A adoção de um processo de desenvolvimento iterativo e incremental em aplicações BPx relevantes está nas bases das metodologias ágeis, como a Scrum. A ideia é que a criação de um software seja pautada por vários ciclos menores, em que funcionalidades são introduzidas, feedbacks coletados e requisitos revistos, sendo cada etapa validada e formalmente entregue ao negócio (releases parciais). Nesta abordagem, a URS (User Requirement Specification) é elaborada de forma incremental (para cada etapa de implementação), por parte ou processo que seguem para desenvolvimento ou configuração, testes e liberação em ciclos iterativos.

O principal ponto desta literatura é a abordagem iterativa e incremental para o processo de desenvolvimento de software e é uma tendência que vem dominando o mercado como um todo. A larga adoção se explica pela agilidade e flexibilidade que o framework traz para os times de negócio. Embora o modelo tradicional em cascata (waterfall) ofereça uma série de vantagens e atenda a diversos cenários incluindo o regulatório, este apresenta algumas desvantagens por não se alinhar às urgências e constantes mudanças no mercado atual. Assim, para lidar com essas demandas e atingir melhores resultados em médio e longo prazo, é preciso buscar novas saídas. Adoção deste apêndice pode ajudar seu negócio a desempenhar melhor, atendendo de forma robusta, a conformidade esperada pelos órgãos reguladores.

 

Clique para saber mais: Validação sem papel.

Apêndice D9 – ferramentas ao invés de documentos

Esse item descreve abordagem baseada em risco recomendada para ferramentas que suportam processos do ciclo de vida de sistemas computadorizados, processos de TI e infraestrutura de TI (ferramentas de desenvolvimento, suporte e manutenção). As ferramentas que forem utilizadas devem passar por um processo de seleção, avaliação dos riscos associados à sua utilização, instalação e configuração, sendo disponível de forma segura ao uso pretendido. As ferramentas que aceleram ou auxiliam o processo de validação devem ter controles para manter a integridade, segurança e disponibilidade.

No caso da ferramenta GO!FIVE® desenvolvida pela FIVE Validation, todos os controles de integridade de dados de registros BPx foram previstos, disponibilizados e validados pelo time de QA. Qualquer aprovação ou aceite de documentos ou resultados de testes tem controle de acesso robusto, rastreabilidade e assinatura eletrônica.

 

Clique para saber mais: Validação sem papel.

O Guia GAMP5 segunda edição incluiu os seguintes tópicos:

Apêndice D10 – sistemas distribuídos (Blockchain)
Esse apêndice do Guia descreve como tratar a infraestrutura ou sistemas descentralizados com computação distribuída.

O termo ‘ledger’ é bastante utilizado na contabilidade. É como se fosse um livro razão ou arquivo digital de entrada final e oficial onde as transações de negócio são registradas.

Distributed Ledgers é o consenso de dados digitais replicados, compartilhados, e sincronizados que estão geograficamente espalhados (distribuídos) por muitos lugares, países ou instituições.

Ao contrário de uma base de dados centralizada, um sistema de distributed ledger não requer um administrador central, e consequentemente não tem um único ponto central de falha.

À medida que mais membros do ambiente tecnológico de healthcare optam por participar na rede, esta pode abranger cadeias inteiras de fornecimento, desde fabricantes de matérias-primas até farmácias, clínicas ou hospitais.

Os efeitos de rede desta tecnologia podem pressionar os fabricantes biofarmacêuticos a participar, tanto para fins regulatórios como comerciais.
Mesmo que a empresa regulada opte por não participar, é muito provável que um dos seus fornecedores ou clientes o faça.

Apêndice D11 – inteligência artificial e machine learning (AI/ML)
Esse apêndice descreve como a inteligência artificial e machine learning podem ser integrados na indústria de Ciências da Vida. Sua adoção é importante para inovação no setor.

Descreve que a importância da integridade de dados para qualidade da AI/ML e entendimento de riscos inerentes.

A utilização de AI, juntamente com a subdisciplina do ML, apresenta à indústria das ciências da vida um desafio na manutenção da qualidade global e conformidade regulatória de tais sistemas, aplicações e/ou soluções de TI.

Esse apêndice fornece um entendimento básico para estas soluções digitais e orientação sobre como assegurar a integração e adequação à utilização em um ambiente BPx relevante.
Apêndice M11 – infraestrutura de TI em nuvem
A primeira versão do GAMP5 trazia um capítulo importante no apêndice S5 sobre gerenciamento de qualidade em ambiente de TI terceirizado.

Agora, na segunda edição, o apêndice M11 deixa clara a recomendação da estratégia baseada em riscos para boas práticas de gerenciamento de infraestrutura interna ou fornecedores externos, principalmente infraestrutura em nuvem.

Infraestrutura de TI controlada é um pré-requisito para assegurar que as aplicações BPx relevantes são geridas neste ambiente.

A infraestrutura desempenha um papel significativo na garantia de que as aplicações se encontram numa plataforma estável com comunicações e interfaces necessárias e confiáveis.

A infraestrutura de TI suporta a performance e a disponibilidade das aplicações, bem como a integridade, a segurança e a confidencialidade dos dados.
Muitos dos processos necessários para assegurá-los dependem de alguns aspectos da gestão da infraestrutura, tais como segurança da informação, balanceamento de carga, backup e restauração, recuperação de desastres etc.
Apêndice M12 – pensamento crítico
Esse apêndice discorre sobre o conceito de pensamento crítico para otimizar de maneira proativa a abordagem a ser seguida de forma a assegurar qualidade e conformidade de sistemas computadorizados.

O desperdício de tempo e esforço em atividades sem adição de valor pode levar ao trabalho insuficiente ou excessivo, com potenciais custos adicionais e atrasos, e pode reduzir o foco em atividades de qualidade mais valiosas e essenciais.

A utilização de tabelas rígidas, ou templates demasiadamente prescritivos que originam de procedimentos que não permitem abertura para adaptação a cada caso, impede o pensamento crítico e pode inibir a inovação e a adoção de novas tecnologias.

GAMP5 promove abordagem baseada em risco para assegurar a adequação ao uso pretendido.

Alguns profissionais não aplicam uma reflexão suficiente para assegurar que a abordagem que estão na iminência de adotar poderia ser personalizada e proporcional às necessidades de cada sistema.

Um exemplo prático de pensamento crítico, ou racional (termo que costumamos utilizar também) é classificar CDS (Chromatography Data System) como categoria 4 – configuração, conforme sugerido pelo GAMP edição atual na tabela do item 12.1 como exemplo típico de como pode ter seu ciclo de documentos otimizado.

Classificá-lo como categoria 4 do GAMP faz sentido quando existem cálculos customizados ou interface com LIMS (Laboratory Information Mangament System), por exemplo.

Porém este mesmo sistema é com frequência instalado utilizando suas funções de prateleira, standard. Neste caso, a abordagem de ciclo de vida poderia ser diferente.

Quando classificamos um sistema como categoria 4 do GAMP, é usual que os procedimentos requeiram uma Especificação Funcional. Quando o CDS é utilizado em sua função standard, ou seja, sem interfaces e sem cálculos customizados, por que produziríamos uma Especificação Funcional? Para replicar ou repetir menções que já constam no manual do fabricante? Perda de tempo, não adiciona valor.

É este tipo de pensamento crítico que a versão atual do GAMP5 procura incentivar.
Deve existir uma razão de se produzir documentos e testes que adicionem valor, que foquem na qualidade de produto, na saúde do paciente ou consumidor e na integridade de dados, ou seja, no que realmente importa.

Por outro lado, não se deve utilizar o pensamento crítico como uma ferramenta para desconsiderar algum entregável do ciclo de validação, por falta de tempo de projeto ou custo que não foi previsto.
O pensamento crítico deve, também, ser utilizado para planejar os esforços aplicados aos testes.

Enfim, a nova versão do Guia GAMP5 incentiva a liberdade de utilização de racional, entretanto, devemos utilizar estas orientações de forma responsável e comprometida com a qualidade.

As decisões devem ser tomadas em equipes multidisciplinares e registradas em documentos que expliquem tal estratégia, como por exemplo, o Plano de Validação.
Apêndice D1 – especificação de requisitos
A extensão e detalhes dos requisitos devem ser baseados no risco, complexidade, inovação e devem ser suficientes para suportar a Análise de Riscos.

Documentos existentes sobre o sistema devem ser usados para determinar a extensão dos detalhes, quando aplicável.
Apêndice S2 – registros eletrônicos de produção
Descreve o conceito e abordagem high level para determinar requisitos para registros eletrônicos de produção (manufatura).

Há menções sobre revisão pela exceção (RBE: review by exception), adoção de tecnologia em nuvem, blockchain, disponibilização de dados em tempo real, e melhor clareza quanto aos dados em trilha de auditoria e sua revisão.

Ferramentas, ao invés de documentos

Esse é um ponto crítico que pode impactar o negócio positivamente. A nova edição do Guia GAMP5® incentiva e recomenda a utilização de ferramentas de software para suportar práticas Agile que podem trazer oportunidades para melhorar abordagem da documentação tradicional que apresenta barreiras e, potencialmente introduz riscos de não-conformidade (papel aceita tudo e de difícil rastreabilidade).

Ferramentas de software para suportar a validação permitem que o time escreva requisitos funcionais e de qualidade de forma eficiente para iniciar o processo ágil, gerenciando o ciclo de vida de cada requisito, de forma independente. Um conjunto de requisitos, pode formar uma release.

Testes são excelentes exemplos de onde ferramentas de software podem prover oportunidades para melhorar performance das entregas.

Alto volume de testes executados de forma mais eficiente, com menos recursos humanos.

Uma ferramenta pode fornecer rastreabilidade automática sem a necessidade de criar um documento de matriz manualmente.

A rastreabilidade pode ser obtida de forma dinâmica e demonstrada pela ferramenta, que, se necessário, pode gerar relatórios em etapas-chave (releases parciais).

 

Nota: a FIVE Validation desenvolveu um sistema de geração e gerenciamento de validações que segue framework ágil, com validações 5x mais rápidas e que atende os requisitos da ANVISA, FDA e EMA.

Clique para saber mais: Validação sem papel.

O que é CSA FDA?

CSA significa Computer Software Assurance e se trata de um guia FDA para assegurar qualidade de softwares utilizados ao longo do processo de fabricação, e garantia de qualidade de produtos médicos.

Em resumo, alguns pontos importantes sobre CSA, versão draft lançada em Set/2022:

  • Não considera risco ao paciente ou consumidor, nem integridade de dados – somente risco ao processo;
  • Não considera probabilidade de ocorrência e detectabilidade na composição do risco;
  • Não incentiva ações mitigatórias que não estejam relacionadas com escopo de testes (como orientações em procedimentos ou novos desenvolvimentos) para diminuição de riscos;
  • A determinação do risco é informada diretamente no requisito.

Testes CSA e GAMP5®

Apesar de as orientações dos Guias GAMP5 e CSA serem diferentes, há uma sinergia interessante entre ambas as literaturas no que diz respeito ao escopo de testes. Os tipos de testes guiados e não guiados sugeridos ou recomendados em ambos os guias são similares.

Testes não devem estar limitados a um protocolo detalhado e prescritivo incluindo passo-a-passo. O uso de testes exploratórios e outras técnicas não guiadas é encorajado para ampliar a cobertura de testes e melhorar a detecção de defeitos.

Os testes não roteirizados devem ser documentados e podem então ser aproveitados como parte da etapa de verificação geral.

O uso de testes automatizados traz benefícios para a cobertura das verificações, repetibilidade e velocidade na sua execução.

Algumas abordagens de testes que podem ser utilizadas:

Unscripted Testing (testes não guiados) – usualmente produzidos por equipes de projeto

Não significa sem documentação dos testes.

Os testes não roteirizados devem ser documentados e podem então ser aproveitados como parte da etapa de verificação geral.

A segunda edição do GAMP5 incentiva que os testes não devam estar limitados a um protocolo detalhado e prescritivo, passo a passo. Portanto, passa a ser viável, a explicação da estratégia de testes que o time do projeto está aplicando. Essa abordagem pode ser justificada no Plano de Validação ou Protocolo de Testes.

Os testes que estão previstos pelo time de projeto não precisam mais ser ignorados por falta de robustez em sua evidência. Contudo, ainda é necessário capturar alguns dados que demonstrem que o teste foi/será realmente executado, como: quem executou, data, problemas enfrentados na execução do teste, se passou ou falhou. Entretanto, o script de teste não precisa ser detalhado, principalmente testes relacionados com transações ou funcionalidades que não são críticas e tem riscos classificados como baixo.

Não se trata de passar a aceitar qualquer falta de robustez na documentação por parte da equipe de projeto, mas se o trabalho em time for possível, será que orientação na utilização de melhores práticas documentais pode ser suficiente para aproveitar tais testes?

Por que então não repetir ou deixar os testes críticos para as fases formais de qualificação de instalação, operação e desempenho para que a qualidade seja assegurada?

Unscripted testing pode ser: ad-hoc, error-guessing e exploratórios.

Ad-hoc significa teste ou cenário que não foi/será planejado com antecedência.

Error-guessing é uma técnica de concepção de testes em que os casos de teste são derivados com base no conhecimento do executor que considera falhas passadas ou no conhecimento geral dos modos de falha.

Testes exploratórios são os testes que são baseados na experiência do executor que define os cenários e executa espontaneamente de acordo com seus conhecimentos relevantes existentes.

A realização de testes não guiados reduz o tempo de escrita de scripts, reduz os erros de elaboração, e acelera os relatórios com o bônus de proporcionar treinamento na operação do sistema aos usuários.

A integração bem-sucedida de testes não guiados na sua estratégia de validação significa um pensamento mais crítico, mas menos documentação, poupando, em última análise, tempo, esforço e custo.

Scripted Testing (testes guiados)

Testes em que as ações do executor são prescritas por instruções escritas num caso de teste.

Testes guiados robustos: esforços de teste com scripts nos quais o risco do sistema de gestão ou automação inclui provas de repetibilidade, rastreabilidade aos requisitos, e comprovação robusta da execução do teste.

Testes com scripts limitados: abordagem híbrida de testes com e sem scripts que é adequadamente dimensionada de acordo com o risco que a implementação do sistema trás.

Esta abordagem pode aplicar testes com scripts para características ou operações de alto risco e testes sem scripts para itens de baixo e médio risco, como parte do mesmo esforço de garantia. 

Ferramenta de Software que atende ambas as áreas: Projetos e Qualidade

Imagine que existe um fornecedor que consegue fornecer um software de produção de documentos de validação robustos, mas com agilidade que as áreas de TI, Engenharia ou fornecedor necessitam.

Imagine ainda que esta mesma ferramenta é capaz de gerenciar requisitos, riscos e testes de maneira integrada, para as funcionalidades BPx (impacto em qualidade) e não BPx relevante?

Clique para saber mais: Validação sem papel.

Conclusão – Quebra de Paradigma

GAMP5 primeira edição inovou em 2008 trazendo o racional de focar as atividades da validação naquilo que realmente importa, utilizando o gerenciamento de risco de qualidade como forma de decisão de onde focar os esforços. Na época, a comunidade farmacêutica e de produtos médicos levou um tempo para absorver o que este guia estava realmente trazendo de benefícios.

Tudo leva a crer que a segunda edição veio para continuar a abordagem de basear as decisões em riscos, porém buscando abertura à inovação e agilidade, tirando alguns preceitos de templates ou procedimentos muito robustos. É definitivamente, uma quebra de paradigma que provavelmente o mercado vai levar um tempo para ‘digerir’ os novos benefícios.

Quem sair na frente nesta adoção, terá mais tempo de economia e agilidade na conformidade dos seus processos.

O objetivo é evitar que a validação seja a “âncora pesada” do negócio que impede a inovação. Já é uma realidade para o time da FIVE Validation investir mais tempo nos alinhamentos entre os times, engajando-os a adotar melhores práticas, do que exatamente produzindo documentos de validação.

CLIQUE AQUI para agendar uma reunião e descobrir como o time da FIVE Validation consegue produzir documentos 6x mais rápidos do que fazia em 2018, no processo baseado no papel.

 

GAMP5® é um guia que tem seus direitos intelectuais reservados à ISPE. Disponível para aquisição no site https://ispe.org/.

 

Sobre a autora

SILVIA MARTINS é engenheira eletricista, 20 anos de experiência na área de Validação de Sistemas. Treinada na Inglaterra em GAMP5 e FDA 21 CFR Part11, na Alemanha em validação de SAP e na Dinamarca em Data Integrity e Data Governance. Coordenou grupo que elaborou o 1º Guia para Validação de Sistemas Computadorizados em conjunto com a ANVISA, Manual de Integridade de Dados e Manual de Qualificação de Fornecedores em Nuvem, ambos no Sindufarma. Ministrou cursos de capacitação para os inspetores de VISA e ANVISA. CEO e co-fundadora da FIVE Validation.