UseCaseView - SENG-350-2024-fall/Team-8 GitHub Wiki
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Steps |
|
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 |
|
Actors | Admin, Doctor, Patient, or Nurse as USER |
Assumptions | User is signed in to their account. |
Steps |
|
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 |
|
Steps |
|
Variations | N/A |
Non-Functional | Security: Messages must be encrypted. |
Issues | N/A |