cdaefa Diskussion:EFA Kommunikationsmuster: Unterschied zwischen den Versionen
K (Change Requests aktualisiert.) |
(Status der Change Requests aktualisiert.) |
||
Zeile 11: | Zeile 11: | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
− | |style="background-color:# | + | |style="background-color: #89C35C;"|included |
|style="background-color: white;"|Eouns.01.06 : Einstellen von Dokumenten | |style="background-color: white;"|Eouns.01.06 : Einstellen von Dokumenten | ||
|style="background-color: white;"|'''Konkreter beschreiben, wie ein Dokument invalidiert wird:''' | |style="background-color: white;"|'''Konkreter beschreiben, wie ein Dokument invalidiert wird:''' |
Version vom 16. Juni 2014, 20:02 Uhr
Change Requests
Requester | Status | Section | Change Request | Recommendation Editor | Discussion |
---|---|---|---|---|---|
included | Eouns.01.06 : Einstellen von Dokumenten | Konkreter beschreiben, wie ein Dokument invalidiert wird:
Zum Invalidieren wird ein Dokument mit einem leeren Dokument ersetzt und das ursprüngliche Dokument auf „deprecated“ gesetzt, so dass es normalerweise beim Abruf nicht mehr sichtbar ist (siehe Kapitel EFA Business Informationsmodell). Dieser Vorgang ist in der EFA-Spezifikation nur unzureichend beschrieben, da dieses Thema für alle Arten von Akten relevant ist und daher eigentlich im „IHE Cookbook“ beschrieben werden sollte. |
Das Invalidieren eines Dokuments sollte als eigenes Kommunikationsmuster beschrieben werden. Dieses Muster nutzt die logische Schnittstelle zum Einstellen eines Dokuments und beschriebt, wie dieses zum Invalidieren eines Dokuments zu parametrisieren ist. |
|
Kommentierung
Author | Status | Section | Existing | Proposed | Comment | Comment Editor | Discussion |
---|---|---|---|---|---|---|---|
ti | included | Eouns.01.02.02 : Fusion mit einer bestehenden Fallakte | Wenn die alte und die neu anzulegende Fallakte den gleichen Patienten und den gleichen Zweck haben, können sie sich ja nur im Teilnehmerkreis und der Gültigkeit unterscheiden (da ja in der neuen Fallakte noch keine Inhalte sind). Somit unterscheidet sich der Fall nicht vom Interaktionsmuster zum Anpassen einer EFA (ti, 31.05.2013) | ||||
fo | included | Eouns.01.04 : Schließen einer Fallakte | schließen einer Akte: auffinden | eine Akte wird immer über die Patienten-ID identifiziert, insofern entfällt das "Suchen". | Im Text klargestellt: Das Schließen der Akte beinhaltet das EInstellen eines Dokuments (consentinfo) mit einer Begründugn der Aktenschließung. Um diesen Schreibvorgang durchführen zu können, muss die Akte zunächst geöffnet werden. Ein "Suchen" ist immer erforderlich, da ein Patient potenziell mehrere Fallakten besitzen kann und daher die zu schließende Akte zunächst durch Angabe von Patient und Zweck lokalisiert werden muss. | Suchen/Finden ist getrennt zu betrachten, in Binding: Grace-Period-Policy berücksichtigen | |
fo | rejected | Eouns.01.05 : Auflisten von Partitionen | auflisten von Partitionen | die Objekte lassen sich auch ohne "Partition" auslesen | Ja, mit GetAll wäre dies möglich. Um hierbei jedoch die EFA-Semantik durchzusetzen, müssen die aktuell nur an den Orndern (Partitionen) hängenden Zweck-Attribute auf alle Dokumente in diesen Ordnern vererbt werden. Hier wurde der einfachere Weg gewählt, immer über die Ordner zuzugreifen, um so die Dokumentenverwaltung ach XDS-"as-is" realisieren zu können. Darüber hinaus bekommt man so eine Ablaufsequenz, die analog auch für das P2P-Szenario gilt, d.h. es muss in Bezug auf die reine Ablaufsequenzierung keine Unterscheidung zwischen Single-Peer und Multi-Peer gemacht werden. | ||
fo | included | Eouns.01.06 : Einstellen von Dokumenten | Objekte immer in Partition | kann man so machen | |||
ti | included | Eouns.01.06 : Einstellen von Dokumenten | Es wird hier von dem Document Repository des EFA Providers gesprochen. Aufgrund der konzeptionellen Darstellung geht der Leser aber eher von einer dezentralen Dokumentenspeicherung mit Ausnahmen für Praxissysteme aus. Daher sollte die Formulierung hier hinsichtlich des Repositories neutraler sein. Ich würde hier vom "Document Repository für den Teilnehmer" sprechen, wobei natürlich noch erläutert werden soll was das heisst. Prinzipiell hat jeder Teilnehmer aber genau ein dediziertes Repository wo er Daten ablegt. (ti, 31.05.2013) | Richtig. Zur Klarstellung wurde in das Kapitel eine entsprechende Infobox eingefügt. | |||
ti | included | Eouns.01.06 : Einstellen von Dokumenten | Unter 4.4 sollte auch noch die Verpflichtung der Registry zum Markieren von veralteten verlinkten Dokumenten (d.h. bei availability auf deprecated setzen bei Replace Assoziationen) erwähnt werden. (ti, 31.05.2013) | Als 4.5 eingefügt. | |||
fo | included | Eouns.01.07 : Auflisten von Dokumenten | Zugriff über Partition | an dieser Stelle kommt das alte EFA-Konstrukt wieder zum Vorschein. Jetzt erfolgt ein Zugriff immer top-down. Insofern ist eine Prüfung der Berechtigung nicht später, sondern früher erforderlich. (Dieser Fakt zieht sich über mehrere Stellen…) | Wie in anderen Kommentaren bereits beschrieben, ist die Fokussierung auf den Top-Down Zugang vor allem eine Vereinfachung der Umsetzung. Prinzipiell spricht nichts dagegen, in zukünftigen EFA-Versionen auch weitere Zugänge zu unterstützen. Um dies deutlicher zu machen, wurde die (logische) Operation "listData" in "listPartitionContent" umbenannt, d.h. zukünftig kann es in Abgrenzung hierzu auch noch eine weitere Operation "listEfaContent" geben.... | Standard-Verhalten: Top Down Zugriffe mit Folder-Konstrukten, weiterhin muss die Anfrage "getAll" der Document Registry für das Profil "EFA" spezifiziert werden.
Verweis auf Cookbook. Notwendig: Spezifikation eines normativen Request Kontextes. | |
fo | rejected | Eouns.01.07 : Auflisten von Dokumenten | alle Partitionen anfassen | Objekte können auch unabhängig von Partitionen/Ordnern gesucht werden.
Da in einer Fallakte sowieso alle Objekte allen zur Verfügung stehen, ist diese Einschränkung nicht notwendig. |
Ja, mit GetAll wäre dies möglich. Um hierbei jedoch die EFA-Semantik durchzusetzen, müssen die aktuell nur an den Orndern (Partitionen) hängenden Zweck-Attribute auf alle Dokumente in diesen Ordnern vererbt werden. Hier wurde der einfachere Weg gewählt, immer über die Ordner zuzugreifen, um so die Dokumentenverwaltung ach XDS-"as-is" realisieren zu können. Darüber hinaus bekommt man so eine Ablaufsequenz, die analog auch für das P2P-Szenario gilt, d.h. es muss in Bezug auf die reine Ablaufsequenzierung keine Unterscheidung zwischen Single-Peer und Multi-Peer gemacht werden. | ||
fo | included | Eouns.01.08 : Abrufen von Dokumenten | Ändern der Zweckbindung | Das ist ein Punkt, den wir nicht diskutiert haben. Gemäß Verwaltung von Ordnern kann das dazu führen, dass Konflikte (mit anderen Akten) entstehen. Ausserdem muss das über alle betroffenen Ordner durchgezogen werden. | Guter Punkt. In der Spezifikation wurde eine entsprechende Prüfung verankert. Besteht schon eine Akte mit dem "neuen" Zweck, ist dies eine Zusammenführung von Akten und muss über das entsprechende Interaktionsmuster erfolgen. | ||
fo | rejected | Eouns.01.08 : Abrufen von Dokumenten | Zugriff auf Dokumente | Für den Zugriff auf die Dokumente benötigt man nur die ID, nicht die Partition. | Aktuell wird nur ein Top-Down Zugang über Ornder unterstützt. Von daher ist die Partitions-ID erforderlich. Zur Verdeutlichung (und um weitere Zugänge nicht auszuschließen) wurde die Operation in "listPartitionContent" umbenannt. | ||
ti | included | Eouns.01.08 : Abrufen von Dokumenten | Wie im vorherigen Abschnitt sollte auch hier auf den Umgang mit mehreren Repositories hingewiesen werden. Dies ist ja auch ein Teil der Konzeption und logischen Sicht auf das System, daher ist eine Erwähnung in diesem Kapitel sinnvoll. Der Abruf muss natürlich nicht aus dem Repository des abfragenden Teilnehmers geschehen, sondern aus dem für den einstellenden Teilnehmer zuständigem Repository. (ti, 31.05.2013) | Wichtiger Punkt; Text wurde entsprechend konkretisiert.
ACHTUNG: Text muss ggf. für das P2P Szenario noch mal erweitert werden (für das Single-Peer Szenario ändert sich nichts, da in diesem Szenario der für die Partition zuständige Provider immer der "Single Peer" ist). |
|||
ti | included | Eouns.01.09 : Registrierung einer neuen Einwilligung | Die unter 3.2 beschriebene Prüfung der Einwilligung durch den EFA Provider sollte genauer erläutert werden: Handelt es sich um eine manuelle Prüfung oder eine automatische? Wenn automatisch, was muss dort geprüft werden, da die EFA Spezifikation ja sehr konkrete Vorgaben mit wenig Freiheitsgraden macht? (ti, 31.05.2013) | Die Prüfung umfasst die Identifizierbarkeit der Teilnehmer, die Kodierung von Rollen und die Gültigkeit von Zeitangaben. Die Spezifikation wurde entsprechend konkretisiert. |