Hintergrund (Einwilligung)

Patienten-Einwilligung

Eine Statuserhebung am Beispiel „Einweiserportal"

Autor: Jens-Uwe Thieme, iSoft/CSC
Stand: 4.10.12

Management Summary

Eine der Kernaufgabe von Krankenhausinformationssystemen (KIS) ist, neben der Darstellung und Speicherung von medizinischen Daten, ihre Funktion als patientenführendes System innerhalb einer Institution und die damit verbundene Abbildung der administrativ-organisatorischen Patientenaufnahme. Seit einigen Jahren steigt auch in diesem Bereich kontinuierlich der Aufwand für die Dokumentation an und insbesondere zur rechtlichen Absicherung bzw. als Rechtsgrundlage für die Behandlung und Therapie muss der Patient neben dem Behandlungsvertrag in aller Regel auch zur elektronischen Speicherung und Verarbeitung seiner Daten einwilligen, spätestens sobald Dritte eingebunden sind.

Mit dem steigenden Vernetzungsgrund zwischen den unterschiedlichen IT-Systemen im Gesundheitswesen, werden Patientendaten institutionsintern regelhaft elektronisch übertragen und verarbeitet, verlassen aber auch immer häufiger, im Sinne einer einrichtungsübergreifenden Kommunikation, die klassischen Grenzen des einzelnen Krankenhauses. Einmal wird dieser Trend durch eine verstärkte Kooperation im Gesundheitswesen, in Form neuer Vertragsformen (Selektivverträge, IV-Verträge) und zum anderen durch den steigenden Kostendruck und die vermehrte Inanspruchnahme externer Dienstleister für diverse Dienstleistungen (z.B. Erstellung von Abrechnungen, Archivierung,...) beflügelt.

In der Regel muss der Patient der Datenübermittlung und/oder der Datenverarbeitung im Auftrage (sofern keine gesetzliche Grundlage vorliegt) schriftlich zustimmen. Die Datenschutzgesetzgebung formuliert dabei die grundlegenden Anforderungen an eine solche Einwilligung, jedoch existiert diese weder als normierter - elektronisch interpretierbarer- Dokumentenstandard, noch wird eine solche „Einwilligungsweitergabe" zwischen IT-Systemen von den heute genutzten Kommunikationsprotokollen unterstützt.

Daraus folgt, dass jeder IT-Hersteller die Abbildung des Einwilligungsworkflows in seinem Produkt individuell abgebildet hat und normalerweise keine Schnittstellen existieren, um diese Informationen an andere Systeme zu kommunizieren. Vielmehr werden in einer Vielzahl von einzelnen Projekten (insbesondere auch zur intersektoralen Kommunikation) proprietäre Lösungen neuentwickelt, ohne dass sich bisher ein widerverwendbarer Standard herauskristallisiert hat.

Gleichzeitig werden die rechtlichen Rahmenbedingungen heutzutage technisch häufig im Kommunikationslayer umgesetzt und mittels organisatorischer Regelungen (bspw.: „Nimmt der Patient an einem IV-Programm teil") über das aktive Handeln der Aufnahmekraft abgebildet. Auf Grundlage dieser Überlegungen erscheint es sinnvoll, einen Nachrichten- und Kommunikationsstandard mit entsprechendem Workflow zu definieren und zur Nutzung in den Primärsystemen einzuführen, der diese Anforderungen abdeckt.

Use-Case „Aufnahme"

Als Grundlage für alle nachfolgenden Betrachtungen soll der Anwendungsfall einer „geplanten Aufnahme" in einer stationären Einrichtung dienen. Grundsätzlich lässt sich diese Szenario auch auf nicht-geplante Aufnahmen (Notfälle und ambulante Behandlungen) übertragen, jedoch unterliegen diese normalerweise leicht abgewandelten Mechanismen und insbesondere im Falle akuter Behandlungen steht die medizinische Therapie im Vordergrund. In diesen Fällen erfolgt die administrative Aufnahme meistens nachgelagert und zeitlich u.U. auch um einige Tage verzögert, jedoch unterliegt sie dann wieder denselben Vorgehensweisen. Analog gilt dies bei initial nicht einwilligungsfähigen (bspw. komatösen) Patienten, die nach dem Grundsatz der mutmaßlichen Einwilligung behandelt werden.

Der Patient wird im Regelfall vom niedergelassenen Haus- oder Facharzt mit einer „Verordnung von Krankenhausbehandlung" (allgemeinsprachlich: „Einweisung") an eine stationäre Einrichtung verwiesen und wird zu einem geplanten Termin aufgenommen. Der eigentliche Aufnahmevorgang ist in den verschiedenen Einrichtungen unterschiedlich geregelt und erfolgt im Erstkontakt (unabhängig von der Dringlichkeit) entweder immer über eine „zentrale Notaufnahme" (ZNA) oder für geplante Einweisungen über ein (zentrales oder dezentrales (je Fachabteilung)) Aufnahmesekretariat mit anschließender medizinischer Aufnahme.

In jedem Fall werden im ersten Schritt die Patientenstammdaten automatisch (z.B. mittels Einlesen der KV-Karte) oder manuell erfasst bzw. bei einem Wiederkehrer aus einem früheren Fall übernommen. Technisch wird zu diesem Zeitpunkt im KIS ein neuer Fall, der über eine Fallnummer eindeutig identifiziert ist, angelegt. Sofern der Patient im KIS bereits mit einer Patientennummer versehen war, so wird der Fall dieser zugeordnet, andernfalls wird neben dem Fall auch ein neuer Patient angelegt. In diesem Vorgang wird vom Patienten der behandelnden Hausarzt erfragt und sofern von der Einweisung abweichend, wird dieser und der einweisende Arzt in den Stammdaten des KIS ermittelt und zum Fall als Einweiser/Mitbehandler hinterlegt.

Das Krankenhaussystem unterstützt diesen Prozess i.d.R. indem die für die Behandlung notwendigen Dokumente, wie der Behandlungsvertrag, Patientenaufkleber, Information über die Zuzahlung bei vollstätionären Leistungen, „Buchung von Wahlleistungen" etc. automatisch ausgedruckt werden. Mit dem Behandlungsvertrag ist dabei häufig auch eine Einwilligungserklärung zur „Datenverarbeitung im Auftrage", z.B. zur Rechnungsstellung durch einen Dienstleister, gekoppelt. Der Patient oder ein berechtigter Vertreter erhält normalerweise einen Durchschlag für sich zur Kenntnis und unterschreibt die Originale zum Verbleib in der Akte.

