feat: add funnel analytics routes for camp analytics dashboard
Merge Request
Overview
This MR enhances the existing analytics endpoint by adding missing funnel-related data required for the patient journey funnel chart in the admin dashboard.
Previously, /api/v1/analytics returned only limited aggregated metrics such as:
Patients registered Completed vitals Completed consultations
This was insufficient for representing the full funnel flow.
What does this MR do and why?
The current analytics endpoint does not provide stage-wise patient progression data required for the funnel chart.
This MR extends the existing /api/v1/analytics endpoint to include additional funnel stages without introducing a new endpoint.
The approach:
Reuse existing analytics API Add additional computed fields for funnel stages Maintain backward compatibility
Changes Made
Updated existing endpoint: GET /api/v1/analytics Added new funnel-related fields in response: doctor_assignment vitals_collection consultation prescription medicine_verification counseling Extended service logic to compute stage-wise counts No changes to route structure
Technical Details
Root cause: Existing analytics API lacked detailed stage-wise breakdown required for funnel chart Solution: Enhanced analytics response by: Fetching all patients for a given medical camp Computing stage counts using available patient fields Example logic: Registration → total patients Doctor Assignment → patients with doctor_id != null Vitals → patients with vitals_done == true Consultation → patients with consultation_done == true Prescription → patients with prescription_given == true Medicine Verification → patients with medicine_verified == true Counseling → patients with counseling_done == true No database schema changes required
Type of Change
-
🐛 Bug fix (non-breaking change that fixes an issue) -
✨ New feature (non-breaking change that adds functionality) -
💥 Breaking change (fix or feature that would cause existing functionality to change) -
📝 Documentation update -
♻ ️ Refactor (no functional changes) -
⚡ Performance improvement -
🧪 Test update -
🔧 Configuration change -
🚨 Security fix -
🗑 ️ Deprecation (removing deprecated code)
Related Issues / References
How to Validate Locally
Run backend:
docker compose up --build -d
Open Swagger:
Call:
GET /api/v1/analytics?medical_camp_id= Verify response includes: Existing fields (patients, vitals, consultations) New funnel fields (doctor_assignment, etc.) Check frontend: Funnel chart should now display correct data
Testing Done
-
Unit tests added/updated -
API endpoint tests passing
Test Cases Covered:
| Scenario | Expected Result | Status |
|---|---|---|
| Patients registered | Registration correct | |
| Doctor assigned | doctor_assignment updated | |
| Vitals completed | vitals_collection updated |
Test Commands Run:
# Example: Run all tests
curl "http://localhost:8000/api/v1/analytics?medical_camp_id=1"
<!-- Reviewer: Use this checklist to evaluate code quality -->
### Code Standards
- [ ] Code follows project conventions (naming, structure, formatting)
- [ ] No debug statements or commented-out code left (unless necessary and intended)
- [ ] No unused imports, variables, or functions
- [ ] No duplicate code (DRY principle followed)
- [ ] Type hints are properly defined (no `Any` unless justified and no mypy type check errors)
- [ ] Ruff checks pass:
```bash
ruff check .
ruff format . --check
Python & FastAPI Best Practices
-
Functions follow single-responsibility principle -
Async/await used correctly (no blocking calls in async functions) -
Dependency injection used appropriately -
Pydantic models used for request/response validation -
SQLAlchemy queries are optimized (no N+1 queries) -
Error handling is comprehensive (try/except with proper logging)
API Design
-
RESTful conventions followed -
Proper HTTP status codes returned -
Input validation implemented -
Authentication/authorization enforced -
Role Base access control used for user restriction -
API documentation (docstrings) updated
Database & Migrations
-
Database migrations created (if schema changed) -
Database migrations version is pointing to the latest version (and version name follows project conventions) -
Migrations are reversible (migrations contain downgrade scripts) -
Indexes added for frequently queried fields -
No raw SQL queries (using SQLAlchemy ORM) -
Data integrity constraints maintained
Security
-
No sensitive data logged (passwords, tokens, PII) -
SQL injection prevention verified (ORM used) -
Input sanitization implemented -
Authentication tokens handled securely -
CORS settings appropriate -
Security scan passes: bandit -r app/
Error Handling
-
Errors are caught and handled gracefully -
User-friendly error messages returned -
Errors are logged appropriately -
HTTP error responses follow API standards
Documentation
-
README.md updated (if setup steps changed) -
.env.exampleupdated (if new env vars added) -
API documentation updated (docstrings, OpenAPI specs) -
CHANGELOG.md will be updated (if applicable) -
Code comments explain complex logic (not what, but why)
Known Limitations / Technical Debt
Additional Notes
MR Acceptance Checklist
Quality & Correctness
-
Code works as intended and solves the stated problem -
No bugs introduced (existing functionality not broken) -
Edge cases handled appropriately
###screenshot
Maintainability
-
Code is readable and well-organized -
Code is testable and well-tested -
Follows project patterns and conventions
Acceptance Review
-
Reviewed by at least 1 teammate -
Reviewed by product owner
related to #74 (closed)


