السيناريو 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) تظل تُباع وتعمل مستقلة تماماً كما اليوم — وهي التي تموّل المراحل الأولى من خارطة الطريق.