الأمان والهوية في تطبيقات الصحة: الخريطة

إجابة مختصرة: الأمان في تطبيق صحي يجيب على أربعة أسئلة، بالترتيب. من هذا؟ الهوية: مستخدم تم التحقق منه (مريض، طبيب، نظام) عبر OpenID Connect، وللأطباء، الهوية المهنية الوطنية؛ مستوى التحقق أهم من قوة كلمة المرور. ماذا يمكنهم أن يفعلوا؟ التفويض: رموز OAuth 2.0 (تتجه إلى 2.1) مع نطاقات (scopes) بصيغة SMART on FHIR، مشتقة من موافقة المريض لغرض ومدة محددة، يتم فرضها على مستوى البيانات. ماذا فعلوا؟ المساءلة: سجل وصول يمكن للمريض قراءته ومسار FHIR AuditEvent للمؤسسة. هل البيانات آمنة أثناء التخزين، النقل، والنسخ الاحتياطي؟ الحماية: التشفير، إدارة المفاتيح، الفصل، استعادة تم اختبارها. حولها: خط الأساس لـ ISO 27001 و 27799، و NIS2 وقاعدة الأمان في HIPAA، والتهديدات المحددة للبيانات الصحية (التصفح الداخلي، سوء التصنيف، برامج الفدية).

الخريطة

تتكون طبقات الأمان والهوية في تطبيق صحي من سبع طبقات: الهوية عبر OpenID Connect والهويات الوطنية أو المهنية، التفويض عبر OAuth 2.0 ونطاقات SMART on FHIR، الموافقة كمصدر لكل منح، المساءلة عبر سجلات الوصول وحدث تدقيق FHIR (AuditEvent)، الحماية عبر التشفير والنسخ الاحتياطي، خط أساس من ISO 27001 و ISO 27799 و NIS2 و HIPAA، والمشاركة التي يبدأها المريض.

الطبقة	المعيار أو الممارسة	ما تقدمه لك	الصفحة
الهوية	OpenID Connect؛ الهويات الوطنية (eIDAS، NHS login، GesundheitsID)؛ الهويات المهنية (eHBA، CPS، UZI)	موضوع تم التحقق منه بمستوى ضمان	شرح SMART App Launch
التفويض	OAuth 2.0 و 2.1 (PKCE إلزامي، لا توجد منح ضمنية أو بالكلمة المرور)؛ نطاقات SMART on FHIR (patient/Observation.rs)؛ خدمات خلفية مع مصادقة عميل غير متماثلة	رموز مرتبطة بمستخدم، وسياق مريض، ونطاق	شرح SMART App Launch، خدمة SMART on FHIR الخلفية
الموافقة	FHIR Consent؛ منح مرتبطة بالغرض والوقت؛ الإلغاء؛ "كسر الزجاج" مع تبرير وتنبيه	المريض كمصدر لكل تفويض	منصة موافقة المريض، طلبات وصول العيادة
المساءلة	سجلات وصول لكل سجل مرئية للمريض؛ FHIR AuditEvent؛ تخزين مقاوم للتلاعب؛ الاحتفاظ	من رأى ماذا، متى، لماذا	من شاهد سجلي الطبي؟
الحماية	TLS 1.2+، تشفير أثناء التخزين بمفاتيح مُدارة، تشفير على مستوى الحقل للمعرفات، بيئات مفصولة، نسخ احتياطي مع استعادة تم اختبارها	السرية والتوافر	ISO 27001 مقابل ISO 27799
خط الأساس	نظام إدارة أمن المعلومات ISO 27001، ضوابط صحية ISO 27799، تدابير NIS2، قاعدة الأمان HIPAA، مخططات وطنية (HDS، DSPT، C5)	ما تتوقعه المستشفيات والمراجعون والجهات التنظيمية	NIS2 للمستشفيات والبائعين، HIPAA مقابل GDPR
المشاركة	SMART Health Links و Cards؛ بيانات اعتماد قابلة للتحقق	مشاركة يبدأها المريض برابط أو رمز QR، قابلة للإلغاء	شرح SMART Health Links

