HealthTracker
The problem
Keeping a useful record of a chronic condition is, in practice, administrative work: writing down every symptom, its intensity, when it started, whether it’s still active or already gone, what medication was taken and when. Traditional forms don’t forgive fatigue, small print, or short-term memory. Exactly the three things a long illness, age, or a disability test first.
On the other side, the doctor gets the summarized version of months of symptoms in a fifteen-minute visit, without the detail that would let them actually see a pattern.
Why it exists
This project started with something personal. I have a condition that took years to diagnose — the kind that standard medical forms don’t capture well and that doctors see in fragments, appointment by appointment, with no continuity. Knowing that from the inside shaped every design decision: how the system separates one-off symptoms from persistent conditions, the accessibility built for someone who is exhausted, the doctor view that surfaces what the patient can’t always articulate.
HealthTracker was presented at the Barranqui-IA Hackathon 2026, where it received one of the top scores of the event. What I remember most from that day isn’t the result. It’s the people who came up afterward to share their own stories of delayed diagnosis.
How it works
HealthTracker is a web app (Next.js + Supabase) where the patient logs their health by talking, the way they’d write to a person: “headache today, a 6 out of 10” is enough. An assistant built on Claude extracts structured data from that conversation (symptom, intensity, body area, date) and can also read medical documents (prescriptions, lab results) and pull the same information from those.
Every symptom is automatically classified with SNOMED CT, the standard clinical vocabulary, so it’s interoperable with other health systems. The app exposes a FHIR endpoint with the patient’s full history. But the patient never sees those codes: what they wrote in their own words is what gets shown back to them. The clinical term stays in the doctor’s view.
The system distinguishes a one-off symptom (today’s headache, and that’s it) from a condition that persists over time (fatigue, still active even if it isn’t logged every day). That classification is always an explicit choice by the patient, never inferred. Active conditions surface prominently on the main dashboard, with the option to mark them resolved at any time.
The doctor’s portal adds automatic alerts (severe symptom patterns, worsening trends, medications without apparent improvement), AI-generated SOAP notes with full traceability of the data behind them, and a group symptom map cross-referenced with air quality data.
Much of the recent work has gone into accessibility: larger typography and controls, tap-based intensity input instead of a slider, voice dictation in the chat, and dark mode. The design assumption is that the real user might be an older adult, someone with a motor disability, or simply someone worn down by their own illness.
The team
All development has been done by Dorelys Martínez Suárez. There is no team right now — but there is growing support: people who joined after the hackathon and research centers exploring partnerships for the clinical testing phase.
Current status
In active development. Symptom logging via form and chat, automatic SNOMED CT classification, active and resolved chronic-condition tracking, the doctor’s portal with SOAP notes and alerts, FHIR export, and full-history PDF export for patients are all working today.
The next focus is structured validation with real users in clinical settings. The technical foundation is there. What comes now is finding out whether it actually changes something for the people who need it most.