HitoeSleep

Wireless Solution for Childrens' Sleep Studies - Powered by Hitoe

Sleep studies using polysomnography tend to be uncomfortable for patients especially in the case of children. Our team is providing a Proof-Of-Concept implementation of NTTData’s ‘hitoe’ smart t-shirt system for use as a wireless sensor suite in sleep studies at Great Ormond Street Hospital’s (GOSH) Respiratory Sleep Clinic. We will be modifying the existing ‘hitoe’ Android app to store data in the cloud. A physician can then view this data in real time through a web portal. Our project will pave the way for future development of the ‘hitoe’ as a viable replacement for polysomnography in sleep studies, providing a more comfortable and potentially more reliable source of sleep data for physicians.

Key Features

Real-Time Data Storage

All data received from the Hitoe is automatically stored in the cloud, physicians no longer need to fear data loss due to machine failure

Real-Time Data Display

Data from the Hitoe can be viewed in real time from our web portal from anywhere in the world. This opens up the possibilities for remote monitoring of home sleep studies.

100% Wireless

Patients only need to put on the hitoe t-shirt; no wires need to be connected at all. No wires means a more comfortable sleep experience for patients and less data loss for physicians


Our Team

Mariam Abbas
Team Leader/Mobile Developer

Client Liaison
Android App Developer
Unit Testing

Abhinath Kumar
Front-End Developer

UI Design
Dashboard Development
Integration Testing

Vijeykannen Vijayaratnam
Back-End Developer

Azure Cloud Management
Report Editing
System Testing

Requirements

Client Information
NTT Data

NTT Data Corporation is a Japanese System Integration Company and a partially owned subsidiary of Nippon Telegraph and Telephone (NTT). It is the largest IT services company headquartered in Japan. NTT Data develops many products for use in multiple applications. One such product is the Hitoe smart t-shirt, it has electrocardiogram sensors and an accelerometer embedded within the t-shirt which can provide detailed and real-time information on its wearer's heart rate, posture and heart activity. NTT Data has found applications for the Hitoe in the sport, racing and military sectors among others. NTT Data is looking to expand the use of the Hitoe into the medical sector as a wireless sensor suite for sleep studies.

Great Ormond Street Hospital

Great Ormond Street Hospital (GOSH) is a children's hospital located in the Bloomsbury area of the London Borough of Camden. It is the largest centre for child heart surgery in the UK and one of the alrgest centres for heart transplantation in the world. The Respiratory Sleep Unit of GOSH evaluates and treats sleep disorders in children.
A sleep study involves the use electrocardiogram sensors, chest and lung excursion sensors, oxygen saturation sensors, and occasionally brain activity sensors. Each sensor is individually wired to a it difficult for patients to sleep reducing the effective duration of the test. Furthermore, if the patients move or touch the wires in the sleep it could lead to data loss and may require physicians to adjust the sensors further disrupting the study. The physicians from GOSH want a wireless sensor suite so that patients can sleep comfortably and have less data lost due to wire movement. They also want to explore the possibilities for remote monitoring of patients, so that patients could perform sleep studies from the comfort of their own homes without compromising the usefulness of the data.

Project Goals


Our team was tasked with providing a Proof-Of-Concept implementation of the Hitoe as a wireless sensor suite for sleep studies. We were to modify the Hitoe Android app to push data to a database instead of only displaying on the phone. We had to make a web portal to view the data received from the Android app. This would pave the way for the use of the Hitoe in remote monitoring of sleep studies done at home.

Requirements Gathering


We gathered our requirements through multiple discussions with our client. We talked with both Doctors and Sleep Physicians to get a better idea of the problem from multiple perspectives. Due to confidentiality issues, we were unable to interview any patients but we did have a hands-on trial with the existing sensors to get an idea of how the wires affected patients.

Personas

Storyboards

MoSCoW Requirements

Once we gathered all our requirements, we classified them into functional and non-functional requirements and then further divided them into Must Have, Could Have, and Should Have.

Requirement Priority Type
System must be stored in the cloud or accessible on a localhost Must Functional
System must be able to operate wirelessly Must Functional
All data must be stored in a database Must Functional
A web portal must be built to view the data Must Functional
The web portal must be able to display the data in real time Must Functional
Mobile app must send data received from Hitoe in real time to database Must Functional
The web portal should be able to updata data in real time without refreshing the page Should Functional
Mobile App should be able to show if it is connected to the necessary systems (WiFi, Server, Hitoe) Should Functional
The web portal should have a login system Should Functional
Database should be encrypted. Data should only be viewable from the dashboard and not from the database admin. Should Non-Functional
System could notify doctors if sensors are disconnected Could Non-Functional
Web portal could have a slider to view past data from at least the past 2 hours Could Non-Functional
Web portal could allow Physicians to export a study as a CSV Could Functional
System could be able to handle multiple concurrent studies Could Non-Functional
Web portal could be accessible by multiple physicians from different computers Could Non-Functional

