أولاً: وحدة الحسابات (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) يعيد بناء دفتر أستاذ أو محرك مخزون أو مسير رواتب داخله يجب رفضه معمارياً.