«ДатаМед»: как превратить разрозненные медицинские данные в инструмент управления

Вчера в 19:08

© Изображение сгенерировано ИИ

Медицинские организации (МО) ежедневно формируют большие массивы информации — это данные о приёме пациентов и госпитализациях, а также сведения о передаче электронных медицинских документов (ЭМД), ресурсах и структурных подразделениях, персонале, финансовых расчетах и т.д. Часто эти данные хранятся в разных информационных системах и могут отличаться по форматам, справочникам и качеству заполнения. Для руководителя региона или медицинской организации задача заключается уже не только в получении отчётности, но и в том, чтобы быстро понять, насколько данные полны и достоверны, что именно стоит за изменением конкретного показателя.

Система аналитики медицинских данных «ДатаМед», разработанная АО «БАРС Груп», решает эту задачу. Система собирает формируемые в медицинских организациях данные в отдельном аналитическом контуре, позволяющем строить наглядные визуализации по интересующим показателям, контролирует качество и обеспечивает переход к конкретному источнику информации во всей системе здравоохранения региона.

От МИС к аналитическому контуру

«ДатаМед» не заменяет медицинские информационные системы (МИС), а работает поверх них. Первичные данные поступают из различных информационных систем (финансовых, МИС, ЛИС и др.). По умолчанию решение интегрировано с БАРС.МИС. Также предусмотрена загрузка данных из файлов XLS/XLSX, CSV, XML и JSON.

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

Архитектура решения построена на микросервисах и контейнерах Docker. Для обработки данных используются Apache Spark и Apache Airflow. Основные базы данных: PostgreSQL — для хранения операционного состояния приложения — и ClickHouse — в роли хранилища данных моделей; для объектного хранения применяется MinIO.

Интеграция с источниками может выполняться через API или специализированные интеграционные шины. В одном из регионов внедрения, например, решение подключено к распределённым базам данных КПС «СМСО» через интеграционную шину.

На входе «ДатаМед» поддерживает работу с файлами, базами данных PostgreSQL, Oracle, MySQL, ClickHouse и Greenplum, а также API с форматами JSON и XML. Пользовательские отчёты и дашборды можно выгружать в XLSX, PDF и CSV.

Как устроен аналитический контур

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

Это позволяет выполнять ресурсоёмкие запросы независимо от систем-источников данных. Специалисты при этом продолжают работать в своей основной информационной системе (МИС, ЛИС, ФХД и др.), а руководители и аналитики получают отдельный контур для построения отчётов и дашбордов. 

Архитектура допускает распределение компонентов между разными серверами. Например, ETL-сервисы и аналитическое хранилище ClickHouse могут размещаться на отдельных виртуальных машинах.

Как система приводит данные к единому виду

Одна из задач аналитической системы — сделать данные из разных медицинских организаций сопоставимыми. Для этого используются несколько механизмов.

Форматно-логический контроль (ФЛК). На этапе загрузки система проверяет обязательные поля и логические связи между ними. Например, запись не проходит в аналитику, если в ней отсутствуют дата приёма или код услуги либо если дата выписки предшествует дате рождения пациента.

Согласование нормативно-справочной информации (НСИ). Система приводит к единому виду справочники, используемые разными организациями. Например, одна МО может обозначать специальность кодом «101», а другая — «Т-01». При обработке данные сопоставляются с едиными справочниками, включая МКБ-10, номенклатуру медицинских услуг и специальности.

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

Контроль качества данных

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

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

Полнота данных контролируется на этапе ETL с помощью ФЛК. Записи с отсутствующими обязательными полями не загружаются в аналитическую систему. При обнаружении аномально низких показателей пользователь может детализировать отчёт до конкретной медицинской организации или врача и определить, на каком уровне возникла проблема.

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

При этом «ДатаМед» не исправляет первичные сведения непосредственно в медицинских информационных системах. Ответственность разделяется между несколькими уровнями:

— медицинские организации отвечают за корректность первичного ввода данных;

— администраторы и разработчики аналитической системы настраивают правила ФЛК, очистки и работы со справочниками;

— руководители МО и медицинских информационно-аналитических центров (МИАЦ) с помощью аналитики выявляют проблемные данные и инициируют их исправление в источнике.

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

