Настройка — параметры исследования (Settings)

Страница описывает вкладки Settings и то, как изменения влияют на реальные операционные сценарии: создание субъектов, ввод данных, queries, аудит и доступы.

подсказка

Если «пропала» вкладка или кнопка сохранения, в 90% случаев это одно из трёх: нет права → не тот контекст → исследование в read-only статусе.

Где это в UI

• Базовый маршрут: /studies/[studyId]/settings
• Вкладки:
  • general — общие данные исследования
  • protocol — детали протокола (краткий набор полей)
  • data-collection — правила сбора данных (обязательность полей, queries и т.д.)
  • users — команда исследования (приглашения и назначения ролей)

Кто может менять (права)

Права проверяются в контексте исследования (study-scope).

Вкладка	Что меняет	Требуемое право
general	название/спонсор/ОИР, даты, план набора	studies.change_study
protocol	терапевтическая область и описание (как “паспорт” протокола)	studies.change_study
data-collection	правила ввода/обязательности и feature-флаги	studies.manage_study
users	приглашения и назначения ролей/центров	studies.manage_study_users

Отдельно: смена статуса исследования доступна пользователям с studies.manage_study.

Когда Settings становятся read-only (по статусу)

Настройки можно менять только в «рабочих» статусах исследования:

• PENDING (в UI: «Черновик»)
• AVAILABLE (в UI: «Активен»)

В статусах FROZEN, LOCKED, SIGNED и при удалении контур становится read-only: UI покажет предупреждение, и сохранение будет заблокировано.

Вкладка General

General — это “паспорт” исследования. Данные используются в:

• списке исследований,
• отчётах/выгрузках (описательные поля),
• операционных KPI (план/факт и даты).

Что обычно меняют:

• Название, спонсор, ОИР: влияют на подписи в отчетах и видимость для команды.
• Плановые/фактические даты: используются в графиках и контрольных отчётах.
• План набора: используется в сводных виджетах и дашбордах прогресса.

Практика:

• изменяйте значения осознанно: это не меняет данные CRF, но меняет «паспорт» исследования;
• в проде фиксируйте rationale (внешний change-control), если SOP требует.

Вкладка Protocol

Protocol — краткий раздел, ориентированный на “описание протокола” в отчётах.

Важно:

• ID протокола отображается как read-only (это идентификатор исследования).
• На текущем этапе в этой вкладке обычно редактируются:
  • терапевтическая область,
  • описание.

Вкладка Data Collection (ключевая)

Здесь задаются правила, которые немедленно меняют поведение форм и валидаций. Перед изменениями согласуйте их с SOP и предупредите команду.

1) Конфигурация субъектов

Настройка	Значения	Что меняет на практике
Сбор даты рождения (collectDob)	1 полная DOB, 2 год рождения, 3 не используется	какие поля видны/обязательны при создании/редактировании субъекта и что уходит в экспорты
Пол обязателен (genderRequired)	true, false, not used	обязательность пола и его присутствие в формах/выгрузках
Персональный ID субъекта (subjectPersonIdRequired)	required, optional, not used	включение поля Person ID и обязательность (для сопоставления с внешними системами)
Генерация ID субъекта (subjectIdGeneration)	manual, auto editable, auto non-editable	кто задаёт Subject ID: пользователь или система, и можно ли его менять
Префикс/суффикс для ID (subjectIdPrefixSuffix)	on/off	формат авто-ID и правило нумерации (по центру или по исследованию)

Как читать subjectIdGeneration:

• manual: пользователь вводит Subject ID вручную (поле обязательно).
• auto editable: система предлагает ID автоматически, но пользователь может отредактировать.
• auto non-editable: система генерирует ID, редактирование запрещено.

Как работает subjectIdPrefixSuffix при авто-генерации:

• включено: ID формируется по шаблону вида S-{site_code}-{seq:03d}, и счётчик обычно идёт внутри центра;
• выключено: ID упрощается до последовательности (0001, 0002, …) и счётчик идёт по исследованию.

