Интеграция с МИС: Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС и другие

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

Кратко

В России нет единого API, который каждая медицинская информационная система (МИС) обязана открывать сторонним приложениям. Общий обязательный язык есть – структурированные электронные медицинские документы (СЭМД) на базе HL7 CDA R2 и справочники НСИ Минздрава, – но он нужен для обмена с ЕГИСЗ, а не с вашим телемед-продуктом. Поэтому каждая МИС – отдельный проект: Медиалог в частных сетях, 1С:Медицина с поддержкой HL7 v2 и v3, государственные ЕЦП.МИС и ЕМИАС, MEDODS, Renovatio, Инфоклиника и другие. Для каждой нужны документация и тестовый стенд, договор с разработчиком, доработка и приёмка, затем подключение у каждой клиники. Если у клиентов много разных МИС, интеграционная шина вроде МедФлекс (заявляет 152 интегрированные МИС) даёт один API ко многим системам, а платформа N3.Health работает по HL7 FHIR и передаёт протоколы телемедицинских консультаций в ЕГИСЗ. Публичная документация API есть не у всех разработчиков, и это нужно проверить до того, как вы назовёте срок. На любом пути правило одно: до первых реальных данных пациентов – поручение на обработку персональных данных с каждым звеном цепочки и хранение в России. Статья продолжает разбор стандартов из материала HL7 FHIR, СЭМД и интеграция с МИС на практике.

Зачем это читать

Фразу «мы интегрируемся с МИС» в российском медтехе произносят часто, но смысл в неё вкладывают разный. МИС – система, где хранятся расписание, записи врача, назначения, услуги и результаты, и это не один коннектор, который достаточно включить. У каждого разработчика своя политика доступа, свой формат обмена, свои партнёры и свой порядок подключения, а у каждой клиники – своя версия и свои справочники. Статья написана для основателя, продакт-менеджера или ИТ-руководителя клиники, которому сказали, что интеграция с МИС – «просто вызов API», и которому нужно честно оценить её до того, как обещать клиенту срок. Если понимать, как устроен доступ у разработчиков МИС, срок получится реалистичным. Если нет, уже после подписания договора выяснится, что за двумя неделями кода стоят семь недель согласований. Здесь подробно разобрана одна из связей на карте интеграций телемед-платформы – связь с МИС.

Общий формат, разный доступ

Начнём с хорошей новости. Медицинские организации государственной, муниципальной и частной систем здравоохранения – поставщики сведений в ЕГИСЗ, единую государственную информационную систему в сфере здравоохранения (п. 44 «к» Положения о ЕГИСЗ, ПП № 140). Для частной клиники это ещё и лицензионное требование (ПП № 852, п. 6 «е»), а Минздрав в письме от 23.08.2023 подтвердил: передавать документы в реестр электронных медицинских документов (РЭМД) частные клиники обязаны за свой счёт. Сведения о документе уходят в РЭМД в течение одного рабочего дня со дня его формирования, а сам документ оформляется как СЭМД – XML на базе HL7 CDA R2 уровня 3. Коды болезней, услуг, специальностей берутся из нормативно-справочной информации (НСИ) Минздрава, у которой есть REST API.

Поэтому МИС российских клиник, как правило, умеют собирать СЭМД и работать со справочниками НСИ. Если вы написали код сборки СЭМД по статье о стандартах, он переносится от клиники к клинике. Есть и второй общий язык – HL7 FHIR: на нём работает платформа обмена N3.Health, а сообщество HL7 FHIR Россия развивает национальный профиль RuCore (на FHIR R5) и Ru-SEMD.

Но есть ограничение, ради которого и написана статья: обязательный общий язык работает только в направлении «клиника → государство». Для направления «стороннее приложение ↔ МИС клиники» единого обязательного API нет: каждый разработчик МИС сам решает, открывать ли интерфейс, в каком формате и на каких условиях. Формат СЭМД у всех один, а право читать и писать записи в конкретной МИС каждый раз приходится получать отдельно. На этом телемед-проекты и срывают сроки, поэтому дальше разберём системы по очереди.

