cdaefa:EFA Concept Paper

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

EFA und »EFA in a Box« - Konzept und Umsetzung

Dr. Jörg Caumanns, Olaf Rode // Fraunhofer FOKUS

Dr. Winfried Seibert // Städtisches Klinikum München

Elektronische Fallakten

Die elektronische Fallakte (EFA) ist eine Plattform, über die für verschiedene Ärzte eine einheitliche Sicht auf im Rahmen einer gemeinsamen Behandlung erstellte und genutzte Dokumente hergestellt werden kann. Eine durch die EFA zu unterstützende Behandlung wird dazu zunächst bei einem sog. EFA-Provider registriert. Diese Registrierung umfasst insbesondere die Benennung der vom Patienten zur Nutzung der EFA berechtigten Ärzte und Einrichtungen, für die der EFA-Provider entsprechende Zugriffsrechte einrichtet. Berechtigte Ärzte können anschließend in ihren Systemen erstellte und gespeicherte Behandlungsdokumente an der für den Patienten eingerichteten Fallakte registrieren bzw. hinterlegen, wodurch diese Dokumente auch für alle anderen an der Behandlung beteiligten Ärzte sichtbar und abrufbar werden.

Der »medizinische Fall«

Ausgangspunkt einer Fallakte ist immer die medizinische Behandlung eines Patienten, welche je nach Phase eine konkrete Zusammenarbeit mehrerer medizinischer Leistungserbringer erfordert. Dies können z. B. der Hausarzt des Patienten, ein Facharzt, eine Fachabteilung eines Krankenhauses und eine Reha-Einrichtung sein. Die besonderen Charakteristika der durch die EFA abbildbaren Behandlungsphase können dabei wie folgt zusammengefasst werden:

• Es besteht ein Erfordernis der unmittelbaren Kommunikation von medizinischen Daten zwischen den in die Behandlung eingebundenen Leistungserbringern, d. h. mittels einer EFA wird vorrangig über den Patienten und nicht mit dem Patienten kommuniziert.
• Es existieren prüfbare Kriterien, die das zu erreichende Ziel der unterstützten Behandlungsphase - und damit das Schließen der Fallakte – markieren. Das Ziel der jeweiligen Phase muss dabei nicht zwingend die vollständige Genesung des Patienten implizieren, sondern bedeutet lediglich, dass kein Erfordernis einer engen Abstimmung und unmittelbaren Datenkommunikation zwischen verschiedenen Einrichtungen mehr besteht.
• Der Kreis der Behandler, der über die Fallakte Daten austauscht und die Behandlungsereignisse dokumentiert, ist zu jeder Zeit abschließend benennbar. Er umfasst die Personen, die in der aktuellen Behandlungsphase in die Behandlung eingebunden sind bzw. die Behandlung in einer definierten Rolle begleiten (z. B. als Fallmanager oder Qualitätsbeauftragter).

Wesentlich bei der Festlegung einer Fallakte ist der Behandlungsgrund, der für die intersektorale Kommunikation zwischen mitbehandelnden Organisationen als zentral erachtet werden soll. Dabei wird dieser Grund in der Regel mittels einer zentralen ICD oder mittels einer zwischen Organisationen vereinbarten Regelung beschrieben. Bei der Festlegung des Grundes der gemeinsamen Behandlungsphase ist es von geringer Relevanz, ob dieser eine einzelne oder mehrere, die Behandlung wechselseitig beeinflussende Diagnosen zugrunde liegen,.

Zentral ist vielmehr das klare Erfordernis für die Kommunikation zwischen Ärzten und die definierte Zweckbindung der Dokumentationsinhalte. (Benennung des Ziels und der Teilnehmer der Behandlung, der erwarteten Dauer des Kommunikationsbedarfs und des Kommunikationsumfanges.) Eine solche kooperative Behandlungsphase mit dem Erfordernis einer gemeinsamen, zweckbezogenen Dokumentation wird in den technischen Spezifikationen der EFA als »medizinischer Fall« bezeichnet, der inhaltlich den medizinischen Kommunikationsbedarf zwischen mitbehandelnden Organisationen festlegt.

