EFA Spezifikation v2.0

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 .

Anmerkung: Die Kürzel vor 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".

---

{Epif.01} Einleitung

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

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

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

Epif.02: Von EFA 1.2 zu EFA 2.0

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

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

Im März 2012 haben daher der EFA-Verein als Träger der EFA-Spezifikation und der bvitg als Vertreter der ambulanten und stationären Sektor tätigen Hersteller beschlossen, gemeinsam eine Version 2.0 der EFA-Spezifikation zu erarbeiten. Diese Version soll

• auf den bewährten und in verschiedenen Gesundheitsnetzen erfolgreich erprobten Kernprinzipien und -konzepten der EFA v1.2 aufbauen
• in Produkten der Industrie verfügbare Schnittstellenstandards aufgreifen und
• durch Verzahnung mit dem "IHE Cookbook" auf Basis generischer XDS-konformer Lösungsbausteine elektronischer Akten implementierbar sein.

Epif.03: EFA 2.0 Spezifikation

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

EFA v2.0	Enterprise Dimension "Why" Policy	Information Dimension "What" Content	Computational Dimension "How" Behavior
Conceptual Perspective	Die EFA als zweckgebundene Akte Die EFA als Gesundheitsdatendienst EFA Provider Akteure und Rollen Prinzipien für Datenschutz und Datensicherheit	Kontext, Akte, Ressource EFA Geschäftsobjekte Lebenszyklus einer Fallakte Patienteneinwilligung zur EFA	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 Anpassen des Teilnehmerkreises
Logical Perspective	EFA Sicherheitsanforderungen Sicherheitszonen	EFA Geschäftsobjekte Informationsmodelle EFA Sicherheitsobjekte Informationsmodelle EFA Einwilligungsdokument	EFA Kommunikationsmuster EFA Anwendungsdienste (logische Spezifikation) EFA Ressource Manager SFM EFA Document Registry SFM EFA Document Repository SFM 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 IHE Setup and Flow of Control EFA XDS Bindings EFA XDS Binding: Transaction Overview EFA XDS Binding: ResourceManager EFA XDS Binding: DocumentRegistry EFA XDS Binding: DocumentRepository EFA Access Control System

Epif.04: Offene Punkte und ToDos

Fehlende Seiten

Teile der normativen Spezifikation

• Interaktionsmuster für das Löschen von Dokumenten
• Kompletter Strang (Interaktion, Kommunikation, SFM, Binding) für das Ändern der Berechtigungen

Nicht-Normative Zusatzinfos

• Darstellung des Zusammenhangs Interaktionsmuster-Kommunikationsmuster-SFM-Binding
• Abbildung der Interaktionsmuster auf Kommunikationsmuster

Zu überarbeitende Seiten

Überarbeitung bis zum Beginn der Kommentierung am 20.04.13

• Prinzipien für Datenschutz und Datensicherheit
  • Text fokussieren und für die Online-Darstellung prägnanter formulieren
  • Pseudonymisierung nur noch als optionale Erweiterung
  • Grafik zum Assertion Chaining muss ausgetauscht werden

Niedrige Priorität

• Akteure und Rollen
  • Akteursdiagramm ergänzen (ggf. aus EFA 1.2 Fachkonzept)
  • Texte sprachlich überarbeiten und inhaltlich erweitern

OIDs und Codesysteme

• Aktuell existiert keine OID für die Nutzung der Telematik-ID als Identifizierungsmechansimus für Organisationen und Leistungserbringer. Eine solche OID wird in folgenden Spezifikationsteilen benötigt:
  • Element AuthorInstitution im XDS Binding der Dokumentenmetadaten
  • Element AuthorPerson im XDS Binding der Dokumentenmetadaten
  • Subject-Identifizierung im EFA SAML Profil

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