Die Compliance-Annahme, die Gesundheitsorganisationen falsch machen
Jede Gesundheitsorganisation, die Cloud-AI-Tools einsetzt, erhält denselben Rat von ihrem Rechtsteam: Unterzeichnen Sie eine Business Associate Agreement (BAA) mit dem Anbieter, und Sie sind unter HIPAA abgesichert.
Die BAA-Anforderung ist real. Die Datenschutzregel von HIPAA verlangt von den betroffenen Einrichtungen, BAAs mit Geschäftspartnern abzuschließen – Anbieter, die geschützte Gesundheitsinformationen in ihrem Auftrag erstellen, empfangen, aufbewahren oder übermitteln. Der AI-Anbieter, der Ihre klinischen Notizen verarbeitet, benötigt eine BAA, bevor er auf diese Daten zugreift.
Aber die BAA-Anforderung bezieht sich auf die vertragliche Beziehung zwischen den Organisationen. Sie behandelt nicht, was mit PHI auf der Infrastruktur des Anbieters passiert, nachdem der Vertrag unterzeichnet wurde.
Die entscheidende Frage ist nicht, ob Sie eine BAA haben. Es ist, ob der Anbieter auf Ihre PHI im Klartext zugreifen kann – und was mit diesen Daten passiert, wenn er einen Verstoß erleidet.
Was eine Business Associate Agreement tatsächlich abdeckt
Eine BAA legt fest, dass ein Geschäftspartner:
- PHI nur für die im Vertrag festgelegten Zwecke verwendet
- Angemessene Sicherheitsvorkehrungen zum Schutz von PHI implementiert
- Jeden PHI-Verstoß der betroffenen Einrichtung meldet
- PHI bei Vertragsbeendigung zurückgibt oder vernichtet
Die BAA ist eine vertragliche Verpflichtung. Der Geschäftspartner verpflichtet sich, PHI verantwortungsbewusst zu behandeln, angemessene Sicherheitsmaßnahmen zu implementieren und die betroffene Einrichtung zu benachrichtigen, wenn etwas schiefgeht.
Was die BAA nicht tut:
- Verhindern, dass die Systeme des Geschäftspartners verletzt werden
- Den technischen Zugriff des Geschäftspartners auf PHI in entschlüsselter Form beseitigen
- Die betroffene Einrichtung vor der HIPAA-Haftung schützen, wenn der Geschäftspartner verletzt wird
Wenn ein Cloud-AI-Anbieter verletzt wird und sein serverseitiger Speicher Ihre Patienten-PHI in entschlüsselbarer Form enthält, wird die Verpflichtung zur Benachrichtigung über den Verstoß durch die BAA erfüllt – aber die PHI-Exposition ist real, Patienten sind geschädigt, und die betroffene Einrichtung sieht sich unabhängig von dem unterzeichneten Vertrag einer HIPAA-Durchsetzungsuntersuchung gegenüber.
Das serverseitige PHI-Problem
Cloud-AI-Tools, die Gesundheitsdaten verarbeiten, arbeiten auf einer grundlegenden Architektur: Die Daten reisen zu den Servern des Anbieters, werden dort vom AI-Modell verarbeitet und die Ergebnisse werden an den Benutzer zurückgegeben. Damit dies funktioniert, muss die Infrastruktur des Anbieters Zugriff auf die Daten in einer Form haben, die das AI-Modell verarbeiten kann.
Das bedeutet, dass die Daten entweder unverschlüsselt auf den Servern des Anbieters vorliegen oder die Verschlüsselung vom Anbieter mit Schlüsseln, die der Anbieter kontrolliert, durchgeführt wird.
Von dem Anbieter kontrollierte Verschlüsselung ist keine End-to-End-Verschlüsselung. Wenn der Anbieter die Schlüssel hält, kann der Anbieter entschlüsseln. Wenn der Anbieter entschlüsseln kann, exponiert ein kompromittierter Server des Anbieters Ihre Daten in lesbarer Form.
Dies ist die Architektur, die BAAs nicht ansprechen. Die BAA verlangt vom Anbieter, "angemessene Sicherheitsvorkehrungen" zu verwenden – aber die serverseitige Verschlüsselung, die vom Anbieter kontrolliert wird, erfüllt diese Anforderung vertraglich, obwohl sie keinen Schutz gegen Verstöße auf der Seite des Anbieters bietet.
Gesundheitsdaten, die unter diesen Bedingungen von Cloud-AI verarbeitet werden, haben ein spezifisches Risikoprofil: Die PHI, die zur Erstellung von AI-unterstützter klinischer Dokumentation, Abrechnungscodes oder Pflegeplänen verwendet wird, existiert in der Infrastruktur des Anbieters in einer Form, die gelesen werden kann, wenn diese Infrastruktur kompromittiert wird.
Die Durchsetzung von HIPAA unterscheidet nicht zwischen "wir wurden verletzt, aber wir hatten eine BAA" und "wir wurden verletzt." Die PHI der Patienten der betroffenen Einrichtung wurde exponiert. Die betroffene Einrichtung hatte die Verpflichtung, sie zu schützen. Die technische Umsetzung dieses Schutzes bestimmt, ob die Verpflichtung erfüllt wurde – nicht der Vertrag.
Was die Zero-Knowledge-Architektur ändert
Die Zero-Knowledge-Architektur adressiert das Problem des serverseitigen Zugriffs auf architektonischer Ebene.
In einer Zero-Knowledge-Implementierung wird PHI anonymisiert, bevor sie die Umgebung der betroffenen Einrichtung verlässt. Der AI-Anbieter erhält anonymisierte Daten – klinische Notizen mit Patientenidentifikatoren, die durch strukturierte Tokens ersetzt wurden, Abrechnungsunterlagen mit Namen und Kontonummern ersetzt, Pflegepläne ohne demografische Informationen.
Das AI-Modell verarbeitet den anonymisierten Inhalt und gibt Ergebnisse zurück. Die betroffene Einrichtung verknüpft die Ergebnisse mit dem ursprünglichen Patientenakte mithilfe der Token-Zuordnung, die nie an den Anbieter übertragen wurde.
Was sich dadurch ändert:
Der Anbieter erhält niemals PHI. Klinische Notizen, die durch Zero-Knowledge-Anonymisierung verarbeitet werden, enthalten keine Namen, Geburtsdaten, Adressen, medizinischen Aktennummern oder andere von HIPAA definierte PHI-Identifikatoren. Das AI-Modell des Anbieters arbeitet mit anonymisierten Daten.
Ein Verstoß des Anbieters exponiert keine PHI. Wenn die Infrastruktur des AI-Anbieters kompromittiert wird, enthält die dort gespeicherte Daten anonymisierte Inhalte ohne patientenidentifizierbare Informationen. Der Verstoß kann nicht zu einer PHI-Exposition führen, da die PHI nie übertragen wurde.
BAA-Anforderungen werden auf einem höheren Standard erfüllt. Die betroffene Einrichtung hat technische Sicherheitsvorkehrungen implementiert, die über das vertragliche Minimum hinausgehen – nicht weil die BAA dies verlangt, sondern weil die Architektur die technische Exposition von PHI unmöglich macht, anstatt sie lediglich vertraglich zu verbieten.
Der Compliance-Standard, der tatsächlich gilt
Die Durchsetzung von HIPAA durch das HHS-Büro für Bürgerrechte konzentriert sich darauf, ob die betroffenen Einrichtungen angemessene und angemessene Sicherheitsvorkehrungen zum Schutz von PHI implementiert haben. "Angemessen und angemessen" wird im Hinblick auf das Risiko für PHI, die Wahrscheinlichkeit eines Verstoßes und die Kosten der verfügbaren Sicherheitsvorkehrungen bewertet.
Cloud-AI-Anbieter, die PHI unter BAAs verarbeiten, haben Verstöße erlebt. Das Risiko ist nicht hypothetisch. Die Frage, die die Durchsetzungsbeamten stellen, ist, ob die betroffene Einrichtung Sicherheitsvorkehrungen implementiert hat, die das bekannte Risikoprofil ihrer Anbieterbeziehungen adressieren.
Eine betroffene Einrichtung, die sich auf eine BAA und von dem Anbieter kontrollierte serverseitige Verschlüsselung verlassen hat, hat einen vertraglichen Ansatz für ein technisches Problem gewählt. Eine betroffene Einrichtung, die Zero-Knowledge-Anonymisierung implementiert hat, bevor sie PHI an AI-Anbieter überträgt, hat einen technischen Ansatz gewählt, der die Exposition beseitigt.
Der zweite Ansatz adressiert die Durchsetzungsfrage: Die PHI war nie im Besitz des Anbieters in verwendbarer Form. Es gibt keinen Verstoß zu melden, keinen Patienten zu benachrichtigen, keine Durchsetzungsuntersuchung zu beantworten – weil die Architektur den Fehlermodus unmöglich gemacht hat.
Für Gesundheitsorganisationen, die die Einführung von Cloud-AI bewerten, ist der Compliance-Rahmen nicht "holen Sie sich eine BAA und fahren Sie fort." Es ist "sicherstellen, dass PHI niemals in einer wiederherstellbaren Form in die Umgebung des Anbieters gelangt." Die BAA erfüllt die vertragliche Anforderung. Die Zero-Knowledge-Architektur erfüllt die technische.
Quellen: