cdaefa Diskussion:EFA XDS Folder Metadata Binding - Versionsgeschichte

Jcaumanns am 16. September 2014 um 12:41 Uhr

2014-09-16T12:41:30Z

Änderungen zeigen

Jcaumanns: /* Kommentierung */ Duplikat entfernt

2014-06-16T20:07:54Z

‎Kommentierung: Duplikat entfernt

Jcaumanns: /* Kommentierung */

2014-03-29T08:47:51Z

‎Kommentierung

Jcaumanns: /* Kommentierung */

2014-03-29T08:43:01Z

‎Kommentierung

Jcaumanns: Aktuelle Fassung der Kommentar-Tabelle eingefügt.

2014-01-24T15:53:30Z

Aktuelle Fassung der Kommentar-Tabelle eingefügt.

Jcaumanns: Die Seite wurde neu angelegt: „== EDold.01.01 == ;Comment :Mir fehlt hier noch ein expliziterer Hinweis auf das logische Konzept purpose das über die codeList abgebildet wird. …“

2013-09-17T16:21:22Z

Die Seite wurde neu angelegt: „== EDold.01.01 == ;Comment :Mir fehlt hier noch ein expliziterer Hinweis auf das logische Konzept purpose das über die codeList abgebildet wird. …“

Neue Seite

== EDold.01.01 ==

;Comment
:Mir fehlt hier noch ein expliziterer Hinweis auf das logische Konzept purpose das über die codeList abgebildet wird. (ti, 03.06.2013)
;Author
:ti
== EDold.01.01 ==

;Comment
:Ist ein Hausarztvertrag nicht viel zu breit und unspezifisch um dies mit einer Fallakte abzubilden? Hier geht es ja um ein getrenntes Abrechnungssystem, das nicht-indikationsspezifisch ist. (ti, 03.06.2013)
;Author
:ti
== EDold.01.01 ==

;Comment
:Für IV Vertrag und Hausarztzentrierte Versorgung sollte in der Value(s) Spalte nicht von "event code", sondern einfach nur von "code" gesprochen werden.
;Author
:ti
== EDold.01.01 ==

