cdaefa Diskussion:EFA Kommunikationsmuster

Change Requests

ID	Requester	Status	Section	Change Request	Recommendation Editor	Discussion
7	-	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.	ok (fo) Invalidieren bisher: Deprecation des alten Dokuments und Verweis auf neues Dokument (jc, 2014-01-21) Bisher keine Vorgaben im Cookbook, aber Hinweis auf Metadata-Update. (ti, 2014-01-21) Revision: Visualisierte Darstellung der Akte muss auch archiviert sein. "Was konnte der Arzt zu Zeitpunkt X sehen?". Empfehlung von Schmücker: Parallele Archivierung (ws, 2014-01-21) Ersetzen mit leeren Dokument vorteilhaft, da leicht implementierbar. MetadataUpdate nur für XDS, damit nicht Peer-übergreifend. FA-Manager sollte aber Peer-übergreifend invalidieren können. (jc, 2014-01-21) Beide Varianten erlauben? Welche Anforderungen gibt es an den FA-Manager. (ti, 2014-01-21) Nur Möglichkeit für Invalidierung für FAM. Wichtig aus Datenschutzsicht. (jc, 2014-01-21) Bedeutet Schreiben auf Fremd-Partition. Daher vertragliche Regelung notwendig. (ti, 2014-01-21) Stimmt. Problematisch, da jeder Rolle FAM ausfüllen könnte. Vorschlag: FAM je Provider derjenige, der die erste Partition der Akte beim Provider anlegt. Weiterhin mit leerem Dokument ersetzen. (jc, 2014-01-21) Vorschlag und Einigung: Vorschlag: Ersetzen MUSS erlaubt werden, Metadata-Update KANN zusätzlich erlaubt werden.(ti, 2014-01-21)

Kommentare

