cdaefa Diskussion:EFA Geschäftsobjekte

Eehä.01: Hierarchisches Informationsmodell der EFA

Vierstufiges Informationsmodell: Wo bleiben da die "Ordner"? (fo, 30.05.2013)

An dieser Stelle werden die verschiedenen möglichen Arten von Ordnern (technisch, logisch) wieder in einen Topf geschmissen. (Das gleiche passiert auch sehr häufig mit "Dokumenten".) (fo, 30.05.2013)

Der Begriff "Ordner" ist bei EFAv1.2 schon überladen und durch das XDS-Binding kommt eine weitere Semantik hinzu. Eine Erklärung der Begrifflichkeiten wurde als Infobox hinzugefügt. In der gesamten Spec wurde versucht, diese Begriffe einheitlich zu verwenden: technisch = "Partition" vs. logisch = "Ordner". (jc, 08.09.2013)

Eehä.01.01: Klasse Patient

IHE-ACS-Domäne: Das muss erklärt werden. (fo, 30.05.2013)

Das im White Paper "Access Control" definierte Domänenmodell sollte auf einer gesonderten Seite beschrieben werden, da dieses doch an mehreren Stellen referenziert wird. (jc, 08.09.2013)

Eehä.01.02.01: Verteilung von Fallakten über mehrere EFA-Provider

Zusammenführung von bei verschiedenen Providern angelegten Fallakten

Um so verteilte, parallel existierende Akten zusammenzuführen, bedarf es der Einwilligung des Patienten, die dieser gegenüber einem Arzt geben muss, der Zugriff auf beide Akten hat (ggf. muss durch eine Änderung der Einwilligung zu einer der Akten dieser Zustand zunächst hergestellt werden). Ist dies organisatorisch realistisch? Existiert ein zentraler Verzeichnisdienst für alle Provider? Werden Verzeichnisdienste synchronisiert? Ist ein Leistungserbringer Teilnehmer bei mehreren Providern? (sh, 24.04.2013)

Der hier beschriebene Mechanismus für verteilte Fallakten scheint (v.a. von Punkt 4 an) signifikant vom in der 7er Gruppe abgestimmten Vorschlag abzuweichen. (ti, 28.05.2013)

Abfrage anderer Provider: Es ist sicherlich nicht möglich alle zu kennen.Es kann auch nicht jeder Provider abgefragt werden. Abgesehen von Performancegründen macht das auch wenig Sinn. Es sollte aber berücksichtigt werden, dass ein Patient kommt und klar sagt, dass er bei einem anderen Provider bereits eine Akte hat. (fo, 30.05.2013)

Ein Essential logischer Natur ist die Anforderung, dass es nur eine Fallakte für einen medizinischen Fall geben sollte. Hier wird diese Anforderung klar unterlaufen und das Ziel als solches ausgehebelt. Dann sollte im dritten Bullet-Point unbedingt darauf hingewiesen werden, dass eine Zusammenführung durchzuführen ist. (fo, 30.05.2013)

Eehä.01.03: Klasse Partition

Semantik von Partitionen (1)

Die konkrete Semantik einer Partition ist bei der EFA weitgehend frei definierbar, wodurch sie an beliebige bestehende Strukturierungsmechanismen gebunden werden kann. Somit kann eine Fallakte im einfachsten Szenario aus nur einer einzigen Partition bestehen, in die alle EFA-relevanten Daten eingestellt werden. (sh, 24.04.2013)

Ja. Da die Strukturierung der Daten für den Nutzer dynamisch anhand der Metadaten erfolgt, spricht nichts dagegen, alle Daten einer EFA auch in einer einzelnen Partition zu sammeln. Die Neu-Anlage einer Partition mach nur Sinn, wenn dies zu einer Vereinfachung beim Einstellen der Daten führt oder wenn eine Gruppierung von Daten erfolgen soll, die durch die definierten Metadaten nicht beschreibbar ist. (jc, 08.09.2013)

Semantik von Partitionen (2)

