Cdampl:Probleme - Versionsgeschichte

Foemig am 19. Dezember 2015 um 21:24 Uhr

2015-12-19T21:24:55Z

Foemig am 19. Dezember 2015 um 21:06 Uhr

2015-12-19T21:06:06Z

Wikiadmin am 10. Dezember 2014 um 20:08 Uhr

2014-12-10T20:08:24Z

Foemig am 9. Dezember 2014 um 13:53 Uhr

2014-12-09T13:53:39Z

Foemig am 9. Dezember 2014 um 13:51 Uhr

2014-12-09T13:51:30Z

Foemig am 9. Dezember 2014 um 13:01 Uhr

2014-12-09T13:01:22Z

Foemig am 9. Dezember 2014 um 13:00 Uhr

2014-12-09T13:00:54Z

Foemig am 9. Dezember 2014 um 12:47 Uhr

2014-12-09T12:47:02Z

Wikiadmin: /* Probleme mit dem AkdÄ-Medikationsplans */

2014-07-18T14:19:01Z

‎Probleme mit dem AkdÄ-Medikationsplans

Foemig am 15. Juli 2014 um 08:43 Uhr

2014-07-15T08:43:52Z

@@ Zeile 7: / Zeile 7: @@
 ==Probleme mit dem AkdÄ-Medikationsplan==
 * Grammatik für den Inhalt des Barcodes
 ** Um den Inhalt des Barcodes korrekt parsen zu können, muss ein sogenanntes Look-Ahead/Backtracking implementiert werden, da nicht an jeder Position klar ist, an welcher Stelle man sich im Inhalt befindet. Dies könnte durch eine kleinere Korrektur behoben werden! -&gt; [[Cdampl:Grammatik]]

@@ Zeile 4: / Zeile 4: @@
 So sehr die grundlegende Arbeit und inhaltliche Vorgabe des AkdÄ-Medikationsplanes begrüßt wird, so sind dennoch noch Probleme zu lösen, die später im praktischen Einsatz mitunter die Patientensicherheit gefährden können:
 }}
 ==Probleme mit dem AkdÄ-Medikationsplan==
 * Grammatik für den Inhalt des Barcodes
-** Um den Inhalt des Barcodes korrekt parsen zu können, muss ein sogenanntes Look-Ahead implementiert werden, da nicht an jeder Position klar ist, an welcher Stelle man sich im Inhalt befindet. Dies kann durch eine kleinere Korrektur behoben werden! -&gt; [[Cdampl:Grammatik]]
+** Um den Inhalt des Barcodes korrekt parsen zu können, muss ein sogenanntes Look-Ahead/Backtracking implementiert werden, da nicht an jeder Position klar ist, an welcher Stelle man sich im Inhalt befindet. Dies könnte durch eine kleinere Korrektur behoben werden! -&gt; [[Cdampl:Grammatik]]
 **Grundsätzlich sollte hier aber Synergien mit entsprechenden Standards gesucht werden. (Oemig: "Der CDA-basierte Medikationsplan - Eine Win-Win-Situation?" in "eHealth 2014 - Sonderausgabe Medikationsplan", Hrsg: Prof. Dr. Frank Duesberg, Gunther Hellmann, medical future verlag, ISBN: 978-3-9814005-7-1, p.59ff, http://www.medical-future-verlag.de )
 * Inhalt des Freitextes
 ** Hier müssen die entsprechenden Texte in der Anwendung hinterlegt werden.
 ** Wie soll eine Anwendung einen Freitext komprimieren?
 * Zeichensatz:
 ** Bestimmte Zahlen ("1/2") werden als einzelnes Zeichen repräsentiert. Die korrekte Darstellung hängt von der Berücksichtigung des Zeichensatzes ab.
 ** Der Zeichensatz wird aber (meistens) nicht korrekt umgesetzt bzw. berücksichtigt. Insofern fehlt zumindest ein konkreter Hinweis, dass alle Vorgaben in der Spezifikation korrekt und vollständig umgesetzt werden müssen!
@@ Zeile 32: / Zeile 36: @@
 *Syntax
 ** Die im Medikationsplan beschriebene Syntax ist proprietär. Um Daten aus einer Anwendung in die beschriebene Form zu bringen (Serialisierung) ist ein spezialistischer Generator nötig. Diesen muss jedes Softwareunternehmen entweder selber schreiben oder er wird von Ihrer Seite zur Verfügung gestellt. Ob ein solcher Generator prototypisch bereits irgendwo existiert, ist unbekannt. Der Serialisierer ist allerdings auch der einfachste Teil.
-** Um die Daten, die in dieser Syntax eingebettet sind, wieder auslesen zu können, z. B. um sie weiterzuverwenden, muss von jedem Anbieter von Software ein spezialistischer und robuster Parser programmiert bzw eingesetzt werden. Der Parser verwandelt die serialisierte Form wieder in Datenobjekte der lesenden Anwendung um, damit diese weiterverwendet oder geändert und in eine neue Version des Plans für den Patienten umgesetzt werden können. Auch hier ist unklar ob dieser prototypisch existiert. Parser müssen robust sein, weil man davon ausgehen muss, dass nicht alle Serialisierungen korrekt sind und man eine Chance haben muss, dies auch zu entdecken.
+** Um die Daten, die in dieser Syntax eingebettet sind, wieder auslesen zu können, z. B. um sie weiterzuverwenden, muss von jedem Anbieter von Software ein spezialistischer und robuster Parser programmiert bzw eingesetzt werden. Der Parser verwandelt die serialisierte Form wieder in Datenobjekte der lesenden Anwendung um, damit diese weiterverwendet oder geändert und in eine neue Version des Plans für den Patienten umgesetzt werden können. Auch hier ist unklar, ob dieser prototypisch existiert. Parser müssen robust sein, weil man davon ausgehen muss, dass nicht alle Serialisierungen korrekt sind und man eine Chance haben muss, dies auch zu entdecken.
 ** Für die Sicherstellung, ob ein Datensatz in dieser Syntax formal korrekt serialisiert ist braucht man einen Validator der die Regeln der Syntax überprüft. Dazu ist es auch nötig, die zugrundeliegende Grammatik formal zu beschreiben, zum Beispiel in der üblichen Backus-Naur-Form. Ohne Validator, der auch Bestandteil des Parsers sein kann, ist eine Garantie darauf, dass die Daten korrekt wiedergegeben und wiederverwendet werden können nicht gegeben. Eine geplante Zertifizierung ist ohne Validator äußerst schwierig.
 ** Die Syntax mischt manchmal Anweisungen zum Druck für die Papierfassung mit den eigentlichen Daten. Ein Parser muss diese Druckinstruktionen aus der Serialisierung holen, denn diese können sich bei veränderten Daten natürlich auch ändern. Üblich ist Struktur und Präsentation zu trennen.
@@ Zeile 42: / Zeile 46: @@
 ==Zertifizierung==
-Für eine Zertizifierung muss die Spezifikation überarbeitet bzw. ergänzt werden, um klare Vorgabem zu bekommen, was in welchem Umfang wofür geprüft wird. Derzeit enthält die Spezifikation keinerlei Konformanzkriterien, die eine Zertifizierung ermöglichen. Demnach sind '''alle''' Angaben als MUSS-Kriterien aufzufassen, eine Abweichung ist nicht zulässig.
+Für eine Zertizifierung muss die Spezifikation überarbeitet bzw. ergänzt werden, um klare Vorgaben zu bekommen, was in welchem Umfang wofür geprüft wird. Die ersten Versionen der Spezifikation (bis 2.0) enthielten keinerlei Konformanzkriterien, die eine Zertifizierung ermöglichen. Demnach sind '''alle''' Angaben als MUSS-Kriterien aufzufassen, eine Abweichung ist nicht zulässig.
 Zertifizierungen für den Medikationsplan könnten unterteilt werden in:

@@ Zeile 4: / Zeile 4: @@
 So sehr die grundlegende Arbeit und inhaltliche Vorgabe des AkdÄ-Medikationsplanes begrüßt wird, so sind dennoch noch Probleme zu lösen, die später im praktischen Einsatz mitunter die Patientensicherheit gefährden können:
 }}
