cdaefa Diskussion:EFA XDS ResourceManager

Offene Change Requests

Anlage leerer Partitionen (XDS Folder)

Hintergrund

In der Spezifikation wird die "createPartition" Operation auf die ITI-41 Transaktion abgebildet. Die von der Operation auszulösende Ordneranlage wird dabei implizit im Kontext des Einstellens eines Dokuments ausgeführt. Die Angabe eines Dokuments ist - in Abweichung zum SFM - verpflichtend. Motivation ist, dass IHE ITI-41 die Angabe eines Dokuments verlange.

Recherchen in den IHE Spezifikationen und eigene Test legen nahe, dass diese Behauptung falsch ist und dass IHE ITI-41 auch die Anlage von Ordnern ohne gleichzeitiges Einstellen eines Dokuments erlaubt. Dies wird gefolgert aus:

• ITI TF-3 Figure 4.1-1
• ITI TF-3 Section 4.1.1: “A SubmissionSet shall be the source of at least one Association of type HasMember (1), HasMember (3), and/or HasMember (4).” HasMember (1) ist die Folder-Assoziation.
• XDStarClient gibt keine Fehler bei Validierung aus (Test ausgeführt gegen den ITI-41 Konformanztest im Gazelle Testtool)

Empfehlung Editor

Die Einschränkung sollte gestrichen werden. Die Angabe eines Dokuments sollte analog zum SFM optional sein.

Kommentare

EDesa.01

Comment

Der einleitende Satz kündigt ein Mapping auf XDR an. XDR kennt nur Document Source und Document Recipient. Die anderen Akteure (Repository, Consumer, Registry) sind Teil von XDS. Dies deutet darauf hin, dass hier der Einsatz von XDS ggf. angebrachter wäre. (ti, 09.06.2013)

Author

ti

Comment Editor

XDS statt XDR.

EDesa.01

Comment

Mit dem Service closeECR werden die Partitionen einer eFA in den Status ‚grace‘ gesetzt, nach Ablauf der Grace-Periode ist die betroffene eFA zu archivieren und zu löschen. Dieser Service ist noch nicht beschrieben.

Author

mr

Proposed

Die EFA Resource Manager Services sollten um einen Dienst ‚archiveECR‘ erweitert werden welcher die eFA-Partitions archiviert und danach die XDS-Folder der betroffenen eFA löscht. Es existiert allerdings keine IHE-Transaktion um einen Folder zu löschen.

Comment Editor

policy regelt Lebenszeitraum der Dokumente

EDesa.02

Comment

Wie ist die Aussage "Documents cannot be copied by reference" zu verstehen? Geht es um das hinzufügen eines Dokuments per Assoziation mit Typ "Reference" (siehe Vol.3 4.1.4.1) in einem Submission Set? Oder geht es um das Hinzufügen eines existierenden Dokuments per Assoziation mit dem neu anzulegenden Folder (Vol.3 4.1.5)? Oder geht es um die Verknüpfung eines bestehenden Dokuments aus einem anderen Folder mit einem neuem Dokument per Assoziation (siehe Vol.3 4.1.6.1)? (ti, 07.06.2013)

Author

ti

Comment Editor

ti: Mehrere Metadatensätze zu einem Dokument sollen erlaubt sein. Formulierung copy-by-reference unglücklich. Ein Metadatensatz darf nicht mehreren Fallakten zugeordnet sein.

EDesa.02

Comment

Müsste das nicht in codeList gespeichert werden?

Author

fo

Existing

eventCodes

Proposed

codeList

EDesa.02

Comment

Das gehört in das Cookbook.

Author

fo

Existing

The application of security measures and the contents of the SOAP security header are specified

normatively

EDesa.02.01

Comment

Ist mit embrace "The requestor (EFA Client) SHOULD embrace the provided documents as a single IHE XDS submission set acc. to [IHE ITI TF-2a]." gemeint, dass alle Dokumente in einem einzigen SubmissionSet gesammelt werden sollen? (ti, 07.06.2013)

Author

ti

EDesa.02.01

Comment

"The EFA provider MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata and contents." Auch hierdurch wird die Umsetzung von Hybridsystemen unnötig erschwert. Auch wenn reine EFA Systeme das Submission Set nicht persistieren müssen, sollte es nicht verboten sein dies zu tun. Aus Interoperabilitätssicht spricht nichts dagegen wenn ein EFA Provider System das SubmissionSet speichert, solange sich dadurch das externe Verhalten nicht ändert. Aus Sicherheitssicht sollte einfach die Abfrage dieser Objekte nicht über EFA Schnittstellen möglich sein. (ti, 07.06.2013)

Author

ti

Comment Editor

