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

\usepackage{algorithm}
\usepackage{algpseudocode}
\usepackage{subcaption} % allows multiple figures to share a caption

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

\todo{brief description of the project}

\subsection{Background}

% TODO add full lit review

Clinical \gls{deterioration} is a critical concern in healthcare, particularly for vulnerable populations such as the elderly and chronically
ill patients. It refers to a decline in a patient's health status and may lead to adverse outcomes, including hospitalization,
longer stays in intensive care units, and increased healthcare costs.
The \Gls{ews} has been widely adopted internationally for preemptive detection of deteriorating patients\cite{downey_strengths_2017}.
A large body of scientific evidence validates the effectiveness of \Glspl{ews} in assessing severity of illness, and in predicting adverse clinical events,
such as severe deterioration, likelihood of \gls{icu} admission, and mortality, both in hospital wards\cite{subbe_validation_2001, buist_association_2004, paterson_prediction_2006, gardner-thorpe_value_2006, alam_exploring_2015, bilben_national_2016, brekke_value_2019}
and in ambulatory care \cite{ehara_effectiveness_2019, burgos-esteban_effectiveness_2022, paganelli_conceptual_2022}.

Two commonly used clinical scores are the \Gls{news2} and the
\Gls{mews}\cite{burgos-esteban_effectiveness_2022}.
Both are calculated by capturing various vital parameters from the patient at a specific point in time, followed by numerical aggregation of the
captured data according to the score being used\cite{subbe_validation_2001, noauthor_national_2017}.
For \Gls{mews}, each measured physiological parameter is assigned an individual score based on which range it is in.
The ranges for scoring each parameter are shown in Table \ref{tab:mews-calculation}.
The individual scores are then added together to produce the final \Gls{mews}.
A MEWS value of 5 or above indicates an elevated risk of death, and likelihood of ICU admission\cite{subbe_validation_2001}.

\begin{table}[!ht]
    \centering
    \begin{tcolorbox}[
            enhanced, width=\linewidth, boxrule=2pt, arc=4pt,
            tabularx={
                >{\centering\arraybackslash\footnotesize}X
                >{\centering\arraybackslash\footnotesize\columncolor{red!15}}c
                >{\centering\arraybackslash\footnotesize\columncolor{orange!15}}c
                >{\centering\arraybackslash\footnotesize\columncolor{yellow!15}}c
                >{\centering\arraybackslash\footnotesize\columncolor{green!15}}c
                >{\centering\arraybackslash\footnotesize\columncolor{yellow!15}}c
                >{\centering\arraybackslash\footnotesize\columncolor{orange!15}}c
                >{\centering\arraybackslash\footnotesize\columncolor{red!15}}c
            }
        ]
        \tiny{Individual Score} & $\mathbf{+3}$ & $\mathbf{+2}$ & $\mathbf{+1}$ & $\mathbf{+0}$ & $\mathbf{+1}$ & $\mathbf{+2}$ & $\mathbf{+3}$ \\
        \specialrule{2pt}{0em}{0em}
        \tiny{\textbf{Systolic Blood Pressure} [mmHg]} & $<70$ & $71-80$ & $81-100$ & $101-199$ & ---  & $\geq 200$ & --- \\
        \hline
        \tiny{\textbf{Heart Rate} [bpm]} & --- & $<40$ & $41-50$ & $51-100$ & $101-110$ & $111-129$ & $\geq 130$ \\
        \hline
        \tiny{\textbf{Respiratory Rate} [bpm]} & --- & $<9$ & --- & $9-14$ & $15-20$ & $21-29$ & $\geq 30$ \\
        \hline
        \tiny{\textbf{Temperature} [°C]} & ---  & $<35$ & --- & $35-38.4$ & --- & $\geq 38.5$ & --- \\
        \hline
        \tiny{\textbf{AVPU}} & --- & --- & --- & \tiny{alert} & \tiny{reacting to voice} & \tiny{reacting to pain} & \tiny{unresponsive} \\
    \end{tcolorbox}
    \caption{\label{tab:mews-calculation}MEWS calculation ranges}
\end{table}

Traditionally, doctors and nursing staff perform collection and evaluation of the data manually, often inputting data into an EWS-calculator by hand.
However, as Eisenkraft et al. mentioned in 2023, \enquote{some known setbacks of the NEWS and other scales are the frequency of scoring and
response, integration into practice, and miscalculation by healthcare providers\ldots~}\cite{eisenkraft_developing_2023}.

\Gls{rpm} can improve deterioration detection\cite{shaik_remote_2023} by greatly reducing the
amount of human interaction required to take measurements and perform \Gls{ews} calculations.
A number of studies have explored \Gls{rpm} combined with automated \Gls{ews} calculation in hospitals\cite{eisenkraft_developing_2023, filho_iot-based_2021, un_observational_2021, karvounis_hospital_2021}.
With hospitals facing overwhelming patient load during the SARS-CoV-2 pandemic, interest in exploring \Gls{rpm} surged to unprecedented heights,
and \Gls{news2} emerged as an effective tool for predicting severe infection outcomes\cite{filho_iot-based_2021, gidari_predictive_2020, otoom_iot-based_2020, carr_evaluation_2021}
while reducing person-to-person contact during patient monitoring.

