The_Vitals_Hub

A hub that sends readings from paired FDA-cleared devices straight to the right patient's record. No typing, no wrong-patient errors, nothing lost offline. Faster vitals doctors trust.

Comment

Inspiration

Puerto Rico faces a shortage of doctors and nurses, while its population keeps getting older. Patients with conditions like high blood pressure often wait weeks between visits, and between visits the clinic has little reliable information about how they’re doing. I wanted to build something that helps both sides: a simple, bilingual hub that patients can use at home, in a clinic, or in a doctor’s office, which sends trustworthy readings straight to their care team. That way, limited staff time goes to the patients who need it most.

What it does

The Vitals Hub gets trustworthy health readings from patients’ homes to their clinic, without adding work for limited staff. • Home hub: connects over Bluetooth to a blood-pressure cuff and a wearable. It is bilingual (English/Spanish), uses large high-contrast text for older patients, and asks “Who took this?” when family members share one cuff. • Never loses a reading: each reading is saved on the hub first and kept until the clinic’s cloud confirms it was stored, even though Wi-Fi outages. • Never files a reading under the wrong patient: every reading is checked against the device, the patient, and the clinic’s rules. Anything suspicious goes to a quarantine queue for staff review instead of into the chart. • Clinic portal: clinicians sign in with MFA. They see readable vitals tables, trend charts, CSV export, and quarantined readings. • Clinic admin: staff enroll patients, turn people and devices on or off per hub, and restrict a shared cuff to specific patients. Changes reach the hub automatically. • EHR hand-off: accepted readings flow into the clinic’s record system (a demo EHR here).

How we built it

Home hub (Python, NiceGUI desktop app). The hub connects over Bluetooth Low Energy to a real Omron blood-pressure cuff and a WHOOP band. Pairing includes an identity check and a test reading, and only trusted devices may connect. Every reading is saved locally first, then sent and kept in a queue until the cloud confirms it was stored, so no reading is lost when Wi-Fi drops. The interface is bilingual (English/Spanish), uses AAA-contrast large text for older patients, and asks “Who took this?” when several people share one cuff. Cloud (AWS, deployed with SAM). The hub talks to AWS IoT Core over mutual TLS using three MQTT topics: vitals, acknowledgements, and roster. An ingest Lambda validates each reading. It checks that the device is active, that the person is enrolled, that a personal device belongs to that patient, and that a shared device is allowed for that patient. Readings that fail any check go to a quarantine queue for clinic review instead of being stored. Accepted readings go into KMS-encrypted DynamoDB tables, and a second Lambda writes them to a demo clinic EHR. The acknowledgement is sent only after the database write succeeds. Clinic portal (Streamlit). Clinicians sign in through Cognito with MFA, and role groups separate clinicians from clinic admins. They see readable vitals tables, trend charts, CSV export, and quarantine review. Admins can enroll patients and activate, deactivate, or restrict devices per hub, and those changes reach the hub as a live roster. Data and testing. Live data comes only from the builder’s own devices. All 68 patients are synthetic. Sixty automated tests cover the cloud checks and the hub’s offline queue, including reconnecting after a dropped session. Public libraries and AI coding assistants were used and are disclosed in the README.

Challenges we ran into

• Making “delivered” really mean delivered. I designed the cloud to confirm a reading only after the database write succeeds, so the hub never deletes a reading the clinic doesn’t actually have. • Long outages broke the confirmation loop. After about an hour offline, AWS dropped the hub’s session. Readings kept being re-sent but were never confirmed. Fixing this meant detecting the lost session and resubscribing, and I wrote tests that simulate it. • Shared devices and the wrong patient. One cuff can serve a whole household, and a wearable belongs to one person. Keeping those rules consistent across the hub, the cloud checks, and the admin screens took several iterations. • A setup script that silently undid clinic changes. Re-seeding test data wiped patients enrolled through the portal. I caught it in testing and fixed it before it could cost real data. • Privacy on a livestream. The demo uses real devices, but every patient is synthetic, device addresses are masked, and no credentials or account details appear on screen.

Accomplishments that we're proud of

• Verified end to end on real hardware: a real cuff reading travels hub → encrypted cloud → clinician portal → EHR, with confirmation back to the hub. • Safety checks that fail closed: deactivated devices, wrong-owner wearables, and unknown devices are all refused or quarantined, never silently stored. • 60 automated tests covering the validation rules and the offline queue, including timeouts, duplicate confirmations, and lost sessions. • Built for the people who will use it: a bilingual, high-contrast interface for older patients and a clinician view that reads like a chart, not a database. • Security from day one: mutual TLS per hub, KMS-encrypted storage, and MFA with separate roles for clinicians and clinic admins.

What we learned

• In healthcare data, “not stored” beats “stored wrong.” Quarantine-by-default made the system both safer and simpler to reason about. • Diagnose with evidence before fixing. Watching the actual message traffic located each bug quickly: hub side or cloud side. • Offline is the normal case, not an edge case. Designing for outages first made everything else more reliable. • Accessibility and language aren’t polish. For older patients in Puerto Rico, they decide whether the tool gets used at all.

What's next for The_Vitals_Hub

• Low-cost hardware hub: an ESP32-S3 device that uses the same secure protocol, so a family only needs to plug it in. (In the works) • Real EHR integration: connect to clinic record systems such as CharmHealth, so each patient’s readings land directly in their own doctor’s chart, with no copying or re-entry for staff. • AI pre-screening: flag readings and trends that need a clinician’s attention first, so limited staff can prioritize. • Pilot with a Puerto Rico clinic to measure staff time saved and patient follow-through. • Regulatory path: work toward the requirements for clinical use. My background in safety-critical aerospace software (DO-178) maps well to that kind of rigor.

Built With

Share this project:

Updates

Submission history