ICH Q12: lifecycle sem revalidar o mundo

Toda planta conhece a sensação: uma melhoria pequena no processo — faixa um pouco mais estreita, site alternativo, ajuste analítico — e de repente o calendário regula a vida. Variação, dossier, fila, revalidação que parece reabrir o universo. Parte desse peso é real e necessária. Parte nasce de não distinguir, com clareza, o que é condição estabelecida do produto e o que é informação de suporte.

ICH Q12 (Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management), final em Step 4 em 20 de novembro de 2019, existe para tornar a gestão de mudanças CMC pós-aprovação mais previsível e eficiente ao longo do ciclo de vida comercial — em diálogo com Q8(R2), Q9, Q10 e Q11. Não é varinha. É framework. E no chão eletrônico, ele só ajuda se a planta souber o que mudou de verdade no system of record.

O problema que Q12 tenta endereçar

Globalização de supply chain e regras regionais diferentes tornaram o pós-aprovação um labirinto. Q12 oferece linguagem comum para:

• Established Conditions (ECs): informação considerada necessária para assegurar qualidade e que, se alterada, exige submissão/comunicação conforme o marco aplicável;
• informação de suporte: o que pode mudar sob o PQS sem o mesmo tipo de submissão, quando bem delimitado;
• PACMP: protocolo acordado com a autoridade para preparar e verificar mudanças futuras com mais previsibilidade;
• documento PLCM: repositório do plano de lifecycle (ECs, categorias de reporte, PACMPs, compromissos CMC).

A promessa implícita — e é bom dizer “implícita”, porque a implementação regional não é uniforme (ver assimetria UE vs FDA abaixo) — é lifecycle com menos teatro e mais combinação de ciência + PQS + diálogo regulatório. Sem revalidar o mundo a cada parafuso.

ECs: o que muda (e o que não) quando o sistema é eletrônico

No papel, a master recipe e o dossier já brigavam por atenção. No eletrônico, aparece uma terceira superfície: a configuração do EBR/MES — limites, gates, sequência, regras de exceção, integrações.

A pergunta de Q12 no chão vira:

1. Quais elementos da receita e do controle são ECs (ou mapeiam diretamente a ECs)?
2. Quais são suporte / parâmetros de operação sob PQS?
3. Quando alguém altera a configuração, isso toca EC, toca só PQS, ou toca os dois?

Se a planta não tem essa distinção, duas falhas opostas aparecem:

• Tudo vira “variation.” Melhoria congela. Pessoas contornam. O contorno não entra no PLCM de ninguém.
• Nada vira EC na prática. Configuração muda no silêncio; o dossier fica para trás; a inspeção encontra duas verdades.

Sistema eletrônico não resolve a classificação regulatória sozinho. Ele torna a classificação cobrável: versão da master, diff do que mudou, trilha de quem aprovou, ligação ao change control. Sem isso, Q12 no slide e caos no admin do MES.

PACMP sem romance

O Post-Approval Change Management Protocol é acordo prévio: que mudança, como avaliar impacto, que estudos, que critérios, que categoria de reporte sugerida. Pode cobrir uma mudança ou um conjunto; um produto ou, em certos desenhos, múltiplos — sempre sob o que a autoridade aprovou.

Para o time de Qualidade e Assuntos Regulatórios, o PACMP é previsibilidade. Para a planta, é disciplina antecipada: se o protocolo assume certos controles e evidências, o system of record precisa conseguir gerar essas evidências sem mutirão. Caso contrário, o PACMP vira outro documento que a operação não consegue cumprir no prazo.

PLCM: mapa, não gaveta

O Product Lifecycle Management document (no sentido de Q12) concentra ECs, categorias, PACMPs e compromissos. Só funciona se for atualizado quando a vida muda — e se apontar para onde a verdade operacional vive.

Em planta digital, “atualizar o PLCM” sem atualizar a receita mestra versionada é teatro coordenado. Os dois precisam conversar. O PLCM não substitui o PQS (Q10); ele se apoia nele. Q12 é explícito em complementar Q10 no pós-aprovação comercial.

O que “sem revalidar o mundo” não significa

Vale o antídoto cedo, para não virar overclaim:

