Vysvětlení zpráv HL7 v2 ORM a OML pro objednávky

Krátká odpověď: V HL7 v2 se požadavek (laboratorní test, zobrazovací vyšetření, lék) posílá jako zpráva ORM^O01 ve verzích do 2.5.1, nebo jako zpráva o laboratorním požadavku OML^O21 od verze 2.4. Obě nesou pacienta (PID), návštěvu (PV1), segment ORC, který řídí požadavek (nový, zrušit, pozastavit, změna stavu, s čísly zadavatele a zpracovatele) a segment OBR, který uvádí, co bylo objednáno, kým a na kdy. Systém zpracovatele odpovídá zprávou ORR (nebo ORL pro OML) a později vrací výsledky jako ORU. Ekvivalentem ORC+OBR ve FHIR je ServiceRequest.

Laboratorní požadavek, segment po segmentu

Zpráva HL7 v2 pro laboratorní požadavek (ORM^O01) se skládá ze segmentů: MSH určuje typ a verzi zprávy, PID identifikuje pacienta, PV1 popisuje návštěvu, ORC obsahuje kód řízení objednávky, čísla objednávek od zadavatele a zpracovatele, prioritu a odesílajícího poskytovatele, OBR pojmenovává požadovaný test s kódem LOINC a časem odběru a DG1 uvádí zdůvodňující diagnózu.

MSH|^~\&|EHR|GENHOSP|LIS|CENTRALLAB|20260314091200||ORM^O01^ORM_O01|MSG0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F|||12 High Street^^Leeds^^LS1 4AB^GB
PV1|1|O|CLINIC-3^^^GENHOSP||||42^SMITH^JOHN^^^Dr
ORC|NW|PLC-778812^EHR|||||^^^20260314093000^^R||20260314091200|42^SMITH^JOHN
OBR|1|PLC-778812^EHR||4548-4^Hemoglobin A1c/Hemoglobin.total in Blood^LN|||20260314093000||||||||42^SMITH^JOHN
DG1|1||E11.9^Type 2 diabetes mellitus without complications^I10

MSH-9 ORM^O01^ORM_O01 pojmenovává typ zprávy, spouštěcí událost a strukturu. MSH-12 udává verzi.
PID identifikuje pacienta; PID-3 obsahuje identifikátor s jeho přidělující autoritou a typem (MR, číslo lékařské dokumentace).
PV1 uvádí návštěvu: ambulantní (O), umístění, ošetřujícího lékaře.
ORC-1 je kód řízení požadavku: NW nový požadavek, CA žádost o zrušení, OC požadavek zrušen, HD pozastaven, RL uvolněn, SC změna stavu, OK požadavek přijat, UA nelze přijmout, XO změna požadavku, DC ukončení. ORC-2 je číslo požadavku zadavatele (přiřazené objednávajícím systémem), ORC-3 číslo požadavku zpracovatele (přiřazené laboratoří, prázdné, dokud neodpoví). ORC-7 obsahuje časování a prioritu (R rutinní, S statim, A co nejdříve). ORC-12 je objednávající poskytovatel.
OBR-4 je univerzální identifikátor služby: co bylo objednáno, kódováno (zde LOINC, LN). OBR-7 je datum a čas pozorování nebo odběru. OBR-16 opakuje objednávajícího poskytovatele. U laboratorních požadavků jsou podrobnosti o vzorku ve starších verzích v OBR-15 a od verze 2.5 ve vyhrazeném segmentu SPM.
DG1 nese diagnózu, která ospravedlňuje požadavek.

Stejný požadavek s více testy opakuje pár ORC/OBR jednou pro každý test, každý s vlastním OBR-1 set ID.

ORM vs OML

ORM^O01 je obecná zpráva pro objednávky HL7 v2, což je volná struktura pro laboratoř, radiologii, lékárnu a zásoby. OML, zavedená ve verzi 2.4, je specifická laboratorní zpráva pro objednávky s triggery O21, O33 a O35 a explicitními segmenty SPM a SAC pro vzorky a nádoby. Většina rozhraní nemocnice-laboratoř stále používá ORM^O01; OML se objevuje v novějších laboratorních systémech a profilech IHE.

ORM^O01 je obecná zpráva o požadavku: jedna struktura pro laboratoř, radiologii, lékárnu, stravování a zásoby, což ji činilo volnou. Od verze 2.4 zavedla HL7 OML (laboratorní požadavek) s několika spouštěči, O21 (požadavek podle testu), O33 (požadavek podle vzorku) a O35 (požadavek podle vzorku a nádoby), a přísnější strukturu se segmenty SPM a SAC pro vzorky a nádoby. Následovaly OMG (obecný klinický požadavek), OMI (zobrazovací metody), OMP (lékárna) ve stejném vzoru. V praxi většina nemocničních rozhraní do laboratoří stále běží na ORM^O01 ve verzi 2.3.1 nebo 2.5.1 a OML se objevuje v novějších laboratorních systémech a v profilu IHE Laboratory Testing Workflow.

Odpovědi

Objednávka HL7 v2 obdrží dvě odpovědi. Okamžitá ACK (MSA-1 AA, AE nebo AR) potvrzuje, že zpráva byla přijata a zpracována. Poté aplikační odpověď, ORR^O02 pro ORM nebo ORL^O22 pro OML, opakuje ORC s OK nebo UA a vyplňuje ORC-3, číslo objednávky zpracovatele. Výsledky se později vrátí jako ORU^R01 nesoucí obě čísla objednávek.

