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

Problem Background

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

System Overview

The goal of MisterED is to reduce and control the load on the Emergency Department. MisterED will achieve this by providing real-time triage support from online medical professionals and offering users more flexibility with being able to wait for assistance and direction from the comfort of their own home. For this Milestone we have made the assumption that the MisterED system is to be implemented in British Columbia and supports local users by being able to log in with the BC Services Card app.

The MisterED application will show a disclaimer on the main page directing people experiencing life-threatening symptoms or injuries to immediately contact 9-1-1/EMS for quicker emergency support which persists on every page.

There are 5 primary actors that we have identified will use or interact with the MisterED system in their own respective ways:

  • Users / Patients
  • Online Medical Professionals
  • In-Person Medical Professionals
  • First Responders / EMS
  • System Administrators

General users will log into the MisterED application using their BC Services Card app, which improves the service that MisterED can offer since users with a valid BC Services Card have their health information stored in the Medical Information Database, meaning they won't have to input or update their medical history or conditions. Once logged in, a user will be able to edit their profile, see nearest ED and ED wait times, undergo a virtual triage process, view their place in the ED queue, and receive a notification when it is their turn to visit the ED.

The primary support for users that MisterED focuses on is the virtual triage, since diagnosing patients correctly and helping them is a priority. Once a user has selected to undergo a virtual triage, they will be asked to input their symptoms and will henceforth considered a Patient. The patient's case will be placed in a queue for the Online Medical Professionals to view and triage, and if the system detects the patient has inputted severe but not life-threatening symptoms their case will jump to the front of the queue so they can be triaged as soon as possible. Once triaged, patients will receive follow-up directions and be placed in an ED priority-based queue by the Online Medical Professional. Patients will receive a notification from once it is their turn to visit the ED. They will also be able to update their symptoms and remove themselves from the queue if their symptoms are not critical or require urgent medical attention.

The Online Health Professionals, or as they are called here, Online Nurses, are primarily responsible for triaging patients based on their symptoms and relevant medical history. After they have logged in they will be able to pick a patient from the triage queue and treat their case accordingly by providing directions for them to follow while they wait. The nurse is responsible for sending the patient a notification when it is their turn to visit the ED, however if the patient has been waiting at the front of the queue for more than 15 minutes the system should notify them automatically since the nurses are likely too busy. The nurse is also able to escalate the patient to an emergency First Responder should the patient's condition be severe enough, which will provide them with the patient's symptoms and medical history before they arrive.

The In-Person Medical Professionals, which will be called Healthcare Professionals, represent the doctors or nurses that work in the ED. They will be able to view the patient's symptoms and medical history when they are in the queue, and will also be able to add patients to the ED queue when new patients walk into the ED. When conducting in-person evaluations the nurses and doctors will first assign the patient from the queue to themselves, thus removing them from the queue and updating it. Since the physical evaluation by the professional will be more accurate than the online-triage version, they will be able to update the triage report and also submit the patient's medical report once they are discharged.

In the event that a patient's symptoms are severe enough the Online Nurse will be able to escalate the patient to First Responder's care and they will be notified instantly. The First Responders will be able to view the patient's triage report ahead of time and reach out to establish contact with them to check-in with the patient and gather any additional information. Should the First Responders determine they need to physically assist the patient, MisterED will provide the First Responders with the patient's GPS location and check ED wait times so they can determine which ED to transport the patient to. They will also be able to modify the patient's triage report with more accurate triage reports and notify the ED nurses and doctors ahead of time that they are bringing in a high-priority patient with the updated triage status.

Lastly, the System Administrators will act as the primary actor when it comes to record modification and tech-related support for both Users and Medical Professionals. The Administrators will be in charge of managing User and Employee accounts which includes creating, modifying, or deleting accounts and their permissions. For IT support, Administrators will be able to view service tickets submitted by staff regarding account permissions or other issues they may encounter. This will follow the typical process where they will accept the ticket, communicate with the reporting employee, diagnose and fix the issue / provide a solution, and then close the ticket. Administrators will also be able to modify existing records when Healthcare Professionals submit a record modification. Lastly, one of the most important tasks the Administrators will take on will be regular server updates/maintenance and data backup. The regular server updates will be scheduled during regular system load dips to avoid as much disruption as possible while ensuring that the MisterED system is providing the best possible service to Users/Employees, and the data backups will ensure that User/Employee data is stored securely with no data loss.