• Não significa acabar com validação/qualificação quando o risco pede.
• Não significa que EC muda “só com ticket de TI”.
• Não significa que toda jurisdição trata cada EC do mesmo jeito no mesmo prazo — a implementação regional importa; o time regulatório local precisa estar na mesa.
• Não significa que MES “é Q12 compliant” como selo. Q12 é sobre relação MAH–autoridade e sobre PQS; o software é ferramenta de evidência e controle.

A frase útil é outra: com ECs claros e PQS forte, muita mudança deixa de ser surpresa existencial — e passa a ter caminho conhecido (incluindo caminho regulatório quando EC muda de fato).

Ponte com o que já escrevemos na fila ICH

• Q9: classificar impacto de mudança em EC versus suporte sem reabrir risco é chute elegante.
• Q10: Q12 presume PQS capaz de gerir mudança; organograma não basta.
• Q8/Q11 → chão: design space e estratégia de controle alimentam a conversa de o que pode ser EC e o que permanece sob controle de processo — desde que o EBR imponha o que o desenvolvimento assumiu.

Sem essas pontes, Q12 vira curso isolado de Affairs.

Onde o system of record ajuda de verdade

Sem vender milagre, o que costuma ajudar:

• Versionamento de receita e de regra de controle com diff legível para Qualidade e RA — não só “publish” opaco.
• Change control que obriga classificar: toca EC? toca dossier? só PQS? referência ao PLCM/PACMP quando existir.
• Trilha de configuração crítica (limites, gates, sequência) no mesmo rigor que o MBR de papel exigia.
• Ligação lote → versão da master para provar o que estava vigente quando o lote rodou — base de qualquer discussão de lifecycle sob inspeção.

Plataformas como o NEO EBR entram aqui como system of record de execução e mudança — não como substituto do diálogo com a autoridade.

Incerteza regulatória (para Soc e RA)

Detalhes de categoria de variation/suplemento (ANVISA, EMA/UE, FDA, etc.) mudam de forma e de prazo. Q12 oferece framework comum (ECs, suporte, PACMP, PLCM); não homogeneíza a prática local. Em especial: a implementação de ECs e o reconhecimento de documento PLCM variam entre regiões — a FDA avançou com orientações de implementação; na UE, o marco legal de variations prevalece sobre o guia, e ferramentas Q12 não previstas nesse marco não se usam como atalho operacional “textbook”. Produto legado pode não ter ECs no formato Q12. Relação design space aprovado ↔ ECs é caso a caso com RA. Este artigo é educativo; não substitui assessment regulatório nem conversa MAH–autoridade.

Pontos que permanecem abertos na prática:

• Nem todo produto legado terá ECs no formato “Q12 textbook”; a transição é trabalho regulatório, não só IT.
• Relação entre design space aprovado e ECs pede leitura caso a caso com RA — este artigo não substitui essa análise.

Se algo aqui for usado em conversa com cliente regulado, a checagem local é porta, não detalhe.

Uma sequência prática (planta + RA)

1. Escolha um produto piloto. Liste o que hoje a equipe trata como intocável sem variation — e o que muda “só na fábrica”. Compare com a lógica de EC versus suporte.
2. No MES/EBR, inventarie os últimos seis meses de mudanças de configuração em limites/sequência. Quantas tiveram change control formal? Quantas teriam tocado EC?
3. Se houver (ou houver plano de) PACMP, escreva quais evidências o system of record já produz — e quais ainda são mutirão.
4. Ajuste o formulário de mudança: campo explícito de impacto em EC/PLCM, com “não se aplica” auditável.
5. Só então fale em “agilidade de lifecycle”. Agilidade sem mapa é só pressa.

Fechamento

ICH Q12 não promete lifecycle sem trabalho. Promete — no framework — lifecycle com mapa: o que é Established Condition, o que o PQS cobre, o que um PACMP já combinou com a autoridade. Em planta eletrônica, o mapa só vale se a configuração do system of record for tão governada quanto o dossier que ela executa.

Sem isso, a gente continua revalidando o mundo — ou, pior, mudando o mundo sem perceber. A diferença entre os dois costuma estar menos no slide de Q12 e mais no último hard gate que alguém alterou “só um pouquinho” na sexta-feira.