примечание

Шаблон авто-генерации ID может быть настроен для проекта (если требуется иной формат).

2) Поля интервьюера в CRF

Поля интервьюера — метаданные формы (в заголовке/шапке CRF), которые участвуют в аудите и могут быть обязательными для сохранения/завершения.

Настройка	Что делает
interviewerNameRequired	включает поле «Имя интервьюера» и задаёт обязательность
interviewerNameDefault	пустое или предзаполненное именем текущего пользователя
interviewerNameEditable	можно ли править предзаполненное имя
interviewDateRequired	включает поле «Дата интервью» и задаёт обязательность
interviewDateDefault	пустая или предзаполненная датой события
interviewDateEditable	можно ли править предзаполненную дату

Практика:

• если включили обязательность интервьюера в середине исследования, команда Data Entry начнёт получать ошибки сохранения на старых формах, где поле пустое;
• заранее прогоните smoke-сценарий на тестовом субъекте.

3) Отображение в CRF

Эти настройки не меняют данные, они меняют шапку CRF для удобной идентификации.

• personIdShownOnCrf: показывать Person ID в заголовке CRF.
• secondaryLabelViewable: показывать Secondary ID в заголовке CRF.

4) Поведение системы

Настройка	Что меняет
Причина изменения (админ) (adminForcedReasonForChange)	требует RFC при административных правках данных и фиксирует причину в audit trail
Местоположение события (eventLocationRequired)	включает/делает обязательным поле “Location” для визитов
Управление расхождениями (discrepancyManagement)	включает/выключает модуль Queries (страницы Queries и панель в CRF)
Автосохранение CRF (crfAutosaveEnabled)	включает фоновое автосохранение в Data Entry. По умолчанию выключено: пользователи сохраняют форму вручную

Рекомендация по эксплуатации:

• оставляйте автосохранение выключенным, если важен максимально явный контроль момента сохранения;
• включайте автосохранение для исследований с интенсивным вводом, где критично снизить риск потери незаписанных изменений.

5) Расширенные функции (Plus)

Эти поля видны в UI как опциональные модули:

• participantPortal: портал участников (enabled/disabled)
• randomization: рандомизация (enabled/disabled)

Если модуль выключен, связанные действия и разделы скрываются.

Вкладка Users (команда исследования)

Вкладка users управляет доступом людей к исследованию:

• приглашения (pending → accepted),
• назначения ролей,
• ограничения по центрам (site scope),
• экспорт списка команды для off-line проверки.

Практика безопасных назначений:

1. Сначала убедитесь, что у пользователя есть доступ к нужному исследованию.
2. Назначайте роль в правильном scope (study vs site).
3. Если роль site-уровня, ограничьте центры (sites) явно.
4. После назначения попросите пользователя обновить страницу и проверить меню.

Базовый безопасный процесс изменений

1. Сформулируйте цель изменения (что должно стать доступно/обязательно).
2. Проверьте статус исследования (не read-only ли контур).
3. Примените изменение.
4. Прогоните короткий E2E сценарий на тестовом субъекте.
5. Сообщите команде, что правило вступило в силу (особенно если выросла обязательность).

Диагностика (симптом → проверка → действие)

Симптом	Проверка	Действие
Вкладка Settings не видна	есть ли studies.view_study и доступ к study	проверить назначения роли (study-scope)
Не получается сохранить general/protocol	studies.change_study + статус исследования	дать право / перевести в «Черновик» или «Активен»
Не получается сохранить data-collection	studies.manage_study + статус исследования	дать manage_study или использовать роль выше
Вкладка Users не видна	studies.manage_study_users	дать право или делегировать Study Director
Queries не появились после включения	модуль включён, но роль не видит меню	обновить страницу, проверить queries.view_discrepancynote и scope

Смежные страницы

• Запуск исследования
• Роли и права
• Администрирование
• Queries