Cdampl:Probleme

Dieses Material ist Teil des Leitfadens [[Category:|Cdampl:Probleme]]. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: [[:Category:|hier]], Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

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! -> 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!
  • Eine gemischte Darstellung von "1/2", "1/2" als ein Zeichen und "0,5" ist unschön.
• Einheiten:
  • Hier sollte auf Unified_Code_for_Units_of_Measure_(UCUM) gesetzt werden.
• Vokabularien
  • Einheiten
  • Doseforms
  • ..
• 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.)
• Workflow
  • Was soll passieren, wenn von 2 Seiten nur eine Seite eingescannt wird?
  • Wie geht man mit einem Update eines vorhergehenden Medikationsplanes um bzw. welche Beziehungen werden dazwischen aufgebaut?
  • Wie identifiziert man den Medikationsplan bzw. die Medikation?
  • ...

• 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.
  • 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.

• Standardbasiertheit
  • 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.

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.

Zertifizierungen für den Medikationsplan könnten unterteilt werden in:

• Layout
• Barcode
• Workflow

Lösungsvorschläge

Da die Größe des Barcodes als limitierend eingestuft wird, sollte es eine bijektive Abbildung in ein Standardformat (á la greenCDA) auf Basis einer öffentlich verfügbaren Bibliothek (Softwarekomponenten) geben, das die gemeinhin üblichen Probleme dauerhaft löst.

Nutzbare Vorarbeiten

• Implementierungsleitfaden im HL7-Wiki
• Implementierungsleitfaden von Fraunhofer FOKUS
• Implementierungsleitfaden der DKG
• 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.