EFA Business Informationsmodell

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(document)
K (EFA Business Informationsmodell)
 
(39 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Infobox Dokument
+
{{DocumentPart
|Title    = Informationsmodell der EFA Geschäftsobjekte
 
|Short    = Informationsmodell der EFA Geschäftsobjekte
 
|Namespace = cdaefa
 
|Type      = Implementierungsleitfaden
 
|Version  = 0.9
 
|Submitted = February 2013
 
|Author    = Jörg Caumanns, Raik Kuhlisch , Ben Kraufmann
 
|Date      = March 2013
 
|Copyright = 2012-2013
 
|Status    = Draft
 
|Period    = xxx
 
|OID      = n.n.
 
|Realm    = Deutschland
 
 
}}
 
}}
 
 
''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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
 
''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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
 
----
 
----
  
== EFA Informationsmodell ==
+
== EFA Business Informationsmodell ==
 +
 
 +
=== EFA Informationsmodell ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.01}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.01}</tt>
  
Zeile 25: Zeile 13:
 
[[Datei:IM_PIM_RIM_EFA.png|600px]]
 
[[Datei:IM_PIM_RIM_EFA.png|600px]]
  
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.  
+
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 [[cdaefa:EFA_Geschäftsobjekte|EFA Geschäftsobjekte]] auf ihre korrespondierenden logischen Objekte im Informationsmodell wider.
 +
 
 +
==== Patient ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.01.01}</tt>
 +
 
 +
Die funktional-logische Spezifikation der EFA korrespondiert mit der Sichtweise auf ein EFA-Netzwerk als eine [[cdaefa:EFA_Provider|Versorgungsdomäne]]. Auf der Sicht einer [[cdaefa:EFA_Provider|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_DE_Cookbook|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 ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.01.02}</tt>
  
Die Aussen-Semantik kann dabei über die folgenden, in der obigen Darstellung enthaltenen Aussagen zusammengefasst werden:
+
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 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.
 
* 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 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 [[cdaefa:Akteure_und_Rollen_der_EFA#EFA-Teilnehmer|Rollen der EFA-Nutzung]] ableiten.
 
* Zu jeder Fallakte sind berechtigte EFA-Teilnehmer benannt, deren Berechtigungen sich aus ihren definierten [[cdaefa:Akteure_und_Rollen_der_EFA#EFA-Teilnehmer|Rollen der EFA-Nutzung]] ableiten.
 +
 +
==== Partition ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.01.03}</tt>
 +
 +
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.
 
* 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.
 
* 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.
* Datenobjekte der EFA werden in Partitionen verwaltet. Ein Datenobjekt kann mehreren Partitionen zugeordnet sein, sofern diese beim selben EFA-Provider angelegt sind.
 
  
=== document ===
+
==== document ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.10}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.10}</tt>
 +
 +
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|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.   
 
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|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.   
Zeile 47: Zeile 51:
 
: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.
 
: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|docMetadata]]
 
