Covered Entity, Business Associate, Subcontractor: die Rollenfrage unter HIPAA

Problem in der Praxis

Rollenfragen werden in Vertragsverhandlungen oft vom Kunden beantwortet, und zwar in seinem Interesse: Ein US-Krankenhaus wird jeden Dienstleister mit Datenzugang als Business Associate behandeln wollen, ein Dienstleister möchte die Rolle vermeiden. Beides kann falsch sein. Wer zu Unrecht ein BAA unterschreibt, übernimmt vertragliche Pflichten ohne gesetzlichen Grund; wer die Rolle zu Unrecht verneint, verarbeitet PHI ohne die vorgeschriebenen Zusicherungen und haftet für Verstöße gegen die Security Rule.

Typische Grauzonen bei deutschen Anbietern: der Fernwartungszugang zu Medizingeräten, die Telemetrie eines Geräts, die Diagnosedaten enthält, der Support-Mitarbeiter, der im Ticket Screenshots mit Patientendaten erhält, und der Konzern-IT-Dienstleister, der für eine US-Tochter mit Klinikbetrieb Systeme betreibt.

CISO-Einordnung

Die Rollen im Einzelnen, nach 45 CFR 160.103:

• Covered Entity. Health Plan, Health Care Clearinghouse oder Health Care Provider, der Gesundheitsinformationen elektronisch im Zusammenhang mit einer von der Verordnung erfassten Transaktion übermittelt. Erfasste Transaktionen sind unter anderem Abrechnungsansprüche, Zahlungen, Anspruchs- und Leistungsprüfungen, An- und Abmeldungen und Beitragszahlungen.
• Business Associate. Wer im Auftrag einer Covered Entity, aber nicht als Teil ihrer Workforce, PHI für eine regulierte Funktion erstellt, empfängt, speichert oder übermittelt, etwa für Abrechnung, Datenanalyse, Qualitätssicherung oder Practice Management, oder wer für sie Rechts-, Beratungs-, Buchhaltungs-, Datenaggregations-, Management-, Verwaltungs-, Akkreditierungs- oder Finanzdienstleistungen erbringt, bei denen PHI offengelegt wird. Ausdrücklich eingeschlossen sind Datenübermittler mit routinemäßigem Zugriff und Anbieter persönlicher Gesundheitsakten im Auftrag einer Covered Entity.
• Subcontractor. Person, an die ein Business Associate eine Funktion, Tätigkeit oder Dienstleistung delegiert, außer als Workforce-Mitglied; verarbeitet sie dabei PHI, ist sie selbst Business Associate.
• Workforce. Beschäftigte, Freiwillige, Auszubildende und andere Personen unter direkter Kontrolle der Stelle, bezahlt oder nicht. Wer zur Workforce gehört, ist kein Business Associate.

HHS nennt in seiner Leitlinie zu Business Associates unter anderem folgende Beispiele: Cloud-Anbieter, die ePHI im Auftrag speichern oder verarbeiten; IT-Dienstleister wie EHR-Anbieter oder Managed Services Provider, deren Wartung oder Support die Verarbeitung von ePHI erfordert; Techniker, die ein Gerät mit gespeicherter PHI warten (Kopierer, Medizingerät), wenn die Wartung die Offenlegung von PHI umfasst; KI-Chatbots von Drittanbietern in Patientenportalen; App-Entwickler, die im Auftrag einer Covered Entity eine Gesundheits-App betreiben; Kanzleien mit PHI-Zugang.

Keine Business Associates sind nach derselben Leitlinie unter anderem Leistungserbringer, denen PHI zur Behandlung übermittelt wird, Dienstleister ohne PHI-Bezug mit allenfalls beiläufigem Zugang (Reinigung, Elektriker) und reine Übermittler ("conduit") wie Post, Kurierdienste und ihre elektronischen Entsprechungen. Die Conduit-Ausnahme ist eng: Sie gilt nur für reine Übermittlung mit vorübergehender Zwischenspeicherung. Wer PHI speichert, ist kein Conduit, auch wenn er die Daten nicht einsehen kann.

Zur Verschlüsselung hält die HHS-Leitlinie zu Cloud Computing fest: Ein Cloud-Anbieter, der nur verschlüsselte ePHI ohne Schlüssel speichert ("no-view"), ist trotzdem Business Associate. Die Pflichten der Security Rule sind dann skalierbar, und einzelne Anforderungen wie Zugriffskontrollen können durch die Maßnahmen einer Partei für beide erfüllt werden; die Meldepflicht gegenüber dem Auftraggeber bei Verletzungen bleibt.

Zur Speicherung außerhalb der USA beantwortet dieselbe Leitlinie die Frage mit ja, sofern ein BAA besteht und die HIPAA Rules eingehalten werden. Die Rules enthalten keine eigenen Anforderungen für ePHI außerhalb der USA; OCR weist aber darauf hin, dass die Risiken je nach Ort stark variieren und in Risikoanalyse und Risikomanagement einzubeziehen sind.

