Was macht Software HIPAA-konform: Eine Checkliste für Käufer

Keine Anwendung ist automatisch „HIPAA-konform“. HIPAA-Konformität ist eine fortlaufende organisatorische Verantwortung: Risikoanalyse, Richtlinien, Praktiken für Mitarbeitende, Überwachung von Dienstleistern und technische Schutzmaßnahmen müssen zusammenwirken. Software kann diese Verantwortung unterstützen—oder es erheblich erschweren, die Anforderungen zu erfüllen.

Für Käufer oder Technologieleiter lautet die nützliche Frage nicht „Ist dieses Produkt HIPAA-zertifiziert?“ Für Software gibt es keine offizielle HIPAA-Zertifizierung. Die bessere Frage lautet: Bietet dieses System unserer Organisation die Kontrollen, Nachweise und die betriebliche Transparenz, die erforderlich sind, um elektronisch geschützte Gesundheitsinformationen (ePHI) zu schützen?

Dieser Leitfaden erläutert, worauf Sie beim Kauf oder bei der Entwicklung von Software achten sollten, die ePHI verarbeitet, welche technischen Schutzmaßnahmen wichtig sind, was eine Vereinbarung über Geschäftspartner (Business Associate Agreement, BAA) nachweist und was nicht, und wie Sie einen Anbieter bewerten, ohne sich auf vage Aussagen wie „Sicherheit auf Enterprise-Niveau“ zu verlassen.

HIPAA-konforme Software im Überblick

Frage	Praktische Antwort
Kann Software HIPAA-zertifiziert sein?	Nein. HIPAA bietet kein formelles Zertifizierungsprogramm für Software.
Wer ist für die Konformität verantwortlich?	Die betroffene Einrichtung und gegebenenfalls ihre Geschäftspartner. Ein Anbieter kann Ihnen diese Verantwortung nicht abnehmen.
Was sollte Software bereitstellen?	Zugriffskontrollen, Audit-Kontrollen, Datenschutz, sichere Übertragung, Wiederherstellungsfähigkeit und Nachweise dafür, dass diese Kontrollen wie vorgesehen funktionieren.
Beweist eine BAA die Sicherheit?	Nein. Eine BAA legt vertragliche Verpflichtungen fest. Sie sollte durch Nachweise aus den Bereichen Architektur, Sicherheit und Betrieb gestützt werden.
Womit sollte ein Projekt beginnen?	Mit einer dokumentierten Risikoanalyse, die ermittelt, wo ePHI erstellt, gespeichert, übertragen, abgerufen und gesichert wird.

Wichtig: Dieser Artikel enthält allgemeine technische Informationen und stellt keine Rechtsberatung dar. Die HIPAA-Verpflichtungen hängen von Ihrer Rolle, Ihren Verträgen, Systemen, Rechtsordnungen und Ihrem Risikoprofil ab. Ziehen Sie bei Compliance-Entscheidungen qualifizierte Fachleute für Datenschutz, Sicherheit und Recht hinzu.

Inhaltsverzeichnis

• Was erfordert HIPAA-konforme Software tatsächlich?
• Zu bewertende oder zu entwickelnde technische Schutzmaßnahmen
• Administrative und physische Schutzmaßnahmen
• Was eine Vereinbarung über Geschäftspartner leistet—und was nicht
• Checkliste für die Sorgfaltspflicht gegenüber Anbietern
• Häufige Fehler bei der Implementierung
• Ein praktischer Implementierungsplan
• Wie Ridiculous Engineering helfen kann
• FAQ
• Quellen

Was erfordert HIPAA-konforme Software tatsächlich?

Die HIPAA-Sicherheitsregel gliedert Schutzmaßnahmen in drei Kategorien: administrative, physische und technische. Software fällt hauptsächlich in die technische Kategorie, kann jedoch fehlende Richtlinien, unklare Zuständigkeiten, ungeschulte Mitarbeitende, eine unzureichende Überwachung von Dienstleistern oder eine Organisation, die nicht weiß, wo sich ihre ePHI befinden, nicht ausgleichen.

Das US-Gesundheitsministerium betrachtet eine dokumentierte Risikoanalyse als Grundlage der Sicherheitsregel. Bevor Sie Kontrollen auswählen, muss Ihre Organisation verstehen:

• Welche Systeme ePHI erstellen, empfangen, pflegen oder übertragen
• Wo ePHI gespeichert wird, einschließlich Backups, Protokollen, Exporten und Analyseplattformen
• Welche Benutzer, Administratoren, Anbieter und Subunternehmer darauf zugreifen können
• Wie Daten zwischen Anwendungen, Geräten, Umgebungen und Integrationen übertragen werden
• Was die Vertraulichkeit, Integrität oder Verfügbarkeit nach vernünftigem Ermessen beeinträchtigen könnte
• Welche Schutzmaßnahmen diese Risiken auf ein angemessenes Niveau reduzieren

Dieses Inventar ist außerdem ein guter Ausgangspunkt für Softwareberatung und Unterstützung bei der Bereitstellung. Viele Compliance-Probleme werden nicht durch ein einziges fehlendes Sicherheitsmerkmal verursacht. Sie entstehen durch eine unklare Systemgrenze: Eine Produktionsanwendung wird kontrolliert, aber ein Support-Export, eine Analyse-Replik oder eine Drittanbieterintegration nicht.

Verpflichtende vs. adressierbare Vorgaben

Die HIPAA-Implementierungsvorgaben werden entweder als verpflichtend oder als adressierbar kategorisiert.

• Verpflichtende Vorgaben müssen wie formuliert umgesetzt werden.
• Adressierbare Vorgaben müssen bewertet werden. Wenn eine Vorgabe in Ihrer Umgebung nicht angemessen und geeignet ist, müssen Sie dokumentieren, warum, und gegebenenfalls eine gleichwertige alternative Schutzmaßnahme umsetzen.

„Adressierbar“ bedeutet nicht optional. Es bedeutet, dass die Entscheidung risikobasiert getroffen, dokumentiert und vertretbar begründet werden muss. Verschlüsselung ist ein häufiges Beispiel: HIPAA schreibt keine einheitliche Umsetzung für jedes System vor, aber eine Organisation, die sich gegen die Verschlüsselung von ePHI entscheidet, benötigt eine überzeugende, dokumentierte risikobasierte Begründung.

HIPAA-Dokumentation, einschließlich Richtlinien, Verfahren, Risikobewertungen und zugehöriger Aufzeichnungen, muss gemäß 45 CFR §164.316 im Allgemeinen sechs Jahre lang aufbewahrt werden.

Zu bewertende oder zu entwickelnde technische Schutzmaßnahmen

Technische Schutzmaßnahmen sollten in der Anwendungsarchitektur, der Cloud-Konfiguration, den betrieblichen Runbooks und den Nachweisen, die ein Anbieter vorlegen kann, erkennbar sein. Eine Funktionscheckliste reicht nicht aus; die Kontrollen müssen korrekt implementiert und dauerhaft betrieben werden.

1. Eindeutige Identität und Zugriffskontrolle

Jeder Benutzer, der auf ePHI zugreift, sollte eine individuelle Identität haben. Gemeinsame Konten erschweren die Zugriffsüberprüfung, die Untersuchung von Vorfällen und die Deaktivierung beim Ausscheiden unnötig.

Mindestens sollten Sie Folgendes bewerten:

• Eindeutige Benutzer-IDs statt gemeinsam genutzter Zugangsdaten
• Rollenbasierte oder attributbasierte Zugriffskontrolle, die an die beruflichen Verantwortlichkeiten gebunden ist
• Mehrfaktor-Authentifizierung für privilegierte und Remote-Zugriffe
• Sitzungs-Timeouts und erneute Authentifizierung für sensible Aktionen
• Formalisierte Prozesse für Eintritt, Positionswechsel und Austritt
• Regelmäßige Zugriffsüberprüfungen, insbesondere für Administratoren und Supportmitarbeiter

