الرؤية الاستراتيجية: كيف تكتمل المنظومة الطبية؟
Moon ERP × LIS × HIS × OBGY

الإجابات المباشرة

دور OBGY الحقيقي — أربعة أدوار بلا سطر كود واحد

• متبرّع بالأنماط لنواة HIS: نحو ثلث أصوله (نموذج الزيارة والطابور وسعة الفترات، توحيد 18 جدول روشتات وتحاليل في 4 جداول، محرك أسئلة التاريخ المرضي القابل للتهيئة، الفحص لكل جهاز بالجسم، قائمة انتظار العمليات والتقرير الجراحي، محرك ~190 قائمة ترميز) يدخل تصميم النواة العامة نفسها.
• المحتوى التخصصي داخل Modules/Obgy: نحو نصف أصوله (متابعة الحمل، دورات الحقن المجهري بجداول مراحلها، الأشعة النسائية، المناظير، ملفات العقم) — الشيتات المعقدة جداول حقيقية، والبسيطة محتوى لمحرك النماذج.
• أول عميل تجريبي مدفوع وبروفة ترحيل: 10 سنوات بيانات حقيقية و~190 قاموس مفردات عربية منقّحة بالإنتاج — ميزة تنافسية لا يملكها أي منافس.
• إثبات السوق: يثبت أن منصة العيادات الخارجية (المرحلة الأولى) قابلة للبيع وحدها قبل اكتمال التنويم.

خريطة العلاقات في ست جمل

1. ERP ↔ LIS: قائم اليوم — LIS يركب على قضبان المنصة (الفروع، الصلاحيات، الترقيم) ويرحّل قيوده عبر CreateJournalEntry فقط.
2. ERP ↔ HIS: الـ HIS يستهلك الحسابات والموارد البشرية والمخزون والتأمين للأمام كخدمات جاهزة — لا يعيد بناء أي منها.
3. HIS ↔ LIS: الـ HIS يطلب التحاليل عبر نقطة الدخول الجاهزة CreateLabRequest برقم المواجهة، والنتائج تعود عبر الأحداث (LabResultReleased) — الـ LIS لا يستورد من HIS أبداً ولا يتأثر إطلاقاً.
4. HIS ↔ OBGY: موديول Obgy يستورد من HIS (المواجهات، الفوترة، النماذج) ويسجّل نفسه في سجلات التوصيل — والـ HIS لا يعرف اسمه أصلاً.
5. OBGY ↔ LIS: تحاليل الذكورة والهرمونات تصبح فحوصات في كتالوج LIS نفسه بمرجعيات WHO — بلا أي ازدواج.
6. OBGY ↔ ERP: مرضى OBGY يصبحون سجلات في ملف المريض الموحد، أدويته في كتالوج المنتجات والمخزون، وأمواله عبر الـ Folio إلى الحسابات — ويُلغى ربط cURL القديم نهائياً.

كيف حُسم القرار؟

تنافست ثلاث معماريات حقيقية دافع عن كل منها مهندس مستقل: «المنصة أولاً» (HIS نواة عامة رقيقة + Obgy إضافة تخصصية)، «OBGY كبذرة» (بناء HIS بتعميم مخطط OBGY وبيع مستشفى النساء أولاً)، و«الحد الأدنى» (توثيق إكلينيكي كله بمحرك نماذج وصفي). حكم عليها ثلاثة محكّمون عدائيون من عدسات الهندسة والتشغيل الإكلينيكي والمنتج: فازت «المنصة أولاً» بعدستين (8/10 إكلينيكياً و8/10 تجارياً)، وفازت «OBGY كبذرة» بعدسة الهندسة (8/10) — فاعتُمدت «المنصة أولاً المخصّبة بـ OBGY»: معمارية المنصة، مع امتصاص أفضل أفكار المقترحين الخاسرين (الجداول النوعية للقياسات السريرية، تثبيت إصدارات النماذج، تحويل تحاليل الذكورة لكتالوج LIS، الانضباط في حواجز التعميم). التفاصيل الكاملة بجداول الدرجات في قسم القرار المعماري، وخمسة سيناريوهات تشغيلية كاملة في قسم السيناريوهات، والمراحل في خارطة الطريق.

الخلاصة للإدارة

المعادلة التي طلبتموها تتحقق هكذا: الـ ERP هو الأرض، والـ HIS هو الهيكل الإكلينيكي العام فوقها، والـ LIS وOBGY (وأي تخصص قادم) أجنحة متخصصة تركب على الهيكل نفسه. بهذا تبيعون لأي مستشفى منصة عامة كاملة، وتتميزون في سوق النساء والخصوبة بعمق إكلينيكي لا يملكه أحد، دون أن يعيق أي طرف الآخر — وكل قرار هنا ملتزم بالقرارات المعتمدة سابقاً (LIS لا يُمس، HIS موديول واحد، الاعتماديات للأمام فقط).

أولاً: هل يكون OBGY هو نواة الـ HIS؟ — الجواب: لا، بإجماع الأدلة

القرار: OBGY ليس نواة الـ HIS ولن يكون. النواة هي Modules/HIS جديد يُبنى على منصة Moon ERP، ويُستخدم OBGY كـ«بذرة تصميم ومحتوى وأول عميل تجريبي». الأسباب الحاسمة، كلها موثقة من التحليل نفسه:

• OBGY يفتقد الكيان الأهم في أي HIS: لا يوجد مفهوم Encounter أصلاً — السجلات السريرية في النظام القديم لا تشير إلى جدول visits إطلاقاً (القسم 90.1 من التحليل)، بل تُربط بالمريض والتاريخ فقط. العمود الفقري يجب أن يُصمَّم جديداً في كل الأحوال.
• لا قدرة تنويم على الإطلاق: صفر ADT، صفر أسرّة/أجنحة، صفر طوارئ، صفر تمريض، صفر eMAR — أي أن 5 من 14 قدرة أساسية لأي مستشفى عام غائبة كلياً عن OBGY.
• لا دورة تأمين: النظام القديم نقدي/فيزا فقط؛ بينما دورة المطالبات السعودية الحرجة (NPHIES FHIR) تعمل فعلياً في الإنتاج داخل Moon ERP اليوم.
• ~48% من محتواه تخصص نسائي بحت (حمل، حقن مجهري، ذكورة، مناظير، عقم) — نظام نصفه محتوى تخصصي لا يصلح أساساً لـ HIS عام.
• صفر شيفرة قابلة للنقل: PHP 5.6 منتهي الدعم، ثغرات SQL Injection مؤكدة ومنتشرة، API موبايل بلا مصادقة — القاعدة الصارمة R12 في مخطط الترحيل نفسه تمنع نقل أي endpoint قديم.
• مخطط ترحيل OBGY نفسه يتبنى هذا الاتجاه: القسم §95 (2.6) صمّم 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 ذا معنى تجاري حقيقي.

ثالثاً: علاقة كل طرف بالآخر — جملة واحدة لكل علاقة

رابعاً: مقارنة المقترحات الثلاثة ودرجات المحكمين

منطق الحسم: العدسة الهندسية فضّلت OBGY-AS-SEED لأن تصميمه مدفوع الثمن مسبقاً (مخطط §95)، لكن عدستي التشغيل السريري والأعمال رجّحتا P-PLATFORM-FIRST لأنه الوحيد الذي يصل لمستشفى عام بمسار غير مشروط، ويُطلق التعميم التأميني/NPHIES مع أول باقة جديدة لا في آخر المراحل، ويحافظ على مصفوفة الترخيص الرباعية نظيفة، وبصفر قرارات معاد فتحها. القرار النهائي: P-PLATFORM-FIRST معدَّلاً بتسلسل OBGY-AS-SEED — أي «المنصة أولاً، ببذرة OBGY وعميله».

خامساً: الأفكار الممتصة من المقترحين الخاسرين (ملزمة في التنفيذ)

• من OBGY-AS-SEED: توقيع عيادة OBGY كعميل تجريبي مدفوع أثناء المرحلة صفر (خدمات الترحيل تُفوتر وتموّل الطريق)؛ قاعدة «كل جدول في النواة له مستهلك إنتاجي في أول قطار إصدار» كشرط إطلاق صارم؛ بوابة «التخصص الثاني» الملزمة قبل تمويل التنويم لإثبات حياد النواة؛ نمط ETL الآمن سريرياً (الصفوف غير المطابقة تصبح مواجهات source=migration بدرجات ثقة وطوابير مراجعة طبية لا تخمينات صامتة)؛ أعمدة scheduled_at والموارد في his_appointments من اليوم الأول.
• من ERP-Maximalist: جدول his_observations المُنمَّط (سلاسل زمنية سريرية بنمط FHIR Observation — علامات حيوية، منحنيات الحمل، قياسات الجريبات)؛ his_episodes كرأس EpisodeOfCare عام (الحمل = نوع حلقة)؛ إصدارات نماذج غير قابلة للتعديل مع سير توقيع draft|signed|amended لكل استجابة سريرية (متطلب طبي-قانوني)؛ تحويل تحاليل الذكورة والهرمونات إلى كتالوج LIS؛ حوكمة «مبرر كسر الميتاداتا» لأي جدول تخصصي صلب جديد؛ الحدث العام FormResponseSubmitted.
• ضوابط هندسية مشتركة: بوابات CI آلية تمنع use Modules\Obgy خارج موديوله وuse Modules\HIS داخل LIS؛ تأجيل أي تعميم (نماذج/قواميس) إلى ما بعد وجود قوالب OBGY الحقيقية؛ القيد الفريد UNIQUE(source_type, source_id) على بنود الرسوم كضمانة قاعدة-بيانات ضد الترحيل المزدوج.

