Запросы

Запрос — официальное сообщение по конкретному значению в форме. У каждого запроса есть автор, получатель, тип, приоритет, переписка, состояние разрешения и привязка к полю, форме, визиту или субъекту. Эта страница описывает четыре типа заметок расхождений (Discrepancy Notes), полный жизненный цикл состояний, приоритеты и правила переоткрытия.

Кто что делает

Действие	Кто	Возможность
Создаёт запрос вручную	Монитор, Менеджер данных, Исследователь, Координатор	queries.create_query
Создаёт запрос автоматически	Система (правило RuleActionType.FILE_DISCREPANCY_NOTE)	—
Отвечает	Координатор, Оператор, Исследователь	queries.respond_query
Предлагает закрытие	Координатор, Исследователь	queries.respond_query
Закрывает	Монитор, Менеджер данных, Директор	queries.resolve_query
Управляет потоком (массовые действия, повторный маршрут)	Монитор, Менеджер данных	queries.manage_query_workflow
Переоткрывает закрытый запрос	Директор исследования	queries.manage_query_workflow

Где смотреть

• По исследованию (все центры): /studies/[studyId]/queries.
• По центру: /studies/[studyId]/sites/[siteId]/queries.
• Конкретный запрос (исследование): /studies/[studyId]/queries/[queryId].
• Конкретный запрос (центр): /studies/[studyId]/sites/[siteId]/queries/[queryId].
• Из формы — иконка запроса рядом с полем.
• В карточке субъекта — секция «Запросы» со списком всех запросов по этому участнику.
• В карточке формы (Event CRF) — счётчик запросов и быстрая ссылка на список.

Скриншот

Содержание: страница /studies/[studyId]/queries — фильтры по центру, статусу и приоритету, в строках Subject ID, поле, автор, срок ответа.

Типы заметок расхождений

Все запросы и связанные с ними записи — это Discrepancy Notes (DN). Тип DN определяется при создании и больше не меняется (queries.enums.DiscrepancyNoteType).

Тип	Что это	Кто создаёт	Требует ответа
Запрос (QUERY)	Ручной вопрос по значению	Монитор, Менеджер данных, Исследователь, Координатор	Да
Аннотация (ANNOTATION)	Информационная заметка без действий	Любой с правом просмотра данных	Нет
Ошибка валидации (FAILED_VALIDATION_CHECK)	Системный запрос от правила валидации	Система	Да
Причина изменения (REASON_FOR_CHANGE)	Обязательное обоснование при «Административном редактировании»	Менеджер данных, Директор	Нет

QUERY и FAILED_VALIDATION_CHECK ведут себя одинаково в потоке закрытия. ANNOTATION и REASON_FOR_CHANGE остаются видимыми в журнале аудита, но не блокируют процессы.

Приоритет

Приоритет (queries.enums.QueryPriority) задаётся при создании. На него настраивают фильтры и SLA внутри команды.

Приоритет	Когда выбирать
Низкий	Уточнения, не блокирующие подпись
Средний	Стандартный рабочий случай
Высокий	Влияет на критичные клинические оценки
Критический	Безопасность субъекта, регуляторные требования, явные ошибки данных

Состояния разрешения

В таблице запросов отображается итоговое состояние разрешения (QueryResolutionStatus). В карточке самого запроса видна полная переписка: каждое следующее сообщение фиксирует промежуточное состояние.

Состояние	Что означает	Итоговый статус	Что можно делать
Открыт	Создан, ждёт ответа	Открыт	Ответить, изменить приоритет, закрыть
Обновлён	После ответа центра запрос вернули запрашивающему	Открыт	Уточнить, предложить закрытие, закрыть
Предложено решение	Центр предложил закрыть запрос	Открыт	Закрыть с подтверждением или вернуть на доработку
Закрыт	Запрос закрыт без правки данных	Закрыт	Только просмотр; переоткрытие — Директор
Закрыт — данные изменены	Запрос закрыт, при ответе данные были исправлены	Закрыт	Только просмотр; переоткрытие — Директор
Неприменим	Запрос признан неактуальным	Закрыт	Только просмотр