Einwilligung und Autorisierung

Die oben skizzierten Charakteristika einer Fallakte finden sich unmittelbar im Prozess des Aufsetzens einer Fallakte wieder:

1. Aus einer Behandlungssituation heraus ergibt sich das Erfordernis der Nutzung einer Fallakte. Ein entsprechend geschulter Behandlungsteilnehmer beschreibt dem Patienten die angestrebte Art der Fallaktennutzung, stellt die damit verbundenen Vorteile für die Behandler (und den Patienten) dar und informiert den Patienten über die organisatorischen Randbedingungen.
2. Sofern der Patient der Fallaktennutzung zustimmt, wird der Zweck der Fallaktennutzung – und damit das Ziel der durch die EFA unterstützten Behandlungsphase – festgelegt. Die Zustimmung des Patienten zu der vereinbarten Fallaktennutzung wird schriftlich in Form einer Einwilligung dokumentiert und durch die Unterschrift des Patienten rechtsgültig.
3. Die an der Behandlung beteiligten Ärzte und Einrichtungen werden erfasst; sie bilden den Kreis der Zugriffsberechtigten auf eine Fallakte. Der Patient kann einzelne Behandler von der Fallaktennutzung ausschließen sofern hierdurch Erfordernis und Zweck der Fallakte nicht in Frage gestellt werden. Sollte dies der Fall sein, wird die Fallakte ausgesetzt. In Abstimmung zwischen Behandlern und Patient muss nun entweder der Nutzungszweck neu definiert oder andere Formen der Kooperation gewählt werden.

Der Patient kann seine Einwilligung zur Nutzung einer Fallakte jederzeit widerrufen.

Kliniken als EFA-Provider

Eine Fallakten-Infrastruktur besteht im einfachsten Fall aus drei Klassen von Akteuren:

• Ein EFA-Register (eCR Registry) stellt die Verzeichnisse zur Verwaltung von Fallakten und darin enthaltenen Dokumenten bereit. In einem regionalen Gesundheitsnetz kann ein einzelner EFA-Teilnehmer das EFA-Register für das gesamte Netzwerk anbieten.
• Ein EFA-Speichersystem (eCR Repository) hält die registrierten Dokumente vor und stellt sie für berechtigte Nutzer zum Abruf bereit. Jeder EFA-Teilnehmer kann ein eigenes EFA-Speichersystem bereitstellen und an das EFA-Register anbinden.
• Ein EFA-Teilnehmersystem (eCR Consumer) bildet eine Nutzerschnittstelle ab, über die ein Arzt Behandlungsdaten anderer Ärzte aus an einem EFA-Register registrierten Speichersystemen abrufen kann bzw. in einem Speichersystem verwaltete Behandlungsdaten am EFA-Register registrieren kann.

Im einfachsten Fall sind die EFA-Speichersysteme über bestehende Datenspeicher bei den EFA-Teilnehmern realisiert, d. h. das EFA-Register vermittelt den Behandlern lediglich einen gegenseitigen, stark reglementierten und geschützten Zugang zu bestehenden IT-Systemen. Niedergelassene Ärzte verfügen jedoch in den meisten Fällen nicht über die technischen Möglichkeiten, um ein EFA-Speichersystem sicher und wirtschaftlich in eigener Regie und innerhalb der eigenen IT-Infrastruktur zu betreiben. Aus diesem Grund verfügt die EFA über die Möglichkeit, dass ein EFA-Teilnehmer im Rahmen der Registrierung von Daten an einem EFA-Register diese Daten auch gleichzeitig in das EFA-Speichersystem des Register-Betreibers kopieren kann.

