cdaefa Diskussion:EFA Geschäftsobjekte: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Empfehlung des Editors)
 
(8 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
+
= Change Requests =
= Offene Change Requests =
+
{|class="wikitable" style="text-align: left; cellpadding: 10;"
== Unterscheidung von "Muss"- und "Kann"-Informationen ==
+
!ID
=== Hintergrund ===
+
!Requester
Der "Ärztliche Beirat zur Begleitung des Aufbaus einer Telematikinfrastruktur für das Gesundheitswesen in
+
!Status
Nordrhein-Westfalen" hat Ende 2013 eine Reihe von Anforderungen an die einrichtungsübergreifende elektronische Fallakte (eFA) formuliert. Eine dieser Empfehlungen betrifft die Klassifizierung von Partitionen:
+
!Section
 
+
!Change Request
 +
!Recommendation Editor
 +
!Discussion
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|6
 +
        |style="background-color: white;"|-
 +
        |style="background-color: #E77471;"|rejected
 +
        |style="background-color: white;"|Eehä.01 : Hierarchisches Informationsmodell der EFA
 +
        |style="background-color: white;"|'''Unterscheidung von Muss- und Kann-Informationen:'''
 +
Der "Ärztliche Beirat zur Begleitung des Aufbaus einer Telematikinfrastruktur für das Gesundheitswesen in Nordrhein-Westfalen" hat Ende 2013 eine Reihe von Anforderungen an die einrichtungsübergreifende elektronische Fallakte (eFA) formuliert. Eine dieser Empfehlungen betrifft die Klassifizierung von Partitionen:  
 
''Die Informationen der eFA müssen sowohl zeitnah als auch sicher umgesetzt werden. Hierzu sind insbesondere die Bestimmungen des § 630f, 1 BGB (Patientenrechtegesetz) zu beachten. Dazu müssen die für die Behandlung obligatorischen Einträge von fakultativen Einträgen unterschieden werden. Die obligatorischen Einträge werden in der Partition 1 abgelegt. Diese enthält alle notwendigen Informationen, um medizinische Entscheidungen sicher treffen zu können. In der Partition 2 werden alle übrigen - die fakultativen - Einträge abgelegt. Beide Partitionen müssen durch Suchroutinen sicher und schnell durchgesehen werden können.''
 
''Die Informationen der eFA müssen sowohl zeitnah als auch sicher umgesetzt werden. Hierzu sind insbesondere die Bestimmungen des § 630f, 1 BGB (Patientenrechtegesetz) zu beachten. Dazu müssen die für die Behandlung obligatorischen Einträge von fakultativen Einträgen unterschieden werden. Die obligatorischen Einträge werden in der Partition 1 abgelegt. Diese enthält alle notwendigen Informationen, um medizinische Entscheidungen sicher treffen zu können. In der Partition 2 werden alle übrigen - die fakultativen - Einträge abgelegt. Beide Partitionen müssen durch Suchroutinen sicher und schnell durchgesehen werden können.''
 
+
        |style="background-color: white;"|Der Change Request sollte abgelehnt werden, da die praktische Umsetzbarkeit nicht ersichtlich ist und die haftungsrechtlichen Implikationen nicht abschließend bewertet werden können.
=== Diskussion ===
+
        |style="background-color: white;"|
Ein ähnlicher Vorschlag wurde schon einmal im Rahmen der eFAv1.2 Spezifikation diskutiert. Sowohl seitens des beteiligten Anwalts als auch seitens der Klinikvertreter wurde es als kritisch angesehen, dass der Daten in eine Akte einstellende Arzt eine Klassifizierung dieser Daten vornimmt, die potenziell dazu führt, dass andere Nutzer diese Daten nicht in dem aus ihrem Kontext angemessenen Maße würdigen. Dies gilt umso mehr, wenn Ärzte verschiedener Fachdisziplinen über eine EFA kooperieren. Hier sollten die Ärzte nicht gezwungen werden, festzulegen, welche Informationen für einen Arzt einer anderen Fachdisziplin obligatorisch sind und welche nicht.
+
* Ein ähnlicher Vorschlag wurde schon einmal im Rahmen der eFAv1.2 Spezifikation diskutiert. Sowohl seitens des beteiligten Anwalts als auch seitens der Klinikvertreter wurde es als kritisch angesehen, dass der Daten in eine Akte einstellende Arzt eine Klassifizierung dieser Daten vornimmt, die potenziell dazu führt, dass andere Nutzer diese Daten nicht in dem aus ihrem Kontext angemessenen Maße würdigen. Dies gilt umso mehr, wenn Ärzte verschiedener Fachdisziplinen über eine EFA kooperieren. Hier sollten die Ärzte nicht gezwungen werden, festzulegen, welche Informationen für einen Arzt einer anderen Fachdisziplin obligatorisch sind und welche nicht. (jc)
 
+
* So, wie das dargestellt ist, bietet es sich an, derartige Markierungen über Ordner zu realisieren. Damit käme zu der bisherigen Liste von kombinierbaren Flags weitere Einträge hinzu: "Dokumente mit obligatorischen Informationen" und "Dokumente mit fakultativen Informationen". (fo)
=== Empfehlung des Editors ===
+
* Abbildung über Relationship-Objekte möglich (jc, 2014-01-21)
Der Change Request sollte abgelehnt werden, da die praktische Umsetzbarkeit nicht ersichtlich ist und die haftungsrechtlichen Implikationen nicht abschließend bewertet werden können.
+
* Für Akzeptanz wichtig. Informationen sollten nicht Metadaten liegen, sondern in Dokumente.(ws, 2014-01-21)
 +
* Partitionierung: 1) Hauptinformationen, 2) Ergänzende Informationen (ma, 2014-01-21)
 +
