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

Операции — Data Entry (CRF)

Эта страница описывает полный рабочий контур Data Entry в X7 Insight: от открытия формы до завершения, DDE, SDV, подписи, RFC‑правок и диагностики типовых проблем.

Для кого​

  • CRC / Data Entry / Data Specialist: ежедневный ввод данных.
  • Monitor / Data Manager: контроль качества данных, SDV и closeout.
  • Study Director: процессные исключения и эскалации по SOP.

Карта процесса (кратко)​

Где это в UI​

  • Канонический маршрут CRF: /studies/[studyId]/sites/[siteId]/subjects/[subjectId]/events/[eventId]/crfs/[eventCrfId]
  • Короткий deep-link: /studies/[studyId]/data-entry/[eventCrfId] (редиректит в канонический маршрут).
  • SDV-режим: тот же URL + ?mode=sdv.

1) Как система выбирает Start / Continue / View​

Решение всегда строится на 4 факторах:

  1. Права роли в правильном scope (study/site).
  2. Статус визита (event) и формы (event CRF).
  3. Наличие технического editing lock.
  4. Owner-gating для IDE/DDE.
Что видит пользовательКогда так будетЧто чаще блокирует
Startформы еще нет или UNCOMPLETED, есть право начать вводнет data.add_itemdata, read-only статус визита, lock другого пользователя
ContinueCRF в INITIAL_DATA_ENTRY / DOUBLE_DATA_ENTRY / ADMINISTRATIVE_EDITING и разрешено редактированиеowner-gating, editing lock, отсутствие data.administrative_editing для admin edit
Viewзавершённая/заблокированная форма или нет прав на редактированиеLOCKED, SIGNED/LOCKED/STOPPED/SKIPPED у визита, can_edit=false
Locked Viewevent_crf_status=LOCKEDтребуется явная разблокировка по SOP
подсказка

UI опирается на серверные флаги can_edit, can_complete, can_sign, dde_status. Если кнопка неактивна или отсутствует, сначала проверяйте эти флаги и статусы.

2) Режимы страницы​

  • Entry: ввод/изменение данных, сохранение, завершение.
  • View: read-only просмотр.
  • SDV: верификация источников (mode=sdv) с отдельным контуром SDV-кнопок.

Переключение в view может происходить автоматически, если:

  • форма в завершённой стадии и пользователь не в Administrative Editing;
  • форма или визит в read-only процессе;
  • can_edit=false из-за owner-gating или lock.

3) Сохранение данных​

3.1 Кнопки секции​

  • Сохранить и далее: сохранить и перейти к следующей секции.
  • Сохр. и выйти: сохранить и выйти на страницу визита (не последняя секция).
  • Сохранить: сохранить на последней секции.
  • Выход: выйти без сохранения текущих изменений.

3.2 Автосохранение​

Настройка: Settings → data-collection → Автосохранение CRF (crfAutosaveEnabled).

  • по умолчанию автосохранение выключено;
  • при включении изменения сохраняются в фоне (debounce);
  • автосохранение не запускается при ошибках валидации и блокирующих rule errors.

3.3 Что блокирует сохранение​

  • ошибки валидации полей;
  • blocking errors от rules;
  • конфликт параллельной правки (409 conflict);
  • активный editing lock другого пользователя.
warning

При 409 conflict локальные изменения не применяются. Нужно обновить данные с сервера, перепроверить конфликтующие поля и повторить сохранение.

4) “Отметить CRF как завершенный” (Mark Complete)​

Чекбокс на последней секции работает по OpenClinica-логике:

  • сам чекбокс не завершает форму мгновенно;
  • завершение пытается выполниться на следующем сохранении;
  • если нужна электронная подпись, при завершении откроется подпись;
  • при незаполненных обязательных полях завершение блокируется.

5) Завершение ввода (Complete): что проверяется​

Завершить ввод и Сохранить и завершить делают один и тот же процесс:

  1. Сохраняют pending изменения.
  2. Проверяют required-поля с учетом display logic/visibility.
  3. Проверяют обязательные метаданные CRF (если включены в настройках):
    • interviewer_name,
    • date_interviewed.
  4. При необходимости запрашивают пароль подписи.
  5. Выполняют переход статуса формы.

