cdaefa:Die EFA als Gesundheitsdatendienst

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 .

Die EFA als Gesundheitsdatendienst

Im Rahmen der Bestandsaufnahme und Neuausrichtung der Telematikinfrastruktur (TI) haben die Gesellschafter der gematik das Projekt zur „Migration von Gesundheitsdatendiensten als Mehrwertfachdienste in die Telematikinfrastruktur am Beispiel der elektronischen Fallakte“ (Migration GDD / EFA) beschlossen. Es hat die Aufgabe, (1) ein allgemeines, wieder verwendbares, an Standards orientiertes Muster für die Migration von Gesundheitsdatendiensten (GDD) in die Telematikinfrastruktur zu schaffen, um (2) damit die bestehenden EFA-Netzwerke in die Telematikinfrastruktur einzubinden und (3) die Telematikinfrastruktur als flexibel nutzbare technologische Plattform für bestehende und künftige Gesundheitsdatendienste verfügbar zu machen.

Die EFA 2.0 Spezifikation nimmt die Arbeiten der gematik zur GDD/EFA-Migration auf und ist somit kompatibel zur Telematikinfrastruktur und deren Diensten. Hierdurch ist eine größtmögliche Nachnutzbarkeit von GDD-übergreifend definierten und betriebenen Diensten (z.B. zur Authentisierung und Autorisierung) sichergestellt. EFA-Provider können so in einem regionalen Gesundheitsnetz mit wenig Mehraufwand neben der elektronischen Fallakte auch weitere Gesundheitsdatendienste betreiben und anbieten.

Gesundheitsdatendienste (GDD)

IHE-Deutschland beabsichtigt mit dem Akten-Cookbook eine gemeinsame technische Basis (in diesem Fall IHE XDS und weitere IHE Profile) für verschiedene Ausprägungen von Aktenplattformen zu schaffen. Hierdurch sollen die Gemeinsamkeiten verschiedener Akten herausgearbeitet und Aktenplattformen so neu konzipiert werden, dass diese Gemeinsamkeiten auch über einheitliche technische Bausteine abbildbar sind. Im Idealfall muss das gleiche Set technischer Bausteine für jede Ausprägung einer Aktenplattform nur neu zusammengestellt und konfiguriert werden.

Das Konzept der "Gesundheitsdatendienste" (GDD) verfolgt die gleiche Idee, setzt jedoch eine Ebene höher bei den logischen Bausteinen des Austauschs von Gesundheitsdaten zwischen Leistungserbringern an. Gesundheitsdatendienste bilden somit eine Klasse von Anwendungen, die auf identischen funktionalen Bausteinen (Kommunikationsmuster), logischen Informationsmodellen und Sicherheitsanforderungen basieren. Hierdurch können insbesondere auch Datenschutzkonzepte, Betriebskonzepte und Sicherheitskonzepte sehr einfach zwischen GDD übertragen werden. Auch eine Abbildung auf eine einheitliche technische Basis ist auf diesem Wege möglich. Dies ist aber eher zweitrangig, da in vielen Fällen bereits die sichergestellte Interoperabilität auf der logisch/funktionalen Ebene für das reibungslose Zusammenspiel verschiedener Akteure ausreichend ist.

GDD Referenzmodell

Gesundheitsdatendienste in der TI müssen eine Reihe von Vorgaben in Bezug auf IT-Sicherheit, Datenschutz und TI-Konformität erfüllen. Die Umsetzung dieser Vorgaben wird durch ein Zulassungsverfahren sowie eine technische Freigabe sicherheitskritischer Systembausteine sichergestellt. Die Vielzahl gemeinsamer Charakteristika von Gesundheitsdatendiensten (GDD) spiegelt sich in wiederverwendbaren GDD-Artefakten (Konzepte, Spezifikationen, etc) wider, die nur einmalig definiert werden müssen und dann für jeden einzelnen GDD profiliert bzw. instanziiert werden können. Durch solche GDD-übergreifend nutzbaren Komponenten werden die Aufwände zur Implementierung und Zulassung eines GDD deutlich reduziert.

