AI для клинических испытаний: подбор пациентов и мониторинг

Почему AI в клинических испытаниях буксует на отборе пациентов

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

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

Скрытая цена — не только часы. Пока отбор не воспроизводится, нельзя доказать, что критерии применяли одинаково ко всем: вопрос аудита требует заново перечитать первичные документы, а расхождение списков ставит под сомнение качество данных всего исследования. Потеря пациентов растягивает набор и сдвигает сроки по всему протоколу.

Разбираем, как закрывается это узкое место: как перевести текстовые критерии в проверяемые запросы к данным, свести разрозненные источники в один слой и сделать отбор повторяемым.

Эффект от внедрения: скорость набора и полнота данных

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

Сокращение времени предварительного отбора

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

Отдельно виден эффект по отсеву: пациент, отвалившийся на проверке критериев, больше не тратит слот визита. Уходят два класса ошибок — пропущенный подходящий пациент и приглашённый неподходящий.

Единый профиль пациента вместо ручных сверок

Данные истории болезни, лаборатории и дневников сводятся в один профиль по стандарту CDISC — с указанием источника и времени для каждого поля. Число ручных сверок падает: расхождения между системами ловит правило, а не человек. Полнота профиля становится измеримой — доля заполненных обязательных полей видна на панели контроля, пробелы закрываются до визита.

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

Сравнение подходов: правила, модель, гибрид

Правила, модель и их комбинация решают одну задачу — подходит ли пациент под протокол, — но ошибаются по-разному. Правила дают воспроизводимый ответ и понятную причину, модель ловит неочевидные сочетания признаков, но требует данных и объяснения решения.

Выбор зависит от зрелости данных и того, насколько формализован протокол. Ниже — варианты, между которыми реально выбирают.

Где правила надёжнее модели

Когда критерии включения и исключения записаны однозначно, правила выигрывают: результат не меняется между запусками, а отклонение пациента объясняется пунктом протокола. Аудиту показывают условия и пороги, а не веса модели.

Где модель обходит правила

Если критериев десятки и они пересекаются, правила конфликтуют между собой, а пороги отсекают пациентов, которых протокол допускает. Модель ранжирует поток по вероятности соответствия — пограничные случаи уходят на ручную проверку специалистом.

Как строится внедрение AI-модели в поток пациентов

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

Аудит данных и критериев

1. Разбираем источники: где лежат данные о пациентах, как кодируются диагнозы и результаты анализов, какие критерии включения применяются на практике и где они расходятся с протоколом.

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

3. Готовим разметку и обучаем модель на решениях исследователей, проверяя, какие признаки она использует — это контроль здравого смысла, а не только цифры качества.

4. Собираем схему интеграции с рабочими системами: выгрузки или программный интерфейс, журналирование обращений, разграничение доступа по ролям.

Проверка на исторических данных

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

• Фиксируем регламент сопровождения: когда переобучаем при смене протокола, при каких порогах модель останавливается и передаёт решение исследователю.

• Передаём команде заказчика документацию, обучение специалистов и порядок действий при сбоях.

Артефакты проекта: правила доступа, схемы данных, регламенты

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

Правила доступа и разграничение ролей

• Схема данных: сущности исследований, визитов, критериев включения и лабораторных показателей, их связи и правила обезличивания перед подачей в модель.
• Матрица ролей: кто из исследователей, координаторов и специалистов по данным видит персональные данные, а кто — только обезличенные выгрузки.
• Порядок выдачи и отзыва доступов, включая действия при уходе сотрудника из команды.
• Журналирование обращений к данным: фиксируется, кто и когда выгружал выборку и менял правила отбора.

Регламент сопровождения и обновления

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

Кейс: сократили отсев пациентов на предварительном отборе

Работали с сетью исследовательских центров: несколько активных протоколов одновременно, сотни карт кандидатов в неделю. Подбор вёл координатор, и основная масса времени и кандидатов терялась именно на предварительном отборе.

Исходная схема отбора

Критерии включения и исключения выписывались в таблицу, затем вручную сверялись с картами — структурированные поля, назначения, текстовые заключения. На один протокол уходили часы, до скрининга доходила примерно треть изначальной выборки, а часть подходящих пациентов отсеивалась ещё до контакта с врачом.

Отдельно били ложные срабатывания — кандидаты, прошедшие фильтр формально, но не подходившие по клиническим деталям. Их повторная проверка съедала до четверти времени врача.

Результат после внедрения