Почему каждая МИС – отдельный проект

Прежде чем переходить к конкретным системам, разберём общую схему: зная её, можно оценить любую МИС. Подключение к каждой проходит одни и те же четыре стадии.

Стадия первая – документация и тестовый стенд. Вы изучаете интерфейс и собираете интеграцию на синтетических данных – на тестовой базе разработчика или клиники. Публичной песочницы, куда можно зайти без договора, у большинства российских МИС нет или мы её не нашли; чаще стенд и документацию выдают по запросу, иногда под соглашение о неразглашении. Данные ненастоящие, поэтому медданные на этой стадии не обрабатываются и поручение на обработку ещё не нужно. (Напомним: поручение – условия договора, по которым клиника-оператор разрешает подрядчику обрабатывать персональные данные пациентов, ст. 6 ч. 3 152-ФЗ; к нему мы вернёмся ниже.)

Стадия вторая – договор с разработчиком МИС. Вы договариваетесь о доступе: технологическое партнёрство, лицензия на модуль обмена у клиники, работа через партнёра-внедренца. Здесь же согласуются требования безопасности – как ваша система аутентифицируется, где хранит данные, кто отвечает за инциденты. Эта стадия – в основном ожидание, а не код.

Стадия третья – доработка и приёмка. Вы сопоставляете свои сущности со справочниками МИС и НСИ: врачи, услуги, кабинеты, слоты расписания, коды документов. У коробочных систем это иногда означает доработку конфигурации на стороне клиники или её внедренца. Затем – приёмочные испытания.

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

Эта схема (стенд, договор, доработка и приёмка, подключение у каждой клиники) повторяется для всех систем, о которых пойдёт речь ниже.

Нажмите, чтобы увеличить

Медиалог: частные сети и обмен с ЕГИСЗ через N3.Health

Медиалог – система, которую вы, скорее всего, встретите в частных многопрофильных сетях. Разработчик заявляет более 1 000 медицинских учреждений; среди клиентов – Медси и «Мать и дитя». С ноября 2024 года компания-разработчик находится под контролем Ростелекома и входит в его кластер «Ростелеком Здоровье». С первого полугодия 2026 года внедряется новая версия – Медиалог 2.0, которая, по словам разработчика, наследует функциональность предыдущей.

Что это значит для интеграции. Во-первых, у Медиалога есть опыт внешних связей: на сайте названы интеграции с сервисами ПроДокторов и НаПоправку, а передача данных в ЕГИСЗ идёт через платформу N3.Health. Для взаимодействия с внешними системами разработчик предлагает собственную платформу интеграционных решений. Публичной документации API для сторонних разработчиков на сайте мы не нашли, поэтому условия доступа – вопрос к разработчику на стадии договора. Во-вторых, переход на версию 2.0 означает, что в ближайшие годы у ваших клиентов будут стоять две версии; спрашивайте, какая у конкретной клиники, и закладывайте поддержку обеих. В-третьих, у Медиалога есть собственный личный кабинет пациента «Мобимед» с телемедициной – уточните заранее, не решает ли он ту задачу, ради которой клиника обращается к вам, и как ваш продукт будет с ним уживаться.

1С:Медицина: стандарты из коробки и партнёрская сеть

Вторая система, которую вы встретите, – 1С:Медицина, линейка отраслевых решений на платформе «1С:Предприятие»: Поликлиника, Больница, Стоматология, Клиническая лаборатория и Регион. В отличие от многих систем, разработчик прямо перечисляет поддерживаемые стандарты обмена: HL7 v2, HL7 v3, DICOM 3 и интеграцию с ЕГИСЗ. Для телемед-продукта это хорошая новость: часть событий – запись, приём, результаты – потенциально можно получать сообщениями HL7 v2, формат которых разобран в статье о стандартах, а не через закрытый проприетарный протокол.