Отказоустойчивость 

«ДатаМед» построена на микросервисной архитектуре с использованием контейнеров Docker. Сервисы могут автоматически перезапускаться при сбоях, а их работоспособность контролируется с помощью механизма проверок состояния. 

Отдельные компоненты системы можно распределять между разными серверами. Например, ETL-сервисы и аналитическое хранилище ClickHouse могут размещаться на отдельных виртуальных машинах.

Резервному копированию подлежат конфигурация системы, основные базы данных: PostgreSQL и ClickHouse, объектное хранилище MinIO и файловые источники. Копирование выполняется с остановкой сервисов, чтобы обеспечить согласованность данных. Периодичность и сроки хранения резервных копий определяются регламентом конкретного заказчика, а сам механизм резервного копирования реализуется сторонним ПО и силами заказчика.

Время восстановления зависит от характера сбоя, объёма данных, производительности дисковой подсистемы и используемой схемы резервирования. Универсальные значения RTO и RPO для всех установок не используются — они определяются отдельно для конкретной инфраструктуры.

Географическое резервирование не входит в стандартную схему поставки, однако может быть организовано на инфраструктурном уровне. В частности, возможны размещение экземпляров системы в разных ЦОД, использование реплицируемых кластеров ClickHouse и PostgreSQL и хранение резервных копий в удалённом ЦОД.

Если один из источников временно недоступен, очередной сеанс загрузки завершается с ошибкой, однако уже загруженная информация сохраняется. На дашбордах отображается дата последнего успешного обновления.

После восстановления источника администратор может повторно запустить ETL-процесс и загрузить данные за пропущенный период. Поскольку «ДатаМед» не является первичным источником информации, данные при необходимости могут быть повторно загружены из МИС.

Защита данных и разграничение доступа

«ДатаМед» рассчитана на работу с медицинской информацией в закрытом контуре заказчика. Информация о пациентах обезличивается ещё на стороне МИС: ФИО, адреса и контактные данные не передаются в аналитическую систему и заменяются анонимным идентификатором.

При максимальной детализации пользователь видит обезличенный идентификатор случая. Данные врачей могут использоваться для анализа нагрузки и эффективности работы специалистов, однако доступ к ним ограничивается ролевой моделью.

Права пользователей настраиваются через административную панель. Например, главный врач может получать доступ к данным своей медицинской организации, заведующий отделением — к информации своего подразделения, а сотрудник МИАЦ — к сводным данным по региону.

В системе ведётся аудит действий пользователей. В журнале фиксируются пользователь, время, IP-адрес, раздел системы и выполненное действие, включая просмотр, создание и экспорт данных. Срок хранения журнала и порядок его передачи во внешние SIEM-системы определяются регламентом заказчика.

Передача данных между системами защищается с помощью HTTPS и TLS. Для подключения к источникам могут использоваться TLS-шифрование, защищённые JDBC-соединения и HTTPS API. Внутренние микросервисы взаимодействуют в изолированной контейнерной сети.

Какие задачи решает «ДатаМед»

Система рассчитана на работу с показателями на нескольких уровнях — от регионального управления до конкретной медицинской организации и её подразделений.

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

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

Отдельный класс задач связан с контролем цифровых процессов. Например, система позволяет анализировать источники записи к врачу — инфоматы, регистратуру и ЕПГУ — и сравнивать их вклад в общий объём записей.

Основным инструментом работы пользователя становятся интерактивные дашборды. Они позволяют быстро оценить ситуацию и перейти от общего показателя к деталям.

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

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

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

Масштабирование и производительность

Архитектура «ДатаМед» рассчитана на работу с большими объёмами информации. В действующих внедрениях система ежедневно обрабатывает 100-200 млн записей, при этом основная загрузка данных выполняется в ночное время — с 00:00 до 06:00. В зависимости от объёма информации по конкретному направлению задержка между её поступлением в источник и появлением в аналитике составляет от нескольких минут до двух часов.

Для параллельной обработки используется Apache Spark, а в качестве аналитического хранилища — ClickHouse. При этом работа с уже загруженными данными не требует длительного ожидания: типовые отчёты и дашборды открываются в среднем за 5-10 секунд.