\subsection{Motivation}

While the application of \Glspl{ews} in ambulant care facilities and hospitals has been thoroughly investigated,
very little research has been done to assess their practicability for remote monitoring of at-risk patients at home.
Some studies have examined monitoring vital signs of at-home-patients for abnormalities,
however in most of them, no automated \Gls{ews} calculations were made\cite{archip_iot_2016, azimi_medical_2016, chowdary_efficient_2018, yeri_iot_2020, lee_all-day_2020, athira_design_2020, phaltankar_curaband_2021, thippeswamy_prototype_2021}.
In 2015, Anzanpour et al. developed a monitoring system which collects vitals data and calculates an \Gls{ews}, however due to limited or nonexistent
availability of wireless sensors for all relevant vital signs, the work was limited to using a laboratory prototype
and required manual interaction in transferring vitals data\cite{anzanpour_internet_2015}.
Sahu et al. documented their development of an \Gls{ews}-supported digital early warning system using the PM6750\cite{sahu_internet--things-enabled_2022},
an experimental vitals data monitoring device capable of taking continuous measurements in a laboratory setting\cite{noauthor_pm6750_nodate}.
However, the methodology they used to calculate an \Gls{ews} in real-time with laboratory data is both inconsistent and weak.

The availability of comprehensive, mobile vital signs monitoring equipment has seen a significant increase, especially in the wake of the SARS-CoV-2
pandemic\cite{paganelli_conceptual_2022, filho_iot-based_2021, otoom_iot-based_2020, gronbaek_continuous_2023}.
Since then, a variety of wearable medical sensors capable of continuously recording vital parameters have been developed and are
commercially available\cite{noauthor_visi_nodate, noauthor_equivital_nodate, noauthor_vitls_nodate, noauthor_caretaker_nodate, noauthor_medtronic_nodate, noauthor_bpm_nodate, noauthor_worlds_nodate, noauthor_smart_nodate}.
This surge in accessibility has paved the way for more extensive and continuous monitoring of patients in non-medical care settings.
This demonstrates the evolving landscape of \Gls{rpm}, aiming to improve clinical outcomes and alleviate the burden on hospital wards.

By remotely monitoring patients, it may be possible to identify early signs of deterioration, enabling earlier dismissal from
hospital care and thereby freeing up valuable resources.
Additionally, this approach holds the potential to reduce mortality rates and minimize the frequency of adverse clinical outcomes.

Installing and operating traditional continuous monitoring systems, like the vital sign monitors used in medical facilities, demands
specialized equipment and technical expertise.
Furthermore, these systems are cumbersome for patients, as they involve connecting patient and sensor device with numerous electrodes
and cables, restricting patient mobility to the bed area, and physically tying the monitoring equipment
to a single location.
Conversely, battery-powered, wireless vitals monitoring devices, such as wearable armbands or smartwatches, can combine several
biometric sensors into one device, allowing for a much higher degree of patient mobility, faster deployment and better
scalability\cite{un_observational_2021}.

In summary, with the current availability of wearable, networked biosensors and the validated effectiveness of \Glspl{ews} in medical facilities,
combining both aspects presents an important and interesting research opportunity which could help reduce mortality and improve clinical
outcomes for patients at risk of deterioration, both in their homes and on the go.
Conducting a feasibility study to explore the practicality and challenges of implementing a system capable of remote \Gls{ews} calculation for mobile patients
would contribute significantly to the existing body of knowledge and help advance the field of automated early warning score monitoring in
non-medical care settings.

\subsection{State of the problem}

% There is a lack of software calculating MEWS with RPM

The rapid advancements in wearable, networked biosensors have expanded the horizons of \Gls{rpm}.
Still, their integration with \Glspl{ews} remains under-explored, especially for outpatients or those outside traditional medical care settings.
While \Glspl{ews} have proven effective in hospitals and ambulant care facilities, the practicality of implementing them remotely, under real-life conditions,
leveraging state-of-the-art smart medical devices, remains uncertain.
Existing research on \Gls{rpm} predominantly focuses on the technology's capability for vitals monitoring, often sidelining the integration and automated calculation of \Glspl{ews}.
Consequently, there is a knowledge gap concerning the system's effectiveness, feasibility, and challenges when deployed in everyday environments,
particularly in patients' homes or during their daily routines.

\subsection{Research goals}

The objective of this research was to explore \gls{rwm}: remote monitoring of patients dismissed from direct medical care using an \Gls{ews}.

Specifically, the following questions were asked:

\begin{itemize}
    \item Is \Gls{rwm} practically feasible using smart medical devices commercially available today?
    \item Can existing, validated \Glspl{ews} be utilized in \Gls{rwm}?
    \item What are the technical and operational challenges of implementing an \Gls{rwm} system designed for daily use?
\end{itemize}

\subsection{Tasks}

