Written by:
Last Published:
21. Oktober 2026
•
HIPAA-konforme Softwareentwicklung ist die Praxis, Software so zu konzipieren, zu erstellen und zu betreiben, dass elektronische geschützte Gesundheitsinformationen (ePHI) gemäß der HIPAA Security Rule vertraulich, korrekt und verfügbar bleiben. Es kommt auf dokumentierte Architektur-Entscheidungen an, die frühzeitig getroffen werden, nicht auf Funktionen, die erst beim Launch hinzugefügt werden.
Dieser Leitfaden richtet sich an diejenigen, die Architektur und Budget absegnen: CTOs, Produktverantwortliche und Führungskräfte, die für das Risiko geradestehen. Kein juristischer Exkurs. Wir gehen direkt auf die Entscheidungen ein, die Ihre Daten, Audit-Trails, EHR-Integrationen und Cloud-Anbieter prägen, und fassen diese in einer HIPAA-Compliance-Checkliste zusammen, die Ihre Ingenieure bei einer Design-Überprüfung durchgehen können.
Hier liegt das Missverständnis: HIPAA-Compliance ist kein Gütesiegel, das Ihr Produkt beim Launch erhält. Es ist die Bausubstanz, nicht die Wandfarbe.
Sie können ein Gebäude an einem Nachmittag neu streichen, aber Sie können keine tragenden Wände einfach überstreichen. Diese werden früh festgelegt und sind teuer zu verändern, sobald das Gebäude bewohnt ist. (Dies stellt keine Rechtsberatung dar. Ihr Rechtsbeistand hat das letzte Wort.)
HIPAA-konforme Softwareentwicklung bedeutet, frühzeitig eine Reihe von Architektur-Entscheidungen zu treffen und diese zu dokumentieren: Zuerst eine Risikoanalyse, dann Verschlüsselung, rollenbasierter Zugriff, Audit-Logging, kontrollierte Integrationen sowie eine Business Associate Agreement (BAA) für jede Partei, die mit ePHI in Berührung kommt. Diese Kontrollen bereits in der Designphase zu implementieren, ist weitaus kostengünstiger als eine nachträgliche Anpassung. Zudem bilden sie den Nachweis, den Käufer, Investoren und Versicherer verlangen. Die folgenden Punkte fassen jede Entscheidung zusammen.
Denn die Kosten treffen das Unternehmen, nicht den Programmcode. Sicherheitsverletzungen sind teuer, Regulierungsbehörden verhängen Vergleiche und Strafen in Millionenhöhe, und die nachträgliche Implementierung von Kontrollen in ein bestehendes Produkt ist kostspieliger als deren Einplanung von Beginn an. Compliance-Entscheidungen sind Investitionsentscheidungen – und am günstigsten sind sie zu Beginn.
Die Zahlen sind nicht abstrakt. IBMs Bericht zu den Kosten von Datenschutzverletzungen 2026 beziffert den weltweiten Durchschnitt auf 4,99 Millionen US-Dollar – ein Rekordhoch und ein Anstieg von 12 % gegenüber dem Vorjahr.
Auch die Regulierungsbehörden halten sich nicht zurück. Das HHS veröffentlicht seine Vergleichsvereinbarungen und zivilrechtlichen Geldstrafen, und die aktuelle Liste umfasst 3 Millionen US-Dollar (Solara Medical Supplies, Januar 2025), 1,5 Millionen US-Dollar (Warby Parker, Februar 2025) und 1,19 Millionen US-Dollar (Gulf Coast Pain Consultants, Dezember 2024). Bei allen drei Fällen handelte es sich um Verstöße gegen die Security Rule, zwei davon folgten auf Phishing- oder Hacking-Vorfälle.
Dann gibt es noch den Teil, für den niemand ein Budget einplant. Compliance wird in geschäftlichen Momenten relevant, lange bevor eine Regulierungsbehörde auftaucht. Käufer im Gesundheitswesen versenden regelmäßig Sicherheitsfragebögen, in denen nach Ihrer Risikoanalyse, BAA-Bedingungen, Verschlüsselung, Zugriffskontrolle, Audit-Logging und Incident-Response-Verfahren gefragt wird. Investoren, die im Rahmen einer Finanzierungsrunde eine Due-Diligence-Prüfung durchführen, suchen in der Regel nach einer abgeschlossenen Risikoanalyse, einem Verzeichnis unterzeichneter BAAs und dem Nachweis, dass entsprechende Kontrollen vorhanden sind.
Cyber-Versicherer schließen sich bei Angeboten und Vertragsverlängerungen dieser Reihe an. Sie fragen nach Multi-Faktor-Authentifizierung, getesteten Backups und einem schriftlichen Incident-Response-Plan. Lücken in diesen Bereichen können die Prämien erhöhen oder den Versicherungsschutz einschränken. Zudem arbeitet ein Team, das alle drei Punkte anhand bereits vorhandener Dokumente beantworten kann, schneller als eines, das die Nachweise unter Zeitdruck zusammenstellen muss. (Ehrlich gesagt ist diese Geschwindigkeit der eigentliche Gewinn, wenn man dies frühzeitig angeht.)
Für alle, die die Entwicklung von Software für das Gesundheitswesen planen, ergeben sich daraus drei geschäftliche Aspekte:
HIPAA gilt für abgedeckte Unternehmen wie Gesundheitsdienstleister und Krankenversicherungen sowie für deren Geschäftspartner (Business Associates). Wenn Ihre Software ePHI für einen dieser Akteure erstellt, empfängt, verwaltet oder überträgt, sind Sie ein Geschäftspartner. Die Security Rule schreibt in diesem Fall administrative, physische und technische Sicherheitsvorkehrungen vor, die dokumentiert und auf dem neuesten Stand gehalten werden müssen.
Die HIPAA Security Rule legt in 45 CFR 164.312 fünf technische Schutzmaßnahmen fest: Zugriffskontrolle, Audit-Kontrollen, Integrität, Authentifizierung von Personen oder Entitäten sowie Übertragungssicherheit. Einige Spezifikationen sind verpflichtend. Andere sind „adressierbar“, ein Begriff, der oft für Verwirrung sorgt. Adressierbar bedeutet nicht optional.
Sie setzen die Maßnahme um, wenn sie angemessen und zweckmäßig ist, oder Sie dokumentieren, warum eine gleichwertige Alternative besser geeignet ist.
Die Dokumentation ist genauso wichtig wie der Code. Gemäß 45 CFR 164.316 müssen erforderliche Unterlagen sechs Jahre lang ab ihrer Erstellung oder ab dem Datum ihrer letzten Gültigkeit aufbewahrt werden, je nachdem, welcher Zeitpunkt später liegt. Wenn eine Entscheidung nicht schriftlich festgehalten wurde, wird ein Prüfer sie so behandeln, als wäre sie nie getroffen worden.
Für den breiteren regulatorischen Kontext, einschließlich der DSGVO, behandelt unser Beitrag über digitale Transformation in der Gesundheitstechnologie was über HIPAA hinausgeht.
Eine Risikoanalyse ist die gemäß 45 CFR 164.308(a)(1)(ii)(A) erforderliche, dokumentierte Bewertung von Risiken und Schwachstellen für ePHI. Sie identifizieren, wo ePHI gespeichert ist, listen Bedrohungen und Schwachstellen auf, bewerten Eintrittswahrscheinlichkeit und Auswirkungen und halten Korrekturmaßnahmen fest. Sie erfolgt vor der Architekturplanung, da sie vorgibt, welche Kontrollen das Design enthalten muss.
Die Die HHS-Leitlinien zur Risikoanalyse schreiben keine bestimmte Methode vor, beschreiben jedoch die Elemente, die jede glaubwürdige Analyse enthalten muss:
Die Analyse dient dem Risikomanagement: der Implementierung von Sicherheitsmaßnahmen, die ausreichen, um Risiken und Schwachstellen auf ein angemessenes und vertretbares Maß zu reduzieren. Zwei benachbarte Punkte finden sich in 45 CFR 164.308: regelmäßige Überprüfung der Protokolle von Systemaktivitäten (eine erforderliche Spezifikation) sowie die Durchführung regelmäßiger technischer und nicht-technischer Bewertungen.
Ist das nur Papierkram? Teilweise. Es ist auch das Baugutachten, das Sie in Auftrag geben, bevor Sie das Fundament gießen.
Die aktuelle Vorschrift nennt Penetrationstests nicht explizit, und auch die Risikomanagement-Leitlinien des HHS erwähnen sie nicht. Doch regelmäßige Bewertungen und Risikomanagement sind ohne technische Tests nur schwer nachzuweisen. Scans, Abhängigkeitsüberwachung und Penetrationstests sind der übliche Nachweis dafür, dass Sicherheitsvorkehrungen so funktionieren, wie sie konfiguriert wurden – und nicht nur, wie sie auf dem Papier stehen.
Für eine HIPAA-konforme Softwareentwicklung ist es sinnvoll, kontinuierlich zu scannen, nach einem festgelegten Zeitplan zu patchen und vor größeren Releases sowie nach wesentlichen Architekturänderungen externe Tests durchzuführen. Dokumentieren Sie die Ergebnisse und die Fehlerbehebungen. Diese Aufzeichnungen werden Teil Ihrer Dokumentation.
Fünf Entscheidungen fallen besonders ins Gewicht: Wo ePHI gespeichert wird, wie es verschlüsselt ist, wer welche Felder sehen darf, wie Umgebungen voneinander getrennt sind und was mit Daten geschieht, wenn sie nicht mehr benötigt werden. Treffen Sie diese Entscheidungen frühzeitig. Sie nachträglich in ein laufendes Produkt zu integrieren, ist langsamer, kostspieliger und riskanter, als sie von Anfang an einzuplanen.
Gemäß der Security Rule fallen Verschlüsselung und Entschlüsselung unter die Zugriffskontrolle, und die Verschlüsselung von Daten bei der Übertragung unter die Übertragungssicherheit. Beides ist umsetzbar. In der Praxis ist es im Jahr 2026 kaum zu rechtfertigen, darauf zu verzichten.
Es gibt einen zweiten Grund für die Verschlüsselung. Wenn ePHI gemäß den Standards des HHS verschlüsselt wurde, kann eine Datenpanne unter eine sogenannte „Safe Harbor“-Regelung fallen, wie die HHS-Richtlinien zum Cloud-Computing erläutern. Doch Verschlüsselung allein macht Sie noch nicht regelkonform. Sie leistet keinen Beitrag zur Integrität, Verfügbarkeit oder zu Ihren administrativen Sicherheitsvorkehrungen.
Ein solider Standard:
Eindeutige Benutzeridentifizierung und Notfallzugriffsverfahren sind zwingend erforderlich. Eine automatische Abmeldung ist eine adressierbare Anforderung. Das bildet die Grundlage: keine geteilten Konten, ein dokumentierter Notfallweg und Sitzungen, die nicht unbegrenzt offen bleiben. Der Notfallweg wird oft als „Break Glass“-Verfahren bezeichnet: eine streng protokollierte Notfallfreigabe, die es autorisiertem Personal ermöglicht, auf einen Datensatz zuzugreifen, wenn normale Berechtigungen dies verhindern würden und es auf Zeit ankommt.
Dann stellt sich eine Designfrage. Der HIPAA-Standard zur minimalen notwendigen Datenverwendung verlangt von Organisationen, die Informationen, die verwendet, offengelegt oder angefordert werden, auf das für den jeweiligen Zweck erforderliche Maß zu beschränken (Offenlegungen zur Behandlung gehören zu den Ausnahmen). In der Softwareentwicklung bedeutet das: rollenbasierte Zugriffsrechte, Sichtbarkeit auf Feldebene und Oberflächen, die auf Aufgaben ausgerichtet sind, nicht auf die gesamte Patientenakte.
Dies ist besonders wichtig bei Produkten, die auf den Austausch von Daten ausgelegt sind. Jinga Life, eine App für familiäre Gesundheitsdaten, bei der Datensätze mit Ärzten geteilt werden, während sie privat bleiben, wurde als eine Reihe von Microservices (Node.js und Ruby on Rails) hinter einer Swift-iOS-App entwickelt.
Die Aufteilung eines Produkts in Services bietet natürliche Ansatzpunkte, um Zugriffsregeln durchzusetzen. Sie vervielfacht jedoch auch die Verbindungen, die Sie absichern und protokollieren müssen. Deshalb muss das Zugriffsmodell entworfen werden, bevor die Service-Grenzen festgelegt werden. Ein Mitarbeiter in der Abrechnung und ein Arzt sollten nicht denselben Bildschirm sehen. Sie sollten auch nicht dieselbe API-Antwort erhalten.
Hier schleichen sich oft Fehler ein, trotz guter Absichten. Die Produktionsumgebung ist abgesichert, dann kopiert jemand eine Datenbank in die Staging-Umgebung, um einen Fehler zu reproduzieren. Oder ein Fehler-Tracker erfasst einen Request-Body voller Patientendaten. Oder ein Analysetool erhält ein Freitextfeld.
Halten Sie echte ePHI aus Entwicklungs- und Testumgebungen fern. Verwenden Sie stattdessen synthetische oder ordnungsgemäß anonymisierte Daten. Scannen Sie Protokolle, Fehlerberichte und Analyse-Payloads auf Identifikatoren und behandeln Sie jedes Drittanbieter-Tool, das Patientendaten empfängt, als einen Dienstleister, der eine eigene Vereinbarung benötigt (dazu weiter unten mehr).
Die Sechsjahresregel von HIPAA deckt erforderliche Dokumentationen wie Richtlinien, Verfahren und Risikoanalysen ab. Sie ersetzt nicht die Aufbewahrungsfristen für medizinische Unterlagen selbst, die je nach Zuständigkeitsbereich variieren. Definieren Sie beides und legen Sie fest, was Löschung für Backups, Replikate und Suchindizes tatsächlich bedeutet. Ein Datensatz, der aus der Benutzeroberfläche verschwindet, aber im Snapshot des letzten Jahres weiterbesteht, wurde nicht ordnungsgemäß gelöscht.
Plattformen, die Dokumente und medizinische Informationen für Familien und Pflegekräfte speichern, müssen die Frage der Aufbewahrung vor dem Start klären, nicht erst nach der ersten Löschungsanfrage. VestaConnect läuft beispielsweise auf der Google Cloud mit PostgreSQL als Hauptdatenbank für Benutzerdaten, Aufgaben, Zeitpläne und Aktivitätsprotokolle. Die Speicherung von Aktivitätsprotokollen zusammen mit Anwendungsdaten in einem relationalen Speicher ist eine Designentscheidung mit Konsequenzen für die Aufbewahrung: Jede Löschregel, die Sie für den einen Bereich festlegen, muss auch für den anderen geprüft werden.
Audit-Kontrollen müssen Aktivitäten in Systemen, die ePHI enthalten, aufzeichnen und untersuchen. In der Praxis bedeutet das: Protokollieren Sie, wer wann von wo auf was zugegriffen hat und was dabei getan wurde – einschließlich Lesezugriffen, nicht nur Schreibzugriffen. Speichern Sie Protokolle getrennt von der Anwendung, schützen Sie sie vor Manipulation und überprüfen Sie sie regelmäßig, nicht erst nach einem Vorfall.
Gute HIPAA-Audit-Protokolle beantworten schnell eine Frage: Wer hat diesen Datensatz berührt und warum? Lesezugriffe sind dabei am wichtigsten.
Die meisten Teams protokollieren Datenänderungen aus Gewohnheit, weil dies für das Debugging erforderlich ist. HIPAA interessiert sich jedoch genauso sehr dafür, wer die Daten eingesehen hat. Ein Türprotokoll, das nur Renovierungen, aber keine Besucher erfasst, ist wenig nützlich.
Ein nützlicher Audit-Datensatz enthält in der Regel:
Gestalten Sie das Protokoll nur zum Anhängen (append-only) und bewahren Sie es außerhalb der Reichweite der Personen auf, die darin erfasst werden. Richten Sie dann Warnmeldungen für relevante Muster ein: Massenexporte, Zugriffe außerhalb der normalen Geschäftszeiten, wiederholte Verweigerungen oder die Nutzung von Notfallzugriffen.
Die Cloud bringt eine Besonderheit mit sich: Ein Teil der Nachweise liegt bei Ihrem Anbieter. Das HHS weist darauf hin, dass HIPAA Cloud-Anbieter nicht dazu verpflichtet, Sicherheitsdokumentationen bereitzustellen oder Kunden-Audits zu gestatten. Daher muss der Zugriff im BAA (Business Associate Agreement) oder im Service Level Agreement vereinbart werden. Fordern Sie den Zugriff auf Protokolle und Bedingungen zur Meldung von Vorfällen vor der Vertragsunterzeichnung an, nicht erst während eines Vorfalls.
Die Erkennung bestimmt auch Ihre Fristen. Die Breach Notification Rule erwartet eine Benachrichtigung ohne unzumutbare Verzögerung und spätestens 60 Tage nach der Entdeckung. Sie können nicht melden, was Sie nicht sehen können. Ein guter Audit-Trail macht aus „Wir glauben, da ist etwas passiert“ ein „Hier ist genau ersichtlich, welche Datensätze betroffen waren“.
Was die Aufbewahrung betrifft, so nennt die Regel keine Frist für Systemprotokolle. Viele Teams orientieren sich als konservativen Standard an der sechsjährigen Dokumentationspflicht. Klären Sie dies mit Ihrem Rechtsbeistand und prüfen Sie alle geltenden lokalen Vorschriften.
Für einen strukturierten Weg, dies alles auf Kontrollen abzubilden, ist NIST SP 800-66 Rev. 2, der Leitfaden für Cybersicherheitsressourcen zur Implementierung der Security Rule, die Referenz, die die meisten Engineering-Teams letztlich verwenden.
Auf einer Multi-Mandanten-Plattform bedienen eine Codebasis und eine Infrastruktur mehrere Kunden. Ein einziger Fehler kann daher die ePHI aller Mandanten gefährden. HIPAA verbietet Multi-Mandanten-Architekturen nicht, aber die Anforderungen an Zugriffskontrolle und Auditierung gelten für die Daten jedes einzelnen Kunden. Die Designfrage ist, wie strikt Sie Schlüssel, Daten, Zugriffe und Audit-Trails pro Mandant isolieren.
Vier Entscheidungen leisten dabei die meiste Arbeit:
Ein Multi-Tenant-Produkt ist wie ein Mehrfamilienhaus, kein Einfamilienhaus: gemeinsame Leitungen, ein gemeinsames Treppenhaus und ein eigenes Schloss an jeder Tür.
Die Anpassung an einzelne Mandanten ist der Punkt, an dem diese Produkte meist scheitern. Ein gemeinsamer Löschauftrag oder eine Log-Pipeline ist einfach zu erstellen, aber nur schwer mit zehn verschiedenen Verträgen in Einklang zu bringen.
Jede EHR-Integration ist ein neuer Weg für ePHI und benötigt daher ein eigenes Bedrohungsmodell. Bevorzugen Sie FHIR-APIs mit OAuth 2.0-Scopes gegenüber Dateitransfers und Punkt-zu-Punkt-Feeds, beschränken Sie jede Integration auf die minimal erforderlichen Daten und schließen Sie mit jeder Partei, die mit den Daten in Berührung kommt, eine Business Associate Agreement (BAA) ab.
Betrachten Sie Ihr Produkt als Gebäude und jede Integration als neue Tür. Niemand baut eine Tür ein, ohne zu entscheiden, wer den Schlüssel hat und wohin die Tür führt. Integrationen verdienen dieselbe Frage: Wer darf hindurchgehen und in welche Räume?
FHIR ist der moderne Standard für den Austausch von Gesundheitsdaten. Das SMART App Launch-Framework (derzeit Version 2.2.0, basierend auf FHIR R4) fügt eine OAuth 2.0-Autorisierungsebene hinzu. Über die Scopes können Sie einer App genau die Berechtigungen erteilen, die sie benötigt – zum Beispiel Lese- und Suchzugriff auf einen bestimmten Ressourcentyp für den autorisierenden Benutzer.
Es definiert zudem ein Backend-Services-Muster für Server-zu-Server-Integrationen ohne Benutzerinteraktion. Ältere HL7 v2-Feeds sind nach wie vor verbreitet und bergen ihre eigenen Risiken. Der MLLP-Transport, der sie überträgt (ein einfacher Wrapper, der HL7 v2-Nachrichten über eine TCP-Verbindung sendet), verfügt über keine integrierte Verschlüsselung oder Authentifizierung. Sichern Sie diese Verbindungen daher über ein VPN oder einen TLS-Tunnel ab und schränken Sie sie netzwerk- und senderseitig ein.
Halten Sie für jede Integration Folgendes fest:
Ja. Wenn ein Cloud-Anbieter ePHI für Sie erstellt, empfängt, verwaltet oder überträgt, gilt er als Geschäftspartner (Business Associate). Laut HHS verstößt die Nutzung eines solchen Anbieters ohne eine Business Associate Agreement (BAA) gegen die HIPAA-Regeln. Dies gilt auch dann, wenn der Anbieter nur verschlüsselte Daten speichert und nicht über den Schlüssel verfügt.
Ein HIPAA-konformes Cloud-Setup beginnt mit der Vereinbarung, nicht mit dem Architekturdiagramm.
In einem BAA werden zudem die Verantwortlichkeiten aufgeteilt. Das HHS beschreibt ein geteiltes Modell: Der Kunde ist möglicherweise für die Benutzerauthentifizierung zuständig, der Anbieter für die Verschlüsselung. Die genaue Aufteilung hängt von der Vereinbarung und dem Risikomanagement der jeweiligen Partei ab. Halten Sie dies schriftlich fest. Niemand möchte mitten in einem Vorfall erst klären müssen, wer für das Patch-Management verantwortlich ist.
Daraus ergeben sich einige praktische Punkte:
Das HHS veröffentlicht Musterbestimmungen für Business Associate Agreements. Eine konforme Vereinbarung legt fest, welche Nutzungen und Offenlegungen der Geschäftspartner vornehmen darf, und schreibt angemessene Sicherheitsvorkehrungen vor, einschließlich der Security Rule für ePHI. Sie erfordert die Meldung unbefugter Nutzungen und Offenlegungen, einschließlich Datenschutzverletzungen und Sicherheitsvorfällen.
Zudem müssen Unterauftragnehmer an dieselben Beschränkungen gebunden werden, die Rückgabe oder Vernichtung von PHI bei Vertragsende (sofern möglich) gefordert werden und der abgedeckten Stelle die Kündigung bei wesentlichen Vertragsverletzungen ermöglicht werden. Lesen Sie das Dokument wie ein Ingenieur: Jede Klausel entspricht einer Anforderung, die Ihr System erfüllen muss, wie etwa Meldepflichten, Löschvorgänge oder die Kontrolle von Unterauftragnehmern.
KI-Funktionen verdienen besondere Aufmerksamkeit. Ein Prompt, der eine Patientenzusammenfassung enthält, ist ePHI während der Übertragung. Behandeln Sie Anbieter von Sprachmodellen wie jeden anderen Dienstleister: Erst die Vereinbarung, dann die Daten.
Verwenden Sie diese Imaginary Cloud HIPAA-Architektur-Checkliste bei Design-Reviews für jedes HIPAA-konforme Softwareentwicklungsprojekt sowie als Lückenanalyse für bereits aktive Produkte. Die erste Spalte enthält die Entscheidung, die zweite den Grund für die HIPAA-Relevanz und die dritte eine sinnvolle Standardvorgabe. Die Bezeichnungen „Required“ (erforderlich) und „Addressable“ (adressierbar) stammen aus 45 CFR 164.312. Die übrigen Punkte beziehen sich auf die administrativen Anforderungen der Security Rule, die Privacy Rule, die Breach Notification Rule und die Dokumentationsregeln.
| Entscheidung | Warum HIPAA hier relevant ist | Sinnvolle Standardlösung |
|---|---|---|
| Risikoanalyse | Verpflichtend (164.308(a)(1)(ii)(A)) | Dokumentierte Analyse vor dem Design; Überprüfung nach Vorfällen, Anbieterwechseln und größeren Releases |
| Schwachstellen- und Penetrationstests | Unterstützt die regelmäßige Evaluierung und das Risikomanagement | Kontinuierliches Scanning, geplantes Patching, externe Tests vor größeren Releases |
| Eindeutige Benutzeridentifizierung | Verpflichtende Spezifikation (Zugriffskontrolle) | Individuelle Identitäten über SSO; keine geteilten Zugänge; Servicekonten eingegrenzt und rotiert |
| Notfallzugriff | Verpflichtende Spezifikation (Zugriffskontrolle) | Dokumentierte „Break Glass“-Rolle mit zusätzlicher Protokollierung und nachträglicher Überprüfung |
| Automatische Abmeldung | Adressierbar (Zugriffskontrolle) | Kurze Sitzungs-Timeouts; erneute Authentifizierung bei sensiblen Aktionen |
| Verschlüsselung ruhender Daten | Adressierbar; unterstützt zudem die „Breach Safe Harbour“-Regelung | Verwalteter Schlüsseldienst, separate Schlüssel pro Umgebung, Rotation nach Zeitplan |
| Verschlüsselung bei der Übertragung | Übertragungssicherheit (Verschlüsselung adressierbar) | TLS überall, auch im internen Datenverkehr; Legacy-HL7-v2 durch einen Tunnel leiten |
| Integrität | Mechanismus zur Authentifizierung von ePHI (adressierbar) | Versionierte Datensätze, manipulationssichere Audit-Daten, getestete Backups und Wiederherstellungen |
| Audit-Kontrollen | Standard: Aktivitäten aufzeichnen und prüfen | Zentrale, nur anfügbare Protokolle aller Lese- und Schreibvorgänge; Warnungen bei ungewöhnlichem Zugriff |
| Minimale notwendige Datenverwendung | Standard der Privacy Rule | Rollenbasierter Zugriff, Sichtbarkeit auf Feldebene, aufgabenbezogene Oberflächen |
| Entwicklungs- und Testdaten | Teil der Risikoanalyse | Synthetische oder anonymisierte Daten; Scan auf Identifikatoren in Protokollen und CI |
| Multi-Tenancy | Zugriffskontrolle, Audit-Kontrollen und kundenspezifische BAA-Bedingungen | Schlüssel pro Mandant; Mandantenkennung auf Datenebene erzwungen und getestet; mandantenbezogene Audit-Logs; Offboarding pro Mandant |
| EHR-Integrationen | Übertragungssicherheit; BAAs | FHIR mit SMART-Scopes; Bedrohungsmodell pro Integration; BAA-Register |
| Cloud und Anbieter | BAA erforderlich | Nur abgedeckte Dienste; Zugriff auf Protokolle und Vorfallsbedingungen im BAA festlegen; keine ePHI an Tools ohne Vereinbarung |
| Vorbereitung auf Datenpannen | Breach Notification Rule (60 Tage) | Getestetes Runbook, Erkennung, benannte Verantwortliche, Kontaktkette |
| Dokumentation | Aufbewahrung über sechs Jahre (164.316) | Entscheidungen als Architecture Decision Records festgehalten; Risikoanalyse aktuell gehalten |
Kein einzelnes Feature. Eine App ist dann HIPAA-konform, wenn die dahinterstehende Organisation ihre Risiken bewertet, die geltenden Sicherheitsvorkehrungen der Security Rule umgesetzt, Business Associate Agreements (BAAs) mit allen Parteien geschlossen hat, die ePHI verarbeiten, und dies alles dokumentiert hat. Der Code, das Hosting und der Papierkram zählen gleichermaßen.
In dieser Reihenfolge: Risikoanalyse, Sicherheitsvorkehrungen, Vereinbarungen, Nachweise. Beginnen Sie mit einer dokumentierten Risikoanalyse und entwerfen Sie dann die erforderlichen Schutzmaßnahmen: Verschlüsselung, rollenbasierter Zugriff, Audit-Logging und sichere Integrationen. Schließen Sie BAAs mit Ihren Cloud- und Tool-Anbietern ab, testen Sie auf Schwachstellen, halten Sie Ihre Entscheidungen schriftlich fest und überprüfen Sie diese regelmäßig. Das ist der Prozess, der hinter der meisten professionellen Entwicklung HIPAA-konformer Apps steht.
Kurz gesagt: ePHI ist bei der Übertragung und Speicherung verschlüsselt, der Zugriff ist nach Rolle und Zweck beschränkt, jeder Lese- und Schreibvorgang wird in einem geschützten Speicher protokolliert, Testumgebungen sind frei von echten Patientendaten, Integrationen sind auf das Minimum beschränkt und jeder Anbieter unterliegt einem BAA. Die obige Checkliste macht jeden dieser Punkte zu einem Bestandteil der Designprüfung.
Es gibt keine ehrliche Pauschalsumme, da die Kosten vom Umfang abhängen. Fünf Variablen bestimmen den Großteil: die Anzahl der Datenspeicher, die ePHI enthalten, die Anzahl der Integrationen (jede benötigt ein eigenes Bedrohungsmodell und eine eigene Vereinbarung), die Anzahl der Testzyklen, der Dokumentationsaufwand und die Frage, ob Sie ein neues Projekt auf der grünen Wiese starten oder ein bestehendes Produkt nachrüsten. Bei einem Neubau konzentriert sich der Aufwand auf das Design. Bei der Nachrüstung verteilt er sich auf alle Ebenen, meist während Patienten bereits auf das System angewiesen sind.
Für eine fundierte Kostenschätzung nennen Sie uns bitte die erwarteten Eckdaten, und wir ermitteln gemeinsam mit Ihnen den Aufwand über unsere Healthcare-Technologie-Lösungen Seite.
Nein. Das HHS unterstützt oder anerkennt keine privaten "HIPAA-Zertifizierungen", und kein Standard schreibt eine Zertifizierung der Konformität vor. Ein Anbieter kann ein Produkt als HIPAA-konform bezeichnen, aber die Konformität hängt davon ab, wie das System aufgebaut, konfiguriert und betrieben wird sowie von den Richtlinien und Vereinbarungen, die es umgeben. Unabhängige Bewertungen und Frameworks wie NIST SP 800-66 helfen Ihnen dabei, die Konformität nachzuweisen.
Fast, aber nicht namentlich. Die Verschlüsselung ist eine "addressable specification" (adressierbare Spezifikation) für Daten bei der Speicherung und Übertragung. Das bedeutet, Sie müssen sie implementieren, wenn dies angemessen und zweckmäßig ist, oder eine gleichwertige Alternative dokumentieren und begründen. In der Praxis ist es schwer zu rechtfertigen, darauf zu verzichten, und die Verschlüsselung unterstützt zudem die "Breach Safe Harbour"-Regelung.
Das HHS hat im Dezember 2024 eine Verschärfung der Security Rule vorgeschlagen, aber die aktuelle Regelung bleibt in Kraft.
Ja. Ein Cloud-Anbieter, der in Ihrem Auftrag ePHI verarbeitet, ist ein "Business Associate", und laut HHS verstößt die Nutzung eines solchen Anbieters ohne BAA gegen die HIPAA-Regeln. Dies gilt auch dann, wenn der Anbieter nur verschlüsselte Daten speichert.
Die Regelung macht dazu keine Angaben. Sie legt keinen Zeitraum für System-Logs fest, schreibt jedoch vor, dass erforderliche Dokumentationen sechs Jahre lang aufbewahrt werden müssen. Viele Teams nutzen dies auch als konservativen Standard für Logs. Klären Sie den korrekten Zeitraum mit Ihrer Rechtsabteilung ab, da die lokalen gesetzlichen Bestimmungen variieren können.
Das hängt davon ab, für wen Sie arbeiten. HIPAA findet Anwendung, wenn Sie eine „Covered Entity“ (abgedeckte Einrichtung) sind oder als Geschäftspartner ePHI im Auftrag einer solchen verarbeiten. Eine Verbraucher-App, die Daten direkt von Nutzern erhebt, fällt möglicherweise nicht unter HIPAA, obwohl andere Vorschriften, wie die FTC Health Breach Notification Rule sowie staatliche Datenschutzgesetze, dennoch gelten können. Holen Sie rechtlichen Rat ein, bevor Sie eine Annahme treffen.
Führen Sie zuerst die Risikoanalyse durch. Verschlüsseln Sie ordnungsgemäß, gewähren Sie nur den notwendigen Zugriff, protokollieren Sie jeden Zugriff, testen Sie auf Schwachstellen, betrachten Sie jede Integration und jeden Anbieter als potenzielles Einfallstor und dokumentieren Sie alles. Wenn Sie das tun, wird das Audit zu einer Routineprüfung statt zu einer Rettungsaktion. Sie bestimmen, wo die tragenden Wände stehen – also legen Sie diese frühzeitig fest.
Wenn Sie die Entwicklung einer Healthtech-Software planen oder ein bereits live geschaltetes Produkt überprüfen möchten, stehen wir Ihnen gerne für ein Gespräch zur Verfügung. Imaginary Cloud entwickelt seit 2010 Technologien für das Gesundheitswesen. Stellen Sie uns ruhig zuerst die schwierigen Fragen.
Wie wir mit Teams im Gesundheitswesen zusammenarbeiten, erfahren Sie auf unserer Healthtech-Lösungen Seite. Dort finden Sie auch Beispiele für unsere Healthtech-Entwicklungen, wie zum Beispiel VestaConnect und Jinga Life.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud, einer Agentur für Softwareentwicklung und UX/UI-Design mit Niederlassungen in Portugal und Großbritannien. Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Er basiert auf Quellen von HHS, NIST, HL7 und FTC, geprüft am 21. Oktober 2026.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
.webp)
