​

PHI’ye yakın kitleleri kaydet

​

1. Bir kitle ne zaman PHI’ye yakın olarak işaretlemeli

• Üyeleri PHI tutan bir sistemden import edildi (bir EHR exportu, bir hasta portalı opt-in senkronizasyonu).
• Liste veya segment PHI taşıyan kriterlere filtrelenmiş veya toplanmış (tanı-yakın etiketler, tedavi kohortleri).
• Compliance sorumlunuzun veri haritası kitleyi PHI kapsamında kaydeder.

​

2. Liste vs. segment id’leri seçin

# Contact list'leri
GET /api/v1/contacts/lists

# Segment'ler
GET /api/v1/contacts/segments

Kaynak id’sini belirleyin, bir downstream kopya değil. Bir PHI taşıyan liste bir türetilmiş segment besliyorsa, türetilmiş segment’nin PHI içerip içermediğine karar verin ve onu açıkça belirleyin — ön-denetim kampanyanın gerçekten başvurduğu id’yi kontrol eder, başka hiçbir şey değil.

​

3. Atomik PUT değişimi

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. Başlatma ön-denetiminin registry’i nasıl kullandığı

1. Başlatma ön-denetimi (kampanya seviyesi, katı gate). Bir kampanya taslak/programlamadan çıkmadan önce, ön-denetim kitle id’sini registry’ye karşı çözümleyebilir. Belirlenmiş bir id ve terim içinde olmayan bir BAA başlatmayı 422 HIPAA_BAA_REQUIRED ile reddeder — tek bir recipient kaydolmadan önce. Uyumluluk durumu okunamıyorsa, ön-denetim kitleyi sessizce kabul etmek yerine 500 HIPAA_BAA_GATE_DB_FAIL ile kapalı hata verir.
2. Recipient-başı send gate’i (mesaj zamanı, değiştirilmemiş). Mevcut send gate’i her bireysel gönderime hâlâ uygulanır ve registry’ye başvurmaz — tek seferlik gönderimler sadece onunla yönetilir.

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

• BAA’yı çözün — gate’in geçmesi için yürütün veya yeniden yürütün. Kitle gerçekten PHI taşıyorsa bu doğru yoldur.
• Belirlemeyi kaldırın — registry’i kitle id’si olmadan PUT. Bu doğru yoldur sadece kitlege hatalı belirlendiyse. Gate’i atlatmak için bir belirlemenin kaldırılması kendi audit log’unuzda görünürdür.

​

5. Audit izi

• hipaa.phi_audiences.set — her PUT için bir satır, işlem yapan kullanıcıyı, organizasyonu ve tam post-yazma id kümesini kaydet. Bu versiyon hikayeniz: registry ayrı bir revision resource’una sahip değil — audit satırlarının dizisi versiyon geçmişi. Belirli bir noktada belirlendiğini yeniden çıkarmak için set satırını geri okuyun; geri almak için önceki bir satırın id kümesini PUT.
• HIPAA_BAA_REQUIRED başlatma reddi — her engellenen başlatma, reddinen neden ve değerlendirilen kitle ile loglanır. Bu satırlar olay sıranızı da iki misli olarak katlar: bir red ya da uyumluluk işi bekliyor (BAA yürütülmemiş) veya bir belirleme ve bir kampanya anlaşmıyor.

1. Reddın details.reason’ını ve details.audience.id’sini okuyun.
2. GET /api/v1/compliance/baa/ kontrol edin — BAA pending/expired/yürütülmemişse, BAA akışı ile çözün.
3. BAA sağlıkliysa, kitlege kitesinin belirlenmesi gerekip gerekmediğini kontrol edin: GET /api/v1/compliance/hipaa/phi-audiences ve veri haritanızla karşılaştırın. Hatalı bir belirlemeyi swap ile kaldırın (PUT id olmadan).
4. Sonucu kendi olay kayıt defterinizde kaydedin — yukarıdaki audit satırları gösterdiğiniz deliktir.

​

6. Eşzamanlı yazma çatışmaları giderme

• Operatör A ve operatör B her ikisi de GET yapar.
• A list_aaa ekler ve PUT. B — A öncesi snapshot’tan çalışarak — list_bbb ekler ve PUT.
• B’nin swap’ı list_aaa’yı sessizce düşürür.

• Yazmadan hemen önce oku. Read-modify-write penceresini kısa tutun; getirilmiş registry’yi bir düzenleme oturumu boyunca taşımayın — PUT için hazır olduğunuzda tekrar GET.
• Yazmadan sonra doğrula. Bir kez daha GET ve id’nizin mevcut olduğunu ve ilgisiz bir belirlemenin kaybolmadığını onaylayın. Bir şey kaybolsa, audit log’unun hipaa.phi_audiences.set satırları kimin yazmada kimin üzerine yazdığı ve hangi kümeyi geri getirdiğini göster.
• Registry düzenlemeleri organizasyonel olarak sıralandırın. Belirleme compliance attestasyonu olduğu için, düzenlemeleri bir rol’den (compliance sorumlusu) geçir, operatörler arasında yaymama unorumdan — race’i tamamen kaldıran bir prosedürevi fix.

​

Ayrıca bkz.

• PHI’ye yakın kitle belirlemeleri — registry sözleşmesinin endpoint referansı (tavan, replacement semantics, audit action)
• HIPAA uyumluluk kontrolleri — registry’nin beslediği tam kontrol referansı
• BAA — Business Associate Agreement — başlatma ön-denetiminin zorladığı yaşam döngüsü
• HIPAA onboarding: BAA’dan audit hazırlığına — kitleleri belirlemeden önce sağlık workspace’ini audit hazırlığına getiren sıra
• Send gate’ler — başlatma ön-denetimini tamamlayan recipient-başı gate