;[[#docMetadata|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.
;docContent
+
;docData
:
+
:Das eigentliche Dokument ist aus Sicht der EFA (von wenigen Ausnahmen abgesehen) ein BLOB, der nicht weiter maschinell verarbeitet wird.
;[[#docRelationship||docRelationship]]
+
;[[#docRelationship|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 ==
+
=== PIM Data Structures ===
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02}</tt>
  
Die nachfolgend beschriebenen Objektklassen beschreiben die über Operationen der EFA-Dienste ausgetauschten Instanzen (von Ausschnitten) des EFA-Informationsmodells. Diese Klassen werden nachfolgend in der Abstraktionsstufe des ''EFA Service Functional Model'' unabhängig von einer konkreten technischen Umsetzung definiert.
+
Die hier definierten plattformunabhängigen Datenstrukturen zeichnen die fachlichen Eingabe- und Ausgabe-Parameter der Operationen des EFA Service Functional Model aus.
  
=== patientID ===
+
==== patientID ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.01}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.01}</tt>
  
Die ''patientID'' ist ein eindeutiger Identifizierer eines Patienten innerhalb einer von einem EFA-Provider realisierten [[cdaefa:EFA_Provider|Affinity Domain]]. Sie bildet damit in der IHE-Semantik die "XAD-PID" ab (siehe IHE Cookbook).
+
Diese Klasse ist ein eindeutiger Identifizierer eines Patienten innerhalb einer [[cdaefa:EFA_Provider|Affinity Domain]] eines EFA-Providers.
 
 
Wenn eine ''patientID'' bei einem Operationsaufruf von einem EFA-Teilnehmer an einen EFA-Dienst übergeben wird, muss diese ID in der Affinity Domain des EFA-Providers registriert sein, d.h. das Clientsystem des EFA-Teilnehmers muss ggf. vor dem Dienstaufruf eine Abbildung der lokal genutzten Patienten-ID auf die EFA ''patientID'' der Domäne des EFA-Providers vornehmen.
 
  
Im Fall von in einem Peer-to-Peer-Verbund verteilt verwalteten Fallakten ist es nicht unwahrscheinlich, dass jeder Provider den selben Patienten unter einer anderen ''patientID'' führt. Um eine sichere Verknüpfung der verteilt verwalteten Partitionen einer Fallakte realisieren zu können, muss jeder Provider bei einer verteilten Akte eine Abbildung der von ihm genutzten ''patientID'' auf die von sämtlichen anderen beteiligten Providern genutzten ''patientID''s realisieren können. Analog zu der Nutzung der ''patientID'' in einem Single-Peer-Szenario gilt auch hier die Regel "Sender does it right", d.h. bevor eine Anfrage von einem Peer an einen anderen weitergeleitet wird, muss der initierende Peer die Überführung der ''patientID'' in die Domäne des Ziel-Peers vornehmen.
+
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.
  
Da jede Fallakte eindeutig einem Patienten zugeordnet ist und jede Partition zu genau einer Fallakte gehört, ist auch jede Partition eindeutig einem Patienten zugeordnet. D.h. aus Sicht des Informationsmodells spielt es keine Rolle, ob eine EFA-Umsetzung die Patientenzuordnung ausschließlich auf Ebene der Fallakten verwaltet oder auch auf die Ebene der Partitionen herunter zieht.
+
In der IHE-Semantik entspricht diese Klasse der "XAD-PID" (siehe IHE Cookbook).
  
=== purpose ===
+
==== purpose ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.02}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.02}</tt>
  
Die Klasse ''purpose'' kodiert den Zweck einer Fallakte und referenziert damit eindeutig auf einen [[cdaefa:Die_EFA_als_zweckgebundene_Akte#Der_.22medizinische_Fall.22.|"medizinischen Fall"]] des Patienten. Die Kodierung des Zwecks kann entweder über einen standardisierten Diagnosecode (z.B. ICD-10) oder die Referenzierung eines Vertrags (DMP, IV, etc.) erfolgen. Instanzen der Klasse ''purpose'' müssen den Zweck einer Akte ausschließlich über kodierte Werte aus einem vorab innerhalb einer [[cdaefa:EFA_Provider|Versorgungdomäne]] definierten Vokabular verwenden.  
+
Diese abstrakte Klasse kodiert den Zweck einer Fallakte. Sie referenziert eindeutig den [[cdaefa:Die_EFA_als_zweckgebundene_Akte#Der_.22medizinische_Fall.22|"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.
 
[[Datei:IM_PIM_Purpose.png|640px]]
 
  
Da jede Fallakte eindeutig einem Zweck dient und jede Partition zu genau einer Fallakte gehört, ist auch jede Partition eindeutig einem Zweck zugeordnet. D.h. aus Sicht des Informationsmodells spielt es keine Rolle, ob eine EFA-Umsetzung die Zweckbindung ausschließlich auf Ebene der Fallakten verwaltet oder auch auf die Ebene der Partitionen herunter zieht.
+
{{NoteBox|
 +
Es wird empfohlen, die medizinische Fälle determinierenden Versorgungsmuster über Konzepte in einem vom EFA-Verein gepflegten Codesystem auszudrücken.
 +
}}
 +
 
 +
==== ecrStatus ====
  
=== ecrInfo ===
 
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.03}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.03}</tt>
  
Die Klasse ''ecrInfo'' umfasst die Metadaten zu einer Fallakte. In der EFA-Version 2.0 ist diese Klasse leer und lediglich ein auf der logischen Ebene definierter Platzhalter für zukünftige Erweiterungen oder in einer Versorgungsdomäne definierte spezielle Profile dieser Spezifikation.
+
Diese Klasse beschreibt die Zustände des [[cdaefa:EFA_Business_Lebenszyklus#Lebenszyklus_einer_Fallakte|Lebenszyklus ]]einer Fallakte.
  
{{NoteBox|
+
Der Wertebereich dieser Klasse ist:
Der Verzicht auf normativ vorgegebene Metadaten zu einer Akte bringt den Vorteil einer deutlich einfacheren und flexibleren Umsetzbarkeit der Spezifikation auf bestehenden Standards (gängige Aktenstandards wie IHE XDS unterstützen keine logischen Konstrukte oberhalb eines weitgehend semantikfreien Ordner, d.h. ein Container für Metadaten einer Fallakte wäre in jedem Fall eine proprietäre Ergänzung). Um dieses zu realisieren wurde 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:
 
* In der EFA-v2.0-Spezifikation ist eine Fallakte implizit als Summe der unter einer Patienteneinwilligung gefassten, zum gleichen Patienten und Zweck angelegten Partitionen definiert. "Einwilligung" ([[#consentInfo|consentInfo]]), "Partition" ([[#partitionID|partitionID]]) sowie "Patient und Zweck" ([[#ecrRef|ecrRef]]) sind hierbei eigenständig verwaltete und verknüpfte Objekte, die sofern im Rahmen eines Operationsaufrufs erforderlich auch explizit als Argumente übergeben werden.
 
* Die EFA-v2.0-Spezifikation besitzt mit Ausnahme der Operationen zur Steuerung des Lebenszyklus (createECR, closeECR, registerConsent) keine Operationen auf Fallakten, sondern realisiert Funktionen zum Lesen und Schreiben ausschließlich auf Ebene der Partitionen. Insbesondere gibt es im [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|''Service Functional Model'']] keine Operationen zum Suchen, Öffnen oder Auslesen von Fallakten, für die Metadaten einer Fallakte erforderlich wären.
 
}}
 
  
=== consentInfo ===
+
*Offen / Open
 +
*Gesperrt / Suspended
 +
*Verfallen / Retired
 +
*Archiviert / Archived.
 +
==== consentInfo ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.04}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.04}</tt>
  
Die Klasse ''consentInfo'' bildet den Inhalt einer Patienteneinwilligung in so weit maschinenlesbar ab, als dass darüber eine automatische Konfiguration einer Fallakte und ihrer Zugriffsrechte möglich ist.
+
Diese Klasse ist eine strukturierte Abbildung der [[cdaefa:Patienteneinwilligung_zur_EFA| Patienteneinwilligung zur EFA]]. EFA-Dienste erzeugen aus den Instanzen dieser Klasse EFA-Berechtigungsregeln.
''consentInfo'' ist ein EFA-2.0-Profil auf dem im [[DAM_„Zweckgebundene_Kommunikation“|Domänenmodell "Einwilligung zur zweckgebundenen Kommunikation"]] definierten Konzeptmodell und dem daraus abgeleiteten Informationsmodell einer Einwilligungserklärung. Im Einzelnen umfasst dieses Profil die folgenden Einschränkungen zu dem im [[Patienteneinwilligung|Leitfaden "Einwilligung"]] definierten Informationsmodell:
+
 
* Die Kodierung des Zwecks unterliegt den im Abschnitt zur Klasse "[[#purpose|purpose]]" definierten Vorgaben. Es müssen die im [[cdaefa:EFA_XDS_Folder_Metadata_Binding#codeList|EFA-2.0-XDS-Binding]] festgelegten Codesysteme verwendet werden.  
+
Diese Klasse ist eine Spezialisierung der Klasse [[#document|''document'']].
* Die maschinenlesbare Darstellung einer Einwilligung muss eine Umsetzung der im [[cdaefa:CIM_Anlegen_einer_Fallakte#Interaktionsmuster:_Fallakte_anlegen|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.
+
 
 
+
[[Datei:IM_PIM_consentInfo2.png|507px]]
Die technischen Umsetzung der Klasse ''consentInfo'' kann über jedes Binding erfolgen, dass den [[Patienteneinwilligung|Leitfaden "Einwilligung"]] umsetzt. Hierbei sind die benannten Einschränkungen aus dem Informationsmodell in das Binding zu übernehmen.
+
 
 +
Diese Klasse setzt die Vorgaben zu den Inhalten einer [http://wiki.hl7.de/index.php?title=cdaefa:Patienteneinwilligung_zur_EFA Patienteneinwilligung zur EFA] technisch um:
 +
* Der Patient muss identifiziert sein.
 +
* Der Zweck muss angegeben sein. Dessen Kodierung unterliegt den Vorgaben der Klasse [[#purpose|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 [[cdaefa:CIM_Anlegen_einer_Fallakte#Interaktionsmuster:_Fallakte_anlegen|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.  
  
Es kann zu jedem Zeitpunkt nur eine aktuelle gültige Einwilligung geben, d.h. mit dem Einstellen eines validen ''consentInfo''-Objekts in eine Fallakte werden automatisch alle zuvor eingestellten ''consentInfo''-Objekte ungültig.
+
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 ===  
+
==== consentDoc ====  
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.05}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.05}</tt>
  
Die Klasse ''consentDoc'' ist eine Spezialisierung der Klasse ''[[#document|document]]'' und umfasst ein vom EFA-Provider inhaltlich nicht weiter verarbeitetes Dokument, dessen Gegenstand eine Patienteneinwilligung ist.  
+
Diese Klasse beschreibt die [[cdaefa:Patienteneinwilligung_zur_EFA|informierte, schriftliche Patienteneinwilligung]]. Sie ist ein unstrukturiertes, vom EFA-Provider inhaltlich nicht verarbeitetes Dokument.
 +
 
 +
Diese Klasse ist eine Spezialisierung der Klasse ''[[#document|document]]''.
 +
 
 +
Ein consentDoc-Dokument muss ein consentInfo-Dokument ergänzen (siehe [[#docRelationship|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.
  
Es kann zu jedem Zeitpunkt nur eine aktuelle gültige Einwilligung geben, die dem EFA-Provider gegenüber über die Klasse ''[[#consentInfo|consentInfo]] dargestellt wird. Zusammen mit der Bekanntmachung einer Einwilligung über ein ''consentInfo''-Objekt kann eine Instanz der Klasse ''consentDoc'' als menschenlesbares Pendant in die betroffene Akte eingestellt werden. Das ''consentDoc''-Objekt wird dabei als [[cdaefa:EFA_Geschäftsobjekte#Klasse_Datenobjekt|Ergänzung]] des ''consentInfo''-Objekts deklariert.
+
==== caseRecordManager ====
 +
Ein EFA-Teilnehmer muss als Fallakten-Manager ausgezeichnet sein. Hiermit sind erweiterte Berechtigungen verbunden (siehe [[cdaefa:Akteure_und_Rollen_der_EFA|"Akteure und Rollen"]]).
  
Ein Einstellen eines ''consentInfo''-Objekts ohne korrespondierendes ''consentDoc''-Objekt ist möglich. Das Einstellen eines ''consentDoc''-Objekts ist nur möglich, wenn dieses über eine Ergänzt-Beziehung mit einem ''consentInfo''-Objekt verknüpft ist.
+
==== consentCustodian ====
 +
Die Klasse ''consentCustodian'' benennt die Einrichtung, in der die vom Patienten unterschriebene Fassung der Einwilligung aufbewahrt wird.  
  
=== partitionID ===
+
==== partitionID ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.06}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.06}</tt>
  
Zeile 117: Zeile 136:
 
* ein von diesem Provider eindeutig auflösbarer Identifizierer.
 
* ein von diesem Provider eindeutig auflösbarer Identifizierer.
  
=== partitionList ===
+
==== partitionList ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.07}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.07}</tt>
  
Die Klasse ''partitionList'' beschreibt eine Menge von [[cdaefa:EFA_Geschäftsobjekte#Klasse_Partition|Partitionen]], die Fallakten des 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 [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|listPartitions]] die folgenden Informationen zu einer Partition verknüpft sein:
+
Diese Klasse beschreibt eine Menge von [[cdaefa:EFA_Geschäftsobjekte#Klasse_Partition|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 [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|listPartitions]] die folgenden Informationen zu einer Partition verknüpft sein:
 
;[[#partitionID|partitionID]]
 
;[[#partitionID|partitionID]]
:Identifizierer der Partition, über den diese Partition eindeutig referenziert werden kann. Eine solche Referenzierung ist vor allem zum Einstellen von Daten in eine Partition und zum Auslesen einer Partition erforderlich.
+
:Eindeutiger Identifizierer der Partition.
 
;[[#ecrRef|ecrRef]]
 
;[[#ecrRef|ecrRef]]
 
:Verweis auf die Fallakte, der die Partition zugeordnet ist. Jede Partition ist genau einer Fallakte zugeordnet.
 
:Verweis auf die Fallakte, der die Partition zugeordnet ist. Jede Partition ist genau einer Fallakte zugeordnet.
Zeile 130: Zeile 151:
 
[[Datei:IM_PIM_PartitionList.png|480px]]
 
[[Datei:IM_PIM_PartitionList.png|480px]]
  
=== ecrRef ===
+
==== ecrRef ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.08}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.08}</tt>
  
In der EFA-2.0-Spezifikation ist kein orginärer Identifier für Fallakten definiert. Wie schon im Zusammenhang mit der Klasse ''[[#ecrInfo|ecrInfo]]'' beschrieben, wird durch die Möglichkeit eines vollständigen Verzichts auf ein manifestiertes Fallakten-Objekt eine flexiblere und einfachere Umsetzung der EFA-Spezifikation über bestehende Standards unterstützt.
+
Diese Klasse beschreibt die Referenz einer Fallakte.
  
Um dennoch Fallakten eindeutig referenzieren zu können, wird die Tatsache ausgenutzt, dass pro Patient (''[[#patientID|patientID]]'') und Zweck (''[[#purpose|purpose]]'') per Definition nur eine Fallakte existieren darf. Hiermit bilden die in der Klasse ''ecrRef'' zusammengefassten Angaben zu Patient und Zweck zusammen eine eindeutige Referenz auf eine Fallakten.
+
Per [[cdaefa:EFA_Geschäftsobjekte#Klasse_Fallakte_.28Medizinischer_Fall.29|Definition]] hat ein Patient je Zweck höchstens eine Fallakte. Sie wird daher mit dem Tupel (''[[#patientID|patientID]]'', ''[[#purpose|purpose]]'') eindeutig in einer Affinity Domain referenziert.
  
[[Datei:IM_PIM_ecrRef.png|320px]]
+
Bei einer Peer-to-Peer-Vernetzung, in der Daten einer Fallakte über mehrere [[cdaefa:EFA_Provider|Affinity Domains]] verteilt vorgehalten werden, kann jede Affinity Domain potenziell eine eigene [[#patientID|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|communityID]] als dritter Bestandteil einer Fallakten-Referenz benötigt, die angibt, in welcher Affinity Domain die Referenz gültig ist.
  
=== partitionInfo ===
+
[[Datei:IM_PIM_ecrRef.png|420px]]
 +
 
 +
{{NoteBox
 +
| 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:
 +
 
 +
*In der EFA-v2.0-Spezifikation ist eine Fallakte implizit als Summe der unter einer Patienteneinwilligung gefassten, zum gleichen Patienten und Zweck angelegten Partitionen definiert. "Einwilligung" ([[#consentInfo|consentInfo]]), "Partition" ([[#partitionID|partitionID]]) sowie "Patient und Zweck" ([[#ecrRef|ecrRef]]) sind hierbei eigenständig verwaltete und verknüpfte Objekte, die sofern im Rahmen eines Operationsaufrufs erforderlich auch explizit als Argumente übergeben werden. Hiermit werden implizit auch die EFA-Metadaten [[#patientID|patientID]] und [[#purpose|purpose]] auf der Ebene der Partitionen realisiert.
 +
*Die EFA-v2.0-Spezifikation besitzt mit Ausnahme der Operationen zur Steuerung des Lebenszyklus (createECR, closeECR, registerConsent) keine Operationen auf Fallakten, sondern realisiert Funktionen zum Lesen und Schreiben ausschließlich auf Ebene der Partitionen. Insbesondere gibt es im ''[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)|Service Functional Model]]'' keine Operationen zum Suchen, Öffnen oder Auslesen von Fallakten, für die administrative oder gar medizinische Metadaten einer Fallakte erforderlich wären.
 +
<nowiki></nowiki>}}
 +
 
 +
==== partitionInfo ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.09}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.09}</tt>
  
Zeile 168: Zeile 198:
 
|Bezeichner der Organisation, die für die Anlage der Partition und die Pflege der darin enthaltenen Inhalte verantwortlich ist.
 
|Bezeichner der Organisation, die für die Anlage der Partition und die Pflege der darin enthaltenen Inhalte verantwortlich ist.
 
|Sofern diese Information nicht beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createPartition|Anlegen einer Partition]] gesetzt wird, gilt die Organisation des die Partition anlegenden Leistungserbringers als für die Partition verantwortlich. Diese Information muss beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|Auslesen der Partitionsdaten]] bereit gestellt werden.
 
|Sofern diese Information nicht beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#createPartition|Anlegen einer Partition]] gesetzt wird, gilt die Organisation des die Partition anlegenden Leistungserbringers als für die Partition verantwortlich. Diese Information muss beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitions|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 [[cdaefa:EFA Geschäftsobjekte|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.
 
Ein EFA-Binding kann weitere Attribute für Partitionen definieren. Diese müssen jedoch von einem clientseitigen Teilnehmersystem nicht zwingend verarbeitet werden.
  
=== docMetadata ===
+
==== docMetadata ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.11}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.11}</tt>
  
Die Interaktionsmuster der EFA-v2.0 sehen vor, dass ein Teilnehmersystem nach dem Öffnen einer Fallakte zunächst die Metadaten dieser Akte abruft und in einer dem Nutzungsszenario angemessenen Struktur anzeigt. Hierbei können auch Filter genutzt werden, um nicht relevante Daten auszublenden. Gezielte Suchen nach bestimmten Dokumenten setzen auf dem selben Muster auf, auch hier ruft das Teilnehmersystem zunächst die Metadaten der Inhalte der Fallakte ab und führt anschließend eine Suche auch diesen Daten durch.
+
Diese Klasse bildet die Metadaten eines Dokuments. Die folgende Tabelle beschreibt deren Attribute.
 
 
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 umfangreiche Metadaten zu jedem Dokument benötigt:
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 
!Attribut
 
!Attribut
 +
!Optionalität
 
!Beschreibung
 
!Beschreibung
 
!Verwendung
 
!Verwendung
 
|-
 
|-
|[[#documentID|documentID]] (mandatory)
+
|[[#documentID|documentID]]
|Eindeutiger Identifizierer der Partition
+
|muss
|Die ID eines Dokuments wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen von Daten]] in eine Partition abhängig vom genutzten Binding durch den EFA-Teilnehmer oder den EFA-Provider festgelegt. Sie muss beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert werden.<br>Die [[#documentID|documentID]] wird beim Abruf eines Dokuments, zum Invalidieren eines Dokuments sowie zum Setzen von [[#docRelationship|Dokumentenbeziehungen]] benötigt.
+
|Eindeutiger Identifizierer des Dokuments
 +
|Die ID eines Dokuments wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen von Daten]] in eine Partition abhängig vom genutzten Binding durch den EFA-Teilnehmer oder den EFA-Provider festgelegt. Sie muss beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert werden.<br>Die [[#documentID|documentID]] wird beim Abruf eines Dokuments, zum Invalidieren eines Dokuments sowie zum Setzen von [[#docRelationship|Dokumentenbeziehungen]] benötigt. Die ID eines Dokuments ist eine Instanz der Klasse [[#documentID|documentID]].
 +
|-
 +
|[[#patientID|patientID]]
 +
|muss
 +
|Eindeutige Identifizierung des Patienten, dem das Dokument zuzuordnen ist
 +
|Die ID des Patienten, dem das Dokument zuzuordnen ist, muss beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|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|patientID]] angegeben.
 
|-
 
|-
|Titel (mandatory)
+
|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.
 
|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 [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert.<br>Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
 
|Der Titel wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert.<br>Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
 
|-
 
|-
|Dokumentklasse (mandatory)
+
|Dokumentklasse
 +
|muss
 
|Grobgranulare Klassifizierung des Dokuments in einer über [[cdaefa:EFA_Provider|Versorgungsdomänen]] hinweg einheitlichen Nomenklatur.
 
|Grobgranulare Klassifizierung des Dokuments in einer über [[cdaefa:EFA_Provider|Versorgungsdomänen]] hinweg einheitlichen Nomenklatur.
 
|Die Dokumentklasse wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert.<br>Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
 
|Die Dokumentklasse wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert.<br>Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
 
|-
 
|-
|Dokumenttyp (mandatory)
+
|Dokumenttyp
|Feingranulare Klassifizierung des Dokuments in einer in der aktuellen [[cdaefa:EFA_Provider|Versorgungsdomäne]] definierten Nomenklatur.
+
|muss
|Der Dokumenttyp wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert.<br>Dieses Attribut kann z.B. genutzt werden, um einen EFA-Teilnehmer beim gezielten Abruf benötigter Informationen zu unterstützen.
+
|Feingranulare Klassifizierung des Dokuments in einer Nomenklatur, die von der [[cdaefa:EFA_Provider|Versorgungsdomäne]] definiert ist.
 +
|Das EFA-Teilnehmersystem setzt das Attribut beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen des Dokuments]] gesetzt und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert.<br>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 [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen des Dokuments]].
 
|-
 
|-
|Dokumentformat (mandatory)
+
|Zeitpunkt der Bereitstellung
|Kodierte Angabe zum Format des Dokuments (z.B. PDF)
+
|muss
|Das Dokumentformat wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert. Ein EFA-Provider kann zum Schutz vor Angriffen und Viren bestimmte Dokumentformate ablehnen bzw. vor der Übernahme in seine Datenbank prüfen, ob ein eingestelltes Dokument dem angegebenen Format entspricht.
+
|Zeitpunkt des Einstellens in die Fallakte.
 +
|Der EFA-Dienst setzt das Attribut beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|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 (mandatory)
+
|Zeitliche Einordnung
|Zeitraum der über das Dokument beschriebenen Handlung. Sofern dieser Zeitraum nicht bekannt oder eingrenzbar ist, wird das Datum des Einstellens des Dokuments als zeitliche Einordnung festgesetzt.
+
|kann
|Die zeitliche Einordnung eines Dokuments wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt. Der Zeitpunkt des Einstellens kann alternativ/zusätzlich durch den EFA-Provider gesetzt werden. Die festgesetzte zeitliche Einordnung wird beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert.<br>Dieses Attribut soll die gezielte Suche nach neu in eine Akte eingestellte Dokumente sowie eine chronologische Sortierung von EFA-Inhalten unterstützen.
+
|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 [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen des Dokuments]]. EFA-Teilnehmersysteme können mithilfe des Attributs Dokumente entlang des Behandlungsverlaufs sortieren.
 
|-
 
|-
|Verantwortliche Organisation (optional)
+
|Verantwortliche Organisation
|Bezeichner der Organisation, die für das Einstellen des Dokuments und die Richtigkeit der darin enthaltenen Inhalte verantwortlich ist.
+
|muss
|Sofern diese Information nicht beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] gesetzt wird, gilt die Organisation des die Daten in die Akte einstellenden Leistungserbringers als für das Dokument verantwortlich. Diese Information muss beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] bereit gestellt werden.
+
|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 [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments]]. Für den EFA-Dienst gilt: Er setzt die Organisations-ID der [[cdaefa:EFA_Security_Informationsmodell#subjectIdentity|subjectIdentity]] als Wert des Attributs.
 
|-
 
|-
|Dateigröße (optional)
+
|Dateigröße
 +
|kann
 
|Dateigröße des Dokuments  
 
|Dateigröße des Dokuments  
|Die Dateigröße eines Dokuments wird vom EFA-Provider ermittelt und beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] übermittelt.<br>Dieses Attribut kann vom EFA-Teilnehmersystem genutzt werden, um z.B. sehr große Dokumente parallel zu laufenden Nutzerinteraktionen im Hintergrund zu laden.
+
|Der Wert muss vom EFA-Provider ermittelt und gesetzt werden.
 
|-
 
|-
|Fehlererkennender Code (conditional, mandatory)
+
|Fehlererkennender Code
|Informationen zur Prüfung der Integrität des Dokuments. Dieses Attribut kann entfallen, wenn das Dokument mit einer digitalen Signatur versehen ist (s.u.).
+
|sollte
|Ein fehlererkennender Code (z.B. Hashwert) wird idealerweise bereits beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#provideData|Einstellen eines Dokuments in eine Partition]] berechnet und unverändert beim [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listData|Auflisten der Dokumente einer Partition]] vom EFA-Provider zurück geliefert. Hierdurch kann der Nutzer eines Dokuments sicher sein, dass ein Dokument während der Übertragung und Speicherung nicht verfälscht wurde.
+
|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 (optional)
+
|Signatur
|Digitale Signatur zur Sicherung der Authentizität (und Integrität)
+
|kann
|Idealerweise werden nur vom Ersteller digital signierte Dokumente in eine Fallakte eingestellt, um ein sehr hohes Maß an Integritäts- und Authentizitätsschutz zu realisieren. Da die hierzu benötigten Mechanismen jedoch erst mit der flächendeckenden Einführung von Heilberufsausweisen und zugehörigen Prüfdiensten verfügbar sind, ist die Nutzung von Signaturen zunächst optional.
+
|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.
 
Ein EFA-Binding kann weitere Attribute für Dokumente definieren. Diese müssen jedoch von einem clientseitigen Teilnehmersystem nicht zwingend verarbeitet werden.
  
 
+
==== docRelationship ====
=== docRelationship ===
 
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.12}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.12}</tt>
  
Beziehungen zwischen Dokumenten können sowohl innerhalb von Dokumenten als auch als eigenständige Objekte kodiert werden. Die Klasse ''docRelationship'' beschreibt ausschließlich außerhalb von Dokumenten definierte Beziehungen zwischen Dokumenten. Hierbei muss ein Binding die beiden folgenden Beziehungen unterstützen:
+
Diese Klasse beschreibt die [[cdaefa:EFA_Geschäftsobjekte#Klasse_Datenobjekt|Beziehung zweier Dokumente]]. Die nachfolgende Tabelle beschreibt die zulässigen Ausprägungen.
* Replace: Ein Dokument ersetzt ein anderes Dokument
 
* Append: Ein Dokument ergänzt ein anderes Dokument
 
 
 
Die nachfolgende Tabelle stellt dar, wie hierbei die auf der konzeptionellen Ebene definierten [[cdaefa:EFA_Geschäftsobjekte#Klasse_Datenobjekt|Dokumentbeziehungen]] umzusetzen sind.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
![[cdaefa:EFA_Geschäftsobjekte#Klasse_Datenobjekt|Dokumentbeziehung]]
+
!Dokumentbeziehung
 
!Semantik
 
!Semantik
!Umsetzung
 
 
!Anmerkungen
 
!Anmerkungen
 
|-
 
|-
|Aktualisieren eines Dokuments
+
|ergänzt
|Ein Dokument stellt eine neuere Version eines benannten anderen Dokuments dar. Das "alte" Dokument bleibt gültig und beim Abruf von Dokumenten aus einer Fallakte werden beide Versionen bereitgestellt. Es ist Aufgabe des EFA-Teilnehmersystems die Dokumente so anzuzeigen, dass es für den Nutzer erkennbar ist, dass ein Dokument durch ein anderes ersetzt wurde.  
+
|Ein Dokument ergänzt ein anderes Dokument.
|Replace
 
 
|
 
|
 
|-
 
|-
|Ergänzen eines Dokuments
+
|ersetzt
|Ein Dokument stellte eine Ergänzung eines anderen Dokuments dar (z.B. Befund zum Bild).
+
|Ein Dokument ersetzt ein anderes Dokument und dessen ergänzende Dokumente. Ein Dokument ist invalidiert, wenn ein leeres Dokument es ersetzt.
|Append
+
|Ein ersetztes Dokument darf nur für Inhaber erweiterter Rollen (z. B. Fallaktenmanager) sichtbar und abrufbar sein.
|Diese Beziehung wird u.a. im Rahmen der Verwaltung von Einwilligungen genutzt, um ein [[#consentDoc|consentDoc]]-Objekt an ein [[#consentInfo|consentInfo]]-Objekt zu binden.
 
|-
 
|Ersetzen eines Dokuments
 
|Ein Dokument ersetzt ein benanntes anderes Dokument. Das ersetzte Dokument wird 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.
 
|Replace
 
|Diese Semantik wird ausschließlich zur Invalidierung von Dokumenten genutzt. Hierbei wird das zu invalidierende Dokument durch ein Dokument ersetzt, dessen Dokumentklasse eindeutig anzeigt, dass das neue Dokument Angaben zur Invalidierung des ersetzten Dokuments trägt. Die Änderung des Dokumentenstatus muss durch den EFA-Provider erfolgen.
 
 
|}
 
|}
  
=== documentID ===
+
==== documentID ====
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.13}</tt>
 
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.13}</tt>
  
 
Die Klasse ''documentID'' beschreibt eine eindeutige Referenz auf ein [[#document|Dokument]]. Bestandteil der Referenz sind  
 
Die Klasse ''documentID'' beschreibt eine eindeutige Referenz auf ein [[#document|Dokument]]. Bestandteil der Referenz sind  
 
* ein Verweis auf das EFA Document Repository, in dem das Dokument verfügbar ist, sowie  
 
* ein Verweis auf das EFA Document Repository, in dem das Dokument verfügbar ist, sowie  
* ein von diesem Repository eindeutig auflösbarer Identifizierer.
+
* einen Identifizierer, den das EFA Document Repository auflösen kann.
 +
 
 +
==== communityID ====
 +
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.14}</tt>
  
== Querverweise und Referenzen ==
+
Die Klasse ''communityID'' beschreibt eine eindeutige Referenz auf eine [[cdaefa:EFA_Provider|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:
 +
 +
{|class="wikitable"
 +
|-
 +
!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.
 +
|}
 +
 +
 +
 +
----
 +
 +
 +
{{NoteBox|'''Referenzen und Querverweise'''
 
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 +
<nowiki></nowiki>
 +
}}

Aktuelle Version vom 17. Februar 2016, 07:58 Uhr

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anmerkung: Die 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.

IM PIM RIM EFA.png

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.

IM PIM Document.png

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.

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.

IM PIM consentInfo2.png

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.

IM PIM PartitionList.png

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.

IM PIM ecrRef.png

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.