Requirements

Client

Technology and medicine have gone hand-in-hand for centuries and the perpetual development of both fields mean that the quality of healthcare and life expectancy is ever-increasing [1]. The National Health Service (NHS) is the United Kingdom’s public healthcare provider and is free at the point of use. Decades of innovation within the service has continuously raised the standards expected of British healthcare and, as such, the British people see it as the responsibility of the NHS to deliver on these expectations.

This is demonstrated through the announcement made in 2013 that the NHS will invest £1bn into technological advancements. As stated by the King’s Fund website, one of the major roles of technology within healthcare and the NHS is in “providing and storing information and advice” [2]. This is where NeuroRespone comes in, a team from the NHS, who deal with patients with long term neurological conditions, approached our group to build a system that can monitor and track data inputted by their patients.

Project

Our group was tasked with building NeuroResponse Mobile, a mobile application designed specifically to enhance the quality, efficiency and experience of patients symptom and side effect tracking. This project is one of the two pillars that fit together to form an overall system for dealing with the problem. The other pilar is a web clinician portal that was developed during the last summer, tailored for clinicians to manage and track their patients' evolution.

One of the main aims of the whole system is to provide better care to patients with multiple sclerosis. Our mobile app will play the role to offer patients the patients the possibility to input data such as how they are feeling on certain days and what side effects they are currently experiencing. From the clinician's perspective this is essential because it will dramatically increase the efficiency of communication between the clinician and patient, since the clinician will have available a wide spectrum of data to analyse, which in the past was unimaginable.

However, apart from all this collection of data that will result really useful to the clinician and for research, it is also worth mentioning that there exist patients' motivations to track their data. This was shown in a research conducted by at UCLIC and University of California, Irvine [3] where it was proved that self-tracking practices can make multiple sclerosis patients feel better and gain a sense of control over the disease.

Approach to the project

All team members actively took part in each stage of development of the project. Initially, the key objectives were to meet with our client and to establish an agreed upon direction to take the app. This involved requirement gathering and finding out the specific information we had to include once the structure of the app was built. We created a wireframe and designed the use cases and confirmed these with the client before we moved on to implementation.

Requirement gathering

Identifying and understanding the exact requirements was rather long process, especially when it comes to mutiple sclerosis (MS) because there is a plethora of variables to consider. One of initial meeetings was with our NHS client and this involved identifying the exact specifics that needed to be included in the mobile app – we also discussed the feasibility and timescale of achieving particular requirements. We also held weekly meetings with Dr Delmiro Fernandez-Reyes, which we spent discussing the technicalities and design structure of the app.

We had a meeting with our NHS client, where she took us through the science behind MS and showed us diagrams and how the side effects of particular treatments are caused. This gave us an insight into how we should be designing and structuring our app and gave us useful background information and context.

The final step of the requirement gathering process was to bring everything together and organise it all in a way in which we could easily implement. It was important here to recognise that the requirements we had were essentially feasible and correct.

Main deliverables

• Cross platform mobile health tracking app.

• Specifically designed for patients with multiple sclerosis, therefore it is not a generic self-tracking app.

• It has to allow patients them to keep record of their symptoms (these will be given by the NHS).

• It has to allow patients them to keep record of the side effects of the drug course they are on through a questionnaire. This questionnaire will be linked with the patient's treatment.

• It should have a simple and accessible design, with just the essential features.

Personas

A summary of what would be two different types of user that would make use of our app. Steve, a patient recently diagnosed with multiple sclerosis and Sarah, another patient with long experience with the disease. These two patients mainly differ in the experience they have with the disease and the way they cope with it.

Steve Smith

“I didn't know what was going on, I didn’t know where I was going next. I suppose that I just started to write stuff down as some sort of record, really, of what was happening to me.”

Demographics

• Age: 22
• Occupation: student
• Status: single
• Tier: millennial

Background

He's a philosophy university student. He isn't a sportive person, > although he likes eating healthy. He has been recently diagnosed with > MS. He feels frightened and overwhelmed with the randomness of relapses.

Technologies

• Samsung S8

Motivations

• Afraid of losing his physical and cognitive abilities at some later point in life.
• Wants to track the disease but at the same time he’s scared to see a worsening of the symptoms.

Goals

• Grasp the nature of MS.
• Take control over the relapses.
• Find some tool to record his symptoms on the fly, to later be able to communicate to his doctor how he feels.
• Be notified when he has appointments with the clinicians.

Sarah Miller

"Like any good scientist, I went: OK, I am going to try this experiment now and I am going to record what I measure and see if it helps.”

Demographics

• Age: 48
• Occupation: cook
• Status: married
• Tier: Gen X

Background

She has one son. Although she has a busy lifestyle, she really emphasises the importance of exercise. She was diagnosed MS 10 years ago, she has experience in self-managing the disease and she can cope with the symptoms.

Technologies

• MyFitnessPal
• Apple Watch
• NokiaBody +
• Nokia BPM
• iPhone

Motivations

• Wants to stay as healthy as possible to be eligible for a cure in the near future.
• Uses self-tracking to keep a control of her symptoms (spreadsheet to centralise all the data).
• Considers that data-tracking it is essential for her mental wellbeing.

Goals

• Wants an app where all the data is centralised.
• Wants to explore and see causal relationships between symptoms and everyday actions.
• Wants to have a better idea of what is going on in her body.

Storyboards

Steve

Steve is worried about MS Symptoms. He remembers that his doctor recommended him an app. He records all his symptoms in the app. If Steves tracks the symptoms, his doctor will be able to see how Steve feels in that moment. Steve sends the records to his doctor and now he feels safer.

Sarah

Sara just finished her run. She feels more tired than usual. She checks the correlation between heart rate and sleeping hours/medication. She notices a correlation between heart rate and the medication she is taking. She fills in and sends the Side-Effect Check questionnaire to be sure if it because of the treatment's medication.

MoSCoW requirements

The following requirement list went under multiple cycles of scrutiny by both our team and our client to ensure we would deliver a high-quality yet feasible product by the deadline. The list includes the must haves, the should haves and the could haves.

The must haves and should haves are the core functionalities of the app and what needs to be completed first to have a minimum viable product, and the could haves are optional requirements that would be desirable for future stages of the development process before deploying the complete app.

Functional

Non-functional

The functional requirement 7 depends if the hospital has an accessible API or some other internal protocol in order to retrieve the data.

There are also some external constrains regarding where our server is going to be deployed. Initially, our client, told us that it would be the Royal Free Hospital and the University College Hospital, both of them in London. This will affect the infrastructure of the server (RESTful API) and we will need to take into consideration in the development process.

Use cases

Diagram

A use case diagram has to show the interaction between the system (application) and the external users (actors). We believe that this aim has to be achieved in a simple and visual way. From the previous we have extracted the must haves requirements and generated their corresponding use cases, as shown in the following figure.

List

Detailed use cases

PatientAuthenticates

• ID: U_1
• Brief description : Patient authenticates.
• Primary Actor(s) : Patient
• Secondary Actors(s) : RESTful API
• Main flow :
  1. Patient types in the NHS number and a code given by the clinician.
  2. Patient taps the authenticate button.
  3. The system displays a new view, the tracking view.
  4. The system displays the tracking view.
• Extensions
  1. System displays error message because on local input:
     1. Incorrect credentials.
     2. Server-side error. Patient couldn’t be retrieved.

PatientRecordsSymtpom

• ID: U_2
• Brief description : Patient records a set of symptoms.
• Primary Actor(s) : Patient
• Precondition : U_1
• Main flow :
  1. Patient taps the tracking view tab.
  2. Patient taps the symptoms button.
  3. The system displays a table view will all the general symptoms.
  4. Patient taps on a general symptom.
  5. The system displays a table view will all the specific symptoms
  6. Patient taps on a specific symptom.
  7. The system displays a pop-over to set a scale.
  8. Patient slides the slider to set up the scale.
  9. Patient taps set button.
  10. Patient taps on the back button.
  11. Patient taps save button.
  12. The system displays the track
