HL7 v2 ORM ve OML sipariş mesajları hakkında

Kısa cevap: HL7 v2'de bir istek (laboratuvar testi, görüntüleme incelemesi, ilaç) 2.5.1'e kadar olan sürümlerde ORM^O01 mesajı olarak, 2.4 sürümünden itibaren ise laboratuvar isteği mesajı olarak OML^O21 olarak gönderilir. Her ikisi de hastayı (PID), ziyareti (PV1), isteği kontrol eden ORC segmentini (yeni, iptal, bekletme, durum değişikliği, yerleştirici ve doldurucu numaralarıyla) ve neyin istendiğini, kim tarafından ve ne zaman istendiğini belirten OBR segmentini taşır. Doldurucu sistem ORR (veya OML için ORL) ile yanıt verir ve daha sonra sonuçları ORU olarak döndürür. ORC+OBR'nin FHIR karşılığı ServiceRequest'tir.

Laboratuvar isteği, segment segment

Bir HL7 v2 laboratuvar isteği mesajı (ORM^O01) segmentlerden oluşur: MSH mesaj türünü ve sürümünü adlandırır, PID hastayı tanımlar, PV1 ziyareti açıklar, ORC istek kontrol kodunu, yerleştirici ve doldurucu istek numaralarını, önceliği ve isteyen sağlayıcıyı taşır, OBR istenen testi LOINC kodu ve toplama zamanı ile adlandırır ve DG1 gerekçelendiren tanıyı verir.

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 mesaj türünü, tetikleyici olayı ve yapıyı adlandırır. MSH-12 sürümü belirtir.
PID hastayı tanımlar; PID-3 tanımlayıcıyı atayan otorite ve türü (MR, tıbbi kayıt numarası) ile birlikte tutar.
PV1 ziyareti belirtir: ayakta hasta (O), konum, ilgili klinisyen.
ORC-1 istek kontrol kodudur: NW yeni istek, CA iptal talebi, OC istek iptal edildi, HD bekletme, RL serbest bırakma, SC durum değişti, OK istek kabul edildi, UA kabul edilemedi, XO isteği değiştir, DC sonlandırma. ORC-2 yerleştirici istek numarasıdır (isteyen sistem tarafından atanır), ORC-3 doldurucu istek numarasıdır (laboratuvar tarafından atanır, yanıt verene kadar boştur). ORC-7 zamanlamayı ve önceliği tutar (R rutin, S acil, A en kısa sürede). ORC-12 isteyen sağlayıcıdır.
OBR-4 evrensel hizmet tanımlayıcısıdır: istenen, kodlanmış (burada LOINC, LN). OBR-7 gözlem veya toplama tarih-saatidir. OBR-16 isteyen sağlayıcıyı tekrarlar. Laboratuvar isteklerinde, örnek ayrıntıları eski sürümlerde OBR-15'te ve 2.5'ten itibaren özel bir SPM segmentinde bulunur.
DG1 isteği haklı çıkaran tanıyı taşır.

Birden fazla test içeren aynı istek, her biri kendi OBR-1 küme kimliğine sahip ORC/OBR çiftini test başına bir kez tekrarlar.

ORM vs OML

ORM^O01 genel HL7 v2 istek mesajıdır, laboratuvar, radyoloji, eczane ve malzemeler için gevşek bir yapıdır. Sürüm 2.4'te tanıtılan OML, tetikleyicileri O21, O33 ve O35 olan ve numuneler ve kaplar için açık SPM ve SAC segmentlerine sahip laboratuvara özgü istek mesajıdır. Çoğu hastaneden laboratuvara arayüz hala ORM^O01 çalıştırır; OML daha yeni laboratuvar sistemlerinde ve IHE profillerinde görünür.

