Health Signal
A prototype that turns post-surgery home reports (pain, temperature, medication, symptoms) into a timeline and flags deviation from expected recovery.
Prototype2026BuilderFuture Hack · Dubai Knowledge Park / DIAC, with Smart Salem and Mediclinic
TL;DR
- After surgery the monitoring continues but the interpretation stops, so patients dismiss real change or worry about normal variation.
- Health Signal keeps a calm recovery timeline between patient and clinician, and leads with a plain-language summary rather than a dashboard.
- Short daily check-ins on pain, temperature, medication, and symptoms become one continuous history compared against the shape recovery should take.
- The design problem was where to place the boundary between normal variation and meaningful change: an alert can be technically correct and still harmful.
- Mobile-first Next.js for input and summaries, Python for the time-series processing and deviation logic. No production infrastructure by choice.
- A research prototype from Future Hack in Dubai Knowledge Park / DIAC. Not deployed, and not a clinical system.
Where it started
Leaving hospital does not end the monitoring. It ends the interpretation.
After surgery, patients go home with a list of symptoms to watch and broad advice about when to worry. They continue producing useful information: pain, temperature, medication timing, changes in how they feel. But no longer have someone turning those observations into a picture of how recovery is going.
A single reading rarely answers that question. A small change can be expected early in recovery and concerning several days later. Without the surrounding timeline, patients either dismiss something that is changing or become anxious about normal variation.
Health Signal was an attempt to show the meaning of the data, not simply collect more of it.
The product
A calm recovery timeline between the patient and the clinician.
The patient answers a short check-in from their phone. Health Signal builds those reports into a continuous view of recovery, compares the direction of change with what is expected, and brings forward the deviations that may deserve attention.
The first thing on screen is a summary in ordinary language. The detailed readings and timeline are there when someone needs them, but they do not lead the experience. That matters because the person reading it may be tired, in pain, or already worried.
How it works
The value comes from the timeline, not any single reading.
01
A small daily check-in
The patient records pain, temperature, medication, and symptoms from their phone. The interaction stays short enough to repeat during recovery.
02
One recovery timeline
Instead of treating each answer as an isolated reading, the system keeps them as a continuous history of how the patient is changing.
03
Comparison with expected recovery
The timeline is compared with the shape recovery should take after the procedure. That gives the same reading different meaning on day one and day six.
04
A signal people can understand
Meaningful deviation is surfaced in a short summary. The underlying readings stay available, but the patient is not asked to interpret a dashboard.
What was difficult
An alert can be harmful even when it is technically correct.
Flag every unusual value and people learn to ignore the product. Filter too aggressively and an early change disappears into the noise. The central design problem was therefore not how to draw a chart; it was where to place the boundary between normal variation and a meaningful change for each stage of recovery.
The interface had the same trade-off. More detail can make a clinical system look capable while making it harder for the patient to understand. We kept the summary first and the evidence behind it, so the system could explain a signal without turning recovery into another dashboard to manage.
How it was built
A deliberately small prototype.
The patient-facing surface was built with Next.js, React, and TypeScript, with mobile use treated as the default. Python handled the time-series processing and the comparison against expected recovery. There was no production infrastructure because the purpose of the project was to test the signal and its presentation, not to deploy a clinical service.
Stack
Interface
Analysis
Time-series processing and deviation-from-expected detection.
Where it stands
A research prototype, not a medical product.
Health Signal was developed at Future Hack in Dubai Knowledge Park / DIAC, with Smart Salem and Mediclinic involved in the event. It was not deployed and it does not replace medical judgment. The useful conclusion was narrower: post-surgery monitoring is as much a communication problem as a data problem. What matters is deciding what to show, when to show it, and how to explain why it matters.
