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

Концепции — целостность данных и контроль качества

Эта страница описывает контуры качества данных X7 Insight (OpenClinica‑style): Audit Trail, RFC, Queries, SDV, DDE, подпись и блокировки.

Цель одна: трассируемость + воспроизводимость + управляемый closeout.

1) Audit Trail​

Audit Trail фиксирует:

  • кто сделал действие;
  • когда;
  • что именно изменилось;
  • в каком контексте (study/site/subject/event/crf/item);
  • почему изменено (RFC), если применимо.

Практическое следствие: “исправить задним числом и забыть” в EDC нельзя — каждый процессный шаг оставляет след, и это правильно для GxP.

2) RFC (Reason for Change)​

RFC требуется для изменений после завершения контуров ввода и в других процессно-чувствительных операциях.

Практика качественного RFC:

  • коротко и предметно,
  • с источником уточнения,
  • без общих формулировок вида «исправлено».

3) Queries (Discrepancy Notes) — основной контур data cleaning​

Queries используются для коммуникации и фиксации решения внутри данных, а не “в чате”.

Типы queries:

  • ручные (QUERY, ANNOTATION);
  • системные (валидации, DDE discrepancies).

Важный принцип: обсуждение и решение фиксируются в треде запроса, а не во внешнем чате.

Важно понимать две независимых оси:

  • priority (LOW/MEDIUM/HIGH/CRITICAL) — для очереди работ;
  • is_blocking — для блокировки подписи.

Подробно: Queries.

4) SDV (Source Data Verification)​

SDV подтверждает соответствие данных источнику.

После изменений данных SDV может быть сброшен и должен быть выполнен повторно.

Подробно: SDV.

5) Подпись и блокировка (closeout‑контур)​

  • Электронная подпись подтверждает состояние данных «на текущий момент».
  • Любое изменение после подписи может автоматически снять подпись.
  • LOCKED фиксирует данные как read-only на уровне процесса.

Ключевая идея: подпись и lock — это не “декорации” статуса, а гарантии, которые система поддерживает автоматически.

Подробно: Closeout.

6) DDE и расхождения​

При включённом DDE вторичный ввод сравнивается с первичным. Различия создают DDE discrepancies и системные queries.

Данные считаются процессно-готовыми после разрешения расхождений и выполнения дальнейших pre-checks (если они включены в SOP).

7) Что сбрасывается автоматически при изменении данных (очень важный блок)​

Если данные в CRF меняются после SDV/подписи, система может автоматически:

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

Это ожидаемое поведение и защита процесса: подпись/SDV подтверждают состояние данных, а не “разрешают править бесследно”.

8) Рекомендованный порядок data cleaning (SOP‑friendly)​

  1. Data Entry → Complete.
  2. DDE (если требуется) → разрешение discrepancies.
  3. Queries → закрытие/фиксирование решений.
  4. SDV → верификация.
  5. Подпись → фиксация ответственности.
  6. Lock → перевод в read‑only там, где это нужно по SOP.

9) Модули, которые меняют поведение системы​

На уровне настроек исследования ключевые переключатели:

  • Queries / discrepancy management;
  • RFC requirement;
  • DDE requirement (на assignment CRF↔visit);
  • SDV requirement (на assignment CRF↔visit).

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