Version vom 20. März 2013, 08:05 Uhr

	Dieses Dokument gibt wieder: Implementierungsleitfaden eFA Spezifikation v2.0 (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an.

eFA Spezifikation v2.0

Implementierungsleitfaden

vorgelegt von:
February 2013
Jörg Caumanns, Raik Kuhlisch

Draft

Version:	0.9
Datum:	March 2013
Status:	xxx
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
01	2013	Entwurf	Deutschland
		noch kein download verfügbar

Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen Spezifikationsvorschlag für eine elektronische Einwilligung erstellt, der aktuell innerhalb des Interoperabilitätsforums zur öffentlichen Kommentierung freigegeben wurde. Nach Abschluss der Kommentierung werden die EFA-relevanten Bestandteile dieser Spezifikation als Supplement zur EFAv2.0-Spezifikation auf dieser Seite verlinkt.

Im Rahmen des europäischen IHE Connectathon 2017 in Venedig wird der zweite "EFA Projectathon" stattfinden. Alle hierzu relevanten Informationen finden Sie auf der Seite "EFA Projectathon 2017".

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Einleitung

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {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." - einer 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 einem 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 dezentral in bestehenden Systemen verwaltet und können bei Bedarf zu einer integrierten, für alle behandelnden Ärzte einheitlichen Sicht auf den Patienten zusammengeführt werden. 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

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {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. epSOS und Prozessdatenbeschleuniger (P23R) 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 des EFA-1.2-Informationsmodells zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt war.

Im März 2012 haben daher der EFA-Verein als Träger der EFA-Spezifikation und der bvitg als Vertreter der im ambulanten und stationären Sektor tätigen Hersteller von IT-Lösungen 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 eine Abbildbarkeit des EFA-Informationsmodells auf das Aktenkonzept von IHE herstellen,
durch Verzahnung mit dem IHE-D Cookbook auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

EFA 2.0 Spezifikation

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Epif.03}

Die folgende Tabelle stellt die einzelnen Kapitel der EFA 2.0 Spezifikation im Strukturraster des HL7 Enterprise Conformance and Compliance Frameworks dar. Die Spezifikation liegt auch als kompiliertes Dokument vor:

EFA v2.0	Enterprise Dimension "Why" Policy	Information Dimension "What" Content	Computational Dimension "How" Behavior
Conceptual Perspective	Die EFA als zweckgebundene Akte Versorgungsdomänen Die EFA als Gesundheitsdatendienst Peer-to-Peer-Vernetzung von EFA-Providern Akteure und Rollen Prinzipien für Datenschutz und Datensicherheit	Kontext, Akte, Ressource Patienteneinwilligung zur EFA EFA Geschäftsobjekte Lebenszyklus einer Fallakte	Interaktionsmuster der EFA Anlegen einer Fallakte Anlegen und Registrieren einer Partition Einstellen von Datenobjekten Auffinden der Fallakten eines Patienten Browsing über eine Akte oder eine Partition Abruf von Datenobjekten Schließen einer Fallakte Invalidieren von Datenobjekten Ändern der Einwilligung Autorisierung eines weiteren Teilnehmers Zusammenführen von Fallakten
Logical Perspective	EFA Sicherheitsanforderungen	Informationsmodelle der EFA Geschäftsobjekte Informationsmodelle der EFA Sicherheitsobjekte Fehlermeldungen und Warnungen	EFA Dienste EFA Kommunikationsmuster EFA Anwendungsdienste (logische Spezifikation) EFA Sicherheitsdienste (logische Spezifikation) EFA Context Manager SFM EFA Identity Provider SFM EFA Policy Provider SFM Gruppierung von Anwendungs- und Sicherheitsdiensten
Implementable Perspective	Verwendete Standards Namespaces	EFA Metadata Bindings EFA XDS Folder Metadata Binding EFA XDS Document Metadata Binding EFA Security Objects Bindings EFA Identity Assertion SAML2 Binding EFA Policy Assertion SAML2 Binding EFA Patient Consent Binding EFA Audit Trail Binding EFA Error Codes and Warning Codes	EFA IHE Setup and Flow of Control EFA XDS Bindings EFA XDS Binding: ResourceManager EFA XDS Binding: DocumentRegistry EFA XDS Binding: DocumentRepository EFA Access Control System EFA WS-Trust Binding: PolicyProvider Security Considerations

Weiterführende Themen

In der EFA-Spezifikation wird an verschiedenen Stellen auf weiterführende Informationen oder Grundlagenpapiere verwiesen, die in der ECCF-Matrix nicht verzeichnet sind. Diese "Anhänge" zur EFAv2.0-Spezifikation sind hier verzeichnet.

Methodische Grundlagen

HL7 SAIF ECCF: Kurze Einführung in das HL7 SAIF Enterprise Conformance and Compliance Framework, das dem Aufbau dieser Spezifikation zugrunde liegt
IHE Access Control Domains: Zusammenfassung des IHE White Paper "Access Control" mit Fokus auf in der EFAv2.0-Spezifikation genutzte Konzepte und Begrifflichkeiten

EFA Konformitätsnachweis

In Abstimmung zwischen dem Vorstand des EFA-Vereins und dem Fraunhofer FOKUS wird ein Verfahren zum Nachweis der Konformität von Produkten zu den EFA-Spezifikationen durchgeführt, das im Wesentlichen auf einer Selbsterklärung eines Herstellers beruht. EFAv2.0-konforme Produkte dürfen das EFA-Logo tragen und mit dem EFA-Logo auf Messen sowie in Print- und Online-Materialien beworben werden.

Gegenstand der Konformitätsprüfung

Die Ausstellung dieses EFAv2.0-Konformitätsnachweises ist für Hersteller kostenlos und wird wie bisher durch das Fraunhofer FOKUS durchgeführt. Das Fraunhofer FOKUS ist zur Durchführung des Verfahrens und zur Vergabe des EFA-Logos vom EFA-Verein akkreditiert.

Durchführung der Konformitätsprüfung

Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS (joerg.caumanns@fokus.fraunhofer.de) anfordern.

Hinweis: Das hier beschriebene Verfahren und die ausgestellten Konformitätsnachweise sind bis Ende 2014 gültig. Ab 2015 soll ein erweitertes Verfahren zum Tragen kommen, dass auf der erfolgreichen Teilnahme von Produkten an einem IHE Connectathon aufsetzt.

Change Requests

Mit der Finalisierung der EFA-Spezifikation im Herbst 2013 haben verschiedene Hersteller (und auch FuE-Projekte) begonnen, die EFAv2.0 zu implementieren. Trotz aller Sorgfalt bei der Erstellung der Spezifikationen fallen hierbei zuweilen kleinere Fehler auf und an manchen Stellen sind fachliche oder technische Festlegungen nur schwer nachvollziehbar, da die entsprechenden Beweggründe der Autorengruppe von Fraunhofer FOKUS, EFA-Verein und bvitg nicht ausreichend dokumentiert wurden.

Um die Spezifikationen kontinuierlich zu verbessern und insbesondere auch Hersteller und Projekte bestmöglich bei der Implementierung zu unterstützen, nehmen wir Fragen und Anregungen weiterhin gerne entgegen. Hierzu wurde für die EFAv2.0 ein regulärer Change- und Releasemanagement-Prozess definiert, der ab Juli 2015 schrittweise operationalisiert wird.

Alle nach den vorgaben des definierten Prozesses eingereichten Änderungsanforderungen an die EFAv2.0-Spezifikation werden auf dieser Seite aufgelistet und durch Fraunhofer FOKUS, EFA-Verein und bvitg bearbeitet. Der Status der Bearbeitung sowie Entscheidungen zur Annahme bzw. Ablehnung eines Changes Requests werden auf der zu jedem Change Request angelegten Wiki-Seite dokumentiert.

Hinweis: Alle Änderungsbedarfe an der EFAv2.0-Spezifikation, die sich aus angenommenen IHE ITI Change Proposals ergeben können, sind in der nachfolgenden Liste offener Change Requests bis einschließlich Ballot-35 (Juli 2016, finaler Ballot für IHE ITI-TF Revision 13) berücksichtigt.

Offene Punkte und ToDos

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Epif.04}

ToDos aus der Kommentierung (Fraunhofer)

Informationsmodell: Übersichtsgrafik als UML-Klassenmodell
EFA Anwendungsdienste: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
Akteure und Rollen: Akteursdiagramm einfügen
Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)

Diskussionsbedarfe - operativ (7er-Gruppe)

Binding für die Operation issueAccessToken
Binding für die Operation redeemAccessToken
Informationsmodell für die Klasse accessToken
Binding für die Klasse accessToken

Diskussionbedarfe - strategisch (Lenkungsgruppe)

Abschnitte, die ggf. in das Cookbook verschoben werden können

cdaefa:EFA_Business_Informationsmodell#Patient: Regel "Sender does it right"
cdaefa:EFA_Business_Informationsmodell#purpose
cdaefa:EFA_XDS_ResourceManager#EFA_XDS.2FXDR_Binding:_createECR: "The application of security measures and the contents of the SOAP security header are specified normatively"
cdaefa:EFA_XDS_ResourceManager#Security_Considerations
cdaefa:EFA_Verwendete_Standards#Verwendete_Standards:_Sicherheit
cdaefa:EFA_IHE_Setup_and_Flow_of_Control#EFA_Setup
cdaefa:Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten#Gruppierung_von_Anwendungs-_und_Sicherheitsdiensten
cdaefa:Patienteneinwilligung_zur_EFA#Patienteneinwilligung_zur_EFA
cdaefa:EFA_Identity_Assertion_SAML2_Binding#HCP_Identity_Attributes: Values for attribute "Structural Role"

Externe Abhängigkeiten

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:

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:
- Subject-Attribut im EFA SAML Profil

Conceptual Perspective

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Die EFA als zweckgebundene Akte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {DFlsb.01}

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 (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"

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {DFlsb.01.01}

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 die klare Benennung des Zwecks der Nutzung einer Fallakte im Rahmen einer einrichtungsübergreifenden Behandlung. Zentral ist hierbei 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). Das der Fallakte zugrunde liegende einrichtungsübergreifende Behandlungsgeschehen wird in den technischen Spezifikationen der EFA als "medizinischer Fall" bezeichnet, der inhaltlich den medizinischen Kommunikationsbedarf zwischen mitbehandelnden Organisationen festlegt. Dabei wird davon ausgegangen, dass jeder "medizinische" Fall vorab zwischen den Akteuren getroffene Absprachen zu den Kommunikationsinhalten und -prozessen abbildet, d. h. vielmehr ein Behandlungsmuster widerspiegelt als die spezifische Versorgung eines individuellen Patienten. Der "Zweck" einer Fallakte referenziert entsprechend auf dieses abgestimmte Muster, das Vorgaben zu den Versorgungszielen, der inhaltlichen Abgrenzung und den Kommunikationsflüssen festlegt.

Auswirkungen der Zweckbindung auf die Nutzung von Fallakten

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

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.

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

EFA-2.0-Spezifikation
Abgrenzung der Fallakte gegen patientengeführte Akten (Quelle: EFA-Verein)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Die EFA als Gesundheitsdatendienst

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

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

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

Gesundheitsdatendienste (GDD)

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

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

Das Konzept der "Gesundheitsdatendienste" (GDD) verfolgt die gleiche Idee, setzt jedoch eine Ebene höher bei den logischen Bausteinen des Austauschs von Gesundheitsdaten zwischen Leistungserbringern an. Gesundheitsdatendienste bilden somit eine Klasse von Anwendungen, die auf identischen funktionalen Bausteinen (Kommunikationsmuster), logischen Informationsmodellen und Sicherheitsanforderungen basieren. Wesentliche Gemeinsamkeiten aller GDD sind:

Der GDD vermittelt den Austausch von medizinischen Daten zwischen Leistungserbringern bzw. zwischen Leistungserbringern und medizinisch-fachlichen, IT-gestützten Diensten (z.B. elektronische Register)
Der Austausch der Daten erfolgt zweckbezogen im Kontext der medizinischen Versorgung (einschließlich Vorsorge, Rehabilitation, Versorgungsforschung, etc.)
Die ausgetauschten Daten haben einen hohen Schutzbedarf (über einen GDD vermittelte Daten können auch einen sehr hohen Schutzbedarf haben, in diesem Fall müssen jedoch die GDD-übergreifenden Datenschutzkonzepte und Sicherheitsdienste für diesen GDD spezifisch erweitert werden)
Zu jedem GDD kann es verschiedene Anbieter geben

Diese Gemeinsamkeiten werden auf ein GDD-Referenzmodell abgebildet, das insbesondere wiederkehrende Muster in Bezug auf Nutzerinteraktion, Ablaufsequenzen und die Vernetzung elementarer Informationsbausteine aufnimmt. Hierdurch können insbesondere auch Datenschutzkonzepte, Betriebskonzepte und Sicherheitskonzepte zwischen GDD übertragen werden.

Die EFAv2.0 ist ein GDD und damit auch eine Instanz des GDD-Referenzmodells. Viele der technischen Spezifikationen der EFAv2.0 bilden valide Bindings zu den funktionalen und logischen Bausteinen von Gesundheitsdatendiensten und sind damit GDD-übergreifend wiederverwendbar. Ebenso sind viele der Sicherheits- und Datenschutzmechanismen der EFAv2.0 valide Umsetzungen der allen GDD gemeinsamen Sicherheits- und Datenschutzanforderungen und können damit ebenfalls für weitere GDD genutzt werden.

GDD Referenzmodell

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

Gesundheitsdatendienste besitzen eine Vielzahl gemeinsamer Charakteristika in Bezug auf IT-Sicherheit, Datenschutz und TI-Konformität, die sich u.a. in wiederverwendbaren GDD-Artefakten (Konzepte, Spezifikationen, etc) widerspiegeln, die nur einmalig definiert werden müssen und dann für jeden einzelnen GDD profiliert bzw. instanziiert werden können. Durch solche GDD-übergreifend nutzbaren Komponenten werden die Aufwände zur Implementierung und Zulassung sowie zum Betrieb eines GDD deutlich reduziert.

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

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

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

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

Durch Instanziierung, Anpassung und Erweiterung des Referenz-Objektmodells und der Referenz-Abläufe kann ein bestehender oder geplanter GDD sehr einfach in das Rahmenwerk des GDD-Referenzmodells eingepasst werden. Hierdurch können alle GDD-übergreifend angelegten Spezifikationen, Konzepte und Software-Komponenten zur Implementierung und zum Aufsetzen des GDD sowie zu seiner Migration in die zukünftige Telematikinfrastruktur genutzt werden.

Referenzen und Querverweise

EFAv2.0-Spezifikation
Informationen zu den geplanten Anwendungen auf der Telematikinfrastruktur (Quelle: gematik)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Affinity Domain vs. Versorgungsdomänen

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Erid.01}

Die elektronische Fallakte ist eine Plattform für die regionale Vernetzung und Verankerung von Krankenhäusern. Während z. B. Zuweiserportale lediglich einzelne Aspekte der Datenkommunikation mit Niedergelassenen effizienter gestalten, bildet die elektronische Fallakte ein vollständiges regionales Versorgungsnetzwerk ab, in dem die einzelnen Akteure beliebige Gesundheitsdatendienste aufsetzen und eigene, fallspezifische Kooperationsnetze innerhalb des Verbunds ausbilden können:

Als Plattform bietet die elektronische Fallakte Sicherheits- und Datendienste an, auf denen neben der Anwendung Fallakte auch beliebige weitere Gesundheitsdatendienste (Fallkonferenz, Terminbuchung, Tele-Konsil, etc.) aufgesetzt werden können. Nutzeraccounts und Berechtigungen werden in den beteiligten Einrichtungen zentral verwaltet und können von allen Gesundheitsdatendiensten im regionalen Verbund genutzt werden; hierdurch wird nicht nur das Aufsetzen neuer Anwendungen einfacher und kostengünstiger, sondern auch der Nutzenkomfort für die Ärzte erhöht: ein Arzt muss sich nicht an jedem Portal neu anmelden und es spielt für ihn keine Rolle mehr, wo benötigte Daten nun gerade physikalisch gespeichert sind – er meldet sich einfach wie bisher an seinem System an und die Plattform sorgt dann dafür, dass er alle benötigten Dienste und Daten so nutzen kann, als wären diese lokal in seinem System verfügbar.
Als Anwendung vernetzt die elektronische Fallakte alle Ärzte, die in die Behandlung einer Erkrankung eines Patienten eingebunden sind. Alle behandelnden Ärzte haben Zugriff auf alle Daten eines medizinischen Falls und pflegen über die Fallakte eine gemeinsame Falldokumentation. Über die Fallakte werden somit bestehende Kooperationsbeziehungen in einem regionalen Netzwerk technisch unterstützt und auf eine einheitliche technische Basis gesetzt.

Diese unterschiedlichen Sichtweisen auf eine EFA als Plattform und als Anwendung spiegelt sich auch in den unterliegenden Konzepten der technischen und fachlichen Vernetzung der EFA Teilnehmer wider:

EFA als Plattform: Ein Netzwerk von kooperierenden Einrichtungen, in dem es festgelegte Regeln zur technischen und semantischen Umsetzung von Diensten zum Austausch medizinischer Informationen sowie zur Umsetzung von IT-Sicherheit und Datenschutz gibt, wird als Affinity Domain bezeichnet. Der originären Definition einer Affinity Domain durch IHE folgend wird eine Affinity Domain immer von einem EFA-Provider mit einem EFA-Peer bedient (wobei umgekehrt ein Provider auch mehrere Affinity Domains realisieren kann). Alle Einrichtungen der Affinity Domain nutzen bevorzugt die EFA-Dienste des die Affinity Domain technisch abbildenden EFA-Peers und sind mit dem entsprechenden Provider vertraglich verbunden. Die Zugehörigkeit einer Arztpraxis oder eines Krankenhauses wird somit alleine durch die vertragliche Bindung dieser Einrichtung an einen EFA-Provider bestimmt.
EFA als Anwendung: Diametral zu der Affinity Domain ist zusätzlich jede an einer EFA teilnehmende Einrichtung auch einer oder mehreren Versorgungsdomänen zugeordnet. Hierbei handelt es sich um einen regionalen (ggf. nationalen) Zusammenschluss von Einrichtungen zur kooperativen und einheitlichen fachlichen Vorgaben folgenden Behandlung von bestimmten Patientengruppen; z. B. im Rahmen eines Traumanetzwerks oder eines Palliativnetzes.

Die nachfolgende Abbildung stellt exemplarisch über mehrere EFA-Provider realisierte Affinity Domains und Versorgungsdomänen (fachliche Netzwerke) dar. Die kleinen Kreise bezeichnen dabei jeweils einzelne (Partitionen von) Fallakten.

Die vorliegende EFAv2.0 Spezifikation definiert Vorgaben für die EFA als Plattform und damit für die Umsetzung einer EFA-konformen Affinity Domain. Vorgaben für die konkrete Umsetzung von EFA-Anwendungen innerhalb von Versorgungsdomänen - z. B. Festlegungen zu den Inhalten einer Fallakte - sind nicht Gegenstand dieser Spezifikation.

Krankenhäuser als EFA Provider

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Erid.01.01}

Ein Krankenhaus ist immer sehr stark regional verankert und spielt eine besondere Rolle in regionalen Versorgungsstrukturen. Die von der Politik immer wieder gerne ausgerufenen Gesundheitsregionen sind ohne Krankenhäuser nicht denkbar und genauso ist für ein Krankenhaus eine Teilnahme an neuen Versorgungsformen ohne funktionierende Gesundheitsregion nicht denkbar. Der Betrieb eines Krankenhauses ist damit ein Geschäft, das über die stationäre Behandlung von Patienten hinausgeht. Teil dieses Geschäfts ist das Aufsetzen zeitgemäßer Angebote für andere Akteure im regionalen Verbund, um für Zuweiser und Patienten attraktiv zu bleiben und neue Kundengruppen zu gewinnen bzw. bestehenden Kunden zusätzliche Angebote zu machen.

Aus dieser Motivation heraus übernehmen in vielen Netzwerken Krankenhäuser die Funktion des EFA-Providers. Hiermit übernimmt dieses Krankenhaus innerhalb seiner Affinity Domain zwei Rollen:

als technischer Dienstleister der die Infrastruktur zur Anlage und Pflege von Fallakten bereitstellt
als Gesundheitsdienstleister der am medizinischen Datenaustausch über die Fallakte teilnimmt

Eine logische Trennung der beiden Rollen MUSS zwingend vorgenommen werden und hat folgende Vorteile:

Als Gesundheitsdienstleister nutzt der EFA Provider die gleichen Schnittstellen und Funktionen die auch für die anderen Teilnehmer bereitgestellt werden müssen
Als technischer Dienstleister kann der EFA Provider seinen administrativen Pflichten nachkommen ohne datenschutzrechtlich bedenkliche umfängliche Zugriffsrechte auf medizinische Inhalte

Diese logische Trennung schliesst nicht aus, dass ein EFA Provider besondere Integrationsbedürfnisse hat. Diese sind aber sehr spezifisch und können praktisch nicht standardisiert werden.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Akteure der EFA

Patient (Versicherter)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Auun.01.01}

Der Bürger tritt in der Rolle des "Patienten" auf (und nicht als "Versicherter"), da sich hieran wesentliche Grundsatzentscheidungen für Umsetzung und Nutzung der EFA knüpfen:

es liegt eine Erkrankung vor, aus der heraus sich der Zweck der EFA-Nutzung ergibt. Übergeordneter und vorrangiger Zweck ist dabei immer, die Effizienz und Qualität der Prozesse zur Verbesserung des Zustands des Patienten durch den Einsatz einer Fallakte zu steigern.
der Betroffene ist auf die behandelnden Ärzte angewiesen und muss deren Entscheidungen und Handlungen in einem guten Maße vertrauen. Insbesondere muss er den behandelnden Ärzten auch vertrauen, dass diese sorgfältig mit seinen Gesundheitsdaten umgehen - unabhängig davon, ob es sich um Daten auf Papier oder in einer elektronischen Akte handelt.

Der Patient hat keinen Zugriff auf die Fallakte. Stattdessen kann er mit der Abgabe einer Einwilligungserklärung Fallaktenmanager und EFA-Teilnehmer zum Zugriff berechtigen. Das Recht zur Einholung einer Selbstauskunft bleibt davon unberührt.

Fallaktenmanager

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Auun.01.02.01}

Der Fallaktenmanager trägt die Verfahrens- und Fachverantwortung mit allen den daraus resultierenden Rechten und Pflichten (auch Haftung). Dieser Rolle sind bei unmittelbarer Wahrnehmung der Pflichten als Disziplinarvorgesetzter sämtliche Berechtigungen einer Fallakte zugewiesen. Diese Rolle sollte der klinische Leiter/Direktor (oder der im Allgemeinen zuständige Disziplinarvorgesetzte) der eröffnenden Stelle besetzen.

Die Rolle des Fallaktenmanagers muss für jede angelegte Fallakte besetzt sein. Der Fallaktenmanager muss in der Einwilligung als verfahrens- und fachverantwortliche Person benannt sein. Als Verfahrens- und Fachverantwortlicher wird der Fallaktenmanager von den Teilnehmern eines EFA-Netzwerks festgelegt. Eine Änderung dieser Festlegung durch den Patienten ist nicht möglich.

Der Fallaktenmanager ist die einzige Stelle, die auf eine Fallakte im gesperrten Zustand über ein gesondertes Verfahren zugreifen kann und dem gegenüber invalidierte Daten sichtbar sind. Des Weiteren kann der Fallaktenmanager bei Bedarf jederzeit die Löschung einer Fallakte durchführen.

EFA-Teilnehmer

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

Der Patient legt die an seiner Behandlung teilnehmenden Akteure fest und berechtigt diese zur Teilnahme an einer zur Unterstützung der Behandlung aufgesetzten elektronischen Fallakte. EFA-Teilnehmer sind damit üblicherweise alle in die Behandlung einbezogenen Ärzte sowie das nicht-ärztliche medizinische Fachpersonal (z. B. Pflegekräfte), das in die Behandlung und Dokumentation als berufsmäßig tätige Gehilfen der Ärzte einbezogen ist.

Im Kontext der Fallakte wird der Akteur "EFA-Teilnehmer" üblicherweise als Rolleninhaber innerhalb einer Institution betrachtet, in der er als Arzt oder Gehilfe seine Berechtigung zur Nutzung der Fallakte aus seiner Mitwirkung an der Behandlung des Versicherten begründen kann. Dabei kann der Versicherte die Berechtigung an weitere Voraussetzungen gebunden haben, z. B. an die Zugehörigkeit zur behandelnden Fachabteilung im Krankenhaus.

Die Erteilung einer Berechtigung an eine Institution ist jedoch in jedem Fall an die Voraussetzung gebunden, dass den innerhalb der berechtigten Institution tätigen Heilberuflern ausschließlich im Rahmen ihrer Beteiligung an der Behandlung eine Nutzung ermöglicht wird und eine Nutzung durch nicht in die Behandlung einbezogene Personen in der Einrichtung technisch oder organisatorisch verhindert wird.

Die Verantwortung für den Inhalt der Fallakte liegt bei den teilnehmenden Ärzten, wobei jeder Arzt die Richtigkeit und Vollständigkeit der aus seinem Zuständigkeitsbereich heraus in die Akte eingestellten Daten sicherstellen muss.

Inhaber der Rolle "EFA-Teilnehmer" haben das Recht,

Fallakten anzulegen und in einen geordneten Schließungsprozess zu überführen
neue Partitionen zu einer Fallakte anzulegen
alle in eine Fallakte eingestellten, gültigen Daten einzusehen und aus der Akte in ihre IT-Systeme zu übernehmen
selbst erhobene oder von Dritten (einschießlich des Patienten) empfangene medizinische Daten in eine Fallakte einzustellen
in eine Fallakte eingestellte Dokumente zu invalidieren

Diese Rechte gelten auch für über mehrere Provider verteilt vorgehaltene Fallakten, wobei die Anlage von Akten und Partitionen sowie das Einstellen von Daten ausschließlich bei EFA-Providern erfolgt, mit denen ein Arzt entsprechende vertragliche Vereinbarungen getroffen hat.

Von der obigen Aufstellung abweichende Berechtigungen existieren lediglich für einige Sonderrollen:

Verwaltungspersonal: Auch wenn die Einwilligung zur Nutzung der Fallakte gegenüber einem Arzt gegeben werden muss, so können die damit verbundenen administrativen Aufgaben durch Verwaltungspersonal vorgenommen werden. Diesem Personal wird daher die Berechtigung eingeräumt, elektronische Fallakten für Ärzte zu eröffnen. Eine Berechtigung dieser Rolle, Fallakten einzusehen oder zu modifizieren, ist keinesfalls gewährt.
Die Umsetzung dieser Rolle in einem EFA-Netzwerk ist optional, d.h. es kann durchaus die Vorgabe definiert werden, dass der vollständige Ablauf der Einrichtung einer Fallakte vom Einwilligungsnehmer durchgeführt werden muss.
Personen mit datenschutzrechtlichen Kontrollaufgaben: Personen mit datenschutzrechtlichen Kontrollaufgaben sind im täglichen Regelbetrieb keine Zugangs- und Zugriffsrechte eingeräumt. Für geplante Audits und ungeplante oder stichprobenartige Kontrollen sind hier jedoch für die Dauer der Prüfung ausreichende Berechtigungen zur Wahrnehmung der Kontrollpflichten zu vergeben. Dies gilt auch, wenn auf Grund von Patientenbeschwerden eine außerordentliche Prüfung durch eine Kontrollinstanz notwendig wird.
Automatisierte Audits und Plausibilitätsprüfungen: Auch potenziellen automatisierten (Datenschutz-)Analysewerkzeugen können gegebenenfalls Berechtigungen zugestanden werden, damit diese im Hintergrund automatisiert Kontrollaufgaben wahrnehmen können.

EFA Provider

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Auun.01.03}

Ein EFA-Provider ist ein Dienstleister, der EFA-Teilnehmern und Fallaktenmanagern die Dienste der EFA bereit stellt. Er stellt einen expliziten Ansprechpartner für Datenschutzfragen des Versicherten.

Der EFA-Provider verantwortet und betreibt die technischen Dienste der EFA, in ihrer Gesamtheit auch als EFA-Peer bezeichnet, welche die Interaktionsmuster der EFA implementieren.

