Emergency Departments (EDs) face significant challenges due to overcrowding and inefficient patient management. These issues often lead to prolonged wait times, resource strain, and patient dissatisfaction. Patients often visit ED’s without knowing the severity of their condition, many of which can be managed just as well from home. This unnecessary increase in the load at ED’s can make it difficult for healthcare providers to take care of patients, and will often lead to patients waiting hours in a busy ED lobby. Without a proper solution addressing all of these issues ED’s will continue to face the challenges discussed.

Key Challenges:

• Overcrowding: ED’s are often overwhelmed by high volumes of patients with minor symptoms, creating delays for patients with critical conditions.
• Lack of Patient Resources: Patients do not currently have access to real-time loads and capacities at ED’s.
• Inefficient Triage: Current systems require in-person evaluation, which consumes valuable resources and time.
• Patient Experience: Patients often have to wait long hours in waiting areas, increasing stress and discomfort.

The Mr. Ed system is a digital healthcare solution designed to alleviate ED overcrowding, give patients access to online loads and capacities, and overall improve the patients experience.

Key Features:

• Real-Time ED Status
  • Displays the current load and estimated wait times at nearby Emergency Departments.
  • Helps patients weigh their options, and make an educated decision on their next course of action.
• Virtual Registration
  • Allows patients to register for our application, allowing interaction with the virtual triage feature.
• Virtual Triage and Queueing
  • Allows patients to submit a form describing their symptoms, current condition, and health information.
  • Manages Virtual Triage tickets (or submissions) through a queueing system, displayed to nurse practitioners for review and priority setting.
  • Includes a priority system, set by the nurse.
  • Displays ticket information for medical personnel to view.
• Notification System
  • Notifies patients of their position in the queue once a virtual triage form has been submitted.
  • Notifies patients when they should come into the ED

Goals:

The primary goal of the Mr. Ed system’s software architecture is to provide a scalable, maintainable, and reliable platform that reduces the load on emergency departments while improving convenience. The system ensures that patients in critical condition receive priority over patients with more manageable symptoms. It implements a strict authorization mechanism to protect important information and limit access to authorized users only. This approach not only prioritizes patient outcomes but also optimizes the allocation of healthcare resources.

Role of Software Architecture:

The software architecture plays a role in the life cycle by guiding development, supporting scalability, and enabling flexibility. It serves as a blueprint for development, dividing the structure into components for easier development. It supports a wide variety of loads through cloud based-services and modular components. It allows for the addition of future features, and evolving user requirements.

System Engineering:

The architecture aligns closely with system engineering principles, translating high-level goals into actionable modules, validating design choices through prototypes, and integrating seamlessly with external dependencies.

Functional Requirements:

• Real-Time ED Load Tracking:
  • The system must offer the ability to view wait times for selected emergency departments.
• Virtual Triage Capability
  • The system must allow patients to submit their symptoms online, to be reviewed by a medical practitioner.
• Account Registration
  • The system enables users to create accounts, keeping track of their personal information.
• Ticket Prioritization
  • The system implements a system for the prioritization of patients with severe symptoms.
• Notification System
  • The system notifies patients of the status of their virtual triage
• Doctor View
  • The system displays the patient information for a doctor to understand the needs of the patient.

Design Constraints:

• Secure Data
  • The system provides security for confidential patient information. It implements authorizations of different levels for different users.
• Cross-Platform Compatibility
  • The system functions on any device with web access
• Performance Requirement
  • The system functions given a high volume of users. A heavier load does not lead to extreme system response times.

The system occupies a traditional web development architectural approach. It defines three major deployment components: the frontend, backend, and database systems. These components provide a clear separation in the functionality of the application, promoting maintainability and scalability across the architecture. Each of these overarching components encompass subcomponents which build the ultimate structure of the application.

Three-Tier Architecture

• • *Frontend: Implements the user interface, providing users with access to the application resources. It functions as the only point of contact between users and the application.
• Backend: Serves as the middle ground between the database and the frontend, manipulating data according to the application requirements.
• Database: Stores the account data, triaging information, and current department loads and capacities.

This approach was selected for its properly defined roles and sequential order. Having related sections within each component allows for easy maintainability and scalability. Furthermore, by having access to the database filtered by the backend we can employ various security strategies.

Modular Approach

