Skip to main content

​
اتفاقية شراكة الأعمال (BAA)

تحتاج المنظمات التي ترسل أو تخزّن أو تعالج معلومات صحية محمية (PHI) عبر Devotel Orbit إلى اتفاقية شراكة أعمال (BAA) موثَّقة في الملف. تفرض المنصّة وجود مسار BAA قبل أن يمكن تفعيل وضع HIPAA: حين تدخل PHI في النطاق، تحجب بوّابة وقت الإرسال الحركة بـHIPAA_BAA_REQUIRED حتى يُسجَّل BAA منفَّذ. تغطّي هذه الإرشادات دورة الحياة الكاملة: حالات baa_status القانونية، وكيفية تآلف نقاط النهاية الستّ /api/v1/compliance/baa، وأيّ دور يمكنه نداء أيّ نقطة، وما يتغيّر بعد تنفيذ BAA، وكيفية إرجاع اتفاقية منفَّذة إلى الافتراضي المنصّي.
هذا ضابط HIPAA مملوك للمستأجر: تقرّر أنت ما إذا كانت PHI في النطاق، وتنفّذ الاتفاقية عن قصد، وتعيد تنفيذها قبل انقضاء الأجل السنوي. يوفّر Devotel مسار التوقيع الإلكتروني — إخراج القالب، والتقاط التوقيع المكتوب، والإرساء التدقيقي غير القابل للتغيير، وملف PDF المنفَّذ المخزَّن — غير أن القرار القانوني بأن PHI في النطاق قرارك أنت.

​
حالات baa_status

تكون منظّمتك دائمًا في إحدى أربع حالات، تبلغ عنها GET /api/v1/compliance/baa: يحمل الرد أيضًا تفاصيل الموقّع والعدّ التنازلي للانقضاء:
حين تنقلب hipaa_required إلى مفعَّلة بينما الحالة لا تزال not_required، تنقل نقطة القراءة المنظمة إلى pending تلقائيًا، فتُفتَح خطوة التنفيذ دون نداء منفصل.

​
لماذا يبدأ المسار بإقرار

يوجد مسار BAA لأن HIPAA ينطبق على الاستخدام لا على الحسابات. لا تفترض المنصّة أن كل مساحة عمل تعالج PHI — تُقِرّ المنظمة أولًا بأن PHI في النطاق، ما يرفع راية hipaa_required وينقل الحالة إلى pending. ذلك الإقرار هو ما يفتح خطوة التنفيذ؛ ثم يُتمّ التنفيذ الاتفاقية. يغلق هذا الترتيب تبعية دائرية: لا يمكن تفعيل وضع HIPAA دون BAA منفَّذ، لكن لوحة التحكم احتاجت أيضًا طريقة لبدء الـ BAA قبل وجود وضع HIPAA. كلّ من require (PHI في النطاق) وdecline (لا PHI في النطاق) يكتب صفًّا في سلسلة التدقيق compliance.baa.* يسمّي الفاعل، فيكون الإقرار نفسه حدثًا قانونيًّا مسجَّلًا — لا مجرّد تبديل إعداد عابر.

​
مسار نقاط النهاية

تقيم كل المسارات تحت /api/v1/compliance/baa وتشترط جلسة موثَّقة. العمليات الستّ أدناه هي دورة الحياة الكاملة؛ وتقود صفحة Settings → Compliance → BAA في لوحة التحكم هذه النقاط بالضبط.

​
1. اقرأ الحالة الحالية

يمكن لأي owner أو admin القراءة. استخدم هذا أولًا — يخبرك ما إذا كانت المنظمة تحتاج إلى الإقرار أو التنفيذ أو إعادة التنفيذ أو التنزيل.

​
2. عاين القالب

قبل التوقيع، راجع نص الاتفاقية النهائي. تُعيد GET /api/v1/compliance/baa/template القالب مُخرَجًا واسم منظّمتك القانوني معبَّأ مسبقًا. تظهر حقول وقت التنفيذ (الطوابع الزمنية، مرجع الوثيقة) كعلامات مقروءة بدل مواضع خام، وحقول الموقّع فراغات تعبّئها لوحة التحكم حيًّا بينما تكتب.
الرد:

​
3. أقِرّ بأن PHI في النطاق

يقلب هذا hipaa_required = true وينقل منظمة not_required إلى pending. يفتح مسار التنفيذ — ولا يفعّل وضع HIPAA. يُسجَّل reason الاختياري (حتى 500 حرف) في صفّ التدقيق.

