This section explains the SAD's overall purpose and scope, the criteria for deciding which design decisions are architectural (and therefore documented in the SAD), and which design decisions are non-architectural (and therefore documented elsewhere).

This wiki describes the architectural structure of the Mister Ed web application. This application provides a means for patients to recieve a preliminary, virtual assessment of their condition, and recieve recommendations for further actions. It also allows them to book an appointment at the ER, rather than waiting on-site for an open spot. The application has a frontend constructed in VUE JS, a backend written in Python, and was managed via source control through GitHub.

This Software Architecture Document (SAD) was constructed based on this template. See here for an in-depth breakdown of the template.

This section provides a narrative description of the seven major sections of the SAD and the overall contents of each. Readers seeking specific information can use this section to help them locate it more quickly.

The SAD is organized into the following sections:

• Documentation Roadmap and Overview: Provides a guide to the document's structure, summarizing its content and purpose.
• Architecture Background: Explains the system's context, constraints, and key drivers influencing architectural decisions (e.g., business goals, technical requirements).
• Views: Represents the system's architecture from different perspectives (module, component, and allocation views) to address stakeholder concerns.
• Mapping Between Views: Illustrates how elements in different architectural views relate to one another to ensure consistency and coherence.
• Referenced Materials: Lists external documents, standards, or resources cited in the architecture document for further context or validation.
• Glossary and Acronyms: Defines key terms and acronyms used in the document to ensure clarity and consistent understanding.

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

There are several restrictions that influenced the design of the Mister Ed architecture:

• Patients and medical staff must have different privileges.
• Medical staff must be able to access data that patients have explicitly provided while seeking medical attention, while maintaining security of user data.
• For patients to receive quick and targeted responses, interactions between patients and medical staff must be one-to-many, and interactions from medical staff to patients must be one-to-one or many-to-one.

This section describes the general function and purpose for the system or subsystem whose architecture is described in this SAD.

The Mister Ed application is a web-based system providing health assessments and hospital bookings to users. The system can thus be broken into two parts:

1. Virtual Triage: users will enter their symptoms and recieve a preliminary diagnosis.
2. Appointment booking: users can book an appointment at a local ER.

This section describes the goals and major contextual factors for the software architecture. The section includes a description of the role software architecture plays in the life cycle, the relationship to system engineering results and artifacts, and any other relevant factors.

The primary goal of this software architecture is to create a light, modular system that is easy to maintain. Since Mister Ed is an emergency service, ensuring a high level of availability is important, and part of providing a high up-time is limiting clutter in the front and back end.

This section lists the functional requirements quality attributes and design constraints. It may point to a separate requirements document.

Symptoms and severity

• Users should be prompted for the serverity of their situation before describing their symptoms
• A relatively large field should be provided for symptom descriptions

Diagnosis

• Diagnoses provided by Mister Ed should include (but not be limited by) the symptoms provided by the user
• Diagnoses should be relatively fast to produce
• If a diagnosis cannot be made, Mister Ed should prompt the user for additional info

Appointments

• Users should be able to view the details of their appointments at any time
• Hospital staff should be able to book, cancel, and reschedule appointments
• Appointments should be listed based on priority (higher severity = higher priority)

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.

This section provides a rationale for the major design decisions embodied by the software architecture. It describes any design approaches applied to the software architecture, including the use of architectural styles or design patterns, when the scope of those approaches transcends any single architectural view. The section also provides a rationale for the selection of those approaches. It also describes any significant alternatives that were seriously considered and why they were ultimately rejected. The section describes any relevant COTS issues, including any associated trade studies.

The design necessitated providing different user types with different roles, with the medical roles being able to access information from the patient roles while not compromising personal information. This strongly favoured a design built around a central backend database, which allows each user type access to information they are authorized, and a frontend responsible for displaying said information. Given high uptime can be critical in medical applications, the design should also seek to be as reliable as possible. This led to the decision of having a backup database in case of data corruption. Medical decisions also need quick responses, but should always be made under the decision of human experts, in order to maximize patient health outcomes. This led to the design of the virtual triage system, which aims to provide an initial priority assessment based on user reports, lightening the burden on medical workers and shifting focus to more urgent cases while not interfering with or overriding the decisions of medical professionals.

This section describes the results of any quantitative or qualitative analyses that have been performed that provide evidence that the software architecture is fit for purpose. If an Architecture Tradeoff Analysis Method evaluation has been performed, it is included in the analysis sections of its final report. This section refers to the results of any other relevant trade studies, quantitative modeling, or other analysis results.

While functional testing has not been performed, the UI design was well-received during architecture design review. Reviewers were satisfied with the practicality and visual appeal of the frontend application.

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.

Symptoms and severity

• Users should be prompted for the serverity of their situation before describing their symptoms - Addressed in the design of the frontend software interface
• A relatively large field should be provided for symptom descriptions - Addressed in the design of the frontend software interface

Diagnosis

• Diagnoses provided by Mister Ed should include (but not be limited by) the symptoms provided by the user - Addressed via virtual triage system, allowing initial tentative diagnosis from Mister Ed, and then follow-up from medical staff
• Diagnoses should be relatively fast to produce - Addressed via virtual triage system allowing speedy initial diagnosis, followed by review from medical professionals
• If a diagnosis cannot be made, Mister Ed should prompt the user for additional info - Addressed in the design of the frontend software interface