„Nach dem Abschluss" der Aufnahme, die je nach Produkt in einem workflow-unterstützenden Assistenten realisiert ist, informiert – technisch gesehen - das KIS alle zu diesem Zeitpunkt angeschlossenen (Sub-)Systeme mit einer Nachricht (Aufnahmeevent) über den neuen Patienten/Fall. Alle Änderungen zum Patientenstatus, wie die Verlegung auf eine Station/Fachabteilung oder auch medizinische Maßnahmen, Beauftragung von Untersuchungen, werden von nun an vom KIS an die (relevanten) Subsysteme kommuniziert. Die angebundenen Systeme speichern dabei die Patienten- und Fallstammdaten und sofern notwendig den Patientenstatus bzw. die Auftragsdaten in einer eigenen Datenhaltung.

In vielen Einrichtungen muss dieser Aufnahmeprozess immer dann um weitere organisatorische Tätigkeiten ergänzt werden, wenn mit der Aufnahme bzw. nachgelagert weitere, insbesondere einrichtungsübergreifende, Kommunikationsprozesse verbunden sind. Dieser Fall liegt immer dann vor, wenn der Patient auf Grund der Mitgliedschaft zu einer Krankenkasse an einem IV-Vertrag mit elektronischer Datenübermittlung teilnimmt oder das Krankenhaus niedergelassenen bzw. mit- und nachbehandelnden Ärzten den elektronischen Zugriff auf die Falldaten (beispielsweise über ein sogenanntes Einweiserportal) ermöglicht.

Der Patient muss in diesen Fällen jeweils sein Einverständnis für die einzelne Datenübermittlung/Datenverarbeitung im Auftrage erklären. Damit die administrativen Prozesse möglichst schlank gehalten werden können, wird gerade im Nutzungskontext eines Einweiserportals, der Behandlungsvertag um eine weitere Seite, auf der der Patient sein Einverständnis für die Bereitstellung der Daten in dem Einweiserportal für die teilnehmenden Ärzte erklärt, ergänzt. Idealerweise wird dieser Vorgang durch die Software unterstützt (z.B. durch die Informationen zu Hausarzt, Spezialisten, einweisender Arzt, etc., die im KIS hinterlegt sind) und im Aufnahmeworkflow integriert.

Neben der vorgenannten Einschränkung ist dieser Anwendungsfall zum Zwecke der Übersichtlichkeit idealisiert dargestellt und prinzipiell müssten natürlich auch Voraufnahmen mit Bettenplanungen, etc. berücksichtigt werden.

Problemdarstellung

In der weiteren Betrachtung soll der Fokus auf die Abbildung der Einwilligungserklärungen in den Krankenhausinformationssystemen (KIS) gelegt werden. Dabei kann bedingt durch die Heterogenität der IT Lösungen keine Aussage für bestimmte Systeme getroffen, sondern vielmehr ein allgemeingültiger Überblick, gegeben werden.

Als Kernproblem zeigt sich, dass das KIS für alle Subsysteme im Krankenhaus zwar das patientenführende System darstellt und somit die „Hoheit" über die Daten inne hat, dabei jedoch die für Übermittlung an Dritte notwendigen Einwilligungserklärungen technisch nicht allgemeingültig umsetzen kann.

In den nachfolgenden Abschnitten sollen nun einmal kurz die rechtlichen und technischen Rahmengrundlagen dargestellt werden und abschließend ein möglicher Lösungsansatz vorgestellt werden.

Rechtliche Aspekte

Die Details der rechtlichen Aspekte und das Zusammenspiel zwischen den Regelungen des Datenschutzes (Gesetzte auf Bundes- und Landesebene), sowie den standesrechtlichen Rahmenbedingungen (namentlich der ärztlichen Musterberufsordnung) soll im weiteren nicht erörtert werden. Vielmehr soll für den konkreten Gegenstand der Fokus auf den Punkt der Notwendigkeit der Einwilligung in eine Datenübermittlung gelegt werden.

Personenbezogene Daten

Das Bundesdatenschutzgesetz (§ 3 Abs. 1 BDSG) definiert alle „Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person" als schützenswert, dies können beispielsweise sein

• den Familien- und Vornamen,
• die Anschrift,
• die Staatsangehörigkeit und
• den Beruf.

Dabei meint der Begriff „Datenschutz" im engeren Sinne den „Schutz des Einzelnen vor dem Missbrauch personenbezogener Daten", wobei heutzutage damit im Allgemeinen das Recht des Einzelnen auf seine informationelle Selbstbestimmung, so wie sie im „Volkszählungsurteil" vom 15.12.1983 durch das Bundesverfassungsgericht (BVerfG) definiert wurde, beschrieben wird. Diese abstrakte Umschreibung meint in der praktischen Anwendung, dass jeder Mensch selber bestimmen kann, wem er, zu welchem Zeitpunkt persönliche Informationen zur Kenntnis gibt. Gleichzeitig wurde festgestellt, dass es „ein belangloses personenbezogenes Datum im Zeitalter der EDV nicht geben kann" (BVerfGE 65, 1 = NJW 1984, 419) und somit jedes Datum für sich sensibel ist. Eine weitere Differenzierung der Schutzwürdigkeit bzw. des Schutzbedarfes erfolgt dabei nicht.

Datenschutzrelevante Tätigkeiten

Das Erhebung von Daten wird ist nach § 3 Abs. 3 BDSG definiert als „das Beschaffen von Daten über den Betroffenen" und meint, dass dies mit einer Aktivität, durch die die erhebende Stelle oder Person, einhergeht.

Die Verarbeitung personenbezogener Daten (gem. § 3 Abs. 4 BDSG) umfasst die Speicherung (Nr. 1), Veränderung (Nr. 2), Übermittlung (Nr. 3), Sperrung (Nr. 4) und Löschung (Nr. 5), wobei in diesem Zusammenhang das Speichern und Übermitteln als die relevantesten Verarbeitungsphasen definiert werden können.

Aus informationstechnischer Sicht meint die Speicherung (§ 3 Abs. 4 Nr. 1 BDSG), dass Daten auf einem Datenträger zum Zwecke ihrer weiteren Verwendung abgespeichert werden, wohin gegen das BDSG diesen Begriff weiter fasst und bereits das Erfassen, Aufnehmen oder Aufbewahren von Daten als Speicherung (z.B. auf einem Papiervordruck) definiert.

Mit dem Begriff der „Veränderung" (§ 3 Abs. 4 Nr. 2 BDSG) werden alle inhaltliche Modifikationen an Informationen bezeichnet, die die Intention eines Datum bzw. deren Informationsgehalt abändern.