"Ordner" stellen ein Konstrukt zur Strukturierung der Akte dar, insbesondere wenn viele Objekte eingestellt wurden. Für reine Verwaltungsaufgaben sollten diese nicht verwendet werden, da man davon ausgehen kann, dass jedes System "weiß", welche Objekte es eingestellt hat. (fo, 30.05.2013)

Die Semantik und Nutzung des Konstrukts einer "Partition" ist absichtlich vage definiert, da letzten Endes nur konkrete Nutzungserfahrungen Aufschluss geben können, welche Empfehlungen als "best practice" in die Spezifikation einfließen sollten. (jc, 08.09.2013)

EFA Basisdaten

Existiert das Konstrukt Basisdaten in der EFA 2.0 nicht mehr? Gemäß alter Spezifikation wäre dies ja eine Partition, die in jeder EFA vorhanden sein muss und z. B. die Patienteneinwilligung speichert. (sh, 24.04.2013)

An dieser Stelle wurden in EFAv1.2 logische Elemente (Basisdaten) und technische Repräsentation (eigene Partition) vermischt. In EFAv2.0 soll das logische Konstrukt von Basisdaten unabhängig von seiner technischen Umsetzung sein. (jc, 08.09.2013)

Begriff "Partition"

Eine UNIX-Partition erlaubt noch mehrere Ordner. Von daher oktruiert dieses Bild wieder die Verteilung auf mehrere Provider, was hier aber mal nicht gemeint ist. Stattdessen muss man hier "logische Ordner" annehmen. Der Begriff der Partition führt nur zur Konfusion, solange er unterschiedlich genutzt wird. (fo, 30.05.2013)

Beim selben Provider für die selbe Fallakte angelegte Partitionen können (bei Überladung des Begriffs "Ordner") als "logische Ordner" angesehen werden. Wenn die Default-Semantik jedoch - wie im Text beschrieben - die Spiegelung der Daten einer Episode aus dem KIS/PVS eines EFA-Teilnehmers ist, so passt das Bild einer "Partition" wieder. (jc, 08.09.2013)

Eehä.01.04: Klasse Datenobjekt

Das Aktualisieren eines Dokuments ist in XDS nicht wie hier beschrieben vorgesehen. XDS kennt die Beziehungen "replace", "addendum", "transform" und "transform+replace". Die "replace" Beziehung bewirkt immer ein "deprecated" setzen des alten Dokuments. Es gibt über XDS Metadata Update die Möglichkeit die Metadaten zu aktualisieren, aber nicht die Document uniqueId, d.h. die referenzierten Binärdaten. Ausserdem gilt auch hier: "At any point in time there shall be at most one version of a logical DocumentEntry object with status Approved in the registry/recipient. If this version exists it shall always be the most recent version." (Metadata Update Supplement rev 1.2, line 623-625). Ich würde vorschlagen keine Unterscheidung zwischen Aktualisierung und Ersetzen zu machen. Änderungen am Dokument sollten immer als "replace" aufgefasst werden. Ich halte es nicht für notwendig den Client entscheiden zu lassen ob eine Ersetzung das alte Dokument invalidieren soll. (ti, 28.05.2013)

In späteren Teilen des Dokuments (v.a. {CiteD.01.03}) wird die Unterscheidung zwischen Aktualisieren und Ersetzen auch nicht mehr gemacht. (ti, 28.05.2013)

In der 7er-Gruppe wurde das Invalidieren durch Ersetzen mit einem leeren Dokument definiert. Leider ist diese Semantik hier mit dem Ersetzen "überlagert" worden. Diese Seite sowie auch die logische Spezifikation der Dokumenten-Beziehungen wurden entsprechend korrigiert.

Namenskürzel

fo

Dr. Frank Oemig, Agfa Healthcare
frank.oemig@agfa.com

jc

Dr. Jörg Caumanns, Fraunhofer FOKUS
joerg.caumanns@fokus.fraunhofer.de

sh

Salima Houta, Fraunhofer ISST
salima.houta@isst.fraunhofer.de

ti

Tarik Idris, InterComponentWare AG
tarik.idris@icw.de