HL7 FHIR, СЭМД и интеграция с МИС на практике

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

Кратко

Телемед-приложение в России обменивается данными с медицинскими системами по трём стандартам одного семейства HL7. HL7 v2 – формат сообщений с вертикальной чертой в качестве разделителя: на нём МИС общается с оборудованием и лабораторными системами. HL7 CDA R2 – формат клинического документа, на нём построены СЭМД, которые обязательно передаются в РЭМД ЕГИСЗ. FHIR – веб-API, который отдаёт клинические данные в JSON по HTTPS; на нём работают частные платформы обмена вроде N3.Health и построен профиль RuCore сообщества HL7 FHIR Россия. Государство регулирует не версию FHIR, а СЭМД: формат по руководствам с портала ЕГИСЗ, подпись УКЭП и регистрацию в РЭМД в течение одного рабочего дня. За выходные интеграцию с МИС не сделать: у многих систем нет открытой документации API, каждая инсталляция настроена по-своему, а доступ дают по договору с разработчиком или через шину. В статье – три стандарта простым языком, путь СЭМД от консультации до РЭМД, справочники НСИ, способы обмена данными и то, что на практике означает подключение к российской МИС. К статье прилагается одностраничная шпаргалка.

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

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

Три стандарта, одна семья

Первое, что обычно удивляет: HL7 v2, CDA и FHIR разработала одна некоммерческая организация по стандартизации – Health Level Seven International (HL7). Стандарты не конкурируют между собой: это три поколения, созданные под разные задачи, и в российских медицинских ИТ-системах используются все три одновременно.

HL7 v2 – самый старый. Его спроектировали в конце 1980-х, чтобы компьютер одного отделения мог отправить другому по локальной сети сообщение: поступил пациент, готов результат анализа, создан заказ. Это стандарт сообщений: системы обмениваются структурированными текстовыми сообщениями и подтверждают получение [1]. CDA (Clinical Document Architecture) – стандарт документа: он задаёт структуру и смысл клинического документа (выписки, протокола, заключения) и развивался вместе с третьей версией HL7 [2]. FHIR (Fast Healthcare Interoperability Resources, читается «файр») – самый молодой: первый черновик появился в 2011 году, и стандарт с самого начала создавался для веба. Это стандарт API: приложение запрашивает у сервера по HTTPS, например, активные назначения пациента и получает структурированный JSON [3].

В России используются все три, и причины понятны. HL7 v2 давно связывает МИС, лабораторные системы и оборудование, и эти связи работают. CDA выбрало государство: на нём построены структурированные электронные медицинские документы (СЭМД), которые медорганизации обязаны передавать в ЕГИСЗ. FHIR берут те, кто строит новые системы: частные платформы обмена и сообщество разработчиков. Поэтому телемед-продукту приходится работать со всеми тремя.

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

HL7 v2: язык оборудования и лабораторных систем

Так выглядит сообщение HL7 v2 (данные вымышленные; реальные данные пациентов в примерах использовать нельзя):

MSH|^~\&|LIS|LAB|MIS|CLINIC|202610121015||ORU^R01|MSG00001|P|2.5.1
PID|1||100042^^^CLINIC^MR||IVANOVA^ANNA||19850312|F
OBR|1||ORD789|14749-6^Glucose^LN|||202610121000
OBX|1|NM|14749-6^Glucose^LN||5.3|mmol/L|3.9-5.5|N|||F

Каждая строка – сегмент, его тип задают первые три буквы. MSH – заголовок: отправитель, получатель, тип сообщения и время. PID идентифицирует пациента: номер карты, имя, дата рождения, пол. OBR описывает заказ, OBX – наблюдение (здесь глюкоза 5,3 ммоль/л с референсным диапазоном и флагом «N», то есть норма). Вертикальная черта | разделяет поля, символ ^ – компоненты внутри поля: одна строка на один факт.

Трёхбуквенные коды типов сообщений полезно знать: разработчики постоянно говорят ими. ADT (Admit, Discharge, Transfer) сообщает о движении пациента и его демографических данных. ORU передаёт результаты наблюдений, как анализ выше. ORM и более новые OMG/OMP передают заказы, SIU – расписание. На каждое сообщение приходит ACK, подтверждение доставки. Транспортом обычно служит не HTTPS, а MLLP (Minimal Lower Layer Protocol) – тонкая обёртка над обычным TCP-сокетом. Поэтому обмен по HL7 v2 идёт внутри сети клиники, без выхода в открытый интернет.

