EFA Spezifikation v2.0

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
K (Aufbau der Spezifikation)
K
 
(193 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
<!--
 
  
    Spezifikation "EFA v2.0"
+
[[Datei:Information_icon.svg|40px|left]]Gemeinsam mit dem bvitg und IHE Deutschland hat der EFA-Verein einen [http://wiki.hl7.de/index.php?title=Datei:EPPC-G_Draft_for_Comment_v04.pdf 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.
  
 +
 +
[[Datei:Attention_icon.svg|40px|left]] 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 "[[cdaefa:EFA Projectathon 2017|EFA Projectathon 2017]]".
 +
 +
 +
{{DocumentPart}}
 +
 +
<!-- [[Datei:Todo.svg|left]] Die EFA2.0 Spezifikation wurde im Frühjahr um Funktionen zur Peer-to-Peer-Vernetzung von EFA-Providern erweitert. Hierzu findet vom '''23.6.14''' bis '''18.8.14''' eine '''öffentliche Kommentierung''' der Spezifikation statt. Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0 - P2P|Kommentierung EFAv2.0 - P2P]]".
 +
 +
Allgemeine Verbesserungsvorschläge und Change Requests ohne Bezug zu den Peer-to-Peer-Erweiterungen werden parallel zur Kommentierung nach dem bewährten Verfahren weiter bearbeitet. Hinweise hierzu finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".
 +
----
 
-->
 
-->
{{Infobox Dokument
 
|Title    = Spezifikation EFA 2.0
 
|Short    = Spezifikation EFA 2.0
 
|Namespace = cdaefa
 
|Type      = Implementierungsleitfaden
 
|Version  = 0.9
 
|Submitted = February 2013
 
|Author    = Jörg Caumanns, Raik Kuhlisch
 
|Date      = March 2013
 
|Copyright = 2012-2013
 
|Status    = Draft
 
|Period    = xxx
 
|OID      = n.n.
 
|Realm    = Deutschland
 
}}
 
  
 +
= Einleitung =
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.01}</tt>
  
== Einleitung ==
+
Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - einer Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.
  
Die Elektronische Fallakte (EFA) ist eine 2006 gestartete Initiative des stationären Sektors (d.h. Krankenhäuser und Kliniken). Seit 2009 wird sie vom Verein "Elektronische FallAkte e.V." - eine Interessengemeinschaft aus Krankenhäusern, Krankenhausketten, Verbänden der Leistungserbringer im Gesundheitswesen sowie regionalen Gesundheitsnetzen - getragen.
+
Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf 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.
  
Elektronische Fallakten ermöglichen eine strukturierte und integrierte Sicht auf einen Patienten zugeordnete, medizinische Daten. Ein Fall beginnt mit einer Erstdiagnose und integriert alle weiteren notwendigen Abrechnungs- und Behandlungsdaten. Ein Arzt betreut die Fallakte zusammen mit weiteren behandelnden Ärzten, die für die Inhalte und deren Vollständigkeit verantwortlich sind.
+
Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt 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.
  
Die dezentrale Handhabung und Pflege der Fallakten basiert auf der Metapher eines Versorgungsnetzes als Interessengemeinschaft autonomer Akteure mit bestimmten Aufgaben. Medizinische Daten und administrative Informationen (z.B. Benutzerkonten) werden bevorzugt an festen Orten gespeichert. Daher kann die Fallakte sehr einfach in bestehende Netze integriert werden und erleichert somit die Zusammenarbeit auf regionaler Ebene.  
+
== Von EFA 1.2 zu EFA 2.0 ==
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.02}</tt>
  
