Die flächendeckende Etablierung einrichtungsübergreifender Elektronischer Patientenakten (eEPA) setzt die Bewältigung einer Reihe sowohl technischer als auch gesellschaftlicher Herausforderungen voraus. Eine ganz konkrete – so zeigt es eine kürzlich von der Bertelsmann Stiftung veröffentlichte Expertise – ist die Beantwortung der Frage: Wie und durch wen wird geregelt, wer zu welchem Zeitpunkt und vor welchem Kontext auf bestimmte Daten in einer eEPA zugreifen darf? Dabei sind zahlreiche Interessen zu wahren: allen voran die Souveränität des Patienten und dessen Recht auf informationelle Selbstbestimmung. In diesem Beitrag beleuchten wir eine attributbasierte Rechteverwaltung als ein mögliches Lösungsszenario – und liefern im Sinne eines Ideenpapiers die Erklärung, wie ein solches Zugriffsmanagement für eEPA-Systeme konkret aussehen kann.


„eEPA-Systeme müssen über ein differenziertes Berechtigungsmanagement verfügen. Die Formulierung von Rechte-Policies muss für Patienten praktikabel, in ihren Auswirkungen nachvollziehbar und verständlich sein.“ So lautet eine Kernaussage der kürzlich von der Bertelsmann Stiftung veröffentlichten Expertise zu Elektronischen Patientenakten.

Ein solches Berechtigungsmanagement ist im Kontext der eEPA deutlich komplexer, als wir es beispielsweise von den Privatsphäre-Einstellungen sozialer Netzwerke oder unserer Smartphones kennen. Die Gründe: Neben dem Recht auf informationelle Selbstbestimmung müssen auch Ziel und Zweck der eEPA eines Patienten erhalten bleiben: der sinnvolle behandlungsunterstützende Datenzugang zwischen Leistungserbringern und Patient zur Verbesserung der Versorgung. Zudem sollen neben Arzt und Patient potenziell etliche weitere Akteure auf – zumindest ausgewählte – Daten einer Akte zugreifen können, um das interdisziplinäre Potenzial voll ausschöpfen zu können. Man denke dabei zum Beispiel an Pflegedienste (Medikationspläne, medizinische Verordnungen), Physiotherapeuten, Psychotherapeuten und viele andere mehr. Und die Inhalte einer Akte sind eben weitaus differenzierter und verschiedenartiger, als bei anderen privaten Anwendungen.

Wir beschreiben im Folgenden einen aus vier Bausteinen bestehenden Lösungsansatz, welcher die notwendigen Anforderungen an ein vielschichtiges Berechtigungsmanagement erfüllen kann – und dabei auch die Möglichkeit bietet, Zugriffsszenarien abzubilden, deren Notwendigkeit heute noch nicht gesehen wird.

Den Überlegungen liegt die Prämisse zugrunde, dass eine reine Zugriffsmatrix (Wer darf genau auf was zugreifen?) schnell unübersichtlich und schwierig zu pflegen wird.

Baustein 1: Die zugriffsrechterelevante Attributwelt

Das dem Lösungsansatz dieses Beitrags zugrundeliegende Modell heißt „Attribute-Based Access Controll“ (ABAC). Es scheint sich besonders für solche Anwendungsfälle durchzusetzen, in denen kritische Informationen differenzierter Struktur und Semantik unterschiedlichsten Nutzern mit bestimmten Eigenschaften zugängig gemacht werden sollen. Denn ABAC unterscheidet sich von klassischen rollenbasierten Modellen (Rolle „Arzt“ darf x und y, Rolle „Pflegepersonal“ darf nur y) dadurch, dass sich sehr komplexe und beliebig granulare Zugriffsberechtigungen in relativ einfacher sowie natürlicher Art und Weise abbilden lassen. Hierzu spielen Attributausprägungen des Zugreifenden („Sicherheitssubjekt“) und Attributausprägungen des Informationsobjektes, welches eingesehen, eingefügt, geändert oder gelöscht werden soll, eine wichtige Rolle („Jeder Radiologe darf nur Röntgenbefunde einsehen“). Dabei können auch implizite Attributentsprecheungen benutzt werden (wie die Übereinstimmung von Fachgebiet des Arztes und Dokumenttyp, Beispie: Fachgebiet = „Rad“ für „Radiologe“, Dokumenttyp = „Rad“ für „Radiologischer Befund“). So könnte man analog generisch definieren, dass alle Ärzte einer bestimmten Fachgruppe nur jene Befunde einsehen dürfen, die ihrer Fachgruppe entsprechen – mit nur einer oder wenigen Regeln.

