التحليل الشامل لنظام إدارة عيادات النساء والتوليد
وخطة دمجه كموديول في منظومة Moon ERP

ما هو النظام؟

نظام متكامل لإدارة مراكز وعيادات أمراض النساء والتوليد والعقم، يعمل منذ ما يقارب عام 2015، ويغطي رحلة المريضة كاملة: التسجيل والحجز والطابور، ثم الشيتات الإكلينيكية المتخصصة (متابعة الحمل ANC، أمراض النساء، العقم وتأخر الإنجاب، الحقن المجهري IVF/ICSI/IUI مع شيت متابعة التنشيط، تحاليل الزوج والسائل المنوي)، مروراً بالموجات الصوتية والأشعة والمناظير والعمليات والولادات، وانتهاءً بالروشتات والتحاليل والماليات. ويُلحق به ثلاثة تطبيقات مساندة: صيدلية بمخزون وفواتير شراء وبيع، وبورد تعليمي لمناقشة الحالات بين الأطباء، وشاشة انتظار لعرض الطابور.

أهم الاستنتاجات

• قيمة إكلينيكية عالية جداً: النظام يحتوي معرفة طبية متخصصة متراكمة (بروتوكولات التنشيط، قياسات الأجنة، مفردات التشخيص المزروعة في ~190 جدول ترميز) تمثل أهم أصل يجب الحفاظ عليه عند النقل — وهي موثقة بالكامل في هذا التقرير.
• بنية تقنية منتهية العمر: framework مخصص ("aw framework") بدون Composer أو اختبارات أو إدارة إصدارات، مع قاعدة بيانات بلا أي مفاتيح أجنبية (Foreign Keys) — كل العلاقات ضمنية عبر تسمية الأعمدة، وقد استخرجها التحليل وأثبتها من كود الكنترولرات.
• نمط تصميم متكرر قابل للتوحيد: النظام يكرر نمط "شيت + جداول أدوية + جداول تحاليل" عشر مرات (10 جداول روشتات و8 جداول طلبات تحاليل متطابقة البنية) — يمكن دمجها في جدولين موحّدين فقط في الـ ERP.
• ديون تقنية وأمنية جوهرية: ثغرات حقن SQL في نقاط كتابة عامة، غياب CSRF، ملفات مرضى (3.2 جيجا) ونسخ قاعدة البيانات كاملة داخل مجلد الويب العام، وكلمات مرور بتشفير ضعيف — التفاصيل في قسم المعمارية، وكلها تُحل تلقائياً بالنقل إلى الـ ERP.
• جداول ميتة ومكررة: نحو 40 جدولاً مهجوراً أو مكرراً (منها 4 نسخ متطابقة لجدول السائل المنوي بأخطاء إملائية) حُدّدت بالاسم ولن تُنقل.
• تكامل قائم بالفعل مع الـ ERP: النظام يزامن المرضى والفواتير حالياً مع الـ ERP عبر cURL — عند الدمج يصبح هذا التكامل داخلياً مباشراً ويُلغى الازدواج.

التوصية

بناء موديول Modules/Obgy داخل Moon ERP (بنية Laravel Modules + واجهة Angular) بإجمالي ~85 جدولاً منظّماً بدلاً من 312، مع إعادة استخدام مكونات الـ ERP القائمة: ملف المريض الموحد، موديول المعامل LIS للتحاليل، المخزون للصيدلية، والحسابات للماليات. خطة التنفيذ المرحلية الكاملة وخريطة نقل كل جدول قديم إلى الموديل الجديد في قسم خطة النقل إلى ERP، وخريطة العلاقات الكاملة في قسم ERD.

كيف تقرأ هذا التقرير؟

1. القائمة الجانبية تنقلك لأي موديول مباشرة — كل قسم مستقل وقابل للقراءة منفرداً.
2. كل موديول يعرض: الغرض، الوظائف، جدولاً يوثّق كل جداول قاعدة البيانات التابعة له بحقولها وعلاقاتها، سير العمل الفعلي كما استُخرج من الكود، ثم توصيات النقل.
3. الملحق الفني obgy-erp-analysis.md (مرفق مع التقرير) يحتوي النسخة التقنية الكاملة بالإنجليزية — بنية كل جدول بكل أعمدته وقيم جداول الترميز المزروعة — وهو مُعدّ ليُغذّى مباشرة إلى Claude Code عند بدء تنفيذ الموديول.

تحديث (11 يونيو): اكتشاف النسخة الثانية

بعد إصدار هذا التقرير اكتُشفت نسخة ثانية عاملة من البرنامج لدى مستشفى Green Nature (السعودية) تبيّن أنها نسخة أحدث متشعبة (Fork) وليست مجرد إعدادات مختلفة: ~70 كنترولر إضافي و178 جدولاً جديداً تغطي الإقامة الداخلية وغرف العمليات ومعمل الأجنة والتجميد وقسم الأشعة وعيادة الذكورة وتعدد الفروع. التحليل الكامل في ملحق النسخة الثانية آخر التقرير، وتعديلات خطة النقل المترتبة عليه في قسم تعديلات الخطة.

نظرة عامة على البنية

• المعمارية: تطبيق PHP تقليدي (Server-Side Rendering) بنمط شبيه بـ MVC لكن دون فصل حقيقي — كل شاشة عبارة عن ملف كنترولر مستقل يُستدعى مباشرة من المتصفح مثل /obgy/core/controllers/patients.php?ac=search.
• لا توجد نقطة دخول موحدة (Front Controller) ولا نظام Routing — ملف .htaccess الرئيسي يضبط فقط DirectoryIndex وصفحات الأخطاء ويمنع تصفح المجلدات (Options -Indexes)، بينما RewriteEngine off.
• المكونات المشتركة في _library/: مكتبة قاعدة البيانات (RedBeanPHP)، نظام تسجيل الدخول (login_system)، مكتبة JWT (غير مستخدمة فعليًا)، قوالب Smarty، وإضافات (Breadcrumbs، رفع ملفات، PHPMailer).
• الإعدادات في _public/aw_config.php (نموذج عام) مع نسخة مكررة داخل كل تطبيق فرعي (core/public/aw_config.php وما يقابلها) — جميعها تحمل نفس بيانات اتصال قاعدة البيانات مكتوبة نصًا صريحًا.
• ملفات المرضى وصور/فيديوهات السونار تُخزن على نظام الملفات في مجلد upload/ (نحو 3.2 جيجابايت، منها 3.1 جيجابايت سونار) داخل مجلد الويب العام.
• تكاملات خارجية: مزامنة العملاء والفواتير مع نظام ERP منفصل عبر cURL، وواجهة API خارجية للرسائل القصيرة على http://api.gt4it.com (بدون تشفير HTTPS).

مكونات النظام الأربعة

• التطبيقات الأربعة تتشارك قاعدة بيانات واحدة (amrtechogate_obgy) ونفس جداول المستخدمين والصلاحيات (awusers/awrole...) ونفس المكتبات.
• كل تطبيق فرعي يكرر نفس بنية المجلدات (controllers / views / public / temp) ونفس ملف الإعدادات بنفس كلمة مرور قاعدة البيانات — أي تغيير في الإعدادات يجب تكراره يدويًا في 4-5 مواضع.

الـ Framework المخصص (aw framework) وطريقة عمله

• التوجيه (Routing): الملف core/controllers/imp/_imp.php (23 سطرًا) هو "الموجّه" بالكامل: يقرأ ?ac= من الرابط، ينشئ كائنًا من كلاس Controllers، ويستدعي الدالة المطابقة لاسم ac إن وُجدت وإلا index(). لا يوجد تحقق من نوع الطلب (GET/POST) ولا قائمة سماح بالأكشنات — أي دالة public في الكلاس قابلة للاستدعاء من الرابط مباشرة.
• نمط الكنترولر: كل ملف من الـ81 ملفًا يعرّف كلاسًا بنفس الاسم Controllers (تعارض تسمية مقصود لأن كل ملف يعمل منفصلًا). الـ constructor يكرر في كل ملف نفس الكود التمهيدي (~60 سطرًا): تحميل الإعدادات والاتصال بقاعدة البيانات وتهيئة Smarty وBreadcrumbs وتضمين كلاسات _header/_sidebar/_leftsidebar/_footer.
• ربط العرض (Views): قوالب Smarty 3.1.11 في مجلد views/؛ كل أكشن يعرض الصفحة على أجزاء متتالية: header::headershow() ثم sidebar::sidebarshow() ثم القالب الخاص بالشاشة ($smarty->display('xxx.html')) ثم القائمة اليسرى والفوتر. تمرير البيانات عبر $smarty->assign().
• نموذج الصلاحيات (RBAC): نظام صلاحيات دقيق مبني على جداول: awcontroll (الشاشات) وawcontrollprop (الأكشنات داخل كل شاشة) وawrole (الأدوار) وawrolecontrollprop (صلاحية كل دور على كل أكشن) إضافة إلى awmenu/awrolemenu (القوائم لكل دور) وawrolebtn (أزرار الواجهة). الدالة autho::checkauthoize() تتحقق عند كل أكشن من صلاحية دور المستخدم الحالي ($_SESSION['role_id']) وتعيد التوجيه لصفحة خطأ عند الرفض.
• القائمة الديناميكية: القائمة الجانبية تُبنى من جدول awmenu هرميًا حسب دور المستخدم وإعداد "النموذج المبسط/الكامل" في programesetting.
• نقطة ضعف جوهرية: تفعيل التحقق من الصلاحيات يعتمد على انضباط المطور — في عدة أكشنات نجد سطور التحقق معلّقة (commented out)، وأبرزها كنترولر خدمات الموبايل بالكامل.

طبقة البيانات

المصادقة وواجهات الـ API

• تسجيل الدخول: مبني على مكتبة php-login مفتوحة المصدر (_library/login_system/classes/Login.php) تستخدم PDO باستعلامات مُعاملة (Prepared Statements) وجلسات PHP و"تذكرني" بكوكي، مع عدّاد محاولات فاشلة (user_failed_logins) للحد من التخمين.
• تخزين كلمات المرور: ممتاز نسبيًا — password_hash() بخوارزمية bcrypt بتكلفة 10 (مؤكد من عمود user_password_hash بصيغة $2y$10$... في جدول awusers)، وكذلك كلمات مرور المرضى للموبايل.
• API الموبايل: core/controllers/mobileservices.php (671 سطرًا) يوفر تسجيل/تحديث بيانات المرضى وإرجاع JSON — لكن كل فحوصات الدخول والصلاحيات فيه معلّقة، ومفتوح للجميع مع Access-Control-Allow-Origin: *.
• JWT: مكتبة php-jwt-master موجودة في _library لكن لا يوجد أي استدعاء لها في كود التطبيقات — تبعية ميتة، أي لا توجد مصادقة Token حقيقية للـ API.
• إعدادات API خارجية: _public/api_config.php يضع مفاتيح api_key/api_user/api_password كمتغيرات بيئة بقيم مكتوبة نصًا في الملف، ويفعّل display_errors = on — ولا يوجد ملف داخل النظام يستدعيه (يُرجح استخدامه من خدمات خارجية مثل SMS/التحاليل).
• تكامل ERP: استدعاءات cURL مباشرة من الكنترولرات إلى /ERP/controllers/clientControllerAjax.php لمزامنة العملاء والفواتير دون أي توقيع أو مفتاح مصادقة ظاهر.

الأمان — نقاط القوة

• تشفير كلمات المرور بـ bcrypt عبر password_hash/password_verify مع إعادة تجزئة تلقائية عند الحاجة.
• نظام صلاحيات RBAC دقيق على مستوى الأكشن الواحد (جداول awcontroll/awrole*) مطبق في معظم شاشات النظام الداخلية.
• استخدام filter_input() لقراءة المدخلات، واستعلامات مُعاملة في مكتبة الدخول وفي جزء كبير من استدعاءات ORM.
• display_errors = off في الإعدادات الرئيسية، ومنع تصفح المجلدات في .htaccess، وحد لمحاولات الدخول الفاشلة.
• نسخ احتياطي يومي تلقائي لقاعدة البيانات مع إمكانية إرساله بالبريد.

الأمان — نقاط الضعف (بصراحة مهنية)

الديون التقنية (Tech Debt)

الخلاصة الإدارية

• النظام مكتمل وظيفيًا وغني إكلينيكيًا، ونموذج الصلاحيات فيه جيد التصميم، لكن أساسه التقني (PHP 5.6 + إطار مخصص بلا صيانة + تكرار كود واسع) وصل لنهاية عمره الافتراضي.
• الثغرات الحرجة (حقن SQL في شاشات البحث والتقارير، وAPI الموبايل المفتوح، والنسخ الاحتياطية داخل مجلد الويب) تمس بيانات طبية حساسة وتستوجب معالجة عاجلة حتى مع المضي في خطة الترحيل.
• الترحيل إلى Laravel + Angular مبرر تقنيًا بقوة: يعالج جذريًا مشاكل الأمان (Eloquent/حماية CSRF/مصادقة API)، وإدارة التبعيات، وتكرار الكود، ويتيح فصل الواجهات وخدمات الموبايل عبر API موحد — مع التنبيه إلى أن أصعب جزء في الترحيل سيكون نقل 312 جدولًا بترميز مزدوج وملفات 3.2 جيجابايت دون فقد بيانات.

الوظائف الرئيسية

• تسجيل مريضة جديدة بنظام "المسودة": يُنشأ سجل فارغ بحالة done=0 لكل مستخدم ويُستكمل تدريجيًا ثم يُعتمد عبر addfinish بحالة done=1.
• توليد رقم ملف تلقائي statusno (أكبر رقم موجود + 1) مع إمكانية الإدخال اليدوي حسب إعداد programesetting.patientnoaut.
• قراءة الرقم القومي المصري (14 رقمًا) بتعبير نمطي واستخراج تاريخ الميلاد منه وحساب العمر تلقائيًا (سنة/شهر/يوم) للزوجة والزوج.
• تسجيل بيانات الزوجة الكاملة: الاسم، اللقب، الميلاد، التعليم، الوظيفة، الحالة الاجتماعية، فصيلة الدم، الرقم القومي، العنوان، الهاتف، مدة الزواج، عدد الأبناء (ذكور/إناث)، ملاحظات الخطورة risk/risktype.
• تسجيل بيانات الزوج في نفس السجل: الاسم، اللقب، الميلاد، التعليم، الوظيفة، فصيلة الدم، الرقم القومي، العادات husband_habbits وملاحظاته.
• تسجيل الزيجات السابقة للزوجة والزوج (جداول previous_marriage وhus_previous_marriage).
• فحص التكرار لحظيًا عبر AJAX: اسم الزوجة، رقم الملف، الرقم القومي للزوجة والزوج، رقم الهاتف.
• إنشاء زيارة استقبال (كشف) مع التسجيل مباشرة: نوع الكشف، قيمة نقدي/فيزا، خصم، دور الانتظار — تُكتب في جدول visits داخل نفس المعاملة.
• بحث متعدد المعايير (اسم/رقم ملف، اسم الزوج، وظيفة الزوج أو الزوجة، العنوان، الهاتف، المحمول، العمر، الرقم القومي) وبحث بالقسم في وضع المستشفى عبر visits.detectionid، مع توجيه المستخدم لآخر شاشة إكلينيكية من جدول lastvisit.
• إدارة كاملة (إضافة/تعديل/حذف) لقوائم الترميز: ألقاب الزوجة والزوج، التعليم، الوظائف، الحالة الاجتماعية، فصائل الدم — كلها من شاشة المريض نفسها عبر AJAX.
• شريط بيانات المريضة الموحد _patientdata.php الذي يظهر أعلى كل شاشة إكلينيكية: البيانات الديموغرافية + الصيغة التوليدية (P / CS / AB / Ectopic / VM / SVD) محسوبة من جدول phobstetric مضافًا إليها أعمدة الرصيد الافتتاحي في patients، وملخص التاريخ المرضي والجراحي والنسائي والعائلي.
• السجل الطبي السريع (record.php): صفوف تشخيص/علاج بالتاريخ مع روشتات للزوجة أو الزوج من كتالوج الأدوية وطباعتها.
• إدارة ملفات المريضة: رفع متعدد إلى مجلد upload/patientfiles/{id} وعرض وتحميل الملفات (قراءة من نظام الملفات مباشرة).
• إنهاء فترة المتابعة وتسجيل تقارير إنهاء الزيارات (endvisitreports).
• كلمة مرور للمريضة patient_password_hash (مشفرة بـ password_hash) لاستخدامها في خدمات الموبايل.
• مزامنة المريضة كعميل في نظام ERP خارجي (إضافة/تحديث/حذف وفاتورة كشف) عبر cURL إلى clientControllerAjax.php، مع زر ترحيل جميع المرضى دفعة واحدة addAllPatientsToERP.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يفتح موظف الاستقبال شاشة التسجيل patients.php?ac=index؛ يبحث النظام عن مسودة غير معتمدة (done=0) لنفس المستخدم فيستكملها، أو ينشئ سجلًا جديدًا فورًا في قاعدة البيانات برقم ملف تلقائي statusno.
2. عند إدخال الرقم القومي يتحقق النظام من صحته بتعبير نمطي ويستخرج منه تاريخ الميلاد ويحسب العمر تلقائيًا؛ كما تُجرى فحوص تكرار فورية (الاسم، رقم الملف، الرقم القومي، الهاتف) عبر AJAX.
3. تُحفظ الحقول حقلًا بحقل عبر AJAX (updateajax) أثناء الإدخال، وتُملأ القوائم المنسدلة من جداول الترميز (الألقاب، التعليم، الوظائف، الحالة، فصائل الدم) مع إمكانية إضافة قيم جديدة لهذه القوائم من نفس الشاشة.
4. عند الضغط على "إنهاء" (addfinish) يُعتمد السجل (done=1) وتُسجَّل بيانات الزوجة والزوج كاملة وتُشفَّر كلمة مرور المريضة، وإذا طُلبت زيارة تُنشأ في جدول visits (نوع الكشف، نقدي/فيزا، خصم، ترتيب الدخول) داخل معاملة واحدة، ثم يُحوَّل المستخدم لشاشة تاريخ المريضة أو شاشة الاستقبال حسب صلاحيته.
5. تُزامَن بيانات المريضة تلقائيًا كعميل في قاعدة ERP الخارجية (إضافة أو تحديث عبر curlAddClient/curlUpdateClient) إذا كانت قاعدة ERP معرّفة في الإعدادات.
6. البحث عن مريضة قائمة من شاشة البحث متعدد المعايير؛ النتائج محدودة بـ60 سجلًا، ويوجّه الرابط لآخر شاشة إكلينيكية زارتها المريضة من جدول lastvisit، وفي وضع المستشفى يُبحث بالقسم عبر visits.detectionid مع استبعاد من انتهت متابعتهم في endvisitreports.
7. في كل شاشة إكلينيكية يُعرض شريط بيانات المريضة (_patientdata.php) الذي يفك ترميز القوائم ويحسب الأعمار ومدة الزواج والصيغة التوليدية (P/CS/AB/Ectopic/VM/SVD) من phobstetric + الأرصدة الافتتاحية، ويعرض ملخصات التاريخ الطبي والجراحي والنسائي والعائلي — وينشئ تلقائيًا سجل فحص examination فارغًا إن لم يوجد.
8. من شاشة السجل الطبي (record.php) يضيف الطبيب صفوف تشخيص/علاج بالتاريخ، ويكتب روشتات للزوجة أو الزوج من كتالوج الأدوية (recorddrugs/drugs) ويطبعها بلقب واسم المريض من جداول الألقاب.
9. تُرفع ملفات وصور المريضة إلى مجلد upload/patientfiles/{id} عبر إضافة الرفع المتعدد، وتُعرض وتُحمَّل من نظام الملفات مباشرة.
10. أثناء متابعة الحمل تُسجَّل بيانات حجز الولادة في صفوف registeration المرتبطة بشيت ancsheet (المكان، المنشأ، النوع، التكلفة) وتُقرأ لاحقًا في تقارير الولادات.
11. عند انتهاء فترة العلاج/المتابعة يُسجَّل تقرير إنهاء في endvisitreports، ويمكن حذف المريضة حذفًا منطقيًا (deleted=1) مع حذف العميل المقابل في ERP.

الارتباط بالموديولات الأخرى

• الزيارات والاستقبال (visits): visits.patientid → patients.id؛ كما يُنشئ هذا الموديول زيارة الكشف الأولى بقيمها المالية، ويستخدم lastvisit.patientid وendvisitreports.patientid.
• التاريخ المرضي (patient history): جداول phmenstrual / phcontraception / phobstetric / phpastmedical / phpastsurgical / phpastgynecological / phpastart / phfamily كلها عبر patientid وتُعرض ملخصاتها في شريط بيانات المريضة.
• الفحص الإكلينيكي (examination): examination.patientid → patients.id — يُنشأ سجل فحص تلقائيًا من _patientdata.php.
• الشيتات الإكلينيكية: ancsheet / gynasheet / infertilitysheet / ivfsheet عبر patientid، وجدول registeration.ancsheetid → ancsheet.id يربط التسجيل بمتابعة الحمل، وتقارير الولادات (Deliveries.php) تقرأ registeration + origin.
• زيارات المتابعة: قوائم الشكاوى complaint (gyna/infertility) وcomplaintant (antenatal) تُستهلك في antenalvisit.php وgyna.php وتقارير completereport.php.
• كتالوج الأدوية (drugs): روشتات السجل الطبي عبر recorddrugs.drugid → drugs.id وrecorddrugs.patientid → patients.id.
• درجات الخطورة: patients.risktype → risktype.id (كنترولر risktype.php).
• المستخدمون والأطباء: patients.userid / patients.doctorid → awusers.user_id، والأطباء هم المستخدمون ذوو role_id = 4.
• صور الجهاز التناسلي: gtimage.patientid → patients.id مع تفاصيل التعليقات في gtdetail.gtid.
• نظام ERP الخارجي: client.obygyPatientId → patients.id في قاعدة بيانات ERP منفصلة، بمزامنة عبر cURL (إضافة/تحديث/حذف عميل + فاتورة كشف).

ملاحظات فنية

• لا توجد مفاتيح أجنبية معلنة إطلاقًا؛ كل العلاقات ضمنية بأسماء الأعمدة، والفهرس الوحيد غير الأساسي على patients هو statusno — أداء البحث بـLIKE '%..%' سيتدهور مع نمو البيانات.
• ثغرات حقن SQL: استعلام البحث في patients.php?ac=search يبني الشروط بدمج نصوص مباشرة، و_patientdata.php يُمرر patientid من الـGET مباشرة في الاستعلام.
• أخطاء إملائية متجذرة في أسماء الأعمدة يجب توحيدها عند الترحيل: husdandname، wiftypeid، mirragefrom، spacialnotes، registeration، coast (المقصود cost).
• معرّفات القوائم مخزنة في أعمدة varchar (مثل wifeeducation، husbandjob، husbandbl) بينما نظيرتها للزوجة int — عدم اتساق في الأنواع، وخلط ترميزات latin1 / utf8mb4 بين الجداول أدى لتلف عرض القيم العربية المزروعة.
• ازدواجية البيانات: العمر (wifeage) وتاريخ الميلاد يُخزنان معًا، ومدة الزواج تُخزن كنص mirragefrom وكتاريخ محسوب عكسيًا mirragefromdate.
• توليد رقم الملف بـ MAX(statusno)+1 بدون قفل — احتمال تضارب أرقام عند التسجيل المتزامن.
• نمط "المسودة" ينشئ سجلات مرضى فارغة فعليًا في قاعدة البيانات قبل اكتمال الإدخال، وشريط بيانات المريضة يُنشئ سجل examination عند مجرد العرض (كتابة أثناء القراءة) — مصدر سجلات يتيمة.
• جداول ميتة: patients_tmp وlocations بلا أي استخدام، وpatientfiles موجود لكن الملفات تُدار من نظام الملفات مباشرة بمسح المجلد، وpatients_updates (سجل التدقيق) لا يكتب فيه الكود الحالي.
• جدولا complaint وcomplaintant متطابقان بنيويًا (تكرار لنفس المفهوم بسياقين).
• تكامل ERP منفّذ بفتح اتصال مباشر بقاعدة بيانات ثانية + استدعاءات cURL متزامنة داخل دورة الحفظ — نقطة فشل وأداء حرجة.
• كلمات مرور المرضى مشفرة بـ password_hash (جيد)، لكنها مخزنة داخل جدول البيانات الديموغرافية نفسه.

توصيات النقل إلى ERP

• إنشاء موديل Patient رئيسي (جدول patients) يقتصر على بيانات المريضة، وفصل بيانات الزوج في جدول/موديل Spouse (علاقة 1-1) بدلًا من 20+ عمودًا مزدوجًا في سجل واحد — مع الإبقاء على إمكانية الدمج في واجهة العرض.
• توحيد قوائم الترميز: دمج wifejobs + husbandjobs في جدول job_titles، وwifetypes + husbandtypes في person_titles، والإبقاء على education_levels، blood_types (يفضَّل Enum)، marital_statuses — كلها بمفاتيح أجنبية حقيقية وأعمدة deleted_at (SoftDeletes).
• دمج complaint + complaintant في جدول واحد complaints بعمود سياق (context: gyna | antenatal | infertility).
• إسقاط الجداول الميتة نهائيًا: patients_tmp، locations، والاستغناء عن patientfiles لصالح إدارة مرفقات حقيقية (Spatie MediaLibrary أو جدول patient_attachments مع ترحيل الملفات الموجودة على القرص).
• استبدال patients_updates بحزمة تدقيق قياسية مثل owen-it/laravel-auditing لتسجيل كل تعديلات سجل المريض تلقائيًا.
• إنشاء موديل MedicalRecord (جدول records) مرتبطًا بـ Patient وPrescription، وموديل DeliveryRegistration (جدول registeration بعد تصحيح الاسم) بمفتاحين أجنبيين إلى anc_sheets وorigins وتحويل coast إلى cost decimal.
• تنقية البيانات عند الترحيل: تحويل الأعمدة النصية الحاملة لمعرّفات إلى foreignId، توحيد التواريخ (إلغاء 0000-00-00 لصالح NULL)، حذف عمود العمر المخزن والاكتفاء بـ Accessor محسوب من تاريخ الميلاد، وتحويل أعمدة الصيغة التوليدية الافتتاحية (pno/ab/ectopic/vmodel/svd/cs) إلى أعداد صحيحة في جدول obstetric_baselines.
• توليد رقم الملف عبر تسلسل آمن (قيد فريد + معاملة) بدل MAX+1، وجعل الرقم القومي فريدًا مع خدمة تحقق مستقلة لاستخراج تاريخ الميلاد.
• نقل حساب الزوجة/المريضة (كلمة المرور) إلى جدول مستخدمين منفصل أو Guard مستقل في Laravel بدل تخزينها في جدول الديموغرافيا.
• استبدال مزامنة cURL المتزامنة مع ERP بأحداث (Events) و Jobs في طوابير Laravel، أو إلغاؤها كليًا بما أن الوجهة هي نفس منظومة ERP المستهدفة (يصبح المريض هو العميل مباشرة عبر patient_id).
• بناء البحث على فهارس حقيقية (full-text أو Laravel Scout) بدلًا من LIKE على أعمدة غير مفهرسة، مع واجهة Angular بنفس معايير البحث الحالية للحفاظ على عادات المستخدمين.

الوظائف الرئيسية

