HIPAA-Checkliste für die Softwareentwicklung — Privacy Rule, Security Rule, BAA

Sophie Laurent Legal & Compliance Lead, YuSMP Group · Praktikerin für DSGVO, HIPAA und EU AI Act

Gilt HIPAA für mich? CE, BA und die HITECH-Erweiterung

HIPAA (Public Law 104-191, 1996) und seine Vorschriften in 45 CFR Parts 160 und 164 gelten unmittelbar für Covered Entities (CEs): Krankenversicherungen, Healthcare-Clearinghouses und Gesundheitsdienstleister, die Gesundheitsinformationen in elektronischer Form im Zusammenhang mit einer Transaktion übermitteln, für die HHS einen Standard verabschiedet hat (Definition in 45 CFR 160.103).

Der HITECH Act von 2009 und die Omnibus Rule von 2013 haben den Großteil der Privacy Rule und die gesamte Security Rule unmittelbar auf Business Associates (BAs) ausgeweitet — jede Person oder Entität, die Protected Health Information im Auftrag eines CE erstellt, empfängt, vorhält oder übermittelt. Zu den BAs zählen Cloud-Anbieter, SaaS-Anbieter, Abrechnungsdienstleister, Transkriptionsdienste, Datenanalyse-Firmen und nun — gemäß HHS-Sub-Regulatory-Guidance — KI-Inferenz-Anbieter, wenn PHI durchläuft.

Wenn Sie Software ausliefern, die Protected Health Information berührt, sind Sie mit hoher Wahrscheinlichkeit ein Business Associate. Der HHS-Test ist funktional: Haben Sie im Rahmen der Leistungserbringung für ein CE Zugriff auf PHI? Falls ja, gelten der BA-Status und die BAA-Pflicht, unabhängig von der vertraglichen Bezeichnung.

Beachten Sie die Ausnahme für den „Conduit“-Status (HHS-Guidance, 2013): Reine Übertragungsdienste (ISPs, Postdienste), die nur vorübergehend auf PHI zugreifen, sind keine BAs. Cloud-Anbieter qualifizieren sich gemäß derselben Guidance ausdrücklich nicht für die Conduit-Ausnahme, da sie PHI auch nur kurzzeitig speichern.

Strafstufen 2026 und die HHS-Durchsetzungshaltung

Zivilrechtliche Geldbußen nach 45 CFR 160.404, inflationsbereinigt im Federal-Register-Update 2024, folgen einer abgestuften Verschuldensskala. Die Werte für 2026 gemäß der jüngsten HHS-Anpassung:

Strafrechtliche Sanktionen nach 42 USC 1320d-6 ergänzen Haftstrafen von 1–10 Jahren für wissentliche Verstöße und für Taten, die mit der Absicht begangen werden, PHI zum persönlichen Vorteil zu verkaufen. Auch die State Attorneys General verfügen über eine durch HITECH verliehene Durchsetzungsbefugnis. 2024–2025 lagen OCR-Vergleichsvereinbarungen durchgängig im Bereich von USD 1–5 Mio., wobei die Vergleiche von Anthem und Premera die Obergrenze weiterhin verankern.

HHS veröffentlichte im Dezember 2024 eine Notice of Proposed Rulemaking zur Verschärfung der Security Rule, darunter die Umwandlung der meisten „addressable“-Spezifikationen in „required“, die Vorgabe von Multi-Faktor-Authentifizierung, standardmäßiger Verschlüsselung von ePHI im Ruhezustand und bei der Übertragung, Asset-Inventaren und jährlichen Compliance-Audits. Wir behandeln die NPRM als operativen Standard für jeden HIPAA-Build ab 2026 — die Finalisierung wird weithin für 2026–2027 erwartet.

Grundlagen der Privacy Rule (45 CFR 164.500–534)

Die Privacy Rule regelt die Nutzung und Offenlegung von PHI in jeder Form (Papier, mündlich, elektronisch). Für Softwareentwickler die maßgeblichen Bestimmungen:

