Das Gerät MedDoser ist ein mit einem Touchscreen und weiteren Komponenten versehenes RaspberryPi, das eine Erinnerungsfunktion samt Medikationsdokumentation auf Basis eines eingescannten Medikationsplans ermöglicht und die Medikation eines Patienten visuell darstellt.


Der MedDoser bietet akustische und visuelle Erinnerungsfunktionen und stellt eine Historie zur Verfügung, mit welcher der Verlauf der Medikation tages- und zeitpunktgenau nachvollzogen werden kann.

Die Informationen der jeweiligen Medikamente basieren hierbei auf dem vom Arzt verordneten Medikationsplan auf Papier, dessen Barcode eingescannt werden kann. Die eingelesenen Daten werden in einer Benutzeroberfläche bereitgestellt, die ausschließlich mit dem Finger bedient wird. Der Benutzer hat zudem die Möglichkeit, die Erinnerungszeitpunkte für jede Tageszeit manuell auf seine Bedürfnisse anzupassen.

Motivation und Ziel des Projekts

Der demografische Wandel resultiert in einem wachsenden Anteil alter Menschen in unserer Gesellschaft. Einige von ihnen befinden sich an der Schwelle zur Pflegebedürftigkeit und sind auf eine regelmäßige Medikamenteneinnahme angewiesen. Vor allem jene von ihnen, die an den Volkskrankheiten Demenz und Alzheimer leiden, aber auch Patienten, die aus anderen Gründen Probleme bei Medikamenteneinnahme haben, soll diese Prozedur erleichtert werden. Durch den MedDoser kann die Wahrscheinlichkeit, Einnahmen von Medikamenten zu vergessen und den Therapieverlauf dadurch negativ zu beeinflussen, reduziert werden.

Der Patient sowie der behandelnde Arzt können zusätzlich retrospektiv den Medikationsverlauf anhand der erfassten Daten nachvollziehen. Durch diese Form der Unterstützung des Patienten in seinem Alltag fungiert der MedDoser als Teil von AAL (Ambient Assisted Living).


Anforderungen

  • Mobilität: Das Gerät soll auch ohne lokal gebundene Stromzufuhr verwendbar sein
  • Einlesen des Medikationsplans: Ein neuer beziehungsweise ein aktualisierter Medikationsplan, der auch aus mehreren Seiten bestehen kann, muss sich auf Wunsch einlesen lassen
  • Personalisierung der Erinnerungszeitpunkte: Der Benutzer kann pro Tageszeit bestimmen, wann er an die Einnahme seiner Medikamente erinnert werden möchte
  • Darstellung der Daten: Alle Medikamente, die Einnahmezeitpunkte und die Metadaten aus dem Medikationsplan werden dargestellt
  • Erinnerungsfunktion (optisch): Wenn ein oder mehrere Einnahmezeitpunkte überschritten wurden, wird dies durch wechselnde Farben auf dem Display sowie einer blinkenden LED gekennzeichnet. Hat der Patient die Einnahme der ausstehenden Medikamente quittiert, wird das Gerät automatisch in den Ursprungszustand
    versetzt
  • Erinnerungsfunktion (akustisch): Beim Überschreiten eines Einnahmezeitpunktes ertönt zeitgleich mit der optischen Erinnerungsfunktion ein Ton, so lange bis alle ausstehenden Einnahmen quittiert wurden


Verwendete Hardware

Die folgenden Bauteile wurden für das Projekt angeschafft und verbaut. Der Handscanner ist hierbei ein Workaround für die Raspberry-Kamera, mit der das Einlesen eines Medikationsplans Probleme machte.

Beschreibung Hersteller Preis (€)
RaspberryPi 3 Model B RaspberryPi 33,99
Netzteil (microUSB-Stecker) Goobay 6,47
Externe Stromquelle (Powerbank) EasyAcc 42,99
7-Zoll-Touchscreen (kapazitiv), mit Standfuß Waveshare 66,99
MicroSD-Karte (16GB) Intenso 6,90
Plastikgehäuse (schwarz) RaspberryPi 5,80
Kamera (Flachband) AZDelivery 11,99
USB-Handscanner (MK 6200) Albasca 145,80
LED (bunt) BinaryKitchen (Regensburg) 0,10
Miniatur-Lautsprecher (84 dB) Conrad 4,09
RTC (Real-Time-Clock) AZDelivery 6,29

Grundlage: Bundeseinheitlicher Medikationsplan (BMP)

Der bundeseinheitliche Medikationsplan (BMP) ist ein Plan, der einen Patienten bei seiner Einnahme unterstützen und die Therapiesicherheit gewährleisten soll. Seit dem 01. Oktober 2016 haben Patienten einen Anspruch auf den BMP in Papierform. Damit der BMP erstellt werden kann, müssen die folgenden beiden Anforderungen erfüllt sein:

  • Es müssen mindestens drei Medikamente von der gesetzlichen Krankenkasse (GKV) verordnet worden sein, die gleichzeitig und systematisch einzunehmen oder anzuwenden sind.
  • Die Medikamente müssen dauerhaft eingenommen werden. Eine dauerhafte Einnahme wird mit einem Mindestzeitraum von 28 Tagen definiert.

In der Regel wird der Anspruch gegenüber dem Hausarzt oder auch dem Facharzt geltend gemacht. Ab dem Jahr 2018 kann der Patient auf Wunsch den Medikationsplan in digitaler Version auf seine elektronische Gesundheitskarte (eGK) abspeichern lassen. Die Bundesärztekammer betont dabei, dass sie damit nicht die Papierform des BMP ersetzen wolle.

Jeder papierbasierte Medikationsplan besitzt einen DataMatrix-Code (Eine Art des 2D-Barcodes), der alle ausgedruckten Daten des Plans, im UKF (Ultrakurzformat) kodiert, enthält. Dieser Code wird mit dem MedDoser gescannt, in HL7-FHIR konvertiert, interpretiert und dargestellt.


Umsetzung - Randbedingungen und Qualitätsmaßnahmen

  • Die Programmierung der Anwendung erfolgt in Java (aus Kompatibilitätsgründen zum OS Rasbian Jessie) mit dem JDK 8.
  • Für die Datenspeicherung kommen SQLite (permanente Daten) und XML (Nutzerinteraktion) zum Einsatz.
  • Die Benutzeroberfläche wird mit JavaFX (siehe JavaFX und Raspbian OS) und dem SceneBuilder gestaltet.
  • Modultests werden mit JUnit verwaltet und gewartet.
  • Die Versionsverwaltung bei diesem Projekt wird mit git realisiert.
  • Um eine möglichst vollständige Codedokumentation zu erhalten, wird Javadoc genutzt.
  • Das Bugtracking übernimmt das CMS Mantis.
  • Beim Logging von Systemereignissen und kritischen Meldungen zur Laufzeit hilft die Bibliothek Log4J.

Umsetzung - Einscannen eines Medikationsplans

medDoser flowchart scan

Ein Medikationsplan kann aus mehreren Seiten bestehen - abhängig davon, wie viele Medikationen er enthält. Auf einer Seite können maximal 15 Medikationen enthalten sein, meist sind es weniger aufgrund von Metadaten wie Zwischenüberschriften und Freitextzeilen.

Das angefügte Diagramm zeigt den Vorgang des Scannens in Interaktion mit der UI. Erst nach einem erfolgreichen Scan werden alle Daten geparsed und zu einem HL7-FHIR-Dokument (Siehe Syntaktik: Health Level 7 (HL7)) zusammen gefügt.

Anschließend öffnet sich das Hauptfenster der Benutzeroberfläche und der Patient kann direkt damit beginnen, seine Medikationen zu verwalten.


Umsetzung - UKF zu HL7-FHIR

Der Schritt der Konvertierung des Medikationsplans vom Ultrakurzformat hin zum HL7-FHIR-Format wird mit einem Parser durchgeführt. Als Eingabe wird eine Zeichenkette erwartet, deren Inhalt dem UKF-Format entspricht. Das Ergebnis der Konvertierung ist eine XML-Datei, deren Inhalte dem FHIR-Standard entsprechen.