• حجز زيارة جديدة من شاشة الاستقبال مع اختيار نوع الكشف (detections) وتحديد القيمة نقدًا/فيزا والخصم والمتبقي كدين على المريضة.
• حجز الزيارات من تطبيق الموبايل عبر mobileservices.php مع حد أقصى مُثبّت بالكود (10 زيارات تطبيق يوميًا) ومنع تكرار حجز نفس المريضة في نفس اليوم.
• إدارة فترات الزيارة اليومية (visit_periods) باسم الفترة وتوقيتها وحد أقصى لعدد المرضى لكل فترة، مع التحقق من السعة قبل الحجز (patPerPeriod).
• طابور الانتظار اليومي في الشاشة الرئيسية: وضع "مستشفى" يفصل المنتظرين (view=0) عن الداخلين (view=1)، ووضع "عيادة" يعرض زيارات اليوم مرتبة بترتيب الطابور والوقت التقريبي، مع إعادة ترتيب الطابور بالسحب (sortable).
• عرض زيارات أمس مع زيارات اليوم خلال ساعات العمل الممتدة بعد منتصف الليل (إعداد addshours في programesetting).
• قائمة انتظار للحالات العاجلة المستقبلية (urgent=1) مع إمكانية ترحيلها إلى اليوم أو إلغائها.
• المعاملات المالية داخل جدول الزيارات نفسه: سداد متبقٍ (detectionid=999)، مرتجع عملاء (detectionid=9999)، دفع قسط من رصيد المريضة (detectionid=-99) المرتبط بجدول totalbalance.
• مزامنة فورية مع نظام ERP خارجي عبر cURL: إنشاء/تعديل/حذف فاتورة بيع لكل زيارة مدفوعة، وتسجيل أنواع الكشف كمنتجات خدمية.
• توجيه الطبيب تلقائيًا من الطابور إلى آخر شيت إكلينيكي فتحه للمريضة (متابعة حمل، نساء، عقم، حقن صناعي) عبر جدول lastvisit.
• تسجيل زيارات المتابعة داخل شيت العقم (newvisit) بتاريخ آخر دورة ووزن الجسم وحالة الرحم والمبايض والعلاج.
• إنهاء فترة العلاج بتقرير نهاية زيارات (endvisitreports) بالسبب والتاريخ والطبيب، مع إمكانية الإغلاق الجماعي لقسم كامل.
• بحث في الزيارات باسم الزوجة أو الزوج أو فترة زمنية، وبحث سريع برقم ملف المريضة (statusno).

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يبحث موظف الاستقبال عن المريضة برقم الملف (statusno) أو بالاسم (بحث تلقائي بالإكمال)، ثم يفتح شاشة إضافة زيارة (visits.php?ac=index).
2. يختار نوع الكشف من قاموس detections (الذي يحمل السعر)، ويحدد التاريخ والفترة الزمنية والقيمة المدفوعة نقدًا/فيزا والخصم والمتبقي والملاحظات والوقت التقريبي، ثم تُحفظ الزيارة بـ payedflag=1 ويُحتسب ترتيب الدخول enterordered تلقائيًا.
3. عند تفعيل نظام الفترات (programesetting.visit_period=1) يتحقق النظام من عدد المحجوزين في الفترة مقابل max_no قبل الحجز.
4. بديلًا، تحجز المريضة من تطبيق الموبايل (mobileservices.php?ac=addVisit) فتُسجَّل الزيارة بـ mobileappvisit=1 وpayedflag=0، وعند الحضور والدفع يستدعي الاستقبال payvisit فيتحول العلم إلى مدفوع وتُنشأ فاتورة بيع في الـ ERP الخارجي.
5. كل زيارة مدفوعة تُرسل فورًا عبر cURL إلى نظام ERP خارجي (sellbillController.php?do=addObgyVisit) لإنشاء فاتورة بيع مرتبطة بالزيارة، ويُحدَّث/يُحذف معها عند تعديل أو حذف الزيارة.
6. تظهر زيارات اليوم في الشاشة الرئيسية (index.php) كطابور انتظار؛ في وضع المستشفى ينقسم الطابور إلى منتظرين وداخلين، ويضغط المستخدم "دخول" فتُعلَّم الزيارة view=1 وتنتقل لقائمة الداخلين، مع إمكانية إعادة الترتيب بالسحب.
7. من الطابور ينتقل الطبيب إلى الشيت الإكلينيكي؛ ويستخدم النظام جدول lastvisit لمعرفة آخر شيت فُتح للمريضة (متابعة حمل/نساء/عقم/حقن مجهري) فيوجهها مباشرة، ويُحدَّث هذا السجل تلقائيًا عند فتح أي شيت.
8. داخل شيت العقم يضيف الطبيب صفوف زيارات متابعة (newvisit) عبر حفظ خلوي فوري بالأجاكس، مع اختيار نوع السيكل من قاموس newvisitcycles.
9. المعاملات المالية اللاحقة تُسجَّل كصفوف جديدة في visits مرتبطة بالزيارة الأصلية عبر visitid: سداد متبقٍ (detectionid=999) أو مرتجع (detectionid=9999) بعد التحقق من أن المرتجع لا يتجاوز المدفوع، أو دفع قسط (detectionid=-99) يخصم من رصيد totalbalance.
10. عند انتهاء خطة العلاج يُنشأ تقرير إنهاء (endvisitreports) بالسبب والتاريخ واسم الطبيب من شاشة المريضة، أو إغلاق جماعي لكل مرضى قسم معين عبر emptydeptvisit.
11. الزيارات المستقبلية العاجلة (urgent=1) تظهر في قائمة الانتظار (waitingList) ليُقرَّر ترحيلها إلى اليوم أو إلغاؤها.

الارتباط بالموديولات الأخرى

• موديول المرضى: visits.patientid وlastvisit.patientid وendvisitreports.patientid → patients.id، والبحث برقم الملف patients.statusno.
• قاموس أنواع الكشف/الخدمات: visits.detectionid → detections.id (الاسم والسعر detectionval)، وتُدار شاشات إضافته من نفس كنترولر الزيارات.
• الشيتات الإكلينيكية: newvisit.infertilitysheetid → infertilitysheet.id، وقيمة lastvisit.control تشير إلى كنترولرات الشيتات (antenalvisit، ancsheet، gynasheet، iui، infertilitysheet).
• قاموس السيكلات المشترك: newvisit.newvisitcycles وnewvisitg.newvisitcycles (شيت النساء) → newvisitcycles.id.
• المستخدمون والصلاحيات: visits.user_id وendvisitreports.doctorid → awusers.user_id، وأزرار التعديل/الحذف محكومة بجدول awrolebtn.
• الحسابات: أقساط detectionid=-99 تُخصم من جدول totalbalance عبر patientid.
• الإعدادات: programesetting يتحكم في وضع العرض (visitsform مستشفى/عيادة)، وتفعيل الفترات (visit_period)، والساعات الإضافية (addshours)، واسم قاعدة الـ ERP (erpdb).
• نظام ERP خارجي (قاعدة بيانات منفصلة): sellbill.obygyVisitId → visits.id، وproduct.obygyDetectionId → detections.id، وclient.obygyPatientId → patients.id عبر استدعاءات cURL.
• تطبيق الموبايل: حجز وتعديل وحذف الزيارات عبر mobileservices.php مع العلم mobileappvisit.

ملاحظات فنية

• جدول visits يخلط بين مفهومين: الموعد/الزيارة والمعاملة المالية (إيصال)، باستخدام قيم سحرية في detectionid (‏-99 قسط، 999 سداد متبقٍ، 9999 مرتجع) وربط ذاتي عبر visitid — منطق مُثبّت بالكود يصعب صيانته.
• لا توجد مفاتيح أجنبية معلنة إطلاقًا؛ جميع العلاقات ضمنية عبر أسماء الأعمدة واستعلامات JOIN.
• جدولا visits_updates وvacations غير مستخدمين في أي كنترولر أو واجهة تم فحصها (موجودان في المخطط فقط) — على الأرجح بقايا تطوير غير مكتمل (استنتاج).
• old_visits جدول ترحيل قديم، وسكربت fixOldVisits() الخاص بترحيله ما زال موجودًا في كود الإنتاج ويمكن استدعاؤه من المتصفح.
• ثغرات حقن SQL واضحة: دوال البحث (search, getnames, emptydeptvisit) تبني الاستعلامات بدمج نصي مباشر لمدخلات المستخدم.
• دوال أجاكس عامة (updateAjax, addNewRow, editselect) تستقبل اسم الجدول والعمود من العميل مباشرة — مخاطرة أمنية وبنيوية كبيرة.
• حقول newvisit كلها نصوص varchar(191) حتى التواريخ والأوزان؛ ولا توجد بيانات مزروعة لقواميس visit_periods وnewvisitcycles في النسخة الاحتياطية.
• حد حجوزات الموبايل (10 يوميًا) وقيم كثيرة أخرى مُثبّتة بالكود وليست إعدادات.
• الحذف منطقي بأعلام غير موحدة (deleted في الزيارات مقابل del في القواميس)، مع وجود حذف فعلي في دالة delv.
• تكرار في حقول الترتيب (visitorder, visit_order, enterordered) داخل نفس الجدول.

توصيات النقل إلى ERP

• فصل جدول visits إلى ثلاثة نماذج Laravel: Appointment (الحجز: المريضة، الخدمة، التاريخ، الفترة، الحالة، المصدر، عاجل)، وEncounter (الدخول الفعلي وترتيب الطابور)، وPaymentTransaction (نوع المعاملة كـ enum: كشف/سداد متبقٍ/مرتجع/قسط بدلًا من القيم السحرية، مع appointment_id بدل الربط الذاتي visitid).
• إنشاء نموذج VisitPeriod (أو AppointmentSlot) من جدول visit_periods مع قيد سعة max_no يُفحص بمعاملة قاعدة بيانات، وربطه بنموذج ClinicClosure المبني على جدول vacations لمنع الحجز في الإجازات.
• استبدال جدول lastvisit بمنطق اشتقاقي (آخر شيت إكلينيكي بحسب تاريخ الإنشاء) أو عمود last_sheet_type على المريضة — لا حاجة لجدول مستقل.
• نقل newvisit وnewvisitcycles إلى موديول العقم الإكلينيكي كنموذجي InfertilityFollowUp وCycleType، مع تحويل الحقول النصية إلى أنواع صحيحة (تاريخ، رقم عشري) وتوحيد القاموس المشترك مع شيت النساء.
• تحويل endvisitreports إلى نموذج TreatmentClosure مرتبط بالمريضة والطبيب، أو دمجه كحالة (status) على مفهوم "حلقة علاجية" (Episode of Care) إن اعتُمد.
• إسقاط جدولي old_visits وvisits_updates بعد أرشفة بياناتهما، والاستعاضة عن التدقيق بحزمة Laravel Auditing أو جدول activity_log موحد.
• اعتماد مفاتيح أجنبية حقيقية وقيود NOT NULL، وتوحيد الحذف المنطقي عبر SoftDeletes، ونقل الإعدادات المثبتة بالكود (حد الموبايل، الساعات الإضافية) إلى جدول إعدادات.
• استبدال تكامل cURL مع الـ ERP بمعاملات داخلية مباشرة (الفوترة جزء من نفس النظام الجديد) أو بطبقة Events/Jobs غير متزامنة مع ضمان عدم فقد الفواتير.
• بناء واجهات Angular: شاشة حجز بتقويم وفترات وسعات، وشاشة طابور لحظية (WebSockets/Polling) بدل إعادة تحميل القوائم، ونقطة نهاية REST موثقة لتطبيق الموبايل بدل mobileservices.php المفتوح بلا تحقق من الهوية.

الوظائف الرئيسية

• إنشاء ملف حمل تلقائيًا للمريضة عند فتح شاشة المتابعة (ancsheet بحالة endpreg=0 أو mainantenental بحالة done=0) بحيث يوجد حمل نشط واحد فقط لكل مريضة.
• حساب ميعاد الولادة المتوقع تلقائيًا بقاعدة نيجيلي (LMP + 9 أشهر + 7 أيام) في الاتجاهين: إدخال LMP يحسب EDD والعكس، مع حساب تاريخ مرجعي للحقن المجهري (ivf = LMP + 9 أشهر − 7 أيام).
• حساب عمر الحمل تلقائيًا (أسابيع + أيام) لكل زيارة متابعة وكل أشعة بناءً على فرق التاريخ عن LMP.
• تسجيل زيارات المتابعة: التاريخ، وزن الأم، ضغط الدم، النبض، الشكوى، التشخيص (قوائم متعددة من diagnosisant وcomplaintant)، الملاحظات والخطة العلاجية.
• تسجيل نتائج الموجات فوق الصوتية للحمل (mainantenentalus): GA، GS، CRL، FHR، BPD، FL، موضع المشيمة، السائل الأمنيوسي، الوزن المتوقع للجنين.
• متابعة فحوصات الأشعة المرحلية في ملف ANC: فحص T-scan (الثلث الأول) وفحص TT-scan (مسح التشوهات) بتاريخ وأسبوع ونتيجة وتقرير لكل منهما.
• الحجز التلقائي في قائمة انتظار أشعة 4D (op_4d_list) بمجرد إدخال EDD، وتحديث حالتها (t11/t21) عند تسجيل تواريخ T-scan وTT-scan.
• كتابة روشتات أدوية لكل زيارة بتاريخ معين (للزوجة أو الزوج) مع طباعتها، من كتالوج الأدوية المركزي.
• طلب تحاليل واستقصاءات من كتالوج التحاليل المصنف (investcats/invests) مع تسجيل النتائج وطباعة الطلبات.
• تسجيل تاريخ فقدان الحمل السابق EPC (إجهاض مبكر EPL، إجهاض الثلث الأول/الثاني، حمل عنقودي كامل/جزئي، حمل خارج الرحم) مع طريقة العلاج (تحفظي/دوائي/جراحي) والطبيب المعالج ونتيجة الباثولوجي.
• إنهاء الحمل وأرشفته مع أخذ لقطة من بيانات G/P/EPC وقت الإنهاء، وتصفح أرشيف الأحمال السابقة لكل مريضة.
• حساب عدد مرات الحمل (Gravida) تلقائيًا من سجل الولادات والإجهاضات السابقة (phobstetric + عدادات جدول المرضى).
• تقارير: الولادات المتوقعة اليوم أو في فترة (edd وexpected)، حالات EPC بالتاريخ (epc)، المرضى حسب نوع الخطورة (risktype)، والحالات حسب نوع إنهاء الحمل (termination).
• إضافة قيم جديدة لقوائم الاختيار (المشيمة، أنواع EPC، أطباء الولادة...) ديناميكيًا من داخل الشاشة دون شاشة إعدادات منفصلة.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. عند فتح شاشة ANC للمريضة (ancsheet.php?ac=index) يبحث النظام عن ملف حمل نشط (endpreg=0)؛ إن لم يوجد يُنشأ تلقائيًا، ويُنشأ كذلك ملف infertilitysheet إن لم يوجد، ويُسجل الدخول في lastvisit.
2. يُدخل الطبيب تاريخ آخر دورة LMP فيحسب النظام EDD تلقائيًا (LMP + 9 أشهر + 7 أيام) عبر دالة eedlmp()، وبمجرد وجود EDD يُضاف صف تلقائي في قائمة انتظار أشعة 4D (op_4d_list) ويُربط بالملف عبر 4d_list_id.
3. تُسجل بيانات فحص الثلث الأول (T-scan) ومسح التشوهات (TT-scan)؛ إدخال التاريخ يُحدّث حالة الحجز في op_4d_list (الأعمدة t11/t21).
4. في كل حضور يضيف الطبيب "New Visit" فيُنشأ صف ancnewvisit بتاريخ اليوم ويحسب عمر الحمل بالأسابيع والأيام من LMP تلقائيًا، ثم تُملأ الحقول (وزن، ضغط، ملاحظات، خطة، بيانات أشعة) بحفظ فوري حقلًا بحقل عبر AJAX.
5. من نفس الشاشة تُكتب روشتة اليوم (ancsheetdrugs) من كتالوج الأدوية، للزوجة أو الزوج، مع إمكانية الطباعة وعرض روشتات التواريخ السابقة وتعديلها.
6. تُطلب التحاليل بتحديد بنود من كتالوج التحاليل المصنف فتُحفظ دفعة واحدة في ancsheetinvest وتُطبع، وتُسجل النتائج لاحقًا في نفس الصفوف.
7. تُعرض في الملف أيضًا بيانات التاريخ التوليدي من موديول العقم: الأطفال السابقون (awifep مع قوائم طريقة/توقيت/مكان الولادة) وحالات فقدان الحمل (wifeepc مع قوائم النوع/العلاج/الطبيب)، وتُحرر من هنا مباشرة.
8. عند انتهاء الحمل يضغط المستخدم "End Pregnancy" فيتحول endpreg=1 وتُلتقط قيم G/P/EPC من ملف العقم وتُحفظ في الملف، ويصبح الملف أرشيفًا يُستعرض من شاشة archive/historys.
9. بالتوازي، شاشة antenalvisit.php تدير نفس الحمل بجداول أخرى: تُنشئ/تحمّل mainantenental (مع حساب G تلقائيًا من phobstetric وعدادات المريضة)، وتسجل زيارات antenalvisit وأشعة mainantenentalus وأدوية وتحاليل خاصة بها، وتُنهى بـ done=1 ويُستعرض أرشيفها برقم الحمل g.
10. التقارير: edd.php يعرض من ولادتهن المتوقعة اليوم أو في مدى تاريخي من ancsheet.sheetedd، وexpected.php يعرض نفس التقرير من mainantenental.eed، وepc.php يعرض حالات فقدان الحمل بالتاريخ، وrisktype.php يصنف المرضى حسب patients.risktype، وtermination.php يعرض الحالات حسب نوع إنهاء الحمل من phobstetric.

الارتباط بالموديولات الأخرى

• موديول المرضى: كل الجداول الرئيسية ترتبط بجدول patients عبر patientid، وتقرير الخطورة يقرأ patients.risktype وpatients.risk.
• موديول المستخدمين/الأطباء: حقول doctorid في الزيارات والأدوية والتحاليل والأشعة ترتبط بـ awusers.user_id.
• كتالوج الأدوية والمخزون: ancsheetdrugs.drugid وmainantenentaldrugs.drugid يرتبطان بجدول drugs، مع ربط بالإيصالات عبر recepittmpid/recepitdrugid.
• كتالوج التحاليل: ancsheetinvest.investid وmainantenentalinvest.investid يرتبطان بـ invests (المصنفة في investcats).
• موديول العقم (Infertility): wifeepc.infertilitysheetid يرتبط بـ infertilitysheet، وقوائم wifeobst/wifemodeofd/wifetypeofd يستهلكها جدول الأطفال awifep التابع لملف العقم، وإنهاء الحمل ينسخ G/P/EPC من ملف العقم.
• موديول العمليات/أشعة 4D: ancsheet.4d_list_id يرتبط بـ op_4d_list (حجز وتتبع فحوصات 4D).
• موديول التاريخ المرضي: حساب Gravida وتقرير إنهاء الحمل يعتمدان على phobstetric وقوائم phobstericterminate/phobstericterplace.
• موديول الحجز/الاستقبال: ملف ANC يعرض حجوزات registeration المرتبطة بالملف عبر ancsheetid، ويسجل آخر شاشة زارها المريض في lastvisit.
• موديول IVF: جداول antype وantypes وpla2cen (وanprotocol المهجور) تُستخدم فعليًا من ivfsheet وليس من شاشات متابعة الحمل.

ملاحظات فنية

• ازدواجية كاملة: يوجد مساران متوازيان لمتابعة الحمل (ancsheet/ancnewvisit مقابل mainantenental/antenalvisit) بجداول أدوية وتحاليل مكررة بنفس البنية، ما يشتت بيانات الحمل الواحد بين مصدرين.
• ancsheet00.php نسخة قديمة مكررة من ancsheet.php ما زالت موجودة في الكود (Dead/Legacy code).
• أخطاء إملائية متجذرة في المخطط: mainantenental (الصحيح antenatal) وعمود الربط مكتوب mainantenatalid بإملاء مختلف عن اسم الجدول، وantenalvisit بدون حرف t.
• التواريخ مخزنة كنصوص varchar بصيغة Y/m/d في جداول أساسية (ancsheet, ancnewvisit, wifeepc) ما يجعل المقارنات والفرز عرضة للأخطاء، بينما جداول أخرى تستخدم date.
• mainantenental.patientid من نوع varchar بينما باقي الجداول تستخدم int لنفس المفتاح.
• لا توجد مفاتيح أجنبية معلنة إطلاقًا؛ كل العلاقات مستنتجة من أسماء الأعمدة وأكواد الكنترولر.
• أعلام الحذف غير موحدة: del وdeleted وconditions وendpreg/done كلها تؤدي نفس الغرض بأسماء مختلفة.
• ثغرات SQL Injection مؤكدة: risktype.php وtermination.php يلصقان مدخلات POST مباشرة في جمل SQL، ودوال getselectajax/Add تسمح للعميل بتمرير اسم الجدول والعمود (Table/Mass-assignment injection).
• جداول anprotocol وantype وantypes وpla2cen مصنفة ضمن هذا الموديول لكنها تخص IVF؛ anprotocol مهجور (الكود يستخدم icsiprotocol)، وعمود pla2cen.title معرف كـ int خطأً، وpla2cen بلا بيانات أولية.
• بيانات قوائم الاختيار ملوثة: جدول placenta يحوي صفوف NULL وقيم نصية حرة مكررة، وقوائم wifeobst/wifeepcobst تخلط أسماء أطباء وأماكن ودول في حقل واحد.
• diagnosisid وcomplaintid وwifeobst تُخزن كقوائم CSV داخل عمود نصي بدلًا من جداول وسيطة.
• قاعدة حساب EDD مثبتة في الكود (+9 أشهر +7 أيام) ومكررة في أكثر من كنترولر، وعمر الحمل يُعاد حسابه ويُحفظ في قاعدة البيانات عند كل عرض للصفحة (كتابة عند القراءة).

توصيات النقل إلى ERP

• توحيد المسارين في نموذج واحد: جدول pregnancies (موديل Pregnancy) يدمج ancsheet + mainantenental بحقول: patient_id, lmp, edd, gravida, status (active/ended), hb, placenta_site_id, مع ترحيل بيانات المسارين بمطابقة المريضة والتواريخ.
• جدول antenatal_visits (موديل AntenatalVisit) يدمج ancnewvisit + antenalvisit: pregnancy_id, visit_date, weight, bp, pulse, notes, plan، مع جداول وسيطة antenatal_visit_diagnosis وantenatal_visit_complaints بدل قوائم CSV، وحساب عمر الحمل كـ Accessor محسوب وليس عمودًا مخزنًا.
• جدول antenatal_ultrasounds (موديل AntenatalUltrasound) من mainantenentalus مع ضم حقول T-scan/TT-scan من ancsheet كأنواع فحص (scan_type: routine / first_trimester / anomaly / 4d) بدلًا من أعمدة ثابتة.
• توحيد الروشتات والتحاليل عبر النظام كله: prescriptions/prescription_items وinvestigation_requests/investigation_results بعلاقة Polymorphic أو بـ pregnancy_id، لتحل محل الجداول الأربعة المكررة (ancsheetdrugs, mainantenentaldrugs, ancsheetinvest, mainantenentalinvest).
• جدول pregnancy_losses (موديل PregnancyLoss) من wifeepc مربوط مباشرة بـ patient_id بدل المرور على ملف العقم، بحقول: loss_type_id, gestational_weeks, treatment_id, provider_id, histopathology, cost, date من نوع date.
• تحويل القوائم الصغيرة إلى Enums أو جداول مرجعية موحدة: delivery_modes (CS/SVD/NVD)، delivery_terms (full_term/preterm)، pregnancy_loss_types، pregnancy_loss_treatments، placenta_sites (بعد تنقية بيانات placenta)، ودمج wifeobst + wifeepcobst في جدول external_providers واحد بحقل نوع (طبيب/مستشفى/خارجي).
• نقل antype وantypes وpla2cen إلى موديول IVF عند ترحيله، وإسقاط anprotocol بعد التأكد من خلوه من بيانات مرتبطة (الكود يستخدم icsiprotocol).
• أثناء الترحيل: تحويل كل التواريخ النصية إلى DATE مع معالجة القيم 0000-00-00 والفارغة، توحيد الحذف الناعم على deleted_at (SoftDeletes)، وإضافة مفاتيح أجنبية وقيود فعلية، ونقل منطق EDD إلى Service واحد (EddCalculator) قابل للاختبار.
• إعادة بناء التقارير (EDD المتوقعة، EPC، الخطورة، الإنهاء) كاستعلامات Eloquent/API endpoints محمية بـ Validation وParameter binding لإغلاق ثغرات SQL Injection الحالية.

الوظائف الرئيسية

