Cdampl:Grammatik

Aus Hl7wiki
(Teildokument von )
Wechseln zu: Navigation, Suche
 
(3 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
 
==aktuelle Grammatik==
 
==aktuelle Grammatik==
  
Dies ist eine kontextfreie BNF-Grammatik für den Medikationsplan in der Version 1.3:
+
Nachfolgend die kontextfreien BNF-Grammatiken für den Medikationsplan in der jeweiligen Version. Die erste Fassung ist die BAsis, danach folgen die Abwandlungen:
 +
 
 +
===Version 1.3===
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 18: Zeile 20:
 
|  
 
|  
 
|-
 
|-
| <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>
+
| <Inhalt> ::= <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> <Hauptblock> <5.3> <Prüsumme>
| &nbsp;
+
| 2.1=Patientenname, 2.2=Geburtsdatum, 2.4=Datum der Erstellung
 
|-
 
|-
 
| <Parameter >::= <2.12> <2.12> <2.12>
 
| <Parameter >::= <2.12> <2.12> <2.12>
Zeile 28: Zeile 30:
 
(15 mal wiederholbar)<br/>
 
(15 mal wiederholbar)<br/>
 
An dieser Stelle ist ein Look-Ahead zu implementieren, um beim Parsen eine korrekte Entscheidung treffen zu können.<br/>
 
An dieser Stelle ist ein Look-Ahead zu implementieren, um beim Parsen eine korrekte Entscheidung treffen zu können.<br/>
Eine freu Zwischenüberschrift muss ggf. noch von den vordefinierten abgegrenzt werden.
+
Eine freie Zwischenüberschrift muss ggf. noch von den vordefinierten abgegrenzt werden.
 
|-
 
|-
 
| <Medikation> := <4.1> <4.2> <4.3> <4.4> <4.5> <4.6> <4.7> <4.8>
 
| <Medikation> := <4.1> <4.2> <4.3> <4.4> <4.5> <4.6> <4.7> <4.8>
Zeile 91: Zeile 93:
 
{{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 entstündige 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.
+
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.  
 
}}
 
}}
  
===Probleme mit der Grammatik===
+
===Version 1.7===
 +
 
 +
Abwandlungen für die Version 1.7:
 +
 
 +
{| class="hl7table"
 +
|-
 +
!Grammatik!!Kommentar
 +
|-
 +
| <Inhalt> ::= <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> <2.11><Parameter> <Hauptblock> <6.1> <6.3> <6.4> <6.5> <Prüsumme>
 +
| 2.1=Patientenvorname, 2.2=Patientennachname, 2.4=Geburtsdatum
 +
 
 +
|}
 +
 
 +
===Version 2.0===
  
Diese Grammatik weist zwei fundamentale Probleme auf:
+
Abwandlungen für die Version 2.0:
 +
 
 +
{| class="hl7table"
 +
|-
 +
!Grammatik!!Kommentar
 +
|-
 +
| <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> <Prüsumme>
 +
| &nbsp;
 +
 
 +
|}
 +
 
 +
==Probleme mit der Grammatik==
 +
 
 +
Diese Grammatik weist (zwei) fundamentale Probleme auf:
 
#Backtracking/Lookahead
 
#Backtracking/Lookahead
 
#Mehrdeutigkeit
 
#Mehrdeutigkeit
 +
#Versionierung
  
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 im Encoding, die durch geschickte Ausnutzung zu einer Patientengefährdung führen kann, da keine geeignete Validierung vorhanden ist.  
+
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.
 +
 
 +
Darüber hinaus muss noch eine eindeutige Versionierung vorgesehen werden. Dafür gibt es zwar ein Feld, die zu verwendende Angabe lässt sich aber nur aus einem informativen Beispiel entnehmen. Wie aus der Grammatik ersichtlich ist, ergeben sich strukturelle Änderungen. Aber auch Änderungen am Inhalt sind nicht ausgeschlossen, so dass hier eine explizite Vorgabe gemacht werden muss.
 +
 
 +
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"
Zeile 129: Zeile 163:
 
