In this project, our team, summerCubs, creates a general hospital dashboard, particularly used for resource allocation and medical assistant purposes.
Authentication To log in into this project, the user has to enter with their email and password (register if they did not have any). For the authentication, we are using Knox Django Library to implement a more secure token-based authentication rather than using the default token generated by the Django Rest Framework (DRF)
Authorization There are three different roles for a user model with different functionalities.
Patient -> Access to chatbot as medical assistant and feedback form MedicalStaff -> Access to the entire dashboard, including the chatbot Admin -> administrative role that manages user account and the Django ORM Model Databases
On default, any email registered through the client-side application is set to Patient. To change the role into the others, users need to contact the admin to switch the user role into MedicalStaff or Admin.
Main Functionalities Below are the two primary features implemented in our project Resource Allocation Accessible by: MedicalStaff Create / Register Patient into the Patient SQL Databases (Create Patient instances) Allocate Patient to a Room (Select Patient from Patient List and allocate it into a particular room) -> This creates a Patient Entry. The MedicalStaff can allocate a room by clicking on the room that are available through the interactive
Patient Prediction Simulation Based on the last 7 days, predicts the number of patients that will arrive to the hospital in the next 24 hours Medical Chatbot For the chatbot, we used agentic flow from LangGraph and OpenAI API for the LLM. We first initialized a SQL database of doctors with their relevant skills, specialties, and consultation schedule. Then we created a SQL query tool for the agent, giving the table schema, as well as the list of all possible skills and specialties. To increase query accuracy, we created a vector database containing all the valid skills and specialties.
The agent will read incoming user’s text, then determine if it is necessary to query the database for relevant information. If no database query is needed, it will answer the text normally. If a database query is needed, the agent will parse relevant keywords, then do a semantic search over the vector database to get precise matching when querying the SQL database. This means that if the user typed in “diabetes”, which is not included in the skills nor specialties of our doctors, the vector database will return “insulin management”, which is queryable.
After querying, it will format the final response based on query data.
Included in the README.md
Log in or sign up for Devpost to join the conversation.