• تسجيل زيارات أمراض النساء لكل مريضة (جدول gyna) بتاريخ الزيارة، الشكوى الحرة والشكاوى المختارة من قائمة، التشخيصات المتعددة، الملاحظات، وتاريخ آخر دورة (LMP)، مع إمكانية إضافة شكوى/تشخيص جديد للقاموس أثناء العمل.
• ملاحظات وخطة علاجية عامة أعلى شاشة النساء لكل مريضة (جدول maingyna) تُنشأ تلقائياً عند أول دخول للشاشة.
• كتابة روشتات الأدوية بتاريخ اليوم للزوجة أو الزوج (gynadrugs / gynasheetdrugs) مع اختيار متسلسل (تصنيف ← اسم ← شكل ← جرعة) من كتالوج الأدوية، وعرض الروشتات السابقة وتعديلها وطباعتها مع التشخيص الأخير اختيارياً.
• طلب الفحوصات والتحاليل عبر نافذة اختيار مجمّعة حسب تصنيفات الفحوصات (gynainvestigation / gynasheetinvest) للزوجة أو الزوج، مع طباعة طلب الفحص وتسجيل النتائج لاحقاً.
• سونار النساء (gynaus): تسجيل يوم الدورة، سُمك بطانة الرحم، قياسات المبيض الأيمن والأيسر (طول/عرض/حجم/عدد الحويصلات)، قياسات الرحم وعنق الرحم، بنموذج مبسّط أو كامل حسب إعدادات البرنامج، مع طباعة التقرير.
• تفصيل الحويصلات لكل مبيض (gynausficils): قياس اسم وطول وعرض وحجم كل حويصلة على حدة، وتحديث عدد الحويصلات في سجل السونار ضمن معاملة واحدة (Transaction).
• ملف تأخر الإنجاب المختصر داخل شاشة النساء (gynainfertility): نوع العقم ومدته وفترة المعاشرة ونتائج الهرمونات (FSH/LH/TSH/PRL/AMH) والسائل المنوي وأشعة الصبغة، مع خطط علاجية متعددة (gynainfertilityplan) وأنواع عقم قابلة للإضافة (gynainfertilitytype).
• «شيت النساء» (gynasheet): صفحة ملخّص واحدة لكل مريضة تتضمن «بيانات حرجة» (importantnote) تُعرض أعلى الشيت، والتاريخ الحيضي (انتظام/كمية/عسر الطمث من قوائم menstrualreg، menstrualamount، menstrualdysm) والفحص الموضعي (الفرج/المهبل/عنق الرحم من قوائم localvulva، localvagina، localcx).
• زيارات متابعة داخل الشيت (newvisitg): التاريخ، الدورة، LMP، وزن الجسم، الرحم والمبيض، نوع الفحص بالموجات (US / TVS / 3D TVS)، الشكوى (C/O) والتشخيص من قوائم قابلة للإضافة (newvisitgco، newvisitgdiag)، وزر TTT لفتح روشتة الشيت مباشرة.
• سجل فحص نسائي ضمن موديول العقم (infertilitygyna): المهبل، الفحص، السبر (Sounding)، الملحقات (Adnexae) لكل ملف عقم.
• التحرير الموضعي (inline editing) لكل الحقول عبر AJAX يحفظ كل حقل فور تعديله (id / table / column / value)، مع حذف منطقي (soft delete) للسجلات.
• تسجيل آخر شاشة دخلتها المريضة في جدول lastvisit لتسهيل الرجوع إليها من شاشة الاستقبال.
• كنترولر ultrasoundgyna.php يوفر سير عمل أخصائي السونار: إنشاء تقرير سونار نسائي رسمي (جدول ultrasoundgyna التابع لموديول السونار)، تعبئته ثم اعتماده بالطباعة (done=1).

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يفتح الطبيب شاشة «Gyna» للمريضة (gyna.php?patientid=) فيُسجَّل الدخول في lastvisit ويُنشأ تلقائياً سجل maingyna (ملاحظات/خطة) إن لم يوجد، وتُعرض كل الزيارات السابقة مرتبة تنازلياً.
2. يضيف الطبيب زيارة جديدة (AJAX newrow) فتُنشأ صفّاً فارغاً بتاريخ اليوم في gyna، ثم يُحرَّر كل حقل (الشكوى، التشخيصات المتعددة، LMP، الملاحظات) فورياً عبر update الذي يحفظ عموداً واحداً في كل نداء.
3. تُختار الشكاوى والتشخيصات من قاموسَي complaint وdiagnosis المشتركَين وتُخزَّن كسلسلة معرّفات مفصولة بفواصل؛ ويمكن إضافة مصطلح جديد للقاموس مباشرة (adddiagnosis).
4. للروشتة: يفتح الطبيب نافذة الأدوية فتُنشأ صفوف gynadrugs بتاريخ اليوم (للزوجة forhusband=0 أو الزوج forhusband=1) ويختار الدواء بتسلسل تصنيف/اسم/شكل/جرعة، ثم يطبع الروشتة (مع التشخيص الأخير إذا فُعّل print_diag في الإعدادات).
5. للفحوصات: نافذة Checkbox مجمّعة حسب investcats تحفظ صفوف gynainvestigation وتطبع طلب الفحص؛ وتُسجَّل النتائج لاحقاً في investresult.
6. للسونار: زر إضافة يُنشئ صفّاً في gynaus (نموذج مبسّط أو كامل حسب programesetting.ultrasound)، وتفتح نافذة الحويصلات لكل مبيض لتحفظ القياسات في gynausficils وتحدّث lfolliclesno/rfolliclesno داخل معاملة واحدة، مع إمكانية طباعة تقارير سونار مختارة.
7. نافذة العقم (getInfdata): تُنشأ تلقائياً سجل gynainfertility وسطر خطة gynainfertilityplan إن لم يوجدا، وتُعبّأ بيانات النوع والمدد والهرمونات، مع إضافة أنواع جديدة إلى gynainfertilitytype.
8. شاشة «شيت النساء» (gynasheet.php): تُنشأ تلقائياً سجلا gynasheet وinfertilitysheet للمريضة؛ يدوَّن التاريخ الحيضي والفحص الموضعي عبر قوائم منسدلة تُحفظ في أعمدة infertilitysheet، وتُضاف زيارات متابعة newvisitg (إجراء append) بشكواها وتشخيصها وروشتتها (gynasheetdrugs) وفحوصاتها (gynasheetinvest).
9. القوائم المنسدلة (الحيضية والموضعية وC/O والتشخيص) قابلة للإثراء أثناء العمل: getselectajax يضيف عنواناً جديداً للجدول المرجعي، وgetdataselect/deldataselect يديران حذف القيم منطقياً.
10. gynasheet00.php نسخة قديمة بديلة تعرض الشيت مدموجاً مع زيارات gyna وسونار gynaus في صفحة واحدة (منطق مكرر).
11. في موديول العقم، عند إنشاء ملف infertility تُنشأ معه تلقائياً صفوف فحص نسائي infertilitygyna ضمن مجموعة جداول الملف، وتُحرَّر حقولها (Vagina/Exam/Sounding/Adnexae) موضعياً.
12. أخصائي السونار يستخدم ultrasoundgyna.php لإنشاء تقرير سونار نسائي رسمي مسوّدة (done=0) ثم اعتماده بالطباعة (done=1) — في جدول ultrasoundgyna التابع لموديول السونار.

الارتباط بالموديولات الأخرى

• المرضى (Patients): كل الجداول التشغيلية تقريباً ترتبط بـ patients عبر patientid، وتُقرأ أسماء الزوجة/الزوج وألقابهما (wifetypes/husbandtypes) للطباعة.
• المستخدمون/الأطباء: doctorid في gyna وgynadrugs وgynainvestigation وgynaus يشير إلى awusers.user_id، وقائمة أخصائيي السونار تُجلب بشرط positionid = 4.
• كتالوج الأدوية: gynadrugs.drugid وgynasheetdrugs.drugid يشيران إلى drugs.id مع نسخ اسم الدواء denormalized.
• كتالوج الفحوصات: gynainvestigation.investid وgynasheetinvest.investid يشيران إلى invests.id المجمّعة في investcats.
• قاموسا الشكاوى والتشخيصات المشتركان: gyna.complaintid ← complaint.id وgyna.diagnosisid ← diagnosis.id (CSV).
• موديول العقم: infertilitygyna.infertid ← infertility.id، وشاشة الشيت تنشئ وتعرض infertilitysheet الذي تُخزَّن فيه قيم قوائم الحيض والفحص الموضعي.
• موديول متابعة الحمل: gynaus.mainantenatalid يربط سونار النساء بسجل mainantenatal (استنتاج من اسم العمود).
• موديول السونار: كنترولر ultrasoundgyna.php يدير جدول ultrasoundgyna (تقرير أخصائي السونار) المرتبط بالمريضة عبر patientid.
• التاريخ المرضي الحالي: شاشة النساء تكتب في gynaph المرتبط بقاموسَي presenthistoryquestions/presenthistoryanswers.
• تتبع الزيارات: كل دخول للشاشة يُحدِّث lastvisit (patientid + اسم الكنترولر).
• الإعدادات العامة: programesetting تتحكم في شكل نموذج السونار (مبسّط/كامل) وطباعة التشخيص مع الروشتة وغيرها.

ملاحظات فنية

• لا توجد مفاتيح أجنبية (Foreign Keys) أو فهارس غير المفتاح الأساسي في أي جدول؛ كل العلاقات ضمنية في كود الكنترولرات.
• تعدد أنماط الحذف المنطقي بشكل غير متسق: conditions في gyna، وdeleted في جداول الأدوية والفحوصات والسونار، وdel في جداول القواميس.
• كود infertility.php يستعلم بشرط del = 0 على infertilitygyna بينما العمود غير موجود في تعريف الجدول بالـ dump — يضيفه RedBeanPHP في الوضع المرن وقت التشغيل (استنتاج).
• حقول متعددة القيم مخزّنة كسلاسل CSV: gyna.diagnosisid وgyna.complaintid وnewvisitg.newvisitgco وnewvisitg.newvisitgdiag وأعمدة الحيض والفحص الموضعي على infertilitysheet — يستحيل معها الاستعلام والتقارير بكفاءة.
• ازدواج كامل في الجداول: gynadrugs ≡ gynasheetdrugs وgynainvestigation ≡ gynasheetinvest (نفس البنية حرفياً لشاشتين مختلفتين)، كما تتكرر بيانات العقم بين gynainfertility وحقول gyna.inf_*.
• gynasheet00.php نسخة قديمة مكررة من منطق gyna.php + gynasheet.php معاً (Legacy duplicate).
• newvisitg.date وnewvisitg.lmp من نوع varchar وليست تواريخ، والقياسات الطبية في gynaus/gynausficils مخزّنة varchar(50).
• القوائم المرجعية (الحيض، الفحص الموضعي، C/O، التشخيص، أنواع العقم) فارغة في نسخة قاعدة البيانات؛ المفردات تُبنى من المستخدمين وقت التشغيل عبر getselectajax.
• نقاط نهاية التحديث العامة تستقبل اسم الجدول والعمود من العميل مباشرة (update/Add/append/deleterow) — مخاطرة أمنية تسمح بالكتابة في أي جدول، إضافة إلى بناء SQL بسلاسل نصية في بحث الأدوية (search).
• عمليات كتابة أثناء القراءة: دالة العرض index تدمج diagnosistxt داخل complaint وتحفظ السجل أثناء عرض الصفحة (ترحيل بيانات خفي).
• اسم الدواء يُنسخ denormalized في drugname داخل جداول الروشتات، وحقل investresult نصي حر بلا وحدات أو مدى مرجعي.

توصيات النقل إلى ERP

• إنشاء موديل GynaVisit (من جدول gyna) مع جدولي ربط Pivot: gyna_visit_complaints وgyna_visit_diagnoses بدلاً من حقول CSV، وحذف diagnosistxt بعد ترحيل محتواه (الدمج يتم أصلاً في الكود الحالي).
• توحيد روشتات الموديول في جدول واحد gyna_prescriptions + gyna_prescription_items بدمج gynadrugs وgynasheetdrugs مع عمود context (visit / sheet)، واستبدال forhusband بعمود subject (wife/husband)، وربط drug_id بمفتاح أجنبي حقيقي.
• توحيد الفحوصات في gyna_investigation_requests بدمج gynainvestigation وgynasheetinvest بنفس أسلوب الدمج، مع فصل النتيجة في جدول/أعمدة منظّمة (قيمة، وحدة، تاريخ النتيجة).
• موديل GynaUltrasound (من gynaus) مع تحويل كل القياسات إلى decimal، وموديل تابع GynaUltrasoundFollicle (من gynausficils) بعلاقة hasMany وعمود side (enum: left/right) بدل type الرقمي؛ وإلغاء عمودي العدّ lfolliclesno/rfolliclesno والاكتفاء بالعد من العلاقة.
• موديل GynaSheet + GynaSheetVisit (من newvisitg) مع تحويل date وlmp إلى نوع date فعلي، وتحويل usvsdtv إلى enum (US/TVS/3D_TVS)، وجداول Pivot للشكاوى والتشخيصات بدل CSV.
• دمج كل القواميس البسيطة (menstrualreg، menstrualamount، menstrualdysm، localcx، localvagina، localvulva، newvisitgco، newvisitgdiag، gynainfertilitytype) في جدول مرجعي موحّد lookups (type, title, is_active) أو Enums مزروعة بقيم معتمدة طبياً، لأنها جميعاً بنفس البنية (id/title/del) وفارغة في النسخة الحالية.
• توحيد ملف العقم: دمج gynainfertility وحقول gyna.inf_* في موديل واحد InfertilityProfile مرتبط بالمريضة، مع InfertilityPlan (من gynainfertilityplan)، ونقل infertilitygyna إلى ترحيل موديول العقم كموديل InfertilityGynaExam مرتبط بـ infertility_id.
• تحويل maingyna إلى حقلي notes وplan ضمن ملف المريضة النسائي (GynaProfile) بدلاً من جدول مستقل.
• اعتماد الحذف المنطقي الموحّد بـ deleted_at (SoftDeletes في Laravel) بدل conditions/deleted/del، وإضافة created_at/updated_at ومُعرّف الطبيب الموحّد doctor_id بمفاتيح أجنبية.
• إغلاق الثغرة المعمارية: استبدال نقاط النهاية العامة (table/column من العميل) بـ API Resources وFormRequests محدّدة لكل موديل مع Validation صارم وصلاحيات.
• إهمال gynasheet00.php نهائياً عند النقل (شاشة قديمة مكررة) والاكتفاء بشاشة شيت واحدة في واجهة Angular.

الوظائف الرئيسية

• إنشاء ملف عقم تلقائي لكل مريضة عند أول دخول للشاشة (سجل رئيسي + صفوف أولية للتشخيص وآخر دورة والفحص والتحاليل والملاحظات).
• توثيق تاريخ الزواج والدورة والعمليات والتاريخ الجنسي وعلامات سريرية (الثدي، الشعرانية، السمنة) في الملف السريع القديم.
• «شيت العقم» الشامل: نوع العقم (أولي/ثانوي)، مدة العقم، التاريخ المرضي والجراحي والعائلي، تفاصيل الدورة الشهرية (الانتظام، الكمية، عسر الطمث، آخر دورة)، الفحص العام والموضعي للزوجة.
• تشخيص عامل الزوج عبر ثلاث قوائم تشخيص متعددة الاختيار (husbndiagnosis1/2/3) وقوائم أسباب منسوبة للزوج والزوجة (sheethusband, sheetwife).
• تسجيل العلاجات السابقة واستجابتها: منشطات/محفزات (tttda)، ميتفورمين (tttmetformin)، نوع العلاج (ttttype)، الاستجابة (tttresponse) وعدد المحاولات ونتيجتها.
• سجل تفصيلي للحمول السابقة للزوجة (awifep): نوع المولود، تاريخ الولادة، طريقة الولادة ونوعها (مكتمل/مبتسر)، الوزن، حي/متوفى، وسيلة منع الحمل بعده ومدتها — مع حساب عمر الطفل آلياً.
• حساب الصيغة التوليدية آلياً (G/P/FT/PT/EPC/Living) من سجل الحمول السابقة والإجهاضات مع إضافة الحمل الجاري من شيت متابعة الحمل النشط.
• روشتات أدوية منفصلة للزوج والزوجة بتاريخ الزيارة مع الطباعة والتعديل وعرض السجل التاريخي (forhusband = 0/1).
• طلب تحاليل واستقصاءات من كتالوج التحاليل المصنّف، منفصلة للزوج والزوجة، مع تسجيل النتائج والطباعة.
• إضافة قيم جديدة لقوائم الاختيار السريرية أثناء العمل (إثراء المعجم السريري ديناميكياً من شاشة الطبيب).
• تسجيل زيجات سابقة للزوجة والزوج (previous_marriage, hus_previous_marriage) من ملف المريضة وعرضها في ترويسة بيانات المريضة.
• تسجيل آخر شاشة دخلتها المريضة (lastvisit) لتسهيل استئناف العمل.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. تُختار المريضة من شاشة البحث، ثم يفتح الطبيب شاشة «شيت العقم» (infertilitysheet.php?patientid=N)؛ إذا لم يوجد شيت يُنشأ سجل فارغ تلقائياً في infertilitysheet، ويُنشأ كذلك gynasheet مرافق، ويُسجَّل الدخول في lastvisit.
2. يملأ الطبيب بنود الشيت حقلاً حقلاً؛ كل حقل يُحفظ فوراً عبر AJAX (دالة Add/update تستقبل اسم الجدول والعمود والقيمة وتحفظ مباشرة).
3. القوائم السريرية (نوع العقم، تشخيصات الزوج، العلاجات ttt*، عوامل الزوج/الزوجة، المكان...) تُحمَّل عبر getselect من جداول القوائم، ويمكن للطبيب إضافة قيمة جديدة فورياً عبر getselectajax أو حذفها عبر deldataselect.
4. يضيف الطبيب صفوف التاريخ الإنجابي عبر append الذي يُدرج صفاً جديداً في awifep مرتبطاً بـinfertilitysheetid، ثم يكمل بياناته (نوع المولود، تاريخ وطريقة الولادة، الوزن، حي/متوفى، وسيلة منع الحمل بعده).
5. عند الضغط على زر الصيغة التوليدية تُنفَّذ دالة obstetric() فتعدّ الولادات المكتملة والمبتسرة من awifep والإجهاضات من wifeepc والحمل الجاري من ancsheet النشط، وتحفظ النتائج في حقول obst* بالشيت.
6. تُكتب روشتة لكل من الزوجة (forhusband=0) والزوج (forhusband=1) في infertilitysheetdrugs من كتالوج drugs، مع إمكانية عرض الروشتات السابقة بالتاريخ وتعديلها وطباعتها (قالب طباعة مشترك مع موديول النساء).
7. تُطلب التحاليل من كتالوج invests المصنّف بـinvestcats وتُحفظ في infertilitysheetinvest لكل من الزوجين، وتُسجَّل النتائج لاحقاً في حقل investresult وتُطبع.
8. تكمل المتابعة في جداول الفحوصات المتقدمة المرتبطة بالشيت نفسه (سائل منوي، هرمونات، موجات صوتية، مناظير، متابعة تبويض، حقن مجهري) — وهي ضمن موديولات أخرى لكنها كلها تُفتح بمفتاح infertilitysheetid.
9. الشاشة القديمة (infertility.php) ما زالت متاحة كملف سريع: تُنشئ سجل infertility مع صفوف أولية للتشخيص وآخر دورة والفحص والتحاليل والملاحظات، وتدار صفوفها بنفس أسلوب الإضافة/التعديل/الحذف الناعم.
10. الزيجات السابقة للزوجين تُسجَّل من شاشة بيانات المريضة (موديول المرضى) وتظهر في ترويسة كل الشاشات حسب إعداد programesetting.previous_marriage.

الارتباط بالموديولات الأخرى

• المرضى (patients): جميع الجداول الرئيسية مرتبطة عبر patientid، وأسماء الزوج/الزوجة وألقابهما (wifetypes, husbandtypes) تُستخدم في الطباعة.
• كتالوج الأدوية (drugs): infertilitydrugs.drugid وinfertilitysheetdrugs.drugid يشيران إلى drugs.id.
• كتالوج التحاليل (invests / investcats): infertilitysheetinvest.investid يشير إلى invests.id والتصنيف عبر invests.investcatid.
• متابعة الحمل (ancsheet): دالة obstetric() تقرأ الشيت النشط (endpreg=0) لإضافة الحمل الجاري إلى Gravida؛ كما أن قائمة type مستخدمة فعلياً في جدول registeration الخاص بشيت الحمل.
• النساء (gynasheet): يُنشأ سجل gynasheet تلقائياً من شاشة شيت العقم، وقوالب طباعة الروشتة والتحاليل مشتركة (gyna/print.html).
• الحقن المجهري (ivfsheet): يقرأ infertilitysheet وawifep وwifep وwifeepc بمفتاح infertilitysheetid لعرض التاريخ الإنجابي.
• الفحوصات المتقدمة المرتبطة بالشيت: جداول semeninfertility, hormonalprofile, tvs, hsginfertility, laparoscopyinfertility, icsi, folliculom, newvisit, wifeepc (موديولات أخرى) كلها بمفتاح infertilitysheetid.
• المستخدمون (awusers): doctorid في جداول الروشتات والتحاليل يشير إلى user_id من الجلسة.
• إعدادات البرنامج (programesetting): شعارات الطباعة وتفعيل خاصية الزيجات السابقة.
• آخر زيارة (lastvisit): تسجيل دخول المريضة لشاشة شيت العقم.

ملاحظات فنية

• يوجد جيلان متوازيان للموديول: الملف السريع القديم (infertility وفروعه) وشيت العقم الحديث (infertilitysheet وفروعه)؛ ولا يوجد ترابط بينهما سوى patientid.
• wifep جدول قديم حلّ محله awifep (الذي أضاف الوزن وحقل التوقف والعمر)، لكنه ما زال يُقرأ في شاشة تاريخ الحقن المجهري (ivfsheet.php سطر 378) — ازدواجية بيانات محتملة. وبالمثل wifepmethod قديمة وawifepmethod هي الفعّالة.
• infertilitysheet00.php نسخة كنترولر قديمة مكررة من infertilitysheet.php (تستخدم gynadrugs للروشتات بدلاً من infertilitysheetdrugs) — كود ميت يجب استبعاده.
• ثغرة أمنية جوهرية: دوال Add/update/append/getselect/deleterow تستقبل اسم الجدول والعمود من طلب POST مباشرة دون قائمة سماح، ما يتيح الكتابة أو الحذف في أي جدول بقاعدة البيانات.
• القيم متعددة الاختيار (تشخيصات الزوج، ttttype، sheethusband/sheetwife، awifepmethod) تُخزَّن كمعرفات مفصولة بفواصل داخل أعمدة varchar — غير معيارية ولا يمكن الاستعلام عنها مباشرة.
• التواريخ في infertilitysheet وawifep مخزنة كنصوص varchar بصيغ مختلطة (Y/m/d وd-m-Y)، بينما الجداول القديمة تستخدم date فعلياً.
• جميع جداول القوائم (typeinf، ttt*، sheethusband...) فارغة في نسخة قاعدة البيانات المرفقة — المعجم السريري يُبنى أثناء التشغيل من شاشة الطبيب ولا توجد قيم مرجعية معتمدة.
• عدم اتساق الحذف الناعم: del في بعض الجداول وdeleted في أخرى، وقيم del IS NULL تعني «نشط» في جداول القوائم.
• جدولا previous_marriage وhus_previous_marriage بترميز latin1 رغم احتوائهما نصوصاً عربية محتملة، وهما متطابقا البنية (تكرار هيكلي).
• الصيغة التوليدية تُخزَّن كأرقام مجمّعة في الشيت وتُعاد حسابتها يدوياً بزر — قابلة لعدم الاتساق مع بيانات awifep الفعلية.
• قائمة type ليست خاصة بالعقم فعلياً؛ تُستخدم في جدول registeration بموديول متابعة الحمل (تصنيف مكان التسجيل) — تصنيفها هنا تاريخي فقط.

توصيات النقل إلى ERP

• إنشاء موديل رئيسي InfertilityFile (يدمج infertility + infertilitysheet في ملف واحد لكل مريضة) مع جداول فرعية مهيكلة بدلاً من 64 عموداً مسطحاً: infertility_history، infertility_examination، infertility_menstrual_history.
• موديل ObstetricHistory موحّد يحل محل wifep وawifep معاً (مع ترحيل بيانات الجدولين وإزالة التكرار)، بعلاقات FK حقيقية إلى قوائم baby_sex وdelivery_mode وdelivery_type وcontraception_method.
• توحيد قوائم الاختيار في جدول واحد lookups (أو جداول Enum مهيكلة) بحقل group بدلاً من 15 جدولاً منفصلاً متطابق البنية (typeinf، sheethusband، sheetwife، sheetlocation، husbndiagnosis1-3، ttt*، wifesex، wifepmethod، awifepmethod)، مع جداول pivot للعلاقات متعددة الاختيار بدلاً من النصوص المفصولة بفواصل.
• توحيد الروشتات: استبدال infertilitydrugs وinfertilitysheetdrugs (وأشباههما في باقي الموديولات) بموديل Prescription + PrescriptionItem مركزي بحقل module وfor_spouse، وكذلك LabOrder + LabOrderItem بدلاً من infertilitysheetinvest.
• تحويل الصيغة التوليدية (G/P/FT/PT/EPC/Living) إلى Accessor محسوب آنياً في Laravel من سجلات ObstetricHistory والإجهاضات والحمل النشط بدلاً من تخزينها يدوياً.
• نقل previous_marriage وhus_previous_marriage إلى جدول واحد previous_marriages بحقل spouse (wife/husband) ضمن موديول المرضى، مع تحويل الترميز إلى utf8mb4.
• تحويل كل أعمدة التواريخ النصية إلى نوع date مع سكربت ترحيل يعالج الصيغ المختلطة، وتوحيد الحذف الناعم عبر SoftDeletes القياسية.
• إغلاق ثغرة الكتابة العامة: استبدال نقاط AJAX العامة بـ Form Requests وValidation صريحة لكل موديل، مع سياسات صلاحيات (Policies) لكل عملية.
• إسقاط infertilitysheet00.php نهائياً، ومراجعة بيانات wifep قبل الترحيل لدمج ما هو غير مكرر مع awifep.
• نقل قائمة type إلى نطاق موديول متابعة الحمل (ANC) عند الترحيل لأنها مرتبطة بجدول registeration وليس بالعقم.

الوظائف الرئيسية

• فتح ورقة IVF/ICSI نشطة واحدة لكل مريضة تلقائياً (ivfsheet حيث endpreg = 0) مع إنشاء أوراق العقم والنساء (infertilitysheet وgynasheet) تلقائياً إن لم توجد.
• تسجيل بيانات التقييم قبل التنشيط: نوع العقم ومدته، AMH، عدد الحويصلات الأولية (AFC)، البروتوكول، العلاج، الملاحظات.
• شبكة متابعة تنشيط المبايض (ovst): صف لكل زيارة يحوي يوم الدورة، التاريخ، Agonist/Antagonist، جرعة HMG، عدّ الحويصلات حسب القطر (10–20 مم) لكل مبيض، سمك البطانة، قيمة E2، وملاحظات، مع حساب التاريخ آلياً من LMP ويوم الدورة.
• تسجيل تفجير التبويض (TOO)، وسحب البويضات (OPU: العدد، MII، MI، GV)، وبيانات السائل المنوي، ونسب الإخصاب (F/E D2)، ونقل الأجنة الطازج (العدد، الدرجة، الإلغاء) والتجميد.
• دورات النقل المجمد: تحضير بطانة الرحم (eprep) بنظام دعم أصفري (epreplps)، متابعة سمك البطانة والمبيضين، الإذابة (Thawing) والنقل والنتيجة.
• إنهاء المحاولة وأرشفتها (fresh أو frozen) مع نسخ BMI من آخر فحص سريري، وتوليد سطر ملخص تاريخي في جدول icsi مرتبط بورقة العقم — بما في ذلك صفوف النقل الإضافية من جدول sefo.
• استعراض أرشيف محاولات IVF السابقة لكل مريضة وفتح أي محاولة للقراءة (ac=archive وac=historys).
• ورقة متابعة دورة تنشيط مستقلة (mointoringsheet) برقم محاولة، إجراء (IVF/ICSI/IUI...)، بروتوكول، مصدر الحيوانات المنوية (Ejaculate/PESA/TESE/Cryo)، أدوية تحفيز (HMG/Agonist/HCG) — جميعها قوائم منسدلة قابلة للإضافة الفورية من الشاشة.
• زيارات متابعة يومية داخل ورقة المتابعة (mointoringsheetvisits): يوم الدورة محسوب آلياً، جرعة HMG، سمك البطانة، حويصلات المبيض الأيمن والأيسر، E2.
• كتابة وصفات دوائية للزوجة أو الزوج من كتالوج الأدوية مع الطباعة وسجل تاريخي بالتواريخ (mointoringsheetdrugs).
• طلب تحاليل واستقصاءات للزوجة أو الزوج من كتالوج التحاليل مع تسجيل النتائج والطباعة (mointoringsheetinvestigation).
• تسجيل نتيجة الدورة في ورقة المتابعة (بويضات، أجنة منقولة، تجميد، P4، Outcome) ثم أرشفتها (status = 1) واستعراض المحاولات السابقة بتفاصيلها.
• متابعة الإباضة البسيطة (Folliculometry) ضمن ورقة العقم (folliculom): LMP، العلاج المنشط، يوم الدورة، قياس المبيضين والبطانة، التفجير والنتيجة.
• تقرير إحصائي لنتائج الـ IVF (Ivfstatistics): بحث بالفترة أو بالمريضة على الدورات الطازجة والمجمدة مع حساب عمر الزوجة وقت المحاولة وعرض البروتوكول والسائل المنوي وأول/آخر متابعة تنشيط وعدد دورات تحضير البطانة، مع الطباعة.
• تقرير يومي وبحث بفترة لحالات الـ IUI (iui.php) اعتماداً على تاريخ ونتيجة ورقة العقم (infertilitysheet.sheetdate / sheetresult) مع الطباعة.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يدخل الطبيب على المريضة من شاشة المرضى ويفتح «IVF Sheet» (ivfsheet.php?ac=index&patientid=…)؛ يبحث النظام عن ورقة نشطة (endpreg = 0) وإن لم توجد ينشئها فوراً، وينشئ معها infertilitysheet وgynasheet إن لم تكونا موجودتين، ويسجل الدخول في lastvisit.
2. تُحفظ كل خانة في الشاشة لحظياً عبر AJAX (دالة Add() تستقبل اسم الجدول والعمود والقيمة وتحدّث مباشرة) — لا يوجد زر حفظ مركزي.
3. يضيف الطبيب صفوف متابعة التنشيط بالزر «append» الذي ينشئ سجل ovst مرتبطاً بالورقة، ثم يُدخل يوم الدورة فيحسب النظام التاريخ آلياً من lmpfresh (دالتا ovstcdfh وnewcd)، ويُسجل Ag/HMG وعدّ الحويصلات حسب القطر والبطانة وE2.
4. عند النضج تُسجل بيانات التفجير (TOO) ثم سحب البويضات (OPU) وبيانات السائل المنوي والإخصاب، ثم نقل الأجنة الطازج (وصفوف نقل إضافية في جدول sefo) أو التجميد.
5. في دورات النقل المجمد تُضاف صفوف eprep لتحضير البطانة (LMP المجمد، العلاج، السمك، نظام LPS من قائمة epreplps) ثم بيانات الإذابة والنقل والنتيجة.
6. عند انتهاء المحاولة يضغط الطبيب «إنهاء» محدداً النوع (fresh/frozen)؛ فتُؤرشف الورقة (endpreg = 1، frozenor، historytoday، نسخ bmi من آخر examination) ويُولَّد سطر/أسطر ملخصة في icsi بقيم نصية منسوخة من القوائم (البروتوكول، المكان، السائل المنوي) مرتبطة بـ infertilitysheetid لتظهر في تاريخ ورقة العقم.
7. يمكن استعراض المحاولات المؤرشفة من ac=archive وفتح أي محاولة للقراءة من ac=historys.
8. بالتوازي توجد شاشة «Monitoring Sheet» (monitoring.php): تُفتح ورقة متابعة مفتوحة واحدة لكل مريضة (status = 0) وتُنشأ تلقائياً، ويُختار الإجراء والبروتوكول ومصدر العينة وأدوية التحفيز من قوائم قابلة للإضافة الفورية (addNewItem) والتعديل (editselect).
9. كل زيارة متابعة تُضاف بصف جديد (addNewVisit) بيوم دورة محسوب آلياً من monitordate، وتُحدَّث خاناته (HMG/Endo/حويصلات يمين-يسار/E2) لحظياً عبر update().
10. من نفس الشاشة تُكتب وصفات للزوجة أو الزوج (mointoringsheetdrugs من كتالوج drugs) وتُطلب تحاليل (mointoringsheetinvestigation من كتالوج invests) مع شاشات عرض وطباعة بالتواريخ.
11. بعد تسجيل نتائج OPU والأجنة والتجميد والمحصلة تُؤرشف الورقة (trigSheet ⇒ status = 1)، وتُستعرض المحاولات السابقة من trials وتفاصيل كل محاولة من trialdetail عبر استعلام JOIN مع جداول القوائم التسعة.
12. تقرير «IVF Statistics» يبحث في ivfsheet بفترة LMP (طازج أو مجمد) أو بالمريضة، ويحسب عمر الزوجة وقت المحاولة من patients.dateofbirth، ويعرض أول وآخر صف تنشيط وعدد دورات تحضير البطانة؛ وتقرير «IUI» يعرض حالات اليوم ويبحث بفترة على infertilitysheet.sheetdate وsheetresult مع الطباعة.

