cdaefa Diskussion:EFA Anwendungsdienste (logische Spezifikation): Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „== {Enndn.01} == Die in den Beschreibungen der einzelnen Operationen beschriebenen Fehlerfälle enthalten viele Redundanzen zu der Seite [[cdaefa:EFA_Fehlermeldu…“)
 
 
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
== {Enndn.01} ==
+
= Kommentare =
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!ID
 +
!Author
 +
!Status
 +
!Section
 +
!Vote
 +
!Existing
 +
!Proposed
 +
!Comment
 +
!Comment Editor
 +
!Discussion
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|173
 +
|style="background-color: white;"|jc
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Enndn.01 : EFA Anwendungsarchitektur: Service Functional Model
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|Die gemeinsamen Fehlermeldungen sind jetzt auf einer EFA-Wiki-Seite gesammelt dargestellt. (bkr, 13.06.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|174
 +
|style="background-color: white;"|mr
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Enndn.01 : EFA Anwendungsarchitektur: Service Functional Model
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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.
 +
|style="background-color: white;"|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.
 +
|style="background-color: white;"|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.
 +
|style="background-color: white;"|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.
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|175
 +
|style="background-color: white;"|jc
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Enndn.01.01.01 : createECR
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Fallaktenmanager
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|In den Text wurde ein entsprechender Hinweis eingefügt.
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|176
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Enndn.01.01.01 : createECR
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|"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)
 +
|style="background-color: white;"|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.
 +
|style="background-color: white;"|Für neue Partition muss consent erweitert werden, Additive consents, Klärung des Partitionsbegriffs vs. Folderbegriff (ti)
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|177
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Enndn.01.03.01 : provideData
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|Kommentar bezog sich auf eine veraltete Fassung der Spezifikation, die versehendlich verlinkt wurde....
 +
|style="background-color: white;"|
 +
|}
  
−
Die in den Beschreibungen der einzelnen Operationen beschriebenen Fehlerfälle enthalten viele Redundanzen zu der Seite [[cdaefa:EFA_Fehlermeldungen_und_Warnungen|Fehlermeldungen und Warnung]]. 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 [[cdaefa:EFA_Fehlermeldungen_und_Warnungen|Fehlermeldungen und Warnung]] 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 [[cdaefa:EFA_Fehlermeldungen_und_Warnungen|Fehlermeldungen und Warnung]] hinaus in das Cookbook gezogen werden. (jc, 27.04.13)
+
= Authors =
−
 
+
{|class="wikitable" style="text-align: left; cellpadding: 10;"
−
== Namenskürzel ==
+
!Kürzel
−
 
+
!Name
−
;jc
+
!Organisation
−
:[[Benutzer:Jcaumanns|Dr. Jörg Caumanns]], Fraunhofer FOKUS<br>joerg.caumanns@fokus.fraunhofer.de
+
!E-Mail
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|fh
 +
        |style="background-color: white;"|Frank Oemig
 +
        |style="background-color: white;"|Agfa Healthcare
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|ti
 +
        |style="background-color: white;"|Tarik Idris
 +
        |style="background-color: white;"|InterComponentWare AG
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|mr
 +
        |style="background-color: white;"|Michael Rübener
 +
        |style="background-color: white;"|X-tension
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|sh
 +
        |style="background-color: white;"|Salima Houta
 +
        |style="background-color: white;"|Fraunhofer ISST
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|jc
 +
        |style="background-color: white;"|Jörg Caumanns
 +
        |style="background-color: white;"|Fraunhofer FOKUS
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|bk
 +
        |style="background-color: white;"|Ben Kraufmann
 +
        |style="background-color: white;"|Fraunhofer FOKUS
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|iw
 +
        |style="background-color: white;"|Ingo Wolf
 +
        |style="background-color: white;"|gematik
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|mk
 +
        |style="background-color: white;"|Marcel Klötgen
 +
        |style="background-color: white;"|CompuGroup Medical
 +
|}

Aktuelle Version vom 16. September 2014, 12:24 Uhr

Kommentare

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....

Authors

Kürzel Name Organisation E-Mail
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
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa_Diskussion:EFA_Anwendungsdienste_(logische_Spezifikation)&oldid=20374“