Milestone 4: Implementation Discussion - SENG-350-2024-fall/Team3 GitHub Wiki

Milestone 4 is the final sprint of the project and will focus on completing the branch merges, implementing bug fixes and new features, as well as improving the already existing systems. The merging of the branches will be the primary focus for the sprint, as it is by far the most complex. A lot of the team's work is currently contained on separate branches, using different designs, database models, and code approaches. The idea is to try and implement all of the work we have done in milestone 2 and 3 into a single functioning branch while retaining and adjusting the systems within the branch and making them work together seamlessly. In addition, a number of features in the code are currently implemented more as placeholders and are missing the necessary implementation to make them functional. The goal for this milestone is to polish out such features to allow for a more complete user view-based experience. Finally, the system currently lacks, the ability to schedule virtual clinic appointments, as well as there is no clear implementation in the work for the Emergency Departments. The final objective is to try and implement a smarter system for the triage evaluation, the current system works off of points, where each box ticked provides a certain point value, which while predictable, is linear and will have trouble adjusting to the wide variety of problems that could be submitted to the virtual triage. The goal for this milestone is to implement a smarter analysis system that has been in the works since milestone 3, but is not quite complete yet. In addition, the milestone aims to add admin and staff side logins and webpages. For those, the primary goal is to develop the essential systems, and be able to showcase that it can appropriately redirect users, staff, and admins.

The end of the final sprint saw a lot of implementations, reimplementations, fixes and adjustments. However, despite the complexity of the goals set for milestone 4, all of the goals have been met. The system now contains fully established models for the User, Patient, Clinic, Doctor, Schedule, and ED. Features such as logout of the account which were just placeholders before, are now completely implemented and work flawlessly with the rest of the system. The resources page, profile view, and medical records view are now integrated into the home page with the newer version of the webpage design and layout which had to be merged with the primary branch that used the older UI design. The triage has also been improved. It now involves a submission box where the users can better describe the problem that they are having. The triage analysis now contains the fully implemented incorporation of ChatGPT's API, through the use of careful promoting, and response parsing, the system can send the triage to the LLM and receive a response regarding the appropriate course of action. This made the system much more adaptable to the different types of scenarios that it can encounter. MisterED now also supports the making of Virtual meeting appointments, this has been made possible with improved Schedule models for the database, and improved data injection scripts that provide data on the meetings. Whenever a meeting is scheduled, the database is updated appropriately. Whenever a visit to the ED is recommended, the system will first redirect the user to the page that showcases the queues and the loads in each ED, for each ED, the user is able to view details and enqueue. This information is updated in real-time, and the user is able to see how the load and queue changes. Whenever the user decides to proceed with a certain ED, and the user clicks 'View Details', another ChatGPT query is used to determine the appropriate position for the user in the queue. It will showcase what each user is in the list with, specifically where they are in the queue and what is the problem that they are coming there with. The users determined position in the queue, is also visualized. Here the user has the option of either proceeding with waiting in the queue, or coming back to the list of the ED's. If the user decides to proceed, the user is sent to the next page that shows the position in the queue, whenever the queue position reaches zero, the user is prompted to proceed to the ED, with an appropriate email being sent to the user over an SMTP connection confirming the ED visit and includes some general details. For the general overview of the application, the design has been made consistent throughout the entire application making it easier to learn and more intuitive. Previous bugs and problems were solved, with some of them being resolved due to the complexity of the merging which often required complete code rewrites as the two merges were simply incompatible. Finally, the system now contains a more flushed-out flow of the application from the users side, being able to access a wide variety of resources and having a worked-out flow from the very start where the user logs, to the end, where the virtual triage is complete, and the patient makes the next step of actions to resolve the issue that they are having. Overall, all of the goals were reached by the end of this milestone's sprint. Finally, the system has now been set up and developed to have different types of users, specifically users, staff, and admins. Judging by who has logged in, the system will appropriately send the user either to the home page, the staff dashboard, or the admin dashboard. The staff dash board contains general user information for the doctor, while the admin dashboard contains a wide variety of information, such as the loads, users, doctors, and doctor information. In addition if they have access to the database through an application such as Dbeaver, they are able to modify, add, and delete schedules, users, doctors, and other entries in the database. For example for schedules, it could be setting certain appointments from booked to available, and from virtual to in person. Now through the project, the team has considered the user side to be the primary focus of the implementation. However, the following implementation demonstrates the implementation of the complex part of the system that determines the types of users and redirects them accordingly. In general, the team was able to meet all of the goals for set by the system description as well as during the start of the sprint.