Перейти к содержимому
РуководствоДата-менеджер

Провести поправку протокола

Поправка (amendment) — изменение протокола, которое живёт как новая опубликованная версия дизайна. Уже включённые субъекты не переезжают на неё автоматически: их переводят явной операцией миграции по плану — всегда сначала дифф и пробный прогон, потом выполнение.

Дата-менеджер — право «переводить субъектов на новую версию дизайна» (subject.migrate_version). Новую версию дизайна создают и публикуют держатели прав на версию (studyversion.*), ревью и утверждение — другим человеком.

Задача возникает, когда протокол изменился после начала набора: добавились поля или визиты, ужесточились проверки, изменились списки вариантов.

  • Новая версия дизайна создана, прошла ревью и Опубликована — см. Опубликовать версию. Для поправки нужны две версии: та, на которой сейчас субъекты, и новая опубликованная.
  • Центры, которые должны заводить новых субъектов на новой версии, переведены на неё — см. Добавить центры.
  • Откройте Настройка → вкладка Поправки (/studies/{studyId}/amendments). Если опубликованная версия одна, экран подскажет: «Для поправки нужна вторая версия дизайна».
0:000:00
Миграция субъектов на новую версию: дифф изменений, пробный прогон и выполнение под аудитом
  1. Создайте план. Нажмите Новый план, выберите Исходную версию (откуда) и Целевую версию (куда) и Охват плана — Всё исследование или Один центр (поэтапный раскат). Нажмите Создать план. План считает дифф по совпадению OID и фиксирует маппинг — само по себе это ничего не меняет в данных.

  2. Изучите дифф (шаг «1. Дифф версий»). Изменения разложены по классам — от косметических до ломающих; ломающие раскрыты по умолчанию. Если план показывает Блокеры, разрешите их: задайте явное сопоставление значений или выберите другую целевую версию (новым планом).

  3. Запустите пробный прогон (шаг «2. Пробный прогон (без изменений)») кнопкой Пробный прогон. Оцените impact-отчёт, панель Последствия миграции и разбивку По субъектам. Данные при этом не меняются.

  4. Выполните миграцию (шаг «3. Выполнение»): нажмите Выполнить миграцию. Диалог «Выполнить миграцию vX → vY?» ещё раз повторяет итоговые цифры; отметьте «Понимаю последствия: подписи снимутся, SDV сбросится, запросы откроются и закроются автоматически» и нажмите Мигрировать.

  5. Проверьте результат. Таблица Результаты по субъектам показывает по каждому субъекту «Мигрирован», «Ошибка» или «Пропущен»; блок Кто на какой версии — сколько субъектов на каждой версии дизайна. Пока план выполняется, нажимайте Обновить, чтобы увидеть прогресс.

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

  • Субъекты переходят на целевую версию; автоэффекты применяются по классам изменений: подписи инвалидируются (Инвалидирована), SDV сбрасывается в Ожидает, запросы автоматически открываются и закрываются, формы могут вернуться в работу.
  • Значения без места в новой версии уходят в архив («осиротеют») — ничего не удаляется.
  • Каждое автодействие фиксируется в аудиторском следе с системной причиной «migration vX→vY» — отдельное поле причины не требуется.
  • План проходит статусы Черновик → Прогон выполнен → Выполняется → Завершён (или С ошибками ).
  • «Для поправки нужна вторая версия дизайна» — новая версия ещё не опубликована. Создайте и опубликуйте черновик на экране Дизайн (Перейти в Дизайн).
  • «Исходная и целевая версии должны различаться» — выберите разные версии.
  • «Сначала пробный прогон: цену поправки нужно увидеть до выполнения» — кнопка выполнения недоступна до успешного пробного прогона.
  • «План содержит блокеры — миграция недоступна» — ломающее изменение при живых данных без явного маппинга, удалённый код, который используется данными, неопубликованная целевая версия и т. п. Разрешите блокеры или создайте план на другую целевую версию.
  • Вкладки «Поправки» нет, подсказка «Нет права переводить субъектов на новую версию дизайна» — нет subject.migrate_version. Обратитесь к администратору.
  • Итоги не совпадают с разбивкой по субъектам — итоги взяты из последнего прогона; запустите пробный прогон заново.

Сама новая версия создаётся и публикуется как черновик на экране Дизайн — с ревью и утверждением другим человеком (разделение обязанностей). Раздел Поправки подключается, когда есть две версии: та, на которой сейчас субъекты, и новая опубликованная, куда их нужно перевести.

Миграция описывается планом: исходная версия → целевая.

  • Исходная — версия, на которой субъекты сейчас (опубликованная или уже заменённая).
  • Целевая — новая опубликованная версия, на которой работают центры.

План может охватывать всё исследование или один центр — для поэтапного раската поправки по центрам.

  1. Черновикпробный прогон
  2. Прогон выполненвыполнить
  3. Выполняется
    • часть субъектов не мигрировалаС ошибками
    все субъекты перенесены
  4. Завершён
Статусы плана миграции: выполнение заканчивается либо полным переносом, либо статусом «С ошибками»; повторный запуск дообрабатывает только оставшихся субъектов.

План классифицирует каждое изменение по цене для существующих данных:

Класс Что это значит для собранных данных
Косметические Безопасно: лейблы, порядок, отображение. Данные и подписи не затронуты.
Аддитивные Новые поля, формы, визиты. Новые поля приходят пустыми; существующие данные не меняются.
Ограничивающие Ужесточения (обязательность, диапазоны, SDV): возможны конфликты значений; подписи станут недействительны и потребуют повторного подписания.
Ломающие Поля исчезают или меняют тип — данные осиротеют (уйдут в архив, ничего не удаляется). Требуются явные маппинги или подтверждение.

Внутри каждого класса видны конкретные изменения по OID (например, «поле стало обязательным», «изменён тип данных», «визит добавлен»).

Блокеры. Если ломающие изменения не сопровождены явными маппингами или подтверждением, план показывает блокеры. Пока они не разрешены, выполнение недоступно: без явных маппингов или подтверждения платформа данные не переписывает. Удалённый код, который используется данными, требует явного сопоставления «старый → новый» — молча переназначать нельзя.

Пробный прогон считает impact-отчёт по реальным данным — без единого изменения и показывает, во что обойдётся поправка.

Показатель Смысл
Субъектов в границах плана сколько субъектов затронет миграция
Переносится значения переезжают как есть
Трансформируется значения преобразуются по маппингу
Осиротеет (архив) значения без места в новой версии уходят в архив (не удаляются)
Новых обязательных пустых новые обязательные поля, которые придут пустыми
Форм вернётся в работу формы, которые перестанут считаться заполненными

Панель Последствия миграции прямо называет побочные эффекты:

  • Подписи будут инвалидированы — сколько подписей слетит и потребует переподписания;
  • SDV сбросится — сколько верификаций вернётся в статус «ожидает» (и сколько флагов медицинского обзора);
  • Запросы — сколько запросов закроется и сколько откроется автоматически.

Разбивка По субъектам показывает, у кого именно возникнут «сироты» и потери подписей.

Операция идемпотентна и резюмируема: если часть субъектов не мигрировала, повторный запуск дообработает только оставшихся — уже мигрированные не трогаются.

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