MUST NOT aufweichen, ti: submission set darf keine EFA-Semantik haben

EDesa.02.01

Comment

"The EFA provider MUST NOT register documents that are only provided through associations." Geht es hier um Dokumente die nur per Referenz Assoziation (siehe Vol.3 4.1.4.1) in das SubmissionSet inkludiert wurden? (ti, 07.06.2013)

Author

ti

EDesa.02.02

Comment

Die unterschiedlichen Akteure und ihre Aufgaben erschliessen sich mir beim Lesen nicht. Es fängt an mit "The XDS Document Repository provider SHALL ...", dann kommt "The provider of the XDS Document Repository provider MUST ..." was ja auf ein versehentlich gedoppeltes Wort deutet. Aber dann geht es weiter mit "The ECR provider SHALL ..." während die Response dann vom "EFA Document Registry Service provider" (in {EDesa.02.03}) kommt. Hier wären 1. eine einheitliche Benennung und 2. ein Übersichtsbild hilfreich. (ti, 09.06.2013)

Author

ti

EDesa.02.02

Comment

Ist das Document Repository nicht (im Sinne einer dezentralen Datenspeicherung) Teil des EFA Clients? In dem Fall würde die Kommunikation zwischen Document Source und Document Repository interessanterweise eine interne Kommunikation des EFA Clients sein. (ti, 09.06.2013)

Author

ti

EDesa.02.02

Comment

Der Akteur XDR Document Repository existiert so nicht in IHE XDR. Es gibt nur einen XDR Document Recipient. Dies ist relevant, wenn es um die Möglichkeit des Abrufs eines Dokuments geht. Hierfür hat das XDS Document Repository eine Schnittstelle, der XDR Document Recipient aber nicht. (ti, 09.06.2013)

Author

ti

Comment Editor

XDS

EDesa.02.02

Comment

Wenn schon eine Fallakte mit gleichem Zweck existiert, soll auf das "modify consent" Recht geprüft werden. Wann dieses Recht festgelegt wird, wer das darf und wie es geändert werden kann erschliesst sich mir (noch) nicht. Ich vermute, das Ziel hier ist es eine einfache Ad-Hoc Berechtigung optional zu ermöglichen, in dem man einfach die gleiche Akte nochmal anlegt. Dies halte ich für sinnvoll, auch wenn dies noch viel klarer spezifiziert werden müsste. V.a. das Verhalten hinsichtlich des consent info Dokuments ist sehr unklar. Es wird initial davon gesprochen, dass es die consent info nur einmal geben darf. Am Ende des hier beschriebenen Prozesses gibt es aber (mindestens) zwei consent info Dokumente. Was vereinheitlich wird ist nur die access control policy, was mir fraglich erscheint, da es sich auf der XACML Ebene wahrscheinlich sowieso um mehr als ein Objekt (mehrere Policies mit vielen Rules) handelt. (ti, 09.06.2013)

Author

ti

Comment Editor

"modify consent" unklar, Abstimmung mit jc

EDesa.02.02

Comment

Dafür brauchen wir aber die Entry Level Spezifikation von BPPC.

Author

fo

Existing

translate the provided consentInfo document into an access control policy

Comment Editor

rb: auf eigenständige Spez. Verweisen

EDesa.02.02

Comment

In einem Peer-to-Peer Szenario müsste bei einer ‚Modify Consent‘-Operation der Patient-Consent auch in die verbundenen eFA-Peers weiter geleitet werden

Author

mr

Proposed

Die Anwendungsfälle einer Peer-to-Peer Konfiguration sind näher zu spezifizieren, speziell die Peer-übergreifende Berechtigungsverwaltung und die Verknüpfung von eFAs über Peer-Grenzen

EDesa.02.03

Comment

Ich würde als Reponse Status Type nicht Success erwarten, wenn die Anfrage nicht verarbeitet wurde (und somit die Fallakte auch noch nicht existiert, bzw. die Dokumente noch nicht registriert sind). "Processing deferred" ist ja auch keine Garantie, dass die Anlage zu einem späteren Zeitpunkt (d.h. nach der manuellen Intervention) nicht noch fehlschlägt. (ti, 09.06.2013)

Author

ti

EDesa.02.04

Comment

