---
title: مبادئ المالك الحاكمة للكلينك — نماذج البيع والخدمة والعقيدة التصميمية
slug: clinic-principles
status: active
owner: hazem
updated: 2026-07-02
related:
  - his
  - clinic-tightening-plan
  - gyna-reference
---

> كل بند هنا **ملزم** — يُقيَّم به كل تصميم وWP في الكلينك. المصدر: توجيهات المالك الحرفية 2026-07-02.

---

# نماذج بيع الكلينك (المالك، 2026-07-02) — مبدأ معماري ملزم

## ⛔ وضع العمل الحالي: تخطيط فقط (المالك، 2026-07-02)
«مش هننفذ دلوقتي — ناخد كل وقتنا في التخطيط علشان يبقى معانا **خطة متكاملة**. وحتى واحنا بننفذ هنعملها في شكل **phases مرتبطة بالفلو** — اللي يخلص يكون عامل **add value في الـ UI** بحيث أعرف **أتست وأحس ببروجرس**.» → لا كود للكلينك قبل اعتماد الخطة الكاملة؛ كل فيز لازم ينتهي بقيمة UI قابلة للتست بسيناريو يمشيه المالك بنفسه.

**«الطبيب كده كده بيطلب — لكن الشراء والتنفيذ مختلف».** النظام يتباع في **حالتين فقط** (مفيش تالتة):

## التحاليل والأشعة
1. **متكامل:** العميل واخد الكلينك + موديول اللاب (LIS) → التكامل الواسع: طلب الطبيب → الاستقبال ينفّذ → LIS/RIS بتوعنا (الوضع الحالي `lis_integrated`).
2. **مستقل:** العميل واخد الكلينك **بس** (عنده معمل خاص برّه نظامنا) → يعرّف الخدمات بنفسه في كتالوج العيادة بنوع «تحاليل»/«أشعة» → الطبيب يطلب من الكتالوج → الاستقبال ينفّذ/يفوتر بلا LIS → النتيجة ترجع بمسار النتيجة الخارجية (L3).
**وده سبب فصل طلب الدكتور عن التنفيذ** (طبقة النوايا L1) — الاستقبال هو اللي بينفّذ في الحالتين.

## الروشتة والأدوية (نفس القصة)
الطبيب لازم يكون عنده **قاعدة بيانات أدوية** يروشت منها في الحالتين:
1. **مع المشتريات/المخازن:** قاعدة الأدوية مرتبطة بالمشتريات والمخزون بتوعنا، **والصرف عملية منفصلة تمامًا** (في قسم المبيعات مثلًا) — الطبيب يطلب، الصرف/البيع في مكان تاني.
2. **بدون المشتريات/المخازن:** يقدر يعرّف الأدوية بنفسه (قاعدة أدوية مستقلة) — **فصل تام بين النظامين**.

## سرعة الروشتة — الهدف الأساسي من السيستم (المالك، 2026-07-02)
«الدكتور مش عنده وقت وعايز يختار ويكتب بسرعة بدون ما ياخد وقت ولا يقعد يكتب جرعات — **كله اختيارات**، وده الهدف الأساسي من السيستم.» → فورم الروشتة = pick لا typing: دواء من قائمة سريعة (favorites/الأكثر استخدامًا) → الجرعة/التكرار/المدة/التعليمات كلها **قوائم اختيار جاهزة** بديفولت لكل دواء + «كرر الروشتة السابقة» → طباعة. المرجع التفصيلي: روشتة الجينا القديم (obgy@amrtechogate) — فيه الميكانيكا كاملة (lookup tables للجرعات + defaults).

