​

HIPAA-Compliance

​

Übersicht

1. Verschlüsselung im Ruhezustand — PHI im Ruhezustand mit von Google verwaltetem AES-256 verschlüsselt (Cloud-SQL-Standard)
2. Zugriffssteuerungen — PHI-Zugriff auf bestimmte Rollen beschränkt
3. Audit-Protokollierung — Jeder PHI-Zugriff mit Begründungscodes protokolliert
4. Datenaufbewahrung — Automatische Löschung nach der konfigurierten Aufbewahrungsfrist
5. BAA-Verfolgung — Verwaltung des Status der Business Associate Agreement

​

Wer kann was

​

Voraussetzungen

1. Eine Business Associate Agreement (BAA) mit Devotel abschließen
2. Einen HIPAA-Compliance-Beauftragten innerhalb ihres Teams benennen

​

Technische Steuerungen

​

1. Verschlüsselung im Ruhezustand

• Algorithmus: AES-256 (Google Cloud Standard-Ruhezustandsverschlüsselung)
• Schlüsselverwaltung: Verschlüsselungsschlüssel werden von Google Cloud verwaltet und rotiert
• Umfang: Alle datenbankgespeicherten Inhalte, einschließlich der Nachrichten-body, media_url und Metadaten
• Im Transit: TLS 1.3 schützt alle Daten im Transit (siehe Infrastruktur-Sicherheitsmaßnahmen)

Hinweis: Devotel führt derzeit keine organisationsbezogene anwendungsebene Verschlüsselung von Nachrichtentexten durch. Die PHI-Vertraulichkeit im Ruhezustand beruht auf der transparenten AES-256-Verschlüsselung von Google Cloud statt auf einem anwendungsebene Cipher. Die GET /settings/hipaa-Antwort enthält ein encryption_algorithm-Feld nur zu Berichtzwecken — es zeigt nicht an, dass Nachrichtentexte einzeln auf der Anwendungsebene verschlüsselt sind.

​

2. Zugriffssteuerungen

• treatment — Zugriff für Koordinierung der Patientenbehandlung erforderlich
• payment — Zugriff für Zahlungsabwicklung erforderlich
• operations — Zugriff für Gesundheitsvorgänge erforderlich
• legal — Zugriff für rechtliche Compliance erforderlich
• support — Zugriff für Kundensupport-Auflösung erforderlich

Bekannte Einschränkung: Orbit beschränkt das Lesen von Nachrichteninhalten derzeit nicht auf eine engere Rollengruppe über die obige billing-Einschränkung hinaus, und verlangt auf den Nachrichten-Endpunkten (GET /messages, GET /messages/{id}) keine vom Betreiber angegebenen Begründungscode. Um dem HIPAA-Minimum-Necessary-Standard zu entsprechen, stellen Sie Workspace-Mitgliedschaft und API-Schlüssel-Scopes so bereit, dass nur Personal, das PHI benötigt, diese Endpunkte erreichen kann. Wenn Ihr Programm eine rollenbezogene Leseeinschränkung für Nachrichteninhalte erfordert, wenden Sie sich vor dem Vertrauen darauf an compliance@devotel.io.

​

3. PHI-Audit-Protokoll

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

• Ist nur anfügbar und kann nicht verändert oder gelöscht werden
• Speichert bis zu 10.000 Einträge je Organisation (älteste Einträge werden automatisch rotiert)
• Ist für owner- und admin-Rollen über das Dashboard oder die API zugänglich
• Kann für externe Compliance-Audits exportiert werden

​

4. Datenaufbewahrung

• Standardaufbewahrungsfrist: 365 Tage (konfigurierbar: 30–3.650 Tage)
• Umfang: Nachrichteninhalte, Anrufaufzeichnungen, Medienanhänge
• Mechanismus: Automatischer Hintergrundjob scannt auf abgelaufene Datensätze und löscht diese sicher
• Ausnahmen: Audit-Protokolle und PHI-Zugriffsprotokolle werden unabhängig von der Datenaufbewahrungsrichtlinie aufbewahrt

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

​

5. BAA-Status-Lebenszyklus

• not_required — die Organisation hat attestiert, dass keine PHI im Umfang liegt (der Standard)
• pending — PHI liegt im Umfang und die BAA wartet auf Ausführung
• executed — die BAA wurde unterzeichnet und liegt innerhalb ihrer Laufzeit
• expired — eine ausgeführte BAA hat ihre einjährige Laufzeit überschritten und muss erneut ausgeführt werden

​

Ausführen der BAA

1. Den aktuellen Zustand prüfen — GET /api/v1/compliance/baa/ gibt baa_status, die Unterzeichnerdetails und days_until_expiry zurück (owner/admin).
2. Attestieren, dass PHI im Umfang liegt — POST /api/v1/compliance/baa/require setzt hipaa_required und bewegt eine not_required-Organisation zu pending, sodass sich der Ausführungsschritt öffnet (nur owner). Dies startet den Ablauf; es aktiviert nicht den HIPAA-Modus.

POST /api/v1/compliance/baa/require
{
  "reason": "We began storing patient appointment reminders that contain PHI."
}

3. Die BAA ausführen — POST /api/v1/compliance/baa/execute erfasst die Vereinbarung mit einer Click-wrap-E-Signatur mit getipptem Namen (nur owner). Die typed_attestation muss signer_name exakt entsprechen. Bei Erfolg wird die Organisation als executed mit Unterzeichner, Version und Datum gestempelt, was PHI-Sendungen entsperrt und das Aktivieren des HIPAA-Modus ermöglicht.

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

Legacy-Endpunkt: PUT /api/v1/settings/hipaa/baa (Body { signed, signed_at, document_url }) schreibt einen älteren JSONB-Statusspiegel und ist ein Fallback nur für vormigrierte Mandanten. Sobald eine Organisation einen baa_status-Wert hat, lesen die HIPAA-Aktivierungs- und PHI-Sende-Gates diese kanonische Spalte und ignorieren diesen Spiegel — ein signed: true-Schreiben hier entsperrt also nicht Sendungen oder den HIPAA-Modus. Verwenden Sie stattdessen 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"
}

​

PHI-nahes Zielgruppenregister

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

Hinweis: Das Register ist die Attestierung Ihrer Organisation darüber, welche Zielgruppen PHI enthalten. Es ist mandatemneigen: Devotel kennzeichnet Zielgruppen niemals auf Ihre Rechnung, und die Kennzeichnung tritt erst in Kraft, sobald HIPAA für Ihre Organisation im Umfang liegt.

​

Kampagnenstart-Vor-Check

1. Start-Vor-Check (Kampagnenebene, hartes Gate). Bevor eine Kampagne den Entwurfs-/Geplant-Zustand verlässt, löst der Start-Vor-Check ihre Zielgruppe gegen das Register auf. Wenn die Zielgruppe eine gekennzeichnete Liste oder ein Segment und die BAA Ihrer Organisation nicht executed und in der Laufzeit ist, wird der Start mit 422 HIPAA_BAA_REQUIRED verweigert. Dies hält eine PHI-Kohorte aus der Kampagnenaufnahme, statt Wallet-Guthaben für Tausende von Empfängerverweigerungen zu verbrennen. Wenn der Compliance-Zustand nicht lesbar ist, versagt der Vor-Check geschlossen (500 HIPAA_BAA_GATE_DB_FAIL) statt eine PHI-Zielgruppe schweigend zuzulassen.
2. Send-Gate (pro Empfänger, bestehendes Verhalten). Das pro Empfänger unter BAA — das HIPAA-Send-Gate dokumentierte Send-Gate gilt zur Nachrichtenzeit weiterhin und bleibt unverändert.