سادساً: خريطة الموديولات المعتمدة واتجاهات الاعتماد

سابعاً: عقود الأحداث (Event Contracts)

ثامناً: العمود الفقري للبيانات — قرار MPI / Encounter / Folio

• سجل المرضى الرئيسي (MPI): lab_patients مرقّى في مكانه (القرار المعتمد D1 — لا جدول مرضى ثانٍ أبداً، لا إعادة تسمية): HIS وObgy يستهلكانه عبر النطاق المسمّى LabPatient::internal() فقط؛ مرضى B2B معزولون بـexternal_lab_id والفهرس الفريد؛ مرضى OBGY يُرحَّلون كصفوف داخلية (statusno → mrn) مع فصل بيانات الزوج إلى his_patient_spouses؛ الجسر المالي partner_id → AccBpExt يلغي مزامنة cURL القديمة.
• المواجهة (Encounter): his_encounters تحمل type (عيادات/تنويم/طوارئ/يوم واحد) وparent_encounter_id من أول هجرة — فالتنويم لاحقاً إضافة لا إعادة بناء؛ attending_doctor_id → lab_doctors → employees → users توحّد الهوية السريرية والوظيفية؛ his_episodes فوقها للحلقات الطولية (الحمل، ملف العقم)؛ وعمود lab_requests.encounter_id الخامل (هجرة 2026_06_10_160000) يحصل على مفتاحه الأجنبي عند الانطلاق.
• الحساب المالي (Folio): his_folios (دافع: نقدي/تأمين/حساب B2B) + his_folio_charges متعددة المصادر بقيد UNIQUE(source_type, source_id) — الفعل السريري يُفوتر مرة واحدة فقط، وفواتير المختبر تدخل بالمرجع ولا تُرحَّل ثانية (D4)؛ الإقفال يولّد الفواتير ويرحّل عبر ChargePostingService المستخرج من PostLabInvoice المجرَّب، وأعمدة المطالبة (nphies_claim_status...) تتبع نمط lab_invoices المثبت.

السيناريو 1: مريضة عيادة نساء خارجية — من الحجز إلى القيد المحاسبي

1. الحجز: موظفة الاستقبال (أو بوابة المريض) تحجز موعداً في Modules/HIS — صف في his_appointments مرتبط بفترة سعة في his_visit_periods، ويُطلق الحدث AppointmentBooked فتتحدّث شاشة الانتظار.
2. الوصول والطابور: عند تسجيل الحضور (AppointmentCheckedIn) يفتح HIS مواجهة his_encounters بنوع opd ورقم تسلسلي من SequenceService، ويستمد المريضة من lab_patients عبر النطاق internal()، ويضبط queue_position — ويُطلق EncounterOpened.
3. الشيت السريري: الطبيبة تفتح مساحة العمل /clinic/*؛ تبويب الشيت النسائي يأتي من Modules/Obgy المسجّل في EncounterContentRegistry: الشيت البسيط يُحفظ كاستجابة نموذج his_form_responses مثبتة على إصدار غير قابل للتعديل (his_form_versions) ثم تُوقَّع (draft → signed)، والعلامات الحيوية تُسجَّل صفوفاً منمّطة في his_observations.
4. الروشتة: وصفة في his_prescriptions/his_prescription_items بأصناف من Core Product؛ عند الصرف من الصيدلية يُطلق PrescriptionDispensed فيخصم Inventory StockService::decreaseStock المخزون بمرجع الروشتة، ويُضاف بند إلى his_folio_charges.
5. طلب التحاليل: الطبيبة تطلب تحليلاً من شاشة HIS التي تستدعي Modules\LIS\Actions\CreateLabRequest (المسار المستخرج خصيصاً لهذا) ممررةً encounter_id — فيتولد طلب lab_requests بتسعيره وفاتورته داخل LIS بلا أي تعديل عليه، ويظهر في worklists المختبر كأي طلب آخر.
6. النتيجة: المختبر يُدخل ويعتمد ويُصدر النتيجة بدورة عمله المعتادة؛ الحدث LabResultReleased يصل مستمعَ HIS فيُلحق النتيجة بالمواجهة وتظهر داخل شيت Obgy عبر obgy_lis_test_map؛ ولو كانت حرجة فالحدث CriticalResultDetected ينبّه الطبيبة فوراً.
7. الفوترة: كشف العيادة والسونار والصرف بنود في his_folio_charges بقيد UNIQUE(source_type, source_id)؛ فاتورة المختبر تدخل الـ Folio بالمرجع فقط ولا تُرحَّل ثانية.
8. القيد المحاسبي: إقفال الـ Folio (FolioClosed) يولّد الفاتورة حسب الدافع، ثم يرحّل ChargePostingService القيد عبر Modules\Accounting\Actions\CreateJournalEntry (مدين ذمم المريضة عبر AccBpExt.ar_account_id / دائن إيراد وضريبة) بمصدر source_type='his_invoice' — ولو كانت مؤمَّنة تنطلق المطالبة عبر NphiesClaimService::submit().

السيناريو 2: حالة ولادة وتنويم — ADT والعمليات ومطالبة التأمين

1. الدخول (Admission): من الطوارئ أو بحجز مسبق، يفتح HIS مواجهة his_encounters بنوع ipd (وقد تكون ابنة مواجهة العيادة عبر parent_encounter_id)، ويُطلق PatientAdmitted.
2. السرير: تخصيص سرير في his_bed_assignments (جناح → غرفة → سرير من his_wards/his_rooms/his_beds)؛ كل نقلة داخلية تُسجَّل بحدث PatientTransferred، ووظيفة ليلية تضيف بند «يوم سرير» إلى his_folio_charges آلياً.
3. التحقق التأميني: عند مكتب الدخول يُستدعى NphiesEligibilityService::check() (بعد توسيع مدخلاته للمريض المشترك)، ويُحصل على موافقة مسبقة NphiesPreauth تُربط بالـ Folio.
4. الأوامر أثناء الإقامة: تحاليل عبر CreateLabRequest(encounter_id, source=in_patient) — قيمة الـ enum موجودة أصلاً في LIS؛ أدوية عبر his_prescriptions ثم الصرف والخصم المخزني؛ كل بند يصل الـ Folio بحدث FolioChargePosted.
5. الولادة القيصرية: حجز في his_surgical_bookings، ثم تقرير عمليات منمّط في his_operative_notes (فريق الجراحة في his_operative_note_staff، التخدير والشق من قواميس his_lookups) — وتسجيل المولود حدث DeliveryRecorded في Modules/Obgy؛ مستلزمات العملية تُخصم من مخزن العمليات (Inventory warehouse) وتتقيد كبنود Folio.
6. الخروج: PatientDischarged يحرر السرير ويغلق المواجهة؛ FolioClosed يقسم الفاتورة: حصة المريضة نقداً عبر خزائن وورديات الكاشير القائمة، وحصة التأمين فاتورة تحمل أعمدة nphies_claim_status / nphies_preauth_ref / nphies_covered_amount بنمط lab_invoices المثبت.
7. المطالبة: NphiesClaimService::submit() يبني مطالبة FHIR (بالتشخيصات من his_encounter_diagnoses وأكواد SBS على كتالوج الخدمات) ويسجّل كل شيء في nphies_transactions، والرد يعود بالـ polling ويحدّث الفاتورة — ثم قيد التحصيل عبر CreateJournalEntry.

السيناريو 3: دورة حقن مجهري IVF — حلقة طولية عبر الموديولات

1. فتح الملف: ملف عقم للزوجين: المريضة صف lab_patients داخلي، وبيانات الزوج في his_patient_spouses؛ تُفتح حلقة رعاية his_episodes بنوع «دورة IVF» يملك تفاصيلها obgy_ivf_cycles في Modules/Obgy، ويُطلق IvfCycleOpened.
2. تحاليل ما قبل الدورة: الهرمونات وتحليل السائل المنوي فحوصات في كتالوج LIS نفسه (مُبذَّرة بمدياتها المرجعية WHO) تُطلب عبر CreateLabRequest — فتحصل مجاناً على دورة التحقق والاعتماد وواجهات الأجهزة، وتعود النتائج بحدث LabResultReleased إلى شيت العقم.
3. المتابعة والتنشيط: كل زيارة متابعة مواجهة opd مرتبطة بالحلقة؛ قياسات الجريبات وسماكة البطانة تُسجَّل صفوفاً منمّطة في his_observations وتُعرض في ودجة الشبكة الزمنية (observation grid) — لا JSON مدفوناً.
4. السحب والإرجاع: سحب البويضات إجراء جراحي يومي (his_encounters type=daycase + his_surgical_bookings)؛ توقيع نموذج السحب يُطلق FormResponseSubmitted فيستمع Obgy ويقدّم مرحلة الدورة (IvfCycleStageCompleted): تخصيب → obgy_embryo_transfers → تجميد الفائض في obgy_cryopreservations.
5. المال والنتيجة: كل مرحلة ترحّل بنودها إلى his_folio_charges (باقة الدورة أو بنوداً متدرجة) وتُفوتر عبر نفس مسار ChargePostingService؛ ونتيجة الدورة (حمل إيجابي) تغلق الحلقة وتفتح تلقائياً ملف حمل obgy_pregnancies بحدث PregnancyOpened — فتبدأ متابعة الحمل على نفس العمود الفقري.

السيناريو 4: مستشفى عام بلا قسم نساء — نفس المنصة بمفتاح ترخيص مختلف

1. التفعيل: عميل جديد (مستشفى باطنة وجراحة عامة) يُرخَّص له Core + Accounting + HRM + Inventory + LIS + HIS فقط؛ Modules/Obgy غير مفعّل — والتحقق على مستوى الـ API (بند المرحلة صفر) لا الواجهة فقط.
2. لا أثر للتخصص: لأن HIS لا يستورد Obgy ولا يسميه، تعمل النواة كاملة: مواعيد وطوابير، مواجهات، تشخيصات ICD في his_encounter_diagnoses، أوامر تحاليل وأدوية، تنويم وأسرّة، عمليات عامة في his_surgical_bookings/his_operative_notes — بلا جدول نسائي واحد في قاعدة بياناته.
3. محتوى تخصصاته: شيتات الباطنة والجراحة تُؤلَّف كمحتوى في محرك النماذج (his_form_templates + قواميس his_lookups بنطاقات خاصة) — وأي تخصص مستقبلي يحتاج جداول صلبة يمر بحوكمة «مبرر كسر الميتاداتا».
4. الإثبات المؤسسي: هذا السيناريو هو نفسه «بوابة التخصص الثاني» الملزمة قبل تمويل التنويم: تشغيل تخصص رفيع كمحتوى خالص يثبت للإدارة أن النواة ليست نظام نساء وتوليد متنكراً.
5. نفس المال ونفس المختبر: الفوترة والمطالبات والمخزون والرواتب تمر بنفس المسارات (FolioClosed → ChargePostingService → CreateJournalEntry → NPHIES) — أي أن باقة «Moon Hospital» منتج تركيب وترخيص، لا مشروع تطوير جديد لكل عميل.

السيناريو 5: معمل B2B الحالي يستمر — صفر تأثر بكل ما سبق

1. العزل بالبيانات: مرضى المعامل الخارجية يبقون في lab_patients بمالكهم external_lab_id والفهرس الفريد (company_id, ext_scope_key, national_id) — القرار المحسوم 37/40؛ وHIS لا يراهم أصلاً لأنه يقرأ عبر LabPatient::internal() حصراً، وبلا أي Global Scope شامل (القيد المعتمد).
2. العزل بالاتجاه: LIS لا يستورد HIS بنص القرار D2؛ عموده encounter_id يبقى NULL لكل طلبات B2B والمشي المباشر، فلا يتغير سلوك بوابة المعامل الخارجية ولا سلسلة المناديب (lab_external_lab_couriers) ولا الفوترة الشهرية للمعامل.
3. العزل بالأداء: القيد الحاكم D5 يسري على كل مرحلة: صفر استعلامات مضافة على المسارات الساخنة (worklist والاستقبال)، وبوابة قبول لكل بند = نجاح كل الاختبارات + قياس curl قبل/بعد، وأي تدهور يُرجِع البند فوراً.
4. العزل بالأدوات: بوابات CI تمنع آلياً ظهور use Modules\HIS داخل LIS — حماية ميكانيكية لا تعتمد على الانضباط وحده، لأن nwidart لا يفرض اتجاهات الاعتماد بنفسه.
5. الخلاصة التجارية: باقة «Moon Lab» (Tier-1) تظل تُباع وتعمل مستقلة تماماً كما اليوم — وهي التي تموّل المراحل الأولى من خارطة الطريق.

تسلسل المراحل

المخاطر والقرارات المطلوبة من الإدارة

نظرة رقمية سريعة

خدمات المنصة التي يرثها أي موديول جديد مجاناً

• تعدد الشركات كل نموذج يرث App\Models\BaseModel فيحصل تلقائياً على TenantAware (ختم company_id عند الإنشاء + نطاق scopeTenant)، وAuditable (سجل تدقيق كامل عبر spatie/laravel-activitylog)، وSoftDeletes، وHasArabicContent (ثنائية اللغة name/name_ar).
• الفروع جدول branches مركزي (app/Models/Branch.php) بعلاقة branch_user مع علم is_primary؛ كل عملية جديدة تُختم بفرع المستخدم الأساسي عبر DataScope::operatingBranchId().
• رؤية البيانات نمط Modules/Core/app/Support/DataScope.php: لكل دور data_scope بقيم all / branch / own تُطبَّق على استعلامات القوائم مع دعم فلتر ?branch_id= ورأس X-Branch-Id من واجهة Angular — صُمّم أصلاً لـ LIS وقابل للتطبيق المباشر على أي موديول إكلينيكي.
• الصلاحيات spatie/laravel-permission مع Modules\Core\Models\Role، وسجلّ تبعيات الصلاحيات PermissionDependencyRegistry الذي يسمح لكل موديول بتسجيل شجرة صلاحياته وحزم أدواره الجاهزة عند الإقلاع (LIS مسجَّل بالبادئة lis من LISServiceProvider) — نفس النمط جاهز لبادئتي his وobgy.
• ناقل الأحداث أحداث نطاق حقيقية: النواة تبث BusinessPartnerCreated فيستمع موديول المحاسبة عبر CreatePartnerAccounts لإنشاء الحسابات تلقائياً؛ وLIS يملك 10 أحداث (مثل LabResultReleased وCriticalResultDetected) مع 11 مستمعاً داخلياً.
• الترقيم SequenceService بترقيم لكل شركة/موديول/كيان مع خيار per_branch وإعادة تصفير حسب السنة المالية (sequences + sequence_counters).
• الإعدادات SettingsService بأربعة نطاقات (SettingScope: global / company / branch / user) مع تعريفات setting_definitions.
• الموافقات محرك ApprovalWorkflowService متعدد المستويات (approval_workflows / approval_workflow_levels / approval_logs) — حالياً مقصور على Sales وPurchases في ApprovalModule ويحتاج توسعة للسياقات الإكلينيكية (استنتاج).
• المرفقات مرفقات Polymorphic موحّدة: attachments + سمة HasAttachments (morphMany) — جاهزة لملفات الأشعة والتقارير الطبية.
• الذكاء الاصطناعي طبقة AI جاهزة في النواة: AiChatService مع جداول ai_settings وai_usage_logs وai_response_cache.
• SaaS طبقة ترخيص وحصص على مستوى التطبيق: MoonLicenseClient وQuotaTrackingService وسمة TracksQuota (مثل max_users وmax_branches) وCentralSyncQueue.

سجل الأطراف الموحّد: يوجد «شريك أعمال» ولا يوجد «مريض» في النواة

الكيان الرئيسي للأطراف في النواة هو Modules\Core\Models\BusinessPartner (جدول business_partners) بأعلام is_customer/is_supplier وعلاقات جهات اتصال وعناوين، وتُبنى فوقه امتدادات لكل موديول: المحاسبة عبر AccBpExt وCRM عبر crm_customer_ext (partner_id). أما المريض فلا وجود له على مستوى النواة إطلاقاً؛ الكيان الوحيد للمرضى هو Modules\LIS\Models\LabPatient (جدول lab_patients) داخل موديول المعمل، ويحمل mrn وبيانات التأمين ورموز بوابة المريض، ويرتبط بسجل الأطراف عبر partner_id. كذلك يرتبط الأطباء (LabDoctor) وشركات التأمين (LabInsuranceContract) والمعامل الخارجية (LabExternalLab) جميعاً بـBusinessPartner عبر partner_id. أي مشروع HIS سيتطلب ترقية «ملف المريض» إلى سجل رئيسي مشترك بدل بقائه حبيس موديول المعمل (استنتاج).

الموديولات الخمسة عشر وكياناتها الرئيسية

كيف يندمج موديول إكلينيكي في المنصة؟ (نموذج LIS العامل)

1. التسجيل: مزوّد خدمة لكل موديول (مثل CoreServiceProvider) يحمّل الهجرات والإعدادات والترجمات تلقائياً، والتفعيل عبر modules_statuses.json.
2. الهوية: ربط الكيانات الخارجية (طبيب، شركة تأمين، معمل خارجي، مريض) بسجل BusinessPartner عبر partner_id.
3. الصلاحيات: تسجيل شجرة صلاحيات الموديول في PermissionDependencyRegistry::register() مع حزم أدوار جاهزة.
4. المالية: ترحيل مباشر إلى دفتر الأستاذ — Modules/LIS/app/Actions/PostLabInvoice.php يستدعي Modules\Accounting\Actions\CreateJournalEntry (قيود عادية وقيود تأمين).
5. سير العمل: أحداث نطاق (LabSampleReceived ← GenerateResultsOnSampleReceived، LabResultReleased ← PostInvoiceItemOnResultRelease) تفصل المراحل الإكلينيكية عن المالية.

الخلاصة الاستراتيجية: المنصة تقدّم لأي موديول HIS أو OBGY جديد البنية الإدارية والمالية والأمنية كاملةً؛ الفجوة الوحيدة الجوهرية هي غياب «سجل مريض موحّد» على مستوى النواة، وهي نقطة القرار المعمارية الأولى قبل بناء HIS (استنتاج).

حجم الموديول بالأرقام

خريطة الكيانات الأساسية

جميع الجداول تحمل البادئة lab_ والموديول مكتفٍ ذاتياً مع جسور محسوبة نحو بقية الـ ERP:

• lab_patients — سجل مرضى خاص بالمعمل (لا يوجد سجل مرضى مركزي في الـ ERP حتى الآن)، مربوط بشركاء الأعمال عبر partner_id → Modules\Core\Models\BusinessPartner، مع توكن دائم لبوابة النتائج portal_link_token يُولَّد تلقائياً عند الإنشاء.
• lab_doctors — الأطباء المحوِّلون، مربوطون بقسم HRM عبر department_id وبحسابات العمولات في المحاسبة عبر commission_account_id وcommission_payable_account_id.
• lab_requests — رأس الطلب: ترقيم تسلسلي عبر SequenceService، أولوية، حالة، مصدر RequestSource يتضمن أصلاً قيم in_patient وemergency (تحسّب مبكر لطلبات المستشفى)، وحقول تأمين وفرع وقائمة أسعار.
• lab_samples — العينات بسلسلة حيازة كاملة (جمع/استلام/رفض/معالجة بطوابع _at/_by)، وانقسام عينات عبر parent_id، والسجل الرسمي في lab_sample_custody_logs.
• lab_results — النتائج بآلة حالات pending → entered → validated → approved → released مع مسارات سحب وتصحيح وإبطال، ومصدر إدخال entry_source (يدوي/أجهزة/معمل خارجي)، وربط أجهزة التحاليل (lab_machines وlab_machine_results وقواعد التحقق الآلي).
• lab_invoices — فواتير بأنواع standard / insurance_invoice / external_lab_payable / external_lab_receivable وروابط قيود journal_entry_id وcogs_journal_entry_id وحقول مطالبات nphies_*.
• منظومة B2B كاملة: lab_external_labs وتسعيرها وإحالاتها، وفوترة شهرية، ومناديب نقل العينات عبر الجدول المحوري lab_external_lab_couriers (هجرة 2026_06_09_150000_add_b2b_courier_pickup_foundation.php: العينة تولد at_external_lab ثم in_transit ثم collected).
• طبقات داعمة: تأمين وعقود، عمولات أطباء وتسوياتها، كواشف ومخزون، جودة QC بقواعد Westgard، وقوالب باثولوجي lab_histopath_templates.

دورة حياة الطلب — من الاستقبال إلى الفاتورة

1. الاستقبال: إنشاء الطلب عبر الأكشن Modules\LIS\Actions\CreateLabRequest — وهو مستخرج نصياً من الكنترولر خصيصاً «لكي يستطيع HIS إنشاء طلبات معمل عبر نفس المسار» (تعليق موثق في الكود: HMS Phase-0 W1-3). شاشة الاستقبال تُنشئ الفاتورة وتحصّل الدفع في نفس الخطوة، وسلسلة تسعير واضحة: سعر صريح ← تسعير معمل خارجي ← قائمة أسعار الطبيب ← السعر الافتراضي.
2. سحب العينات: الجمع يبث LabSampleCollected، والاستلام يبث LabSampleReceived الذي يولّد صفوف النتائج المعلّقة، ويفتح معالجة الأقسام، ويُنشئ إحالات خارجية تلقائياً للفحوصات المُسنَدة للخارج.
3. قوائم العمل: كانبان أقسام، صندوق نتائج الأجهزة مع مطابقة آلية MachineResultMatchingService وقواعد تحقق تلقائي.
4. إدخال النتائج: يبث LabResultEntered (يستهلك الكواشف ويحدّث حالة الطلب) وCriticalResultDetected للقيم الحرجة (إنذار فوري).
5. التحقق ← الاعتماد ← الإصدار: سلّم صلاحيات منفصل لكل خطوة (lis.results.validate / approve / release) مع صلاحية استثنائية محروسة release_unpaid.
6. عند الإصدار: حدث LabResultReleased يشغّل سلسلة مستمعين مرتّبة عمداً في EventServiceProvider: تجميع الباقات والمعادلات ← النشر التلقائي للبوابة ← ترحيل بند الفاتورة B2B محاسبياً ← قلب الطلب إلى completed وبث LabRequestCompleted.
7. بعد الإصدار: مسارات سحب وتصحيح من الدرجة الأولى بأحداث LabResultRetracted وLabResultCorrected وسجل تدقيق كامل في lab_result_audit_logs.

الأحداث المبثوثة — نقطة استهلاك النتائج لأي موديول قادم

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

التكامل المحاسبي

قاعدة ثابتة: LIS يحتفظ بدفتر مساعد خاص به ويرحّل قيوداً ملخّصة فقط عبر موديول المحاسبة — لا يكتب في دفتر الأستاذ مباشرة. الترحيل في Modules\LIS\Actions\PostLabInvoice عبر Modules\Accounting\Actions\CreateJournalEntry، بحسابات من الإعدادات (lis.receivable_account_id، lis.revenue_account_id، lis.tax_payable_account_id) مع تفضيل حساب مدينين خاص بالشريك عبر AccBpExt، وقيد تكلفة مبيعات منفصل، واحتساب عمولات الأطباء تلقائياً عند الترحيل، وترحيل بنود B2B بنداً-ببند فور إصدار كل نتيجة (مستمع PostInvoiceItemOnResultRelease — idempotent).

الصلاحيات ونطاق الفروع

أعمدة الجاهزية للمستشفى — مضافة فعلاً وخاملة عمداً

• lab_requests.encounter_id (هجرة 2026_06_10_160000): عمود خامل لربط طلب المعمل بزيارة/إقامة المستشفى المستقبلية؛ التعليق الموثق نصاً: «جدول encounters الخاص بـ HIS غير موجود بعد — المفتاح الأجنبي والمستهلكون يصلون عند انطلاق HIS». تحققنا أنه غير موجود في $fillable ولا يُقرأ في أي مكان بالكود.
• lab_doctors.employee_id (هجرة 2026_06_10_150000): سلسلة هوية «طبيب ← موظف HRM ← مستخدم» (مرحلة W1-2)، بمفتاح أجنبي محروس بوجود جدول employees.
• الخلاصة: توجد خطة تنفيذية مُسمّاة HMS Phase-0 (خطوات W1-1 إلى W1-4) شُحنت بالفعل داخل LIS لتجهيزه كمزوّد خدمات معملية لأي طبقة سريرية فوقه.

عقد التكامل المستقبلي: كيف يطلب HIS/OBGY تحليلاً ويستلم نتيجته

1. إنشاء الطلب باستدعاء CreateLabRequest بمصدر in_patient مع تعبئة encounter_id — فيحصل تلقائياً على التسعير والفوترة والتأمين وختم الفرع.
2. توحيد هوية المريض مؤقتاً عبر lab_patients.partner_id (BusinessPartner) إلى حين حسم قرار سجل المرضى المركزي (استنتاج)، وهوية الطبيب عبر employee_id.
3. استلام النتائج بالاشتراك في LabResultReleased وLabRequestCompleted وLabResultCorrected/LabResultRetracted للتعديلات.
4. اعتماد نفس «وصفة الموديول الإكلينيكي الجيد»: جداول ببادئة موحدة، Enums لكل آلة حالات، أحداث ومستمعون مرتّبون للآثار الجانبية، Actions كنقاط دخول بين الموديولات، ترحيل محاسبي عبر CreateJournalEntry فقط، وصلاحيات ونطاق فروع من Core.

أولاً: وحدة الحسابات (Accounting) — دفتر الأستاذ المركزي

الوحدة تغطي دورة محاسبية كاملة: شجرة حسابات هرمية ثنائية اللغة في جدول accounts (مستويات أب/ابن، تصنيف header/detail، تصنيف زكوي zakat_classification)، وقيود يومية في journal_entries وjournal_entry_lines بدورة حالات Draft → Approved → Posted / Cancelled، وسنوات وفترات مالية، وعملات وأسعار صرف، وسندات قبض وصرف (receipt_vouchers / payment_vouchers)، وشيكات وعُهد نقدية وتسويات بنكية وأصول ثابتة وموازنات وضرائب واستقطاع وزكاة.

• عقد التكامل الواجهة الرسمية Modules/Accounting/app/Contracts/AccountingServiceInterface.php تتيح createJournalEntry(JournalEntryDTO) وgetAccountBalance() وgetTrialBalance() لأي وحدة أخرى.
• الترحيل الآلي كل القيود البرمجية تمر عبر Modules/Accounting/app/Actions/CreateJournalEntry.php الذي يتحقق من توازن المدين/الدائن، ويرفض الحسابات الرئيسية (header)، ويحلّ الفترة المالية تلقائياً عبر JournalEntryService::resolvePeriod()، ويعالج فروق العملات.
• تتبّع المصدر حقلا source_type وsource_id في journal_entries يربطان كل قيد بمستنده الأصلي (فاتورة مختبر، مسير رواتب، فاتورة مبيعات...) — وهي الفتحة الجاهزة لقيود HIS.
• إنشاء حسابات تلقائي خدمة AutoAccountService::createChildAccount() تنشئ حسابات فرعية تحت أي كود أب تلقائياً (تُستخدم لحسابات الشركاء والموظفين).
• أحداث أحداث جاهزة للاستماع: JournalEntryPosted، JournalEntryApproved، JournalEntryCancelled، PeriodClosed، FiscalYearClosed.

الدليل العملي أن هذا النمط يعمل مع وحدة طبية: مختبر LIS يرحّل فواتيره اليوم عبر Modules/LIS/app/Actions/PostLabInvoice.php الذي ينشئ قيد إيراد بقيمة entry_type = 'lab_invoice' وقيد تكلفة 'lab_cogs' ضمن معاملة واحدة، وكذلك تفعل وحدات Sales وPurchases وPOS وHRM.

ثانياً: وحدة الموارد البشرية (HRM) — الكادر الطبي والإداري

وحدة شاملة: ملف موظف كامل في جدول employees، أقسام هرمية في departments، مسميات وظيفية، ورديات وجداول مناوبات، حضور بأجهزة بصمة، إجازات، رواتب وقروض ومكافآت نهاية خدمة، توظيف وتقييم أداء وتدريب.

• سلسلة الهوية حقل employees.user_id مفتاح أجنبي فريد إلى جدول users (في تهجير 2026_03_01_100003_create_employees_table.php) — أي مستخدم نظام يُربط بملفه الوظيفي مباشرة؛ وهذه هي السلسلة التي ستربط حساب الطبيب/الممرض في HIS بملفه الوظيفي وراتبه دون أي جداول جديدة.
• ورديات متقدمة نموذج Shift يدعم الورديات الليلية وفترات السماح وحدود التأخير وعمولات الوقت الإضافي، بل ويتضمن حقولاً تمريضية جاهزة: nursing_extra_minutes وspecial_needs_extra_minutes وpresence_check_enabled — أي أن جدولة المناوبات الطبية مدعومة فعلاً.
• حضور بالبصمة جداول attendances وbiometric_devices وbiometric_employee_mappings مع مصادر تسجيل دخول/خروج وتصحيحات.
• رواتب مرحّلة آلياً خدمة PayrollAccountingService::postPayroll() ترحّل مسير الرواتب إلى دفتر الأستاذ بقيد entry_type = 'payroll'، وتنشئ حساب ذمم فرعياً لكل موظف عبر EmployeeAccountService بصيغة كود {parent_code}-{employee_number}.

ثالثاً: وحدة المخزون (Inventory) — العمود الفقري للصيدلية والمستهلكات

محرك مخزون متعدد المخازن: جدول warehouses (هرمي، مرتبط بالفرع وبحساب محاسبي account_id)، وأرصدة لحظية في inventory_stock_balances (كمية، متوسط تكلفة، قيمة إجمالية لكل منتج/متغير/مخزن)، وسجل حركة كامل في inventory_movements، وطبقات تكلفة FIFO في inventory_cost_layers، ومستندات استلام وصرف وتحويل وجرد وتسوية.

• عقد التكامل خدمة Modules/Inventory/app/Services/StockService.php توفر increaseStock() وdecreaseStock() وgetIssueCost() وgetProductCost() مع دعم طريقتي تقييم (fifo / weighted_avg) حسب إعداد inventory.valuation_method.
• مرجعية مفتوحة كل حركة تحمل reference_type وreference_id — أي أن صرف دواء من صيدلية HIS يُسجَّل كحركة issue بمرجع وصفة طبية دون تعديل المحرك.
• سابقة طبية قائمة المختبر يستهلك المخزون فعلاً: نموذج Modules/LIS/app/Models/LabReagent.php يرتبط بـproduct_id ويقرأ متوسط التكلفة من StockBalance مباشرة لحساب تكلفة الفحص.
• تعريف الأصناف نفسه (أدوية، مستلزمات) يقع في وحدة Core (Product، ProductVariant، ProductUnit) — فالصيدلية في HIS هي «مخزن من نوع خاص» وليست نظام مخزون جديداً.

رابعاً: وحدة نفيس (NPHIES) — بوابة التأمين السعودية

تكامل FHIR كامل مع منصة نفيس: إعدادات المنشأة والشهادات في nphies_config، وسجل تدقيق لكل معاملة (طلب/استجابة JSON كاملة) في nphies_transactions، وموافقات مسبقة في nphies_preauths (مرجع الموافقة، المبلغ المعتمد، فترة الصلاحية، البنود المعتمدة).

• الأهلية NphiesEligibilityService::check() تبني حزمة eligibility-request وتعيد حالة التغطية والمنافع.
• المطالبات NphiesClaimService::submit() تبني المطالبة من بنود الفاتورة (مريض + مزود + مؤمِّن + تغطية + مطالبة) وتعيد المبلغ المغطى ومشاركة المريض، وتحدّث الفاتورة بحقول nphies_claim_status وnphies_covered_amount وnphies_copay_amount.
• بنية قابلة لإعادة الاستخدام بنّاءات FHIR منفصلة: FhirPatientBuilder وFhirServiceItemBuilder وNphiesFhirClient وNphiesPollingService للاستعلام الدوري.
• تنبيه معماري الخدمات الحالية مقترنة بنماذج المختبر تحديداً (Modules\LIS\Models\LabPatient وLabInvoice)، والتهجيرات أضافت حقول نفيس إلى جدولي lab_invoices وlab_patients — فوترة HIS التأمينية يجب أن تمر من هنا بعد تعميم مدخلات البنّاءات لتقبل «مريض المستشفى» و«فاتورة المستشفى» بدل نسخ الوحدة (استنتاج مبني على بنية الكود الحالية).

خريطة: ماذا تستهلك HIS من كل عمود؟

الخلاصة الإدارية

1. أربع وظائف مستشفوية جوهرية — الفوترة المحاسبية، الرواتب والمناوبات، مخزون الصيدلية، التأمين الصحي — موجودة اليوم في الإنتاج ومثبتة بتكاملات حقيقية مع وحدة طبية (LIS).
2. نمط التكامل المعتمد في المنصة واضح ومتكرر: الوحدة التخصصية تملك مستنداتها السريرية فقط، وتستدعي العمود المساند عبر Actions وServices وعقود رسمية — وهذا هو القالب الجاهز لـ HIS.
3. الفجوة الوحيدة الجديرة بالاستثمار هي تعميم وحدة NPHIES لتخدم مريض المستشفى كما تخدم مريض المختبر، وهي فجوة تعميم لا فجوة بناء.
4. أي تصميم لـ HIS (أو لاعتماد OBGY) يعيد بناء دفتر أستاذ أو محرك مخزون أو مسير رواتب داخله يجب رفضه معمارياً.

التنظيم العام للمشروع

يتبع المشروع في /home/moonui/public_html/moon-erp/src/app فصلاً صارماً بين الطبقات:

• core/ — خدمات الـ API (services/)، شرائح NgRx (store/)، نماذج TypeScript (models/)، الحراس (guards/auth.guard.ts)، ومعترض المصادقة (interceptors/auth.interceptor.ts) الذي يضيف ترويسة X-Authorization: Bearer.
• features/ — كل ميزة في مجلد مستقل يُحمَّل كسولاً (lazy-loaded) عبر loadComponent في app.routes.ts؛ لا توجد NgModules إطلاقاً.
• layout/ — الهيكل العام: main-layout وsidebar وtopbar.
• shared/ — لبنات إعادة الاستخدام: data-table وform-dialog وpage-header وmodule-nav ومحرّك الطباعة shared/print/ والتوجيه الهيكلي للصلاحيات can.directive.ts.

نمط تدفق البيانات موحّد في كل شاشات CRUD: Component → Action → Effect → Service → API → Reducer → Selector مع شكل حالة ثابت لكل شريحة (loading / saving / error / loaded / meta) باستخدام @ngrx/entity.

شاشات المختبر LIS — النموذج العملي الناضج

وحدة LIS تضم أكثر من 60 شاشة في features/lis/ وتعمل بثلاثة سياقات توجيه: مدمج، ومستقل عبر lis-standalone.routes.ts بتخطيط خاص LisLayoutComponent، وبوابة عامة للمرضى برابط رمزي (/p/:token) دون تسجيل دخول. أهم الشاشات التشغيلية:

درس معماري مهم: المختبر تحوّل من نموذج الكانبان إلى نموذج Worklist مدفوع من الخادم عبر core/services/lis-worklist.service.ts (عقد WorklistCard / WorklistRow مع علم تشغيل USE_SERVER_WORKLIST) — أي أن منطق ترتيب العمل انتقل للباك-إند وبقيت الواجهة عارضاً ومنفّذاً للإجراءات.

الصلاحيات والحماية

1. authGuard — يتحقق من الجلسة ويعيد تحميل الملف الشخصي من /auth/me قبل السماح بأي مسار (مع معالجة الجلسات الملغاة).
2. permissionGuard — يقرأ بادئات الصلاحيات من بيانات المسار مثل data: { permissions: ['lis.results'] } بمطابقة على حدود النقطة، مع تجاوز كامل لدور super-admin.
3. moduleGuard — يمنع الوصول لمسارات الوحدات المعطّلة من شاشة module-activation.
4. على مستوى الأزرار: التوجيه الهيكلي *appCan في shared/directives/can.directive.ts يخفي أي زر لا يملك المستخدم صلاحيته — حماية دفاعية والباك-إند يظل الحكم النهائي.

الترجمة والطباعة

• الترجمة عبر ngx-translate v17 بملفين src/assets/i18n/en.json وar.json (7,494 مفتاحاً، 85 نطاقاً علوياً) مع fallbackLang: 'en' — المفاتيح إنجليزية بنمط LIS.RESULTS.APPROVE ووحدة LIS لها نطاق LIS بـ 48 نطاقاً فرعياً. LanguageService يضبط dir=rtl على مستوى المستند تلقائياً.
• محرّك طباعة عام في shared/print/: عقد GenericPrintData (يحمل dir/lang ودالة ترجمة t)، قوالب جاهزة في print-templates.ts (GENERIC_TEMPLATES بقالب افتراضي classic)، وقالب مخصص قابل للضبط CustomTemplateConfig (ألوان/خط/إظهار الشعار) من شاشة /core/print-settings.
• محرّك تقارير مخبرية متخصص: lis-report-pdf.service.ts (1,620 سطراً، jsPDF + jspdf-autotable مع طباعة عبر iframe) وlis-html-report.service.ts (1,311 سطراً، تقارير HTML بقوالب ترويسة قابلة للضبط من lab-info)، إضافة لخدمة ملصقات الباركود lis-barcode-label.service.ts وشاشة طباعة دفعية print-queue.

ما يجب أن تلتزم به واجهة HIS/OBGY الجديدة

• مجلد ميزة جديد features/his/ (أو features/obgy/) على غرار features/lis/، بمكوّنات Standalone وإشارات signal() لحالة الواجهة وخدمات his-*.service.ts في core/services/ بنمط providedIn: 'root' ودالة listAll() للتقسيم التلقائي للصفحات.
• مساران: مدمج /core/his/* ومستقل بشاشة كاملة (مثل /clinic/* على غرار /lab/*) بتخطيط خاص يحاكي LisLayoutComponent — هذا النمط مجرَّب إنتاجياً.
• صلاحيات ببادئة his. في بيانات المسارات و*appCan على الأزرار، ونطاق ترجمة HIS جديد في ملفي i18n بمفاتيح إنجليزية أولاً.
• إعادة استخدام مباشرة: data-table (تصدير Excel/PDF وتخصيص الأعمدة)، page-header، form-dialog، محرّك الطباعة العام، ونمط الـ Worklist المدفوع من الخادم لقوائم عمل العيادات (مواعيد اليوم، الكشوفات المعلّقة، السونار).
• (استنتاج) نقطة القرار الوحيدة الجوهرية على مستوى الواجهة: نموذج المريض — الواجهة الحالية تستخدم lis-patient.model.ts الخاص بالمختبر (mrn، تأمين)، وبناء HIS يستلزم شاشة سجل مرضى موحّد تستهلكه LIS وOBGY معاً بدل تكرار شاشات المرضى في كل وحدة.

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

وثّقت الدراسة أربعة قرارات حاكمة، وأكدتها مواصفة المرحلة 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.
• قيد حاكم قيد المالك المُلزِم لكل بند: «برنامج المعامل لا يتأثر — أداءً ولا سلوكاً». صفر استعلامات مضافة على المسارات الساخنة، وكل تغيير سلوكي مقصود يُسلَّم خادماً وواجهة في نشر واحد، وبوابة قبول لكل معلم: كل السويتات خضراء + مقارنة زمن استجابة قبل/بعد على قوائم العمل والاستقبال — أي تراجع يُرجِع البند.

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

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

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

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

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

مؤجَّل صراحة إلى انطلاق 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 مع تأجيل العمق الإكلينيكي، لكن القرار نفسه غير محسوم في هذه الوثائق (استنتاج).

نظرة كمية سريعة

النسب الثلاث الأخيرة تقدير تحليلي (استنتاج) مبني على أرقام موثقة في التحليل: ~190 جدول قوائم من 312 (61%)، وخطة الترحيل 312 → ~85 جدولاً مع إسقاط ~40 جدولاً ميتاً/مشتقاً مباشرة، واستبدال ~17 جدول منصة (aw*) بنواة الـ ERP الحالية.

الفئة (أ) — أصول عامة تصلح لأي تخصص طبي نواة HIS محتملة

هذه ليست أكواداً قابلة للنقل (الكود القديم PHP 5.6 / Smarty / RedBeanPHP غير قابل للإنقاذ)، بل نماذج بيانات وتدفقات عمل مجرَّبة سريرياً لسنوات يعاد بناؤها في Laravel داخل نواة HIS:

الفئة (ب) — أصول تخصصية: قيمتها داخل وحدة «صحة المرأة» فقط

• متابعة الحمل (ANC): ثلاثة أجيال متوازية (ancsheet+ancnewvisit، mainantenental+antenalvisit، followup+followupvisit) تُدمج في Pregnancy + AntenatalVisit مع حساب EDD/GA كـ accessors، وwifeepc → PregnancyLoss، وregisteration → DeliveryRegistration، وop_4d_list → FourDScanBooking.
• أطفال الأنابيب ومراقبة الدورات (IVF/ICSI/IUI): ivfsheet + mointoringsheet (وأبناؤها العشرة) → IvfCycle + IvfCycleVisit + FollicleMeasurement (يستبدل 26 عموداً مبهماً في ovst) + جداول مراحل OocyteRetrieval/EmbryoTransfer/Cryopreservation/CycleOutcome + EndometrialPrep من eprep.
• الذكورة وتحليل السائل المنوي: semen/semen2/semeninfertility → SemenAnalysis وAndrologyInvestigation، وhormon+hormonalprofile+hormonalprofile2 → HormoneResult مرتبطة بمرجعيات LIS.
• قوالب الموجات فوق الصوتية النسائية: ultrasound/ultrasoundobst + تفاصيل لكل جنين، gynaus+gynausficils، tvs/dtvs/sis/hsg → ImagingStudy + FetalScanFinding.
• المناظير: laparoscopy/hysteroscopy + نسخ *infertility المهيكلة → EndoscopyProcedure + EndoscopyFinding، مع استبدال 24 جدول مفردات (lapar*/copy*) بقاموس EndoscopyTerm.
• ملف العقم الزوجي: infertility + infertilitysheet (64 عموداً، 17 جدولاً يشير إليه) → InfertilityFile؛ نمط «الزوج/الزوجة» (forhusband/subject) أصل شبه عام يفيد أي تخصص يتعامل مع مرافقين (استنتاج).
• المحتوى السريري للقوائم: معظم الـ 190 قائمة (بروتوكولات تنشيط، أنواع نقل الأجنة، نتائج TVS/HSG…) محتوى نسائي تخصصي يُزرع في obgy_lookups من قاعدة الإنتاج.

الفئة (ج) — للإسقاط النهائي: لا يُرحَّل ولا يُحاكى

• الإطار البرمجي بالكامل: aw framework بلا front controller (مُوزِّع ?ac= في core/controllers/imp/_imp.php — 23 سطراً)، PHP 5.6.40 (منتهي الدعم منذ 2018)، Smarty 3.1.11 (2012)، RedBeanPHP 4.3 بوضع fluid في الإنتاج، صفر اختبارات وصفر git.
• الثغرات الأمنية (تُصلح فوراً على القديم ولا تنتقل): حقن SQL واسع ومؤكَّد (patients.php, financialreport.php, visits.php, sonar.php)، واجهة موبايل بلا مصادقة مع CORS * (mobileservices.php — فحوص الصلاحية كلها مُعلَّقة)، لا CSRF إطلاقاً، نقاط AJAX عامة تقبل اسم الجدول/العمود من العميل، نسخ قاعدة البيانات كاملة داخل web root (core/db_backups — 1.6GB)، كلمات مرور وأسرار مكتوبة في الكود.
• الجداول الميتة والمكررة (~40 جدولاً): بقايا تطوير (table2/table3/tablename/testtbl1/testtbl2/patients_tmp)، رباعية الاستنساخ ssemen/sseemen/sseemmen/sseemmeen، أرشيفات (old_visits, visits_updates, patients_updates → تستبدل بـ auditing)، جداول مشتقة (icsi, lastvisit)، يتائم (operationids, anprotocol, drugdos, importtdetails, excelinfo)، ومكتبة php-jwt غير المستخدمة.
• منصة تُستبدل لا تُرحَّل: جداول aw* العشرة + programesetting + devices/floors/device_tracking/messages — تحل محلها نواة Moon ERP (مستخدمون، صلاحيات spatie، إعدادات، Sanctum).

