cdaefa Diskussion:EFA Geschäftsobjekte - Versionsgeschichte

Jcaumanns am 16. September 2014 um 11:49 Uhr

2014-09-16T11:49:18Z

Änderungen zeigen

Jcaumanns: Kommentare aktuallisiert.

2014-06-20T18:12:03Z

Kommentare aktuallisiert.

Jcaumanns: Status der Change Requests aktualisiert.

2014-06-16T20:01:27Z

Status der Change Requests aktualisiert.

Tidris am 10. April 2014 um 09:16 Uhr

2014-04-10T09:16:20Z

Tidris: /* Kommentierung */

2014-04-10T09:15:53Z

‎Kommentierung

Jcaumanns: /* Offene Change Requests */

2014-01-24T18:31:00Z

‎Offene Change Requests

Jcaumanns: Change Requests aktualisiert.

2014-01-24T18:27:14Z

Change Requests aktualisiert.

Jcaumanns: Aktuelle Fassung der Kommentar-Tabelle eingefügt.

2014-01-24T15:20:56Z

Aktuelle Fassung der Kommentar-Tabelle eingefügt.

Änderungen zeigen

Foemig: kommentiert

2014-01-20T12:23:03Z

kommentiert

Jcaumanns: /* Empfehlung des Editors */

2014-01-06T23:15:15Z

‎Empfehlung des Editors

@@ Zeile 41: / Zeile 41: @@
 !Comment Editor
 !Discussion
 |- style="vertical-align:top;"
 |style="background-color: white;"|fo
@@ Zeile 71: / Zeile 62: @@
 |- style="vertical-align:top;"
 |style="background-color: white;"|fo
-|style="background-color: white;"|captured
+|style="background-color: #E77471;"|rejected
 |style="background-color: white;"|Eehä.01 : Hierarchisches Informationsmodell der EFA
 |style="background-color: white;"|
 |style="background-color: white;"|
 |style="background-color: white;"|Wir müssen hier nochmal diese Grundlagen explizit darstellen! Also, was brauchen wir logisch zum Arbeiten und wie wird es technisch dargestellt!? In der Community fehlt nach wie vor das Bewusstsein, dass eine Kommunikation IMMER über das ISO-Schichtenmodell läuft. Es geht nicht ohne. (Das wird bspw. auch in der realen Kommunikation zwischen Menschen gemacht, nur wird das nicht explizit dargestellt.) Diese Aspekte laufen auf eine klare Trennung der Ebenen 5 bis 7 hinaus. Vielleicht sollte die Zuordnung von logischen Ordnern und Dokumenten auf Ebene 7 mit der Umsetzung in technischen Objekten auf Ebene 5 mal aufgemalt werden? Dann wird auch klar, dass wir auf Ebene 7 unterschiedliche Objekte haben, die dann auf dieselben Objekte in Ebene 5 gemappt werden, so dass für die bijektive Abbildung dann Zusatzattribute bemüht werden müssen! (fo, 20.01.14)
-|style="background-color: white;"|
+|style="background-color: white;"|Abstraktionsschichten für die Spezifikation wurden mithilfe der ECCF-Matrix eingezogen. Das OSI-Schichtenmodell ist in der Spezifikation nicht unmittelbar relevant, da nur Aspekte auf der Anwendungsebene (HTTP und darüber) berührt werden. (bkr, 13.06.2014)
 |style="background-color: white;"|
 |- style="vertical-align:top;"
@@ Zeile 117: / Zeile 108: @@
 |- style="vertical-align:top;"
 |style="background-color: white;"|fo
-|style="background-color: #C2DFFF;"|postponed
+|style="background-color: #89C35C;"|included
 |style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 |style="background-color: white;"|Abfrage anderer Provider
@@ Zeile 123: / Zeile 114: @@
 |style="background-color: white;"|Es ist sicherlich nicht möglich alle zu bennen.Es kann auch nicht jeder Provider abgefragt werden. Abgesehen von Performancegründen macht das auch wenig Sinn. Es sollte aber berücksichtigt werden, dass ein Patient kommt und klar sagt, dass er bei einem anderen Provider bereits eine Akte hat.
 |style="background-color: white;"|Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)
-|style="background-color: white;"|
+|style="background-color: white;"|Jeder Peer verwaltet Mount-Points zu den Aktenteilen anderer Peers. Es wurden Operationen hinzugefügt (listRecordLocations, registerRecordLocation), mit denen Mount-Point abgefragt und registriert werden können. (bkr, 13.06.2014)
 |- style="vertical-align:top;"
 |style="background-color: white;"|sh
