Validação de eQMS: uma abordagem baseada no risco para pequenas equipas da qualidade

Comprou, ou está prestes a comprar, um sistema eletrónico de gestão da qualidade e alguém lhe pediu o plano de validação. A equipa da qualidade tem três pessoas. A última validação de sistemas informáticos que alguém daqui viu foi um dossier de argolas com capturas de ecrã de um instrumento de laboratório, e ninguém quer repetir isso para um sistema que irá conter todos os procedimentos operacionais normalizados (SOP), CAPA e registos de formação da organização. Este artigo apresenta uma abordagem proporcional para a validação de eQMS: o que o Anexo 11 das BPF da UE e a ISO 13485 exigem efetivamente, como a segunda edição do GAMP 5 e os princípios de computer software assurance reduzem o trabalho, até que ponto pode confiar nos testes do próprio fornecedor, que diferença fazem a configuração e a personalização, o que deve testar por si e como manter o sistema validado depois de entrar em funcionamento.

O que os requisitos exigem efetivamente

Para os fabricantes de dispositivos médicos, a cláusula 4.1.6 da ISO 13485:2016 exige procedimentos documentados para validar a aplicação de software informático utilizado no sistema de gestão da qualidade. A validação ocorre antes da primeira utilização e, conforme adequado, após alterações ao software ou à sua aplicação, e a abordagem deve ser proporcional ao risco associado à utilização do software. Os registos do trabalho são conservados. O relatório técnico ISO/TR 80002-2:2017 fornece orientações específicas sobre a validação de software utilizado em sistemas da qualidade de dispositivos médicos e é útil se pretender um enquadramento prático.

Para os medicamentos, o Anexo 11 das BPF da UE aplica-se a todos os sistemas informatizados utilizados em atividades regulamentadas pelas BPF. A secção 1 exige a gestão do risco ao longo do ciclo de vida do sistema, devendo a extensão da validação basear-se numa avaliação do risco justificada e documentada. A secção 4 aborda a validação: requisitos do utilizador baseados no risco e no impacto nas BPF, com rastreabilidade ao longo do ciclo de vida (4.4); avaliação do fornecedor (4.5); e evidência de métodos e cenários de teste adequados (4.7). A secção 3 aborda os acordos formais com os fornecedores e a secção 11 a avaliação periódica. Uma versão revista do Anexo 11 foi submetida a consulta pública em 2025; à data da redação, o texto de 2011 continua a ser a versão publicada na página EudraLex da Comissão, pelo que deve planear com base nele e acompanhar a publicação da nova versão.

Nenhum dos textos lhe pede que teste todos os botões. Ambos exigem que compreenda o que o sistema faz no seu processo, determine o que pode correr mal e concentre aí os seus esforços. A ICH Q9(R1) transmite a mesma ideia em termos gerais: o esforço, o grau de formalidade e a documentação da gestão do risco da qualidade devem corresponder ao nível de risco.

Segunda edição do GAMP 5 e computer software assurance na prática

A ISPE publicou a segunda edição do GAMP 5 em julho de 2022. As categorias de software continuam a ser úteis: a maioria dos produtos eQMS é software configurável (categoria 4) e qualquer software desenvolvido especificamente para si é personalizado (categoria 5). As mudanças mais úteis estão na ênfase. A segunda edição apela ao pensamento crítico por parte de pessoas que compreendem o processo, espera que as empresas regulamentadas tirem pleno partido do conhecimento, dos testes e da documentação dos fornecedores, e apoia o desenvolvimento iterativo e os serviços na cloud.

