تكامل HL7 بين KHCC وHAKEEM

معظم المهندسين لم يروا رسالة HL7 حقيقية.

إن عملت في fintech ربما حلّلت ISO 8583. إن عملت في اللوجستيات واجهت EDI. إن بنيت تكاملاً حياً بين نظامَي مستشفى، رأيت HL7 v2، ولديك آراء عنه لم تكن لديك من قبل.

الفريق في Electronic Health Solutions بنى تكامل HL7 بين مركز الحسين للسرطان (KHCC) وHAKEEM، السجل الصحي الإلكتروني الوطني الأردني، خلال التعاقد الممتد من 2010 إلى 2013. هكذا بدا ذلك فعلاً.

كيف تبدو رسالة HL7 v2

صيغة السلك هي أول شيء يجعل المهندسين يعملوا وش “هو ده بجد؟”.

MSH|^~\&|KHCC|KHCC|HAKEEM|MOH|20120315120000||ADT^A01|MSG00001|P|2.3
EVN|A01|20120315120000
PID|1||12345^^^KHCC^MR||AL-MANSOUR^AHMAD^MOHAMMED||19750304|M|||AMMAN^JO||||AR|M||12345
PV1|1|I|ONCOLOGY^101^1^KHCC||||SMITH^JOHN^A^^^DR

هذه ADT^A01 - رسالة قبول/خروج/نقل، الحدث A01 يعني قبول المريض. كل مقطع مفصول بأنبوب. الحقول داخل المقطع مفصولة بأنابيب. الحقول الفرعية بـ^. الحقول الفرعية-الفرعية بـ&. الحقول المتكررة بـ~.

مقطع MSH رأس الرسالة: تطبيق الإرسال ومرفق الإرسال وتطبيق الاستقبال ومرفق الاستقبال والطابع الزمني ونوع الرسالة ومعرّف الرسالة ومعرّف المعالجة والإصدار. مقطع PID هوية المريض: قائمة معرّفات والاسم وتاريخ الميلاد والجنس والعنوان واللغة. الإصدار - HL7 v2.3 - اكتمل عام 1997. الصيغة المفصولة بالأنابيب تسبق فتح XML للسيطرة على أنظمة المؤسسات. ليست جميلة. إنها تُعيَّن مباشرة لكيفية تخزين المستشفيات فعلاً وتبادل بيانات المرضى، وهو السبب في أنها لا تزال الصيغة السلكية المهيمنة في الرعاية الصحية عقوداً لاحقاً، رغم FHIR وCDA وكل معيار كان من المفترض أن يستبدلها.

لماذا كان KHCC تحدياً محدداً

مركز الحسين للسرطان ليس مستشفى عاماً. إنه مرفق الأورام التخصصي الرائد في الأردن - مركز تميّز تأسّس تحت رعاية الأميرة غيداء طلال، برسالة تمتد عبر العلاج والبحث والتعليم في المنطقة. يصل المرضى عبر الإحالة من مستشفيات أخرى، كثير منها كان على HAKEEM بالفعل.

هذا يعني أن سجل المريض لا يبدأ في KHCC. يبدأ في مرفق الإحالة - لنقل مستشفى الأمير حمزة - حيث شُخِّصت حالته المحتاجة لخبرة في الأورام. بياناته الديموغرافية والتشخيص الأولي وتاريخ الدواء ونتائج المختبر كلها تعيش في HAKEEM.

حين يصل ذلك المريض إلى KHCC، يمتلك KHCC سجله الصحي الخاص. مساحة معرّف مريض خاصة به. نموذج بيانات خاص به لبروتوكولات العلاج الكيميائي وخطط العلاج الإشعاعي ولوحات المختبر الخاصة بالأورام.

التحدي ليس “أدخل بيانات KHCC إلى HAKEEM”. التحدي هو تحليل هوية المريض عبر نظامَين خصّصا معرّفات مختلفة لنفس الإنسان، تلي ذلك مزامنة ثنائية الاتجاه تبقي كلا النظامَين محدَّثَين دون إنشاء تكرارات أو فقدان السياق السريري.

HL7 v2 طبقة النقل لتلك المشكلة. إنه ليس الحل لها.

الأجزاء الصعبة فعلاً

هوية المريض مشكلة غير محلولة. خصّص KHCC أرقام السجلات الطبية الخاصة به. يحتفظ HAKEEM بمخطط المعرّف الوطني للمريض الخاص به. حقل PID-3 يستوعب تحديداً قائمة معرّفات المريض - لأن للمريض معرّفات متعددة عبر أنظمة متعددة. لكن معرفة أن المريض 12345 في KHCC هو المريض 98765 في HAKEEM يتطلب جدول تعيين، وبناء ذلك الجدول يتطلب إما مطابقة احتمالية على الاسم + تاريخ الميلاد + الجنس + العنوان، أو مصالحة يدوية، أو - عملياً - كليهما، بقواعد مختلفة لعتبات ثقة مختلفة.