Use Cases


ID Use Case
WP1 Show Login Page
WP2 Search Studies
WP3 Export Study
WP4 Select Study
WP5 Logout
AA1 Startup
AA2 Change Patient ID
AA3 Change Study ID
AA4 Start Measurement
AA5 Stop Measurement
Use Case Show Login Page
ID WP1
Brief Description The system displays the login page
Primary Actors Physician
Secondary Actors System
Preconditions None
Main Flow 1. Physician accesses the web portal via its URL.
2. System displays login page with fields for username and password.
3. Physician enters username and password, then clicks on login.
4. System checks that username and password match with known users.
5. System saves logged in user.
6. System displays table page.
Postconditions Physician is logged in.
Alternative Flows Wrong Credentials
Alternative flow starts after step 4 in main flow.
1. System displays error message "Wrong Username or Password"

Use Case Search studies
ID WP2
Brief Description System displays Table page where studies can be searched
Primary Actors Physician
Secondary Actors System
Preconditions 1. Physician is logged in (WP1)
2. System is displaying table page.
Main Flow 1. System displays table page with table of all studies.
2. Physician types Study ID, Patient ID, Time, or Date into search box at top right corner of table.
3. System filters table to show studies which match the search field.
Postconditions Table shows filtered table of studies
Alternative Flows None

Use Case Export Study
ID WP3
Brief Description Physician selects a study to be exported as CSV file
Primary Actors Physician
Secondary Actors System
Preconditions 1. Physician is logged in (WP1)
2. System is displaying table page.
Main Flow 1. Physician enters the Study ID of the study they want to export into the text field saying "Enter ID of study to export as CSV" and hits enter.
2. System stores the Study ID and queries the database for the table belonging to the study ID.
3. System converts the table into CSV format and displays a download pop-up.
4. Physician clicks save file.
Postconditions Physician has downloaded a CSV of a study.
Alternative Flows None

Use Case Select Study
ID WP 4
Brief Description Physician selects the study they want to view
Primary Actors Physician
Secondary Actors System
Preconditions 1. Physician is logged in (WP1)
2. System is displaying table page.
Main Flow 1. Physician types in the ID of the study they want to view into the text box "Enter ID of Study" and hits enter.
2. System stores ID of study.
3. System displays dashboard page with the info from the selected study.
Postconditions 1. System has stored Study ID of selected study.
2. System is displaying dashboard page for selected study.
Alternative Flows None

Use Case Logout
ID WP5
Brief Description Physician logs out from the system
Primary Actors Physician
Secondary Actors System
Preconditions 1. Physician is logged in (WP1)
2. System is displaying dashboard page.
Main Flow 1. Physician clicks on the "Logout" button.
2. System sets the logged in user to none.
3. System displays the login page.
Postconditions 1. Physician is no longer logged in.
Alternative Flows None

Use Case Startup
ID AA1
Brief Description Mobile User starts up app
Primary Actors Mobile User
Secondary Actors Mobile App
Preconditions Phone is connected to WiFi
Main Flow 1. Mobile User opens app.
2. App asks User to enter a Patient ID.
3. User enters a Patient ID and clicks "OK".
4. App stores the Patient ID.
5. App asks User to enter a Study ID.
6. User enters a Study ID and clicks "OK".
7. App displays main screen.
Postconditions 1. App has stored Patient ID.
2. App has stored Study ID.
Alternative Flows Alternative Flow starts before step 1 in Main Flow.
1. App displays pop-up telling User to turn on WiFi before starting up the app.
2. User click "OK".
3. App exits.

Use Case Change Patient ID
ID AA2
Brief Description Mobile User decides to change the Patient ID previously entered
Primary Actors Mobile User
Secondary Actors App
Preconditions 1. Phone is connected to WiFi.
2. App has stored Patient ID.
3. App has stored Study ID.
Main Flow 1. User clicks on menu button in top right.
2. App displays menu.
3. User clicks on "Change Patient ID".
4. App displays pop-up with current Patient ID and a text field for new Patient ID.
5. User enters new Patient ID and clicks "OK".
6. App displays main page.
Postconditions 1. App stores updated Patient ID.
Alternative Flows None