Der Trick: Es können auf Basis einer Vielzahl definierter Attribute unzählige Zugriffsregeln formuliert und so die individuellen Wünsche gut abgebildet werden – es werden sinngemäß bei jeder Zugriffsanfrage für diese Anfrage zutreffende Regeln angewendet und durchgesetzt. Dabei können im Falle der eEPA zum Beispiel folgende Eigenschaften, die sich dann in Eigenschaftsattributen der entsprechenden Objekttypen wiederfinden müssen, eine Rolle spielen:

  • Eigenschaften des Sicherheitssubjekts
    • Welche fachliche Rolle hat eine Person (Arzt bzw. Fachgruppe, Pflegekraft, Physiotherapeut etc.)?
    • Welche Rolle spielt eine Person im Care-Team (Hausarzt bzw. spezieller Facharzt, Pflegeperson, Apotheker, Angehöriger)?
    • Welcher Einrichtung zugehörig (Hausarztpraxis, Gemeinschaftspraxis Dres. Meyer und Müller, Klinikum Musterstadt, Stamm-Apotheke)?
    • Welche Beziehungsrolle nimmt die Person in Bezug zum Patienten ein?
  • Eigenschaften der (Trans)aktion
    • Welche Handlung(en) will das Sicherheitssubjekt bezüglich des Sicherheitsobjektes durchführen (Daten lesen, verändern, hinzufügen, löschen)?
    • Wie häufig geschieht das (einmalig, regelmäßig)?
  • Eigenschaften der angefragten Ressource bzw. des Sicherheitsobjektes
    • Von welchem Typ ist das Sicherheitsobjekt (z.B. Arztbrief, Diagnose, Medikation, Abrechnungsdokument, Notfalldaten, etc.)?
    • Welches Datum trägt es (von heute, max. x Tage alt)?
    • Welche Vertraulichkeit hat es (normal, vertraulich, streng vertraulich)?
  • Eigenschaften des Kontextes
    • Technischer Kontext, zum Beispiel: Über welches Gerät greift das Subjekt zu (Smartphone, Tablet, Laptop oder stationärer Rechner)?
    • Zeitlicher Kontext, zum Beispiel: Zu welchem Zeitpunkt geschieht der Zugriff (an einem Werktag, innerhalb der Öffnungszeiten der dem Subjekt zugehörigen Einrichtung)?
    • Behandlungskontext, zum Beispiel: In welcher Behandlungssituation wird eine Aktion durchgeführt (Notfall, stationäre Aufnahme, ambulanter Arztbesuch, Auftragsleistung etc.)?

Man erkennt: Die Attribut-Sets sind umfangreich und lassen sich beliebig ergänzen. Jede Anfrage an eine eEPA – gemeint ist damit beispielsweise der Abruf eines Dokuments oder auch das Einfügen einer Diagnose – umfasst eine individuelle Kombination aus Attributen des Sicherheitssubjektes und -objektes mit verknüpfenden Bedingungen. Am Ende muss auf dieser Basis entschieden werden: Wird die Anfrage bzw. Aktion genehmigt oder abgelehnt?

Von hoher Bedeutung: Nationale Konsentierung

Es ist daher evident, die für Datenschutzmechanismen einer eEPA entscheidenden Eigenschaftattribute von Akteuren und Datenobjektklassen und deren Wertebereiche von Beginn an festzulegen und im Kern national zu konsentieren – wie zum Beispiel einen Facharztgruppenkatalog (den es schon gibt) und eine Dokumententaxonomie, also eine Klassifikation der Versorgungsdokumente (die es leider noch nicht gibt). Beliebige lösungsspezifische Erweiterungen sind dann denkbar.

Ob Zugriff auf bestimmte Daten einer eEPA gewährt oder abgelehnt wird, entscheidet sich anhand der Ausprägungen vieler Attribute einer Zugriffs-Anfrage
Im dargestellten Fall ist geregelt, dass das Pflegepersonal einer bestimmten Klinik immer Lesezugriff auf Diagnose und Medikation des Patienten hat, sofern die Daten nicht älter als sieben Tage sind.

Baustein 2: Die Zugriffspolicy

Soll der Bürger souverän entscheiden können, welche Person oder welches System auf bestimmte Daten seiner eEPA zugreifen darf, muss er entsprechende Regeln definieren können. Das Aufstellen dieser Regeln – hier in ihrer Summe weiter als Zugriffspolicy bezeichnet – ist aufgrund der Vielzahl von zu berücksichtigenden Faktoren eine komplexe Aufgabe, die für den Patienten aber so einfach und so natürlich wie möglich abgebildet werden sollte. Die folgende exemplarische Aufzählung von Fragen verdeutlicht dies, sie ließe sich beliebig lange erweitern:

  • Darf ein Radiologe, der bei Verdacht auf einen Schienbeinbruch eine Röntgendiagnostik durchführt, nur auf Vorbefunde des betroffenen Beins zugreifen, oder auf alle früher erstellten Röntgenbilder? Soll er auch Risikofaktoren oder die Notfalldaten des Patienten sehen können?
  • Darf das Pflegepersonal im Krankenhaus nur bis zum Tag der Entlassung eines Patienten auf dessen aktuellen Medikamentenplan zugreifen, oder auch noch eine definierte Zeit danach – oder immer?
  • Kann der Patient wissen und entscheiden, welche Daten er einem Arzt zur Verfügung stellen muss, wenn er von diesem eine fundierte Zweitmeinung erhalten will?

