Milestone 1 - SENG-350-2024-fall/Team-11 GitHub Wiki
Emergency departments (EDs) are often overwhelmed, leading to long wait times, delayed care, and stressed healthcare providers. Many visits are for conditions that could be managed elsewhere, adding unnecessary strain to the system. The Mister ED system addresses these challenges by offering a virtual triage platform that allows potential ED patients to assess their symptoms from home. This triage process provides treatment recommendations that could include visiting the ED or pursuing other care options, such as consulting a GP, managing symptoms with over-the-counter medications, or contacting a nurse/clinician hotline.
The Mister ED system is designed to reduce crowded and overloaded emergency departments. By directing patients to other treatment options where appropriate, the system helps to reduce wait times and patient load in emergency rooms. In addition to preventing unnecessary visits, virtual triage allows patients to complete assessments from home, empowering them to make informed decisions about their care.
Objectives:
1. Reduce ED Overload: By prioritizing urgent cases and diverting non-urgent patients to alternative care settings, the system helps alleviate pressure on emergency departments.
2. Provide Accessible Virtual Triage: Patients can remotely assess their condition, receiving tailored recommendations on whether to visit the ED, see a GP, manage with over-the-counter medications, or contact a nurse hotline.
3. Improve Patient Outcomes: By recommending the appropriate level of care, the system ensures timely treatment, reducing unnecessary ED visits and minimizing wait times.
4. Offer Alternative Treatment Courses: These include primary care visits, over-the-counter medication guidance, and consultations via a nurse or clinician hotline, promoting efficient and patient-centered care.
5. Enhance Coordination Among Stakeholders: The Mister ED system connects various healthcare stakeholders, enabling efficient communication and collaboration to improve patient care.
Register: Create an account with Mister Ed System if using first time.
Log In/Log Out: Access the system to update personal information, check triage results, and log out when done.
Undergo Virtual Triage (VT): Complete an online assessment to determine the urgency of their condition.
Choose Options: Based on the VT results, decide whether to visit the ED, go to a GP, take over-the-counter medication, or contact a nurse/clinician hotline.
Receive Notifications: Get alerts about the best time and location to visit the ED if necessary.
Use Case | 1.1 Patient registers account |
---|---|
Description | Patient creates an account with Mister MD |
Actors | Patient |
Assumptions | Patient lives in an area serviced my Mister MD Patient is alive Patient has an internet connection Patient has an email |
Steps | 1. Patient accesses website 2. Patient clicks “create account” button 3. Patient inputs their name 4. Patient inputs their location 5. Patient inputs their email 6. Patient inputs their password 7. Patient confirms their password (second input) 8. Patient submits account creation request 9. Patient receives successful confirmation |
Variations | Patient may receive an unsuccessful account creation message in case of invalid information |
Non-Functional Requirements | Fault Tolerance: Patients' data must remain secure. |
Issues | Can a patient input a phone number in case they do not have reliable wifi or if it is a more reliable method of contact? |
Use Case | 1.2 Patient logs in |
---|---|
Description | Patient logs into their account |
Actors | Patient |
Assumptions | Patient has an account Patient has internet connection |
Steps | 1. Patient accesses website 2. Patient clicks “log in” button 3. Patient inputs email 4. Patient inputs password 5. Patient clicks new “log in” button 6. Patient accesses their account |
Variations | N/A |
Non-Functional Requirements | N/A |
Issues | What if the system is down? What if something happens to the internet connection during the log in process? |
Use Case | 1.3 Patient needs care |
---|---|
Description | Patient needs care, and will be using the website to determine what degree of care they need |
Actors | Patient, anyone for end goal |
Assumptions | Patient is in need of care or aid. Patient has access to the website. Patient has an account The website is running. |
Steps | 1, Patient accesses website 2. Patient logs in 3. Patient logs symptoms 4. Patient submits symptoms to system 5. Patient clicks “Triage” 6. Patient is given suggestion(s) for care, or Patient is given an estimated wait time for care suggestions |
Variations | N/A |
Non-Functional Requirements | List of non-functional requirements that the use case must meet. |
Issues | What happens if patient lies, exaggerates,or excludes symptoms? How can we take input of symptoms? How can we assure all symptoms are treated, even bizarre ones? How can we ensure patients are inputting symptoms in a uniform enough way (ie describing something as “buzzing” vs “ringing” vs etc)? How do we account for medical history? |
Use Case | 1.4 Patient chooses care options |
---|---|
Description | Allow patient to make an informed decision on which care option is the best for them at the time. |
Actors | Patient |
Assumptions | Patient has submitted a virtual triage Patient fulfills all requirements outlined in 1.3 Patient is logged into their account |
Steps | 1. Patient views their virtual triage results 2. Patient views recommended options 3. Patient decides what option to take IF (one option given AND patient chooses an option) Patient goes to suggested care facility ELSE IF (multiple options given AND patient chooses an option) Patient chooses which care facility to go to ELSE IF (patient is not in need of further care) Patient remains as they are ELSE IF (patient chooses none of the options) IF (patient chooses a different care facility) Patient is responsible for dealing with that themselves ELSE IF (patent chooses to do nothing) Patient remains where they are, as they are END END 5. Patient waits at home for notification to go to care facility, orPatient heads to care facility to wait there |
Variations | Use case may end in step 4 if patient chooses none of the given options |
Non-Functional Requirements | N/A |
Issues | Can we provide an estimated wait time for each care option? |
Use Case | 1.5 Patient logs out |
---|---|
Description | 1.5 Patient logs out of their account |
Actors | Patient |
Assumptions | Patient has an account Patient has internet connection Patient is currently logged into their account |
Steps | 1. Patient clicks on log out button 2. Patient is logged out |
Variations | N/A |
Non-Functional Requirements | N/A |
Issues | What if the system is down? What if something happens to the internet connection during the log out process? |
Log In: Access the system to view patient registrations and triage results (Use Case same as 6.1 Admin_Log_in)
Log out: Log out from Mister Ed System (Use case same as 6.2 Admin_Log_out)
Manage Patient Flow: Prioritize and manage patient visits based on triage results.
Update Status: Provide real-time updates on ED load and patient status.
Communicate with Patients: Send notifications to patients about their appointment times and any changes.
Generate Reports: Create reports on patient flow, triage outcomes, and ED performance.
Use Case | 2.1 Manage patient flow |
---|---|
Description | Emergency department determines the order and type of care for patients based on the results in the ED system |
Actors | ED worker, ED System |
Assumptions | There are patients in the ED systemED worker is logged in |
Steps | ED worker looks over the patients in the ED systemED worker edits the queue of patients based on the patient’s symptomsED System updates wait times for each patient in queue |
Variations | N/A |
Issues | Could be automated more with some data processing in the ED system. If an ED worker doesn’t get to the queue in time, should notifications still be sent out to patients? |
Use Case | 2.2 Update Status |
---|---|
Description | Emergency department determines the load of patients in the ED, and updates the ED system |
Actors | ED worker, ED System |
Assumptions | ED worker is logged in |
Steps | ED workers keep track of patient load, and patients coming in and outED worker updates the status in the ED system with patient load |
Variations | If there is a status not related to patient load (i.e. if there’s a patient room that isn’t available or if they’re short staffed), they will also put this in the ED system |
Issues | If information isn’t updated regularly, patients will get wait times that may be incorrect. |
Use Case | 2.3 Communicate with patients |
---|---|
Description | ED worker communicates status of the ED and the patient’s expected wait time through ED system |
Actors | ED System, patient, ED worker |
Assumptions | Patient has filled out information formPatient load and status are up to date |
Steps | ED system gets patient load and status from databaseED system reaches out to client to show their wait time and any issues in the ED that might affect wait times |
Variations | If custom messages need to be sent out, ED workers can manually send messages to patients |
Issues | Patient may not be checking regularly and miss an update on their wait time. |
Use Case | 2.4 Generate reports |
---|---|
Description | Generates reports for patient’s triage, patient load, status, and ED performance from information in database |
Actors | ED System, User |
Assumptions | ED database is up to date |
Steps | User (ED worker or patient) logs inUser clicks on Reports tab 2.1. List of report options shows up (Triage results, Patient load, ED status, ED performance) 3. User selects a report 4. IF user has correct permissions 4.1. ED system contacts database for relevant information 4.2. ED system processes information and displays a report 5. ELSE Pop up says “You do not have the correct permissions to view this report.” |
Variations | If a user has an account, but has not filled out the form and been triaged, generating a triage results form will also show an error message saying: “You will need to fill out a triage form before you are able to view this report”. |
Issues | Information may be out of date if it isn’t being updated regularly |
Log In: Access the system to view patient registrations and triage results (Use Case same as 6.1 Admin_Log_in)
Log out: Log out from Mister Ed System (Use case same as 6.2 Admin_Log_out)
Receive Referrals: Get notified when patients are directed to them instead of the ED.
Access Patient History: Review patient history and triage results to provide informed care.
Provide Care: Offer appropriate medical care based on the patient’s needs.
Update Patient Records: Keep patient records updated with the care provided.
Communicate with ED: Coordinate with the ED for any necessary follow-up or referrals.
Use Case | 3.1 Clinician Login |
---|---|
Description | Access the system to view patient registrations and triage reults |
Actors | Clinic, ED System |
Assumptions | - Clinician has valid credentials and account within system - Multi-factor authentication (MFA) has been enabled - The system is accessible and functioning properly |
Steps | 1. Clinician navigates to Mister Ed system login page 2. Clinician enters username and password 3. System verifies credentials 4. IF the credentials are correct THEN 4.1 System prompts for MFA (e.g. with authenticator app or code via SMS) 4.2 Clinician enters authentication code 4.3 System grants access to Clinician page 5. IF credentials or MFA code are incorrect THEN 5.1 System displays error message and allows retry 5.2 Clinician may select "Forgot Password" option to reset password if needed |
Variations | - If MFA is disabled or not required, system proceeds directly to Clinician page after credential verification - Login may be attempted multiple times, after a number of failed attempts system may lock account temporarily -Password reset function may send email to Clinician with reset instructions |
Non-Functional Requirements | Security: All login credentials and authentication codes must be transmitted over encrypted connections (e.g. HTTPS) Performance: Login process, including MFA, should take no longer than 10 seconds Availability: System should be accessible 24/7 |
Issues | How should system handle repeated failed login attempts? What should happen if Clinician does nor have access to MFA method? |
Use Case | 3.2 Clinician Logout |
---|---|
Description | Clinician logs out of Mister Ed system to securely end session and prevent unauthorized access |
Actors | Clinic, ED System |
Assumptions | - Clinician is logged into system - System requires explict logout to end session |
Steps | 1. Clinician selects "Logout" option 2. System ends active session and logs out Clinician 3. System redirects Clinician to login page 4.System ensures that no session data or personal information is stored on device or browser 5. Clinician receives confirmation of successful logout |
Variations | Clinician may be automatically logged out after a set period of inactivity |
Non-Functional Requirements | Security: Logout actions must completely clear session information and prevent re-access without new login Performance: Logout process should take no longer than 5 seconds |
Issues | What happens if Clinician forgets to log out and system is left active on shared device? |
Use Case | 3.3 Receive Referrals from Mister Ed System |
---|---|
Description | The primary clinic will be notified when patients are directed to them and receive basic patient information |
Actors | Clinic, ED System |
Assumptions | - The clinic is available to receive patients - A patient requires non-emergency medical care - Clinician is logged out of system |
Steps | 1. Clinician logs in to system 2. Ed system sends notification of referral 3. Clinician clicks on notification 4. Clinician selects option to view full referral 5. Clinician reviews patient information and care needs 6. Clinic prepares to treat patient |
Variations | If clinician is already logged in, login step is bypassed |
Non-Functional Requirements | Performance: System should take no longer than 10 seconds to view full referral information Accuracy: Patient data provided to clinician should be accurate and up to date |
Issues | Clinic wait times may cause delays in patient treatment |
Use Case | 3.4 Access patient history |
---|---|
Description | The primary care clinic will review patient medical history and triage results to provide informed care |
Actors | Clinician, Patient, Ed system |
Assumptions | - Patient has accurately inputted medical information and symptoms to virtual triage - Patient has been referred to primary care clinic by Mister Ed system |
Steps | 1. Clinician logs in to Ed system 2. Clinician opens "Referrals" page 3. Clinician selects patient's referral 4. Clinician views patient information, medical history on file, and symptoms |
Variations | Clinic may reach out to patient beforehand via phone or email to confirm contact information and set expectations for visit |
Non-Functional Requirements | Security: Patient data should be securely transferred and stored Integration: System might integrate with clinic system to pull information from both sources if patient has previously visisted clinic |
Issues | Potential risk of delays or errors in updating patient records Patient symptoms may change or escalate after completing virtual triage, but before visiting clinic |
Use Case | 3.5 Clinic provides care |
---|---|
Description | The patient visits the primary care clinic, where they are provided medical care |
Actors | Clinician, Patient, Ed system |
Assumptions | - Clinic is available to receive and treat patient - Patient is willing and able to travel to primary care clinic |
Steps | 1. Clinician logs in to system 2. Clinician receives notification of referral 3. Clinician opens Referrals page 4. Clinician selects patient's referral 5. Clinic prepares for patient visit 6. Patient arrives at clinic 6. Clinician provides patient with treatment |
Variations | N/A |
Non-Functional Requirements | Security: Patient data should be securely transferred and stored |
Issues | Patient's symptoms may worsen, causing them to be unable to visit clinic Clinic wait times may cause delays in treatment of patient |
Use Case | 3.6 Update Patient Records |
---|---|
Description | Clinic updates patient records with care provided during visit |
Actors | Clinician, Patient, Ed system |
Assumptions | - Patient has visited clinic and received care - Clinic has the abilitiy to access and update patient information in Ed system - Clinician is currently logged out |
Steps | 1. After visit, clinician logs in to Ed system 2. Clinician opens Referrals page 3. Clinician selects patient's referral 4. Clinician clicks "Update" option 5. Clinician updates record with provided care 6. System prompts Clinician to review and confirm information is correct 7. Clinician verifies information and submits |
Variations | Clinic may have its own system that integrates with Mister Ed to automatically sync updates System may send notification to patient when records are updated |
Non-Functional Requirements | Security: Patient data should be securely transferred and stored Audit Trail: System should provide audit trail of changes made to patient records Performance: System should allow real time (~10s) updates to records |
Issues | Potential risk of delays or errors in updating patient records Clinician may not have access to information from previous visits |
Use Case | 3.7 Communicate with Ed System |
---|---|
Description | Clinic communicates with Ed system to coordinate follow up visits or provide updates |
Actors | Clinician, Patient, Ed system |
Assumptions | - Patient has visited clinic and received care - Patient requires follow up care or additional referral - Clinician is currently logged out |
Steps | 1. Clinician logs in to Ed system 2. Clinician opens Referrals page 3. Clinician selects patient's referral 4. Clinician clicks "Update" option 5. Clinician updates record with provided care 6. System prompts Clinician to review and confirm information is correct 7. Clinician verifies information and submits |
Variations | Clinic may have its own system that integrates with Mister Ed to automatically sync updates System may send notification to patient when records are updated |
Non-Functional Requirements | Security: Patient data should be securely transferred and stored Audit Trail: System should provide audit trail of changes made to patient records Performance: System should allow real time (~10s) updates to records |
Issues | Potential risk of delays or errors in updating patient records Clinician may not have access to information from previous visits |
Log In: Access the system to view patient registrations and triage results (Use Case same as 6.1 Admin_Log_in)
Log out: Log out from Mister Ed System (Use case same as 6.2 Admin_Log_out)
Assist with Triage: Help in the virtual triage process if needed.
Follow up with patients: Nurses follow up with patients who have been triaged to ensure they are following the recommended course of action
Create in-person appointments: Create in-person appointment for the patient over the phone calls.
Updates patient medical information: Records any changes in the patient's condition or treatment.
Check patient wait time: Nurses can view patient appointment wait time
Use Case | 4.1 Assist with Triage |
---|---|
Description | Nurses assist with triaging patients when they visit clinics. |
Actors | Nurse (primary) Patient |
Assumptions | -Patients will visit clinic when they need to be triaged in person -Nurses are trained to use the Mister Ed to complete triage -Patient will complete online registration before they visit the clinic |
steps | 1. Patient visits clinic 2. Nurse login to the system 3. Nurses find patient information in the system using patient name 4. Nurse complete triaging |
Issues | What happens if nurses are not available when patient visit clinic? |
Use Case | 4.2 Follow up with patients |
---|---|
Description | Nurses follow up with patients who have been triaged to ensure they are following the recommended course of action |
Actors | Nurse (primary) Patient |
Assumptions | -Patient is already registered in system and completed virtual triage |
steps | 1. Nurse logon to the system 2. Nurse search for patient information in the system using patient name 3. Nurse contacts the patient using their preferred method of communication 4. Nurse update the system when follow-up is completed |
Variations | Nurse may look up the patient details in the system using personal health number |
NF | N/A |
Issues | What happens if patient is not available when nurse try to contact them? |
Use Case | 4.3 Create in-person appointments |
---|---|
Description | Create in-person appointment for the patient over the phone calls |
Actors | Nurse (primary) Patient |
Assumptions | -Nurses always answer clinic hotline number -Patients are already registered and completed virtual triage |
steps | 1.Patient calls clinic hotline number 2. Nurse answer the call 3. Nurse logon to the system 4. Nurse searches for patient information the Mister Ed system using patient name 5. Nurse creates new appointment 6. Nurse updates patient information in the system 7.System sends a message to the patient with appointment details. |
Variations | -Nurse may look up the patient details in the system using personal health number -Patients may reach out to nurse via clinic email |
NF | Performance: All patient requests via clinic hotline number or emails must be answered within 3 hours of request |
Issues | What happens if nurses are not available to answer calls? |
Use Case | 4.4 Updates patient medical information |
---|---|
Description | Nurse records any changes in the patient's condition or treatment |
Actors | Nurse (primary) |
Assumptions | -Nurse have access to the system -Patient have already registered and completed virtual triage |
steps | 1. Nurse answers clinic hotline number 2. Nurse logon to the system 3. Nurse searches for patient information in the system using patient name 4. Nurse records any new information |
Variations | - Nurses may add any new information when they call an existing patient for follow-up. |
NF | Auditability: Any modification to patient data must be accurately recorded with a date and time |
Issues | How can the system maintain confidentiality of patient data? |
Use Case | 4.5 Check patient wait time |
---|---|
Description | Nurses can view patient appointment wait time. |
Actors | Nurse (primary) |
Assumptions | Nurses have access to the system to view appointment details -Patients are already registered and completed triage |
steps | 1.Nurse logon to system 2.Nurse looks up patient appointment details using patient name 3.Nurse finds the approximate wait time |
Variations | N/A |
NF | Performance: system should update patient wait times in real-time, so nurses can provide accurate information. |
Issues | How can the system verify that nurses can only access patient data necessary for their role? |
Chemist_Log_in: Log into the Mister Ed System account (Use Case same as 6.1 Admin_Log_in)
Chemist_Log_Out: Log out of the Mister Ed System account (Use case same as 6.2 Admin_Log_out)
Receive_Prescriptions: Get notified of prescriptions from GPs or EDs for patients.
Dispense_Medication: Provide prescribed medications to patients.
Offer_Advice: Give advice on over-the-counter medications and their proper use.
Filter_Prescriptions: filter and organize prescriptions based on various criteria (e.g., urgency, medication type, or prescription status)
Coordinate_with_Healthcare_providers: Communicate with GPs and EDs about patient prescriptions and any potential issues.
Use Case | 5.1 Receive_Prescriptions |
---|---|
Description | Receive prescriptions from Primary Care Clinics or Emergency Departments after virtual triage. |
Actors | Chemist (primary), Primary Care Clinics, Emergency Departments |
Assumptions | Chemists can view electronic prescriptions in the Mister Ed System. |
Steps | 1. IF Chemist is logged in THEN: 1.1 System sends a notification for new prescription. 1.2 Chemist clicks on Notification. ELSE: 1.3 Chemist selects login option. 1.4 System prompts credentials entry. 1.5 Chemist provides credentials. 1.6 System authenticates Chemist. 1.7 Chemist selects “View Prescriptions.” 1.8 Chemist selects relevant prescription. 2. System opens prescription details. |
Variations | Notifications may be received via email, mobile app, or in-system alert, depending on preferred communication method. |
Non-Functional Requirements | Performance: Notifications must be received within 5 minutes of prescription generation. Fault Tolerance: System must handle failures without data loss. |
Issues | What protocol should be followed if immediate modification of the prescription is required? |
Use Case | 5.2 Dispense_Medication |
---|---|
Description | Dispense medication after reviewing and approving a prescription received via the Mister Ed system. |
Actors | Chemist (primary), Primary Care Clinics, Emergency Departments, Patient |
Assumptions | Chemist is logged in and prescriptions are valid and approved by a healthcare provider. |
Steps | 1. Chemist selects “View Prescriptions.” 2. System shows prescription list. 3. REPEAT: 3.1 Chemist selects prescription. 3.2 Checks medication availability. IF available THEN: 3.3.1 Chemist prepares medication. 3.3.2 Logs action and confirms dispensing. 3.3.3 System notifies patient. ELSE: 3.3.4 Notifies patient and provider of unavailability. UNTIL all prescriptions are processed. |
Variations | Patients may request delivery instead of pickup. Prescription adjustments may be required for allergies. |
Non-Functional Requirements | Performance: Dispensing must be confirmed within 2 minutes of preparation. Reliability: System logging must be 100% accurate. |
Issues | How should the system handle stock discrepancies between physical inventory and system data? |
Use Case | 5.3 Offer_Advice |
---|---|
Description | Give advice on OTC medications and their use after virtual triage. |
Actors | Chemist (primary), Patient |
Assumptions | Chemist and patient are logged into the Mister Ed system. Virtual Triage determined OTC medication as appropriate. |
Steps | 1. Patient clicks on “My Prescriptions” and selects “Advice Needed.” 2. Chemist receives notification of status change. 3. Chemist views prescription and selects it. 4. Chemist adds advice in comment section and sends. 5. System notifies patient. |
Variations | N/A |
Non-Functional Requirements | Performance: Urgent advice requests should be addressed within 5 minutes. Security: Communications must be encrypted. |
Issues | What should the protocol be if the patient disagrees with or questions the advice? |
Use Case | 5.4 Filter_Prescriptions |
---|---|
Description | Filter and organize prescriptions based on criteria within the Mister Ed system. |
Actors | Chemist (primary) |
Assumptions | Chemists and EDs/Clinics have access to the system and are logged in. |
Steps | 1. Chemist logs into the system. 2. Chemist selects “View Prescriptions.” 3. System displays all prescriptions. 4. Chemist clicks “Filter.” 5. System shows filtering criteria. 6. Chemist selects criteria and sorts. 7. System displays filtered prescriptions. |
Variations | Chemist may save custom filters or apply multiple filters simultaneously. |
NF | Performance: Filtering should take no more than 2 seconds. Usability: Filters must be configurable and customizable. |
Issues | Should the system recommend filters based on time-sensitive prescriptions or preferences? |
Use Case | 5.5 Coordinate_with_Healthcare_providers |
---|---|
Description | Communicate with EDs or Clinics to resolve prescription or medication availability issues. |
Actors | Chemist (primary), Primary Care Clinics, Emergency Departments |
Assumptions | Chemists and EDs/Clinics have secure, real-time communication through the system. |
Steps | 1. Chemist selects “View prescriptions.” 2. Chooses a prescription needing clarification. 3. Selects "Coordinate with Provider." 4. System shows providers list. 5. Chemist selects provider. 6. Opens secure communication window. 7. IF provider responds THEN Chemist reviews response and updates prescription. ELSE System prompts follow-up. |
Variations | Providers may update prescriptions without Chemist’s initial communication. |
Non-Functional Requirements | Availability: System must operate 24/7. Reliability: Secure, uninterrupted communication. |
Issues | What if the provider is unavailable due to scheduling or time zone differences? |
Admin_Log_in: Log into the system
Admin_Log_out: Log out of the system
View User Accounts: View user accounts within the Mister Ed system.
Add User Account: Add new user accounts to the Mister Ed system.
Disable/Delete User Account: Disable or delete user accounts within the Mister Ed system.
View_Audit_logs: View audit logs to monitor user activities and system changes.
Update_System_Configuration: Admin updates system settings, including notification preferences, user roles, and triage protocols.
Use Case | 6.1 Admin_Log_in |
---|---|
Description | Process for an Admin to securely log into the Mister Ed system to access patient prescriptions and other essential data. |
Actors | Admin (primary) |
Assumptions | Admin has valid credentials and accounts within the Mister Ed system. Multi-factor authentication (MFA) is enabled for enhanced security. The system is accessible and functioning properly. |
Steps | 1. Admin navigates to the Mister Ed system login page. 2. Admin enters their username and password. 3. The system verifies the credentials. 4. IF the credentials are correct THEN 4.1 The system prompts for MFA (e.g., an authentication code sent via SMS or an authenticator app). 4.2 Admin enters the authentication code. 4.3 The system grants access to the Admin’s dashboard. 5. IF the credentials or MFA code are incorrect THEN 5.1 The system displays an error message and allows the Admin to retry. 5.2 The Admin may select the "Forgot Password" option to reset their password if needed. |
Variations | If MFA is disabled or not required, the system will proceed directly to the dashboard after credential verification. The Admin may attempt to log in multiple times if they fail, and after a number of failed attempts, the system may temporarily lock the account for security reasons. Password reset functionality may send an email to the Admin with instructions for resetting their password. |
Non-Functional Requirements | Security: All login credentials and authentication codes must be transmitted over encrypted connections (e.g., HTTPS). Performance: The login process, including MFA, should take no longer than 10 seconds. Availability: The system should be accessible 24/7. |
Issues | How should the system handle repeated failed login attempts? What should happen if the Admin does not have access to their MFA device? Should the system alert Admins if there are login attempts from unknown locations or devices? |
Use Case | 6.2 Admin_Log_Out |
---|---|
Description | Admin logs out of the Mister Ed system to securely end their session and prevent unauthorized access. |
Actors | Admin (primary) |
Assumptions | The Admin is logged into the system and has completed their tasks. The system requires an explicit logout to end the session. |
Steps | 1. Admin selects the “Logout” option from the system’s menu. 2. The system ends the active session and logs out the Admin. 3. The system redirects the Admin to the login page. 4. The system ensures that no session data or personal information is stored on the device or browser, clearing cookies and temporary data. 5. Admin receives confirmation that the logout was successful. |
Variations | The Admin may be automatically logged out after a period of inactivity (e.g., 15 minutes of no activity). |
Non-Functional Requirements | Security: Logout actions must completely clear session information and prevent re-access without a new login. Performance: The logout process should take no longer than 5 seconds. |
Issues | What happens if an Admin forgets to log out and leaves the system active on a shared device? |
Use Case | 6.3 View User Accounts |
---|---|
Description | Admin views user accounts within the Mister Ed system. |
Actors | Primary Actor: Admin Secondary Actor: Primary Care Clinics, Emergency Departments, Patient, Nurse, Chemist |
Assumptions | Admin is logged into the system with the necessary permissions. Admin has access to the user management module. |
Steps | 1. Admin logs into the Mister Ed system. 2. Admin navigates to the “User Management” section. 3. Admin views the list of user accounts. 4. Admin can filter users by role, status, or other criteria. |
Variations | N/A |
Non-Functional Requirements | Security: Only authorized Admins should have access. Performance: User list should load within a few seconds. |
Issues | How can Admins ensure that the displayed user data is current and accurate? |
Use Case | 6.4 Add User Account |
---|---|
Description | Admin adds new user accounts to the Mister Ed system. |
Actors | Primary Actor: Admin Secondary Actor: Primary Care Clinics, Emergency Departments, Patient, Nurse, Chemist |
Assumptions | Admin is logged into the system with the necessary permissions. Admin has access to the user management module. |
Steps | 1. Admin logs into the Mister Ed system. 2. Admin navigates to the “User Management” section. 3. Admin clicks “Add New User.” 4. Admin fills in the required and optional fields and hits “Submit.” 5. System validates the information and adds the new user. 6. System confirms the user has been successfully added. |
Variations | Admin might encounter validation errors when adding users (e.g., missing required fields, invalid email format). |
Non-Functional Requirements | Security: Only authorized Admins should have access. Audit: All actions must be logged. Performance: Actions should be processed within a few seconds. |
Issues | N/A |
Use Case | 6.5 Disable/Delete User Account |
---|---|
Description | Admin disables or deletes user accounts within the Mister Ed system. |
Actors | Primary Actor: Admin Secondary Actor: Primary Care Clinics, Emergency Departments, Patient, Nurse, Chemist |
Assumptions | Admin is logged into the system with the necessary permissions. Admin has access to the user management module. |
Steps | 1. Admin logs into the Mister Ed system. 2. Admin navigates to the “User Management” section. 3. Admin selects a specific user account. 4. Admin clicks “Delete” or “Disable.” 5. System prompts for confirmation. 6. IF Admin confirms THEN 6.1 System deletes or disables the user account. 6.2 System confirms the action. |
Variations | Admin may choose to disable rather than delete the user account based on policy. |
Non-Functional Requirements | Security: Only authorized Admins should have access. Audit: All actions must be logged. Performance: Actions should be processed within a few seconds. |
Issues | How can accidental deletions be prevented? |
Use Case | 6.6 View_Audit_logs |
---|---|
Description | Admin views audit logs to monitor user activities and system changes. |
Actors | Primary Actor: Admin |
Assumptions | Admin has access to audit logs and is logged in. |
Steps | 1. Admin navigates to the “Audit Logs” section. 2. Admin selects filters (e.g., date range, user type) to narrow down the logs. 3. Admin reviews the logs, looking for specific actions or anomalies. 4. IF suspicious activity is detected THEN 4.1 Admin marks the activity for further review. 4.2 Admin may initiate follow-up actions (e.g., password reset, user suspension). |
Variations | Admin can export logs for offline review or compliance purposes. |
Non-Functional Requirements | Performance: Logs should be accessible with minimal delay, even for large data sets. Security: Only authorized Admins should be able to view or export logs. |
Issues | How to handle logs that become too large over time? Archival or auto-cleanup policies may be needed. |
Use Case | 6.7 Update_System_Configuration |
---|---|
Description | Admin updates system settings, including notification preferences, user roles, and triage protocols. |
Actors | Primary Actor: Admin |
Assumptions | Admin is logged in and has permissions to modify system settings. |
Steps | 1. Admin accesses the “System Configuration” menu. 2. Admin selects the module to update (e.g., Notifications, Triage Protocols). 3. REPEAT 3.1 Admin makes the required changes (e.g., update notification frequency). 3.2 Admin reviews and validates the changes. 3.3 Admin saves the changes. 3.4 The system confirms the update was successful. UNTIL all desired configurations are updated. |
Variations | Some settings may require a system restart or refresh to take effect. |
Non-Functional Requirements | Reliability: Configuration changes should not disrupt ongoing system operations. Traceability: All changes should be logged with timestamps for audit purposes. |
Issues | Managing potential conflicts when multiple Admins update configurations simultaneously. |
Isha Tanwar - Responsible for some parts of the system description, and for completing the textual descriptions and use case diagram for the Chemist and Admin actors.
Kaitlyn Rafter - Responsible for some parts of system description and for textual descriptions and use case diagram for Primary Care Clinic actor.
Treesa Sabu - Responsible for textual descriptions and use case diagram for Nurse actor.
Myfanwy Warren - Responsible for textual description for Patient actor use cases, associated diagram for patient, and partial diagrams for Chemist and Admin.
Cameron Cosbey - Responsible for textual description and use case diagram for the Emergency Department primary actor.