Документы DM: DVP и DMP

Как портал пишет план проверки данных и план управления данными, версии, подписи, TMF.

План проверки данных (DVP, data validation plan) перечисляет все сверки (edit checks) и ручные проверки данных исследования: что проверяется, какое сообщение видит центр и как это протестировать. Обычно его пишут вручную в Word и Excel, и он быстро расходится с базой. В YouEDC портал сам пишет DVP из конструктора eCRF, поэтому план всегда описывает то, что действительно работает. Раздел «Документы DM» есть в меню исследования YouEDC Capture.

Путь DVP: черновик собирается из конструктора, выпускается на подпись, автор подписывает, другой человек утверждает, PDF уходит в TMF. Если исследование изменилось, портал предупреждает и предлагает новую версию.

Что портал пишет сам

• Обязательные поля (код ФОРМА_ПОЛЕ_REQ): форму нельзя завершить, пока поле пусто и не отмечено «нет данных».
• Допустимый диапазон (_RNG): жёсткая сверка, значение не сохраняется. Ожидаемый диапазон (_EXP): значение сохраняется, открывается запрос.
• Правила «если — то» из конструктора: у каждого постоянный код вида VS_R001. Код удалённого правила больше никогда не выдаётся, поэтому ссылки в старых версиях DVP и в отчётах не путаются. Код виден в списке правил формы.
• Условия показа (_SHOW): поле скрыто и очищено, пока условие ложно.
• Для каждой сверки портал предлагает тест для UAT: значение, на котором сверка срабатывает, и значение, которое проходит. Например, «301 → отклонено; 300 → сохранено». Тесты выгружаются в Excel отдельными столбцами, их можно сразу отдать тестировщику.
• Сводку по формам, критичные данные и раздел изменений по сравнению с прошлой утверждённой версией: что добавлено, изменено и удалено.

В документе цветом отмечено, откуда текст: зелёный — из данных портала, жёлтый — типовой текст, красный — пишет команда. Команда дописывает цель (если типовая не подходит), примечания и ручные проверки: перекрёстные проверки форм, листинги, медицинский обзор. Они получают коды MAN_001, MAN_002…

Живой черновик исследования TST-01. Слева документ в том виде, в каком он попадёт в PDF, справа выпуск на подпись, версии и поля для текстов команды.

Версии и подписи

1. Администратор проекта или дата-менеджер нажимает «Выпустить версию 0.1». Черновик фиксируется вместе с контрольной суммой структуры eCRF.
2. Автор подписывает первым: вводит свой пароль ещё раз. Портал записывает имя, роль, дату и время, смысл подписи и хеш версии.
3. Другой человек (не автор) проверяет или утверждает. При утверждении версия получает номер 1.0, файлы PDF/A, Word и Excel сохраняются ровно в подписанном виде, а PDF попадает во «Входящие» мастер-файла исследования (TMF, зона «Управление данными»).
4. Спонсор может подписать с ролью «Спонсор / наблюдатель».

Если после выпуска исследование изменилось (например, поменяли диапазон давления), утвердить эту версию уже нельзя: портал покажет, что изменилось, и предложит выпустить новую. Следующие версии нумеруются 1.1, 1.2…, после утверждения — 2.0. Подписи нельзя изменить или удалить даже напрямую в базе, их можно только отозвать с причиной. Каждое действие записывается в аудиторский след.

Файлы

• PDF/A — для архива и TMF: шрифты встроены, внутри исходные данные.
• Word — если спонсор хочет свой шаблон: можно перенести текст.
• Excel — для тестирования: лист сверок (edit checks) с тестами, ручные проверки, сводка, изменения.

План управления данными (DMP)

DMP описывает, как данные исследования собираются, проверяются, кодируются, сверяются, блокируются и архивируются. Откройте План управления данными в меню исследования (или карточку в разделе Документы DM) и нажмите «Начать DMP», выбрав язык документа: русский или английский. Большую часть плана портал заполняет сам из того, что уже знает об исследовании:

• профиль и дизайн исследования, роли команды с числом людей, центры;
• версии eCRF с историей выпусков, число визитов, форм, полей и сверок, ссылку на DVP;
• работу с запросами: кто открывает, отвечает и закрывает запросы, сроки из настроек сроков ввода данных;
• план SDV, одобрение форм дата-менеджером и электронную подпись исследователя;
• медицинское кодирование: только словари и их версии, без содержимого словарей;
• сверки серьёзных нежелательных явлений, лабораторных данных и данных подрядчиков; ePRO и согласие; рандомизацию и ослепление (без списка, его зерна и параметров); импорт и ключи API (без самих ключей);
• обзор данных и аудиторского следа, закрытие базы с чек-листом готовности, архив и защиту данных.

То, чего портал знать не может (соглашения с подрядчиками, план обзора, порядок закрытия базы, сроки хранения, СОП), команда пишет прямо на экране, там, где этот текст стоит в документе. Такой текст помечен как написанный командой и сохраняется в каждой версии.

Живой черновик демо-исследования: слева документ в том виде, в каком он попадёт в Word; справа выпуск новой версии с причиной, ниже выпущенные версии с версией eCRF, которую описывает каждая.

1. Администратор проекта или дата-менеджер нажимает «Выпустить версию» и пишет причину, например «Поправка 1 к eCRF». План фиксируется вместе с SHA-256 и номером версии eCRF, которую он описывает; файл Word сохраняется ровно в выпущенном виде. Версии нумеруются 1.0, 2.0…, предыдущая становится «заменённой».
2. В документе есть история версий с причинами и что изменилось по сравнению с предыдущей версией.
3. Когда у eCRF появляется новая версия, пункт меню и экран показывают «eCRF изменилась после версии DMP 1.0»: пора выпустить новую.
4. В файле Word есть таблица подписей для подписания на бумаге. Пока план не подписан, на каждой странице написано, что он сформирован порталом и является черновиком.

Мониторы могут читать выпущенные версии и скачивать их файлы; роли центров план не видят. Начало плана, каждая правка текста команды и каждая выпущенная версия записываются в аудиторский след с причиной. Раздел о защите данных на российской установке называет требования Федерального закона № 152-ФЗ; он описывает меры портала и не утверждает соответствие или сертификацию.

Источники

• SCDM, Good Clinical Data Management Practices: разделы о проверке данных и плане управления данными.
• 21 CFR Part 11: требования к электронным подписям (имя, дата, смысл подписи, связь с записью).

Также портал так же пишет руководство исследователя. Электронная подпись в прототипе равна собственноручной только там, где это закреплено соглашением об электронных подписях.