• Registration Module: Implements the login and registration functionality.
• Virtual Triage Module: Functions to register patients for medical attention, these requests are reviewed by a nurse to determine priority.
• Medical Module: Creates a priority queue for requests after review, allows for doctors to select patients based on priority
• Department Module: Keeps track of department loads, capacities, and wait times
• Data Storage Module: Stores all information involved with the application, including account data, triage tickets, medical tickets, and department information

This approach was selected to facilitate implementation, improve maintainability and readability. By having designated modules we can split the design into subsections, allowing developers to focus on one module at a time. It allows for review of specific modules at a time, facilitating the design process.

The primary analysis of the “Mr. Ed” system was done through exploratory usage of the application, where testers interacted with the various features of the system highlighting key points. This approach provided realistic insights into the limitations and functionality of the system.

Qualitative Findings

1. System Usability
   • Testers found the interface intuitive and simple to use with minimal understanding of the various roles within the application.
   • All modules worked as intended during the final testing.
2. Reliability
   • The system remained reliable, with no critical errors observed.
   • All information was stored and retrieved accurately, with no unintentional modification of data.
   • The system was responsive and ran under a reasonable time constraint.

System Limitations

• No stress testing was performed to evaluate the system's usability under a heavy load of users.
• Basic security functionality was tested, however, no advanced security testing was done.

The exploratory testing showed that the system met the design requirements specified, however, further testing is recommended to ensure the application meets general standards under more rigorous conditions.

Each functional requirement is addressed by a specific frontend and backend component of the application. The frontend implements the user interface for that requirement, and the backend executes the storage and retrieval of data related to the requirement into the database. The design constraints vary in the location in which they are addressed within the software architecture. The system employs secure data primarily through the login page, ensuring proper authentication before given access to any process or resource. The cross-platform capability is demonstrated by the chosen architecture, being a web application it is deployable amongst a wide variety of electronic devices, using responsive web design practices to ensure compatibility across devices. The performance requirement is addressed by the backend system by reducing the number of time consuming operations, allowing for a responsive application. This mapping illustrates how the software architecture aligns with the design requirements, ensuring all functional needs and constraints are addressed within the application.

Sub-parts of this section provide information that will help readers or users of the Software Architecture Document (SAD) quickly find information that will enable them to do their jobs. Readers of the SAD seeking an overview should begin here, as should readers interested in finding particular information to answer a specific question.

• How the SAD is organized explains the information that is found in each section of the SAD.
• How a view is documented explains how architectural views are documented in this SAD.

This SAD specifies the software architecture for insert scope of SAD. All information regarding the software architecture may be found in this document, although much information is incorporated by reference to other documents.
The software architecture for a system is the structure or structures of that system, which comprise software elements, the externally-visible properties of those elements, and the relationships among them [ Bass 2012]. "Externally visible"� properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. This definition provides the basic litmus test for what information is included in this SAD, and what information is relegated to downstream documentation.

The software architecture first and foremost embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, a software architecture is an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. Elements interact with each other by means of interfaces that partition details about an element into public and private parts. Software architecture is concerned with the public side of this division, and that will be documented in this SAD accordingly. On the other hand, private details of elements—�details having to do solely with internal implementation—are not architectural and will not be documented in a SAD.

The definition of software architecture makes it clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. The neurologist, the orthopedist, the hematologist, and the dermatologist all take a different perspective on the structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on subsystems. And the kinesiologist and psychiatrist are concerned with different aspects of the entire arrangement's behavior. Although these perspectives are pictured differently and have very different properties, all are inherently related; together they describe the architecture of the human body. So it is with software. Modern systems are more than complex enough to make it difficult to grasp them all at once. Instead, we restrict our attention at any one moment to one (or a small number) of the software system's structures. To communicate meaningfully about an architecture, we must make clear which structure or structures we are discussing at the moment—which view we are taking of the architecture. Thus, this SAD follows the principle that documenting a software architecture is a matter of documenting the relevant views and then documenting information that applies to more than one view.

For example, all non-trivial software systems are partitioned into implementation units; these units are given specific responsibilities, and are the basis of work assignments for programming teams. This kind of element will comprise programs and data that software in other implementation units can call or access, and programs and data that are private. In large projects, the elements will almost certainly be subdivided for assignment to sub-teams. This is one kind of structure often used to describe a system. It is a very static structure, in that it focuses on the way the system's functionality is divided up and assigned to implementation teams.

