Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR مقابل HL7 v2: اختلافات عملية

رسائل HL7 v2 وموارد FHIR مقارنة للمطورين: التنسيق، النقل، نفس نتيجة المختبر في كليهما، مخاطر الترجمة، وأين تقبل Anpheros v2.

HL7 v2 هو تنسيق الرسائل الذي تبادله أنظمة المستشفيات منذ أواخر الثمانينيات - أحداث مفصولة بأنابيب مثل "تم قبول المريض" أو "نتيجة المختبر جاهزة" يتم دفعها بين الأنظمة عبر اتصال شبكة - بينما HL7 FHIR هو معيار واجهة برمجة تطبيقات الويب حيث تقرأ التطبيقات وتكتب الموارد مثل Patient و Observation عبر HTTPS بتنسيق JSON. ليسا بديلين تختار أحدهما مرة واحدة: لا تزال معظم المستشفيات تعمل بنظام v2 داخليًا، وتستخدم التطبيقات الجديدة وواجهات برمجة التطبيقات المواجهة للمرضى FHIR، وغالبًا ما يتضمن عمل التكامل ترجمة أحدهما إلى الآخر. تقارن هذه الصفحة بينهما في النقاط التي تهمك عند كتابة التعليمات البرمجية، وتعرض نفس البيانات في كليهما، وتشرح أين يقبل Anpheros v2.

جنباً إلى جنب

الرسائل v2 الأكثر شيوعاً:

نفس نتيجة المختبر في كليهما

سطر نتيجة ORU^R01 (مقطع OBX):

OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500

نفس النتيجة كملاحظة HL7 FHIR R4، كما يخزنها Anpheros بعد استيراد هذه الرسالة:

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}

حقلًا بحقل: OBX-3 يصبح code، و OBX-5 و OBX-6 يصبحان valueQuantity، و OBX-7 referenceRange، و OBX-8 interpretation، و OBX-11 status، و OBX-14 effectiveDateTime. تنشر HL7 دليل تنفيذ رسمي HL7 Version 2 to FHIR مع تعيينات للمقاطع وأنواع البيانات والمفردات.

أين تخطئ الترجمات

• المناطق الزمنية. غالبًا ما تحمل الطوابع الزمنية لـ v2 مثل 20261002074500 لا تحمل إزاحة؛ يجب أن تعرف منطقة المرسل. يتطلب FHIR منطقة زمنية كلما كان الوقت موجودًا. (يقرأ Anpheros وقت v2 غير المحدد المنطقة على أنه UTC؛ أرسل الإزاحة إذا كانت لديك.)
• الرموز المحلية. تضع العديد من المختبرات رموزها الخاصة في OBX-3 بدلاً من LOINC. تحتفظ الترجمة الجيدة بالرمز المحلي وتربطه بـ LOINC عندما تستطيع، بدلاً من حذفه.
• الإرسال المتكرر. يعيد مرسلو v2 الإرسال عند انتهاء المهلة. بدون معرف ثابت لكل نتيجة، يمتلئ مخزن FHIR بالنسخ المكررة.
• كل شيء اختياري. يمكن أن يكون نفس الحقل فارغًا، أو مكررًا، أو مستخدمًا بشكل مختلف من قبل مرسلين اثنين. تحقق من جانب FHIR؛ يُظهر مدقق FHIR R4 ما ينقص المورد المترجم.
• التصحيحات. يجب أن يقوم حالة نتيجة v2 C (مصححة) بتحديث الملاحظة الحالية والاحتفاظ بتاريخها، وليس إنشاء ملاحظة ثانية.

متى تستخدم أيًا منها

• داخل المستشفى، بين الأنظمة الحالية: عادةً ما يكون v2 هو ما تتحدث به الأنظمة. يقوم محرك التكامل بتوجيه وتحويل الرسائل.
• بناء تطبيق، أو واجهة برمجة تطبيقات (API) للوصول للمرضى، أو أي شيء يعبر المنظمات: FHIR، مع OAuth والموافقة.
• تغذية الذكاء الاصطناعي (AI) أو التحليلات: FHIR، لأنه قابل للاستعلام، ومُرمز، ومُدار الإصدارات.
• كليهما: النمط الشائع في العالم الواقعي - استقبال v2 من المختبر أو سجلات الصحة الإلكترونية (EHR)، وتخزين FHIR، وتقديم FHIR للتطبيقات.

أين يتناسب Anpheros

يقوم Anpheros بتخزين سجلات المرضى بصيغة FHIR R4 ويقبل نوع رسالة HL7 v2 واحدة: ORU^R01 نتائج المختبر، يتم إرسالها عبر HTTPS إلى موصل المختبر (POST /v1/patients/{id}/labs/import مع Content-Type: x-application/hl7-v2+er7). يصبح كل OBX ملاحظة مختبرية (Observation) مع رمز LOINC، ونطاق مرجعي، وتفسير؛ يتم الاحتفاظ بمعرف التقرير في المصدر (provenance) ويتم تخطي التقارير المعاد إرسالها. يتم تخزين نتيجة مصححة (OBX-11 = C) بقيمة جديدة كملاحظة جديدة (Observation) بحالة amended؛ تبقى الأصلية كما كانت، لذا إذا كان المصدر الخاص بك يرسل تصحيحات، فقم بتمييز الملاحظة السابقة entered-in-error أو قم بتحديثها عبر FHIR API. مثال عملي هو Lab results API.

لا يقبل رسائل v2 أخرى (ADT، طلبات، جدولة)، ولا يستمع على MLLP، ولا يرسل v2. لهذه الحالات، يقوم محرك تكامل أمام Anpheros بالترجمة إلى FHIR والكتابة عبر API.

أسئلة متكررة

هل يحل FHIR محل HL7 v2؟

ليس قريبًا. لا يزال v2 العمود الفقري لمعظم المستشفيات لأنه يعمل ومدمج في الأنظمة الحالية. ينمو FHIR حوله - في التطبيقات، وصول المرضى، والتبادل بين المنظمات - ويتعايش الاثنان، غالبًا مع الترجمة بينهما.

ما هو MLLP؟

بروتوكول الطبقة الدنيا الأدنى (Minimal Lower Layer Protocol): طريقة بسيطة لتأطير رسائل v2 عبر اتصال TCP، مع أحرف بداية ونهاية حول كل رسالة وإقرار (ACK) بالرد. يستخدم FHIR بروتوكول HTTPS بدلاً من ذلك.

هل يمكنني تحويل رسائل HL7 v2 إلى FHIR تلقائيًا؟

في الغالب. يوفر دليل تطبيق HL7 v2 إلى FHIR تعيينات قياسية، وتقوم محركات التكامل بتنفيذها. توقع عملًا يدويًا للأكواد المحلية، ومقاطع Z (Z-segments)، والمناطق الزمنية، وكيفية استخدام كل مرسل للحقول الاختيارية.

هل يقبل Anpheros بروتوكول HL7 v2؟

نعم، لنتائج المختبر: رسائل ORU^R01 المنشورة عبر HTTPS إلى موصل المختبر تصبح FHIR Observations. لا يتم دعم أنواع رسائل v2 الأخرى واتصالات MLLP.

ذات الصلة

• تعيين HL7 v2 إلى FHIR: تعيين المقاطع والحقول، ومحول
• واجهة برمجة تطبيقات نتائج المختبر: HL7 v2 و FHIR و LOINC
• كيفية استيراد نتائج المختبر إلى سجل FHIR
• قابلية التشغيل البيني للبيانات الصحية
• DICOM مقابل FHIR: بيانات التصوير والبيانات السريرية
• منصة FHIR

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card