Use Case Change Study ID
ID AA3
Brief Description Mobile User decides to change the Study ID previously entered
Primary Actors Mobile User
Secondary Actors App
Preconditions 1. Phone is connected to WiFi.
2. App has stored Patient ID.
3. App has stored Study ID.
Main Flow 1. User clicks on menu button in top right.
2. App displays menu.
3. User clicks on "Change Study ID".
4. App displays pop-up with current Study ID and a text field for new Study ID.
5. User enters new Study ID and clicks "OK".
6. App displays main page.
Postconditions 1. App stores updated Study ID.
Alternative Flows None

Use Case Start Measurement
ID AA4
Brief Description User decides to start measurement using Hitoe
Primary Actors User
Secondary Actors App, System
Preconditions 1. Phone is connected to WiFi.
2. App has stored Patient ID.
3. App has stored Study ID.
4. Bluetooth is on.
Main Flow 1. User clicks on "Start Measurement".
2. App displays a pop-up saying it is searching for available sensors.
3. After some time, the App displays a list of the sensors it has found.
4. User selects their Hitoe shirt from the list and clicks "OK".
5. The App starts receiving data from the Hitoe.
6. App displays data from Hitoe on main screen.
7. App sends data from Hitoe to Sytem in the background.
Postconditions 1. Hitoe is connected.
2. App is sending data to System.
Alternative Flows Alternative Flow starts after step 3 in Main Flow
1. If no sensors are found the App displays an empty list of sensors.
2. User clicks on "OK".
3. App displays main screen.

Use Case Stop Measurement
ID AA5
Brief Description User decides to stop measurement using Hitoe
Primary Actors Mobile User
Secondary Actors App, System
Preconditions 1. Phone is connected to WiFi.
2. App has stored Patient ID.
3. App has stored Study ID.
4. Bluetooth is on.
5. Hitoe is connected.
6. App is sending data to System.
Main Flow 1. User clicks on "Start Measurement" button.
2. App stops receiving data from Hitoe.
3. App stops sending data to System.
Postconditions 1. App has stopped sending data to System.
Alternative Flows None

Research

Existing Sleep Study Systems
Polysomnography

Polysomnography is a diagnostic tool in sleep medicine used to determine sleep disorders. In its most basic form it requires the use of electrocardiogram sensors to measure heart activity, chest and abdomen excursion sensors to measure respiratory activity, and pulse oximeters to measure blood oxygen level. More in-depth studies may add sensors to measure eye movements or brain activity. [1] The data from these sensors is transmitted to a physician's computer. These studies need to be performed in a sleep clinic and require at minimum four wired sensors. These two factors can lead to discomfort for patients.


Home Sleep Study Kit

Home sleep study kits were designed to overcome the need for sleep studies to be done in a clinic. They have the necessary sensors for a basic polysomogram (electrocardiogram, chest and abdomen excursion, pulse oximeter) but have a memory unit in the sensor hub able to store the data for one to two sleep studies. The patient would attach the sensors to themselves before going to sleep in their own bedroom, after that they have to return the kit to a physician who will download the data from the kit and perform their analysis of the data. [2] These kits allow patients to perform the sleep study at home, however they still use wired sensors which still lead to discomfort. Furthermore, patients may find difficulty attaching the sensors correctly.


Hitoe

The Hitoe provides an electrocardiogram and accelerometer embedded in the shirt. It transmits data via Bluetooth to an Android phone which displays the data. Since the sensors are embedded in the shirt there are no exposed wires. The Hitoe does not currently have the necessary sensors to conduct a sleep study. However the shirt is comfortable and easy to use as the sensors do not need to be individually attached to the body.


Decision

In order for the Hitoe to be a viable replacement for polysomnography it would need to be fitted with additional sensors. It would also need to be modified to transmit the data to a computer or a cloud storage so that the data can be analysed by a physician. Due to the limited timeframe and the team's general lack of experience in product design and electrical engineering, we decided that we would focus on building the data transmission modifications. We would modify the Hitoe Android app to transmit the data to a cloud storage which can then be accessed via a web portal. This would allow the data to be viewed in real time, which would be an improvement over home sleep studies and paves the way for the Hitoe to be used for remote monitoring of sleep studies.

Mobile Application

The Hitoe had both Apple and Android versions of its application. We had to decide on one to modify.

Apple (iOS)

It would make sense to have developed an Apple app as the iPhone is the most popular smartphone operating system in the UK [3], this would theoretically make the Hitoe accessible to more people in the UK for home sleep studies. However, the team has not had much experience developing apps for iOS.


Android

Android apps have the benefit of being coded in Java which the team has had prior experience with. Furthermore, the average price of an Android phone is about a third of the average price of an iPhone. [4] This would lead to significant savings for physicians if they had to purchase phones to use the Hitoe.


Decision

We decided to develop in Android as our client GOSH would have to buy smartphones in order to use the Hitoe in their sleep clinic. We concluded that the slight lead in market share of Apple over Android in the UK was not as significant as the potential savings from Android phones.

Data Visualisation Framework


Razorflow

Razorflow is a data visualisation framework that supports industry-standard column, pie, bar, line charts and more. It is cross-browser compatible and even mobile friendly. [5] The most appealing feature of Razorflow for our team was that it supported server-side wrapping which meant that dashboards could be built entirely using PHP without any JavaScript or HTML. This would mean that our team would have needed less research to begin coding.


Chart.js

Chart.js is an open source HTML5 data visualisation framework. [6] Chart.js includes smooth transitions when updating data which is important for our dashboard as data from the t-shirt would be updated in real time. Chart.js also has very comprehensive documentation and a large user base.


Decision

Upon further research into the documentation of Razorflow, we discovered that the PHP only version of Razorflow did not support real-time updating. Thus the main selling point for Razorflow was rendered moot. We decided that Chart.js would be the ideal data visualisation framework.

References

[1] Mayo Clinic, "Polysomnography (Sleep Study) - About - Mayo Clinic," 4 December 2014. [Online]. Available: https://www.mayoclinic.org/tests-procedures/polysomnography/about/pac-20394877.
[2] Sleep.org, "Do at Home Sleep Studies Really Work | Sleep.org," [Online]. Available: https://sleep.org/articles/home-sleep-study-kits/.
[3] Statista, "Mobile OS: Market Share in the United Kingdom 2011-2018 | Statistic," 2018. [Online]. Available: https://www.statista.com/statistics/262179/market-share-held-by-mobile-operating-systems-in-the-united-kingdom/.
[4] M. Rutnik, "Price gap between Samsung and Apple smartphones reaches new record - Android Authority," 5 May 2017. [Online]. Available: https://www.androidauthority.com/price-gap-samsung-apple-smartphones-769772/.
[5] Razorflow Technologies LLP, "Razorflow - HTML5 Dashboard Framework," 2014. [Online]. Available: https://razorflow.com/.
[6] Chart.js, "Chart.js | Open Source HTML5 Charts for your Website," 2017. [Online]. Available: http://www.chartjs.org.

Human Computer Interaction

Interviews

We gathered the requirements for our project by interviewing the sleep physiologists from GOSH.

Sketches
Widgets

Right from the start of the design process it was clear that our client needed clear and intuitive displays for the data. Hence we decided it would be best to start by designing the displays or widgets for each form of data.

Dashboard Sketches

Once the design of the widgets was completed, the next step was to find an optimal arrangement of widgets. We decided to sketch out multiple different options and discuss with out client to see which one would work best.

Final Dashboard Sketch

Once we had an chosen an arrangment with our client. We further fleshed out the design and labelled the key features.

Wireframe

We then proceeded to build a wireframe for our final dashboard using Microsoft Powerpoint. We incorporated some changes to the design that were requested by our clients. Namely, they wanted the line charts (electrocardiogram and excursion) to be aligned and they wanted a slider to move between different periods of time. We also added the widget for posture.

Final Prototype

Our final prototype included many of the design aspects from our wireframe. However, due to time constraints we could not implement every feature that was initially included in the wireframe. Our clients understood our concerns and were willing to reduce the requirements of the project accordingly.
Final Prototype

Design

System Architecture

Sequence Diagram

The sequence diagram shows the interaction between the different PHP scripts we have written. Dashed lines are used to indicate background processes, solid lines indicate actions initiated by user input. The scripts in orange boxes are front-end PHP scripts ie. they have HTML and Javascript elements for displaying to the browser. uploadData.php is the script used by the Android app to upload the Hitoe data to the database. It does not interact with the other PHP scripts but has been included in the sequence diagram for completeness.

Design Patterns

Although our system was not object-oriented we were able to draw on some of the design patterns from object-oriented programming in our design.

Singleton Pattern

The file "config.php" acted as a singleton for storing the database credentials. This allowed us to move between different database setups without having to edit all the PHP scripts.

Iterator Pattern

We use an iterator to iterate through each row of the table and write to a CSV file when exporting a study as CSV.

Model-View-Controller (MVC) Pattern

In the Android app, there are functions that act as a controller which pulls data from the model classes and updates the View functions which update the UI for when data needs to be displayed (such as Patient ID, ecg etc). There are also model functions which handle the data and store it. These model classes also handle the data such as parsing the values they receive from the sensors.

Observer Pattern

