cdaefa Diskussion:EFA Business Informationsmodell

Offene Change Requests

Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte

Hintergrund

Der Gültigkeitszeitraum ist in der Einwilligung festgehalten und wird über die consentdoc Datenstruktur übermittelt. Dies wird in der Spezifikation nur am Rande erwähnt und spiegelt sich vor allem auch nicht im logischen Informationsmodell wider.

Empfehlung Editor

Es sollte in die Elemente "ecrInfo" und "consentInfo" des logischen Informationsmodells ein Attribut "Gültigkeitsdauer" aufgenommen werden. Bei der Darstellung der Abbildung dieses Attributs auf IHE XDS Metadaten (Kapitel IHE XD* Binding) muss entsprechend erwähnt werden, dass dieses Attribut verpflichtend über die Einwilligung kommuniziert wird, die konkrete Umsetzung der Verwaltung der Gültigkeit von Akten beim Provider aber der Implementierung überlassen ist. Eine Option hierbei ist, dieses Datum über die aus der Einwilligung generierte Berechtigungspolicy abzubilden.

Ausformulieren des Informationsmodells einer Einwilligung

Hintergrund

Der Inhalt einer Einwilligung wird nur informell beschrieben und es wird für die Details auf ein Domain Analysis Modell verwiesen. Dieses Modell ist jedoch auf der konzeptionellen Ebene anzusiedeln und stellt kein logisches Informationsmodell dar. Es fehlt in der Spezifikation somit eine konkretere logische Darstellung des Informationsmodells einer Einwilligung in dem die im Kapitel Patienteneinwilligung zur EFA beschriebenen Inhalte einer Einwilligung geeignet formalisiert werden.

Empfehlung Editor

Der Change Request sollte umgesetzt und ein aus den Inhalten des Kapitels Patienteneinwilligung zur EFA abgeleitetes Informationsmodell angegeben werden.

Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen

Hintergrund

In der EFA-Spezifikation wird in Bezug auf die technische Umsetzung der Einwilligung lediglich auf eine unfertige Spezifikation im HL7-Wiki verwiesen. Es ist unklar, wie es hier weitergeht.

Empfehlung Editor

Es sollte ein Hinweis eingefügt werden, dass mit dem bvitg und dem Cookbook-Team vereinbart wurde, die aktuelle HL7 (Draft) Spezifikation zum Patient Consent geeignet anzupassen und zu verwenden. Die entsprechenden Arbeiten werden gemeinsam unter dem Dach des Interoperabilitätsforums durchgeführt.

Kommentare

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:

1. Anfangsdatum
2. Status (Seitens XDS ist hier nur ‚Approved‘ unterstützt, es würde aber zumindest noch ‚graced‘ benötigt)
3. verantwortliche Organisation

(mr, 28.05.2013)

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.

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 fachlich relevant ist) oder es sich nur um einen default fallback Wert handelt, dem keine fachliche Bedeutung beizumessen ist. (ti, 29.05.2013)

In der logischen Spezifikation der Dokument-Metadaten wurde das bisherige Attribut "zeitliche Einordnung" in das Datum der Bereitstellung des Dokuments sowie den im Dokument erfassten Behandlungszeitraum differenziert. Hierdurch ist jetzt sowohl eine Suche nach neuen Dokumenten als auch eine zeitliche Sortierung von Dokumenten entlang des Behandlungsverlaufs möglich. (JC, 05.09.2013)

BnsIi.02.12: docRelationship

Ein Ersetzen (Replace Assoziation) in XDS bewirkt immer eine Invalidierung (d.h. "availabilityStatus=Deprecated"). Dies betrifft übrigens nicht nur das Original Dokument, sondern auch seine Addenda! (ti, 29.05.2013)

Ein entsprechender Hinweis zur Semantik der Invalidierung wurde aufgenommen. (jc, 05.09.2013)

In der konzeptuellen Spezifikation der Beziehungen zwischen Datenobjekten wurden "ersetzen" und "aktualisieren" gleichgesetzt. Daher musste die logische Spezifikation entsprechend angepasst werden. (jc, 05.09.2013)

BnsIi.02.12: documentID

Die Beziehung zwischen der Klasse documentID und dem Attribut documentID der Klasse documentMetadata ist unklar. Wird die Klasse documentID in der Klasse documentMetadata verwendet oder ist sie als davon unabhängiges logisches Objekt zu sehen? (ti, 29.05.2013)

In der Tabelle zu den Dokument-Metadaten klar gestellt, dass die ID eines Dokuments eine Instanz der Klasse documentID ist. In der Mapping.Tabelle XDSDocument.repositoryUniqueID als Bestandteil der Umsetzung der logischen documentID in XDS hinzugefügt.

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