Разработка AI-системы прогнозирования загрузки стационара

Прогнозирование загрузки стационара: где ломается текущий расчёт

План госпитализаций чаще всего строится на средних значениях за прошлые периоды: берут занятость коечного фонда за месяц или квартал и переносят на следующий интервал. Такой расчёт держится, пока поток однороден. Как только структура поступлений меняется — сдвигаются плановые госпитализации, идёт волна экстренных — среднее перестаёт описывать реальность, и расхождение плана и факта растёт.

Вторая точка отказа — запаздывание выгрузок. Данные приходят из разных подсистем с разной периодичностью: приёмное отделение фиксирует поступление в момент оформления, а движение по койкам и выписки попадают в отчётность позже, иногда раз в сутки. Расчёт, построенный на таком срезе, видит вчерашнюю картину и не реагирует на сегодняшний всплеск.

Сезонность поступлений обычно не учитывается вовсе. Респираторные волны, отпускной спад плановой госпитализации, праздничные периоды дают повторяемый профиль по неделям и месяцам, но внутри среднего за период он размывается. Отдельная проблема — плановые потоки: заранее известные объёмы операций и госпитализаций не подаются во вход как отдельный сигнал, хотя именно они определяют, сколько коек останется под экстренный приём.

В сумме получается прогноз, который расходится с фактом тем сильнее, чем выше нагрузка — то есть ровно тогда, когда решение о перераспределении коек критично. Разбираем, как это закрывается: откуда берутся данные, что уходит во вход расчёта и как строится прогнозирование загрузки стационара, которому можно доверять в смену пиковой загрузки.

Регулярное прогнозирование потока пациентов: измеримый эффект

Регулярный расчёт меняет саму логику работы: прогноз по каждому отделению пересчитывается nightly, а при поступлении новых данных — внепланово, поэтому решения принимаются не по факту заполненности коек, а за несколько дней до пика. Данные подтягиваются из учётной системы по отраслевому стандарту обмена HL7 FHIR, без ручных выгрузок и «согласований в мессенджере».

• Отказы в плановой госпитализации. Прогноз на 7–14 дней вперёд показывает перегрузку заранее — дату госпитализации переносят до приезда пациента, а не в день оформления. Из потока уходит самый дорогой класс отказов: те, что бьют по репутации и требуют повторной записи.
• Загрузка отделений. Видно перекос между отделениями за 3–5 дней до пика, появляется время на перевод профильных пациентов и перераспределение коечного фонда. Разброс загрузки между отделениями сокращается, авральные «дежурства на пределе» становятся исключением.
• Перераспределение смен. Прогноз потока по дням недели и часам приёмного покоя даёт основание ставить усиление под конкретный интервал, а не держать полный состав «на всякий случай». Смены планируются под ожидаемую нагрузку, переработки уходят в управляемый режим.
• Горизонт планирования. Три ритма: сутки — оперативное реагирование, неделя — смены, месяц — расходники, лекарства и плановые объёмы. Каждый горизонт закрывается своим срезом прогноза, а не одной общей цифрой.
• Класс отказов. Отдельно считаем, сколько отказов удалось превратить в плановый перенос. Это и есть измеримый эффект: смещение из неуправляемого класса в управляемый, а не просто «стало спокойнее».

Эффект держится только при контроле точности: считаем отклонение факта от прогноза по каждому отделению, при устойчивом выходе за порог модель переобучается на свежих данных. Разовый прогноз ничего не решает — работает регулярный цикл с обратной связью.

Подходы к модели расчёта: правила, статистика, обучение на данных

Модель расчёта — это не только алгоритм, но и то, какие данные в него попадают, с каким горизонтом он обновляется и как проверяется. Мы держим несколько взаимозаменяемых вариантов одного уровня и выбираем под задачу: где-то достаточно правил и сезонных коэффициентов, где-то нужна статистическая модель, а где-то — обучение на данных с проверкой на ретроспективных срезах.

Критерий один: вариант должен обыгрывать простое правило на вашей истории, а не на демонстрационных данных. Если выигрыша нет — в расчёт идёт правило, оно прозрачнее.

Варианты и их границы применимости

На практике чаще работает гибрид: правила задают рамки и отсекают невозможные значения, обучение на данных уточняет прогноз внутри этих рамок, а сезонные коэффициенты сглаживают известные пики.