Сильная сторона HL7 v2 – распространённость и стабильность. Слабая – нестрогость: в стандарте много необязательных полей и есть «Z-сегменты» (локальные расширения). Две системы могут отправить «одинаковое» сообщение ORU с разным набором заполненных полей, так что интеграция должна учитывать диалект каждой площадки. В российских МИС HL7 v2 встречается, в частности, на стыке с оборудованием и PACS: 1С:Медицина, например, заявляет взаимодействие по DICOM 3 и HL7 версии 2, а также поддержку форматов HL7 версии 3 [10]. Телемед-продукт через HL7 v2 обычно получает поток лабораторных результатов или события о пациенте, если их публикует МИС или лабораторная система. Это обмен между серверами внутри защищённого периметра клиники.

CDA и СЭМД: формат, который требует государство

HL7 v2 нужен системам, чтобы обмениваться данными между собой, а СЭМД – чтобы передавать документы государству. СЭМД – структурированный электронный медицинский документ ЕГИСЗ: XML на базе HL7 CDA R2 уровня 3 [11]. Уровень 3 означает, что в документе есть не только текст для человека, но и машиночитаемые кодированные записи: вместо строки «глюкоза в норме» – код показателя, значение и единицы измерения. Как у любого CDA-документа, у СЭМД есть заголовок (автор, пациент, организация, дата создания) и тело с разделами [2].

Каждый вид СЭМД (протокол консультации, выписка, направление, медицинское свидетельство) собирается по своему руководству по реализации, опубликованному на портале оперативного взаимодействия участников ЕГИСЗ [11]. Руководство задаёт обязательные элементы, допустимые значения и справочники для кодов. Сами коды берутся из НСИ Минздрава – нормативно-справочной информации, о ней ниже. Поэтому фраза «мы умеем CDA» говорит так же мало, как «мы поддерживаем FHIR»: в спецификации должны стоять конкретный вид СЭМД и конкретная версия его руководства.

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

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

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

FHIR: веб-API для клинических данных

FHIR устроен иначе. Вместо сообщений и документов он описывает здравоохранение как набор ресурсов – именованных объектов, которые читают и записывают через REST-API: Patient, Observation (результат анализа, витальный показатель), MedicationRequest (назначение), Appointment, Encounter, Condition (диагноз), DocumentReference (клиническая заметка). В FHIR R4 определено около 145 типов ресурсов, телемед-приложению обычно хватает примерно дюжины [3].

Данные читаются обычным HTTPS-запросом. Карточку пациента возвращает GET [base]/Patient/100042, активные назначения – GET [base]/MedicationRequest?patient=100042&status=active. Ответ приходит в JSON. Ниже сокращённый вымышленный Observation: тот же результат анализа на глюкозу, что и в примере HL7 v2, только в форме FHIR.

{
  "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "14749-6", "display": "Glucose" }] },
  "subject": { "reference": "Patient/100042" },
  "valueQuantity": { "value": 5.3, "unit": "mmol/L" },
  "referenceRange": [{ "low": { "value": 3.9 }, "high": { "value": 5.5 } }]
}

Команде приложения с FHIR удобно работать по двум причинам. Во-первых, это самоописываемый JSON по HTTPS: любой веб-инженер разберётся в нём, не изучая грамматику клинических сообщений. Во-вторых, коды передаются вместе с данными: пара loinc.org / 14749-6 по международному словарю LOINC означает «глюкоза в ммоль/л» [17], и гадать, что означает число, не приходится. В российских профилях вместо международных словарей часто используются справочники НСИ, к этому вернёмся в разделе о терминологии.

Где FHIR используется в России? Платформа обмена медданными N3.Health (группа «Нетрика») прямо заявляет: «работаем по стандарту HL7 FHIR». Через неё проходят интегрированная электронная медкарта, лабораторные данные, телемедицинские консультации, запись и рецепты, а МИС подключаются по API [8]. Сообщество HL7 FHIR Россия ведёт профиль RuCore – «руководство по реализации FHIR в Российской Федерации», где, по словам авторов, учтены требования к использованию НСИ Минздрава [7]. Обязательного государственного FHIR-профиля при этом нет: государственный контур работает с СЭМД.