* Arzt in der Pflicht. Wie unterscheidet dieser, dass Informationen nicht wichtig waren? (ti, 2014-01-21)
 +
* Fragestellung: was ist relevant? (ws, 2014-01-21)
 +
* Vorschlag: Spec sollte mechanismus erlauben, Dokumente zu markieren. Jedes EFA-Projekt kann selbst entscheiden. (ti, 2014-01-21)
 +
* Wie klassifiziert man dann bei fremden Akten? Unterscheidung muss organisationsbezogen sein. Diese Vereinbarung könnte als Dokument in die Akte eingstellt werden. (ws, 2014-01-21)
 +
* Einigung: Einschätzungen sollen in Dokument festgehalten werden. Ergänzend können die IHE-Relationsships verwenden werden. (jc, 2014-01-21)
 +
|}
  
 
= Kommentare =
 
= Kommentare =
== [[Datei:Si-reject.svg|32px]] Eehä.01: Hierarchisches Informationsmodell der EFA ==
+
{|class="wikitable" style="text-align: left; cellpadding: 10;"
Vierstufiges Informationsmodell: Wo bleiben da die "Ordner"? (fo, 30.05.2013)
+
!ID
 
+
!Author
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)
+
!Status
 
+
!Section
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)
+
!Vote
 
+
!Existing
== [[Datei:Under_construction_icon-blue.svg|confirm.svg|32px]] Eehä.01.01: Klasse Patient ==
+
!Proposed
IHE-ACS-Domäne: Das muss erklärt werden. (fo, 30.05.2013)
+
!Comment
 
+
!Comment Editor
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)
+
!Discussion
 
+
       
== Eehä.01.02.01: Verteilung von Fallakten über mehrere EFA-Provider ==
+
|- style="vertical-align:top;"
 
+
|style="background-color: white;"|120
=== [[Datei:Si-reconc.svg|32px]] Zusammenführung von bei verschiedenen Providern angelegten Fallakten ===
+
|style="background-color: white;"|fo
 
+
|style="background-color: #C2DFFF;"|postponed
''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)
+
|style="background-color: white;"|Eehä.01 : Hierarchisches Informationsmodell der EFA
 
+
        |style="background-color: white;"|
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)
+
|style="background-color: white;"|passendsten Begriff "Partition"
 
+
|style="background-color: white;"|
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)
+
|style="background-color: white;"|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".)
 
+
An dieser Stelle fällt auf, dass XCA benötigt wird und dringend im Cookbook beschrieben werden muss, ansonsten kommt man mit dem Begriff Partition auch nicht klar!
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)
+
|style="background-color: white;"|Insbesondere in XCA-Szenarien hat man soviele verschiedene Konstrukte auf der logischen und technsichen Ebene (die auch nicht zwingend immer 1:1 korrelieren), dass man Gedanken über geeignete deutsche Begrifflichkeiten machen sollte, die auch überladene Begriffe wie z.B. "Ordner" vermeiden. Dies ist aber keine Aufgabe der EFA, sondern eher des Cookbooks (EFA sollte dann die abgestimmten Begrifflichkeiten übernehmen).
 
+
|style="background-color: white;"|
== Eehä.01.03: Klasse Partition ==
+
       
 
+
|- style="vertical-align:top;"
=== Semantik von Partitionen (1) ===
+
|style="background-color: white;"|121
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)
+
|style="background-color: white;"|fo
 
+
|style="background-color: #E77471;"|rejected
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)
+
|style="background-color: white;"|Eehä.01 : Hierarchisches Informationsmodell der EFA
 
+
        |style="background-color: white;"|
=== Semantik von Partitionen (2) ===
+
|style="background-color: white;"|vierstufiges Informationsmodell
"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)
+
|style="background-color: white;"|
 
+
|style="background-color: white;"|Wo bleiben da die "Ordner"?
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)
+
|style="background-color: white;"|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)
 
+
|style="background-color: white;"|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)
=== 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)
+
|- style="vertical-align:top;"
 
+
|style="background-color: white;"|122
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)
+
|style="background-color: white;"|fo
 
+
|style="background-color: #E77471;"|rejected
=== [[Datei:Si-reject.svg|32px]] Begriff "Partition" ===
+
|style="background-color: white;"|Eehä.01 : Hierarchisches Informationsmodell der EFA  
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)
+
        |style="background-color: white;"|
 
+
|style="background-color: white;"|
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)
+
|style="background-color: white;"|
 
+
|style="background-color: white;"|Wir müssen hier nochmal diese Grundlagen explizit darstellen! Also, was brauchen wir logisch zum Arbeiten und wie wird es technisch dargestellt!? In der Community fehlt nach wie vor das Bewusstsein, dass eine Kommunikation IMMER über das ISO-Schichtenmodell läuft. Es geht nicht ohne. (Das wird bspw. auch in der realen Kommunikation zwischen Menschen gemacht, nur wird das nicht explizit dargestellt.) Diese Aspekte laufen auf eine klare Trennung der Ebenen 5 bis 7 hinaus. Vielleicht sollte die Zuordnung von logischen Ordnern und Dokumenten auf Ebene 7 mit der Umsetzung in technischen Objekten auf Ebene 5 mal aufgemalt werden? Dann wird auch klar, dass wir auf Ebene 7 unterschiedliche Objekte haben, die dann auf dieselben Objekte in Ebene 5 gemappt werden, so dass für die bijektive Abbildung dann Zusatzattribute bemüht werden müssen! (fo, 20.01.14)
== [[Datei:Attention_icon.svg|32px]][[Datei:Si-confirm.svg|32px]] Eehä.01.04: Klasse Datenobjekt ==
+
|style="background-color: white;"|Abstraktionsschichten für die Spezifikation wurden mithilfe der ECCF-Matrix eingezogen. Das OSI-Schichtenmodell ist in der Spezifikation nicht unmittelbar relevant, da nur Aspekte auf der Anwendungsebene (HTTP und darüber) berührt werden. (bkr, 13.06.2014)
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)
+
|style="background-color: white;"|
 
+
       
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)
+
|- style="vertical-align:top;"
 
