cdaefa Diskussion:Patienteneinwilligung zur EFA: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 13: Zeile 13:
 
          
 
          
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
−
|style="background-color: white;"|2
+
|style="background-color: white;"|251
−
|style="background-color: white;"|fo
 
−
|style="background-color: #89C35C;"|included
 
−
|style="background-color: white;"|BnsIi.01 : EFA Informationsmodell
 
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|Diese Darstellung finde ich sehr gut und hilfreich.
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|3
 
 
|style="background-color: white;"|fo
 
|style="background-color: white;"|fo
 
|style="background-color: #C2DFFF;"|postponed
 
|style="background-color: #C2DFFF;"|postponed
−
|style="background-color: white;"|BnsIi.01 : EFA Informationsmodell
+
|style="background-color: white;"|Peen.01.01 : Patienteneinwilligung zur EFA
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|EFA-Teilnehmer
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|Welche Aktvität ist denn in der Grafik dazwischengeschoben?
 
−
|style="background-color: white;"|Kardinalität-Verbinder (1..n) für Rolle-Akte raus (fo, 13.09.13)
 
−
|style="background-color: white;"|Die Grafik ist wenig selbsterklärend, da durch die Nutzung eines RMIM als Darstellung einige "Hilfsklassen" hinzukommen. Vorschlag: Analog zu den detaillierteren Grafiken zu den einzelnen Klassen wird auch die Übersichtsgrafik als UML Klassenmodell dargestellt. (jc, 26.07.13)
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|4
 
−
|style="background-color: white;"|fo
 
−
|style="background-color: #C2DFFF;"|postponed
 
−
|style="background-color: white;"|BnsIi.01.01 : Patient
 
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|Regel "Sender does it right",
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|Das muss genaugenommen in das IHE-Cookbook.
 
−
|style="background-color: white;"|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)
 
−
|style="background-color: white;"|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)
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|5
 
−
|style="background-color: white;"|mk
 
−
|style="background-color: #E77471;"|rejected
 
−
|style="background-color: white;"|BnsIi.01.02 : Fallakte
 
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|Jede Fallakte dient genau einem klar abgrenzbaren Zweck. Pro Patient und Zweck kann es nur eine Fallakte geben.
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|Der Zweck einer Akte ist nach wie vor singulär und bildet Diagnose oder Vertrag ab. Das schließt das Verwalten mehrerer Diagnosen als Fallaktenmetadatum aus. Das ist aus unserer Sicht nicht praktikabel, da der Zweck nicht immer bei Eröffnung einer Fallakte detailliert bekannt ist. (15.08.2014)
 
−
|style="background-color: white;"|Die enge Zweckbindung einer Fallakte ist die Voraussetzung dafür, dass die Akte arztgeführt sein darf. Das ist die gängige juristische Bewertung. Wenn die Diagnose nicht klar abgrenzbar ist, kann mit dem Patienten ein entsprechend allgemeinerer Zweck abgestimmt werden. (bk, 22.08.2014)
 
−
|style="background-color: white;"|
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|6
 
−
|style="background-color: white;"|fo
 
−
|style="background-color: #C2DFFF;"|postponed
 
−
|style="background-color: white;"|BnsIi.02.02 : purpose
 
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|purpose
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|genau, das steht aber schon im Cookbook.
 
−
|style="background-color: white;"|Vorschlag ti: Verweis auf Cookbook auf Standards-Ebene, Vorschlag fo: Zusätzlich Verweis auf fachliche Ebene. Vorschlag jc: 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)
 
−
|style="background-color: white;"|
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|7
 
−
|style="background-color: white;"|ti
 
−
|style="background-color: #89C35C;"|included
 
−
|style="background-color: white;"|BnsIi.02.04 : consentInfo
 
 
         |style="background-color: white;"|
 
         |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
−
|style="background-color: white;"|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)
+
|style="background-color: white;"|Grundsätzlich ok, gehört aber in das Cookbook.
−
|style="background-color: white;"|Die Definition wurde geändert: Jede Fallakte kann mehrere aktuelle consentInfo-Dokumente haben, aber nur eins je EFA-Provider. Das consentInfo definiert die Berechtigungen der EFA-Teilnehmer, die beim jeweiligen EFA-Provider registriert sind. (bkr, 13.06.2014)
+
|style="background-color: white;"|Hinweis auf Verschiebung ins Cookbook wurde in Einstiegsseite eingefügt. (bk)
−
|style="background-color: white;"|Vorschlag ti: es darf mehr als einen consentInfo je Zeitpunkt geben, Anmerkung ws: der einen gültige consent muss dann aber identifizierbar sein, Durch P2P stark beeinflusst, aufgeschoben
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|8
 
−
|style="background-color: white;"|ti
 
−
|style="background-color: #E77471;"|rejected
 