Datenerhebende und datenverantwortliche Stellen

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Auun.01.04}

Im Normalfall wird eine elektronische Fallakte von einem niedergelassenen (Fach-)Arzt oder von einem Krankenhaus im Rahmen eines bestehenden Behandlungsvertrages eröffnet. Ein EFA-Peer wird immer von einem Provider (Betreiber) betrieben, wobei es sich dabei im Regelfall um ein Krankenhaus handelt. Datenhaltende und somit auch datenverantwortliche Stelle ist hierbei der Provider des für die Eröffnung der Fallakte verwendeten Dienstes. Dieser wird explizit auf der Einwilligung genannt.

Sofern ein Krankenhaus im Kontext einer Fallakte sowohl als EFA-Teilnehmer als auch als EFA-Provider agiert, sind die von diesem Teilnehmer bereitgestellten medizinischen Daten innerhalb einer Fallakte im Regelfall lediglich Verweise (Referenzen) auf die in den Primärsystemen abgelegten medizinischen Daten, weshalb die fachliche und datenschutzrechtliche Verantwortung für die medizinischen Daten bei den jeweiligen originären Erstellern verbleibt.

In der Praxis muss jedoch davon ausgegangen werden, dass ein niedergelassener (Fach-)Arzt nur in Ausnahmefällen über die notwendige technische Infrastruktur verfügt, welches die strengen Anforderungen des eFA-Systems erfüllt. Deshalb werden in diesem Fall die medizinischen Daten über ein Portalsystem an einen Drittanbieter (z.B. EFA-Zwischenspeicher bei einem EFA-Provider) übertragen, dort gespeichert und zugreifbar gemacht. In diesem Falle handelt es sich um eine Auftragsdatenverarbeitung. Der niedergelassene Arzt muss deshalb bei der Nutzung eines Drittanbieters als EFA-Provider zusätzlich zur Einwilligung zur Nutzung der EFA auch eine Einwilligung zu dieser Auftragsdatenverarbeitung erfragen.

Datenverantwortliche Stelle ist in beiden Szenarien die Daten erhebende Stelle, also der niedergelassene Arzt oder das Krankenhaus. Sollte der niedergelassene Arzt, wie oben beschrieben, die medizinischen Daten an einen Drittanbieter ausliefern, so erfolgt dies im Rahmen der Auftragsdatenverarbeitung nach §11 BDSG. Dabei verbleibt die Verantwortung für eine auftragsgemäße und gesetzeskonforme Verarbeitung der Daten durch den Auftragnehmer beim beauftragenden Arzt [nach: §§5, 9, 11 BDSG]. Beachtenswert hierbei ist es jedoch, dass in bestimmten Bundesländern eine Datenoffenbarung bei der Datenverarbeitung im Auftrag untersagt ist und demnach zusätzliche Maßnahmen getroffen werden müssen, sobald Daten an einen Zwischenspeicher kommuniziert werden sollen.

Referenzen und Querverweise

EFA-2.0-Spezifikation
Umsetzung der Rolle des EFA-Providers am Beispiel des UK Aachen (Deutsches Ärzteblatt, Jg. 109, Heft 40, 5.10.2012, S. A1978-80)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Prinzipien für Datenschutz und Datensicherheit

EFA Sicherheitsstrategie

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.01}

Die EFA ist eine zweckgebundene Akte. Der Zugriff auf die Akte ist auf Leistungserbringer beschränkt, die vom Patienten als Behandlungsteilnehmer benannt wurden und die im Kontext dieser Behandlung Patientendaten zu dem an die Akte gebundenen Zweck verarbeiten.

Maßnahmen des Datenschutzes und der IT-Sicherheit müssen daher sicherstellen, dass eine Offenbarung von über die Akte vermittelten Daten nur

gegenüber in die Behandlung einbezogenen Personen und nur
zu dem benannten Zweck erfolgt.

Darüber hinaus bedingt der Charakter der Akte als behandlungsbegleitende Kommunikationsplattform und Grundlage einer gemeinsamen Behandlungsdokumentation, dass

über die Akte nur die für die Behandlung und die Behandlungsdokumentation relevanten Informationen ausgetauscht werden und
die in der Akte enthaltenen Dokumente verlässlich sind in dem Sinne, als dass Urheber und Status der Dokumente für die Nutzer erkennbar ist.

Diese primären Zielstellungen der EFA-Sicherheit werden durch eine von den konkreten Umsetzungsmaßnahmen unabhängige Sicherheitsstrategie aufgefangen. Diese Strategie wiederum wird auf einige wenige elementare und implementierungsunabhängige Sicherheits-Kernkonzepte heruntergebrochen, die jeweils mit im EFA-Sicherheitskonzept oder der EFA-Sicherheitsarchitektur verankerten Maßnahmen hinterlegt sind.

Abgeleitet aus diesen Zielstellungen wird in der EFA eine aus sechs Kernaussagen bestehende Sicherheitsstrategie verfolgt:

Zusammenspiel von Sicherheitskonzept und Sicherheitsarchitektur: Um die spezifizierten Sicherheitsziele zu erreichen, müssen sowohl organisatorische als auch technische Umsetzungswege in Betracht gezogen werden. Basis der IT-Sicherheit der EFA sind ein integriertes, stringentes Sicherheitskonzept und eine von der Anwendung entkoppelte, einfach aufgebaute Sicherheitsarchitektur nach den Vorgaben von ISO-7498-2. Nutzungseinschränkungen und Restriktionen in Bezug auf die Umsetzung der funktionalen Anforderungen können zur Vermeidung technischer Komplexität in Kauf genommen werden.
Lose Kopplung der Sicherheitsdienste untereinander und an die abzusichernden Anwendungsdienste: Sicherheits- und Anwendungsarchitektur werden von einander entkoppelt, um die Komplexität der Systemarchitektur und ihrer Implementierungen zu reduzieren. Alle Sicherheitsdienste müssen anwendungsunabhängig sein. Anwendungsdienste dürfen sich nicht auf bestimmte Implementierungen von Sicherheitsdiensten beziehen.
Sicherheit (z. B. Integrität, Vertraulichkeit, Verbindlichkeit) wird auf der Anwendungsebene als Teil der Kontroll- und Datenflüsse umgesetzt. Kontroll- und Datenflüsse werden gestuft aufgesetzt, um die Integration von Verteidigungslinien entlang der Abläufe zu unterstützen. Verteidigungslinien entlang der Abläufe ermöglichen es datenhaltenden Diensten die Integrität von Nachrichten und Daten sowie die Gültigkeit von Autorisierungen auf Basis lokal verfügbarer Informationen zu verifizieren. Der Zugang zur EFA-Anwendung, der Abruf digitaler Identitäten, der Zugang zu einer Fallakte und der Zugriff auf medizinische Datenobjekte werden als entkoppelte Aktionen aufgefasst, die über unterschiedliche, möglichst voneinander unabhängige Maßnahmen abgesichert werden.

Sicherheitsdienste sind nicht von Eigenschaften der verwendeten Kommunikationsmechanismen abhängig.

Patienteneinwilligung und Needs-To-Know Prinzip als Grundlage aller Berechtigungen: Mechanismen zum Zugriffsschutz basieren auf Identitäten (Individuen und Organisationen). Zugriffsrechte werden ausschließlich an die vom Patienten benannten Behandlungsteilnehmer vergeben, sind synchron zu den fachlichen Zugriffserfordernissen aufgesetzt und gelten immer für eine Fallakte als Ganzes. Berechtigungen werden mit Identitäten verknüpft, indem Rollen des Fachkontextes mit Personen und/oder Organisationen instanziiert werden.
EFA-Policy als Grundlage des Datenaustauschs zwischen autonomen EFA-Netzwerken: Die Vermittlung von Vertrauen, die Abbildung von Sicherheitsrichtlinien und die Weitergabe von Identitätsinformationen zwischen eng integrierten EFA-Netzwerken werden durch eine Föderation dieser Netzwerke realisiert.
Ende-zu-Ende Absicherung des Zugriffs auf medizinische Daten: Ende-zu-Ende-Integrität und Ende-zu-Ende-Vertraulichkeit wird zwischen den Endpunkten "EFA Teilnehmer" und "EFA Datenspeicher (Repository)" hergestellt, um einen sicheren Austausch medizinischer Datenobjekte zu realisieren.
Nutzung der Sicherheitsobjekte, -mechanismen und -maßnahmen der Telematikinfrastruktur: Auch wenn die EFA selber keine Anwendung des § 291a SGB V darstellt, so gelten doch viele der für Anwendungen nach § 291a Absatz 3 SGB V benannten Anforderungen gleichermaßen. Um die parallele und idealerweise integrierte Nutzung von EFA und Anwendungen des § 291a SGB V zu ermöglichen, kann die EFA auf den Basis-Sicherheitsobjekten und -mechanismen der Telematikinfrastruktur (Karten, Kartenleser, Zertifikate, Algorithmen, etc.) aufgesetzt werden. Auch sind weite Teile der Datenschutz- und Sicherheitskonzepte der Telematikinfrastruktur auf die EFA abbildbar und erleichtern so den synergetischen Betrieb und die verzahnte Nutzung von EFA und Telematik-Diensten.

Kernkonzepte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02}

Aus der Sicherheitsstrategie wurden eine Reihe von technisch abgesicherten Kernkonzepten in Bezug auf die Architektur von Fallakten, deren technische Umsetzung und operative Nutzung abgeleitet. Die nachfolgende Abbildung stellt diese Konzepte im Kontext der Sicherheitsstrategie im Überblick dar.

Synchronität von Behandlungsteam und Berechtigungen

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.01}

Als Plattform für eine Behandlungskooperation und gemeinsame Behandlungsdokumentation muss eine Fallakte für alle an der Behandlung aktiv teilnehmenden Personen gleichermaßen zugreifbar sein. Ein Verbergen von Dokumenten für einzelne Teilnehmer oder eine differenzierende Berechtigungsvergabe stehen im Widerspruch zu dieser Zielsetzung der Fallaktennutzung.

Aus diesem Grund erhalten alle vom Patienten in seiner Einwilligungserklärung benannten aktiven Behandlungsteilnehmer die Berechtigung, auf alle in der Akte enthaltenen medizinischen Daten zuzugreifen und auch neue Daten in die Akte einzustellen.

Differenzierte Rollen und Berechtigungen können lediglich für passive Teilnehmer definiert werden, die Sonderrollen - z.B. durch rein administrative Aufgaben in der Verwaltung von Fallakten - ausfüllen. Beispiele hierfür sind im Abschnitt "Akteure und Rollen" aufgeführt.

Zugriffsberechtigungen sind immer an eine komplette Fallakte geknüpft und werden an alle Objekte innerhalb der Fallakte vererbt. Der Patient kann sowohl Einzelpersonen als auch Organisationen bzw. Organisationseinheiten als Behandlungsteilnehmer benennen. Dieses wird 1:1 auf das interne Berechtigungsmangement der EFA abgebildet, d.h. Zugriffsrechte werden dementsprechend entweder an Individuen oder Organisationen als EFA-Teilnehmer gebunden. Im Fall der Berechtigungsvergabe an eine Organisation(seinheit) muss die Zuordnung eines auf die Akte zugreifenden Individuums zu einer berechtigten Organisation und zum Behandlungskontext der Fallakte mit Hilfe eines dezentralen (technisch oder organisatorisch realisierten) Berechtigungsmanagements erreicht werden. Mit der Registrierung bei einem EFA-Provider verpflichtet sich eine Organisation, dieses sicherzustellen.

Die Granularität der für einen EFA-Provider technisch verifizierbaren Authentisierung (Individuum bzw. Organisation) muss auf die Granularität der Zugriffsrechte, die für eine Fallakte definiert sind, abgebildet werden können. Wenn z. B. eine Organisation für den Zugriff auf eine Fallakte autorisiert ist, muss die Zugehörigkeit eines Arztes zu dieser Organisation geprüft werden können, um ihm den Zugang zu gestatten. Dies kann z.B. dadurch erfolgen, dass eine vom EFA-Provider als vertrauenswürdig anerkannte Organisation die Zugehörigkeit des Mitarbeiters zu dieser Organisation in einer Form bestätigt, die vom EFA-Provider als authentisch und nachvollziehbar verifizierbar ist.

Ungeachtet dessen muss jede Authentisierung auf eine natürliche Person rückführbar sein, die auch im an die EFA-Dienste übermittelten Authentisierungsnachweis benannt sein muss und auch im Audit Trail vermerkt wird. D.h. auch wenn eine Autorisierung auf Ebene einer Organisation erfolgt, so bedeutet dies nicht, dass die handelnde natürliche Person gegenüber der EFA anonym bleibt.

Übertragbarer Sicherheitskontext

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.02}

Der Sicherheitskontext eines EFA-Teilnehmers wird durch dessen Identitätsdaten, einen Nachweis der Authentizität und die im aktuellen Nutzungsszenario geltenden Zugangs- und Zugriffsberechtigungen des Teilnehmers beschrieben. Ein im aktuellen Zugriffsszenario gültiger Sicherheitskontext wird über eine Menge von aufeinander aufbauenden Sicherheitsnachweisen (Assertions) kodiert. Die nachfolgende Grafik veranschaulicht dieses Prinzip:

der EFA-Teilnehmer authentisiert sich gegenüber einem vertrauenswürdigen lokalen oder als dediziertem Plattformdienst aufgesetzten Identity Provider.
der Identity Provider fasst die vom EFA Berechtigungsmanagement benötigten Identitätsdaten des Teilnehmers zu einem Sicherheitsnachweis (HP Identity Assertion) zusammen und versieht diesen mit einer für alle EFA-Dienste verifizierbaren Signatur.
sofern die Option der Pseudonymisierung von Registerdaten aktiviert ist, wird im nächsten Schritt eine sog. Admission Assertion erzeugt, die benötigt wird, um das für den Datenzugang benötigte Pseudonym des Patienten aufzulösen. Die zuvor ausgestellte HP Identity Assertion wird nicht nur für die Generierung des Pseudonyms benötigt, sondern dient auch der Absicherung, dass die bei der Pseudonymgenerierung verwendeten Daten authentisch sind.
die EFA unterstützt u.a. das sog. "Policy Push" Verfahren, bei dem der EFA-Teilnehmer von einem dedizierten Dienst seine aktuell gültigen Berechtigungen abruft. Die Authentisierung und Identifizierung gegenüber diesem Dienst erfolgt über die HP Identity Assertion bzw. im Fall pseudonymer Registerdaten über die Admission Assertion. Die Berechtigungen werden in einem Berechtigungsnachweis (Policy Assertion)zusammengefasst, der fest mit der HP Identity Assertion verknüpft ist. Ein Berechtigungsnachweis ist nur zusammen mit einem auf den selben Nutzer ausgestellten authentischen Identitätsnachweis gültig.
Alle entlang der Kette eingesammelten und miteinander verknüpften Assertions werden beim AUfruf eines Fachdiensts übergeben. Dieser prüft die Authentizität der Assertions, die Authentizität des EFA-Teilnehmers und setzt anschließend die in der Policy Assertion kodierten Berechtigungen des Nutzers durch.

Durch diese Verkettung von Sicherheitsnachweisen wird faktisch der beim Aufrufer gültige Sicherheitskontext an einen Fachdienst übermittelt und kann dort zur Prüfung und Durchsetzung von Berechtigungen rekonstruiert werden.

Deklarative Sicherheit

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.03}

Sicherheitsfunktionen zur Erfüllung von Anforderungen an die Vertraulichkeit und Authentizität von geschützten Daten folgen oftmals dem gleichen Muster: Eine die geschützte Ressource kapselnde Anwendung erhält einen Dienstaufruf. Der Aufrufende muss authentisiert und anschließend autorisiert werden. Dies führt zum Zugriff auf entsprechende Ressourcen oder eben nicht. Hier liegt es nahe, solche wiederkehrende Aufgaben in Security Frameworks auszulagern und zu beschreiben (deklarieren), welche Sicherheitsfunktionen zu aktivieren sind, um einer übergeordneten Sicherheitsstrategie gerecht zu werden. Die Ausübung dieser Sicherheitsfunktionen ist dann Sache des Frameworks. Dieser Schutzziele und Sicherheitsdienste betonende deklarative Sicherheitsansatz steht im Gegensatz zur programmierten Sicherheit, bei der konkrete Sicherheitsmechanismen und –objekte fest an die Implementierung der Anwendungslogik gebunden werden. Ziel ist es hierbei immer, die für eine Komponente oder Kommunikationsbeziehung geltenden Sicherheitsziele zu beschreiben und die Auswahl des geeigneten Mechanismus dem Framework zu überlassen.

Die Nutzung deklarativer Sicherheit bietet eine Reihe von Vorteilen:

Sicherheitsdienste und –mechanismen können ohne Änderungen am Code der Anwendungsdienste weiterentwickelt und an neue Anforderungen angepasst werden
In einem Framework enthaltene Stubs der Sicherheitsdienste können sehr einfach an bestehenden Anwendungen angebunden werden. Hierdurch wird eine Entkopplung von Sicherheitsdiensten - z. B. für Authentifizierung und Autorisierung – unterstützt
Die Kongruenz der Umsetzung von Sicherheit zu ihrer Spezifikation und einer übergeordneten Sicherheitsrichtlinie ist explizit gegeben, d. h. deklarative Sicherheit kann unmittelbar aus dem Sicherheitskonzept abgeleitet werden
Die umgesetzten Sicherheitsmechanismen und die genutzten Objekte werden an der Schnittstelle der Dienste sichtbar und damit überprüfbar.

Die Sicherheitsdienste der EFA v2.0 setzen wo immer machbar und sinnvoll Konzepte einer deklarativen Sicherheit um.

Policy Enforcement dicht an den Ressourcen

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Pziee.02.04}

Sofern die Organisation eines EFA-Teilnehmers nicht selbst als EFA-Provider fungiert, erfolgt die Bereitstellung von Daten dieses Teilnehmers über einen Provider den Tatbestand einer Auftragsdatenverarbeitung. Dieses legt dem Teilnehmer besondere Pflichten in der Auswahl des Providers auf; gleichzeitig muss der Provider für die im Auftrag verwalteten Daten ein den regulativen Vorgaben genügendes Niveau an Datenschutz und Datensicherheit sicherstellen.

Insbesondere in einem weitgehend auf gegenseitigem Vertrauen der EFA-Peers basierenden Verbund stellt dies große Herausforderungen, da letzten Endes jeder Provider nur die Sicherheitszusagen machen kann, die er auch selbst technisch, organisatorisch und/oder juristisch durchsetzen kann.

Um den Provider entsprechend zu befähigen, gilt für die EFA, dass jeder Provider für die bei ihm vorgehaltenen Daten für die Prüfung und Durchsetzung der aus der Patienteneinwilligung abgeleiteten Zugriffsberechtigungen verantwortlich ist und diese auch selbst durchführen muss. Zusätzlich ist jeder Provider für die korrekte Abbildung der Angaben aus der Patienteneinwilligung (insb. berechtigte Teilnehmer) auf sein Zugriffskontrollsystem verantwortlich. Da hierzu eine Verarbeitung von potenziell über andere Akteure erhobene Daten unabdingbar ist (z.B. von einem anderen Provider bestätigter Nachweise einer Nutzer-Authentisierung oder gegenüber einem Arzt gegebene Einwilligung) ist es unabdingbar, dass die Systemteilnehmer untereinander die gegenseitige Vertrauensstellung ausreichend absichernde vertragliche Bindungen eingehen.

Referenzen und Querverweise

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

EFA als Instanz des GDD Referenzmodells

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {KeAk.01}

Die EFA ist ein Gesundheitsdatendienst (GDD) und damit eine Instanz des GDD-Referenzmodells. Dies bedeutet:

im Mittelpunkt eines GDD steht die Vermittlung geschützter Ressourcen zwischen Leistungserbringern. Im Fall der EFA sind diese Ressourcen die einzelnen Fallakten, auf die berechtigte Leistungserbringer im Rahmen der Behandlung medizinischer Fälle zugreifen.
die Vermittlung der Ressource wird durch eine Anwendung realisiert, die von einem oder mehreren GDD-Anbietern bereit gestellt wird. Im Fall der EFA bilden die EFA-2.0-konformen, über EFA-Peers realisierten Fachdienste die Anwendung "EFA" während die Rolle der GDD-Anbieter durch die EFA-Provider ausgefüllt wird.
sämtlicher Datenaustausch findet innerhalb eines über alle Akteure gespannten Sicherheitskontextes statt. Im Fall der EFA bildet die Patienteneinwilligung die konzeptuelle Basis dieses gemeinsamen Kontextes. Die technische Umsetzung erfolgt durch zwischen den Akteuren ausgetauschte Sicherheitsnachweise.

In den nachfolgenden Abschnitten wird beschrieben, wie diese Vorgaben des GDD-Referenzmodells innerhalb des EFA-Informationsmodells konkret umgesetzt sind.

Kontext

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {KeAk.01.01}

Nach den Vorgaben des GDD-Referenzmodells sind sämtliche Operationen zur Verarbeitung der Ressource (d.h. der Fallakten und ihrer Daten) in einen Sicherheitskontext eingebettet, der potenziell alle beteiligten IT-Systeme umspannt. Konkret bedeutet dies, dass der Sicherheitskontext des Nutzers an seinem Arbeitsplatz in der Klinik auf Seiten der EFA-Dienste beim EFA-Provider so rekonstruiert werden kann, dass es für den Nutzer so aussieht, als ob würden die EFA-Dienste in seinem lokalen Sicherheitskontext auf seinem Arbeitsplatzsystem laufen (und umgekehrt: Für die EFA-Dienste ist es vollkommen egal wo der Nutzer sitzt, da die die Dienste immer in dem Sicherheitskontext laufen, in dem sich der Nutzer gerade befindet).

Um einen solchen Sicherheitskontext zu realisieren, werden alle für diesen Kontext relevanten Informationen zur Identität und zu den Berechtigungen des Nutzers in sog. Sicherheitsnachweisen (Assertions) gekapselt. Diese Nachweise enthalten verifizierbare, zuverlässige Aussagen darüber, wer der Nutzer ist und was er im Rahmen der Nutzung einer Ressource für Berechtigungen besitzt. Jedes IT-System im EFA-Verbund kann anhand der Sicherheitsnachweise den gleichen Sicherheitskontext aufbauen - unabhängig davon wo und in welchem Zuständigkeitsbereich das Identitäts- und Berechtigungsmanagement realisiert sind.

Für die konkreten Verfahren zur Vermittlung und Absicherung von Sicherheitsnachweisen gibt es verschiedene Paradigmen, die im wesentlichen davon abhängen, ob ein Sicherheitskontext bereits zu Beginn einer Anwendungsnutzung vollständig aufgebaut wird oder ob dieser Aufbau schrittweise erfolgt, wenn die einzelnen Nachweise benötigt werden (und dann ggf. auch nur auf den Systemen, die diese Nachweise auch wirklich benötigen). Im IHE White Paper "Access Control" werden z.B. die Strategien "Policy Push" (Client baut den vollständigen Kontext auf) "Policy Pull" (Aufbau des Kontextes erfolgt on demand beim Dienstanbieter) beschrieben, die auch beide von der EFA unterstützt werden.

EFA-Anwendung und EFA-Peers

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

Eine Anwendung im Sinne des GDD-Referenzmodells ist eine von einem Anbieter betriebene Instanz eines Dienstes, der definierten Vorgaben - insbesondere zur angebotenen Funktionalität - genügt. Anwendungen bedürfen einer Zulassung, die sich über verschiedene Ebenen - Konzeption/Spezifikation, Implementierung/Produkt, Betrieb/Einsatz - erstrecken kann.

Jeder von einem EFA-Provider betriebene EFA-Peer ist eine solche Anwendung.
Die Spezifikationen der EFA werden durch den EFA-Verein verantwortet. Dieser stellt die Konformität der Spezifikationen zu den regulativen Rahmenbedingungen in Deutschland sicher. Der EFA-Verein vergibt verschiedene Konformitätssiegel für den Spezifikationen entsprechende Produkte. Idealerweise setzen entsprechende Konformitätsprüfungen auf in IHE Connectathons erworbenen "conformace statements" auf und stellen im Kern lediglich die richtige Umsetzung der in der EFA-Spezifikation festgelegten Einschränkungen und Erweiterungen auf den verschiedenen IHE-Profilen fest.
Der Einsatz einer EFA in einem regionalen Gesundheitsnetz bedarf der Freigabe durch den zuständigen Landesdatenschutz. Dieser prüft insbesondere die vollständige Umsetzung des für alle EFA-Betreiber maßgeblichen EFA-Datenschutzkonzepts.

Anwendungen sind diskriminierungsfrei im Rahmen definierter Regeln nutzbar. Anwendungen eines GDD können in mehreren Instanzen von verschiedenen Anbietern aufgesetzt und zur Nutzung angeboten werden. Der Nutzer ist frei in der Wahl des Anbieters wobei jedoch je nach Art des GDD die Vorgaben zur Wahl eines Dienstleisters im Rahmen einer Auftragsdatenverarbeitung zu beachten sind.

Die Spezifikationen der EFA können von jedem Anbieter umgesetzt werden. Jeder Anbieter, der die rechtlichen Vorgaben zum Schutz der verwalteten und ausgetauschten EFA-Daten nachweisbar einhält, kann am Markt als EFA-Provider agieren.
EFA-Teilnehmer können im Rahmen ihrer Berechtigungen auf alle Fallakten und Fallaktendaten lesend zugreifen - unabhängig davon auf welchem EFA-Peer und von welchem EFA-Provider diese bereit gestellt werden.
EFA-Teilnehmer können frei wählen, bei welchem Provider sie selber Fallakten anlegen bzw. die von ihnen in Fallakten eingestellten Daten verwaltet werden.

Ein EFA-Teilnehmer greift über den EFA-Provider auf das EFA-Netzwerk zu, mit dem er einen Vertrag über die Vorhaltung der selbst angelegten Fallakten und selbst eingestellten Daten geschlossen hat. Die Dienstadressen des von diesem Provider angebotenen EFA-Peer sind Bestandteil der statischen EFA-Konfiguration des Teilnehmers. EFA-Teilnehmer, die nicht an einen Provider gebunden sind, können nur lesend auf Fallakten zugreifen. Sie können als Einstiegspunkt in ein EFA-Netzwerk grundsätzlich jeden an dieses Netz angebundenen Peer nutzen, sofern dieser in der Lage ist die Authentizität des beim Nutzer aufgebauten Teils des Sicherheitskontextes (s.o.) zu prüfen. Die Dienstadressen von einem oder mehreren solcher EFA-Peers sind Bestandteil der statischen EFA-Konfiguration des Teilnehmers.

Ressourcen der EFA

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {KeAk.01.03}

Das EFA Geschäftsobjekt "Fallakte" bildet im Sinne des GDD-Referenzmodells die Ressource der EFA. Berechtigungen und Nutzungseinschränkungen sind ausschließlich an Objekte dieser Klasse gebunden und werden auf nachgeordnete Objekte (Partitionen, Datenobjekte) vererbt.

EFA-Ressourcen haben per se einen hohen Schutzbedarf, da Szenarien, die einen sehr hohen Schutzbedarf bedingen würden, explizit von der Umsetzung über eine EFA ausgeschlossen sind. Die hierzu definierten Maßnahmen sind im EFAv1.2-Datenschutzkonzept beschreiben.

Referenzen und Querverweise

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Hierarchisches Informationsmodell der EFA

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eehä.01}

Das Informationsmodell der EFA hat die Klassen Patient, Einwilligungserklärung, Fallakte, Partition sowie medizinisches Datenobjekt:

Ein Patient kann beliebig viele Fallakten haben. Eine Fallakte gehört zu genau einem Patienten. Ein Patient darf nicht mehr als eine Fallakte mit der gleichen Zweckbindung haben.
Jede Patient-Fallakte-Beziehung wird mit genau einer Einwilligungserklärung legitimiert. Eine Einwilligungserklärung bezieht sich auf genau eine Fallakte und deren untergeordneten Geschäftsobjekte Partition und medizinisches Datenobjekt.
Eine Fallakte kann beliebig viele Partitionen haben. Eine Partition gehört zu genau einer Fallakte.
Eine Partition kann beliebig viele medizinische Datenobjekte enthalten. Ein medizinisches Datenobjekt kann muss zu mindestens einer Partition gehören.

