Inspiration
When a health concern appears, most people do not know what to notice, what counts as urgent, or what to ask a clinician — so care gets delayed and a first appointment is spent reconstructing a pattern from memory. CareSooner was built to close that gap before the appointment, not to replace the appointment.
What it does
CareSooner is a web app with four steps: (1) choose up to three concern topics in plain language, from 8 topics; (2) run a ten-item red-flag safety check, with emergency information shown first if any red flag applies; (3) track dated observations in the browser to spot a repeating or worsening pattern early; (4) generate a printable visit-prep note with questions for a clinician. It covers the Faster care and Early detection theme directions, and deliberately does not claim to be a diagnostic tool: it names no cause and makes no diagnosis.
How I built it
Python standard library only on the server (no database, no API keys, stateless by design), plain HTML/CSS/JavaScript on the front end. The "AI" is a transparent rule set (R1–R6) shown to the user as a visible trace for every result — no black-box model, no external API. The change tracker uses the visitor's own browser storage only. 11 automated tests cover the safety rules, including a ban on diagnosis wording in every output.
Challenges I ran into
The hardest part was safety wording: making the app genuinely useful without ever implying a diagnosis. The fix was structural, not cosmetic — a rule engine that cannot output a cause, plus automated tests that fail the build if diagnosis wording ("you have …", "you likely have") appears in any output.
What I learned
For health information, explainability is a feature, not a footnote: showing the exact rule that produced a result builds more trust than a confident-sounding answer ever could — especially when the honest answer is "a clinician needs to assess this".
Built With
- accessibility
- ai
- css
- explainable
- healthcare
- html
- javascript
- library
- privacy
- python
- standard
