Подсистема информационного взаимодействия в системе сбора медицинских статистических данных

Полный текст

Введение Цифровая трансформация системы здравоохранения - это процесс выстраивания новой модели работы медицинских организаций и органов управления в них. Главной целью цифровой трансформации системы здравоохранения является сохранение жизни и здоровья людей, повышение ожидаемой продолжительности жизни до 78 лет[8]. Взаимодействие всех уровней управления в медицине осуществляется при помощи единой государственной информационной системы в сфере здравоохранения (ЕГИСЗ)[9]. В данной системе используется электронный медицинский документооборот (ЭМДО) на основе структурированных электронных медицинских документов (СЭМД)[10]. Пример таких документов - медицинские статистические данные, структурированные в соответствии со стандартом SDMX [1]. Использование единого цифрового пространства позволяет обмениваться информацией о деятельности лечебно- профилактических учреждений, а затем совершенствовать и модернизировать систему оказания медицинской помощи жителям регионов [2]. Использование подобной системы повышает достоверность статистических медицинских данных и помогает эффективно маневрировать ограниченными ресурсами здравоохранения [3]. До модернизации системы медицинской статистики передача данных осуществлялась с муниципального уровня на региональный, а затем с регионального на федеральный уровень. Таким образом, федеральный уровень не имел доступа к исходным данным с муниципального уровня, а значит невозможно было проверить их актуальность. Каждый субъект предоставлял отчеты на магнитном и бумажном носителе в двух экземплярах. Передача электронных документов осуществлялась через электронную почту или предоставлялась на магнитном носителе. При такой схеме взаимодействия между федеральным и региональным центрами часто встречались несоответствия медико- статистической информации и требовалось обеспечить процесс корректировки ошибок в статистических данных непосредственно сотрудниками региональных медицинских информационно- аналитических центров (МИАЦ). После модернизации системы медицинской статистики федеральный уровень может получать данные с любого из нижестоящих уровней в режиме реального времени [2]. Для обеспечения такого обмена данными между всеми уровнями необходима подсистема информационного взаимодействия. В качестве такой подсистемы может выступать специальное программное обеспечение - брокер сообщений. Мы рассматриваем логическую топологию брокеров сообщений и их конфигурацию. Цель исследования - описать конфигурацию и топологию брокера сообщений для асинхронной и надежной передачи данных в подсистеме информационного взаимодействия в рамках модернизации системы сбора и обработки медицинских статистических данных. Материалы и методы Использована информация из нормативно- правовых актов, федерального закона в сфере здравоохранения, а также данные об актуальных исследованиях в области передачи данных. Результаты В качестве подсистемы информационного взаимодействия мы предлагаем использовать брокер сообщений [4] Apache Kafka с открытым исходным кодом [5]. Брокер сообщений паттерн проектирования, при котором ответственность за доставку сообщений между сервисами возлагают на некоторую программу посредник. Предлагаем использовать следующую логическую топологию для обмена данными между уровнями (рис.). Кластер - объединение 2 брокеров сообщений под управляющей системой Zookeeper или Kraft / The cluster is a union of 2 message brokers under the management system Zookeeper or Kraft. Схема взаимодействия с использованием брокеров сообщений: ФГБУ отправляют данные на федеральный уровень, минуя региональный уровень Источник: выполнил Т.А. Асмус. Diagram of interaction with use message brokers: a federal budgetary state institution send data to the federal level, bypassing the regional level Source: made by T.A. Asmus. Рассмотрим теперь конфигурацию кластеров. Мы предлагаем использовать следующую конфигурацию для всех кластеров: 2 брокера в кластере, один топик в каждом брокере (топик - это логическое разделение сообщений на темы), настройки брокеров в кластере: фактор репликации: 1, т.е. копирование данных на второй брокер в кластере; время хранения файла в оперативной памяти перед сбросом на диск: 0 секунд; максимальный размер раздела (раздел - количество памяти выделенное для хранения последовательности полученных сообщений): неограничен; максимальный размер сообщения от продюсера (программа, отправляющая данные в брокер): неограничен; время в часах, в течении которого файлы будут храниться на брокере: 4380 (6 месяцев); политика очистки логов (лог - история получения сообщений): хранить столько же, сколько и сообщения в брокере - 6 месяцев. Остальные настройки брокера и кластера предлагаем оставить без изменений. Обсуждение Опишем, как использование брокера сообщений исправляет недостатки системы передачи медицинских данных до ее модернизации. Apache Kafka - программа с открытым исходным кодом - является одной из наиболее распространенных реализаций паттерна брокер сообщений [6; 7]. Выше мы отметили, что до модернизации передача данных происходила таким образом, что федеральный уровень не мог составить объективное представление о событиях, происходящих на муниципальном уровне и была необходима физическая передача данных в места их обработки и дальнейшее их преобразование в электронный формат или ручной перенос в систему обработки данных, а если на каком- либо уровне возникали ошибки или неточности в обработке или передаче данных, то эти документы необходимо было запросить заново, в результате чего увеличивается время, за которое данные дойдут до федерального уровня. Также эта модель подвержена ошибкам, связанным с человеческим фактором. Использование брокера сообщений исправляет эти проблемы. Мы предлагаем объединить учреждения на муниципальном уровне в группы, например, по территориальному признаку, и каждую такую группу подключить к своему кластеру. Использование кластера повысит надежность использования брокера: если основной брокер выйдет из строя, другой примет на себя нагрузку. Аналогично предлагаем сделать и на региональном уровне. Следует разместить кластеры брокеров между уровнями (см. рис.). Каждый уровень должен загружать данные в свой кластер, и каждый вышестоящий уровень будет иметь доступ к кластерам брокеров из нижестоящего уровня. При таком подходе у федерального уровня будет возможность получать исходные данные в любое время как с регионального, так и муниципального уровня, что может повысить эффективность использования ресурсов здравоохранения. При такой модели обмена данными уменьшается задержка передачи данных, а значит вышестоящие уровни будут получать информацию с нижестоящих уровней более оперативно. Процесс чтения данных из брокера можно настроить таким образом, чтобы переданная в них информация сразу попадала в необходимые БД без участия человека. Apache Kafka позволяет хранить переданные ему данные в течение заданного промежутка времени (время жизни сообщения), в т.ч. неограниченно. При неограниченном хранении сообщений со временем потребуется огромный объем дискового пространства, поэтому мы предлагаем хранить сообщения 6 месяцев. В отличие от многих других брокеров, Kafka не удаляет сообщения после их прочтения принимающей стороной. Следовательно, все уровни смогут читать данные из доступных им брокеров в любое время неограниченное количество раз в течение жизни сообщения. Помимо асинхронности передачи данных и удобства масштабирования, Kafka гарантирует доставку сообщения до принимающей стороны. Также Kafka предоставляет возможность регулирования нагрузки на компьютер принимающей стороны, благодаря тому что консумер - программа, читающая данные из брокера, - считывает данные через заранее заданные промежутки времени или по требованию принимающей стороны. Заключение Для обеспечения обмена медицинскими статистическими данными в режиме реального времени в системе медицинской статистики целесообразно использовать Apache Kafka - программу, реализующую паттерн проектирования - брокер сообщений. Главным преимуществом ее использования является гарантия доставки сообщений до получателя и возможность их асинхронной передачи. Подобная подсистема информационного взаимодействия позволит достаточно быстро обмениваться данными между всеми уровнями взаимодействия в системе сбора и обработки медицинских статистических данных, что позволит более рационально распределять ограниченные ресурсы системы здравоохранения.

Об авторах

Александр Алексеевич Лисненко

Первый МГМУ им. И.М. Сеченова Минздрава России (Сеченовский университет)

Email: lisnenko_a_a@staff.sechenov.ru
ORCID iD: 0000-0003-3625-3715

преподаватель кафедры информационных и интернет-технологий

Россия, 119048, Москва, ул. Трубецкая, д. 8, стр. 2

Вероника Андреевна Асмус

Первый МГМУ им. И.М. Сеченова Минздрава России (Сеченовский университет)

Автор, ответственный за переписку.
Email: asmus.veronika.a@mail.ru
студент 4 курса лечебного факультета Россия, 119048, Москва, ул. Трубецкая, д. 8, стр. 2

Тимофей Андреевич Асмус

Российский университет дружбы народов

Email: asmus.tim.a@gmail.com
ORCID iD: 0009-0009-1642-4135

магистрант инженерной академии

Россия, 117198, Москва, ул. Миклухо-Маклая, д. 6

Список литературы

Дополнительные файлы