Architecture Background

Problem Background

The Mr. Ed system aims to solve the overcrowding in Emergency Departments (EDs) by providing an online platform for patients and medical staff to perform menial medical tasks without the need to physically convene at an ED.

System Overview

Mr. Ed provides patients and medical staff with a dashboard through which additional services can be accessed depending on the user's role. Some of the services accessible by patients are as follows:

• Triage Registration
• View Medical History
• View Notifications
• View Appointments
• Request Admin Support

These online services focus on providing a more convenient and accessible option for patients seeking medical assistance while reducing the demand for physical space within EDs. Medical staff are given their own dashboards with the necessary tools to accomodate patients using Mr. Ed's online services.

Context and Scope

The software architecture of Mr. Ed aims to achieve a reliable and highly expandable system to manage interactions between patients and medical staff. New features and functionality are expected to be added in respect to established architecture. The architecture is expected to be referenced when implementing new features. In an agile model, this means the architecture must be continually updated and reviewed before accomodating new features. The architecture relies on the system engineering results to ensure the best architecture for the scope and requirements of the project are used.

Driving Requirements

The functional requirements for each user is encapsulated within the use case views of each actor. However, for convenience, the functional requirements for the actors are as follows.

All Users

• The user should be able to create an account.
• The user should be able to contact support.
• The user should be able to log in to their account.
• The user should be able to log out of their account after logging in.
• The user should be able to view their profile.
• The user should be able to edit information in their profile.
• The user should be able to delete their account.
• The user should be able to recieve and view notifications.

Patient

• The patient should be able to request a virtual triage from a hospital.
• The patient should be able to be able to see the results of their triage.
• The patient should be able to view the current capacities of EDs.
• The patient should be able to view their history.
• The patient should be able to view their appointment schedule.

Nurse

• The nurse should be able to resolve patient triage requests.
• The nurse should be able to book appointments.
• The nurse should be able to send a dispatch request for an ambulance.
• The nurse should be able to view patient history.

Doctor

• The doctor should be able to view patient triage history.
• The doctor should be able to view patient appointment history.
• The doctor should be able to view their appointment schedule.
• The doctor should be able to view patients' appointment schedules.

EMT

• The EMT should be able to recieve and view dispatch requests.
• The EMT should be able to view patient history.
• The EMT should be able to dispatch an ambulance.

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

• Client-Server Architecture: Important medical data is always stored in the database. Clients interact with the servers through APIs. Any access to the data is made through the server via the API, rather than using a local variables to store objects. This is to ensure all data viewed by medical staff is up to date and security can be added for sensitive information by sructinizing requests from a client.
• Role-Based Access Control: Each user's access to features in the system are locked behind their roles. Each role is given certain permissions, which influences what they can do within Mr. Ed. This is a security measure to ensure users cannot access functionality outside what the functional requirements specify.
• Asynchronous Communication Tools: For triages, the patient and the nurse send information to each other asynchronously. This accomodates the medical staff by allowing them to attend to requests when available, which may not be often during a busy day. This also accomodates the patient as they may want to attend to other matters while waiting for a response to their triage request.

Other alternatives to these approaches were previously considered and discarded:

• Service-based Architecture: Have each service be managed by its own Tomcat application to add a large separation of concerns. This would require too much time to implement a working prototype for this class. The scope of the application is simple enough to not require this.
• Synchronous Communication Tools: Use synchronous communication for triages such that patients can get real-time feedback from a nurse. This approach also encourages medical staff to resolve requests in a short amount of time. However, patients may not be able to adequately describe their symptoms in a time-sensitive situation, and nurses may be pressured into making hasty and poor evaluations in order to resolve the patient backlog.

Analysis Results

As of writing, no qualititive or quantitive analysis has been performed to determine the suitability of architecture decisions.

Mapping Requirements to Architecture

This section describes the requirements (original or derived) addressed by the software architecture, with a short statement about where in the architecture each requirement is addressed.