Skip to main content

​
Business Associate Agreement (BAA)

Les organisations qui envoient, stockent ou traitent des Protected Health Information (PHI) via Devotel Orbit doivent disposer d’un Business Associate Agreement enregistré. La plateforme exige que la route BAA existe avant que le mode HIPAA puisse être activé : lorsque des PHI entrent dans le périmètre, le contrôle à l’envoi rejette le trafic avec HIPAA_BAA_REQUIRED jusqu’à ce qu’un BAA exécuté soit enregistré. Ce guide couvre l’ensemble du cycle de vie : les états canoniques de baa_status, la manière dont les six endpoints /api/v1/compliance/baa s’articulent, quel rôle peut appeler quel endpoint, ce qui change une fois un BAA exécuté, et comment revenir à la configuration par défaut de la plateforme après un accord exécuté.
Il s’agit d’un contrôle HIPAA appartenant au tenant : c’est vous qui décidez si des PHI sont dans le périmètre, qui exécutez délibérément l’accord, et qui le renouvelez avant l’expiration de la durée annuelle. Devotel fournit le pipeline de signature électronique — le rendu du modèle, la capture de la signature par saisie du nom, l’ancrage immuable dans l’audit, et le PDF exécuté conservé —, mais la détermination juridique selon laquelle des PHI sont dans le périmètre vous appartient.

​
États de baa_status

Votre organisation se trouve toujours dans l’un des quatre états suivants, renvoyés par GET /api/v1/compliance/baa : La réponse contient également les informations du signataire et le compte à rebours jusqu’à l’expiration :
Lorsque hipaa_required passe à true alors que le statut est encore not_required, l’endpoint de lecture fait passer l’organisation à pending automatiquement, de sorte que l’étape d’exécution s’ouvre sans appel séparé.

​
Pourquoi le processus commence par une attestation

Le processus BAA existe parce que HIPAA s’applique à l’usage, et non aux comptes. La plateforme ne présume pas que chaque espace de travail traite des PHI — l’organisation atteste d’abord que des PHI sont dans le périmètre, ce qui définit le drapeau hipaa_required et fait passer l’état à pending. Cette attestation ouvre l’étape d’exécution ; l’exécution complète alors l’accord. Cet ordre supprime une dépendance circulaire : le mode HIPAA ne peut pas être activé sans un BAA exécuté, mais le tableau de bord avait également besoin d’un moyen de démarrer le BAA avant que le mode HIPAA n’existe. Aussi bien require (des PHI sont dans le périmètre) que decline (aucune PHI n’est dans le périmètre) écrivent une ligne d’audit compliance.baa.* nommant l’acteur, de sorte que l’attestation elle-même est un événement juridique enregistré — et non un simple interrupteur de paramètre.

​
Le flux des endpoints

Toutes les routes se trouvent sous /api/v1/compliance/baa et exigent une session authentifiée. Les six opérations ci-dessous constituent l’intégralité du cycle de vie ; la page Settings → Compliance → BAA du tableau de bord pilote exactement ces endpoints.

​
1. Lire l’état actuel

Tout owner ou admin peut lire. Appelez ce endpoint en premier — il vous indique si l’organisation doit attester, exécuter, re-exécuter ou télécharger.

​
2. Prévisualiser le modèle

Avant de signer, examinez le texte définitif de l’accord. GET /api/v1/compliance/baa/template renvoie le modèle rendu avec la dénomination sociale de votre organisation déjà remplie. Les champs d’exécution (horodatages, référence du document) apparaissent sous forme de marqueurs lisibles plutôt que d’espaces réservés bruts, et les champs du signataire sont des blancs que le tableau de bord remplit en direct pendant que vous saisissez.
Réponse :

​
3. Attester que des PHI sont dans le périmètre

Cela définit hipaa_required = true et fait passer une organisation not_required à pending. Cela ouvre le flux d’exécution — cela n’active pas le mode HIPAA. Le reason facultatif (jusqu’à 500 caractères) est enregistré sur la ligne d’audit.

