دراسة جدوى معمارية — إضافة نظام إدارة المستشفيات (HIS) إلى Moon ERP

6/10

الجاهزية الإجمالية — «جاهز بشروط، بلا عوائق صلبة»

9/10

القضبان المالية (قيود/حسابات/خزائن/تأمين) — مجرّبة قتالياً

0–1/10

المواعيد والفندقة/الأسرّة — بناء جديد خالص (لا وجود لمحرك)

✓

LIS بُني أصلاً متوقعاً مستشفى (in_patient/emergency جاهزة)

21–35

أسبوع-شخص حتى نهاية المرحلة 2 (ديمو تنويم كامل) = تأسيس + مرحلتان

الخلاصة التنفيذية — الإجابة المباشرة

Executive Summary

نعم — المنصة مهيأة لاستضافة نظام مستشفيات، والقرار الصحيح أنه موديول منفصل Modules/HIS يستهلك LIS والحسابات والـ HRM ولا يعيد بناءها. أقوى دليل: وحدة المعامل نفسها — أعقد موديول في النظام (135 هجرة، ~311 مساراً) — بُنيت بنفس الوصفة وتتكامل اليوم فعلياً مع الحسابات (قيود يومية كاملة بأنواع فواتير خمسة)، ومع شركاء الأعمال (كل مريض يصبح تلقائياً شريكاً له حسابات أستاذ خاصة)، ومع الخزائن وورديات الكاشير والتأمين وNPHIES. هذه بالضبط البنية التحتية التي يحتاجها أي HIS — وهي موجودة وتعمل.

المفاجأة الإيجابية: وحدة المعامل بُنيت أصلاً وكأنها تنتظر المستشفى — حالات مصدر الطلب in_patient / emergency موجودة في الـ enum منذ البداية، وكيان الزيارة lab_visits قائم. أي أن «الاستقبال الذي يطلب تحاليل» — أحد أهم متطلباتك — تكامل وليس بناء: شاشة استقبال HIS تستدعي مسار إنشاء الطلب الموجود، والمعمل يبقى المنفّذ بلا أي تغيير.

والصراحة الكاملة: الفجوات الحقيقية ليست في المنصة بل في نطاق جديد خالص لا يوجد له أي أثر في الموديولات الـ 15: محرك مواعيد (لا يوجد تقويم/حجز في أي مكان)، والفندقة بالكامل (لا أجنحة ولا غرف ولا أسرّة ولا ADT — بحث شامل أكد الصفر)، و«فوليو المريض» (الفاتورة المجمعة للإقامة). كما أن نسيج التكامل بين الموديولات اليوم استيراد مباشر لا عقود — وفي النظام كله حدثٌ واحد فقط يعبر بين موديولين. هذا نجح حتى الآن لكنه أنتج تاريخياً ازدواجاً موثقاً (قصة محركات الطباعة الأربعة) — لذا الخطة تبدأ بمرحلة تأسيس قصيرة تمنع تكرار ذلك في HIS قبل أول شاشة.

خريطة الواقع المعماري — كما هو فعلاً

Architecture Ground Truth

