سنوات في بناء منصات EHR/EMR - أولاً في HAKEEM، ثم في AFAQ كمؤسّس - علّمتني أن المنتج المرئي (الواجهة، الأزرار، عرض الملف الطبي) هو ربما 15% مما يجعل النظام يعمل فعلاً داخل مستشفى. الـ85% الأخرى هي ورق عمل لا تراه: تشريع، تدقيق، تشغيل بيني (interop)، وصيغة البيانات الدقيقة التي يتوقّعها طابع الصيدلية الساعة 03:00. كل مهندس رعاية صحية أدّربته قدّر الـ85% بأقل مما هي قبل الشحن، وفهمها بعده.

جبل الجليد

تخيّل أول عرض لمهندس جديد لـ”شاشة العلامات الحيوية”. معدّل ضربات القلب، ضغط الدم، درجة الحرارة، رسم بياني جميل. يبدو رائعاً. يُشحَن في sprint.

ثم تصل الواقعية:

  • العلامة الحيوية تأتي من ستة أنواع مختلفة من الأجهزة عبر ثلاثة بروتوكولات مختلفة (HL7 v2 فوق TCP، ملكي ثنائي لمورّد معيّن، FHIR REST API للأجهزة الأحدث). نصف الأجهزة أقدم من FHIR ولن تُحدَّث أبداً.
  • الرقم الذي يُدخله الطبيب يدوياً يجب أن يتعايش مع رقم الجهاز. أيّهما معتمد؟ الجواب: يعتمد على من في الوردية، أي مستشفى، أي طراز جهاز، وأي بروتوكول للوحدة. تحتاج حقل مصدر (provenance)، لا حقل قيمة فحسب.
  • الشاشة يجب أن تصمد أمام تدقيق بعد ست سنوات. ليس “تعرض نفس الرقم” - بل تُثبت من رأى ماذا، متى، وهل أقرّ به. هذا يعني سجلات ثابتة (immutable)، لا كتابة فوق القيم القديمة.
  • نفس الشاشة لا تستطيع أن تسرّب عبر المستأجرين. علامات Clinic A الحيوية لا تظهر لموظفي Clinic B، حتى لو كان بعض الموظفين مشتركين بين العيادتين. نموذج الصلاحيات رسم علاقات، لا enum دور.
  • المعايير التنظيمية تتغيّر. HL7 v2 كان الشيء في 2010؛ FHIR هو الشيء في 2025؛ مهما كان الشيء في 2035 يجب أن ينزلق دون إعادة كتابة شاشة الملف الطبي.

كل نقطة من هذه أسبوع عمل لم يُدفع ثمنه لأحد. معظمها لا يمكن تأجيله - إنها تعاقدية أو قانونية أو حرجة لسلامة المريض من اليوم الأول.

الإطار المساعد

حصلت على نتائج أفضل مع المهندسين الجدد حين أرسم جبل الجليد صراحةً في بداية أي مشروع رعاية صحية. المنتج المرئي هو 15%. النطاق المرئي هو 15%. تخطيط sprint عن 15%. الـ85% الأخرى يجب أن تُعمَّر أولاً، لأن تركيبها لاحقاً يُكلّف ضعفين.

بشكل ملموس، أُقدّم هذه الخمسة على أي بناء رعاية صحية جديد:

  1. سجل تدقيق ثابت (immutable). كل كتابة على أي شيء مجاور للمريض تُضاف، لا تُحدَّث. لا يهمّني إن كان جدول دفتر حسابات على مستوى الصف، أو event stream، أو ملف مسطّح - لكن يجب أن يكون موجوداً قبل شحن الميزة الأولى. تركيب هذا لاحقاً هو أغلى شيء فعلته قط على codebase رعاية صحية.
  2. المصدر، لا القيمة. كل حقل له (value, source, observed_at, confidence). التظاهر بأن الحقل مجرد قيمة عددية مقبول في القطاع المالي؛ غير مقبول في نظام أدخل فيه اثنان من الأطباء أرقاماً مختلفة من شاشتين مختلفتين.
  3. عزل المستأجر على مستوى الاستعلام. Row-level security في Postgres أو ما يعادلها. ليس “التطبيق يفلتر على tenant_id” - لأن يوماً ما لن يفعل، وذلك اليوم اختراق.
  4. طبقة interop، لا تكاملات مباشرة. خدمة صغيرة تتحدّث HL7 v2 + FHIR + أي ملكي ثنائي لمورّد، وتكشف شكلاً داخلياً نظيفاً لبقية تطبيقك. ستُضيف صيغاً. لن تُزيل أي منها أبداً.
  5. دورة مراجعة تنظيمية. ليست بوابة، دورة. كل ربع سنة، شخص من مهمّته الاهتمام بـHIPAA / GDPR / المعادل المحلي ينظر إلى ما شُحن ويُثير المخاوف. إن لم يكن عندك هذا، ستمرّ بلحظة ذعر كبرى قبل الإطلاق بستة أشهر.

