Doctor On-Call

Landing page
Request a doctor.
Request page.
Real time chat.
Dashboard.
Review creation.
Viewing reviews for a doctor.

Inspiration

In developing countries, it is not uncommon for everyday medical services to be delivered by on-call doctors. Many in need of help lack the mobility (eg. the old and infirm) or the means of transportation in order to receive often very necessary everyday medical care. Traditionally, these networks on-call doctors were based in a word-of-mouth system- you had to have relatives, friends, and other acquaintances connect you to them. Technology is excelling rapidly in these parts of the world, but the accessibility of practical everyday medicine has failed to catch up- that is the gap Doctor On-Call aims to bridge. Our non-profit organization's aim is to use the proximity of practitioners and their patients to break down barriers in communication and make medical care easily accessible to all.

What it does

Doctor On-Call is the solution our team has created to ensure citizens in developing countries can get the quality medical attention they deserve. With features such as live chatting, location-based matching between doctor and patient, and doctor ratings/reviews, we have made the process of connecting with a doctor in real-time as easy as possible. Once doctors and patients are signed on for their respective position, it is as simple as pressing one button for a patient to request a doctor. Doctors who have received a request are able to accept if possible, and can then be matched with the patient. Help can be given via live chat or if needed, in-person because of our location-based matching. Once the necessary help is given, patients can then give a review of the doctor for future patients to acknowledge.

How we built it

The forefront thought when we came up with our project was to maximize velocity of development without sacrificing quality. What this meant was standing on the shoulders of giants and using frameworks and libraries that would propel us to a robust MVP. With previous experience from our members, we found that Next.JS would be the optimal choice for the frontend framework seeing that React.JS makes building frontend web apps simple and streamlined. Moreover, Next.JS comes with out of the box tools to make backend API endpoints and a structured site with emphasis on speed (especially considering this product would be used in low wifi quality regions). As our backend, we selected Firebase since it would provide us with the necessary BaaS infrastructure without setting up any first-party systems. Both a NoSQL Database and secure Authentication management are managed by this. We deployed on Vercel since that is the official vendor of Next.JS and CI/CD comes out of the box - making development even more rapid. Moreover, our API endpoints are deployed completely seamlessly, making the backend email service deploying incredibly simple. On the note of emails, we determined from the start that timely responses are incredibly important. As such, notifications to doctors that have been requested is of utmost importance. As such, our backend has nodemailer service endpoints that provide the necessary logic to send emails to relevent users. Our location displaying system piggy backs off of the popular Google Maps API that allows us to embed map iFrames and make the site even more interactable.

Challenges we ran into

One of the biggest challenges we ran into as a team was narrowing our scope into creating a refined proof of concept that was manageable within the time frame. When we're really passionate about our idea and about the art of creation in general, it is difficult for us to bring down our expectations to be based in more realistic agendas, because at the end of the day, we want to deliver something tangible. It's a great problem to have, but a problem nonetheless. We also learned the value of project management and the importance of consensus. Everyone has an image of what the project should be, how it should be implemented, and what principles should be religiously followed. Often these ideas are conflicting and coming to agreement is a challenge of compromising on our wants to further the wellbeing of our mission. There were difficult conversations to be had about where we should focus our time, and I think we extracted a great bit of value from them because it taught us that the path to harmony isn't itself harmonious- it has to be earned.

Accomplishments that we're proud of

Iteration is paramount to creating a well developed mvp. Consistently reviewing our priorities and re-evaluating where we want the project to go, and stripping the project of details that may bog us down or expand our scope unnecessarily is an ability we are really proud of possessing. Further, our developers hold a diverse but spread out skillset. Being able to bring these together and utilize them effectively despite our differences was a great strength. Our team had great tenacity at tackling blockers that individual members were struggling with. We held to a strict 'no man left behind' policy, where an issue that brought one of us down was bringing all of us down.

What we learned

Both the collaboration and technical aspects of this hackathon were incredibly useful in supplying us with knowledge we will carry forward with us. It's obvious that working on an independent project over the course of months versus working with a team on a short term project are completely different things. However, the nuances start to appear when you can experience both. The biggest point we learned is how to effectively account for each other whilst managing ourselves. There had to be a sense of efficient teamwork, which meant reviewing the work of others and delegating tasks. This project had multiple parts, such as ideation, authentication, platform, and various features. Working all together on one thing at a time is almost never efficient enough. As such, we needed to adapt quickly and learn to allocate tasks between each other. GitHub was a superb helper for this, since it made independent code writing on a collaborative repo easy. Our biggest takeaway was to assign tasks early on within the project, but not to stick to them too closely. Being too rigid in your tasks means that the project becomes rigid and narrow focussed. With a project as expandable as this, it was necessary to make changes along the way and "cross" coding paths at various times. Another key point was to leverage each others talents. There are different technologies used within the project, many of which are understood differently by different team members. As such, it was key for us to collaborate early on a suggest technologies we are familiar with so we can come together with a cohesive tech stack we all have a hand in. Being inclusive was absolutely necessary - since you need to work with tools that people know how to use and built great things with.

What's next for Doctor On-Call

What's next for Doctor On-Call Although we are extremely proud of the end product that has come out of these 2 days, we do believe that Doctor On-Call still has a long way to go. Firstly, UI wise, we could implement a more visually appealing design for users to interact with. We went minimalistic due to the time constraint, and therefore prioritized functionality over design. Additionally, we would like to implement a validation check for doctors when they sign up. As of now, anyone can claim to be a doctor, which in practice, could do more harm than good. As a result, we believe some sort of ID check or 3rd party validation would be a great way to minimize such fraud. Furthermore, we were also thinking of adding a self-diagnose option, which would be a more complicated algorithm to determine various treatments that patients could follow. However, this would also need to be validated by doctors to ensure accurate diagnosis. Another key point mentioned previously was that our product relies on rapid response and notification. Our system in place uses email notification to ensure doctors and patients are apprised of the situations at hand. Whilst this works in its current form, it is no secret that email is dying out. As such, adopting SMS notification with a service like Twilio will become essential to lowering time to response and ensuring medical help is as rapid as possible. Moreover, partnering with hospitals directly to gain a direct line of communication would be incredibly beneficial to communicating patient difficulties with rapidity. Overall, we are proud of the barriers we have overcome during these 2 days, and would love to take Doctor On-Call to the next level!