Cdampl:Probleme
(Teildokument von )
Dieses Material ist Teil des Leitfadens [[Category:|Cdampl:Probleme]].
|
 |
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: |
Inhaltsverzeichnis
Probleme mit dem AkdÄ-Medikationsplan
- Versionierung
- Der Medikationsplan wurde mehrfach überarbeitet und als neue Version herausgegeben. Die Änderungen sind jedoch nicht nachvollziehbar dokumentiert.
- 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! -> 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 )
- Mehrdeutigkeit: Das Encoding garntiert keine korrekte Darstellung, da eine fehlerhafte Verwendung nicht systematisch verhindert wird und somit eine mehrdeutige Interpretation zulassen.
- Inhalt des Freitextes
- Hier müssen die entsprechenden Texte in der Anwendung hinterlegt werden.
- Wie soll eine Anwendung einen Freitext komprimieren?
- Bestimmte Zeichen müssen durch die Anwendung blockiert werden.
- Zeichensatz:
- ASCII: lässt nur 7-Bit-Zeichen zu, und somit keine deutschen Umlaute
- 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 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. Neuere Arbeiten (ebenfalls 2.0) führen Toleranzen ein.
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.