== EFA Spezifikation v2.0 ==
+
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der [http://www.fallakte.de/spezifikationen 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.
Nach einer nur im Rahmen eines Proof-of-Concept implementierten Version 1.0 der EFA-Spezifikation wurde im Februar 2008 mit der EFA Version 1.2 das erste öffentliche Major-Release der EFA-Spezifikation von den Trägern der EFA-Initiative freigegeben. Bereits Ende 2008 konnten drei namhafte Hersteller (Siemens, ISPro, iSoft) auf dem ersten EFA-Connectathon Produkte präsentieren, die die interoperablen Schnittstellen der EFA implementierten und so miteinander in einem Peer-to-Peer Netzwerk zusammengeschaltet werden konnten. In den folgenden Jahren wurden in verschiedenen Bundesländern EFA-Pilotprojekte gestartet und 2011 konnte am Städtischen Klinikum München das erste regionale EFA-Netzwerk in den Regelbetrieb überführt werden.
 
  
Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] den State-of-the-Art auch mit geprägt hat) haben sich in dieser Zeit im Bereich der Fachschnittstellen von elektronischen Aktensystemen die meisten Hersteller mit ihren Produkten in Richtung des IHE-Profils XDS bewegt, das von der EFA Version 1.2 lediglich logisch aber nicht syntaktisch berücksichtigt wurde - wobei auch die Synchronizität der EFA-Abläufe zu IHE XDS auf die Ebene der Dokumentenverwaltung beschränkt ist und die übergeordneten EFA-Konzepte (Fallakte, Ordner) nicht abdeckt.
+
Während die EFA-Sicherheitsarchitektur auch fünf Jahre nach ihrer Veröffentlichung noch dem State-of-the-Art entspricht (und durch Übernahme in Projekte wie z.B. [http://www.epsos.eu epSOS] und [http://www.p23r.de 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 ambulanten und stationören Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifiation zu erarbeiten. Diese Version soll
+
Im März 2012 haben daher der [http://www.fallakte.de EFA-Verein] als Träger der EFA-Spezifikation und der [http://www.bvitg.de bvitg] als Vertreter der 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
+
* 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  
+
* 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 Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.
+
* durch Verzahnung mit dem [[IHE_DE_Cookbook|IHE-D Cookbook]] auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.
  
== Aufbau der Spezifikation ==
+
== EFA 2.0 Spezifikation ==
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.03}</tt>
  
Die EFA-Spezifikation orientiert sich an der Spezifikationsmatrix des ''[http://wiki.hl7.org/index.php?title=SAIF_ECCF Enterprise Consistency and Conformity Framework]'' (ECCF) als Teil des HL7 ''Service-Aware Interoperability Framework'' (SAIF). Die folgende Tabelle gibt sie am Beispiel der EFA wieder.
+
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:
 +
* [[cdaefa:EFAv2_Single_Document|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML)]],
 +
* [[Media:EFAv2.0-freeze-131118.pdf|Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF)]].
  
<table border="1" cellspacing="0" cellpadding="0" width="100%">
+
<table border="1" cellspacing="0" cellpadding="5em" width="100%">
 
<tr bgcolor="lightgray" align="center">
 
<tr bgcolor="lightgray" align="center">
<td width="10%" valign="top"></td>
+
<td width="10%" valign="top">EFA v2.0</td>
 
<td width="30%" valign="top">'''Enterprise Dimension'''<br><span style="color:red">'''''"Why"'''''</span><br>'''''Policy'''''</td>
 
<td width="30%" valign="top">'''Enterprise Dimension'''<br><span style="color:red">'''''"Why"'''''</span><br>'''''Policy'''''</td>
 
<td width="30%" valign="top">'''Information Dimension'''<br><span style="color:red">'''''"What"'''''</span><br>'''''Content'''''</td>
 
<td width="30%" valign="top">'''Information Dimension'''<br><span style="color:red">'''''"What"'''''</span><br>'''''Content'''''</td>
Zeile 54: Zeile 53:
 
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
 
<td width="10%" valign="top" align="left">'''Conceptual Perspective'''</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
* Prinzipien und Strategien für EFA
+
[[cdaefa:Die EFA als zweckgebundene Akte|Die EFA als zweckgebundene Akte]]
** Die EFA als zweckgebundene Akte
+
 
** Akteure und Rollen der EFA
+
[[cdaefa:EFA Provider|Versorgungsdomänen]]
** Prinzipien für Datenschutz und Datensicherheit
+
 
** Vernetzung von Netzen
+
[[cdaefa:Die EFA als Gesundheitsdatendienst|Die EFA als Gesundheitsdatendienst]]
** Integration in bestehende IT-Landschaften
+
 
 +
[[cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern|Peer-to-Peer-Vernetzung von EFA-Providern]]
 +
 
 +
[[cdaefa:Akteure und Rollen der EFA|Akteure und Rollen]]
 +
 
 +
[[cdaefa:Prinzipien für Datenschutz und Datensicherheit|Prinzipien für Datenschutz und Datensicherheit]]
 
</td>
 
</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
* EFA-Informationsobjekte
+
[[cdaefa:Kontext, Akte, Ressource|Kontext, Akte, Ressource]]
** Fallakten
+
 
** Ordner
+
[[cdaefa:Patienteneinwilligung zur EFA|Patienteneinwilligung zur EFA]]
** (med.) Dokument
+
 
* Patienteneinwilligung
+
[[cdaefa:EFA Geschäftsobjekte|EFA Geschäftsobjekte]]
 +
 
 +
*[[cdaefa:EFA Business Lebenszyklus|Lebenszyklus einer Fallakte]]
 
</td>
 
</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
* Geschäftsfunktionalitäten
+
[[cdaefa:Interaktionsmuster der EFA|Interaktionsmuster der EFA]]
** Interaktions- und Kommunikationsmuster
+
*[[cdaefa:CIM Anlegen einer Fallakte|Anlegen einer Fallakte]]
** EFA-Initialisierung
+
*[[cdaefa:CIM Anlegen und Registrieren einer Partition|Anlegen und Registrieren einer Partition]]
* EFA-Design-Prinzipien
+
*[[cdaefa:CIM:Einstellen von Datenobjekten|Einstellen von Datenobjekten]]
** Nutzung von Standards
+
*[[cdaefa:CIM Auffinden der Fallakten eines Patienten|Auffinden der Fallakten eines Patienten]]
** Autonomie von EFA-Peers
+
*[[cdaefa:CIM Browsing über eine Akte oder eine Partition|Browsing über eine Akte oder eine Partition]]
** Eckpfeiler EFA-Sicherheit
+
*[[cdaefa:CIM Abruf von Datenobjekten|Abruf von Datenobjekten]]
* Schichtenarchitektur
+
*[[cdaefa:CIM Schließen einer Fallakte|Schließen einer Fallakte]]
** EFA-3-Schichten-Architektur
+
*[[cdaefa:CIM Invalidieren von Datenobjekten|Invalidieren von Datenobjekten]]
** Kompatibilität mit dem [[IHE_DE_Cookbook|IHE Cookbook]] (nicht-normativ)
+
*[[cdaefa:CIM Anpassen des Teilnehmerkreises|Ändern der Einwilligung]]
** Abwärtskompatibilität mit der EFA-Spezifikation v1.2
+
*[[cdaefa:CIM_Autorisierung_eines_weiteren_Teilnehmers|Autorisierung eines weiteren Teilnehmers]]
 +
*[[cdaefa:CIM_Zusammenführen_von_Fallakten|Zusammenführen von Fallakten]]
 
</td>
 
</td>
 
</tr>
 
</tr>
Zeile 86: Zeile 93:
 
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
 
<td width="10%" valign="top" align="left">'''Logical Perspective'''</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
* Anforderungen an Anwendungs- und Sicherheitsarchitektur
+
[[cdaefa:EFA Sicherheitsanforderungen|EFA Sicherheitsanforderungen]]
* Sicherheitszonen
 
 
</td>
 
</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
* Logisches Informationsmodell der EFA
+
[[cdaefa:EFA Business Informationsmodell|Informationsmodelle der EFA Geschäftsobjekte]]
 +
 
 +
[[cdaefa:EFA Security Informationsmodell|Informationsmodelle der EFA Sicherheitsobjekte]]
 +
 
 +
[[cdaefa:EFA Fehlermeldungen und Warnungen|Fehlermeldungen und Warnungen]]
 
</td>
 
</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
* EFA-Dienste
+
[[cdaefa:EFA Dienste|EFA Dienste]]
* EFA-Funktionen
+
 
* Sicherheitsdienste
+
[[cdaefa:EFA Kommunikationsmuster|EFA Kommunikationsmuster]]
 +
 
 +
[[cdaefa:EFA Anwendungsdienste (logische Spezifikation)|EFA Anwendungsdienste (logische Spezifikation)]]
 +
 
 +
[[cdaefa:EFA Sicherheitsdienste (logische Spezifikation)|EFA Sicherheitsdienste (logische Spezifikation)]]
 +
*[[cdaefa:EFA Context Manager SFM|EFA Context Manager SFM]]
 +
*[[cdaefa:EFA Identity Provider SFM|EFA Identity Provider SFM]]
 +
*[[cdaefa:EFA Policy Provider SFM|EFA Policy Provider SFM]]
 +
 
 +
[[cdaefa:Gruppierung von Anwendungs- und Sicherheitsdiensten|Gruppierung von Anwendungs- und Sicherheitsdiensten]]
 
</td>
 
</td>
 
</tr>
 
</tr>
Zeile 102: Zeile 121:
 
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
 
<td width="10%" valign="top" align="left">'''Implementable Perspective'''</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
 +
[[cdaefa:EFA Verwendete Standards|Verwendete Standards]]
 +
 +
[[cdaefa:EFA Used Namespaces|Namespaces]]
 
</td>
 
</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
 +
[[cdaefa:EFA Metadata Bindings|EFA Metadata Bindings]]
 +
*[[cdaefa:EFA XDS Folder Metadata Binding|EFA XDS Folder Metadata Binding]]
 +
*[[cdaefa:EFA XDS Document Metadata Binding|EFA XDS Document Metadata Binding]]
 +
 +
[[cdaefa:EFA Security Objects Bindings|EFA Security Objects Bindings]]
 +
*[[cdaefa:EFA Identity Assertion SAML2 Binding|EFA Identity Assertion SAML2 Binding]]
 +
*[[cdaefa:EFA Policy Assertion SAML2 Binding|EFA Policy Assertion SAML2 Binding]]
 +
 +
[[cdaefa:EFA Patient Consent Binding|EFA Patient Consent Binding]]
 +
 +
[[cdaefa:EFA Audit Trail Binding|EFA Audit Trail Binding]]
 +
 +
[[cdaefa:EFA Error Codes and Warning Codes|EFA Error Codes and Warning Codes]]
 
</td>
 
</td>
 
<td width="30%" valign="top" align="left">
 
<td width="30%" valign="top" align="left">
 +
[[cdaefa:EFA IHE Setup and Flow of Control|EFA IHE Setup and Flow of Control]]
 +
 +
[[cdaefa:EFA XDS/XDR Bindings|EFA XDS Bindings]]
 +
*[[cdaefa:EFA XDS ResourceManager|EFA XDS Binding: ResourceManager]]
 +
*[[cdaefa:EFA XDS DocumentRegistry|EFA XDS Binding: DocumentRegistry]]
 +
*[[cdaefa:EFA XDS DocumentRepository|EFA XDS Binding: DocumentRepository]]
 +
 +
[[cdaefa:EFA Access Control System|EFA Access Control System]]
 +
*[[cdaefa:EFA WS Trust Policy Provider|EFA WS-Trust Binding: PolicyProvider]]
 +
 +
[[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]]
 
</td>
 
</td>
 
</tr>
 
</tr>
 
</table>
 
</table>
  
Die Spalten der Tabelle stellen bestimmte Eigenschaften des zu analysierenden und zu spezifizierenden Systems dar:
+
== Weiterführende Themen ==
* Die Enterprise Dimension definiert den geschäftlichen Zusammenhang und befasst sich primär mit den EFA-Informationsobjekten und EFA-Geschäftsprozessen.
+
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.
* Die Information Dimension befasst sich mit dem Informationsmodell der Fallakte sowie damit zusammenhängenden Restiktionen bei der Nutzung und Interpretation dieser Information.
+
 
* Die Computational Dimension fokussiert auf die fachlichen Funktionen der EFA mit den zugehörigen Akteuren, welche durch Transaktionen mit einem bestimmtem Verhalten und Interaktionen charakterisiert sind.
+
=== Methodische Grundlagen ===
 +
 
 +
* [[HL7_Enterprise_Conformance_and_Compliance_Frameworks|HL7 SAIF ECCF]]: Kurze Einführung in das HL7 SAIF ''Enterprise Conformance and Compliance Framework'', das dem Aufbau dieser Spezifikation zugrunde liegt
 +
* [[cdaefa:IHE_Access_Control_Domains | 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.
 +
* [[cdaefa:Gegenstand der Konformitätsprüfung|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.
 +
* [[cdaefa:Durchführung der Konformitätsprüfung|Durchführung der Konformitätsprüfung]]
 +
 
 +
Hersteller können alle zur Durchführung des Verfahrens erforderlichen Unterlagen per Mail beim Fraunhofer FOKUS ([mailto:joerg.caumanns@fokus.fraunhofer.de 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 [[EFA Change- und Releasemanagement|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 Change Requests ===
 +
* 31.10.16: [[cdaefa:CP-046-00|CP-046-00: IHE ITI TF Revision 13: Änderungen am SOAP Header]]
 +
* 30.10.16: [[cdaefa:CP-045-00|CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten]]
 +
* 30.10.16: [[cdaefa:CP-044-00|CP-044-00: Integration administrativer Fallnummern]]
 +
* 30.10.16: [[cdaefa:CP-043-00|CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten]]
 +
* 30.10.16: [[cdaefa:CP-042-00|CP-042-00: Klarstellungen zu partiellen Fehlern bei ''ProvideAndRegisterDocument'']]
 +
* 07.07.16: [[cdaefa:CP-041-00|CP-041-00: Zu strikte Vorgaben beim Aktualisieren einer Einwilligung]]
 +
* 07.07.16: [[cdaefa:CP-040-00|CP-040-00: Fehlermeldungen bei Nutzung verbotener Attribute in den XDS Metadaten]]
 +
* 07.07.16: [[cdaefa:CP-039-00|CP-039-00: Umgang mit XDS-''GetAll'' und -''FindDocuments Query Flavor'' klären]]
 +
* 07.07.16: [[cdaefa:CP-038-00|CP-038-00: Überarbeitetes Konzept zur Zweck-Kodierung in die Spezifikation aufnehmen]]
 +
* 07.07.16: [[cdaefa:CP-037-00|CP-037-00: Probleme mit dem Audit Trail bei ''provideAndRegister'']]
 +
* 07.07.16: [[cdaefa:CP-036-00|CP-036-00: Unklar, wieso ''retrieveDocuments'' nur Dokumente in einem Ordner referenzieren darf]]
 +
* 07.07.16: [[cdaefa:CP-035-00|CP-035-00: Nutzung von WS Security ''mustUnderstand'' unklar]]
 +
* 07.07.16: [[cdaefa:CP-034-00|CP-034-00: Fallakten-Manager muss Dokumente im Status ''deprecated'' lesen können]]
 +
* 07.07.16: [[cdaefa:CP-033-00|CP-033-00: EFAv2.0 verletzt die IHE PCC Vorgaben zur ''sourcePatientID'']]
 +
* 07.07.16: [[cdaefa:CP-032-00|CP-032-00: Fehlendes XSPA ''subjectID'' Attribut im EFAv2.0 Policy Binding]]
 +
* 07.07.16: [[cdaefa:CP-031-00|CP-031-00: Vorgabe zur ''nameID'' stellt keine ausreichende Eindeutigkeit von Personen sicher]]
 +
* 07.07.16: [[cdaefa:CP-030-00|CP-030-00: Mehrdeutige Definition im Policy Assertion Binding]]
 +
* 07.07.16: [[cdaefa:CP-029-00|CP-029-00: ''Rule'' Element fehlt im Policy Assertion Beispiel]]
 +
* 07.07.16: [[cdaefa:CP-028-00|CP-028-00: Falsches Beispiel im Binding ''ListPartitions'']]
 +
* 07.07.16: [[cdaefa:CP-027-00|CP-027-00: Nutzung von APPC]]
 +
* 07.07.16: [[cdaefa:CP-026-00|CP-026-00: Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers]]
 +
* 07.07.16: [[cdaefa:CP-025-00|CP-025-00: ''subjectID'' in der EFA Identity Assertion eventuell nicht IHE-konform kodiert]]
 +
* 07.07.16: [[cdaefa:CP-024-00|CP-024-00: EFA-Notation für ''subjectRole'' nicht IHE-konform]]
 +
* 07.07.16: [[cdaefa:CP-023-00|CP-023-00: Beispiel für EFA Identity Assertion fehlerhaft]]
 +
* 07.07.16: [[cdaefa:CP-022-00|CP-022-00: Binding für SFM ''redeemAccessToken'' fehlt]]
 +
* 07.07.16: [[cdaefa:CP-021-00|CP-021-00: Fehlende Stored Query bei ListRecordLocations Binding]]
 +
* 07.04.16: [[cdaefa:CP-020-00|CP-020-00: Systemverhalten bei Berechtigungsfehlern]]
 +
* 07.04.16: [[cdaefa:CP-019-00|CP-019-00: Klassifizierung von Mount-Points]]
 +
* 09.04.15: [[cdaefa:CP-005-00|CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)]]
 +
* 09.04.15: [[cdaefa:CP-007-00|CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten]]
 +
* 09.04.15: [[cdaefa:CP-008-00|CP-008-00: Fehlende Profilierung der Dokumentensignatur]]
 +
* 09.04.15: [[cdaefa:CP-010-00|CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste]]
 +
* 09.04.15: [[cdaefa:CP-011-00|CP-011-00: SecureRetrieve für EFAv2.0]]
 +
 
 +
=== In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen ===
 +
* 07.04.16: [[cdaefa:CP-018-00|CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe]]
 +
* 02.11.15: [[cdaefa:CP-012-00|CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel]]
 +
* 02.11.15: [[cdaefa:CP-013-00|CP-013-00: Groß-/Kleinschreibung bei Query-Parametern]]
 +
* 12.02.16: [[cdaefa:CP-001-00|CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity]]
 +
* 12.02.16: [[cdaefa:CP-003-00|CP-003-00: Zulässigkeit weiterer Zweckcodes]]
 +
* 12.02.16: [[cdaefa:CP-006-00|CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten]]
 +
* 12.02.16: [[cdaefa:CP-014-00|CP-014-00: Fehler in der OID-Nutzung für SMC-B]]
 +
* 14.02.16: [[cdaefa:CP-015-00|CP-015-00: Fehlende Vorgabe für „HP Speciality“]]
 +
* 14.02.16: [[cdaefa:CP-017-00|CP-017-00: EFA Identity Assertion SAML2 Binding]]
 +
* 14.02.16: [[cdaefa:CP-016-00|CP-016-00: Nutzung von XDS-Optionen explizieren]]
 +
* 16.02.16: [[cdaefa:CP-004-00|CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)]]
 +
* 16.02.16: [[cdaefa:CP-002-00|CP-002-00: Unvollständige Spezifikation der Klasse consentInfo]]
 +
 
 +
=== In die Revision 1 (Januar 2015) aufgenommene Änderungen ===
 +
* 01.10.14: [[cdaefa_Diskussion:EFA_Dienste|Deployment-Optionen für das XDS DocumentRegistry]]
 +
* 27.04.14: [[cdaefa_Diskussion:EFA_Identity_Assertion_SAML2_Binding#Change_Requests|Kodierung von Rollen (HCP Identity Assertion)]]
 +
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests |Zulässigkeit weiterer Verwendungszwecke (logisch)]]
 +
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Grundlage einer consentInfo]]
 +
* 29.03.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Change_Requests|Vorzeitiges Schließen einer Fallakte]]
 +
* 11.12.13: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Einbau_eines_technischen_.22Verfallsdatums.22_f.C3.BCr_FallAkten |Einbau eines technischen "Verfallsdatums" für FallAkten]] 
 +
* 11.12.13: [[cdaefa_Diskussion:EFA_Geschäftsobjekte#Unterscheidung_von_.22Muss.22-_und_.22Kann.22-Informationen|Unterscheidung von "Muss"- und "Kann"-Informationen ]]
 +
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Konkretere_Empfehlungen_zur_Archivierung_von_Fallakten|Konkretere Empfehlungen zur Archivierung von Fallakten]]
 +
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Konkretere_Darstellung_der_Kodierung_der_G.C3.BCltigkeitsdauer_einer_Akte|Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte]]
 +
