بنية مؤسسية متعددة الطبقات، مصمّمة للتكامل مع أنظمة المستشفى القائمة (HIS/EMR) ولتحمّل أحمال تشغيل مستشفى كامل — موثّقة هنا كمخطط مفهومي وليست بيئة تشغيل فعلية.
من واجهة المستخدم إلى قاعدة البيانات — كل طبقة مستقلة قابلة للتوسّع أفقياً دون التأثير على الطبقات الأخرى.
مثال حي: مريض يطلب وجبة معتمدة من تطبيقه إلى لحظة ظهورها على شاشة المطبخ وإشعاره عبر واتساب.
لا تُبنى المنظومة بعزلة — بل تتكامل عبر واجهات برمجية (APIs) وطبقة ناقل رسائل (Integration Bus) مع الأنظمة التالية:
الكيانات الأساسية للمنظومة — مع فصل واضح بين هوية المريض وهوية المرافق كسجلّين مستقلّين مرتبطين فقط بعلاقة "مرتبط بغرفة" دون تشارك بيانات طبية.
| الكيان | الوصف | العلاقات الأساسية |
|---|---|---|
| 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) |
تحقق ثنائي عبر واتساب لكل من المريض والمرافق بشكل مستقل، صلاحيات محددة لكل دور وظيفي (RBAC)، وجلسات محدودة الصلاحية.
تشفير أثناء النقل والتخزين، فصل بيانات المرافق عن الملف الطبي، والامتثال لأنظمة حماية البيانات الصحية المحلية.
سجل تدقيق كامل لكل اعتماد حمية وكل تعديل طلب، مع إمكانية استخراج تقارير الامتثال لجهات الاعتماد الصحي.
قابلة للنشر على بنية سحابية خاصة أو محلية داخل مركز بيانات المستشفى وفق سياسة أمن المعلومات.
تكرار للخدمات الحرجة (الطلبات، المطبخ، الإشعارات) لضمان استمرارية الخدمة على مدار الساعة.
نسخ احتياطي دوري وخطة تعافي موثقة (RPO/RTO) تناسب بيئة الرعاية الصحية الحرجة.