Clinic Tek منتج برمج تك لإدارة العيادات، وهذه دراسة حالة للمنتج نفسه لا شهادة عميل. تشرح كيف تحول مسار الموعد والزيارة والفاتورة إلى نطاق، وما القرارات التي اتخذناها في العربية والصلاحيات وتعدد المستأجرين والتكاملات. لا ننشر اسم عيادة أو بيانات مريض أو نسبة تحسن غير موثقة. ما يمكن فحصه علناً هو المنتج وسير العمل ببيانات تجريبية، وحدود الادعاء جزء من جودة الدراسة لا نقص فيها.
نقطة البداية: يوم عمل مجزأ
المشكلة التي صمم لها المنتج ليست «نقص شاشة». يوم العيادة يمر بين طلب موعد، وتسجيل مريض، وانتظار، وزيارة، وملاحظات، وخدمات، وفاتورة، ودفع، ومتابعة. عندما تعيش الحالات في أماكن منفصلة، يعيد الفريق الإدخال ويصعب تفسير ما اكتمل وما بقي. لكن جمع كل شيء في قاعدة واحدة لا يكفي؛ يجب أن يرى كل دور ما يحتاجه ويستطيع تنفيذ الفعل المسموح.
بدأ النطاق من رحلات وأدوار: موظف الاستقبال يدير الموعد والوصول، والطبيب يوثق الزيارة ضمن صلاحياته، والمالية تراجع الفاتورة والدفع، والإدارة تضبط الخدمات والمستخدمين والتقارير. هذه الحدود تمنع تصميم واجهة واحدة مزدحمة للجميع.
ما لم ندخله في الادعاء
Clinic Tek أداة لإدارة العمل، وليس جهازاً طبياً أو بديلاً عن حكم الطبيب. عرض تنبيه أو تنظيم ملف لا يعني تشخيصاً أو توصية علاج. كما أن التذكير لا يضمن حضور المريض، والدفع الإلكتروني لا يضمن زمناً أو رسماً ثابتاً؛ القناة والمزود والعقد تحدد التفاصيل.
لا نعزو وفراً أو نتيجة صحية إلى المنتج من دون قياس منشور وإذن. هذه الدراسة تصف التصميم والقدرات القابلة للعرض. أي عيادة تريد قياس الأثر تحتاج خط أساس وتعريفاً وملاحظة قبل وبعد.
صممنا الموعد كحالة لا كصف تقويم
يحمل الموعد المريض ومقدم الخدمة والوقت والمدة والحالة، مع قواعد للتعديل والإلغاء. يجب أن يعرف الاستقبال الفرق بين حجز مؤكد وطلب تغيير، وأن تبقى التعديلات قابلة للتفسير. لا يكفي سحب مربع على التقويم إذا أدى إلى تعارض أو فقدان سبب التغيير.
التذكير مرتبط بالموعد. ينشأ من حالة صحيحة ويتوقف أو يتغير عند تعديلها. الرد يحتاج العودة إلى الجدول بدل البقاء في قناة منفصلة. يشرح دليل أتمتة التذكيرات كيف تُقاس هذه الحلقة من دون افتراض تحسن مسبق.
فصلنا المريض عن الزيارة
ملف المريض يجمع الهوية وبيانات التواصل والمعلومات المسموح بها، بينما الزيارة حدث بزمن ومقدم خدمة ومحتوى. الفصل مهم لأن المريض قد يملك زيارات كثيرة، ولأن تصحيح معلومة عامة لا يجب أن يعيد كتابة تاريخ كل زيارة. كما يسمح بسياسة وصول أدق.
استخدمنا حقولاً منظمة حيث يفيد البحث والتقرير، ونصاً مرناً حيث تحتاج الملاحظة سياقاً. لا نحول كل معلومة طبية إلى خيار مغلق، ولا نترك كل شيء في مستند لا يمكن العثور فيه على ما يحتاجه المستخدم.
الصلاحية جزء من كل فعل
وجود تسجيل دخول ليس حماية كافية. تُفحص الصلاحية على المورد والفعل: من يرى الموعد، ومن يفتح الملاحظة، ومن يعدل خدمة، ومن يصدر تصديراً. لوحة الإدارة لا تلغي هذه الحدود بصمت. وتحتاج العمليات المهمة إلى أثر يوضح المستخدم والوقت والتغيير.
الدعم الفني يمثل حالة حساسة. لا ينبغي مشاركة كلمات المرور أو فتح وصول دائم. يحتاج أي وصول مساعد إلى سبب ومدة وسجل وفق السياسة المتفق عليها. كما يجب حذف وصول الموظف المغادر وتحديث الأدوار بانتظام.
العربية أثرت في البنية البصرية
بدأت الواجهة من RTL، لا من قلب صفحة إنجليزية بعد اكتمالها. اختبرنا اتجاه الحقول المختلطة، والأرقام والتواريخ، والقوائم والجداول والطباعة. استخدمنا مصطلحات يفهمها الدور بدلاً من أسماء تقنية. وفي الإنجليزية تبقى الرحلة كاملة وليست نصاً فوق تخطيط عربي.
العمل السريع في الاستقبال يحتاج تسلسلاً ولوحة مفاتيح ورسائل خطأ قابلة للإصلاح. الأيقونة لا تكون وحدها وصفاً لحالة مهمة، واللون لا يحمل معنى بلا نص. هذه القرارات تقلل الالتباس لكنها تحتاج اختباراً مع كل تغيير.
الفوترة تتبع ما حدث في الزيارة
الفاتورة ترتبط بالخدمات وحالتها، لكن دورة الفاتورة مستقلة عن الدفع. يمكن أن تكون هناك دفعة جزئية أو تصحيح أو حدث مزود متأخر. لا ينبغي تغيير الرصيد من زر بلا مرجع. نحتفظ بالحالات اللازمة للمراجعة ونفصل التأكيد الخارجي عن عودة المتصفح.
أي ربط مع الفوترة الوطنية أو مزود دفع يُراجع وفق المواصفة الرسمية والحساب المختار وقت التنفيذ. لا نضع مفتاحاً أو قراراً تنظيمياً في قلب المجال؛ يستخدم Adapter يترجم العقد والحالات والأخطاء.
اخترنا Laravel وPostgreSQL بحدود واضحة
Laravel يدير طبقات الويب والتفويض والطوابير وحالات الاستخدام، وPostgreSQL يخزن البيانات العلائقية. المنتج متعدد المستأجرين، لذلك يحمل السياق هوية العيادة عبر الطلب والاستعلام والمهام والـ cache والملفات. لا نقدم وجود tenant_id كدليل وحيد؛ الاختبارات تحاول الوصول المتبادل في المسارات المهمة.
التقارير والتصدير مسارات حساسة لأنها تقرأ مجموعات كبيرة. تخضع للنطاق والصلاحية، وتعمل في الخلفية عندما تكون ثقيلة، وتنتج ملفاً مرتبطاً بالمستأجر. يشرح دليل معمارية SaaS متعددة المستأجرين هذه الحدود بمزيد من التفصيل.
صممنا التكاملات للاستبدال
المزود الخارجي يتغير أو يفشل. لذلك يتعامل التطبيق مع عقد يصف النتيجة التي يحتاجها، بينما ينفذ Adapter تفاصيل API. المهمة تحمل مرجعاً ثابتاً، وتتعامل مع التكرار وإعادة المحاولة، وتظهر الحالات التي تحتاج تدخلاً.
لا يعني ذلك أن تغيير المزود مجرد تعديل اسم إعداد دائماً؛ اختلاف القدرات والعقود قد يحتاج عملاً. العزل يقلل مساحة التغيير ويمنع انتشار SDK في كل النظام.
عرّفنا حدود العمل عند ضعف الاتصال
عبارة «دون اتصال» يجب أن تُشرح وظيفة بوظيفة. بعض الشاشات يمكن أن تعرض حالة محفوظة، وبعض التغييرات تحتاج الخادم لتأكيد التعارض والصلاحية. لا نعد أن كل مسار طبي ومالي يعمل بلا شبكة. يظهر المنتج للمستخدم ما هو محفوظ محلياً وما ينتظر التحقق عند تصميم تلك القدرة.
اختبار الانقطاع يشمل فصل الشبكة وإعادتها ومراجعة التزامن، لا مجرد تحميل الصفحة مرة. وإذا تعارض تغيير، يحتاج المستخدم مساراً واضحاً بدل اختيار صامت قد يفقد معلومة.
البيانات التجريبية هي أساس العرض
يستخدم العرض أسماء وسجلات وهمية. يمر السيناريو من إنشاء المريض والموعد إلى زيارة وفاتورة وحالة دفع، ويمكن للمشاهد اختبار الأدوار. لا نطلب ملف مرضى حقيقياً لإثبات القدرة. عند مشروع هجرة فعلي، تُحدد عينة مضبوطة واتفاق نقل وحذف.
هذه السياسة تحمي الخصوصية وتجعل العرض قابلاً للتكرار بين المشترين. كما تمنع أن يتحول المثال إلى قصة عميل غير مأذونة.
القبول مبني على سيناريوهات
لا تُقبل ميزة لأنها ظاهرة في القائمة. نكتب حالة ناجحة وحالات رفض: مستخدم بلا صلاحية، وتعارض وقت، وسجل ناقص، وحدث مكرر، وانقطاع مزود. تختبر النتيجة والرسالة والأثر. في الأجزاء الحساسة، نضيف اختبارات Feature وحدوداً عبر أكثر من مستأجر.
تستخدم قائمة اختيار برنامج العيادات الفكرة نفسها للمشتري. ويمكن استخدامها لمقارنة Clinic Tek بأي منتج آخر، وهو اختبار أكثر عدلاً من الاعتماد على هذه الدراسة.
التشغيل جزء من المنتج
الإطلاق يحتاج تهيئة أدوار وخدمات وبيانات، وتدريباً حسب الدور، وخطة تحويل ورجوع. وبعده تحتاج الطوابير والتكاملات والنسخ والشهادات إلى مراقبة. تحدد الاتفاقية ما يديره المزود وما تديره العيادة، وكيف يُبلغ العطل ويُصعّد.
التصدير وخطة الخروج جزء من العلاقة. يجب أن تعرف العيادة الصيغة والمرفقات والمدة والاحتفاظ والحذف. النسخة الاحتياطية لاستعادة المنصة لا تغني عن بيانات قابلة للاستخدام.
ما تعلمناه من حدود المنتج
أهم درس أن الاتساع السريع ليس تقدماً دائماً. المسار القصير الواضح والصلاحية الصحيحة وحالة قابلة للتفسير أهم من إضافة وحدة لا يكتمل تشغيلها. كما أن الإعداد المرن مفيد، لكنه يجب ألا يسمح بتكوين يكسر ثابتاً أو يعقد الدعم بلا نهاية.
الدرس الآخر أن المنتج القطاعي يحتاج لغة المجال، لكنه لا يدعي اتخاذ القرار المهني. التقنية تنظم وتحمي وتعرض؛ الإنسان المؤهل يقرر.
الخلاصة: شاهد المنتج واختبر الادعاء
Clinic Tek مثال يمكن فحصه على طريقة برمج تك في تحويل سير العمل إلى منتج عربي متعدد المستأجرين، وليس دليلاً منشوراً على نتائج كل عيادة. راجع صفحة Clinic Tek للقدرات والنطاق، ثم احجز عرضاً تجريبياً من الموعد إلى الفاتورة واطلب رؤية الصلاحيات وحالات الفشل والتصدير، لا الحالة المثالية وحدها.