Die „Übermittlung (§ 3 Abs. 4 Nr. 3 BDSG) bezeichnet die Bekanntgabe von Daten durch die verantwortliche Stelle (§ 3 Abs. 7 BDSG) an Dritte (§ 3 Abs. 8 BDSG) durch Weitergabe, Einsichtnahme oder Abruf.

Eine Forderung in der Wahrung des Rechts auf informationelle Selbstbestimmung ist die Möglichkeit des Betroffenen eine „Sperrung" (§ 3 Abs. 4 Nr. 4 BDSG) zum Zwecke der Einschränkung der weiteren Verarbeitung oder Nutzung zu fordern.

Darüber hinaus geht die Löschung (§ 3 Abs. 4 Nr. 5 BDSG) die als unwiderbringliche Unkenntlichmachung von Daten bezeichnet wird. Das in der IT genutzte Verfahren des logischen Löschen, also des ergänzen eines Datensatzes um einen Löschvermerk ist dabei nicht ausreichend. Ebenso müssen auch alle Sicherheitskopien bzw. archivierte Daten gelöscht werden.

Ermächtigungsgrundlagen

Nach dem Grundsatz des BDSG (§4) ist die Erhebung, Verarbeitung und Nutzung personenbezogener Daten erst mal nicht unzulässig, sofern nicht eine ausdrückliche gesetzliche Grundlage oder eine andere Rechtsvorschrift dies erlaubt oder anordnet bzw. der Betroffene eingewilligt hat, dass sein Recht auf informationelle Selbstbestimmung eingeschränkt wird.

Einwilligung

Die Einwilligung (§ 4a BDSG) ist in diesem Kontext besonders hervorzuheben, da sie in aller Regel die Rechtsgrundlage für die Verarbeitung (darunter sollen alle anderen Verwendungszwecke subsummiert sein) von Gesundheitsdaten darstellt und diese erst dann zulässig macht.

Die Einwilligung muss ohne Zwang, also aus freien Stücken und im Vollbesitz der geistigen Kräfte und ohne jeglichen sozialen, finanziellen, psychologischen oder sonstigen Druck, erfolgen. Der Einwilligende muss sich ebenso in Kenntnis des Zweckes der Verarbeitung seiner Daten befinden und auf seine Rechte (Einsicht, Sperrung, Korrektur, etc.) hingewiesen werden. Gleichzeitig sind im die Folgen einer Verweigerung zu erläutern (sog. „informierte Einwilligung, § 4a Abs. 1 Satz 2 BDSG). Jedoch darf an das Versagen einer Einwilligung kein Hinweis auf eine möglicherweise schlechtere medizinische Behandlung geknüpft sein, dies dem Abs. 1 (frei von Zwang) widersprechen würde.

Davon ausgenommen ist die Verarbeitung der Daten, wenn dies dem Schutz lebenswichtiger Interessen der betroffenen Person dient bzw. der Betroffene aus physischen oder rechtlichen Gründen außerstande ist, eine Einwilligung auszusprechen (vgl. EG Richtlinie 95/46/EG, § 677 ff. BGB, §35 STGB).

Im Rahmen der Einwilligung ist es nicht möglich, die Rechte auf Auskunft, Berichtigung, Sperrung und Löschung der Daten auszuschließen oder zu beschränken (§ 6 Abs.1 BDSG). Darüber hinaus Bedarf die Einwilligungserklärungen der Schriftform (§ 4 Abs. 2 BDSG), insbesondere da bei der Verarbeitung von Gesundheitsdaten immer davon ausgegangen werden kann, dass es sich um „besondere Arten personenbezogener Daten" nach § 3 Abs. 9 BDSG handelt.

Personenbezogene Daten besonderer Art

Alle Daten, „aus denen die rassische und ethnische Herkunft, politische Meinungen, religiöse oder philosophische Überzeugungen \[…\] hervorgehen, sowie von Daten über Gesundheit oder Sexualleben", werden nach der Europäischen Richtlinie 95/46/EG (Artikel 8) und dem Bundesdatenschutzgesetz (vgl. auch §3 Abs. 9 BDSG) zur Kategorie personenbezogener Daten besonderer Art gezählt. Dabei kann regelhaft davon ausgegangen werden, dass alle im stationären Umfeld kommunizierten Daten unter diese Regelungen fallen.

Nach Artikel 8 Absatz 1 ist grundsätzlich die Verarbeitung von Daten über die Gesundheit oder das Sexualleben nicht zulässig, sofern nicht eine der Ausnahmeregelungen aus Artikel 8 Absatz 2 und 3 der Richtlinie 95/46/EG zur Anwendung kommen kann. Diese Absätze definieren die Ausnahmentatbestände, analog den Regelungen der einschlägigen Berufsordnungen (s.o.), wobei die Notwendigkeit der Einwilligung durch den Patienten besonders hervorgehoben wird.

Zweckbindung

Die Erhebung und Verarbeitung von Patientendaten darf von einem Arzt oder einer Einrichtung nur zu einem konkreten Zweck erfolgen (z.B. Behandlungskontext). Dabei ist jegliche Sammlung personenbezogener Daten „auf Vorrat zu unbestimmten Zwecken" bzw. die Zweckentfremdung unzulässig. Das Speichern, Verändern, Übermitteln (...) ist nur im Rahmen der Zweckbestimmung des Vertragsverhältnisses oder zur Wahrung berechtigter Interessen des Arztes bzw. der Behandlungseinrichtung, soweit kein Grund zu der Annahme besteht, dass das schutzwürdige Interesse des Patienten an dem Ausschluss der Verarbeitung oder der Nutzung überwiegt, zulässig. (§ 28 BDSG).

Maßnahmen

Der Betreiber einer Einrichtung (privat oder öffentlich) muss, wenn er „selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten oder nutzt", geeignete „technische und organisatorische Maßnahmen \[..\] treffen, um die Anforderungen des Datenschutzes umzusetzen (§ 9 BDSDG). Der Zugang zu den Datenverarbeitungssystemen ist allen Unbefugten zu verwehren und es muss verhindert werde, dass Datenbestände unbefugt gelesen, kopiert oder verändert werden können bzw. Datenübertragungseinrichtungen durch unbefugt genutzt werden können.

Ebenso ist sicherzustellen, das berechtigte Personen ausschließlich auf die ihrer Zugriffsberechtigung unterliegenden Daten zurückgreifen können und überprüfbar festgestellt werden kann, welche Daten zu welcher Zeit von wem eingegeben worden sind bzw. an welche Stellen diese Daten automatisiert übermittelt wurden.

