​

Conformité HIPAA

​

Vue d’ensemble

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

​

Qui peut faire quoi

​

Prérequis

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

• 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)

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

• 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 avant de vous y fier.

​

3. Journal d’audit PHI

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

• 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

​

4. Rétention des données

• 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

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

​

5. Cycle de vie du statut BAA

• 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é

​

Exécution du BAA

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.

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.

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

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.

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

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"]
}

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

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 s’applique toujours au moment du message et reste inchangée.

{
  "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. 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.
4. Relancer — une fois le BAA executed et dans sa durée de validité, le precheck passe et la campagne se lance normalement.

• 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

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."
  }
}

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

​

Configuration du dashboard

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

• 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

​

La rédaction est activée par défaut

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.

​

Responsabilité partagée

​

Réponse aux incidents

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 — 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 — le verdict et le mode d’application que ce contrôle alimente