Nenhum LIMS é validado

O que a ISO/IEC 17025, o 21 CFR Part 11 e o Anexo 11 realmente exigem de um sistema laboratorial, o que o GAMP 5 orienta — e a pergunta que quase ninguém faz ao fornecedor de SaaS 

Toda avaliação de um Sistema de Gerenciamento de Informações de Laboratórios (LIMS) em um ambiente regulado chega, em algum momento, à mesma pergunta: 

“O sistema é validado?” 

A resposta tecnicamente correta é: não é assim que a validação deve ser entendida. 

Software não é validado de forma isolada. O título deste artigo é provocativo de propósito: nenhum LIMS chega validado para o uso pretendido de um laboratório específico. 

O que se valida é a implementação de um sistema computadorizado para um uso pretendido, em um ambiente específico, com uma configuração específica e sob controles definidos. 

Isso muda completamente a conversa. 

Vale fixar dois termos que vão aparecer em todo o texto. Uso pretendido é o conjunto de processos, ensaios, cálculos e decisões que o laboratório vai apoiar no sistema. Estado validado é a condição em que existe evidência documentada de que aquela implementação atende a esse uso pretendido — e em que essa evidência continua válida ao longo do tempo. 

Uma nota de escopo antes de seguir: o 21 CFR Part 11 se aplica a registros eletrônicos sob regulação da FDA e o Anexo 11 a ambientes GMP europeus. Para um laboratório de alimentos ou ambiental, o referencial mais frequente é a ISO/IEC 17025, item 7.11, que trata de gestão de dados e sistemas de informação. A lógica de evidência é a mesma nos três casos; o que muda é qual norma será citada na auditoria. 

Quando um fornecedor responde simplesmente que “o LIMS é validado”, a pergunta seguinte deveria ser: 

Validado para qual processo? Para qual configuração? Para qual ambiente? Para quais requisitos de usuário? 

Porque é exatamente aí que a validação começa. 

E é também por isso que uma frase como “nosso LIMS já é validado” não substitui a evidência que será solicitada durante uma auditoria. 

Antes de falar de validação, precisamos falar de GAMP 5 

Um dos conceitos mais importantes para entender a validação de um LIMS é o GAMP 5. 

GAMP significa Good Automated Manufacturing Practice e é uma abordagem desenvolvida pela ISPE  (International Society for Pharmaceutical Engineering) para orientar a implementação, validação e manutenção de sistemas computadorizados utilizados em ambientes regulados. 

Um ponto importante: 

GAMP 5 não é uma norma regulatória e não é um certificado de conformidade. 

É uma orientação baseada em risco para ajudar organizações a definir quanto controle, documentação, teste e evidência são necessários para demonstrar que um sistema computadorizado é adequado ao uso pretendido.

A ISPE descreve justamente essa abordagem como pragmática, baseada em risco e voltada a sistemas computadorizados GxP. A referência é o GAMP 5 Segunda Edição (ISPE, 2022), que reforça essa abordagem e acrescenta orientação sobre pensamento crítico, métodos ágeis e serviços em nuvem — inclusive apêndices dedicados a SaaS, que é exatamente o cenário discutido no fim deste artigo. 

Na prática, o GAMP 5 responde a uma pergunta muito mais útil do que “o sistema é validado?”: 

Qual é o risco desse sistema para o processo e para a integridade dos dados, e qual nível de evidência precisamos produzir para demonstrar que esse risco está controlado? 

É essa lógica que torna o GAMP tão importante para um LIMS. 

GAMP 5 Categoria 4: por que essa classificação importa? 

Um LIMS comercial configurável normalmente se enquadra no conceito de GAMP 5 Categoria 4 —Configured products. 

Categoria 4 significa, de forma simplificada, que estamos falando de um produto comercial que possui funcionalidades padronizadas, mas que pode ser configurado para atender aos processos específicos de uma organização. 

Isso é diferente de: 

• Categoria 3: software comercial não configurado; 
• Categoria 5: software desenvolvido especificamente para atender a uma necessidade particular. 

O GAMP 5 Segunda Edição, no apêndice de categorias de software, descreve os sistemas laboratoriais como podendo se enquadrar nas categorias 3, 4 e, em determinados casos, 5. Também destaca que a Categoria 4 pode exigir uma avaliação de risco específica da configuração utilizada pelo laboratório. 

