Pular para o conteúdo
Kralen

Guia 33/2020 da ANVISA na prática: URS, FS, DQ, IQ, OQ, PQ explicados

Validação de sistemas computadorizados em distribuidora farmacêutica: o que cada documento do Guia 33/2020 contém, quando é exigido na auditoria e como o K-SINFI entrega o pacote pronto no onboarding.

Admin Kralen
Equipe Kralen
Card branded com selo de validação e título Guia 33/2020 ANVISA na prática — URS FS DQ IQ OQ PQ
Neste artigo

"Sistema computadorizado validado conforme o Guia 33/2020 da ANVISA" — frase que aparece em editais de licitação, em propostas de ERP e em auditorias sanitárias. O que ela significa na prática? Quais documentos compõem essa validação? Quem precisa ter o quê em mãos no dia da inspeção? Este artigo cobre as siglas — URS, FS, DQ, IQ, OQ, PQ — e mostra como cada documento é cobrado em ambiente real de distribuidora farmacêutica.

O que é o Guia 33/2020

O Guia 33/2020 da ANVISA é um documento orientativo que estabelece as expectativas da Agência sobre validação de sistemas computadorizados usados em atividades reguladas — produção, controle de qualidade, distribuição e comercialização de medicamentos. Ele não é uma RDC (resolução com força normativa direta), mas funciona como referência usada em inspeção: o auditor da Vigilância espera ver o pacote documental que o Guia descreve.

Na prática, o Guia 33 traduz para o contexto brasileiro a metodologia GAMP (Good Automated Manufacturing Practice) reconhecida internacionalmente. A diferença é que o Guia adapta exigências documentais ao mercado brasileiro e ao tipo de empresa regulada pela ANVISA.

A ANVISA não certifica ERPs — certifica empresas

Este é o ponto que mais gera confusão na primeira conversa de venda. Não existe "ERP certificado pela ANVISA". O que existe é:

  • Empresa (distribuidora) regulamentada pela ANVISA.
  • Sistema computadorizado validado conforme o Guia 33/2020 dentro da operação dessa empresa.

Quem responde pela validação é a empresa usuária, não o fornecedor do software. Por isso o pacote documental abaixo é elaborado pela parceria entre distribuidora e fornecedor do ERP — e fica em poder da distribuidora, à disposição da inspeção.

URS — User Requirements Specification

A URS descreve o que o usuário precisa que o sistema faça. Não fala de tecnologia ainda — fala de necessidade de negócio. Em distribuidora farmacêutica, uma URS típica inclui:

  • Rastrear lote e validade em todas as movimentações.
  • Aplicar FEFO automático na separação.
  • Transmitir movimentação de controlados ao SNGPC em tempo real.
  • Registrar trilha de auditoria imutável.
  • Gerar relatórios exigidos por Vigilância Sanitária estadual.

A URS é assinada pelo responsável técnico farmacêutico e pelo gestor de TI da distribuidora. É o documento que mostra ao auditor que a empresa sabe o que precisava, antes mesmo de escolher o sistema.

FS — Functional Specification

A FS é a resposta do fornecedor do software à URS. Para cada requisito da URS, a FS descreve como o sistema entrega aquela necessidade. Continuando o exemplo:

  • URS: "rastrear lote e validade em todas as movimentações" → FS: "tabela movimentacoes com campos lote e validade obrigatórios; UI da separação exige seleção de lote".
  • URS: "transmitir movimentação de controlados ao SNGPC" → FS: "job em fila sngpc-transmissao dispara a cada 5 minutos; retry exponencial em caso de falha; logs em sngpc_audit".

A FS é técnica, mas precisa ser compreensível pelo responsável técnico farmacêutico — é ele quem confirma que a "como" entrega a "necessidade".

DQ — Design Qualification

A DQ documenta que o desenho do sistema atende ao que está especificado. Em distribuidora farmacêutica, a DQ costuma incluir:

  • Arquitetura geral do sistema (banco de dados, servidores de aplicação, integrações).
  • Modelo de dados das principais tabelas (movimentações, lote, validade, controlados).
  • Fluxos de processo (entrada, separação, expedição, devolução).
  • Plano de backup e recuperação.
  • Plano de segurança e controle de acesso.

É na DQ que o auditor verifica se decisões arquiteturais estão coerentes com o que a operação exige. Sistema sem backup automatizado, por exemplo, é um achado de DQ.

IQ — Installation Qualification

A IQ comprova que o sistema foi instalado conforme especificado, no ambiente do cliente. Inclui:

  • Lista de servidores e versões de software instaladas.
  • Configurações de rede e firewall.
  • Procedimentos de instalação seguidos.
  • Backup de configuração inicial.