4702: In {ItyAn.01} wurde X509 als einziger erlaubter AuthContext festgelegt, daher sehe ich nicht ganz, wie diese Fehlermeldung auftreten sollte (ausser es handelt sich um eine Protokollverletzung, worauf der Benutzer ja kaum wie beschrieben reagieren kann. (ti, 09.06.2013)

Author

ti

EDesa.02.04

Comment

Hier wird es Zeit, Value Sets zu definieren, um nicht doppelte Informationen zu hinterlegen und zu pflegen…

Author

fo

Existing

Fehlercodes

EDesa.02.05

Comment

Dieser Abschnitt gehört in das Cookbook.

Author

fo

EDesa.02.05.02

Comment

Hier wäre es sicherlich hilfreich die EFA 1.2 Audit Trail Spezifikation zu verlinken. Wäre es nicht simpler diese Spezifikation, wenn sie keine Änderungen benötigt, einfach hochzuzählen (d.h. als EFA Audit Trail 2.0 neu herauszugeben)? (ti, 09.06.2013)

Author

ti

EDesa.02.05.02

Comment

Wie verhält sich die EFA Audit Anforderung zu den ebenso verpflichtenden Audit Anforderungen des IHE XDS Profils (bzw. XDR). Müssen clients und registry/repositor jeweils zweimal auditieren? (ti, 09.06.2013)

Author

ti

EDesa.03

Comment

kommt mehrfach vor…

Author

fo

Existing

eventCodes

Proposed

codeList

EDesa.03.04

Comment

Ich würde empfehlen, dass Fehler die durch den Benutzer durch unterscheidliche Aktionen korrigiert werden können auch unterschiedliche Error Codes erhalten. So kann der EFA Client den Benutzer ideal in der Korrektur des Fehlers unterstützen, ohne die Fehlerbeschreibung parsen zu müssen (wie es bei den 3 Fehlern mit code 4109 der Fall ist). (ti, 09.06.2013)

Author

ti

EDesa.04.01

Comment

Warum können hier ausser den consentInfo und consentDoc Dokumenten auch noch andere Dokumente eingestellt werden. Wäre es hier nicht sinnvoller darauf zu bestehen, dass diese Transaktion nur die dargestellten Dokumente beinhält. Wenn weitere Dokumente zum Abschluss notwendig sind, können diese ja durchaus vorher hochgeladen werden. (ti, 09.06.2013)

Author

ti

EDesa.05

Comment

"The initial query is restricted to folder metadata and does not return any data contained within that folders." Heisst initial, das immer zuerst diese Query gemacht werden muss? Muss die Registry prüfen was die "initiale" Query war (und somit pro Client den Zustand halten)? (ti, 09.06.2013)

Author

ti

EDesa.05

Comment

Hier muss der entsprechende Zweck berücksichtigt werden, da es vorkommen kann, dass ein Patient mehrere unterschiedliche Fallakten hat.

(Das kommt aber später.)

Author

fo

Existing

Therefore listing partitions corresponds to listing all

accessible ECR-classified folders which are assigned to a given patient.

EDesa.05.01

Comment

In der Tabelle klingt die purpose Einschränkung so, daß man nur nach einem spezifischen Grund fragen darf. In der Auflistung darunter wird es so dargestellt, dass man nur nach Fallakten fragen darf, aber nicht einen spezifischen Grund angeben muss. Welches ist korrekt? (ti, 09.06.2013)

Author

ti

EDesa.05.02

Author

fo

Existing

comly

Proposed

comply

EDesa.05.04

Comment

Die Action to be taken bei "No Data" macht wenig Sinn, wenn der Client die drei Fälle nicht unterscheiden kann. Soll er Sie unterscheiden können oder ist dies aus Datenschutzgründen abzulehnen (v.a. da man sonst abfragen könnte ob ein Patient mit ID X eine Fallakte mit Code Y hat). (ti, 09.06.2013)

Author

ti

EDesa.06.01

Comment

Gibt es nicht nur ein Consent Document? Oder ist hier dann auch die gescannte Variante gemeint?

Von daher muss es hier entweder ein oder zwei Dokumente geben. (Der nächste Punkt ist da etwas präziser.) Im Prinzip kann man danach auch andere Dokumente hochladen, dann dürfte es aber nicht mehr registerConsent heißen.

Author

fo

Existing

All provided documents SHALL ..

EDesa.06.02

Comment

"if the purpose is aligned by the new consent: change the eventList codes of all containers that are assigned to the eCR to the new purpose" heisst das man kann damit den Purpose ändern? "Aligned" ist da sehr zweideutig. Was passiert mit den alten consentInfo Dokumenten? Werden diese nicht invalidiert? Muss die register Nachricht eingentlich noch den alten Code in der Folder.codeList haben? Wenn ja, wie wird der neue code transportiert? Wenn nein, woher weiss der EFA Provider, dass es sich hier um eine Änderung des Zwecks handelt, da ja auch ein neu anzulegender Folder hierfür werden werden kann. Dabei darf man auch nicht ausser lassen, dass sich die Folder codeList ohne XDS Metadata Update nicht anpassen lässt. (ti, 09.06.2013)

Author

ti