> ## 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. # HIPAA-Compliance-Steuerungen für Nachrichten im Gesundheitswesen > Vom Mandanten getragene HIPAA-Haltung: ein Opt-in-Schalter des Workspace-Inhabers, die BAA-vorgeschriebenen desk-seitigen Umschläge, die er als Mandantensteuerungen dokumentiert, die Rollen-versus-Oberflächen-Matrix und die PHI-Audit-Zeile, die in den DPA-Verarbeitungsverzeichnis-Katalog eingeht. # HIPAA-Compliance Die Compliance-Haltung liegt in Ihrer Verantwortung — Devotel Orbit liefert standardmäßig offen. Der HIPAA-Modus ist ein **Opt-in-Schalter je Organisation** für Organisationen, die geschützte Gesundheitsdaten (PHI) verarbeiten: ein Workspace-Inhaber aktiviert ihn, und er bleibt ausgeschaltet, sofern Sie ihn nicht anfordern. Devotel schreibt den HIPAA-Modus niemals vor und entscheidet nicht, dass Ihr Verkehr „konform" wäre — die Aktivierung des Schalters aktiviert die von Orbit BAA-geskarteten Sicherheitsmaßnahmen, und die damit geöffneten Gates sind Mandantensteuerungen, die Sie betreiben. Dieses Dokument beschreibt die technischen und administrativen Steuerungen, die bei aktiviertem HIPAA-Modus gelten. *** ## Übersicht Der HIPAA-Modus ist ein **Opt-in-Schalter je Organisation** — keine plattformseitig vorgeschriebene Haltung. Nur ein Workspace-`owner` kann ihn schalten; der Schalter ist aus, bis Sie handeln, und BAA-geskartet: Er aktiviert (oder lockert) einen Satz erweiterter Steuerungen, und kein Versand oder Zugriff trägt PHI-spezifische Regeln, es sei denn, Sie haben sich angemeldet: 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 Die desk-seitig empfangbaren Umschläge `HIPAA_BAA_REQUIRED` und `HIPAA_BAA_INVALID` sind dokumentenebene Mandantensteuerungen, in die Sie sich einloggen und die Sie besitzen — dasselbe Urteil und dasselbe Fail-closed-Verhalten wie unter [BAA — das HIPAA-Send-Gate](/compliance/send-gates#baa-the-hipaa-send-gate) beschrieben. Sie sind keine Plattform-Mandate. ## Wer kann was HIPAA-Steuerungen sind Rollen zugeordnet, sodass Sie jede Oberfläche den Personen in Ihrem Workspace zuordnen können. (Diese Spalten entsprechen dem Prosa in den nachfolgenden Abschnitten.) | Rolle | Nachrichteninhalte lesen | PHI-Zugriffsprotokoll lesen | BAA schreiben | HIPAA-Modus aktivieren/deaktivieren | | ----------- | ------------------------ | --------------------------- | ------------- | ----------------------------------------------------- | | `owner` | Ja | Ja | Ja | Ja (Deaktivieren erfordert erneute Authentifizierung) | | `admin` | Ja | Ja | Nein | Nein | | `developer` | Ja | Nein | Nein | Nein | | `viewer` | Ja | Nein | Nein | Nein | | `billing` | Nein | Nein | Nein | Nein | ## Voraussetzungen Vor der Aktivierung des HIPAA-Modus müssen Organisationen: 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 Alle PHI — einschließlich der Nachrichten-`body`, `media_url` und Metadaten — werden im Ruhezustand mit **von Google verwalteten AES-256** Schlüsseln verschlüsselt (Cloud-SQL-Standardverschlüsselung): * **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](#infrastructure-safeguards)) > **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 Lesen von Nachrichteninhalten wird durch die Workspace-Mitgliedschaft und, bei API-Schlüsseln, durch den `messages:read` / `messages:write`-Scope gesteuert. Jeder Lesevorgang wird im [PHI-Audit-Protokoll](#3-phi-audit-log) aufgezeichnet. Die folgende Tabelle zeigt, wer heute Nachrichteninhalte lesen kann: | Rolle | Nachrichteninhalte lesen | Hinweise | | ----------- | ------------------------ | -------------------------------------------------------------------------------------- | | `owner` | Ja | Kann den HIPAA-Modus aktivieren/deaktivieren und PHI-Zugriffsprotokolle einsehen | | `admin` | Ja | Kann PHI-Zugriffsprotokolle einsehen | | `developer` | Ja | Jeder Lesevorgang wird im PHI-Zugriffsprotokoll aufgezeichnet | | `viewer` | Ja | Jeder Lesevorgang wird im PHI-Zugriffsprotokoll aufgezeichnet | | `billing` | Nein | Auf finanzielle Oberflächen beschränkt; erhält `403` auf Nachrichteninhalts-Endpunkten | Die Rolle `billing` ist auf finanzielle Oberflächen beschränkt — Abrechnung, Preise und Nutzungseinblicke — und kann Nachrichteninhalte nicht lesen. Jede andere Rolle, einschließlich `viewer`, kann Nachrichteninhalte lesen, und jeder Zugriff wird in das PHI-Zugriffsprotokoll geschrieben. Begründungscodes werden bei jedem PHI-Zugriffsprotokolleintrag gespeichert. Lesen über `GET /messages` und `GET /messages/{id}` wird mit einem automatischen `read`-Begrundung aufgezeichnet. Die nachstehenden Kategorien beschreiben die Zugriffsbegründungen, die an anderen Stellen der Plattform verwendet werden, wenn ein Betreiber sie ausdrücklich angibt: * `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](mailto:compliance@devotel.io). ### 3. PHI-Audit-Protokoll Jeder Zugriff auf PHI-haltige Daten generiert einen Audit-Protokolleintrag. Dieses Protokoll ist eine Zeile im Verarbeitungsverzeichnis-Katalog, den Ihre Organisation unterhält — die [Data Processing Agreement](/compliance/data-processing-agreement)-Seite ist der vorgelagerte Katalog dieser Aufzeichnungen und der Attestierungen, die sie binden: ```json theme={null} { "id": "phi_abc123", "userId": "usr_xyz789", "resource": "message:msg_def456", "reason": "treatment", "accessedAt": "2026-04-02T10:30:00Z" } ``` Das PHI-Zugriffsprotokoll: * 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 **API-Endpunkt**: `GET /api/v1/settings/hipaa/phi-access-log` ### 4. Datenaufbewahrung Bei aktiviertem HIPAA-Modus wird die Datenaufbewahrung durchgesetzt: * **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 **Konfiguration**: Über das Dashboard unter **Einstellungen → Compliance → HIPAA → Datenaufbewahrung** oder über die API: ```bash theme={null} PUT /api/v1/settings/hipaa { "enabled": true, "data_retention_days": 365 } ``` **Das Aktivieren** des HIPAA-Modus ist ein einzelner Aufruf — es verschärft die Sicherheitshaltung des Workspace, daher ist keine erneute Authentifizierungsaufforderung erforderlich (eine unterzeichnete BAA ist dennoch Pflicht; siehe unten). **Das Deaktivieren** des HIPAA-Modus ist destruktiv und erfordert den zweistufigen erneute-Authentifizierung-Ablauf, der unter [Deaktivieren des HIPAA-Modus](#6-disabling-hipaa-mode) beschrieben ist. ### 5. BAA-Status-Lebenszyklus Devotel verfolgt den BAA-Status je Organisation auf einem kanonischen `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 Jede ausgeführte BAA erfasst ihre Vorlageversion, den Namen und die E-Mail des Unterzeichners, den Ausführungszeitstempel und das Laufzeitende. **Anforderung**: Der HIPAA-Modus **kann nicht aktiviert werden**, bis `baa_status` `executed` ist. Der Versuch, den HIPAA-Modus vorher zu aktivieren, gibt einen `403 Forbidden`-Fehler zurück, und jeder PHI-Versand wird mit `422 HIPAA_BAA_REQUIRED` abgelehnt. Das Urteil des Sende-Zeit-Gates und dessen Fail-closed-Verhalten sind unter [BAA — das HIPAA-Send-Gate](/compliance/send-gates#baa-the-hipaa-send-gate) dokumentiert. #### Ausführen der BAA Führen Sie die BAA über die `/api/v1/compliance/baa`-Endpunkte aus. Dies ist der Ablauf, den das Dashboard-Pane **Compliance → BAA** verwendet, und der einzige Ablauf, der die HIPAA-Aktivierungs- und PHI-Sende-Gates erfüllt. 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. ```bash theme={null} 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. ```bash theme={null} POST /api/v1/compliance/baa/execute { "signer_name": "Jane Roe", "signer_email": "jane@example.com", "typed_attestation": "Jane Roe" } ``` Um die Vereinbarung vor der Unterzeichnung einzusehen, rufen Sie `GET /api/v1/compliance/baa/template` auf. > **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`. > > ```bash theme={null} > 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 Das PHI-nahe Zielgruppenregister ist ein **organisationsweites Register von Kontaktlisten- und Segment-IDs, deren Mitglieder PHI tragen** — zum Beispiel Patienten, die in die Behandlungsansprache eingewilligt haben. Die Kennzeichnung gehört zur Zielgruppe selbst, nicht zu einer einzelnen Kampagne: Eine Zielgruppe ist PHI-nah aufgrund ihrer Quelldaten, sodass die Kennzeichnung ihr folgt, unabhängig davon, welche Kampagne sie aufnimmt. Wenn HIPAA für Ihre Organisation im Umfang liegt (`hipaa_required` über den [BAA-Ablauf](#5-baa-status-lifecycle) gesetzt) und die Zielgruppe einer Kampagne zu einer gekennzeichneten Listen- oder Segment-ID auflöst, verweigert der [Kampagnenstart-Vor-Check](#kampagnen-start-vor-check) den Start, bis Ihre BAA `executed` und in der Laufzeit ist. **API**: `GET /api/v1/compliance/hipaa/phi-audiences` gibt das auf Ihre Organisation beschränkte aktuelle Register zurück. `PUT /api/v1/compliance/hipaa/phi-audiences` ersetzt das Register in einem einzelnen Schreibvorgang. Beide Endpunkte erfordern die `owner`- oder `admin`-Rolle — dasselbe Gate wie für die BAA-Endpunkte. **Lesen des Registers:** ```bash theme={null} GET /api/v1/compliance/hipaa/phi-audiences ``` ```json theme={null} { "audience_ids": ["list_9f2c1a", "seg_4b7e20"], "max": 500 } ``` **Ersetzen des Registers:** ```bash theme={null} PUT /api/v1/compliance/hipaa/phi-audiences { "audience_ids": ["list_9f2c1a", "seg_4b7e20"] } ``` Das PUT ist ein **vollständiger Ersatz** der gekennzeichneten IDs — es gibt keinen DELETE-Endpunkt. Um eine Kennzeichnung aufzuheben, PUT das Register ohne diese ID; zum Wieder-Kennzeichnen PUT es mit der ID wieder hinzugefügt. Jedes Element ist ein Zielgruppen-ID-String (1–128 Zeichen), bis zu **500** IDs je Organisation. Ein `PUT` mit einem leeren `audience_ids`-Array löscht das Register. Jeder Ersatz wird atomar geschrieben (ein gleichzeitiger GET sieht nie eine Teilaktualisierung) und im Audit-Protokoll protokolliert. > **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 Kampagnen haben **zwei** HIPAA-Gates an verschiedenen Punkten des Ablaufs: 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](/compliance/send-gates#baa-the-hipaa-send-gate) dokumentierte Send-Gate gilt zur Nachrichtenzeit weiterhin und bleibt unverändert. Der Vor-Check wertet dieselben BAA-Regeln wie das pro-Empfänger-Gate aus, sodass die beiden nie uneinig sind, was „BAA in der Laufzeit" bedeutet. **Dashboard-Oberfläche:** Im Zielgruppenschritt des Kampagnen-Assistenten zeigt die Wahl einer gekennzeichneten Liste oder eines Segments eine beratende Warnung — *„Diese Zielgruppe ist als PHI-nah gekennzeichnet. Der Start erfordert eine ausgeführte Business Associate Agreement (BAA) — prüfen Sie ihren Status unter Einstellungen → Compliance → BAA."* Die Warnung ist beratend: Sie blockiert die **Weiter**-Schaltfläche nicht, weil die Kennzeichnung (oder die BAA ausgeführt) vor dem tatsächlichen Start aufgehoben worden sein könnte. Das harte Gate liegt beim Start. **Die Verweigerungsantwort:** ```json theme={null} { "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." } } ``` **Betreibersequenz — ein vom Vor-Check verweierter Start:** 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](#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. **Beschränkungen:** * 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 Das Deaktivieren des HIPAA-Modus ist ein **destruktiver, audit-sensitive** Übergang: Es löscht das Covered-Entity-Flag, die BAA-Verknüpfung und die strikte Aufbewahrungsfloor auf einem Workspace, der möglicherweise PHI hält. Um zu verhindern, dass dies bei einer gestohlenen Browsersitzung geschieht, erfordert das Deaktivieren eine **frische erneute Authentifizierungsaufforderung**. (Das Aktivieren des HIPAA-Modus tut dies *nicht* — es verschärft nur die Haltung.) Das Deaktivieren ist daher ein **zweistufiger** Ablauf: **Schritt 1 — Ein single-use erneute Authentifizierungs-Challenge-Token erstellen:** ```bash theme={null} POST /api/v1/settings/hipaa/reauth-challenge ``` Die Antwort gibt ein kurzlebiges (5-Minuten), single-use Token zurück: ```json theme={null} { "challenge_token": "h7Yc...base64url...", "expires_at": "2026-04-02T10:35:00Z" } ``` **Schritt 2 — Die Deaktivierungsanfrage mit dem `X-Reauth-Challenge`-Header auf dieses Token senden:** ```bash theme={null} PUT /api/v1/settings/hipaa X-Reauth-Challenge: h7Yc...base64url... { "enabled": false } ``` Das Token muss **innerhalb von 5 Minuten** eingelöst und nur **einmal** genutzt werden. Wenn der `X-Reauth-Challenge`-Header fehlt, fehlerhaft oder abgelaufen ist, wird die Deaktivierungsanfrage mit `401 REAUTH_REQUIRED` abgelehnt: ```json theme={null} { "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 | Methode | Endpunkt | Beschreibung | Erforderliche Rolle | | ------- | ---------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------- | | `GET` | `/settings/hipaa` | HIPAA-Status und Konfiguration abrufen | `admin+` | | `PUT` | `/settings/hipaa` | HIPAA-Modus aktivieren/deaktivieren (Deaktivieren erfordert `X-Reauth-Challenge`) | `owner` | | `POST` | `/settings/hipaa/reauth-challenge` | Ein single-use erneute Authentifizierungs-Token zum **Deaktivieren** des HIPAA-Modus erstellen | `owner` | | `GET` | `/settings/hipaa/phi-access-log` | Paginiertes PHI-Zugriffsprotokoll | `admin+` | | `GET` | `/compliance/baa/` | Aktuellen BAA-Zustand abrufen (`baa_status`, Unterzeichner, Ablauf) | `admin+` | | `GET` | `/compliance/baa/template` | Die BAA-Vereinbarung vor der Unterzeichnung einsehen | `admin+` | | `POST` | `/compliance/baa/require` | Attestieren, dass PHI im Umfang liegt und den Ausführungsablauf öffnen | `owner` | | `POST` | `/compliance/baa/execute` | Die BAA via E-Signatur mit getipptem Namen ausführen | `owner` | | `GET` | `/compliance/hipaa/phi-audiences` | Das PHI-nahe Zielgruppenregister lesen | `admin+` | | `PUT` | `/compliance/hipaa/phi-audiences` | Das PHI-nahe Zielgruppenregister ersetzen (Vollersatz-Schreiben) | `owner`/`admin` | | `PUT` | `/settings/hipaa/baa` | **Legacy** — vormigrierter BAA-Statusspiegel; ignoriert, sobald `baa_status` gesetzt ist | `owner` | *** ## Dashboard-Konfiguration HIPAA-Einstellungen sind im Dashboard unter **Einstellungen → Compliance** verfügbar: 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 Über die anwendungsebene Steuerungen hinaus bietet Devotels Infrastruktur: * **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 Live-Untertitel, Anruftranskripte und Nach-Anruf-Transkripte werden von Devotels Sprach-zu-Text-Subprozessor mit standardmäßig aktivierter PII/PHI-Schwärzung generiert. Sensible Numeriken — Kreditkartennummern, Sozialversicherungsnummern und Ähnliches — werden an der Quelle maskiert, bevor Transkripttext gespeichert oder in Protokolle geschrieben wird. Für HIPAA-Organisationen bedeutet dies, dass im Anruf gesprochene PHI geschwärzt wird, bevor sie persistent wird. ### Schwärzung ist standardmäßig aktiviert Die Transkript-Schwärzung ist standardmäßig aktiviert und kann nicht von Ihrem Dashboard oder Ihrer API ausgeschaltet werden. Das Ausschalten ist eine deploymentsweite Änderung, die Devotel nur für Archiv-Compliance-Vertikale (z. B. Recht oder Gesundheitswesen) vornimmt, die vertraglich verpflichtet sind, *rohe*, ungeschwärzte Transkripte unter eigenen Sicherheitsmaßnahmen und BAA aufzubewahren. > **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. Wenn die Roh-Transkript-Aufbewahrung jemals für Ihr Deployment aktiviert war, wurden Transkripte, die während dieses Fensters erfasst wurden, ungeschwärzt gespeichert und werden **nicht** rückwirkend maskiert. Überprüfen und löschen Sie diese gemäß Ihrer Aufbewahrungsrichtlinie, falls sie PHI enthalten, und bitten Sie Devotel, zu bestätigen, dass die Schwärzung für alle weiteren Transkripte wieder aktiviert ist. *** ## Geteilte Verantwortung HIPAA-Compliance ist eine geteilte Verantwortung zwischen Devotel und dem Kunden: | Verantwortung | Devotel | Kunde | | ------------------------------------------------------------------------------------ | ------- | ----- | | Infrastruktursicherheit | ✅ | | | Datenverschlüsselung im Ruhezustand | ✅ | | | Datenverschlüsselung im Transit | ✅ | | | Zugriffssteuerungs-Durchsetzung | ✅ | | | PHI-Zugriffsprotokollierung | ✅ | | | Transkript-PII/PHI-Schwärzung (standardmäßig aktiviert) | ✅ | | | Bestätigen, dass die Transkript-Schwärzung aktiviert ist, bevor PHI gespeichert wird | | ✅ | | BAA-Ausführung | ✅ | ✅ | | Personal-Schulung | | ✅ | | Verfahren zur Meldung von Verletzungen | ✅ | ✅ | | PHI-Minimum-Necessary-Standard | | ✅ | | Patienteneinwilligungsverwaltung | | ✅ | | Risikobewertung | ✅ | ✅ | *** ## Vorfallreaktion Im Fall einer vermuteten PHI-Verletzung: 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](/compliance/dlp-scanner) — die Sende-Zeit-Steuerung, die regulierte Daten markiert, die eine ausgehende Nachricht überschreiten * [Sende-Vor-Richtlinien-Scanner](/compliance/policy-scanner) — das Urteil und der Durchsetzungsmodus, dem diese Steuerung zufließt *** *Zuletzt aktualisiert: April 2026* *Bei Fragen zur HIPAA-Compliance wenden Sie sich an: [compliance@devotel.io](mailto:compliance@devotel.io)*