Важно:

  • если форма уже в DOUBLE_DATA_ENTRY_COMPLETE, endpoint complete-entry с паролем используется как операция подписи;
  • без пароля для такого статуса сервер вернет ошибку;
  • кнопка может быть видима, но завершение завершится ошибкой при фактических блокерах.

6) Статусы Event CRF и переходы​

СтатусСмысл
UNCOMPLETEDформа существует, ввод не начат
INITIAL_DATA_ENTRYпервичный ввод
INITIAL_DATA_ENTRY_COMPLETEпервичный ввод завершён (ожидание DDE при необходимости)
DOUBLE_DATA_ENTRYвторичный DDE-ввод
DOUBLE_DATA_ENTRY_COMPLETEввод завершён (терминальная completed-стадия для подписи)
ADMINISTRATIVE_EDITINGпривилегированная стадия пост-редактирования
LOCKEDпроцессный read-only lock
подсказка

Если DDE не требуется, завершение IDE сразу переводит форму в DOUBLE_DATA_ENTRY_COMPLETE.

7) DDE (Double Data Entry): подробный сценарий​

7.1 Где включается DDE​

DDE включается на уровне assignment CRF ↔ визит, а не “на всём исследовании”.

7.2 Когда можно начать secondary​

Нужно одновременно:

  • event_crf_status = INITIAL_DATA_ENTRY_COMPLETE;
  • завершена primary DDE session;
  • есть право data.perform_dde;
  • нет конфликтующего editing lock.

7.3 Правило “12 часов”​

Если первичный ввод завершил пользователь A, пользователь A не может начать secondary раньше, чем через 12 часов, если нет права data.bypass_dde_time_restriction.

UI получает это через dde_status:

  • can_start_secondary,
  • secondary_start_restricted_until,
  • secondary_start_restriction_reason.

7.4 Что важно в secondary​

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

7.5 После завершения secondary​

  • форма переходит в DOUBLE_DATA_ENTRY_COMPLETE;
  • система сравнивает primary vs secondary;
  • создаются DDE discrepancies и системные queries по расхождениям;
  • расхождения открываются отдельно через диалог Расхождения DDE (N).

8) Queries внутри Data Entry​

В форме queries видны на трех уровнях:

  • рядом с полем (field-level);
  • в панели query-thread справа;
  • на метаданных формы (interviewer_name, date_interviewed).

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

  • открытые blocking queries блокируют подпись CRF/visit/subject;
  • часть query-типов создаётся автоматически (rules, DDE discrepancies);
  • в Admin Editing RFC может требоваться как обязательная причина правки.

Подробно: Queries.

9) SDV в Data Entry​

SDV доступен в режиме ?mode=sdv при выполнении условий:

  • право data.perform_sdv;
  • SDV требуется для CRF по assignment;
  • форма в completed-стадии (INITIAL_DATA_ENTRY_COMPLETE или DOUBLE_DATA_ENTRY_COMPLETE);
  • визит не SIGNED и не LOCKED;
  • сама форма не LOCKED.

Любая правка данных после SDV:

  • снимает SDV флаг;
  • очищает SDV-комментарий;
  • фиксируется в audit.

Подробно: SDV.

10) Электронная подпись CRF​

Подпись формы:

  • требует пароль пользователя;
  • доступна только на DOUBLE_DATA_ENTRY_COMPLETE;
  • блокируется открытыми blocking queries;
  • снимается автоматически при изменении данных.

Не путайте операции:

  • Complete = завершить стадию ввода;
  • Sign = применить электронную подпись к завершенной форме.

11) Administrative Editing и RFC​

11.1 Когда можно войти​

  • есть право data.administrative_editing;
  • форма уже completed;
  • форма/визит/исследование не в process read-only блокировке;
  • для DDE-форм — только после полной DDE готовности (обычно после DOUBLE_DATA_ENTRY_COMPLETE).

11.2 RFC-правила​

При включенном forced RFC (adminForcedReasonForChange):

  • каждое изменение поля должно иметь Reason for Change;
  • удаления ItemData тоже требуют RFC;
  • без RFC сохранение блокируется.

11.3 Чем завершается admin edit​

