في هذه الصفحة
مساريMasary
منظومة لتنظيم صف الطوارئ: تطبيق جوال للمريض، وتطبيقا سطح مكتب لفريق الطوارئ وللإدارة، على خادم واحد، منشورة على المتجرين في نسخة تجريبية مغلقة.
- 3 أشهرمدة البناء
- 3تطبيقات المنظومة
- 4أنظمة تشغيل مدعومة
الوضع الذي بُني له مساري#
مساري منتج من داخل الشركة، لا مشروع عميل. بنيناه لتنظيم صف الانتظار في أقسام الطوارئ: من يدخل، وفي أي ترتيب، وما الذي يعرفه المريض وأهله عن موقعهم في الصف.
قسم الطوارئ يدير في اللحظة نفسها أمرين متعارضين: ترتيب طبي يقرره الفريق حسب الحالة، وناساً في صالة انتظار لا يرون هذا الترتيب ولا يفهمونه. غياب المعلومة عن الصف يخلق ضغطاً على الموظف عند الاستقبال، ويحوّل جزءاً من وقت الفريق من العمل الطبي إلى الرد على سؤال متكرر عن الدور.
وفي الجهة المقابلة، الفريق نفسه يحتاج شاشة واحدة يرى فيها الصف كله في وقت واحد، لا سجلاً ورقياً ولا نافذة متصفح بين عشر نوافذ أخرى.
التحدي#
المنتج الواحد هنا يخدم ثلاث فئات لا تشترك في جهاز ولا في نمط استخدام: المريض، وفريق الطوارئ في المنشأة، والجهة التي تدير المنظومة كلها.
المريض يستخدم جواله دقيقة واحدة في ظرف ضاغط، وقد يكون أحد أهله هو من يفتح التطبيق نيابة عنه. فريق الطوارئ يستخدم شاشة ثابتة طوال الوردية ويحتاج استجابة فورية وسلوكاً لا يتغير. الجهة المديرة تحتاج تحكماً في المنشآت والصلاحيات والبيانات.
هذا يعني ثلاثة تطبيقات لا تطبيقاً واحداً بثلاث واجهات، وخادماً واحداً يجمعها ويحافظ على حالة الصف صحيحة لدى الجميع في اللحظة نفسها. أضف إلى ذلك أن البيانات صحية، أي أن الأمان والصلاحيات ليسا تحسيناً يؤجَّل إلى نسخة لاحقة.
ما قررنا ألا نبنيه#
لم نبنِ سجلاً طبياً، ولا ملفاً للمريض، ولا نظام مواعيد عيادات، ولا فوترة ولا مطالبات تأمين. مساري ينظّم الصف وينقل حالته، ويتوقف عند هذا الحد.
استبعدنا أيضاً الربط بأنظمة المستشفيات القائمة في النسخة الأولى. كل ربط من هذا النوع مشروع مستقل بمواصفاته وموافقاته وجدوله، وإقحامه مبكراً كان سيحوّل ثلاثة أشهر إلى سنة قبل أن نتحقق من الفكرة نفسها.
ما نفّذناه#
أربع قطع فوق خادم واحد: تطبيق جوال للمريض، وتطبيق سطح مكتب لفريق الطوارئ، وتطبيق سطح مكتب للإدارة، وصفحة تعريفية كاملة للمنتج. الواجهات صُمِّمت ضمن تصميم واجهات وتجربة المستخدم، والبنية الخلفية ضمن برمجة الأنظمة المخصصة.
تطبيق المريض#
تطبيق جوال منشور على App Store وGoogle Play ضمن خدمة برمجة تطبيقات الجوال. وظيفته الأساسية واحدة: الانضمام إلى صف الطوارئ ومتابعة الحالة. صمّمناه ليُستخدم بيد واحدة وفي دقيقة، لأن من يفتحه لا يكون في وضع يسمح بتصفح شاشات.
تطبيق فريق الطوارئ#
تطبيق سطح مكتب يعمل على Windows وmacOS، ضمن خدمة برمجة تطبيقات سطح المكتب. يعرض الصف كاملاً ويتيح للفريق إدارته والتحكم في حالات المرضى داخل المنشأة.
اخترنا سطح المكتب لا نافذة متصفح لأن هذه الشاشة تعمل ساعات متصلة في مكان لا يحتمل تبويباً يُغلق بالخطأ أو جلسة تنتهي صلاحيتها في منتصف الوردية. الفرق بين التطبيق المثبَّت والصفحة في المتصفح شرحناه في سياق آخر في برنامج نقاط بيع بدون إنترنت، والمنطق نفسه ينطبق هنا.
تطبيق الإدارة#
تطبيق سطح مكتب ثانٍ، منفصل تماماً عن تطبيق الفريق الطبي، لإدارة المنظومة والمنشآت والصلاحيات. الفصل بين التطبيقين قرار أمني قبل أن يكون تنظيمياً: صلاحيات الإدارة لا تسكن الجهاز نفسه الذي يعمل عليه فريق الوردية.
الفصل بين تطبيقين بدل دور إضافي داخل تطبيق واحد يكلف بناءً أكثر، ويشتري مقابله حدوداً واضحة: خطأ في شاشة الإدارة لا يصل إلى شاشة الوردية، وجهاز في صالة القسم لا يحمل أصلاً الكود الذي يدير المنشآت والصلاحيات.
الخادم الخلفي وصفحة المنتج#
الخادم هو مصدر الحقيقة الوحيد لحالة الصف، وبُني ليتحمل نمواً في عدد المنشآت لا في عدد المستخدمين وحده، لأن كل منشأة جديدة تعني صفاً مستقلاً وصلاحيات مستقلة. وإلى جانبه صفحة تعريفية كاملة للمنتج، بُنيت ضمن تطوير المواقع الإلكترونية.
جهة المريض
جوال، استخدام قصير تحت ضغط، معلومة واحدة مطلوبة: موقعه في الصف وحالته.
جهة فريق الطوارئ
شاشة مثبَّتة طوال الوردية، عرض للصف كله، تحكم في الحالات، وسلوك ثابت لا يتغير بتغير المتصفح.
القرارات التي حسمت المشروع#
القرار الأول: تعدد المنصات شرط لا خيار. المستشفيات لا تتوحد على نظام تشغيل واحد، فبنينا تطبيقي سطح المكتب على Windows وmacOS معاً، وتطبيق المريض لأندرويد وiOS. منتج يشترط جهازاً بعينه يخسر المنشأة كلها لا مستخدماً واحداً.
القرار الثاني: الأمان يسبق الميزة. البيانات هنا صحية، والصلاحيات مفصولة بين ثلاثة تطبيقات، وكل واجهة لا ترى إلا ما يخص دورها. اختصرنا الميزات في النسخة الأولى بدل أن نختصر هذا الجانب.
القرار الثالث: الاعتمادية تُقاس في أسوأ لحظة لا في المتوسط. صف الطوارئ لا يحتمل شاشة تتأخر ثوانيَ أو حالة صف تختلف بين جهازين. جعلنا حالة الصف تُقرأ من مصدر واحد، ورفضنا كل ميزة تزيد احتمال اختلاف نسختين من الحقيقة.
النتيجة#
سلّمنا المنظومة كاملة في ثلاثة أشهر بفريق صغير: تطبيقان لسطح المكتب، وتطبيق جوال، وخادم، وصفحة منتج. تطبيق المريض منشور فعلياً على App Store وGoogle Play، وتجاوز مراجعة المتجرين، وهي خطوة تسقط فيها تطبيقات كثيرة لأسباب لا علاقة لها بالبرمجة.
المدة نفسها تستحق قراءة صحيحة. ثلاثة أشهر لأربع قطع لم تكن ممكنة باختصار الجودة، بل باستبعاد السجل الطبي والفوترة والربط من النطاق منذ اليوم الأول. النطاق الضيق هو ما يشتري السرعة، لا العمل بساعات أطول.
المنتج الآن في نسخة تجريبية مغلقة: الوصول إليه يمر عبرنا، والمنشآت المشاركة تُفعَّل يدوياً. اخترنا هذا لأن نظاماً يعمل في قسم طوارئ لا يُفتح للعامة بضغطة زر، بل يدخل منشأة واحدة في كل مرة مع متابعة قريبة.
ما بعد الإطلاق#
النسخة التجريبية المغلقة تعني أن ما نراه اليوم ملاحظات استخدام لا أرقام سوق، ولا ننشر أرقاماً عن منتج لم يفتح أبوابه بعد.
ما نبنيه تالياً محكوم بما نتعلمه من المنشآت المشاركة، لا بقائمة ميزات كُتبت قبل الإطلاق. الربط بأنظمة المستشفيات القائمة أول ما يُدرَس حين تطلبه منشأة فعلياً، لأن الربط يستحق ثمنه حين يكون له مستخدم ينتظره.
ومساري نفسه إجابة عملية عن سؤال يتكرر علينا: هل تبنون منظومة تعمل على الجوال وسطح المكتب معاً بخادم واحد. الجواب منتج نشغّله نحن، لا شريحة في عرض تقديمي.
الخطوة التالية
لديك مشروع مشابه؟
احصل على استشارة مجانية وعرض سعر تفصيلي خلال يوم عمل واحد.
ماذا يحدث بعد ذلك؟
- استشارة مجانية لمدة 30 دقيقة
- عرض سعر تفصيلي خلال يوم عمل واحد
- بداية التطوير خلال أسبوع