ماذا يعني هذا لقرار «نواة HIS أم وحدة تخصصية؟»

1. الأصول العامة (الفئة أ) أنماط تصميم مجرّبة وليست نظاماً جاهزاً: النظام القديم نفسه يعاني عيباً معمارياً قاتلاً موثقاً في القسم 90 — السجلات السريرية لا تشير أبداً إلى الزيارة (patientid + تاريخ فقط)، أي أن نموذج «اللقاء/Encounter» الذي تحتاجه HIS غير موجود أصلاً في OBGY ويجب بناؤه جديداً.
2. ~48% من الجداول محتوى نسائي بحت، والكود غير قابل للنقل بالكامل؛ ما يُنقل فعلياً هو: نموذج Encounter/Queue، نمط الشيت + الوصفات + طلبات المعمل، محرك Q&A، الفحص لكل جهاز، سير العمليات، ومحرك القوائم — وكلها مصممة في مخطط القسم 95 (بند 2.6) لتكون module-agnostic تستهلكها HIS.
3. التكاملات محسومة في المخطط: المريض هو مريض الـ ERP نفسه، المعمل عبر أحداث LabOrderPlaced/LabResultReceived إلى LIS، والصرف عبر PrescriptionDispensed إلى المخزون، والفوترة عبر VisitInvoiced إلى الحسابات.
4. الخلاصة التحليلية (استنتاج): تُستخرج أصول الفئة (أ) لتؤسس نواة HIS العامة، ويُبنى OBGY كوحدة تخصصية (الفئة ب) فوق تلك النواة — لا أن يكون OBGY ذاته نواة HIS.

