Krátká odpověď: laboratorní rozhraní má dva směry. Požadavky jdou z EHR do laboratorního informačního systému (LIS) jako zprávy HL7 v2 ORM^O01 nebo OML^O21 (nebo jako FHIR ServiceRequest) a LIS odpovídá pomocí ORR/ORL a později výsledky jako ORU^R01 (nebo FHIR DiagnosticReport s Observations). Těžké nejsou zprávy, ale detaily v nich: placer a filler čísla, která spojují výsledky s požadavky, stav výsledku (předběžný, finální, opravený), příznaky abnormality, jednotky a referenční rozsahy, informace o vzorku, mikrobiologie s vícedílnými výsledky a mapování kódů na LOINC. Pokud je to provedeno dobře, každý výsledek se dostane ke správnému pacientovi, ke správnému požadavku a na správné místo v dokumentaci, s nezměněným významem.
Krok 1: Dohodněte si toky
Prvním krokem při integraci laboratorního informačního systému s EHR je dohoda s laboratoří o tom, které toky existují: výstupní žádanky, aktualizace stavu žádanky, vstup výsledků, opravy, zrušení, doplňkové a reflexní testy a přenos demografických údajů ADT do LIS. Strany si také stanoví verzi HL7, obvykle 2.3.1 nebo 2.5.1, a transport, obvykle MLLP s potvrzením.
Rozhodněte se s laboratoří, které toky existují: požadavky ven (nebo laboratoř přijímá papír a registruje se sama?), aktualizace stavu požadavků, výsledky dovnitř, opravy, zrušení, doplňkové testy, reflexní testy a demografické údaje (ADT feed do LIS, aby věděl o pacientovi před příjezdem vzorku). Nakreslete sekvenci pro normální výsledek, opravený výsledek a zrušený požadavek. Rozhodněte se pro verzi HL7 (nejběžnější jsou 2.3.1 a 2.5.1) a transport (MLLP s ACK; někdy soubory). Viz HL7 v2 zprávy o požadavcích.
Krok 2: Zpráva s výsledky, pole po poli
Výsledek z laboratoře dorazí do EHR jako zpráva HL7 v2 ORU^R01: MSH identifikuje odesílatele a příjemce, PID pacienta, PV1 návštěvu, ORC a OBR nesou čísla žádanky od zadavatele a provádějícího, objednaný panel a stav zprávy a každá OBX obsahuje jeden analyt s kódem LOINC, hodnotou, jednotkami, referenčním rozsahem, příznakem abnormality a stavem výsledku.
MSH|^~\&|LIS|CENTRALLAB|EHR|GENHOSP|20260314130500||ORU^R01^ORU_R01|RES0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F
PV1|1|O|CLINIC-3^^^GENHOSP
ORC|RE|PLC-778812^EHR|FIL-556701^LIS|||||||||42^SMITH^JOHN
OBR|1|PLC-778812^EHR|FIL-556701^LIS|58410-2^CBC panel - Blood by Automated count^LN|||20260314084000|||||||||42^SMITH^JOHN||||||20260314130000|||F
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||10.9|g/dL|12.0-15.5|L|||F|||20260314125800
OBX|2|NM|6690-2^Leukocytes [#/volume] in Blood by Automated count^LN||6.4|10*3/uL|4.0-10.0|N|||F|||20260314125800
OBX|3|NM|777-3^Platelets [#/volume] in Blood by Automated count^LN||230|10*3/uL|150-400|N|||F|||20260314125800
NTE|1||Mild normocytic anaemia; suggest iron studies if clinically indicated.
- ORC-2 / OBR-2 placer number a ORC-3 / OBR-3 filler number: spojení s požadavkem. OBR-4: panel, kódovaný (LOINC
LN). OBR-7: čas odběru vzorku. OBR-22: čas vydání zprávy s výsledky. OBR-25: stav výsledku pro celý požadavek (Ppředběžný,Ffinální,Copravený,Xzrušený). - OBX-2: typ hodnoty (
NMnumerický,STřetězec,TXtext,CE/CWEkódovaný,SNstrukturovaný numerický jako<^5). OBX-3: analyzovaná látka, kódovaná. OBX-5: hodnota. OBX-6: jednotky, ideálně UCUM (10*3/uL, neK/µL). OBX-7: referenční rozsah jako text. OBX-8: příznaky abnormality (L,H,LL,HH,A,N). OBX-11: stav výsledku pro každou analyzovanou látku (P,F,C,X,Dsmazáno). OBX-14: čas pozorování. OBX-19: čas analýzy. - NTE: komentáře, připojené k OBR nebo ke konkrétnímu OBX podle pozice.
- SPM (2.5+): typ vzorku (SNOMED CT), čas odběru, čas přijetí, stav.
Krok 3: Zvláštní případy
Zvláštní případy, které musí laboratorní rozhraní řešit, jsou opravené výsledky (stav C s původními čísly žádanky, nahrazující a upozorňující spíše než mazající), předběžné a následně finální výsledky, mikrobiologie s organismy a citlivostmi spojenými pod-ID, textové výsledky a vložená PDF, reflexní a doplňkové testy, zrušení a jednotky a referenční rozsahy, které se mění při výměně analyzátorů v laboratoři.
- Opravy: nová ORU s
Cv OBR-25 a OBX-11 a stejnými placer/filler čísly; EHR musí nahradit, označit změnu a upozornit lékaře. Nikdy neignorujte původní záznam. - Předběžné a pak finální: výsledky
P(Gramovo barvení) následovanéF(kultura); dokumentace musí zobrazovat stav. - Mikrobiologie: jeden OBX pro identifikovaný organismus (kódovaný, SNOMED CT), pak výsledky citlivosti jako OBX pro každý antibiotikum s organismem jako pod-ID (OBX-4), často napříč několika zprávami. Zde se skrývá většina chyb rozhraní.
- Textové výsledky a PDF: patologické a některé chemické komentáře přicházejí jako TX řádky nebo jako vložené PDF (OBX-2
ED); dokumentace potřebuje text i soubor. - Reflexní a doplňkové testy: nové OBR pod původním požadavkem, nebo nový požadavek vytvořený laboratoří; dohodněte se, jak budou číslovány.
- Zrušení: stav
X, s původními čísly. - Jednotky a rozsahy podle analyzátoru: stejný test může změnit jednotky, když laboratoř změní analyzátory; rozhraní musí nést rozsah s každým výsledkem, ne ho předpokládat.
Krok 4: kódy
Mapování kódů v laboratorním rozhraní znamená jednorázový překlad lokálních laboratorních kódů testů na LOINC v udržované tabulce a odeslání lokálního i LOINC kódu v OBX-3, normalizaci jednotek na UCUM a kódování typů vzorků a organismů v SNOMED CT. Bez tohoto mapování nelze výsledky trendovat napříč laboratořemi ani je číst externími systémy.
Mapujte kódy testů laboratoře na LOINC jednou, v udržované tabulce, a posílejte lokální i LOINC kódy v OBX-3 (GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN). Normalizujte jednotky na UCUM. Typy vzorků a organismy v SNOMED CT. Metoda je v Jak mapovat lokální laboratorní kódy na LOINC; bez ní nelze výsledky trendovat napříč laboratořemi ani je číst externím systémem.
Krok 5: Alternativa FHIR
Alternativou FHIR k laboratornímu rozhraní HL7 v2 je použití ServiceRequest pro žádanku, jedno Observation na analyt s kódem LOINC, kvantitou UCUM, referenčním rozsahem a interpretací, a DiagnosticReport, který je seskupuje se stavem, provádějícím, časem vydání, závěrem a PDF. Dodání je formou REST zápisů, transakčního Bundle na zprávu, nebo FHIR Subscriptions.
S FHIR je požadavek ServiceRequest, výsledky jsou Observations (jedna na analyzovanou látku, LOINC kód, UCUM kvantita, referenceRange, interpretation) seskupené DiagnosticReport, který nese stav, vykonavatele, čas vydání, závěr a PDF, s basedOn odkazujícím na ServiceRequest. Opravy jsou verze stejných zdrojů se stavem amended nebo corrected. Dodání je REST zápisy na FHIR server EHR, transakční Bundle na zprávu, nebo Subscriptions. Průvodce HL7 v2-to-FHIR mapuje každé pole výše; mnoho laboratoří nyní nabízí obojí. Viz FHIR DiagnosticReport vysvětleno a FHIR Observation vysvětleno.
Krok 6: testování a spuštění
Testování laboratorního rozhraní před spuštěním znamená zpracování syntetických pacientů přes všechny zvláštní případy, porovnání jednoho dne paralelních výsledků mezi laboratorní zprávou a kartou EHR, kontrolu časových pásem a přechodů na letní čas, ověření zpracování potvrzení a opakování po výpadku a dohodu o postupu pro případ selhání zpráv, s využitím profilu Laboratory Testing Workflow od IHE jako základu.
Testujte s umělými pacienty přes všechny případy v kroku 3; porovnejte den paralelních výsledků mezi papírovou nebo PDF zprávou a dokumentací; zkontrolujte časová pásma a přechody na letní čas; ověřte zpracování ACK a opakování po výpadku; dohodněte si pohotovostní postup pro selhané zprávy. IHE Laboratory Testing Workflow profil a národní konformační sady poskytují testovaný základ.
Selhání, proti kterým je třeba navrhnout
Selhání, proti kterým musí být laboratorní rozhraní navrženo, jsou výsledky zapsané k předchozí návštěvě, sloučení pacientů neaplikované do LIS, změny jednotek po upgradu analyzátoru posouvající trendy, opravené výsledky přepisující bez upozornění, mikrobiologické citlivosti přiřazené k nesprávnému organismu a výsledky testů, pro které EHR nemá kód, mizící ve frontě chyb.
Výsledky zapsané do předchozího setkání kvůli zastaralému PV1; sloučení (ADT A40) neaplikované na LIS; změna jednotky po upgradu analyzátoru tiše posouvající trendy; opravené výsledky přepisující bez upozornění; mikrobiologické citlivosti připojené k nesprávnému organismu; laboratoř posílající výsledky pro test, pro který EHR nemá kód, které pak zmizí ve frontě chyb.
V Anpheros
Laboratorní konektor Anpheros přijímá ORU^R01, CSV a JSON a vytváří Observations pod DiagnosticReport s LOINC a UCUM, přičemž zachovává lokální kódy a původní soubor; vývojářský průvodce importem laboratorních výsledků vás tím provede proti bezplatnému sandboxu.
Související stránky
- HL7 v2 ORM a OML zprávy o požadavcích
- HL7 v2 zprávy vysvětleny: ADT a ORU
- Jak mapovat lokální laboratorní kódy na LOINC
- FHIR DiagnosticReport vysvětleno
- Laboratorní konektor: HL7 v2, CSV nebo JSON do FHIR
- Interfacové enginy vysvětleny
- Import laboratorních výsledků do FHIR (vývojářský web)
Zdroje
- HL7 v2.5.1 ORU_R01 reference (Caristix)
- HL7 v2.5.1 OBX segment (Caristix)
- IHE Laboratory technical framework (LTW)
- HL7 v2-to-FHIR implementation guide
- HL7 FHIR R4: DiagnosticReport
Časté otázky
Kterou verzi HL7 by mělo nové laboratorní rozhraní používat?
2.5.1, pokud ji obě strany podporují: má SPM pro vzorky a jasnější zpracování stavu. Mnoho laboratoří stále používá 2.3.1 a rozhraní se přizpůsobí starší straně.
Jak jsou výsledky přiřazeny k požadavkům?
Podle čísla požadavku zadavatele (přiřazeného EHR) a čísla požadavku příjemce (přiřazeného LIS), přenášených v ORC-2/3 a OBR-2/3 jak odpovědi na požadavek, tak výsledku. Pokud EHR nikdy nezaznamenal číslo příjemce, přiřazení se vrátí k číslu zadavatele.
Co když laboratoř nemůže posílat LOINC kódy?
Namapujte jejich lokální kódy na LOINC na vaší straně, v enginu nebo konektoru, a uchovejte obojí. Trvejte na tom, aby systém lokálních kódů byl stabilní a aby nové testy byly oznamovány.
Je FHIR připraven pro laboratorní rozhraní?
Ano pro nové připojení, zejména mimo nemocnici: ServiceRequest, Observation a DiagnosticReport plně pokrývají požadavky a výsledky a národní průvodci je profilují. Uvnitř nemocnice budou LIS a analyzátory ještě roky mluvit jazykem HL7 v2.
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 →