+
|style="background-color: white;"|123
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 [[cdaefa:EFA_Business_Informationsmodell#docRelationship|Dokumenten-Beziehungen]] wurden entsprechend korrigiert.
+
|style="background-color: white;"|fo
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.01 : Klasse Patient
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|IHE-ACS-Domäne
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Das muss erklärt werden.
 +
|style="background-color: white;"|Das im White Paper "Access Control" definierte Domänenmodell wird auf einer gesonderten Seite beschrieben, da dieses doch an mehreren Stellen referenziert wird. (jc, 08.09.2013)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|124
 +
|style="background-color: white;"|sh
 +
|style="background-color: #E77471;"|rejected
 +
|style="background-color: white;"|Eehä.01.02 : Klasse Fallakte
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Der der Fallakte zugrunde liegende medizinische Fall
 +
|style="background-color: white;"|Der, der Fallakte
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Gemäß Duden ist die Zeichensetzung hier zulässig
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|125
 +
|style="background-color: white;"|mk
 +
|style="background-color: #C2DFFF;"|postponed
 +
|style="background-color: white;"|Eehä.01.02.01
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"| Wenn Aktenteile zusammengeführt werden sollen, die bei verschiedenen Providern geführt werden, muss für die Aktenteile eine Einwilligung des Patienten vorliegen, die das Zusammenführen erlaubt.  
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Was unterscheidet Einwilligungen, die ein Zusammenführen erlauben, von anderen Einwilligungen? (15.08.2014)
 +
|style="background-color: white;"|Zusammenführen von Fallakten ist bei der Modellierung der Einwilligung aktuell nicht berücksichtigt. Hierfür sind weitere Abstimmungen mit dem IHE-D-Cookbook nötig. (bk, 22.08.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|126
 +
|style="background-color: white;"|fo
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|als Partition hinzugefügt
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|An dieser Stelle wird wieder nicht klar, was mit Partition gemeint genau gemeint ist.
 +
|style="background-color: white;"|Verweis auf Definition "Partition" eingefügt. (jc, 15.11.2013)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|127
 +
|style="background-color: white;"|fo
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Essentials
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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-Pont unbedingt darauf hingewiesen werden, dass eine Zusammenführung durchzuführen ist.
 +
|style="background-color: white;"|Richtig. Absatz wurde entsprechend geändert (jc, 16.11.2013)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|128
 +
|style="background-color: white;"|fo
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Abfrage anderer Provider
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Es ist sicherlich nicht möglich alle zu bennen.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.
 +
|style="background-color: white;"|Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)
 +
|style="background-color: white;"|Jeder Peer verwaltet Mount-Points zu den Aktenteilen anderer Peers. Es wurden Operationen hinzugefügt (listRecordLocations, registerRecordLocation), mit denen Mount-Point abgefragt und registriert werden können. (bkr, 13.06.2014)
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|129
 +
|style="background-color: white;"|sh
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|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).
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Ist dies organisatorisch realistisch? Existiert ein zentraler Verzeichnisdienst für alle Provider? Werden Verzeichnisdienste synchronisiert? Ist ein Leistungserbringer Teilnehmer bei mehreren Providern?
 +
|style="background-color: white;"|Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)
 +
Der Punkt 4 wurde in seiner Formulierung abgeschwächt. Die für das Zusammenführen von Fallakten benötigte Einwilligung des Patienten muss nicht weitergeleitet werden, aber auf den beiden Peers, dessen Aktenteile zusammengeführt werden, vorliegen. Mit dem Offline-Token-Szenario ist das: Token ausstellen und Token einlösen. Ein zentraler Verzeichnisdienst und dergleichen werden nicht benötigt. (bkr, 13.06.2014)
 +
|style="background-color: white;"|Ich gehe davon aus. (fo, 20.01.14)
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|130
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)
 +
Der Punkt 4 wurde in seiner Formulierung abgeschwächt. Die für das Zusammenführen von Fallakten benötigte Einwilligung des Patienten muss nicht weitergeleitet werden, aber auf den beiden Peers, dessen Aktenteile zusammengeführt werden, vorliegen. Mit dem Offline-Token-Szenario ist das: Token ausstellen und Token einlösen. (bkr, 13.06.2014)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|131
 +
|style="background-color: white;"|fo
 +
|style="background-color: #E77471;"|rejected
 +
|style="background-color: white;"|Eehä.01.03 : Klasse Partition
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Partition
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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.
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|132
 +
|style="background-color: white;"|fo
 +
|style="background-color: #E77471;"|rejected
 +
|style="background-color: white;"|Eehä.01.03 : Klasse Partition
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Partition verbergen
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|"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.
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|133
 +
|style="background-color: white;"|sh
 +
|style="background-color: #E77471;"|rejected
 +
|style="background-color: white;"|Eehä.01.03 : Klasse Partition
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|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.
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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.
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|134
 +