الارتباط بالموديولات الأخرى

• موديول المرضى: ivfsheet.patientid وmointoringsheet.patientid وmointoringsheetdrugs.patientid وmointoringsheetinvestigation.patientid ← patients.id (وبيانات الزوج تُقرأ من نفس سجل المريضة: husdandname, husbandtypeid).
• موديول العقم (Infertility): icsi.infertilitysheetid وfolliculom.infertilitysheetid ← infertilitysheet.id؛ وشاشة IVF تنشئ وتعرض ورقة العقم وجداولها (awifep, wifeepc)، وتقرير IUI يعتمد كلياً على infertilitysheet.sheetdate/sheetresult.
• موديول النساء (Gyna): شاشة IVF تنشئ/تعرض gynasheet للمريضة، وشاشات طباعة المتابعة تستخدم قوالب gyna/print.html وgyna/printinv.html.
• كتالوج الأدوية: mointoringsheetdrugs.drugid ← drugs.id مع حقلي ربط بإيصالات الصيدلية recepittmpid وrecepitdrugid (استنتاج).
• كتالوج التحاليل: mointoringsheetinvestigation.investid ← invests.id وتُعرض مجموعات التحاليل من investcats.
• موديول الفحص السريري: عند أرشفة المحاولة يُنسخ examination.bmi إلى ivfsheet.bmi.
• المستخدمون والصلاحيات: mointoringsheet.doctorid وdoctorid في الوصفات والتحاليل ← awusers (من الجلسة user_id)، والتحقق عبر awrole.
• قوائم مشتركة من موديولات أخرى: ivfsheet.antype/antypes ← جدولا antype/antypes، وivfsheet.pla2cen ← pla2cen (أماكن)، وivfsheet.sseemen ← sseemen.
• تتبع آخر زيارة: شاشتا IVF وIUI تسجلان في lastvisit؛ وتقارير Completesreport وsh وpatienthistory تقرأ icsi وfolliculom وeprep ضمن الملف الشامل للمريضة.

ملاحظات فنية

• خطأ إملائي ثابت في أسماء عشرة جداول: «mointoring» بدلاً من «monitoring»، و«sryo» بدلاً من «cryo»، و«folliculom» بدلاً من «folliculometry» — يجب توحيدها عند النقل.
• ازدواجية كاملة بين ivfsheet.php وivfsheet00.php (نسخة أقدم لا تدعم جدول sefo ولا نسخ BMI) — كود ميت يجب إسقاطه.
• جدول ovst يستخدم أسماء أعمدة مشفّرة غير قابلة للصيانة (ovstfr, ovstfrrrr, ovstdffffff…) تمثل خلايا شبكة عدّ الحويصلات حسب القطر 10–20 مم؛ المعنى محفوظ فقط في ترتيب أعمدة قالب Smarty.
• جدول icsi يخزن قيم القوائم كنصوص منسوخة (denormalized) بينما ivfsheet يخزنها كمعرّفات — ازدواجية تمثيل لنفس البيانات.
• جدول sefo (صفوف نقل أجنة إضافية) مستخدم في الكود لكنه غير موجود في ملف الـ SQL — يُنشأ آلياً بوضع RedBeanPHP الـ fluid، وهي مخاطرة تشغيلية.
• جميع جداول القوائم المنسدلة (15 جدولاً) فارغة في النسخة الاحتياطية؛ المفردات السريرية تُدخل وتُدار من الشاشات مباشرة (addNewItem/getselectajax).
• كل التواريخ في ivfsheet وovst وeprep وfolliculom مخزنة كـ varchar بصيغة Y/m/d وليست أعمدة تاريخ — يستحيل الفرز والاستعلام الزمني الموثوق.
• ثغرات أمنية جوهرية: دوال Add() وupdate() وdel() تستقبل اسم الجدول والعمود من الـ POST مباشرة (كتابة عشوائية في أي جدول)، ودالة newcd() وبحث iui.php يبنيان SQL بالتجميع النصي (SQL Injection).
• خطأ منطقي في بحث Ivfstatistics: شرط OR بدون أقواس في الفرع غير المقيد بالمريضة، ودالة showprint فيه تستعلم من ancsheet (خطأ نسخ-لصق من تقرير الحمل) فالطباعة لا تعكس نتائج البحث.
• ورقة المتابعة تفترض ورقة مفتوحة واحدة لكل مريضة دون قيد فريد في قاعدة البيانات، والحذف في كل الجداول منطقي (deleted/del) بدون توحيد (بعضها del is null وبعضها deleted = 0).

توصيات النقل إلى ERP

• توحيد المسارين المزدوجين (ورقة IVF وورقة المتابعة) في كيان واحد: نموذج IvfCycle (Laravel) يمثل المحاولة برقمها ونوعها (Fresh/Frozen/IUI/Monitoring) وحالتها (Active/Archived) بدلاً من ivfsheet + mointoringsheet المنفصلين.
• إنشاء نموذج IvfCycleVisit موحّد يدمج ovst وmointoringsheetvisits وfolliculom: زيارة متابعة بتاريخ ويوم دورة وجرعات وE2 وسمك بطانة، مع جدول فرعي follicle_measurements (جانب المبيض، القطر، العدد) بدلاً من الأعمدة المشفّرة الـ 26 في ovst.
• نمذجة مراحل الدورة كجداول فرعية واضحة: OpuRecord (البويضات: total/MII/MI/GV)، SemenSample (المصدر: Ejaculate/PESA/TESE/Cryo)، EmbryoTransfer (يشمل صفوف sefo الإضافية)، Cryopreservation، EndometrialPrep (يستوعب eprep مع الإذابة)، وCycleOutcome (HCG/كيس حمل/ولادة).
• الاستغناء عن جدول icsi الملخّص نهائياً: هو نسخة denormalized تُولَّد عند الأرشفة، ويُستبدل بـ View أو API endpoint يجمع تاريخ المحاولات من الكيانات الأصلية.
• دمج جداول القوائم الـ 15 (icsiprotocol, icsiplace, icsisemen, icsiss, icsiresult, epreplps, وجداول mointoringsheet* التسعة) في جدول مرجعي واحد lookups بنمط type + name + is_active أو Enum حيث تكون القيم سريرية ثابتة (البروتوكولات، مصادر العينة)، مع ترحيل القيم الحية من قاعدة الإنتاج لأنها فارغة في النسخة الاحتياطية.
• تحويل جميع أعمدة التواريخ النصية إلى date/datetime أثناء الترحيل مع سكربت تنظيف لصيغة Y/m/d والقيم 0000-00-00، وتحويل الأعداد (بويضات، أجنة، E2) إلى أنواع رقمية مع التحقق.
• ربط الوصفات والتحاليل بنظام الوصفات/المعمل الموحد في الـ ERP: mointoringsheetdrugs ⇒ prescriptions العامة (مع علاقة بالدورة وبالشريك)، وmointoringsheetinvestigation ⇒ lab_orders، مع خاصية for_partner بدل forhusband.
• فرض قيود قاعدة البيانات الغائبة: مفاتيح أجنبية فعلية، وقيد فريد «دورة نشطة واحدة لكل مريضة»، وحذف ناعم موحّد (deleted_at)، وإلغاء كل نقاط الـ AJAX العامة (table/column من العميل) لصالح Form Requests وPolicies في Laravel.
• إعادة بناء تقرير إحصائيات الـ IVF كاستعلامات Eloquent/SQL مفهرسة على الكيانات الجديدة (نِسب الحمل لكل بروتوكول/فئة عمرية/نوع دورة) بدل الحلقات N+1 الحالية، وتصحيح تقرير الطباعة المعطوب، وبناء تقرير IUI على كيان الدورة بدلاً من ورقة العقم.

الوظائف الرئيسية

• تسجيل تحليل سائل منوي سريع للمريض من شاشة الفحوصات (Investigations) مع الحقول: العدد count، الحركة التقدمية motilitya/motilityab، الأشكال الطبيعية normal، خلايا الصديد puscell، مع أعلام تصنيفية (Oligo / Astheno / Terato / Normal) كمربعات اختيار.
• تسجيل صفوف متعددة لتحاليل السائل المنوي داخل شيت العقم مع مكان التحليل ونوعه (قوائم منسدلة قابلة للإضافة أثناء العمل) والقيم: nc (العدد)، prm (الحركة التقدمية)، tm (الحركة الكلية)، af (الأشكال غير الطبيعية)، vit (الحيوية)، vol (الحجم)، tzi، sdi.
• تسجيل الفحوصات الأندرولوجية المتقدمة (قسم "Other Inv" في شيت العقم): سونار كيس الصفن، فحص TRUE، الخريطة الكروموسومية Karyotype، حذف Y الدقيق Yq Microdeletion، تفتت DNA الحيوانات المنوية SDF، فحص Semen Fr، وعينة الخصية TESE — لكل فحص تاريخ ومكان ونتيجة.
• نتائج الفحوصات تُختار من قوائم مرجعية يديرها المستخدم (سبعة جداول lookup) مع إمكانية إضافة قيمة جديدة من داخل الشاشة عبر AJAX دون مغادرة الشيت، ونتيجة السونار تقبل اختيارات متعددة.
• تسجيل ملف هرموني للزوج داخل شيت العقم (FSH، LH، Testosterone الكلي، Prolactin، E2، Inhibin B + خانتان حرتان) بصيغة تاريخ/نتيجة لكل هرمون، وملف هرموني ثانٍ (hormonalprofile2) يضم AMH وTSH وP4 (للزوجة — استنتاج).
• تسجيل لوحة هرمونات معملية شاملة للمريض من شاشة الفحوصات (جدول hormon): LH، FSH، PRL، E2، AMH، Free/Total Testosterone، P4، TSH، T3، T4، DHT، BhCG، Inhibin B، DHEAS، إضافة إلى دلالات أورام (CA125، CEA، LDH).
• إدخال خصائص السائل المنوي المستخدم في دورة الحقن المجهري/أطفال الأنابيب (أربع قوائم منسدلة تحت عمود "Semen" في جدول الدورة بشيت IVF) تُخزَّن في أعمدة ssemen/sseemen/sseemmen/sseemmeen بجدول ivfsheet.
• عرض كل بيانات الموديول في تقرير المراجعة الشامل (كنترولر sh.php) مع فك ترميز القوائم المرجعية وطباعة الشيت.
• حذف منطقي (soft delete) لسجلات semen وhormon عبر العمود del، وحذف فعلي لصفوف شيت العقم.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يفتح الطبيب شاشة الفحوصات (investigation.php) لمريض محدد؛ إذا لم يوجد سجل سائل منوي، يُنشئ النظام تلقائيًا صفًا فارغًا في semen بتاريخ اليوم ومعرّف الطبيب الحالي.
2. تُحرَّر القيم خانةً بخانة عبر AJAX (دالة update العامة التي تستقبل اسم الجدول والعمود والقيمة)، وتُضاف صفوف جديدة بزر "Add" (دالة addRow العامة لجداول semen وhormon وغيرها)، ويتم الحذف منطقيًا بوضع del = 1.
3. في مسار العقم، يفتح الطبيب شيت العقم (infertilitysheet.php) فيُنشأ infertilitysheet تلقائيًا للمريض إن لم يوجد، وتُحمَّل صفوف semeninfertility وsemen2 وhormonalprofile وhormonalprofile2 المرتبطة به.
4. يضيف الطبيب صف تحليل سائل منوي أو فحص أندرولوجي أو ملف هرموني بالنقر على رابط الإضافة (دالة append العامة التي تُنشئ صفًا بربط infertilitysheetid)، ثم يملأ الخلايا التي تُحفظ فورًا حقلًا بحقل.
5. عند اختيار مكان التحليل أو نتيجته، تُحمَّل الخيارات من جداول الـ lookup عبر AJAX، ويمكن للطبيب إضافة قيمة جديدة فورًا (دالة getselectajax تُدخل سطرًا جديدًا في جدول الـ lookup المعني)؛ نتيجة سونار الصفن تُحفظ كقائمة معرّفات مفصولة بفواصل.
6. في شيت أطفال الأنابيب (ivfsheet.php) يسجّل الطبيب خصائص العينة المنوية المستخدمة في الدورة من أربع قوائم منسدلة تُخزَّن قيمها في أعمدة ssemen/sseemen/sseemmen/sseemmeen بجدول ivfsheet.
7. عند المراجعة أو الطباعة، يعرض كنترولر sh.php الشيت كاملًا للقراءة: يجلب صفوف السائل المنوي والفحوصات الأندرولوجية والملفات الهرمونية ويفك ترميز كل القوائم المرجعية إلى نصوصها، ويسجّل آخر زيارة للمريض في lastvisit.
8. تظهر بيانات الموديول أيضًا في التقارير المجمعة (completereport.php وfullreport.php وغيرها) ضمن التقرير الشامل للمريضة.

الارتباط بالموديولات الأخرى

• المرضى (Patients): عبر semen.patientid وhormon.patientid وكذلك infertilitysheet.patientid الذي تتفرع منه بقية الجداول.
• شيت العقم (Infertility): الجداول semeninfertility وsemen2 وhormonalprofile وhormonalprofile2 كلها أبناء لـ infertilitysheet عبر infertilitysheetid.
• أطفال الأنابيب (IVF): أعمدة ivfsheet.ssemen وsseemen وsseemmen وsseemmeen تشير إلى جداول الـ lookup الخاصة بهذا الموديول إضافة إلى جدول icsisemen التابع لموديول IVF.
• المستخدمون/الأطباء (Users): عبر semen.doctorid وhormon.doctorid إلى awusers.user_id (يُعرض اسم الطبيب مع كل سجل).
• الفحوصات العامة (Investigations): جدولا semen وhormon يُعرضان في نفس شاشة الفحوصات مع HSG والباثولوجي والفحوصات الأخرى، ويتحكم إعداد programesetting.investshow في شكل الشاشة.
• الأدوية (Drugs): كنترولر drugsex.php المرتبط بالموديول هو في الواقع إدارة كتالوج الأدوية (drugs) المستخدم في الروشتات، وليس له علاقة مباشرة بجداول السائل المنوي.
• الزيارات (Visits): كنترولر sh.php يسجّل فتح الشيت في جدول lastvisit.

ملاحظات فنية

• لا توجد أي مفاتيح أجنبية معلنة؛ كل العلاقات ضمنية عبر أعمدة معرّفات، وsemen.patientid معرّف نصي varchar(191) بينما معرف المريض رقمي.
• جميع القيم الرقمية والتواريخ في جداول الشيت مخزنة كـ varchar(191) (حتى تواريخ الفحوصات ونتائج الهرمونات)، ما يمنع أي تحقق أو حسابات أو فرز زمني سليم.
• الجداول الأربعة المشوّهة إملائيًا ssemen/sseemen/sseemmen/sseemmeen ليست نسخًا مكررة من بعضها: ثلاثة منها قوائم مرجعية مستخدمة فعليًا لأعمدة "Semen" بشيت IVF، بينما sseemmen جدول يتيم لا يقرأه الكود إطلاقًا (القائمة المقابلة تقرأ من icsisemen).
• نتيجة سونار الصفن تُخزَّن كسلسلة معرّفات مفصولة بفواصل داخل عمود نصي، وتُستعلم بتركيب نصي مباشر "id in (0$ids)" — نمط هش وقابل لحقن SQL.
• دوال عامة مثل update وappend وgetselectajax تستقبل اسم الجدول والعمود من طلب POST مباشرة دون قائمة سماح — ثغرة Mass Assignment/كتابة في أي جدول.
• الكنترولر القديم infertilitysheet00.php يستعلم جدول semen بشرط infertilitysheetid = ? رغم أن الجدول لا يحتوي هذا العمود أصلًا — كود قديم ميت يعكس تغيّر التصميم.
• فتح شاشة الفحوصات يُنشئ تلقائيًا سجل semen فارغًا إذا لم يوجد، ما يولّد سجلات فارغة غير ذات معنى في قاعدة البيانات.
• جدول hormon يخلط هرمونات الخصوبة بدلالات الأورام (CA125، CEA، LDH) في صف واحد عريض.
• جداول الـ lookup كلها فارغة في نسخة قاعدة البيانات (لا بيانات seed)؛ المصطلحات السريرية تُبنى من إدخالات المستخدمين أثناء التشغيل.
• drugsex.php اسم مضلِّل (إدارة كتالوج الأدوية)، ويحتوي استعلامات DataTables مبنية بدمج نصوص مع LIKE '%...%' مباشرة من المدخلات — قابلية حقن SQL.
• جدول semen2 "عريض" (wide table): لكل فحص ثلاث أو أربع أعمدة (تاريخ/مكان/نتيجة) بدلًا من نمذجة الفحوصات كصفوف.

توصيات النقل إلى ERP

• إنشاء موديل SemenAnalysis موحّد يدمج semen وsemeninfertility في جدول واحد بأعمدة رقمية مُنمَّطة (volume، concentration، progressive_motility، total_motility، normal_forms، vitality، tzi، sdi، pus_cells) مع patient_id إلزامي وinfertility_sheet_id اختياري، وأعلام التصنيف (oligo/astheno/terato) كحقول boolean أو يُستغنى عنها بالحساب من القيم.
• تطبيع جدول semen2 العريض إلى موديل AndrologyInvestigation بصيغة طولية: صف لكل فحص بأعمدة type (scrotal_us, trus, karyotype, y_microdeletion, sdf, semen_fr, tese, other) وperformed_at وplace وresult، مع جدول pivot لنتائج السونار متعددة القيم بدل السلاسل المفصولة بفواصل.
• دمج جداول الـ lookup السبعة (semen2result* وsemen2place*) في جدولين مرجعيين عامين: andrology_result_options وlab_places مع عمود تمييز investigation_type، ودمج semenplace/sementype في نفس البنية.
• تطبيع الهرمونات: استبدال hormon وhormonalprofile وhormonalprofile2 بموديل HormoneResult طولي (patient_id، infertility_sheet_id اختياري، hormone_code، value، sampled_at) مع جدول مرجعي hormones يشمل المدى الطبيعي والوحدة، وربطه بموديول المعمل في الـ ERP بدل تكرار البيانات؛ مع فصل دلالات الأورام عن هرمونات الخصوبة.
• حذف الجدول اليتيم sseemmen نهائيًا، وإعادة تسمية ssemen/sseemen/sseemmeen إلى قوائم مرجعية بأسماء واضحة بعد التحقق من دلالتها السريرية مع العيادة (استنتاج: مصدر العينة وطريقة التحضير وحالتها)، وربطها بموديول IVF كحقول منمّطة في دورة الحقن.
• تحويل كل التواريخ إلى نوع DATE والقيم الرقمية إلى DECIMAL مع تنظيف البيانات أثناء الترحيل (قيم نصية حرة متوقعة)، واعتماد deleted_at (SoftDeletes) بدل عمود del.
• إعلان مفاتيح أجنبية فعلية (patient_id، doctor_id، infertility_sheet_id) واستبدال نقاط النهاية العامة (تحديث أي جدول/عمود من POST) بـ Form Requests وValidation وWhitelisting في Laravel وواجهات Angular مخصصة لكل نموذج.
• إلغاء إنشاء السجلات الفارغة تلقائيًا عند فتح الشاشات، وتصفية السجلات الفارغة الموروثة أثناء الترحيل.

الوظائف الرئيسية

• إنشاء تقرير موجات صوتية للحمل متعدد الأجنة: سجل رئيسي للفحص وصف تفصيلي مستقل لكل جنين (مسح تشريحي كامل: الرأس، القلب، البطن، الكلى، العمود الفقري، الأطراف، النوع) مع قياسات حيوية (BPD, HC, AC, FL, CRL, NT) وتقدير عمر الحمل.
• الحفظ الفوري حقلاً بحقل عبر AJAX دون زر حفظ (نمط update(table, column, value) عام في جميع شاشات الموديول).
• إضافة جنين جديد أو حذفه مع تحديث عدد الأجنة babyno تلقائياً، واعتماد التقرير نهائياً عند الطباعة (done = 1).
• تقرير موجات صوتية نسائي شامل (وضع الرحم، سمك بطانة الرحم، المبيضان، كتل الحوض، شرايين الدوبلر، الاستنتاج) في سجل واحد مسطح.
• تسجيل فحوص TVS والدوبلر المهبلي وSIS وHSG داخل ملف العقم باختيارات متعددة من قوائم مفردات إكلينيكية (رحم، مبيض أيمن/أيسر، عنق الرحم، الحوض، الأنابيب).
• تسجيل نتائج HSG وUS-TV وMRI/CT كنصوص حرة (الرحم، الزائدتان، الحوض، الأنابيب) من شاشة الفحوصات الموحدة مع اسم الطبيب والتاريخ.
• حجز ومتابعة فحوص 4D: إنشاء تلقائي لسجل الحجز عند إدخال تاريخ الولادة المتوقع في ملف متابعة الحمل، واختيار الخدمات والمكان، وتتبع تنفيذ الفحص الأول والثاني والتأكيد.
• رفع صور الموجات (متعددة دفعة واحدة) وفيديوهات الفحص مع ملاحظات وتاريخ، وطباعة مجموعة صور مختارة بترويسة العيادة، وتنزيل الفيديو باسمه الأصلي.
• أداة GT Image: سحب وإفلات علامات مرقمة على صورة تشريحية أساسية مع تعليق لكل علامة وحفظ إحداثياتها (x, y, عرض, ارتفاع).
• عرض حقول الموجات (السائل الأمنيوسي، موضع المشيمة، الملاحظات) داخل زيارات متابعة الحمل عبر قوائم usn / usaf / usplace.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يفتح الطبيب أو فني الموجات شاشة التقرير من ملف المريضة؛ إذا لم يوجد تقرير مفتوح يُنشأ تلقائياً سجل رأس جديد (ultrasound أو ultrasoundobst أو ultrasoundgyna) بتاريخ اليوم مع سطر تفاصيل افتراضي لجنين واحد.
2. تُملأ بيانات الفحص حقلاً بحقل (نوع الفحص، دواعي الإجراء، فني الموجات من مستخدمي النظام ذوي الوظيفة 4) ويُحفظ كل حقل فور تعديله عبر AJAX.
3. في حالة الحمل المتعدد يضيف المستخدم سطر تفاصيل لكل جنين، ويستكمل المسح التشريحي (أكواد عددية) والقياسات الحيوية، وعند حذف جنين يُخفض عداد babyno.
4. عند الطباعة يُعتمد التقرير نهائياً (done = 1) ويظهر بعدها في قائمة التقارير المنجزة للمريضة، مع إمكانية الحذف المنطقي (del = 1).
5. من شاشة الفحوصات (investigation.php) تُنشأ تلقائياً سجلات فارغة لـ hsg وustv وmrict عند أول فتح، وتُسجل النتائج نصياً مع تاريخ الفحص واسم الطبيب.
6. داخل ملف العقم تُسجل فحوص TVS والدوبلر وSIS وHSG كصفوف مرتبطة بـ infertilitysheetid، وتُختار النتائج من قوائم المفردات وتُخزن كمعرفات مفصولة بفواصل، وتظهر مجمعة في التقارير الشاملة (sh.php، Completesreport.php).
7. عند إدخال تاريخ الولادة المتوقع في ملف متابعة الحمل يُنشأ تلقائياً حجز 4D في op_4d_list ويُربط بالملف عبر ancsheet.4d_list_id؛ ويدير قسم العمليات قائمة الحجوزات (الخدمات، المكان، علامات تنفيذ الفحص الأول والثاني والتأكيد).
8. تُرفع صور الفحص دفعة واحدة إلى upload/sonar بأسماء عشوائية (md5) والفيديوهات إلى upload/sonarvedio/1 مع حفظ الاسم الأصلي، وتُعرض في معرض زمني لكل مريضة مع الطباعة والتنزيل، والحذف منطقي فقط (tempdelete).
9. في أداة GT Image يُنشأ سجل جلسة جديد عند كل دخول، ويسحب المستخدم علامات مرقمة على الصورة التشريحية وتُحفظ إحداثياتها وتعليقاتها في gtdetail.

الارتباط بالموديولات الأخرى