In einem regionalen Gesundheitsnetz bildet sich somit eine Aufgabenverteilung heraus, bei der Kliniken Register und Speichersysteme anbieten, die von kooperierenden niedergelassenen Ärzten mit genutzt werden. Sofern solche Kliniken dabei selbst nicht mitbehandelnde Organisation bei einer Fallakte sind, kommt das Modell einer »Datenverarbeitung im Auftrag« zum Tragen, d. h. eine Klinik bietet für einen Niedergelassenen IT-Dienstleistungen an. Durch die Vernetzung der Register spielt es keine Rolle, bei welcher Klinik ein Arzt seine Daten in ein EFA-Speichersystem einspielt oder über welches Register ein Arzt nach Behandlungsdaten anderer Ärzte sucht.

Hierdurch sind auch EFA-Netzwerke realisierbar, in denen eine Klinik (oder ein Dienstleister im Auftrag einer Klinik) zwar EFA-Register und EFA-Speichersysteme betreibt, selber aber nicht zwingend auch Teilnehmer an Fallakten sein muss. Für dieses Szenario muss im Rahmen der Einwilligung das Einverständnis des Patienten auch die Information über den EFA Dienstanbieter enthalten sein, der entsprechende Daten bei einer nicht in die Behandlung eingebundenen Einrichtung für die Lebensdauer der Fallakte speichert..

Abbildung von organisationsinternen Ordnungsstrukturen auf elektronische Fallakten

In einem regionalen Gesundheitsnetz treten Kliniken üblicherweise sowohl als EFA-Provider als auch als EFA-Teilnehmer auf. Die Teilnehmerrolle beinhaltet dabei sowohl den lesenden Zugriff auf Fallakteninhalte als auch das Einstellen von Dokumenten aus den klinikinternen Systemen.

Was das Einstellen von Daten betrifft, so mussten beim Design der EFA-Architektur verschiedene Anforderungen der auch als EFA-Provider auftretenden Kliniken berücksichtigt werden:

• Eine Einzelfreigabe von Dokumenten zu deren Registrierung in eine Fallakte ist nicht praktikabel, da dies entsprechende Erweiterungen in allen datenerzeugenden Systemen erfordern würde. Dies betrifft nicht nur das GUI, sondern auch die interne Systemintegration, da jedes System um eine Schnittstelle zur EFA – einschließlich der kompletten Anbindung an die Sicherheitsdienste – erweitert werden müsste.
• Die Registrierung eines Dokuments an einer EFA erfordert die Kenntnis der ID der entsprechenden EFA. Es wird als nicht realisierbar angesehen, EFA-IDs durch alle datenerzeugenden Systeme zu ziehen. D. h. es muss daher auch möglich sein, Daten aus einem dokumentierenden System an einer EFA zu registrieren, wenn dieses keine Kenntnis vom Vorhandensein bzw. der konkreten ID einer EFA hat.
• Die Administration von Fallakten – insbesondere deren Anlage – soll in einer Klinik nicht nur technisch, sondern vor allem auch organisatorisch zentralisiert werden können. Einzelne Chefärzte sollen für ihren Verantwortungsbereich in die Lage versetzt werden, in Abstimmung mit ihren Netzwerkpartnern patientenübergreifend zu definieren, welche Daten (ggf. differenziert nach Diagnosen und Vertragsarten) EFA-relevant sind. Dazu müssen für den gemeinsamen Behandlungsverlauf jeweils typische Fallaktenarten herausgebildet werden können. Sofern eine entsprechende Einwilligung des Patienten vorliegt, soll die Registrierung dieser Daten an einer EFA möglichst automatisiert und ohne zusätzlich Nutzerinteraktion erfolgen können.

Aus diesen Anforderungen heraus wurde das in der nachfolgenden Abbildung dargestellte Konzept entwickelt:

Abbildung 1: Entkopplung der daten-bereitstellenden Systeme von der EFA