Baustein 3: Der Policy-Editor

Praktisch wird daher für Patienten – aber auch für andere Akteure, die Zugriffsrechte vergeben sollen können – eine einfache Oberfläche benötigt (wir wollen diese im Weiteren „Policy-Editor“ nennen), mittels der gewünschte Rechte formuliert werden können – und zwar sowohl auf sehr grober Ebene („Alle meine Ärzte dürfen alles.“) oder eben auch feingranular wie in vorangehenden Beispiel angedeutet.

Unsere Idee: Ein wissenschaftlich validierter, intelligenter und verständlich formulierter Fragenkatalog soll dem Bürger helfen, seine individuelle Zugriffspolicy eigenständig zu erarbeiten. Ziel muss hierbei sein, diese auf Basis von Aussagen wie beispielsweise „Mein Hausarzt soll alle Inhalte meiner Akte sehen können“ durch einen klugen Algorithmus automatisiert erstellen zu lassen. Dabei kommt einem solchen Ansatz zugute, dass bei natürlicher Betrachtung der Betroffene sowieso das, was er möchte, regelartig formulieren würde:

  • „Im Notfall sollen alle Heilberufler meine Notfalldaten einsehen können“ oder
  • „Daten zu meiner chronisch-entzündlichen Darmerkrankung sollen nur mich aktuell behandelnde Ärzte sehen können.“
  • „Daten zu meiner Angststörung und Verschreibungen zugehöriger Medikamente dürfen nur mein Hausarzt und mein Psychosomatiker sehen.“

Wie in der Expertise beschrieben kennt die Akte auch das aktuelle Behandlungsteam und weiß also, wer „mein Hausarzt“ und „mein Psychosomatiker“ ist.

Eine Zugriffspolicy muss sich selbstverständlich jederzeit neu definieren und um Sonderregelungen – wie die gezielte Blockierung des Zugriffsrechts einzelner Personen – ergänzen lassen. Gegebenenfalls reicht es sogar aus, Ausschlüsse zu definieren, statt kleinteilig Rechte zu vergeben (ohne den eigentlichen Zweck der Patientenakte konterkarieren zu dürfen):

  • „Psychiatrische Diagnosen sollen nur von meinem Psychiater und meinem Hausarzt eingesehen werden können“ oder
  • „Niemand außer der verordnende Arzt soll sehen, dass ich Viagra erhalte.“
Prototyp einer eEPA-Anwendung (Elektronische Patientenakte) für Patienten
Dieser Prototyp einer eEPA-Anwendung für Patienten zeigt in einem Ausschnitt, wie der Nutzer anhand aufeinanderfolgender einfacher Fragen seine persönliche Zugriffspolicy generieren kann.

Für die Bürger, welche keine individuelle Zugriffspolicy definieren möchten oder können, sollte eine Standard-Policy bereitgestellt werden. Diese kann gleichzeitig als „Startwert“ bzw. „Initialisierungs-Policy“ dienen, bis im Bedarfsfall ein patientenindividuelles Regelwerk erstellt wird. Es wäre eine gesellschaftliche Aufgabe, eine solche „Standard-Policy“ vor ethischem und zugleich pragmatischem Hintergrund zu definieren und zu konsentieren. Denkbar ist auch die Bereitstellung vordefinierter Zugriffspolicies für verschiedene Personengruppen – Kinder, Patienten mit seltenen Erkrankungen, Pflegebedürftige – oder die Erstellung von Policies unter Hinzuziehen von vertrauenswürdiger ärztlicher Beratung, professioneller Patientenberatung, jeweils auch durch Begleitung von Angehörigen.

Darüber hinaus kann das System der Zugriffspolicies auch Wenn-Dann-Szenarien abbilden: Vorstellbar ist, dass ein Bürger verschiedene Policy-Varianten definiert, die unter neuen Bedingungen automatisch gültig werden – beispielsweise beim Übergang in eine Situation, in welcher eine Person nicht mehr selbst handlungs- oder entscheidungsfähig ist.

