Карта интеграций телемед-платформы: что с чем соединяется

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

Кратко

Телемед-платформа – это не приложение с видеозвонком внутри, а хаб, связанный ещё с десятком систем: медицинской информационной системой (МИС) клиники, государственным контуром ЕГИСЗ, ЕСИА и регистрами врачей, записью и агрегаторами, лабораториями, электронными рецептами, страховщиками ДМС, эквайрингом с онлайн-кассой и аналитикой. Каждая связь говорит на своём языке: API разработчика МИС, HL7 v2 и FHIR, СЭМД на базе HL7 CDA R2 с усиленной электронной подписью, вход через Госуслуги, чеки по 54-ФЗ. Большая часть стоимости, сроков и рисков для медданных приходится на эти соединения, а не на видео. Самое полезное, что можно сделать до разработки, – нарисовать карту: для каждой связи записать систему, стандарт, направление данных и то, проходят ли через неё сведения о здоровье. В статье – такая карта для российского рынка, места, где сосредоточен риск, и одностраничный чек-лист.

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

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

Платформа – это хаб, а не приложение

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

Два термина простыми словами. Медицинская информационная система (МИС) – основная система клиники, где хранятся записи врача, расписание, прейскурант, диагнозы и результаты. Это постоянная карта пациента, которая принадлежит клинике, а не вашему приложению. В России это Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС, MEDODS, Renovatio, Инфоклиника и другие. Медданные – сведения о здоровье конкретного человека: специальная категория персональных данных (ст. 10 152-ФЗ) и одновременно врачебная тайна (ст. 13 323-ФЗ), куда входит уже сам факт обращения за помощью [8][9]. Имя рядом с диагнозом, запись к конкретному врачу, результат анализа с номером пациента – всё это медданные.

Дальше всё измеряется медданными. Если они проходят через связь, у стороны на другом конце должно быть законное основание. Обычно это договор-поручение на обработку персональных данных с клиникой-оператором (ст. 6 ч. 3 152-ФЗ) плюс обязательство хранить врачебную тайну, а базы данных должны находиться в России (ст. 18 ч. 5) [8].

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

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

Клиническое ядро: МИС, запись и лаборатории

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

HL7 v2 – старшее поколение: формат сообщений, по которому клинические данные передаются между больничными системами с конца 1980-х. Он текстовый, с вертикальной чертой (|) в роли разделителя, надёжен для стабильного обмена «сервер – сервер», но неудобен для веба и мобильных приложений [10]. В России он встречается, в частности, там, где МИС обменивается данными с оборудованием и PACS: 1С:Медицина, например, заявляет взаимодействие по DICOM 3 и HL7 версии 2, а также поддержку форматов HL7 версии 3 [12]. FHIR (Fast Healthcare Interoperability Resources, читается «файр») – современный стандарт той же организации: веб-API, который отдаёт клинические данные в JSON по HTTPS [11]. На нём, например, работает платформа обмена медданными N3.Health [13].

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

На этом ядре держатся две соседние связи. Запись синхронизирует слоты врача, записи, переносы и отмены между платформой и расписанием МИС. Синхронизация двусторонняя: слот, занятый в одном месте, должен исчезнуть везде. Источников записи у клиники обычно несколько: собственный сайт, федеральная электронная регистратура (ФЭР), куда граждане записываются через Госуслуги [3], агрегаторы вроде ПроДокторов, СберЗдоровья и НаПоправку, а также шина МедФлекс, через которую записывают онлайн-сервисы и страховщики [14]. Тонкие места – перенос, отмена и неявка – разобраны в статье об интеграции расписания и календаря.

Лаборатории – цикл «заказ – результат». С крупными сетями (Инвитро, Гемотест, Хеликс, KDL, ЦМД) рассчитывайте на договорную интеграцию: через лабораторный модуль МИС, через N3.Health или через региональные системы обмена данными лабораторных исследований (ОДЛИ). Трудность не в транспорте, а в том, чтобы безопасно показать отклонение от нормы и не потерять опасное значение. Этому посвящена статья о заказах и результатах лабораторных исследований.

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