منهجية التصنيف ومحاذاة FHIR

أسماء القدرات مُحاذاة لموارد FHIR R4 لأن تقرير التحليل القائم في /home/amrtechogate/public_html/obgy-erp-analysis.md يستخدم النمط ذاته بالفعل: نموذج Appointment وEncounter من جدول visits، واقتراح نمذجة إنهاء العلاج (endvisitreports) كحالة على EpisodeOfCare، وأوامر المعمل كـ ServiceRequest عبر أحداث LabOrderPlaced وLabResultReceived، والوصفات بدلالة MedicationRequest عبر حدث PrescriptionDispensed، والعمليات كـ Procedure. تصنيف المصادر ثلاثي:

• ERP القدرة موجودة في وحدات Moon ERP القائمة — وفق معطيات الدراسة (المحاسبة، المخزون، HRM، LIS، NPHIES)؛ كود الـ ERP غير متاح في بيئة الفحص، فالاعتماد هنا على معطيات التكليف.
• بذرة OBGY التحليل أنتج تصميمًا مستهدفًا جاهزًا (جداول/نماذج/أحداث) يصلح أساسًا للبناء — مع قاعدة صارمة في سجل المخاطر (R12): no legacy endpoint ported؛ أي أن البذرة هي نموذج البيانات وسير العمل فقط، وليست الكود الموروث (حقن SQL مؤكد ومنتشر — القسم 00 §5.1).
• بناء جديد لا يوجد أي أصل قابل لإعادة الاستخدام؛ تصميم وتنفيذ من الصفر.

