Ключевые понятия
Эта страница даёт минимальный словарь, необходимый, чтобы читать остальную документацию X7 Insight без сносок. Понятия разобраны через ту иерархию, в которой они существуют в системе: от исследования к конкретному значению поля. Полный перечень терминов — в Глоссарии; все статусы со списком переходов — на странице Статусы.
Исследование (Study)
Верхний уровень: протокол, набор форм, команда, правила валидации, центры, журнал аудита. Один экземпляр X7 Insight ведёт произвольное число исследований; пользователь видит только те, в которые он назначен.
- Главная исследования —
/studies/[studyId]. - Настройки —
/studies/[studyId]/settings/general,/protocol,/data-collection,/users. - Жизненный цикл задаётся
core.enums.Status:Черновик → Активен → Заморожен → Заблокирован → Подписан. Возможна также деактивация (Неактивен) и удаление (Удалён,Автоудалён).
Подробности — Запуск исследования и Настройки исследования.
Центр (Site)
Клиническая площадка, где работают с реальными субъектами. В исследовании может быть один или несколько центров; у каждого собственная команда, субъекты, запросы и журнал делегирования.
В X7 Insight различают три типа центров (studies.enums.SiteType):
- Головной центр (
HEAD) — координирующий центр, который может иметь подчинённые. - Дочерний центр (
BRANCH) — центр, подчинённый головному. - Независимый центр (
INDEPENDENT) — самостоятельный центр без иерархии.
Маршруты:
- Главная центра —
/studies/[studyId]/sites/[siteId]. - Команда —
/studies/[studyId]/sites/[siteId]/team. - Журнал делегирования —
/studies/[studyId]/sites/[siteId]/team/delegation-log.
Статусы центра — те же, что у исследования (Черновик, Активен, Неактивен, Заблокирован).
Команда исследования
Состоит из пользователей с назначенными ролями. Семь стандартных ролей (roles.enums.RoleType):
| Роль | Область назначения |
|---|---|
| Системный администратор | Глобально |
| Директор исследования | Исследование |
| Менеджер данных | Исследование |
| Монитор | Исследование |
| Исследователь | Центр |
| Координатор клинических исследований | Центр |
| Оператор ввода данных | Центр |
Точный набор разрешённых действий определяется не самой ролью, а её capability keys — каталогом из backend/roles/capabilities.py. Полная матрица — Роли и права и Капабилити RBAC.
Субъект (Subject)
Участник исследования, привязанный к конкретному центру. В системе обезличен: используется Subject ID, а не ФИО. Связь Subject ID ↔ персональные данные хранится в центре отдельно (медицинская карта, бумажные журналы), под ответственностью исследователя.
- Карточка субъекта —
/studies/[studyId]/sites/[siteId]/subjects/[subjectId]. - Матрица субъектов центра —
/studies/[studyId]/sites/[siteId]/subjects. - Агрегированная таблица по всему исследованию —
/studies/[studyId]/subjects.
Статус включения субъекта в исследование — subjects.enums.SubjectEnrollmentStatus:
| Статус | Что означает |
|---|---|
| Прошёл скрининг | Скрининг успешен, ожидает зачисления |
| Зачислен | Включён в исследование |
| Выбыл | Прекратил участие до завершения |
| Завершил | Прошёл весь протокол |
| Не прошёл скрининг | Не подошёл по критериям |
Кроме статуса субъект может быть отнесён к одной или нескольким группам (subjects.enums.GroupClassType): TREATMENT (Группа лечения), AGE (Возрастная группа), GENDER (Гендерная группа), CUSTOM (Пользовательская). Назначение в группу бывает обязательным или опциональным (SubjectAssignmentType: REQUIRED, OPTIONAL).
Содержание: Матрица субъектов центра — строки субъекты, столбцы визиты, цветовые маркеры статусов форм.
EventDefinition и StudyEvent: шаблон визита и его экземпляр
Это различие критично: без него остальная документация не читается.
- EventDefinition (шаблон визита) — описание визита на уровне исследования: название, тип (
events.enums.EventType:SCHEDULED— плановое,UNSCHEDULED— внеплановое), признак повторяемости (is_repeating), список назначенных форм. Шаблон один на исследование. Маршрут —/studies/[studyId]/events/[eventDefinitionId]. - StudyEvent (экземпляр визита) — конкретный визит конкретного субъекта, созданный по шаблону. У каждого StudyEvent есть собственный статус и собственные
EventCRF. Маршрут —/studies/[studyId]/sites/[siteId]/subjects/[subjectId]/events/[eventId].
Когда координатор планирует субъекту визит «Скрининг», система создаёт новый StudyEvent на основании EventDefinition «Скрининг». Изменения шаблона задним числом не переписывают существующие StudyEvent — для этого предусмотрены отдельные операции миграции.
Статусы экземпляра визита — events.enums.SubjectEventStatus:
| Статус | Что означает |
|---|---|
| Невалидный | Несогласованное состояние; в обычной работе не возникает |
| Не запланировано | Визит существует в плане, дата не назначена |
| Запланировано | Дата назначена, ввод ещё не начат |
| Начат ввод данных | По хотя бы одной форме идёт ввод |
| Завершено | Все формы визита завершены |
| Остановлено | Визит остановлен (досрочное прекращение) |
| Пропущено | Визит пропущен по протоколу |
| Заблокировано | Визит заблокирован — правки запрещены |
| Подписано | Визит подписан исследователем |
CRF, CRFVersion и EventCRF: библиотека, версия, экземпляр
В X7 Insight форма имеет три уровня:
- CRF (форма-шаблон) — запись в библиотеке исследования. Маршрут —
/studies/[studyId]/crfs/[crfId]. - CRFVersion (версия формы) — конкретная редакция формы с собственным набором полей, секций и валидаций. У одной CRF может быть несколько версий; одна из них помечена активной. Маршруты:
/studies/[studyId]/crfs/[crfId]/versions, превью —/studies/[studyId]/crfs/[crfId]/versions/[versionId]/preview. - EventCRF (инстанс формы) — конкретная форма, заполняемая для конкретного субъекта на конкретном визите по конкретной
CRFVersion. Маршрут заполнения —/studies/[studyId]/sites/[siteId]/subjects/[subjectId]/events/[eventId]/crfs/[eventCrfId]или ярлык/studies/[studyId]/data-entry/[eventCrfId].
Версионирование критично для регуляторного соответствия: после публикации формы её определение замораживается. Любое изменение — это новая CRFVersion. Существующие EventCRF остаются на своей версии и не переписываются; миграция данных между версиями выполняется отдельной процедурой с обоснованием. Это позволяет точно ответить на вопрос «по какому варианту фор мы введён каждый ответ».
Жизненный цикл формы (EventCRF)
Все семь состояний — из data.enums.EventCRFStatus. Соответствующий русский ярлык появляется на карточке формы и в Матрице субъектов.
Поле и ItemData
Элементарное значение в форме хранится как ItemData. У каждого поля есть:
- тип (дата, число, выбор из списка, текст, файл и т. д.);
- группа полей (
ItemGroup) — поля могут идти в одиночку или в составе повторяющейся группы (например, список препаратов или нежелательных явлений); - валидации (диапазон, формат, обязательность, расчётные правила);
- история изменений — каждое значение хранится со всеми правками, временной меткой и автором;
- связанные запросы — иконка запроса появляется рядом с полем.
При правке уже сохранённого значения система требует указать Reason for Change — это автоматически фиксируется как запись типа REASON_FOR_CHANGE в журнале запросов.
Запрос (Discrepancy Note)
Запрос — формализованный комментарий к конкретному значению поля. В X7 Insight используется четыре типа (queries.enums.DiscrepancyNoteType):
| Тип | Когда возникает |
|---|---|
| Запрос | Вопрос монитора или менеджера данных к значению |
| Аннотация | Информационная пометка без требования действия |
| Ошибка валидации | Создаётся автоматически по правилу валидации |
| Причина изменения | Фиксируется системой при правке сохранённого значения |
Состояние запроса хранится в queries.enums.QueryResolutionStatus:
| Состояние | Что происходит |
|---|---|
| Открыт | Запрос создан, ждёт ответа |
| Обновлён | Координатор/исследователь ответил или поправил данные |
| Предложено решение | Предложено закрытие, ждёт подтверждения |
| Закрыт | Запрос закрыт без изменения данных |
| Закрыт — данные изменены | Запрос закрыт, данные исправлены |
| Неприменим | Запрос признан неприменимым |
Приоритет запроса (QueryPriority) — Низкий / Средний / Высокий / Критический.
Подробный сценарий работы — Запросы.
Верификация исходных данных (SDV, Source Data Verification)
Сверка значений в системе с первичными источниками — амбулаторной картой, лабораторными отчётами, ЭКГ. Выполняет монитор.
- Рабочее место монитора —
/studies/[studyId]/sdv. - У каждого поля и
EventCRFесть отметка верификации с автором, временем и причиной (если SDV сбрасывался). - Отметка автоматически снимается, если данные изменились после неё. Это называется «SDV reset» — поле повторно подлежит верификации.
Подробнее — Верификация SDV.
Двойной ввод (DDE, Double Data Entry)
Одну форму независимо заполняют два разных оператора, чтобы исключить ошибки ручного ввода.
- Включается на уровне
VisitCRFAssignment.is_double_data_entry— то есть для конкретной формы на конкретном визите, не на уровне всего исследования. - Второй оператор обязан быть другим пользователем, не тем, кто выполнил первичный ввод. Система это контролирует.
- После статуса
Первичный ввод завершёнВторой оператор открывает форму в режимеДвойной ввод данныхи вводит значения заново, не видя первой версии. - В статусе
Ввод данных завершёнсистема сравнивает обе версии и показывает расхождения для разрешения.
Подробности — Двойной ввод.
Электронная подпись
Подпись выполняется на двух уровнях:
- Подпись визита — исследователь подтверждает, что все формы визита проверены. Визит переходит в статус
Подписано. - Подпись данных субъекта — выполняется через сервис
subjects.sign_subject_data. Подписываются все формы по субъекту разом; используется при закрытии участия субъекта.
Подпись требует повторного ввода пароля (а при включённой 2FA — и кода) и сохраняется с привязкой к конкретному пользователю, ФИО, временной метке и причине. По 21 CFR Part 11 подписи защищены от изменений; снятие подписи создаёт новую запись в аудите.
Журнал аудита
Журнал аудита фиксирует, кто, что и когда изменил. Видимость управляется двумя capabilities:
audit.view_audit— журнал в разрезе исследования. Маршрут —/studies/[studyId]/audit. Доступен ролям уровня исследования и центра.audit.view_audit_global— глобальный журнал всей системы. Маршрут —/admin/audit. Доступен только Системному администратору.audit.export_audit— выгрузка журнала во внешний файл (поддерживает PHI-флаг через экспорт).
Подробности — Аудит.
Уведомления
Уведомления приходят по двум каналам: внутренние (in-app) и e-mail.
- Список уведомлений —
/notifications. Поддержаны фильтры по исследованию, типу события, прочитанности. - Настройки канала и подписок —
/profile/preferences. Каждый тип события (назначение, новый запрос, ответ, подпись, изменение команды) можно включить или выключить независимо. - Часть уведомлений генерируется правилами валидации (действие
NOTIFICATIONвrules/enums.RuleActionType).
Сводка статусов
| Объект | Источник | Цепочка состояний |
|---|---|---|
| Исследование / Центр / CRF / CRFVersion / EventDefinition | core.enums.Status | Черновик → Активен → Заморожен / Неактивен → Заблокирован → Подписан |
Визит (StudyEvent) | events.enums.SubjectEventStatus | Не запланировано → Запланировано → Начат ввод данных → Завершено / Остановлено / Пропущено → Заблокировано → Подписано |
Форма (EventCRF) | data.enums.EventCRFStatus | Не начат → Первичный ввод данных → Первичный ввод завершён → Двойной ввод данных → Ввод данных завершён → Административное редактирование → Заблокирован |
| Запрос | queries.enums.QueryResolutionStatus | Открыт → Обновлён → Предложено решение → Закрыт / Закрыт — данные изменены / Неприменим |
| Субъект | subjects.enums.SubjectEnrollmentStatus | Прошёл скрининг → Зачислен → Завершил / Выбыл / Не прошёл скрининг |
Полный список переходов с правами — Статусы.
См. также
- Глоссарий — определения всех терминов.
- Статусы — справочник статусов и переходов.
- Ввод данных — практика работы с EventCRF.
- Запуск исследования — где появляются EventDefinition и CRF.
- Роли и права — кто что может.