Это история появилась на стыке государственной медицины и IT. Она о том, как быстро и бесплатно получилось внедрить процесс информационного обеспечения станций скорой медицинской помощи о заполненности койко-мест инфекционных отделений больниц.
Во время пандемии, когда в соцсетях появлялись фото с очередями из машин скорой помощи на въездах в больницы, многие стали подозревать, что в нашей системе здравоохранения что-то не так. Ситуация осложнялась тем, что диспетчера станций скорой медицинской помощи не владели точной информацией о наличии свободных койко-мест в инфекционных отделениях больниц. Дозвониться до дежурных врачей не всегда удавалось в регламентное время, телефоны в инфекционных отделениях буквально «плавились» от звонков. Бригады скорой помощи ездили от одной больницы к другой, в формате «броуновского движения», чтобы передать пациентов на госпитализацию.
Источник фото: Российская газета
От диспетчера скорой помощи зависит, насколько быстро пациента госпитализирует стационар. Важно знать заполненность всех коек, отслеживать их освобождение и развертывание новых койко-мест, то есть быть в курсе изменений коечного фонда. Медицинский информационно-аналитический центр начал решение задачи по обеспечению системы здравоохранения оперативной информацией о наличии свободных коек в режиме реального времени.
Часть 2. Формирование гипотезы
Традиционно наша бюджетная сфера решает задачи в условиях нехватки финансов (дорого), либо времени (долго). У нас не было ни того, ни другого, поэтому собрали из того, что есть.
Задача была в том, чтобы максимально ускорить сбор, обработку и предоставление диспетчерам скорой помощи информации о наличии свободных койко-мест в инфекционных отделениях. При этом, желательно исключить коммуникацию диспетчеров и дежурных врачей по телефону, так как мы уже выяснили, что в периоды высокой нагрузки на больницы, диспетчерам сложнее дозвониться до врачей. Нужно было создать быстрые способы передачи информации о заполняемости койко-мест разных типов.
При госпитализации пациента с респираторными инфекциями, тип койки, на которую его положат, зависит от его состояния. В распоряжении стационаров есть койки без кислородного оборудования, койки с кислородным оборудованием, реанимационные койки с ИВЛ и провизорные («диагностические койки», в отдельных палатах для пациентов с неподтвержденным диагнозом и признаками внебольничной пневмонии). Следующим этапом отрабатывали алгоритм взаимодействия и режим передачи информации.
Для решения этой задачи имелась гипотеза, которую я сразу начал проверять в боевых условиях.
Круглосуточное взаимодействие диспетчеров скорой помощи, дежурных стационаров и руководства организовывали через группу в Telegram. Дежурные отправляли в чат сообщения с названием больницы, количеством и типом свободных койко-мест. Дежурный оператор сводил информацию в таблице Excel, копировал и выкладывал в чат. В чате она уже была доступна в виде графического изображения.
Рабочая модель, собранная на коленке из «песка и палок», получилась на удивление жизнеспособной. Уменьшилось время принятия решения о том, куда госпитализировать пациента. Это и был прототип информационной системы, где таблицы в Excel это СУБД, оператор, который заносит цифры в ячейки – веб-приложение, а картинка в чате – графический интерфейс.
Часть 4. Результат
Чат врачей и диспетчеров скорой помощи стал выполнять роль регулировщика на загруженном перекрестке и был удобен для статистиков при составлении отчетов. Со временем его передали на круглосуточное администрирование в одно из медицинских учреждений.
Следующим шагом развития стало создание информационной системы, где роль человека, который вручную менял цифры в таблице и выкладывал ее в чат, заменило веб-приложение. Преимущество подхода заключалось в том, что все процессы были протестированы, история группы отлично дополняла техзадание на разработку системы.
Часть 1. Немного истории
Во время пандемии, когда в соцсетях появлялись фото с очередями из машин скорой помощи на въездах в больницы, многие стали подозревать, что в нашей системе здравоохранения что-то не так. Ситуация осложнялась тем, что диспетчера станций скорой медицинской помощи не владели точной информацией о наличии свободных койко-мест в инфекционных отделениях больниц. Дозвониться до дежурных врачей не всегда удавалось в регламентное время, телефоны в инфекционных отделениях буквально «плавились» от звонков. Бригады скорой помощи ездили от одной больницы к другой, в формате «броуновского движения», чтобы передать пациентов на госпитализацию.
Источник фото: Российская газета
От диспетчера скорой помощи зависит, насколько быстро пациента госпитализирует стационар. Важно знать заполненность всех коек, отслеживать их освобождение и развертывание новых койко-мест, то есть быть в курсе изменений коечного фонда. Медицинский информационно-аналитический центр начал решение задачи по обеспечению системы здравоохранения оперативной информацией о наличии свободных коек в режиме реального времени.
Часть 2. Формирование гипотезы
Традиционно наша бюджетная сфера решает задачи в условиях нехватки финансов (дорого), либо времени (долго). У нас не было ни того, ни другого, поэтому собрали из того, что есть.
Задача была в том, чтобы максимально ускорить сбор, обработку и предоставление диспетчерам скорой помощи информации о наличии свободных койко-мест в инфекционных отделениях. При этом, желательно исключить коммуникацию диспетчеров и дежурных врачей по телефону, так как мы уже выяснили, что в периоды высокой нагрузки на больницы, диспетчерам сложнее дозвониться до врачей. Нужно было создать быстрые способы передачи информации о заполняемости койко-мест разных типов.
При госпитализации пациента с респираторными инфекциями, тип койки, на которую его положат, зависит от его состояния. В распоряжении стационаров есть койки без кислородного оборудования, койки с кислородным оборудованием, реанимационные койки с ИВЛ и провизорные («диагностические койки», в отдельных палатах для пациентов с неподтвержденным диагнозом и признаками внебольничной пневмонии). Следующим этапом отрабатывали алгоритм взаимодействия и режим передачи информации.
Для решения этой задачи имелась гипотеза, которую я сразу начал проверять в боевых условиях.
Часть 3. Маршрутизация пациентов при помощи Telegram и Excel
Круглосуточное взаимодействие диспетчеров скорой помощи, дежурных стационаров и руководства организовывали через группу в Telegram. Дежурные отправляли в чат сообщения с названием больницы, количеством и типом свободных койко-мест. Дежурный оператор сводил информацию в таблице Excel, копировал и выкладывал в чат. В чате она уже была доступна в виде графического изображения.
Рабочая модель, собранная на коленке из «песка и палок», получилась на удивление жизнеспособной. Уменьшилось время принятия решения о том, куда госпитализировать пациента. Это и был прототип информационной системы, где таблицы в Excel это СУБД, оператор, который заносит цифры в ячейки – веб-приложение, а картинка в чате – графический интерфейс.
Часть 4. Результат
Чат врачей и диспетчеров скорой помощи стал выполнять роль регулировщика на загруженном перекрестке и был удобен для статистиков при составлении отчетов. Со временем его передали на круглосуточное администрирование в одно из медицинских учреждений.
Следующим шагом развития стало создание информационной системы, где роль человека, который вручную менял цифры в таблице и выкладывал ее в чат, заменило веб-приложение. Преимущество подхода заключалось в том, что все процессы были протестированы, история группы отлично дополняла техзадание на разработку системы.
Что было дальше?
Сделали сайт, раздали учетки, провели обучение. Подключили экспериментального телеграм-бота, который по команде отправлял пользователю выгрузку базы данных сайта и рассылал уведомление врачам стационара, если диспетчер скорой помощи отправлял заявку на госпитализацию пациента.
Почувствовать себя победителями в полной мере не удалось. Эпидемиологическая ситуация начала улучшаться, разработку прекратили на половине, так как в приоритете были другие проекты.
Почувствовать себя победителями в полной мере не удалось. Эпидемиологическая ситуация начала улучшаться, разработку прекратили на половине, так как в приоритете были другие проекты.
