Від реактивного підрахунку до ранньої прогнозування
Класичне громадське здоров’я відстежує те, що вже сталося: підтверджені випадки, госпіталізації, свідоцтва про смерть. До того часу, коли ці цифри змінюються, спалах уже розпочався. Системи машинного навчання замість цього шукають слабкі сигнали, які передують офіційному підрахунку – пошукові запити щодо симптомів, публікації в соціальних мережах про хвороби, продажі безрецептурних ліків у аптеках та поточні дані про госпіталізації.
Система прогнозування грипу CDC поєднує саме ці потоки даних. Корелюючи тенденції пошукових запитів та дані про продажі ліків з історичними патернами спалахів, вона може виявити ймовірний стрибок на 6-8 тижнів до піку, на відміну від багатотижневого заґудкування традиційних систем звітування про випадки. Це часове відставання дозволяє органам охорони здоров’я попередньо розміщувати запаси вакцин та персонал замість реагування після того, як лікарні переповнюються.
Алгоритми, що працюють
Для більшості цього не потрібне нічого екзотичного. Чотири родини алгоритмів охоплюють основну частину розгорнутих публічних охорони ML: моделі регресії прогнозують безперервне число – рівень захворюваності, очікувана тривалість перебування в лікарні. Алгоритми класифікації (логістична регресія, машини опорних векторів) розподіляють пацієнтів на групи за ризиком – високий, середній, низький, для діабету або ускладнень від раку. Алгоритми кластеризації, K-means як стандарт, групують пацієнтів або географічні зони за спільними характеристиками без попередньо визначених міток, що корисно для виявлення «гарячої точки», яку ніхто не відмічав. Моделі часових рядів прогнозують вперед з історичних послідовностей, що є основою прогнозування спалахів.
Якість кожної моделі залежить лише від її ознак – модель CDC щодо грипу працює завдяки тому, що хтось вирішив прогодувати її пошуковими запитами та продажами ліків, а не завдяки інноваційному регресійному алгоритму. Вибір ознак, а не складність алгоритму, зазвичай є визначальним фактором того, чи працює публічна модель охорони здоров’я.
Приклади розгортання з зазначенням чисел
Три приклади демонструють цей шаблон, який часто використовується при заявлених виграшах для цих систем: система CDC щодо інфлюенци, описана вище, отримує кредит за 15% скорочення госпіталізацій під час пікового сезону грипу завдяки наданню офіціям тижнів попереднього часу для проведення кампаній вакцинації.
Місцеві органи охорони здоров’я застосовують подібний логічний підхід до випадків передозування опіоїдами: замість очікування повідомлень про місця передозувань – які відстають від реального поширення епідемії – моделі, навчені на даних про рецепти, реєстрах випадків передозувань та демографічних показниках, виявляють нові зони ризику у міру їх формування. Звітний результат: збільшення на 20% доступу до лікування залежностей у цільових районах.
HUD запустила паралельну модель для оцінки ризику бездомності, оцінюючи осіб за рівнем безробіття, історією виселень та тенденціями доходів, щоб виявляти ризик ще до втрати житла. Пілотні програми, що використовували цей підхід, повідомили про 10% скорочення кількості бездомних у цільовій популяції.
Що потрібно моделі для переходу від пілотування до виробництва
Стандартний процес полягає у визначенні конкретної, вузькоспеціалізованої задачі – не "покращити охорону здоров’я", а "прогнозувати госпіталізацію з грипом за два тижні до» – в описі доступних джерел даних, їх очищенні та попередній обробці, навчанні та валідації на відметьованому тестовому наборі, а потім інтеграції результату у реальний робочий процес замість дашборду, який ніхто не перевіряє. Пропуск останнього кроку – найпоширеніший спосіб, коли технічно грамотна модель не має жодного реального впливу.
Якість даних є постійним джерелом помилок – неповні або невідповідні записи погіршують прогнози швидше, ніж недоліки в алгоритмі. Упередження – друга постійна проблема: модель, навчена на історично нерівномірному доступі до медичної допомоги, відтворюватиме цю нерівність у своїх оцінках ризику, якщо тільки хтось явно не перевірить це. Важлива також інтерпретованість – лікар або представник влади, який не може зрозуміти, чому модель виявила певний випадок, не діятиме на її рекомендацію, незалежно від точності.
Куди це веде
Федеративне навчання дозволяє моделі навчатися на даних кількох лікарень без переміщення жодних оригінальних медичних записів за межі об’єктів, що усуває багато заперечень щодо конфіденційності, які гальмують угоди про обмін даними. Генерація синтетичних даних створює реалістичні, але штучні медичні записи для навчання, коли реальні дані рідкісні або надто чутливі для безпосереднього використання. Обчислення на краю (edge computing) переносить навчену модель безпосередньо на пристрій – датчик на одязі, який оцінює ризик пацієнта локально, а не відправляє дані на сервер спочатку, що важливо для будь-чого, що потребує миттєвої реакції.
Жоден з цих методів поки що не є стандартним; більшість поточних систем у сфері охорони здоров’я працюють на основі чотирьох вищезазначених алгоритмічних родин, застосованих до даних, зібраних централізовано. Перехід інфраструктури до підходів федеративного та edge computing розпочався, але поки що не є базовим сценарієм.
Система прогнозування грипу CDC на основі машинного навчання може виявити ймовірний спалах за 6-8 тижнів до піку, використовуючи дані про пошукові запити, продажі в аптеках та госпіталізацію у лікарнях.
Часті запитання
Які саме дані живлять ці моделі прогнозування?
Електронні медичні записи, інформаційні потоки щодо захворювань, дані про рецепти та продажі в аптеках, показники датчиків навколишнього середовища та агреговані сигнали, такі як пошукові запити в Google або публікації у соціальних мережах про симптоми. Модель CDC щодо грипу, наприклад, поєднує тенденції пошуку, продажі ліків та госпіталізацію.
Які саме алгоритми використовуються, а не лише запропоновані?
Логістична регресія та машини опорного вектора для класифікації ризиків, кластеризація K-means для групування схожих пацієнтів або місць розташування, регресійні моделі для прогнозування частоти захворювань та часові ряди для прогнозування спалахів. Глибоке навчання використовується рідше в реальних умовах, ніж просуває його маркетинг.
Як довго потрібно, щоб побачити результати від пілотного проєкту?
Узгоджений за обсягом пілотний проєкт, наприклад, прогнозування спалаху грипу, може дати вимірювані покращення в прогнозуванні протягом 3-6 місяців. Більші розгортання, такі як оптимізація ресурсів у системі лікарень, зазвичай потребують 12-24 місяців ітеративного розвитку та валідації моделі перед повною інтеграцією.
Яка найбільша причина невдач цих проєктів?
Якість даних та інтеграція робочих процесів, а не вибір алгоритму. Технічно точна модель, яка передає дані до дашборду, який ніхто не перевіряє, або навчена на неповних записах, не має реального впливу, незалежно від її складності.
Спробуйте наживо
Усе, що вище, працює прямо у вашому браузері — відкрийте the simulation і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.
▶ Відкрити симуляцію the simulation