Eine individuelle Zugriffspolicy entsteht, indem der Bürger eine Sammlung leicht verständlicher und intelligent verknüpfter Fragen zu seinem "Datenverhalten" beantwortet
Der Fragenkatalog für die Erstellung und Generierung einer individuellen Zugriffspolicy kann beispielsweise direkt in eine eEPA-Anwendung für Patienten integriert werden.

Baustein 4: Die Autorisierungs-Engine

Die Attribute sind essenziell zur Formulierung und Steuerung der Berechtigungen, dienen in Verbindung mit der Zugriffspolicy letztendlich aber nur als „Futter“ für eine Autorisierungs-Engine. Die Engine, ein Programmcode, verarbeitet die Attribute in Kombination mit den Regeln der Policy zu den Entscheidungen, ob eine Person im konkreten Fall eine Anfrage an die eEPA genehmigt bekommt. Sie stellt den Policy Decision Point dar.

Ein konkretes Beispiel: Der Hausarzt eines Patienten möchte beim Verschreiben eines neuen Medikaments prüfen, ob in der Patientenakte eine Unverträglichkeit gegen dieses Medikament verzeichnet ist. Die Anfrage wird an die Autorisierungs-Engine weitergeleitet, diese prüft basierend auf den ihr übermittelten Attributen die Regeln in der Zugriffspolicy.

Die Engine liefert letztendlich die Entscheidung, dass der Hausarzt in dieser konkreten Situation berechtigt ist – und gewährt dem Anfragenden Zugriff auf das Ergebnis der Unverträglichkeits-Prüfung.

Die Autorisierungs-Engine trifft basierend auf der individuellen Zugriffspolicy und den Attributen einer Anfrage die Entscheidung, ob Zugriff auf die eEPA gewährt wird oder nicht
Das Zusammenspiel von auf dem Fragenkatalog basierender Zugriffspolicy, individuellen Attributen einer Anfrage und der daraus resultierenden Entscheidung der Autorisierungs-Engine

Weitere Aspekte: Authentizität des Nutzers und Sinnhaftigkeit der Policy

Die Regelung der Zugriffs-Berechtigungen – also die Autorisierung – sind ein wesentlicher, aber eben nur ein Teil des Datenschutz- und Datensicherheit-Komplexes einer eEPA. Nicht vergessen darf man daher: Die beste Zugriffspolicy wirkt nur dann, wenn hinter den Zugreifenden auch tatsächlich die Person steckt, für die sie sich ausgibt – daher ist Authentizität aller Beteiligten eine wichtige Voraussetzung für das Funktionieren von eEPA-Systemen.

Darüber hinaus steht eine weitere wichtige Frage zur Diskussion: Kann ein Bürger die Zugriffspolicy seiner eEPA frei definieren, könnten potenziell auch Regelwerke entstehen, die den eigentlichen Zweck der Patientenakte konterkarieren. So wären Behandlungsfehler, die aufgrund fehlender Zugriffsrechte des Arztes entstehen, das genaue Gegenteil vom erwarteten Zugewinn an Versorgungsqualität. Policies brauchen also Rahmenbedingungen, die verhindern, dass eEPA-Systeme ihren eigenen Nutzen in Frage stellen.

Zusammenfassung

Moderne Konzepte des Zugriffsmanagements in Anwendungssystemen setzen auf ABAC, womit basierend auf Eigenschaften von Zugreifenden und verwalteten Informa-tionsobjekten flexible Zugriffsrechte definiert werden können.

Ein System aus personalisierter Zugriffspolicy und intelligenter Autorisierungs-Engine kann basierend auf der Ausprägung von Attributen der beteiligten Subjekte und Objekte sowie dem Kontext einer Zugriffs-Anfrage im Sinne des jeweiligen Bürgers entscheiden, ob eine solche Anfrage genehmigt oder abgelehnt wird. Damit diese Berechtigungs-Lösung praxistauglich wird, muss die Ausgestaltung der Policy für den Bürger sehr einfach möglich und jederzeit anpassbar sein, wozu ein entsprechender intelligenter Policy-Editor notwendig wird.

Darüber hinaus brauchen wir einen nationalen Dialog- und Verständigungsprozess, um die Anforderungen an Zugriffspolicies festzulegen und notwendige Voraussetzungen zu konsentieren.


Dieser Artikel ist Teil einer Reihe von Beiträgen rund um das Thema Elektronische Patientenakten. Dabei werden wir in unregelmäßigen Abständen einzelne in der Expertise von Peter Haas analysierte Aspekte aufgreifen und auch andere Akteure zu Wort kommen lassen.

Weiterführende Links:


Abonnieren Sie jetzt unseren Newsletter, um zukünftig per E-Mail über neue Blog-Beiträge informiert zu werden.