Krátká odpověď: integrační engine (interface engine) je middleware navržený pro zdravotnickou výměnu zpráv. Naslouchá na mnoha protokolech (MLLP pro HL7 v2, HTTP pro FHIR a SOAP, soubory, databáze, fronty), transformuje zprávy (mapování polí, překlad kódů, konverze formátů jako HL7 v2 na FHIR), směruje je na jedno nebo více míst s filtry a udržuje fronty, opakované pokusy, logy a přehledy, aby se zajistilo, že žádná zpráva neztratí a každý problém je viditelný. Nemocnice jej používají, aby každý systém byl připojen k enginu pouze jednou, místo aby byl připojen ke všem ostatním systémům. Mezi známé produkty patří Mirth Connect (NextGen Connect, historicky open source), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion a mnoho dalších; cloudoví poskytovatelé nabízejí spravované ekvivalenty.
Stavební kameny
Základními stavebními kameny rozhraní jsou kanály (jeden tok ze zdroje do jeho cílů), zdrojové konektory nebo posluchače, jako je MLLP a HTTP, filtry, které rozhodují, zda zpráva pokračuje, transformátory, které mapují pole a kódy, cílové konektory, fronty s opakovaným pokusem, monitorování s upozorněním a sledování změn kanálů a historie zpráv.
Každý engine, bez ohledu na slovník, má stejné části:
- Kanál (interface): jeden tok ze zdroje do jednoho nebo více cílů s vlastními nastaveními a statistikami.
- Zdrojový konektor / posluchač: MLLP (TCP s rámováním pro HL7 v2), koncové body HTTP(S), SFTP a dotazování souborů, databázové dotazy, fronty JMS nebo jiné, DICOM v některých produktech.
- Filtr: pravidlo, které rozhoduje, zda zpráva pokračuje (pouze ADT^A01 pro tuto třídu pacientů).
- Transformátor: skripty nebo mapování, které mění zprávu: přejmenování polí, mapování lokálních kódů na LOINC prostřednictvím vyhledávací tabulky, sestavení FHIR Observation z OBX segmentu, přidání Z-segmentu, který očekává starší systém.
- Cílový konektor: kam jde výsledek, s vlastním protokolem a zpracováním chyb.
- Fronta a opakované pokusy: zprávy přetrvávají, dokud nejsou potvrzeny; neúspěšné pokusy se opakují s postupným zpožděním; "jedovaté" zprávy končí ve frontě chyb pro lidi.
- Monitorování a upozornění: počítadla na kanál, latence, chybovost, upozornění, když kanál ztichne (nejužitečnější upozornění ve zdravotnické integraci).
- Audit: kdo změnil který kanál a historie zpráv pro řešení problémů, s uchováváním a kontrolou přístupu, protože se jedná o data pacienta.
Typické úlohy
Typickými úlohami rozhraní ve zdravotnictví jsou ADT fan-out z HIS do oddělení, směrování laboratorních výsledků k několika příjemcům, překlad lokálních kódů na LOINC, ATC a UCUM, propojování formátů HL7 v2, FHIR, CDA a CSV, vystavení FHIR fasády nad starší databází, normalizace dat ze zařízení a adaptace MLLP uvnitř na HTTPS venku.
- ADT fan-out: příjem přijetí z HIS, filtrování a překlad pro každé oddělení, doručení do laboratoře, radiologie, lékárny, správy lůžek a pacientského portálu.
- Směrování výsledků: ORU z LIS do EHR, do systému objednávajícího praktického lékaře, do regionálního záznamu, do FHIR záznamu pacienta, každý s jinou podmnožinou a formátem.
- Překlad kódů: lokální testovací kódy na LOINC, lokální kódy léků na ATC, jednotky volného textu na UCUM, prostřednictvím spravovaných vyhledávacích tabulek (mapování laboratorních kódů na LOINC).
- Přemostění formátů: HL7 v2 na FHIR a zpět, CDA na FHIR, CSV ze starého systému na cokoli.
- FHIR fasáda: engine vystavuje FHIR koncové body a odpovídá na ně dotazováním starší databáze nebo odesíláním dotazů v2, takže aplikace vidí FHIR server, kde žádný neexistuje.
- Integrace zařízení: proprietární monitorovací kanály normalizované na IHE PCD pozorování.
- Adaptace protokolu: MLLP uvnitř budovy, HTTPS s OAuth venku.
Výběr jednoho
Výběr rozhraní závisí na šesti kritériích: objem zpráv a jak kritická je latence a výpadky, protokoly a standardy podporované ihned (HL7 v2, FHIR R4, DICOM, národní formáty), zkušenosti vývojářů, operace, jako je klastrování a převzetí služeb při selhání, licenční podmínky, které se u některých produktů změnily v roce 2025, a dostupné dovednosti pro údržbu kanálů.
- Objem a kritičnost: zprávy za den, přijatelná latence a zda dvouminutový výpadek má význam (pro ADT a výsledky ano).
- Protokoly a standardy ihned k dispozici: verze a parsery HL7 v2, podpora FHIR R4 s validací, DICOM, X12 v USA, národní formáty.
- Zkušenost vývojářů: skriptovací jazyk (JavaScript v Mirth, proprietární v jiných), správa verzí definic kanálů, testovací nástroje, nasazení do několika prostředí.
- Provoz: klastrování, převzetí služeb při selhání, integrace monitorování, cesta k upgradu, model podpory.
- Licencování: open source nebo komunitní edice, předplatné na kanál nebo na jádro, spravované cloudové nabídky; licencování některých historicky otevřených produktů se v roce 2025 změnilo, proto si ověřte aktuální podmínky.
- Dostupné dovednosti: engine je jen tak dobrý, jak dobří jsou lidé, kteří spravují kanály.
Bezpečné spuštění jednoho
Bezpečné spuštění rozhraní znamená považovat definice kanálů za kód pod verzovacím systémem, testování se syntetickými zprávami před produkcí, správu tabulek vyhledávání kódu s určenými vlastníky, upozornění, když kanál ztichne, omezení a čištění historie zpráv, protože se jedná o data pacienta, dokumentování účelu každého kanálu a nikdy nenechat rozhraní stát se systémem záznamu.
Definice kanálů považujte za kód: ve správě verzí, revidované, nasazené přes testovací a staging prostředí se syntetickými zprávami. Vyhledávací tabulky (mapování kódů) udržujte pod správou s vlastníky. Nastavte upozornění na ticho, nejen na chyby. Omezte přístup k historii zpráv, což jsou data pacienta, a pravidelně je mažte. Zdokumentujte účel a vlastníka každého kanálu; nedokumentovaný kanál je ten, který zastaví oddělení, když odejde jeho autor. A nikdy nedovolte, aby se engine stal systémem záznamu: přesouvá a transformuje data, nevlastní je.
Kdy jeden nepotřebujete
Rozhraní není potřeba, když všichni partneři nového systému komunikují ve FHIR, v takovém případě FHIR server s odběry (Subscriptions) a API brána pokrývají směrování a autentizaci, nebo když lze jedno HL7 v2 rozhraní zvládnout pomocí knihovny, jako je HAPI HL7v2 nebo hl7apy. Rozhraní si své místo zaslouží při práci s mnoha systémy a formáty.
Nový systém, jehož partneři mluví všichni FHIR, může použít FHIR server s předplatnými (Subscriptions) a API bránu pro autentizaci, omezení rychlosti a směrování, s transformacemi v běžných službách. Jedno HL7 v2 rozhraní lze zvládnout malou knihovnou (HAPI HL7v2 v Javě, hl7apy nebo python-hl7 v Pythonu) uvnitř aplikace. Engine si své místo zaslouží, když existuje mnoho systémů, mnoho formátů a potřeba operační konzole, kterou mohou sledovat i ne-vývojáři.
V Anpheros
Anpheros Platform je na straně enginu orientované na FHIR: nemocnice směrují toky, které chtějí sdílet (výsledky, dokumenty, setkání), prostřednictvím svého enginu nebo prostřednictvím konektoru laboratoře a čtou zpět prostřednictvím FHIR API a webhooků. Stránka pro vývojáře ukazuje mapování HL7 v2 na FHIR, které konektor aplikuje.
Související stránky
- Integrace nemocničních systémů vysvětlena
- Jak integrovat laboratorní systém s EHR
- HL7 v2 zprávy vysvětleny: ADT a ORU
- Jak mapovat lokální laboratorní kódy na LOINC
- FHIR Subscriptions vysvětleny
- Mapování HL7 v2 na FHIR (stránka pro vývojáře)
Zdroje
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- HAPI HL7v2 knihovna
- Implementační příručka HL7 v2-to-FHIR
Časté otázky
Je integrační engine stejný jako ESB nebo iPaaS?
Stejná rodina, specializovaná: integrační engine přichází s podporou HL7 v2, DICOM, CDA a FHIR, MLLP, monitorováním specifickým pro zdravotnictví a integračními týmy pro slovník. Obecné ESB a iPaaS produkty mohou s více úsilím zvládnout úkol.
Může engine automaticky převést HL7 v2 na FHIR?
Několik enginů obsahuje mapování založené na příručce HL7 v2-to-FHIR a zvládnou běžné segmenty. Lokální konvence, Z-segmenty a mapování kódů vždy vyžadují projektovou práci.
Ukládá engine data pacienta?
Perzistentně ukládá zprávy během přenosu a uchovává historii zpráv pro řešení problémů, což jsou data pacienta a musí být chráněna a mazána. Neměl by být používán jako dlouhodobé úložiště nebo systém záznamu.
Open source nebo komerční?
Oba jsou v provozu ve velkých nemocnicích. Rozhodnutí se obvykle týká podpory, dovedností, potřeb klastrování a aktuálních licenčních podmínek, které se pro některé produkty změnily; před závazkem si je ověřte.
Vyzkoušejte zdarma v sandboxu
První volání FHIR za 5 minut. API standardu HL7 FHIR R4 s integrovaným souhlasem pacienta: vyzkoušejte si ho v sandboxu a poté propojte svou vlastní aplikaci nebo klinický systém.
Zdarma · 30 syntetických pacientů · bez karty
Anpheros vytváří zdravotní záznamy, které pacient ovládá a může sdílet s jakoukoli klinikou, na platformě HL7 FHIR R4 se sídlem v EU. Tyto průvodce vám pomohou porozumět vašemu zdraví a uspořádat si ho; nenahrazují vašeho lékaře.
O Anpheros →