Duas ressalvas sobre essa classificação. A Categoria 1 cobre o software de infraestrutura — sistema operacional, banco de dados, middleware — e a Categoria 2 foi eliminada na versão atual do GAMP 5. E a categoria não descreve o sistema inteiro: aplica-se a componentes e funções. Um LIMS típico é Categoria 4 no núcleo, com elementos de Categoria 5 em cálculos customizados, relatórios e interfaces com equipamentos. Um produto configurável mantido na configuração padrão, por sua vez, pode ser tratado como Categoria 3. 

E aqui está o ponto que interessa para quem está comprando um LIMS: 

a Categoria 4 não significa que o fornecedor entrega uma “validação pronta”. 

Ela significa que existe uma divisão entre: 

1. aquilo que o fornecedor precisa demonstrar sobre o produto; 
2. aquilo que precisa ser verificado sobre a configuração; 
3. aquilo que o laboratório precisa demonstrar sobre seu uso pretendido. 

O fornecedor deve fornecer evidências sobre o desenvolvimento do produto, controles de qualidade, infraestrutura, versões, testes e demais elementos sob sua responsabilidade. 

O laboratório, por sua vez, precisa demonstrar que aquela implementação específica atende aos seus requisitos e funciona adequadamente para o uso pretendido. 

É por isso que o dono do sistema validado é o laboratório. 

E isso não é uma deficiência do fornecedor. 

É justamente o modelo esperado. 

O que cada lado deve fazer na validação de um LIMS? 

Uma implementação de LIMS em ambiente regulado precisa deixar clara a divisão de responsabilidades. 

Duas leituras importantes dessa tabela. A primeira: ela descreve o modelo típico de um LIMS SaaS configurável e deve ser ajustada em contrato. A segunda: há três linhas em que a divisão precisa ficar mais explícita. A URS e a matriz de rastreabilidade são entregáveis do laboratório — o fornecedor oferece modelo e insumos, mas quem escreve, assume e mantém é o laboratório, e as declarações do fornecedor na matriz ainda precisam ser verificadas. Na OQ, o fornecedor prepara protocolos e apoia, e a execução ou o testemunho e a aprovação cabem ao laboratório ou a terceiro qualificado. E em desvio causado por defeito de produto, a causa raiz técnica é do fornecedor, enquanto a classificação de criticidade e o fechamento são do laboratório. 

A linha mais importante dessa tabela é a do PQ/UAT. 

O fornecedor pode apoiar, orientar, fornecer evidências, preparar protocolos e acompanhar a execução. 

Mas o fornecedor não deve ser o executor e o aprovador da qualificação de desempenho do próprio sistema. 

Não existe proibição explícita na norma de que o fornecedor execute um protocolo. O que o Anexo 11, item 1, e o Capítulo 7 do EU GMP estabelecem é que a responsabilidade pelo sistema permanece com o usuário regulado, inclusive em atividades terceirizadas. O ponto aqui é segregação de funções e conflito de interesse. 

Quem aprova que o sistema atende ao uso pretendido é o laboratório. 

Se o fornecedor se oferece para assinar o seu UAT como aprovador, eu perguntaria imediatamente por quê: quem está fazendo a validação: o fornecedor ou o usuário do sistema? 

A responsabilidade final pela confirmação de que o sistema atende aos requisitos do usuário permanece com o usuário. 

Veja também: Principais módulos e recursos de um LIMS

Os oito blocos de evidência que sustentam uma validação 

Um informe de validação que resiste a uma auditoria não é um documento isolado. 

É um conjunto de evidências que se referenciam entre si. Três desses blocos — IQ, OQ e PQ — são tratados em conjunto no item 4, e os dois últimos, controle de mudanças e revalidação, são processos contínuos e não documentos. 

É aqui que muita validação de LIMS fica frágil: existe um documento chamado “Validation Report”, mas não existe uma cadeia consistente entre requisito, risco, configuração, teste, resultado e aprovação. 

1. Confirmação de URS 

O laboratório emite os requisitos de usuário. 

O fornecedor devolve uma matriz em que cada requisito recebe um status: 

• atende no padrão; 
• atende por configuração; 
• exige desenvolvimento; 
• não atende. 

Além disso, a matriz deve apontar a referência à tela ou funcionalidade correspondente e ao caso de teste que comprova o atendimento. 

Um gap declarado, documentado e controlado é muito melhor do que um gap descoberto durante o UAT. 

2. Gestão de riscos 

A análise deve considerar as funções GxP e seus impactos. 

Uma abordagem FMEA pode avaliar, entre outros pontos: 

• qualidade do produto; 
• segurança do consumidor ou do paciente, conforme o setor;integridade dos dados. 

O nível de risco deve orientar a profundidade do teste. 

FMEA não é obrigatório. O GAMP 5 Segunda Edição adverte contra a sobre-engenharia de ferramentas de risco, e para a maioria dos LIMS uma matriz simples de severidade, probabilidade e detecção resolve. E antes de tudo isso vem uma pergunta mais básica, que a avaliação inicial precisa responder: quais funções do sistema são de fato reguladas e entram no escopo da validação? 

Funções críticas podem exigir teste integral e evidência documental. Funções de menor risco podem ser tratadas por amostragem, quando tecnicamente justificável. Amostragem também não é a única alternativa ao teste integral: valem igualmente o aproveitamento do teste do fornecedor e o teste exploratório não roteirizado. 

Essa é uma das principais contribuições do GAMP 5: 

não testar tudo da mesma maneira. 

A abordagem deve ser proporcional ao risco. 

O próprio GAMP 5 enfatiza que a categorização e a avaliação de risco devem orientar o esforço de verificação e os controles necessários. 

3. Rastreabilidade 

Existem duas rastreabilidades que não deveriam ser confundidas. 

Rastreabilidade da validação 

URS → configuração → caso de teste → resultado → desvio → informe final. 

Nenhum requisito deveria ficar sem método de verificação definido — teste, inspeção, revisão documental ou evidência do fornecedor — ou sem justificativa registrada para não ser verificado. 

E nenhum teste deveria existir sem um requisito ou risco que justifique sua existência. 

Rastreabilidade do dado 

Aqui estamos falando do processo laboratorial. 

Por exemplo: 

matéria-prima → lote do fornecedor → amostra → análise → resultado → analista → equipamento → calibração → especificação → produto acabado. 

Essa cadeia precisa ser percorrível nos dois sentidos. 

A validação do sistema e a integridade do dado estão relacionadas, mas não são a mesma coisa. 

4. IQ, OQ e PQ: três objetivos diferentes 

Uma ressalva de vocabulário antes de seguir: IQ, OQ e PQ vêm da qualificação de equipamentos, e o GAMP 5 não os prescreve para sistemas computadorizados — ele fala em especificação e verificação, ou seja, verificação de instalação, testes funcionais e de requisitos e aceitação do usuário. Os termos seguem sendo os que o mercado usa, e é assim que aparecem aqui; o que importa é o objetivo de cada etapa, não a sigla. 

IQ — Installation Qualification 

A IQ registra o ambiente em que o sistema está instalado e operando. Em instalação on-premise, isso é executado no ambiente do laboratório. Em SaaS, essa camada é a qualificação de infraestrutura do fornecedor: o que o laboratório verifica e arquiva é o sumário de hospedagem mais o que existe do seu lado. O teste de restauração, por sua vez, costuma ser tratado junto com continuidade e recuperação (Anexo 11, itens 7.2 e 16), e não como item de IQ. 

Entre os elementos relevantes estão: 

• versão da aplicação; 
• versão e parametrização do banco; 
• rede; 
• certificados; 
• política de backup; 
• teste de restauração. 

OQ — Operational Qualification 

A OQ verifica se as funções críticas operam conforme especificado. 

Os testes devem utilizar protocolos previamente aprovados. Isso vale para as funções de maior risco. Para o restante, a abordagem de Computer Software Assurance da FDA admite teste não roteirizado, exploratório ou ad hoc, com documentação proporcional ao risco. E o escopo — quais funções são consideradas críticas — precisa estar justificado no plano de validação. 

PQ — Performance Qualification 

A PQ verifica o sistema no contexto real de utilização. 

É onde o processo real do laboratório entra em cena. 

Por isso, a PQ é executada pelo laboratório. 

O fornecedor pode acompanhar, capacitar e dar suporte. 

Mas a organização usuária precisa demonstrar que o sistema funciona adequadamente no seu processo. 

