المنصة الطبية الموحّدة

الخلاصة

المشكلة: كل تخصص (عام، تغذية، أسنان، مستشفى، والنسا اللي جاي) بنى جزء من الحاجات المشتركة بطريقته. النتيجة إن الدكتور بيلاقي نفس الحاجة في مكان مختلف وشكل مختلف. والبيانات اتكررت: العلامات الحيوية في 5 أماكن، والحساسية في 4، والأمراض المزمنة في 5، والأدوية في 5، والتشخيص في 5. ومفيش شاشة «أول زيارة» خالص. وكل تخصص جديد بيكبّر الملخبطة.

الحل في 3 طبقات: 1. البيانات (الطبقات الأربعة): كل حقل يتوصف بحاجتين: للمريض أو للزيارة، ومشترك أو خاص بتخصص. - محرك حقول واحد، وهو موجود ومتوسّع جزئياً. - مخزن واحد للحقائق، ومخزن واحد للقياسات المتكررة (العلامات الحيوية وجولات التمريض وInBody). - الحساسية والأمراض والأدوية الخارجية ليها جداول منظّمة. كل تكرار من الـ13 ليه مالك واحد. 2. الشاشة (كروت قابلة للتخصيص): كل حاجة في الشاشة «كارت»، وكل تخصص ليه شكله الافتراضي: التغذية = البورد اللي الدكتور طلبه زي ما هو بالظبط، والأسنان = الشارت بكل تفاصيله، والعام والنسا = خطوات مرتبة. الترتيب بيتحدد على 3 مستويات: افتراضي التخصص ← العيادة ← الدكتور، ووضع «تخصيص الشاشة» بيخلّي كل دكتور يرتّب ويكبّر ويخفي ويضيف كروت. والثابت في كل الأشكال: الهيدر بالتنبيهات، و«أول زيارة»، والتوقيع والقفل، والملخص، والروشتة والطلبات والتشخيص بنفس الكود. - التخصص بيعلن كروته وشكله الافتراضي في registry، والتوحيد بيبقى في البيانات والمكوّنات والقواعد، مش إن كل الشاشات تبقى شبه بعض. - المستشفى «سياق» بيضيف محطات التمريض والأدوية والخروج فوق أي تخصص. - شاشة «أول زيارة» على خطوتين: المشترك مرة واحدة، والتخصص مرة واحدة عند أول دخول ليه. 3. البلوكات المشتركة (Clinical Core): روشتة واحدة (والمستشفى بيستخدمها)، ومنفّذ واحد للتحاليل والأشعة، والأشعة بتقريرها وصورها، ومستندات موحّدة (إجازة، تقرير، شهادة، ملخص خروج)، وتنبيهات، وطباعة PDF واحدة.

عيادة ولا مركز ولا مستشفى: نفس الكود، والفرق إعدادات بس. والتحكم في الشكل والحقول لكل عميل (مركز يشيل كروت أو حقول، ومركز تاني يسيبها)، وتخصيص الدكتور لنفسه اختياري بإعداد من العميل.

النسا (العميل الجديد): تحليل النسا متدمج جوه المنصة. 6 من جداوله المقترحة موجودة أصلاً في المنصة، و4 بقوا كيانات مشتركة (الحلقات، العمليات، المتابعات، التحويلات + مولّد الملخص)، و3 بس فاضلين خاصين بالنسا (الحمل السابق، الحمل، دورات العلاج). وفيه 13 مرحلة ★ لازمة علشان العميل يشتغل، ومنها الأمان «قبل التشغيل».

إزاي تقرا الخطة

تصحيح بعد مراجعتك (2026-10-21): النسخة الأولى كانت بتفكّك بورد التغذية لمحطات، وبتختصر الأسنان. اتصلّحت: الشكل الحالي لكل تخصص هو الافتراضي زي ما هو، والتخصيص بيبقى طبقة فوقه.

اتساق بين التصاميم (اتظبط هنا): (١) اسم نوع النسا = gyn_ob في كل الوثائق. (٢) الحمل = حقل زيارة مشترك (طبقة ٣) يتملى مسبقاً 30 يوم، مش حقل تخصص. (٣) التنبيهات patient_alerts اتقدمت من P5 لـ D2. (٤) محرك الحقول الديناميكية (م6) شغّال فعلاً، فبنكمّله ومش بنبنيه من الأول.

١ · النموذج التفاعلي

جرّب: التغذية (بورد الدكتور زي ما هو)، والأسنان (الشارت وكل الشاشات الفرعية)، والعام والنسا (خطوات). اختار الطبيب (د. هبة بالافتراضي، ود. سارة بترتيبها الخاص)، وشغّل «تخصيص الشاشة» علشان ترتّب وتكبّر وتخفي وتضيف كروت وتحفظ لنفسك أو للعيادة. وجرّب كمان السياق «إقامة مستشفى»، و«أول زيارة»، وتابلت وموبايل. وتحت النموذج لوحة الـ Registry: دي اللي كل تخصص بيعلنها، ومنها بيتحسب شكل الشاشة.

افتح النموذج في صفحة كاملة ↗

بيانات تجريبية · الحفظ في المتصفح بس.

المراحل الموحّدة

ترتيب واحد يجمع التصاميم الثلاثة وتحليل النسا والتوليد والأمان (النسخة 3). P = البلوكات المشتركة، D = البيانات، S = الشاشة، E = المحرك، C = الكيانات الإكلينيكية المشتركة، G = النسا، SEC = الأمان. كل مرحلة بتتسلّم شغّالة وبتختبرها بنفسك على /app، والهيكل الجديد بيشتغل جنب الشاشة القديمة خلف الإعداد clinic.visit_shell لحد ما توافق.

★ = لازمة لتشغيل عميل النسا (عيادة بوضع عمليات برّه). النسا مش موديول لوحده: 6 من كياناته موجودة في المنصة، و4 بقوا مفهوم مشترك (الحلقات، العمليات، المتابعة، الملخص)، و3 بس جداول خاصة بيه. التفاصيل في تصميم الدمج (design-gyn-integration.md).

الأحجام: S ≈ أيام قليلة · M ≈ أسبوع · L ≈ أسبوعين أو أكتر (بتتقسم WPs). المراحل الـ ★ (13 مرحلة) ≈ 3–3.5 شهور متصلة لحد ما عميل النسا يشتغل؛ الكل ≈ 6–7 شهور. كل مرحلة ليها قيمة لوحدها، وممكن نقف بعد أي مرحلة. SEC1 ممكن تتعمل بالتوازي مع P0/D0 لأنها ما بتلمسش ملفات العيادة.

بعد كده: بوابة المريض تملا الـ intake · نقل dental_recalls ومتابعة التغذية على follow_up_tasks · طلبات المعمل من بوابة.

ننفذ فين — هنا (moonui3) ولا في moonui؟

✅ اتقرر (2026-10-21): هنا في moonui3، وmoonui متوقف لحد ما نخلص. اللي تحت هو التحليل اللي القرار اتبنى عليه، سايبينه للعلم.

الحقايق من تاريخ الكود (من منتصف سبتمبر): - موديول العيادة والتغذية: معظم الشغل من moonui، زي الروشتة والكالندر والأجهزة والخزينة وكشف التغذية الكامل (Nutrition كله بتاعه). وكمان LIS والحسابات. - moonui3 (هنا): إطار نوع التخصص (clinical_type)، والمستشفى كامل، والأسنان، وتحليل النسا، والتحليل ده. - الـ KB مش بيتزامن بين الحسابات. الخطة دي موجودة هنا بس، ولو اتنفذت في moonui لازم تتنقل يدوياً (rsync منك). - الخطة دي بتلمس الملفات الأكتر ازدحاماً: شاشة الكشف، والروشتة، والتاريخ المرضي، والعلامات الحيوية، وقارئات التغذية. لو اتنين اشتغلوا عليها في نفس الوقت، كل دمج هيبقى فيه تعارضات.

القرار: (أ) — moonui3 ينفّذ كله، وmoonui متوقف. - moonui3 ماسك موديول العيادة المشترك والنسا والأمان طول المراحل. - تعديلات التغذية (قراية القياسات، الشكوى والتشخيص، الحساسية الغذائية) بتتعمل هنا بالاتفاق مع المالك، لأن moonui واقف. - merge لـ main بعد كل مرحلة، علشان لما moonui يرجع يبني على الجديد على طول. - الـ KB بتاع الخطة دي هنا بس؛ لما moonui يرجع يتنقل له يدوياً (rsync).

القرارات المجمّعة (المنصة + النسا — 36)

✅ = اتقرر · ⏳ = مستني منك · 👩‍⚕️ = مستني من الدكتورة (عميلة النسا)

القرارات التفصيلية كلها موجودة في كل تصميم: 13 قرار للبلوكات، و13 قرار للبيانات، وجدول المطابقة الكامل في تصميم دمج النسا.

Visit Shell — مواصفة UX لقشرة الزيارة الموحّدة (v3)

تصميم فقط — 2026-10-21 (مراجعة ثالثة بعد توضيحات المالك: العميل هو مستوى التحكم الأساسي، والنسا على تحليل المالك الحقيقي). النموذج التفاعلي: visit-shell-prototype.html (نفس المجلد). المراجع: r4-fields-screens.md §G، design.md §5، knowledge-base/topics/dental-module.md، nutrition-consult-board.component.html، knowledge-base/plans/gyn-obstetrics-module.html + مصادره gyn-obstetrics-module-src/p3a…p3g (schema)، p4a/p4b (engine)، p4c (scenarios).

1. الفكرة في ثلاثة أسطر

