Architecture Background - SENG-350-2024-fall/Team-11 GitHub Wiki

Problem Background

The sub-parts of this section explain the constraints that provided the significant influence over the architecture.

Our main architectural constraints fell into two categories. The first category is the ever-present availability, which becomes especially important in a healthcare context, when people need it the most at odd and sometimes dangerous times. The second category revolves around hardware constraints. This includes uptime and server admin access. An outlier constraint is the time constraint, as we had several deadlines related to and not related to the codebase itself.

System Overview

The Mister ED system is designed to help those who are unsure what level of healthcare they need access appropriate care, freeing up Hospitals to focus on more serious patients, reducing wait times, and freeing up time of Triage Nurses and other healthcare workers. It does so by asking the questions needed about current symptoms, relevant medical history, and allowing for patients to be less anxious as they can track the status of their prescriptions, where they can pick them up, and reassurance that their health is in the best and most appropriate hands possible.

Context

Software architecture set up the guidelines and basis for all actual code, as well as what external components were used to aid the website along. It is the groundwork laid before the first line of code has even thought about. So far, that looks like having planned how pages, different user types, and all software and hardware should work together before we begin working on the implantation. One example of how patients, caregivers, and Mister ED work together is available for viewing below, or in more detail here.

As the Mister ED system grows, we will have to plan for scaling up. This will not be done until the initial project is complete. This can look like scaling up the database, changing how symptom inputs are processed, having multiple servers running to balance the load, or so on. This will be significantly less planning as to how the systems will interact and more to do with planning for failure of different components, such as having backup databases and having multiple servers where the Mister ED website will be hosted.

Driving Requirements

This section outlines the core functionalities for each user role within the system. These requirements define the key actions each user should be able to perform.

General User Functions

• Account creation for new users.
• Ability to contact support.
• Secure login and logout functionality.
• Profile management: viewing, editing, and deleting user details.
• Receiving and viewing important system notifications.

Patient Requirements

• Requesting and completing a virtual triage to assess their health.
• Viewing the results of their triage and associated recommendations.
• Checking available capacity at nearby Emergency Departments (EDs).
• Accessing their health history and appointment schedule.

Emergency Department (ED) Requirements

• Logging into the system to view patient registrations and triage results.
• Logging out of the system when done.
• Managing patient flow and prioritizing care based on triage data.
• Providing real-time updates on ED capacity and patient status.
• Communicating with patients to confirm appointments and provide updates.
• Generating reports on patient care and ED performance.

Primary Care Clinic (GP) Requirements

• Accessing patient registrations and triage results upon login.
• Logging out when finished.
• Receiving patient referrals and providing appropriate care.
• Reviewing patient history and making informed care decisions.
• Updating patient records after providing care.
• Coordinating follow-ups and communications with the ED.

Nurse Requirements

• Viewing patient registrations and triage results after logging in.
• Assisting with virtual triage assessments as needed.
• Following up with patients to ensure they follow triage recommendations.
• Scheduling in-person appointments for patients over the phone.
• Updating medical records and checking on patient wait times.

Chemist Requirements

• Secure login to the system for access to patient prescriptions.
• Logging out once tasks are complete.
• Receiving prescriptions and dispensing medication to patients.
• Offering advice on the use of over-the-counter medications.
• Filtering and organizing prescriptions based on urgency and status.
• Coordinating with GPs and EDs on patient prescriptions and treatment plans.

Admin Requirements

• Managing system access through secure login and logout.
• Viewing, adding, and managing user accounts.
• Disabling or deleting user accounts when necessary.
• Monitoring system activities via audit logs.
• Updating system settings, including triage protocols, user roles, and notification preferences.

Primary quality attributes include:

• Reliability: Users must not have issues accessing the site due to login errors or other issues
• Availability: Users must be able to access MisterED at all times and with prompt service
• Speed: Users must be able to get answers from MisterED quickly to ensure prompt medical attention
• Correctness: Users not see only necessary information, and all necessary information

Primary design constraints include:

• Infrastructure: We have had issues with the database, we must ensure it is properly accessible and available at all times
• Privacy laws: The system must not violate The Personal Information Protection and Electronic Documents Act (PIPEDA)

Solution Background

The sub-parts of this section provide a description of why the architecture is the way that it is, and a convincing argument that the architecture is the right one to satisfy the behavioural and quality attribute goals levied upon it.

Architectural Approaches

Five design patterns were used, see more detail here, and they were used in order to make the Mister ED website easier to use, understand, and debug. We made the systems in isolation, interacting with each other via information in the database. The biggest focuses were upon Template Design, State Pattern, and Command Design Pattern. Template Design was used for any pages with input, making them clean, consistent, and easy to understand. It made input very easy to read and break down, and output easy to format, making it comprehensible at a glace to the user. State Pattern and Command Design Pattern were used hand in hand to isolate structures, allow for easy planning of potential user paths, and customization of each object used to facilitate these user paths and states.

These design approaches and patterns were chosen in order to put the majority of the work on the database, and to allow for several different user types with minimal amounts of pages needed in order to succeed. The Mister ED system is not excessively complicated, but needs to take several inputs and format outputs for different user types. Therefore, we had a lot of freedom in which approaches to take, putting our focus on making database connections clean, quick, easy, and reliable. We wanted to eliminate as many potential sources of error to make a seamless experience for all users. We did this by focusing on ways to streamline data collection as that could be our greatest source of errors.

We did not have many rejected architecture decisions. The only ones rejected were a different DB structure of putting everything in one table and rollback as an availability tactic. The rejected DB structure would have been more complicated to use, which could lead to unexpected errors and more work, both of which we wanted to avoid. Additionally, more information than necessary would be available at multiple stages. This was due to both the strongest ideal of minimizing errors and due to time constraints as students. Rollback as an availability tactic was rejected due to time constraints and due to the fact that it could potentially erase or overwrite patient data, leading to missing patient care. This would be unacceptable, and was therefore rejected.

Analysis Results**

No major feedback provided from Group 2 and Group 13. Both cited adequate C&C views, and suggested updates to our old database plan, which were implemented. One group focused on our views being lacking, which were then entirely rewritten. Overall, very simple analysis, and results adequately and rapidly fixed.

Mapping Requirements to Architecture

Please see mapping between views, as it covers all details far better than this section ever could.

Extras

Please find all references, glossary terms, and acronyms at the pages below:     SAD homepage     Referenced Materials     Glossary and Acronyms