• موديول المرضى: جميع جداول الفحوص ترتبط بـ patients عبر patientid.
• موديول المستخدمين والصلاحيات: فني الموجات عبر sid والطبيب عبر doctorid ومنفذو فحص 4D عبر t1_userid / t2_userid إلى awusers.user_id (الفنيون هم المستخدمون ذوو positionid = 4).
• موديول متابعة الحمل (ANC): حجوزات 4D عبر op_4d_list.ancsheetid → ancsheet.id والمؤشر العكسي ancsheet.4d_list_id، وقوائم usn / usaf / usplace تُستهلك من جدول زيارات المتابعة ancnewvisit.
• موديول العقم: فحوص tvs / dtvs / sis / hsginfertility مرتبطة بـ infertilitysheet عبر infertilitysheetid، وقائمة sisresult تتبع موديول العقم.
• موديول الفحوصات والمعامل: سجلات hsg / ustv / mrict تُدار من شاشة الفحوصات الموحدة investigation.php جنباً إلى جنب مع المعمل والمناظير.
• موديول العمليات: قائمة 4D تُدار من operations.php وترتبط بقائمة الأماكن place عبر op_4d_list.place.
• إعدادات النظام: صورة الأساس لأداة GT Image ووضع العرض من programesetting.
• التقارير المجمعة: sh.php وCompletesreport.php وfullreport.php تقرأ جداول الموديول لبناء التقرير الشامل للمريضة.

ملاحظات فنية

• ازدواجية واضحة: ultrasound/ultrasounddetail وultrasoundobst/ultrasoundobstdetail نسختان متداخلتان (نحو 80% من الحقول مشتركة) وكلتاهما نشطتان في الكود؛ كما تتكرر بيانات HSG في ثلاثة مواضع (hsg نص حر، hsginfertility قوائم، وحقول داخل ملفات أخرى).
• الاختيارات المتعددة مخزنة كمعرفات مفصولة بفواصل في حقول varchar (مثل tvs.tvsut وop_4d_list.four_d) وتُحل بالنمط id in (0$csv) — لا تكامل مرجعي ولا إمكانية استعلام فعالة.
• لا توجد مفاتيح خارجية معلنة إطلاقاً؛ وكل العلاقات استُنتجت من أسماء الأعمدة وكود الكنترولرات.
• أخطاء أنواع بيانات: patientid من النوع varchar في hsg وustv وmrict، وتواريخ مخزنة كـ varchar في tvs / dtvs / sis / hsginfertility، وكل القياسات الرقمية (BPD وHC وغيرها) مخزنة كنصوص.
• جدول sonar هو الوحيد بمحرك MyISAM (بقية الجداول InnoDB)، والملفات تُخزن على القرص بأسماء md5 دون تحقق من النوع، ويُحذف الملف فعلياً عند الاستبدال بينما الحذف من الشاشة منطقي فقط (تظل الملفات على القرص).
• ثغرات أمنية: بناء استعلامات SQL بدمج النصوص مباشرة (patientid في sonar.php مثلاً)، ونقطة AJAX عامة تسمح بالكتابة في أي جدول/عمود يمرر من المتصفح (update(tableName, colName, value)).
• خلل وظيفي: gtimage.php?ac=index يدرج سجل جلسة جديداً عند كل زيارة للصفحة مما يولد سجلات فارغة يتيمة؛ وكذلك investigation.php يدرج صفوف hsg/ustv/mrict فارغة تلقائياً.
• نسخة قاعدة البيانات (12-7-2024) لا تحتوي على أي بيانات أولية لقوائم المفردات (tvs*/hsg*/us*/four_d)؛ المفردات الفعلية موجودة فقط في قاعدة بيانات التشغيل ويجب تصديرها منها قبل الترحيل.
• دلالات أعلام t1/t11/t12/t2/t21/t22 في حجوزات 4D غير موثقة؛ المؤكد من الكود أن إدخال tscandate/ttscandate في ملف المتابعة يرفع t11/t21 (استنتاج: مراحل حجز/تنفيذ/سداد الفحصين الأول والثاني).

توصيات النقل إلى ERP

• إنشاء موديل موحد ImagingStudy (نوع الدراسة: OBST_US, GYNA_US, TVS, DOPPLER_TVS, SIS, HSG, MRI, CT, 4D) يحل محل رؤوس ultrasound / ultrasoundobst / ultrasoundgyna / ustv / mrict / hsg وصفوف فحوص ملف العقم، مع حالة (مسودة/معتمد) بدل العلم done.
• دمج ultrasounddetail وultrasoundobstdetail في موديل واحد FetalScanFinding (سجل لكل جنين) يضم الحقول المشتركة وحقول الثلث الأول، مع تخزين المسح التشريحي كـ JSON أو جدول قيم مرجعي بدلاً من 35+ عموداً مرمزاً.
• توحيد 16 جدول مفردات صغيراً (tvs*, hsg*, usn/usaf/usplace, dtvs*, four_d) في جدول واحد imaging_finding_options بعمود domain، مع تصدير القيم من قاعدة التشغيل لا من النسخة الاحتياطية.
• استبدال جميع حقول CSV بجداول وسيطة (Pivot) بعلاقات Many-to-Many حقيقية ومفاتيح خارجية مفروضة.
• ترحيل sonar إلى نظام مرفقات قياسي (Spatie MediaLibrary أو تخزين S3) مع روابط موقعة بدل readfile()، ونقل ملفات upload/sonar وupload/sonarvedio/1 مع الاحتفاظ بالاسم الأصلي وتاريخ الالتقاط والملاحظات.
• تحويل op_4d_list إلى موديل FourDScanBooking بحالة صريحة (Enum) بدل أعلام البتات، وعلاقة hasOne من سجل متابعة الحمل بدل المؤشر العكسي 4d_list_id.
• تحويل gtimage / gtdetail إلى AnnotatedDiagram / DiagramMarker بإحداثيات نسبية (%) وإصلاح إنشاء الجلسات الفارغة، أو إعادة بنائها كمكون Angular Canvas.
• أثناء الـ ETL: تحويل patientid النصي إلى مفاتيح رقمية، وتحويل التواريخ والقياسات النصية إلى أنواع DATE وDECIMAL، وتوحيد أعلام الحذف (del / tempdelete / deleted) في SoftDeletes، ووسم كل سجل بجدول المصدر لتتبع الازدواجية بين النسختين القديمة والحديثة.
• إلغاء نقطة التحديث العامة واستبدالها بـ FormRequests مخصصة لكل مورد مع تحقق من المدخلات وصلاحيات على مستوى السجل.

الوظائف الرئيسية

• تسجيل تقرير منظار بطن نصّي حر لكل مريضة (الرحم، الزائدة اليمنى، الزائدة اليسرى، الحوض، ملاحظات) من تبويب LAPAROSCOPY في شاشة الفحوصات، مع إنشاء سجل فارغ تلقائيًا بتاريخ اليوم عند أول فتح للشاشة.
• تسجيل تقرير منظار رحم نصّي حر (عنق الرحم، التجويف الرحمي، الفتحة اليمنى، الفتحة اليسرى، ملاحظات) بنفس الآلية من تبويب HYSTEROSCOPY.
• تسجيل منظار بطن منظّم داخل شيت العقم: صف للنتائج لكل عضو (مكان الإجراء، الرحم UT، الأنبوب الأيمن RT، الأنبوب الأيسر LT، المبيض الأيمن RO، المبيض الأيسر LO، الحوض) وصف ثانٍ للتدخل الجراحي/الإدارة العلاجية لكل عضو (laparm*) مع نص التدخل والتكلفة.
• تسجيل منظار رحم منظّم داخل شيت العقم: التوسيع (Dil)، إدخال المنظار (Introd)، عنق الرحم (CX)، التجويف والقاع (Cavity-Fundus)، الفتحتان اليمنى واليسرى، ثم صف الإدارة العلاجية (copym*) مع نص التدخل والتكلفة.
• إضافة صفوف مناظير غير محدودة لكل شيت عقم عبر AJAX (أكشن append)، وحفظ كل حقل لحظيًا عند التعديل (أكشن update العام).
• إثراء قوائم المصطلحات السريرية أثناء العمل: الطبيب يضيف مصطلحًا جديدًا لأي قائمة (lapar*/copy*) مباشرة من الشاشة عبر getselectajax دون الرجوع لشاشة إعدادات.
• دعم الاختيار المتعدد للنتائج: تُخزَّن معرّفات القيم المختارة كسلسلة مفصولة بفواصل (CSV) في حقل واحد وتُفكّ عند العرض بـ id in (...).
• تقرير عمليات اليوم/فترة بحث: شاشة Operations تعرض عمليات المناظير (من جداول العقم) مع بيانات المريضة ومكان الإجراء، بالربط مع شيت العقم.
• إدراج نتائج المناظير في التقرير الشامل للمريضة (Complete Report) والتقرير الكامل (Full Report) مع اسم الطبيب المعالج، وفي تقارير الطباعة (sh.php وCompletesreport.php).
• إدارة قوائم نوع الشق الجراحي (jncision: midline/transverse/paramedian/Pfannenstiel) والنوع الفرعي التابع له (midlinejncision: upper/lower...) كقائمتين متسلسلتين تُستخدمان في تفاصيل العمليات (Operative Details).
• تتبّع آخر زيارة للمريضة (جدول lastvisit) عند فتح شاشة العمليات باسم الكنترولر.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. المسار الأول (شاشة الفحوصات – investigation.php): عند فتح ملف فحوصات المريضة، إن لم يوجد سجل منظار سابق يُنشأ تلقائيًا سجل فارغ في laparoscopy وآخر في hysteroscopy بتاريخ اليوم ومعرّف الطبيب الحالي.
2. يدوّن الطبيب النتائج نصيًا في تبويبي LAPAROSCOPY وHYSTEROSCOPY، ويُحفظ كل حقل فور تعديله عبر AJAX (updateElement → أكشن update)، مع إمكانية إضافة سجلات بتواريخ جديدة أو حذف سجل (حذف منطقي del=1).
3. المسار الثاني (شيت العقم – infertilitysheet.php): من قسم Investigations في الشيت يضغط الطبيب «Hysteroscopy» أو «Laparoscopy» فيُنشأ صف جديد عبر أكشن append مربوط بـinfertilitysheetid وبتاريخ اليوم.
4. يختار الطبيب النتائج لكل عضو من قوائم منسدلة (بعضها متعدد الاختيار)، وتُحمَّل القوائم من جداول lapar*/copy* عبر getselect، ويمكنه إضافة مصطلح جديد للقائمة فورًا عبر getselectajax أو حذف مصطلح عبر deldataselect.
5. في الصف الثاني لكل منظار يسجّل الطبيب التدخل الجراحي النصّي (lapintervention/hysintervention) والإدارة العلاجية لكل عضو (قوائم laparm*/copym*) والتكلفة (coast).
6. شاشة العمليات (operations.php) تعرض مناظير اليوم أو نتائج بحث بفترة/مريضة، بالربط بين laparoscopyinfertility/hysteroscopyinfertility وجدول infertilitysheet لجلب بيانات المريضة، وتسجّل آخر زيارة في lastvisit.
7. عند الطباعة أو التقارير: sh.php وCompletesreport.php يفكّان معرّفات CSV إلى نصوصها من جداول القوائم، وcompletereport.php يضم سجلات المناظير الحرة (غير الفارغة فقط) مع اسم الطبيب من awusers، وfullreport.php يفحص وجود مناظير في الفترة المطلوبة.
8. في موديول تفاصيل العمليات (operativedetails.php) تُستخدم قائمتا jncision وmidlinejncision كقائمتين متسلسلتين (اختيار نوع الشق يحمّل أنواعه الفرعية عبر loadjncision)، مع إمكانية إضافة أنواع جديدة من الشاشة نفسها.

الارتباط بالموديولات الأخرى

• موديول المرضى (patients): عبر laparoscopy.patientid وhysteroscopy.patientid.
• موديول المستخدمين/الأطباء (awusers): عبر doctorid → awusers.user_id لعرض اسم الطبيب في التقارير.
• موديول شيت العقم (infertilitysheet): عبر laparoscopyinfertility.infertilitysheetid وhysteroscopyinfertility.infertilitysheetid، وتُعرض البيانات أيضًا داخل شيت النساء (gynasheet) للمريضة نفسها.
• موديول الفحوصات (investigation): تبويبا المناظير جزء من شاشة الفحوصات إلى جوار HSG وUS-TV وMRI/CT.
• موديول العمليات وتقاريرها (operations / operativedetails): شاشة Operations تجمع المناظير مع العمليات الأخرى، وقائمتا jncision/midlinejncision تُستخدمان في تفاصيل العمليات عبر operativedetails.jncisionid وoperativedetails.midlineid.
• موديول التقارير (completereport / Completesreport / fullreport / sh): إدراج نتائج المناظير في التقارير المطبوعة والشاملة.
• تتبّع الزيارات (lastvisit): تسجيل آخر شاشة فتحت لملف المريضة عبر lastvisit.patientid.

ملاحظات فنية

• ازدواجية تمثيل البيانات: نفس الإجراء السريري يُسجَّل بنمطين منفصلين تمامًا (جدولا laparoscopy/hysteroscopy النصّيان مقابل laparoscopyinfertility/hysteroscopyinfertility المنظّمين) دون أي ربط بينهما.
• الاختيار المتعدد مخزَّن كسلسلة CSV من المعرّفات داخل حقل varchar واحد (مثل copycx، laparrt) ويُفكّ بعبارة id in (0$csv) المبنية بدمج نصّي مباشر — مخالف للتطبيع وعرضة لحقن SQL.
• استعلامات شاشة العمليات تبني شرط البحث بدمج متغيّرات الطلب نصيًا (patientid، التواريخ) — ثغرة حقن SQL مؤكدة في operations.php.
• كود operations.php يستعلم عن laparoscopy/hysteroscopy بعمود date غير الموجود (العمود الفعلي sdate) ثم يقرأ منهما infertilitysheetid غير الموجود أيضًا — كود ميت/معطّل على الأرجح (استنتاج).
• تناقض دلالة الحذف المنطقي: قوائم الشيت تُحمَّل بشرط del is null بينما السجلات الرئيسية بشرط del = 0، والحذف يضع del = 1 — خليط يصعب صيانته.
• جداول القوائم الـ 26 (lapar*/copy*) متطابقة البنية (id, title, del) وفارغة من البذور في النسخة الاحتياطية؛ المفردات السريرية تُبنى أثناء التشغيل من إدخالات الأطباء.
• بيانات jncision/midlinejncision مليئة بصفوف تجريبية مهملة (sss، wwwaa، 444...) معظمها بحذف منطقي، مع خطأ إملائي متعمد في الاسم (jncision بدل incision وpfnnestiel بدل Pfannenstiel).
• حقل التكلفة اسمه coast (خطأ إملائي لـ cost) ونوعه varchar وليس رقميًا، وحقل date في جداول العقم varchar وليس date.
• أكشن update العام يقبل اسم الجدول والعمود من الطلب مباشرة دون قائمة سماح — يمكّن تعديل أي جدول في قاعدة البيانات (ثغرة Mass Assignment).
• إنشاء سجلات مناظير فارغة تلقائيًا عند فتح شاشة الفحوصات يولّد بيانات وهمية، وتضطر التقارير لترشيحها بشرط «غير فارغ» في completereport.php.

توصيات النقل إلى ERP

• توحيد النمطين في نموذج واحد: جدول endoscopy_procedures (Model: EndoscopyProcedure) بحقول: patient_id, infertility_sheet_id (اختياري), type (laparoscopy/hysteroscopy), performed_at, place_id, intervention, cost (decimal), notes, doctor_id.
• تطبيع النتائج لكل عضو في جدول تفصيلي endoscopy_findings (Model: EndoscopyFinding) بحقول: procedure_id, site (uterus/right_tube/left_tube/right_ovary/left_ovary/pelvis/cervix/cavity/r_ostium/l_ostium/dilatation/introduction), finding_term_id, category (finding/management) — بدلًا من 26 عمود CSV.
• دمج جداول القوائم الـ 26 المتطابقة في جدول معجم واحد endoscopy_terms (Model: EndoscopyTerm) بحقول scope (laparoscopy/hysteroscopy)، site، category، title، is_active، مع علاقة many-to-many عبر جدول pivot بدل CSV.
• نقل jncision/midlinejncision إلى موديول العمليات كجدول incision_types ذاتي العلاقة (parent_id) مع تنقية الصفوف التجريبية المهملة وتصحيح الأسماء قبل الترحيل.
• اعتماد Soft Deletes القياسية في Laravel (deleted_at) بدل خليط del = 0/1/null، وتحويل coast إلى cost decimal(10,2) وdate النصّي إلى date حقيقي مع تنظيف الصيغ أثناء الترحيل.
• استبدال أكشن update العام بـ API Resources مخصصة مع Form Requests للتحقق وقوائم سماح للحقول، وإلغاء الإنشاء التلقائي للسجلات الفارغة (إنشاء السجل فقط عند الحفظ الفعلي).
• أثناء الترحيل: استيراد سجلات laparoscopy/hysteroscopy غير الفارغة فقط (بنفس منطق ترشيح التقرير الشامل)، وتفكيك حقول CSV إلى صفوف findings مع الحفاظ على المصطلحات المرجعية.
• إعادة بناء تقرير العمليات في Angular كشاشة موحدة تستعلم من endoscopy_procedures مباشرة، بما يصحح الكود المعطّل الحالي في operations.php.

الوظائف الرئيسية

• قائمة انتظار العمليات (Operation Waiting List): إضافة مريضة بتاريخ العملية ونوع العملية (متعدد الاختيار) ومكان الإجراء مع ملاحظات، وعرض القائمة مجمّعة حسب اليوم بأسماء الأيام بالعربية، مع تعديل وحذف منطقي وتتبع المستخدم المُدخل.
• تسجيل المذكرة الجراحية التفصيلية لكل مريضة: نوع العملية، التاريخ ووقت البداية والنهاية، دواعي الإجراء (Indication)، نوع التخدير الرئيسي والفرعي (قوائم متسلسلة)، أطباء التخدير والمساعدون (فريقان)، نوع الشق الجراحي (Incision) ونوعه الفرعي، الغسيل البريتوني، خطوات العملية، الطبقات والدرنقة والخيوط الجراحية، نقل الدم، المضاعفات والتوصيات.
• تسجيل أدوية العملية في شبكة (Grid) مرتبطة بكتالوج الأدوية، مع توليد روشتة تلقائية في الصيدلية (recepittmp / receiptdrugs) لتمكين الصرف والتحصيل المالي.
• إضافة عناصر القوائم المرجعية أثناء العمل مباشرة (عملية جديدة، نوع تخدير، نوع شق جراحي، مستشفى) دون مغادرة الشاشة.
• تقرير العمليات اليومي مع البحث بالفترة والمريضة، ويشمل عمليات شيت العقم (Operations / Hysteroscopy / Laparoscopy) مع نتيجة الأنسجة والتكلفة ومكان الإجراء، وطباعته.
• تقرير الولادات اليومي (Deliveries): يعرض ولادات اليوم من سجل الحمل (awifep) مع طريقة الولادة ومكانها (place2) وبيانات التسجيل، مع البحث والطباعة.
• تقرير إنهاء الحمل (Termination): استعلام عن حالات الولادة حسب نوع الإنهاء (طبيعي / قيصري / إجهاض ...) من السجل الوبائي للولادات السابقة phobstetric.
• خطاب تحويل المريضة إلى مستشفى: اختيار المستشفى من hospitalnames وتعليمات العملية وطباعة خطاب يتضمن الصيغة التوليدية (G/P/Ab) المحسوبة آليًا.
• تسجيل نتائج الباثولوجيا للمريضة (Cytology / Histopathology) بتاريخ وطبيب من شاشة الفحوصات.
• قائمة انتظار السونار رباعي الأبعاد (4D) مرتبطة بشيت متابعة الحمل مع إرسال المريضة لقائمة زيارات اليوم برسوم كشف محددة.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. تُضاف المريضة إلى قائمة انتظار العمليات من شاشة operations.php?ac=waiting_list: يُحدد تاريخ العملية ونوع/أنواع العملية (تُخزن كمعرّفات مفصولة بفواصل في op_wait_list.operation) ومكان الإجراء من place مع الملاحظات، ويُسجل المستخدم وتاريخ الإدخال.
2. تُعرض قائمة الانتظار مجمعة باليوم (بأسماء الأيام العربية) خلال فترة محددة، أو قائمة العمليات المستقبلية لمريضة بعينها، مع إمكانية التعديل أو الحذف المنطقي (deleted = 1).
3. يوم العملية تُفتح شاشة المذكرة الجراحية operativedetails.php?ac=showdata للمريضة؛ يُنشئ النظام سجلًا فارغًا في operativedetails فور فتح الشاشة، ثم تُحفظ كل خانة عبر AJAX حقلًا بحقل (نمط Inline Edit).
4. يُختار نوع التخدير من anasthesa فتُحمَّل الأنواع الفرعية من generalanasthesa ديناميكيًا، وكذلك نوع الشق الجراحي من jncision ثم نوعه الفرعي من midlinejncision، ويُختار أطباء التخدير والمساعدون من مستخدمي النظام (awusers) حسب الدور والتخصص.
5. تُضاف أدوية العملية صفًا صفًا في operativedetailsdrugs؛ عند اختيار الدواء يُنشئ النظام تلقائيًا روشتة مؤقتة (recepittmp) وبنود صرف (receiptdrugs) في موديول الصيدلية، فإذا كانت الروشتة محصّلة (status=1) تُفتح روشتة جديدة.
6. تظهر العمليات الموجزة المسجلة في شيت العقم (operations المرتبط بـ infertilitysheet) في تقرير العمليات اليومي مع المنظار الرحمي والبطني، ويُبحث فيها بالفترة أو المريضة وتُطبع.
7. تقرير الولادات (Deliveries.php) يعرض ولادات اليوم من سجل awifep مع طريقة الولادة وبيانات التسجيل ومكان الولادة من place2، مع البحث والطباعة.
8. تقرير الإنهاء (termination.php) يستعلم عن سجل الولادات السابقة phobstetric حسب نوع إنهاء الحمل المختار ويعرض بيانات المريضات.
9. عند الحاجة لتحويل المريضة لمستشفى تُستخدم شاشة التحويل في instruction.php: اختيار المستشفى من hospitalnames وتعليمات العملية، ويُطبع خطاب يتضمن الصيغة التوليدية المحسوبة من سجلات الولادة.
10. تُسجل نتيجة الباثولوجيا بعد العملية في جدول pathology من شاشة الفحوصات (investigation.php) بتاريخ وطبيب.

الارتباط بالموديولات الأخرى

• موديول المرضى (Patients): عبر operativedetails.patientid وop_wait_list.patientid وpathology.patientid.
• موديول العقم (Infertility Sheet): جدول operations مرتبط بـ infertilitysheetid ويُعرض ضمن شيت العقم وتقاريره.
• موديول الصيدلية (Pharmacy): أدوية العملية تنشئ روشتات عبر operativedetailsdrugs.recepittmpid → recepittmp وrecepitdrugid → receiptdrugs، والأدوية من كتالوج drugs.
• موديول الزيارات والمالية (Visits): إرسال مريضة 4D لقائمة الزيارات ينشئ سجل visits برسوم من detections (المعرّف 36 ثابت بالكود).
• موديول متابعة الحمل (Antenatal): تقرير الولادات يقرأ awifep وregisteration (مكان الولادة من place2) وancsheet لقائمة 4D.
• موديول التاريخ المرضي (History): تقرير الإنهاء يقرأ phobstetric.obstermination، وخطاب التحويل يحسب الصيغة التوليدية منه.
• المستخدمون والصلاحيات (awusers/awrole): فريق العملية (تخدير/مساعدون) يُختار من awusers حسب role_id وspecialid بقيم ثابتة في الكود.

ملاحظات فنية

• لا توجد مفاتيح أجنبية معلنة إطلاقًا؛ جميع العلاقات استُنتجت من أسماء الأعمدة واستعلامات الكنترولرات.
• تعدد القيم يُخزن كنصوص مفصولة بفواصل (CSV) في op_wait_list.operation وoperations.operation وoperations.histopath وحقول فريق العملية الأربعة في operativedetails — يكسر التطبيع ويمنع الاستعلام السليم.
• جدول operation يحتوي عمودين title وname يُستخدمان بالتبادل في شاشات مختلفة (قائمة الانتظار تقرأ title والمذكرة الجراحية تقرأ name) — مصدر محتمل لبيانات غير متسقة.
• جدول operationids غير مستخدم في أي كنترولر أو عرض — جدول مهجور قابل للإسقاط.
• ازدواجية القوائم المرجعية: place (أماكن العمليات) وplace2 (أماكن الولادة) بنفس البنية تمامًا، إضافة إلى copyplace وlaparplace في موديولات مجاورة.
• أنواع بيانات ضعيفة: operations.date وoperations.cost نصوص varchar، وpathology.patientid varchar بينما بقية الجداول int.
• حقن SQL محتمل: تمرير patientid وparentid وtermtype بالتسلسل النصي مباشرة في الاستعلامات (operations.php و operativedetails.php و termination.php).
• فتح شاشة المذكرة الجراحية يُنشئ سجلًا فارغًا فورًا، ما يولّد سجلات يتيمة عند إغلاق الشاشة دون إدخال.
• قيم ثابتة بالكود (Hardcoded): معرّف خدمة 4D = 36 في sendToVisits، وأدوار/تخصصات الفريق الجراحي (role_id 4/6 و specialid 1-4)، ودلالات نوع الإنهاء (1 = ولادة طبيعية، 2 = قيصرية).
• أسلوبا حذف منطقي مختلطان: del (NULL/0/1) في القوائم المرجعية مقابل deleted (0/1) في جداول الحركة.
• بيانات القوائم المرجعية المزروعة في النسخة تحتوي قيم تجريبية مهملة (مثل صفوف jncision: "sss"، "www") محذوفة منطقيًا فقط.

توصيات النقل إلى ERP

• إنشاء نماذج Laravel أساسية: SurgicalBooking (بديل op_wait_list)، OperativeNote (بديل operativedetails)، OperativeNoteDrug، InfertilityOperation (بديل operations)، PathologyResult، مع قوائم مرجعية: Procedure، AnesthesiaType/AnesthesiaSubtype، IncisionType/IncisionSubtype، Hospital، HistopathologyFinding.
• تطبيع كل الحقول متعددة القيم (CSV) إلى جداول Pivot: booking_procedures، operation_procedures، operation_histopath_findings، وoperative_note_staff (بعمود دور: anesthetist / assistant) بدلاً من أربعة أعمدة CSV.
• توحيد place وplace2 (ومثيلاتهما copyplace وlaparplace) في جدول واحد locations بعمود نوع (مكان عملية / مكان ولادة)، وتوحيد عمودي title/name في جدول العمليات المرجعي إلى عمود واحد مع ترحيل القيمتين.
• إسقاط جدول operationids المهجور بعد التحقق من خلو بياناته الإنتاجية، وتنقية صفوف الاختبار المحذوفة منطقيًا في القوائم المرجعية قبل الترحيل.
• تحويل الأنواع: date إلى نوع تاريخ حقيقي، وcost إلى decimal، وpatientid في pathology إلى مفتاح أجنبي رقمي، مع إعلان قيود المفاتيح الأجنبية كاملة.
• استبدال نمط "إنشاء سجل فارغ عند فتح الشاشة + حفظ حقل بحقل" بنموذج إدخال يُحفظ دفعة واحدة عبر Form Request مع Validation، أو مسودة صريحة بحالة (draft/final).
• نقل تكامل الصيدلية إلى خدمة (Service) موحدة لإنشاء الروشتات بدل المنطق المكرر داخل الكنترولر، وربط أدوية العملية بوحدة المخزون/الفوترة في الـ ERP بأحداث (Events).
• نقل القيم الثابتة (رسوم 4D، أدوار الفريق، أنواع الإنهاء) إلى جداول إعدادات أو Enums معرفة بدل أرقام مزروعة في الكود.
• توحيد الحذف المنطقي باستخدام SoftDeletes القياسية في Laravel (deleted_at) في جميع الجداول.
• في واجهة Angular: فصل الشاشات إلى مكونات (قائمة الانتظار، المذكرة الجراحية بقوائم متسلسلة، تقارير العمليات/الولادات) مع APIs REST موثقة بدلاً من قوالب Smarty المختلطة.

