On this page, there are use case diagrams of the Mister ED system as well as use case descriptions for every single use case identified in the use case diagrams.

• Patients
• Nurses
• Doctors
• EMTs
• Administrators

Below are the use case diagrams for the main actors of the Mister ED system.

For all the use cases identified in the use case diagrams, below are all the textual descriptions of each use case.

Title	Content
Use Case	UC01 - Create Account
Description	Create an account in the Mister ED System to gain access to its features. Sources: [Project Idea]
Actors	Patient or Admin as USER
Assumptions	User has internet and a device to access the app User does not currently have an active account in the system
Steps	User clicks ‘Register’ User enters details for registration (legal name, DOB, health #, address, contact info, email/password, role) User clicks ‘Finish’ User clicks confirmation link sent to email User is shown successful registration message and redirected to login page
Variations	1# Admins can create different account types with different permissions (Doctor, Nurse, Admin etc…) 2# If any required field is left blank, ‘Finish’ button is not available 3# User gets an error since account is already in system
Non-Functional	Usability: Should feel familiar and look similar to other registration pages patients may have used before. Availability: Should have less than 6 minutes downtime per year (99.999% availability) since this is a critical medical system.
Issues	Is this all the information that is legally required? Should the patient need to submit a photo ID to confirm who they are?

Title	Content
Use Case	UC02 - Log In
Description	The user logs in to the system to access system features. Sources: [Project Idea]
Actors	Patient, Doctor, Nurse, Admin, or EMT as USER
Assumptions	User has internet and a device to access app User already has an account in the system User is logged out
Steps	User opens the app and clicks ‘Login’ User enters their credentials (username/email and password) into the relevant fields User clicks 'Login’ button User receives a code in their email User enters code in the app User is shown successful login message and redirected to their homepage
Variations	2# If any required field is left blank, ‘Login’ button is not available 3# If username/email or password is incorrect, login is not completed successfully and an error message is shown 4# User receives a code as a text to their phone
Non-Functional	Usability: Should feel familiar and look similar to other login pages patients may have used before. Availability: Should have less than 6 minutes downtime per year (99.999% availability) since this is a critical medical system.
Issues	N/A

Title	Content
Use Case	UC03 - Log Out
Description	Log out a user who is currently logged in to the Mister ED System. Sources:[Project Idea]
Actors	Patient, Doctor, Nurse, Admin, or EMT as USER
Assumptions	User has internet and a device to access app User has an active account User is already logged into the system
Steps	User clicks ‘Log Out’ User returns to the homepage
Variations	N/A
Non-Functional	Usability: Should feel familiar and look similar to other login pages patients may have used before. The log out button should not be obscured. Performance: Home page is displayed within 5 seconds of clicking log out button. Availability: Should have less than 6 minutes downtime per year (99.999% availability) since this is a critical medical system.
Issues	N/A

Title	Content
Use Case	UC04 - View Profile
Description	The user can view their profile information and account settings. Sources: [Project Idea]
Actors	Patient, Doctor, Nurse, Admin, or EMT as USER
Assumptions	User is already logged into their account
Steps	User clicks the profile icon User clicks profile information The system displays the profile information
Variations	1# Admins, Nurses, Doctors and EMTs can view other users profiles as well 2# User clicks account settings
Non-Functional	Performance: Must display the profile information and account settings within 2 seconds of the user clicking the profile icon. Usability: The user interface should be intuitive, and the profile and account settings should be accessible within 3 clicks or less. Data Privacy: The system must comply with data privacy regulations to ensure the protection of sensitive profile information. Availability: This functionality should have an uptime of 99.9%, except for scheduled maintenance.
Issues	What kind of account settings does a medical app need/want?

Title	Content
Use Case	UC05 - Edit Profile
Description	The user updates their Mister ED profile. Sources: [Project Idea]
Actors	Patient, Doctor, Nurse, Admin, or EMT as USER
Assumptions	User is already logged into their account
Steps	User clicks the profile icon User clicks profile information User makes changes to the fields User submits the updated changes
Variations	1# Admin can edit other user profiles 2# Patient clicks account settings
Non-Functional	Performance: The system must reflect changes to the user's profile within 2 seconds of submission. Usability: The system should provide real-time feedback on input errors before submitting the changes. Security: Proper authentication is required for editing a profile. Data Integrity: The system must ensure that data changes reflect accurately across all related systems or interfaces after submission.
Issues	Which fields can be changed? Are some fields uneditable and require admin assistance?

Title	Content
Use Case	UC06 - Delete Account
Description	The user deletes their account. Sources: [Project Idea]
Actors	Admin or Patient as USER
Assumptions	User is already logged into their account
Steps	User navigates to their profile User clicks ‘Delete Account’ System asks for confirmation User clicks ‘Yes’ System deletes the account
Variations	1# Admin can navigate to another user's profile and initiate the process on their behalf
Non-Functional	Usability: Users must be made aware that deleting their account is permanent. Usability: Deleting accounts should be straightforward. Security: Only administrators and patients should be able to delete accounts.
Issues	Should there be an option to disable the account?

Title	Content
Use Case	UC07 - Change Account Permissions
Description	The user can change the account permissions and account type. Sources: [Project Idea]
Actors	Admin as USER
Assumptions	User has admin privileges User is on the accounts profile page
Steps	User clicks ‘Change Permission’ System displays a pop-up with the different account options User chooses which account type and access level is appropriate User clicks ‘OK’ System changes the account
Variations	N/A
Non-Functional	Performance: Changes should be validated within seconds after completion.
Issues	N/A

Title	Content
Use Case	UC08 - View System Logs
Description	The user can view system logs. Sources: [Project Idea]
Actors	Admin as USER
Assumptions	N/A
Steps	User clicks on the system tab to bring up the system view System displays system metrics and logs with their status User clicks on individual log entry to get more detail System displays more information about the specific log entry
Variations	N/A
Non-Functional	Performance: The system must display log history in 2 seconds. Data Integrity: System log history must be backed up to prevent data corruption. Security: System data must be encrypted.
Issues	N/A

Title	Content
Use Case	UC09 - View Patient History
Description	The user has access to all prior ED visits and triage assessments that were conducted using the Mister ED system. Sources: [Project Idea]
Actors	Patient, Doctor, EMT or Nurse as USER
Assumptions	User has internet and a device to access app User has an active account User is already logged into the system User has correct authorization
Steps	User clicks ‘Patient History’ System fetches patient history from the database User views a list of prior health assessments conducted using the system User selects one of these assessments User views the health assessment that was worked on by a medical staff member (nurse, doctor, etc.)
Variations	1# Doctor, EMT and Nurse have access to the patient history for all users 2# There are no prior health assessments conducted using the system
Non-Functional	Performance: The system must retrieve and display the patient’s history within 3 seconds of the user clicking the ‘Patient History’ button. Usability: The system will have a filter/search bar for quick searching of specific assessments. Security: Proper authorization is required for viewing past assessments. Availability: This functionality should have an uptime of 99.9%, except for scheduled maintenance.
Issues	What exactly is in the health assessment? Is the health assessment a report of the triage? Does it also contain a doctor report if the patient had an ED visit?

Title	Content
Use Case	UC10 - Request Triage
Description	The user is able to request a virtual triage within the Mister ED system. Sources: [Project Idea]
Actors	Patient as USER
Assumptions	User is already logged into the system
Steps	User clicks ‘Request Triage’ User selects a hospital User waits in system queue for nurse availability
Variations	2# IF User inputs a location THEN 2.1# System selects nearest hospital
Non-Functional	Performance: Patient receives a confirmation within 2 seconds of clicking the ‘Request Triage’ button. Performance: The average time in the queue should not exceed 20 minutes, depending on nurse availability. Usability: Must provide real-time feedback on the patient’s position in the queue and estimated wait time for nurse availability. Availability: The triage request system should be available 99.99% of the time, with minimal downtime. Availability: Must be able to recover from failures (system crashes) automatically or via manual intervention without losing patient requests.
Issues	Is there other information that would be required prior to triage?

Title	Content
Use Case	UC11 - Contact Support
Description	The patient is able to contact support for issues using the system. Sources: [Project Idea]
Actors	Patient as USER and Admin
Assumptions	User has internet and a device User has the app open
Steps	User clicks ‘Contact Support’ User is shown a dialog box User enters information regarding their issue and presses send System generates a support ticket for admins
Variations	1# User clicks FAQ for common problems
Non-Functional	Usability: The patient must be able to easily find and access ‘Contact Support’ from anywhere in the app. Maintainability: Must support easy modification of FAQs.
Issues	N/A

Title	Content
Use Case	UC12 - Triage includes: UC17 – Book Appointment includes: UC15 – Dispatch Request includes: UC10 – Request Triage History [Created 09/30/2024] by Reid Williamson]
Description	The patient can register virtually and undergo a “virtual triage” to determine whether they should visit the ER or follow another course of action (e.g., visiting a GP, taking over-the-counter medication, or contacting the nurse/clinician hotline).
Actors	Nurse (Primary) and Patient (Primary)
Assumptions	The Patient and Nurse have a strong internet connection The Patient and Nurse are logged into the system
Steps	1. Patient requests a triage 2. Patient moves to the front of the triage queue 3. Nurse contacts next patient in triage queue 4. IF patient responds THEN:    4.1. Nurse removes patient from queue    4.2. Nurse performs a virtual triage on patient    4.3. Nurse recommends a course of action for the patient    4.4. IF patient needs to visit ER THEN:      4.4.1. Book an appointment for the patient with notes on triage results      4.4.2. Update patient history with notes on triage results    4.5. ELSE IF patient needs immediate medical attention THEN:      4.5.1. Send dispatch request with triage results to EMTs 5. ELSE IF patient doesn’t respond for the first time THEN:    5.1. Send patient back 5 places in the queue 6. ELSE:    6.1. Remove patient from queue
Variations	N/A
Non-Functional Requirements	Performance: Updates to patient history and appointment bookings should be completed within 5 seconds. Reliability: The system must be available 99.9% of the time. Reliability: Any failure in system operation should be resolved within 30 minutes. Security: All patient data, including triage results and medical history, must be encrypted during transmission and storage, complying with relevant healthcare regulations (e.g., HIPAA). Security: Access to the system should be role-based, allowing only authorized medical personnel to access and modify patient information.
Issues	How does the ED view the virtual ER queue? How does the ED manually place a patient in the ER queue? How would different EDs be connected to this system? How will the triage be performed (video call, phone call)? Is removing the patient from the queue an appropriate response to a missed appointment? How many chances should a patient get to miss their appointment? How long should the nurse wait for a response?