​
4. نفّذ بتوقيع إلكتروني بكتابة الاسم

التنفيذ للمالك حصرًا — توقيع click-wrap يُلزم المنظمة، فليس إجراءً من مرتبة المطوّر. يعيد الموقّع كتابة اسمه القانوني في typed_attestation، ويشترط الخادم تطابقه مع signer_name تمامًا؛ يُرفض الخلاف بـ400، ما يحجب أيضًا إرسالات النموذج الفارغة التلقائية.
عند النجاح، الخادم:
  1. يُخرج القالب مع تفاصيل الموقّع وطوابع التنفيذ الزمنية ومرجع وثيقة مولَّد
  2. يخزّن الوثيقة المُخرَجة كالـ PDF المنفَّذ القانوني
  3. يختم المنظمة executed مع الموقّع ونسخة القالب وطابع التنفيذ، ويسجّل الانقضاء (التنفيذ مضافًا إليه الأجل القياسي السنوي)
  4. يكتب قيد compliance.baa.executed في سجل التدقيق مع أسلوب التوقيع (type_the_name) — القيد التدقيقي هو الدليل القانوني للإقرار، والـ PDF المخزَّن هو الوثيقة القانونية
يعيد الرد الحالة الجديدة مضافًا إليها مرجع الوثيقة:
يُحدَّ التنفيذ بمعدّل حفنة من الطلبات في الدقيقة؛ فهو فعل قانوني متعمَّد، لا حلقة مؤتمتة. (للأساس القانوني لـ click-wrap، راجع التوقيعات الصوتية.)

​
5. نزّل النسخة المنفَّذة

حين يكون BAA في الملف، يمكن لأي owner أو admin جلبه لسجلاتك أو لتدقيق عميل أو لمنظّم:
يحمل الرد عنوان تنزيل صالحًا لـ 24 ساعة:
شارك العنوان داخل تلك النافذة أو نزّل الملف بنفسك وأرشفه. إن لم يُنفَّذ أي BAA بعد، تعيد النقطة 404.

​
6. ارجع إلى الافتراضي المنصّي

الرجوع يزيل الاتفاقية الموثَّقة في الملف ويعيد المنظمة إلى not_required. وهو للمالك حصرًا ولا يُنادى إلا على BAA منفَّذ أو منتهٍ — وبعد تعطيل وضع HIPAA فحسب، حتى لا تستطيع مساحة عمل HIPAA نشطة أن تفكّ دليلها الخاص صامتةً.
سوابق التدقيق للـ BAA المنفَّذ والـ PDF المخزَّن محفوظان — الرجوع يزيل الحالة النشطة ولا يمحو الدليل. استخدمه حين تخرج PHI حقًّا من النطاق، أو لإعادة مساحة عمل إلى أساس نظيف؛ واستخدم decline بدلًا منه حين يتغيّر إقرار «لا PHI».

​
Decline: الإقرار بعدم وجود PHI في النطاق

POST /api/v1/compliance/baa/decline (مالك أو إداري، مع reason اختياري) يسجّل أن PHI ليست في النطاق ويرفع بوّابة وقت الإرسال بعد أن كانت المنظمة مشتركة. يمتنع عن لمس BAA موثَّق في الملف — لا تستطيع decline تفكيك اتفاقية منفَّذة؛ فذلك دور revert. ولأن require وdecline تبديلان إقراريّان متماثلان، يستطيع الإداري الذي يخفض استعادة المطلب لاحقًا إن عادت PHI إلى النطاق.

​
الأدوار وسلسلة التدقيق

تقبل نقاط القراءة والمعاينة والتنزيل والإقرار owner أو admin. أما الفعلان اللذان يُلزمان أو يفكّان اتفاقية قانونية — execute وrevert — فهما owner حصرًا. كل كتابة تُلحِق قيد compliance.baa.* بسجل تدقيق المنظمة — compliance.baa.hipaa_required للـ require، وcompliance.baa.declined للـ decline، وcompliance.baa.executed للتنفيذ، وcompliance.baa.reverted للرجوع — حاملًا الفاعل والسبب و(عند التنفيذ) نسخة القالب وأسلوب التوقيع. تلك السلسلة الملحَقة فحسب، لا حقل الحالة الحالي، هي الدليل القانوني للإقرار. ويمكنك تفقّدها من لوحة التحكم ضمن Settings → Audit log.

