إجابة مختصرة: واجهة المختبر لها اتجاهان. الطلبات تذهب من نظام السجلات الصحية الإلكترونية (EHR) إلى نظام معلومات المختبر (LIS) كرسائل HL7 v2 ORM^O01 أو OML^O21 (أو كـ FHIR ServiceRequest)، ويرد نظام LIS بـ ORR/ORL ولاحقًا بـ النتائج كـ ORU^R01 (أو FHIR DiagnosticReport مع Observations). الأجزاء الصعبة ليست الرسائل بل التفاصيل بداخلها: أرقام المودع والمُنفذ التي تربط النتائج بالطلبات، حالة النتيجة (أولية، نهائية، مصححة)، علامات الشذوذ، الوحدات ونطاقات المرجع، معلومات العينة، علم الأحياء الدقيقة بنتائجها متعددة الأجزاء، وربط الرموز بـ LOINC. عند القيام بها بشكل جيد، تصل كل نتيجة للمريض الصحيح، والطلب الصحيح، والمكان الصحيح في الملف، مع الحفاظ على معناها.
الخطوة 1: الاتفاق على التدفقات
تتمثل الخطوة الأولى في دمج نظام معلومات المختبر مع السجل الصحي الإلكتروني في الاتفاق مع المختبر على التدفقات الموجودة: الطلبات الصادرة، تحديثات حالة الطلب، النتائج الواردة، التصحيحات، الإلغاءات، الاختبارات الإضافية والاختبارات الانعكاسية، وتغذية بيانات ديموغرافية ADT إلى نظام معلومات المختبر. كما تحدد الأطراف إصدار HL7، وعادة ما يكون 2.3.1 أو 2.5.1، وطريقة النقل، وعادة ما تكون MLLP مع إشعارات الاستلام.
قرر مع المختبر ما هي التدفقات الموجودة: طلبات صادرة (أم يستقبل المختبر الورق ويسجل نفسه؟)، تحديثات حالة الطلب، نتائج واردة، تصحيحات، إلغاءات، اختبارات إضافية، اختبارات انعكاسية، وبيانات ديموغرافية (تغذية ADT إلى LIS ليعرف المريض قبل وصول العينة). ارسم التسلسل لنتيجة طبيعية، ونتيجة مصححة، وطلب ملغى. حدد إصدار HL7 (2.3.1 و 2.5.1 هما الأكثر شيوعًا) والنقل (MLLP مع ACKs؛ أحيانًا ملفات). انظر رسائل طلبات HL7 v2.
الخطوة 2: رسالة النتيجة، حقلاً بحقل
تصل نتيجة المختبر إلى السجل الصحي الإلكتروني كرسالة HL7 v2 ORU^R01: تحدد MSH المرسل والمستقبل، PID المريض، PV1 الزيارة، تحمل ORC و OBR أرقام الطلبات الخاصة بالمنفذ والمُنفذ، لوحة الاختبار المطلوبة وحالة التقرير، وكل OBX يحمل مادة تحليلية واحدة مع رمز LOINC الخاص بها، والقيمة، والوحدات، والنطاق المرجعي، وعلامة الشذوذ، وحالة النتيجة.
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 رقم المودع و ORC-3 / OBR-3 رقم المُنفذ: الربط بالطلب. OBR-4: المجموعة، مرمزة (LOINC
LN). OBR-7: وقت جمع العينة. OBR-22: وقت تقرير النتائج. OBR-25: حالة النتيجة للطلب بأكمله (Pأولية،Fنهائية،Cمصححة،Xملغاة). - OBX-2: نوع القيمة (
NMرقمي،STنصي،TXنص،CE/CWEمرمّز،SNرقمي منظم مثل<^5). OBX-3: المادة التحليلية، مرمّزة. OBX-5: القيمة. OBX-6: الوحدات، يفضل UCUM (10*3/uL، وليسK/µL). OBX-7: نطاق المرجع كنص. OBX-8: علامات الشذوذ (L،H،LL،HH،A،N). OBX-11: حالة النتيجة لكل مادة تحليلية (P،F،C،X،Dمحذوفة). OBX-14: وقت الملاحظة. OBX-19: وقت التحليل. - NTE: تعليقات، مرتبطة بـ OBR أو بـ OBX محددة حسب الموضع.
- SPM (2.5+): نوع العينة (SNOMED CT)، وقت الجمع، وقت الاستلام، الحالة.
الخطوة 3: الحالات الخاصة
الحالات الخاصة التي يجب أن يتعامل معها واجهة المختبر هي النتائج المصححة (الحالة C مع أرقام الطلبات الأصلية، استبدال وتنبيه بدلاً من الحذف)، النتائج الأولية ثم النهائية، علم الأحياء الدقيقة مع الكائنات الحية وقابليتها للتأثر مرتبطة بمعرف فرعي، النتائج النصية وملفات PDF المضمنة، الاختبارات الانعكاسية والإضافية، الإلغاءات، والوحدات والنطاقات المرجعية التي تتغير عندما يغير المختبر أجهزة التحليل.
- التصحيحات: ORU جديدة مع
Cفي OBR-25 و OBX-11 ونفس أرقام المودع/المُنفذ؛ يجب على نظام EHR الاستبدال، ووضع علامة على التغيير، وتنبيه الطبيب. لا تحذف الأصل بصمت أبدًا. - أولية ثم نهائية: نتائج
P(صبغة جرام) تليهاF(المزرعة)؛ يجب أن يُظهر الملف الحالة. - علم الأحياء الدقيقة: OBX واحد للكائن الحي المحدد (مرمّز، SNOMED CT)، ثم نتائج الحساسية كـ OBX لكل مضاد حيوي مع الكائن الحي كمعرف فرعي (OBX-4)، غالبًا عبر عدة رسائل. هذا هو المكان الذي تختبئ فيه معظم أخطاء الواجهة.
- النتائج النصية وملفات PDF: تعليقات علم الأمراض وبعض الكيمياء تصل كخطوط TX أو كملف PDF مضمن (OBX-2
ED)؛ يحتاج الملف إلى النص والملف. - الاختبارات الانعكاسية والإضافية: OBR جديدة تحت الطلب الأصلي، أو طلب جديد تم إنشاؤه بواسطة المختبر؛ اتفق على كيفية ترقيمها.
- الإلغاءات: حالة
X، مع الأرقام الأصلية. - الوحدات والنطاقات لكل محلل: نفس الاختبار يمكن أن يغير الوحدات عندما يغير المختبر المحللات؛ يجب أن تحمل الواجهة النطاق مع كل نتيجة، ولا تفترض ذلك.
الخطوة 4: الرموز
يعني تعيين الرموز في واجهة المختبر ترجمة رموز الاختبارات المحلية للمختبر إلى LOINC مرة واحدة، في جدول مُدار، وإرسال كل من الرمز المحلي ورمز LOINC في OBX-3، وتطبيع الوحدات إلى UCUM، وترميز أنواع العينات والكائنات الحية في SNOMED CT. بدون هذا التعيين، لا يمكن تتبع النتائج عبر المختبرات أو قراءتها بواسطة أنظمة خارجية.
اربط رموز اختبارات المختبر بـ LOINC مرة واحدة، في جدول مُدار، وأرسل كلا الرمزين المحلي و LOINC في OBX-3 (GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN). قم بتطبيع الوحدات إلى UCUM. أنواع العينات والكائنات الحية في SNOMED CT. الطريقة موجودة في كيفية ربط رموز المختبر المحلية بـ LOINC؛ بدونها، لا يمكن تتبع النتائج عبر المختبرات أو قراءتها بواسطة أي نظام خارجي.
الخطوة 5: البديل FHIR
البديل FHIR لواجهة مختبر HL7 v2 يستخدم ServiceRequest للطلب، Observation واحدة لكل مادة تحليلية مع رمز LOINC، كمية UCUM، نطاق مرجعي وتفسير، و DiagnosticReport يجمعها مع الحالة، المُنفذ، وقت الإصدار، الاستنتاج، وملف PDF. يتم التسليم عبر عمليات REST للكتابة، أو Bundle معاملة لكل تقرير، أو اشتراكات FHIR.
مع FHIR، الطلب هو ServiceRequest، والنتائج هي Observations (واحدة لكل مادة تحليلية، رمز LOINC، كمية UCUM، referenceRange، interpretation) مجمعة بواسطة DiagnosticReport الذي يحمل الحالة، والأداء، ووقت الإصدار، والاستنتاج، وملف PDF، مع basedOn يشير إلى ServiceRequest. التصحيحات هي إصدارات من نفس الموارد بحالة amended أو corrected. التسليم هو عمليات كتابة REST إلى خادم FHIR الخاص بـ EHR، أو حزمة معاملة لكل تقرير، أو اشتراكات. دليل HL7 v2-to-FHIR يربط كل حقل أعلاه؛ العديد من المختبرات تقدم الآن كلاهما. انظر FHIR DiagnosticReport مشروح و FHIR Observation مشروح.
الخطوة 6: الاختبار والتشغيل
اختبار واجهة المختبر قبل التشغيل يعني تشغيل مرضى اصطناعيين عبر كل حالة خاصة، ومقارنة يوم من النتائج المتوازية بين تقرير المختبر وسجل السجل الصحي الإلكتروني، والتحقق من المناطق الزمنية وانتقالات التوقيت الصيفي، والتحقق من معالجة إشعارات الاستلام وإعادة الإرسال بعد انقطاع، والاتفاق على إجراء استدعاء للطوارئ للرسائل الفاشلة، باستخدام ملف IHE الخاص بسير عمل اختبارات المختبر كخط أساس.
اختبر بمرضى وهميين عبر كل حالة في الخطوة 3؛ قارن يومًا من النتائج المتوازية بين التقرير الورقي أو PDF والملف؛ تحقق من المناطق الزمنية وانتقالات التوقيت الصيفي؛ تحقق من معالجة ACK وإعادة الإرسال بعد انقطاع؛ اتفق على إجراء استدعاء عند الطلب للرسائل الفاشلة. ملف Laboratory Testing Workflow الخاص بـ IHE ومجموعات المطابقة الوطنية توفر خط أساس تم اختباره.
حالات فشل التصميم ضدها
حالات الفشل التي يجب تصميم واجهة المختبر ضدها هي النتائج التي تم تسجيلها في زيارة سابقة، دمج المرضى الذي لم يتم تطبيقه على نظام معلومات المختبر، تغييرات الوحدات بعد ترقية جهاز تحليل أدت إلى تحول في الاتجاهات، نتائج مصححة تم تجاوزها دون تنبيه، قابليات التأثر لعلم الأحياء الدقيقة مرتبطة بالكائن الحي الخطأ، ونتائج للاختبارات التي لا يمتلك السجل الصحي الإلكتروني رمزًا لها تختفي في قائمة الأخطاء.
نتائج تم إيداعها في لقاء سابق لأن PV1 كان قديمًا؛ دمج (ADT A40) لم يتم تطبيقه على LIS؛ تغيير وحدة بعد ترقية محلل أدى إلى تحول صامت في الاتجاهات؛ نتائج مصححة تتجاوز دون تنبيه؛ حساسيات علم الأحياء الدقيقة مرتبطة بكائن حي خاطئ؛ مختبر يرسل نتائج لاختبار لا يمتلك نظام EHR رمزًا له، والتي تختفي بعد ذلك في قائمة انتظار الأخطاء.
في Anpheros
يقبل موصل المختبر Anpheros lab connector ORU^R01 و CSV و JSON وينتج Observations تحت DiagnosticReport مع LOINC و UCUM، مع الاحتفاظ بالرموز المحلية والملف الأصلي؛ دليل المطور حول استيراد نتائج المختبر يشرح ذلك بالتفصيل مقابل البيئة التجريبية المجانية.
صفحات ذات صلة
- رسائل طلبات HL7 v2 ORM و OML
- رسائل HL7 v2 مشروحة: ADT و ORU
- كيفية ربط رموز المختبر المحلية بـ LOINC
- FHIR DiagnosticReport مشروح
- موصل المختبر: HL7 v2، CSV أو JSON إلى FHIR
- محركات الواجهة مشروحة
- استيراد نتائج المختبر إلى FHIR (موقع المطورين)
مصادر
- مرجع HL7 v2.5.1 ORU_R01 (Caristix)
- مقطع HL7 v2.5.1 OBX (Caristix)
- إطار عمل IHE للمختبرات الفني (LTW)
- دليل تطبيق HL7 v2 إلى FHIR
- HL7 FHIR R4: DiagnosticReport
الأسئلة الشائعة
ما هو إصدار HL7 الذي يجب أن تستخدمه واجهة مختبر جديدة؟
2.5.1 إذا كان كلا الطرفين يدعمانه: فهو يحتوي على SPM للعينات ومعالجة حالة أوضح. لا يزال العديد من المختبرات يعملون بـ 2.3.1، وتتكيف الواجهة مع الجانب الأقدم.
كيف تتم مطابقة النتائج مع الطلبات؟
بواسطة رقم طلب المودع (المعين بواسطة EHR) ورقم طلب المُنفذ (المعين بواسطة LIS)، يتم حملهما في ORC-2/3 و OBR-2/3 لكل من استجابة الطلب والنتيجة. إذا لم يسجل نظام EHR رقم المُنفذ أبدًا، فإن المطابقة تعود إلى رقم المودع.
ماذا لو لم يتمكن المختبر من إرسال رموز LOINC؟
اربط رموزهم المحلية بـ LOINC من جانبك، في المحرك أو الموصل، واحتفظ بكليهما. أصر على أن نظام الرموز المحلي مستقر وأن الاختبارات الجديدة يتم الإعلان عنها.
هل FHIR جاهز لواجهات المختبر؟
نعم للاتصالات الجديدة، خاصة خارج المستشفى: ServiceRequest و Observation و DiagnosticReport تغطي الطلبات والنتائج بالكامل، والأدلة الوطنية تحددها. داخل المستشفى، ستتحدث LIS والمحللات بلغة HL7 v2 لسنوات.
جرّبه مجانًا في بيئة الاختبار
أول طلب FHIR خلال 5 دقائق. واجهة برمجة تطبيقات HL7 FHIR R4 مع موافقة المريض مدمجة: جربها في بيئة الاختبار، ثم اربط تطبيقك الخاص أو نظام عيادتك.
مجاني · 30 مريضًا اصطناعيًا · دون بطاقة
تبني Anpheros سجلًا طبيًا يتحكم فيه المريض ويمكن مشاركته مع أي عيادة، على منصة HL7 FHIR R4، مقرها في الاتحاد الأوروبي. تساعدك هذه الأدلة على فهم وتنظيم صحتك؛ ولا تغني عن استشارة طبيبك.
عن Anpheros →