517 lines
27 KiB
TeX
517 lines
27 KiB
TeX
\documentclass[12pt, a4paper]{article}
|
||
|
||
\usepackage[utf8]{inputenc}
|
||
\usepackage[T1]{fontenc}
|
||
\usepackage{DejaVuSerif} % Serif font
|
||
\usepackage{ascii} % Monospace font
|
||
\usepackage{csquotes}
|
||
\usepackage[english]{babel}
|
||
\usepackage{graphicx}
|
||
\usepackage{parskip}
|
||
|
||
\usepackage[onehalfspacing]{setspace}
|
||
\usepackage{geometry}
|
||
\usepackage{titlesec}
|
||
\usepackage{fancyhdr}
|
||
|
||
\usepackage{booktabs} % thick horizontal lines
|
||
\usepackage{multirow}
|
||
\usepackage{array,tabularx}
|
||
\usepackage[bf]{caption} % custom table captions
|
||
\usepackage[table]{xcolor}
|
||
\usepackage[colorlinks]{hyperref}
|
||
\usepackage[most]{tcolorbox}
|
||
\pagestyle{plain}
|
||
\usepackage{pdfpages} % PDFs in appendix
|
||
\usepackage[toc,nopostdot,nonumberlist,style=altlist,acronym]{glossaries}
|
||
|
||
% Page margins
|
||
\geometry{left=3cm, right=2cm, top=3cm, bottom=2cm}
|
||
|
||
% Correct footnote size
|
||
% TODO check if this is working correctly
|
||
\renewcommand{\footnotesize}{\fontsize{10pt}{12pt}\selectfont}
|
||
\usepackage[bottom]{footmisc}
|
||
|
||
% Section Headings
|
||
\titleformat*{\section}{\fontsize{16}{19}\selectfont\bfseries}
|
||
\titleformat*{\subsection}{\fontsize{14}{17}\selectfont\bfseries}
|
||
\titleformat*{\subsubsection}{\fontsize{12}{14.4}\selectfont\bfseries}
|
||
|
||
% Page Numbering
|
||
\pagestyle{fancy}
|
||
\fancyhf{}
|
||
\fancyhead[C]{\thepage} % Page number in header center
|
||
\renewcommand{\headrulewidth}{0pt}
|
||
\fancypagestyle{plain}{%
|
||
\fancyhf{} % clear all header and footer fields
|
||
\fancyhead[C]{\thepage}
|
||
}
|
||
\setlength{\headheight}{14.49998pt}
|
||
|
||
% Code listing
|
||
\usepackage{listings}
|
||
\definecolor{bgtinted}{HTML}{efefef}
|
||
\definecolor{codegray}{HTML}{111111}
|
||
\definecolor{codeorange}{HTML}{91632C}
|
||
\definecolor{codegreen}{HTML}{3D5232}
|
||
\definecolor{codepurple}{HTML}{4E3A52}
|
||
\lstdefinestyle{mystyle}{
|
||
backgroundcolor=\color{black!5!white},
|
||
commentstyle=\color{codepurple},
|
||
keywordstyle=\color{codegray},
|
||
stringstyle=\color{codegreen},
|
||
basicstyle=\asciifamily\color{codegray},
|
||
breakatwhitespace=true,
|
||
breaklines=true,
|
||
captionpos=b,
|
||
keepspaces=true,
|
||
showspaces=false,
|
||
showstringspaces=false,
|
||
showtabs=false,
|
||
tabsize=2
|
||
}
|
||
\lstset{style=mystyle}
|
||
|
||
% Inline code snippets
|
||
\newcommand{\code}[1]{\tikz[baseline=(X.base)]\node [draw=gray!50,fill=gray!25,semithick,rectangle,inner sep=2.5pt, rounded corners=3pt] (X) {\asciifamily\color{codegray}{#1}};}
|
||
|
||
% Citations
|
||
%\usepackage{cite}
|
||
\usepackage[backend=biber, style=vancouver]{biblatex}
|
||
\addbibresource{../bibliography/bibliography.bib}
|
||
|
||
% Colors
|
||
\definecolor{PLRI_Rot}{RGB}{190,30,60}
|
||
\definecolor{grau}{RGB}{120,110,100}
|
||
|
||
% A command which generates a TODO message
|
||
\newcommand{\todo}[1]{{\fontfamily{lmtt}\selectfont{\color{orange}\small\underline{TODO:}} \textbf{#1}\normalsize \\}}
|
||
|
||
|
||
\input{./glossary.tex}
|
||
|
||
|
||
\begin{document}
|
||
|
||
|
||
\input{cover.tex}
|
||
|
||
\pagenumbering{Roman}
|
||
\section*{Summary}
|
||
\addcontentsline{toc}{section}{Summary}
|
||
|
||
The summary should be a guideline for creating the work, and briefly name the findings.
|
||
|
||
A summary must be written in both English and German.
|
||
|
||
\newpage
|
||
\renewcommand*\contentsname{Table of contents}
|
||
\tableofcontents
|
||
|
||
\newpage
|
||
\setcounter{page}{1}
|
||
\pagenumbering{arabic}
|
||
\section{Introduction}
|
||
|
||
\textbf{Gegenstand und Motivation}
|
||
|
||
\begin{itemize}
|
||
\item{brief description of the project}
|
||
\item{impact on the field}
|
||
\item{background (what lead to the project?)}
|
||
\item{motivation, predicted usefulness to the field}
|
||
\end{itemize}
|
||
|
||
\textbf{Problemstellung}
|
||
|
||
State clearly which problems exist.
|
||
They should phrased such that the project can solve them.
|
||
|
||
\textbf{Zielsetzung}
|
||
|
||
State clearly the goals of the research work.
|
||
The goals should be derived clearly from the problem statement, and meeting the goals should solve the stated problems.
|
||
|
||
\textbf{Frage- und Aufgabenstellung}
|
||
|
||
List concrete questions/tasks, derived from the goals.
|
||
Completing all tasks should result meeting all goals.
|
||
|
||
\textbf{Gliederung}
|
||
|
||
Describe the structure of the work.
|
||
|
||
|
||
\newpage
|
||
\section{Background}
|
||
|
||
\todo{write}
|
||
|
||
|
||
\newpage
|
||
\section{Architecture and Design}
|
||
|
||
Medwings is designed as a browser-based web application in the classic client-server model, facilitating centralized data storage and evaluation.
|
||
Opting for a web application offers numerous advantages: the primary benefit is its inherent cross-platform compatibility, enabling usage
|
||
on a wide range of devices such as mobile phones and personal computers.
|
||
Secondly, implementing a web application reduces complexity and shortens development time, compared to the creation of a native mobile app coupled
|
||
with a separate, dedicated API server.
|
||
|
||
\begin{figure}[!ht]
|
||
\begin{center}
|
||
\includegraphics[width=.75\textwidth]{./figures/components-macro.png}
|
||
\caption{\label{fig:components-macro}System diagram showing data flow and user interactions between components in the Medwings environment.}
|
||
\end{center}
|
||
\end{figure}
|
||
|
||
The overall system environment is shown in Figure~\ref{fig:components-macro}, depicting the following workflow:
|
||
\begin{enumerate}
|
||
\item A patient receives a notification on their mobile phone, prompting them to take vitals measurements.
|
||
\item Upon opening the notification, they are redirected to the Medwings website.
|
||
Here, they are prompted to self-assess their respiration score by answering a short questionnaire, followed by a prompt to take one measurement
|
||
on each smart medical device.
|
||
\item Upon completion of the measurement, each device transmits the data via Bluetooth to the Withings mobile app, installed on the user's phone.
|
||
The mobile app now sends the data to the Withings Cloud for storage.
|
||
\item A backend process on the Medwings server awaits the arrival of all recorded measurements from the Withings Cloud, storing them upon reception.
|
||
Once all required vitals measurements have been retrieved, the MEWS is calculated, stored and displayed to the patient.
|
||
\end{enumerate}
|
||
Measurement prompt notifications are dispatched to the patient at regular intervals throughout the day.
|
||
|
||
\subsection{Application Modules}\label{sec:modules}
|
||
|
||
To separate the different functional aspects of Medwings according to responsibility, its application code is split into the following five modules:
|
||
\begin{itemize}
|
||
\item \code{core}
|
||
\item \code{withings}
|
||
\item \code{gotify}
|
||
\item \code{authentication}
|
||
\item \code{medwings}
|
||
\end{itemize}
|
||
Each module defines classes representing backend logic, database schemas and user interface elements pertaining to its specific function.
|
||
Implementation details are encapsulated within these classes, while public interfaces are exposed to external program code to provide each module's core functionality.
|
||
|
||
The \code{core} module forms the backbone of the application.
|
||
It encompasses configuration settings, secrets such as private encryption keys or API tokens, and functionalities shared across multiple other modules.
|
||
|
||
Medwings interfaces with the Withings Cloud through the \code{withings} module.
|
||
This includes retrieving vitals data through authenticated requests to the Withings Cloud API, which implements the OAuth 2.0 Authorization Framework.
|
||
As per its specification, \enquote{In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server\ldots~
|
||
Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token\ldots~
|
||
The client uses the access token to access the protected resources hosted by the resource server.
|
||
}\cite{hardt_oauth_2012}
|
||
While this process is largely transparent for the resource owner --- the patient in this case --- the communication between
|
||
Medwings as the resource client and Withings as the resource server is complex, and is therefore abstracted by the module.
|
||
Aside from OAuth 2.0, \code{withings} also encapsulates fetching, parsing, and storing vitals data retrieved from Withings.
|
||
|
||
Medwings implements a standalone user authentication system, which is provided by the \code{authentication} module.
|
||
Patients must register with a username and password to be able to use the application.
|
||
The registration occurs in three stages:
|
||
\begin{enumerate}
|
||
\item The patient grants Medwings the permission to retrieve their health data from Withings in an OAuth2 authorization flow.
|
||
\item A registration form is shown, prompting the user to choose a username and password, and to enter relevant personal information.
|
||
\item The user is shown a confirmation that the account was created successfully, and is asked to download the Gotify app, described below, and log in using their Medwings credentials.
|
||
\end{enumerate}
|
||
Following registration, the supplied information and numerous authentication tokens are saved in the Medwings database.
|
||
Patients can now sign in on the Medwings website.
|
||
|
||
The \code{medwings} module, pivotal to the core functionalty of Medwings, defines the data model used to represent and store the various vital signs handled by the application.
|
||
Furthermore, it provides interfaces to access the data, as well as the algorithm used to calculate the MEWS.
|
||
|
||
In order to send push notifications to mobile devices, Medwings leverages \textit{Gotify} -- a dedicated notification microservice\cite{noauthor_gotify_nodate}.
|
||
Gotify is composed of a web server component, and a mobile app acting as the client software.
|
||
The server exposes its own API, which allows external applications like Medwings to dispatch push notifications programmatically.
|
||
It uses an independent database for client authentication. The \code{gotify} module ensures synchronization between the user databases of Gotify and Medwings.
|
||
In addition, the module provides interfaces to send customized push notifications to specific patients.
|
||
|
||
\subsection{Data Model}
|
||
|
||
A relational database is used to store application data, whereby each Medwings module defines the database schema for the underlying data it is responsible for handling.
|
||
Module interdependencies correlate closely with the foreign key references in the data model.
|
||
A holistic representation of the Medwings data model is shown in Figure~\ref{fig:datamodel}.
|
||
|
||
\begin{figure}[!ht]
|
||
\begin{center}
|
||
\includegraphics[width=\textwidth]{./figures/datamodel.png}
|
||
\caption{\label{fig:datamodel}Entity-Relationship diagram (Crow's Foot notation) showing the data model of the Medwings database.}
|
||
\end{center}
|
||
\end{figure}
|
||
|
||
At its heart lies the \code{User} entity: it forms the nexus to which all vitals data and user information is linked.
|
||
Withings API tokens are stored in the \code{RefreshToken} and \code{AccessToken} entities, while the \code{GotifyUser} and \code{GotifyAccount} entities retain the Gotify API credentials.
|
||
The numerous vital signs, as well as the MEWS record which can potentially be calculated based on them, are also represented.
|
||
The \code{Profile} table stores additional medically relevant patient information as supplied during user registration.
|
||
|
||
\subsection{Deployment}
|
||
|
||
To use the smart devices to take measurements, patient users must first install the Withings mobile app on their phone, and use it to create a Withings user account.
|
||
Following registration, each device must be linked to the app and configured via Bluetooth.
|
||
Some basic configuration is required in order to enable specific device features, such as measurement of \Gls{spo2} on the Scanwatch.
|
||
Users are guided through the process by the app's \Gls{gui}.
|
||
|
||
Being a web application, no installation is necessary to access the Medwings interface, patients simply visit the website in a web browser.
|
||
Patients do need to create a Medwings account on the website however, followed by installation and configuration of the Gotify mobile app, as described in the registration
|
||
process in Section~\ref{sec:modules}.
|
||
|
||
The centralized server components, including the Gotify server, a task scheduler used to schedule sending notifications and the Medwings application code itself are deployed
|
||
on a publicly accessible web server using a Docker container environment.
|
||
|
||
\subsection{Design Challenges}\label{sec:design-challenges}
|
||
|
||
Since managing a user in Medwings requires the respective user's state to be mirrored by two other services, Withings and Gotify, keeping user accounts across
|
||
all three services in sync presents a challenge.
|
||
Particularly during user creation, user accounts must be linked to Withings, created on the Gotify server and finally saved to the Medwings database.
|
||
Various integrity checks, such as when the user aborts the registration process midway, were put in place to prevent diverging user states across the three services
|
||
and overcome this challenge.
|
||
|
||
Similarly, vitals records kept in the Medwings database must be synchronized with all records available on the Withings cloud.
|
||
Regularly recurring, as well as on-demand data synchronization hooks were implemented to keep the Medwings database up to date,
|
||
while database constraints ensure validity of imported data and prevent duplication of existing records.
|
||
|
||
The non-enterprise Withings API enforces a rate limit of 120 requests per minute.
|
||
Medwings polls the API regularly to retrieve the latest health data for patients.
|
||
At scale, with many patient users, the rate limit would quickly be reached.
|
||
The Withing API does provide functionality to notify client applications upon availability of new data, making it possible to avoid polling.
|
||
Given that Medwings was only used by a single patient user during the trial phase, falling back to polling was an acceptable compromise to lower complexity
|
||
while still operating within the rate limit.
|
||
|
||
A MEWS calculation should represent the patient's overall physiological state at -- ideally -- a discrete point in time.
|
||
Naturally, there is a delay from when a measurement is taken with a device until it can be retrieved from the API.
|
||
The percieved transmission delay in the Medwings implementation was generally consistent with what is stated in the Withings public API documentation:
|
||
\enquote{Delays are typically less than two minutes, but it can be longer.}\cite{noauthor_keep_nodate}.
|
||
However, in some cases, the measurements taken on a device do not get pushed to the Withings Cloud until much later, or fail to do so at all.
|
||
While the cause for these longer than normal delays and missing data points is unknown and outside of the control of Medwings, these edge cases
|
||
had to be taken into account.
|
||
Furthermore, the time it takes a patient to take measurements using all three devices must also be accounted for.
|
||
Therefore, Medwings enforces a maximum allowed time difference of ten minutes between measurements of the different vitals records used to calculate MEWS.
|
||
If a set of vitals measurements is, across all records in the set, spaced further apart than ten minutes, no MEWS record is calculated, and the user is shown an
|
||
error message, prompting them to repeat the measurements.
|
||
|
||
|
||
\newpage
|
||
\section{Methodology}
|
||
|
||
Following the development and deployment of the application, Medwings underwent a performance and usability study.
|
||
A test subject, impersonating a patient, used the application daily over the course of one week.
|
||
Each day, five notifications were dispatched every three hours, starting at 10 AM.
|
||
When prompted by a notification, the subject was asked to take vital sign readings using the three Withings medical sensors,
|
||
followed by a MEWS calculation carried out by Medwings.
|
||
|
||
The values of the vitals and MEWS records, as well as the time of measurement, were recorded by the application.
|
||
For each MEWS calculation, the test subject manually kept track of which type of environment the system was used in.
|
||
A distinction was made between the following environments:
|
||
\begin{itemize}
|
||
\item At home: The subject was located at home, and their phone had access to a low latency broadband internet connection
|
||
\item On the go: The subject was away from home, and their phone had access to a high latency mobile internet connection
|
||
\end{itemize}
|
||
Preceeding each MEWS measurement, the maximum data transmission rates, both uplink and downlink, as well as the average connection round trip time
|
||
from the subject's phone to a distant reference server was measured.
|
||
The location of the reference server was kept constant throughout the trial.
|
||
|
||
The occurrence of some measurement failures was anticipated, and manually recorded.
|
||
Measurement failures were categorized into eight distinct classes, as listed in Table~\ref{tab:measurement-failures}.
|
||
|
||
\begin{table}[!ht]
|
||
\centering
|
||
\begin{tcolorbox}[
|
||
enhanced, width=0.95\linewidth, boxrule=2pt, arc=4pt,
|
||
tabularx={>{\centering\arraybackslash}c|>{\centering\arraybackslash}c|>{\arraybackslash}X}
|
||
]
|
||
\textbf{Device} & \textbf{Failure Class} & \textbf{Description} \\
|
||
\specialrule{2pt}{0em}{0em}
|
||
\multirow{2}{*}{Scanwatch} & $S_1$ & Device aborted measurement \\
|
||
\cline{2-3}
|
||
& $S_2$ & Measurement synchronization failure \\
|
||
\hline
|
||
\multirow{2}{*}{BPM Core} & $B_1$ & Device aborted measurement \\
|
||
\cline{2-3}
|
||
& $B_2$ & Measurement synchronization failure \\
|
||
\hline
|
||
\multirow{2}{*}{Thermo} & $T_1$ & Device aborted measurement \\
|
||
\cline{2-3}
|
||
& $T_2$ & Measurement synchronization failure \\
|
||
\hline
|
||
\multirow{2}{*}{---} & $P_1$ & Patient did not take any measurements \\
|
||
\cline{2-3}
|
||
& $P_2$ & MEWS calculation timed out \\
|
||
\end{tcolorbox}
|
||
\caption{\label{tab:measurement-failures}Classification of measurement failures during the usability trial}
|
||
\end{table}
|
||
|
||
The Scanwatch and BPM Core are equipped with accellerometers\cite{noauthor_worlds_nodate, noauthor_bpm_nodate}.
|
||
If erratic movement is detected, the devices abort the measurement to avoid misinterpretation of sensor readings.
|
||
Similarly, upon failure to process captured sensor data into a plausible result, a measurement may be aborted by the device\cite{noauthor_scanwatch_nodate, noauthor_bpm_nodate-1, noauthor_guides_nodate}.
|
||
The measurement failure classes $S_1$, $B_1$ and $T_1$ were used to record these kinds of failure for each respective device.
|
||
Following an $S_1$, $B_1$ or $T_1$ failure, the subject repeatedly carried out measurements unsing the affected device until a valid reading could be obtained.
|
||
Subsequent failures were also recorded.
|
||
|
||
As explained in Section~\ref{sec:design-challenges}, following a successful reading, a device may fail to push the measurement data to the Withings
|
||
Cloud within the ten minute validity range for a MEWS calculation imposed by Medwings.
|
||
Depending on which device failed to synchronize its data within the allowed time, a $S_2$, $B_2$ or $T_2$ failure was recorded.
|
||
|
||
If the subject did not carry out any vitals measurements despite being prompted by a notification, a $P_1$ failure was noted.
|
||
Finally, if the patient failed to carry out all three required measurements within the ten minute time limit, a $P_2$ failure was recorded.
|
||
|
||
Following $S_2$, $B_2$, $T_2$, $P_1$ and $P_2$ failures, the measurement process was not repeated until the next notification.
|
||
|
||
\newpage
|
||
\section{Data Presentation and Analysis}
|
||
|
||
The trial period encompassed seven days, on each of which five notifications were dispatched to the patient.
|
||
Thus, an overall of $N=35$ system interactions were recorded.
|
||
The patient was at home during $26$ of these, and on the go in all other cases.
|
||
|
||
Seven $P_1$ measurement failures occurred, wherein the patient did not react to a received notification by taking measurements.
|
||
Out of these, five occurred while the patient was on the go and, notably, four $P_1$ failures were consequtive, stemming from a period of 24 hours
|
||
during which the patient did not have access to the smart devices.
|
||
No $P_2$ measurement failures occured during the trial.
|
||
|
||
In total, vitals were measured using all three devices in $28$ cases.
|
||
However, in $11$ cases, at least one device failed to synchronize its readings within the ten minute timeout.
|
||
Throughout the trial, $17$ MEWS calculations were recorded successfully.
|
||
Figure~\ref{fig:measurement-stats} visualizes the overall measurement and failure counts.
|
||
|
||
\begin{figure}[!ht]
|
||
\begin{center}
|
||
\includegraphics[width=\textwidth]{./figures/chart-measurement-stats.png}
|
||
\caption{\label{fig:measurement-stats}Measurement and measurement failure statistics at home and on the go.}
|
||
\end{center}
|
||
\end{figure}
|
||
|
||
Out of $84$ successful individual measurements across all devices throughout the trial, $18\%$ took longer than premitted by Medwings to synchronize with the Withings Cloud.
|
||
Particularly while on the go, synchronization was prone to taking too long: $25\%$ of measurements resulted in synchronization failure, compared
|
||
to $11\%$ at home.
|
||
Especially the BPM Core and Thermo devices suffered from slow synchronization times: in a total of $15$ synchronization timeouts, $n_{B_2} = 7$ were caused
|
||
by the blood pressure meter, and $n_{T_2} = 7$ by the thermometer.
|
||
|
||
Three causing factors were identified: firstly, while the Scanwatch is constantly connected to the patient's phone, the BPM Core and Thermo devices only establish
|
||
a connection intermittently.
|
||
Presumably, measurement data updates from the smart device to the phone are sent less frequently.
|
||
|
||
The second factor becomes apparent when examining the likelihood of each device aborting a measurement due to inconclusive sensor data,
|
||
as displayed in Figure~\ref{fig:measurement-repeats}:
|
||
for the BPM Core, $15\%$ of attempted measurements had to be repeated ($n_{B_1} = 5$).
|
||
For the Scanwatch, over $34\%$ of readings ($n_{S_1} = 15$) were inconclusive and had to be repeated.
|
||
The Withings Thermo did not abort any measurements ($n_{T_1} = 0$).
|
||
Although aborted measurements did not cause synchronization failures directly, the time taken to repeat measurements did impact
|
||
the likelihood of the MEWS calculation timing out before all vitals data was synchronized.
|
||
|
||
\begin{figure}[!ht]
|
||
\begin{center}
|
||
\includegraphics[width=0.8\textwidth]{./figures/chart-measurement-repeats.png}
|
||
\caption{\label{fig:measurement-repeats}Number of measurement attempts and aborted measurements for each smart device.}
|
||
\end{center}
|
||
\end{figure}
|
||
|
||
Figure~\ref{fig:connection-boxplot} illustrates the comparative boxplots for the \gls{downlink-datarate}, \gls{uplink-datarate}, and \Gls{rtt} connection metrics when
|
||
the patient was at home versus on the go.
|
||
While there are evident differences in the distributions of these metrics between the two environments, the points representing synchronization failures do not
|
||
predominantly cluster around areas of low datarate or high \Gls{rtt}.
|
||
|
||
\begin{figure}[!ht]
|
||
\begin{center}
|
||
\includegraphics[width=\textwidth]{./figures/chart-connection-boxplot.png}
|
||
\caption{\label{fig:connection-boxplot}Connection quality and synchronization failures.}
|
||
\end{center}
|
||
\end{figure}
|
||
|
||
A reaction delay $t_r$ existed from when a notification was dispatched until the subject visited the Medwings website to take measurements.
|
||
The average ($\overline{t_{r,\text{home}}} = 36\text{ min}$) and median ($M_{t_{r,\text{home}}} = 33\text{ min}$) delay was significantly lower
|
||
while the patient was at home, compared to when they were out of the house ($\overline{t_{r,\text{on the go}}} = 68\text{ min}$, $M_{t_{r,\text{on the go}}} = 70\text{ min}$).
|
||
The average time taken to carry out all three measurements was $4.5$ minutes in both enviroments.
|
||
|
||
In all cases where vitals measurements were taken using the devices, the vitals data was captured and stored by Medwings.
|
||
All MEWS calculations carried out by the application returned the correct value as expected from the vitals data they were based upon.
|
||
The subject's vital signs were within their normal ranges representative of the patient's age for all measurements, with the exception of
|
||
two outliers where a slightly increased heart rate was measured.
|
||
Both outliers were detected correctly by Medwings.
|
||
The complete trial data can be seen in Appendix~\ref{apdx:trial-data}.
|
||
|
||
|
||
\newpage
|
||
\section{Evaluation and Validation}
|
||
% - Personal experiences in interacting with the system and the medical devices
|
||
% - What went well and what didn't? Why?
|
||
% - Usability for potential medical staff, if applicable
|
||
% - Strengths and weaknesses of patients taking their own measurements vs. having a medical professional take them
|
||
% - How well did patients (or you, in this case) adhere to the measurement schedule? What factors influenced this?
|
||
\begin{itemize}
|
||
\item Describe the methods used to evaluate the system
|
||
\item Discuss the validity of the study, especially considering that the test patient was yourself
|
||
Explicitly state the limitations of your study. For example, the fact that you were the test patient, which might introduce bias into the results
|
||
\item Are the results likely to generalize? Why or why not?
|
||
\end{itemize}
|
||
|
||
% The absence of a clear correlation suggests that synchronization failures were not majorly influenced by the fundamental connection quality metrics.
|
||
% The root cause of these failures likely lies elsewhere and is not solely dictated by raw connection performance.
|
||
|
||
|
||
\newpage
|
||
\section{Lessons Learned and Reflections}
|
||
\begin{itemize}
|
||
\item Reflect on the overall development process
|
||
\item What would you do differently if you were to start over?
|
||
\item What did you learn that was unexpected?
|
||
\end{itemize}
|
||
|
||
|
||
\newpage
|
||
\section{Future Work and Improvements}
|
||
\begin{itemize}
|
||
\item What can be improved in the current system?
|
||
\item Are there additional features that could make the system more effective?
|
||
\item Any scalability or security issues that would need to be addressed for a larger-scale deployment?
|
||
\end{itemize}
|
||
|
||
\newpage
|
||
\section{Implications and Conclusions}
|
||
\begin{itemize}
|
||
\item Implications of this research for the wider field of remote patient monitoring
|
||
\item Conclusions drawn from the research
|
||
\item Summary of the contributions of your work
|
||
\end{itemize}
|
||
|
||
|
||
\newpage
|
||
% TODO adjust: carry on from TOC
|
||
\setcounter{page}{3}
|
||
\pagenumbering{Roman}
|
||
\printnoidxglossary[title=Glossary, toctitle=Glossary]\label{sec:glossary}
|
||
|
||
\newpage
|
||
\printnoidxglossary[type=\acronymtype, title=Acronyms, toctitle=Acronyms]\label{sec:acronyms}
|
||
|
||
\newpage
|
||
\listoffigures
|
||
\addcontentsline{toc}{section}{List of figures}
|
||
|
||
\newpage
|
||
\listoftables
|
||
\addcontentsline{toc}{section}{List of tables}
|
||
|
||
\newpage
|
||
\printbibliography
|
||
\addcontentsline{toc}{section}{References}
|
||
|
||
\newpage
|
||
\appendix
|
||
\includepdf[pages=1, scale=0.95, pagecommand={\vspace*{-2.75cm}\section{Trial Data}\label{apdx:trial-data}}, angle=-90]{./attachments/trial-data.pdf}
|
||
\includepdf[pages=2-, scale=0.95, pagecommand={}, angle=-90]{./attachments/trial-data.pdf}
|
||
|
||
\newpage
|
||
\section*{Ehrenwörtliche Erklärung}
|
||
\addcontentsline{toc}{section}{Ehrenwörtliche Erklärung}
|
||
|
||
Ich versichere, dass ich die beiliegende Bachelorarbeit ohne Hilfe Dritter und ohne Benutzung anderer als der angegebenen
|
||
Quellen und Hilfsmittel angefertigt und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
|
||
kenntlich gemacht habe.
|
||
Diese Arbeit hat in gleicher Form noch keiner Prüfungsbehörde vorgelegen.
|
||
|
||
Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
|
||
|
||
|
||
Braunschweig, 12.09.2023
|
||
\vspace{3cm}
|
||
|
||
\end{document}
|