A computer software assurance (CSA) aponta na mesma direção. Foi apresentada pela FDA dos EUA em orientações finalizadas em setembro de 2025 e atualizadas em fevereiro de 2026. Embora seja um documento dos EUA, os seus quatro passos constituem uma estrutura sólida para qualquer equipa pequena. Identifique a utilização prevista de cada funcionalidade. Determine se uma falha dessa funcionalidade representaria um risco elevado para o processo. Escolha atividades de assurance adequadas: testes com guião, passos detalhados e resultados esperados quando o risco é elevado; métodos sem guião, como testes exploratórios ou por tentativa de erro, quando não o é. Conserve registos suficientes para demonstrar que o trabalho foi realizado, sem mais do que isso.

Em conjunto, permitem-lhe deixar de produzir evidências que ninguém utiliza. Não lhe permitem deixar de pensar.

Comece pela utilização prevista

Redija uma página que indique para que serve o eQMS na sua instalação. Que processos suporta (controlo de documentos, formação, desvios, CAPA, auditorias internas), quais não suporta (libertação de lotes, comunicação de reclamações às autoridades, por exemplo), quem o utiliza e que registos nele contidos são registos BPF ou ISO 13485. Acrescente o sistema ao seu inventário de sistemas informatizados, que o Anexo 11 4.3 espera que mantenha atualizado.

Em seguida, redija requisitos do utilizador com base nos seus próprios processos, pelas suas próprias palavras. «Uma revisão de um SOP entra em vigor na respetiva data de entrada em vigor e a revisão anterior é retirada de utilização nessa mesma data» é um requisito que pode testar. «O sistema deve permitir o controlo de documentos» não é. Para uma empresa pequena, algumas dezenas de requisitos costumam ser suficientes para um eQMS. Classifique cada um quanto ao risco: uma falha poderia afetar a qualidade do produto, a segurança do doente ou a integridade de um registo BPF? A maioria será de baixo risco. Os que não forem — como a transição na data de entrada em vigor, as assinaturas eletrónicas, o registo de auditoria, as permissões por função e a atribuição de formação após uma revisão — são aqueles que deve testar por si.

Avaliação do fornecedor e confiança nos respetivos testes

O Anexo 11 determina que a competência e a fiabilidade do fornecedor são fatores fundamentais, que a necessidade de uma auditoria deve basear-se no risco (3.2) e que as informações sobre o sistema da qualidade e as auditorias dos fornecedores devem estar disponíveis aos inspetores, mediante pedido (3.4). Para a maioria das pequenas empresas que adquirem um sistema cloud configurável, uma avaliação à distância, baseada num questionário e em documentos, é proporcional; uma auditoria no local justifica-se quando as respostas suscitam dúvidas.

Peça uma descrição do ciclo de vida de desenvolvimento e do sistema da qualidade, do processo de lançamento de versões e de comunicação de alterações, um resumo dos testes realizados às funções essenciais, uma explicação do funcionamento do registo de auditoria e das assinaturas eletrónicas, informações sobre o alojamento dos dados, sobre como são testadas as cópias de segurança e as restaurações, e sobre o processo de saída e exportação. A nossa lista de verificação para compradores de eQMS contém a lista completa de perguntas.

Eis o limite. As orientações da MHRA sobre integridade de dados GxP (secção 6.19) indicam que não é aceitável aceitar dados de validação fornecidos pelo fornecedor isoladamente, sem ter em conta a configuração do sistema e a utilização prevista pelo utilizador, pois é provável que os testes do fornecedor, fora do seu processo, constituam apenas uma verificação funcional. Os testes do fornecedor podem abranger o produto essencial: o mecanismo do registo de auditoria regista as alterações, as assinaturas ficam associadas aos registos e as permissões são aplicadas conforme configuradas. Os seus testes abrangem a sua configuração no seu processo. Registe esta divisão numa declaração breve sobre a confiança nos testes do fornecedor, identificando os documentos do fornecedor que analisou e as conclusões a que chegou.

Configuração versus personalização

A configuração consiste em preparar o produto utilizando as ferramentas que este disponibiliza: fluxos de trabalho, percursos de aprovação, funções, esquemas de numeração, campos de formulários e regras de formação. A personalização consiste em escrever ou alterar código para si. A diferença tem um impacto considerável no esforço de validação.

