A migração para eCTD v4.0 não é um projeto de substituição — é uma transição que precisa acontecer em paralelo com a operação regulatória normal. Dossiês em andamento continuam. Exigências chegam. Prazos não param.
Empresas que tratam a migração como um projeto de TI isolado geralmente se surpreendem com a complexidade. As que a tratam como uma mudança de processo — com impactos em equipes, ferramentas e fluxos de trabalho — chegam melhor preparadas.
O que não precisa mudar: compatibilidade forward
Uma das boas notícias da transição é que não é necessário converter dossiês existentes. Para FDA, EMA e ANVISA, um dossiê iniciado em v3.2.2 pode continuar em v3.2.2. A migração para v4.0 se aplica a novos dossiês — não a dossiês em andamento.
Exceção importante: o Japão (PMDA) não permite troca de versão eCTD após o início do dossiê. Se você tem ou planeja submissões no Japão, a decisão de versão precisa ser feita antes da sequência 0000.
Isso significa que a transição pode ser gradual: novos dossiês em v4.0, dossiês existentes mantidos em v3.2.2 até sua conclusão natural. O período de operação dual — com equipes gerenciando ambas as versões — precisa ser planejado.
O que precisa mudar: sistemas e pessoas
O software de eCTD precisa suportar v4.0. Isso parece óbvio, mas o prazo de entrega dos fornecedores varia muito. Alguns já têm suporte completo; outros têm roadmaps para 2025-2026. Confirme com seu fornecedor atual qual é o status e qual é o prazo contratual de entrega.
As equipes precisam entender o novo modelo conceitual — especialmente o Context of Use, que não tem equivalente direto na v3.2.2. Treinamento antes da primeira submissão é essencial. O CoU não é algo que se aprende errando em produção.
Os processos internos de criação e aprovação de documentos precisam ser revisados. Os UUIDs que a v4.0 exige são gerados automaticamente pelo software, mas o mapeamento de documentos para suas posições CTD — os Contexts of Use — precisa ser planejado com cuidado para cada tipo de dossiê.
Um roteiro prático
Comece com um inventário: quais dossiês estão ativos em v3.2.2, quais novos dossiês são esperados nos próximos 18 meses, e qual é o prazo regulatório de v4.0 para cada agência-alvo.
Em seguida, confirme o status do software: seu fornecedor tem v4.0? Em qual versão está? Peça uma demonstração com um dossiê real — não com os exemplos de treinamento do fornecedor.
Depois, planeje o treinamento. A equipe de regulatory affairs precisa entender CoU e UUIDs antes de configurar o primeiro dossiê v4.0. A equipe de TI precisa entender os novos requisitos de validação.
Por fim, escolha um dossiê piloto: um dossiê novo, de baixo risco regulatório, para a primeira submissão em v4.0. Os aprendizados desse piloto vão calibrar o processo para os dossiês seguintes.