Mit EFA v2.0 ist es nicht zulässig, dass die in der Einwilligungserklärung des Patienten benannten EFA-Provider mehrere Fallakten zum gleichen Zweck für diesen Patienten führen und so das Prinzip der vollständigen Dokumentation des medizinischen Falls verletzen. Während Berechtigungen in EFA v1.2 den Zugriff auf eine bestimmte Fallakte regeln, müssen Berechtigungen in EFA v2.0 den Zugriff auf die Beziehung Patient-zu-Zweck regeln. Soll dennoch eine Fallakte zum gleichen Zweck angelegt werden, um beispielsweise eine Zweitmeinung einzuholen, dann muss diese Fallakte mit dem entsprechenden Zweck (z. B. "Zweitmeinung") erstellt werden.

Da der in der eFA Version 1.2 für Partitionen genutzte Begriff des "Ordners" auch für Strukturierungselemente in für den Nutzer generierten Sichten genutzt wurde und jetzt zusätzlich auch noch im IHE Cookbook mit dem technischen Konstrukt des XDS-Ordners gleichgesetzt ist, wird in der EFA 2.0 Spezifikation zur Wiederherstellung begrifflicher Klarheiten wieder auf den in der ersten EFA Spezifikation benutzten und konzeptionell passendsten Begriff "Partition" zurückgegriffen. Für diese Spezifikation gilt damit grundsätzlich:

Eine Partition bezeichnet einen Speicherbereich, in dem Dokumente bei einem EFA-Provider verwaltet werden. Die Semantik dieses Speicherbereich bestimmt derjenige, der diesen anlegt und darin von ihm verantwortete Dokumente einstellt. Üblicherweise wird man versuchen, eine Korrespondenz zwischen einer Partition und einer Behandlungsepisode herzustellen. Partitionen sind damit "physikalische" Objekte der EFA.
Ein Ordner bezeichnet ein Strukturierungselement in für den Nutzer generierten Sichten auf eine Fallakte. Ob diese Strukturierung anhand von Partitionszugehörigkeiten oder Metadaten der in einer Fallakte zusammengefassten Dokumente erfolgt, ist in der EFA-Spezifikation nicht reglementiert. Ordner sind damit rein "logische" Konstrukte für die Visualisierung von Fallakten.

Klasse Patient

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eehä.01.01}

Die Klasse "Patient" ist in der IHE-ACS-Domäne patient angesiedelt und bindet alle zur Identifikation des Patienten erforderlichen Informationen sowie die Einwilligungserklärung(en) des Patienten zur Führung einer Fallakte.

Klasse Fallakte (Medizinischer Fall)

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

Eine Fallakte bildet einen konkreten Behandlungskontext wie z.B. einer konkrete Erkrankung oder einen bestimmten Versorgungsvertrag zwischen dem Patienten und den behandelnden Einrichtungen auf eine Zweckbindung ab. Der der Fallakte zugrunde liegende medizinische Fall determiniert, welche Arten von Dokumenten über eine Fallakte ausgetauscht werden können. Zusätzlich können in strukturierten Versorgungskontexten ggf. bereits aus dem medizinischen Fall auch Einschränkungen bezüglich der berechtigten EFA-Teilnehmer abgeleitet werden.

Die Klasse "Fallakte" verbindet die IHE-ACS-Domänen resource und application und spiegelt damit wider, dass eine Fallakte sowohl Plattform als auch Anwendung ist:

das generische Konstrukt einer zweckgebundenen Akte ist eine resource im Sinne der gleichnamigen IHE-ACS-Domäne.
eine standardisierte, diagnose-spezifische Ausprägung einer Fallakte (z.B. eine Herz-Akte) ist zusätzlich eine Anwendung (application) im Sinne des IHE-ACS-Domänenmodells, da in diesem Fall eine vordefinierte Nutzungssemantik besteht, aus der heraus sich spezifische Anforderungen und Einschränkungen an den Zugang zu der resource der Fallakte und deren Inhalte ableiten.

Verteilung von Fallakten über mehrere EFA-Provider

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eehä.01.02.01}

Die hier beschriebene Semantik ist jedoch rechtlich nur innerhalb eines EFA-Providers abbildbar, da ansonsten zwischen Providern abgefragt werden müsste, ob ggf. bei einem anderen Provider schon eine Fallakte zum selben Zweck besteht. Eine solche Abfrage ist durch die Einwilligung des Patienten nicht abgedeckt, da es unmöglich ist, in der Einwilligung alle Provider zu benennen, die angefragt werden. Daher ist eine solche Abfrage nicht zulässig.

Um die konsistente Semantik der engen Korrespondenz von Zweck und Fallakte aufrecht zu erhalten, ohne die Essentials der EFA-Sicherheit zu unterlaufen, wird folgendes Vorgehen für verteilte Fallakten definiert:

Bei Anlage einer neuen Fallakte bei einem EFA-Provider prüft dieser Provider, ob bereits für diesen Patienten eine Fallakte zum benannten Zweck angelegt ist. Ist dies der Fall, wird die neue Akte der bestehenden Akte als Partition hinzugefügt, sofern dies durch die beiden Einwilligungen abgedeckt ist.
Eine neue Fallakte wird beim Provider nur angelegt, wenn nicht bereits eine Akte des Patienten zum selben Zweck bei diesem Provider existiert. Eine Anfrage, ob eine solche Akte bei einem anderen Provider existiert, erfolgt nicht.
In der Konsequenz resultiert dies in zwei Akten bei zwei Providern, die zwar den selben Zweck erfüllen sollen, denen aber unterschiedliche Einwilligungserklärungen zugrunde liegen und für die entsprechend auch unterschiedliche Teilnehmer berechtigt sein können. Dieses ist im Einklang mit den Essentials der EFA-Sicherheit, da hierdurch jeder Provider in der Lage ist, "seine" Einwilligung durchzusetzen. Um jedoch das essentielle Grundkonzept der EFA - nur eine Fallakte pro Zweck - durchzusetzen, muss in einem solchen Szenario eine Zusammenführung der Akten und Einwilligungen erfolgen, da ansonsten keine der beiden "Halb-Akten" seinen medizinischen Mehrwert entfalten kann.
Wenn Aktenteile zusammengeführt werden sollen, die bei verschiedenen Providern geführt werden, muss für die Aktenteile eine Einwilligung des Patienten vorliegen, die das Zusammenführen erlaubt.
Die betroffenen Provider stellen eine geeignete Verknüpfung zwischen den verteilt vorgehaltenen Teilen der Fallakte her, die es den berechtigten Nutzer ermöglicht, alle in der Akte enthaltenen Daten zu sehen und auf diese zuzugreifen.

Klasse Partition

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eehä.01.03}

Kliniken und Ärzte nutzen jeweils spezifische Mechanismen zur internen Zusammenführung von medizinischen Daten, z.B. Abrechnungsfälle, Quartale oder Patientenkontakte. Insbesondere in Krankenhäusern mit einer weitgehend automatisierten Steuerung von Datenflüssen kann die Registrierung von Dokumenten an einer EFA vereinfacht werden, wenn sich ein solcher Strukturierungsmechanismus 1:1 auf ein Konstrukt des EFA-Informationsmodells abbilden lässt. In einem solchen Fall können intern freigegebene Dokumente bei ihrer Zuweisung zu einem internen Strukturierungsmechanismus automatisiert an dem korrespondierenden EFA-Konstrukt registriert und damit in die übergeordnete Fallakte eingestellt werden.

Diese skizzierte Rolle übernimmt in der EFA das Konstrukt der Partition. In Analogie zu dem gleichnamigen Konzept des UNIX-Dateisystems ist eine Partition ein eigenständiger Speicherbereich, der einen Teil einer gesamten Datenmenge vorhält aber auch autonom existieren kann.

Die konkrete Semantik einer Partition ist bei der EFA weitgehend frei definierbar, wodurch sie an beliebige bestehende Strukturierungsmechanismen gebunden werden kann. Somit kann eine Fallakte im einfachsten Szenario aus nur einer einzigen Partition bestehen, in die alle EFA-relevanten Daten eingestellt werden. In komplexeren Szenarien können jedoch in einer Fallakte Partitionen für einzelne Klinikaufenthalte und einzelne teilnehmende niedergelassene Ärzte angelegt werden, um eine IT-gesteuerte Filterung und Bereitstellung von Dokumenten aus diesen Einrichtungen zu unterstützen. Die gegebenen Freiheitsgrade erlauben es aber z.B. auch einem niedergelassenen Radiologen eine Partition in einer EFA anzulegen und diese mit einer internen Auftragsnummer zu verknüpfen. Alle Dokumente, die im Rahmen des Auftrags erstellt werden, können so automatisiert der richtigen Fallakte zugeordnet und an dieser registriert werden.

Da Partitionen lediglich ein Konstrukt zur Vereinfachung des Einstellens von Daten in eine Fallakte sind, sind sie auch üblicherweise dem Nutzer gegenüber verborgen.

Die Klasse "Partition" bildet im IHE-ACS-Modell eine Ressource, d.h. sie trägt weder eine Anwendungssemantik noch eigene Berechtigungen. Beides wird von der logisch übergeordneten Fallakte geerbt. Technisch gesehen können Partitionen auch ohne Fallakte existieren, aufgrund der fehlenden Semantik und Teilnehmer-Autorisierungen sind sie dann jedoch nicht als Fallakte nutzbar.

Klasse Datenobjekt

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eehä.01.04}

Datenobjekte bilden die Blätter des EFA-Informationsmodells. Datenobjekte sind atomar und jeweils eindeutig einem Patienten zugeordnet. Jedes Datenobjekt ist mindestens einer Partition zugeordnet. Aktuell werden von der EFA ausschließlich Dokumente als Datenobjekte unterstützt.

Datenobjekte können zueinander in Beziehung stehen. Diese Beziehungen werden explizit festgelegt und sind für EFA-Teilnehmer sichtbar. Die folgenden Beziehungen zwischen Datenobjekten werden von der EFA v2.0 unterstützt:

Ergänzen eines Dokuments: Ein Dokument stellt eine Ergänzung eines anderen Dokuments dar (z.B. Befund zum Bild).
Ersetzen/Aktualisieren eines Dokuments: Ein Dokument ersetzt ein benanntes anderes Dokument. Das ersetzte Dokument wird (einschließlich seiner Ergänzungen/Anhänge) invalidiert und beim Abruf von Dokumenten aus einer Fallakte nur für bestimmte Rolleninhaber (z.B. Fallaktenmanager) bereitgestellt. Für alle anderen Teilnehmer ist nur noch das neue Dokument sichtbar. Dieses enthält jedoch einen Verweis auf das ersetzte Dokument.

Klasse Einwilligungserklärung

Siehe Patienteneinwilligung zur EFA.

Die Einwilligungserklärung hat verschiedene Ausprägungen:

menschenlesbar in Papierform,
menschenlesbar als elektronisch ausgefülltes Formular,
menschenlesbar als Scan der Papierform und
maschinenlesbar.

Klasse Berechtigungstoken

Ein Berechtigungstoken ist eine Fallaktenkennung, die ein Patient einem Arzt geben kann, damit sich dieser zugriffsberechtigter Teilnehmer der Fallakte registrieren kann. Der Patient kann das Berechtigungstoken von einem EFA-Teilnehmer erhalten. Das Einlösen des Berechtigungstokens durch einen Arzt an kann an bestimmte Bedingungen geknüpft werden, beispielsweise die Fachrichtung des Arztes oder einen Gültigkeitszeitraum.

Klasse EFA-Teilnehmer

Diese Klasse repräsentiert den Akteur EFA-Teilnehmer. in EFA-Teilnehmer ist eine in der Einwilligung des Patienten benannte Organisation oder Person, die in die Behandlung des Patienten eingebunden ist. EFA-Teilnehmer müssen bei ihrer Benennung in der Einwilligung des Patienten eindeutig identifiziert werden und grundsätzlich zur Nutzung einer EFA befähigt sein.

Alle EFA-Teilnehmer sind über die Einwilligung gleichermaßen zur Nutzung einer gemeinsamen Fallakte autorisiert und können über diese eine gemeinsame Behandlungsdokumentation führen und/oder erforderliche Informationen austauschen. Durch die Zuweisung einer EFA-Rolle zu einem EFA-Teilnehmer können diese ungeachtet des einheitlichen Zugangs zu den über die EFA ausgetauschten medizinischen Daten unterschiedliche administrative Berechtigungen erhalten.

Klasse EFA-Nutzer

Ein EFA-Nutzer ist eine Person, die im Rahmen des konkreten Einsatzes einer Fallakte die Berechtigung eines EFA-Teilnehmers wahrnimmt und damit auch die Rolle dieses EFA-Teilnehmers instanziiert. Sofern der EFA-Teilnehmer eine Person ist, kann nur diese Person als EFA-Nutzer in der Rolle dieses Teilnehmers agieren. Ist als EFA-Teilnehmer eine Organisation benannt, können alle Mitglieder dieser Organisation gemäß organisationsinternen Vorgaben und vorbehaltlich ihrer Einbindung in die Behandlung als EFA-Nutzer in der Rolle des EFA-Teilnehmers agieren.

Klasse EFA-Provider

Diese Klasse repräsentiert den Akteur EFA-Provider.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Interaktionsmuster der EFA

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Irti.01}

Arbeiten mit Fallakten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Irti.01.01}

Muster	Umsetzung
Auffinden der Fallakten eines Patienten Das Muster beschreibt wir ein Arzt bei einem EFA-Provider nach Fallakten eines Patienten sucht und eine Akte für die weitere Nutzung auswählt.
Browsing über eine Akte Das Muster beschreibt, wie ein berechtigter Teilnehmer Informationen zu den in einer Akte verwalteten Dokumenten abrufen kann, so dass diese anschließend in geeigneter Weise in seinem Primärsystem aufbereiten werden können.
Abruf von Datenobjekten Das Muster beschreibt, wie ausgewählte Dokumente von einem Arzt aus der Fallakte in ein Primärsystem übernommen werden.
Einstellen von Datenobjekten Das Muster beschreibt, wie berechtigte Teilnehmer in einem Primärsystem erfasste Daten in eine Fallakte einspielen können. Die Daten werden hierdurch für alle anderen berechtigten Teilnehmer der Fallakte zugänglich.
Invalidieren von Datenobjekten Das Muster beschreibt, wie ein zuvor an einer Fallakte registriertes Datenobjekt invalidiert werden kann, so dass alle anderen Teilnehmer davon in Kenntnis gesetzt sind, dass dieses Objekt nicht weiter verwendet werden soll.

Verwaltung von Fallakten

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

Muster	Umsetzung
Anlegen einer Fallakte Das Muster beschreibt die Anlage einer Fallakte auf Basis einer Einwilligung des betroffenen Patienten. Varianten des Musters beschrieben, wie zum selben Zweck angelegte Akten integriert werden.
Anlegen und Registrieren einer Partition Das Muster beschriebt, wie zu einer bestehenden Fallakte weitere Partitionen - z.B. zur Zusammenfassung der im Rahmen eines stationären Aufenthalts erhobenen Daten - angelegt werden können.
Schließen einer Fallakte Das Muster beschriebt das explizite Schließen einer Fallakte, z.B. aufgrund der Rücknahme der Einwilligung durch den Patienten.
Ändern/Aktualisieren einer Einwilligung Das Muster beschreibt die Anpassung des Teilnehmerkreises einer EFA aufgrund einer veränderten Behandlungssituation oder einer Änderung der Einwilligung des Patienten. Varianten dieses Musters erlauben auch die Konkretisierung des Zwecks einer EFA sowie die Anpassung des Gültigkeitszeitraums.
Autorisierung eines weiteren Teilnehmers Das Muster beschreibt, wie der Patient ergänzend zur bestehenden Einwilligung weitere Ärzte bzw. Einrichtungen zur Teilnahme an einer EFA berechtigen kann (z.B. durch Nutzung eines Offline-Tokens). Varianten dieses Musters erlauben auch die Rücknahme einer solchen Einzelautorisierung.
Zusammenführen von Fallakten Das Muster beschreibt, wie ein Arzt zwei Fallakten eines Patienten zu einer Fallakten zusammenführen kann.

Referenzen und Querverweise

EFA-2.0-Spezifikation
Interaktionsmuster: Auffinden der Fallakten eines Patienten
Interaktionsmuster: Browsing über eine Akte
Interaktionsmuster: Abruf von Datenobjekten
Interaktionsmuster: Einstellen von Datenobjekten
Interaktionsmuster: Invalidieren von Datenobjekten
Interaktionsmuster: Anlegen einer Fallakte
Interaktionsmuster: Anlegen und Registrieren einer Partition
Interaktionsmuster: Schließen einer Fallakte
Interaktionsmuster: Anpassen des Teilnehmerkreises

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Interaktionsmuster zum Anlegen einer EFA

Anwendungsszenario: Anlegen einer Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngea.01.01}

Vorbedingungen

Der Arzt ist ein behandelnder Arzt des Patienten.
Der Arzt kann die Identität des Patienten vertrauenswürdig feststellen.
Ein kooperatives Behandlungsszenario mit der Erfordernis eines effizienten Datenaustauschs zwischen den behandelnden Einrichtungen liegt vor.
Für die Diagnose und den eingeschlagene Behandlungspfad eignet sich für eine Fallakte.

Ablauf

Der Arzt informiert den Patienten über die Fallakte. Er nennt die Vorteile und Risiken der Nutzung der Fallakte und erklärt, welche Daten zwischen welchen Akteuren ausgetauscht werden. Er weist den Patienten darauf hin, dass die Anlage der Fallakte ein freiwilliges Angebot ist und dass er jederzeit die Schließung der Akte verlangen kann ohne dass es einen Abbruch der Behandlung zur Folge hat.
Der Arzt stimmt mit dem Patienten die Modalitäten zur Nutzung der Fallakte ab. Der Zweck der Fallakte wird möglichst konkret erfasst und es wird das Verfallsdatum der Fallakte festgelegt. Hierbei müssen die Vorgaben des regionalen EFA-Verbunds eingehalten werden.
Der Arzt stimmt mit dem Patienten den initialen Kreis der EFA-Teilnehmer ab. Hierfür erläutert der Arzt, welche Fachdisziplinen und Einrichtungen idealerweise in die Behandlung und damit auch in die Teilnahme an der EFA eingebunden sein sollten.
Der Arzt authentifziert den Patienten. Das heißt er stellt dessen Identität vertrauenswürdig ggf. auch mit organisatorischen Mitteln fest.
Der Arzt überführt die Daten der Einwilligungserklärung in ein elektronisches Formular, wenn sie zunächst schriftlich erfasst wurden.
Der Patient unterschreibt die Einwilligungserklärung eigenhändig in papierform und gibt sie dem Arzt.
Der Arzt bestätigt die Richtigkeit der Angaben, die Datenschutzkonformität des Ablaufs der Einwilligungserteilung und das Vorhandensein der vom Patienten unterschriebenen Kopie.
Der Arzt übermittelt die für die Anlage der Akte erforderlichen Informationen einschließlich einer Kopie der Einwilligung an einen EFA-Provider.
Der EFA-Provider legt in einem Aktensystem eine Fallakte gemäß den Vorgaben des Arztes an. Die Berechtigungen zum Zugriff auf die Akte werden gemäß den Vorgaben der Einwilligungserklärung aufgesetzt.

Ergebnis: Die Fallakte ist verfügbar. Ihre Konfiguration entspricht den Daten der Einwilligungserklärung und den Vorgaben des Arztes.
Ausnahmen

Der Patient willigt nicht in die Nutzung der Fallakte ein.
Für den Patienten existiert bereits eine Fallakte zum medizinschen Fall.

Varianten des Anwendungsszenarios

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

Aktuell sind keine Varianten definiert

Abbildung der Szenarien und Varianten auf Interaktionsmuster

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngea.01.03}

Interaktion
Funktionalität, Vorbedingungen, Nachbedingungen	Vorbedingungen: Die Einwilligung des Patienten zur Anlage und Nutzung einer Fallakte liegt vor. Die an der Behandlung teilnehmenden Ärzte und Einrichtungen sind identifiziert. Der Patient ist eindeutig identifiziert und authentisiert (ggf. organisatorisch). Funktionalität: Eine neue Fallakte wird für einen Patienten zu einem definierten Zweck angelegt. Die an der Behandlung teilnehmenden Ärzte und Einrichtungen werden als EFA-Teilnehmer registriert und autorisiert. Nachbedingungen: Eine neue Fallakte ist angelegt und kann von den EFA-Teilnehmern genutzt werden. Sofern elektronisch verfügbar, ist die Einwilligung als Dokument aus der Akte abrufbar. Die Einwilligungserklärung und Stammdaten sind ggf. auch zur korrekten Identifikation des Patienten zu nutzen. Verpflichtungen: Es ist nachvollziehbar, welche Person die Akte auf welcher Basis und in welcher Konfiguration angelegt hat.
Muster	Muster Fallakte anlegen Bereit gestellte Informationen: Patient (identifizierende Daten) Zweck der Akte Teilnehmer der Akte (identifizierende Daten, Rollen bzw. Autorisierungen) Gültigkeit der Akte elektronisches Einwilligungsdokument oder Bestätigung des Arztes, dass eine solche Einwilligung vorliegt Erforderliche Konfigurationsdaten: EFA Provider

Definition der Interaktionsmuster

Interaktionsmuster: Fallakte anlegen

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngea.01.04.01}

Motivation	Anlegen einer neuen Fallakte zu einem definierten Zweck.
Akteure und Rollen	Leistungserbringer (LE) Die Anlage einer Fallakte MUSS durch einen Leistungserbringer initiiert werden. Basis der von Leistungserbringer angeforderten Aktenkonfiguration ist üblicherweise die informierte, schriftliche Einwilligung des Betroffenen. Wenn keine solche Einwilligung vorliegt, kann eine Akte zwar über dieses Interaktionsmuster angelegt werden, es ist jedoch keine Nutzung der Akte und insbesondere kein Zugriff auf die in der Akte registrierten Daten möglich. EFA-Provider Der EFA-Provider legt die angeforderte Akte gemäß der vom LE vorgegebenen Konfiguration an. Der EFA-Provider stellt sicher, dass Aktenzugriffe nur durch autorisierte EFA-Teilnehmer im Rahmen der diesen zugewiesenen Rollen erfolgen können.
Interaktion	Arzt --> (Patientenidentifikation, Zweck der Akte, [Gültigkeit], [EFA-Teilnehmer], [Einwilligungsformular]) --> EFA-Provider
Vorbedingungen	Die fachlichen Voraussetzungen für die Anlage einer EFA sind gegeben. Insbesondere ist der Zweck der Akte benennbar. Die organisatorischen und rechtlichen Voraussetzungen für die Anlage einer EFA sind gegeben: Der die Akte anlegende LE hat mit dem EFA-Provider eine Vereinbarung geschlossen, die den im EFA-Datenschutzkonzept definierten Vorgaben entspricht. Sofern es sich hierbei um eine Datenverarbeitung im Auftrag handelt, muss eine entsprechende Zustimmung des Betroffenen eingeholt werden. Es existiert eine Festlegung zur Besetzung der Rolle des Fallaktenmanagers für die anzulegende Akte. Der LE kann eine sichere Kommunikation mit dem EFA-Provider aufbauen. Beide Akteure können wechselseitig ihre Identität und Authentizität verifizieren. Der LE hat den Patienten sicher identifiziert und von diesem Daten erfasst, die auch für andere EFA-Teilnehmer eine eindeutige Identifizierung des Patienten ermöglichen.
Ablauf	Der LE übermittelt die zur Anlage der Fallakte erforderlichen Informationen an den EFA-Provider. Der EFA-Provider nimmt die Anfrage entgegen und verifiziert deren Vollständigkeit und Korrektheit. Der EFA-Provider legt eine Fallakte in der gewünschten Konfiguration an. Der EFA-Provider setzt die Berechtigungen der Fallakte analog zu den Rollen der benannten EFA-Teilnehmer. Sofern keine Einwilligung des Patienten vorliegt oder keine EFA-Teilnehmer benannt wurden, wird lediglich ein Schreibrecht für die Organisation des LE vergeben. Sofern im Rahmen der EFA-Anlage eine elektronische Kopie des Einwilligungsformulars übermittelt wurde, wird dieses in der neu aufgesetzten Fallakte abgelegt.
Eingangsinformationen	Patientenidentifikation Zur Anlage einer Fallakte müssen Angaben zum Patienten übergeben werden, die auch anderen EFA-Teilnehmern die (1) Identifikation des Patienten, (2) die Prüfung der Zuordnung der Akte zum Patienten und (3)das Auffinden der Fallakte anhand von Identitätsinformationen zum Patienten ermöglichen. Zweck Der Zweck der Anlage und Nutzung der Fallakte muss möglichst konkret angegeben werden. Gültigkeit (optional) Für die anzulegende Fallakte kann eine maximale Gültigkeitsdauer angegeben werden. Diese darf einen beim Provider vorgegebenen Maximalwert nicht überschreiten. Wenn keine Gültigkeitsdauer angegeben ist, wird als Default eine beim Provider vorgegebene Mindest-Gültigkeit angenommen. EFA-Teilnehmer (optional) Die Teilnehmer der anzulegenden Fallakte können/sollen bereits bei der Anlage der Akte benannt werden. Zu jedem Teilnehmer sind identifizierende Daten sowie die Rolle im Rahmen der der Fallakte zugrunde liegenden Behandlung anzugeben. Die identifizierenden Daten müssen geeignet sein, einen authentisierten EFA-Nutzer zuverlässig als EFA-Teilnehmer zu identifizieren. Sofern die genutzten Identitätsdaten keinen Abruf von Informationen zu Name, Adresse etc. des Berechtigten erlauben (bzw. entsprechende Verzeichnisse nicht verfügbar sind), müssen zusätzlich zu jedem EFA-Teilnehmer Daten bereit gestellt werden, die dem Patienten und anderen EFA-Teilnehmern eine Identifizierung dieses Teilnehmers anhand von Name und Anschrift erlauben. Wenn bei der Anlage der EFA keine EFA-Teilnehmer benannt werden, werden lediglich Berechtigungen für den Initiator der Aktenanlage eingerichtet. Einwilligungsformular (optional) Eine elektronische Kopie der Einwilligungsformulars kann bei der Anlage der Akte übergeben werden. Dieses wird als Dokument in der Akte abgelegt. Der die Aktenanlage initiierende LE stellt sicher, dass die zur Konfiguration der EFA genutzten Angaben zum Patienten und zu den EFA-Teilnehmern mit den vom Patienten im Rahmen der Einwilligung gemachten Vorgaben übereinstimmen.
Nachbedingungen	Die Fallakte ist angelegt und für berechtigte EFA-Teilnehmer eindeutig adressierbar. Berechtigte Teilnehmer können Daten in die Akte einstellen und aus dieser auslesen. Die Fallakte ist mit einem Patienten und einem Zweck verknüpft. Beide Angaben sind für berechtigte Teilnehmer - und nur für berechtigte Teilnehmer - einsehbar. An die Fallakte sind Berechtigungen gebunden, die einen Zugriff auf registriert und autorisierte EFA-Teilnehmer beschränken. Sofern eine elektronische Kopie des Einwilligungsformulars bei der EFA-Anlage übergeben wurde, ist diese als Dokument in der Fallakte abrufbar.
Ausnahmeszenarien	Für den Patienten besteht bei dem angesprochenen EFA-Provider bereits eine Fallakte zu dem angegebenen Zweck. Sofern die Einwilligung den expliziten Zusatz enthält, dass mit der neuen Akte eine ggf. bereits zu dem angegebenen Zweck angelegte Akte in die neue Akte überführt werden kann, wird die neue Akte angelegt. Die Partitionen der bestehenden Akte werden mit der neuen Akte verknüpft. Die neu abgegebene Einwilligung ersetzt alle zuvor abgegebenen Einwilligungen. Dem Arzt wird ein Hinweis angezeigt, dass eine bestehende Akte integriert wurde. Sofern die Einwilligung keinen solchen Zusatz enthält, wird die Operation mit einer Fehlermeldung abgebrochen.