التوحيد = بيانات مشتركة + كومبوننتات مشتركة + قواعد مشتركة — مش شكل صفحة واحد. الهيدر والتنبيهات، الاستقبال الأول (intake)، التوقيع والقفل، الملخص الحي، وكومبوننتات الروشتة/التحاليل/الأشعة/التشخيص/المستندات واحدة في كل التخصصات. شكل المساحة الرئيسية layout من كروت: لكل تخصص افتراضي يناسبه (التغذية = لوحة الدكتور ذات الشاشة الواحدة كما هي، الأسنان = workspace الفكّين + شريط الكشف كما اتوافق عليه، العام والنسا = تسلسل محطات + كروت النسا الديناميكية)، والعميل (المركز/العيادة) هو اللي يشيل/يرتب/يخفي حقول ويقفل مجموعات مزايا، والدكتور يخصّص لنفسه بس لو العميل سامح. الـ @switch (747 سطر) يتحول لـ shell + كتالوج كروت + layout محلول، والكومبوننتات التخصصية الموجودة تتستضاف زي ما هي.

2. تصحيح: التخصص يملك شكل شاشته — والعميل يتحكم فيه

توضيحات المالك: (1) لوحة التغذية من تفاصيل الدكتور نفسه وهو طالبها كده — ما تتحلّش. (2) الأسنان فيها تفاصيل كتير — ما تتختزلش. (3) «لما قلت التحكم طبقاً للطبيب كنت أقصد العميل — مركز بيشيل حاجات ومركز تاني لأ». (4) النسا لازم تعكس تحليل المالك الحقيقي للعميل الجديد (51 module، categories، show_if، ملخصات).

2.1 كتالوج الكروت (Widget catalog)

كل بلوك = كارت له id، عنوان، أحجام (S|M|L|F)، كومبوننت، نوع، وfeature اختيارية (بتربطه بمجموعة مزايا العميل): - مشترك: الهيدر+التنبيهات (مثبّت)، العلامات الحيوية (full|compact|readonly)، الشكوى، التاريخ (patientScopeOnly)، التشخيص، التحاليل، الأشعة، الروشتة (kind)، المستندات، الزيارات السابقة، الأدوية الحالية، النتائج بالتاريخ، الملاحظات، الصور، المتابعة، حالة الـ intake، سكة الطلبات، الملخص الحي. - تخصصي: تغذية (13 كارت اللوحة + التقدم نحو الهدف) · أسنان (الفكّين بكل الـ sub-views، الزيارة دي، الفحص، الخطة، اللثة، FMX، التقويم، المعمل، Recall) · نسا (التصنيفات، مضيف الـ modules، الخط الزمني، مولّد الملخص + 41 module غير-core كل واحد كارت قابل للإضافة gyn_<key>). - سياق (الإقامة): MAR، التمريض/الجولات، الخروج.

2.2 عقد الـ layout (TS)

export type CardSize = 'S'|'M'|'L'|'F';
export interface CardDef { id: string; titleKey: string; kind: 'shared'|'spec'|'ctx'; spec?: ClinicalTypeKey; component: Type<unknown>;
  sizes: readonly CardSize[]; required?: boolean; requiredWhen?: 'insured'; feature?: string; /* dental.feature.* / gyn.feature.* */ priv?: boolean; }
export interface LayoutCard { id: string; col: number; order: number; size: CardSize; collapsed?: boolean; props?: Record<string, unknown>; }
export interface VisitLayout { version: number; columns: readonly string[]; flow: boolean; cards: LayoutCard[]; }
export interface FieldRule { visible?: boolean; required?: boolean; input?: 'select'|'text'|'chips'; }  // input = تبديل نوع الإدخال للحقل (من Program Setting في نظام عمرو: Select ⟷ Text)
export interface ClientProfile { allowDoctorOverride: boolean; /* clinic.layout.allow_doctor_override — default false */
  layouts: Partial<Record<ClinicalTypeKey, VisitLayout>>;                         // clinic.layout.{type}
  fields: Record<string /* pack code */, FieldRule>;                             // clinic.fields.{type}
  features: Partial<Record<ClinicalTypeKey, Record<string, boolean>>>; }           // {type}.feature.*
export interface ClinicalTypeDef { key; labelKey; descriptionKey; layout: VisitLayout; actions?: readonly string[];
  vitalsPack; historyPack; intakePack; intakeRefs?; alerts?; settings?: { features?: Record<string, boolean>; [k: string]: unknown }; }
// resolveLayout(type, ctx, client, doctor?) → VisitLayout + per-card from: 'default'|'client'|'doctor'|'context'|'required'

2.3 الحلّ: default → client → (doctor لو مسموح) → context

1. الافتراضي من الـ registry (كود). 2. العميل: clinic.layout.{type} (ترتيب/حجم/إخفاء كروت) + clinic.fields.* (إخفاء/إلزام حقول الباقات) + {type}.feature.* (قفل مجموعات: اللثة/التقويم/المعمل في الأسنان، الخصوبة/التوليد/Urogyn/Sexual/الأورام في النسا) — يضبطها أدمن العميل بصلاحية clinic.layout.manage. 3. الدكتور — موجود فقط لو clinic.layout.allow_doctor_override=true عند العميل (الافتراضي off)؛ تفضيل شخصي في settings بـ user_id. 4. السياق (الإقامة) يضيف كروته. كل مستوى يستبدل اللي قبله كاملاً (مش merge) وله «إعادة الافتراضي». التحقق: كارت مجهول/تخصص تاني/feature مقفول → يُسقط · required → يُعاد في الأول · حجم غير مسموح → يُصحح · version أقل → migration. الحقول المخفية عند العميل تختفي من الـ intake ومن الكروت معاً (مصدر واحد)، والإلزامية تظهر بـ * وتُفرض عند التوقيع.

2.4 وضع «تخصيص الشاشة»

شريط لكل كارت (↑↓ · ◀▶ · الحجم · مطوي · إخفاء إلا الإلزامي) + «إضافة كارت» من الكتالوج مفلتراً بالتخصص ومزايا العميل. الحفظ: «حفظ للعميل (المركز)» هو الأساسي؛ «حفظ لي» يظهر فقط لو العميل سامح. مفتاح العميل في الـ shell (مركز النور يسمح للدكتور ويشغّل كل المزايا · عيادة د. منى تقفل اللثة/التقويم/المعمل وUrogyn/Sexual، تشيل 3 كروت من لوحة التغذية، وتخفي/تُلزم حقول) يبيّن الفرق فوراً، ولوحة الـ registry تطبع مصدر كل كارت.

2.5 المحطات = خاصية layout

flow: true = كروت العمود محطات مرتّبة (ترقيم، «تم ✓» يطوي لسطر ملخص، Ctrl+Enter/Alt+↑↓) — العام والنسا. flow: false = لوحة — التغذية والأسنان. التوقيع (Alt+F) والتحذيرات الناعمة واحدة.

2.6 عرض الخيارات = «pick-don't-type» مُركّز (مستفاد من نظام عمرو القديم)

المشكلة في v3: الاختيارات كانت كلها مفرودة ومعروضة (chips طويلة، كل module في النسا كارت ظاهر، قوائم خيارات دايماً مفتوحة) → الشاشة تتخم. الحل المعتمد من نظام عمرو (مع تفادي عيوبه): - الخيار = select/picker مُركّز مش قائمة مفرودة. المعروض = الملخص المختار بس + زر «＋ اختيار / بحث» يفتح picker مركّز (dialog/popover). الـchips تفضل للمختار فقط. - الـpickers الثقيلة ورا أزرار (زي HISTORY / EXAMINATION / INVESTIGATIONS عندهم): التاريخ، الفحص، الفحوصات، التشخيص — كلها تفتح من زر في picker فيه بحث + المفضّلة (★) فوق + تجميع بالفئة + اختيار متعدد + صف inline «＋ إضافة جديد» يكتب مصطلح في الكتالوج بصلاحية. - picker الفحوصات = شبكة فئات (يطابق investcats→invests): فئات بـ display_order تتفرد لفحوصاتها، اختيار متعدد، مفضّلة، مطوية افتراضياً. - الروشتة = دواء + جملة افتراضية (Rx v2): اختيار الدواء من الكتالوج → جملة الجرعة العربية الافتراضية تتملى في حقل قابل للتعديل؛ «تكرار» يكلِّن صف بجملة بديلة. صف واحد مُركّز لكل دواء. - المفضّلة لكل دكتور (مش install): ★ على أي خيار = مفضّلة شخصية تطفو فوق في المرة الجاية — جدول clinical_lookup_favorites(user_id, lookup_key, value_id). - تبديل نوع الإدخال للحقل (FieldRule.input = select/text) زي Examination Controller عندهم: العميل يقرر الحقل يتعرض dropdown من الكتالوج ولا نص حر.

تفادي عيوبهم (حُرّاس): (أ) كتالوج lookup واحد مُدار بـ lookup_key — ممنوع جدول lookup مستقل لكل حقل (هُم عندهم عشرات: examinationhead/chest/abdomen/pelvis, husbndiagnosis1/2/3…). (ب) الاختيار المتعدد = صفوف ربط مُطبّعة (مثلاً encounter_diagnoses) — ممنوع تخزين CSV في عمود واحد (diagnosisid="3,7,12") لأنه بيكسر التقارير. الـchips في الـUI مدعومة بصفوف، مش بسترينج.

مصدر كل picker مختلف — مش كله من الكتالوج العام: - المصطلحات الإكلينيكية (شكوى، فحص، تشخيص، أسئلة تاريخ) → كتالوج clinical_lookups العام بـ lookup_key. - الأدوية → فورمولاري clinic_drugs (drug_name/form/active_ingredient + الجملة use_note + clinic_drug_presets)، كل دواء مربوط اختيارياً بمنتج مخزون (product_id) حسب clinic.pharmacy_source (products ⟷ standalone_formulary). الروشتة تشاور على clinic_drug_id أو drug_id (مش lookup عام). تفاصيل design.md §4.1. - التحاليل/الأشعة → كتالوج LIS (LabInvestigation + LabInvestigationCategory + LabPackage) / كتالوج الأشعة (rad_procedures)، موصولة للعيادة عبر جسر clinic_catalog (lis_investigation_id/rad_procedure_id) بالتسعير. تفاصيل design.md §4.2/4.3.