Государственный контур: ЕГИСЗ и рецепты – самая регулируемая связь

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

ЕГИСЗ – единая государственная информационная система в сфере здравоохранения. Подсистемы, важные для телемедицины: ФРМР и ФРМО (регистры медработников и медорганизаций), ФЭР (электронная регистратура), РЭМД (реестр электронных медицинских документов), ИЭМК (интегрированная электронная медкарта) и НСИ (справочники) [3]. Поставщики сведений – медорганизации государственной, муниципальной и частной систем (п. 44 «к» Положения о ЕГИСЗ); для клиники это ещё и лицензионное требование. В 2023 году Минздрав отдельным письмом подтвердил, что частные клиники передают документы в РЭМД за свой счёт [4].

Для телемедицины важны сроки. Запрос на телемедицинскую консультацию и её протокол передаются в ФЭР в течение одного рабочего дня, а сведения о сформированном электронном медицинском документе – в РЭМД тоже в течение одного рабочего дня [3]. Сам документ – это СЭМД, структурированный электронный медицинский документ: XML на базе HL7 CDA R2 уровня 3, собранный по руководству по реализации с портала ЕГИСЗ [6]. С 1 сентября 2026 года электронные медицинские документы подписываются только усиленной квалифицированной электронной подписью (УКЭП) в формате CMS – этого требует приказ Минздрава № 209н [5]. Подпись часто не одна: например, медицинское свидетельство сначала подписывают врач и руководитель, а для отправки в РЭМД – ещё и медорганизация [6].

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

Электронный рецепт относится к тому же контуру. После телемедицинской консультации рецепт возможен только при коррекции лечения, назначенного на очном приёме по тому же обращению (п. 38–39 приказа 193н) [2]. Для рецепта в форме электронного документа нужны УКЭП врача, регистрация врача в ФРМР и организации в ФРМО и подключение организации к ГИС субъекта (приказ 1094н) [7]. Полный путь описан в статье электронные рецепты: приказ 1094н, УКЭП и ограничения. На карте пока отметьте государственный контур как интеграцию на несколько недель с подписями и согласованиями, а не задачу на один спринт.

Идентификация и доступ: ЕСИА, ФРМР и УКЭП

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

Со стороны пациента всё решает закон: участники телемедицинской консультации идентифицируются через ЕСИА – единую систему идентификации и аутентификации, то есть вход через Госуслуги (ч. 6 ст. 36.2 323-ФЗ, п. 7 приказа 193н) [1][2]. Технически это вход по OAuth 2.0 / OpenID Connect, но подключение коммерческой системы к ЕСИА – отдельная процедура регистрации с криптографической частью, и её надо заранее закладывать в план. Sber ID или VK ID удобны для входа в приложение, но ЕСИА для консультации не заменяют.

Со стороны врача задач две. Первая – вход: клиницисты обычно заходят через единый вход клиники (single sign-on по OIDC или SAML, например на Keycloak), и отдельного пароля к вашему приложению у врача быть не должно. Вторая – юридическая личность врача: консультант должен быть в ФРМР, а организация – в ФРМО (п. 9 приказа 193н) [2], а документы консультации подписываются УКЭП медработника (ч. 7 ст. 36.2) [1]. Если платформа запускается из МИС, удобно передавать ей уже авторизованного врача и открытую карту пациента. В международной практике для этого есть схема SMART on FHIR (OAuth 2.0 с PKCE), но у российских МИС единого механизма нет, и параметры запуска согласуют с каждым разработчиком отдельно. Полный разбор – в статье идентификация через ЕСИА, SSO и регистры ФРМР/ФРМО.

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

Деньги: ДМС, ОМС и касса – держите платежи по картам вне границы

Финансовая сторона телемедицины – три разных потока, которые часто смешивают: пациент платит сам, платит страховщик ДМС, платит ОМС. У них разные стандарты и очень разная связь с медданными.