|style="background-color: white;"|sh
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.04 : Klasse Datenobjekt
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Datenobjekte können zueinander in Beziehung stehen. Diese Beziehungen werden explizit festgelegt und sind für EFA-Teilnehmer sichtbar. Die folgenden Beziehungen zwischen Datenobjekten werden von der EFA v.20 unterstützt:
 +
|style="background-color: white;"|EFA v 2.0
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|135
 +
|style="background-color: white;"|sh
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.04 : Klasse Datenobjekt
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Ein Dokument stellte eine Ergänzung eines anderen Dokuments dar (z.B. Befund zum Bild).
 +
|style="background-color: white;"|Ein Dokument stellt eine
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|136
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.04 : Klasse Datenobjekt
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|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 [[cdaefa:EFA_Business_Informationsmodell#docRelationship|Dokumenten-Beziehungen]] wurden entsprechend korrigiert.
 +
|style="background-color: white;"|ok (fo, 20.01.14)
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|137
 +
|style="background-color: white;"|ti
 +
|style="background-color: #89C35C;"|included
 +
|style="background-color: white;"|Eehä.01.04 : Klasse Datenobjekt
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|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)
 +
|style="background-color: white;"|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 [[cdaefa:EFA_Business_Informationsmodell#docRelationship|Dokumenten-Beziehungen]] wurden entsprechend korrigiert.
 +
|style="background-color: white;"|ok (fo, 20.01.14)
 +
       
 +
|- style="vertical-align:top;"
 +
|style="background-color: white;"|138
 +
|style="background-color: white;"|mk
 +
|style="background-color: #E77471;"|rejected
 +
|style="background-color: white;"|Eehä.01.04 : Klasse Datenobjekt
 +
        |style="background-color: white;"|
 +
|style="background-color: white;"|Das ersetzte Dokument wird (einschließlich seiner Ergänzungen/Anhänge) invalidiert und beim Abruf von Dokumenten aus einer Fallakte nur für bestimmte Rolleninhaber (z.B. Fallaktenmanager) bereitgestellt.
 +
|style="background-color: white;"|
 +
|style="background-color: white;"|Widerspricht dem Grundsatz "jeder sieht alles". (15.08.2014)
 +
|style="background-color: white;"|Jeder EFA-Teilnehmer soll den aktuellen Stand der Fallakte vollständig sehen können. Ersetzte Dokumente enthalten aktualisierte oder falsche Informationen, die vom EFA-Teilnehmer nicht mehr berücksichtigt werden dürfen und folglich ersetzt wurden. Ersetzte Dokumente können dabei anhand ihrer uniqueID immer noch von jedem Berechtigten durch Verfolgen der Dokumentbeziehungen abgerufen werden (bk, 22.08.2014)
 +
|style="background-color: white;"|
 +
|}
  
== Namenskürzel ==
+
= Authors =
;fo
+
{|class="wikitable" style="text-align: left; cellpadding: 10;"
:[[Benutzer:Foemig|Dr. Frank Oemig]], Agfa Healthcare<br>frank.oemig@agfa.com
+
!Kürzel
;jc
+
!Name
:[[Benutzer:Jcaumanns|Dr. Jörg Caumanns]], Fraunhofer FOKUS<br>joerg.caumanns@fokus.fraunhofer.de
+
!Organisation
;sh
+
!E-Mail
:[[Benutzer:Shouta|Salima Houta]], Fraunhofer ISST<br>salima.houta@isst.fraunhofer.de
+
       
;ti
+
        |- style="vertical-align:top;"
: [[Benutzer:Tidris|Tarik Idris]], InterComponentWare AG<br>tarik.idris@icw.de
+
        |style="background-color: white;"|fh
 +
        |style="background-color: white;"|Frank Oemig
 +
        |style="background-color: white;"|Agfa Healthcare
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|ti
 +
        |style="background-color: white;"|Tarik Idris
 +
        |style="background-color: white;"|InterComponentWare AG
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|mr
 +
        |style="background-color: white;"|Michael Rübener
 +
        |style="background-color: white;"|X-tension
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|sh
 +
        |style="background-color: white;"|Salima Houta
 +
        |style="background-color: white;"|Fraunhofer ISST
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|jc
 +
        |style="background-color: white;"|Jörg Caumanns
 +
        |style="background-color: white;"|Fraunhofer FOKUS
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|bk
 +
        |style="background-color: white;"|Ben Kraufmann
 +
        |style="background-color: white;"|Fraunhofer FOKUS
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|iw
 +
        |style="background-color: white;"|Ingo Wolf
 +
        |style="background-color: white;"|gematik
 +
       
 +
        |- style="vertical-align:top;"
 +
        |style="background-color: white;"|mk
 +
        |style="background-color: white;"|Marcel Klötgen
 +
        |style="background-color: white;"|CompuGroup Medical
 +
|}

Aktuelle Version vom 16. September 2014, 11:49 Uhr

Change Requests

ID Requester Status Section Change Request Recommendation Editor Discussion
6 - rejected Eehä.01 : Hierarchisches Informationsmodell der EFA Unterscheidung von Muss- und Kann-Informationen:

Der "Ärztliche Beirat zur Begleitung des Aufbaus einer Telematikinfrastruktur für das Gesundheitswesen in Nordrhein-Westfalen" hat Ende 2013 eine Reihe von Anforderungen an die einrichtungsübergreifende elektronische Fallakte (eFA) formuliert. Eine dieser Empfehlungen betrifft die Klassifizierung von Partitionen: Die Informationen der eFA müssen sowohl zeitnah als auch sicher umgesetzt werden. Hierzu sind insbesondere die Bestimmungen des § 630f, 1 BGB (Patientenrechtegesetz) zu beachten. Dazu müssen die für die Behandlung obligatorischen Einträge von fakultativen Einträgen unterschieden werden. Die obligatorischen Einträge werden in der Partition 1 abgelegt. Diese enthält alle notwendigen Informationen, um medizinische Entscheidungen sicher treffen zu können. In der Partition 2 werden alle übrigen - die fakultativen - Einträge abgelegt. Beide Partitionen müssen durch Suchroutinen sicher und schnell durchgesehen werden können.

Der Change Request sollte abgelehnt werden, da die praktische Umsetzbarkeit nicht ersichtlich ist und die haftungsrechtlichen Implikationen nicht abschließend bewertet werden können.
  • Ein ähnlicher Vorschlag wurde schon einmal im Rahmen der eFAv1.2 Spezifikation diskutiert. Sowohl seitens des beteiligten Anwalts als auch seitens der Klinikvertreter wurde es als kritisch angesehen, dass der Daten in eine Akte einstellende Arzt eine Klassifizierung dieser Daten vornimmt, die potenziell dazu führt, dass andere Nutzer diese Daten nicht in dem aus ihrem Kontext angemessenen Maße würdigen. Dies gilt umso mehr, wenn Ärzte verschiedener Fachdisziplinen über eine EFA kooperieren. Hier sollten die Ärzte nicht gezwungen werden, festzulegen, welche Informationen für einen Arzt einer anderen Fachdisziplin obligatorisch sind und welche nicht. (jc)
  • So, wie das dargestellt ist, bietet es sich an, derartige Markierungen über Ordner zu realisieren. Damit käme zu der bisherigen Liste von kombinierbaren Flags weitere Einträge hinzu: "Dokumente mit obligatorischen Informationen" und "Dokumente mit fakultativen Informationen". (fo)
  • Abbildung über Relationship-Objekte möglich (jc, 2014-01-21)
  • Für Akzeptanz wichtig. Informationen sollten nicht Metadaten liegen, sondern in Dokumente.(ws, 2014-01-21)
  • Partitionierung: 1) Hauptinformationen, 2) Ergänzende Informationen (ma, 2014-01-21)
  • Arzt in der Pflicht. Wie unterscheidet dieser, dass Informationen nicht wichtig waren? (ti, 2014-01-21)
  • Fragestellung: was ist relevant? (ws, 2014-01-21)
  • Vorschlag: Spec sollte mechanismus erlauben, Dokumente zu markieren. Jedes EFA-Projekt kann selbst entscheiden. (ti, 2014-01-21)
  • Wie klassifiziert man dann bei fremden Akten? Unterscheidung muss organisationsbezogen sein. Diese Vereinbarung könnte als Dokument in die Akte eingstellt werden. (ws, 2014-01-21)
  • Einigung: Einschätzungen sollen in Dokument festgehalten werden. Ergänzend können die IHE-Relationsships verwenden werden. (jc, 2014-01-21)

