gms | German Medical Science

GMS Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS)

ISSN 1860-9171

Zur Interoperabilität des bundeseinheitlichen Medikationsplanes – vom „Ultrakurzformat“ zu HL7-Standards

Investigating interoperability of the German Federal Medication Plan – from “Ultrakurzformat” to HL7 standards

Fallbericht

Suche in Medline nach

  • Clemens Hoffmann - Kompetenzzentrum Digitale Dienstleistungssysteme am Institut für Angewandte Informatik (InfAI), Leipzig, Deutschland
  • corresponding author Kyrill Meyer - Kompetenzzentrum Digitale Dienstleistungssysteme am Institut für Angewandte Informatik (InfAI), Leipzig, Deutschland
  • Romy Elze - Betriebliche Informationssysteme an der Universität Leipzig, Leipzig, Deutschland

GMS Med Inform Biom Epidemiol 2017;13(2):Doc08

doi: 10.3205/mibe000175, urn:nbn:de:0183-mibe0001751

Veröffentlicht: 21. Dezember 2017

© 2017 Hoffmann et al.
Dieser Artikel ist ein Open-Access-Artikel und steht unter den Lizenzbedingungen der Creative Commons Attribution 4.0 License (Namensnennung). Lizenz-Angaben siehe http://creativecommons.org/licenses/by/4.0/.


Zusammenfassung

Nach dem deutschen E-Health-Gesetz wird ab 01.04.2017 der bundeseinheitliche Medikationsplan (BMP) allen Patienten, die mindestens drei verordnete Medikamente gleichzeitig einnehmen, in gedruckter Form ausgehändigt. Der im Medikationsplan enthaltene Datamatrix-Code erfasst dabei die Medikationsinformationen im XML-basierten Ultrakurzformat und soll eine standardkonforme, elektronische Übermittlung der Daten ebenfalls ermöglichen. Erstellt wird der BMP vom Hausarzt, der diesen neben Fachärzten, Kliniken und Apothekern aktualisiert. Neben dem BMP existieren aber auch weiterhin eine Reihe von anderen Dokumenten mit Medikationsinformationen (z.B. Entlassungsdokumentationen), die ebenfalls in den digitalen Datenaustausch integriert werden müssen. Der Artikel beschreibt vor dem Hintergrund der praktischen Anwendung des BMP den langen Weg von der Theorie in die Praxis und beleuchtet, welche organisatorischen und technischen Barrieren für einen elektronischen Datenaustausch überwunden werden müssen. Neben der Prozessbetrachtung wird eine technische Infrastruktur vorgestellt und es wird auf Herausforderungen im Umgang mit dem Ultrakurzformat eingegangen.

Schlüsselwörter: BMP, Medikationsplan, E-Health-Gesetz, FHIR, UKF, HL7, Standardisierung

Abstract

According to the German E-Health-Law it will be mandatory to hand out a national medication plan (BMP) in printed form to all patients that have a prescription of three or more drugs to take at the same time starting 1st April, 2017. Part of this printout is a datamatrix code that encodes all medication information using the XML-based UKF (German: Ultrakurzformat) in order to include a means for a standardized electronic transfer of the data. Generated by the general practitioner, the medication plan also needs to be updated through medical specialists, clinical doctors or pharmacists. This paper documents, based on usage scenarios for the BMP, the long way from theory to practical use and points to organizational and technical hurdles that need to be overcome as part of the digitalization. Along with the implications for the process dimension, a technical infrastructure is introduced and different challenges in working with the UKF are identified and discussed

Keywords: BMP, drug plan, medication plan, e-health, FHIR, UKF, HL7, Standardization


1 Einleitung

Die digitale Umsetzung des Medikationsplanes [1], als Bestandteil des am 01.01.2016 in Kraft getretenen „Gesetz für sichere digitale Kommunikation und Anwendungen im Gesundheitswesen“ [2] – kurz als E-Health-Gesetz bezeichnet – ist eine gemeinsame Errungenschaft der Kassenärztlichen Bundesvereinigung (KBV), dem Deutschen Apothekerverband (DAV) und der Bundesärztekammer (BÄK) in enger Abstimmung mit dem Bundesverband Gesundheits-IT e.V. (bvitg), dem Bundesverband Deutscher Apotheken-Softwarehäuser e.V. (ADAS) und HL7 Deutschland e.V. Damit soll die elektronische Übertragung von Datenerfassungs- und Kommunikationsprozessen sowie die Digitalisierung und Vernetzung der Akteure im Gesundheitswesen gefördert werden [3], [4].