• 164.502 — Nutzung und Offenlegung allgemein. PHI darf nur genutzt oder offengelegt werden, soweit die Privacy Rule es erlaubt oder verlangt oder die betroffene Person es autorisiert.
• 164.502(b) — Minimum Necessary. PHI auf das für den jeweiligen Zweck Notwendige beschränken. In Software: rollenbasierte Zugriffskontrolle und Sichtbarkeit auf Feldebene, nicht „jeder sieht alles“.
• 164.508 — Autorisierungen. Marketing, Psychotherapie-Notizen, Verkauf von PHI — erfordern eine spezifische schriftliche Autorisierung. Umsetzung: explizite Einwilligungs-Flows mit Widerrufspfaden.
• 164.514 — De-Identifikation. Zwei Safe Harbors: Expert Determination (statistisch) und Safe Harbor (Entfernen von 18 Identifikatoren). De-identifizierte Daten fallen aus HIPAA heraus. Behandeln Sie die De-Identifikations-Pipeline als sicherheitskritisch — eine Re-Identifikation ist ein Breach.
• 164.520 — Notice of Privacy Practices. Pflicht für CEs; BA-Verträge verlangen oft die BA-Konformität mit der NPP des CE.
• 164.524 — Auskunftsrecht. Personen müssen innerhalb von 30 Tagen Zugriff auf ihre PHI erhalten (eine 30-tägige Verlängerung zulässig). Software muss den Export von Patientendaten in maschinenlesbaren Formaten unterstützen (HHS-Guidance, OCR-Right-of-Access-Initiative 2020).
• 164.526 — Recht auf Berichtigung. Patienten können Berichtigungen beantragen; das System muss Berichtigungsanträge annehmen und weiterleiten.
• 164.528 — Accounting of Disclosures. 6-Jahres-Historie für Offenlegungen außerhalb von Behandlung, Zahlung und Betrieb — das Audit-Log muss dafür von Tag eins an ausgelegt sein.

Technische Schutzmaßnahmen der Security Rule (164.302–318)

Die Security Rule regelt ausschließlich elektronische PHI (ePHI) und ist die Regel, die Software-Teams täglich berühren. Sie gliedert sich in drei Schutzmaßnahmengruppen, jeweils mit „Standards“ (verpflichtend) und „Implementation Specifications“ (Required oder Addressable). „Addressable“ bedeutet nicht optional — es bedeutet, dass Sie es umsetzen oder eine angemessene und sachgerechte Alternative dokumentieren müssen.

Administrative Schutzmaßnahmen — 164.308

• 164.308(a)(1) Security Management Process — Risikoanalyse, Risikomanagement, Sanktionsrichtlinie, Prüfung der Aktivität in Informationssystemen. Die Risikoanalyse ist das Fundament des gesamten Security-Rule-Programms; HHS-Befunde nennen fehlende oder veraltete Risikoanalysen in großen Vergleichen durchgängig als Grundursache.
• 164.308(a)(3) Workforce Security — Autorisierung/Aufsicht, Freigabe, Austrittsverfahren.
• 164.308(a)(4) Information Access Management — Zugriffsautorisierung, -einrichtung und -änderung. Vierteljährliche Zugriffsprüfungen gelten heute als Mindeststandard.
• 164.308(a)(5) Security Awareness and Training — regelmäßige Schulungen, Sicherheitserinnerungen, Malware-Schutz, Login-Überwachung, Passwortverwaltung.
• 164.308(a)(6) Security Incident Procedures — identifizieren, reagieren, dokumentieren, eindämmen.
• 164.308(a)(7) Contingency Plan — Datensicherung, Disaster Recovery, Notfallbetrieb, Test und Revision, Kritikalität von Anwendungen und Daten.
• 164.308(a)(8) Evaluation — regelmäßige technische und nicht-technische Bewertung anhand des Standards.
• 164.308(b) Business Associate Contracts — schriftliche zufriedenstellende Zusicherungen (BAA), bevor BA-Zugriff gewährt wird.

Physische Schutzmaßnahmen — 164.310

Zugangskontrollen zu Einrichtungen (164.310(a)), Nutzung und Sicherheit von Arbeitsplätzen (164.310(b)/(c)), Geräte- und Medienkontrollen einschließlich Entsorgung, Wiederverwendung, Nachweisbarkeit und Backup (164.310(d)). Bei Cloud-nativem SaaS werden die physischen Kontrollen weitgehend aus dem Cloud-BAA übernommen, doch Arbeitsplatzrichtlinien für Entwickler-Laptops, die ePHI in Nicht-Produktionsumgebungen berühren, müssen Sie weiterhin selbst erstellen und durchsetzen.

Technische Schutzmaßnahmen — 164.312

Dies ist der Abschnitt, den Ihr Engineering-Team unmittelbar umsetzen muss. Fünf Standards:

• 164.312(a) Access Control. Eindeutige Benutzeridentifikation (Required), Notfallzugriffsverfahren (Required), automatisches Abmelden (Addressable — in der Praxis erforderlich), Ver- und Entschlüsselung (Addressable — in der Praxis erforderlich).
• 164.312(b) Audit Controls. Hardware-, Software- und prozedurale Mechanismen, die Aktivitäten in Informationssystemen mit ePHI aufzeichnen und prüfen. Keine vorgegebene Aufbewahrung, aber 164.316(b)(2) setzt 6 Jahre für die zugehörige Dokumentation fest.
• 164.312(c) Integrity. Mechanismus zur Authentifizierung von ePHI — Schutz vor unzulässiger Veränderung oder Zerstörung. Kryptografische Hashes, digitale Signaturen, Write-once-Speicher für Audit-Logs.
• 164.312(d) Person or Entity Authentication. Identität vor Zugriffsgewährung verifizieren. MFA gilt heute als Untergrenze.
• 164.312(e) Transmission Security. Integritätskontrollen und Verschlüsselung von ePHI bei der Übertragung. TLS 1.2+ überall, keine Ausnahmen.

Breach Notification: die 60-Tage-Uhr (164.400–414)

Die Breach Notification wurde durch HITECH eingeführt und in 45 CFR Subpart D kodifiziert. Ein „Breach“ ist der Erwerb, Zugriff, die Nutzung oder Offenlegung ungesicherter PHI in einer von der Privacy Rule nicht erlaubten Weise, die Sicherheit oder Privatsphäre beeinträchtigt (164.402). Eine Vier-Faktor-Risikobewertung entscheidet, ob eine Meldung erforderlich ist; es gilt die Vermutung, dass eine unzulässige Nutzung oder Offenlegung ein Breach ist, sofern die Vier-Faktor-Analyse keine geringe Wahrscheinlichkeit einer Beeinträchtigung nachweist.

Der Safe Harbor: War PHI nach dem HHS-/HITECH-Guidance-Standard verschlüsselt (NIST SP 800-111 im Ruhezustand, nach NIST SP 800-52 / FIPS 140-2 validiertes TLS bei der Übertragung), ist das Verlustereignis kein meldepflichtiger Breach. Verschlüsselung ist die wirkungsstärkste Einzelkontrolle im gesamten technischen HIPAA-Stack.

BAAs und die Subunternehmer-Kette

Die BAA-Pflicht nach 45 CFR 164.504(e) ist nicht verhandelbar. Erforderliche Elemente:

• Erlaubte und erforderliche Nutzung und Offenlegung von PHI durch den BA.
• Der BA nutzt oder legt PHI nur wie erlaubt oder erforderlich offen.
• Der BA setzt angemessene Schutzmaßnahmen um (Security Rule für ePHI).
• Der BA meldet Breaches und Sicherheitsvorfälle.
• Der BA stellt sicher, dass Subunternehmer denselben Beschränkungen zustimmen (164.308(b)(2), 164.502(e)(1)(ii)).
• Der BA stellt PHI für individuellen Zugriff, Berichtigung und Accounting bereit.
• Der BA gibt PHI bei Beendigung zurück oder vernichtet sie (sofern machbar).
• Der BA stellt HHS seine Compliance-Praktiken zur Verfügung.
• Kündigung bei wesentlichem Verstoß.

Erstellen Sie jetzt ein BAA-Inventar, falls Sie keines haben. Wir sehen Programme, in denen Postgres auf einer HIPAA-fähigen RDS-Instanz ordnungsgemäß unter BAA läuft, die Logs aber in einen Nicht-HIPAA-Observability-Stack fließen — ein sofortiger Verstoß. Jeder nachgelagerte Dienst, der ePHI auch nur kurzzeitig sieht, benötigt ein BAA.

Cloud, LLMs, Mobile und IoT — ePHI in modernen Stacks

Die heutigen HIPAA-Realitäten gehen über das hinaus, was das Gesetz von 1996 vorsah. Praktische Konsequenzen:

• Cloud. AWS, GCP, Azure veröffentlichen Listen HIPAA-fähiger Dienste. Unterzeichnen Sie das BAA, bevor Sie ePHI senden. Beschränken Sie ePHI-Workloads ausschließlich auf förderfähige Dienste. Achten Sie auf „Schatten“-Dienste, die Analysten aufsetzen.
• LLMs. AWS Bedrock, Azure OpenAI Service und Vertex AI bieten BAA-gedeckte Nutzung. Das Consumer-ChatGPT und Claude.ai sind nicht BAA-gedeckt — schon das Einfügen von PHI in eine Entwickler-Konsole ist ein Breach. Bei RAG über PHI enthalten der Embedding-Store, die Vektor-DB und die Retrieval-Logs allesamt ePHI und benötigen volle BAA-Deckung. Unsere HIPAA-konforme Softwareentwicklung behandelt den LLM-Stack als erstklassige ePHI-Oberfläche.
• Mobile. iOS- und Android-Gesundheits-Apps, die PHI verarbeiten, müssen Keychain / Keystore für Anmeldedaten verwenden, eine Biometrie- oder PIN-Sperre erzwingen, das Backup von ePHI in die iCloud / Google Drive des Nutzers deaktivieren, sofern nicht unter BAA (was bei keinem der beiden der Fall ist), und Zertifikate pinnen.
• IoT und Remote-Monitoring. Transportverschlüsselung von Gerät zu Cloud, Rotation der Geräteidentität, Secure Boot und manipulationssicheres Logging. FDA-510(k)-Overlay für Geräte der Klasse II/III.

Ein HIPAA-konformer SDLC in 8 Säulen

1. Risikoanalyse nach 164.308(a)(1)(ii)(A), jährlich und nach wesentlicher Änderung aktualisiert. Nutzen Sie die NIST-800-30-Methodik; Auditoren erkennen sie an.
2. Mitarbeiterschulung nach 164.530(b) für jeden, der PHI berührt; in einem LMS mit Abschlussbestätigungen dokumentiert.
3. Least-Privilege-Zugriff mit vierteljährlichen Zugriffsprüfungen nach 164.308(a)(4); SCIM-provisioniert, JIT für Produktionszugriff, versionierte Rollendefinitionen.
4. Audit-Logging in einem manipulationssicheren Speicher (Object Lock, append-only) mit über 6 Jahren Aufbewahrung gemäß 164.316(b)(2); protokollieren Sie jeden PHI-Lese-, Schreib-, Lösch- und Exportvorgang mit Benutzer, Zeitstempel, Quell-IP und Datensatzkennung.
5. Verschlüsselung im Ruhezustand (AES-256, KMS-verwaltete Schlüssel) und bei der Übertragung (TLS 1.2+, nach FIPS 140-2 validierte Krypto-Module, wo machbar); BYOK für Enterprise-Mandanten.
6. Backup, DR und getesteter Notfallplan nach 164.308(a)(7); RTO/RPO pro System dokumentiert, Wiederherstellung mindestens jährlich getestet.
7. BAA-Kette abgebildet, jährlich aktualisiert, über den Einkauf geschleust.
8. Incident Response-Runbook mit eingebauter 60-Tage-Breach-Uhr, zweimal jährlich per Tabletop getestet, in das On-Call-Paging integriert.

Die technische Checkliste, die Auditoren wirklich verwenden

• Eindeutige Benutzer-IDs — niemals gemeinsam genutzte Konten.
• MFA für jedes Konto mit PHI-Zugriff erzwungen, keine Ausnahmen für „Admin-Bequemlichkeit“.
• Session-Timeouts ≤ 15 Minuten für klinische Oberflächen, ≤ 30 für das Back-Office.
• Automatisches Abmelden implementiert und getestet.
• Verschlüsselung im Ruhezustand mit KMS-verwalteten Schlüsseln; Schlüsselrotationsrichtlinie dokumentiert und umgesetzt.
• TLS 1.2+ überall; schwache Ciphers deaktiviert; HSTS-Preload.
• Audit-Logs append-only, unveränderlich, mit Integritätsprüfung (HMAC oder signiert); 6 Jahre Aufbewahrung.
• PHI-Export-Audit-Trail mit Auflösung auf Feldebene.
• De-Identifikations-Pipeline gegen Safe Harbor oder Expert Determination validiert, Re-Identifikationsrisiko jährlich neu getestet.
• Zugriff auf die Produktionsdatenbank nur per JIT, jede Sitzung aufgezeichnet.
• Backups verschlüsselt, geografisch verteilt, Wiederherstellung getestet.
• Anbieter-BAA-Inventar aktuell; jeder PHI-berührende Dienst im Scope.
• Risikoanalyse aktuell, unterzeichnet, innerhalb der letzten 12 Monate datiert.
• Incident-Response-Runbook aktuell, letztes Tabletop innerhalb von 6 Monaten.
• Schulungsnachweise der Belegschaft aktuell, letzter Zyklus innerhalb von 12 Monaten.

Top 10 der Verstöße, die wir in Pre-Audit-Reviews sehen