​
4. Exécuter avec une signature électronique par saisie du nom

L’exécution est réservée à l’owner — une signature click-wrap engage l’organisation, il ne s’agit donc pas d’une action de niveau développeur. Le signataire ressaisit son nom légal dans typed_attestation, et le serveur exige qu’il corresponde exactement à signer_name ; toute incompatibilité est rejetée avec un 400, ce qui bloque également les soumissions automatiques de formulaires vides.
En cas de succès, le serveur :
  1. Rend le modèle avec les informations du signataire, les horodatages d’exécution, et une référence de document générée
  2. Conserve le document rendu en tant que PDF exécuté canonique
  3. Marque l’organisation executed avec le signataire, la version du modèle et l’horodatage d’exécution, et enregistre l’expiration (exécution plus la durée standard d’un an)
  4. Écrit une entrée compliance.baa.executed dans le journal d’audit avec la méthode de signature (type_the_name) — l’entrée d’audit est la preuve juridique de l’attestation, et le PDF conservé est le document canonique
La réponse renvoie le nouvel état ainsi que la référence du document :
L’exécution est limitée à un faible nombre de requêtes par minute ; il s’agit d’un acte juridique délibéré, et non d’une boucle scriptée. (Pour le fondement juridique du click-wrap, voir Signatures vocales.)

​
5. Télécharger la copie exécutée

Une fois qu’un BAA est enregistré, tout owner ou admin peut le récupérer pour vos dossiers, un audit client ou un régulateur :
La réponse contient une URL de téléchargement valable 24 heures :
Partagez l’URL dans cette fenêtre ou téléchargez vous-même le fichier et archivez-le. Si aucun BAA n’a encore été exécuté, l’endpoint renvoie 404.

​
6. Revenir à la configuration par défaut de la plateforme

La réversion supprime l’accord enregistré et ramène l’organisation à not_required. Elle est réservée à l’owner et n’est appelable que sur un BAA exécuté ou expiré — et seulement après que le mode HIPAA a été désactivé, de sorte qu’un espace de travail HIPAA actif ne peut pas révoquer silencieusement ses propres preuves.
L’historique d’audit du BAA exécuté et le PDF conservé sont préservés — la réversion retire l’état actif, elle n’efface pas les preuves. Utilisez-la lorsque les PHI quittent réellement le périmètre, ou pour réinitialiser un espace de travail sur une ligne de base propre ; utilisez plutôt decline lorsque l’attestation « aucune PHI » change.

​
Decline : attester qu’aucune PHI n’est dans le périmètre

POST /api/v1/compliance/baa/decline (owner ou admin, reason facultatif) enregistre que les PHI ne sont pas dans le périmètre et lève le contrôle à l’envoi une fois qu’une organisation y a été soumise. Il refuse de toucher à un BAA enregistré — un decline ne peut pas démanteler un accord exécuté ; c’est le rôle de revert. Parce que require et decline sont des bascules d’attestation symétriques, un admin qui decline peut rétablir l’exigence plus tard si des PHI reviennent dans le périmètre.

​
Rôles et chaîne d’audit

Les endpoints de lecture, prévisualisation, téléchargement et attestation acceptent owner ou admin. Les deux actes qui engagent ou révoquent un accord juridique — execute et revert — sont réservés à l’owner. Chaque écriture ajoute une entrée compliance.baa.* au journal d’audit de l’organisation — compliance.baa.hipaa_required en cas de require, compliance.baa.declined en cas de decline, compliance.baa.executed en cas d’exécution, compliance.baa.reverted en cas de réversion — portant l’acteur, la raison, et (en cas d’exécution) la version du modèle et la méthode de signature. C’est cette chaîne en écriture seule, et non le champ de statut actuel, qui constitue la preuve juridique de l’attestation. Vous pouvez l’inspecter depuis le tableau de bord sous Settings → Audit log.

