ينقر المريض على زر يحمل تسمية "قطع اتصال بياناتي". يظهر تطبيق الويب علامة صح خضراء وتأكيداً مبهجاً. وفي مكان ما في طابور خلفي، تستيقظ عملية عامل (worker process) من أجل مزامنتها الليلية، وتسحب مهمة أُنشئت بالأمس، وتبدأ في بث تاريخ الأدوية لمدة عامين إلى عنقود تحليلات لاحق. لقد وثق المستخدم في الواجهة، لكن النظام خان تلك الثقة.
يطارد نمط الفشل هذا بنية بيانات الصحة لأن المخاطر عالية جداً. فالإذن القديم ليس مجرد خطأ بسيط؛ بل هو خرق نشط. الحل هو ربط كل طلب بيانات بـ "إيصال موافقة": سجل صغير ومنظم يحمل نية المستخدم من واجهة المستخدم وصولاً إلى محرك السياسات الخاص بك، ومعاملات قاعدة البيانات، وكل عامل خلفي. هذا الإيصال لا يخزن أبداً القيم السريرية، بل يخزن فقط الحق في الوصول إليها، مختوماً بإصدار لا يمكن تغييره بهدوء خلف الكواليس.
ما الذي يحمله الإيصال فعلياً
فكر في الإيصال كعقد محدد النطاق، وليس كمجرد علامة جلسة (session flag). فهو يحتوي على معرف المنح، وصاحب البيانات، والنطاق الدقيق للوصول (نتائج المختبر، العلامات الحيوية، تاريخ الأدوية)، ونافذة صلاحية مرتبطة بزمن، ورقم إصدار. عندما تطلب الواجهة الأمامية الوصول نيابة عن مستخدم، تصدر واجهة برمجة التطبيقات (API) هذا الإيصال. تحتفظ الواجهة الأمامية به، ويجب على كل خدمة تابعة تريد قراءة البيانات الصحية تقديم الإيصال إلى طبقة سياسات مركزية وتلقي موافقة صريحة قبل فتح السجل.
هذا الأمر مهم لأن الأنظمة الصحية غالباً ما تخلط بين رمز حساب المستخدم (user account token) وبين الموافقة. الرمز يخبرنا من أنت، أما الإيصال فيخبرنا بما يُسمح لك بفعله الآن. وإذا حدث تباعد بينهما، يجب أن تكون الغلبة دائماً للإيصال.
إصدار كل شيء
قم ببناء مخزن الموافقة الخاص بك كسجل للإضافة فقط (append-only log). عندما يمنح المستخدم الوصول لأول مرة إلى سجلات التطعيم الخاصة به، يكون هذا هو الإصدار الأول. إذا قام لاحقاً بتضييق النطاق لاستبعاد مقدمي خدمات محددين، أو إذا ألغى الوصول تماماً، فلا تقم بالكتابة فوق الإدخال الأول، بل اكتب الإصدار الثاني. سيظل الإيصال الذي في يد العامل يشير إلى الإصدار الأول، ويمكن لمحرك السياسات أن يرى بالضبط ما سمح به الإصدار الأول وأن هذا الإصدار قد تم استبداله في طابع زمني محدد.
هذه الخاصية (عدم القابلية للتغيير) هي العمود الفقري لعمليات التدقيق لديك. بعد ستة أشهر، عندما يسأل مسؤول الامتثال عن سبب تشغيل مهمة ETL معينة في بعد ظهر يوم خميس، يمكنك تتبع إصدار المنح الدقيق الذي حملته المهمة وإثبات أنه كان صالحاً عند بدء المهمة. إذا قمت بتخزين الموافقة كعلامة منطقية (boolean flag) واحدة في ملف تعريف المستخدم، فإنك تمحو ذلك التاريخ، وتفقد القدرة على التمييز بين "لم يُسمح بهذا أبداً" وبين "كان مسموحاً به عندما بدأت المهمة ولكن المستخدم غير رأيه بعد ساعتين".
صمم نقاط النهاية (Endpoints) بصدق
يجب أن توفر واجهة برمجة تطبيقات الموافقة (Consent API) مسارات واضحة ومحددة. اجعل POST /grants ينشئ إذناً جديداً. واجعل GET /grants/{id} يعيد الحالة الحالية لإيصال معين. واجعل POST /grants/{id}/revoke يبدأ عملية الإلغاء. لا تتظاهر بأن النقر على "إلغاء" يمسح فوراً كل نسخة من البيانات الصحية العائمة في خطوط المعالجة (pipelines) لديك. بدلاً من ذلك، أعد معرف عملية الإلغاء مع حالة 202 Accepted. هذا يخبر المستخدم أن الطلب حقيقي، وأنه قيد التنفيذ، ويمكنه تتبعه.
يصبح معرف العملية هذا حاسماً عندما ينقر المستخدم نقراً مزدوجاً لأن الواجهة بدت بطيئة. إذا قدم طلباً ثانياً للإلغاء، فأعد معرف العملية الأصلي. خاصية "عدم التكرار" (Idempotency) هنا ليست مجرد ميزة إضافية؛ بل هي تمنع حدوث حالة ذعر مكررة وتمنح المستخدم مصدراً واحداً للحقيقة بشأن حالة طلبه.
اطلب الإذن في آخر لحظة ممكنة
من الأخطاء الشائعة التحقق من الموافقة عند بوابة واجهة برمجة التطبيقات (API gateway) ثم الوثوق بعلامة مخزنة مؤقتاً (cached flag) في أعماق العامل. لا تفعل ذلك. يجب أن يحمل العامل الإيصال الخاص به طوال دورة حياة المهمة. وقبل تنفيذ الاستعلام مباشرة ضد مخزن السجلات الصحية، يجب عليه أن يسأل طبقة السياسات: "هل الإصدار الثالث من هذا المنح المحدد لا يزال صالحاً لهذا النطاق بالضبط؟". إذا كانت الإجابة لا، يتوقف العامل، وتفشل المهمة، ولا يحاول مجدداً.
منطق إعادة المحاولة (Retry logic) هو بمثابة سمّ هنا. عدم تطابق الإصدار ليس مجرد خلل عابر في الشبكة، بل هو قرار بشري. لقد ألغى المستخدم الموافقة، أو انتهت صلاحية المنح، أو تقلص النطاق. إذا حاولت ثلاث مرات ونجحت في الرابعة بسبب حالة تسابق (race condition)، فقد انتهكت الموافقة للتو. تعامل مع عدم التطابق كفشل ذريع، وقم بإرساله إلى طابور الرسائل الميتة (dead-letter queue) أو لوحة عملياتك، واترك الأمر لبشر للتحقيق فيه.
التعامل مع السيناريوهات المعقدة
الأنظمة الحقيقية لا تسير وفق خطوات منظمة. يترك المستخدمون علامات تبويب المتصفح القديمة مفتوحة. تستغرق عمليات الاستيراد الجماعي عشرين دقيقة. تتغير النطاقات (Scopes) بينما تكون عملية المزامنة في منتصفها. تحتاج واجهة برمجة تطبيقات الموافقة (consent API) الخاصة بك إلى قواعد صريحة لهذه اللحظات.
علامات تبويب المتصفح القديمة. يقوم مستخدم بإلغاء الوصول في علامة تبويب فُتحت حديثًا. تحاول علامة تبويب أقدم، لا تزال تحتفظ بكائن منح (grant object) من تحميل صفحة سابق، إعادة الاتصال. يجب على الواجهة الخلفية (backend) رفض ذلك الإيصال القديم فورًا وفرض مراجعة موافقة جديدة. يجب أن يتعامل المنح الملغى مثل جواز سفر ملغى: لا يعود للحياة لمجرد أن حامله وجد نسخة قديمة في درج.
عمليات الاستيراد قيد التنفيذ. إذا كانت عملية استيراد جماعي قيد التشغيل وقام المستخدم بالإلغاء، فأنت بحاجة إلى حدوث شيئين في آن واحد. أولاً، توقف عن السماح بعمليات الكتابة الجديدة في اللحظة التي يتم فيها رفض الإصدار. ثانياً، أظهر للمستخدم تقدم عملية التنظيف الحقيقية من خلال معرف العملية (operation ID). امنحهم صفحة حالة صادقة: "تم قبول الإلغاء. جاري تطهير ثماني عشرة عملية كتابة معلقة". لا تسمح للعاملين (workers) بتثبيت البيانات باستخدام إصدار منح تم تمييزه بالفعل على أنه غير صالح.
تغييرات النطاق (Scope changes). افترض أن مستخدمًا منح في الأصل حق الوصول إلى تاريخ يمتد لخمس سنوات ثم عدله لاحقًا إلى ستة أشهر. لا تقم بتعديل المنح الأصلي. أغلق الإصدار الأول، وأصدر الإصدار الثاني بالنافذة الزمنية الأضيق، واجبر أي عمليات جارية على التوفيق مع الحدود الجديدة. يظل الإصدار الأقدم في سجلاتك كحقيقة تاريخية، وليس كإذن فعال.
قواعد أمنية صارمة
الإيصالات نفسها حساسة، لكنها ليست بيانات سريرية. حافظ على فصلها في بنيتك البرمجية. يجب أن يكون المريض فقط أو دور مفوض خصيصًا - مثل وصي قانوني أو مقدم رعاية معتمد - قادرًا على عرض الإيصال أو إلغائه. فرض هذا يجب أن يتم في طبقة البيانات، وليس فقط في جدول توجيه واجهة المستخدم (UI routing table).
ستحاول سجلات الأخطاء لديك امتصاص البيانات الصحية عند فشل المهام. حارب هذا الميل بقوة. عندما يتوقف عامل عن العمل لأنه قدم إيصال موافقة غير صالح، قم بتسجيل معرف المنح (grant ID)، والإصدار، والخطأ. لا تقم أبدًا بتسجيل معرف المريض، أو رمز التشخيص، أو قيمة المختبر التي كان العامل يحاول جلبها. البيانات الصحية في السجلات تنتشر مثل العفن: يتم نسخها احتياطيًا، وفهرستها، ونسيانها بطرق تتجاوز ضوابط الوصول العادية لديك.
أخيرًا، لا تقم أبدًا باستعادة منح نشط قديم أثناء استعادة النظام. إذا قمت بالتراجع عن قاعدة بيانات أو استعادة لقطة (snapshot) تحتوي بالصدفة على إصدار من جدول المنح يسبق عملية الإلغاء، فيجب أن يقوم دليل التشغيل (runbook) الخاص بك تلقائيًا بتعطيل تلك الأذونات المستعادة قبل أن تقبل الخدمة أي حركة مرور جديدة. حالات الموافقة التاريخية تنتمي إلى سجل التدقيق (audit log)، وليس إلى مجموعة القواعد النشطة أبدًا.