## Inspiration

Automation is at its peak when it comes to technology, but one area that has lacked to keep up, is areas of daily medicine. We encountered many moments within our family members where they had trouble keeping up with their prescription timelines. In a decade dominated by cell phones, we saw the need to develop something fast and easy, where it wouldn’t require something too complicated to keep track of all their prescriptions and timelines and would be accessibly at their fingertips.

## What it does

CapsuleCalendar is an Android application that lets one take a picture of their prescriptions or pill bottles and have them saved to their calendars (as reminders) based on the recommended intake amounts (on prescriptions). The user will then be notified based on the frequency outlined by the physician on the prescription. The application simply requires taking a picture, its been developed with the user in mind and does not require one to go through the calendar reminder, everything is pre-populated for the user through the optical-character recognition (OCR) processing when they take a snap of their prescription/pill bottle.

## How we built it

The application was built for Android purely in Java, including integration of all APIs and frameworks. First, authorization of individualized accounts was done using Firebase. We implemented and modified Google’s optical-character recognition (OCR) cloud-vision framework, to accurately recognize text on labels, and process and parse it in real-time. The Google Calendar API was then applied on the parsed data, and with further processing, we used intents to set reminders based on the data of the prescriptions labels (e.g. take X tablets X daily - where X was some arbitrary number which was accounted for in a (or multiple) reminders).

## Challenges we ran into

Working with the OCR Java framework was quite difficult to implement into our personalized application due to various dependency failures - it took us way too long to debug and get the framework to work *sufficiently* for our needs. Also, the default OCR graphics toolkit only captures very small snippets of text at a single time whereas we needed multiple lines to be processed at once and text at different areas within the label at once (e.g. default implementation would allow one set to be recognized and processed - we needed multiple sets). The default OCR engine wasn't quite effective for multiple lines of prescriptions, especially when identifying both prescription name and intake procedure - tweaking this was pretty tough. Also, when we tried to use the Google Calendar API, we had extensive issues using Firebase to generate Oauth 2.0 credentials (Google documentation wasn’t too great here :-/).

## Accomplishments that we're proud of

We’re proud of being able to implement a customized Google Cloud Vision based OCR engine and successfully process, parse and post text to the Google Calendar API. We were just really happy we had a functional prototype!

## What we learned

Debugging is a powerful skill we took away from this hackathon - it was pretty rough going through complex, pre-written framework code. We also learned to work with some new Google APIs, and Firebase integrations. Reading documentation is also very important… along with reading lots of StackOverflow.

## What's next for CapsuleCalendar

We would like to use a better, stronger OCR engine that is more accurate at reading labels in a curved manner, and does not get easily flawed from multiple lines of text. Also, we would like to add functionality to parse pre-taken images (if the patient doesn’t have their prescription readily available and only happens to have a picture of their prescription). We would also like to improve the UI.

## Run the application

Simply download/clone the source code from GitHub link provided and run on Android studio. It is required to use a physical Android device as it requires use of the camera - not possible on emulator.
## Inspiration

We were inspired by Duolingo which makes learning languages fun! Physics is often a difficult subject for many students, so we wanted to revisit some concepts that would incorporate the physics curriculum in a fun way using simulation 🤓

## What it does

Our web app has a dashboard of user-interactive simulations that act as physics lessons. We wanted to make online physics simulations more interesting, so we implemented a working fruit-themed projectile motion game that allows you to change the angle and speed of a tomato which splatters when it falls.

## How we built it

We built Galileo using Matter.js, a physics javascript library, HTML, CSS, frameworks such as Astro and Tailwind CSS. Figma was used for wireframing, planning, as well as prototyping. We used an Astro template to get our landing page started.

## Challenges we ran into

Implementing Matter.js and figuring out how to make physics interesting to learn. We also struggled with combining logic and the Astro templates.

## Accomplishments that we're proud of

Our newest member was a first year engineering student and a hackathon beginner 🤫 🧏‍♂️ 🧏‍♂️ We also all tried something outside of our comfort zones and learned a lot from eachother!

## What we learned

SO proud of our tomatos 🍅 ❤️
Using Javascript libraries, physics rules and logic in coding

## What's next for Galileo (Dynasim)

Potentially creating more games and trying more physics libraries. Adding a review feature.
## Inspiration

We were inspired by our grandparents where picking up medication can be a struggle for them. From travelling to long line waits. We wanted a platform or tool that eases the process not only for patients but also has a systemized flow that can also help doctors and pharmaceuticals streamline their process.

## What it does

After getting checked up by a doctor, they can send your prescription straight to the patient's preferred pharmaceutical. A trusted driver can then pick it up and deliver to the patient's address.

## How we built it

For this web application, we used React.js for the component base since it's easy to manage states for a dashboard application, and used TailwindCSS for reusable component styling. We also used static mockup JSON files for the data that is being presented in the application.

## Challenges we ran into

For the first 4 hours, we regret jumping straight to code without any rough wireframes. We've listed features, components, and screens that we can divide up and code, but with no visuals to work for, we've struggled to code for the first few hours.

## Accomplishments that we're proud of

Making the app! We're pretty proud of how much we built in 8-20 hours that is functional with our current technical skills.

## What we learned

To prioritize key tasks for the MVP completion. Keeping each other constantly updated on what we were working on or any blockers we encountered helped keep things moving in case anyone else on the team had the experience to solve a specific bug or issue.

We could've planned better how reusable we wanted components to be and how we could conceive the data to hydrate the UI, but we were able to keep a good workflow and adapt to each other's work to complete our MVP.

## What's next for RxPress - Prescriptions made easy.

Our project would benefit from having input from their end users. We have different profiles that would interact with the application and their feedback would be instrumental to continue iterating on RxPress.

We would like to have the capacity to read from the doctor's office patient database, to make sure the necessary information is available to create and send prescriptions to the pharmacies.

Refining the way the Notifications work for patients would be another thing to iterate on, so they can stay updated with their prescription fulfillment status on the go, initially by integrating email alerts, and eventually by developing a mobile version of RxPress.

The service monetization needs some development too, to make sure fees are convenient for pharmacies, couriers and patients.