Title	Content
Use Case	UC13 - View Current Load
Description	Patients 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. Sources: [Project Idea]
Actors	Patient and Database
Assumptions	The patient is already logged into the system The database is successfully updated when the patient has an ED appointment The ED location exists The ED location supports showing the current load
Steps	Patient clicks the ‘Capacity’ tab Patient enters the location of a valid ED System calculates and displays estimated wait times for appointments and triages
Variations	N/A
Non-Functional	Performance: The system must return an estimated wait time within 500 milliseconds of receiving a request from a patient. Portability: This feature must be available on Android and iOS. Usability: The ‘Capacity’ tab must be visible from the homepage of the website/app. Availability: This feature must be available 99.90% of the year.
Issues	How will the estimated wait time be calculated? What must be done by ER operators to facilitate this feature?

Title	Content
Use Case	UC14 - Dispatch Ambulance
Description	EMTs respond to the received dispatch request to send an ambulance to the patient in need. Sources: [Project Idea]
Actors	EMT (Primary)
Assumptions	EMT is logged in EMTs are available to receive a dispatch request
Steps	Available EMT team receives a dispatch request notification EMTs opens dispatch request EMTs read the location and notes on the dispatch request EMTs click ‘Accept’ button on dispatch request Dispatch request is marked as "in progress" as EMTs who accepted are made unavailable for further requests EMT team departs to address specified in request After the request is resolved, an EMT opens dispatch request and presses "Close Request" Dispatch request is marked as "resolved" as EMTs for that request are made available for future requests
Variations	N/A
Non-Functional	Availability: Should have less than 6 minutes downtime per year (99.999% availability) since this is a critical medical system. Usability: Dispatch accept button available directly on the dispatch request screen, with minimal redirection to allow for fast response.
Issues	Will "unavailable" EMTs still receive notifications? Should there be a way to "decline" requests? What about EMTs who are not on call? How will EMTs coordinate requests?