A configuração é testada com base nos seus requisitos. Se o percurso de aprovação de um SOP tiver dois revisores e um aprovador de QA, teste esse percurso, incluindo o que acontece quando um revisor rejeita o documento. A personalização introduz a categoria 5, com as implicações de conceção, revisão de código e testes, e tem de ser novamente testada sempre que o fornecedor lança uma nova versão. Para uma equipa pequena, a estratégia de validação menos dispendiosa consiste em configurar o sistema de acordo com o seu processo e alterar o processo quando este entra em conflito com o produto. Justifique por escrito todos os pedidos de personalização.

Mantenha a própria configuração sob controlo. A secção 10 do Anexo 11 exige que as alterações à configuração sigam um procedimento definido; por isso, registe a configuração de referência no momento da entrada em funcionamento e encaminhe as alterações posteriores através do controlo de alterações com uma avaliação de impacto.

O que deve testar por si

Concentre os testes com guião nas funções cuja falha poderia danificar registos ou permitir que o documento errado chegasse à linha de produção. Uma divisão típica para um eQMS seria a seguinte:

Os testes exploratórios também precisam de ser registados: quem testou, quando, que área abrangeu, o que tentou e o que encontrou. Meia página por sessão é suficiente. A migração de dados exige uma verificação própria, uma vez que o Anexo 11 4.8 exige que os dados migrados não sejam alterados quanto ao seu valor ou significado.

Conclua com um relatório-resumo de validação que enumere os requisitos, as evidências relativas a cada um (os seus testes, as evidências do fornecedor ou ambos), os desvios encontrados durante os testes e a forma como foram resolvidos (Anexo 11 4.2), bem como uma declaração clara de que o sistema é adequado à utilização prevista.

Manter o sistema validado

Um eQMS na cloud sofre várias alterações por ano. Redija um procedimento breve para os lançamentos de novas versões: como é informado, quem lê as notas da versão, como é avaliado o impacto face aos seus requisitos e quando uma alteração exige novos testes. Uma alteração à lógica de assinatura ou aprovação exige um novo teste direcionado. Uma nova disposição de relatório não.

A secção 11 do Anexo 11 prevê avaliações periódicas para confirmar que o sistema se mantém num estado validado, tendo em conta a funcionalidade, os desvios, os incidentes, o histórico de atualizações, o desempenho, a segurança e o estado da validação. Para uma empresa pequena, uma revisão anual de uma ou duas páginas é suficiente: o que mudou, o que correu mal, se os acessos dos utilizadores continuam adequados, se foi verificada a restauração de uma cópia de segurança e se o dossier de validação ainda corresponde à forma como o sistema é utilizado. Aproveite também para rever o registo de auditoria de uma amostra de registos.

Manter a proporcionalidade

Um dossier de validação de eQMS defensável para um pequeno fabricante cabe numa única pasta: utilização prevista, requisitos avaliados quanto ao risco, avaliação do fornecedor e declaração de confiança nos testes, configuração de referência, os seus guiões de teste e registos de testes exploratórios, um relatório-resumo e um procedimento para as novas versões e a revisão periódica. Um inspetor consegue lê-lo numa hora. Se o seu for muito maior, pergunte que partes foram utilizadas por alguém para tomar uma decisão.

Em resumo

Valide a configuração que criou para o processo que executa, confie no fornecedor quanto ao produto essencial depois de verificar as respetivas evidências e mantenha o sistema validado através da avaliação das novas versões e de uma revisão anual.

Se está a definir o âmbito desse trabalho, a página da plataforma InnoQualis apresenta os módulos de controlo de documentos, formação, desvios, CAPA e auditorias que teria de validar, com assinaturas eletrónicas concebidas para apoiar a 21 CFR Part 11 e o Anexo 11 das BPF da UE, bem como um registo de auditoria apenas de acréscimo.