IG Diskussion:EFA Spezifikation v2.0 - Versionsgeschichte

Tidris am 9. Juni 2013 um 18:43 Uhr

2013-06-09T18:43:55Z

2013-06-09T17:50:58Z

2013-06-09T17:41:35Z

2013-06-09T17:31:13Z

2013-06-09T17:07:26Z

2013-06-09T16:51:25Z

2013-06-09T16:36:36Z

2013-06-09T16:25:10Z

2013-06-09T16:07:16Z

2013-06-09T15:55:04Z

@@ Zeile 271: / Zeile 271: @@
 '''Wie sollen eigentlich Dokumentenersetzungen realisiert werden? Die folgenden Einschränkungen scheinen Assoziationen zu einem bestehendem Dokument praktisch auszuschliessen: "The EFA provider SHOULD ignore this grouping and MUST ignore all associations between documents and submission sets." (also auch Assoziationen zwischen 2 Dokumenten, oder ist dies nur eine sprachliche Ungenauigkeit?) sowie "Documents to be stored and registered SHALL be included with the request. The EFA provider MUST NOT register documents that are only provided through metadata and/or associations." (man kann somit kein existierendes Dokument per RPLC Assoziation ersetzen, da es dann nicht "provided" wäre). (ti, 09.06.2013)'''
+== {EXoce.02.04} ==
 == Namenskürzel ==

← Nächstältere Version		Version vom 9. Juni 2013, 17:50 Uhr
Zeile 268:		Zeile 268:
	'''Werden reine ID Abfragen (d.h. returnType = ObjectRef) unterstützt? Im Moment wird dies nicht ausgeschlossen. Das kann auch ein sinnvoller Mechanismus sein, um zu prüfen ob seit Beginn der Session neue Dokumente hinzugefügt wurden. (ti, 09.06.2013)'''		'''Werden reine ID Abfragen (d.h. returnType = ObjectRef) unterstützt? Im Moment wird dies nicht ausgeschlossen. Das kann auch ein sinnvoller Mechanismus sein, um zu prüfen ob seit Beginn der Session neue Dokumente hinzugefügt wurden. (ti, 09.06.2013)'''

−		+	== {EXoce.02.01} ==
		+	'''Wie sollen eigentlich Dokumentenersetzungen realisiert werden? Die folgenden Einschränkungen scheinen Assoziationen zu einem bestehendem Dokument praktisch auszuschliessen: "The EFA provider SHOULD ignore this grouping and MUST ignore all associations between documents and submission sets." (also auch Assoziationen zwischen 2 Dokumenten, oder ist dies nur eine sprachliche Ungenauigkeit?) sowie "Documents to be stored and registered SHALL be included with the request. The EFA provider MUST NOT register documents that are only provided through metadata and/or associations." (man kann somit kein existierendes Dokument per RPLC Assoziation ersetzen, da es dann nicht "provided" wäre). (ti, 09.06.2013)'''

@@ Zeile 262: / Zeile 262: @@
 == {EDcui.02.02} ==
 RegisterDocumentSet nicht ProvideAndRegister (ti, 09.06.2013)
 == Namenskürzel ==

@@ Zeile 259: / Zeile 259: @@
 == {EDesa.06.02} ==
 '''"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)'''
 == Namenskürzel ==

@@ Zeile 253: / Zeile 253: @@
 == {EDesa.05.01} ==
 '''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)'''
 == Namenskürzel ==

@@ Zeile 247: / Zeile 247: @@
 == {EDesa.04.01} ==
 '''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)'''
 == Namenskürzel ==

@@ Zeile 244: / Zeile 244: @@
 == {EDesa.03.04} ==
 '''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)'''
 == Namenskürzel ==

← Nächstältere Version		Version vom 9. Juni 2013, 16:07 Uhr
Zeile 236:		Zeile 236:
	== {EDesa.02.04} ==		== {EDesa.02.04} ==
	'''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)'''		'''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)'''
		+
		+	== {EDesa.02.05.02} ==
		+	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)
		+
		+	'''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)'''

@@ Zeile 233: / Zeile 233: @@
 == {EDesa.02.03} ==
 '''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)'''
 == Namenskürzel ==