Aus den vorgenannten Erläuterungen wird deutlich, dass in einer stationären Einrichtung bei praktisch allen Kommunikationsvorgängen „personenbezogene Daten der besonderen Art" übertragen werden und somit als Grundlage für eine Verarbeitung und/oder Übertragung der Daten, die Einwilligung des Patienten in Schriftform vorliegen muss.

In diesem Zusammenhang muss beachtet werden, dass bereits das Einscannen von Dokumenten zum Zwecke der Archivierung, sofern diese Tätigkeit nicht unter Aufsicht des Klinikpersonals, beispielsweise in einem externen Büro erfolgt, eine Datenverarbeitung im Auftrage und zugleich eine unzulässige Offenbarung eines beruflichen Geheimnisses darstellt, sofern der Patient dieser nicht schriftlich zugestimmt hat.

Kommunikationsprotokolle

Die in Deutschland bestehende Trennung zwischen ambulanter und stationärer Versorgung spiegelt sich neben getrennten Vergütungsbudgets auch in der Nutzung unterschiedlicher Kommunikationsprotokolle wieder. Im Folgenden sollen die beiden wichtigsten Protokolle in beiden Sektoren für das allgemeine Verständnis kurz vorgestellt werden. Daneben findet sich noch eine Vielzahl anderer Standards (z.B. DICOM für die Bildkommunikation), die ebenfalls bedeutsam sind.

Im ambulanten Bereich wird hauptsächlich der von der kassenärztlichen Bundesvereinigung (KBV) gepflegte Standard „xDT" verwendet. Die Einführung dieses Formates geht auf die Überlegungen Ende der 1980er Jahre zurück und war getrieben von der vermehrten Einführung von EDV Systemen in den Praxen und die Einführung der Krankenversichertenkarte in der gesetzlichen Krankenversicherung (GKV) in den Jahren 1993/1994.

Dabei lag der Fokus für dieses Format nicht auf der Übermittlung von medizinischen Informationen, sondern diente der Einführung einer "elektronischen" Quartalsabrechnung. Bis zu diesem Zeitpunkt wurden viele Daten zwar bereits digital erfasst mussten aber für die Abrechnung wieder ausgedruckt und papiergebunden an die Kassenärztlichen Vereinigung (KV) übermittelt werden.

Als Alternative zu diesem Verfahren wurde der sogenannte ADT (AbrechnungsDatenTransfer) entwickelt, mit dem die Papierabrechnung durch die Übermittlung eines Diskettensatzes ersetzt wurde. Neben den ADT Satz wurden auch der Behandlungs-, Labor- und Gerätedatenträger spezifiziert, die als „Protokollfamilie" häufig auch mit xDT bezeichnet werden. Technisch ist das Format dabei an den EDIFACT Standard angelehnt und gegenüber modernen Formaten (z.B. auf XML-Basis) in Bezug auf Erweiterbarkeit und formale Validierung entsprechend limitiert.

Auch wenn heute keine Übermittlung der Daten immer Sinne eines Datenträgers erfolgt, sind Name und Format erhalten geblieben, dabei haben die Umsetzung in Form eines XML Dokumentes bisher keine Verbreitung gefunden.

