cdaefa Diskussion:EFA Business Informationsmodell
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
Statusinformationen sind immer an die gesamte Fallakte gebunden und werden von dieser an Partitionen und Dokumente vererbt. Von daher existiert kein explizites Status-Attribut für Partitionen.
verantwortliche Organisation
BnsIi.02.09: document
Verbot provider-übergreifender Dokument-Referenzen
Die Spezifikation enthält die Einschränkung, dass Dokumente nur dann in mehreren Partitionen referenziert sein können, wenn diese Partitionen beim selben Provider liegen. In der Konzeption der P2P-Vernetzung von Providern waren sog. Mount-Objekte vorgesehen, um u.a. dieses Szenario abzufangen. (fo,30.05.2013)
- Gegenkommentierung
- Mount-Objekte sollten lediglich Referenzen auf Partitionen sein. Grundsätzlich spricht nichts dagegen, diese auch als Vorwärts-Referenz auf Dokumente auszugestalten, aber ich habe etwas Sorge, dass wir uns damit eine ziemliche Komplexität einfangen, was die Synchronisierung dieser verteilten Objekte angeht.
- Vorschlag
- Mount-Objekte werden zunächst nur für Partitionen ausgearbeitet. Sie sollen aber so spezifiziert werden, dass zukünftig damit auch Referenzen auf beliebige Objekte verwaltet werden können. Eine konkrete Ausarbeitung für Dokumente erfolgt erst, wenn aus einem EFA-Netz ein entsprechender Bedarf mit einem sinnvollen Szenario hinterlegt werden kann. Ggf. kann man ja schon parallel mal die diversen Szenarien entlang des Lebenszyklus eines Dokuments durchspielen... (jc, 05.09.2013)
BnsIi.02.11: docMetadata
XDS entryUUID vs. XDS uniqueID
Bei der Document ID sollte bedacht werden, dass auf der XDS Ebene zwei unterschiedliche IDs für die Verknüpfung und das Abrufen zum Einsatz kommen: Die entryUUID für Verknüpfungen und die uniqueId für das Retrieval. (ti, 29.05.2013)
Das Mapping der documentID auf die XDS Dokument Metadaten wurde entsprechend korrigiert. (JC, 05.09.2013)
Zeitliche Einordnung
'Beim Element "Zeitliche Einordnung" sollte keine Vermischung mit dem nicht medizinisch relevantem Datum des Einstellens in die Fallakte gefordert werden. Wann das Dokument eingestellt wurde sollte immer mitgeführt werden (es wird im Moment auf der logischen Sicht kein Feld dafür definiert). Wenn der medizinisch relevante Zeitraum (effectiveTime) nicht bekannt ist, sollte er lieber leer bleiben. Ansonsten ist es für Clients nicht möglich zu unterscheiden ob der Zeitraum explizit angegeben wurde (und somit fach-relevant ist) oder es sich nur um einen default fallback Wert handelt, dem keine fachliche Bedeutung beizumessen ist. (ti, 29.05.2013)
Ein weiteres Attribut gemäß Kommentar wurde aufgenommen. Das Mapping der documentID auf die XDS Dokument Metadaten wurde entsprechend erweitert. (JC, 05.09.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 - mr
- Michael Rübener, X-tension
Michael.Ruebener@x-tention.at - ti
- Tarik Idris, InterComponentWare AG
tarik.idris@icw.de