При подключении новой медицинской организации в уже внедрённом регионе техническая доработка системы не требуется: достаточно создать учётные записи и назначить соответствующие права доступа. Жёсткий программный предел по объёму данных не установлен; для конфигураций с объёмом до 1 млрд записей определены ориентировочные требования к инфраструктуре. Для пользовательской нагрузки предусмотрены конфигурации до 1000 пользователей, при этом в среднем в регионе с системой работают около 250 пользователей.

Производительность поддерживается за счёт кэширования аналитических запросов, индексации и партицирования таблиц ClickHouse, параллельной обработки данных в Apache Spark и оркестрации процессов через Apache Airflow. Backend-приложения могут запускаться в нескольких экземплярах, а отдельные сервисы — распределяться между разными серверами.

В одной из конфигураций решение развёртывается на трёх виртуальных машинах: сервер приложения получает 16 CPU, 32 ГБ RAM и 500 ГБ SSD, сервер ClickHouse — 16 CPU, 32 ГБ RAM и 1 ТБ SSD, сервер ETL — 16 CPU, 32 ГБ RAM и 300 ГБ SSD.

Подключение новых организаций и источников

Подключение новой МО в уже внедрённом регионе является преимущественно административной операцией и может занимать от нескольких часов до нескольких дней — в зависимости от структуры организации.

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

Таким образом, «ДатаМед» сочетает готовую базовую платформу с возможностью адаптации под конкретный регион. В поставку входят архитектура ETL и OLAP, инструменты визуализации, типовые отчёты и более 25 готовых аналитических панелей для управления здравоохранением.

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

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

Технологический стек и импортозамещение

«ДатаМед» — отечественная разработка с российской кодовой базой и архитектурой. 

В технологический стек входят TypeScript, Angular, ECharts и Nginx на frontend-уровне, PHP/Yii2 и Python/FastAPI на backend-уровне, Apache Airflow и Apache Spark для ETL, а также PostgreSQL, ClickHouse и MinIO для работы с данными.

При этом решение использует международные open-source-компоненты, включая Linux, Docker, PostgreSQL, ClickHouse, Nginx, Angular, Python, PHP и Apache. Коммерческие зарубежные BI-платформы вроде Tableau или Power BI не используются. Обязательной зависимости от зарубежных облачных сервисов нет: система может работать в закрытом контуре инфраструктуры заказчика.

Предусмотрена работа с российскими операционными системами, включая Astra Linux, ALT Linux и РЕД ОС. Компоненты решения поставляются в контейнерном виде, что снижает зависимость от конкретной операционной системы.

В зависимости от конфигурации заказчика инфраструктурные компоненты, включая PostgreSQL, ClickHouse, RabbitMQ, Redis и MinIO, могут заменяться на совместимые решения при условии соответствия протоколам и прохождения необходимого тестирования.

Результаты внедрения

Несколько сценариев использования «ДатаМед». 

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

В другом регионе система использовалась для анализа источников записи к врачу. Доля записей через ЕПГУ была выделена в качестве одного из показателей цифровой зрелости региона, а данные о фактической нагрузке по специальностям позволили перераспределить часы приёма и устранить локальные очереди.

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

В отдельном сценарии система помогает выявлять не только медицинские организации, но и конкретные типы электронных медицинских документов, в которых чаще возникают ошибки при передаче в РЭМД. Это позволяет проводить адресную работу с персоналом и корректировать настройки МИС.

Наконец, автоматизация аналитических срезов сокращает объём ручной работы сотрудников Минздрава и МИАЦ при подготовке сводных отчётов. Вместо ручного сведения информации необходимые данные можно получать с помощью инструментов аналитической системы.

Что получает заказчик

«ДатаМед» — аналитическая надстройка над медицинскими информационными системами. Её задача не заменить МИС, а собрать данные из разных источников в отдельном аналитическом контуре, привести их к сопоставимому виду и дать руководителям инструменты для анализа.

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

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

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

Читайте также: Как ГИС-комплекс «Риск ЧС» предотвращает аварии на объектах ТЭК