;Comment
:Das für IV Vertrag und Hausarztzentrierte Versorgung gewählte Konstrukt, indem der displayName die für die Differenzierung entscheidende Information enthält, sehe ich kritisch. Es ist nun nicht mehr möglich anhand des codes eine Unterscheidung zwischen zwei verschiedenen IV Verträgen durchzuführen. Wenn für 2 IV Verträge jeweils eine Fallakte geführt wird, heisst dies, dass die Registry nicht anhand der codeList (d.h. codingScheme+code) alleine Filtern kann, sondern auch noch den ursprünglich verwendeten displayName heranziehen muss. Dies widerspricht ausserdem der Definition der codeListDisplayName in volume 3: "The list of human readable descriptions of the meaning of each of the codes present in the codeList." Es handelt sich hier nicht um eine menschenlesbare Erläuterung, sondern um ein kritisches Unterscheidungsmerkmal um unterschiedliche IV Verträge auseinanderzuhalten. Hier sollte auch bedacht werden, dass viele Systeme bei der Rückgabe von displayNames die eingesendete Variante ggf. durch eine normalisierte/kanonische und ggf. übersetzte Variante aus der eigenen Katalogverwaltung ersetzen. Sinnvoller wäre hier eine explizitere Kennzeichnung von Fallakten die auf IV (oder HA) Verträgen basieren. Anstelle von (oder zusätzlich zu) einem immer gleichen Kennzeichen (code="ECR", codeSystem="IHE-D-Cookbook-FolderClassCode"), könnte man die vier Fälle unterscheiden (DMP, IV, HA, DIAG für diagnose-basiert). Ähnlich haben wir das im Cookbook dargestellt: [http://wiki.hl7.de/index.php/IHE_DE_Cookbook#Abbildung_von_Ordnern_zur_Zweckbindung_durch_XDS_Folders]. Die besondere Problematik, wie man unterschiedliche IV und HA Verträge einheitlich benennt, ist aber auch dort nicht adressiert. Wenn man durch einen expliziten code diese Fälle unterscheiden kann und somit nicht das codingScheme zur Unterscheidung zwischen den 4 Fällen benutzen muss, kann man auch auf eine Projekt-spezifische Kennzeichnung von IV und HA Verträgen setzen. Solche Verträge die mittels Fallakte abgebildet werden sollen, würden dann bei allen betroffenen EFA Providern (entsprechend der in der 7er Gruppe diskutierten "Fachlichen Netzwerke") eine eindeutige Kennzeichnung (d.h. eine Kombination aus codingScheme und code) festlegen. (ti, 03.06.2013)
;Author
:ti

@@ Zeile 9: / Zeile 9: @@
 !Discussion
 !Decision
 |- style="vertical-align:top;"
 |style="background-color: white;"|ti

@@ Zeile 3: / Zeile 3: @@
 = Kommentierung =
 {|class="wikitable" style="text-align: left; cellpadding: 10;"
-!Author
+!Requestor
 !Status
 !Section
-!Existing
+!Change Request
 !Discussion
 |- style="vertical-align:top;"
 |style="background-color: white;"| sh, jc
@@ Zeile 16: / Zeile 14: @@
 |style="background-color: white;"|BnsIi.02.02 : Zweck einer Fallakte
 |style="background-color: white;"|'''Zweckbindung:'''
-Die Spezifikation legt abschließend vier mögliche Arten der Zweckbindung fest. Für die entsprechenden Ausführungen auf der logishcen Ebene liegt ein [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Change Request]] vor, weitere Arten der Zweckbindung zuzulassen. Die Ausführungen zur codeList müßten entsprechend angepasst werden.
+Die Spezifikation legt abschließend vier mögliche Arten der Zweckbindung fest. Für die entsprechenden Ausführungen auf der logishcen Ebene liegt ein [[cdaefa_Diskussion:EFA_Business_Informationsmodell#Change_Requests|Change Request]] vor, weitere Arten der Zweckbindung zuzulassen. Die Ausführungen zur codeList müßten entsprechend angepasst werden. Zusätzliche Codes sollten über ein zu definierendes Verfahren zugelassen werden können.
-|style="background-color: white;"|zusätzliche Codes über ein zu definierendes Verfahren zulassen.
+|style="background-color: white;"|
 |style="background-color: white;"|
 |- style="vertical-align:top;"
@@ Zeile 23: / Zeile 21: @@
 |style="background-color: #E77471;"|rejected
 |style="background-color: white;"|EDold.01.01 : codeList
 |style="background-color: white;"|Das für IV Vertrag und Hausarztzentrierte Versorgung gewählte Konstrukt, indem der displayName die für die Differenzierung entscheidende Information enthält, sehe ich kritisch. Es ist nun nicht mehr möglich anhand des codes eine Unterscheidung zwischen zwei verschiedenen IV Verträgen durchzuführen. Wenn für 2 IV Verträge jeweils eine Fallakte geführt wird, heisst dies, dass die Registry nicht anhand der codeList (d.h. codingScheme+code) alleine Filtern kann, sondern auch noch den ursprünglich verwendeten displayName heranziehen muss. Dies widerspricht ausserdem der Definition der codeListDisplayName in volume 3: "The list of human readable descriptions of the meaning of each of the codes present in the codeList." Es handelt sich hier nicht um eine menschenlesbare Erläuterung, sondern um ein kritisches Unterscheidungsmerkmal um unterschiedliche IV Verträge auseinanderzuhalten. Hier sollte auch bedacht werden, dass viele Systeme bei der Rückgabe von displayNames die eingesendete Variante ggf. durch eine normalisierte/kanonische und ggf. übersetzte Variante aus der eigenen Katalogverwaltung ersetzen. Sinnvoller wäre hier eine explizitere Kennzeichnung von Fallakten die auf IV (oder HA) Verträgen basieren. Anstelle von (oder zusätzlich zu) einem immer gleichen Kennzeichen (code="ECR", codeSystem="IHE-D-Cookbook-FolderClassCode"), könnte man die vier Fälle unterscheiden (DMP, IV, HA, DIAG für diagnose-basiert). Ähnlich haben wir das im Cookbook dargestellt: [http://wiki.hl7.de/index.php/IHE_DE_Cookbook#Abbildung_von_Ordnern_zur_Zweckbindung_durch_XDS_Folders]. Die besondere Problematik, wie man unterschiedliche IV und HA Verträge einheitlich benennt, ist aber auch dort nicht adressiert. Wenn man durch einen expliziten code diese Fälle unterscheiden kann und somit nicht das codingScheme zur Unterscheidung zwischen den 4 Fällen benutzen muss, kann man auch auf eine Projekt-spezifische Kennzeichnung von IV und HA Verträgen setzen. Solche Verträge die mittels Fallakte abgebildet werden sollen, würden dann bei allen betroffenen EFA Providern (entsprechend der in der 7er Gruppe diskutierten "Fachlichen Netzwerke") eine eindeutige Kennzeichnung (d.h. eine Kombination aus codingScheme und code) festlegen. (ti, 03.06.2013)
 |style="background-color: white;"|Anhand der gegebenen Werte (07 und 09) sind IV-Vertrag und Hausarzt-zentierte Versorgung unterscheidbar.
@@ Zeile 32: / Zeile 28: @@
 |style="background-color: #89C35C;"|included
 |style="background-color: white;"|EDold.01.01 : codeList
 |style="background-color: white;"|Mir fehlt hier noch ein expliziterer Hinweis auf das logische Konzept purpose das über die codeList abgebildet wird. (ti, 03.06.2013)
 |style="background-color: white;"|Ein Verweis auf das Business-Informationmodell-Element purpose wurde eingefügt. (bk)
@@ Zeile 41: / Zeile 35: @@
 |style="background-color: #89C35C;"|included
 |style="background-color: white;"|EDold.01.01 : codeList
 |style="background-color: white;"|Für IV Vertrag und Hausarztzentrierte Versorgung sollte in der Value(s) Spalte nicht von "event code", sondern einfach nur von "code" gesprochen werden.
 |style="background-color: white;"|Korrigiert. (bk)
@@ Zeile 50: / Zeile 42: @@
 |style="background-color: #E77471;"|rejected
 |style="background-color: white;"|EDold.01.01 : codeList
 |style="background-color: white;"|Ist ein Hausarztvertrag nicht viel zu breit und unspezifisch um dies mit einer Fallakte abzubilden? Hier geht es ja um ein getrenntes Abrechnungssystem, das nicht-indikationsspezifisch ist. (ti, 03.06.2013)
 |style="background-color: white;"|Jede als Zweck einer Fallakte angegebene Vertragsform ist zunächst breit und unspezifisch, soll aber zulässig sein. Wesentlich ist, dass der Patient diesem Zweck zustimmt. (bk)
 |style="background-color: white;"|
 |}

@@ Zeile 1: / Zeile 1: @@
 = Kommentierung =
 {|class="wikitable" style="text-align: left; cellpadding: 10;"
@@ Zeile 9: / Zeile 11: @@
 !Comment Editor
 !Discussion
 |- style="vertical-align:top;"
 |style="background-color: white;"|ti

@@ Zeile 1: / Zeile 1: @@
-== EDold.01.01 ==
+= Kommentierung =
+{|class="wikitable" style="text-align: left; cellpadding: 10;"
-;Comment
+!Author
-:Mir fehlt hier noch ein expliziterer Hinweis auf das logische Konzept purpose das über die codeList abgebildet wird. (ti, 03.06.2013)
+!Status
-;Author
+!Section
-:ti
+!Existing
-== EDold.01.01 ==
+!Proposed
+!Comment
-;Comment
+!Comment Editor
-:Ist ein Hausarztvertrag nicht viel zu breit und unspezifisch um dies mit einer Fallakte abzubilden? Hier geht es ja um ein getrenntes Abrechnungssystem, das nicht-indikationsspezifisch ist. (ti, 03.06.2013)
+!Discussion
-;Author
+|- style="vertical-align:top;"
-:ti
+|style="background-color: white;"|ti
-== EDold.01.01 ==
+|style="background-color: #E77471;"|rejected
+|style="background-color: white;"|EDold.01.01 : codeList
-;Comment
+|style="background-color: white;"|
-:Für IV Vertrag und Hausarztzentrierte Versorgung sollte in der Value(s) Spalte nicht von "event code", sondern einfach nur von "code" gesprochen werden.
+|style="background-color: white;"|
-;Author
+|style="background-color: white;"|Das für IV Vertrag und Hausarztzentrierte Versorgung gewählte Konstrukt, indem der displayName die für die Differenzierung entscheidende Information enthält, sehe ich kritisch. Es ist nun nicht mehr möglich anhand des codes eine Unterscheidung zwischen zwei verschiedenen IV Verträgen durchzuführen. Wenn für 2 IV Verträge jeweils eine Fallakte geführt wird, heisst dies, dass die Registry nicht anhand der codeList (d.h. codingScheme+code) alleine Filtern kann, sondern auch noch den ursprünglich verwendeten displayName heranziehen muss. Dies widerspricht ausserdem der Definition der codeListDisplayName in volume 3: "The list of human readable descriptions of the meaning of each of the codes present in the codeList." Es handelt sich hier nicht um eine menschenlesbare Erläuterung, sondern um ein kritisches Unterscheidungsmerkmal um unterschiedliche IV Verträge auseinanderzuhalten. Hier sollte auch bedacht werden, dass viele Systeme bei der Rückgabe von displayNames die eingesendete Variante ggf. durch eine normalisierte/kanonische und ggf. übersetzte Variante aus der eigenen Katalogverwaltung ersetzen. Sinnvoller wäre hier eine explizitere Kennzeichnung von Fallakten die auf IV (oder HA) Verträgen basieren. Anstelle von (oder zusätzlich zu) einem immer gleichen Kennzeichen (code="ECR", codeSystem="IHE-D-Cookbook-FolderClassCode"), könnte man die vier Fälle unterscheiden (DMP, IV, HA, DIAG für diagnose-basiert). Ähnlich haben wir das im Cookbook dargestellt: [http://wiki.hl7.de/index.php/IHE_DE_Cookbook#Abbildung_von_Ordnern_zur_Zweckbindung_durch_XDS_Folders]. Die besondere Problematik, wie man unterschiedliche IV und HA Verträge einheitlich benennt, ist aber auch dort nicht adressiert. Wenn man durch einen expliziten code diese Fälle unterscheiden kann und somit nicht das codingScheme zur Unterscheidung zwischen den 4 Fällen benutzen muss, kann man auch auf eine Projekt-spezifische Kennzeichnung von IV und HA Verträgen setzen. Solche Verträge die mittels Fallakte abgebildet werden sollen, würden dann bei allen betroffenen EFA Providern (entsprechend der in der 7er Gruppe diskutierten "Fachlichen Netzwerke") eine eindeutige Kennzeichnung (d.h. eine Kombination aus codingScheme und code) festlegen. (ti, 03.06.2013)
-:ti
+|style="background-color: white;"|Anhand der gegebenen Werte (07 und 09) sind IV-Vertrag und Hausarzt-zentierte Versorgung unterscheidbar.
-== EDold.01.01 ==
+|style="background-color: white;"|
+|- style="vertical-align:top;"
-;Comment
+|style="background-color: white;"|ti
-:Das für IV Vertrag und Hausarztzentrierte Versorgung gewählte Konstrukt, indem der displayName die für die Differenzierung entscheidende Information enthält, sehe ich kritisch. Es ist nun nicht mehr möglich anhand des codes eine Unterscheidung zwischen zwei verschiedenen IV Verträgen durchzuführen. Wenn für 2 IV Verträge jeweils eine Fallakte geführt wird, heisst dies, dass die Registry nicht anhand der codeList (d.h. codingScheme+code) alleine Filtern kann, sondern auch noch den ursprünglich verwendeten displayName heranziehen muss. Dies widerspricht ausserdem der Definition der codeListDisplayName in volume 3: "The list of human readable descriptions of the meaning of each of the codes present in the codeList." Es handelt sich hier nicht um eine menschenlesbare Erläuterung, sondern um ein kritisches Unterscheidungsmerkmal um unterschiedliche IV Verträge auseinanderzuhalten. Hier sollte auch bedacht werden, dass viele Systeme bei der Rückgabe von displayNames die eingesendete Variante ggf. durch eine normalisierte/kanonische und ggf. übersetzte Variante aus der eigenen Katalogverwaltung ersetzen. Sinnvoller wäre hier eine explizitere Kennzeichnung von Fallakten die auf IV (oder HA) Verträgen basieren. Anstelle von (oder zusätzlich zu) einem immer gleichen Kennzeichen (code="ECR", codeSystem="IHE-D-Cookbook-FolderClassCode"), könnte man die vier Fälle unterscheiden (DMP, IV, HA, DIAG für diagnose-basiert). Ähnlich haben wir das im Cookbook dargestellt: [http://wiki.hl7.de/index.php/IHE_DE_Cookbook#Abbildung_von_Ordnern_zur_Zweckbindung_durch_XDS_Folders]. Die besondere Problematik, wie man unterschiedliche IV und HA Verträge einheitlich benennt, ist aber auch dort nicht adressiert. Wenn man durch einen expliziten code diese Fälle unterscheiden kann und somit nicht das codingScheme zur Unterscheidung zwischen den 4 Fällen benutzen muss, kann man auch auf eine Projekt-spezifische Kennzeichnung von IV und HA Verträgen setzen. Solche Verträge die mittels Fallakte abgebildet werden sollen, würden dann bei allen betroffenen EFA Providern (entsprechend der in der 7er Gruppe diskutierten "Fachlichen Netzwerke") eine eindeutige Kennzeichnung (d.h. eine Kombination aus codingScheme und code) festlegen. (ti, 03.06.2013)
+|style="background-color: #89C35C;"|included
-;Author
+|style="background-color: white;"|EDold.01.01 : codeList
-:ti
+|style="background-color: white;"|