Project Requirements

Background of the project



At the moment, the medical staff is facing problems of time management, while trying to keep track of patients or to discuss their diagnostics. This is why, the main goal of the our project is to provide tools for medical professionals and researchers that can aid them in diagnostic and analytics processes through the use of online platforms.
We are delighted that our work is contributing to a better medical system and we aim to create an unique health platform for University College Hospital and its patients.

Clients

Our client is Dr. Navin Ramachandran, representing University College Hospital and the P.E.A.C.H(Platform for Enhanced Analytics and Computational Healthcare) Project. During development, we were kindly sponsored by Microsoft to make sure that we have all the resources to accomplish the full potential of the project.

Problem Statement

The features we had to implement are a crucial part of a healthcare platform and we believe their impact will be valuable for both our client and the people using them. Currently, our team is working on the implementation of three different components for the PEACH web platform:

  • the login and role based access control system for managing user authentication and permissions on the website;
  • an internal messaging system for communication enhancement;
  • the collaborative document editing which allows real-time online collaboration between doctors.



Requirement gathering



Collecting requirements

One of the first steps in the development of our project was to collect the requirements for our future platform. The main way to accomplish our task was to set up several meetings with our client, Dr. Navin Ramachandran, and to gather as much information as possible about the features that the final product should have. After understanding the main concepts of the new platform, we iterated various MoSCoW analysis versions, which were defined after more discussions with our main client.

Apart from discussing with our client, we also focused a lot on conducting online research, as this was the main method to find out what tools we can use and what requirements are feasible. We certainly identified tools to use (see Research page) and understood exactly what we can achieve in the given time. This helped us in presenting real facts and examples to Dr. Navin when establishing the requirements list and their priorities.

To better understand the needs of the potential users for our tools, we proceeded with creating various personas, storyboards and use cases for our project, which will be presented shortly. They were really helpful in figuring out how users might use our tools and why, which was highly valuable in coming up with our requirements list and agreeing on it with the client.

Finally, a last method to clearly gather all the requirements was to get feedback on our work from different people, from friends and colleagues to TAs and supervisors of the project. Since they might benefit from using the PEACH platform in the future and since healthcare is something that everyone cares about, they provided us with clear and specific views about what they would like / not like to see when using it.


Personas

Typical users









Storyboards




1. An admin should be able to create roles and accounts for users.
2. Users can log in according to their roles (administrator, senior clinician, junior clinician, clerical, patient).
3. Once logged in, users can access the internal messaging system (chat) or the collaborative editing tool (for the patient notes).
4. The messaging system is available for medical staff and patients.
5. The collaborative editing tool is available for all medical staff in order to write notes in real-time on the patients' health condition.
6. Medical staff can access all the pads for all patients.




MoSCoW requirement list


Authentication - RBAC

Requirement Description Priority Type
A1 Good security Must Have Functional/Non-functional
A2 Registration started by admin and sent by email invitation Must Have Functional
A3 Only admins can start a new registration Must Have Functional
A4 Integration with RBAC / ABAC Must Have Functional
A5 Forgotten password Must Have Functional
A6 Provide users with specific role Must Have Functional
A7 Admins can change roles if necessary Must Have Functional
A8 Roles provide different permissions and page flow on the website Must Have Functional
A9 Support for different roles in different apps Must Have Functional
A10 Change password in or other features in an user dashboard Should Have Functional
A11 Users can request registration or role change Should Have Functional
A12 Blockchain like authentication / IOTA technology for authentication, etc. Could Have Functional
A13 Simple registration option where user can directly sign-up Won't Have Functional



Internal Messaging

Requirement Description Priority Type
IM1 Functional text messaging system between clinicians and patients Must Have Functional
IM2 Functional text messaging system among clinicians Must Have Functional
IM3 Group chat inside the web app Must Have Functional
IM4 Storing history in a database Must Have Functional
IM5 Different access permissions Must Have Functional
IM6 Access to patient records inside chat Should Have Functional/Non-functional
IM7 Sending images and files Should Have Functional
IM8 Real time Should Have Functional
IM9 Offline access to messages Should Have Functional
IM10 Scalable to store terabytes. Should have Functional
IM11 Videochat Could Have Functional
IM12 Integration with the ChatBot Could Have Functional/Non-functional
IM13 Flexibility for creating mobile apps Could Have Functional
IM14 Messaging between patients Won't Have Functional



Collaborative Editing

Requirement Description Priority Type
CE1 Multiple users must be able to edit the data simultaneously Must Have Functional
CE2 The entered text must update in real time for all users Must Have Functional
CE3 The input field must be available as a component that can be embedded on any form Must Have Functional
CE4 A submit button which stores the input in a DV_PARSABLE data type field in openEHR Must Have Functional
CE5 Text formatting Should Have Functional
CE6 Input should be saved with formatting Should Have Functional/Non-functional
CE7 When a form is reopened, the previously entered text should be reloaded Should Have Functional
CE8 Marker indicating the cursor position of other concurrent users Could Have Functional
CE9 No need to see the previous editing history Won't Have Functional/Non-functional



Use cases


1. 2. 3. 4. 5. 6.
Application Authentication System Authentication System Messaging System Messaging System Document Editing Tool Document Editing Tool
Name Logging In Forgot password Sending Direct Message Sending Group Message Changing User Details Writing text
Description This is where the users are entering details and log in onto the platform This is the case when users starts the process of setting up a new password when he forgot the old one This is how a user can send a direct message to someone else (either text or file) This is how a user can send a group message (either text or file) This is how users can set their color highlight preferences This happens when a user is writing text within a document
Primary Actor User (App in browser) User (App in browser) User (App in browser) User (App in browser) User (App in browser) User (App in browser)
Precondition User reaching the login page User not remembering password and reaching login page User logged in and using the messaging tool User logged in and using the messaging tool User logged in and using the doc editing tool User logged in and using the doc editing tool
Trigger User entering his details and submitting them User click the “Forgot Password button” User creates a new direct chat or enters an existing one User creates a new group chat or enters an existing one User enters a pad and clicks the customization menu User enters a pad and starts writing
Basic Flow User opens the web platform. If he is not authenticated, he is redirected to the login page where he enters his details and submits them. Then, the server validates them and allows his access to the tools on the platform User reaches the login page but he does not remember his password. He clicks the specific button and is redirected to a page where he has to enter his email. If email is matching a current account, an email with a reset link is sent. When he access the link from his email, he is provided access to a page where he can reset the password. After submitting the new details, he can use his password again User opens the chat and enters (creates) a direct chat with another user. He inputs a test message (or a file) and clicks the send button. The message is sent and appears for both users User opens the chat and enters (creates) a group chat with another user. He inputs a test message (or a file) and clicks the send button. The message is sent and appears for all group users User opens the doc editing tool. He then opens the customization tab, where he can set the colors in which his text is highlighted to be differentiated from other text. Color change appears for all users. User opens the editing tool and starts writing. Everything he does appears in real time for others. He can also change text options (font, colour, etc.) and others can see it also in real time.
Alternate Flows * User inserts wrong details - error message
* User does not remember his password - see user case 2
* User exits the app
* User does not receive email - he has to try again
* User exits the app
* User does not send a message
* File size is too large
* User does not send a message
* File size is too large
* User does not set a colour
* User writes without a predefined colour
* User does not input anything
* User writes without modifying text