Chapter 08 — وثيقة تصوّرية

العمارة التقنية (System Architecture)

بنية مؤسسية متعددة الطبقات، مصمّمة للتكامل مع أنظمة المستشفى القائمة (HIS/EMR) ولتحمّل أحمال تشغيل مستشفى كامل — موثّقة هنا كمخطط مفهومي وليست بيئة تشغيل فعلية.

08.1

الطبقات الست للنظام

من واجهة المستخدم إلى قاعدة البيانات — كل طبقة مستقلة قابلة للتوسّع أفقياً دون التأثير على الطبقات الأخرى.

1. UI Layer
Patient / Companion / Doctor / Dietitian / Kitchen / Nursing / Admin / Executive apps
2. API Gateway
مصادقة، تحديد معدل الطلبات، توجيه الطلبات، تسجيل العمليات
3. Microservices
Diet Rules · Orders · Kitchen · Notifications · Feedback · Users & Roles
4. AI & Analytics
محرك التوصيات الذكية، التنبؤ بالطلب، لوحات BI التنفيذية
5. Integration Bus
HIS/ADT · EMR · LIS · Pharmacy · Active Directory · WhatsApp Business API
6. Data Layer
قواعد بيانات علائقية + مخزن تحليلي + أرشفة سجلات التدقيق
08.2

مسار الطلب من الجوّال إلى المطبخ

مثال حي: مريض يطلب وجبة معتمدة من تطبيقه إلى لحظة ظهورها على شاشة المطبخ وإشعاره عبر واتساب.

Patient Appاختيار الوجبة
API Gatewayمصادقة + تحقق
Diet Rules Engineمطابقة مع الحمية المعتمدة
Orders Serviceتسجيل الطلب + الجدولة
Kitchen Displayيظهر في لوحة Kanban
Notification Serviceتنبيه واتساب للمريض
08.3

التكامل مع أنظمة المستشفى القائمة

لا تُبنى المنظومة بعزلة — بل تتكامل عبر واجهات برمجية (APIs) وطبقة ناقل رسائل (Integration Bus) مع الأنظمة التالية:

HIS / ADT
بيانات التنويم والغرف والأقسام
EMR / EHR
الملف الطبي والتشخيص
LIS
نتائج المختبر المرتبطة بالحمية
Pharmacy
تفاعلات الدواء والغذاء
Billing / ERP
فاتورة المريض والمرافق منفصلتان
Active Directory
صلاحيات الموظفين حسب الدور
WhatsApp Business API
روابط الدخول، OTP، إشعارات الطلب — القناة الرسمية الوحيدة للتواصل
Kitchen / Inventory
مخزون المكوّنات والوجبات المتاحة
08.4

نموذج البيانات (Entity Relationship)

الكيانات الأساسية للمنظومة — مع فصل واضح بين هوية المريض وهوية المرافق كسجلّين مستقلّين مرتبطين فقط بعلاقة "مرتبط بغرفة" دون تشارك بيانات طبية.

الكيانالوصفالعلاقات الأساسية
Patientبيانات المريض، رقم الجوال المسجّل (مفتاح دخول المريض الوحيد)، MRN مخزَّن داخلياً فقط ولا يُعرض للمريض أو يُدخله بنفسه1—N Admission، 1—N Order
Companionحساب مستقل تماماً: اسم، رقم جوال خاص، قناة واتساب خاصةN—1 Room (ربط قراءة فقط) — لا علاقة مباشرة مع Patient
Admissionسجل التنويم، الغرفة، القسم، تاريخ الدخولN—1 Patient
DietProfileالحمية المعتمدة حالياً للمريض وتاريخها1—1 Admission، N—1 DietType
DietTypeقاموس حميات مفتوح ولا حدّ أعلى لعدد الأنواع (29 حمية مسجّلة حالياً عبر دليل v2.0)، مع كودها اللوني المعتمد ونافذة الطلب الخاصة بها — يمكن لأخصائي التغذية/المدير إضافة أي عدد من الحميات الجديدة وألوانها دون تعديل برمجي (جدول diets في RESTful Table API)1—N DietProfile، 1—N MealCatalogItem
MealCatalogItemالوجبة من القائمة الرسمية (اسم، سعرات، مسببات حساسية، صورة)N—1 DietType، 1—N OrderLine
Orderطلب المريض أو المرافق (رئيسي أو إضافات)، موعد تسليم مختار من قبل المريض/المرافق من بين نوافذ المطبخ الرسمية الثلاث فقط (فطور/غداء/عشاء)، الحالة، وعلم إن كان الطلب منفَّذاً بالنيابة من الطاقم (isProxyOrder)N—1 Patient أو N—1 Companion، 1—N OrderLine
KitchenTicketتذكرة تحضير على لوحة Kanban بالمطبخ1—1 Order
Feedbackتقييم ونجوم وملاحظات المريض/المرافق بعد التسليمN—1 Order
AuditLogسجل تدقيق لكل اعتماد حمية، تعديل طلب، أو طلب منفَّذ بالنيابة عن المريض عبر بحث MRN (مقيّد باسم الموظف ووقت التنفيذ)N—1 User (Staff)
08.5

الأمن والالتزام (Security & Compliance)

الهوية والوصول

تحقق ثنائي عبر واتساب لكل من المريض والمرافق بشكل مستقل، صلاحيات محددة لكل دور وظيفي (RBAC)، وجلسات محدودة الصلاحية.

حماية البيانات

تشفير أثناء النقل والتخزين، فصل بيانات المرافق عن الملف الطبي، والامتثال لأنظمة حماية البيانات الصحية المحلية.

التدقيق والامتثال

سجل تدقيق كامل لكل اعتماد حمية وكل تعديل طلب، مع إمكانية استخراج تقارير الامتثال لجهات الاعتماد الصحي.

08.6

البنية التحتية والاستمرارية

نشر مرن (Flexible Deployment)

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

التوفر العالي

تكرار للخدمات الحرجة (الطلبات، المطبخ، الإشعارات) لضمان استمرارية الخدمة على مدار الساعة.

التعافي من الكوارث

نسخ احتياطي دوري وخطة تعافي موثقة (RPO/RTO) تناسب بيئة الرعاية الصحية الحرجة.