Cdampl:Grammatik
Foemig (Diskussion | Beiträge) |
Foemig (Diskussion | Beiträge) |
||
Zeile 91: | Zeile 91: | ||
{{NoteBox|Auch wenn diese Grammatik für die Version 1.3 ausgearbeitet wurde, sind die Probleme mit 2.0 immer noch nicht gelöst. | {{NoteBox|Auch wenn diese Grammatik für die Version 1.3 ausgearbeitet wurde, sind die Probleme mit 2.0 immer noch nicht gelöst. | ||
− | Wenn die Version 2.0 in diese Grammatik mit eingebaut wird - und das wäre für die Hersteller notwendig - so | + | Wenn die Version 2.0 in diese Grammatik mit eingebaut wird - und das wäre für die Hersteller notwendig - so entstünde eine kontextbehaftete Grammatik, die die Struktur von der Version abhängig ist. Ein Beispiel dafür ist das Feld 2.3, das in der Version 2.0 nicht mehr vorkommt. |
}} | }} | ||
Zeile 100: | Zeile 100: | ||
#Mehrdeutigkeit | #Mehrdeutigkeit | ||
− | Der erste Punkt führt eine Ineffizienz ein, die nicht notwendig ist. Auf Generatorseite ist dies zweitrangig, auf der Parserseite muss hier durch jeden Hersteller erhöhter Aufwand betrieben werden, der eigentlich unnötig wäre. Damit sind Kosten verbunden, die getragen werden müssen. | + | Der erste Punkt führt eine Ineffizienz ein, die nicht notwendig ist. Auf Generatorseite ist dies zweitrangig, auf der Parserseite muss hier durch jeden Hersteller erhöhter Aufwand betrieben werden, der eigentlich unnötig wäre. Damit sind Kosten verbunden, die letztendlich getragen werden müssen. |
− | Der zweite Punkt muss gemäß Absatz A2.4 der AkdÄ-Spezeifikation durch die Software unterbunden werden. Somit fehlt eine Absicherung | + | Der zweite Punkt muss gemäß Absatz A2.4 der AkdÄ-Spezeifikation durch die Software unterbunden werden. Somit fehlt im Encoding eine Absicherung, die Fehler erkennen lässt und eine fehlerhafte Verwendung verhindert. Durch eine geschickte Ausnutzung kann dies letztendlich zu einer Patientengefährdung führen, da keine geeignete Validierung vorhanden ist. Es muss somit konstatiert werden, dass das vorgebene Encoding nicht State of the Art ist sondern eherfahrlässig. |
+ | |||
+ | Bei einer zunehmenden Verbreitung und Einsatz der AkdÄ-Spezifikation dürften die vorhandenen Gefahren nicht zu unterschätzende Risiken darstellen. | ||
==Vorschläge für eine Verbesserung== | ==Vorschläge für eine Verbesserung== | ||
+ | Die nachfolgenden Vorschläge lösen lediglich das Backtracking-Problem: | ||
{| class="hl7table" | {| class="hl7table" |
Version vom 19. Dezember 2015, 22:35 Uhr
Dieses Material ist Teil des Leitfadens [[Category:|Cdampl:Grammatik]].
|
aktuelle Grammatik
Dies ist eine kontextfreie BNF-Grammatik für den Medikationsplan in der Version 1.3:
Grammatik | Kommentar |
---|---|
MP ::= „MP“ <Trenner> <Feld> „#@“ | |
<Feld> ::= <Inhalt> <Trenner> [ <Feld> ] | |
<Trenner> ::= „|“ | |
<Inhalt> ::= <6.1> <6.3> <6.4> <6.5> <2.11> <1.2> <1.3> <1.4> <2.1> <2.2> <2.3> <2.4> <2.5> <2.6> <2.7> <2.8> <2.9> <2.10> <Parameter> <Hauptblock> <Text> <Prüsumme> | |
<Parameter >::= <2.12> <2.12> <2.12> | Genau 3 Parameter |
<Hauptblock> ::= ( <Medikation> | „$“ <Zwischenüberschrift-Code> | „$“ <Zwischenüberschrifttext> | „@“ <Freitext> ) * 15 | Dies geht so aus der Spezifikation nicht hervor, ist wohl aber so gemeint! (15 mal wiederholbar) |
<Medikation> := <4.1> <4.2> <4.3> <4.4> <4.5> <4.6> <4.7> <4.8> | Als Block von 8 Elementen |
<ZwischenüberschriftCode> ::= „411“ | „412“ | ... | „418“ | Referenzieren den entsprechenden Text (S.25) |
<Freitext> ::= <bel. Text> | „#“ + < Code aus Anlage 2.3 > | |
<4.1> ::= „“ | <PZN> | <Freitext> |
|
<4.2> ::= „“ | <PZN> | <Freitext> |
|
<4.3> ::= „“ | <Wirkstärke> |
|
<4.4> ::= „“ | <Darreichungsform> |
|
<4.5> ::= „“ | <X> „-„ <Y> „-„ <Z> | <W> „-„ <X> „-„ <Y> „-„ <Z> |
|
<4.7> ::= „“ | <Hinweistext> | XY |
|
<4.8> ::= < Behandlungsgrund > | <Freitext> | XYYYYY | |
<Wirkstärke> ::= <Zahl> „ „ <Einheit> | <Freitext> | Ist so in der Spezifikation nicht dargestellt. |
<Darreichungsform> ::= <IFA-Code> | Tab.11 auf Seite 55-57 3-stellig |
<W> ::= <Dosierungscode> <X> ::= <Dosierungscode> |
Dosierung |
<Dosierungscode> ::= „<“ | „>“ | „0-9“ | „A-Z“ | Tab.12 auf Seite 58 |
<Hinweistext> ::= <Freitext> | <Einnahmezeitpunkt> | <Lagerung> | <Zubereitung> | <Anwendung> | <Besonderheit> [ „#“ <Hinweistext> ]
|
Tab.13/14/15/16/17 auf Seite 60ff. Hier muss darauf geachtet werden, dass nicht jeder Freitext zugelassen ist! |
<Behandlungsgrund> ::= <Freitext> | „Z0 | „Z1“ > [ „#“ < Behandlungsgrund > ] |
Probleme mit der Grammatik
Diese Grammatik weist zwei fundamentale Probleme auf:
- Backtracking/Lookahead
- Mehrdeutigkeit
Der erste Punkt führt eine Ineffizienz ein, die nicht notwendig ist. Auf Generatorseite ist dies zweitrangig, auf der Parserseite muss hier durch jeden Hersteller erhöhter Aufwand betrieben werden, der eigentlich unnötig wäre. Damit sind Kosten verbunden, die letztendlich getragen werden müssen.
Der zweite Punkt muss gemäß Absatz A2.4 der AkdÄ-Spezeifikation durch die Software unterbunden werden. Somit fehlt im Encoding eine Absicherung, die Fehler erkennen lässt und eine fehlerhafte Verwendung verhindert. Durch eine geschickte Ausnutzung kann dies letztendlich zu einer Patientengefährdung führen, da keine geeignete Validierung vorhanden ist. Es muss somit konstatiert werden, dass das vorgebene Encoding nicht State of the Art ist sondern eherfahrlässig.
Bei einer zunehmenden Verbreitung und Einsatz der AkdÄ-Spezifikation dürften die vorhandenen Gefahren nicht zu unterschätzende Risiken darstellen.
Vorschläge für eine Verbesserung
Die nachfolgenden Vorschläge lösen lediglich das Backtracking-Problem:
Grammatik | Kommentar |
---|---|
<Hauptblock> ::= ( "1" <Medikation-8> | "2" <Medikation-9> | „3“ <Zwischenüberschrift-Code> | „4“ <Zwischenüberschrifttext> | „5“ <Freitext> ) * 15 | Der Hauptblock kennzeichnet konkret die nachfolgenden Inhalte. Dadurch entfallten die Sonderzeichen "$" und "@". |
<Medikation-8> := <4.1> <4.2> <4.3> <4.4> <4.5> <4.6> <4.7> <4.8> | Als Block von 8 Elementen |
<Medikation-9> := <4.1> <4.2> <4.3> <4.4> <4.5> <4.6> <4.7> <4.8> <4.9> | Als Block von 9 Elementen, d.h. hier ist dann das Element für "2.0+" mit dabei. |
Vorteile:
- Entfall des Sonderzeichens "$" zur Kennzeichnung
- kein Look-Ahead notwendig
- vereinfachte Implementierung
- einfachere Versionierung des Hauptblocks
Nachteile:
- Für den Inhalt des Barcodes werden 15 (nur Text) bis 30 Zeichen (nur Medikamente) mehr benötigt. Für die Patientensicherheit sollte dies akzeptabel sein.