Title	Content
Use Case	UC15 – Dispatch Request
Description	The nurse can send a dispatch request to the EMTs for a patient in need. Sources: [Project Idea]
Actors	Nurse (Primary) and EMT (Secondary)
Assumptions	Nurse has a strong internet connection Nurse is logged in to system An EMT is available to receive the request
Steps	Nurse enters dispatch request window Nurse enters location of incident Nurse enters additional info about the patient and their situation Nurse finalizes dispatch request Request confirmation is shown to the Nurse The request is sent to EMT team closest to location specified in the request
Variations	N/A
Non-Functional	Performance: The request must be sent to EMTs within 3 seconds of confirmation being shown to the nurse. Reliability: The dispatch system must be available 99.99% of the time. Reliability: In case of system failure, the system should automatically retry sending the dispatch request within 5 seconds and log the failure for review by the technical team. Reliability: In the case of system failure, the nurse will be notified to contact the EMT using other avenues. Security: All data related to the dispatch request (location, patient information, etc.) must be encrypted during transmission and storage. Only authorized personnel should have access to this data, and the system must comply with healthcare security regulations (e.g. HIPAA). Usability: The system should ensure that the nurse can complete the dispatch process in under 1 minute with minimal training. Usability: Clear error messages must be displayed if any required fields (e.g., location) are missing, and input validation should be performed before the request is submitted.
Issues	How will the Nurse know what information to include with the request?