​
ما يتغيّر بعد تنفيذ BAA

تنفيذ الـ BAA يفعل أمرين:
  1. يرفع بوّابة إرسال PHI. بينما hipaa_required صحيح ولا BAA ضمن الأجل في الملف، تُرفض الإرسالات الصادرة التي تمسّ PHI بـ422 HIPAA_BAA_REQUIRED. يزيل BAA منفَّذ ذلك الرفض. (نتيجة البوّابة وسلوك fail-closed موثَّقان ضمن Send gates.)
  2. يفتح قفل وضع HIPAA. تفعيل وضع HIPAA يشترط baa_status = "executed"؛ تُعيد المحاولة قبل التنفيذ 403. وحين يكون وضع HIPAA مفعّلًا، تنطبق الضوابط الموصوفة في ضوابط امتثال HIPAA — تسجيل وصول PHI، واستبقاء البيانات، وبقيّتها — على مساحة العمل.
ما لا يغيّره: تنفيذ BAA لا يفعّل وضع HIPAA بذاته، ولا يحدّد مشروعية معالجتك، ولا يغني عن برنامج HIPAA الخاص بك. تسجّل الاتفاقية التزامات المنصّة إليك كشريك أعمال؛ وتبقى قرارات أن PHI في النطاق وتعيين جمهورات ملاصقة لـ PHI وتهيئة الاستبقاء مملوكة للمستأجر. لكيفية تآلف القطع، راجع تهيئة HIPAA وضوابط امتثال HIPAA.

​
مسار لوحة التحكم

دورة الحياة نفسها متاحة دون لمس الواجهة البرمجية عند Settings → Compliance → BAA:
  1. بطاقة الحالة — تعرض baa_status الحالي وتاريخ التنفيذ والموقّع وشعار إعادة تنفيذ حين يكون الأجل ضمن 60 يومًا من الانقضاء
  2. معاينة القالب — الاتفاقية المُخرَجة واسم منظّمتك معبَّأ
  3. نموذج الإقرار — اسم الموقّع وبريده مضافًا إلى حقل توقيع كتابة الاسم، معروضًا للمالكين حين تكون الحالة pending
  4. تنزيل — رابط إلى النسخة المنفَّذة بعد التنفيذ، بعنوان جديد لـ 24 ساعة عند كل طلب
إن لم تُقِرّ PHI بعد، تعرض الصفحة دعوة «Start handling PHI» تُقدِّم إقرار require وتفتح جزء التنفيذ فورًا — محاكيةً مسار الواجهة البرمجية أعلاه.

​
أسئلة شائعة

كم يدوم BAA منفَّذ؟ سنة من التنفيذ. يحمل رد الحالة expires_at وdays_until_expiry؛ وضمن 60 يومًا من الانقضاء تعرض لوحة التحكم شعار إعادة التنفيذ. بعد الانقضاء تقرأ الحالة expired وتُغلَق بوّابة إرسال PHI مجددًا حتى تعيد التنفيذ بالمسار نفسه. هل يستطيع إداري تنفيذ الـ BAA لفتح الإرسالات؟ لا — التنفيذ (والرجوع) للمالك حصرًا لأنه يُلزم المنظمة. يستطيع الإداري أن يوسم PHI كمطلوبة أو مخفَضة، وقراءة الحالة، ومعاينة القالب، وتنزيل النسخة المنفَّذة. ما الفرق بين decline وrevert؟ تسجّل decline أن لا PHI في النطاق وترفع بوّابة الإرسال؛ وتمتنع عن لمس BAA منفَّذ. أما revert فيزيل اتفاقية منفَّذة أو منتهية كليًّا، معيدًا المنظمة إلى not_required مع حفظ سوابق تدقيقها والـ PDF المخزَّن. وكلاهما يترك قيدًا في سلسلة التدقيق. هل تقبل نقاط النهاية مرآة JSONB قديمة للحالة؟ مسار /api/v1/compliance/baa هو المسار القانوني. المرآة الأقدم PUT /api/v1/settings/hipaa/baa (الموثَّقة ضمن ضوابط امتثال HIPAA) هي احتياط للمستأجرين قبل الترحيل فحسب؛ وحين تمتلك المنظمة قيمة baa_status، تقرأ البوّابات العمود القانوني وتتجاهل المرآة.
آخر تحديث: سبتمبر 2026 لأسئلة حول الـ BAA، راسل: compliance@devotel.io