«Итоговый статус» — это бинарное «открыт / закрыт», который отображается в общих счётчиках и блокировках. «Состояние переписки» — это конкретное значение из таблицы выше. И то и другое полезно: счётчик помогает понять нагрузку, состояние — где именно сейчас застрял запрос.

Скриншот

Содержание: карточка запроса — переписка с состояниями Открыт / Обновлён / Предложено решение, ссылка «Перейти к полю», кнопки «Ответить», «Предложить закрытие», «Закрыть».

Создание

1. В форме найдите поле с проблемным значением.
2. Наведите курсор — появится иконка запроса.
3. Нажмите её и заполните карточку:
   • текст вопроса;
   • тип (Запрос / Аннотация — для остальных типов карточка не создаётся вручную);
   • приоритет;
   • флаг «Блокирующий» — мешает подписи визита.
4. Сохраните. Запрос получит состояние Открыт и попадёт в очередь центра и в общий список запросов исследования.

Ответ

1. Откройте список запросов центра или перейдите по ссылке из уведомления.
2. «Перейти к полю» откроет форму на нужной секции.
3. Если вы исправляете значение, обоснование автоматически попадает в переписку как REASON_FOR_CHANGE.
4. В карточке запроса опишите, что сделано и почему.
5. Когда ситуация разрешена, выберите «Предложить закрытие» — состояние станет Предложено решение. Итоговый статус останется «Открыт» до закрытия Монитором или Менеджером данных.

Закрытие

Закрывает Монитор, Менеджер данных или Директор (возможность queries.resolve_query).

1. Откройте запрос и проверьте итоговый ответ и текущее значение в форме.
2. Если ответ удовлетворяет:
   • данные были изменены — система зафиксирует состояние Закрыт — данные изменены;
   • данные не менялись — состояние Закрыт;
   • запрос признан неактуальным — выберите Неприменим.
3. Если ответ не подходит — добавьте комментарий и вернёте состояние Обновлён; запрос остаётся «открыт».

Переоткрытие закрытого запроса

Переоткрыть запрос из Закрыт или Закрыт — данные изменены может только Директор исследования через возможность queries.manage_query_workflow. После переоткрытия состояние становится Открыт, а в переписке остаётся отметка, кто и когда переоткрыл. Используется, если после закрытия обнаружились новые обстоятельства.

Блокирующие запросы

Блокирующий запрос останавливает движение по этапам:

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

Делайте блокирующими только действительно критичные расхождения: ошибка даты визита, невозможная дозировка, сомнение по безопасности.

Связь с верификацией

• Монитор открывает запрос прямо из экрана SDV.
• Открытый блокирующий запрос на поле не даёт отметить это поле как верифицированное.
• Если после закрытия запроса данные поменялись, отметка SDV автоматически снимается — см. SDV.

Что делать, если…

Ситуация	Что проверить
Не видно раздел запросов	Нет роли Монитора, Координатора, Исследователя или Менеджера данных в этом исследовании
Нет кнопки «Создать запрос»	Возможность queries.create_query не назначена вашей роли
Не получается ответить	Запрос адресован другому центру или другому уровню роли
Не могу закрыть	Финальное закрытие — у Монитора / Менеджера данных / Директора
Не могу переоткрыть	Переоткрытие закрытых запросов — только у Директора исследования
Подпись визита не работает	Есть открытые блокирующие запросы — закройте их
Запрос «исчез» из списка	Закрыт — переключите фильтр на закрытые состояния

См. также

• Ввод данных — открытие запроса по полю прямо из формы.
• Верификация исходных данных — Монитор открывает запросы из режима SDV.
• Двойной ввод — расхождения DDE не путать с запросами.
• Закрытие исследования — закрытие всех запросов перед подписью и блокировкой.
• Правила и валидация — автоматическое создание запросов правилом.
• Справочник статусов — все состояния QueryResolutionStatus.