UseCaseView - SENG-350-2024-fall/Team-8 GitHub Wiki

Use Case View

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.

Actors

  • Patients
  • Nurses
  • Doctors
  • EMTs
  • Administrators

Use Case Diagram

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

Patient Use Case Diagram

Nurse Use Case Diagram

Doctor Use Case Diagram

EMT Use Case Diagram

Admin Use Case Diagram

Use Case Descriptions

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

Create Account

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
  1. User clicks ‘Register’
  2. User enters details for registration (legal name, DOB, health #, address, contact info, email/password, role)
  3. User clicks ‘Finish’
  4. User clicks confirmation link sent to email
  5. 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?

Log In

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
  1. User opens the app and clicks ‘Login’
  2. User enters their credentials (username/email and password) into the relevant fields
  3. User clicks 'Login’ button
  4. User receives a code in their email
  5. User enters code in the app
  6. 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

Log Out

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
  1. User clicks ‘Log Out’
  2. 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

View Profile

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
  1. User clicks the profile icon
  2. User clicks profile information
  3. 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?

Edit Profile

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
  1. User clicks the profile icon
  2. User clicks profile information
  3. User makes changes to the fields
  4. 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?

Delete Account

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
  1. User navigates to their profile
  2. User clicks ‘Delete Account’
  3. System asks for confirmation
  4. User clicks ‘Yes’
  5. 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?

Change Account Permissions

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
  1. User clicks ‘Change Permission’
  2. System displays a pop-up with the different account options
  3. User chooses which account type and access level is appropriate
  4. User clicks ‘OK’
  5. System changes the account
Variations N/A
Non-Functional Performance: Changes should be validated within seconds after completion.
Issues N/A

View Logs

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
  1. User clicks on the system tab to bring up the system view
  2. System displays system metrics and logs with their status
  3. User clicks on individual log entry to get more detail
  4. 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

View Patient History

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
  1. User clicks ‘Patient History’
  2. System fetches patient history from the database
  3. User views a list of prior health assessments conducted using the system
  4. User selects one of these assessments
  5. 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?

Request Triage

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
  1. User clicks ‘Request Triage’
  2. User selects a hospital
  3. 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?

Contact Support

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
  1. User clicks ‘Contact Support’
  2. User is shown a dialog box
  3. User enters information regarding their issue and presses send
  4. 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

Triage

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?

View Current Load

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
  1. Patient clicks the ‘Capacity’ tab
  2. Patient enters the location of a valid ED
  3. 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?

Dispatch Ambulance

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
  1. Available EMT team receives a dispatch request notification
  2. EMTs opens dispatch request
  3. EMTs read the location and notes on the dispatch request
  4. EMTs click ‘Accept’ button on dispatch request
  5. Dispatch request is marked as "in progress" as EMTs who accepted are made unavailable for further requests
  6. EMT team departs to address specified in request
  7. After the request is resolved, an EMT opens dispatch request and presses "Close Request"
  8. 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?

Dispatch Request

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
  1. Nurse enters dispatch request window
  2. Nurse enters location of incident
  3. Nurse enters additional info about the patient and their situation
  4. Nurse finalizes dispatch request
  5. Request confirmation is shown to the Nurse
  6. 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?

View Schedule

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
  1. Doctor navigates to the page to view the schedule
  2. Doctor selects a patient from the schedule
  3. Database fetches patient medical history
  4. Doctor views the patient's medical history
  5. Database fetches the patient’s triage results
  6. 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.

Book Appointment

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
  1. Nurse enters ‘Add Appointment’ window
  2. Nurse enters appointment type
  3. Nurse enters date of appointment
  4. Nurse enters actors associated with the appointment (Patient, Nurse, Doctor).
  5. Nurse enters notes about the appointment in text (e.g. patient symptoms)
  6. Nurse finalizes appointment
  7. Appointment confirmation is displayed
  8. 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?

View Support Ticket

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
  1. Admin clicks on the system tab to bring up the system view
  2. Admin views support tickets and their status
  3. Admin clicks on an individual ticket
  4. 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

Close Support Tickets

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
  1. Admin clicks the ‘Resolved’ button in the support ticket
  2. A message box is displayed
  3. Admin types out further details about the issue if necessary
  4. 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.

View Notifications

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
  1. User clicks on the bell icon.
  2. 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

Send Message

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
  1. Admin clicks on the message icon.
  2. A message box is displayed.
  3. Admin types out the message they wish to send.
  4. Admin selects users to send the message to.
  5. Admin clicks the ‘Send’ button.
Variations N/A
Non-Functional Security: Messages must be encrypted.
Issues N/A
⚠️ **GitHub.com Fallback** ⚠️