Other structures are much more focused on the way the elements interact with each other at runtime to carry out the system's function. Suppose the system is to be built as a set of parallel processes. The set of processes that will exist at runtime, the programs in the various implementation units described previously that are strung together sequentially to form each process, and the synchronization relations among the processes form another kind of structure often used to describe a system.

None of these structures alone is the architecture, although they all convey architectural information. The architecture consists of these structures as well as many others. This example shows that since architecture can comprise more than one kind of structure, there is more than one kind of element (e.g., implementation unit and processes), more than one kind of interaction among elements (e.g., subdivision and synchronization), and even more than one context (e.g., development time versus runtime). By intention, the definition does not specify what the architectural elements and relationships are. Is a software element an object? A process? A library? A database? A commercial product? It can be any of these things and more.

Although software architecture tends to focus on structural information, behavior of each element is part of the software architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the software architecture and will be documented in the SAD as such. Behavior is documented in the element catalog of each view.

This SAD is organized into the following seven sections:

• Documentation Roadmap and Overview provides information about this document and its intended audience. It provides the roadmap and document overview. Every reader who wishes to find information relevant to the software architecture described in this document should begin by reading this section, which describes how the document is organized, and where information may be found.
• Architecture Background provides information about the software architecture. It describes the background and rationale for the software architecture. It explains the constraints and influences that led to the current architecture, and it describes the major architectural approaches that have been utilized in the architecture.
• Views and Mapping Between Views specify the software architecture.
• Referenced Materials and Glossary and Acronyms provide reference information. Referenced Materials provides look-up information for documents that are cited elsewhere in this SAD. Glossary and Acronyms is an index of architectural elements and relations giving their definition, and where each is used in this SAD.

1. Primary Presentation
   • A graphical representation of the view being described, showing elements and the relationships between them. It identifies elements internal to the scope of the view, as well as any external elements.
2. Element Catalog
   • A descriptive table of the elements depicted in the primary presentation, explaining their function and properties.
3. Variability Guide
   • Describes points where the system can be parameterized or reconfigured.
4. Other Information
   • Description and rationale for important design decisions (including relevant rejected alternatives)
5. Parent View
   • If the current view is the refinement of another view, indicates which one

List of definitions of special terms and acronyms used in the SAD. If terms are used in the SAD that are also used in a parent SAD and the definition is different, this section explains why.
Term	Definition
software architecture	The structure or structures of that system, which comprise software elements, the externally visible properties of those elements, and the relationships among them [Bass 2012]. "Externally visible"� properties refer to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on.
view	A representation of a whole system from the perspective of a related set of concerns [IEEE 1471]. A representation of a particular type of software architectural elements that occur in a system, their properties, and the relations among them. A view conforms to a defining viewpoint.
viewpoint	A specification of the conventions for constructing and using a view; a pattern or template from which to develop individual views by establishing the purposes and audience for a view, and the techniques for its creation and analysis [IEEE 1471]. Identifies the set of concerns to be addressed, and identifies the modeling techniques, evaluation techniques, consistency checking techniques, etc., used by any conforming view.
view packet	The smallest package of architectural documentation that could usefully be given to a stakeholder. The documentation of a view is composed of one or more view packets.
virtual triage	The process described by the submission of a request for medical attention, and all steps up to the medical appointment.

• Software Architecture Documentation Template
• The Java Pet Store SAD

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 views. As required by ANSI/IEEE 1471-2000, it also describes any known inconsistencies among the views.

The module view and component and connector view are related in the sense that the latter describes the implementation of each module. Each module has a frontend and backend component that interacts with the rest of the application as depicted in the component and connector view, with the exception of the data storage module which is depicted as the data storage component.

The allocation view describes the physical deployment of the application. The physical allocation of each module within the module view can be described within the frontend and backend servers, with the exception of the data storage module which is described by the database server.

The component and connector view and allocation view are related in the sense that the latter describes the physical implementation of the components. Each subcomponent within the component and connector view can be individually mapped to a physical node in the allocation view.