Context

Medical Information System To Enhance Resources for Emergency Departments - Mister Ed

Emergency Departments (EDs) are often crowded and overloaded. The Mister Ed system will be designed to help with this situation. People who feel that they need to visit an ED will be able to use Mister Ed to understand the current load of EDs in their area. They will be able to register virtually and undergo a "virtual triage" to determine whether they really should visit the ER or potentially follow another course of action, like go to a regular primary care clinic (GP), take over the counter medication, or contact the nurse/clinician hotline over the phone or Internet. Patients who can safely be triaged virtually but still need to visit the ED can wait from the comfort of their home and will be notified to come in when it is time to see them. Patients who need to be triaged in person are asked to attend in person but can then return to their home until it is time to see them.

Driving Requirements

This section lists the functional requirements quality attributes and design constraints.

Functional Requirements

  1. User Authentication

    • Patients must be able to log in using their BC Services Card app.
    • Staff must be able to log in using their credentials.

  2. Virtual Triage

    • Users can input symptoms to undergo a virtual triage process.
    • Online Nurses must assess and prioritize cases based on severity.
    • Severe cases should automatically jump to the front of the queue.
    • Patients must be notified of triage results and follow-up directions.

  3. Queue Management

    • Patients can view their place in the ED queue but not other patients’ positions.
    • Online Nurses and In-Person Healthcare Professionals can update the queue.
    • The system must notify patients when it is their turn to visit the ED.
    • Patients can remove themselves from the queue.

  4. Symptom and Profile Management

    • Users can update their symptoms and profile information.
    • Online and In-Person Healthcare Professionals can view and update a patient’s medical history and triage reports.
    • System administrator’s can access and alter all records.

  5. Emergency Escalation

    • Online Nurses can escalate critical cases to First Responders.
    • The system must provide First Responders with ED wait times and allow them to update triage reports.

  6. System Notifications

    • Disclaimers directing users with life-threatening conditions to call 9-1-1 or go to the ED.
    • Notifies Patient if they have been at the front of the queue for over 15 minutes without nurse action.
    • Notifications for upcoming ED visits and changes in queue position.

  7. ED Wait Times and Locations

    • Users can view the nearest ED locations and their respective wait times.

  8. IT issues

    • Administrators handle service tickets for IT issues or account permissions.

  9. Data Backup and Maintenance

    • Administrators must perform regular data backups.
    • Scheduled server updates should minimize system disruption during low-load periods.

Non-Functional Requirements

  1. Performance

    • The system must process virtual triage cases and update queues in real time.

  2. Scalability

    • The system must support thousands of concurrent users during peak hours.

  3. Reliability and Availability

    • The system must maintain a 99.9% uptime.
    • Automatic fallback procedures must ensure functionality during maintenance or unexpected downtime.

  4. Security

    • All data must be encrypted to protect sensitive user health data.
    • Multi-factor authentication for user log in with the BC Services Card app.

  5. Usability

    • The interface must be intuitive, so non-technical users can easily navigate the app.

  6. Maintainability

    • The system must be modular to allow easy updates or additional functionalities.
    • Documentation for administrators and developers.

Design Constraints

1. Time Constraints

  • Limited Development Timeline: All primary functionalities must be implemented within 4 months. Priority must be given to critical features (e.g., virtual triage and ED queue management).
  • Phased Delivery: The project needs to be delivered in phases, focusing on MVP features initially, with enhancements in later iterations.

2. Scope Constraints

  • Core Functionality Focus: The system should prioritize virtual triage, ED wait time display, and queue management.

3. Resource Constraints

  • Team Size and Expertise: The project team has limited personnel with limited experience.
  • Budget Limitations: Constraints on licensing third-party software or APIs may limit options for integration.

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 behavioral and quality attribute goals levied upon it.

Architectural Approaches

Availability Tactics

Availability was identified to be a primary non-functional requirement, as system downtime could significantly disrupt access to healthcare for users relying on the MisterED application. As such, several tactics for assuring availability have been implemented.

The Heartbeat architecture tactic is used to continuously ping the front end to check that it is ‘up’. This is an effective tactic to use because it provides continuous, automated monitoring of the frontend's availability, ensuring any downtime is detected immediately. Running this on a separate thread avoids interfering with the main application logic and maintains regular checks which is ideal. Real-time logging of frontend status allows for easy and quick diagnosis and resolution if there is a problem. Thus, this tactic enhances the system's resilience, reliability, and availability.

