AkdÄ-Medikationsplan auf der Basis von CDA R2

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
Zeile 30: Zeile 30:
 
{{Infobox Contributors End}}
 
{{Infobox Contributors End}}
  
 +
{{AlertBox|
 +
Es erscheint in Kürze der ''Patientenorientierte Medikationsplan'', der zur Abstimmung gestellt werden wird.
 +
An dieser Stelle werden lediglich Hinweise zum Medikationsplan der AkdÄ gegeben.
 +
}}
  
 
{{HL7transclude| cdampl:Einleitung}}
 
{{HL7transclude| cdampl:Einleitung}}
Zeile 64: Zeile 68:
 
*...
 
*...
 
-->
 
-->
{{AlertBox|
 
Hier erscheint in Kürze der Medikationsplan, der zur Abstimmung gestellt werden wird.
 
}}
 
 
=Referenzen=
 
=Referenzen=
 
[http://www.akdae.de/AMTS/Massnahmen/docs/Medikationsplan.pdf http://www.akdae.de/AMTS/Massnahmen/docs/Medikationsplan.pdf]
 
[http://www.akdae.de/AMTS/Massnahmen/docs/Medikationsplan.pdf http://www.akdae.de/AMTS/Massnahmen/docs/Medikationsplan.pdf]

Version vom 16. November 2014, 10:27 Uhr


Kontributoren 
Logo-Agfa.jpg Agfa HealthCare GmbH Bonn
Logo-Siemens.jpg Siemens AG Healthcare Sector Erlangen
100px Tieto Deutschland GmbH Köln


Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • 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: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Einleitung

Die Arzneimittelkommission der deutschen Ärzteschaft (AKdÄ) hat zusammen mit der AG AMTS des bvitg eine Spezifikation für einen Medikationsplan erstellt (www.akdae.de/AMTS/Massnahmen/docs/Medikationsplan.pdf). Diese Spezifikation dient primär für einen Ausdruck der aktuellen Medikation, um diese dem Patienetn mitzugeben. Über einen Barcode ist auch ein Austausch der aktuellen Medikationsdaten zwischen APIS und KIS möglich. Hier stand eine möglichst einfache Umsetzbarkeit sowie ein Datenaustausch über den Barcode im Vordergrund. Die proprietäre Spezifikation wurde und wird mit der Längenbeschränkung des Barcodecarriers begründet.

Diese Initialfassung eines Implementierungsleitfadens demonstriert, dass diese Spezifikation auch mit CDA sehr leicht umsetzbar ist (vgl. Layoutbeispiele nachfolgend).

Alternativen

Die im Interoperabilitätsforum durchgeführten Arbeiten haben eindruckscoll bewiesen, dass die inhaltlichen Vorgaben des BMP verlustfrei auf Basis von Standards realisiert werden können. Alle Anforderungen sind über den patientenbezogenen Medikationsplan mit Hilfe von XML umsetzbar. Die Längenbeschränkung des Barcode-Carriers führen jedoch dazu, dass ein vollständiges CDA-Dokument nicht direkt darin enthalten sein kann. Durch eine bijektive Transformation ist jedoch eine verkürzte und vereinfachte XML-Darstellung möglich. Hierdurch werden zum einen XML-Basis-Tools nutzbar, für die es umfangreiche Bibliotheken gibt, zum anderen hat jeder Hersteller die freie Wahl, ob er die verkürzte XML-Fassung oder ein korrekte CDA-Dokument nutzen möchte. Darüber hinaus ist eine Validierung der Inhalte möglich.

Die Spezifikation ist als PMP fertig erstellt, abgestimmt, verfügbar und in NRW erfolgreich im Test.

Damit ist unerklärbar, warum an der nachteiligen, ineffizenten, mehrdeutigen, proprietären und somit Zusatzaufwände produzierenden technischen Spezifkation festgehalten wird.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • 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: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Original-Layout

Nachfolgend das Layout als Auszug aus der Originalspezifikation:

AKdÄ Layout

CDA-Layout

Nun das Layout, das durch ein Stylesheet aufbereitet wurde. Das Datamatrix-Barcode wurde dabei aus dem Observation-Entry gerendert:

CDA Layout

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • 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: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Umsetzungsmöglichkeiten

Der Medikationsplan kann auf unterschiedliche Weise mit jeweils individuellen Vor- und Nachteilen umgesetzt werden. Diese werden nachfolgend kurz aufgelistet.

1. PDF in CDA

Die einfachste Möglichkeit ist der Ausdruck gemäß AKdÄ-Spezifikation mit Einbettung des daraus entstehenden PDFs in einem CDA-Dokument. Damit wäre aber keine Wiederverwendbarkeit gegeben, die auch zu einer neuen Version des Dokuments führt. Dieshalb wird diese Version hier wieder verworfen.

2. einfaches CDA mit 2 Abschnitten und simplen Entry

Diese Variante ist nicht kompliziert und entspricht am ehesten einer direkten Umsetzung der Originalspezifikation. Hierbei können die Daten ebenfalls geparst und auch als Datamatrixcode ausgedruckt werden. Das ist die hier verfolgte einfache Variante.

3. CDA mit Modell auf Entrylevel

Hier werden die Daten in einzelnen Entries repräsentiert. Damit wird jede Information einzeln beschrieben und auch wiederverwendbar. Jedoch wird die Spezifikation insgesamt deutlich umfangreicher und komplizierter, der Barcode muss dann erst errechnet werden. Hier sollten dann Sektions und Entries erarbeitet werden, die auch in anderen Dokumenttypen wiederverwendet werden können.

Diese Variante wird hier auf Basis des Addendums Medikation beschrieben.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • 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: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Anhang

Felder aus dem AKdÄ-Medikationsplan (1.3)

Feld- code Bezeichnung Datenfeld Syntax Feldlänge und zulässige Werte Instanz kommt aus der Datenquelle Identität zu Ausdruck
1.1 Identifikation "MP" fix Anlage 2 entsprechend
1.2 Seite von X Länge: 1 Zahl Werte: \[1,2,3\] Software absolut identisch mit Ausdruck
1.3 Gesamtseitenzahl Y Länge: 1 Zahl Werte: \[1,2,3\] Software absolut identisch mit Ausdruck
1.5 Zertifizierungsstatus X 1 Zeichen

"j" oder "n" für ja oder nein||Software||Entsprechend dem Zertifizierungslogo(1.4)

2.1 Patientenname Freitext Länge: 1 – 40 Zeichen Software absolut identisch mit Ausdruck
2.2 Geburtsdatum des Patienten TTMM(j)JJJ Länge: 9 Zeichen

Werte >01.01.1890||Software ||inhalt identisch,Format angepasst

2.3 Ersteller des MP Freitext Länge: 0 - 25 Zeichen Software absolut identisch mit Ausdruck
2.4 Datum der Erstellung TTMM((jj)JJ Länge: 8 Zeichen

Werte >=01.07.2012||Software ||inhalt identisch, Format angepasst.

2.5 Kontaktdaten der Erstellers Freitext Länge: 0 – 50 Zeichen Software absolut identisch mit Ausdruck
2.6 Sonstige Angaben Freitext Länge: 0 – 50 Zeichen Software, Schlüsselworte von Anlage 2 absolut identisch mit Ausdruck
3.1 Wirkstoffname bleibt leer, wenn Arzneimittel über PZN eindeutig identifiziert. über PZN eindeutig zuordenbar
ATC:
mindestens5 stellig
Länge: 5 – 8 Zeichen
Werte: ATC-Code
akueller ATC laut Anlage 1 Die Wirkstoffbezeichnung ist dem ATC-Code entsprechend; Es ist keine PZN verfügbar.
Freitext Länge: 0 - 30 Zeichen Anwender gibt Wert über Software ein Absolut identisch; es ist keine PZN noch ATC-Code verfügbar.
3.2 Handelsname PZN
(ab 1.1.13: PZN-8)
Länge: 7(8 Ziffern) AM-Datenbanken, entsprechend der Fachinformation, AMG §11a Entsprechend
Freitext Länge: 0 - 40 Zeichen Anwender gibt Wert über Software ein absolut identisch mit Ausdruck
3.3 Wirkstärke bleibt leer, wenn Arzneimittel über PZN eindeutig identifiziert. über PZN eindeutig zuordenbar
Freitext Länge: 0 – 8 Zeichen Anwender gibt Wert über Software ein absolut identisch mit Ausdruck
3.4 Darreichungsform Freitext Länge: 0 – 7 Zeichen Anwender gibt Wert über Software ein absolut identisch mit Ausdruck
3.5 Dosierschema Freitext Länge: 0 – 10 Zeichen Anwender gibt Werte über Software ein absolut identisch mit Ausdruck
Form "XYZ" Länge: 3 Zeichen
Werte: \[0 .. 9,1/2,1/4,-\]
Anwender gibt Wert über Software ein entsprechend, andere Formatierung
Form "WXYZ" Länge: 4 Zeichen Werte: \[0 .. 9,1/2,1/4,-\] Anwender gibt Wert über Software ein entsprechend, andere Formatierung
3.6 Dosierungseinheit Freitext Länge: 0 – 7Zeichen Anwender gibt Wert über Software ein absolut identisch mit Ausdruck
3.7 Hinweise Freitext Länge: 0 - 35 Zeichen Anwender gibt Wert über Software ein, wird ggf. durch die Software unterstützt absolut identisch mit Ausdruck
3.8 Behandlungsgrund Freitext Länge: 0 – 25 Zeichen Anwender gibt Wert über Software ein, wird ggf. durch die Software unterstützt absolut identisch mit Ausdruck
4.1 Zwischenüberschrift mit Kennung "\#" + Freitext Länge: 0 – 31 Zeichen Entweder Anhang B oder vom Anwender oder der Software vorgegeben. identisch, "\#" ist die Kennung, dass es sich um eine Zwischen-überschrift handelt
\#xyz Länge: 4 Zeichen Werte: xyz sind Ziffern nur aus dem Codebereich 41z zulässig. Anlage 2 Text-Code-Tabelle aus Anlage 2
4.2 Überschrift X Länge: 1 Zeichen Wert: "¦" Durch den Anwender gesetzt, Anlage 2 Entsprechend
4.3 Sonstige Hinweise Freitext Länge: 0 – 200 Zeichen Anwender gibt Wert über Software ein absolut identisch mit Ausdruck
5.1 Versionsnummer der Spezifikation (X)XY Länge: 2 – 3 Ziffern ist in der Software hinterlegt Entsprechend,andere Formatierung
5.2 Datum der Version Wird nicht im Barcode genutzt.
5.3 Länderkennzeichen XY Länge: 2 Zeichen Wert: "DE" wird von der Software Automatisch gesetzt, Anlage 1 und 2 absolut identisch mit Ausdruck
5.4 Herstellerangabe Nicht im Barcode enthalten; obliegt dem Hersteller, wie dieses Feld zu füllen ist. Ohne Entsprechung, kein Transfer im 2DBarcode notwendig
5.5 Freifeld ohne Entsprechung

Felder aus dem AKdÄ-Medikationsplan (2.0)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
  • 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: 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

Referenzen

http://www.akdae.de/AMTS/Massnahmen/docs/Medikationsplan.pdf