Ein Benutzer aus der Abrechnung benötigt möglicherweise Zugriff auf demografische Daten und Anspruchsinformationen, jedoch nicht auf klinische Notizen. Ein Supporttechniker benötigt möglicherweise Zugriff auf betriebliche Telemetriedaten, jedoch keinen uneingeschränkten Zugriff auf Patientenakten. Diese Unterscheidungen sollten im Autorisierungsmodell abgebildet werden und nicht allein der Richtlinie überlassen bleiben.

2. Prüfkontrollen und aussagekräftige Protokolle

HIPAA verlangt Mechanismen zur Aufzeichnung und Überprüfung von Aktivitäten in Systemen, die ePHI enthalten oder verwenden. In der Praxis sollten aussagekräftige Prüfprotokolle beantworten: wer was an welchem Datensatz wann und von wo aus getan hat und ob die Aktion erfolgreich war.

Bei Anwendungen, die sensible Gesundheitsdaten verarbeiten, umfassen protokollierte Ereignisse häufig:

• Authentifizierungsversuche und Kontosperrungen
• Ansichten, Änderungen, Exporte und Löschungen von Patientenakten
• Änderungen von Berechtigungen und Rollen
• Administrativer Zugriff und Support-Aktionen
• Massenhafter Datenzugriff oder ungewöhnliches Abfrageverhalten
• Integrationsfehler und Wiederholungsversuche im Zusammenhang mit ePHI

Protokolle sollten vor unbefugten Änderungen geschützt, gemäß Ihren Richtlinien und Risikoanforderungen aufbewahrt und nach einem festgelegten Verfahren überprüft werden. Ein Protokoll, das zwar vorhanden ist, aber nie überwacht wird oder während einer Untersuchung nicht durchsucht werden kann, liefert nur unvollständige Belege für die Wirksamkeit der Kontrollen.

3. Datenschutz, Verschlüsselung und Schlüsselverwaltung

Schützen Sie ePHI während der Übertragung durch aktuelle Transportverschlüsselung, in der Regel TLS. Schützen Sie gespeicherte ePHI durch eine Verschlüsselung, die dem Risiko und der Systemarchitektur angemessen ist, einschließlich Datenbanken, Objektspeicher, Backups und gegebenenfalls mobiler Geräte.

Verschlüsselung ist nur so nützlich wie ihre Schlüsselverwaltung. Klären Sie, wer für die Schlüssel verantwortlich ist, wo sie gespeichert werden, wie der Zugriff kontrolliert wird, ob die Schlüssel regelmäßig erneuert werden und was geschieht, wenn ein Zugangsdaten- oder Schlüsselmaterial offengelegt wird.

Der NIST-Leitfaden zu den HIPAA-Sicherheitsregeln ist eine nützliche technische Referenz, um Schutzmaßnahmen den Überlegungen zur Umsetzung zuzuordnen. Er ersetzt keine Risikoanalyse, ist aber erheblich nützlicher als ein Sicherheitsslogan eines Anbieters.

4. Integrität, Änderungsmanagement und sichere Bereitstellung

Systeme benötigen Kontrollen, die dazu beitragen, eine unzulässige Änderung oder Zerstörung von ePHI zu verhindern. Bei kundenspezifischer Software bedeutet dies, Bereitstellungen und Änderungen an der Infrastruktur als Teil des Compliance-Bereichs zu behandeln.

• Nutzen Sie Peer-Reviews und kontrollierte Quellcode-Repositories.
• Trennen Sie Entwicklungs-, Test- und Produktionsumgebungen.
• Beschränken Sie den Produktionszugriff und protokollieren Sie privilegierte Aktionen.
• Testen Sie sicherheitsrelevante Abläufe vor der Veröffentlichung.
• Halten Sie Verfahren für Rollbacks und die Reaktion auf Vorfälle vor.
• Verfolgen Sie Abhängigkeiten und spielen Sie Sicherheitspatches über einen verwalteten Prozess ein.