## الحقول الإكلينيكية الديناميكية — Dynamic Forms (المالك، 2026-07-02)
«أقدر أضيف مؤشر حيوي جديد زي الضغط: أقول رقمي ولا تكست، وإمتى يبقى **خطر**، وأضيفه — يتضاف خلاص ويبقى موجود في الشيت. نفس القصة في المعلومات الطبية — dynamic forms علشان نسهّل الإضافة **لأن الحاجات كتير**. وممكن presets تتطبق عند العملاء مباشرة، وليها إعدادات إخفاء وإظهار.»
→ الـ vitals والمعلومات الطبية = **تعريفات data-driven** مش أعمدة ثابتة: (تعريف حقل: اسم ثنائي اللغة + نوع رقمي/نصي/اختيار + وحدة + مدى طبيعي/**حدود خطر** بتنبيه + إظهار/إخفاء + ترتيب) → يظهر في شيت الكشف تلقائيًا. Presets قابلة للتصدير/الزرع للعملاء (زي history_questions seeder). **السابقة الموجودة:** محرك أسئلة التاريخ (history_questions/answer_options WP-14) هو النموذج — المطلوب تعميمه على الـ vitals (حاليًا جدول clinical_examinations بأعمدة ثابتة 1:1) وباقي المعلومات الطبية.

## مقاييس البيع — الكور واحد (المالك، 2026-07-02)
النظام يتباع لـ: **عيادة واحدة** أو **مركز بكذا عيادة** أو **مستشفى** (لما نضيف غرف العمليات وباقي الأقسام) — **لكن الكور واحد**: في الآخر «خدمات مختلفة بتتضاف». أي تصميم لازم يسكيل من عيادة→مركز→مستشفى بنفس النواة؛ الأقسام والخدمات additive مش نسخ متفرعة. (متسق مع قرار «shared clinical core» الأصلي في KB his.md.)

## تصنيف الخدمات — 3 أنواع مختلفة في المعاملة والطباعة (المالك، 2026-07-02)
**(١) الكشف/الإعادة** (أساس الشغل — أو مثيلها في أي قسم مستشفى): خدمة بيقدمها **واحد من 3 احتمالات وكل الحسابات تترتب عليه**: (أ) دكتور بعينه — محدد بساعاته من ساعة إنشاء الخدمة · (ب) قسم بعينه — والدكتور يتحدد **في الحجز نفسه** · (ج) القسم كله بيقدمها — **والدكتور اللي يفتح الحالة هو اللي ياخدها**. (مرجع البنية: خدمات الجينا القديم — يُفحص تكوين الـ service/detection فيه.)
**(٢) التحاليل كخدمة:** إعداد أساسي = «المعمل (LIS) متفعل ولا لأ»: متفعل → اختيار الاستقبال للتحاليل يدخلها فلو الـ LIS · مش متفعل → بيبيعها خدمة عادية، **والنتايج**: لو من سيستمنا تيجي تلقائي، لو مش سيستمنا **الدكتور يدخل قسم النتايج بنفسه: قيمة رقمية أو صورة يرفعها أو ملف PDF** — خطوة **اختيارية** للدكتور يملّي بيها التحاليل اللي طلبها قبل كده. (مسار L3 المبني = نفس الفكرة على النوايا؛ يتعمم على الخدمات standalone.)
**(٣) الأشعة كخدمة:** نفس قصة التحاليل.

## عقيدة «الدكتور يختار مش يكتب» — تمتد لكل الشيت (المالك، 2026-07-02)
«أغلب السيستم قايم على إن الدكتور **مش هيكتب — هيختار**»: (١) **التحاليل** في روشتة الجينا: سريعة جدًا و**عارضة أكبر عدد من التحاليل** مرة واحدة (grid واسع + favorites) — ونفس القصة في الريسيبشن · (٢) **الأشعة**: نفس الشيء — «دول أساسيين» · (٣) **الشكوى والتشخيص**: اختيارات مضافة قبل كده **أو الدكتور يضيفها فتبقى معاه على طول** (inline-add يترسّخ في قايمته للأبد). → عقد تصميم شاشات الطلبات/الشكوى/التشخيص في Moon Clinic: عرض أقصى عدد مرئي (مش typeahead بنتيجة واحدة) + favorites + إضافة inline بتترسّخ + أقل نقرات. الميكانيكا الحرفية من كود الجينا: session scratchpad t14/ (scout مخصص).

## أدوار التنفيذ (المالك، 2026-07-02)
«هنعمل الخطة متكاملة و**أوبس هو اللي هينفذ** وهنخلي **فابل هو الأدفايزور** يرجعله في أي حاجة محتاجة قرار علشان يمشي صح.» → وقت التنفيذ: منفّذو Opus يشتغلوا، وأي نقطة قرار/غموض يرجعوا لـ Fable (الـ orchestrator) — مايقررواش لوحدهم.

## الخدمة = العمود الفقري + الإعدادات بترتّب الدنيا (المالك، 2026-07-02)
«جزء أساسي في الأناليسيس عن **الخدمة وتكوينها واللوجيك بتاعها مع اللوجيك التاني — ربط الدنيا ببعض**. كمان شاشات الإعدادات وما سيتم عمله فيها **علشان الدنيا ترتب بعضها**.» → (١) الخدمة هي الكيان المركزي: إضافة خدمة واحدة المفروض تتسلسل تلقائيًا (تظهر في الحجز بنوعها/قسمها → تتسعّر 3 محاور+عقد → تتطلب حسب الوضع → تتفوتر → تتغطى → تتقسم → تتقرّر) — أي كسر في السلسلة دي = bug ترابط. (٢) الإعدادات definitions-driven بمجموعات (مالية/أوضاع بيع/حقول ديناميكية/تشغيل/طباعة/روشتة) — «عميل جديد = يظبط إعداداته فيشتغل النظام على وضعه بلا كود». القسم مضاف لخطة التظبيط + التحليل الخام في session scratchpad t14/service-settings-analysis.md.

## الأطباء منضمين لأقسام — الفلترة إلزامية (المالك، 2026-07-02)
«الأطباء المفروض إنهم منضمين إلى أقسام — لما أختار القسم يفلتر الأطباء، لأن مثلًا في مراكز فيها **1000 طبيب** في كل التخصصات.» → كل doctor-picker في النظام (الحجز، الجدولة، مصفوفة الأسعار، توزيع الإيراد، التقارير): اختيار القسم أولًا → قائمة الأطباء **مفلترة بالقسم** ومبنية على **بحث server-side** (مش listAll — 1000 طبيب لا يتحمّلوا تحميل كامل). امتداد طبيعي لمبدأ «الكور واحد» (عيادة→مركز→مستشفى).

**Why:** ده نموذج البيع الفعلي للعملاء — أي تصميم يربط الطلب بالتنفيذ ربطًا صلبًا، أو يبطّئ الروشتة بكتابة حرة، أو يفرّع الكور حسب الحجم — بيكسر السوق.
**How to apply:** أي شغل في orders/roshetta/كتالوج: (١) النية/الطلب polymorphic ما يفترضش وجود LIS/مخزون (L1 عامل كده: `catalog_ref_type=lis_investigation|rad_procedure|clinic_service|free_text` ✓) · (٢) وضع standalone = خطة L4 (`clinic.lab_mode/rad_mode=lis_integrated|standalone`) لازم يتنفذ · (٣) قاعدة أدوية العيادة يا مربوطة بـ Core Products (مشتريات) يا مستقلة — والصرف **مش** جوه شاشة الطبيب أبدًا · (٤) خطة التظبيط (T14) والـ L4 يتصمموا على النموذجين · (٥) **⛔ GATE (من م3، 2026-07-03): أي حقل في شاشة كلينك يحمّل خياراته من مصدر LIS لازم يتحوّل لـ lookup مقيّد بصلاحية clinic قبل نشر standalone** — أول حالة مرصودة: `specialty_id` في فورم الطبيب (`clinic-doctors.component.ts`) بيحمّل من `LisDoctorSpecialtyService` (صلاحية LIS) → select فارغ لمستخدم clinic-only → لازم `GET /his/doctor-specialties` بحارس `clinic.doctors.view` + تحويل الـ FE. مُوثّق في `plans/CLINIC-MODULE-FREEZE-RESUME.md` §4-[B]. مرتبط بـ [[feedback_orchestrate_with_agents]] وKB topics/his.md.

## الزيارة الطبية = 3 محطات داخلية قابلة للفصل/الدمج (المالك، 2026-07-02)
1. **محطة القياسات (vitals)** — ممكن شخص مختلف (التمريض) يدخلها.
2. **محطة الشيت/الهيستوري** — ممكن دكتور معيّن (مساعد) يعملها لتسهيل الموضوع على الطبيب الأساسي.
3. **الزيارة نفسها** — الشكوى + التشخيص + الروشتة + طلبات التحاليل/الأشعة + إدخال النتايج.
**التلاتة مع بعض أو منفصلين حسب فلو كل عيادة/مركز/مستشفى.**

**التصميم المرسّب:** اللوحات مكونات منفصلة أصلًا (vitals-panel/history-panel داخل consultation) → الفصل = شاشات محطات worklist-driven («محطة القياسات» للتمريض بطابور الواصلين وصلاحية `clinic.vitals.record` فقط · «محطة الشيت» بصلاحية `clinic.history.record`) والدمج = الشاشة الكاملة كاليوم. **إنجاز المحطة مشتق من وجود الداتا** (بلا حالات جديدة) — الطابور يعرض ✓ قياسات / ✓ شيت فالطبيب يعرف الجاهز. إعداد `clinic.visit_stations` + أدوار presets (تمريض/مساعد). المحطات: م2 (علامات الطابور) + م3 (شاشات المحطات) + م9 (الإعدادات/الأدوار). متسق مع «الكور واحد»: نفس اللوحات — تركيبات مختلفة لكل عميل.

## نتايج التحاليل/الأشعة — قدرة دائمة للدكتور في كل الأوضاع (المالك، 2026-07-02)
الدكتور **يدخل النتايج أو يشوفها من شيته في كل حالات البرنامج** — القدرة mode-independent: متكامل → النتايج تلقائي من LIS/RIS + يقدر يدخل نتيجة اتعملت خارجيًا · مستقل → إدخاله (قيمة رقمية / صورة / PDF — خطوة اختيارية) هو المسار · العرض موحّد على الشيت بشارة مصدر («خارجي»). الميكانيزم المبني: مسار L3 (external-result على النية) — يتعمم على خدمات standalone. البوابة الوحيدة = صلاحية `clinic.results.external`، **الوضع لا يمنع أبدًا**.

## الجدولة اختيارية — وضع الحجز الحر (المالك، 2026-07-02)
عيادات كتير مش بتشتغل بجداول الكشف — بتحجز أي عدد في نفس المعاد. → إعداد `clinic.scheduling_mode`: **`slots`** (مواعيد بسعة، ومعه toggle السماح بالتجاوز — `allow_overbooking` الموجود) أو **`open`** (حجز حر: شاشة الحجز تتخطى الـ slots خالص، الطابور بترتيب الوصول). ينضم لمجموعة 📅 تشغيل في مخطط الإعدادات (م1).