Критерии протокола мы описали в машиночитаемом виде и собрали конвейер: извлечение признаков из полей и текста, сопоставление с критериями, ранжирование кандидатов. Ограничения по лабораторным порогам, датам и сопутствующей терапии проверяются до того, как карта попадёт к человеку. Реестры вроде ClinicalTrials.gov разбираются в тот же набор правил, поэтому новый набор запускается без ручной переверстки.

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

Каждое решение объяснимо: видно, какой критерий сработал, поэтому координатор проверяет не всю карту, а спорный фрагмент. Это закрывает главный риск — молчаливый пропуск подходящего пациента.

Что делать, если данные пациентов лежат в разных системах?

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

Единый профиль пациента собирается в два прохода. Сначала жёсткое сопоставление по национальному идентификатору и номеру протокола, затем вероятностное — по дате рождения, полу, совпадению начала ФИО и контакту. Порог настраивается: ниже него запись уходит в карантин с пометкой, а не растворяется в модели как «почти совпадение».

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

Разметка данных опирается на тот же профиль: разметчик видит полную хронологию, а каждая метка несёт ссылку на источник и версию записи. Если расхождение всё-таки просочилось в обучение, модель воспроизводит его как закономерность. Поэтому в выборку попадает только подтверждённая версия профиля — с журналом, кто и когда её сверил. Когда источники отдают данные в стандарте HL7 FHIR, сопоставление упрощается, но проверка конфликтов остаётся обязательной.

Технические сомнения: разметка, приватность, ложные срабатывания

Сомнения на этом этапе обычно не про возможности модели, а про её поведение на живых данных: сколько ложных срабатываний доедет до координатора, что произойдёт с персональными данными пациента, кто отвечает за качество разметки. Отвечаем по каждому контуру отдельно.

Как решается вопрос персональных данных?

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

Кто отвечает за качество разметки и повторяемость результата?

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

Что происходит с моделью после передачи?

Передаём не только модель, но и воспроизводимый конвейер обучения, наборы проверок и регламент сопровождения: контроль дрейфа входных данных, плановое переобучение, разбор каждого отказа с пополнением регрессионного набора. Без этого метрика тихо деградирует, а откат к предыдущей версии становится невозможен.

Обсудим задачу и вернёмся с оценкой и планом работ

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

• Протокол исследования и критерии включения и исключения — по ним настраиваем отбор кандидатов и правила их приоритизации.
• Перечень источников: электронная история болезни, лабораторные системы, регистры пациентов, рекрутинговые базы — что реально доступно.
• Обезличенная выгрузка за период — проверим полноту полей, частоту пропусков и пригодность данных для обучения моделей.
• Требования к обработке персональных данных и размещению: локальный контур, изолированный сегмент, разграничение доступа.
• Ответственный клинический эксперт со стороны заказчика — он подтверждает разметку и оценивает качество отбора по спорным случаям.
• Целевые метрики: какую долю скринингов хотите отсеивать автоматически и насколько сократить время закрытия набора.
• Окно для пилотного запуска и ограничения по срокам — от этого зависит, что успеваем проверить до полного внедрения.

Опишите задачу в свободной форме — вернёмся с оценкой и планом работ: этапы пилотного запуска, сроки по каждому, состав команды и критерии приёмки. Уточняющие вопросы зададим до оценки, чтобы цифры в плане были рабочими, а не ориентировочными.

• Ждать «идеально чистых данных» и из-за этого не начинать: пилот запускают на одном потоке, где записи уже ведутся в электронном виде, а не на всём архиве сразу.
• Передавать критерии включения и исключения только текстом протокола, без перевода в машиночитаемые правила, — модель физически не может применить то, что не описано однозначно.
• Требовать от системы отбора точности выше, чем у самих исходных записей: если признак встречается лишь в свободных заметках врача, никакая модель не сделает его надёжнее.
• Путать предварительный отбор с решением о включении в исследование: система готовит короткий список для проверки, а вердикт остаётся за врачом-исследователем.
• Оценивать результат по единственному показателю — числу найденных пациентов — и не смотреть на долю ложных срабатываний, из-за чего доверие к списку падает после первых же проверок.
• Не назначать ответственного за разбор спорных карточек: очередь сомнительных случаев копится, а исследователи перестают открывать систему.
• Считать запуск финальной точкой и не закладывать сопровождение: критерии набора уточняются по ходу, а настройки отбора остаются прежними и постепенно расходятся с протоколом.
• Встраивать отбор поверх существующего порядка работы, дублируя уже заполняемые формы, — вместо того чтобы снять с координаторов ручной перенос данных между системами.