🏥

أصول OBGY القابلة لإعادة الاستخدام (OBGY Reusable Assets)

تصنيف استراتيجي لأصول نظام عيادات النساء والتوليد القديم (312 جدولاً، 18 وحدة وظيفية، موثَّقة بالكامل في obgy-erp-analysis.md) إلى ثلاث فئات: أصول عامة تصلح نواةً لأي وحدة مستشفيات (HIS)، وأصول تخصصية تخص طب النساء فقط، وأصول يجب التخلص منها نهائياً. هذا التصنيف هو المدخل الرئيسي لقرار مجلس الإدارة: هل يصبح OBGY هو قلب وحدة HIS أم وحدة تخصصية فوقها؟

نظرة كمية سريعة

312جدولاً في النظام القديم

~190جدول قوائم/مفردات سريرية (61%)

~85جدولاً مستهدفاً بعد الترحيل (مخطط القسم 95)

~32%أصول عامة لأي تخصص (استنتاج)

~48%أصول تخصصية نسائية (استنتاج)

~20%للإسقاط النهائي (استنتاج)

النسب الثلاث الأخيرة تقدير تحليلي (استنتاج) مبني على أرقام موثقة في التحليل: ~190 جدول قوائم من 312 (61%)، وخطة الترحيل 312 → ~85 جدولاً مع إسقاط ~40 جدولاً ميتاً/مشتقاً مباشرة، واستبدال ~17 جدول منصة (aw*) بنواة الـ ERP الحالية.

الفئة (أ) — أصول عامة تصلح لأي تخصص طبي نواة HIS محتملة

هذه ليست أكواداً قابلة للنقل (الكود القديم PHP 5.6 / Smarty / RedBeanPHP غير قابل للإنقاذ)، بل نماذج بيانات وتدفقات عمل مجرَّبة سريرياً لسنوات يعاد بناؤها في Laravel داخل نواة HIS:

الأصل	المصدر القديم (جداول/ملفات)	ماذا يصبح في Laravel
نموذج الزيارة + طابور الانتظار	`visits` (حجز + طابور + دفع في جدول واحد)، `visit_periods` (سعة الفترات)، `endvisitreports`، `detections` (كتالوج الخدمات)، شاشة الطابور `core/controllers/index.php` وتطبيق شاشة الانتظار `obgy/screen/`	`Appointment` + `Encounter` (queue_no, drag-sort) + `Service` + `VisitPeriod` + `PatientLedgerEntry` — مع إصلاح العيب الجوهري: ربط كل سجل سريري بـ `encounter_id`
نمط «الشيت السريري» + أبناؤه	10 جداول وصفات متطابقة (`ancsheetdrugs`, `gynadrugs`, `infertilitysheetdrugs`, `mointoringsheetdrugs`, `operativedetailsdrugs`…) و8 جداول تحاليل (`ancsheetinvest`, `gynainvestigation`, `infertilitysheetinvest`…)	`Prescription`/`PrescriptionItem` (علاقة `prescribable` متعددة الأشكال) و`LabOrder`/`LabOrderItem` مرتبطة بكتالوج LIS — أربعة جداول بدل 18
محرك أسئلة وأجوبة التاريخ المرضي القابل للتهيئة	`presenthistoryquestions`, `presenthistoryanswers`, جدول الإجابات الفعلية `gynaph` (يُنشأ وقت التشغيل — يجب تصديره من الإنتاج)	`HistoryQuestion` / `HistoryAnswerOption` / `PatientHistoryAnswer` — محرك استبيانات سريرية عام لأي عيادة
الفحص السريري لكل جهاز عضوي	`examination` (علامات حيوية + 5 أعمدة أجهزة) + 9 قوائم نتائج (`examinationhead/chest/abdomen/pelvis/extremitis`, `examinationlocalse`, `generalbreast/hirsutism/thyroid`)	`ClinicalExamination` + `ExaminationFinding` + خيارات في `obgy_lookups(domain=exam.*)` مع `body_system` enum
سير عمل العمليات وقائمة الانتظار الجراحية	`op_wait_list`, `operativedetails` (المذكرة الجراحية الكاملة: تخدير، شق جراحي، فريق، أدوية أثناء العملية), `anasthesa`/`generalanasthesa`, `jncision`/`midlinejncision`, `hospitalnames`, `pathology`/`histopath`	`SurgicalBooking` + `OperativeNote` + `operative_note_staff` + `AnesthesiaType` + `incision_types` + `Hospital` — مصممة صراحةً في المخطط (بند 2.6) لتستهلكها وحدة HIS/HMS
كروت المتابعة والتعليمات	`followupcard` + `followupcarddrugs` (تأكيد الكارت يدفع الوصفة للصيدلية عبر `recepittmp`/`receiptdrugs`)، مكتبة `instruction`	كارت لقاء مربوط بـ `Encounter` + حدث `PrescriptionDispensed` للصيدلية + `InstructionTemplate` و`Referral`
مرفقات الوسائط الطبية	`sonar` (صور/فيديو، MyISAM)، `patientfiles`، `gtimage`/`gtdetail` (رسوم تخطيطية معلَّمة)، مجلد `obgy/upload/` بحجم 3.2GB (منها `upload/sonar` 3.1GB / 1,846 ملفاً داخل web root!)	`MediaAttachment` عبر spatie medialibrary بروابط موقعة + `AnnotatedDiagram`/`DiagramMarker` بإحداثيات نسبية
محرك المفردات السريرية الموحَّد	~190 جدول قوائم بنفس الشكل `id + title + del` — قيمتها الحقيقية في المحتوى المنسَّق سريرياً الموجود في قاعدة الإنتاج (القوائم فارغة في dump 2024)	جدول واحد `obgy_lookups (domain, parent_id, title_ar, title_en, sort, is_active)` + PHP Enums للقيم الثابتة سريرياً
طلبات التحاليل الحرة (EAV)	`otherinvestigations` / `otherinvestigationsrows` / `otherinvestigationsvalues` + كتالوج `invests` (276 تحليلاً) و`investcats` (22 فئة)	طبقة ربط `obgy_lis_test_map` على كتالوج LIS القائم؛ التحاليل الحرة تصبح ad-hoc tests في LIS
مجلس الأطباء والصلاحيات الدقيقة	جداول `b*` (جلسات مناقشة الحالات) + نموذج RBAC `awcontroll`/`awcontrollprop`/`awrolecontrollprop` (~590 إجراء / ~3000 منحة)	`BoardRequest/BoardSession/BoardMemberOpinion` (يعاد بناؤها) + خريطة صلاحيات إلى `spatie/laravel-permission`

الفئة (ب) — أصول تخصصية: قيمتها داخل وحدة «صحة المرأة» فقط

متابعة الحمل (ANC): ثلاثة أجيال متوازية (ancsheet+ancnewvisit، mainantenental+antenalvisit، followup+followupvisit) تُدمج في Pregnancy + AntenatalVisit مع حساب EDD/GA كـ accessors، وwifeepc → PregnancyLoss، وregisteration → DeliveryRegistration، وop_4d_list → FourDScanBooking.
أطفال الأنابيب ومراقبة الدورات (IVF/ICSI/IUI): ivfsheet + mointoringsheet (وأبناؤها العشرة) → IvfCycle + IvfCycleVisit + FollicleMeasurement (يستبدل 26 عموداً مبهماً في ovst) + جداول مراحل OocyteRetrieval/EmbryoTransfer/Cryopreservation/CycleOutcome + EndometrialPrep من eprep.
الذكورة وتحليل السائل المنوي: semen/semen2/semeninfertility → SemenAnalysis وAndrologyInvestigation، وhormon+hormonalprofile+hormonalprofile2 → HormoneResult مرتبطة بمرجعيات LIS.
قوالب الموجات فوق الصوتية النسائية: ultrasound/ultrasoundobst + تفاصيل لكل جنين، gynaus+gynausficils، tvs/dtvs/sis/hsg → ImagingStudy + FetalScanFinding.
المناظير: laparoscopy/hysteroscopy + نسخ *infertility المهيكلة → EndoscopyProcedure + EndoscopyFinding، مع استبدال 24 جدول مفردات (lapar*/copy*) بقاموس EndoscopyTerm.
ملف العقم الزوجي: infertility + infertilitysheet (64 عموداً، 17 جدولاً يشير إليه) → InfertilityFile؛ نمط «الزوج/الزوجة» (forhusband/subject) أصل شبه عام يفيد أي تخصص يتعامل مع مرافقين (استنتاج).
المحتوى السريري للقوائم: معظم الـ 190 قائمة (بروتوكولات تنشيط، أنواع نقل الأجنة، نتائج TVS/HSG…) محتوى نسائي تخصصي يُزرع في obgy_lookups من قاعدة الإنتاج.