This section provides citations for each reference document.
Short Name	Reference
Barbacci 2003	Barbacci, Ellison, Lattanze, Stafford, Weinstock, Wood, Quality Attribute Workshops (QAWs), Third Edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
Bass 2012	Bass, Clements, Kazman, Software Architecture in Practice, third edition, Addison Wesley, 2012.
Clements 2001	Clements, Kazman, Klein, Evaluating Software Architectures: Methods and Case Studies, Addison Wesley Longman, 2001.
Clements 2003	Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures: Views and Beyond, Addison Wesley Longman, 2003.
IEEE 1471	ANSI/IEEE-1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE, 21 September 2000.
Waits 2019	Waits, Software Architecture Documentation Template - Software Architecture Documentation (SAD) - Confluence, Confluence, 2019.

Below is a graphical representation of the “Mister Ed” system’s module architecture and the data relationships between each.

Diagram 1: Module View

Element Name	Description
Registration Module	Handles account registration, supports a variety of account types (patient, doctor, nurse)
Virtual Triage Module	Handles virtual triage tickets, including patient medical information such as symptoms, health number, etc.
Medical Ticket Module	Handles virtual triage ticket priorities, the final stage of a ticket
Department Module	Service to handle medical establishment information such as wait times and capacities
Data Storage Module	Stores all information related to the application, including accounts, VT tickets, medical tickets, and department information

• Parameterization Points
  • Supports the addition or removal of emergency departments
• Environment Compatibility
  • Support for multiple runtime environments
  • Extendable module architecture for future integration with third-party health monitoring tools

• Design Decisions:
  • A modular approach to design was chosen to ensure scalability and maintainability
  • Use of cloud-hosted services to handle variable loads effectively

The diagram below represents the Component and Connector View of the “Mister Ed” system. It shows runtime interactions between the key components and external entities.

Diagram 2: Component and Connector View

Component/Connector Name	Description
Application	The Mr. Ed deployable application
Frontend System	Subcomponent interface for patients to interact with the system via web or mobile devices
Backend System	Subcomponent that orchestrates operations such as triage, notification, and priorities
Cloud Hosting	Hosts the data storage on the cloud
Data Storage	Subcomponent that stores patient data, triage information, and ED details
External Device	Devices used to access the system by patients and medical practitioners

• Environment Compatibility
  • Support for a wide range of external devices (any device with web access)

• Design Decisions
  • Adoption of a classic structured approach to the application, defining the frontend, backend, and database components, allowing easier implementation and maintainability

This view is a higher-level refinement of the Modular View, detailing runtime interactions and relationships between the overarching components involved in the system

The diagram below illustrates how the software is allocated across physical and virtual nodes. It shows a graphical representation of the system’s deployment.

Diagram 3: Allocation View

Node Name	Description
Frontend Servers	Serve the user interface for patient registration, triage, and notifications
Backend Servers	Perform system logic, include triage and department load
Database Servers	Store and manage data securely for all system interactions

• Environment Compatibility
  • Support for a wide range of external devices (any device with web access)

This view is a refinement of the Components and Connectors view. It shows the internal and external components, representing the physical allocation of services.

The purpose of this question set is to assess how effectively the Mr. ED architecture addresses stakeholders' concerns and interests, as well as to evaluate their overall satisfaction.

All stakeholders must have their concerns, roles, and interests represented within the architecture for the Mr. ED application.

1. List all your concerns corresponding to the architecture. Are all these concerns addressed?
   Answer: No data protection, no notification for when patient is next in line. Yes, the concerns are addressed.
2. ​​Is the architecture documentation clear and understandable?
   Answer: The architecture documentation is very easy to read and explains the architecture very well. There was a clear understanding of the architecture once finished reading the architecture package.
3. Are there any inconsistencies between the architecture diagrams, textual descriptions, and models?
   Answer: There are a few inconsistencies between the architecture diagrams and current architecture. Specifically, the sequence diagrams and class diagram.
4. Does the architecture meet all needs of the stakeholders?
   Answer: Yes, the architecture meets all the needs of the stakeholders.
5. Does the architecture protect my data?
   Answer: No.
6. List potential risks that you see arising from our architecture?
   Answer: No data protection and patients do not get a warning when they need to be at the hospital soon (being next in line).

1. Does the architecture follow industry standards and guidelines?
   Answer: No data protection, which is critical with industry standards and guidelines.
2. Are there any potential risks with the current implementation that are not addressed?
   Answer: Yes, no data protection and no notification when user is next in line (come to hospital now).
3. How easily can the architecture accommodate future change?
   Answer: Very easily.

