Життєвий цикл реєстраційного досьє
та eCTD-подання до ДЕЦ
Корпоративне рішення для фармацевтичних виробників і заявників: веде лікарський засіб від першого досьє через усі процедури та послідовності — структура CTD, документи, історія розділів, валідація за критеріями ДЕЦ, збірка пакета, незмінний архів поданого.
- 1–5Модулі CTD за наказом МОЗ № 1789
- 76Критеріїв ДЕЦ до зібраного пакета
- 3Незалежні рівні контролю
Основні функції
- Реєстр досьє: відповідальний, поточна процедура, строки дії реєстрації
- Процедура ДЕЦ як сутність: групує послідовності, має стан і наказ МОЗ, що її закриває
- Дерево CTD Модулів 1–5 з розмноженням гілок за складом і показаннями препарату
- Життєвий цикл розділів між послідовностями:
new/replace/deleteз історією
- Документи: завантаження PDF/ODT, конвертація з вшиванням шрифтів, версії, контроль MD5
- Валідація трьома рівнями: документ → зібраний пакет → незалежна крос-перевірка
- Збірка backbone-XML і ZIP-пакета, перелік файлів для супровідного листа, фіксація поданого
- КЕП, антивірусна перевірка, листування з ДЕЦ, кабінет заявника, журнали аудиту
Ключові особливості
Рішення, які відрізняють систему
Дев'ять принципів, закладених в основу: подання має бути прийняте з першого разу, а історія досьє — лишатися доказовою через усі процедури.
Перевірка правилами регулятора
У систему вбудовано дослівний порт офіційного скрипта перевірки ДЕЦ. Це не «натхненна оригіналом» реалізація: логіка відтворена рядок у рядок і запечатана хеш-контролем, тож відповідь, яку дасть регулятор, відома заявнику до подання.
порт перевірки ДЕЦ рядок у рядок · хеш-контроль
Життєвий цикл, а не лише збірка пакета
Система знає не тільки «які документи є зараз», а історію кожного розділу через усі послідовності: що подано, що замінено, що вилучено. Процедура ДЕЦ — окрема сутність, яка групує подання й зберігає наказ, що її закриває.
процедура → послідовність → розділ → документ
Три незалежні рівні контролю
Документ перевіряється при завантаженні (шрифти, текстовий шар, закладки, захист PDF), зібрана послідовність — за критеріями ДЕЦ, готовий пакет — незалежною крос-перевіркою: після експорту досьє перевіряє окремий незмінний скрипт, побудований на іншій технології, тож помилка однієї реалізації не пройде непоміченою. Попередження дорівнює відмові.
документ → пакет → незалежна крос-перевірка
Система виправляє, а не лише дорікає
Імена файлів приводяться до правила ДЕЦ автоматично, ODT конвертується у відповідний PDF із вшитими шрифтами й закладками, посилання на документ попередньої послідовності підставляються самі. Автор працює у звичному редакторі.
ODT → PDF · імена файлів · авто-посилання
Подане стає незмінним
Фіксація подання — юридично значуща межа: послідовність блокується для редагування, у журнал пишеться базова лінія контрольних сум усіх файлів пакета, атрибути, що вже пішли в подання, заморожуються. Виправити заднім числом не може й адміністратор.
lock → MD5 baseline → append-only
Дані не покидають периметр
Капсульна модель: один екземпляр системи — одна віртуальна машина замовника, одна країна подання. Документи й база — всередині; зовнішні звернення ідуть через корпоративний проксі й білий список вузлів. Особистий ключ КЕП на сервер не потрапляє.
одна країна = одна капсула
Вимоги змінює адміністратор
Профілі типів подання, правила КЕП, правила життєвого циклу, матриця вимог за правовою підставою заявки, реєстр керованих документів — усе це налаштування, а не код. Коли ДЕЦ змінює вимоги, реакція вимірюється годинами, а не кварталом очікування релізу.
профілі · правила · матриця підстав
Вхід без «почати з нуля»
Досьє, подані раніше будь-яким способом, імпортуються з ZIP-архівів eCTD разом з усією історією послідовностей. Правильність імпорту перевірено циклом «імпорт → збірка → порівняння» на еталонних поданнях, уже прийнятих ДЕЦ.
ZIP eCTD → досьє з історією процедур
Оновлення не змінюють поданого
Регресійною сіткою слугують еталонні знімки: backbone-XML і дерева всіх послідовностей, вердикти валідатора на реальних файлах, вердикти крос-валідатора на зібраних і еталонних пакетах. Будь-яка зміна коду звіряється з ними байт у байт.
golden backbone · звірка байт у байт
Конкурентні переваги
Порівняння з типовими способами готувати подання
Критерії, що визначають, чи буде подання прийняте з першого разу й чи втримає досьє свою історію через усі процедури.
| Критерій | Ця система | Ручна підготовка + скрипт ДЕЦ | Універсальний публішер | Файлова куля + Excel |
|---|---|---|---|---|
| Знання вимог ДЕЦ і наказу МОЗ № 1789 | У структурі й перевірках | У голові фахівця | Загальні правила ICH | Немає |
| Коли виявляється помилка | При завантаженні документа | Після збірки | На публікації | Після відмови ДЕЦ |
| Життєвий цикл розділів між поданнями | За практикою ДЕЦ | Вручну, в Excel | За практикою ICH | Немає |
| Процедура як сутність, що групує подання | Зі станом і наказом МОЗ | Тека й листування | Частково | Немає |
| Реакція на зміну вимог регулятора | Налаштування адміністратором | Переробка інструкцій | Запит до постачальника | Нічого не змінюється |
| Антивірусна перевірка пакета (вимога ДЕЦ) | При завантаженні й фіксації | Вручну, без звіту | Не передбачено | Немає |
| Доказовість для аудиту | Незмінні журнали | Журнали відсутні | Залежить від рішення | Немає |
| Розташування даних | Капсула замовника | Периметр підприємства | Хмара постачальника | Периметр підприємства |
| Перехід з наявних досьє | Імпорт ZIP з історією | Не застосовується | Платна послуга | Не застосовується |
| Вартість володіння | Без ліцензійних платежів | «Безкоштовно» + ризик відмови | Ліцензії за користувача | Нульова |
Колонка «універсальний публішер» описує типову картину таких рішень і не є порівнянням із конкретним продуктом за результатами випробувань.
← Усі рішення · Запитання й пропозиції — office [at] rdsoft.com.ua