مصفوفة القدرات: القدرة × المصدر × أولوية الإصدار الأول القابل للبيع

ما تقدمه تحليلات OBGY فعليًا — وما لا تقدمه

• نص صريح في المخطط (§2.6): «Encounter, OperativeNote, SurgicalBooking, Hospital, incision_types وخدمة طابور الانتظار مصممة module-agnostic كي تستهلكها وحدة HMS» — أي أن نواة المواعيد/المقابلات/العمليات قابلة للمشاركة مع الـ HIS بحكم التصميم.
• إصلاح ربط السجلات بالمقابلة: المخاطرة R2 توثق أن السجلات الإكلينيكية الموروثة لا ترتبط بالزيارات إطلاقًا؛ التصميم الجديد يفرض encounter_id إلزاميًا — وهو الانضباط الذي يحتاجه أي مستشفى عام.
• دفتر مالي للمريض جاهز التصميم: تحويل الأكواد السحرية في visits.detectionid إلى أنواع قيود صريحة (رسم/سداد/مرتجع/قسط/رصيد باقة) مع ترحيل محاسبي بالأحداث — أساس مباشر لملف حساب المريض في الـ HIS.
• لكن لا يوجد تنويم على الإطلاق: كل مقابلة في OBGY نهارية؛ visits.view يعني منتظر/داخل وليس منوَّمًا، وجداول floors/device_tracking ميزة غير مكتملة أسقطها المخطط (§1.16) — فقدرات ADT والأسرّة والطوارئ وeMAR والتمريض الخمس بناء جديد كامل.
• ولا يوجد تأمين: النظام الموروث نقدي/فيزا فقط (detectionvalue_cash/detectionvalue_visa)؛ دورة الدافعين والمطالبات تعتمد كليًا على NPHIES في Moon ERP.
• وثلثا محتواه تخصصي بحت: نحو 9 من 19 موديولًا محللًا (متابعة حمل، نساء، عقم، حقن مجهري، ذكورة، مناظير، سجل ولادي…) محتوى نسائي لا يُعاد استخدامه في مستشفى عام (استنتاج من أغراض الموديولات الموثقة).
• وصفر إعادة استخدام للكود: قاعدة R12 الصارمة no legacy endpoint ported بسبب حقن SQL المؤكد (القسم 00 §5.1) ونقاط الكتابة العامة وواجهة الموبايل بلا مصادقة — البذور تصاميم وبيانات مُرحَّلة فقط.

قطع الإصدار الأول القابل للبيع (Sellable v1)

1. v1 (P0): MPI + المواعيد + مقابلات العيادات الخارجية والطابور + ADT + الأسرّة والأجنحة + CPOE (معمل/صيدلية/إجراءات) + التوثيق الإكلينيكي + eMAR مبسط + ملف الحساب وجسر NPHIES + إعادة استخدام LIS — لا يشتري أي مستشفى نظامًا بلا عمود تنويم، رغم أن OBGY لا يسهم فيه (استنتاج منتجي فوق الحقائق الموثقة).
2. v1.5 (P1): الطوارئ والفرز، إدارة غرف العمليات (مبذورة بقوة من OBGY)، محطة التمريض.
3. v2 (P2): الأشعة RIS/PACS، eMAR كامل مع المحاليل، خطط الرعاية.

الخلاصة المعمارية لمدخلات قرار المجلس: البذور المشتركة (Encounter، أشكال CPOE، الدفتر المالي، خدمة الطابور) موضعها الطبيعي نواة إكلينيكية مشتركة يستهلكها الـ HIS وتستهلكها وحدة Modules/Obgy التخصصية معًا — وهو الاتجاه الذي يشير إليه §2.6 من المخطط نصًا؛ أما اعتبار OBGY ذاته «نواة الـ HIS» فتعارضه حقيقة أن خمس قدرات التنويم الجوهرية ودورة التأمين غائبة عنه تمامًا.

أولاً: هوية المريض — أين يعيش سجل المرضى الرئيسي (MPI)؟

يوجد اليوم ثلاثة كيانات "شبيهة بالمريض" في المنظومة، بالإضافة إلى جدول مرضى النظام القديم لعيادة النساء والتوليد:

الأدلة على أن lab_patients أصبح فعلياً سجل المرضى الرئيسي وليس مجرد "مرضى مختبر":

• حوكمة B2B جاهزة: عمود المالك external_lab_id (هجرة 2026_05_23_000002) يطبّق نمط FHIR Patient.managingOrganization، مع فهرس فريد (company_id, external_lab_id, national_id) (هجرة 2026_06_03_010000).
• الهوية الوطنية للمطالبات: وحدة NPHIES نفسها أضافت national_id_type وpassport_country على lab_patients (هجرة 2026_04_02_200001) — أي أن طبقة المطالبات الوطنية تعتبره مصدر المريض الرسمي.
• جسر مالي قائم: lab_patients.partner_id يربط المريض بحسابات الذمم عبر AccBpExt.ar_account_id — وهو بالضبط ما يحاول OBGY القديم تقليده بمزامنة cURL هشّة ومتزامنة.
• قرار محسوم لا يُعاد فتحه: وثيقة hms-phase0-spec.md تنص: مرضى B2B يبقون في lab_patients (نتيجة تقييم 37/40 مقابل 19/40 للفصل)، والترقية إلى "كيان مشترك" تكون بنقل مساحة الأسماء فقط بلا إعادة تسمية للجدول، مع نطاقات مسماة internal() / forLab() يستهلك HIS أولها — وبدون أي Global Scope شامل.

الخلاصة: سجل المرضى الرئيسي المستقبلي هو lab_patients مرقّى إلى ملكية مشتركة. مرضى OBGY يُرحَّلون إليه كصفوف داخلية (external_lab_id = NULL)، وتُفصل بيانات الزوج إلى جدول تخصصي مثل his_patient_spouses (استنتاج متوافق مع توصيات التحليل نفسه)، ويُلغى ازدواج cURL نهائياً لأن الربط المالي موجود أصلاً عبر partner_id.

ثانياً: خط المواجهة — مخطط Encounter + Folio المقترح

الوضع الحالي: عمود lab_requests.encounter_id أُضيف بالفعل (هجرة 2026_06_10_160000) لكنه خامل عمداً — بلا مفتاح أجنبي ولا قارئ — في انتظار انطلاق HIS، وجداول Encounter/Folio مؤجلة رسمياً بقرار معتمد. أما OBGY فيقدّم الدرس الأهم: جدول visits عنده يخلط الحجز والطابور والمواجهة السريرية ودفتر المدفوعات في جدول واحد، بقيم سحرية في detectionid (−99 قسط، 999 سداد متبقٍ، 9999 استرداد) — وهذا بالضبط ما يجب ألا يتكرر في HIS.

عقود الربط بين الوحدات (FK/Events) — مع احترام القاعدة المعتمدة: HIS يستورد LIS والمحاسبة والموارد البشرية للأمام، وLIS لا يستورد HIS أبداً:

• HIS → LIS (استدعاء أمامي): طلب التحاليل من داخل المواجهة عبر الإجراء المستخرج Modules/LIS/app/Actions/CreateLabRequest مع تمرير encounter_id — دون أي تعديل على مسار المختبر المستقل (قيد المالك الحاكم: "LIS لا يتأثر").
• LIS → HIS (أحداث خلفية قائمة فعلاً): LabResultReleased وLabRequestCompleted وCriticalResultDetected (موجودة في Modules/LIS/app/Events/ وتُطلق من LabResultController.php:516 وLabWorkflowService.php:75) — يلتقطها HIS ليعلّق النتائج على المواجهة.
• OBGY (كوحدة تخصصية لاحقاً): صفوف visits تُرحَّل بتفكيك واضح: شقّ الحجز/الطابور → his_encounters، والصفوف المالية ذات القيم السحرية → معاملات دفع على his_folios؛ والملفات السريرية (ancsheet، gynasheet، infertilitysheet) تشير إلى encounter_id.
• أحداث مقترحة (استنتاج): EncounterOpened، FolioChargePosted، FolioClosed — تُنشأ مع وحدة Modules/HIS عند الانطلاق.

ثالثاً: مسار الفوترة — من المختبر اليوم إلى المستشفى غداً

المسار المحاسبي مثبت ويعمل في الإنتاج داخل Modules/LIS/app/Actions/PostLabInvoice.php: مدين ذمم العميل (حساب الشريك من AccBpExt.ar_account_id أو إعداد lis.receivable_account_id) / دائن الإيراد والضريبة، مع تقسيم تلقائي بين حصة المريض patient_amount وحصة التأمين insurance_amount، وقيد تكلفة منفصل موزع على مراكز التكلفة، وكل ذلك عبر إجراء محاسبي محايد للوحدات هو Modules\Accounting\Actions\CreateJournalEntry بمرجعية source_type='lab_invoice'. والسداد عبر PostLabPayment.php بنفس سلسلة حسم الحسابات. ثم تكتمل الحلقة وطنياً: حقول المطالبة على الفاتورة نفسها (nphies_claim_status، nphies_covered_amount — هجرة 2026_04_03_000001) وخدمة NphiesClaimService::submit() تسجّل في nphies_transactions.