1. Is the architecture an improvement to the current method used?
   Answer: Yes, the architecture is an improvement to the current method used.
2. Is the architecture efficient and easy to use?
   Answer: Yes.

For any concerns listed by the stakeholders, they should be properly addressed. The documentation should be clear and understandable. The diagrams, descriptions and models should be consistent. The architecture should meet the needs of the stakeholders. The architecture should protect stakeholder data. The risks from our architecture should be properly addressed. The architecture should follow industry standards and guidelines. The architecture should be future-proof. The architecture should improve upon the currently used method. The architecture should be efficient and easy to use.

Questions concerning baseline architecture function are most important, followed by questions concerning industry standard, followed by questions concerning ease of use.

This question set is appropriate for determining the needs of our stakeholders and whether or not they have been met. It ensures that concerns regarding functionality, data protection, and usability are addressed comprehensively. Additionally, it highlights areas for improvement by evaluating alignment with industry standards and accommodating future changes. By systematically documenting stakeholder feedback, this process fosters collaboration and supports informed decision-making to refine the architecture.

The purpose of this question set is to assess how effectively the Mr. ED architecture addresses stakeholders' concerns and interests, as well as to evaluate their overall satisfaction.

All stakeholders must have their concerns, roles, and interests represented within the architecture for the Mr. ED application.

1. List all your concerns corresponding to the architecture. Are all these concerns addressed?
   Answer: No data protection. This concern is addressed in the architecture package.
2. ​​Is the architecture documentation clear and understandable?
   Answer: Yes, it was very clear.
3. Are there any inconsistencies between the architecture diagrams, textual descriptions, and models?
   Answer: A few within the sequence diagrams.
4. Does the architecture meet all needs of the stakeholders?
   Answer: Although it might not meet all the wants like a map etc. It definitely meets the fundamental needs of all stakeholders.
5. Does the architecture protect my data?
   Answer: No.
6. List potential risks that you see arising from our architecture?
   Answer: No data protection.

1. Does the architecture follow industry standards and guidelines?
   Answer: Although the architecture does well at following the industry standards and guidelines, it falls short with data protection. There is no architecture present to secure user data.
2. Are there any potential risks with the current implementation that are not addressed?
   Answer: Yes, there is no data protection and cybersecurity.
3. How easily can the architecture accommodate future change?
   Answer: It can accomodate future easily. For examples, new priorities and emergency departments can be implemented easily.

1. Is the architecture an improvement to the current method used?
   Answer: Yes, because there is no method currently that allows patients to enter emergency triage virtually.
2. Is the architecture efficient and easy to use?
   Answer: Yes, it is very simple.

For any concerns listed by the stakeholders, they should be properly addressed. The documentation should be clear and understandable. The diagrams, descriptions and models should be consistent. The architecture should meet the needs of the stakeholders. The architecture should protect stakeholder data. The risks from our architecture should be properly addressed. The architecture should follow industry standards and guidelines. The architecture should be future-proof. The architecture should improve upon the currently used method. The architecture should be efficient and easy to use.

Questions concerning baseline architecture function are most important, followed by questions concerning industry standard, followed by questions concerning ease of use.

This question set is appropriate for determining the needs of our stakeholders and whether or not they have been met. It ensures that concerns regarding functionality, data protection, and usability are addressed comprehensively. Additionally, it highlights areas for improvement by evaluating alignment with industry standards and accommodating future changes. By systematically documenting stakeholder feedback, this process fosters collaboration and supports informed decision-making to refine the architecture.

The following is an analysis and comparison of the architecture package reviews completed by two different groups:

• The architecture documentation was clear, simple, and understandable to read.
• Both groups were concerned about data protection and security. Currently, this is out of scope for our project.
• Group 1 is concerned that the patient will not be notified when they are next in line to be seen by a doctor at the hospital. However, the patient is notified whenever their spot in line changes. When the patient is 1st in line, that means they are next. Thus, a patient can choose when they believe they should go to the hospital depending on their place in line and distance from their chosen hospital.
• Both groups identified inconsistencies between the architecture diagrams and architecture, including the class diagram (noted by Group 1) and the sequence diagrams (noted by Group 1 and 2). This has since been fixed.
• Both groups recognized that the architecture can accomodate future change easily.

