cdaefa Diskussion:EFA XDS ResourceManager

Kommentierung

Author	Status	Section	Existing	Proposed	Comment	Comment Editor	Discussion
mr	rejected	EDesa.01 : EFA Resource Manager XDR/XDS Binding		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.	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.	Archivieren und Löschen sind keine Interaktionsmuster der Fallakte.
ti	included	EDesa.01 : EFA Resource Manager XDR/XDS Binding			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)	XDS statt XDR.
fo	included	EDesa.02 : EFA XDS/XDR Binding: createECR	eventCodes	codeList	Müsste das nicht in codeList gespeichert werden?	Korrigiert. (bk)
fo	postponed	EDesa.02 : EFA XDS/XDR Binding: createECR	The application of security measures and the contents of the SOAP security header are specified normatively		Das gehört in das Cookbook.	Hinweis auf Verschiebung ins Cookbook wurde in Einstiegsseite eingefügt. (bk)
ti	postponed	EDesa.02 : EFA XDS/XDR Binding: createECR			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)	Hier sind die consent-Documente gemeint. Diese sollten nicht per Referenz bereitgestellt werden. Wird im Zuge der Peer-to-Peer-Diskussion aber erneut betrachtet.	Mehrere Metadatensätze zu einem Dokument sollen erlaubt sein. Formulierung copy-by-reference unglücklich. Ein Metadatensatz darf nicht mehreren Fallakten zugeordnet sein. (ti)
bk	included	EDesa.02.01 : Constraints on the Request Message	SHOULD provide documents embraced by a single IHE XDS submission set		Diese Anforderung ist trivial und kann entfallen. ITI-41 fordert, dass Documents und Folders mit einem Submission Set assoziiert sind (siehe ITI-TF-3 Figure 4.1-1). Kommt mehrfach vor. (bk, 20.12.2013)	Die Anforderung wurde entfernt. (bk, 20.12.2013)
ti	included	EDesa.02.01 : Constraints on the Request Message			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)	Der EFA-Client soll Dokumente, die zum gleichen Zeitpunkt bereitgestellt werden, zu einem submission set zusammengefasst bereitstellen. Formulierung wurde angepasst. (bk)
ti	included	EDesa.02.01 : Constraints on the Request Message			"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)	Formulierung wurde angepasst. (bk)	MUST NOT aufweichen, submission set darf keine EFA-Semantik haben (ti)
ti	included	EDesa.02.01 : Constraints on the Request Message			"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)	Ja. Die Formulierung wurde angepasst. (bk)
fo	included	EDesa.02.02 : Expected Actions	translate the provided consentInfo document into an access control policy		Dafür brauchen wir aber die Entry Level Spezifikation von BPPC.	In cdaefa:EFA_Metadata_Bindings wird auf HL7 Consent Directives verwiesen. (bk)
mr	postponed	EDesa.02.02 : Expected Actions		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	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
ti	included	EDesa.02.02 : Expected Actions			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)	XDS
ti	postponed	EDesa.02.02 : Expected Actions			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)	Die Begriffe wurden vereinheitlicht, die Verwendung des Begriffs Efa Provider wurde aber noch nicht verfeinert. (bk)
ti	included	EDesa.02.02 : Expected Actions			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)	Formulierung wurde angepasst. (bk)	"modify consent" unklar, Abstimmung mit jc
ti	rejected	EDesa.02.02 : Expected Actions			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)	Das Document Repository ist Teil des EFA-Peers. (bk)
ti	rejected	EDesa.02.03 : Response Message (Full Success Scenario)			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)	Da "Processing deferred" nicht bedeutet, dass die Anfrage grundsätzlich abgelehnt wurde, soll hier nicht mit "Failure" geantwortet werden. (bk)
fo	postponed	EDesa.02.04 : Response Message (Failure or Partial Failure Scenario)	Fehlercodes		Hier wird es Zeit, Value Sets zu definieren, um nicht doppelte Informationen zu hinterlegen und zu pflegen…	Es wurde vereinbart, dass Value Sets im CTS2-Katalog des Fraunhofer FOKUS aufgenommen werden. Zusätzlich werden Value Sets mit dem Cookbook abgestimmt und gegebenenfalls dorthin verschoben. (bk)
ti	rejected	EDesa.02.04 : Response Message (Failure or Partial Failure Scenario)			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)	Am 18.10.2013 wurde vereinbart, dass das Bearer-Verfahren für die Authentifzierung zulässig ist. Die Response Message 4702 ist daher sinnvoll. (bk)
fo	postponed	EDesa.02.05 : Security Considerations			Dieser Abschnitt gehört in das Cookbook.	Hinweis auf Verschiebung ins Cookbook wurde in Einstiegsseite eingefügt. (bk)
ti	included	EDesa.02.05.02 : Audit Trail			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)	Link wurde eingefügt (bk)
ti	included	EDesa.02.05.02 : Audit Trail			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)	Entweder ATNA oder EFA-1.2-konformes Audit (dezentral), wird präzisiert
fo	included	EDesa.03 : EFA XDS/XDR Binding: createPartition	eventCodes	codeList	kommt mehrfach vor…	Korrigiert. (bk)
bk	included	Edesa.03.01 : Constraints on the Request Message			In den Abschnitten "Constraints on the request message" werden die Constraints auf ITI-41 wiederholt beschrieben. Diese sollten in einem einzigen Abschnitt gebündelt werden, um die Lesbarkeit zu erhöhen. (bk, 18.12.2013)	Auf der Seite XDR-Bindings wurde ein Abschnitt eingefügt, der die für EFA allgemeingültigen Einschränkungen auf ITI-41 spezifiziert. (bk, 18.12.2013)
ti	included	EDesa.03.04 : Response Message (Failure or Partial Failure Scenario)			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)	Für Anfragen, die die Consent-Policy verletzen, wurde der Fehler-Code "No Consent" aus epSOS eingeführt. (bk)
ti	rejected	EDesa.04.01 : Constraints on the Request Message			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)	Das consentInfo-Doc soll lediglich das Signal zum Schließen der Akte geben. Weitere Dokumente sollen eingestellt werden können, die z.B. das Schließen der Akte begründen. Die elektronische Kopie des Einwilligungsformulars ist im Zweifel ein Dokument, das vom EFA-Proder nicht als solches erkannt werden kann. (bk)	Dokumente sollten vor close bereits eingestellt sein. (ti)
fo	included	EDesa.05 : EFA XDS Binding: listPartitions	Therefore listing partitions corresponds to listing all accessible ECR-classified folders which are assigned to a given patient.		Hier muss der entsprechende Zweck berücksichtigt werden, da es vorkommen kann, dass ein Patient mehrere unterschiedliche Fallakten hat. (Das kommt aber später.)	Formulierung wurde angepasst. (bk)
ti	included	EDesa.05 : EFA XDS Binding: listPartitions			"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)	Vorschlag: "initial" streichen	Erschwert Umsetzung von Hybriden (ti)
ti	included	EDesa.05.01 : Constraints on the Request Message			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)	Constraints aus Tabelle und außerhalb der Tabelle zusammenführen
fo	included	EDesa.05.02 : Expected Actions	comly	comply
ti	included	EDesa.05.04 : Response Message (Failure or Partial Failure Scenario)			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)	Die "Action to be taken" für den Fall "patient unknown" wurde entfernt, da es sich hierbei nicht um eine Reaktion auf die Antwort handelt sondern um eine organisatorische Rahmenbedingung zum Einsatz der EFA handelt. Der tatsächliche Grund für "No-Data" wird damit in keinem Fall offenbart. (bk)
fo	rejected	EDesa.06.01 : Constraints on the Request Message	All provided documents SHALL ..		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.	Gemeint ist auch die gescannte Variante. Wesentlich für die Semantik der Transaktion ist das Vorhandensein des consentInfo-Docs. Im Zweifel werden nicht nur die elektronische Kopie des Einwilligungsformulars eingestellt, sondern auch Dokumente, die den Grund für registerConsent beschreiben. (bk)
ti	postponed	EDesa.06.02 : Expected Actions			"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)		purpose sollte wie abgestimmt zunächst nicht änderbar sein, könnte aber provider-spezifisch technisch auch anders umgesetzt werden (Neuanlage vs. Umschreibung). Ws: Änderung purpose tritt in der Praxis häufig auf und sollte im Aktenkonstrukt berücksichtigt sein. (ti) Diskussion nur IHE-spezifisch, Diskussion verschoben. (fo)