الوظائف الرئيسية

• تسجيل عدة فحوصات عامة للمريضة الواحدة مرتبة تنازليًا بالتاريخ، مع تسجيل اسم الطبيب الفاحص من جدول المستخدمين awusers.
• إضافة صف فحص جديد فارغ فورًا عبر AJAX (addNewRow)، ثم تعبئة كل خلية على حدة بالحفظ التلقائي الفوري (Inline AJAX update) دون زر حفظ.
• حساب مؤشر كتلة الجسم (BMI) تلقائيًا في الواجهة من الوزن والطول، مع قناع إدخال لضغط الدم (حقلان: b_p وbp2).
• إدخال نتيجة فحص كل جهاز إما كنص حر أو من قائمة منسدلة معرّفة مسبقًا، حسب أعلام التهيئة (head, chest, abdomen, pelvis, extremitis) في جدول programesetting.
• إضافة قيمة جديدة لقوائم نتائج الفحص أثناء العمل مباشرة (addexitem) مع ربطها فورًا بسجل الفحص الجاري.
• حذف منطقي (Soft Delete) لسجلات الفحص عبر العلم del.
• إدارة بنك أسئلة التاريخ المرضي الحالي (presenthistoryquestions) وإجاباتها (presenthistoryanswers) من شاشة إعداد مستقلة، مع ترتيب عرض الأسئلة (displayorder) وتمييز إجابات مفضلة (favorite).
• تسجيل إجابات المريضة على أسئلة التاريخ المرضي بتاريخ زيارة محدد من شاشة الجيناكولوجي (تُخزن في جدول gynaph) مع إمكانية الطباعة والاستعراض حسب التاريخ.
• كتالوج تشخيصات لزيارات النساء (diagnosis) وآخر لزيارات متابعة الحمل (diagnosisant)، مع اختيار متعدد يُخزن كقائمة مفصولة بفواصل في حقل الزيارة، وإضافة تشخيص جديد أثناء الزيارة.
• قوائم نتائج الفحص الموضعي والعام (الثدي متعدد الاختيار، الشعرانية، الغدة الدرقية، الفحص الموضعي) تُستخدم في شيتات العقم والجيناكولوجي وتُخزن في أعمدة جدول infertilitysheet.
• كتالوج تفاصيل التخدير العام (generalanasthesa) كمستوى فرعي تابع لنوع التخدير (anasthesa) ويُستخدم في شاشة تفاصيل العمليات.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يفتح الطبيب ملف المريضة ثم تبويب الفحص (examination.php?ac=index)؛ تُعرض جميع سجلات الفحص السابقة (غير المحذوفة) مرتبة بالتاريخ تنازليًا مع اسم الطبيب لكل سجل.
2. تقرأ الشاشة إعدادات programesetting؛ فإذا كان علم الجهاز (رأس/صدر/بطن/حوض/أطراف) لا يساوي 1 تُحمَّل قائمته المنسدلة من جدول اللوكب المقابل، وإلا يظهر حقل نص حر.
3. عند الضغط على "إضافة" يُنشأ صف فحص فارغ فورًا في قاعدة البيانات (addNewRow) بتاريخ اليوم ومعرف الطبيب من الجلسة، ويُعاد جزء HTML للصف الجديد.
4. تُحفظ كل خلية (وزن، طول، ضغط، نبض، نتيجة كل جهاز...) تلقائيًا عند مغادرتها عبر دالة update العامة التي تستقبل اسم الجدول والعمود والقيمة من الواجهة، ويُحسب الـ BMI تلقائيًا في المتصفح.
5. يمكن إضافة قيمة جديدة لأي قائمة نتائج أثناء الفحص (addexitem)؛ تُدرج في جدول اللوكب ثم يُحدَّث عمود سجل الفحص بمعرف القيمة الجديدة.
6. الحذف يتم منطقيًا بوضع del = 1 (delData).
7. في شاشة الإعداد addpresenthistory.php يُدير المسؤول أسئلة التاريخ المرضي الحالي وإجاباتها: إضافة سؤال (يأخذ ترتيب عرض تاليًا تلقائيًا)، إضافة إجابات لكل سؤال، تمييز مفضلة، وحذف منطقي.
8. أثناء زيارة الجيناكولوجي (كنترولر gyna.php) تُعرض الأسئلة في أعمدة حسب displayorder (مجموعات 1-3، 4-6، 7-9، 10-12، أكبر من 12، وصفر = أخرى)، وتُحفظ الإجابات المختارة لكل تاريخ في جدول gynaph مع معرف المريضة والطبيب، مع إمكانية الطباعة والحذف حسب التاريخ.
9. في زيارة النساء يختار الطبيب تشخيصات متعددة من كتالوج diagnosis فتُخزن معرفاتها كنص مفصول بفواصل في gyna.diagnosisid؛ وبنفس الآلية تُخزن تشخيصات diagnosisant في antenalvisit.diagnosisid لزيارات الحمل، مع إمكانية إضافة تشخيص جديد للكتالوج أثناء الزيارة.
10. في شيتات العقم والجيناكولوجي تُختار نتائج فحص الثدي والشعرانية والدرقية والفحص الموضعي من قوائم generalbreast وgeneralhirsutism وgeneralthyroid وexaminationlocalse وتُخزن في أعمدة جدول infertilitysheet، وتُفك ترميزها عند طباعة التقارير الكاملة (sh.php, Completesreport.php).

الارتباط بالموديولات الأخرى

• موديول المرضى: examination.patientid → patients.id.
• موديول المستخدمين والصلاحيات: examination.doctorid → awusers.user_id، مع فحص الصلاحيات عبر role_id في الجلسة.
• موديول إعدادات البرنامج: أعلام programesetting.head/chest/abdomen/pelvis/extremitis تتحكم في إظهار القوائم المنسدلة مقابل النص الحر.
• موديول زيارات النساء (Gyna): gyna.diagnosisid → معرفات diagnosis (CSV)، وgynaph.catid/answerid → presenthistoryquestions/presenthistoryanswers.
• موديول متابعة الحمل (Antenatal): antenalvisit.diagnosisid → معرفات diagnosisant (CSV).
• موديول شيت العقم: أعمدة infertilitysheet.generalbreast/generalhirsutism/generalthyroid/examinationlocalse → جداول اللوكب المقابلة.
• موديول العمليات: generalanasthesa.anasthesaid → anasthesa.id، وتُستهلك في operativedetails.php.
• موديول التقارير: sh.php وCompletesreport.php وcombinedreport.php تفك ترميز معرفات الفحص والتشخيص للطباعة.
• موديول الإعداد العام: setup.php يصنف diagnosis وdiagnosisant ضمن الجداول المسموح تفريغها، بينما generalanasthesa محمي من الحذف.

ملاحظات فنية

• لا توجد مفاتيح أجنبية معلنة إطلاقًا؛ كل العلاقات مستنتجة من أسماء الأعمدة واستعلامات الكنترولرات.
• examination.patientid من نوع varchar(191) بينما patients.id رقمي — عدم تطابق أنواع.
• جميع القيم السريرية الرقمية (الوزن، الطول، BMI، الضغط، النبض) والتواريخ مخزنة كـ varchar بلا أي تحقق من الصحة.
• أعمدة فحص الأجهزة في examination تخزن محتوى مختلطًا: نصًا حرًا أحيانًا ومعرف لوكب رقميًا أحيانًا أخرى (دالة addexitem تكتب المعرف في نفس العمود النصي) — خطر جسيم على جودة البيانات عند الترحيل.
• الاختيار المتعدد (التشخيصات، الثدي، الفحص الموضعي) يُخزن كنص مفصول بفواصل (CSV) داخل عمود واحد — مخالف للتطبيع الأول (1NF) ويستلزم جداول وسيطة عند الترحيل.
• عمود conditions في diagnosis/diagnosisant يُستخدم فعليًا كعلم حذف منطقي (1 = محذوف) رغم اسمه المضلل، إلى جانب وجود عمود del آخر غير مستخدم في diagnosis.
• دالة examination::update() لا تتضمن أي فحص لتسجيل الدخول أو الصلاحيات، وتقبل اسم الجدول والعمود مباشرة من طلب POST — ثغرة تتيح تعديل أي جدول/عمود (Mass Assignment). كذلك delData وaddexitem يقبلان اسم الجدول من العميل.
• تقارير sh.php وCompletesreport.php تبني استعلامات SQL بدمج نصي مباشر (id in (0$var)) — سطح هجوم لحقن SQL.
• جدول gynaph (إجابات التاريخ المرضي الفعلية للمريضات) غير موجود في ملف الـ SQL Dump رغم استخدامه في الكود — يُنشأ غالبًا وقت التشغيل بواسطة RedBeanPHP في الوضع المرن (استنتاج).
• جداول اللوكب كلها فارغة في هذا الـ Dump (AUTO_INCREMENT=1)؛ المفردات السريرية الفعلية موجودة فقط في قاعدة بيانات الإنتاج.
• منطق تجميع أسئلة التاريخ المرضي في أعمدة العرض (1-3، 4-6...) مكتوب صراحة (Hardcoded) داخل gyna.php اعتمادًا على قيم displayorder.
• ازدواجية كتالوجات: diagnosis وdiagnosisant متطابقا البنية تقريبًا ومفترقان فقط حسب نوع العيادة.

توصيات النقل إلى ERP

• إنشاء موديل ClinicalExamination (جدول clinical_examinations) بمفاتيح أجنبية حقيقية patient_id وdoctor_id، وأنواع صحيحة: decimal للوزن والطول والـ BMI، أعمدة systolic/diastolic/pulse أعدادًا صحيحة، وdate لتاريخ الفحص، مع SoftDeletes.
• دمج جداول اللوكب الخمسة لفحص الأجهزة مع examinationlocalse وgeneralbreast وgeneralhirsutism وgeneralthyroid في جدول موحد examination_finding_options بعمود تمييز body_system (head_neck, chest_heart, abdomen, pelvis, extremities, local, breast, hirsutism, thyroid) بدلًا من تسعة جداول متطابقة البنية.
• إنشاء جدول وسيط examination_findings (examination_id, body_system, finding_option_id قابل للفراغ, free_text قابل للفراغ) لفصل النص الحر عن المعرفات، مع سكربت ترحيل ينظف المحتوى المختلط الحالي (رقم = معرف لوكب، غير ذلك = نص حر).
• دمج diagnosis وdiagnosisant في كتالوج واحد diagnoses بعمود specialty (gyna/antenatal)، واستبدال أعمدة CSV بجدول وسيط visit_diagnosis (morph أو visit_id + diagnosis_id)، مع التفكير في إسناد التشخيصات إلى ترميز ICD-10 مستقبلًا.
• ترحيل محرك التاريخ المرضي إلى ثلاثة موديلات: HistoryQuestion وHistoryAnswerOption (مع is_favorite) وPatientHistoryAnswer (يحل محل gynaph) بمفاتيح أجنبية لـ patient_id وvisit_date وdoctor_id، واستبدال منطق التجميع المكتوب صراحة بعمود display_group صريح.
• إنشاء AnesthesiaType وAnesthesiaSubtype (يحل محل anasthesa وgeneralanasthesa) بعلاقة belongsTo صريحة، ويُستهلك من موديول العمليات.
• توحيد الحذف المنطقي على deleted_at (Laravel SoftDeletes) بدلًا من الأعلام الثلاثة المتضاربة del وdeleted وconditions.
• فرض التحقق من الصحة (Form Requests) والتفويض (Policies) على جميع نقاط التعديل، وإلغاء نمط "اسم الجدول والعمود من العميل" نهائيًا واستبداله بنقاط API محددة الموارد (RESTful) في Laravel مع واجهات Angular Reactive Forms.
• الإبقاء على ميزة الحفظ التلقائي خلية-بخلية في واجهة Angular (PATCH على حقول مسماة بقائمة بيضاء) لأنها جوهرية في سير عمل العيادة.
• تصدير محتوى جداول اللوكب من قاعدة الإنتاج (وليس هذا الـ Dump الفارغ) قبل الترحيل لبناء بيانات الـ Seeders الخاصة بالمفردات السريرية.

الوظائف الرئيسية

• تسجيل سجلات متعددة لتاريخ الدورة الشهرية لكل مريضة: سن البلوغ menarche، مدة الدورة، طول الدورة، الانتظام، كمية الطمث، عسر الطمث، وتاريخ آخر دورة phl_mp (LMP) المستخدم في حسابات الحمل.
• تسجيل وسائل منع الحمل السابقة (نوع الوسيلة، المدة، تاريخ الإيقاف، ملاحظات).
• توثيق تاريخ الولادات السابقة (Obstetric History): مدة الحمل، طريقة انتهاء الحمل (ولادة طبيعية/قيصرية/إجهاض/حمل خارج الرحم/حمل عنقودي)، مكان الولادة، التاريخ، وبيانات حتى 3 أطفال لكل حمل (النوع، الجنس، الوزن، الاسم) لدعم التوائم.
• حساب الصيغة التوليدية (عدد القيصريات/الطبيعي/الإجهاض/الحمل خارج الرحم) تلقائياً وعرضها في رأس بيانات المريضة في كل الشاشات.
• تسجيل الأمراض الطبية السابقة والعمليات الجراحية العامة والعمليات النسائية السابقة مع السنة واسم الجرّاح والملاحظات.
• توثيق محاولات الإخصاب المساعد السابقة (IUI/IVF/ICSI/تجميد) مع المركز والسنة، وتفاصيل معملية لكل محاولة ICSI: عدد البويضات المسحوبة opu، درجات البويضات GI/GII/GV، عدد الأجنة المنقولة، الأجنة المجمدة، نتيجة تحليل الحمل bhcg، ونبض الجنين fhr.
• عرض دورات التنشيط الداخلية المكتملة (Monitoring Sheets) داخل صفحة التاريخ كجزء من تاريخ ART الداخلي.
• تسجيل التاريخ العائلي (المرض + صلة القرابة + ملاحظات).
• إضافة قيم جديدة لقوائم الاختيار (الانتظام، كمية الطمث، أنواع منع الحمل، أنواع العمليات، مراكز الإخصاب... إلخ) مباشرة من نفس الشاشة دون مغادرتها (inline lookup creation)، مع تعديل أسماء عناصر القوائم.
• التحرير الخلوي المباشر (inline cell editing) لأي حقل عبر دالة update عامة تستقبل اسم الجدول والعمود من الواجهة.
• حذف منطقي (soft delete) لأي سجل تاريخ عبر العلم del.
• وضع عرض مبسّط بديل (Simple View) يعرض تشخيصات مبسطة بدلاً من نموذج التاريخ الكامل حسب إعدادات البرنامج، مع إمكانية إظهار/إخفاء كل قسم من أقسام التاريخ من جدول الإعدادات.
• إدارة بنك أسئلة "الشكوى الحالية" (Present History) كقوائم أسئلة وإجابات مع ترتيب عرض ومفضلة، تُستهلك في شيتات الكشف.
• تصدير بيانات التاريخ المرضي تلقائياً إلى ملف Excel خارجي عند فتح الصفحة (عبر exec لتشغيل excel.php).

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يفتح الطبيب صفحة «Patient History» (patienthistory.php) بعد اختيار المريضة؛ إذا لم تُحدد مريضة يُعاد التوجيه للصفحة الرئيسية.
2. حسب إعداد programesetting.simpleview يُعرض إما نموذج مبسّط (تشخيصات بسيطة) أو النموذج الكامل بسبعة أقسام: الدورة الشهرية، منع الحمل، الولادات، الأمراض السابقة، الجراحات، العمليات النسائية، محاولات ART، والتاريخ العائلي، مع تحميل كل قوائم الاختيار وسجلات المريضة السابقة لكل قسم.
3. عند الضغط على «إضافة صف» في أي قسم تُستدعى دالة AJAX (مثل addnewmenstural, addnewobstetric, addnewpastart...) تنشئ فوراً سجلاً فارغاً في قاعدة البيانات مرتبطاً بالمريضة والطبيب الحالي بتاريخ اليوم، وتُعيد صف HTML جديداً (قالب Smarty جزئي مثل newMenstrualRow.html).
4. يملأ الطبيب الحقول مباشرة داخل الجدول؛ كل تغيير في خلية يستدعي الدالة العامة update التي تستقبل اسم الجدول والعمود والقيمة وتحفظ مباشرة (حفظ خلوي لحظي بدون زر حفظ).
5. في قسم ART، عند إدخال تفاصيل معملية لمحاولة IVF/ICSI تُنشأ/تُحدّث تلقائياً سجلة ابنة في phpasticsi مربوطة بـpartentid، كما تُعرض دورات التنشيط الداخلية المكتملة من mointoringsheet ضمن نفس القسم.
6. إذا لم تكن القيمة المطلوبة موجودة في قائمة الاختيار، يضيفها المستخدم من نفس الشاشة فتُحفظ في جدول القائمة (مثل phcontracttype) ويُحدَّث سجل المريضة فوراً بالمعرف الجديد؛ ويمكن أيضاً تعديل اسم عنصر قائمة عبر editselect/updateselect.
7. الحذف يتم منطقياً برفع العلم del=1 عبر delRows.
8. عند فتح الصفحة تُسجَّل المريضة في قائمة تصدير Excel (excelinfopatients) ويُشغَّل سكربت excel.php في الخلفية لتصدير بياناتها.
9. ملخص التاريخ (آخر دورة LMP، الصيغة التوليدية المحسوبة من phobstetric بمعرّفات ثابتة للقيصرية/الطبيعي/الإجهاض...) يُعرض في رأس بيانات المريضة (_patientdata.php/_phmain.php) في كل شاشات الكشف والشيتات.
10. بشكل منفصل، شاشة addpresenthistory.php تُدير بنك أسئلة «الشكوى الحالية» (presenthistoryquestions/presenthistoryanswers) بترتيب عرض ومفضلة، وتُستهلك إجاباتها في شيتات الكشف.

الارتباط بالموديولات الأخرى

• موديول المرضى (patients): كل جداول السجلات ترتبط بالمريضة عبر patientid، وتقرير الإنهاءات يربط phobstetric.patientid بجدول patients مباشرة.
• موديول المستخدمين/الأطباء (awusers): كل سجل يحمل doctorid الذي يُترجم لاسم الطبيب عبر awusers.user_id.
• موديول شيت العقم (infertilitysheet): الكتالوجات medicalhistory, medicalhistorydm, surgicalhistory, surgicalhistorydm, familyhistory تُخزَّن كقوائم معرفات مفصولة بفواصل داخل أعمدة infertilitysheet وتُفك في التقارير (sh.php, Completesreport.php).
• موديول متابعة التنشيط (mointoringsheet): صفحة التاريخ تعرض الدورات المكتملة (status=1) عبر mointoringsheet.patientid كتاريخ ART داخلي.
• موديول الزيارات والشيتات (gynasheet, infertilitysheet, ancsheet, antenalvisit): تعرض ملخص التاريخ عبر _phmain.php و_patientdata.php (آخر LMP والصيغة التوليدية).
• موديول التقارير (fullreport, completereport, combinedreport, termination, excel): يقرأ جداول ph* لطباعة التقرير الكامل وتقرير الإنهاءات والتصدير إلى Excel.
• موديول دمج المرضى (merge.php): ينقل كل سجلات ph* من المريضة المكررة إلى الأصلية عند الدمج.
• موديول الإعدادات (programesetting): أعلام إظهار/إخفاء أقسام التاريخ (menstrual, contraception, obstetric, past, family, art...) ووضع simpleview ومسار PHP لتصدير Excel.
• موديول الشكوى الحالية: presenthistoryquestions/presenthistoryanswers عبر presenthistorycatid (يُدار من addpresenthistory.php ويُستهلك في شيتات الكشف).

ملاحظات فنية

• لا توجد مفاتيح أجنبية معلنة إطلاقاً؛ كل العلاقات ضمنية، وكثير من أعمدة الربط نصية varchar بدلاً من int (مثل phmenstrual.patientid وphobstetric.obstermination).
• ازدواجية كتالوجات: يوجد كتالوجان منفصلان للأمراض (phpastmedicaldisease مقابل medicalhistory) وللجراحات وللتاريخ العائلي — أحدهما لشاشة التاريخ والآخر لشيت العقم — بنفس المعنى السريري تقريباً.
• جداول شيت العقم تخزن المعرفات كقوائم نصية مفصولة بفواصل (comma-separated IDs) وتُفك بـid IN (0$list) عبر حقن نص مباشر في SQL — مخاطرة أمنية وتصميم غير معياري.
• دوال update وdelRows تستقبل اسم الجدول والعمود من المتصفح مباشرة وتمررها إلى ORM دون قائمة سماح (whitelist) — ثغرة تتيح تعديل أي جدول؛ ودالة delRowsommedel بلا أي تحقق من الجلسة.
• منطق الصيغة التوليدية في _patientdata.php يعتمد على معرّفات ثابتة مكتوبة في الكود (1=SVD، 2=CS، 3=Ectopic، 4=Abortion، 5=V.mole) رغم أن القائمة قابلة للتعديل من المستخدم.
• phobstetric غير معياري: بيانات حتى 3 أطفال في أعمدة مكررة (babytype, babytype1, babytype2...) بدل جدول أطفال مستقل، وعمود outcomeid يقلب babygendernew بمنطق خاص.
• الكود يقرأ أعمدة غير موجودة في مخطط 2024 (phpastart.ovdate, freezdate, phpasticsi.notes) — تُنشأ ديناميكياً بواسطة RedBeanPHP في وضع fluid (استنتاج)، ما يدل على انجراف مخطط غير موثق.
• عمود patientid داخل جدول القائمة phobstericterplace شاذ ولا يُستخدم في الكود المقروء.
• التواريخ مخزنة كـvarchar في معظم الجداول (sysdate, obsdate) ما يضعف الفرز والاستعلام، وسنوات العمليات نصوص حرة.
• بيانات القوائم في نسخة 2024 فارغة بينما نسخة 2021 تحتوي القيم الفعلية، مع تلوث واضح بقيم تجريبية محذوفة منطقياً (aaaa, 777...) وقيم مكررة (DM ثلاث مرات في familyhistory).
• إنشاء الصف الفارغ في قاعدة البيانات قبل إدخال أي بيانات (insert-then-edit) يترك سجلات فارغة كثيرة إذا تراجع المستخدم.
• استدعاء exec() لتشغيل تصدير Excel عند كل فتح للصفحة — عبء أداء ونمط غير آمن.

توصيات النقل إلى ERP

• إنشاء موديولات Laravel واضحة لكل قسم: MenstrualHistory, ContraceptionHistory, ObstetricHistory (+ جدول ابن ObstetricBaby يلغي الأعمدة المكررة الثلاثية), PastMedicalHistory, PastSurgicalHistory, PastGynecologicalHistory, PastArtCycle (+ PastArtIcsiDetail أو دمجها كأعمدة في نفس الجدول), FamilyHistory — جميعها بمفتاح أجنبي حقيقي patient_id وdoctor_id.
• توحيد القوائم في جدول مرجعي واحد متعدد الأنواع lookup_values (type + name + is_active) أو جداول Eloquent صغيرة، مع دمج الكتالوجات المزدوجة: medicalhistory مع phpastmedicaldisease، وsurgicalhistory مع phpastsurgicaloperation، وfamilyhistory مع phfamilydisease.
• استبدال أعمدة القوائم المفصولة بفواصل في شيت العقم بجداول pivot معيارية (many-to-many) مثل infertility_sheet_medical_histories مع تمييز الزوج/الزوجة بعمود for_husband بدلاً من جداول *dm منفصلة.
• تحويل كل التواريخ إلى أعمدة date/timestamp حقيقية، وتحويل أعمدة الربط النصية إلى unsignedBigInteger مع قيود مفاتيح أجنبية، واستخدام softDeletes القياسية بدل العلم del.
• استبدال جدول phobstericterminate القابل للتعديل بـEnum ثابت (SVD/CS/Ectopic/Abortion/V.mole) لأن منطق الصيغة التوليدية يعتمد على هذه القيم؛ وحساب G/P في خدمة Domain Service مختبَرة بدل الاستعلامات المتناثرة.
• إغلاق الثغرات أثناء النقل: إلغاء أي endpoint عام يستقبل أسماء جداول/أعمدة من العميل، واعتماد Form Requests وValidation وPolicy لكل عملية، وإلغاء exec() لصالح Laravel Queue/Export (مكتبة Laravel Excel).
• تنقية البيانات قبل الترحيل: حذف صفوف القوائم التجريبية والمكررة، ودمج القيم المتطابقة، واستبعاد السجلات الفارغة الناتجة عن نمط insert-then-edit.
• نقل بنك أسئلة الشكوى الحالية إلى جدولي present_history_questions/present_history_answers بعلاقة hasMany مع ترتيب عرض ومفضلة.
• في واجهة Angular، الإبقاء على تجربة «الحفظ اللحظي للصف» لكنها عبر نماذج Reactive Forms مع إنشاء السجل عند أول حفظ فعلي (وليس عند فتح الصف) لتفادي السجلات الفارغة.

الوظائف الرئيسية