الطلب ≠ التنفيذ (حدّ واضح): كروت التحاليل/الأشعة/الروشتة في الزيارة بتعمل طلبات/نيّة بس (service_order_lines status=Ordered / prescriptions status=issued). التنفيذ سطح منفصل: LIS بيعمل LabRequest بدورة حياته (sample_collected → in_progress → resulted)، والصيدلية بتصرف (dispense_status) — ويقدر يسحب طلبات الطبيب كتسهيل من غير ما ينفّذ/يصرف الكل. النتائج ترجع للزيارة أوتوماتيك لو اتعملت جوّه السيستم، أو إدخال يدوي لو من بره (clinic.results.external + مسار LabExternalLab*). الربط بـ fulfillment_type/fulfillment_id.

2.7 شاشة إعدادات العميل = تعميم «Program Setting»

نظام عمرو أثبت إن كود واحد يتقاد بجدول إعدادات (إظهار/إخفاء عناصر، تشغيل تابات، Select/Text لكل حقل، سويتش Clinic/Hospital، General/Gynecology). إحنا نعمّمه: نفس الأفكار بس لكل عميل ← الدكتور (اختياري) عبر ClientProfile (layouts/fields/features) + FieldRule.input + Hospital = context (مش تخصص). شاشة الإعداد تعرض: كروت التخصص (ترتيب/حجم/إخفاء)، قواعد الحقول {visible, required, input}، ومجموعات المزايا {type}.feature.*.

3. النسا والتوليد — كروت ديناميكية من تحليل المالك

• المصدر: schema النسا (p3a…p3g) كما هو: 8 مجموعات (core/gyn/fert/op/ob/uro/sex/fu)، قوائم التصنيفات (CATS)، 51 module بأقسامها وحقولها وshow_if، أنواع الملخص العشرة. مضمّن في النموذج حرفياً: الفهرس الكامل (51) + 8 modules كاملة التفاعل (الرحم والألياف Myoma 1..n FIGO، العقم، دورات التنشيط OI ككروت، الحمل EDD/GA تلقائي، VTE score RCOG 37a، POP-Q بحساب الـ Stage، Urodynamics، Sexual history 🔒) + قيم السيناريوهات (p4c).
• كارت التصنيفات (app-gyn-category-picker، إلزامي): تابات GYN / الخصوبة / الحمل والولادة / Urogyn / Sexual 🔒 — كل تاب chips اختيار متعدد؛ المجموعة المقفولة بـ gyn.feature.* تختفي ومعها categories وmodules بتاعتها.
• مضيف الـ modules (app-gyn-module-host، إلزامي): يقيّم show_if (cat / mod.key eq|in|has|truthy / any|all) بنفس محرك p4b ويرسم الـ modules المفتوحة ككروت فرعية بنفس محرك الحقول (text/num/date/seg/sel/chips/bool/calc/repeat/table/figo/popq/media) مع شارة «اتفتح من الاختيار». الـ core modules (profile/alerts/history/obhx/menstrual/complaint/exam/imaging/team/dx) = الكروت المشتركة في الـ shell — ما بتترسمش تاني.
• الكارت الخاص (Sexual health): لون داكن + قفل + صلاحية gyn.sexual.view + «يُسأل على انفراد»، ومستبعد من كل أنواع الملخص بما فيها Couple.
• مولّد الملخص (app-gyn-summary): Clinic / Fertility / Operative / Antenatal / Delivery / Discharge / Follow-up / UDS / Urogyn / Couple (no private) — يجمع قيم الـ modules المفتوحة بأسماء الحقول + سطر «من الكروت المشتركة». الخط الزمني (app-gyn-timeline): زيارات/دورات/عمليات/حمل.
• أي module من الـ 41 قابل للإضافة ككارت مستقل من الكتالوج (gyn_cs، gyn_ivf…) بغض النظر عن show_if، ويحمل feature مجموعته.

4. مناطق الشاشة

App bar (المسار · العميل · الطبيب · layout: flow/board · من default/client/doctor · encounter.kind) · هيدر المريض sticky بالتنبيهات دايماً · سكة البداية (230px؛ drawer على التابلت/الموبايل) · المساحة الرئيسية (layout محلول + رأس اللوحة بأزرار الـ dialogs) · سكة النهاية (الملخص الحي + الفاتورة) · Footer (تقدم/عدد الكروت · طباعة · كاشير · إنهاء). الأعمدة من layout.columns؛ التابلت عمودان والثالث ينزل، الموبايل عمود واحد.

5. تشريح الكارت

رأس: أيقونة/رقم · العنوان · 🔗 مشترك / 🏷 خاص / سياق · الطبقة · مصدر الكارت (افتراضي/العميل/الدكتور/سياق/إلزامي) · الملخص عند الطيّ · «تم ✓» في flow. الحالات: مفتوح/مطوي · flow: todo → active → done · بعد التوقيع read-only. كل كارت تخصصي يلتزم بـ [encounterId] [patientId] [locked] ويصدر summary$.

6. طبقات البيانات

١ مريض مشترك (lab_patients + 7 أسئلة + حساسية + مضاد تجلط — intake خطوة ١) · ٢ مريض تخصصي (nut_/dent_/obgy packs — intake خطوة ٢؛ المراجع المشتركة لا تُسأل تاني) · ٣ زيارة مشترك (علامات، شكوى، تشخيص، طلبات، روشتة، مستندات، متابعة) · ٤ زيارة تخصصي (الأوزان/InBody، الفكّين/الخطة/اللثة، modules النسا، MAR/الجولات). حقول الطبقتين ٢ و٤ بتخضع لقواعد العميل {visible, required}.

7. قواعد التفاعل

حفظ تلقائي (debounce) · الملخص الحي من نفس الـ signals · إنهاء الزيارة = تحذيرات ناعمة (منها «التشخيص مطلوب للمطالبة» لو المريض مؤمّن والكارت مش في اللوحة) ثم توقيع؛ القفل من الـ BE · Addendum بعد التوقيع · التنبيهات من patient_alerts · أزرار الـ dialogs تفتح نفس الكومبوننتات المشتركة · لوحة المفاتيح في flow.

8. الاستقبال الأول

نفس الـ wizard لكل التخصصات: خطوة ١ مشتركة → خطوة ٢ intakePack التخصص؛ الحقول المخفية عند العميل لا تظهر، الإلزامية بـ *. الشارة في الهيدر تفتح خطوة ٢.

9. من شاشات النهاردة للـ shell

10. الاستجابة والـ RTL وإمكانية الوصول

تابلت: لمس ≥ 44px، لوحتان، الفكّين فوق لوحة السنة. موبايل: عمود واحد، تمرير أفقي للفكّين وشارت اللثة، ملخص sticky. RTL أولاً؛ الأرقام/الأكواد/الـ popq grid ltr. رؤوس الكروت button بـ aria-expanded، الحالة بالنص، تباين ≥ 4.5:1؛ الكارت الخاص يحمل aria-label بالقيد.

11. مخزون الكومبوننتات (FE)

جديد (الـ shell): app-visit-shell (resolveLayout + grid + flow) · app-visit-header · app-visit-card · app-visit-layout-editor (تخصيص + كتالوج + حفظ بالمستوى) · app-visit-rail-start · app-visit-summary-rail · app-visit-intake-wizard · app-visit-finish-panel · app-clinic-exam · app-clinic-complaint. نسا (جديد من الخطة): app-gyn-category-picker · app-gyn-module-host (محرك p4b: ev + fieldHTML + calcs) · app-gyn-summary · app-gyn-timeline. يُعاد استضافته بلا تغيير ككروت مشتركة: app-clinic-vitals-panel · app-clinic-history-panel · app-clinic-diagnosis-panel · app-clinic-lab-orders · app-clinic-rad-orders · app-clinic-prescription · app-clinic-previous-visits · app-referral-dialog · app-external-result-dialog · app-lab-history-groups · app-clinic-dynamic-field-renderer · app-clinic-service-order-rail. يُعاد استضافته ككروت تخصصية: تغذية: app-nutrition-patient-panel، app-nv-* cards، app-patient-body-comp، app-nutrition-plan-builder… · أسنان: app-dental-workspace (+ app-odontogram، app-dental-perio، app-dental-fmx، app-dental-ortho، app-dental-plan-panel)، app-dental-today، app-dental-exam، app-dental-lab-board، app-dental-recall · إقامة: app-nursing-panel. يتفكك/يتشال: الـ @switch · app-nutrition-consult-board كصفحة · app-dental-alerts · التضمينات المكررة في clinic-patient-file.

12. ترتيب التنفيذ المقترح

1. CARD_CATALOG + VisitLayout + ClientProfile + resolveLayout + app-visit-shell بالعام خلف clinic.visit_shell=true.
2. السكك + الملخص + إنهاء/توقيع (قفل BE من design.md P0) + app-visit-layout-editor (العميل أولاً، الدكتور خلف الإعداد) + قواعد الحقول.
3. الأسنان (الافتراضي = workspace + consult) → التغذية (بالاتفاق مع moonui) → النسا (picker + host على schema p3 + summary).
4. سياق الإقامة (بعد P2) → الـ intake wizard + patient_alerts (P5).

دمج النسا والتوليد في المنصة الإكلينيكية الموحّدة

تصميم فقط — 2026-10-21. بيكمّل design.md (البلوكات) وdesign-data-layers.md (البيانات) وdesign-visit-shell.md (الشاشة) وmaster-plan.md. المرجع للنسا: plans/gyn-obstetrics-module.html (المصدر -src/p3a…p3g, p4a, p5-bottom) + clinic-dynamic-fields.md + gyna-reference.md. كل ادّعاء عن الكود اتفحص (file:line).

---

1. الخلاصة وقرارات الدمج