The Android app uses Listeners to detect when particular buttons are clicked.

Adapter Pattern

The Android app uses an Adapter function to retrieve data from the Hitoe SDK and packages it in a JSON format so it can be parsed by a PHP script, and inserted into the database.

Data Schema

The data schema shows the relations betweent the tables in our database. Each individual study is stored in a single table as indicated by the stacked tables.

Testing

Testing Strategy

We followed the V-Model when testing our system. We performed unit tests, integration tests, system tests, and acceptance tests. Below is a list of the tests we conducted.
ID Test Name Type
1 Test that app can convert data into JSON packages correctly. Unit
2 JSON files are posted to PHP file Unit
3 Check phone sends data to PHP script correctly Integration
4 Check PHP script sends data to database correctly Integration
5 Check dashboard pulls data from database and displays it correctly Integration
6 Check that dashboard updates in real time without refreshing the page Integration
7 Stress Test System
8 System sends data in real time System
9 System sends data that matches that received by the phone System
10 Acceptance test with NTT Data: Mr Gadhu Sundaram Acceptance
11 UI Acceptance test with NTT Data: Mr Gadhu Sundaram Acceptance
12 Acceptance test with NTT Data: Mr Warren Stone Acceptance
13 UI Acceptance test with NTT Data: Mr Warren Stone Acceptance
14 Acceptance test with GOSH: Dr Elaine Chan Acceptance
15 UI Acceptance test with GOSH: Dr Elaine Chan Acceptance

Unit Testing


ID 1
Title Test that app can convert data into JSON packages correctly
Description When we send data from the Android app, we must package it into a JSON file. This test ensures those functions run correctly
Test Steps 1. Create a unit test suit that checks the tests the following functionalities:
 a. A unit test that makes sure heart rate gets loaded correctly
 b. A unit test take makes sure posture values get loaded correctly
 c. A unit test that makes sure that ecg gets loaded correctly
 d. A unit test that makes sure time values get loaded correctly
2. Run the test suite.
Expected Results All unit tests in the test suite should pass
Actual Results Test Passed, All unit tests passed

ID 2
Title JSON files are posted to PHP file
Description When we send the data from the phone as a JSON file, we do so with a function that uses HTTP Post, this test ensures that this function behaves correctly
Test Steps 1. Create a test PHP script to accept the test JSON file
2. Create a unit test that packages a JSON file using the function and sends it to the test PHP script
3. Assert the response of the HTTP POST to check it has been successfully sent
Expected Results The Unit test should pass
Actual Results Test Passed, All unit tests passed

Integration Testing


ID 3
Title Check phone sends data to PHP script correctly
Description We need to ensure that PHP script is properly integrated with the mobile phone application and successfully receiving the data
Test Steps 1. Modify the PHP script to a test script that output all the data it receives to a text file
2. Modify the mobile application to a testing version which records all JSON files sent
3. Turn on the Android app and send data to the PHP script
4. Compare 10 randomly selected JSON files received by the PHP script to the JSON files sent by the phone
Expected Results All 10 JSON files sent match those that the phone sends
Actual Results Test passed, All 10 JSON files matched

ID 4
Title Check PHP script sends data to database correctly
Description We need to ensure that PHP script is properly integrated with the database and is correctly inserting the data into the right tables.
Test Steps 1. Modify the PHP script to a test script that output all the data it receives to a text file
2. Setup the phone and create 5 test studies with different Patient IDs and Study IDs and note down the IDs and their start times.
3. Check the database has created 5 new tables with the correct Study ID as the table name.
4. Check data in the tables matches those found in the text files
5. Check all the studies have been properly inserted into the database with the correct start times
Expected Results All the steps should have been successfully completed
Actual Results Test passed, All test steps were successfully completed

ID 5
Title Check dashboard pulls data from database and displays it correctly
Description We need to ensure that dashboard is properly integrated with the database and is correctly displaying the data.
Test Steps 1. Create a test study and start collating data inside the database
2. Load the dashboard with the correct test study
3. Choose 10 random data points in the ecg and compare to those in the database to ensure they match
4. At 10 random time intervals note the Heart Rate and Posture and compare those to the database to ensure they match
5. After test study has been completed, download the CSV file from dashboard, and compare 15 entries to that in the database
Expected Results All the steps should have been successfully completed
Actual Results Test passed, All test steps were successfully completed

