Поправки и миграция субъектов

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

0:000:00

Миграция субъектов на новую версию: дифф изменений, пробный прогон и выполнение под аудитом

Поправка начинается в «Дизайне исследования»

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

План миграции: откуда и куда

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

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

Создание плана только считает дифф и фиксирует маппинг по совпадению OID-идентификаторов — само по себе оно ничего не меняет в данных. Планы проходят статусы: Черновик → Прогон выполнен → Выполняется → Завершён (или С ошибками).

Шаг 1. Дифф изменений

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

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

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

Блокеры останавливают миграцию

Если ломающие изменения не сопровождены явными маппингами или подтверждением, план показывает блокеры. Пока блокеры не разрешены (маппинги при создании плана или новая целевая версия), кнопка выполнения недоступна — платформа не переписывает данные молча никогда.

Шаг 2. Пробный прогон (dry-run)

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

Итоговые счётчики:

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

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

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

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

Шаг 3. Выполнение (execute)

Выполнение переключает субъектов на целевую версию и применяет автоэффекты по классам (инвалидация подписей, сброс SDV, авто-открытие/закрытие запросов) с полным аудитом.

Выполнение необратимо изменяет статусы данных

Выполнение доступно только после успешного пробного прогона и явного подтверждения «Понимаю последствия: инвалидация подписей, сброс SDV, авто-открытие/закрытие queries». Диалог ещё раз повторяет итоговые цифры. Отдельное поле причины не требуется — каждое автодействие фиксируется в аудите с системной причиной «migration vX→vY».

1. Создайте план: выберите исходную и целевую версии. План посчитает дифф.

2. Изучите дифф по классам, разрешите блокеры (если есть).

3. Запустите пробный прогон и оцените impact-отчёт и панель последствий.

4. Нажмите «Выполнить миграцию», подтвердите осознание последствий — субъекты переводятся на новую версию.

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

Перепись «кто на какой версии»

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

Заверши миграцию до закрытия базы

Немигрированные субъекты — препятствие для финальной блокировки базы. Проведите миграцию до ревью перед блокировкой, чтобы чек-лист готовности сошёлся. См. Блокировка базы.

Дальше

Дизайн исследованияГде создаётся и публикуется новая версия дизайна для поправки.

Электронная подписьОграничивающие и ломающие изменения инвалидируют подписи.

Мониторинг и запросыМиграция автоматически открывает и закрывает запросы.

Блокировка базыЗаверши миграцию до закрытия базы.