​

الامتثال لـ HIPAA

​

نظرة عامة

1. التشفير أثناء التخزين — تشفير PHI أثناء التخزين باستخدام AES-256 المُدار من Google (الافتراضي في Cloud SQL)
2. ضوابط الوصول — تقييد الوصول إلى PHI على الأدوار المخصصة
3. تسجيل التدقيق — تسجيل كل وصول إلى PHI مع رموز الأسباب
4. الاحتفاظ بالبيانات — الحذف التلقائي بعد فترة الاحتفاظ المُهيأة
5. تتبّع BAA — إدارة حالة اتفاقية شريك الأعمال (Business Associate Agreement)

​

من يستطيع فعل ماذا

​

المتطلبات المسبقة

1. توقيع اتفاقية شريك الأعمال (BAA) مع Devotel
2. تعيين مسؤول امتثال HIPAA ضمن فريقها

​

الضوابط التقنية

​

1. التشفير أثناء التخزين

• الخوارزمية: AES-256 (التشفير الافتراضي من Google Cloud أثناء التخزين)
• إدارة المفاتيح: تُدار مفاتيح التشفير وتُدوَّر بواسطة Google Cloud
• النطاق: جميع المحتويات المخزّنة في قاعدة البيانات، بما في ذلك body للرسائل وmedia_url والبيانات الوصفية
• أثناء النقل: يحمي TLS 1.3 جميع البيانات أثناء النقل (انظر ضمانات البنية التحتية)

ملاحظة: لا تجري Devotel حاليًا تشفيرًا على مستوى التطبيق لمحتوى الرسائل لكل مؤسسة. تعتمد سرّية PHI أثناء التخزين على تشفير AES-256 الشفاف من Google Cloud وليس على تشفير عند طبقة التطبيق. يتضمن ردّ GET /settings/hipaa حقل encryption_algorithm لأغراض إعداد التقارير فقط — وهو لا يعني أن محتويات الرسائل مشفّرة بشكل فردي على مستوى التطبيق.

​

2. ضوابط الوصول

• treatment — الوصول مطلوب لتنسيق علاج المرضى
• payment — الوصول مطلوب لمعالجة المدفوعات
• operations — الوصول مطلوب للعمليات الصحية
• legal — الوصول مطلوب للامتثال القانوني
• support — الوصول مطلوب لحل طلبات دعم العملاء

قيود معروفة: لا تقيّد Orbit حاليًا قراءات محتوى الرسائل على مجموعة أضيق من الأدوار بخلاف حصر billing أعلاه، ولا تتطلب رمز سبب يوفّره المشغّل على نقاط نهاية قراءة الرسائل (GET /messages وGET /messages/{id}). لتحقيق معيار HIPAA الخاص بـ الحد الأدنى الضروري (minimum necessary)، وفّر عضوية مساحة العمل ونطاقات مفاتيح API بحيث لا يصل إلى هذه النقاط إلا الموظفون الذين يحتاجون إلى PHI. إذا كان برنامجك يتطلب تقييد القراءة لكل دور على محتوى الرسائل، فتواصل مع compliance@devotel.io قبل الاعتماد على ذلك.

​

3. سجل تدقيق PHI

{
  "id": "phi_abc123",
  "userId": "usr_xyz789",
  "resource": "message:msg_def456",
  "reason": "treatment",
  "accessedAt": "2026-04-02T10:30:00Z"
}

• إلحاق فقط (append-only) ولا يمكن تعديله أو حذفه
• يحتفظ بما يصل إلى 10,000 إدخال لكل مؤسسة (تُدوَّر الإدخالات الأقدم تلقائيًا)
• يمكن الوصول إليه لأدوار owner وadmin عبر لوحة التحكم أو API
• يمكن تصديره لأغراض التدقيقات الخارجية للامتثال

​

4. الاحتفاظ بالبيانات

• فترة الاحتفاظ الافتراضية: 365 يومًا (قابلة للتهيئة: 30–3,650 يومًا)
• النطاق: محتوى الرسائل وتسجيلات المكالمات والمرفقات الوسائطية
• الآلية: مهمة خلفية مؤتمتة تفحص السجلات المنتهية الصلاحية وتحذفها بأمان
• الاستثناءات: تُحتفظ سجلات التدقيق وسجلات الوصول إلى PHI بشكل مستقل عن سياسة الاحتفاظ بالبيانات

PUT /api/v1/settings/hipaa
{
  "enabled": true,
  "data_retention_days": 365
}

​

5. دورة حياة حالة BAA

• not_required — أقرت المؤسسة أن PHI خارج النطاق (الافتراضي)
• pending — PHI ضمن النطاق واتفاقية BAA بانتظار التنفيذ
• executed — وُقّعت اتفاقية BAA وهي ضمن مدتها
• expired — اتفاقية BAA منفذة تجاوزت مدتها السنوية ويجب إعادة تنفيذها