-|style="background-color: #C2DFFF;"|postponed
+|style="background-color: #89C35C;"|included
 |style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 |style="background-color: white;"|Um so verteilte, parallel existierende Akten zusammenzuführen, bedarf es der Einwilligung des Patienten, die dieser gegenüber einem Arzt geben muss, der Zugriff auf beide Akten hat (ggf. muss durch eine Änderung der Einwilligung zu einer der Akten dieser Zustand zunächst hergestellt werden).
@@ Zeile 132: / Zeile 123: @@
 |style="background-color: white;"|Ist dies organisatorisch realistisch? Existiert ein zentraler Verzeichnisdienst für alle Provider? Werden Verzeichnisdienste synchronisiert? Ist ein Leistungserbringer Teilnehmer bei mehreren Providern?
 |style="background-color: white;"|Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)
 |style="background-color: white;"|Ich gehe davon aus. (fo, 20.01.14)
 |- style="vertical-align:top;"
 |style="background-color: white;"|ti
-|style="background-color: #C2DFFF;"|postponed
+|style="background-color: #89C35C;"|included
 |style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 |style="background-color: white;"|
@@ Zeile 141: / Zeile 133: @@
 |style="background-color: white;"|Der hier beschriebene Mechanismus für verteilte Fallakten scheint (v.a. von Punkt 4 an) signifikant vom in der 7er Gruppe abgestimmten Vorschlag abzuweichen. (ti, 28.05.2013)
 |style="background-color: white;"|Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)
 |style="background-color: white;"|
 |- style="vertical-align:top;"

@@ Zeile 12: / Zeile 12: @@
 |- style="vertical-align:top;"
 |style="background-color: white;"|
-|style="background-color: #B5EAAA;"|commented
+|style="background-color: #E77471;"|rejected
 |style="background-color: white;"|Eehä.01 : Hierarchisches Informationsmodell der EFA
 |style="background-color: white;"|'''Unterscheidung von Muss- und Kann-Informationen:'''

@@ Zeile 43: / Zeile 43: @@
 |- style="vertical-align:top;"
 |style="background-color: white;"|ti
-|style="background-color: white;"|
+|style="background-color: white;"|captured
 |style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 |style="background-color: white;"|bedarf es der Einwilligung des Patienten, die dieser gegenüber einem Arzt geben muss, der Zugriff auf beide Akten hat (ggf. muss durch eine Änderung der Einwilligung zu einer der Akten dieser Zustand zunächst hergestellt werden).

@@ Zeile 41: / Zeile 41: @@
 !Comment Editor
 !Discussion
 |- style="vertical-align:top;"
 |style="background-color: white;"|fo

← Nächstältere Version		Version vom 24. Januar 2014, 18:31 Uhr
Zeile 1:		Zeile 1:

−	= ~~Offene~~ Change Requests =	+	= Change Requests =
−

	{\|class="wikitable" style="text-align: left; cellpadding: 10;"		{\|class="wikitable" style="text-align: left; cellpadding: 10;"

@@ Zeile 1: / Zeile 1: @@
 = Offene Change Requests =
 ''Die Informationen der eFA müssen sowohl zeitnah als auch sicher umgesetzt werden. Hierzu sind insbesondere die Bestimmungen des § 630f, 1 BGB (Patientenrechtegesetz) zu beachten. Dazu müssen die für die Behandlung obligatorischen Einträge von fakultativen Einträgen unterschieden werden. Die obligatorischen Einträge werden in der Partition 1 abgelegt. Diese enthält alle notwendigen Informationen, um medizinische Entscheidungen sicher treffen zu können. In der Partition 2 werden alle übrigen - die fakultativen - Einträge abgelegt. Beide Partitionen müssen durch Suchroutinen sicher und schnell durchgesehen werden können.''
+|style="background-color: white;"|Der Change Request sollte abgelehnt werden, da die praktische Umsetzbarkeit nicht ersichtlich ist und die haftungsrechtlichen Implikationen nicht abschließend bewertet werden können.
-=== Diskussion ===
+|style="background-color: white;"|
-Ein ähnlicher Vorschlag wurde schon einmal im Rahmen der eFAv1.2 Spezifikation diskutiert. Sowohl seitens des beteiligten Anwalts als auch seitens der Klinikvertreter wurde es als kritisch angesehen, dass der Daten in eine Akte einstellende Arzt eine Klassifizierung dieser Daten vornimmt, die potenziell dazu führt, dass andere Nutzer diese Daten nicht in dem aus ihrem Kontext angemessenen Maße würdigen. Dies gilt umso mehr, wenn Ärzte verschiedener Fachdisziplinen über eine EFA kooperieren. Hier sollten die Ärzte nicht gezwungen werden, festzulegen, welche Informationen für einen Arzt einer anderen Fachdisziplin obligatorisch sind und welche nicht.
+* Ein ähnlicher Vorschlag wurde schon einmal im Rahmen der eFAv1.2 Spezifikation diskutiert. Sowohl seitens des beteiligten Anwalts als auch seitens der Klinikvertreter wurde es als kritisch angesehen, dass der Daten in eine Akte einstellende Arzt eine Klassifizierung dieser Daten vornimmt, die potenziell dazu führt, dass andere Nutzer diese Daten nicht in dem aus ihrem Kontext angemessenen Maße würdigen. Dies gilt umso mehr, wenn Ärzte verschiedener Fachdisziplinen über eine EFA kooperieren. Hier sollten die Ärzte nicht gezwungen werden, festzulegen, welche Informationen für einen Arzt einer anderen Fachdisziplin obligatorisch sind und welche nicht. (jc)
+* So, wie das dargestellt ist, bietet es sich an, derartige Markierungen über Ordner zu realisieren. Damit käme zu der bisherigen Liste von kombinierbaren Flags weitere Einträge hinzu: "Dokumente mit obligatorischen Informationen" und "Dokumente mit fakultativen Informationen". (fo)
-=== Empfehlung des Editors ===
+* Abbildung über Relationship-Objekte möglich (jc, 2014-01-21)
-Der Change Request sollte abgelehnt werden, da die praktische Umsetzbarkeit nicht ersichtlich ist und die haftungsrechtlichen Implikationen nicht abschließend bewertet werden können.
+* Für Akzeptanz wichtig. Informationen sollten nicht Metadaten liegen, sondern in Dokumente.(ws, 2014-01-21)
+* Partitionierung: 1) Hauptinformationen, 2) Ergänzende Informationen (ma, 2014-01-21)
-=== Kommentar FO ===
+* Arzt in der Pflicht. Wie unterscheidet dieser, dass Informationen nicht wichtig waren? (ti, 2014-01-21)
-So, wie das dargestellt ist, bietet es sich an, derartige Markierungen über Ordner zu realisieren. Damit käme zu der bisherigen Liste von kombinierbaren Flags weitere Einträge hinzu: "Dokumente mit obligatorischen Informationen" und "Dokumente mit fakultativen Informationen".
+* Fragestellung: was ist relevant? (ws, 2014-01-21)
 = Kommentierung =

@@ Zeile 13: / Zeile 13: @@
 === Empfehlung des Editors ===
 Der Change Request sollte abgelehnt werden, da die praktische Umsetzbarkeit nicht ersichtlich ist und die haftungsrechtlichen Implikationen nicht abschließend bewertet werden können.
 = Kommentare =
@@ Zeile 21: / Zeile 24: @@
 Der Begriff "Ordner" ist bei EFAv1.2 schon überladen und durch das XDS-Binding kommt eine weitere Semantik hinzu. Eine Erklärung der Begrifflichkeiten wurde als Infobox hinzugefügt. In der gesamten Spec wurde versucht, diese Begriffe einheitlich zu verwenden: technisch = "Partition" vs. logisch = "Ordner". (jc, 08.09.2013)
 == [[Datei:Under_construction_icon-blue.svg|confirm.svg|32px]] Eehä.01.01: Klasse Patient ==
@@ Zeile 31: / Zeile 36: @@
 === [[Datei:Si-reconc.svg|32px]] Zusammenführung von bei verschiedenen Providern angelegten Fallakten ===
-''Um so verteilte, parallel existierende Akten zusammenzuführen, bedarf es der Einwilligung des Patienten, die dieser gegenüber einem Arzt geben muss, der Zugriff auf beide Akten hat (ggf. muss durch eine Änderung der Einwilligung zu einer der Akten dieser Zustand zunächst hergestellt werden).''	Ist dies organisatorisch realistisch? Existiert ein zentraler Verzeichnisdienst für alle Provider? Werden Verzeichnisdienste synchronisiert? Ist ein Leistungserbringer Teilnehmer bei mehreren Providern? (sh, 24.04.2013)
+''Um so verteilte, parallel existierende Akten zusammenzuführen, bedarf es der Einwilligung des Patienten, die dieser gegenüber einem Arzt geben muss, der Zugriff auf beide Akten hat (ggf. muss durch eine Änderung der Einwilligung zu einer der Akten dieser Zustand zunächst hergestellt werden).''	Ist dies organisatorisch realistisch? Existiert ein zentraler Verzeichnisdienst für alle Provider? Werden Verzeichnisdienste synchronisiert? Ist ein Leistungserbringer Teilnehmer bei mehreren Providern? (sh, 24.04.2013) Ich gehe davon aus. (fo, 20.01.14)
 Der hier beschriebene Mechanismus für verteilte Fallakten scheint (v.a. von Punkt 4 an) signifikant vom in der 7er Gruppe abgestimmten Vorschlag abzuweichen. (ti, 28.05.2013)