Kommentare

ID Author Status Section Vote Existing Proposed Comment Comment Editor Discussion
120 fo postponed Eehä.01 : Hierarchisches Informationsmodell der EFA passendsten Begriff "Partition" 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".)

An dieser Stelle fällt auf, dass XCA benötigt wird und dringend im Cookbook beschrieben werden muss, ansonsten kommt man mit dem Begriff Partition auch nicht klar!

Insbesondere in XCA-Szenarien hat man soviele verschiedene Konstrukte auf der logischen und technsichen Ebene (die auch nicht zwingend immer 1:1 korrelieren), dass man Gedanken über geeignete deutsche Begrifflichkeiten machen sollte, die auch überladene Begriffe wie z.B. "Ordner" vermeiden. Dies ist aber keine Aufgabe der EFA, sondern eher des Cookbooks (EFA sollte dann die abgestimmten Begrifflichkeiten übernehmen).
121 fo rejected Eehä.01 : Hierarchisches Informationsmodell der EFA vierstufiges Informationsmodell Wo bleiben da die "Ordner"? 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) 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)
122 fo rejected Eehä.01 : Hierarchisches Informationsmodell der EFA Wir müssen hier nochmal diese Grundlagen explizit darstellen! Also, was brauchen wir logisch zum Arbeiten und wie wird es technisch dargestellt!? In der Community fehlt nach wie vor das Bewusstsein, dass eine Kommunikation IMMER über das ISO-Schichtenmodell läuft. Es geht nicht ohne. (Das wird bspw. auch in der realen Kommunikation zwischen Menschen gemacht, nur wird das nicht explizit dargestellt.) Diese Aspekte laufen auf eine klare Trennung der Ebenen 5 bis 7 hinaus. Vielleicht sollte die Zuordnung von logischen Ordnern und Dokumenten auf Ebene 7 mit der Umsetzung in technischen Objekten auf Ebene 5 mal aufgemalt werden? Dann wird auch klar, dass wir auf Ebene 7 unterschiedliche Objekte haben, die dann auf dieselben Objekte in Ebene 5 gemappt werden, so dass für die bijektive Abbildung dann Zusatzattribute bemüht werden müssen! (fo, 20.01.14) Abstraktionsschichten für die Spezifikation wurden mithilfe der ECCF-Matrix eingezogen. Das OSI-Schichtenmodell ist in der Spezifikation nicht unmittelbar relevant, da nur Aspekte auf der Anwendungsebene (HTTP und darüber) berührt werden. (bkr, 13.06.2014)
123 fo included Eehä.01.01 : Klasse Patient IHE-ACS-Domäne Das muss erklärt werden. Das im White Paper "Access Control" definierte Domänenmodell wird auf einer gesonderten Seite beschrieben, da dieses doch an mehreren Stellen referenziert wird. (jc, 08.09.2013)
124 sh rejected Eehä.01.02 : Klasse Fallakte Der der Fallakte zugrunde liegende medizinische Fall Der, der Fallakte Gemäß Duden ist die Zeichensetzung hier zulässig
125 mk postponed Eehä.01.02.01 Wenn Aktenteile zusammengeführt werden sollen, die bei verschiedenen Providern geführt werden, muss für die Aktenteile eine Einwilligung des Patienten vorliegen, die das Zusammenführen erlaubt. Was unterscheidet Einwilligungen, die ein Zusammenführen erlauben, von anderen Einwilligungen? (15.08.2014) Zusammenführen von Fallakten ist bei der Modellierung der Einwilligung aktuell nicht berücksichtigt. Hierfür sind weitere Abstimmungen mit dem IHE-D-Cookbook nötig. (bk, 22.08.2014)
126 fo included Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider als Partition hinzugefügt An dieser Stelle wird wieder nicht klar, was mit Partition gemeint genau gemeint ist. Verweis auf Definition "Partition" eingefügt. (jc, 15.11.2013)
127 fo included Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider Essentials 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-Pont unbedingt darauf hingewiesen werden, dass eine Zusammenführung durchzuführen ist.