The Ping/Echo architecture tactic is utilized to ping the front end and assert it is up. This is an effective tactic to use because it provides real-time monitoring of the frontend’s availability through making continuous HTTP requests. Logging successes or failures immediately allows the tech team to quickly detect problems, and more easily diagnose resolve problems. This is a critical quality for maintaining reliability and availability in a medical triage system where downtime can have serious consequences.

The Exception Prevention architecture tactic is used to assert that all required data is present before proceeding with a login request. This results in avoided runtime errors that could disrupt the application’s normal workflow. Verifying fields specific to the userType prevents invalid API calls and enhances the system's stability and avoids unknown/unhandled states. This tactic must be effectively implemented to assure availability standards are met and ensure a smooth user.

The Timestamp architecture tactic is used to log system events with precise timestamps enabling administrators to track availability and troubleshoot issues when they arise. Recording the times along with the outcomes of when actions like pings or errors occur, offers more context and therefore easier analysis of system performance over time. This level of detail is helpful to have in a medical triage system since reliable monitoring and timely issue resolution are essential for maintaining service availability.

The Exception Handling architecture tactic is used during the login process to ensure the system remains stable and reliable by gracefully handling potential errors. A try-catch block is used to prevent crashes caused by network or server issues and errors are logged for debugging. This tactic gives the application a layer of resilience so it can recover smoothly thus providing a more consistent and pleasant user experience. By not crashing on errors, the system will stay available which is critical for a medical triage application where uninterrupted availability is critical for user trust.

Design Patterns

The singleton pattern is used to implement the patient queue to ensure a single, consistent instance of the queue is maintained across all system views. This design pattern was chosen because it is the most suitable approach for shared features. It is the most suitable because, the singleton pattern prevents duplication, conflicting updates, and data inconsistencies, thus preventing conflicting patient appointment times. Additionally, it reduces the complexity of resource management and maintenance by localizing controls over the queue's states.

The Observer design pattern used for the patient queue to ensure all patients in the queue are receive real-time notifications about updates when the queue is updated. The observer pattern is ideal for the queue as it is frequently updated and patients in the queue (observers) are directly affected by updates, such as changes in their position. This pattern allows them to be notified of changes without requiring them to repeatedly query the system. By centralizing notifications, the observer pattern ensures patients are informed in a timely manner, which is essential in a healthcare context.

