jlobbes/ba-thesis
jlobbes/ba-thesis
1
0
Fork 0
Code Issues Pull Requests Releases Activity

docs(thesis): add lots of text

Browse Source
This commit is contained in:
Julian Lobbes 2023-08-30 03:15:58 +02:00 committed by Julian Lobbes
parent fd62042c20
commit 2ff225d621
4 changed files with 752 additions and 126 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -21,6 +21,7 @@
**/*.bcf
**/*.blg
**/*.gz
**/*.loa
**/*.log
**/*.lof
**/*.lot

56
docs/bibliography/bibliography.bib
View File

@ -1236,3 +1236,59 @@ The result of a one-time measureme...},
urldate = {2023-08-22},
file = {Guides documents | Withings:/home/ulinja/Zotero/storage/IJU54NKT/guides.html:text/html},
}
@article{gardner-thorpe_value_2006,
title = {The Value of Modified Early Warning Score ({MEWS}) in Surgical In-Patients: A Prospective Observational Study},
volume = {88},
issn = {0035-8843},
url = {https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1963767/},
doi = {10.1308/003588406X130615},
shorttitle = {The Value of Modified Early Warning Score ({MEWS}) in Surgical In-Patients},
abstract = {{INTRODUCTION}
The Modified Early Warning Score ({MEWS}) is a simple, physiological score that may allow improvement in the quality and safety of management provided to surgical ward patients. The primary purpose is to prevent delay in intervention or transfer of critically ill patients.
{PATIENTS} {AND} {METHODS}
A total of 334 consecutive ward patients were prospectively studied. {MEWS} were recorded on all patients and the primary end-point was transfer to {ITU} or {HDU}.
{RESULTS}
Fifty-seven (17\%) ward patients triggered the call-out algorithm by scoring four or more on {MEWS}. Emergency patients were more likely to trigger the system than elective patients. Sixteen (5\% of the total) patients were admitted to the {ITU} or {HDU}. {MEWS} with a threshold of four or more was 75\% sensitive and 83\% specific for patients who required transfer to {ITU} or {HDU}.
{CONCLUSIONS}
The {MEWS} in association with a call-out algorithm is a useful and appropriate risk-management tool that should be implemented for all surgical in-patients.},
pages = {571--575},
number = {6},
journaltitle = {Annals of The Royal College of Surgeons of England},
shortjournal = {Ann R Coll Surg Engl},
author = {Gardner-Thorpe, J and Love, N and Wrightson, J and Walsh, S and Keeling, N},
urldate = {2023-08-27},
date = {2006-10},
pmid = {17059720},
pmcid = {PMC1963767},
file = {PubMed Central Full Text PDF:/home/ulinja/Zotero/storage/BTN53CJA/Gardner-Thorpe et al. - 2006 - The Value of Modified Early Warning Score (MEWS) i.pdf:application/pdf},
}
@online{noauthor_smart_nodate,
title = {Smart Temporal Thermometer - Thermo {\textbar} Withings},
url = {https://www.withings.com/de/en/thermo},
abstract = {Award-winning smart thermometer requires no contact, provides highly-accurate temperatures, and automatically syncs with a dedicated app to track up to 8 users.},
urldate = {2023-08-27},
langid = {english},
file = {Snapshot:/home/ulinja/Zotero/storage/ZDQ99SFX/thermo.html:text/html},
}
@article{monaghan_detecting_2005,
title = {Detecting and managing deterioration in children: Alan Monaghan describes how the introduction of a critical care outreach service and a Paediatric Early Warning Score improved management of acutely ill children},
volume = {17},
issn = {0962-9513},
url = {http://rcnpublishing.com/doi/abs/10.7748/paed2005.02.17.1.32.c964},
doi = {10.7748/paed2005.02.17.1.32.c964},
shorttitle = {Detecting and managing deterioration in children},
pages = {32--35},
number = {1},
journaltitle = {Paediatric Care},
shortjournal = {Paediatric Care},
author = {Monaghan, Alan},
urldate = {2023-08-27},
date = {2005-02},
langid = {english},
}

206
docs/thesis/glossary.tex
View File

@ -1,63 +1,199 @@
\makenoidxglossaries
\newglossaryentry{dbms}{
type=\acronymtype,
name={DBMS},
description={Database Management System},
first={\Gls{dbms_full} (DBMS)}
name={DBMS},
description={Database Management System},
first={\Gls{dbms_full} (DBMS)}
}
\newglossaryentry{dbms_full}{
name={Database Management System},
description={
A Database Management System is a software system which enables the creation, organization, and management of databases.
It generally acts as an interface between the database and client applications, ensuring that data is consistently
stored and readily accessible in a secure and efficient manner, while maintaining data integrity.
They can manage various forms of data, including text, numbers, multimedia, and more.
The DBMS plays a crucial role in maintaining the integrity, consistency, and security of the data it handles.
}
description={
A Database Management System is a software system which enables the creation, organization, and management of databases.
It generally acts as an interface between the database and client applications, ensuring that data is consistently
stored and readily accessible in a secure and efficient manner, while maintaining data integrity.
They can manage various forms of data, including text, numbers, multimedia, and more.
The DBMS plays a crucial role in maintaining the integrity, consistency, and security of the data it handles.
}
}
\newglossaryentry{gui}{
type=\acronymtype,
name={GUI},
description={Graphical User Interface},
first={Graphical User Interface (GUI)}
name={GUI},
description={Graphical User Interface},
first={Graphical User Interface (GUI)}
}
\newglossaryentry{spo2}{
type=\acronymtype,
name={SPO\textsubscript{2}},
description={\Gls{spo2_full}},
first={\Gls{spo2_full} (SPO\textsubscript{2})}
name={SPO\textsubscript{2}},
description={\Gls{spo2_full}},
first={\Gls{spo2_full} (SPO\textsubscript{2})}
}
\newglossaryentry{spo2_full}{
name={Blood Oxygen Saturation},
description={
A percentage measure indicating the level of oxygen saturation in the blood.
The blood oxygen saturation represents the proportion of hemoglobin molecules in the bloodstream that are saturated with oxygen\cite{hafen_oxygen_2023}.
}
description={
A percentage measure indicating the level of oxygen saturation in the blood.
The blood oxygen saturation represents the proportion of hemoglobin molecules in the bloodstream that are saturated with oxygen\cite{hafen_oxygen_2023}.
}
}
\newglossaryentry{uplink-datarate}{
name={uplink datarate},
description={
The speed at which data is transmitted from a client device, such as a computer or smartphone, to a server or central network.
Typically measured in Mbps (megabits per second), it represents the efficiency of data sending capabilities of a network connection.
}
description={
The speed at which data is transmitted from a client device, such as a computer or smartphone, to a server or central network.
Typically measured in Mbps (megabits per second), it represents the efficiency of data sending capabilities of a network connection.
}
}
\newglossaryentry{downlink-datarate}{
name={downlink datarate},
description={
The rate at which data is received by a client device from a central server or network.
Expressed often in Mbps, it reflects the downloading or data reception efficiency of a network connection.
}
description={
The rate at which data is received by a client device from a central server or network.
Expressed often in Mbps, it reflects the downloading or data reception efficiency of a network connection.
}
}
\newglossaryentry{rtt}{
type=\acronymtype,
name={RTT},
description={\Gls{rtt_full}},
first={\Gls{rtt_full} (RTT)}
name={RTT},
description={\Gls{rtt_full}},
first={\Gls{rtt_full} (RTT)}
}
\newglossaryentry{rtt_full}{
name={Round trip time},
description={
The time taken for a data packet to travel from a source to a destination and back again.
It provides an indication of the latency or delay inherent in a network connection and is usually measured in milliseconds (ms).
}
description={
The time taken for a data packet to travel from a source to a destination and back again.
It provides an indication of the latency or delay inherent in a network connection and is usually measured in milliseconds (ms).
}
}
\newglossaryentry{icu}{
type=\acronymtype,
name={ICU},
description={intensive care unit},
first={intensive care unit (ICU)},
}
\newglossaryentry{mews}{
type=\acronymtype,
name={MEWS},
plural={MEWSs},
description={\Gls{mews_full}},
first={\Gls{mews_full} (MEWS)},
}
\newglossaryentry{mews_full}{
name={Modified Early Warning Score},
description={
An adaptation of the \Gls{ews_full}, which provides a simplified scoring system based on fewer physiological parameters to predict medical deterioration.
}
}
\newglossaryentry{news2}{
type=\acronymtype,
name={NEWS2},
description={\Gls{news2_full}},
first={\Gls{news2_full} (NEWS2)},
}
\newglossaryentry{news2_full}{
name={National Early Warning Score 2},
description={
The second iteration of a standardized scoring system used in the UK to detect and respond to clinical deterioration in adult patients.
It builds upon and refines the original NEWS score.
}
}
\newglossaryentry{ews}{
type=\acronymtype,
name={EWS},
plural={EWSs},
description={\Gls{ews_full}},
first={\Gls{ews_full} (EWS)}
}
\newglossaryentry{ews_full}{
name={Early Warning Score},
plural={Early Warning Scores},
description={
A clinical tool used to assess the severity and likelihood of patient deterioration by scoring multiple vital signs.
}
}
\newglossaryentry{deterioration}{
name={deterioration},
description={
A decline in a patient's health status marked by worsening of clinical signs and symptoms, often necessitating escalated medical intervention.
}
}
\newglossaryentry{rpm}{
type=\acronymtype,
name={RPM},
description={\Gls{rpm_full}},
first={\Gls{rpm_full} (RPM)}
}
\newglossaryentry{rpm_full}{
name={remote patient monitoring},
description={
A technology to enable monitoring of patients outside of conventional clinical settings, such as in the home or in a remote area,
which may increase access to care and decrease healthcare delivery costs.
}
}
\newglossaryentry{rwm}{
type=\acronymtype,
name={RWM},
description={\Gls{rwm_full}},
first={\Gls{rwm_full} (RWM)}
}
\newglossaryentry{rwm_full}{
name={Remote Warning Score Monitoring},
description={
An approach that integrates \gls{rpm} of mobile patients with the automated calculation of an \gls{ews}.
It enables real-time assessment of patient risk based on data gathered remotely, offering proactive care interventions.
}
}
\newglossaryentry{api}{
type=\acronymtype,
name={API},
description={\Gls{api_full}},
first={\Gls{api_full} (API)}
}
\newglossaryentry{api_full}{
name={Application Programming Interface},
description={
A set of rules and protocols that allow different software entities to communicate with each other.
It defines the methods and data formats that applications can use to request and exchange information.
APIs are utilized to enable the integration between different systems and devices, streamlining their functionalities and expanding capabilities.
}
}
\newglossaryentry{pews}{
type=\acronymtype,
name={PEWS},
description={\Gls{pews_full}},
first={\Gls{pews_full} (PEWS)}
}
\newglossaryentry{pews_full}{
name={Pediatric Early Warning Score},
description={
An early warning score used to identify early signs of \gls{deterioration} in pediatric patients.
}
}
\newglossaryentry{avpu}{
type=\acronymtype,
name={AVPU},
description={\Gls{avpu_full}},
first={\Gls{avpu_full} (AVPU)}
}
\newglossaryentry{avpu_full}{
name={AVPU Score},
description={
A rapid assessment method to determine a patient's level of consciousness.
The AVPU scale is used to quickly identify potential neurological impairment or altered mental status in emergency settings.
The four possible findings are:
\begin{itemize}
\item \textbf{Alert}: Patient is fully alert and oriented.
\item \textbf{Voice}: Patient responds to verbal stimuli but is not fully alert.
\item \textbf{Pain}: Patient responds only to painful stimuli.
\item \textbf{Unresponsive}: Patient does not respond to any external stimuli.
\end{itemize}
}
}
\newglossaryentry{ecg}{
type=\acronymtype,
name={ECG},
description={\Gls{ecg_full}},
first={\Gls{ecg_full} (ECG)}
}
\newglossaryentry{ecg_full}{
name={Electrocardiogram},
description={
A medical test that measures the electrical activity of the heartbeat to diagnose various heart conditions.
}
}

615
docs/thesis/thesis.tex
View File

@ -17,6 +17,7 @@
\usepackage{booktabs} % thick horizontal lines
\usepackage{multirow}
\usepackage{array,tabularx}
\usepackage{colortbl}
\usepackage[bf]{caption} % custom table captions
\usepackage[table]{xcolor}
\usepackage[colorlinks]{hyperref}
@ -25,6 +26,9 @@
\usepackage{pdfpages} % PDFs in appendix
\usepackage[toc,nopostdot,nonumberlist,style=altlist,acronym]{glossaries}
\usepackage{algorithm}
\usepackage{algpseudocode}
% Page margins
\geometry{left=3cm, right=2cm, top=3cm, bottom=2cm}
@ -114,49 +118,325 @@ A summary must be written in both English and German.
\pagenumbering{arabic}
\section{Introduction}
\textbf{Gegenstand und Motivation}
\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{brief description of the project}
\item{impact on the field}
\item{background (what lead to the project?)}
\item{motivation, predicted usefulness to the field}
\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}
\textbf{Problemstellung}
\subsection{Tasks}
State clearly which problems exist.
They should phrased such that the project can solve them.
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.
\textbf{Zielsetzung}
An outline of the steps taken to carry out this investigation is shown here:
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.
\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}
\textbf{Frage- und Aufgabenstellung}
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.
List concrete questions/tasks, derived from the goals.
Completing all tasks should result meeting all goals.
\textbf{Gliederung}
Describe the structure of the work.
\subsection{Structure}
\todo{Describe the structure of the work.}
\newpage
\section{Background}
\section{Medwings}
\todo{write}
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}
\newpage
\section{Architecture and Design}
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.
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
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}
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.
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.
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}
@ -178,9 +458,10 @@ The overall system environment is shown in Figure~\ref{fig:components-macro}, de
\end{enumerate}
Measurement prompt notifications are dispatched to the patient at regular intervals throughout the day.
\subsection{Application Modules}\label{sec:modules}
\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}
@ -188,6 +469,7 @@ To separate the different functional aspects of Medwings according to responsibi
\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.
@ -216,7 +498,32 @@ Following registration, the supplied information and numerous authentication tok
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.
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.
@ -224,7 +531,9 @@ The server exposes its own API, which allows external applications like Medwings
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}
% TODO add section about user interface here.
\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.
@ -242,7 +551,7 @@ Withings API tokens are stored in the \code{RefreshToken} and \code{AccessToken}
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}
\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.
@ -256,7 +565,7 @@ 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}
\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.
@ -289,26 +598,43 @@ error message, prompting them to repeat the measurements.
\newpage
\section{Methodology}
\section{System test and trial}
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.
Over the course of one week, a test subject, impersonating a patient, used the application several times a day.
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.
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 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
\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}
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 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 some measurement failures was anticipated, and manually recorded.
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]
@ -341,33 +667,41 @@ Measurement failures were categorized into eight distinct classes, as listed in
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.
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 which device failed to synchronize its data within the allowed time, a $S_2$, $B_2$ or $T_2$ failure was recorded.
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.
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.
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.
Following $S_2$, $B_2$, $T_2$, $P_1$ and $P_2$ failures, the measurement process was not repeated until the next notification.
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.
\newpage
\section{Data Presentation and Analysis}
\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 consequtive, stemming from a period of 24 hours
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 readings within the ten minute timeout.
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.
@ -378,23 +712,16 @@ Figure~\ref{fig:measurement-stats} visualizes the overall measurement and failur
\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.
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.
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$).
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$).
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}
@ -417,65 +744,167 @@ predominantly cluster around areas of low datarate or high \Gls{rtt}.
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.
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.
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
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 correctly by Medwings.
The complete trial data can be seen in Appendix~\ref{apdx:trial-data}.
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 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}
\section{Evaluation}
% 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.
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.
\newpage
\section{Lessons Learned and Reflections}
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.
\subsection{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?
\item Describe personal experiences in interacting with the system and the medical devices
\end{itemize}
\newpage
\section{Future Work and Improvements}
\subsection{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}
% Maybe a client-side only, native mobile app could be the way to go
Future work could explore the integration of machine learning models to predict potential health anomalies based on historical data, as well as the incorporation of additional vitals or health metrics to make the MEWS calculation more comprehensive.
The system as it stands lacks real-time alerting for emergency situations, relying solely on periodic MEWS calculations.
Incorporating real-time alerts can make the system more robust and useful.
Taking continuous measurements is superior to measuring intermittently\cite{gronbaek_continuous_2023, shaik_remote_2023}.
\newpage
\section{Implications and Conclusions}
\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
\setcounter{page}{3}
\pagenumbering{Roman}
\setcounter{page}{4}
\printnoidxglossary[title=Glossary, toctitle=Glossary]\label{sec:glossary}
\newpage
@ -489,6 +918,10 @@ The complete trial data can be seen in Appendix~\ref{apdx:trial-data}.
\listoftables
\addcontentsline{toc}{section}{List of tables}
\newpage
\listofalgorithms
\addcontentsline{toc}{section}{List of algorithms}
\newpage
\printbibliography
\addcontentsline{toc}{section}{References}