Das übergeordnete Ziel des Medikationsplanes kann in der Unterstützung der digitalen Informationskontinuität innerhalb des Versorgungsprozesses gesehen werden [5], welche in der Konsequenz zu einer Erhöhung der Arzneimitteltherapiesicherheit (AMTS) beiträgt [6]. AMTS kann dabei definiert werden als „die Gesamtheit der Maßnahmen zur Gewährleistung eines optimalen Medikationsprozesses mit dem Ziel, Medikationsfehler und damit vermeidbare Risiken für den Patienten bei der Arzneimitteltherapie zu verringern“ [6]. Als konkreten ersten Schritt haben Patienten in der ambulanten Versorgung seit dem 1. Oktober 2016 Anspruch auf die Aushändigung eines Medikationsplanes, wenn sie mindestens drei verordnete, systemisch wirkende Medikamente gleichzeitig verordnet bekommen und diese Anwendung über einen Zeitraum von mindestens 28 Tagen vorgesehen ist.

Zunächst im Wesentlichen als Offline-Dokument konzipiert, besteht doch der Anspruch der digitalen Interoperabilität und späteren Übertragung auf die Telematikinfrastruktur der elektronischen Gesundheitskarte (eGK). Die intersektorale Zusammenarbeit auf technischer Ebene soll bereits beim BMP durch den Einsatz des Ultrakurzformates (UKF), welches auf dem Fast Healthcare Interoperability (FHIR) Standard basiert, etabliert werden. Bei der technischen Umsetzung und insbesondere bei der bidirektionalen Transformation der Formate treten jedoch Einstiegsbarrieren auf [7]. So sind einerseits Schnittstellen zu den existierenden Informationssystemen zu schaffen, die den Einstieg in das digitale Medikationsmanagement initial ermöglichen. Des Weiteren darf nicht unberücksichtigt bleiben, dass bisher Medikationsinformationen in unterschiedlicher Form weitergegeben werden (z.B. über Rezepte, Entlassungsberichte, Arztbriefe etc.). Es gilt demgemäß die Medikationsinformationen für den intersektoralen Austausch nutzbar zu machen, damit der gesetzlich vorgeschriebene Medikationsplan dem Patienten ausgehändigt und zwischen den heterogenen Softwaresystemen der beteiligten Akteure sicher und verlustfrei ausgetauscht werden kann [8].

Der vorliegende Beitrag untersucht vor diesem Hintergrund eine praktische Umsetzungsstrategie zur Arbeit mit Medikationsplänen. Es wird eine Service-Architektur vorgestellt, welche an der Schnittstelle zwischen Kliniken, Apotheken und ambulanter ärztlicher Versorgung die existierenden Realisierungs- und Umsetzungsmöglichkeiten beleuchtet und real existierende Defizite und Bedarfe aufzeigt. Dies alles wird vor dem Hintergrund der gewünschten und tatsächlich bereits realisierten Interoperabilität der Daten betrachtet.


2 Projektbeschreibung und -ergebnisse

2.1 Der bundeseinheitliche Medikationsplan (BMP)

Durch die Koordinierungsgruppe AMTS wurde für Deutschland ein Standardformat erarbeitet (siehe Abbildung 1 [Abb. 1]) und eine technische Spezifikation erstellt [1], [9]. Die Vorgaben zu Inhalt und Struktur des bundeseinheitlichen Medikationsplans gemäß § 31a SGB V [10] wurden am 30. April 2016 [1] veröffentlicht. Dieser bundeseinheitliche Medikationsplan enthält als Ausdruck für alle Arzneimittel Angaben zu Wirkstoff, Handelsname, Stärke, Form, Dosierungsschema, Einheit, Hinweise sowie Grund der Einnahme. Zusätzlich sind im Dokumentenkopf der Name und das Geburtsdatum sowie weitere wichtige patientenbezogene Daten erfasst. Ebenso ist der Ersteller des Medikationsplanes ersichtlich. Die Erstellung des Medikationsplanes übernimmt in der Regel der Hausarzt mit Hilfe seines Praxisverwaltungssystems (PVS).

Neben der Praktikabilität des BMP für den Patienten soll die Aktualisierung durch die am Medikationsprozess beteiligten Akteure ermöglicht werden. Für den digitalen Austausch sieht der bundeseinheitliche Medikationsplan einen maschinenlesbaren 2D-Barcode vor, der den Inhalt der jeweiligen Seite des Medikationsplans als Datamatrix Barcode [11] speichert. Der Barcode erfasst die im Medikationsplan enthalten Informationen als XML-basiertes Ultrakurzformat (UKF). Für das Ultrakurzformat wird angegeben, dass es auf dem internationalen Standard Fast Healthcare Interoperability Resources (FHIR) [12] basiert [13] und damit bereits auf Interoperabilität ausgelegt ist.

2.1.1 Theorie versus Praxis

