Гид по решению об интеграции: напрямую, через агрегатор или iframe

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

Кратко

Подключить телемед-продукт к медицинской информационной системе (МИС) клиники можно четырьмя способами, и неверный выбор – самая дорогая ошибка во всём проекте интеграции. Можно построить прямое соединение «точка – точка» с API каждой МИС по договору с её разработчиком; подключиться к интеграционной шине (агрегатору) вроде N3.Health или МедФлекс, которая поддерживает соединения за вас и даёт один API; встроить приложение внутрь интерфейса МИС (в iframe или виджет), чтобы врач не уходил из карты; либо остаться standalone и обойтись без живой интеграции с чужими МИС. Ответ дают четыре вопроса (сколько разных МИС, кто пользователь, нужно чтение, запись или государственный контур и какую регулярную плату вы готовы нести) и одно неизменное правило: любой путь с реальными данными пациента требует договорного основания (поручения обработки по ст. 6 152-ФЗ) и баз в России ещё до старта. Особняком стоит обязательный поток в ЕГИСЗ: его не выбирают, его обеспечивают на любом пути. Это завершающая статья блока об интеграциях; она рассчитана на читателя, который уже знаком с картой интеграций телемед-платформы и хочет получить само решение, а не перечень вариантов.

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

Путь интеграции выбирают рано, а живёт он годами: чтобы его поменять, придётся переписать весь слой соединений продукта. Выберете «напрямую» там, где нужна была шина, – потратите полгода, подключая МИС по одной. Выберете шину там, где хватило бы одной прямой интеграции, – будете постоянно платить за ненужный слой. Статья написана для основателя, продакт-менеджера или техлида, который уже изучил детали – стандарты HL7 FHIR и СЭМД, особенности конкретных МИС – и теперь должен выбрать одну схему. Удачный выбор совпадёт со списком клиентов и дорожной картой, неудачный будет мешать и тому и другому. Цель – превратить расплывчатое «как нам интегрироваться?» в решение со сроками, которое можно защитить перед клиентом.

Единой точки подключения нет: почему стандарт – ещё не решение

Начнём с того, что выбор не определяет: это снимает частую путаницу. У российских МИС нет единой обязательной программной точки подключения для сторонних приложений. Общий обязательный язык есть только «вверх», в государственный контур: медорганизации, в том числе частные, передают в ЕГИСЗ структурированные электронные медицинские документы (СЭМД, XML на базе HL7 CDA R2), сведения о документах регистрируются в РЭМД, а запрос на телемедицинскую консультацию и её протокол уходят в ФЭР – в течение одного рабочего дня [1][2][3]. «Вбок», к вашему приложению, каждая МИС открывается по-своему: собственный API по договору с разработчиком, интеграционная шина, файловый обмен.

FHIR в России есть: на нём работает платформа обмена N3.Health, а сообщество HL7 FHIR Россия развивает профиль RuCore [4][5]. Но это выбор отдельных платформ, а не обязанность МИС. Поэтому решение об интеграции не сводится к протоколу: фраза «мы поддерживаем FHIR» сама по себе не открывает доступ ни к одной МИС. Решают доступ и доставка: с кем у вас договор, кто поддерживает соединения и где физически работает ваше приложение. Четыре варианта ответа – ниже.

Путь 1 – Напрямую: каждое соединение строите и сопровождаете вы

Прямая интеграция – соединение «точка – точка», которое ваша команда строит к API каждой МИС. Вы договариваетесь с разработчиком (Медиалога, 1С:Медицины, MEDODS, Renovatio, Инфоклиники и так далее), получаете тестовый стенд и документацию, проходите согласование требований безопасности и запускаете интеграцию в каждой клинике, потому что каждая инсталляция настроена по-своему: свои справочники услуг, врачей, кабинетов и расписаний. У государственных систем – ЕЦП.МИС в регионах, ЕМИАС в Москве – условия подключения определяет региональный оператор, и коммерческий продукт попадает туда только через проект с регионом. Разбор по системам – в статье Интеграция с МИС: Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС и другие.

Прямой путь даёт максимум контроля и самый глубокий доступ. Вы получаете ровно те данные и операции, которые нужны, сами ведёте отношения с разработчиком, и между вами и картой нет третьей стороны. Цена – каждая МИС превращается в отдельный проект: договор, стенд, сопоставление справочников, согласование безопасности и запуск в клинике. Как показано в статье о HL7 FHIR, СЭМД и интеграции с МИС, на код уходит примерно две из девяти недель на одну МИС, остальные семь – процесс, и именно процесс умножается с каждой новой системой. Прямой путь верен, когда вы обслуживаете одну-две МИС и хотите максимум контроля; типичный случай – продукт для одной крупной сети клиник.