Přijímající systém odpovídá dvakrát. Okamžitě zprávou ACK (MSA-1 AA přijato, AE chyba, AR zamítnuto), která potvrzuje příjem a zpracování zprávy. Poté jako aplikační odpověď zprávou ORR^O02 (pro ORM) nebo ORL^O22 (pro OML), opakující ORC s OK nebo UA a vyplňující ORC-3, číslo požadavku zpracovatele, které obě strany od té doby používají. Výsledky se vracejí jako ORU^R01, se stejnými čísly zadavatele a zpracovatele v OBR-2 a OBR-3, což je způsob, jak výsledek najde svůj požadavek. Viz Vysvětlení zpráv HL7 v2: ADT a ORU.

Kde se požadavky kazí

Objednávky HL7 v2 se nejčastěji kazí kvůli neshodám čísel zadavatele a zpracovatele, když nebyla zpracována ORR, lokálním kódům testů v OBR-4 bez kódu LOINC, zrušením odeslaným bez původního čísla zadavatele, neshodám verzí, jako je segment SPM odeslaný přijímači verze 2.3.1, a prioritě zapsané v textovém poli NTE místo ORC-7 nebo OBR-5.

Nesoulad čísel: ORU se vrací s číslem zpracovatele, které EHR nikdy neviděl, obvykle proto, že ORR nebyl zpracován.
Lokální kódy v OBR-4: interní kód testu laboratoře místo (nebo bez) kódu LOINC, takže přijímající záznam nemůže test namapovat. Řešením je kód s oběma: GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN.
Zrušení bez původních čísel: CA musí nést číslo zadavatele požadavku, který ruší.
Neshody verzí: segment SPM zaslaný příjemci verze 2.3.1 je vynechán nebo odmítnut.
Priorita ve špatném poli: STAT v textovém poli NTE místo ORC-7 nebo OBR-5.

Stejný požadavek ve FHIR

Ve FHIR se segmenty ORC a OBR objednávky HL7 v2 zhroutí do jedné ServiceRequest se stavem, záměrem objednávky, prioritou, kódem LOINC, předmětem, setkáním, žadatelem, occurrenceDateTime, reasonCode pro diagnózu a identifikátory pro čísla zadavatele a zpracovatele. Výsledné Observation a DiagnosticReport na ni odkazují prostřednictvím basedOn, jak je mapováno v implementačním průvodci HL7 v2-to-FHIR.

Ve FHIR se ORC a OBR spojují do jednoho ServiceRequest: status (aktivní, pozastaveno, zrušeno, dokončeno), intent (order), priority (rutinní, urgentní, co nejdříve, statim), code (test LOINC), subject, encounter, requester, occurrenceDateTime, reasonCode (diagnóza ICD-10) a identifier pro čísla zadavatele a zpracovatele. Výsledek Observation a DiagnosticReport odkazují zpět pomocí basedOn. HL7 publikuje mapování pole po poli v implementačním průvodci v2-to-FHIR.

Anpheros Platform podporuje ServiceRequest, Observation a DiagnosticReport a její laboratorní konektor přijímá výsledky ve formátech HL7 v2 ORU, CSV nebo JSON. Neodesílá ani nepřijímá požadavky; objednávání zůstává v systémech nemocnice nebo laboratoře a dokončený výsledek se připojí k záznamu pacienta.

Související stránky

Zdroje

Časté otázky

Jaký je rozdíl mezi ORC a OBR?

ORC se týká požadavku jako administrativního objektu: kdo jej zadal, jeho čísla, jeho stav, jeho priorita. OBR se týká požadované služby: jaký test, na jakém vzorku, kdy. Každému OBR předchází jeho ORC.

Co je zadavatel a zpracovatel?

Zadavatel je systém, který žádá o službu (EHR nebo systém objednávajícího lékaře); zpracovatel je systém, který ji provádí (laboratorní nebo radiologický systém). Každý přiřadí své vlastní číslo požadavku a zprávy nesou obě, aby si kterákoli strana mohla požadavek najít.

Mám pro nové laboratorní rozhraní implementovat ORM nebo OML?

Pokud partner podporuje OML^O21 ve verzi 2.5.1 nebo novější, preferujte jej: manipulace se vzorky je explicitní a profily IHE jsou na něm postaveny. Pokud je partner starší LIS, mluví jazykem ORM^O01 a vy se přizpůsobíte.

Jak se požadavek HL7 v2 mapuje na FHIR?

ORC a OBR dohromady se stávají ServiceRequest; čísla zadavatele a zpracovatele se stávají identifikátory; ORC-1 a ORC-5 se mapují na stav; OBR-4 na kód; DG1 na reasonCode; objednávající poskytovatel na requester. Průvodce HL7 v2-to-FHIR publikuje podrobné tabulky.

Anpheros Platform

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.

Vytvořit sandbox zdarma Přečíst návody pro vývojáře →

Zdarma · 30 syntetických pacientů · bez karty

Tento návod slouží pouze pro informační účely a nenahrazuje lékařskou radu. Ohledně rozhodnutí o svém zdraví se poraďte se svým lékařem. V naléhavém případě volejte místní tísňové číslo (v Evropě 112).

Napsal

Tým Anpheros

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 →