HIPAA-Compliance,
verständlich erklärt

HIPAA ist der Health Insurance Portability and Accountability Act von 1996, ein US-Bundesgesetz. Im Alltag meint man mit dem Namen «die Regeln zum Schutz von Gesundheitsdaten», und genau dieser Teil betrifft die meisten Software-Teams: HIPAA legt fest, wie Gesundheitsinformationen zu schützen sind, wer für ihren Schutz verantwortlich ist und was geschehen muss, wenn sie offengelegt werden.

Zuerst gilt es zu klären, was HIPAA nicht ist. Es ist keine Zertifizierung. Das US Department of Health and Human Services (HHS) stellt kein HIPAA-Zertifikat aus, und keine Behörde prüft Sie und bescheinigt Ihnen «compliant». Sie bestimmen Ihre Compliance gegenüber dem Gesetz selbst und müssen sie auf Anfrage nachweisen können. Wer Ihnen ein «HIPAA certified»-Siegel verkauft, verkauft seine eigene Bescheinigung, keine staatliche, und das Gesetz selbst kennt so etwas gar nicht.

Was es sehr wohl gibt, ist Durchsetzung. Das HHS Office for Civil Rights (OCR) untersucht Beschwerden, Audits und gemeldete Verstösse und kann zivilrechtliche Geldbussen verhängen. Die praktische Messlatte lautet also nicht «haben Sie eine Prüfung bestanden», sondern «könnten Sie, wenn die OCR hinschaut, zeigen, dass Sie das ernst nehmen und über die Schutzmassnahmen und Nachweise verfügen, um es zu belegen».

HIPAA schützt «protected health information» (PHI): individuell identifizierbare Gesundheitsinformationen, also der Gesundheitszustand einer Person, ihre Versorgung oder die Bezahlung dafür, verknüpft mit Merkmalen wie Name, Daten oder Kontaktangaben. Werden diese Informationen elektronisch gehalten oder übermittelt, spricht man von «electronic protected health information» (ePHI), für die ausdrücklich die Security Rule gilt. Sobald Ihre Systeme Patientenakten, Termindaten oder irgendetwas berühren, das eine Person mit ihrer Gesundheit verbindet, verarbeiten Sie mit grosser Sicherheit PHI.

HIPAA gilt unmittelbar für «covered entities»: Leistungserbringer, die Gesundheitsinformationen elektronisch übermitteln, Krankenversicherer und Clearingstellen im Gesundheitswesen. Für diese Organisationen wurde das Gesetz geschrieben. Doch die Pflichten enden dort nicht, sondern reichen bis zu den Anbietern, auf die sich Covered Entities stützen.

Ein «business associate» ist jeder Anbieter, der im Auftrag einer Covered Entity PHI erzeugt, empfängt, vorhält oder übermittelt. Ein SaaS-Unternehmen, das Patientendaten speichert, ein Cloud-Host, ein Analytics-Anbieter, der mit Gesundheitsakten arbeitet: alle sind Business Associates und alle haften unmittelbar nach HIPAA. Wenn Sie Software bauen, die PHI für Kunden im Gesundheitswesen verarbeitet, fallen Sie mit grosser Sicherheit in diese Kategorie, und genau deshalb taucht HIPAA in Ihren Verkaufsgesprächen auf.

Die Privacy Rule regelt Nutzung und Weitergabe geschützter Gesundheitsinformationen in jeder Form, ob auf Papier, elektronisch oder mündlich. Sie steckt die Grenzen ab: wann PHI genutzt und geteilt werden dürfen (grob für Behandlung, Bezahlung und den Betrieb des Gesundheitswesens), wann die Einwilligung der betroffenen Person nötig ist und was ohne sie niemals offengelegt werden darf.

Zwei Gedanken aus der Privacy Rule kehren immer wieder. Der erste ist der Grundsatz «minimum necessary»: Sie sollten nur die kleinste für die jeweilige Aufgabe nötige Menge an PHI nutzen oder weitergeben, statt einen ganzen Datensatz herauszugeben, wo ein einzelnes Feld genügt. Der zweite sind die individuellen Rechte, die die Regel gewährt, allen voran das Recht der Betroffenen, ihre eigenen Gesundheitsakten einzusehen, eine Kopie zu erhalten und Korrekturen zu verlangen. Für einen Software-Anbieter werden beide zu konkreten Entscheidungen über Produkt und Zugriffssteuerung, nicht nur zu Formulierungen in Richtlinien.

Die Security Rule ist der Teil, mit dem die meisten Engineering-Teams ihre Zeit verbringen, weil sie sich ausdrücklich mit elektronischer PHI befasst. Sie verlangt Schutzmassnahmen in drei Kategorien: administrativ (die Richtlinien, Schulungen und die Zuweisung von Verantwortung, die regeln, wie Menschen mit ePHI umgehen), physisch (die Kontrolle des physischen Zugangs zu den Systemen und Räumen, die sie vorhalten) und technisch (die Zugriffssteuerung, das Audit-Logging, der Integritätsschutz und die Übertragungssicherheit, die in die Systeme selbst eingebaut sind).

Ein prägendes Merkmal der Security Rule ist, dass ihre Schutzmassnahmen als «implementation specifications» kommen, gekennzeichnet entweder als «required» oder als «addressable». «Required» muss umgesetzt werden. «Addressable» heisst nicht optional: Es bedeutet, dass Sie prüfen, ob die Vorgabe für Ihre Umgebung angemessen und verhältnismässig ist, und sie dann entweder umsetzen, eine gleichwertige Alternative umsetzen oder dokumentieren, warum sie nicht gilt. Diese Flexibilität ist gewollt, denn HIPAA soll von der kleinen Praxis bis zur grossen Plattform skalieren; es sagt Ihnen, was zu erreichen ist, und lässt offen, wie.

Wenn eine Pflicht die ganze Security Rule verankert, dann die Risikoanalyse. HIPAA verlangt von Covered Entities und Business Associates eine genaue und gründliche Beurteilung der möglichen Risiken und Schwachstellen für die Vertraulichkeit, Integrität und Verfügbarkeit der gehaltenen ePHI und danach, diese Risiken auf ein angemessenes und verhältnismässiges Mass zu senken.

Das ist kein einmaliges Dokument. Die Risikoanalyse ist der Motor, der entscheidet, welche Schutzmassnahmen für Ihre konkreten Systeme zählen und wie viel Aufwand jede verdient, und die Durchsetzungsverfahren der OCR kommen immer wieder darauf zurück: Eine fehlende, veraltete oder oberflächliche Risikoanalyse ist einer der häufigsten Befunde. Sie aktuell zu halten, während sich Ihre Systeme verändern, ist das meiste daran, ein HIPAA-Programm zu «führen», so wie ein lebendiges Risikoregister das Herzstück jedes ernsthaften Sicherheitsprogramms ist.

HIPAA geht nicht davon aus, dass nie etwas schiefgeht; es sagt Ihnen, was zu tun ist, wenn es passiert. Die Breach Notification Rule verlangt, dass Sie nach einem Verstoss gegen ungesicherte PHI die betroffenen Personen und das HHS ohne unangemessene Verzögerung und in keinem Fall später als 60 Tage nach Entdeckung benachrichtigen. Bei grösseren Verstössen, die viele Personen einer Region betreffen, müssen zusätzlich die Medien informiert werden, und die Meldung an das HHS hat eine engere Frist.

Für einen Business Associate läuft die Pflicht in der Regel auf die Covered Entity zu, die Sie bedienen: Sie melden ihr einen Verstoss, damit sie ihre eigenen Meldepflichten erfüllen kann, in der Frist, die Ihr BAA setzt. Praktisch heisst das, Sie müssen einen Verstoss erkennen, den betroffenen Datenbestand eingrenzen und dieses Bild rasch erstellen können. 60 Tage klingen grosszügig, bis ein Vorfall läuft und Sie aus verstreuten Logs rekonstruieren, was geschehen ist. Die Arbeit, vor einem Vorfall auditbereit zu bleiben, ist genau die Arbeit, die Sie während eines Vorfalls schnell antworten lässt.

HIPAA wird vom HHS Office for Civil Rights durchgesetzt. Die OCR reagiert auf Beschwerden, untersucht gemeldete Verstösse und führt Audits durch, und wo sie Non-Compliance feststellt, kann sie Korrekturmassnahmen verlangen und zivilrechtliche Geldbussen verhängen. Diese Bussen sind nach Verschulden abgestuft, grob von echtem Nichtwissen am unteren Ende bis zu nie behobener vorsätzlicher Vernachlässigung am oberen Ende. In einer Untersuchung zählt deshalb oft am meisten, ob Sie zeigen können, dass Sie angemessene Schritte unternommen und in gutem Glauben gehandelt haben.

Weil es kein Zertifikat hochzuhalten gibt, ist dieser Nachweis alles. Sie können nicht auf ein Siegel zeigen; Sie zeigen auf Ihre Risikoanalyse, Ihre Schutzmassnahmen, Ihre Richtlinien, Ihre Schulungsnachweise und Ihre BAAs. Ein Programm, das dokumentiert, aktuell und konsistent ist, steht zwischen einer beherrschbaren Anfrage und einem Befund der Vernachlässigung. Deshalb belohnt HIPAA, obwohl es keine Prüfung gibt, dieselbe fortlaufende Disziplin wie zertifizierbare Frameworks.

Teams, die mit Gesundheitsdaten umgehen, begegnen HIPAA selten allein. Ein US-Kunde im Gesundheitswesen fragt, ob Sie HIPAA-compliant sind; ein grösserer oder internationaler verlangt zusätzlich SOC 2 oder ISO 27001. Die gute Nachricht: Auf der Ebene der tatsächlichen Praxis überschneiden sich diese stark. Zugriffssteuerung, Audit-Logging, Verschlüsselung, Risikobeurteilung, Incident Response, Lieferantenmanagement und Sicherheitsschulungen sind allen dreien gemeinsam, auch wenn jedes sie anders benennt und einrahmt.

Den Unterschied, den man auseinanderhalten sollte, ist, was jedes davon eigentlich ist. SOC 2 ist ein Attestierungsbericht, den ein Prüfer gegen die Trust Services Criteria erstellt; ISO 27001 ist eine internationale Zertifizierung eines Managementsystems; HIPAA ist ein Gesetz, das Sie einhalten und dessen Einhaltung Sie nachweisen müssen, ganz ohne Zertifikat. Andere Artefakte, andere Stellen, doch weitgehend dieselben zugrunde liegenden Schutzmassnahmen. Pflegen Sie diese Schutzmassnahmen einmal und ordnen Sie sie den Anforderungen jedes Frameworks zu, dann ist HIPAA kein eigenes Projekt mehr, sondern eine weitere Sicht auf Arbeit, die Sie ohnehin schon leisten.

Da Ihnen niemand ein Zertifikat aushändigt, heisst HIPAA-Compliance nachzuweisen, auf Anfrage einen stimmigen Bestand an Nachweisen vorlegen zu können, sei es für eine Anfrage der OCR, das Sicherheitsreview eines Kunden oder Ihre eigene interne Prüfung. Eine offizielle Checkliste gibt es nicht, doch die Form ist immer ähnlich: eine aktuelle Risikoanalyse, die administrativen, physischen und technischen Schutzmassnahmen, die darauf eingehen, Ihre schriftlichen Richtlinien und Verfahren, Nachweise der Mitarbeiterschulung und unterzeichnete BAAs mit jedem Anbieter, der PHI berührt.

In der Praxis entscheidet sich hier, ob ein HIPAA-Programm gelingt oder scheitert. Die Schutzmassnahmen sind meist vorhanden; schief geht, dass der Nachweis verstreut ist: Die Risikoanalyse ist ein Jahr alt, die Richtlinie sagt das eine und die Systeme tun das andere, die BAAs liegen in irgendjemandes Postfach. Alles an einem Ort, aktuell und mit der Anforderung verknüpft zu halten, die es erfüllt, ist das meiste daran, compliant zu bleiben. Es macht den Unterschied, ob Sie einen Sicherheitsfragebogen an einem Nachmittag beantworten oder sich eine Woche davor fürchten.