5. Desvios 

Todo resultado diferente do esperado deve gerar um registro. 

Esse registro precisa permitir: 

• classificação do desvio; 
• avaliação de impacto sobre a integridade do dado; 
• investigação da causa raiz; 
• definição da ação; 
• evidência de fechamento. 

E existe uma regra que vale deixar explícita no plano de validação: 

nenhum desvio crítico deve permanecer aberto na aprovação do informe final. Na prática, isso quer dizer: sem justificativa documentada, risco residual formalmente aceito e ação corretiva aprovada. E o plano precisa dizer antes o que torna um desvio crítico — impacto em função GxP, em resultado liberado ou na integridade do dado. 

6. Informe final 

O informe final deve consolidar, no mínimo: 

• escopo; 
• resumo da execução; 
• matriz de URS com status final; 
• risco residual aceito; 
• desvios e status de fechamento; 
• registro de capacitação dos usuários; 
• linha base da configuração. 

Essa última parte merece atenção especial. 

A linha base de configuração deve registrar, entre outros elementos: 

• versão da aplicação; 
• versão do banco; 
• parâmetros; 
• especificações carregadas; 
• lista de usuários e privilégios vigentes; 
• inventário de interfaces e integrações (equipamentos, ERP); 
• versões dos relatórios e dos modelos de certificado; 
• limites e especificações carregadas, com data de vigência; 
• matriz de perfis vigente. 

Ela é a fotografia controlada do estado validado. 

Sem essa fotografia, fica muito mais difícil responder à pergunta: “O que exatamente foi validado?” 

E sem essa resposta, o controle de mudanças fica comprometido. 

7. Controle de mudanças 

O controle de mudanças acontece em dois níveis. 

Mudança do produto 

É responsabilidade do fornecedor. 

Inclui: 

• versionamento; 
• avaliação de impacto GxP por release; 
• regressão; 
• QA antes da disponibilização em produção. 

Mudança da configuração 

É responsabilidade do laboratório. 

Por exemplo: 

• nova especificação; 
• novo ensaio; 
• novo template de certificado; 
• novo perfil de usuário; 
• alteração de fluxo. 

Cada mudança precisa passar por avaliação de impacto e, quando aplicável, teste dirigido antes de entrar em produção. 

Esse conceito está alinhado ao próprio Anexo 11, que determina que alterações em sistemas computadorizados e suas configurações sejam realizadas de maneira controlada e segundo procedimentos definidos. 

8. Revalidação e revisão periódica 

Revalidação não deveria ser sinônimo de “refazer tudo uma vez por ano”. O vocabulário atual, na verdade, separa três coisas: o controle de mudanças, que dispara a reverificação; a revisão periódica, que confirma se o sistema segue em estado validado; e a manutenção do estado de controle ao longo do ciclo de vida. 

Ela deve ser orientada por gatilhos de mudança e risco. 

Exemplos: 

• upgrade com impacto em função crítica; 
• migração de infraestrutura; 
• alteração de cálculo; 
• alteração de fluxo de aprovação; 
• mudança regulatória; 
• achado de auditoria; 
• ampliação do uso pretendido. 

O escopo deve ser proporcional ao impacto. 

Pode envolver regressão direcionada às funções afetadas e PQ parcial, em vez de simplesmente repetir toda a validação. 

Isso não elimina a revisão periódica. 

Ao contrário: a revisão periódica deve avaliar se o sistema continua em estado validado. A frequência é dirigida por risco, criticidade e histórico de mudanças, e não é anual por definição (Anexo 11, item 11 — avaliação periódica). 

O Anexo 11 também estabelece a necessidade de avaliações periódicas para confirmar que sistemas computadorizados permanecem em estado válido e em conformidade, considerando elementos como funcionalidade atual, desvios, incidentes, upgrades, segurança e status de validação. 

Fora dessa lista há temas que aparecem em quase toda auditoria e que este artigo não cobriu: migração de dados legados (Anexo 11, item 4.8), que é o achado mais comum em implantação de LIMS; assinatura eletrônica (Part 11, Subparte C, e Anexo 11, item 14); gestão de acessos e revisão periódica de perfis; segregação de ambientes entre produção, homologação e treinamento; backup, restauração e continuidade (Anexo 11, itens 7.2 e 16); checagens de exatidão e interfaces com equipamentos (Anexo 11, itens 5 e 6); retenção e arquivamento de registros (item 17); e treinamento com registro de capacitação (item 2). 

