📜

قرارات HMS المعتمدة سابقاً (Settled HMS Decisions & Phase-0)

قبل أي رؤية جديدة لعلاقة ERP ↔ LIS ↔ HIS ↔ OBGY، يجب تثبيت ما اعتُمد فعلاً: دراسة الجدوى المعمارية لنظام المستشفيات (النسخة 2 بتاريخ 10 يونيو 2026، الملف /home/moonui/public_html/hms-feasibility-report.html) ومواصفة التنفيذ /home/moonui/hms-phase0-spec.md. هذه الوثائق تحمل قرارات معتمدة من المالك بصيغة «لا يُعاد فتحها» — أي أنها قيود مُلزِمة على أي طرح جديد بخصوص نظام عيادات النساء والتوليد (OBGY)، وحالتها التنفيذية: معتمدة ولم يبدأ تنفيذها بعد.

6/10الجاهزية الإجمالية للمنصة (بلا عوائق صلبة)

4قرارات معمارية حاكمة معتمدة

6بنود المرحلة 0 — كلها لم تبدأ بعد

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

144+اختباراً في بوابة القبول قبل أي دفع

القرارات المعتمدة المُلزِمة (لا يُعاد فتحها)

وثّقت الدراسة أربعة قرارات حاكمة، وأكدتها مواصفة المرحلة 0 تحت عنوان صريح SETTLED DECISIONS (do not reopen):

قرار 1 هوية المريض الموحّدة: ترقية جدول lab_patients نفسه ليصبح الكيان المشترك للمرضى — بلا جدول جديد وبلا إعادة تسمية. السبب المقاس: 8 مفاتيح FK صلبة و144 مرجع patient_id في 52 ملفاً داخل LIS، وتكامل NPHIES يبني مورد FHIR Patient منه مباشرة.
قرار B2B مرضى معامل B2B يبقون في lab_patients: حُسم بتحليل مخصص (37/40 للجدول الواحد مقابل 19/40 للفصل). عمود external_lab_id يلعب حرفياً دور Patient.managingOrganization في معيار FHIR. الأرقام: 11,769 مريض شركة مقابل 15 مريض B2B مرتبطين بصفوف إكلينيكية حية (15 طلباً، 18 عينة، 45 نتيجة، 16 فاتورة). الحراسة بـ named scopes اختيارية internal()/forLab() — وممنوع صراحة أي Global Scope شامل على الجدول.
قرار 2 موديول واحد Modules/HIS لا عدة موديولات صغيرة، والتقسيم الداخلي بالمجلدات. قاعدة الاتجاه الذهبية: HIS يستورد من LIS وAccounting وHRM (نداء مباشر للأمام)، وLIS لا يستورد HIS أبداً — رجوع المعلومات عبر الحدثين القائمين LabResultReleased وLabRequestCompleted يستمع لهما HIS.
قرار 3 عقد «الاستقبال يطلب تحاليل»: استخراج CreateLabRequest Action من الكونترولر (دالة LabRequestController::store ~294 سطراً) بمطابقة بايت، + عمود encounter_id خامل على lab_requests (بلا FK لأن جدول HIS غير موجود بعد). نفس العقد يصبح القالب للأشعة وأي منفّذ خدمة لاحق.
قرار 4 الفوليو والفوترة المركزية: كيان Encounter + بنود رسوم متعددة المصادر تُرحَّل بتعميم نمط الفوترة المرحلية القائم في B2B، مع قاعدة منع الازدواج المحاسبي: فاتورة المعمل تدخل الفوليو بالمرجع ولا يعاد ترحيل بنودها. تصميم Encounter/Folio اعتُمد لكن إنشاء الجداول مؤجَّل صراحة إلى انطلاق HIS.
قيد حاكم قيد المالك المُلزِم لكل بند: «برنامج المعامل لا يتأثر — أداءً ولا سلوكاً». صفر استعلامات مضافة على المسارات الساخنة، وكل تغيير سلوكي مقصود يُسلَّم خادماً وواجهة في نشر واحد، وبوابة قبول لكل معلم: كل السويتات خضراء + مقارنة زمن استجابة قبل/بعد على قوائم العمل والاستقبال — أي تراجع يُرجِع البند.

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