Peer-to-Peer Semantik

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngea.01.05}

Ist ein EFA-Teilnehmer einem EFA-Provider organisatorisch zugehörig, dann legt der EFA-Teilnehmer die neue Fallakte bevorzugt bei diesem EFA-Provider an.

Ansonsten legen EFA-Teilnehmer eine neue Fallakte immer bei dem EFA-Provider an, mit eine entsprechende Vereinbarung über eine Auftragsdatenverarbeitung besteht. Der Patient ist hierüber zu informieren und muss der Auftragsdatenverarbeitung zustimmen (siehe auch Domänenanalyse zur Auftragsdatenverarbeitung).

Referenzen und Querverweise

EFA-2.0-Spezifikation

Logical Perspective

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Identifizierung und Authentifizierung von EFA-Teilnehmern

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.01}

Anforderungen

Die Identität jedes zugriffsanfragenden Leitungserbringers muss vorab ausreichend sicher authentisiert werden. Die Zusicherung bezüglich der korrekten Identifizierung des Leistungserbringer (und der Stärke des vollzogenen Authentisierungsverfahrens) muss durch den ausstellenden Dienst attestierbar und kommunizierbar gestaltet werden.
Der austellende Dienst muss neben der Zuweisung der Identität und der Zusicherung über die korrekte Authentisierung des Leistungserbringers auch zusätzliche Attribute liefern, die der datenhaltenden Stelle ermöglichen, informierte und korrekte Zugriffsentscheidungen zu treffen. Der ausstellende Dienst ist zur Bereitstellung der folgenden Informationen verpflichtet:
- die eindeutige und korrekte Korrelation (Behandlungskontext) zwischen Patient, Daten und die Kombination Leistungserbringer + Organisation ausschließlich anhand der gelieferten Informationen zu ermöglichen
- Kontextinfomationen über die Natur des Zugriffs zu liefern (Stärke des Authentisierungsverfahrens, Zugriffsart etc.)
- den ausstellenden und ggf. haftenden Dienst eindeutig und für die datenhaltende Stelle dokumentierbar zu benennen
Die Identitätsinformationen, inklusive eventuell benötigter zugewiesener Attribute, müssen "in-band", d. h. innerhalb der zu tätigenden Transaktion, übermittelt werden.
Die datenhaltende Stelle ist verpflichtet, die innerhalb der Transaktion übermittelten Identitätsinformationen vor jeder Datenverarbeitung oder -offenbarung detailliert zu prüfen. Dabei ist es auch zwingend notwendig, neben der Gültigkeit der Identität und der Zusicherung über deren korrekte Zuweisung, auch Kontextinformationen wie beispielsweise die Stärke der Authentisierungsverfahren oder die Stabilität des Vertrauensverhältnis zum austellenden Dienst zu bewerten.
Der behandelnde Leistungserbringer ist zur korrekten Identifikation und Authentisierung des Patienten verpflichtet. Dies kann in Ermangelung von geeigneten technischen Verfahren ggf. organisatorisch ablaufen und ist mit den durch die Stammdaten und Einwilligungserklärung zugänglichen Identifikationsmerkmalen zu vergleichen.

Autorisierung von EFA-Teilnehmern

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.02}

Anforderungen

Die fundamentale Erlaubnis, personenbezogene und/oder medizinische Daten eines Patienten zu verarbeiten wird durch die Einwilligungserklärung des Patienten erteilt. Sollte zum Zeitpunkt der Zugriffsanfrage keine gültige Patienteneinwilligung vorliegen und der behandelnde Leistungserbringer nicht vorab berechtigt sein, so ist einen neue Patienteneinwilligung nach dem EFA-üblichen Muster zu erstellen.
Jegliche legitime Datenverarbeitungen durch die EFA sind durch den Patienten motiviert und müssen ausnahmslos fallbezogen und zum Ziel der Behandlung des Patienten durch einen vorab benannten Leistungserbringer vollzogen werden.
Die datenverarbeitende Stelle bürgt für die korrekte Identifikation und Authentisierung des Patienten, ggf. auch durch organisatorische Maßnahmen.
Sowohl die datenverarbeitende Stelle als auch die -haltende Stelle müssen jederzeit in der Lage sein, (Geschäfts-)Rollen und Funktionen geeignet technisch abzubilden und überprüfbar zu kommunizieren.
- Die Entscheidung unter welcher qualifizierten Rolle der Zugreifende eine Datenoffenbarung erfragt, obliegt der anfragenden Stelle.
- Die qualifizierte Rolle des Berufstätigen mit qualifizierter Ausbildung (professional role) ist so spezifisch zu fassen, wie es der technische Rahmen und der aktuelle Zugriffskontext zulässt (least privilege).
Die Entscheidung über die Freigabe der Datenoffenabrung auf Basis der durch die anfragende Stelle gelieferten Informationen obliegt stets der datenhaltenden Stelle.
- Die Freigabe einer Datenoffenbarung durch die datenhaltende Stelle ist stets erst nach der vollständigen Auswertung aller verfügbarer und durch die datenverarbeitende Stelle gelieferter Informationen und der Anwendung der lokalen Sicherheitsrichtlinie zu entscheiden. Dabei verursachen eventuelle Negativindikatoren zwingend eine negative Zugriffsentscheidung und unterbinden die erfragte Datenoffenbarung.
- Die datenhaltende Stelle ist dazu verpflichtet eine Datenoffenbarung abzulehnen, wenn die durch die datenverarebitende Stelle gelieferte qualifizierte Rolle nicht dem ausdrücklichen Patientenwunsch innerhalb der Einwilligungserklärung entspricht oder dem durch den aktuellen Behandlungskontext gerechtfertigten Zugriffsnotwendigkeiten widerspricht.
- Die datenhaltende Stelle ist jederzeit berechtigt und üblicherweise auch dazu verpflichtet, eine Datenoffenbarung abzulehnen, wenn die durch die datenverarbeitende Stelle gelieferte qualifizierte Rolle gemäß der lokalen Sicherheitsrichtlinie ungeeignet ausgestaltet ist.
- Eventuelle Nebenabsprachen zwischen EFA-Partnern, die eine Datenoffenbarung innerhalb vorab definierten Sonderszenarien oder unter besonderen Umständen legitimieren, sind dem Patienten in dessen Einwilligungserklärung vorab mitzuteilen und zu erklären. Sollten die Nebenabsprachen eine den üblichen EFA-Rahmen übersteigene Datenoffenbarung legitimieren oder zusätzliche Informationen zur Erfüllung von Datenanfragen benötigen, so sind auch alle betroffenen EFA-Partner zu informieren.

Vertraulichkeit

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.03}

Anforderungen

Personenbezogene und/oder medizinische Informationen dürfen ohne vorherige Einwilliung des Patienten keinesfalls gegenüber Dritten offenbart werden, sofern die Offenbarung nicht durch eine vorrangige Rechtsvorschrift vorgeschrieben ist oder es sich um einen geduldeten gesetzlichen Bruch handelt (wie beispielsweise einen Notfallzugriff bei Gefahr für Leib und Leben des Patienten).
Personenbezogene und/oder medizinische Informationen innerhalb der EFA dürfen ausschließlich an (medizinische) Leistungserbringer und deren benannte Auftragsdatenverarbeiter im Rahmen der Behandlung offenbart werden.
Personenbezogene und/oder medizinische Informationen dürfen ausschließlich den explizit als berechtigt benannten Stellen offenbart werden. Sollten vorrangige Rechtsvorschriften bestehen, die eine weitere Offenbarung gegenüber Dritten anordenen, so sollte der Patient möglichst über die Grundlage, Art und den Umfang dieser vorgeschriebenen Offenbarung vorab informiert werden.
Die legitime Verarbeitung von personenbezogene und/oder medizinische Informationen muss lückenlos über den kompletten Lebenszyklus der Fallakte durch den Einsatz geeigneter technischer, organisatorischer und rechtlicher Mittel sichergestellt werden. Der angemessene Einsatz dieser Mittel und die korrekte Umsetzung der Patientenwünsche (dokumentiert in der Patienteneinwilligung) müssen für den Patienten sowie Stellen mit datenschutzrechtlichen Kontrollaufgaben jederzeit und freimütig nachvollziehbar und überprüfbar sein.
Die zur Übertragung und Speicherung von Daten einer Fallakte benötigten personenbezogenen und/oder medizinische Informationen (beispielsweise innerhalb von Metadaten) sind auf das zwingend notwendige Minimum zu beschränken. Eventuell für Nicht-Berechtigte (d.h. nicht durch den Patienten autorisierte Personen/Einrichtungen) zugängliche Metadaten sind idealerweise so zu gestalten, dass sie keine Rückschlüsse auf die Inhalte der in der Fallakte verwalteten personenbezogenen und/oder medizinische Informationen zulassen. Insbesondere soll kein Bezug zwischen einem für Nicht-Berechtigte identifizierbaren Patienten und einer Erkrankung in den Metadaten kodiert sein.
Personenbezogene und/oder medizinische Informationen die durch die EFA ausgetauscht werden, müssen stets durch den ursprünglich vereinbarten Zweck gebunden bleiben. Eine eventuelle Neu-Klassifizierung der personenbezogenen und/oder medizinische Informationen muss ausschließlich medizinisch und fallbezogen gerechtfertigt werden und eine zweckfremde Nachnutzung ausschließen.

EFA Secure Channels

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.03.01}

Die datenhaltende Stelle muss die Kommunikationsendpunkte der am Datenaustausch beteiligten technischen Kommunikationspartner vor jeder Datenoffenbarung gegenseitig authentisieren (Mutual Node Authentication).
Alle beteiligten Kommunikationspartner müssen besonders abgesicherte, dokumentierbare und zuverlässige technische Verfahren zum einvernehmlichen Datenaustausch einsetzten (Reliable Messaging).
Spezielle Anforderungen bestehen für alle Kommunikationsprozesse, in denen sich die Daten nicht in der direkten/alleinigen Obhut einer durch den autorisierten Leistungserbinger oder den Patienten kontrollierte Stelle befinden. Hier sind geeignete Maßnahmen zur Herstellung eines vertraulichen Transportkanals zwischen den Kommunikationsendpunkten dieser Datenaustausch-Prozesse umzusetzen:
- Die innerhalb der EFA durchgeführten Kommunikationsprozesse müssen durch geeignete technische Mittel durchgängig unbelauschbar gestaltet werden.
- Die innerhalb der EFA durchgeführten Kommunikationsprozesse müssen durch geeignete technische Mittel von anderem Datenverkehr durchgängig isoliert werden.
- Die innerhalb der EFA durchgeführten Kommunikationsprozesse müssen durch geeignete technische Mittel davor bewahrt werden, Rückschlüsse über die Natur, den Inhalt oder die Betroffenen der Datenübertragung anhand sekundärer Identifikationsmerkmale oder Metadaten der genutzten Kommunikationsmittel zu ermöglichen.

Authentizität und Integrität von EFA Daten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.04}

Anforderungen

Jeder durch eine EFA vollzogene Datenaustausch muss gesicherte Informationen über die:
- Urheberschaft der medizinischen Daten (author and/or ownership)
- Verantwortung und Haftung der Daten (legal authenticator) enthalten.
Die datenverarbeitende Stelle (datenkonsumierender Leistungserbringer) muss durch die in der Transaktion und EFA enthaltenden Informationen in der Lage versetzt werden, den Datenursprung (Originator Authenticity) und den Grad der Datenautenzität (legal authenticator & data authenticity) selbstständig bewerten und dokumentieren zu können.
Die Informationen über Datenauthenzität und Datenursprung innerhalb der EFA oder den begleitenden Metadaten dürfen durch die Übertragungsmittel nicht innerhalb des Transfers geändert werden.
Die innerhalb der EFA enthaltenen medizinischen Daten müssen während des Transfers durch geeignete technische Mittel vor:
- unabsichtlicher Verfälschung und vorsätzlicher Manipulation,
- Verlust und Unvollständigkeit geschützt werden.
Sofern der Datenaustausch zwischen datenhaltenden Stellen und berechtigten Nutzern über Dritte vermittelt wird (beispielsweise P2P-Gateways zur Vernetzung von EFA-Providern), müssen gesicherte Informationen über die Identität der bei einer Datenkommunikation genutzten datenvermittelnden Stellen für alle Kommunikationspartner verfügbar sein.

Digital Signature

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.04.01}

Als future extension, wenn HBA und SMC flächendeckend verfügbar….

Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.05}

Anforderungen

Jeder durch die EFA vollzogene Datenaustausch muss geeignet dokumentiert werden, so dass eine nachträgliche lückenlose Rekonstruktion der Kommunikation und des Kontexts möglich ist (Nachträglich: nach erfolgtem Zugriff auf einen Fachdienst, Lückenlos: alle Transaktionen auf der EFA-Anwendungsebene sind erfasst).
Die innerhalb der digitale Beweiskette und dem Audit-Trail abzulegenden Informationen sind manipulations- und revisionssicher abzuspeichern.
Die digitale Beweiskette und der Audit-Trail müssen geeignet archiviert werden und die Aufbewahrungsfristen sind an den gesetzlichen Gegebenheiten auszurichten. Sollten lediglich Minimalaufbewahrungsfristen gewahrt werden, so sind alle direkt Betroffenen (Patient, EFA-Teilnehmer) über diesen Umstand geeignet zu unterrichten.
Eine geeignete Beweiskette muss sich aus dem Audit-Trail ergeben, die eventuellen Betroffenen und mit datenschutzrechtlichen Kontrollaufgaben beauftragten Personen eine fallbezogene, umfassende Überprüfung der Legitimität der aktuellen und historischen Fallaktenzugriffe ermöglicht.
Die digitale Beweiskette und der Audit-Trail darf lediglich die zwingend zur Erfüllung der Dokumentationspflichten personenbezogenen und/oder medizinischen Daten erfassen. Andere Protokolle und -arten, wie beispielsweise Performancelogs, dürfen keinerlei personenbezogenen und/oder medizinischen Daten erfassen.
Die digitale Beweiskette und der Audit-Trail sind auf Grund der zwingend zur Erfüllung der Dokumentationspflichten enthaltenden personenbezogenen und/oder medizinischen Daten vor Zugriffen unberechtigter Dritter zu schützen und verfügen über den gleichen Schutzbedarf wie die darin enthaltenen Daten.
Die innerhalb der digitalen Beweiskette und dem Audit-Trail enthaltenden Informationen dürfen lediglich gegenüber dem Patienten und mit datenschutzrechtlichen Kontrollaufgaben betrauten Personen offenbart werden. Reguläre Leistungserbringer haben generell keinen Zugriff auf die digitale Beweiskette und den Audit-Trail. Die digitale Beweiskette und der Audit-Trail dürfen keinesfalls zweckfremd verwendet werden und werden ausschließlich zu Dokumentations- und Nachweiszwecken erfasst. Automatisierte Kontrollsysteme des Audit-Trails sind gesondert zu berechtigen und der Patient ist über den Einsatz derartiger Systeme zu informieren.

Verfügbarkeit von EFA-Teilnehmern und EFA-Daten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierf.06}

Anforderungen

EFA Partner sind verpflichtet, andere Verbundpartner geeignet über geplante und ungeplante Nicht-Verfügbarkeit durch einen gesonderten Prozess zu unterrichten.
Die Vollständigkeit und Unversehrtheit der zu übertragenen Daten MUSS während des Transfers durch die gewählten Kommunikationsmittel lückenlos gewährleistet werden.
Temporäre Fehler in der Datenbereitstellung durch die datenhaltende Stelle müssen geeignet markiert und kommuniziert werden.
- Eventuelle Providencefehler und/oder Unvollständigkeiten bezüglich der in der Datenübertragung kommunizierten Daten sind stets zu Nachweiszwecken umfänglich von allen beteiligten Kommunikationspartnern eigenständig zu dokumentieren. Dieses kann z.B. im Rahmen der Protokollierung erfolgen, indem auch Fehler- und Warnhinweise zu nicht erfolgten Zugriffen in das Protokoll aufgenommen werden.
- EFA-Kommunikation ist unter dem "best-attempt" Prinzip zu betreiben und die EFA-Partner sowie der Patient sind über diesen umstand geeignet zu unterrichten. EFA-Daten als solche sind nicht als Primärdokumentation mit den daraus resultierenden Implikationen bezüglich der jederzeit zwingenden Verfügbarkeit zu verstehen.
- In einer verteilten EFA bewertet die datenverarbeitende als verantwortliche Stelle der Datenkompilation die Bewerting der tatsächlichen Vollständigkeit der emfangenen Datensammlung.
- Die Entscheidung über die medizinische Nutzbarkeit der unvollständigen Daten kann der datenverarbeitenden Stelle übertragen werden.
Sofern nicht durch gesonderte Indikatoren angezeigt, gilt eine von der datenhaltenden Stelle freigegebene Datenoffenbarung zum Zeitpunkt der Offenbarung als komplett und unversehrt.
- Diese Anforderung ist auf die aktuell in der EFA eingestelten Daten zu limitieren und trifft keine Aussage über Art und Umfang der tatsächlich bei der datenhaltenden Stelle vollumfänglich verfügbaren Daten über den betroffenen Patienten.
- Die Vollständigkeit und Verfügbarkeit der EFA selbst und der darin eingestellten Daten ist durch die Patienteneinwilligung und die lokale Sicherheitsrichtlinie der datenhaltenden Stelle definiert. Dies kann zu Ausblendungen, Zurückhaltung oder Löschung führen, sofern diese durch den Patienten, aktuell gültige Rechtsvorschriften oder die datenhaltende Stelle mandatiert sind.
Die Existenz einer EFA und den durch diese verfügbar gemachten Daten bedingt keinen Rechtsanspruch bezüglich deren tatsächlicher Nutzung (patientengesteuerte freiwillige Nutzung). Der Patient ist jederzeit berechtigt situationsbezogen entscheiden, ob und wie die EFA in dessen Behandlungskontext durch die Leistungserbringer genutzt wird.
- Die tatsächliche Verfügbarkeit einer EFA und den in diese eingestellen Daten kann nicht über die gesamte Dauer des Behandlungskontext garantiert werden. Der Patient hat jederzeit das Recht die Einwilligung der EFA zurückzuziehen und damit auch vorab durch die EFA zuängliche oder kommunizierte Daten unverfügbar zu machen. Dieser Umstand ist insbesondere bei datenverarbeitenden Stellen geeignet zu adressieren, um stets eine angemessen vollständige lokale Behandlungsdokumentation gewährleisten zu können.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

EFA Business Informationsmodell

EFA Informationsmodell

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.01}

Die folgende Abbildung zeigt das aus der Definition der EFA-Geschäftsobjekte abgeleitete und über HL7 RIM Klassen ausgedrückte Informationsmodell des EFA-Konstrukts.

Prinzipiell schreibt die EFA-Spezifikation keine bestimmte interne Umsetzung dieses Informationsmodells vor, d.h. ein Hersteller kann dieses über beliebige Technologien abbilden. Normative Vorgaben bestehen jedoch bezüglich der Aussen-Semantik und der über Operationen der EFA-Dienste ausgetauschten Instanzen (von Ausschnitten) dieses Informationsmodells. Dieses spiegelt sich vor allem in der nachfolgend beschriebenen Abbildung der EFA Geschäftsobjekte auf ihre korrespondierenden logischen Objekte im Informationsmodell wider.

Patient

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.01.01}

Die funktional-logische Spezifikation der EFA korrespondiert mit der Sichtweise auf ein EFA-Netzwerk als eine Versorgungsdomäne. Auf der Sicht einer Affinity Domain angesiedelte Problemstellungen bezüglich der Repräsentation des Patienten durch in den einzelnen EFA-Peers unterschiedliche Patienten-IDs müssen daher außerhalb der EFA gelöst werden. Hierzu sind die u.a. im IHE Cookbook beschriebenen, von der EFA unabhängig umsetzbaren Verfahren eines Master Patient Index oder einer domänenübergreifend gültigen ID zu nutzen.

Konkret bedeutet dies: Eine von einem EFA-Teilnehmersystem beim Aufruf eines EFA-Dienstes genutzte Patienten-ID muss immer in der Affinity Domain des EFA-Providers bekannt sein, d.h. das Clientsystem des EFA-Teilnehmers muss ggf. vor dem Dienstaufruf eine Abbildung der lokal genutzten Patienten-ID auf die Patienten-ID der Domäne des EFA-Providers vornehmen. Analog hierzu gilt auch in einer aus mehreren Affinity Domains bestehenden Versorgungsdomäne die Regel "Sender does it right", d.h. bevor eine Anfrage von einem EFA-Provider an einen anderen weitergeleitet wird, muss der initierende Peer die Überführung der Patienten-ID in die Domäne des Ziel-Peers vornehmen.

Fallakte

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

Die folgenden Aussagen prägen das Außen-Verhalten eines logischen Objekts der Klasse "Fallakte":

Jede Fallakte ist genau einem Patienten zugeordnet. Diese Beziehung ist für Berechtigte bidirektional auflösbar, d.h. zu einem Patienten können die zugehörigen Fallakten und zu einer gegebenen Fallakte der betroffene Patient ermittelt werden.
Jede Fallakte dient genau einem klar abgrenzbaren Zweck. Pro Patient und Zweck kann es nur eine Fallakte geben.
Zu jeder Fallakte gibt es zu jeder Zeit genau eine gültige Einwilligung des betroffenen Patienten. Die Fallakte ist von der Einwilligung abhängig, d.h. eine Rücknahme der Einwilligung bedingt das Schließen der Fallakte.
Zu jeder Fallakte sind berechtigte EFA-Teilnehmer benannt, deren Berechtigungen sich aus ihren definierten Rollen der EFA-Nutzung ableiten.

Partition

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.01.03}

Die folgenden Aussagen prägen das Außen-Verhalten eines logischen Objekts der Klasse "Partition":

Eine Fallakte besteht aus einer oder mehr Partitionen. Jede Partition ist genau einer Fallakte zugeordnet. Auch hier besteht eine Abhängigkeitsbeziehung; mit Schließen der Fallakte werden auch die abhängigen Partitionen geschlossen und sind nicht mehr zugreifbar.
Jede Partition wird bei einem EFA-Provider angelegt und verwaltet. Dieser ist für die sichere Speicherung der daran hängenden Daten sowie die Durchsetzung der definierten Berechtigungen bei Zugriffen auf die Partition verantwortlich.

document

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.10}

Datenobjekte der EFA werden in Partitionen verwaltet. Ein Datenobjekt kann mehreren Partitionen zugeordnet sein, sofern diese beim selben EFA-Provider angelegt sind. Aktuell werden lediglich (medizinische) Dokumente als Datenobjekte der EFA unterstützt.

Für die EFA-v2.0-Spezifikation wird davon ausgegangen, dass die Inhalte von Dokumenten nur für einige wenige definierte Dokumentklassen (z.B. consentInfo) maschinell verarbeitet werden können. Dies bedeutet, dass alle für das Einstellen, die Auswahl, den Abruf, die Strukturierung/Suche und die Anzeige von Dokumenten relevanten Attribute eines Dokuments explizit außerhalb des Dokuments verfügbar sein müssen.

Die Klasse document bildet hierbei die Klammer über alle Bestandteile eines Dokuments, die explizit über Klassen gekapselt und hierdurch potenziell für eine maschinelle Verarbeitung verfügbar sind:

partitionID: Jedes Dokument ist eindeutig einer Partition zugeordnet, die ihrerseits eindeutig einer Fallakte zugeordnet ist. Die für diese Fallakte definierten Zugriffsrechte werden auf deren Partitionen und damit auch die darin enthaltenen Dokumente vererbt.
docMetadata: Jedem Dokument sind beschreibene Metadaten (z.B. Dokumenttyp und Dokumentformat) zugeordnet, um die automatisierte Filterung und Strukturierung zur Anzeige von EFA-Inhalten gegenüber einem EFA-Teilnehmer zu unterstützen.
docData: Das eigentliche Dokument ist aus Sicht der EFA (von wenigen Ausnahmen abgesehen) ein BLOB, der nicht weiter maschinell verarbeitet wird.
docRelationship: Dokumente können zueinander in Beziehung stehen. Neben in Dokumenten kodierten Verweisen können diese Beziehungen auch über eigenständige Objekte explizit gemacht werden.

PIM Data Structures

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02}

Die hier definierten plattformunabhängigen Datenstrukturen zeichnen die fachlichen Eingabe- und Ausgabe-Parameter der Operationen des EFA Service Functional Model aus.

patientID

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.01}

Diese Klasse ist ein eindeutiger Identifizierer eines Patienten innerhalb einer Affinity Domain eines EFA-Providers.

Der Aufrufer eines EFA-Dienstes verwendet immer den Identifizierer eines Patienten, der in der Affinity Domain des EFA-Dienstes registriert ist. Ein konkurrierender, nicht registrierter Identifizierer muss vom Aufrufer zunächst auf einen in der Affinity Domain registrierten Identifizierer abgebildet werden.

In der IHE-Semantik entspricht diese Klasse der "XAD-PID" (siehe IHE Cookbook).

purpose

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.02}

Diese abstrakte Klasse kodiert den Zweck einer Fallakte. Sie referenziert eindeutig den "medizinischen Fall" des Patienten im Sinne eines zwischen den Akteuren abgestimmten Behandlungsmusters, das Vorgaben zu den Versorgungszielen, der inhaltlichen Abgrenzung und den Kommunikationsflüssen festlegt.

Es wird empfohlen, die medizinische Fälle determinierenden Versorgungsmuster über Konzepte in einem vom EFA-Verein gepflegten Codesystem auszudrücken.

ecrStatus

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.03}

Diese Klasse beschreibt die Zustände des Lebenszyklus einer Fallakte.

Der Wertebereich dieser Klasse ist:

Offen / Open
Gesperrt / Suspended
Verfallen / Retired
Archiviert / Archived.

consentInfo

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.04}

Diese Klasse ist eine strukturierte Abbildung der Patienteneinwilligung zur EFA. EFA-Dienste erzeugen aus den Instanzen dieser Klasse EFA-Berechtigungsregeln.

Diese Klasse ist eine Spezialisierung der Klasse document.

Diese Klasse setzt die Vorgaben zu den Inhalten einer Patienteneinwilligung zur EFA technisch um:

Der Patient muss identifiziert sein.
Der Zweck muss angegeben sein. Dessen Kodierung unterliegt den Vorgaben der Klasse purpose.
Das Verfallsdatum der Akte muss angegeben sein.
Die EFA-Teilnehmer müssen identifiziert sein. In der über diese Klasse realisierten Dokumentation einer Einwilligung können ausschließlich Organisationen oder Organisationen zugeordnete Personen als EFA-Teilnehmer benannt werden.

Diese Klasse muss eine Umsetzung der im Interaktionsmuster "Fallakte anlegen" beschriebenen Ausnahmeszenarien erlauben. Dies bedeutet, dass per Konvention oder per expliziter Aussage erkennbar sein muss, wie die Anlage einer Akte realisiert wird, wenn bereits eine Akte zu den benannten Zweck besteht.

Zu jedem Zeitpunkt hat eine Fallakte bei jedem beteiligten EFA-Provider genau eine wirksame Instanz von consentInfo. Eine neue Instanz invalidiert die bestehende Instanz.

consentDoc

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.05}

Diese Klasse beschreibt die informierte, schriftliche Patienteneinwilligung. Sie ist ein unstrukturiertes, vom EFA-Provider inhaltlich nicht verarbeitetes Dokument.

Diese Klasse ist eine Spezialisierung der Klasse document.

Ein consentDoc-Dokument muss ein consentInfo-Dokument ergänzen (siehe docRelationship).

consentLegalAuthenticator

Die Klasse consentLegalAuthenticator identifiziert die Person, die die Einwilligung geprüft hat und gegenüber der EFA bekannt gegeben hat. Die Benennung der Person muss so ausgestaltet sein, dass eine Nachvollziehbarkeit auch langfristig möglich ist.

caseRecordManager

Ein EFA-Teilnehmer muss als Fallakten-Manager ausgezeichnet sein. Hiermit sind erweiterte Berechtigungen verbunden (siehe "Akteure und Rollen").

consentCustodian

Die Klasse consentCustodian benennt die Einrichtung, in der die vom Patienten unterschriebene Fassung der Einwilligung aufbewahrt wird.