Appointments

• Users should be able to view the details of their appointments at any time - Addressed in the design of the frontend software interface
• Hospital staff should be able to book, cancel, and reschedule appointments - Addressed in frontend interface design, and in maintaining separate user privilege levels for staff and patients
• Appointments should be listed based on priority (higher severity = higher priority) - Addressed in frontend interface design and virtual triage prioritization system

How a view is documented:

1. Primary Presentation

• Is usually graphical
• Should include a key that explains the notation
• Shows elements and relations among them
• Shows the information you want to convey about the view first
• Should identify elements that are external to scope of the view
• If external entities are not clearly marked in the diagram, consider adding a context diagram

2. Element Catalog

• Explains elements depicted in primary presentation and their properties
• Is usually a table with element name and textual description
• May contain interface documentation
• May contain behavior documentation

3. Variability Guide

• Points where system can be parameterized or reconfigured. Examples:
• Number of instances in a pool
• Support for plug-ins or add-ons
• Support for different versions of OS, database server or runtime environment
• Maybe the view is a reference architecture
• Provide guidelines to instantiate it

4. Other Information (optional)

• Description and rationale for important design decisions (including relevant rejected alternatives)
• Results of analysis, prototypes and experiments
• Context diagram

5. Parent View (optional)

• If the current view is the refinement of another view, indicate which one

For booking, viewing, tracking triage results, history, and updating.

Encompasses patients, employees and appointments.

Handles user registration, login, logout, as well profile editing logic.

Handles triage result viewing, adjusting patients and resetting triages.

JSON file acting as a database with user info (name, username, password, email, phone number, etc.).

The main users of the Mister Ed system; the targets of the virtual triage.

Encompasses all hospital workers with access to the system for the purposes of managing appointments.

Maintainers of the Mister Ed system with root access to databases, servers, and source code.

It is neccessary for all users to sign in with valid credentials before accessing the web interface of Mister Ed.

JSON file acting as a database with user info (name, username, password, email, phone number, etc.).

Main page of the Mister Ed web interface. Includes ability to navigate between components (virtual triage, appointment booking, settings, user profile, etc.).

Web-side interface of Mister Ed to be displayed to users. Allows for navigation of pages and user input.

Assessment page for users to enter symptoms and severity, and recieve a diagnosis from Mister Ed based on matching symptoms in the IllnessDB. Will tell user if a hospital visit is recommended or not.

JSON file acting as a database to store various illnesses and their associated systems. Used by the VirtualTriage to assess a patient's condition.

Sets an appointment at the ER for patient's that are recommended a hospital visit by the VirtualTriage. Appointments must be confirmed by hospital staff at the relevant ER before the booking is confirmed for the patient.

Both patients and hospital staff have the ability to cancel the booking of an appointment.

If sufficient info is not provided for an assessment, Mister Ed will alert the user and prompt them for additional symptoms.

Machine running backend code, responsible for managing the internal database.

Software running on the backend server, which receives requests from frontend software, performs queries, and responds with the appropriate data.

JSON files containing user data and illness data. Queried by backend code.

Any machine used to access Mister Ed.

Browser running on the frontend device, which will access Mister Ed via the web interface.

User-facing portion of Mister Ed. Allows users to enter data, then sends requests to backend software, providing appropriate feedback to users.

If the primary database is inaccessible or corrupted, a copy of the database will be used instead. This should ensure that uptime is high.

If the backend server is not running, then the frontend will recognize this after a timeout, and provide an appropriate error message to users.

Each of the views specified in Views provides a different perspective and design handle on a system, and each is valid and useful in its own right. Although the views give different system perspectives, they are not independent. Elements of one view will be related to elements of other views, and we need to reason about these relations. For example, a module in a decomposition view may be manifested as one, part of one, or several components in one of the component-and-connector views, reflecting its runtime alter-ego. In general, mappings between views are many to many. This section describes the relations that exist among the view. As required by ANSI/IEEE 1471-2000, it also describes any known inconsistencies among the views.

The module view focuses on the internal components of the frontend software. All the modules contained in the view map onto the web interface shown in the allocation view, while the database interface serves as a means of communication with the backend server found in the allocation view.

Similarly, the C&C view maps onto the allocation view in that all components apart from the databases are parts of the frontend software, and the databases are parts of the backend server. There is, however, a discrepancy in terminology, where "web interface" refers to solely the user interface in the C&C view, whereas in the allocation view "web interface" refers to the entire frontend application running in a browser.

The C&C view and module view both focus on interactions between the different system components, but from different perspectives. The module view focuses on how different high-level actions interact. For instance, the various user groups are able to interact with the other functions of the system, such as the virtual triage. The C&C view on the other hand focuses on how the low-level components interact. For instance, a patient can input their data into the virtual triage system by first inputting their user credentials, being verified by the login page, and then inputting their symptoms for processing in the virtual triage.

This section provides citations for each reference document.

Short Name	Reference
Name 1	Reference 1
Name 2	Reference 2

List of definitions of special terms and acronyms used in the SAD. If terms are used in the SAD that are also used in t a parent SAD and the definition is different, this section explains why.

Term	Definition
Term 1	Definition 1
Term 2	Definition 2