Версии FHIR и российский профиль RuCore

Фраза «мы поддерживаем FHIR» ещё не спецификация, потому что у FHIR есть версии. Базовая – FHIR Release 4 (R4), опубликованная в конце 2018 года. Это первая версия с нормативным содержимым, то есть с частями, которые авторы обязались не менять несовместимым образом [4]. Более новые – R4B (2022), промежуточный релиз с изменениями в отдельных областях, и R5 (март 2023), крупный релиз в статусе trial use. Текущая опубликованная версия – R5, R6 ещё в разработке [4].

В России версию выбираете не вы и не регулятор, а тот, с кем вы обмениваетесь данными. RuCore построен на R5. На момент проверки это непрерывная сборка версии 0.26.0, «живой документ», который продолжает меняться. Авторы сами подчёркивают, что RuCore не задаёт стандарты передачи данных для каждого конкретного случая: под отдельный сценарий обмена на его основе пишут собственные руководства [7]. Версию FHIR конкретной шины на её главной странице не найти: её нужно брать из документации API и фиксировать в договоре [8].

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

Вход и контекст: ЕСИА, SSO и запуск из МИС

FHIR-API отвечает на вопрос, как прочитать данные. Но сначала нужно решить другую задачу: как приложению подтвердить, кто запрашивает данные, и получить на это разрешение.

В международной практике для этого используют SMART on FHIR – тонкую медицинскую надстройку над OAuth 2.0; текущая ветка спецификации – SMART App Launch 2.x [5]. Она отвечает за вход и передачу контекста. Врач нажимает кнопку вашего инструмента внутри медкарты, медкарта перенаправляет его в приложение с одноразовым launch-токеном, приложение завершает OAuth-обмен с PKCE (дополнительной проверкой, которая не даёт повторно использовать перехваченный код) и получает токен доступа вместе с контекстом: кто вошёл и какой пациент открыт. Права задаются через scopes вида patient/Observation.rs («читать и искать наблюдения только этого пациента») и выдаются строго в нужном объёме.

У российских МИС единого механизма запуска внешних приложений нет: каждая система делает это по-своему, от кнопки со ссылкой до встроенного виджета, а параметры согласуются с разработчиком. Но схему SMART всё равно стоит повторить. Договоритесь с разработчиком МИС, что вместо персональных данных в URL передаётся одноразовый код запуска. Обменивайте его на короткоживущий токен на своём бэкенде, передавайте контекст (идентификаторы приёма и пациента) и выдавайте минимальные права. Сверху добавляются обязательные российские требования: пациент как участник телемедицинской консультации входит через ЕСИА, а врач должен быть внесён в ФРМР и подписывать документы УКЭП. Подробно об этом – в статье идентификация через ЕСИА, SSO и регистры ФРМР/ФРМО.

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

Как на практике передаются данные: четыре способа

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

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

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

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

Четвёртый – массовые выгрузки, когда нужны данные сразу по многим пациентам: для регистра, отчётности о качестве, аналитики. В международном FHIR для этого есть спецификация Bulk Data Access: операция $export выдаёт данные в формате NDJSON, а сервер авторизуется через SMART Backend Services [6]. В российских МИС массовую выгрузку чаще согласуют индивидуально. В аналитику при этом передают только обезличенные данные; подробно об этом – в статье обезличивание и аналитика медданных.

Онлайн-API нужен для живой консультации, события – для реакции в реальном времени, СЭМД – для государства, выгрузки – для работы с данными по всей группе пациентов. Большинству клинических продуктов со временем требуются все четыре способа.

Что на деле значит «интегрироваться с МИС»

HL7 v2, CDA и FHIR дают общий язык, но доступ к конкретной МИС определяют договорённости с её разработчиком и клиникой. Поэтому интеграция с МИС – полноценный проект, а не пункт в настройках.

Публичная документация API есть не у всех российских МИС. Часто доступ к API означает договор с разработчиком или его партнёром, тестовый стенд по запросу и согласование требований безопасности. Каждая инсталляция настроена по-своему: свои справочники услуг, врачей, кабинетов и расписаний, своя версия, облако или собственный сервер клиники. Условия подключения к государственным системам (ЕЦП.МИС в регионах, ЕМИАС в Москве) определяет региональный оператор, и коммерческий продукт попадает туда только через проект с регионом.