النسا مش موديول بشاشة لوحده — هي أول تخصص «كبير» بيركب على المنصة زي ما هي. تحليل النسا كان بيقترح 15 جدول + مجموعة آليات (قيم، تنبيهات، ملاحظات، ميديا، متابعة، audit، summary). بعد المطابقة مع التصاميم التلاتة: 6 منهم موجودين فعلاً في المنصة، 4 بيتحوّلوا لمفهوم مشترك (episodes، procedures، follow-up، summary)، و3 بس بيفضلوا جداول خاصة بالنسا (obstetric_history_rows، pregnancies، treatment_cycles + صف المتابعة). الباقي (POP-Q، PROMs، UDS، antenatal visits) بيتخزن في المخازن الموحّدة (القياسات / الإجابات / المستندات) ومفيش جداول ليه.

قرارات الدمج الأساسية (8):

1. مفيش clinical_field_values. القيم كلها في patient_history_answers (قرار data-layers §3.2) مع alias ClinicalFieldValue. الامتداد الوحيد المطلوب للنسا: scope تالت = record (قيم مربوطة بعملية/دورة/حمل) — تفاصيله في §4.
2. التحكم في الشكل والحقول لكل عميل أولاً (تعليمات المالك): default (كود) ← company (الأدمن) ← doctor بس لو clinic.layout.allow_doctor_override=true (الافتراضي false) ← context. الحقول نفسها بنفس الآليات الموجودة: is_active/is_required على التعريف المنسوخ للشركة + clinic.patient_form_fields {visible,required} + {type}.feature.*. مفيش آلية جديدة.
3. موديولات النسا الـ 51 = كروت في الكتالوج بتتولّد من الباقة (module_key)، وshow_if بتاع الموديول هو اللي بيفتحها ويقفلها إكلينيكياً، وgyn.feature.* بيشيل مجموعات كاملة للعميل اللي مش محتاجها.
4. الموديولات الأساسية بتاعة النسا (complaint/exam/imaging/dx/team) = الكروت المشتركة نفسها + حقول L4 من باقة gyn_ob بـ show_if على اختيارات الشكوى. مش كروت نسا منفصلة — وإلا نرجّع تكرار الشكوى والتشخيص اللي بنحلّه.
5. العمليات = clinical_procedures في الكور (قرار المالك 2026-10-20، GYN §7.6)، والـ 5 جداول الكيانية المشتركة (episodes، procedures، follow_up_tasks، referral الممتد، summary) بتتبني مرة في مرحلة كور جديدة C1 قبل أول مرحلة نسا.
6. الحمل والقياسات مش بيتكرروا: pregnancies جدول (كيان له حالة)، لكن زيارة المتابعة = encounter عادي في episode الحمل + قياساتها (BP/وزن/FHR/FH) في clinical_observations. مفيش antenatal_visits.
7. الأمان مرحلتين مستقلتين (SEC1, SEC2) + مرحلة تشفير ونسخ (SEC3) — كلهم قبل تشغيل عميل النسا، والأغلب platform-wide مش نسا.
8. كود النسا في Modules/Gyn + features/gyn (نفس نمط Dental/Nutrition)، والكور في Clinic. الباقة packs/gyn_ob بتتبذر بـ updateOrCreate(company_id, code) زي باقي الباقات.

---

2. جدول المطابقة — كل كيان في GYN §7 ومكانه في المنصة

الاختبار الواحد اللي اتطبّق على كل جدول: هو (أ) كيان له دورة حياة وحالة وتواريخ → جدول؛ (ب) قياس بيتكرر بالزمن → clinical_observations؛ (ج) نص بيتولّد ويتوقّع → clinical_documents؛ (د) حقول فورم → إجابات المحرك.

---

3. الموديولات ككروت + التحكم لكل عميل

تلات آليات رؤية، كل واحدة ليها دور ما يتداخلش مع التانية:

تصحيح لازم في D0: ClinicProfilePackService.php:78-79 بيكتب is_active=true, is_required=false جوه قيم الـ updateOrCreate → أي إعادة تطبيق للباقة (تحديث MoonStack أو زرار «تطبيق باقة») بترجّع الحقول اللي العيادة خبّتها. القاعدة: الأعمدة دي تتكتب عند الإنشاء بس.

إزاي الـ 51 موديول بيبقوا كروت: الباقة بتبذر التعريفات بـ module_key، والـ registry بيولّد CardDef لكل module_key (kind:'spec', spec:'gyn_ob', feature:'gyn.feature.X', showIf:<module show_if>). الكارت بيتعرض بـ app-clinic-dynamic-field-renderer مفلتر بالـ module — مفيش كومبوننت لكل موديول. اللي ليه كومبوننت خاص: obhx (جدول الحمل السابق)، oi/ivf (كروت الدورات)، antenatal (flowsheet)، popq (ودجت)، operation (شاشة الـ procedure)، team (الإحالات)، timeline.

الـ layout الافتراضي gyn_ob: عمود ١ flow:true (محطات): القياسات 🔗 → الشكوى 🔗 (+ أسئلة النسا الشرطية) → التصنيفات (gyn_categories — chips لكل مجموعة مفعّلة؛ required) → الفحص 🔗 (+ فحص النسا) → الفحوصات المنظّمة (gyn_imaging) → التشخيص 🔗 → التحاليل/الأشعة/الروشتة 🔗 (الروشتة بـ subjectEnabled) → الإحالة/الفريق → المتابعة. عمود ٢ (flow:false): كروت الموديولات اللي show_if بتاعها صحيح، بترتيب المجموعات؛ الدورات والعمليات والحمل كروت قابلة للتكرار (صف لكل كيان). السكة: الهيدر فيه G/P/A/L + EDD/GA + التنبيهات؛ الـ timeline؛ الملخص الحي. فين الـ cat: اختيارات التصنيفات بتتخزن كإجابات L4 gyn_cat_{group} على الزيارة ∪ categories بتاعة الحلقات المفتوحة — وده اللي الـ evaluator بيقرا منه (النموذج كان بيحطها في state عام بلا بيت).

عميلين مختلفين: مركز A بيطفّي gyn.feature.urogyn وgyn.feature.sexual → chips الـ uro/sex وكروت الـ 13 موديول وصلاحيات gyn.sexual.* وقوالب الـ summary بتاعتهم بتختفي، ومفيش حاجة تتمسح. مركز B سايبهم. وجوّه نفس المركز، الأدمن يخفي حقل «Ferriman-Gallwey» بـ is_active=false، ويخلّي «الزواج السابق» إلزامي بـ is_required.

---

4. ملاءمة المحرك — الأنواع والشروط والحسابات

الأنواع (عدّ فعلي من الـ schema): chips 286 · seg 242 · text 145 · num 107 · bool 81 · date 56 · sel 53 · calc 42 · repeat 16 · area 8 · table 5 · media 5 · score 3 · popq 2 · figo 1.

الفجوة الوحيدة في الأعمدة: meta json null (w/cols/items/render/card) — مش في قائمة data-layers §3.1، يتضاف في E1.

الـ show_if: الاستخدام الفعلي: k 337 · has 206 · any 111 · eq 93 · in 39 · cat 20 · mod 18 (35 مرجع فريد عبر الموديولات) · truthy 14 · all 4 · gt 3. القرار: grammar النسا هي grammar المنصة (أشمل من {field,op,value} في data-layers): المرجع k (نفس الموديول) أو mod:'m.k' أو patient.* أو encounter.*؛ العمليات eq\|in\|has\|nothas\|gt\|truthy؛ التركيب any\|all؛ وcat. مفسّر واحد ShowIfEvaluator في PHP (التحقق + الـ summary) وTS (العرض) بنفس حالات الاختبار. الـ mod: بيتحل من إجابات نفس الزيارة + الحلقة + المريض حسب scope التعريف المرجعي.

scope record (الامتداد الوحيد على القيم): scope_key عمود عادي بيساوي COALESCE(encounter_id,0) من saving() (migration 2026_07_03_100001:17-24,43-47)، والـ unique (patient_id, history_question_id, scope_key). الإضافة: record_type varchar(24) NOT NULL default '' + record_id nullable؛ الـ hook يبقى scope_key = record_id ?? encounter_id ?? 0؛ الـ unique (patient_id, history_question_id, record_type, scope_key, repeat_index). كده قيم العملية/الدورة/الحمل بتتخزن بنفس الجدول بلا عمود nullable في المفتاح.

الحسابات (30 مفتاح في الـ schema): - مرايا مش حسابات (7): from:imaging.pap/hpv/amh/fsh/afc_total, from:profile.rh, from:uroexam.pvr → computed_key=mirror + meta.ref. - قالب ملخص مش حساب (1): udsReport → ClinicalSummaryService نوع uds. نص ثابت (1): muiNote → meta.hint. - 27 حساب حقيقي في ComputedRegistry (PHP — موجود له bmi/news2) + مرآة TS: age, bmi, bmiProfile, gpal, utvol, afc, rasrm, rotterdam, rmi, semenTotal, semenWho, fertRate, edd, ga, gaAt, gdm, vte, bishop, pph, iciq, diary, diaryFrom, npi, popq, promChange, fsfi, fsds, oabClass, ufSum. البعض محتاج بيانات برّه الموديول: age/bmi (المريض)، gpal (obstetric rows + pregnancies)، edd/ga/gaAt (pregnancies)، popq (observation set)، promChange (series)، vte (BMI/السن/parity مشتقين). الـ BE هو الحاكم عند الحفظ (بيكتب القيمة source=derived للبحث والملخص)، والـ FE للعرض الحي.

المفردات: V (tube/hsgUt/tvsUt/endo/ovary/cx/pelvis/lap…) وPROC_LIB (60 إجراء) وCATS → clinic_history_options بـ lookup_key + إضافة inline بتترسّخ + favorites لكل دكتور* (جينا — clinic_favorites موجود). PROC_LIB بالذات → صفوف في hospital_operations (specialty=gyn) لأنه الكتالوج الواحد (§7.6).

الشبكة القصوى للتحاليل (GYN §7.5 + جينا): تعديل في الكومبوننت المشترك app-clinic-lab-orders (وضع grid بفئات + «حدد الفئة» + حارة favorites) — WP مشترك أول مستهلكه النسا، مش كود نسا.

---

5. الأمان «قبل التشغيل» — مراحل SEC