* 06.01.14: [[cdaefa_Diskussion:EFA_Kommunikationsmuster#Konkreter_beschreiben.2C_wie_ein_Dokument_invalidiert_wird|Konkreter beschreiben, wie ein Dokument invalidiert wird]]
 +
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Lebenszyklus#Zustands.C3.BCbergang_.22verfallen.22_-.3E_.22archiviert.22_beschreiben|Zustandsübergang "verfallen" -> "archiviert" beschreiben]]
 +
* 06.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Hinweis_auf_laufende_Arbeiten_zur_Einwilligungserkl.C3.A4rung_einf.C3.BCgen|Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen]]
 +
* 07.01.14: [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Ausformulieren_des_Informationsmodells_einer_Einwilligung|Ausformulieren des Informationsmodells einer Einwilligung]]
 +
 
 +
=== Abgewiesene Change Requests ===
 +
* 09.04.15: [[cdaefa:CP-009-00|CP-009-00: Profilierung von DocumentEntry.confidentialityCode]]
 +
 
 +
== Offene Punkte und ToDos ==
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Epif.04}</tt>
 +
 
 +
=== ToDos aus der Kommentierung (Fraunhofer) ===
 +
 
 +
* [[cdaefa:EFA_Business_Informationsmodell|Informationsmodell]]: Übersichtsgrafik als UML-Klassenmodell
 +