وصفة الموديول موحّدة ومجربة: ‏module.json + ثلاثة Providers + ملفات مسارات + هجرات/زارعات/ترجمات — إنشاء Modules/HIS ميكانيكياً رخيص (سطر artisan + ‏dump-autoload + تسجيل في الحالة والصلاحيات وقائمة الواجهة ~30 سطراً إضافياً). module.json · LISServiceProvider.php:22-39
ما يحصل عليه HIS مجاناً من المنصة: تعدد الشركات (TenantAware)، التسلسلات لكل شركة/فرع، الإعدادات، شركاء الأعمال وحساباتهم التلقائية، فعل القيود الواحد المحمي (فترات مالية/رفض حسابات رئيسية/عملات)، الصلاحيات والأدوار (بما فيها العزل بالشركات الجديد)، المرفقات، وموظفو/ورديات HRM (موديول كامل حقيقي: 48 هجرة، رواتب وبصمة وحضور).
نسيج التكامل المقاس بالأرقام (استيراد مباشر): ‏LIS→Core ‏93 مرجعاً، LIS→Accounting ‏68، Sales→Core ‏42… — لا توجد طبقة عقود فعلية (الواجهات الموجودة بلا أي مستهلك عابر للموديولات)، وفي النظام كله اشتراك حدثي واحد بين موديولين (الحسابات تسمع إنشاء الشريك). PostLabInvoice.php:7,43
ثلاثة انعكاسات طبقات قائمة يجب ألا يضيف HIS رابعاً: ‏Core→Accounting (42)، Core→WebStore (12)، Core→LIS (سطر واحد في RoleSaveService). RoleSaveService.php:10
مفتاح تشغيل الموديولات واجهة-فقط: ‏system.enabled_modules تحترمه الواجهة (moduleGuard) بينما الخادم لا يفحصه إطلاقاً — موديول «معطّل» تبقى API الخاصة به قابلة للنداء (تحقق مباشر: grep شامل للخادم — النتيجة الوحيدة لـ enabled_modules هي DTO ترخيص لا أي فرض)؛ وطبقة الترخيص المركزية موجودة لكنها غير موصولة كـ middleware. قرار فرض على مستوى API مطلوب ضمن التأسيس. system-modules.service.ts · auth.guard.ts:162
ملاحظات تشغيلية صغيرة: المستودع على Laravel ‏12 (لا 11)، وسكربت إصلاح autoload التاريخي على الاستضافة قديم (يعرف 5 موديولات فقط) — يُحدَّث عند إضافة HIS. composer.json · fix-autoload.php:10

مصفوفة التداخل — كل قدرة مستشفيات مقابل الموجود فعلاً

HMS Capability × What Exists Today

قدرة الـ HIS	الموجود اليوم	التقييم	الاستراتيجية
ملف المريض + ربطه بالحسابات	`lab_patients` يغطي ~80% من سجل مريض رئيسي: MRN، هوية وطنية فريدة لكل شركة، جنسية، تأمين، روابط بورتال، وأهمها partner_id ← شريك أعمال بحسابات مدينة/دائنة تلقائية — متطلب «المريض المربوط بالحسابات» يعمل اليوم حرفياً في LIS	جزئي قوي	ترقيته لكيان مشترك (القرار 1)
الاستقبال يطلب تحاليل	‏`POST /lis/requests` يقبل اليوم: المريض، الطبيب، التحاليل/الباقات، الفرع، عقد التأمين، والمصدر in_patient/emergency + توليد فاتورة تلقائي	جاهز	تكامل عبر استخراج Action (القرار 3)
الأطباء	سجل ناضج في LIS (تخصصات، ترخيص، توقيع، محرك عمولات وتسويات كامل) — لكن صفر ربط بموظفي HRM (الـ FK مؤجل بتعليق صريح في الهجرة)	جزئي	إضافة user_id/employee_id ويصبح سجل الممارسين الموحد
الزيارة/الـ Encounter	‏`lab_visits` غلاف رفيع 1:1 حول طلب معمل (مسجّل/منتظر/جارٍ/مكتمل)	بذرة	كيان Encounter جديد في HIS يبنى على النمط
المواعيد والحجوزات	لا يوجد أي محرك مواعيد/تقويم في الموديولات الـ 15 («appointment» مجرد تسمية في enum؛ CRM تذاكر فقط)	غير موجود	بناء جديد — أكبر بند واجهةً أيضاً
الفندقة: أجنحة/غرف/أسرّة + ADT	صفر — بحث شامل في كل الموديولات: لا جداول ولا مفاهيم (أصول CMMS فيها نص موقع حر فقط)	غير موجود	بناء جديد كامل (المرحلة 2)
الكتالوج: منتجات وخدمات وأسعار وتأمين	منتجات Core فيها نوع «خدمة» وتتبع باتشات؛ لكن قوائم الأسعار المسماة وتغطية التأمين (حصة مريض/شركة، حدود، فوترة شهرية) موجودة في LIS فقط ومربوطة بالتحاليل	انقسام	تعميم نمط LIS للتسعير/التأمين على بنود HIS
الصيدلية	كمخزن تعمل اليوم: مخزون بباتشات وتواريخ صلاحية + POS للبيع؛ الصيدلة الإكلينيكية (وصفات/eMAR/مخدرات) غير موجودة	المخزن جاهز	مرحلة 3 — فوق Inventory/POS
فوليو المريض (الفاتورة المجمعة)	لا يوجد كيان فوليو/إيداع — لكن النمط الأولي موجود ويعمل: الفوترة المرحلية بند-ببند بقيود لحظية مطبقة على فواتير B2B، وتخصيص الدفعات FIFO، وسندات القبض	نمط جاهز	تعميم النمط + كيان Encounter/Folio (القرار 4)
الدفعات المقدمة/الودائع	غير مدعومة (الدفع مربوط بفاتورة منشورة ويمنع الزيادة)	ناقص	تبنى على سابقتي سند القبض وتخصيص FIFO
كاشير الاستقبال والخزائن	كامل في LIS: طرق دفع ديناميكية (تمارا/تابي)، خزائن بحسابات أستاذ تلقائية، ورديات بتقرير Z	جاهز	إعادة استخدام مباشرة
التأمين والمطالبات + NPHIES	عقود بأسعار معتمدة وحصص، فوترة شهرية، وتكامل NPHIES (أهلية/موافقات/مطالبات FHIR)	جاهز	تعميم على بنود HIS غير المعملية