الهوية: ضمان أعلى من كلمات المرور

تعتمد الهوية في التطبيق الصحي على مستوى التأكيد بدلاً من قوة كلمة المرور: مستويات تأكيد الهوية مثل NIST IAL، و eIDAS substantial و high، أو NHS login P9 تصف مدى قوة التحقق من هوية الشخص عند التسجيل، بينما تصف المصادقة متعددة العوامل (multi-factor authentication) وكلمات المرور (passkeys) كل عملية تسجيل دخول. يتم تحديد هوية الأطباء من خلال هويات مهنية يتم إلغاؤها عند مغادرتهم.

يجب أن يعرف تطبيق المريض الذي يعرض سجلاً كاملاً أنه يتحدث مع هذا المريض. مستويات ضمان الهوية (IAL من NIST، substantial و high من eIDAS، P9 من NHS login) تصف مدى قوة التحقق من الهوية عند التسجيل؛ قوة المصادقة (متعددة العوامل، passkeys) تصف كل تسجيل دخول. تتطلب المستشفيات والأنظمة الوطنية بشكل متزايد هويات تم التحقق منها من مخططات معترف بها بدلاً من التسجيلات الذاتية، وسيصبح محفظة الهوية الرقمية للاتحاد الأوروبي وسيلة مقبولة. بالنسبة للأطباء، الهوية المهنية (وإلغاؤها عند مغادرة شخص ما) هي نظام السجلات لمن يمكنه العمل كطبيب على الإطلاق.

التفويض: الموافقة تتحول إلى نطاقات

يترجم التفويض في سجل يتحكم فيه المريض موافقة المريض، مثل السماح للعيادة بقراءة نتائج المختبر والحالات لمدة 90 يومًا، إلى نطاقات OAuth وسياق المريض في الرمز (token)، بصيغة SMART on FHIR مثل patient/Observation.rs، ويتم فرضه على مستوى البيانات في كل طلب ويتم إلغاؤه عندما يسحب المريض موافقته. يعتبر "كسر الزجاج" (Break-the-glass) مسارًا منفصلاً ومدققًا.

في سجل يتحكم فيه المريض، موافقة المريض هي السياسة: يمكن لهذه العيادة قراءة نتائج مختبري وحالتي لمدة 90 يومًا. يترجم النظام ذلك إلى نطاقات OAuth و سياق (أي مريض، أي موارد، أي عمليات) على الرمز الذي يتلقاه نظام العيادة، ويفرضها على كل طلب على مستوى البيانات، ويلغيها عندما يسحب المريض موافقته. صيغة نطاق SMART on FHIR (patient/Observation.rs، patient/Condition.rs) هي اللغة المشتركة لهذا؛ توجد نطاقات دقيقة (حسب الفئة أو الرمز) في SMART v2 لمزيد من التحكم الدقيق. "كسر الزجاج" (الوصول الطارئ بدون موافقة) هو مسار منفصل، يتم تدقيقه، مع تبرير إلزامي وتنبيه للمريض، وليس افتراضيًا أبدًا. انظر منصة موافقة المريض.

المساءلة: السجل الذي يقرأه المريض

تعني المساءلة في التطبيق الصحي أن كل وصول إلى سجل، ومن قبل من، ومتى، وماذا، وتحت أي موافقة، يتم تسجيله في سجل غير قابل للحذف يمكن للمريض قراءته في تطبيقه وفي مسار تدقيق تنظيمي في حدث تدقيق FHIR (AuditEvent). تعامل ISO 27799 هذا كإلزامي، والسجل المرئي هو أقوى رادع للتصفح الداخلي.

كل وصول إلى سجل، من قبل من، متى، ماذا، تحت أي موافقة، مكتوب إلى سجل قابل للإلحاق فقط يمكن للمريض قراءته في تطبيقه، وإلى مسار تدقيق تنظيمي (FHIR AuditEvent) لفرق الأمان. تعامل ISO 27799 هذا كأمر إلزامي للمعلومات الصحية؛ مبدأ الشفافية في GDPR وحقوق المريض في EHDS تشير إلى نفس الاتجاه؛ أقوى رادع في العالم الواقعي للتصفح الداخلي هو سجل مرئي. انظر من شاهد سجلي الطبي؟.