Zur sicheren Übermittlung – hier Netzwerksicherheit über VPN und geschlossene Community mit Bezug zu den Zugriffsberechtigten – wird im ambulanten Bereich u.a. das KV-Safenet genutzt. Das KV-SafeNet ist eine Anbindungsmöglichkeit an das sichere Netz der [Kassenärztlichen Vereinigungen-http://de.wikipedia.org/wiki/Kassen%C3%A4rztliche_Vereinigung] (KVen), das die Kommunikation zwischen Leistungserbringern und KVen absichern und erleichtern soll. Es verbindet einzelne Arztpraxen, medizinische Einrichtungen und Krankenhäuser mit den Rechenzentren der KVen. Eine Zugangsberechtigung zum KV-SafeNet bekommen nur die von der KV zugelassenen Anwender. Der Zugang durch Unbefugte zum sicheren Netz der KVen, den darin übertragenen Daten und bereitgestellten Anwendungen und Diensten sowie den angeschlossenen PCs ist somit ausgeschlossen.

Dem gegenüber findet sich im stationären Sektor das HL7 Format als vorherrschendes Kommunikationsprotokoll. Das Format liegt in den beiden Majorversionen 2.x (textbasiert) und 3 (vom Reference Information Model (RIM) adaptierte XML Struktur) vor, wobei die Version 2 den weitverbreiteten Standard der Systemintegration innerhalb von Krankenhäusern darstellt. Obwohl das Format einen defacto Standard auf internationaler Ebene darstellt und in einem umfangreichen Normenwerk dokumentiert ist, gibt es eine Umsetzung in den Produkten, die der internationalen Standardisierung komplett folgt. Aus diesem Grunde ist HL7 heute im Feld keine Plug ‚n\' Play Protokoll sondern vielmehr müssen in der Regel Dienstleister beauftragt, um zwei Systeme untereinander zu verbinden.

Die Kommunikation erfolgt fast ausschließlich als Push Verfahren und Event-basiert. Dies wurde in dem einführenden Beispiel kurz erläutert, in dem das KIS bei dem Aufnahmeevent alle angeschlossenen Systeme über den neuen Patienten informiert. Auf Grund dieses Kommunikationsprinzips ist es normalerweise nicht vorgesehen, dass angeschlossene Systeme bestimmte Nachrichten nochmal anfordern können.

Auf Grund des Umstands, dass HL7-Nachrichten in herstellerspezifischen Ausprägungen genutzt werden und semantisch gleichbedeutende Nachrichten mit unterschiedlichen Events abgebildet werden können, müssen die Schnittstellen zwischen zwei kommunizierenden Systemen in der Regel individuell angepasst werden. In einer größeren Einrichtung kann es jedoch schnell notwendig sein, viele Systeme mit dem KIS zu verbinden, wobei die Anzahl der notwendigen Schnittstellen dabei schnell ansteigt („Problem der kombinatorischen Explosion").

In der Praxis hat sich daher der Einsatz sogenannter Kommunikationsserver etabliert, die als zentraler „Router" die Nachrichten zwischen den verschiedenen Systemen übertragen und dabei die notwendigen Formatumsetzungen übernehmen. Der Vorteil ergibt sich einmal aus der zentralen Verwaltung der Schnittstellenanpassung auf den Kommunikationsserver anstatt dezentral in allen Systemen und einmal erstellte Schnittstellen von bzw. zu einem System können häufig auch für Kommunikationsbeziehungen wiederverwendet werden. Daraus ergibt sich meistens ein Kostenvorteil, da Schnittstellen bei den Herstellern normalerweise auf Basis von Eventtypen und angeschlossenen Systemen lizensiert werden.

Zusammenfassend kann festgehalten werden, dass wir in Deutschland auch aus informationstechnischer Sicht eine Trennung der Versorgungssektoren vorfinden. Beide Protokolle sind vom Design her auf die Übermittlung von Patientenstamm- und Behandlungsdaten ausgelegt, wobei das HL7 Format darüber hinaus auch Auftragsanforderungen und administrative Informationen kommunizieren kann. In beiden Fällen wird die Kommunikation immer vom Sender initiiert und ist von einem Event (manuelles Auslösen eines Datenversandes oder getriggert durch eine Aktion, z.B. Verlegung auf eine Station) abhängig, dabei kann ein anderes System normalerweise keine Informationen von sich aus anfordern. (Die von HL7 spezifizierten Queries werden häufig nicht genutzt.)

Auf Grund der unterschiedlichen Ausgestaltung der Protokolle ist es an den Systemgrenzen immer erforderlich, eine Interpretation in die jeweils andere umzusetzen. Dabei ist festzustellen, dass für die Übertragung einer Zustimmungsinformation zwischen zwei Systemen bis heute kein Standard definiert ist. In diesem Zusammenhang muss der Vollständigkeit halber erwähnt werden, dass das xDT Format als solches zwar im ambulanten Bereich verbreitet ist, die verschiedene Hersteller von IT-Lösungen, außer für die Übertragung von Abrechnungsinformationen, eigene Formate nutzen.

Intersektorale Kommunikation am Beispiel von Einweiserportalen

In der einführenden Use-Case Beschreibung wurde die Begrifflichkeit „Einweiserportal" als ein Beispiel für ein intersektorales Kommunikationsszenario bereits erwähnt und soll nun stellvertretend für intersektorale Kommunikationsszenarien näher erläutert werden. Prinzipiell lassen sich die nachfolgenden Aussagen auch auf andere Kommunikationsformen analog übertragen, so könnte an Stelle des Einweiserportals auch eine organisationsübergreifende Akte, oder ein direkter elektronischer Versand von Dokumenten an einen nachbehandelnden Arzt bzw. eine Gruppe (z.B. per verschlüsselter Email) erfolgen oder das Krankenhaus mit einem Arztnetz kooperieren und die Daten den teilnehmenden niedergelassenen Medizinern transitiv über eine Arztnetzlösung zur Verfügung stellen.

Was ist ein Einweiserportal

Der Begriff Einweiserportal (oder auch Zuweiserportal) beschreibt im Allgemeinen eine Anwendung (in Form eines webbasiertes Extranet), mit der ein Krankenhaus, seinen zuweisenden, nach- und mitbehandelnden Ärzten eine digitale Einsichtnahme auf die medizinischen Fallinformationen ihrer Patienten, ermöglicht. Insbesondere wird auch ein bidirektionaler Austausch zwischen den Kommunikationspartnern angestrebt. Dabei werden weitere administrative und medizinische Daten wir die elektronische Überweisung, Vorbefunde und weitere ausgetauscht. Auch im Zusammenhang mit dem Terminmanagement wird die Einweiserplattform genutzt.

Meistens bieten Einweiserportale auch Kommunikationsfunktionen zur direkten Übernahme von z.B. Entlassbriefen und OP-Berichten bzw. allgemein Arztbriefen, die auch heute noch das leitende Kommunikationsmedium im Gesundheitswesen darstellen, in das Arztpraxisinformationssystem (APIS/PVS) an.

Die Portalapplikation repräsentiert sich dem niedergelassenen Nutzer im Wesentlichen über die browserbasierte Oberfläche (GUI) und übernimmt auch wesentliche Funktionen, wie die Authentifizierung und Autorisierung, sowie den Aufbau eines sicheren Transportkanals (i.d.R. über das Internet) zwischen Einweiserportal und Arztpraxis.

In den letzten Jahren wurden die Funktionen von Einweiserportalen wesentlich weiterentwickelt und während in den ersten Entwicklungsstufen noch der Aspekt der Kommunikation (eCommunication) und Teledokumentation im Vordergrund stand, sind diese mittlerweile selbstverständliche technische Basis und die Portalanwendungen unterstützen darüber hinaus heutzutage aktiv die einrichtungs- und sektorübergreifende Zusammenarbeit (eCollaboration). Krankenhäuser können den angeschlossenen niedergelassenen Ärzten z.B. die Möglichkeit der elektronischen Bettenbelegung bieten oder diese können dem Krankenhaus über das Einweiserportal relevante medizinische Dokumente für eine anstehende therapeutische Behandlung eines Patienten vorab zur Verfügung zu stellen. Dabei erfüllen die Einweiserportale auch die technische Funktion zwischen den unterschiedlichen Kommunikationsprotokollen im ambulanten bzw. stationären Sektor zu vermitteln.

Für die stationäre Einrichtung bietet ein Einweiserportal einmal die Möglichkeit das eigene Image bei „seinen" Niedergelassenen zu erhöhen und das eigene Markenbild durch die Darstellung im Corporate Design zu schärfen. Daneben besteht natürlich allgemein der Wunsch die Attraktivität des eigenen Hauses im Vergleich zu anderen Krankenhäusern in der Region zu steigern und somit aktiv zur Zuweiserbindung („Kundenbindung") beizutragen. Für die niedergelassenen Ärzte ist ein Einweiserportal i.d.R. ein Service des jeweiligen Krankenhauses und die Nutzung und Einrichtung ist für die kostenfrei.

Die erhöhte Transparenz in der Kommunikation zwischen den medizinischen Leistungserbringern bietet auch Vorteile für die Patienten:

• Dem Hausarzt (im Folgenden als Synonym für alle niedergelassenen Ärzte verwandt) stehen die Behandlungsinformationen (z.B. der Entlassbrief) schneller, medienbruchfrei und weder zeitlich noch räumlich beschränkt zur Verfügung.
• Über die Arztbriefdokumentation hinausgehend stehen dem Hausarzt auf Wunsch alle Daten auch in einer größeren Informationstiefe zur Verfügung, so kann z.B. zu einem Befund, das entsprechende Röntgenbild in einer webkonformen Betrachtungsqualität eingesehen werden.
• Im Idealfall verbessert sich der medizinische Behandlungsprozess insgesamt, da alle beteiligten Leistungserbringer zu jeder Zeit besser informiert sind. Neben der allgemeinen Steigerung der Behandlungsqualität kann sich auch die Gesamtbehandlungsdauer durch eine optimierte Kommunikation und/oder den Wegfall unnötiger Rückfragen verkürzen.

Der niedergelassene Arzt kann die Nutzung eines Einweiserportals ebenso zur Attraktivitätssteigerung bei seinen Patienten, mit den o.g. Argumenten nutzen und dies in sein Praxismarketing integrieren.

In dem vorhergehenden Abschnitt wurde erläutert, dass es sich bei einem Einweiserportal normalerweise um einen kostenlosen Service für die niedergelassenen Ärzte handelt. Neben den Aspekten „Imagesteigerung" und „Kundenbindung" ergibt sich eine mögliche Erlösdeterminante auch in dem Abschluss eines „integrierten Versorgungsvertrag" (IV-Vertrag), der das Einweiserportal als technische Basis nutzt.

Die am Markt etablierten Lösungen können aus informations-technischer Sicht in zwei Gruppen differenziert werden.

Viele Hersteller von Krankenhausinformationssystemen (KIS) bieten ein entsprechendes Modul, das als webbasierte Oberfläche des KIS für externe Ärzte verstanden werden kann, an und somit auch auf diese Datenhaltung zugreift.

Daneben bestehen Ansätze, die über Standard-Schnittstellen (i.d.R. HL7) an das KIS angebunden und somit KIS-herstellerunabhängig sind. Diese Portallösungen sind als komplette Applikationslösung mit eigener Datenhaltung (getrennt vom KIS) und mit eigener Applikationslogik zu verstehen. In neueren, konsequenter auf internationalen Standards beruhenden Umsetzungen werden Repository und Storage meist auf Basis IHE XDS.b umgesetzt.

Abbildung 1: eigenständige Zuweiserportal-Applikation - vereinfache Darstellung

Abbildung datenschutzrechtlicher Anforderungen

Kommunikationslayer

In dem vorhergehenden Abschnitt findet sich die Darstellung eines Einweiserportals, dass nicht als Modul des KIS realisiert ist, sondern über Standardschnittstellen an dieses angebunden wurde. Diese Form der Realisierung stellt heute den verbreitetsten Typ von Einweiserportalen dar. Die Integration in die klinische Infrastruktur erfolgt dabei in der Regel direkt über einen Integration- bzw. Kommunikationsserver, so dass das KIS das Einweiserportal als empfangendes System selbst u.U. gar nicht kennt. Aus diesem Grunde kann ist es für das KIS auch nicht möglich zusteuern, welche Daten an das System „Portal" gesendet werden bzw. welche nicht.

Aus diesem Grunde wird die Filterung der zu übermittelnden Daten aus dem Applikations- (KIS) in den Kommunikationslayer verlagert und vom Integrationsserver übernommen. Die Schnittstellen für den Versand an das Portal verhindern beispielsweise, dass das Nachrichten aus bestimmten Fachabteilungen (z.B. Psychiatrie) oder bestimmte Eventtypen oder -arten (z.B. Abrechnungsinformationen, Dokumente für den MDK,…) an das Portal übermittelt werden und dort zur Anzeige kommen. Ebenso setzten die Anbieter dieser Lösungen i.d.R. in ihrer Applikation selbst einen Integrationsserver zur Annahme der Daten ein, in dem sich eine analoge Filterlogik findet.

Dieses Vorgehen ist aus drei Gründen problematisch:

• Eine datenschutzrechtlich relevante Funktion wird der eigentlichen Applikation abgenommen und auf die Ebene der Kommunikation verlagert. Dabei werden Änderungen an den Schnittstellen normalerweise nicht automatisiert protokolliert und sofern eine Filterung der anzuzeigenden Daten nur in der Applikation des Portalanbieters erfolgt, könnte dieser mit einem Update, dass diese Filterung akzidentiell deaktiviert, schnell die Anforderungen des hausinternen Datenschützers aushebeln.
• Bei diesem Vorgehen müssen prinzip-bedingt (vgl. Ausführungen zu den Kommunikationsprotokollen) immer alles Daten an die Portallösung übermittelt werden. Die Daten selbst bleiben zu diesem Zeitpunkt zwar technisch gesehen in der Hoheit der stationären Einrichtung, da noch kein externe Kommunikation stattgefunden hat, aber das KIS verliert bereits zu diesem Zeitpunkt die Führung über den weiteren Datenfluss.
• Auf Grund der Entkopplung von KIS und Portallösung und der Widerverwendung vorhandener Schnittstellen können für die Steuerung des Datenzugriffes in der Portalapplikation ausschließlich die im normalen Datensatz enthaltenen Informationen genutzt werden. In aller Regel erfolgt dies über eine Auswertung der HL7 Felder, zur Kommunikation der einweisenden bzw. mitbehandelnden Ärzte. Diese Daten werden in der Form interpretiert, dass alle dort angegeben Ärzte, sofern sie auch an der Portallösung teilnehmen, Zugriff auf die Daten erhalten, was u.U. gar nicht gewünscht bzw. den handelnden Personen auch nicht transparent ist.
• Das System muss die Anforderung unterstützen, dass der Patient frei und individuell die Rechte für einzelne Ärzte bestimmen kann. Eine Lösung muss daher, unabhängig von dem im zentralen KIS hinterlegten Daten, eine Oberfläche zur Verwaltung dieser Daten bieten.

Abbildung der Einwilligung

In den einführenden Abschnitten wurde bereits erläutert, dass der Patient willentlich, der Übermittlung der Daten auf elektronischem Wege an die nach- und mitbehandelnden Ärzte zustimmen muss, damit sein Recht auf informationelle Selbstbestimmung gewahrt bleibt. In diesem Zusammenhang, kann auch festgehalten werden, dass es sich im Gesundheitswesen in aller Regel immer um Daten besonderer Art handelt und somit über das reine Vertragsverhältnis zwischen Patient und Einrichtung hinaus grundsätzlich eine Einwilligung für die Datenübermittlung erforderlich ist.

Die Einwilligung wird abhängig vom KIS meistens als vorausgefülltes Formular ausgedruckt und handschriftlich vom Patienten unterschrieben. Durch Speicherung der Einwilligungserklärungen und Berechtigungen ist so eine Historie darstellbar.

Unabhängig von der technischen Ausgestaltung, als Modul des KIS bzw. als eigenständige Lösung hat der hessische Datenschutzbeauftragte einen Musterentwurf für eine Patienteneinwilligung (siehe Anlage) für ein Krankenhauseinweiserportal (Musterentwurf Stand: 18. Juni 2009) erarbeitet, die den in den vorgenannten Abschnitten genannten Anforderungen an Form und Inhalt genügt. Dem Musterentwurf für die Einwilligung ist ein ergänzendes Informationsblatt, als Basis für eine geeignete Aufklärung, angefügt. Gleichzeitig sind mit der Einwilligung auch einige Rechte des Patienten verknüpft. So kann er jederzeit seine Einwilligung widerrufen, die Sperrung des Zugriffs auf die Daten oder eine Korrektur verlangen.

Die Anbieter von KIS-unabhängigen Portallösungen setzten, zur Umsetzung dieser datenschutzrechtlichen Anforderungen eigene Verwaltungsoberflächen ein, mittels derer eine administrative Kraft eine nachträgliche Sperrung vornehmen oder prinzipiell die Übermittlung der Daten bzw. treffender, die Anzeige im Portal, verhindern kann.

In diesem Zusammenhang müssen drei Punkte kritisch betrachtet werden:

• Die Einwilligungen sind manchmal auch als formlose Blankovordrucke realisiert und die auf der Einwilligung handschriftlich gemachten Angaben (z.B. welche teilnehmenden Ärzte auf die Daten zugreifen dürfen), sind nicht im KIS hinterlegt oder müssen dort manuell nachgetragen werden.
• Innerhalb des Aufnahmeworkflows werden Behandlungsvertrag und Einwilligung immer in einem „Rutsch" ausgedruckt und dem Patienten zur Unterschrift vorgelegt, so dass die notwendige datenschutzrechtliche Entkopplung und Aufklärung in den Hintergrund tritt. Bei diesem Vorgehen erfolgt keine Differenzierung, welche Dokumente (Einwilligungen) für welchen Patienten wirklich erforderlich sind.
• Die Umsetzung datenschutzrechtlich relevanter Anforderungen (wie die Sperrung der Daten im Portal) erfolgt nicht direkt im patientenführenden System (KIS) sondern in einem angeschossenen Subsystem, das u.U. mittels eines Kommunikationsservers vollkommen vom KIS entkoppelt ist. Damit verliert das KIS die Hoheit die Steuerung der datenschutzrechtlichen Funktionen und die Nutzer müssen speziell für diese Funktion eine zweite Verwaltungsoberfläche nutzen, die von den der sonstigen klinischen Infrastruktur losgelöst ist und auf die u.U. nur bestimmte Mitarbeiter Zugriff haben.

Integrationsbestrebungen

Auch die Hersteller von Portallösungen haben diese Probleme identifiziert und versucht Lösungen auf Basis der vorhandenen Standards (bspw. HL7) anzubieten. Bereits in einer frühen Verbreitungsphase von Einweiserportalen wurde versucht, Felder im HL7 Strom für die Übermittlung von Einwilligungs-informationen zu nutzen.

Der Anbieter des KIS wird dann in aller Regel vom Krankenhaus beauftragt, die Aufnahmemaske um einen Bereich für die Steuerung der Portaleinwilligung zu erweitern, in dem ein „Einwilligungsflag" gesetzt werden kann. Diese Informationen werden dann in ein, in der jeweiligen Einrichtung, nicht genutztes HL7 Feld eingefügt oder anderes Standardfelder wird für die Verwendung dieses Flags „missbraucht".

Die bei diesem Vorgehen zu kommunizierenden Datenmengen sind in der Regel auf ein einfachen Status (ja/nein) reduziert und somit kann nicht der Anwendungsfall der Steuerung, welcher externe Nutzer explizit auf welche Informationen berechtigt ist, abdecken. Diese Zuordnung wird bei diesem Vorgehen weiterhin über die Standard-HL7 Felder zur Kommunikation von Einweiser und Mitbehandler übertragen.

In einigen Projekten wurde daher für die Kommunikation des Status zur Patienteneinwilligung ein paralleler Kommunikationsweg realisiert. Auch in diesem Fall ist prinzipiell die Kooperation des KIS Anbieters für die Erweiterung der GUI Elemente notwendig, so dass direkt im KIS neben dem eigentlichen Status auch angegeben werden, kann welche externen Nutzer auf die Daten zugreifen dürfen. Diese Informationen werden dann entweder in individuell abgestimmten HL7 Nachrichten (vornehmlich in Z-Segmenten oder „missbrauchte" Felder) oder über Webservicefunktionen des Portalanbieters vom KIS an die Applikation übermittelt.

Bei diesem Vorgehen kann neben dem Status, den berechtigten Nutzern, auch die zeitliche Dauer für den Zugriff auf die Daten gesteuert werden und somit die datenschutzrechtlichen Anforderungen umfassend abgedeckt werden.

Bei allen Umsetzungsvarianten ist aber eine Kooperation des KIS-Anbieters vorausgesetzt und in der Regel wird eine für jedes Krankenhaus –mit den damit entsprechend verbundenen Kosten- individuelle Lösung realisiert.

• Grundsätzlich muss die Verwendung von HL7 Feldern, für die Kommunikation anderer, als im Standard definierter Informationen, formal gerügt werden. Insbesondere diese proprietären Erweiterungen führen zu Kommunikationsproblemen zwischen zwei IT-Systemen, verhindern eine plug ‚n\' play Fähigkeit und widersprechen dem grundsätzlichen Ansatz von Standards.
• Die mit der Realisierung individueller Lösungen verbundenen Kosten werden in aller Regel nur von großen Krankenhäusern (Maximalerversorger, Universitätskliniken) oder Krankenhausketten getragen werden können und sind unter wirtschaftlichen Aspekten für Häuser der Grund- und Regelversorgung uninteressant.

Eine Zusammenarbeit mit den Arztinformationssystemherstellern (AIS) ist auch von Vorteil. So können Daten mit tiefer Integration direkt in einem AIS gespeichert werden bzw. der Niedergelassene hat die Möglichkeit, Dokumente aus seinem Primärsystem direkt an das KH zu senden. So kann der gesamte Workflow über die Systeme abgebildet werden und ein Medienbruch durch Drucken, Scannen oder externer Dateiablage und komplizierter Verlinkung vermieden werden.

Ansätze, die Zustimmung eines Patienten gleich - nicht fremd veränderbar - im Dokument bei der Erstellung abzulegen (Typisierung notwendig), stecken noch in den Kinderfüßen, könnten aber die unabhängige Verteilung der aktuellen Patienten-Einwilligung pro Dokument, mit all den Risiken mit Bezug auf Laufzeit der Übermittlung von Änderungen der Patienteneinwilligung reduzieren.

Zusammenfassung

Die Abbildung der Übermittlung eines Einwilligungsstatus ist bisher kein integraler Bestandteil eines etablierten Nachrichtenprotokolls und auf Grund der klinischen IT-Struktur mit heterogenen (verteilten) Subsystemen, werden Funktionen zur Steuerung der Datenübermittlung u.U. nicht vom Patientenführenden Systemen wahrgenommen, sondern zwangsläufig an ein Subsystem „delegiert". In den verschiedenen Projekten wurden individuelle Ansätze mit der das KIS die Steuerung über die Datenübermittlung wieder erlangt umgesetzt, jedoch hat sich bisher kein übergreifender Standard etabliert.

Die Realisierung der Funktionen ist aber auf Ebene des Kommunikationslayers angesiedelt und beispielsweise nicht als „elektronisches Einwilligungsdokument", dass von den einzelnen Applikationen inhaltlich interpretiert werden kann realisiert. Damit ergeben sich für ein empfangendes System praktisch keine Möglichkeiten der Validierung und Verifizierung.

Verallgemeinerung

Die am Beispiel der intersektoralen Kommunikation mittels eines Einweiserportals aufgeführten Probleme und sich daraus ableitenden Anforderungen an die technische Umsetzung lassen sich auf alle patientenbezogenen Einwilligungsprozesse verallgemeinern. In diesem Zusammenhang ist es prinzipiell unerheblich, ob eine Einwilligung für die Datenverarbeitung im Auftrage (z.B. durch einen externen Dienstleister für die Abrechnung) oder eine Übermittlung von Behandlungsdaten an Dritte außerhalb der normalen Mitwirkung in der medizinischen Versorgung handelt. Grundsätzlich können diese Funktionalitäten in Teilen auch für das Erstellen des eigentlichen Behandlungsvertrages genutzt werden. Dabei müssen an die Umsetzung des Prozesses nachfolgende Anforderungen gestellt werden:

• Das patientenführende System muss die Erstellung der notwendigen Einwilligungserklärung (auf Basis eines übergreifenden Standards) mit einem Assistenten unterstützen. Dabei dürfen nur, die im konkreten Kontext notwendigen Dokumente erstellt werden. Nimmt der Patient beispielsweise keine Wahlleistungen in Anspruch, die über einen externen Dienstleister abgerechnet werden, so darf ihm die Einwilligung auch nicht zur Unterschrift vorgelegt werden.
• Für jeden Kommunikationsprozess muss dem Patienten vor dem Ausfüllen der Einwilligung ein ergänzendes Informationsblatt ausgehändigt werden, damit er im Sinne einer informierten Einwilligung entscheiden kann. Dies sollte drucktechnisch in der Form umgesetzt werden, dass das Informationsblatt immer vor dem eigentlichen Einwilligungsdokument erstellt wird.
• Jedes Formular muss dabei patientenindividuell (mit seinen Stammdaten und seinen gemachten Angaben) bedruckt werden. Der Ausdruck von Blankoformularen und das nachträgliche Bekleben mit Patientenetiketten und manuelle Ausfüllen von Ankreuzfeldern kann als nicht ausreichend angesehen werden.
• Der Assistent muss in der Form gestaltet sein, dass für jeden einzelnen Kommunikationspartner (z.B. an ein externer Dienstleister, einen Hausarzt) explizit angegeben werden kann, wer welche Daten über welchen Zeitraum erhält. Dabei muss das patientenführende System diese Informationen über standardisierte Schnittstellen den datenversendenen Systemen mitteilen. Diese Angaben müssen Bestandteil der automatisiert erstellten Einwilligung werden.
• Das patientenführende System muss in jedem Fall die Hoheit über die Steuerung der datenschutzrechtlich relevanten Einwilligungen behalten. Diese Funktion darf nicht auf ein Subsystem, das die Kommunikation zu externen IT-Systemen realisiert, verlagert werden.
• In jedem Fall muss technisch sichergestellt sein, dass die schriftlich vorliegende Einwilligung bzw. die darauf benannten Personen/Institutionen und die wirklichen Empfänger einer Nachricht wirklich identisch sind. Solange keine flächendeckende Verfügbarkeit einer national eindeutigen Patienten-ID gegeben ist (eGK, aber auch der ePersonalausweis könnte dies auch abbilden), muss dieser Punkt organisatorisch gelöst werden, in dem der die Einwilligung erstellende Mitarbeiter, dies in einem modalen Dialog manuell bestätigt.
• Alle Änderungen der Einwilligungserklärungen müssen historisiert und gleichzeitig in einem Auditlog protokolliert werden, wer diese Änderung, zu welchem Zeitpunkt, an welchem Arbeitsplatz (unter welcher Benutzerkennung) durchgeführt hat.
• Das Einwilligungsdokument sollte aus einem elektronisch auswertbaren und aus einem lesbaren Teil bestehen. In den Metadaten muss mindestens angegeben sein:
  • Wer hat die Einwilligung, in welcher Institution, erstellt.
  • Wen betrifft die Einwilligung (welcher Patient inkl. der Patientenstammdaten).
  • Welchen Umfang hat die Einwilligung, welche Daten dürfen bzw. dürfen nicht kommuniziert werden.
  • Wann wurde das Dokument erstellt und bis zu welchen Datum ist die Einwilligung gültig.
  • Die Bestätigung enthalten, dass die unterschriebene Einwilligung vor liegt
  • Das Dokument sollte elektronisch signiert sein.
  • Der lesbare Teil kann strukturierten oder unstrukturierten Text enthalten. Analog der Definition des bvitg-Arztbriefes können mehrere Stufen der Strukturierung gewählt werden, wobei notwendigen Metadaten immer auswertbar übertragen werden müssen.
• In der initialen Kommunikation wird nach dem Prinzip eines Handshake-Verfahrens die Einwilligung übertragen und deren Validität vom empfangenden System geprüft und dem Sender die Akzeptanz der Einwilligung mitgeteilt.
• In allen weiteren Kommunikationsvorgängen muss der Sender prüfen, ob zwischenzeitlich eine aktualisierte Einwilligung die Übertragung der Daten möglicherweise verhindert. Analog steht auch der Empfänger in der Verantwortung zu prüfen, ob die ihm vorliegende Einwilligung noch gültig ist, um den aktuellen Kommunikationsvorgang zu legitimieren. Der Empfänger sollte jeden Datenempfang ohne Vorliegen einer Einwilligung ablehnen.
• Das Format für die Übertragung der Einwilligung muss so gestaltet, dass es entweder in Form eines Dokumentes oder eine Webservice-Kommunikation übermittelt werden kann. Gleichzeitig muss der Aufbau einer Form genügen, die für die unterschiedlichen Anwendungskontexte, genutzt werden kann.
  • elektronische Einrichtungsübergreifende Akte (i.d.R. als IV-Vertrag)
  • direkte Kommunikation zwischen zwei Ärzten
  • Zustimmung für den Datenzugriff über ein Einweiserportal
  • etc.