EFA Spezifikation v2.0
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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".
Inhaltsverzeichnis
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. Eine Zusammenstellung aller Seiten der Spezifikation zu einem Dokument finden Sie unter den folgenden Links:
- Aktuelle Spezifikation auf einer Wiki-Seite
- Datei:EFAv2.0-freeze-131118.pdf (PDF, Querformat, aus der generierten Single-Document-Sicht erzeugt)
EFA v2.0 | Enterprise Dimension "Why" Policy |
Information Dimension "What" Content |
Computational Dimension "How" Behavior |
Conceptual Perspective |
|
||
Logical Perspective | |||
Implementable Perspective |
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
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. Bitte senden Sie diese an joerg.caumanns@fokus.fraunhofer.de. Sofern sich hieraus Änderungsanforderungen an die Spezifikation ergeben, werden diese auf dieser Seite aufgelistet und können auf den Diskussionsseiten der betroffenen Spezifikationskapitel diskutiert bzw. kommentiert werden. Fraunhofer FOKUS, EFA-Verein und bvitg werden die kommentierten Änderungsanforderungen in regelmäßigen Abständen prüfen und anschließend annehmen oder ablehnen. Annahme bzw. Ablehnung werden auf den Diskussionsseiten der betroffenen Kapitel dokumentiert.
Offene Change Requests
Geschlossene Change Requests
- 27.04.14: Kodierung von Rollen (HCP Identity Assertion)
- 29.03.14: Zulässigkeit weiterer Verwendungszwecke (logisch)
- 29.03.14: Grundlage einer consentInfo
- 29.03.14: Vorzeitiges Schließen einer Fallakte
- 11.12.13: Einbau eines technischen "Verfallsdatums" für FallAkten
- 11.12.13: Unterscheidung von "Muss"- und "Kann"-Informationen
- 06.01.14: Konkretere Empfehlungen zur Archivierung von Fallakten
- 06.01.14: Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte
- 06.01.14: Konkreter beschreiben, wie ein Dokument invalidiert wird
- 06.01.14: Zustandsübergang "verfallen" -> "archiviert" beschreiben
- 06.01.14: Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen
- 07.01.14: Ausformulieren des Informationsmodells einer Einwilligung
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: