Due to personal experience, we have noticed how stressful and tedious it can be to keep track of your medical records and send that information to your physician, especially when you are switching doctor's offices. The whole process is nothing but a struggle, so we wanted to come up with a technology that would allow both patient and doctor to easily communicate with one another about the patient's information and needs.
Our vision for MediLib (Medical Library), was a bit more than we could handle within the span of 3 days. We were only able to come up with our idea and work on it close to 3 hours after the hackathon began, but our ambitions were still at large.
We initially intended to have a dashboard for both patient and doctor (separately), and those dashboards would have a certain collection of features. Across both dashboards there would be a profile button containing the user information such as name, email, medical organization, etc. (as well as biometrics for the patient), a list of offices and doctors that the user is/has been affiliated with, an option to send and request documents between the user and their doctor, a chat bot to help the user navigate the site (this bot would also prompt the user with questions upon first entry into the site so as to provide a more friendly way of obtaining their personal information), an option to view the conversations held between a patient and their doctor (intended for instances in which the patient is encountering symptoms that would not be able to be seen to with an appointment in a timely manner), a highlights section of the more important parts of that conversation, and a sign out button. The patient's dashboard would specifically have a list of all of their uploaded files with an option to delete and/or upload any of them or any new ones, and each of those files would have an option to be made visible or hidden to their doctor in which case the doctor would have to ask the patient for their consent for the documents to be shared to them. The patient dashboard has been mostly completed sans the styling, and we have yet to construct the doctor dashboard. The doctor's dashboard would have a list of all of their patients across their offices. We have included images of our vision for the dashboards and our brainstorming process.
In our current implementation due to the way we had intended to retrieve the user's information, users are unable to select/change their medical organization or select any doctors they are affiliated with.
We initially wanted to make use of as many APIs as we could, and we ultimately decided that we could make use of Google's Cloud Storage, Dialogflow, Natural Language, and Authentication APIs.
For the Natural Language API, the end goal is to analyze the uploaded medical documents, and highlight repeated symptoms and organize the reports in a more approachable format between doctors. In addition, for those symptoms with constant occurrences, the user would be prompted on some undetermined time basis to inquire if symptoms persist. The CSV files contained in the 'MedDocs' folder were generated from a massive CSV of medical record sample data from Kaggle.com. It was broken in parts for demonstration purposes to exist as separate medical history reports from different offices/medical professionals. Since, of course, laws prohibit including actual medical record data for such use.
For the Cloud Storage API, we wanted to create an organized system for all of the user information in such a way that it would be easy to locate, transfer, and delete anything required. Our file structure in Cloud Storage is included in the image gallery. Currently, we have been able to begin uploading files to their respective locations in the database but due to new bugs we are unable to upload files (although we do have a suspicion that they are immediately being deleted).
For the Authentication API, we wanted an easy way for the user to log in besides creating a new account by way of our own implementation. Additionally, using this API would help to ensure more security of the users accessing our site. We were able to successfully implement this feature upon the clicking of a sign in button but it caused errors to occur in navigating between pages, so we decided to make a small custom login feature instead (image included in gallery). Using this API would have also allowed for an easy transition to beginning the chat box conversation.
The DialogFlow feature was intended for use as the voice of our AI Bot "Libi" (image included in gallery). Libi is a virtual healthcare librarian that kicks off the user’s experience with a chatbox dialog. He takes in basic profile info, and if enabled, will prompt the user for more extensive healthcare questions. The extended questions and answers were to be stored as a quick-guide reference to make the office check-in experience easier and less of a hassle.
Overall, Libi acts as the user interface bot who assists with navigation questions, and “stores, uploads, sends, requests, and organizes” all your medical data. He is even intended to store the user’s personal symptom logging and images, to make upcoming doctor’s visits flow in an efficient straight-forward manner. Google’s DialogFlow is the tool that supports this functionality.
On the non-technical side of things, we learned that it is best not to wait until the last minute and beyond to get started on brainstorming for a project. While we were able to find a project idea we were both excited to work on after some time, we sacrificed valuable programming time in the process. Also, even more time was sacrificed by the fact that we did not have previous exposure to some fairly complex APIs we intended to use. This led to various problems with understanding the implementations of the API as well as the proper software in which to use it, and unfortunately we were never able to resolve those issues, so our website capabilities were hindered. We are determined to ensure that we have previous exposure to the technologies we want to use in future timed projects such as this one. We also want to take time to understand how to set up a project, either a web app or a mobile app prior to a hackathon so we would not waste time looking up all the different steps we would need to take.