AkdÄ-Medikationsplan auf der Basis von CDA R2

AkdÄ-Medikationsplan auf Basis der
HL7 Clinical Document Architecture Release 2
für das deutsche Gesundheitswesen

AkdÄ-Medikationsplan auf der Basis von CDA R2

Implementierungsleitfaden

Initialfassung

Version:	01
Datum:	2013
Status:	Abstimmung
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2013: HL7 Deutschland

Kontributoren
	Agfa HealthCare GmbH	Bonn
	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:

CDA-Layout

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

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.

Referenzen

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