The Template Design Pattern is used for the Staff class and its subclasses (Doctor, EMT, and Nurse. This pattern provides a consistent structure for shared attributes like name, role, and login methods. Subclasses can extend this template to include their own attributes. This maximizes code reuse while still allowing role-specific customization. This pattern simplifies maintenance and extensibility by allowing new staff types to be added with minimal changes to the logic, making it easily scalable for managing many roles in the system. Using a decorator pattern was also considered but it was determined the Template pattern was better suited for this component than the Decorator pattern because the primary need is to provide a consistent structure for all staff types not to dynamically add/modify behaviors at runtime.

The Role-Based Conditional Rendering pattern is used for the Dashboard component because it dynamically tailors the displayed content based on the user's role (e.g., "patient" or "staff"). This ensures that each user sees only the relevant options, examples are "Appointments" and "Medical Records" for patients or "Shift Schedule" and "Assigned Patients" for staff. By organizing role-specific content, this pattern keeps the code clean and maintainable, making it easy to extend, restrict, or modify role-based features as the system grows. The template design pattern was also considered for the dashboard but was ultimately decided against in favour of the role-based conditional rendering since dynamically adjusting the UI at runtime based on the userType was desired rather than static inheritance which would be the case with the template pattern. Additionally the role-based pattern allowed for more flexibility/customization in the UI design than the template pattern would have.

The strategy pattern is used when users select symptoms in the handleChange function. This is the ideal pattern to use because it separates the logic for handling user input from of the Select component’s rendering logic and its children (MenuItem and Checkbox). Because this is a modular design, it ensures flexibility. Changes to the way symptoms are selected or managed can be made independently of the component’s structure. This approach supports cleaner, more maintainable code and simplifies future development, such as introducing new selection mechanisms or modifying input behavior, by containing state update logic in a distinct, reusable function.

The Facade Pattern is used for the login function in the AuthProvider component because it provides a unified and simple interface to handle different authentications for both staff and patients. The function determines the correct API to use based on the userType which allows the rest of the code to be much simpler. This results in cleaner, more maintainable code and simplifies future changes to authentication logic, making it an ideal solution for managing multiple login processes in an efficient way.

Analysis Results

A third party reviewed the software architecture planned for the implementation of MisterED. The results of their evaluation are included in the following documents.

rubricM1.pdf

rubricM2.pdf

rubricM3.pdf

Mapping Requirements to Architecture

  1. User Authentication
  • Requirement: Patients must log in using BC Services Card, and staff must log in using their credentials.
  • Addressed By:
    • Facade Pattern: Used in the login function of the AuthProvider component. Provides a unified interface for handling both patient and staff authentication while managing their respective requirements (e.g., BC Services Card for patients, username/password for staff).
    • Exception Prevention Tactic: Ensures required fields are validated before proceeding with API requests to prevent runtime errors.
  1. Virtual Triage
  • Requirement: Users can input symptoms for a virtual triage process, and cases are prioritized by severity.
  • Addressed By:
    • Strategy Pattern: Used in the handleChange function to handle symptom input and state updates modularly. Reusable logic/code for managing triage input.
    • Observer Pattern: Users are notified in real-time of triage results and follow-up directions.
  1. Queue Management
  • Requirement: Patients must see their queue position, staff must be able to update it, and notifications must be sent for queue changes.
  • Addressed By:
    • Singleton Pattern: Maintains a single instance of the patient queue across all system views, preventing inconsistencies in queue information.
    • Observer Pattern: Notifies patients of changes in their queue position or when it's their turn to visit the ED.
  1. Symptom and Profile Management
  • Requirement: Users and healthcare professionals can view or update medical history, symptoms, and profiles.
  • Addressed By:
    • Template Pattern: Used for the Staff class, enabling healthcare professionals to manage medical history.
    • Strategy Pattern: Handles symptom updates dynamically and modularly.
  1. Emergency Escalation
  • Requirement: Critical cases must be escalated to first responders with ED wait times provided.
  • Addressed By:
    • Observer Pattern: Real-time notifications ensure that first responders are informed promptly of escalated cases.
    • Singleton Pattern: Ensures consistent queue data is shared across the system.
  1. System Notifications
  • Requirement: Notify users about disclaimers, queue updates, and ED visit times.
  • Addressed By:
    • Observer Pattern: Dynamically notifies patients of updates to queue position and reminders for upcoming visits.
  1. ED Wait Times and Locations
  • Requirement: Users must view ED locations and their wait times.
  • Addressed By:
    • Role-Based Conditional Rendering Pattern: Dynamically tailors dashboard content for patients and staff, including relevant ED wait times.
  1. IT Issues
  • Requirement: Administrators handle service tickets for IT issues.
  • Addressed By:
    • Timestamp Tactic: Logs all service-related events, enabling administrators to resolve IT issues efficiently.
    • Heartbeat Tactic: Continuously monitors the system’s status, ensuring downtimes are quickly spotted and fixed.
    • Ping/Echo Tactic: Ensures real-time monitoring, allowing downtimes to be quickly identified and resolved.
  1. Scalability
  • Requirement: Support thousands of users concurrently.
  • Addressed By:
    • Singleton Pattern: Maintains a reduced number of patient queues, preventing redundant operations and improving scalability.
  1. Reliability and Availability
  • Requirement: 99.9% uptime and fallback during downtime.
  • Addressed By:
    • Heartbeat Tactic: Ensures continuous monitoring.
    • Exception Handling Tactic: Prevents disruptions from unhandled errors.
  1. Security
  • Requirement: Encrypt sensitive health data and implement multi-factor authentication.
  • Addressed By:
    • Facade Pattern: Simplifies the integration of security measures, including multi-factor authentication.
  1. Usability
  • Requirement: Intuitive interface for non-technical users.
  • Addressed By:
    • Role-Based Conditional Rendering Pattern: Simplifies the interface by presenting only relevant content based on the user’s role.
  1. Maintainability
  • Requirement: Modular design with developer documentation.
  • Addressed By:
    • Template Pattern: Encourages code reuse and simplifies updates for shared functionality.
    • Strategy Pattern: Modular design makes modifications easier for handling user input.