Backend Issue — Persist & Manage Onboarding Health Data (Post-Login) #91
Description
This issue focuses on implementing the backend support for FEM-CARE’s mandatory onboarding flow.
The frontend onboarding screen already collects detailed health, lifestyle, and symptom data after a user logs in for the first time. This issue ensures that data is securely validated, stored, and retrievable, forming the foundation for PCOS risk assessment, dashboards, and future ML predictions.
This issue is strictly about data persistence and access, not ML logic or diagnosis.
Why this issue exists
FEM-CARE relies on structured onboarding data to:
- Generate PCOS risk insights
- Track symptom trends over time
- Enable personalized wellness guidance
Key Expectations
-
Onboarding Data Model
-
Create a dedicated model/schema to store onboarding data, linked to a user.
Fields should cover: -
Basic profile (age, height, weight, BMI)
-
Menstrual health data
-
Physical & hormonal symptoms
-
Medical history & lifestyle indicators
-
Timestamps for audit and tracking (
Take data onboarding form data from frontend or you can also check issue: #77) -
BMI should be calculated on the backend, not trusted from the client.
API Endpoints
Implement the following protected routes:
POST /onboarding
- Accept onboarding payload
- Validate all inputs
- Store data for the authenticated user
- Mark onboarding as completed
GET /onboarding
- Fetch the onboarding data for the logged-in user
- Used to restore state or prevent repeat onboarding
- Authentication & Security
- Routes must be JWT-protected
- Onboarding data must be accessible only to the owner
- Input validation is mandatory (types, ranges, required fields)
Required Behavior
- Users can submit onboarding data only once
- Duplicate submissions are rejected or handled gracefully
- Backend calculates BMI from height & weight
- Invalid or missing fields return meaningful errors
- Onboarding status can be checked server-side
Folder to Work In
backend/src/modules/onboarding/
Suggested structure:
onboarding/
├── onboarding.model.ts
├── onboarding.routes.ts
├── onboarding.controller.ts
└── onboarding.service.ts
What NOT to do
- Do NOT implement ML prediction logic
- Do NOT perform medical diagnosis
- Do NOT expose onboarding data publicly
- Do NOT store raw or unvalidated client data
Submission Requirements
- List of implemented API routes
- Sample request/response payloads
- Validation logic clearly shown
- Clean PR with explanation of schema decisions