Hl7wiki - Benutzerbeiträge [de]

cdaefa:EFA Spezifikation v2.0

2013-04-08T13:36:19Z

Rkuhlisch: /* Zu überarbeitende Seiten */

{{DocumentPart}}

''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 "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
----

== Einleitung {Epif.01} ==

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - eine Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einen Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt an festen Orten gespeichert. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 {Epif.02} ==
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der EFA Version 1.2 das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität der EFA-Abläufe zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt ist und die übergeordneten EFA-Konzepte (Fallakte, Ordner) nicht abdeckt.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der ambulanten und stationären Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und
* durch Verzahnung mit dem "IHE Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation {Epif.03} ==

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar.

<table border="1" cellspacing="0" cellpadding="0" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]
* [[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]
* [[cdaefa:EFA Provider|EFA Provider]]
* [[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]
* [[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]
* [[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]
** [[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
* [[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
** [[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
** [[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
** [[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
** [[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
** [[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
** [[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
** [[cdaefa:CIM Anpassen des Teilnehmerkreises|Anpassen des Teilnehmerkreises]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
* Sicherheitszonen
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]
* [[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]
* [[cdaefa:EFA Einwilligungsdokument|EFA Einwilligungsdokument]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]
* [[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]
** [[cdaefa:EFA Ressource Manager SFM|EFA Ressource Manager SFM]]
** [[cdaefa:EFA Document Registry SFM|EFA Document Registry SFM]]
** [[cdaefa:EFA Document Repository SFM|EFA Document Repository SFM]]
* [[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
** [[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
** [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
** [[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]
* [[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Verwendete Standards|Verwendete Standards]]
* [[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
** [[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
** [[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]
* [[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
** [[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
** [[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]
* [[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
** [[cdaefa:EFA XDS ConstraintTransactions|EFA XDS Binding: Transaction Overview]]
** [[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
** [[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
** [[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]
* [[cdaefa:EFA Access Control System|EFA Access Control System]]
</td>
</tr>
</table>

== Offene Punkte und ToDos {Epif.04} ==

=== Fehlende Seiten ===

'''Teile der normativen Spezifikation'''
* Interaktionsmuster für das Löschen von Dokumenten
* Kompletter Strang (Interaktion, Kommunikation, SFM, Binding) für das Ändern der Berechtigungen
* Binding: [[cdaefa:EFA_Identity_Provider_WS_Trust_Binding|EFA Identity Provider WS Trust Binding]], [[cdaefa:EFA_Policy_Provider_WS Trust_Binding|EFA Policy Provider WS Trust Binding]]

'''Nicht-Normative Zusatzinfos'''
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding
* Abbildung der Interaktionsmuster auf Kommunikationsmuster

=== Zu überarbeitende Seiten ===

'''Überarbeitung bis zum Beginn der Kommentierung am 20.04.13'''
* [[cdaefa:Prinzipien_für_Datenschutz_und_Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
** Text fokussieren und für die Online-Darstellung prägnanter formulieren
** Pseudonymisierung nur noch als optionale Erweiterung

'''Niedrige Priorität'''
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]
** Akteursdiagramm ergänzen (ggf. aus EFA 1.2 Fachkonzept)
** Texte sprachlich überarbeiten und inhaltlich erweitern

=== OIDs und Codesysteme ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:EFA Spezifikation v2.0

2013-04-08T13:35:51Z

Rkuhlisch: /* Fehlende Seiten */

{{DocumentPart}}

''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 "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
----

== Einleitung {Epif.01} ==

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - eine Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einen Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt an festen Orten gespeichert. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 {Epif.02} ==
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der EFA Version 1.2 das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität der EFA-Abläufe zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt ist und die übergeordneten EFA-Konzepte (Fallakte, Ordner) nicht abdeckt.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der ambulanten und stationären Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und
* durch Verzahnung mit dem "IHE Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation {Epif.03} ==

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar.

<table border="1" cellspacing="0" cellpadding="0" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]
* [[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]
* [[cdaefa:EFA Provider|EFA Provider]]
* [[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]
* [[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]
* [[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]
** [[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
* [[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
** [[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
** [[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
** [[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
** [[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
** [[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
** [[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
** [[cdaefa:CIM Anpassen des Teilnehmerkreises|Anpassen des Teilnehmerkreises]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
* Sicherheitszonen
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]
* [[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]
* [[cdaefa:EFA Einwilligungsdokument|EFA Einwilligungsdokument]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]
* [[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]
** [[cdaefa:EFA Ressource Manager SFM|EFA Ressource Manager SFM]]
** [[cdaefa:EFA Document Registry SFM|EFA Document Registry SFM]]
** [[cdaefa:EFA Document Repository SFM|EFA Document Repository SFM]]
* [[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
** [[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
** [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
** [[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]
* [[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Verwendete Standards|Verwendete Standards]]
* [[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
** [[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
** [[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]
* [[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
** [[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
** [[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]
* [[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
** [[cdaefa:EFA XDS ConstraintTransactions|EFA XDS Binding: Transaction Overview]]
** [[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
** [[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
** [[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]
* [[cdaefa:EFA Access Control System|EFA Access Control System]]
</td>
</tr>
</table>

== Offene Punkte und ToDos {Epif.04} ==

=== Fehlende Seiten ===

'''Teile der normativen Spezifikation'''
* Interaktionsmuster für das Löschen von Dokumenten
* Kompletter Strang (Interaktion, Kommunikation, SFM, Binding) für das Ändern der Berechtigungen
* Binding: [[cdaefa:EFA_Identity_Provider_WS_Trust_Binding|EFA Identity Provider WS Trust Binding]], [[cdaefa:EFA_Policy_Provider_WS Trust_Binding|EFA Policy Provider WS Trust Binding]]

'''Nicht-Normative Zusatzinfos'''
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding
* Abbildung der Interaktionsmuster auf Kommunikationsmuster

=== Zu überarbeitende Seiten ===

'''Überarbeitung bis zum Beginn der Kommentierung am 20.04.13'''
* [[cdaefa:Prinzipien_für_Datenschutz_und_Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
** Text fokussieren und für die Online-Darstellung prägnanter formulieren
** Pseudonymisierung nur noch als optionale Erweiterung
** Grafik zum Assertion Chaining muss ausgetauscht werden

'''Niedrige Priorität'''
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]
** Akteursdiagramm ergänzen (ggf. aus EFA 1.2 Fachkonzept)
** Texte sprachlich überarbeiten und inhaltlich erweitern

=== OIDs und Codesysteme ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

Datei:EFA Assertion Chain.png

2013-04-08T13:29:16Z

Rkuhlisch: hat eine neue Version von „Datei:EFA Assertion Chain.png“ hochgeladen

cdaefa:Akteure und Rollen der EFA

2013-04-08T12:34:48Z

Rkuhlisch: /* Datenerhebende Stellen und Datenverantwortliche Stellen {Auun.01.05} */

cdaefa:Akteure und Rollen der EFA

2013-04-08T12:28:55Z

Rkuhlisch: /* Gesundheitseinrichtung (Institution) {Auun.01.03} */

cdaefa:Akteure und Rollen der EFA

2013-04-08T12:23:17Z

Rkuhlisch: /* EFA-Teilnehmer (Heilberufler) {Auun.01.02} */

cdaefa:Die EFA als zweckgebundene Akte

2013-04-08T12:02:05Z

Rkuhlisch: /* Die EFA als zweckgebundene Akte */

{{DocumentPart}}

==Die EFA als zweckgebundene Akte==
Die elektronische Fallakte (eFA) unterstützt einrichtungsübergreifende Dokumentations- und Kommunikationsprozesse in der Zusammenarbeit von Leistungserbringern bei der strukturierten Behandlung von spezifischen Erkrankungen.

Die grundsätzliche Entscheidung, ob die Behandlung einer Erkrankung in einer Einrichtung über eine Fallakte unterstützt werden soll, liegt bei der Einrichtung. Üblicherweise wird eine Einrichtung ihren Patienten nur dann die Nutzung einer Fallakte anbieten, wenn weitere Behandler einbezogen werden müssen und die Herstellung einer gemeinsam nutzbaren Dokumentations- und Kommunikationsplattform eine qualitative Verbesserung der Behandlung oder eine Verringerung von Unannehmlichkeiten für den Patienten mit sich bringt. In einem Versorgungsverbund legen die Fallakten anbietenden Einrichtungen ([[cdaefa:EFA Provider|EFA Provider]]) im Konsens mit den einbezogenen Ärzten den jeweils erforderlichen Inhalt einer diagnose-spezifischen Fallakte fest. Ziel ist es durch die strikte Reglementierung der Fallakteninhalte sowohl eine Informationsüberflutung als auch das Fehlen von relevanten Informationen zu vermeiden. Alle behandelnden Ärzte können sich so auf die Angemessenheit und Vollständigkeit der ihnen in der Fallakte vorliegenden Informationen verlassen. Der Patient wird bei der Abfrage der Einwilligung über die regelhaft in seine Fallakte eingestellten Daten informiert; er kann jedoch lediglich die Nutzung der Fallakte als Ganzes ablehnen, nicht jedoch die Ausklammerung einzelner, von den Ärzten als wichtig erachteten Inhalte, verlangen.

Aufgrund ihrer Bindung an spezifische Krankheitsbilder im Kontext einrichtungsübergreifend strukturierter Behandlungen ist die Fallakte nicht darauf angelegt, für alle Behandlungsfälle zur Anwendung zu kommen. Vielmehr wird zunächst eine Konzentration auf diejenigen Erkrankungen im Vordergrund stehen, bei denen für bestehende Behandlungskooperationen durch die Nutzung von Fallakten deutliche Verbesserungen der Versorgung und/oder Vereinfachungen von einrichtungsübergreifenden Abstimmungsprozessen erzielt werden können.

Die Entscheidung darüber, ob im konkreten Behandlungsfall eine für eine Erkrankung mögliche und von einem Arzt vorgeschlagene Fallaktendokumentation akzeptiert wird und tatsächlich eine Fallakte angelegt werden kann, liegt beim Patienten. Lehnt der Patient die Anlage einer Fallakte ab, darf ihm daraus kein weiterer Nachteil entstehen.

=== 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 Leistungserbringer, 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.

=== Auswirkungen der Zweckbindung auf die Nutzung von Fallakten ===
Die erhobenen medizinischen Daten einer elektronischen Fallakte unterliegen aufgrund ihrer Bindung an einen "medizinischen Fall" einer konkreten Zweckbindung: Zweck der elektronischen Fallakte ist das kooperative Zusammenwirken verschiedener Leistungserbringer bei der Behandlung eines konkreten Behandlungsfalls. Das bedeutet, dass nur für den Behandlungsprozess relevante Informationen zu diesem definierten Behandlungsfall in der Fallakte referenziert und zugänglich gemacht werden dürfen. Eine Vorratsdatenerhebung und -speicherung allgemein zum Gesundheitszustand des Patienten ist im Rahmen der Fallakte nicht zulässig. Doppelerhebungen von medizinischen Daten sind bestmöglich zu vermeiden.

Die Zweckbindung der Datenverarbeitung durch die EFA beinhaltet zusammengefasst, dass
* medizinische Informationen über einen bestimmten Patienten in einem bestimmten Behandlungsprozess einem berechtigten Personenkreis in vollem benötigtem Umfang,
* ortsungebunden und
* korrekt zum benötigten Zeitpunkt
zur Verfügung stehen, um den Patienten schnellst- und bestmöglich behandeln zu können.

{{NoteBox|'''Zweckbindung und Patientenhoheit''' 
Aus den Anforderungen des Datenschutzes und dem Streben nach einer vertrauensvollen Zusammenarbeit von Arzt und Patient heraus ist eine möglichst starke Rolle des Patienten in Bezug auf die Steuerung der Nutzung seiner medizinischen Daten anzustreben. Diese Rolle kann dabei unterschiedlich in der Interaktion von Arzt und Patient manifestiert werden, wobei die Herstellung einer starken Zweckbindung und die Autorisierung von Einzeltransaktionen zwei Strategien an den Enden des denkbaren Spektrums darstellen:
* Eine '''enge Zweckbindung''' schafft Transparenz und ermöglicht eine praktikable Patientenhoheit ohne Notwendigkeit einer vollständigen Datenhoheit des Patienten. Die informationelle Selbstbestimmung wird durch die Einwilligung in den Zweck und durch Transparenz bei der datensparsamen Durchsetzung des Zwecks gewahrt. Durch eine patientenbestimmte Belegung von Rollen mit Personen/Organisationen wird eine Intervenierbarkeit des Patienten hergestellt, indem die Berechtigungen jederzeit die Nutzungsanforderungen der vom Patienten als sein Behandlungsteam bestimmten Personen und Organisationen abbilden. Technische Sicherheitsmaßnahmen einer zweckgebundenen Akte dienen vorrangig zur Absicherung der Zweckbindung.
* Eine '''starke Patientenhoheit''' erlaubt dem Patienten die Zweckbestimmung jeder einzelnen Verarbeitung seiner Daten. Intervenierbarkeit und Selbstbestimmung werden hierbei durch die vollständige Datenhoheit des Patienten abgesichert, wozu auch eine praktikable und diskriminierungsfreie Umsetzung des Rechts auf Verweigerung gehört. Technische Sicherheitsmaßnahmen einer Akte in Patientenhoheit zielen vorrangig auf die Absicherung der Datenhoheit des Patienten ab, d. h. stellen sicher, dass jede Einzeltransaktion durch den Patienten autorisiert ist.

Die EFA ist eine Akte mit enger Zweckbindung. Die damit einher gehenden Anforderungen an das abzusichernde Zusammenspiel von Arzt und Patient werden in der Stellungnahme der Landesdatenschützer zum Datenschutzkonzept der EFA v1.2 beschrieben:

''Anders als die einrichtungsübergreifende elektronische Patientenakte (eEPA), die eine Art Vorratsdatenspeicherung für in der Regel noch nicht eingetretene Behandlungsfälle darstellt und damit datenschutzrechtliche Fragen zur Sicherstellung der Zweckbindung aufwirft, wird die eFA für konkrete Behandlungsfälle angelegt, womit eine enge Zweckbindung für die eFA definiert wird.

In die gemeinsame Fallakte werden nur für die aktuelle Behandlung erforderliche Informationen eingestellt. Mit seiner Einwilligung autorisiert der Patient den von ihm bestimmten Leistungserbringer, zur Durchführung der Behandlung auf den gesamten Inhalt der gemeinsamen Fallakte zuzugreifen. Er hat nicht das Recht, den Zugriff auf einzelne Dokumente auszuschließen. Der Patient hat jedoch das Recht, seine Einwilligung zu widerrufen. Macht er von diesem Recht Gebrauch, darf kein Leistungserbringer mehr auf die Fallakte zugreifen.
''}}

=== Referenzen und Querverweise ===

* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
* [http://www.fallakte.de/ueber-efa Abgrenzung der Fallakte gegen patientengeführte Akten] (Quelle: EFA-Verein)

IG:EFA Spezifikation v2.0

2013-04-08T08:54:40Z

Rkuhlisch:

{{Infobox Dokument
|Title = eFA Spezifikation v2.0
|Short = eFA Spezifikation v2.0
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

{{Infobox Ballot Begin}}
{{Ballot | Version = 01 | Date = 2013 | Status = Entwurf | Realm = Deutschland}}
{{Infobox Ballot End}}

{{HL7transclude|cdaefa:EFA_Spezifikation_v2.0}}

=Conceptual Perspective=

{{HL7transclude|cdaefa:Die EFA als zweckgebundene Akte}}
{{HL7transclude|cdaefa:Die EFA als Gesundheitsdatendienst}}
{{HL7transclude|cdaefa:EFA Provider}}
{{HL7transclude|cdaefa:Akteure und Rollen der EFA}}
{{HL7transclude|cdaefa:Prinzipien für Datenschutz und Datensicherheit}}

{{HL7transclude|cdaefa:Kontext, Akte, Ressource}}
{{HL7transclude|cdaefa:EFA Geschäftsobjekte}}
{{HL7transclude|cdaefa:EFA_Business_Lebenszyklus}}
{{HL7transclude|cdaefa:Patienteneinwilligung_zur_EFA}}

{{HL7transclude|cdaefa:Interaktionsmuster der EFA}}
{{HL7transclude|cdaefa:CIM Anlegen einer Fallakte}}
{{HL7transclude|cdaefa:CIM_Anlegen_und_Registrieren_einer_Partition}}
{{HL7transclude|cdaefa:CIM:Einstellen_von_Datenobjekten}}
{{HL7transclude|cdaefa:CIM_Auffinden_der_Fallakten_eines_Patienten}}
{{HL7transclude|cdaefa:CIM_Browsing_über_eine_Akte_oder_eine_Partition}}
{{HL7transclude|cdaefa:CIM_Abruf_von_Datenobjekten}}
{{HL7transclude|cdaefa:CIM_Schließen_einer_Fallakte}}
{{HL7transclude|cdaefa:CIM_Invalidieren_von_Datenobjekten}}
{{HL7transclude|cdaefa:CIM_Anpassen_des_Teilnehmerkreises}}

=Logical Perspective=

{{HL7transclude|cdaefa:EFA_Sicherheitsanforderungen}}
{{HL7transclude|cdaefa:Sicherheitszonen}}

{{HL7transclude|cdaefa:EFA_Business_Informationsmodell}}
{{HL7transclude|cdaefa:EFA_Security_Informationsmodell}}
{{HL7transclude|cdaefa:EFA_Einwilligungsdokument}}

{{HL7transclude|cdaefa:EFA_Kommunikationsmuster}}
{{HL7transclude|cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)}}
{{HL7transclude|cdaefa:EFA_Ressource_Manager_SFM}}
{{HL7transclude|cdaefa:EFA_Document_Registry_SFM}}
{{HL7transclude|cdaefa:EFA_Document_Repository_SFM}}
{{HL7transclude|cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)}}
{{HL7transclude|cdaefa:EFA_Context_Manager_SFM}}
{{HL7transclude|cdaefa:EFA_Identity_Provider_SFM}}
{{HL7transclude|cdaefa:EFA_Policy_Provider_SFM}}
{{HL7transclude|cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten}}

=Implementable Perspective=

{{HL7transclude|cdaefa:EFA_Verwendete_Standards}}
{{HL7transclude|cdaefa:EFA_Used_Namespaces}}

{{HL7transclude|cdaefa:EFA_Metadata_Bindings}}
{{HL7transclude|cdaefa:EFA_XDS_Folder_Metadata_Binding}}
{{HL7transclude|cdaefa:EFA_XDS_Document_Metadata_Binding}}
{{HL7transclude|cdaefa:EFA_Security_Objects_Bindings}}
{{HL7transclude|cdaefa:EFA_Identity_Assertion_SAML2_Binding}}
{{HL7transclude|cdaefa:EFA_Policy_Assertion_SAML2_Binding}}

{{HL7transclude|cdaefa:EFA_IHE_Setup_and_Flow_of_Control}}
{{HL7transclude|cdaefa:EFA_XDS/XDR_Bindings}}
{{HL7transclude|cdaefa:EFA_XDS_ConstraintTransactions}}
{{HL7transclude|cdaefa:EFA_XDS_ResourceManager}}
{{HL7transclude|cdaefa:EFA_XDS_DocumentRegistry}}
{{HL7transclude|cdaefa:EFA_XDS_DocumentRepository}}
{{HL7transclude|cdaefa:EFA_Access_Control_System}}

cdaefa:EFA Sicherheitsdienste (logische Spezifikation)

2013-04-08T08:38:07Z

Rkuhlisch: /* Spezifikation */

{{Infobox Dokument
|Title = EFA Sicherheitsdienste (logische Spezifikation)
|Short = EFA Sicherheitsdienste (logische Spezifikation)
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

= Sicherheitstoken und Sicherheitstokendienste =
Jeder EFA-Anwendungsdienst und jeder EFA-Sicherheitsdienst besitzt eine Sicherheitspolitik, in der u. a. definiert ist, wie der Sicherheitskontext aussehen muss, aus dem heraus der Dienst aufgerufen werden kann. Hierdurch „weiß“ ein EFA-Client, welches Sicherheitstoken er von welchem GDD-Sicherheitsdienst abrufen und in den Ablaufkontext laden muss, bevor der gewünschte Dienst aufgerufen werden kann. Dadurch dass auch Sicherheitsdienste Sicherheitspolitiken besitzen, lässt sich die komplette Ablaufsteuerung über den Sicherheitsdiensten deklarativ abbilden. Beispielsweise kann ein EFA-Anwendungsdienst für den Zugriff auf eine Ressource ein Sicherheitstoken verlangen, über das die entsprechende Berechtigung des Nutzers verifizierbar ist. Der dieses Token ausstellende Autorisierungsdienst wiederum kann eine Politik definieren, dass Berechtigungsnachweise nur ausgestellt werden, wenn der Nutzer über ein entsprechendes Token seine Authentizität nachweist, d.h. vor dem Autorisierungsdienst ein Authentifizierungsdienst aufgerufen wurde.

Im Rahmen des ''IHE Cookbook'' und der EFA-2.0 Spezifikation werden verschiedene Sicherheitstokendienste (föderierte Authentifizierung, Pseudonymisierung, Zugang zu Anwendungen, Autorisierung auf Ressourcen) spezifiziert, die nach dem oben skizzierten Prinzip von allen Aktendiensten genutzt werden können. Welche Sicherheitsdienste ein Aktendienst in Anspruch nimmt, definiert er über seine Sicherheitspolitk, die im Fachmodul in Aufrufe an die Sicherheitstokendienste übersetzt wird.

= EFA Sicherheits(token)dienste =

[[Datei:Sicherheitsdienste_5_Domains.png|480px]]

;EFA Identity Provider
:Der EFA Identity Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Teilnehmersystem aufgerufen und stellt einen Identitätsnachweis für authentifizierte Nutzer aus. Dieser Nachweis enthält neben einem ''Proof-of-Possession'' Merkmal auch Angaben zu Rollen und Gruppenzugehörigkeiten des Nutzers. Der EFA Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z.B. mittels Passwort, HBA oder SMC-B). Bei einer Authentifizierung mittels HBA werden die Nutzerattribute aus dem HBA-Zertifikat in den Identitätsnachweis übernommen. Zusätzlich wird anhand der genutzten SMC-B die Organisationszugehörigkeit eingetragen. Bei der Authentifizierung mittels SMC-B hat sich der Nutzer bereits innerhalb seiner Organisation sicher authentisiert. Auch alle Attribute wurden bereits durch die Organisation zugewiesen. Beim Aufruf des EFA Identity Providers bestätigt die Organisation die durchgeführte Authentifizierung und die Authentizität der Attribute in Form eines selbst ausgestellten, von der SMC-B signierten Identitätsnachweises (Guarantor Assertion). Dieser Nachweis wird vom EFA Identity Provider geprüft und in einen für EFA-Anwendungs- und EFA-Sicherheitsdienste nutzbaren Authentifizierungsnachweis überführt.
;EFA Policy Provider
:Der EFA Policy Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Client oder einem EFA-Anwendungsdienst aufgerufen und liefert einen Verweis auf die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) zu einer Anwendungsinstanz (z. B. einer spezifischen eFA) oder die zum Verweis gehörende Policy. Diese Verweise sind transparent, d. h. sie können sowohl selber bereits eine Semantik tragen (z. B. gemäß IHE BPPC) oder eine Policy-Datei referenzieren. Um auch ein "Policy Pull" zu erlauben (siehe [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf IHE White Paper on Access Control]), wird auch ein Aufruf des Policy Provider durch einen EFA-Anwendungsdienst unterstützt.

{| class="wikitable"
!Dienst || Aufgaben || Datenhaltung
|-
| EFA Identity Provider
|| Authentifiziert einen EFA-Teilnehmer durch Verifikation seiner Credentials. Der Dienst bietet verschiedene Authentifizierungsmethoden an:
* Direktes Vertrauen: Authentifiziert einen EFA-Teilnehmer per X.509 Zertifikat oder Benutzername/Passwort-Kombination
* Vermitteltes Vertrauen: Authentifiziert einen EFA-Teilnehmer durch Verifikation einer übermittelten signierten Guarantor Assertion (lokaler Identitätsnachweis eines EFA-Teilnehmers aus einer Organisation).
|| Weitere Attribute können über einen mit dem EFA Identity Provider gruppierten Verzeichnisdienst abgerufen werden. Der Dienst enthält einen Identity Store, wo die verwalteten Identitäten sowie die Credentials für die Authentifizierung gespeichert sind.
|-
| EFA Policy Provider
|| Gibt eine Policy zu einem bestimmten (Behandlungs-)Zweck heraus. Je nach Autorisierungsmodell ("Policy Push"/"Policy Pull") kann eine explizite Access Control Policy oder ein Verweis (mit impliziter Semantik) die Autorisierung eines Benutzers (oder seiner Rolle) zu einer Fallakte bzw. dem festgelegten Zweck beschreiben.
|| Policies, welche jeweils den konsentierten Kreis der Behandelnden zu einem Zweck definieren.
|}

=== Spezifikation ===
* Normative Spezifikation: [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider Service Functional Model]], [[cdaefa:EFA_Policy_Provider_SFM|EFA Policy Provider Service Functional Model]]
* Binding: [[cdaefa:EFA_Identity_Provider_WS_Trust_Binding|EFA Identity Provider WS Trust Binding]], [[cdaefa:EFA_Policy_Provider_WS Trust_Binding|EFA Policy Provider WS Trust Binding]]

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Metadata Bindings

2013-04-08T08:34:14Z

Rkuhlisch:

For the linkage of XDS compliant components with eCR components the following mapping of business objects MUST be implemented:

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Electronic Case Record
!IHE XDS
|-
|Patient
|Patient
|-
|eCR Record
|''no correspondence''
|-
|eCR Folder
|XDS Folder
|-
|''no correspondence''
|XDS Submission Set
|-
|eCR Medical Data Object
|XDS Document Entry
|}

cdaefa:EFA Security Objects Bindings

2013-04-08T08:33:40Z

Rkuhlisch: Die Seite wurde neu angelegt: „EFA security objects are encapsulated through SAML assertions so as the followin…“

EFA security objects are encapsulated through [[cdaefa:EFA_Verwendete_Standards#Security_Assertion_Markup_Language_.28SAML.29|SAML assertions]] so as the following mapping of security objects MUST be implemented:

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Electronic Case Record
!SAML
|-
|Authentication Token / HP Identity Assertion
|[[cdaefa:EFA_Identity_Assertion_SAML2_Binding|EFA Identity Assertion SAML2 Binding]]
|-
|Authorization Token / Access Policy
|[[cdaefa:EFA_Policy_Assertion_SAML2_Binding|EFA Policy Assertion SAML2 Binding]]
|}

IG:EFA Spezifikation v2.0

2013-04-08T08:21:13Z

Rkuhlisch:

{{Infobox Dokument
|Title = eFA Spezifikation v2.0
|Short = eFA Spezifikation v2.0
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

{{Infobox Ballot Begin}}
{{Ballot | Version = 01 | Date = 2013 | Status = Entwurf | Realm = Deutschland}}
{{Infobox Ballot End}}

{{HL7transclude|cdaefa:EFA_Spezifikation_v2.0}}

=Conceptual Perspective=

{{HL7transclude|cdaefa:Die EFA als zweckgebundene Akte}}
{{HL7transclude|cdaefa:Die EFA als Gesundheitsdatendienst}}
{{HL7transclude|cdaefa:EFA Provider}}
{{HL7transclude|cdaefa:Akteure und Rollen der EFA}}
{{HL7transclude|cdaefa:Prinzipien für Datenschutz und Datensicherheit}}

{{HL7transclude|cdaefa:Kontext, Akte, Ressource}}
{{HL7transclude|cdaefa:EFA Geschäftsobjekte}}
{{HL7transclude|cdaefa:EFA_Business_Lebenszyklus}}
{{HL7transclude|cdaefa:Patienteneinwilligung_zur_EFA}}

{{HL7transclude|cdaefa:Interaktionsmuster der EFA}}
{{HL7transclude|cdaefa:CIM Anlegen einer Fallakte}}
{{HL7transclude|cdaefa:CIM_Anlegen_und_Registrieren_einer_Partition}}
{{HL7transclude|cdaefa:CIM:Einstellen_von_Datenobjekten}}
{{HL7transclude|cdaefa:CIM_Auffinden_der_Fallakten_eines_Patienten}}
{{HL7transclude|cdaefa:CIM_Browsing_über_eine_Akte_oder_eine_Partition}}
{{HL7transclude|cdaefa:CIM_Abruf_von_Datenobjekten}}
{{HL7transclude|cdaefa:CIM_Schließen_einer_Fallakte}}
{{HL7transclude|cdaefa:CIM_Invalidieren_von_Datenobjekten}}
{{HL7transclude|cdaefa:CIM_Anpassen_des_Teilnehmerkreises}}

=Logical Perspective=
{{HL7transclude|cdaefa:EFA Sicherheitsanforderungen}}
{{HL7transclude|cdaefa:EFA Business Informationsmodell}}
{{HL7transclude|cdaefa:EFA Business Lebenszyklus}}
{{HL7transclude|cdaefa:EFA Einwilligungsdokument}}
{{HL7transclude|cdaefa:EFA Kommunikationsmuster}}
{{HL7transclude|cdaefa:EFA Anwendungsdienste (logische Spezifikation)}}
{{HL7transclude|cdaefa:EFA Sicherheitsdienste (logische Spezifikation)}}
{{HL7transclude|cdaefa:EFA Identity Provider SFM}}
{{HL7transclude|cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten}}

=Implementable Perspective=
{{HL7transclude|cdaefa:EFA Verwendete Standards}}
{{HL7transclude|cdaefa:EFA Metadata Bindings}}
{{HL7transclude|cdaefa:EFA XDS Folder Metadata Binding}}
{{HL7transclude|cdaefa:EFA XDS Document Metadata Binding}}
{{HL7transclude|cdaefa:EFA Security Objects Bindings}}
{{HL7transclude|cdaefa:EFA Identity Assertion SAML2 Binding}}
{{HL7transclude|cdaefa:EFA Access Assertion SAML2 Binding}}
{{HL7transclude|cdaefa:EFA Policy Assertion SAML2 Binding}}
{{HL7transclude|cdaefa:EFA IHE Setup and Flow of Control}}
{{HL7transclude|cdaefa:EFA Access Control System}}
{{HL7transclude|cdaefa:EFA XDS/XDR Bindings}}
{{HL7transclude|cdaefa:EFA XDR SetupCaseRecord}}
{{HL7transclude|cdaefa:EFA XDS ListRecords}}
{{HL7transclude|cdaefa:EFA XDS ListRecordContent}}
{{HL7transclude|cdaefa:EFA XDS ListFolderContent}}
{{HL7transclude|cdaefa:EFA XDS RetrieveDocument}}
{{HL7transclude|cdaefa:EFA XDR ProvideDocument}}

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T13:20:08Z

Rkuhlisch: /* Example Assertion */

== SAML 2.0 Profile for ECR Policy Assertions ==

{{NoteBox|This profile applies to scenarios where the eCR Context Manager requests an Access Policy Assertion from the eCR Policy Provider and thus implements a policy push authorization model. There is no specification in the case that the Authorization Decision Provider requests policies from the eCR Policy Provider.}}

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="4"|Assertion Element
!Opt
!Usage Convention
|-
|colspan="4"|@Version
|R
|MUST be “2.0”
|-
|colspan="4"|@ID
|R
|URN encoded unique identifier (UUID) of the assertion
|-
|colspan="4"|@IssueInstant
|R
|Time instant of issuance in UTC
|-
|colspan="4"|Issuer
|R
|Address URI that identifies the endpoint of the issuing service
|-
|colspan="4"|Subject
|R
|This element defines the subject confirmation method of the user in order to use the Policy Assertion as a supporting token. Moreover, it defines the subject name identifier that accords with the user identity from an Identity Assertion.
|-
|
|colspan="3"|NameID
|R
|Identifier of the HP given in the Identity Asstertion encoded as an X.509 subject name, an e-Mail address or as a string value (unspecified format). Only identifiers must be used that can be long-term tracked back to an individual person.
|-
|
|
|colspan="2"|@Format
|R
|MUST be ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' 
For providing an OID as a subject identifier the ''unspecified'' format must be used. The OID must be provided as a string encoded in ISO format.
|-
|
|colspan="3"|SubjectConfirmation
|R
|
|-
|
|
|colspan="2"|@Method
|R
|This element MUST hold a URI reference that identifies a protocol to be used to authenticate the subject.[SAML2.0core] The value of this element MUST be set to 
''urn:oasis:names:tc:SAML:2.0:cm:holder-of-key''
|-
|
|
|colspan="2"|SubjectConfirmationData
|R
|
|-
|
|
|
|ds:KeyInfo
|R
|The XML Signature [XMLSignature] element MUST embed a cryptographic key that is only held by the user. This can be the user’s public key (ds:KeyValue/ds:RSAKeyValue), the complete user’s X.509 certificate (ds:X509Data/ds:X509Certificate), or an encrypted symmetric key (xenc:EncryptedKey [XMLEncryption]). This symmetric key MUST be encrypted by using the public key of the consumer service’s certificate [eFA PKI 1.2].
|-
|colspan="4"|Conditions
|R
|
|-
|
|colspan="3"|@NotBefore
|R
|time instant from which the assertion is useable. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion.
|-
|
|colspan="3"|@NotOnOrAfter
|R
|Time instant at which the assertion expires. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion. The maximum validity timespan for a Policy Assertion MUST NOT be more than 4 hours.
|-
|colspan="4"|XACMLPolicyStatement
|R
|
|-
|
|colspan="3"|PolicySet
|R
|PolicySet that expresses the given authorization (see section below for details).
|-
|colspan="4"|ds:Signature
|R
|Enveloped XML signature of the issuer of the Policy Assertion (see section below for details).
|}

=== PolicySet Profile ===

The ECR 2.0 specification differentiates three kinds of an authorization statement as it is described logically in the security token services section for the [[cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)|Policy Provider]]. These are:
* Reference without semantics (policyId) to an access policy which contains the valid authorization rules for an eCR Consumer
* Reference with semantics (e.g., as per IHE BPPC)
* Access policy which contains the valid authorization rules for an eCR Consumer

In order to implement such differentiations the ''<PolicySet>'' element has different sub-elements.

==== Policy Assignment ====
{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="6"|PolicySet Element
!Opt
!Usage Convention
|-
|colspan="6"|@PolicySetId
|R
|URN encoded unique identifier (UUID) of the policy set.
|-
|colspan="6"|@PolicyCombiningAlgId
|R
|This attribute is REQUIRED. Its value is a predefined identifier of the policy-combining algorithm for this policy set (see Appendix C and section B.10 in [XACML2.0Core]). The ''urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:ordered-permit-overrides'' algorithm has been used. Other algorithms are not allowed.
|-
|colspan="6"|Target
|R
|This element is used to specify the resource match (i.e., [[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]])
|-
|
|colspan="5"|Subjects
|R
|This element contains one ''xacml:Subject'' element.
|-
|
|
|colspan="4"|Subject
|R
|It contains one ''xacml:SubjectMatch'' element.
|-
|
|
|
|colspan="3"|SubjectMatch
|R
|It defines matches of the subject attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier must refer to the subject nameID format of the Identity Assertion. The following list defines the used identifier for this policy (see Section 7.5 in [XACML2.0Core]):
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' -> ''urn:oasis:names:tc:xacml:1.0:function:string-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' -> ''urn:oasis:names:tc:xacml:1.0:function:x500Name-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' -> ''urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal''
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the subject value for matching depending on the subject match id format.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|
|
|
|colspan="2"|SubjectAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@SubjectCategory
|O
|It specifies the categorized subject from which to match named subject attributes. If set, it MUST have the value ''urn:oasis:names:tc:xacml:1.0:subject-category:access-subject''.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:subject:subject-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|colspan="5"|Resources
|R
|This element contains one ''xacml:Resource'' element.
|-
|
|
|colspan="4"|Resource
|R
|It contains one ''xacml:ResourceMatch'' element.
|-
|
|
|
|colspan="3"|ResourceMatch
|R
|It defines matches of the resource attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier ''urn:oasis:names:tc:xacml:2.0:function:anyURI-regexp-match'' is defined to use regular expressions (see A.3.13 in [XACML2.0Core]).
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the regular expression for matching.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is ''http://www.w3.org/2001/XMLSchema#string'' to indicate that the attribute value is of ''string'' simple type.
|-
|
|
|
|
|colspan="2"|ResourceAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|It specifies the identifier of the attribute that is used for matching. The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:resource:resource-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|It specifies the type of the values that the resource attribute designator returns. The value of this attribute is set to ''http://www.w3.org/2001/XMLSchema#anyURI''.
|-
|colspan="6"|PolicySetIdReference
|R
|Its value either references an assigned access policy that is expressed in a separate XACML ''PolicySet'' or already expresses the given authorization.
|-
|}

==== Policy Attachment ====
It is implementation-specific how the ''PolicySet'' with the authorization rules is defined - there are no restrictions made. However, there MUST NOT be used further ''PolicyIdReference'' or ''PolicySetIdReference'' elements.

== Assertion Signature ==
Every Policy Assertion MUST be signed by its issuer. The XML signature MUST be applied by using the ''saml:Assertion/ds:Signature'' element as defined below.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Signature Parameter
!Usage Convention
|-
|CanonicalizationMethod
|SHOULD be ''http://www.w3.org/2001/10/xml-exc-c14n#''
|-
|Transformation
|Enveloped signature transform acc. to section 6.6.4 of [W3C XMLDSig] SHOULD be used (''http://www.w3.org/2000/09/xmldsig#enveloped-signature''). In addition, exclusive canonicalization SHOULD be defined as transformation (''http://www.w3.org/2001/10/xml-exc-c14n#'', acc. [W3C XMLDSig] and [W3C XML-EXC 1.0]). As inclusive namespaces other prefixes than the ones defined in [[cdaefa:EFA Used Namespaces|''EFA Namespaces'']] MUST NOT be used.
|-
|SignatureMethod
|For signing assertions the signature method 
''http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'' or 
''http://www.w3.org/2000/09/xmldsig#rsa-sha1'' 
SHOULD be used. An assertion consumer MAY reject signatures that use SHA-1 for digesting.
|-
|DigestMethod
|For signing assertions the digest method 
''http://www.w3.org/2000/09/xmldsig#sha1'' or 
''http://www.w3.org/2001/04/xmlenc#sha256'' 
SHOULD be used. An assertion consumer MAY reject SHA-1 digests.
|-
|KeyInfo
|This element MUST either contain a wsse:SecurityTokenReference element which references the X.509 certificate of the assertion’s issuer by using a subject key identifier OR contain a ds:X509Data element which contains the X.509 certificate of the assertion issuer.
|}

== Example Assertion ==

<pre>
<soap12:Envelope … >
<soap12:Header … >
<wsse:Security … >
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="uuid-6dbb391c-20d3-4568-8c04-ff9d91d049c1"
IssueInstant="2013-04-05T08:14:28.788Z" Version="2.0">
<saml:Issuer>urn:de:berlin:hp:pap</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#urn:uuid:7102AC72154DCFD1F51253534608780">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="ds saml xs" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>A1LyLvFHRrYaOJ28YVFd3MfKGSI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ggyn … LQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
...
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2013-04-05T08:14:28.788Z"
NotOnOrAfter="2013-04-05T12:14:28.788Z">
</saml:Conditions>
<xacml-saml:XACMLPolicyStatement>
<xacml:PolicySet>
<xacml:Target>
<xacml:Subjects>
<xacml:Subject>
<xacml:SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:x500Name-equal">
<xacml:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">CN= ...</AttributeValue>
<xacml:SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="urn:oasis:names:tc:xacml:1.0:data-type:x500Name"/>
</xacml:SubjectMatch>
</xacml:Subject>
</xacml:Subjects>
<xacml:Resources>
<xacml:Resource>
<xacml:ResourceMatch MatchId="urn:oasis:names:tc:xacml:2.0:function:anyURI-regexp-match">
<xacml:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">...</AttributeValue>
<xacml:ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>
</xacml:ResourceMatch>
</xacml:Resource>
</xacml:Resources>
</xacml:Target>
<xacml:PolicySetIdReference>urn:ecr:names:xacml:2.0:default:policyid:permit-all</xacml:PolicySetIdReference>
</xacml:PolicySet>
</xacml-saml:XACMLPolicyStatement>
</saml:Assertion>
</wsse:Security>
</soap12:Header>
<soap12:Body/>
</soap12:Envelope>
</pre>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T13:01:53Z

Rkuhlisch: /* Policy Assignment */

== SAML 2.0 Profile for ECR Policy Assertions ==

{{NoteBox|This profile applies to scenarios where the eCR Context Manager requests an Access Policy Assertion from the eCR Policy Provider and thus implements a policy push authorization model. There is no specification in the case that the Authorization Decision Provider requests policies from the eCR Policy Provider.}}

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="4"|Assertion Element
!Opt
!Usage Convention
|-
|colspan="4"|@Version
|R
|MUST be “2.0”
|-
|colspan="4"|@ID
|R
|URN encoded unique identifier (UUID) of the assertion
|-
|colspan="4"|@IssueInstant
|R
|Time instant of issuance in UTC
|-
|colspan="4"|Issuer
|R
|Address URI that identifies the endpoint of the issuing service
|-
|colspan="4"|Subject
|R
|This element defines the subject confirmation method of the user in order to use the Policy Assertion as a supporting token. Moreover, it defines the subject name identifier that accords with the user identity from an Identity Assertion.
|-
|
|colspan="3"|NameID
|R
|Identifier of the HP given in the Identity Asstertion encoded as an X.509 subject name, an e-Mail address or as a string value (unspecified format). Only identifiers must be used that can be long-term tracked back to an individual person.
|-
|
|
|colspan="2"|@Format
|R
|MUST be ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' 
For providing an OID as a subject identifier the ''unspecified'' format must be used. The OID must be provided as a string encoded in ISO format.
|-
|
|colspan="3"|SubjectConfirmation
|R
|
|-
|
|
|colspan="2"|@Method
|R
|This element MUST hold a URI reference that identifies a protocol to be used to authenticate the subject.[SAML2.0core] The value of this element MUST be set to 
''urn:oasis:names:tc:SAML:2.0:cm:holder-of-key''
|-
|
|
|colspan="2"|SubjectConfirmationData
|R
|
|-
|
|
|
|ds:KeyInfo
|R
|The XML Signature [XMLSignature] element MUST embed a cryptographic key that is only held by the user. This can be the user’s public key (ds:KeyValue/ds:RSAKeyValue), the complete user’s X.509 certificate (ds:X509Data/ds:X509Certificate), or an encrypted symmetric key (xenc:EncryptedKey [XMLEncryption]). This symmetric key MUST be encrypted by using the public key of the consumer service’s certificate [eFA PKI 1.2].
|-
|colspan="4"|Conditions
|R
|
|-
|
|colspan="3"|@NotBefore
|R
|time instant from which the assertion is useable. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion.
|-
|
|colspan="3"|@NotOnOrAfter
|R
|Time instant at which the assertion expires. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion. The maximum validity timespan for a Policy Assertion MUST NOT be more than 4 hours.
|-
|colspan="4"|XACMLPolicyStatement
|R
|
|-
|
|colspan="3"|PolicySet
|R
|PolicySet that expresses the given authorization (see section below for details).
|-
|colspan="4"|ds:Signature
|R
|Enveloped XML signature of the issuer of the Policy Assertion (see section below for details).
|}

=== PolicySet Profile ===

The ECR 2.0 specification differentiates three kinds of an authorization statement as it is described logically in the security token services section for the [[cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)|Policy Provider]]. These are:
* Reference without semantics (policyId) to an access policy which contains the valid authorization rules for an eCR Consumer
* Reference with semantics (e.g., as per IHE BPPC)
* Access policy which contains the valid authorization rules for an eCR Consumer

In order to implement such differentiations the ''<PolicySet>'' element has different sub-elements.

==== Policy Assignment ====
{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="6"|PolicySet Element
!Opt
!Usage Convention
|-
|colspan="6"|@PolicySetId
|R
|URN encoded unique identifier (UUID) of the policy set.
|-
|colspan="6"|@PolicyCombiningAlgId
|R
|This attribute is REQUIRED. Its value is a predefined identifier of the policy-combining algorithm for this policy set (see Appendix C and section B.10 in [XACML2.0Core]). The ''urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:ordered-permit-overrides'' algorithm has been used. Other algorithms are not allowed.
|-
|colspan="6"|Target
|R
|This element is used to specify the resource match (i.e., [[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]])
|-
|
|colspan="5"|Subjects
|R
|This element contains one ''xacml:Subject'' element.
|-
|
|
|colspan="4"|Subject
|R
|It contains one ''xacml:SubjectMatch'' element.
|-
|
|
|
|colspan="3"|SubjectMatch
|R
|It defines matches of the subject attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier must refer to the subject nameID format of the Identity Assertion. The following list defines the used identifier for this policy (see Section 7.5 in [XACML2.0Core]):
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' -> ''urn:oasis:names:tc:xacml:1.0:function:string-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' -> ''urn:oasis:names:tc:xacml:1.0:function:x500Name-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' -> ''urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal''
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the subject value for matching depending on the subject match id format.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|
|
|
|colspan="2"|SubjectAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@SubjectCategory
|O
|It specifies the categorized subject from which to match named subject attributes. If set, it MUST have the value ''urn:oasis:names:tc:xacml:1.0:subject-category:access-subject''.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:subject:subject-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|colspan="5"|Resources
|R
|This element contains one ''xacml:Resource'' element.
|-
|
|
|colspan="4"|Resource
|R
|It contains one ''xacml:ResourceMatch'' element.
|-
|
|
|
|colspan="3"|ResourceMatch
|R
|It defines matches of the resource attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier ''urn:oasis:names:tc:xacml:2.0:function:anyURI-regexp-match'' is defined to use regular expressions (see A.3.13 in [XACML2.0Core]).
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the regular expression for matching.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is ''http://www.w3.org/2001/XMLSchema#string'' to indicate that the attribute value is of ''string'' simple type.
|-
|
|
|
|
|colspan="2"|ResourceAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|It specifies the identifier of the attribute that is used for matching. The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:resource:resource-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|It specifies the type of the values that the resource attribute designator returns. The value of this attribute is set to ''http://www.w3.org/2001/XMLSchema#anyURI''.
|-
|colspan="6"|PolicySetIdReference
|R
|Its value either references an assigned access policy that is expressed in a separate XACML ''PolicySet'' or already expresses the given authorization.
|-
|}

==== Policy Attachment ====
It is implementation-specific how the ''PolicySet'' with the authorization rules is defined - there are no restrictions made. However, there MUST NOT be used further ''PolicyIdReference'' or ''PolicySetIdReference'' elements.

== Assertion Signature ==
Every Policy Assertion MUST be signed by its issuer. The XML signature MUST be applied by using the ''saml:Assertion/ds:Signature'' element as defined below.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Signature Parameter
!Usage Convention
|-
|CanonicalizationMethod
|SHOULD be ''http://www.w3.org/2001/10/xml-exc-c14n#''
|-
|Transformation
|Enveloped signature transform acc. to section 6.6.4 of [W3C XMLDSig] SHOULD be used (''http://www.w3.org/2000/09/xmldsig#enveloped-signature''). In addition, exclusive canonicalization SHOULD be defined as transformation (''http://www.w3.org/2001/10/xml-exc-c14n#'', acc. [W3C XMLDSig] and [W3C XML-EXC 1.0]). As inclusive namespaces other prefixes than the ones defined in [[cdaefa:EFA Used Namespaces|''EFA Namespaces'']] MUST NOT be used.
|-
|SignatureMethod
|For signing assertions the signature method 
''http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'' or 
''http://www.w3.org/2000/09/xmldsig#rsa-sha1'' 
SHOULD be used. An assertion consumer MAY reject signatures that use SHA-1 for digesting.
|-
|DigestMethod
|For signing assertions the digest method 
''http://www.w3.org/2000/09/xmldsig#sha1'' or 
''http://www.w3.org/2001/04/xmlenc#sha256'' 
SHOULD be used. An assertion consumer MAY reject SHA-1 digests.
|-
|KeyInfo
|This element MUST either contain a wsse:SecurityTokenReference element which references the X.509 certificate of the assertion’s issuer by using a subject key identifier OR contain a ds:X509Data element which contains the X.509 certificate of the assertion issuer.
|}

== Example Assertion ==

<pre>
<soap12:Envelope … >
<soap12:Header … >
<wsse:Security … >
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="uuid-6dbb391c-20d3-4568-8c04-ff9d91d049c1"
IssueInstant="2013-04-05T08:14:28.788Z" Version="2.0">
<saml:Issuer>urn:de:berlin:hp:pap</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#urn:uuid:7102AC72154DCFD1F51253534608780">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="ds saml xs" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>A1LyLvFHRrYaOJ28YVFd3MfKGSI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ggyn … LQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
...
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2013-04-05T08:14:28.788Z"
NotOnOrAfter="2013-04-05T12:14:28.788Z">
</saml:Conditions>
<xacml-saml:XACMLPolicyStatement>
<xacml:PolicySet>
...
</xacml:PolicySet>
</xacml-saml:XACMLPolicyStatement>
</saml:Assertion>
</wsse:Security>
</pre>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T12:54:21Z

Rkuhlisch: /* Policy Assignment */

== SAML 2.0 Profile for ECR Policy Assertions ==

{{NoteBox|This profile applies to scenarios where the eCR Context Manager requests an Access Policy Assertion from the eCR Policy Provider and thus implements a policy push authorization model. There is no specification in the case that the Authorization Decision Provider requests policies from the eCR Policy Provider.}}

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="4"|Assertion Element
!Opt
!Usage Convention
|-
|colspan="4"|@Version
|R
|MUST be “2.0”
|-
|colspan="4"|@ID
|R
|URN encoded unique identifier (UUID) of the assertion
|-
|colspan="4"|@IssueInstant
|R
|Time instant of issuance in UTC
|-
|colspan="4"|Issuer
|R
|Address URI that identifies the endpoint of the issuing service
|-
|colspan="4"|Subject
|R
|This element defines the subject confirmation method of the user in order to use the Policy Assertion as a supporting token. Moreover, it defines the subject name identifier that accords with the user identity from an Identity Assertion.
|-
|
|colspan="3"|NameID
|R
|Identifier of the HP given in the Identity Asstertion encoded as an X.509 subject name, an e-Mail address or as a string value (unspecified format). Only identifiers must be used that can be long-term tracked back to an individual person.
|-
|
|
|colspan="2"|@Format
|R
|MUST be ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' 
For providing an OID as a subject identifier the ''unspecified'' format must be used. The OID must be provided as a string encoded in ISO format.
|-
|
|colspan="3"|SubjectConfirmation
|R
|
|-
|
|
|colspan="2"|@Method
|R
|This element MUST hold a URI reference that identifies a protocol to be used to authenticate the subject.[SAML2.0core] The value of this element MUST be set to 
''urn:oasis:names:tc:SAML:2.0:cm:holder-of-key''
|-
|
|
|colspan="2"|SubjectConfirmationData
|R
|
|-
|
|
|
|ds:KeyInfo
|R
|The XML Signature [XMLSignature] element MUST embed a cryptographic key that is only held by the user. This can be the user’s public key (ds:KeyValue/ds:RSAKeyValue), the complete user’s X.509 certificate (ds:X509Data/ds:X509Certificate), or an encrypted symmetric key (xenc:EncryptedKey [XMLEncryption]). This symmetric key MUST be encrypted by using the public key of the consumer service’s certificate [eFA PKI 1.2].
|-
|colspan="4"|Conditions
|R
|
|-
|
|colspan="3"|@NotBefore
|R
|time instant from which the assertion is useable. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion.
|-
|
|colspan="3"|@NotOnOrAfter
|R
|Time instant at which the assertion expires. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion. The maximum validity timespan for a Policy Assertion MUST NOT be more than 4 hours.
|-
|colspan="4"|XACMLPolicyStatement
|R
|
|-
|
|colspan="3"|PolicySet
|R
|PolicySet that expresses the given authorization (see section below for details).
|-
|colspan="4"|ds:Signature
|R
|Enveloped XML signature of the issuer of the Policy Assertion (see section below for details).
|}

=== PolicySet Profile ===

The ECR 2.0 specification differentiates three kinds of an authorization statement as it is described logically in the security token services section for the [[cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)|Policy Provider]]. These are:
* Reference without semantics (policyId) to an access policy which contains the valid authorization rules for an eCR Consumer
* Reference with semantics (e.g., as per IHE BPPC)
* Access policy which contains the valid authorization rules for an eCR Consumer

In order to implement such differentiations the ''<PolicySet>'' element has different sub-elements.

==== Policy Assignment ====
{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="6"|PolicySet Element
!Opt
!Usage Convention
|-
|colspan="6"|@PolicySetId
|R
|URN encoded unique identifier (UUID) of the policy set.
|-
|colspan="6"|@PolicyCombiningAlgId
|R
|This attribute is REQUIRED. Its value is a predefined identifier of the policy-combining algorithm for this policy set (see Appendix C and section B.10 in [XACML2.0Core]). The ''urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:ordered-permit-overrides'' algorithm has been used. Other algorithms are not allowed.
|-
|colspan="6"|Target
|R
|This element is used to specify the resource match (i.e., [[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]])
|-
|
|colspan="5"|Subjects
|R
|This element contains one ''xacml:Subject'' element.
|-
|
|
|colspan="4"|Subject
|R
|It contains one ''xacml:SubjectMatch'' element.
|-
|
|
|
|colspan="3"|SubjectMatch
|R
|It defines matches of the subject attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier must refer to the subject nameID format of the Identity Assertion. The following list defines the used identifier for this policy (see Section 7.5 in [XACML2.0Core]):
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' -> ''urn:oasis:names:tc:xacml:1.0:function:string-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' -> ''urn:oasis:names:tc:xacml:1.0:function:x500Name-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' -> ''urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal''
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the subject value for matching depending on the subject match id format.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|
|
|
|colspan="2"|SubjectAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@SubjectCategory
|O
|It specifies the categorized subject from which to match named subject attributes. If set, it MUST have the value ''urn:oasis:names:tc:xacml:1.0:subject-category:access-subject''.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:subject:subject-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|colspan="5"|Resources
|R
|This element contains one ''xacml:Resource'' element.
|-
|
|
|colspan="4"|Resource
|R
|It contains one ''xacml:ResourceMatch'' element.
|-
|
|
|
|colspan="3"|ResourceMatch
|R
|It defines matches of the resource attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier ''urn:oasis:names:tc:xacml:1.0:function:anyURI-regexp-match'' is defined to use regular expressions (see A.3.13 in [XACML2.0Core]).
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the regular expression for matching.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is ''http://www.w3.org/2001/XMLSchema#string'' to indicate that the attribute value is of ''string'' simple type.
|-
|
|
|
|
|colspan="2"|ResourceAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|It specifies the identifier of the attribute that is used for matching. The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:resource:resource-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|It specifies the type of the values that the resource attribute designator returns. The value of this attribute is set to ''http://www.w3.org/2001/XMLSchema#anyURI''.
|-
|colspan="6"|PolicySetIdReference
|R
|Its value either references an assigned access policy that is expressed in a separate XACML ''PolicySet'' or already expresses the given authorization.
|-
|}

==== Policy Attachment ====
It is implementation-specific how the ''PolicySet'' with the authorization rules is defined - there are no restrictions made. However, there MUST NOT be used further ''PolicyIdReference'' or ''PolicySetIdReference'' elements.

== Assertion Signature ==
Every Policy Assertion MUST be signed by its issuer. The XML signature MUST be applied by using the ''saml:Assertion/ds:Signature'' element as defined below.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Signature Parameter
!Usage Convention
|-
|CanonicalizationMethod
|SHOULD be ''http://www.w3.org/2001/10/xml-exc-c14n#''
|-
|Transformation
|Enveloped signature transform acc. to section 6.6.4 of [W3C XMLDSig] SHOULD be used (''http://www.w3.org/2000/09/xmldsig#enveloped-signature''). In addition, exclusive canonicalization SHOULD be defined as transformation (''http://www.w3.org/2001/10/xml-exc-c14n#'', acc. [W3C XMLDSig] and [W3C XML-EXC 1.0]). As inclusive namespaces other prefixes than the ones defined in [[cdaefa:EFA Used Namespaces|''EFA Namespaces'']] MUST NOT be used.
|-
|SignatureMethod
|For signing assertions the signature method 
''http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'' or 
''http://www.w3.org/2000/09/xmldsig#rsa-sha1'' 
SHOULD be used. An assertion consumer MAY reject signatures that use SHA-1 for digesting.
|-
|DigestMethod
|For signing assertions the digest method 
''http://www.w3.org/2000/09/xmldsig#sha1'' or 
''http://www.w3.org/2001/04/xmlenc#sha256'' 
SHOULD be used. An assertion consumer MAY reject SHA-1 digests.
|-
|KeyInfo
|This element MUST either contain a wsse:SecurityTokenReference element which references the X.509 certificate of the assertion’s issuer by using a subject key identifier OR contain a ds:X509Data element which contains the X.509 certificate of the assertion issuer.
|}

== Example Assertion ==

<pre>
<soap12:Envelope … >
<soap12:Header … >
<wsse:Security … >
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="uuid-6dbb391c-20d3-4568-8c04-ff9d91d049c1"
IssueInstant="2013-04-05T08:14:28.788Z" Version="2.0">
<saml:Issuer>urn:de:berlin:hp:pap</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#urn:uuid:7102AC72154DCFD1F51253534608780">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="ds saml xs" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>A1LyLvFHRrYaOJ28YVFd3MfKGSI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ggyn … LQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
...
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2013-04-05T08:14:28.788Z"
NotOnOrAfter="2013-04-05T12:14:28.788Z">
</saml:Conditions>
<xacml-saml:XACMLPolicyStatement>
<xacml:PolicySet>
...
</xacml:PolicySet>
</xacml-saml:XACMLPolicyStatement>
</saml:Assertion>
</wsse:Security>
</pre>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T11:47:41Z

Rkuhlisch: /* Policy Assignment */

== SAML 2.0 Profile for ECR Policy Assertions ==

{{NoteBox|This profile applies to scenarios where the eCR Context Manager requests an Access Policy Assertion from the eCR Policy Provider and thus implements a policy push authorization model. There is no specification in the case that the Authorization Decision Provider requests policies from the eCR Policy Provider.}}

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="4"|Assertion Element
!Opt
!Usage Convention
|-
|colspan="4"|@Version
|R
|MUST be “2.0”
|-
|colspan="4"|@ID
|R
|URN encoded unique identifier (UUID) of the assertion
|-
|colspan="4"|@IssueInstant
|R
|Time instant of issuance in UTC
|-
|colspan="4"|Issuer
|R
|Address URI that identifies the endpoint of the issuing service
|-
|colspan="4"|Subject
|R
|This element defines the subject confirmation method of the user in order to use the Policy Assertion as a supporting token. Moreover, it defines the subject name identifier that accords with the user identity from an Identity Assertion.
|-
|
|colspan="3"|NameID
|R
|Identifier of the HP given in the Identity Asstertion encoded as an X.509 subject name, an e-Mail address or as a string value (unspecified format). Only identifiers must be used that can be long-term tracked back to an individual person.
|-
|
|
|colspan="2"|@Format
|R
|MUST be ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' 
For providing an OID as a subject identifier the ''unspecified'' format must be used. The OID must be provided as a string encoded in ISO format.
|-
|
|colspan="3"|SubjectConfirmation
|R
|
|-
|
|
|colspan="2"|@Method
|R
|This element MUST hold a URI reference that identifies a protocol to be used to authenticate the subject.[SAML2.0core] The value of this element MUST be set to 
''urn:oasis:names:tc:SAML:2.0:cm:holder-of-key''
|-
|
|
|colspan="2"|SubjectConfirmationData
|R
|
|-
|
|
|
|ds:KeyInfo
|R
|The XML Signature [XMLSignature] element MUST embed a cryptographic key that is only held by the user. This can be the user’s public key (ds:KeyValue/ds:RSAKeyValue), the complete user’s X.509 certificate (ds:X509Data/ds:X509Certificate), or an encrypted symmetric key (xenc:EncryptedKey [XMLEncryption]). This symmetric key MUST be encrypted by using the public key of the consumer service’s certificate [eFA PKI 1.2].
|-
|colspan="4"|Conditions
|R
|
|-
|
|colspan="3"|@NotBefore
|R
|time instant from which the assertion is useable. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion.
|-
|
|colspan="3"|@NotOnOrAfter
|R
|Time instant at which the assertion expires. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion. The maximum validity timespan for a Policy Assertion MUST NOT be more than 4 hours.
|-
|colspan="4"|XACMLPolicyStatement
|R
|
|-
|
|colspan="3"|PolicySet
|R
|PolicySet that expresses the given authorization (see section below for details).
|-
|colspan="4"|ds:Signature
|R
|Enveloped XML signature of the issuer of the Policy Assertion (see section below for details).
|}

=== PolicySet Profile ===

The ECR 2.0 specification differentiates three kinds of an authorization statement as it is described logically in the security token services section for the [[cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)|Policy Provider]]. These are:
* Reference without semantics (policyId) to an access policy which contains the valid authorization rules for an eCR Consumer
* Reference with semantics (e.g., as per IHE BPPC)
* Access policy which contains the valid authorization rules for an eCR Consumer

In order to implement such differentiations the ''<PolicySet>'' element has different sub-elements.

==== Policy Assignment ====
{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="6"|PolicySet Element
!Opt
!Usage Convention
|-
|colspan="6"|@PolicySetId
|R
|URN encoded unique identifier (UUID) of the policy set.
|-
|colspan="6"|@PolicyCombiningAlgId
|R
|This attribute is REQUIRED. Its value is a predefined identifier of the policy-combining algorithm for this policy set (see Appendix C and section B.10 in [XACML2.0Core]). The ''urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:ordered-permit-overrides'' algorithm has been used. Other algorithms are not allowed.
|-
|colspan="6"|Target
|R
|This element is used to specify the resource match (i.e., [[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]])
|-
|
|colspan="5"|Subjects
|R
|This element contains one ''xacml:Subject'' element.
|-
|
|
|colspan="4"|Subject
|R
|It contains one ''xacml:SubjectMatch'' element.
|-
|
|
|
|colspan="3"|SubjectMatch
|R
|It defines matches of the subject attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier must refer to the subject nameID format of the Identity Assertion. The following list defines the used identifier for this policy (see Section 7.5 in [XACML2.0Core]):
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' -> ''urn:oasis:names:tc:xacml:1.0:function:string-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' -> ''urn:oasis:names:tc:xacml:1.0:function:x500Name-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' -> ''urn:oasis:names:tc:xacml:1.0:function:rfc822Name-equal''
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the subject value for matching depending on the subject match id format.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|
|
|
|colspan="2"|SubjectAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@SubjectCategory
|O
|It specifies the categorized subject from which to match named subject attributes. If set, it MUST have the value ''urn:oasis:names:tc:xacml:1.0:subject-category:access-subject''.
|-
|
|
|
|
|
|colspan="1"|AttributeId
|R
|The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:subject:subject-id''.
|-
|
|
|
|
|
|colspan="1"|DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|colspan="5"|Resources
|R
|This element contains one ''xacml:Resource'' element.
|-
|
|
|colspan="4"|Resource
|R
|It contains one ''xacml:ResourceMatch'' element.
|-
|
|
|
|colspan="3"|ResourceMatch
|R
|It defines matches of the resource attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier ''urn:oasis:names:tc:xacml:1.0:function:anyURI-regexp-match'' is defined to use regular expressions (see A.3.13 in [XACML2.0Core]).
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the regular expression for matching.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is ''http://www.w3.org/2001/XMLSchema#string'' to indicate that the attribute value is of ''string'' simple type.
|-
|
|
|
|
|colspan="2"|ResourceAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|It specifies the identifier of the attribute that is used for matching. The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:resource:resource-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|It specifies the type of the values that the resource attribute designator returns. The value of this attribute is set to ''http://www.w3.org/2001/XMLSchema#anyURI''.
|-
|colspan="6"|PolicySetIdReference
|R
|Its value either references an assigned access policy that is expressed in a separate XACML ''PolicySet'' or already expresses the given authorization.
|-
|}

==== Policy Attachment ====
It is implementation-specific how the ''PolicySet'' with the authorization rules is defined - there are no restrictions made. However, there MUST NOT be used further ''PolicyIdReference'' or ''PolicySetIdReference'' elements.

== Assertion Signature ==
Every Policy Assertion MUST be signed by its issuer. The XML signature MUST be applied by using the ''saml:Assertion/ds:Signature'' element as defined below.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Signature Parameter
!Usage Convention
|-
|CanonicalizationMethod
|SHOULD be ''http://www.w3.org/2001/10/xml-exc-c14n#''
|-
|Transformation
|Enveloped signature transform acc. to section 6.6.4 of [W3C XMLDSig] SHOULD be used (''http://www.w3.org/2000/09/xmldsig#enveloped-signature''). In addition, exclusive canonicalization SHOULD be defined as transformation (''http://www.w3.org/2001/10/xml-exc-c14n#'', acc. [W3C XMLDSig] and [W3C XML-EXC 1.0]). As inclusive namespaces other prefixes than the ones defined in [[cdaefa:EFA Used Namespaces|''EFA Namespaces'']] MUST NOT be used.
|-
|SignatureMethod
|For signing assertions the signature method 
''http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'' or 
''http://www.w3.org/2000/09/xmldsig#rsa-sha1'' 
SHOULD be used. An assertion consumer MAY reject signatures that use SHA-1 for digesting.
|-
|DigestMethod
|For signing assertions the digest method 
''http://www.w3.org/2000/09/xmldsig#sha1'' or 
''http://www.w3.org/2001/04/xmlenc#sha256'' 
SHOULD be used. An assertion consumer MAY reject SHA-1 digests.
|-
|KeyInfo
|This element MUST either contain a wsse:SecurityTokenReference element which references the X.509 certificate of the assertion’s issuer by using a subject key identifier OR contain a ds:X509Data element which contains the X.509 certificate of the assertion issuer.
|}

== Example Assertion ==

<pre>
<soap12:Envelope … >
<soap12:Header … >
<wsse:Security … >
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="uuid-6dbb391c-20d3-4568-8c04-ff9d91d049c1"
IssueInstant="2013-04-05T08:14:28.788Z" Version="2.0">
<saml:Issuer>urn:de:berlin:hp:pap</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#urn:uuid:7102AC72154DCFD1F51253534608780">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="ds saml xs" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>A1LyLvFHRrYaOJ28YVFd3MfKGSI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ggyn … LQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
...
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2013-04-05T08:14:28.788Z"
NotOnOrAfter="2013-04-05T12:14:28.788Z">
</saml:Conditions>
<xacml-saml:XACMLPolicyStatement>
<xacml:PolicySet>
...
</xacml:PolicySet>
</xacml-saml:XACMLPolicyStatement>
</saml:Assertion>
</wsse:Security>
</pre>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T11:22:20Z

Rkuhlisch: /* Policy Assignment */

== SAML 2.0 Profile for ECR Policy Assertions ==

{{NoteBox|This profile applies to scenarios where the eCR Context Manager requests an Access Policy Assertion from the eCR Policy Provider and thus implements a policy push authorization model. There is no specification in the case that the Authorization Decision Provider requests policies from the eCR Policy Provider.}}

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="4"|Assertion Element
!Opt
!Usage Convention
|-
|colspan="4"|@Version
|R
|MUST be “2.0”
|-
|colspan="4"|@ID
|R
|URN encoded unique identifier (UUID) of the assertion
|-
|colspan="4"|@IssueInstant
|R
|Time instant of issuance in UTC
|-
|colspan="4"|Issuer
|R
|Address URI that identifies the endpoint of the issuing service
|-
|colspan="4"|Subject
|R
|This element defines the subject confirmation method of the user in order to use the Policy Assertion as a supporting token. Moreover, it defines the subject name identifier that accords with the user identity from an Identity Assertion.
|-
|
|colspan="3"|NameID
|R
|Identifier of the HP given in the Identity Asstertion encoded as an X.509 subject name, an e-Mail address or as a string value (unspecified format). Only identifiers must be used that can be long-term tracked back to an individual person.
|-
|
|
|colspan="2"|@Format
|R
|MUST be ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' 
or ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' 
For providing an OID as a subject identifier the ''unspecified'' format must be used. The OID must be provided as a string encoded in ISO format.
|-
|
|colspan="3"|SubjectConfirmation
|R
|
|-
|
|
|colspan="2"|@Method
|R
|This element MUST hold a URI reference that identifies a protocol to be used to authenticate the subject.[SAML2.0core] The value of this element MUST be set to 
''urn:oasis:names:tc:SAML:2.0:cm:holder-of-key''
|-
|
|
|colspan="2"|SubjectConfirmationData
|R
|
|-
|
|
|
|ds:KeyInfo
|R
|The XML Signature [XMLSignature] element MUST embed a cryptographic key that is only held by the user. This can be the user’s public key (ds:KeyValue/ds:RSAKeyValue), the complete user’s X.509 certificate (ds:X509Data/ds:X509Certificate), or an encrypted symmetric key (xenc:EncryptedKey [XMLEncryption]). This symmetric key MUST be encrypted by using the public key of the consumer service’s certificate [eFA PKI 1.2].
|-
|colspan="4"|Conditions
|R
|
|-
|
|colspan="3"|@NotBefore
|R
|time instant from which the assertion is useable. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion.
|-
|
|colspan="3"|@NotOnOrAfter
|R
|Time instant at which the assertion expires. This condition MUST be assessed by the assertion consumer to proof the validity of the assertion. The maximum validity timespan for a Policy Assertion MUST NOT be more than 4 hours.
|-
|colspan="4"|XACMLPolicyStatement
|R
|
|-
|
|colspan="3"|PolicySet
|R
|PolicySet that expresses the given authorization (see section below for details).
|-
|colspan="4"|ds:Signature
|R
|Enveloped XML signature of the issuer of the Policy Assertion (see section below for details).
|}

=== PolicySet Profile ===

The ECR 2.0 specification differentiates three kinds of an authorization statement as it is described logically in the security token services section for the [[cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)|Policy Provider]]. These are:
* Reference without semantics (policyId) to an access policy which contains the valid authorization rules for an eCR Consumer
* Reference with semantics (e.g., as per IHE BPPC)
* Access policy which contains the valid authorization rules for an eCR Consumer

In order to implement such differentiations the ''<PolicySet>'' element has different sub-elements.

==== Policy Assignment ====
{|class="wikitable" style="text-align: left; cellpadding: 10;"
!colspan="6"|PolicySet Element
!Opt
!Usage Convention
|-
|colspan="6"|@PolicySetId
|R
|URN encoded unique identifier (UUID) of the policy set.
|-
|colspan="6"|@PolicyCombiningAlgId
|R
|This attribute is REQUIRED. Its value is a predefined identifier of the policy-combining algorithm for this policy set (see Appendix C and section B.10 in [XACML2.0Core]). The ''urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:ordered-permit-overrides'' algorithm has been used. Other algorithms are not allowed.
|-
|colspan="6"|Target
|R
|This element is used to specify the resource match (i.e., [[cdaefa:EFA_Business_Informationsmodell#purpose|purpose]])
|-
|
|colspan="5"|Subjects
|R
|This element contains one ''xacml:Subject'' element.
|-
|
|
|colspan="4"|Subject
|R
|It contains one ''xacml:SubjectMatch'' element.
|-
|
|
|
|colspan="3"|SubjectMatch
|R
|It defines matches of the subject attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier must refer to the subject nameID format of the Identity Assertion. The following list defines the used identifier for this policy (see A.3.13 in [XACML2.0Core]):
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'' -> ''urn:oasis:names:tc:xacml:1.0:function:string-equal''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName'' -> ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name''
* ''urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'' -> ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name''
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the regular expression for matching.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is either ''http://www.w3.org/2001/XMLSchema#string'', ''urn:oasis:names:tc:xacml:1.0:data-type:x500Name'', or ''urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name'' that corresponds to the subject match.
|-
|
|
|
|
|colspan="2"|SubjectAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|It specifies the identifier of the attribute that is used for matching. The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:resource:resource-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|It specifies the type of the values that the resource attribute designator returns. The value of this attribute is set to ''http://www.w3.org/2001/XMLSchema#anyURI''.
|-
|
|colspan="5"|Resources
|R
|This element contains one ''xacml:Resource'' element.
|-
|
|
|colspan="4"|Resource
|R
|It contains one ''xacml:ResourceMatch'' element.
|-
|
|
|
|colspan="3"|ResourceMatch
|R
|It defines matches of the resource attributes.
|-
|
|
|
|
|colspan="2"|@MatchId
|R
|Its value specifies the matching function. The identifier ''urn:oasis:names:tc:xacml:1.0:function:anyURI-regexp-match'' is defined to use regular expressions (see A.3.13 in [XACML2.0Core]).
|-
|
|
|
|
|colspan="2"|AttributeValue
|R
|It defines the regular expression for matching.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|Its value is ''http://www.w3.org/2001/XMLSchema#string'' to indicate that the attribute value is of ''string'' simple type.
|-
|
|
|
|
|colspan="2"|ResourceAttributeDesignator
|R
|It defines the designator of a resource attribute.
|-
|
|
|
|
|
|colspan="1"|@AttributeId
|R
|It specifies the identifier of the attribute that is used for matching. The value of this attribute is set to ''urn:oasis:names:tc:xacml:1.0:resource:resource-id''.
|-
|
|
|
|
|
|colspan="1"|@DataType
|R
|It specifies the type of the values that the resource attribute designator returns. The value of this attribute is set to ''http://www.w3.org/2001/XMLSchema#anyURI''.
|-
|colspan="6"|PolicySetIdReference
|R
|Its value either references an assigned access policy that is expressed in a separate XACML ''PolicySet'' or already expresses the given authorization.
|-
|}

==== Policy Attachment ====
It is implementation-specific how the ''PolicySet'' with the authorization rules is defined - there are no restrictions made. However, there MUST NOT be used further ''PolicyIdReference'' or ''PolicySetIdReference'' elements.

== Assertion Signature ==
Every Policy Assertion MUST be signed by its issuer. The XML signature MUST be applied by using the ''saml:Assertion/ds:Signature'' element as defined below.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Signature Parameter
!Usage Convention
|-
|CanonicalizationMethod
|SHOULD be ''http://www.w3.org/2001/10/xml-exc-c14n#''
|-
|Transformation
|Enveloped signature transform acc. to section 6.6.4 of [W3C XMLDSig] SHOULD be used (''http://www.w3.org/2000/09/xmldsig#enveloped-signature''). In addition, exclusive canonicalization SHOULD be defined as transformation (''http://www.w3.org/2001/10/xml-exc-c14n#'', acc. [W3C XMLDSig] and [W3C XML-EXC 1.0]). As inclusive namespaces other prefixes than the ones defined in [[cdaefa:EFA Used Namespaces|''EFA Namespaces'']] MUST NOT be used.
|-
|SignatureMethod
|For signing assertions the signature method 
''http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'' or 
''http://www.w3.org/2000/09/xmldsig#rsa-sha1'' 
SHOULD be used. An assertion consumer MAY reject signatures that use SHA-1 for digesting.
|-
|DigestMethod
|For signing assertions the digest method 
''http://www.w3.org/2000/09/xmldsig#sha1'' or 
''http://www.w3.org/2001/04/xmlenc#sha256'' 
SHOULD be used. An assertion consumer MAY reject SHA-1 digests.
|-
|KeyInfo
|This element MUST either contain a wsse:SecurityTokenReference element which references the X.509 certificate of the assertion’s issuer by using a subject key identifier OR contain a ds:X509Data element which contains the X.509 certificate of the assertion issuer.
|}

== Example Assertion ==

<pre>
<soap12:Envelope … >
<soap12:Header … >
<wsse:Security … >
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="uuid-6dbb391c-20d3-4568-8c04-ff9d91d049c1"
IssueInstant="2013-04-05T08:14:28.788Z" Version="2.0">
<saml:Issuer>urn:de:berlin:hp:pap</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#urn:uuid:7102AC72154DCFD1F51253534608780">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="ds saml xs" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>A1LyLvFHRrYaOJ28YVFd3MfKGSI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ggyn … LQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
...
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> … </ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2013-04-05T08:14:28.788Z"
NotOnOrAfter="2013-04-05T12:14:28.788Z">
</saml:Conditions>
<xacml-saml:XACMLPolicyStatement>
<xacml:PolicySet>
...
</xacml:PolicySet>
</xacml-saml:XACMLPolicyStatement>
</saml:Assertion>
</wsse:Security>
</pre>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T07:19:22Z

Rkuhlisch:

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T06:20:56Z

Rkuhlisch:

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T06:18:35Z

Rkuhlisch:

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-05T06:03:50Z

Rkuhlisch:

cdaefa:EFA Used Namespaces

2013-04-05T05:27:54Z

Rkuhlisch: /* ECR Namespace Prefixes */

== ECR Namespace Prefixes ==

XML namespace prefixes are used in this specification to stand for their respective namespaces as follows:

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Prefix
!Namespace
|-
|ecr
|urn:efa:v2:2013
|-
|soapenv
|http://www.w3.org/2003/05/soap-envelope
|-
|wsse
|http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
|-
|saml
|urn:oasis:names:tc:SAML:2.0:assertion
|-
|xacml
|urn:oasis:names:tc:xacml:2.0:policy:schema:os
|-
|xacml-saml
|urn:oasis:names:tc:xacml:2.0:saml:assertion:schema:os
|-
|hl7v2
|urn:hl7-org:v2
|-
|hl7v3
|urn:hl7-org:v3
|-
|xds
|urn:ihe:iti:xds-b:2007
|-
|xs
|http://www.w3.org/2001/XMLSchema
|-
|xsi
|http://www.w3.org/2001/XMLSchema-instance
|-
|rimext
|urn:ihe:iti:xds-ebrim:extensions:2010
|-
|query
|urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0
|-
|rim
|urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0
|-
|rs
|urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0
|-
|lcm
|urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0
|}

cdaefa:EFA Policy Assertion SAML2 Binding

2013-04-04T07:57:10Z

Rkuhlisch: Die Seite wurde neu angelegt: „== SAML 2.0 Profile for ECR Access Policy Assertions == {{NoteBox|This profile applies to scenarios where the eCR Context Manager requests an Access Policy Asser…“

== SAML 2.0 Profile for ECR Access Policy Assertions ==

{{NoteBox|This profile applies to scenarios where the eCR Context Manager requests an Access Policy Assertion from the eCR Policy Provider and thus implements a policy push authorization model.}}

Datei:IM PIM Fallakte.png

2013-04-03T14:55:14Z

Rkuhlisch: hat eine neue Version von „Datei:IM PIM Fallakte.png“ hochgeladen

cdaefa:EFA Business Informationsmodell

2013-04-03T14:53:34Z

Rkuhlisch: /* PIM Data Structures */

{{Infobox Dokument
|Title = Informationsmodell der EFA Geschäftsobjekte
|Short = Informationsmodell der EFA Geschäftsobjekte
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

== PIM Data Structures ==
Die nachfolgend beschriebenen Objektklassen werden im Rahmen des EFA Service Functional Model verwendet und bilden die Datenstrukturen des EFA Platform Independent Model. Die folgende Abbildung zeigt das grobe Informationsmodell des EFA-Konstrukts.

[[Datei:IM_PIM_Fallakte.png|640px]]

=== patientID ===

Eindeutiger, beim EFA-Provider registrierter Identifizierer eines Patienten (siehe auch IHE Cookbook zum Thema "XAD-PID").

=== purpose ===

[[Datei:IM_PIM_Purpose.png|640px]]

=== ecrInfo ===

=== consentInfo ===

=== consentDoc ===

=== partitionID ===

=== ecrRef ===

[[Datei:IM_PIM_ecrRef.png|400px]]

=== partitionInfo ===

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

Datei:IM PIM Fallakte.png

2013-04-03T14:51:53Z

Rkuhlisch: hat eine neue Version von „Datei:IM PIM Fallakte.png“ hochgeladen

Datei:IM PIM Fallakte.png

2013-04-03T14:46:18Z

Rkuhlisch:

cdaefa:EFA Policy Provider SFM

2013-04-03T13:49:33Z

Rkuhlisch:

== Operationen des EFA Policy Provider ==

Der EFA Policy Provider ist für die Verwaltung der Berechtigungen in Form von Policies in einem Policy Repository zuständig. Berechtigungen sind an einen bestimmten [[cdaefa:EFA_Business_Informationsmodell#purpose|Zweck]] gebunden und steuern den Zugriff von EFA-Teilnehmern auf eine Fallakte. Die nachfolgende Tabelle listet die vom EFA Policy Provider bereit gestellten Operationen.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Operation
!Beschreibung
|-
|registerPolicy
|Registriert eine neue Access Policy auf Basis eines [[cdaefa:EFA_Einwilligungsdokument|Einwilligungsdokuments]].
|-
|activatePolicy
|Aktiviert eine Access Policy auf Grundlage verschiedener Attribute bzw. Kennzeichen (Zweck, Patient, Rolle, Kontext etc.). Eine aktivierte Access Policy autorisiert eine Rolle für einen bestimmten Verarbeitungskontext. Die ''activatePolicy''-Operation wird implizit von der ''requestPolicy''-Operation aufgerufen.
|-
|requestPolicy
|Für die Evaluierung einer Autorisierungsentscheidung muss ein Authorization Decision Provider Zugriff auf entsprechende Policies haben. Dazu fragt dieser Policies mit zwei verschiedenen Semantiken an:
* Verweis ohne Semantik (PolicyID) auf eine Policy, welche die gültigen Berechtigungsregeln eines EFA-Teilnehmers enthält
* Verweis mit Semantik (z.B. gemäß IHE BPPC). ''Hinweis'': Für eine Zugriffskontrolle kann der Authorization Decision Provider bereits implizit im Programmcode des jeweiligen Anwendungsdienstes implementiert sein, welcher den Verweis entsprechend interpretiert. In diesem Fall kann auf den Akteur EFA Policy Provider verzichtet werden. Lediglich für ein Policy-Push-Szenario muss der Verweis mit Semantik unterstützt werden (siehe unten).
* Attribute, die einen Verarbeitungskontext beschreiben
|}

Die EFA-Spezifikation macht keine normativen Vorgaben wie diese Operationen implementiert werden. Einzige Ausnahme ist der Fall, dass der EFA-Kontext-Manager die Access Policy anfordert und diese beim Zugriff auf eine Fallakte mitsendet (Policy Push). Damit wird schließlich dem Authorization Decision Provider die Access Policy für die Zugriffskontrolle übergeben. Die Operation ''requestPolicy'' hat die folgende formale Schnittstelle:

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Operation
! colspan="3"|requestPolicy
|-
|Funktionalität
| colspan="2"| Gibt eine Autorisierung zum Zugriff auf eine Fallakte wieder.
|-
|rowspan="4" | Eingabe
|patientID
|Eindeutige Identifizierung des Patienten für den eine Fallakte angelegt wurde.
|-
|HPIdentityAssertion
|Ein gültiger Authentifizierungsnachweis eines EFA-Teilnehmers für das EFA-Netzwerk.
|-
|purpose
|Zweck der Fallakte auf die zugegriffen werden soll.
|-
|consentInfo (optional)
|Informationen zu der vom Patienten gegebenen Einwilligung
|-
|Rückgabe
|Access Policy Assertion
|Autorisierungsnachweis, welcher entweder einen Verweis (mit oder ohne Semantik) auf eine Berechtigung oder eine explizite Access Policy enthält und somit die Autorisierung des aktuellen EFA-Teilnehmers bestätigt.
|-
|Vorbedingungen
| colspan="2"|
# Der EFA-Teilnehmer hat sich authentisiert und ein Nachweis liegt vor
# Policies und/oder Verweise wurden registriert
|-
|Ablaufsequenz
| colspan="2"|
# Überprüfe die Authentizität des Authentisierungsnachweises
# Aktiviere die Access Policy anhand der Eingabedaten
# Returniere die Access Policy an den Aufrufer
|-
|Mögliche Fehler
|MissingAttributes
|Autorisierung konnte nicht erfolgen, da Attribute für die Policy-Aktivierung nicht vorhanden waren.
|}

cdaefa:EFA Policy Provider SFM

2013-04-03T09:41:31Z

Rkuhlisch:

== Operationen des EFA Policy Provider ==

Der EFA Policy Provider ist für die Verwaltung der Berechtigungen in Form von Policies in einem Policy Repository zuständig. Berechtigungen sind an einen bestimmten [[cdaefa:EFA_Business_Informationsmodell#purpose|Zweck]] gebunden und steuern den Zugriff von EFA-Teilnehmern auf eine Fallakte. Die nachfolgende Tabelle listet die vom EFA Policy Provider bereit gestellten Operationen.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Operation
!Beschreibung
|-
|registerPolicy
|Registriert eine neue Access Policy auf Basis eines [[cdaefa:EFA_Einwilligungsdokument|Einwilligungsdokuments]].
|-
|activatePolicy
|Aktiviert eine Access Policy auf Grundlage verschiedener Attribute bzw. Kennzeichen (Zweck, Patient, Rolle, Kontext etc.). Eine aktivierte Access Policy autorisiert eine Rolle für einen bestimmten Verarbeitungskontext. Die ''activatePolicy''-Operation wird implizit von der ''requestPolicy''-Operation aufgerufen.
|-
|requestPolicy
|Für die Evaluierung einer Autorisierungsentscheidung muss ein Authorization Decision Provider Zugriff auf entsprechende Policies haben. Dazu fragt dieser Policies mit zwei verschiedenen Semantiken an:
* Verweis ohne Semantik (PolicyID) auf eine Policy, welche die gültigen Berechtigungsregeln eines EFA-Teilnehmers enthält
* Verweis mit Semantik (z.B. gemäß IHE BPPC). ''Hinweis'': Für eine Zugriffskontrolle kann der Authorization Decision Provider bereits implizit im Programmcode des jeweiligen Anwendungsdienstes implementiert sein, welcher den Verweis entsprechend interpretiert. In diesem Fall kann auf den Akteur EFA Policy Provider verzichtet werden. Lediglich für ein Policy-Push-Szenario muss der Verweis mit Semantik unterstützt werden (siehe unten).
* Attribute, die einen Verarbeitungskontext beschreiben
|}

Die EFA-Spezifikation macht keine normativen Vorgaben wie diese Operationen implementiert werden. Einzige Ausnahme ist der Fall, dass der EFA-Kontext-Manager die Access Policy anfordert und diese beim Zugriff auf eine Fallakte mitsendet (Policy Push). Damit wird schließlich dem Authorization Decision Provider die Access Policy für die Zugriffskontrolle übergeben. Die Operation ''requestPolicy'' hat die folgende formale Schnittstelle:

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Operation
! colspan="3"|requestPolicy
|-
|Funktionalität
| colspan="2"| Gibt eine Autorisierung zum Zugriff auf eine Fallakte wieder.
|-
|rowspan="4" | Eingabe
|patientID
|Eindeutige Identifizierung des Patienten für den eine Fallakte angelegt wurde.
|-
|HPIdentityAssertion
|Ein gültiger Authentifizierungsnachweis eines EFA-Teilnehmers für das EFA-Netzwerk.
|-
|purpose
|Zweck der Fallakte auf die zugegriffen werden soll.
|-
|consentInfo (optional)
|Informationen zu der vom Patienten gegebenen Einwilligung
|-
|Rückgabe
|Access Policy Assertion
|Autorisierungsnachweis, welcher entweder einen Verweis (mit oder ohne Semantik) auf eine Berechtigung oder eine explizite Access Policy enthält und somit die Autorisierung des aktuellen EFA-Teilnehmers bestätigt.
|-
|Vorbedingungen
| colspan="2"|
# Der EFA-Teilnehmer hat sich authentisiert und ein Nachweis liegt vor
# Policies und/oder Verweise wurden registriert
|-
|Ablaufsequenz
| colspan="2"|
# ...
|-
|Mögliche Fehler
|MissingAttributes
|Autorisierung konnte nicht erfolgen, da Attribute für die Policy-Aktivierung nicht vorhanden waren.
|}

cdaefa:EFA Policy Provider SFM

2013-04-03T09:14:05Z

Rkuhlisch:

== Operationen des EFA Policy Provider ==

Der EFA Policy Provider ist für die Verwaltung der Berechtigungen in Form von Policies in einem Policy Repository zuständig. Berechtigungen sind an einen bestimmten [[cdaefa:EFA_Business_Informationsmodell#purpose|Zweck]] gebunden und steuern den Zugriff von EFA-Teilnehmern auf eine Fallakte. Die nachfolgende Tabelle listet die vom EFA Policy Provider bereit gestellten Operationen.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Operation
!Beschreibung
|-
|registerPolicy
|Registriert eine neue Access Policy auf Basis eines [[cdaefa:EFA_Einwilligungsdokument|Einwilligungsdokuments]].
|-
|activatePolicy
|Aktiviert eine Access Policy auf Grundlage verschiedener Attribute bzw. Kennzeichen (Zweck, Patient, Rolle, Kontext etc.). Eine aktivierte Access Policy autorisiert eine Rolle für einen bestimmten Verarbeitungskontext. Die ''activatePolicy''-Operation wird implizit von der ''requestPolicy''-Operation aufgerufen.
|-
|requestPolicy
|Für die Evaluierung einer Autorisierungsentscheidung muss ein Authorization Decision Provider Zugriff auf entsprechende Policies haben. Dazu fragt dieser Policies mit zwei verschiedenen Semantiken an:
* Verweis ohne Semantik (PolicyID) auf eine Policy, welche die gültigen Berechtigungsregeln eines EFA-Teilnehmers enthält
* Verweis mit Semantik (z.B. gemäß IHE BPPC). ''Hinweis'': Für eine Zugriffskontrolle kann der Authorization Decision Provider bereits implizit im Programmcode des jeweiligen Anwendungsdienstes implementiert sein, welcher den Verweis entsprechend interpretiert. In diesem Fall kann auf den Akteur EFA Policy Provider verzichtet werden. Lediglich für ein Policy-Push-Szenario muss der Verweis mit Semantik unterstützt werden (siehe unten).
* Attribute, die einen Verarbeitungskontext beschreiben
|}

Die EFA-Spezifikation macht keine normativen Vorgaben wie diese Operationen implementiert werden. Einzige Ausnahme ist der Fall, dass der EFA-Kontext-Manager die Access Policy anfordert und diese beim Zugriff auf eine Fallakte mitsendet (Policy Push). Damit wird schließlich dem Authorization Decision Provider die Access Policy für die Zugriffskontrolle übergeben. Die Operation ''requestPolicy'' hat die folgende formale Schnittstelle:

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Operation
! colspan="3"|requestPolicy
|-
|Funktionalität
| colspan="2"| Gibt eine Autorisierung zum Zugriff auf eine Fallakte wieder.
|-
|Eingabe
|patientID
|...
|-
|Rückgabe
|Access Policy Assertion
|Autorisierungsnachweis, welcher entweder einen Verweis (mit oder ohne Semantik) auf eine Berechtigung oder eine explizite Access Policy enthält und somit die Autorisierung des aktuellen EFA-Teilnehmers bestätigt.
|-
|Vorbedingungen
| colspan="2"|
# ...
|-
|Ablaufsequenz
| colspan="2"|
# ...
|-
|Mögliche Fehler
|MissingAttributes
|Autorisierung konnte nicht erfolgen, da Attribute für die Policy-Aktivierung nicht vorhanden sind.
|}

cdaefa:EFA Policy Provider SFM

2013-04-03T08:03:50Z

Rkuhlisch: Die Seite wurde neu angelegt: „== Operationen des EFA Policy Provider == Der EFA Policy Provider ist für die Verwaltung der Berechtigungen in Form von Policies in einem Policy Repository zust…“

cdaefa:EFA Kommunikationsmuster

2013-04-03T07:34:43Z

Rkuhlisch: /* Aufbau des Sicherheitskontextes */

{{Infobox Dokument
|Title = EFA Kommunikationsmuster
|Short = EFA Kommunikationsmuster
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

== Akteure der EFA-Kommunikationsmuster ==

Die logische Anwendungsebene einer Fallakten-Infrastruktur besteht im einfachsten Fall aus fünf Klassen von Akteuren:
* Ein EFA-Kontext-Manager ('''eCR Context Manager''') baut den Sicherheitskontext zur Nutzung von Fallakten auf und verwaltet die darin bereit gestellten Sicherheitsnachweise des EFA-Teilnehmers.
* Ein EFA-Ressource-Manager('''eCR Resource Manager''') stellt ein Verzeichnis zur Verwaltung von Fallakten und EFA-Partitionen bereit. Mit dem selben Patienten und dem selben Zweck verbundene Partitionen bilden eine Fallakte.
* Ein EFA-Daten-Register ('''eCR Document Registry''') stellt ein Verzeichniss zur Verwaltung von 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.

Hinzu kommen zwei Klassen von Sicherheitstoken-Diensten, die jeweils Sicherheitsnachweise zum Aufbau eines zwischen EFA-Teilnehmersystem und EFA-Fachdienst (Register bzw. Speichersystem) geteilten Sicherheitskontextes bereit stellen:
* Ein '''Identity Provider''' stellt einen von allen anderen EFA-Akteuren als vertrauenswürdig akzeptierten Identitätsnachweis für authentifizierte Nutzer aus. Der Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z. B. mittels Passwort, HBA oder SMC-B).
* Ein '''Policy Provider''' liefert die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) auf einer spezifischen Fallakte.

Der Aufruf der Sicherheitstoken-Dienste und die Verwaltung der von diesen abgerufenen Sicherheitsnachweise wird gegenüber dem EFA-Teilnehmersystem über den EFA-Kontext-Manager gekapselt.

[[Datei:PIM_EFA_Dienste.png|480px]]

== Aufbau des Sicherheitskontextes ==

Die nachfolgende Abbildung stellt das Kommunikationsmuster zum Aufbau des Sicherheitskontextes im Überblick dar. Jeder nachfolgende Aufruf eines EFA-Dienstes erfordert, dass der im EFA-Kontext-Manager verwaltete Sicherheitskontext in Form von authentischen Sicherheitsnachweisen an den aufgerufenen Dienst übergeben wird. Dieser wird so in die Lage versetzt, den Sicherheitskontext des Aufrufers zu rekonstruieren und dadurch den Aufruf innerhalb dieses Kontextes gegen die geltenden Sicherheitsregeln zu verifizieren.

[[Datei:PIM_SEQ_Kontext_aufbauen.png|640px]]

# Der EFA-Teilnehmer authentisiert sich gegenüber dem EFA-Teilnehmersystem. Die EFA Spezifikation macht hierzu keine normativen technischen Vorgaben, Umsetzungen müssen jedoch die Regularien des EFA Sicherheitskonzepts berücksichtigen.
# Das EFA-Teilnehmersystem (TNS) erfasst die für die EFA-Nutzung wichtigen Informationen zum EFA-Teilnehmer und übermittelt sie an den EFA-Kontext-Manager. Hierzu wird die [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|funktionale Schnittstelle ''openContext'']] des [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Managers]] verwendet.
# Der [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Manager]] nutzt die übergebenen Informationen, um für den EFA-Teilnehmer von den EFA-Sicherheitsdiensten Sicherheitsnachweise abzurufen, die von den EFA-Fachdiensten prüfbar sind. Welche Dienste aufgerufen werden, hängt von der konkreten Sicherheitspolitik eines EFA-Netzwerks ab. Eine typische Konfiguration umfasst den Aufruf des ''Identity Providers'' zum Abruf eines netzweit gültigen Identitäts- und Authentisierungsnachweises. Optional können auch Teile der für den Teilnehmer geltenden Zugriffspolitik bereits vor dem Aufruf der EFA-Fachdienste von einem ''EFA Policy Provider'' abgefragt werden.
# Der [[cdaefa:EFA_Context_Manager_SFM|EFA-Kontext-Manager]] verknüpft die abgerufenen Sicherheitsnachweise mit der aktuellen Nutzersitzung und liefert einen Verweis auf den so gebildeten Sicherheitskontext an das EFA-Teilnehmersystem zurück.

== Anlegen einer Fallakte ==

Eine neue Fallakte wird angelegt, indem im EFA-Ressource-Manager eines EFA-Providers für den betroffenen Patienten eine neue Partition angelegt wird, die sowohl mit einem Zweck als auch einer Einwilligung verbunden ist:
* Gemäß der Vorgaben des Interaktionsmusters [[cdaefa:CIM_Anlegen_einer_Fallakte|''Anlegen einer Fallakte'']] erteilt der Patient eine informierte, schriftliche Einwilligung über die Nutzung einer Fallakte zur Unterstützung einer Behandlung. Die vom Patienten benannten Teilnehmer der Behandlung sind die zugriffsberechtigten Teilnehmer der Fallakte.
* Der Arzt baut über sein EFA-Teilnehmersystem den zur Anlage einer EFA erforderlichen Sicherheitskontext auf (siehe Kommunikationsmuster [[cdaefa:EFA_Kommunikationsmuster#Aufbau_des_Sicherheitskontextes|Aufbau des Sicherheitskontextes]]).
* Der Arzt fordert beim von seinem EFA-Provider bereit gestellten ''EFA-Ressource-Manager'' die Anlage einer neuen Fallakte an. Hierbei benennt der den Zweck der Akte sowie die als Teilnehmer zu berechtigenden Personen und Organisationen. Mit der Anlage einer Fallakte ist implizit die Anlage einer Partition verknüpft.

[[Datei:PIM_SEQ_EFA_Anlegen_var1.png|560px]]

* Der EFA-Provider prüft, ob für den Patienten bereits eine Fallakte existiert, die mit dem angegebenen Zweck assoziiert ist. Im Ergebnis dieser Prüfung müssen zwei Konstellationen unterschieden werden:
** Es besteht noch keine Fallakte für den benannten Patienten und den benannten Zweck: Eine neue, aus einer einzigen Partition bestehende Fallakte wird angelegt
** Es besteht bereits eine Fallakte für den benannten Patienten und den benannten Zweck: Im Ergebnis der angeforderten Anlage einer neuen EFA wird diese der bestehenden Fallakte als weitere Partition hinzugefügt. Der Teilnehmerkreis (und damit die Zugriffsrechte) werden wie in der neuen Einwilligung angegeben angepasst.

Die nachfolgenden Abschnitte definieren das Verhalten des EFA-Providers in diesen beiden Konstellationen.

=== Neu-Anlage einer Fallakte ===

* Im EFA-Berechtigungsmanagement des EFA-Providers wird eine neue Berechtigungsregel registriert, die den für die Aktenanlage angegebenen Zweck und die Patientenidentität mit den in der Patienteneinwilligung angegebenen Vorgaben zu den EFA-Teilnehmern und der Gültigkeit der Fallakte verknüpft.
** (Patient, Zweck) -> (Teilnehmer, Gültigkeit)
* Der EFA-Provider legt zu der Akte eine initiale Partition als Container-Objekt an, mit dem Dokumente verknüpft werden können.
* Sofern die Einwilligung des Patienten als (gescanntes) Dokument vorliegt, wird diese als Dokument in die neu angelegte Partition eingestellt.

=== Fusion mit einer bestehenden Fallakte ===

* Im EFA-Berechtigungsmanagement des EFA-Providers wird die Patienteneinwilligung (Berechtigungsregel) für die bestehende Fallakte darauf hin geprüft, ob
** der Arzt, der die neue Akte anlegen möchte, als Teilnehmer an der bereits zum selben Zweck bestehenden Akte registriert ist. Ist dieses der Fall, wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben. Ein bereits berechtigter EFA-Teilnehmer kann zu einer bestehenden Akte eine neue Partition hinzufügen oder eine neue/erweiterte Patienteneinwilligung registrieren. Eine gleichzeitige Ausführung beider Aktionen ist nicht möglich, da sich in diese Aktivität unterschiedliche Motivationen hinein interpretieren ließen, die jeweils zu einer unterschiedlichen Verarbeitung der übergebenen Berechtigungen führen würden.
** die zu der bestehenden Akte registrierte Einwilligung eine Erweiterung der Berechtigungen durch aktuell nicht registrierte Personen/Organisationen zulässt. Ist dies nicht der Fall, wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben. In diesem Szenario müsste ein bereits berechtigter Teilnehmer zunächst die neue Einwilligung des Patienten an der Akte registrieren. Anschließend könnte der so zum Aktenzugang berechtigte Arzt eine neue Partition an der Akte registrieren.
** die vom Patienten für die neue Akte gegebene Einwilligung die Fusion mit einer eventuell bereits bestehenden Akte autorisiert. Ist dies nicht der Fall, wird der Vorgang abgebrochen und eine Fehlermeldung ausgegeben. Um die bestehende Akte dennoch um eine weitere Partition erweitern zu können, muss eine entsprechend erweiterte Einwilligung des Patienten vorliegen.
* Die bestehende Akte wird um eine neue Partition erweitert.
* Die im EFA-Berechtigungsmanagement des EFA-Providers bereits registrierten Berechtigungsregeln werden um die in der neuen Einwilligungserklärung benannten Teilnehmer erweitert.
* Sofern die neue/erweiterte Einwilligung des Patienten als (gescanntes) Dokument vorliegt, wird diese als Dokument in die neu angelegte Partition eingestellt.

== Anlegen einer Partition zu einer bestehenden Fallakte ==

[[Datei:PIM_SEQ_Partition_Anlegen.png|400px]]

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Verwendete Standards

2013-04-02T14:11:51Z

Rkuhlisch:

== Security Assertion Markup Language (SAML) ==

Die Security Assertion Markup Language (SAML) spezifiziert einen Rahmen, in dem vertrauenswürdige Aussagen zu Identitäten dargestellt und ausgetauscht werden können. Die primären Anwendungsszenarien, in denen SAML eingesetzt wird, sind Single Sign-On sowie Identity Federation (Verknüpfung und Austausch von Identitätsinformationen über Organisationsgrenzen hinweg).

Den zentralen Bestandteil des Standards bilden die abstrakten Nachweise (Assertions) und Protokolle.<ref name="saml">S. Cantor et al. (2005), Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.</ref> Während die Assertions vertrauenswürdige Aussagen zur Authentifizierung und Autorisierung einer Identität sowie einer Identität zugeordnete Attribute kapseln, erlauben es die Protokolle, solche Assertions anzufragen und zu transportieren.

{| class="wikitable"
! colspan="2" | SAML Core
|-
| Organisation || OASIS
|-
| Version || 2.0 (März 2005)
|-
| rowspan="2" | Zweck || Abstrakte, XML-basierte Darstellung von vertrauenswürdigen Aussagen in Form von SAML Assertions
|-
| | Abstrakte Protokolle für den Transport der SAML Assertions
|}

Die SAML-Protokolle und deren Nachrichten werden in <ref name="saml" /> zunächst abstrakt spezifiziert. Wie die Protokolle an ein konkretes Nachrichten- oder Transportprotokoll, beispielsweise SOAP oder HTTP, gebunden werden, wird in <ref name="saml-bindings">S. Cantor et al. (2005), Bindings for the OASIS Security Assertion Markup Language (SAML)
V2.0.</ref> spezifiziert. Abhängig vom mit SAML umzusetzenden Anwendungsszenario können Assertions und Protokolle zusätzlich in Form einer Profilierung konkretisiert werden. Für typische Anwendungsszenarien gibt der SAML-Standard bereits Profilierungen in <ref name="saml-profiles">J. Hughes et al. (2005), Profiles for the OASIS Security Assertion Markup Language (SAML)
V2.0.</ref> vor. Diese umfassen u.a. Single Sign-On-Szenarien für Web Browser und für erweiterte Clients sowie Identity-Federation-Szenarien in verschiedenen Varianten.

Die EFA 2.0 Spezifikation verwendet SAML Assertions als [[cdaefa:EFA_Security_Objects_Bindings|Sicherheitstoken]], welche von speziellen [[cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)|Sicherheitstokendiensten]] ausgestellt werden. Die Assertions erlauben die Kodierung von Identitäts- und Authentifizierungsnachweisen.

Weitere Informationen zu diesem Standard sind im [[IHE_DE_Cookbook#Security_Assertion_Markup_Language_.28SAML.29|IHE Cookbook]] zu finden.

== eXtensible Access Control Markup Language (XACML) ==

XACML<ref name"xacml">T. Moses (2005), eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS.</ref> erlaubt die XML-basierte Beschreibung von Regeln für den Zugriff auf Ressourcen und spezifiziert Protokolle, mit denen Autorisierungsentscheidungen angefordert und ausgegeben werden können. Der Standard verfolgt einen generischen Ansatz, sodass mit XACML verschiedenartige Ansätze für Berechtigungssysteme (z.B. rollenbasierte Berechtigungen) realisiert werden können.

{| class="wikitable"
! colspan="2" | XACML
|-
| Organisation || OASIS
|-
| Version || 2.0 (Februar 2005)
|-
| rowspan="3" | Zweck || Autorisierung
|-
| | Beschreibung von Zugriffsregeln
|-
| | Protokoll zur Anforderung und Herausgabe von Autorisierungsentscheidungen
|}

Der Standard besteht in seinem Kern aus den Systembausteinen Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP) sowie Policy Administration Point (PAP). Diese Systembausteine werden durch weitere periphere Informationssysteme (z.B. Verzeichnisdienste) unterstützt. Weitere von OASIS herausgegebene Profile adressieren das Zusammenspiel mit anderen Standards (z.B. SAML) oder die Implementierung spezifischer Berechtigungsmodelle über die Konstrukte von XACML.

XACML spezifiziert – wie SAML auch – zunächst lediglich die Schemata für Protokollnachrichten. Der Transport dieser Nachrichten wird vom Standard nicht adressiert und ist Gegenstand einer Profilierung. In der EFA 2.0 Spezifikation wird XACML für die Kodierung von Autorisierungsnachweisen verwendet.

Weitere Informationen zu diesem Standard sind im [[IHE_DE_Cookbook#Extensible_Access_Control_Markup_Language_.28XACML.29|IHE Cookbook]] zu finden.

== Web Service Security (WS-Security) ==

WS-Security <ref name="ws-security">A. Nadalin et al. (2006), Web Service Security: SOAP Message Security 1.1. OASIS.</ref> erlaubt es, SOAP-Nachrichten auf der Nachrichtenebene zu signieren und zu verschlüsseln. Es bietet außerdem einen Rahmen, in dem verschiedene Sicherheitstoken übertragen werden können. Der Standard wird daher von weiteren Token-Profilen begleitet, die etwa die Nutzung von X.509-basierten Zertifikaten, SAML-Token oder Kerberos-Tickets als Sicherheitstoken spezifizieren.

{| class="wikitable"
! colspan="3" | WS-Security
|-
| Organisation || colspan="2" | OASIS
|-
| Version || colspan="2" | 1.1 (Februar 2006)
|-
| Zweck || colspan="2" | Nachrichtensicherheit auf Nachrichtenebene, Bereitstellung von Mechanismen für höhere
Sicherheitsprotokolle
|-
| rowspan="4" | Erweiterungen || rowspan="4" | Tokenprofile: || Username Token Profile 1.1
|-
| | X.509 Token Profile 1.1
|-
| | SAML Token Profile 1.1
|-
| | Kerberos Token Profile 1.1
|}

Im Rahmen der EFA-Sicherheitsarchitektur wird WS-Security genutzt, um Sicherheitstoken zwischen EFA-Teilnehmersystem und EFA-Anwendung- und Sicherheitsdiensten auszutauschen.

== Web Services Trust Language (WS-Trust) ==

WS-Trust <ref name="ws-trust">A. Nadalin et al. (2007), WS-Trust 1.3. OASIS.</ref> erweitert WS-Security um ein nachrichtenbasiertes Protokoll, das das Anfragen und Ausstellen von Sicherheitstoken sowie die Delegation von Vertrauensbeziehungen erlaubt. WS-Trust führt dazu ein aus drei Rollen bestehendes Modell ein, in dem ein Webservice-Nutzer bei einem Sicherheitstokendienst ein Sicherheitstoken anfragt, welches dieser anschließend bei einem Webservice-Anbieter einlösen kann. Die vom Webservice-Nutzer so vorgelegten Behauptungen zur Nutzeridentität sind durch die Vertrauensbeziehung zwischen Webservice-Anbieter und Sicherheitstokendienst mithilfe von kryptographischen Methoden verifizierbar.

WS-Trust ist funktional dem SAML 2.0 Protokoll sehr ähnlich, wobei SAML eher in browserbasierten Lösungen zum Einsatz kommt, während WS-Trust vorwiegend in Fat-Client-Umgebungen genutzt wird, bei denen auch über eine rein textbasierte HTTP-Kommunikation hinausgehende Protokolle wie z.B. SOAP zur Kommunikation zwischen Systemkomponenten genutzt werden. Hersteller von Identitäts- und Berechtigungsmanagement-Lösungen unterstützen üblicherweise beide Protokolle.

{| class="wikitable"
! colspan="2" | WS-Trust
|-
| Organisation || OASIS
|-
| Version || 1.3 (März 2007)
|-
| Zweck || Anfragen und Ausstellen von Sicherheitstoken (z. B. SAML Assertions), Konzept des direkt vermittelten Vertrauens
|}

Der EFA Identity Provider ist ein WS-Trust 1.3 Sicherheitstokendienst. Er erlaubt einen Abruf von EFA Identity
Assertions über das WS-Trust-Protokoll. Weitere Informationen im [[IHE_DE_Cookbook#Zentrale_Ausstellung_der_Assertion|IHE Cookbook]].

= Referenzen =
<references/>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Verwendete Standards

2013-04-02T14:10:52Z

Rkuhlisch:

== Security Assertion Markup Language (SAML) ==

Die Security Assertion Markup Language (SAML) spezifiziert einen Rahmen, in dem vertrauenswürdige Aussagen zu Identitäten dargestellt und ausgetauscht werden können. Die primären Anwendungsszenarien, in denen SAML eingesetzt wird, sind Single Sign-On sowie Identity Federation (Verknüpfung und Austausch von Identitätsinformationen über Organisationsgrenzen hinweg).

Den zentralen Bestandteil des Standards bilden die abstrakten Nachweise (Assertions) und Protokolle.<ref name="saml">S. Cantor et al. (2005), Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.</ref> Während die Assertions vertrauenswürdige Aussagen zur Authentifizierung und Autorisierung einer Identität sowie einer Identität zugeordnete Attribute kapseln, erlauben es die Protokolle, solche Assertions anzufragen und zu transportieren.

{| class="wikitable"
! colspan="2" | SAML Core
|-
| Organisation || OASIS
|-
| Version || 2.0 (März 2005)
|-
| rowspan="2" | Zweck || Abstrakte, XML-basierte Darstellung von vertrauenswürdigen Aussagen in Form von SAML Assertions
|-
| | Abstrakte Protokolle für den Transport der SAML Assertions
|}

Die SAML-Protokolle und deren Nachrichten werden in <ref name="saml" /> zunächst abstrakt spezifiziert. Wie die Protokolle an ein konkretes Nachrichten- oder Transportprotokoll, beispielsweise SOAP oder HTTP, gebunden werden, wird in <ref name="saml-bindings">S. Cantor et al. (2005), Bindings for the OASIS Security Assertion Markup Language (SAML)
V2.0.</ref> spezifiziert. Abhängig vom mit SAML umzusetzenden Anwendungsszenario können Assertions und Protokolle zusätzlich in Form einer Profilierung konkretisiert werden. Für typische Anwendungsszenarien gibt der SAML-Standard bereits Profilierungen in <ref name="saml-profiles">J. Hughes et al. (2005), Profiles for the OASIS Security Assertion Markup Language (SAML)
V2.0.</ref> vor. Diese umfassen u.a. Single Sign-On-Szenarien für Web Browser und für erweiterte Clients sowie Identity-Federation-Szenarien in verschiedenen Varianten.

Die EFA 2.0 Spezifikation verwendet SAML Assertions als [[cdaefa:EFA_Security_Objects_Bindings|Sicherheitstoken]], welche von speziellen [[cdaefa:EFA_Sicherheitsdienste_(logische_Spezifikation)|Sicherheitstokendiensten]] ausgestellt werden. Die Assertions erlauben die Kodierung von Identitäts- und Authentifizierungsnachweisen.

Weitere Informationen zu diesem Standard sind im [[IHE_DE_Cookbook#Security_Assertion_Markup_Language_.28SAML.29|IHE Cookbook]] zu finden.

== eXtensible Access Control Markup Language (XACML) ==

XACML<ref name"xacml">T. Moses (2005), eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS.</ref> erlaubt die XML-basierte Beschreibung von Regeln für den Zugriff auf Ressourcen und spezifiziert Protokolle, mit denen Autorisierungsentscheidungen angefordert und ausgegeben werden können. Der Standard verfolgt einen generischen Ansatz, sodass mit XACML verschiedenartige Ansätze für Berechtigungssysteme (z.B. rollenbasierte Berechtigungen) realisiert werden können.

{| class="wikitable"
! colspan="2" | XACML
|-
| Organisation || OASIS
|-
| Version || 2.0 (Februar 2005)
|-
| rowspan="3" | Zweck || Autorisierung
|-
| | Beschreibung von Zugriffsregeln
|-
| | Protokoll zur Anforderung und Herausgabe von Autorisierungsentscheidungen
|}

Der Standard besteht in seinem Kern aus den Systembausteinen Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP) sowie Policy Administration Point (PAP). Diese Systembausteine werden durch weitere periphere Informationssysteme (z.B. Verzeichnisdienste) unterstützt. Weitere von OASIS herausgegebene Profile adressieren das Zusammenspiel mit anderen Standards (z.B. SAML) oder die Implementierung spezifischer Berechtigungsmodelle über die Konstrukte von XACML.

XACML spezifiziert – wie SAML auch – zunächst lediglich die Schemata für Protokollnachrichten. Der Transport dieser Nachrichten wird vom Standard nicht adressiert und ist Gegenstand einer Profilierung. In der EFA 2.0 Spezifikation wird XACML für die Kodierung von Autorisierungsnachweisen verwendet.

Weitere Informationen zu diesem Standard sind im [[IHE_DE_Cookbook#Extensible_Access_Control_Markup_Language_.28XACML.29|IHE Cookbook]] zu finden.

== Web Service Security (WS-Security) ==

WS-Security <ref name="ws-security">A. Nadalin et al. (2006), Web Service Security: SOAP Message Security 1.1. OASIS.</ref> erlaubt es, SOAP-Nachrichten auf der Nachrichtenebene zu signieren und zu verschlüsseln. Es bietet außerdem einen Rahmen, in dem verschiedene Sicherheitstoken übertragen werden können. Der Standard wird daher von weiteren Token-Profilen begleitet, die etwa die Nutzung von X.509-basierten Zertifikaten, SAML-Token oder Kerberos-Tickets als Sicherheitstoken spezifizieren.

{| class="wikitable"
! colspan="3" | WS-Security
|-
| Organisation || colspan="2" | OASIS
|-
| Version || colspan="2" | 1.1 (Februar 2006)
|-
| Zweck || colspan="2" | Nachrichtensicherheit auf Nachrichtenebene, Bereitstellung von Mechanismen für höhere
Sicherheitsprotokolle
|-
| rowspan="4" | Erweiterungen || rowspan="4" | Tokenprofile: || Username Token Profile 1.1
|-
| | X.509 Token Profile 1.1
|-
| | SAML Token Profile 1.1
|-
| | Kerberos Token Profile 1.1
|}

Im Rahmen der EFA-Sicherheitsarchitektur wird WS-Security genutzt, um Sicherheitstoken zwischen EFA-Teilnehmersystem und EFA-Anwendung- und Sicherheitsdiensten auszutauschen.

== Web Services Trust Language (WS-Trust) ==

WS-Trust <ref name="ws-trust">A. Nadalin et al. (2007), WS-Trust 1.3. OASIS.</ref> erweitert WS-Security um ein nachrichtenbasiertes Protokoll, das das Anfragen und Ausstellen von Sicherheitstoken sowie die Delegation von Vertrauensbeziehungen erlaubt. WS-Trust führt dazu ein aus drei Rollen bestehendes Modell ein, in dem ein Webservice-Nutzer bei einem Sicherheitstokendienst ein Sicherheitstoken anfragt, welches dieser anschließend bei einem Webservice-Anbieter einlösen kann. Die vom Webservice-Nutzer so vorgelegten Behauptungen zur Nutzeridentität sind durch die Vertrauensbeziehung zwischen Webservice-Anbieter und Sicherheitstokendienst mithilfe von kryptographischen Methoden verifizierbar.

WS-Trust ist funktional dem SAML 2.0 Protokoll sehr ähnlich, wobei SAML eher in browserbasierten Lösungen zum Einsatz kommt, während WS-Trust vorwiegend in Fat-Client-Umgebungen genutzt wird, bei denen auch über eine rein textbasierte HTTP-Kommunikation hinausgehende Protokolle wie z.B. SOAP zur Kommunikation zwischen Systemkomponenten genutzt werden. Hersteller von Identitäts- und Berechtigungsmanagement-Lösungen unterstützen üblicherweise beide Protokolle.

{| class="wikitable"
! colspan="2" | WS-Trust
|-
| Organisation || OASIS
|-
| Version || 1.3 (März 2007)
|-
| Zweck || Anfragen und Ausstellen von Sicherheitstoken (z. B. SAML Assertions), Konzept des direkt vermittelten Vertrauens
|}

Der EFA Identity Provider ist ein WS-Trust 1.3 Sicherheitstokendienst. Er erlaubt einen Abruf von EFA Identity
Assertions über das WS-Trust-Protokoll. Weitere Informationen im [[IHE_DE_Cookbook#Zentrale_Ausstellung_der_Assertion|IHE Cookbook]].

== Web Services Security Policy Language (WS-SecurityPolicy) ==

= Referenzen =
<references/>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

cdaefa:EFA Sicherheitsdienste (logische Spezifikation)

2013-04-02T13:31:41Z

Rkuhlisch: /* EFA Sicherheits(token)dienste */

{{Infobox Dokument
|Title = EFA Sicherheitsdienste (logische Spezifikation)
|Short = EFA Sicherheitsdienste (logische Spezifikation)
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

= Sicherheitstoken und Sicherheitstokendienste =
Jeder EFA-Anwendungsdienst und jeder EFA-Sicherheitsdienst besitzt eine Sicherheitspolitik, in der u. a. definiert ist, wie der Sicherheitskontext aussehen muss, aus dem heraus der Dienst aufgerufen werden kann. Hierdurch „weiß“ ein EFA-Client, welches Sicherheitstoken er von welchem GDD-Sicherheitsdienst abrufen und in den Ablaufkontext laden muss, bevor der gewünschte Dienst aufgerufen werden kann. Dadurch dass auch Sicherheitsdienste Sicherheitspolitiken besitzen, lässt sich die komplette Ablaufsteuerung über den Sicherheitsdiensten deklarativ abbilden. Beispielsweise kann ein EFA-Anwendungsdienst für den Zugriff auf eine Ressource ein Sicherheitstoken verlangen, über das die entsprechende Berechtigung des Nutzers verifizierbar ist. Der dieses Token ausstellende Autorisierungsdienst wiederum kann eine Politik definieren, dass Berechtigungsnachweise nur ausgestellt werden, wenn der Nutzer über ein entsprechendes Token seine Authentizität nachweist, d.h. vor dem Autorisierungsdienst ein Authentifizierungsdienst aufgerufen wurde.

Im Rahmen des ''IHE Cookbook'' und der EFA-2.0 Spezifikation werden verschiedene Sicherheitstokendienste (föderierte Authentifizierung, Pseudonymisierung, Zugang zu Anwendungen, Autorisierung auf Ressourcen) spezifiziert, die nach dem oben skizzierten Prinzip von allen Aktendiensten genutzt werden können. Welche Sicherheitsdienste ein Aktendienst in Anspruch nimmt, definiert er über seine Sicherheitspolitk, die im Fachmodul in Aufrufe an die Sicherheitstokendienste übersetzt wird.

= EFA Sicherheits(token)dienste =

[[Datei:Sicherheitsdienste_5_Domains.png|480px]]

;EFA Identity Provider
:Der EFA Identity Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Teilnehmersystem aufgerufen und stellt einen Identitätsnachweis für authentifizierte Nutzer aus. Dieser Nachweis enthält neben einem ''Proof-of-Possession'' Merkmal auch Angaben zu Rollen und Gruppenzugehörigkeiten des Nutzers. Der EFA Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z.B. mittels Passwort, HBA oder SMC-B). Bei einer Authentifizierung mittels HBA werden die Nutzerattribute aus dem HBA-Zertifikat in den Identitätsnachweis übernommen. Zusätzlich wird anhand der genutzten SMC-B die Organisationszugehörigkeit eingetragen. Bei der Authentifizierung mittels SMC-B hat sich der Nutzer bereits innerhalb seiner Organisation sicher authentisiert. Auch alle Attribute wurden bereits durch die Organisation zugewiesen. Beim Aufruf des EFA Identity Providers bestätigt die Organisation die durchgeführte Authentifizierung und die Authentizität der Attribute in Form eines selbst ausgestellten, von der SMC-B signierten Identitätsnachweises (Guarantor Assertion). Dieser Nachweis wird vom EFA Identity Provider geprüft und in einen für EFA-Anwendungs- und EFA-Sicherheitsdienste nutzbaren Authentifizierungsnachweis überführt.
;EFA Policy Provider
:Der EFA Policy Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Client oder einem EFA-Anwendungsdienst aufgerufen und liefert einen Verweis auf die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) zu einer Anwendungsinstanz (z. B. einer spezifischen eFA) oder die zum Verweis gehörende Policy. Diese Verweise sind transparent, d. h. sie können sowohl selber bereits eine Semantik tragen (z. B. gemäß IHE BPPC) oder eine Policy-Datei referenzieren. Um auch ein "Policy Pull" zu erlauben (siehe [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf IHE White Paper on Access Control]), wird auch ein Aufruf des Policy Provider durch einen EFA-Anwendungsdienst unterstützt.

{| class="wikitable"
!Dienst || Aufgaben || Datenhaltung
|-
| EFA Identity Provider
|| Authentifiziert einen EFA-Teilnehmer durch Verifikation seiner Credentials. Der Dienst bietet verschiedene Authentifizierungsmethoden an:
* Direktes Vertrauen: Authentifiziert einen EFA-Teilnehmer per X.509 Zertifikat oder Benutzername/Passwort-Kombination
* Vermitteltes Vertrauen: Authentifiziert einen EFA-Teilnehmer durch Verifikation einer übermittelten signierten Guarantor Assertion (lokaler Identitätsnachweis eines EFA-Teilnehmers aus einer Organisation).
|| Weitere Attribute können über einen mit dem EFA Identity Provider gruppierten Verzeichnisdienst abgerufen werden. Der Dienst enthält einen Identity Store, wo die verwalteten Identitäten sowie die Credentials für die Authentifizierung gespeichert sind.
|-
| EFA Policy Provider
|| Gibt eine Policy zu einem bestimmten (Behandlungs-)Zweck heraus. Je nach Autorisierungsmodell ("Policy Push"/"Policy Pull") kann eine explizite Access Control Policy oder ein Verweis (mit impliziter Semantik) die Autorisierung eines Benutzers (oder seiner Rolle) zu einer Fallakte bzw. dem festgelegten Zweck beschreiben.
|| Policies, welche jeweils den konsentierten Kreis der Behandelnden zu einem Zweck definieren.
|}

=== Spezifikation ===
* Normative Spezifikation: [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider Service Functional Model]], [[cdaefa:EFA_Policy_Provider_SFM|EFA Policy Provider SFM]]
* Binding: [[cdaefa:EFA Identity Provider WS Trust Binding|EFA Identity Provider WS Trust Binding]], [[cdaefa:EFA Policy Provider SAML-XACML Binding|EFA Policy Provider SAML-XACML Binding]]

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

Datei:EFA-Grouping.jpg

2013-04-02T12:44:22Z

Rkuhlisch: hat eine neue Version von „Datei:EFA-Grouping.jpg“ hochgeladen

cdaefa:EFA Spezifikation v2.0

2013-04-02T09:58:32Z

Rkuhlisch: /* EFA 2.0 Spezifikation */

{{DocumentPart}}

== Einleitung ==

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - eine Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einen Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt an festen Orten gespeichert. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der EFA Version 1.2 das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität der EFA-Abläufe zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt ist und die übergeordneten EFA-Konzepte (Fallakte, Ordner) nicht abdeckt.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der ambulanten und stationären Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und
* durch Verzahnung mit dem "IHE Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar.

<table border="1" cellspacing="0" cellpadding="0" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]
* [[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]
* [[cdaefa:EFA Provider|EFA Provider]]
* [[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]
* [[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]
* [[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]
* Patienteneinwilligung zur EFA
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
** [[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
** [[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
** [[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
** [[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
** [[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
** [[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
** [[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
** [[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
** [[cdaefa:CIM Anpassen des Teilnehmerkreises|Anpassen des Teilnehmerkreises]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
* Sicherheitszonen
</td>
<td width="30%" valign="top" align="left">
* EFA Geschäftsobjekte
** [[cdaefa:EFA Business Informationsmodell|Informationsmodell]]
** [[cdaefa:EFA Business Lebenszyklus|Lebenszyklus]]
* EFA Sicherheitsobjekte
** Informationsmodelle
* [[cdaefa:EFA Einwilligungsdokument|EFA Einwilligungsdokument]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]
* [[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]
** EFA Resource Manager
** EFA Document Registry
** EFA Document Repository
* [[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
** [[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
** [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
** [[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]
* [[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Verwendete Standards|Verwendete Standards]]
* [[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
** [[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
** [[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]
* [[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
** [[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
** [[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]
* [[cdaefa:EFA XUA Binding|EFA XUA Binding]]
* [[cdaefa:EFA Access Control System|EFA Access Control System]]
* [[cdaefa:EFA XDS/XDR Bindings|EFA XDS/XDR Bindings]]
** [[cdaefa:EFA XDR SetupCaseRecord|EFA XDR Binding: SetupCaseRecord]]
** [[cdaefa:EFA XDS ListPartitions|EFA XDS Binding: ListPartitions]]
** [[cdaefa:EFA XDS ListRecordContent|EFA XDR Binding: ListRecordContent]]
** [[cdaefa:EFA XDS ListPartitionContent|EFA XDR Binding: ListPartitionContent]]
** [[cdaefa:EFA XDS RetrieveDocument|EFA XDR Binding: RetrieveDocument]]
** [[cdaefa:EFA XDR ProvideAndRegisterDocument|EFA XDR Binding: ProvideAndRegisterDocument]]

</td>
</tr>
</table>

== Offene Punkte und ToDos ==

=== OIDs und Codesysteme ===

* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]

* Ein Codesystem für die Klassifizierung von Fachbereichszugehörigkeiten eines Leistungserbringers muss festgelegt werden. Hier gibt es diverse KBV Schlüsseltabellen, die auf ihre Eignung zu prüfen sind. Diese Klassifizierung wird in folgenden Spezifikationsteilen benötigt:
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten

2013-03-27T15:09:35Z

Rkuhlisch:

Die EFA Anwendungs- und Sicherheitsarchitektur ist über eine spezielle Gruppierung von Akteuren miteinander verzahnt. Die nachfolgende Grafik stellt die Beziehungen im Überblick dar.

[[Datei:EFA-Grouping.jpg|700px]]

Aus der Grafik sind die folgenden Gruppierungen ersichtlich:
{| class="wikitable"
! Anwendungsdienst bzw. Akteur || Sicherheitsdienst bzw. Akteur || Beschreibung
|-
| EFA-Teilnehmersystem || HP Identity Assertion User || Das EFA-Teilnehmersystem bzw. der Arzt authentisiert sich bei einem konfigurierten EFA Identity Provider, welcher eine HP Identity Assertion als Authentifizierungsnachweis ausstellt.
|-
| rowspan="3" | EFA-Register || HP Identity Assertion Consumer || Die HP Identity Assertion ist für die Nutzung des EFA-Registers notwendig. Die Inhalte des Nachweises werden für eine Zugriffskontrollprüfung durch den Authorization Requestor Akteur verwendet.
|-
| | Authorization Requestor || Der Authorization Requestor Akteur stellt eine Autorisierungsanfrage an den Authorization Decision Provider.
|-
| | Authorization Decision Provider || Der Authorization Decision Provider Akteur wird mit dem EFA-Register gruppiert, da keine standardisierte Schnittstelle vorgesehen ist, über die effizient alle für die Zugriffsentscheidung notwendigen Dokumentenmetadaten transportiert werden können.
|-
| rowspan="2" | EFA-Speichersystem || HP Identity Assertion Consumer || Die HP Identity Assertion ist für die Nutzung des EFA-Speichersystems notwendig.
|-
| | Authorization Requestor || Für eine Zugriffsentscheidung zur Herausgabe eines Dokuments wird über den Authorization Requestor Akteur eine Autorisierungsanfrage an den Authorization Decision Provider Akteur des EFA-Registers gestellt.
|}

Datei:EFA-Grouping.jpg

2013-03-27T15:07:35Z

Rkuhlisch: hat eine neue Version von „Datei:EFA-Grouping.jpg“ hochgeladen

cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten

2013-03-27T14:38:35Z

Rkuhlisch:

Die EFA Anwendungs- und Sicherheitsarchitektur ist über eine spezielle Gruppierung von Akteuren miteinander verzahnt. Die nachfolgende Grafik stellt die Beziehungen im Überblick dar.

[[Datei:EFA-Grouping.jpg|700px]]

Aus der Grafik sind die folgenden Gruppierungen ersichtlich:
{| class="wikitable"
! Anwendungsdienst bzw. Akteur || Sicherheitsdienst bzw. Akteur || Beschreibung
|-
| EFA-Client || HP Identity Assertion User || Der EFA-Client Akteur authentisiert sich bei einem konfigurierten EFA Identity Provider, welcher eine HP Identity Assertion als Authentifizierungsnachweis ausstellt.
|-
| rowspan="3" | EFA-Register || HP Identity Assertion Consumer || Die HP Identity Assertion ist für die Nutzung des EFA-Registers notwendig. Die Inhalte des Nachweises werden für eine Zugriffskontrollprüfung durch den Authorization Requestor Akteur verwendet.
|-
| | Authorization Requestor || Der Authorization Requestor Akteur stellt eine Autorisierungsanfrage an den Authorization Decision Provider.
|-
| | Authorization Decision Provider || Der Authorization Decision Provider Akteur wird mit dem EFA-Register gruppiert, da keine standardisierte Schnittstelle vorgesehen ist, über die effizient alle für die Zugriffsentscheidung notwendigen Dokumentenmetadaten transportiert werden können.
|-
| rowspan="2" | EFA-Speichersystem || HP Identity Assertion Consumer || Die HP Identity Assertion ist für die Nutzung des EFA-Speichersystems notwendig.
|-
| | Authorization Requestor || Für eine Zugriffsentscheidung zur Herausgabe eines Dokuments wird über den Authorization Requestor Akteur eine Autorisierungsanfrage an den Authorization Decision Provider Akteur des EFA-Registers gestellt.
|}

Datei:EFA-Grouping.jpg

2013-03-27T14:36:38Z

Rkuhlisch:

cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten

2013-03-27T13:44:46Z

Rkuhlisch:

Die EFA Anwendungs- und Sicherheitsarchitektur ist über eine spezielle Gruppierung von Akteuren miteinander verzahnt. Die nachfolgende Grafik stellt die Beziehungen im Überblick dar.

[[Datei:EFA_access_control_grouping.png|720px]]

Aus der Grafik sind die folgenden Gruppierungen ersichtlich:
{| class="wikitable"
! Anwendungsdienst bzw. Akteur || Sicherheitsdienst bzw. Akteur || Beschreibung
|-
| EFA-Client || HP Identity Assertion User || Der EFA-Client Akteur authentisiert sich bei einem konfigurierten EFA Identity Provider, welcher eine HP Identity Assertion als Authentifizierungsnachweis ausstellt.
|-
| rowspan="3" | EFA-Register || HP Identity Assertion Consumer || Die HP Identity Assertion ist für die Nutzung des EFA-Registers notwendig. Die Inhalte des Nachweises werden für eine Zugriffskontrollprüfung durch den Authorization Requestor Akteur verwendet.
|-
| | Authorization Requestor || Der Authorization Requestor Akteur stellt eine Autorisierungsanfrage an den Authorization Decision Provider.
|-
| | Authorization Decision Provider || Der Authorization Decision Provider Akteur wird mit dem EFA-Register gruppiert, da keine standardisierte Schnittstelle vorgesehen ist, über die effizient alle für die Zugriffsentscheidung notwendigen Dokumentenmetadaten transportiert werden können.
|-
| rowspan="2" | EFA-Speichersystem || HP Identity Assertion Consumer || Die HP Identity Assertion ist für die Nutzung des EFA-Speichersystems notwendig.
|-
| | Authorization Requestor || Für eine Zugriffsentscheidung zur Herausgabe eines Dokuments wird über den Authorization Requestor Akteur eine Autorisierungsanfrage an den Authorization Decision Provider Akteur des EFA-Registers gestellt.
|}

cdaefa:EFA Identity Provider SFM

2013-03-26T13:45:53Z

Rkuhlisch: Die Seite wurde neu angelegt: „Die Authentisierung ist der initiale Schritt eines Clients (EFA-Teilnehmer), um einen EFA Sicherheitskontext zwischen Client un…“

Die Authentisierung ist der initiale Schritt eines Clients (EFA-Teilnehmer), um einen [[cdaefa:EFA_Context_Manager_SFM|EFA Sicherheitskontext]] zwischen Client und EFA-Provider aufzubauen. Ein Client, der sich gegenüber einen EFA Identity Provider (über die [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|OpenContext-Operation]]) authentisiert, muss dazu Credentials für seine behauptete Identität vorlegen, welche serverseitig überprüft werden.

== Service Functional Model ==

Der EFA Identity Provider bietet als Schnittstelle zum Client nur eine Operation zur Authentifizierung an. Da der EFA Identity Provider ist als Sicherheitstokendienst deployt ist, erstellt er bei positiver Authentifizierung einen Nachweis als Sicherheitstoken, nämlich die HP Identity Assertion. Die EFA 2.0 Spezifikation macht keine spezifischen Vorgaben, wie das Protokoll ausgestaltet ist. Als Vorgabe gilt hingegen das IHE-Profil [[IHE_DE_Cookbook#Cross-Enterprise_User_Assertion_.28XUA.29|Cross-Enterprise User Assertion (XUA)]], welches ein Binding auf das SAML- oder WS-Tust-Protokoll spezifiziert (siehe [[cdaefa:EFA_XUA_Binding| EFA XUA Binding]]). Der Authentifizierungsnachweis kann weitere Attribute eines EFA-Teilnehmers aus einem [[IHE_DE_Cookbook#Healthcare_Provider_Directory_.28HPD.29|Healthcare Provider Directory (HPD)]] enthalten, welche später für eine Zugriffskontrolle genutzt werden.

{|class="wikitable" style="text-align: left; cellpadding: 10;"
!Method
! colspan="2"|requestHPIdentityAssertion()(credential Object) : 
HPIdentityAssertion 
fault AuthenticationFailedException
|-
|Description
| colspan="2"|This method authenticates a user by means of an EFA Identity Provider. If necessary the EFA Identity Provider calls more user attributes from a HPD. A credential MUST be passed.
|-
|Input Parameters
|credential
|Object which MAY be a username/password combination, a subject identifier, a health card handle, or a SAML assertion that guarantees for an authentication.
|-
|Return Value
|HP Identity Assertion
|The assertion confirms the successful authentication.
|-
|Preconditions
| colspan="2"|
# Credentials (i.e., username/password) are present.
# The user is already registered in the identity store of the EFA Identity Provider (i.e., the identity is established).
|-
|Sequence (Main success scenario)
| colspan="2"|
# The EFA Identity Provider detects whether a username password combination [WSSUsername], SAML assertion (i.e, a locally issued Guarantor Assertion), or a X.509 certificate is passed.
# Depending on the given credentials, the EFA Identity Provider authenticates the user using the identity store.
# If the authentication was successful, the Identity Assertion is issued. Otherwise an exception is thrown.
|-
|Exception
|AuthenticationFailedException
|Authentication failed due to wrong credentials.
|}

cdaefa:EFA Spezifikation v2.0

2013-03-26T13:25:52Z

Rkuhlisch: /* EFA 2.0 Spezifikation */

{{DocumentPart}}

== Einleitung ==

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - eine Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einen Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt an festen Orten gespeichert. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichtert somit die Zusammenarbeit auf regionaler Ebene.

== Von EFA 1.2 zu EFA 2.0 ==
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der EFA Version 1.2 das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität der EFA-Abläufe zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt ist und die übergeordneten EFA-Konzepte (Fallakte, Ordner) nicht abdeckt.

Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der ambulanten und stationären Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und
* durch Verzahnung mit dem "IHE Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== EFA 2.0 Spezifikation ==

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des [[HL7 Enterprise Conformance and Compliance Frameworks]] dar.

<table border="1" cellspacing="0" cellpadding="0" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top">EFA v2.0</td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]
* [[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]
* [[cdaefa:EFA Provider|EFA Provider]]
* [[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]
* [[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]
* [[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]
* Patienteneinwilligung zur EFA
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
** [[cdaefa:CIM Anlegen einer Fallakte|Interaktionsmuster zum Anlegen von Fallakten]]
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
* Sicherheitszonen
</td>
<td width="30%" valign="top" align="left">
* EFA Geschäftsobjekte
** [[cdaefa:EFA Business Informationsmodell|Informationsmodell]]
** [[cdaefa:EFA Business Lebenszyklus|Lebenszyklus]]
* EFA Sicherheitsobjekte
** Informationsmodelle
* [[cdaefa:EFA Einwilligungsdokument|EFA Einwilligungsdokument]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Kommunikationsmuster|EFA Komunikationsmuster]]
* [[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]
** EFA Resource Manager
** EFA Document Registry
** EFA Document Repository
* [[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
** [[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
** [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
** EFA Access Provider SFM
* [[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Verwendete Standards|Verwendete Standards]]
* [[cdaefa:EFA Used Namespaces|Namespaces]]
</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
** [[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
** [[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]
* [[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
** [[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
** [[cdaefa:EFA Access Assertion SAML2 Binding|EFA Access Assertion SAML2 Binding]]
** [[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]

</td>
<td width="30%" valign="top" align="left">
* [[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]
* [[cdaefa:EFA XUA Binding|EFA XUA Binding]]
* [[cdaefa:EFA Access Control System|EFA Access Control System]]
* [[cdaefa:EFA XDS/XDR Bindings|EFA XDS/XDR Bindings]]
** [[cdaefa:EFA XDR SetupCaseRecord|EFA XDR Binding: SetupCaseRecord]]
** [[cdaefa:EFA XDS ListRecords|EFA XDS Binding: ListRecords]]
** [[cdaefa:EFA XDS ListRecordContent|EFA XDR Binding: ListRecordContent]]
** [[cdaefa:EFA XDS ListFolderContent|EFA XDR Binding: ListFolderContent]]
** [[cdaefa:EFA XDS RetrieveDocument|EFA XDR Binding: RetrieveDocument]]
** [[cdaefa:EFA XDR ProvideDocument|EFA XDR Binding: ProvideDocument]]

</td>
</tr>
</table>

cdaefa:EFA Access Control System

2013-03-25T13:45:54Z

Rkuhlisch: /* Bausteine des ACS */

{{DocumentPart}}

= Bindung von Policies an Schnittstellen =
Die Sicherheitsarchitektur der elektronischen Fallakte definiert für jeden Anwendungsdienst mittels WS-Policy und WS-SecurityPolicy welche Sicherheitsnachweise (Security Assertions, z. B. kodiert als Security Token) notwendig sind, um die Operationen aufrufen zu können. SAML Assertions [SAML2.0] kodieren die notwendigen Authentisierungs- und Autorisierungsinformationen, welche von speziellen Security Token Services ausgestellt werden. Hierbei kann ein Security Token Service zur Ausstellung eines geforderten Sicherheitsnachweises (Security Assertion) die Vorlage eines Security Token verlangen, dass in die Zuständigkeit eines anderen Security Token Service fällt. Auf diese Weise können Abhängigkeiten in Sicherheitsdiensten (z. B. Autorisierung erfordert Authentifizierung) auf sequentielle Ketten von Sicherheitsnachweisen abgebildet werden.

[[Datei:EFA_Assertion_Chain.png|640px]]

In der Deklaration der zur Umsetzung der Schutzziele beizubringenden Sicherheitsobjekte können „klassische“ X.509 Token und Security Context Token mit SAML Token kombiniert werden. Die eFA-Sicherheitsarchitektur erlaubt es auch, mehrere SAML Token an einen Web Service zu versenden, d. h. iterativ ganze Ketten von aufeinander verweisenden Sicherheitsnachweisen aufzubauen. Hiermit können die Nachweise der Nutzung einzelner Sicherheitsdienste (Authentisierung, Pseudonymisierung, Autorisierung, etc.) als vom unterliegenden Security Framework zu bearbeitende Bestandteile des Aufrufs eines Anwendungsdienstes kodiert werden.

Die Einbettung mehrerer SAML Assertions in das SOAP Security Header stellt auf der Implementierungsseite vielerlei Ansprüche: Zum einen muss die Semantik der Assertions selbst (strukturierte Elemente in Attributen) und zum anderen die korrekte Kombination einer Assertion-Kette überprüft werden können. Einem Aufrufenden muss zudem ein Besitznachweis für diese SAML Assertions abverlangt werden.

Um unterschiedliche Sicherheitsanforderungen für die verschiedenen Vertrauensbeziehungen zwischen Dienstnutzern und -anbietern deklarieren zu können, wird für jede Vertrauensbeziehung in der Schnittstellenspezifikation ein eigener Port definiert. So können z. B. sehr einfach unterschiedliche Policies für Zugriffe aus verschiedenen Sicherheitszonen heraus definiert werden (z. B. Zugriffe innerhalb eines Circle-of-Trust und in einen Circle-of-Trust hinein).

== Bausteine des Access Control System ==

Die nachfolgende Grafik stellt das Prinzip der Zugriffskontrolle abstrakt mit den [[cdaefa:EFA_Verwendete_Standards#eXtensible_Access_Control_Markup_Language_.28XACML.29|XACML]]-Akteuren dar. Ein Zugriff auf den eigentlichen Dienst einer Document Registry wird serverseitig von einem PEP unterbrochen. Ein PEP implementiert einen Authorization Requestor, welcher eine Autorisierungsanfrage an einen PDP (Authorization Decision Provider) stellt. Der in der Abbildung gezeigte optionale Context Handler kann diese Anfrage in ein standardisiertes Protokoll (bspw. SAML)<ref>A. Anderson und H. Lockhart (2005), SAML 2.0 profile of XACML v2.0.</ref> überführen oder der Authorization Requestor kann direkt mit einem Authorization Decision Provider kommunizieren. Über einen PAP (Policy Repository) können die eigentlichen Autorisierungsrichtlinien kodiert als XACML Policies abgerufen werden. Der Transport einer Autorisierungsanfrage bzw. Policy-Abfrage kann über einen HTTP SOAP Request erfolgen.<ref>C. L. Joie (2007), SOAP Profile for XACML-SAML.</ref> Sind weitere Attribute für die Evaluierung einer Autorisierungsentscheidung notwendig (eine Policy bestimmt die notwendigen Attribute), so können diese über einen PIP bezogen werden.

[[Datei:EFA_ACS_abstrakt.jpg|700px]]

[[IHE_DE_Cookbook#.C3.9Cberpr.C3.BCfen_von_Berechtigungen|IHE Cookbook]]

IHE White Paper on Access Control <ref name="ihe-acwp">J. Caumanns et al. (2009), IHE White Paper on Access Control, S. 56f. [Online]. Available: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf</ref>



= Referenzen =
<references/>

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

Datei:EFA ACS abstrakt.jpg

2013-03-25T10:38:38Z

Rkuhlisch:

cdaefa:EFA Verwendete Standards

2013-03-25T10:02:24Z

Rkuhlisch: Die Seite wurde neu angelegt: „== Security Assertion Markup Language (SAML) == Die Security Assertion Markup Language (SAML) spezifiziert einen Rahmen, in dem vertrauenswürdige Aussagen zu Id…“

cdaefa:EFA Access Control System

2013-03-21T09:19:45Z

Rkuhlisch:

cdaefa:EFA Spezifikation v2.0

2013-03-07T09:51:01Z

Rkuhlisch: /* Aufbau der Spezifikation */

{{Infobox Dokument
|Title = Spezifikation EFA 2.0
|Short = Spezifikation EFA 2.0
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

== Einleitung ==

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - eine Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einen Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt an festen Orten gespeichert. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichert somit die Zusammenarbeit auf regionaler Ebene.

== EFA Spezifikation v2.0 ==
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der EFA Version 1.2 das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität der EFA-Abläufe zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt ist und die übergeordneten EFA-Konzepte (Fallakte, Ordner) nicht abdeckt.

Im März 2012 haben daher der EFA-Verein als Träger der EFA-Spezifikation und der bvitg als Vertreter der ambulanten und stationören Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifiation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und
* durch Verzahnung mit dem "IHE Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== Aufbau der Spezifikation ==

Die EFA-Spezifikation orientiert sich an der Spezifikationsmatrix des ''[http://wiki.hl7.org/index.php?title=SAIF_ECCF Enterprise Consistency and Conformity Framework]'' (ECCF) als Teil des HL7 ''Service-Aware Interoperability Framework'' (SAIF). Die folgende Tabelle gibt sie am Beispiel der EFA wieder.

<table border="1" cellspacing="0" cellpadding="0" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top"></td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
* Prinzipien und Strategien für EFA
** Die EFA als zweckgebundene Akte
** Akteure und Rollen der EFA
** Prinzipien für Datenschutz und Datensicherheit
** Vernetzung von Netzen
** Integration in bestehende IT-Landschaften
</td>
<td width="30%" valign="top" align="left">
* EFA-Informationsobjekte
** Fallakten
** Ordner
** (med.) Dokument
* Patienteneinwilligung
</td>
<td width="30%" valign="top" align="left">
* Geschäftsfunktionalitäten
** Interaktions- und Kommunikationsmuster
** EFA-Initialisierung
* EFA-Design-Prinzipien
** Nutzung von Standards
** Autonomie von EFA-Peers
** Eckpfeiler EFA-Sicherheit
* Schichtenarchitektur
** EFA-3-Schichten-Architektur
** Kompatibilität mit dem [[IHE_DE_Cookbook|IHE Cookbook]] (nicht-normativ)
** Abwärtskompatibilität mit der EFA-Spezifikation v1.2
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
* Anforderungen an Anwendungs- und Sicherheitsarchitektur
* Sicherheitszonen
</td>
<td width="30%" valign="top" align="left">
* Logisches Informationsmodell der EFA
</td>
<td width="30%" valign="top" align="left">
* EFA-Dienste
* EFA-Funktionen
* Sicherheitsdienste
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
</td>
<td width="30%" valign="top" align="left">
</td>
<td width="30%" valign="top" align="left">
</td>
</tr>
</table>

Die Spalten der Tabelle stellen bestimmte Eigenschaften des zu analysierenden und zu spezifizierenden Systems dar:
* Die Enterprise Dimension definiert den geschäftlichen Zusammenhang und befasst sich primär mit den EFA-Informationsobjekten und EFA-Geschäftsprozessen.
* Die Information Dimension befasst sich mit dem Informationsmodell der Fallakte sowie damit zusammenhängenden Restiktionen bei der Nutzung und Interpretation dieser Information.
* Die Computational Dimension fokussiert auf die fachlichen Funktionen der EFA mit den zugehörigen Akteuren, welche durch Transaktionen mit einem bestimmtem Verhalten und Interaktionen charakterisiert sind.

Die Zeilen der Tabelle geben verschiedene Abstraktionsgrade wieder und adressieren somit verschiedene Expertengruppen:
* Die Conceptual Perspective ist vollstänig rechnerunabhängig und eher problem- als lösungsorientiert. Artefakte dieser Ebene skizzieren die Grundlagen und Kernkonzepte der EFA aus der Fachexpertensicht und definieren als solche das ganzheitliche konzeptionelle Modell der EFA.
* Artefakte in der Logical Perspective stellen nachvollziehbare Transformationen von Artefakten der konzeptuellen Ebene in Formate für Architekten/Analysten dar. Diese Perspektive repräsentiert die funktionale/logische Spezifikation der EFA und definiert somit den EFA-Lösungsraum mit seinen Klassen, Diensten und Operationen.
* Artefakte in der Implementable Perspective enthalten alle notwendigen, technischen Bindungen (z. B. Datentypen, Wertemengen, Schnittstellen-Spezifikationen etc.) mit denen Entwickler in die Lage versetzt werden, Bausteine der funktionalen/logischen Spezifikation mittels Standards-basierender technischer Komponenten umzusetzen zu können.

== EFA-Conceptual-Perspective-Spezifikation ==


== EFA-Application-Architecure-Spezifikation ==


== EFA Security Architecure Specification ==


== EFA Bindings ==

cdaefa:EFA Spezifikation v2.0

2013-03-06T15:11:03Z

Rkuhlisch:

{{Infobox Dokument
|Title = Spezifikation EFA 2.0
|Short = Spezifikation EFA 2.0
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

== Einleitung ==

Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - eine Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.

Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einen Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.

Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt an festen Orten gespeichert. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichert somit die Zusammenarbeit auf regionaler Ebene.

== EFA Spezifikation v2.0 ==
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der EFA Version 1.2 das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.

Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität der EFA-Abläufe zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt ist und die übergeordneten EFA-Konzepte (Fallakte, Ordner) nicht abdeckt.

Im März 2012 haben daher der EFA-Verein als Träger der EFA-Spezifikation und der bvitg als Vertreter der ambulanten und stationören Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifiation zu erarbeiten. Diese Version soll
* auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen
* in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und
* durch Verzahnung mit dem "IHE Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

== Aufbau der Spezifikation ==

Die EFA-Spezifikation orientiert sich an der Spezifikationsmatrix des ''[http://wiki.hl7.org/index.php?title=SAIF_ECCF| Enterprise Consistency and Conformity Framework]'' (ECCF) als Teil des HL7 ''Service-Aware Interoperability Framework'' (SAIF). Die folgende Tabelle gibt sie am Beispiel der EFA wieder.

<table border="1" cellspacing="0" cellpadding="0" width="100%">
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top"></td>
<td width="30%" valign="top">'''Enterprise Dimension''' '''''"Why"''''' '''''Policy'''''</td>
<td width="30%" valign="top">'''Information Dimension''' '''''"What"''''' '''''Content'''''</td>
<td width="30%" valign="top">'''Computational Dimension''' '''''"How"''''' '''''Behavior'''''</td>
</tr>

<tr bgcolor="orange" align="center">
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
<td width="30%" valign="top" align="left">
* Prinzipien und Strategien für EFA
** Die EFA als zweckgebundene Akte
** Akteure und Rollen der EFA
** Prinzipien für Datenschutz und Datensicherheit
** Vernetzung von Netzen
** Integration in bestehende IT-Landschaften
</td>
<td width="30%" valign="top" align="left">
* EFA-Informationsobjekte
** Fallakten
** Ordner
** (med.) Dokument
* Patienteneinwilligung
</td>
<td width="30%" valign="top" align="left">
* Geschäftsfunktionalitäten
** Interaktions- und Kommunikationsmuster
** EFA-Initialisierung
* EFA-Design-Prinzipien
** Nutzung von Standards
** Autonomie von EFA-Peers
** Eckpfeiler EFA-Sicherheit
* Schichtenarchitektur
** EFA-3-Schichten-Architektur
** Kompatibilität mit dem [[IHE_DE_Cookbook|IHE Cookbook]] (nicht-normativ)
** Abwärtskompatibilität mit der EFA-Spezifikation v1.2
</td>
</tr>

<tr bgcolor="yellow" align="center">
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
<td width="30%" valign="top" align="left">
* Anforderungen an Anwendungs- und Sicherheitsarchitektur
* Sicherheitszonen
</td>
<td width="30%" valign="top" align="left">
* Logisches Informationsmodell der EFA
</td>
<td width="30%" valign="top" align="left">
* EFA-Dienste
* EFA-Funktionen
* Sicherheitsdienste
</td>
</tr>

<tr bgcolor="palegreen" align="center">
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
<td width="30%" valign="top" align="left">
</td>
<td width="30%" valign="top" align="left">
</td>
<td width="30%" valign="top" align="left">
</td>
</tr>
</table>

Die Spalten der Tabelle stellen bestimmte Eigenschaften des zu analysierenden und zu spezifizierenden Systems dar:
* Die Enterprise Dimension definiert den geschäftlichen Zusammenhang und befasst sich primär mit den EFA-Informationsobjekten und EFA-Geschäftsprozessen.
* Die Information Dimension befasst sich mit dem Informationsmodell der Fallakte sowie damit zusammenhängenden Restiktionen bei der Nutzung und Interpretation dieser Information.
* Die Computational Dimension fokussiert auf die fachlichen Funktionen der EFA mit den zugehörigen Akteuren, welche durch Transaktionen mit einem bestimmtem Verhalten und Interaktionen charakterisiert sind.

Die Zeilen der Tabelle geben verschiedene Abstraktionsgrade wieder und adressieren somit verschiedene Expertengruppen:
* Die Conceptual Perspective ist vollstänig rechnerunabhängig und eher problem- als lösungsorientiert. Artefakte dieser Ebene skizzieren die Grundlagen und Kernkonzepte der EFA aus der Fachexpertensicht und definieren als solche das ganzheitliche konzeptionelle Modell der EFA.
* Artefakte in der Logical Perspective stellen nachvollziehbare Transformationen von Artefakten der konzeptuellen Ebene in Formate für Architekten/Analysten dar. Diese Perspektive repräsentiert die funktionale/logische Spezifikation der EFA und definiert somit den EFA-Lösungsraum mit seinen Klassen, Diensten und Operationen.
* Artefakte in der Implementable Perspective enthalten alle notwendigen, technischen Bindungen (z. B. Datentypen, Wertemengen, Schnittstellen-Spezifikationen etc.) mit denen Entwickler in die Lage versetzt werden, Bausteine der funktionalen/logischen Spezifikation mittels Standards-basierender technischer Komponenten umzusetzen zu können.

== EFA-Conceptual-Perspective-Spezifikation ==


== EFA-Application-Architecure-Spezifikation ==


== EFA Security Architecure Specification ==


== EFA Bindings ==