INFO30005 Project Solution

Your team has been contracted to design and build software for Diabetes@Home, a startup who plan to sell digital health solutions.
You will build their flagship product, a web app that helps people to manage their diabetes in the convenience of their own home, recording data that can be monitored remotely by their clinician.
Photo by Towfiqu barbhuiya on Unsplash
You need to make two different user-interfaces for the app: one for patients and one for clinicians. These will share a database.
This document describes the features you should include.

Patient UI
OUR PATIENTS
INFORMATION PAGES
Anyone who navigates to the website should be able to access two information pages:
• “About diabetes”
• “About this website”
“About this website” is a static webpage that briefly describes the website and who built it, and explains that people need to be logged in to access most of the features.
Users do not need to be logged in to view these two static pages. However, the remaining features described in this document should only be accessible by users who are logged in.
RECORDING HEALTH DATA
The primary purpose of the app is to allow patients to record their own health data. Different patients will need to record different data, as specified by their clinician – this is explained below. Each data-set is a time series, and each patient will record one or more of them. We want patients to update each of their time-series once per day.
Note that patients don’t necessarily want to update all their time-series at the same time. For example, Alice might prefer to update her blood glucose data in the morning and her insulin dose data at night. Your UI design should make this easy.
At a given moment, the user-interface needs to make it clear which data the patient has already recorded that day, and which they have yet to record. This is so that patients don’t forget to enter their data, but also don’t double up and enter a value twice.
A person with diabetes will typically need to record data every day for many years, so the app needs to offer great usability, and a positive and motivating user-experience.
CUSTOMIZED DATA REQUIREMENTS FOR PATIENTS
Each patient will record some subset of these heath data time-series:
• blood glucose level (in nmol/L)
• weight (in kg)
• doses of insulin taken (number of doses)
• exercise (step count)
These are all numerical data. ‘Insulin’ and ‘exercise’ are counts and needn’t include decimal places. The app should allow the patient to add a written comment to any number: for example, Alice might attach a comment to her step-count saying “I went for an extra walk Photo by Nathan Dumlao on today”. Each number entered should be timestamped in the database. Unsplash
(When you display data to users, make sure that times are displayed in a user-friendly format and in Melbourne time.)
The app must allow clinicians to specify the set of required time-series for each individual patient that they manage. For example, patient Alice might be required to record “blood glucose + exercise”, while patient Bob is required to record “blood glucose + weight + number of insulin doses”. Clinicians need to be able to manage this over time – for example, Bob’s clinician might decide to add “exercise” to Bob’s list at some point, or remove ‘weight’. It should be clear to every patient which data they need to enter.
VIEWING DATA
Your app should allow patients to view data that they have already recorded. Seeing their health data change over time can be informative and motivating for patients.
A good way to display a time-series is in a table or grid format, with one data-entry per row, and time flowing down the page. Numbers and times should be displayed in a user-friendly format. Later in this document you’ll see that you can earn bonus marks by offering a chart display also.
SUPPORT MESSAGES
MOTIVATION
People with diabetes need to enter data every day for many years, and some struggle to stay motivated to perform these necessary actions. Include the following features to encourage users to engage with data-entry:
• Patients get a digital badge (an image appears in their UI) if their overall engagement rate since they started using the app is more than 80%.
• Allow patients to see a leaderboard that congratulates the 5 patients with the highest engagement rate. (Display patients’ “screen names” rather than real names.)
Engagement rate is the percentage of data entries that were carried out as requested by the patient’s clinician.
You can be creative in choosing how to visualize these features.
Clinician UI
patient per row, and columns showing the current values of the data being tracked. Photo by Online Marketing on Unsplash
DASHBOARD
Clinicians need a main “dashboard” screen that displays an overview of their patients. We suggest you use a grid or table format, with one
Data values should be highlighted visually if the clinician’s attention is required – for example, if a patient has not entered some required data, or has entered data that fall outside the patient’s safety thresholds (i.e. the number is too big or too small). Safety thresholds can be different for each patient, and clinicians must be able to store these in the database.
WORKING WITH INDIVIDUAL PATIENTS
While viewing the dashboard, a clinician must be able to “drill down” on an individual patient by clicking on their name. This should open a new page that allows the clinician to see the data about that patient.
The clinician needs to be able to manage the requirements for each patient, such as:
• specify which time-series this patient should be recording • specify upper and/or lower safety thresholds for the patient’s data
• enter and manage support messages for this patient.
VIEWING PATIENT HEALTH DATA
The clinician should be able to view data that the patient has recorded.
CLINICAL NOTES
Clinicians sometimes need to record notes about a patient. Clinical notes are text only – they don’t include pictures or audiovisual recordings. Each note is about a specific patient at a specific time, and needn’t be attached to a specific piece of health data.
The UI should make it easy for clinicians both to enter and read clinical notes about a patient.
SUPPORT MESSAGES
Many people with diabetes like to receive encouragement from their clinician, but while selfmanaging there are few opportunities to speak. Include a feature that allows clinicians to enter customized text messages which are displayed to patients. Allow emojis.
Messages need to be entered individually for individual patients: for example, clinician Carol might want patient Alice to see the message “Happy birthday Alice!”, and patient Bob to see the message “Hi Bob - great day for exercising”. Messages need to be updatable, so that patients don’t get tired of seeing the same message every day.
MONITORING PATIENT COMMENTS
When a health system allows patients to enter text, it is important that staff monitor what patients are entering, in case a patient uses the feature to indicate a problem.
Include a feature that allows a clinician to see a list of all comments by all of the clinician’s patients. Allow the clinician to quickly scan all comments, so they can spot possible problems. Allow them to click on any comment to view that patient’s data.
Other requirements
AUTHENTICATION and SECURITY
All users (patients and clinicians) must be registered in the database, and must enter a userid
(email address) and password to use the app. Use good security practices such as authentication and session management to handle logins and registrations and to appropriately restrict access to features and data. Allow all users to manage their own passwords. Make sure passwords are at least 8 characters long. Passwords should be encrypted when stored in the database.
As well as email and password, the app should store each user’s given and family names, screen name (that other users see), year of birth, and a brief text bio.
Patients do not self-register; rather, each clinician should register their own patients by entering their details into a form.
INPUT DATA VALIDATION
Check that all data entered by patients are of valid data types (e.g. text, integers etc) and within reasonable bounds (e.g. numbers are not negative nor extremely big). This is in addition to checking safety thresholds, as discussed above.
Validation constraints can be hard-coded – you do not need to build an administrative system to manage them.
DATA MANAGEMENT
Health data and clinical notes need not be editable – once recorded in the database they can be considered permanent.
Your system will probably include other data that don’t change very often. There’s no need to create a separate administration website for this - you can simply enter such data yourself.
RESPONSIVE DESIGN
The patient UI needs to work well on these screen sizes:
• Phone: 375 x 812 (iPhone X, portrait)
• Tablet: 1024 x 768 (iPad, landscape)
• Desktop: 1920 × 1080 (monitor, landscape)
The clinician UI only needs to be designed for the desktop screen size.
Optional features
CHARTS
Use line charts to visualize numerical data, such as a patient’s blood glucose level over time.
There are a number of ways to create charts on the web – choose one that you wish to explore.
LIVE ALERTS
Use a dynamic-update technology such as Ajax to implement alert messages that appear in a clinician’s UI if one of their patients submits health data that is outside the safety range.
Ideally the message should be presented to the clinician regardless of which screen they are looking at (as long as they are logged in), within 5 minutes of the patient entering the data.
CUSTOMIZED COLOUR SCHEMES
Allow patients to choose among a small set of pre-defined colour schemes for their UI – for example, “light mode” and “dark mode”, or seasonal palettes such as “winter” and “summer”.
When a patient chooses a colour scheme, the UI’s appearance should change (for that patient only).
(Ideally, store this preference in the database so that the patient sees this colour-scheme on all their devices.)

[end of requirements]