القرارات المعمارية الأربعة الحاكمة

The Four Governing Decisions

القرار 1 — هوية المريض الموحّدة (أخطر قرار في المشروع كله)

ترقية lab_patients نفسه لكيان مشترك

نفس الجدول بلا إعادة تسمية؛ موديل مشترك يملكه نطاق المرضى، وLIS يحتفظ بمفاتيحه كما هي

جدول مرضى جديد لـ HIS بربط 1:1

هوية منقسمة، مزامنة أبدية، وشاشتا «مريض» متنافستان — مرفوض

ترك الازدواج

يعيد إنتاج مأساة معروفة في كل HIS فاشل — مرفوض بشدة

لماذا الترقية في المكان؟ الجدول مرتبط بـ 8 مفاتيح FK صلبة و144 مرجع patient_id في 52 ملفاً، وNPHIES يبني FHIR Patient منه مباشرة، وفيه فعلاً ربط الحسابات والبورتال — نقله أغلى بكثير من ترقيته. قاعدة سلامة حرجة ترافق القرار: الجدول ثنائي الغرض (مرضى الشركة + مرضى معامل B2B) — يجب أن يرى HIS حصرياً external_lab_id IS NULL كـ Global Scope مع اختبار يحرسها.

سؤال المالك: «هل صحيح أصلاً أن مرضى B2B في نفس الجدول؟» — أُجري تحليل مخصص معمّق، والجواب: نعم، التصميم الحالي صحيح، والفصل خطأ معماري. جدول القرار حسم 37/40 للجدول الواحد المحصّن مقابل 19/40 للفصل. الأدلة المقاسة على بيئة التطوير: 11,769 مريض شركة مقابل 15 مريض B2B، ومرضى B2B مرتبطون فعلاً بصفوف إكلينيكية حية (15 طلباً، 18 عينة، 45 نتيجة، 16 فاتورة) — فصلهم يفرض مراجع polymorphic على المسار الإكلينيكي كله أو تكرار خط الأنابيب أو نسخاً مزدوجاً للهوية، ويكسر عقد بورتال B2B لعملاء أحياء. كما أن النمط الواحد هو معيار الصناعة: ‏FHIR يمثّل الحالة بمورد Patient واحد مع managingOrganization — وهو حرفياً دور عمود external_lab_id. وعرض مرضى B2B في شاشة الموظفين اليوم مقصود لا تسريب (بشارة معمل موصوفة في الكود).

