«Ростелеком» выпустил первый релиз МИС «Медиалог 2.0»

22 июля 2026 года «Пост Модерн Текнолоджи», входящая в кластер «Ростелеком Здоровье», представила первый релиз медицинской информационной системы «Медиалог 2.0». Новая версия построена на микросервисной архитектуре, использует компоненты с открытым исходным кодом и предлагает модульную настройку процессов клиники.

По данным компании, предыдущая версия работает более чем в тысяче медицинских организаций и ежегодно поддерживает свыше 40 тысяч рабочих мест в России и странах СНГ. Такой масштаб делает переход на новую архитектуру не только продуктовым обновлением, но и задачей миграции для распределённых организаций с чувствительными данными и непрерывными процессами.

Что изменилось в архитектуре

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

«Медиалог 2.0» заявлен как модульная система, которую можно адаптировать под масштаб и специализацию организации. Сотрудники получают веб-интерфейс, а заказчики — встроенные инструменты для самостоятельной доработки функциональности. Платформа разработки «Пульсар», на которой создан продукт, включена в реестр отечественного ПО.

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

Почему модульность не равна простой миграции

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

Перед переходом организации нужен реестр:

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

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

Интеграции становятся частью надёжности

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

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

Что проверить при пилотном переходе

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

1. Перенос данных и контроль их полноты.
2. Работу ролей, включая временное замещение сотрудника.
3. Обмен со всеми системами маршрута.
4. Действия при дублировании и задержке сообщения.
5. Полноту аудита чтения и изменения данных.
6. Производительность в утренний или сменный пик.
7. Резервное копирование и восстановление.
8. Откат на согласованную точку при неуспешной миграции.

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

Безопасность медицинских данных

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

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

План резервирования следует проверять восстановлением, а не наличием копии. Подход к RPO, RTO и контрольным сценариям описан в статье о резервном копировании и отказоустойчивости.

Практический вывод

«Медиалог 2.0» отражает общий переход отраслевых корпоративных систем к модульным веб-платформам с открытыми интерфейсами. Это создаёт больше возможностей для интеграций и поэтапного развития.

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

Источник: официальный информационный сайт «Ростелекома».