Skip to content

feat: add funnel analytics routes for camp analytics dashboard

Laxman Reddy requested to merge feature/camp-analytics-funnel into develop

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:

http://localhost:8000/docs

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.example updated (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

Screenshot_from_2026-03-21_14-43-52

Screenshot_from_2026-03-21_14-44-06

Screenshot_from_2026-03-21_14-44-14

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)

Edited by Swarna rathna madhuri Kanda

Merge request reports

Loading