\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{booktabs} % thick horizontal lines
\usepackage{multirow}
\usepackage{array,tabularx}
\usepackage[bf]{caption} % custom table captions
\usepackage[table]{xcolor}
\usepackage[colorlinks]{hyperref}
\usepackage[most]{tcolorbox}
\pagestyle{plain}
\usepackage{pdfpages} % PDFs in appendix
\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}


\begin{document}


\input{cover.tex}

\pagenumbering{Roman}
\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}\label{sec: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{Methodology}

Following the development and deployment of the application, Medwings underwent a performance and usability study.
A test subject, impersonating a patient, used the application daily over the course of one week.
Each day, five notifications were dispatched every three hours, starting at 10 AM.
When prompted by a notification, the subject was asked to take vital sign readings using the three Withings medical sensors,
followed by a MEWS calculation carried out by Medwings.

The values of the vitals and MEWS records, as well as the time of measurement, were recorded by the application.
For each MEWS calculation, the test subject manually kept track of which type of environment the system was used in.
A distinction was made between the following environments:
\begin{itemize}
    \item At home: The subject was located at home, and their phone had access to a low latency broadband internet connection
    \item On the go: The subject was away from home, and their phone had access to a high latency mobile internet connection
\end{itemize}
Preceeding each MEWS measurement, the maximum data transmission rates, both uplink and downlink, as well as the average connection round trip time
from the subject's phone to a distant reference server was measured.
The location of the reference server was kept constant throughout the trial.

The occurrence of some measurement failures was anticipated, and manually recorded.
Measurement failures were categorized into eight distinct classes, as listed in Table~\ref{tab:measurement-failures}.

\begin{table}[!ht]
    \centering
    \begin{tcolorbox}[
            enhanced, width=0.95\linewidth, boxrule=2pt, arc=4pt,
            tabularx={>{\centering\arraybackslash}c|>{\centering\arraybackslash}c|>{\arraybackslash}X}
        ]
        \textbf{Device} & \textbf{Failure Class} & \textbf{Description} \\
        \specialrule{2pt}{0em}{0em}
        \multirow{2}{*}{Scanwatch} & $S_1$ & Device aborted measurement \\
        \cline{2-3}
        & $S_2$ & Measurement synchronization failure \\
        \hline
        \multirow{2}{*}{BPM Core} & $B_1$ & Device aborted measurement \\
        \cline{2-3}
        & $B_2$ & Measurement synchronization failure \\
        \hline
        \multirow{2}{*}{Thermo} & $T_1$ & Device aborted measurement \\
        \cline{2-3}
        & $T_2$ & Measurement synchronization failure \\
        \hline
        \multirow{2}{*}{---} & $P_1$ & Patient did not take any measurements \\
        \cline{2-3}
        & $P_2$ & MEWS calculation timed out \\
    \end{tcolorbox}
    \caption{\label{tab:measurement-failures}Classification of measurement failures during the usability trial}
\end{table}

The Scanwatch and BPM Core are equipped with accellerometers\cite{noauthor_worlds_nodate, noauthor_bpm_nodate}.
If erratic movement is detected, the devices abort the measurement to avoid misinterpretation of sensor readings.
Similarly, upon failure to process captured sensor data into a plausible result, a measurement may be aborted by the device\cite{noauthor_scanwatch_nodate, noauthor_bpm_nodate-1, noauthor_guides_nodate}.
The measurement failure classes $S_1$, $B_1$ and $T_1$ were used to record these kinds of failure for each respective device.
Following an $S_1$, $B_1$ or $T_1$ failure, the subject repeatedly carried out measurements unsing the affected device until a valid reading could be obtained.
Subsequent failures were also recorded.

As explained in Section~\ref{sec:design-challenges}, following a successful reading, a device may fail to push the measurement data to the Withings
Cloud within the ten minute validity range for a MEWS calculation imposed by Medwings.
Depending on which device failed to synchronize its data within the allowed time, a $S_2$, $B_2$ or $T_2$ failure was recorded.

If the subject did not carry out any vitals measurements despite being prompted by a notification, a $P_1$ failure was noted.
Finally, if the patient failed to carry out all three required measurements within the ten minute time limit, a $P_2$ failure was recorded.

Following $S_2$, $B_2$, $T_2$, $P_1$ and $P_2$ failures, the measurement process was not repeated until the next notification.

\newpage
\section{Data Presentation and Analysis}

The trial period encompassed seven days, on each of which five notifications were dispatched to the patient.
Thus, an overall of $N=35$ system interactions were recorded.
The patient was at home during $26$ of these, and on the go in all other cases.

Seven $P_1$ measurement failures occurred, wherein the patient did not react to a received notification by taking measurements.
Out of these, five occurred while the patient was on the go and, notably, four $P_1$ failures were consequtive, stemming from a period of 24 hours
during which the patient did not have access to the smart devices.
No $P_2$ measurement failures occured during the trial.

In total, vitals were measured using all three devices in $28$ cases.
However, in $11$ cases, at least one device failed to synchronize its readings within the ten minute timeout.
Throughout the trial, $17$ MEWS calculations were recorded successfully.
Figure~\ref{fig:measurement-stats} visualizes the overall measurement and failure counts.

\begin{figure}[!ht]
    \begin{center}
        \includegraphics[width=\textwidth]{./figures/chart-measurement-stats.png}
        \caption{\label{fig:measurement-stats}Measurement and measurement failure statistics at home and on the go.}
    \end{center}
\end{figure}

Out of $84$ successful individual measurements across all devices throughout the trial, $18\%$ took longer than premitted by Medwings to synchronize with the Withings Cloud.
Particularly while on the go, synchronization was prone to taking too long: $25\%$ of measurements resulted in synchronization failure, compared
to $11\%$ at home.
Especially the BPM Core and Thermo devices suffered from slow synchronization times: in a total of $15$ synchronization timeouts, $n_{B_2} = 7$ were caused
by the blood pressure meter, and $n_{T_2} = 7$ by the thermometer.

Three causing factors were identified: firstly, while the Scanwatch is constantly connected to the patient's phone, the BPM Core and Thermo devices only establish
a connection intermittently.
Presumably, measurement data updates from the smart device to the phone are sent less frequently.

The second factor becomes apparent when examining the likelihood of each device aborting a measurement due to inconclusive sensor data,
as displayed in Figure~\ref{fig:measurement-repeats}:
for the BPM Core, $15\%$ of attempted measurements had to be repeated ($n_{B_1} = 5$).
For the Scanwatch, over $34\%$ of readings ($n_{S_1} = 15$) were inconclusive and had to be repeated.
The Withings Thermo did not abort any measurements ($n_{T_1} = 0$).
Although aborted measurements did not cause synchronization failures directly, the time taken to repeat measurements did impact
the likelihood of the MEWS calculation timing out before all vitals data was synchronized.

\begin{figure}[!ht]
    \begin{center}
        \includegraphics[width=0.8\textwidth]{./figures/chart-measurement-repeats.png}
        \caption{\label{fig:measurement-repeats}Number of measurement attempts and aborted measurements for each smart device.}
    \end{center}
\end{figure}

Figure~\ref{fig:connection-boxplot} illustrates the comparative boxplots for the \gls{downlink-datarate}, \gls{uplink-datarate}, and \Gls{rtt} connection metrics when
the patient was at home versus on the go.
While there are evident differences in the distributions of these metrics between the two environments, the points representing synchronization failures do not
predominantly cluster around areas of low datarate or high \Gls{rtt}.

\begin{figure}[!ht]
    \begin{center}
        \includegraphics[width=\textwidth]{./figures/chart-connection-boxplot.png}
        \caption{\label{fig:connection-boxplot}Connection quality and synchronization failures.}
    \end{center}
\end{figure}

A reaction delay $t_r$ existed from when a notification was dispatched until the subject visited the Medwings website to take measurements.
The average ($\overline{t_{r,\text{home}}} = 36\text{ min}$) and median ($M_{t_{r,\text{home}}} = 33\text{ min}$) delay was significantly lower
while the patient was at home, compared to when they were out of the house ($\overline{t_{r,\text{on the go}}} = 68\text{ min}$, $M_{t_{r,\text{on the go}}} = 70\text{ min}$).
The average time taken to carry out all three measurements was $4.5$ minutes in both enviroments.

In all cases where vitals measurements were taken using the devices, the vitals data was captured and stored by Medwings.
All MEWS calculations carried out by the application returned the correct value as expected from the vitals data they were based upon.
The subject's vital signs were within their normal ranges representative of the patient's age for all measurements, with the exception of
two outliers where a slightly increased heart rate was measured.
Both outliers were detected correctly by Medwings.
The complete trial data can be seen in Appendix~\ref{apdx:trial-data}.


\newpage
\section{Evaluation and Validation}
% - Personal experiences in interacting with the system and the medical devices
% - What went well and what didn't? Why?
% - Usability for potential medical staff, if applicable
% - Strengths and weaknesses of patients taking their own measurements vs. having a medical professional take them
% - How well did patients (or you, in this case) adhere to the measurement schedule? What factors influenced this?
\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}

% The absence of a clear correlation suggests that synchronization failures were not majorly influenced by the fundamental connection quality metrics.
% The root cause of these failures likely lies elsewhere and is not solely dictated by raw connection performance.


\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
\addcontentsline{toc}{section}{List of figures}

\newpage
\listoftables
\addcontentsline{toc}{section}{List of tables}

\newpage
\printbibliography
\addcontentsline{toc}{section}{References}

\newpage
\appendix
\includepdf[pages=1, scale=0.95, pagecommand={\vspace*{-2.75cm}\section{Trial Data}\label{apdx:trial-data}}, angle=-90]{./attachments/trial-data.pdf}
\includepdf[pages=2-, scale=0.95, pagecommand={}, angle=-90]{./attachments/trial-data.pdf}

\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}
