Context
The project explores how to represent a triage questionnaire in a mobile experience while keeping its rules consistent on the backend. The flow covers child registration, symptom selection, answers, educational classification, and later history review, without replacing professional assessment.
My contribution
I worked across development of the application and API, connecting authentication, registration, questionnaires, and results. I focused on deriving age from birth dates, configurable question rules, and preserving the context of each assessment.
How it works
- An authenticated user registers or selects a child and chooses symptoms for the questionnaire.
- The application collects answers with explicit progression and allows earlier steps to be revisited before completion.
- The API checks access to the child and calculates age conditions using birth date, assessment date, and question metadata.
- The result stores answers, age, and protocol version in a snapshot for later review and guidance presentation.
Technical decisions
Derive age on the server
Conditions in days, months, and years use explicit metadata with inclusive or exclusive boundaries. Rules do not depend on question wording or an age re-entered by the user.
Preserve assessments over time
A child's current age and questionnaire configuration can change. Recording context and protocol version alongside the result prevents an old assessment from being silently reinterpreted with current data.
What I learned
Dates, authorization, and history are part of business logic. The project reinforced the importance of testing calendar boundaries and access between users, alongside clear messages when questionnaires or integrations are unavailable.
Limits and next steps
- An educational project without clinical validation; it does not provide a diagnosis or replace professional care.
- Some guidance has a local fallback. No medical records or real children's data are displayed.