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