partitionID

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.06}

Die Klasse partitionID beschreibt eine eindeutige Referenz auf eine Partition einer Fallakte. Bestandteil der Referenz sind

ein Verweis auf den EFA-Provider, der die Partition verwaltet, sowie
ein von diesem Provider eindeutig auflösbarer Identifizierer.

partitionList

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.07}

Diese Klasse beschreibt eine Menge von Partitionen, die dem selben Patienten zugeordnet sind.

Jede Partition wird durch ein partition-Objekt repräsentiert. Mit diesem Objekt müssen vom EFA-Provider im Rahmen der Operation listPartitions die folgenden Informationen zu einer Partition verknüpft sein:

partitionID: Eindeutiger Identifizierer der Partition.
ecrRef: Verweis auf die Fallakte, der die Partition zugeordnet ist. Jede Partition ist genau einer Fallakte zugeordnet.
Metadaten der Partition: Die genaue Festlegung der von einem EFA-Provider zu einer Partition verwalteten Metadaten ist vom konkreten Binding abhängig. Jedes Binding muss aber mindestens die in der Klasse partitionInfo enthaltenen Angaben unterstützen und als Teil des eine Partition repräsentierenden partition-Objekts bei der Abfrage der Partitionen einer Fallakte an den Aufrufer zurück liefern.

ecrRef

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.08}

Diese Klasse beschreibt die Referenz einer Fallakte.

Per Definition hat ein Patient je Zweck höchstens eine Fallakte. Sie wird daher mit dem Tupel (patientID, purpose) eindeutig in einer Affinity Domain referenziert.

Bei einer Peer-to-Peer-Vernetzung, in der Daten einer Fallakte über mehrere Affinity Domains verteilt vorgehalten werden, kann jede Affinity Domain potenziell eine eigene patientID für den selben Patienten vergeben. Daher ist eine Fallakten-Referenz aus patientID und Zweck immer relativ, d.h. kann nur in der Affinity Domain verarbeitet werden, in der diese Referenz zur Verarbeitung der in dieser Domain verwalteten Partitionen der Fallakte erzeugt wurde. Um Fallakten über Affinity Domains hinweg zu vernetzen und insbesondere auch Zugriffe auf verteilte Fallakten zu ermöglichen, wird daher zusätzlich eine communityID als dritter Bestandteil einer Fallakten-Referenz benötigt, die angibt, in welcher Affinity Domain die Referenz gültig ist.

Gängige Aktenstandards wie IHE XDS unterstützen keine logischen Konstrukte oberhalb weitgehend semantikfreier Ordner, d.h. der Container für Metadaten einer Fallakte muss entweder als proprietäre Ergänzung realisiert werden oder es muss eine Abbildung der EFA-Metadaten auf Ordner erfolgen. Um die zweite Option einfach realisieren zu können, wurde in der EFAv2.0 im Vergleich zur EFA-1.2-Spezifikation das Konstrukt der Partitionen deutlich gestärkt und auch die Funktionalität stärker auf dieses Konstrukt fokussiert:

In der EFA-v2.0-Spezifikation ist eine Fallakte implizit als Summe der unter einer Patienteneinwilligung gefassten, zum gleichen Patienten und Zweck angelegten Partitionen definiert. "Einwilligung" (consentInfo), "Partition" (partitionID) sowie "Patient und Zweck" (ecrRef) sind hierbei eigenständig verwaltete und verknüpfte Objekte, die sofern im Rahmen eines Operationsaufrufs erforderlich auch explizit als Argumente übergeben werden. Hiermit werden implizit auch die EFA-Metadaten patientID und purpose auf der Ebene der Partitionen realisiert.
Die EFA-v2.0-Spezifikation besitzt mit Ausnahme der Operationen zur Steuerung des Lebenszyklus (createECR, closeECR, registerConsent) keine Operationen auf Fallakten, sondern realisiert Funktionen zum Lesen und Schreiben ausschließlich auf Ebene der Partitionen. Insbesondere gibt es im Service Functional Model keine Operationen zum Suchen, Öffnen oder Auslesen von Fallakten, für die administrative oder gar medizinische Metadaten einer Fallakte erforderlich wären.

partitionInfo

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.09}

Der Zugriff auf die Inhalte einer Fallakte erfolgt durch Auflisten der Partitionen der Akte und anschließendes Browsing bzw. Suchen/Filtern über den in den einzelnen Partitionen enthaltenen Daten. Damit die IT-Systeme der EFA-Teilnehmer diesen Ablauf optimieren und an verschiedene Zugriffsmetaphern (z.B. Anzeigen seit dem letzten Zugriff neu hinzugekommener Daten) anpassen können, werden Partitionen mit Metadaten versehen. Hierbei muss ein Binding zumindest die folgenden Metadaten unterstützen:

Attribut	Beschreibung	Verwendung
partitionID (mandatory)	Eindeutiger Identifizierer der Partition	Die ID der Partition wird beim Anlegen einer Partition abhängig vom genutzten Binding durch den EFA-Teilnehmer oder den EFA-Provider festgelegt. Sie muss beim Auslesen der Partitionsdaten vom EFA-Provider zurück geliefert werden. Die ID der Partition wird zum Abruf von Daten aus einer Partition und zum Einstellen von Daten in eine Partition benötigt.
Titel (mandatory)	Für den EFA-Teilnehmer verständliche Bezeichnung der Partition, aus der hervorgeht, welche Daten in der Partition zu erwarten sind (z.B. "Nachsorge nach Bypass-Operation"). Aus Datenschutzgründen darf dieser Titel keine identifizierenden Angaben zum Patient enthalten.	Der Titel wird beim Anlegen einer Partition gesetzt und unverändert beim Auslesen der Partitionsdaten vom EFA-Provider zurück geliefert. Dieses Attribut kann z.B. genutzt werden, um einem EFA-Teilnehmer beim Browsing über einer Akte zunächst die verfügbaren Partitionen anzuzeigen und nur Daten aus vom Teilnehmer als für die aktuelle Behandlungssituation relevant markierten Partitionen abzurufen.
Klassifizierung (optional)	In Ergänzung zum Titel kann eine Partition auch eine maschinenlesbare Klassifizierung enthalten. Beispiele hierfür finden sind administrative Informationen, z.B. ob es sich um Daten zu einem Krankenhausaufenthalt handelt.	Klassifizierungen müssen beim Anlegen einer Partition gesetzt und vom EFA-Provider unverändert beim Auslesen der Partitionsdaten vom EFA-Provider zurück geliefert werden.
Erfasster Behandlungszeitraum (mandatory)	Zeitraum der über die Partition unterstützten Behandlungsepisode. Hierbei werden das Anfangsdatum der Episode sowie das Datum der letzten Änderung der Inhalte der Partition verwaltet.	Das Anfangsdatum der Episode wird beim beim Anlegen einer Partition gesetzt. Fehlt diese Angabe, wird das Datum der Anlage der Partition als Anfang der begleiteten Episode angenommen. Das Datum der letzten Änderung wird vom EFA-Provider bei jeder Einstellen von Daten in die Partition neu gesetzt und beim Auslesen der Partitionsdaten mitgegeben. Ein EFA-Teilnehmersystem kann Partitionen anhand dieser Angaben in eine chronologische Reihenfolge bringen oder effizient nach den aktuellsten Daten durchsuchen.
Verantwortliche Organisation (optional)	Bezeichner der Organisation, die für die Anlage der Partition und die Pflege der darin enthaltenen Inhalte verantwortlich ist.	Sofern diese Information nicht beim Anlegen einer Partition gesetzt wird, gilt die Organisation des die Partition anlegenden Leistungserbringers als für die Partition verantwortlich. Diese Information muss beim Auslesen der Partitionsdaten bereit gestellt werden.
Anker (optional)	Bei der Anlage der Partition gesetzter Wert, der von der für die Partition verantwortlichen Einrichtung für interne Zwecke genutzt werden kann.	Wie in der Darstellung der EFA Geschäftsobjekte beschrieben, kann eine Partition mit einem Containerobjekt des EFA-Teilnehmers wie z.B. einem Aufenthalt oder einem Abrechnungsfall verknüpft werden. In diesem Fall kann z.B. ein Kommunikationsserver eine automatisierte Synchronisierung zwischen den Daten in der Partition und dem damit verknüpften internen Container durchführen. Um dieses zu unterstützen kann zu einer Partition ein Anker zu dem damit verknüpften internen Containerobjekt angegeben werden. Dieser Wert ist für den EFA-Provider und die anderen Teilnehmer semantikfrei und transparent.

Ein EFA-Binding kann weitere Attribute für Partitionen definieren. Diese müssen jedoch von einem clientseitigen Teilnehmersystem nicht zwingend verarbeitet werden.

docMetadata

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.11}

Diese Klasse bildet die Metadaten eines Dokuments. Die folgende Tabelle beschreibt deren Attribute.

Attribut	Optionalität	Beschreibung	Verwendung
documentID	muss	Eindeutiger Identifizierer des Dokuments	Die ID eines Dokuments wird beim Einstellen von Daten in eine Partition abhängig vom genutzten Binding durch den EFA-Teilnehmer oder den EFA-Provider festgelegt. Sie muss beim Auflisten der Dokumente einer Partition vom EFA-Provider zurück geliefert werden. Die documentID wird beim Abruf eines Dokuments, zum Invalidieren eines Dokuments sowie zum Setzen von Dokumentenbeziehungen benötigt. Die ID eines Dokuments ist eine Instanz der Klasse documentID.
patientID	muss	Eindeutige Identifizierung des Patienten, dem das Dokument zuzuordnen ist	Die ID des Patienten, dem das Dokument zuzuordnen ist, muss beim Einstellen von Daten durch den EFA-Teilnehmer angegeben werden. Der EFA-Provider muss sicherstellen, dass in eine EFA nur Dokumente zu dem Patienten eingestellt werden, der in der Einwilligung zur EFA als Betroffener benannt ist. Die ID des Patienten wird als Instanz der Klasse patientID angegeben.
Titel	muss	Für den EFA-Teilnehmer verständliche Bezeichnung des Dokuments (z.B. "OP-Bericht zu Bypass-Operation"). Aus Datenschutzgründen darf dieser Titel keine identifizierenden Angaben zum Patient enthalten.	Der Titel wird beim Einstellen eines Dokuments in eine Partition gesetzt und unverändert beim Auflisten der Dokumente einer Partition vom EFA-Provider zurück geliefert. Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
Dokumentklasse	muss	Grobgranulare Klassifizierung des Dokuments in einer über Versorgungsdomänen hinweg einheitlichen Nomenklatur.	Die Dokumentklasse wird beim Einstellen eines Dokuments in eine Partition gesetzt und unverändert beim Auflisten der Dokumente einer Partition vom EFA-Provider zurück geliefert. Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
Dokumenttyp	muss	Feingranulare Klassifizierung des Dokuments in einer Nomenklatur, die von der Versorgungsdomäne definiert ist.	Das EFA-Teilnehmersystem setzt das Attribut beim Einstellen des Dokuments gesetzt und unverändert beim Auflisten der Dokumente einer Partition vom EFA-Provider zurück geliefert. Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
Dokumentformat	muss	Kodiertes Format des Datenobjekts (z.B. PDF)	Das EFA-Teilnehmersystem setzt das Attribut beim Einstellen des Dokuments.
Zeitpunkt der Bereitstellung	muss	Zeitpunkt des Einstellens in die Fallakte.	Der EFA-Dienst setzt das Attribut beim Einstellen des Dokuments, wenn es nicht in den bereitgestellten Metadaten enthalten ist. Das EFA-Teilnehmersystem kann mithilfe des Attributs neu eingestellten Dokumenten erkennen.
Zeitliche Einordnung	kann	Zeitraum, auf den sich das Dokument bezieht. Das Attribut muss leer sein, wenn der Zeitraum unbekannt, nicht eingrenzbar oder medizinisch irrelevant ist. Der Wert darf nicht gemeinhin der Zeitpunkt des Einstellens des Dokuments sein.	Der EFA-Teilnehmer setzt das Attribut beim Einstellen des Dokuments. EFA-Teilnehmersysteme können mithilfe des Attributs Dokumente entlang des Behandlungsverlaufs sortieren.
Verantwortliche Organisation	muss	Bezeichner der Organisation, die das Dokument einstellt und die Richtigkeit der Inhalte verantwortet.	Entweder der EFA-Teilnehmer oder der EFA-Dienst setzt das Attribut beim Einstellen eines Dokuments. Für den EFA-Dienst gilt: Er setzt die Organisations-ID der subjectIdentity als Wert des Attributs.
Dateigröße	kann	Dateigröße des Dokuments	Der Wert muss vom EFA-Provider ermittelt und gesetzt werden.
Fehlererkennender Code	sollte	Informationen zur Prüfung der Integrität. Das Attribut kann entfallen, wenn das Attribut Signatur verwendet wird.	EFA-Teilnehmer und EFA-Dienste prüfen mithilfe des Attributs, ob die Integrität des Dokuments nach dessen Transport und Speicherung gewahrt ist.
Signatur	kann	Digitale Signatur zur Sicherung der Authentizität und Integrität	Die Signatur sollte vom Ersteller des Dokuments stammen. EFA-Teilnehmer und EFA-Dienste prüfen mithilfe des Attributs, ob die Authentizität und Integrität des Dokuments gewahrt ist. Die hierzu benötigten Mechanismen werden erst mit der flächendeckenden Einführung von Heilberufsausweisen und zugehörigen Prüfdiensten verfügbar sein. Das Attribut ist daher optional.

Ein EFA-Binding kann weitere Attribute für Dokumente definieren. Diese müssen jedoch von einem clientseitigen Teilnehmersystem nicht zwingend verarbeitet werden.

docRelationship

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.12}

Diese Klasse beschreibt die Beziehung zweier Dokumente. Die nachfolgende Tabelle beschreibt die zulässigen Ausprägungen.

Dokumentbeziehung	Semantik	Anmerkungen
ergänzt	Ein Dokument ergänzt ein anderes Dokument.
ersetzt	Ein Dokument ersetzt ein anderes Dokument und dessen ergänzende Dokumente. Ein Dokument ist invalidiert, wenn ein leeres Dokument es ersetzt.	Ein ersetztes Dokument darf nur für Inhaber erweiterter Rollen (z. B. Fallaktenmanager) sichtbar und abrufbar sein.

documentID

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.13}

Die Klasse documentID beschreibt eine eindeutige Referenz auf ein Dokument. Bestandteil der Referenz sind

ein Verweis auf das EFA Document Repository, in dem das Dokument verfügbar ist, sowie
einen Identifizierer, den das EFA Document Repository auflösen kann.

communityID

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {BnsIi.02.14}

Die Klasse communityID beschreibt eine eindeutige Referenz auf eine Affinity Domain und damit auf den für diese Domain verantwortlichen EFA-Provider.

MountPoint

Die Klasse MountPoint beschreibt eine Referenz auf Teile einer Fallakte, die bei einem benachbarten EFA-Provider registriert sind.

Die Klasse hat die folgenden Attribute:

Attribut	Beschreibung
patientID	Typ: Klasse patientID Verwendung: Der Wert muss der patientID der Fallakte entsprechen, für die die Referenz verwaltet wird. Die patientID muss bei dem EFA-Provider gültig sein, der die Referenz speichert.
purpose	Typ: Klasse purpose Verwendung: Der Wert muss dem purpose-Wert der Fallakte entsprechenden, für die die Referenz verwaltet wird.
sourcePatientId	Typ: Klasse patientID Verwendung: Der Wert muss der patientID der Fallakte entsprechen, für die die Referenz verwaltet wird. Die patientID muss bei dem EFA-Provider gültig sein, der mit dem Attribut communityID ausgezeichnet ist.
communityID	Typ: Klasse communityID Verwendung: Der Wert muss der Referenz auf den EFA-Provider entsprechen, auf dessen Teile der Fallakte mit diesem Mount-Point verwiesen wird.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Lebenszyklus einer Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eune.01}

Fallakten müssen den in diesem Abschnitt definierten Lebenszyklus durchlaufen. Das folgende Zustandsdiagramm zeigt die Zustände und Zustandsübergänge des Lebenszyklus.

Zustände des Lebenszyklus

Offen / Open: Die Fallakte ist eingerichtet. Die Patienteneinwilligung ist wirksam. EFA-Teilnehmer und Fallaktenmanager sollen Zugriff haben.
Gesperrt / Suspended: Die Fallakte ist eingerichtet. Für eine Übergangszeit (Grace-Periode) sollen Fallaktenmanager Zugriff haben. EFA-Teilnehmer dürfen keinen Zugriff haben.
Verfallen / Retired: Die Fallakte ist eingerichtet. EFA-Teilnehmer und Fallaktenmanager dürfen keinen Zugriff haben. Der EFA-Provider muss die Fallakte zeitnah in den Zustand "Langzeitarchiviert" überführt haben.
Langzeitarchiviert / Archived: Die Referenzen und Zugriffsrechte/-protokolle der Fallakte sind in einem revisionssicheren Archiv gespeichert. Die verfallene Fallakte muss nach der Archivierung sofort und vollständig gelöscht sein.

Die Archivierungszeit ist institutionsspezifisch festzulegen, beträgt aber mindestens zehn Jahre. Das Risikomanagement der protokollierenden Institution hat hierbei die Aufgabe, die institutionsspezifischen Archivierungsfristen festzulegen. Die Frage, wer wann auf welche Informationen der eFA zugegriffen hat, kann in einem potenziellen Haftungsprozess unter dem Aspekt relevant werden, wer wann von welcher Information Kenntnis hatte bzw. hätte Kenntnis haben müssen bzw. können. Somit bewegen sich die Speicherfristen innerhalb der 30-jährigen Verjährungsfristen für Schadensersatzansprüche, die für die Verletzung von Leib, Leben und körperlicher Unversehrtheit gelten.

Die elektronische Fallakte ist eine temporäre Zusammenführung von bestehenden, anderweitig gespeicherten Dokumenten und keine Primärdokumentation. D. h., dass bei einer Löschung nur die Wurzel der Fallakte entfernt wird und die konkreten Dokumente an ihrem konkreten Ursprungsort bestehen und gespeichert bleiben. Eine explizite Löschung dieser Dokumente im Primärsystem vor der in §10 Abs. 3 MBO/Ärzte geregelten Aufbewahrungsfrist, in der Regel mindestens zehn Jahre, ist nicht einforderbar.

Zustandsübergange des Lebenszyklus

(*) - Offen

Auslöser: Die Patienteneinwilligung liegt vor. Ressourcen und Zugriffsrechte der Fallakte wurden eingerichtet.

Offen - Gesperrt

Auslöser: Der Zweck ist erloschen.

Der Zweck der Fallakten kann aus vielen Gründen erlöschen:

Die Behandlung ist abgeschlossen.
Der Patient ist verstorben.
Die EFA-Teilnehmer erachten die fachliche Notwendigkeit als nicht mehr gegeben. Das kann bereits nach kurzer Zeit gegeben sein, bspw. nach Abschluss eines Konzils.
Das Verfallsdatum der Fallakte wurde überschritten.
Eine zwischen EFA-Provider und EFA-Teilnehmern abgestimmte maximale Dauer der Nicht-Nutzung wurde überschritten.

Weitere Auslöser können innerhalb der fachlichen Netzwerke realisiert werden, sofern sie die gesetzlichen Vorgaben erfüllen.

Offen - Verfallen

Auslöser: Die Patienteneinwilligung ist erloschen.

Die Patienteneinwilligung kann erlöschen, wenn sie vom Patienten entzogen wird oder wenn die Gültigkeitsdauer der Einwilligung überschritten ist. Eine erloschene oder entzogene Patienteneinwilligung darf nicht für andere Fallakten wiederverwendet werden.

Das Verfallsdatum einer Fallakte sollte sich diagnosespezifisch an die Fünf-Jahres-Überlebensrate anlehnen. Die Fünf-Jahres-Überlebensrate dient als Mittel, um eine aus medizinischer Sicht differenzierte maximale Gültigkeitsdauer einer bestimmten Diagnose festzulegen. Abhängig vom Zweck der Fallakte kann auch eine deutlich kürzere Gültigkeitsdauer festgelegt werden, z. B. bei Anlage einer Fallakte für das Einholen einer Zweitmeinung. Grundsätzlich darf die Fallakte über das Verfallsdatum hinweg genutzt werden, wenn der Patient dem mit einer Einwilligungserklärung zustimmt.

Gesperrt - Verfallen

Auslöser: Die Grace-Periode ist beendet.

Die Grace-Periode ist beendet, wenn der Fallaktenmanager die Fallakte zur Archivierung freigibt, oder wenn die maximale Dauer der Grace-Periode überschritten wurde. Diese Dauer sollte nicht länger sein als 6 Monate.

Verfallen - Archiviert

Auslöser: Die Archivierung ist abgeschlossen.

Dieser Übergang ist lediglich für den EFA-Provider von Bedeutung. Die Übergangszeit ist die technische Karenzzeit, in der der EFA-Provider die Archivierung durchführt, um den Zustand "archiviert" zu erreichen.

Referenzen und Querverweise

LOINC Code: 59284-0 (siehe http://s.details.loinc.org/LOINC/59284-0.html?sections=Simple)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Kommunikationsmuster

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01}

Kommunikationsmuster beschreiben die geschäftlichen Interaktionsmuster der EFA mit logischen Transaktionen zwischen den technischen Akteuren der EFA.

Die nachfolgende Tabelle zeigt, welches Kommunikationsmuster welches Interaktionsmuster auf der logischen Ebene realisiert.

Interaktionsmuster	Kommunikationsmuster	Anmerkungen
Auffinden der Fallakten eines Patienten	Auflisten von Partitionen	Das Kommunikationsmuster gibt dem EFA-Teilnehmersystem eine Liste aller verfügbaren EFA-Partionen eines Patienten. Sie sind mit dem Zweck der Fallakte verknüpft, sodass das EFA-Teilnehmersystem eine Liste der Fallakten erstellen kann.
Browsing über eine Akte	Auflisten von Dokumenten	Das Kommunikationsmuster gibt dem EFA-Teilnehmersystem die Metadaten der Dokumente einer EFA-Partition. Diese Daten ermöglichen es dem Teilnehmersystem, eine strukturierte, navigierbare Sicht für den Arzt zu erzeugen. Das Muster kann für verschiedene Partitionen wiederholt werden.
Abruf von Datenobjekten	Abrufen von Dokumenten
Einstellen von Datenobjekten	Einstellen von Dokumenten
Invalidieren von Datenobjekten	Invalidieren eines Dokuments
Anlegen einer Fallakte	Anlegen einer Fallakte
Anlegen und Registrieren einer Partition	Anlegen einer Partition
Schließen einer Fallakte	Schließen einer Fallakte
Änderung einer Einwilligung	Registrierung einer neuen Einwilligung
Autorisierung eines weiteren Teilnehmers	Anfordern eines Berechtigungstoken	Der Patient erhält vom berechtigten EFA-Teilnehmer ein Offline-Token für die Fallakte.
Autorisierung eines weiteren Teilnehmers	Einlösen eines Berechtigungstoken	Der Patient übergibt das Offline-Token einem anderen Arzt und berechtigt ihn somit, auf die Fallakte zuzugreifen.

Aufbau des Sicherheitskontextes

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.01}

Alle Operationen der EFA-Fachdienste und die meisten Operationen der EFA-Sicherheitsdienste müssen mit einem Sicherheitskontext aufgerufen werden. Er ermöglicht es den Diensten, EFA-Berechtigungsregeln zu prüfen und durchzusetzen sowie Dienstaufrufe datenschutzkonform zu protokollieren.

Dieses Muster ist abhängig von der Authentisierung des Arztes am EFA-Teilnehmersystem (TNS). Sie unterliegt nicht der EFA-Spezifikation, muss jedoch die Regularien des EFA-Sicherheitskonzeptes berücksichtigen.

Um den Sicherheitskontext aufzubauen:

Das TNS ruft die Operation openContext des EFA-Kontext-Managers auf. Sie übernimmt die Credentials des EFA-Teilnehmers und gegebenenfalls weitere Identitätsmerkmale.
Der EFA-Kontext-Manager ruft die Operation requestHPIdentityAssertion des Identity Providers auf.
Wenn das Sicherheitskonzept der EFA-Provider-Domäne das Policy-Push-Verfahren anwendet, dann ruft der EFA-Kontext-Manager die Operation requestPolicy des Policy Providers auf.
Der EFA-Kontext-Manager baut mit den Sicherheitsobjekten den Sicherheitskontext auf und gibt ihn dem TNS.

Anlegen einer Fallakte

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

Dieses Muster ist abhängig von Aufbau des Sicherheitskontextes.

Um eine Fallakte anzulegen:

Mit dem EFA-Teilnehmersystem ruft der Arzt die Operation createECR des EFA-Ressourcen-Manager auf.
Der EFA-Ressourcen-Manager führt
1. entweder die Variante Neu-Anlage einer Fallakte
2. oder die Variante Fusion mit einer bestehenden Fallakte aus.
Der EFA-Ressourcen-Manager gibt die Kennung der Partition dem EFA-Teilnehmersystem.

Neu-Anlage einer Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.02.01}

Vorbedingung dieser Variante: Der EFA-Provider führt keine Fallakte mit dem gleichen Zweck für den Patienten.

Der EFA-Ressourcen-Manager

erstellt eine Fallakte, die aus einer Partition besteht,
speichert und registriert consentInfo sowie consentDoc,
erstellt und aktiviert für die Fallakte eine EFA-Berechtigungsregel, die konform zum consentInfo ist.

Fusion mit einer bestehenden Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.02.02}

Vorbedingung dieser Variante: Der EFA-Provider führt eine bestehende Fallakte mit dem gleichen Zweck für den Patienten.

Der EFA-Ressourcen-Manager

prüft, ob
1. die EFA-Berechtigungsregel der bestehenden Fallakte den zugreifenden Arzt als Berechtigten auszeichnet. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.
2. die Einwilligung für das Anlegen der Fallakte die Übernahme einer bestehenden Fallkte autorisiert. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.
erstellt eine Fallakte, die aus einer Partition besteht,
speichert und registriert consentInfo sowie consentDoc,
erstellt und aktiviert für die Fallakte eine EFA-Berechtigungsregel, die konform zum consentInfo ist. Die Einwilligung zu der bestehenden Fallakte wird außer Kraft gesetzt.
verknüpft die Partitionen der bestehende Fallakte mit der neuen Fallakte.

Aktenfusion vs. Änderung der Einwilligung

Der Zustand der Fallakte nach Ablauf dieses Kommunikationsmusters entspricht weitestgehend einem Zustand, der auch über das Kommunikationsmuster Registrierung einer neuen Einwilligung hergestellt werden kann. Die Aktenfusion findet jedoch immer im Rahmen einer Akten-Neuanlage statt, d.h. es wird davon ausgegangen, dass im nächsten Ablaufschritte Daten in diese Akte eingestellt werden. Daher wird bei der Akten-Neuanlage - und damit auch der Aktenfusion - immer auch eine neue Partition angelegt und ein Verweis auf diese Partition an den Aufrufer zurückgeliefert.

Damit entspricht eine Aktenfusion einer Sequenz der Kommunikationsmuster Registrierung einer neuen Einwilligung und Anlegen einer Partition.

Anlegen einer Partition zu einer bestehenden Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.03}

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um eine Partition zu einer bestehenden Fallakte anzulegen:

Das EFA-Teilnehmersystem (TNS) wählt die Fallakte aus der Liste der Partitionen aus.
Das TNS ruft die Operation createPartition des EFA-Ressourcen-Managers auf.
Der EFA-Ressourcen-Manager
1. legt die Partition an,
2. registriert und speichert gegebenenfalls die Dokumente und verknüpft sie mit der Partition und
3. gibt dem TNS die Kennung der Partition.

Schließen einer Fallakte

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.04}

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um eine Fallakte zu schließen:

Das EFA-Teilnehmersystem (TNS) wählt die zu schließende Fallakte aus der Liste der Partitionen aus.
Das TNS ruf die Operation closeECR des EFA-Ressourcen-Managers auf.
Der EFA-Ressourcen-Manager
1. führt für die Dokumente, die das Schließen begründen, das Muster Speichern und Registrieren von Dokumenten aus,
2. ändert den Status und die EFA-Berechtigungsregel der Fallakte gemäß des Lebenszyklus und
3. gibt die Kennung der Partition, mit der die Dokumente verknüpft sind, dem TNS.

