# واجهة برمجة تطبيقات الرعاية الصحية بموافقة المريض

> كيف يتم منح الوصول إلى سجل بواسطة المريض من خلال نطاقات ومدد OAuth 2.1، وتسجيله وإلغائه، وما يغيره في تصميم التطبيق، وكيف تبقي المعرفات المزدوجة التطبيقات منفصلة.

Source: https://developers.anpheros.com/ar/guides/healthcare-api-patient-consent

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

## طريقتان للوصول إلى سجل

| | وصول المؤسسة | وصول يمنحه المريض |
|---|---|---|
| من يصرح | مؤسستك، عبر مفتاح API | المريض، عبر شاشة موافقة OAuth 2.1 |
| الاستخدام النموذجي | عيادة أو مختبر يكتب النتائج، تطبيقك الخاص يكتب نيابة عن مستخدميه | تطبيق طرف ثالث، مساعد ذكاء اصطناعي، أداة طبيب، فرد من العائلة |
| النطاق | المرضى الذين أنشأتهم مؤسستك أو الذين تمت مشاركتهم معها | النطاقات التي وافق عليها المريض (`patient/Observation.read`، …) |
| المدة | طالما المفتاح صالح | المدة التي اختارها المريض؛ قابلة للتجديد، قابلة للإلغاء |
| مرئي للمريض | نعم، في سجل الوصول | نعم، مع إمكانية السحب |

كلا المسارين يمران عبر نفس الـ API ونفس سجل FHIR. الفرق هو من يملك مفتاح الباب.

## تدفق الموافقة، خطوة بخطوة

1. يرسل تطبيقك المريض إلى نقطة نهاية تفويض Anpheros مع النطاقات (scopes) التي يحتاجها وسبب بلغة واضحة.
2. يرى المريض ما تطلبه، ويختار مدة زمنية، ويقبل أو يرفض. الشاشة تكون بلغة المريض.
3. تتلقى رمز وصول (access token) مقيدًا بتلك النطاقات وهذا المريض. الرموز قصيرة الأجل؛ رموز التحديث (refresh tokens) تدوم طالما استمرت الموافقة.
4. يتم تسجيل كل قراءة وكتابة بهذا الرمز باسم تطبيقك. يرى المريض السجل في تطبيقه.
5. إذا سحب المريض موافقته، يفشل الطلب التالي بخطأ واضح. تتلقى خطاف ويب (webhook) حتى تتمكن من التنظيف.

التدفق هو معيار OAuth 2.1 مع PKCE ونطاقات SMART on FHIR، لذا تعمل المكتبات الحالية. دليل [المصادقة و OAuth](https://developers.anpheros.com/ar/guides/authentication) يحتوي على المعلمات الدقيقة، ودليل [نموذج الموافقة والوصول](https://developers.anpheros.com/ar/guides/consent) يحتوي على القواعد الكامنة وراءه.

## ما الذي يتغير في تطبيقك

- **تطلب أقل.** النطاقات (Scopes) تكون لكل نوع مورد ولكل اتجاه. التطبيق الذي يرسم الوزن يطلب `Observation.read`، وليس السجل بأكمله.
- **تصمم للسحب (Withdrawal).** يمكن أن ينتهي الوصول في أي وقت. قم بالتخزين المؤقت للقليل، وأعد القراءة عند الحاجة، وتعامل مع خطأ الإلغاء (revoked) كحالة طبيعية.
- **تكسب الثقة مجانًا.** يرى المرضى اسم تطبيقك، وما يمكنه الوصول إليه، ومتى قرأ شيئًا آخر مرة. التطبيقات التي تتصرف بشكل جيد يسهل قبولها.
- **تكتب مع إثبات المصدر (Provenance).** كل ما تكتبه يحمل اسم تطبيقك كمؤلف، وعند الاقتضاء، الشخص الذي تم باسمه. يمكن للمريض والتطبيقات الأخرى تمييز بياناتك عن بياناتهم.

## معرفات لا تُسرب معلومات

ترى كل تطبيق مريضًا بمعرف فريد خاص به: نفس الشخص لديه معرف مختلف في تطبيقك ومعرف آخر في تطبيق آخر. لا يمكن لتطبيقين ربط بياناتهما عن شخص ما دون موافقة المريض، حتى لو كان كلاهما مبنيًا على Anpheros. بالنسبة لكودك، هذا غير مرئي؛ بالنسبة للمريض، هذا هو الفرق بين الموافقة والإجراء شكلي.

## العائلات ومقدمو الرعاية

يمتد نطاق الموافقة ليشمل الأشخاص الذين يديرون السجلات للآخرين: الوالد لطفل، أو الابن البالغ لوالده المسن. يبقى السجل مع الحساب الذي أنشأه؛ وتتلقى الحسابات الأخرى إمكانية الوصول، والتي يمكن سحبها. يرى تطبيقك نفس آلية الموافقة، حيث يكون مقدم الرعاية هو الشخص الذي يقبل.

## ذات الصلة

- [نموذج الموافقة والوصول](https://developers.anpheros.com/ar/guides/consent)
- [المصادقة و OAuth](https://developers.anpheros.com/ar/guides/authentication)
- [الواجهة الخلفية لـ SMART on FHIR](https://developers.anpheros.com/ar/guides/smart-on-fhir-backend)
- [واجهة برمجة تطبيقات الرعاية الصحية](https://developers.anpheros.com/ar/guides/healthcare-api)
- [الأمان والخصوصية ومكان البيانات](https://developers.anpheros.com/ar/guides/security)