منصة AFAQ للرعاية الصحية

في أغسطس 2014، كنت في السابعة والعشرين من عمري، وعملت الحاجة اللي أي شخص عاقل يقولك: بلاش. شاركت في تأسيس شركة برمجيات رعاية صحية في عمّان. لا مشروعاً جانبياً من نوع SaaS مع خطة runway وخيار pivot. بل شركة استشارية ستسلّم نظام سجلات صحية إلكترونية كاملاً لمستشفى قلبية حي في المملكة العربية السعودية - بمرضى حقيقيين، وسير عمل سريرية حقيقية، وعواقب حقيقية للخطأ.

أسميناها AFAQ. اثنا عشر مهندساً. أنا كمؤسس ورئيس تقنية ومهندس رئيسي ومدير منتج ورئيس تنفيذي بالنيابة ومدير تقنية معلومات ومدير تطوير - في آنٍ واحد، على نفس بطاقة العمل، براتب كان صفراً فعلياً في السنة الأولى. لم يُحذّرني أحد أن “المسؤول عن كل حاجة” وصف وظيفي يزوّد عمرك الإداري بسرعة غير محترمة.

ما كانت عليه المنصة فعلاً

كان المنتج الأساسي لـAFAQ منصة EHR/EMR على مستوى المستشفى بأكملها: وحدات سريرية وإدارية ومالية مع إمكانيات ERP كاملة. عرض القيمة كان التماسك - لا يجب أن يحتاج المستشفى سبعة موردين لسبعة أنظمة مختلفة. سنسلّم منصة واحدة مبنية في الأردن، جاهزة لمرافق الرعاية الصحية الخليجية في منتصف دورة ترقيتها من الورق والأنظمة القديمة إلى الحداثة.

المنظومة التقنية لم تكن بسيطة. Java EE. Spring Boot وSpring MVC وSpring Security وSpring WS. Hibernate مع JPA. AngularJS وBootstrap على الواجهات الإدارية. Talend ETL للتحويل. Tomcat وWildFly كخوادم تطبيقات. PHP مع Symfony وYii لطبقات التكامل. MySQL وOracle كقواعد بيانات رئيسية. HL7 وFHIR للتشغيل البيني. وGT.M - الذي سأتحدث عنه.

كثير على فريق من 12 شخصاً؟ أيوه. سلّمناه على أي حال، لأنك حين توقّع العقد لا تملك رفاهية الشكوى من النطاق.

موصّل GT.M الذي لم يكتبه أحد غيرنا

هذه هي القطعة التي لا أزال فخوراً بها بعد عقد.

GT.M قاعدة بيانات NoSQL هرمية - محرك التخزين تحت VistA، نظام السجلات الصحية الإلكترونية مفتوح المصدر الذي يعمل في مستشفيات قدامى المحاربين الأمريكيين منذ الثمانينيات. يعمل على MUMPS (المسمى الآن M). أدواته شحيحة. توثيقه يفترض أنك تعرف سياقاً يعود إلى أربعين عاماً.

في 2015، لم يكن أحد يكتب موصّلات قواعد بيانات حديثة لـGT.M. كان علينا ذلك، لأن AFAQ كانت بحاجة للتواصل مع أنظمة مستشفى يعيش فيها بيانات الصيدلية والفواتير داخل بنية تحتية GT.M - و”تجاوزها” لم يكن خياراً حين عميلك مركز قلبية والبيانات حيوية سريرياً.

فقرأت دليل مبرمج GT.M، وقرأت مواصفة MUMPS، وكتبت موصّلات تجعل GT.M يتصرف كشيء يمكنك استدعاؤه من خدمة Java حديثة. معظم المهندسين يكتبون صفر موصّلات قواعد بيانات في مسيرتهم. من يكتب واحداً يكتبه عادةً لـPostgres أو MySQL حيث لكل سؤال جواب على Stack Overflow. كتابة موصّل GT.M في 2015 تعني قراءة كود مصدري وقوائم بريدية لأشخاص كانوا يفعلون هذا قبل أن أولد. كل ساعة منها تستحق.

مركز الأمير سلطان للقلب

كان النشر الرئيسي في مركز الأمير سلطان للقلب في الأحساء، المملكة العربية السعودية - مرفق قلبية متخصص تكون فيه مؤشرات الأداء ليست أرقام نمو ربع سنوية؛ بل أشياء كـdoor-to-balloon time (الفترة بين مراجعة مريض بألم في الصدر وبدء التدخل)، ومعدلات خطأ مصالحة الأدوية، وأعداد أوامر الفحوص المكررة.

هذه مؤشرات أداء تتعلق بالسلامة والحياة. قبل الإطلاق، أجرى فريق AFAQ تحليل مؤشرات الأداء عبر سير عمل المركز السريرية - رسم العمليات الورقية والقديمة، وحدّد أين تهم الأرقام أكثر، ثم بنى خطوط تقارير داخل السجل الصحي الإلكتروني تُظهر البيانات الصحيحة في المكان الصحيح. Talend ETL حمل عبء التحويل. رسائل HL7 تولّت طبقة التشغيل البيني بين الأنظمة.

كان الإطلاق يوم ثلاثاء عادي. كام ممرضة سألوا الزر راح فين. كده تعرف أنه سار بشكل جيد.

اثنا عشر مهندساً، قرار هندسي واحد شهرياً

إدارة اثني عشر مهندساً بينما أنت المهندس الرئيسي على نفس المنتج مشكلة تنسيق بلا إجابة نظيفة. من المفترض أن تفوّض القرارات التقنية. ومن المفترض أيضاً أن تتخذها أسرع من أي شخص في الفريق لأنك المسؤول عن العقد. هذان الشيئان يتصارعان كل أسبوع.

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

مارسنا ملكية النطاق المحدودة قبل أن تصبح مفهوماً في مقالة. ليست فكرة أصيلة؛ إنها ببساطة الشيء الذي يبقي شركة استشارية صغيرة متماسكة حين النطاق واسع والفريق صغير.

ما تعني “مؤرشف” هنا

عملت AFAQ من أغسطس 2014 إلى يناير 2017. سنتان ونصف. غادرت مطلع 2017؛ كانت المنصة في الإنتاج آنذاك. هل لا تزال تعمل بشكل ما في مركز الأمير سلطان للقلب - لا أعرف فعلاً. برمجيات الرعاية الصحية تميل إلى الصمود أطول من مؤلفيها الأصليين بهامش كبير. موصّلات GT.M تحديداً: هذا النوع من البنية التحتية لا يُستبدل وفق الجدول الزمني المفضّل لأي أحد.

كانت الشركة أقل من شركة وأشبه بمِسبك. دخل اثنا عشر مهندساً يعرفون Java أو PHP. خرجوا يعرفون كيف تعمل نماذج بيانات الرعاية الصحية، ولماذا يوجد HL7، وكيف تتفاوض على عقد مع قسم تقنية معلومات مستشفى لديه اثنتا عشرة طبقة من موافقات المشتريات، وما الذي يكلفه الخطأ في افتراض على مستوى نموذج البيانات حين قاعدة بياناتك الإنتاجية Oracle وعميلك يدير وحدة عناية مركزة للقلب.

خرجت أنا بنفس المعرفة، زائداً مجموعة محددة جداً من الآراء حول ما يجعل برمجيات الرعاية الصحية صعبة - وهو لا علاقة له تقريباً بالكود.