choosing google account
sign up typeform
main patient portal
google calendar appointment scheduler
prototype doctor portal
grabs events from calendar
Overused API calls
list of events (if we were to have them)
Our story begins with 2 Estimote beacons. A friend of ours introduced the team to beacons, which are pieces of hardware that can detect phones within a certain proximity. Placing beacons in a health hack context, we realized their great potential in expediting the patient-doctor experience that defines healthcare: beacons can use their unique proximity features to detect patients in waiting rooms without the need for paper sign-in, or detect patients in examination or hospital rooms, triggering an automatic sending of patient history and data to a visiting doctor. As a result, beacons have the capability of creating an automated healthcare network, which optimizes speed and efficiency in everyday healthcare operations. Furthermore, this beacon healthcare network is low-cost and easy-to-use, having immense potential for bettering the health standards in environments that may lack the means to provide online, automated patient-doctor services, such as smaller clinics or hospitals in impoverished areas including third-world countries. As 2/3rds of the world uses smartphones, and each beacon costs around $15-20, any healthcare facility with wifi can implement this automated patient-doctor system. Creating a network of closely-connected beacons and Android apps, we named our product Lighthouse to pay homage to the first beacon. Just as a lighthouse emits a light to direct the navigation of people by air and sea, our beacon-based apps emit signals to organize and elucidate the healthcare system of the everyday population.
What it does
Lighthouse works with both the patient side and doctor side of organizing health services to automate the healthcare process: On the patient side, a patient first installs our app with the incentive of decreasing their wait time and experiencing faster appointments. In the signup process, the patient enters their patient history just once, and this health history can be updated and reviewed in subsequent appointments and following any changes in health. After the patient signs up for an appointment with a doctor, their visit becomes automated. As they enter a waiting room, rather than checking in, the beacon senses that they are nearby and upon review of patient history, Lighthouse automatically checks them in, notifying their doctor. During the appointment, a beacon specific to a patient room will send out its specific UID to the doctor's device, prompting the doctor app to bring up the information regarding the specific patient. On the doctor side, appointments populate a doctor's Google Calendar, which is accessed through Lighthouse. These appointments are without overlap and easily viewed amidst the rest of the doctor's non-patient calendar events. Each day, the doctor is able to view their appointments as they receive patient name and room number, making their schedule easy to access, understand, and use.
How we built it
Lighthouse is made of an interconnection of android apps and beacons. The Estimote API was called through Android Studio, and android apps were made to detect the beacons. Patient history was collected through Typeform, whose information was sent to a Firebase backend. All graphics were created as SVGs in Inkscape and assembled in Android Studio.
Challenges we ran into
Our first challenge was learning how to use beacons, which none of us had any experience with. Following that, our challenges came from implementation of different APIs, such as the Typeform API and Google Calendar API, as well as usage of Android Studio, which only one of our team members had some experience in.
Accomplishments that we're proud of
We're proud of learning how to use beacons, which are a piece of new hardware that we have never heard of or used before this weekend! We're also proud of debugging code that pertained to the different API calls we had to make, since each API had its own quirks and features. In addition, we thought of a punny domain name: beacons led us to signals, which led us to morse code: .--. Since our Android app does not need a link, we have linked our domain, dot-dash.org, to this very devpost! This link may be useful if we revamp our product as a web app in the future.
What we learned
We learned how to implement several APIs, such as for Estimote, Typeform, and Google Calendar in a short amount of time. Some of us learned the foundations of Android Studio. We all learned how to function on very little sleep and power through.
What's next for Lighthouse
Next up, additional features can be added to Lighthouse: Multiple languages to better cater to small clinics and healthcare systems in third-world countries. Additional appointment options to allow different healthcare services to utilize the same app: a patient may be able to use the same quick, efficient beacon check-in and patient history transfer at their doctor's appointment, dentist appointment, eye exam, and etc.