• إنشاء ملف متابعة حمل تلقائياً عند أول دخول لشاشة المتابعة (سجل followup بحالة 0 = جارٍ) مع حساب EDD تلقائياً (LMP + 9 أشهر + 7 أيام) وتاريخ IVF (LMP + 9 أشهر − 7 أيام).
• تسجيل زيارات المتابعة الدورية: الوزن، ضغط الدم، عمر الحمل GA (يُحسب بالأسابيع من LMP)، نتيجة الموجات فوق الصوتية، وملاحظات — مع تنبيه إذا كان تاريخ الزيارة أقدم من LMP.
• إضافة صفوف تشخيص وفحص إكلينيكي وتحاليل/أشعات مؤرخة عبر استدعاءات AJAX، مع تحرير خلوي مباشر (inline edit) لأي حقل وحذف منطقي (del = 1).
• كتابة روشتات أدوية داخل شاشة المتابعة (جدول followupdrugs يُنشأ وقت التشغيل) مع تمييز روشتة الزوجة عن الزوج (forhusband)، وعرض أرشيف الروشتات حسب التاريخ وطباعتها.
• أرشفة ملفات الحمل المنتهية (status = 1) وعرض تفاصيل أي حمل سابق كاملاً (زيارات/تشخيصات/فحوصات/تحاليل) من شاشة الأرشيف.
• إنشاء كارت متابعة لكل زيارة عيادة (followupcard) يلتقط تاريخ الدخول من آخر زيارة في جدول visits وقسم الكشف من detections واسم الطبيب من المستخدم الحالي.
• إضافة أدوية الكارت (followupcarddrugs) من كتالوج الأدوية مع النوع والجرعة، وعند اعتماد الكارت تُنشأ روشتة صيدلية تلقائياً (recepittmp + receiptdrugs) لتسعيرها وتحصيلها في الصيدلية.
• طباعة كارت المتابعة (التشخيص + الأدوية + بيانات المريضة والقسم) وإعادة طباعته لاحقاً دون إعادة إرساله للصيدلية.
• إدارة مكتبة تعليمات للمريضات (instruction: عنوان + محتوى نصي منسق) مع إضافة وتعديل وحذف منطقي، واختيار عدة تعليمات وطباعتها باسم المريضة وتاريخ اليوم.
• إصدار خطاب تحويل إلى مستشفى من نفس كنترولر التعليمات: يجمع بيانات الحمل الحالي من mainantenental والتاريخ الولادي والمرضي والجراحي، مع اختيار المستشفى وتعليمات العمليات وطباعة الخطاب.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. تدخل الممرضة/الطبيب شاشة المتابعة من ملف المريضة (followup.php?patientid=N)؛ إن لم يوجد ملف متابعة نشط (status = 0) يُنشأ تلقائياً بسجل followup جديد بقيمة LMP = اليوم، وتُحسب EDD وIVF، وتُضاف أول زيارة فارغة في followupvisit.
2. تُعرض الشاشة أربع قوائم مؤرخة (زيارات، تشخيصات، فحوصات، تحاليل) تنازلياً، ويُحسب عمر الحمل لكل زيارة بالأسابيع من LMP، مع تعليم الزيارات الأقدم من LMP كغير منطقية.
3. يضيف الطبيب صفوفاً جديدة عبر AJAX (newvisit/newdiag/newexam/newinv) ثم يحرر القيم خلية بخلية عبر دالة update العامة (اسم الجدول والعمود والقيمة تُرسل من المتصفح)، وتعديل LMP يعيد حساب EDD وIVF فوراً.
4. يكتب الطبيب روشتة اليوم من نفس الشاشة (تُحفظ في جدول followupdrugs غير الموجود بالـ dump — يُنشأ وقت التشغيل)، ويمكن عرض أرشيف الروشتات بالتواريخ منفصلة للزوجة والزوج وطباعة أي منها بقالب gyna/print.html.
5. عند انتهاء الحمل يُغلق الملف (status = 1) ويظهر في شاشة الأرشيف (archive)، ومن هناك تُفتح تفاصيل أي حمل سابق للقراءة عبر pregdetail.
6. بالتوازي، في كل زيارة عيادة يفتح الطبيب شاشة كارت المتابعة (followupcard.php?ac=addit)؛ يُنشأ كارت جديد (status = 0) يلتقط تاريخ آخر زيارة من visits وقسمها (detectionid)، ويُسجل التشخيص ويضاف الدواء سطراً سطراً من كتالوج drugs.
7. عند الحفظ/الطباعة (printit) يُعتمد الكارت (status = 1)، وتُحفظ الأدوية في followupcarddrugs، وتُنشأ روشتة مؤقتة في الصيدلية (recepittmp بمصدر drugstablename = followupcarddrugs) مع سطور receiptdrugs ليتم تحصيلها وصرفها من موديول الصيدلية، ثم يُطبع الكارت.
8. شاشة عرض الكروت (index) تُظهر كل الكروت المعتمدة للمريضة مع اسم الطبيب وقائمة الأدوية مجمعة، مع إمكانية إعادة الطباعة فقط (yesOnly) أو الحذف المنطقي.
9. في موديول التعليمات: تُدار مكتبة التعليمات (إضافة/تعديل/حذف منطقي عبر tempdelete)، ويختار المستخدم مجموعة تعليمات لطباعتها باسم المريضة ولقبها (من wifetypes) وتاريخ اليوم.
10. من نفس كنترولر التعليمات تُصدر خطابات التحويل للمستشفيات: تُجمع بيانات الحمل الحالي من mainantenental وآخر سونار من mainantenentalus والتاريخ المرضي/الجراحي/النسائي من جداول ph*، ويُختار المستشفى من hospitalnames وتعليمات العمليات من operationinstructions ثم يُطبع الخطاب.

الارتباط بالموديولات الأخرى

• موديول المرضى (patients): عبر followup.patientid وfollowupcard.patientid، مع قراءة ألقاب الزوجة/الزوج من wifetypes وhusbandtypes عند الطباعة.
• موديول الزيارات والاستقبال (visits / detections): followupcard.enterdate يُلتقط من آخر visits.visitdate، وfollowupcard.deptid من visits.detectionid (جدول أقسام الكشف detections).
• كتالوج الأدوية (drugs): عبر followupcarddrugs.drugid وfollowupdrugs.drugid، مع قراءة التصنيفات والأنواع والجرعات المميزة من نفس الجدول لملء القوائم.
• موديول الصيدلية (recepittmp / receiptdrugs): اعتماد كارت المتابعة ينشئ روشتة صيدلية كاملة عبر followupcarddrugs.recepittmpid وrecepittmp.drugstablename = 'followupcarddrugs' لتحصيلها لاحقاً.
• المستخدمون والصلاحيات (awusers / roles): followupcard.doctorid يشير إلى awusers.user_id، وكل دالة محمية بفحص الدخول والصلاحية حسب role_id.
• موديول متابعة الحمل الرئيسي (mainantenental / mainantenentalus): خطاب التحويل في كنترولر التعليمات يقرأ الحمل الحالي وبيانات السونار منهما (تداخل وظيفي مع موديول ANC).
• التاريخ المرضي (phobstetric / phpastmedical / phpastsurgical / phpastgynecological): تُجمع في خطاب التحويل لحساب G/P وسرد الأمراض والعمليات السابقة.
• إعدادات البرنامج (programesetting): تُقرأ في كل شاشات العرض والطباعة (ترويسة العيادة وبيانات الطباعة).

ملاحظات فنية

• جدول followupdrugs (روشتات شاشة المتابعة) مستخدم بكثافة في الكود لكنه غير موجود في ملف الـ SQL dump إطلاقاً — يُنشأ تلقائياً وقت التشغيل بواسطة RedBeanPHP في الوضع المرن (fluid)، وهذه فجوة خطيرة في توثيق المخطط يجب حصرها قبل الترحيل.
• دوال update وdel تستقبل اسم الجدول واسم العمود من المتصفح مباشرة وتكتب بهما عبر R::load — ثغرة Mass Assignment تتيح تعديل أي جدول في قاعدة البيانات من أي مستخدم مصرح له بالموديول.
• في instruction.php يُحذف السجل بسلسلة SQL مُركّبة نصياً: UPDATE instruction SET tempdelete = 1 WHERE id = ' . $id — ثغرة SQL Injection محتملة، وعدة دوال (مثل addopinst وgetinstdetail) فحوصات الصلاحية فيها معطلة بالتعليق.
• خطأ منطقي في followupcard.php سطر 270: استخدام = (إسناد) بدلاً من == داخل شرط if، فالشرط صحيح دائماً.
• instruction.patientid مكتوب ثابتاً بقيمة 1 عند الإضافة والتعديل — العمود بلا معنى فعلي والجدول عملياً مكتبة عامة غير مرتبطة بمريضة.
• لا توجد مفاتيح أجنبية معلنة في أي جدول؛ كل العلاقات استنتاجية من أسماء الأعمدة وكود الكنترولرات، وتتعدد أنماط الحذف المنطقي (del وdeleted وtempdelete وstatus).
• ازدواجية وظيفية واضحة: شاشة المتابعة followup تكاد تطابق موديول ANC الرئيسي (mainantenental وملحقاته) — نفس مفاهيم LMP/EDD/زيارات/روشتات، وكنترولر التعليمات يحتوي منطق تحويل مستشفيات لا علاقة له بالتعليمات.
• تواريخ EDD/IVF تُحسب بسلاسل strtotime نصية (LMP + 9 أشهر ± 7 أيام) بدلاً من قاعدة Naegele القياسية (LMP + 280 يوماً)، وعمر الحمل يُعاد حسابه في الكود ولا يُخزن إلا نصياً في followupvisit.ga.
• الجداول followupcard وfollowupcarddrugs بترميز latin1 بينما البقية utf8mb4 — خطر تلف النصوص العربية في حقل التشخيص.
• أخطاء قاعدة البيانات تُبتلع بصمت (catch فارغ) في معظم الدوال، ولا يوجد أي تسجيل (logging) أو تحقق من المدخلات.

توصيات النقل إلى ERP

• إنشاء موديل Laravel رئيسي Pregnancy (يدمج followup مع mainantenental في كيان واحد للحمل — استنتاج مدعوم بتطابق الحقول) بحقول: patient_id, lmp, edd, ivf_date, gravida, para, status (enum: active/closed) مع حساب EDD كـ Accessor بقاعدة Naegele.
• إنشاء موديل AntenatalVisit (يستوعب followupvisit) بحقول رقمية مُهيكلة: weight (decimal)، bp_systolic/bp_diastolic، gestational_age_weeks محسوب، ultrasound_notes، مع pregnancy_id كمفتاح أجنبي حقيقي.
• توحيد followupdiagnosis وfollowupexam وfollowupinvest في موديل واحد ClinicalNote بعمود type (enum: diagnosis/examination/investigation) لأن بنيتها متطابقة تماماً (followid + date + text + del)، أو ربط التشخيص بقاموس ICD-10 مستقبلاً.
• إنشاء موديل Encounter أو VisitCard (يحل محل followupcard) مرتبط بـ Visit وDepartment وUser بمفاتيح أجنبية معلنة، مع موديل Prescription + PrescriptionItem موحد يستبدل followupcarddrugs وfollowupdrugs وجداول الروشتات المتناثرة في باقي الموديولات (نمط مصدر واحد للروشتة يغذي الصيدلية عبر Event/Job بدلاً من الكتابة المباشرة في recepittmp).
• نقل instruction إلى موديل InstructionTemplate كمكتبة قوالب عامة (إسقاط عمود patientid العديم الفائدة)، وفصل منطق خطاب التحويل إلى خدمة مستقلة ReferralLetterService مع موديل Referral يؤرشف الخطابات الصادرة بدلاً من الطباعة دون أثر.
• استبدال التحرير الخلوي العام (tableName/colName من المتصفح) بـ API Endpoints محددة مع FormRequest Validation وPolicies لكل عملية، وإغلاق ثغرتي Mass Assignment وSQL Injection نهائياً.
• توحيد الحذف المنطقي على SoftDeletes القياسية في Laravel (deleted_at)، وترحيل البيانات مع تحويل ترميز جدولي latin1 إلى utf8mb4 والتحقق من سلامة النصوص العربية.
• قبل الترحيل: عمل dump حي من قاعدة الإنتاج لالتقاط مخطط followupdrugs الفعلي وأي جداول أخرى أنشأها RedBeanPHP وقت التشغيل وغير موجودة في النسخة الاحتياطية المرجعية.

الوظائف الرئيسية

• إدارة كتالوج التحاليل: إضافة/تعديل/حذف منطقي لفئات التحاليل (investcats) وبنود التحاليل (invests) مع ترتيب عرض مخصص (displayorder) عبر شاشة addinvestigation.php.
• تمييز تحاليل "مفضلة" (favorite) لتظهر بشكل أسرع عند طلب التحاليل من الشيتات.
• طلب تحاليل لكل زيارة/شيت: اختيار بنود من الكتالوج وحفظها في جداول أوامر منفصلة لكل تخصص (ancsheetinvest لمتابعة الحمل، gynasheetinvest لأمراض النساء، infertilitysheetinvest للعقم) مع تحديد ما إذا كان التحليل للزوجة أم للزوج (forhusband) وطباعة أمر التحليل.
• تسجيل نتائج التحاليل (investresult) يدوياً على مستوى كل أمر تحليل، وعرضها مجمّعة حسب التاريخ في الشيتات والتقارير المجمعة.
• شاشة فحوصات المريضة الشاملة (investigation.php): تجميع وعرض وتحرير مباشر (inline AJAX) لفحوصات السائل المنوي والأشعة بالصبغة والموجات الصوتية والمنظار البطني والرحمي والرنين والهرمونات والباثولوجي (جداول موديول العقم).
• فحوصات أخرى ديناميكية (Other Investigations): تعريف الطبيب لأعمدة فحوصات مخصصة (otherinvestigations) ثم إنشاء صف لكل مريضة بتاريخ معين (otherinvestigationsrows) وتخزين القيم بنمط سمة/قيمة (otherinvestigationsvalues).
• تصدير دفعي للملف الطبي الكامل للمريضة (تاريخ مرضي، فحص، تحاليل، زيارات، متابعة حمل) إلى ملفات Excel منسقة عبر excel.php ومكتبة PHPExcel، مع قائمة انتظار للمرضى المطلوب تصديرهم (excelinfopatients).
• التحقق من ترخيص البرنامج: جدول excelinfo يخزّن الرقم التسلسلي لتفعيل النسخة (يُفحص عند تسجيل الدخول) رغم أن اسمه يوحي بأنه خاص بالإكسل.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يقوم مدير النظام/الطبيب من شاشة إدارة التحاليل (addinvestigation.php) بإنشاء فئات التحاليل وبنودها، وتحريرها مباشرة عبر AJAX، وتمييز المفضلة، والحذف المنطقي (deleted = 1).
2. داخل شيت متابعة الحمل أو أمراض النساء أو العقم، تُعرض الفئات مجمّعة حسب نطاقات displayorder (مكوّدة يدوياً: 1-2، 3، 4-5، 6-11، أكبر من 11) مع قائمة المفضلة، ويختار الطبيب التحاليل المطلوبة (checkboxes) ويحدد التاريخ وهل هي للزوجة أم للزوج.
3. عند الحفظ يُنشأ سجل لكل بند مختار في جدول الأوامر الخاص بالشيت (ancsheetinvest أو gynasheetinvest أو infertilitysheetinvest) حاملاً patientid وinvestid وdate وdoctorid وforhusband، ثم يُعرض أمر التحاليل للطباعة باسم المريضة أو الزوج.
4. لاحقاً تُسجَّل النتائج في حقل investresult لكل سجل، وتُعرض التحاليل مجمّعة حسب التاريخ (زوجة/زوج) داخل الشيت وفي التقرير المجمع (completereport.php) الذي يجلب اسم التحليل من الكتالوج invests.
5. شاشة الفحوصات العامة (investigation.php?patientid=...) تعرض لكل مريضة جداول السائل المنوي وHSG وUS/TVS والمنظارين وMRI/CT والهرمونات والباثولوجي، وتُنشئ تلقائياً صفاً فارغاً بتاريخ اليوم إن لم يوجد، مع تحرير أي خلية مباشرة عبر update().
6. في قسم الفحوصات الأخرى: إضافة تعريف فحص جديد (otherinvestsAdd) ينشئ عموداً جديداً، وإضافة صف للمريضة (otherinvestsRow) ينشئ سجلاً في otherinvestigationsrows وقيماً فارغة في otherinvestigationsvalues لكل تعريف نشط داخل معاملة واحدة، ثم تُملأ القيم بالتحرير المباشر.
7. عند فتح ملف المريضة في patienthistory.php أو completereport.php تُضاف المريضة تلقائياً إلى قائمة excelinfopatients إن لم تكن موجودة.
8. يعمل السكريبت excel.php (يُشغَّل مباشرة، على الأرجح بمجدولة cron - استنتاج) فيقرأ القائمة، ويفرّغها، ويبني لكل مريضة جدول HTML شاملاً (تاريخ مرضي، فحص، تحاليل، زيارات، متابعة حمل) ويحوّله إلى ملف .xlsx منسّق يُحفظ في excel_backups/{statusno}/{date}.xlsx.

الارتباط بالموديولات الأخرى

• المرضى (patients): عبر otherinvestigationsrows.patientid وexcelinfopatients.patientid وكذلك patientid في جميع جداول أوامر التحاليل الفرعية، وstatusno المنسوخ من patients.statusno.
• متابعة الحمل (Antenatal): ancsheetinvest.investid → invests.id وancsheetinvest.ancsheetid → شيت متابعة الحمل، وinvestigations.ancsheetid (الجدول القديم)، وكذلك mainantenentalinvest.
• أمراض النساء (Gyna): gynasheetinvest.investid → invests.id إضافة إلى gynainvestigation وfollowupinvest التابعة لموديولات المتابعة.
• العقم (Infertility): infertilitysheetinvest.investid → invests.id، وشاشة investigation.php تعرض وتحرر جداول موديول العقم (semen, hsg, ustv, laparoscopy, hysteroscopy, mrict, hormon, pathology).
• المستخدمون (awusers): عبر doctorid في otherinvestigationsrows وجميع جداول أوامر التحاليل لإظهار اسم الطبيب الطالب.
• التقارير (completereport / Completesreport / patienthistory): تقرأ الكتالوج والأوامر وتغذّي قائمة تصدير الإكسل.
• المراقبة (Monitoring): جدول mointoringsheetinvestigation يتبع نفس النمط ويرجع للكتالوج ذاته (استنتاج من تشابه البنية).

ملاحظات فنية

• لا توجد مفاتيح أجنبية معلنة إطلاقاً؛ جميع العلاقات مستنتجة من أسماء الأعمدة واستعلامات الكنترولرات.
• اسم جدول excelinfo مضلِّل تماماً: هو مخزن ترخيص/تفعيل البرنامج (serial SHA-512) وليس له علاقة بالإكسل، وقد أُدرج عمداً ضمن الجداول المحمية من الحذف في setup.php.
• جدول investigations قديم (legacy) بأعمدة ثابتة مكررة لكل تحليل (زوج تاريخ/نتيجة)، فارغ من البيانات، وقد حلّ محله نمط ancsheetinvest المرتبط بالكتالوج؛ كما يُستعلم عنه في Completesreport.php بمعرّف شيت IVF أحياناً (خلط محتمل في المعرّفات).
• تكرار بنيوي كبير: ثلاثة جداول أوامر متطابقة البنية (ancsheetinvest, gynasheetinvest, infertilitysheetinvest) تختلف فقط في سياق الشيت.
• منطق تجميع الفئات في الواجهة مكوَّد يدوياً على نطاقات displayorder (1-2 / 3 / 4-5 / 6-11 / >11 / 0 / -1) ومكرر في أكثر من كنترولر (ancsheet00.php, antenalvisit.php...).
• ثغرة أمنية في investigation.php::update() وaddinvestigation.php::update(): استقبال اسم الجدول واسم العمود من الطلب مباشرة (tableName/colName) ما يسمح بالكتابة في أي جدول؛ كما يُدمج doctorid في نصوص SQL بدون ربط معاملات.
• بيانات الكتالوج المزروعة تحتوي سجلات تجريبية وتالفة (أسماء فارغة، بنود مثل "vvv" و"new33"، وبنود بـ investcatid = 0 لا تنتمي لأي فئة).
• شاشة investigation.php تُنشئ تلقائياً صفوفاً فارغة في 7 جداول عند أول فتح للملف، ما يولّد بيانات وهمية (سجلات بلا قيم) بمرور الوقت.
• excel.php سكريبت إجرائي بلا فئة كنترولر ولا تحقق من الصلاحيات، يعتمد مكتبة PHPExcel المهجورة، ويستخدم مواضع صفوف مكوَّدة يدوياً للتنسيق ما يجعله هشاً لأي تغيير في البنية، ويسمّي الملفات بتاريخ اليوم فقط (الكتابة فوق التصدير السابق لنفس اليوم).
• otherinvestigationsvalues يخزّن كل القيم كنص حر (varchar) دون وحدات قياس أو مدى مرجعي أو نوع بيانات.

توصيات النقل إلى ERP

• إنشاء كتالوج موحّد في Laravel: نموذج LabTestCategory (من investcats) وLabTest (من invests) مع مفاتيح أجنبية حقيقية، وإضافة حقول ناقصة إكلينيكياً (كود التحليل، الوحدة، المدى المرجعي، نوع النتيجة) وتنظيف السجلات التجريبية والفارغة قبل الترحيل.
• توحيد جداول الأوامر الثلاثة (ancsheetinvest, gynasheetinvest, infertilitysheetinvest ومثيلاتها) في نموذج واحد LabOrder + LabOrderItem بعلاقة polymorphic (orderable_type/orderable_id) نحو الزيارة أو الشيت، مع حقول patient_id, doctor_id, ordered_for (wife/husband), result, result_date.
• إسقاط جدول investigations القديم نهائياً (فارغ ومهجور) بعد التأكد من خلوّه في قاعدة الإنتاج، وترحيل أي بيانات تاريخية محتملة إلى LabOrderItem.
• استبدال نمط EAV في الفحوصات الأخرى بنموذج CustomInvestigation (تعريف) وCustomInvestigationResult مع التحقق من نوع القيمة، أو دمجها كلياً في الكتالوج الموحد كفحوصات يعرّفها المستخدم بدلاً من نظام موازٍ.
• استبدال ترتيب العرض المكوَّد (displayorder ونطاقاته الثابتة) بحقل ترتيب صريح وتجميع قابل للتهيئة من واجهة الإدارة في Angular.
• إلغاء آلية excelinfo (الترخيص) لأنها خاصة بالنسخة المكتبية القديمة، والاستعاضة عنها بإدارة الاشتراكات/التفعيل في الـ ERP إن لزم.
• استبدال قائمة excelinfopatients وسكريبت excel.php بنظام Jobs/Queues في Laravel مع مكتبة حديثة (Laravel Excel / PhpSpreadsheet) أو تقارير PDF، وتسجيل حالة كل عملية تصدير بدلاً من TRUNCATE.
• فرض التحقق من المدخلات ومنع تمرير أسماء الجداول والأعمدة من الواجهة؛ استخدام Form Requests وEloquent مع whitelist صريح للحقول القابلة للتعديل.
• الاحتفاظ بمسار ترحيل بيانات واضح: ربط معرّفات الكتالوج القديمة بالجديدة في جدول mapping لضمان سلامة التقارير التاريخية.

الوظائف الرئيسية

• إدارة كتالوج الأدوية (drugs.php): إضافة/تعديل/حذف صنف دوائي بحقول التصنيف العلاجي (drugcat) والاسم التجاري والشكل الصيدلي (Tab/Syrup/Amp...) ونص الجرعة بالعربية، مع جدول عرض DataTables وبحث تكميلي (Autocomplete) لكل حقل على حدة.
• تسجيل فواتير الشراء من الموردين (buys.php): رقم الفاتورة، التاريخ، اسم المورد (نص حر)، المستخدم المستلم، وبنود الفاتورة (دواء + كمية) — مع زيادة رصيد المخزون آليًا داخل معاملة (Transaction).
• تعديل وحذف فواتير الشراء مع عكس أثرها على الأرصدة وتسجيل حركة تصحيحية في دفتر المخزن.
• دفتر حركات المخزون (store.php): تقرير زمني لكل حركة دواء (الرصيد قبل/بعد/الفرق) مع نوع العملية: 0 = توريد، 1 = صرف، 2 = تعديل فاتورة، 3 = حذف/تصحيح.
• شاشة صرف الروشتات (receipt.php): عرض الروشتات المعلّقة القادمة من الشيتات الإكلينيكية باسم الطبيب والمريضة، وعرض تفاصيل الأدوية مع تحذير إذا كان الرصيد الحالي أقل من المطلوب، ثم تأكيد الصرف بخصم الكميات من المخزون وتغيير حالة الروشتة.
• توليد الروشتات آليًا من الموديولات الإكلينيكية: كنترولرات followupcard.php وoperativedetails.php في النواة تُنشئ سجل recepittmp وبنوده في receiptdrugs عند حفظ الوصفة الطبية، فتظهر فورًا في طابور الصيدلية.
• إدارة طاقم/رئيس المجلس (stuff.php): وظيفة جانبية تدير جدول councilstaff، مع نسخة مكررة بالكامل من دوال تعديل وحذف الفواتير الموجودة في buys.php.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يُجهَّز كتالوج الأدوية مرة واحدة (بيانات مزروعة ~2,000 صنف) ويُضاف عليه من شاشة الأدوية؛ عند إضافة صنف جديد يُسجَّل رصيد افتتاحي يُنسخ إلى currentbalance.
2. عند وصول توريد من مورد، يُدخل أمين المخزن فاتورة شراء (buys.php → addnew) داخل معاملة واحدة: سجل في importbill، ثم لكل بند سجل في importdetails + حركة توريد (optype=0) في pharmacystore + تحديث drugs.currentbalance.
3. في العيادة، عند حفظ وصفة في كارت المتابعة أو تفاصيل العمليات (كنترولرات النواة followupcard.php / operativedetails.php) يُنشأ آليًا رأس روشتة في recepittmp بحالة 0 مع اسم جدول الوصفة المصدر، وتُنسخ الأدوية إلى receiptdrugs بكمية افتراضية 1، ويُحفظ رقما الروشتة والبند (recepittmpid / recepitdrugid) داخل سجل الوصفة الإكلينيكية نفسه.
4. يفتح موظف الصيدلية شاشة الروشتات (receipt.php) فيرى الطابور باسم الطبيب والمريضة، ويدخل على التفاصيل حيث يُحذَّر تلقائيًا إن كان رصيد أي صنف أقل من الكمية المطلوبة.
5. عند تأكيد الصرف (updatereceipt) تُسجَّل لكل صنف حركة صرف (optype=1) في pharmacystore ويُخصم من drugs.currentbalance — مع تخطّي الأصناف التي لا يكفي رصيدها — ثم تتحول حالة الروشتة إلى 1 (تم الصرف).
6. تعديل فاتورة شراء (update) يعكس الكميات القديمة ويسجل حركات تصحيح (optype=2)؛ وحذف الفاتورة (del) يخصم الكميات ويسجل حركات (optype=3).
7. تقرير المخزن (store.php → show) يعرض دفتر الحركات كاملًا باسم الدواء ونوع العملية والتاريخ كسجل تدقيق للمخزون.

الارتباط بالموديولات الأخرى

• موديول المرضى: recepittmp.patient_id → patients.id (اسم المريضة من wifename).
• المستخدمون والصلاحيات: recepittmp.doctor_id → awusers.user_id وimportbill.receiveuser → awusers.user_id، مع نظام صلاحيات autho المشترك مع تطبيق النواة.
• الشيتات الإكلينيكية (متابعة الحمل، النساء، العقم، العمليات...): جداول الوصفات followupcarddrugs, operativedetailsdrugs, ancsheetdrugs, gynadrugs, gynasheetdrugs, mainantenentaldrugs, infertilitydrugs وغيرها تحمل أعمدة drugid → drugs.id وrecepittmpid → recepittmp.id وrecepitdrugid → receiptdrugs.id.
• ارتباط متعدد الأشكال: recepittmp.drugstablename يخزن اسم جدول الوصفة المصدر كنص (مثل followupcarddrugs أو operativedetailsdrugs).
• موديول الزيارات: شاشة طباعة الروشتة في كارت المتابعة تقرأ من visits وdetections (استخدام غير مباشر).
• إدارة المجلس: كنترولر stuff.php يكتب في جدول councilstaff (خارج جداول هذا الموديول).

ملاحظات فنية

• جدولان ميتان: drugdos (فارغ، حقل name من نوع int خطأً، لا يُستخدم في أي كود) وimporttdetails (نسخة مكررة فارغة من importdetails بلا أي مرجع في الكود).
• ثغرة حقن SQL في drugs.php → show(): قيمة البحث sSearch تُدمج في الاستعلام مباشرة بلا Prepared Statement.
• ثغرة خطيرة في receipt.php → update(): نقطة نهاية عامة تستقبل اسم الجدول والعمود والقيمة من المستخدم وتكتب في أي جدول بقاعدة البيانات.
• تكرار كود ضخم: دوال update/del/delup منسوخة حرفيًا بين buys.php وstuff.php، وكنترولر receipt.php يكرر نفس المنطق في index() وshow().
• تعليقات الكود مضللة: التعليق يقول إن optype "0 للحذف و1 للتعديل" بينما الاستخدام الفعلي: 0 توريد، 1 صرف، 2 تعديل، 3 حذف — قيم مُدمجة في الكود (Hardcoded) بلا جدول مرجعي.
• لا توجد مفاتيح أجنبية معلنة إطلاقًا؛ حذف فاتورة يخصم الكمية من الرصيد دون التحقق من عدم سلبيته، ومنطق تعديل الفاتورة في buys.php → update() هشّ وبه شروط يصعب تتبعها (مقارنة billIDn بـ drug_id).
• لا يوجد جدول موردين: importbill.suppliers نص حر، ولا أسعار شراء أو بيع ولا تواريخ صلاحية أو أرقام تشغيلات (Batches) في المخزون.
• الكمية في بنود الروشتة ثابتة دائمًا = 1 عند التوليد الآلي من الشيتات، والتصنيف والشكل الصيدلي والجرعة في drugs نصوص حرة غير منضبطة (تكرارات مثل Anti-viruis\r\n).
• عند صرف روشتة، الأصناف التي لا يكفي رصيدها تُتخطى بصمت ثم تُعلَّم الروشتة كلها "تم الصرف" — فقدان لمعلومة الصرف الجزئي.

