🏨

نطاق الـ HIS المستهدف لأي مستشفى (Target HIS Scope (Any Hospital))

يحدد هذا القسم النطاق المرجعي الكامل لنظام معلومات المستشفيات (HIS) الذي تستهدف الشركة بيعه لأي مستشفى عام — وليس فقط مراكز النساء والخصوبة — ثم يصنّف كل قدرة وظيفية حسب مصدر بنائها: هل تغطيها وحدات Moon ERP القائمة (المحاسبة، المخزون، الموارد البشرية، LIS، NPHIES)؟ أم تمنحنا تحليلات نظام OBGY الموروث بذرة تصميمية جاهزة؟ أم أنها بناء جديد بالكامل؟ مع محاذاة كل قدرة لموارد FHIR القياسية التي تعتمدها تقاريرنا الحالية.

14قدرة وظيفية مرجعية

4تغطيها Moon ERP

7تبذرها تحليلات OBGY

5بناء جديد بالكامل (العمود الداخلي للتنويم)

منهجية التصنيف ومحاذاة 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).
بناء جديد لا يوجد أي أصل قابل لإعادة الاستخدام؛ تصميم وتنفيذ من الصفر.

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

#	القدرة	محاذاة FHIR	موجودة في Moon ERP	تبذرها تحليلات OBGY	بناء جديد	أولوية v1
1	الفهرس الرئيسي للمرضى (MPI)	`Patient`	جزئيًا — سجل المريض/العميل في الـ ERP؛ والمخطط ينص: المريض الموروث «يصبح» مريض الـ ERP (§1.1)	نعم — متطلبات إزالة التكرار موثقة (المخاطرة R10: أرقام ملفات `MAX+1` وهويات وطنية مكررة) ونمط `obgy_patient_profiles`	سير عمل دمج/مراجعة التكرارات، وإصدار رقم ملف `MRN` لكل منشأة	P0 حرجة
2	المواعيد والجدولة	`Appointment`, `Schedule`, `Slot`	لا	قوية — `visits` (شق الحجز)، فترات بسعة قصوى `visit_periods.max_no`، قائمة انتظار `urgent=1`، حجز موبايل، `vacations` → `ClinicClosure`	جدولة متعددة الموارد (طبيب + غرفة + جهاز)	P0 حرجة
3	العيادات الخارجية وطابور الاستقبال (OPD)	`Encounter` (ambulatory), `EpisodeOfCare`	لا	قوية — نموذج `Encounter` من شق الطابور في `visits` + `followupcard` (§1.2)؛ آليات الطابور `visitorder`/`enterordered`/`view`، توجيه الشيتات عبر `lastvisit`، شاشة الانتظار `screen_slider` مع خدمة طابور (§1.6)	تهيئة عيادات متعددة التخصصات ونموذج أقسام عام	P0 حرجة
4	الدخول والخروج والتحويل (ADT)	`Encounter` (inpatient), `EpisodeOfCare`, `Location`	لا	ضعيفة جدًا — دليل مستشفيات `hospitalnames` وخطابات تحويل طباعية فقط (`instruction.php::printtransfer`)؛ جداول `floors`/`devices`/`device_tracking` ميزة غير مكتملة قرر المخطط إسقاطها (§1.16)	نعم — دورة التنويم كاملة: أمر دخول، تحويل، ملخص خروج، آلة حالات `EpisodeOfCare`	P0 حرجة
5	إدارة الأسرّة والأجنحة	`Location` (جناح/غرفة/سرير)	لا	لا	نعم — شجرة مواقع، حالات السرير (مشغول/محجوز/تنظيف)، لوحة إشغال	P0 حرجة
6	الطوارئ (ER)	`Encounter` (emergency) + فرز كـ `Observation`	لا	ضعيفة — علم الأولوية `urgent=1` ليس نظام فرز (استنتاج)	نعم — مقاييس فرز، لوحة تتبع طوارئ، قرار المصير	P1 عالية
7	أوامر الطبيب الموحدة (CPOE)	`ServiceRequest`, `MedicationRequest`	جانب تنفيذ المعمل عبر `LIS`	قوية الشكل — توحيد 8 جداول `invest` في `visit_investigations`/`lab_order_items` و10 جداول `drugs` في `visit_prescriptions`/`prescription_items` بعلاقات متعددة الأشكال، وأحداث `LabOrderPlaced`/`PrescriptionDispensed`	محور أوامر موحّد (`ServiceRequest` واحد)، أوامر أشعة، حزم أوامر، دورة حالة الأمر	P0 حرجة
8	التوثيق الإكلينيكي (ملاحظات/نماذج)	`Condition`, `Observation`, `QuestionnaireResponse`	لا	قوية — `ClinicalExamination` (علامات حيوية)، محرك أسئلة وأجوبة قابل للتهيئة `presenthistoryquestions`/`presenthistoryanswers`، `ClinicalNote` بأنواع، تشخيصات عبر pivot `encounter_diagnoses`	باني نماذج عام لأي تخصص، ترميز `ICD-10`، اعتماد وتعديل الملاحظات	P0 حرجة
9	سجل إعطاء الدواء وصيدلية التنويم (eMAR)	`MedicationRequest`, `MedicationAdministration`	المخزون وكتالوج الأصناف في الـ ERP؛ المخطط §1.14: الكتالوج والرصيد يُفوَّضان لـ `ERP inventory item master`	جزئيًا — سلسلة الصرف الخارجي (`recepittmp`/`receiptdrugs` → حدث `PrescriptionDispensed`) وأدوية أثناء العمليات (`operativedetailsdrugs`)	نعم — طبقة الإعطاء: جرعات مجدولة، توثيق تمريضي للإعطاء، مخزون الجناح	P0 حرجة (نسخة مبسطة في v1)
10	إدارة غرف العمليات (OR)	`Procedure`, `ServiceRequest`	لا	قوية — `SurgicalBooking` من `op_wait_list`، `OperativeNote` من `operativedetails` مع pivot `operative_note_staff`، تخدير متدرج `anasthesa`→`generalanasthesa`، `incision_types`، نتائج باثولوجي `pathology`؛ والمخطط §2.6 ينص أنها مصممة `module-agnostic` لاستهلاك وحدة HMS لها	لوحة جدولة غرف العمليات، قائمة فحص ما قبل الجراحة، الإفاقة (PACU)	P1 عالية
11	محطة التمريض	`Observation`, `Task`, `CarePlan`	لا	ضعيفة — حقول العلامات الحيوية في `examination` وخدمة الطابور (استنتاج لإعادة الاستخدام)	نعم — تقييمات تمريضية، خطط رعاية، مهام ومناوبات، ميزان سوائل	P1 عالية
12	الفوترة وملف الحساب + دورة التأمين	`Account`, `ChargeItem`, `Claim`, `Coverage`	نعم (العمود الفقري) — المحاسبة + `NPHIES` للتأمين السعودي	جسر قوي — `PatientLedgerEntry` من `totalbalance` والأكواد السحرية `detectionid` (-99/999/9999)، أحداث `VisitInvoiced`/`PaymentReceived`/`RefundIssued` (§2.4)، كتالوج خدمات من `detections`	ملف حساب التنويم (تجميع الرسوم من CPOE/eMAR/OR)، تسعير الباقات، الموافقات المسبقة لكل Encounter	P0 حرجة
13	أوامر المعمل → `LIS`	`ServiceRequest`, `DiagnosticReport`	نعم — وحدة `LIS` ناضجة وتعمل إنتاجيًا	نعم — طبقة ربط الكتالوج `obgy_lis_test_map` (§2.2)؛ `investcats` 22 تصنيفًا و`invests` 276 فحصًا	طفيف — الـ HIS يستهلك العقد نفسه	P0 (إعادة استخدام)
14	الأشعة (RIS/PACS)	`ImagingStudy`, `DiagnosticReport`	لا	جزئيًا — تصميم رأس موحد `ImagingStudy` (توحيد `ultrasound*`/`tvs`/`hsg`/`mrict`/`sonar`) مع `MediaAttachment`	نعم — قائمة عمل الأجهزة، تكامل `DICOM/PACS`، طابور تقارير أخصائي الأشعة	P2 متوسطة (تقارير فقط في v1)

ما تقدمه تحليلات 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)

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

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