eCTD 4.0 становится обязательным в 2026 году.
Как ИТ-отделам фармкомпаний подготовить инфраструктуру
Двадцать лет фармацевтическая отрасль работала с одним и тем же форматом электронных подач. За это время появились смартфоны, облачные технологии, искусственный интеллект, а регистрационные досье по-прежнему упаковывались в XML-структуры образца 2003 года. В январе 2026 года этот период подходит к концу.
Япония стала первой страной, которая сделала eCTD 4.0 обязательным форматом для новых регистрационных подач. FDA принимает досье в новом формате с сентября 2024 года, а EMA планирует обязательный переход для централизованных процедур к 2027 году.
Для ИТ-директоров фармкомпаний это означает одно: пора менять инфраструктуру.
Как было. Версия 3.2.2 и её ограничения
Стандарт eCTD 3.2.2 появился в 2008 году и с тех пор практически не менялся. Он построен просто: регистрационное досье выглядит как набор папок с PDF-файлами, связанных XML-индексом.
Каждый документ занимает строго определённое место в иерархии CTD (Common Technical Document), а любое изменение требует пересборки всей структуры.
На практике это создавало серьёзные проблемы. Если компания хотела заменить один файл в досье, приходилось формировать новую «сиквенцию» (последовательность подач) и переписывать весь XML-индекс. При внесении изменений в несколько заявок одновременно, например при обновлении информации о производственной площадке, один и тот же документ загружался многократно.
Система работала как «односторонняя связь». Компания отправляла досье, а затем ждала ответа от регулятора по отдельным каналам связи, без какой-либо интеграции и единого окна для отслеживания статуса.
Таблица 1. Проблемы eCTD 3.2.2 и их последствия для бизнеса
| Проблема версии 3.2.2 | Последствия для бизнеса |
|---|---|
| Жёсткая структура папок | Любое изменение требует пересборки |
| Дублирование документов | Увеличение объёма подач и времени обработки |
| Односторонняя коммуникация | Невозможность отслеживать статус в реальном времени |
| Устаревший XML-формат | Сложности с интеграцией современных систем |
Что изменилось. Архитектура eCTD 4.0
Версия 4.0 построена на совершенно иных принципах.
В её основе лежит стандарт HL7 RPS (Regulated Product Submission), который разрабатывался специально для обмена регуляторной информацией между государственными органами и фармацевтической индустрией.
Главное техническое отличие заключается в работе с документами. В новой версии каждому файлу присваивается UUID (Universal Unique Identifier) при первой загрузке.
Этот идентификатор позволяет ссылаться на документ в любых последующих подачах без повторной загрузки. Если компания зарегистрировала препарат в одной стране и хочет подать заявку в другой, она может просто указать UUID уже загруженных документов вместо того, чтобы отправлять их заново.
Контролируемые словари (Controlled Vocabularies) стали обязательным элементом системы. Раньше компании могли использовать произвольные формулировки для описания документов. Теперь существуют стандартизированные справочники терминов, которые управляются на разных уровнях: ICH определяет глобальные термины, региональные регуляторы добавляют свои, а компании могут использовать собственные ключевые слова для внутренней классификации.
Ещё одно существенное изменение касается управления жизненным циклом документов. В версии 3.2.2 существовали три базовые операции: добавить новый документ, заменить существующий, удалить. Версия 4.0 расширяет этот набор. Теперь можно заменить один документ несколькими (split), объединить несколько документов в один (merge), обновить метаданные без изменения самого файла.
Таблица 2. Сравнение возможностей eCTD 3.2.2 и eCTD 4.0
| Возможность | eCTD 3.2.2 | eCTD 4.0 |
|---|---|---|
| Повторное использование документов | Нет | Да, через UUID |
| Обновление метаданных | Требует перезагрузки файла | Без перезагрузки файла |
| Объединение/разделение документов | Нет | Да |
| Двусторонняя связь | Нет | Предусмотрена в архитектуре |
| Контролируемые словари | Ограниченные | Полная поддержка |
Сроки внедрения в разных странах
Разные страны движутся к обязательному внедрению с разной скоростью.
Япония (PMDA) стала лидером этого процесса. Агентство начало пилотные подачи ещё в 2021 году, а с 2022 года принимает досье в формате 4.0 на добровольной основе. В 2026 году новый формат становится обязательным для всех новых заявок.
США (FDA) начали принимать eCTD 4.0 с 16 сентября 2024 года, пока на добровольной основе. Обязательное внедрение планируется на 2029 год, хотя сначала речь шла о более ранних сроках. Пока функция forward compatibility (совместимость со старыми подачами) не реализована, так что переводить существующие заявки в новый формат нельзя.
Европа (EMA) проводит пилотные проекты с 2024 года. Обязательное использование для централизованных процедур ожидается в 2027 году. Для других типов процедур (MRP/DCP/национальные) сроки пока не определены окончательно.
Канада (Health Canada) планирует начать обязательный приём в 2027–2028 годах, хотя добровольные подачи уже возможны.
Специфика ЕАЭС
А как обстоят дела на евразийском рынке?
Компании, работающие в России, Казахстане или Беларуси, сталкиваются с дополнительным вызовом. Формат электронного досье ЕАЭС (определяемый Решением Коллегии ЕЭК №79) технически отличается от международных стандартов ICH.
Схема R.017 для структурированного заявления
Этот XML-файл заменяет бумажную форму заявления и содержит:
- сведения о заявителе и держателе регистрационного удостоверения;
- полный состав препарата со ссылками на справочники ЕАЭС;
- данные о производстве на всех стадиях;
- информацию об упаковке и маркировке.
Проблема в том, что эти данные обычно разбросаны по разным системам: часть хранится в ERP (Enterprise Resource Planning, система управления ресурсами предприятия), часть в таблицах регуляторного отдела, часть в текстах PDF-документов. Автоматизация сбора через интеграционную шину становится одной из приоритетных задач.
Схема R.022 для описи досье
Это аналог index.xml в eCTD, но с существенными отличиями. Каждому документу присваивается GUID (Globally Unique Identifier). Каждый файл должен быть классифицирован по справочнику видов документов ЕЭК. Обязательно вычисление контрольной суммы (MD5 или SHA-256) и указание размера файла в байтах. Ошибка в выборе кода классификации приводит к отказу в валидации.
Требования к документам
Решение Совета ЕЭК №78 устанавливает строгие технические требования:
- все сканированные документы должны проходить OCR (распознавание текста);
- рекомендуется формат PDF/A для долгосрочного хранения;
- ограничение на один файл составляет 100 МБ;
- обязательны закладки и гиперссылки внутри документов.
Для больших отчётов о клинических исследованиях ограничение в 100 МБ создаёт дополнительную работу: документы приходится разбивать на части, корректно именовать и связывать в XML-описи.
Проблема электронной подписи
Отдельная головная боль связана с трансграничным признанием ЭЦП. Удостоверяющие центры России используют криптографические алгоритмы ГОСТ, Казахстан применяет свои национальные стандарты. Файл, подписанный российской ЭЦП, может не пройти валидацию на портале Минздрава Казахстана без специальной настройки.
ЕЭК работает над созданием сервисов «Доверенной третьей стороны» для взаимного признания подписей. До полноценного запуска этих механизмов ИТ-отделам приходится обеспечивать наличие локальных ЭЦП для каждого целевого рынка и настраивать рабочие места для работы с разными криптопровайдерами.
Подготовка ИТ-инфраструктуры
Переход на eCTD 4.0 затрагивает три уровня: программное обеспечение для публикации досье, системы управления данными и каналы связи с регуляторами.
Уровень 1. Обновление системы публикации
Первый и самый очевидный шаг заключается в проверке готовности текущего программного обеспечения. Крупные вендоры уже выпустили или готовят модули для работы с версией 4.0:
Veeva Vault RIM (Regulatory Information Management, система управления регуляторной информацией) активно внедряет поддержку eCTD 4.0 и ЕАЭС. Для евразийского рынка реализована поддержка схем R.022. Для подготовки к версии 4.0 рекомендуется включить функционал объектного управления документами.
EXTEDO eCTDmanager традиционно силён в Европе и регионе ЕАЭС. Поддерживает модуль ЕАЭС с возможностью валидации и публикации, для версии 4.0 предлагает инструменты конвертации и управления UUID.
LORENZ docuBridge также реализовал поддержку схем ЕАЭС (R.022) и eCTD 4.0, предлагает облачные решения для тестирования публикаций.
Нужно связаться с поставщиком и уточнить:
- поддерживает ли текущая версия ПО формат eCTD 4.0;
- требуется ли обновление или покупка нового модуля;
- есть ли функциональность для Transition Mapping Message (перевод существующих досье из 3.2.2 в 4.0);
- поддерживаются ли контролируемые словари для нужных регионов.
Если компания использует собственные решения или небольших вендоров, ситуация сложнее. Придётся либо переходить на коммерческое ПО, либо инвестировать в доработку текущих систем в соответствии со спецификациями ICH.
Уровень 2. Управление мастер-данными
Версия 4.0 требует строгого соответствия контролируемым словарям. Это означает, что названия производственных площадок, лекарственных форм, путей введения и других параметров должны точно совпадать с официальными справочниками.
На практике многие компании сталкиваются с тем, что в разных внутренних системах одни и те же объекты называются по-разному. В корпоративной ERP завод может фигурировать как «Производственная площадка №1», в системе документооборота как «Plant 1», а в регистрационных документах как «Manufacturing Site 1». При валидации eCTD 4.0 такие расхождения приведут к ошибкам.
Решение состоит в создании единого источника правды (Master Data Management). Все системы должны использовать согласованные наименования, соответствующие официальным контролируемым словарям ICH и региональных регуляторов. Это масштабный проект, затрагивающий как ИТ-подразделение, так и регуляторный отдел.
Уровень 3. Каналы связи с регуляторами
Архитектура eCTD 4.0 предусматривает двустороннюю связь между компанией и регулятором. Теоретически это означает, что запросы на дополнительную информацию (RFI) и уведомления о статусе смогут приходить в виде структурированных сообщений непосредственно в систему компании.
На практике полноценная двусторонняя коммуникация пока не реализована ни одним регулятором. FDA планирует внедрение в будущих версиях, EMA тестирует подходы. Тем не менее, инфраструктура должна быть готова.
Для работы с двусторонними сообщениями необходим собственный шлюз (gateway) на стороне компании. Это отличается от текущей модели, где компании могут использовать веб-порталы регуляторов для подачи. Крупные организации могут построить собственную инфраструктуру, небольшие компании, вероятно, будут пользоваться облачными сервисами вендоров, которые выступят посредниками.
Протоколы передачи AS2 и AS4
С изменением форматов меняется и транспортный уровень. AS2 (Applicability Statement 2) остаётся текущим стандартом для FDA ESG и EMA Gateway, обеспечивая шифрование и цифровую подпись. AS4 (на базе Web Services) продвигается Еврокомиссией как более современный протокол с поддержкой различных сценариев взаимодействия. Национальные порталы ЕС могут начать требовать его использование.
В ЕАЭС прямая передача «машина-машина» пока развита слабо. Основной канал остаётся ручным: загрузка XML и PDF через веб-порталы («личные кабинеты») или использование REST API, специфичных для каждой страны. Для автоматизации этого процесса требуется разработка или покупка коннекторов.
Роль мастер-данных в новой архитектуре
Переход на eCTD 4.0 делает управление мастер-данными (Master Data Management) не вспомогательной, а центральной функцией бизнеса.
Стандарты ISO IDMP
Стандарты ISO IDMP (Identification of Medicinal Products) описывают, как должны быть структурированы данные о лекарствах для обеспечения глобальной совместимости. Они включают пять стандартов: информация о регулируемом продукте (ISO 11615), фармацевтическом продукте (ISO 11616), веществах (ISO 11238), лекарственных формах и путях введения (ISO 11239), единицах измерения (ISO 11240).
SPOR в Европейском Союзе
EMA реализует стандарты IDMP через проект SPOR (Substance, Product, Organisation, Referential). Базы данных SMS (вещества) и OMS (организации) уже функционируют. Компании обязаны зарегистрировать свои данные в системах EMA и получить уникальные идентификаторы.
При формировании eCTD 4.0 многие поля, которые раньше заполнялись свободным текстом (например, «Таблетки, покрытые плёночной оболочкой»), теперь должны содержать код из классификатора SPOR RMS. Если RIM-система не синхронизирована со SPOR, она сгенерирует невалидное досье.
Двойное кодирование для глобальных компаний
ЕАЭС также движется по пути IDMP, создавая Единый реестр лекарственных средств. ЕЭК утвердила справочники, гармонизированные с номенклатурой ICH, но имеющие свои особенности кодирования.
Глобальные компании сталкиваются с необходимостью поддерживать «двойную бухгалтерию». В ERP-системе продукт имеет один код. Для подачи в ЕС он должен быть сопоставлен с кодами SPOR. Для подачи в ЕАЭС требуются коды классификаторов ЕЭК. Решение состоит во внедрении MDM-системы, которая поддерживает управление таблицами соответствия между локальными кодами и кодами различных регуляторных систем.
Переход существующих досье. Baseline или Migration
При внедрении eCTD 4.0 компания должна решить, что делать с уже зарегистрированными препаратами.
Существуют два подхода.
Миграция (Migration) означает перевод всей истории подач в новый формат с сохранением связей между документами. Это технически сложный процесс, который требует формирования Transition Mapping Message. Регуляторы предоставляют спецификации для такого перехода, но реализация трудоёмка.
Базовая линия (Baseline) означает создание «чистого» досье в формате 4.0 при первом существенном изменении. Вся предыдущая история остаётся в версии 3.2.2, а новое досье начинается с нуля. Этот подход проще технически, но означает потерю возможности ссылаться на ранее поданные документы.
Большинство экспертов рекомендуют использовать Baseline при первом крупном изменении (variation) после начала обязательного приёма версии 4.0 в соответствующем регионе. Полная миграция оправдана только для продуктов с активным жизненным циклом и частыми изменениями.
Кибербезопасность и облачная инфраструктура
Хранение регистрационных досье на локальных серверах постепенно уходит в прошлое. Системы класса RIM переместились в облака, и это создаёт новые требования к безопасности.
Фармацевтический сектор становится мишенью для кибератак всё чаще. Регистрационные досье содержат конфиденциальную информацию о составе препаратов, производственных процессах, результатах клинических исследований. Утечка таких данных может привести к серьёзным последствиям.
При выборе облачного решения стоит обращать внимание на несколько аспектов: соответствие стандартам GxP (в частности, Annex 11 для компьютеризированных систем), шифрование данных при передаче и хранении, географическое расположение серверов (особенно актуально для компаний, работающих с данными из разных юрисдикций), наличие процедур аудита и отслеживания изменений.
Риски гибридного периода 2026–2029
В ближайшие годы придётся поддерживать несколько форматов одновременно: eCTD 3.2.2 для существующих досье в США и ЕС, eCTD 4.0 для новых подач, формат ЕАЭС для евразийского рынка. Это создаёт несколько рисков.
Десинхронизация контента. Изменения в документ вносятся в одной системе, но забываются в другой. Один и тот же сертификат качества обновляется для досье 4.0, а в версии 3.2.2 остаётся старый вариант.
Безопасность структурированных данных. Переход к XML делает данные легко читаемыми для машин. Утечка файла R.017 (ЕАЭС) раскрывает конкурентам всю структуру поставщиков и состав препарата гораздо быстрее, чем утечка PDF. Требуется усиление систем предотвращения утечек (DLP).
Зависимость от вендора. Сложность eCTD 4.0 делает практически невозможной разработку собственных инструментов. Компании становятся заложниками дорожных карт крупных поставщиков. При выборе вендора стоит оценивать текущую функциональность и долгосрочную стратегию развития продукта.
Что делать сейчас?
1. Проведите аудит текущей инфраструктуры. Составьте список всех систем, участвующих в формировании и хранении регистрационных досье. Определите, какие из них требуют обновления для работы с eCTD 4.0 и форматами ЕАЭС.
2. Свяжитесь с вендором ПО для публикации. Уточните сроки и условия перехода на поддержку версии 4.0 и схем R.022. Если текущий поставщик не планирует обновления, начинайте искать альтернативу.
3. Запустите проект по управлению мастер-данными. Проведите инвентаризацию терминологии, используемой в разных системах. Сопоставьте её с контролируемыми словарями ICH, SPOR и классификаторами ЕЭК. Создайте таблицы соответствия.
4. Определите стратегию перехода для каждого продукта. Для препаратов с активным жизненным циклом запланируйте Baseline при первом существенном изменении. Для продуктов на рынке ЕАЭС проверьте статус процедуры приведения в соответствие.
5. Подготовьте инфраструктуру для ЕАЭС. Внедрите решения для массового OCR и конвертации в PDF/A. Настройте рабочие места для работы с ЭЦП разных стран. Увеличьте квоты хранилищ с учётом пиковых нагрузок.
6. Обучите команду. Новый формат требует понимания новой терминологии (UUID, Context of Use, Controlled Vocabularies) и новых процессов. Организуйте обучение для регуляторных специалистов и ИТ-персонала.
Переход на eCTD 4.0 можно воспринимать по-разному. Для кого-то это обременительная необходимость, требующая инвестиций в инфраструктуру и обучение персонала. Для других это возможность перестроить устаревшие процессы и повысить эффективность работы с регуляторными данными.
В любом случае, подготовка должна начаться сейчас. Японский рынок уже требует нового формата, американский и европейский последуют в ближайшие годы. Компании, которые инвестируют в инфраструктуру заранее, смогут использовать преимущества нового стандарта раньше конкурентов.
Нормативная база:
1. Стандарты ISO IDMP: ISO 11615, ISO 11616, ISO 11238, ISO 11239, ISO 11240
2. ICH eCTD v4.0 Implementation Package (Step 4, 2015, обновления до 2025)
3. FDA eCTD v4.0 Implementation Guide
4. EMA EU eCTD v4.0 Implementation Guide v1.2
5. PMDA eCTD v4.0 Technical Implementation Guide
6. HL7 Version 3 Standard: Regulated Product Submissions (RPS), Release 2
7. Решение Совета ЕЭК от 03.11.2016 №78 «О Правилах регистрации и экспертизы лекарственных средств для медицинского применения» (ред. от 22.05.2025)
8. Решение Коллегии ЕЭК от 30.06.2017 №79 «О Требованиях к электронному виду заявлений и документов регистрационного досье» (ред. от 19.04.2022)