الفئة (ج) — للإسقاط النهائي: لا يُرحَّل ولا يُحاكى

الإطار البرمجي بالكامل: aw framework بلا front controller (مُوزِّع ?ac= في core/controllers/imp/_imp.php — 23 سطراً)، PHP 5.6.40 (منتهي الدعم منذ 2018)، Smarty 3.1.11 (2012)، RedBeanPHP 4.3 بوضع fluid في الإنتاج، صفر اختبارات وصفر git.
الثغرات الأمنية (تُصلح فوراً على القديم ولا تنتقل): حقن SQL واسع ومؤكَّد (patients.php, financialreport.php, visits.php, sonar.php)، واجهة موبايل بلا مصادقة مع CORS * (mobileservices.php — فحوص الصلاحية كلها مُعلَّقة)، لا CSRF إطلاقاً، نقاط AJAX عامة تقبل اسم الجدول/العمود من العميل، نسخ قاعدة البيانات كاملة داخل web root (core/db_backups — 1.6GB)، كلمات مرور وأسرار مكتوبة في الكود.
الجداول الميتة والمكررة (~40 جدولاً): بقايا تطوير (table2/table3/tablename/testtbl1/testtbl2/patients_tmp)، رباعية الاستنساخ ssemen/sseemen/sseemmen/sseemmeen، أرشيفات (old_visits, visits_updates, patients_updates → تستبدل بـ auditing)، جداول مشتقة (icsi, lastvisit)، يتائم (operationids, anprotocol, drugdos, importtdetails, excelinfo)، ومكتبة php-jwt غير المستخدمة.
منصة تُستبدل لا تُرحَّل: جداول aw* العشرة + programesetting + devices/floors/device_tracking/messages — تحل محلها نواة Moon ERP (مستخدمون، صلاحيات spatie، إعدادات، Sanctum).

ماذا يعني هذا لقرار «نواة HIS أم وحدة تخصصية؟»

الأصول العامة (الفئة أ) أنماط تصميم مجرّبة وليست نظاماً جاهزاً: النظام القديم نفسه يعاني عيباً معمارياً قاتلاً موثقاً في القسم 90 — السجلات السريرية لا تشير أبداً إلى الزيارة (patientid + تاريخ فقط)، أي أن نموذج «اللقاء/Encounter» الذي تحتاجه HIS غير موجود أصلاً في OBGY ويجب بناؤه جديداً.
~48% من الجداول محتوى نسائي بحت، والكود غير قابل للنقل بالكامل؛ ما يُنقل فعلياً هو: نموذج Encounter/Queue، نمط الشيت + الوصفات + طلبات المعمل، محرك Q&A، الفحص لكل جهاز، سير العمليات، ومحرك القوائم — وكلها مصممة في مخطط القسم 95 (بند 2.6) لتكون module-agnostic تستهلكها HIS.
التكاملات محسومة في المخطط: المريض هو مريض الـ ERP نفسه، المعمل عبر أحداث LabOrderPlaced/LabResultReceived إلى LIS، والصرف عبر PrescriptionDispensed إلى المخزون، والفوترة عبر VisitInvoiced إلى الحسابات.
الخلاصة التحليلية (استنتاج): تُستخرج أصول الفئة (أ) لتؤسس نواة HIS العامة، ويُبنى OBGY كوحدة تخصصية (الفئة ب) فوق تلك النواة — لا أن يكون OBGY ذاته نواة HIS.