قدرة HIS	الموجود اليوم	التقييم المعتمد	الاستراتيجية
ملف المريض + ربطه بالحسابات	`lab_patients` يغطي ~80% (MRN، تأمين، `partner_id` ← شريك أعمال بحسابات تلقائية)	جزئي قوي	ترقية في المكان (قرار 1)
الاستقبال يطلب تحاليل	`POST /lis/requests` يقبل المصدر `in_patient`/`emergency` منذ البداية	جاهز	تكامل عبر `CreateLabRequest`
الأطباء	سجل ناضج في LIS بعمولات وتواقيع — صفر ربط بـ HRM	جزئي	عمود `employee_id` يكمل سلسلة طبيب←موظف←مستخدم
الزيارة / Encounter	`lab_visits` غلاف رفيع 1:1 حول طلب معمل	بذرة	كيان Encounter جديد في HIS
المواعيد والحجوزات	لا محرك تقويم/حجز في الموديولات الـ15 إطلاقاً	غير موجود (1/10)	بناء جديد — أكبر بند
الفندقة: غرف/أسرّة + ADT	صفر جداول (بحث شامل مؤكَّد)	غير موجود (0–1/10)	بناء جديد كامل (مرحلة 2)
التسعير والتأمين	قوائم أسعار وتغطية تأمين في LIS مربوطة بالتحاليل فقط	انقسام	تعميم على بنود polymorphic
الصيدلية	المخزن جاهز (باتشات + POS)؛ الإكلينيكية غير موجودة	جزئي	مرحلة 3 فوق Inventory/POS
فوليو المريض والودائع	النمط المحاسبي قائم (فوترة مرحلية B2B + تخصيص FIFO)، الكيان غير موجود	نمط جاهز	قرار 4
الكاشير والخزائن والتأمين/NPHIES	كامل ومجرّب في LIS (ورديات، تقرير Z، مطالبات FHIR)	جاهز (9/10 مالياً)	إعادة استخدام مباشرة

خارطة الطريق المعتمدة (P0–P3)

المرحلة 0 — التأسيس (تُنفَّذ الآن، ~7–10 أيام-مطوّر): حزمة «جاهزية المنصة» المستقلة الموصوفة أدناه — معتمدة من المالك قبل أي شغل HIS.
المرحلة 1 — العيادات الخارجية (8–14 أسبوع-شخص): استقبال + ملف مريض 360° + محرك المواعيد (أكبر بناء جديد) + Encounter عيادة + فوليو وكاشير وتأمين.
المرحلة 2 — التنويم والفندقة (10–16 أسبوع-شخص): أجنحة/غرف/أسرّة + ADT + رسوم إقامة بـ Job ليلي + ودائع + محطة تمريض أساسية.
المرحلة 3 — الامتدادات (4–10 أسابيع-شخص لكل بند): صيدلية إكلينيكية، عمليات/أشعة بنفس عقد القرار 3، تغذية، بوابة مواعيد.

بنود المرحلة 0 وحالتها التنفيذية

المواصفة /home/moonui/hms-phase0-spec.md تنص: معتمدة من المالك، لم يبدأ أي بند (كل خانات الحالة فارغة حتى تاريخ قراءتها):

البند	المضمون	الخطر على LIS	بوابة الإثبات	الحالة
`W1-1`	رفع نطاق الفروع: `LisDataScope` ← `Modules/Core/app/Support/DataScope.php` مع shim توافقي (14 موضع نداء بلا تغيير)	لا خطر	سويتات LIS القائمة	لم يبدأ
`W1-2`	عمود `employee_id` خامل على `lab_doctors` (ربط طبيب←موظف HRM)	صفر	`LabDoctorApiTest` (11)	لم يبدأ
`W1-3`	استخراج `CreateLabRequest` Action بمطابقة بايت + `encounter_id` خامل على `lab_requests`	منخفض	`LabRequestApiTest` (42) + سويتات B2B (74)	لم يبدأ
`W1-4`	سجل تبعيات الصلاحيات في Core (`PermissionDependencyRegistry`) — يصلح انعكاس `RoleSaveService.php:10` ويجهّز تسجيل `his.*`	صفر (استجابات مطابقة بالبايت)	سويتات Role (47+)	لم يبدأ
`W2-1`	تحصين B2B (8 بنود: مؤشر اللوحة، 6 منتقيات واجهة، حارس الدمج، قيد فريد `UNIQUE(company_id, ext_scope_key, national_id)`، scopes مسماة…) + ترقية الكيان المشترك	منخفض — تغييرات مقصودة فقط	`LabPatientApiTest` (20) + اختبارات حراسة جديدة	لم يبدأ — البند 8 ينتظر قرار المالك
`W2-2`	فرض مفتاح الموديولات على API — وضع المراقبة فقط (القياس أثبت أن الفرض الفوري يكسر تدفقات شغّالة: إعداد شركة التطوير لا يذكر موديولات عليها بيانات حية)	لا حظر	مراجعة السجلات بعد أسبوعين	لم يبدأ