Auf dem Weg von der Theorie zur Praxis sind sowohl organisatorische als auch technische Fragen zu klären. Aufgrund der gesetzlichen Vorgaben sind die Hersteller von Praxisverwaltungssystemen gezwungen, entsprechende Erweiterungen zur Erstellung des BMP in ihre Softwarelösungen zu integrieren. Da auch bisher die meisten Systeme in der Lage sind, (unstandardisierte) Medikationspläne zu erstellen, realisieren bisher viele Hersteller zusätzliche Module und verlangen von den Nutzern eine Vergütung für deren Bereitstellung bzw. Nutzung. Entsprechend entstehen neben zusätzlichen Kosten auch Probleme aus der Übernahme bestehender Medikationsinformationen bzw. Medikationspläne und deren Integration in den Aktualisierungsprozess. Dies betrifft neben bestehenden Medikationsplänen in den verschiedenen PVS vor allem auch weitere Medikationsinformationen aus Befundberichten, Entlassungs- oder Überleitungsdokumentationen. Aus Sicht der Ärzte, die hierfür neben den Softwarekosten geeignete Arbeitsprozesse in ihren Arztpraxen etablieren müssen, ist nicht zuletzt aus diesem Grund die Höhe der vorgesehenen Vergütung für die Erstellung von BMP als nicht ausreichend umstritten [14]. Eine Aktualisierung des BMP in einer solchen Konstellation setzt voraus, dass Schnittstellen und Austauschformate zur verlustfreien Übertragung für die unterschiedlichen Quellen zur Verfügung stehen, was bisher als nicht realisiert angesehen werden muss. Entsprechend hoch sind die manuellen Prozessschritte in vielen Fällen: Um eine Therapieempfehlung eines Befundberichtes in den Medikationsplan zu integrieren, muss diese häufig erst manuell erfasst werden. Dies erfordert einerseits zeitliche Ressourcen und stellt andererseits eine Unsicherheit bei der Arzneimitteltherapie dar, da Übertragungsfehler eintreten können.

2.1.2 Übermittlung des BMP mittels 2D-Barcode

Da die Spezifikation des bundeseinheitlichen Medikationsplanes zur Art und Vorhaltung der Medikationspläne in den jeweiligen Systemen/PVS keine Vorgaben macht, ist an der Schnittstelle zwischen analogem Papierdokument und digitaler Repräsentation des Planes zunächst die im 2D-Barcode enthalte Information interessant.

Der 2D-Barcode erfasst in seinem Carriersegement die im Medikationsplan enthaltenen Informationen in Form einer XML-Datei im Ultrakurzformat (UKF). UKF wurde als Speicherformat für kapazitätslimitierte Datenträger entwickelt und soll sowohl für den Barcode als auch für die eGK genutzt werden. Nach dem Prinzip der Datensparsamkeit wird der Medikationsplan durch möglichst wenig Zeichen kodiert. Im Ultrakurzformat werden im Handel befindliche Medikamente beispielsweise nicht mit ihrem Namen, sondern über ihre Pharmazentralnummer (PZN) erfasst. Ein Medikationsplan findet so eine digitale Entsprechung wie in Abbildung 2 [Abb. 2], stellt aber aufgrund der Codierung keine 1:1-Abbildung dar. Im Ergebnis bedeutet dies, dass eine Weiterverarbeitung der Daten nur mittels Dekodierungsmechanismen erfolgen kann, d.h. aus einer PZN muss maschinell auf Wirkstoff bzw. Präparat geschlossen werden. Die dekodierte Information muss wiederum in einem interoperablen Austauschformat gespeichert werden. Aus dieser Vorgehensweise resultiert gleichzeitig eine zusätzliche Schwierigkeit: Wird nur ein Wirkstoff verordnet, kann dieser nicht datensparsam im UKF kodiert werden und muss als Wirkstoff im Klartext gespeichert werden.

2.2 Lösungsansatz: BMP „get started“