Этапы внедрения: от аудита данных до передачи модели

Порядок этапов не случаен: пока не проверена полнота выгрузок, любая метрика качества прогноза ничего не значит. Работу ведём по отраслевому стандарту организации проектов CRISP-DM — с фиксированными критериями готовности на каждом шаге.

1. Аудит источников. Разбираем выгрузки приёмного отделения, плановой госпитализации и коечного фонда: разрывы, дубликаты, смена правил учёта. На выходе — карта данных и перечень мест, где без допущений не обойтись.
2. Схема признаков. Из сырых событий собираем то, что реально объясняет загрузку: день недели и сезонность, профиль отделения, доля экстренных поступлений, листы ожидания, эпидемические волны.
3. Настройка расчёта. Фиксируем горизонт — сутки, трое суток, неделя — и определение переполнения. Модель отдаёт не одно число, а интервал и порог, при котором срабатывает предупреждение.
4. Проверка на исторических периодах. Прогоняем расчёт по прошлым отрезкам, включая праздники и всплески заболеваемости. Смотрим отклонение по занятости коек и долю попаданий в интервал.
5. Приёмка модели. Критерии согласуем заранее: точность на контрольных периодах, устойчивость к выбросам, понятная причина отказа от прогноза. Прошлая версия остаётся для отката.
6. Передача решения. Разворачиваем расчёт на вашей стороне, отдаём документацию и регламент переобучения, разбираем код с вашей командой. Дальше модель сопровождают ваши инженеры.

Схемы данных, регламент переобучения, контроль качества

Прогноз загрузки живёт не внутри модели, а в документах, которые остаются у команды стационара. Через полгода меняется маршрутизация пациентов или приходит новый аналитик — систему можно поднять, проверить и переобучить только по этому комплекту. Поэтому передаём не «чёрный ящик», а набор артефактов.

• Схема данных: источники (приёмное отделение, плановая запись, история госпитализаций, переводы между отделениями), частота выгрузки, типовые задержки поступления и ответственный за каждый поток.
• Описание признаков: что подаётся на вход — профиль и мощность отделения, день недели и сезонность, возрастная группа, средняя длительность пребывания, объём плановых поступлений; для каждого признака указан источник, тип и поведение при пропуске.
• Правила подготовки: как обрабатываются отмены, повторные госпитализации и неполные срезы, чтобы прогноз не расходился на стыках смен и в праздничные периоды.
• Регламент переобучения: триггеры (смена потока пациентов, новый профиль отделения, плановая периодичность), длина контрольного периода, кто запускает и кто подтверждает результат.
• Контроль качества прогноза: показатели по каждому отделению и горизонту, пороги пригодности и оповещение, когда ошибка выходит за них.
• Порядок разбора расхождений: сверка факта с прогнозом по интервалам, классификация причин (изменение маршрутизации, карантин, вспышка заболеваемости), вывод в журнал.
• Журнал версий и откат: какая версия работала в какой период и на каких данных обучалась, как вернуться к предыдущей, не теряя накопленную историю.

Кейс: расхождение плана и факта сократилось втрое

Многопрофильный стационар с потоком плановых и экстренных госпитализаций планировал загрузку по средним за прошлый период: отделения сводили цифры вручную раз в неделю. На горизонте семи дней ошибка доходила до четверти коек — часть коек простаивала, часть смен закрывали сверхурочными, плановые госпитализации переносили в день поступления.

Контур планирования перестроили: модель получает историю госпитализаций и операций за несколько лет, календарь плановых вмешательств, сезонность ОРВИ, дни недели и праздники, свежие экстренные поступления. Прогноз считаем по каждому отделению на 1, 7 и 14 дней вперёд; ядро — ансамбль деревьев Градиентный бустинг с доверительными интервалами, поэтому планировщик видит не одну цифру, а диапазон и вероятность выхода за него. Пересчёт идёт каждые сутки и внепланово, когда факт отклоняется от прогноза.

Через три месяца эксплуатации ошибка прогноза загрузки коек на недельном горизонте сократилась с 23% до 7%, расхождение плана и факта — втрое. Доля незапланированных простоев коек упала примерно вдвое, отказы в плановой госпитализации из-за отсутствия места почти ушли из отчётности. Смены медперсонала ставят под прогноз, а не под факт: переработки сократились на четверть.