​
Ce qui change une fois un BAA exécuté

L’exécution du BAA fait deux choses :
  1. Lève le contrôle d’envoi de PHI. Tant que hipaa_required est true et qu’aucun BAA dans sa durée n’est enregistré, les envois sortants qui concernent des PHI sont rejetés avec 422 HIPAA_BAA_REQUIRED. Un BAA exécuté supprime ce rejet. (Le verdict du contrôle et le comportement fail-closed sont documentés sous Contrôles à l’envoi.)
  2. Débloque le mode HIPAA. L’activation du mode HIPAA exige baa_status = "executed" ; la tentative avant l’exécution renvoie 403. Une fois le mode HIPAA activé, les contrôles décrits dans Contrôles de conformité HIPAA — journalisation des accès aux PHI, rétention des données, etc. — s’appliquent à l’espace de travail.
Ce que cela ne change pas : exécuter un BAA n’active pas en soi le mode HIPAA, ne détermine pas si votre traitement est licite, et ne remplace pas votre propre programme HIPAA. L’accord enregistre les obligations de la plateforme envers vous en tant que business associate ; la décision que les PHI sont dans le périmètre, la désignation des audiences proches des PHI, et la configuration de la rétention restent du ressort du tenant. Pour la manière dont les éléments s’assemblent, voir Intégration HIPAA et Contrôles de conformité HIPAA.

​
Flux dans le tableau de bord

Le même cycle de vie est disponible sans toucher à l’API sous Settings → Compliance → BAA :
  1. Carte de statut — affiche le baa_status actuel, la date d’exécution, le signataire, et un bandeau de re-exécution lorsque la durée se situe dans les 60 jours avant l’expiration
  2. Prévisualisation du modèle — l’accord rendu avec le nom de votre organisation rempli
  3. Formulaire d’attestation — le nom et l’e-mail du signataire, plus le champ de signature par saisie du nom, affichés aux owners lorsque l’état est pending
  4. Téléchargement — un lien vers la copie exécutée une fois exécutée, avec une URL de 24 heures fraîchement générée à chaque requête
Si les PHI n’ont pas encore été attestées, la page présente un appel à l’action « Start handling PHI » qui soumet l’attestation require et ouvre immédiatement le volet d’exécution — à l’image du flux API ci-dessus.

​
FAQ

Combien de temps dure un BAA exécuté ? Un an à compter de l’exécution. La réponse d’état contient expires_at et days_until_expiry ; dans les 60 jours avant l’expiration, le tableau de bord affiche un bandeau de re-exécution. Après l’expiration, le statut indique expired et le contrôle d’envoi de PHI se referme jusqu’à ce que vous le re-exécutiez avec le même flux. Un admin peut-il exécuter le BAA pour débloquer les envois ? Non — l’exécution (et la réversion) est réservée à l’owner car elle engage l’organisation. Un admin peut marquer les PHI comme requises ou refusées, lire l’état, prévisualiser le modèle et télécharger la copie exécutée. Quelle est la différence entre decline et revert ? decline enregistre qu’aucune PHI n’est dans le périmètre et lève le contrôle à l’envoi ; il refuse de toucher à un BAA exécuté. revert supprime entièrement un accord exécuté ou expiré, ramenant l’organisation à not_required tout en préservant son historique d’audit et son PDF conservé. Les deux laissent des entrées dans la chaîne d’audit. Les endpoints acceptent-ils un miroir d’état JSONB hérité ? Le flux /api/v1/compliance/baa est le chemin canonique. L’ancien miroir PUT /api/v1/settings/hipaa/baa (documenté sous Contrôles de conformité HIPAA) est un recours uniquement pour les tenants antérieurs à la migration ; une fois qu’une organisation possède une valeur baa_status, les contrôles lisent la colonne canonique et ignorent le miroir.
Dernière mise à jour : septembre 2026 Pour toute question concernant le BAA, contactez : compliance@devotel.io