Eine Fallakte im EFA-Verbund schließen

Die Partitionen einer Fallakte können auf mehrere EFA-Provider verteilt sein. In diesem Fall schließt dieses Kommunikationsmuster lediglich die Partitionen, die in der Community des Arztes (also bei dessen EFA-Provider) geführt werden.

Um die gesamte Fallakte zu schließen, müssen die restlichen teilnehmenden EFA-Provider benachrichtigt werden. Dieser Prozess unterliegt nicht der EFA-Spezifikation. Ein EFA-Verbund muss aber zumindest einen organisatorischen Prozess definieren.

Auflisten von Partitionen

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.05}

Dieses Kommunikationsmuster erlaubt es dem EFA-Teilnehmersystem (TNS), die Liste der Fallakten und derer Partitionen zu verarbeiten, die der EFA-Provider zu einem Patienten führt und für die der EFA-Teilnehmer zugriffsberechtigt ist.

Dieses Muster ist abhängig von Aufbau des Sicherheitskontextes.

Um die verfügbaren Partitionen aufzulisten:

Das TNS ruft die Operation listPartitions des Resource Managers auf.
Der Resource Manager
1. identifiziert die lokal verfügbaren Partitionen,
2. ruft für jeden Mount-Point die Operation listPartitions des für den Mount-Point verantwortlichen Resource Managers eines benachbarten EFA-Providers auf und
3. gibt die Liste der Partitionen dem TNS.

Einstellen von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.06}

Dieses Muster ist abhängig von:

Auflisten von Partitionen und
Auflisten von Dokumenten (optional).

Um Dokumente in eine Partition einzustellen:

Das EFA-Teilnehmersystem (TNS) wählt die Partition aus der Liste der Partitionen aus.
Das TNS erfasst die Dokumentbeziehungen mithilfe der Liste der Dokumente (optional).
Das TNS ruft die Operation provideData des EFA-Document-Repository auf.
Das EFA-Document-Repository
1. speichert das Datenobjekt (docData) jedes Dokuments,
2. ruft die Operation registerData des EFA-Document-Registry auf.
Das EFA-Document-Registry gibt dem EFA-Document-Repository eine Status-Meldung.
Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.

Zuordnung von Teilnehmern zu Providern
Jeder EFA-Teilnehmer ist immer einer oder mehreren Affinity-Domains zugeordnet. Jede Affinity-Domain wird durch einen EFA-Provider realisiert. Zwischen EFA-Teilnehmer und EFA-Provider besteht eine vertragliche Beziehung, die u.a. auch die Vorhaltung von Daten des Teilnehmers durch den Provider regelt. Wenn im Zusammenhang mit dem Einstellen von Daten somit von einem "EFA-Provider" die Rede ist, ist damit implizit immer ein EFA-Provider gemeint, mit dem der EFA-Teilnehmer eine vertragliche Beziehung hat, die ihm das Einstellen von EFA-Daten bei diesem Provider ermöglicht. Analog ist auch der Begriff "Document Repository" auf das Document Repository dieses Providers eingeschränkt, das dieser für die Daten des Teilnehmers vorgesehen hat. Ein Sonderfall ist die Konstellation, wenn ein Teilnehmer gleichzeitig Provider ist. In diesem Fall erfolgt die Datenvorhaltung analog zu den bestehenden Regularien für die Datenspeicherung innerhalb dieser Einrichtung.

Auflisten von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.07}

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um die Dokumente einer Fallakte aufzulisten:

Das EFA-Teilnehmersystem (TNS) wählt die Partitionen, deren Dokumente aufgelistet werden sollen, aus der Liste der Partitionen aus.
Das TNS ruft für jede gewählte Partitionen die Operation listPartitionContent des EFA-Document-Registry auf.
Das EFA-Document-Registry
1. sucht die Dokumente der jeweiligen Partition entweder lokal,
2. oder ruft die Operation listPartitionContent des Document Registry des für die Partition zuständigen EFA-Providers auf,
3. und gibt Dokument-Metadaten und Dokumentbeziehungen dem TNS.

Abrufen von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.08}

Dieses Muster ist abhängig von Auflisten von Dokumenten.

Um Dokumente einer Fallakte abzurufen:

Das EFA-Teilnehmersystem (TNS) wählt die Dokumente aus der Liste der Dokumente aus.
Das TNS ruft für jedes gewählte Dokumente die Operation retrieveData des EFA-Document-Repository auf.
Das EFA-Document-Repository
1. sucht das Datenobjekt entweder lokal
2. oder ruft die Operation retrieveData des Document Repository in der für das Dokument zuständigen Affinity Domain auf und
3. gibt das Datenobjekt des Dokument dem TNS.

Invalidieren eines Dokuments

Beim Invalidieren eines Dokuments wird dessen Status auf "ungültig" gesetzt.

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.15}

Dieses Muster ist abhängig von:

Auflisten von Dokumenten.

Um ein Dokument zu invalidieren:

Das EFA-Teilnehmersystem (TNS) wählt das zu ersetzende Dokument aus.
Das TNS ruft die Operation [cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|invalidateData]] des EFA-Document-Registry auf.
Das EFA-Document-Registry markiert das referenzierte Dokument als ungültig, sofern dieses in der lokalen Affinity Domain registriert ist
Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.

Registrierung einer neuen Einwilligung

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.09}

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um eine neue Einwilligung zu registrieren:

Das EFA-Teilnehmersystem (TNS) wählt die Fallakte aus der Liste der Partitionen aus.
Das TNS ruft die Operation registerConsent des EFA-Ressourcen-Managers auf.
Der EFA-Ressourcen-Manager führt das Muster Speichern und Registrieren von Dokumenten für die Einwilligungsdokumente aus.
Wenn das consentInfo eine Änderung des Zwecks anzeigt, dann konfiguriert der EFA-Ressourcen-Manager die Metadaten der Partitionen der Fallaktion bei der Document Registry.
Der EFA-Ressourcen-Manager registriert die neue EFA-Berechtigungsregel beim Policy Provider und
gibt dem TNS eine Status-Meldung.

Anfordern eines Berechtigungstoken

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.10}

Dieses Muster ist abhängig von Auflisten von Partitionen.

Um ein Berechtigungstoken anzufordern:

Das EFA-Teilnehmersystem (TNS) wählt die Fallakte, für die das Berechtigungstoken angefordert werden soll, aus der Liste der Partitionen aus.
Das TNS ruft die Operation issueAccessToken des Policy Providers auf.
Der Policy Provider gibt das Berechtigungstoken dem TNS.
Der EFA-Teilnehmer kann das Berechtigungstoken auf einen Träger aufbringen und dem Patienten geben.

Einlösen eines Berechtigungstoken

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.11}

Ein EFA-Teilnehmer löst ein Berechtigungstoken ein, um sich als Zugriffsberechtigter einer Fallakte zu registrieren.

Dieses Muster ist abhängig von Aufbau des Sicherheitskontextes.

Um ein Berechtigungstoken einzulösen:

Der EFA-Teilnehmer entnimmt das Berechtigungstoken dem vom Patienten bereitgestellten Träger.
Das EFA-Teilnehmersystem (TNS) ruft die Operation redeemAccessToken des EFA-Policy-Providers auf.
Wenn das Berechtigungstoken nicht vom eigenen EFA-Provider ausgestellt wurde, dann ruft der EFA-Policy-Provider die Operation redeemAccessToken des ausstellenden EFA-Providers auf.
Der Policy Provider gibt die Subject Access Policy für das Berechtigungstoken dem Policy Provider in der einreichenden EFA-Provider-Domäne.
Der Policy Provider registriert die Subject Access Policy und führt das Kommunikationsmuster Fallakte konsolidieren aus.
Der Policy Provider gibt dem TNS die Subject Access Policy.

Wenn der EFA-Provider das Client-Policy-Push-Verfahren erlaubt, dann ruft der Context Manager des TNS die Operation requestPolicy des Policy Providers auf.

Konsolidieren von Fallakten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.14}

Ein EFA-Policy-Provider hat ein Berechtigungstoken für einen EFA-Teilnehmer eingelöst und registriert. Der EFA-Ressourcen-Manager muss daraufhin die eigens geführten Partitionen der Fallakte bei den teilnehmenden EFA-Providern registrieren. Der Ressourcen-Manager der ausstellenden EFA-Provider-Domäne kennt alle teilnehmenden EFA-Provider.

Um eine Fallakte zu konsolidieren:

Wenn der eigene EFA-Provider keine Partitionen der Fallakte führt:
1. Der EFA-Ressource-Manager ruft die Operation listRecordLocations des EFA-Ressourcen-Managers in der ausstellenden EFA-Provider-Domäne auf.
2. Für jede communityID in der Ergebnisliste des Operationsaufrufs: Der EFA-Ressourcen-Manager ruft die Operation registerRecordLocation des EFA-Ressource-Managers der entsprechenden EFA-Provider-Domäne auf.

Speichern und Registrieren von Dokumenten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.12}

Mit diesem Muster speichert und registriert ein Resourcen Manager Dokumente im Document Repository und Document Registry.

Um Dokumente zu speichern und zu registrieren:

Der Resource Manager ruft die Operation provideData des Document Repository auf.
Das Document Repository
1. speichert das Datenobjekt (docData) jedes Dokuments,
2. ruft die Operation registerData des Document Registry auf.
Das Document Registry gibt dem Document Repository eine Status-Meldung.
Das Document Repository gibt dem Resource Manager eine Status-Meldung.

Verteilen einer Einwilligung im EFA-Verbund

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eouns.01.13}

Mit diesem Muster verteilt ein Resource Manager eine Einwilligung im EFA-Verbund. Alle an einer Fallakte beteiligten EFA-Provider können so ihre EFA-Berechtigungsregeln anpassen.

Um eine Einwilligung zu verteilen:

Der Resource Manager ruft für jeden Mount-Point der Fallakte die Operation notifyOfConsent des für den jeweiligen Mount-Point verantwortlichen Resource Manager einer benachbarten Affinity Domain auf.
Der Resource Manager der benachbarten Affinity Domain
1. ruft das die Operation retrieveData des Document Repository der lokalen Affinity Domain auf und erhält das consentInfo,
2. führt das Muster Speichern und Registrieren von Dokumenten aus,
3. berechnet die EFA-Berechtigungsregel und registriert sie beim Policy Provider.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

EFA Anwendungsarchitektur: Service Functional Model

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01}

Die nachfolgende Tabelle listet zu den EFA-Kommunikationsmustern die zu deren Umsetzung benötigten Operationen auf. Die Gesamtheit dieser Operationen bildet das Service Functional Model der EFA-Anwendungsarchitektur, d.h. liefert eine vollständige plattformunabhängige Beschreibung der technisch umzusetzenden EFA-Funktionalität.

Kommunikationsmuster	Operation (logisch)	Umsetzender Dienst (logisch)
Anlegen einer Fallakte	createECR	EFA Ressource Manager
Anlegen einer Partition zu einer bestehenden Fallakte	createPartition	EFA Ressource Manager
Schließen einer Fallakte	closeECR	EFA Ressource Manager
Auflisten von Partitionen	listPartitions	EFA Ressource Manager
Registrierung einer neuen Einwilligung	registerConsent	EFA Ressource Manager
Verteilen einer Einwilligung im EFA-Verbund	notifyOfConsent	EFA Ressource Manager
Anfordern eines Berechtigungstoken	issueAccessToken	EFA Ressource Manager
Einlösen eines Berechtigungstoken	redeemAccessToken	EFA Ressource Manager
	listRecordLocations	EFA Ressource Manager
	registerRecordLocation	EFA Ressource Manager
Einstellen von Dokumenten	provideData	EFA Document Repository
Einstellen von Dokumenten	registerData	EFA Document Registry
Auflisten von Dokumenten (einer Partition)	listPartitionContent	EFA Document Registry
Abrufen von Dokumenten	retrieveData	EFA Document Repository
Invalidieren eines Dokuments	invalidateData	EFA Document Registry

Das Zusammenspiel von Diensten und Operationen ist in der folgenden Darstellung noch einmal im Überblick dargestellt.

Die gestrichelt dargestellten internen Operationsaufrufe vom Ressource Manager zu den anderen Diensten sind optional in dem Sinne als dass die geforderte Funktionalität der Speicherung und Registrierung von Einwilligungen und Einwilligungsdokumenten auch über interne Mechanismen des EFA-Providers erfolgen kann.

Für alle Operationen gilt:

Der vom Teilnehmersystem übermittelte Sicherheitskontext muss gültig, vollständig, authentisch und von einer vertrauenswürdigen Stelle für den Aufrufer ausgestellt worden sein.
Der EFA-Dienst muss den Aufrufer anhand des Eingabeparameters context authentifizieren können.
Die beteiligten Systeme schreiben einen Audit-Trail.

Operationen des EFA Ressource Manager

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01}

Der EFA Ressource Manager muss die in diesem Abschnitt enthaltenen Operationen implementieren.

createECR

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.01}

Operation	createECR
Funktionalität	Diese Operation erzeugt eine Fallakte. Wenn die Fallakte für den Patienten und für den Zweck bereits besteht, werden die bestehende und die neue Fallakte fusioniert. Die Einwilligung der bestehenden Fallakte wird invalidiert und mit der neuen Einwilligung ersetzt.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	patientID	Die ID des Patienten, für den die Fallakte angelegt werden soll.
	purpose	Der Zweck für den die Fallakte angelegt werden soll. Er muss mit dem Zweck übereinstimmen, der im Eingabe-Parameter consentInfo angegeben ist.
	consentInfo	Das strukturierte Dokument, das die Einwilligung des Patienten für die Anlage der Fallakte abbildet.
	consentDoc (optional)	Sofern die Einwilligungserklärung des Patienten als (gescanntes) elektronisches Dokument vorliegt, kann diese bei der Anlage der Akte direkt in die Akte eingestellt werden.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Rückgabe	partitionID	Eindeutige ID der initial zu der neuen Akte angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in die Fallakte, durchführen.
Vorbedingungen	Das übergebene consentInfo Dokument ist konsistent: Die Angaben zum betroffenen Patient MÜSSEN mit den verfügbaren Informationen zum Besitzer der übergebenen Patienten-ID übereinstimmen. Es MUSS ein Zweck benannt sein, der mit dem bei der EFA-Anlage benannten Zweck überein stimmen MUSS. Es ist ein Gültigkeitsdatum benannt. Zumindest ein autorisierter EFA Teilnehmer MUSS benannt und anhand der angegebenen Daten eindeutig identifizierbar sein. Dies KANN die Einrichtung/Person sein, die die Fallakte anlegt. Sofern im consentInfo ein Fallaktenmanager identifiziert ist, MUSS dieser mit der im EFA-Netzwerk für diese Rolle benannten Person übereinstimmen (die Festlegung des Fallaktenmanagers erfolgt nicht durch den Patienten und muss daher nicht zwingend in den kodierten Informationen zur Einwilligung enthalten sein).
Ablauf	Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel. Registriere die EFA-Berechtigungsregel beim Policy Provider. Erzeuge eine Partition. Verknüpfe sie mit ecrRef. Konfiguriere die Metadaten der Partition (partitionInfo). Verknüpfe consentInfo und consentDoc mit der Partition (partitionID). Wenn eine Fallakte für patientID und purpose (ecrRef) existiert: Beachte die Fehlersituation Prohibited Merge. Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc. Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry. Gib die Kennung der neuen Partition (partitionID) und den Status dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen Der angegebene Fallaktenmanager ist in dem EFA-Netzwerk nicht autorisiert, diese Rolle auszufüllen (Fehler).

createPartition

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.02}

Operation	createPartition
Funktionalität	Diese Operation erzeugt eine Partition für eine bestehende Fallakte.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	ecrRef	Eindeutige Identifizierung der Fallakte, zu der die Partition hinzugefügt werden soll.
	partitionInfo	Metadaten zu der neu anzulegenden Partition (Titel, etc.)
	initialDoc (optional)	Bei der Anlage einer Partition können initial in diese Partition einzustellende Dokumente mit übergeben werden.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Rückgabe	partitionID	Eindeutige ID der neu angelegten Partition. Mit Hilfe dieser ID kann der EFA-Teilnehmer weitere Operationen, wie z.B. das Einstellen von Dokumenten in diese Partition, durchführen.
Vorbedingungen	Die übergebenen Metadaten der anzulegenden Partition sind vollständig und valide.
Ablauf	Erzeuge eine Partition. Verknüpfe sie mit dem Eingabeparametern ecrRef und partitionInfo. Verknüpfe initialDoc mit der Partition (partitionID). Speichre und registriere initialDoc bei Document Repository und Document Registry. Gib die Kennung der neuen Partition (partitionID) und den Status dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen Die übergebene partitionInfo ist nicht vollständig oder nicht konsistent zu anderen Angaben. (Fehler)

closeECR

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.03}

Operation	closeECR
Funktionalität	Schließt eine Fallakte. Sie wechselt in den Status "Gesperrt" und ist nur für Fallaktenmanager verfügbar.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	ecrRef	Eindeutige Identifizierung der Fallakte, die geschlossen werden soll.
	consentInfo	Angaben zum Grund für das Schließen der Fallakte (z.B. Rücknahme der Einwilligung durch den Patienten).
	consentDoc (optional)	Sofern die Schließung der Akte auf eine Änderung der Einwilligung zurückzuführen ist, kann eine elektronische Version des entsprechenden Dokuments mit übergeben werden. Hierdurch ist auch nach dem Schließen der Akte der Grund für diese Operation noch nachvollziehbar.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
Ablauf	Ändere den Status der Fallakte (ecrStatus) auf "Gesperrt". Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel. Registriere die EFA-Berechtigungsregel beim Policy Provider. Verknüpfe consentInfo und consentDoc mit einer Partition (partitionID) der Fallakte. Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc. Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry. Gib statusInfo dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

listPartitions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.04}

Operation	listPartitions
Funktionalität	Diese Operation listet die Informationen aller Partitionen (und deren übergeordneten Fallakte) auf, zu denen der Aufrufer über die vom betroffenen Patienten gegebenen Einwilligungen zugangsberechtigt ist.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne, Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	patientID	Die ID des betroffenen Patienten.
	purpose	Einschränkung der Suche auf Akten und Partitionen, die zu einem bestimmten Zweck angelegt wurden.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Rückgabe	partitionList	Liste von nach übergeordneten Fallakten strukturierten Partitionen des Patienten, die im Ergebnis der Suchanfrage gefunden wurden.
Vorbedingungen
Ablauf	Identifiziere alle Partitionen, die mit den Eingabeparametern patientID und purpose verknüpft sind und für welche der Aufrufer (context) zugriffsberechtigt ist. Erstelle das partitionList-Objekt für diese Partitionen. Gib partitionList und statusInfo dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

registerConsent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.05}

Operation	registerConsent
Funktionalität	Registriert eine neue Patienteneinwilligung für eine bestehende Fallakte. Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte werden gemäß der neuen Einwilligung festgesetzt. Die zuvor gültige Einwilligung wird invalidiert.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	ecrRef	Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
	consentInfo docRelationship	Angaben zur neuen Einwilligung auf deren Basis Zweck, Gültigkeitsdauer und Teilnehmerkreis der Akte an Änderungen in der Behandlungsorganisation oder der Behandlungssituation angepasst werden sollen. consentInfo MUSS über docRelationship (Wert "ersetzt") mit dem gültigen consentInfo-Dokument in der Fallakte assoziiert werden.
	consentDoc (optional) docRelationship	Eine ggf. verfügbare elektronische Version des Einwilligungsdokuments kann im Rahmen dieser Operation zur Ablage in der Akte übergeben werden. Wenn consentDoc gegeben ist, dann MUSS consentDoc über docRelationship (Wert "ersetzt") mit dem gültigen consentDoc-Dokument in der Fallakte assoziiert werden.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen	Das übergebene consentInfo Dokument ist konsistent: Es ist ein Gültigkeitsdatum benannt. Die EFA Teilnehmer sind benannt. Die Angaben zu den Rollen der Teilnehmer ermöglichen eine Zuordnung der Teilnehmer zu mit konkreten Zugriffsrechten hinterlegten EFA-Rollen.
Ablauf	Passe ecrRef.purpose der Partitionen der Fallakte an den Zweck der neuen Einwilligung an. Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel. Registriere die EFA-Berechtigungsregel beim Policy Provider. Verknüpfe consentInfo und consentDoc mit einer Partition (partitionID) der Fallakte. Ersetze (docRelationship) das bestehende consentInfo und consentDoc mit dem neuen consentInfo und consentDoc. Speichre und registriere consentInfo und consentDoc bei Document Repository und Document Registry. Gib statusInfo an den Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

notifyOfConsent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.08}

Operation	notifyOfConsent
Funktionalität	Benachrichtigt den EFA Ressource Manager über ein consentInfo-Dokument, das bei einem benachbarten EFA-Provider registriert wurde.
Aufrufer	Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	ecrRef	Eindeutige Identifizierung der Fallakte, zu der eine neue Einwilligung vorliegt.
	documentID	Die Referenz des consentInfo-Dokuments.
Rückgabe
Vorbedingungen
Ablauf	Rufe die Operation retrieveData des Document Repository auf, das im Eingabe-Parameter documentID referenziert ist. Identifiziere die Fallakte, die das abgerufene consentInfo-Dokument referenziert. Übersetze das consentInfo-Dokument in eine EFA-Berechtigungsregel. Passe die bestehende EFA-Berechtigungsregel beim Policy Provider an.
Fehler und Warnungen	Folgende Fehler müssen erkannt und zurückgemeldet werden: Gemeinsame Fehler und Warnungen. Der Eingabe-Parameter documentID referenziert kein consentInfo-Dokument. Die im consentInfo-Dokument referenzierte Fallakte existiert nicht.

listRecordLocations

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.09}

Operation	listRecordLocations
Funktionalität	Listet die an einer Fallakte beteiligten EFA-Provider-Domänen auf.
Aufrufer	Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
Eingabe	ecrRef	Referenziert die Fallakte, deren EFA-Provider-Domänen aufgelistet werden sollen.
Rückgabe	MountPoint*	Liste der Mount-Points
Vorbedingungen
Ablauf	Gib die Liste der Mount-Points dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und zurückgemeldet werden: Gemeinsame Fehler und Warnungen. Der Sicherheitskontext enthält kein Access Policy Token, das von diesem EFA-Provider ausgestellt wurde.

registerRecordLocation

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.01.10}

Operation	registerRecordLocation
Funktionalität	Registriert eine EFA-Provider-Domäne als weiteren Speicherort für Partitionen einer Fallakte. Beim Aufrufer wurde ein Offline-Token eingereicht, das vom aufgerufenen EFA-Provider ausgestellten worden ist.
Aufrufer	Ressource Manager der EFA-Provider-Domäne, in der das Offline-Token eingereicht wurde.
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	MountPoint.sourcePatientId MountPoint.patientId MountPoint.purpose	Referenziert die Fallakte bei dem Peer, bei dem das Offline-Token eingereicht wurde. sourcePatientId ist die lokal gültige Patienten-ID. patientId ist die Patienten-ID, die in der Ziel-Provider-Domäne gültig ist.
	MountPoint.communityID	Kennung der lokalen EFA-Provider-Domäne, bei der das Offline-Token eingereicht wurde.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
Ablauf	Verknüpfe und speichre den Eingabeparameter ecrRef mit der ecrRef-Instanz des accessPolicyToken.
Fehler und Warnungen	Folgende Fehler müssen erkannt und zurückgemeldet werden: Gemeinsame Fehler und Warnungen. Der Sicherheitskontext enthält kein Access Policy Token, das von diesem EFA-Provider ausgestellt wurde.

Operationen des EFA Document Registry

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

Die EFA Document Registry muss die in diesem Abschnitt enthaltenen Operationen implementieren.

registerData

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.02.01}

Operation	registerData
Funktionalität	Diese Operation registriert von Daten an einer bestehenden Partition einer Fallakte.
Aufrufer	Document Repository der gleichen EFA-Provider-Domäne. Die Absicherung der Kommunikation durch einen zwischen beiden Diensten gespannten Sicherheitskontext ist Aufgabe des EFA-Providers und kann mit EFA-unabhängigen Mechanismen realisiert werden.
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	partitionID	Eindeutige Identifizierung der Partition, an der die Daten registriert werden sollen.
	docMetadata[1..*]	Metadaten der bereits im Document Repository abgelegten Daten, die am Document Registry registriert werden sollen.
	docRelationship[0..*]	Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten. Diese müssen so registriert werden, dass sie bei der Auflistung von Dokumenten mit bereit gestellt werden können.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen	Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide. Die Konfiguration der angesprochenen Akte erlaubt das Einstellen der übergebenen Dokumente.
Ablauf	Speichre docMetadata, docRelationship und den Bezug zu partitionID. Gib das statusInfo-Objekt dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

listPartitionContent

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.02.02}

Operation	listPartitionContent
Funktionalität	Diese Operation gibt die Liste der Dokumente, die in einer Partition enthalten sind, zurück. Die Liste enthält die Dokument-Metadaten und Dokument-Beziehungen.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne, Document Registry einer benachbarten EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
Eingabe	partitionID	Eindeutige Identifizierung der Partition, deren Inhalte ausgelesen werden sollen.
Rückgabe	docMetadata[0..*]	Metadaten der an der ausgewählten Partition registrierten Dokumente
Rückgabe	docRelationship[0..*]	Beziehungen zwischen den Dokumenten der zu listenden Partition und Dokumenten dieser und anderer Partitionen.
Vorbedingungen
Ablauf	Identifiziere alle Dokumente, die mit partitionID verknüpft sind und für welche der Aufrufer (context) zugriffsberechtigt ist. Identifiziere alle Dokument-Beziehungen dieser Dokumente. Gib die Metadaten der Dokumente und deren Dokument-Beziehungen dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

invalidateData

Operation	invalidateData
Funktionalität	Invalidieren eines Dokuments in einer Fallakte.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
Eingabe	documentID	Eindeutige Identifizierung des zu invalidierenden Dokuments. Das zu invalidierende Dokument DARF NICHT vom Typ consentInfo oder consentDoc sein.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen
Ablauf	Das Document Registry ... ändert den Wert des Attributs Status des Dokuments auf ungültig. ... sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

Operationen des EFA Document Repository

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.03}

Das EFA Document Repository muss die in diesem Abschnitt enthaltenen Operationen implementieren.

provideData

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.03.01}

Operation	provideData
Funktionalität	Diese Operation stellt Daten in eine Partition einer Fallakte ein.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	partitionID	Eindeutige Identifizierung der Partition, in die die Daten eingestellt werden sollen.
	document[1..*]	In die Partition einzustellende Dokumente mitsamt ihrer Metadaten.
	docRelationship[0..*]	Beziehungen der neu zu registrierenden Daten zu bestehenden Dokumenten.
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Vorbedingungen	Die übergebenen Metadaten der einzustellenden Daten sind vollständig und valide.
Ablauf	Speichre die Dokument-Daten. Rufe die Operation registerData Operation des Document Registry der gleichen Community auf. Übergebe die Eingabeparameter dieser Operation. Gib das statusInfo-Objekt dem Aufrufer.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

retrieveData

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Enndn.01.03.02}

Operation	retrieveData
Funktionalität	Abrufen von Daten aus einer Fallakte.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne, Ressource Manager einer benachbarten EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
Eingabe	documentID	Eindeutige Identifizierung der abzurufenden Dokumente
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
Rückgabe	docData[0..n]	angeforderte Dokumente
Vorbedingungen
Ablauf	Das Document Repository ... ruft die angefragten Dokumente aus dem sicheren Dokumentenspeicher ab. ... sendet eine Information zum Ausführungsstatus der Operation sie wie die angefragten Dokumente an den Nutzer zurück.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Sicherheitstoken und Sicherheitstokendienste

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierz.01}

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

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierz.02}

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 kann neben Angaben zu Rollen und Gruppenzugehörigkeiten des Nutzers je nach Sicherheitspolitik auch ein Proof-of-Possession Merkmal enthalten, über der Provider die Authentizität des Nutzers unmittelbar verifizieren kann (im Gegensatz hierzu wird bei einer mittelbaren Authentizitätsprüfung die Nutzer-Authentizitätsprüfung eines als authentisch geprüften Clientsystems akzeptiert).

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 IHE White Paper on Access Control), wird auch ein Aufruf des Policy Provider durch einen EFA-Anwendungsdienst unterstützt.

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.

