Чому ШІ в клінічних випробуваннях буксує на відборі пацієнтів
Критеріїв включення та виключення — десятки, і живуть вони не в одному місці. Частина задана структурно: коди діагнозів, лабораторні показники, вік, стадія захворювання.
Частина — лише в текстових описах протоколу, де формулювання на кшталт «відсутність клінічно значущої супутньої патології» вимагає прочитати історію хвороби повністю.
Самі дані при цьому розкидані між лабораторною системою, медичними картками, реєстрами госпіталізацій і скринінговими оглядами.
Далі починається найдорожче. Попередній відбір відбувається вручну: один центр — це десятки годин перегляду карт, а результат залежить від того, хто саме дивиться.
Два координатори на одному й тому самому наборі даних видають різні списки, а повторити відбір через місяць за тими самими критеріями не вдається — змінюються люди, вивантаження та правила читання.
Частина пацієнтів губиться не тому, що не підходить, а тому що відповідний випадок просто не потрапив у поле зору.
Прихована ціна — не лише години. Поки відбір не відтворюється, не можна довести, що критерії застосовували однаково до всіх: питання аудиту вимагає заново перечитати первинні документи, а розбіжність списків ставить під сумнів якість даних усього дослідження. Втрата пацієнтів розтягує набір і зсуває терміни за всім протоколом.
Розбираємо, як закривається це вузьке місце: як перевести текстові критерії в перевірювані запити до даних, звести розрізнені джерела в один шар і зробити відбір повторюваним.
Ефект від впровадження: швидкість набору та повнота даних
Ефект рахуємо за метриками до і після на одному й тому самому потоці пацієнтів: скільки часу йшло на попередній відбір, яка частка запрошених проходила критерії включення, скільки ручних звірок робив координатор на учасника.
Так видно, що змінилося від моделі, а не від сезонності — і де швидкість набору впиралася в ручний етап.
Скорочення часу попереднього відбору
Модель переглядає електронні історії та ранжує кандидатів за критеріями включення і виключення, координатор отримує короткий список з обґрунтуванням за кожним пунктом.
Попередній відбір скорочується з днів до годин, а частка знайдених відповідних пацієнтів зростає: правила перевіряються на всьому масиві, а не на тих, хто випадково потрапив у поле зору.
Окремо видно ефект щодо відсіювання: пацієнт, який відпав на перевірці критеріїв, більше не витрачає слот візиту. Зникають два класи помилок — пропущений відповідний пацієнт і запрошений невідповідний.
Єдиний профіль пацієнта замість ручних звірок
Дані історії хвороби, лабораторії та щоденників зводяться в один профіль за стандартом CDISC — із зазначенням джерела та часу для кожного поля. Кількість ручних звірок падає: розбіжності між системами ловить правило, а не людина.
Повнота профілю стає вимірюваною — частка заповнених обов’язкових полів видна на панелі контролю, прогалини закриваються до візиту.
Відтворюваність тримається на зафіксованих правилах відбору та контролю якості даних із журналом версій: повторний прогін на тому самому масиві дає той самий список кандидатів, а кожне рішення пояснюване для перевіряльника.
Порівняння підходів: правила, модель, гібрид
Правила, модель та їх комбінація розв’язують одну задачу — чи підходить пацієнт під протокол, — але помиляються по-різному. Правила дають відтворювану відповідь і зрозумілу причину, модель ловить неочевидні поєднання ознак, але потребує даних і пояснення рішення.
Вибір залежить від зрілості даних і того, наскільки формалізований протокол. Нижче — варіанти, між якими реально обирають.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Жорсткі правила відбору | Критерії протоколу однозначні, потрібна відтворюваність | Не бачать поєднань ознак, відсікають пограничних пацієнтів |
| Модель машинного навчання | Багато історичних даних, критеріїв багато і вони перетинаються | Залежить від розмітки, рішення потрібно пояснювати регулятору |
| Гібрид: правила плюс модель | Правила задають рамку, модель ранжує всередині неї | Потрібно синхронізувати правила і версії моделі |
| Ручна перевірка фахівцем | Спірні випадки та аудит якості відбору | Не масштабується, залежить від завантаження лікаря |
Де правила надійніші за модель
Коли критерії включення і виключення записані однозначно, правила виграють: результат не змінюється між запусками, а відхилення пацієнта пояснюється пунктом протоколу. Аудиту показують умови та пороги, а не ваги моделі.
Де модель обходить правила
Якщо критеріїв десятки і вони перетинаються, правила конфліктують між собою, а пороги відсікають пацієнтів, яких протокол допускає. Модель ранжує потік за ймовірністю відповідності — пограничні випадки йдуть на ручну перевірку фахівцем.
Як будується впровадження ШІ-моделі в потік пацієнтів
Впровадження моделі в потік пацієнтів — це не встановлення готового продукту, а послідовність інженерних робіт, де кожен крок спирається на результат попереднього.
Порядок принциповий: якщо пропустити аудит критеріїв відбору, модель навчиться на зміщеній вибірці, і помилку доведеться шукати вже в працюючому процесі набору.
Аудит даних і критеріїв
-
Розбираємо джерела: де лежать дані про пацієнтів, як кодуються діагнози та результати аналізів, які критерії включення застосовуються на практиці і де вони розходяться з протоколом.
-
Узгоджуємо схему даних: які поля модель отримує на вхід, з якою періодичністю, хто відповідає за повноту і як обробляються пропуски та застарілі записи.
-
Готуємо розмітку й навчаємо модель на рішеннях дослідників, перевіряючи, які ознаки вона використовує — це контроль здорового глузду, а не лише цифри якості.
-
Збираємо схему інтеграції з робочими системами: вивантаження або програмний інтерфейс, журналювання звернень, розмежування доступу за ролями.
Перевірка на історичних даних
-
Проганяємо модель за закритими дослідженнями: скільки відповідних пацієнтів вона знайшла, скільки пропустила і яку частку становили хибні спрацювання.
-
Фіксуємо регламент супроводу: коли перенавчаємо при зміні протоколу, за яких порогів модель зупиняється і передає рішення досліднику.
-
Передаємо команді замовника документацію, навчання фахівців і порядок дій при збоях.
Артефакти проєкту: правила доступу, схеми даних, регламенти
Проєкт із підбору пацієнтів закінчується не презентацією, а набором робочих документів, за якими дослідницька команда продовжує роботу без нас.
Усе, що описує логіку відбору, доступ до даних і порядок супроводу моделі, передається як актуальні конфігурації та регламенти — їх можна перечитати, змінити й передати іншому виконавцю.
Правила доступу та розмежування ролей
- Схема даних: сутності досліджень, візитів, критеріїв включення та лабораторних показників, їхні зв’язки та правила знеособлення перед поданням у модель.
- Матриця ролей: хто з дослідників, координаторів і фахівців з даних бачить персональні дані, а хто — лише знеособлені вивантаження.
- Порядок видачі та відкликання доступів, включно з діями при виході співробітника з команди.
- Журналювання звернень до даних: фіксується, хто і коли вивантажував вибірку та змінював правила відбору.
Регламент супроводу та оновлення
- Правила відбору з історією правок: видно, яка зміна дала який результат на перевірочній вибірці.
- Порядок перевірки моделі на нових даних і пороги, за яких вона йде на перезбирання.
- Інструкції для дослідницької команди: як готувати вивантаження, як читати звіт щодо кандидатів, куди повідомляти про розбіжності.
- План оновлення при зміні протоколу дослідження — що перезбирається, а що переналаштовується.
Кейс: скоротили відсів пацієнтів на попередньому відборі
Працювали з мережею дослідницьких центрів: кілька активних протоколів одночасно, сотні карт кандидатів на тиждень. Підбір вів координатор, і основна маса часу та кандидатів губилася саме на попередньому відборі.
Початкова схема відбору
Критерії включення і виключення виписувалися в таблицю, потім вручну звірялися з картами — структуровані поля, призначення, текстові висновки.
На один протокол ішли години, до скринінгу доходила приблизно третина початкової вибірки, а частина відповідних пацієнтів відсіювалася ще до контакту з лікарем.
Окремо били хибні спрацювання — кандидати, які пройшли фільтр формально, але не підходили за клінічними деталями. Їхня повторна перевірка з’їдала до чверті часу лікаря.
Результат після впровадження
Критерії протоколу ми описали в машинозчитуваному вигляді та зібрали конвеєр: вилучення ознак із полів і тексту, зіставлення з критеріями, ранжування кандидатів. Обмеження за лабораторними порогами, датами та супутньою терапією перевіряються до того, як карта потрапить до людини.
Реєстри на кшталт ClinicalTrials.gov розбираються в той самий набір правил, тому новий набір запускається без ручного переверстування.
Час попереднього відбору за одним протоколом скоротився з годин до десятків хвилин, частка тих, хто дійшов до скринінгу, зросла більш ніж удвічі, ручних звірок на кандидата стало в рази менше. Частка хибних спрацювань упала з чверті до одиниць відсотків.
Кожне рішення пояснюване: видно, який критерій спрацював, тому координатор перевіряє не всю карту, а спірний фрагмент. Це закриває головний ризик — мовчазний пропуск відповідного пацієнта.
Що робити, якщо дані пацієнтів лежать у різних системах?
Однакових систем у клінічному центрі майже не буває: лабораторія віддає результати своїми вивантаженнями, реєстратура веде розклад окремо, аптека та карта пацієнта живуть у своїх контурах.
Зшивати це вручну за прізвищем — втрачати години на кожного кандидата і все одно не мати відтворюваної картини. Інтеграція із системами починається не з файлів, а з реєстру ключів: які ідентифікатори є в кожному джерелі, який із них стабільний і що робити, коли поле порожнє.
Єдиний профіль пацієнта збирається у два проходи. Спочатку жорстке зіставлення за національним ідентифікатором і номером протоколу, потім імовірнісне — за датою народження, статтю, збігом початку ПІБ і контактом.
Поріг налаштовується: нижче нього запис іде в карантин із позначкою, а не розчиняється в моделі як «майже збіг».
Далі — обов’язкові звірки. Дата візиту звіряється з датою забору, значення — з одиницями вимірювання джерела, супутня терапія — з вікном скринінгу.
Розбіжність за критерієм включення або за лабораторним показником критична: такі записи не усереднюються і не «береться найсвіжіше» — конфлікт фіксується й іде на ручну валідацію.
Розмітка даних спирається на той самий профіль: розмітник бачить повну хронологію, а кожна мітка несе посилання на джерело та версію запису. Якщо розбіжність усе-таки просочилася в навчання, модель відтворює її як закономірність.
Тому у вибірку потрапляє лише підтверджена версія профілю — з журналом, хто і коли її звірив. Коли джерела віддають дані в стандарті HL7 FHIR, зіставлення спрощується, але перевірка конфліктів залишається обов’язковою.
Технічні сумніви: розмітка, приватність, хибні спрацювання
Сумніви на цьому етапі зазвичай не про можливості моделі, а про її поведінку на живих даних: скільки хибних спрацювань доїде до координатора, що станеться з персональними даними пацієнта, хто відповідає за якість розмітки. Відповідаємо за кожним контуром окремо.
Наскільки точним виходить відбір і що з хибними спрацюваннями?
Модель працює фільтром першої лінії: поріг відсікання налаштовуємо так, щоб жоден відповідний пацієнт не випав із воронки — ціна пропуску вища за ціну зайвої картки, а її все одно закриває координатор.
Точність і повнота відбору знімаються на відкладеній вибірці й рахуються за кожним центром окремо: середня цифра за всім дослідженням приховує провал на маленькій підвибірці.
Як вирішується питання персональних даних?
Прямі ідентифікатори не залишають контур замовника: у модель ідуть знеособлені записи, а зіставлення з історією хвороби виконується на боці клініки.
Доступи розмежовані за ролями, звернення до даних пишуться в незмінюваний журнал, терміни зберігання та правила видалення зафіксовані в політиці, а не в усних домовленостях.
Хто відповідає за якість розмітки та повторюваність результату?
Розмітка йде за єдиною інструкцією з подвійною перевіркою спірних випадків і розрахунком згоди між анотаторами: розбіжність — привід переписати правило, а не «дотягнути» його голосуванням.
Склад навчального та перевірочного наборів фіксується, тому результат відтворюваний: та сама конфігурація на тих самих даних дає ту саму метрику, а не «приблизно схожу».
Що відбувається з моделлю після передачі?
Передаємо не лише модель, а й відтворюваний конвеєр навчання, набори перевірок і регламент супроводу: контроль дрейфу вхідних даних, планове перенавчання, розбір кожної відмови з поповненням регресійного набору. Без цього метрика тихо деградує, а відкат до попередньої версії стає неможливим.
Обговоримо задачу та повернемося з оцінкою й планом робіт
Щоб пілотний запуск спирався на реальні дані, а не на припущення, зберімо вихідні за вашою задачею заздалегідь. Нижче — що потрібно від вас для старту: без цих пунктів оцінка проєкту перетворюється на вилку «від і до», а терміни зсуваються вже на першому етапі.
- Протокол дослідження та критерії включення і виключення — за ними налаштовуємо відбір кандидатів і правила їхньої пріоритизації.
- Перелік джерел: електронна історія хвороби, лабораторні системи, реєстри пацієнтів, рекрутингові бази — що реально доступно.
- Знеособлене вивантаження за період — перевіримо повноту полів, частоту пропусків і придатність даних для навчання моделей.
- Вимоги до обробки персональних даних і розміщення: локальний контур, ізольований сегмент, розмежування доступу.
- Відповідальний клінічний експерт з боку замовника — він підтверджує розмітку та оцінює якість відбору за спірними випадками.
- Цільові метрики: яку частку скринінгів хочете відсіювати автоматично і наскільки скоротити час закриття набору.
- Вікно для пілотного запуску та обмеження за термінами — від цього залежить, що встигаємо перевірити до повного впровадження.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом робіт: етапи пілотного запуску, терміни за кожним, склад команди та критерії приймання. Уточнювальні питання поставимо до оцінки, щоб цифри в плані були робочими, а не орієнтовними.