لكن التحليل كشف فجوات تحصين حقيقية تُصلَّح الآن (حِزمة من 8 بنود: 6 صغيرة + 2 متوسطة): مؤشر «المرضى النشطين» في لوحة الـ ERP يحسب مرضى B2B خطأً؛ 6 شاشات بحث/اختيار للموظفين غير مفلترة (أخطرها: ويزارد الطلبات قد يربط طلباً داخلياً بمريض B2B ففوترة على هوية خاطئة)؛ والأسوأ: شاشة دمج المرضى تسمح بدمج مريض B2B في مريض داخلي فتفسد كشوف معمل العميل؛ + قاعدة قيد فريدة على مستوى قاعدة البيانات تسد ثغرة السباق الموثقة في الهجرة، وقرار سياسة لروابط بوابة المريض لمرضى B2B.

القرار 2 — طوبولوجيا الموديول واتجاه الاعتماد

‏Modules/HIS واحد

يطابق أسلوب البيت (موديولات كبيرة — LIS وحده 275 مساراً)؛ التقسيم الداخلي بالمجلدات لا بموديولات

عدة موديولات صغيرة (HIS+Bedding+Appointments)

أناقة نظرية تصطدم بواقع لا يفرض اعتماديات بين الموديولات أصلاً — تأجيل

قاعدة الاتجاه الذهبية: ‏HIS يستورد من LIS/Accounting/HRM (أفعال وخدمات مباشرة — النمط القائم والعملي)، وLIS لا يستورد HIS أبداً — رجوع المعلومات (نتيجة صدرت، طلب اكتمل) عبر الأحداث الموجودة فعلاً LabResultReleased / LabRequestCompleted يستمع لها HIS لتغذية ملف الزيارة. بهذا يبقى LIS قابلاً للبيع منفرداً كما هو اليوم.

القرار 3 — عقد «الاستقبال يطلب تحاليل»

الواقع: إنشاء الطلب اليوم ~300 سطر داخل الكونترولر مباشرة (قياس مباشر: 294 سطراً) — لا يمكن لـ HIS استدعاؤه برمجياً بنظافة. الحل (ضمن التأسيس): استخراج CreateLabRequest Action يستهلكه كونترولر LIS نفسه (سلوك مطابق بالبايت) ويستدعيه HIS، + عمود encounter_id اختياري على الطلبات ليرتبط الأمر بالزيارة ويتجمّع في الفوليو. الواجهة أسهل: ويزارد الطلبات نفسه يدعم وضع Dialog مدمج — شاشة الاستقبال تفتحه كما هو. ونفس العقد يصبح القالب لاحقاً للأشعة وأي منفّذ خدمة آخر.

القرار 4 — الفوليو والفوترة المركزية

التصميم: كيان Encounter (زيارة عيادة أو إقامة تنويم) + بنود رسوم متعددة المصادر (كشف، خدمة، يوم-سرير عبر Job ليلي، فاتورة معمل بالمرجع، صرف صيدلية) تُرحَّل بقيود لحظية على تعميم نمط الفوترة المرحلية الموجود (المطبق حالياً على فواتير B2B بنداً-ببند)، مع ودائع/دفعات مقدمة تُبنى على سندات القبض وتخصيص FIFO القائمين. قاعدة منع الازدواج المحاسبي: فاتورة المعمل تدخل الفوليو بالمرجع — لا يعاد ترحيل بنودها أبداً (مصدر ترحيل واحد لكل بند).

التأسيس — يُنفَّذ الآن كحزمة جاهزية مستقلة

Phase 0 — Run NOW (updated per owner decision)