Die grundsätzliche Überlegung hierbei ist, dass im Regelfall bereits bei der Aufnahme bzw. beim Erstkontakt mit dem behandelnden Arzt Teilbereiche, die für eine Fallakte relevant sind, geprüft und vorbereitet werden, ob eine Fallakte besteht bzw. sinnvollerweise angelegt werden sollte. Ist dies der Fall, wird im EFA-Management die anstehende bzw. laufende Krankenhausbehandlung für die relevanten Informationen zur Weiterbehandlung mit der Fallakte verknüpft. Es wird davon ausgegangen, dass jedes Behandlungsdokument spätestens mit seiner Freigabe im Kliniknetzwerk „abgegriffen“ werden kann, um die Weiterbehandlungsrelevanz prüfen zu können. Dies kann z. B. anhand einer von einem Kommunikationsserver abgefangenen HL7 MDM-Nachricht erfolgen. Der Kommunikationsserver prüft in diesem Fall, ob für die dem Dokument zugrunde liegende Behandlung eine EFA registriert ist und ob das Dokument gemäß vorab definierter Regeln „EFA-relevant“ ist. Ist dies der Fall, wird das Dokument vom Kommunikationsserver über eine klinik-interne Schnittstelle am EFA-Register registriert. Je nach Implementierung kann in diesem Zuge auch eine Kopie des Dokuments im EFA-Speicher angelegt werden bzw. bei der Registrierung wird ein Verweis auf das Original-Dokument übergeben, der bei einem externen Zugriff über den EFA-Speicher aufgelöst werden kann. Damit dieses Verfahren funktioniert, muss über alle beteiligten Systeme von der Aufnahme über das EFA-Management bis zum KIS und den Subsystemen ein möglichst einheitlicher Identifier durchgezogen werden, der die „Behandlung“ repräsentiert. Üblicherweise wird dieses eine klinikintern genutzte administrative Nummer sein, die den Aufenthalt, die Abrechnung oder einen Vertrag bezeichnet. Aus diesem Grund wird die „Behandlung“ in der EFA-Spezifikation auch als „administrativer Fall“ (zuweilen auch als „visit“ oder „episode“) bezeichnet. Hierbei ist es jedoch irrelevant, welche Semantik die entsprechende ID innerhalb der Klinik-IT-Infrastruktur wirklich trägt, wesentlich ist lediglich ihre durchgängige Verfügbarkeit und die Möglichkeit, alle an dieser Nummer hängenden, EFA-relevanten Daten einem „medizinischen Fall“ zuordnen zu können.

Um die technische Umsetzung dieses Konstrukts zu vereinfachen, werden „administrative Fälle“ in der EFA immer mit „Ordnern“ einer Fallakte assoziiert; d. h. es besteht immer eine Korrespondenz zwischen einem EFA-Ordner und einem „administrativen Fall“ in einer Klinik. Ordner wiederum sind an eine Fallakte gebunden, wodurch implizit eine Zuordnung eines „administrativen Falls“ einer Organisation zu dem von der Fallakte abgedeckten medizinischen Fall (sektorübergreifende Behandlung) erfolgt. Dieser Kunstgriff realisiert damit nicht nur die Abbildung eines proprietären, klinikinternen Konstrukts auf das normative Informationsmodell der EFA, sondern erlaubt auch eine Verteilung von Fallakten auf der Abstraktionsebene von Ordnern. Eine EFA kann mehrere „administrative Fälle“ bei mehreren Kliniken zusammenfassen ohne dass hierzu mit klinikinternen Semantiken belegte Identifier nach außen kommuniziert werden müssten (nach außen sind immer nur die korrespondierenden „Ordner“ sichtbar). Durch das Ordnerkonstrukt ist es umgekehrt auch möglich, innerhalb der Klinik aus einem „administrativen Fall“ heraus die zugeordnete Fallakte zu identifizieren und damit den Zugang zu von Mitbehandlern erstellten Dokumenten benutzerfreundlich in die Klinik-IT-Systeme zu intgrieren.