ما يخفيه سطر السيرة الذاتية

في سيرتي الذاتية، AFAQ سطران: “بنيت منصة EHR/EMR للمستشفيات.” HAKEEM سطران: “سجل صحي وطني للمستشفيات العامة.”

ما لا تقوله تلك الأسطر:

  • في AFAQ كتبتُ النسخة الأولى من فحص تفاعل الدواء بكود MUMPS-adjacent لأن ذلك ما أراده نظام الصيدلية كمدخلات. الأسبوع الذي شحنتُه فيه، شكرني طبيب لأن العملية السابقة كانت PDF مطبوعاً يجب أن يُبقيه على مكتبه.
  • في HAKEEM شاهدتُ استقراراً في نشر عبر مستشفيات متعدّدة حيث العائق لم يكن الكود - بل كان الحصول على موافقة ستة مديرين طبيين على ما تعنيه كلمة “مُعتمَد” في نموذج البيانات. شحنّا الكود في أسابيع. الاتفاق استغرق أشهراً. الاتفاق كان المنتج الحقيقي.
  • كلا النظامين ما زالا يعملان، في مكان ما. كود كتبتُه في 2012 ما زال يوجّه العلامات الحيوية في مستشفى في الأردن. هذا ليس تفاخراً - إنه تذكير بأن أنظمة الرعاية الصحية تعمر أطول من مصمّميها وعقودها. خطّط لذلك من اليوم الأول.

مفاجأة 2026

سأقول الجزء الهادئ: الهندسة بمساعدة الذكاء الاصطناعي مسرّع استثنائي للـ85%. ورق العمل الذي لا تراه هو في معظمه عمل نمطي - توصيل التدقيق، تحويلات المصدر، محوّلات interop، فلاتر المستأجرين. هذه هي الأشياء التي يجيد نموذج LLM توليدها إن أطّرتها جيداً. الـ15% من المنتج المرئي هو حيث حكم الإنسان ما زال يهمّ أكثر، لأن هذا حيث سير العمل السريري يلتقي الواجهة والاختيار الخاطئ يُضيّع فترة بعد الظهر على الممرضين.

الخطأ الذي أراه في الفِرق في 2026 هو العكس: يستخدمون الذكاء الاصطناعي لتوليد لوحة بيانات فاخرة ثم يتجاوزون طبقة التدقيق. الترتيب الصحيح هو العكس. استخدم الذكاء الاصطناعي لتركيب الـ85% بسرعة وصحة؛ أنفق انتباهك البشري على الـ15% التي تلمسها الممرضون فعلاً.

الشيء الواحد الذي يجب أن يتعلّمه كل مهندس رعاية صحية

لو كنتُ أُعيّن مهندساً جديداً في مشروع رعاية صحية غداً، كنتُ سأجعله يقضي أسبوعه الأول في قراءة تقارير الحوادث من أنظمة تكنولوجيا المعلومات الصحية الحقيقية. ليس إخطارات اختراق HIPAA (تلك للمحامين). دراسات حالة حقيقية من مجتمع تكنولوجيا المعلومات الصحية - نظام الصيدلية الذي طبع جرعة خاطئة، محوّل interop الذي أسقط نصف بالمئة من نتائج المختبر، النسخ الاحتياطي الذي استعاد ملف مريض من ثلاث سنوات ولم يلاحظ أحد لأسبوع.

ذاك الأسبوع الواحد يعلّمك لماذا الـ85% موجودة. كل اختصار “لا نحتاج هذا” هو يوم ثلاثاء شخص آخر السابق. اقرأ ما يكفي منها وستتوقّف عن طلب تخطّي سجل التدقيق.