{
  "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. Das Register zusammenstellen — PUT /api/v1/compliance/hipaa/phi-audiences mit den Listen-/Segment-IDs, die PHI enthalten.
2. Die Blockierung verifizieren — den Start gegen eine gekennzeichnete Zielgruppe versuchen; erwarten Sie 422 HIPAA_BAA_REQUIRED, solange die BAA nicht executed/in der Laufzeit ist.
3. Die BAA auflösen — eine expired-BAA ausführen (oder erneut ausführen) via POST /api/v1/compliance/baa/execute, wie unter Ausführen der BAA beschrieben.
4. Erneut starten — sobald die BAA executed und in der Laufzeit ist, passiert der Vor-Check und die Kampagne startet normal.

• Das Register regiert nur Kampagnenstarts. Legacy-Einzelversendungen pro Empfänger werden weiterhin vom pro-Empfänger-Send-Gate geregelt, das das Register nicht konsultiert.
• Nur list- und segment-Typ-Zielgruppen lösen beim Start gegen das Register auf. Pro-Kontakt-assemblierte Zielgruppen (alle Kontakte, CSV, manuelle Eingabe) werden zur Sendezeit empfängerweise bewertet.
• Die PHI-nahe Warnung des Assistenten ist beratend im Zielgruppen-Picker; die Durchsetzung liegt beim Start.

​

6. Deaktivieren des HIPAA-Modus

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

Hinweis: Die erneute Authentifizierungs-Challenge gated nur den Aktivieren → Deaktivieren-Übergang. Das Aktivieren des HIPAA-Modus und nur-Rückhalte-Updates, die während bereits deaktiviertem HIPAA-Modus eingereicht werden, erfordern den Header nicht.

​

API-Referenz

​

Dashboard-Konfiguration

1. HIPAA-Modus-Schalter — HIPAA-Modus aktivieren/deaktivieren (erfordert BAA)
2. BAA-Abschnitt — Die BAA (E-Signatur mit getipptem Namen) ausführen und ihren Status, Unterzeichner und Laufzeitende verfolgen
3. Datenaufbewahrung — Die Frist für automatische Datenlöschung konfigurieren
4. PHI-Zugriffsprotokoll — Das PHI-Zugriffs-Audit-Protokoll einsehen und exportieren
5. PHI-nahe Zielgruppen — Kennzeichnen, welche Kontaktlisten und Segmente PHI tragen; der Kampagnen-Assistent warnt bei gekennzeichneten Zielgruppen und der Start-Vor-Check setzt das BAA-Gate durch

​

Infrastruktur-Sicherheitsmaßnahmen

• Cloud-SQL-Verschlüsselung: Alle Datenbankspeicher mit AES-256 von Google Cloud verschlüsselt
• TLS 1.3: Alle Daten im Transit mit TLS 1.3 verschlüsselt
• VPC-Isolation: Datenbank nur über private IP innerhalb der VPC erreichbar
• Keine privilegierten Container: GKE Autopilot verhindert Ausführung privilegierter Container
• Secret Manager: Alle Verschlüsselungsschlüssel und Anmeldedaten in GCP Secret Manager gespeichert
• Audit-Trails: Google Cloud Audit Logs für infrastrukturebenen Zugriffsverfolgung

​

Sprach- & Videotranskript-PII/PHI-Schwärzung

​

Schwärzung ist standardmäßig aktiviert

Warnung: Da diese Steuerung ein ganzes Deployment statt einer einzelnen Organisation betrifft, kann sie nicht auf einen Workspace beschränkt werden. Wenn Ihr Deployment PHI verarbeitet, sollte die Schwärzung aktiviert bleiben — bestätigen Sie ihren Status schriftlich mit Ihrem Devotel-Kontakt im Rahmen Ihrer BAA, bevor Sie PHI speichern.

​

Geteilte Verantwortung

​

Vorfallreaktion

1. Devotels Sicherheitsteam wird innerhalb von 1 Stunde über automatische Alarmierung benachrichtigt
2. Betroffene Organisationen werden innerhalb von 24 Stunden gemäß HIPAA Breach Notification Rule benachrichtigt
3. PHI-Zugriffsprotokolle werden sofort aufbewahrt und für die forensische Analyse exportiert
4. Sanierungsschritte werden dokumentiert und mit betroffenen Parteien geteilt

​

Verwandte Seiten

• DLP-Scanner — die Sende-Zeit-Steuerung, die regulierte Daten markiert, die eine ausgehende Nachricht überschreiten
• Sende-Vor-Richtlinien-Scanner — das Urteil und der Durchsetzungsmodus, dem diese Steuerung zufließt