تخطَّ إلى المحتوى الرئيسي
AMA GROUP
مشروع تصوّري: تصوّر تصميمي يوضّح طريقة تفكيرنا، وليس مشروعًا منفّذًا لعميل.

الرعاية الصحية

نبضمنصة متكاملة لحجز المواعيد الصحية

تصوّر لمنصة تنظّم رحلة المريض من الحجز حتى باب العيادة عبر فروع متعددة، بتكامل قائم على معيار HL7 FHIR.

واجهة تصوّرية ببيانات توضيحية، وليست منتجًا قائمًا.

01

التحدي

في مجموعات العيادات متعددة الفروع يبقى الهاتف قناة الحجز الرئيسية، وتتوزّع جداول الأطباء بين أنظمة وفروع مختلفة. يصعب على المريض معرفة أقرب موعد متاح، ويصعب على الإدارة رؤية الطاقة الاستيعابية الفعلية.

وتتراكم الآثار: مواعيد يتغيّب عنها أصحابها دون إلغاء فتضيع على مرضى آخرين كانوا في حاجة إليها، وصالات انتظار مزدحمة، وتحقّق من التغطية التأمينية يجري عند مكتب الاستقبال لا قبل الزيارة، فيكتشف المريض المفاجأة متأخرًا.

وكل ذلك يجري على بيانات من أشدّ الفئات حساسية. فأي حل يجب أن يتكامل مع نظام المعلومات الصحية القائم لا أن يستبدله، وأن يراعي نظام حماية البيانات الشخصية ومتطلبات منصة «نفيس» للتبادل الصحي التأميني، وأن يحفظ أثرًا كاملًا لكل وصول إلى سجل مريض.

02

الحل المقترح

يتمحور «نبض» حول محرّك جدولة يدير الموارد لا الأطباء وحدهم: الطبيب والغرفة والجهاز معًا، بقوالب مواعيد مرنة حسب التخصص ونوع الزيارة. وتعرض المنصة أقرب موعد متاح عبر كل الفروع، وتدير قائمة انتظار ذكية تعرض المواعيد الملغاة تلقائيًا على المرضى التالين.

ويجري التكامل عبر طبقة HL7 FHIR R4 تعرض موارد Patient وPractitioner وSchedule وSlot وAppointment بصيغة قياسية، مع محرّك واجهات يترجم رسائل HL7 v2 للأنظمة القديمة. وبذلك تبقى المنصة طبقة وصول للمريض فوق نظام المعلومات الصحية القائم، لا بديلًا عنه.

وتشمل الرحلة تحققًا مسبقًا من الأهلية التأمينية عبر تدفقات مصمّمة للتوافق مع «نفيس»، وتسجيل وصول ذاتيًا من الجوال أو من كشك الاستقبال، وطابورًا افتراضيًا يُعلم المريض باقتراب دوره، وزيارات عن بُعد لمواعيد المتابعة.

03

منطق التصميم

  • يستخدم المنصة مرضى من كل الأعمار، لذا صُمّمت لتُفهم من النظرة الأولى: أهداف لمس كبيرة، ولغة بسيطة بعيدة عن المصطلحات الطبية حيثما أمكن، ودعم كامل لتكبير الخط وقارئات الشاشة وفق WCAG 2.2 AA. ويستطيع ربّ الأسرة حجز مواعيد لأفرادها التابعين من حساب واحد.

  • الخصوصية ظاهرة في التصميم: إشعارات شاشة القفل لا تكشف التخصص ولا سبب الزيارة، وشاشات الموافقة مكتوبة بلغة واضحة لا بصياغة قانونية مبهمة، ويستطيع المريض أن يرى من اطّلع على بياناته.

  • في المقابل، تقدّم واجهة الاستقبال كثافة عالية تناسب الموظف المتمرّس: عرض يومي لكل الأطباء والغرف، واختصارات لوحة مفاتيح للحجز السريع، وحالات وصول ملوّنة مقرونة بنص. وتتبع الواجهتان نظام تصميم واحدًا بوضعين داكن وفاتح.

04

مثال على المعمارية

