Guia 33/2020 da ANVISA na prática: URS, FS, DQ, IQ, OQ e PQ explicados
Validação de sistemas pelo Guia 33/2020 da ANVISA em linguagem simples: o que são URS, FS, DQ, IQ, OQ e PQ e como a distribuidora organiza cada um.
Por Equipe Kralen · Publicado em · Atualizado em
"Sistema validado conforme o Guia 33 da ANVISA." A frase aparece em propostas de software, em conversas com consultores e em inspeções sanitárias. Mas pouca gente consegue explicar o que ela quer dizer. E as siglas não ajudam: URS, FS, DQ, IQ, OQ, PQ.
Para a distribuidora de medicamentos, o assunto não é só teoria. A RDC 430/2020, que trata das Boas Práticas de Distribuição e Armazenagem, diz que sistemas informatizados precisam ser qualificados e validados antes do uso. O Guia 33 é o documento da ANVISA que explica um jeito organizado de fazer isso.
Neste artigo você vai entender o que é o Guia 33, se ele é obrigatório, o que significa cada sigla com exemplos do dia a dia da distribuidora, a ordem dos trabalhos, os erros mais comuns e um checklist para conferir se a sua documentação está em ordem.
O que é o Guia 33/2020
O Guia 33/2020 é o "Guia para Validação de Sistemas Computadorizados" da ANVISA. A versão em uso é a versão 1, que passou a valer em 14 de abril de 2020. Ele substituiu um guia com o mesmo nome publicado em 2010.
Na época, a ANVISA abriu um período de sugestões do público até 12 de agosto de 2020, para uma possível revisão. Até a data desta atualização, não encontramos versão mais nova publicada. Antes de usar o guia num projeto, vale conferir no portal da ANVISA se saiu alguma revisão.
O guia se baseia no GAMP 5, um método internacional muito usado pela indústria farmacêutica para validar sistemas. A sigla vem do inglês e quer dizer, em resumo, boas práticas para sistemas automatizados.
O Guia 33 é obrigatório?
Não. O próprio texto diz que ele é um guia de recomendação, sem força de norma. A empresa pode usar outro método, desde que ele seja adequado e cumpra as exigências legais. Não seguir o guia, por si só, não é infração sanitária.
O foco original do guia são as Boas Práticas de Fabricação de medicamentos e de insumos farmacêuticos. Ou seja, ele foi escrito pensando na indústria.
Então por que ele importa para a distribuidora? Porque a obrigação de validar vem da RDC 430/2020. Ela exige que sistemas informatizados sejam qualificados e validados antes do uso e depois de mudanças importantes. O Guia 33 é a referência mais conhecida no Brasil sobre como fazer isso. Muitas distribuidoras usam o guia como modelo, ajustando o tamanho do trabalho ao risco de cada sistema.
A ANVISA não certifica sistemas
Esse é o ponto que mais confunde. Não existe "sistema certificado pela ANVISA". O que existe é:
- Uma empresa regulada pela ANVISA (a distribuidora).
- Um sistema validado dentro da operação dessa empresa.
Quem responde pela validação é a empresa que usa o sistema. O fornecedor do software ajuda, entrega documentos e participa dos testes. Mas a responsabilidade final é da distribuidora. Por isso a documentação fica com ela, pronta para a inspeção.
Validação baseada em risco
O guia pede que o esforço de validação seja proporcional ao risco. Um sistema que controla lote, validade e rastreio de medicamentos tem impacto grande na qualidade e na segurança do paciente. Um sistema usado só para agenda de reuniões, não.
Na prática, a distribuidora:
- Faz uma lista dos sistemas que usa.
- Avalia quais deles afetam as Boas Práticas (lote, validade, temperatura, rastreio, recolhimento, registros).
- Dentro de cada sistema, aponta as funções de maior risco.
- Concentra os testes e a documentação nessas funções.
O guia também usa as categorias do GAMP 5. Em resumo:
| Categoria | O que é | Exemplo |
|---|---|---|
| 1 | Programas de base | Sistema operacional, banco de dados |
| 3 | Produto pronto, usado sem configurar | Programa de leitura de um equipamento |
| 4 | Produto pronto e configurado para a empresa | Sistema de gestão (ERP) com parâmetros da distribuidora |
| 5 | Programa feito sob medida | Rotina desenvolvida só para a empresa |
Quanto maior a categoria, maior o trabalho de validação. Um ERP para distribuidora costuma ficar na categoria 4. Partes desenvolvidas sob medida entram na categoria 5.
O ciclo de vida do sistema
O guia organiza a validação em quatro fases:
- Conceito: a empresa percebe a necessidade e define o que quer.
- Projeto: planejamento, escolha do fornecedor, especificações, configuração, testes e liberação para uso.
- Operação: uso no dia a dia, com controle de mudanças, revisão periódica, cópias de segurança e controle de acesso.
- Aposentadoria: desligamento do sistema, com migração ou guarda dos dados.
As siglas abaixo aparecem principalmente na fase de projeto.
URS: o que a distribuidora precisa
A URS (do inglês User Requirements Specification) é a especificação dos requisitos do usuário. Em português, o guia também usa a sigla ERU. Ela descreve o que a empresa precisa que o sistema faça, sem falar ainda de tecnologia.
Exemplos de requisitos numa distribuidora:
- Registrar lote, validade e quantidade em toda entrada e saída.
- Impedir a venda e a separação de lote bloqueado ou vencido.
- Levar o lote e a validade para a nota fiscal.
- Listar, a partir de um lote, todos os clientes que o receberam.
- Registrar quem alterou cada dado, quando e por quê, sem apagar o dado original.
- Permitir acesso só a usuários autorizados, com perfis por função.
- Fazer cópia de segurança dos dados.
Uma dica do próprio guia: escreva requisitos claros e testáveis. "O sistema deve atender à legislação" não é um requisito, porque não dá para testar.
A URS é aprovada pelos responsáveis da distribuidora, como o responsável técnico e o gestor da área.
FS: como o sistema atende
A FS (Functional Specification) é a especificação funcional. Ela explica como o sistema atende a cada requisito da URS. Em sistemas prontos, costuma ser escrita pelo fornecedor e aprovada pela distribuidora.
Exemplo:
- URS: "impedir a separação de lote bloqueado."
- FS: "o lote tem um campo de situação. Quando a situação é 'bloqueado', ele não aparece na lista de separação e não pode ser incluído na nota."
Em sistemas configurados, existe também a especificação de configuração, que registra os parâmetros escolhidos pela empresa.
DQ: o projeto atende ao que foi pedido?
A DQ (Design Qualification) é a qualificação do projeto. É uma revisão que confirma que o desenho do sistema e as escolhas do fornecedor atendem à URS.
Na DQ, a distribuidora costuma olhar:
- Se cada requisito da URS tem uma resposta na FS.
- Como funcionam o controle de acesso e o registro de alterações.
- O plano de cópia de segurança e de recuperação dos dados.
- A avaliação do fornecedor (questionário, visita ou auditoria, conforme o risco).
IQ: foi instalado do jeito certo?
A IQ (Installation Qualification) é a qualificação da instalação. Ela comprova que o sistema foi instalado e configurado como planejado.
Registros comuns:
- Versão do sistema em uso.
- Onde o sistema roda (servidor próprio ou na internet).
- Configurações principais e perfis de acesso criados.
- Equipamentos usados no armazém, como celulares e leitores de código de barras.
Quando o sistema funciona pela internet, parte da infraestrutura fica com o fornecedor. Nesse caso, a distribuidora reúne as evidências que o fornecedor entrega e documenta a parte que é dela.
OQ: cada função funciona?
A OQ (Operational Qualification) é a qualificação de operação. São os testes que provam que cada função importante faz o que a FS promete.
Exemplos de testes numa distribuidora:
- Dar entrada numa nota de fornecedor e conferir se lote e validade foram gravados.
- Bloquear um lote e tentar separá-lo. O sistema deve impedir.
- Emitir uma nota e conferir se o lote e a validade saíram certos.
- Alterar um dado e conferir se o registro mostra quem alterou, quando e o valor antigo.
- Entrar com um usuário sem permissão e tentar uma função restrita.
- Restaurar uma cópia de segurança num ambiente de teste.
Cada teste tem: situação de partida, passos, resultado esperado, resultado obtido, data e assinatura de quem executou. Teste sem resultado registrado é teste não feito.
PQ: funciona na operação real?
A PQ (Performance Qualification) é a qualificação de desempenho. Ela mostra que o sistema funciona bem no processo real da empresa, com o volume de pedidos, os usuários e a rotina de verdade.
Exemplos:
- Acompanhar algumas semanas de operação e conferir se saldos, lotes e notas batem.
- Simular um recolhimento e medir quanto tempo leva para listar os clientes de um lote.
- Fazer um inventário e comparar o físico com o sistema.
Ordem dos trabalhos: passo a passo
- Fazer a lista de sistemas e a avaliação de risco.
- Escrever o plano de validação: o que será feito, por quem e com quais critérios.
- Escrever e aprovar a URS.
- Avaliar o fornecedor e receber a FS.
- Fazer a DQ.
- Instalar e registrar a IQ.
- Executar os testes da OQ.
- Acompanhar a operação real na PQ.
- Fechar com o relatório de validação, que diz se o sistema está liberado para uso.
- Manter o controle de mudanças e as revisões periódicas.
O tempo de cada etapa depende do tamanho da operação e do número de funções de risco.
Depois da validação: manter em dia
A validação não termina no relatório. Na fase de operação, a distribuidora precisa:
- Controlar mudanças: atualização do sistema ou nova função precisa de avaliação de impacto e, se for o caso, novos testes.
- Fazer revisões periódicas: conferir se o sistema continua validado, com frequência definida pelo risco.
- Treinar usuários e registrar o treinamento.
- Gerenciar acessos: desligar usuários que saíram da empresa.
- Testar as cópias de segurança.
Erros comuns
- URS copiada de modelo, que não reflete a operação da empresa.
- Testes da OQ sem resultado preenchido ou sem assinatura.
- Versão do sistema na IQ diferente da versão em uso.
- Atualizações sem controle de mudança.
- Validar tudo com o mesmo peso, em vez de focar nas funções de risco.
- Achar que o fornecedor resolve tudo. A responsabilidade é da distribuidora.
Checklist para a inspeção
- Lista de sistemas com avaliação de risco.
- Plano de validação aprovado.
- URS aprovada e assinada.
- FS ou documentação equivalente do fornecedor.
- Avaliação do fornecedor registrada.
- IQ com a versão em uso.
- OQ com todos os testes executados e assinados.
- PQ ou acompanhamento da operação real.
- Relatório de validação com a liberação.
- Registros de controle de mudanças e revisões periódicas.
- Procedimento de cópia de segurança e teste de restauração.
Perguntas frequentes
O Guia 33 tem versão mais nova?
A versão em uso é a versão 1, que vale desde 14 de abril de 2020. Não encontramos versão mais recente publicada até outubro de 2026. Confira no portal da ANVISA antes de iniciar um projeto.
A distribuidora é obrigada a seguir o Guia 33?
O guia não é obrigatório. Mas a RDC 430/2020 exige que os sistemas informatizados sejam qualificados e validados. O guia é a forma mais conhecida de mostrar isso de modo organizado.
Existe software "aprovado pela ANVISA"?
Não. A ANVISA não certifica sistemas de gestão. Quem valida o sistema é a empresa que o usa, dentro da própria operação.
A validação vence?
Não há prazo fixo. A validação precisa ser mantida com controle de mudanças e revisões periódicas. Mudanças grandes no sistema pedem nova avaliação e, se preciso, novos testes.
O fornecedor entrega os documentos prontos?
Em parte. O fornecedor pode entregar a FS, evidências de testes e informações para a IQ. A URS, a avaliação de risco, a PQ e o relatório final são da distribuidora. Combine antes de contratar o que o fornecedor vai entregar.
Planilha também precisa ser validada?
O Guia 33 inclui planilhas no seu escopo quando elas são usadas em atividades reguladas. Se uma planilha controla validade ou temperatura, ela entra na avaliação de risco.
Onde o KWeb entra
Vários requisitos de uma URS dependem de controle de acesso, de registro de alterações e de controle por lote. No KWeb, há verificação em duas etapas no acesso, permissões por usuário e histórico de alterações, e os produtos são controlados por lote e validade. A validação dentro da operação continua sendo da distribuidora.