Milestone 4
See the following
- Template Description: https://docs.google.com/document/d/18RJKBFbwPJ9mKok0bNsooNefcqQ7-rrliirjLcuswyQ/edit?usp=sharing
- Example 1: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=146280205
- Example 2: https://wiki.sei.cmu.edu/confluence/display/SAD/The+Java+Pet+Store+SAD
TODO:
- Section 1
- Section 2
- Section 4
- Section 5
- Section 6
- Section 7
This wiki describes the architecture of the Mister ED application. Mister ED is a web application which allows users to view wait-times for emergency rooms, add them to emergency room wait lists, and receive triage either in-app or from a medical professional.
This document is currently managed and maintained by the original contributors to the Mister ED application.
The Mister ED architecture is designed to serve the needs of doctors, nurses patients and emergency rooms. This includes providing doctors and nurses with the ability to add/remove people from wait lists, administer triage and provide informed feedback to patients. Patients are provided with accurate information about emergency room wait times and given the option for remote triage. This document describes these aspects in the form of views with mapping between the views.
This document is organized by the following sections:
- Documentation Roadmap: Outlines this document and it's organization.
- Architecture Background: Provides background and context to the architecture of Mister ED.
- Views: Shows and describes view of the architecture
- Mapping Between Views: Shows how aspects of one view relate to another
Our primary stakeholders for the purpose of this document are future maintainers of Mister ED.
The Use Case View showcase the flow of the software between several key stakeholders relevent to the usage of our software, including users, maintainers, etc.
Testers and Integrators who will rely on this module to conduct their work.
The customers who have concerns on how the program operates and how information are processed.
Implementers who need to have a brief idea on how the program is supposed to run like.
Actors
This include users of the program, like patients and doctors, also the databases associated with the information of these users. Actors cannot perform actions that are not in their pre-designated path as specified by the full diagram.
Use Cases
This include Use Cases of the program, actions that can be performed by the actors. Certain Use Cases can only be performed by certain actors. For example, only a doctor can be visited by a patient should it is determined that a patient need to visit a doctor.
The View will be represented in a diagram that is drawn using the application draw.io.
a) The union of all elements' functionalities will represnt the all possible ways the system can be used in.
b) Actors and Use Cases will be executed in the pre-designated path as show in the Diagram, no other form will be allowed.
c) Major functionality is only represented or provided by one element.
N/A
The Component and Connector View showcase the connection and relations between major functionalities of the program and each subsystems.
Implementers who will be implementing the program and need more technical representation of the inner workings of the program.
Testers who will be testing the program and need a goood understanding of how the program works.
System build engineers who need to know how each component of the system connect or relate with other elements in order to build a working system.
Database
This element stores all necessary information in order for the program to properly function. This is accessible to all microservices but none of the subsystems.
Microservices
These elements represet the major functionalities or the software. Each microservices will have their own unique subsystems that they connect and have access to but all microservices will be able to access the database.
Subsystems
These subsystems communicate with external component using REST-API calls, each representing an outcome for the patient after they use one of the microservices.
The View will be represented in a diagram that is drawn using the application draw.io.
a) The union of all elements' functionalities will represnt the all possible ways the system can function in, when no fault arises.
b) Major functionality is only represented or provided by one element.
N/A
Section 3 of this SAD contains one view for each viewpoint listed in Section 1.5. Each view is documented as a set of view packets. A view packet is the smallest bundle of architectural documentation that might be given to an individual stakeholder. Each view is documented as follows, where the letter i stands for the number of the view: 1, 2, etc.:
Section 3.i.1: View description.
This section describes the purpose and contents of the view. It should refer to (and match) the viewpoint description in Section 1.5 to which this view conforms.
Section 3.i.2: View packet overview.
This section shows the set of view packets in this view, and provides rationale that explains why the chosen set is complete and non-duplicative. The set of view packets may be listed textually, or shown graphically in terms of how they partition the entire architecture being shown in the view.
Section 3.i.3: Architecture background.
Whereas the architecture background of Section 2 pertains to those constraints and decisions whose scope is the entire architecture, this section provides any architecture background (including significant driving requirements, design approaches, patterns, analysis results, and requirements coverage) that applies to this view.
Section 3.i.4: Variability mechanisms.
This section describes any architectural variability mechanisms (e.g., adaptation data, compile-time parameters, variable replication, and so forth) described by this view, including a description of how and when those mechanisms may be exercised and any constraints on their use.
Section 3.i.5: View packets.
This section presents all of the view packets given for this view. Each view packet is described using the following outline, where the letter j stands for the number of the view packet being described: 1, 2, etc.
Section 3.i.5.j.1: Primary presentation.
This section presents the elements and the relations among them that populate this view packet, using an appropriate language, languages, notation, or tool-based representation.
Section 3.i.5.j.2: Element catalog.
Whereas the primary presentation shows the important elements and relations of the view packet, this section provides additional information needed to complete the architectural picture. It consists of the following subsections:
Section 3.i.5.j.2.1: Elements. This section describes each element shown in the primary presentation, details its responsibilities of each element, and specifies values of the elements’ relevant properties, which are defined in the viewpoint to which this view conforms.
Section 3.i.5.j.2.2: Relations. This section describes any additional relations among elements shown in the primary presentation, or specializations or restrictions on the relations shown in the primary presentation.
Section 3.i.5.j.2.3: Interfaces. This section specifies the software interfaces to any elements shown in the primary presentation that must be visible to other elements.
Section 3.i.5.j.2.4: Behavior. This section specifies any significant behavior of elements or groups of interacting elements shown in the primary presentation.
Section 3.i.5.j.2.5: Constraints: This section lists any constraints on elements or relations not otherwise described.
Section 3.i.5.j.3: Context diagram. This section provides a context diagram showing the context of the part of the system represented by this view packet. It also designates the view packet’s scope with a distinguished symbol, and shows interactions with external entities in the vocabulary of the view.
Section 3.i.5.j.4: Variability mechanisms. This section describes any variabilities that are available in the portion of the system shown in the view packet, along with how and when those mechanisms may be exercised.
Section 3.i.5.j.5: Architecture background. This section provides rationale for any significant design decisions whose scope is limited to this view packet.
Section 3.i.5.j.6: Relation to other view packets. This section provides references for related view packets, including the parent, children, and siblings of this view packet. Related view packets may be in the same view or in different views.
N/A
N/A
The Mister Ed system is a software solution designed to address the issues of overcrowding and overload in Emergency Departments (EDs). This system aims to provide a more efficient process for individuals who believe they require medical attention and are considering a visit to the ED. Below is a description of the system:
-
User Registration: Individuals who feel the need to visit an ED can access the Mister Ed system through the web. They will be required to register virtually, providing their basic information and medical history.
-
Virtual Triage: After registration, users undergo a "virtual triage" process. During this phase, a series of questions and assessments are conducted remotely to evaluate the severity of the user's condition.
-
Triage Outcome: Based on the virtual triage results, users are given recommendations. These recommendations may include:
- ED Visit: If the system determines that an ED visit is necessary due to the severity of the condition, users are instructed to visit the ED and are added to a virtual wait list based on priority.
- Alternative Care: For less severe cases, users are given alternative healthcare options, such as visiting a primary care clinic (General Practitioner or GP), taking over-the-counter medication, or contacting a nurse or clinician hotline via phone or internet for further guidance.
-
Remote Waiting: Patients who are advised to visit the ED are placed in a virtual queue and can safely wait are allowed at home until it is their turn to see a doctor.
-
Notification and Updates: The Mister Ed system manages the virtual queue and notifies patients when it's their turn to be seen by medical staff at the ED.
The primary objective of this application is to address the challenge of determining the required medical attention based on a patient's symptoms. Additionally, it offers a wait-at-home solution for individuals requiring emergency room (ER) visits. The application incorporates a waitlist feature, allowing patients to register and check their position in the queue, including the number of individuals ahead of them.
For healthcare professionals, the solution streamlines the process by providing swift access to patient symptoms, aiding in the efficient narrowing down of potential diagnoses. This ensures doctors can quickly and accurately assess the patient's condition and determine the appropriate course of action.
The architectural approach for this software engineering project was centered around modularity using separate microservices, as well as architecture that promotes flexibility and maintainability. The system is designed to consist of components that communicate through well-defined APIs, facilitating easy integration of new features and accommodating future enhancements.
Key architectural decisions include:
-
Microservices: Breaking down the system into the three independently deployable microservices (Waitlist, Triage, Authorization).
-
Logging: Logging all events using built in functionality.
-
Backups: Creating a backup of the database to insure safety.
Several comprehensive analyses were conducted to ensure the strength of our chosen architectural approaches:
-
Performance Analysis: We tested all the functionality between the frontend and backend to make sure there were no bugs.
-
Database backup analysis: We made sure the backup database was functioning correctly.
The architectural approaches chosen and analysis results met the requirements of our project and ensured comprehensive coverage.
The current version of the software reflects a culmination of iterative improvements based on past issues discovered. Changes incorporated include:
- Refinement of microservices to fix potential bugs
- Implementation of second database
The project has been created with modularity in mind by creating separate microservices that communicate with each other as needed, as well as using well-defined APIs to facilitate easy reusability.
Patient
Actor - The patient, should be able to perform various actions such as: view the current wait-time, register/sign-in, enter the waitlist, and complete a triage form.
Patient Load Database
Actor - A relational database that will store all the necessary information for MisterED to work.
ER Doctor
Actor - Emergency Room Doctor, will use MisterED to manage the waitlist and serve patients.
Nurse
Actor - Nurse, depending on the outcome from MisterED's triage, they will perform further diagnosis through a hotline.
GP
Actor - General Practitioner, depending on the outcome from MisterED's triage, patients will be asked to visit their GP before visiting urgent care.
Authorization
Use case - Microservice to handle login and registration.
Login
Use case - Sign into our application using the authentication microservice.
Registration
Use case - Register a new patient using the authentication microservice.
View wait-time
Use case - An action from the authentication microservice.
Triage
Use case - icroservice that will determine whether a patient should really visit the ER.
Enter waitlist
Use case - Outcome from the triage microservice.
ER Room
Use case - Outcome from the triage microservice.
Hotline
Use case - Outcome from the triage microservice.
N/A
N/A
database
This is a relational database (PostgresSQL 15) that stores all the information necessary for MisterED to work, e.g. waitlist information and triage results. It also stores information about users for authentication and authorization.
Auth
The authentication microservice. It communicates with external components using REST API calls - used to control access the Triage and Waitlist microservices.
Triage
The triage microservice. It communicates with external components using REST API calls - it processes the triage forms from patients and call other subsystems.
<subsystem> GP
A subsystem from triage. It communicates with external components using REST API calls - used when a patient must visit their GP.
<subsystem> Hotline
A subsystem from triage. It communicates with external components using REST API calls - used when a patient must be further diagnosed.
<subsystem> Over the counter meds
A subsystem from triage. It communicates with external components using REST API calls - used when a patient should take over the counter meds.
<subsystem> You're Okay!
A subsystem from triage. It communicates with external components using REST API calls - used when the patient has no major symtoms/conditions.
<Waitlist>
The waitlist microservice. It communicates with external components using REST API calls - it allows medical staff to the manages the ED queue; it also allows patients to view estimated waittimes and enter the ED queue.
<subsystem> Enter Waitlist
A subsystem from waitlist. It communicates with external components using REST API calls - used when entering patients to the queue.
<subsystem> View ED Queue
A subsystem from waitlist. It communicates with external components using REST API calls - used for viewing the current waitlist and estimating the wait times.
<subsystem> ER
A subsystem from waitlist. It communicates with external components using REST API calls - used to notify patients to visit the ER when its their turn.
N/A
N/A
The diagram below depicts our current deployment structure. Our microservices were built using Python and the Flask framework. The frontend was built using JavaScript and the React framework.
First, we created a database using DigitalOcean's Managed Databases, more specificly the PostgresSQL - a fully managed, high performance database cluster service.
Next, when the development was complete, we created a Dockerfile for each of our microservices. Once we were certain that our images were running as expected, we deployed them to DigitalOcean Container Registry.
Then, we creted a web-app for each of the docker images using DO's App Platform.
<<device>> Patient's device
Represents the device used by a regular user.
<<device>> Doctors's device
Represents the device used by the medical staff.
<<webrowser>>
Represents any browser that is used to access our application.
<<device>> Digital Ocean App Platform
App Platform is a Platform-as-a-Service (PaaS) offering that allows developers to publish code directly to DigitalOcean servers without worrying about the underlying infrastructure [ref].
<<artifact>> docker image
A Docker image deployed to a private DigitalOcean container registry.
<<execution environment>> Authentication
A DigitalOcean App deployment using a <<artifact>> docker image that contains our authentication microservice.
<<execution environment>> Triage
A DigitalOcean App deployment using a <<artifact>> docker image that contains our triage microservice.
<<execution environment>> Waitlist
A DigitalOcean App deployment using a <<artifact>> docker image that contains our waitlist microservice.
<<execution environment>> Frontend
A DigitalOcean App deployment using a <<artifact>> docker image that contains our frontend.
<<device>> Digital Ocean Database Server
DigitalOcean’s Managed Database - fully managed, high performance database cluster service [ref].
<<database system>> PgSQL Server
This is a relational database (PostgresSQL 15) that stores all the information necessary for MisterED to work, e.g. waitlist information and triage results. It also stores information about users for authentication and authorization.
<<schema>> Account
The table that stores information about all user's accounts.
<<schema>> Patient
The table that stores information about patients, e.g., name, age, address, and phone.
<<schema>> Triage
The table that stores information about patients' completed triages and thier results.
<<schema>> Waitlist
The table that stores information about the current ED waitlist.
N/A
Instead of relying on Docker images for deployments, we could make use of Digital Ocean App Platform direct code deployment feature - this feature allows us to simply push code into a repo and have it spun into a web-app, thus not having to worry about the underlying infrastructure. However, having docker images on hand allows us to quickly switch cloud providers if needed - this works because most, if not all, provide a service where we can run virtual machines and docker images instantly.
Account
The Account schema, stores information about all user's accounts.
| Column | Attribute | Data Type | Notes |
|---|---|---|---|
account_id |
PRIMARY KEY | SERIAL | Account ID |
username |
VARCHAR(255) NOT NULL | Account username, used for login. | |
password |
VARCHAR(255) NOT NULL | Account password, used for login. | |
is_doctor |
BOOLEAN | Flag used to determine users' permissions |
Patient
The Patient schema store information about a patient, e.g., name, age, address, and phone.
| Column | Attribute | Data Type | Notes |
|---|---|---|---|
| patient_id | PRIMARY KEY | SERIAL | Patient ID |
| account_id | FOREIGN KEY REFERENCES Account(account_id) | INT NOT NULL | Account ID |
| username | VARCHAR(255) NOT NULL | Account username | |
| name | VARCHAR(255) NOT NULL | User's name | |
| age | INT NOT NULL | User's age | |
| address | VARCHAR(255) NOT NULL | User's address | |
| phone | VARCHAR(255) NOT NULL | User's phone number | |
| created_timestamp | TIMESTAMPTZ NOT NULL | When the user was registered |
Triage
The Triage schema stores information about patients' completed triages and their results.
| Column | Attribute | Data Type | Notes |
|---|---|---|---|
| triage_id | PRIMARY KEY | SERIAL | Triage ID |
| patient_id | FOREIGN KEY REFERENCES Patient(patient_id) | INT NOT NULL | Patient ID |
| account_id | FOREIGN KEY REFERENCES Account(account_id) | INT NOT NULL | Account ID |
| symptom_1 | BOOLEAN | Specifies whether the patient has symptom 1 | |
| symptom_2 | BOOLEAN | Specifies whether the patient has symptom 2 | |
| symptom_3 | BOOLEAN | Specifies whether the patient has symptom 3 | |
| condition_1 | BOOLEAN | Specifies whether the patient has condition 1 | |
| condition_2 | BOOLEAN | Specifies whether the patient has condition 2 | |
| condition_3 | BOOLEAN | Specifies whether the patient has condition 3 | |
| outcome | VARCHAR(255) | The outcome from the triage | |
| created_timestamp | TIMESTAMPTZ | When the triage form was completed |
Waitlist
The Waitlist schema stores information about the current ED waitlist.
| Column | Attribute | Data Type | Notes |
|---|---|---|---|
| waitlist_id | PRIMARY KEY | SERIAL | Waitlist ID |
| account_id | FOREIGN KEY REFERENCES Account(account_id) | INT NOT NULL | Account ID |
| patient_id | FOREIGN KEY REFERENCES Patient(patient_id) | INT NOT NULL | Patient ID |
| booked_dt | TIMESTAMPTZ | When the patient entered the waitlist |
N/A
The Account and Patient tables could be merged into a single table. This would decrease the performance overhead of registering new accounts because we'd be able to write all information in a single SQL operation instead of two.
| C&C View | Deployment View |
|---|---|
database |
<<database system>> PgSQL Server |
Auth |
<<execution environment>> Authentication |
Triage |
<<execution environment>> Triage |
<Waitlist> |
<<execution environment>> Waitlist |
Patient |
<<device>> Patient's device |
ER Doctor |
<<device>> Doctors's device |
| Use Case View | C&C View |
|---|---|
Patient |
N/A |
Patient Load Database |
database |
ER Doctor |
<subsystem> ER |
Nurse |
<subsystem> Hotline |
GP |
<subsystem> GP |
Authorization |
Auth |
Login |
Auth |
Registration |
Auth |
View wait-time |
<subsystem> View ED Queue |
Triage |
Triage |
Enter waitlist |
<subsystem> Enter Waitlist |
ER Room |
<subsystem> ER |
Hotline |
<subsystem> Hotline |
| Data Model | Deployment View |
|---|---|
account_id |
<<database system>> PgSQL Server |
address |
<<database system>> PgSQL Server |
age |
<<database system>> PgSQL Server |
booked_dt |
<<database system>> PgSQL Server |
condition_1 |
<<database system>> PgSQL Server |
condition_2 |
<<database system>> PgSQL Server |
condition_3 |
<<database system>> PgSQL Server |
created_timestamp |
<<database system>> PgSQL Server |
is_doctor |
<<database system>> PgSQL Server |
name |
<<database system>> PgSQL Server |
outcome |
<<database system>> PgSQL Server |
password |
<<database system>> PgSQL Server |
patient_id |
<<database system>> PgSQL Server |
phone |
<<database system>> PgSQL Server |
symptom_1 |
<<database system>> PgSQL Server |
symptom_2 |
<<database system>> PgSQL Server |
symptom_3 |
<<database system>> PgSQL Server |
triage_id |
<<database system>> PgSQL Server |
username |
<<database system>> PgSQL Server |
Rodrigo:
- Section 3 - Views
- Seciton 4 - Mapping Between Views
- Fix bugs in Auth, Triage, and Waitlist microservices (1, 2, 3)
- Create frontend for registration [ref] and triage [ref]
- Add fix to display proper errors in frontend (1, 2)
- Deploy frontend to DigitalOcean [ref]
Ethan:
- placeholder
Amann
- Architectural Background
- Frontend bug fixes
- Frontend error handling on wait list triage
- Role based features on Frontend
Jacob
- Architectural approaches
- Analysis results,
- Requirements coverage,
- Summary of background changes reflected in current version
- Product line reuse considerations
Tim
- placeholder