A IQ é assinada pelo engenheiro de infraestrutura responsável pela instalação e contra-assinada pelo gestor de TI da distribuidora. Em ambiente SaaS, parte da IQ é coberta pelo fornecedor e parte pela configuração específica do tenant da distribuidora.

OQ — Operational Qualification

A OQ é onde a coisa fica concreta: testes que comprovam que cada funcionalidade especificada na FS opera corretamente. Em distribuidora farmacêutica, casos de teste típicos da OQ incluem:

  • Cadastrar produto, conferir que aparece no estoque.
  • Receber NF-e, conferir lote e validade gravados.
  • Movimentar lote, conferir trilha de auditoria.
  • Tentar editar registro retroativo, conferir que não é permitido.
  • Disparar transmissão SNGPC, conferir XML enviado e retorno recebido.
  • Simular excursão térmica, conferir alerta gerado.

Cada caso tem cenário (entrada), passos, resultado esperado e resultado obtido. A OQ é o documento mais volumoso do pacote — dezenas a centenas de casos de teste, dependendo do escopo.

PQ — Performance Qualification

A PQ comprova que o sistema entrega performance e disponibilidade adequadas em ambiente real de operação. Inclui:

  • Testes de carga (usuários simultâneos, transações por minuto).
  • SLA de disponibilidade do sistema.
  • Tempo de resposta em operações críticas.
  • Procedimentos de monitoramento contínuo.

A PQ é o documento que distingue "o sistema funciona" de "o sistema funciona no volume da minha operação". Distribuidora que processa milhares de pedidos por dia precisa de PQ correspondente.

Como cada documento é cobrado em auditoria

O fiscal não vai pedir os seis documentos em sequência. Costuma pedir um deles para validar um achado específico. Padrões observados:

  • Achou divergência entre relatório e dados → pede OQ daquele relatório.
  • Achou trilha de auditoria editável → pede DQ da arquitetura de logs.
  • Achou falha de transmissão SNGPC → pede OQ do módulo + PQ de retry.
  • Achou usuário ativo sem treinamento → pede URS dos perfis de acesso.

O pacote precisa estar em poder da distribuidora, organizado, e o responsável técnico precisa saber onde encontrar cada documento.

Cronograma típico de validação no onboarding

Para distribuidora mid-market (R$ 30-150 mi), o cronograma padrão do pacote Guia 33 cabe nos 60-90 dias do onboarding:

  • Semanas 1-2: URS conjunta (distribuidora + Kralen).
  • Semanas 3-4: FS e DQ entregues pelo fornecedor.
  • Semanas 5-8: IQ (instalação no ambiente do cliente) e OQ (execução de casos de teste).
  • Semanas 9-12: PQ (testes de carga e SLA).
  • Go-live com pacote documental completo assinado.

Erros comuns que reprovam a validação

Em auditoria, alguns erros aparecem com frequência:

  • URS genérica copiada de modelo padrão, sem refletir a operação real.
  • OQ com casos de teste não executados (resultado obtido vazio).
  • DQ desatualizada após upgrades do sistema.
  • Pacote completo mas não assinado pelo RT farmacêutico.
  • Versão do sistema documentada na IQ diferente da versão em produção.

Perguntas frequentes

Validação Guia 33 tem prazo de validade?

Não há prazo legal, mas mudanças significativas no sistema (upgrades maiores, novos módulos) exigem revalidação parcial ou total dos documentos afetados.

Posso usar um sistema sem validação Guia 33?

Tecnicamente sim, mas em inspeção a Vigilância vai exigir comprovação de que o sistema atende aos requisitos regulatórios. Validação documentada é a forma reconhecida de comprovar.

O fornecedor do ERP entrega o pacote pronto?

Parte sim, parte não. URS é responsabilidade da distribuidora (ou conjunta). FS, DQ, parte da IQ e PQ vêm do fornecedor. OQ é executada conjuntamente. No K-SINFI, o pacote é entregue como entregável padrão do onboarding.

Próximos passos

Para conhecer detalhadamente como o pacote Guia 33/2020 é montado durante o onboarding da Kralen, veja a página Vigilância Sanitária e Licitação ou solicite uma demonstração com nosso farmacêutico regulatório.

Referências oficiais

Para aprofundar os pontos deste artigo, consulte as fontes primárias:

Última revisão editorial: maio de 2026.

Obrigado por ler até aqui

Compartilhe com quem decide na sua operação ou siga conosco para o próximo artigo sobre distribuidoras farmacêuticas reguladas.

Próximo passo

Veja o K-SINFI em operação.

45 minutos com especialista farmacêutico. Demonstração com dados do seu perfil operacional — não slides genéricos.