أصعب سؤال تكاملي في البرنامج كله: كيف تتشارك وحدات ERP و LIS و HIS و OBGY هويةَ المريض الواحدة، وخطَّ المواجهة السريرية (Encounter)، ومسارَ الفوترة من الخدمة إلى القيد المحاسبي إلى مطالبة NPHIES؟ هذا القسم يحسم مكان سجل المرضى الرئيسي (MPI)، ويقترح مخطط Encounter/Folio الذي تستند إليه كل الوحدات السريرية، ويعمّم مسار الترحيل المحاسبي المثبت فعلياً في المختبر — وكل ما يلي موثّق من ملفات الشيفرة الحقيقية.
يوجد اليوم ثلاثة كيانات "شبيهة بالمريض" في المنظومة، بالإضافة إلى جدول مرضى النظام القديم لعيادة النساء والتوليد:
| الكيان | الموقع | طبيعته | أبرز الأعمدة |
|---|---|---|---|
lab_patients إنتاج فعلي | Modules/LIS/database/migrations/2026_03_01_000006 | سجل أشخاص سريري حي (~11,769 مريضاً داخلياً + 15 B2B) | mrn فريد، national_id، partner_id → business_partners، external_lab_id، insurance_info |
business_partners | Modules/Core/.../2026_02_16_200001 | كيان تجاري (عميل/مورّد) بلا أي حقول سريرية | is_customer، credit_limit، tax_number، payment_terms_days |
| عميل CRM | Modules/CRM/.../2026_03_31_100001 | امتداد لشريك الأعمال فقط (crm_customer_ext) — ليس سجل أشخاص مستقلاً | customer_type |
patients في OBGY نظام قديم | obgy/core/controllers/patients.php (تحليل القسم 01) | صف واحد = الزوجان معاً؛ بلا أي مفاتيح أجنبية معلنة في القاعدة كلها | statusno يولَّد بـ MAX+1، أعمدة الزوج مدمجة (husdandname بخطأ إملائي)، مزامنة cURL إلى client.obygyPatientId |
الأدلة على أن lab_patients أصبح فعلياً سجل المرضى الرئيسي وليس مجرد "مرضى مختبر":
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.
lab_patientspatient_id في 52 ملف LISالوضع الحالي: عمود lab_requests.encounter_id أُضيف بالفعل (هجرة 2026_06_10_160000) لكنه خامل عمداً — بلا مفتاح أجنبي ولا قارئ — في انتظار انطلاق HIS، وجداول Encounter/Folio مؤجلة رسمياً بقرار معتمد. أما OBGY فيقدّم الدرس الأهم: جدول visits عنده يخلط الحجز والطابور والمواجهة السريرية ودفتر المدفوعات في جدول واحد، بقيم سحرية في detectionid (−99 قسط، 999 سداد متبقٍ، 9999 استرداد) — وهذا بالضبط ما يجب ألا يتكرر في HIS.
| الجدول المقترح | الدور | أهم الأعمدة (مقترح يتبع أعراف LIS القائمة) |
|---|---|---|
his_encounters | المرساة السريرية لكل زيارة/إقامة (مطابق لمفهوم FHIR Encounter) | encounter_number فريد، patient_id → lab_patients، type (عيادات/تنويم/طوارئ)، status، attending_doctor_id → lab_doctors (المرتبط بالموارد البشرية عبر employee_id)، queue_position (يستبدل ثلاثية OBGY visitorder/enterordered/view)، parent_encounter_id |
his_folios | حساب المريض المالي لكل مواجهة/إقامة — وعاء الرسوم قبل الفوترة | folio_number، encounter_id، payer_type (نقدي/تأمين/حساب B2B)، insurance_contract_id، total_charges/balance بدقة decimal(12,3) كما في lab_invoices |
his_folio_charges | كل وحدة سريرية ترحّل بنود خدماتها هنا (نقطة الالتقاء الموحدة) | source_type/source_id (مرجع متعدد الأشكال: فحص مختبر، خدمة نساء وتوليد، صرف دواء، يوم سرير)، service_code (نمط sbscs_code القائم على lab_investigations)، cost_center_id، فهرس فريد (source_type, source_id) يضمن أن الفعل السريري يُفوتر مرة واحدة فقط |
عقود الربط بين الوحدات (FK/Events) — مع احترام القاعدة المعتمدة: HIS يستورد LIS والمحاسبة والموارد البشرية للأمام، وLIS لا يستورد HIS أبداً:
Modules/LIS/app/Actions/CreateLabRequest مع تمرير encounter_id — دون أي تعديل على مسار المختبر المستقل (قيد المالك الحاكم: "LIS لا يتأثر").LabResultReleased وLabRequestCompleted وCriticalResultDetected (موجودة في Modules/LIS/app/Events/ وتُطلق من LabResultController.php:516 وLabWorkflowService.php:75) — يلتقطها HIS ليعلّق النتائج على المواجهة.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.
FolioChargePosted يضيف بنداً إلى his_folio_charges.FolioClosed يولّد الفواتير مقسمة حسب الدافع: فاتورة حصة المريض + فاتورة حصة التأمين (نفس منطق تقسيم insurance_amount/patient_amount القائم).PostLabInvoice ببادئة إعدادات his.* بدل lis.*) ⇠ CreateJournalEntry بمرجعية source_type='his_invoice' + قيد تكلفة بمراكز التكلفة.PostLabPayment (مدين الخزينة / دائن الذمم بنفس سلسلة الحسم).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 المثبت.his_encounters وhis_folios، وتساهم بملفاتها السريرية الغنية (متابعة الحمل، أمراض النساء، علاج العقم، الحقن المجهري) كتوثيق للمواجهة.