Parivar — Rebuild Documentation Set

Technical documentation for re-building the Parivar cross-border healthcare platform off Lovable/Supabase onto a modern stack. Start here, then read the document that matches your task.

Target stack

Layer	Choice
Web frontend	Next.js
Backend API	NestJS
Mobile (nurse field app)	Flutter / React Native
Primary database	Postgres
Cache / queues / realtime scale-out / rate-limit	Redis
Object storage	S3-compatible (report PDFs, wound photos, staff docs)
Third parties (unchanged)	Stripe · Google OAuth · Didit KYC · Resend · Google Maps · ConnectIPS

Anything not named follows current industry best practice (observability via OpenTelemetry, secrets manager, CI/CD with DB migrations, etc.).

The documents

#	File	Read it for	Authoritative for
1	architecture	The hub. Stack mapping (Supabase → NestJS), the 17-module map, cross-cutting infra (auth, RBAC, errors, pagination, realtime, storage, caching), integrations, jobs, and the web + mobile client map.	Auth & authorization model, integration list, overall design
2	modules	The full module-by-module endpoint reference: all 17 NestJS modules, every endpoint with its original Supabase call, suggested NestJS route, guards, request/response fields, side effects, and errors.	Module / API surface
3	data-model	The real Postgres schema: 41 tables grouped by domain, every enum, FK, unique constraint, and indexing/perf advice.	Schema, enums, constraints (reconstructed from live-DB exports + ERD)
4	clinical-reporting	The nurse reporting workflow: four form types, full field specs, validation ranges, drafts, 24h edit window, assessment_versions, approval loop.	Reporting/assessment behaviour
5	account-lifecycle	Deactivation, reactivation (3/7-day + 15-day rules), session revocation, and FK-ordered purge — re-architected for NestJS.	Account lifecycle behaviour

Source-of-truth rule

The companion docs and the live-database exports (database_enums.csv, database_constraints.csv, Parivar_ERD.mmd) were produced after the original "Role-Based Backend API Reference" and are more current. Where they disagree with the original reference, they win. The architecture hub has been reconciled to match; remaining ⚠️ markers flag spots to confirm during build.

Key corrections already applied

• visit_type = routine / follow_up (not regular/first_assessment/on_demand). "First visit" is detected by absence of a first_visit_assessments row.
• escalation_type = the 7 clinical values (doctor_review, urgent_health, medication_issue, fall_risk, hospital_support, family_followup, admin_support).
• escalation_status = open → under_review → actioned → closed.
• Assessment approval uses approval_status + admin_viewed; vitals are bp_systolic_1/bp_diastolic_1 etc. — see doc 3.
• nurse_bank_details (not user_bank_details); no incidents table — use escalations.

Suggested reading order

1. Architects / leads: doc 1 (Parts 1–2) → doc 2 → skim docs 3–4.
2. Backend engineers: doc 2 → doc 1 (Part 3 module reference) → docs 3–4 for the complex flows.
3. Mobile engineers: doc 1 §4.3 (nurse app) → doc 3 (reporting) → doc 4 (deactivation UX).
4. Web engineers: doc 1 §4.3 (web feature map) → relevant module sections.

Build order (recommended)

1. Stand up Postgres schema from doc 2 (entities, enums, FKs, indexes) + migrations.
2. AuthModule (JWT, OTP, OAuth, RBAC guards) + Redis (throttle, denylist) — doc 1 §2 + doc 4.
3. Core domain: Parents → Visits → Clinical reporting (doc 3) → Escalations.
4. Nurse ops (onboarding/KYC, availability, location/SOS, earnings) + mobile app.
5. Billing (Stripe) + Referrals + Notifications/Alerts + Config.
6. Realtime gateway, background jobs/crons, observability, hardening.