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

Операции — Closeout (подпись, блокировки, read-only)

Closeout в X7 Insight — это контролируемый переход от активного ввода данных к “зафиксированному” контуру: подпись, блокировки и перевод данных в read‑only там, где это требует SOP.

На практике closeout отвечает на 3 вопроса:

  1. Готовы ли данные (CRF completed, DDE/queries/SDV отработаны).
  2. Можно ли подписывать (нет blocking‑блокеров).
  3. Можно ли блокировать (нет критичных процессных блокеров).

Для кого

  • CRC / Data Entry: доведение форм до “готово” (complete) и ответы на queries.
  • Monitor / Data Manager: SDV, закрытие queries, readiness.
  • Study Director: финальные процессные решения (подпись/lock, исключения).

1) Разные “статусы” в системе (обязательно понять)

В closeout участвуют несколько независимых осей:

  • Event CRF status: стадия ввода формы (INITIAL_DATA_ENTRY, DOUBLE_DATA_ENTRY_COMPLETE, …).
  • Event status (визит): стадия визита (COMPLETED, SIGNED, LOCKED, …).
  • Core status (Study/Site/Subject): базовый статус (AVAILABLE/LOCKED/SIGNED/...) — влияет на редактируемость.
  • Electronic signature: флаг электронной подписи формы (electronic_signature_status).
  • SDV status: флаг SDV (sdv_status).

Closeout — это не “одна кнопка”. Это набор действий на разных уровнях.

2) Типовой порядок closeout (рекомендуемый)

  1. Довести CRF до завершения ввода (Complete).
  2. Разрешить DDE (если включено): secondary entry + discrepancies.
  3. Отработать Queries (data cleaning).
  4. Выполнить SDV (если требуется SOP).
  5. Выполнить электронную подпись (CRF / визит / субъект — по процессу).
  6. Выполнить блокировку (CRF / визит / выше) — если это часть SOP.

3) Подпись: уровни и pre-checks (что реально блокирует)

3.1 Подпись CRF (электронная подпись формы)

Что делает:

  • ставит электронную подпись на конкретную форму (Event CRF).

Требования:

  • форма в статусе DOUBLE_DATA_ENTRY_COMPLETE (ввод данных завершён);
  • в форме нет открытых blocking queries;
  • у роли есть право подписи (events.sign_studyevent);
  • требуется пароль.

Практика:

  • Если подпись “пропала” после правки — это ожидаемо: любая мутация данных снимает подпись.

3.2 Подпись визита (Study Event)

Что делает:

  • переводит визит в SIGNED;
  • подписывает (ставит electronic_signature_status=true) все “открытые” формы визита.

Требования:

  • визит должен быть COMPLETED;
  • обязательные CRF визита должны быть завершены (включая “не открытые” обязательные формы);
  • нет открытых blocking queries в контуре визита (на визите/формах/полях);
  • у роли есть events.sign_studyevent;
  • требуется пароль.

Важно:

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

3.3 Подпись субъекта (Study Subject)

Что делает:

  • переводит субъекта в SIGNED;
  • переводит все визиты субъекта в SIGNED;
  • подписывает все формы под ними.

Требования:

  • все обязательные CRF субъекта завершены;
  • все визиты субъекта в COMPLETED;
  • нет открытых blocking queries на уровне субъекта;
  • право subjects.sign_studysubject;
  • требуется пароль.

4) Блокировка (Lock): уровни и pre-checks

4.1 Блокировка формы (Event CRF → LOCKED)

Что делает:

  • переводит форму в LOCKED (read‑only) и запоминает пред‑lock статус для корректного восстановления при unlock.

Требования:

  • право data.manage_eventcrf_lock;
  • форма должна быть завершена/в допустимой стадии для lock:
    • INITIAL_DATA_ENTRY_COMPLETE или DOUBLE_DATA_ENTRY_COMPLETE или ADMINISTRATIVE_EDITING;
  • исследование не должно быть в read‑only core‑статусе;
  • не должно быть конфликтующего editing lock.

Важно:

  • Lock формы не является “подписью” и не заменяет closeout‑контуры качества.

4.2 Блокировка визита (Study Event → LOCKED)

Что делает:

  • переводит визит в LOCKED и синхронизирует статусы форм визита с lock‑контуром.

Требования (строже, чем для подписи):

  • обязательные формы присутствуют и завершены;
  • все открытые формы визита завершены (не только обязательные);
  • нет открытых HIGH/CRITICAL queries в статусах OPEN/UPDATED на уровне визита/форм.
  • право data.manage_eventcrf_lock.

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

  • Если lock визита недоступен, сначала проверьте: незавершенные формы и критичные queries.

5) Что система делает автоматически при изменениях данных

Любые изменения данных в форме могут:

  • снять электронную подпись формы;
  • сбросить SDV (если оно было установлено);
  • если был подписан визит/субъект — вернуть их статусы из SIGNED обратно в COMPLETED (это ожидаемая защита целостности процесса).

После правок процесс обычно требует повторных шагов: SDV → подпись → lock (если применимо).

6) Почему “нет кнопки Sign/Lock” (алгоритм проверки)

  1. Вы в правильном контексте (study/site).
  2. У роли есть нужное право:
    • подпись: events.sign_studyevent или subjects.sign_studysubject
    • блокировка: data.manage_eventcrf_lock
  3. Статусы позволяют действие:
    • CRF должен быть завершен для подписи/SDV,
    • визит должен быть COMPLETED для подписи визита,
    • визит/исследование не в read‑only для SDV/редактирования.
  4. Нет процессных блокеров:
    • для подписи: blocking queries,
    • для lock визита: HIGH/CRITICAL queries OPEN/UPDATED + незавершенные формы.
  5. Нет конфликтующего editing lock (форма сейчас не редактируется другим пользователем).

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

СимптомПричинаЧто делать
Не подписывается CRFформа не в DOUBLE_DATA_ENTRY_COMPLETE или есть blocking queriesдовести ввод/DDE, закрыть blocking queries
Не подписывается визитвизит не COMPLETED или есть blocking queriesзавершить обязательные CRF, закрыть blocking queries
Не блокируется визитесть незавершенные формы или критичные queriesзавершить формы, закрыть HIGH/CRITICAL queries OPEN/UPDATED
После правки “пропала подпись/SDV”ожидаемый auto‑reset при data changeповторить SDV/подпись по SOP
Нужно исправить данные после closeoutданные read‑onlyadmin edit (RFC) / unlock по SOP, затем повторный closeout

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