Прогнозування завантаження стаціонару: де ламається поточний розрахунок
План госпіталізацій найчастіше будується на середніх значеннях за минулі періоди: беруть зайнятість ліжкового фонду за місяць або квартал і переносять на наступний інтервал. Такий розрахунок тримається, поки потік однорідний.
Щойно структура надходжень змінюється — зсуваються планові госпіталізації, йде хвиля екстрених — середнє перестає описувати реальність, і розходження плану та факту зростає.
Друга точка відмови — запізнення вивантажень. Дані надходять з різних підсистем з різною періодичністю: приймальне відділення фіксує надходження в момент оформлення, а рух по ліжках і виписки потрапляють у звітність пізніше, іноді раз на добу.
Розрахунок, побудований на такому зрізі, бачить учорашню картину і не реагує на сьогоднішній сплеск.
Сезонність надходжень зазвичай не враховується взагалі. Респіраторні хвилі, відпускний спад планової госпіталізації, святкові періоди дають повторюваний профіль за тижнями та місяцями, але всередині середнього за період він розмивається.
Окрема проблема — планові потоки: заздалегідь відомі обсяги операцій і госпіталізацій не подаються на вхід як окремий сигнал, хоча саме вони визначають, скільки ліжок залишиться під екстрений прийом.
У сумі виходить прогноз, який розходиться з фактом тим сильніше, чим вище навантаження — тобто рівно тоді, коли рішення про перерозподіл ліжок критичне.
Розбираємо, як це закривається: звідки беруться дані, що йде на вхід розрахунку і як будується прогнозування завантаження стаціонару, якому можна довіряти у зміну пікового навантаження.
Регулярне прогнозування потоку пацієнтів: вимірюваний ефект
Регулярний розрахунок змінює саму логіку роботи: прогноз за кожним відділенням перераховується nightly, а при надходженні нових даних — позапланово, тому рішення ухвалюються не за фактом заповненості ліжок, а за кілька днів до піку.
Дані підтягуються з облікової системи за галузевим стандартом обміну HL7 FHIR, без ручних вивантажень і «узгоджень у месенджері».
- Відмови в плановій госпіталізації. Прогноз на 7–14 днів уперед показує перевантаження заздалегідь — дату госпіталізації переносять до приїзду пацієнта, а не в день оформлення. З потоку йде найдорожчий клас відмов: ті, що б'ють по репутації і вимагають повторного запису.
- Завантаження відділень. Видно перекіс між відділеннями за 3–5 днів до піку, з'являється час на переведення профільних пацієнтів і перерозподіл ліжкового фонду. Розкид завантаження між відділеннями скорочується, авральні «чергування на межі» стають винятком.
- Перерозподіл змін. Прогноз потоку за днями тижня та годинами приймального відділення дає підставу ставити підсилення під конкретний інтервал, а не тримати повний склад «про всяк випадок». Зміни плануються під очікуване навантаження, переробки переходять у керований режим.
- Горизонт планування. Три ритми: доба — оперативне реагування, тиждень — зміни, місяць — витратні матеріали, ліки та планові обсяги. Кожен горизонт закривається своїм зрізом прогнозу, а не однією загальною цифрою.
- Клас відмов. Окремо рахуємо, скільки відмов вдалося перетворити на планове перенесення. Це і є вимірюваний ефект: зсув із некерованого класу в керований, а не просто «стало спокійніше».
Ефект тримається лише за контролю точності: рахуємо відхилення факту від прогнозу за кожним відділенням, при стійкому виході за поріг модель перенавчається на свіжих даних. Разовий прогноз нічого не вирішує — працює регулярний цикл зі зворотним зв'язком.
Підходи до моделі розрахунку: правила, статистика, навчання на даних
Модель розрахунку — це не лише алгоритм, а й те, які дані до нього потрапляють, з яким горизонтом він оновлюється і як перевіряється.
Ми тримаємо кілька взаємозамінних варіантів одного рівня і вибираємо під задачу: десь достатньо правил і сезонних коефіцієнтів, десь потрібна статистична модель, а десь — навчання на даних з перевіркою на ретроспективних зрізах.
Критерій один: варіант має обігравати просте правило на вашій історії, а не на демонстраційних даних. Якщо виграшу немає — у розрахунок іде правило, воно прозоріше.
Варіанти та їхні межі застосовності
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Жорсткі правила | Стійкі потоки з передбачуваним маршрутом пацієнта, потрібна пояснюваність кожної цифри | Не реагують на сплески та зміну профілю відділень, правляться вручну |
| Сезонні коефіцієнти | Підйоми і спади повторюються рік у рік: планова госпіталізація, епідсезон, відпустки | Дають систематичну похибку на тижневому горизонті |
| Статистична модель | Потрібен прогноз на кілька тижнів і оцінка розкиду при короткій історії | Чутлива до викидів, слабко ловить зміну поведінки потоку |
| Навчання на даних | Є кілька років зрізів за відділеннями, днями тижня та каналами надходження | Потребує регулярної переперевірки, інакше розходження з реальністю зростає |
| Ансамбль моделей | Одиночна модель помиляється по-різному в різних відділеннях | Складніший у супроводі: версіонування і контроль кожної складової |
На практиці частіше працює гібрид: правила задають рамки та відсікають неможливі значення, навчання на даних уточнює прогноз усередині цих рамок, а сезонні коефіцієнти згладжують відомі піки.
Етапи впровадження: від аудиту даних до передачі моделі
Порядок етапів не випадковий: поки не перевірено повноту вивантажень, будь-яка метрика якості прогнозу нічого не означає. Роботу ведемо за галузевим стандартом організації проєктів CRISP-DM — з фіксованими критеріями готовності на кожному кроці.
- Аудит джерел. Розбираємо вивантаження приймального відділення, планової госпіталізації та ліжкового фонду: розриви, дублікати, зміна правил обліку. На виході — карта даних і перелік місць, де без припущень не обійтися.
- Схема ознак. Із сирих подій збираємо те, що реально пояснює завантаження: день тижня і сезонність, профіль відділення, частка екстрених надходжень, листи очікування, епідемічні хвилі.
- Налаштування розрахунку. Фіксуємо горизонт — доба, три доби, тиждень — і визначення переповнення. Модель віддає не одне число, а інтервал і поріг, за якого спрацьовує попередження.
- Перевірка на історичних періодах. Проганяємо розрахунок за минулими відрізками, включно зі святами та сплесками захворюваності. Дивимося відхилення за зайнятістю ліжок і частку влучань в інтервал.
- Приймання моделі. Критерії узгоджуємо заздалегідь: точність на контрольних періодах, стійкість до викидів, зрозуміла причина відмови від прогнозу. Попередня версія лишається для відкату.
- Передача рішення. Розгортаємо розрахунок на вашому боці, віддаємо документацію та регламент перенавчання, розбираємо код із вашою командою. Далі модель супроводжують ваші інженери.
Схеми даних, регламент перенавчання, контроль якості
Прогноз завантаження живе не всередині моделі, а в документах, які залишаються в команди стаціонару. За пів року змінюється маршрутизація пацієнтів або приходить новий аналітик — систему можна підняти, перевірити й перенавчити лише за цим комплектом. Тому передаємо не «чорну скриньку», а набір артефактів.
- Схема даних: джерела (приймальне відділення, плановий запис, історія госпіталізацій, переведення між відділеннями), частота вивантаження, типові затримки надходження і відповідальний за кожен потік.
- Опис ознак: що подається на вхід — профіль і потужність відділення, день тижня й сезонність, вікова група, середня тривалість перебування, обсяг планових надходжень; для кожної ознаки вказано джерело, тип і поведінку при пропуску.
- Правила підготовки: як обробляються скасування, повторні госпіталізації та неповні зрізи, щоб прогноз не розходився на стиках змін і в святкові періоди.
- Регламент перенавчання: тригери (зміна потоку пацієнтів, новий профіль відділення, планова періодичність), довжина контрольного періоду, хто запускає і хто підтверджує результат.
- Контроль якості прогнозу: показники за кожним відділенням і горизонтом, пороги придатності та оповіщення, коли похибка виходить за них.
- Порядок розбору розходжень: звірка факту з прогнозом за інтервалами, класифікація причин (зміна маршрутизації, карантин, спалах захворюваності), виведення в журнал.
- Журнал версій і відкат: яка версія працювала в який період і на яких даних навчалася, як повернутися до попередньої, не втрачаючи накопичену історію.
Кейс: розходження плану та факту скоротилося втричі
Багатопрофільний стаціонар із потоком планових і екстрених госпіталізацій планував завантаження за середніми за минулий період: відділення зводили цифри вручну раз на тиждень.
На горизонті семи днів похибка сягала чверті ліжок — частина ліжок простоювала, частину змін закривали понаднормово, планові госпіталізації переносили в день надходження.
Контур планування перебудували: модель отримує історію госпіталізацій і операцій за кілька років, календар планових втручань, сезонність ГРВІ, дні тижня та свята, свіжі екстрені надходження.
Прогноз рахуємо за кожним відділенням на 1, 7 і 14 днів уперед; ядро — ансамбль дерев Градієнтний бустинг з довірчими інтервалами, тому планувальник бачить не одну цифру, а діапазон і ймовірність виходу за нього. Перерахунок іде щодоби і позапланово, коли факт відхиляється від прогнозу.
Через три місяці експлуатації похибка прогнозу завантаження ліжок на тижневому горизонті скоротилася з 23% до 7%, розходження плану та факту — втричі.
Частка незапланованих простоїв ліжок упала приблизно вдвічі, відмови в плановій госпіталізації через відсутність місця майже зникли зі звітності. Зміни медперсоналу ставлять під прогноз, а не під факт: переробки скоротилися на чверть.
Рішення залишається за людиною: модель показує, де ризик виходу за діапазон, завідувач відділення коригує план, система перераховує прогноз з урахуванням правки.
Що робити, якщо дані збираються вручну і із затримкою?
Прогноз можна будувати й на запізнілих даних — питання не в повноті, а в передбачуваності затримки. Якщо вивантаження приходить щоранку в той самий час, модель навчають на зрізі «дані на момент прогнозу» і не підмішують майбутнє.
Якщо затримка гуляє від години до двох діб, якість падає непомітно: поля виглядають свіжими, а фактично застаріли.
Ручні вивантаження з облікової системи закривають перший випадок: джерела даних збираються в одному місці, обсяг невеликий, склад полів стабільний. Їх беруть, коли звіт за ліжками, надходженнями та переведеннями йде за розкладом. Обмеження передбачувані — пропущені дні, дублі та розходження довідників відділень.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручні вивантаження за розкладом | Невеликий обсяг, стабільні поля, один відповідальний за звіт | Затримка плаває, пропуски днів, дублі та розходження довідників |
| Обмін з обліковою системою за розкладом | Потрібна затримка в межах години, є доступ і стабільні ідентифікатори | Узгодження, доопрацювання на боці системи, роз'їзд довідників |
| Потокова передача подій | Критична свіжість: прогноз на поточну зміну | Жорсткі вимоги до якості даних, трудомістка підтримка |
Неповні дані закриваємо ознаками, а не здогадками: у модель ідуть давність останнього запису, частка порожніх полів і мітка джерела. Прогноз тоді віддає інтервал і чесно розширює його в дні, коли дані прийшли пізніше звичайного, замість того щоб мовчки помилитися.
Автоматичний обмін підключають другим етапом — коли ручний контур дає зрозумілу схему даних і видно, які поля впливають на прогноз.
Технічні питання перед стартом проєкту
Перед стартом зазвичай перевіряють три речі: чи вистачить накопичених даних, як система поведеться при масовому надходженні і хто відповідає за якість прогнозу після передачі. Розбираємо кожен пункт предметно, без обіцянок «в середньому по лікарні».
Стартуємо з пілота на одному відділенні: модель навчається на його історії, прогноз щодня звіряється з фактом — і лише після стійкого розходження в допустимих межах рішення розходиться на решту корпусів. Пілот дає вимірювану базу: точність на конкретному відділенні замість обіцянки точності взагалі.
У нас кілька місяців історії — прогноз буде працювати?
Коротка історія обмежує не модель, а набір ознак. Спираємося на повторюване: день тижня, свята та канікули, сезонність госпіталізацій, планові направлення, профілі ліжок.
При низці в 3–4 місяці точність прогнозу на 1–3 доби вперед укладається в робочу вилку, а в міру накопичення даних вікно розширюємо.
Що буде при масовому надходженні?
Сплеск модель не передбачить — він приходить ззовні: аварія, спалах, масовий заїзд. Тому закладаємо ручне введення подій і поріг розходження: якщо факт пішов від прогнозу далі заданого, черговий отримує оповіщення і бачить, які відділення під загрозою. Правка вводиться однією дією і враховується в наступних розрахунках.
Хто відповідає за якість прогнозу після передачі?
Без контролю точність падає: змінюються профілі, потоки, порядок госпіталізації. Фіксуємо метрику якості, передаємо регламент перенавчання і панель розходжень, вчимо вашу команду запускати цикл самостійно. Перші оновлення проходимо разом — так лишається зрозуміла процедура замість «чорної скриньки».
Обговоримо задачу і повернемося з оцінкою та планом
Для старту нам не потрібен доступ до всього інформаційного середовища клініки — достатньо первинного складу даних і розуміння, які рішення спиратимуться на прогноз. Цього вистачає, щоб повернутися з оцінкою робіт і планом впровадження, а не із загальними слайдами.
- Первинний склад даних: історія госпіталізацій і переведень між відділеннями, тривалість перебування, відмови в прийомі, сезонні сплески — за кілька повних циклів разом з епідсезоном.
- Точки інтеграції: звідки дані забираються зараз — модуль медстатистики, приймальне відділення, операційний блок — і в якому вигляді доступні вивантаження: файл, представлення в базі або сервіс із запитами.
- Горизонт планування і рішення під нього: розстановка змін, резерв ліжок або план планової госпіталізації. Прогноз на добу і на два тижні — різні моделі та різна частота перерахунку.
- Зовнішній контекст потоку: календар планових операцій, свята та канікули, графік відпусток лікарів, обмеження за профілями ліжок.
- Правила ухвалення рішення: які пороги вважаються критичними, хто і як часто дивиться прогноз, що відбувається при перевищенні.
- Доступи та середовище: тестовий контур, порядок знеособлення вивантажень, хто з боку клініки підтверджує коректність історичних даних.
Після обговорення задачі ми повертаємося з оцінкою робіт і планом впровадження: черговість етапів, що перевіряємо на історичних даних, де межа між пілотом на одному відділенні та повним контуром і за якими відділеннями вважаємо модель робочою.
Якщо частини даних поки немає — це теж частина розмови: підкажемо, що збирається по ходу і як це впливає на строки.