​

تنفيذ اتفاقية BAA

1. تحقق من الحالة الحالية — يعيد GET /api/v1/compliance/baa/ قيمة baa_status وتفاصيل الموقّع وdays_until_expiry (المالك/المسؤول).
2. أقرّ بأن PHI ضمن النطاق — يضبط POST /api/v1/compliance/baa/require قيمة hipaa_required وينقل المؤسسة من not_required إلى pending بحيث تُفتح خطوة التنفيذ (المالك فقط). تبدأ هذه الخطوة التدفق؛ ولا تُفعّل وضع HIPAA.

POST /api/v1/compliance/baa/require
{
  "reason": "We began storing patient appointment reminders that contain PHI."
}

3. نفِّذ اتفاقية BAA — يسجّل POST /api/v1/compliance/baa/execute الاتفاقية بتوقيع إلكتروني بنمط اكتب-الاسم (click-wrap) (المالك فقط). يجب أن تطابق typed_attestation قيمة signer_name تمامًا. عند النجاح تُختم المؤسسة بحالة executed مع الموقّع والنسخة والتاريخ، ما يرفع حظر إرسالات PHI ويتيح لك تفعيل وضع HIPAA.

POST /api/v1/compliance/baa/execute
{
  "signer_name": "Jane Roe",
  "signer_email": "jane@example.com",
  "typed_attestation": "Jane Roe"
}

نقطة نهاية قديمة: PUT /api/v1/settings/hipaa/baa (بجسم { signed, signed_at, document_url }) يكتب مرآة حالة JSONB أقدم وهو احتياطي للمستأجرين ما قبل الترحيل فقط. بمجرد أن تمتلك المؤسسة قيمة baa_status، تقرأ بوابتا تفعيل HIPAA وإرسال PHI ذلك العمود القانوني وتتجاهلان هذه المرآة — لذا فإن كتابة signed: true هنا لا ترفع الحظر عن الإرسالات أو وضع HIPAA. استخدم POST /api/v1/compliance/baa/execute بدلًا من ذلك.

PUT /api/v1/settings/hipaa/baa
{
  "signed": true,
  "signed_at": "2026-04-01T00:00:00Z",
  "document_url": "https://storage.devotel.io/baa/org_abc123.pdf"
}

​

سجل الجماهير المجاورة لـ PHI

GET /api/v1/compliance/hipaa/phi-audiences

{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20"],
  "max": 500
}

PUT /api/v1/compliance/hipaa/phi-audiences
{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20"]
}

ملاحظة: السجل هو إقرار مؤسستك بشأن أي الجماهير تحتوي PHI. وهو مملوك للمستأجر: لا تصنّف Devotel الجماهير نيابةً عنك إطلاقًا، ولا يسري التصنيف إلا بمجرد أن يصبح HIPAA ضمن نطاق مؤسستك.

​

الفحص المسبق لإطلاق الحملة

1. الفحص المسبق للإطلاق (على مستوى الحملة، بوابة صارمة). قبل أن تغادر الحملة حالة المسودة/المجدولة، يحلّ الفحص المسبق للإطلاق جمهورها وفق السجل. إذا كان الجمهور قائمة أو شريحة مُصنّفة و كانت اتفاقية BAA لمؤسستك ليست بحالة executed وضمن مدتها، يُرفض الإطلاق بخطأ 422 HIPAA_BAA_REQUIRED. يبقي هذا فئة PHI خارج تسجيل الحملة بدلًا من حرق رصيد المحفظة على آلاف الرفض لكل مستلم. إذا تعذّرت قراءة حالة الامتثال، يفشل الفحص المسبق مغلقًا (500 HIPAA_BAA_GATE_DB_FAIL) بدلًا من قبول جمهور PHI بشكل صامت.
2. بوابة الإرسال (لكل مستلم، السلوك الحالي). لا تزال بوابة الإرسال لكل مستلم الموثقة في BAA — بوابة الإرسال الخاصة بـ HIPAA تنطبق وقت الرسالة وهي دون تغيير.

{
  "error": {
    "code": "HIPAA_BAA_REQUIRED",
    "status": 422,
    "message": "The designated PHI-adjacent audience for this campaign requires an executed Business Associate Agreement (BAA) before outbound sends are permitted."
  }
}

1. كوِّن السجل — PUT /api/v1/compliance/hipaa/phi-audiences مع معرّفات القائمة/الشريحة التي تحتوي PHI.
2. تحقق من الحظر — حاول الإطلاق على جمهور مُصنّف؛ توقّع 422 HIPAA_BAA_REQUIRED ما دامت BAA ليست بحالة executed/ضمن المدة.
3. حلّ مشكلة BAA — نفِّذ (أو أعد تنفيذ expired) اتفاقية BAA عبر POST /api/v1/compliance/baa/execute كما هو موصوف في تنفيذ BAA.
4. أعد الإطلاق — بمجرد أن تصبح BAA بحالة executed وضمن المدة، ينجح الفحص المسبق وتُطلَق الحملة بشكل طبيعي.