1. فعل سريري في أي وحدة (تحليل، كشف، دواء، يوم سرير) ⇠ حدث FolioChargePosted يضيف بنداً إلى his_folio_charges.
2. إغلاق المواجهة/الخروج ⇠ حدث FolioClosed يولّد الفواتير مقسمة حسب الدافع: فاتورة حصة المريض + فاتورة حصة التأمين (نفس منطق تقسيم insurance_amount/patient_amount القائم).
3. ترحيل الفاتورة ⇠ خدمة ترحيل موحّدة في النواة (تعميم PostLabInvoice ببادئة إعدادات his.* بدل lis.*) ⇠ CreateJournalEntry بمرجعية source_type='his_invoice' + قيد تكلفة بمراكز التكلفة.
4. السداد ⇠ تعميم PostLabPayment (مدين الخزينة / دائن الذمم بنفس سلسلة الحسم).
5. المطالبة ⇠ NphiesClaimService::submit() على الفاتورة ⇠ تتبع في nphies_transactions وتحديث nphies_claim_status.

هذه "خدمة الترحيل الموحّدة" ليست فكرة جديدة: هي بالحرف أحد بنود سجل التعميم المؤجل في hms-phase0-spec.md ("unified charge-posting service")، والجزء الوحيد الخاص بالمختبر في الشيفرة الحالية هو بادئة مفاتيح الإعدادات وسلاسل الحسم — أي أن كلفة التعميم منخفضة والهيكل جاهز. كما يحل هذا المسار نهائياً محل اختراق erpSellbill بـ cURL في OBGY القديم.

ما يعنيه هذا لقرار مجلس الإدارة

• العمود الفقري (مريض/مواجهة/فوترة) يجب أن يُبنى داخل Modules/HIS فوق أصول قائمة: lab_patients كسجل رئيسي، وencounter_id الخامل المزروع مسبقاً، ومسار PostLabInvoice → CreateJournalEntry → NPHIES المثبت.
• نموذج بيانات OBGY (زوجان في صف واحد، خلط المواجهة بالمدفوعات، قيم سحرية، صفر مفاتيح أجنبية) صالح كمصدر متطلبات وبيانات تاريخية تُرحَّل — لا كنواة معمارية لـ HIS.
• المكان الطبيعي لـ OBGY: حزمة تخصصية لصحة المرأة تستند بمفاتيح أجنبية إلى his_encounters وhis_folios، وتساهم بملفاتها السريرية الغنية (متابعة الحمل، أمراض النساء، علاج العقم، الحقن المجهري) كتوثيق للمواجهة.

الباقات الأربع — نفس المنصة، مفاتيح مختلفة

كل باقة هي توليفة موديولات تُفعَّل بالترخيص، لا منتجاً منفصل الكود. القاعدة المعمارية المعتمدة في دراسة الجدوى (القرار 2): ‏HIS يستورد من LIS/Accounting/HRM، وLIS لا يستورد HIS أبداً — وبذلك يبقى المعمل قابلاً للبيع منفرداً كما هو اليوم.

كيف تخدم منصة واحدة الباقات الأربع

• هوية مريض واحدة: القرار 1 المعتمد يرقّي lab_patients (بربطه القائم فعلاً بشريك الأعمال partner_id وحساباته التلقائية) إلى الكيان المشترك — فالمريض الذي يدخل من المعمل أو العيادة أو قسم النساء أو التنويم سجلٌّ واحد بذمة مالية واحدة.
• قضبان مالية واحدة: القيود والخزائن والورديات والتأمين وNPHIES (درجتها 9/10 في بطاقة الجاهزية) تخدم الباقات كلها بلا تكرار؛ فاتورة المعمل تدخل فوليو المستشفى بالمرجع لا بإعادة الترحيل (القرار 4).
• عقد تنفيذ خدمة واحد: ‏CreateLabRequest + عمود encounter_id هو القالب: الاستقبال أو شيت الحمل أو جناح التنويم يطلب، والمعمل/الأشعة ينفّذ ويرجع بالأحداث القائمة LabResultReleased / LabRequestCompleted. مخطط OBGY يستهلك نفس العقد عبر LabOrderPlaced → obgy_lis_test_map (276 تحليلاً من كتالوج invests القديم تُمَطّ على كتالوج LIS).
• واجهة واحدة: نمط «تطبيق داخل تطبيق» مجرّب ثلاث مرات (POS/HR/Lab) — كل باقة تضيف تطبيقات لنفس الصدفة الواحدة.
• شرط ترخيصي يجب سداده أولاً: مفتاح system.enabled_modules تحترمه الواجهة فقط (moduleGuard في auth.guard.ts) بينما الخادم لا يفرضه — بيع باقات متمايزة الأسعار يستلزم الفرض على مستوى API، وهو بند قائم في حزمة التأسيس (بوضع المراقبة أولاً لأن إعدادات شركات قائمة قديمة).

التمايز التنافسي في سوقي مصر والسعودية

• جاهزية NPHIES فعلية لا وعداً: أهلية وموافقات ومطالبات FHIR تعمل اليوم في LIS الإنتاجي — تعميمها على بنود HIS بند مخطط، بينما أغلب المنافسين المحليين يبنونها من الصفر (استنتاج تنافسي؛ جاهزيتنا نحن موثقة بالكود).
• قواميس إكلينيكية عربية-أولاً من OBGY: ~190 جدول مفردات إكلينيكية في النظام القديم (تشخيصات، شكاوى، بروتوكولات IVF، مفردات موجات TVS/HSG) تتوحد في obgy_lookups بعمودَي title_ar / title_en — حصيلة سنوات استخدام سريري حقيقي بالعربية، وهي أصعب ما يُشترى جاهزاً في السوق (استنتاج).
• عمق IVF/حقن مجهري كامل: دورة IvfCycle بمراحلها (سحب بويضات، نقل أجنة، تجميد، تحضير بطانة) وشبكة الحويصلات — عمق تخصصي نادر في أنظمة HIS العامة (استنتاج).
• مالية بمستوى ERP داخل النظام الطبي: قيود محاسبية لحظية لكل بند، مريض=شريك أعمال بحسابات أستاذ — نقطة الضعف التقليدية في أنظمة العيادات المنافسة (استنتاج) ونقطة قوتنا الموثقة (9/10).
• شبكة معامل B2B قائمة: بورتال المعامل المرجعية يعمل اليوم بعملاء أحياء — قناة بيع متقاطعة طبيعية لباقتي العيادات والمستشفى.
• درس أمني يسوَّق بحذر: النظام القديم OBGY غير قابل للبيع بحالته (PHP 5.6 منتهي الدعم، حقن SQL مؤكد، ‏API موبايل مفتوح بلا مصادقة في mobileservices.php) — قيمة الأصل في نموذج البيانات والمفردات، والهجرة إلى المنصة هي نفسها عرض البيع لعملاء الأنظمة القديمة المماثلة.

انعكاس التغليف على القرار المعماري: نواة HIS + إضافات تخصصية

التغليف أعلاه غير قابل للتحقيق إلا إذا كانت التخصصات قابلة للفصل ترخيصياً: مستشفى عام لا يدفع ثمن شيتات الحقن المجهري، ومركز IVF لا يدفع ثمن ADT والأسرّة. لو صار OBGY هو نواة HIS لانهار هذا الفصل — كل عميل يحمل 85 جدولاً تخصصياً لا يحتاجها. القسمة الصحيحة:

تسلسل الطرح — أي شريحة تموّل أي مرحلة

1. الآن: إيراد باقة «معمل فقط» القائم يموّل حزمة التأسيس (~7–10 أيام-مطوّر: ‏CreateLabRequest، تحصين B2B، فرض المفاتيح بوضع المراقبة) — وهي شرط الترخيص قبل أي بيع باقات.
2. الربعان التاليان: بناء نواة HIS مرحلة 1 (عيادات خارجية) وإطلاق باقة «عيادات» — التمويل من المعامل + أول عملاء العيادات.
3. بالتوازي ثم تتويجاً: عيادة OBGY القديمة نفسها هي العميل المرجعي الأول لباقة «صحة المرأة» — لديها دافع اضطراري للهجرة (دين أمني موثق: حقن SQL، ‏API مفتوح، نسخ قاعدة بيانات داخل web root) وبياناتها هي ذاتها اختبار الـ ETL ‏(مراحل P0–P7 وسجل مخاطر R1–R12 جاهزة في المخطط). خدمات الهجرة نفسها بند إيراد (استنتاج).
4. بعد إثبات باقتي 2 و3: إيرادهما يموّل مرحلة HIS ‏2 (التنويم والفندقة — أغلى بناء جديد) فتكتمل باقة «مستشفى عام»، وتُضاف امتدادات المرحلة 3 حسب طلب السوق بنداً بنداً.

الخلاصة للإدارة: نبيع منصة واحدة بأربع بوابات دخول؛ المعمل يموّل اليوم، والعيادات توسّع غداً، وصحة المرأة تميّزنا عن كل منافس عام، والمستشفى يأتي حين تكون النواة قد دفعت ثمن نفسها. ومعمارياً: ‏OBGY يتفكك — عمومياته (مواعيد/زيارة/روشتة) ترفد نواة Modules/HIS، وتخصصه يبقى إضافة Modules/Obgy مرخّصة على حدة.

نهاية التقرير — أُعدّ آلياً بواسطة Claude Code عبر 16 وكيل تحليل وتحكيم متوازٍ

المصدر: كود Moon ERP الفعلي + تحليل OBGY الكامل + تقارير HMS المعتمدة — الملحق الفني: his-integration-vision.md