-==Probleme mit dem AkdÄ-Medikationsplans==
+==Probleme mit dem AkdÄ-Medikationsplan==
 * Grammatik für den Inhalt des Barcodes

@@ Zeile 18: / Zeile 18: @@
 * Einheiten:
 **Hier sollte auf [[Unified_Code_for_Units_of_Measure_(UCUM)]] gesetzt werden.
 * Dosierangaben:
 ** Im Beispiel kommt auch "1-0" und "1-0-1-0-1" vor, ohne das jetzt zu erklären. (Somit ist die Spezifikation in sich nicht konsistent.)

@@ Zeile 11: / Zeile 11: @@
 * Inhalt des Freitextes
 ** Hier müssen die entsprechenden Texte in der Anwendung hinterlegt werden.
-**Wie soll eine Anwendung einen Freitext komprimieren?
+** Wie soll eine Anwendung einen Freitext komprimieren?
 * Zeichensatz:
 ** Bestimmte Zahlen ("1/2") werden als einzelnes Zeichen repräsentiert. Die korrekte Darstellung hängt von der Berücksichtigung des Zeichensatzes ab.
@@ Zeile 19: / Zeile 19: @@
 **Hier sollte auf [[Unified_Code_for_Units_of_Measure_(UCUM)]] gesetzt werden.
 * Dosierangaben:
-** Im Beispiel komt auch "1-0" und "1-0-1-0-1" vor, ohne das jetzt zu erklären.
+** Im Beispiel kommt auch "1-0" und "1-0-1-0-1" vor, ohne das jetzt zu erklären. (Somit ist die Spezifikation in sich nicht konsistent.)
 *Workflow
 ** Was soll passieren, wenn von 2 Seiten nur eine Seite eingescannt wird?
@@ Zeile 35: / Zeile 35: @@
 **Wenn mit dem QR-Code eine Standardbasiertheit gegeben ist, dann hätte ein Verweis auf DIN/A4 auch gereicht.
 **Unter Standardbasiertheit im Sinne einer semantischen Interoperabilität wird normalerweise die Nutzung von Vokabularien oder anderen High-Level-Standards wie bspw. ISO/HL7 27932:2009 verstanden.
 ==Nutzbare Vorarbeiten==
@@ Zeile 40: / Zeile 53: @@
 *[[IG:AKd%C3%84-Medikationsplan|Implementierungsleitfaden im HL7-Wiki]]
 *Implementierungsleitfaden von Fraunhofer FOKUS
 *epSOS
   Optimal wäre eine Kooperation und Kombination dieser Spezifikationen und Lösungsansätze!
   Auch ist nicht viel zu ändern, um diese Problem zu beseitigen.
 [[Kategorie:cdampl|Probleme]]