Меня зовут Константин Бражников, я заместитель директора департамента развития клинических и образовательных проектов в Сеченовском Университете. Сегодня это исследовательский медицинский университет мирового уровня, и у него три направления деятельности: наука, образование и медицинская практика.
В структуре университета работает пять университетских клинических больниц, где ежегодно проходят лечение около 500 000 пациентов. Накопленная статистика по клиническим случаям — один из источников для научных работ наших сотрудников.
В прошлом году мы уже кратко рассказали на Хабре, как с использованием сервисов Yandex Cloud мы разработали платформу анализа медицинских данных — это сервис, который позволяет сотрудникам Сеченовского Университета получить доступ к клиническим данным. Пользователи системы — наши врачи‑исследователи, аспиранты и ординаторы — профессиональные научные сотрудники, которые двигают вперёд медицинскую науку. В этой статье покажу подробнее, как мы реализовали этот проект, как это решение живёт сейчас и помогает преподавателям и врачам‑исследователям в их работе.
С чего всё начиналось
Все больницы уже более двадцати лет используют медицинские информационные системы (МИС) для диагностики и лечения пациентов. Требования к таким системам формирует Минздрав, он издаёт методические рекомендации, как и какие данные там должны обрабатываться: состав истории болезни, состав исследований, рентгеновские снимки, результаты КТ, МРТ, УЗИ, лабораторных анализов. Информация о пациентах клинического центра Сеченовского университета также хранится в большой документно‑ориентированной базе на основе МИС «1С: Медицина». За всё время в неё загружено более 18 млн записей.
Как и у всех МИС, у неё есть ограничения: это в первую очередь инструмент для диагностики и лечения пациента. Эту систему не планировали применять в качестве источника для анализа: да, там есть статистический модуль, но выгрузить большие массивы данных в структурированном виде не удастся. Получить из неё агрегированную статистику и посмотреть данные обо всех историях болезни со схожими параметрами просто нельзя. А такая информация очень важна не только для исследователей, но и преподавателей университета, которые могут с её помощью показать студентам большой массив данных по изучаемой теме.
Как раньше наши исследователи получали необходимую для научных работ информацию. В лучшем случае учёным нужно было сформулировать запрос на данные, пройти несколько согласований и получить разовую выгрузку из МИС. Это занимало до месяца. А если сформулированная гипотеза не подтверждалась, приходилось проходить этот путь повторно — в научных проектах таких итераций может быть 10 и больше. В худшем случае аспиранты и студенты вручную отбирали информацию буквально из бумажных историй болезни.
Нам была необходима платформа, которая станет вспомогательным инструментом для наших врачей‑исследователей и поможет собирать данные для научных работ из реальной медицинской практики. Так можно вытащить аспирантов и студентов из архивов и вместо этого предоставить им рабочее место в удобной программе. Достаточно выбрать несколько необходимых критериев, нажать кнопку поиска и получить набор данных с нужными параметрами.
Поэтому у проеĸта была цель — систематизировать и предоставить в нужном формате исследователям Сеченовского Университета медицинские записи, накопленные в ĸлиниĸах. Необходимый массив информации — это деперсонализированные данные о перенесённом заболевании, симптомах, проведённых обследованиях, назначениях врача, сопутствующих заболеваниях, ходе лечения и т. д.
Сейчас платформа используется только внутри Сеченовского Университета, но в будущем она обещает и более эффективное сотрудничество с другими вузами — с её помощью можно будет обмениваться структурированными массивами данных по заболеваниям с определёнными проявлениями. В результате можно получить более точный прогноз, как будет протекать заболевание, и выявить более эффективные методы терапии. На основе накопленных данных в дальнейшем также можно будет разработать решения на основе искусственного интеллекта для улучшения качества диагностики и лечения.
Важные требования на старте проекта
Платформу решили создавать на базе облачной инфраструктуры Yandex Cloud. Поскольку проект довольно специфический и непростой, к работе также решили привлечь партнёра с подходящей специализацией. В результате конкурса мы выбрали компанию Beltel Datanomics, которая фокусируется на технологиях искусственного интеллекта и аналитике Big Data.
От Yandex Cloud к работе подключились специалисты с опытом в сфере здравоохранения и помогли Beltel Datanomics освоиться в предметной области. Нужно отдать должное партнёру, им пришлось изучить очень много информации про форматы и стандарты медицинсĸих данных.
После анализа требований к новой платформе появился список необходимых функций. Новое решение должно:
-
упростить процесс получения данных из нескольких систем‑источниĸов: МИС, радиологической ИС, лабораторной ИС и др.
-
управлять правами пользователей;
-
дать возможность просматривать исследования (КТ, МРТ, рентген) и выгружать их;
-
позволить искать информацию не тольĸо по тем данным, ĸоторые есть в виде полей в БД МИС, но и по сведениям в медицинских доĸументах: выписках, рентгеновских исследованиях и УЗИ, протоколах операций — с помощью простого теĸстового поисĸа в разных семантичесĸих формах;
-
получать данные автоматичесĸи не реже, чем раз в сутĸи, а лучше в реальном времени;
-
сохранять версии поисĸовых запросов и давать возможность быстро получить по ним выборĸи данных;
-
на следующих этапах дать возможность работы с любыми типами данных (табличные, теĸстовые, изображения, DICOM, видео, ЭКГ и др.);
-
в дальнейшем — автоматически передавать полученные выборĸи на следующие этапы процесса (анализ данных, разметĸа данных, обучение моделей).
Сначала покажу, как оно устроено, а затем перейду к особенностям работы с ним.
Архитектура решения
Партнёр совместно со специалистами Сеченовского университета и Yandex Cloud описал видение архитеĸтуры для первой версии системы. Для стартового этапа команда реализовала небольшой функциональный блок, чтобы проверить, как работает выбранное архитектурное решение.
Архитектура платформы — это по сути набор слоёв, выполняющих различные задачи:
-
слой загрузки и трансформации данных (ETL/ELT);
-
слой хранения и обработки данных;
-
слой доступа к данным.
Слои хранения данных представлены разными типами данных:
-
«сырые» данные из систем‑источниĸов;
-
единая модель данных на основе очищенных и обогащённых первичных данных;
-
витрины данных предметных областей, где единая модель представлена в удобном виде для дальнейшего использования посетителями сайтов.
Платформа должна помочь выстроить единый путь данных, от их извлечения и преобразования до предоставления удобного интерфейса работы. В состав решения также входят инструменты для работы различных групп пользователей: администраторов и исследователей — а также интеграционные механизмы. Пройдёмся по этим составляющим.
Источник первичных данных. МИС «1С: Медицина» — это не только источник данных, но и система‑посредник между платформой и другими информационными системами, например, радиологической ИС (РИС). Рентгеновские снимки самые объёмные, поэтому в МИС они хранятся только в виде ссылки. При помощи этих ссылок можно точно сверить конкретные данные о радиологическом исследовании с направлением или кейсом лечения.
Передача данных. Саму платформу разместили в сервисах Yandex Cloud. Было важно, чтобы в облаке данные о пациентах были уже в деперсонализированном виде, и по ним нельзя было определить конкретного пациента. Поэтому много внимания уделили процессу безопасной передачи данных.
Обезличивание всех документов и записей происходит на сервере 1С. Через защищённый канал связи данные поступают в разработанный для проекта сервис Data Refresh Service на основе FastAPI. Cервис принимает данные в формате JSON для дальнейшей валидации, типизации, загрузки в хранилища и логирования всех загрузок. По стандарту Минздрава, электронные медицинские документы хранятся в XML, но JSON даёт больше возможностей и удобнее для работы, например, он позволяет применять запросы Yandex Query поверх объектного хранилища. Поэтому структура электронного медицинского документа выдерживается по стандарту, а сам формат преобразуется.
Таким способом передаются:
-
Обезличенная информация о пациенте: только пол и возраст;
-
Медицинские карты;
-
Данные госпитализации;
-
Данные выписки;
-
Информация об оперативных вмешательствах.
«Сырое» хранилище. Для хранения данных из исходных информационных систем, которые ещё не преобразованы к единой модели и не направлены в аналитическое хранилище, предназначено объектное хранилище Yandex Object Storage. Это большой исторический архив данных, к которым всегда можно вернуться и запустить поиск на всю глубину хранения.
Безопасное хранение и подготовка данных для поиска. Из объектного хранилища данные поступают в аналитическое ядро (DWH) на базе Yandex Managed PostgreSQL. Данные имеют и реляционную структуру, и документоориентированную. Поэтому архитекторы остановили свой выбор на PostgreSQL как СУБД для работы с реляционными данными, которая также позволяет создавать ORM‑модели в рамках используемого стека FastAPI + SQL и удобна для масштабирования.
К хранилищу подключен полнотекстовый поиск на базе Yandex Managed OpenSearch. Синхронизация данных между хранилищем и системой поиска происходит через Yandex Managed Service for Redis, который выполняет роль своеобразного буфера, чтобы в случае проблем с сетью часть данных не потерялась.
Для защищённой аутентификации используется университетский сервис Sechenov ID. Поисковые запросы поступают на фронтенд, трафик от пользователей проходит через Security Groups, для предотвращения несанкционированного доступа. А уже бэкенд системы взаимодействует с DWH и поисковым ядром.
Пользовательские интерфейсы. В системе есть две основных группы ролей:
1) Администраторы, которые отвечают за управление доступом с помощью SechenovID;
2) Исследователи Сеченовского Университета, для которых настроены права:
-
на выгрузку данных из системы с учетом персональных фильтров;
-
на выгрузку данных из системы по шаблону;
-
на просмотр и повторную выгрузку предварительных запросов.
В веб‑интерфейсе сотрудники видят фильтр по 120 параметрам, где также можно сохранить шаблон поиска — свой собственный набор критериев для формирования выборки. Результат поиска выводится в табличном виде, его также можно выгрузить и преобразовать в другие форматы:
Обновление. Справочники обновляются из внешних источников с помощью облачных функций Yandex Cloud Functions. Для электронных медицинских карт пока нет строгого регламента обновления, его сценарий настроен на ежедневный запуск по расписанию. Миграция данных при обновлении обеспечивается сервисом Yandex Data Transfer.
Для деплоя и хранения кода используется Yandex Managed Service for Gitlab и Gitlab Runner.
Это все основные детали внутреннего устройства, но гораздо интереснее то, с какими трудностями мы столкнулись при реализации нужных нам сценариев работы.
Сложности при запуске проекта
Основная проблема заключалась в том, что в МИС не была предусмотрена типизация входящих данных. Параметры электронных медицинских карт были унифицированы, но структура данных и их объём были уникальными. Какие конкретно тут были трудности:
-
Системы‑источниĸи очень динамично развиваются. Например, в электронных картах за 5 лет мог полностью поменяться состав полей и вложенных документов. Скажем, если сегодня ĸод МКБ-10 указывается в табличном виде, то пять лет назад он мог быть просто уĸазан теĸстом в ĸомментарии.
-
Формат вложенных в карту элеĸтронных медицинсĸих доĸументов также не установился и может меняться.
-
Соответственно, ĸультура работы пользователей с системами‑источниĸами выстраивается до сих пор. Врачам приходится регулярно переучиваться заполнять всё по‑новому с появлением новых полей.
-
При этом ĸаждая система‑источниĸ может иметь свой ĸонтеĸст. Например, поле «Направление» в МИС заполняется врачом, если он направил пациента на обследование. А в радиологической ИС «Направление» означает: пациент направлен на аппарат или в ĸонĸретный ĸабинет.
Перед командой стояла задача — структурировать и организовать реляционную модель хранения данных, чтобы они были доступнее для обработки поисковых запросов.
Проблемы вызвала структура запросов пользователей для формирования датасетов из аналитической платформы — она была сложной, с разным количеством медицинских параметров поиска. Для запросов к хранилищу разработчики использовали язык запросов GraphQL и организовали взаимодействие по принципам RESTful (representational state transfer).
Работу по UX/UI усложняло большое количество возможных фильтров: 150 поисковых параметров и 109 лабораторных исследований, суммарно с 1700 лабораторными параметрами. Поэтому Beltel Datanomics детально прорабатывали дизайн системы совместно со специалистами Сеченовского Университета.
Немного цифр на этом этапе
Систему разрабатывали полгода, ещё месяц потребовался на её тестирование и развёртывание в инфраструктуре Yandex Cloud.
Сейчас платформа работает в режиме опытной эксплуатации. Обучение прошли 30 сотрудников — заведующих и доцентов кафедр. Это люди, которые раньше собирали клинические данные вручную, и сейчас могут предлагать доработки для системы.
В ходе тестирования мы намеренно нагружали платформу и создавали большой датасет. Система выгружает объёмные данные в среднем не более 10–12 секунд, ранее аспиранту или ординатору нужно было несколько месяцев, чтобы собрать такие данные.
Сейчас на платформе есть данные о нескольких миллионах пациентов с диагнозами, обработано более 18 млн медицинских документов и 50 справочников. Это выписки, рентгеновские исследования, УЗИ, протоколы операций, протоколы родов и т. п. Объём хранения сырых данных только с июля 2019 года в Yandex Object Storage составляет 200 Гб, в базе данных PostgreSQL — 100 Гб.
Данные в системе хранятся таким образом, что названия параметров поиска в пользовательском интерфейсе соответствуют названиям в МИС 1С и имеют чёткое сопоставление. Например: анамнез, заключение врача‑терапевта, а также пол, возраст, индивидуальный номер.
При этом платформа не хранит в себе объёмные файлы, такие как рентгеновские исследования в формате DICOM, поскольку их размещение в хранилище очищенных данных замедляло бы работу системы. Такие изображения по‑прежнему хранятся в системе в виде ссылок и доступны в режиме предпросмотра, а оригиналы остаются на сервере радиологической информационной системы Сеченовского Университета.
Что дальше
Сейчас основной приоритет — это первичная математическая обработка и визуализация данных.
Для этого планируем подключить сервис анализа и визуализации данных Yandex DataLens. Следующим этапом с использованием накопленных данных мы сможем продолжить разработки на основе технологий машинного обучения и постепенно преобразовать платформу в полноценную систему поддержки принятия решений, где будет возможность более точно прогнозировать развитие болезни с опорой на данные.
С инфраструктурной точки зрения мы предполагаем через некоторое время масштабировать платформу: подключить новые источники данных, обработку данных в режиме, близком к реальному времени, использование MDM, управление данными на основе метаданных.
На уровне интерфейса мы добавили подсказки, чтобы можно было быстрее выбрать нужные параметры поиска и сделать поисковый путь более простым. В 2025 году также планируем передавать полученные выборĸи на следующие этапы процесса обработки (анализ данных, разметĸа данных, обучение моделей).
Благодаря нашему проекту мы сможем использовать настоящие, живые клинические данные для обучения моделей машинного обучения и создания на этой базе новых «умных» продуктов. Параллельно будем развивать модуль для полного цикла работы с датасетами, где можно разметить наборы данных для машинного обучения, выстроить их хранение с учётом версионности и необходимости контроля доступа.
Сейчас мы уделяем много внимания выстраиванию правильной ролевой модели для доступа к данным внутренних пользователей Сеченовского Университета и следим, чтобы инструменты для работы с этими данными были как удобными, так и безопасными. После решения всех вопросов защищённого доступа для партнёрских проектов также будет создан портал с датасетами и кратким описанием клинической задачи, аннотацией, количеством пациентов, показателями. Это позволит нам подключать на паритетной основе к нашей систем и другие университеты, объединив датасеты и тем самым создать более масштабные наборы данных.
Автор: k_brazhnikov
