في أغسطس 2014 كان عمري 27 عاماً، أعيش في عمّان، وفعلت الشيء الذي لا يُنصحك به كل شخص عاقل: أسّست شركة برمجيات. ليست مشروع SaaS جانبي. كانت شركة استشارات برمجيات رعاية صحية ستنتهي بنشر نظام سجل طبي إلكتروني كامل في مركز الأمير سلطان للقلب في الأحساء، المملكة العربية السعودية.
أسمّيناها AFAQ. اثنا عشر مهندساً. مستشفيات حقيقية. مرضى حقيقيون. كنت مؤسساً ومديراً تقنياً ومهندساً رئيسياً ومديراً للمنتج ورئيساً تنفيذياً قائماً ومديراً لتقنية المعلومات ومديراً للتطوير - في نفس الوقت، على نفس بطاقة العمل، براتب واحد (كان صفراً فعلياً في السنة الأولى).
لم يحذّرني أحد من أن “كبير مسؤولي كل شيء” وصف وظيفي يُشيّخك بسنوات الكلاب.
ما بنت AFAQ فعلاً
بنينا منصة EHR/EMR - وحدات سريرية وإدارية ومالية مع قدرات ERP كاملة مُلحَقة. الفكرة كانت أن المستشفى لا ينبغي أن يحتاج سبعة موردين مختلفين لسبعة أنظمة مختلفة. سنشحن منصة واحدة متسقة، أردنية البناء، مُطرَحة في مرافق الرعاية الصحية الخليجية التي كانت في منتصف دورة ترقية من الورق والنظم القديمة إلى شيء حديث.
الـstack لم يكن بسيطاً. Java EE. Spring Boot وSpring Security وSpring WS. Hibernate مع JPA. على الـfrontend: GWT لواجهات الـفرونت إند السريرية الثقيلة، وAngularJS وBootstrap للواجهات الإدارية. Talend لـETL. Tomcat وWildFly كخوادم تطبيق. PHP مع Symfony وYii للتكاملات. MySQL وOracle كقواعد بيانات أساسية. HL7 وFHIR للتشغيل البيني.
هذا كثير. هذا أكثر مما يستطيع فريق من اثني عشر شخصاً. شحنّاه على أي حال، لأن حين تكون الشخص الذي باع العقد لا يحق لك الشكوى من النطاق.
الـconnector لقاعدة البيانات الذي لم يكتبه أحد غيرنا
هذا الجزء الذي ما زلت فخوراً به: كتبنا connectors قاعدة بيانات جديدة لـfis GT.M.
إذا لم تسمع بـGT.M - لست وحدك وهذا هو المقصود. GT.M قاعدة بيانات NoSQL هرمية تعمل داخل VistA، نظام EHR مفتوح المصدر للـVA المُطرَح في مستشفيات المحاربين الأمريكية منذ التسعينيات. تعمل على لغة تسمى MUMPS (المُسمّاة الآن M). أنماط وصولها قديمة، وأدواتها شحيحة، والوثائق تفترض أنك تعرف بالفعل السياق الممتد لأربعة عقود.
لم يكتب أحد connectors قاعدة بيانات حديثة لـGT.M في 2015. فعلنا ذلك، لأن منصة AFAQ كانت تحتاج التواصل مع أنظمة مستشفيات تشغّل بنية تحتية GT.M - و”سنتحايل عليها” لم يكن خياراً حين تعيش بيانات الصيدلية والفوترة الخاصة بعميلك بداخلها. فجلست، قرأت دليل مبرمجي GT.M، قرأت مواصفة MUMPS، وكتبت connectors جعلت GT.M يتصرف كشيء يمكن استدعاؤه من خدمة Java حديثة.
معظم المهندسين لن يكتبوا connector قاعدة بيانات في مساراتهم المهنية. معظم الذين يفعلون سيكتبون واحداً لـPostgres أو MySQL حيث لكل سؤال إجابة على Stack Overflow. كتابة connector لـGT.M في 2015 كانت تعني قراءة الكود المصدري وقوائم البريد الإلكتروني من أشخاص كانوا يفعلون هذا قبل أن أولد.
اثنا عشر مهندساً، مخطط تنظيمي واحد لا معنى له
إدارة اثني عشر مهندساً أثناء كونك في نفس الوقت المهندس الرئيسي على المنتج هي مشكلة تنسيق لا تملك إجابة نظيفة. من المفترض أن تُفوّض القرارات التقنية. كما من المفترض أن تتخذها بسرعة أكبر من أي شخص آخر في الفريق لأنك المسؤول عن العقد. هذان الأمران يتصارعان باستمرار.
ما تعلمته: القيد الأهم في شركة استشارات صغيرة ليس تقنياً، بل تحديد النطاق لكل شخص. كل مهندس يحتاج شيئاً واحداً يملكه ويكون مسؤولاً عنه. في اللحظة التي يعمل فيها مهندسان كلاهما “على الوحدة السريرية”، لديك مشكلة دمج وتحميل تواصل سيأكل sprint الخاص بك.
شغّلنا ملكية دومين رشيقة قبل أن تصبح مفهوماً تدوّن عنه. مهندس الفوترة يملك الفوترة. مهندس الصيدلية يملك الصيدلية. أنا أملك القرارات المعمارية التي تتقاطع تلك الخطوط، وأتخذ بالضبط اثنين منها شهرياً كحد أقصى، لأن كل قرار متقاطع هو ضريبة تبديل سياق على الجميع.
كيف بدو تحليل مؤشرات الأداء في طرح مستشفى قلبية
قبل الإطلاق في مركز الأمير سلطان للقلب، أجرينا تحليل مؤشرات الأداء الرئيسية وتطبيقها عبر سير العمل السريرية الخاصة بهم. يبدو هذا مجرداً. هكذا يعني ذلك بشكل ملموس.
مركز قلبية يهتم بـ: وقت الباب إلى البالون (كم من الوقت من ألم الصدر إلى التدخل)، وأخطاء مطابقة الأدوية، وأوامر الاختبارات المكررة، وعدم تطابق معرّف المريض بين الأقسام. هذه ليست مؤشرات نظرية. إنها مؤشرات حياة وسلامة. الخطأ في التقارير لا يُنتج مراجعة ربع سنوية سيئة - يُنتج تدقيقاً سريرياً لا تريد أن يُذكر اسمك فيه.
فجلسنا مع قياداتهم السريرية، ورسّمنا سير عملهم القائمة على الورق والأنظمة القديمة، ثم بنينا pipelines تقارير في EHR الخاص بنا تظهر الأرقام الصحيحة في المكان الصحيح. Talend ETL فعل الرفع الثقيل للتحويلات بين بياناتهم القديمة ونماذجنا. رسائل HL7 حملت طبقة التشغيل البيني.
الإطلاق لم يكن لحظة درامية. كان يوم ثلاثاء. طلبت بعض الممرضات أين انتقل الزر. هكذا تعرف أن الأمر سار بشكل جيد.
لماذا كانت AFAQ فعلاً
AFAQ امتدت من أغسطس 2014 إلى يناير 2017. سنتان ونصف. شحنّا. كان لنا عملاء. كانت لدينا أنظمة تعمل في مستشفيات إنتاجية.
لكن AFAQ كانت أقل من شركة وأكثر من بوتقة. اثنا عشر مهندساً دخلوا يعرفون Java أو PHP وخرجوا يعرفون كيف تعمل نماذج بيانات الرعاية الصحية، ولماذا HL7 موجودة، وكيف تتفاوض على عقد مع قسم تقنية معلومات في مستشفى لديه اثنا عشر مستوى من الموافقة، وما الثمن الذي تدفعه حين تكون مخطئاً بشأن افتراض على مستوى نموذج البيانات حين قاعدة بيانات الإنتاج لديك Oracle وعميلك مستشفى قلبية في المملكة العربية السعودية.
خرجت من AFAQ بمجموعة محددة جداً من الآراء. أن برمجيات الرعاية الصحية أصعب من البرمجيات المؤسسية بطرق لا علاقة لها بالكود. أن فريقاً من اثني عشر شخصاً كبير بما يكفي لإنتاج أنظمة حقيقية وصغير بما يكفي ليظل هشاً بطرق لا تعاني منها الشركة المكوّنة من مئة شخص. أن كتابة connector لقاعدة بيانات هرمية من الثمانينيات هي تعليم أفضل في نمذجة البيانات من أي دورة ستأخذها.
بطاقة العمل التي تحمل ستة مسميات وظيفية كانت فوضوية. الأنظمة التي شحنّاها لم تكن كذلك. كان هذا هو المقصود بأكمله.