تقسيم توضيحي لطبقات النظام، من الشاشات التي يستخدمها الناس إلى البنية التحتية. نقطة انطلاق نتحقق منها في مرحلة الاكتشاف، وليست تصميمًا نهائيًا.

  1. طبقة 01

    طبقة التجربة

    • تطبيق المريض بـ Flutter مع ملفات أفراد الأسرة
    • حجز عبر الويب بـ Next.js
    • لوحة الاستقبال والجدولة
    • جهاز خدمة ذاتية لتسجيل الوصول في الردهة
  2. طبقة 02

    التكامل

    • واجهة HL7 FHIR R4 (عبر HAPI FHIR)
    • محرك واجهات HL7 v2 لأنظمة المعلومات الصحية القديمة
    • محوّل للتحقق من الأهلية التأمينية
    • إشعارات عبر الرسائل النصية وواتساب والإشعارات الفورية
  3. طبقة 03

    خدمات النطاق

    • محرك جدولة قائم على الموارد
    • قائمة انتظار ذكية وإعادة ملء المواعيد الشاغرة
    • طابور افتراضي وتسجيل الوصول
    • جلسات رعاية عن بُعد عبر WebRTC
  4. طبقة 04

    الأمن والخصوصية

    • إدارة الموافقات
    • تشفير البيانات الصحية على مستوى الحقل
    • تدقيق الوصول مع إجراء للوصول الطارئ
    • دخول موحّد ومصادقة متعددة العوامل للموظفين عبر Keycloak
  5. طبقة 05

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

    • PostgreSQL
    • أقفال Redis لحجز المواعيد
    • Kubernetes في منطقة سحابية داخل المملكة
    • قابلية الرصد عبر OpenTelemetry

05

التقنيات المقترحة

أدوات قد نعتمدها في هذا التصوّر، وتشير إلى منظومات تقنية نعمل بها، لا إلى شراكات أو شهادات.

  • Flutter
  • Next.js
  • TypeScript
  • Kotlin
  • Spring Boot
  • HL7 FHIR R4
  • HAPI FHIR
  • Mirth Connect
  • PostgreSQL
  • Redis
  • WebRTC
  • Keycloak
  • Kubernetes

06

أبرز المزايا

  • أقرب موعد عبر كل الفروع

    بحث موحّد في جداول الأطباء والفروع يعرض أقرب موعد مناسب حسب التخصص والموقع.

  • قائمة انتظار ذكية

    إعادة عرض المواعيد الملغاة تلقائيًا على المرضى المنتظرين مع تأكيد سريع.

  • تحقّق تأميني مسبق

    معرفة الأهلية والتغطية قبل الزيارة، لا عند مكتب الاستقبال.

  • تسجيل وصول وطابور افتراضي

    وصول ذاتي من الجوال أو الكشك، وتنبيه عند اقتراب الدور يخفّف ازدحام الصالات.

  • تكامل قائم على FHIR

    تبادل بيانات قياسي مع نظام المعلومات الصحية القائم دون استبداله.

  • زيارات عن بُعد

    مواعيد متابعة مرئية آمنة ضمن الرحلة نفسها.

07

الفوائد المحتملة

هذه أهداف تصميمية يُبنى الحل لتحقيقها، وليست نتائج مُقاسة.

  • الحدّ من المواعيد الضائعة عبر التذكيرات وإعادة توزيع الإلغاءات

  • تخفيف الازدحام في صالات الانتظار

  • تقليل المفاجآت التأمينية بالتحقق قبل الزيارة

  • رؤية أوضح للطاقة الاستيعابية عبر الفروع

  • حماية أقوى للبيانات الصحية مع أثر تدقيق كامل

القطاع

الرعاية الصحية

منصات صحية رقمية محورها المريض، من حجز المواعيد والرعاية الافتراضية إلى تكامل البيانات السريرية.

الخدمات المرتبطة

  • تطبيقات الجوال

    تطبيقات iOS وAndroid أصلية ومتعددة المنصات، بتجربة عربية متقنة وأداء ثابت ومسار نشر واضح في المتاجر.

  • المواقع وتطبيقات الويب

    مواقع مؤسسية ومتاجر ومنصات ويب ثنائية اللغة، تُبنى للسرعة والأمان والتوسع منذ السطر الأول.

  • واجهات API وتكامل الأنظمة

    واجهات REST وGraphQL، وتكامل المدفوعات، وتكاملات قائمة على الأحداث تجعل أنظمتك المنفصلة منظومة واحدة.

  • هندسة الأمان البرمجي

    أمان يُبنى في المعمارية والشيفرة وخطوط النشر منذ اليوم الأول، لا يُضاف بعد الإطلاق.

  • تصميم المنتجات وتجربة المستخدم

    تصميم منتجات قائم على البحث، من رحلات المستخدم إلى أنظمة تصميم جاهزة للتطوير في الواجهات المؤسسية المعقّدة.

مشروع تصوّري: تصوّر تصميمي يوضّح طريقة تفكيرنا، وليس مشروعًا منفّذًا لعميل.

هذا مشروع تصوّري أعدّته AMA GROUP لتوضيح منهجيتها، وليس عملًا منفّذًا لعميل؛ فالواجهة تعرض بيانات توضيحية، ولا تشير إلى أي عميل أو شعار أو نتائج محقّقة.

لديك تحدٍّ مشابه؟

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