Referenzen und Querverweise

EFA-2.0-Spezifikation
Normative Spezifikation: EFA Identity Provider Service Functional Model
Normative Spezifikation: EFA Policy Provider Service Functional Model

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

EFA Identity Provider

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Edtie.01}

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

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 Cross-Enterprise User Assertion (XUA), welches ein Binding auf das SAML- oder WS-Tust-Protokoll spezifiziert (siehe EFA Identity Assertion SAML2 Binding). Der Authentifizierungsnachweis kann weitere Attribute eines EFA-Teilnehmers aus einem Healthcare Provider Directory (HPD) enthalten, welche später für eine Zugriffskontrolle genutzt werden.

Method	requestHPIdentityAssertion(credential Object) : HPIdentityAssertion fault AuthenticationFailedException
Description	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	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)	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.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Gruppierung von Anwendungs- und Sicherheitsdiensten

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Gpruw.01}

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

Aus der Grafik sind die folgenden Gruppierungen ersichtlich:

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.
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.
EFA-Speichersystem	HP Identity Assertion Consumer	Die HP Identity Assertion ist für die Nutzung des EFA-Speichersystems notwendig.
EFA-Speichersystem	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.

Policy Pull

Jeder EFA-Provider muss das im IHE Cookbook beschriebene Verfahren des Policy Pull unterstützen. Hierbei wird vom EFA-Dienst für jede Anfrage die gültige Policy (Berechtigungsregelwerk) ermittelt und ausgewertet. Der EFA Policy Provider zur Verwaltung und Bereitstellung von Berechtigungsregeln ist hierbei ein logischer Dienst, dessen konkrete Umsetzung nicht näher reglementiert ist. Insbesondere ist es dem Hersteller der EFA-Aktendienste überlassen, wie er eine Einwilligungserklärung in eine Policy übersetzt und wie er diese bei einem Aktenaufruf ermittelt und auswertet.

Client Policy Push

Optional kann ein EFA-Provider das in der EFAv1.2 bevorzugt genutzte Policy Push Verfahren unterstützen. Hierbei ruft der Client die für den aktuellen Nutzer gültige Policy für eine zu öffnende Fallakte vom EFA Policy Provider ab. Die Policy wird als Teil des EFA-Nutzerkontextes im Context Manager verwaltet und bei jedem Aufruf eines EFA-Dienstes in Form einer subjectAccessPolicy mitgegeben.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Implementable Perspective

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Verwendete Standards: Sicherheit

Security Assertion Markup Language (SAML)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeenn.01.01}

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.^[1] 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.

SAML Core
Organisation	OASIS
Version	2.0 (März 2005)
Zweck	Abstrakte, XML-basierte Darstellung von vertrauenswürdigen Aussagen in Form von SAML Assertions
Zweck	Abstrakte Protokolle für den Transport der SAML Assertions

Die SAML-Protokolle und deren Nachrichten werden in ^[1] zunächst abstrakt spezifiziert. Wie die Protokolle an ein konkretes Nachrichten- oder Transportprotokoll, beispielsweise SOAP oder HTTP, gebunden werden, wird in ^[2] 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 ^[3] 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 Sicherheitstoken, welche von speziellen Sicherheitstokendiensten ausgestellt werden. Die Assertions erlauben die Kodierung von Identitäts- und Authentifizierungsnachweisen.

Weitere Informationen zu diesem Standard sind im IHE Cookbook zu finden.

eXtensible Access Control Markup Language (XACML)

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

XACML^[4] 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.

XACML
Organisation	OASIS
Version	2.0 (Februar 2005)
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 Cookbook zu finden.

Web Service Security (WS-Security)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeenn.01.03}

WS-Security ^[5] 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.

WS-Security
Organisation	OASIS
Version	1.1 (Februar 2006)
Zweck	Nachrichtensicherheit auf Nachrichtenebene, Bereitstellung von Mechanismen für höhere Sicherheitsprotokolle
Erweiterungen	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)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeenn.01.04}

WS-Trust ^[6] 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.

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 Cookbook.

Referenzen und Querverweise

↑ ^1,0 ^1,1 S. Cantor et al. (2005), Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.
↑ S. Cantor et al. (2005), Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0.
↑ J. Hughes et al. (2005), Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0.
↑ T. Moses (2005), eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS.
↑ A. Nadalin et al. (2006), Web Service Security: SOAP Message Security 1.1. OASIS.
↑ A. Nadalin et al. (2007), WS-Trust 1.3. OASIS.

zurück zur EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Mapping of Core Information Model Classes

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {MdaBs.01}

This section defines the XDS-Metadata bindings for the classes of the EFA core information model.

The following table describes how EFA classes MUST be mapped to classes and object types of IHE ITI.

EFA core information model	IHE ITI
Patient	Patient
eCR CaseRecord	Set of Folder-objects, that have values of Folder.patientID and Folder.codeList in common
eCR Partition	Folder
eCR Medical Data Object	DocumentEntry for metadata, Document for binary data

The object type SubmissionSet of IHE ITI has no corresponding class of the EFA core information model. Therefore, SubmissionSet SHALL be used as specified in IHE ITI but it MUST NOT have EFA semantics.

Mapping of PIM Classes

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {MdaBs.01}

This section defines the XDS-Metadata bindings for the classes of the EFA platform independent model.

Instances of ECR PIM Classes are shared through XD* transactions and within XD* metadata. The following table shows the respective binding of these classes to IHE XD* message arguments and ebRS metadata slots/elements.

EFA PIM	IHE ITI Metadata Model	Comments
patientID	Folder.patientId DocumentEntry.patientId	-
communityID	DocumentEntry.homeCommunityId Folder.homeCommunityId	-
purpose	Folder.codeList	see XDS Folder Metadata
consentInfo	Document	ECR consentInfo objects are represented as structured, coded documents. See "Leitfaden Patienteneinwilligung" for details. The binding of consentInfo is not subject to the EFA Specification. An EFA domain must agree on a specific binding. Implementation Guide for CDA®, Release 2: Consent Directives, Release 1 MAY be used.
consentDoc	Document	Consent documents are represented as documents of a format that is to be agreed by each ECR domain (e.g. PDF/A).
partitionID	Folder.uniqueId	see IHE ITI TF Vol3 section 4.1.9.1 for details
partitionList	set of Folder objects	-
ecrRef	Folder.patientId Folder.codeList Folder.homeCommunityId	Folders that have the same patient ID and the same purpose codes form a distinct case record. The homeCommunityId indicates the XDS Affinity Domain where the reference is valid.
partitionInfo	Folder	see XDS Folder Metadata for details
docMetadata	DocumentEntry	see XDS Document Metadata for details
docRelationship	Document Relationship	see Append and Replace in IHE ITI TF-3#4.1.2
documentID	DocumentEntry.uniqueId DocumentEntry.repositoryUniqueId	shall be used for document retrieval (retrieveDocument transaction).
documentID	DocumentEntry.entryUUID	shall be used for document referral (associations between registry entries)

MountPoint

Instances of the EFA PIM class MountPoint SHALL be bound to DocumentEntry as follows:

ECR PIM MountPoint attribute	IHE XDS Metadata Attribute	Comments
patientID	DocumentEntry.patientId
sourcePatientID	DocumentEntry.sourcePatientId
communityID	DocumentEntry.homeCommunityId

The DocumentEntry SHALL be a member of a Folder. This Folder SHALL have a codeList classification containing

(code="ECR-mountpoint", codeSystem="IHE-D-Cookbook-FolderClassCode") and
a purpose code.

ecrStatus

The EFA PIM class ecrStatus MUST be implemented by means of access policies. The values of ecrStatus MUST correspond to access policies and system configuration as follows:

Open: The access policy implements the patient's consent.
Suspended: The access policy implements the patient's consent with the exception that only the consented case record manager and their substitutes are authorized.
Retired: No access policy permits access to the case record.
Archived: No XDS metadata and no documents reside in the EFA system.

The IHE ITI TF-3 states that the value of the XDS attribute Folder.availabilityStatus must always be Approved. Therefore, the lifecycle of case records does not correspond to this XDS attribute.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Folder Metadata

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDold.01}

Instances of the partitionInfo ECR PIM Class are shared through XD* transactions and within XDS folder metadata. The following table shows the respective binding of the partitionInfo subelements to IHE XDS Folder ebRS metadata slots/elements.

partitionInfo	IHE XDS Folder Metadata	Comments
partitionID	XDSFolder.uniqueID	see IHE ITI TF Vol3 section 4.1.9.1 for details
title	XDSFolder.title	see IHE ITI TF Vol3 section 4.2.3.4.8 for details on the encoding of folder titles. ECR partition (XDS folder) titles SHALL NOT contain the name of the patient.
classification (purpose)	XDSFolder.codeList	see additional profiling for eCR purpose codes below
time.startTime	-	This eCR partitionInfo element cannot be mapped to IHE XDS Folder Metadata. Client-side implementations of the partitionInfo data structure SHALL allow for NULL-Values for this element.
time.endTime	XDSFolder.lastUpdateTime	As this element is mainly used for sorting partitions, the last update time of the corresponding folder is considered a good indicator for this purpose.
organization	XDSFolder.comments	This eCR partitionInfo element cannot be mapped to "regular" IHE XDS Folder Metadata. Client-side implementations of the partitionInfo data structure SHALL allow for NULL-Values for this element.
anchor	XDSFolder.codeList	The creator of a XDS folder may add further classifications to the corresponding eCR partition. Beside the purpose-clasification, eCR participants SHALL NOT process classifications that were defined by other participants.

Folder metadata which are not profiled in the table MUST be used as defined in table 4.1-7 of [IHE ITI TF Vol3 v9.0]. Further constraints MAY apply for EFA national profiles.

codeList

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDold.01.01}

Through a coded value in the XDS filder codeList attribute, an XDS Folder SHALL be marked as part of an eCR. The respective coded value SHALL contain either the EFA-Folder classification code (code="ECR", codeSystem="1.3.6.1.4.1.19376.3.276.1.5.7") or the EFA-Mount-Point classification code (code="ECR-mountpoint", codeSystem="1.3.6.1.4.1.19376.3.276.1.5.7").

An second coded value in the XDS folder codeList attribute SHALL signal the purpose of the case record. Only codes from the code system 1.2.276.0.76.3.1.81.81.5.6 SHALL be used.

Example

 <rim:Classification 
    id="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
    lid="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
    classificationScheme="urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5"
    classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" 
    nodeRepresentation="ECR">
    <rim:Slot name="codingScheme">
        <rim:ValueList>
            <rim:Value>1.3.6.1.4.1.19376.3.276.1.5.7</rim:Value>
        </rim:ValueList>
    </rim:Slot>
    <rim:Name>
        <rim:LocalizedString xml:lang="de" charset="UTF-8" value="Elektronische Fallakte"/>
    </rim:Name>
 </rim:Classification>

 <rim:Classification 
    id="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
    lid="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
    classificationScheme="urn:uuid:1ba97051-7806-41a8-a48b-8fce7af683c5"
    classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" 
    nodeRepresentation="Test:Connectathon-2016:Sinusitis-Demo">
    <rim:Slot name="codingScheme">
        <rim:ValueList>
            <rim:Value>1.2.276.0.76.3.1.81.81.5.6</rim:Value>
        </rim:ValueList>
    </rim:Slot>
    <rim:Name>
        <rim:LocalizedString xml:lang="de" charset="UTF-8" value="Connectathon 2016 Sinusitis Demo"/>
    </rim:Name>
 </rim:Classification>

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Document Metadata

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.01}

The table below shows how eCR folder attributes map onto IHE XDS Folder metadata and vice versa:

EFA Metadata	IHE documentEntry Attribute	Remarks and Usage Constraints
Verantwortliche Organisation	author	EFA demands for registering the organization that takes responsibility for providing a document while IHE only allows to register the person/device (and organisation) that created the document. As it is assumed that provider of a document either ist the author of the document or acts on behalf the author of the document, the EFA "responsible organization" object is mapped onto an IHE "documentEntry.author" element. In cases these semantics conflict, the IHE semantics of "documentEntry.author" according to IHE ITI TF-3#4.2.3.2.1 shall be followed.
Status	availabilityStatus	shall be used according to IHE ITI TF-3#4.2.3.2.2.
Dokumentklasse	classCode	see below
	comments	see below
	confidentialityCode	shall always be "N" for EFA
Zeitpunkt der Bereitstellung		EFA demands for registering the timestamp when a document was provided to an EFA. IHE XDS does not assign this information to single document entry but to the submissions set which was used for registering a set of documents with an XDS Document Registry. EFA implementations SHALL therefore map this logical attribute onto the XDS submission set's submissionTime attribute.
	creationTime	shall be used according to IHE ITI TF-3#4.2.3.2.6.
	entryUUID	shall be used according to IHE ITI TF-3#4.2.3.2.7.
	eventCodeList	shall be used according to IHE ITI TF-3#4.2.3.2.8.
	formatCode	shall be used according to IHE ITI TF-3#4.2.3.2.9.
Fehlererkennender Code	hash	shall be used according to IHE ITI TF-3#4.2.3.2.10.
	healthcareFacilityTypeCode	shall be used according to IHE ITI TF-3#4.2.3.2.11.
	homeCommunityId	shall be used according to IHE ITI TF-3#4.2.3.2.12.
	languageCode	shall be used according to IHE ITI TF-3#4.2.3.2.13.
	legalAuthenticator	shall be used according to IHE ITI TF-3#4.2.3.2.14. For consent documents this element shall record the person/organization that validated the patient's consent and registered it with EFA.
Dokumentformat	mimeType	shall be used according to IHE ITI TF-3#4.2.3.2.15.
patientID	patientId	shall be used according to IHE ITI TF-3#4.2.3.2.16. EFA Document Registry actors shall verify that the patient matches the person who gave consent to the respective EFA.
	practiceSettingCode	shall be used according to IHE ITI TF-3#4.2.3.2.17.
	repositoryUniqueId	shall be used according to IHE ITI TF-3#4.2.3.2.18.
Zeitliche Einordnung	serviceStartTime	shall be used according to IHE ITI TF-3#4.2.3.2.19.
Zeitliche Einordnung	serviceStopTime	shall be used according to IHE ITI TF-3#4.2.3.2.20.
Dateigröße	size	shall be used according to IHE ITI TF-3#4.2.3.2.21.
	sourcePatientId	shall be used according to IHE ITI TF-3#4.2.3.2.22.
	sourcePatientInfo	This element shall not be used for EFA.
Titel	title	shall be used according to IHE ITI TF-3#4.2.3.2.24.
Dokumenttyp	typeCode	see below
documentID	uniqueId	shall be used according to IHE ITI TF-3#4.2.3.2.25.
	URI	shall be used according to IHE ITI TF-3#4.2.3.2.26.
	referenceIdList	shall be used according to IHE ITI TF-3#4.2.3.2.27.
	limitedMetadata	Limited metadata are not allowed for IHE XDS document sources and therefore the respective option SHALL NOT be used by EFA implementations.
	objectType	shall be used according to IHE ITI TF-3#4.2.3.2.29.
Signatur		Documents provided to an EFA may be digitally signed. In this case, the constraints and means defined by the IHE ITI DSG integration profile shall be considered.

classCode

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.01.01}

The document class shall be taken from a national catalogue. The national catalogue should be a value set on top of LOINC as a reference terminology.

typeCode

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

The document type shall be provided as a LOINC code. Document types shall be more specific than document classes. They may be defined per Care Domain.

Example:

 <rim:Classification 
    id="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
    lid="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
    classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
    classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" 
    nodeRepresentation="11520-4">
    <rim:Slot name="codingScheme">
        <rim:ValueList>
            <rim:Value>2.16.840.1.113883.6.1</rim:Value>
        </rim:ValueList>
    </rim:Slot>
    <rim:Name>
        <rim:LocalizedString xml:lang="de" charset="UTF-8" value="EKG Befund"/>
    </rim:Name>
 </rim:Classification>

Comments

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.01.03}

This slot is optional. If given, it SHALL hold a summary of the document content.

Example:

<rim:Description>
   <rim:LocalizedString xml:lang="de" charset="UTF-8" value = "Befund zur Magenspiegelung vom 3.3.13"/>
</rim:Description>

German Profile

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.02}

For using EFA within the German national healthcare IT infrastructure (Telematikinfrastruktur) the constraints listed below MUST be considered.

Author Institution

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.02.01}

For the German healthcare system the following identification schemes MUST be used. If multiple schemes are available for an organization, the order in the table denotes the order of preference.

Organization	Scheme	Code System OID
Practice	Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the SMC-B AUT certificate of the practice.	1.2.276.0.76.4.188
Practice	»Institutskennzeichen (IK)« acc. to § 293 SGB V	1.2.276.0.76.4.5
Practice	KBV »Arztnummer Praxis«	1.2.276.0.76.4.10
Practice	Any internal identification scheme that guarantees a unique identification within the scope of the affinity domain. Identifiers SHALL be resolvable to all EFA participants through public directory services (e.g. HPD, see IHE-Cookbook).	local code system
Hospital department or faculty	Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the SMC-B AUT certificate of the department/faculty.	1.2.276.0.76.4.188
Hospital department or faculty	Any internal identification scheme that guarantees a unique identification within the scope of the affinity domain. Identifiers SHALL be resolvable to all EFA participants through public directory services (e.g. HPD, see IHE-Cookbook).	local code system
Hospital	Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the SMC-B AUT certificate of the hospital.	1.2.276.0.76.4.188
Hospital	»Institutskennzeichen (IK)« acc. to § 293 SGB V	1.2.276.0.76.4.5
Hospital	Any internal identification scheme that guarantees a unique identification within the scope of the affinity domain. Identifiers SHALL be resolvable to all EFA participants through public directory services (e.g. HPD, see IHE-Cookbook).	local code system

Telematik ID and SMC-B certificates will only be available with the Telematik-Infrastruktur. Before the final roll-out of the Telematik-Infrastruktur identifiers based on Telematik ID and SMC-B SHOULD NOT be used.

Example:

A resident practice with the Institutskennzeichen 260326822 would be encoded as:

<rim:Slot name="authorInstitution">
  <rim:ValueList>
    <rim:Value>Name der Praxis^^^^^&1.2.276.0.76.4.5&ISO^^^^260326822</rim:Value> 
  </rim:ValueList>
</rim:Slot>

Author Person

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.02.02}

For the German healthcare system the following identification schemes MUST be used. If multiple schemes are available for an author's ID, the order in the table denotes the order of preference. If multiple IDs are known, at least two SHOULD be provided (considering the order of preference). An author identifier SHALL NOT be used without additionally providing the full name of the author.

Person Role	Scheme	Code System OID
Physician	Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the HBA AUT certificate of the physician.	1.2.276.0.76.4.188
Physician	Lebenslange Arztnummer KV	1.2.276.0.76.4.16
Physician Hospital Staff Practice Staff	Any internal identification scheme that guarantees a unique identification within the scope of the identified organization. The <authorInstitution> and an <id> for this organization MUST be recorded.	local code system

Telematik ID and HBA certificates will only be available with the Telematik-Infrastruktur. Before the final roll-out of the Telematik-Infrastruktur identifiers based on Telematik ID and HBA SHOULD NOT be used.

Example:

A physician with the Arztnummer 12345678 would be encoded as:

<rim:Slot name="authorPerson">
  <rim:ValueList>
    <rim:Value>Name des Arztes^^^^^&1.2.276.0.76.4.16&ISO^^^^12345678</rim:Value> 
  </rim:ValueList>
</rim:Slot>

HealthcareFacilityTypeCode

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.02.03}

The healthcare facility type code SHALL be encoded as a coded value acc to the KBV Schlüsseltabelle S_VDX_PRAXISTYP ([1]). The root OID 1.2.276.0.76.3.1.1.5.1.4 SHALL be used.

Example:

A hospital facility type would be encoded as:

<rim:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
                    classifiedObject="theDocument" id=”ID_050"
                    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
                    nodeRepresentation="50">
    <rim:Name>
        <rim:LocalizedString xml:lang="de" value="Krankenhaus"/>
    </rim:Name>
    <rim:Slot name="codingScheme">
       <rim:ValueList>
           <rim:Value>1.2.276.0.76.3.1.1.5.1.4</rim:Value>
       </rim:ValueList>
    </rim:Slot>
</rim:Classification>

sourcePatientInfo

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDoct.02.04}

For reasons of protecting the confidentiality of personal medical information this slot SHALL NOT be used. For the identifing the patient the sourcePatientId element SHALL be provided for all documents metadata.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Security Object Bindings

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeris.01}

EFA security objects are encapsulated through SAML assertions so as the following mapping of security objects MUST be implemented:

Electronic Case Record	SAML
Authentication Token / HP Identity Assertion	EFA Identity Assertion SAML2 Binding
Authorization Token / Access Policy	EFA Policy Assertion SAML2 Binding

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

SAML 2.0 Profile for ECR Identity Assertions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {ItyAn.01}

Assertion Element				Opt	Usage Convention
@Version				R	MUST be “2.0”
@ID				R	URN encoded unique identifier (UUID) of the assertion
@IssueInstant				R	time instant of issuance in UTC
Issuer				R	address URI that identifies the endpoint of the issuing service
Subject				R	This element defines the subject confirmation method of the user in order to use the Identity Assertion as a protection token. Moreover, it defines the subject name identifier that accords with the user identity.
	NameID			R	Identifier of the HP 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.
		@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.
	SubjectConfirmation			R
		@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 or urn:oasis:names:tc:SAML:2.0:cm:bearer If the bearer method is used, the EFA Identity Assertion SHALL only be exchanged over secure channels with trusted endpoints in order to maintain confidentiality and message integrity.
		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].
Conditions				R
	@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.
	@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 an HCP Identity Assertion MUST NOT be more than 4 hours.
AuthnStatement				R
	@AuthnInstant			R	time instant of HP authentication in UTC
	@SessionNotOnOrAfter			O	Time instant of the expiration of the session
	AuthnContext			R
		AuthnContextClassRef		R	A URI reference that specifies the type of authentication that took place (see SAML 2.0).
AttributeStatement				R	HP identity attributes and permissions (see section below for details)
ds:Signature				R	Enveloped XML signature of the issuer of the HCP Identity Assertion (see section below for details).

German Profile

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {ItyAn.01.05}

The subject must refer to a health professional. The subject identifier must be provided as an OID. Only the following identitification schemes must be used. The order of the table denotes the order of preference.

Person Role	Scheme	Code System OID
Physician	Telematik ID This ID scheme MUST be preferred only if the Telematik ID is recorded within the HBA AUT certificate of the physician.	not defined yet
Physician	ID of the HBA AUT Certificate	1.2.276.0.76.4.75
Physician	Lebenslange Arztnummer KV	1.2.276.0.76.4.16
Physician Hospital Staff Practice Staff	Any internal identification scheme that guarantees a unique identification within the scope of the identified organization. The <representedOrganization> and an <id> for this organization MUST be recorded.	local code system

Telematik ID and HBA certificates will only be available with the Telematik-Infrastruktur. Before the final roll-out of the Telematik-Infrastruktur identifiers based on Telematik ID and HBA SHOULD NOT be used.

Assertion Signature

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {ItyAn.01.01}

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

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 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.

HCP Identity Attributes

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

An identity assertion can carry an arbitrary number of attributes on the authenticated entity. Each attribute MUST be encoded using a SAML attribute element.

For ECR the following attribute names and catalogues are defined.

HP Identifier
FriendlyName	XSPA Subject
Name	urn:oasis:names:tc:xacml:1.0:subject:subject-id
Values	person’s full name according to http://www.ietf.org/rfc/rfc2256.txt chapter 5.4.
Type	String
Optionality	Mandatory
Description	This attribute SHALL contain the full name of the HP.

Structural Role of the HCP
FriendlyName	XSPA Role
Name	urn:oasis:names:tc:xacml:2.0:subject:role
Values	See ASTM E1986-98 (2005). Only the ASTM structural roles “dentist”, “nurse”, “pharmacist”, “physician”, “nurse midwife”, “admission clerk”, “ancillary services”, “clinical services”, and “health records management” MUST be used.
Type	String
Optionality	Mandatory

Delegated Rights
FriendlyName	OnBehalfOf
Name	urn:epsos:names:wp3.4:subject:on-behalf-of
Values	See ASTM E1986-98 (2005). Only the ASTM structural roles “dentist”, “pharmacist”, “physician”, “nurse midwife”, and “health record management” MUST be used.
Type	String
Optionality	Mandatory if a structural role of “ancillary services”, or “clinical services” is presented. For all other structural roles this attribute is optional
Description	If a person is acting on behalf of another person the role of this person MAY be provided with this attribute. If this attribute is included with a HCP identity assertion, the issuer of the assertion MUST be able to track back the delegation to the two natural persons involved. Only valid roles as defined for HCP structural roles MUST be used. An assertion consumer MAY decide not to accept delegated access rights by just ignoring this attribute.

Healthcare Professional Organisation
FriendlyName	XSPA Organization
Name	urn:oasis:names:tc:xspa:1.0:subject:organization
Values	Name of the Healthcare Professional Organisation
Type	String
Optionality	Optional
Description	This value SHOULD only be provided if different from the point of care (e.g. in cases where a hospital organization runs multiple points of care or where a hospital just provides a professional environment for otherwise independent care providers)

Healthcare Professional Organisation ID
FriendlyName	XSPA Organization Id
Name	urn:oasis:names:tc:xspa:1.0:subject:organization-id
Values	URN encoded OID of the Healthcare Professional Organisation
Type	URI
Optionality	Mandatory

Purpose of Use
FriendlyName	XSPA Purpose of Use
Name	urn:oasis:names:tc:xspa:1.0:subject:purposeofuse
Values	MUST be TREATMENT
Optionality	Optional
Description	ECR access is only granted for treatment purposes.

Point of Care
Attribute Name	XSPA Locality
Name	urn:oasis:names:tc:xspa:1.0:environment:locality
Values	String
Optionality	Optional
Description	Name of the hospital or medical facility where patient care takes place.

ECR regional networks MAY agree on further attributes. Any attributes not listed in this list MAY be ignored by the assertion consumer.

German Extensions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {ItyAn.01.03}

Speciality of the HP
FriendlyName	EFA HP Organization Specialty
Name	urn:efa:2-0:subject:organization:specialty
Values	Values shall be taken from the value set 1.2.276.0.76.11.37 as defined by IHE Germany.
Type	String
Optionality	Optional
Description	EFA permissions are preferrably managed on the abstraction level of organizations. Therefore the respective clinical specialty of the identified EFA user's organization may be provided as an attribute to a HP Identity Assertion.

Example

   <saml:Attribute 
    FriendlyName="EFA HP Organization Specialty" 
    Name="urn:efa:2-0:subject:organization:specialty" 
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue 
     xmlns:xs="http://www.w3.org/2001/XMLSchema" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:type="xs:string">ALLG
    </saml:AttributeValue>
   </saml:Attribute>

