Existe uma categoria de problema em submissões eCTD que frustra equipes inteiras: a rejeição técnica por PDF incorreto. O dossiê está completo, os dados estão certos, o XML foi validado — e mesmo assim a submissão volta porque um arquivo não está no formato PDF/A.
PDF/A não é um capricho burocrático. É um padrão de preservação de longa duração — e entender por que ele existe ajuda a evitar os erros mais comuns.
Por que PDF/A e não PDF comum
Um dossiê regulatório precisa ser legível décadas depois de submetido. O PDF comum permite dependências externas: fontes não incorporadas, links para recursos online, scripts JavaScript, conteúdo encriptado. Tudo isso pode tornar o arquivo ilegível no futuro — ou simplesmente numa máquina diferente da usada para criá-lo.
O PDF/A — especificamente o PDF/A-1b exigido pelo eCTD — elimina essas dependências. Todas as fontes precisam estar incorporadas no arquivo. Links externos são proibidos. Encriptação e senhas são proibidas. Scripts são proibidos. O arquivo precisa ser autossuficiente e abrível por qualquer leitor de PDF sem depender de recursos externos.
Os erros mais comuns
Fontes não incorporadas são a causa número um de rejeição. Isso acontece quando um documento Word é convertido para PDF sem o cuidado de incorporar todas as fontes usadas. Fontes do sistema operacional, fontes customizadas da empresa, fontes usadas em gráficos e tabelas — todas precisam estar dentro do arquivo.
Senhas e restrições de segurança são outro problema frequente. Alguns fluxos de aprovação interna adicionam senha de leitura ou restrições de impressão nos PDFs. Qualquer restrição de segurança causa rejeição automática.
Links absolutos dentro do PDF — apontando para URLs externas ou para caminhos de rede — são igualmente problemáticos. Todos os hyperlinks dentro de um pacote eCTD precisam ser relativos, apontando para outros arquivos dentro do mesmo pacote.
Como garantir conformidade
A validação de PDF/A deve ser parte do fluxo de trabalho padrão, não uma verificação de último minuto. Ferramentas como Adobe Acrobat Pro, VeraPDF (gratuito e open source) e os próprios validadores dos softwares de eCTD permitem verificar conformidade antes da submissão.
Para equipes que produzem documentos em Word, o processo de conversão precisa ser padronizado. Não basta ‘salvar como PDF’. É preciso usar a função específica de exportação para PDF/A, verificar as configurações de incorporação de fontes, e validar o resultado.
Um erro de PDF/A descoberto pela agência atrasa o processo. O mesmo erro descoberto internamente custa apenas o tempo de correção.
