Перейти к основному содержимому

Операции — субъекты и визиты

Каноническая страница ежедневного операционного контура: субъект → визит → CRF → Data Entry → queries/SDV → closeout.

Для кого

  • CRC / Data Specialist / Data Entry Person (операции центра);
  • Data Manager / Monitor (контроль статусов, качество данных).

Где это в UI

  • Aggregated subjects (для study-wide ролей): /studies/[studyId]/subjects
  • Subject Matrix (центр): /studies/[studyId]/sites/[siteId]/subjects
  • Карточка субъекта: /studies/[studyId]/sites/[siteId]/subjects/[subjectId]
  • Страница визита: /studies/[studyId]/sites/[siteId]/subjects/[subjectId]/events/[eventId]
подсказка

Если у вас роль с ограничением по центрам, система часто ведет в site-centric UI и вы будете работать через матрицу субъекта центра.

1) Базовый маршрут до CRF

  1. Откройте список субъектов (aggregated) или матрицу центра (matrix).
  2. Найдите субъекта по Subject ID / фильтрам.
  3. Откройте визит (event) и проверьте его статус.
  4. Откройте нужную CRF.
  5. Перейдите в Data Entry (Start/Continue/View).

2) Subject Matrix: что это и как читать

Subject Matrix — это “OpenClinica-style” таблица:

  • строки: субъекты;
  • колонки: визиты (event definitions);
  • ячейки: статус визита и прогресс CRF внутри визита (completion, queries, SDV, подпись).

Типовые возможности матрицы:

  • фильтры (по статусам субъектов/визитов/CRF, open queries, SDV);
  • поиск по Subject ID;
  • табы по визитам (если включены);
  • popover в ячейке: список CRF визита и быстрый переход в Data Entry.

3) Статусы субъекта: два уровня (важно)

В UI встречаются два разных “статуса”:

  1. Enrollment status (участие в исследовании): SCREENED, ENROLLED, COMPLETED, WITHDRAWN, SCREEN_FAILED.
  2. Core status записи (технический): AVAILABLE, DELETED, SIGNED, LOCKED, FROZEN и т.д.

Практическое следствие:

  • можно “удалить” субъекта (core status), не меняя enrollment;
  • enrollment влияет на операционные отчеты и readiness, core status — на доступность действий.

4) Создание/зачисление субъекта (Enroll)

Предусловия

  • есть право subjects.add_studysubject (создание участия);
  • исследование в статусе AVAILABLE (в UI: «Активен») — иначе добавление блокируется процессно;
  • вы находитесь в контексте нужного центра (site).

Что нужно заполнить

Набор полей зависит от Settings → data-collection:

  • Subject ID: ручной или авто-генерируемый (см. subjectIdGeneration);
  • DOB/год рождения: зависит от collectDob;
  • пол: зависит от genderRequired;
  • Person ID: зависит от subjectPersonIdRequired.

Ограничения (важно для ошибок валидации):

  • Subject ID уникален в пределах исследования;
  • длина Subject ID и Secondary ID ограничена (типично до 30 символов);
  • Person ID (если используется) ограничен по длине (типично до 255) и не должен дублировать уже зачисленного субъекта.

Типовой сценарий

  1. Откройте матрицу центра.
  2. Нажмите действие зачисления/добавления субъекта.
  3. Заполните обязательные поля.
  4. Сохраните.
  5. При необходимости сразу запланируйте визит (Schedule).
примечание

Если Subject ID авто-генерируется, он зависит от настроек генерации и может включать site_code и последовательность.

5) Визиты (Study Events): типы, статусы, действия

В системе важно различать:

  • Event Definition — “шаблон” визита в дизайне исследования (протокол).
  • Study Event — конкретный визит у конкретного субъекта (операционная сущность).

Типы визитов

  • SCHEDULED (плановые): заранее определены протоколом.
  • UNSCHEDULED (внеплановые): создаются по необходимости.

Статусы визита и что они означают

СтатусСмыслЧто обычно доступно
NOT_SCHEDULEDвизит не стоит в расписаниизапланировать (schedule) или остановить
SCHEDULEDзапланированввод данных, перенос даты, skip/miss
DATA_ENTRY_STARTEDначат ввод по одной из CRFпродолжить ввод, контроль CRF
COMPLETEDвсе ключевые условия completion выполненыподпись/блокировка (по правам и pre-checks)
SKIPPEDвизит пропущентолько просмотр
STOPPEDвизит остановлен (missed)только просмотр
SIGNEDвизит подписанпросмотр, возможна блокировка (по процессу)
LOCKEDвизит заблокировантолько просмотр

Действия с визитом (в матрице/карточке субъекта)

  • Schedule: поставить визит в расписание (создать/активировать событие).
  • Reschedule: перенести дату.
  • Skip: пропустить визит (обычно требует причины по SOP).
  • Miss/Stop: зафиксировать “не состоялся” (обычно с причиной).
  • Sign: подписать (после completion и при выполнении pre-checks).
  • Lock: заблокировать (самый “жёсткий” read-only контур).
  • Remove: убрать визит из операционного контура (мягкое удаление).
warning

Статусы LOCKED, SIGNED, STOPPED, SKIPPED переводят контур визита в read-only: Data Entry по CRF внутри такого визита будет недоступен.

6) CRF внутри визита: где смотреть и как стартовать ввод

Основные точки:

  • на странице визита показывается список CRF, их статусы и доступные действия;
  • если Event CRF еще не создан, при старте ввода система создаст его на версии по умолчанию из assignment (если не задана — старт будет заблокирован).

Полезные действия на карточке субъекта:

  • Start/Continue: перейти в Data Entry.
  • View: открыть read-only режим.
  • Print: открыть печатный вид CRF (для review/архива).

7) Карточка субъекта: вкладки и сценарии

Карточка субъекта обычно включает вкладки:

  • События и CRF: полный список визитов и форм, быстрый старт ввода.
  • Журнал аудита: статусные события и расширенный аудит (если доступен).
  • Группы: назначения в study groups (если используются).
  • Демография: поля субъекта с возможностью фиксировать заметки/queries по полям.

Casebook (выгрузка по субъекту)

Casebook формируется по субъекту и может включать:

  • данные CRF,
  • Discrepancy Notes (queries),
  • audit trail (если разрешено).

Форматы обычно: HTML / PDF / JSON / XML (ODM).

8) Удаление и восстановление (Remove/Restore)

  • Remove — мягкое удаление: доступ снимается, но история действий сохраняется (audit trail).
  • Restore — восстановление: возвращает субъект в операционный контур.

Практика:

  • не используйте remove как замену “withdrawn/completed” — это разные оси (см. статусы выше);
  • для регуляторных процессов фиксируйте rationale и следуйте SOP.

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

СимптомПроверкаДействие
Не видно матрицу/список субъектовsubjects.view_studysubject + контекст study/siteпроверить назначения роли и site-scope
Не видно кнопки зачисленияsubjects.add_studysubject + статус исследованияперевести study в AVAILABLE, уточнить права
Не создается субъектобязательные поля из Settingsпроверить Settings → data-collection и заполнение
Визит нельзя подписать/заблокироватьstatus + pre-checks (CRF complete, queries)закрыть блокеры, см. closeout
CRF не стартуетнет default version на assignment или визит read-onlyисправить assignment / проверить статус визита

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