cdaefa Diskussion:EFA XDS ResourceManager

Aus Hl7wiki
Version vom 13. Januar 2014, 16:36 Uhr von Jcaumanns (Diskussion | Beiträge) (Offene Change Requests)
Wechseln zu: Navigation, Suche

Offene Change Requests

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