• Extensions
  1. Patient taps on a symptom that is already set:
     1. Patient slides the slider to set a new scale.
     2. Patient taps on the remove button to unset the symptom.
  2. Patient discards the symptom. Patient taps on cancel button.
  3. a) Patient wants to record more symptoms. Repeat from action 5.
  4. b) Patient discards all the saves symptoms. Patient taps on cancel button.

PatientRecordsSideEffect

• ID: U_3
• Brief description : Patient records a side effect check.
• Primary Actor(s) : Patient
• Precondition : U_1
• Main flow :
  1. Patient taps the tracking view tab.
  2. Patient taps the side effect button.
  3. The system displays a questionnaire view 4. according to the drug the patient is on.
  4. Patient taps on an answer for the given question.
  5. Patient taps on next button.
  6. The system displays the next question.
  7. Repeat actions 4,5,6 until there are no more questions.
  8. The system displays the final screen of the questionnaire.
  9. Patient taps on save button.
  10. The system displays the tracking view.
• Extensions
  1. Patient wants to discard the questionnaire. Patient taps on cancel button.

PatientSetsAppointment

• ID: U_4
• Brief description : Patient sets an appointment.
• Primary Actor(s) : Patient
• Precondition : U_1
• Main flow :
  1. Patient taps on the appointments view tab.
  2. The system displays a table with all the appointments.
  3. Patient taps on the add appointment button.
  4. The system displays a pop up with title and date options.
  5. Patient sets a title.
  6. Patient sets a date.
  7. Patient taps on the save button.
  8. The system displays the history view.

PatientModifiesAppointment

• ID: U_5
• Brief description : Patient modifies an appointment.
• Primary Actor(s) : Patient
• Precondition : U_1, U_4
• Main flow :
  1. Patient taps on the appointments view tab.
  2. The system displays a table with all the appointments.
  3. Patient taps on an existing appointment.
  4. The system displays a pop up with the title and the date from the chosen appointments.
  5. Patient edits the details.
     1. Edits title.
     2. Edits date.
  6. Patient taps on the save button.
  7. The system displays the history view.

PatientViewsSymptomHistory

• ID: U_6
• Brief description : Patient visualises the symptoms history.
• Primary Actor(s) : Patient
• Secondary Actors(s) : RESTful API
• Precondition : U_1
• Main flow :
  1. Patient taps the tracking view tab.
  2. Patient taps the history view all button.
  3. The system displays a table with all the previous symptoms recorded.

PatientViewsSideEffectHistory

• ID: U_7
• Brief description : Patient visualises the side effects questionnaires history.
• Primary Actor(s) : Patient
• Secondary Actors(s) : RESTful API
• Precondition : U_1
• Main flow :
  1. Patient taps the tracking view tab.
  2. Patient taps the history view all button.
  3. Patient taps on the side effects tab.
  4. The system displays a table with all the previous side effects questionnaires recorded.

PatientPerformsActiveTask (only on iOS)

• ID: U_8
• Brief description : Patient performs an ActiveTask.
• Primary Actor(s) : Patient
• Precondition : U_1, iOS device
• Main flow :
  1. Patient taps the ActiveTask view tab.
  2. The system displays a table with all the available ActiveTasks to perform.
  3. Patient taps on a specific ActiveTask.
  4. The system displays the ActiveTask view.
  5. The patient follows the set of instructions unit the ActiveTask is finished.
• Extensions
  1. Patient wants to stop the active task. Patient taps on cancel button.

References

• [1] Public Health England. (2016) “Life expectancy at older ages is the highest it’s ever been". [Online] Avaiable at: https://www.gov.uk/government/news/life-expectancy-at-older-ages-is-the-highest-its-ever-been

• [2] The King’s Fund. (2018) "Technology in the NHS". [Online] Avaiable at: https://www.kingsfund.org.uk/projects/technology-nhs

• [3] Amid Ayobi et al.. (2017) [Online] "Quantifying the Body and Caring for the Mind: Self-Tracking in Multiple Sclerosis". [online] Avaiable at: https://uclic.ucl.ac.uk/content/6-news-events-seminars/20170502-ucl-will-have-a-great-presence-at-chi-2017/ayobi.paper.pdf