OpenHealthCheck

  • Problemstellung: Fragebögen zur Selbstdiagnose des eigenen Gesundheitszustands (Self-Health Check) werden meist nur in digitaler Form, wie beispielsweise als Website oder Mobile App, angeboten. Dadurch werden bestimmte Zielgruppen, die nicht über einen Zugang zu diesen digitalen Kanälen verfügen, von der Selbstdiagnose ausgeschlossen und müssen stattdessen direkt einen Arzt aufsuchen.
  • Lösung: Stattdessen sollte ein Service zur Selbstdiagnose über möglichst viele Kanäle angeboten werden, sodass dieser Service für alle verfügbar und erreichbar ist.
  • Zielsetzung: Wir wollen einen Self-Health Check anbieten, der über eine Vielzahl von Kanälen, wie Telefon (Sprache), Chat (Text), Web und App, genutzt werden kann. Der dahinterliegende Fragebogen muss zentral verwaltet werden können und für alle Kanäle gleichermaßen gelten.

Links:

Unsere Idee

Ein Self-Health Check sollte:

  • die Risikoabschätzung von Patienten ermöglichen
  • einheitlich für die gesamte Bevölkerung in Deutschland gelten
  • einfach zu bedienen sein
  • für alle (auch für ältere Menschen) zugänglich sein (daher OpenHealthCheck)
  • automatisiert ablaufen

Des Weiteren ist ein automatisierter Self-Health Check einem Arztbesuch vorzuziehen, weil:

  • (Risiko-)Patienten besser zu Hause bleiben sollten
  • Ärzte und Telefonhotlines entlastet werden sollten
  • ein automatisiertes und standardisiertes Verfahren Zeit sparrt und Sicherheit schafft
  • solch ein Service jedem und zur jeder Uhrzeit zur Verfügung steht

Benutzung des OpenHealthChecks

  1. Ich fühle mich krank.
  2. Ich will wissen, was ich tun soll.
  3. Ich wähle das Medium/den Kanal, der für mich am einfachsten zugänglich ist und mit dem ich am besten klar komme:
    • Ich öffne die OpenHealthCheck Web Applikation.
    • Ich wähle die automatisierte OpenHealthCheck Hotline.
    • Ich benutze den OpenHealthCheck Chatbot.
  4. Ich werde per Sprache, Chat oder grafischer Oberfläche durch den Fragekatalog geführt und beantworte die Fragen.
  5. Ich bekomme eine Diagnose/Zusammenfassung gestellt mit der Empfehlung zum Arzt zu gehen oder besser zu Hause zu bleiben.
  6. Ich notiere mir meinen persönlichen Diagnose Code, mit dem ich meinen Hausarzt aufsuchen kann.
  7. Mein Hausarzt bekommt mit diesem Code eine Übersicht meiner beantworteten Fragen und kann mich schneller behandeln.

Die Architektur hinter OpenHealthCheck

Um die Standardisierung des Verfahrens zu gewährleisten, ist es elementar wichtig, dass für alle Kanäle/Medien dieselben Fragen und dieselbe Auswertungslogik gilt. Zusätzlich darf kein Anwender durch ein bestimmtes Medium oder einen bestimmten Kanal beschränkt werden: Steht einem Anwender beispielsweise nur ein Telefon zur Verfügung, darf für ihn kein Nachteil gegenüber einem anderen Anwender entstehen, der beispielsweise auch per Web oder App auf den Dienst zugreifen könnte.

Dies erfordert, dass sämtliche Fragen wie auch die Auswertungslogik auf allen Kanälen synchron gehalten werden. Gleichzeitig sollen aber auch Änderungen der Fragen sowie der Auswertungslogik einfach handhabbar sein.

Aus diesem Grund haben wir uns für unseren Prototypen sowie auch für das spätere produktive Setup für eine verteilte Applikation entschieden, die durch eine zentrale Komponente gesteuert und verwaltet wird. Diese setzt sich zum aktuellen Stand (zum Zeitpunkt des Abschlusses des Hackathons) aus folgenden Komponenten zusammen:

Zentrales Backend mit RESTful API

Über einen zentralen Backend Server wird ein für alle Kanäle/Medien einheitlicher Fragebogen samt Auswertungslogik bereitgestellt. Des Weiteren werden über das Backend die beantworteten Fragen sowie die Selbstdiagnose/Zusammenfassung individuell für jeden Anwender gespeichert.

Das Backend verfügt daher über eine RESTful API (Web-basierte Schnittstelle), die den aktuellen Fragebogen in einem maschinell lesbaren Format (JSON) anbietet. Im Detail werden die Fragen einzeln als Web Ressourcen angeboten und können individuell für bzw. durch einen Anwender mit einer Antwort belegt werden. Ein "hypertext-driven" Design erzwingt die Beantwortung der einzelnen Fragen in der richtigen Reihenfolge. Vielmehr wird die Reihenfolge der Fragen innerhalb eines Fragebogens dynamisch auf Basis der bisherigen Antworten angepasst, indem ein Hyperlink, der auf die nächste zu beantwortende Frage referenziert, situationsbedingt gesetzt wird. Durch dieses Prinzip ist HATEOAS sowie ein RESTful Design der Schnittstelle gegeben. Für die Beschreibung der Schnittstelle liegt eine OpenAPI Dokumentation vor (siehe OpenAPI.json, der Inhalt von OpenAPI.json kann hier visualisiert werden).

