Операции — субъекты и визиты
Каноническая страница ежедневного операционного контура: субъект → визит → 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
- Откройте список субъектов (aggregated) или матрицу центра (matrix).
- Найдите субъекта по Subject ID / фильтрам.
- Откройте визит (event) и проверьте его статус.
- Откройте нужную CRF.
- Перейдите в 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 встречаются два разных “статуса”:
- Enrollment status (участие в исследовании):
SCREENED,ENROLLED,COMPLETED,WITHDRAWN,SCREEN_FAILED. - 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) и не должен дублировать уже зачисленного субъекта.
Типовой сценарий
- Откройте матрицу центра.
- Нажмите действие зачисления/добавления субъекта.
- Заполните обязательные поля.
- Сохраните.
- При необходимости сразу запланируйте визит (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: убрать визит из опера ционного контура (мягкое удаление).
Статусы 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.