−
|style="background-color: white;"|BnsIi.02.07 : partitionList
 
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|Um Peer-to-Peer Fallakten zu unterstützen, wäre hier eine Referenz auf den EFA Provider sinnvoll. (ti, 29.05.2013)
 
−
|style="background-color: white;"|Siehe [[cdaefa:EFA_Business_Informationsmodell#partitionID|Beschreibung der PartitionID]]: Der Verweis auf den EFA Provider ist Bestandteil der PartitionID. (jc, 05.09.2013)
 
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
          
 
          
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
−
|style="background-color: white;"|9
+
|style="background-color: white;"|252
−
|style="background-color: white;"|mr
+
|style="background-color: white;"|jc
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
−
|style="background-color: white;"|BnsIi.02.09 : partitionInfo
+
|style="background-color: white;"|Peen.01.01 : Patienteneinwilligung zur EFA
 
         |style="background-color: white;"|
 
         |style="background-color: white;"|
 +
|style="background-color: white;"|Fallaktenmanager
 
|style="background-color: white;"|
 
|style="background-color: white;"|
−
|style="background-color: white;"|Über das XDS-Bindung sollten eventuelle eventCodes definiert werden um diese Attribute abzubilden
 
−
|style="background-color: white;"|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
 
−
|style="background-color: white;"|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. (jc) Vorschlag ti: Kommentar verschieben ins XDS-Binding, da hier fachliche Beschreibung
 
 
|style="background-color: white;"|
 
|style="background-color: white;"|
−
       
+
|style="background-color: white;"|Die Beschreibung der Rolle des [[cdaefa:Akteure_und_Rollen_der_EFA#Fallaktenmanager|Fallaktenmanagers]] wurde geschärft und dementsprechend auch ein Passus hierzu in die Vorgaben zur Einwilligungserklärung eingefügt. (jc, 26.07.2013
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|10
 
−
|style="background-color: white;"|fo
 
−
|style="background-color: #89C35C;"|included
 
−
|style="background-color: white;"|BnsIi.02.10 : document
 
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|sofern diese beim selben EFA-Provider angelegt sind.
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|Hatten wir nicht die sog. Mount-Points besprochen…. 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)
 
−
|style="background-color: white;"|
 
−
* 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)
 
−
* ok (fo, 20.01.14)
 
 
|style="background-color: white;"|
 
|style="background-color: white;"|
−
* 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. (jc)
 
−
* Document-Metadaten können mehrfach eingestellt werden. Ein Dokument kann daher einfach im Rep. abgelegt werden, aber in zwei Akten eingestellt werden.  Dokumente sollten einem Ordner logisch zugeordnet werden können (siehe Cookbook). (fo)
 
−
*Unterscheidung Folder/Partition verdeutlichen. (ti)
 
 
          
 
          
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
−
|style="background-color: white;"|11
+
|style="background-color: white;"|253
−
|style="background-color: white;"|fo
+
|style="background-color: white;"|sh
 
|style="background-color: #89C35C;"|included
 
|style="background-color: #89C35C;"|included
−
|style="background-color: white;"|BnsIi.02.11 : docMetadata
+
|style="background-color: white;"|Peen.01.01 : Patienteneinwilligung zur EFA
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|documentID := Eindeutiger Identifizierer der Partition
 
−
|style="background-color: white;"|Eindeutiger Identifizierer des Dokuments
 
−
|style="background-color: white;"|Hier dürfte das Dokument identifiziert werden…
 
−
|style="background-color: white;"|Korrigiert. (bk)
 
−
|style="background-color: white;"|
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|12
 
−
|style="background-color: white;"|ti
 
−
|style="background-color: #89C35C;"|included
 
−
|style="background-color: white;"|BnsIi.02.11 : docMetadata
 
 
         |style="background-color: white;"|
 
         |style="background-color: white;"|
 +
|style="background-color: white;"|Die elektronische Fallakte ist ein an § 291a SGB V angelehnter Gesundheitsdatendienste.
 +
|style="background-color: white;"|Gesundheitsdatendienst.
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
−
|style="background-color: white;"|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)
 
−
|style="background-color: white;"|Das [[cdaefa:EFA_Metadata_Bindings#Mapping_of_PIM_Classes|Mapping der documentID auf die XDS Dokument Metadaten]] wurde entsprechend korrigiert. (JC, 05.09.2013)
 
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
          
 
          
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
−
|style="background-color: white;"|13
+
|style="background-color: white;"|254
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
−
|style="background-color: #89C35C;"|included
+
|style="background-color: #E77471;"|rejected
−
|style="background-color: white;"|BnsIi.02.11 : docMetadata
+
|style="background-color: white;"|Peen.01.01 : Patienteneinwilligung zur EFA
 
         |style="background-color: white;"|
 
         |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
−
|style="background-color: white;"|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 faach relevant ist) oder es sich nur um einen default fallback Wert handelt, dem keine fachliche Bedeutung beizumessen ist. (ti, 29.05.2013)
+
|style="background-color: white;"|Die Verwendung eines Offline-Tokens zur Autorisierung eines Teilnehmers über eine Arztrolle (bspw. Kardiologe) widerspricht der Abmachung in der 7er Gruppe, dass Offline-Tokens nur zur Identifikation von Fallakten verwendet werden. (ti, 28.05.2013)
−
|style="background-color: white;"|In der [[cdaefa:EFA_Business_Informationsmodell#docMetadata|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)
+
|style="background-color: white;"|Da das Offline-Token im Text nur als Beispiel für eine Umsetzung des beschriebenen Konzepts erwähnt wurde, wird diese Erwähnung gestrichen. Der weitere Umgang mit dem Thema Offline-Token wird mit dem Lenkungskreis abgestimmt. (jc)
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 +
* Die Instanziierung von Rollen ist eine wesentliche Funktionalität zur Sicherstellung der freien Arztwahl durch den Patienten bei gleichzeitiger Beibehaltung des Prinzips der Zweckbindung. In der Stellungnahme der Landesdatenschützer zum Offline-Token wird dieses sehr kritisch bewertet, da hiermit die vereinbarte Zweckbindung (durch den Patienten) unterlaufen werden kann und die EFA damit faktisch zur eEPA wird. Die Restriktion, dass ein Token nur durch einen Arzt einer vorgegebenen Fachrichtung eingelöst werden kann, löst dieses Problem. (jc, 05.09.2013)
 +
* Unabhängig davon ist die EFAv1.2-Spezifikationserweiterung des Offline-Tokens unabhängig von der EFA-Kernspezifikation und nicht Gegenstand der Arbeiten der 7er-Gruppe. (jc, 05.09.2013)
 
          
 
          
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
−
|style="background-color: white;"|14
+
|style="background-color: white;"|255
 
|style="background-color: white;"|ti
 
|style="background-color: white;"|ti
−
|style="background-color: #89C35C;"|included
+
|style="background-color: #E77471;"|rejected
−
|style="background-color: white;"|BnsIi.02.12 : docRelationship
+
|style="background-color: white;"|Peen.01.01 : Patienteneinwilligung zur EFA
−
        |style="background-color: white;"|
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|
 
−
|style="background-color: white;"|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)
 
−
|style="background-color: white;"|Ein entsprechender Hinweis zur Semantik der Invalidierung wurde aufgenommen. In der konzeptuellen Spezifikation der [[cdaefa:EFA_Geschäftsobjekte#Klasse_Datenobjekt|Beziehungen zwischen Datenobjekten]] wurden "ersetzen" und "aktualisieren" gleichgesetzt. Daher musste die logische Spezifikation entsprechend angepasst werden. (jc, 05.09.2013)
 
−
|style="background-color: white;"|Spalte "Umsetzung" der Tabelle docRelationship entfernen, da kein Binding in logischer Ebene.
 
−
       
 
−
|- style="vertical-align:top;"
 
−
|style="background-color: white;"|15
 
−
|style="background-color: white;"|ti
 
−
|style="background-color: #89C35C;"|included
 
−
|style="background-color: white;"|BnsIi.02.13 : documentID
 
 
         |style="background-color: white;"|
 
         |style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 
|style="background-color: white;"|
−
|style="background-color: white;"|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)
+
|style="background-color: white;"|Der explizite Ausschluss von mehreren Einwilligungserklärungen widerspricht der abgesprochenen Verwendung von Offline-Tokens. Bei Einsatz eines Tokens zur Identifkation einer Fallakte, ist danach ein Anlegen einer weiteren Patientenzustimmung, die den vorher nicht autorisierten Arzt berechtigt, zwingend notwendig. Ansonsten hat der hinzuzufügende Arzt nicht die notwendige Berechtigung um die zu ersetzende Patientenzustimmung zu identifizieren. (ti, 28.05.2013)
−
|style="background-color: white;"|In der Tabelle zu den Dokument-Metadaten klar gestellt, dass die ID eines Dokuments eine Instanz der Klasse documentID ist. In der [[cdaefa:EFA_Metadata_Bindings#Mapping_of_PIM_Classes|Mapping.Tabelle]] XDSDocument.repositoryUniqueID als Bestandteil der Umsetzung der logischen documentID in XDS hinzugefügt.
+
|style="background-color: white;"|Da das Offline-Token im Text nur als Beispiel für eine Umsetzung des beschriebenen Konzepts erwähnt wurde, wird diese Erwähnung gestrichen. Der weitere Umgang mit dem Thema Offline-Token wird mit dem Lenkungskreis abgestimmt. (jc)
 
|style="background-color: white;"|
 
|style="background-color: white;"|
 +
* Grundsätzlich besteht kein Widerspruch: Im "Regelbetrieb" der Fallakte besteht immer nur eine gültige Einwilligung. Mit dem Offline-Token wird vom Patienten lediglich eine temporäre, auf den Zweck des Einstellens einer neuen Einwilligung beschränkte Autorisierung neben der bestehenden Einwilligung vergeben. (jc, 05.09.2013)
 +
* Unabhängig davon ist die EFAv1.2-Spezifikationserweiterung des Offline-Tokens unabhängig von der EFA-Kernspezifikation und nicht Gegenstand der Arbeiten der 7er-Gruppe. (jc, 05.09.2013)
 
|}
 
|}
  

Aktuelle Version vom 16. September 2014, 12:57 Uhr

Kommentare

ID Author Status Section Vote Existing Proposed Comment Comment Editor Discussion
251 fo postponed Peen.01.01 : Patienteneinwilligung zur EFA Grundsätzlich ok, gehört aber in das Cookbook. Hinweis auf Verschiebung ins Cookbook wurde in Einstiegsseite eingefügt. (bk)
252 jc included Peen.01.01 : Patienteneinwilligung zur EFA Fallaktenmanager Die Beschreibung der Rolle des Fallaktenmanagers wurde geschärft und dementsprechend auch ein Passus hierzu in die Vorgaben zur Einwilligungserklärung eingefügt. (jc, 26.07.2013
253 sh included Peen.01.01 : Patienteneinwilligung zur EFA Die elektronische Fallakte ist ein an § 291a SGB V angelehnter Gesundheitsdatendienste. Gesundheitsdatendienst.
254 ti rejected Peen.01.01 : Patienteneinwilligung zur EFA Die Verwendung eines Offline-Tokens zur Autorisierung eines Teilnehmers über eine Arztrolle (bspw. Kardiologe) widerspricht der Abmachung in der 7er Gruppe, dass Offline-Tokens nur zur Identifikation von Fallakten verwendet werden. (ti, 28.05.2013) Da das Offline-Token im Text nur als Beispiel für eine Umsetzung des beschriebenen Konzepts erwähnt wurde, wird diese Erwähnung gestrichen. Der weitere Umgang mit dem Thema Offline-Token wird mit dem Lenkungskreis abgestimmt. (jc)
  • Die Instanziierung von Rollen ist eine wesentliche Funktionalität zur Sicherstellung der freien Arztwahl durch den Patienten bei gleichzeitiger Beibehaltung des Prinzips der Zweckbindung. In der Stellungnahme der Landesdatenschützer zum Offline-Token wird dieses sehr kritisch bewertet, da hiermit die vereinbarte Zweckbindung (durch den Patienten) unterlaufen werden kann und die EFA damit faktisch zur eEPA wird. Die Restriktion, dass ein Token nur durch einen Arzt einer vorgegebenen Fachrichtung eingelöst werden kann, löst dieses Problem. (jc, 05.09.2013)
  • Unabhängig davon ist die EFAv1.2-Spezifikationserweiterung des Offline-Tokens unabhängig von der EFA-Kernspezifikation und nicht Gegenstand der Arbeiten der 7er-Gruppe. (jc, 05.09.2013)
255 ti rejected Peen.01.01 : Patienteneinwilligung zur EFA Der explizite Ausschluss von mehreren Einwilligungserklärungen widerspricht der abgesprochenen Verwendung von Offline-Tokens. Bei Einsatz eines Tokens zur Identifkation einer Fallakte, ist danach ein Anlegen einer weiteren Patientenzustimmung, die den vorher nicht autorisierten Arzt berechtigt, zwingend notwendig. Ansonsten hat der hinzuzufügende Arzt nicht die notwendige Berechtigung um die zu ersetzende Patientenzustimmung zu identifizieren. (ti, 28.05.2013) Da das Offline-Token im Text nur als Beispiel für eine Umsetzung des beschriebenen Konzepts erwähnt wurde, wird diese Erwähnung gestrichen. Der weitere Umgang mit dem Thema Offline-Token wird mit dem Lenkungskreis abgestimmt. (jc)
  • Grundsätzlich besteht kein Widerspruch: Im "Regelbetrieb" der Fallakte besteht immer nur eine gültige Einwilligung. Mit dem Offline-Token wird vom Patienten lediglich eine temporäre, auf den Zweck des Einstellens einer neuen Einwilligung beschränkte Autorisierung neben der bestehenden Einwilligung vergeben. (jc, 05.09.2013)
  • Unabhängig davon ist die EFAv1.2-Spezifikationserweiterung des Offline-Tokens unabhängig von der EFA-Kernspezifikation und nicht Gegenstand der Arbeiten der 7er-Gruppe. (jc, 05.09.2013)

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
Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa_Diskussion:Patienteneinwilligung_zur_EFA&oldid=20392“