fix(patient-status): update vitals and know your patient stage handling (!105) · Merge requests · HealthTech / Medical Camp / eHRS-backend

Banuri Koushik Reddy requested to merge bug/patient-status-vitals-kyp- into develop Mar 11, 2026

Overview

This merge request fixes a bug in the patient status response logic where an active status in a queue (like [vitals] or know_your_patient) was prematurely added to the patient's completed stages.

What does this MR do and why?

The motivation behind this change is to ensure accurate tracking of a patient's journey during a medical camp.

Previously, the backend was adding stages like [vitals] and know_your_patient (and other downstream queue stages) too early by inferring completion from the patient’s current queue position. That caused stages to appear as "completed" in the response even when the patient had only just entered them.

This change updates the logic so that active queue stages are not treated as completed stages, and it modifies the test suite to validate this intended behavior.

Changes Made

Fixed the queue progress formatting logic to exclude the current active queue status (meaning it only considers preceding statuses as completed).
Updated test expectations and mock data to accurately reflect the patient state.
- Added the consultation completion stage to the mocked visit details list to fix false-negative assertions.
- Changed the mocked queue status from 'in consultation' to 'consultation completed' to properly test the consultation skip logic.

Technical Details

The root cause of the issue was an off-by-one/inclusion error when building the chronological queue statuses list. When a patient was in a specific queue (e.g., [vitals]), the logic was slicing to include the active queue itself, which marked it as a "completed" progress status.

By changing the slice range to omit the current element, the response now correctly excludes the currently active stage from the historical/completed stages unless it is genuinely completed.

Type of Change

Related Issues / References

Closes #62 (closed)

How to Validate Locally

Setup the backend locally and start the server.
Run the tests specifically for patient routes.
Observe that all tests pass, specifically the two that previously failed indicating incorrect consultation status testing.
Use Swagger UI or Postman to fetch a patient's status mid-queue. Verify that if they are currently active in a specific queue, that queue's stage is not present in the returned status list.

Testing Done

Unit tests added/updated
API endpoint tests passing

Test Cases Covered:

Scenario	Expected Result	Status
Patient active in the vitals queue	vitals missing from completed status array	✅
Patient active in the know your patient queue	know your patient missing from completed status array	✅
Queue skip logic	Correct statuses present in final array	✅

Test Commands Run:

# Run specific test file for the patient routes
pytest tests/test_api/test_patient_routes.py -v

# Run all tests
pytest tests/ -v

Code Quality Checklist

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:
```
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)
Environment templates updated
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

None identified.

Additional Notes

None.

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

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