Путь 2 – Шина: соединения поддерживает кто-то другой

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

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

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

Путь 3 – Встроенно (iframe или виджет): приложение работает внутри МИС

Третий путь отличается принципиально. Ваше приложение не обращается к МИС снаружи, а работает внутри её интерфейса, в привычном рабочем процессе врача. Врач открывает карту пациента или запись в расписании, нажимает кнопку вашего модуля, и модуль появляется в панели, обычно в iframe (веб-странице, встроенной в другую) или во встроенном виджете, не уводя врача из карты. Единого механизма запуска внешних приложений у российских МИС нет: от кнопки со ссылкой до встроенного виджета, и параметры согласуют с разработчиком каждой системы.

Образец, который стоит повторить, – международный стандарт. SMART on FHIR – слой авторизации поверх OAuth 2.0 – определяет два способа запуска. При standalone launch пользователь открывает приложение вне медкарты (иконка, ссылка, портал пациента), и приложение само запрашивает контекст у сервера авторизации. При EHR launch медкарта сама «открывает новый экземпляр браузера (или iframe)» по зарегистрированному адресу запуска приложения и передаёт контекст, так что приложение стартует, уже зная, какого пациента и какой приём смотрит врач [7]. Оба потока входят в один фреймворк SMART App Launch и заканчиваются выдачей токена доступа OAuth. Даже если МИС не поддерживает SMART, договоритесь о той же схеме: одноразовый код запуска вместо персональных данных в URL, обмен кода на короткоживущий токен на вашем бэкенде, контекст приёма и пациента, минимальные права.

Встраивание – верный выбор, когда пользователь – врач, который весь день работает в МИС и которому переключаться на другую вкладку слишком неудобно: окно видеоконсультации, панель ИИ-скрайба, виджет консультации специалиста. Цена в том, что вы подстраиваетесь под правила встраивания каждой МИС: заголовки безопасности встроенной страницы (Content-Security-Policy: frame-ancestors), сессия без опоры на сторонние cookie, которые часть браузеров блокирует, ограничения по размеру и стилям чужого интерфейса. Встраивание не отменяет обязательных требований телемедицины: пациент как участник консультации идентифицируется через ЕСИА, врач должен быть в ФРМР, а документы подписываются УКЭП [10][11]. И вам по-прежнему нужен доступ к данным по Пути 1 или 2: встраивание определяет только то, где появляется приложение, поверх выбранного пути данных.

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

Путь 4 – Standalone: без живой интеграции (пока)

Четвёртый вариант команды часто забывают рассмотреть: не интегрироваться с чужими МИС вовсе или до поры. Standalone-продукт ведёт собственное расписание, протоколы и карты пациентов, а с внешним миром обменивается данными простыми способами: пациент сам загружает выписки и результаты (получить свои медицинские документы, их копии и выписки, в том числе в электронной форме, он вправе по запросу – ст. 22 323-ФЗ [13]), ручной экспорт, обмен документами.

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

Standalone – верный выбор на раннем этапе, для продукта, работающего напрямую с потребителем, или когда у клиентов нет общей МИС. Сервису онлайн-психологов, который работает как ИТ-платформа, а не как медорганизация, интеграция с МИС может не понадобиться вовсе. Плюс – скорость: вы выходите на рынок, не дожидаясь договоров с разработчиками. Минус – данные не передаются автоматически, врачам приходится перепечатывать, и с ростом ручные разрывы становятся узким местом, которое подталкивает к Путям 1–3. Выбрать standalone осознанно и заранее записать условие, при котором вы от него откажетесь, – вполне разумное и часто верное решение.

Решение в четырёх вопросах

Если свести пути вместе, выбор сводится к четырём вопросам, которые задают по порядку.

Первый: сколько разных МИС нужно охватить? Сегодня ни одной – standalone (и свой путь в ЕГИСЗ, если вы медорганизация). Одну-две – напрямую. Три и более – считайте шину и сверьте её список подключённых МИС. Второй: кто пользователь и где он работает? Если это врач, который весь день в МИС, – встраивание. Если пациент дома или врач в вашем приложении – standalone либо прямой путь или шина с самостоятельным входом. Третий: нужно чтение, запись или государственный контур? Для чтения истории из других организаций подходят платформы обмена и ИЭМК; для структурированной записи в карту клиники – прямая или встроенная интеграция с согласованными правами на запись; документы в ЕГИСЗ отправляет тот, кто их формирует и подписывает: МИС клиники, региональная система или платформа с доступом к РЭМД. Четвёртый: какую регулярную плату вы готовы нести? Шина заменяет крупные разовые затраты на постоянную плату; прямой путь, наоборот, означает больше разовых затрат плюс собственную поддержку. Большинство реальных продуктов комбинируют пути: например, прямая встроенная интеграция с МИС сети клиник, которая даёт 60% выручки, плюс шина для множества небольших клиник.

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