„Ordner“ sind ein generelles technisches Konstrukt der EFA, mit dem in den angebundenen IT-Systemen implementierte Informationsstrukturen einfacher auf das Informationsmodell einer Fallakte abgebildet werden können. „Ordner“ sind natürlich auch für an die EFA angebundene Niedergelassene nutzbar. So kann z. B. ein niedergelassener Radiologe einen „Ordner“ in einer EFA anlegen und diesen mit einer internen Auftragsnummer verknüpfen. Alle Dokumente, die im Rahmen des Auftrags erstellt werden, können so automatisiert der richtigen Fallakte zugeordnet und an dieser registriert werden.

Da „Ordner“ lediglich ein Konstrukt zur Vereinfachung des Einstellens von Daten in eine Fallakte sind, sind sie auch üblicherweise dem Nutzer gegenüber verborgen. Ein Clientsystem nutzt im Normalfall eine von der EFA-Schnittstelle angebotene Funktion zum Abruf der Metadaten aller in einer ausgewählten Fallakte registrierten Objekte und baut daraus eine nutzerspezifische Sicht zusammen. Auch diese Sicht kann natürlich Ordner als Strukturelemente enthalten (z. B. für Medikationsdaten, Therapie-Berichte, etc.) aber diese fachlich strukturierenden Ordner sind semantisch vollkommen losgelöst von den oben beschriebenen „Ordnern“ für „administrative Fälle“ der EFA.

Abbildung 2: Ordner und administrative Fälle

EFA-Stecker

Aus den EFA-Implementierungen und EFA-Pilotierungen wurde bei der Umsetzung des oben skizzierten Konzepts die Anforderung gestellt, dass für die Strecke von einem datenerzeugenden System über einen Kommunikations¬server in die EFA-Dienste hinein eine Mehrfachnutzung einmal implementierter Lösungen unterstützt werden muss. Hierbei soll es sowohl möglich sein

• unterschiedliche Systeme, die gleiche Nachrichten (z. B. MDM T01) aussenden, innerhalb der gleichen EFA-Implementierung gleichartig anzubinden als auch
• gleiche Produkte gleichartig an unterschiedliche EFA-Implementierungen anzubinden – d. h. der Anbindungslösung selbst einen Produktcharakter zu geben.

Die Lösung hierzu sind sog. »EFA-Stecker«. Ein EFA-Stecker nimmt eine von einem datenerzeugenden System ausgelöste Nachricht auf und wandelt diese in eine Nachricht um, die von einer normierten Schnittstelle des EFA-Registers und des EFA-Datenspeichers verarbeitet werden kann. Ein Beispiel hierfür ist z. B. ein »MDM-T02-Stecker«, der eine MDM-T02-Nachricht aufnimmt, das übertragene Dokument im EFA-Datenspeicher ablegt und die Metadaten des Dokuments am EFA-Register registriert.

EFA in a Box

Der nächste, aus den EFA-Pilotprojekten getriebene, Evolutionsschritt ist »EFA in a Box«. Hierbei werden im Wesentlichen weitere ursprünglich in der Klinik-IT-Infrastruktur angesiedelte Funktionalitäten normiert und in die EFA-Dienste verschoben, die nun quasi als »Black Box« die klinikinternen Dienste und Abläufe von den Funktionen und Abläufen der EFA entkoppeln:

• die Abbildung einer administrativen Fall-ID auf eine EFA-Ordner-ID muss nicht mehr durch jeden »EFA-Stecker« realisiert werden, sondern erfolgt in der EFA-Box. Hierzu wird eine Schnittstelle bereit gestellt, über die ein „administrativer Fall“ mit einem „medizinischen Fall“ verknüpft werden kann. Auch diese Schnittstelle kann dabei über einen »EFA-Stecker« bedient werden (z. B. durch Verarbeiten von ADTxx-Nachrichten).
  EFA-Stecker müssen so nur noch „wissen“ welche Nummer (d. h. welches Element der aufgefangenen Nachricht) in einer Klinik die administrative Fallnummer der EFA repräsentiert. Die Zuordnung der Daten zu einem Ordner und damit zu einem medizinischen Fall kann dann innerhalb der EFA-Box realisiert werden.