Richtig. Absatz wurde entsprechend geändert (jc, 16.11.2013)
128 fo included Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider Abfrage anderer Provider Es ist sicherlich nicht möglich alle zu bennen.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. Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013) Jeder Peer verwaltet Mount-Points zu den Aktenteilen anderer Peers. Es wurden Operationen hinzugefügt (listRecordLocations, registerRecordLocation), mit denen Mount-Point abgefragt und registriert werden können. (bkr, 13.06.2014)
129 sh included Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider 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? Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)

Der Punkt 4 wurde in seiner Formulierung abgeschwächt. Die für das Zusammenführen von Fallakten benötigte Einwilligung des Patienten muss nicht weitergeleitet werden, aber auf den beiden Peers, dessen Aktenteile zusammengeführt werden, vorliegen. Mit dem Offline-Token-Szenario ist das: Token ausstellen und Token einlösen. Ein zentraler Verzeichnisdienst und dergleichen werden nicht benötigt. (bkr, 13.06.2014)

Ich gehe davon aus. (fo, 20.01.14)
130 ti included Eehä.01.02.01 : Verteilung von Fallakten über mehrere EFA-Provider 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) Der Kommentar wird im Rahmen der Spezifikation der P2P-EFA aufgegriffen. (jc, 15.11.2013)