الحماية: خط الأساس الهندسي

خط الأساس الهندسي لحماية البيانات الصحية هو TLS في كل مكان، والتشفير أثناء التخزين (encryption at rest) باستخدام مفاتيح مُدارة ومُتناوبة، وتشفير منفصل أو ترميز (tokenisation) للمعرفات المباشرة، وبيئات معزولة ببيانات اصطناعية خارج بيئة الإنتاج، والوصول بأقل الامتيازات (least-privilege access) مع المصادقة متعددة العوامل للمسؤولين، وإدارة الأسرار والثغرات الأمنية، ونسخ احتياطي مشفر يتم اختباره بالاستعادة ضد برامج الفدية (ransomware)، والاستجابة للحوادث ضمن إطار زمني GDPR و NIS2.

TLS في كل مكان، مع تشفير حديث وتثبيت شهادات في التطبيقات عند الاقتضاء؛ تشفير أثناء التخزين بمفاتيح في خدمة مفاتيح مُدارة وتدويرها؛ تشفير منفصل أو ترميز للمعرفات المباشرة؛ فصل بيئات الإنتاج عن بيئات التطوير، مع بيانات اصطناعية خارج بيئة الإنتاج؛ وصول بأقل الامتيازات للموظفين، لا توجد حسابات مشتركة، مصادقة متعددة العوامل لجميع الوصول الإداري؛ إدارة الأسرار؛ إدارة التبعيات والثغرات مع الإفصاح؛ نسخ احتياطي مشفر، تم اختباره بالاستعادة، ومحمي ضد برامج الفدية التي ضربت المستشفيات والمختبرات بشكل متكرر (WannaCry في 2017، مستشفى دوسلدورف في 2020، Change Healthcare و Synnovis في 2024). الاستجابة للحوادث مع ساعات GDPR 72 ساعة و NIS2 24 ساعة في خطة تشغيل واحدة.

تهديدات خاصة بالبيانات الصحية

التهديدات الخاصة بالبيانات الصحية هي التصفح الداخلي لسجلات المعارف، وسوء التصنيف بين المرضى، والمشاركة الواسعة جدًا الممنوحة لفترة طويلة جدًا، وحزم تطوير البرامج الإعلانية (advertising SDKs) داخل التطبيقات التي تتعامل مع البيانات الصحية، وحقن البيانات عبر المستندات في ميزات الذكاء الاصطناعي، والاحتفاظ الطويل لعقود حيث يجب أن تتجاوز المفاتيح والتنسيقات وقواعد الوصول عمر الموظفين والبائعين.

التصفح الداخلي لسجلات المعارف أو الشخصيات العامة: وصول قائم على العلاقات وسجلات مرئية.
سوء التصنيف بين المرضى: مطابقة الهوية والأصل، وليس فقط التحكم في الوصول.
المشاركة الواسعة جدًا: عيادة مُنحت "كل شيء" لمدة عام؛ نطاقات ومدد مع افتراضيات معقولة.
تطبيقات تحتوي على حزم تطوير إعلانية: لا توجد أدوات تتبع خارجية في أي شيء يتعامل مع البيانات الصحية.
حقن المستندات في ميزات الذكاء الاصطناعي: المحتوى هو بيانات، وليس تعليمات (RAG على السجلات الطبية).
الاحتفاظ الطويل: تعيش السجلات لعقود؛ يجب أن تصمد المفاتيح والتنسيقات وقواعد الوصول أمام الموظفين والبائعين.

في Anpheros

يطبق Anpheros خريطة الأمان على نفسه باستخدام OAuth 2.0 مع PKCE للتطبيقات والمصادقة غير المتماثلة للعملاء (asymmetric client authentication) للواجهات الخلفية (backends)، والموافقة حسب الغرض والمدة كمصدر لوصول كل عيادة، وسجل وصول لكل سجل في تطبيق الشخص، والتشفير أثناء التخزين وأثناء النقل (encryption in transit)، والاستضافة في الاتحاد الأوروبي، وعدم وجود حزم تطوير برامج إعلانية (advertising SDKs)، ونظام إدارة أمن المعلومات (ISMS) وفقًا لمعايير ISO 27001 و 27799.

تطبق Anpheros هذه الخريطة على نفسها: OAuth 2.0 مع PKCE للتطبيقات ومصادقة عميل غير متماثلة للخدمات الخلفية؛ موافقة لكل غرض ومدة كمصدر لوصول كل عيادة، مع الإلغاء وعدم وجود "كسر زجاج" صامت؛ سجل وصول لكل سجل في تطبيق الشخص؛ تشفير أثناء التخزين والنقل، استضافة في الاتحاد الأوروبي، لا توجد حزم تطوير إعلانية؛ نظام إدارة أمن معلومات وفقًا لـ ISO 27001 مع ضوابط صحية ISO 27799. يوثق موقع المطورين المصادقة، الموافقة و الأمان.

صفحات ذات صلة

مصادر

الأسئلة الشائعة

هل OAuth 2.1 مختلف عن 2.0؟

يوحد OAuth 2.1 معايير 2.0 مع أفضل ممارسات الأمان الخاصة به: PKCE مطلوب لجميع العملاء، تم إزالة المنح الضمنية ومنح كلمة المرور، يجب أن تتطابق عناوين URI لإعادة التوجيه تمامًا، ويجب ربط رموز التحديث للعملاء العامين أو تدويرها. يتطلب SMART on FHIR v2 بالفعل معظم هذا.

ما هو "كسر الزجاج"؟

الوصول الطارئ إلى سجل دون موافقة مسبقة من المريض، من قبل طبيب يؤكد تبريرًا. يجب أن يكون نادرًا، وأن يتم تسجيله، ومراجعته، والإبلاغ عنه للمريض؛ وهو ليس مسار الوصول الافتراضي أبدًا.

لماذا يجب على المرضى رؤية سجل الوصول؟

لأنه أقوى رادع للوصول غير المناسب وأوضح تعبير عن التحكم: يرى الشخص أي عيادة قرأت ماذا ومتى، ويمكنه الإلغاء. تشير ISO 27799 و EHDS إلى نفس الاتجاه.

هل أحتاج إلى نظام تدقيق منفصل؟

تحتاج إلى مسار تدقيق قابل للإلحاق فقط (FHIR AuditEvent أو ما يعادله) لا يمكن للتطبيق تعديله، ويتم الاحتفاظ به وفقًا للسياسة، وعرض مرئي للمريض مشتق منه. سواء كان نظامًا منفصلاً أو مخزنًا محميًا داخل المنصة هو خيار تنفيذي.

Anpheros Platform

جرّبه مجانًا في بيئة الاختبار

أول طلب FHIR خلال 5 دقائق. واجهة برمجة تطبيقات HL7 FHIR R4 مع موافقة المريض مدمجة: جربها في بيئة الاختبار، ثم اربط تطبيقك الخاص أو نظام عيادتك.

أنشئ بيئة اختبار مجانية اقرأ أدلة المطورين →

مجاني · 30 مريضًا اصطناعيًا · دون بطاقة

هذا الدليل هو للمعلومات فقط ولا يغني عن الاستشارة الطبية. لاتخاذ قرارات بشأن صحتك، تحدث مع طبيبك. في حالة الطوارئ، اتصل برقم الطوارئ المحلي (112 في أوروبا).

بقلم

فريق Anpheros

تبني Anpheros سجلًا طبيًا يتحكم فيه المريض ويمكن مشاركته مع أي عيادة، على منصة HL7 FHIR R4، مقرها في الاتحاد الأوروبي. تساعدك هذه الأدلة على فهم وتنظيم صحتك؛ ولا تغني عن استشارة طبيبك.

عن Anpheros →