Розробка AI для медицини: де ламається ручний розбір знімків
Потік досліджень зростає швидше, ніж кількість фахівців, готових їх описувати. Лікар за зміну переглядає десятки серій, а кожна серія — це сотні зрізів у стандартному форматі DICOM: їх потрібно перегорнути, зіставити з попереднім сканом і вкласти висновок у протокол.
Пропускна здатність відділення впирається не в якість сканера, а в людино-години та стійкість уваги.
Тут і є вузьке місце діагностики. Наприкінці зміни час на одне дослідження зростає, а дрібні утворення на однорідному фоні переглядаються гірше — частка розбіжностей між двома незалежними описами у складних випадках вимірюється десятками відсотків.
Ручний розбір знімків погано масштабується: зрослий потік закривається новими посадами, а не переналаштуванням процесу.
Розробка AI для медицини закриває це як попередній прохід, а не як заміну лікаря. Модель розмічає підозрілі зони, рахує обсяги та розставляє пріоритет у черзі — дослідження зі знахідками йдуть угору, норма зміщується вниз.
Аналіз медичних зображень при цьому оцінюємо на відкладеній вибірці самого відділення: важливі чутливість на цільовому класі знахідок і частка хибних спрацювань, а не метрика на публічному наборі.
Далі розбираємо, як це закривається — від підготовки й розмітки даних до вбудовування в поточний процес опису.
Швидкість і повторюваність розбору досліджень
Ефект впровадження перевіряємо не одним числом, а набором метрик: час від надходження серії в потік до підписаного висновку, частка досліджень, що йдуть на повторний перегляд, розкид оцінок між фахівцями та клас пропущених знахідок.
Кожну метрику знімаємо на тому самому потоці до змін — інакше покращення нічим підтвердити, а різницю списують на природний розкид потоку.
Час до висновку вважаємо медіаною та 90-м процентилем, а не середнім: середнє приховує хвіст, коли складні випадки накопичуються до кінця зміни й переходять на наступний день.
Якщо за пікового навантаження зростає саме хвіст, а медіана тримається — вузьке місце в пріоритизації черги, а не в самому розборі, і лікується це порядком подання досліджень, а не дообученням.
Частка досліджень, що йдуть на повторний перегляд другим фахівцем, — індикатор того, наскільки попередній розбір звужує зону уваги.
Її зниження означає, що спірні випадки система позначає сама й лікар дивиться адресно, а не перевіряє все підряд; при цьому сама метрика не повинна падати до нуля — повна відсутність повторів говорить про те, що поріг упевненості виставлено занадто м'яко.
Розкид оцінок між фахівцями вимірюємо за ключовими класами знахідок: згода за ними важливіша за загальну точність, бо саме вона визначає, чи буде висновок однаковим у двох лікарів на тому самому знімку.
Клас пропущених знахідок розбираємо окремо — критичні неприпустимі й зобов'язані йти на підтвердження, пограничні допустимо віддавати на дорозмітку, а не виносити у висновок.
Окремо дивимося пропускну здатність контуру: скільки досліджень за годину він тримає без зростання часу очікування і що відбувається з метриками за подвоєння потоку.
Повторюваність вважається лише на стабільній ділянці — якщо черга плаває, будь-які цифри щодо якості розбору недостовірні.
Формати впровадження: хмарний контур, локальний, гібридний
Контур обирають за вимогами до даних пацієнтів: де дозволено зберігати дослідження, хто має до них доступ і чи допустимий вихід за межі захищеної мережі. Від цього залежать схема інтеграції з обліковою системою клініки та порядок оновлення моделей.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарна обробка досліджень | Немає заборони на зовнішню обробку, потрібен швидкий старт і еластичні ресурси під пікове навантаження | Кожне дослідження залишає контур клініки: потрібні знеособлення на вході та надійний канал передавання |
| Локальний контур обробки | Дані не повинні залишати захищену мережу — відомчі об'єкти, чутливі дослідження | Ресурси фіксовані: піки впираються в обладнання, оновлення моделей і моніторинг — на команді замовника |
| Гібридний контур | Передобробка й аналіз — поруч із даними, навчання та перенавчання моделей — поза контуром | Складніший супровід: узгоджені версії моделей з обох сторін і контроль того, що йде назовні |
Гібридний контур зазвичай стає компромісом за замовчуванням: знеособлення й розбір знімків відбуваються поруч із сховищем, а важкі обчислення виносяться туди, де ресурси нарощуються під задачу. Плата за це — дисципліна версій моделей і явний перелік полів, які дозволено передавати назовні.
Перехід між контурами закладаємо заздалегідь: вхідний формат досліджень і шар знеособлення залишаються незмінними, тому зміна розміщення не вимагає переписувати інтеграцію з клінікою. Далі розбираємо, що входить у роботу за кожним із варіантів.
Етапи: від аудиту архіву до передачі в експлуатацію
Порядок робіт тут не формальність: стелю якості моделі задають дані, а не архітектура, тому починаємо з аудиту архіву досліджень і лише потім обираємо схему. Інакше легко зібрати рішення з красивими метриками на своїй вибірці, яке заважає лікарю в потоці.
- Аудит архіву досліджень: обсяг за модальностями, частка розмічених серій, дублі та повтори, розбалансування класів, розбіжності у висновках різних лікарів щодо одного випадку.
- Схема рішення: де працює модель, які дані залишаються в контурі клініки, що надходить лікарю у відповіді й хто ухвалює фінальне рішення щодо випадку.
- Підготовка даних і навчання: приведення серій до єдиного вигляду, знеособлення, дорозмітка силами лікарів-експертів, налаштування класів знахідок під реальний профіль потоку.
- Перевірка на відкладеній вибірці: частину досліджень відкладаємо до початку навчання й не показуємо моделі — рахуємо частку пропусків і хибних спрацювань окремо за кожним класом.
- Налаштування порогу спрацювання: підбираємо так, щоб рідкісні знахідки не губилися, а однотипні дослідження не перевантажували лікаря зайвими позначками.
- Інтеграція: зв'язка зі сховищем досліджень і робочим списком лікаря, формат відповіді, поведінка за недоступності сервісу — черга й повторна обробка.
- Навчання персоналу та передача в експлуатацію: розбір спірних випадків із лікарями, регламент оновлення моделі, моніторинг частки розбіжностей із висновками й передача документації.
Після передачі залишається період супроводу: ми бачимо, як модель поводиться на нових дослідженнях, і дообучаємо її, коли змінюється обладнання або протоколи зйомки.
Комплект документації та артефактів після впровадження
Впровадження вважається завершеним не тоді, коли модель видає висновок на демо-знімку, а коли замовник може експлуатувати систему без нас: змінювати пороги, розбирати інциденти, підключати новий кабінет і пояснювати лікарю, чому рішення спрацювало саме так.
Тому ми віддаємо не «навчену модель», а комплект, де кожне рішення задокументовано й відтворюване. Нижче — що фізично залишається у вас на руках.
- Схема інтеграції — як систему вбудовано в контур клініки: які модулі з чим обмінюються, у якому форматі передаються знімки та висновки, що відбувається за недоступності архіву або черги досліджень.
- Політики доступу — ролі та області видимості (лікар, лаборант, адміністратор, сервісний інженер), правила знеособлення, а також журналювання кожного звернення до дослідження й вивантаження даних.
- Опис моделей — картка на кожну модель: на яких даних навчалася, які класи знахідок і типи зйомки покриває, де проходять межі застосовності та на якому наборі рахувався контроль якості.
- Регламент оновлення моделі — коли й за яким тригером запускається перенавчання, хто погоджує викатку, як перевіряють нову версію на відкладеному наборі та як відкотитися на попередню без зупинки відділення.
- Документація для лікарів — коротка інструкція щодо інтерфейсу, трактування впевненості моделі, порядку підтвердження або відхилення знахідки та дій за сумнівного результату.
- Конфігурації та пороги — винесені назовні параметри чутливості під профіль відділення, щоб правка не вимагала перезбирання й повторної валідації всього контуру.
- Експлуатаційний пакет — моніторинг, перелік спостережуваних сигналів, порядок розбору збою, контакти відповідальних і журнал змін з історією версій.
Комплект розрахований на те, що читати його буде ваш інженер і завідувач відділення, а не автор рішення. Опишіть задачу — повернемося з оцінкою та планом, включно зі складом документації під ваш контур.
Кейс: медичний потік досліджень до і після
Пілот запускали не на демонстраційній вибірці, а на живому потоці: близько 1 100 досліджень на добу з чотирьох апаратів. Усі вони потрапляли до загальної черги, і черговий фахівець вручну вирішував, що дивитися першим.
Термінові знахідки чекали на розбір до 40 хвилин, а 31% досліджень поверталися на доопрацювання через неповний опис.
Метрики до і після
| Показник | До пілоту | Після |
|---|---|---|
| Частка автоматичного сортування | 0% | 72% |
| Час до розбору термінового випадку | 40 хв | 9 хв |
| Повернення на доопрацювання | 31% | 12% |
| Навантаження на чергову зміну | повне | удвічі менше |
Сортування відбувається за передобробленими серіями у форматі DICOM: модель відокремлює дослідження без ознак патології, позначає підозрілі та піднімає їх на початок черги. Лікар отримує не загальну стрічку, а пріоритизований список, де першим стоїть те, що не можна відкласти.
Змінювали не лише модель: переписали правила маршрутизації, додали поріг упевненості та журнал рішень, щоб кожен автоматичний висновок можна було перевірити. Журнал і дозволив за перший тиждень розібрати хибні спрацювання та підняти частку автоматичного сортування з 58% до 72%. Контроль залишився за лікарем — система пропонує пріоритет, рішення ухвалює людина.
Чим відрізняється підтримка лікаря від повної автоматизації?
Режими розрізняються не точністю моделі, а тим, хто формує висновок і на кого лягає відповідальність за помилку. Між сортуванням досліджень і повною автоматизацією діагностики лежить різний клас ризику та різний обсяг доказів, які потрібно зібрати до впровадження.
У режимі сортування модель обробляє потік досліджень у форматі DICOM, оцінює ймовірність критичної знахідки та піднімає випадок у черзі. Лікар дивиться те саме зображення, просто раніше — помилка змінює порядок перегляду, але не діагноз.
Це найдешевший за погодженням режим, і він же дає основний ефект: час до перегляду критичних випадків скорочується в рази.
Підтримка лікарських рішень — це вже підказка: контури осередків, теплова карта уваги, ймовірність за класами. Лікар підтверджує або відхиляє, відповідальність за висновок залишається на ньому.
Тут критичні дві метрики — чутливість на цільовій патології та частка хибних спрацювань; поріг підбирається під конкретну клініку, інакше лікар перестає довіряти розмітці.
Повна автоматизація діагностики вимагає, щоб система видавала вердикт і відмовлялася від нього в непевних випадках, передаючи їх лікарю.
Відповідальність за висновок переходить на виробника, а сама система стає медичним виробом — з випробуваннями та обмеженням сфери застосування однією-двома нозологіями.
На практиці робоча схема майже завжди змішана: сортування на потоці, підказка у спірних випадках, автоматизація на вузькому класі.
Технічні сумніви та обмеження рішення
Якість рішення впирається не в архітектуру моделі, а в дані: розмітку, покриття рідкісних знахідок і поведінку на знімках, не схожих на навчальну вибірку. Ці ділянки закриваємо до розробки, а не за фактом провалу на прийманні.
Розмітка відбувається за одним правилом: кожне дослідження дивляться два незалежні лікарі, розбіжності йдуть третьому на арбітраж, у навчання потрапляє лише узгоджений результат.
Частка спірних випадків — контрольна метрика: там, де інструкція розмітки допускає різні трактування, вона уточнюється.
Рідкісні патології та нестандартні знімки не розчиняються в загальній масі. Класи з малою кількістю прикладів ідуть окремим контролем, а знімки з артефактами або іншою укладкою заздалегідь потрапляють у перевірочний набір — інакше модель упевнено помиляється саме на них.
Розмітку роблять різні лікарі — ми не тягнемо їхню суб'єктивність у модель?
Спірні випадки не «усереднюємо»: або консенсус двох фахівців, або виключення з позначкою про причину. Розбіжності розбираємо окремо — найчастіше вони вказують на нечіткий критерій в інструкції, і після її правки частка спірних досліджень падає.
Рідкісних патологій мало — модель їх просто не вивчить?
Для них окремий відбір прикладів і окрема перевірка повноти за кожним класом, а не одна загальна метрика за всіма знахідками.
Якщо прикладів фізично недостатньо, модель відносить випадок до тих, що потребують уваги лікаря: пропуск рідкісної патології ми вважаємо гіршим результатом, ніж зайве направлення на перегляд.
Замінили апарат або змінили укладку — усе переробляти заново?
Ні. Версію набору даних і моделі фіксуємо, тому відкат на попередню залишається доступним.
Спершу дивимося поведінку на нових знімках, і якщо якість знизилася — дообучення на невеликій партії, розміченій під нове обладнання, і повторна перевірка на попередніх тестах, щоб не втратити те, що вже працювало. Оновлення не випускаємо, поки воно не підтверджене на обох наборах.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка проєкту спиралася на факти, а не на усереднені припущення, на вході потрібен мінімум: яку задачу вирішує система, які дані вже є і в якому вигляді, які обмеження щодо інфраструктури та строків. Далі — дзвінок з інженером і профільним фахівцем: без презентацій, лише розбір задачі по суті.
На дзвінку уточнюємо:
- який результат вважається успішним і як його виміряти — частка правильних знахідок, час до висновку, кількість пропущених випадків;
- які типи знімків у роботі, чи є розмітка і хто з боку клініки її підтверджує;
- де зберігаються й обробляються дані, які вимоги до доступів, знеособлення та журналу дій;
- як зараз виглядає маршрут знімка від апарата до висновку і на якому кроці втрачається час;
- який рівень якості обов'язковий для допуску системи до роботи поруч із лікарем;
- які системи доведеться зв'язати: сховище досліджень, робочі місця, звітність;
- хто приймає результат поетапно і в які строки потрібен перший робочий контур.
За підсумком розбору надсилаємо оцінку проєкту: склад етапів, план впровадження з контрольними точками, вимоги до даних і до команди замовника, список ризиків і спосіб відкату на ручний режим.
Після погодження фіксуємо перший етап — старт робіт починається з перевірки даних і базової моделі, яку докручуємо на ваших прикладах.