Sonderfall US-Tochter als Arbeitgeber: Ein Group Health Plan im Sinne von 45 CFR 160.103 (betrieblicher Gesundheitsplan nach ERISA mit 50 oder mehr Teilnehmern oder Verwaltung durch einen Dritten) ist ein Health Plan und damit Covered Entity. Der Arbeitgeber ist als Plan Sponsor kein Business Associate, soweit die Vorgaben des 45 CFR 164.504(f) eingehalten sind: Die Plandokumente müssen Nutzung und Offenlegung beschränken und eine angemessene Trennung zwischen Plan und Sponsor vorsehen; ohne diese Beschränkung dürfen Summary Health Information zur Ausschreibung oder Änderung des Plans, Angaben zum Teilnahmestatus und Informationen aufgrund einer Authorization des Betroffenen nach 45 CFR 164.508 an den Sponsor fließen. Für ePHI verlangt 45 CFR 164.314(b) zusätzlich, dass die Plandokumente den Sponsor zu angemessenen Sicherheitsmaßnahmen und zur Meldung von Sicherheitsvorfällen verpflichten, mit denselben Ausnahmen.

Umsetzungsperspektive

• Rollenprüfung je Dienstleistung, nicht je Kunde: Dasselbe Unternehmen kann für ein Produkt Business Associate sein und für ein anderes nicht.
• Datenflüsse belegen: Welche PHI erreichen das Unternehmen tatsächlich, über welche Kanäle (Produktdaten, Support, Fernwartung, Telemetrie, Backups)?
• Support- und Wartungsprozesse so gestalten, dass PHI nur dort ankommt, wo es fachlich nötig ist; jeder zusätzliche Kanal erweitert den HIPAA-Bereich.
• Eigene Subunternehmer mit PHI-Zugriff identifizieren: Hosting, Ticketsystem, Fernwartungswerkzeuge, Offshore-Support. Für jeden ist ein eigenes BAA nötig (hipaa-003).
• Bei US-Töchtern mit Group Health Plan die Trennung von Plan und Personalabteilung organisatorisch und technisch umsetzen.

Typische Fehler

1. Die Rolle wird verneint, weil die Daten verschlüsselt sind und das Unternehmen keinen Schlüssel hat.
2. Ein Speicher- oder Backupdienst beruft sich auf die Conduit-Ausnahme, obwohl er PHI dauerhaft hält.
3. Die Fernwartung von Medizingeräten wird ohne Prüfung der PHI-Offenlegung als reine Technik behandelt.
4. Support-Kanäle (Tickets, Screenshots, Logdateien) werden bei der Rollenprüfung vergessen.
5. Die US-Personalabteilung erhält Leistungsdaten aus dem Gesundheitsplan, ohne dass die Plandokumente das regeln.

Risiken und Trade-offs

Eine großzügige Rollenannahme schafft Vertragssicherheit gegenüber Kunden, weitet aber den Bereich aus, in dem Security Rule, Meldepflichten und Haftung greifen. Eine enge Rollenannahme spart Aufwand, setzt aber voraus, dass Datenflüsse technisch wirklich ausgeschlossen sind; ein einziger Support-Fall mit Patientendaten kann die Annahme widerlegen. Produktentscheidungen wie Ende-zu-Ende-Verschlüsselung verringern das Risiko, ändern aber nach HHS-Leitlinie nichts an der Rolle eines speichernden Anbieters.

Entscheidungspunkte

• Für welche Produkte und Dienste verarbeitet das Unternehmen PHI im Auftrag von US-Covered-Entities oder US-Business-Associates?
• Lassen sich PHI aus Support und Wartung technisch fernhalten, oder ist die Rolle als Business Associate anzunehmen?
• Welche eigenen Dienstleister werden dadurch zu Subcontractors?
• Ist der Group Health Plan jeder US-Tochter als Covered Entity erkannt und vom Personalbereich getrennt?

Praktische Empfehlungen

1. Prüfen Sie die Rolle je Dienstleistung anhand der Definitionen in 45 CFR 160.103 und der HHS-Beispiele.
2. Dokumentieren Sie die PHI-Flüsse einschließlich Support, Fernwartung, Telemetrie und Backups.
3. Behandeln Sie Speicherung verschlüsselter ePHI ohne Schlüssel als Business-Associate-Tätigkeit.
4. Erfassen Sie alle eigenen Dienstleister mit PHI-Zugriff als potenzielle Subcontractors.
5. Beziehen Sie den Speicherort der ePHI ausdrücklich in die Risikoanalyse ein.

Relevante Normreferenzen

• 45 CFR 160.102 (Anwendungsbereich), 160.103 (Covered Entity, Business Associate, Subcontractor, Workforce, Group Health Plan, PHI, Transaction).
• 45 CFR 164.504(f) und 164.314(b) (Group Health Plan und Plan Sponsor).
• HHS OCR, Business Associates (Stand 30.07.2026) und Guidance on HIPAA & Cloud Computing (Stand 23.12.2022).