القائمة المرجعية = فجوات المنصة المسجّلة في clinic-dynamic-fields.md:168 + GYN §9. التقسيم:

قرار مطلوب: تشفير الاسم بيكسر البحث بالاسم (أهم بحث في الاستقبال). التوصية: الاسم يفضل plain، والتشفير على القومي/التليفون/العنوان بـ blind index.

الترتيب للتشغيل الآمن: SEC1 بدري (مستقلة عن الشغل الإكلينيكي، ممكن تتعمل جنب P0/D0) ← SEC2 بعد C1/G1 (عشان تغطي الـ endpoints الجديدة) ← SEC3 آخر حاجة قبل الـ go-live.

---

6. المراحل الموحّدة v3 (منصة + نسا + أمان)

P بلوكات · D بيانات · S شاشة · E محرك · C كيانات كور · G نسا · SEC أمان. ★ = لازمة لتشغيل عميل النسا (MVP: عيادة بوضع procedures.mode=external).

الإجمالي: الـ MVP (13 مرحلة ★) ≈ 3–3.5 شهور متصلة؛ الكل ≈ 6–7 شهور. SEC1 ممكن تتعمل بالتوازي مع P0/D0 لأنها ما بتلمسش ملفات العيادة.

---

7. القرارات للمالك — القائمة المدمجة

✅ = اتقرر · ⏳ = مستني

القرارات التفصيلية التانية موجودة في كل تصميم (13 للبلوكات، 13 للبيانات).

طبقات البيانات الإكلينيكية — الأربع طبقات + المحرك + الـ Intake (تصميم بيانات)

تحليل فقط — 2026-10-21. امتداد لـ design.md (Clinical Core) مش بديل له. المرجع: r3/r4 + فحص مباشر للكود (BE = /home/moonui3/moon-erp-be/Modules, FE = /home/moonui3/public_html/moon-erp/src/app/features). تصحيح مهم لـ design.md §4.7/§8: «vitals الديناميكية (م6) بعد P6» — م6 اتنفذ فعلاً: history_questions فيها scope/category/is_required (2026_07_03_100000) + unit/normal_*/danger_*/danger_values/is_computed/computed_key (2026_07_07_010001)، وpatient_history_answers فيها encounter_id nullable + scope_key + value_num (2026_07_03_100001, 2026_07_07_010002)، وVitalsService::mirrorToUnified بيكتب الـ vitals فيها، وencounters.history_snapshot بيتختم عند التوقيع. اللي ناقص هو الباقي اللي تحت.

---

1. الخلاصة

• كل حقل إكلينيكي بيتوصف بـ بُعدين: scope (patient | encounter) × pack (core | تخصص). التقاطع هو الطبقات الأربع — مش عمود layer، ده مشتق.
• محرك واحد = history_questions (موجود ومتوسّع) + مخزن واحد للحقائق = patient_history_answers (موجود) + مخزن واحد للقياسات = clinical_observations (جديد، time-series). الفرق: الحقيقة ليها قيمة واحدة لكل scope؛ القياس بيتكرر داخل نفس الـ scope (جولات تمريض، وزن تليفون، InBody).
• الحقائق المهيكلة ليها جداولها: الحساسية → patient_alerts، الأمراض → past_medical_history (بتتسمى patient conditions)، العمليات/العائلي → جداولهم، الأدوية الخارجية → prescriptions.kind=home. الأسئلة الـ boolean المكررة (diabetes، dent_anticoagulant…) بتتحول لـ chips على الجدول المهيكل مش إجابات.
• العزل بعمود clinical_type على التعريف بدل hack الـ prefix (isNutritionQuestion) — وده اللي بيقفل تسريب nut_ في شاشة التسجيل.
• أول زيارة = Intake مرحلي: خطوة مشتركة مرة واحدة + خطوة لكل تخصص عند أول encounter في النوع ده، بحالة متتبعة في patient_intakes وشارة في الطابور.
• التخصص بيعلن ولا يكرر: باقة L2/L4 + vitals إضافية + خطوة intake + endpoints الـ workspace — كلها في ClinicalTypeRegistry بالكود (قرار المالك 2026-10-03).

القرار المفتاحي الوحيد: الحقائق (facts) والقياسات (observations) مخزنين مختلفين على نفس التعريفات. محاولة «كل حاجة في patient_history_answers» (clinic-dynamic-fields §3.3) هي سبب وجود 3 جداول vitals موازية — المفتاح الفريد (patient_id, question_id, scope_key) بيسمح بقيمة واحدة للزيارة، والإقامة زيارة واحدة طولها أسبوع.

---

2. الطبقات الأربع

---

3. الـ Engine

3.1 التعريفات — history_questions (الاسم يفضل؛ model alias ClinicalFieldDefinition)

category تفضل الـ router للوحة: profile (تسجيل) · history (حقائق طبية) · vitals (قياسات) · exam (جديد — فحص الزيارة/الـ workspace) · custom.

3.2 مخزن الحقائق — القرار: patient_history_answers يفضل، مفيش clinical_field_values كجدول

كل القرّاء الحاليين (VitalsService, PatientReadService chronic/allergies, SnapshotEncounterHistory, backfill 010003, الكنترولرين) بيقروا منه — جدول تاني = مكرر رقم 14. تمديد: - + repeat_index smallint default 0 يدخل في الـ unique: (patient_id, history_question_id, scope_key, repeat_index). - + value_json json null (multi_select/repeat rows بدل text). - + source string(12) default manual (manual | prefill | portal | import | derived). - LogsActivity (Spatie — موجود في الـ stack) على الموديل: answer_value/value_num/value_json فقط. - model alias ClinicalFieldValue extends PatientHistoryAnswer عشان كود GYN يتكتب بالاسم المقرر بلا جدول جديد. - صفوف category=vitals اللي اتعملت لها mirror تتهاجر لـ clinical_observations ثم تتمسح (المحرك يوقف الـ mirror).

3.3 مخزن القياسات — clinical_observations = مخزن الـ vitals الواحد

clinical_observations: id, company_id, patient_id, encounter_id? , history_question_id,
  value_num, value_text?, observed_at, set_id (ulid — جلسة قياس واحدة),
  source (manual|device|import|portal|carried), recorded_by, softDeletes
idx (patient_id, history_question_id, observed_at) · (encounter_id) · (set_id)

• التعريفات: core 9 (موجودة category=vitals) + إضافات التخصص بـ clinical_type: تغذية waist, hip, fat_pct, muscle_kg, visceral_fat, bmr…؛ نسا fundal_height, fetal_hr؛ إقامة rr, on_oxygen, consciousness, pain, intake_ml, output_ml, news2 (is_computed, computed_key=news2).
• الـ set = صف لكل قيمة + set_id يجمع الجلسة (جولة تمريض/InBody/قياسات الزيارة). الـ NEWS2 يتحسب على الـ set.
• القراءة: ObservationService::latestFor(encounter|patient, codes) + series(patient, code) (trend). is_danger من التعريف في الـ Resource (قرار م6 §4 كما هو).
• ده انحراف معلن عن clinic-dynamic-fields §3.3 («توحيد التخزين في جدول القيم») — الأسماء المجمّدة في §3.1/3.2 ما اتمستش؛ الاستراتيجية بس اتغيرت لأن المفتاح الفريد ما يحملش time-series.

مصير الجداول الخمسة:

3.4 كتالوج الخيارات المُدار + المفضّلة + الإضافة اللحظية (مستفاد من نظام عمرو، مع تفادي عيوبه)

نظام عمرو القديم (amrtechogate/obgy) بيعرض الخيارات بـ «pick-don't-type» قوي؛ ناخد المميزات ونتفادى العيبين (جدول lookup لكل حقل + تخزين CSV). المعتمد:

• كتالوج واحد مُدار بـ lookup_key (clinic_history_options/clinical_lookups): id, lookup_key, value_ar/en, parent_id (للفئات والشجرة)، display_order, specialty?, is_active. حقل التعريف بيشاور عليه بـ lookup_key بدل ما يملك جدوله. ممنوع جدول lookup مستقل لكل حقل (هُم عندهم عشرات: examinationhead/chest/abdomen/pelvis, diagnosis, husbndiagnosis1/2/3, operation…).
• إضافة لحظية (inline-add): أي picker فيه صف «＋ إضافة جديد» يعمل INSERT في الكتالوج (بصلاحية clinic.lookups.add) ويختار القيمة فورًا — زي زر Add + updateElementSelect عندهم.
• مفضّلة لكل دكتور: clinical_lookup_favorites(user_id, lookup_key, value_id) — القيم المميّزة بـ ★ تطفو فوق في الـ picker (عندهم flag favorite بس على مستوى install؛ إحنا per-user). يغطّي سرعة المتكرر في التاريخ/التشخيص/الفحوصات.
• شبكة فئات (full-grid): الفحوصات/الباقات = parent_id (فئة) + أبناء، بـ display_order — picker بفئات مطوية (يطابق investcats→invests).
• تبديل نوع الإدخال للحقل: العميل يقرر الحقل select من الكتالوج ولا نص حر (FieldRule.input, مرآة Examination Controller عندهم) — من غير ما يتغير التخزين.
• الاختيار المتعدد = صفوف ربط مُطبّعة (مثلاً encounter_diagnoses, أو value_json array مع storage) — ممنوع CSV في عمود واحد (diagnosisid="3,7,12") اللي بيكسر الـjoins والتقارير عندهم.

مرجع كامل: legacy-obgy-options-analysis.md.

---

4. جدول تسكين كل حقل

(الطبقة: 1–4 · الإجراء: keep / move / merge / delete)

