مستشفى حلب — نظام المعلومات الصحي

صفحة مرجعية للدراسة وخطة البناء — قابلة للتعديل

مرجع المشروع

دراسة وتحليل مشروع HIS

← العودة للعرض التجريبي

1. الرؤية والقرارات الأساسية

التوصية: لا نبني مشروعاً منفصلاً بقاعدة بيانات جديدة. نوسّع منصة حجز المواعيد الحالية (AleppoAppointmentBookingSystem) بمساحة Clinical/ داخل Core، مع واجهة كادر طبي منفصلة (Web.HIS).
الطبقةالقرار
قاعدة البياناتقاعدة واحدة SQL Server — نفس ApplicationDbContext
المنطق المشتركAleppoAppointmentBookingSystem.Core — مساحة Clinical/
واجهة الكادر الطبيWeb.HIS (هذا المشروع)
واجهة المريضWeb.Citizen + تطبيق موبايل لاحقاً
لوحة الإدارةWeb.Full — توسيع تدريجي
المعاييرICD-10، INN/ATC، FHIR (تبادل)، LOINC/SNOMED (لاحقاً)
الجداول الديناميكيةEAV + JSON Schema — كفلسفة RequestField الحالية

المرجع: 812_Technologies_Official_quotation - HIS.docx — الدراسة الكاملة: docs/HIS-Architecture-Study.md — آخر مراجعة: 2026-07-03

2. ثلاثة منتجات — لا نخلط بينها

📋 دراسة وتحليل

قرارات معمارية، مراحل، معايير، مخاطر. هذه الصفحة + ملف Markdown.

🎬 عرض تفاعلي (Demo)

صفحات HTML + localStorage لعرض سريع على الإدارة أثناء الاجتماعات.

🏥 نظام HIS فعلي

Auth + DB + APIs في Core. الواجهة الحقيقية تُبنى تدريجياً وتستبدل Demo.

3. تحليل الوحدات — العرض مقابل الواقع

الوحدة المتطلب الجوهري الوضع الفجوة
حجز موعد حجز سريع، طبيب/قسم/وقت جاهز تحسين UX، ربط EHR
دور ذكي (Queue) طوابير عيادات + أقسام، شاشات، تابلت ممرض تصميم معتمد استقبال مركزي + شاشات — انظر القسم 7أ
ملف طبي (EHR) تاريخ زيارات، تشخيصات، وصفات بداية Encounter + واجهة طبيب حقيقية
عيادات وأقسام تخصصات، مواعيد لكل طبيب جاهز ربط Service بنوع عيادة
مختبر / أشعة طلب، نتيجة، مرفقات Demo فقط وحدة جديدة + استمارات
صيدلية وصفة إلكترونية، مخزون جزئي جدول Medicines + وصفات + صرف
فوترة وتأمين فواتير، تقارير مالية غير موجود Billing module
إحالات طبيب → مختبر → أشعة → صيدلية نموذج DB ClinicalReferral + workflow
تقارير لحظية Dashboards، أمراض، أرباح جزئي Analytics layer
استمارات إلكترونية Form Builder، قوالب لكل تخصص APIs Clinical Form Engine + UI
تطبيق موبايل ملف طبي، نتائج، حجز Citizen web Flutter لاحقاً

4. البنية المقترحة

AleppoAppointmentBookingSystem.sln
├── Core
│   ├── Models/
│   ├── Clinical/          ← EHR, Forms, Prescriptions, Referrals
│   ├── Services/
│   └── Data/
├── Web.Full               ← Admin + API عام
├── Web.Citizen            ← مريض
└── Web.HIS                ← أطباء، تمريض، استقبال (هذا المشروع)

لماذا Web.HIS منفصل؟

  • واجهة مختلفة (RTL، شاشات سريعة، لوحة طبيب، Form Builder)
  • صلاحيات: Doctor, Nurse, Reception, Pharmacist, LabTech
  • نشر على subdomain: his.example.com مع نفس JWT و Core
  • Citizen يبقى خفيفاً للمريض فقط

ما أُنجز في الكود حتى الآن

