Validação de sistemas computadorizados sem a espiral de papelada

A validação tem um problema de reputação na manufatura, e ele é em boa parte merecido. Pergunte a um engenheiro o que é CSV na prática e você costuma receber a descrição de um conjunto de documentos, não de uma atividade: protocolos escritos a partir de um modelo, capturas de tela de cada campo, uma folha de assinaturas mais grossa que o teste que ela certifica.

Não é isso que a orientação pede. O GAMP 5 é explícito ao dizer que o esforço deve ser proporcional ao risco, à complexidade e à novidade — e que é o pensamento crítico, não o volume, que torna uma validação defensável. A distância entre esse princípio e a prática comum é onde fica a maior parte do custo.

O que "baseado em risco" realmente significa

Para fechar essa distância, o primeiro passo é definir de que risco se está falando. Risco aqui é risco ao paciente, à qualidade do produto e à integridade dos dados — não risco de projeto. Uma função que calcula uma quantidade de dispensação carrega risco. Uma função que permite ao usuário mudar a cor de um gráfico, não. Testar as duas com a mesma profundidade não é rigor; na prática, é ausência de priorização, e tira atenção das partes que importam.

Aplicado corretamente, isso muda o formato do pacote. Funções de alto risco recebem especificação detalhada, teste minucioso e rastreabilidade explícita. Funções de baixo risco recebem cobertura proporcional. O esforço economizado vai para as áreas que um inspetor de fato vai sondar.

Um pacote de validação que trata toda função como igualmente crítica diz ao inspetor que ninguém avaliou quais eram.

Aproveite o fornecedor em vez de retestá-lo

A avaliação de risco diz o que merece teste. A segunda pergunta é quem já testou. Uma das maiores fontes de desperdício é retestar o que o fornecedor já testou, e o GAMP 5 antecipa isso: quando o fornecedor tem um sistema de qualidade maduro e consegue evidenciar seu próprio desenvolvimento e teste, essa evidência pode ser aproveitada em vez de duplicada.

Esse aproveitamento precisa ser conquistado, não presumido. Uma avaliação de fornecedor em que se possa confiar estabelece:

• se existe um ciclo de vida de desenvolvimento documentado, e evidência de que é seguido
• como as mudanças são controladas, testadas e liberadas
• o que o fornecedor testa, e se esse teste é retido e auditável
• como defeitos são rastreados, e como os clientes são notificados dos relevantes

Onde as respostas forem boas, o seu teste se concentra na configuração e no seu próprio processo. Onde não forem, você testa mais — e agora tem uma razão documentada para isso, o que já é uma posição mais forte do que testar tudo por padrão.

Teste o processo, não o software

Com o escopo definido pelo risco e pelo fornecedor, sobra a pergunta de como testar o que ficou. O teste de validação mais útil exercita o uso pretendido, não a lista de funcionalidades. Um protocolo que confirma que um campo aceita números diz pouco. Um protocolo que roda um lote representativo pelo sistema — incluindo um valor deliberadamente fora de faixa, um lançamento corrigido e uma revisão de segunda pessoa — diz se o processo está de fato sendo imposto.

É também aqui que a arquitetura aparece. Se os valores em processo chegam de um historiador de processo com seu carimbo de tempo de origem, em vez de serem digitados, toda uma classe de casos de teste de transcrição deixa de ser necessária — o modo de falha foi removido, não testado.

O que "baseado em risco" não dispensa

Nada disso é licença para afrouxar onde importa. Uma abordagem proporcional não é uma abordagem leve nas partes críticas, e algumas coisas permanecem inegociáveis, independentemente do que a avaliação de risco tenha concluído:

1. Requisitos específicos o bastante para serem testados. "O sistema deve ser amigável" não é verificável e não deveria passar na revisão.
2. Rastreabilidade do requisito ao teste, para que a cobertura seja demonstrável e não afirmada.
3. Evidência de que os controles de integridade de dados funcionam — trilha de auditoria, assinatura eletrônica, controle de acesso — porque é por aí que uma inspeção costuma começar.
4. Uma justificativa documentada para o escopo escolhido. A decisão de testar menos é defensável; uma decisão não documentada de testar menos, não.

A validação não termina no go-live

Mesmo um pacote proporcional e bem justificado só vale enquanto o sistema continua no estado em que foi validado. O estado validado é uma condição a ser mantida, não um marco a ser vencido. A maioria dos apontamentos nessa área não é sobre o pacote original — é sobre o que aconteceu depois: uma configuração alterada sem avaliação, um patch do fornecedor aplicado sem teste de regressão, uma revisão periódica que foi agendada e nunca realizada.

Aqui os sistemas ajudam de um jeito que a documentação não consegue. Uma trilha de auditoria encadeada por hash das alterações de configuração transforma "nós controlamos mudanças" de uma afirmação num POP em algo que o inspetor pode inspecionar. Permissões por perfil tornam a declaração de controle de acesso verificável em vez de aspiracional.

Por onde começar se a abordagem atual está pesada demais

Não comece reescrevendo modelos. Comece com um sistema e uma avaliação de risco honesta, e veja quanto do pacote existente essa avaliação teria justificado. A resposta costuma ser desconfortável, e é o argumento mais persuasivo disponível para mudar a abordagem.

A partir daí, a questão de escopo se encaixa naturalmente nas fases de um roteiro de digitalização, e os sistemas mais frequentemente no escopo — o registro eletrônico de lote entre eles — pertencem a uma postura mais ampla de conformidade digital, e não a um exercício de validação isolado.