• Die Integration von Funktionalitäten zur Anlage und Pflege von Fallakten in KIS hat sich als schwierig bzw. kostspielig herausgestellt. Es sollte daher eine Möglichkeit eröffnet werden, bestehende Funktionalität von Klinik-IT-Systemen zur Anlage von Fallakten zu nutzen und die entsprechende Anbindung dann ggf. auch über »EFA-Stecker« zu realisieren.

Die Lösung hierzu ist die sog. Provider-Schnittstelle der EFA-Box. Über diese Schnittstelle kann eine Fallakten-Instanz bzw. ein Fallakten-Ordner als ein CDA-Dokument exportiert und importiert werden. Die Anlage einer Fallakte ist damit in drei einfachen Schritten realisierbar:

• • In einem Klinik-IT-System wird die anzulegende Fallakte als strukturiertes Dokument beschrieben. Hierzu kann z. B. ein VHitG-Arztbrief, ein auf Templates basierendes Word-Dokument oder ein PDF-Formular genutzt werden.
  • Über einen EFA-Stecker wird dieses Dokument nach Vorgabe eines CDA Profils transformiert, das zu dem Informationsmodell der EFA korrespondiert.
  • Das so erzeugte CDA-Dokument wird an die EFA-Box übermittelt, die die entsprechende Instanz der EFA in ihren internen Datenstrukturen anlegt.

Über die Provider-Schnittstelle wurde damit gleichzeitig eine Möglichkeit hergestellt, sämtlichen denkbaren Administrationsaufgaben auf Fallakten über einen einheitlichen Mechanismus abzubilden. Beispiele hierfür sind die De-Registrierung falsch zugeordneter Dokumente, die Verwaltung von in die Behandlung einbezogenen Einrichtungen oder auch einfach nur die Änderung der Anschrift des Patienten.

EFA Connector

Das client-seitige Pendant der EFA-Box ist der EFA-Connector. Genauso wie die EFA-Box die Anbindung von Quellsystemen in Kliniken erleichtert, vereinfacht der EFA-Connector die Anbindung von Clientsystemen an die EFA-Box eines EFA-Providers.

Abbildung 3: Zusammenspiel von EFA-Connector und EFA-Box

Der EFA-Connector implementiert im Zusammenspiel mit der EFA-Box den Aufbau und die Nutzung sicherer EFA-Sitzungen, innerhalb derer ein Arztsystem die fachlichen Funktionen der EFA nutzen kann. Hierdurch werden EFA-spezifische Sicherheitsdienste und –objekte komplett im EFA-Connector gekapselt, d. h. vollständig vor dem Arztsystem verborgen. Ausgehend von einer im Arztsystem vorgenommenen Anmeldung des Nutzers wickelt der Connector selbstständig alle EFA-Abläufe zur Authentisierung am EFA-Provider, zur Lokalisierung gesuchter Fallakten und zur Inanspruchnahme erteilter Berechtigungen aus. Über eine solche Anbindung gelingt es einfache Dokumentationssysteme unmittelbar in die Fallakte integrieren zu können, weil diesen gegenüber damit nur die fachliche Schnittstelle der EFA sichtbar wird, deren Aufrufe einfach in bestehende Abläufe des PVS bzw. KIS eingebettet werden können.

Der EFA-Connector kann sowohl als Software-Library zur Integration in das PVS bzw. KIS als auch als Hardware-Box mit einer SOAP-Schnittstelle für die EFA-Fachdienste umgesetzt werden.