Example Assertion

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {ItyAn.01.04}

 <soap12:Envelope … >
 <soap12:Header … >
  <wsse:Security … > 
   <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                   ID="_2c356d70-1215-42f9-93a0-fc6fab1c966e" 
                   IssueInstant="2009-09-21T12:03:28.788Z" Version="2.0">
   <saml:Issuer>urn:de:berlin:hp:idp</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>cH+lCY … </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="2012-09-21T12:03:28.788Z" 
      NotOnOrAfter="2012-09-21T16:03:28.788Z">
    </saml:Conditions>
    <saml:AuthnStatement 
     AuthnInstant="2012-09-21T12:03:28.788Z" 
     SessionNotOnOrAfter="2012-09-21T16:03:28.788Z">
     <saml:AuthnContext>
     <saml:AuthnContextClassRef>
      urn:oasis:names:tc:SAML:2.0:ac:classes:X509
     </saml:AuthnContextClassRef>
     </saml:AuthnContext>
    </saml:AuthnStatement>
   <saml:AttributeStatement>
   <saml:Attribute 
    FriendlyName="XSPA Subject" 
    Name="urn:oasis:names:tc:xacml:1.0:subject:subject-id" 
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue 
     xmlns:xs="http://www.w3.org/2001/XMLSchema" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:type="xs:string">Dr. Peter Meier
    </saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute 
    FriendlyName="XSPA Organization" 
    Name="urn:oasis:names:tc:xspa:1.0:subject:organization" 
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue 
     xmlns:xs="http://www.w3.org/2001/XMLSchema" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:type="xs:string">Kreiskrankenhaus Neustadt
    </saml:AttributeValue>
   </saml:Attribute>
   </saml:Attribute>
   <saml:Attribute 
    FriendlyName="XSPA Role" 
    Name="urn:oasis:names:tc:xacml:2.0:subject:role" 
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue 
     xmlns:xs="http://www.w3.org/2001/XMLSchema" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:type="xs:string">physician
    </saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute 
    FriendlyName="XSPA Purpose of Use" 
    Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse" 
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue 
     xmlns:xs="http://www.w3.org/2001/XMLSchema" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:type="xs:string">TREATMENT
    </saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute 
    FriendlyName="XSPA Locality" 
    Name="urn:oasis:names:tc:xspa:1.0:environment:locality" 
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml:AttributeValue 
     xmlns:xs="http://www.w3.org/2001/XMLSchema" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:type="xs:string">Kreiskrankenhaus Neustadt
    </saml:AttributeValue>
   </saml:Attribute>
  </saml:AttributeStatement>
 </saml:Assertion>
</wsse:Security>
</pre>

Referenzen und Querverweise

EFA-2.0-Spezifikation

cdaefa:EFA Access Assertion SAML2 Binding

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

SAML 2.0 Profile for ECR Policy Assertions

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocyo.01}

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.

Assertion Element				Opt	Usage Convention
@Version				R	MUST be “2.0”
@ID				R	URN encoded unique identifier (UUID) of the assertion
@IssueInstant				R	Time instant of issuance in UTC
Issuer				R	Address URI that identifies the endpoint of the issuing service
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.
	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.
		@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.
	SubjectConfirmation			R
		@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
		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].
Conditions				R
	@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.
	@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.
XACMLPolicyStatement				R
	PolicySet			R	PolicySet that expresses the given authorization (see section below for details).
ds:Signature				R	Enveloped XML signature of the issuer of the Policy Assertion (see section below for details).

PolicySet Profile

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocyo.01.01}

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 Policy Provider. These are:

Reference without semantics (policyId) to an access policy which contains the valid authorization rules for an eCR Consumer
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

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

Element or Attribute				Opt.	Constraints
PolicySet				R
	@PolicySetId			R	Shall be of type UUID or OID. Shall not be URN encoded.
	@PolicyCombiningAlgId			R	Shall be urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides.
	Target			R
		Resources		R
			Resource	R	Shall contain at least: ResourceMatch for EFA Folder classification, ResourceMatch for purpose classification, ResourceMatch for patientId.
		Actions		R	May contain Action elements that qualify the use of specific operations in the context of an EFA.
	Policy			cond. R	Shall be the policy for the subject stated in the ECR Policy Assertion. This element shall conform to one of Policy Attachment for a health professional or Policy Attachment for health record managers. Either Policy or PolicyIdReference shall be used.
	PolicyIdReference			cond. R	Shall be the reference to the policy for the subject stated in the ECR Policy Assertion. This referenced policy shall conform to one of: Policy Attachment for a health professional or Policy Attachment for health record managers. Either Policy or PolicyIdReference shall be used.

Policy Attachment for a health professional

If not in the role of a health record manager, health professionals may have access to the health record if it neither suspended nor retired.

Element or Attribute							Opt.	Constraints
Policy							R
	@PolicyId						R	Shall be of type UUID or OID. Shall not be URN encoded.
	@RuleCombiningAlgId						R	Shall be urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides
	Target						R
		Subjects					R
			Subject				R
				SubjectMatch			R	Shall contain at leat one of the following SubjectMatch elements: SubjectMatch for EFA Identity Assertion NameID, SubjectMatch for health professional ID, and SubjectMatch for health professional organization ID. Shall contain a SubjectMatch for structural role with attribute value of dentist, pharmacist, physician, or nurse midwife.
		Resources					R
			Resource				R
				ResourceMatch			R	Restricts access to open ECRs. This match relates to ecrStatus. It applies the IHE-D Cookbook XACML binding of DocumentEntry.availabilityStatus.
					@MatchId		R	Shall be urn:oasis:names:tc:xacml:1.0:function:anyURI-equal
					AttributeValue		R	Shall be urn:oasis:names:tc:ebxml-regrep:StatusType:Approved
						@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#anyURI
					ResourceAttributeDesignator		R
						@AttributeId	R	Shall be urn:ihe:iti:xds-b:2007:availability-status
						@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#anyURI
		Environments					R
			Environment				R
				EnvironmentMatch			R	Verifies, that the current date is before the date of expiry, i. e. the grace period has not started.
					@MatchId		R	Shall be urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than-or-equal
					AttributeValue		R	Shall be the point in time when ecrStatus of the record changes to suspended.
						@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#dateTime
					EnvironmentAttributeDesignator		R
						@AttributeId	R	Shall be urn:oasis:names:tc:xacml:1.0:environment:current-dateTime
						@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#dateTime

Policy Attachment for health record managers

Health professionals in the role of a health record manager may have access to the health record if it is suspended but nor retired.

Element or Attribute							Opt.	Constraints
Policy							R
	@PolicyId						R	Shall be of type UUID or OID. Shall not be URN encoded.
	@RuleCombiningAlgId						R	Shall be urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides
	Target						R
		Subjects					R
			Subject				R	Shall contain at leat one of the following SubjectMatch elements: SubjectMatch for EFA Identity Assertion NameID, SubjectMatch for health professional ID, and SubjectMatch for health professional organization ID Shall contain a SubjectMatch for structural role with attribute value health record management.
		Environments					R
			Environment				R
				EnvironmentMatch			R	Verifies, that the current date is before the end of the grace period.
					@MatchId		R	Shall be urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than-or-equal
					AttributeValue		R	Shall be the point in time when ecrStatus of the record changes to retired.
						@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#dateTime
					EnvironmentAttributeDesignator		R
						@AttributeId	R	Shall be urn:oasis:names:tc:xacml:1.0:environment:current-dateTime
						@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#dateTime

SubjectMatch for EFA Identity Assertion NameID

This SubjectMatch element relates to the saml:NameID element of the EFA Identity Assertion.

This element applies the IHE-D Cookbook XACML binding of User ID.

Element or Attribute			Opt.	Constraints
SubjectMatch			R
	@MatchId		R	Shall be urn:oasis:names:tc:xacml:1.0:function:string-equal
	AttributeValue		R	Shall be equal to saml:NameID used for the subject. See EFA Identity Assertion
		@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#string
	SubjectAttributeDesignator		R
		@AttributeId	R	Shall be urn:oasis:names:tc:xacml:1.0:subject:subject-id
		@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#string

SubjectMatch for health professional ID

This SubjectMatch element relates to the health professional identifier of the EFA Identity Assertion.

Element or Attribute			Opt.	Constraints
SubjectMatch			R
	@MatchId		R	Shall be urn:oasis:names:tc:xacml:1.0:function:string-equal
	AttributeValue		R	Shall be equal to the HP Identifier as defined for EFA Identity Assertion.
		@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#string
	SubjectAttributeDesignator		R
		@AttributeId	R	Shall be urn:oasis:names:tc:xacml:1.0:subject:subject-id
		@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#string

SubjectMatch for structural role

This SubjectMatch element relates to the Structural Role of the EFA Identity Assertion.

Element or Attribute				Opt.	Constraints
Subject				R
	SubjectMatch			R
		@MatchId		R	Shall be urn:oasis:names:tc:xacml:1.0:function:string-equal
		AttributeValue		R	Shall be one of the following roles defined in ASTM E1986-98 (2005): dentist, pharmacist, physician, nurse midwife, or health record management.
			@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#string
		SubjectAttributeDesignator		R
			@AttributeId	R	Shall be urn:oasis:names:tc:xacml:2.0:subject:role'
			@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#string

SubjectMatch for health professional organization ID

This SubjectMatch element relates to the HP Organization ID of the EFA Identity Assertion.

This element applies the IHE-D Cookbook XACML binding of User Organization ID.

Element or Attribute			Opt.	Constraints
SubjectMatch			R
	@MatchId		R	Shall be urn:oasis:names:tc:xacml:1.0:function:anyURI-equal
	AttributeValue		R	Shall be the URN encoded OID of the Healthcare Professional Organisation.
		@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#anyURI
	SubjectAttributeDesignator		R
		@AttributeId	R	Shall be urn:oasis:names:tc:xspa:1.0:subject:organization-id
		@DataType	R	Shall be http://www.w3.org/2001/XMLSchema#anyURI

ResourceMatch for EFA Folder classification

This ResourceMatch element relates to the Folder.codeList entry which indicates an EFA Folder.

This element applies the IHE-D Cookbook XACML binding of Folder.codeList.

Element or Attribute				Opt.	Constraints
ResourceMatch				R
	@MatchId			R	Shall be urn:hl7-org:v3:function:CV-equal (see IHE DE Cookbook, XACML Binding).
	AttributeValue			R
		@DataType		R	Shall be urn:hl7-org:v3#CV.
		hl7:CodedValue		R
			@code	R	Shall be ECR.
			@codeSystem	R	Shall be IHE-D-Cookbook-FolderClassCode.
	ResourceAttributeDesignator			R
		@AttributeId		R	Shall be urn:ihe:iti:xds-b:2007:folder:code.
		@DataType		R	Shall be urn:hl7-org:v3#CV.

ResourceMatch for purpose classification

This ResourceMatch element relates to the Folder.codeList entry which indicates the purpose.

This element applies the IHE-D Cookbook XACML binding of Folder.codeList.

Element or Attribute				Opt.	Constraints
ResourceMatch				R
	@MatchId			R	Shall be urn:hl7-org:v3:function:CV-equal (see IHE DE Cookbook, XACML Binding).
	AttributeValue			R
		@DataType		R	Shall be urn:hl7-org:v3#CV.
		hl7:CodedValue		R
			@code	R	Shall be equal to the purpose code of the case record.
			@codeSystem	R	Shall be equal the purpose codingScheme of the case record.
	ResourceAttributeDesignator			R
		@AttributeId		R	Shall be urn:ihe:iti:xds-b:2007:folder:code
		@DataType		R	Shall be urn:hl7-org:v3#CV.

ResourceMatch for patientId

This ResourceMatch element relates to Folder.patientId and DocumentEntry.patientId.

This element applies the IHE-D Cookbook XACML binding of Folder.patientId.

Element or Attribute				Opt.	Constraints
ResourceMatch				R
	@MatchId			R	Shall be urn:hl7-org:v3:function:II-equal (see IHE DE Cookbook, XACML Binding).
	AttributeValue			R
		@DataType		R	Shall be urn:hl7-org:v3#II.
		hl7:InstanceIdentifier		R
			@extension	R	Shall be equal to the Id-Number value of the XDS Metadata Attributes patientId.
			@root	R	Shall be equal to the Assigning-Authority value of the XDS Metadata Attributes patientId.
	ResourceAttributeDesignator			R
		@AttributeId		R	Shall be urn:ihe:iti:xds-b:2007:patient-id.
		@DataType		R	Shall be urn:hl7-org:v3#II.

Assertion Signature

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocyo.01.04}

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.

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 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

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocyo.01.05}

 <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>
<PolicySet xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"
  xmlns:hl7="urn:hl7-org:v3"
  xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:os access_control-xacml-2.0-policy-schema-os.xsd"
  PolicySetId="2B789DEE-9CB6-11E4-97F9-246A95DB5880"
  PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides">
  <Target>
    <Resources>
      <Resource>
        <!-- ECR Folder Code -->
        <ResourceMatch MatchId="urn:hl7-org:v3:function:CV-equal">
          <AttributeValue DataType="urn:hl7-org:v3#CV">
            <hl7:CodedValue code="ECR"
              codeSystem="IHE-D-Cookbook-FolderClassCode" />
          </AttributeValue>
          <ResourceAttributeDesignator
            AttributeId="urn:ihe:iti:xds-b:2007:folder:code"
            DataType="urn:hl7-org:v3#CV" />
        </ResourceMatch>
        <!-- Purpose Folder Code -->
        <ResourceMatch MatchId="urn:hl7-org:v3:function:CV-equal">
          <AttributeValue DataType="urn:hl7-org:v3#CV">
            <hl7:CodedValue code="K70.0" codeSystem="1.2.276.0.76.5.311" />
          </AttributeValue>
          <ResourceAttributeDesignator
            AttributeId="urn:ihe:iti:xds-b:2007:folder:code"
            DataType="urn:hl7-org:v3#CV" />
        </ResourceMatch>
        <!-- Patient -->
        <ResourceMatch MatchId="urn:hl7-org:v3:function:II-equal">
          <AttributeValue DataType="urn:hl7-org:v3#II">
            <hl7:InstanceIdentifier extension="6578946"
              root="1.3.6.1.4.1.21367.2005.3.7" />
          </AttributeValue>
          <ResourceAttributeDesignator
            AttributeId="urn:ihe:iti:xds-b:2007:patient-id"
            DataType="urn:hl7-org:v3#II" />
        </ResourceMatch>
      </Resource>
    </Resources>
  </Target>

  <Policy PolicyId="urn:ecr:2.0:xacml:policyid:1"
    RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
    <Target>
      <Subjects>
        <!-- An HC professional and its role -->
        <Subject>
          <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"
              >urn:oid:1.2.276.0.76.3.1.81.1.76.4</AttributeValue>
            <SubjectAttributeDesignator
              AttributeId="urn:oasis:names:tc:xspa:1.0:subject:organization-id"
              DataType="http://www.w3.org/2001/XMLSchema#anyURI" />
          </SubjectMatch>
          <SubjectMatch
            MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"
              >physician</AttributeValue>
            <SubjectAttributeDesignator
              AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
              DataType="http://www.w3.org/2001/XMLSchema#string" />
          </SubjectMatch>
        </Subject>
      </Subjects>
      <Resources>
        <!-- Document.availabilityStatus -->
        <Resource>
          <ResourceMatch
            MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI"
              >urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</AttributeValue>
            <ResourceAttributeDesignator
              AttributeId="urn:ihe:iti:xds-b:2007:availability-status"
              DataType="http://www.w3.org/2001/XMLSchema#anyURI" />
          </ResourceMatch>
        </Resource>
      </Resources>
      <Environments>
        <Environment>
          <!-- Begin of grace period -->
          <EnvironmentMatch
            MatchId="urn:oasis:names:tc:xacml:1.0:function:dateTime-greater-than-or-equal">
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#dateTime"
              >2014-12-24T22:00:00Z</AttributeValue>
            <EnvironmentAttributeDesignator
              AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-dateTime"
              DataType="http://www.w3.org/2001/XMLSchema#dateTime" />
          </EnvironmentMatch>
        </Environment>
      </Environments>
    </Target>
  </Policy>
</PolicySet>
      </xacml-saml:XACMLPolicyStatement>
 </saml:Assertion>
</wsse:Security>
</soap12:Header>
<soap12:Body/>
</soap12:Envelope>

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

EFA Setup

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EHetw.01}

In IHE XDS wird eine Fallakte durch die Summe aller Ordner mit dem gleichen Zweck (im Sinne einer allgemeinen Zweckgebundenen Akte) abgebildet. Der Zweck wird in der XDSFolder.codeList gespeichert. Als code wird dabei ein 3‐stelliger ICD‐10 Wert verwendet, der Name oder die Nummer eines IV Vertrags oder ein beliebiges anderes Kennzeichen. Als codingScheme wird dabei ein fixer, zu standardisierender Wert angenommen, unabhängig davon ob der code aus dem ICD‐10 Katalog stammt oder einen IV-Vertrag referenziert.

Um als Fallakte zu gelten, muss es für einen Patienten mindestens einen XDSFolder mit einem Zweck geben, d.h. mit einem Eintrag in der codeList dessen codingScheme dem festgelegten Wert entspricht. Zwei XDSFolder mit dem gleichen Zweck gelten als zwei „Ordner“ einer gemeinsamen Fallakte. Ein XDSFolder darf immer nur einen Zweck haben, da ansonsten der zweite Zweck code fälschlicherweise lesbar ist. XDSFolder mit Zweck können beliebige zusätzliche codes verwenden. Zum Beispiel kann durch Hinzufügen der administrativen Fall ID in die codeList ein XDSFolder mit Zweck auch als „Ordner“ genutzt werden.

Referenzen und Querverweise

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

Bindung von Policies an Schnittstellen

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EcssS.01}

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. Die nachfolgende Abbildung stellt dies in der maximalen Komplexitätsstufe dar, in der neben dem Authentisierungsnachweis auch ein Admission Code und ein Autorisierungsnachweis Bestandteil der Nachweis-Kette sind.

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.

Durch diese Flexibilität kann eine EFA-Implementierung alle im IHE White Paper "Access Control" benannten Verfahren zum Austausch von Autorisierungsnachweisen (policy push, policy pull, policy cache) nutzen. Grundsätzlich gelten hierbei jedoch die folgenden Vorgaben:

jeder providerseitige EFA-Dienst muss die Verfahren "policy pull" und "policy push" unterstützen.
ein providerseitiger Dienst kann zusätzlich ein policy Cache Verfahren umsetzen.
ein EFA-Client kann ein "policy push" unterstützen.

Die beschriebene 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

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EcssS.01.01}

Die nachfolgende Grafik stellt das Prinzip der Zugriffskontrolle abstrakt mit den 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)^[1] ü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.^[2] 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.

IHE Cookbook

IHE White Paper on Access Control ^[3]

Referenzen und Querverweise

↑ A. Anderson und H. Lockhart (2005), SAML 2.0 profile of XACML v2.0.
↑ C. L. Joie (2007), SOAP Profile for XACML-SAML.
↑ 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

EFA-2.0-Spezifikation

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die Kürzel unter den einzelnen Überschriften dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".

EFA XDR/XDS Binding

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDXDg.01}

This section specifies the binding of the EFA components to IHE-ITI actors and the binding of the EFA operations to IHE-ITI transactions.

The EFA actors MUST be bound to IHE-ITI actors as follows:

EFA actor	IHE-ITI actors	Operations
EFA Client	Document Source	out-bound: createECR, closeECR, registerConsent, createPartition, provideData
EFA Client	Document Consumer	out-bound: listPartitions, listPartitionContents, retrieveData
EFA Resource Manager	Document Repository	in-bound: createECR, closeECR, registerConsent
	Document Source	out-bound: registerRecordLocation
	Document Recipient	in-bound: registerRecordLocation
	Initiating Gateway with XDS Affinity Domain Option (see IHE-ITI-TF-Vol1#18.2.1)	out-bound: listRecordLocations
	Responding Gateway grouped with Document Consumer (see IHE-ITI-TF-Vol1#18.2.3.2)	in-bound: listRecordLocations
EFA Document Registry	Document Registry	in-bound: listPartitions, listPartitionContent, registerData
	Initiating Gateway with XDS Affinity Domain Option (see IHE-ITI-TF-Vol1#18.2.1)	in-bound: listPartitions, listPartitionContent out-bound: listPartitions, listPartitionContent
	Responding Gateway grouped with Document Consumer (see IHE-ITI-TF-Vol1#18.2.3.2)	in-bound: listPartitions, listPartitionContent out-bound: listPartitions, listPartitionContent
EFA Document Repository	Document Repository	in-bound: createPartition, provideData, retrieveData out-bound: registerData
	Initiating Gateway with XDS Affinity Domain Option (see IHE-ITI-TF-Vol1#18.2.1)	in-bound: retrieveData out-bound: retrieveData
	Responding Gateway grouped with Document Consumer (see IHE-ITI-TF-Vol1#18.2.3.2)	in-bound: listPartitions, listPartitionContent out-bound: listPartitions, listPartitionContent

There are no contraints on the grouping or composition of EFA actors and IHE-ITI actors.

The EFA operations MUST be bound to IHE-ITI transactions as follows:

EFA Service Functional Model	IHE-ITI Profile	Binding
createECR	Provide and Register Document Set ITI-41	createECR
createPartition	Provide and Register Document Set ITI-41	createPartition
closeECR	Provide and Register Document Set ITI-41	closeECR
listPartitions	Registry Stored Query ITI-18	listPartitions
registerConsent	Provide and Register Document Set ITI-41	registerConsent
listRecordLocations	Cross Gateway Query ITI-38	listRecordLocations
registerRecordLocation	Provide and Register Document Set-b ITI-41	registerRecordLocation
registerData	Register Document Set ITI-42	registerData
listPartitionContent	Registry Stored Query ITI-18	listPartitionContent
provideData	Provide and Register Document Set ITI-41	provideData
retrieveData	Retrieve Document Set ITI-43	retrieveData

Constraints and Triggers

All bindings to the ITI-41 transaction MUST satisfy a set of common constraints and a distinct set of constraints which triggers a certain binding.

The common constraints are:

The SubmissionSet MUST NOT have EFA semantics.
The HasMember(4)-Associations (SubmissionSet to XDSDocumentEntry) MUST have the SubmissionSetStatus-attribute set to "Original".
The HasMember-Associations MUST reference exactly one XDSFolder.
The XDSFolder MUST satisfy the EFA XDS Folder Metadata Binding.
All XDSDocument-Elements MUST be associated with the XDSFolder.
All XDSDocument-Elements MUST satisfy the EFA XDS Document Metadata Binding.

The distinct sets of constraints are defined in the table below (R = required, O = optional, - = forbidden).

Constraints	Triggers for bindings
Constraints	createECR	closeECR	registerConsent	createPartition	provideData
One XDSDocument is a consentInfo which gives a new consent or does not revoke all active consents	R	-	R	-	-
One XDSDocument is a consentInfo, which revokes all active consents	-	R	-	-	-
An XDSFolder is provided (uniqueID)	R	O	O	R	-
An XDSFolder is referenced (uniqueID)	-	O	O	-	R

Hybrid EFA/non-EFA systems should verify that a request is an EFA request prior to processing it with EFA semantics. Non-EFA requests MUST be rejected with an error message if processed with EFA semantics.

IHE XDS Options

The table below shows which IHE XDS options apply to EFA.

XDS Option	Use for EFA	Remarks
Document Replacement	SHOULD NOT be used	EFA clients may replace documents within any dedicated peer. In order to minimize complexity of peer-to-peer deployments, this option may only be used for replacing own documents. It must not be used for replacing documents that have been provided to EFA by another user.
Document Addendum	MUST NOT be used	This option does not work for EFA peer-to-peer deployments and therefore must not be used.
Document Transformation	MUST NOT be used	This option does not work for EFA peer-to-peer deployments and therefore must not be used.
Folder Management	SHALL be implemented	EFA access control builds upon folders. Therefore the implementation of this option is indispensible for EFA compliant systems.
Basic Patient Privacy Enforcement	MUST NOT be used	EFA requires full and written consent to be given by the patient. BPPC-style consents must not be used for EFA. Respective requests (e.g. providing or requesting a BPPC document) shall be ignored by all EFA actors.
Asynchronous Web Services Exchange	MAY be used	EFAv2.0 does not constrain the use of this option.
Reference-ID	SHOULD be implemented	EFA implementations may use the referenceIDList for linking related documents. In this case the FindDocumentsByReferenceId Query may be used for discovering related documents to a given document.
On-Demand Documents	MAY be used	EFAv2.0 does not constrain the use of this option.
Persistence of Retrieved Documents	MAY be used	EFAv2.0 does not constrain the use of this option.
Limited Metadata	Not applicable because EFA builds upon IHE XDS for which limited metadata is not permitted.

Referenzen und Querverweise

EFA-2.0-Spezifikation

cdaefa:EFA XDR SetupCaseRecord cdaefa:EFA XDS ListRecords cdaefa:EFA XDS ListRecordContent cdaefa:EFA XDS ListFolderContent cdaefa:EFA XDS RetrieveDocument cdaefa:EFA XDR ProvideDocument

[saml-1] 1,0 ^1,1 S. Cantor et al. (2005), Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.

[saml-bindings-2] S. Cantor et al. (2005), Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0.

[saml-profiles-3] J. Hughes et al. (2005), Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0.

[4] T. Moses (2005), eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS.

[ws-security-5] A. Nadalin et al. (2006), Web Service Security: SOAP Message Security 1.1. OASIS.

[ws-trust-6] A. Nadalin et al. (2007), WS-Trust 1.3. OASIS.

[7] A. Anderson und H. Lockhart (2005), SAML 2.0 profile of XACML v2.0.

[8] C. L. Joie (2007), SOAP Profile for XACML-SAML.

[ihe-acwp-9] 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

[1]

[2]

[3]

[4]

[5]

[6]

[1]

[2]

[3]

@@ Zeile 9: / Zeile 9: @@
 |Namespace = cdaefa
 |Type      = Implementierungsleitfaden
-|Version   = 01
+|Version   = 0.9
-|Date      = 2013
+|Submitted = February 2013
-|Copyright = 2010-2013
+|Author    = Jörg Caumanns, Raik Kuhlisch
+|Date      = March 2013
+|Copyright = 2012-2013
 |Status    = Draft
-|Period    = Abstimmung
+|Period    = xxx
 |OID       = n.n.
 |Realm     = Deutschland

eFA Spezifikation v2.0

Version vom 20. März 2013, 08:05 Uhr

Inhaltsverzeichnis

Einleitung

Von EFA 1.2 zu EFA 2.0

EFA 2.0 Spezifikation

Weiterführende Themen

Methodische Grundlagen

EFA Konformitätsnachweis

Change Requests

Offene Change Requests

In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen

In die Revision 1 (Januar 2015) aufgenommene Änderungen

Abgewiesene Change Requests

Offene Punkte und ToDos

ToDos aus der Kommentierung (Fraunhofer)

Diskussionsbedarfe - operativ (7er-Gruppe)

Diskussionbedarfe - strategisch (Lenkungsgruppe)

Abschnitte, die ggf. in das Cookbook verschoben werden können

Externe Abhängigkeiten

Conceptual Perspective

Die EFA als zweckgebundene Akte

Der "medizinische Fall"

Auswirkungen der Zweckbindung auf die Nutzung von Fallakten

Die EFA als Gesundheitsdatendienst

Gesundheitsdatendienste (GDD)

GDD Referenzmodell

Affinity Domain vs. Versorgungsdomänen

Krankenhäuser als EFA Provider

Akteure der EFA

Patient (Versicherter)

Fallaktenmanager

EFA-Teilnehmer

EFA Provider

Datenerhebende und datenverantwortliche Stellen

Prinzipien für Datenschutz und Datensicherheit

EFA Sicherheitsstrategie

Kernkonzepte

Synchronität von Behandlungsteam und Berechtigungen

Übertragbarer Sicherheitskontext

Deklarative Sicherheit

Policy Enforcement dicht an den Ressourcen

EFA als Instanz des GDD Referenzmodells

Kontext

EFA-Anwendung und EFA-Peers

Ressourcen der EFA

Hierarchisches Informationsmodell der EFA

Klasse Patient

Klasse Fallakte (Medizinischer Fall)

Verteilung von Fallakten über mehrere EFA-Provider

Klasse Partition

Klasse Datenobjekt

Klasse Einwilligungserklärung

Klasse Berechtigungstoken

Klasse EFA-Teilnehmer

Klasse EFA-Nutzer

Klasse EFA-Provider

Interaktionsmuster der EFA

Arbeiten mit Fallakten

Verwaltung von Fallakten

Interaktionsmuster zum Anlegen einer EFA

Anwendungsszenario: Anlegen einer Fallakte

Varianten des Anwendungsszenarios

Abbildung der Szenarien und Varianten auf Interaktionsmuster

Definition der Interaktionsmuster

Interaktionsmuster: Fallakte anlegen

Peer-to-Peer Semantik

Logical Perspective

Identifizierung und Authentifizierung von EFA-Teilnehmern

Anforderungen

Autorisierung von EFA-Teilnehmern

Anforderungen

Vertraulichkeit

Anforderungen

EFA Secure Channels

Authentizität und Integrität von EFA Daten

Anforderungen

Digital Signature

Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail

Anforderungen