cdaefa:EFA Business Informationsmodell - Versionsgeschichte

Jcaumanns: /* EFA Business Informationsmodell */

2016-02-17T07:58:43Z

‎EFA Business Informationsmodell

Jcaumanns: /* consentDoc */

2016-02-17T07:57:29Z

‎consentDoc

Jcaumanns: /* consentInfo */ Bild-Auflösung korrigiert

2016-02-16T16:16:51Z

‎consentInfo: Bild-Auflösung korrigiert

Jcaumanns: /* purpose */

2016-02-14T11:36:41Z

‎purpose

Jcaumanns: /* consentInfo */

2016-02-14T10:03:08Z

‎consentInfo

Jcaumanns: /* docMetadata */

2016-01-13T19:10:09Z

‎docMetadata

Jcaumanns: Markup-Fehler behoben

2015-01-27T10:06:31Z

Markup-Fehler behoben

Jcaumanns: Markup-Fehler behoben

2015-01-26T15:59:19Z

Markup-Fehler behoben

Jcaumanns: Markup-Fehler behoben

2015-01-26T15:59:01Z

Markup-Fehler behoben

Jcaumanns: Querverweise

2015-01-13T17:32:03Z

Querverweise

Änderungen zeigen

@@ Zeile 120: / Zeile 120: @@
 Ein consentDoc-Dokument muss ein consentInfo-Dokument ergänzen (siehe [[#docRelationship|docRelationship]]).
-=== consentLegalAuthenticator  ===
+==== 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 ===
+==== 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"]]).
-=== consentCustodian ===
+==== consentCustodian ====
 Die Klasse ''consentCustodian'' benennt die Einrichtung, in der die vom Patienten unterschriebene Fassung der Einwilligung aufbewahrt wird.
 ==== partitionID ====

← Nächstältere Version		Version vom 17. Februar 2016, 07:57 Uhr
Zeile 119:		Zeile 119:

	Ein consentDoc-Dokument muss ein consentInfo-Dokument ergänzen (siehe [[#docRelationship\|docRelationship]]).		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.
		+
		+	=== 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"]]).
		+
		+	=== consentCustodian ===
		+	Die Klasse ''consentCustodian'' benennt die Einrichtung, in der die vom Patienten unterschriebene Fassung der Einwilligung aufbewahrt wird.
		+
		+	=== consentCreationDate ===
		+	Diese Klasse benennt das Erstellungsdatum der Einwilligung, das gleichzeitig den Beginn der Gültigkeit der Einwilligung markiert.

	==== partitionID ====		==== partitionID ====

@@ Zeile 99: / Zeile 99: @@
 Diese Klasse ist eine Spezialisierung der Klasse [[#document|''document'']].
-[[Datei:IM_PIM_consentInfo2.png|340px]]
+[[Datei:IM_PIM_consentInfo2.png|507px]]
 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:

@@ Zeile 74: / Zeile 74: @@
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.02}</tt>
-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.
+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.
 {{NoteBox|
-Es wird empfohlen, standardisierte Diagnosecodes (z. B. ICD-10) oder die Referenzierung eines Vertrages (z. B. DMP, Hausarzt-Vertrag, IV-Vertrag) zu verwenden. Weitere Merkmale können verwendet werden. Sie sollten offiziell mit dem Verein Elektronische Fallakte abgestimmt werden.
+Es wird empfohlen, die medizinische Fälle determinierenden Versorgungsmuster über Konzepte in einem vom EFA-Verein gepflegten Codesystem auszudrücken.
 }}
 ==== ecrStatus ====

@@ Zeile 102: / Zeile 102: @@
 Diese Klasse ist eine Spezialisierung der Klasse [[#document|''document'']].
-[[Datei:IM_PIM_consentInfo.png|437px]]
+[[Datei:IM_PIM_consentInfo2.png|340px]]
-Diese Klasse ist eine Profilierung des Informationsmodells einer Einwilligung (siehe [[Patienteneinwilligung|Leitfaden "Einwilligung"]]). Es basiert auf dem Konzeptmodell des [[DAM_„Zweckgebundene_Kommunikation“|Domänenmodells "Einwilligung zur zweckgebundenen Kommunikation"]]:
+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'']].
+* 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.
+* 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.
-Zu jedem Zeitpunkt hat eine Fallakte bei jedem beteiligten EFA-Provider genau eine wirksame Instanz von ''consentInfo''. Eine neue Instanz invalidiert die bestehende Instanz.
+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.
 ==== consentDoc ====

@@ Zeile 214: / Zeile 214: @@
 |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]].
 |-
 |Titel

@@ Zeile 307: / Zeile 307: @@
 {|class="wikitable"
 |-
-|'''Attribut'''
+!Attribut
-|'''Beschreibung'''
+!Beschreibung
 |-
 |patientID

@@ Zeile 338: / Zeile 338: @@
 {{NoteBox|'''Referenzen und Querverweise'''
 * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 }}

@@ Zeile 159: / Zeile 159: @@
 *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.}}
+*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.
 ==== partitionInfo ====
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {BnsIi.02.09}</tt>