Rövid válasz: az interface engine (integrációs motor) egy middleware, amelyet egészségügyi üzenetek kezelésére terveztek. Számos protokollon hallgatózik (MLLP HL7 v2 esetén, HTTP FHIR és SOAP esetén, fájlok, adatbázisok, üzenetsorok), átalakítja az üzeneteket (mezőleképezés, kódfordítás, formátumkonverzió, például HL7 v2-ről FHIR-re), útvonalakat határoz meg egy vagy több célállomásra szűrőkkel, és sorokat, újrapróbálkozásokat, naplókat és műszerfalakat tart fenn, így egyetlen üzenet sem vész el, és minden hiba láthatóvá válik. A kórházak azért használnak ilyet, hogy minden rendszert csak egyszer kelljen az engine-hez csatlakoztatni, ahelyett, hogy minden rendszert minden más rendszerhez kellene csatlakoztatni. Az ismertebb termékek a Mirth Connect (NextGen Connect, történelmileg nyílt forráskódú), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion és még sok más; a felhőszolgáltatók felügyelt megfelelőket kínálnak.
Az építőelemek
Az interfészmotor építőkövei a következők: csatornák (egy forrásból a célállomásokra irányuló áramlás), forrás-összekötők vagy figyelők, mint például az MLLP és az HTTP, szűrők, amelyek eldöntik, hogy egy üzenet továbbhalad-e, transzformátorok, amelyek mezőket és kódokat képeznek le, cél-összekötők, sorok újraküldéssel, figyelés riasztásokkal, valamint a csatornaváltoztatások és az üzenetelőzmények auditnaplója.
Minden engine, bármilyen szókincset is használ, ugyanazokkal az alkatrészekkel rendelkezik:
- Csatorna (interface): egyetlen áramlás egy forrásból egy vagy több célállomásra, saját beállításokkal és statisztikákkal.
- Forrás csatlakozó / figyelő: MLLP (TCP keretezéssel HL7 v2 esetén), HTTP(S) végpontok, SFTP és fájl lekérdezés, adatbázis lekérdezések, JMS vagy más üzenetsorok, DICOM egyes termékekben.
- Szűrő: egy szabály, amely eldönti, hogy az üzenet folytatódik-e (csak ADT^A01 ehhez a betegosztályhoz).
- Átalakító: szkriptek vagy leképezések, amelyek módosítják az üzenetet: átnevezik a mezőket, helyi kódokat LOINC-ra képeznek le egy lekérdezési táblán keresztül, FHIR Observation-t építenek egy OBX szegmensből, hozzáadnak egy Z-szegmenst, amelyet egy régi rendszer vár.
- Cél csatlakozó: ahová az eredmény kerül, saját protokollal és hibakezeléssel.
- Sor és újrapróbálkozás: az üzenetek nyugtázásig megmaradnak; a hibák visszaugorva újrapróbálkoznak; a mérgező üzenetek egy hiba sorba kerülnek az emberek számára.
- Felügyelet és riasztás: csatornánkénti számlálók, késleltetés, hibaarányok, riasztások, ha egy csatorna elhallgat (a leginkább hasznos riasztás az egészségügyi integrációban).
- Napló: ki módosított melyik csatornát, és az üzenet története a hibaelhárításhoz, megőrzési és hozzáférési szabályokkal, mivel ez betegadat.
Tipikus feladatok
Az egészségügyi interfészmotor tipikus feladatai közé tartozik az ADT-k elosztása a HIS-ből a részlegekre, a laboratóriumi eredmények több fogadóhoz történő útválasztása, a helyi kódok LOINC, ATC és UCUM formátumra való fordítása, az HL7 v2, FHIR, CDA és CSV formátumok közötti hídépítés, egy FHIR homlokzat kiépítése egy örökölt adatbázis fölé, az eszközadatok normalizálása, valamint az MLLP belsőleg HTTPS-re való adaptálása külsőleg.
- ADT fan-out: felvételek fogadása a HIS-től, osztályonkénti szűrés és fordítás, továbbítás a laboratóriumba, radiológiára, gyógyszertárba, ágykezeléshez és a betegportálra.
- Eredmények útvonalának meghatározása: ORU az LIS-től az EHR-hez, a rendelő háziorvos rendszeréhez, a regionális nyilvántartáshoz, a beteg FHIR nyilvántartásához, mindegyik más alhalmazzal és formátummal.
- Kódfordítás: helyi tesztkódok LOINC-ra, helyi gyógyszerkódok ATC-ra, szabad szöveges egységek UCUM-ra, karbantartott lekérdezési táblákon keresztül (laboratóriumi kódok leképezése LOINC-ra).
- Formátumhíd: HL7 v2 FHIR-re és vissza, CDA FHIR-re, CSV egy régi rendszerből bármire.
- FHIR homlokzat: az engine FHIR végpontokat tesz elérhetővé, és ezekre válaszol a régi adatbázis lekérdezésével vagy v2 lekérdezések küldésével, így az alkalmazások egy FHIR szervert látnak, ahol nincs is.
- Eszközintegráció: szabadalmaztatott monitor-táplálékok normalizálva IHE PCD megfigyelésekre.
- Protokoll adaptáció: MLLP az épületen belül, HTTPS OAuth-val kívülre.
Egy kiválasztása
Az interfészmotor kiválasztása hat kritériumra vezethető vissza: üzenetforgalom és a késleltetés, valamint a kimaradások fontossága, az azonnal támogatott protokollok és szabványok (HL7 v2, FHIR R4, DICOM, nemzeti formátumok), a fejlesztői tapasztalat, a műveletek, mint például a fürtözés és a hibaelhárítás, a licencelési feltételek, amelyek 2025-ben néhány termék esetében változtak, valamint a csatornák karbantartásához rendelkezésre álló készségek.
- Forgalom és kritikus fontosság: üzenetek naponta, elfogadható késleltetés, és hogy egy kétperces kimaradás számít-e (ADT és eredmények esetén igen).
- Protokollok és szabványok azonnal: HL7 v2 verziók és elemzők, FHIR R4 támogatás validálással, DICOM, X12 az USA-ban, nemzeti formátumok.
- Fejlesztői élmény: szkriptnyelv (JavaScript Mirth-ben, saját másokban), csatorna definíciók verziókövetése, teszt eszközök, üzembe helyezés több környezetbe.
- Működés: klaszterezés, hibatűrés, felügyeleti integrációk, frissítési út, támogatási modell.
- Licencelés: nyílt forráskódú vagy közösségi kiadások, előfizetés csatornánként vagy magonként, felügyelt felhő ajánlatok; egyes történelmileg nyílt termékek licencelése 2025-ben változott, ezért ellenőrizze az aktuális feltételeket.
- Rendelkezésre álló készségek: az engine csak annyira jó, amennyire a csatornákat karbantartó emberek.
Biztonságos futtatás
Az interfészmotor biztonságos futtatása azt jelenti, hogy a csatornadefiníciókat verziókövetés alatt álló kódként kezeljük, szintetikus üzenetekkel teszteljük a gyártás előtt, a kódkeresőtáblákat nevesített tulajdonosokkal kezeljük, riasztást adunk, ha egy csatorna elhallgat, korlátozzuk és töröljük az üzenetelőzményeket, mert azok betegadatok, dokumentáljuk minden csatorna célját, és soha nem engedjük, hogy a motor legyen a rendszerrekord.
A csatorna definíciókat kódként kezelje: verziókövetésben, áttekintve, teszt és éles környezetben üzembe helyezve szintetikus üzenetekkel. A lekérdezési táblákat (kódleképezések) irányítás alatt tartsa tulajdonosokkal. Állítson be riasztásokat csendre, ne csak hibákra. Korlátozza a hozzáférést az üzenet történetéhez, amely betegadat, és ütemezetten törölje azt. Dokumentáljon minden csatorna célját és tulajdonosát; a dokumentálatlan csatorna az, amely leállítja egy osztályt, amikor a szerzője távozik. És soha ne engedje, hogy az engine legyen a nyilvántartás rendszere: adatokat mozgat és alakít át, nem birtokolja azokat.
Amikor nincs rá szüksége
Az interfészmotorra nincs szükség, ha egy új rendszer összes partnere FHIR-t használ, ebben az esetben egy FHIR szerver előfizetésekkel és egy API átjáróval fedezi az útválasztást és az autentikációt, vagy ha egyetlen HL7 v2 interfész kezelhető egy olyan könyvtárral, mint a HAPI HL7v2 vagy az hl7apy. A motor sok rendszerrel és formátummal érdemli ki a helyét.
Egy zöldmezős rendszer, amelynek partnerei mind FHIR-t beszélnek, használhat egy FHIR szervert előfizetésekkel és egy API átjáróval az autentikációhoz, sebességkorlátozáshoz és útvonalmeghatározáshoz, átalakításokkal szokásos szolgáltatásokban. Egyetlen HL7 v2 interfész kezelhető egy kis könyvtárral (HAPI HL7v2 Java-ban, hl7apy vagy python-hl7 Python-ban) az alkalmazáson belül. Az engine akkor érdemli meg a helyét, ha sok rendszer, sok formátum van, és szükség van egy működési konzolra, amelyet nem fejlesztők is figyelhetnek.
Anpheros-ban
Az Anpheros Platform az engine FHIR oldalán található: a kórházak az általuk megosztani kívánt áramlásokat (eredmények, dokumentumok, találkozók) az engine-jükön vagy a laboratóriumi csatlakozón keresztül irányítják oda, és FHIR API-kon és webhookokon keresztül olvassák vissza. A fejlesztői webhely bemutatja a HL7 v2-ről FHIR-re való leképezést, amelyet a csatlakozó alkalmaz.
Kapcsolódó oldalak
- Kórházi rendszerintegráció magyarázata
- Hogyan integráljunk egy laboratóriumi rendszert egy EHR-rel
- HL7 v2 üzenetek magyarázata: ADT és ORU
- Hogyan képezzünk le helyi laboratóriumi kódokat LOINC-ra
- FHIR előfizetések magyarázata
- HL7 v2-ről FHIR-re való leképezés (fejlesztői webhely)
Források
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- HAPI HL7v2 könyvtár
- HL7 v2-FHIR implementációs útmutató
Gyakori kérdések
Az interface engine ugyanaz, mint egy ESB vagy egy iPaaS?
Ugyanaz a család, de specializált: egy interface engine HL7 v2, DICOM, CDA és FHIR támogatással, MLLP-vel, egészségügyi specifikus felügyelettel és a csapatok által használt szókincs integrációval érkezik. Az általános ESB-k és iPaaS termékek több építéssel is elvégezhetik a feladatot.
Az engine automatikusan konvertálhatja a HL7 v2-t FHIR-re?
Több engine tartalmaz leképezéseket a HL7 v2-FHIR útmutató alapján, és kezelik a gyakori szegmenseket. A helyi konvenciók, Z-szegmensek és kódleképezések mindig projektmunkát igényelnek.
Az engine tárolja a betegadatokat?
Az üzeneteket átvitel közben megőrzi, és megőrzi az üzenet történetét a hibaelhárításhoz, ami betegadat, és védeni és törölni kell. Nem szabad hosszú távú tárolóként vagy nyilvántartási rendszerként használni.
Nyílt forráskódú vagy kereskedelmi?
Mindkettő működik nagy kórházakban. A döntés általában a támogatáson, a készségeken, a klaszterezési igényeken és az aktuális licencelési feltételeken múlik, amelyek egyes termékeknél változtak; ellenőrizze, mielőtt elkötelezi magát.
Próbálja ki ingyen a sandboxban
Az első FHIR-hívás 5 perc alatt. Egy HL7 FHIR R4 API, amely tartalmazza a beteg beleegyezését: próbáld ki a sandboxban, majd csatlakoztasd saját alkalmazásodat vagy klinikai rendszeredet.
Ingyenes · 30 szintetikus beteg · kártya nélkül
Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.
Tudj meg többet az Anpherosról →