This class diagram demonstrates the use of multiple design patterns in the system. The Factory Pattern is evident in the createVT() method, abstracting the creation of virtual triage tickets. The State Pattern is represented by transitions in ticket states, such as prioritization in MedicalTicket. The system follows the MVC Pattern, separating data models (User, VT Ticket, MedicalTicket) from logic (e.g., register(), login()) and connecting to the React frontend for rendering. While the Decorator Pattern and Observer Pattern are primarily implemented in the API and frontend, this diagram reflects the extensibility and event-driven nature of the system’s architecture.

This final rendition of the Entity Relationship Diagram was required, as we made several changes to the structure of our data from Milstone 3. Firstly, we eliminated the admin portion of the ERD altogether. Instead of having an admin class, our group members act as administrators, creating and deleting nurse and doctor accounts as needed. Furthermore, "doctor", "nurse" and "patient" were all generalized to "user" which carries the attribute "userType" in order to differentiate patients, doctors and nurses. In addition to these major changes, some attributes were added to all the remaining entities in order to reflect their state in our database. The most critical addition was the "inTriage" boolean, added to "users" which is a state variable that manages whether a user is eligible to submit a triage form or not. Having this distinction between users is essential as it ensures that each patient has no more than 1 instance of a ticket being processed at one time.

Specify the remaining implementation goals for this last sprint. Implement them and comment on the completion. Describe what goals were in the previous sprints, why they were shifted, and when they were completed.

The following describes the goals in each sprint/milestone:

• Milestone 1: Obtain a clear idea of the project's system, identify primary actors, create and describe use case diagrams.
• Milestone 2: Develop a comprehensive plan for the code architecture, complete all required design diagrams, complete the full-stack development (front-end, back-end, database, and connections) for the login and registration pages.
• Milestone 3: Complete 80% of the system's code, implement design patterns and architectural tactics, and update design diagrams.
• Milestone 4: Complete the remaining features, minor bug fixes, and styling for this web application, write and review the architecture package, and update design diagrams.

Some goals in these milestones were moved to other milestones.

• Milestone 1: All goals were completed in Milestone 1.
• Milestone 2: There were difficulties with creating the connections between the front-end, back-end, and database in MongoDB. This task was shifted to and completed in Milestone 3. All other goals set for Milestone 2 were completed in Milestone 2.
• Milestone 3: All goals were completed in Milestone 3.
• Milestone 4: All goals were completed in Milestone 4.

A detailed description of the implementation goals for this last sprint are described below. All implementation goals set for Milestone 4 were completed.

• Doctor view: View the medical ticket details (priority, symptoms, emergency department, and medical information) and accept the ticket to treat the patient.
• Notify patient: Notify the patient on the "Patient Waiting" screen. When the nurse has set a priority to the patient's ticket, the patient will be notified what place in line they are in. If more patients enter the queue, the place in line will continue to be updated. In addition, the patient will be notified when the doctor is ready to see them.
• User authentication: Only allow certain user types to view/use certain pages. For example, Patients should only be allowed to access the "Enter Virtual Triage" page.
• Added multiple rest API routes, with GET and POST HTTP methods used.

The Mr. ED web application is now complete and fully functional.

** It is very important to note that this web application will not function without our MongoDB database. If needed, we can come to campus and demo it. **

• Ashley: Worked on the doctor view feature so the doctor can select and view medical ticket details. Performed testing on the web application. Completed documentation in the Wiki, including the Incremental Construction and a description of our final implementation. Conducted the review of the architectural package.
• Liam: Implemented the front and back end code necessary for the nurse point of view (viewing all triages, opening one, assigning it a priority and creating a medical ticket out of it). Also implemented all of the emergency department code (front and back end as well), allowing Mr ED to display the wait time of each emergency department based on the number of active medical tickets that reference it. Updated the ERD and Class diagram and wrote descriptions of both.
• Erich: Contributed to the front and back end for the nurse point of view, also assisted in the backend implementation of the medical tickets. Wrote the architecture package document for the wiki.
• Isaac: Fixed Doctor screen so that it showed patient symptoms. Implemented the patient notifications from the nurse's point of view (accept and reject ticket), as well as alerting the patient to come in to the ER from the doctor's point of view, from the back and frontend. Implemented authentication for each user type associated with a screen, meaning users can only access what they're allowed to access. Dressed up the application for production release. Fixed register screen after backend issue.