Пациент платит сам – это платные медицинские услуги. С 1 сентября 2026 года действуют новые правила (постановление Правительства № 659): договор можно заключить дистанционно на сайте или в приложении, а до подписания пациенту нужно раскрыть ОГРН, ИНН, лицензию, условия оплаты и адрес для претензий [15]. Деньги принимает эквайер – ЮKassa, CloudPayments, Т-Касса, Robokassa; СБП и карты «Мир» есть у всех. На каждую онлайн-оплату по 54-ФЗ нужен кассовый чек, который при расчётах в интернете отправляется в электронной форме [16]. Обычно это облачная касса (АТОЛ Онлайн, КОМТЕТ Касса, Orange Data) плюс оператор фискальных данных (ОФД).

Платит страховщик ДМС. Этот канал растёт: по опросу страхового брокера Remind, в 2025 году телемедициной пользовались 25% застрахованных по ДМС против 12% в 2022-м [17]. Цикл выглядит так: проверить полис и программу пациента, согласовать услугу со страховщиком (гарантийное письмо), провести консультацию и оформить документы, затем выставить страховщику реестр и счёт. Форматы обмена задаёт договор с конкретным страховщиком; часть этой работы берут на себя шины – у МедФлекс, например, есть API «согласования услуг» между клиниками и страховыми [14]. Помните, что страховщику уходят сведения, составляющие врачебную тайну: передавать их можно с письменного согласия пациента или в случаях ч. 4 ст. 13 323-ФЗ [9], и основание должны зафиксировать юристы.

Платит ОМС – для клиник, работающих в системе обязательного страхования. Программа госгарантий на 2026–2028 годы предусматривает отдельные тарифы на телемедицину; средний норматив стоимости на 2026 год – 379,9 ₽ за консультацию «врач – врач» и 336,3 ₽ за «врач – пациент» [18]. Счета идут реестрами через ТФОМС и страховые медицинские организации. Подробно о том, кто и за что платит, – в статье оплата телемедицины: ОМС, ДМС и платные услуги.

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

На платеже пациента правильно проведённая граница особенно выручает. Если номер карты вводится на платёжной форме эквайера, а не на вашем сервере, основная часть требований к защите карточных данных (стандарт PCI DSS) ложится на провайдера [19]. Главное – не смешивать два контура: отправлять эквайеру номер заказа и сумму, а не диагноз или специальность врача. Тогда платёжный провайдер вообще не касается медданных и не становится ещё одним звеном в цепочке поручений. Отдельный вопрос к юристам и бухгалтерии – наименование услуги в чеке: чек уходит в ОФД и налоговую, и «Консультация психиатра» в нём – уже сведения о факте обращения. Полная картина – в статье платежи, ДМС, ОМС и фискализация по 54-ФЗ.

На каком языке говорит каждая связь

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

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

Таблица 1. Десять интеграций одним взглядом. Трудоёмкость указана для первой прямой интеграции; шина вроде N3.Health или МедФлекс может сократить работу по МИС, записи и ЕГИСЗ – этот компромисс разобран в гиде по решению об интеграции.

Где сосредоточен риск интеграций

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

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

Второе – государственный контур: на критическом пути стоят подписи УКЭП, руководства по реализации СЭМД, регистрация информационной системы и жёсткий срок в один рабочий день на передачу протокола. Ошибку здесь видит не только клиника, но и регулятор: размещение сведений в ЕГИСЗ – лицензионное требование.

Третье, самое коварное, – данные, которые вы выпускаете из платформы: аналитика, трекеры ошибок, маркетинговые счётчики, push-уведомления. Медданные в стороннем SDK, во внешнем трекере ошибок или в URL, который читает чужой счётчик, – это передача сведений третьему лицу без основания, а если сервис хранит данные за рубежом, ещё и нарушение требования о локализации (ст. 18 ч. 5 152-ФЗ) [8]. Это один из самых частых способов, которыми телемед-команды теряют данные пациентов. Безопасная схема – отправлять в аналитику только обезличенный поток и хранить его в России. Методы описаны в статье обезличивание, вторичное использование и аналитика медданных, а требования к размещению – в материале локализация данных и где хранятся медданные.