Die Überführung von Medikationsinformationen und -verschreibungen aus Quelldaten beliebiger Struktur in den bundeseinheitlichen Medikationsplan ist erklärtes Forschungsziel des Projektes AMME (gefördert vom BMWI, siehe https://www.medikationsplan-services.de/). Die Transformation von papierbasierten und anderen proprietären Formaten wie z.B. Arztbriefen, Rezepten, Medikationsplänen einerseits und die Überführung der Informationen in ein standardkonformes Format andererseits soll die Bearbeitungsprozesse für die Erstellung und Bearbeitung des BMP vereinfachen.

Für die Transformation von Papierformaten in das Format des bundeseinheitlichen Medikationsplanes wurde im Rahmen des Vorhabens AMME eine Micro-Service-Architektur entwickelt (siehe Abbildung 3 [Abb. 3]), welche FHIR [12] als Austauschformat verwendet. FHIR ist als Standard für den Datenaustausch zwischen Softwaresystemen im Gesundheitswesen konzipiert und wurde vor dem Hintergrund gewählt, dass UKF von FHIR abgeleitet ist und somit eine Einbindung des BMP in die Lösungsarchitektur leichter ermöglicht werden kann. Durch definierte Ressourcen/Profile wie zum Beispiel Patient, AllergyIntolerance und MedicationStatement [15] lassen sich Instanzen des einen Formats in das andere (im Sinne einer Bijektivität) überführen. Damit ist die Funktionsfähigkeit gebunden an die Umwandlung von UKF in das FHIR-Format, welche als Teil der Micro-Service-Architektur zu entwickeln war.

2.2.1 Dekodieren eines 2D-Barcodes des BMPs und Überführung nach FHIR DSTU2

Die Abbildung 4 [Abb. 4] visualisiert einen typischen Anwendungsfall im AMME-Projekt. Im Schritt 1 wird über den AMME-Datamatrix-Service das Ultrakurzformat (UKF) aus einem Datamatrix-Barcode des bundeseinheitlichen Medikationsplans dekodiert. Anschließend erfolgt die Umwandlung nach FHIR mit Hilfe des AMME-UKF-FHIR-Konvertierers (Schritt 2). In einem weiteren Schritt 3 erfolgt die Übergabe des erzeugten FHIR-Bundles an den AMME-Print-BMP-Service. Das Ergebnis ist die Generierung eines bundeseinheitlichen Medikationsplans im PDF-Format.

2.2.2 UKF zu FHIR – Architektur und Funktionsweise

Zur Übertragung der Medikations-Information wurde eine UKF zu FHIR-Konvertierer-Schnittstelle entwickelt, welche Teil der AMME-Micro-Service-Architektur (siehe Abbildung 3 [Abb. 3]) ist. Der UKF zu FHIR Umwandlungsservice setzt auf die Node.js-Plattform unter Verwendung eigener sowie externer Node-Module auf (vgl. Abbildung 5 [Abb. 5]). Node.js ist als Software-Entwicklungsplattform besonders für den Betrieb von Netzwerkanwendungen geeignet, um eine große Anzahl gleichzeitig bestehender Netzwerkverbindungen zu ermöglichen.

Für die Bereitstellung einer Restful-WebAPI wurde das ExpressJS-Framework eingesetzt (Express.js ist ein serverseitiges Web Application Framework für die Entwicklung moderner Webanwendungen mit Node.js, weitere Informationen unter [16]). Für das Einlesen von UKF und dessen Validierung gegen die bereitgestellte XSD-Datei vom FTP-Server der Kassenärztlichen Bundesvereinigung (KBV) [17], dient das Node-Module xmljs. Die Konvertierung von UKF-Elementen zu FHIR-Ressourcen übernimmt eine im AMME-Projekt entwickelte AMME-FHIR-Bibliothek. Mithilfe dieser Bibliothek ist es möglich, benötigte FHIR-Ressourcen in prototypischen JavaScript-Klassen zu instanziieren, ähnlich dem objektorientiertem Programmierparadigma. Momentan unterstützt die AMME-FHIR-Bibliothek alle notwendigen FHIR-Ressourcen und -Datentypen, welche für die Konvertierung von Medikationsplänen im Ultrakurzformat (Version 2.3) zu FHIR DSTU2 (Version 1.0.2-7202) benötigt werden. Einzelne UKF-Elemente, wie zum Beispiel das A-Element (Author) oder O-Element (Observation), werden im Datenformat FHIR mittels Universally Unique Identifier (UUID) innerhalb eines FHIR-Bundle referenziert. Eine UUID ist ein Standard für Identifikatoren. Das FHIR-Bundle fasst alle FHIR-Ressourcen eines Medikationsplans zu einem Dokument zusammen. Für die Generierung der UUIDs setzt der AMME-UKF-FHIR-Konvertierer auf das Node-Module node-uuid. Jede instanziierte prototypische JavaScript-Klasse der AMME-FHIR-Bibliothek verfügt über die Funktion .toFHIR(). Der Aufruf dieser Funktion bewirkt die Ausgabe der gesetzten Informationen aus den einzelnen UKF-Elementen nach FHIR in der Repräsentation JSON (JavaScript Object Notation) (application/json+fhir). Bevor das erzeugte FHIR-Bundle dem Client zurückgeliefert wird, erfolgt eine Validierung durch das Node-Module fhir-validator.

Das UML-Aktivitätsdiagramm in Abbildung 6 [Abb. 6] verdeutlicht die internen Verarbeitungsschritte bei einem API-Aufruf.

2.2.3 REST-Endpunkte des Service

Tabelle 1 [Tab. 1] beschreibt die sieben bereitgestellten Schnittstellen des AMME-UKF-FHIR-Konvertierers. Es besteht nicht nur die Möglichkeit, einen kompletten Medikationsplan im UKF-Format (Schnittstelle #6), sondern auch einzelne UKF-Elemente wie Patient (P), Author (A), Custodian (C), Observation (O) oder MedicationStatement (MS) separat in die entsprechende FHIR-Ressource zu überführen.

2.2.4 Anwendung einer Konvertierung von UKF nach FHIR

Das folgende Beispiel beschreibt die Konvertierung von einem P-Element im Ultrakurzformat in das standardisierte HL7 FHIR in der Serialisierung JSON unter Verwendung des AMME-UKF-FHIR-Konvertierers.

Im Beispiel aus Abbildung 7 [Abb. 7] wird das P-Element des Ultrakurzformats mit den folgenden Attributen

  • g (Vorname),
  • f (Nachname),
  • b (Geburtsdatum)

bzw. ergänzend sofern vorhanden

  • s (Geschlecht) und
  • egk (Nummer der elektronischen Gesundheitskarte)

in FHIR konvertiert werden. Im Beispiel aus Abbildung 2 [Abb. 2] fehlt die Information zu Geschlecht und eGK, könnte daher nicht konvertiert werden und würde entfallen. Wenngleich die Spezifikation dies zulässt, bedeutet dies im entsprechenden Fall, dass eine Zuordnung im Praxisverwaltungsprogramm schwerer fallen könnte. Für die Vollständigkeit der Darstellung wird in der weiteren Darstellung die Existenz der Informationen wie in Abbildung 6 [Abb. 6] dargestellt angenommen.

Micro-Services wurden im AMME-Projekt überwiegend mit Node.js umgesetzt. Das folgende Code-Beispiel aus Abbildung 8 [Abb. 8] liegt daher in JavaScript vor. Für die Konvertierung von UKF zu FHIR wurde sich an der Wiki-Dokumentation [9] des Ultrakurzformats orientiert. Zu Beginn werden die benötigten FHIR-Ressourcen sowie -Datentypen für eine notwendige Konvertierung eines P-Elements nach FHIR aus der AMME-FHIR-Bibliothek importiert – im konkreten Fallbeispiel Patient, Identifier und HumanName. Wie die FHIR-Ressource vom Typ „Patient“ vollständig beschrieben wird, kann der FHIR-Spezifikation [18] entnommen werden.

Abbildung 9 [Abb. 9] zeigt das Ergebnis des obigen Fallbeispiels einer Umwandlung von UKF nach FHIR. Diese Vorgehensweise wurde analog für alle anderen UKF-Elemente vollzogen, um den kompletten bundeseinheitlichen Medikationsplan (BMP) abzubilden. Die gewählte JSON-Serialisierung erlaubt als ein kompaktes Datenformat eine einfache anwendungsunabhängige Datenübergabe der strukturierten Daten.

2.2.5 Anbindung der AMME-Software an das Praxisverwaltungssystem

Mit dem Vorhaben AMME soll unter anderem dem Personal in Arztpraxen das Digitalisieren von Medikationsplänen (z.B. Arztbriefen) erleichtert werden. Nach Analyse der Geschäftsprozesse von Arztpraxen entwickelte sich der in Abbildung 10 [Abb. 10] abgebildete Use-Case unter Nutzung der AMME-Micro-Service-Architektur inklusive AMME-Benutzeroberflächen (Webanwendung und App). In der Nutzung scannt das medizinische Personal einer Arztpraxis den (meist) unstrukturierten Medikationsplan ein und legt diesen in der elektronischen Patientenakte des Patienten ab. Die Informationen zur Medikation müssen in einem weiteren Schritt manuell in der vom Praxisverwaltungssystem für die Medikation bereitgestellten Eingabemaske eingetragen, ergänzt oder geändert werden. Die AMME-Benutzeroberfläche wird über die standardisierte GDT-Schnittstelle für den Gerätedatentransfer [19] aus der Praxisverwaltungssoftware heraus gestartet. Diese standardisierte Schnittstelle, die dem systemunabhängigen Austausch von Daten zwischen Medizingeräten dienen soll, unterstützen alle wesentlichen Praxisverwaltungslösungen. Die AMME-Anwendung nutzt diese Schnittstelle für den Austausch von Informationen mit dem System des Arztes und ist selbst als Webanwendung realisiert, um Interoperabilität zu gewährleisten. Das medizinische Personal besitzt die Möglichkeit, den Medikationsplan direkt über den Scanner oder einen bereits vorhandenen Medikationsplan (z.B. via E-Mail erhalten) einzulesen.

Die Art des Medikationsplans entscheidet nun über das weitere Vorgehen. Liegt ein bundeseinheitlicher Medikationsplan vor, wird der 2D-Barcode (Datamatrix) über einen AMME-Barcode-Service dekodiert. Bedingt durch die fehlenden Metainformationen über Medikamente im Ultrakurzformat werden über den AMME-IFA-Service die Informationen abgerufen, welche sich zusätzlich auf dem papierbasierten Druck des Plans befinden. Dazu gehört beispielsweise der Wirkstoff oder der Handelsname des Präparats bei einem Medikament, welches eine PZN besitzt und deshalb nur über selbige kodiert wird Soll ein unstrukturierter (z.B. Arztbrief) oder semi-strukturierter (z.B. Tabelle) Medikationsplan als Plan eingelesen werden, muss das medizinische Personal in der Webanwendung einen Rahmen um die relevanten Medikationsinformationen ziehen. Anschließend versuchen verschiedene Algorithmen, die Medikation zu extrahieren. Das Ergebnis der Erkennung – gleichwohl über 2D-Barcode eingelesene, semi-strukturierter oder unstrukturierter Medikationspläne – wird in der Webanwendung in einer Tabelle mit der Struktur des bundeseinheitlichen Medikationsplans ausgegeben. Mit Klick in die jeweilige Tabellen-Zelle lassen sich Änderungen am Medikationsplan tätigen. Nach Abschluss des Einlesens und etwaigen Editiervorgängen kann das Ergebnis gespeichert werden. Bei diesem Vorgang wird der Medikationsplan in einen bundeseinheitlichen Medikationsplan (PDF-Datei) überführt und zusammen mit einem möglichen Scan (Bild-Datei) in der elektronischen Patientenakte des Praxisverwaltungssystems verlinkt. Der Ausdruck der PDF-Datei des aktualisierten BMPs kann dem Patienten übergeben werden.


3 Diskussion

Mit dem bundeseinheitlichen Medikationsplan wird vor dem Hintergrund des aktuellen Stands der Digitalisierung im Gesundheitswesen in Deutschland ein Weg eingeschlagen, der eine Brücke schlägt zwischen einer gezielten Verbesserung und Steuerung der Arzneimitteltherapiesicherheit und dem dafür notwendigen Informationsaustausch. Als überwiegend analoges Mittel der Kommunikation ist es dabei zunächst ein Kompromiss. Während es der fehlenden Infrastruktur und den ursprünglichen Anforderungen an den BMP geschuldet ist, dass die Datenhoheit in die Hände des betroffenen Patienten gelegt wird und der Datenaustausch über unterschiedlichste Systeme überhaupt ermöglicht wird, kann andererseits die Schnittstelleproblematik analog/digital langfristig nur eine Übergangslösung darstellen und betrachtet nur einen kleinen Teil des notwendigen Informationsaustausches. So wird mit dem über den Datamatrix-Code auf den BMP gebrachten Medikationsplaninformationen im UKF bewusst eine Datenkomprimierung und -reduktion aufgrund der begrenzenden Speicherkapazität der 2D-Data Matrix vorgenommen. Es entsteht der Nachteil, dass die gedruckten Informationen in UKF-kodierter Form nicht vollständig abgelegt sind und für eine Auflösung zusätzliche Datenquellen vorgehalten werden müssen. Es sei an dieser Stelle explizit erwähnt, dass damit eine bijektive Abbildung (d.h. umkehrbar eindeutige) von UKF in FHIR nur dann gegeben sein kann, wenn ein Zugriff auf Arzneimitteldatenbanken möglich ist, der eine Auflösung (insbesondere der PZN) ermöglicht.

Als Vorteil des verwendeten UKF ist festzuhalten, dass durch die Nutzung die Möglichkeit gegeben ist, eine geringe Menge an Daten (im Beispiel 360 Zeichen ohne Leerzeichen) zu nutzen und diese im verwendeten Data-Matrix-Code abzulegen. Der entsprechende vollständige Datensatz des Beispiels in FHIR umfasst 5813 Zeichen und beträgt damit etwa das 16-fache, beinhaltet aber neben dem Codesystem auch die Aufschlüsselung der ansonsten nur über die PZN kodierten Informationen zu den Wirkstoffen. Es bleibt an dieser Stelle festzuhalten, dass es zwar grundsätzlich günstiger wäre, direkt mit einem internationalen Standard wie FHIR zu arbeiten, dies aber in Abwägung zur eingeschränkten Speicherkapazität des im BMP verwendeten Data Matrix Codes steht. Die aktuelle Realisierung und angedachte Nutzung des BMP ist insofern als ein Zwischenschritt anzusehen, der durch die Möglichkeiten aufgrund einer angedachten durchgängigen Telematik-Infrastruktur im Gesundheitswesen abgelöst werden sollte.

Weiterhin ist die Einbindung des BMP in die bestehenden Prozesse, insbesondere an der Schnittstelle zwischen klinischer und ambulanter Versorgung, bisher nur unzureichend betrachtet worden. Es zeigt sich, dass neben dem BMP auch weiterhin verschiedene andere analoge und digitale Dokumentationen von Medikationsinformationen existieren und so nicht zuletzt durch den BMP ein zusätzlicher Aufwand der Integration und Datenpflege zwischen den verschiedenen Formaten entsteht. Der in diesem Beitrag vorgestellte Ansatz des Vorhabens AMME schlägt vor diesem Hintergrund eine Micro-Service-Architektur vor, die es ermöglicht Medikationsinformation in strukturierter und unstrukturierter Form gleichermaßen zu integrieren. Anders als bei den Spezifikationen für den BMP wird dabei bewusst auf die Nutzung von internationalen Standards gesetzt, um eine Interoperabilität im Gesundheitswesen langfristig und durchgehend zu gewährleisten. Durch die Nutzung von FHIR DSTU als internes Datenformat des vorgestellten Frameworks werden folgende Vorteile realisiert:

  • moderner internationaler HL7-Standard verwendet
  • mehrere moderne Serialisierungen (JSON, RDF, XML) bereits verfügbar
  • Restful FHIR-Server (Speicherung und Abfrage von FHIR-Ressourcen) realisiert
  • die eigene Implementierung wird durch Vorhandene Softwarelösungen für FHIR ergänzt
  • überführbar nach CDA als weiterer internationaler Standard (im Bereich Klinik)
  • Abbildung eines kompletten Medikationsplans und weitere Anwendungsfälle im Vorhaben demonstriert
  • die Lösung ist von proprietären Softwarelösungen unabhängig

4 Zusammenfassung und Ausblick

Der Mehrwert des Beitrages ist die Entwicklung und Darstellung von Services zur Herstellung der Funktionsfähigkeit einer Micro-Service-Architektur zum Umgang mit Medikationsplänen. Auf der Anwenderseite kann diese Architektur über Schnittstellen in die existierenden Softwarelösungen (z.B. Praxisverwaltungssoftware) eingebunden werden. Gleichzeitig besteht eine hohe Flexibilität für weitere Prozess- und Geschäftsmodelle (z.B. über WebApplikationen oder mobile Apps) aufgrund des webbasierten Ansatzes der Lösung und des Micro-Service-Paradigmas. Für die Umwandlung von Medikationsinformationen von papierbasierten Formaten existiert eine Scannerschnittstelle mit Texterkennung und ein Import-Service. Für eine Nutzung eines 2D-Barcode (Datamatrix) des BMP wurde ein Webservice zur Umwandlung von Ultrakurzformat (UKF) nach HL7 FHIR DSTU2 vorgestellt. Mit der Umwandlung des UKFs in den internationalen Standard wird eine Möglichkeit geschaffen, alle Informationen des papierbasierten Drucks abzubilden und für die unterschiedlichsten Anwendungsszenarien zur Verfügung zu stellen. Erst mit der Existenz einer solcher Architektur kann aus Sicht der Autoren ein Beitrag für die Arzneimittelsicherheit geleistet werden, der über eine Dokumentation der Medikation (wie es über den BMP erfolgt) hinausgeht: So sind z.B. AMTS-Prüfungen hinsichtlich Neben- und Wechselwirkungen in der gegebenen Architektur technisch gesehen leicht möglich. Als Erweiterung der bisherigen Lösung sind folgende Ansätze denkbar:

  • Anbindung von weiteren Services mit Mehrwert (z.B. AMTS relevante Prüfungen) und Etablierung entsprechender Prüfprozesse.
  • Speicherung des erzeugten FHIR-Bundles in einem Restful FHIR-Server: Ein umgewandelter bundeseinheitlicher Medikationsplan nach FHIR kann in einem Restful FHIR-Server abgelegt werden. So besteht die Möglichkeit, den Medikationsplan eines Patienten jederzeit wieder in die Webanwendung zu importieren. Ebenso lassen sich gezielt relevante Informationen abrufen. Über die Historie einer Ressource lassen sich Änderungen an der Medikation nachvollziehen. Dies kann systemübergreifend erfolgen und ist in eine entsprechende Gesundheitstelematikinfrastruktur integrierbar.
  • Nutzung des AMME-FHIR-UKF-Konvertierers als Brücke zur Umwandlung nach CDA: Über bereits existierende Konvertierer ließe sich das generierte FHIR-Bundle aus dem Ultrakurzformat des bundeseinheitlichen Medikationsplans in die Clinical Document Architecture (CDA) überführen. CDA wird hauptsächlich im klinischen Umfeld für den Austausch und Speicherung verwendet. Entsprechend kann an dieser Stelle ein zusätzlicher Mehrwert generiert werden.

Anmerkung

Interessenkonflikte

Die Autoren erklären, dass sie keine Interessenkonflikte in Zusammenhang mit diesem Artikel haben.

Danksagung

Der Lösungsansatz ist innerhalb des Projektes „Semantische Integration von Medikationsplänen unterschiedlicher Struktur“ (AMME) entwickelt worden. Dieses Projekt wird als ZIM-Netzwerkvorhaben (FKZ) für den Zeitraum 01.07.2015 bis 30.11.2017 vom Bundesministerium für Wirtschaft und Energie (BMWi) gefördert (Förderkennzeichen 16KN039934).


Literatur

1.
Bundesärtzekammer. Spezifikation für einen bundeseinheitlichen Medikationsplan (BMP) gemäß § 31a SGB V. Anlage 3 – Spezifikation BMP Version 2.2 vom 31.05.2016 [Internet]. [zitiert 3. Februar 2017]. Verfügbar unter: http://www.bundesaerztekammer.de/fileadmin/user_upload/downloads/pdf-Ordner/Telematik/BMP_Anlage3.pdf Externer Link
2.
Gesetz für sichere digitale Kommunikation und Anwendungen im Gesundheitswesen sowie zur Änderung weiterer Gesetze [Internet]. Bundesgesetzblatt. 2015 Dez 21;Abschn. 1:2408. Verfügbar unter: http://www.bgbl.de/xaver/bgbl/start.xav?startbk=Bundesanzeiger_BGBl&jumpTo=bgbl115s2408.pdf Externer Link
3.
Dietzel GTW. E-Health und Gesundheitstelematik. In: Kreyher VJ, Herausgeber. Handbuch Gesundheits- und Medizinmarketing: Chancen, Strategien und Erfolgsfaktoren. Heidelberg: Hüthig Jehle Rehm; 2001. S. 237-52.
4.
Müller-Mielitz S, Lux T. E-Health-Gesetz. In: Müller-Mielitz S, Lux T, Herausgeber. E-Health-Ökonomie [Internet]. Wiesbaden: Springer Fachmedien; 2017 [zitiert 3. Februar 2017]. S. 125-36. DOI: 10.1007/978-3-658-10788-8_8 Externer Link
5.
Dormann H, Bangemann M, Prokosch H-U, Zerth J. Digitalisierte Arzneimittelversorgung am Beispiel des bundeseinheitlichen patientenbezogenen Medikationsplans – eine Frage der Stakeholderakzeptanz. In: Pfannstiel MA, Da-Cruz P, Mehlich H, Herausgeber. Digitale Transformation von Dienstleistungen im Gesundheitswesen I [Internet]. Wiesbaden: Springer Fachmedien; 2017 [zitiert 3. Februar 2017]. S. 149-64. DOI: 10.1007/978-3-658-12258-4_10 Externer Link
6.
Kuske S, Lessing C, Lux R, Schmitz A, Schrappe M. Patientensicherheitsindikatoren zur Arzneimitteltherapiesicherheit (AMTS-PSI): Internationaler Status, Übertragbarkeit und Validierung. Gesundheitswesen. 2012;74(02):79-86.
7.
Medikationsplan: bvitg weist Vorwürfe der KBV zurück [Internet]. Krankenhaus-IT online Journal. 2017 Jan 21 [zitiert 3. Februar 2017]. Verfügbar unter: http://www.medizin-edv.de/modules/AMS/article.php?storyid=4154 Externer Link
8.
Thun S, van de Sand L. eMedikation in Deutschland vor dem Hintergrund ausländischer Erfahrungen. GG Wiss. 2016;16(3):14-22.
9.
HL7 Deutschland e.V. IG: Ultrakurzformat Patientenbezogener Medikationsplan – Hl7wiki [Internet]. 2016. Verfügbar unter: http://wiki.hl7.de/index.php?title=IG:Ultrakurzformat_Patientenbezogener_Medikationsplan Externer Link
10.
Bundesministerium der Justiz und Verbraucherschutz. Sozialgesetzbuch (SGB) Fünftes Buch (V) – Gesetzliche Krankenversicherung – (Artikel 1 des Gesetzes v. 20. Dezember 1988, BGBl. I S. 2477) § 31a Medikationsplan [Internet]. [zitiert 3. Februar 2017]. Verfügbar unter: https://www.gesetze-im-internet.de/sgb_5/__31a.html Externer Link
11.
Lenk B. Data Matrix ECC 200: Der 2D-Code für die Optische Identifikation. 1. Aufl. Kirchheim unter Teck: Monika Lenk Fachbuchverlag; 2007.
12.
Documentation – FHIR v1.0.2 [Internet]. [zitiert 3. Februar 2017]. Verfügbar unter: http://www.hl7.org/fhir/documentation.html Externer Link
13.
Ultrakurzformat. In: Wikipedia [Internet]. [zitiert 1. März 2017]. Verfügbar unter: https://de.wikipedia.org/wiki/Ultrakurzformat Externer Link
14.
Gerlof H. Medikationsplan: Honorar wird auch ohne Leistung gezahlt. Ärzte Zeitung. 2016 Sep 23 [zitiert 6. März 2017]. Verfügbar unter: http://www.aerztezeitung.de/praxis_wirtschaft/rezepte/article/919866/medikationsplan-honorar-leistung-gezahlt.html Externer Link
15.
Heitmann KU. Medikationsplan – E-Health Gesetz und Ultrakurzformat [Internet]. 2016 Juni 2 [zitiert 3. Februar 2017]. Verfügbar unter: http://wiki.hl7.de/images/Heitmann_medikationsplan-20160602.pdf Externer Link
16.
Node.js Foundation. Express.js [Internet]. [zitiert 1. März 2017]. Verfügbar unter: http://expressjs.com/ Externer Link
17.
KBV. Index von ftp://ftp.kbv.de/ita-update/Verordnungen/Arzneimittel/BMP/ [Internet]. [zitiert 1. März 2017]. Verfügbar unter: ftp://ftp.kbv.de/ita-update/Verordnungen/Arzneimittel/BMP Externer Link
18.
Patient – FHIR v3.0.1 [Internet]. [zitiert 15. Juni 2017]. Verfügbar unter: https://www.hl7.org/fhir/patient.html Externer Link
19.
GDT-Schnittstelle [Internet]. [zitiert 3. März 2017]. Verfügbar unter: http://www.qms-standards.de/standards/gdt-schnittstelle/ Externer Link
20.
KBV. Testfälle_bmp23.pdf [Internet]. 2016 [zitiert 1. März 2017]. Verfügbar unter: ftp://ftp.kbv.de/ita-update/Verordnungen/Arzneimittel/BMP/testpaket.zip Externer Link