Отличительная черта 1С – модель внедрения. Типовые конфигурации 1С, как правило, внедряют и сопровождают партнёры, и у конкретной клиники конфигурация может быть доработана. Поэтому вопрос «как интегрироваться с 1С:Медициной» на практике распадается на три: какая линейка и версия у клиники, кто сопровождает её конфигурацию и какие механизмы обмена в ней включены. Стадии те же – стенд, договор, доработка, подключение, – но доработку часто делает партнёр клиники, и его график становится вашим.

ЕЦП.МИС и ЕМИАС: государственные контуры

Третья группа – государственные системы, и здесь логика другая. ЕЦП.МИС (разработчик – РТ МИС) работает в 29 регионах примерно в 2,8 тыс. медицинских организаций и включает модуль «Дистанционный мониторинг». ЕМИАС – единая медицинская информационно-аналитическая система Москвы; её сервис «Дневник здоровья» принимает данные с умных устройств. Среди других региональных систем – «Цифромед» Ростелекома и РМИС «Медведь».

Владелец такой системы – не разработчик, а регион как заказчик, и маркетплейса приложений здесь нет. Коммерческий телемед-продукт попадает в государственный контур только через проект с регионом: закупку, согласование архитектуры, требования к защите государственных информационных систем – с 1 марта 2026 года это приказ ФСТЭК № 117 вместо № 17. Поэтому интеграция с ЕЦП.МИС или ЕМИАС – отдельная продажа со своим циклом, в спринт она не помещается. Если ваши клиенты – государственные поликлиники, планируйте её как бизнес-задачу. Подробнее о требованиях к защите – в статье о требованиях к защите ПДн в 2026 году.

Нажмите, чтобы увеличить

Остальные: десятки частных МИС

Кроме крупных систем, есть MEDODS, Renovatio, Инфоклиника, qMS, ArchiMed+, Medesk и множество более мелких и специализированных, особенно в стоматологии и узких специальностях. У части из них заявлена интеграция по API – например, у MEDODS, – но наличие публичной документации и условия доступа для сторонних разработчиков мы по каждой системе не подтвердили. Поэтому не обещайте клиенту интеграцию с МИС, пока не увидели её документацию и не получили доступ к стенду.

Открытых данных о долях рынка МИС мы не нашли, но масштаб виден по шинам: МедФлекс заявляет 152 интегрированные МИС, N3.Health – сотрудничество с более чем 150 МИС и лабораторными системами. Задача «поддержать все МИС наших клиентов» в России означает десятки систем, а не четыре. Остаётся решить, интегрироваться ли даже с крупнейшими напрямую или охватить многие одним подключением через шину.

Путь через шину: одно подключение ко многим МИС

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

МедФлекс (проект платформы МедРокет) – самая заметная коммерческая шина для частных клиник. Она описывает себя как защищённую платформу передачи данных между клиниками, онлайн-сервисами и страховыми компаниями и устроена по схеме «звезда»: ваше приложение обращается к API МедФлекс (портал разработчика – developer.medflex.ru), а шина поддерживает подключения к МИС. МедФлекс заявляет более 24 тыс. подключённых клиник и 152 интегрированные МИС; среди функций – онлайн-запись и её отмена, запись на услуги, выгрузка прайс-листов и отправка документов в РЭМД; через неё же записывают пациентов страховщики ДМС. Обратите внимание на состав функций: шина сильна в записи и расписании, а чтение и запись клинических данных конкретной медкарты нужно проверять по документации под ваш сценарий. Запись разобрана отдельно в статье об интеграции расписания и календаря.