1. Risikoanalyse fehlt oder ist 3+ Jahre veraltet.
2. Logs fließen zu einem Nicht-BAA-Observability-Anbieter (Datadog-Standard, Sentry-Standard usw.).
3. „Schatten“-Zugriff von Entwicklern auf die Produktion ohne JIT, ohne Aufzeichnung.
4. Gemeinsam genutzte Service-Konten, oft Überbleibsel aus der Entwicklungsphase.
5. De-Identifikation als Ad-hoc-SQL implementiert, nicht als validierte Pipeline.
6. Mobile-App cacht PHI unverschlüsselt im lokalen Speicher.
7. ChatGPT oder Claude.ai vom Support-Personal mit echten PHI genutzt — sofortiger Breach.
8. Backups bei der Übertragung verschlüsselt, aber entschlüsselt in einem CDN-Cache abgelegt.
9. Kein BAA mit dem E-Mail-Anbieter, obwohl PHI in den Inhalten von Support-Tickets steht.
10. Das Incident-Response-Runbook verweist auf die 60-Tage-Uhr, aber niemand hat es seit 18 Monaten ausgelöst.

Wenn Sie einen HealthTech-Build aufsetzen oder ein HIPAA-Programm sanieren, führen wir über die HIPAA-konforme Softwareentwicklung Festpreis-Gap-Assessments durch; wir haben diese im Tandem mit SaaS-Entwicklungs- und Individualsoftware-Programmen umgesetzt, und ein Fractional CTO mit ausgelieferter HIPAA-Erfahrung amortisiert sich meist schon in den ersten zwei Monaten allein durch die Risikominderung.

FAQ

Muss ich HIPAA-konform sein, wenn ich nur Zulieferer bin?

Wenn Sie PHI im Auftrag eines Covered Entity erstellen, empfangen, vorhalten oder übermitteln, ja — dann sind Sie ein Business Associate nach 45 CFR 160.103, die HITECH-erweiterte Security Rule und der Großteil der Privacy Rule gelten unmittelbar, und Sie schulden ein BAA.

Was verlangt die Security Rule technisch?

164.312 Technische Schutzmaßnahmen: Zugriffskontrolle mit eindeutigen IDs und Notfallzugriff (164.312(a)), Audit-Controls (164.312(b)), Integrität (164.312(c)), Authentifizierung (164.312(d)) — mit MFA als Untergrenze für 2026 — und Übertragungssicherheit mit TLS 1.2+ (164.312(e)).

Wie lange habe ich Zeit, einen Breach zu melden?

CE: Personen innerhalb von 60 Tagen nach Entdeckung benachrichtigen (164.404); HHS zeitgleich bei 500+; jährliches Protokoll bei <500. BA: CE innerhalb von 60 Tagen benachrichtigen (164.410), vertraglich meist auf 5–30 verkürzt.

Verschafft Verschlüsselung einen Safe Harbor bei der Breach-Meldung?

Ja, sofern nach dem HHS-/HITECH-Guidance-Standard verschlüsselt — NIST 800-111 im Ruhezustand, NIST 800-52 / FIPS 140-2 bei der Übertragung. Schlüssel müssen vom Chiffretext getrennt sein.

Darf ich AWS, GCP, Azure für ePHI nutzen?

Ja — zuerst das BAA unterzeichnen, auf HIPAA-fähige Dienste beschränken, KMS-Verschlüsselung, IAM-Least-Privilege, vollständiges Audit-Logging und VPC-Isolation umsetzen. Prüfen Sie die Förderfähigkeitsliste vierteljährlich.

Wie sieht ein HIPAA-konformer SDLC aus?

Acht Säulen: Risikoanalyse, Mitarbeiterschulung, Least-Privilege-Zugriff, Audit-Logging mit 6-jähriger Aufbewahrung, Verschlüsselung, Notfallplan, BAA-Kette, Incident Response mit eingebauter 60-Tage-Uhr.

HIPAA ist keine Checkliste. Es ist eine Betriebshaltung.

Teams, die HIPAA sauber ausliefern, behandeln Compliance als Build-Time-Artefakt: BAA-geschleuster Einkauf, standardmäßig verschlüsselte Dienste, vom Framework statt von Hand erzeugte Audit-Logs, ab Tag eins erzwungenes MFA, Risikoanalyse nach Kalender. Teams, die HIPAA als Audit am Projektende behandeln, übersehen stets etwas Wesentliches und zahlen dafür während einer OCR-Untersuchung.

Zuletzt aktualisiert am 26. Mai 2026. Verweise auf Abschnitte beziehen sich auf 45 CFR Parts 160 und 164. Nichts in diesem Artikel stellt eine Rechtsberatung für eine konkrete Situation dar.