Audit trail: cinco atributos e o teste que realmente importa 

Dizer que um LIMS possui audit trail não significa muita coisa. 

O que importa é como essa trilha funciona na prática. 

O 21 CFR Part 11, item 11.10(a), exige validação capaz de discernir registros inválidos ou alterados, e o item 11.10(e) exige trilha de auditoria com data e hora das entradas e ações.

O Anexo 11, item 9, trata da trilha com base em avaliação de risco e pede que ela esteja disponível em formato inteligível e seja revisada regularmente. Já o registro do motivo da alteração vem do Capítulo 4.9 do EU GMP e dos guias de integridade de dados da MHRA e do PIC/S. 

Por isso, eu faria cinco perguntas. 

1. É seguro? 

Teste: 

Existe alguma tela, em qualquer perfil — inclusive administrador — que permita editar ou apagar um registro da trilha? 

Quem possui acesso direto ao banco utiliza contas nominais? 

Esse acesso é registrado? 

A infraestrutura está exposta à internet pública? 

2. É independente? 

Teste: 

Existe algum parâmetro que permita operar o sistema com a trilha desligada? 

A data e hora são determinadas pelo servidor ou pelo computador do usuário? 

Se o usuário controla o timestamp, existe um problema. E um servidor com relógio não sincronizado tem exatamente o mesmo problema: o requisito é fonte de tempo controlada, sincronizada e documentada, com tratamento de fuso horário. 

3. É inalterável? 

Teste: 

Altere um resultado que já foi aprovado. 

Depois olhe a trilha. 

O valor anterior continua disponível? 

O novo valor foi registrado? 

O sistema exigiu o motivo da alteração? 

Esse último ponto é especialmente importante em ambientes regulados. 

4. É exportável? 

Teste: 

A Qualidade consegue exportar a trilha, filtrada por período e usuário, contendo valor anterior, valor novo e demais informações relevantes? 

E consegue fazer isso sem abrir um chamado para o fornecedor e sem acessar diretamente o banco de dados? 

Se a evidência depende do fornecedor para ser obtida durante uma inspeção, isso precisa estar muito bem avaliado. Uma ressalva de escopo: a exigência normativa é que a trilha esteja disponível para revisão e inspeção em formato inteligível. Autosserviço de exportação é critério de compra, e um bom critério, mas não é obrigação regulatória. 

5. É revisável? 

Aqui está um teste simples: 

“Quais resultados foram alterados depois da aprovação no último trimestre, por quem e com qual motivo?” 

Se para responder isso é necessário exportar tudo e cruzar manualmente em uma planilha, talvez exista uma consulta de dados. 

Mas isso não é necessariamente o mesmo que ter uma revisão eficiente da trilha. 

O ponto cego do SaaS multi-tenant 

Agora chegamos a uma questão que, na minha opinião, deveria aparecer em toda avaliação de LIMS SaaS. 

Imagine: 

Você validou o sistema em março. 

Em abril, o fornecedor disponibilizou uma nova release para todos os clientes. 

Seu estado validado continua válido? 

Em um SaaS multi-tenant, normalmente o cliente não escolhe individualmente quando recebe uma atualização. 

Isso não é necessariamente um defeito. 

É parte do modelo SaaS. 

Mas cria uma responsabilidade adicional para o fornecedor e para o laboratório. Vale dizer com clareza: a release não invalida automaticamente o estado validado. Ela precisa passar por avaliação de impacto sob controle de mudanças, e o estado de controle se mantém pela combinação entre a gestão de mudanças do fornecedor e a avaliação do laboratório. 

Por isso, antes de contratar um LIMS SaaS, eu perguntaria: 

1. Existe release note com avaliação de impacto GxP? 

Não basta uma lista de “novidades”. 

É preciso entender quais funções reguladas podem ser afetadas. 

2. Existe notificação prévia? 

E com quantos dias de antecedência? 

3. Existe ambiente para regressão? 

O laboratório consegue testar as alterações antes que elas cheguem à produção? 

4. Existe congelamento de versão durante OQ e PQ? 

Essa última pergunta é particularmente importante. 

