Krátká odpověď: nemocnice provozuje desítky systémů a integrace je práce, která spočívá v tom, aby se tyto systémy shodly na jednom pacientovi. V centru sedí nemocniční informační systém (NIS) nebo elektronický zdravotní záznam (EHR), který spravuje identitu pacienta, přijetí a klinický záznam. Kolem něj jsou: laboratorní systém (LIS), radiologický systém (RIS a PACS), lékárna, operační sály, pohotovost, fakturace, přístroje (monitory, infuzní pumpy) a stále častěji pacientské aplikace, nositelná zařízení a telemedicína. Integrační engine uprostřed přijímá, transformuje a směruje zprávy, takže každý systém je připojen pouze jednou, nikoli ke všem ostatním. Komunikace probíhá převážně ve formátu HL7 v2 zpráv přes MLLP pro události (přijetí, objednávky, výsledky), DICOM pro obrazy, CDA nebo PDF pro dokumenty a FHIR přes REST pro cokoli nového, směřujícího k pacientovi nebo externího.
Systémy a co si vyměňují
Integrační prostředí nemocnice se skládá z nemocničního informačního systému (NIS) nebo elektronického zdravotního záznamu (EHR), který spravuje identitu pacienta, jeho návštěvy a klinické záznamy, dále z laboratorního systému, radiologie (RIS a PACS), lékárny, přístrojů, pacientských aplikací, telemedicíny a regionálních systémů. Tyto systémy si vyměňují zprávy HL7 v2, jako jsou ADT (příjem, propuštění, převod), objednávky a výsledky ORU, snímky DICOM, dokumenty CDA a zdroje FHIR.
| Systém | Vlastní | Odesílá | Přijímá |
|---|---|---|---|
| NIS / EHR | Identita pacienta, návštěvy, objednávky, klinický záznam | ADT (přijetí, převody), ORM/OML objednávky, SIU plánování | ORU výsledky, MDM dokumenty, DFT poplatky |
| LIS (laboratoř) | Vzorky, analýzy, výsledky, referenční rozsahy | ORU^R01 výsledky, ORR odpovědi na objednávky | ORM/OML objednávky, ADT pro demografické údaje |
| RIS / PACS | Objednávky zobrazovacích metod, pracovní seznamy, zprávy, obrazy | ORU zprávy, DICOM pro prohlížeče, SIU | ORM/OMI objednávky, ADT; DICOM MWL pro modalitní přístroje |
| Lékárna | Seznam léků, výdej, sklad | RDS výdej, RAS podání | OMP/RDE objednávky léků, ADT |
| Přístroje a monitory | Životní funkce, křivky, alarmy | ORU^R01 pozorování (IHE PCD), proprietární | ADT pro kontext pacienta |
| Pacientský portál / aplikace | Data zadaná pacientem, přístup | FHIR Observations, dotazníky, zprávy | FHIR čtení výsledků, schůzek, dokumentů |
| Telemedicína | Video návštěvy, vzdálené monitorování | FHIR Encounter, Observation, DocumentReference | Schůzka, kontext pacienta, SMART spuštění |
| Regionální a národní systémy | Sdílené záznamy, registry, elektronické recepty | CDA dokumenty (XDS), FHIR, národní zprávy | Dotazy, oznámení |
Integrační engine
Integrační engine je komunikační centrum nemocnice: přijímá zprávy HL7 v2, FHIR, soubory a databázový provoz z každého systému, transformuje je a směruje do všech ostatních systémů, které je potřebují, a spravuje fronty, opakované pokusy, monitorování a audit. Bez něj N systémů potřebuje až N×(N−1)/2 ručně vytvořených rozhraní; s jedním se každý systém připojí pouze jednou.
Engine (např. Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare a IRIS for Health, Infor Cloverleaf, Qvera QIE) poskytuje posluchače (MLLP, HTTP, soubory, databáze), transformace (mapování polí, oprava kódů, převod v2 na FHIR), směrování (odeslání ADT do osmi systémů s osmi filtry), fronty a opakované pokusy, monitorování a audit. Je to také místo, kde se identita pacienta sjednocuje, když se systémy neshodnou, a kde se často buduje FHIR fasáda nad starší databází. Viz Vysvětlení integračních enginů.
Toky, na kterých nejvíce záleží
Nejdůležitější integrační toky v nemocnici jsou ADT (příjem, propuštění, převody a aktualizace demografických údajů šířené z NIS), objednávky a výsledky mezi EHR a laboratoří nebo radiologií, objednávky léků a jejich výdej, dokumenty jako propouštěcí zprávy, data z monitorovacích přístrojů a výměna výsledků, termínů a domácích měření s pacienty přes FHIR.
- ADT: každé přijetí, propuštění, převod, registrace a aktualizace demografických údajů (A01, A03, A02, A04, A08, A40 sloučení) se šíří z NIS do všech ostatních. Pokud je ADT pozdní nebo nesprávné, každý navazující systém ukládá data pod nesprávného pacienta nebo návštěvu. Viz Vysvětlení zpráv HL7 v2: ADT a ORU.
- Objednávky a výsledky: ORM/OML ven, ORU zpět, s čísly zadavatele a zpracovatele, které je spojují; LOINC a UCUM ve výsledcích. Viz Zprávy o objednávkách HL7 v2 a Integrace laboratorního systému s EHR.
- Zobrazovací metody: objednávky do RIS, DICOM pracovní seznamy do skenerů, obrazy do PACS, zprávy zpět jako ORU, prohlížeče přes DICOMweb. Viz PACS vs RIS vs VNA.
- Léky: objednávky do lékárny, výdej a podání zpět, s uzavřenou smyčkou (čárový kód u lůžka) jako bezpečnostní cíl.
- Dokumenty: propouštěcí zprávy, operační poznámky a naskenované dokumenty jako MDM zprávy, CDA nebo PDF do repozitáře dokumentů, publikované do regionálních registrů.
- Přístroje: monitory dodávající životní funkce do záznamu prostřednictvím profilů IHE PCD nebo bran dodavatelů, s řízením alarmů jako samostatnou disciplínou.
- Směrem k pacientovi: výsledky, schůzky a dokumenty do portálu a aplikací přes FHIR; dotazníky, domácí měření a data z nositelných zařízení zpět, s označením původu jako data nahlášená pacientem. Viz Vzdálené monitorování pacientů s FHIR.
Fungující vzory
Funkční integrační vzory v nemocnicích jsou: jeden hlavní systém pro identitu pacienta, kde se všichni ostatní přihlašují k odběru ADT; mapování kódů na LOINC, SNOMED CT a ATC jednou v enginu; potvrzení, fronty a opakované pokusy pro každou zprávu; idempotentní výsledky a dokumenty; vrstva FHIR pro pacientské aplikace a externí partnery; a testovací prostředí se syntetickými pacienty před spuštěním.
- Jeden hlavní zdroj pro identitu. NIS (nebo hlavní index pacienta) vlastní identifikátory; všichni ostatní se přihlašují k odběru ADT a nikdy si pacienty nevymýšlejí.
- Kódy na hranici. Mapujte lokální kódy na LOINC, SNOMED CT, ATC v enginu, jednou, a ponechte si lokální kód vedle.
- Potvrzení, fronta, opakování. Každá zpráva v2 dostane ACK; engine ukládá a znovu přehrává; nikdo neztratí výsledek, protože se systém restartoval.
- Idempotence. Výsledky a dokumenty nesou identifikátory; opakované přehrání aktualizuje, nikoli duplikuje.
- Vrstva FHIR pro vše nové. Pacientské aplikace, telemedicína, výzkumné extrakty a externí partneři komunikují přes FHIR s fasádou nebo dedikovaným FHIR serverem napájeným z interních toků, nikoli přímo s NIS.
- Testovací prostředí se syntetickými pacienty a krok ověření shody (profily IHE Connectathon, národní testovací sady) předtím, než se cokoli dostane do produkce.
Režimy selhání viděné všude
Chybové stavy, které se vyskytují téměř v každé nemocniční integraci, jsou duplicitní pacienti kvůli překlepům při registraci, výsledky přiřazené k nesprávné návštěvě po sloučení, nemapované lokální kódy, chyby časových zón a letního času v časových značkách, jednotky v textovém formátu, rozhraní, která se tiše zastaví bez monitorování, vendor specifické Z-segmenty, které narušují parsery, a dočasné CSV soubory, které se nikdy neodstraní.
Duplicitní pacienti z překlepů při registraci; výsledky uložené k nesprávné návštěvě po sloučení; lokální testovací kódy, které nikdo nemapoval; časová pásma a letní čas v časových značkách zpráv; jednotky v textu; rozhraní, které tiše přestalo fungovat a nikdo ho neměl monitorované; specifické Z-segmenty dodavatele, které rozbíjejí analyzátory; a "dočasný" CSV feed, který běží ještě deset let poté.
Kde FHIR mění situaci
FHIR mění nemocniční integraci spíše na okrajích než v jádru. Uvnitř budovy zůstávají HL7 v2 a DICOM, protože analyzátory, skenery a starší moduly s nimi komunikují; FHIR přebírá přístup pacienta, aplikace SMART on FHIR, podpora rozhodování CDS Hooks, odběry (Subscriptions), regionální a národní výměnu v rámci EHDS a TEFCA a extrakci dat pro výzkum.
Interně HL7 v2 a DICOM zůstávají roky, protože každý analyzátor, skener a starší modul s nimi komunikuje. FHIR vítězí na okrajích: přístup pacienta, aplikace spouštěné uvnitř EHR (SMART on FHIR), podpora rozhodování (CDS Hooks), odběry pro integraci řízenou událostmi, regionální a národní výměna v rámci EHDS a TEFCA a výzkumné extrakty. Mnoho nemocnic nyní provozuje FHIR server napájený enginem jako svou integrační vrstvu pro vše mimo budovu; viz Standardy interoperability ve zdravotnictví: mapa.
V Anpheros
Platforma Anpheros se nachází na FHIR okraji nemocniční integrace: záznam FHIR R4, do kterého může nemocnice nebo klinika zapisovat a ze kterého může číst s pacientovým souhlasem, napájený vlastní integrací nemocnice přes konektor laboratoře (HL7 v2 ORU, CSV nebo JSON), s webovými háčky a údaji o původu pro každý zdroj. Nenahrazuje NIS ani engine.
Anpheros Platform sedí na tomto okraji: záznam FHIR R4, do kterého může nemocnice nebo klinika zapisovat a ze kterého může číst s pacientovým souhlasem, napájený vlastní integrací nemocnice ( konektor laboratoře přijímá HL7 v2 ORU, CSV nebo JSON), s webhooky pro oznámení o změnách a informacemi o původu pro každý zdroj. Nenahrazuje NIS ani engine; dává pacientovi záznam, který ho doprovází mimo budovu.
Související stránky
- Vysvětlení integračních enginů
- Jak integrovat laboratorní systém s EHR
- Vysvětlení zpráv HL7 v2: ADT a ORU
- PACS vs RIS vs VNA
- Vzdálené monitorování pacientů s FHIR
- Standardy interoperability ve zdravotnictví: mapa
- Integrace klinických systémů s FHIR (vývojářský web)
Zdroje
- Produktová sada HL7 verze 2
- Technický rámec IHE IT Infrastructure
- Doména IHE Devices (profily Patient Care Device)
- HL7 FHIR R4: Messaging and workflow
- Implementační příručka HL7 v2-to-FHIR
Časté otázky
Měla by nová nemocnice integrovat vše s FHIR?
Ne všechno. Analyzátory, skenery a většina oddělení systémů mluví HL7 v2 a DICOM, a to se brzy nezmění. Použijte FHIR pro integrace směřující k pacientovi, externí a nové integrace a engine pro propojení.
Jaký je rozdíl mezi NIS a EHR?
Použití se liší podle země. NIS často znamená administrativní a klinický nemocniční systém dohromady; EHR klade důraz na klinický záznam. Z hlediska integrace jsou oba systémy, které vlastní identitu, návštěvy a záznam.
Kolik rozhraní má středně velká nemocnice?
Typicky mezi padesáti a několika stovkami komunikačních toků prochází enginem, počítáno pro každý směr a každý přijímající systém. Obrazovka monitorování enginu je místem, kde žijí integrační týmy.
Kdo vlastní integraci v nemocnici?
IT integrační tým nemocnice, obvykle s podporou dodavatele enginu, a každý dodavatel oddělení za svou stranu. Národní programy a profily IHE snižují, ale neodstraňují projektovou práci.
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

