cdaefa Diskussion:EFA XDS ResourceManager
Change Log
- 02.11.15
- Umsetzung von CP-012-00 (Korrektur eines Tippfehlers in einem Beispiel)
Kommentare
| ID | Author | Status | Section | Vote | Existing | Proposed | Comment | Comment Editor | Discussion |
|---|---|---|---|---|---|---|---|---|---|
| 50 | 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. | |||
| 51 | 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. | ||||
| 52 | fo | included | EDesa.02 : EFA XDS/XDR Binding: createECR | eventCodes | codeList | Müsste das nicht in codeList gespeichert werden? | Korrigiert. (bk) | ||
| 53 | 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) | |||
| 54 | ti | included | 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) | Gemeint ist eine HasMember(4)-Assoziation mit SubmissionSetStatus=Reference. HasMember-Associationen erlauben nur die Referenzierung von Objekten, die in der gleichen community registriert sind (keine homeCommunityId). Daher kann der EFA-Provider leicht prüfen, ob Constraints eingehalten wurden. copy-by-reference wurde durch eine präzisiere Formulierung ersetzt. (bkr, 13.06.2014) | Mehrere Metadatensätze zu einem Dokument sollen erlaubt sein. Formulierung copy-by-reference unglücklich. Ein Metadatensatz darf nicht mehreren Fallakten zugeordnet sein. (ti) | |||
| 55 | 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) | |||
| 56 | 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) | ||||
| 57 | 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) | |||
| 58 | 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) | ||||
| 59 | 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) | |||
| 60 | mr | included | 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 | Das Kommunikationsmuster "Verteilen einer Einwillung" mit der Operation notifyOfConsent wurde hinzugefügt. (bkr, 13.06.2014) | |||
| 61 | 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 | ||||
| 62 | ti | included | 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. (bk) | ||||
| 63 | 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 | |||
| 64 | 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. In einem der ersten Treffen der 7er-Gruppe wurde festgelegt, den Sonderfall, dass ein EFA-Provider auch EFA-Client ist, nicht auszuführen, sondern immer davon auszugehen, dass es logisch zwei verschiedene Akteure sind. Damit ist das Repository immer dem Akteur "provider" zugeordnet (bk, jc) | ||||
| 65 | 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) | ||||
| 66 | 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) | |||
| 67 | 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) | ||||
| 68 | 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) | ||||
| 69 | 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) | ||||
| 70 | 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 | ||||
| 71 | fo | included | EDesa.03 : EFA XDS/XDR Binding: createPartition | eventCodes | codeList | kommt mehrfach vor… | Korrigiert. (bk) | ||
| 72 | 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) | ||||
| 73 | 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) | ||||
| 74 | 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) | |||
| 75 | 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) | |||
| 76 | 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) | |||
| 77 | 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 | ||||
| 78 | fo | included | EDesa.05.02 : Expected Actions | comly | comply | ||||
| 79 | 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) | ||||
| 80 | 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) | |||
| 81 | 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) | In die Spezifikation wird aufgenommen, dass das Überschreibern bzw. Erweitern eines Consent über die entsprechende Dokumentbeziehung expliziert werden muss (RPLC vs APND). Details werden zusammen mit dem Cookbook im Rahmen der finalen Ausgestaltung der Einwilligungsdokumentation festgelegt. |
| |||
| 82 | ti | included | EDesa.08 : EFA IHE-ITI-Binding: registerRecordLocation | Mount-Points können nicht auf XDSFolder abgebildet werden, da das Objekt sowohl die Community-eigene Patienten-ID als auch die fremde Patienten-ID enthalten muss. | Änderung: Mount-Points werden auf DocumentEntry abgebildet. Homecommunityid = id der entfernten community, sourcepatientid = patienten-id in der entf. Community. Ein Mount-Point-Code in der eventCode-List zeichnet das Objekt als Mount-Point aus. (bk, 12.09.2014) |
Authors
| Kürzel | Name | Organisation | |
|---|---|---|---|
| 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 |