Поэтому многие команды вместо прямой интеграции с каждой МИС подключаются через шину. N3.Health сообщает о сотрудничестве с более чем 150 МИС и ЛИС [8], МедФлекс – о 152 МИС и API для партнёров: онлайн-запись, согласование услуг со страховыми, интеграция с ЕГИСЗ [9]. Шина заменяет отдельные договорённости с каждым разработчиком одной точкой интеграции, но за неё придётся платить по тарифам шины. Когда идти напрямую, когда через шину, а когда встраиваться в интерфейс МИС, разобрано в гиде по решению об интеграции; особенности отдельных систем – в статье интеграция с МИС: Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС и другие.

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

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

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

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

2 (код) + 1 (стенд) + 1 (сопоставление) + 3 (договор и ИБ, середина)
+ 2 (запуск, середина) = 9 инженер-недель

Из девяти недель на код приходятся только две. Теперь умножим. Поддержка Медиалога, 1С:Медицины и ЕЦП.МИС почти не утраивает объём кода (вызовы похожи), зато примерно утраивает накладные расходы на стенд, договор и запуск: каждая МИС допускает вас отдельно. Если протокол консультации в виде СЭМД формирует ваша платформа, а не МИС, заложите отдельный блок на руководство по реализации, подписи и тестирование передачи в РЭМД. Сроки растягивают именно накладные расходы, а не работа с API, поэтому шина, которая сводит несколько подключений к одному, может окупить свою стоимость. Подставьте свои системы – структура расчёта останется прежней.

Терминологический слой

В основе всех трёх стандартов лежат системы кодов, которые придают данным однозначный смысл. Сегмент OBX, ресурс Observation и запись в СЭМД полезны, только если «глюкоза» везде означает одно и то же.

В российском государственном контуре эту роль играет НСИ Минздрава – федеральные справочники с REST API на портале nsi.rosminzdrav.ru [15]. Руководства по реализации СЭМД указывают, из какого справочника брать каждый код, а RuCore, по заявлению авторов, учитывает требования к использованию НСИ [7]. Диагнозы кодируются по МКБ-10. Международные словари вроде LOINC (лабораторные тесты) и SNOMED CT (клинические находки) встречаются в примерах FHIR и в документации зарубежных библиотек [17]. Придумывать коды не нужно: задача в том, чтобы сопоставить свои данные со справочниками контрагента и НСИ. Подробнее о лабораторных кодах – в статье заказы и результаты лабораторных исследований.

Типичная ошибка, которой стоит избегать

Самое дорогое заблуждение – считать подключение к МИС одной задачей и завести в бэклоге один тикет «добавить интеграцию с МИС». За ним стоят как минимум четыре решения: какой способ обмена выбрать для каждого потока данных (API, HL7 v2, СЭМД или FHIR через шину); какие версии взять (версию руководства СЭМД, версию FHIR и профиль контрагента); какой режим доступа нужен (онлайн-API, события, документы или выгрузки); каким путём подключать каждую МИС (напрямую, через шину или встраиванием). Если свести всё это в один тикет, вы оцените две недели кода и упустите семь недель на стенд, сопоставление, договор и запуск.

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

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

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

Главное

• HL7 v2, CDA и FHIR разработаны одной организацией – HL7; в России используются все три.
• HL7 v2 – сообщения с вертикальной чертой в качестве разделителя (ADT, ORU, ORM), передаются по MLLP; в России встречаются, например, на стыке МИС с оборудованием и лабораториями.
• СЭМД – XML на базе HL7 CDA R2 уровня 3 по руководствам с портала ЕГИСЗ, с подписью УКЭП и регистрацией в РЭМД за один рабочий день.
• FHIR – REST-API для приложений; в России на нём работают шины вроде N3.Health и профиль RuCore (R5), обязательного государственного FHIR-профиля нет.
• Для запуска из МИС повторите схему SMART on FHIR (OAuth 2.0 + PKCE, контекст, минимальные права); пациент входит через ЕСИА.
• Интеграция с каждой МИС – отдельный проект (стенд, договор, запуск), а не настройка.

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

• Интеграция с МИС: Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС и другие
• Гид по решению об интеграции: напрямую, через агрегатор или iframe
• Карта интеграций телемед-платформы: что с чем соединяется