ORM^O01 genel istek mesajıdır: laboratuvar, radyoloji, eczane, diyet ve malzemeler için tek bir yapı, bu da onu gevşek hale getiriyordu. 2.4 sürümünden itibaren HL7, çeşitli tetikleyicilerle OML'yi (laboratuvar isteği) tanıttı: O21 (test başına istek), O33 (örnek başına istek) ve O35 (örnek ve kap başına istek) ve örnekler ve kaplar için SPM ve SAC segmentleriyle daha katı bir yapı. OMG (genel klinik istek), OMI (görüntüleme), OMP (eczane) aynı deseni izledi. Uygulamada, çoğu hastane-laboratuvar arayüzü hala 2.3.1 veya 2.5.1 sürümünde ORM^O01 üzerinde çalışır ve OML yeni laboratuvar sistemlerinde ve IHE'nin Laboratuvar Test İş Akışı profilinde görünür.

Yanıtlar

Bir HL7 v2 isteği iki yanıt alır. Anında bir ACK (MSA-1 AA, AE veya AR) mesajın alındığını ve ayrıştırıldığını onaylar. Ardından bir uygulama yanıtı, ORM için ORR^O02 veya OML için ORL^O22, ORC'yi OK veya UA ile tekrarlar ve doldurucu istek numarasını ORC-3'e doldurur. Sonuçlar daha sonra her iki istek numarasını da taşıyan ORU^R01 olarak döner.

Alıcı sistem iki kez yanıt verir. Hemen, mesajın alındığını ve ayrıştırıldığını onaylayan bir ACK (MSA-1 AA kabul, AE hata, AR reddet) ile. Ardından, bir uygulama yanıtı olarak, ORR^O02 (ORM için) veya ORL^O22 (OML için) ile, ORC'yi OK veya UA ile tekrarlar ve ORC-3'ü, doldurucu istek numarasını doldurur, bu numarayı her iki taraf da o andan itibaren kullanır. Sonuçlar ORU^R01 olarak geri gelir, OBR-2 ve OBR-3'te aynı yerleştirici ve doldurucu numaralarıyla, bu da bir sonucun isteğini nasıl bulduğunu gösterir. Bkz. HL7 v2 mesajları açıklandı: ADT ve ORU.

İsteklerin bozulduğu yerler

HL7 v2 istekleri en sık, ORR işlenmediğinde yerleştirici ve doldurucu numaralarının eşleşmemesi, OBR-4'teki yerel test kodlarının LOINC kodu olmadan olması, orijinal yerleştirici numarası olmadan gönderilen iptaller, 2.3.1 alıcısına gönderilen bir SPM segmenti gibi sürüm eşleşmeleri ve ORC-7 veya OBR-5 yerine serbest metin bir NTE'de yazılan öncelik nedeniyle bozulur.

Eşleşmeyen numaralar: ORU, EHR'nin hiç görmediği bir doldurucu numarasıyla geri döner, genellikle çünkü ORR işlenmemiştir.
OBR-4'te yerel kodlar: LOINC kodu yerine (veya onsuz) laboratuvarın dahili test kodu, bu nedenle alıcı kayıt testle eşleşemez. Çözüm, her ikisini de içeren bir koddur: GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN.
Orijinal numaralar olmadan iptaller: CA iptal ettiği isteğin yerleştirici numarasını taşımalıdır.
Sürüm uyumsuzlukları: 2.3.1 alıcısına gönderilen bir SPM segmenti atılır veya reddedilir.
Yanlış alanda öncelik: ORC-7 veya OBR-5 yerine serbest metin NTE'de STAT.

FHIR'da aynı istek

FHIR'da, bir HL7 v2 isteğinin ORC ve OBR segmentleri, durum, niyet isteği, öncelik, bir LOINC kodu, konu, karşılaşma, isteyen, oluşum zamanı, teşhis için sebep kodu ve yerleştirici ve doldurucu numaraları için tanımlayıcılar içeren tek bir ServiceRequest'e çöker. Ortaya çıkan Observation ve DiagnosticReport, HL7'nin v2'den FHIR'a uygulama kılavuzunun eşlemesi aracılığıyla basedOn aracılığıyla buna başvurur.