У N3.Health (группа «Нетрика») похожая, но другая роль. Это облачная платформа обмена медданными между частной медициной и государственными системами, работающая по HL7 FHIR: интегрированная электронная медкарта (ИЭМК), лабораторные данные, телемедицинские консультации с передачей протокола в РЭМД, онлайн-запись и рецепты; группа участвовала в создании региональных систем здравоохранения в 22 регионах. Различие важно: шина вроде МедФлекс связывает вас с конкретными МИС ваших клиентов, а платформа вроде N3.Health – с контуром обмена между организациями и с ЕГИСЗ. Для телемед-продукта, которому нужно передать протокол консультации в ЕГИСЗ в течение одного рабочего дня, это принципиально другая возможность. Условия подключения сторонней платформы определяют оператор и регион.

Есть и третий вариант – подключить саму платформу к ЕГИСЗ как «иную информационную систему». Это отдельная процедура через Минздрав (по ПП № 447 от 12.04.2018: заявка, включение в перечень, подключение к ЕСИА); её актуальность и сроки на 2026 год уточняйте до старта, а пока исходите из того, что для большинства продуктов быстрее идти через МИС клиники или N3.Health.

Нажмите, чтобы увеличить

Правило, общее для всех путей

Какой бы путь вы ни выбрали, одно правило не меняется, и о нём часто забывают. Ваша платформа, облачная МИС (если её размещает у себя разработчик), интегратор и любая шина на пути обрабатывают медданные – персональные данные о здоровье, специальную категорию по ст. 10 152-ФЗ, и сведения, составляющие врачебную тайну. Поэтому каждое звено должно работать по поручению клиники-оператора (ст. 6 ч. 3 152-ФЗ), и оформить его нужно до передачи первых реальных данных. Закон не описывает «субпоручение» отдельной нормой, поэтому цепочку строят договорами: клиника разрешает привлечь конкретных подрядчиков, а условия поручения распространяются на каждого из них. Без этого обмен данными – обработка без законного основания, как бы хорошо ни было зашифровано соединение. Шифрование и законность – разные требования, и выполнить нужно оба.

Второе условие – территория: базы шины, интегратора и вашей платформы, где лежат медданные, должны находиться в России (ст. 18 ч. 5 152-ФЗ, с 1 июля 2025 года). Проверяйте это у каждого звена так же, как наличие API.

Граница здесь чёткая: стенд работает на синтетических данных и не требует поручения, поэтому разработку можно начинать сразу. К переходу на реальные данные пациентов, то есть к подключению у клиники, поручение должно быть подписано – и с вами, и с любой шиной между вами и МИС. Шина не отменяет поручение, а добавляет в цепочку ещё одно звено. Сам договор разобран в статье о поручении обработки ПДн и договорах с подрядчиками, а нормы, на которых он основан, – в материале 152-ФЗ и врачебная тайна простым языком.

Расчёт на примере: время

Посчитаем реалистичный сценарий: телемед-продукт должен записывать пациентов в расписание врача и возвращать в МИС заключение консультации, а у трёх клиентов три разные МИС.

Начнём с одной МИС. Если документация и стенд уже есть, кода обмена немного – скажем, две инженер-недели. Теперь добавим то, от чего стандарт не избавляет. Получение стенда и изучение особенностей системы: одна неделя (если стенда нет, дольше). Сопоставление со справочниками клиники и НСИ: одна неделя. Договор с разработчиком и согласование требований безопасности: 2–4 недели, в основном ожидание. Первое подключение у клиники с её ИТ-подрядчиком: 1–3 недели. Берём середины диапазонов:

2 (код) + 1 (стенд) + 1 (справочники) + 3 (договор) + 2 (подключение) = 9 инженер-недель

Только две из этих девяти недель – код, остальные семь – организационная работа. Теперь умножим на три МИС. Код не утраивается – логика записи и выгрузки заключения общая, – но накладные расходы на стенд, договор и подключение утраиваются, потому что каждый разработчик допускает вас отдельно:

3 МИС × ~7 недель процесса = ~21 неделя процесса
+ ~3 недели общего кода (общая логика, отличия по системам) = ~24 инженер-недели