Der Fragenbogen inkl. Fragen und Antwortmöglichkeiten werden in einem JSON File festgelegt und im Backend gespeichert. In diesem JSON File entsteht eine Graph-ähnliche Struktur, die die möglichen, antwortabhängigen Reihenfolgen bei der Beantwortung der Fragen widerspiegelt.

Das Backend wurde in Java mithilfe des Spring Boot Frameworks implementiert. Der Source Code findet man hier.

Der Anwender greift nun natürlich nicht direkt über die maschinelle Schnittstelle (RESTful API) auf den Fragebogen zu, sodern nutzt einen der Kanäle/Medien, um den OpenHealthCheck Service zu bedienen:

Speech Bot (Voice Kanal)

Für unseren Prototypen existiert vorerst nur ein Kanal zur Nutzung unseres OpenHealthCheck Services. Die Speech Bot Applikation ermöglicht die Benutzung von OpenHealthCheck mittels Sprache und soll einen Telefonservice repräsentieren. Der Anwender wird durch ein Sprachdialog (Spracherkennung und Sprachausgabe) durch den Fragebogen geführt. Speech Bot kommuniziert dabei im Hintergrund mit dem zentralen Backend und holt den aktuellen Fragebogen Frage für Frage über die RESTful API ab. Nach der Beantwortung einer Frage (das Ergebnis wird per HTTP PUT Request an das Backend übermittelt) wird per HTTP GET Request die nächste Frage geladen, wobei die Reihenfolge durch das Backend festgelegt ist und sich dynamisch, basierend auf der letzten Antwort ändern kann (siehe HATEOAS Prinzip im vorherigen Abschnitt).

Der Speech Bot ist in C# .NET implementiert und nutzt für die Spracherkennung die Microsoft Azure Speech Services (siehe Link). Der Source Code ist auf GitHub hinterlegt (siehe Link).

WebInterface für Ärzte

Der Speech Bot, wie auch die anderen noch geplanten Kanäle/Medien, geben nach der Beantwortung aller Fragen einen Diagnose Code dem Anwender zurück. Über ein grafisches Web Interface kann ein Arzt nun mithilfe des Diagnose Codes auf die durch den Anwender beantworteten Fragen zugreifen sowie die Diagnose einsehen. Die Antworten des Anwenders werden in der Oberfläche mit entsprechenden Farben hinterlegt, um eine schnelle manuelle Auswertung des Fragenkatalogs zu ermöglichen.

Das WebInterface greift über die RESTful API auf die im Backend hinterlegten Daten zu und kann entweder als eigenständige Server-Applikation oder im Backend integriert betrieben werden. Screenshots der Web Oberfläche sowie die auf Node.js basierende Implementierung ist in GitHub hinterlegt (siehe Link).

Editor zum Generieren des Fragenkatalogs

In unserem ersten Prototyp muss der Fragenkatalog noch manuell über das JSON File editiert werden. Jedoch existiert bereits zum jetzigen Zeitpunkt ein Web-basiertes Tool, das Bestandteil des Backends ist, und die Editierung des Fragenkatalogs vereinfachen soll. Das Tool visualisiert grafisch die möglichen Ablaufpfade (Reihenfolgen der Fragen) durch den Fragebogen. Modifikationen des Fragebogen im JSON File werden sofort im Tool angezeigt.

Erweiterungen/Ideen/nächste Schritte

Im nächsten Schritt wollen wir weitere, bereits in der Theorie aufgezeigte, Kanäle und Medien mitaufnehmen. Dazu zählen:

  • ein oder mehrere Chatbots für Telegram, WhatsApp, Instagram und Facebook (insbesondere Facebook erscheint hier, aufgrund der breiten Masse an Anwendern und der einfachen Integration (siehe Messenger API), als sehr attraktiv).
  • ein klassisches Web Interface für Desktop aber auch Mobile Browser
  • eine native Android/iOS App

Zusätzlich sollen auch das Updaten des Fragenkatalogs im Backend vereinfacht werden. Das Backend ist dabei zum einen um weitere API Endpoints zu erweitern, sodass Änderungen per HTTP Request eingespielt werden können (eine Versionierung des Fragenkatalogs ist bereits implementiert). Zum anderen soll aber auch das bisher existierende grafische, Web-basierte Tool ausgebaut werden, sodass Änderungen des Fragebogens auch grafisch erfolgen können (WYSIWYG-Editor)

Für einen produktiven Betrieb der Lösung sind zudem weitere Maßnahmen von Nöten, um die Daten sowie Schnittstellen des Backends vor unbefugtem Zugriff zu schützen. Zum Schutz der Schnittstellen kommt hier beispielsweise das OAuth 2.0 Framework in Frage.

Built With

+ 2 more
Share this project:

Updates