مخطط الهجرة المنشور (§95) بُني على النسخة العيادية ذات الـ312 جدولًا، وقرار المعمارية النهائي (Platform-First) صمّم Modules/HIS كمنصة سريرية عامة وModules/Obgy كأول تخصص. اكتشاف نسخة MED (~276 جدولًا جديدًا، 9 مجالات وظيفية) لا يقلب هذا القرار — بل يؤكده — لكنه يفرض تعديلات نطاق محددة: ما يذهب إلى HIS، وما يذهب إلى Obgy، وما يُغطّيه ERP القائم أصلًا، وما يُسحب ويُتقاعد. الجدول التالي هو قائمة التعديلات الملزمة على المخطط.
| الإضافة المكتشفة في MED | الوجهة في الخطة | الجداول المقترحة / آلية الاستيعاب | الحجم |
|---|---|---|---|
التنويم وغرف العمليات (operations_rooms, residence_rooms, operations_rooms_cal, operations_main, أعمدة التنويم على visits) |
Modules/HIS — المرحلة 4 (تنويم) + جراحة P1 |
التصميم المعتمد يستوعبها كما هو: his_wards/his_rooms/his_beds/his_bed_assignments/his_encounter_movements + his_surgical_bookings. التعديل المطلوب: إضافة تقويم شرائح غرف العمليات (his_or_slots) بمنع تعارض على مستوى قاعدة البيانات (MED تكتشف التعارض في PHP فقط)، وترقية «نوع العملية» من جدول detections المشترك إلى كتالوج إجراءات حقيقي، وتوحيد محرّكي الحجز المتوازيين في كيان حجز واحد بحالة صريحة. لوحة الإشغال الحيّة وقوائم اليوم (today_list) تثبت الحاجة لشاشة أسرّة لحظية |
M |
معمل الأجنة + خزانات النيتروجين (~40 جدولًا: embryoslab, embryoscoring, embryo, tanks/tankcells/tankcellhistory…) |
Modules/Obgy — توسعة كبرى للمرحلة 2 |
المخطط الأصلي خصّص obgy_cryopreservations واحدًا فقط؛ يلزم الآن نطاق فرعي كامل: obgy_embryology_sheets، obgy_embryo_records، obgy_embryo_scorings (يوم 2–6 كصفوف his_observations حيث أمكن)، obgy_cryo_tanks، obgy_cryo_positions، obgy_cryo_custody_events (سجل عهدة على نمط tankcellhistory)، obgy_thaw_events. شرطان إلزاميان: توحيد نموذجي التخزين المتوازيين قبل الهجرة، وجعل الشاهد الثاني (double-witnessing) حقلًا إجباريًا على كل تجميد/إذابة/نقل. ~30 جدول قوائم مرجعية تذوب في his_lookups |
L |
| قوالب المناظير (14 جدولًا: معدة/قولون/بطن/رحم + قوالب + صور) | Modules/Obgy + محرّك النماذج في HIS |
أنماط القوالب الثلاثة في MED تُستبدل بمحرّك النماذج المعتمد (his_form_templates/his_form_versions غير القابلة للتعديل/his_form_responses بحالة توقيع)؛ بنك القوالب المسمّاة يصبح محتوى نسخ نماذج. obgy_endoscopy_procedures المخطط يبقى للنساء؛ مناظير الجهاز الهضمي تُسجَّل كمحتوى نماذج عام (لا جداول صلبة) تمهيدًا لبوابة «التخصص الثاني». أرشيف الصور → مكتبة الوسائط الموحّدة. يُصحَّح عيب حقن «المبيض الأيسر» في oscopic.js ولا يُنقل |
M |
عيادة الذكورة (~17 جدول and*) |
Modules/Obgy (عيادة رفيعة) + كتالوج LIS |
وفق قرار المجلس: تحاليل السائل المنوي والهرمونات تصبح فحوصات في كتالوج LIS بمدًى مرجعية WHO (andvisitssemen → نتائج LIS، لا جدول خاص). يبقى في Obgy: obgy_andrology_visits وobgy_andrology_exams (فحص سريري ثنائي الجانب) والتاريخ المرضي كمحتوى محرّك أسئلة؛ القوائم المرجعية (anddiagnosis، erectiondisease…) → his_lookups. الزيارة نفسها = his_encounters عادي |
M |
قسم الأشعة (rays/rayscats/raysresults/raysresults_img) |
ملاحظة RIS مستقبلية — المرحلة 5 عبر عقد D3 | لا جداول الآن. نمط MED (طلب → قائمة عمل → أداء → صور → إنهاء) يؤكد صلاحية عقد D3 المعتمد (Action + encounter_id + FolioChargePosted) للأشعة كما للمختبر. الكتالوج المُسعّر (rays) يدخل كتالوج الخدمات في Core عند التنفيذ؛ الصور → خدمة وسائط/PACS-lite. تنبيه توثيقي: radiation.php ليس أشعة بل خطابات تحويل/تعليمات — يُستثنى من نطاق RIS |
S الآن / L لاحقًا |
الفروع والمناطق والمنظمات (regions/sub_regions, organizations* , awusers.related_branches) |
Modules/Core القائم + توليدة التأمين في HIS P1 |
الفروع أصلًا أولّية في المنصة (company_id/branch_id على BaseModel + DataScope) — يُستبدل نطاق CSV في related_branches بربط مستخدم↔فرع القائم. regions/sub_regions → قوائم جغرافية في Core. المنظمات المتعاقدة = وحدة التأمين/B2B القائمة: organizations → شركاء أعمال + عقود، organization_discount/price_lists → قواعد قوائم الأسعار المعتمدة في HIS P1، organizations_patient_no → أرقام مرضى لكل جهة على نمط ext_scope_key، وبوابة المنظمات الخارجية تُعاد كتابتها على Sanctum |
M |
جسر أجهزة المختبر والنتائج التفصيلية (lab_devices, lab_devices_ranges, investigationresults_* ×13, saveresultslog) |
Modules/LIS القائم — تخطيط فقط |
لا جداول جديدة: LIS في Moon ERP يغطي واجهات الأجهزة وأنواع النتائج أصلًا. العمل = جدول تخطيط في الـETL يربط investid القديم وأكواد الإرسال/الاستقبال بكتالوج LIS، ويستوعب الأنواع الـ16 الخاصة (دهون/eGFR…) كنتائج محسوبة. saveresultslog → تدقيق LIS القائم. قاعدة D5 تبقى: لا تغيير في سلوك LIS |
S |
كشك تقييم رضا المرضى (6 جداول vote* + clients_votes*) |
ملاحظة CRM/جودة — خارج HIS v1 | لا يدخل نطاق الهجرة الأساسي؛ يُوثَّق كمتطلب لوحدة جودة/تجربة مريض مستقبلية (استبيانات لكل جهاز، إسناد للموظف، متابعة شكوى is_contact/reply). شكاوى المرضى (patients_complaints) ومؤشرات الانتظار تُشتق لاحقًا من طوابع his_encounters الزمنية |
ملاحظة |
الرسائل النصية والروابط القصيرة (sms_control, short_urls, مزوّدا smsmisr/naslab) |
خدمة إشعارات موحّدة في Core | قوالب الرسائل (أنواع 1–5 لكل قسم) → خدمة Notification واحدة متعددة القنوات (SMS/WhatsApp) ببيانات اعتماد في .env مع تدوير فوري للأسرار المكشوفة المكتوبة صلبًا في الكود الحالي. محرّك الروابط القصيرة يُستبدل بنمط بوابة المريض المعتمد /p/:token |
S |
طبقة مزامنة ERP القديمة (erp_common.php, api_web.php, قاعدة erpDB, مزامنة فواتير/أطباء/مديونية عبر cURL وJWT صلب) |
تُسحب وتُتقاعد | التكامل يصبح أصليًا بالكامل وفق العقود المعتمدة: المريض هو سجل lab_patients، والمال عبر his_folio_charges → ChargePostingService → CreateJournalEntry، والطبيب عبر سلسلة lab_doctors → employees → users. قيمة وحيدة تُحفظ من الطبقة القديمة: خرائط المعرّفات (obygyDetectionId/obygyVisitId/obygyPatientId) تُستخدم مرة واحدة في تسوية الـETL ثم تُهمل |
S (تفكيك) |
الإقرارات والموافقات الموقّعة (decleration/patientdecleration + ملفات مرفوعة) |
محرّك نماذج HIS + مكتبة وسائط | قوالب الإقرار → his_form_templates (نسخ غير قابلة للتعديل)، والإقرار الموقَّع → his_form_responses بحالة signed، والمسح الضوئي → مرفق وسائط موثّق |
S |
جدولة العيادات وتتبّع الملفات (clinic_rooms/clinic_reserves, archive_tracking/archive_request) |
Modules/HIS P1 (جدولة) + ملاحظة سجلات طبية |
الجدولة الأسبوعية طبيب×غرفة×ساعة تؤكد صواب قرار «أعمدة الموارد من اليوم الأول» على his_appointments — تُستوعب دون جداول إضافية. تتبّع حركة الملفات الورقية بالماسحات يبقى ملاحظة تصميم لوحدة السجلات الطبية (كما كان مقررًا لجداول devices/floors)، مع الاحتفاظ بنمط سير العمل رباعي المراحل بتدقيق لكل مرحلة كقالب لوحدة تتبّع الطلبات |
S |
كل خطة الـETL في §95 افترضت قاعدة إنتاج واحدة. أصبح لدينا نشرتان إنتاجيتان بمخططين متباعدين: قاعدة العيادة الأصلية (312 جدولًا) وقاعدة MED (medgreennatureco_med، +276 جدولًا وأعمدة إضافية كثيرة على الجداول المعروفة مثل visits الموسّع). التعديلات الملزمة:
legacy_db إلى جانب legacy_id/legacy_table، مع قاموسي تخطيط أعمدة منفصلين (مخطط visits وحده يختلف جوهريًا بين النسختين).lab_patients: نفس المريض قد يوجد في القاعدتين (أداة syncstructure.php وأسماء القواعد المتعددة فيها تثبت تاريخ نقلٍ بين النسخ) — إلغاء التكرار بالهوية الوطنية/الهاتف/الاسم+الميلاد مع طابور مراجعة بشرية (توسعة R10).SHOW CREATE TABLE على قاعدة MED (بتصريح) قبل اعتماد أي تخطيط نهائي.operation_details، بوابة API خارجية بمصادقة معطّلة، وكتابة جداول/أعمدة بأسماء قادمة من المستخدم — تُعالج في المرحلة 0b على نشرة MED أيضًا، ولا يُنقل أي endpoint قديم.syncstructure، excelread) موجودة في مسار الإنتاج — تُستبعد من أي نقل وتُعطَّل فورًا.الخلاصة الإدارية: لا تغيير في المعمارية المعتمدة ولا في تسلسل المراحل — التغيير في النطاق والحجم: المرحلة 2 (Obgy) تكبر بمعمل الأجنة والذكورة، والمرحلة 4 (تنويم) تكتسب نموذجًا مرجعيًا حيًا من MED، والـETL يصبح ثنائي المستأجر. اكتشاف MED يرفع كلفة الترحيل قليلًا لكنه يرفع اليقين كثيرًا: المورّد القديم أثبت بالفعل أن طريق «العيادة → المستشفى» هو ما يطلبه السوق.