Краткий ответ: интеграционный движок (интерфейсный движок) — это промежуточное ПО, созданное для обмена медицинскими данными. Он прослушивает множество протоколов (MLLP для HL7 v2, HTTP для FHIR и SOAP, файлы, базы данных, очереди), преобразует сообщения (сопоставление полей, перевод кодов, преобразование форматов, например, из HL7 v2 в FHIR), направляет их к одному или нескольким получателям с помощью фильтров и поддерживает очереди, повторные попытки, журналы и панели мониторинга, чтобы ни одно сообщение не было потеряно, а каждый сбой был виден. Больницы используют его, чтобы каждая система подключалась к движку один раз, а не ко всем остальным системам. Известные продукты: Mirth Connect (NextGen Connect, исторически с открытым исходным кодом), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion и множество других; облачные провайдеры предлагают управляемые аналоги.
Основные компоненты
Основные компоненты интерфейсного движка включают каналы (один поток от источника к его получателям), исходные коннекторы или слушатели, такие как MLLP и HTTP, фильтры, которые решают, будет ли сообщение продолжено, трансформаторы, которые сопоставляют поля и коды, коннекторы назначения, очереди с повторными попытками, мониторинг с оповещениями и журнал изменений каналов и истории сообщений.
Каждый движок, независимо от терминологии, имеет одинаковые части:
- Канал (интерфейс): один поток от источника к одному или нескольким получателям, со своими настройками и статистикой.
- Исходный коннектор / слушатель: MLLP (TCP с обрамлением для HL7 v2), конечные точки HTTP(S), SFTP и опрос файлов, запросы к базе данных, JMS или другие очереди, DICOM в некоторых продуктах.
- Фильтр: правило, которое определяет, будет ли сообщение продолжено (только ADT^A01 для этого класса пациентов).
- Трансформатор: скрипты или сопоставления, которые изменяют сообщение: переименовывают поля, сопоставляют локальные коды с LOINC через таблицу поиска, создают FHIR Observation из сегмента OBX, добавляют Z-сегмент, который ожидает устаревшая система.
- Коннектор назначения: куда идет результат, со своим протоколом и обработкой ошибок.
- Очередь и повторные попытки: сообщения сохраняются до подтверждения; при сбоях предпринимаются повторные попытки с экспоненциальной задержкой; "отравленные" сообщения попадают в очередь ошибок для человека.
- Мониторинг и оповещение: счетчики по каналам, задержка, частота ошибок, оповещения, когда канал замолкает (самое полезное оповещение в медицинской интеграции).
- Аудит: кто изменил какой канал, и история сообщений для устранения неполадок, с контролем срока хранения и доступа, поскольку это пациентские данные.
Типичные задачи
Типичные задачи медицинского интерфейсного движка включают веерную рассылку ADT из HIS по отделам, маршрутизацию лабораторных результатов нескольким получателям, перевод локальных кодов на LOINC, ATC и UCUM, сопряжение форматов HL7 v2, FHIR, CDA и CSV, предоставление фасада FHIR поверх устаревшей базы данных, нормализацию потоков данных устройств и адаптацию MLLP внутри к HTTPS снаружи.
- Рассылка ADT: получение данных о поступлении из HIS, фильтрация и перевод по отделам, доставка в лабораторию, радиологию, аптеку, службу управления койками и на пациентский портал.
- Маршрутизация результатов: ORU из LIS в EHR, в систему врача, назначившего исследование, в региональную запись, в запись пациента FHIR, каждая с разным подмножеством и форматом.
- Перевод кодов: локальные коды тестов в LOINC, локальные коды лекарств в ATC, единицы измерения в свободной форме в UCUM, через поддерживаемые таблицы поиска (сопоставление лабораторных кодов с LOINC).
- Сопряжение форматов: HL7 v2 в FHIR и обратно, CDA в FHIR, CSV из старой системы во что угодно.
- FHIR-фасад: движок предоставляет конечные точки FHIR и отвечает на них, запрашивая устаревшую базу данных или отправляя запросы v2, чтобы приложения видели FHIR-сервер там, где его нет.
- Интеграция устройств: проприетарные потоки мониторов, нормализованные до наблюдений IHE PCD.
- Адаптация протокола: MLLP внутри здания, HTTPS с OAuth снаружи.
Выбор движка
Выбор интерфейсного движка основывается на шести критериях: объем сообщений и насколько критичны задержки и сбои, поддерживаемые «из коробки» протоколы и стандарты (HL7 v2, FHIR R4, DICOM, национальные форматы), опыт разработчиков, операционные возможности, такие как кластеризация и отказоустойчивость, условия лицензирования, которые изменились для некоторых продуктов в 2025 году, и имеющиеся навыки для обслуживания каналов.
- Объем и критичность: количество сообщений в день, допустимая задержка и имеет ли значение двухминутный сбой (для ADT и результатов — имеет).
- Протоколы и стандарты "из коробки": версии и парсеры HL7 v2, поддержка FHIR R4 с валидацией, DICOM, X12 в США, национальные форматы.
- Опыт разработчика: язык скриптов (JavaScript в Mirth, проприетарный в других), контроль версий определений каналов, инструменты тестирования, развертывание в нескольких средах.
- Эксплуатация: кластеризация, отказоустойчивость, интеграция мониторинга, путь обновления, модель поддержки.
- Лицензирование: открытый исходный код или сообщество, подписка за канал или за ядро, управляемые облачные предложения; лицензирование некоторых исторически открытых продуктов изменилось в 2025 году, поэтому проверьте текущие условия.
- Доступные навыки: движок хорош настолько, насколько хороши люди, которые поддерживают каналы.
Безопасная эксплуатация
Безопасная эксплуатация интерфейсного движка означает управление определениями каналов как кодом под версионным контролем, тестирование с синтетическими сообщениями перед запуском в производственную среду, управление таблицами поиска кода с назначенными владельцами, оповещение при молчании канала, ограничение и удаление истории сообщений, поскольку это данные пациента, документирование назначения каждого канала и никогда не позволяйте движку становиться системой учета.
Относитесь к определениям каналов как к коду: в системе контроля версий, рецензируемому, развертываемому через тестирование и промежуточные среды с использованием синтетических сообщений. Держите таблицы поиска (карты кодов) под управлением с назначенными владельцами. Настраивайте оповещения о тишине, а не только об ошибках. Ограничивайте доступ к истории сообщений, которая является пациентскими данными, и удаляйте ее по расписанию. Документируйте назначение и владельца каждого канала; недокументированный канал — это тот, который останавливает работу отдела, когда уходит его автор. И никогда не позволяйте движку становиться системой учета: он перемещает и преобразует данные, он ими не владеет.
Когда он не нужен
Интерфейсный движок не нужен, когда все партнеры новой системы говорят на FHIR, в этом случае FHIR-сервер с подписками (Subscriptions) и API-шлюз обеспечивают маршрутизацию и аутентификацию, или когда один интерфейс HL7 v2 может быть обработан библиотекой, такой как HAPI HL7v2 или hl7apy. Движок оправдывает свое применение при работе со множеством систем и форматов.
Система с нуля, партнеры которой полностью используют FHIR, может использовать FHIR-сервер с подписками и API-шлюз для аутентификации, ограничения скорости и маршрутизации, с преобразованиями в обычных сервисах. Один интерфейс HL7 v2 может быть обработан небольшой библиотекой (HAPI HL7v2 в Java, hl7apy или python-hl7 в Python) внутри приложения. Движок оправдывает свое место, когда существует множество систем, множество форматов и потребность в консоли управления, за которой могут наблюдать не-разработчики.
В Anpheros
Anpheros Platform находится на стороне FHIR движка: больницы направляют потоки, которыми они хотят поделиться (результаты, документы, встречи), через свой движок или через лабораторный коннектор, и читают обратно через FHIR API и вебхуки. На сайте для разработчиков показано сопоставление HL7 v2 в FHIR, которое применяет коннектор.
Связанные страницы
- Интеграция больничных систем: объяснение
- Как интегрировать лабораторную систему с EHR
- Сообщения HL7 v2: ADT и ORU
- Как сопоставить локальные лабораторные коды с LOINC
- FHIR Subscriptions: объяснение
- Сопоставление HL7 v2 в FHIR (сайт для разработчиков)
Источники
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- Библиотека HAPI HL7v2
- Руководство по реализации HL7 v2-to-FHIR
Частые вопросы
Является ли интеграционный движок тем же, что и ESB или iPaaS?
Семья одна, но специализация другая: интеграционный движок поставляется с поддержкой HL7 v2, DICOM, CDA и FHIR, MLLP, медицинским мониторингом и интеграцией словарей, используемых командами. Общие ESB и iPaaS могут выполнить эту работу с большими усилиями.
Может ли движок автоматически преобразовывать HL7 v2 в FHIR?
Несколько движков включают сопоставления на основе руководства HL7 v2-to-FHIR и обрабатывают общие сегменты. Локальные соглашения, Z-сегменты и сопоставление кодов всегда требуют проектной работы.
Хранит ли движок пациентские данные?
Он сохраняет сообщения в процессе передачи и ведет историю сообщений для устранения неполадок, что является пациентскими данными и должно быть защищено и удалено. Его не следует использовать в качестве долгосрочного хранилища или системы учета.
Открытый исходный код или коммерческий?
Оба используются в крупных больницах. Решение обычно сводится к поддержке, навыкам, потребностям в кластеризации и текущим условиям лицензирования, которые изменились для некоторых продуктов; проверьте перед принятием решения.
Попробуйте бесплатно в песочнице
Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.
Бесплатно · 30 синтетических пациентов · без карты
Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.
О Anpheros →