Diese Praktiken sind zentral für eine zuverlässige Entwicklung kundenspezifischer Software. Nachträglich Prüfprotokolle, Berechtigungen und betriebliche Kontrollen einzuführen, nachdem ein Produkt bereits echte Patientendaten angesammelt hat, ist deutlich schwieriger, als die Grenzen von Anfang an korrekt zu gestalten.

5. Backup, Wiederherstellung und Verfügbarkeit

Verfügbarkeit ist Teil des Schutzes von ePHI. Backups sollten verschlüsselt, zugriffskontrolliert und überwacht werden sowie durch tatsächliche Wiederherstellungsübungen getestet werden. Eine Backup-Strategie, die unter realistischen Bedingungen noch nie wiederhergestellt wurde, ist eine Annahme und keine Wiederherstellungsfähigkeit.

Definieren Sie Wiederherstellungsziele, die zu den klinischen oder betrieblichen Auswirkungen eines Systemausfalls passen. Ein Portal zur Patiententerminplanung, ein System für das Versorgungsmanagement und eine Plattform für historische Analysen können jeweils unterschiedliche Ziele für Wiederherstellungszeit und Wiederherstellungspunkt erfordern.

Administrative und physische Schutzmaßnahmen sind weiterhin wichtig

Software ist ein Teil des Systems. Die HIPAA-Compliance hängt auch von administrativen und physischen Schutzmaßnahmen ab, die keine Anwendung allein bereitstellen kann.

Administrative Schutzmaßnahmen

• Benannte Datenschutz- und Sicherheitsbeauftragte mit klar definierten Befugnissen
• Dokumentierte Risikoanalyse und Risikomanagementprozess
• Richtlinien für Zugriff, zulässige Nutzung, Reaktion auf Vorfälle und die Überwachung von Anbietern
• Schulungen für Mitarbeitende und Nachweise über deren Durchführung
• Ein Sanktionsverfahren für Richtlinienverstöße
• Regelmäßige Überprüfung von Systemaktivitäten und Sicherheitsereignissen

Physische Schutzmaßnahmen

Physische Schutzmaßnahmen können Arbeitsplatzkontrollen, Geräteinventarisierung, Verfahren zur Entsorgung von Datenträgern, Zugangskontrollen zu Einrichtungen sowie die Überprüfung der von Cloud- und Hosting-Anbietern bereitgestellten physischen Schutzmaßnahmen umfassen. Eine ordnungsgemäß entwickelte Anwendung kann ePHI nicht schützen, die auf einen nicht verwalteten Laptop kopiert oder auf ein nicht genehmigtes USB-Laufwerk exportiert wurde.

Patientenorientierte Systeme sollten auch für die Menschen benutzbar sein, die sie benötigen. Bei Portalen und Workflows, die von Patienten, Mitarbeitenden oder Betreuungspersonen genutzt werden, sollten Sicherheitsanforderungen gemeinsam mit Anforderungen an Barrierefreiheit und Benutzerfreundlichkeit entwickelt werden. Unsere UX-Design- und Barrierefreiheitspraxis kann Teams dabei helfen, zu vermeiden, dass ein sicherer Workflow in einen Workflow verwandelt wird, den Nutzer umgehen, weil er unnötig schwer zu bedienen ist.

Was ein Business-Associate-Vertrag leistet – und was nicht

Ein Anbieter ist in der Regel ein Business Associate, wenn er ePHI im Auftrag einer betroffenen Einrichtung oder eines anderen Business Associates erstellt, empfängt, verwaltet oder übermittelt. Die Beziehung erfordert in der Regel einen Business-Associate-Vertrag (BAA).

Ein BAA sollte zulässige Verwendungen von ePHI, Schutzpflichten, Verantwortlichkeiten für die Meldung von Vorfällen und Datenschutzverletzungen, Anforderungen an Unterauftragnehmer sowie Verfahren zur Rückgabe oder Vernichtung von ePHI bei Vertragsbeendigung festlegen. Die organisatorischen Anforderungen sind in 45 CFR §164.314.

Ein unterzeichneter BAA ist jedoch ein Vertrag und kein Beleg dafür, dass technische Kontrollen wirksam sind. Bevor Sie sich auf einen Anbieter verlassen, fordern Sie Nachweise an, die für den Dienst und das Risikoprofil angemessen sind:

• Architektur- und Datenflussdiagramme, aus denen hervorgeht, wo ePHI gespeichert und übermittelt wird
• Eine Liste der Unterauftragsverarbeiter sowie eine Bestätigung, dass die BAA-Pflichten entlang der Lieferkette weitergegeben werden
• Verfahren für Zugriffskontrolle und Identitätsmanagement
• Beispiele für Audit-Protokolle oder eine klare Erläuterung der verfügbaren Audit-Ereignisse
• Verfahren für Schwachstellenmanagement und Patchen
• Prozesse für Backups, Wiederherstellung und Reaktion auf Sicherheitsvorfälle
• Relevante unabhängige Sicherheitsbewertungen mit klar angegebenem Umfang und Datum

„Wir sind HIPAA-konform“ ohne unterstützende Dokumentation ist keine vollständige Antwort im Beschaffungsprozess. Ebenso wenig ist es die Aussage „unser Cloud-Anbieter ist konform“. Ihre Implementierung, Konfigurationen, Datenflüsse und betrieblichen Verfahren sind weiterhin entscheidend.

Checkliste für die Due-Diligence-Prüfung von Anbietern

Verwenden Sie diese Fragen in einer Ausschreibung, Sicherheitsprüfung, Beschaffungsbesprechung oder technischen Anforderungsanalyse.

• Wo werden ePHI gespeichert, verarbeitet, gesichert und protokolliert?
• Welche Mitarbeiterrollen können auf Produktionsdaten zugreifen, und wie wird dieser Zugriff genehmigt und überprüft?
• Kann privilegierter Zugriff zeitlich begrenzt, protokolliert und widerrufen werden?
• Welche Audit-Ereignisse werden erfasst, wie lange werden Protokolle aufbewahrt und wie können sie exportiert werden?
• Wie werden Verschlüsselungsschlüssel geschützt, abgerufen und regelmäßig erneuert?
• Welche Unterauftragnehmer haben Zugriff auf ePHI, und bestehen entlang der gesamten Kette BAAs?
• Wie schnell wird der Anbieter Ihre Organisation über einen vermuteten Sicherheitsvorfall informieren?
• Wie werden Schwachstellen identifiziert, priorisiert und behoben?
• Wie häufig werden Backups wiederhergestellt und Wiederherstellungsverfahren getestet?
• Kann das System die Anforderungen Ihrer Organisation an Zugriffskontrolle, Aufbewahrung und Audits ohne individuelle Umgehungslösungen unterstützen?

Für Führungsteams, die zwischen einer gekauften Plattform und einem maßgeschneiderten System entscheiden, ist unsere Checkliste für die Softwareentscheidung „Eigenentwicklung oder Kauf“ als Ergänzung zu dieser Bewertung hilfreich. HIPAA-Anforderungen machen nicht automatisch kundenspezifische Software erforderlich, zeigen aber häufig, wo das Datenmodell, die Berechtigungen oder die Integrationsbeschränkungen eines Standardprodukts nicht zum tatsächlichen Betriebsmodell passen.

Häufige Fehler bei der Implementierung

Die meisten Vorfälle werden nicht durch exotische Angriffe verursacht. Sie entstehen durch gewöhnliche Kontrollen, die nie entworfen, konfiguriert, getestet oder einer verantwortlichen Person zugewiesen wurden.

• Anzunehmen, dass ein BAA die Implementierung konform macht.Verträge sind wichtig, aber sie konfigurieren keine Berechtigungen und validieren keine Backup-Wiederherstellung.
• Gemeinsam genutzte Konten verwenden.Gemeinsame Zugangsdaten beeinträchtigen die Nachvollziehbarkeit und machen das Entfernen von Zugriffsrechten beim Ausscheiden von Mitarbeitenden riskant.
• Zu wenig protokollieren.Anmeldungen zu erfassen, aber keine Aufrufe sensibler Datensätze, Exporte oder administrativen Aktionen, schafft blinde Flecken.
• Cloud-Speicher oder Entwicklungsumgebungen ungeschützt zu lassen.Nicht produktive Daten, Test-Backups und Exporte werden häufig weniger sorgfältig geprüft als Produktivsysteme.
• Wiederherstellungstests auszulassen.Ein Backup-Prozess, der nie getestet wurde, kann genau dann ausfallen, wenn die Organisation ihn am dringendsten benötigt.
• Breiten Administrationszugriff „vorübergehend“ zu gewähren.Vorübergehender Zugriff überdauert häufig den Notfall, der ihn ursprünglich rechtfertigte.
• Integrationen zu ignorieren.ePHI wird häufig über Schnittstellen, Warteschlangen, Analysetools, Supportsysteme und Benachrichtigungsdienste übertragen.

Integrationen verdienen besondere Aufmerksamkeit, weil Daten eine gut kontrollierte Anwendung über einen unzureichend kontrollierten nachgelagerten Workflow verlassen können. Wenn Ihr Projekt Reporting, operative Dashboards oder Datenpipelines umfasst, beziehen Sie Datenanalyse und Business Intelligencefrühzeitig ein, um eine angemessene Datenminimierung, Zugriffskontrollen und Governance für replizierte Datensätze zu etablieren.

Ein praxisnaher Implementierungsplan

Betrachten Sie die HIPAA-Vorbereitung nicht als abschließende Checkliste vor dem Launch. Integrieren Sie sie in den Bereitstellungsprozess.

1. Daten- und Systemgrenzen abbilden.Identifizieren Sie jede Stelle, an der ePHI eingeht, übertragen wird, gespeichert ist, gesichert wird oder auf die zugegriffen werden kann.
2. Eine Risikoanalyse durchführen und dokumentieren.Priorisieren Sie Risiken nach Wahrscheinlichkeit, Auswirkungen und der Wirksamkeit bestehender Schutzmaßnahmen.
3. Verantwortlichkeiten festlegen.Weisen Sie die Verantwortung für Datenschutz, Sicherheit, Zugriffsüberprüfungen, Reaktion auf Vorfälle, Lieferantenmanagement und Wiederherstellungstests zu.
4. Kontrollen in die Architektur integrieren.Integrieren Sie Autorisierung, Nachvollziehbarkeit, Verschlüsselung, sichere Integrationen und Wiederherstellung in das System, statt sie nach Fertigstellung der Kernanwendung hinzuzufügen.
5. Vor dem Einsatz in der Produktion validieren.Testen Sie Zugriffsgrenzen, Audit-Ereignisse, Verfahren für Vorfälle, Backups und kritische Workflows anhand realistischer Datenflüsse.
6. Betreiben und verbessern.Überprüfen Sie Zugriffe, beheben Sie Schwachstellen, bewerten Sie Risiken nach wesentlichen Änderungen neu, testen Sie die Wiederherstellung und halten Sie die Dokumentation aktuell.

Wenn die Software KI für die Dokumentenverarbeitung, die Patientenkommunikation, die Unterstützung bei der Triage, den Wissensabruf oder die Workflow-Automatisierung nutzt, unterziehen Sie diese Komponente einer eigenen Risiko- und Governance-Prüfung. Die KI-Funktion ändert die HIPAA-Verpflichtungen nicht und wirft praktische Fragen zu Modellzugriff, Datenaufbewahrung, Evaluierung und menschlicher Aufsicht auf. Dies sind Bereiche, in denen KI-Entwicklung und Automatisierungmit derselben Sorgfalt wie der Rest der Anwendung konzipiert werden sollten.