ترتيب الأحداث مهم سريرياً. رسالة HL7 ADT تحمل نوع حدث: A01 هو قبول، A02 هو نقل، A03 هو خروج، A08 هو تحديث معلومات. يجب وصول تلك الأحداث ومعالجتها بالترتيب، وإلا تكون الصورة السريرية خاطئة. مريض قُبل ثم نُقل ثم خُرِج يبدو مختلفاً جداً عن مريض وصلت رسائله خارج التسلسل ومعولجت كمقبول وخارج ومنقول إلى قسم غادره بالفعل.

في تكامل عالي الحجم، الرسائل لا تصل دائماً بالترتيب. TCP يمنحك التسليم الموثوق؛ لا يمنحك ضمانات ترتيب على مستوى التطبيق حين تُنتَج الرسائل بشكل غير متزامن. تحتاج أرقام تسلسل وإقرار (ACK/NAK) وقائمة انتظار مع منطق إعادة محاولة يتعامل مع NAKs دون فقدان الرسالة أو إغراق الوجهة بتكرارات.

تطبيق النظام المُرسِل هو المواصفة الحقيقية. HL7 v2.3 معيار بحقول اختيارية ومجال واسع لتباين التطبيق. ما أرسله فعلاً سجل KHCC الصحي في PID-3 هو ما أهمّ - لا ما قالت المواصفة يجب أن يكون هناك. قُضي وقت مع الفريق التقني لـKHCC لتحليل رسائلهم الصادرة الفعلية لأن توثيق التطبيق كان ناقصاً. هذا طبيعي. لكل تكامل HL7 هذه القصة.

كيف بدت طبقة التوجيه

استخدم التكامل حزمة HL7 Messaging في VistA - روتينات MUMPS تتعامل مع تحليل الرسائل الواردة وتوجيهها على الجانب HAKEEM. كتب الفريق روتينات لأنواع أحداث محددة: بشكل رئيسي أحداث ADT لحركة المريض، وأزواج ORM/ORU لأوامر المختبر ونتائجه.

تدفق الإحالة:

1. المستشفى المُحيل (على HAKEEM) يُرسل المريض إلى KHCC.
2. KHCC يُسجّل المريض، يُعيّن رقم السجل الطبي الخاص به.
3. KHCC يُرسل ADT^A01 إلى HAKEEM مُقرّاً بالقبول.
4. طبقة توجيه HAKEEM تستقبل A01، تُحلّل هوية المريض عبر فهرس المرضى الرئيسي، وتحدّث سجل المريض بمعلومات مواجهة KHCC.
5. نتائج المختبر من لوحات أورام KHCC تعود عبر رسائل ORU^R01 وتهبط في سجل المريض HAKEEM - مرئية للأطباء المُحيلين الذين لا يزالون يحملون علاقة الرعاية الأولية للمريض.

تلك النقطة الأخيرة مهمة سريرياً. طبيب أورام في KHCC يعالج السرطان. الطبيب العام في المستشفى المُحيل لا يزال يدير ضغط الدم والسكري وكل شيء آخر عند المريض. يحتاجون رؤية نتائج الأورام دون مطالبة المريض بحمل سجلات ورقية بين المرافق. تكامل HL7 هو ما يجعل ذلك ممكناً.

كيف يبدو هذا بعد اثني عشر عاماً

HL7 v2 ليس برمجيات جميلة. لكنه نوع القبح الذي يكسب الاحترام - قبيح لأن نطاق المشكلة قبيح، لا لأن المصممين لم يحاولوا. بيانات الرعاية الصحية فوضوية لأن الرعاية الصحية فوضوية. للمرضى معرّفات متعددة لأنهم يتفاعلون مع أنظمة متعددة. الأحداث تحتاج ترتيباً لأن الجداول الزمنية السريرية مهمة للتشخيص. اختيارية الحقول تبدو تراخياً؛ إنها فعلاً المعيار يستوعب اتساع التخصصات السريرية التي يجب عليها استخدامه.

FHIR أفضل حقيقياً في معظم النواحي. في 2012، كان FHIR مواصفة مسودة. HL7 v2 كان ما تتحدث به أنظمة المستشفيات. تتكامل مع ما هو موجود.

المهندسون الذين يبنون تكاملات الرعاية الصحية يُنجزون عملاً لا تراه معظم الصناعة. رسالة HL7 التي تحمل نتيجة مختبر من نظام المختبر إلى الملف إلى شاشة الطبيب هي سباكة. لا أحد يلاحظ السباكة حتى تنكسر. هذه الأنابيب لا تزال تجري.