Эффективность проверок

Как определяется, изменил ли запрос данные, и как читать оценки.

Каждый запрос стоит времени центру и дата-менеджменту. Проверка, на запросы которой почти всегда отвечают «данные верны, согласно первичной документации», добавляет работу и не добавляет качества, а центры привыкают её игнорировать. Отчёт ранжирует edit check по доле запросов, которые ничего не изменили, и показывает поля, где люди вручную снова и снова задают один и тот же запрос: это кандидаты на новую проверку. Запускайте его по листингу запросов на промежуточном этапе, перед пересмотром проверок или когда в исследовании слишком много запросов.

Что загружать

Листинг запросов: все запросы, включая закрытые и отменённые. Столбцы узнаются по названиям: номер запроса, центр, пациент, статус, даты открытия и закрытия, форма, поле, название проверки, текст запроса, ответ, «кем открыт» (система или человек) и признак изменения данных, если ваша EDC его выгружает.
Аудиторский след (по желанию): пациент, поле, дата, старое и новое значение. Это самый надёжный способ понять, изменилось ли значение.

Как определяется исход запроса

Для каждого закрытого запроса берётся первое доступное свидетельство:

столбец «данные изменены» в листинге (Y/N, yes/no, да/нет);
аудиторский след: изменение этого поля у этого пациента между датой открытия и датой закрытия запроса, где новое значение отличается от старого;
текст ответа: слова об изменении («исправлено», «внесено», «обновлено», corrected, updated, entered) означают изменение и важнее слов подтверждения; «верно», «подтверждаю», «согласно первичной документации», «без изменений», data correct, confirmed означают, что изменений нет.

Если ничего из этого не подходит, исход «неизвестен» и считается отдельно. В сводке видно, сколько запросов оценено по каждому виду свидетельства. Текст ответа — самое слабое свидетельство: центр может написать «подтверждаю» и всё же изменить значение. По возможности добавляйте аудиторский след.

Группировка и оценки

Запросы группируются по столбцу с названием проверки. Если его нет, то по полю и тексту запроса, в котором числа и значения в кавычках заменены, так что «Возраст 40 вне 18–65» и «Возраст 71 вне 18–65» попадают в одну группу. Запросы, открытые человеком (это видно по столбцу «кем открыт», и названия проверки нет), группируются по форме и полю.

Шумная: 80% и больше запросов ничего не изменили или отменены. Поменяйте границы, текст запроса или уберите проверку.
Слабая: 50% и больше ничего не изменили. Пересмотрите её.
Полезная: большинство запросов привели к изменению данных.
Мало запросов: меньше порога (по умолчанию 10), чтобы судить.

Форма и поле с ручными запросами, где запросов не меньше порога и половина или больше привели к изменению, помечаются как кандидат на edit check.

Столбец «Центр, где больше всего» показывает, если запросы проверки идут в основном из одного центра: тогда проблема, возможно, в практике центра, а не в проверке.

Попробовать

Файлы-примеры: queries.csv, audit_trail.csv. Сначала загрузите только листинг запросов: проверка диапазона возраста окажется шумной, проверка давления слабой, проверка пропущенной даты НЯ полезной, а ручные запросы по дозе — кандидатом на новую проверку. Потом добавьте аудиторский след: исход запросов по возрасту будет определён по нему, а не по тексту ответа.

Источники

Tufts CSDD: отраслевые исследования, показывающие, что большинство запросов не меняют данные.
SCDM, Good Clinical Data Management Practices: проектирование edit check и план валидации данных.

Ничего не сохраняется. Файлы читаются в памяти и сразу удаляются, в журнал аудита пишутся только количества. Менять или убирать проверку решает команда исследования по плану валидации данных; отчёт — доказательная база для этого решения, а не само решение.