Операции — Queries (Discrepancy Notes)

Queries в X7 Insight = Discrepancy Notes в стиле OpenClinica: треды обсуждения и фиксации решений по качеству данных, привязанные к конкретному полю/форме/визиту/субъекту.

Эта страница отвечает на вопросы “как правильно поставить query”, “почему не меняется статус”, “что блокирует подпись/lock” и “как работает тред”.

Для кого

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

Где это в UI

• Study-wide список: /studies/[studyId]/queries
• Site-centric список: /studies/[studyId]/sites/[siteId]/queries
• Внутри CRF (Data Entry): панель queries + индикаторы рядом с полями

1) Модель треда (важно)

Query в системе — это тред, а не одиночная запись.

• Root query: parent_query = NULL (именно она считается “открытой/закрытой”).
• Child notes: каждый ответ, комментарий и смена статуса фиксируется как отдельная запись, привязанная к root.

Это нужно для GxP‑трассируемости: история треда не теряется и не “перезаписывается”.

2) На что можно повесить query (уровни привязки)

Практически полезные уровни:

• field-level: к конкретному значению поля (ItemData).
• CRF-level: к форме в целом (Event CRF).
• CRF metadata: к полям “шапки” формы (например, interviewer/date).
• Выше по иерархии (визит/субъект) — используется реже и обычно в процессных кейсах.

3) Типы Discrepancy Notes (dn_type)

Тип	Что это	Когда использовать
QUERY	обычный запрос к данным	“почему значение такое”, “нужна проверка источника”, “нужно исправить”
FAILED_VALIDATION_CHECK	системный query от правила/валидации	“значение не прошло rule/check”
ANNOTATION	информационная заметка	пояснение без требования действия
REASON_FOR_CHANGE	RFC‑контур	фиксация причины изменения (особенно при admin edit)

примечание

ANNOTATION и REASON_FOR_CHANGE — информационные типы: для них используется статус NOT_APPLICABLE.

4) Статусы (resolution_status) и как они работают

Статусы root query:

• OPEN — открыт
• UPDATED — обновлён (есть ответ/изменение контекста)
• RESOLUTION_PROPOSED — предложена резолюция (обычно со стороны центра)
• CLOSED — закрыт
• CLOSED_MODIFIED — закрыт с модификацией данных (семантика “закрыто после правки”)
• NOT_APPLICABLE — неприменимо (только для ANNOTATION и REASON_FOR_CHANGE)

Что важно на практике:

• “Открытые” статусы — это OPEN, UPDATED, RESOLUTION_PROPOSED.
• Закрытие/переоткрытие почти всегда требует отдельных прав (см. ниже).
• Для ANNOTATION и REASON_FOR_CHANGE система запрещает статусы кроме NOT_APPLICABLE.

5) Priority vs Blocking (две разные оси)

У query есть два независимых признака:

1. Priority (LOW/MEDIUM/HIGH/CRITICAL) — для приоритизации работ и triage.
2. Blocking (is_blocking=true/false) — для процессных блокировок подписи.

Как это влияет на процесс

• Подпись CRF/визита/субъекта блокируется открытыми blocking queries.
• Lock визита (event lock) блокируется открытыми HIGH/CRITICAL queries в статусах OPEN/UPDATED.

подсказка

Если цель — “нельзя подписывать, пока не решено”, используйте is_blocking=true. Если цель — “важно/срочно”, используйте priority=HIGH/CRITICAL. В SOP часто используется сочетание: “критичные и блокирующие”.

6) Типовые сценарии

Сценарий A: Monitor ставит query на поле

1. Откройте CRF.
2. Нажмите иконку queries рядом с полем.
3. Создайте QUERY с чёткой формулировкой:
   • что не так,
   • что нужно сделать (уточнить/исправить/подтвердить),
   • при необходимости: priority и is_blocking.
4. При необходимости назначьте ответственного (assign).

Сценарий B: Центр отвечает и/или правит данные

1. Откройте query (в списке queries или в CRF панели).
2. Добавьте child note (ответ).
3. Если требуется правка данных:
   • внесите правку в CRF,
   • добавьте пояснение (если требует SOP),
   • предложите резолюцию (RESOLUTION_PROPOSED), если процесс это использует.

Сценарий C: Monitor закрывает query

1. Проверьте ответ и фактические данные.
2. Переведите query в CLOSED или CLOSED_MODIFIED.
3. Переоткрывайте только при объективной причине (это отдельное действие и обычно требует отдельного права).

7) Queries и Data Entry: что увидит пользователь

В Data Entry есть несколько способов “увидеть” наличие queries:

• индикатор рядом с полем (field‑level),
• панель queries по выбранному полю,
• счётчики открытых queries на уровне CRF/визита (в матрице и карточках).

Системные источники queries:

• правила/валидации (создают FAILED_VALIDATION_CHECK);
• DDE discrepancies (создают системные queries по расхождениям).

8) Права (permissions) и “почему кнопки нет”

Коды ниже помогают админам и support быстро диагностировать доступ:

• Просмотр: queries.view_discrepancynote
• Создание query: queries.create_query
• Ответ/коммуникация (child notes): queries.respond_to_query
• Предложить резолюцию: queries.propose_resolution
• Закрыть: queries.close_query
• Назначение и bulk actions: queries.manage_queries
• Переоткрыть: queries.reopen_query (обычно только повышенные роли)
• Глобальный просмотр всех queries (без scoping): queries.view_all_queries (редко, обычно SysAdmin)

примечание

Даже при наличии прав query может быть недоступен, если в исследовании выключен модуль Settings → data-collection → discrepancyManagement.

9) FAQ и диагностика

Симптом	Причина	Что делать
Раздел Queries не виден	нет queries.view_discrepancynote или нет scope на study/site	проверить assignments в профиле
Кнопки “создать query” нет	нет queries.create_query	использовать роль/назначение с нужным правом
Статус не меняется	нет права на transition или тип DN не допускает статус	для ANNOTATION/RFC только NOT_APPLICABLE
Нельзя закрыть	нет queries.close_query	эскалировать DM/Monitor
Нельзя переоткрыть	нет queries.reopen_query	переоткрытие ограничено elevated ролями
Подпись/closeout заблокированы	есть открытые blocking queries	закрыть/разрешить blocking контур

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

• Data Entry
• SDV
• Closeout
• Settings исследования