Subsystem of information interaction in the system of collecting medical statistical data

Cover Page

Cite item

Full Text

Abstract

The purpose of the study is describing the configuration and topology of a message broker for asynchronous and reliable data transmission in the information interaction subsystem as part of the modernization of the system for collecting and processing medical statistical data. Information from regulatory and legal acts, federal law, as well as data on current research in the field of data transmission were used. Medical statistics is a branch of statistics that includes data on medicine, public health, and the activities of medical organizations. Medical statistics allow the most efficient allocation of limited health resources. The introduction of digital technologies contributes to the effective collection of medical statistics. As part of the digital transformation of the healthcare system, the process of collecting medical statistics is being optimized. One of the optimization tools is the introduction of electronic medical document management, where each document is presented in the form of a structured electronic medical document. An example of structuring an electronic document for medical statistics is documents structured in accordance with the international standard for the exchange of statistical data and metadata - Statistical data and metadata exchange. The main advantages of optimization are the ability to receive information in real time, the asynchrony of the messaging process and the ordering of the flow of medical data over time. To ensure the operation of the information system, it is necessary to configure the subsystem of information interaction between medical data sources and their processing centers. As such a subsystem, we suggest using an intermediary program for asynchronous message transmission. A program that implements the message broker design pattern. The study describes the advantages of the Apache Kafka message broker. The introduction of such a subsystem makes it possible to change the system of information interaction between administrative levels, so that the upper levels can directly receive the initial raw data from the lower levels. At the same time, the number of Apache Kafka clusters depends on the number of administrative units that medical institutions are assigned to.

Full Text

Введение Цифровая трансформация системы здравоохранения - это процесс выстраивания новой модели работы медицинских организаций и органов управления в них. Главной целью цифровой трансформации системы здравоохранения является сохранение жизни и здоровья людей, повышение ожидаемой продолжительности жизни до 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 - программу, реализующую паттерн проектирования - брокер сообщений. Главным преимуществом ее использования является гарантия доставки сообщений до получателя и возможность их асинхронной передачи. Подобная подсистема информационного взаимодействия позволит достаточно быстро обмениваться данными между всеми уровнями взаимодействия в системе сбора и обработки медицинских статистических данных, что позволит более рационально распределять ограниченные ресурсы системы здравоохранения.
×

About the authors

Alexander A. Lisnenko

I.M. Sechenov First Moscow State Medical University (Sechenov University)

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

Lecturer at the Department of Information and Internet Technologies

8 Trubetskaya st., bldg. 2, Moscow, 119048, Russian Federation

Veronica A. Asmus

I.M. Sechenov First Moscow State Medical University (Sechenov University)

Author for correspondence.
Email: asmus.veronika.a@mail.ru
4rd Year Student of the Faculty of Medicine 8 Trubetskaya st., bldg. 2, Moscow, 119048, Russian Federation

Timofey A. Asmus

RUDN University

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

Master Student of the Academy of Engineering

6 Miklukho-Maklaya st., Moscow, 117198, Russian Federation

References

  1. Bashina O, Komkova N, Matraeva L, Kosolapova V. The future of international statistical data sharing and new issues of interaction. Voprosy statistiki. 2019;26(7):55–66. (In Russ). https://doi.org/10.34023/2313-6383-2019-26-7-55-66 EDN: IMYRTT
  2. Zarubina T, Shvyrev S, Solovyev V, Rauzina S, Rodionov V, Penzin O, Surin M. Integrated electronic health record: status and prospects. Medical Doctor and IT. 2016;(2):35–44. (In Russ.). EDN: WMOTPH
  3. Blum VS. Innovative System State Medical Statistics. Aktual’nye problemy ekonomiki i upravleniya. 2015;(2):80–88. (In Russ.). EDN: TWTVMB
  4. Samtani G, Sadhwani D. Integration brokers and Web services. Web Services Business Strategies and Architectures. Birmingham: Apress; 2013:71–84. https://doi.org/10.1007/978-1-4302-5356-3
  5. Scott D, Gamow V, Klein D. Kafka in Action. Moscow: DMK Press; 2022. (In Russ.).
  6. Rakhmatulin TG. Comparative analysis of Apache Kafka and RabbitMQ. Aktual’nye issledovaniya. 2022;(49):35–40. (In Russ.). https://doi.org/10.51635/27131513_2022_49-1_35 EDN: ESRFWG
  7. Linev FA. Obzor sistem obmena soobshcheniyami [Review of messaging systems]. Young Scientist. 2017;(19):29–32. (In Russ.). EDN: YNVUHT

Supplementary files

Supplementary Files
Action
1. JATS XML
Download

Copyright (c) 2025 Lisnenko A.A., Asmus V.A., Asmus T.A.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.