Inspiration

I was primarily inspired by my visits to our local hospital. The patients' vitals and information were being written periodically by nurses in Expo marker in the hospital room windows. Upon further investigation, I realized that the only way to view a patient's vital measurements or status was to be physically present in the room. There was no intranet integration, even though there were computers in every room.

The problem with this is that it severely limits a doctor/nurses ability to monitor patients (especially across multiple floors). There is no dashboard. Additionally, if a patient's vitals drop to a critical condition, only the floor staff within ear shot (of that horrid beeping noise) are notified.

What it does

LiveWire allows users to 1) log vitals, summarize their data, and connect devices to record/stream vitals; 2) share this data (live and history) with a doctor or trusted caretaker/family member; and 3) alerts said doctors/caretakers when the patient's vitals reach critically low levels.

Broadly speaking, LiveWire targets two main audiences:

Personal users, who want to use the app to log their vitals and potentially share them with trusted family members. The app allows users to connect devices which stream their vitals information (like a bluetooth heart rate monitor), or to record them manually (such as from a blood-pressure cuff).

Doctors and hospitals. This can be broken into two main use cases: summarizing the patients' vitals that they've logged throughout the week (so that they can view a worsening/better-ing condition), or monitoring patient status in a hospital setting. The app provides a dashboard for all connected patients.

When a patient adds a live device, it is streamed (via MQTT pub/sub) to their topic, which their connected doctors/caretakers can view live. When a patient records a snapshot of their data, it is saved as a measure that their doctor can view.

When the patient's vitals reach a critical low or high point, an emergency dialog pops up and they are urged to call 911. The doctor/caretaker is then notified via MQTT that an emergency is occurring with that patient.

Final note: There is a minimal (but secure) authentication system built around Basic Auth and carved out into the database.

How we built

The tech stack:

  • Flutter/Dart frontend. This is a language and frontend kit that can be used to create a mobile, desktop, and web app all in one.
  • FastApi Python backend.
  • SQLite: first time using this. Backed by a .db file.
  • Emqx/MQTT: mqtt is a lightweight pub/sub protocol, where topics are cheap to create and subscribe to. It involves using an Emqx broker to manage the messages. Note that MQTT is built specifically for low-memory (and high required quality) environments, specifically Internet of Things. This was a purposeful choice, as most hospital settings/devices involve IoT. This choice allows the application to integrate with low-brains technology.

Challenges I ran into

The biggest challenge overall (especially since I was working alone) was burnout. Phew! I was living off RedBull for a while there.

Technical challenges: There were a few minor ones. It has been a couple years since I've used Flutter/Dart and it took me a bit to pick it back up. I also used SQLite for the first time (though there was little learning curve).

MQTT took some effort to get working. It's finicky to test (being an async, pub/sub protocol).

This was also my first time trying to use AI to code (I've always been a skeptic). There wasn't a huge learning curve per se, but I had to figure out how to use it effectively, and that proved challenging.

Accomplishments that I'm proud of

I'm happy with how far this app has gone (especially going solo). I also reached out for a number of technologies that I'm not very familiar with. All-in-all, I'm proud of what I've made.

What I learned

A lot really. How to leverage AI code generation/questioning in such a way that is helpful rather than a hinderance. I've "relearned" and become more familiar with my tech choices.

This was my first hackathon, and it was certainly a new experience learning how to balance time and energy and produce a working MVP within a strict time limit.

What's next for LiveWire

The first order of business is locking down data with HIPPA. Obviously, before an app like LiveWire can be used, it must meet those regulations/requirements.

The other big feature would be bluetooth and IoT connection for streaming devices. I used simulated devices in the app to demo the features, especially so I could effectively demo the critical health alert.

I want to build out LiveWire's usecases. It would be useful to have LiveWire automatically record measures. I did not build background notifications (only in app via mqtt), which would be especially important for emergency situations. Also, it would be good to have notifications to encourage/remind a personal user to record their vitals (something like "Good morning! Time to record blood pressure!").

Also, LiveWire could be extended to measures beyond simple vitals. Whether that's expanding existing values (like providing a heart beat graph) or adding new values (like all-in-one I.V. monitoring or something similar).

LiveWire is a simple idea, but it packs in a variety of flexible use cases and addresses an existing flaw in healthcare (at least in my local hospital).

I'm happy with what I've built.

Built With

Share this project:

Updates

Submission history