Title	Content
Use Case	UC16 - View Schedule
Description	To understand the patient's situation, the doctor must be able to view the schedule of upcoming patients who have been determined to need care through the triage process. Sources: [Project Idea]
Actors	Doctor and Database
Assumptions	Patient is registered If the Patient has a medical history or triage results, that information is available in the Database
Steps	Doctor navigates to the page to view the schedule Doctor selects a patient from the schedule Database fetches patient medical history Doctor views the patient's medical history Database fetches the patient’s triage results Doctor views the triage results
Variations	4# There is no medical history available 6# There are no triage results available
Non-Functional	Response Time: The system must display the patient schedule and related information (medical history, triage results) within 2 seconds of a request. Performance: The system must be able to handle up to 100 concurrent users accessing the schedule without performance degradation. Security: Only authorized users should be able to access the schedule and view patient medical history or triage results. Privacy: The system must maintain the privacy of patient data, complying with healthcare regulations (e.g. HIPAA).
Issues	Medical history or triage results may not always be available for all patients, which could slow down the decision-making process.

Title	Content
Use Case	UC17 – Book Appointment
Description	Adds a record of when a patient will visit the ED. Sources: [Project Idea]
Actors	Nurse and Database
Assumptions	Nurse has a strong internet connection Nurse is logged in to the system
Steps	Nurse enters ‘Add Appointment’ window Nurse enters appointment type Nurse enters date of appointment Nurse enters actors associated with the appointment (Patient, Nurse, Doctor). Nurse enters notes about the appointment in text (e.g. patient symptoms) Nurse finalizes appointment Appointment confirmation is displayed Appointment is added to the database
Variations	1# The ‘Add Appointment’ window may display automatically as a step in another use case, or the Nurse will manually navigate to the window
Non-Functional	Usability: The ‘Add Appointment’ window must have an intuitive and user-friendly interface that allows the nurse to complete the process in under 2 minutes with minimal training. Usability: Form inputs should be clearly labeled, and any errors (e.g. missing fields) must be highlighted with clear instructions for correction. Data Integrity: The system must validate all inputs (e.g. appointment type, date, associated actors). No appointment should be added to the schedules unless all required fields are properly filled and validated. System Integration: Once the appointment is finalized, it must be synchronized across all relevant systems (e.g. the actors’ schedules, patient history, and hospital records) within 3 seconds.
Issues	How will scheduling conflicts be checked, if at all? How will the nurses know the format for each of the fields?

Title	Content
Use Case	UC18 - View Support Ticket
Description	The admin can view any tech support tickets created. Sources: [Project Idea]
Actors	Admin
Assumptions	Admin has privileges to view support tickets
Steps	Admin clicks on the system tab to bring up the system view Admin views support tickets and their status Admin clicks on an individual ticket Admin views specific details about the ticket
Variations	N/A
Non-Functional	Security: System information must not be displayed to users without correct authorization.
Issues	N/A

Title	Content
Use Case	UC19 - Close Support Tickets
Description	The admin can flag a particular ticket as closed if they have resolved the issue. Sources: [Project Idea]
Actors	Admin
Assumptions	Admin has privileges to close support tickets Admin has selected a particular ticket
Steps	Admin clicks the ‘Resolved’ button in the support ticket A message box is displayed Admin types out further details about the issue if necessary Admin clicks the ‘Submit’ button
Variations	N/A
Non-Functional	Security: User information gathered by the system for support functions must be encrypted.
Issues	There could be user statuses other than open and resolved.

Title	Content
Use Case	UC20 - View Notifications Sources: [Project Idea]
Description	Users view any notifications they may have
Actors	Admin, Doctor, Patient, or Nurse as USER
Assumptions	User is signed in to their account.
Steps	User clicks on the bell icon. User views any pending and previously viewed notifications.
Variations	N/A
Non-Functional	Availability: Notifications must be available 99.9% of the time. Security: All notifications should be encrypted during transmission.
Issues	N/A

Title	Content
Use Case	UC21 - Send Message
Description	The admin can send a message to other users. Sources: [Project Idea]
Actors	Admin
Assumptions	Admin has privileges to send messages
Steps	Admin clicks on the message icon. A message box is displayed. Admin types out the message they wish to send. Admin selects users to send the message to. Admin clicks the ‘Send’ button.
Variations	N/A
Non-Functional	Security: Messages must be encrypted.
Issues	N/A