| ID
|
Author
|
Status
|
Section
|
Vote
|
Existing
|
Proposed
|
Comment
|
Comment Editor
|
Discussion
|
| 95
|
ti
|
rejected
|
EDold.01.01 : codeList
|
|
|
|
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: [1]. 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)
|
Anhand der gegebenen Werte (07 und 09) sind IV-Vertrag und Hausarzt-zentierte Versorgung unterscheidbar.
|
|
| 96
|
ti
|
included
|
EDold.01.01 : codeList
|
|
|
|
Mir fehlt hier noch ein expliziterer Hinweis auf das logische Konzept purpose das über die codeList abgebildet wird. (ti, 03.06.2013)
|
Ein Verweis auf das Business-Informationmodell-Element purpose wurde eingefügt. (bk)
|
|
| 97
|
ti
|
included
|
EDold.01.01 : codeList
|
|
|
|
Für IV Vertrag und Hausarztzentrierte Versorgung sollte in der Value(s) Spalte nicht von "event code", sondern einfach nur von "code" gesprochen werden.
|
Korrigiert. (bk)
|
|
| 98
|
ti
|
rejected
|
EDold.01.01 : codeList
|
|
|
|
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)
|
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)
|
|
| 99
|
ti
|
postponed
|
EDold.01.01 : codeList
|
|
|
|
Die zulässiges Codes für den Zweck einer Fallakte sollten als Value-Set bereitgestellt werden.
|
Ok. Das organisatorische Vorgehen und die Form der Bereitstellung muss mit dem EFA-Verein und mit dem IHE-D-Cookbook abgestimmt werden (bk, 12.09.2014)
|
|
