موديول المعامل هو الموديول الإكلينيكي الوحيد العامل فعلياً في الإنتاج داخل Moon ERP، وهو بذلك «القالب المُثبَت» الذي يجب أن يُبنى عليه أي موديول إكلينيكي قادم (HIS أو عيادات النساء والتوليد). هذا القسم يوثّق بنيته الفعلية كما قُرئت من الكود في Modules/LIS: خريطة الكيانات، دورة حياة الطلب، الأحداث التي يبثّها، التكامل المحاسبي، نمط الصلاحيات، ونطاق الفروع — بالإضافة إلى أعمدة «الجاهزية للمستشفى» التي أُضيفت بالفعل ولم تُستهلك بعد.
جميع الجداول تحمل البادئة 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_*.lab_external_labs وتسعيرها وإحالاتها، وفوترة شهرية، ومناديب نقل العينات عبر الجدول المحوري lab_external_lab_couriers (هجرة 2026_06_09_150000_add_b2b_courier_pickup_foundation.php: العينة تولد at_external_lab ثم in_transit ثم collected).lab_histopath_templates.Modules\LIS\Actions\CreateLabRequest — وهو مستخرج نصياً من الكنترولر خصيصاً «لكي يستطيع HIS إنشاء طلبات معمل عبر نفس المسار» (تعليق موثق في الكود: HMS Phase-0 W1-3). شاشة الاستقبال تُنشئ الفاتورة وتحصّل الدفع في نفس الخطوة، وسلسلة تسعير واضحة: سعر صريح ← تسعير معمل خارجي ← قائمة أسعار الطبيب ← السعر الافتراضي.LabSampleCollected، والاستلام يبث LabSampleReceived الذي يولّد صفوف النتائج المعلّقة، ويفتح معالجة الأقسام، ويُنشئ إحالات خارجية تلقائياً للفحوصات المُسنَدة للخارج.MachineResultMatchingService وقواعد تحقق تلقائي.LabResultEntered (يستهلك الكواشف ويحدّث حالة الطلب) وCriticalResultDetected للقيم الحرجة (إنذار فوري).lis.results.validate / approve / release) مع صلاحية استثنائية محروسة release_unpaid.LabResultReleased يشغّل سلسلة مستمعين مرتّبة عمداً في EventServiceProvider: تجميع الباقات والمعادلات ← النشر التلقائي للبوابة ← ترحيل بند الفاتورة B2B محاسبياً ← قلب الطلب إلى completed وبث LabRequestCompleted.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).
| الآلية | التنفيذ الفعلي | الجاهزية لإعادة الاستخدام في HIS/OBGY |
|---|---|---|
صلاحيات بنمط lis.{resource}.{action} | Middleware على مستوى الكنترولر، مثال موثق في LabRequestController | نمط قابل للنسخ مباشرة كـ his.* / obgy.* |
| خريطة اعتماديات الصلاحيات | LisPermissionDependencies: 36 حافة صريحة + قاعدة عامة (أي فعل يستلزم view)، تُوسَّع كإغلاق متعدٍّ عند حفظ الدور | سُجّلت في سجل مركزي Modules\Core\Support\PermissionDependencyRegistry (مرحلة HMS Phase-0 W1-4) — نقطة امتداد جاهزة لأي موديول |
| نطاق رؤية البيانات بالفرع | own / branch / all حسب دور المستخدم، مع فلترة X-Branch-Id وختم فرع التشغيل على كل سجل جديد | المنطق رُفع بالفعل من LIS إلى Modules\Core\Support\DataScope (مرحلة W1-1) وLisDataScope أصبح غلافاً متوافقاً فقط |
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 لتجهيزه كمزوّد خدمات معملية لأي طبقة سريرية فوقه.CreateLabRequest بمصدر in_patient مع تعبئة encounter_id — فيحصل تلقائياً على التسعير والفوترة والتأمين وختم الفرع.lab_patients.partner_id (BusinessPartner) إلى حين حسم قرار سجل المرضى المركزي (استنتاج)، وهوية الطبيب عبر employee_id.LabResultReleased وLabRequestCompleted وLabResultCorrected/LabResultRetracted للتعديلات.CreateJournalEntry فقط، وصلاحيات ونطاق فروع من Core.