Manutenção de Estado de Validado dos Sistemas, o grande desafio das empresas de Ciências da Vida
Conheça o GO!FIVE® e a Validação Paperless
As empresas de Ciências da Vida enfrentam uma série de desafios no desenvolvimento e manutenção de seus sistemas. Um dos maiores desafios é manter o estado de validado, principalmente dos softwares de gestão, o que significa garantir que eles funcionem de forma eficiente e confiável a todo momento. Isso é essencial para garantir a qualidade e a segurança dos produtos farmacêuticos e produtos médicos que são produzidos por essas empresas.
O objetivo 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 pandemia acelerou a pesquisa e o desenvolvimento de novas terapias e vacinas, o que exigiu uma maior colaboração e troca de informações em toda a cadeia de valor da indústria farmacêutica e produtos médicos, o que só foi possível graças às tecnologias digitais avançadas. Entretanto, a transformação digital, majoritariamente em nuvem, trouxe um aumento significativo no número de sistemas que foram implementados nos últimos anos e que recebem constantes atualizações e melhorias nas soluções e tecnologias envolvidas. Por isso, a manutenção de estado validado tem sido um verdadeiro desafio.
Para enfrentar esses desafios, as empresas de Ciências da Vida necessitam ter um processo rigoroso de gerenciamento de mudanças e, dependendo do seu tamanho e porte, uma equipe dedicada à manutenção do estado validado dos sistemas deve ser considerada. É importante que essas empresas trabalhem com fornecedores confiáveis e experientes no segmento farmacêutico, a fim de garantir que as atualizações e melhorias sejam realizadas de forma eficiente e segura, incluindo boas práticas.
Deployments de novas versões nos ambientes de qualidade e produção
Deployment é o termo utilizado para indicar ação de instalação ou de implementação inicial ou atualização de um sistema. Em sistemas baseados na nuvem, atualizações são geralmente escopo do fornecedor que se não for alinhado com as melhores práticas regulatórias farmacêuticas, podem fazer o deployment sem prévio aviso nos ambientes de qualidade e produção simultaneamente, não permitindo janela de tempo para equipes de validação analisar as mudanças e providenciar atualização da documentação para autorizar migração desta atualização para o ambiente de produção.
Release notes
Release notes ou notas de versão são documentos distribuídos pelos fornecedores com produtos de software ou produtos de hardware, quando estão para ser lançados ou atualizados. Espera-se que os vendors contemple o conteúdo de forma que possa ser interpretado por usuários de qualquer área de atuação que esteja relacionada com o uso da plataforma, evitando linguagens demasiadamente técnicas.
Em posse de um bom release notes, o usuário tem condições de analisar se o conteúdo do update impactará no estado validado do sistema, ou seja, se a documentação continuará vigente (ou não) em caso de atualização do sistema. Independente da decisão, a análise deve ser documentada utilizando um CM (Controle de Mudanças).
No caso de ser decidido pela adoção de uma nova funcionalidade, uma ‘mini validação’ deve ser conduzida para estudar o impacto da mudança que pode ser documentada na Análise de Riscos Funcional e definir o escopo de testes.
O que é FDA Audit Readiness?
É o termo utilizado para sistema da qualidade de padrão elevado que está pronto para uma inspeção da agência reguladora sem quaisquer preparações importantes.
Agora, vamos exemplificar como aplicar este termo à um estudo de validação de um sistema de gestão implementado em uma empresa que regularmente aplica novas regras de negócios para adaptar-se à um mercado cada vez mais dinâmico.
Neste exemplo, vamos supor que esta empresa adotou um ERP em nuvem que lança novas funcionalidades ou atualizações a cada dois ou três meses. Imagine os esforços para manter o estado validado deste sistema e todos os outros da empresa.
Para cada mudança BPx relevante (impacto nas boas práticas), um conjunto de requisitos, riscos e testes devem ser desenvolvidos para conduzir a validação da mudança em questão e seu respectivo impacto. Essa documentação gerada normalmente é atrelada e anexada ao controle de mudança (e não à validação original).
O auditor pode questionar algo que foi alterado e que não se encontra mais na documentação original. É relativamente fácil e prático ‘versionar’ alguns documentos de validação originais para incluir as mudanças, assim como: Plano de Validação, URS e Análise de Riscos.
Mas as empresas normalmente não conseguem fazer o mesmo com os scripts de testes, porque todo seu conteúdo e respectivos passos estão em um único documento. Quando este é atualizado (salvar como), testes não alterados ficariam sem aplicação de testes nesta nova versão.
É por causa disso que a maioria dos profissionais de validação acabam gerando um novo script de testes para cada mudança, alterando o status do protocolo original, deixando vigente uma série de anexos que podem ficar desatualizados também com abertura de novos CMs.
Resumindo, com o passar do tempo, o estudo de validação fica todo fragmentado, não havendo uma versão atualizada consolidada contendo testes que foram realizados na validação original. O ideal é que fosse possível ter um único script de teste de QO, por exemplo, referente às funções que nunca sofreram alterações desde a implementação junto com as mudanças em um único estudo mostrando a rastreabilidade e controle de versão de cada teste, incluindo respectivas revisões e aprovações antes (pré) e depois (pós) execução dos testes.
Você já tinha parado para pensar que existe um sistema de gestão de validação onde é possível gerar conjunto de documentos por CM ou imprimir todo o estudo de validação atualizado em formato PDF com itens atualizados acoplados ao estudo original?
Pois bem, nós desenhamos essa função para você usufruí-la no software GO!FIVE®. CLIQUE AQUI para ver como abordagem de validação baseada em itens agrega valor na manutenção de estado validado.
Controle de Mudanças
O primeiro passo para dar andamento em uma mudança é abrir o documento de Controle de Mudanças de acordo com o procedimento da empresa. Normalmente, as mudanças da área de Sistemas Computadorizados também são relatadas no POP (Procedimento Operacional Padrão) de CM (Controle de Mudanças), ou seja, pode não ser controlada por formulário de CM específico. De qualquer forma, o conteúdo deve descrever as ações a serem tomadas para execução da alteração ou correção do sistema após o término da validação. A criticidade da mudança deve determinar a extensão e a verificação das atividades e documentações necessárias sempre baseada na Análise de Riscos e na complexidade da alteração a ser implementada.
O procedimento de Controle de Mudanças da empresa deve contemplar o gerenciamento e controle de todas as alterações relacionadas a sistemas computadorizados validados com o objetivo de assegurar que estes permaneçam neste estado.
As mudanças necessárias em um sistema computadorizado validado devem ser aprovadas por equipe multidisciplinar que envolva a Garantia de Qualidade. Em caso de mudanças emergenciais, estas devem ser registradas e, ainda assim, analisadas quanto ao seu impacto e aprovadas pela Garantia de Qualidade. Critérios para considerar casos emergenciais devem estar descritos no procedimento de controle de mudanças da empresa.
Testes de Regressão
Testes de Regressão consiste em uma técnica de aplicação de testes à versão mais recente do software, para garantir que não surgiram novos defeitos em componentes críticos já testados. Se surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu. Quando a mudança é aplicável para mais de um site/país que não é requerida para todas unidades, os testes de regressão também são importantes para verificar que não houve impacto nos demais sites.
Para desafio da nova versão da aplicação devido à uma alteração, o Controle de Mudança deve prever Testes de Regressão. O CM deve prever Análise de Riscos Funcional para definir o impacto da atualização nas funções críticas do sistema, e assim direcionar testes de regressão quando existe a possibilidade de impacto indireto das alterações com funções críticas ‘inalteradas’.
Normalmente, há muitas dúvidas no conteúdo destes testes, mas basicamente, fica mais fácil se definirmos que riscos classificados como ‘alto’ e ‘médio’ na Análise de Riscos realizada durante a validação, como sendo os testes que tem que estar previstos como Testes de Regressão, pois são os pontos mais frágeis no sistema. Assim, minimamente os testes referentes à própria mudança, adicionados aos testes de regressão garantirão a entrada da mudança em ambiente de produção, assegurando que os riscos altos e médios estão sob controle, demonstrando robustez no processo, sem necessidade de repetir completamente a etapa de qualificação de operação do sistema para cada vez que procede uma mudança, o que seria inviável no dia-a-dia.
CAB (Change Advisor Board)
Para implementação e/ou melhoria do processo de gerenciamento das mudanças, recomenda-se que seja formada equipe que seja responsável por aprovar e gerenciar as mudanças, suportando análise de impacto e priorização. Normalmente faz parte da equipe: gestor da CAB, especialistas técnicos IT e/ou OT (automação), usuários, Engenharia, Manutenção, Garantia da Qualidade e/ou Validação (BPx).
Os membros da CAB são responsáveis por entender as necessidades e impactos da mudança pelas perspectivas técnica, negócio e Qualidade. Reuniões rápidas semanais para tomadas de decisões são importantes. Os membros da CAB também são responsáveis por monitorar o processo de desenvolvimento, testes e aprovação de migração da mudança de um ambiente para outro.
Controle das Mudanças por Sistema – muitas mudanças!
CAB deve envolver mudanças de perfis, funcionais, hardware, software, configurações, patches, atualizações, etc. É uma prática de ITIL (Information Technology Infrastructure Library) – conjunto de boas práticas para governança de TI. Dependendo do tamanho da empresa, algumas medidas de controle têm que ser implementadas para adequada gestão das mudanças que podem ser muito numerosas, tais como: a.) determinar regra de entrada da mudança no comitê somente após aprovação do custo e b.) utilizar um sistema para gestão das mudanças desde a solicitação da alteração até a confirmação do adequado funcionamento da mesma.
O sistema deve gerenciar o workflow (fluxo de aprovações) de cada mudança funcional e perfil que deve ser controlado minimamente pelas seguintes informações: ID (número para identificação da mudança), setor/área, equipamento e/ou sistema, system owner (dono do sistema), conteúdo da mudança, classificação relevância BPx, impacto documental, impacto produtivo, prazo de implementação e campos para follow-up com data.
Revisão Periódica
Independentemente do tratamento das mudanças, as validações dos sistemas devem ser revisadas periodicamente. No geral, nesta área, evitamos o termo ‘revalidação’, e normalmente utilizamos a atividade de Revisão Periódica para proceder a verificação da atualização da validação do sistema para, ao fim desta tarefa, checar se o sistema continua com o status de validado.
A revisão periódica de sistemas computadorizados deve ser realizada com o objetivo de garantir que possíveis mudanças de processo, de componentes do sistema ou de manutenções, por exemplo, não tenham impactado no seu estado de validado. Deve ser determinado um cronograma de revisões para todos os sistemas.
A frequência de revisão das validações deve ser baseada na criticidade do sistema. Não é produtivo estabelecer a mesma frequência de revisão periódica para todos os sistemas da empresa, visto que alguns deles são mais dinâmicos e mais instáveis que outros. É interessante utilizar abordagem da frequência variável para o mesmo sistema e mais interessante ainda, definir a primeira revisão periódica relativamente próxima ao término da validação do sistema (aproximadamente 6 meses), justamente para estudar a estabilidade pós implementação. Se esta primeira revisão periódica for conduzida sem intercorrências, e o sistema se mostrar estável, mudanças e administração de usuários e backups atualizados, a revisão periódica pode ser postergada para 1 ano e assim ter a frequência aumentada na próxima, dependendo do resultado deste último processo de revisão periódica.
A revisão deve levar em consideração vários aspectos, como:
- Documentação de validação do sistema
- Documentação da revisão anterior
- Controles de mudanças emitidos
- Desvios ocorridos
- Procedimentos operacionais
- Controle de acesso ao sistema
- Execução correta do backup do sistema
- Status do sistema computadorizado (ex. espaço em disco, utilização RAM)
- Status dos arquivos de histórico e trilhas de auditoria
Caso seja encontrado algum problema no sistema, um plano de ação deve ser estabelecido.
Durante avaliação da documentação de validação, é importante dar especial atenção à Análise de Riscos Funcionais e verificar se os cenários de riscos, classificações e mitigações que foram necessários na ocasião da implementação ainda estão vigentes e se são necessários. Novos cenários de riscos podem surgir se mudanças não foram bem controladas. Neste caso, é necessário revisar a Análise de Riscos e assim prosseguir como se fosse uma ‘mini validação’ buscando novas mitigações (controles para baixar os novos riscos) e testes que comprovem que a validação está de acordo com o processo atual. O Relatório de Revisão Periódica não deve ser finalizado até que todas as pendências estejam sanadas.
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.