Около полугода работы на три прямые интеграции, и большая часть уходит на согласования. Теперь сравним с шиной. Интеграция с шиной – одно подключение вместо трёх. Заложим те же ~9 недель на первое, но дальше новые МИС, если они есть в списке шины и она поддерживает нужные вам функции, подключаются настройкой, без новых проектов. Цена – плата шине по её тарифам и лишний посредник; взамен вы экономите ~15 инженер-недель (≈ 24 против ≈ 9), почти все – на согласованиях. Ориентир такой: одна-две МИС – интегрируйтесь напрямую; три и больше – считайте вариант с шиной, потому что с каждой новой системой умножаются согласования, а не код. Подставьте своё число систем – структура расчёта останется той же. Полное сравнение вариантов «напрямую – шина – встраивание» – в гиде по решению об интеграции.

Нажмите, чтобы увеличить

Частая ошибка

Самая дорогая ошибка – оценить интеграцию с МИС в «две недели», потому что столько занимает код обмена. Код – наименьшая часть. Стенд, справочники, договор с разработчиком и подключение у каждой клиники – это остальные семь недель на систему, и они в основном вне вашего контроля: вы ждёте ответа разработчика, партнёра-внедренца и ИТ-службы клиники. Оценивайте весь процесс, а не только протокол обмена, иначе срок будет сорван.

Вторая ошибка, близкая к первой, – считать, что фраза «у нас есть API» от разработчика МИС или шины закрывает вопрос. Она ничего не говорит о том, открыты ли нужные вам операции, в какой версии, есть ли право записи там, где вам нужно писать. Шина может отлично записывать на приём и не отдавать медкарту; МИС может принимать заключение только как СЭМД определённого вида. Сверьте точный список операций с документацией до того, как назовёте срок. И заранее проверьте договорную сторону: если при подключении выяснится, что шина хранит данные не в России или не готова принять условия поручения, запуск сорвётся.

Где здесь Фора Софт

Фора Софт с 2005 года разрабатывает системы видеосвязи в реальном времени и клиническое ПО. В телемедицине сроки чаще всего срываются именно на подключении к МИС, поэтому с первого дня мы планируем его как отдельный проект и закладываем время на согласования, а не только на код. Сначала обязательное: поручение с каждым звеном цепочки и хранение в России до первых реальных данных, СЭМД и справочники НСИ по текущим версиям Минздрава, осознанно выбранный путь интеграции – напрямую для одной-двух МИС, шина или платформа обмена, когда клиентов много или нужен обмен с ЕГИСЗ. Потом функции: видеоконсультация, которая записывает пациента в расписание, видит нужное из медкарты и возвращает подписанное заключение в МИС клиники – в Медиалог, 1С:Медицину или любую другую систему, – без потерь данных и сдвигов сроков.

Главное

• Обязательный общий язык – СЭМД на HL7 CDA R2 и НСИ – обращён к ЕГИСЗ; единого обязательного API для сторонних приложений у МИС нет.
• Каждая МИС проходит те же четыре стадии: стенд, договор, доработка и приёмка, подключение у клиники.
• Медиалог – частные сети и обмен с ЕГИСЗ через N3.Health; 1С:Медицина – HL7 v2/v3 и партнёры; ЕЦП.МИС и ЕМИАС – проект с регионом.
• Публичная документация API есть не у всех: не обещайте интеграцию, пока не увидели документацию и стенд.
• Шины (МедФлекс, N3.Health) за регулярную плату дают один API ко многим системам – сверяйте состав функций.
• Каждому звену нужно поручение и хранение в России до передачи реальных медданных.

Что читать дальше

• HL7 FHIR, СЭМД и интеграция с МИС на практике
• Гид по решению об интеграции: напрямую, через агрегатор или iframe
• Карта интеграций телемед-платформы: что с чем соединяется