الإصلاحات الستة: (1) nut_visit_reason → goal ✔؛ أما نمط الحياة فقرار مش إصلاح: بيفضل patient-level عن قصد كـ baseline في الـ intake التخصصي (التغيير لكل زيارة مكانه visit_adherence L4) — قرار #13 في §9. (2) الطول: carry_forward=prefill ✔. (3) Body comps بلا encounter: encounter_id + observations ✔ (moonui). (4) الحقول الإضافية عند الإنشاء: POST clinic/patients يقبل profile_answers[] → savePatientAnswers في نفس الـ transaction. (5) تسريب nut_: PatientProfileFieldController يفلتر clinical_type IS NULL افتراضياً، و?clinical_type= يضيف باقة تخصص واحدة (شاشة الـ intake التخصصي). (6) المحطات المنفصلة: clinic.visit_stations=split يتفرض في الـ BE بـ fill_role — الطبيب يشوف محطة القياسات read-only ما لم يمتلك clinic.vitals.record.

---

5. أول زيارة — Intake

التتبع: جدول صغير patient_intakes (patient_id, clinical_type? (NULL=مشترك), status pending|partial|complete|skipped, completed_at/by, confirmed_at, skip_reason). الاكتمال مشتق من التعريفات: كل in_intake=true AND is_required في الطبقة ليها قيمة. الجدول بيخزن الحالة + التأكيد + التخطي بس.

الفلو: 1. الخطوة المشتركة (L1) — بتفتح تلقائياً من: فورم التسجيل (الاستقبال، fill_role=reception فقط: ديموغرافيا + فصيلة + حالة اجتماعية + وظيفة + how_heard) ثم من محطة الشيت (fill_role=nurse|assistant: alerts/حساسية، مزمن chips، عمليات، عائلي، أدوية من برّه، تدخين). الحد الأدنى الإلزامي: الحساسية (أو «لا يوجد» صريح — alert kind=nka) + المزمن (أو «لا يوجد») + الأدوية الحالية. أي حاجة تانية اختيارية. 2. الخطوة التخصصية (L2) — بتتفعّل عند أول encounter في department.clinical_type=X للمريض ده ولو patient_intakes(X) مش complete: تعرض حقول clinical_type=X, scope=patient, in_intake=true (+ أي مشترك ناقص). التغذية: نمط الحياة + تفضيلات + هدف. النسا: دورة/G-P-A/زوج. الأسنان: alerts الأسنان (chips بعلم) + baseline الشارت. 3. الحفظ الجزئي — كل حقل autosave (نمط history-panel الموجود)؛ الحالة partial لحد ما الإلزامي يكمل. 4. شارة الطابور — chip تالت جنب has_vitals/has_sheet: intake: ok | missing_shared | missing_specialty (من ClinicDashboardService). الطبيب يشوفها قبل ما يفتح. 5. إعادة الـ intake — المشترك: لو confirmed_at أقدم من clinic.intake.reconfirm_days (default 365) → بانر «أكّد البيانات» بنقرة واحدة (بيحدّث confirmed_at) أو عدّل. التخصصي: مرة واحدة ما لم التخصص يعلن reintake_days. 6. مين قبل الزيارة — الاستقبال بيعمل التسجيل + L1 الإداري وقت الحجز؛ التمريض/المساعد بيعمل L1 الطبي في محطة الشيت؛ الطبيب بيراجع ويعدّل مش بيملى من الصفر. لو العيادة visit_stations=merged الطبيب بيشوف الخطوة كلها كـ station أولى بتظهر مرة واحدة. 7. بوابة المريض (لاحقاً) — نفس التعريفات بـ fill_role=patient تتعرض في الـ portal (lab_patients.portal_* موجود) وتتكتب بـ source=portal بحالة «في انتظار مراجعة» → تظهر للتمريض كمسودة. 8. Triage (اختياري) — محطة قبل القياسات لو encounters.kind=emergency (إضافة لقائمة design.md §3-2) أو إعداد clinic.stations.triage=true: تعريفات core triage_level (select بـ danger_values=[red,orange])، triage_note، + الـ vitals الأساسية كـ observation set source=triage. الطابور يترتب بالـ level.

---

6. عقد التخصص — الجانب البياني

Modules/Clinic/app/Clinical/ClinicalTypeRegistry (PHP، بالكود) + نفس الـ entry في clinical-types.ts. التخصص بيعلن:

القواعد: (1) ممنوع تعريف حقل موجود في core بكود تاني — الـ seeder يرفض code مكرر بدون prefix. (2) أي حقل تخصص = prefix {key}_ و clinical_type=key (العمود هو الفلتر، الـ prefix للتوثيق). (3) حقيقة بتهم كل العيادات (حساسية/مرض/حمل) ممنوع تتعرّف في باقة؛ التخصص بيعلّم chips من الكتالوج المشترك بس. (4) العزل في BE بـ clinical_type على encounter ↔ تعريف، مش في FE. (5) ممنوع جدول vitals/alerts/notes خاص — الجدول الخاص مسموح بس لما بيتعرض كـ card أو بيتبحث فيه (odontogram, InBody, pregnancies).

---

7. الهجرة بدون كسر

كل خطوة additive وقابلة للرجوع؛ البيانات الحية على moonui3 صغيرة. على MySQL (SQLite يبلع أعمدة ناقصة — درس مسجّل).

1. أعمدة التعريفات (§3.1) nullable + backfill clinical_type من الـ prefix (nut_→nutrition, dent_→dental, obgy spouse→gyn_ob) + storage للأسئلة المهيكلة. شرط: ClinicalType النهارده general/nutrition/dental بس، وعيادة النسا في co4 شغالة كقسم general → نضيف case gyn_ob في D0 (enum + registry entry بتاب consultation العادي، بلا workspace) ويتعلّم قسم النسا بيه قبل الـ backfill؛ وإلا حقول الزوج تختفي من شاشة الملف بعد D0. بديل مرفوض: إبقاء باقة obgy clinical_type=NULL (تظهر لكل العيادات). الكنترولرين يفلتروا بالعمود؛ isNutritionQuestion/isDentalQuestion يفضلوا كـ fallback ريليس واحد.
2. القيم: repeat_index + unique الجديد + value_json + source + LogsActivity.
3. clinical_observations: create → backfill من clinical_examinations (set لكل صف) + patient_vital_entries (encounter NULL) + صفوف answers category=vitals → VitalsService يكتب الاتنين خلف clinic.vitals.dual_write → القرّاء الـ 13 يتحولوا → حذف mirror + drop الجدولين الريليس اللي بعده.
4. patient_alerts (design.md 4.5 — يتقدّم): create → backfill من medical_history.allergies + سؤال allergies (split بالفاصلة) + dent_allergy_*=true + important_note (kind=note) → PatientReadService::allergiesList يقرا alerts فقط → الأسئلة الثلاثة is_active=false. SnapshotEncounterHistory يتوسّع يختم alerts النشطة في history_snapshot (النهارده بيختم إجابات patient-scope بس).
5. Conditions: past_medical_history + status/is_chronic + كتالوج is_alert/alert_types → backfill diabetes/hypertension/dent_*=true → صفوف بكود؛ الأسئلة تتحول storage=condition (تفضل ظاهرة كـ chips). نفس الشيء prior_surgery/family_history_flag (يتحسبوا). الـ snapshot يختم conditions/surgical/family كمان.
6. Home meds: يعتمد على P1 (Rx v2 drug_name snapshot) → prescriptions.kind=home + backfill nut_supplements/nut_external_medications/medical_history.meds. الـ snapshot يختم بنود home النشطة.
7. الحمل/التدخين/الاجتماعية: تعريفات core الجديدة + backfill من nut_/dent_ ثم حذف النسخ.
8. encounter_diagnoses.stage + backfill primary؛ المستشفى يكتب pre/post هنا.
9. clinical_notes + backfill treatment_plan/general_health_note (sticky) ثم نقل hospital_nursing_notes (kind=nursing).
10. patient_intakes + backfill: مريض عنده إجابات L1 إلزامية كاملة = complete بتاريخ آخر إجابة.
11. medical_history json: بعد 4+5+6 يتشال من الفورم ويفضل read-only.

مخاطر: الـ dual-write للـ vitals (شاشتين يكتبوا في وقت واحد) → الـ flag يتقفل بعد ما المالك يتست؛ unique الجديد على answers مع repeat_index (backfill 0 الأول)؛ QueueController has_vitals لازم يتحول في نفس الريليس وإلا الطابور يفقد الشارة.

تنسيق moonui (Nutrition): (أ) nutrition_body_compositions.encounter_id + كتابة observations عبر ObservationService::recordSet()؛ (ب) PatientNutritionMetrics::weightSeries يقرا observations بس؛ (ج) goal 5 قيم + استقبال nut_visit_reason؛ (د) food_prefs kind=allergy → patient_alerts بـ ref=nutrition_food؛ (هـ) تبنّي picks/diagnosis (design.md). Clinic-side بلا تنسيق: نقل nutritionQuestions() لباقة بـ clinical_type، العزل، حذف nut_smoker/marital/pregnant/visit_reason بعد الهجرة (الكود في Clinic).

---

8. المراحل — دمج مع P0–P6

---

9. قرارات مطلوبة من المالك

1. مخزنين (حقائق + قياسات) ولا مخزن واحد؟ التوصية: اتنين — المفتاح الفريد ما يحملش جولات/سلاسل، والدليل 3 جداول موازية اتعملت بسببه.
2. المزمن: جدول مهيكل + chips (التوصية) ولا أسئلة boolean؟ المهيكل يدّي since_when/status وعلامة alert لكل العيادات؛ الـ chips بتحافظ على «يختار مش يكتب».
3. الحساسية الغذائية تتوحّد في patient_alerts (التوصية، تنسيق moonui) ولا تفضل في التغذية بس؟
4. الحمل حقل زيارة بـ prefill 30 يوم (التوصية) لحد ما pregnancies تتبنى — موافقة على حذف نسختي التغذية والأسنان.
5. الأدوية الخارجية = prescriptions.kind=home (التوصية، يعتمد على P1) ولا جدول patient_medications منفصل؟
6. patient_alerts + clinical_notes يتقدّموا لـ D2 (قبل P2/P3) — موافقة على إعادة الترتيب.
7. marital_status/job/how_heard/referred_from تبقى core profile مطفية افتراضياً (التوصية) ولا تفضل في الباقات؟
8. الحد الأدنى الإلزامي للـ intake المشترك = حساسية + مزمن + أدوية (بخيار «لا يوجد» صريح) — تأكيد أو تقليل.
9. encounters.kind=emergency + محطة triage (التوصية: نضيفها في D4 كإعداد مطفي) — موافقة على الإضافة لقائمة design.md.
10. hospital_vital_rounds تتهاجر (D4) ولا تفضل للأبد كجدول تمريض خاص؟ التوصية: تتهاجر — لوحة التمريض عندنا على moonui3.
11. طول الأطفال (<18): إعادة قياس كل زيارة (التوصية) ولا نفس الـ 365؟
12. مين يبدأ تنسيق moonui (البنود أ–هـ في §7) وإمتى — قبل D1 ولا بعده؟ التوصية: الاتفاق قبل D1، التنفيذ عندهم بعد D1.
13. نمط حياة التغذية (9 حقول) يفضل patient-level كـ baseline في الـ intake التخصصي (التوصية) ولا يتحول لحقول زيارة؟ الدليل: الـ r4 اعتبرها «خطأ patient-level»، لكن التغيير بالزيارة عنده مكان فعلاً (visit_adherence)، والحقائق دي بتتسأل مرة وبتتراجع — مش بتتقاس.