* [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|EFA Anwendungsdienste]]: Fehlercodes konsolidieren und auf einer Seite zusammenfassen
 +
* [[cdaefa:Akteure_und_Rollen_der_EFA|Akteure und Rollen]]: Akteursdiagramm einfügen
 +
* Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding (zusätzliche Seite)
  
Die Zeilen der Tabelle geben verschiedene Abstraktionsgrade wieder und adressieren somit verschiedene Expertengruppen:
+
=== Diskussionsbedarfe - operativ (7er-Gruppe) ===
* Die Conceptual Perspective ist vollstänig rechnerunabhängig und eher problem- als lösungsorientiert. Artefakte dieser Ebene skizzieren die Grundlagen und Kernkonzepte der EFA aus der Fachexpertensicht und definieren als solche das ganzheitliche konzeptionelle Modell der EFA.
 
* Artefakte in der Logical Perspective stellen nachvollziehbare Transformationen von Artefakten der konzeptuellen Ebene in Formate für Architekten/Analysten dar. Diese Perspektive repräsentiert die funktionale/logische Spezifikation der EFA und definiert somit den EFA-Lösungsraum mit seinen Klassen, Diensten und Operationen.
 
* Artefakte in der Implementable Perspective enthalten alle notwendigen, technischen Bindungen (z. B. Datentypen, Wertemengen, Schnittstellen-Spezifikationen etc.) mit denen Entwickler in die Lage versetzt werden, Bausteine ​​der funktionalen/logischen Spezifikation mittels Standards-basierender technischer Komponenten umzusetzen zu können.
 
  
== EFA-Conceptual-Perspective-Spezifikation ==
+
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#issueAccessToken|issueAccessToken]]
<!-- Deutsch -->
+
* Binding für die Operation [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#redeemAccessToken|redeemAccessToken]]
 +
*Informationsmodell für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
 +
* Binding für die Klasse [[cdaefa:EFA_Security_Informationsmodell#accessToken|accessToken]]
  
 +
=== Diskussionbedarfe - strategisch (Lenkungsgruppe) ===
  
== EFA-Application-Architecure-Spezifikation ==
+
=== Abschnitte, die ggf. in das Cookbook verschoben werden können ===
<!-- Deutsch -->
 
  
 +
* [[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"
  
== EFA Security Architecure Specification ==
+
=== Externe Abhängigkeiten ===
<!-- Englisch -->
 
  
 +
* Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
 +
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Institution|Element ''AuthorInstitution'' im XDS Binding der Dokumentenmetadaten]]
 +
** [[cdaefa:EFA_XDS_Document_Metadata_Binding#Author_Person|Element ''AuthorPerson'' im XDS Binding der Dokumentenmetadaten]]
 +
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_Profile|Subject-Identifizierung im EFA SAML Profil]]
  
== EFA Bindings ==
+
* 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:
<!-- Englisch -->
+
** [[cdaefa:EFA_Identity_Assertion_SAML2_Binding#German_National_Profile_and_Extensions|Subject-Attribut im EFA SAML Profil]]

Aktuelle Version vom 1. Februar 2017, 20:11 Uhr

Information icon.svg

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.


Attention icon.svg

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 CDA für die elektronische Fallakte.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .


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

Interaktionsmuster der EFA

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)

Gruppierung von Anwendungs- und Sicherheitsdiensten

Implementable Perspective

Verwendete Standards

Namespaces

EFA Metadata Bindings

EFA Security Objects Bindings

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 Access Control System

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.

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.

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

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)

Diskussionbedarfe - strategisch (Lenkungsgruppe)

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

Externe Abhängigkeiten

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