ICH Q12: lifecycle CMC com mapa de mudança

Toda planta conhece a situação: uma melhoria pequena no processo — uma faixa um pouco mais estreita, um site alternativo, um ajuste analítico — e o cronograma regulatório passa a ditar o ritmo da operação. Variação, dossiê, fila de análise, revalidação que parece reabrir mais do que o necessário. Parte desse peso é real e necessária. Parte nasce da falta de uma distinção clara entre o que é condição estabelecida do produto e o que é informação de suporte.

O ICH Q12 (Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management), finalizado 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 resolve o problema sozinho: é um framework. Em uma planta com registro eletrônico, o Q12 só ajuda se a equipe souber o que mudou de fato no system of record.

O problema que o Q12 tenta tratar

A globalização da cadeia de suprimentos e as regras regionais diferentes transformaram o pós-aprovação em uma fila com complexidade regional. O Q12 oferece uma linguagem comum para:

• Established Conditions (ECs): informação considerada necessária para assegurar a qualidade e que, se alterada, exige submissão ou 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, desde que 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 vale dizer "implícita", porque a implementação regional não é uniforme (ver a assimetria UE vs. FDA adiante) — é uma gestão de lifecycle com menos processo apenas documental e mais combinação de ciência, PQS e diálogo regulatório, sem reabrir validação desnecessária a cada ajuste menor.

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

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

No chão de fábrica, a pergunta do Q12 se desdobra em três:

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

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

• Tudo vira variation. A melhoria congela. A operação passa a contornar o processo, e o contorno não aparece no PLCM de ninguém.
• Nada vira EC na prática. A configuração muda sem registro adequado, o dossiê fica defasado e a inspeção encontra divergência entre o que foi registrado e o que está em execução.

O sistema eletrônico não resolve a classificação regulatória por si só. O que ele faz é tornar a classificação cobrável: versão da master, diff do que mudou, trilha de quem aprovou, vínculo com o change control. Sem isso, o Q12 fica na apresentação e a configuração do MES fica sem governança.

PACMP: previsibilidade com disciplina de evidência

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

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

PLCM: mapa, não arquivo morto

O Product Lifecycle Management document (no sentido do Q12) concentra ECs, categorias de reporte, PACMPs e compromissos. Só funciona se for atualizado quando o produto ou o processo mudam — e se apontar para onde a informação operacional de fato reside.

Em uma planta digital, atualizar o PLCM sem atualizar a receita mestra versionada é uma atualização desencontrada: o plano e a configuração do chão de fábrica deixam de refletir a mesma realidade. Os dois precisam estar alinhados. O PLCM não substitui o PQS (Q10); ele se apoia nele. O Q12 é explícito ao se posicionar como complemento do Q10 no pós-aprovação comercial.

O que o mapa de mudança não significa

Vale deixar isso claro desde o início, para evitar overclaim:

• Não significa eliminar validação ou qualificação quando o risco as exige.
• Não significa que uma EC muda "apenas com ticket de TI".
• Não significa que toda jurisdição trata cada EC da mesma forma e no mesmo prazo — a implementação regional importa, e o time regulatório local precisa participar da decisão.
• Não significa que um MES "é Q12 compliant" como selo. O Q12 trata da relação MAH–autoridade e do PQS; o software é ferramenta de evidência e controle.

A formulação útil é outra: com ECs claras e PQS robusto, muitas mudanças deixam de ser surpresa sem caminho definido e passam a ter rota conhecida — incluindo o caminho regulatório quando uma EC é de fato alterada.

Ponte com o que já escrevemos na série ICH

• Q9: classificar o impacto de uma mudança em EC versus suporte sem reavaliar o risco fica incompleto — falta um método de risco documentado e gerido.
• Q10: o Q12 pressupõe um PQS capaz de gerir mudança; organograma não basta.
• Q8/Q11 → chão: design space e estratégia de controle alimentam a discussão sobre 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, o Q12 vira um curso isolado de Assuntos Regulatórios.

Onde o system of record ajuda de fato

Sem overclaim, o que costuma ajudar:

• Versionamento de receita e de regras de controle com diff legível para Qualidade e Assuntos Regulatórios — não apenas um "publish" opaco.
• Change control que obriga a classificar: afeta EC? afeta o dossiê? apenas o PQS? Com referência ao PLCM/PACMP quando existir.
• Trilha de auditoria da configuração crítica (limites, gates, sequência) com o mesmo rigor que o MBR em papel exigia.
• Vínculo lote → versão da master para comprovar o que estava vigente quando o lote foi executado — base de qualquer discussão de lifecycle em inspeção.

Plataformas como o NEO EBR entram aqui como system of record de execução e de mudança — com capacidade de registrar, versionar e vincular evidência —, não como substituto do diálogo com a autoridade nem como garantia de resultado regulatório.

Incerteza regulatória (para Assuntos Regulatórios e Qualidade)

Os detalhes de categoria de variation ou suplemento (ANVISA, EMA/UE, FDA etc.) mudam em formato e em prazo. O Q12 oferece um framework comum (ECs, suporte, PACMP, PLCM); não homogeneíza a prática local. Em especial, a implementação de ECs e o reconhecimento do 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 as ferramentas do Q12 não previstas nesse marco não podem ser usadas como atalho operacional. Produtos legados podem não ter ECs no formato do Q12. A relação entre design space aprovado e ECs é definida caso a caso com Assuntos Regulatórios. Este artigo é educativo; não substitui assessment regulatório nem a conversa MAH–autoridade.

Se algum ponto daqui for levado a uma conversa com cliente regulado, a verificação local é obrigatória, não um detalhe.

Uma sequência prática (planta + Assuntos Regulatórios)

1. Escolha um produto piloto. Liste o que hoje a equipe trata como intocável sem variation e o que muda "apenas na fábrica". Compare com a lógica de EC versus suporte.
2. No MES/EBR, faça um inventário dos últimos seis meses de mudanças de configuração em limites e sequência. Quantas passaram por change control formal? Quantas teriam afetado uma EC?
3. Se houver PACMP (ou plano de ter um), registre quais evidências o system of record já produz e quais ainda dependem de esforço manual.
4. Ajuste o formulário de mudança: inclua um campo explícito de impacto em EC/PLCM, com a opção "não se aplica" auditável.
5. Só então fale em "agilidade de lifecycle". Agilidade sem mapa é apenas pressa.

Fechamento

O ICH Q12 não promete lifecycle sem trabalho. Promete, dentro do framework, lifecycle com mapa: o que é Established Condition, o que o PQS cobre, o que um PACMP já acordou com a autoridade. Em uma planta com registro eletrônico, esse mapa só vale se a configuração do system of record for tão governada quanto o dossiê que ela executa.

Sem isso, continuamos reabrindo validação desnecessária ou, pior, alterando configuração sem perceber o impacto regulatório. A diferença entre os dois cenários costuma estar menos na apresentação sobre o Q12 e mais no último hard gate que alguém ajustou "só um pouco" na sexta-feira.