docs(thesis): add conclusion and fix some things
This commit is contained in:
parent
2131447870
commit
a0584b008b
@ -25,7 +25,7 @@
|
||||
type=\acronymtype,
|
||||
name={UI},
|
||||
description={User Interface},
|
||||
first={User Interface (GUI)}
|
||||
first={User Interface (UI)}
|
||||
}
|
||||
\newglossaryentry{iot}{
|
||||
type=\acronymtype,
|
||||
@ -138,17 +138,17 @@
|
||||
which may increase access to care and decrease healthcare delivery costs.
|
||||
}
|
||||
}
|
||||
\newglossaryentry{rwm}{
|
||||
\newglossaryentry{rwsm}{
|
||||
type=\acronymtype,
|
||||
name={RWM},
|
||||
name={RWSM},
|
||||
description={\Gls{rwm_full}},
|
||||
first={\Gls{rwm_full} (RWM)}
|
||||
first={\Gls{rwm_full} (RWSM)}
|
||||
}
|
||||
\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.
|
||||
It enables real-time assessment of patient deterioration risk based on data gathered remotely.
|
||||
}
|
||||
}
|
||||
\newglossaryentry{api}{
|
||||
|
||||
@ -26,8 +26,8 @@
|
||||
\usepackage{pdfpages} % PDFs in appendix
|
||||
\usepackage[toc,nopostdot,nonumberlist,style=altlist,acronym]{glossaries}
|
||||
|
||||
\usepackage{algorithm}
|
||||
\usepackage{algpseudocode}
|
||||
%\usepackage{algorithm}
|
||||
\usepackage[vlined]{algorithm2e}
|
||||
\usepackage{subcaption} % allows multiple figures to share a caption
|
||||
|
||||
% Page margins
|
||||
@ -89,10 +89,21 @@
|
||||
% 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 \\}}
|
||||
|
||||
% Link colors
|
||||
\definecolor{linkColor}{RGB}{0,42,112}
|
||||
\definecolor{citeColor}{RGB}{0,112,47}
|
||||
\hypersetup{
|
||||
colorlinks=true, % true: colored links, false: boxed links
|
||||
linkcolor=linkColor, % color of internal links (change box color with linkbordercolor)
|
||||
citecolor=citeColor, % color of links to bibliography
|
||||
filecolor=magenta, % color of file links
|
||||
urlcolor=cyan, % color of external URLs
|
||||
linktocpage=true % make page numbers, not text, be link on TOC, LOF and LOT
|
||||
}
|
||||
|
||||
|
||||
\input{./glossary.tex}
|
||||
|
||||
@ -106,9 +117,18 @@
|
||||
\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.
|
||||
This research investigated the feasibility of Remote Warning Score Monitoring (RWSM)
|
||||
for outpatients using commercially available smart medical devices.
|
||||
A system, named Medwings, was designed, implemented, and evaluated.
|
||||
A usability study was carried out and found that consumer-grade smart devices can be used to facilitate remote patient monitoring
|
||||
integrated with Early Warning Scores (EWS).
|
||||
While the system was largely successful in demonstrating the practicability of RWSM, it also identified
|
||||
several operational challenges.
|
||||
The Medwings system shows potential for improving patient quality of life and optimizing healthcare resources.
|
||||
Despite its current limitations, Medwings opens the door for future research and development,
|
||||
given the fast-evolving market for advanced smart medical devices.
|
||||
The study fills a critical knowledge gap and sets the stage for further advancements in the field of remote patient
|
||||
monitoring with early warning scores.
|
||||
|
||||
\newpage
|
||||
\renewcommand*\contentsname{Table of contents}
|
||||
@ -119,8 +139,6 @@ A summary must be written in both English and German.
|
||||
\pagenumbering{arabic}
|
||||
\section{Introduction}
|
||||
|
||||
\todo{brief description of the project}
|
||||
|
||||
\subsection{Background}
|
||||
|
||||
Clinical \gls{deterioration} is a critical concern in healthcare, particularly for vulnerable populations such as the elderly and chronically
|
||||
@ -128,14 +146,14 @@ ill patients. It refers to a decline in a patient's health status and may lead t
|
||||
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}
|
||||
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.
|
||||
For \Gls{mews}, each measured physiological parameter is assigned an individual score based on which range it lies 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}.
|
||||
@ -170,14 +188,14 @@ A MEWS value of 5 or above indicates an elevated risk of death, and likelihood o
|
||||
\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.
|
||||
Traditionally, doctors and nursing staff perform collection and evaluation of the data manually, often inputting data into \Gls{ews}-calculators 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,
|
||||
With hospitals facing overwhelming patient load during the SARS-CoV-2 pandemic, interest in exploring \Gls{rpm} surged to new 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.
|
||||
|
||||
@ -192,7 +210,7 @@ in this rapidly evolving field.
|
||||
\subsubsection{Search strategy}
|
||||
|
||||
A systematic search strategy was implemented on the Scopus database, aimed to encompass a broad spectrum of literature relevant
|
||||
to the use of smart medical devices for automated early warning score monitoring of patients dismissed from ambulant or hospital care.
|
||||
to the use of smart medical devices for automated early warning score monitoring of outpatients.
|
||||
The search focused on topics related to the research area, encompassing the examination of \Gls{ews}, hospital admission, care escalation,
|
||||
and medical emergencies in combination with IT automation, medical wearables and \Gls{iot}.
|
||||
The Scopus database was chosen for its extensive coverage of scholarly literature across multiple disciplines.
|
||||
@ -203,8 +221,8 @@ Inclusion criteria:
|
||||
|
||||
\begin{itemize}
|
||||
\item Articles focusing on the utilization of medical wearable devices for remote patient monitoring
|
||||
\item Articles addressing the automated calculation of early warning scores
|
||||
\item Articles discussing the application of early warning scores outside of medical care facilities
|
||||
\item \textit{OR} articles addressing the automated calculation of early warning scores
|
||||
\item \textit{OR} articles discussing the application of early warning scores outside of medical care facilities
|
||||
\end{itemize}
|
||||
|
||||
Exclusion criteria:
|
||||
@ -213,14 +231,14 @@ Exclusion criteria:
|
||||
\item Non-English language articles
|
||||
\item Publications for which full-text access was not available
|
||||
\item Duplicate articles
|
||||
\item Articles outside of the \enquote{Computer Science} subject area
|
||||
\item Articles unrelated to the \enquote{Medicine}, \enquote{Medical Informatics} or \enquote{Computer Science} subject areas
|
||||
\end{itemize}
|
||||
|
||||
The following Scopus query was used to identify relevant literature:
|
||||
|
||||
\begin{tcolorbox}[enhanced, center, width=0.95\linewidth, rounded corners=all, colframe=black!75!white, boxrule=0.5pt, colback=black!5!white]
|
||||
\begin{lstlisting}[language=SQL]
|
||||
TITLE-ABS-KEY(("patient" OR "clinical" OR "medical") AND ("deterioration" OR "instability" OR "decompensation" OR "admission" OR "hospitalization" OR "escalation" OR "triage" OR "emergency")) OR ("early warning" OR "early warning score" OR "warning" OR "score*" OR "EWS") AND TITLE-ABS-KEY("system" OR "automat*" OR "smart*" OR "wearable*" OR "internet of thing*" OR "iot" OR "digital" OR "sensor*" OR "signal" OR "intelligen*" OR "predict*" OR "monitor*" OR "sreen*" OR "remote" OR "it" OR "comput*" OR "mobile" OR "5G" OR "network" (("vital*" OR "bio*") AND ("marker*" OR "sign*" OR "monitor*"))) AND TITLE-ABS-KEY("home" OR "domestic" OR "community" OR "remote" OR "longterm" OR "nursing" OR "rehabilitation" OR "outof*hospital" OR "telemedicine" OR "ehealth" OR "mhealth")
|
||||
TITLE-ABS-KEY(("patient" OR "clinical" OR "medical") AND ("deterioration" OR "instability" OR "decompensation" OR "admission" OR "hospitalization" OR "escalation" OR "triage" OR "emergency")) OR ("early warning" OR "early warning score" OR "warning" OR "score*" OR "EWS") AND TITLE-ABS-KEY("system" OR "automat*" OR "smart*" OR "wearable*" OR "internet of thing*" OR "iot" OR "digital" OR "sensor*" OR "signal" OR "intelligen*" OR "predict*" OR "monitor*" OR "sreen*" OR "remote" OR "it" OR "comput*" OR "mobile" OR "5G" OR "network" (("vital*" OR "bio*") AND ("marker*" OR "sign*" OR "monitor*"))) AND TITLE-ABS-KEY("home" OR "domestic" OR "community" OR "remote" OR "longterm" OR "nursing" OR "rehabilitation" OR "out*of*hospital" OR "telemedicine" OR "ehealth" OR "mhealth")
|
||||
\end{lstlisting}
|
||||
\end{tcolorbox}
|
||||
|
||||
@ -240,8 +258,8 @@ eligibility in full text.
|
||||
Finally, after a thorough evaluation, $N=45$ articles were included for the literature review, providing insight into the current state of
|
||||
research on the use of smart medical devices for automated early warning score monitoring in patients transitioning from ambulant or
|
||||
hospital care.
|
||||
Figure \ref{prisma-flowchart} shows the literature assessment process.
|
||||
The list of reviewed literature is shown in Tables \ref{tab:inclusion-table-1}, \ref{tab:inclusion-table-2} and \ref{tab:inclusion-table-3}.
|
||||
Figure \ref{prisma-flowchart} shows the screening process.
|
||||
The complete list of reviewed literature is shown in Tables \ref{tab:inclusion-table-1}, \ref{tab:inclusion-table-2} and \ref{tab:inclusion-table-3}.
|
||||
|
||||
\begin{table}[!ht]
|
||||
\centering
|
||||
@ -468,14 +486,12 @@ The list of reviewed literature is shown in Tables \ref{tab:inclusion-table-1},
|
||||
\caption{\label{tab:inclusion-table-3}List of reviewed articles \textit{(Part 3 of 3)}}
|
||||
\end{table}
|
||||
|
||||
% TODO for all outcomes, present and compare the findings of each study
|
||||
|
||||
\subsubsection{Discussion}
|
||||
|
||||
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.
|
||||
Furthermore, it was observed that previous research on the use of \Gls{iot}-devices for this purpose was largely conducted in
|
||||
experimental settings, limiting the generalizability of the results.
|
||||
laboratory settings, limiting the generalizability of the results.
|
||||
Some studies have examined monitoring vital signs of at-home-patients for abnormalities,
|
||||
however in most of them, no automated 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
|
||||
@ -488,7 +504,7 @@ However, the methodology they used to calculate the \Gls{ews} in real-time with
|
||||
Recent studies indicate a growing trend towards investigating automated \Gls{ews} calculations in real-world scenarios\cite{downey_strengths_2017, karvounis_hospital_2021, b_v_review_2022, dagan_use_2020}.
|
||||
Notably, 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}.
|
||||
This surge in accessibility has paved the way for more extensive and continuous monitoring of patients in non-medical care settings.
|
||||
This surge in accessibility has paved the way for more extensive remote monitoring of outpatients.
|
||||
Moreover, there is a growing interest in incorporating machine learning algorithms to enhance the predictive capabilities of
|
||||
deterioration detection\cite{un_observational_2021, da_silva_deepsigns_2021, de_mello_dantas_data_2020}.
|
||||
This demonstrates the evolving landscape of remote patient monitoring, aiming to improve clinical outcomes and alleviate the
|
||||
@ -504,13 +520,13 @@ of an \Gls{ews} specialized for use outside of medical care facilities.
|
||||
Based on the findings, several key implications can be drawn.
|
||||
Firstly, the improved availability of smart sensors and the demonstrated effectiveness of \Glspl{ews} in predicting deterioration in direct
|
||||
medical care settings warrant research into their utilization at home.
|
||||
By remotely monitoring patients, it may be possible to identify early signs of deterioration, enabling earlier dismissal from
|
||||
By remotely monitoring patients, it may be possible to identify early signs of deterioration, allowing for 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.
|
||||
Additionally, this approach holds the potential to reduce the frequency of adverse clinical outcomes, as well as mortality rates.
|
||||
|
||||
However, it is important to acknowledge the lack of research on the use of \Glspl{ews} at home, which calls for a feasibility study in this
|
||||
specific context.
|
||||
This study would need to address challenges such as the frequency of measurements required and the absence of immediate diagnosis
|
||||
Such a study would need to address challenges such as the frequency of measurements required and the absence of immediate diagnosis
|
||||
from qualified medical staff.
|
||||
Overcoming these obstacles is essential to ensure the safety and efficacy of automated remote patient monitoring in home-based settings.
|
||||
|
||||
@ -523,7 +539,6 @@ non-medical care settings.
|
||||
|
||||
\subsection{Motivation}
|
||||
|
||||
% TODO EWS makes prediction value better than monitoring abnormalities in single vital signs
|
||||
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
|
||||
@ -534,42 +549,49 @@ biometric sensors into one device, allowing for a much higher degree of patient
|
||||
scalability\cite{un_observational_2021}.
|
||||
Therefore, utilizing such devices for \Gls{rpm} is a suitable approach.
|
||||
|
||||
In summary, with the current availability of wearable, networked biosensors and the validated effectiveness of EWS in medical facilities,
|
||||
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.
|
||||
|
||||
\subsection{State of the problem}
|
||||
|
||||
% Merge with Motivation?
|
||||
|
||||
% 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.
|
||||
Still, their integration with \Glspl{ews} remains under-explored, especially for outpatients or those outside of 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.
|
||||
|
||||
There is a lack of available software which integrates \Gls{rpm} with \Glspl{ews} while being feasible for everyday use,
|
||||
as well as a general knowledge gap in exploring the usefulness of this approach.
|
||||
|
||||
Existing research on \Gls{rpm} predominantly focuses on the technology's capability for vitals monitoring and often sidelines
|
||||
the integration and automated calculation of \Glspl{ews}.
|
||||
This results in a knowledge gap concerning the effectiveness, feasibility, and design challenges of a system which combines both concepts.
|
||||
Moreover, there is a lack of available software which integrates \Gls{rpm} with \Glspl{ews} aimed at everyday use by patients.
|
||||
|
||||
\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}.
|
||||
The objective of this research is to explore \gls{rwsm}: remote monitoring of patients dismissed from direct medical care using automated \Gls{ews}
|
||||
assessments.
|
||||
|
||||
Specifically, the following questions were asked:
|
||||
Specifically, the following questions are 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?
|
||||
\item Can an \Gls{rwsm} system, feasible for everyday use, be implented using smart medical devices commercially available today?
|
||||
\item What are the technical and operational challenges of implementing such a system?
|
||||
\item Can existing, validated \Glspl{ews} be utilized in \Gls{rwsm}?
|
||||
\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.
|
||||
The research questions stated above were pursued by designing, implementing and deploying an \Gls{rwsm} system
|
||||
which utilizes a clinically validated \Gls{ews}, followed by a feasibility study examining its everyday use,
|
||||
and a subsequent evaluation of the study.
|
||||
|
||||
An outline of the steps taken to carry out this investigation is shown here:
|
||||
A detailed outline of each step taken to carry out this investigation is shown here:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{EWS selection:} identification of an \Gls{ews} which is:
|
||||
@ -586,86 +608,77 @@ An outline of the steps taken to carry out this investigation is shown here:
|
||||
\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:
|
||||
\item \textbf{System design and implementation:} development of a software application facilitating \Gls{rwsm} 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:
|
||||
\item \textbf{Evaluation:} methodical review of the implemented \Gls{rwsm} 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 Analysis of the effectiveness of the system in regularly gathering vitals data and \Gls{ews} samples
|
||||
\item Investigation of failure points when sample retrieval or \Gls{ews} assessments were 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 draw conclusions on the feasibility of \Gls{rwsm} using modern smart medical sensors
|
||||
\item discuss application of the chosen \Gls{ews} for \Gls{rwsm}
|
||||
\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.
|
||||
of \Gls{rwsm} in everyday settings, using current technology.
|
||||
|
||||
\subsection{Structure}
|
||||
%\subsection{Structure}
|
||||
|
||||
\todo{Describe the structure of the work.}
|
||||
% TODO Describe the structure of the work
|
||||
% TODO Describe used notations
|
||||
|
||||
\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}.
|
||||
The initial step in conceptualizing an \Gls{rwsm} system was to choose an appropriate \Gls{ews} to use for patient health evaluation.
|
||||
Three widely used \Glspl{ews} emerged as potential candidates: 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
|
||||
The choice between \Gls{mews} and \Gls{news2} was made by considering the input parameters to each score's calculation:
|
||||
compared to \Gls{mews}, \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.
|
||||
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{rwsm} system.
|
||||
|
||||
To calculate \Gls{mews}, the following vital signs must be captured and processed by the system:
|
||||
To calculate the \Gls{mews}, the following vital parameters must be recorded and processed:
|
||||
\begin{itemize}
|
||||
\item Heart Rate
|
||||
\item Blood Pressure (systolic)
|
||||
\item Body Temperature
|
||||
\item Respiratory Rate
|
||||
\item \Gls{avpu} Score
|
||||
\item \Gls{avpu}
|
||||
\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.
|
||||
To develop an \Gls{rwsm} system capable of gathering these vital signs and making them accessible remotely,
|
||||
wirelessly 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.
|
||||
While considering devices that met the procurement criteria outlined earlier, a large number of products had to be excluded, as they
|
||||
would have constrained patient mobility to the confines of their home or bedside.
|
||||
Several promising devices were identified, but dismissed due to still being in active development and having not yet received
|
||||
clinical approval.
|
||||
|
||||
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}.
|
||||
Among a few options on the final shortlist, Withings emerged as the most feasible choice for several reasons.
|
||||
Notably, they were the only manufacturer who offers a publicly accessible \Gls{api}, allowing for automated retrieval of vitals data.
|
||||
Consequently, three Withings devices were selected for the study.
|
||||
The \textit{Withings Scanwatch}\cite{noauthor_worlds_nodate}, shown in Figure~\ref{fig:withings-scanwatch} is a smartwatch capable of
|
||||
measuring a user's \Gls{ecg} and \Gls{spo2} among other things.
|
||||
A \textit{Withings BPM Core}\cite{noauthor_bpm_nodate}, displayed in Figure~\ref{fig:withings-bpm-core}, was also procured.
|
||||
It is a digital blood pressure meter capable of recording blood pressure and heart rate.
|
||||
The third and last device used was a \textit{Withings Thermo}\cite{noauthor_smart_nodate}, a contactless digital thermometer
|
||||
used to measure body temperature. A picture of a Whithings Thermo can be seen in Figure~\ref{fig:withings-thermo}.
|
||||
|
||||
\begin{figure}[!ht]
|
||||
\begin{center}
|
||||
@ -694,12 +707,17 @@ A picture of each device is shown in Figure~\ref{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.
|
||||
All three devices are able synchronize vitals data with the Withings Cloud over the internet, as they connect to the user's phone
|
||||
using a mobile application provided by Withings.
|
||||
|
||||
The chosen selection of devices allows measurements and programmatic access to the vital parameters required to determine a
|
||||
\Gls{mews}, with some caveats: the AVPU score cannot be measured remotely, as it necessitates a clinical assessment from medical
|
||||
staff.
|
||||
Additionally, 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, taken while the user is asleep.
|
||||
|
||||
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.
|
||||
Instead, a custom \textit{respiration score} was introduced, shown in Table~\ref{tab:respiration-score}, which represents any shortness of breath reported by the patient.
|
||||
|
||||
\begin{table}[!ht]
|
||||
\centering
|
||||
@ -722,7 +740,7 @@ To replace the respiration rate in the \Gls{mews} calculation, we took into acco
|
||||
|
||||
\subsection{Requirements}
|
||||
|
||||
Following the selection of an \Gls{ews} and suitable medical sensors, a comprehensive \Gls{rwm} application was conceptualized,
|
||||
Following the selection of an \Gls{ews} and suitable medical sensors, a comprehensive \Gls{rwsm} 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.
|
||||
|
||||
@ -731,23 +749,27 @@ Prior to its development, several key software requirements for the application
|
||||
\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[Portability:] Patients must be able to access Medwings from their mobile phone.
|
||||
Enabling access from other types of end user devices is also desirable.
|
||||
\item[Data Collection:] The application must be capable of collecting and storing vital sign readings from all three
|
||||
Withings smart medical sensors without the need to transfer data manually.
|
||||
Additionally, it must be able to determine the custom respiration score introduced earlier, by prompting patients
|
||||
on whether they are experiencing shortness of breath.
|
||||
\item[Measurement prompts:] To facilitate a regular \Gls{mews} assessment schedule, 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.
|
||||
each of the patient's end devices. Captured data should be stored by the system for later analysis.
|
||||
\item[Data Visualization] Patients should be able to view a history of their recorded vitals and \Gls{mews} values.
|
||||
\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[Usability:] Medwings should be intuitive and user-friendly, requiring minimal technical expertise from end-users.
|
||||
The \Gls{ui} should be adaptive for display on both mobile displays and larger monitors.
|
||||
If measurements fail or errors occur, clear error messages should be displayed to the user.
|
||||
\item[Availability:] The system should be available for patients to use at all times, and from any location, 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}
|
||||
@ -757,10 +779,11 @@ Prior to its development, several key software requirements for the application
|
||||
\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.
|
||||
To ensure the medical validity of a \Gls{mews} assessment, when a set of vitals measurements is used to calculate a \Gls{mews},
|
||||
the time of measurement for any two measurements in the set must not be further apart than ten minutes.
|
||||
\item[Security:] All personal and medical data must be handled in a secure manner, both during storage and in transit.
|
||||
When transmitting data between Medwings and Withings, or between a user's end device and Medwings, communication confidentiality
|
||||
and integrity must be ensured. The identity of both communication partners must be cryptographically verifiable.
|
||||
\end{description}
|
||||
|
||||
\subsection{Design and Implementation}
|
||||
@ -770,18 +793,20 @@ Opting for this format offers several advantages: the primary benefit is its inh
|
||||
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.
|
||||
This architecture was found to be benificial for simplifying data synchronization, facilitating secure authentication,
|
||||
and ensuring 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.
|
||||
Some of the primary motivations for selecting Django were 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 more unique functionalities
|
||||
of the Medwings web application.
|
||||
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.
|
||||
While web applications offer many advantages, one limitation is their increased design complexity required to support push
|
||||
notifications directly on the patient's mobile phone.
|
||||
To simplify this aspect of the design, a separate push notification microservice was deployed on premise and integrated with Medwings.
|
||||
Considering the time constraints under which the application was developed, this approach proved to be an effective compromise.
|
||||
|
||||
\subsubsection{Architecture}
|
||||
|
||||
@ -797,14 +822,14 @@ The overall system environment is shown in Figure~\ref{fig:components-macro}, de
|
||||
\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.
|
||||
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 Withings device.
|
||||
\item When a measurement is completed, 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.
|
||||
Throughout the day, measurement prompt notifications are dispatched to the patient at regular intervals.
|
||||
|
||||
\subsubsection{Modules}\label{sec:modules}
|
||||
|
||||
@ -822,14 +847,17 @@ Each module defines classes representing backend logic, database schemas and use
|
||||
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.
|
||||
It encompasses configuration settings, handling of secrets such as private encryption keys or API tokens, and functionalities
|
||||
shared across multiple other modules.
|
||||
This includes backend utility functions and shared \Gls{ui} components for the frontend.
|
||||
|
||||
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.
|
||||
Responsibilities include 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}
|
||||
% TODO explain this in more detail. It is unclear what is happening here.
|
||||
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.
|
||||
@ -842,7 +870,7 @@ The registration occurs in three stages:
|
||||
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.
|
||||
Figure \ref{fig:ui-register-finalize} shows this final 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.
|
||||
@ -883,42 +911,67 @@ The patient can now log in to the Medwings website and begin using the system to
|
||||
|
||||
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}.
|
||||
% TODO add some more text here
|
||||
|
||||
\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}
|
||||
\begin{centering}
|
||||
\begin{tcolorbox}[
|
||||
enhanced, width=0.9\linewidth, boxrule=1pt, arc=4pt,
|
||||
]
|
||||
\begin{algorithm}[H]
|
||||
\KwIn{$blood\_pressure\_systolic$, $body\_temperature$, $heart\_rate$, $spo2$, $respiration\_score$}
|
||||
\KwOut{$mews$}
|
||||
\DontPrintSemicolon
|
||||
\BlankLine
|
||||
|
||||
$mews \leftarrow 0$ \;
|
||||
\BlankLine
|
||||
|
||||
\If{$blood\_pressure\_systolic \leq 70$}{
|
||||
$mews \leftarrow mews + 3$ \;
|
||||
}\ElseIf{$blood\_pressure\_systolic \leq 80$}{
|
||||
$mews \leftarrow mews + 2$ \;
|
||||
}
|
||||
\ldots \;
|
||||
\tcp*[l]{systolic blood pressure, body temperature}
|
||||
\tcp*[l]{and heart rate as per Table~\ref{tab:mews-calculation}}
|
||||
\BlankLine
|
||||
\BlankLine
|
||||
\BlankLine
|
||||
|
||||
\If{$respiration\_score = 1$}{
|
||||
$mews \leftarrow mews + 1$ \;
|
||||
}\ElseIf{$respiration\_score = 2$}{
|
||||
$mews \leftarrow mews + 2$ \;
|
||||
}
|
||||
\BlankLine
|
||||
|
||||
\If{$spo2 \leq 90$}{
|
||||
$mews \leftarrow mews + 2$ \;
|
||||
}\ElseIf{$spo2 < 95$}{
|
||||
$mews \leftarrow mews + 1$ \;
|
||||
}
|
||||
\BlankLine
|
||||
|
||||
\Return $mews$
|
||||
\BlankLine
|
||||
\BlankLine
|
||||
\BlankLine
|
||||
|
||||
\caption{\label{algo:mews}Medwings \Gls{mews} calculation}
|
||||
\end{algorithm}
|
||||
\end{tcolorbox}
|
||||
\end{centering}
|
||||
|
||||
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.
|
||||
The server exposes its own \Gls{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.
|
||||
Figure \ref{fig:ui-screenshots} provides some impressions of what a user sees when using the application.
|
||||
|
||||
\begin{figure}[!ht]
|
||||
\begin{center}
|
||||
@ -968,7 +1021,7 @@ Animations are sparingly used to visually indicate in-progress system states, su
|
||||
|
||||
\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.
|
||||
A relational database was 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}.
|
||||
|
||||
@ -1019,26 +1072,26 @@ 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:
|
||||
The transmission delays are mentioned 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.
|
||||
However, in some cases, the measurements taken on a device do not get pushed to the Withings Cloud until much later.
|
||||
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.
|
||||
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 the \Gls{mews}.
|
||||
If a set of vitals measurements is, across all records in the set, spaced further apart than ten minutes, no \Gls{mews} record
|
||||
is calculated, and the user is shown an error message.
|
||||
|
||||
|
||||
\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.
|
||||
Each day, five notifications were dispatched.
|
||||
Starting at 10 AM, one notification was sent every three hours.
|
||||
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:
|
||||
Following a notification, the measurements were carried out in the following order:
|
||||
|
||||
\begin{enumerate}
|
||||
\item The subject responds to a Medwings prompt to assess their respiration score.
|
||||
@ -1048,7 +1101,7 @@ Following a notification, the measurement process was carried out in the followi
|
||||
\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
|
||||
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.
|
||||
@ -1304,7 +1357,7 @@ 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.
|
||||
Additionally, expanding the range of monitored vitals could allow implementation of more comprehensive \Gls{rwsm} 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.
|
||||
@ -1322,20 +1375,33 @@ As technology advances, future work could explore machine learning models to pre
|
||||
|
||||
\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 objective of this research was to explore the feasibility and of an \gls{rwsm} system for use by outpatients, using
|
||||
commercially available smart medical devices.
|
||||
The Medwings system was successful in demonstrating the feasibility of such an approach.
|
||||
Key operational challenges and successes were identified, providing insights for the future development
|
||||
and refinement of systems in this domain.
|
||||
|
||||
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.
|
||||
The research found that \gls{rwsm} is feasible.
|
||||
While the \Gls{mews} could not be directly applied in its unaltered form,
|
||||
the use of consumer-grade smart devices in the Medwings system
|
||||
successfully facilitated remote patient monitoring in combination with \Gls{ews} assessments.
|
||||
|
||||
% Usability for potential medical staff, if applicable
|
||||
% Not perfect, but people can get sent home earlier
|
||||
Given the rapidly evolving market for advanced smart medical devices, the implications for healthcare providers are significant.
|
||||
Potentially freeing up medical resources and improving patient mobility and autonomy by allowing for earlier dismissal of patients
|
||||
from care facilities, systems such as Medwings may hold considerable value.
|
||||
|
||||
While the Medwings system has demonstrated the feasibility of \gls{rwsm},
|
||||
it remains somewhat rough around the edges.
|
||||
Continued research in this area is essential to enhance the robustness and effectiveness of \Gls{rwsm} systems.
|
||||
The potential for life-saving interventions via automated alerts makes the case for a more robust system compelling.
|
||||
Although the current system uses a web-based client-server architecture, alternative approaches should be explored.
|
||||
Research into the development of a local, body-area-network system could offer improved reliability and responsiveness.
|
||||
|
||||
In conclusion, the research has successfully filled an important knowledge gap in the field of remote patient monitoring
|
||||
with early warning scores, and outlines the scope for future advancements.
|
||||
Given the continuing technological advancements in smart medical devices, the future appears promising for the adoption and refinement
|
||||
of systems like Medwings for better patient care and resource optimization in healthcare.
|
||||
|
||||
\newpage
|
||||
% TODO adjust: carry on from TOC
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user