The research questions stated above were pursued by designing, implementing and deploying an \Gls{rwm} system, followed by a usability study and subsequent evaluation
of the attained knowledge.

An outline of the steps taken to carry out this investigation is shown here:

\begin{enumerate}
    \item \textbf{EWS selection:} identification of an \Gls{ews} which is:
        \begin{itemize}
            \item widely recognized
            \item clinically validated
            \item applicable for adult patient evaluation
            \item capable of assessing the overall risk of patient deterioration
            \item not limited to specific patient populations
        \end{itemize}
    \item \textbf{Device selection:} procurement of smart medical devices that:
        \begin{itemize}
            \item are commercially available and have clinical approval for medical use
            \item offer user-friendly, non-intrusive measurement procedures, suitable for the patient to use at home and on the go
            \item allow secure and automated retrieval of the vitals data needed to calculate the chosen \Gls{ews} via an \Gls{api}
        \end{itemize}
    \item \textbf{System design and implementation:} development of a software application facilitating \Gls{rwm} using the selected medical devices, ensuring:
        \begin{itemize}
            \item regular vitals data capture from patients
            \item accurate calculation of the chosen \Gls{ews} based on captured data
        \end{itemize}
    \item \textbf{Real-world usability trial:} conduction of a trial, wherein a test subject utilizes the implemented system in real-world conditions,
        collecting data useful for system evaluation.
    \item \textbf{Evaluation:} methodical review of the implemented \Gls{rwm} system:
        \begin{itemize}
            \item Analysis regarding the effectiveness of the system in consistently gathering \Gls{ews} samples
            \item Investigation of failure points when \Gls{ews} sample retrieval was unsuccessful
            \item Collation of the subject's feedback on user experience
        \end{itemize}
    \item \textbf{Feasibility and challenge discussion:} reflection on the entire research process to:
        \begin{itemize}
            \item draw conclusions on the feasibility of \Gls{rwm} using modern smart medical sensors
            \item discuss application of the chosen \Gls{ews} for \Gls{rwm}
            \item highlight the identified technical and operational challenges
        \end{itemize}
\end{enumerate}

By completing these tasks, the research provided a comprehensive understanding of the practicality and potential pitfalls
of \Gls{rwm} in everyday settings, using current technology.

\subsection{Structure}

\todo{Describe the structure of the work.}

\newpage
\section{Medwings}

Three widely used \Glspl{ews} for deterioration are the \Gls{pews}\cite{monaghan_detecting_2005}, \Gls{news2}\cite{noauthor_national_2017} and \Gls{mews}\cite{subbe_validation_2001}.
All three are established as being effective in predicting clinical deterioration.
\Gls{pews} was excluded due to its application being limited to pediatric patients.
Among other factors, \Gls{news2} takes into account whether a patient is currently suffering from hypercapnic respiratory failure, and whether or not the
patient is currently being ventilated using supplemental oxygen.
These parameters are generally not applicable to patients dismissed from medical care, hence \Gls{mews} was chosen as the early warning score
for the envisioned \Gls{rwm} system.

To calculate \Gls{mews}, the following vital signs must be captured and processed by the system:
\begin{itemize}
    \item Heart Rate
    \item Blood Pressure (systolic)
    \item Body Temperature
    \item Respiratory Rate
    \item \Gls{avpu} Score
\end{itemize}

To develop an \Gls{rwm} system capable of gathering these vital signs and making them accessible remotely,
networked vitals measurement devices were used.
The process of selecting the right smart sensors presented a series of challenges.
A significant portion of the available medical sensors on the market were either not accessible to the general public, or are not distributed
in the geographic area where the research was carried out.
While considering devices that met the procurement criteria outlined earlier, a large number of products had to be excluded due to
constraining patient mobility within or beyond the confines of the patient's home.
Several promising devices were still undergoing development and had not yet received clinical approval, drastically limiting
the pool of viable options.

Among the shortlisted options, Withings emerged as the most feasible choice for several reasons.
Notably, they were the only manufacturer that offered a publicly accessible \Gls{api}, allowing for automated retrieval of vitals data.
Consequently, the following three devices were selected for the study:

\begin{itemize}
    \item \textit{Withings Scanwatch}\cite{noauthor_worlds_nodate} -- a smart watch capable of, among other things, measuring:
        \begin{itemize}
            \item \Gls{ecg}
            \item \Gls{spo2}
        \end{itemize}
    \item \textit{Withings BPM Core}\cite{noauthor_bpm_nodate} -- a digital blood pressure measurement cuff used to measure:
        \begin{itemize}
            \item Blood Pressure
            \item Heart Rate
        \end{itemize}
    \item \textit{Withings Thermo}\cite{noauthor_smart_nodate} -- a contactless digital thermometer for measuring:
        \begin{itemize}
            \item Body Temperature
        \end{itemize}
\end{itemize}

A picture of each device is shown in Figure~\ref{fig:withings-devices}.