البندالحالة
مشروع Web.HISموجود
scripts/HIS_Clinical_Schema.sqlموجود
كيانات Clinical/* في Coreموجود
APIs encounters / form-templates / codingموجود
واجهة Demo (HTML + localStorage)موجود
Form Builder + واجهة طبيب حقيقيةقيد البناء
ربط Demo بالـ APIلم يبدأ

5. استراتيجية البيانات — بدون ALTER TABLE

طبقة الترميز

ثابتة، معيارية: MedicalDiagnoses (ICD-10)، Medicines (INN/ATC)، CodingSystems

طبقة التعريف (Metadata)

ديناميكية عبر واجهة: ClinicalFormTemplates، ClinicalFormFields، FieldRules

طبقة القيم (Instance)

EAV + JSON: ClinicalFormInstances، ClinicalFormFieldValues

جداول نواة الزيارة (تُنشأ مرة واحدة)

الجدولالغرض
ClinicalEncountersزيارة طبية مرتبطة بموعد (AppointmentId)
ClinicalObservationsعلامات حيوية وملاحظات
ClinicalDiagnosesتشخيص مسجّل — FK إلى MedicalDiagnoses
ClinicalPrescriptions / Linesوصفة وسطور دواء — FK إلى Medicines
ClinicalReferralsإحالة بين أقسام
ClinicalAttachmentsصور، PDF، DICOM ref
قاعدة ذهبية: إضافة استمارة طبية جديدة = صفوف في جداول metadata (ClinicalFormTemplates + ClinicalFormFields) — وليس ALTER TABLE. نمط موجود مسبقاً في RequestField / AppointmentBookingData.

6. المعايير الطبية والعلمية

المعيارالاستخدامالمرحلة
ICD-10 (WHO)التشخيص، إحصاء الأمراضالمرحلة 1
INN + ATC (WHO)الأدوية والوصفاتالمرحلة 1
SNOMED CTمفاهيم سريرية إضافيةالمرحلة 2
LOINCطلبات ونتائج مختبرالمرحلة 3
HL7 FHIR R4نموذج تبادل — Mapping عند التصديرتدريجي

ربط FHIR (تبادل فقط — ليس تخزيناً أولياً)

كيانناFHIR Resource
User (مواطن)Patient
Appointment + ClinicalEncounterEncounter
ClinicalDiagnosisCondition
ClinicalPrescriptionLineMedicationRequest
ClinicalObservationObservation
ClinicalReferralServiceRequest
ClinicalFormInstanceQuestionnaireResponse

7. رحلة المريض (مبسّطة)

مبدأ: المريض لا يتتبع تطبيقاً ولا يمسح QR. يحجز عن بُعد (هو أو ذويه)، يصل للمركز، يدفع ويقطع وصلاً عند الاستقبال، يجلس وينظر الشاشة حتى يُنادى اسمه.
حجز عن بُعد → وصول (≤10 د قبل الموعد) → دفع + قطع وصل → غرفة الانتظار (شاشة) → ممرض ينادي → طبيب + تشخيص → أقسام (مخبر/صيدلية/أشعة)

MVP المعتمد (قابل للتعديل)

حجز → وصل استقبال → طابور عيادة → طبيب (Encounter + تشخيص) → إحالة قسم → تنفيذ/تعذر

7أ. دور الانتظار — التصميم المعتمد

قرار 2026-07-03: سلوك بسيط للمريض. موظف استقبال واحد لجميع عيادات المركز. اسم المريض دائماً من AppointmentBookingData المرتبط بالموعد.

أدوار الواجهات

الواجهةالمستخدمالوظيفة
استقبال مركزي موظف الاستقبال بحث موعد اليوم → تأكيد الدفع → قطع وصل → إدراج المريض في طابور عيادته
شاشة غرفة الانتظار (TV) المرضى أسماء العيادات، وتحت كل عيادة: رقم الدور + الاسم لمن قطع وصلاً ولم يدخل بعد (بالتسلسل)
تابلت الممرض ممرض العيادة قائمة رقم + اسم → زر «التالي» → يظهر الرقم والاسم على شاشة العيادة ويُنادى
شاشة العيادة (TV) غرفة الانتظار الفرعية / الممرض يعرض رقم الدور + الاسم للمريض المُستدعى حالياً (بخط كبير)
شاشة الطبيب طبيب / ممرض تشخيص، وصفة، إحالة لمخبر / صيدلية / أشعة / قسم آخر
طابور القسم مخبر / صيدلية / أشعة … قائمة محالين (رقم + اسم) → عند الوصول: تم التنفيذ أو تعذّر التنفيذ

تسلسل العمليات

┌─────────────────────────────────────────────────────────────────────────┐
│ 1. حجز عن بُعد (Citizen) — المريض أو ذويه — الاسم في AppointmentBookingData │
└─────────────────────────────────────────────────────────────────────────┘
                                    ↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 2. وصول المركز — لا يُقبل قطع الوصل قبل أكثر من 10 دقائق من الموعد      │
└─────────────────────────────────────────────────────────────────────────┘
                                    ↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 3. استقبال مركزي (موظف واحد لكل العيادات): دفع → قطع وصل → طابور العيادة │
└─────────────────────────────────────────────────────────────────────────┘
                                    ↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 4. شاشة غرفة الانتظار العامة                                           │
│    عيادة الباطنية:  12 أحمد — 13 فاطمة — 14 خالد                         │
│    عيادة الأطفال:   7 سارة — 8 عمر                                       │
│    (رقم الدور + الاسم — من قطع وصلاً ولم يُستدعَ بعد)                     │
└─────────────────────────────────────────────────────────────────────────┘
                                    ↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 5. تابلت الممرض: «التالي» → شاشة العيادة: «14 — خالد» → يدخل الطبيب    │
└─────────────────────────────────────────────────────────────────────────┘
                                    ↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 6. الطبيب: ClinicalEncounter + تشخيص + إحالات                           │
└─────────────────────────────────────────────────────────────────────────┘
                                    ↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 7. كل قسم محال إليه له طابور مستقل: وصول → تنفيذ ✓ / تعذر ✗            │
└─────────────────────────────────────────────────────────────────────────┘

ما يراه المريض (بساطة التتبع)

  • قبل الوصول: موعده وعيادته فقط (من رسالة الحجز أو Citizen).
  • بعد قطع الوصل: ينظر الشاشة — يرى رقم دوره واسمه ومن أمامه في عيادته.
  • عند الاستدعاء: رقم الدور + الاسم على شاشة العيادة — يدخل.
  • بعد الإحالة: يذهب للقسم وينتظر دوره هناك (رقم + اسم على شاشة القسم).
  • لا تطبيق تتبع، لا QR إلزامي للمريض.

عرض الشاشات: رقم الدور + الاسم

غرفة الانتظار العامة

12 — أحمد علي
13 — فاطمة حسن
14 — خالد محمود

رقم صغير + اسم — قائمة أفقية أو عمودية تحت اسم العيادة

شاشة العيادة (نداء)

14
خالد محمود

الرقم بارز كبيراً، الاسم تحته — للنداء الصوتي أيضاً

طابور القسم (مخبر/صيدلية)

3 — سارة أحمد
4 — عمر يوسف

رقم مستقل لكل قسم (ليس نفس رقم العيادة)

القاعدةالتفصيل
مصدر الاسمAppointmentBookingData
رقم دور العيادةيُمنح عند قطع الوصل — تسلسل يومي لكل عيادة (Service)
رقم دور القسمتسلسل يومي لكل قسم عند وصول المحال
صيغة العرض{رقم} — {الاسم} في كل الشاشات والطباعة
وصل الاستقباليطبع أو يعرض: رقم الدور + الاسم + العيادة + وقت الموعد

ربط بالبيانات الحالية

الحاجةالمصدر / الإجراء
اسم المريضAppointmentBookingData (FieldKey لاسم المريض في كل خدمة)
الموعد والعيادةAppointments + Service (العيادة = الخدمة/التخصص)
وقت قطع الوصل + رقم الدورAppointmentExecution.QueueNumber (لكل عيادة) أو ClinicQueueTicket
طابور العيادةترتيب حسب وقت الوصل — عرض QueueNumber + اسم من الحجز
حالة «دخل العيادة»عند ضغط الممرض «التالي» / ActualStartTime
الزيارة الطبيةClinicalEncounter عند دخول الطبيب
إحالة لقسمClinicalReferral → طابور القسم
تنفيذ / تعذرحالة الإحالة: Completed / Cancelled + سبب التعذر
تحديث الشاشاتSignalR (جديد) — polling كبديل مؤقت

حالات الطابور (مقترحة)

الحالةالمعنىتظهر في
Bookedحجز عن بُعد — لم يصل بعد—
TicketIssuedدفع + قطع وصل + رقم دورشاشة الانتظار: 12 — أحمد
Calledالممرض استدعى «التالي»شاشة العيادة: رقم كبير + اسم
InClinicدخل غرفة الطبيبيُزال من شاشة الانتظار العامة
WithDoctorالطبيب يفحصواجهة الطبيب
Referredأُحيل لقسمطابور ذلك القسم
DeptDone / DeptFailedنُفّذ / تعذّرسجل الإحالة

ما نستبعده (تعقيد غير مطلوب)

  • QR إلزامي للمريض عند الوصول
  • تطبيق موبايل لتتبع الدور لحظياً
  • طابور واحد لكل المركز دون تفصيل عيادات (الوضع الحالي في الكود)
  • موظف استقبال منفصل لكل عيادة

8. الأمان والصلاحيات

الدورالصلاحيات
Citizenحجز، ملفه، نتائجه
Receptionاستقبال مركزي: دفع، قطع وصل، إدراج طابور العيادة
Doctorencounter، تشخيص، وصفة، إحالة
Nurseتابلت العيادة: استدعاء «التالي»، شاشة العيادة
LabTechنتائج مختبر
Radiologistتقارير أشعة
Pharmacistصرف، مخزون
HospitalAdminForm Builder، تقارير، إعدادات
SystemAdminكل شيء
  • تشفير at-rest للمرفقات (AES-256)
  • Audit log: ClinicalAuditLog
  • QR اختياري لاحقاً — ليس جزءاً من سير الاستقبال المعتمد
  • Field-level masking حسب الدور

9. التقنيات

المجالالقرارالسبب
Backend.NET 9Core جاهز، EF، JWT
قاعدة البياناتSQL Serverلا migration مزدوج
Frontend HISHTML/React تدريجياًDemo الآن، React للإنتاج
MobileFlutter — مرحلة 5REST من نفس API
APIREST + OpenAPISwagger موجود
SQL vs MigrationsScript للـ Clinical + seed للبيانات المرجعيةكما اتفقنا للتشخيصات والأدوية

10. خطة المراحل — قابلة للتعديل

عدّل الخطوات مباشرة (انقر على النص)، أضف أو احذف مهاماً، غيّر حالة كل مرحلة. التعديلات تُحفظ تلقائياً في المتصفح. استخدم التصدير لمشاركة الخطة مع الفريق.

التقدّم الكلي: 0%

11. المخاطر وقرارات التخفيف

المخاطرةالتخفيف
تضخم EAV — بطء استعلاماتفهارس، JSON indexed columns، snapshots للتقارير
تعقيد Form Builderالبدء بـ 5 أنواع حقول + توسيع
Scope creep — كل الوحدات دفعة واحدةمراحل واضحة — MVP محدود
FHIR كامل مبكراًMapping عند التصدير فقط
ازدواجية Citizen/HISCore واحد، واجهات منفصلة

12. المراجع والملفات

الملفالغرض
docs/HIS-Architecture-Study.mdالدراسة الكاملة (Markdown)
scripts/HIS_Clinical_Schema.sqlجداول Clinical Core + Form Engine
scripts/MedicalDiagnoses_icd10_ar.sqlبيانات ICD-10 (~12,130 تشخيص)
scripts/Medicines_who_eml_ar.sqlبيانات INN/ATC
Core/Models/ServiceBookingField.csنمط EAV مرجعي
Core/Clinical/*كيانات وخدمات HIS
Web.HIS/Controllers/Clinical/*APIs السريرية
wwwroot/study.htmlهذه الصفحة المرجعية
الخطوة التالية: راجعوا خطة المراحل أعلاه، عدّلوا الخطوات حسب الأولويات، ثم ثبّتوا MVP وابدأوا المرحلة التالية غير المكتملة.