Расчёт стоимости на примере

Решение стоит проверить цифрами. Возьмём телемед-продукт, который должен читать карту пациента до консультации и записывать протокол обратно после, и три разные МИС. Оценим два реальных пути.

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

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

Шина, одно соединение. Первое подключение занимает те же ~9 недель, а вторая и третья МИС добавляются настройкой, если они уже работают с шиной:

~9 недель до первого запуска
+ новые МИС = подключение и настройка (дни–недели, не месяцы)
+ регулярная плата шине по её тарифу, постоянно

Шина экономит примерно 15 инженер-недель разработки и избавляет от постоянной поддержки трёх соединений, а взамен вы платите сумму, которая растёт с объёмом использования. Для ориентира по деньгам: 15 недель – около 3,5 человеко-месяца, и при медиане middle-разработчика 178 тыс. ₽ в месяц на руки (Хабр Карьера, 2026) одна только зарплатная часть составит порядка 620 тыс. ₽ без налогов, взносов и накладных [15]; сравнивайте это с годовой платой шине по её тарифу. Граница проходит по правилу из статьи о стандартах: одну-две МИС подключайте напрямую, для трёх и более считайте шину, потому что умножаются накладные расходы на каждую систему, а не код. Встраивание добавляет слой интерфейса к любому выбранному пути; standalone избавляет от ожидания разработчиков ценой автоматического обмена данными. Подставьте своё число МИС и тариф шины – логика расчёта останется прежней.

Правило на любом пути: основание для медданных

Одно правило действует на любой ветке дерева, и о нём легко забыть. Каждая сторона, которая работает со сведениями о здоровье пациента (специальная категория персональных данных по ст. 10 152-ФЗ и врачебная тайна), должна получить основание до того, как через неё пройдёт хоть одно реальное поле. Для подрядчиков это поручение обработки от клиники-оператора по ст. 6 ч. 3 152-ФЗ: перечень данных и действий, цели, обязанность соблюдать конфиденциальность, требования к защите по ст. 19 и обязанность сообщать оператору об инцидентах [8][9]. На прямом пути это поручение вам и договор клиники с разработчиком облачной МИС. На пути шины в цепочку добавляется и сама шина: она становится ещё одним обработчиком. На встроенном пути действуют те же договоры, ведь приложение читает и пишет реальные медданные, даже если отображается внутри МИС. И на любом пути базы с данными граждан РФ должны находиться в России (ст. 18 ч. 5) [8]. Без лишнего звена иногда обходятся только standalone без чужих данных, работа на синтетике или обмен, полностью инициированный самим пациентом, и то лишь пока медданные не проходят через привлечённых вами третьих лиц.

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

Типичная ошибка

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

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

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

Фора Софт строит видеосвязь реального времени и клинический софт с 2005 года. Путь интеграции мы выбираем как архитектурное решение, исходя из списка клиентов, а не по умолчанию. Сначала требования: поручение на каждом звене, где есть медданные, до того как пойдут реальные данные, базы в России, путь в ЕГИСЗ выбран до первой строки кода, а сам путь интеграции – осознанно: напрямую для одной-двух МИС, шина вроде N3.Health или МедФлекс при длинном списке, встроенный запуск из МИС по образцу SMART on FHIR, когда врач весь день работает в МИС, и честный старт в режиме standalone, когда общей МИС ещё нет. Затем функции: видеоконсультация, которая читает карту до приёма и записывает протокол после, на пути, который соответствует тому, кто ваши клиенты и сколько их будет.

Главное

• Четыре пути: напрямую, через шину, встраивание (iframe или виджет в МИС), standalone; выбирайте по списку клиентов.
• Единой обязательной точки подключения у МИС нет: стандарт задаёт формат данных, а доступ открывает договор.
• Одна-две МИС – напрямую; три и более – считайте шину (N3.Health, МедФлекс) и сверьте её охват.
• Встраивание размещает приложение внутри МИС для врачей, которые в ней работают; ЕСИА, ФРМР и УКЭП остаются обязательными.
• Standalone – без чужих МИС, но не без ЕГИСЗ, если за продуктом стоит медорганизация.
• Любой путь с реальными медданными требует поручения и баз в России; шифрование этого не заменяет.

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

• Интеграция с МИС: Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС и другие
• HL7 FHIR, СЭМД и реальность интеграции с МИС
• Карта интеграций телемед-платформы: что с чем соединяется