| ID
|
Author
|
Status
|
Section
|
Vote
|
Existing
|
Proposed
|
Comment
|
Comment Editor
|
Discussion
|
| 173
|
jc
|
included
|
Enndn.01 : EFA Anwendungsarchitektur: Service Functional Model
|
|
|
|
Die in den Beschreibungen der einzelnen Operationen beschriebenen Fehlerfälle enthalten viele Redundanzen zu der Seite Fehlermeldungen und Warnungen. Idealerweise sollen in den Tabellen zu den Operationen nur noch die für diese Operation spezifischen Fehler benannt werden und alle anderen Fehler auf der Seite Fehlermeldungen und Warnungen beschrieben werden. Hierdurch kann man dann auch zu einer sauberen "Fehlerhierarchie" mit dem IHE-Cookbook kommen, indem perspektivisch für alle Aktentypen mögliche Fehlerfälle sogar aus der Seite Fehlermeldungen und Warnungen hinaus in das Cookbook gezogen werden. (jc, 27.04.13)
|
Die gemeinsamen Fehlermeldungen sind jetzt auf einer EFA-Wiki-Seite gesammelt dargestellt. (bkr, 13.06.2014)
|
|
| 174
|
mr
|
included
|
Enndn.01 : EFA Anwendungsarchitektur: Service Functional Model
|
|
|
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.
|
Bei dem in der Diskussion bevorzugten Vorschlag eines expliziten Ordner-Status wurde nicht berücksichtigt, dass dann ein Ordner immer nur zu einer EFA gehören kann. In den Diskussionen wurde diese Einschränkung als nach Möglichkeit zu vermeiden charakterisiert. Von daher sollte der Status implizit über die Rechte ausgedrückt werden. Dies schließt nicht aus, dass ein Provider intern Stati verwalet und diese in der Policy berücksichtigt. In der Spezifikation wird daher nur noch von einem "internen Status" gesprochen.
|
Abbildung des Statusmodells explizit als Metadatum von Ordnern vs. Implizit in XACML Policies.
Status: optionales Metadatum von Ordnern. Falls Statusmetadatum von EFA Provider Implementierung genutzt wird, kann die Policy im Rahmen von Gültigkeitsprüfungen auf dieses Metadatum verweisen. Status als CodeList von Ordnern.
|
| 175
|
jc
|
included
|
Enndn.01.01.01 : createECR
|
|
Fallaktenmanager
|
|
Der Fallaktenmanager kann über diese Operation nicht festgelegt werden, da die Belegung dieser Rolle eine Vereinbarung der Teilnehmer ist und nicht durch den Patienten verändert werden kann. (jc, 26.07.2013)
|
In den Text wurde ein entsprechender Hinweis eingefügt.
|
|
| 176
|
ti
|
included
|
Enndn.01.01.01 : createECR
|
|
|
|
"Sofern bereits eine Fallakte zu dem benannten Zweck existiert, wird keine neue Akte angelegt, sondern stattdessen die bestehende Akte um eine Partition und die neu hinzu kommenden Behandlungsteilnehmer erweitert." Dies scheint im Widerspruch zu {Eouns.01.02.02} zu stehen, wo beschrieben wird, dass die neue Einwilligung die alte ersetzt, d.h. es handelt sich um einen neuen "Snapshot" der Teilnehmer, nicht wie hier beschrieben ein Hinzufügen der bisher nicht geführten Teilnehmer. Um die Ad-Hoc Autorisierung durch eine zusätzliche Einwilligung (bei Fallaktenidentifikation über ein identifizierendes Offline Token) zu unterstützen, ist der hier beschriebene Mechanismus der additiven Einwilligung vorzuziehen. Dafür müsste die Einschränkung aus der referenzierten (logischen) Transaktion, dass der anlegende Teilnehmer auf die schon vorhandene Akte autorisiert ist, ausser Kraft gesetzt werden. (ti, 31.05.2013)
|
In den Diskusionen zum P2P Szenario wurde festgelegt, dass es immer einen Basis-Consent und optional zusätzliche additive Consents gint. Bei der bschriebenen Aktenzusammenführung gäbe es 2 Basis-Constent, was unzulässig wäre. Von daher ist das in den Kommunikationsmustern aufgezeigte Vorgehen der Übernahme der neuen Einwilligung auch in Richtung P2P konsistenter. Der Text hier wurde entsprechend angepasst.
|
Für neue Partition muss consent erweitert werden, Additive consents, Klärung des Partitionsbegriffs vs. Folderbegriff (ti)
|
| 177
|
ti
|
included
|
Enndn.01.03.01 : provideData
|
|
|
|
Die auf diesen Abschnitt folgenden Abschnitte wiederholen nur die schon gelisteten Operationen und haben keinen Kommentierungscode. Die folgenden Abschnitte bis zu {Eierz.01} sollten wahrscheinlich gelöscht werden. (ti, 31.05.2013)
|
Kommentar bezog sich auf eine veraltete Fassung der Spezifikation, die versehendlich verlinkt wurde....
|
|