توصيات النقل إلى ERP

• إنشاء موديلات Laravel: Drug (مع فصل التصنيف إلى DrugCategory والشكل الصيدلي إلى DosageForm كجداول مرجعية بدل النص الحر)، وStockMovement بدل pharmacystore مع Enum لنوع الحركة، وPurchaseInvoice + PurchaseInvoiceItem بدل importbill/importdetails، وPrescription + PrescriptionItem بدل recepittmp/receiptdrugs.
• إسقاط الجدولين الميتين drugdos وimporttdetails نهائيًا من خطة الترحيل.
• إنشاء جدول suppliers مستقل وربط فواتير الشراء به بمفتاح أجنبي بدل النص الحر، وإضافة حقول الأسعار وتواريخ الصلاحية وأرقام التشغيلات إن أرادت الإدارة إدارة مخزون حقيقية.
• التوقف عن تخزين currentbalance كحقل يُحدَّث يدويًا، وجعله محسوبًا من دفتر الحركات (أو تحديثه عبر Observers/Events داخل معاملات قاعدة بيانات) مع قيد يمنع الرصيد السالب.
• استبدال الارتباط النصي متعدد الأشكال (drugstablename + أعمدة recepittmpid/recepitdrugid المبعثرة في 8+ جداول وصفات) بعلاقة Polymorphic قياسية في Laravel (prescribable_type/prescribable_id) أو بتوحيد جداول الوصفات الإكلينيكية كلها في جدول prescription_items واحد مرتبط بنوع الشيت.
• دعم الصرف الجزئي: حالة الروشتة يجب أن تكون Enum (معلّقة/مصروفة جزئيًا/مصروفة/ملغاة) مع تسجيل الكمية المصروفة فعليًا لكل بند بدل تخطّي النواقص بصمت.
• تنظيف بيانات الكتالوج قبل الترحيل: توحيد التصنيفات المكررة وإزالة محارف \r\n والمسافات الزائدة، وفرض Unique على (الاسم + الشكل الصيدلي).
• إغلاق الثغرات أثناء الترحيل بطبيعة Laravel: Form Requests للتحقق، Eloquent/Query Builder بدل دمج النصوص في SQL، وحذف أي نقطة نهاية كتابة عامة مثل receipt.php → update()، مع نقل صلاحيات الصيدلية إلى Policies/Gates.

الوظائف الرئيسية

• تسجيل رسوم الزيارة داخل جدول visits نفسه: نوع الكشف من كتالوج detections مع الحقول المالية totaldetectionvalue وdetectionvalue_cash وdetectionvalue_visa وdiscount وrestdetectionvalue (المتبقي كدَين).
• التقرير المالي اليومي/الفتري (financialreport): إجمالي الإيرادات، النقدي، الفيزا، الخصومات، المديونيات، المرتجعات، مع تمييز المرضى الجدد خلال الفترة، والبحث باسم الزوجة أو الزوج أو العنوان، مع شاشة طباعة.
• إدارة "المبلغ الإجمالي" للمريضة: إضافة رصيد عبر جدول totalbalance (من شاشة الزيارات بطلب AJAX) وحساب المتبقي = مجموع الرصيد − مدفوعات الأقساط المسجلة كزيارات بكود detectionid = -99.
• تقرير الأرصدة (balance): دمج إضافات الرصيد من totalbalance مع مدفوعات الأقساط من visits عبر استعلام UNION لعرض صافي الحركة.
• تقرير المتبقيات (rest): حصر الزيارات التي بها مديونية restdetectionvalue > 0 بعد خصم ما سُدِّد لاحقًا (زيارات بكود detectionid = 999 "دفع متبقى") وما خُصم.
• معالجة المرتجعات: زيارات بكود detectionid = 9999 "مرتجع العملاء" مرتبطة بالزيارة الأصلية عبر visits.visitid وتُخصم من إيرادات اليوم.
• تقرير استخدام الأدوية: حصر المريضات اللاتي وُصف لهن دواء معين خلال فترة عبر 6 جداول وصفات (gynadrugs، mainantenentaldrugs، ancsheetdrugs، infertilitydrugs، gynasheetdrugs، infertilitysheetdrugs).
• التقرير الكامل (fullreport): مصفوفة نشاط لكل مريضة زارت العيادة خلال فترة، تُبيِّن الأقسام السريرية التي بها بيانات (تاريخ مرضي، فحص، استقصاءات، متابعة حمل، نساء، موجات صوتية، سونار، عمليات) مع عدد الزيارات.
• التقرير المدمج (combinedreport): بحث إحصائي/وبائي بالعمر والتشخيص النسائي وتشخيص الحمل والعمليات والإجهاض، مع حساب نسبة مئوية من إجمالي المريضات.
• التقرير الشامل للمريضة (completereport): تجميع كل بيانات المريضة (ديموغرافيا، تاريخ مرضي، فحص، استقصاءات، نساء، متابعة حمل) في شاشة واحدة، مع تصدير Excel بتشغيل سكربت خارجي excel.php وحفظ الملفات في core/excel_backups/<statusno>.
• تقرير الشيتات الشامل (Completesreport): نسخة أحدث تجمع شيتات العقم والحقن المجهري ومتابعة الحمل والنساء مع عشرات جداول القيم المرجعية في تقرير واحد.
• إحصاءات الحقن المجهري (Ivfstatistics): حصر دورات ivfsheet بتاريخ آخر دورة شهرية (fresh/frozen) مع بروتوكول التنشيط ومراحل التحضير (ovst، eprep) وحساب سن المريضة وقت المحاولة.
• النسخ الاحتياطي (backup): تنفيذ mysqldump وحفظ النسخة في core/db_backups وفي مسار إضافي من إعدادات البرنامج، مع تنزيلها للمتصفح، إضافة لأدوات إصلاح بيانات (استكمال drugid الناقص وتوليد أرقام ملفات statusno المفقودة).
• دمج قاعدة بيانات قديمة (merge): نقل نحو 40 جدولًا من قاعدة عيادة قديمة إلى الحالية جدولًا جدولًا عبر RedBeanPHP ثم تشغيل إصلاحات لاحقة.
• استيراد قاعدة جديدة (newdb): رفع ملف SQL وتنفيذه سطرًا بسطر مباشرة على قاعدة البيانات.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. عند فتح زيارة جديدة من شاشة الاستقبال (visits.php) تختار الموظفة نوع الكشف من كتالوج detections، فتُسجَّل قيمته الإجمالية والمدفوع نقدًا/فيزا والخصم والمتبقي في صف الزيارة نفسه بجدول visits.
2. إذا اشترت المريضة باقة/مبلغًا إجماليًا، تضيف الموظفة الرصيد عبر زر في شاشة الزيارات يستدعي visits.php?addbalance فيُخزَّن صف جديد في totalbalance باسم المستخدم وتاريخ اليوم، ويعرض النظام فورًا المتبقي (مجموع الأرصدة − مدفوعات الأقساط).
3. سداد قسط من الرصيد يُسجَّل كزيارة بكود detectionid = -99، وسداد متبقي زيارة سابقة بكود 999 مع ربطها بالزيارة الأصلية عبر visits.visitid، والمرتجع بكود 9999.
4. في نهاية اليوم تفتح الإدارة التقرير المالي (financialreport.php?index/search) لعرض حركة اليوم أو فترة: لكل زيارة النوع والقيمة والنقدي والفيزا والخصم والمتبقي والمرتجع، مع إجماليات وقائمة المرضى الجدد، ثم الطباعة من showprint.
5. تقرير الأرصدة financialreport.php?balance (وبحثه عبر monitoring.php) يعرض حركة "إضافة للمبلغ الإجمالي" مقابل "دفع قسط" بصافي محسوب، وتقرير المتبقيات rest يحصر المديونيات القائمة.
6. للتقارير السريرية: fullreport يحدد فترة ويستعرض نشاط كل مريضة في كل قسم، وcombinedreport يجري بحثًا إحصائيًا بمعايير تشخيصية، وcompletereport/Completesreport يولّدان ملفًا شاملًا لمريضة واحدة مع إمكانية تصدير Excel، وIvfstatistics يستخرج إحصاءات دورات الحقن المجهري.
7. دوريًا يأخذ المدير نسخة احتياطية من backup.php?takeit (mysqldump ثم تنزيل)، وعند الانتقال من نظام قديم تُستخدم merge.php لدمج قاعدة قديمة أو newdb.php لتنفيذ ملف SQL مرفوع.

الارتباط بالموديولات الأخرى

• موديول المرضى: totalbalance.patientid وtotalbalancepaids.patientid ↔ patients.id، وكل التقارير تعرض wifename وhusdandname وstatusno.
• موديول الزيارات والاستقبال: الرسوم تُسجَّل في visits (detectionid, detectionvalue_cash, detectionvalue_visa, restdetectionvalue) وهي مصدر كل التقارير المالية، مع كتالوج أنواع الكشف detections وجدول إقفال اليوم endvisitreports.
• موديول الصيدلية/الأدوية: تقرير استخدام الأدوية يقرأ من drugs وجداول الوصفات الست عبر drugid وpatientid.
• الموديولات السريرية (التاريخ المرضي، الفحص، الاستقصاءات، متابعة الحمل، النساء، الموجات، العمليات): تُقرأ جداولها (ph*, examination, semen, hsg, gyna, mainantenental, ultrasound*, sonar, operativedetails...) في التقارير الكاملة والمدمجة عبر patientid.
• موديول الشيتات (العقم/الحقن المجهري/متابعة الحمل): Completesreport وIvfstatistics يقرآن infertilitysheet وivfsheet وancsheet وجداولهما الفرعية عبر patientid وivfsheetid وinfertilitysheetid.
• موديول الإعدادات والمستخدمين: programesetting (مسار النسخ الاحتياطي وphppath وقاعدة ERP الخارجية) وtotalbalance.userid ↔ مستخدمي النظام awusers (استنتاج)، كما توجد دالة مزامنة كتالوج الكشوفات إلى قاعدة ERP خارجية (addAllDetectionToERP في visits.php).

ملاحظات فنية

• totalbalancepaids جدول ميت تمامًا: لا يظهر في أي كنترولر أو قالب؛ المدفوعات تُسجَّل بدلًا منه كزيارات بأكواد سحرية.
• منطق محاسبي مبني على قيم سحرية مثبتة في الكود (detectionid = -99 قسط، 999 سداد متبقٍ، 9999 مرتجع) دون جدول أنواع حركات، ما يجعل جدول الزيارات يلعب دور دفتر يومية مالي.
• لا توجد قيود مفاتيح أجنبية إطلاقًا؛ كل العلاقات مستنتجة من أسماء الأعمدة وجمل JOIN.
• ثغرات حقن SQL واسعة: التواريخ والعناوين وأسماء الأزواج تُلصق نصيًا في الاستعلامات (financialreport، monitoring، combinedreport)، ودالة Add() في Completesreport وIvfstatistics تكتب في أي جدول/عمود يصل عبر POST دون أي تحقق.
• newdb.php ينفّذ ملف SQL مرفوعًا مباشرة، وbackup.php يمرر كلمة مرور القاعدة في أمر نظام (system())، مع بقايا بيانات اعتماد قديمة معلَّقة في الكود.
• القيم المالية بدقة صفرية: visits تستخدم decimal(10,0) وtotalbalance.balance من نوع int (لا كسور عملة)، والجدولان بترميز latin1 بخلاف باقي القاعدة utf8mb4.
• تكرار كود كبير: استعلامات البحث/الطباعة منسوخة حرفيًا داخل نفس الكنترولر، وonesetup (حذف قوائم وأدوار) مكرر في أكثر من كنترولر تقارير بلا علاقة بالتقارير.
• تصدير Excel يعتمد على exec() لمسار PHP مخزَّن في الإعدادات (إرث تشغيل على Windows/WAMP) ويكتب ملفات لكل مريضة في مجلدات باسم رقم الملف.
• الجدولان فارغان في النسخة المفحوصة (AUTO_INCREMENT=1) أي أن الإصدار الحالي للعميل قد لا يستخدم خاصية الرصيد الإجمالي فعليًا (استنتاج).

توصيات النقل إلى ERP

• إنشاء نموذج PatientLedgerEntry (دفتر حساب المريض) موحَّد يستوعب: رسوم الزيارة، إضافة رصيد (يحل محل totalbalance)، سداد قسط، سداد متبقٍ، خصم، مرتجع — بعمود type (enum) بدل الأكواد السحرية -99/999/9999، مع reference_id للحركة الأصلية بدل visits.visitid.
• فصل الفاتورة عن الزيارة: نموذج Invoice مرتبط بالزيارة (بنود من كتالوج الخدمات services الذي يحل محل detections) ونموذج Payment بعمود طريقة الدفع (cash/visa) بدل عمودين منفصلين، وحساب المتبقي والمديونية ديناميكيًا لا تخزينه.
• إسقاط totalbalancepaids نهائيًا دون ترحيل (جدول ميت)، وترحيل صفوف totalbalance إن وُجدت إلى حركات إيداع في دفتر الحساب.
• استخدام decimal(10,2) لكل المبالغ، وقيود مفاتيح أجنبية فعلية إلى patients وusers، وحذف ناعم موحَّد (deleted_at) بدل أعمدة deleted الرقمية.
• بناء التقارير (المالي اليومي، الأرصدة، المديونيات، استخدام الأدوية) كطبقة استعلامات/Resources في Laravel مع API لواجهة Angular، وتقارير المريضة الشاملة كـ endpoints تجميعية أو خدمة توليد PDF بدل تصدير Excel عبر exec().
• الاستغناء عن backup.php وmerge.php وnewdb.php: النسخ الاحتياطي عبر أدوات مُدارة (spatie/laravel-backup أو نسخ على مستوى الخادم)، ودمج القواعد القديمة كسكربتات ترحيل (ETL) تُنفَّذ مرة واحدة وقت الانتقال، ومنع أي رفع/تنفيذ SQL من الواجهة.
• تطبيق التحقق من المدخلات والاستعلامات المعدة مسبقًا (Eloquent/Query Builder) في كل شاشات البحث، وإزالة أي نقطة كتابة عامة على غرار Add()، مع صلاحيات دقيقة للتقارير المالية (أدوار محاسب/مدير).

الوظائف الرئيسية

• إنشاء طلب عرض حالة على المجلس: يُنشأ الطلب تلقائيًا كمسودة (status=0) عند فتح الشاشة، مع حفظ تلقائي للعنوان والتفاصيل أثناء الكتابة (AJAX auto-save)، ثم إرساله للمجلس (status=1) بتاريخ اليوم.
• عرض قائمة الطلبات المعلّقة (المرسلة وغير المناقشة) وقائمة أرشيف الطلبات التي نوقشت وأُغلقت (status=2).
• فتح جلسة مجلس جديدة تلقائيًا: عند فتح شاشة الجلسات يُنشأ سجل جلسة مسودة (status=0) وتُسجّل تلقائيًا قائمة أعضاء المجلس (المستخدمون أصحاب positionid ١ و٢ و٣) كأعضاء للجلسة.
• تسجيل حضور وغياب الأعضاء في الجلسة بإضافة/حذف سجل في bsessionmembers.
• تسجيل رأي كل عضو حاضر على كل طلب معروض: قبول (1) أو رفض (2) في جدول bmemberopenion.
• تدوين القرار النهائي للمجلس نصيًا على الطلب (حقل decision في brequests).
• تأجيل طلب لجلسة قادمة (علامة delay=1) أو إلغاء التأجيل.
• إغلاق الجلسة وأرشفتها: تُغلق الجلسة (status=1) وتُؤرشف كل الطلبات المناقشة (status=2) مع ربطها برقم الجلسة sessionid، وتُعاد الطلبات المؤجلة إلى قائمة الانتظار — كل ذلك داخل معاملة (Transaction) واحدة.
• نظام تعليقات متداخل على الطلبات: تعليقات رئيسية وردود عليها (relatedcommentid)، مع إضافة وحذف (حذف التعليق الرئيسي يحذف ردوده).
• عرض تفاصيل الجلسات المؤرشفة: الأعضاء الحاضرون وآراؤهم وقرارات المجلس على كل طلب.
• إدارة تشكيل المجلس (شاشة stuff): تعيين رئيس المجلس (status=0) وأمين المجلس (status=1) والأعضاء (status=2) من بين مستخدمي النظام، مع تعديل وحذف.

الجداول وبنية البيانات (Data Models)

سير العمل (Workflow)

1. يفتح الطبيب شاشة «إضافة طلب» (requests.php)؛ إن وُجدت مسودة طلب سابقة غير مرسلة تُحمَّل، وإلا يُنشأ سجل طلب جديد فارغ باسمه تلقائيًا.
2. يكتب الطبيب عنوان الحالة وتفاصيلها، وتُحفظ القيم تلقائيًا أولًا بأول عبر دالة update() (AJAX).
3. عند الضغط على «إرسال» (sendrequest) يتحول الطلب إلى status=1 ويُختم بتاريخ اليوم ويظهر في قائمة الطلبات المعلّقة.
4. يتبادل الأطباء النقاش كتابيًا على الطلب عبر التعليقات والردود (addcomment / deletecomment).
5. يفتح أمين المجلس شاشة الجلسات (sessions.php)؛ إن لم توجد جلسة مفتوحة تُنشأ جلسة جديدة ويُسجَّل تلقائيًا كل أعضاء المجلس (مستخدمو positionid 1–3) في bsessionmembers.
6. يُحدَّث الحضور الفعلي بإزالة الغائبين وإعادة إضافة الحاضرين (addsessionmember / removesessionmember).
7. تُعرض الطلبات المعلّقة واحدًا تلو الآخر (requestDetails)؛ يسجل كل عضو حاضر رأيه قبول/رفض (saveopinion)، ويُدوَّن قرار المجلس النهائي نصيًا (savedecision)، أو يُؤجَّل الطلب لجلسة قادمة (delay).
8. عند إنهاء الجلسة (savesession): تُغلق الجلسة بتاريخ اليوم، وتُؤرشف الطلبات المناقشة (status=2) مع ربطها بالجلسة، وتُعاد الطلبات المؤجلة إلى قائمة الانتظار (داخل معاملة واحدة).
9. يمكن لاحقًا استعراض أرشيف الجلسات وتفاصيل كل جلسة: الحضور، الطلبات المناقشة، آراء الأعضاء، والقرارات (archiveshowall / sessiondetails / requestDetailsArchive).
10. بشكل مستقل، تُدار عضوية المجلس من شاشة stuff.php: تعيين الرئيس والأمين والأعضاء في جدول councilstaff.

الارتباط بالموديولات الأخرى

• موديول المستخدمين والصلاحيات (Core): كل أعمدة memberid وuserid في الجداول الستة تشير إلى awusers.user_id، وتُجلب أسماء الأطباء منه في كل الشاشات.
• موديول شؤون الأطباء/الوظائف: اختيار أعضاء الجلسة يعتمد على awusers.positionid بقيم مثبّتة في الكود (1، 2، 3) — ولا يوجد جدول positions في نسخة قاعدة البيانات المفحوصة (استنتاج: قيم وظائف الأطباء الاستشاريين والأخصائيين).
• موديول المرضى: لا يوجد ربط هيكلي بجدول patients إطلاقًا؛ بيانات المريض والحالة تُكتب نصًا حرًا في title وdetails فقط — فجوة بيانات جوهرية.
• موديول الصيدلية: كنترولر stuff.php يحتوي دوال كاملة منسوخة من موديول الصيدلية (updategg، del، delup) تتعامل مع جداول importbill وimportdetails وdrugs وpharmacystore — كود ميت منسوخ بالخطأ ولا علاقة له بالمجلس.

ملاحظات فنية

• جدول councilstaff شبه مهجور وظيفيًا: كنترولر الجلسات علّق الاستعلام عنه واستبدله باستعلام مباشر على awusers.positionid IN (1,2,3) بقيم مثبّتة في الكود، فأصبح تشكيل المجلس المُدار من شاشة stuff غير مؤثر فعليًا في الجلسات.
• ثغرة أمنية حرجة في requests.php::update(): تستقبل اسم الجدول واسم العمود والقيمة من POST مباشرة وتكتبها في أي جدول بقاعدة البيانات (Arbitrary table/column write).
• stuff.php بلا أي تحقق من تسجيل الدخول أو الصلاحيات (فحوصات autho معلّقة)، ويستخدم استعلامات SQL مبنية بدمج النصوص (مثل '... user_id = ' . $userid) — قابلة لحقن SQL.
• لا توجد مفاتيح أجنبية (Foreign Keys) مُعرّفة إطلاقًا؛ كل العلاقات استُنتجت من أسماء الأعمدة واستعلامات الكنترولرات.
• تضارب في الترميز: bcomments وbsession وcouncilstaff بترميز latin1 بينما البقية utf8mb4 — خطر تلف للنصوص العربية في التعليقات.
• غياب الطوابع الزمنية: لا يوجد created_at في التعليقات والآراء، وتاريخ الطلب/الجلسة يُسجَّل فقط عند الإرسال/الإغلاق.
• حقلا title وdetails في brequests محدودان بـ varchar(191) — التفاصيل السريرية تُبتر عند هذا الحد رغم أن الواجهة تعرضها كمساحة نص كبيرة.
• قيم الحالات كلها أرقام سحرية مثبّتة في الكود: حالة الطلب (0/1/2)، حالة الجلسة (0/1)، الرأي (1=قبول، 2=رفض)، دور العضو (0=رئيس، 1=أمين، 2=عضو) — بلا جداول مرجعية.
• معالجة الأخطاء صورية: كتل try/catch فارغة تبتلع الاستثناءات بصمت في معظم الدوال.
• الجداول الستة فارغة في نسخة قاعدة البيانات (AUTO_INCREMENT=1) — لا بيانات تاريخية تحتاج ترحيلًا من هذه النسخة (استنتاج: الموديول لم يُستخدم إنتاجيًا أو نُظِّفت بياناته).

توصيات النقل إلى ERP

• إنشاء خمسة نماذج Laravel: BoardRequest وBoardSession وBoardSessionMember وBoardMemberOpinion وBoardComment، مع مفاتيح أجنبية صريحة وقيود ON DELETE مناسبة.
• إضافة عمود patient_id إلزامي في board_requests مرتبط بجدول المرضى الموحد، وربط اختياري بالزيارة/الملف السريري — لمعالجة أكبر فجوة في التصميم الحالي (الحالة نص حر بلا مريض).
• تحويل الأرقام السحرية إلى Enum في Laravel: RequestStatus (draft/submitted/discussed)، SessionStatus (open/closed)، Opinion (accept/refuse)، CouncilRole (head/secretary/member).
• دمج councilstaff في نظام الأدوار/الصلاحيات بالـ ERP (مثل Spatie Permissions أو جدول board_members بحقل role)، وإلغاء الاعتماد المثبّت على positionid IN (1,2,3) بجعل عضوية المجلس قابلة للإدارة فعليًا.
• ربط رأي العضو مباشرة بـ user_id وsession_id بدل المرور عبر sessionmemberid (أو الإبقاء عليه مع قيد فريد على request_id + session_member_id)، مع إضافة طوابع زمنية لكل رأي وتعليق.
• توسيع حقل التفاصيل إلى TEXT، وإضافة created_at/updated_at وsoft deletes لكل الجداول لأغراض التدقيق الطبي.
• استبدال آلية الحفظ التلقائي «أكتب في أي جدول» بنقطة نهاية REST مخصصة ومحمية (PATCH /board-requests/{id}) مع Validation وFormRequest.
• حذف الكود الميت الخاص بالصيدلية من stuff.php نهائيًا وعدم ترحيله — وظائفه مكررة في موديول الصيدلية الأصلي.
• نظرًا لخلو الجداول من البيانات في النسخة المفحوصة، يمكن بناء الموديول في الـ ERP من الصفر بالتصميم المحسّن دون عبء ترحيل بيانات (يُتحقق من نسخة الإنتاج الأحدث قبل الاعتماد النهائي).

الوظائف الرئيسية

• تسجيل دخول وخروج المستخدمين بجلسات PHP مع خيار "تذكرني" عبر كوكي مؤمَّن، وتشفير كلمات المرور بخوارزمية bcrypt، وإيقاف مؤقت بعد ثلاث محاولات فاشلة (مكتبة _library/login_system).
• التحقق من الصلاحية عند كل طلب: كل إجراء في كل كنترولر يستدعي autho::checkauthoize() التي تطابق الدور مع الكنترولر والإجراء (awcontroll ← awcontrollprop ← awrolecontrollprop).
• إدارة الأدوار (_role.php) بمصفوفة صلاحيات تفاعلية: إظهار/إخفاء عناصر القائمة لكل دور، ومنح/منع كل إجراء لكل كنترولر، وأربعة أزرار سريرية مثبّتة بالكود (إضافة مريضة، إضافة زيارة، تعديل زيارة، حذف زيارة).
• إدارة المستخدمين (_member.php) مع ربط كل مستخدم بدور ووظيفة (awroleposition) وتخصص (awrolespecialize) يُحمَّلان ديناميكياً حسب الدور.
• إدارة شجرة القائمة الجانبية (_menu.php) بالسحب والإفلات، مع وضعَي عرض (مبسّط/كامل) يتحكم بهما إعداد simpleview، وخاصية ربط الرابط بالمريضة الحالية (withpatient).
• سجل إعدادات مركزي واحد (programesetting) بنحو 75 عموداً: بيانات المركز والطبيب، هوامش وخطوط الطباعة، تفعيل/تعطيل أقسام التاريخ المرضي والسونار والعقم، عدّادات أرقام الإيصالات الشهرية، وربط قاعدة بيانات ERP خارجية.
• أداة الإعداد (setup.php) المحمية بكلمة مرور ثابتة: ربط قاعدة ERP واختيار الخزينة الافتراضية، وروتين خطير لتفريغ جداول قاعدة البيانات مع قائمة استثناء مثبّتة بالكود.
• تطبيق شاشة الانتظار (screen/): يعرض صوراً دعائية من screen_slider مع اسم المريضة المُنادى عليها وقائمة الخمس التاليات من زيارات اليوم، بتحديث دوري عبر AJAX.
• واجهة API لتطبيق موبايل المريضات (mobileservices.php): تسجيل مريضة جديدة بكلمة مرور، تسجيل دخول بالموبايل، حجز وتعديل وإلغاء الزيارات، عرض الروشتات، وقراءة محادثات الدردشة، مع مزامنة بيانات العميلة مع نظام ERP خارجي عبر curl.
• إدارة مقالات المساعدة (help.php) بإضافة وتعديل وحذف ناعم.
• بنية جاهزة (غير مفعّلة) لتعدد الفروع والطوابق والأجهزة وتتبّع حركة المريضة بين الأجهزة (branches, floors, devices, device_tracking) ورسائل داخلية بين المستخدمين (messages).

الجداول وبنية البيانات (Data Models)