O que é Validação de Sistemas Computadorizados?

A Validação de Sistemas Computadorizados é composta por uma série de documentos que asseguram que softwares, equipamentos, utilidades, infraestrutura ou planilhas estejam em conformidade com o processo, visando garantir a segurança do paciente ou consumidor, a qualidade do produto e a integridade dos dados.

De forma mais simples, comprova que o sistema opera de acordo com o uso para o qual foi projetado (uso pretendido), de maneira consistente e com qualidade.

“Se não está registrado, é apenas um rumor”

Essa afirmação ressalta a importância crucial da validação. Quando um processo, sistema ou dado passa pelo processo adequado de validação, sendo oficialmente registrado e aprovado, este sistema adquire confiabilidade e o status ‘validado’.

A boa notícia é que regulamentos em todo o mundo são harmonizados, então as regras são semelhantes em órgãos reguladores como FDA, EMA, OMS e ANVISA.

Preciso validar todos os sistemas em uma indústria regulada?

A resposta é não! Nem todos os sistemas requerem validação, mas aqueles que são BPx relevantes (impacto em produto, qualidade, segurança do paciente/consumidor e integridade de dados).

Leia mais...
Por exemplo, em um laboratório de pesquisa & desenvolvimento ou local de fabricação, é provável que haja diversos sistemas BPx relevantes devido à sua conexão direta com o produto.

Por outro lado, se a sua empresa opera com a distribuição, é necessário validar os sistemas aplicáveis. Alguns exemplos são WMS (Sistema de Gestão de Armazéns), SGQ (Sistema de Gestão da Qualidade) e sistemas de monitoramento de temperatura, assim como planilhas eletrônicas, se aplicáveis.

Como validar?

No Brasil, a Validação de Sistemas Computadorizados é uma exigência da ANVISA (Agência Nacional de Vigilância Sanitária), assim como de vários outros importantes órgãos reguladores pelo mundo.

Em 2020, a ANVISA publicou um guia atualizado sobre as melhores práticas aplicadas a sistemas computadorizados (clique e faça o download). Esse material foi inspirado no GAMP5® primeira edição, e a proposta foi internalizar o documento de modo a facilitar a compreensão das empresas reguladas acerca das diretrizes propostas por esse guia.

Leia mais...
O guia GAMP5® por sua vez, foi desenvolvido pela ISPE® (International Society of Pharmaceutical Engineering). A primeira do GAMP5 foi lançada em 2008 e em 2022, foi lançada a segunda edição da versão 5 da publicação, trazendo insights que podem ser muito úteis ao negócio.

A estratégia de validar baseado em risco ("A Risk Based Approach to Compliant GxP Computerized Systems") continua sendo o eixo central do guia. GxP é um termo geral para aplicação de boas práticas (good practices). O ‘x’ indica a área em que as boas práticas estão relacionadas (fabricação, distribuição, pesquisa clínica, laboratório etc.).

A validação baseada em riscos é esperada pelos órgãos reguladores. Espera-se que os riscos classificados como níveis ‘médio’ e ‘alto’, sejam previstas ações mitigatórias. Caso a mitigação ou upgrade não seja possível, a troca do sistema deve ser considerada principalmente para riscos altos.

Tanto o GAMP5®, como o Guia da ANVISA detalham o ciclo de vida exato necessário para cada tipo de sistema, seja categoria 1 (infraestrutura), categoria 3 (prateleira), categoria 4 (configurado) e categoria 5 (customizado).

Mesmo quando uma indústria opta por adquirir pacotes de documentos de Validação ou Qualificação disponibilizados pelos próprios fabricantes de equipamentos ou sistemas, é importante lembrar que esses pacotes são parciais, ou seja, cabe à indústria a responsabilidade de revisar o que lhe foi entregue e ainda desenvolver parte do ciclo que resta para concluir a Validação ou Qualificação.

Nestes casos a FIVE também se apresenta como parceira da indústria, colocando-se à disposição para auxiliá-lo na revisão técnica da documentação disponibilizada pelo fornecedor, bem como para a conclusão do ciclo de Validação ou Qualificação.

Ciclo de Entregáveis de um sistema categoria 4 do GAMP5®

A lista de documentos (ou entregáveis) a seguir é comum em um ciclo de validação. No entanto, após o lançamento da segunda edição do guia GAMP5®, ficou evidente que os nomes dos entregáveis, principalmente na fase de testes, não são estritamente obrigatórios nem prescritivos; o conteúdo é o aspecto mais relevante.

Em algumas empresas que adotam abordagens ágeis, os requisitos podem ser denominados 'estórias'. Além disso, para determinados sistemas, as fases de qualificação de instalação, operação e desempenho podem ser referidas como: Unit Testing Configuration, Functional Testing, UAT (User Acceptance Testing), Acceptance Testing (incluindo FAT/SAT), Module Testing, Integration Testing, System Integration Testing (SIT), Data Migration Testing, ou Requirements Testing.