Удобная модель: каждая интеграция – граница доверия. На каждой связи вы аутентифицируете другую сторону, авторизуете доступ к конкретным данным, журналируете обращения, ограничиваете частоту запросов и явно решаете, могут ли через неё проходить медданные. Связи с медданными находятся внутри границы и имеют основание; связи, по которым идут только деньги или обезличенные данные, остаются снаружи. Главное – провести эту границу осознанно.

Пример расчёта: стоимость – в соединениях

Допустим, вы оцениваете MVP телемедицины и закладываете на видео и приложение восемь инженер-недель. Теперь добавьте интеграции, без которых клиническому продукту в России не обойтись. Первая прямая интеграция с одной МИС – по осторожной оценке шесть недель. Запись через МИС и один агрегатор – две. Лаборатории – три. ЕСИА, сверка ФРМР и подпись УКЭП – три. Государственный контур (протокол в ФЭР, СЭМД в РЭМД) – шесть, в основном на ожидание согласований и тесты. ДМС с одним страховщиком – три. Эквайринг и онлайн-касса – одна.

Складываем:

6 (МИС) + 2 (запись) + 3 (лаборатории) + 3 (ЕСИА, ФРМР, УКЭП)
+ 6 (ЕГИСЗ) + 3 (ДМС) + 1 (эквайринг и касса) = 24 инженер-недели

Двадцать четыре недели на интеграции против восьми недель на видео и приложение: интеграции примерно втрое больше ядра, и это нормальные пропорции телемед-проекта. Для ориентира по деньгам: 24 недели – около 5,5 человеко-месяца, и при медиане middle-разработчика 178 тыс. ₽ в месяц на руки (Хабр Карьера, 2026) только зарплатная часть составит порядка 1 млн ₽ без налогов, взносов и накладных расходов [20]. Поэтому так важно решение по каждой связи: напрямую, через шину вроде N3.Health или МедФлекс или встраиванием в интерфейс МИС. Ему посвящён гид по решению об интеграции. Подставьте свои числа: проект – это соединения, а не звонок.

Типичные ошибки

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

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

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

Фора Софт разрабатывает видеосистемы и клинические системы с 2005 года, и в телемедицине основная инженерная работа приходится именно на интеграции. Любую клиническую разработку мы начинаем с такой карты: каждая система, с которой должна работать платформа, стандарт на каждой связи, направление данных и граница медданных. Сначала требования: договор-поручение и основание на каждой связи с медданными, ЕСИА и УКЭП с первого спринта, путь в ЕГИСЗ выбран до начала разработки, эквайринг вне границы, аналитика только на обезличенных данных в российском контуре. И уже затем – функциональность: видеоприём, который становится полноценным эпизодом медицинской помощи, связанным с МИС, записью, лабораторией, государственными системами и страховщиком без утечки хотя бы одного поля данных пациента.

Главное

• Телемед-платформа – хаб, связанный примерно с десятью системами; видео – наименьшая часть работы.
• У российских МИС нет единой двери для сторонних приложений: свой API, шина (N3.Health, МедФлекс) или файловый обмен.
• Государственный контур обязателен и для частных клиник: протокол консультации – в ФЭР, СЭМД (HL7 CDA R2) с УКЭП – в РЭМД, оба за один рабочий день.
• Пациент идентифицируется через ЕСИА; врач должен быть в ФРМР и подписывает документы УКЭП.
• Эквайринг с кассой по 54-ФЗ и аналитику (только обезличенные данные, хранение в РФ) осознанно держите вне границы медданных.
• Где медданные проходят через связь, нужно основание: договор-поручение, согласие пациента или прямая норма закона.

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

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