> ## 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.

# Processus du Business Associate Agreement (BAA)

> Exécutez votre Business Associate Agreement HIPAA avec Devotel : attestation du périmètre PHI, prévisualisation du modèle, signature électronique par saisie du nom, et téléchargement de la copie exécutée.

# 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` :

| État           | Signification                                                                                                                                                                            |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `not_required` | L'organisation a attesté (ou retenu par défaut) qu'aucune PHI n'est dans le périmètre. Il s'agit de la valeur par défaut pour toute nouvelle organisation.                               |
| `pending`      | Des PHI sont dans le périmètre (`hipaa_required = true`) et le BAA est en attente d'exécution. Le formulaire d'exécution est disponible à partir de cet état.                            |
| `executed`     | Un BAA a été signé et se trouve dans sa durée d'un an. Il s'agit du seul état qui satisfait les contrôles d'activation HIPAA et d'envoi de PHI.                                          |
| `expired`      | Un BAA exécuté a dépassé sa durée d'un an. Les envois de PHI sont à nouveau bloqués jusqu'à ce que vous le re-exécutiez. La re-exécution devient disponible 60 jours avant l'expiration. |

La réponse contient également les informations du signataire et le compte à rebours jusqu'à l'expiration :

```json theme={null}
{
  "baa_status": "executed",
  "baa_executed_at": "2026-08-10T14:22:31.410Z",
  "baa_template_version": "v1",
  "baa_signer_name": "Jane Roe",
  "baa_signer_email": "jane@example.com",
  "baa_pdf_gcs_url": "gs://…/baa/org_…/baa_….pdf",
  "hipaa_required": true,
  "expires_at": "2027-08-10T14:22:31.410Z",
  "days_until_expiry": 342
}
```

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

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/baa" \
  -H "Authorization: Bearer sk_live_..."
```

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.

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/baa/template?version=v1" \
  -H "Authorization: Bearer sk_live_..."
```

Réponse :

```json theme={null}
{
  "version": "v1",
  "covered_entity_name": "Acme Health Ltd",
  "format": "markdown",
  "body": "# Business Associate Agreement\n\nThis Business Associate Agreement..."
}
```

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

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/baa/require" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "reason": "We began sending patient appointment reminders that contain PHI." }'
```

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.

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/baa/execute" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "signer_name": "Jane Roe",
    "signer_email": "jane@example.com",
    "typed_attestation": "Jane Roe"
  }'
```

| Champ               | Règle                                                                                |
| ------------------- | ------------------------------------------------------------------------------------ |
| `signer_name`       | Le nom légal du signataire (2 à 200 caractères).                                     |
| `signer_email`      | Une adresse e-mail valide.                                                           |
| `typed_attestation` | Doit **correspondre exactement** à `signer_name`. Une incompatibilité renvoie `400`. |
| `template_version`  | Facultatif. Par défaut, la version canonique actuelle.                               |

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 :

```json theme={null}
{
  "baa_status": "executed",
  "baa_executed_at": "2026-08-24T09:41:12.008Z",
  "baa_template_version": "v1",
  "baa_signer_name": "Jane Roe",
  "baa_signer_email": "jane@example.com",
  "baa_id": "baa_9f2k…",
  "expires_at": "2027-08-24T09:41:12.008Z",
  "days_until_expiry": 365,
  "hipaa_required": true
}
```

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](/compliance/voice-signatures).)

### 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 :

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/baa/download" \
  -H "Authorization: Bearer sk_live_..."
```

La réponse contient une URL de téléchargement valable **24 heures** :

```json theme={null}
{
  "url": "https://storage.googleapis.com/…/baa/org_…/baa_….pdf?X-Goog-Signature=…",
  "expires_in_seconds": 86400
}
```

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.

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/baa/revert" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "reason": "Organization no longer processes PHI; returning to default posture." }'
```

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](#decline-no-phi-in-scope) 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`.

| Action                                                                      | `owner` | `admin` | `developer` / `viewer` / `billing` |
| --------------------------------------------------------------------------- | :-----: | :-----: | :--------------------------------: |
| Lire l'état du BAA                                                          |   Oui   |   Oui   |                 Non                |
| Prévisualiser le modèle                                                     |   Oui   |   Oui   |                 Non                |
| Télécharger la copie exécutée                                               |   Oui   |   Oui   |                 Non                |
| Attester les PHI dans le périmètre (`require`) / hors périmètre (`decline`) |   Oui   |   Oui   |                 Non                |
| Exécuter le BAA                                                             |   Oui   |   Non   |                 Non                |
| Revenir à la configuration par défaut                                       |   Oui   |   Non   |                 Non                |

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](/guides/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](/compliance/send-gates#baa-the-hipaa-send-gate).)
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](/compliance/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](/guides/hipaa-onboarding) et [Contrôles de conformité HIPAA](/compliance/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](/compliance/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](mailto:compliance@devotel.io)*
