docs(thesis): add UI screenshots and limitations section
BIN
docs/thesis/figures/screenshot-home-page.png
Normal file
After Width: | Height: | Size: 930 KiB |
BIN
docs/thesis/figures/screenshot-recording.png
Normal file
After Width: | Height: | Size: 9.7 MiB |
BIN
docs/thesis/figures/screenshot-register-continue.png
Normal file
After Width: | Height: | Size: 251 KiB |
BIN
docs/thesis/figures/screenshot-register-finalize.png
Normal file
After Width: | Height: | Size: 624 KiB |
BIN
docs/thesis/figures/screenshot-register-init.png
Normal file
After Width: | Height: | Size: 518 KiB |
BIN
docs/thesis/figures/screenshot-register-oauth2.png
Normal file
After Width: | Height: | Size: 176 KiB |
BIN
docs/thesis/figures/screenshot-vitals-measurement.png
Normal file
After Width: | Height: | Size: 9.7 MiB |
@ -21,6 +21,12 @@
|
|||||||
description={Graphical User Interface},
|
description={Graphical User Interface},
|
||||||
first={Graphical User Interface (GUI)}
|
first={Graphical User Interface (GUI)}
|
||||||
}
|
}
|
||||||
|
\newglossaryentry{ui}{
|
||||||
|
type=\acronymtype,
|
||||||
|
name={UI},
|
||||||
|
description={User Interface},
|
||||||
|
first={User Interface (GUI)}
|
||||||
|
}
|
||||||
\newglossaryentry{spo2}{
|
\newglossaryentry{spo2}{
|
||||||
type=\acronymtype,
|
type=\acronymtype,
|
||||||
name={SPO\textsubscript{2}},
|
name={SPO\textsubscript{2}},
|
||||||
|
@ -355,24 +355,24 @@ A picture of each device is shown in Figure~\ref{fig:withings-devices}.
|
|||||||
\begin{subfigure}{.25\textwidth}
|
\begin{subfigure}{.25\textwidth}
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{./figures/withings-scanwatch.png}
|
\includegraphics[width=\linewidth]{./figures/withings-scanwatch.png}
|
||||||
\caption{\footnotesize Scanwatch\cite{noauthor_worlds_nodate}}
|
\caption{\footnotesize Scanwatch}
|
||||||
\label{fig:withings-scanwatch}
|
\label{fig:withings-scanwatch}
|
||||||
\end{subfigure}
|
\end{subfigure}
|
||||||
\hfill
|
\hfill
|
||||||
\begin{subfigure}{.25\textwidth}
|
\begin{subfigure}{.25\textwidth}
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{./figures/withings-bpm-core.png}
|
\includegraphics[width=\linewidth]{./figures/withings-bpm-core.png}
|
||||||
\caption{\footnotesize BPM Core\cite{noauthor_bpm_nodate}}
|
\caption{\footnotesize BPM Core}
|
||||||
\label{fig:withings-bpm-core}
|
\label{fig:withings-bpm-core}
|
||||||
\end{subfigure}
|
\end{subfigure}
|
||||||
\hfill
|
\hfill
|
||||||
\begin{subfigure}{.25\textwidth}
|
\begin{subfigure}{.25\textwidth}
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{./figures/withings-thermo.png}
|
\includegraphics[width=\linewidth]{./figures/withings-thermo.png}
|
||||||
\caption{\footnotesize Thermo\cite{noauthor_smart_nodate}}
|
\caption{\footnotesize Thermo}
|
||||||
\label{fig:withings-thermo}
|
\label{fig:withings-thermo}
|
||||||
\end{subfigure}
|
\end{subfigure}
|
||||||
\caption{Withings smart medical devices}
|
\caption{Withings smart medical devices \textit{(image sources: Withings Scanwatch\cite{noauthor_worlds_nodate}, Withings BPM Core\cite{noauthor_bpm_nodate}, Withings Thermo\cite{noauthor_smart_nodate})}}
|
||||||
\label{fig:withings-devices}
|
\label{fig:withings-devices}
|
||||||
\end{center}
|
\end{center}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
@ -521,12 +521,48 @@ Medwings implements a standalone user authentication system, which is provided b
|
|||||||
Patients must register with a username and password to be able to use the application.
|
Patients must register with a username and password to be able to use the application.
|
||||||
The registration occurs in three stages:
|
The registration occurs in three stages:
|
||||||
\begin{enumerate}
|
\begin{enumerate}
|
||||||
\item The patient grants Medwings the permission to retrieve their health data from Withings in an OAuth2 authorization flow.
|
\item The patient grants Medwings the permission to retrieve their health data from Withings in an OAuth2 authorization flow. This process is shown in
|
||||||
\item A registration form is shown, prompting the user to choose a username and password, and to enter relevant personal information.
|
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.
|
\item The user is shown a confirmation that the account was created successfully, and is asked to download the Gotify app, described below, and log in using their Medwings credentials.
|
||||||
|
Figure \ref{fig:ui-register-finalize} shows the finalization step.
|
||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
Following registration, the supplied information and numerous authentication tokens are saved in the Medwings database.
|
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 patient can now log in to the Medwings website and begin using the system to take vitals and \Gls{mews} measurements.
|
||||||
|
|
||||||
|
\begin{figure}[!ht]
|
||||||
|
\begin{center}
|
||||||
|
\begin{subfigure}{.21\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./figures/screenshot-register-init.png}
|
||||||
|
\caption{User signup initialization}
|
||||||
|
\label{fig:ui-register-init}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{.21\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./figures/screenshot-register-oauth2.png}
|
||||||
|
\caption{Withings OAuth 2.0 grant}
|
||||||
|
\label{fig:ui-register-oauth2}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{.21\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./figures/screenshot-register-continue.png}
|
||||||
|
\caption{User details prompt}
|
||||||
|
\label{fig:ui-register-continue}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{.21\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./figures/screenshot-register-finalize.png}
|
||||||
|
\caption{Registration finalization}
|
||||||
|
\label{fig:ui-register-finalize}
|
||||||
|
\end{subfigure}
|
||||||
|
\caption{Medwings user registration process}
|
||||||
|
\label{fig:ui-registration}
|
||||||
|
\end{center}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
The \code{medwings} module, pivotal to the core functionalty of Medwings, defines the data model used to represent and store the various vital signs handled by the application.
|
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}.
|
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}.
|
||||||
@ -562,7 +598,56 @@ 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.
|
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.
|
In addition, the module provides interfaces to send customized push notifications to specific patients.
|
||||||
|
|
||||||
% TODO add section about user interface here.
|
\subsubsection{User Interface}
|
||||||
|
|
||||||
|
The Medwings \Gls{ui} was developed with specific design goals in mind to ensure an efficient and intuitive user experience.
|
||||||
|
Figure \ref{fig:ui-screenshots} provides some impressions from a user's perspective.
|
||||||
|
|
||||||
|
\begin{figure}[!ht]
|
||||||
|
\begin{center}
|
||||||
|
\begin{subfigure}{.3\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./figures/screenshot-home-page.png}
|
||||||
|
\caption{Medwings home page}
|
||||||
|
\label{fig:ui-screenshot-home-page}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{.3\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./figures/screenshot-vitals-measurement.png}
|
||||||
|
\caption{Starting a measurement}
|
||||||
|
\label{fig:ui-screenshot-mews-init}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{.3\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./figures/screenshot-recording.png}
|
||||||
|
\caption{Waiting for synchronization}
|
||||||
|
\label{fig:ui-screenshot-mews-continue}
|
||||||
|
\end{subfigure}
|
||||||
|
\caption{Medwings \Gls{ui} screenshots}
|
||||||
|
\label{fig:ui-screenshots}
|
||||||
|
\end{center}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
Aiming for a clutter-free and fast user experience, simplicity served as the guiding principle to enhance usability.
|
||||||
|
A focus was put on developing accessibility-friendly \Gls{ui} components, ensuring that the system is usable by visually impaired individuals.
|
||||||
|
|
||||||
|
Security was a top priority in the frontend implementation to protect users and the system from common vulnerabilities.
|
||||||
|
Overall, the use of JavaScript was kept to a minimum to reduce the attack surface.
|
||||||
|
Various security measures were carefully put in place to reduce the attack surface of the website:
|
||||||
|
\begin{itemize}
|
||||||
|
\item User input and form field sanitization, alongside strong server-side validation to prevent cross-site scripting (XSS) and SQL injection attacks
|
||||||
|
\item To counteract cross-site request forgery (CSRF) attacks, CSRF tokens were implemented on all forms
|
||||||
|
\item To minimize the risk of supply chain and third-party XSS attacks, no external JavaScript dependencies are used by Medwings
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Considering that mobile devices are the primary platform for Medwings, the \Gls{ui} was designed to be fully responsive.
|
||||||
|
It adapts seamlessly to different screen sizes, whether accessed through mobile phones, tablets, or devices with a larger form factor.
|
||||||
|
Fast load times were a crucial design goal to ensure usability under various network conditions.
|
||||||
|
|
||||||
|
Navigational elements and the overall layout follow conventional patterns.
|
||||||
|
Animations are sparingly used to visually indicate in-progress system states, such as when waiting for data retrieval from the Withings Cloud.
|
||||||
|
|
||||||
\subsubsection{Datamodel}
|
\subsubsection{Datamodel}
|
||||||
|
|
||||||
@ -579,7 +664,7 @@ A holistic representation of the Medwings data model is shown in Figure~\ref{fig
|
|||||||
|
|
||||||
At its heart lies the \code{User} entity: it forms the nexus to which all vitals data and user information is linked.
|
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.
|
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 numerous vital signs, as well as the \Gls{mews} record which can potentially be calculated based on them, are also represented.
|
||||||
The \code{Profile} table stores additional medically relevant patient information as supplied during user registration.
|
The \code{Profile} table stores additional medically relevant patient information as supplied during user registration.
|
||||||
|
|
||||||
\subsubsection{Deployment}
|
\subsubsection{Deployment}
|
||||||
@ -890,30 +975,33 @@ imposed by Withings.
|
|||||||
Lastly, using Medwings and the smart medical devices requires the patient to have internet access, which will negatively impact the
|
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.
|
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
|
\newpage
|
||||||
\subsection{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
|
The Medwings system, while successful in its current iteration, offers multiple avenues for improvement.
|
||||||
|
|
||||||
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.
|
Its dependence on web-based access to the Withings API to retrieve vitals readings results in significant delays and mandates an internet connection.
|
||||||
|
A native mobile application offering direct Bluetooth access to sensor measurements would enhance real-time responsiveness and negate the necessity for a stable internet connection.
|
||||||
|
Unfortunately, Withings do not offer such an option to developers.
|
||||||
|
Vendor dependence in general introduces a risk to Medwings' continued operation.
|
||||||
|
Service outages, discontinued device updates, or the vendor ceasing business operations all render the smart devices, and consequently Medwings, unusable.
|
||||||
|
Vendor-independent access and open-source firmware for the medical devices would mitigate these risks and open up exciting possibilities for further system integrations.
|
||||||
|
|
||||||
The system as it stands lacks real-time alerting for emergency situations, relying solely on periodic MEWS calculations.
|
Additionally, expanding the range of monitored vitals could allow implementation of more comprehensive \Gls{rwm} techniques.
|
||||||
Incorporating real-time alerts can make the system more robust and useful.
|
The integration of a smart device capable of accurately measuring the respiration rate of a mobile patient would refine the \Gls{mews} calculations,
|
||||||
|
leading to a more accurate deterioration monitoring system.
|
||||||
|
The system could also benefit from real-time alerting for emergency situations, rather than relying solely on periodic \Gls{mews} calculations.
|
||||||
|
This would not only make the system more robust but would also be crucial for immediate medical intervention.
|
||||||
|
For healthcare providers, a monitoring platform could be developed to allow medical staff to have direct visibility into their patient's vitals and recent developments.
|
||||||
|
|
||||||
Taking continuous measurements is superior to measuring intermittently\cite{gronbaek_continuous_2023, shaik_remote_2023}.
|
Intermittent vitals monitoring presents an incomplete picture of the patient's health status.
|
||||||
|
A continuous monitoring system would not only improve the system's efficacy\cite{gronbaek_continuous_2023, shaik_remote_2023}, but could greatly enhance the sampling
|
||||||
|
frequency and obviate the need for manual patient interaction for taking measurements.
|
||||||
|
|
||||||
|
Given more development time, a range of auxiliary features could be integrated into Medwings.
|
||||||
|
Native mobile notifications, more detailed vitals analysis, and utilization of additional functionalities available in Withings devices
|
||||||
|
would elevate the system's overall capabilities and usefulness.
|
||||||
|
As technology advances, future work could explore machine learning models to predict potential health anomalies based on historical data.
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
\subsection{Implications and Conclusions}
|
\subsection{Implications and Conclusions}
|
||||||
|