Um ciclo de descontaminação de VHP pode ser aprovado em todas as séries de produção e, mesmo assim, resultar em um pacote de qualificação que não seja suficiente para uma auditoria. A lacuna não está no desempenho, mas nas evidências. Saber quais registros devem constar em cada etapa e quem é responsável por gerá-los e aprová-los determina se um sistema de VHP já instalado está realmente pronto para ser entregue ou apenas pronto para uso.
A rastreabilidade começa com o URS aprovado e a base de projeto
| Item de rastreabilidade | Requisito aprovado | Base de projeto | Evidências aplicáveis de FAT, SAT, IQ ou OQ | Disposição final |
|---|---|---|---|---|
| Cada requisito aprovado do URS (uma linha por requisito) | Identificador e redação dos requisitos específicos do projeto | Documento de projeto de apoio ou decisão de projeto registrada | Registro que atenda ao requisito na(s) etapa(s) aplicável(is) | Desvio aprovado, conclusão, gatilho de alteração ou gatilho de requalificação, conforme o caso |
A confiabilidade de um pacote de qualificação do sistema VHP depende inteiramente de seu ponto de partida: a especificação de requisitos do usuário aprovada e os documentos de projeto que a atendem. Quando um requisito consta na URS, mas não possui correspondência visível na base de projeto, esse requisito já se perdeu antes mesmo do início do FAT, e nenhuma etapa de teste posterior consegue recuperá-lo. Essa é a razão prática pela qual o planejamento da qualificação não pode começar em FAT ou SAT — Nesse ponto, o conjunto de requisitos já foi transportado corretamente ou não.
O que altera essa avaliação é a forma como o próprio URS foi redigido. Um URS que defina resultados funcionais em termos verificáveis fornece à base de projeto algo concreto ao qual se basear e oferece aos testes FAT, SAT, IQ e OQ uma referência comum para o que significa “atender ao requisito”. Um URS que defina intenções de forma vaga obriga a equipe de projeto — e, posteriormente, a equipe de qualificação — a interpretar o que se pretendia, e essa interpretação pode não resistir ao questionamento de um auditor que pergunte onde um determinado requisito foi verificado. Anexo 15 do EudraLex aborda essa questão diretamente ao vincular o URS à qualificação do projeto e ao exigir que essa qualificação se baseie em fundamentos aprovados e rastreáveis, em vez de suposições.
No caso específico de um sistema VHP — em que os parâmetros do ciclo, o posicionamento dos sensores, a configuração da câmara ou do compartimento e a compatibilidade dos materiais decorrem, em sua totalidade, de decisões específicas do projeto —, a base de projeto é onde essas decisões são registradas como referência, em relação à qual todos os testes posteriores são avaliados. Se um requisito for alterado após o congelamento do projeto, o registro de rastreabilidade é onde essa alteração é incorporada aos testes FAT, SAT, IQ e OQ ou simplesmente desaparece sem deixar rastros.
A tarefa do comprador nesta fase não é produzir mais documentação; é confirmar que cada requisito aprovado tenha um caminho claro para, pelo menos, uma etapa de qualificação. Quando um requisito não tiver esse caminho, esse é o momento de levantá-lo — não durante a IQ (Inspeção de Qualificação) e nem durante uma inspeção regulatória. Esse também é o momento em que as informações fornecidas pela equipe do projeto sobre uso pretendido, utilidades, interfaces das salas e condições operacionais passam a fazer parte da análise da configuração ou da cotação do fornecedor, pois a base de projeto proposta pelo fornecedor depende do grau de completude com que essas informações foram definidas desde o início.
A FAT confirma as funções configuradas antes da entrega
| Estágio | Foco nas evidências primárias | Limite de decisão do projeto |
|---|---|---|
| FAT | Funções configuradas que podem ser testadas antes da remessa | Utilize as evidências fornecidas pelo fornecedor somente quando for justificado e após avaliação com base em critérios pré-definidos do projeto |
| SAT | Instalação, infraestrutura local, interfaces e funções afetadas pelo transporte ou pela integração | Verifique a condição específica do local, em vez de presumir que o resultado do FAT já a abrange |
Os testes de aceitação em fábrica existem porque algumas funções podem ser verificadas antes mesmo de um sistema VHP sair das instalações do fornecedor, e verificá-las antecipadamente reduz o número de incógnitas que a equipe do projeto precisa resolver no local. As funções que realmente devem ser avaliadas nos FAT são aquelas que dependem da própria configuração do equipamento — lógica de controle, parâmetros configurados, resposta dos sensores internos, desempenho do gerador nas condições de teste do fornecedor — e não da forma como o sistema será instalado nas instalações do destinatário.
A distinção que importa aqui é o que o FAT pode representar em comparação com o que ele não pode. Um ambiente de teste do fornecedor pode confirmar que um gerador de VHP se comporta conforme configurado quando alimentado pelas redes de serviços e condições disponíveis nesse ambiente. Ele não pode confirmar como o mesmo sistema se comporta uma vez conectado às redes de serviços reais do projeto, integrado aos sistemas de aeração ou monitoramento da sala de recebimento, ou instalado no local físico que o projeto construiu para ele. O Anexo 15 reconhece isso ao permitir que as evidências do FAT substituam a repetição do mesmo teste no SAT, mas somente quando essa confiança for justificada e as evidências do FAT forem avaliadas com base em critérios predefinidos acordados antes do teste, e não depois.
Isso tem uma consequência direta sobre a forma como uma equipe de projeto planeja seus protocolos. Se os critérios de aceitação do FAT forem redigidos de forma vaga, ou acordados somente após a execução do teste, as evidências do FAT fornecidas pelo fornecedor tornam-se menos confiáveis posteriormente, pois um auditor ou revisor de qualificação não tem base documentada para considerá-las equivalentes a um teste no local. Quando os critérios do FAT são definidos com antecedência, vinculados a funções específicas configuradas e formalmente aceitos, essas evidências podem legitimamente reduzir o que o SAT precisa repetir.
A tarefa da equipe do projeto nesta fase é identificar, função por função, quais itens são genuinamente dependentes da configuração e testáveis nas instalações do fornecedor, e quais dependem de condições locais que ainda não existem no FAT. Confundir essas duas categorias é o que mais tarde gera controvérsias sobre se o SAT é redundante ou se o FAT foi insuficiente.
O SAT resolve questões relacionadas a utilidades do local, interfaces e efeitos da instalação
O teste de aceitação no local existe especificamente para verificar o que o FAT não consegue: como o sistema VHP se comporta depois de instalado em seu local de destino, conectado aos serviços de utilidade pública do próprio local e integrado às interfaces fornecidas pela instalação receptora. O transporte, a instalação e a conexão aos serviços específicos do local são, por si só, eventos que podem alterar o comportamento do equipamento; portanto, o SAT não é uma repetição do FAT com outro nome — ele visa uma categoria diferente de risco.
Os recursos que importam aqui são aqueles dos quais a instalação específica do VHP depende para seu funcionamento, e as interfaces que importam são aquelas que conectam o sistema à sala, ao processo ou à infraestrutura de monitoramento e controle da instalação. Quando um sistema está sendo integrado à ventilação da sala, a pontos de passagem ou ao monitoramento em nível da instalação, o SAT é onde o comportamento combinado do sistema e de suas interfaces é verificado pela primeira vez, pois nenhum ambiente de teste do fornecedor reproduz essa combinação.
O fator que determina o escopo do SAT é o grau de dependência do funcionamento do sistema em relação à instalação específica no local, em comparação com o que já era totalmente testável no FAT. Um sistema com conexões simples de serviços públicos e dependência mínima da interface com o local pode ter um escopo de SAT mais restrito, pois a maior parte de seu funcionamento já havia sido confirmada anteriormente. Um sistema integrado a uma infraestrutura complexa de ambiente, com intertravamentos ou monitoramento compartilhados entre vários equipamentos, apresenta um escopo de SAT mais amplo, pois grande parte de seu comportamento só se torna observável após a instalação.
O risco prático que esta etapa se destina a identificar é a suposição de que uma função verificada no FAT continue válida após o transporte e a instalação. O apoio do Anexo 15 à confiança justificada no FAT não se estende a funções dependentes do local; ele se aplica apenas quando a função em si não foi afetada pela instalação. Para uma equipe de projeto, a disciplina consiste em tratar o SAT como a etapa que confirma especificamente os efeitos da instalação e as interfaces com o local, em vez de considerá-lo uma formalidade que revisita o que já foi abordado no FAT.
O IQ documenta o sistema instalado e calibrado
A qualificação da instalação consiste na comparação entre o estado real do sistema VHP e o que foi especificado, desenhado e encomendado. Essa comparação abrange desenhos, componentes instalados, conexões de serviços públicos e o status da calibração, e tem como objetivo estabelecer uma referência documentada do que foi efetivamente instalado, e não do que estava planejado para ser instalado.
A razão pela qual essa reconciliação é importante como uma etapa independente, distinta do FAT ou do SAT, é que a instalação pode se desviar da intenção do projeto de maneiras que não constituem falhas funcionais, mas sim lacunas na documentação. Um componente substituído por uma peça equivalente, uma conexão de serviço público com trajeto diferente do desenhado ou uma calibração realizada com base em uma referência diferente da especificada originalmente — nada disso afeta necessariamente o desempenho operacional, mas cada um desses casos, se não for documentado, rompe a cadeia de rastreabilidade até a base de projeto aprovada. A IQ é onde essas divergências são identificadas e, ou aceitas por meio de uma justificativa documentada, ou corrigidas antes que a qualificação prossiga.
Requisitos do Anexo 11 Os requisitos rastreáveis do usuário e os registros documentados do sistema se aplicam aqui sempre que o sistema VHP incluir controle computadorizado, uma vez que a condição instalada e calibrada de qualquer elemento computadorizado relevante para as BPF requer a mesma reconciliação que os componentes físicos. Quando a lógica de controle, o tratamento de dados ou a configuração da trilha de auditoria fazem parte do sistema instalado, a IQ é a etapa que determina se essa configuração corresponde ao que foi especificado e aprovado, e não a OQ, que pressupõe que a condição instalada já esteja correta e, em vez disso, testa como o sistema se comporta.
O fator que determina o grau de complexidade dessa reconciliação é a própria complexidade do sistema instalado. Uma unidade autônoma simples possui menos componentes e sistemas a serem reconciliados. Um sistema integrado a sistemas compartilhados do edifício, controles em rede ou múltiplos instrumentos calibrados apresenta uma lista de reconciliação mais extensa, e cada interface adicional representa mais um ponto em que a condição real pode divergir da base de projeto. A tarefa da equipe do projeto é confirmar que o registro de IQ leve em conta todos os sistemas, componentes e instrumentos calibrados especificados na base de projeto, e não apenas aqueles que são mais fáceis de verificar.
OQ: Desafios relacionados a limites operacionais, alarmes e respostas a falhas
| Área de desafios da OQ | O protocolo deve definir previamente | Evidências necessárias para a conclusão |
|---|---|---|
| Faixas de operação | Intervalo específico do projeto para critérios de desafio e aceitação | Resultados brutos em toda a faixa contestada e a conclusão aprovada |
| Alarmes | Condições do desafio, respostas esperadas e critérios de aceitação | Registros de desafios de alarme, desvios e a conclusão aprovada |
| Intertravamentos | Condições do desafio, respostas esperadas e critérios de aceitação | Registros de desafios do sistema de intertravamento, desvios e a conclusão aprovada |
| Cenários de interrupção e recuperação | Cenário, respostas esperadas em caso de interrupção e recuperação, e critérios de aceitação | Registros de cenários, desvios e a conclusão aprovada |
Qualificação operacional É nesse estágio que o sistema VHP é submetido a testes para verificar se está dentro das faixas operacionais aprovadas, suas respostas a alarmes, seus intertravamentos e seu comportamento em cenários de interrupção e recuperação. Enquanto a IQ confirma que o sistema foi instalado e calibrado conforme especificado, a OQ confirma que o sistema instalado realmente se comporta da maneira pretendida quando operado, inclusive quando é deliberadamente levado ao limite ou colocado em condições de falha.
Cada uma dessas categorias de teste exige um tipo diferente de comprovação. Os testes de faixa operacional requerem um protocolo que defina, antecipadamente, a faixa específica que está sendo testada e os critérios para um resultado aceitável — os parâmetros de um ciclo de VHP são específicos do projeto, portanto, a base de aceitação deve ser estabelecida para aquele sistema, em vez de ser presumida com base na prática geral. Os testes de alarme e intertravamento exigem condições de acionamento definidas e uma resposta esperada, confirmadas por meio de registros que demonstrem que o sistema respondeu conforme especificado quando essa condição foi deliberadamente criada. Os cenários de interrupção e recuperação exigem que essa mesma disciplina seja estendida ainda mais: um cenário definido, um comportamento esperado de interrupção, um comportamento esperado de recuperação e uma base predefinida para avaliar se ambos foram aceitáveis.
O que une essas categorias é o fato de que nenhuma delas pode ser verificada de maneira informal. A confirmação por parte de um operador de que “o alarme funcionou” durante o comissionamento não equivale a um registro de teste que mostre a condição específica criada, a resposta observada e a conclusão alcançada em relação a um critério acordado antes do teste. Essa é a distinção que o Anexo 15 reforça ao exigir critérios de aceitação predefinidos e desvios documentados — um desvio encontrado durante a OQ não constitui uma falha no exercício de qualificação, mas requer uma disposição aprovada antes que o resultado possa ser considerado confiável.
O fator que determina a profundidade necessária do OQ é o grau em que a função de segurança ou de proteção do produto do sistema depende da resposta dinâmica em comparação com a configuração estática. Um sistema cuja função de proteção é ativada apenas em condições de falha precisa que essas condições sejam efetivamente criadas e observadas, pois uma análise estática da lógica de controle não é capaz de confirmar o comportamento dinâmico. Nos casos em que os ciclos do VHP interagem com outros equipamentos — passagens, pontos de transferência BIBO ou monitoramento em nível de sala —, o escopo da OQ deve determinar se essas interações serão avaliadas como parte da qualificação desse sistema ou tratadas separadamente, e esse limite precisa estar explicitado no protocolo, em vez de ser apenas presumido.
A transferência encerra os desvios, os registros e os gatilhos de requalificação
| Grupo de registros | Entregar as provas a serem mantidas | Limite de decisão |
|---|---|---|
| Protocolos aprovados | Critérios de aceitação predefinidos e a base de testes aprovada | Os testes e critérios exatos variam de acordo com cada projeto |
| Desvios | Registros de desvios aprovados e seu efeito sobre o resultado ou conclusão em questão | Um desvio requer uma medida aprovada, e não uma exceção não documentada |
| Divisão de responsabilidades | Documentação fornecida pelos fornecedores e as decisões correspondentes sobre a qualificação das instalações | As evidências do fornecedor não determinam a decisão sobre o local, a menos que essa responsabilidade seja explicitamente atribuída |
| Evidências do ciclo final | Definição de carga representativa, posicionamento de sensores e indicadores, registros brutos e conclusões | Os resultados dos indicadores não substituem as medições físicas nem definem um ciclo universal |
| Mudança e requalificação | Fatores desencadeadores definidos de mudança ou requalificação | As condições de acionamento continuam sendo específicas à base do projeto aprovado |
Um pacote de qualificação só está completo quando cada desvio identificado durante o FAT, SAT, IQ ou OQ tiver uma disposição aprovada, quando os critérios predefinidos de cada protocolo e a base de teste aprovada forem mantidos no registro final, e quando a distinção entre as evidências fornecidas pelo fornecedor e as decisões de qualificação da unidade for explícita, em vez de presumida. Uma exceção não documentada — um resultado que foi aceito informalmente sem uma justificativa registrada — é a razão mais comum pela qual um pacote de qualificação não consegue sustentar uma inspeção, pois a ausência de uma resolução documentada não deixa nenhuma base para que um auditor compreenda por que um resultado anômalo foi considerado aceitável.
A divisão de responsabilidades é importante porque um sistema VHP fornecido e qualificado por meio de uma parceria com um fornecedor gera duas categorias de registros: o que o fornecedor testou e documentou e o que a equipe de qualificação da unidade concluiu e aprovou. Os registros do fornecedor podem servir de base para uma decisão da unidade, mas não a substituem, a menos que essa responsabilidade tenha sido explicitamente atribuída no plano de qualificação do projeto. Quando essa atribuição não estiver clara, o pacote de transferência corre o risco de conter registros que pareçam completos, mas que, na verdade, não deixem claro quem aprovou o quê.
No que diz respeito especificamente aos dados do ciclo final, Anexo 1 das BPF da UE Fica explícito que a validação da esterilização ou descontaminação se baseia em medições físicas, com indicadores biológicos ou químicos utilizados quando apropriado e posicionados em locais adequados — os resultados dos indicadores não substituem as medições físicas, e nenhum deles substitui uma carga definida e representativa. Um pacote de transferência para um sistema de VHP precisa conter a definição de carga representativa utilizada durante a qualificação, a localização dos sensores e indicadores, os registros brutos dos testes de qualificação e as conclusões extraídas deles, pois uma revisão futura do desempenho do ciclo depende da capacidade de reconstruir o que foi efetivamente testado, e não apenas o que consta no relatório resumido.
O elemento final é o conjunto de condições que desencadearia uma reavaliação ou uma requalificação — uma modificação na configuração da carga, uma alteração nas interfaces da sala, uma alteração no sistema de controle ou qualquer outra condição que a base de qualificação do projeto identifique como relevante. Esses gatilhos são específicos à base do projeto aprovado, e não genéricos; é por isso que precisam ser declarados explicitamente no pacote de transferência, em vez de serem deixados para que um revisor futuro os deduza. Equipamentos como, por exemplo, um Gerador de peróxido de hidrogênio VHP configurado para um projeto específico entra em operação com base nesse conjunto exato de registros, e a integridade desse conjunto de registros é o que determina se o sistema poderá ser mantido, modificado ou requalificado posteriormente sem a necessidade de reconstruir a base de qualificação a partir da memória.
Perguntas frequentes
Q: O que deve ser acordado antes da elaboração dos protocolos de FAT, SAT, IQ e OQ?
A: Comece com o URS aprovado, as decisões de projeto documentadas, os critérios de aceitação específicos do projeto e uma separação clara entre os registros do fornecedor e as decisões de qualificação do local. Para as evidências do ciclo final, defina também a carga representativa e os locais planejados para os sensores e indicadores, de modo que o protocolo possa produzir evidências que correspondam à conclusão pretendida.
Q: Quando as evidências do FAT podem ser incluídas no pacote de qualificação do local?
A: Isso pode atender a um requisito quando a função configurada e testada continua sendo aplicável e seu uso é justificado de acordo com critérios pré-definidos do projeto. A instalação, os utilitários, as interfaces e as funções afetadas pelo transporte ou pela integração ainda precisam passar por uma verificação específica para o local, em vez de se partir do pressuposto de que o resultado do FAT continua sendo suficiente.
Q: Como deve ser tratada uma alteração nos requisitos após o FAT no registro de rastreabilidade?
A: Atualize o mapeamento entre requisitos e evidências e identifique quais documentos de projeto, testes, conclusões ou gatilhos de requalificação são afetados. O pacote de transferência deve preservar a alteração e sua disposição aprovada, de modo que o registro original do FAT não seja considerado como evidência para uma condição que não foi testada.
Q: Quem deve decidir se um desvio é aceitável no momento da entrega?
A: O protocolo deve atribuir essa responsabilidade explicitamente e exigir uma medida aprovada vinculada ao resultado ou conclusão afetada. Um registro de desvio do fornecedor pode documentar o que ocorreu, mas não deve ser tratado como a decisão de qualificação da unidade, a menos que essa autoridade tenha sido claramente atribuída.
Q: Os resultados dos indicadores, por si só, demonstram que um ciclo do VHP é aceitável?
A: Não. Os resultados dos indicadores não substituem as medições físicas nem estabelecem um ciclo universal. A conclusão deve seguir os critérios aprovados do projeto e manter a definição de carga representativa, o posicionamento dos sensores e indicadores, os registros brutos, os desvios e a conclusão final aprovada.