A Especificação de Requisitos (ou Requerimentos) do Usuário define de forma clara e objetiva todos os requisitos necessários que um sistema computadorizado deve atender e pode ser utilizado como um documento ou entregável contratual. Geralmente é elaborado pelo usuário, porém é interessante que seja elaborado em equipe multidisciplinar, sendo revisado e aprovado pelos usuários envolvidos, incluindo a Garantia da Qualidade.
deve ser realizada uma análise de risco inicial com base no entendimento dos processos e avaliações dos riscos do negócio, nos requisitos do usuário, nos requisitos regulatórios e áreas funcionais conhecidas. Os resultados desta avaliação de risco inicial devem incluir a decisão sobre se o sistema é regulado pelas BPx (avaliação de BPx). Quando há impacto, essa avaliação é referenciada no Plano de Validação. .
o Plano de Validação registra as normas, metodologia e equipe envolvida para garantir a qualidade através do ciclo de vida de desenvolvimento de um sistema, e estabelece a adequação de seu desempenho. O planejamento de validação deve ser iniciado na primeira oportunidade possível, podendo ser revisto e atualizado nos estágios subsequentes do projeto. É esperado que o Plano de Validação explique a complexidade do projeto e seu desmembramento. Quando possível, a documentação técnica de apoio ao projeto utilizada durante o trabalho de validação deve estar citada aqui, sendo que deve ser mantido todo o histórico de revisões e aprovações. Para adoção do framework Ágil na validação, é interessante que a estratégia de liberação por sprints e configurações estejam detalhadas no plano.
A especificação funcional é um tipo de entregável de especificação que deve definir clara e completamente o que o sistema computadorizado faz e quais funções e instalações são fornecidas para atender as necessidades descritas nos Requisitos do Usuário. A especificação funcional tipicamente é produzida por um fornecedor, seja ele interno ou externo à empresa e deve ser revisada e aprovada pelo contratante, podendo ser considerado um documento contratual. Para sistemas de prateleira, esse entregável pode ser substituído pelo manual do sistema.

O principal objetivo deste entregável é proporcionar uma explicação clara sobre o processo de desenvolvimento das configurações, customizações e interfaces do sistema e quaisquer interações com outros sistemas. A maior fonte de incerteza com relação a este entregável geralmente está relacionada ao nível de profundidade e detalhamento necessários. No entanto, é prático identificar o que deve ser documentado de forma a capacitar um profissional técnico com o mesmo conhecimento a manter ou modificar as configurações sem a necessidade de consultar os especialistas que estiveram envolvidos na implementação original do sistema.
é um outro tipo de entregável de especificação que deve detalhar o desenho e os requisitos relacionados aos componentes de infraestrutura tecnológica na qual o sistema computadorizado será instalado para uso, seja esta infraestrutura em nuvem ou não. Este documento ou entregável deve contemplar as especificações previstas e apropriadas para um sistema, contemplando todos os componentes e softwares e hardware que compõem a infraestrutura. A Especificação Técnica é baseada nos requisitos técnicos necessários para a instalação e configuração de um sistema computadorizado de forma a garantir sua integridade, segurança e desempenho em seu ambiente de teste e operacional.
O gerenciamento de riscos é a estratégia principal prevista no GAMP5, tanto na primeira como na segunda edição, que inclui análise dos riscos causados pelo sistema no processo que está gerenciando, incluindo potenciais ações mitigatórias (ou medidas de controle). Riscos mais altos podem requerer maior nível no rigor dos testes e nível de documentação. A comprovação de implementação de controles continua pelo ciclo de vida da validação e espera-se que os riscos médios (benéficos) e altos (mandatórios) estejam mitigados e verificados na fase de testes, de forma a evidenciar cumprimento, para que o sistema ganhe o status ‘validado’.
o escopo deste entregável é verificar o atendimento do sistema aos requisitos da URS e especificações do sistema. Verificação documentada de que o projeto proposto para as instalações, sistemas e equipamentos é adequado para o propósito pretendido. Aplicável para sistemas Categoria 4 e 5 do GAMP5®/ANVISA.
o protocolo de testes é o documento que norteia a fase da comprovação da qualidade e segurança do sistema computadorizado. Pode incluir o escopo, plano de testes, estratégia, definição de amostragem, participantes, critério de aceitação e como serão tratadas eventuais falhas ou quaisquer mudanças durante a fase de teste.
o objetivo é verificar e documentar se os componentes do sistema estão combinados e instalados de acordo com as especificações, documentação do fornecedor e requisitos locais e globais. Também pode incluir evidência sobre aceite das documentações do fornecedor, incluindo especificações, manuais e desenhos. Para sistemas e equipamentos de produção ou automação industrial, esta fase também pode ser chamada de Qualificação de Instalação (QI).
este relatório resume os resultados das atividades dos estudos de validação realizados no sistema durante a fase de Testes de Configuração.
o protocolo de testes é o documento que norteia a fase de comprovação do sistema quanto as operações de acordo com as especificações escritas e pré-aprovadas em toda sua gama de operações. Pode incluir o escopo, plano de testes, estratégia, definição de amostragem, participantes, critério de aceitação e como serão tratadas eventuais falhas ou quaisquer mudanças durante a fase de teste.
este documento tem o objetivo de referenciar, verificar e documentar as condições de operação do sistema e se este cumpre satisfatoriamente com os requisitos pré-definidos para sua operação. Este script de testes deve comprovar o atendimento à especificação funcional, comprovar a existência de procedimentos aprovados para as funcionalidades com impacto em BPx, segurança e manutenção do sistema, comprovar a compatibilidade de seus componentes com as funcionalidades a serem qualificadas, possibilitar a verificação da capacidade tecnológica, possibilitar a verificação de conformidade com as normas de BPx e outras normas técnicas aplicáveis, demonstrar que o sistema encontra-se funcionando corretamente através de desafios documentados com base na análise de riscos. Para sistemas e equipamentos de produção ou automação industrial, esta fase também pode ser chamada de Qualificação de Operação (OQ).
este relatório resume os resultados das atividades dos estudos de validação realizados no sistema durante a fase de testes de funcionais. Pode ser elaborado para todo o sistema ou de forma parcial, permitindo no framework Ágil, que parte do sistema seja liberado para uso em produção em conformidade (go live).
o protocolo de testes é o documento que norteia a fase de comprovação do sistema quanto as operações definidas nos requisitos. Os testes realizados na fase anterior não são reexecutados de forma integral nesta fase.
os testes desta fase têm como objetivo referenciar, verificar e documentar que o sistema computadorizado cumpre satisfatoriamente com os requisitos pré-definidos pela Especificação de Requerimentos do Usuário e/ou Especificação Funcional e demonstra aderência com o uso pretendido. Além disso, tem o objetivo de comprovar a existência de procedimentos aprovados para as funcionalidades com impacto em BPx, possibilitar a verificação de conformidade com as normas de BPx e outras normas técnicas aplicáveis, possibilitar o gerenciamento de segurança. Para sistemas e equipamentos de produção ou automação industrial, esta fase também pode ser chamada de Qualificação de Desempenho (QD).
este relatório resume os resultados das atividades dos estudos de validação realizados no sistema durante esta fase de teste.
a Matriz de Rastreabilidade estabelece a relação entre dois ou mais entregáveis que são desenvolvidos durante o processo de validação. A Matriz assegura que requisitos sejam atendidos e que possam ser rastreados às respectivas configurações e/ou elementos de desenho do sistema e, também, ao teste que verifica que os requisitos foram atendidos. Uma matriz também pode permitir maior efetividade no gerenciamento dos riscos, facilitar a avaliação do potencial impacto e gerenciamento de risco para uma mudança pretendida. A Matriz de Rastreabilidade deve ser aprovada e integrada ao ciclo de vida do sistema.
o Relatório de conclusão da validação do sistema deve ser elaborado levando-se em consideração os resultados obtidos nos testes aplicados nas diferentes fases de testes. Devem ser considerados ainda os requisitos para atendimento às normas regulatórias aplicáveis, conforme estratégia estabelecida no Plano de Validação. A partir da data de aprovação do relatório final de validação, o sistema deve estar sujeito a controle de mudanças para quaisquer modificações ou implementações que porventura se façam necessárias.