Das GDD-Referenzmodell definiert vier generische Ablaufschritte zur Nutzung eines GDD durch einen Heilberufler:

1. Aufsetzen eines sicheren Ausführungskontextes
2. Erlangen des Zugangs zu einer von einem GDD-Anbieter bereitgestellten Anwendung aus dem sicheren Ausführungskontext heraus
3. Erlangen des Zugangs zu einer von der Anwendung verwalteten Ressource (Anwendungsinstanz, z. B. eine konkrete Fallakte eines Patienten)
4. Durchführen von Zugriffen auf die Ressource (z. B. Auslesen von Dokumenten aus einer Fallakte)

Ausführungskontext, Anwendung und Ressource sind in einander verschachtelte Klassen, die das Referenz-Objektmodell eines GDD bilden:

• Der Ausführungskontext bildet den aktuellen Sicherheitskontext des Nutzers ab und enthält Nachweise zur Identität, Authentizität und den Autorisierungen des Nutzers. Der Kontext wird dezentral auf Seiten des Nutzers aufgebaut und verwaltet, kann aber beim Aufruf einer GDD-Operation vollständig zum GDD-Fachdienst übermittelt werden; d.h. es wird über Dienstnutzer und Dienstanbieter hinweg ein gemeinsamer Sicherheitskontext aufgespannt.
• Anwendungen repräsentieren die von einem GDD-Anbieter bereitgestellten Dienste eines GDD. Die Mechanismen zum Zugang zu einer Anwendung kapseln die unterschiedlichen Konzepte der Dienstlokalisierung und erlauben die Umsetzung GDD-spezifischer Zugangs- und Sicherheitspolitiken.
• Der Kern eines GDD sind die Ressourcen, die die zu verarbeitenden Gesundheitsdaten repräsentieren. Das GDD-Referenzmodell definiert eine Reihe von generischen Referenz-Abläufen auf Ressourcen (abrufen, anlegen, verändern, autorisieren, etc.) die von einem GDD relativ frei instanziiert und erweitert werden können.

Durch Instanziierung, Anpassung und Erweiterung des Referenz-Objektmodells und der Referenz-Abläufe kann ein bestehender oder geplanter GDD sehr einfach in das Rahmenwerk des GDD-Referenzmodells eingepasst werden. Hierdurch ist eine Umsetzung des GDD über die GDD-Referenzarchitektur möglich und es können alle GDD-übergreifend angelegten Spezifikationen, Konzepte und Software-Komponenten zur Implementierung und zum Aufsetzen des GDD in der TI genutzt werden.

GDD Referenzarchitektur

Die GDD-Referenzarchitektur besteht aus drei Schichten, die sich über die fünf für die Telematikinfrastruktur definierten Tiers (Client, Fachmodul, Plattform dezentral/zentral, Fachdienst) erstrecken.

Das Referenz-Objektmodell und die Referenz-Abläufe werden durch die GDD-Basisschicht umgesetzt. Die Basisschicht enthält GDD-übergreifend nutzbare Funktionen; z. B. zum Aufbau des Ausführungskontextes (Authentifizierung, Autorisierung), zur Dienstlokalisierung, zur Protokollierung, zum Dienstzugang und zum Einwilligungsmanagement. Sofern erforderlich werden zur Umsetzung dieser Funktionalitäten Leistungsmerkmale der TI genutzt (z. B. HBA-Signatur, Schreiben in den GDD-Container der eGK). Damit nicht nur das Design, sondern auch die Implementierung der Basisschicht möglichst umfänglich wiederverwendet werden kann, sind die Funktionen der Basisschicht deklarativ an die Anforderungen eines spezifischen GDD anpassbar. Hierzu gehört z. B. dass ein GDD über eine Sicherheitspolitik den aufzubauenden Ablaufkontext beschreiben kann und damit die Ablaufsteuerung über den Sicherheitsdiensten definiert.

Referenzen und Querverweise

• EFA-2.0-Spezifikation
• Informationen zu den geplanten Anwendungen auf der Telematikinfrastruktur (Quelle: gematik)