Решение остаётся за человеком: модель показывает, где риск выхода за диапазон, заведующий отделением корректирует план, система пересчитывает прогноз с учётом правки.

Что делать, если данные собираются вручную и с задержкой?

Прогноз можно строить и на запаздывающих данных — вопрос не в полноте, а в предсказуемости задержки. Если выгрузка приходит каждое утро в одно и то же время, модель обучают на срезе «данные на момент прогноза» и не подмешивают будущее. Если задержка гуляет от часа до двух суток, качество падает незаметно: поля выглядят свежими, а фактически устарели.

Ручные выгрузки из учётной системы закрывают первый случай: источники данных собираются в одном месте, объём небольшой, состав полей стабилен. Их берут, когда отчёт по койкам, поступлениям и переводам уходит по расписанию. Ограничения предсказуемы — пропущенные дни, дубли и расхождение справочников отделений.

Неполные данные закрываем признаками, а не догадками: в модель идут давность последней записи, доля пустых полей и метка источника. Прогноз тогда отдаёт интервал и честно расширяет его в дни, когда данные пришли позже обычного, вместо того чтобы молча ошибиться.

Автоматический обмен подключают вторым этапом — когда ручной контур даёт понятную схему данных и видно, какие поля влияют на прогноз.

Технические вопросы перед стартом проекта

Перед стартом обычно проверяют три вещи: хватит ли накопленных данных, как система поведёт себя при массовом поступлении и кто отвечает за качество прогноза после передачи. Разбираем каждый пункт предметно, без обещаний «в среднем по больнице».

Стартуем с пилота на одном отделении: модель обучается на его истории, прогноз ежедневно сверяется с фактом — и только после устойчивого расхождения в допустимых границах решение расходится на остальные корпуса. Пилот даёт измеримую базу: точность на конкретном отделении вместо обещания точности вообще.

Что будет при массовом поступлении?

Всплеск модель не предскажет — он приходит извне: авария, вспышка, массовый заезд. Поэтому закладываем ручной ввод событий и порог расхождения: если факт ушёл от прогноза дальше заданного, дежурный получает оповещение и видит, какие отделения под угрозой. Правка вводится одним действием и учитывается в следующих расчётах.

Кто отвечает за качество прогноза после передачи?

Без контроля точность падает: меняются профили, потоки, порядок госпитализации. Фиксируем метрику качества, передаём регламент переобучения и панель расхождений, учим вашу команду запускать цикл самостоятельно. Первые обновления проходим вместе — так остаётся понятная процедура вместо «чёрного ящика».

Обсудим задачу и вернёмся с оценкой и планом

Для старта нам не нужен доступ ко всей информационной среде клиники — достаточно первичного состава данных и понимания, какие решения будут опираться на прогноз. Этого хватает, чтобы вернуться с оценкой работ и планом внедрения, а не с общими слайдами.

• Первичный состав данных: история госпитализаций и переводов между отделениями, длительность пребывания, отказы в приёме, сезонные всплески — за несколько полных циклов вместе с эпидсезоном.
• Точки интеграции: откуда данные забираются сейчас — модуль медстатистики, приёмное отделение, операционный блок — и в каком виде доступны выгрузки: файл, представление в базе или сервис с запросами.
• Горизонт планирования и решение под него: расстановка смен, резерв коек или план плановой госпитализации. Прогноз на сутки и на две недели — разные модели и разная частота пересчёта.
• Внешний контекст потока: календарь плановых операций, праздники и каникулы, график отпусков врачей, ограничения по профилям коек.
• Правила принятия решения: какие пороги считаются критичными, кто и как часто смотрит прогноз, что происходит при превышении.
• Доступы и среда: тестовый контур, порядок обезличивания выгрузок, кто со стороны клиники подтверждает корректность исторических данных.

После обсуждения задачи мы возвращаемся с оценкой работ и планом внедрения: очередность этапов, что проверяем на исторических данных, где граница между пилотом на одном отделении и полным контуром и по каким отделениям считаем модель рабочей. Если части данных пока нет — это тоже часть разговора: подскажем, что собирается по ходу и как это влияет на сроки.