ID 6
Title Check that dashboard updates in real time without refreshing the page
Description Test to ensure that the dashboard is able to update with newly inserted data without refreshing the page
Test Steps 1. Create a test study and collate data inside the database.
2. After 20 seconds stop the study
3. Open the dashboard and see that the data from the test study is being displayed.
4. Manually insert 5 new data points into the test study's table in the database.
5. Check to see if the dashboard updates to show the manually inserted data points without refreshing the page.
Expected Results Dashboard should update to show manually inserted data points.
Actual Results Dashboard was able to update to display new data points without refreshing. Test passed.

System Testing


ID 7
Title Stress Test
Description We need to ensure our system can handle multiple hitoe shirts with multiple studies
Test Steps 1. Create a PHP script that simulates 2 tshirts sending data at twice the expected rate (200 points per second)
2. Open the dashboard for all those studies and ensure that the data is being displayed smoothly and is not lagging
3.Repeat steps 1-2 for the following number of simulated t-shirts: 3, 4, 5, 6
Expected Results All the steps should have been successfully completed
Actual Results Test passed, All test steps were successfully completed

ID 8
Title System sends data in real time
Description Data from the Hitoe t-shirt should be displayed in real time on the dashboard
Test Steps 1. Have someone wear the t-shirt and measure their Heart Rate while they are at rest
2. Start sending data for 10 seconds while the person rests and prepare a timer
3. Have the person start running on the spot for 10 seconds to increase heart rate
4. Time the interval between when the person starts running and when the Heart starts increasing (beyond natural fluctuation +-3bpm)
5. Repeat steps 1-4 five times and find the average time taken for the dashboard to update.
Expected Results The expected result is that the timed value should be less than 5 seconds
Actual Results Test Passed, Data was sent on average within 1 second

ID 9
Title System sends data that matches that received by the phone
Description The data flow from Phone to Dashboard should be accurate and display the correct data
Test Steps 1. Modify the mobile application for a testing version that records all JSON files sent
2. Load the dashboard with the correct test study
3. Choose 10 random data points in the ecg and compare to those in the database to ensure they match
4. At 10 random time intervals note that HR and Posture and compare those the database to ensure they match
5. After the test study has been completed, download the CSV file from the dashboard, and compare 15 entries to data sent by the phone.
Expected Results All the steps should have been successfully completed
Actual Results Test passed, All test steps were successfully completed

Acceptance Testing


We conducted our acceptance testing by giving a live demonstration of our system to our clients, NTTData and GOSH. We then asked them to fill out questionnaires relating to the overall project and to the User Interface.

With regards to the User Interface these are the results of the tests.

With regards to the overall project acceptance tests all of our clients expressed that they were happy with what the project has achieved.
In particular, Dr Elaine Chan had the following comment:
"Mariam and colleagues have made a concerted effort to understand our current sleep study set up in the hospital. In the past few months, they have incorporated our paediatric patient needs with available technology to produce this prototype that allows physiological monitoring during sleep at home, with the capability of remote monitoring and data storage. This will open up future possibilities to expand the parameters being monitored."
Their full responses are attached below as PDFs.
Acceptance test with NTT Data: Mr Gadhu Sundaram
UI Acceptance test with NTT Data: Mr Gadhu Sundaram
Acceptance and UI test with NTT Data: Mr Warren Stone
Acceptance and UI test with GOSH: Dr Elaine Chan

Evaluation

Summary of Achievements

Requirements Completion Status

Requirement Priority State Contributors
System must be stored in the cloud or accessible on a localhost Must ✓ All
System must be able to operate wirelessly Must ✓ All
All data must be stored in a database Must ✓ All
A web portal must be built to view the data Must ✓ Abhinath, Vijey
The web portal must be able to display the data in real time Must ✓ All
Mobile app must send data received from Hitoe in real time to database Must ✓ Mariam, Vijey
The web portal should be able to updata data in real time without refreshing the page Should ✓ Abinath
Mobile App should be able to show if it is connected to the necessary systems (WiFi, Server, Hitoe) Should ✓ Mariam
The web portal should have a login system Should ✓ Vijey
Database should be encrypted. Data should only be viewable from the dashboard and not from the database admin. Should ✗ Abhinath, Vijey
System could notify doctors if sensors are disconnected Could ✓ Abhinath, Mariam
Web portal could have a slider to view past data from at least the past 2 hours Could ✗ Abhinath
Web portal could allow Physicians to export a study as a CSV Could ✓ Abhinath, Vijey
System could be able to handle multiple concurrent studies Could ✓ All
Web portal could be accessible by multiple physicians from different computers Could ✓ Vijey
Key Functionalities (Must Have and Should Have) 90% completed
Optional Functionalities (Could Have) 80% completed

List of Known Bugs

ID Bug Description Priority
1 Very rare (1 in 100) crash when starting measurement Low

Individual Contribution Table

