EFAv2.0
(Die Seite wurde neu angelegt: „<!-- Spezifikation EFAv2.0 --> {{Infobox Dokument |Title Spezifikation "elektronsiche Fallakte" in der Version 2.0 |Short = EFAv2.0 |Namespace = c…“) |
K |
||
Zeile 30: | Zeile 30: | ||
{{HL7transclude| cdaefa:Die EFA als zweckgebundene Akte }} | {{HL7transclude| cdaefa:Die EFA als zweckgebundene Akte }} | ||
{{HL7transclude| cdaefa:Die EFA als Gesundheitsdatendienst }} | {{HL7transclude| cdaefa:Die EFA als Gesundheitsdatendienst }} | ||
+ | {{HL7transclude| cdaefa:EFA Provider }} | ||
+ | {{HL7transclude| cdaefa:Peer-to-Peer-Vernetzung von EFA-Providern }} | ||
+ | {{HL7transclude| cdaefa:Akteure und Rollen der EFA }} | ||
{{HL7transclude| cdaefa:Prinzipien für Datenschutz und Datensicherheit }} | {{HL7transclude| cdaefa:Prinzipien für Datenschutz und Datensicherheit }} | ||
− | |||
− | |||
= Conceptual Perspective - Information Dimension = | = Conceptual Perspective - Information Dimension = |
Version vom 19. Januar 2014, 20:48 Uhr
Dieses Dokument gibt wieder:
Spezifikation EFAv2.0 (02). Die Teilmaterialien gehören der Kategorie cdaefa an. |
EFA-Verein und bvitg
Kontributoren | ||
---|---|---|
EFA-Verein | Aachen | |
bvitg | Berlin | |
Fraunhofer FOKUS | Berlin |
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 CDA für die elektronische Fallakte.
|
Inhaltsverzeichnis
- 1 Einleitung
- 2 Conceptual Perspective - Enterprise Dimension
- 3 Conceptual Perspective - Information Dimension
- 3.1 EFA als Instanz des GDD Referenzmodells
- 3.2 Patienteneinwilligung zur EFA
- 3.3 Hierarchisches Informationsmodell der EFA
- 3.4 Lebenszyklus einer Fallakte
- 4 Conceptual Perspective - Computational Dimension
- 4.1 Interaktionsmuster der EFA
- 4.1.1 Arbeiten mit Fallakten
- 4.1.2 Verwaltung von Fallakten
- 4.1.3 Interaktionsmuster zum Anlegen einer EFA
- 4.1.4 Interaktionsmuster zum Anlegen und Registrieren einer Partition
- 4.1.5 Interaktionsmuster zum Einstellen von Daten in eine Fallakte
- 4.1.6 Interaktionsmuster "Auffinden der Fallakten eines Patienten"
- 4.1.7 Interaktionsmuster "Browsing über einer Fallakte oder einer Partition"
- 4.1.8 Interaktionsmuster "Abruf von Datenobjekten"
- 4.1.9 Interaktionsmuster "Schließen einer Fallakte"
- 4.1.10 Interaktionsmuster zum Invalidieren von Daten in einer Fallakte
- 4.1.11 Interaktionsmuster zum Anpassen einer EFA
- 4.1.12 Interaktionsmuster zur Autorisierung eines weiteren Teilnehmers
- 4.1.13 Interaktionsmuster zum Zusammenführen von Fallakten
- 4.1 Interaktionsmuster der EFA
- 5 Logical Perspective - Enterprise Dimension
- 6 Logical Perspective - Information Dimension
- 6.1 EFA Business Informationsmodell
- 6.1.1 EFA Informationsmodell
- 6.1.2 PIM Data Structures
- 6.1.2.1 patientID
- 6.1.2.2 purpose
- 6.1.2.3 ecrStatus
- 6.1.2.4 consentInfo
- 6.1.2.5 consentDoc
- 6.1.2.6 consentLegalAuthenticator
- 6.1.2.7 caseRecordManager
- 6.1.2.8 consentCustodian
- 6.1.2.9 partitionID
- 6.1.2.10 partitionList
- 6.1.2.11 ecrRef
- 6.1.2.12 partitionInfo
- 6.1.2.13 docMetadata
- 6.1.2.14 docRelationship
- 6.1.2.15 documentID
- 6.1.2.16 communityID
- 6.1.2.17 MountPoint
- 6.2 EFA Sicherheitsinformationsmodell
- 6.3 Fehler und Warnungen
- 6.1 EFA Business Informationsmodell
- 7 Logical Perspective = Computational Dimension
- 7.1 Technische Akteure der EFA
- 7.2 Umsetzungsoptionen für EFA-Speichersysteme (Informativ)
- 7.3 Kommunikationsmuster
- 7.3.1 Aufbau des Sicherheitskontextes
- 7.3.2 Anlegen einer Fallakte
- 7.3.3 Anlegen einer Partition zu einer bestehenden Fallakte
- 7.3.4 Schließen einer Fallakte
- 7.3.5 Auflisten von Partitionen
- 7.3.6 Einstellen von Dokumenten
- 7.3.7 Auflisten von Dokumenten
- 7.3.8 Abrufen von Dokumenten
- 7.3.9 Invalidieren eines Dokuments
- 7.3.10 Registrierung einer neuen Einwilligung
- 7.3.11 Anfordern eines Berechtigungstoken
- 7.3.12 Einlösen eines Berechtigungstoken
- 7.3.13 Konsolidieren von Fallakten
- 7.3.14 Speichern und Registrieren von Dokumenten
- 7.3.15 Verteilen einer Einwilligung im EFA-Verbund
- 7.4 EFA Anwendungsarchitektur: Service Functional Model
- 7.5 Sicherheitstoken und Sicherheitstokendienste
- 7.6 EFA Sicherheits(token)dienste
- 7.7 Gruppierung von Anwendungs- und Sicherheitsdiensten
- 8 Implementable Perspective - Enterprise Dimension
- 9 Implementable Perspective - Information Dimension
- 9.1 Mapping of Core Information Model Classes
- 9.2 Mapping of PIM Classes
- 9.3 Folder Metadata
- 9.4 Document Metadata
- 9.5 Security Object Bindings
- 9.5.1 SAML 2.0 Profile for ECR Identity Assertions
- 9.5.2 SAML 2.0 Profile for ECR Policy Assertions
- 9.5.2.1 PolicySet Profile
- 9.5.2.2 Policy Assignment
- 9.5.2.2.1 Policy Attachment for a health professional
- 9.5.2.2.2 Policy Attachment for health record managers
- 9.5.2.2.3 SubjectMatch for EFA Identity Assertion NameID
- 9.5.2.2.4 SubjectMatch for health professional ID
- 9.5.2.2.5 SubjectMatch for structural role
- 9.5.2.2.6 SubjectMatch for health professional organization ID
- 9.5.2.2.7 ResourceMatch for EFA Folder classification
- 9.5.2.2.8 ResourceMatch for purpose classification
- 9.5.2.2.9 ResourceMatch for patientId
- 9.5.2.3 Assertion Signature
- 9.5.2.4 Example Assertion
- 9.6 EFA Audit Trail Binding for XDS-based Transactions
- 9.7 EFA Error Codes and Warning Codes
- 10 Implementable Perspective - Computational Dimension
- 10.1 EFA Setup
- 10.2 EFA XDR/XDS Binding
- 10.2.1 Constraints and Triggers
- 10.2.2 IHE XDS Options
- 10.2.3 EFA Resource Manager XDR/XDS Binding
- 10.2.3.1 EFA XDS/XDR Binding: createECR
- 10.2.3.2 EFA XDS/XDR Binding: createPartition
- 10.2.3.3 EFA XDS/XDR Binding: closeECR
- 10.2.3.4 EFA XDS Binding: listPartitions
- 10.2.3.5 EFA XDS/XDR Binding: registerConsent
- 10.2.3.6 EFA IHE-ITI-Binding: listRecordLocations
- 10.2.3.7 EFA IHE-ITI-Binding: registerRecordLocation
- 10.2.3.8 EFA IHE-ITI-Binding: notifyOfConsent
- 10.2.4 EFA Document Registry XDS Binding
- 10.2.5 EFA Document Repository XDS Binding
- 10.3 Bindung von Policies an Schnittstellen
- 11 Anhang
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 - Enterprise Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
Peer-to-Peer-Vernetzung von EFA-Providern
Verteilte Fallakten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Petrt.01}
Bei einem einfachen, von einem Krankenhaus betriebenen Zuweiserportal kann zwar jeder Arzt mit mehreren solcher Portale interagieren, muss dazu jedoch an jedem Portal als Nutzer registriert sein und vor allem wissen, über welches Portal er die Daten welches Patienten abrufen kann.
Auch bei der elektronischen Fallakte ist es perspektivisch der Regelfall, dass die Fallaktendaten der Patienten eines Arztes bei verschiedenen EFA-Providern vorgehalten werden. Sofern mehrere in eine Fallbehandlung eingebundene Einrichtungen selbst als EFA-Provider fungieren bzw. mit unterschiedlichen Providern zusammenarbeite, ist es auch möglich, dass die Daten einer Fallakte verteilt bei mehreren EFA-Providern vorgehalten werden.
Dedicated Peers und Trusted Peers
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 |
Conceptual Perspective - Information Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
Patienteneinwilligung zur EFA
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Peen.01.01}
Die elektronische Fallakte ist ein an § 291a SGB V angelehnter Gesundheitsdatendienst. Die EFA ist deshalb nicht durch die spezifische Erlaubnisvorschrift innerhalb der verpflichtenden §291a-Anwendungen befreit, die eine Datenverwendung "soweit es zur Versorgung der Versicherten erforderlich ist" [nach: § 291a (4) Satz 1 SGB V]., ohne eine vorherige spezifische Einwilligung des Patienten zulässig macht: Bei Verarbeitung personenbezogener Daten gilt für die elektronische Fallakte das datenschutzrechtliche Prinzip "Verbot mit Erlaubnisvorbehalt". Demnach ist es nicht gestattet, personenbezogene Daten ohne vorherige Einholung einer Erlaubnis in Form einer Einwilligungserklärung des Betroffenen zu erheben. Für die an § 291a SGB V angelehnten Gesundheitsdatendienste fordert der Gesetzgeber explizit ein ausdrückliches Einverständnis (eine die Datenverarbeitung rechtfertigende Einwilligungserklärung) des Versicherten [§291a (5) Satz 1 SGB V, EU-DSRL].
Es besteht keine verpflichtende Notwendigkeit, der Nutzung der eFA zuzustimmen (Freiwilligkeit). Ein Patient kann jedoch auf Wunsch die EFA als Gesundheitsdatendient in Anspruch nehmen und durch eine freiwillige, informierte und schriftliche Einwilligungserklärung autorisieren.
Der Patient muss vor Abgabe der Einwilligungserklärung in geeigneter Weise über Funktion und Risiken der elektronischen Fallakte aufgeklärt werden. Da eine "informierte Einwilligung" der Patienten erforderlich ist, sollte diese Unterrichtung schriftlich erfolgen und muss zwingend die wichtigsten Eckpunkte der elektronischen Fallakte in allgemein verständlicher Form darlegen [§4a BDSG, §67b Abs. 2 SGB X, EU-DSRL Art. 7]. Die Einwilligung ist bis zur Einführung eines adäquaten elektronischen Verfahrens schriftlich festzuhalten und kann vom Patienten jederzeit widerrufen werden [nach §4a BDSG, §73 Abs. 1b SGB V].
Eine Patienteneinwilligung für eine elektronische Fallakte ist umfassend. Die am aktuellen Behandlungsprozess direkt beteiligten Leistungserbringer sind dabei im Sinne von technischen Positivberechtigungen zugriffsberechtigt. Zugriffsberechtigungen können an Personen oder Einrichtungen vergeben werden. Einrichtungen können, je nach aktuellem Behandlungskontext oder Zweckbindung, folgende Rechtseinheiten sein:
- ein bestimmter Arzt oder eine bestimmte Arztpraxis (bspw. Hausarztpraxis Dr. Peter Müller)
- eine bestimmte Arztrolle (bspw. Kardiologe) mit einer vom Patienten vorzunehmenden Instanziierung
- eine Gemeinschaftspraxis (bspw. Praxis Dr. Peter Müller + Dr. Sandra Müller)
- Fachbereiche oder Fachabteilung eines Klinikums (bspw. Kardiologen der Kardiologie im Klinikum XYZ)
- kombinierte, diagnosespezifische und spezialisierte Facharztrollen (bspw. Dermatologe + Onkologe) mit einer vom Patienten vorzunehmenden Instanziierung
Der Umstand einer Berechtigungsvergabe an eine Organisation(-seinheit) ist jedoch keinesfalls mit einer Pauschalberechtigung für sämtliches Personal einer Einrichtung zu verwechseln, sondern gestattet ausschließlich explizit und direkt Beteiligten den Zugriff nach einem vorab definierten und überprüften Berechtigungsmodell. Als Grundsatz ist hier zwingend von jedem EFA-Verbundmitglied gefordert, dass konkrete Zugriffsberechtigungen prinzipiell für die kleinstmöglichen Bereiche ausgestellt werden.
Als Verfahrens- und Fachverantwortlicher wird von den Teilnehmern eines EFA-Netzwerks ein Fallaktenmanager bestimmt. Der Fallaktenmanager muss in der Einwilligung als verfahrens- und fachverantwortliche Person benannt sein. Sofern der Fallaktenmanager seine operativen Aufgaben auf einen Vertreter delegiert, muss auch diese Person oder Organisationseinheit in der Einwilligung benannt werden. Eine Änderung dieser Festlegungen durch den Patienten ist nicht möglich.
Wenn eine Auftragsdatenverarbeitung vorliegt, muss der Patient darin einwilligen. Eine Auftragsdatenverarbeitung liegt dann vor, wenn der Leistungserbringer EFA-Daten bei einem Drittanbieter speichert. Die Einwilligungserklärung muss in diesem Fall den oder die Drittanbieter als datenhaltende und datenverarbeitende Stelle benennen.
Eine Rücknahme der Einwilligungserklärung durch den Patienten ist jederzeit und freimütig möglich. Eine Rücknahme entzieht der elektronischen Fallakte die rechtliche Existenzberechtigung. Diese ist dann sofort vor externen Zugriffen zu schützen und hat nach dem im Lebenszyklus der Fallakte beschriebenen Verfahren zu verfallen. Der Patient kann die Rücknahme seiner Einwilligungserklärung wahlfrei bei einer beliebigen zugriffsberechtigten Stelle seiner Wahl oder in der bisherigen Einwilligungserklärung benannten verfahrensverantwortlichen Stelle einfordern.
Die Einwilligungserklärung ist für alle Teilnehmer des EFA-Systems zumindest auf nationaler Ebene einheitlich zu gestalten. Dadurch vereinfacht sich eine umfassende datenschutzrechtliche Bewertung der Einwilligungserklärung, zugleich wird die Nutzerakzeptanz durch die einheitliche Darstellung gefördert. Im Bedarfsfall kann die Einwilligungserklärung im Verlauf der Behandlung auf Wunsch des Patienten auf weitere Leistungserbringer erweitert werden. Hierzu kann der Patient den Kreis der zugriffsberechtigten Leistungserbringer durch die Abgabe einer neuen, aktualisierten Einwilligungserklärung erweitern. Es existiert jedoch immer nur eine gültige Einwilligungserklärung. Der Patient ersetzt die vorherige Erklärung wenn er die neuen Erklärung unterschreibt.
Die Historie der Einwilligungen wird in der Fallakte abgelegt. Falls die Einwilligungen nicht elektronisch vorliegen, wird ein Verweis auf den Archivierungsort angegeben.
Referenzen und Querverweise
- EFA-2.0-Spezifikation
- Datenschutzkonzept der EFA Version 1.2
- §291a SGB V
- Bundesdatenschutzgesetz (BDSG)
- Richtlinie 95/46/EG
- §67b Abs. 2 SGB X
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 |
Conceptual Perspective - Computational Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
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 |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 und Registrieren einer Partition
Anwendungsszenario: Anlegen einer Partition zu einer bestehenden Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngei.01.01}
EFA-Teilnehmer können für eine Fallakte relevante Daten entweder in eine bestehende Partition einstellen oder eine neue Partition anlegen, um darüber z.B. eine Verknüpfung mit einem stationären Aufenthalt herzustellen. Auch Strukturierungen auf Daten, die nicht über die Dokumenten-Metadaten herstellbar sind, können über Partitionen realisiert werden (siehe auch Geschäftsobjekt Partition).
Aus der Semantik der Fallakte heraus bilden alle zu dem selben Zweck angelegten Partitionen implizit eine Fallakte. Um eine neue Partition (z.B. zu einem stationären Aufenthalt) anzulegen und einer bestehenden Fallakte hinzuzufügen sind die folgenden Ablaufschritte erforderlich:
- Ein Leistungserbringer ist über die Einwilligung des Patienten zur Nutzung einer EFA berechtigt und damit an dieser als Teilnehmer registriert.
- Der Teilnehmer legt eine neue Partition zu der bestehenden Akte an, um dort Daten zu einem aktuellen stationären Aufenthalt einzustellen und so den anderen EFA-Teilnehmern zugänglich zu machen. Als Zweck der Partition wird der Zweck der Fallakte angegeben. Hiermit ist die neue Partition automatisch mit der bestehenden Akte verknüpft und für alle anderen Teilnehmer der Fallakte zugreifbar.
- Der Teilnehmer registriert in seinen IT-Systemen erstellte Daten an der neuen Partition.
Varianten des Anwendungsszenarios
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngei.02}
Aktuell sind keine Varianten definiert.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngei.03}
Definition der Interaktionsmuster
Interaktionsmuster: Partition anlegen und registrieren
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngei.04.01}
Motivation | Anlegen und Registrieren einer neuen Partition zu einer bestehenden Fallakte. Die Partition repräsentiert innerhalb der Fallakte eine einzelne Behandlungsepisode, einen administrativen Fall oder eine andere semantische Klammer um Behandlungsdaten. |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Aktenidentifikation, Name der Partition, [Anker der Partition], [initiale Dokumente]) --> EFA-Provider |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cngei.05}
Ist ein EFA-Teilnehmer einem EFA-Provider organisatorisch zugehörig, dann legt der EFA-Teilnehmer die neue Partition bevorzugt bei diesem EFA-Provider an.
Ansonsten legen EFA-Teilnehmer eine neue Partition 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
|
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 Einstellen von Daten in eine Fallakte
Anwendungsszenario: Einstellen von Daten in eine Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CiteD.01.01}
Neue Daten zu einer bestehenden Fallakte werden immer in eine vorhandene Partition dieser Akte eingestellt. Welche Partition dies ist, ergibt sich in den meisten Fällen aus dem Kontext der Datenbereitstellung - z.B. weil der zugrunde liegende Krankenhaus-Fall über eine dedizierte Partition an die Fallakte gekoppelt wurde.
Um Daten in eine Partition einzustellen und damit allen berechtigten EFA-Teilnehmern zugänglich zu machen sind die folgenden Ablaufschritte erforderlich:
- Ein Leistungserbringer ist über die Einwilligung des Patienten zur Nutzung einer EFA berechtigt und damit an dieser als Teilnehmer registriert. Diese Einwilligung muss im Vorfeld erteilt worden sein.
- Der Teilnehmer öffnet die gewünschte Fallakte und wählt die Partition aus, in die die neuen Daten eingestellt werden sollen. Die Auswahl der Partition kann dabei auch implizit durch das Teilnehmersystem vorgenommen werden, z.B. aufgrund einer bestehenden Verknüpfung (siehe Interaktionsmuster Anlegen einer Partition).
- Der Teilnehmer sendet in seinen IT-Systemen erstellte Daten an den EFA-Provider und registriert sie an der ausgewählten Partition. Hiermit sind die Daten für alle anderen Teilnehmer der EFA sichtbar und abrufbar.
Varianten des Anwendungsszenarios
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CiteD.01.02}
Neben dem Einstellen orginärer Dokumente in eine Fallakte müssen auch Szenarien des Aktualisierens oder Ergänzens vorhandener Dokumente unterstützt werden.
Aktualisieren eines Dokuments
Ergänzen eines Dokuments
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CiteD.01.03}
Einstellen von Daten in eine Fallakte
Aktualisieren eines Dokuments
Ergänzen eines Dokuments
Definition der Interaktionsmuster
Interaktionsmuster: Daten einstellen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CiteD.04.01}
Motivation | Einstellen von Daten in eine bestehenden Partition einer bestehenden Fallakte. Die eingestellten Daten können dabei in einer Beziehung zu bereits vorhandenen Daten stehen (Aktualisierung, Ergänzung). |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Identifikation der Ziel-Partition, Dokumente und Metadaten, Dokumentenbeziehungen) --> EFA-Provider |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CiteD.01.05}
Sofern ein EFA-Teilnehmer selber auch als EFA-Provider agiert, werden neue Daten von diesem Teilnehmer bevorzugt in einer vom "eigenen" Provider verwalteten Partition angelegt.
Ansonsten stellen EFA-Teilnehmer neue Daten immer bei einem EFA-Provider ein, mit eine entsprechende Vereinbarung über eine Auftragsdatenverarbeitung besteht. Sofern bei diesem Provider noch keine für die Aufnahme der Daten geeignete Partition für die Akte angelegt wurde, muss vor dem Einstellen der Daten zunächst diese Partition registriert werden. Der Patient ist hierüber zu informieren und muss der Auftragsdatenverarbeitung zustimmen (siehe auch Domänenanalyse zur Auftragsdatenverarbeitung).
Referenzen und Querverweise
|
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 "Auffinden der Fallakten eines Patienten"
Anwendungsszenario: Auffinden und Öffnen einer Fallakte eines Patienten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cuina.01.01}
EFA-Teilnehmer können am EFA-Provider abfragen, zu welchen Fallakten eines Patienten sie Zugang haben und anschließend auf die Daten dieser Akten zugreifen.
Aus der Semantik der Fallakte heraus bilden alle zu dem selben Zweck angelegten Partitionen implizit eine Fallakte. Eine Fallakte zu finden und zu öffnen bedeutet daher, dass ein berechtigter Teilnehmer dieser Akte eine Übersicht aller Partitionen der Akte erhält und über diese Daten abrufen und einstellen können. Hierzu sind die folgenden Ablaufschritte erforderlich:
- Ein Leistungserbringer ist über die bei der EFA-Anlage abgegebene Einwilligung des Patienten zur Nutzung einer EFA berechtigt und damit an dieser als Teilnehmer registriert.
- Der Teilnehmer sendet eine Anfrage an den EFA-Provider, in der er den Patient angibt, auf dessen Fallakten er zugreifen möchte.
- Der EFA-Provider prüft, für welche der Fallakten des Patienten der Leistungserbringer als Teilnehmer registriert ist und welche Partitionen diese Akten jeweils aufspannen.
- Aus den vom EFA-Provider gelieferten Daten zu den relevanten Fallakten und Partitionen bekommt der Leistungserbringer einen Überblick, welche Akten für den Patienten aktiv sind und welche Behandlungsepisoden damit erfasst sind. Auf Basis dieser Übersicht kann er anschließend über der Akte und ihren Partitionen browsen und sich die für seine Tätigkeit erforderlichen Dokumente ansehen.
Varianten des Anwendungsszenarios
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cuina.01.02}
Aktuell sind keine Varianten definiert.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cuina.01.03}
Definition der Interaktionsmuster
Interaktionsmuster: Partitionen auflisten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cuina.01.04.01}
Motivation | Auffinden und Auswählen einer Fallakte eines Patienten, um diese im Rahmen einer kooperativen Behandlung zu nutzen. |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Patientenidentifikation, [Diagnose, etc.]) --> EFA-Provider |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cuina.01.05}
Innerhalb eines Peer-to-Peer-Netzes von EFA-Providern werden Suchanfragen an alle teilnehmenden Provider weitergereicht. Der ursprünglich aufgerufene Provider führt die Suchergebnisse zusammen und übermittelt sie an den Aufrufer.
Referenzen und Querverweise
|
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 "Browsing über einer Fallakte oder einer Partition"
Anwendungsszenario: Browsing über eine Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Crsii.01.01}
Fallakten sind in ihrer Nutzeransicht nach fachlichen Vorgaben strukturiert. Wie diese Struktur konkret aussieht ist Gegenstand von Vereinbarungen in regionalen Netzen, Empfehlungen von Fachgesellschaften und/oder Sortiervorgaben des Nutzers. Beispielsweise können für Akten zu bestimmten Diagnosen fest definierte Ordnungsstrukturen vorgegeben sein, so dass Akten zu dieser Diagnose für Nutzer unabhängig von deren Primärsystem immer identisch strukturiert angezeigt werden. Ebenfalls denkbar ist, dass der Nutzer eine Einordnung der Dokumente einer Akte entlang einer Zeitleiste wünscht, z.B. um sich zunächst die aktuellsten Informationen abrufen zu können.
Um diese Flexibilität zu erreichen, ruft das EFA-Teilnehmersystem nach dem Öffnen einer Akte alle Metadaten der in der Akte enthaltenen Dokumente ab. Anhand dieser Metadaten können die Dokumente anschließend in die vorgegebene Anzeige-Struktur einsortiert oder gemäß Nutzervorgaben sortiert werden. Hiermit ist die Daten-Sicht des Arztes vollkommen von der Speicherstruktur in Partitionen entkoppelt.
Im Einzelnen erfolgt das Browsing über einer vollständigen Fallakte in den folgenden Ablaufschritten:
- Ein Leistungserbringer ist über die Einwilligung des Patienten zur Nutzung einer EFA berechtigt und damit an dieser als Teilnehmer registriert. Der Leistungserbringer hat die gewünschte Akte lokalisiert und geöffnet indem sein Teilnehmersystem die zur Akte gehörigen Partitionen identifiziert hat.
- Das Teilnehmersystem ruft die beschreibenden Metadaten zu allen an den Partitionen der Fallakte registrierten Dokumente ab.
- Das Teilnehmersystem stellt die Dokumente anhand der Metadaten in die gewünschte Struktur ein bzw. ordnet diese nach Vorgaben des Nutzers an (z.B. nach Erstellungsdatum) und stellt diese Struktur über eine grafische Benutzeroberfläche dar.
Varianten des Anwendungsszenarios
Suchen und Filtern anhand von definierten Kriterien
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Crsii.01.02.01}
In bestimmten Szenarien können für einen EFA-Teilnehmer nur bestimmte Inhalte einer EFA oder gar nur ein einzelnes spezielles Dokument relevant sein. Ggf. möchte ein Teilnehmer auch nur die Dokumente aufgelistet bekommen, die nach seinem letzten Zugriff auf eine Fallakte neu in diese Akte eingestellt wurden.
Solche Such- und Filter-Funktionen werden bei der EFA clientseitig realisiert. D.h. wie beim Browsing über einer Akte ruft das Teilnehmersystem alle Metadaten der in die Fallakte eingestellten Dokumente ab, und wendet anschließend die Such- und Filter-Kriterien auf diese Metadaten an.
Browsing über einer einzelnen Partition
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Crsii.01.02.02}
Grundsätzlich kann ein Teilnehmersystem dem Nutzer auch in einem ersten Schritt zunächst nur die beim Öffnen der gewünschten Fallakte abgerufenen Informationen zu den verfügbaren Partitionen anzeigen. Insbesondere wenn z.B. in einem regionalen Verbund per Konvention zu jedem stationären Aufenthalt immer eine dedizierte Partition angelegt wird, kann ein Arzt so sehr schnell über diese Partition sehr fokussiert auf die aktuellsten Behandlungsdaten zugreifen.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Crsii.01.03}
Browsing über einer Partition
Browsing über einer Fallakte
Definition der Interaktionsmuster
Interaktionsmuster: Partition abrufen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Crsii.01.04.01}
Motivation | Abrufen der Metadaten der in einer Partition zu einer Fallakte enthaltenen Dokumente. Die Partition repräsentiert innerhalb der Fallakte eine einzelne Behandlungsepisode, einen administrativen Fall oder eine andere semantische Klammer um Behandlungsdaten. |
---|---|
Akteure und Rollen |
Der EFA-Provider stellt sicher, dass Zugriffe nur durch autorisierte EFA-Teilnehmer im Rahmen der diesen für die übergeordnete Fallakte zugewiesenen Rollen erfolgen können. |
Interaktion | Arzt --> (Identifikation der Partition) --> EFA-Provider EFA-Provider --> (Metadaten der Inhalte der Partition) --> Arzt |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Interaktionsmuster: Fallakte abrufen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Crsii.01.04.02}
Motivation | Abrufen der Metadaten aller in einer Fallakte enthaltenen Dokumente. |
---|---|
Akteure und Rollen |
Der EFA-Provider stellt sicher, dass Zugriffe nur durch autorisierte EFA-Teilnehmer im Rahmen der diesen für die Fallakte zugewiesenen Rollen erfolgen können. |
Interaktion | Arzt --> (Aktenidentifikation) --> EFA-Provider EFA-Provider --> (Metadaten der Akteninhalte) --> Arzt |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Crsii.01.05}
Bein Abruf der Dokumente einer Akte müssen alle ggf. über mehrere Peers verteilte Partitionen berücksichtigt werden.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 "Abruf von Datenobjekten"
Anwendungsszenario: Abruf von Daten aus einer Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cbfuo.01.01}
Die EFA unterstützt den Austausch von medizinischen Daten in einer konkreten, einrichtungsübergreifend angelegten Behandlungssituation. Ein wesentlicher Bestandteil dieses Austauschs ist, dass Daten nicht nur im Sinne einer gemeinsamen Dokumentation der Behandlungsteilnehmer in der Fallakte verwaltet werden, sondern auch zur Nutzung im Rahmen der Behandlung aus der Akte abgerufen und in Primärsysteme der EFA-Teilnehmer übernommen werden können.
Die rechts dargestellte Abbildung stellt den Abruf von Dokumenten im Kontext einer typischen EFA-Nutzungssequenz dar.
Um Daten aus einer Fallakte abzurufen sind die folgenden Ablaufschritte erforderlich:
- Ein Leistungserbringer ist über die Einwilligung des Patienten zur Nutzung einer EFA berechtigt und damit an dieser als Teilnehmer registriert. Diese Einwilligung muss im Vorfeld erteilt worden sein.
- Der Teilnehmer öffnet die gewünschte Fallakte, ruft die Metadaten der Inhalte ab und wählt die anzuzeigenden bzw. ins Primärsystem zu übernehmenden Dokumente aus.
- Der Teilnehmer ruft die ausgewählten Dokumente vom EFA-Provider ab und übernimmt sie ggf. in seine Primärdokumentation.
Varianten des Anwendungsszenarios
Aktuell sind keine Varianten definiert.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cbfuo.01.03}
Definition der Interaktionsmuster
Interaktionsmuster: Daten abrufen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cbfuo.01.04.01}
Motivation | Abrufen ausgewählter Daten aus einer Fallakte. |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Identifikation der abzurufenden Dokumente) --> EFA-Provider EFA-Provider --> (Dokumente) --> Arzt |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cbfuo.01.05}
Ein Abruf von auf mehreren Peers verteilt verwalteten Daten muss möglich sein. Teilnehmersystem und EFA-Provider haben in ihrem Zusammenspiel sicher zu stellen, dass die physische Verteilung der Daten einer Fallakte vor dem Nutzer soweit als möglich verborgen bleibt.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 "Schließen einer Fallakte"
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Ccier.01}
Die Existenz einer Fallakte hängt an der vom Patienten gegebenen Einwilligung. Läuft diese mit Erreichen der maximalen Gültigkeit aus oder wird sie vom Patienten zurückgenommen, so muss die Fallakte geschlossen werden. Während unmittelbar und formal aus einer bestehenden Akte ableitbare Schließungen (z.B. Ablauf der Gültigkeit) vom EFA-Provider mit internen Verfahren realisiert werden, erfordern die durch fachliche Gründe oder den Patientenwunsch motivierten Schließungen eine Interaktion von Patient, Arzt und EFA-Provider.
Anwendungsszenario: Rücknahme der Einwilligung durch den Patienten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Ccier.01.01}
Der Patient hat das Recht, seine Einwilligung zur Nutzung einer Akte und zur Bereitstellung seine Daten über eine Akte jederzeit zurückzuziehen. In diesem Fall muss die Akte in einem geregelten Prozess geschlossen werden (siehe auch Lebenszyklus einer Fallakte).
Zur Rücknahme einer Einwilligung und der damit verbundenen Schließung einer EFA sind die folgenden Ablaufschritte erforderlich:
- Der Patient entscheidet sich, die Einwilligung zur Anlage und Nutzung einer Fallakte zurückzunehmen. Er informiert einen der EFA-Teilnehmer über diese Entscheidung.
- Der Teilnehmer dokumentiert den Patientenwunsch (eine Begründung des Patienten ist nicht erforderlich) und übermittelt eine entsprechende Benachrichtigung an den EFA-Provider.
- Der EFA-Provider nimmt die Benachrichtigung zur EFA-Schließung entgegen und stößt die erforderlichen Änderungen im Status der Akte und den damit verbundenen Zugriffsberechtigungen an.
Varianten des Anwendungsszenarios
Wegfall des Zwecks der Akte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Ccier.01.02.01}
Mit dem Wegfall des Zwecks der Fallakte (z.B. durch Heilung oder Tod des Patienten oder durch gravierende Änderungen in der Diagnose oder der Behandlungsplanung) entfällt auch die an diesen Zweck gebundene Einwilligung. In diesem Fall muss von den beteiligten Leistungserbringern die Schließung der Akte angestoßen werden. Sofern möglich ist der Patient hierüber zu informieren.
Die IT-gestützten Abläufe dieser Variante sind analog zum Hauptszenario.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Ccier.01.03}
Definition der Interaktionsmuster
Interaktionsmuster: EFA Schließen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Ccier.01.04.01}
Motivation | Schließen einer bestehenden Fallakte. |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Aktenidentifikation, Grund der Schließung, [Erklärungen]) --> EFA-Provider |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Ccier.01.05}
Der EFA-Provider leitet die Aufforderung zur Schließung der Akte an alle EFA-Provider weiter, bei denen Partitionen dieser Akte verwaltet werden. Diese leiten die Schließung der bei ihnen verwalteten Partitionen gemäß des Lebenszyklus einer EFA ein.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 Invalidieren von Daten in einer Fallakte
Anwendungsszenario: Invalidieren von Daten in einer Fallakte
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnlio.01.01}
In eine Fallakte eingestellte Daten (siehe Interaktionsmuster Einstellen von Datenobjekten) sind für alle EFA-Teilnehmer sichtbar und abrufbar. Die Pflege der Inhalte einer EFA ist die gemeinsame Aufgabe aller EFA-Teilnehmer; daher kann jeder Teilnehmer jedes in der EFA befindliche Dokument deaktivieren oder ersetzen, wenn dieses nicht mehr aktuell ist oder zur Erreichung des Zwecks der Akte nicht mehr benötigt wird.
Einwilligungsdokumente DÜRFEN NICHT invalidiert werden. EFA-Teilnehmer können Einwilligungsdokumente mit den Interaktionsmustern Ändern der Einwilligung und Schließen der Fallakte administrieren.
Das Invalidieren eines Dokuments in einer EFA entfernt dieses Dokument nicht aus der Fallakte, da es ggf. bereits von anderen Teilnehmern abgerufen wurde und daher die Dokumentenreferenz in jedem Fall gültig bleiben muss und das Dokument auch für die Nachvollziehbarkeit der EFA-Nutzung beim Schließen der Akte mitsamt der Akte archiviert werden muss. Statt dessen wird beim Invalidieren der Status des Dokuments so verändert, dass es nur noch für spezielle Rolleninhaber sichtbar ist (z.B. für den Fallaktenmanager). Alle anderen Teilnehmer sehen das Dokument beim Auflisten der EFA-Inhalte nicht mehr und können es daher auch nicht mehr nutzen.
Um Daten zu invalidieren und damit den Dokumentenstatus entsprechend zu ändern sind die folgenden Ablaufschritte erforderlich:
- Ein Leistungserbringer ist über die Einwilligung des Patienten zur Nutzung einer EFA berechtigt und damit an dieser als Teilnehmer registriert. Diese Einwilligung muss im Vorfeld erteilt worden sein.
- Der Teilnehmer öffnet die gewünschte Fallakte und listet die enthaltenen Dokumente auf (siehe Interaktionsmuster Browsing über einer Akte oder Partition).
- Der Teilnehmer wählt über sein IT-System das zu invalidierende Dokument aus.
- Der Teilnehmer sendet eine Nachricht an den EFA-Provider, das ausgewählte Dokument zu invalidieren.
Varianten des Anwendungsszenarios
Aktuell sind keine Varianten definiert
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnlio.01.03}
Definition der Interaktionsmuster
Interaktionsmuster: Daten invalidieren
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnlio.01.04.01}
Motivation | Invalidieren eines Dokuments in einer Fallakte. |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Identifikation der Ziel-Partition, Identifikation des zu invalidierenden Dokuments) --> EFA-Provider |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
Aktuell sind keine Ausnahmeszenarien definiert |
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnlio.01.05}
Durch die explizite Benennung der Partition kann der Peer identifiziert werden, auf dem die zu invalidierenden Daten verwaltet werden.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 Anpassen einer EFA
Anwendungsszenario: Anpassen des Teilnehmerkreises
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnssi.01.01}
Der Patient bestimmt den EFA-Teilnehmerkreis (siehe Patientenhoheit). Allgemein besteht er aus der Gruppe der behandelnden Einrichtungen und Personen, unterliegt aber Änderungen, wenn
- der Patient weitere Leistungserbringer in die Behandlung einbezieht,
- der Patient einen Arzt auswechselt oder
- die Behandlungsteilnahme eines Leistungserbringers abgeschlossen ist.
Ist eine Änderung des EFA-Teilnehmerkreises erforderlich, gibt der Patient gegenüber einem teilnehmenden Arzt eine neue Einwilligung ab, in der der zu berechtigende Teilnehmerkreis benannt ist.
Ein behandelnder Arzt stimmt die Änderung des EFA-Teilnehmerkreises mit dem Patienten typischerweise im folgenden Ablauf ab:
- Der Arzt oder der Patient erkennt, dass der EFA-Teilnehmerkreis an den Kreis der Behandlungsteilnehmer angeglichen werden muss.
- Der Arzt und der Patient vereinbaren einen dem aktuellen Behandlungsgeschehen angepassten Kreis von behandelnden Ärzten/Einrichtungen.
- Die Vereinbarung wird in einer Einwilligungserklärung festgehalten. Der Patient unterschreibt die Einwilligungserklärung und gibt sie dem Arzt.
- Der Arzt erfasst die Daten der Einwilligung elektronisch, sofern sie nicht bereits z.B. aus einem elektronischen Formular erzeugt worden war. Der Arzt bestätigt die Richtigkeit der Angaben, die Datenschutzkonformität des Ablaufs der Einwilligungserteilung und das Vorhandensein einer vom Patienten unterschriebenen Kopie.
- Der Arzt übermittelt die für die Anpassung der Akte erforderlichen Informationen (insb. die neue Liste der zu berechtigenden Behandlungsteilnehme) an den EFA-Provider. Sofern vorliegend, wird auch eine elektronische Kopie der Einwilligung an einen EFA-Provider geschickt.
- Der EFA-Provider setzt die Berechtigungen für den Zugriff auf die Akte gemäß den Vorgaben der neuen Einwilligungserklärung auf.
Mit diesem Interaktionsmuster können ausschließlich EFA-Teilnehmer benannt werden. Die Belegung der Rolle des Fallaktenmanagers einer EFA kann durch den Patienten nicht geändert werden und ist daher auch über dieses Interaktionsmuster nicht möglich. |
Varianten des Anwendungsszenarios
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnssi.01.02}
Variante: Anpassung der Zweck-Parameter
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnssi.01.02.01}
Im Rahmen einer Diagnosestellung kann ein Leistungserbringer eine Fallakte anlegen, deren Zweck zunächst an eine weitgefasste Beschreibung des medizinischen Falls gebunden ist. Soll die Fallakte auch im Rahmen der Behandlung weitergeführt werden, müssen Laufzeit, medizinischer Fall (und alle daran hängenden Konfigurationen) sowie ggf. auch der Kreis der Teilnehmer an die neue Behandlungssituation angepasst werden. Hierzu ist auch eine neue Einwilligung des Patienten erforderlich.
Variante: Verlängerung der Gültigkeit
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnssi.01.02.02}
Bei Neuanlage einer Fallakte wird diese mit einer Gültigkeitsdauer versehen. Mit Ablauf der Gültigkeit werden die bisherige Aktennutzung und die zukünftigen Kommunikationserfordernisse bewertet. Je nach Ergebnis kann dies zur Schließung der Akte mit Ablauf der Gültigkeit oder zu einer Verlängerung der Gültigkeit (ggf. mit Anpassungen an der Aktenkonfiguration) führen.
Soll die Fallakte im Rahmen der Behandlung weitergeführt werden, muss die Gültigkeitsdauer verlängert werden. Hierzu ist auch eine neue Einwilligung des Patienten erforderlich.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnssi.01.03}
Definition der Interaktionsmuster
Interaktionsmuster: Fallakte anpassen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Cnssi.01.04.01}
Motivation | Anpassen einer Fallakte an eine veränderte Behandlungsorganisation/-situation |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Aktenkennung, [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 {Cnssi.01.05}
Sofern ein EFA-Teilnehmer selber auch als EFA-Provider agiert und eine Partition der Akte bei diesem Provider besteht, wird die Anpassung einer Fallakte von diesem Teilnehmer bevorzugt über diesen "eigenen" Provider ausgelöst.
Ansonsten kann die Anpassung der Fallakte über jeden Provider angestoßen werden, bei dem eine Partition der zu verändernden Akte angelegt ist. Der Provider ist verpflichtet, die neuen Konfigurationsdaten der Akte (Zweck, Gültigkeit, Teilnehmer) sowie die ggf. übermittelte Einwilligung an alle EFA-Peers weiter zu reichen, bei denen ebenfalls Partitionen zu der betroffenen Akte angelegt sind.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 zur Autorisierung eines weiteren Teilnehmers
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01}
In kooperativen Behandlungsszenarien kann von den an der Behandlung teilnehmenden Ärzten eine elektronische Fallakte genutzt werden, um die Effizienz des fall-bezogenen, einrichtungsübergreifenden Datenaustausch zu steigern. Der Teilnehmerkreis der Akte wird vom Patienten bestimmt und entspricht im Normalfall der Gruppe der an der Behandlung teilnehmenden Einrichtungen und Personen. Diese werden in der Einwilligung des Patienten benannt und im EFA-Berechtigungssystem mit ihren jeweiligen Rollen entsprechenden Zugriffsrechten versehen.
Änderungserfordernisse an der Zusammensetzung des EFA-Teilnehmerkreises können sich ergeben, wenn der Patient weitere Leistungserbringer in die Behandlung einbezieht, die einen Zugang zur EFA erhalten sollten. Hierzu bestehen grundsätzlich drei Optionen:
- Der Patient gibt gegenüber einem berechtigten Leistungserbringer eine neue Einwilligungserklärung ab
- Der Patient beauftragt einen berechtigten Leistungserbringer, eine bestehende Einwilligung um einen einzelnen, identifizierten Leistungserbringer (Arzt oder Einrichtung) zu erweitern
- Der Patient hat (z.B. bei der Anlage der EFA) ein oder mehrere Offline-Token erhalten. Durch Übergabe eines solchen Tokens an einen Leistungserbringer wird diesem eine Berechtigung zur Nutzung der EFA eingerichtet.
Die ersten beiden Optionen werden im Interaktionsmuster zur Änderung einer Einwiligung beschrieben. Die dritte Option wird durch das auf dieser Seite definierte Interaktionsmuster abgedeckt.
Anwendungsszenario: Offline-Token
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01.01}
Diese Erweiterung des Nutzerkreises einer Fallakte über ein Offline-Token folgt typischerweise dem folgenden Ablauf:
- Der Patient fordert bei einem zum Aktenzugriff berechtigten Arzt (z.B. im Zuge der Anlage der Fallakte) ein Offline-Token an.
- Ein zum Aktenzugriff berechtigter Arzt fordert ein Berechtigungstoken beim EFA-Provider an. Der EFA-Provider stellt das Token in digitaler Form aus und sendet es an den Arzt.
- Der Arzt bringt das Berechtigungstoken auf ein geeignetes Trägermedium (z.B. als Barcode auf Papier) und übergibt es an den Patienten.
- Der Patient möchte einen weiteren Arzt zu der EFA hinzuziehen und übergibt ihm ein dazu geeignetes Offline-Token.
- Der zu berechtigende Arzt liest das Offline-Token ein.
- Der zu berechtigende Arzt über mittelt Angaben zu seiner Identität sowie die Inhalte des Offline-Tokens an den EFA-Provider.
- Die Berechtigungen zum Zugriff auf die Akte werden vom EFA-Provider gemäß den Vorgaben im Offline-Token auf den neuen Teilnehmer ausgeweitet.
Es ist zu beachten, dass über dieses Interaktionsmuster ausschließlich weitere EFA-Teilnehmer benannt werden können. Die Belegung der Rolle des Fallaktenmanagers einer EFA kann durch den Patienten nicht geändert werden und ist daher auch über dieses Interaktionsmuster nicht möglich. |
Varianten des Anwendungsszenarios
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01.02}
Variante: Online-Token
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01.02.01}
Das zur Berechtigungserweiterung genutzte Token muss nicht zwingend auf Papier und über den Patienten übermittelt werden. Ebenso sind elektronische Umsetzungen denkbar, die dem neu zu berechtigenden Arzt vom Patienten oder einem bereits berechtigten Arzt über eine sichere Kommunikationsverbindung übermittelt werden. Hierzu kann beispielsweise das KOM-LE Protokoll oder eine ePA-291a genutzt werden.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01.03}
Token ausstellen
Teilnehmer per Token autorisieren
Definition der Interaktionsmuster
Interaktionsmuster: Token ausstellen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01.04.01}
Motivation | Autorisierung eines zusätzlichen Leistungserbringers zur Nutzung einer EFA |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Aktenkennung) --> EFA-Provider EFA-Provider --> (Berechtigungstoken) --> Arzt |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien | - |
Interaktionsmuster: Teilnehmer per Token autorisieren
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01.04.02}
Motivation | Autorisierung eines zusätzlichen Leistungserbringers zur Nutzung einer EFA |
---|---|
Akteure und Rollen |
|
Interaktion | Arzt --> (Berechtigungstoken, Identifikation des Leistungserbringers) --> EFA-Provider |
Vorbedingungen |
|
Ablauf |
|
Eingangsinformationen |
|
Nachbedingungen |
|
Ausnahmeszenarien |
|
Peer-to-Peer Semantik
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {CAoug.01.05}
Sofern ein EFA-Teilnehmer selber auch als EFA-Provider agiert und eine Partition der Akte bei diesem Provider besteht, wird die Anlage einer Berechtigung über diesen "eigenen" Provider ausgelöst.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Interaktionsmuster zum Zusammenführen von Fallakten
Anwendungsszenario: Zusammenführen von Fallakten
Für einen Patienten wurden zwei Fallakten mit unterschiedlichen Zwecken angelegt. Der Arzt des Patienten möchte die beiden Fallakten zusammenführen, da sie den gleichen medizinischen Fall dokumentieren.
- Vorbedingungen
- Für den Patienten werden zwei Fallakten geführt, die nicht mit dem gleichen Zweck angelegt wurden.
- Der Arzt ist ein EFA-Teilnehmer beider Fallakten.
- Der Arzt kann die Identität des Patienten vertrauenswürdig feststellen.
- Ablauf
- Der Arzt informiert den Patienten darüber, dass beide Fallakten zusammengeführt werden können. Er nennt die Vorteile und Risiken der Zusammenführung der Fallakten und erklärt, welche Daten zwischen welchen Akteuren ausgetauscht werden. Er weist den Patienten darauf hin, dass die Zusammenführung der Fallakten ein freiwilliges Angebot ist und dass er jederzeit die Schließung der zusammengeführten Fallakte verlangen kann ohne dass es einen Abbruch der Behandlungen zur Folge hat. Er weist auch darauf hin, dass mit der Zusammenführung der Fallakten die Einwilligungen zu den beiden bestehenden Fallakten erlöschen.
- Der Arzt nennt dem Patienten, den Zweck der Zusammengeführten Fallakte, das Verfallsdatum sowie den Kreis der EFA-Teilnehmer.
- 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 Zusammenführung der Fallakten erforderlichen Informationen einschließlich einer Kopie der Einwilligung an einen EFA-Provider.
- Der EFA-Provider führt die Fallakten gemäß den Vorgaben des Arztes zusammen. Die Berechtigungen zum Zugriff auf die zusammengeführte Fallakte werden gemäß den Vorgaben der Einwilligungserklärung aufgesetzt.
- Ergebnis
- Die zusammengeführte Fallakte ist verfügbar. Ihre Konfiguration entspricht den Daten der Einwilligungserklärung und den Vorgaben des Arztes. Sie enthält die Partitionen und Dokumente der beiden ursprünglichen Fallakten.
- Die beiden ursprünglichen Fallakten sind nicht mehr verfügbar.
- Ausnahmen
- Der Patient willigt nicht in die Zusammenführung der Fallakten ein.
Abbildung der Szenarien und Varianten auf Interaktionsmuster
Das Anwendungsszenario "Zusammenführen von Fallakten" ist äquivalent zum Anwendungsszenario Anpassung der Zweck-Parameter: Der Zweck der einen Fallakte wird geändert, sodass beide Fallakten den gleichen Zweck haben und somit zusammengeführt sind.
- Bereitgestellte Informationen
- Kennung der Fallakte, deren Zweck geändert wird,
- angepasster Zweck der Akte,
- angepasster Teilnehmerkreis der Akte (identifizierende Daten, Rollen bzw. Autorisierungen): das sind die EFA-Teilnehmer der beiden ursprünglichen Fallakten,
- elektronisches Einwilligungsdokument oder Bestätigung des Arztes, dass eine solche Einwilligung vorliegt.
- Nachbedingungen
- Die Einwilligungserklärungen der ursprünglichen Fallakten werden mit der neuen Einwilligungserklärung ersetzt.
Referenzen und Querverweise |
Logical Perspective - Enterprise Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 |
Logical Perspective - Information Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
EFA Sicherheitsinformationsmodell
EFA Sicherheitskontext
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.01}
Alle Aufrufe einer EFA-Funktionalität erfolgen innerhalb eines definierten Sicherheitskontextes, der über den EFA Context Manager aufgebaut und verwaltet wird.
Grundsätzlich macht diese Spezifikation nur wenige Vorgaben, welche Sicherheitsobjekte im Sicherheitskontext abgelegt sind und wie diese Objekte in den Sicherheitskontext gelangen. Hierdurch entkoppelt der über ein context-Objekt gekapselte Sicherheitskontext die EFA-Anwendungsarchitektur von der darunter liegenden Sicherheitsarchitektur. EFA-Dienste erhalten mit jedem Operationsaufruf eine Kopie des lokalen context-Objekts und können anhand der darin enthaltenen Informationen die eigenen Sicherheitsdienste zur Authentisierung und Autorisierung ausführen.
PIM Data Structures
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02}
Die nachfolgend beschriebenen Objektklassen werden im Rahmen des EFA Service Functional Model verwendet und bilden das Informationsmodel des Platform Independent Model der EFA Sicherheitsarchitektur.
context
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.01}
Die Klasse context entkoppelt Anwendungs- und Sicherheitsarchitektur der EFA. Jeder Aufruf einer EFA-Operation enthält eine Kopie des im lokalen EFA Context Manager des EFA-Clients verwalteten context-Objekts.
Während in der EFA-1.2-Spezifikation noch vier Sicherheitsnachweise über die Klasse context gekapselt wurden, sind in der EFA-2.0-Spezifikation zunächst nur zwei Nachweise normativ spezifiziert. Weitere Sicherheitsnachweise können für Ergänzungen dieser Spezifikation bzw. auch für einzelne Umsetzungen der EFA 2.0 definiert werden. Wesentlich ist lediglich, dass hierbei das logische Konstrukt des context zur Verwaltung und zum Austausch dieser Nachweise genutzt wird. Hierdurch sind die Interoperabilität auf der logischen Ebene sowie die grundsätzliche Migrationsfähigkeit in die Telematikinfrastruktur sichergestellt.
Die nebenstehende Abbildung stellt den Aufbau der context-Klasse dar:
- eine subjectIdentity kapselt die Identität des EFA-Teilnehmers und sichert bei Dienstaufrufen die Authentizität des EFA-Teilnehmers ab.
- eine subjectAccessPolicy beschreibt die Zugriffsberechtigungen des über die subjectIdentity identifizierten EFA-Teilnehmers.
In jedem Sicherheitskontext muss genau ein subjectIdentity-Objekt vorhanden sein. Dieses wird durch den EFA Context Manager im Rahmen der Identifizierung und Authentifizierung des EFA-Teilnehmers von einem Identity Provider ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe Optionen zur Authentifizierung von EFA-Teilnhemern).
Eine subjectAccessPolicy ist nur bei Verwendung eines Policy-Push Verfahrens Bestandteil des Sicherheitskontextes. Ansonsten erfolgt der Abruf von Berechtigungsregeln on demand über den EFA-Dienst, der die angefragte Ressource verwaltete.
Sofern weitere Sicherheitsnachweise über ein context-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das subjectIdentity-Objekt gebunden sein, da nur so eine integre und authentische Nachweis-Kette aufgebaut werden kann.
ecrParticipant
Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen und dient dessen eindeutiger Identifizierung im Kontext eine konkreten Fallakte. Ein EFA-Teilnehmer ist dabei immer eine Organisation oder eine einer Organisation zugeordnete Person.
In der Klasse ecrParticipantwerden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefass:
- ID des EFA-Teilnehmers
- Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ecrParticipant-Nachweis muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert.
- Name des EFA-Teilnehmers
- Zur besseren Nachvollziehbarkeit der Überführung einer Papier-Einwilligung auf eine elektronische Einwilligungsdokumentation, muss dort der Name des berechtigten Teilnehmers wie in der Einwilligung angegeben enthalten sein.
ecrAuthenticatedUser
Die Nutzung einer EFA ist nur für identifizierte und authentifizierte Personen möglich. Zum Zugriff auf eine konkrete EFA muss diese Person entweder
- in der Einwilligung benannt oder
- einer dort als berechtigt benannten Organisation angehören und gemäß den Regularien dieser Organisation zum Zugriff auf diese EFA berechtigt sein.
Die Klasse ecrAuthenticatedUser fasst Informationen zu einem EFA-Nutzer zusammen. Es wird mit jeder Anfrage an einen EFA-Dienst übermittelt und soll es dem aufgerufenen Dienst ermöglichen, den Aufrufer zu authentisieren und dessen Berechtigungen anhand der verfügbar gemachten Informationen auszuwerten und durchzusetzen.
In einem ecrAuthenticatedUser Nachweis müssen mindestens die folgenden Informationen enthalten sein:
- ID des EFA-Teilnehmers
- Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ecrAuthenticatedUser-Objekt muss ein eindeutiger Identifier des EFA-Nutzers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (siehe oben).
- Name des EFA-Teilnehmers
- Anhand der im Audit Trail zu Datenschutzzwecken protokollierten Aktenzugriffe muss der Patient Information darüber erhalten können, wer wann und wieso auf welche Daten des Patienten zugegriffen hat. In jedem ecrAuthenticatedUser-Objekt muss der Klartextname des EFA-Teilnehmers enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.
- Art der Authentifizierung und authentifizierende Stelle
- Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe EFA Sicherheitsprinzipien). Hierzu gehört, dass der Provider die Vertrauenswürdigkeit einer ggf. an anderer Stelle vorgenommenen Authentifizierung bewerten können muss. Aus diesem Grund muss ein ecrAuthenticatedUser-Objekt sichtbar machen, wie sich der EFA-Nutzer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
- Prüfdaten zur Feststellung der Authentizität des EFA-Nutzers
- Ein EFA-Provider muss verifizieren können, dass die einen Dienst aufrufende Person der EFA-Teilnehmer ist, für den er/sie sich ausgibt. Entsprechende Prüfdaten müssen fest an ein ecrAuthenticatedUser-Objekt gebunden sein.
- Prüfdaten zur Feststellung der Authentizität und Integrität des ecrAuthenticatedUser-Objekts
- Eine Verifizierbarkeit der Daten eines ecrAuthenticatedUser-Objekt ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jedes ecrAuthenticatedUser-Objekt von der ausstellenden Stelle signiert werden.
- Point of Care
- Zur Nachvollziehbarkeit der Instantiierung von an Organisationen vergebenen Berechtigungen muss in dem ecrAuthenticatedUser-Nachweis benannt sein, von wo aus der Zugriff auf Patientendaten erfolgt.
Ein ecrAuthenticatedUser-Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden.
subjectAccessPolicy
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.03}
Dieses Sicherheitsobjekt fasst Informationen zu den Berechtigungen eines EFA-Teilnehmers zusammen. Sofern für eine EFA-Umsetzung ein Policy-Push Verfahren genutzt wird, erfolgen Abruf und Austausch dieses Sicherheitsobjekts in folgender Sequenz:
- ein EFA-Provider oder ein EFA-Dienst gibt in seiner Schnittstellenbeschreibung an, dass die zum Zugriff zu überprüfenden Berechtigungen von einem dedizierten Sicherheitsdienst (EFA Policy Provider) verwaltet werden und als Teil des Dienstaufrufs vom EFA-Teilnehmer bereitgestellt werden müssen
- der Context Manager des EFA-Clients ruft die als subjectAccessPolicy kodierten Berechtigungen des über eine subjectIdentity identifizierten und authentisierten EFA-Teilnehmers vom EFA Policy Provider ab
- der Context Manager fügt jedem Dienstaufruf die subjectAccessPolicy bei.
- der aufgerufene Dienst wertet die subjectAccessPolicy unter Nutzung von Attributen der Ressource und des Nutzers (subjectIdentity) aus und setzt sie durch.
In einem subjectAccessPolicy Sicherheitsnachweis müssen mindestens die folgenden Informationen enthalten sein:
- Bindung an eine subjectIdentity
- Eine subjectAccessPolicy ist immer für einen bestimmten EFA-Teilnehmer gültig und kann auch nur von diesem für selbst veranlasste Zugriffe genutzt werden. Durch Bindung einer subjectAccessPolicy an eine subjectIdentity kann der aufgerufene Dienste verifizieren, dass die subjectAccessPolicy auch wirklich für den Aufrufer ausgestellt wurde und von diesem eingebracht wird.
- Prüfdaten zur Feststellung der Authentizität und Integrität der subjectAccessPolicy
- Eine Verifizierbarkeit der Daten einer subjectAccessPolicy ist nur gegeben, wenn die subjectAccessPolicy selbst integer und authentisch ist. Daher muss jede subjectAccessPolicy von der ausstellenden Stelle signiert werden.
Zusätzlich enthält die subjectAccessPolicy die Berechtigungen des EFA-Teilnehmers. Analog zum GDD Referenzmodell können diese Berechtigungen auf der Ebene der Anwendung oder auf der Ebene der Ressource definiert sein:
- Anwendungsberechtigungen: Die subjectAccessPolicy definiert die Berechtigungen eines Leistungserbringers im Kontext eines EFA-Providers. Hierzu zählen z.B. Berechtigungen zur Anlage von Fallakten, zum Einstellen von Daten bei diesem Provider oder zur Besetzung bestimmter Rollen (z.B. Berechtigung, als Fallaktenmanager zu agieren). Die Berechtigungen spiegeln damit die vertraglichen und organisatorischen Bindungen zwischen dem Leistungserbringer und einem EFA-Provider wider.
- Ressourceberechtigungen: Die subjectAccessPolicy definiert die Berechtigungen eines Leistungserbringers im Kontext einer konkreten Fallakte. Hierzu zählen insbesondere die aus der Einwilligung des Betroffenen abgeleiteten Zugriffsrechte auf dieser Fallakte. Die Berechtigungen spiegeln damit die vertraglichen Vereinbarungen zwischen dem Leistungserbringer und einem Patienten wider.
Grundsätzlich können beide Arten von Berechtigungen auch in einem Regelwerk kombiniert werden.
accessToken
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.04}
Diese Klasse beschreibt ein Token, das ein EFA-Teilnehmer einreichen kann, um Zugang zu einer Fallakte zu erhalten. Das Token ist eine Referenz auf eine Token Redeem Policy. Sie ist beim Aussteller des Token registriert und beschreibt, welcher EFA-Teilnehmer das Token innerhalb welches Zeitfensters einreichen darf und welche Berechtigungen auf die Fallakte damit verknüpft sind.
Die Struktur des Tokens ist in der EFA-1.2-Spezifikation eCR Offline Token - Service Architecture definiert.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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".
Fehler und Warnungen
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Feeln.01}
Analog zu den Spezifikationen der Dienste und Operationen werden in der EFA 2.0 Spezifikation auch Fehler und Warnungen auf zwei Ebenen definiert:
- auf der logischen Ebene sind Fehler und Warnungen definiert, die in direktem Zusammenhang mit den anderen Artefakten dieser Ebene - insbesondere Kommunikationsmustern, Service Functional Models und Informationsmodellen - stehen. Logische Fehler und Warnungen beschreiben eine Ausnahmesituation und geben ggf. Hinweise zu deren Auflösung.
- eine Belegung der logischen Fehler und Warnungen mit Fehlercodes und Fehlermeldungen ist Teil des Bindings der Operationen, in denen der Fehler ausgelöst werden kann. Werden die EFA-Operationen z.B. an IHE XDS/XDR gebunden, so müssen auch die logischen EFA-Fehler und -Warnungen an die für XDS/XDR definierten Fehlermechanismen, -codes und -meldungen gebunden werden.
In diesem Abschnitt werden alle von einem konkreten technischen Binding unabhängigen Fehler und Warnungen aufgelistet und beschrieben. Hierbei wird zwischen Ausnahmesituationen im Zusammenhang mit der sicheren Kommunikation zwischen logischen EFA-Bausteinen und mit einzelnen Argumenten eines Operationsaufrufs zusammenhängenden Problemen unterschieden. Fehlern und Warnungen, die spezifisch für eine einzelne Operation sind, werden an dieser Stelle nicht aufgeführt, sondern im Kontext der logischen Spezifikation der entsprechenden Operationen beschrieben.
Sicherheit(skontext)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Feeln.01.01}
Schutzziel | Fehler bzw. Warnung | Betroffene Dienste |
---|---|---|
Identifizierung und Authentifizierung von EFA-Teilnehmern | Fault: Invalid Subject Die Identität eines EFA-Teilnehmers ist für einen EFA-Dienste nicht verifizierbar. Dieser Fehler kann z.B. auftreten, wenn ein EFA-Teilnehmer im Rahmen der Identifizierung/Authentifizierung durch eine ID repräsentiert wird, die einer ID-Domäne entnommen wurde, die dem EFA-Provider nicht bekannt ist bzw. von diesem nicht unterstützt wird. |
Angaben zur Identität und Authentizität von EFA-Teilnehmern werden über Sicherheitsnachweise als Sicherheitskontext gekapselt und als Teil eines Operationsaufrufs übertragen. Da alle EFA-Dienste einen solchen Sicherheitskontext erfordert, müssen die hier aufgeführten Fehlerfälle von allen EFA-Diensten geprüft und ggf. angezeigt werden. |
Fault: Weak Authentication Das zur Authentifizierung des EFA-Teilnehmers genutzte Verfahren wird von einem EFA-Dienste nicht akzeptiert bzw. der die Authentifizierung bestätigende Dienst wird nicht als vertrauenswürdig anerkannt. Beispielsweise kann ein EFA-Provider festlegen, dass eine alleinige Authentisierung über User-ID/Passwort für einen Zugriff auf EFA-Daten nicht ausreichend ist. | ||
Fault: Insufficient Attributes Die zum EFA-Teilnehmer verfügbaren Attribute sind unvollständig oder unzureichend. Dieser Fehlerfall liegt insbesondere dann vor, wenn die bereitgestellten Angaben zum Nutzer nicht ausreichen, um eine Zugriffskontrollentscheidung zu treffen oder einen den Sicherheitsanforderungen genügenden Audit Trail zu schreiben. | ||
Autorisierung von EFA-Teilnehmern | Fault: Insufficient Permissions Der EFA-Teilnehmer ist zwar grundsätzlich zum Zugang zu einer Fallakte berechtigt, verfügt aber nicht über die konkreten Rechte zur Durchführung der angeforderten Operation. Dieser Fehlerfall kann vor allem in Zusammenhang mit Sonderrollen der EFA auftreten. |
Bei der Prüfung von Zugriffsrechten werden die in einer Einwilligung definierten Berechtigungen mit den im aktuellen Sicherheitskontext gekapselten Nutzerattributen abgeglichen. Da alle Operationen der EFA einer Berechtigungsprüfung unterliegen, müssen die hier aufgeführten Fehlerfälle von allen EFA-Diensten geprüft und ggf. angezeigt werden. |
Fault: Policy Mismatch Die in dem Identitätsnachweis genutzten Kodierungen der Nutzer-Attribute (z.B. zu Rollen und Organisationszugehörigkeiten) können nicht eindeutig auf die in den Berechtigungsregeln einer EFA genutzten Attribute abgebildet werden. | ||
Fault: Grace Period Die zum EFA-Teilnehmer verfügbaren Attribute sind unvollständig oder unzureichend. Dieser Fehlerfall liegt insbesondere dann vor, wenn die bereitgestellten Angaben zum Nutzer nicht ausreichen, um eine Zugriffskontrollentscheidung zu treffen oder einen den Sicherheitsanforderungen genügenden Audit Trail zu schreiben. | ||
Vertraulichkeit | Fault: No Channel Der zur Übertragung von Daten benötigte sichere Kommunikationskanal kann nicht aufgebaut werden. |
Dieser Fehlerfall betrifft vorrangig den EFA-Client, der für den Aufbau sicherer Kommunikationskanäle zu allen genutzten EFA-Diensten verantwortlich ist. |
Authentizität und Integrität von EFA-Daten | Fault: Integrity Violation Die Integrität übermittelter medizinischer Daten und/oder zugehöriger Metadaten ist nicht gegeben bzw. kann nicht in dem erforderlichen Maß verifiziert werden. |
Diese Fehlerfälle betreffen alle Operationen, in denen Dokumente oder Metadaten übertragen werden. |
Fault: No Originator Authenticity In übertragenen Daten oder Metadaten fehlen ausreichend abgesicherte Angaben zu der für diese Daten verantwortlichen Person bzw. Organisation. | ||
Nicht-Abstreitbarkeit, Dokumentation und Audit-Trail | Fault: Audit Trail Failure Ein Audit Trail Eintrag kann nicht geschrieben werden, so dass die angeforderte Operation nicht ausgeführt werden kann. |
Dieser Fehlerfall alle EFA-Dienste. Jeder Dienst muss vor Ausführung einer Operation sicherstellen, dass der zugehörige Audit Trail Eintrag geschrieben werden kann. |
Verfügbarkeit von EFA-Teilnehmern und EFA-Daten | Fault: Unknown Service Provider Ein EFA-Dienst kann nicht lokalisiert werden bzw. die verfügbaren Informationen erlauben es nicht, eine Kommunikation mit diesem Dienst aufzubauen. |
Dieser Fehlerfall betrifft vorrangig den EFA-Client, der für den Aufbau sicherer Kommunikationskanäle zu allen genutzten EFA-Diensten verantwortlich ist. |
Fault: Service Not Available Ein angeforderter EFA-Dienst ist nicht verfügbar. |
Operationsaufruf -und abwicklung
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Feeln.01.02}
In diesem Abschnitt werden Fehlerfälle beschrieben, die durch fehlerhafte Angaben in den Argumenten eines Operationsaufrufs ausgelöst werden. Prinzipiell können diese Fehlerfälle damit bei allen Operationen auftreten, die das angegebene Argument als Eingabe erwarten. Die in der Tabelle angegebene Kurznamen der einzelnen Fehler und Warnungen dienen lediglich der besseren Referenzierbarkeit innerhalb dieses Spezifikationsdokuments und müssen in einem konkreten Binding der EFA-Operationen auf die im entsprechenden Standard definierte Fehlermeldungen und -codes abgebildet werden.
Argument | Fehler bzw. Warnung | betroffene Operationen |
---|---|---|
patientID | Fault: Invalid PID Die bei einem Operationsaufruf angegeben Patienten-ID kann nicht aufgelöst werden. Dieser Fehler tritt auf, wenn der aufrufende Akteur eine Patienten-ID verwendet, die nicht im EFA-Netzwerk bzw. beim EFA-Provider registriert ist. Bei dieser Registrierung ist es nicht erforderlich, dass die Identität der Person des Patienten offengelegt wird; wesentlich ist lediglich, dass für EFA-Teilnehmer eine Möglichkeit besteht, eine Abbildung intern verwendeter IDs auf eine in einem EFA-Netzwerk einheitliche ID herzustellen. Anmerkung: Dieser Fehler kann nicht auftreten, wenn in einem EFA-Netzwerk ein von der EFA vollständig unabhängige Verwaltung von einheitlichen Patienten-IDs realisiert ist und keine über dieses Netzwerk hinausgehende Verknüpfung von Patientendaten stattfindet. In diesem Fall müssen EFA-Anwendungsdienste übermittelte Patienten-IDs als valide akzeptieren. |
createECR |
purpose | Fault: Invalid Purpose Die für eine Fallakte festzusetzende Zweckbindung ist ungültig. Dieser Fehler tritt auf, wenn bei der Anlage einer Fallakte oder im Rahmen einer Änderung einer Einwilligung eine Fallakte mit einem Zweck verknüpft werden soll, der entweder falsch/unvollständig kodiert ist oder undefinierte Festsetzungen (Codes) enthält. |
createECR |
Fault: Prohibited Purpose Die für eine Fallakte festzusetzende Zweckbindung ist unzulässig. Dieser Fehler tritt auf, wenn bei der Anlage einer Fallakte oder im Rahmen einer Änderung einer Einwilligung eine Fallakte mit einem Zweck verknüpft werden soll, der zu grobgranular ist oder vom angesprochenen EFA-Provider explizit nicht unterstützt wird. Ein Beispiel für die letzte Konstellation ist ein EFA-Provider, der sich auf Fallakten zu bestimmten DMPs spezialisiert hat und keine Anlage von Fallakten zu anderen Diagnosen erlaubt. | ||
consentInfo | Fault: Unidentifiable Participant Eine oder mehrere der im consentInfo benannten zu berechtigenden Personen bzw. Organisationen
|
createECR |
Fault: Prohibited Role-Assignment Eine im consentInfo beschriebene Rollenbelegung ist nach den Regularien des EFA-Netzwerks nicht zulässig. Beispielsweise kann ein EFA-Verbund festlegen, dass nur Personen mit einer entsprechenden Schulung die Rolle des Fallaktenmanager ausfüllen dürfen. | ||
Fault: Inconsistent PID Bei bestehender Akte: Der im consentInfo benannte Patient kann nicht auf die an die bestehende Akten gebundene patientID abgebildet werden. | ||
Fault: Invalid Lifespan Die angegebene Gültigkeitdauer der Einwilligung (und damit der daran hängenden Akte) ist nicht gültig, da sie im EFA-Netzwerk definierte Vorgaben über- oder unterschreitet. | ||
Fault: Inconsistent Consent Im consentInfo enthaltene Angaben sind inkonsistent oder gar widersprüchlich zu anderen Argumenten des Operationsaufrufs. | ||
Fault: Prohibited Merge Der Eingabe-Parameter consentInfo benennt einen Zweck, für den der EFA-Provider bereits eine Fallakte führt. Die EFA-Berechtigungsregeln der beiden Fallakten erlauben das Zusammenführen allerdings nicht. | ||
Warning: Merge Der Eingabe-Parameter consentInfo benennt einen Zweck, für den der EFA-Provider bereits eine Fallakte führt. Die Fallakten wurden zusammengeführt. Der EFA-Teilnehmer sollte verifizieren, dass die übernommenen Dokumente dem neuen Zweck dienen. Veraltete Dokumente sollten invalidiert werden. | ||
partitionID | Fault: Invalid Partition Die angegeben Partitions-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf der übergeordneten Akte auszuführen. |
listData |
ecrRef | Fault: Invalid ECR Die angegeben EFA-Referenz kann nicht aufgelöst werden bzw. der Aufrufer hat keine (ausreichenden) Berechtigungen, die angeforderte Operation auf der Akte auszuführen. |
createPartition |
document |
Warning: Integrity Violation Bei einem mit einem Integritäts- und/oder Authentizitätsschutz versehenen Dokument wurde eine mögliche Verletzung der Integritär/Authentizität festgestellt. Das betroffene Dokument wurde nicht in die Akte eingestellt, der Operationsaufruf aber ansonsten bearbeitet. |
createECR |
Warning: Security Check Failure Ein in die Akte einzustellendes Dokument hat die Sicherheitsfilter des Repository nicht passiert (z.B. da angegebenes Format und erkanntes Format nicht übereinstimmen). Das betroffene Dokument wurde nicht in die Akte eingestellt, der Operationsaufruf aber ansonsten bearbeitet. | ||
docMetadata | Warning: Invalid Metadata Die zu einem Dokument bereitgestellten Metadaten sind unvollständig, falsch kodiert oder nicht konsistent. Das betroffene Dokument wurde nicht in die Akte eingestellt, der Operationsaufruf aber ansonsten bearbeitet. |
provideData |
Warning: Prohibited Document Type Dokumente mit den in den Metadaten beschriebenen Eigenschaften dürfen nicht in die benannte Fallakte eingestellt werden. Die betroffenen Dokumente wurden nicht in die Akte eingestellt, der Operationsaufruf aber ansonsten bearbeitet. Dieser Fehler kann seine Ursache sowohl in Vorgaben des EFA-Providers (z.B. Festlegung einer maximalen Dateigröße) als auch des EFA-Netzwerks haben (z.B. Ausschluss von Dokumenten mit sehr hohem Schutzbedarf oder Einschränkung bestimmter Aktenausprägungen auf vorab definierte Dokumenttypen). | ||
docRelationship | Warning: Invalid Association Target Die zu einem Dokument benannten Beziehungen referenzieren auf Dokument-IDs, die nicht auflösbar sind bzw. Dokumente in einer anderen Fallakte referenzieren. Die betroffenen Dokumentenbeziehungen wurden verworfen, das Dokument aber in die Akte eingestellt. |
provideData |
Warning: Consent Association Corrected Wenn bei der Registrierung einer Einwilligung (bzw. der Rücknahme einer Einwilligung) neben einem die Einwilligung beschreibenden consentInfo-Objekt auch ein (gescanntes) Dokument (consentDoc) eingestellt wird, muss das Dokument in einer "Append"-Beziehung zu dem consentInfo-Dokument stehen. Falls diese Beziehung nicht oder falsch gesetzt ist, wird sie vom EFA-Provider gesetzt bzw. korrigiert. In diesem Fall wird eine Warnung ausgegeben, dass die Dokumentenbeziehungen durch den Provider verändert wurden. |
createPartition |
Referenzen und Querverweise |
Logical Perspective = Computational Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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".
Technische Akteure der EFA
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eist.01}
Die logische Anwendungsebene einer Fallakten-Infrastruktur besteht im einfachsten Fall aus fünf Klassen von Akteuren:
- Ein EFA-Kontext-Manager (eCR Context Manager) baut den Sicherheitskontext zur Nutzung von Fallakten auf und verwaltet die darin bereit gestellten Sicherheitsnachweise des EFA-Teilnehmers.
- Ein EFA-Ressource-Manager(eCR Resource Manager) stellt ein Verzeichnis zur Verwaltung von Fallakten und EFA-Partitionen bereit. Mit dem selben Patienten und dem selben Zweck verbundene Partitionen bilden eine Fallakte.
- Ein EFA-Daten-Register (eCR Document Registry) stellt ein Verzeichnis zur Verwaltung von Dokumenten bereit. In einem regionalen Gesundheitsnetz kann ein einzelner EFA-Provider das EFA-Register für das gesamte Netzwerk anbieten.
- Ein EFA-Speichersystem (eCR Document Repository) hält die registrierten Dokumente vor und stellt sie für berechtigte Nutzer zum Abruf bereit. Jeder EFA-Provider kann ein eigenes EFA-Speichersystem bereitstellen und an das EFA-Register anbinden.
- Ein EFA-Teilnehmersystem (eCR Consumer) bildet eine Nutzerschnittstelle ab, über die ein Arzt Behandlungsdaten anderer Ärzte aus an einem EFA-Daten-Register registrierten Speichersystemen abrufen kann bzw. in einem Speichersystem verwaltete Behandlungsdaten am EFA-Register registrieren kann.
Hinzu kommen zwei Klassen von Sicherheitstoken-Diensten, die jeweils Sicherheitsnachweise zum Aufbau eines zwischen EFA-Teilnehmersystem und EFA-Fachdienst (Register bzw. Speichersystem) geteilten Sicherheitskontextes bereit stellen:
- Ein Identity Provider stellt einen von allen anderen EFA-Akteuren als vertrauenswürdig akzeptierten Identitätsnachweis für authentifizierte Nutzer aus. Der Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z. B. mittels Passwort, HBA oder SMC-B).
- Ein Policy Provider liefert die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) auf einer spezifischen Fallakte.
Der Aufruf der Sicherheitstoken-Dienste und die Verwaltung der von diesen abgerufenen Sicherheitsnachweise wird gegenüber dem EFA-Teilnehmersystem über den EFA-Kontext-Manager gekapselt.
Umsetzungsoptionen für EFA-Speichersysteme (Informativ)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eist.02}
Die EFA nutzt zur Umsetzung der einzelnen Systemkomponenten das IHE Profil "Cross-Enterprise Document Sharing (XDS)", das in Bezug auf die Verteilung von Datenspeichern vielfältige Umsetzungsoptionen erlaubt. Die EFAv2.0 Spezifikation gibt hier kein festes Deployment von Datenspeichern vor, sondern erlaubt alle in IHE XDS vorgesehenen Umsetzungen der Datenspeicher, sofern
- die Regeln für den Aufbau einer [[cdaefa:EFA_Provider|Affinity Domain] nicht verletzt werden und
- der Datenspeicher nur Dokumente an dem EFA-Daten-Register registriert, die den Vorgaben einer von diesem Register unterstützten Versorgungsdomäne entsprechen.
Die nachfolgende Grafik skizziert vier mögliche Szenarien, wie medizinische Dokumente in einer EFA Affinity Domain verwaltet werden können.
- EFA-Teilnehmer mit eigenem XDS DocumentRepository (links außen)
- Ein EFA-Teilnehmer kann ein eigenes XDS DocumentRepository betreiben, in dem er - z.B. zur einrichtungsinternen Integration der Daten aus vorhandenen Subsystemen - EFA-relevate Dokumente ablegt. Diese werden über die Mechansimen der EFA bei einem EFA-Provider registriert. Alle Suchanfragen laufen über das Register beim EFA-Provider, der Abruf der Dokumenten erfolgt jedoch direkt aus dem XDS DocumentRepository des Teilnehmers. In diesem Szenario verbleiben die medizinischen Daten in der Einrichtung in der sie erstellt wurden. Eine Mehrfachnutzung der Daten für interne Behandlungsabläufe und einrichtungsübergreifende Kooperationen ist möglich, sofern dieses über den Behandlungsvertrag (interne Nutzung) und die Einwilligung des Patienten zur EFA-Nutzung abgedeckt ist.
- EFA-Teilnehmer mit EFA-Facade vor internem Speichersystem (mitte links)
- Eine interne Vorhaltung der EFA-relevanten Dokumente ist auch ohne dediziertes XDS DocumentRepository möglich, sofern das datenhaltende System die Schnittstelle des EFA Datenspeichers bereit stellt. Hiermit kann eine redundante Datenhaltung vollständig vermieden werden. Die Abläufe im Zusammenspiel mit dem EFA-Daten-Register und anderen EFA-Teilnehmern sind analog zu dem oben skizzierten Szenario umzusetzen.
- EFA-Teilnehmer ohne eigenes EFA-Speichersystem
- Arztpraxen und Krankenhäuser können alternativ auch ein vom EFA-Provider bereitzustellendes Speichersystem nutzen und ihre EFA-relevanten Daten über von der EFA bereitgestellte Mechanismen in dieses einspielen. Die Registrierung der Daten am EFA-Daten-Register wird in diesem Fall vom Speichersystem übernommen. Bei diesem Szenario liegt eine Auftragsdatenverarbeitung durch den EFA-Provider vor, die entsprechend über eine Zustimmung des Patienten autorisiert werden muss.
Ein Szenario, in dem ein Krankenhaus als EFA-Provider gleichzeitig auch EFA-Teilnehmer ist, kann gemäß der auf der linken Seite der Abbildung dargestellten Umsetzungsoptionen realisiert werden:
- ein ggf. schon bestehendes XDS DocumentRepository wird an das EFA-Daten-Register als EFA-Speichersystem angebunden. Dieses Speichersystem zur Vorhaltung der eigenen Daten muss von dem Speichersystem für die Vorhaltung externer Daten (Optionen auf der rechten Seite der Abbildung) getrennt sein, da für die Umsetzung der Auftragsdatenverarbeitung zur Speicherung externer Daten andere Regularien gelten, die ggf. auch andere technische Sicherheitsmechanismen erfordern.
- IHE XDS erlaubt die Integration von Quellsystem und Datenspeicher (Integrated Document Source and Document Repository). Über diesen Mechanismus kann z.B. ein EFA-Daten bereitstellendes IT-System des Krankenhauses direkt an das EFA-Daten-Register angebunden werden und seine EFA-relevanten Daten an diesem registrieren ohne dass dabei die Daten selbst aus dem Quellsystem ausgespielt werden müssten. Für den Abruf der Daten muss das Quellsystem jedoch logisch als EFA-Datenspiecher agieren können, d.h. die in der EFA-Spezifikation definierten Schnittstellen und Sicherheitsmaßnahmen eines EFA-Datenspeichers implementieren.
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
EFA Context Manager
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.01}
Die EFA nutzt einen vom Client aufgebauten und mit dem EFA-Provider geteilten Sicherheitskontext. Wesentlicher Bestandteil dieses Sicherheitskontextes sind authentische Nachweise zur Identität des EFA-Teilnehmern, die auf Seiten des EFA-Providers zur Berechtigungsprüfung benötigt werden.
Der erste Schritt jeder EFA-Nutzung ist der Aufbau eines initialen Sicherheitskontextes, da dieser bei jedem Aufruf eines EFA-Dienstes mitgegeben werden muss. Der initiale Sicherheitskontext kann durch Nutzung verschiedener Sicherheitsdienste ausgeweitet werden. Die entsprechenden Anforderungen werden vom EFA-Provider formuliert, der für jeden EFA-Dienst angeben kann, welche Sicherheitsnachweise der zum Aufruf des Dienstes erforderliche Sicherheitskontext enthalten muss.
Auf Seiten des EFA-Clients kapselt der (logische) Dienst des EFA ContextManagers den Aufbau und die Verwaltung des Sicherheitskontextes. Alle clientseitigen Aufrufe von EFA-Sicherheitsdiensten werden durch den EFA ContextManager ausgeführt, der die von diesen Diensten für den EFA-Teilnehmer ausgestellten Sicherheitsnachweise in den bestehenden Sicherheitskontext integriert.
Authentisierung eines EFA-Teilnehmers
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.02}
Die EFA macht keine Vorgaben, wie eine Authentifizierung eines EFA-Teilnehmers erfolgen muss. Verpflichtend ist in Bezug auf das Authentifizierungsverfahren und die eingesetzten Objekte und Mechanismen lediglich die Einhaltung der geltenden regionalen und nationalen Vorgaben zur Stärke der Authentifizierung sowie deren technischer und organisatorischer Absicherung.
Wesentlich für die über den ContextManager gesteuerte Authentisierung ist lediglich, dass in deren Ergebnis eine authentischer Identitätsnachweis des EFA-Teilnehmers vorliegt. Dieser Nachweis muss einem vorgegebenen Format genügen und bestimmte Identitätsinformationen kodieren, so dass jeder EFA-Dienst dieses Nachweis verarbeiten und semantisch gleichartig interpretieren kann.
Optionen zur Authentisierung von EFA-Teilnehmern (nicht-normativ)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.02.01}
Die Identifizierung und Authentifizierung von EFA-Teilnehmern gegenüber den EFA-Diensten erfolgt in zwei Stufen; an einem initialen Authentisierungspunkt erfolgt die Prüfung des Authentizitätsnachweises und die Erstellung eines Identitätsnachweises, in dem die Identität des EFA-Teilnehmers über Attribute (z. B. Rollen und Organisationszugehörigkeiten) beschrieben ist. Jeder EFA-Dienst umfasst einen föderierten Authentisierungspunkt, an dem die Authentizität von Identitätsnachweisen verifiziert werden kann. Dieses zweistufige Verfahren erlaubt die Dezentralisierung der initialen Authentifizierung und die Einbringung von beim Leistungerbringer verwalteten Nutzerattributen (z. B. Funktionsrollen). Darüber hinaus bleiben so die technischen Besonderheiten verschiedener und potenziell parallel genutzter Authentifizierungsmechanismen (HBA, Mitarbeiterausweise einer Klinik, Username/Passwort, etc.) vor den EFA-Diensten verborgen.
Die nachfolgende Grafik stellt verschiedene Optionen zur Umsetzung eines initialen Authentisierungspunkts dar. Wesentlich hierbei ist, dass der Aufruf des initialen Authentisierungspunkts logisch über den ContextManager gekapselt wird, d.h. client-seitige Funktionalitäten der EFA-Nutzung und die beim EFA-Provider angesiedelten EFA-Dienste von konkreten Umsetzungen der initialen Authentisierung unabhängig sind. Einen Sonderfall stellt die Nutzung einer Guarantor Assertion dar, die dezentral ausgestellt wird und anschließend an einem Identity Provider in einen für den EFA-Dienste verarbeitbaren Identitätsnachweis überführt wird. Hierbei prüft der Identity Provider die Authentizität der Guarantor Assertion (föderierter Authentisierungspunkt) und stellt mit den Angaben aus der Guarantor Assertion und ggf. weiteren Informationen eines Verzeichnisdienstes einen neuen, für den EFA-Dienst validierbaren Nachweis aus (initialer Authentisierungspunkt aus Sicht des EFA-Dienstes).
Operation: OpenContext
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.02.02}
Method | openContext(credential Object) : ContextIdentifer | |
---|---|---|
Description | This method establishes a security context for a user that wants to get access to an eCR peer. The security context holds the Identity Assertion [SAML2.0core] necessary for invoking service operations from business services. 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 | context | The identifier used to refer to the security context when issuing EFA activities within that context |
Preconditions |
| |
Sequence (Main success scenario) |
| |
Exception | AuthenticationFailedException | Authentication failed due to wrong credentials. |
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
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 Policy Provider
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocye.01}
Der EFA Policy Provider ist für die Verwaltung der Berechtigungen in Form von Policies in einem Policy Repository zuständig. Berechtigungen sind an einen bestimmten Zweck gebunden und steuern den Zugriff von EFA-Teilnehmern auf eine Fallakte.
requestPolicy
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocye.01.01}
Zur Umsetzung des Policy Push Verfahrens muss der EFA Policy Provider eine Schnittstelle zum Abruf der für einen Nutzerkontext und eine zu verarbeitende Fallakte gültigen Policy bereitstellen.
Operation | requestPolicy | ||
---|---|---|---|
Funktionalität | Stellt eine für einen angegebenen Nutzer zum Zugriff auf eine benannte Fallakte gültige Policy in Form eines Berechtigungsregelwerks bereit. | ||
Eingabe | context | Nutzerkontext, der eine subjectIdentity zur Identifizierung des Nutzers enthält, dessen Berechtigungen auf der angegebenen Fallakte abgerufen werden sollen. | |
ecrRef | Eindeutige Identifizierung der Fallakte, für die Berechtigungen abgefragt werden sollen. | ||
consentInfo (optional) | Informationen zu einer vom Patienten gegebenen Einwilligung. Dieses Argument wird für Ad-Hoc-Berechtigungen und Additive Berechtigungen benötigt und näher ausspezifiziert, wenn die entsprechenden Verfahren im Detail definiert sind. | ||
Rückgabe | subjectAccessPolicy | Für den aktuellen Kontext und die angegebene Fallakte gültigen Berechtigungsregeln. | |
Vorbedingungen |
| ||
Ablaufsequenz |
| ||
Mögliche Fehler | MissingAttributes | Für die Auswahl der zu verwendenden Policy erforderliche Angaben zum EFA-Teilnehmer fehlen. |
issueAccessToken
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocye.01.02}
Operation | issueAccessToken | |
---|---|---|
Funktionalität | Diese Operation stellt ein Berechtigungstoken für eine Fallakte aus. Zu dem Berechtigungstoken gehört eine Redeem-Policy, die beim Policy Provider registriert wird. Die EFA-Berechtigungsregel der Fallakte wird durch diese Operation nicht verändert. | |
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, für die ein Berechtigungstoken ausgestellt werden soll. | |
Rückgabe | accessToken | Ein Berechtigungstoken, das den Leistungserbringer, der es einreicht, zum Zugriff auf die Fallakte berechtigt. |
Vorbedingungen | ||
Ablauf |
| |
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden:
|
redeemAccessToken
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eocye.01.03}
Operation | redeemAccessPolicy | ||
---|---|---|---|
Funktionalität | Diese Operation tauscht ein Berechtigungstoken gegen eine Subject Access Policy. Wenn das Berechtigungstoken nicht bei diesem EFA-Provider ausgestellt wurde, dann wird der Operationsaufruf an die ausstellende EFA-Provider-Domäne weitergereicht. | ||
Eingabe | context | Nutzerkontext, der eine subjectIdentity zur Identifizierung des Nutzers enthält, der das Berechtigungstoken einlösen will. | |
patientID (conditional) | Die ID des Patienten in der Affinity Domain des Arztes, der das Token einreicht. Das EFA-Teilnehmersystem muss diesen Parameter verwenden. Der Policy-Provider darf diesen Parameter beim Weiterleiten nicht verwenden. | ||
accessToken | Über die Operation issueAccessToken ausgestelltes Berechtigungstoken, mit dem der Einreicher als Teilnehmer an der im Token kodierten Fallakte registriert werden soll. | ||
Rückgabe | subjectAccessPolicy | Der vertrauenswürdige Nachweis dafür, dass das Berechtigungstoken eingelöst wurde. | |
Vorbedingungen |
| ||
Ablauf |
Wenn dieser EFA-Provider nicht der ausstellende EFA-Provider ist:
Wenn dieser EFA-Provider der ausstellende EFA-Provider ist:
| ||
Fehler und Warnungen |
Folgende Fehler müssen erkannt und rückgemeldet werden:
|
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 - Enterprise Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
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".
ECR Namespace Prefixes
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Esams.01}
XML namespace prefixes are used in this specification to stand for their respective namespaces as follows:
Implementable Perspective - Information Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 CDA für die elektronische Fallakte.
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
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 |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
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 Audit Trail Binding for XDS-based Transactions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EAiai.01} For transactions implemented by the EFA Resource Manager, EFA Document Registry and EFA Document Repository an Audit Trail shall be written as defined for the underlying XDS transactions. Extensions and exceptions to this rule are defined in the following sections.
Event Identification
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EAiai.01.01} Each audit trail entry written as an obligation to the processing of an EFA transaction shall contain an eventID element as specified for the underlying IHE XDS transaction. In addition each entry shall contain an eventTypeCode element for the logical EFA operation that is implemented through the XDS transaction. The following table lists the respective codes and display names.
EFA Service | eventTypeCode.
codeSystemName |
eventTypeCode.
code |
eventTypeCode.
displayName |
---|---|---|---|
createECR | EFAv2 Transaction | EFA-01 | createECR |
createPartition | EFAv2 Transaction | EFA-02 | createPartition |
closeECR | EFAv2 Transaction | EFA-03 | closeECR |
listPartitions | EFAv2 Transaction | EFA-04 | listPartitions |
registerConsent | EFAv2 Transaction | EFA-05 | registerConsent |
issueAccessToken | EFAv2 Transaction | EFA-06 | issueAccessToken |
redeemAccessToken | EFAv2 Transaction | EFA-07 | redeemAccessToken |
registerData | EFAv2 Transaction | EFA-08 | registerData |
listPartitionContent | EFAv2 Transaction | EFA-09 | listPartitionContent |
ProvideData | EFAv2 Transaction | EFA-10 | provideData |
retrieveData | EFAv2 Transaction | EFA-11 | retrieveData |
Encoding of the User Identifier
The HP identifier entry MUST be taken from the subject field of the identity assertion that is transmitted together with a request. For conformance with IHE XUA++ the following encoding MUST be used:
SPProvidedID<saml:SubjectNameID@saml:Issuer>
The SPProvidedID is needed because there are situations where identity federation is in place. The SPProvidedID is a name identifier established by a service provider or affiliation of providers for the entity in the NameID different from the primary name identifier given in the content of the element.
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 Error Codes and Warning Codes
Code | Message | Severity |
---|---|---|
1102 | No Data | Error |
2201 | Processing deferred | Warning |
2202 | Partition linked with existing ECR | Warning |
4107 | PDF required | Error |
4109 | Policy Violation | Error |
4111 | Unknown HP Identity | Error |
4701 | No Consent | Error |
4702 | Weak Authentication | Error |
4703 | Invalid Subject | Error |
4704 | No Signature | Error |
Implementable Perspective - Computational Dimension
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 CDA für die elektronische Fallakte.
|
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 |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 Resource Manager XDR/XDS Binding
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.01}
Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Resource Manager actors and operations as follows:
Role | EFA Resource Manager Service | IHE XDS | Binding |
---|---|---|---|
Actor | EFA Consumer |
|
- |
Actor | EFA Resource Manager |
|
- |
Transaction | createECR | Provide and Register Document Set ITI-41 | createECR |
Transaction | createPartition | Provide and Register Document Set ITI-41 | createPartition |
Transaction | closeECR | Provide and Register Document Set ITI-41 | closeECR |
Transaction | listPartitions | Registry Stored Query ITI-18 | listPartitions |
Transaction | registerConsent | Provide and Register Document Set ITI-41 | registerConsent |
Transaction | listRecordLocations | Patient Location Query ITI-56 | |
Transaction | registerRecordLocation | Patient Identity Feed HL7 V3 ITI-44 | |
Transaction | notifyOfConsent | Document Metadata Notify ITI-53 |
EFA XDS/XDR Binding: createECR
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02}
The initialization of a new ECR is performed by creating a new XDS folder for the patient. The folder is classified by the ECR purpose codes and as such implicitly linked to all other folders (ECR: partitions) which are assigned to the same purpose.
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA createECR operation and to align with the EFA security framework:
- A new folder shall be created and purpose codes shall be provided for the newly created folder as codeList.
- A consent information document containing the list of authorized subjects shall be provided through BPPC. A scanned consent document may be additionaly provided.
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.01}
The createECR request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
The following table shows how the createECR Service Functional Model is mapped onto the ITI-41 transaction:
createECR | ITI-41 | Constraints | |
---|---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook | |
ecrInfo | patientID | XDS Folder Attribute: patientID | The same patient identifier SHALL be used throughout all metadata |
purpose | XDS Folder Attribute: codeList | see EFA XDS Folder Metadata Binding for details | |
ecrStatus | XDS Folder Attribute: availabilityStatus | SHALL be "approved". | |
consentInfo | XDS Document | Definition of validity and authorized participants (see Interaction Pattern "Creation of a new ECR") is covered within the consentInfo object. | |
consentDoc (optional) | XDS Document | If this argument is given, a scanned document SHALL be provided acc. to the XDS SD Integration Profile. |
Following this, implementations SHALL satisfy
- the Common constraints on ITI-41,
- the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints | createECR binding |
---|---|
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents | R |
One XDS Document is a consentInfo, which revokes all active consents | - |
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) | - |
The XDS Folder is not registered (uniqueID) | R |
The XDSFolder is registered (uniqueID) | - |
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.02}
The XDS Document Repository SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
The XDS Document Repository MUST verify that the requesting service user has sufficient rights to setup a new ECR at this EFA Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the EFA Provider SHALL verify the completeness and consistency of the provided consentInfo document. It SHALL verify that all named ECR participants are either registered with the provider or identifiable through a shared healthcare provider directory.
The EFA Provider SHALL check if an ECR for the given patient and purpose already has been registered with this provider.
If no ECR with the given purpose exists for the given patient, the EFA Provider SHALL
- setup a folder as specified in the request message
- translate the provided consentInfo document into an access control policy which can be automatically enforced for each request to the newly setup ECR
- store the provided documents within the XDS Document Repository
- forward the metadata of the received documents to the XDS Document Registry for registration
If an ECR with the given purpose already exists for the given patient, the EFA Provider SHALL
- verify that EFA participant is allowed to modify the consent of the ECR. If this access is denied an error status SHALL be returned.
- setup a folder as specified in the request message
- extract the identified ECR participants from the provided consentInfo document and add them as authorized users to the existing access control policy.
- store the provided documents within the XDS Document Repository
- forward the metadata of the received documents to the XDS Document Registry for registration
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager MUST respond with the respective error status.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.03}
If the XDS Document Registry is able to decode the received message and to properly initialize the new ECR and its initial partition it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
If the XDS Document Registry wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”:
<rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
<rs:RegistryErrorList>
<rs:RegistryError
severity=”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”
errorCode=”....”
codeContext=”Partition linked with existing ECR”
location="" />
</rs:RegistryErrorList>
</rs:RegistryResponse>
The following warning messages and codes are defined:
Condition and Severity | Message | Code | Action to be taken |
---|---|---|---|
Request was received but not processed; e.g. because a manual intervention by the EFA Provider is required to initalize a new ECR | Processing deferred | 2201 | None |
An ECR with the given purpose already exists for the patient. Instead of initalizing a new ECR a partition has been added to the existing ECR. | Partition linked with existing ECR | 2202 | None |
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.02.04}
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
The instantiation of an ECR is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | - | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
The EFA Provider only accepts consentInfo documents if they are digitally signed by an HP. (ERROR) | OID of the consentInfo document | No Signature | 4704 | If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP. |
The requestor has not sufficient permission to perform the requested operation (ERROR) | - | No Consent | 4701 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent. |
An ECR of the given purpose already exists for the patient. The requestor does not have sufficient permissions to create a new partiton and to register new participants (ERROR) | - | No Consent | 4701 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent for the existing ECR. |
The EFA Provider is unable to identify one or more of the participants that are listed in the consentInfo document (ERROR) | OID of the participant that cannot be identified | Unknown HP Identity | 4111 | The request MUST NOT be processed by the service provider. The requestor SHOULD first resolve the participants' identities into identifiers which are resolvable to the EFA Provider. |
Security Considerations
EFA XDS/XDR Binding: createPartition
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03}
The linkage of a new partition to an existing ECR is performed by creating a new XDS folder for the patient. The folder is classified by the ECR purpose codes of the existing ECR and as such implicitly linked to all other folders (ECR: partitions) which are already assigned to the same ECR.
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA createPartition operation and to align with the EFA security framework:
- A new folder shall be created and purpose codes shall be provided for the newly created folder as codeList
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.01}
The createPartition request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
The following table shows how the createPartition SFM is mapped onto the ITI-41 transaction:
createPartition | ITI-41 | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
ecrRef |
XDS Folder Attribute: patientID |
The codeList shall contain all purpose codes as assigned to the existing ECR the new partition is to be linked with |
partitionInfo | XDS Folder Attribute: title XDS Folder Attribute: uniqueID |
Further elements of the partitionInfo structure MAY be set by the ECR provider. |
initialDoc | XDS Document | At least a single document shall be provided when a new partition is initialized. |
Following this, implementations SHALL satisfy
- the Common constraints on ITI-41,
- the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints | createPartition binding |
---|---|
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents | - |
One XDS Document is a consentInfo, which revokes all active consents | - |
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) | R |
The XDS Folder is not registered (uniqueID) | R |
The XDSFolder is registered (uniqueID) | - |
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.02}
The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
The provider of the XDS Document Repository provider MUST verify that the requesting service user has sufficient rights to setup a new partition at this ECR Provider ant to link this partiton with an existing ECR.
In processing of this request the ECR Provider SHALL
- assess the access control policy of the ECR with the "create partition" operation
- setup a folder as specified in the request message
- store the provided documents within the XDR Document Repository
- forward the metadata of the received documents to the XDS Document Registry for registration
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Repository MUST respond with the respective error status.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.03}
If the EFA Document Registry Service provider is able to decode the received message and to properly initialize the new partition it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.03.04}
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
If the partiton could not be created or if none of the provided documents was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If the partition was successfully initialized and at least one document was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”. A failure location MUST be provided if the error does not apply to all provided documents. It MUST NOT be given if the error applies to all provided documents.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | - | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
An ECR of the given purpose does not exist for the patient (ERROR) | - | Policy Violation | 4109 | The request MUST NOT be processed by the service provider. |
The ECR provider only accepts medical documents if they are digitally signed by an HP. (ERROR) | OID of the consentInfo document | No Signature | 4704 | If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP. |
The requestor has not sufficient permission to perform the requested operation (ERROR) | - | No Consent | 4701 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent. |
For data of the given kind the EFA provider only accepts PDF coded documents (ERROR) | OID of the document | PDF required | 4107 | The provided document MUST NOT be processed by the EFA provider. The EFA Client MUST re-transmit the document in PDF format. |
A document of the provided kind does not comply with the EFA policy or the patient consent (ERROR) | OID of the document | No Consent | 4701 | The provided document MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent. |
Security Considerations
EFA XDS/XDR Binding: closeECR
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04}
The explicit shutdown of an ECR is performed by placing a consentInfo document that invalidates all previously given permissions into one of the ECR's partitions (folders). This may either be a newly created folder of an existing folder that is classified by the ECR purpose codes and as such implicitly represents the ECR that is to be closed.
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA closeECR operation and to align with the EFA security framework:
- A new folder may be created. Purpose codes shall be provided for the newly created folder as codeList
- A consent information document that invalidates all previously given permissions shall be provided through BPPC. A scanned consent revocation document may be additionaly provided.
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.01}
The closeECR request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
The following table shows how the closeECR SFM is mapped onto the ITI-41 transaction:
closeECR | ITI-41 | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
ecrRef | XDS Folder Attribute: patientID XDS Folder Attribute: codeList |
The codeList shall contain all purpose codes as assigned to the ECR that is to be closed |
consentInfo | XDS Document | |
consentDoc (optional) | XDS Document | Scaned documents SHALL be provided acc. to the XDS SD Integration Profile. |
Following this, implementations SHALL satisfy
- the Common constraints on ITI-41,
- the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints | closeECR binding |
---|---|
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents | - |
One XDS Document is a consentInfo, which revokes all active consents | R |
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) | R |
The XDS Folder is not registered (uniqueID) | O |
The XDSFolder is registered (uniqueID) | O |
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.02}
The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
The provider of the XDS Document Repository MUST verify that the requesting service user has sufficient rights to close an ECR at this ECR Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the ECR provider SHALL verify the completeness and consistency of the provided consentInfo document.
In processing this request the ECR Provider SHALL
- assess the access control policy of that ECR with the "modify consent" operation. If this access is denied an error status SHALL be returned.
- setup a folder as specified in the request message
- store the provided documents within the XDR Document Repository
- forward the metadata of the received documents to the XDS Document Registry for registration
- change the status of the ECR and all its partitions (folders) to "grace"
- Adapt all permissions to the new status of the ECR
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager Service provider MUST respond with the respective error status.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.03}
If the EFA Document Registry Service provider is able to decode the received message and to properly change the status of the ECR and its partitions it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”.
The following warning messages and codes are defined:
Condition and Severity | Message | Code | Action to be taken |
---|---|---|---|
Request was received but not processed; e.g. because a manual intervention by the ECR provider is required to close an ECR | Processing deferred | 2201 | None |
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.04.04}
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
The shutdown of an ECR is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | - | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
The ECR provider only accepts consentInfo documents if they are digitally signed by an HP. (ERROR) | OID of the consentInfo document | No Signature | 4704 | If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP. |
The requestor has not sufficient permission to perform the requested operation (ERROR) | - | No Consent | 4701 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent. |
An ECR of the given purpose does not exist for the patient (ERROR) | - | Policy Violation | 4109 | The request MUST NOT be processed by the service provider. |
Security Considerations
EFA XDS Binding: listPartitions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05}
ECR partitions are bound as XDS folders. Therefore listing partitions corresponds to listing accessible folders which
- are assigned to a given patient, and
- are ECR-classified, and
- are classified with the given purpose.
This EFA binding introduces the following extensions and restrictions on the IHE XDS actor and transaction definitions in order to properly cover the EFA listPartitions operation and to align with the EFA security framework:
- The query is restricted to folder metadata and does not return any data contained within that folders.
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.01}
The listPartitions request message implements the FindFolder flavor of the IHE Registry Stored Query transaction (ITI-18) request message as defined in [IHE ITI TF-2b#3.18.4.1.2.3.7.3].
The following table shows how the listPartitions SFM is mapped onto the ITI-18 transaction's query arguments:
listPartitions | ITI-18 | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
patientID | $XDSFolderPatientId | The patient ID used must be resolvable by the ECR Provider. |
purpose | $XDSFolderCodeList | The codeList MUST contain the ECR-Folder classification code (see EFA XDS Folder Metadata Binding for the respective code). The codeList MUST contain exactly one purpose code, which restricts the query to the partitons of a specific ECR. With regard to the parameter $XDSFolderCodeList solely the AND-semantics (see IHE-ITI-TF2a#3.18.4.1.2.3.5) MUST be used. |
In addition the following constrains must be considered:
- The $XDSFolderLastUpdateTimeFrom and/or $XDSFolderLastUpdateTimeTo query arguments MAY be used. If given, they MUST be considered by the Document Registry.
- The $XDSFolderStatus query arguent SHALL be set to "Approved".
Example
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.01.01}
<query:AdhocQueryRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0 ../schemas/query.xsd"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
<query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
<rim:AdhocQuery id="urn:uuid:958f3006-baad-4929-a4de-ff1114824431">
<rim:Slot name="$XDSFolderPatientId">
<rim:ValueList>
<rim:Value>'90378912821^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="$XDSFolderStatus">
<rim:ValueList>
<rim:Value>'urn:oasis:names:tc:ebxml-regrep:StatusType:Approved'</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="$XDSFolderCodeList">
<rim:ValueList>
<rim:Value>'ECR^^^IHE-D-Cookbook-FolderClassCode'</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="$XDSFolderCodeList">
<rim:ValueList>
<rim:Value>'K70.0^^^1.2.276.0.76.5.311'</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:AdhocQuery>
</query:AdhocQueryRequest>
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.02}
The XDS Document Registry provider SHALL respond to a Registry Stored Query request message with the Registry Stored Query response message containing a success indicator and listing XDS metadata of all folders that match the given query. The provider of the XDS Document Registry provider MUST verify that the requesting service user has sufficient rights to access the discovered XDS folders.
In processing of this request the ECR Provider SHALL
- assess the access control policy of all folders assigned to the given patient
- discover all folders that match the query and the policy
- respond to the requestor with the metadata of the discovered folders. Metadata provided SHALL comply to the EFA XDS Folder Metadata Binding.
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Registry MUST respond with the respective error status.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.03}
If the EFA Document Registry Service provider
- is able to decode and process the received message and
- at least one partition exists for the given patient that is accessible to the requestor
it responds with the registry metadata of the discovered partitions.
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.05.04}
If the XDS Document Registry is unable to successfuly process the query request it MUST respond with a ListResponse message that only contains a <AdhocQueryResponse/RegistryResponse> element.
If no matching folder is discovered or an error occured during the processing of the request, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If partitons of the patient are discovered but may be incomplete (e.g. due to a not-responding peer in an ECR P2P network), the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for ECR:
Condition and Severity | Message | Code | Action to be taken |
---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
The ECR provider is unable to verify the identity and/or the authenticity of the requestor (ERROR) | Invalid Subject | 4703 | The request MUST NOT be processed by the service provider. |
The patient is unknown to the ECR provider. | No Data | 1102 | - |
No partitions are registered for the given patient. | No Data | 1102 | - |
None of the patient's partitions is accessible to the requestor. | No Data | 1102 | - |
Security Considerations
EFA XDS/XDR Binding: registerConsent
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06}
The registration and enforcement of a new patient consent to an existing ECR is performed by placing a consentInfo document that expresses the new consent into one of the ECR's partitions (folders). This may either be a newly created folder of an existing folder that is classified by the ECR purpose codes and as such implicitly represents the ECR that is to be aligned to a new treatment setup.
This EFA binding introduces the following extensions and restrictions on the IHE XDR actor and transaction definitions in order to properly cover the EFA registerConsent operation and to align with the EFA security framework:
- A new folder may be created. Purpose codes shall be provided for the newly created folder as codeList
- A consent information document that expresses the new permissions shall be provided through BPPC. A scanned consent revocation document may be additionaly provided.
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.01}
The registerConsent request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]
The following table shows how the registerConsent SFM is mapped onto the ITI-41 transaction:
registerConsent | ITI-41 | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
ecrRef | XDS Folder Attribute: patientID XDS Folder Attribute: codeList |
The codeList shall contain all purpose codes as assigned to the ECR that is to be aligned |
consentInfo | XDS Document | |
consentDoc (optional) | XDS Document | Scaned documents SHALL be provided acc. to the XDS SD Integration Profile. |
docRelationship | RPLC-Association | The given consentInfo SHALL be associated with the approved consentInfo-DocumentEntry of the case record.
A given consentDoc SHALL be associated with the approved consentDoc-DocumentEntry of the case record. |
Following this, implementations SHALL satisfy
- the Common constraints on ITI-41,
- the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints | registerConsent binding |
---|---|
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents | R |
One XDS Document is a consentInfo, which revokes all active consents | - |
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) | R |
The XDS Folder is not registered (uniqueID) | O |
The XDSFolder is registered (uniqueID) | O |
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.02}
The XDS Document Repository provider SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
The provider of the XDS Document Repository MUST verify that the requesting service user has sufficient rights to register a consent document at this ECR Provider. This includes that the service user is registered with the provider and familiar with using ECRs. Additionaly the ECR provider SHALL verify the completeness and consistency of the provided consentInfo document.
In processing this request the ECR Provider SHALL
- assess the access control policy of that ECR with the "modify consent" operation. If this access is denied an error status SHALL be returned.
- setup a folder as specified in the request message
- store the provided documents within the XDR Document Repository
- forward the metadata of the received documents to the XDS Document Registry for registration
- adapt all permissions that are assigned to the ecrRef to the care team setting as described in the newly provided consent. All previously set permissions must be invalidated.
- if the validity date is changed by the consent: register the new validity with the access control system
- if the purpose is aligned by the new consent: change the eventList codes of all containers that are assigned to the eCR to the new purpose
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Resource Manager Service provider MUST respond with the respective error status.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.03}
If the EFA Document Registry Service provider is able to decode the received message and to properly change the settings of the ECR and its partitions it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”.
The following warning messages and codes are defined:
Condition and Severity | Message | Code | Action to be taken |
---|---|---|---|
Request was received but not processed; e.g. because a manual intervention by the ECR provider is required to change the security settings of an ECR | Processing deferred | 2201 | None |
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.06.04}
If the XDS Document Repository is able to decode the received message but the processing of the request failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
The modification of an ECR's security settings is an All-or-Nothing operation. Therefore in any case of failure the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | - | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
The ECR provider only accepts consentInfo documents if they are digitally signed by an HP. (ERROR) | OID of the consentInfo document | No Signature | 4704 | If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP. |
The requestor has not sufficient permission to perform the requested operation (ERROR) | - | No Consent | 4701 | The request MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent. |
An ECR of the given purpose does not exist for the patient (ERROR) | - | Policy Violation | 4109 | The request MUST NOT be processed by the service provider. |
Security Considerations
EFA IHE-ITI-Binding: listRecordLocations
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.07}
The operation listRecordLocations of the Resource Manager is bound to the transaction Cross Gateway Query [ITI-38] of the XCA profile.
Constraints on the request message
The input of listRecordLocations SHALL be bound to ITI-56 Cross Gateway Query as follows:
listRecordLocations | ITI-38 Request | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
patientID | $XDSFolderPatientId | The patient-ID SHALL be known by Document Recipient. |
purpose | $XDSFolderCodeList | The codeList MUST contain the purpose code, which restricts the query to the partitons of a specific ECR. |
Futhermore, the query parameter $XDSFolderCodeList must contain the EFA-MountPoint classification code.
Response Message (Full Success Scenario)
The output of listRecordLocations SHALL be bound to ITI-38 Cross Gateway Query Response as follows:
listRecordLocations | ITI-38 Response | Constraints |
---|---|---|
MountPoint* | see Binding of MountPoint | The responder SHALL return only XDSFolder-Elements, that have been registered for this ECR with the Mount-Point classification. The responder SHALL return all XDSDocumentEntry-Elements, that are a member of these XDSFolder-Elements. |
Response Message (Failure or Partial Failure Scenario)
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR) | - | Policy Violation | 4109 | The request MUST NOT be processed by the Responding Gateway. |
Security Considerations
The request and response messages SHALL be exchanged using a mutually authenticated channel or message authentication.
As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.
As for message authentication, the SOAP-Body of the request and response messages SHALL be signed or encrypted using X.509 certificates.
EFA IHE-ITI-Binding: registerRecordLocation
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.08}
The operation registerRecordLocation SHALL be bound to the transaction Provide and Register Document Set ITI-41 [IHE ITI TF-2b#3.41] of the XDR profile.
Constraints on the request message
registerRecordLocation | ITI-41 | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
MountPoint.patientID | XDSFolder.patientId | The patientId SHALL be know at the target community. |
MountPoint.purpose | XDSFolder.codeList | The codeList SHALL contain the purpose code. |
MountPoint.sourcePatientID | XDSDocumentEntry.sourcePatientId | The sourcePatientId SHALL be the patientId known at the requesters community. |
MountPoint.communityID | XDSFolder.homeCommunityId | The homeCommunityId SHALL be the requester's ID. |
Furthermore, XDSFolder.codeList SHALL contain the EFA-classification code and the Mount-Point-classification code. The attribute XDSFolder.sourcePatientId SHALL contain the patientId known in the requester's community.
Expected Actions
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR) | - | Policy Violation | 4109 | The Patient Identifier Cross-reference Manager MUST NOT process the message. |
Security Considerations
The message SHALL be exchanged using a mutually authenticated channel or message authentication.
As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.
As for message authentication, the SOAP-Body of the message SHALL be signed or encrypted using X.509 certificates.
EFA IHE-ITI-Binding: notifyOfConsent
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDesa.08}
This binding implements the operation notifyOfConsent of the Resource Manager. It profiles the transaction Document Metadata Notify ITI-53 [IHE ITI Suppl. DSUB].
Constraints on the message
The input of notifyOfConsent SHALL be bound to the Notify Message [IHE ITI TF-2#3.53.4.1] as follows:
notifyOfConsent | Notify Message | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
patientID | XDSDocumentEntry.patientId | |
purpose | XDSDocumentEntry.eventCodeList | |
documentID |
|
Expected Actions
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The cross-community trust has not been established by means of a mutually authenticated channel or message authentication. (ERROR) | - | Policy Violation | 4109 | The Document Metadata Notification Recipient MUST NOT process the message. |
Security Considerations
The message SHALL be exchanged using a mutually authenticated channel or message authentication.
As for mutually authenticated channels, pairs of EFA-Providers SHOULD negotiate a protocol (f.e. SSH/TSL, VPN, KV-SafeNet) in the scope of contract conclusion.
As for message authentication, the SOAP-Body of the message SHALL be signed or encrypted using X.509 certificates.
HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1] |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 Document Registry XDS Binding
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.01}
Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Document Registry actors and operations as follows:
Role | EFA Document Registry Service | IHE XDS |
---|---|---|
Actor | EFA Client | Document Consumer |
Actor | EFA Document Registry | XDS Document Registry |
Actor | EFA Document Repository | XDS Document Repository |
Transaction | registerData | Register Document Set ITI-42 |
Transaction | listPartitionContent | Registry Stored Query ITI-18 |
Transaction | invalidateData | Update Document Set ITI-57 |
EFA XDS Binding: registerData
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.02}
While medical data is received and stored by the XDS Document Repository it is the responsibility of the Document Registry to register that data in a way that it can be queried through search and browse operations.
Such registration of a document to an ECR provider's registry service is bound to the IHE Register Document Set transaction (ITI-42). This EFA binding introduces minor extensions and restrictions on the respective XDS actor and transaction definitions in order to properly cover the EFA use cases and to align with the EFA security framework:
- Documents must be associated with folders in order to reflect that each ECR data element must be placed within a partition which in turn is part of a case record that carries the permissions for accessing data
- The requestor must be capable to register documents to the ECR provider that is targeted by this request. The ECR partition the provided document is associated with must be registered at this ECR provider.
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.02.01}
The RegisterDocument request message is issued by an ECR Document Repository actor for registering a medical document to an existing folder which is bound to an EFA instance. Each transmission carries metadata and associations for one or more documents. All referenced documents will be registered with the same folder within the same logical EFA.
The request message implements the IHE Register DocumentSet transaction (ITI-42) request message as profiled in [IHE ITI TF-2b] considering the following constraints:
- Each registered document SHALL be associated with a folder.
- The target folder SHALL be available in advance to this transaction. All documents SHALL be associated with the same folder (these restrictions ensure the proper implementation of the EFA Document Repository SFM which implies the existence of a partition and only allows for a single partitionID to be included with the request).
- The requestor (ECR Document Repository) SHOULD embrace the provided documents as a single IHE XDS submission set acc. to [IHE ITI TF-2a].
- The EFA provider SHOULD ignore this grouping and MUST ignore all associations between documents and submission sets.
- The XDS Document Registy MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata.
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.02.02}
The EFA Document Registry Service provider MUST verify that the requesting service is trustworthy in a way that the registry service can rely on the access control decision that has already been performed by the document repository in advance to this request. The EFA Document Registry Service SHALL respond to an RegisterDocumentSet request message with the RegisterDocumentSet response message containing a success indicator.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.02.03}
If the EFA Document Registry Service provider is able to decode the received message and to properly register all documents it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.02.04}
If the EFA Document Registry Service provider is able to decode the received message but the registration of one or more documents failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
If none of the documents was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If at least one document was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”. A failure location MUST be provided if the error does not apply to all documents. It MUST NOT be given if the error applies to all documents.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. For a list of valid error codes and message see Table 4.1-11 of [IHE ITI TF-3].
Security Audit Considerations
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.02.05}
EFA XDS Binding: listPartitionContent
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03}
Listing the content of a partition corresponds to listing XDSDocumentEntry-Elements that are associated with a given XDSfolder.
This EFA binding introduces the following extensions and restrictions on the IHE XDS actor and transaction definitions in order to properly cover the EFA listPartitionContent operation and to align with the EFA security framework:
- The query is restricted to listing the content of a single folder
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.01}
This operation is bound to a sequence of ITI-18 transactions:
- query GetFolderAndContents [IHE ITI TF-2a#3.18.4.1.2.3.7.11] to list XDSDocumentEntry-Elements,
- query GetAssociations [IHE ITI TF-2a#3.18.4.1.2.3.7.7] to list document relationships.
The following table shows the operation parameter binding:
listPartitionContent | ITI-18 | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
partitionID | $XDSFolderUniqueId | The requestor SHALL provide the unique folder ID as obtained when the partitions of an ECR were intially listed. |
docMetadata and docRelationship | registryObjectList | document metadata SHALL comply to the ECR Document Metadata Binding. If returnType=ObjectRef is defined for the query then only the partition identifiers will be provided. |
Example
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.01.01}
<query:AdhocQueryRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0 ../schemas/query.xsd"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
<query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
<rim:AdhocQuery id="urn:uuid:b909a503-523d-4517-8acf-8e5834dfc4c7">
<rim:Slot name="$XDSFolderUniqueId">
<rim:ValueList>
<rim:Value>'2871627126387^^^&1.2.3.4.213.234.3.7&ISO'</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:AdhocQuery>
</query:AdhocQueryRequest>
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.02}
The XDS Document Registry provider SHALL respond to a Registry Stored Query request message with the Registry Stored Query response message containing a success indicator and listing XDS metadata of all documents that match the given query. The provider of the XDS Document Registry provider MUST verify that the requesting service user has sufficient rights to access the given XDS folders.
In processing of this request the ECR Provider SHALL
- assess the access control policy of the ecrRef object that is assigned with the given folder. If no such object is assigned to the folder, the XDS Document Registry MUST respond with a "policy violation" error.
- respond to the requestor with the metadata of the discovered documents. Metadata provided SHALL comply to the EFA XDS Document Metadata Binding.
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Registry MUST respond with the respective error status.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.03}
If the EFA Document Registry Service provider is able to decode and process the received message it responds with the registry metadata of the discovered documents.
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.04}
If the XDS Document Registry is unable to successfuly process the query request it MUST respond with a ListResponse message that only contains a <AdhocQueryResponse/RegistryResponse> element.
If no matching document is discovered or an error occured during the processing of the request, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for ECR:
Condition and Severity | Message | Code | Action to be taken |
---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
The ECR provider is unable to verify the identity and/or the authenticity of the requestor (ERROR) | Invalid Subject | 4703 | The request MUST NOT be processed by the service provider. |
The partition is unknown to the ECR provider. | No Data | 1102 | The requestor should use a MPI service to discovery an identifier for the patient that is known to the ECR provider. |
The requestor has insufficient permissions to access the given partition. | No Consent | 4701 | - |
The given partition is not classified as an ECR folder. | Policy Violation | 4109 | - |
Security Considerations
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EDcui.03.05}
EFA XDS Binding: invalidateData
This binding realizes SFM operation invalidateData.
This binding conforms to IHE-ITI Update Document Set [ITI-57] and constrains it.
Constraints on the Request Message
The request message SHALL conform to the metadata update operation Update DocumentEntry Status.
The request message SHALL contain an EFA Identity Assertion. It relates to parameter context of SFM invalidateData.
The SFM parameter documentID is bound to the target object of the document relationship indirectly. Note: SFM documentID relates to DocumentEntry.uniqueID. Therefore, prior to invalidateData, an EFA Document Administrator must:
- query the document entry by uniqueID, and
- use DocumentEntry.entryUUID as the reference to the target object.
The value of slot NewStatus shall be urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated.
Expected Actions
Any metadata update operation other than Update DocumentEntry Status SHALL cause the entire transaction to fail, returning an Registry Error of type 4109: Policy Violation.
The EFA Document Registry SHALL enforce the access control policy of the EFA to which the to-be-invalidated document belongs to prior to updating its metadata.
Response Message (Full Success Scenario)
No constraints.
Response Message (Failure or Partial Failure Scenario)
No constraints.
Security Audit Considerations
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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 Document Repository XDS Binding
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.01}
Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Document Repository actors and operations as follows:
Role | EFA Document Repository Service | IHE XDS |
---|---|---|
Actor | EFA Client | Document Source (for provideData) Document Consumer (for retrieveData) |
Actor | EFA Document Repository | XDS Document Repository |
Transaction | provideData | Provide and Register Document Set ITI-41 |
Transaction | retrieveData | Retrieve Document Set ITI-43 |
EFA XDS Binding: provideData
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.02}
Providing a document to an ECR provider's repository service is bound to the IHE Provide and Register Document Set transaction (ITI-41). This ECR binding introduces minor extensions and restrictions on the respective XDS actor and transaction definitions in order to properly cover the EFA use cases and to align with the EFA security framework:
- Documents must be associated with an XDS Folders, i.e an ECR partition, which in turn is part of an ECR that carries the permissions for accessing data.
- The requestor must be capable to register documents to the ECR provider that is targeted by this request. The ECR partition the provided document is associated with must be registered at this ECR provider.
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.02.01}
The ProvideAndRegisterDocument request message is issued by an EFA client at the point of care for providing and registering a medical document to an existing ECR partition. Each transmission carries one or more documents. All provided documents will be registered with the same XDS Folder within the same logical EFA.
The request message implements the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE ITI TF-2b]. Implementations SHALL satisfy
- the Common constraints on ITI-41,
- the distinct set of constraints which trigger this binding, given in the table below (R = required, O = optional, - = forbidden).
Constraints | provideData binding |
---|---|
One XDS Document is a consentInfo which gives a new consent or does not revoke all active consents | - |
One XDS Document is a consentInfo, which revokes all active consents | - |
The provided XDS Folder and a registered XDS Folder have the XDSFolder.codeList and XDSFolder.patientID in common (i.e. the EFA exists) | R |
The XDS Folder is not registered (uniqueID) | - |
The XDSFolder is registered (uniqueID) | R |
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.02.02}
The XDS Document Repository SHALL forward the received documents to the EFA Document Registry using the ECR profiled Register Documents transaction.
The EFA Document Registry MUST verify that the requesting service user has sufficient rights to submit the given kind of documents for the identified patient and into the identified XDS Folder.
After processing the request the XDS Document Repository actor SHALL respond to an ProvideAndRegisterDocument request message with the ProvideAndRegisterDocument response message containing a success indicator.
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the EFA Document Registry Service provider MUST respond with a fault message according to section xx.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.02.03}
If the EFA Document Repository Service provider is able to decode the received message and to properly process/forward all transmitted documents it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"
If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to “urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”:
<rs:RegistryResponse
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
<rs:RegistryErrorList>
<rs:RegistryError
severity=”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning”
errorCode=”2201”
codeContext=”Processing deferred”
location="" />
</rs:RegistryErrorList>
</rs:RegistryResponse>
The following warning messages and codes are defined:
Condition and Severity | Message | Code | Action to be taken |
---|---|---|---|
Documents were received but not processed | Processing deferred | 2201 | None |
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.02.04}
If the EFA Document Repository failed with processing all of the documents or failed with forwarding all documents to the EFA Document Registry, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.
If none of the documents was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If at least one document was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”. A failure location MUST be provided if the error does not apply to all provided documents. It MUST NOT be given if the error applies to all provided documents.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for EFA:
Condition and Severity | Location | Message | Code | Action to be taken |
---|---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | - | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
The EFA Document Registry service provider only accepts data of the given kind if it is digitally signed by an HCP. (ERROR) | OID of the document that caused the error. | No Signature | 4704 | If possible, the EFA Client SHOULD re-issue the request with the data signed by an HP. |
For data of the given kind the EFA provider only accepts PDF coded documents (ERROR) | OID of the document | PDF required | 4107 | The provided document MUST NOT be processed by the EFA provider. The EFA Client MUST re-transmit the document in PDF format. |
A document of the provided kind does not comply with the EFA policy or the patient consent (ERROR) | OID of the document | Policy Violation | 4109 | The provided document MUST NOT be processed by the service provider. The HP MAY request the patient to extend the consent. |
Security Considerations
EFA XDS Binding: retrieveData
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.03}
This EFA binding introduces the following extensions and restrictions on the IHE XDS actor and transaction definitions in order to properly cover the EFA retrieveData operation and to align with the EFA security framework:
- Constraints on the retrieved documents due to the ECR usage conventions for XDS folders
- Additional error messages are defined that cover specific failure conditions of the EFA use cases
- The availability of data fields is aligned to EFA privacy requirements
- The application of security measures and the contents of the SOAP security header are specified normatively
Constraints on the Request Message
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.03.01}
The retrieveData request message implements the IHE Retrieve Document Set transaction (ITI-43) request message.
The following table shows how the retrieveData SFM is mapped onto the ITI-43 transaction's query arguments:
retrieveData | ITI-43 | Constraints |
---|---|---|
context | SAML Identity Assertion within the SOAP Security Header | see IHE Cookbook |
documentID | DocumentRequest/RepositoryUniqueId DocumentRequest/DocumentUniqueId |
The requestor SHALL provide these unique IDs as obtained when the contents of an ECR partition were intially listed. |
docData | DocumentResponse/Document | - |
In addition the following constrains must be considered:
- The data to be retrieved SHALL all be associated with the same XDS Folder. It SHALL be classified as an ECR partition.
Example
<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
<DocumentRequest>
<RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId>
<DocumentUniqueId>1.42.20101110141555.15</DocumentUniqueId>
</DocumentRequest>
</RetrieveDocumentSetRequest>
Expected Actions
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.03.02}
The XDS Document Repository SHALL respond to a Retrieve Document Set request message with the Retrieve Document Set response message containing a success indicator and listing all requested documents. The provider of the XDS Document Repository MUST verify that the requestor has sufficient rights to access the requested documents.
In processing of this request the ECR Provider SHALL
- request the DocumentEntry.availabilityStatus for the given DocumentUniqueId (a health record manager is allowed to access documents with availabilityStatus "Deprecated"),
- assess the access control policy of the ecrRef object that is assigned with the XDS Folder that is associated to the requested documents. If a document is not associated with an XDS Folder or if no ecrRef object is assigned to the XDS Folder, the XDS Document Repository MUST respond with a "policy violation" error.
- respond to the requestor with the requested documents.
In case of an error that relates to the transmission of the request or the processing of the EFA security token, the XDS Document Registry MUST respond with the respective error status.
Response Message (Full Success Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.03.03}
If the EFA Document Repository Service provider is able to decode and process the received message it responds with the discovered documents acc. to the specification of the ITI-43 response message.
Response Message (Failure or Partial Failure Scenario)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {EXoce.03.04}
If the XDS Document Repository is unable to successfuly process the query request it MUST respond with a RetrieveDocumentSetResponse message that only contains a RegistryResponse element.
If no matching document is discovered or an error occured during the processing of the request, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. The failure semantics is all-or-nothing; as soon as one of the requested documents cannot be provided the XDS Document Repository responds with a full failure by providing none of the requested documents.
The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for ECR:
Condition and Severity | Message | Code | Action to be taken |
---|---|---|---|
The EFA provider requests a higher authentication trust level than assigned to the HP (e.g. password-based login is not accepted for the requested operation). (ERROR) | Weak Authentication | 4702 | If possible, the HP SHOULD log in again with a stronger mechansims (e.g. smartcard) and re-issue the request with the respective identity assertion. |
The ECR provider is unable to verify the identity and/or the authenticity of the requestor (ERROR) | Invalid Subject | 4703 | The request MUST NOT be processed by the service provider. |
One or more document identifiers are unknown to the ECR provider. | No Data | 1102 | - |
The requestor has insufficient permissions to access one or more of the requested documents. | No Consent | 4701 | - |
Multiple XDS Folders are associated with the requested documents or at least one of the associated XDS Folders is not classified as an ECR partition. | Policy Violation | 4109 | - |
Security Considerations
Referenzen und Querverweise |
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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
|
Anhang
HL7 SAIF
tbd
HL7 ECCF Framework
Die EFA-Spezifikation orientiert sich an der Spezifikationsmatrix des Enterprise Consistency and Conformity Framework (ECCF) als Teil des HL7 Service-Aware Interoperability Framework (SAIF).
Enterprise Dimension "Why" Policy |
Information Dimension "What" Content |
Computational Dimension "How" Behavior |
Engineering Dimension "Where" Implementation |
Technical Dimension "Where" Deployment |
|
Conceptual Perspective | |||||
Logical Perspective | |||||
Implementable Perspective |
Die Spalten der Tabelle stellen bestimmte Eigenschaften des zu analysierenden und zu spezifizierenden Systems dar:
- Die Enterprise Dimension definiert den geschäftlichen Zusammenhang und befasst sich primär mit den EFA-Informationsobjekten und EFA-Geschäftsprozessen.
- Die Information Dimension befasst sich mit dem Informationsmodell der Fallakte sowie damit zusammenhängenden Restriktionen bei der Nutzung und Interpretation dieser Information.
- Die Computational Dimension fokussiert auf die fachlichen Funktionen der EFA mit den zugehörigen Akteuren, welche durch Transaktionen mit einem bestimmtem Verhalten und Interaktionen charakterisiert sind.
Die Zeilen der Tabelle geben verschiedene Abstraktionsgrade wieder und adressieren somit verschiedene Expertengruppen:
- Die Conceptual Perspective ist vollständig rechnerunabhängig und eher problem- als lösungsorientiert. Artefakte dieser Ebene skizzieren die Grundlagen und Kernkonzepte der EFA aus der Fachexpertensicht und definieren als solche das ganzheitliche konzeptionelle Modell der EFA.
- Artefakte in der Logical Perspective stellen nachvollziehbare Transformationen von Artefakten der konzeptuellen Ebene in Formate für Architekten/Analysten dar. Diese Perspektive repräsentiert die funktionale/logische Spezifikation der EFA und definiert somit den EFA-Lösungsraum mit seinen Klassen, Diensten und Operationen.
- Artefakte in der Implementable Perspective enthalten alle notwendigen, technischen Bindungen (z. B. Datentypen, Wertemengen, Schnittstellen-Spezifikationen etc.) mit denen Entwickler in die Lage versetzt werden, Bausteine der funktionalen/logischen Spezifikation mittels Standards-basierender technischer Komponenten umzusetzen zu können.
- zurück zur EFA-2.0-Spezifikation
IHE White Paper "Access Control"
Diese Seite gibt einen kurzen Überblick über die im IHE White Paper "Access Control" eingeführten Konzepte und Begrifflichkeiten, wie sie auch im IHE Cookbook und in der EFAv2-Spezifikation verwendet werden.
Access Control Subsysteme
Prinzipien Service-Orientierter Architekturen wie z.B. die Entkopplung von Diensten und die deklarative Steuerung von Abläufen über Diensten lassen sich auch auf Sicherheitsinfrastrukturen und Sicherheitsdienste abbilden. Sicherheitsdienste zur Authentifizierung, Autorisierung, Nicht-Abstreitbarkeit, etc. können so voneinander entkoppelt als eigenständige, wiederverwendbare Subsysteme definiert und mit beliebigen Akteuren gruppiert werden. Ein Access Control Subsystem (ACS) integriert dabei insbesondere die in einschlägigen Standards wie z.B. RFC2753 und XACML definierten logische Komponenten zur Verwaltung, Entscheidung und Durchsetzung von Zugriffsregeln (Policies):
- Policy Authorities (technisch: Policy Administration Point, PAP) für die Verwaltung und Bereitstellung von Policies
- Attribute Services (auch: Policy Information Point, PIP) für die Verwaltung und Bereitstellung von Attributen, die zur Laufzeit für die Auswertung von Policies benötigt werden
- Policy Decision Points (PDP) und Policy Enforcement Points (PEP) für die Auswertung und Durchsetzung von Policies
Um Policies, Policy Entscheidungen, für Policy-Auswertungen benötigte Attribute, etc. sicher zwischen an verschiedene Akteure gebundene ACS austauschen zu können, werden sog. Sicherheitstoken verwendet, die von dedizierten Security Token Services (STS) ausgestellt werden.
Die nachfolgende Abbildung stellt den generischen Aufbau eines Access Control Subsystems im Überblick dar.
5-Domänen-Modell
Das IHE White Paper "Access Control" beschreibt eine Methodik zur Analyse, zum Design und zur Bewertung von Access Control Lösungen für eHealth-Anwendungen. Kern dieser Methodik ist das sog. 5-Domänen-Modell, das die verschiedenen Aspekte einer jeden Access Control Lösung auf von konkreten Anwendungsdiensten und Deployments unabhängige logische Domänen abbildet. An jede dieser Domänen ist an ACS gebunden, das domänenspezifische Ausprägungen der oben skizzierten logischen ACS-Komponenten kapselt:
- Die Context Domain bildet den Ausführungskontext des Nutzers ab. Hier werden z.B. Kontext-Attribute (z.B. Zweck eines Datenabrufs) verwaltet und die für eine Anwendung im aktuellen Kontext aktivierte Nutzerrolle festgelegt.
- Die Subject Domain kapselt alle Funktionalitäten zur Identifizierung, Beschreibung und Authentifizierung eines Nutzers.
- Die Resource Domain bildet die durch die Access Control Lösung zu schützende Ressource (z.B. medizinische Daten) ab. Der Zugang zu dieser Ressource wird durch einen vorgelagerten PEP abgesichert.
- In der Patient Domain werden alle direkt mit dem Patienten verknüpften Policies - insb. auch Einwilligungen - verwaltet und bereitgestellt.
- Die Application Domain kapselt alle mit einer Anwendung verknüpften Policies und Nutzungskonventionen. Da diese Policies nur selten explizit sind, repräsentiert diese Domäne für die meisten Anwendungen lediglich eine Sammlung von organisatorischen Vorgaben, die sich z.B. im Sicherheits- und Datenschutzkonzept der Anwendung widerspiegeln.