Energía Vital

Energía Vital connects Puerto Ricans who depend on electric medical equipment with caregivers and authorized emergency responders during power outages.

Comment

Inspiration

I live in Puerto Rico, an island that is often behind on technology and accessibility, and where the power grid fails more often than it should. Here, an outage isn't an inconvenience for everyone. For someone on an oxygen concentrator or a dialysis machine, it starts a countdown.

I'm the founder of MedSeek, a new platform that connects patients in Puerto Rico with healthcare providers, where I also built Código K, a free health profile that patients own and share by QR code. Building it, I've spent a lot of time listening to people and their needs, and one belief keeps getting stronger: patients should own their data, and healthcare in PR deserves patient-centered tools built here, for here.

Energía Vital wasn't in my plans. For this hackathon I took time to research where technology could close a real gap, and I found one: there is still no working registry of people who depend on electricity to stay alive. A past bill (P. del S. 281) died because no agency wanted to maintain the list. I saw a different answer: let residents keep their own data and decide who sees it. It turned out to be the most meaningful thing I could build this weekend, and something I want to turn into a product and integrate with MedSeek.

What it does

  • Residents sign up in plain Spanish and choose, partner by partner, who can see their information: LUMA, their municipal emergency office, and their caregivers.
  • When the power goes out, a clock starts for each person, based on how many hours their equipment lasts without power. They get a simple check-in: Estoy bien / Necesito ayuda.
  • If there's no answer, it escalates on a schedule: caregivers first, then the municipal emergency team.
  • Each partner sees only the fields the resident authorized, and every view is logged.

How I built it

Node.js, Express and SQLite, with vanilla HTML/CSS/JS and a Spanish-first, accessible UI. Personal data is encrypted (AES-256-GCM), check-in links are hashed, and visibility is enforced on the server for every request. A rules engine checks every few seconds and fires each escalation step exactly once. The demo runs live at energiavitalpr.com with synthetic residents, and the demo resident's alerts arrive as a real email.

Challenges

The hardest part was the one that matters most here: reaching a phone. SMS trials aren't available in Puerto Rico, WhatsApp verification never arrived, and carriers now require business registration before an app can text. I built messaging as a swappable channel, simulated SMS honestly, and delivered the demo alerts by real email. The other challenge was making consent real, enforced in code and auditable, not just a checkbox.

What I learned

Using data responsibly isn't a feature you add at the end. It's the product. The technology for this exists. What Puerto Rico needs are solutions built around trust, consent and the people who need them most.

Built With

  • a-default-deny-visibility-projection-per-partner
  • accessible-type-(atkinson-hyperlegible)
  • aes-256-gcm
  • an-access-log-that-stores-field-*names*-only
  • and-status-always-shown-as-**icon-+-word-+-color**
  • atkinson-hyperlegible
  • better-sqlite3
  • check-in-tokens-stored-only-as-sha-256-hashes
  • claude
  • css3
  • express.js
  • helmet
  • html5
  • httponly-samesite-cookies
  • javascript
  • never-color-alone.-**live-data:**-an-unofficial-luma-regional-outage-indicator
  • node.js
  • rate-limits-and-an-origin-check.-**frontend:**-vanilla-html/css/js
  • render
  • resend
  • spanish-first
  • sqlite
  • sqlite-(better-sqlite3)
  • with-a-pure-`evaluate()`-rules-function-and-a-5-second-engine-tick-that-persists-escalation-steps-idempotently.-**privacy-&-security:**-aes-256-gcm-encryption-on-personal-fields
Share this project:

Updates

Submission history