Work Packages Mariam Abhinath Vijey
Client Liaison 60% 20% 20%
Requirement Analysis 32% 32% 36%
Research 32% 36% 32%
UI Design 15% 70% 15%
Front End Development 5% 70% 25%
Back End Development 15% 15% 70%
Mobile Development 80% 10% 10%
Testing 36% 32% 32%
Bi-Weekly Reports 15% 15% 70%
Project Website 15% 15% 70%
Poster Design 15% 70% 15%
Video Editing 70% 15% 15%
Overall Contribution 33% 33% 34%
Main Roles Client Liaison, Mobile Developer, Video Editing UI Design, Front End Developer, Integration Testing Azure Cloud Management, Back End Developer, Documentation

Critical Evaluation of Project

User Interface

The key design principle behind the UI was minimalism. We kept the number of interactive components to a minimum and let most of the key processes run in the background. We wanted to keep the number of steps required to use our system low, this way it could be learned more easily. This is important as our users are not very technically savvy. We think we have succeeded in keeping the system minimal, a physician can access the study they want to view in as little as two steps. We also used colours to differentiate the different data fields displayed on the dashboard, this helps the physician to tell them apart more easily.

Functionality

The goal of the project was to provide a proof of concept implementation of the Hitoe for sleep studies. Through our project we have shown that the data from the Hitoe can be stored in a database and viewed in real time. We have also shown that the system can be effectively deployed on the cloud. We have laid the groundwork for the system to be deployable, future teams will only need to implement a few key functionalities.

Firstly, the web portal needs more functionalities such as report generation, sleep phasing and noise reduction in order to be a viable replacement for programs such as REMLogic which is used by the Respiratory Sleep Unit at GOSH.

Secondly, the Hitoe needs additional sensors such as a pulse oximeter, and chest and abdomen excursion sensors in order to perform a proper sleep study. This would best be done by NTTData as they have experience from making the Hitoe embedding sensors into the fabric of the t-shirt, allowing it to stay wireless even with the added sensors.

Aside from the above, although it was not a requirement of the project, an unintended functionality of our system is that it can be used for other users of the Hitoe such as athletes and military personnel. Storing the data from the Hitoe on a database and having it accessible on the web means that users can analyse their vitals after their exercise. This adds value to the Hitoe for professional athletes or people who want to improve their fitness more seriously. Furthermore, in discussion with Dr. Elaine from GOSH, she said that this system without the extra sensors could still see use in other clinical settings such as physical therapy.

Stablity

The stability of the system has been shown to be high. The mobile app has only crashed once in our testing. The Hitoe t-shirt also has never lost connection with the mobile app. The database is able to handle large requests and data insertions as shown by our stress testing results. The web portal is able to handle the frequent AJAX queries. However, the system is heavily dependent on internet speed due to the high frequency of data pushes and pulls. Without a strong internet connection the web portal lags when displaying data to the dashboard.

Efficiency

In our implementation we chose to deploy our system on Azure. Through this we have shown that a cloud deployment is technically possible. The advantage of a cloud deployment is that it is highly scalable as storage or computing power can easily be expanded. However we have also seen that cloud computing incurs high operating costs. In a full deployment, the database would be storing data from hundreds or thousands of sleep studies each 8 hours long. In order to view the live data from the web portal, multiple queries need to be made constantly. This would incur significant costs in storage and network bandwidth. It may not be financially viable to deploy on Azure in the long term. It may be more cost effective if the hospital were to have their own dedicated server computers. We would recommend that the hospital weigh the pros and cons of both approaches.

Maintainability

The system does not need much maintenance after it is set up. Data can be manipulated while the system is running with no issue. The only maintenance that needs to be done is to clear the database of unneeded studies to save on storage costs. Currently, the data can only be accessed through phpMyAdmin. While this is an improvement from a command line interface, a future development should be to develop an administrator portal to provide a simplified interface for managing the database.

Project Management

We used Dropbox for our file sharing and management, we chose dropbox as it did not require a Google account like Google Drive thus allowing us to use our UCL emails. We used WhatsApp for communication between the team as it was free and the team was already familiar with using it. We used GitHub for version control as we had free private repositories we could use thanks to our student email accounts. We used TomsPlanner for scheduling and Gantt Chart creation.

Future Work

The main task for future development is to incorporate pulse oximeters, and chest and abdomen excursion sensors to the Hitoe. It is vital to add these sensors to the Hitoe in order for it to be used for medical sleep studies. Developing the web portal is also an important future task as physicians require functionalities such as sleep staging, report generation and noise reduction. An administrator portal should also be developed to allow the hospital to manage the records without having to use SQL. A potential alternative would be to develop a plugin that could push data from the database to existing software like REMLogic. This could be a more attractive option to physicians as they can continue to use the software they are familiar and comfortable with. This would require cooperation from Natus Medical Incorporated, the company which makes REMLogic, but has the potential to be more easily received by hospitals.

