بناء تطبيق للصحة الرقمية في عام 2026 لم يعد يشبه ما كان يعرفه مهندسو البنية التحتية قبل خمس سنوات. التكاليف المتغيرة للبنية، ومتطلبات الامتثال الاوروبية والعربية، والحاجة الى time-to-market سريع، والعمل عبر اكثر من ولاية قضائية - كلها تجعل قرارات التصميم حاسمة منذ الشهر الاول. في DossiMed اعتمدنا بنية serverless كاملة تقوم على ثلاث ركائز تقنية. هذا المقال يشرح هذه الخيارات واثرها العملي دون الدخول في تفاصيل التهيئة الداخلية.

لماذا serverless في الصحة الرقمية

الحجة الاوضح لـ serverless هي الجانب المالي: تدفع فقط مقابل ما يُستهلك فعليا. بالنسبة لمنصة صحية تشهد ذروة صباحا (تذكير الدواء) وذروة مساء (عرض الملف)، مع نشاط منخفض ليلا، فهذا النموذج يطابق منحنى الاستخدام مباشرة. اما بنية مصممة على حمل الذروة طوال اليوم فهي هدر بنيوي.

لكن السبب الاهم أعمق من ذلك.

النمط serverless يفرض فصلا صارما بين منطق الاعمال الحساس وبين العميل. لا يمكن لمنصة صحية ان تسمح لتطبيق جوال مخترق بالوصول الى secrets او مفاتيح API خارجية او قاعدة البيانات كاملة. مع serverless يصبح هذا الفصل طبيعيا: العميل يستدعي وظائف مستضافة ولا يرى الا النتيجة. السر يبقى في جهة الخادم بحكم التصميم.

الحجة الثالثة هي time-to-market. نشر ميزة جديدة يعني دفع وظيفة stateless صغيرة، لا اعادة هندسة Kubernetes كامل. لشركة صحة ناشئة تحتاج الوصول سريعا الى منتج يعمل قبل ضغط التمويل، هذا فارق حاسم.

الركيزة 1 - قاعدة البيانات كطبقة الامان الاولى

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

خيارنا كان وضع امن الوصول داخل محرك قاعدة البيانات نفسه عبر Row Level Security (RLS) في PostgreSQL. عمليا، كل جدول اعمال تحكمه سياسة تُنفذ تلقائيا مع كل استعلام، على مستوى اعمق من منطق التطبيق. القاعدة بسيطة: المستخدم لا يقرأ ولا يعدل الا الصفوف التي يملكها. القاعدة تطبقها القاعدة نفسها، لا التطبيق.

الاثر العملي كبير. اذا اضاف مطور غدا وظيفة تستعلم البيانات دون التحقق من هوية الطالب، ستمنع قاعدة البيانات الصفوف غير المملوكة له تلقائيا. الامان هنا لا يعتمد على ذاكرة المطور او جودة مراجعة الكود.

لماذا RLS يغير قواعد اللعبة

  • الحماية تبقى فعالة حتى لو انكشفت وظيفة بلا تحقق تفويض
  • المطور الجديد يرث ضوابط SQL واضحة بدل قواعد تطبيقية هشة
  • النمط يصمد مع تبدل الفرق وامام تدقيقات الامن
  • متاح اصلا في PostgreSQL منذ 9.5 لكنه ما زال غير مستغل بما يكفي في الصحة

الركيزة 2 - وظائف Edge كطبقة للمنطق الحساس

كل منطق يحتاج secrets يعيش في وظائف edge serverless مكتوبة بـ TypeScript. لا مفتاح واحد يصل الى جهاز المستخدم. عميل الجوال يرى فقط نقاط HTTP تتطلب JWT صالحا.

وظائف edge تغطي كامل المنطق الحساس:

  • OCR واستخراج منظم للوثائق الطبية
  • توليد خطة العلاج
  • ارسال التذكيرات عبر الاشعارات
  • التصعيد الى قنوات المحادثة (WhatsApp والصوت)
  • التحقق من webhooks الخارجية والتوقيعات المشفرة
  • ادارة مشتريات in-app
  • حذف الحساب كاملا (حق المحو وفق GDPR)
  • توليد روابط مشاركة للطبيب بتوكن مؤقت

هذا الفصل ينتج فائدتين كبيرتين. اولا، تدوير المفاتيح يصبح بسيطا: عند تغيير مفتاح API من مزود خارجي نحدّث متغير بيئة في edge runtime فقط، دون تحديث عميل او نشر جديد على المتاجر.

ثانيا، التدقيق الامني يصبح مركزا. سطح المخاطر الحساس صغير وقابل للتتبع ومعزول. المدقق او المشتري يمكنه مراجعة functions/ بدلا من الغوص في عشرات الالاف من اسطر Flutter والويب.

الركيزة 3 - تخزين خاص بوصول مقيّد تشفيريا

صور الوثائق الطبية والمرفقات تُحفظ في buckets خاصة بدون اي روابط عامة. الوصول يتم فقط عبر signed URLs قصيرة العمر مولدة من جهة الخادم عند الطلب.

كما ان نمط المسارات مصمم لمنع التسرب الجانبي: كل مورد يبدأ بمعرف المالك. ومع سياسات التخزين، يضمن هذا ان المستخدم لا يقرأ ولا يكتب الا ضمن نطاقه الخاص.

اما الطبيب الذي يصل الى ملف مشترك فالمسار مختلف: يفتح رابطا يحوي token مؤقتا. الخادم يتحقق من hash الخاص بالتوكن، ويطبق قيود المريض (الفئات، الفترة، الاختصاص)، ثم ينشئ signed URLs مؤقتة ويعرض الصفحة. لا تظهر للطبيب روابط دائمة للملفات.

معمارية DossiMed المفاهيمية: اربعة نطاقات وظيفية حول حساب المستخدم

الاستضافة ضمن ولاية قضائية مناسبة

الخادم الرئيسي لـ DossiMed مستضاف في سويسرا (منطقة وسط اوروبا). هذا القرار يغطي عدة متطلبات في وقت واحد.

قرار الملاءمة الاوروبي. سويسرا تتمتع بقرار ملاءمة من المفوضية الاوروبية وفق المادة 45 من GDPR. نقل البيانات من الاتحاد الى سويسرا لا يحتاج اليات تعاقدية اضافية، بخلاف كثير من مناطق الولايات المتحدة بعد Schrems II.

التوافق مع nFADP. القانون السويسري المحدث لحماية البيانات متوافق بدرجة كبيرة مع GDPR، ما يجعل منصة ملتزمة بـ GDPR قريبة جدا من متطلبات nFADP.

موضع جغرافي مناسب لـ MENA + اوروبا. زمن الاستجابة من زيورخ نحو فرنسا وبلجيكا والمانيا وايطاليا وشمال افريقيا والشرق الاوسط ممتاز، ما يجعله نقطة عملية للتوسع متعدد اللغات.

هذه المعمارية مصممة لتكون قابلة للنقل. وظائف edge تعمل على Deno القياسي، وقاعدة البيانات PostgreSQL، والتخزين متوافق مع S3. الانتقال الى منطقة او مزود آخر يتطلب ساعات اعداد وايام اختبار، لا اعادة كتابة كاملة.

خط المعالجة غير المتزامن

OCR مع الاستخراج المنظم للوثائق الطبية يستغرق عادة من ثوانٍ الى دقيقة. ابقاء المستخدم على شاشة مجمدة خلال ذلك غير مقبول.

النمط لدينا يعمل بثلاث مراحل:

  1. تطبيق الجوال يرفع الصورة ويكتب سجلا بحالة pending
  2. يشترك في Realtime لمتابعة تغيرات هذا السجل
  3. وظيفة edge تعمل بالخلفية وتكتب النتيجة المنظمة وتحوّل الحالة الى processed - فيستقبل العميل الحدث ويحدّث العرض فورًا

هذا النمط البسيط مع PostgreSQL وRealtime يعطي احساسا بالاستجابة الفورية رغم ان المعالجة غير متزامنة، ويجنب long polling وwebsockets المخصصة وتعقيد الحالة الموزعة.

تعدد اللغات كقرار بنيوي

كثير من تطبيقات الصحة تتعامل مع تعدد اللغات كترجمة واجهة فقط. هذا غير كافٍ في اسواق اوروبا وMENA حيث اللغة عنصر ثقة اساسي.

DossiMed يعامل التعدد اللغوي كـ معامل معماري. الرسائل الصادرة - اشعارات الدفع، رسائل WhatsApp، وسيناريوهات الاتصال الصوتي - تُوطن في المحرك لا في التطبيق. لغة المستخدم المفضلة محفوظة في قاعدة البيانات وتستهلكها وظائف edge لاختيار القالب وصوت النطق واتجاه الكتابة. نماذج Document AI تتعامل مع العربية والفرنسية والانجليزية ومتغيراتها.

النتيجة: مستخدم ناطق بالعربية يتلقى تنبيها صوتيا بلغته الام عبر نظام صُمم متعدد اللغات من البداية، لا مترجما لاحقا.

الامتثال بالتصميم

تشريعات بيانات الصحة الاوروبية تفرض حقوقا والتزامات كثيرة تنفذها فرق عديدة متاخرا. تنفيذها مبكرا اثناء التصميم اقل كلفة بكثير.

انضباط الامتثال لدينا يعتمد قواعد بسيطة:

  • كل جدول اعمال يتضمن عناصر تتبع اساسية (معرف المستخدم وتواريخ الانشاء والتحديث)
  • حذف المستخدم يطلق cascade كاملة على الجداول التابعة
  • buckets التخزين تتبع نفس مبدأ الملكية حسب المستخدم
  • تصدير بيانات المستخدم يتم عبر JSON لكل جدول مع قائمة ملفاته

هذا الانضباط لم يكن ردة فعل على تدقيق، بل مبدأ تصميم من اليوم الاول - وربما من اعلى قرارات العائد على الاستثمار في المشروع.

ماذا تعني المعمارية الناضجة للمشتري التقني

لفرق تقنية تقيّم منصة صحية بهدف التكامل او الاستحواذ، هناك مؤشرات اهم من عروض الواجهة:

  • جودة واتساق ترحيلات SQL
  • تغطية كاملة لـ RLS على جداول الاعمال
  • فصل صارم بين العميل والخادم دون كشف secrets
  • قابلية نقل الكود الى اي منطقة مستهدفة
  • غياب انماط ديون تقنية متراكمة

هذه العناصر تكشف فريقا بنى بانضباط هندسي.

معمارية serverless متعددة اللغات ومتوافقة مع GDPR ومستضافة في ولاية مناسبة وقابلة للنشر خلال ساعات في اي منطقة مستهدفة ليست طرحا نظريا. انها وعد بحرية تشغيلية لمن يرثها.


DossiMed تصدرها REC، وهي شركة تونسية موجهة بالكامل للتصدير. المنصة مستضافة ضمن ولايات قضائية تُعد ملائمة وفق المادة 45 من GDPR. للاستفسارات التجارية او الشراكات الاستراتيجية: contact@dossimed.ai.