القرار التصميمي الأول للبرمجيات في القطاع الصحّي
القرار الأول هو تصنيف البيانات: أيّ الحقول بيانات صحّية وأيّها بيانات تشغيلية؟ فالبيانات الصحّية تدخل في نطاق البيانات الشخصية ذات الطبيعة الخاصّة؛ وتخضع معالجتها والاطّلاع عليها وحفظها ونقلها إلى الخارج لقواعد مستقلّة. أمّا الطيران والإقامة والنقل فبيانات تشغيلية. وما لم يُكتب هذا التمييز في نموذج البيانات، صُمّم النظام كلّه على أعلى مستوى حماية وثقلت العمليات بلا داعٍ.
العمليات الحرجة
- رحلة المريض: أول تواصل ← التقييم الأوّلي ← العرض ← التخطيط ← العلاج ← المتابعة بعد الخروج؛ ويجب أن يكون مالك السجلّ ولحظة التسليم معرَّفين في كلّ مرحلة.
- تعدّد اللغات: حفظ لغة التواصل في السجلّ، وإصدار قوالب المستندات بأرقام لكلّ لغة، وعرض المواعيد بحسب المنطقة الزمنية للمريض.
- الوكالة والعمولة: سلسلة الوكالة والوكالة الفرعية، وفي أيّ مرحلة تُستحقّ العمولة، واستردادها عند الإلغاء أو العلاج الجزئي.
- مشاركة المستندات: مشاركة التقارير والصور الطبّية داخل النظام برابط مؤقّت وخاصّ بشخص محدّد؛ مع تسجيل كلّ اطّلاع.
- إدارة الموافقات: إصدار نصوص الموافقة بأرقام لكلّ لغة، وتسجيل أيّ مريض وافق على أيّ إصدار.
- تخطيط الترجمة الفورية: التحقّق من توافر المترجم مع الموعد.
أيّ حلّ يقابل أيّ حاجة؟
تُستخدم برمجيات السياحة العلاجية لعمليات المرضى الدوليين، وإدارة علاقات العملاء لإدارة العملاء والفرص، وتكامل واجهات API والأنظمة لتبادل البيانات مع الأنظمة السريرية، وتطوير تطبيقات الهواتف لتطبيقات المرضى والموظفين. ونتناول القرارات المعمارية في دليل معمارية إدارة علاقات العملاء في السياحة العلاجية.
عمليات التكامل اللازمة
أنظمة معلومات المستشفيات، وتخطيط المواعيد وغرف العمليات، وقنوات المراسلة والبريد الإلكتروني، وبنية الدفع، والفاتورة الإلكترونية، والمحاسبة.
من أين نبدأ؟
الوضع الأولي في القطاع الصحّي والسياحة العلاجية هو غالبًا كومة تواصل مجزّأة: طلبات المرضى في WhatsApp والبريد الإلكتروني، والمستندات الطبّية على أجهزة شخصية، ومطابقة الوكالات في Excel. تبدو هذه البنية عاملة، لكنّ المسؤولية عن البيانات غير معرَّفة.
ومخرَج العمل الأول هو جرد البيانات الشخصية: أيّ بيانات تُحفظ وأين، ومن يطّلع عليها، وكم تُحفظ، وأيّ نقل إلى الخارج يجري. وبما أنّ بيانات شخصية ذات طبيعة خاصّة تُعالَج، يأتي هذا الجرد قبل القرارات البرمجية.
ما ينبغي أن يكون واضحًا في نموذج البيانات
- حالة رحلة المريض: الطلب، والتقييم الأوّلي، والعرض، والتخطيط، والعملية، والمتابعة — كلّ حالة بتاريخها ومسؤولها.
- قيد المستند: نوع المستند، والرافع، وسجلّ الاطّلاع، ومدّة الحفظ؛ فاسم الملفّ وحده لا يكفي.
- الوكالة والعمولة: الوكالة لكلّ حالة، ونسبة العمولة، ووضع المستحقّات، والعملة.
- اللغة وتفضيل التواصل: لغة تواصل المريض وإذن القناة؛ ويجب فصل إذن التسويق عن تواصل العلاج.
- سجلّ الاطّلاع: من اطّلع على المستند الطبّي ومتى — بصورة غير قابلة للحذف.
- قيد الموافقة: على أيّ إصدار من أيّ نصّ وُوفق ومتى.
ترتيب التشغيل
- جرد البيانات والصلاحيات: تعريف الأدوار، ونطاق الاطّلاع، ومدد الحفظ، ونصوص الموافقة.
- متابعة الطلب والحالة: نموذج طلب متعدّد اللغات، وأوضاع الحالة، وإنشاء العروض.
- المستندات والتواصل: مشاركة آمنة للمستندات، وسجلّ الاطّلاع، وسجلّ تواصل متعدّد القنوات.
- الوكالات والمالية: حساب العمولة، والمستحقّات، وتعدّد العملات، ومتابعة التحصيل.
ولا يمكن تخطّي المرحلة الأولى. فحين تُضاف قواعد الصلاحيات والحفظ لاحقًا، تبقى البيانات المتراكمة حتى ذلك التاريخ خارج القاعدة.
ما الذي نقيسه؟
- المدّة المنقضية بين أوضاع الحالة (من الطلب إلى العرض، ومن العرض إلى الموافقة)
- عدد الطلبات غير المجاب عنها ومدّة الردّ الأول
- عدد الحالات ووضع استحقاق العمولة على مستوى كلّ وكالة
- قابلية تدقيق سجلّات الاطّلاع على المستندات الطبّية
- توزيع الطلبات بتفصيل اللغة
الأخطاء المتكرّرة
- حفظ المستند الطبّي في تطبيق مراسلة. فلا يمكن إنتاج سجلّ اطّلاع ولا تلبية طلب الحذف.
- دمج إذن التسويق مع تواصل العلاج. فحين يُسحب الإذن يتوقّف الإبلاغ العلاجي أيضًا.
- عدم إصدار نصّ الموافقة بأرقام. فلا يمكن إثبات النصّ الذي وُوفق عليه.
- حساب العمولة خارج الحالة. فينفصل الاستحقاق عن وضع الحالة، وتُجرى المطابقة يدويًا.
الأسئلة الشائعة
هل ينبغي فصل النظام السريري عن نظام إدارة علاقات العملاء؟
نعم في الغالب، وهو فصل صحيح: فالنظام السريري يدير السجلّ الطبّي، ونظام إدارة العلاقات يدير الرحلة والمسار التجاري. وينبغي ألّا يُشارك بينهما إلّا الحقول اللازمة عبر واجهة معرَّفة؛ فنسخ السجلّ الطبّي كاملًا إلى نظام إدارة العلاقات يوسّع التزام الحماية بلا داعٍ.
كيف يُعالَج نقل البيانات إلى الخارج؟
يجب أن يُعرَّف مسبقًا السند القانوني للنقل، ونطاق الموافقة الصريحة، ومصير كلّ بيانات عند سحب الموافقة. وهذا ليس قرارًا برمجيًا، بل قرار قانوني ينبغي أن ينعكس في البرنامج.
أيّ القياسات ذات معنى؟
التحوّل بحسب المصدر (طلب ← عرض ← وصول ← علاج)، وتوزيع المدّة حتى الردّ الأول، وأسباب الإلغاء، ونسبة إتمام المتابعة بعد الخروج.
أين ينبغي حفظ بيانات المريض المقيم في الخارج؟
موضع البيانات مسألة تشريعية وتعاقدية معًا؛ ومن الناحية التقنية يجب تحديد موضع الخادم وموضع النسخ الاحتياطي ومواضع المعالجين الفرعيين كلٌّ على حدة. ولا يلزم أن تكون الثلاثة في مكان واحد، لكن يجب تعريفها جميعًا كتابةً. ونوضّح النطاق في بداية المشروع مع الجانب القانوني.
هل ينبغي أن ترى بوابة الوكالة كامل بيانات المريض؟
لا ينبغي. فوضع الحالة وتاريخ التخطيط والمعلومات المالية تكفي الوكالةَ لإدارة المسار التجاري؛ أمّا المستند الطبّي والتفصيل السريري فيجب حفظهما ضمن صلاحية منفصلة. وهذا التمييز تطبيق مباشر لمبدأ تقليل مشاركة البيانات إلى أدنى حدّ.
كيف تُبنى إدارة المحتوى متعدّد اللغات؟
يجب أن يكون لكلّ حقل نصّي سجلّ منفصل لكلّ لغة؛ وينبغي ألّا تُنشر الترجمة الآلية افتراضيًا. وتبقى الموافقة على الترجمة خطوة مستقلّة في نصوص إبلاغ المرضى، ويُسجَّل أيّ إصدار اعتُمد بأيّ لغة.