Management

User Manual

Mobile Application

  1. Download the apk by clicking here.
  2. Launch App; The mobile application requires you to be connected to wifi, so if you’re not connected to a secure wifi connection, the app will warn you with a pop-up: "No WiFI, Connect to WiFi and restart the app"
  3. On successful launch, the app will then show two more popups, one asking for a Patient ID, and one asking for a Study ID. The Patient ID is used to identify the patient undergoing the study. The Study ID is an identifier for the study which will be used to store and retrieve the data of this study from the database.
  4. If necessary the Patient ID and Study ID can be changed by clicking the menu button in the top right corner of the screen (three vertical dots). This dropdown menu provides 2 options “Change Patient ID” and “Change Study ID”. Selecting either of these will display a window showing the current ID and a text field allowing you to input a new one.
  5. Once the study ID and Patient ID have been setup, click on the radio button next to “Start Measurement” to begin the study.
  6. A pop-up should appear called Sensor selection, and will spend a few seconds searching for an available sensor. During this time do not press ok or cancel. After some time the window will show “These are the sensors we’ve found”. If no selections appear below then the app has not found the Hitoe transmitter, press cancel, and cancel the pincode input. Make sure the Hitoe transmitter is on, charged and in a reasonably close range before pressing the radio button next to "Start Measurement" again.
  7. If sensors do appear, select the topmost option that appears in the list and select “OK”.
  8. A second window will appear showing the ‘Pincode Input’, please input the 6 digit code on the back of the Hitoe transmitter and press “OK”, after this the sensor should be connected to the t-shirt.
  9. You can check the t-shirt is connected by seeing the recorded data being displayed on the screen, while the study is ongoing, please leave the app on and running.
  10. To stop recording, press the radio button next to "Start Measurement" again.

Web Application

  1. Go to the the following URL: http://51.140.155.84
  2. You will be directed to a Login page. Enter your login credentials and click submit or press Enter on your keyboard. These are the login credentials [Username: team29] [Password:team29UCL]
  3. If your login credentials are wrong the message "Your Login Name or Password is invalid" will be displayed.
  4. Once successfully logged in you will be directed to a page which lists all the studies in a table. This table can be ordered by clicking the headings, or searched by typing into the search field. You can download a study as CSV by typing the study ID into the text field below the table and clicking Submit. Once you know the ID of the study you want to look at, type it into the text field at the top of the page and click submit or press Enter on your keyboard.
  5. You will be directed to the dashboard page. On the sidebar on the left of the page you will see details of the patient such as Name, Age, and Sex. Above the patient name you will see the connection status of the Hitoe. In the main part of the page you can see three charts, the first is the electrocardiogram (ECG) graph which shows the last 30 seconds of ECG data. Below that are the Heart Rate chart which shows the last known heart rate of the patient, and the Posture chart which shows the last known posture of the patient.
  6. If the study is ongoing, the connection status in the sidebar will say "Connected". The ECG, Heart Rate, and Posture charts will also be updating in real-time.
  7. If you want to go back and select a different study, click on the "Back" button in the sidebar.
  8. To exit the dashboard click the "Logout" button. You will then be directed back to the login page. You have successfully been logged out.

Deployment Manual

  1. Set up a LAMP (Linux, Apache, MySQL, PHP) stack on Azure. Detailed instructions can be found here: Deploy LAMP on a Virtual Machine in Azure
  2. Edit config.php to match the database credentials you set up in Step 1.
  3. Install phpMyAdmin on your LAMP stack in order to set up your database. Detailed instructions can be found here: How to Install and Secure phpMyAdmin on Ubuntu 16.04
  4. In phpMyAdmin import the SQL file attached in the source code to copy the database setup. If you choose not to do this you will have to edit the table names in the queries for all back-end PHP scripts. (login.php , studies.php, data.php, export.php, patientInfo.php, uploadData.php)
  5. In Android Studio, edit the android app with the URL of your virtual machine. (line 201 of the MainActivity class.)
  6. The system should now be ready for use.

Bi Weekly Reports

Download ZIP file of Bi Weekly Reports

Gantt Chart

Legal Issues Report

As part of our project we also wrote a report on the legal issues associated with our project. Namely, the project deliverables, the potential liabilities, the intelllectual property issues, and data privacy concerns.
The report can be downloaded as a PDF by clicking here.