cdaefa Diskussion:EFA Business Informationsmodell: Unterschied zwischen den Versionen
K (→Namenskürzel) |
K (→Darstellung (Grafik)) |
||
| Zeile 2: | Zeile 2: | ||
== BnsIi.01: EFA Business Informationsmodell == | == BnsIi.01: EFA Business Informationsmodell == | ||
| − | === Darstellung (Grafik) === | + | === [[Datei:Si-vote.svg|32px]] Darstellung (Grafik) === |
Welche Aktivität ist denn in der Grafik dazwischen geschoben? (fo, 31.05.2013) | Welche Aktivität ist denn in der Grafik dazwischen geschoben? (fo, 31.05.2013) | ||
| Zeile 9: | Zeile 9: | ||
;Vorschlag | ;Vorschlag | ||
| − | : | + | :Analog zu den detaillierteren Grafiken zu den einzelnen Klassen wird auch die Übersichtsgrafik als UML Klassenmodell dargestellt. |
== BnsIi.01.01: Patient == | == BnsIi.01.01: Patient == | ||
Version vom 5. September 2013, 11:55 Uhr
Inhaltsverzeichnis
BnsIi.01: EFA Business Informationsmodell
Darstellung (Grafik)
Welche Aktivität ist denn in der Grafik dazwischen geschoben? (fo, 31.05.2013)
- Gegenkommentar
- Die Grafik ist wenig selbsterklärend, da durch die Nutzung eines RMIM als Darstellung einige "Hilfsklassen" hinzukommen. (jc, 26.07.13)
- Vorschlag
- Analog zu den detaillierteren Grafiken zu den einzelnen Klassen wird auch die Übersichtsgrafik als UML Klassenmodell dargestellt.
BnsIi.01.01: Patient
Sender-does-it-Right-Semantik
Das muss genau genommen in das IHE-Cookbook. (fo, 31.05.2013)
- Gegenkommentar
- Wenn ein gemeinsames Verständnis zu dieser Semantik besteht, dann sollte das im Cookbook in dem Abschnitt zu MPI/PIX/PDQ näher ausgeführt werden. (jc, 04.09.2013)
- Vorschlag
- Zunächst keine Änderung an der EFA-Spezifikation. Sobald das Cookbook modularisiert ist, wird aus der EFA-Spezifikation ein Verwies auf die entsprechende Cookbook-Seite gesetzt. (jc, 04.09.2013)
BnsIi.02.02: purpose
Der Text ist redundant zum Cookbook. (fo, 31.05.2013)
- Vorschlag
- Zunächst keine Änderung an der EFA-Spezifikation. Sobald das Cookbook modularisiert ist, wird aus der EFA-Spezifikation ein Verwies auf die entsprechende Cookbook-Seite gesetzt. (jc, 04.09.2013)
BnsIi.02.04: consentInfo
Siehe den Kommentar unter {Peen.01.01} zur Notwendigkeit mehrerer Patientenzustimmungen. Die Einschränkung ist auch problematisch für den Umgang mit Peer-to-Peer Fallakten, bei denen es consentInfo Objekte in mehreren Affinity Domains gibt. Selbst wenn diese synchronisiert werden, handelt es sich um unterschiedliche Objekte, da sie auf unterschiedliche XAD-PIDs referenzieren. (ti, 29.05.2013)
BnsIi.02.07: partitionList
Um Peer-to-Peer Fallakten zu unterstützen, wäre hier eine Referenz auf den EFA Provider sinnvoll. (ti, 29.05.2013)
Siehe Beschreibung der PartitionID: Der Verweis auf den EFA Provider ist Bestandteil der PartitionID. (jc, 05.09.2013)
BnsIi.02.09: partitionInfo
Für folgende Partition-Metadaten existiert keine direkte Repräsentation in den XDS-Metadaten:
- Anfangsdatum
- Status (Seitens XDS ist hier nur ‚Approved‘ unterstützt, es würde aber zumindest noch ‚graced‘ benötigt)
- verantwortliche Organisation
(mr, 28.05.2013)
Anfangsdatum
Status
Der Status einer Fallakte und der daran gebundenen Partitionen wird über die aus der gültigen Einwilligung erzeugte Berechtigungspolicy abgebildet. Hierdurch ist keine explizite Verwaltung des Status in den Metadaten erforderlich. Da ein "normaler" Nutzer immer nur aktive Fallakten einsehen kann, soll der Status vom Clientsystem per default immer auf "offen" gesetzt werden.
verantwortliche Organisation
Namenskürzel
- fo
- Dr. Frank Oemig, Agfa Healthcare
frank.oemig@agfa.com - jc
- Dr. Jörg Caumanns, Fraunhofer FOKUS
joerg.caumanns@fokus.fraunhofer.de - mr
- Michael Rübener, X-tension
Michael.Ruebener@x-tention.at - ti
- Tarik Idris, InterComponentWare AG
tarik.idris@icw.de