Завершить редактирование возвращает форму в completed-стадию:

  • обычно в DOUBLE_DATA_ENTRY_COMPLETE;
  • в DDE-кейсе с незавершенным secondary может вернуться в INITIAL_DATA_ENTRY_COMPLETE;
  • при открытых DDE discrepancies завершение admin edit блокируется.

12) Блокировки: editing lock vs LOCKED​

ТипНазначениеКак ведет себя
Editing lockзащита от одновременной правкикраткоживущий lock, обычно истекает автоматически (по умолчанию 30 мин), продлевается в процессе работы
LOCKED статуспроцессная блокировка формыстабильный read-only до явной разблокировки

Если CRF редактирует другой пользователь:

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

13) Repeating structures​

Repeating item groups​

  • каждая строка группы имеет свой ordinal;
  • удаление строк в Admin Editing может требовать RFC;
  • required/display logic считаются с учетом ordinal.

Repeating CRF​

  • в одном визите может быть несколько экземпляров одной CRF;
  • у каждого экземпляра свой lifecycle (status/signature/SDV/queries).

14) Сквозные рабочие сценарии​

Сценарий A: обычный ввод без DDE​

  1. Start формы.
  2. Ввод по секциям + сохранения.
  3. На последней секции отметить Mark Complete.
  4. Сохранить и завершить.
  5. Форма в DOUBLE_DATA_ENTRY_COMPLETE.
  6. При необходимости подписать (пароль).

Сценарий B: DDE​

  1. Пользователь A завершает IDE, форма в INITIAL_DATA_ENTRY_COMPLETE.
  2. Пользователь B (или A после 12 часов/с bypass правом) запускает secondary.
  3. Secondary ввод и завершение.
  4. Система создает расхождения.
  5. Команда разрешает DDE discrepancies.
  6. Дальше SDV/подпись/closeout.

Сценарий C: правка завершенной/подписанной формы​

  1. Перейти в Редактировать (RFC).
  2. Внести правки с RFC.
  3. Завершить редактирование.
  4. Подпись и SDV сбросятся автоматически.
  5. Повторить SDV/подпись по SOP.

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

СимптомЧто проверитьЧто делать
Форма открывается только read-onlyстатусы визита/CRF, can_edit, mode, lockначать со статусов, потом rights/scope, затем editing lock
Нет Завершить вводcan_complete, статус CRF, owner-gatingпроверить кто начал IDE/DDE, права data.submit_data
При Complete ошибка про парольelectronic_signature_required, completed-stageподписать через пароль и повторить
DDE secondary не стартуетdde_status.can_start_secondary, 12h rule, data.perform_ddeдождаться restricted_until или использовать bypass-роль
Сообщение “Only the user who started...”owner-gating IDE/DDEпродолжает тот же пользователь или super-role по SOP
Нельзя войти в Admin EditingDDE не полностью завершён, нет data.administrative_editing, process lockдовести DDE до complete, проверить права и lock
Нельзя поставить/снять SDVнет data.perform_sdv, event SIGNED/LOCKED, CRF LOCKEDперевести визит/форму в допустимую стадию, затем повторить
409 conflict при sync-item-dataданные изменены после clientLastSyncAtзагрузить свежие данные, применить правки снова
Подпись недоступнастатус не DOUBLE_DATA_ENTRY_COMPLETE, blocking queriesзавершить ввод/закрыть blocking queries
После правки “исчезла подпись/SDV”штатные side effects на data changeэто ожидаемо, выполнить повторный SDV/подпись

16) Мини-чеклисты для команды​

Перед началом ввода​

  1. Проверить, что визит не в STOPPED/SKIPPED/SIGNED/LOCKED.
  2. Проверить корректный CRF и экземпляр (ordinal для repeats).
  3. Убедиться, что форму не редактирует другой пользователь.

Перед завершением формы​

  1. Проверить обязательные поля и rule errors.
  2. Проверить метаданные интервьюера/даты (если required).
  3. Для DDE: убедиться, что стадия правильная (IDE vs DDE).

Перед подписью/closeout​

  1. Нет открытых blocking queries.
  2. Форма в DOUBLE_DATA_ENTRY_COMPLETE.
  3. SDV выполнен там, где SOP это требует.

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