Nachteile:
 
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.
 
* 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.
 +
 +
==Alternative==
 +
 +
{{NoteBox|Der fachlogische Inhalt des Medikationsplans kann verlustfrei auch in XML transportiert werden. Das erspart die Entwicklung eines eigenen Parsers. Das XML-Schema ermöglich zudem eine Validierung der Daten.
 +
Die Alternativspezikation heißt [[IG:Ultrakurzformat_Patientenbezogener_Medikationsplan| Ultrakurzformat]].
 +
 +
Damit werden die auch Probleme des technischen Teils der MP-Spezifikation gelöst, die mit der Grammatik noch nicht adressiert sind.
 +
}}
  
 
[[Kategorie:cdampl|Grammatik]]
 
[[Kategorie:cdampl|Grammatik]]

Aktuelle Version vom 7. März 2016, 08:25 Uhr

Dieses Material ist Teil des Leitfadens [[Category:|Cdampl:Grammatik]].
  • 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 .

aktuelle Grammatik

Nachfolgend die kontextfreien BNF-Grammatiken für den Medikationsplan in der jeweiligen Version. Die erste Fassung ist die BAsis, danach folgen die Abwandlungen:

Version 1.3

Grammatik Kommentar
MP ::= „MP“ <Trenner> <Feld> „#@“  
<Feld> ::= <Inhalt> <Trenner> [ <Feld> ]  
<Trenner> ::= „|“  
<Inhalt> ::= <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> <Hauptblock> <5.3> <Prüsumme> 2.1=Patientenname, 2.2=Geburtsdatum, 2.4=Datum der Erstellung
<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)
An dieser Stelle ist ein Look-Ahead zu implementieren, um beim Parsen eine korrekte Entscheidung treffen zu können.
Eine freie Zwischenüberschrift muss ggf. noch von den vordefinierten abgegrenzt werden.

<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>
<Y> ::= <Dosierungscode>
<Z> ::= <Dosierungscode>

Dosierung
<Dosierungscode> ::= „<“ | „>“ | „0-9“ | „A-Z“ Tab.12 auf Seite 58
<Hinweistext> ::= <Freitext> | <Einnahmezeitpunkt> | <Lagerung> | <Zubereitung> | <Anwendung> | <Besonderheit> [ „#“ <Hinweistext> ]


<Einnahmezeitpunkt> ::= „E“ „1-9“ | „E10“
<Lagerung> ::= „L“ „1-6“
<Zubereitung> ::= „Z“ „1-4“
<Anwendung> ::= „A“ „0-9“
<Besonderheit> ::= „B“ „1-5“

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 > ]

Version 1.7

Abwandlungen für die Version 1.7:

Grammatik Kommentar
<Inhalt> ::= <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> <2.11><Parameter> <Hauptblock> <6.1> <6.3> <6.4> <6.5> <Prüsumme> 2.1=Patientenvorname, 2.2=Patientennachname, 2.4=Geburtsdatum

Version 2.0

Abwandlungen für die Version 2.0:

Grammatik Kommentar
<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> <Prüsumme>  

Probleme mit der Grammatik

Diese Grammatik weist (zwei) fundamentale Probleme auf:

  1. Backtracking/Lookahead
  2. Mehrdeutigkeit
  3. Versionierung

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.

Darüber hinaus muss noch eine eindeutige Versionierung vorgesehen werden. Dafür gibt es zwar ein Feld, die zu verwendende Angabe lässt sich aber nur aus einem informativen Beispiel entnehmen. Wie aus der Grammatik ersichtlich ist, ergeben sich strukturelle Änderungen. Aber auch Änderungen am Inhalt sind nicht ausgeschlossen, so dass hier eine explizite Vorgabe gemacht werden muss.

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.

Alternative