\begin{figure}[!ht]
    \begin{center}
        \begin{subfigure}{.25\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/withings-scanwatch.png}
            \caption{\footnotesize Scanwatch}
            \label{fig:withings-scanwatch}
        \end{subfigure}
        \hfill
        \begin{subfigure}{.25\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/withings-bpm-core.png}
            \caption{\footnotesize BPM Core}
            \label{fig:withings-bpm-core}
        \end{subfigure}
        \hfill
        \begin{subfigure}{.25\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/withings-thermo.png}
            \caption{\footnotesize Thermo}
            \label{fig:withings-thermo}
        \end{subfigure}
        \caption{Withings smart medical devices \textit{(image sources: Withings Scanwatch\cite{noauthor_worlds_nodate}, Withings BPM Core\cite{noauthor_bpm_nodate}, Withings Thermo\cite{noauthor_smart_nodate})}}
        \label{fig:withings-devices}
    \end{center}
\end{figure}

Notably, the AVPU score could not be measured, because it typically necessitates a clinical assessment.
Furthermore, the inclusion of the Withings Scanwatch came with a notable limitation.
Although the device possesses the capability to measure a patient's respiration rate, this functionality is restricted to nocturnal measurements during sleep.

After consulting with several medical professionals, a decision was made to forgo the traditional respiration rate measurement, as well as the AVPU parameter in the \Gls{mews} calculation.
Instead, we introduced a custom \textit{respiration score}, shown in Table~\ref{tab:respiration-score}, which represents any shortness of breath reported by the patient.