Üblicherweise werden zentrale Informationen wie die Pharmazentralnummer (PZN), die Wirkstoffe (bis zu drei) und der Handelsname in der Datenbank der IFA gehalten. Die PZN in einem UKF-Dokument dient daher normalerweise als Identifikator eines Medikaments, sie ist jedoch laut Spezifikation der KBV kein Pflichtfeld. In diesem Fall muss der UKF-String die genannten Daten explizit enthalten, ansonsten fehlen diese Informationen im FHIR-Dokument.


Umsetzung - Datenspeicherung

Weil die Lizenzierung der genannten IFA-Datenbank während des Projektverlaufs aus Kostengründen seitens der OTH Regensburg nicht realisierbar war, dient als Provisorium bei MedDoser eine SQLite-Datenbank. Über einen JDBC-Konnektor werden Daten aus ihr gelesen. Ein Schreibvorgang erfolgt ausschließlich beim Programmstart und dies auch nur dann, wenn die Datenbank auf dem Zielsystem (dem Raspberry Pi 3) zuvor noch nicht erstellt wurde.

Zur Verwaltung der täglichen und tageszeit-entsprechenden Einnahmen ist eine XML-Struktur (Siehe XML und XSD) am Sinnvollsten. Die Wahl für diese Form der Speicherung begründet sich damit, dass Hierarchien und Strukturen mit XML-Schemata besser abgebildet werden können als über eine relationale Datenbankstruktur. In folgendem Codefragment sind die Daten für genau eine Einnahme enthalten. Aus ihm ist ersichtlich, dass ein Medikament

  • mit einer speziellen ID (urn)
  • am 12. März 2018
  • abends (PCV) um 17:00 Uhr (Vom Patient festgelegter Wert aus dem Header)
  • noch eingenommen werden muss (Status 2).
<?xml version="1.0" encoding="UTF−8" standalone="no" ?>
<MedDoser>
<CreationDate>03/12/2018 00:11</CreationDate>
<LastOpenedDate>03/13/2018 00:53</LastOpenedDate>

<IngestionTime>
<morning time="08:00"/>
<midday time="12:00"/>
<evening time="17:00"/>
<night time="21:00"/>
</IngestionTime>

<MedicationIngestion>
<ingestionmedStatementReference=" urn:uuid:09e8d5b1−0e6f−4f0d−8871−5d7eeecbe532" scheduledDate="03/12/2018" scheduledTime="" scheduledTimeCode="PCV" status="2" time="" />
</MedicationIngestion>
</MedDoser>

Die Struktur dieses XML-Schemas wurde eigens für dieses Projekt entwickelt.

Die XML-Datei wird täglich erweitert: Entweder durch den Anwender, der den Status seiner Einnahmen durch Interaktion mit dem Touchscreen verändert, oder durch das Anbrechen eines neuen Tages. In diesem Fall wird für jede planmäßige Medikation ein neuer Eintrag mit dem Standard-Status 2 erstellt.

Nebenläufigkeit (Threads)

Die Funktionalität der Anwendung wird durch folgende Threads unterstützt:

  • Erstellen von Einträgen in der XML-Datei
    Beim erstmaligen Einscannen eines Medikationsplans mit dem MedDoser wird für jede Einnahme eines Medikaments des aktuellen Tages ein Eintrag in der XML-Datei generiert. Falls das Gerät über mehrere Tage hinweg ausgeschaltet war, werden bei Programmstart für jeden Tag, der seit dem letzten Tag, an dem das Gerät eingeschaltet war, vergangen ist, Einträge in der XML-Datei erstellt. Zusätzlich überprüft ein Thread alle 60 Sekunden, ob ein neuer Tag begonnen hat. Ist dies der Fall, werden automatisch die Einträge für den neuen Tag in der XML-Datei generiert und die Ansicht im Hauptfenster aktualisiert sich.
  • Aktualisieren der Uhrzeit
    Das aktuelle Datum sowie die Uhrzeit wird unterhalb des MedDoser-Logos in einem Label angezeigt. Weil der Zustand eines Labels statisch ist, muss die Uhrzeit regelmäßig aktualisiert werden. Hierzu legt der Thread alle fünf Sekunden die neue Uhrzeit als Text des Labels fest.
  • Erinnerung an die Einnahme
    Der Thread überprüft alle acht Sekunden, ob Medikationen noch nicht quittiert wurden. Hierbei werden Medikationen vom aktuellen Tag sowie der Vergangenheit in Betracht gezogen, die eine bestimmte Einnahmezeit definiert haben. Medikamente, die zu besonderen Zeiten eingenommen werden müssen, sind hiervon nicht eingeschlossen. Sobald mindestens eine Einnahme noch nicht vom Anwender quittiert wurde, beginnt er mit der Ausführung folgender Aktionen:
    • Farbliches Hervorheben der Tabs: Alle Tabs für die Einnahmezeiten des heutigen Tages, welche unbestätigte Medikationen enthalten, werden hervorgehoben.
    • Aktivieren und Deaktivieren von LED und Lautsprecher: Die GPIO-Pins des Lautsprechers und der LED werden aktiviert und sie beginnen, den Erinnerungston abzuspielen beziehungsweise zu blinken. Der Thread bemerkt, wenn der Benutzer alle Einnahmen erledigt hat und deaktiviert die beiden Komponenten in diesem Fall wieder.