O fluxograma abaixo foi inspirado na figura 11.7 do guia GAMP5 segunda edição: abordagem baseada em risco para sistemas configurados (categoria 4)

Framework Ágil na validação

Uma prática muito comum, principalmente pelo demasiado trabalho resultante da validação em papel, ou validação manual digital (baseada em editor de texto), é a utilização do modelo waterfall (em cascata) para entrega de projetos.

Leia mais...
O modelo waterfall não é exatamente um problema, há vários projetos bem-sucedidos neste formato, a questão é a adaptação e a flexibilidade para mudanças. ISPE GAMP5® como mencionado acima orienta as boas práticas para sistemas BPx relevantes, e em sua nova versão incorporou diversos conceitos do framework Agile, suportando o uso de abordagens incrementais, iterativas e evolutivas para o desenvolvimento de produtos de aplicações personalizadas. Agile é um processo controlado, e assim como na abordagem Waterfall, se executado mal e com falta de controles, é inaceitável.
 

Ferramentas ao invés de documentos

Esse é um ponto crítico que pode impactar o negócio positivamente. A segunda 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.

Leia mais...
Papel aceita tudo e é de difícil rastreabilidade e o formato eletrônico utilizando ferramenta de gestão de documentos pode dar oportunidade ao executor de teste alterar o script que foi aprovado anteriormente.

Uma ferramenta que já está adaptada ao framework Agile na validação, em conformidade com FDA, EMA, OMS e ANVISA, é o GO!FIVE®, sendo uma excelente opção para projetos ágeis:

• Criar/definir os itens por linha da matriz

• Criação de pacotes de itens (requisitos, riscos, especificação ou testes)

• Liberação parcial (por sprint, por módulo, por processo, por produto etc.)

• Um Plano de Validação e vários Relatórios Parciais

Clique aqui e saiba mais sobre o sistema que traz o compliance Agile e que empodera equipes.

Clique aqui para descobrir como podemos trabalhar juntos.

 

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