تحديث الخطة (بقرار المالك): بنود التأسيس تُنفَّذ الآن كحِزمة «جاهزية منصة» مستقلة — قبل أي شغل HIS — وقد خضع كل بند لتحليل تأثير مخصص. الجواب المباشر على سؤال «هل تؤثر على الوضع الحالي؟»: لا — كل البنود إما إضافات خاملة أو نقل مطابق بالبايت تحرسه 200+ اختبار قائم؛ التغييرات السلوكية الوحيدة مقصودة (إصلاح تسريبات B2B الحقيقية أعلاه). خمسة من السبعة لها قيمة قائمة بذاتها حتى لو تأجل HIS.

قيد حاكم معتمد من المالك (يحكم تنفيذ كل بند): برنامج المعامل لا يتأثر — أداءً ولا سلوكاً — وأي تعديل سلوكي مقصود يُسلَّم مع جانب واجهته في نفس الحزمة وبنفس النشر. الضمانات الفنية لذلك:

صفر استعلامات مضافة على المسارات الساخنة: نقل نطاق الفروع نقل class بلا تغيير استعلام؛ استخراج CreateLabRequest نفس الكود بمسار جديد (نفس الاستعلامات حرفياً)؛ أعمدة الطبيب وencounter_id خاملة لا تُقرأ.
لا Global Scope شامل على جدول المرضى — الحراسة بـ named scopes اختيارية (internal()/forLab()) يستهلكها HIS ومواضع محددة فقط؛ كل استعلامات LIS الحالية (قوائم العمل، الكانبان، النتائج — التي تحتاج المجموعتين عمداً) تبقى بلا أي لمسة.
الفهرس الفريد الجديد إضافة موجبة للأداء (يخدم استعلامات الهوية) لا عبء.
كل تعديل سلوكي مقصود مقرون بواجهته: فلترة منتقيات المرضى الستة تتم بباراميتر internalOnly الموجود أصلاً في خدمة الواجهة؛ حارس الدمج يُسلَّم مع رسالة الخطأ المترجمة في شاشة الدمج؛ تصحيح مؤشر اللوحة تغيير رقمي مقصود — وكل ذلك في حزمة نشر واحدة (خادم + واجهة معاً) حتى لا توجد لحظة «خادم جديد بواجهة قديمة».
بوابة القبول النهائية: السويتات القائمة كلها خضراء + فحص أداء مقارن (نفس زمن استجابة قوائم العمل والاستقبال قبل/بعد) قبل أي push.

البند	الخطر على السلوك الحالي	بوابة الإثبات	قيمته الذاتية اليوم	التوقيت
رفع نطاق الفروع من LIS إلى Core (نقل class + ‏shim توافقي — مواقع النداء الـ 14 بلا أي تغيير)	لا خطر	سويتات LIS القائمة	يفتح نطاق الفروع لـ HRM/Sales	هذا الأسبوع
ربط الطبيب بالموظف: عمود `employee_id` خامل على سجل الأطباء (سلسلة طبيب←موظف←مستخدم تكتمل)	صفر	LabDoctorApiTest ‏11	ربط الرواتب/العمولات	هذا الأسبوع
استخراج `CreateLabRequest` Action من الكونترولر (~300 سطر) بمطابقة بايت + ‏`encounter_id` خامل	منخفض	LabRequestApiTest ‏42 + سويتات B2B ‏74	يسدد دين الكونترولر الضخم	هذا الأسبوع
تحصين شريك B2B (حزمة الـ 8 بنود في القرار 1) + الـ Global Scope والترقية للكيان المشترك	منخفض — تغييرات مقصودة فقط	LabPatientApiTest ‏20 + اختبارات حراسة جديدة	يصلح تسريبات حقيقية اليوم (الدمج، الويزارد، المؤشر)	الأسبوع القادم
فرض مفتاح الموديولات على مستوى API	يجب log-only أولاً	قياس السجلات أسبوعين	حوكمة	الأسبوع القادم — وضع المراقبة فقط: القياس الفعلي أثبت أن إعدادات الشركات قديمة (شركة عليها مبيعات ومشتريات ومخازن وموظفون فعليون وإعدادها لا يذكر هذه الموديولات) — الفرض الفوري كان سيكسر تدفقات شغّالة
سقّالة Modules/HIS + صلاحيات his.*	خاملة لكن لا داعي لها الآن — تُنشأ عند انطلاق HIS			مع HIS
جداول Encounter/Folio + أحداث النطاق	تصميمها يُعتمد الآن، إنشاؤها مع HIS			مع HIS

