Component View - SENG-350-2024-fall/Team-8 GitHub Wiki
Component View
Primary Presentation
Element Catalog
Homepage Subsystem
The Homepage subsystem showcases the process of a user logging into the system and the different services that they have access to. Each user role (Patient, Nurse, Doctor, EMT, Admin) will have their own homepage where only select services required for their role will be available to them.
| Element Name | Description |
|---|---|
| User | A required interface that represents different users (Patient, Nurse, Doctor, EMT, Admin) accessing the system. |
| Authentication | A component that represents the authorization process when a user attempts to log into the system. |
| User Session | A required interface that represents the user session that gets established after a user is authorized. |
| User GUI | A component that represents the Homepage View which a unique for each type of user (Patient, Nurse, Doctor, EMT, Admin). |
Triage Service Subsystem
The Triage Service subsystem showcases the process of a patient joining the triage queue, waiting for their triage form to get reviewed by the nurse. Depending on the results of the triage, system will either use the Appointment Service or the Dispatch Service.
| Element Name | Description |
|---|---|
| Patient | A required interface that represents the patient requesting an online triage. |
| Triage Queue | A component that represents the real-time queue in which patients have to wait for their turn for a triage. |
| Triage Form | A required interface that represents the triage form that a patient needs to fill out for nurses to assess. |
| Triage System | A component that represents the process in which nurses access triage forms and determine the triage results. |
Appointment Service Subsystem
The Appointment Service subsystem showcases the process of a nurse booking an appointment for the patient to come in-person to the hospital.
| Element Name | Description |
|---|---|
| Triage Results | A required interface that represents the patient's results of their triage. |
| Appointment | A component that represents the appointment process in which a nurse determines when a patient can come in to the hospital. |
Dispatch Service Subsystem
The Dispatch Service subsystem showcases the process of an emergency occurring where a nurse determines that the patient needs an ambulance and the EMT is notified and dispatched to the patients location.
| Element Name | Description |
|---|---|
| Triage Results | A required interface that represents the patient's results of their triage. |
| Dispatch Request | A component that represents the process of an EMT receiving a dispatch request and then dispatching to the patient's location. |
| EMT | A required interface that represents the EMT accessing dispatch requests. |
Assessment Service Subsystem
The Assessment Service subsystem showcases the process of viewing/adding/updating patient assessments into the system. This service allows for users to view assessments, with patients only viewing their own assessments while nurses and doctors can view all patient assessments.
| Element Name | Description |
|---|---|
| Triage Results | A required interface that represents the patient's results of their triage. |
| Patient Assessment | A required interface that represents a patient assessment saved in the system. |
| Assessment System | A component that represents the process of traversing/viewing the patient assessments in the system. |
| Assessment Search | A required interface that represents a user searching for assessments. |
| Search Engine | A component that represents the system process of searching through patient assessments. |
| Search Assessments | A required interface that represents the search results of the patient assessments. |
Support System Subsystem
The Support System subsystem showcases the process of creating/viewing tickets of issues that users have. Users (Patient, Nurse, Doctor, EMT) can create tickets while admins can view and complete tickets.
| Element Name | Description |
|---|---|
| Create Ticket | A required interface that represents the create ticket form that the user fills out. |
| Ticket Queue | A component that represents the process of a ticket getting added into the database. |
| Ticket | A required interface that represents a ticket being retrieved from the database. |
| Tickets | A component that represents the process of viewing tickets sent in by users. |
| Ticket Search | A required interface that represents an admin searching through tickets. |
| Search Engine | A component that represents the system process of searching through tickets. |
| Search Tickets | A required interface that represents the search results of the tickets. |
Account System Subsystem
The Account System subsystem showcases the process of creating accounts and getting stored in the system database.
| Element Name | Description |
|---|---|
| Manage Account | A required interface that represents the system requesting accounts stored in the database. |
| Accounts | A component that represents the process of retrieving/adding accounts in the system database. |
| Account | A required interface that represents a user account. |
| Create Account | A component that represents the process of creating a user account. |
Variability Guide
The following variability points highlight where the system can be parameterized and reconfigured to ensure the architecture remains adaptable to evolving demands while ensuring availability, security, modifiability, and usability.
- The Triage Service subsystem can be built to support multiple different triage protocols to support different triage standards and ensure that any changes to standards are easily reconfigured.
- The role-based access control of users can be reconfigured dynamically via an admin panel to changes in policies.
- The Appointment Service subsystem can be integrated with external calendars via calendar APIs to improve usability and availability for users comfortable using other tools.
- The system can be built to support multiple languages for UI and triage process to enhance system usability for many different users.
Other Information
The following list outlines the description and rationale for important design decisions, including relevant rejected alternatives.
- Triage Process
- Decision: A patient will fill out a triage form and the form will be placed in a queue. Asynchronously, the nurse will review triage forms from the queue. The patient will be notified of the triage results.
- Rationale: With an asynchronous process, the system will have a reduced load to process information, especially during flu season. This will also maximize nurse efficiency by avoiding bottlenecks caused by real-time interactions. Lastly, patients can complete the triage forms at their own convenience, reducing wait times.
- Rejected Alternative: Originally, we discussed that patients and nurses should be on call, synchronously, to virtually perform the triage. However, on further review, it was clear that more server resources would be needed to ensure that the performance of the system would be stable and reliable for all patients during peak hours.
- Account Creation
- Decision: Patients and admins are the only users to create accounts within the system.
- Rationale: The system is intended to be integral in the triage process for hospitals. Such a system should be setup by admins when onboarding new staff to ensure that everyone has access to the system.
Related Views
NOTE: May need to update this section once the rest of the views are created.