> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# ضوابط الامتثال لـ HIPAA في رسائل الرعاية الصحية

> وضع HIPAA المملوك للمستأجر: مفتاح تبديل اختياري لمالك مساحة العمل، وأظرف HIPAA_BAA_REQUIRED الموثّقة كضوابط للمستأجر، ومصفوفة الأدوار مقابل الواجهات، وصف تدقيق PHI المتجمّع في كتالوج سجلات المعالجة الخاص باتفاقية معالجة البيانات (DPA).

# الامتثال لـ HIPAA

وضع الامتثال ملك لك لتكوينه — إعدادات Devotel Orbit تأتي مفتوحة افتراضيًا. وضع HIPAA هو **مفتاح تبديل اختياري لكل مؤسسة** للمؤسسات التي تتعامل مع معلومات الصحة المحمية (PHI): يقوم مالك مساحة العمل بتفعيله، ويبقى معطّلًا ما لم تطلب تفعيله. لا تفرض Devotel وضع HIPAA إطلاقًا ولا تقرر أن حركة مرورك "متوافقة" — فتفعيل المفتاح ينشّط ضمانات Orbit المشروطة باتفاقية BAA، والبوابات التي يفتحها هي ضوابط مملوكة للمستأجر تشغّلها أنت. يصف هذا المستند الضوابط التقنية والإدارية التي تنطبق عند تفعيل وضع HIPAA.

***

## نظرة عامة

وضع HIPAA هو **مفتاح تبديل اختياري لكل مؤسسة** — وليس وضعًا تفرضه المنصة. لا يستطيع تبديله سوى مالك مساحة العمل (`owner`)، ويبقى المفتاح معطّلًا حتى تتصرف، وهو مشروط باتفاقية BAA: فهو ينشّط (أو يخفف) مجموعة من الضوابط المعزّزة، ولا تحمل أي عملية إرسال أو وصول قواعد خاصة بـ PHI ما لم تكن قد اخترت التفعيل:

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

إن أظرف `HIPAA_BAA_REQUIRED` و`HIPAA_BAA_INVALID` التي قد تتلقاها على جهة المكتب هي ضوابط على مستوى المستند تختارها وتملكها كمستأجر — وهي نفس الحكم وسلوك الإغلاق عند الفشل (fail-closed) الموصوفين في [BAA — بوابة الإرسال الخاصة بـ HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate). وهي ليست تكليفات من المنصة.

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

تُسند ضوابط HIPAA إلى أدوار، بحيث يمكنك تعيين كل واجهة للأشخاص في مساحة عملك. (تتطابق هذه الأعمدة مع نص الأقسام أدناه.)

| الدور       | قراءة محتوى الرسائل | قراءة سجل الوصول إلى PHI | كتابة BAA | تفعيل/تعطيل وضع HIPAA              |
| ----------- | ------------------- | ------------------------ | --------- | ---------------------------------- |
| `owner`     | نعم                 | نعم                      | نعم       | نعم (التعطيل يتطلب إعادة المصادقة) |
| `admin`     | نعم                 | نعم                      | لا        | لا                                 |
| `developer` | نعم                 | لا                       | لا        | لا                                 |
| `viewer`    | نعم                 | لا                       | لا        | لا                                 |
| `billing`   | لا                  | لا                       | لا        | لا                                 |

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

قبل تفعيل وضع HIPAA، يجب على المؤسسات:

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

***

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

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

جميع بيانات PHI — بما في ذلك `body` للرسائل و`media_url` والبيانات الوصفية — تُشفَّر أثناء التخزين باستخدام مفاتيح **AES-256 المُدارة من Google** (التشفير الافتراضي في Cloud SQL):

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

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

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

تخضع قراءات محتوى الرسائل لعضوية مساحة العمل، ولمفاتيح API بنطاق `messages:read` / `messages:write`. تُسجَّل كل قراءة في [سجل تدقيق PHI](#3-phi-audit-log). يعكس الجدول أدناه من يستطيع قراءة محتوى الرسائل اليوم:

| الدور       | قراءة محتوى الرسائل | ملاحظات                                                             |
| ----------- | ------------------- | ------------------------------------------------------------------- |
| `owner`     | نعم                 | يمكنه تفعيل/تعطيل وضع HIPAA وعرض سجلات الوصول إلى PHI               |
| `admin`     | نعم                 | يمكنه عرض سجلات الوصول إلى PHI                                      |
| `developer` | نعم                 | تُسجَّل كل قراءة في سجل الوصول إلى PHI                              |
| `viewer`    | نعم                 | تُسجَّل كل قراءة في سجل الوصول إلى PHI                              |
| `billing`   | لا                  | محصور في الواجهات المالية؛ يتلقى `403` على نقاط نهاية محتوى الرسائل |

يقتصر دور `billing` على الواجهات المالية — الفوترة والتسعير ورؤى الاستخدام — ولا يمكنه قراءة محتوى الرسائل. يمكن لكل دور آخر، بما في ذلك `viewer`، قراءة محتوى الرسائل، ويُكتب كل وصول في سجل الوصول إلى PHI.

تُخزَّن رموز الأسباب في كل إدخال من إدخالات سجل الوصول إلى PHI. تُسجَّل القراءات عبر `GET /messages` و`GET /messages/{id}` برمز `read` تلقائي. تصف الفئات أدناه أسباب الوصول المستخدمة في أماكن أخرى من المنصة عندما يوفّر المشغّل سببًا صراحةً:

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

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

### 3. سجل تدقيق PHI

كل وصول إلى بيانات تحتوي على PHI يُنشئ إدخالًا في سجل التدقيق. يمثّل هذا السجل صفًا واحدًا في كتالوج سجلات المعالجة الذي تحتفظ به مؤسستك — صفحة [اتفاقية معالجة البيانات](/compliance/data-processing-agreement) هي الكتالوج الأعلى لتلك السجلات وللإقرارات التي تربطها:

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

سجل الوصول إلى PHI:

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

**نقطة النهاية API**: `GET /api/v1/settings/hipaa/phi-access-log`

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

عندما يكون وضع HIPAA نشطًا، يُفرض الاحتفاظ بالبيانات:

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

**التهيئة**: عبر لوحة التحكم في **Settings → Compliance → HIPAA → Data Retention** أو عبر API:

```bash theme={null}
PUT /api/v1/settings/hipaa
{
  "enabled": true,
  "data_retention_days": 365
}
```

**تفعيل** وضع HIPAA هو استدعاء واحد — فهو يشدد وضع أمان مساحة العمل، لذا لا يتطلب تحدي إعادة مصادقة (يبقى توقيع BAA إلزاميًا؛ انظر أدناه). أما **تعطيل** وضع HIPAA فهو إجراء مدمّر ويتطلب تدفق إعادة المصادقة ذا الخطوتين الموصوف في [تعطيل وضع HIPAA](#6-disabling-hipaa-mode).

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

تتتبع Devotel حالة BAA لكل مؤسسة وفق دورة حياة قانونية `baa_status`:

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

كل اتفاقية BAA منفذة تسجّل نسخة القالب واسم الموقّع وبريده الإلكتروني وطابع وقت التنفيذ وانتهاء المدة.

**المتطلب**: **لا يمكن تفعيل** وضع HIPAA حتى تصبح `baa_status` بقيمة `executed`. محاولة تفعيل وضع HIPAA قبل ذلك تعيد خطأ `403 Forbidden`، ويُرفض أي إرسال يحتوي PHI بخطأ `422 HIPAA_BAA_REQUIRED`. حكم بوابة وقت الإرسال وسلوك الإغلاق عند الفشل لديها موثّقان في [BAA — بوابة الإرسال الخاصة بـ HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate).

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

نفِّذ اتفاقية BAA عبر نقاط النهاية `/api/v1/compliance/baa`. هذا هو التدفق الذي يستخدمه جزء **Compliance → BAA** في لوحة التحكم، وهو التدفق الوحيد الذي يستوفي بوابتي تفعيل HIPAA وإرسال PHI.

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.

```bash theme={null}
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.

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

لمراجعة الاتفاقية قبل التوقيع، استدعِ `GET /api/v1/compliance/baa/template`.

> **نقطة نهاية قديمة:** `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` بدلًا من ذلك.
>
> ```bash theme={null}
> 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

سجل الجماهير المجاورة لـ PHI هو **سجل على مستوى المؤسسة لمعرّفات قوائم جهات الاتصال والشرائح التي يحمل أعضاؤها PHI** — مثل المرضى الذين وافقوا على تلقي رسائل العلاج. ينتمي التصنيف إلى الجمهور ذاته، لا إلى أي حملة فردية: الجمهور مجاور لـ PHI بسبب بياناته المصدرية، لذا يتبعه التصنيف أيًّا كانت الحملة التي تستخدمه.

عندما يكون HIPAA ضمن نطاق مؤسستك (ضبط `hipaa_required` عبر [تدفق BAA](#5-baa-status-lifecycle)) ويُحلّ جمهور الحملة إلى معرّف قائمة أو شريحة مُصنّفة، يرفض [الفحص المسبق لإطلاق الحملة](#campaign-launch-precheck) الإطلاق حتى تصبح اتفاقية BAA بحالة `executed` وضمن مدتها.

**API**: يعيد `GET /api/v1/compliance/hipaa/phi-audiences` السجل الحالي المخصص لمؤسستك. ويستبدل `PUT /api/v1/compliance/hipaa/phi-audiences` السجل بكتابة واحدة. تتطلب كلتا نقطتي النهاية دور `owner` أو `admin` — نفس البوابة المستخدمة لنقاط نهاية BAA.

**قراءة السجل:**

```bash theme={null}
GET /api/v1/compliance/hipaa/phi-audiences
```

```json theme={null}
{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20"],
  "max": 500
}
```

**استبدال السجل:**

```bash theme={null}
PUT /api/v1/compliance/hipaa/phi-audiences
{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20"]
}
```

إن PUT هو **استبدال كامل** للمعرّفات المصنّفة — لا توجد نقطة نهاية DELETE. لرفع تصنيفٍ ما، أرسل PUT بالسجل دون ذلك المعرّف؛ ولإعادة التصنيف، أرسل PUT مع إعادة إضافة المعرّف. كل عنصر هو سلسلة معرّف جمهور (1–128 حرفًا)، بحد أقصى **500** معرّف لكل مؤسسة. إن `PUT` بمصفوفة `audience_ids` فارغة يمسح السجل. تُكتب كل عملية استبدال بشكل ذرّي (لا يرى طلب GET المتزامن تحديثًا جزئيًا إطلاقًا) وتُسجَّل في سجل التدقيق.

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

***

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

تمتلك الحملات **بوابتين** لـ HIPAA في نقاط مختلفة من التدفق:

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

يقيّم الفحص المسبق **نفس** قواعد BAA كما في بوابة كل مستلم، بحيث لا يختلف الاثنان أبدًا حول معنى "BAA ضمن المدة".

**واجهة لوحة التحكم:** في خطوة الجمهور بمعالج الحملات، يُظهر اختيار قائمة أو شريحة مُصنّفة تحذيرًا استشاريًا — *"هذا الجمهور مُصنّف على أنه مجاور لـ PHI. يتطلب الإطلاق اتفاقية شريك أعمال (BAA) منفذة — تحقق من حالتها ضمن Settings → Compliance → BAA."* التحذير استشاري: فهو لا يحظر زر **Next**، لأن التصنيف قد يُرفع (أو تُنفَّذ BAA) قبل الإطلاق الفعلي. البوابة الصارمة تقع عند الإطلاق.

**رد الرفض:**

```json theme={null}
{
  "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](#executing-the-baa).
4. **أعد الإطلاق** — بمجرد أن تصبح BAA بحالة `executed` وضمن المدة، ينجح الفحص المسبق وتُطلَق الحملة بشكل طبيعي.

**الحدود:**

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

***

### 6. تعطيل وضع HIPAA

تعطيل وضع HIPAA انتقال **مدمّر وحساس للتدقيق**: فهو يزيل علم الكيان المُغطّى ورابط BAA والحد الأدنى الصارم للاحتفاظ على مساحة عمل قد تحتوي PHI. لمنع حدوث ذلك في جلسة متصفح مسروقة، يتطلب التعطيل **تحدي إعادة مصادقة جديدًا**. (تفعيل وضع HIPAA *لا* يتطلب ذلك — فهو فقط يشدد الوضع.)

لذا فالتعطيل تدفق **من خطوتين**:

**الخطوة 1 — أنشئ رمز تحدي إعادة مصادقة لاستخدام واحد:**

```bash theme={null}
POST /api/v1/settings/hipaa/reauth-challenge
```

يعيد الرد رمزًا قصير الأجل (5 دقائق) لاستخدام واحد:

```json theme={null}
{
  "challenge_token": "h7Yc...base64url...",
  "expires_at": "2026-04-02T10:35:00Z"
}
```

**الخطوة 2 — أرسل طلب التعطيل مع ضبط ترويسة `X-Reauth-Challenge` على ذلك الرمز:**

```bash theme={null}
PUT /api/v1/settings/hipaa
X-Reauth-Challenge: h7Yc...base64url...
{
  "enabled": false
}
```

يجب استبدال الرمز **خلال 5 دقائق** ولا يمكن استهلاكه إلا **مرة واحدة**. إذا كانت ترويسة `X-Reauth-Challenge` مفقودة أو مشوّهة أو منتهية الصلاحية، يُرفض طلب التعطيل بخطأ `401 REAUTH_REQUIRED`:

```json theme={null}
{
  "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

| الطريقة | نقطة النهاية                       | الوصف                                                                   | الدور المطلوب   |
| ------- | ---------------------------------- | ----------------------------------------------------------------------- | --------------- |
| `GET`   | `/settings/hipaa`                  | الحصول على حالة HIPAA وتهيئتها                                          | `admin+`        |
| `PUT`   | `/settings/hipaa`                  | تفعيل/تعطيل وضع HIPAA (التعطيل يتطلب `X-Reauth-Challenge`)              | `owner`         |
| `POST`  | `/settings/hipaa/reauth-challenge` | إنشاء رمز إعادة مصادقة لاستخدام واحد مطلوب **لتعطيل** وضع HIPAA         | `owner`         |
| `GET`   | `/settings/hipaa/phi-access-log`   | سجل وصول PHI مقسّم إلى صفحات                                            | `admin+`        |
| `GET`   | `/compliance/baa/`                 | الحصول على حالة BAA الحالية (`baa_status` والموقّع وانتهاء الصلاحية)    | `admin+`        |
| `GET`   | `/compliance/baa/template`         | معاينة اتفاقية BAA قبل التوقيع                                          | `admin+`        |
| `POST`  | `/compliance/baa/require`          | الإقرار بأن PHI ضمن النطاق وفتح تدفق التنفيذ                            | `owner`         |
| `POST`  | `/compliance/baa/execute`          | تنفيذ BAA عبر توقيع إلكتروني بنمط اكتب-الاسم                            | `owner`         |
| `GET`   | `/compliance/hipaa/phi-audiences`  | قراءة سجل الجماهير المجاورة لـ PHI                                      | `admin+`        |
| `PUT`   | `/compliance/hipaa/phi-audiences`  | استبدال سجل الجماهير المجاورة لـ PHI (كتابة استبدال كامل)               | `owner`/`admin` |
| `PUT`   | `/settings/hipaa/baa`              | **قديم** — مرآة حالة BAA ما قبل الترحيل؛ تُتجاهل بمجرد ضبط `baa_status` | `owner`         |

***

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

تتوفر إعدادات HIPAA في لوحة التحكم ضمن **Settings → Compliance**:

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

***

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

إلى جانب الضوابط على مستوى التطبيق، توفّر بنية Devotel التحتية:

* **تشفير 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 في نصوص الصوت والفيديو

تُنشأ التسميات التوضيحية الحية (Live captions) ونصوص المكالمات ونصوص ما بعد المكالمة بواسطة معالج تحويل الكلام إلى نص التابع لـ Devotel مع تفعيل إخفاء PII/PHI افتراضيًا. تُحجب القيم الرقمية الحساسة — أرقام بطاقات الائتمان وأرقام الضمان الاجتماعي وما يشبهها — في المصدر، قبل تخزين أي نص من النصوص أو كتابته في السجلات. بالنسبة لمؤسسات HIPAA، هذا يعني أن PHI المنطوق في مكالمة يُخفى قبل إدامته.

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

إخفاء النصوص مفعّل افتراضيًا ولا يمكن إيقافه من لوحة التحكم أو API. إيقافه هو تغيير على مستوى النشر بالكامل تجريه Devotel فقط لقطاعات الامتثال الأرشيفي (مثل القانونية أو الصحية) الملزمة تعاقديًا بالاحتفاظ بنصوص *خام* غير مُخفاة تحت ضماناتها وBAA الخاصة بها.

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

إذا فُعّل الاحتفاظ بالنصوص الخام لنشرك في أي وقت، فإن النصوص الملتقطة خلال تلك الفترة خُزّنت دون إخفاء و**لا** تُحجب بأثر رجعي. راجعها وأَخلِها وفق سياسة الاحتفاظ الخاصة بك إذا كانت تحتوي PHI، واطلب من Devotel تأكيد إعادة تفعيل الإخفاء لجميع النصوص المقبلة.

***

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

امتثال HIPAA مسؤولية مشتركة بين Devotel والعميل:

| المسؤولية                                 | Devotel | العميل |
| ----------------------------------------- | ------- | ------ |
| أمان البنية التحتية                       | ✅       |        |
| تشفير البيانات أثناء التخزين              | ✅       |        |
| تشفير البيانات أثناء النقل                | ✅       |        |
| إنفاذ ضوابط الوصول                        | ✅       |        |
| تسجيل الوصول إلى PHI                      | ✅       |        |
| إخفاء PII/PHI في النصوص (مفعّل افتراضيًا) | ✅       |        |
| تأكيد تفعيل إخفاء النصوص قبل تخزين PHI    |         | ✅      |
| تنفيذ BAA                                 | ✅       | ✅      |
| تدريب القوى العاملة                       |         | ✅      |
| إجراءات الإبلاغ عن الاختراق               | ✅       | ✅      |
| معيار الحد الأدنى الضروري لـ PHI          |         | ✅      |
| إدارة موافقات المرضى                      |         | ✅      |
| تقييم المخاطر                             | ✅       | ✅      |

***

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

في حال الاشتباه باختراق PHI:

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

***

## صفحات ذات صلة

* [ماسح DLP](/compliance/dlp-scanner) — ضابط وقت الإرسال الذي يُعلّم البيانات المنظّمة العابرة لرسالة صادرة
* [ماسح السياسة قبل الإرسال](/compliance/policy-scanner) — الحكم ووضع الإنفاذ الذي يغذّيه هذا الضابط

***

*آخر تحديث: أبريل 2026*
*للأسئلة حول امتثال HIPAA، تواصل مع: [compliance@devotel.io](mailto:compliance@devotel.io)*