Sem congelamento durante a janela de qualificação, você pode acabar qualificando uma versão e executando a operação em outra. 

E sem avaliação de impacto e comunicação adequada, o controle de mudanças do laboratório fica comprometido. Vale registrar que, em SaaS multi-tenant real, congelar a versão para um cliente específico normalmente não é possível: o que existe são mitigações — calendário de releases, ambiente de homologação antes da produção e janela de qualificação curta. A pergunta útil, portanto, é como o fornecedor protege essa janela. 

5. Existe acordo de qualidade ou contrato técnico? 

É o instrumento que torna todas as perguntas anteriores exigíveis: escopo de responsabilidades, direito de auditoria e obrigações de notificação (Anexo 11, itens 3.1 e 3.2). 

No final, a pergunta da auditoria não será: 

“O fornecedor atualizou o sistema?” 

Será: 

“Como vocês demonstraram que a mudança não comprometeu o estado validado?” 

Seis perguntas para levar para qualquer avaliação de LIMS 

Se eu estivesse avaliando um fornecedor hoje, começaria por estas seis: 

1. Qual é a categoria GAMP do sistema e o que exatamente está incluído no pacote de suporte à validação? E como o fornecedor sustenta essa posição? A decisão sobre a categoria continua sendo do laboratório, baseada em risco e por função. 

2. O fornecedor assina o PQ? 

Se sim, eu perguntaria imediatamente por quê. 

3. A trilha de auditoria exige motivo para alteração de um resultado aprovado? 

4. A Qualidade consegue exportar e revisar a trilha sem depender do fornecedor? 

5. Com quantos dias de antecedência o laboratório é avisado sobre uma release com impacto GxP e onde pode executar a regressão? 

6. A versão fica congelada durante a janela de PQ? E, se não houver congelamento, como essa janela é protegida? 

Se o fornecedor responde às seis perguntas com evidência documental, a conversa sobre validação começa no lugar certo. 

Se a resposta for apenas: 

“Nosso sistema é validado.” 

Eu faria mais perguntas. 

Porque um LIMS não se torna validado por estar no data center do fornecedor. 

Ele se torna parte de um sistema computadorizado validado quando existe evidência de que aquela implementação, naquela configuração, naquele ambiente e para aquele uso pretendido atende aos requisitos definidos e permanece sob controle ao longo do seu ciclo de vida. 

E onde entra o fornecedor? 

O fornecedor não deve desaparecer da validação. 

Muito pelo contrário. 

Um bom fornecedor deve fornecer evidência suficiente para que o laboratório não precise reconstruir do zero aquilo que já foi demonstrado no ciclo de vida do produto. 

É exatamente uma das vantagens da abordagem baseada em risco: aproveitar conhecimento, documentação e testes existentes do fornecedor, evitando duplicação desnecessária de esforço. 

O fornecedor deve contribuir com aquilo que controla. 

O laboratório deve validar aquilo que utiliza. 

Essa separação é saudável. 

E, principalmente, é auditável. 

Sobre a Actiz 

Na Actiz, operamos um LIMS SaaS para laboratórios de controle de qualidade industrial em infraestrutura dedicada, com isolamento por banco de dados. Isolamento de dados, porém, não é a mesma coisa que controle de versão de aplicação — e é por isso que as perguntas da seção anterior valem também para nós. O que responde a elas é o pacote abaixo, e é ele que deve ser lido como o compromisso, não o modelo de hospedagem. 

Nossa abordagem não é vender a frase: 

“Nosso LIMS é validado.” 

Preferimos entregar evidência. 

Por isso, disponibilizamos um pacote de suporte à validação que pode incluir: 

• matriz de URS; 
• protocolos; 
• evidências técnicas; 
• informações para avaliação de riscos; 
• política de controle de mudanças; 
• release notes; 
• critérios de revalidação; 
• informações sobre a infraestrutura; 
• documentação necessária para suportar a avaliação do estado validado. 

Porque, no fim, a pergunta certa não é: 

“O LIMS é validado?” 

A pergunta certa é: 

“Como o fornecedor e o laboratório dividem a responsabilidade para demonstrar e manter o estado validado do sistema ao longo do seu ciclo de vida?” 

Essa é uma pergunta muito mais difícil. 

E é exatamente a pergunta que deveria ser feita antes de assinar o contrato.