Cdampl:Probleme
(Teildokument von )
Foemig (Diskussion | Beiträge) |
(→Probleme mit dem AkdÄ-Medikationsplans) |
||
| Zeile 6: | Zeile 6: | ||
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: | 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: | ||
}} | }} | ||
| − | |||
* Grammatik für den Inhalt des Barcodes | * Grammatik für den Inhalt des Barcodes | ||
| Zeile 27: | Zeile 26: | ||
** Wie identifiziert man den Medikationsplan bzw. die Medikation? | ** 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. | ||
==Nutzbare Vorarbeiten== | ==Nutzbare Vorarbeiten== | ||
Version vom 18. Juli 2014, 14:19 Uhr
Dieses Material ist Teil des Leitfadens [[Category:|Cdampl:Probleme]].
|
Probleme mit dem AkdÄ-Medikationsplans
 |
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: |
- 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.
- Dosierangaben:
- Im Beispiel komt auch "1-0" und "1-0-1-0-1" vor, ohne das jetzt zu erklären.
- 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.
Nutzbare Vorarbeiten
- 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.
