380 lines
18 KiB
TeX
380 lines
18 KiB
TeX
\documentclass[12pt, a4paper]{article}
|
||
|
||
\usepackage[utf8]{inputenc}
|
||
\usepackage[T1]{fontenc}
|
||
\usepackage{DejaVuSerif} % Serif font
|
||
\usepackage{ascii} % Monospace font
|
||
\usepackage{csquotes}
|
||
\usepackage[english]{babel}
|
||
\usepackage{graphicx}
|
||
\usepackage{parskip}
|
||
|
||
\usepackage[onehalfspacing]{setspace}
|
||
\usepackage{geometry}
|
||
\usepackage{titlesec}
|
||
\usepackage{fancyhdr}
|
||
|
||
\usepackage{color}
|
||
\usepackage[colorlinks]{hyperref}
|
||
\usepackage{tcolorbox}
|
||
\tcbuselibrary{most}
|
||
\pagestyle{plain}
|
||
\usepackage[toc,nopostdot,nonumberlist,style=altlist,acronym]{glossaries}
|
||
|
||
% Page margins
|
||
\geometry{left=3cm, right=2cm, top=3cm, bottom=2cm}
|
||
|
||
% Correct footnote size
|
||
% TODO check if this is working correctly
|
||
\renewcommand{\footnotesize}{\fontsize{10pt}{12pt}\selectfont}
|
||
\usepackage[bottom]{footmisc}
|
||
|
||
% Section Headings
|
||
\titleformat*{\section}{\fontsize{16}{19}\selectfont\bfseries}
|
||
\titleformat*{\subsection}{\fontsize{14}{17}\selectfont\bfseries}
|
||
\titleformat*{\subsubsection}{\fontsize{12}{14.4}\selectfont\bfseries}
|
||
|
||
% Page Numbering
|
||
\pagestyle{fancy}
|
||
\fancyhf{}
|
||
\fancyhead[C]{\thepage} % Page number in header center
|
||
\renewcommand{\headrulewidth}{0pt}
|
||
\fancypagestyle{plain}{%
|
||
\fancyhf{} % clear all header and footer fields
|
||
\fancyhead[C]{\thepage}
|
||
}
|
||
\setlength{\headheight}{14.49998pt}
|
||
|
||
% Code listing
|
||
\usepackage{listings}
|
||
\definecolor{bgtinted}{HTML}{efefef}
|
||
\definecolor{codegray}{HTML}{111111}
|
||
\definecolor{codeorange}{HTML}{91632C}
|
||
\definecolor{codegreen}{HTML}{3D5232}
|
||
\definecolor{codepurple}{HTML}{4E3A52}
|
||
\lstdefinestyle{mystyle}{
|
||
backgroundcolor=\color{black!5!white},
|
||
commentstyle=\color{codepurple},
|
||
keywordstyle=\color{codegray},
|
||
stringstyle=\color{codegreen},
|
||
basicstyle=\asciifamily\color{codegray},
|
||
breakatwhitespace=true,
|
||
breaklines=true,
|
||
captionpos=b,
|
||
keepspaces=true,
|
||
showspaces=false,
|
||
showstringspaces=false,
|
||
showtabs=false,
|
||
tabsize=2
|
||
}
|
||
\lstset{style=mystyle}
|
||
|
||
% Inline code snippets
|
||
\newcommand{\code}[1]{\tikz[baseline=(X.base)]\node [draw=gray!50,fill=gray!25,semithick,rectangle,inner sep=2.5pt, rounded corners=3pt] (X) {\asciifamily\color{codegray}{#1}};}
|
||
|
||
% Citations
|
||
%\usepackage{cite}
|
||
\usepackage[backend=biber, style=vancouver]{biblatex}
|
||
\addbibresource{../bibliography/bibliography.bib}
|
||
|
||
% Colors
|
||
\definecolor{PLRI_Rot}{RGB}{190,30,60}
|
||
\definecolor{grau}{RGB}{120,110,100}
|
||
|
||
% A command which generates a TODO message
|
||
\newcommand{\todo}[1]{{\fontfamily{lmtt}\selectfont{\color{orange}\small\underline{TODO:}} \textbf{#1}\normalsize \\}}
|
||
|
||
\input{./glossary.tex}
|
||
|
||
\renewcommand{\thepage}{\Roman{page}}
|
||
|
||
\begin{document}
|
||
%{\fontfamily{phv}\selectfont}
|
||
|
||
\pagenumbering{Roman}
|
||
|
||
\input{cover.tex}
|
||
|
||
\section*{Summary}
|
||
\addcontentsline{toc}{section}{Summary}
|
||
|
||
The summary should be a guideline for creating the work, and briefly name the findings.
|
||
|
||
A summary must be written in both English and German.
|
||
|
||
\newpage
|
||
\renewcommand*\contentsname{Table of contents}
|
||
\tableofcontents
|
||
|
||
\newpage
|
||
\setcounter{page}{1}
|
||
\pagenumbering{arabic}
|
||
\section{Introduction}
|
||
|
||
\textbf{Gegenstand und Motivation}
|
||
|
||
\begin{itemize}
|
||
\item{brief description of the project}
|
||
\item{impact on the field}
|
||
\item{background (what lead to the project?)}
|
||
\item{motivation, predicted usefulness to the field}
|
||
\end{itemize}
|
||
|
||
\textbf{Problemstellung}
|
||
|
||
State clearly which problems exist.
|
||
They should phrased such that the project can solve them.
|
||
|
||
\textbf{Zielsetzung}
|
||
|
||
State clearly the goals of the research work.
|
||
The goals should be derived clearly from the problem statement, and meeting the goals should solve the stated problems.
|
||
|
||
\textbf{Frage- und Aufgabenstellung}
|
||
|
||
List concrete questions/tasks, derived from the goals.
|
||
Completing all tasks should result meeting all goals.
|
||
|
||
\textbf{Gliederung}
|
||
|
||
Describe the structure of the work.
|
||
|
||
|
||
\newpage
|
||
\section{Background}
|
||
|
||
\todo{write}
|
||
|
||
|
||
\newpage
|
||
\section{Architecture and Design}
|
||
|
||
Medwings is designed as a browser-based web application in the classic client-server model, facilitating centralized data storage and evaluation.
|
||
Opting for a web application offers numerous advantages: the primary benefit is its inherent cross-platform compatibility, enabling usage
|
||
on a wide range of devices such as mobile phones and personal computers.
|
||
Secondly, implementing a web application reduces complexity and shortens development time, compared to the creation of a native mobile app coupled
|
||
with a separate, dedicated API server.
|
||
|
||
\begin{figure}[!ht]
|
||
\begin{center}
|
||
\includegraphics[width=.75\textwidth]{./figures/components-macro.png}
|
||
\caption{\label{fig:components-macro}System diagram showing data flow and user interactions between components in the Medwings environment.}
|
||
\end{center}
|
||
\end{figure}
|
||
|
||
The overall system environment is shown in Figure~\ref{fig:components-macro}, depicting the following workflow:
|
||
\begin{enumerate}
|
||
\item A patient receives a notification on their mobile phone, prompting them to take vitals measurements.
|
||
\item Upon opening the notification, they are redirected to the Medwings website.
|
||
Here, they are prompted to self-assess their respiration score by answering a short questionnaire, followed by a prompt to take one measurement
|
||
on each smart medical device.
|
||
\item Upon completion of the measurement, each device transmits the data via Bluetooth to the Withings mobile app, installed on the user's phone.
|
||
The mobile app now sends the data to the Withings Cloud for storage.
|
||
\item A backend process on the Medwings server awaits the arrival of all recorded measurements from the Withings Cloud, storing them upon reception.
|
||
Once all required vitals measurements have been retrieved, the MEWS is calculated, stored and displayed to the patient.
|
||
\end{enumerate}
|
||
Measurement prompt notifications are dispatched to the patient at regular intervals throughout the day.
|
||
|
||
\subsection{Application Modules}\label{sec:modules}
|
||
|
||
To separate the different functional aspects of Medwings according to responsibility, its application code is split into the following five modules:
|
||
\begin{itemize}
|
||
\item \code{core}
|
||
\item \code{withings}
|
||
\item \code{gotify}
|
||
\item \code{authentication}
|
||
\item \code{medwings}
|
||
\end{itemize}
|
||
Each module defines classes representing backend logic, database schemas and user interface elements pertaining to its specific function.
|
||
Implementation details are encapsulated within these classes, while public interfaces are exposed to external program code to provide each module's core functionality.
|
||
|
||
The \code{core} module forms the backbone of the application.
|
||
It encompasses configuration settings, secrets such as private encryption keys or API tokens, and functionalities shared across multiple other modules.
|
||
|
||
Medwings interfaces with the Withings Cloud through the \code{withings} module.
|
||
This includes retrieving vitals data through authenticated requests to the Withings Cloud API, which implements the OAuth 2.0 Authorization Framework.
|
||
As per its specification, \enquote{In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server\ldots~
|
||
Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token\ldots~
|
||
The client uses the access token to access the protected resources hosted by the resource server.
|
||
}\cite{hardt_oauth_2012}
|
||
While this process is largely transparent for the resource owner --- the patient in this case --- the communication between
|
||
Medwings as the resource client and Withings as the resource server is complex, and is therefore abstracted by the module.
|
||
Aside from OAuth 2.0, \code{withings} also encapsulates fetching, parsing, and storing vitals data retrieved from Withings.
|
||
|
||
Medwings implements a standalone user authentication system, which is provided by the \code{authentication} module.
|
||
Patients must register with a username and password to be able to use the application.
|
||
The registration occurs in three stages:
|
||
\begin{enumerate}
|
||
\item The patient grants Medwings the permission to retrieve their health data from Withings in an OAuth2 authorization flow.
|
||
\item A registration form is shown, prompting the user to choose a username and password, and to enter relevant personal information.
|
||
\item The user is shown a confirmation that the account was created successfully, and is asked to download the Gotify app, described below, and log in using their Medwings credentials.
|
||
\end{enumerate}
|
||
Following registration, the supplied information and numerous authentication tokens are saved in the Medwings database.
|
||
Patients can now sign in on the Medwings website.
|
||
|
||
The \code{medwings} module, pivotal to the core functionalty of Medwings, defines the data model used to represent and store the various vital signs handled by the application.
|
||
Furthermore, it provides interfaces to access the data, as well as the algorithm used to calculate the MEWS.
|
||
|
||
In order to send push notifications to mobile devices, Medwings leverages \textit{Gotify} -- a dedicated notification microservice\cite{noauthor_gotify_nodate}.
|
||
Gotify is composed of a web server component, and a mobile app acting as the client software.
|
||
The server exposes its own API, which allows external applications like Medwings to dispatch push notifications programmatically.
|
||
It uses an independent database for client authentication. The \code{gotify} module ensures synchronization between the user databases of Gotify and Medwings.
|
||
In addition, the module provides interfaces to send customized push notifications to specific patients.
|
||
|
||
\subsection{Data Model}
|
||
|
||
A relational database is used to store application data, whereby each Medwings module defines the database schema for the underlying data it is responsible for handling.
|
||
Module interdependencies correlate closely with the foreign key references in the data model.
|
||
A holistic representation of the Medwings data model is shown in Figure~\ref{fig:datamodel}.
|
||
|
||
\begin{figure}[!ht]
|
||
\begin{center}
|
||
\includegraphics[width=\textwidth]{./figures/datamodel.png}
|
||
\caption{\label{fig:datamodel}Entity-Relationship diagram (Crow's Foot notation) showing the data model of the Medwings database.}
|
||
\end{center}
|
||
\end{figure}
|
||
|
||
At its heart lies the \code{User} entity: it forms the nexus to which all vitals data and user information is linked.
|
||
Withings API tokens are stored in the \code{RefreshToken} and \code{AccessToken} entities, while the \code{GotifyUser} and \code{GotifyAccount} entities retain the Gotify API credentials.
|
||
The numerous vital signs, as well as the MEWS record which can potentially be calculated based on them, are also represented.
|
||
The \code{Profile} table stores additional medically relevant patient information as supplied during user registration.
|
||
|
||
\subsection{Deployment}
|
||
|
||
To use the smart devices to take measurements, patient users must first install the Withings mobile app on their phone, and use it to create a Withings user account.
|
||
Following registration, each device must be linked to the app and configured via Bluetooth.
|
||
Some basic configuration is required in order to enable specific device features, such as measurement of \Gls{spo2} on the Scanwatch.
|
||
Users are guided through the process by the app's \Gls{gui}.
|
||
|
||
Being a web application, no installation is necessary to access the Medwings interface, patients simply visit the website in a web browser.
|
||
Patients do need to create a Medwings account on the website however, followed by installation and configuration of the Gotify mobile app, as described in the registration
|
||
process in Section~\ref{sec:modules}.
|
||
|
||
The centralized server components, including the Gotify server, a task scheduler used to schedule sending notifications and the Medwings application code itself are deployed
|
||
on a publicly accessible web server using a Docker container environment.
|
||
|
||
\subsection{Design Challenges}
|
||
|
||
Since managing a user in Medwings requires the respective user's state to be mirrored by two other services, Withings and Gotify, keeping user accounts across
|
||
all three services in sync presents a challenge.
|
||
Particularly during user creation, user accounts must be linked to Withings, created on the Gotify server and finally saved to the Medwings database.
|
||
Various integrity checks, such as when the user aborts the registration process midway, were put in place to prevent diverging user states across the three services
|
||
and overcome this challenge.
|
||
|
||
Similarly, vitals records kept in the Medwings database must be synchronized with all records available on the Withings cloud.
|
||
Regularly recurring, as well as on-demand data synchronization hooks were implemented to keep the Medwings database up to date,
|
||
while database constraints ensure validity of imported data and prevent duplication of existing records.
|
||
|
||
The non-enterprise Withings API enforces a rate limit of 120 requests per minute.
|
||
Medwings polls the API regularly to retrieve the latest health data for patients.
|
||
At scale, with many patient users, the rate limit would quickly be reached.
|
||
The Withing API does provide functionality to notify client applications upon availability of new data, making it possible to avoid polling.
|
||
Given that Medwings was only used by a single patient user during the trial phase, falling back to polling was an acceptable compromise to lower complexity
|
||
while still operating within the rate limit.
|
||
|
||
A MEWS calculation should represent the patient's overall physiological state at -- ideally -- a discrete point in time.
|
||
Naturally, there is a delay from when a measurement is taken with a device until it can be retrieved from the API.
|
||
The percieved transmission delay in the Medwings implementation was generally consistent with what is stated in the Withings public API documentation:
|
||
\enquote{Delays are typically less than two minutes, but it can be longer.}\cite{noauthor_keep_nodate}.
|
||
However, in some cases, the measurements taken on a device do not get pushed to the Withings Cloud until much later, or fail to do so at all.
|
||
While the cause for these longer than normal delays and missing data points is unknown and outside of the control of Medwings, these edge cases
|
||
had to be taken into account.
|
||
Furthermore, the time it takes a patient to take measurements using all three devices must also be accounted for.
|
||
Therefore, Medwings enforces a maximum allowed time difference of ten minutes between measurements of the different vitals records used to calculate MEWS.
|
||
If a set of vitals measurements is, across all records in the set, spaced further apart than ten minutes, no MEWS record is calculated, and the user is shown an
|
||
error message, prompting them to repeat the measurements.
|
||
|
||
|
||
\newpage
|
||
\section{System Interaction and Usability}
|
||
\begin{itemize}
|
||
\item Personal experiences in interacting with the system and the medical devices
|
||
\item What went well and what didn't? Why?
|
||
\item Usability for potential medical staff, if applicable
|
||
\item Strengths and weaknesses of patients taking their own measurements vs. having a medical professional take them
|
||
\item How well did patients (or you, in this case) adhere to the measurement schedule? What factors influenced this?
|
||
\end{itemize}
|
||
|
||
|
||
\newpage
|
||
\section{Data Presentation and Analysis}
|
||
\begin{itemize}
|
||
\item Present your measured vitals data in an organized and visual manner (tables, graphs, etc.)
|
||
\item Analyze the vitals and MEWS data: trends, anomalies, etc.
|
||
\item Discuss the regularity of measurements and the system’s effectiveness in prompting and collecting data
|
||
\end{itemize}
|
||
|
||
|
||
\newpage
|
||
\section{Evaluation and Validation}
|
||
\begin{itemize}
|
||
\item Describe the methods used to evaluate the system
|
||
\item Discuss the validity of the study, especially considering that the test patient was yourself
|
||
Explicitly state the limitations of your study. For example, the fact that you were the test patient, which might introduce bias into the results
|
||
\item Are the results likely to generalize? Why or why not?
|
||
\end{itemize}
|
||
|
||
|
||
\newpage
|
||
\section{Lessons Learned and Reflections}
|
||
\begin{itemize}
|
||
\item Reflect on the overall development process
|
||
\item What would you do differently if you were to start over?
|
||
\item What did you learn that was unexpected?
|
||
\end{itemize}
|
||
|
||
|
||
\newpage
|
||
\section{Future Work and Improvements}
|
||
\begin{itemize}
|
||
\item What can be improved in the current system?
|
||
\item Are there additional features that could make the system more effective?
|
||
\item Any scalability or security issues that would need to be addressed for a larger-scale deployment?
|
||
\end{itemize}
|
||
|
||
\newpage
|
||
\section{Implications and Conclusions}
|
||
\begin{itemize}
|
||
\item Implications of this research for the wider field of remote patient monitoring
|
||
\item Conclusions drawn from the research
|
||
\item Summary of the contributions of your work
|
||
\end{itemize}
|
||
|
||
|
||
\newpage
|
||
% TODO adjust: carry on from TOC
|
||
\setcounter{page}{3}
|
||
\pagenumbering{Roman}
|
||
\printnoidxglossary[title=Glossary, toctitle=Glossary]\label{sec:glossary}
|
||
|
||
\newpage
|
||
\printnoidxglossary[type=\acronymtype, title=Acronyms, toctitle=Acronyms]\label{sec:acronyms}
|
||
|
||
\newpage
|
||
\listoffigures
|
||
|
||
\newpage
|
||
\listoftables
|
||
|
||
\newpage
|
||
\printbibliography
|
||
|
||
% Appendix here
|
||
|
||
\newpage
|
||
\section*{Ehrenwörtliche Erklärung}
|
||
\addcontentsline{toc}{section}{Ehrenwörtliche Erklärung}
|
||
|
||
Ich versichere, dass ich die beiliegende Bachelorarbeit ohne Hilfe Dritter und ohne Benutzung anderer als der angegebenen
|
||
Quellen und Hilfsmittel angefertigt und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
|
||
kenntlich gemacht habe.
|
||
Diese Arbeit hat in gleicher Form noch keiner Prüfungsbehörde vorgelegen.
|
||
|
||
Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
|
||
|
||
|
||
Braunschweig, 12.09.2023
|
||
\vspace{3cm}
|
||
|
||
\end{document}
|