eFA Spezifikation v2.0
Dieses Dokument gibt wieder:
Implementierungsleitfaden eFA Spezifikation v2.0 (01). Die Teilmaterialien gehören der Kategorie cdaefa an. |
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.
|
Inhaltsverzeichnis
- 1 Einleitung
- 2 Conceptual Perspective
- 2.1 Die EFA als zweckgebundene Akte
- 2.2 Die EFA als Gesundheitsdatendienst
- 2.3 Affinity Domain vs. Versorgungsdomänen
- 2.4 Akteure der EFA
- 2.5 Prinzipien für Datenschutz und Datensicherheit
- 2.6 EFA als Instanz des GDD Referenzmodells
- 2.7 Hierarchisches Informationsmodell der EFA
- 2.8 Interaktionsmuster der EFA
- 3 Logical Perspective
- 3.1 Identifizierung und Authentifizierung von EFA-Teilnehmern
- 3.2 Autorisierung von EFA-Teilnehmern
- 3.3 Vertraulichkeit
- 3.4 Authentizität und Integrität von EFA Daten
- 3.5 Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail
- 3.6 Verfügbarkeit von EFA-Teilnehmern und EFA-Daten
- 3.7 EFA Business Informationsmodell
- 3.7.1 EFA Informationsmodell
- 3.7.2 PIM Data Structures
- 3.7.2.1 patientID
- 3.7.2.2 purpose
- 3.7.2.3 ecrStatus
- 3.7.2.4 consentInfo
- 3.7.2.5 consentDoc
- 3.7.2.6 consentLegalAuthenticator
- 3.7.2.7 caseRecordManager
- 3.7.2.8 consentCustodian
- 3.7.2.9 partitionID
- 3.7.2.10 partitionList
- 3.7.2.11 ecrRef
- 3.7.2.12 partitionInfo
- 3.7.2.13 docMetadata
- 3.7.2.14 docRelationship
- 3.7.2.15 documentID
- 3.7.2.16 communityID
- 3.7.2.17 MountPoint
- 3.8 Lebenszyklus einer Fallakte
- 3.9 Kommunikationsmuster
- 3.9.1 Aufbau des Sicherheitskontextes
- 3.9.2 Anlegen einer Fallakte
- 3.9.3 Anlegen einer Partition zu einer bestehenden Fallakte
- 3.9.4 Schließen einer Fallakte
- 3.9.5 Auflisten von Partitionen
- 3.9.6 Einstellen von Dokumenten
- 3.9.7 Auflisten von Dokumenten
- 3.9.8 Abrufen von Dokumenten
- 3.9.9 Invalidieren eines Dokuments
- 3.9.10 Registrierung einer neuen Einwilligung
- 3.9.11 Anfordern eines Berechtigungstoken
- 3.9.12 Einlösen eines Berechtigungstoken
- 3.9.13 Konsolidieren von Fallakten
- 3.9.14 Speichern und Registrieren von Dokumenten
- 3.9.15 Verteilen einer Einwilligung im EFA-Verbund
- 3.10 EFA Anwendungsarchitektur: Service Functional Model
- 3.11 Sicherheitstoken und Sicherheitstokendienste
- 3.12 EFA Sicherheits(token)dienste
- 3.13 Gruppierung von Anwendungs- und Sicherheitsdiensten
- 4 Implementable Perspective
- 4.1 Verwendete Standards: Sicherheit
- 4.2 Mapping of Core Information Model Classes
- 4.3 Mapping of PIM Classes
- 4.4 Folder Metadata
- 4.5 Document Metadata
- 4.6 Security Object Bindings
- 4.6.1 SAML 2.0 Profile for ECR Identity Assertions
- 4.6.2 SAML 2.0 Profile for ECR Policy Assertions
- 4.6.2.1 PolicySet Profile
- 4.6.2.2 Policy Assignment
- 4.6.2.2.1 Policy Attachment for a health professional
- 4.6.2.2.2 Policy Attachment for health record managers
- 4.6.2.2.3 SubjectMatch for EFA Identity Assertion NameID
- 4.6.2.2.4 SubjectMatch for health professional ID
- 4.6.2.2.5 SubjectMatch for structural role
- 4.6.2.2.6 SubjectMatch for health professional organization ID
- 4.6.2.2.7 ResourceMatch for EFA Folder classification
- 4.6.2.2.8 ResourceMatch for purpose classification
- 4.6.2.2.9 ResourceMatch for patientId
- 4.6.2.3 Assertion Signature
- 4.6.2.4 Example Assertion
- 4.7 EFA Setup
- 4.8 Bindung von Policies an Schnittstellen
- 4.9 EFA XDR/XDS Binding
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:
- Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (HTML),
- Kompilierte Spezifikation der Elektronischen Fallakte Version 2.0 (PDF).
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 |
|
|
Logical Perspective |
Informationsmodelle der EFA Geschäftsobjekte |
EFA Anwendungsdienste (logische Spezifikation) |
|
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
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
- 31.10.16: CP-046-00: IHE ITI TF Revision 13: Änderungen am SOAP Header
- 30.10.16: CP-045-00: Differenzierung von Fehlermeldungen beim Ersetzen von Dokumenten
- 30.10.16: CP-044-00: Integration administrativer Fallnummern
- 30.10.16: CP-043-00: Mehrsprachige Display-Names für Dokumentenmetadaten
- 30.10.16: CP-042-00: Klarstellungen zu partiellen Fehlern bei ProvideAndRegisterDocument
- 07.07.16: CP-041-00: Zu strikte Vorgaben beim Aktualisieren einer Einwilligung
- 07.07.16: CP-040-00: Fehlermeldungen bei Nutzung verbotener Attribute in den XDS Metadaten
- 07.07.16: CP-039-00: Umgang mit XDS-GetAll und -FindDocuments Query Flavor klären
- 07.07.16: CP-038-00: Überarbeitetes Konzept zur Zweck-Kodierung in die Spezifikation aufnehmen
- 07.07.16: CP-037-00: Probleme mit dem Audit Trail bei provideAndRegister
- 07.07.16: CP-036-00: Unklar, wieso retrieveDocuments nur Dokumente in einem Ordner referenzieren darf
- 07.07.16: CP-035-00: Nutzung von WS Security mustUnderstand unklar
- 07.07.16: CP-034-00: Fallakten-Manager muss Dokumente im Status deprecated lesen können
- 07.07.16: CP-033-00: EFAv2.0 verletzt die IHE PCC Vorgaben zur sourcePatientID
- 07.07.16: CP-032-00: Fehlendes XSPA subjectID Attribut im EFAv2.0 Policy Binding
- 07.07.16: CP-031-00: Vorgabe zur nameID stellt keine ausreichende Eindeutigkeit von Personen sicher
- 07.07.16: CP-030-00: Mehrdeutige Definition im Policy Assertion Binding
- 07.07.16: CP-029-00: Rule Element fehlt im Policy Assertion Beispiel
- 07.07.16: CP-028-00: Falsches Beispiel im Binding ListPartitions
- 07.07.16: CP-027-00: Nutzung von APPC
- 07.07.16: CP-026-00: Im PolicyAssertion Binding fehlt eine Vorgabe für die Kodierung der Rechte des Fallaktenmanagers
- 07.07.16: CP-025-00: subjectID in der EFA Identity Assertion eventuell nicht IHE-konform kodiert
- 07.07.16: CP-024-00: EFA-Notation für subjectRole nicht IHE-konform
- 07.07.16: CP-023-00: Beispiel für EFA Identity Assertion fehlerhaft
- 07.07.16: CP-022-00: Binding für SFM redeemAccessToken fehlt
- 07.07.16: CP-021-00: Fehlende Stored Query bei ListRecordLocations Binding
- 07.04.16: CP-020-00: Systemverhalten bei Berechtigungsfehlern
- 07.04.16: CP-019-00: Klassifizierung von Mount-Points
- 09.04.15: CP-005-00: Falsche Zuordnung der Signatur (Metadaten statt Dokument)
- 09.04.15: CP-007-00: Inkonsistenz in der Darstellung der Dokumenten-Metadaten
- 09.04.15: CP-008-00: Fehlende Profilierung der Dokumentensignatur
- 09.04.15: CP-010-00: Audit Trail Einträge für EFAv2.0-Sicherheitsdienste
- 09.04.15: CP-011-00: SecureRetrieve für EFAv2.0
In die Revision 2 (EFA-Projectathon 2016) aufgenommene Änderungen
- 07.04.16: CP-018-00: Übernahme von Codes der deutschen Value-Set-Gruppe
- 02.11.15: CP-012-00: Fehlerhafte Kodierung von IDs in einem Beispiel
- 02.11.15: CP-013-00: Groß-/Kleinschreibung bei Query-Parametern
- 12.02.16: CP-001-00: Missverständliche Spezifikation der Klasse subjectIdentity
- 12.02.16: CP-003-00: Zulässigkeit weiterer Zweckcodes
- 12.02.16: CP-006-00: Unvollständiges Binding der Dokumenten-Metadaten
- 12.02.16: CP-014-00: Fehler in der OID-Nutzung für SMC-B
- 14.02.16: CP-015-00: Fehlende Vorgabe für „HP Speciality“
- 14.02.16: CP-017-00: EFA Identity Assertion SAML2 Binding
- 14.02.16: CP-016-00: Nutzung von XDS-Optionen explizieren
- 16.02.16: CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)
- 16.02.16: CP-002-00: Unvollständige Spezifikation der Klasse consentInfo
In die Revision 1 (Januar 2015) aufgenommene Änderungen
- 01.10.14: Deployment-Optionen für das XDS DocumentRegistry
- 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
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)
- 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:
Conceptual Perspective
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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.
Referenzen und Querverweise
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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.
|
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.
|
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.
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
---|---|
|
|
|
|
|
|
|
|
|
Verwaltung von Fallakten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Irti.01.02}
Muster | Umsetzung |
---|---|
|
|
|
|
|
|
|
|
|
|
|
Referenzen und Querverweise
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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}
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 |
|
Interaktion | Arzt --> (Patientenidentifikation, Zweck der Akte, [Gültigkeit], [EFA-Teilnehmer], [Einwilligungsformular]) --> EFA-Provider |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
|
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 |
Logical Perspective
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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:
|
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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.
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.
|
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. |
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
- entweder die Variante Neu-Anlage einer Fallakte
- 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
- die EFA-Berechtigungsregel der bestehenden Fallakte den zugreifenden Arzt als Berechtigten auszeichnet. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.
- 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
- legt die Partition an,
- registriert und speichert gegebenenfalls die Dokumente und verknüpft sie mit der Partition und
- 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
- führt für die Dokumente, die das Schließen begründen, das Muster Speichern und Registrieren von Dokumenten aus,
- ändert den Status und die EFA-Berechtigungsregel der Fallakte gemäß des Lebenszyklus und
- gibt die Kennung der Partition, mit der die Dokumente verknüpft sind, dem TNS.
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
- identifiziert die lokal verfügbaren Partitionen,
- ruft für jeden Mount-Point die Operation listPartitions des für den Mount-Point verantwortlichen Resource Managers eines benachbarten EFA-Providers auf und
- 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
- speichert das Datenobjekt (docData) jedes Dokuments,
- 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
- sucht die Dokumente der jeweiligen Partition entweder lokal,
- oder ruft die Operation listPartitionContent des Document Registry des für die Partition zuständigen EFA-Providers auf,
- 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
- sucht das Datenobjekt entweder lokal
- oder ruft die Operation retrieveData des Document Repository in der für das Dokument zuständigen Affinity Domain auf und
- 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:
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:
- Der EFA-Ressource-Manager ruft die Operation listRecordLocations des EFA-Ressourcen-Managers in der ausstellenden EFA-Provider-Domäne auf.
- 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
- speichert das Datenobjekt (docData) jedes Dokuments,
- 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
- ruft das die Operation retrieveData des Document Repository der lokalen Affinity Domain auf und erhält das consentInfo,
- führt das Muster Speichern und Registrieren von Dokumenten aus,
- berechnet die EFA-Berechtigungsregel und registriert sie beim Policy Provider.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
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) |
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 |
| |
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden:
|
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) |
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 |
| |
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden:
|
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 |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
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 |
| |
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) |
partitionList | Liste von nach übergeordneten Fallakten strukturierten Partitionen des Patienten, die im Ergebnis der Suchanfrage gefunden wurden. | |
Vorbedingungen | ||
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
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 |
| |
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
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 |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und zurückgemeldet werden:
|
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. |
ecrRef | Referenziert die Fallakte, deren EFA-Provider-Domänen aufgelistet werden sollen. | |
Rückgabe | MountPoint* | Liste der Mount-Points |
Vorbedingungen | ||
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und zurückgemeldet werden:
|
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 |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und zurückgemeldet werden:
|
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 |
| |
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
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 |
| |
Eingabe | context | Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext. |
partitionID | Eindeutige Identifizierung der Partition, deren Inhalte ausgelesen werden sollen. | |
Rückgabe | docMetadata[0..*] | Metadaten der an der ausgewählten Partition registrierten Dokumente |
docRelationship[0..*] | Beziehungen zwischen den Dokumenten der zu listenden Partition und Dokumenten dieser und anderer Partitionen. | |
Vorbedingungen | ||
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
invalidateData
Operation | invalidateData | |
---|---|---|
Funktionalität | Invalidieren eines Dokuments in einer Fallakte. | |
Aufrufer |
| |
Eingabe | context | Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext. |
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
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
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 |
| |
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
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 |
| |
Eingabe | context | Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext. |
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) |
docData[0..n] | angeforderte Dokumente | |
Vorbedingungen | ||
Ablauf |
Das Document Repository
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden: |
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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:
|
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
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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) : | |
---|---|---|
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 |
| |
Sequence (Main success scenario) |
| |
Exception | AuthenticationFailedException | Authentication failed due to wrong credentials. |
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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. |
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 |
Implementable Perspective
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
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
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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). |
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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. |
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 |
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 |
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 | |||
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 | |||
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 |
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 |
DigestMethod | For signing assertions the digest method http://www.w3.org/2000/09/xmldsig#sha1 or |
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 |
cdaefa:EFA Access Assertion SAML2 Binding
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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}
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 | |||
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 | |||
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: | |||||
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 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: 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:
Shall contain a SubjectMatch for structural role with attribute value of
| |||||||||||||||||
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:
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):
| |||||
@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 |
DigestMethod | For signing assertions the digest method http://www.w3.org/2000/09/xmldsig#sha1 or |
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 White Paper on Access Control [3]
Referenzen und Querverweise
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
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 |
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 | ||||
---|---|---|---|---|---|
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 |
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 |
cdaefa:EFA XDR SetupCaseRecord cdaefa:EFA XDS ListRecords cdaefa:EFA XDS ListRecordContent cdaefa:EFA XDS ListFolderContent cdaefa:EFA XDS RetrieveDocument cdaefa:EFA XDR ProvideDocument