Gesundheitssoftware ohne Rätselraten entwickeln

Ridiculous Engineering unterstützt Organisationen bei der Konzeption und Entwicklung kundenspezifischer Systeme unter Berücksichtigung realer betrieblicher Anforderungen: rollenbasierter Zugriff, aussagekräftige Audit-Trails, sichere Integrationen, kontrollierte Bereitstellungsprozesse und eine Architekturdokumentation, die sowohl technische als auch Compliance-Verantwortliche nutzen können.

Wir zertifizieren Organisationen nicht als HIPAA-konform und ersetzen weder Rechtsberatung noch Datenschutzbeauftragte, Sicherheitsbeauftragte oder formelle Risikoanalysen. Wir können mit diesen Beteiligten zusammenarbeiten, damit die technische Umsetzung den Risikoentscheidungen und der tatsächlichen Bereitstellungssituation der Organisation entspricht.

FAQ

Gibt es so etwas wie HIPAA-zertifizierte Software?

Nein. HIPAA bietet keine offizielle Zertifizierung für Softwareprodukte. Die Compliance hängt davon ab, wie ein reguliertes Unternehmen oder Geschäftspartner Systeme entwirft, konfiguriert, betreibt und verwaltet, die ePHI verarbeiten.

Macht die Unterzeichnung eines BAA einen Anbieter HIPAA-konform?

Nein. Ein BAA legt vertragliche Verantwortlichkeiten für den Umgang mit ePHI fest. Es weist nicht nach, dass die Zugriffskontrollen, Protokollierung, Verschlüsselung, Reaktion auf Vorfälle oder Wiederherstellungsprozesse eines Anbieters angemessen sind oder wirksam funktionieren.

Was ist der Unterschied zwischen verpflichtenden und adressierbaren HIPAA-Spezifikationen?

Verpflichtende Spezifikationen müssen umgesetzt werden. Adressierbare Spezifikationen müssen bewertet werden, um festzustellen, ob sie für die Umgebung der Organisation angemessen und geeignet sind. Entscheidungen und alternative Schutzmaßnahmen müssen gegebenenfalls dokumentiert werden.

Wie lange müssen HIPAA-Dokumentationen aufbewahrt werden?

HIPAA-Richtlinien, -Verfahren, Risikoanalysen und zugehörige Dokumentationen müssen im Allgemeinen sechs Jahre ab dem Erstellungsdatum oder dem Datum, an dem sie zuletzt gültig waren, aufbewahrt werden.

Kann maßgeschneiderte Software die HIPAA-Compliance unterstützen?

Ja. Maßgeschneiderte Software kann HIPAA-Verpflichtungen unterstützen, wenn sie mit geeigneten Zugriffskontrollen, Prüfbarkeit, sicherem Datenhandling, zuverlässigen Integrationen und betrieblichen Prozessen entwickelt wird. Die Organisation benötigt weiterhin eine Risikoanalyse, Richtlinien, Aufsicht sowie qualifizierte rechtliche und Compliance-Beratung.

Quellen

• U.S. Department of Health and Human Services: Leitfaden zur Risikoanalyse
• Electronic Code of Federal Regulations: HIPAA-Sicherheitsstandards
• 45 CFR §164.314: Organisatorische Anforderungen und Verträge mit Geschäftspartnern
• 45 CFR §164.316: Anforderungen an Richtlinien, Verfahren und Dokumentation
• NIST SP 800-66 Rev. 2: Umsetzung der HIPAA-Sicherheitsregel

Empfohlen

• Software selbst entwickeln oder kaufen: Eine Entscheidungscheckliste für Führungskräfte
• Entwicklung maßgeschneiderter Software
• Softwareberatung und Unterstützung bei der Umsetzung
• UX-Design und Barrierefreiheit

```