\begin{table}[!ht]
    \centering
    \begin{tcolorbox}[
            enhanced, width=0.9\linewidth, boxrule=2pt, arc=4pt,
            tabularx={l|>{\centering\arraybackslash}X}
        ]
        \textbf{Condition} & \textbf{Score} \\
        \specialrule{2pt}{0em}{0em}
        Patient is \textit{not} suffering from shortness of breath & 0 \\
        \hline
        Patient is experiencing \textit{some} shortness of breath & 1 \\
        \hline
        Patient is suffering from \textit{severe} shortness of breath & 2 \\
    \end{tcolorbox}
    \caption{\label{tab:respiration-score}Scoring table for Medwings' custom respiration score}
\end{table}

To replace the respiration rate in the \Gls{mews} calculation, we took into account the patient's \Gls{spo2}, as well as the described respiration score.

\subsection{Requirements}

Following the selection of an \Gls{ews} and suitable medical sensors, a comprehensive \Gls{rwm} application was conceptualized,
dubbed as the \textit{Mobile Early Deterioration Warning System (Medwings)}.
Prior to its development, several key software requirements for the application were determined.

\subsubsection{Functional Requirements}

\begin{description}
    \item[User Authentication:] Medwings must provide a robust user authentication and authorization system to ensure confidentiality of sensitive patient data, while preventing
        unauthorized access to restricted information.
    \item[Portability:] Patients must be able to access Medwings from their mobile phone. Enabling access from other types of end user devices is desirable.
    \item[Data Collection:] The application must be capable of collecting and storing vital sign readings from all three Withings smart medical sensors without manual
        interaction. Additionally, it must be able to prompt patients on whether they are experiencing shortness of breath, and store the response.
    \item[Measurement prompts:] The application must regularly prompt patients to take vital sign readings.
    \item[MEWS Calculation:] When sufficient vital signs for a patient are collected, Medwings must automatically compute and store the \Gls{mews}.
    \item[Data Synchronization:] Vitals data, \Gls{mews} measurements and any associated metadata should be synchronized and accessible on
        each of the patient's end devices. The captured data should be stored for later analysis.
    \item[Data Visualization] Patients should be able to view a history of recorded vitals and \Gls{mews} measurements.
\end{description}

\subsubsection{Non-functional Requirements}

\begin{description}
    \item[Usability:] Medwings should be intuitive and user-friendly, requiring minimal technical expertise from the end-user.
        User interfaces should be adaptive for display on both mobile displays and larger monitors.
        If measurements or user interactions are invalid, error messages should be displayed to the user.
    \item[Availability:] The system should be available for patients to use at all times, with minimal downtime.
    \item[Data Validity:] Vitals records retrieved from the smart sensor devices must be converted and displayed correctly.
        Calculated \Gls{mews} values must be correct and take into account all relevant vital parameters:
        \begin{itemize}
            \item systolic blood pressure
            \item heart rate
            \item body temperature
            \item \Gls{spo2}
            \item respiration score
        \end{itemize}
        When such a set of vitals measurements is used to calculate a \Gls{mews}, the time of measurement for any two
        measurements in the set cannot be further apart than ten minutes
    \item[Security:] All personal and medical data should be stored securely and. Data in transit must be encrypted at all times.
        The identity of clients and servers must be cryptographically verifiable.
\end{description}

\subsection{Design and Implementation}

Medwings was designed as a web-based application, accessible through a web browser.
Opting for this format offers several 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.

Adhering to the classic client-server paradigm, the Medwings design prioritizes centralized data storage and processing.
This architecture was found to be benificial for ensuring efficient data synchronization, secure authentication,
and high system availability.

Django, a high-level Python web framework, was employed to develop both the frontend and backend components of the Medwings application.
One of the primary motivations for selecting Django was its out-of-the-box user authentication and session management capabilities.
Such features substantially expedited the development process, freeing up time and resources to focus on the unique, medically-oriented functionalities of Medwings.
Furthermore, Django's integrated Object-Relational Mapping (ORM) system greatly simplified the creation, management, and querying of the application's database.
This was pivotal given the essential role of the database in storing vitals data.

While web applications offer many advantages, one limitation is their inability to support push notifications directly to the patient's mobile phone.
To address this gap, a separate push notification microservice was deployed and integrated with Medwings.
Considering the time constraints, this approach proved to be an effective compromise.

\subsubsection{Architecture}

\begin{figure}[!ht]
    \begin{center}
        \includegraphics[width=.75\textwidth]{./figures/components-macro.png}
        \caption{System diagram showing data flow and user interactions between components in the Medwings environment.}
        \label{fig:components-macro}
    \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.

\subsubsection{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. This process is shown in
        Figures \ref{fig:ui-register-init} and \ref{fig:ui-register-oauth2}.
    \item A registration form, displayed in Figure~\ref{fig:ui-register-continue}, 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.
        Figure \ref{fig:ui-register-finalize} shows the finalization step.
\end{enumerate}
Following registration, the supplied information and numerous authentication tokens are saved in the Medwings database.
The patient can now log in to the Medwings website and begin using the system to take vitals and \Gls{mews} measurements.

\begin{figure}[!ht]
    \begin{center}
        \begin{subfigure}{.21\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/screenshot-register-init.png}
            \caption{User signup initialization}
            \label{fig:ui-register-init}
        \end{subfigure}
        \hfill
        \begin{subfigure}{.21\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/screenshot-register-oauth2.png}
            \caption{Withings OAuth 2.0 grant}
            \label{fig:ui-register-oauth2}
        \end{subfigure}
        \hfill
        \begin{subfigure}{.21\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/screenshot-register-continue.png}
            \caption{User details prompt}
            \label{fig:ui-register-continue}
        \end{subfigure}
        \hfill
        \begin{subfigure}{.21\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/screenshot-register-finalize.png}
            \caption{Registration finalization}
            \label{fig:ui-register-finalize}
        \end{subfigure}
        \caption{Medwings user registration process}
        \label{fig:ui-registration}
    \end{center}
\end{figure}

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, which is listed in Algorithm~\ref{algo:mews}.

\begin{algorithm}
\begin{algorithmic}[1]
\Procedure{CalculateMews}{$bp, temp, hr, spo2, resp\_score$}
    \State $mews\_value \gets 0$
    \If{$bp \leq 70$} \State $mews\_value \gets mews\_value + 3$
    \ElsIf{$bp \leq 80$} \State $mews\_value \gets mews\_value + 2$
    \ElsIf{$bp > 100$ \textbf{and} $bp \geq 200$} \State $mews\_value \gets mews\_value + 2$
    \EndIf
    \If{$hr < 40$ \textbf{or} $hr \geq 130$} \State $mews\_value \gets mews\_value + 2$
    \ElsIf{$hr \leq 50$ \textbf{or} $hr \leq 110$} \State $mews\_value \gets mews\_value + 1$
    \EndIf
    \If{$resp\_score = 1$} \State $mews\_value \gets mews\_value + 1$
    \ElsIf{$resp\_score = 2$} \State $mews\_value \gets mews\_value + 2$
    \EndIf
    \If{$spo2 < 90$} \State $mews\_value \gets mews\_value + 2$
    \ElsIf{$spo2 < 95$} \State $mews\_value \gets mews\_value + 1$
    \EndIf
    \If{$temp < 35$ \textbf{or} $temp > 38.4$} \State $mews\_value \gets mews\_value + 2$
    \EndIf
    \State \Return $mews\_value$
\EndProcedure
\end{algorithmic}
\caption{\label{algo:mews}Medwings MEWS calculation}
\end{algorithm}

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.

\subsubsection{User Interface}

The Medwings \Gls{ui} was developed with specific design goals in mind to ensure an efficient and intuitive user experience.
Figure \ref{fig:ui-screenshots} provides some impressions from a user's perspective.

\begin{figure}[!ht]
    \begin{center}
        \begin{subfigure}{.3\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/screenshot-home-page.png}
            \caption{Medwings home page}
            \label{fig:ui-screenshot-home-page}
        \end{subfigure}
        \hfill
        \begin{subfigure}{.3\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/screenshot-vitals-measurement.png}
            \caption{Starting a measurement}
            \label{fig:ui-screenshot-mews-init}
        \end{subfigure}
        \hfill
        \begin{subfigure}{.3\textwidth}
            \centering
            \includegraphics[width=\linewidth]{./figures/screenshot-recording.png}
            \caption{Waiting for synchronization}
            \label{fig:ui-screenshot-mews-continue}
        \end{subfigure}
        \caption{Medwings \Gls{ui} screenshots}
        \label{fig:ui-screenshots}
    \end{center}
\end{figure}

Aiming for a clutter-free and fast user experience, simplicity served as the guiding principle to enhance usability.
A focus was put on developing accessibility-friendly \Gls{ui} components, ensuring that the system is usable by visually impaired individuals.

Security was a top priority in the frontend implementation to protect users and the system from common vulnerabilities.
Overall, the use of JavaScript was kept to a minimum to reduce the attack surface.
Various security measures were carefully put in place to reduce the attack surface of the website:
\begin{itemize}
    \item User input and form field sanitization, alongside strong server-side validation to prevent cross-site scripting (XSS) and SQL injection attacks
    \item To counteract cross-site request forgery (CSRF) attacks, CSRF tokens were implemented on all forms
    \item To minimize the risk of supply chain and third-party XSS attacks, no external JavaScript dependencies are used by Medwings
\end{itemize}

Considering that mobile devices are the primary platform for Medwings, the \Gls{ui} was designed to be fully responsive.
It adapts seamlessly to different screen sizes, whether accessed through mobile phones, tablets, or devices with a larger form factor.
Fast load times were a crucial design goal to ensure usability under various network conditions.

Navigational elements and the overall layout follow conventional patterns.
Animations are sparingly used to visually indicate in-progress system states, such as when waiting for data retrieval from the Withings Cloud.

\subsubsection{Datamodel}

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 \Gls{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.

\subsubsection{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.

\subsubsection{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{System test and trial}

Following the development and deployment of the application, Medwings underwent a performance and usability study.
Over the course of one week, a test subject, impersonating a patient, used the application several times a day.

Each day, five notifications were dispatched every three hours, starting at 10 AM.
When prompted by a notification, the subject was asked to visit the Medwings website and begin the measurement process.
Following a notification, the measurement process was carried out in the following order:

\begin{enumerate}
    \item The subject responds to a Medwings prompt to assess their respiration score.
    \item Using the Scanwatch, the subject starts an \Gls{spo2} measurement and awaits its completion.
    \item A blood pressure and heart rate check is initiated on the BPM core, and the subject waits for the results.
    \item The subject takes a body temperature reading via the Thermo and waits for it to complete
    \item Finally, the subject allows time for Medwings to aggregate all the data and display the \Gls{mews}.
\end{enumerate}

Throughout this process, Medwings would continuously attempt to retrieve the vital sign readings from the Withings cloud, and calculate the
\Gls{mews} once all required readings are available.
If not all readings could be retrieved within the ten minute timeout, Medwings displayed an error message and aborted the \Gls{mews}
measurement process.

\subsection{Methodology}

For each vital sign measurement, as well as for each MEWS calculation, Medwings stored the measurement results alongside the
time of measurement.

For each received notification, the test subject manually kept track of which 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 end device had access to a low latency broadband internet connection
    \item On the go: The subject was away from home, and their end device had access to a high latency mobile internet connection
\end{itemize}
The end device used by the subject to connect to Medwings was their phone throughout the trial.
In addition, the subject reflected on noteworthy experiences regarding use of the system after the trial was completed.

The occurrence of 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 the Scanwatch, BPM Core and Thermo respectively.
Following an $S_1$, $B_1$ or $T_1$ failure, the subject repeatedly carried out measurements using the affected device until a valid reading could be obtained.
Subsequent failures caused by the device aborting measurements were also recorded.
The count of \enquote{device aborted measurement}-failures of each device was compared to the total number of measurement attempts using that device.

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 whether the Scanwatch, BPM Core or Thermo failed to synchronize its data within the allowed time, an $S_2$, $B_2$ or $T_2$ failure was recorded respectively.
The number of measurement synchronization failures which occurred was compared to the number of successfully synchronized measurements for each device.
Following an $S_2$, $B_2$ or $T_2$ failure, the measurement process was not repeated until the next notification.

For each notification to which the subject responded, the duration between when the notification was dispatched and when the patient took the first vitals measurement was recorded.
Additionally, the average time taken to complete all three vitals measurements was noted.
If the subject did not visit the Medwings website or 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 vitals measurements within the ten minute time limit, a $P_2$ failure was recorded.

Preceeding each MEWS measurement, metrics quantifying the quality of the connection between the subject's end device and other devices across the internet were measured.
This was done by sampling and averaging the data transmission rates, both uplink and downlink, as well as the connection round trip times from the end device to a distant reference server,
the location of which was kept constant throughout the trial.
The collected connection metrics were compared with the occurrence of measurement synchronization failures.

\subsection{Data Presentation}

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 consecutive, 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.
The patient reported feeling reluctant about taking measurements using the devices in public spaces, compared to the privacy of their home.

In total, vitals were measured using all three devices in $28$ cases.
However, in $11$ cases, at least one device failed to synchronize its measurements with the Withings Cloud 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 vitals 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.

The likelihood of each device aborting a measurement due to inconclusive sensor data was examined and is visualized 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$).

\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
when 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 patient reported feeling fatigued by the regularity of the notifications from the second trial day onwards.

The average time it took the patient to carry out all three measurements was $4.5$ minutes, with no significant difference between the \enquote{at home} and
\enquote{on the go} environments.

In all cases where vitals measurements were taken using the devices, the vitals data was captured and stored by Medwings.
In cases where the measurement data was not uploaded to the Withings Cloud quickly enough for Medwings to calculate the \Gls{mews}, the recorded
vitals data was still pulled into the Medwings database.
Across all measurements, the subject's vital signs were within normal ranges, with the exception of
two outliers where a slightly increased heart rate was measured.
Both outliers were detected by Medwings in the form of an elevated \Gls{mews}.

The complete trial data is listed in Appendix~\ref{apdx:trial-data}.

\subsection{Interpretation}

The system was successful in retrieving a wide range of vital signs from the patient at regular intervals, and detected abnormal readings
using the \Gls{mews}.
All \Gls{mews} calculations carried out by Medwings resulted in the correct value based on the recorded vitals data.
Both at home and on the go, the patient's vital parameters could be monitored using the system.

While at home, the test subject was able to adhere well to the measurement schedule, missing measurements only twice throughout the week.
With a three-hour window to respond to each notification, the average response time of 36 minutes and the minimal number of $P_1$ failures show that the
4.5-minute measurements were manageable within the home setting.

On the go however, a significant portion of the received notifications were not followed up by vitals measurements.
When leaving the house for extended periods of time, the subject was not always able to bring the whole array of medical devices with them.
Additionally, taking measurements could not always be done discreetly in public spaces, and finding a private area to take measurements
was not always possible.
This lead to a high rate of $P_1$ failures on the go, coupled with a comparatively long average reaction time of $\overline{t_{r,\text{on the go}}} = 68\text{ minutes}$.

The rate at which device synchronization failures occured was high, with $39\%$ of successful measurements not being pushed to the Withings cloud in time
for a \Gls{mews} calculation to be valid.
A combination of three factors was determined to be the cause for this.

Firstly, while the Scanwatch is constantly connected to the patient's phone, the BPM Core and Thermo devices only establish
their bluetooth connection intermittently.
Presumably, measurement data updates from these devices are sent to the phone less frequently than for the Scanwatch.
This is strongly underlined by the fact that $93\%$ of all synchronization timeouts were caused by the BPM Core or Thermo.

The second factor becomes apparent after examining the likelihood of each device aborting its measurement due to inconclusive sensor data,
as displayed in Figure~\ref{fig:measurement-repeats}.
Although the aborted measurements did not cause synchronization failures directly, the time taken to repeat measurements impacted
the likelihood of the MEWS calculation timing out before all vitals data was synchronized.
The Scanwatch was particularly prone to prolonging the overall time it took the patient to complete all readings.

The third factor was the time it took the Withings app to push vitals data to the Cloud, and data being available for retrieval through the Withings API.
While no concrete data to quantify this duration could be gathered, it is clear that the two minute delay estimate provided by the manufacturer\cite{noauthor_keep_nodate} was exceeded
substantially in many cases.
The relationship between the connection quality and the likelihood of synchronization failures was examined, as shown in Figure~\ref{fig:connection-boxplot},
but no correlation was found, suggesting that synchronization failures were not majorly influenced by the current connection quality of the subject's end device.

Ultimately, while $61\%$ of notifications to which the patient responded did result in a successful \Gls{mews} calculation, the high rate of device synchronization timeouts
suggests that routing data from the device, to the mobile app, to the Withings cloud, and finally to the Medwings server introduces substantial delays,
thereby affecting the system's usability for its near-real-time calculation requirement.

\newpage
\section{Evaluation}

The Medwings application successfully met its predetermined software requirements.
The system demonstrated robust user authentication mechanisms and offered portability by being accessible on mobile phones.
Additionally, it provided an intuitive interface for data visualization.
Vital signs were collected and stored automatically from all three Withings smart medical sensors, and the respiration score was able to be determined interactively.
The system was consistently available and ensured data validity, while maintaining stringent security protocols.
While certain challenges were encountered during the usability trial, the software's overarching objectives in terms of functional and non-functional
requirements were successfully achieved.

The usability study of the Medwings system provided valuable insights into the system's performance, reliability, and user interaction experience.
Classifying measurement failures into types helped to identify bottlenecks and other areas for improvement.
Overall, the system performed well in obtaining vitals readings regularly from a patient test subject.
The system successfully aggregated data from multiple sources to compute the \Gls{mews}, with all calculations being accurate.
At home, the patient was able to take all vitals measurements quickly and accommodate the measurement process into their daily routine, leading to a
high rate of interaction with the system.
Within the limited trial period, Medwings was able to detect abnormal readings effectively.

A significant portion of recorded vitals data, however, could not successfully be converted into \Gls{mews} records.
These calculation failures pertained to device synchronization delay with the Withings Cloud, highlighting a critical issue.
The BPM Core and Thermo devices synchronize only when turned on through manual interaction.
This leads to longer sync times for these devices, inhibiting Medwings from accessing new vitals data swiftly and performing a timely \Gls{mews} calculation.
A timeout period more lenient than the ten minute window imposed by Medwings may reduce the rate of synchronization failures, but it may also negatively
impact the validity of a \Gls{mews} record if implemented.
The study found that connection metrics such as data transmission rates and round-trip times did not show a significant correlation with synchronization failures.
This suggests that other factors, likely server-side processing delays on the Withings Cloud, contribute to these failures.

The study also revealed that the system is generally more reliable when the patient is at home, as indicated by the low interaction rate while on the go.
One reason was that carrying a a range of vitals sensors while out of the house is not always feasible.
Another was the subject's reluctance to take measurements in public spaces, suggesting a need for more discreet solutions for on the go vitals monitoring.
However, when measurements were made in the mobile environment, Medwings was successful at aggregating the measured data and, aside from the aforementioned
synchronization issues, was able to calculate the subject's \Gls{mews}.

%Patients appreciate the face-to-face aspect of early warning score monitoring as it allows for reassurance, social interaction, and gives them further opportunity to ask questions about their medical care\cite{downey_patient_2018}.

\subsection{Limitations}

Several limitations of the current study and the Medwings system must be noted.

Firstly, the original \Gls{mews} algorithm could not be used in its unaltered form to facilitate automated deterioration scoring.
Measuring the respiration rate and \Gls{avpu} of a mobile patient presented a challenge, which had to be overcome by disregarding
the \Gls{avpu} from the calculation and replacing the respiration rate in favor of a custom respiration score and \Gls{spo2} measurements.

Furthermore, the usability study had only a single test subject, which does not capture the diversity of potential user experiences.
Due to time constraints, the trial period was limited to lasting only one week, reducing the sample size and potentially introducing
bias in the gathered data.

Measurement prompts were dispatched every 3 hours during the day. This allows for just a restricted, intermittent view of a patient's
physiological state, and the chosen sampling period may require adequate ajdustment.

Moreover, although designed and implemented as a multi-user system, Medwings was only tested with one active user.
When used by many more users, the proof-of-concept system may encounter scalability issues, such as exceeding the API rate limits
imposed by Withings.

Lastly, using Medwings and the smart medical devices requires the patient to have internet access, which will negatively impact the
system's effectiveness in some circumstances where a stable connection is not available.

\newpage
\subsection{Future Work and Improvements}

The Medwings system, while successful in its current iteration, offers multiple avenues for improvement.

Its dependence on web-based access to the Withings API to retrieve vitals readings results in significant delays and mandates an internet connection.
A native mobile application offering direct Bluetooth access to sensor measurements would enhance real-time responsiveness and negate the necessity for a stable internet connection.
Unfortunately, Withings do not offer such an option to developers.
Vendor dependence in general introduces a risk to Medwings' continued operation.
Service outages, discontinued device updates, or the vendor ceasing business operations all render the smart devices, and consequently Medwings, unusable.
Vendor-independent access and open-source firmware for the medical devices would mitigate these risks and open up exciting possibilities for further system integrations.

Additionally, expanding the range of monitored vitals could allow implementation of more comprehensive \Gls{rwm} techniques.
The integration of a smart device capable of accurately measuring the respiration rate of a mobile patient would refine the \Gls{mews} calculations,
leading to a more accurate deterioration monitoring system.
The system could also benefit from real-time alerting for emergency situations, rather than relying solely on periodic \Gls{mews} calculations.
This would not only make the system more robust but would also be crucial for immediate medical intervention.
For healthcare providers, a monitoring platform could be developed to allow medical staff to have direct visibility into their patient's vitals and recent developments. 

Intermittent vitals monitoring presents an incomplete picture of the patient's health status.
A continuous monitoring system would not only improve the system's efficacy\cite{gronbaek_continuous_2023, shaik_remote_2023}, but could greatly enhance the sampling
frequency and obviate the need for manual patient interaction for taking measurements.

Given more development time, a range of auxiliary features could be integrated into Medwings.
Native mobile notifications, more detailed vitals analysis, and utilization of additional functionalities available in Withings devices
would elevate the system's overall capabilities and usefulness.
As technology advances, future work could explore machine learning models to predict potential health anomalies based on historical data.

\newpage
\subsection{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}

Overall, the study has successfully identified key operational successes and challenges, which can be instrumental for future development and refinement of the system.

The Medwings system successfully demonstrated the feasibility of remote patient monitoring using consumer-grade smart devices.
While limitations such as synchronization failures and user compliance exist, the system holds promise for continuous, non-intrusive health monitoring, particularly in a home setting.
Further research and development are required to address its current limitations and expand its capabilities.

% Usability for potential medical staff, if applicable
% Not perfect, but people can get sent home earlier

\newpage
% TODO adjust: carry on from TOC
\pagenumbering{Roman}
\setcounter{page}{4}
\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
\listofalgorithms
\addcontentsline{toc}{section}{List of algorithms}

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