بعد مسح كامل للأدلة (تسعة أقسام موثقة من الشيفرة الفعلية)، وثلاثة مقترحات معمارية متنافسة، ومراجعة تحكيمية عدائية من ثلاث عدسات (الواقع الهندسي، التشغيل السريري، الأعمال والمنتج) — هذا هو القرار النهائي المسبب: مَن هو نواة الـ HIS، وأين يقف OBGY، وكيف يرتبط كل طرف بالآخر. القرار يحترم حرفياً كل القرارات الملزمة المعتمدة سابقاً: Modules/HIS موديول واحد، الاعتماديات أمامية فقط نحو LIS/Accounting/HRM، الرجوع بالأحداث فقط، LIS لا يُمس، ومرضى B2B يبقون في lab_patients.
القرار: OBGY ليس نواة الـ HIS ولن يكون. النواة هي Modules/HIS جديد يُبنى على منصة Moon ERP، ويُستخدم OBGY كـ«بذرة تصميم ومحتوى وأول عميل تجريبي». الأسباب الحاسمة، كلها موثقة من التحليل نفسه:
Encounter أصلاً — السجلات السريرية في النظام القديم لا تشير إلى جدول visits إطلاقاً (القسم 90.1 من التحليل)، بل تُربط بالمريض والتاريخ فقط. العمود الفقري يجب أن يُصمَّم جديداً في كل الأحوال.NPHIES FHIR) تعمل فعلياً في الإنتاج داخل Moon ERP اليوم.Encounter وOperativeNote وSurgicalBooking وخدمة الطابور بشكل محايد للتخصص «حتى تستهلكها وحدة HMS» — أي أن واضع المخطط حسم الجدل مسبقاً.في المقابل، قيمة OBGY الحقيقية لا تُهدر بل تُحصد في أربعة أشكال: (1) بذرة تصميم مُجرَّبة ميدانياً للنواة العامة (المواعيد/الطابور/فترات اليوم — حيث تسجل المنصة أضعف درجاتها 1/10، ونمط توحيد 18 جدولاً مستنسخاً في 4 جداول متعددة الأشكال، ومحرك الأسئلة والأجوبة، وسير العمليات الجراحية)؛ (2) حزمة محتوى تخصصية كاملة داخل Modules/Obgy؛ (3) أول عميل تجريبي مدفوع مع 10 سنوات بيانات حقيقية و~190 قائمة مصطلحات عربية منسّقة؛ (4) إثبات أن المرحلة الأولى الخارجية (العيادات) قابلة للبيع مستقلة.
القرار: فصل تام. Modules/HIS موديول واحد (التزاماً بالقرار المعتمد D2) يحمل النواة السريرية المحايدة للتخصص، وModules/Obgy موديول تخصصي مستقل يركَّب فوقه. القاعدة الذهبية — وهي نفسها التي تُبقي LIS قابلاً للبيع مستقلاً اليوم — تطبَّق درجة أعلى: HIS لا يستورد Obgy أبداً، ولا يذكر اسم أي تخصص في شيفرته؛ Obgy يستورد HIS أمامياً فقط، ويُسجّل نفسه عبر نقاط امتداد (PermissionDependencyRegistry وEncounterContentRegistry). هذا هو ما يجعل باقة «Moon Clinic» قابلة للبيع لمستشفى عام بلا قسم نساء، ويجعل مفتاح ترخيص Obgy ذا معنى تجاري حقيقي.
| العلاقة | الجملة الحاكمة |
|---|---|
| ERP ↔ LIS | LIS موديول تخصصي يركب على قضبان المنصة (BaseModel للتينانسي والتدقيق، DataScope للفروع، SequenceService للترقيم) ويرحّل مالياً حصراً عبر CreateJournalEntry — والمنصة لا تعرف شيئاً عن دواخله. |
| ERP ↔ HIS | HIS يستهلك خدمات المنصة أمامياً (Core وAccounting وHRM وInventory وNPHIES) عبر Actions وServices معلنة، والمنصة لا تتغير إلا بالترقيات المعتمدة في سجل التعميم (أبرزها استخراج ChargePostingService من PostLabInvoice). |
| HIS ↔ LIS | HIS يطلب التحاليل أمامياً عبر Modules\LIS\Actions\CreateLabRequest ممرراً encounter_id، وLIS لا يستورد HIS أبداً — المعلومات تعود خلفياً فقط عبر أحداثه القائمة LabResultReleased / LabRequestCompleted / CriticalResultDetected بصفر تعديل على LIS. |
| HIS ↔ OBGY | Obgy يستورد HIS أمامياً (يفتح his_encounters، يرحّل بنوده إلى his_folio_charges، يبني شيتاته على محرك النماذج والقواميس) ويسجّل صلاحياته وتبويباته عبر السجلات — وHIS لا يستورد Obgy ولا يسميه أبداً. |
| OBGY ↔ LIS | شيتات Obgy تطلب التحاليل عبر مسار HIS نفسه (CreateLabRequest + جدول الربط obgy_lis_test_map لـ276 فحصاً قديماً)، وتحاليل الذكورة والهرمونات تصبح فحوصات في كتالوج LIS نفسه بمدياتها المرجعية (WHO) — والنتائج تعود بالأحداث. |
| OBGY ↔ ERP | مريضة OBGY تصبح صفاً داخلياً في lab_patients مربوطاً مالياً عبر partner_id → AccBpExt (ما يلغي مزامنة cURL القديمة نهائياً)، ودواؤها في صنف Core Product ومخزون Inventory، ونقودها لا تمر إلا عبر his_folio_charges → ChargePostingService → CreateJournalEntry. |
| المقترح | الفكرة | الواقع الهندسي | التشغيل السريري | الأعمال والمنتج | النتيجة |
|---|---|---|---|---|---|
| P-PLATFORM-FIRST الفائز — عدستان من ثلاث | نواة HIS رفيعة محايدة للتخصص + Obgy أول موديول تخصصي مركّب | 7 | 8 (فائز) | 8 (فائز) | يُعتمد — بعد امتصاص ضوابط التسلسل من المقترح الثاني |
| OBGY-AS-SEED وصيف قوي | توليد Modules/HIS مباشرة من مخطط OBGY §95 وإطلاق صحة المرأة أولاً | 8 (فائز) | 7 | 7 | تُمتص ضوابطه: العميل التجريبي من المرحلة صفر، قاعدة «كل جدول له مستهلك إنتاجي»، بوابة التخصص الثاني |
| Thin-HIS / ERP-Maximalist | ~17 جدولاً + محرك نماذج EAV/JSON يحمل التوثيق السريري كله | 4.5 | 4.5 | 6 | يُرفض كمعمارية (السجل السريري كـJSON غير مقبول طبياً-قانونياً) — وتُنهب أفضل أفكاره |
منطق الحسم: العدسة الهندسية فضّلت OBGY-AS-SEED لأن تصميمه مدفوع الثمن مسبقاً (مخطط §95)، لكن عدستي التشغيل السريري والأعمال رجّحتا P-PLATFORM-FIRST لأنه الوحيد الذي يصل لمستشفى عام بمسار غير مشروط، ويُطلق التعميم التأميني/NPHIES مع أول باقة جديدة لا في آخر المراحل، ويحافظ على مصفوفة الترخيص الرباعية نظيفة، وبصفر قرارات معاد فتحها. القرار النهائي: P-PLATFORM-FIRST معدَّلاً بتسلسل OBGY-AS-SEED — أي «المنصة أولاً، ببذرة OBGY وعميله».
source=migration بدرجات ثقة وطوابير مراجعة طبية لا تخمينات صامتة)؛ أعمدة scheduled_at والموارد في his_appointments من اليوم الأول.his_observations المُنمَّط (سلاسل زمنية سريرية بنمط FHIR Observation — علامات حيوية، منحنيات الحمل، قياسات الجريبات)؛ his_episodes كرأس EpisodeOfCare عام (الحمل = نوع حلقة)؛ إصدارات نماذج غير قابلة للتعديل مع سير توقيع draft|signed|amended لكل استجابة سريرية (متطلب طبي-قانوني)؛ تحويل تحاليل الذكورة والهرمونات إلى كتالوج LIS؛ حوكمة «مبرر كسر الميتاداتا» لأي جدول تخصصي صلب جديد؛ الحدث العام FormResponseSubmitted.use Modules\Obgy خارج موديوله وuse Modules\HIS داخل LIS؛ تأجيل أي تعميم (نماذج/قواميس) إلى ما بعد وجود قوالب OBGY الحقيقية؛ القيد الفريد UNIQUE(source_type, source_id) على بنود الرسوم كضمانة قاعدة-بيانات ضد الترحيل المزدوج.| الموديول | الدور | أهم الجداول/المكونات | يستورد (أمامياً) ← | يُمنع عليه |
|---|---|---|---|---|
Modules/HIS جديد — موديول واحد | النواة السريرية المحايدة: المواجهة، الحساب المالي، المواعيد، الأوامر، النماذج، الملاحظات، الجراحة، ثم ADT لاحقاً | his_encounters، his_encounter_diagnoses، his_episodes، his_appointments، his_visit_periods، his_folios، his_folio_charges، his_folio_payments، his_deposits، his_prescriptions(+items)، his_service_orders(+items)، his_form_templates/versions/responses، his_observations، his_lookups، his_clinical_exams، his_patient_spouses، his_surgical_bookings، his_operative_notes؛ لاحقاً: his_wards/rooms/beds، his_bed_assignments | Core، LIS، Accounting، HRM، Inventory، NPHIES | استيراد Obgy أو تسمية أي تخصص |
Modules/Obgy جديد — تخصصي | عمق صحة المرأة: الشيتات المعقدة كجداول، البسيطة كمحتوى نماذج مُبذَّر | obgy_pregnancies، obgy_antenatal_visits، obgy_ivf_cycles + جداول المراحل (سحب بويضات، إرجاع أجنة، تجميد)، obgy_imaging_studies + موجودات الموجات، obgy_endoscopy_*، obgy_infertility_files، التواريخ التوليدية، obgy_lis_test_map؛ القياسات في his_observations والذكورة/الهرمونات في كتالوج LIS | HIS، Core، LIS | جداول مرضى/أطباء/أدوية/أسعار/خزائن خاصة، أو ترحيل GL مباشر |
Modules/LIS لا يُمس | المختبر كما هو — القيد الحاكم D5: صفر تأثير أداءً وسلوكاً | تغيير وحيد مؤجل: تفعيل FK على عموده الخامل lab_requests.encounter_id عند الانطلاق | (كما هو اليوم) | استيراد HIS نهائياً |
Core / Accounting / HRM / Inventory / NPHIES | العمود الفقري القائم | ترقيات معتمدة فقط: ChargePostingService في Core (تعميم PostLabInvoice ببادئة إعدادات his.*)، توسيع type-hints في NPHIES (FhirPatientBuilder) للمريض المشترك | — | أي اعتماد على موديول سريري |
| الحدث | المُصدِر | المستهلكون | الحمولة الأساسية |
|---|---|---|---|
LabResultReleased قائم | LIS | HIS (إلحاق النتيجة بالمواجهة)، Obgy (عرضها في الشيت) | LabResult |
LabRequestCompleted / CriticalResultDetected قائم | LIS | HIS (إغلاق الأمر / صندوق إنذار الطبيب والتمريض) | LabRequest / النتيجة الحرجة |
BusinessPartnerCreated قائم | Core | Accounting (CreatePartnerAccounts — حسابات ذمم المريض آلياً) | الشريك التجاري |
EncounterOpened / EncounterClosed جديد | HIS | Obgy، التقارير، الإشعارات | encounter_id, patient_id, type |
AppointmentBooked / AppointmentCheckedIn جديد | HIS | شاشة الانتظار، البوابة، الإشعارات | appointment_id, period_id |
FolioChargePosted جديد — الخطاف المالي الموحد | HIS | أي موديول سريري حالي أو مستقبلي (أشعة/عمليات) — مع قيد UNIQUE(source_type, source_id) | folio_id, source_type, source_id, total |
FolioClosed جديد | HIS | توليد فواتير مقسومة حسب الدافع → ChargePostingService → CreateJournalEntry(source_type='his_invoice') → مطالبة NphiesClaimService::submit() | folio_id |
PatientAdmitted/Transferred/Discharged جديد — مرحلة التنويم | HIS | وظيفة يوم-السرير الليلية على الـ Folio، لوحة الأسرّة | encounter_id, bed_id |
PrescriptionDispensed جديد | HIS | Inventory (StockService::decreaseStock بمرجع الروشتة) + بند Folio | prescription_id, encounter_id |
FormResponseSubmitted جديد — ممتص | HIS | مستمعو التخصصات (مثال: Obgy يُقدّم مرحلة دورة الحقن المجهري عند توقيع نموذج السحب) | form_response_id, form_code, encounter_id |
PregnancyOpened/Closed، IvfCycleStageCompleted جديد | Obgy | داخل Obgy والتقارير فقط — HIS لا يستمع لأي تخصص | pregnancy_id / cycle_id, stage |
lab_patients مرقّى في مكانه (القرار المعتمد D1 — لا جدول مرضى ثانٍ أبداً، لا إعادة تسمية): HIS وObgy يستهلكانه عبر النطاق المسمّى LabPatient::internal() فقط؛ مرضى B2B معزولون بـexternal_lab_id والفهرس الفريد؛ مرضى OBGY يُرحَّلون كصفوف داخلية (statusno → mrn) مع فصل بيانات الزوج إلى his_patient_spouses؛ الجسر المالي partner_id → AccBpExt يلغي مزامنة cURL القديمة.his_encounters تحمل type (عيادات/تنويم/طوارئ/يوم واحد) وparent_encounter_id من أول هجرة — فالتنويم لاحقاً إضافة لا إعادة بناء؛ attending_doctor_id → lab_doctors → employees → users توحّد الهوية السريرية والوظيفية؛ his_episodes فوقها للحلقات الطولية (الحمل، ملف العقم)؛ وعمود lab_requests.encounter_id الخامل (هجرة 2026_06_10_160000) يحصل على مفتاحه الأجنبي عند الانطلاق.his_folios (دافع: نقدي/تأمين/حساب B2B) + his_folio_charges متعددة المصادر بقيد UNIQUE(source_type, source_id) — الفعل السريري يُفوتر مرة واحدة فقط، وفواتير المختبر تدخل بالمرجع ولا تُرحَّل ثانية (D4)؛ الإقفال يولّد الفواتير ويرحّل عبر ChargePostingService المستخرج من PostLabInvoice المجرَّب، وأعمدة المطالبة (nphies_claim_status...) تتبع نمط lab_invoices المثبت.