FHIR'da ORC ve OBR tek bir ServiceRequest'e birleşir: status (aktif, bekletmede, iptal edilmiş, tamamlanmış), intent (order), priority (rutin, acil, en kısa sürede, stat), code (LOINC testi), subject, encounter, requester, occurrenceDateTime, reasonCode (ICD-10 tanısı) ve yerleştirici ve doldurucu numaraları için identifier. Sonuç Observation ve DiagnosticReport, basedOn ile geri işaret eder. HL7, v2-FHIR uygulama kılavuzunda alan bazında eşlemeyi yayınlar.

Anpheros Platform, ServiceRequest, Observation ve DiagnosticReport'u destekler ve laboratuvar bağlayıcısı sonuçları HL7 v2 ORU, CSV veya JSON olarak kabul eder. İstek göndermez veya almaz; sipariş hastanenin veya laboratuvarın sistemlerinde kalır ve tamamlanan sonuç hastanın kaydına eklenir.

İlgili sayfalar

Kaynaklar

Sık sorulan sorular

ORC ve OBR arasındaki fark nedir?

ORC, istek hakkında idari bir nesne olarak: kimin yerleştirdiği, numaraları, durumu, önceliği hakkında. OBR, istenen hizmet hakkında: hangi test, hangi örnek üzerinde, ne zaman. Her OBR'nin önünde ORC'si bulunur.

Yerleştirici ve doldurucu nedir?

Yerleştirici, hizmeti isteyen sistemdir (EHR veya isteyen hekimin sistemi); doldurucu, hizmeti gerçekleştiren sistemdir (laboratuvar veya radyoloji sistemi). Her biri kendi istek numarasını atar ve mesajlar her ikisini de taşır, böylece her iki taraf da isteği bulabilir.

Yeni bir laboratuvar arayüzü için ORM mi yoksa OML mi uygulamalıyım?

Ortak, 2.5.1 veya daha sonraki sürümlerde OML^O21'i destekliyorsa, onu tercih edin: örnek işleme açıktır ve IHE profilleri buna dayanmaktadır. Ortak eski bir LIS ise, ORM^O01 konuştuğu şeydir ve siz uyum sağlarsınız.

Bir HL7 v2 isteği FHIR'a nasıl eşlenir?

ORC ve OBR birlikte bir ServiceRequest olur; yerleştirici ve doldurucu numaraları tanımlayıcılar olur; ORC-1 ve ORC-5 duruma eşlenir; OBR-4 koda; DG1 reasonCode'a; isteyen sağlayıcı requester'a. HL7 v2'den FHIR'a kılavuzu ayrıntılı tabloları yayınlar.

Anpheros Platform

Sandbox'ta ücretsiz deneyin

İlk FHIR çağrınız 5 dakikada. Hasta izniyle yerleşik HL7 FHIR R4 API: sandbox'ta deneyin, ardından kendi uygulamanızı veya klinik sisteminizi bağlayın.

Ücretsiz sandbox oluşturun Geliştirici kılavuzlarını okuyun →

Ücretsiz · 30 sentetik hasta · kart gerekmez

Bu rehber bilgilendirme amaçlıdır ve tıbbi muayenenin yerini tutmaz. Sağlığınızla ilgili kararlar için doktorunuzla konuşun. Acil bir durumda yerel acil numarasını arayın (Avrupa’da 112).

Yazan

Anpheros Ekibi

Anpheros, hasta kontrolünde olan ve herhangi bir klinik ile paylaşılabilecek, AB merkezli bir HL7 FHIR R4 platformu üzerinde tıbbi kayıtlar oluşturur. Bu rehberler, sağlığınızı anlamanıza ve düzenlemenize yardımcı olur; doktorunuzun yerini tutmaz.

Anpheros Hakkında →