الإجمالي المعدَّل لحزمة «الآن»: ~6–9 أيام-مطوّر (أقل من تقدير التأسيس الأصلي لأن بندين أُجِّلا بداعي عدم الحاجة لا الخطورة).

ديمو مبكر يثبت كل شيء عند انطلاق HIS لاحقاً: موظف استقبال HIS يفتح زيارة، يطلب تحاليل من شاشته، والطلب يظهر فوراً في قوائم عمل المعمل ويُفوتر على الفوليو — لأن العقد (CreateLabRequest + encounter_id) جُهّز الآن.

سجل التعميم — ماذا يُرفع للمستوى العام، ومتى

Generalization Register

إجابة سؤال «إيه تاني محتاج يبقى عاماً؟» — جردٌ كامل للقدرات التي نمت داخل LIS بينما هي بطبيعتها قدرات منصة. القاعدة الحاكمة: نرفع الآن ما يصلح خللاً قائماً أو يلزم لأكثر من موديول بلا تكلفة، ونرفع البقية عند أول حاجة فعلية (الرفع المبكر بلا مستهلكٍ ثانٍ = هندسة زائدة).

القدرة	مكانها اليوم	من يحتاجها غداً	التوقيت	ملاحظة
نطاق بيانات الفروع (own/branch/all)	داخل LIS (‏LisDataScope)	HIS وHRM وSales	الآن — مُقرر	نقل class لـ Core بـ shim توافقي؛ الـ 14 موضع نداء بلا تغيير
سجل تبعيات الصلاحيات والقوالب الجاهزة (التوسعة + presets + صفحات الهبوط)	داخل LIS — وCore يستورد منه (انعكاس طبقات قائم)	HIS سيحتاج تسجيل his.* بنفس الآلية	الآن — يُضاف للحزمة	سجل Core يساهم فيه كل موديول بملف تبعياته؛ يصلح الانعكاس RoleSaveService.php:10 ويفتح الباب لأي موديول قادم. ملاحظة: محرك الصلاحيات نفسه (spatie + RoleSaveService) عام في Core أصلاً — لا نقل مطلوب
طرق الدفع الديناميكية + الخزائن + ورديات الكاشير (تمارا/تابي، تقرير Z)	داخل LIS (جداول lab_*)	كاشير استقبال HIS أول مستهلك ثانٍ حقيقي؛ وPOS/Sales لاحقاً	مع HIS مرحلة 1	الرفع قبلها بلا داعٍ — وعنده تُنقل الجداول بأسماء عامة مع جسور توافق لـ LIS
خدمة ترحيل الرسوم الموحدة (تعميم نمط الفوترة المرحلية + توحيد اختيار حساب المدينين المنسوخ 3 مرات داخل LIS وحده)	أفعال خاصة بكل موديول	فوليو HIS — وكل الموديولات تستفيد	مع الفوليو (HIS م1)	تمنع «النسخة السادسة» من نفس المنطق — مخطَّط لها في القرار 4
قوائم الأسعار المسماة + التغطية التأمينية (أسعار معتمدة، حصص، حدود، فوترة شهرية)	داخل LIS ومربوطة بالتحاليل FK	خدمات/غرف/إجراءات HIS	مع HIS مرحلة 1	تعميم على بنود polymorphic — أكبر بنود هذا السجل جهداً
سجل الممارسين (أطباء بعمولات وتواقيع)	داخل LIS	HIS يستهلكه مباشرة (القرار المعتمد)	يبقى مكانه + ربط HRM الآن	الرفع الكامل لـ Core يُقيَّم فقط لو احتاجته موديولات غير صحية
خدمة ضرائب عامة (VAT اليوم إعداد lis.*)	إعداد لكل موديول	فواتير HIS	لاحقاً — عند توحيد الفوترة	منخفضة الإلحاح؛ تُحل ضمن خدمة الترحيل الموحدة
عقد الطباعة الموحد (واجهة)	مُعمَّم فعلياً (shared/print + عقد القوالب) بأسماء LIS-ية	إيصالات وفواتير HIS	إعادة تسمية فقط عند أول استهلاك HIS	الأصعب أُنجز في مشروع الطباعة — المتبقي شكلي
عام بالفعل ولا يحتاج أي نقل: محرك الصلاحيات والأدوار (Core + العزل بالشركات)، التسلسلات لكل شركة/فرع، الإعدادات، شركاء الأعمال وحساباتهم التلقائية، فعل القيود المحمي، الفروع وأختامها، المرفقات، الإشعارات — وهذه تحديداً هي «الهدية» التي يرثها HIS من اليوم الأول.

تعديل ناتج على حزمة «الآن»: يُضاف بند تاسع صغير — رفع سجل تبعيات الصلاحيات لـ Core (يُصلح انعكاس الطبقات القائم ويجهّز تسجيل his.*) — يرفع إجمالي الحزمة إلى ~7–10 أيام-مطوّر.

خارطة الطريق المرحلية

Phased Roadmap

المرحلة 0

التأسيس

⏱ 3–5 أسابيع-شخص

القرارات الأربعة مُنفَّذة
السقّالة والصلاحيات والمفاتيح

🎯 ديمو: أوردر من HIS يظهر في worklist المعمل

المرحلة 1

العيادات الخارجية

⏱ 8–14 أسبوع-شخص

مكتب الاستقبال + ملف مريض 360°
محرك المواعيد (أكبر بناء جديد هنا)
Encounter عيادة + كشف وخدمات
طلب التحاليل المدمج (ويزارد LIS)
فوليو + كاشير + تأمين

🎯 مستشفى عيادات خارجية كامل التشغيل

المرحلة 2

التنويم والفندقة

⏱ 10–16 أسبوع-شخص

أجنحة/غرف/أسرّة + خريطة أسرّة
‏ADT: دخول/تحويل/خروج
رسوم إقامة يومية (Job ليلي → الفوليو)
ودائع ودفعات مقدمة
محطة تمريض أساسية + أوامر الجناح

🎯 دورة تنويم كاملة: حجز سرير → إقامة → فاتورة خروج

المرحلة 3

الامتدادات

⏱ 4–10 أسابيع-شخص لكل بند

صيدلية إكلينيكية (فوق Inventory/POS الجاهزين)
عمليات/أشعة (نفس عقد القرار 3)
تغذية، بوابة مواعيد للمرضى…

🎯 حسب أولوية السوق — كل بند مستقل

بطاقة درجات الجاهزية — بالمحاور

Readiness Scorecard

المحور	الدرجة	الخلاصة
البنية المالية (قيود، حسابات مريض، خزائن، تأمين، NPHIES)	9/10	جاهزة ومجربة — HIS يركّب عليها تركيباً
بنية الموديولات والتعددية (شركات/فروع/صلاحيات/تسلسلات)	8/10	الوصفة مثبتة بأعقد موديول؛ ينقصها فرض API للمفاتيح
الواجهة (نمط تطبيق-داخل-تطبيق، صلاحيات، طباعة، RTL)	8/10	النمط مجرب 3 مرات (POS/HR/Lab) — HIS رابعها؛ معظم الشاشات تركيب لا اختراع
هوية المريض والممارسين	7/10	80% موجود — مشروط بترقية التأسيس وحارس B2B
انضباط التكامل (عقود/أحداث بين الموديولات)	4/10	حدث واحد في النظام كله؛ التاريخ أثبت خطر الازدواج — يعالَج بالتأسيس
محرك المواعيد	1/10	لا يوجد محرك — الدرجة لوجود بذرة الزيارات (lab_visits) وتسمية enum فقط؛ البناء جديد واجهةً وخادماً
الفندقة/الأسرّة/الفوليو	0–1/10	لا وجود لأي جداول (تحقق مباشر بالبحث الشامل) — الدرجة الجزئية لأن أنماطه المحاسبية الأولية (فوترة مرحلية، FIFO) قائمة
الإجمالي	≈6/10	جاهز بشروط — لا عوائق صلبة؛ الفجوات «بناء نطاق» لا «جراحة منصة»

