Die EFA als Gesundheitsdatendienst
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die hinter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
Inhaltsverzeichnis
Die EFA als Gesundheitsdatendienst {DFsG.01}
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) {DFsG.01.01}
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. Wesentliche dieser Gemeinsamkeiten sind:
- Der GDD vermittelt den Austausch von medizinischen Daten zwischen Leistungserbringern bzw. zwischen Leistungserbringern und medizinisch-fachlichen, IT-gestützten Diensten (z.B. elektronische Register)
- Der Austausch der Daten erfolgt zweckbezogen im Kontext der medizinischen Versorgung (einschließlich Vorsorge, Rehabilitation, Versorgungsforschung, etc.)
- Die ausgetauschten Daten haben einen hohen Schutzbedarf (über einen GDD vermittelte Daten können auch einen sehr hohen Schutzbedarf haben, in diesem Fall müssen jedoch die GDD-übergreifenden Datenschutzkonzepte und Sicherheitsdienste für diesen GDD spezifisch erweitert werden)
- Zu jedem GDD kann es verschiedene Anbieter geben
Diese Gemeinsamkeiten werden auf ein GDD-Referenzmodell abgebildet, das insbesondere wiederkehrende Muster in Bezug auf Nutzerinteraktion, Ablaufsequenzen und die Vernetzung elementarer Informationsbausteine aufnimmt. Hierdurch können insbesondere auch Datenschutzkonzepte, Betriebskonzepte und Sicherheitskonzepte 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. Aus diesem Grund fokussiert die GDD-Referenzarchitektur vorrangig auf die Integration von GDD in die Telematikinfrastruktur als einheitliche Kommunikations- und Sicherheitsplattform des deutschen Gesundheitswesens. Hierdurch wird die Migration bestehender GDD in die TI erleichtert und neu definierte GDD können optimal von der Wiederverwendbarkeit bereits umgesetzter GDD-Bausteine profitieren.
Die EFA 2.0 ist ein GDD und damit sowohl eine Instanz des GDD-Referenzmodells als auch über die GDD-Referenzarchitektur in die TI migrierbar. Viele der technischen Spezifikationen der EFA 2.0 bilden valide Bindings zu den funktionalen und logischen Bausteinen von Gesundheitsdatendiensten und sind damit GDD-übergreifend wiederverwendbar. Ebenso sind viele der Sicherheits- und Datenschutzmechanismen der EFA 2.0 valide Umsetzungen der allen GDD gemeinsamen Sicherheits- und Datenschutzanforderungen und können damit ebenfalls für weitere GDD genutzt werden.
GDD Referenzmodell {DFsG.01.02}
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:
- Aufsetzen eines sicheren Ausführungskontextes
- Erlangen des Zugangs zu einer von einem GDD-Anbieter bereitgestellten Anwendung aus dem sicheren Ausführungskontext heraus
- Erlangen des Zugangs zu einer von der Anwendung verwalteten Ressource (Anwendungsinstanz, z. B. eine konkrete Fallakte eines Patienten)
- 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 {DFsG.01.03}
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.