Der Punkt 4 wurde in seiner Formulierung abgeschwächt. Die für das Zusammenführen von Fallakten benötigte Einwilligung des Patienten muss nicht weitergeleitet werden, aber auf den beiden Peers, dessen Aktenteile zusammengeführt werden, vorliegen. Mit dem Offline-Token-Szenario ist das: Token ausstellen und Token einlösen. (bkr, 13.06.2014)

131 fo rejected Eehä.01.03 : Klasse Partition 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. 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)
132 fo rejected Eehä.01.03 : Klasse Partition Partition verbergen "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. 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)
133 sh rejected Eehä.01.03 : Klasse Partition 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. 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. 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)
134 sh included Eehä.01.04 : Klasse Datenobjekt Datenobjekte können zueinander in Beziehung stehen. Diese Beziehungen werden explizit festgelegt und sind für EFA-Teilnehmer sichtbar. Die folgenden Beziehungen zwischen Datenobjekten werden von der EFA v.20 unterstützt: EFA v 2.0
135 sh included Eehä.01.04 : Klasse Datenobjekt Ein Dokument stellte eine Ergänzung eines anderen Dokuments dar (z.B. Befund zum Bild). Ein Dokument stellt eine
136 ti included 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 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. ok (fo, 20.01.14)
137 ti included Eehä.01.04 : Klasse Datenobjekt 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. ok (fo, 20.01.14)
138 mk rejected Eehä.01.04 : Klasse Datenobjekt Das ersetzte Dokument wird (einschließlich seiner Ergänzungen/Anhänge) invalidiert und beim Abruf von Dokumenten aus einer Fallakte nur für bestimmte Rolleninhaber (z.B. Fallaktenmanager) bereitgestellt. Widerspricht dem Grundsatz "jeder sieht alles". (15.08.2014) Jeder EFA-Teilnehmer soll den aktuellen Stand der Fallakte vollständig sehen können. Ersetzte Dokumente enthalten aktualisierte oder falsche Informationen, die vom EFA-Teilnehmer nicht mehr berücksichtigt werden dürfen und folglich ersetzt wurden. Ersetzte Dokumente können dabei anhand ihrer uniqueID immer noch von jedem Berechtigten durch Verfolgen der Dokumentbeziehungen abgerufen werden (bk, 22.08.2014)

Authors

Kürzel Name Organisation E-Mail
fh Frank Oemig Agfa Healthcare
ti Tarik Idris InterComponentWare AG
mr Michael Rübener X-tension
sh Salima Houta Fraunhofer ISST
jc Jörg Caumanns Fraunhofer FOKUS
bk Ben Kraufmann Fraunhofer FOKUS
iw Ingo Wolf gematik
mk Marcel Klötgen CompuGroup Medical