Краткий ответ: больница использует десятки систем, и интеграция — это работа по приведению их к единому мнению об одном пациенте. В центре находится МИС (медицинская информационная система) или ЭМК (электронная медицинская карта), которая отвечает за идентификацию пациента, его поступления и клиническую запись. Вокруг нее: система лаборатории (ЛИС), радиологии (РИС и PACS), аптеки, операционной, скорой помощи, биллинга, устройств (мониторы, инфузионные насосы), и все чаще приложения для пациентов, носимые устройства и телемедицина. Интерфейсный движок посередине получает, преобразует и маршрутизирует сообщения, так что каждая система подключается один раз, а не ко всем остальным. Трафик в основном состоит из сообщений HL7 v2 через MLLP для событий (поступления, заказы, результаты), DICOM для изображений, CDA или PDF для документов и FHIR через REST для всего нового, ориентированного на пациента или внешнего.
Системы и что они обменивают
Интеграционная среда больницы состоит из HIS или EHR, которые управляют идентификацией пациента, случаями лечения и клиническими записями, а также лабораторной системы, радиологии (RIS и PACS), аптеки, устройств, приложений для пациентов, телемедицины и региональных систем. Они обмениваются сообщениями HL7 v2, такими как ADT, заказами и результатами ORU, изображениями DICOM, документами CDA и ресурсами FHIR.
| Система | Владеет | Отправляет | Получает |
|---|---|---|---|
| МИС / ЭМК | Идентификация пациента, случаи, заказы, клиническая запись | ADT (поступления, переводы), ORM/OML заказы, SIU расписания | ORU результаты, MDM документы, DFT счета |
| ЛИС (лаборатория) | Образцы, анализы, результаты, референсные диапазоны | ORU^R01 результаты, ORR ответы на заказы | ORM/OML заказы, ADT для демографических данных |
| РИС / PACS | Заказы на визуализацию, рабочие списки, отчеты, изображения | ORU отчеты, DICOM для просмотрщиков, SIU | ORM/OMI заказы, ADT; DICOM MWL для модальностей |
| Аптека | Формуляр, выдача, запас | RDS выдача, RAS администрирование | OMP/RDE заказы на лекарства, ADT |
| Устройства и мониторы | Жизненно важные показатели, формы волн, сигналы тревоги | ORU^R01 наблюдения (IHE PCD), проприетарные | ADT для контекста пациента |
| Портал / приложения для пациентов | Данные, введенные пациентом, доступ | FHIR Observations, опросники, сообщения | FHIR чтение результатов, записей на прием, документов |
| Телемедицина | Видео-приемы, удаленный мониторинг | FHIR Encounter, Observation, DocumentReference | Запись на прием, контекст пациента, запуск SMART |
| Региональные и национальные системы | Общие записи, реестры, электронные рецепты | CDA документы (XDS), FHIR, национальные сообщения | Запросы, уведомления |
Интерфейсный движок
Интерфейсный движок — это центр обмена сообщениями больницы: он получает трафик HL7 v2, FHIR, файлы и данные из баз данных от каждой системы, преобразует его и направляет во все другие системы, которым он необходим, а также управляет очередями, повторными попытками, мониторингом и аудитом. Без него N систем требуют до N×(N−1)/2 вручную созданных интерфейсов; с ним каждая система подключается один раз.
Движок (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare и IRIS for Health, Infor Cloverleaf, Qvera QIE и другие) предоставляет слушатели (MLLP, HTTP, файлы, базы данных), преобразования (сопоставление полей, исправление кодов, преобразование v2 в FHIR), маршрутизацию (отправка ADT в восемь систем с восемью фильтрами), очереди и повторные попытки, мониторинг и аудит. Здесь также происходит согласование идентификации пациента, когда системы расходятся во мнениях, и часто создается FHIR-фасад поверх устаревшей базы данных. См. Объяснение интерфейсных движков.
Наиболее важные потоки
Наиболее важные интеграционные потоки больницы включают ADT (поступления, выписки, переводы и обновления демографических данных, распространяемые из HIS), заказы и результаты между EHR и лабораторией или радиологией, заказы на лекарства и их выдачу, документы, такие как выписные письма, данные с устройств мониторинга, а также обмен результатами, записями на прием и домашними измерениями с пациентами через FHIR.
- ADT: каждое поступление, выписка, перевод, регистрация и обновление демографических данных (A01, A03, A02, A04, A08, A40 merge) распространяется из МИС всем остальным. Если ADT задерживается или ошибочно, каждая нижестоящая система записывает данные под неправильным пациентом или случаем. См. Сообщения HL7 v2: объяснение.
- Заказы и результаты: ORM/OML наружу, ORU обратно, с номерами placer и filler, связывающими их; LOINC и UCUM в результатах. См. Сообщения HL7 v2 для заказов и Интеграция лабораторной системы с ЭМК.
- Визуализация: заказы в РИС, DICOM рабочие списки для сканеров, изображения в PACS, отчеты обратно как ORU, просмотрщики через DICOMweb. См. PACS против RIS против VNA.
- Лекарства: заказы в аптеку, выдача и администрирование обратно, с замкнутым циклом (штрих-код у постели) как целью безопасности.
- Документы: выписные письма, операционные заметки и отсканированные документы как MDM сообщения, CDA или PDF в репозиторий документов, опубликованные в региональные реестры.
- Устройства: мониторы, подающие жизненно важные показатели в запись через профили IHE PCD или шлюзы поставщиков, с управлением сигналами тревоги как отдельной дисциплиной.
- Ориентированные на пациента: результаты, записи на прием и документы на портал и в приложения через FHIR; опросники, домашние измерения и данные с носимых устройств обратно, с указанием происхождения, помеченного как предоставленные пациентом. См. Удаленный мониторинг пациентов с FHIR.
Работающие шаблоны
Работающие шаблоны интеграции больниц включают: одну основную систему для идентификации пациента, где все остальные подписываются на ADT; сопоставление кодов с LOINC, SNOMED CT и ATC один раз в движке; подтверждения, очереди и повторные попытки для каждого сообщения; идемпотентные результаты и документы; уровень FHIR для приложений пациентов и внешних партнеров; и тестовые среды с синтетическими пациентами перед запуском.
- Один мастер для идентификации. МИС (или мастер-индекс пациентов) владеет идентификаторами; все остальные подписываются на ADT и никогда не создают пациентов самостоятельно.
- Коды на границе. Сопоставляйте локальные коды с LOINC, SNOMED CT, ATC на движке, один раз, и сохраняйте локальный код рядом.
- Подтверждение, очередь, повторная попытка. Каждое сообщение v2 получает ACK; движок сохраняет и воспроизводит; никто не теряет результат из-за перезагрузки системы.
- Идемпотентность. Результаты и документы содержат идентификаторы; повторное воспроизведение обновляет, а не дублирует.
- FHIR-слой для всего нового. Приложения для пациентов, телемедицина, выгрузки для исследований и внешние партнеры общаются через FHIR с фасадом или выделенным FHIR-сервером, питаемым внутренними потоками, а не напрямую с МИС.
- Тестовые среды с синтетическими пациентами и этап соответствия (профили IHE Connectathon, национальные тестовые наборы) перед тем, как что-либо попадет в производственную среду.
Режимы сбоев, встречающиеся повсеместно
Режимы сбоев, встречающиеся почти в каждой больничной интеграции, включают дублирование пациентов из-за опечаток при регистрации, результаты, приписанные не к тому случаю после объединения, несопоставленные локальные коды, ошибки часовых поясов и перехода на летнее время в метках времени, единицы измерения в свободном тексте, интерфейсы, которые молча останавливаются без мониторинга, Z-сегменты от поставщиков, которые нарушают работу парсеров, и временные CSV-каналы, которые никогда не выводятся из эксплуатации.
Дубликаты пациентов из-за опечаток при регистрации; результаты, записанные в неправильный случай после объединения; локальные тестовые коды, которые никто не сопоставил; часовые пояса и летнее время в метках времени сообщений; единицы измерения в свободном тексте; интерфейс, который молча остановился, и никто не следил за ним; Z-сегменты, специфичные для поставщика, которые нарушают парсеры; и "временный" CSV-канал, который работает до сих пор спустя десять лет.
Где FHIR меняет картину
FHIR меняет больничную интеграцию на периферии, а не в ядре. Внутри здания HL7 v2 и DICOM остаются, поскольку анализаторы, сканеры и устаревшие модули используют их; FHIR берет на себя доступ пациентов, приложения SMART on FHIR, поддержку принятия решений CDS Hooks, подписки, региональный и национальный обмен в рамках EHDS и TEFCA, а также извлечение данных для исследований.
Внутри, HL7 v2 и DICOM остаются на годы, потому что каждый анализатор, сканер и устаревший модуль говорят на них. FHIR выигрывает на краях: доступ пациентов, приложения, запускаемые внутри ЭМК (SMART on FHIR), поддержка принятия решений (CDS Hooks), подписки для интеграции на основе событий, региональный и национальный обмен в рамках EHDS и TEFCA, а также выгрузки для исследований. Многие больницы теперь используют FHIR-сервер, питаемый движком, в качестве своего интеграционного слоя для всего, что находится за пределами здания; см. Стандарты интероперабельности в здравоохранении: карта.
В Anpheros
Платформа Anpheros находится на периферии FHIR больничной интеграции: это запись FHIR R4, в которую больница или клиника может записывать и из которой может считывать данные с согласия пациента, получая их через собственный интеграционный канал больницы (коннектор лаборатории, HL7 v2 ORU, CSV или JSON), с веб-перехватчиками и информацией об источнике для каждого источника. Она не заменяет HIS или движок.
Anpheros Platform находится на этом краю: запись FHIR R4, в которую больница или клиника может записывать и из которой может читать с согласия пациента, питаемая собственной интеграцией больницы ( коннектор лаборатории принимает HL7 v2 ORU, CSV или JSON), с веб-хуками для уведомления об изменениях и указанием происхождения по источнику. Он не заменяет МИС или движок; он дает пациенту запись, которая следует за ним за пределы здания.
Связанные страницы
- Интерфейсные движки: объяснение
- Как интегрировать лабораторную систему с ЭМК
- Сообщения HL7 v2: объяснение ADT и ORU
- PACS против RIS против VNA
- Удаленный мониторинг пациентов с FHIR
- Стандарты интероперабельности в здравоохранении: карта
- Интеграция клинических систем с FHIR (сайт для разработчиков)
Источники
- Набор продуктов HL7 версии 2
- Технический фреймворк IHE IT Infrastructure
- Домен IHE Devices (профили Patient Care Device)
- HL7 FHIR R4: Сообщения и рабочий процесс
- Руководство по реализации HL7 v2-to-FHIR
Частые вопросы
Должна ли новая больница интегрировать все с FHIR?
Не все. Анализаторы, сканеры и большинство ведомственных систем говорят на HL7 v2 и DICOM, и это вряд ли изменится в ближайшее время. Используйте FHIR для интеграций, ориентированных на пациента, внешних и новых, а для связи используйте движок.
В чем разница между МИС и ЭМК?
Использование варьируется в зависимости от страны. МИС часто означает административную и клиническую больничную систему вместе; ЭМК подчеркивает клиническую запись. С точки зрения интеграции, обе являются системой, которая владеет идентификацией, случаями и записью.
Сколько интерфейсов у средней больницы?
Обычно от пятидесяти до нескольких сотен потоков сообщений проходят через движок, учитывая каждое направление и каждую принимающую систему. Экран мониторинга движка — это место, где живут команды интеграции.
Кто отвечает за интеграцию в больнице?
Команда IT-интеграции больницы, обычно при поддержке поставщика движка, и каждый ведомственный поставщик со своей стороны. Национальные программы и профили IHE сокращают, но не устраняют проектную работу.
Попробуйте бесплатно в песочнице
Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.
Бесплатно · 30 синтетических пациентов · без карты
Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.
О Anpheros →