Kontext, Anwendung, Ressource
| Zeile 21: | Zeile 21: | ||
* die Vermittlung der Ressource wird durch eine Anwendung realisiert, die von einem oder mehreren GDD-Anbietern bereit gestellt wird. Im Fall der EFA bilden die EFA-2.0-konformen, über [[cdaefa:EFA_Provider|EFA-Peers]] realisierten Fachdienste die Anwendung "EFA" während die Rolle der GDD-Anbieter durch die [[cdaefa:EFA_Provider|EFA-Provider]] ausgefüllt wird. | * die Vermittlung der Ressource wird durch eine Anwendung realisiert, die von einem oder mehreren GDD-Anbietern bereit gestellt wird. Im Fall der EFA bilden die EFA-2.0-konformen, über [[cdaefa:EFA_Provider|EFA-Peers]] realisierten Fachdienste die Anwendung "EFA" während die Rolle der GDD-Anbieter durch die [[cdaefa:EFA_Provider|EFA-Provider]] ausgefüllt wird. | ||
* sämtlicher Datenaustausch findet innerhalb eines über alle Akteure gespannten Sicherheitskontextes statt. Im Fall der EFA bildet die Patienteneinwilligung die konzeptuelle Basis dieses gemeinsamen Kontextes. Die technische Umsetzung erfolgt durch zwischen den Akteuren ausgetauschte Sicherheitsnachweise. | * sämtlicher Datenaustausch findet innerhalb eines über alle Akteure gespannten Sicherheitskontextes statt. Im Fall der EFA bildet die Patienteneinwilligung die konzeptuelle Basis dieses gemeinsamen Kontextes. Die technische Umsetzung erfolgt durch zwischen den Akteuren ausgetauschte Sicherheitsnachweise. | ||
| + | In den nachfolgenden Abschnitten wird beschrieben, wie diese Vorgaben des GDD-Referenzmodells innerhalb des EFA-Informationsmodells konkret umgesetzt sind. | ||
=== Kontext === | === Kontext === | ||
| + | [[Datei:EFA_Kontext_Komplett.png|638px|right]] | ||
| + | Nach den Vorgaben des GDD-Referenzmodells sind sämtliche Operationen zur Verarbeitung der Ressource (d.h. der Fallakten und ihrer Daten) in einen Sicherheitskontext eingebettet, der potenziell alle beteiligten IT-Systeme umspannt. Konkret bedeutet dies, dass der Sicherheitskontext des Nutzers an seinem Arbeitsplatz in der Klinik auf Seiten der EFA-Dienste beim EFA-Provider so rekonstruiert werden kann, dass es für den Nutzer so aussieht, als ob würden die EFA-Dienste in seinem lokalen Sicherheitskontext auf seinem Arbeitsplatzsystem laufen (und umgekehrt: Für die EFA-Dienste ist es vollkommen egal wo der Nutzer sitzt, da die die Dienste immer in dem Sicherheitskontext laufen, in dem sich der Nutzer gerade befindet). | ||
| − | + | Um einen solchen Sicherheitskontext zu realisieren, werden alle für diesen Kontext relevanten Informationen zur Identität und zu den Berechtigungen des Nutzers in sog. Sicherheitsnachweisen (''Assertions'') gekapselt. Diese Nachweise enthalten verifizierbare, zuverlässige Aussagen darüber, wer der Nutzer ist und was er im Rahmen der Nutzung einer Ressource für Berechtigungen besitzt. Jedes IT-System im EFA-Verbund kann anhand der Sicherheitsnachweise den gleichen Sicherheitskontext aufbauen - unabhängig davon wo und in welchem Zuständigkeitsbereich das Identitäts- und Berechtigungsmanagement realisiert sind. | |
| + | Für die konkreten Verfahren zur Vermittlung und Absicherung von Sicherheitsnachweisen gibt es verschiedene Paradigmen, die im wesentlichen davon abhängen, ob ein Sicherheitskontext bereits zu Beginn einer Anwendungsnutzung vollständig aufgebaut wird oder ob dieser Aufbau schrittweise erfolgt, wenn die einzelnen Nachweise benötigt werden (und dann ggf. auch nur auf den Systemen, die diese Nachweise auch wirklich benötigen). Im [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf IHE White Paper "Access Control"] werden z.B. die Strategien "Policy Push" (Client baut den vollständigen Kontext auf) "Policy Pull" (Aufbau des Kontextes erfolgt ''on demand'' beim Dienstanbieter) beschrieben, die auch beide von der EFA unterstützt werden. | ||
| − | -- | + | === EFA-Anwendung und EFA-Peers === |
| − | * | + | |
| + | === Ressourcen der EFA === | ||
| + | |||
| + | |||
| + | === Querverweise und Referenzen === | ||
| + | |||
| + | * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] | ||
| + | * [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf IHE White Paper "Access Control"] | ||
Version vom 7. April 2013, 09:50 Uhr
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Kontext, Anwendung, Ressource (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
February 2013
Jörg Caumanns, Raik Kuhlisch
| Version: | 0.9 |
| Datum: | March 2013 |
| Status: | xxx |
| Verfahren: | {{{Verfahren}}} |
| Realm: |  Deutschland
|
Inhaltsverzeichnis
EFA als Instanz des GDD Referenzmodells
Die EFA ist ein Gesundheitsdatendienst (GDD) und damit eine Instanz des GDD-Referenzmodells. Dies bedeutet:
- im Mittelpunkt eines GDD steht die Vermittlung geschützter Ressourcen zwischen Leistungserbringern. Im Fall der EFA sind diese Ressourcen die einzelnen Fallakten, auf die berechtigte Leistungserbringer im Rahmen der Behandlung medizinischer Fälle zugreifen.
- die Vermittlung der Ressource wird durch eine Anwendung realisiert, die von einem oder mehreren GDD-Anbietern bereit gestellt wird. Im Fall der EFA bilden die EFA-2.0-konformen, über EFA-Peers realisierten Fachdienste die Anwendung "EFA" während die Rolle der GDD-Anbieter durch die EFA-Provider ausgefüllt wird.
- sämtlicher Datenaustausch findet innerhalb eines über alle Akteure gespannten Sicherheitskontextes statt. Im Fall der EFA bildet die Patienteneinwilligung die konzeptuelle Basis dieses gemeinsamen Kontextes. Die technische Umsetzung erfolgt durch zwischen den Akteuren ausgetauschte Sicherheitsnachweise.
In den nachfolgenden Abschnitten wird beschrieben, wie diese Vorgaben des GDD-Referenzmodells innerhalb des EFA-Informationsmodells konkret umgesetzt sind.
Kontext
Nach den Vorgaben des GDD-Referenzmodells sind sämtliche Operationen zur Verarbeitung der Ressource (d.h. der Fallakten und ihrer Daten) in einen Sicherheitskontext eingebettet, der potenziell alle beteiligten IT-Systeme umspannt. Konkret bedeutet dies, dass der Sicherheitskontext des Nutzers an seinem Arbeitsplatz in der Klinik auf Seiten der EFA-Dienste beim EFA-Provider so rekonstruiert werden kann, dass es für den Nutzer so aussieht, als ob würden die EFA-Dienste in seinem lokalen Sicherheitskontext auf seinem Arbeitsplatzsystem laufen (und umgekehrt: Für die EFA-Dienste ist es vollkommen egal wo der Nutzer sitzt, da die die Dienste immer in dem Sicherheitskontext laufen, in dem sich der Nutzer gerade befindet).
Um einen solchen Sicherheitskontext zu realisieren, werden alle für diesen Kontext relevanten Informationen zur Identität und zu den Berechtigungen des Nutzers in sog. Sicherheitsnachweisen (Assertions) gekapselt. Diese Nachweise enthalten verifizierbare, zuverlässige Aussagen darüber, wer der Nutzer ist und was er im Rahmen der Nutzung einer Ressource für Berechtigungen besitzt. Jedes IT-System im EFA-Verbund kann anhand der Sicherheitsnachweise den gleichen Sicherheitskontext aufbauen - unabhängig davon wo und in welchem Zuständigkeitsbereich das Identitäts- und Berechtigungsmanagement realisiert sind.
Für die konkreten Verfahren zur Vermittlung und Absicherung von Sicherheitsnachweisen gibt es verschiedene Paradigmen, die im wesentlichen davon abhängen, ob ein Sicherheitskontext bereits zu Beginn einer Anwendungsnutzung vollständig aufgebaut wird oder ob dieser Aufbau schrittweise erfolgt, wenn die einzelnen Nachweise benötigt werden (und dann ggf. auch nur auf den Systemen, die diese Nachweise auch wirklich benötigen). Im IHE White Paper "Access Control" werden z.B. die Strategien "Policy Push" (Client baut den vollständigen Kontext auf) "Policy Pull" (Aufbau des Kontextes erfolgt on demand beim Dienstanbieter) beschrieben, die auch beide von der EFA unterstützt werden.
