5 دروس مستفادة من عملية تكامل السجلات الصحية الإلكترونية (EHR) عبر الحدود
قضيت شهوراً في ربط سجلات المرضى عبر دولتين مختلفتين. عملت مع محللة أعمال رئيسية (Lead Business Analyst) لديها عشر سنوات من الخبرة السريرية. لقد غير نهجها نظرتي لبرمجيات الرعاية الصحية.
إليكم خمسة دروس من ذلك المشروع.
- رسم خرائط المصطلحات أصعب من رسم خرائط البيانات
غالباً ما يتعامل المهندسون مع عملية التكامل كمشكلة مخطط (schema). تقوم بربط الحقل A بالحقل B وتنتهي المهمة. في الرعاية الصحية، هذا النهج يفشل.
استخدم أحد الأنظمة ICD-10 بينما استخدم الآخر ICD-11. لا يمكن ربطهما بشكل مباشر. استخدم أحد الأنظمة LOINC للمختبرات بينما استخدم الآخر أكواداً داخلية قديمة.
قامت محللة الأعمال لدينا ببناء مخطط عبور للمفاهيم (concept crosswalk) قبل كتابة الكود. قامت بربط الأكواد المحلية بمجموعة معيارية مثل SNOMED CT. بدون ذلك، كنا سنفسد المعنى السريري.
رسم خرائط الحقول الخاطئ يؤدي إلى قيم خاطئة. أما رسم خرائط المصطلحات الخاطئ فيؤدي إلى قيم تبدو منطقية ولكنها خاطئة سريرياً. والأخيرة هي الأكثر خطورة بكثير.
- قوانين البيانات تشكل البنية التحتية في وقت مبكر
اعتقدت أننا سنقوم بتصميم نموذج البيانات أولاً ثم نتعامل مع الامتثال لاحقاً. كنت مخطئاً.
بيانات المرضى التي تعبر الحدود تصطدم بقوانين متعددة مثل HIPAA أو GDPR. تمنع بعض الدول خروج البيانات الصحية من حدودها.
عملت محللة الأعمال لدينا مع الفرق القانونية في وقت مبكر. قررت أي الحقول يمكن نسخها وأيها يحتاج إلى إزالة الهوية (de-identification).
غير هذا من بنيتنا التحتية. قمنا ببناء طبقة استعلام اتحادية (federated query layer) بدلاً من قاعدة بيانات واحدة منسوخة. أضفنا علامات تصنيف البيانات مباشرة في المخطط (schema) الخاص بنا.
استعن بخبراء الامتثال ومحلل أعمال في الغرفة قبل تصميم نموذج البيانات الخاص بك.
- المعايير ليست كافية
كلا النظامين يدعمان HL7. ومع ذلك، استخدم أحدهما HL7 v2 والآخر استخدم FHIR R4. لم يتمكنا من التواصل دون طبقة ترجمة.
حتى داخل FHIR، واجهنا عدم تطابق في الملفات التعريفية (profiles). ادعى كلا النظامين الامتثال، لكنهما استخدما أدلة تنفيذ (implementation guides) مختلفة.
لا تفترض أن التكامل سهل لمجرد أن النظام يدعم معياراً معيناً. اسأل دائماً عن الإصدار والملف التعريفي المحدد. خصص وقتاً لطبقة المحول (adapter layer).
- مخططات سير العمل تكشف الحالات الاستثنائية الخفية
كنت أعتبر مخططات سير العمل مجرد وثائق إضافية. كنت مخطئاً.
قامت محللة الأعمال لدينا برسم خرائط لنقل المرضى بالتفصيل. بحثت فيما يحدث عندما ينتقل المريض في منتصف العلاج أو عندما تصل نتيجة المختبر بعد الخروج من المستشفى.
هذه ليست حالات استثنائية (edge cases) في المستشفى؛ بل تحدث كل يوم.
غيرت هذه المخططات نموذج البيانات الخاص بنا. أضفنا مفهوم "حلقة رعاية" (care episode) لتتبع الرعاية المستمرة عبر كلا النظامين.
- قم ببناء مسرد مشترك في وقت مبكر
كلمات مثل encounter أو discharge تعني أشياء مختلفة في الأنظمة المختلفة. لقد أضعنا الوقت لأن الفرق فسرت المصطلحات بشكل مختلف.
قامت محللة الأعمال لدينا ببناء مسرد مشترك. راجع كل صاحب مصلحة هذه التعريفات ووافق عليها. قمنا بالإشارة إلى هذا المستند في كل متطلب.
افترض أن كل مصطلح في المجال قد يكون غامضاً. حدده في مستند يوقعه الطرفان.
ملخص
محلل الأعمال القوي يفعل أكثر من مجرد كتابة التذاكر (tickets). إنهم يعملون كمهندسين معماريين للقيود التنظيمية والمعنى السريري. إذا كنت تبني برمجيات معقدة، فلا تنظر إلى هذا الدور كعبء إضافي. فهو يمنع النجاح التقني من التحول إلى فشل سريري.
مجتمع تعلم اختياري: https://t.me/GyaanSetuAi