Clinical Core — توحيد البلوكات الطبية المشتركة (روشتة / تحاليل / أشعة / …)

تحليل فقط — 2026-10-21. المرجع: التقارير r1/r2/r3 + فحص مباشر للكود (file:line تحت كل ادّعاء). BE = /home/moonui3/moon-erp-be/Modules، FE = /home/moonui3/public_html/moon-erp/src/app/features.

---

1. الخلاصة

الـ Clinical Core = مجموعة بلوكات طبية واحدة بتشتغل في كل عيادة (عام / تغذية / أسنان / نسا / إقامة مستشفى) من غير ما أي تخصص يبني نسخته. كل تخصص بيستضيف البلوك ويضيف عليه حقول/قوالب/مفضّلات — لكن ما يعملش جداول أوامر خاصة بيه.

البلوكات اللي بنوحّدها دلوقتي (المرحلة الأولى): (1) الروشتة والأدوية (بما فيها أدوية الإقامة MAR وروشتة الخروج)، (2) طلبات التحاليل، (3) طلبات الأشعة (بتقريرها وصورها)، (4) النتائج والمستندات الإكلينيكية (نتيجة/تقرير/إجازة مرضية/تقرير طبي/شهادة)، (5) المرفقات والتنبيهات، (6) محرك الطباعة. الباقي (التشخيص، العلامات الحيوية الديناميكية، الملاحظات، المتابعة) موجود أو مخطط في الـ KB وبينضم بترتيب لاحق.

أكبر قرار: موديول Clinic هو الـ Clinical Core — مفيش موديول جديد، والـ Encounter هو سياق كل أمر طبي (زيارة عيادة / إقامة / يوم عملية / متابعة تليفون) بدل ما نعمل ربط polymorphic على كل جدول. الإقامة أصلاً بتفتح encounter (hospital_admissions.encounter_id)، وكل جداول الأوامر مفتاحها encounter_id، والـ LIS عنده RequestSource::InPatient. يبقى اللي ناقص نوع للـ encounter مش أنكر جديد.

الوضع الحالي باختصار: 3 نماذج أدوية ما بيكلموش بعض (روشتة العيادة، MAR المستشفى بنص حر، صورة روشتة المتجر)، الروشتة السريعة بتخزّن «—» في الحقول المهيكلة، إعداد مصدر الأدوية ما بيتقراش، الأشعة بتقف عند ordered للأبد، والاستقبال بيعمل طلبات تحاليل/أشعة بيتخطى وضع standalone.

---

2. الوضع الحالي

---

3. المبادئ الملزمة للتوحيد

1. كيان واحد لكل مفهوم. روشتة = prescriptions/prescription_items بس. طلب تحاليل/أشعة من الطبيب = clinic_clinical_intents بس. تقرير أشعة = rad_reports بس. أي تخصص (أسنان/تغذية/نسا/مستشفى) ممنوع يعمل جدول أوامر أو أدوية خاص بيه.
2. السياق = Encounter، والـ Encounter ليه نوع. encounters.kind (outpatient | inpatient | day_case | remote) + encounters.admission_id nullable. الإقامة = encounter واحد طول مدتها (موجود فعلاً). الحلقة (episode) والإجراء (clinical_procedure) بيربطوا encounters، مش بيستبدلوها. الأرضية الدنيا = patient_id (موجود على كل الجداول) للحالات اللي مفيهاش encounter (LIS walk-in).
3. المفردات من مكان واحد. طرق الإعطاء = Clinic\Enums\MedicationRoute (اتحاد القائمتين = 13 قيمة). التكرار = Clinic\Enums\MedicationFrequency (كود → أوقات/يوم، منقول من NursingService::FREQ). الشكل الصيدلي = Core dosage_forms. ممنوع قوائم ثابتة في أي كومبوننت أو سيرفس تاني.
4. الـ BE هو اللي بيفرض القفل والتوقيع. كل كتابة إكلينيكية على encounter موقّع = EncounterLockedException من الـ action نفسه. الـ FE [locked] تجميل بس.
5. الوضع = إعداد، مش كود. clinic.ordering_mode / lab_mode / rad_mode / pharmacy_source / pos.pharmacy.* / clinic.print.* موجودين — بنقراهم في نقطة واحدة لكل واحد (OrderingMode, ClinicCatalogMode, وPharmacySource الجديد).
6. منفّذ واحد للطلب. كل اللي بيحوّل «بند كتالوج» لـ (سطر فوترة + LabRequest/RadOrder/self) بيعدّي على action واحد ExecuteCatalogItem (يتستخرج من فرع DecideClinicalIntent::here). النية (clinic_clinical_intents) = سجل الطبيب وبتتطلب encounter؛ طلب الاستقبال المباشر (CreateVisit) بينادي نفس المنفّذ مربوط بـ service_order_id + patient_id بلا encounter وهمي (عشان ما يطلقش EncounterStarted → in_consultation). وضع immediate = النية بتتقرر «هنا» فوراً بنفس المنفّذ.
7. الصرف مش على شاشة الطبيب أبداً. الروشتة بتصدر event وتحمل dispense_status؛ الصرف/البيع في POS/Sales. الطبيب بيشوف «اتصرفت» كشارة بس.
8. النتيجة بترجع للمريض، والزيارة اختيارية. clinical_documents بتتربط بالـ patient دايماً وبالـ encounter لو موجود. العرض موحّد بشارة المصدر (LIS / RIS / خارجي).
9. محرك طباعة واحد في الـ BE (DomPDF — نفس اللي LIS مثبته بالعربي) بقوالب لكل نوع مستند، وإعدادات clinic.print.* الموجودة. الـ FE preview يفضل لحد ما الـ PDF يثبت، بعدها يتشال.
10. ALTER قبل CREATE. جدول جديد بس لو الـ KB (GYN §7.2) اقترحه قبل كده أو مفيش مكان منطقي له.

---

4. التصميم لكل Block

4.1 الروشتة والأدوية (Prescription / Medication)

المالك: Modules/Clinic (موجود). الكتالوج: Core products (+product_drug_details) أو clinic_drugs حسب الإعداد.

المستشفى (MAR) ← نفس الموديل: hospital_med_orders بتتقسم جزئين: الإكلينيكي (drug/dose/route/frequency/times/prn/starts/ends/status/ordered_by/stopped) → prescription_items تحت prescriptions.kind=inpatient على encounter الإقامة. المالي/المخزني (product_id, warehouse_id, unit_price, charge_per_dose) → يفضل في Hospital كجدول جديد hospital_med_charging (صف لكل بند: prescription_item_id unique, product_id, warehouse_id, unit_price, charge_per_dose) — مش على hospital_med_admins لأن الأعمدة دي لكل أمر مش لكل جرعة. hospital_med_admins: + prescription_item_id nullable (backfill من order_id)، وNursingService بيحسب الـ slots من prescription_items.times. إصلاح مرافق: صرف المخزون (ConsumptionService::issue) يتفك من شرط التحصيل (NursingService.php:129-135) ويشتغل لو product_id+warehouse_id موجودين. روشتة الخروج = prescriptions.kind=discharge على نفس encounter الإقامة، بتتطبع مع ملخص الخروج، وبتظهر في «الأدوية الحالية» للمريض.

الصرف (hand-off): الطبيب يصدر → PrescriptionIssued → POS صيدلية (Phase 6) عنده worklist GET pos/pharmacy/prescriptions?status=pending يقرا من prescriptions مباشرة؛ البيع يستدعي MarkPrescriptionDispensed (يحدّث dispensed_qty/dispense_status). التغذية DispensedItemsService يفضل قارئ عرض.

4.2 طلبات التحاليل (Lab orders)

المالك: Clinic للطلب/النية/الفوترة، LIS للتنفيذ والنتائج.

4.3 طلبات الأشعة (Radiology)

المالك: Clinic (RIS-lite موجود).

4.4 النتائج والمستندات الإكلينيكية (ينضم الآن)

clinical_documents هو كيان المستند الموحّد: doc_type ينضم له sick_leave · medical_report · certificate · discharge_summary · rx_print (snapshot الطباعة). ALTER: encounter_id nullable (4.2) · + document_number (SequenceService) · + template_id → clinical_templates · + signed_at/signed_by · + from_date/to_date (للإجازة). API: POST encounters/{e}/documents {doc_type, template_id, data} + GET documents/{d}/pdf. FE: app-clinical-document-dialog [encounterId] [docType] يظهر في لوحة الخروج (consultation.html:685-734) وفي ملف الإقامة. Permissions: clinic.documents.create/print. المستشفى: admissions.discharge_summary يفضل نص للتوافق لكن الطباعة من المستند.

4.5 المرفقات والتنبيهات (ينضم الآن)