-Abfrage anderer Provider: Es ist sicherlich nicht möglich alle zu kennen.Es kann auch nicht jeder Provider abgefragt werden. Abgesehen von Performancegründen macht das auch wenig Sinn. Es sollte aber berücksichtigt werden, dass ein Patient kommt und klar sagt, dass er bei einem anderen Provider bereits eine Akte hat. (fo, 30.05.2013)
+Abfrage anderer Provider: Es ist sicherlich nicht möglich alle zu kennen. Es kann auch nicht jeder Provider abgefragt werden. Abgesehen von Performancegründen macht das auch wenig Sinn. Es sollte aber berücksichtigt werden, dass ein Patient kommt und klar sagt, dass er bei einem anderen Provider bereits eine Akte hat. (fo, 30.05.2013)
 Ein Essential logischer Natur ist die Anforderung, dass es nur eine Fallakte für einen medizinischen Fall geben sollte. Hier wird diese Anforderung klar unterlaufen und das Ziel als solches ausgehebelt. Dann sollte im dritten Bullet-Point unbedingt darauf hingewiesen werden, dass eine Zusammenführung durchzuführen ist. (fo, 30.05.2013)
@@ Zeile 62: / Zeile 67: @@
 == [[Datei:Attention_icon.svg|32px]][[Datei:Si-confirm.svg|32px]] Eehä.01.04: Klasse Datenobjekt ==
-Das Aktualisieren eines Dokuments ist in XDS nicht wie hier beschrieben vorgesehen. XDS kennt die Beziehungen "replace", "addendum", "transform" und "transform+replace". Die "replace" Beziehung bewirkt immer ein "deprecated" setzen des alten Dokuments. Es gibt über XDS Metadata Update die Möglichkeit die Metadaten zu aktualisieren, aber nicht die Document uniqueId, d.h. die referenzierten Binärdaten. Ausserdem gilt auch hier: "At any point in time there shall be at most one version of a logical DocumentEntry object with status Approved in the registry/recipient. If this version exists it shall always be the most recent version." (Metadata Update Supplement rev 1.2, line 623-625). Ich würde vorschlagen keine Unterscheidung zwischen Aktualisierung und Ersetzen zu machen. Änderungen am Dokument sollten immer als "replace" aufgefasst werden. Ich halte es nicht für notwendig den Client entscheiden zu lassen ob eine Ersetzung das alte Dokument invalidieren soll. (ti, 28.05.2013)
+Das Aktualisieren eines Dokuments ist in XDS nicht wie hier beschrieben vorgesehen. XDS kennt die Beziehungen "replace", "addendum", "transform" und "transform+replace". Die "replace" Beziehung bewirkt immer ein "deprecated" setzen des alten Dokuments. Es gibt über XDS Metadata Update die Möglichkeit die Metadaten zu aktualisieren, aber nicht die Document uniqueId, d.h. die referenzierten Binärdaten. Ausserdem gilt auch hier: "At any point in time there shall be at most one version of a logical DocumentEntry object with status Approved in the registry/recipient. If this version exists it shall always be the most recent version." (Metadata Update Supplement rev 1.2, line 623-625). Ich würde vorschlagen keine Unterscheidung zwischen Aktualisierung und Ersetzen zu machen. Änderungen am Dokument sollten immer als "replace" aufgefasst werden. Ich halte es nicht für notwendig den Client entscheiden zu lassen ob eine Ersetzung das alte Dokument invalidieren soll. (ti, 28.05.2013) ok (fo, 20.01.14)
-In späteren Teilen des Dokuments (v.a. {CiteD.01.03}) wird die Unterscheidung zwischen Aktualisieren und Ersetzen auch nicht mehr gemacht. (ti, 28.05.2013)
+In späteren Teilen des Dokuments (v.a. {CiteD.01.03}) wird die Unterscheidung zwischen Aktualisieren und Ersetzen auch nicht mehr gemacht. (ti, 28.05.2013) ok (fo, 20.01.14)
 In der 7er-Gruppe wurde das Invalidieren durch Ersetzen mit einem leeren Dokument definiert. Leider ist diese Semantik hier mit dem Ersetzen "überlagert" worden. Diese Seite sowie auch die logische Spezifikation der [[cdaefa:EFA_Business_Informationsmodell#docRelationship|Dokumenten-Beziehungen]] wurden entsprechend korrigiert.