أهم 8 مخاطر — وتخفيفاتها

Top Risks & Mitigations

تسرب مرضى B2B إلى المستشفى — جدول المرضى ثنائي الغرض. التخفيف: ‏Global Scope ‏external_lab_id IS NULL + اختبار حارس دائم — يُنفَّذ في التأسيس قبل أي شاشة.

انقسام هوية المريض لو أُنشئ جدول مرضى ثانٍ. التخفيف: القرار 1 (الترقية في المكان) قرار معتمد لا يُعاد فتحه.

الازدواج الزاحف — درس هذا النظام الموثق (4 محركات طباعة متباعدة). التخفيف: أفعال مشتركة + اختبارات عقد من اليوم الأول (نفس أسلوب عقد القوالب الذي يكسر البناء عند الانحراف).

ازدواج محاسبي (نسخة سادسة من اختيار حساب المدينين، أو ترحيل بند مرتين عبر الفوليو). التخفيف: خدمة ترحيل رسوم واحدة معممة + قاعدة «فاتورة المعمل بالمرجع لا بإعادة الترحيل».

تثليث سجل الممارسين (طبيب LIS / موظف HRM / مستخدم). التخفيف: ربط الـ FKs في التأسيس واعتماد سجل واحد بثلاث زوايا.

لا فرض لاعتماديات الموديولات (module.json لا يصرّح بشيء، والمفتاح واجهة-فقط). التخفيف: فرض على مستوى API لمفتاح الموديول + قاعدة الاتجاه (LIS لا يستورد HIS) تُراقب في مراجعات الكود.

زحف نطاق EMR — «ملف طبي إلكتروني كامل» يبتلع المشروع. التخفيف: ‏v1 إداري-مالي صراحةً (تشغيل + فوترة)؛ التوثيق السريري العميق قرار منفصل لاحق.

هشاشة تشغيلية على الاستضافة (autoload/أذونات — سكربت الإصلاح التاريخي شاهد). التخفيف: تحديث سكربت النشر ليشمل HIS + فحص نشر آلي بعد كل ترقية.

منهجية الدراسة

Methodology

🔬 5 محللين متوازين

معمارية الموديولات والتكامل · جرد النطاق والتداخل · تدفق الأموال والفوترة · جاهزية الواجهة · التوليف والقرارات — كلٌّ بقراءة كود فعلية لا افتراضات.

📍 دليل سطري مُعاد التحقق

كل ادعاء جوهري موثّق بملف وسطر، وأُعيد التحقق من أبرزها بقياس مباشر قبل التسليم: أرقام الاعتماديات طابقت حرفياً (93/68/42)، حالات in_patient/emergency موجودة، الحدثان موجودان، صفر جداول فندقة (بحث شامل)، وحجم دالة إنشاء الطلب 294 سطراً.

⚖️ صراحة كاملة

التقرير يسمّي نقاط ضعف المنصة بقدر ما يسمّي قوتها (مفتاح واجهة-فقط، حدث وحيد، انعكاسات الطبقات) — لأن قرار الإدارة يستحق الواقع لا التسويق.

🛡 مراجعة مستقلة

خضعت الادعاءات لمراجعة نموذج مستقل (Codex) للتحقق من الدقة قبل الاعتماد.

إضافة نظام إدارة المستشفيات (HIS)إلى منصة Moon ERP