Die EFA als Gesundheitsdatendienst

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
K
K (Markup-Fehler behoben)
 
(10 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
  
==Die EFA als Gesundheitsdatendienst==
+
''Anmerkung: Die unter 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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
 +
----
 +
 
 +
== Die EFA als Gesundheitsdatendienst ==
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {DFsGe.01}</tt>
  
 
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.
 
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 aufzubauenden Telematikinfrastruktur und deren Diensten. Darüber hinaus ist hierdurch eine größtmögliche Nachnutzbarkeit von GDD-übergreifend nutzbaren Diensten (z.B. zur Authentisierung und Autorisierung) sichergestellt. [[cdaefa:EFA-Provider|EFA-Provider]] können so in einem regionalen Gesundheitsnetz mit wenig Mehraufwand neben der elektronischen Fallakte auch weitere Gesundheitsdatendienste betreiben und anbieten.
+
Die EFAv2.0 Spezifikation legt die elektronische Fallakte explizit als Gesundheitsdatendienst aus, so dass EFAv2.0 konforme EFA-Netzwerke über die für alle GDD anwendbaren Migrationspfade zukünftig von den Möglichkeiten der Telematikinfrastruktur profitieren können. Hierdurch ist z.B. eine größtmögliche Mit- und Nachnutzbarkeit von GDD-übergreifend definierten und betriebenen Diensten (z.B. zur Authentisierung und Autorisierung) sichergestellt. [[cdaefa:EFA_Provider|EFA-Provider]] können dadurch in einem regionalen Gesundheitsnetz mit wenig Mehraufwand neben der elektronischen Fallakte auch weitere Gesundheitsdatendienste betreiben und anbieten.
  
 
=== Gesundheitsdatendienste (GDD) ===
 
=== Gesundheitsdatendienste (GDD) ===
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {DFsGe.01.01}</tt>
 +
 +
IHE-Deutschland beabsichtigt mit dem ''[[IHE_DE_Cookbook|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 Gemeinsamkeiten aller GDD 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 [[cdaefa:Die_EFA_als_Gesundheitsdatendienst#GDD_Referenzmodell|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.
  
 +
Die EFAv2.0 ist ein GDD und damit auch eine Instanz des GDD-Referenzmodells. Viele der technischen Spezifikationen der EFAv2.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 EFAv2.0 valide Umsetzungen der allen GDD gemeinsamen Sicherheits- und Datenschutzanforderungen und können damit ebenfalls für weitere GDD genutzt werden.
  
 
=== GDD Referenzmodell ===
 
=== 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.
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {DFsGe.01.02}</tt>
 +
 
 +
Gesundheitsdatendienste besitzen eine Vielzahl gemeinsamer Charakteristika in Bezug auf IT-Sicherheit, Datenschutz und TI-Konformität, die sich u.a. in wiederverwendbaren GDD-Artefakten (Konzepte, Spezifikationen, etc) widerspiegeln, 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 sowie zum Betrieb eines GDD deutlich reduziert.
  
 
Das '''GDD-Referenzmodell''' definiert vier generische Ablaufschritte zur Nutzung eines GDD durch einen Heilberufler:
 
Das '''GDD-Referenzmodell''' definiert vier generische Ablaufschritte zur Nutzung eines GDD durch einen Heilberufler:
Zeile 26: Zeile 43:
 
* 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.
 
* 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.  
 
* 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.
+
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 können alle GDD-übergreifend angelegten Spezifikationen, Konzepte und Software-Komponenten zur Implementierung und zum Aufsetzen des GDD sowie zu seiner Migration in die zukünftige Telematikinfrastruktur 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.
 
  
[[Datei:GDD_EFA_Layering.png|480px]]
+
----
 
 
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.
 
  
----
 
  
* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
+
{{NoteBox|'''Referenzen und Querverweise'''
 +
* [[cdaefa:EFA_Spezifikation_v2.0|EFAv2.0-Spezifikation]]
 +
* [http://www.gematik.de/cms/de/egk_2/anwendungen/vorbereitung/vorbereitung_1.jsp Informationen zu den geplanten Anwendungen auf der Telematikinfrastruktur] (Quelle: gematik)
 +
<nowiki></nowiki>
 +
}}

Aktuelle Version vom 26. Januar 2015, 15:30 Uhr

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 .

Anmerkung: Die unter 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".


Die EFA als Gesundheitsdatendienst

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {DFsGe.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 EFAv2.0 Spezifikation legt die elektronische Fallakte explizit als Gesundheitsdatendienst aus, so dass EFAv2.0 konforme EFA-Netzwerke über die für alle GDD anwendbaren Migrationspfade zukünftig von den Möglichkeiten der Telematikinfrastruktur profitieren können. Hierdurch ist z.B. eine größtmögliche Mit- und Nachnutzbarkeit von GDD-übergreifend definierten und betriebenen Diensten (z.B. zur Authentisierung und Autorisierung) sichergestellt. EFA-Provider können dadurch in einem regionalen Gesundheitsnetz mit wenig Mehraufwand neben der elektronischen Fallakte auch weitere Gesundheitsdatendienste betreiben und anbieten.

Gesundheitsdatendienste (GDD)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {DFsGe.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 Gemeinsamkeiten aller GDD 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.

Die EFAv2.0 ist ein GDD und damit auch eine Instanz des GDD-Referenzmodells. Viele der technischen Spezifikationen der EFAv2.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 EFAv2.0 valide Umsetzungen der allen GDD gemeinsamen Sicherheits- und Datenschutzanforderungen und können damit ebenfalls für weitere GDD genutzt werden.

GDD Referenzmodell

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {DFsGe.01.02}

Gesundheitsdatendienste besitzen eine Vielzahl gemeinsamer Charakteristika in Bezug auf IT-Sicherheit, Datenschutz und TI-Konformität, die sich u.a. in wiederverwendbaren GDD-Artefakten (Konzepte, Spezifikationen, etc) widerspiegeln, 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 sowie zum Betrieb 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)

GDD EFA Referenzmodell.png

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 können alle GDD-übergreifend angelegten Spezifikationen, Konzepte und Software-Komponenten zur Implementierung und zum Aufsetzen des GDD sowie zu seiner Migration in die zukünftige Telematikinfrastruktur genutzt werden.