cdaefa Diskussion:EFA Business Informationsmodell: Unterschied zwischen den Versionen
(→Darstellung (Grafik)) |
(→Sender-does-it-Right-Semantik) |
||
Zeile 21: | Zeile 21: | ||
;Vorschlag | ;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) | + | :[[Datei:Si-vote.svg|32px]] 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 == | == BnsIi.02.02: purpose == |
Version vom 5. September 2013, 09:12 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)
Namenskürzel
- fo
- Dr. Frank Oemig, Agfa Healthcare
frank.oemig@agfa.com - jc
- Dr. Jörg Caumanns, Fraunhofer FOKUS
joerg.caumanns@fokus.fraunhofer.de - ti
- Tarik Idris, InterComponentWare AG
tarik.idris@icw.de