• يحكم السجل إطلاق الحملات فقط. لا تزال الإرسالات القديمة لمرة واحدة لكل مستلم خاضعة لبوابة الإرسال لكل مستلم، التي لا تستشير السجل.
• تُحلّ ضد السجل عند الإطلاق جماهير من نوعي list وsegment فقط. أما الجماهير المجموعة لكل جهة اتصال (كل جهات الاتصال، CSV، الإدخال اليدوي) فتُقيَّم مستلمًا بمستلم وقت الإرسال.
• تحذير المجاور لـ PHI في المعالج استشاري على منتقي الجمهور؛ ينُفَّذ الإلزام عند الإطلاق.

​

6. تعطيل وضع HIPAA

POST /api/v1/settings/hipaa/reauth-challenge

{
  "challenge_token": "h7Yc...base64url...",
  "expires_at": "2026-04-02T10:35:00Z"
}

PUT /api/v1/settings/hipaa
X-Reauth-Challenge: h7Yc...base64url...
{
  "enabled": false
}

{
  "error": {
    "code": "REAUTH_REQUIRED",
    "message": "Fresh re-authentication is required to disable HIPAA mode. POST /settings/hipaa/reauth-challenge first, then retry within 5 minutes with X-Reauth-Challenge header."
  }
}

ملاحظة: تحدي إعادة المصادقة يحكم فقط انتقال تفعيل → تعطيل. لا يتطلب تفعيل وضع HIPAA، ولا تحديثات الاحتفاظ فقط المرسلة بينما وضع HIPAA معطّل أصلًا، تلك الترويسة.

​

مرجع API

​

تهيئة لوحة التحكم

1. مفتاح وضع HIPAA — تفعيل/تعطيل وضع HIPAA (يتطلب BAA)
2. قسم BAA — تنفيذ BAA (توقيع إلكتروني بنمط اكتب-الاسم) وتتبّع حالته والموقّع وانتهاء المدة
3. الاحتفاظ بالبيانات — تهيئة فترة الحذف التلقائي للبيانات
4. سجل الوصول إلى PHI — عرض وتصدير مسار تدقيق الوصول إلى PHI
5. الجماهير المجاورة لـ PHI — تصنيف أي قوائم جهات الاتصال والشرائح تحمل PHI؛ يحذر معالج الحملات عند الجماهير المُصنّفة ويُنفِّذ الفحص المسبق للإطلاق بوابة BAA

​

ضمانات البنية التحتية

• تشفير Cloud SQL: جميع مخازن قاعدة البيانات مشفرة بـ AES-256 بواسطة Google Cloud
• TLS 1.3: جميع البيانات أثناء النقل مشفرة بـ TLS 1.3
• عزل VPC: قاعدة البيانات متاحة فقط عبر IP خاص ضمن VPC
• لا حاويات متميزة (Privileged): يمنع GKE Autopilot تنفيذ الحاويات المتميزة
• Secret Manager: جميع مفاتيح التشفير وبيانات الاعتماد مخزّنة في GCP Secret Manager
• مسارات التدقيق: سجلات تدقيق Google Cloud لتتبع الوصول على مستوى البنية التحتية

​

إخفاء PII/PHI في نصوص الصوت والفيديو

​

الإخفاء مفعّل افتراضيًا

تحذير: لأن هذا الضابط ينطبق على النشر بأكمله وليس مؤسسة واحدة، لا يمكن تحديد نطاقه لمساحة عمل واحدة. إذا كان نشرك يعالج PHI، فيجب أن يبقى الإخفاء مفعّلًا — أكّد حالته كتابيًا مع جهة اتصال Devotel الخاصة بك كجزء من BAA قبل أن تخزّن أي PHI.

​

المسؤولية المشتركة

​

الاستجابة للحوادث

1. يُبلَّغ فريق أمن Devotel خلال ساعة واحدة عبر التنبيه الآلي
2. تُبلَّغ المؤسسات المتأثرة خلال 24 ساعة وفق قاعدة الإبلاغ عن الاختراقات في HIPAA
3. تُحفَظ سجلات الوصول إلى PHI فورًا وتُصدَّر للتحليل الجنائي
4. تُوثَّق خطوات المعالجة وتُشارَك مع الأطراف المتأثرة

​

صفحات ذات صلة

• ماسح DLP — ضابط وقت الإرسال الذي يُعلّم البيانات المنظّمة العابرة لرسالة صادرة
• ماسح السياسة قبل الإرسال — الحكم ووضع الإنفاذ الذي يغذّيه هذا الضابط