​

Enregistrer les audiences adjacentes au PHI

​

1. Quand marquer une audience comme adjacente au PHI

• Ses membres ont été importés d’un système qui retient du PHI (une exportation EHR, une synchronisation opt-in de portail patient).
• La liste ou le segment est filtré ou assemblé sur des critères porteurs de PHI (tags adjacents au diagnostic, cohortes de traitement).
• La carte de données de votre officier de compliance enregistre l’audience comme PHI dans le périmètre.

​

2. Choisir des ids de liste vs segment

# Listes de contact
GET /api/v1/contacts/lists

# Segments
GET /api/v1/contacts/segments

Désignez l’id de source, pas une copie en aval. Si une liste porteure de PHI alimente un segment dérivé, décidez si le segment dérivé contient aussi du PHI et désignez-le explicitement — le precheck vérifie l’id que la campagne référence réellement, rien d’autre.

​

3. Le swap PUT atomique

PUT /api/v1/compliance/hipaa/phi-audiences
{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20", "list_31dc88"]
}

{
  "data": {
    "audience_ids": ["list_9f2c1a", "seg_4b7e20", "list_31dc88"],
    "replaced": true
  }
}

PUT /api/v1/compliance/hipaa/phi-audiences
{
  "audience_ids": []
}

​

4. Comment le precheck de lancement utilise le registre

1. Precheck de lancement (niveau campagne, gate dur). Avant qu’une campagne ne quitte brouillon/programmée, le precheck résout son id d’audience contre le registre. Un id désigné plus un BAA qui n’est pas executed et en terme refuse le lancement avec 422 HIPAA_BAA_REQUIRED — avant qu’un seul destinataire ne soit inscrit. Si l’état de compliance ne peut être lu, le precheck échoue fermé avec 500 HIPAA_BAA_GATE_DB_FAIL plutôt que d’admettre silencieusement l’audience.
2. Gate d’envoi par destinataire (heure de message, inchangé). Le gate d’envoi existant s’applique toujours à chaque envoi individuel et ne consulte pas le registre — les envois legacy one-off sont gouvernés par lui seul.

{
  "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.",
    "details": {
      "reason": "pending",
      "audience": { "type": "list", "id": "list_9f2c1a" }
    }
  }
}

• Résoudre le BAA — l’exécuter ou le ré-exécuter pour que le gate passe. C’est le bon chemin quand l’audience porte vraiment du PHI.
• Lever la désignation — PUT le registre sans l’id d’audience. C’est le bon chemin seulement quand l’audience a été désignée par erreur. Lever une désignation pour contourner le gate est visible dans votre propre journal d’audit.

​

5. Audit trail

• hipaa.phi_audiences.set — une ligne par PUT, enregistrant l’utilisateur agissant, l’organisation et l’ensemble d’ids post-écriture complet. C’est votre histoire de versionnement : le registre n’a pas de ressource de révision séparée — la séquence de lignes d’audit est l’historique de versions. Pour reconstruire ce qui a été désigné à un point dans le temps, parcourez les lignes set en arrière ; pour revenir, PUT l’ensemble d’ids d’une ligne précédente.
• Refus de lancement HIPAA_BAA_REQUIRED — chaque lancement bloqué est loggé avec la raison du refus et l’audience en évaluation. Ces lignes font double emploi comme votre file d’incidents : un refus signifie soit que du travail de compliance est en attente (BAA non exécuté) soit qu’une désignation et une campagne sont en désaccord.

1. Lisez le details.reason et details.audience.id du refus.
2. Vérifiez GET /api/v1/compliance/baa/ — si le BAA est pending/expired/non exécuté, résolvez-le via le flux BAA.
3. Si le BAA est sain, vérifiez si l’audience devrait être désignée en premier lieu : GET /api/v1/compliance/hipaa/phi-audiences et comparez avec votre carte de données. Levez une désignation erronée avec un swap (PUT sans l’id).
4. Enregistrez le résultat dans votre propre registre d’incidents — les lignes d’audit ci-dessus sont la preuve que vous citez.

​

6. Troubleshooting des conflits d’écrasement concurrent

• Opérateur A et opérateur B font tous les deux GET le registre.
• A ajoute list_aaa et PUT. B — travaillant depuis le snapshot pré-A — ajoute list_bbb et PUT.
• Le swap de B supprime silencieusement list_aaa.

• Lire immédiatement avant d’écrire. Gardez la fenêtre read-modify-write courte ; ne portez pas un registre récupéré à travers une session d’édition — re-GET quand vous êtes prêt pour PUT.
• Vérifier après l’écriture. GET une fois de plus et confirmez que votre id est présent et qu’aucune désignation non connectée n’a été perdue. Si quelque chose a disparu, les lignes hipaa.phi_audiences.set du journal d’audit montrent quel écrivain l’a écrasée et quel ensemble restaurer.
• Sérialiser les éditions du registre organisationnellement. Parce que la désignation est une attestation de compliance, routez les éditions par un rôle (l’officier de compliance) plutôt que de les répandre entre opérateurs — un fix procédural qui élimine la course entièrement.

​

Voir aussi

• Désignations d’audiences adjacentes au PHI — la référence endpoint pour le contrat du registre (plafond, sémantique de remplacement, action d’audit)
• Contrôles de compliance HIPAA — la référence de contrôle complète que le registre alimente
• BAA — Business Associate Agreement — le cycle de vie que le precheck de lancement fait respecter
• Onboarding HIPAA : du BAA à audit-ready — la séquence qui amène un workspace santé à audit-ready avant que vous ne désigniez des audiences
• Send gates — le gate par destinataire qui complète le precheck de lancement