• المرفقات: ALTER clinic_patient_attachments: + attachable_type/attachable_id nullable (morph: rad_study | clinical_intent | prescription | dental_tooth | clinical_procedure…) · + kind string(16) (image | pdf | photo | video | link) · + is_private bool. المستشفى يستخدمه من ملف الإقامة. مفيش جدول ميديا جديد (GYN §7.2 «media (موجود: attachments)» ✔).
• التنبيهات: جديد patient_alerts (كما في GYN §7.2: patient_id, code, label, severity, source (history_answer \| manual \| drug_alert), source_ref, active, set_by). يتغذى تلقائياً من PatientReadService allergies (listener على حفظ history) + يدوي. الهيدر المشترك clinic-patient-header يقرا منه في كل الشاشات بما فيها ملف الإقامة. Permission: clinic.alerts.manage.

4.6 محرك الطباعة (ينضم الآن)

Clinic/app/Services/ClinicalPdfService فوق DomPDF (نفس LabReportPdfService): قوالب Blade لكل نوع (prescription, rad_report, document, visit_summary, referral). الهيدر/الفوتر/اللوجو/الورق من clinic.print.* (موجودة) + توقيع لكل طبيب (lab_doctors.signature_attachment_id جديد). endpoint نمطي GET clinic/print/{kind}/{id}.pdf. الـ FE clinic-print-shell.service.ts يفضل للـ preview السريع حتى يتأكد المالك من الـ PDF، بعدها نحوّل الـ 5 طباعات + الأسنان + التغذية (بتنسيق مع moonui) عليه.

4.7 البلوكات اللاحقة (مخططة في الـ KB — ترتيبها بعد المراحل دي)

---

5. الـ Extension contract للتخصصات

التخصص = ClinicalType (enum بالكود) + entry في registry الـ FE + باقة حقول. اللي يقدر يعمله:

المستشفى = سياق مش تخصص. الإقامة ما تبقاش clinical_type؛ القسم المعالج يفضل بتخصصه (جراحة/نسا/باطنة)، وencounters.kind=inpatient هو اللي بيفتح بلوكات الإقامة (MAR، التمريض، الخروج) جنب نفس الروشتة/التحاليل/الأشعة. ملف الإقامة (admissions/:id) يستضيف app-clinic-prescription [kind=inpatient], app-clinic-lab-orders, app-clinic-rad-orders, المستندات، المرفقات. AdmissionService.php:125-131 يفتح الـ encounter بـ kind=inpatient + admission_id.

التغذية (moonui): بتستضيف الكومبوننتات فعلاً. التغيير المطلوب منهم: (1) PatientMedicationsService يقرا sentence ?? dose/frequency/duration (وإلا تظهر فراغات بعد الهجرة)، (2) تبنّي لوحة التشخيص المشتركة، (3) تحويل print-context على محرك الطباعة. يتم بالاتفاق مش بتعديل كودهم من هنا.

---

6. عيادة / مركز / مستشفى — نفس الكور بإعدادات

مفيش سطر كود يتغير بين الأعمدة الثلاثة.

---

7. الهجرة بدون كسر

كل الخطوات additive وقابلة للرجوع؛ البيانات الحية على moonui3 صغيرة.

1. بنود «—»: migration تمشي على prescription_items حيث dose='—' OR frequency='—' OR duration='—' → sentence = instructions، الحقول الثلاثة = NULL، form = القيمة اللي كانت في dose لو مش «—». instructions تفضل زي ما هي. الطباعة القديمة اللي كانت بتمسح «—» (clinic-prescription.service.ts:295-305) تتشال.
2. الشكل الصيدلي: seed dosage_forms بالقائمة العربية الشائعة (من COMMON_DRUG_FORMS_AR في الكومبوننت) لكل شركة (updateOrCreate على code) → backfill prescription_items.dosage_form_id / clinic_drugs / clinic_drug_presets بمطابقة الاسم؛ اللي ما يتطابقش يفضل نص في form.
3. الطرق/التكرار: MedicationRoute يتوسع (إضافة قيم بس = backward-safe). MedicationFrequency جديد؛ بنود الإقامة القديمة frequency كود صغير يتنقل لـ frequency_code.
4. MAR → prescriptions: migration تعمل لكل إقامة عندها hospital_med_orders روشتة واحدة kind=inpatient على encounter الإقامة، وتنسخ كل order لبند (drug_name=drug, drug_id=product_id, times, prn, starts_at, ends_at, item_status) وتكتب hospital_med_admins.prescription_item_id. hospital_med_orders يفضل للقراءة ريليس واحد (NursingService يكتب في الاتنين خلف flag hospital.mar_on_prescriptions) ثم يتجمّد. الروتس api.hospital.nursing.orders.* تفضل وتنادي الـ Clinic actions.
5. الأشعة الواقفة عند ordered: migration تصلّح الحالة من الواقع: order له study acquired → performed؛ له report released → reported + سطر result_status=ready. مفيش بيانات بتتمسح.
6. الجسر clinic_services.lis_investigation_id/rad_procedure_id: يُحذف من الـ API (الحارسان + الـ import) ويفضل العمود ريليس واحد ثم drop. السبب: القرار المعتمد «بلا mirror» + الوضع المتكامل بيختار من كتالوج LIS مباشرة، فالجسر ما لوش مستهلك.
7. clinical_documents.encounter_id nullable + unique جديد: migration: drop unique القديم → add (company_id, ref_key). تتأكد الأول إن مفيش تكرار (ref_key global فعلاً).
8. CreateVisit: الـ payload القديم (lab.investigations[].investigation_id, radiology[].procedure_id) يتقبل ويتحوّل داخلياً — الـ FE يتحدّث في نفس المرحلة، مفيش كسر للعملاء.
9. الطباعة: PDF endpoints تتضاف جنب الـ FE preview؛ التحويل الكامل بعد اختبار المالك.

---

8. المراحل

بعد P6: clinical_notes, follow_up_tasks, هجرة dental_note_templates/dental_recalls, vitals الديناميكية (م6), access_audit.

---

9. المخاطر والقرارات المطلوبة من المالك

1. مكان الكور: موديول Clinic (التوصية) ولا موديول جديد ClinicalCore؟ Clinic بيملك فعلاً 30+ جدول إكلينيكي وكل التخصصات بتعتمد عليه. موديول جديد = نقل جداول وكسر namespaces بلا فايدة. توصية: Clinic، مع مجلد app/Clinical/ للـ actions المشتركة.
2. السياق: Encounter بنوع (التوصية) ولا polymorphic context على كل جدول؟ الدليل: hospital_admissions.encounter_id + service_order_id موجودين، كل جداول الأوامر encounter_id، LIS عنده in_patient، والسياق الوحيد بلا encounter هو LIS walk-in وده مغطّى بـ patient_id. Polymorphic = فقد FKs + إعادة كتابة كل القرّاء والـ listeners. توصية: Encounter + kind.
3. هجرة MAR على الروشتة (P2) — دلوقتي ولا بعد P3؟ المستشفى اتبنى على moonui3 (نفس الإنستانس) فالتنسيق سهل. توصية: P2 زي الترتيب لأن الإقامة هي أكبر مكرر.
4. محرك الطباعة: BE PDF (التوصية) ولا نكمل FE HTML؟ LIS مثبت DomPDF بالعربي. توصية: BE PDF مع إبقاء الـ preview لحد ما تختبر.
5. سعر تعاقدي لكل تحليل في الوضع المتكامل: LabInsuranceContract في LIS (التوصية) ولا تمديد عقود العيادة؟ توصية: LIS — الكتالوج هناك والسعر هناك.
6. أشعة الأسنان: مش rad order (التوصية) — صور على السنة؛ الخارجي = طلب standalone. محتاج تأكيد.
7. الصرف (P6): دلوقتي ولا بعدين؟ الإعدادات pos.pharmacy.* مزروعة ومكتوب عليها «لسه هتتبني». توصية: بعد P3 — البنية جاهزة من P1 (dispense_status + event).
8. التغذية: الهجرة في P1 هتغيّر اللي PatientMedicationsService بيعرضه. قرار: مين يعدّل قارئ التغذية (moonui) وإمتى؟ ومعاه تبنّي لوحة التشخيص والـ record المشترك.
9. حذف جسر clinic_services.lis_investigation_id/rad_procedure_id (التوصية: يتشال — بلا مستهلك، والقرار «بلا mirror» معتمد) ولا يتفعّل؟
10. المطالبات: تفريد ClaimLine لكل تحليل (التوصية) ولا سطر واحد للطلب؟ NPHIES محتاج كود لكل خدمة.
11. presets الصلاحيات الجديدة (radiologist, rad_technologist) وتصحيح preset الاستقبال بإضافة clinic.lab_results.view — موافقة.
12. الروتس المباشرة POST encounters/{e}/lab-orders|rad-orders: تفضل كـ wrappers (التوصية) ولا تتشال؟ إبقاؤها = صفر كسر للـ FE.
13. مصدر طلبات التحاليل من الإقامة في LIS: يفضل source=clinic (التوصية — قرار مسجّل في his.md:219، والتمييز من encounter.kind) ولا نرجع لـ in_patient عشان شاشات LIS تعرض «مريض داخلي»؟ لو in_patient: تعديل سطر واحد في OrderLabFromEncounter + فلاتر LIS اللي بتعتمد على clinic.

مخاطر عامة: (أ) حجم P3 — يتقسم WPs صغيرة (immediate-via-intent / CreateVisit / rad SM / coverage) كل واحدة بسيناريو على /app. (ب) الاختبارات على SQLite ما بتكشفش أعمدة ناقصة — كل migration تتراجع على MySQL moonui3. (ج) أي تعديل في AddServiceOrderLine/CollectReceptionReceipt يتعمل مرة واحدة في الطبقة المشتركة (قاعدة المالك).

٨ · الحصر الأصلي (حقايق من الكود بـ file:line)

• r1 — الروشتة والأدوية في كل الموديولات
• r2 — التحاليل والأشعة
• r3 — باقي البلوكات المشتركة
• r4 — حصر كل الحقول وتركيب الشاشات + الـ13 تكرار