Resultat

medDoser back"Der MedDoser von hinten. Zu sehen ist die LED sowie der Lautsprecher, die mittels Verbindungskabeln mit den GPIO-Pins des Raspberry Pis verbunden sind medDoser sideDer MedDoser von der Seite. Zu sehen ist der seitlich montierte Lautsprecher, dessen Verbindungskabel ins Gehäuse zeigen  medDoser side2Der MedDoser von der Seite. Zu sehen ist der seitlich montierte Lautsprecher, dessen Verbindungskabel ins Gehäuse zeigen md2Das Hauptfenster des MedDoser enthält alle tagesaktuellen Medikationen, aufgeteilt nach Einnahmezeit  md1Der Verlauf der Medikation enthält alle Medikationen seit dem Einscannen des Medikationsplans. Mit den 'R' und 'L'-Buttons hat der Anwender die Möglichkeit, zwischen Wochentagen und Kalenderwochen zu wechseln und auch im Nachhinein Medikationen zu bestätigen md3In diesem Fenster kann der Anwender die Einnahmezeiten nach seinen Bedürfnissen anpassen

Abschlussbericht

Ein ausführlicher Bericht inklusive Dokumentation zur Einrichtung der Software auf dem Gerät findet sich hier.

 

Siehe auch

  • SmartMirror - Marke Eigenbau
    SmartMirror: Planung und Bau eines digitalen Spiegels

    Das Internet der Dinge (IoT, Internet of Things) macht vor keinem Lebensbereich Halt. Um die Vorzüge dieses Megatrends selbst zu erfahren, habe ich mich entschlossen, das Ganze anhand eines "SmartMirrors" auszuprobieren: Dieser digitale Spiegel soll verschiedene Informationen in Form eines schicken Einrichtungsgegenstandes präsentieren.

  • JavaFX
    JavaFX und Raspbian OS

    Seit der Version 8u33 der ARM-Version von Oracle gibt es keinen Support mehr für JavaFX-Anwendungen out-of-the-box. Die offizielle Meldung dazu findet sich hier. Aus diesem Grund benötigt ein Raspberry-System eine manuelle Erweiterung. Die Voraussetzung dafür ist ein aktuelles installiertes JDK von Oracle auf dem Raspberry-System (siehe dieser Wiki-Artikel).

  • Indikatorenverlauf
    Masterarbeit: Berechnung von Qualitätsindikatoren

    Meine Studienlaufbahn und somit auch das Masterstudium der Fachrichtung Medizininformatik an der OTH Regensburg wird mit der Masterarbeit abgeschlossen.

    Ihr Titel lautet "Entwicklung einer datenschutzkonformen Client-Server-Infrastruktur zur Berechnung von Qualitätsindikatoren der ambulanten Versorgung in heterogenen Praxisnetzen".

    Die in diesem Rahmen entwickelte Software bietet niedergelassenen Haus- und Fachärzten die Möglichkeit, die Versorgung ihrer Patienten durch die Analyse von Qualitätsindikatoren zu verbessern.

Cookies erleichtern die Bereitstellung dieser Homepage. Mit der Nutzung dieser Seite erklären Sie sich damit einverstanden, dass Cookies verwendet werden. Mehr Informationen
OK, verstanden