Design & Implementation

Tech Stack

To choose the tech stack, we have taken into consideration our previous, and carefully evaluating the suitability by referring to the MoSCoW requirements. It is important for us that the language or tools have good documentation and many available open-source resources that we can benefit from.

Frontend: React, Redux and Material-UI

React is a stable, efficient, beginner-friendly JavaScript framework, which makes creating a user-friendly, scalable, and dynamically changing interface simple. There are a ton of useful libraries and resources available, and the documentation is very well written. Since React is modern and popular, there will be no problems for incoming developers to maintain the codebase. Besides, React uses JSX syntax compared to HTML with Vue so it is easier to understand the function of a particular component. This means React does have greater expandability and scalability since reusing JSX is easier as to HTML.


Redux is a small library with a simple, limited API designed to be a predictable container for the application state. It operates in a similar fashion to a reducing function, a functional programming concept. There are three major concepts in Redux: Actions, Store and Reducers. Actions transfer data from the app to Store. Store object would keep the states of the application and provide some methods to access, distribute the states. While Reducer is a function that gets the current state and events of the application and then returns a new state.



In order to optimize the user interface design style, we decided to use Material-UI which is a React UI library that contains a set of high-quality components and demos for building rich, interactive user interfaces. Material-UI is an enterprise-class UI designed for web applications and it also provides us with themes to customize our web application in every detail. With help of this UI design library, we can develop a very clean and polished UI for our users.



Backend: Node.js and Express.js

Our backend is being developed with Node.js. With the fast processing speed and event-driven architecture, it provides fast synchronization and thus the experience of the application. It is also a lightweight tool which means our application can be more scalable.

We have also considered using Django on the backend. However, we went with NodeJS as it aids the simplicity by having both the back end and front end in JavaScript. Also, though Python and JavaScript are both single-threaded, NodeJS has the asynchronous functions, while Django does not. This makes NodeJS a more efficient and convenient solution. From our previous experience, NodeJS is relatively quick to get up and running, and choosing it is a wise decision, given the time constraints of the project.

Express.js is a minimal and open-source Node.js web app framework that enables to structure of a web application to handle multiple different HTTP requests at a specific URL.

With its huge popularity, many useful middleware packages and libraries have been created and maintained by developers. It also provides great flexibility with the ability to add handlers for requests with different HTTP verbs at different URL routes and request processing middleware throughout the request handling pipeline.

Database: PostgreSQL

For storing and managing the data, we decided to use PostgreSQL DBMS. This is because we covered relational databases and SQL in detail during Term 1 of this academic year. We chose PostgreSQL over other relational databases because of many features to protect data integrity and to build fault-tolerant environments in addition to being highly extensible. For example, it comes with a built-in enhancement SE-PostgreSQL which provides additional access controls.

System Architecture Diagram

We have two main types of users, clinicians and patients. They will be making requests and receive responses from the web app. This can be done by them interacting with the frontend UI, for instance, a clinician can click on a button to change the treatment plan for a patient. The backend is where the flow of the application is managed and requests will be interpreted. Then it will interact with the database if data is needed to be stored or retrieved.

Site Map

According to the role of the users, they will see completely different pages after login. If it is a clinician, he can see a clinician version dashboard, which includes all patients he serves, and from there, he can add more patients or check the dashboard of the patient. On the patient dashboard page, the clinician will be able to view the information of the patient as well. On the other hand, a patient will be only allowed to check his dashboard and information.

User Operation Sequence Diagram

When opening the patient dashboard page, data needs to be fetched to generate the graph for the dashboard. Therefore, the patient’s feed and treatment data will be queried from the database. After it is passed to the back-end, the dashboard can be displayed to the user using those data.

During the change treatment plan process, the clinician will be inputting the new treatment data. After that, the back-end will update this info of the patient in the database. Then the new suggested feed will be updated and displayed on the dashboard.

Data Storage ER Diagram

For the structure of our database, the "users" table will be storing the logins of the clinicians and the patients. The "user_perms" contains the permission details of users to determine the control they have on the data. Depending on their roles, clinicians can have multiple patient’s data, storing in the "patients" table, while patients themselves will only store their patient details. The “patients” table also have a relation with "treatments" and "feed". They store the patients feed data and treatment history which are the data we need to display the patient’s dashboard.