cdaefa Diskussion:EFA Business Informationsmodell: Unterschied zwischen den Versionen
K (→Change Requests) |
|||
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | |||
= Change Requests = | = Change Requests = | ||
− | |||
{|class="wikitable" style="text-align: left; cellpadding: 10;" | {|class="wikitable" style="text-align: left; cellpadding: 10;" | ||
− | + | !ID | |
− | ! | + | !Requester |
!Status | !Status | ||
!Section | !Section | ||
Zeile 10: | Zeile 8: | ||
!Recommendation Editor | !Recommendation Editor | ||
!Discussion | !Discussion | ||
− | |- style="vertical-align:top;" | + | |
− | |style="background-color: white;"| | + | |- style="vertical-align:top;" |
− | + | |style="background-color: white;"|1 | |
− | + | |style="background-color: white;"|- | |
− | |style="background-color: white;"| | + | |style="background-color: #89C35C;"|included |
− | + | |style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | |
− | + | |style="background-color: white;"|'''Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte:''' | |
− | |||
− | |||
− | |||
− | |||
− | |style="background-color: # | ||
− | |style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | ||
− | |style="background-color: white;"|'''Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte:''' | ||
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. | 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. | ||
− | |style="background-color: white;"|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. | + | |style="background-color: white;"|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. |
− | |style="background-color: white;"| | + | |style="background-color: white;"| |
− | + | * Sollte über die Policy gemanagt werden. (fo) | |
− | |- style="vertical-align:top;" | + | * Vorschlag: Zeitraum des Consent fehlt im logischen Informationsmodell. Auf logischer Ebene nachziehen. Auf technischer Ebene in consentInfo-Binding. Durchsetzung mit Policy aus consentInfo (jc, 2014-01-21) |
− | |style="background-color: white;"| | + | |
− | |style="background-color: # | + | |- style="vertical-align:top;" |
− | |style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | + | |style="background-color: white;"|2 |
− | |style="background-color: white;"|'''Ausformulieren des Informationsmodells einer Einwilligung:''' | + | |style="background-color: white;"|- |
+ | |style="background-color: #89C35C;"|included | ||
+ | |style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | ||
+ | |style="background-color: white;"|'''Ausformulieren des Informationsmodells einer Einwilligung:''' | ||
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 [[cdaefa:Patienteneinwilligung_zur_EFA|Patienteneinwilligung zur EFA]] beschriebenen Inhalte einer Einwilligung geeignet formalisiert werden. | 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 [[cdaefa:Patienteneinwilligung_zur_EFA|Patienteneinwilligung zur EFA]] beschriebenen Inhalte einer Einwilligung geeignet formalisiert werden. | ||
− | |style="background-color: white;"|Der Change Request sollte umgesetzt und ein aus den Inhalten des Kapitels [[cdaefa:Patienteneinwilligung_zur_EFA|Patienteneinwilligung zur EFA]] abgeleitetes Informationsmodell angegeben werden. | + | |style="background-color: white;"|Der Change Request sollte umgesetzt und ein aus den Inhalten des Kapitels [[cdaefa:Patienteneinwilligung_zur_EFA|Patienteneinwilligung zur EFA]] abgeleitetes Informationsmodell angegeben werden. |
− | |style="background-color: white;"| ecrInfo-Object erweitern: Teilnehmer, Gültigkeit, Fallakten-Manager | + | |style="background-color: white;"| |
− | |- style="vertical-align:top;" | + | * ok (fo) |
− | |style="background-color: white;"| | + | * ecrInfo-Object erweitern: Teilnehmer, Gültigkeit, Fallakten-Manager (jc, 2014-01-21) |
− | |style="background-color: # | + | |
− | |style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | + | |- style="vertical-align:top;" |
− | |style="background-color: white;"|'''Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen:''' | + | |style="background-color: white;"|3 |
+ | |style="background-color: white;"|- | ||
+ | |style="background-color: #89C35C;"|included | ||
+ | |style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | ||
+ | |style="background-color: white;"|'''Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen:''' | ||
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. | 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. | ||
− | |style="background-color: white;"|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. | + | |style="background-color: white;"|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. |
− | |style="background-color: white;"|Grundlage HL7-Draft. Wird im Interop-Forum weitergeführt. | + | |style="background-color: white;"| |
+ | * ok (fo) | ||
+ | * Grundlage HL7-Draft. Wird im Interop-Forum weitergeführt. (jc, 2014-01-21) | ||
+ | * Hinweis wurde auf neuer Wiki-Seite eingefügt: EFA Patient Consent Binding (bkr, 2014-06-13) | ||
+ | |||
+ | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|4 | ||
+ | |style="background-color: white;"|- | ||
+ | |style="background-color: #89C35C;"|included | ||
+ | |style="background-color: white;"|BnsIi.02.02 : purpose | ||
+ | |style="background-color: white;"|'''Ausführungen zur Zweckbindung:''' | ||
+ | Die Spezifikation legt abscließend vier mögliche Arten der Zweckbindung fest. In EFA-Projekten von ISST und FOKUS sind mittlerweile EFA-Einsatzszenarien definiert, die sich mit diesen 4 Optionen nicht adäquat abbilden lasen. | ||
+ | |style="background-color: white;"|jc: Text und Grafik sollen dahingehend geändert werden, dass auch weitere Arten von Zweckbindung zulässig sind. Hierzu sollte man dann ggf. eine Zuständigkeit skizzieren, wie diese "offiziell" wird (z.B. Freigabe durch EFA-Verein). | ||
+ | |style="background-color: white;"| | ||
+ | |||
+ | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|5 | ||
+ | |style="background-color: white;"|- | ||
+ | |style="background-color: #89C35C;"|included | ||
+ | |style="background-color: white;"|BnsIi.02.04 : consentInfo | ||
+ | |style="background-color: white;"|'''Ausführungen zur Grundlage einer consentInfo:''' | ||
+ | Die Darstellung der EFAv2.0-Klasse „consentInfo“ ist sehr stark auf eine explizite, dedizierte Einwilligung zugeschnitten. Hier sollten die gewählten Formulierungen daraufhin angepasst werden, dass auch eine Ableitung einer Einwilligung aus einem Behandlungsvertrag möglich ist. | ||
+ | |style="background-color: white;"|Der Begriff "schriftliche Patienteneinwilligung" wird ersetzt mit einem Verweis auf die Seite "Patienteneinwilligung zur EFA". Die Varianten bzw. der juristische Rahmen der fachlichen Implementierung einer Patienteneinwilligung müssen dort genannt werden. (bkr, 13.06.2014) | ||
+ | |style="background-color: white;"| | ||
|} | |} | ||
− | = | + | = Kommentare = |
{|class="wikitable" style="text-align: left; cellpadding: 10;" | {|class="wikitable" style="text-align: left; cellpadding: 10;" | ||
+ | !ID | ||
!Author | !Author | ||
!Status | !Status | ||
!Section | !Section | ||
+ | !Vote | ||
!Existing | !Existing | ||
!Proposed | !Proposed | ||
Zeile 56: | Zeile 79: | ||
!Comment Editor | !Comment Editor | ||
!Discussion | !Discussion | ||
+ | |||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|2 | ||
|style="background-color: white;"|fo | |style="background-color: white;"|fo | ||
|style="background-color: #89C35C;"|included | |style="background-color: #89C35C;"|included | ||
|style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | |style="background-color: white;"|BnsIi.01 : EFA Informationsmodell | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 65: | Zeile 91: | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
+ | |||
|- style="vertical-align:top;" | |- 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;"|BnsIi.01 : EFA Informationsmodell | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"|EFA-Teilnehmer | |style="background-color: white;"|EFA-Teilnehmer | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 74: | Zeile 103: | ||
|style="background-color: white;"|Kardinalität-Verbinder (1..n) für Rolle-Akte raus (fo, 13.09.13) | |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="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="vertical-align:top;" | ||
+ | |style="background-color: white;"|4 | ||
|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.01 : Patient | |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;"|Regel "Sender does it right", | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 83: | Zeile 115: | ||
|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;"|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="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="vertical-align:top;" | ||
+ | |style="background-color: white;"|6 | ||
|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.02.02 : purpose | |style="background-color: white;"|BnsIi.02.02 : purpose | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"|purpose | |style="background-color: white;"|purpose | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 92: | Zeile 139: | ||
|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;"|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="background-color: white;"| | ||
+ | |||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|7 | ||
|style="background-color: white;"|ti | |style="background-color: white;"|ti | ||
− | |style="background-color: # | + | |style="background-color: #89C35C;"|included |
|style="background-color: white;"|BnsIi.02.04 : consentInfo | |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;"|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;"|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;"|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;"|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="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="vertical-align:top;" | ||
+ | |style="background-color: white;"|8 | ||
|style="background-color: white;"|ti | |style="background-color: white;"|ti | ||
|style="background-color: #E77471;"|rejected | |style="background-color: #E77471;"|rejected | ||
|style="background-color: white;"|BnsIi.02.07 : partitionList | |style="background-color: white;"|BnsIi.02.07 : partitionList | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 110: | Zeile 163: | ||
|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;"|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;"|mr | |style="background-color: white;"|mr | ||
|style="background-color: #89C35C;"|included | |style="background-color: #89C35C;"|included | ||
|style="background-color: white;"|BnsIi.02.09 : partitionInfo | |style="background-color: white;"|BnsIi.02.09 : partitionInfo | ||
+ | |style="background-color: white;"| | ||
|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;"|Über das XDS-Bindung sollten eventuelle eventCodes definiert werden um diese Attribute abzubilden | ||
Zeile 119: | Zeile 175: | ||
|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;"|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="vertical-align:top;" | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|10 | ||
|style="background-color: white;"|fo | |style="background-color: white;"|fo | ||
− | |style="background-color: # | + | |style="background-color: #89C35C;"|included |
|style="background-color: white;"|BnsIi.02.10 : document | |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;"|sofern diese beim selben EFA-Provider angelegt sind. | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 133: | Zeile 192: | ||
* 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) | * 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) | *Unterscheidung Folder/Partition verdeutlichen. (ti) | ||
+ | |||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|11 | ||
|style="background-color: white;"|fo | |style="background-color: white;"|fo | ||
|style="background-color: #89C35C;"|included | |style="background-color: #89C35C;"|included | ||
|style="background-color: white;"|BnsIi.02.11 : docMetadata | |style="background-color: white;"|BnsIi.02.11 : docMetadata | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"|documentID := Eindeutiger Identifizierer der Partition | |style="background-color: white;"|documentID := Eindeutiger Identifizierer der Partition | ||
|style="background-color: white;"|Eindeutiger Identifizierer des Dokuments | |style="background-color: white;"|Eindeutiger Identifizierer des Dokuments | ||
Zeile 142: | Zeile 204: | ||
|style="background-color: white;"|Korrigiert. (bk) | |style="background-color: white;"|Korrigiert. (bk) | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
+ | |||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|12 | ||
|style="background-color: white;"|ti | |style="background-color: white;"|ti | ||
|style="background-color: #89C35C;"|included | |style="background-color: #89C35C;"|included | ||
|style="background-color: white;"|BnsIi.02.11 : docMetadata | |style="background-color: white;"|BnsIi.02.11 : docMetadata | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 151: | Zeile 216: | ||
|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;"|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;"|ti | |style="background-color: white;"|ti | ||
|style="background-color: #89C35C;"|included | |style="background-color: #89C35C;"|included | ||
|style="background-color: white;"|BnsIi.02.11 : docMetadata | |style="background-color: white;"|BnsIi.02.11 : docMetadata | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 160: | Zeile 228: | ||
|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;"|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;"| | |style="background-color: white;"| | ||
+ | |||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|14 | ||
|style="background-color: white;"|ti | |style="background-color: white;"|ti | ||
|style="background-color: #89C35C;"|included | |style="background-color: #89C35C;"|included | ||
|style="background-color: white;"|BnsIi.02.12 : docRelationship | |style="background-color: white;"|BnsIi.02.12 : docRelationship | ||
+ | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
|style="background-color: white;"| | |style="background-color: white;"| | ||
Zeile 169: | Zeile 240: | ||
|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;"|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="background-color: white;"|Spalte "Umsetzung" der Tabelle docRelationship entfernen, da kein Binding in logischer Ebene. | ||
+ | |||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
+ | |style="background-color: white;"|15 | ||
|style="background-color: white;"|ti | |style="background-color: white;"|ti | ||
|style="background-color: #89C35C;"|included | |style="background-color: #89C35C;"|included | ||
|style="background-color: white;"|BnsIi.02.13 : documentID | |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;"| | ||
Zeile 180: | Zeile 254: | ||
|} | |} | ||
− | == | + | = Authors = |
− | ; | + | {|class="wikitable" style="text-align: left; cellpadding: 10;" |
− | : | + | !Kürzel |
− | ; | + | !Name |
− | : | + | !Organisation |
− | ;mr | + | !E-Mail |
− | :Michael Rübener | + | |
− | ; | + | |- style="vertical-align:top;" |
− | : | + | |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, 12:37 Uhr
Change Requests
ID | Requester | Status | Section | Change Request | Recommendation Editor | Discussion |
---|---|---|---|---|---|---|
1 | - | included | BnsIi.01 : EFA Informationsmodell | Konkretere Darstellung der Kodierung der Gültigkeitsdauer einer Akte:
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. |
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. |
|
2 | - | included | BnsIi.01 : EFA Informationsmodell | Ausformulieren des Informationsmodells einer Einwilligung:
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. |
Der Change Request sollte umgesetzt und ein aus den Inhalten des Kapitels Patienteneinwilligung zur EFA abgeleitetes Informationsmodell angegeben werden. |
|
3 | - | included | BnsIi.01 : EFA Informationsmodell | Hinweis auf laufende Arbeiten zur Einwilligungserklärung einfügen:
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. |
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. |
|
4 | - | included | BnsIi.02.02 : purpose | Ausführungen zur Zweckbindung:
Die Spezifikation legt abscließend vier mögliche Arten der Zweckbindung fest. In EFA-Projekten von ISST und FOKUS sind mittlerweile EFA-Einsatzszenarien definiert, die sich mit diesen 4 Optionen nicht adäquat abbilden lasen. |
jc: Text und Grafik sollen dahingehend geändert werden, dass auch weitere Arten von Zweckbindung zulässig sind. Hierzu sollte man dann ggf. eine Zuständigkeit skizzieren, wie diese "offiziell" wird (z.B. Freigabe durch EFA-Verein). | |
5 | - | included | BnsIi.02.04 : consentInfo | Ausführungen zur Grundlage einer consentInfo:
Die Darstellung der EFAv2.0-Klasse „consentInfo“ ist sehr stark auf eine explizite, dedizierte Einwilligung zugeschnitten. Hier sollten die gewählten Formulierungen daraufhin angepasst werden, dass auch eine Ableitung einer Einwilligung aus einem Behandlungsvertrag möglich ist. |
Der Begriff "schriftliche Patienteneinwilligung" wird ersetzt mit einem Verweis auf die Seite "Patienteneinwilligung zur EFA". Die Varianten bzw. der juristische Rahmen der fachlichen Implementierung einer Patienteneinwilligung müssen dort genannt werden. (bkr, 13.06.2014) |
Kommentare
ID | Author | Status | Section | Vote | Existing | Proposed | Comment | Comment Editor | Discussion |
---|---|---|---|---|---|---|---|---|---|
2 | fo | included | BnsIi.01 : EFA Informationsmodell | Diese Darstellung finde ich sehr gut und hilfreich. | |||||
3 | fo | postponed | BnsIi.01 : EFA Informationsmodell | EFA-Teilnehmer | Welche Aktvität ist denn in der Grafik dazwischengeschoben? | Kardinalität-Verbinder (1..n) für Rolle-Akte raus (fo, 13.09.13) | 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) | ||
4 | fo | postponed | BnsIi.01.01 : Patient | Regel "Sender does it right", | Das muss genaugenommen in das IHE-Cookbook. | 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) | 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) | ||
5 | mk | rejected | BnsIi.01.02 : Fallakte | Jede Fallakte dient genau einem klar abgrenzbaren Zweck. Pro Patient und Zweck kann es nur eine Fallakte geben. | 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) | 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) | |||
6 | fo | postponed | BnsIi.02.02 : purpose | purpose | genau, das steht aber schon im Cookbook. | 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) | |||
7 | ti | included | 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) | 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) | 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 | |||
8 | ti | rejected | 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) | ||||
9 | mr | included | BnsIi.02.09 : partitionInfo | Über das XDS-Bindung sollten eventuelle eventCodes definiert werden um diese Attribute abzubilden | 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 | 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 | |||
10 | fo | included | BnsIi.02.10 : document | sofern diese beim selben EFA-Provider angelegt sind. | 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) |
|
| ||
11 | fo | included | BnsIi.02.11 : docMetadata | documentID := Eindeutiger Identifizierer der Partition | Eindeutiger Identifizierer des Dokuments | Hier dürfte das Dokument identifiziert werden… | Korrigiert. (bk) | ||
12 | ti | included | BnsIi.02.11 : docMetadata | 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) | ||||
13 | ti | included | BnsIi.02.11 : docMetadata | 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) | 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) | ||||
14 | ti | included | 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. 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) | Spalte "Umsetzung" der Tabelle docRelationship entfernen, da kein Binding in logischer Ebene. | |||
15 | ti | included | BnsIi.02.13 : 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. |
Authors
Kürzel | Name | Organisation | |
---|---|---|---|
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 |