مؤجَّل صراحة إلى انطلاق HIS: سقّالة Modules/HIS وصلاحيات his.*، جداول Encounter/Folio، رفع طرق الدفع/الخزائن، تعميم قوائم الأسعار/التأمين، خدمة ترحيل الرسوم الموحدة (سجل التعميم — القسم 5+ من الدراسة).

الأسئلة التي تركتها الوثائق مفتوحة

سياسة روابط بوابة المريض لمرضى B2B (W2-1 بند 8): LabPatient.php:60-65 يصدر توكن بورتال لكل مريض — هل يستمر ذلك لصفوف B2B؟ ينتظر قرار المالك.
قرار فرض مفتاح الموديولات: مؤجل لما بعد أسبوعين من المراقبة + تنظيف إعدادات الشركات.
التصميم التفصيلي لـ Encounter/Folio: المبدأ معتمد، لكن الجداول والحقول لم تُصمَّم بعد (مؤجلة لانطلاق HIS).
حدود النطاق الإكلينيكي: النسخة الأولى «إداري-مالي صراحةً»؛ التوثيق السريري العميق (EMR كامل) قرارٌ منفصل لاحق — الخطر رقم 7 في سجل المخاطر.
الرفع الكامل لسجل الممارسين إلى Core: يُقيَّم فقط لو احتاجته موديولات غير صحية.

أين يلمس استحواذ OBGY هذه القرارات؟

الوثيقتان لا تذكران OBGY إطلاقاً — فكل ما يلي مواضع تقاطع نحددها نحن (استنتاج) بناءً على ما قرأناه في الوثيقتين وتحليل OBGY (/home/amrtechogate/public_html/obgy-erp-analysis.md):

أكبر فجوتين في الدراسة هما أقوى ما لدى OBGY معرفياً: محرك المواعيد (درجة 1/10) والمحتوى الإكلينيكي للعيادات — OBGY يدير زيارات ومواعيد عيادة فعلية (visits، visit_periods) وملفات إكلينيكية تخصصية كاملة (متابعة حمل ancsheet، عقم/حقن مجهري، سونار) يمكن أن تُثري تصميم Encounter ومحرك مواعيد المرحلة 1 كنموذج نطاق — لا ككود (استنتاج).
OBGY لا يصلح نواةً لـ HIS كودياً: تحليل OBGY يوثّق إطاراً قديماً (aw framework) بثغرات SQL injection مؤكدة وواسعة وبلا أي مفاتيح FK معلنة — بينما قرارات HMS تفرض موديول Laravel واحد Modules/HIS فوق منصة Moon. القيمة قيمة نموذج بيانات وسير عمل وترحيل بيانات، لا قيمة منصة (استنتاج مدعوم بقسم Migration-Relevant Conclusions في تحليل OBGY).
قرار هوية المريض يستوعب مرضى OBGY بلا تعديل: الكيان المشترك المرقّى من lab_patients هو الوجهة الطبيعية لترحيل جدول patients في OBGY، ولا شيء في OBGY يستدعي إعادة فتح قرار B2B أو قرار الجدول الواحد (استنتاج).
عقد القرار 3 قابل للتعميم على OBGY: نمط «منفّذ خدمة يُستدعى عبر Action + encounter_id» الذي صُمم للمعمل والأشعة يصلح نفسه لطلبات السونار والإجراءات النسائية (استنتاج).
سؤال جديد تطرحه OBGY ولم تُجب عنه الوثائق: هل تكون عيادة النساء والتوليد «تخصصاً» داخل عيادات المرحلة 1 (طبقة إكلينيكية فوق Encounter العام) أم موديولاً تخصصياً منفصلاً؟ الدراسة حذّرت من زحف نطاق EMR (الخطر 7) ومن تعدد الموديولات الصغيرة (قرار 2) — وكلاهما يرجّح كفة الدمج داخل HIS مع تأجيل العمق الإكلينيكي، لكن القرار نفسه غير محسوم في هذه الوثائق (استنتاج).