ID	Author	Status	Section	Vote	Existing	Proposed	Comment	Comment Editor	Discussion
189	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)
190	mk	captured	Eouns.01.02.02 : Fusion mit einer bestehenden Fallakte		Fusion mit einer bestehenden Fallakte Der EFA-Ressourcen-Manager prüft, ob - die EFA-Berechtigungsregel der bestehenden Fallakte den zugreifenden Arzt als Berechtigten auszeichnet. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen. - die Einwilligung für das Anlegen der Fallakte die Übernahme einer bestehenden Fallkte autorisiert. Wenn nicht, dann wird der Vorgang mit einer Fehlermeldung abgebrochen.		Eine Berechtigungsregel für den Arzt liegt nicht vor, da der Arzt sonst einfach in die bestehende Akte einstellen würde. (15.08.2014)
191	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
192	mk	postponed	Eouns.01.04 : Schließen einer Fallakte		Eine Fallakte im EFA-Verbund schließen Die Partitionen einer Fallakte können auf mehrere EFA-Provider verteilt sein. In diesem Fall schließt dieses Kommunikationsmuster lediglich die Partitionen, die in der Community des Arztes (also bei dessen EFA-Provider) geführt werden. Um die gesamte Fallakte zu schließen, müssen die restlichen teilnehmenden EFA-Provider benachrichtigt werden. Dieser Prozess unterliegt nicht der EFA-Spezifikation. Ein EFA-Verbund muss aber zumindest einen organisatorischen Prozess definieren.		Eine organisatorische Regelung ist nicht praktikabel. Wer soll den organisatorischen Prozess initiieren? Wer wird benachrichtigt? Wer ist für das Schließen der verteilten Partitionen verantwortlich? Das Vorgehen widerspricht außerdem dem Interaktionsmuster "Schließen einer Fallakte": "Der EFA-Provider leitet die Aufforderung zur Schließung der Akte an alle EFA-Provider weiter, bei denen Partitionen dieser Akte verwaltet werden. Diese leiten die Schließung der bei ihnen verwalteten Partitionen gemäß des Lebenszyklus einer EFA ein." (15.08.2014)	Derzeitig kann die Anforderung, dass die dezentral gespeicherten consentInfo-Dokumente invalidiert werden müssen, nur mit technisch hohem Aufwand (z. B. mit ITI DSUB) implementiert werden. Derzeitig treibt IHE das ITI-Profil XCDR voran, mit dem diese Anforderung leichter umgesetzt werden kann. Der Widerspruch zum Interaktionsmuster besteht nicht, da das Interaktionmuster den Prozess auf einer geschäftlichen Ebene beschreibt. (bk, 12.09.2014)
193	mk	postponed	Eouns.01.04 : Schließen einer Fallakte		Eine Fallakte im EFA-Verbund schließen Die Partitionen einer Fallakte können auf mehrere EFA-Provider verteilt sein. In diesem Fall schließt dieses Kommunikationsmuster lediglich die Partitionen, die in der Community des Arztes (also bei dessen EFA-Provider) geführt werden. Um die gesamte Fallakte zu schließen, müssen die restlichen teilnehmenden EFA-Provider benachrichtigt werden. Dieser Prozess unterliegt nicht der EFA-Spezifikation. Ein EFA-Verbund muss aber zumindest einen organisatorischen Prozess definieren.		Das Schließen einer verteilten Fallakte organisatorisch abzubilden ist unpraktikabel. (15.08.2014)	Richtig. Derzeitig kann die Anforderung, dass die dezentral gespeicherten consentInfo-Dokumente invalidiert werden müssen, nur mit technisch hohem Aufwand (z. B. mit ITI DSUB) implementiert werden. Derzeitig treibt IHE das ITI-Profil XCDR voran, mit dem diese Anforderung leichter umgesetzt werden kann. (bk, 12.09.2014)
194	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.
195	fo	included	Eouns.01.06 : Einstellen von Dokumenten		Objekte immer in Partition		kann man so machen
196	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.
197	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.
198	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.
199	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.
200	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.
201	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.
202	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).
203	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.
204	mk	rejected	Eouns.01.14 : Konsolidieren von Fallakten		Konsolidieren von Fallakten		Das beschriebene Registrierungsmuster / Synchronisierungsmuster ist auf die Verfügbarkeit aller beteiligten Systeme zum Zeitpunkt der Konsolidierung angewiesen. Das birgt die Gefahr von Fehlern und ggf. sogar Inkonsistenzen.	Der Aspekt Verfügbarkeit ist in der Spezifikation nicht verankert. Für die logischen Operationen der Spezifikation werden die erwarteten Ergebnisse der Transaktionen angegeben. Wenn diese nicht erfüllt werden können, zum Beispiels wenn die Kompensation von Ausfällen nicht möglich ist, ist das ein definierter Fehlerfall. Die Kompensations-Techniken für Verfügbarkeit können Produkt-spezifisch sein. (bk, 22.08.2014)
205	mk	included	Eouns.01.15 : Invalidieren eines Dokuments		Das EFA-Teilnehmersystem invalidiert ein Datenobjekt, indem es das Datenobjekt mit dem Invalidierungsdokument ersetzt. Es wird im IHE-D Cookbook definiert werden.		Wann steht die Definition zur Verfügung? (15.08.2014)	Die IHE-D-Cookbook-Gruppe ist hierzu auskunftsfähig. Als Zwischenlösung gilt: das inhaltsleere Dokument invalidiert ein ersetztes Dokument. (bk, 22.08.2014)
206	mk	postponed	Eouns.01.15 : Invalidieren eines Dokuments		Invalidieren eines Dokuments bei einem benachbarten EFA-Provider Das Dokument, Invalidierungsdokument und Dokument-Beziehung müssen beim selben EFA-Provider registriert sein. Der Grund ist, dass andernfalls die Invalidierung unerkannt bleibt, wenn der jeweilige benachbarte EFA-Provider zum Anfrage-Zeitpunkt nicht verfügbar ist. Das Invalidieren eines Dokuments bei einem benachbarten EFA-Provider kann technisch realisiert werden. Es muss zumindest ein organisatorischer Prozess aufgesetzt werden.		Wie erfolgt das technisch bzw. wie kann sichergestellt werden, dass das Invalidierungsdokument beim "richtigen" Provider eingestellt wird? Für den Benutzer ist das transparent, er kann also nicht eigenständig die Invalidierung sicherstellen und weiß ggf. nicht, was im Fehlerfall zu tun ist. (15.08.2014)	Richtig. Auf der logischen Ebene ist diese Annahme falsch, da die gesamtheitliche Sicht auf die Fallakte gewährleistet sein muss. Technisch kann das Invalidieren Peer-übergreifend derzeitig allerdings nicht umgesetzt werden, da folgende XDS-Einschränkung besteht: Original-Dokument, Ersetzendes-Dokument und Replace-Assoziation müssen in der gleichen Registry gespeichert werden. Derzeitig treibt IHE das ITI-Profil XCDR voran, ein Cross-Community-ITI-41. (bk, 12.09.2014)
207	mk	postponed	Eouns.01.15 : Invalidieren eines Dokuments		Invalidieren eines Dokuments bei einem benachbarten EFA-Provider Das Dokument, Invalidierungsdokument und Dokument-Beziehung müssen beim selben EFA-Provider registriert sein. Der Grund ist, dass andernfalls die Invalidierung unerkannt bleibt, wenn der jeweilige benachbarte EFA-Provider zum Anfrage-Zeitpunkt nicht verfügbar ist. Das Invalidieren eines Dokuments bei einem benachbarten EFA-Provider kann technisch realisiert werden. Es muss zumindest ein organisatorischer Prozess aufgesetzt werden.		Das Invalidieren ist unpraktikabel, wenn es nicht technisch für Patienten und Ärzte transparent erfolgt. (15.08.2014)	Richtig. Auf der logischen Ebene ist diese Annahme falsch, da die gesamtheitliche Sicht auf die Fallakte gewährleistet sein muss. Technisch kann das Invalidieren Peer-übergreifend derzeitig allerdings nicht umgesetzt werden, da folgende XDS-Einschränkung besteht: Original-Dokument, Ersetzendes-Dokument und Replace-Assoziation müssen in der gleichen Registry gespeichert werden. Derzeitig treibt IHE das ITI-Profil XCDR voran, ein Cross-Community-ITI-41. (bk, 12.09.2014)

Authors

Kürzel	Name	Organisation	E-Mail
fh	Frank Oemig	Agfa Healthcare
ti	Tarik Idris	InterComponentWare AG
mr	Michael Rübener	X-tension
sh	Salima Houta	Fraunhofer ISST
jc	Jörg Caumanns	Fraunhofer FOKUS
bk	Ben Kraufmann	Fraunhofer FOKUS
iw	Ingo Wolf	gematik
mk	Marcel Klötgen	CompuGroup Medical