Коротка відповідь: лікарня використовує десятки систем, і інтеграція — це робота, яка полягає в тому, щоб вони "домовилися" щодо одного пацієнта. У центрі знаходиться HIS (інформаційна система лікарні) або EHR, яка володіє ідентифікатором пацієнта, даними про госпіталізацію та клінічним записом. Навколо неї: система лабораторії (LIS), радіології (RIS та PACS), аптеки, операційної, невідкладної допомоги, білінгу, пристроїв (монітори, інфузійні насоси), а також все частіше додатки для пацієнтів, носимі пристрої та телемедицина. Інтерфейсний рушій посередині отримує, трансформує та маршрутизує повідомлення, щоб кожна система була підключена один раз, а не до всіх інших. Трафік переважно складається з повідомлень HL7 v2 через MLLP для подій (госпіталізація, замовлення, результати), DICOM для зображень, CDA або PDF для документів та FHIR через REST для всього нового, орієнтованого на пацієнта або зовнішнього.
Системи та їх обмін даними
Інтеграційний ландшафт лікарні складається з медичної інформаційної системи (МІС) або електронної медичної карти (ЕМК), яка володіє ідентифікацією пацієнта, даними про прийоми та клінічною історією, а також лабораторної системи, радіології (RIS та PACS), аптеки, пристроїв, додатків для пацієнтів, телемедицини та регіональних систем. Вони обмінюються повідомленнями HL7 v2, такими як ADT, замовленнями та результатами ORU, зображеннями DICOM, документами CDA та ресурсами FHIR.
| Система | Володіє | Надсилає | Отримує |
|---|---|---|---|
| HIS / EHR | Ідентифікатор пацієнта, випадки, замовлення, клінічний запис | ADT (госпіталізація, переведення), ORM/OML замовлення, SIU розклад | ORU результати, MDM документи, DFT рахунки |
| LIS (лабораторія) | Зразки, аналізи, результати, референтні діапазони | ORU^R01 результати, ORR відповіді на замовлення | ORM/OML замовлення, ADT для демографічних даних |
| RIS / PACS | Замовлення на візуалізацію, списки завдань, звіти, зображення | ORU звіти, DICOM для переглядачів, SIU | ORM/OMI замовлення, ADT; DICOM MWL для модальностей |
| Аптека | Формуляр, видача, запас | RDS видача, RAS введення | OMP/RDE замовлення на ліки, ADT |
| Пристрої та монітори | Життєві показники, хвилі, тривоги | ORU^R01 спостереження (IHE PCD), пропрієтарні | ADT для контексту пацієнта |
| Портал / додатки для пацієнтів | Дані, введені пацієнтом, доступ | FHIR Спостереження, анкети, повідомлення | FHIR читання результатів, записів на прийом, документів |
| Телемедицина | Відеовізити, віддалений моніторинг | FHIR Зустріч, Спостереження, ДокументПосилання | Запис на прийом, контекст пацієнта, запуск 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 (прийоми, виписки, переведення та оновлення демографічних даних, що розсилаються з МІС), замовлення та результати між ЕМК та лабораторією або радіологією, замовлення ліків та їх видачу, документи, такі як виписки, дані з моніторів, а також обмін результатами, призначеннями та домашніми вимірюваннями з пацієнтами через FHIR.
- ADT: кожна госпіталізація, виписка, переведення, реєстрація та оновлення демографічних даних (A01, A03, A02, A04, A08, A40 злиття) поширюються з HIS до всіх інших. Якщо ADT запізнюється або є неправильним, кожна наступна система записує дані під неправильним пацієнтом або випадком. Див. Пояснення повідомлень HL7 v2: ADT та ORU.
- Замовлення та результати: ORM/OML назовні, ORU назад, з номерами замовника та виконавця, що їх пов'язують; LOINC та UCUM у результатах. Див. Повідомлення про замовлення HL7 v2 та Інтеграція лабораторної системи з EHR.
- Візуалізація: замовлення до RIS, робочі списки DICOM до сканерів, зображення до PACS, звіти назад як ORU, переглядачі через DICOMweb. Див. PACS проти RIS проти VNA.
- Медикаменти: замовлення до аптеки, видача та введення назад, з замкненим циклом (штрих-код біля ліжка) як цільовою показником безпеки.
- Документи: виписні листи, операційні нотатки та скановані документи як повідомлення MDM, CDA або PDF до репозиторію документів, опубліковані до регіональних реєстрів.
- Пристрої: монітори, що передають життєві показники до запису через профілі IHE PCD або шлюзи виробника, з керуванням тривогою як окремою дисципліною.
- Орієнтовані на пацієнта: результати, записи на прийом та документи до порталу та додатків через FHIR; анкети, домашні вимірювання та дані з носимих пристроїв назад, з позначкою походження як дані, надані пацієнтом. Див. Віддалений моніторинг пацієнтів за допомогою FHIR.
Шаблони, що працюють
Працюючі шаблони інтеграції лікарень: одна головна система для ідентифікації пацієнта, з усіма іншими, що підписуються на ADT; зіставлення кодів з LOINC, SNOMED CT та ATC один раз на рушії; підтвердження, черги та повторні спроби для кожного повідомлення; ідемпотентні результати та документи; рівень FHIR для додатків пацієнтів та зовнішніх партнерів; та тестові середовища з синтетичними пацієнтами перед запуском.
- Один майстер для ідентичності. HIS (або головний індекс пацієнтів) володіє ідентифікаторами; всі інші підписуються на ADT і ніколи не створюють пацієнтів самостійно.
- Коди на межі. Зіставляйте локальні коди з LOINC, SNOMED CT, ATC на рушії, один раз, і зберігайте локальний код поруч.
- Підтвердження, черга, повторна спроба. Кожне повідомлення v2 отримує ACK; рушій зберігає та повторно надсилає; ніхто не втрачає результат через перезавантаження системи.
- Ідемпотентність. Результати та документи містять ідентифікатори; повторне надсилання оновлює, а не дублює.
- FHIR-рівень для всього нового. Додатки для пацієнтів, телемедицина, вибірки для досліджень та зовнішні партнери спілкуються через FHIR з фасадом або виділеним FHIR-сервером, що живиться від внутрішніх потоків, а не безпосередньо з HIS.
- Тестові середовища з синтетичними пацієнтами та етап відповідності (профілі IHE Connectathon, національні тестові набори) перед тим, як щось потрапить у продакшн.
Режими збоїв, що спостерігаються всюди
Режими збоїв, що спостерігаються майже в кожній лікарняній інтеграції: дублікати пацієнтів через помилки при реєстрації, результати, що потрапили до неправильного прийому після злиття, незіставлені локальні коди, помилки часових зон та переходу на літній/зимовий час у часових мітках, одиниці вимірювання у вільному тексті, інтерфейси, що зупиняються мовчки без моніторингу, Z-сегменти від постачальників, що порушують парсери, та тимчасові CSV-канали, які ніколи не виводяться з експлуатації.
Дублювання пацієнтів через помилки при реєстрації; результати, записані до неправильного випадку після злиття; локальні тестові коди, які ніхто не зіставив; часові пояси та літній час у часових мітках повідомлень; одиниці вимірювання у вільному тексті; інтерфейс, який мовчки зупинився, і його ніхто не моніторив; специфічні для постачальника Z-сегменти, які порушують парсери; і "тимчасовий" CSV-канал, який працює досі через десять років.
Де FHIR змінює картину
FHIR змінює лікарняну інтеграцію на периферії, а не в ядрі. Всередині будівлі HL7 v2 та DICOM залишаються, оскільки аналізатори, сканери та застарілі модулі їх використовують; FHIR бере на себе доступ пацієнтів, додатки SMART on FHIR, підтримку прийняття рішень CDS Hooks, підписки, регіональний та національний обмін у рамках EHDS та TEFCA, а також витяги для досліджень.
Всередині, HL7 v2 та DICOM залишаються на роки, оскільки кожен аналізатор, сканер та застарілий модуль спілкуються ними. FHIR виграє на периферії: доступ пацієнтів, додатки, запущені всередині EHR (SMART on FHIR), підтримка прийняття рішень (CDS Hooks), підписки для інтеграції на основі подій, регіональний та національний обмін у рамках EHDS та TEFCA, а також вибірки для досліджень. Багато лікарень зараз використовують FHIR-сервер, що живиться від рушія, як свій інтеграційний шар для всього, що знаходиться за межами будівлі; див. Стандарти медичної інтероперабельності: карта.
В Anpheros
Платформа Anpheros знаходиться на периферії FHIR лікарняної інтеграції: це запис FHIR R4, до якого лікарня або клініка може записувати та читати дані за згодою пацієнта, що живиться інтеграцією лікарні через лабораторний конектор (HL7 v2 ORU, CSV або JSON), з веб-хуками та інформацією про походження для кожного джерела. Вона не замінює МІС чи рушій.
Anpheros Platform знаходиться на цій периферії: запис FHIR R4, до якого лікарня або клініка може записувати та читати дані за згодою пацієнта, що живиться від власної інтеграції лікарні ( лабораторний конектор приймає HL7 v2 ORU, CSV або JSON), з вебхуками для сповіщення про зміни та позначкою походження за джерелом. Він не замінює HIS або рушій; він надає пацієнту запис, який супроводжує його за межами будівлі.
Пов'язані сторінки
- Пояснення інтерфейсних рушіїв
- Як інтегрувати лабораторну систему з EHR
- Пояснення повідомлень HL7 v2: ADT та ORU
- PACS проти RIS проти VNA
- Віддалений моніторинг пацієнтів за допомогою FHIR
- Стандарти медичної інтероперабельності: карта
- Інтеграція клінічних систем з FHIR (сайт для розробників)
Джерела
- Набір продуктів HL7 Version 2
- Технічна документація IHE IT Infrastructure
- Домен IHE Devices (профілі Patient Care Device)
- HL7 FHIR R4: Messaging and workflow
- Посібник з реалізації HL7 v2 до FHIR
Поширені запитання
Чи варто новій лікарні інтегрувати все з FHIR?
Не все. Аналізатори, сканери та більшість віддільських систем спілкуються HL7 v2 та DICOM, і це не зміниться найближчим часом. Використовуйте FHIR для інтеграцій, орієнтованих на пацієнта, зовнішніх та нових, а для зв'язку використовуйте рушій.
Яка різниця між HIS та EHR?
Використання варіюється залежно від країни. HIS часто означає адміністративну та клінічну систему лікарні разом; EHR наголошує на клінічному записі. З точки зору інтеграції, обидва є системою, яка володіє ідентичністю, випадками та записом.
Скільки інтерфейсів має лікарня середнього розміру?
Зазвичай від п'ятдесяти до кількох сотень потоків повідомлень проходять через рушій, враховуючи кожен напрямок та кожну приймаючу систему. Екран моніторингу рушія — це місце, де живуть команди з інтеграції.
Хто відповідає за інтеграцію в лікарні?
Команда ІТ-інтеграції лікарні, зазвичай за підтримки постачальника рушія, та кожен постачальник відділення зі свого боку. Національні програми та профілі IHE зменшують, але не усувають проєктну роботу.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →