> ## 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. # Contrôles de conformité HIPAA pour la messagerie de santé > Posture HIPAA gérée par le tenant : un basculement opt-in réservé au propriétaire du workspace, les enveloppes côté desk soumises au BAA qu'il documente comme contrôles du tenant, la matrice rôles-surfaces, et la ligne d'audit PHI remontant au catalogue des registres de traitement du DPA. # Conformité HIPAA La posture de conformité vous appartient — Devotel Orbit est ouvert par défaut. Le mode HIPAA est un **basculement opt-in, par organisation** pour les organisations qui traitent des informations de santé protégées (PHI) : un propriétaire de workspace l'active, et il reste désactivé sauf si vous le demandez. Devotel n'impose jamais le mode HIPAA et ne décide pas que votre trafic est « conforme » — l'activation du basculement active les garde-fous d'Orbit conditionnés par le BAA, et les barrières qu'il ouvre sont des contrôles du tenant que vous exploitez. Ce document décrit les contrôles techniques et administratifs qui s'appliquent lorsque le mode HIPAA est activé. *** ## Vue d'ensemble Le mode HIPAA est un **basculement opt-in, par organisation** — et non une posture imposée par la plateforme. Seul un `owner` du workspace peut l'activer, le basculement reste désactivé jusqu'à votre action, et il est conditionné par le BAA : il active (ou assouplit) un ensemble de contrôles renforcés, et aucun envoi ni accès ne porte de règles spécifiques aux PHI tant que vous n'avez pas opté : 1. **Chiffrement au repos** — PHI chiffrées au repos avec AES-256 géré par Google (par défaut Cloud SQL) 2. **Contrôles d'accès** — accès aux PHI limité aux rôles désignés 3. **Journalisation d'audit** — tout accès aux PHI journalisé avec des codes de motif 4. **Rétention des données** — suppression automatique après la période de rétention configurée 5. **Suivi du BAA** — gestion du statut du Business Associate Agreement Les enveloppes `HIPAA_BAA_REQUIRED` et `HIPAA_BAA_INVALID` que vous pouvez recevoir côté desk sont des contrôles du tenant au niveau document, auxquels vous optez et que vous possédez — le même verdict et comportement fail-closed décrits sous [BAA — la barrière d'envoi HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate). Ce ne sont pas des mandats de la plateforme. ## Qui peut faire quoi Les contrôles HIPAA sont assignés à des rôles, afin de mapper chaque surface aux personnes de votre workspace. (Ces colonnes correspondent à la prose des sections ci-dessous.) | Rôle | Lecture du contenu des messages | Lecture du journal d'accès PHI | Écriture BAA | Activer/désactiver le mode HIPAA | | ----------- | ------------------------------- | ------------------------------ | ------------ | ---------------------------------------------------- | | `owner` | Oui | Oui | Oui | Oui (la désactivation exige une ré-authentification) | | `admin` | Oui | Oui | Non | Non | | `developer` | Oui | Non | Non | Non | | `viewer` | Oui | Non | Non | Non | | `billing` | Non | Non | Non | Non | ## Prérequis Avant d'activer le mode HIPAA, les organisations doivent : 1. **Signer un Business Associate Agreement (BAA)** avec Devotel 2. Désigner un **responsable conformité HIPAA** au sein de leur équipe *** ## Contrôles techniques ### 1. Chiffrement au repos Toutes les PHI — y compris le `body` des messages, `media_url` et les métadonnées — sont chiffrées au repos à l'aide de clés **AES-256 gérées par Google** (chiffrement par défaut de Cloud SQL) : * **Algorithme** : AES-256 (chiffrement au repos par défaut de Google Cloud) * **Gestion des clés** : les clés de chiffrement sont gérées et renouvelées par Google Cloud * **Portée** : tout le contenu stocké en base de données, y compris le `body` des messages, `media_url` et les métadonnées * **En transit** : TLS 1.3 protège toutes les données en transit (voir [Protections de l'infrastructure](#infrastructure-safeguards)) > **Remarque** : Devotel n'effectue pas actuellement de chiffrement au niveau applicatif, par organisation, des corps de messages. La confidentialité des PHI au repos repose sur le chiffrement transparent AES-256 de Google Cloud plutôt que sur un chiffrement au niveau applicatif. La réponse `GET /settings/hipaa` inclut un champ `encryption_algorithm` à des fins de reporting uniquement — il n'indique **pas** que les corps de messages sont chiffrés individuellement au niveau applicatif. ### 2. Contrôles d'accès Les lectures du contenu des messages sont régies par l'appartenance au workspace et, pour les clés API, par la portée `messages:read` / `messages:write`. Chaque lecture est enregistrée dans le [journal d'accès PHI](#3-phi-audit-log). Le tableau ci-dessous reflète qui peut lire le contenu des messages aujourd'hui : | Rôle | Lecture du contenu des messages | Remarques | | ----------- | ------------------------------- | ---------------------------------------------------------------------------------------- | | `owner` | Oui | Peut activer/désactiver le mode HIPAA et consulter les journaux d'accès PHI | | `admin` | Oui | Peut consulter les journaux d'accès PHI | | `developer` | Oui | Chaque lecture est enregistrée dans le journal d'accès PHI | | `viewer` | Oui | Chaque lecture est enregistrée dans le journal d'accès PHI | | `billing` | Non | Limité aux surfaces financières ; reçoit `403` sur les endpoints de contenu des messages | Le rôle `billing` est limité aux surfaces financières — facturation, tarification et analyses d'utilisation — et ne peut pas lire le contenu des messages. Tout autre rôle, y compris `viewer`, peut lire le contenu des messages, et chaque accès est écrit dans le journal d'accès PHI. Des codes de motif sont stockés sur chaque entrée du journal d'accès PHI. Les lectures via `GET /messages` et `GET /messages/{id}` sont enregistrées avec un motif automatique `read`. Les catégories ci-dessous décrivent les motifs d'accès utilisés ailleurs dans la plateforme lorsqu'un opérateur en fournit un explicitement : * `treatment` — accès requis pour la coordination du traitement du patient * `payment` — accès requis pour le traitement des paiements * `operations` — accès requis pour les opérations de santé * `legal` — accès requis pour la conformité légale * `support` — accès requis pour la résolution du support client > **Limitation connue :** Orbit ne limite pas actuellement les lectures du contenu des messages à un ensemble de rôles plus restreint au-delà de la restriction de `billing` ci-dessus, et n'exige pas de code de motif fourni par l'opérateur sur les endpoints de lecture des messages (`GET /messages`, `GET /messages/{id}`). Pour respecter le standard HIPAA du *minimum nécessaire*, provisionnez l'appartenance au workspace et les portées des clés API de sorte que seul le personnel ayant besoin des PHI puisse atteindre ces endpoints. Si votre programme exige une restriction de lecture par rôle sur le contenu des messages, contactez [compliance@devotel.io](mailto:compliance@devotel.io) avant de vous y fier. ### 3. Journal d'audit PHI Chaque accès à des données contenant des PHI génère une entrée de journal d'audit. Ce journal constitue une ligne du catalogue des registres de traitement que votre organisation maintient — la page [Data Processing Agreement](/compliance/data-processing-agreement) est le catalogue amont de ces registres et des attestations qui les lient : ```json theme={null} { "id": "phi_abc123", "userId": "usr_xyz789", "resource": "message:msg_def456", "reason": "treatment", "accessedAt": "2026-04-02T10:30:00Z" } ``` Le journal d'accès PHI : * Est en **append-only** et ne peut être modifié ni supprimé * Conserve jusqu'à **10 000 entrées** par organisation (les entrées les plus anciennes sont automatiquement recyclées) * Est accessible aux rôles `owner` et `admin` via le dashboard ou l'API * Peut être exporté pour des audits de conformité externes **Endpoint API** : `GET /api/v1/settings/hipaa/phi-access-log` ### 4. Rétention des données Lorsque le mode HIPAA est actif, la rétention des données est appliquée : * **Période de rétention par défaut** : 365 jours (configurable : 30–3 650 jours) * **Portée** : contenu des messages, enregistrements d'appels, pièces jointes média * **Mécanisme** : un job d'arrière-plan automatisé recherche les enregistrements expirés et les supprime de manière sécurisée * **Exceptions** : les journaux d'audit et les journaux d'accès PHI sont conservés indépendamment de la politique de rétention des données **Configuration** : via le dashboard dans **Settings → Compliance → HIPAA → Data Retention** ou via l'API : ```bash theme={null} PUT /api/v1/settings/hipaa { "enabled": true, "data_retention_days": 365 } ``` **L'activation** du mode HIPAA est un appel unique — elle renforce la posture de sécurité du workspace, donc aucun défi de ré-authentification n'est requis (un BAA signé reste obligatoire ; voir ci-dessous). **La désactivation** du mode HIPAA est destructrice et requiert le flux de ré-authentification en deux étapes décrit dans [Désactivation du mode HIPAA](#6-disabling-hipaa-mode). ### 5. Cycle de vie du statut BAA Devotel suit le statut BAA par organisation selon un cycle de vie canonique `baa_status` : * **`not_required`** — l'organisation a attesté qu'aucune PHI n'est dans le périmètre (valeur par défaut) * **`pending`** — des PHI sont dans le périmètre et le BAA attend d'être exécuté * **`executed`** — le BAA a été signé et est dans sa durée de validité * **`expired`** — un BAA exécuté a dépassé sa durée d'un an et doit être ré-exécuté Chaque BAA exécuté enregistre sa version de modèle, le nom et l'email du signataire, l'horodatage d'exécution et l'expiration de la durée. **Exigence** : le mode HIPAA **ne peut pas être activé** tant que `baa_status` n'est pas `executed`. Tenter d'activer le mode HIPAA avant cela renvoie une erreur `403 Forbidden`, et tout envoi de PHI est rejeté avec `422 HIPAA_BAA_REQUIRED`. Le verdict de la barrière au moment de l'envoi et son comportement fail-closed sont documentés sous [BAA — la barrière d'envoi HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate). #### Exécution du BAA Exécutez le BAA via les endpoints `/api/v1/compliance/baa`. Il s'agit du flux utilisé par le panneau **Compliance → BAA** du dashboard, et du seul flux qui satisfasse les barrières d'activation HIPAA et d'envoi de PHI. 1. **Vérifier l'état actuel** — `GET /api/v1/compliance/baa/` renvoie `baa_status`, les détails du signataire et `days_until_expiry` (owner/admin). 2. **Attester que des PHI sont dans le périmètre** — `POST /api/v1/compliance/baa/require` définit `hipaa_required` et fait passer une organisation `not_required` à `pending` afin que l'étape d'exécution s'ouvre (owner uniquement). Cela démarre le flux ; cela n'active pas le mode HIPAA. ```bash theme={null} POST /api/v1/compliance/baa/require { "reason": "We began storing patient appointment reminders that contain PHI." } ``` 3. **Exécuter le BAA** — `POST /api/v1/compliance/baa/execute` enregistre l'accord avec une e-signature click-wrap de type-the-name (owner uniquement). Le `typed_attestation` doit correspondre exactement à `signer_name`. En cas de succès, l'organisation est marquée `executed` avec le signataire, la version et la date, ce qui débloque les envois de PHI et permet d'activer le mode HIPAA. ```bash theme={null} POST /api/v1/compliance/baa/execute { "signer_name": "Jane Roe", "signer_email": "jane@example.com", "typed_attestation": "Jane Roe" } ``` Pour consulter l'accord avant de signer, appelez `GET /api/v1/compliance/baa/template`. > **Endpoint hérité :** `PUT /api/v1/settings/hipaa/baa` (corps `{ signed, signed_at, document_url }`) écrit un ancien miroir de statut JSONB et constitue un **fallback pour les tenants pré-migration uniquement**. Dès qu'une organisation dispose d'une valeur `baa_status`, les barrières d'activation HIPAA et d'envoi de PHI lisent cette colonne canonique et ignorent ce miroir — donc une écriture `signed: true` ici ne débloque **pas** les envois ni le mode HIPAA. Utilisez plutôt `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" > } > ``` *** ## Registre des audiences adjacentes aux PHI Le registre des audiences adjacentes aux PHI est un **registre au niveau de l'organisation des identifiants de listes de contacts et de segments dont les membres portent des PHI** — par exemple, des patients ayant opté pour des communications de traitement. La désignation appartient à l'audience elle-même, et non à une campagne individuelle : une audience est adjacente aux PHI en raison de ses données sources, donc la désignation la suit quelle que soit la campagne qui la récupère. Lorsque HIPAA est dans le périmètre de votre organisation (`hipaa_required` défini via le [flux BAA](#5-baa-status-lifecycle)) et que l'audience d'une campagne se résout en un identifiant de liste ou de segment désigné, le [precheck de lancement de campagne](#campaign-launch-precheck) refuse le lancement jusqu'à ce que votre BAA soit `executed` et dans sa durée de validité. **API** : `GET /api/v1/compliance/hipaa/phi-audiences` renvoie le registre actuel limité à votre organisation. `PUT /api/v1/compliance/hipaa/phi-audiences` remplace le registre en une seule écriture. Les deux endpoints requièrent le rôle `owner` ou `admin` — la même barrière que celle utilisée pour les endpoints BAA. **Lecture du registre :** ```bash theme={null} GET /api/v1/compliance/hipaa/phi-audiences ``` ```json theme={null} { "audience_ids": ["list_9f2c1a", "seg_4b7e20"], "max": 500 } ``` **Remplacement du registre :** ```bash theme={null} PUT /api/v1/compliance/hipaa/phi-audiences { "audience_ids": ["list_9f2c1a", "seg_4b7e20"] } ``` Le PUT est un **remplacement complet** des identifiants désignés — il n'existe pas d'endpoint DELETE. Pour lever une désignation, envoyez un PUT du registre sans cet identifiant ; pour redésigner, envoyez un PUT avec l'identifiant rajouté. Chaque élément est une chaîne d'identifiant d'audience (1–128 caractères), jusqu'à **500** identifiants par organisation. Un `PUT` avec un tableau `audience_ids` vide vide le registre. Chaque remplacement est écrit de manière atomique (un GET concurrent ne voit jamais une mise à jour partielle) et enregistré dans le journal d'audit. > **Remarque :** le registre est l'attestation de votre organisation sur les audiences contenant des PHI. Il appartient au tenant : Devotel ne désigne jamais d'audiences pour votre compte, et la désignation ne prend effet qu'une fois HIPAA dans le périmètre de votre organisation. *** ## Precheck de lancement de campagne Les campagnes comportent **deux** barrières HIPAA à différents points du flux : 1. **Precheck de lancement (au niveau campagne, barrière dure).** Avant qu'une campagne ne quitte l'état brouillon/planifié, le precheck de lancement résout son audience par rapport au registre. Si l'audience est une liste ou un segment désigné **et** que le BAA de votre organisation n'est pas `executed` et dans sa durée de validité, le lancement est refusé avec `422 HIPAA_BAA_REQUIRED`. Cela empêche une cohorte PHI d'entrer dans l'inscription de campagne au lieu de consommer du crédit wallet sur des milliers de refus par destinataire. Si l'état de conformité ne peut pas être lu, le precheck échoue en mode fermé (`500 HIPAA_BAA_GATE_DB_FAIL`) plutôt que d'admettre silencieusement une audience PHI. 2. **Barrière d'envoi (par destinataire, comportement existant).** La barrière d'envoi par destinataire documentée sous [BAA — la barrière d'envoi HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate) s'applique toujours au moment du message et reste inchangée. Le precheck évalue les **mêmes** règles BAA que la barrière par destinataire, de sorte que les deux ne sont jamais en désaccord sur ce que signifie « BAA dans sa durée de validité ». **Surface dashboard :** dans l'étape audience de l'assistant de campagne, choisir une liste ou un segment désigné affiche un avertissement consultatif — *« Cette audience est désignée comme adjacente aux PHI. Le lancement requiert un Business Associate Agreement (BAA) exécuté — vérifiez son statut sous Settings → Compliance → BAA. »* L'avertissement est consultatif : il ne bloque pas le bouton **Suivant**, car la désignation peut être levée (ou le BAA exécuté) avant le lancement effectif. La barrière dure se situe au lancement. **La réponse de refus :** ```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." } } ``` **Séquence de l'opérateur — un lancement refusé par le precheck :** 1. **Composer le registre** — `PUT /api/v1/compliance/hipaa/phi-audiences` avec les identifiants de listes/segments contenant des PHI. 2. **Vérifier le blocage** — tentez le lancement contre une audience désignée ; attendez-vous à `422 HIPAA_BAA_REQUIRED` tant que le BAA n'est pas `executed`/dans sa durée de validité. 3. **Résoudre le BAA** — exécutez (ou ré-exécutez un BAA `expired`) via `POST /api/v1/compliance/baa/execute` comme décrit dans [Exécution du BAA](#executing-the-baa). 4. **Relancer** — une fois le BAA `executed` et dans sa durée de validité, le precheck passe et la campagne se lance normalement. **Limites :** * Le registre gouverne **uniquement les lancements de campagnes**. Les envois hérités ponctuels par destinataire restent gouvernés par la barrière d'envoi par destinataire, qui ne consulte pas le registre. * Seules les audiences de type `list` et `segment` se résolvent par rapport au registre au lancement. Les audiences assemblées par contact (tous les contacts, CSV, saisie manuelle) sont évaluées destinataire par destinataire au moment de l'envoi. * L'avertissement d'audience adjacente aux PHI de l'assistant est consultatif sur le sélecteur d'audience ; l'application se fait au lancement. *** ### 6. Désactivation du mode HIPAA Désactiver le mode HIPAA est une transition **destructrice et sensible à l'audit** : elle efface le drapeau d'entité couverte, le lien BAA et le plancher de rétention strict sur un workspace pouvant contenir des PHI. Pour empêcher que cela se produise sur une session de navigateur volée, la désactivation requiert un **défi de ré-authentification frais**. (L'activation du mode HIPAA n'en requiert *pas* — elle ne fait que renforcer la posture.) La désactivation est donc un flux en **deux étapes** : **Étape 1 — Émettre un jeton de défi de ré-authentification à usage unique :** ```bash theme={null} POST /api/v1/settings/hipaa/reauth-challenge ``` La réponse renvoie un jeton à usage unique de courte durée (5 minutes) : ```json theme={null} { "challenge_token": "h7Yc...base64url...", "expires_at": "2026-04-02T10:35:00Z" } ``` **Étape 2 — Envoyer la requête de désactivation avec l'en-tête `X-Reauth-Challenge` défini sur ce jeton :** ```bash theme={null} PUT /api/v1/settings/hipaa X-Reauth-Challenge: h7Yc...base64url... { "enabled": false } ``` Le jeton doit être consommé **dans les 5 minutes** et ne peut l'être qu'**une seule fois**. Si l'en-tête `X-Reauth-Challenge` est manquant, mal formé ou expiré, la requête de désactivation est rejetée avec `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." } } ``` > **Remarque :** le défi de ré-authentification ne contrôle que la transition **activation → désactivation**. L'activation du mode HIPAA, ainsi que les mises à jour portant uniquement sur la rétention soumises alors que le mode HIPAA est déjà désactivé, ne requièrent **pas** l'en-tête. *** ## Référence API | Méthode | Endpoint | Description | Rôle requis | | ------- | ---------------------------------- | ----------------------------------------------------------------------------------------------- | --------------- | | `GET` | `/settings/hipaa` | Obtenir le statut et la configuration HIPAA | `admin+` | | `PUT` | `/settings/hipaa` | Activer/désactiver le mode HIPAA (la désactivation requiert `X-Reauth-Challenge`) | `owner` | | `POST` | `/settings/hipaa/reauth-challenge` | Émettre un jeton de ré-authentification à usage unique requis pour **désactiver** le mode HIPAA | `owner` | | `GET` | `/settings/hipaa/phi-access-log` | Journal d'accès PHI paginé | `admin+` | | `GET` | `/compliance/baa/` | Obtenir l'état BAA actuel (`baa_status`, signataire, expiration) | `admin+` | | `GET` | `/compliance/baa/template` | Prévisualiser l'accord BAA avant signature | `admin+` | | `POST` | `/compliance/baa/require` | Attester que des PHI sont dans le périmètre et ouvrir le flux d'exécution | `owner` | | `POST` | `/compliance/baa/execute` | Exécuter le BAA via une e-signature type-the-name | `owner` | | `GET` | `/compliance/hipaa/phi-audiences` | Lire le registre des audiences adjacentes aux PHI | `admin+` | | `PUT` | `/compliance/hipaa/phi-audiences` | Remplacer le registre des audiences adjacentes aux PHI (écriture de remplacement complet) | `owner`/`admin` | | `PUT` | `/settings/hipaa/baa` | **Hérité** — miroir de statut BAA pré-migration ; ignoré dès que `baa_status` est défini | `owner` | *** ## Configuration du dashboard Les paramètres HIPAA sont disponibles dans le dashboard sous **Settings → Compliance** : 1. **Basculement du mode HIPAA** — activer/désactiver le mode HIPAA (requiert un BAA) 2. **Section BAA** — exécuter le BAA (e-signature type-the-name) et suivre son statut, son signataire et l'expiration de sa durée 3. **Rétention des données** — configurer la période de suppression automatique des données 4. **Journal d'accès PHI** — consulter et exporter la piste d'audit des accès aux PHI 5. **Audiences adjacentes aux PHI** — désigner quelles listes de contacts et segments portent des PHI ; l'assistant de campagne avertit sur les audiences désignées et le precheck de lancement applique la barrière BAA *** ## Protections de l'infrastructure Au-delà des contrôles au niveau applicatif, l'infrastructure de Devotel fournit : * **Chiffrement Cloud SQL** : tout le stockage en base de données chiffré avec AES-256 par Google Cloud * **TLS 1.3** : toutes les données en transit chiffrées avec TLS 1.3 * **Isolation VPC** : base de données accessible uniquement via IP privée au sein du VPC * **Aucun conteneur privilégié** : GKE Autopilot empêche l'exécution de conteneurs privilégiés * **Secret Manager** : toutes les clés de chiffrement et identifiants stockés dans GCP Secret Manager * **Pistes d'audit** : Google Cloud Audit Logs pour le suivi des accès au niveau infrastructure *** ## Rédaction des PII/PHI dans les transcriptions voix et vidéo Les sous-titres en direct, les transcriptions d'appels et les transcriptions post-appel sont générés par le sous-traitant speech-to-text de Devotel avec la rédaction des PII/PHI activée par défaut. Les données numériques sensibles — numéros de cartes bancaires, numéros de sécurité sociale et similaires — sont masquées à la source, avant que tout texte de transcription ne soit stocké ou écrit dans les journaux. Pour les organisations HIPAA, cela signifie que les PHI prononcées lors d'un appel sont rédigées avant d'être persistées. ### La rédaction est activée par défaut La rédaction des transcriptions est activée par défaut et ne peut pas être désactivée depuis votre dashboard ou votre API. La désactiver est un changement à l'échelle du déploiement que Devotel n'effectue que pour les verticales de conformité archivistique (par exemple, juridique ou santé) contractuellement tenues de conserver des transcriptions *brutes*, non rédigées, sous leurs propres protections et leur BAA. > **Avertissement :** comme ce contrôle s'applique à l'ensemble d'un déploiement plutôt qu'à une seule organisation, il ne peut pas être limité à un workspace. Si votre déploiement traite des PHI, la rédaction doit rester activée — confirmez son statut par écrit avec votre contact Devotel dans le cadre de votre BAA avant de stocker la moindre PHI. Si la conservation des transcriptions brutes a déjà été activée pour votre déploiement, les transcriptions capturées durant cette fenêtre ont été stockées non rédigées et ne sont **pas** masquées rétroactivement. Examinez-les et purgez-les selon votre politique de rétention si elles contiennent des PHI, et demandez à Devotel de confirmer que la rédaction est réactivée pour toutes les transcriptions à l'avenir. *** ## Responsabilité partagée La conformité HIPAA est une responsabilité partagée entre Devotel et le client : | Responsabilité | Devotel | Client | | ---------------------------------------------------------------------------------- | ------- | ------ | | Sécurité de l'infrastructure | ✅ | | | Chiffrement des données au repos | ✅ | | | Chiffrement des données en transit | ✅ | | | Application du contrôle d'accès | ✅ | | | Journalisation des accès PHI | ✅ | | | Rédaction des PII/PHI dans les transcriptions (activée par défaut) | ✅ | | | Confirmer que la rédaction des transcriptions est activée avant de stocker des PHI | | ✅ | | Exécution du BAA | ✅ | ✅ | | Formation du personnel | | ✅ | | Procédures de notification de violation | ✅ | ✅ | | Standard HIPAA du minimum nécessaire pour les PHI | | ✅ | | Gestion du consentement des patients | | ✅ | | Évaluation des risques | ✅ | ✅ | *** ## Réponse aux incidents En cas de suspicion de violation de PHI : 1. L'équipe sécurité de Devotel est notifiée dans un délai de **1 heure** via l'alerte automatisée 2. Les organisations affectées sont notifiées dans un délai de **24 heures** conformément à la HIPAA Breach Notification Rule 3. Les journaux d'accès PHI sont immédiatement conservés et exportés pour l'analyse forensique 4. Les étapes de remédiation sont documentées et partagées avec les parties affectées *** ## Pages associées * [Scanner DLP](/compliance/dlp-scanner) — le contrôle au moment de l'envoi qui signale les données réglementées traversant un message sortant * [Scanner de politique pré-envoi](/compliance/policy-scanner) — le verdict et le mode d'application que ce contrôle alimente *** *Dernière mise à jour : avril 2026* *Pour toute question sur la conformité HIPAA, contactez : [compliance@devotel.io](mailto:compliance@devotel.io)*