Skip to content

fix: temperature and added help area

Vandana reddy Balannagari requested to merge fix/temp-helparea into develop

Merge Request

Overview

This MR fixes the vitals temperature flow and adds help as a supported designated area. It ensures temperature submitted through the vitals API is persisted, returned in vitals responses/history, and covered by focused tests. It also updates area-related behavior and tests so help desk assignment is available in the area workflow.

What does this MR do and why?

The vitals schema/model already supports temperature, but the route and service flow did not consistently pass it through when creating, updating, logging, or returning vitals. This caused temperature values submitted by clients to be dropped from downstream persistence and response handling.

This MR threads temperature through the patient vitals route, service create/update logic, vitals history mapping, and log payloads. It also adds help to DesignatedArea so volunteers/users can be assigned to the help area and so area lists include that station.

Trade-off: this change is intentionally small and follows the existing vitals field pattern instead of introducing a broader vitals abstraction.

Changes Made

  • Updated app/api/v1/routes/patient_routes.py to pass temperature into create_vital and include it in vitals logging payloads.
  • Updated app/services/patient_service.py to persist and return temperature for create, update, and vitals-history flows.
  • Added help to app/enums/designated_area.py.
  • Updated area route docstring in app/api/v1/routes/areas_routes.py to match admin/coordinator behavior.
  • Updated tests for patient vitals, designated areas, and stations routes.

Technical Details

Root cause: the temperature field was present in the schema/model layer but missing from parts of the route/service mapping. Since these mappings enumerate individual vitals fields, adding the database/schema field alone was not enough.

Fix:

  • Include temperature in the list of fields applied to existing and newly created PatientVisitDetails vitals records.
  • Pass temperature from the API route into VitalCreate.
  • Convert stored temperature values to float when building Vital and VitalWithCampInfo responses, matching how other numeric vitals are handled.
  • Add test assertions to verify temperature is accepted, persisted into constructor/update calls, and returned.
  • Add DesignatedArea.help and update enum/area tests accordingly.

Database schema: no new migration is introduced in this top branch diff. The temperature column migration already exists in the branch history/develop lineage as alembic/versions/c331978e5e64_add_temperature_column_to_vitals.py.

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

Screenshots or Screen Recordings

Not applicable. This MR changes API/service behavior and enum support; no UI screenshots were captured.

How to Validate Locally

  1. Start from the target branch and check out this branch:

    git checkout fix/temp-helparea
  2. Apply database migrations if validating against a local database:

    alembic upgrade head
  3. Run the focused tests:

    uv run pytest tests/test_api/test_patient_routes.py tests/test_api/test_stations_routes.py tests/test_enums/test_designated_area.py tests/test_services/test_patient_service.py -q
  4. Validate the vitals update endpoint by sending a vitals payload with temperature, for example:

    curl -X PUT "http://localhost:8000/api/v1/patients/vitals/<book_no>" \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer <token>" \
      -d '{"bp_manual":"120/80","pulse":72,"heart_rate":72,"temperature":98.6}'
  5. Confirm the response includes temperature: 98.6 and the vitals history endpoint returns the same value.

Previous behavior: submitted temperature values could be omitted from the service create/update flow and response mapping.

New behavior: temperature is preserved across vitals create/update, logging payloads, and vitals history responses.

Testing Done

  • Unit tests added/updated
  • API endpoint tests updated

Test Cases Covered:

Scenario Expected Result Status
Update vitals API receives temperature temperature is passed into service payload
Create vitals for existing visit Returned vital includes submitted temperature
Create vitals for new visit details Constructor receives temperature and response includes it
Vitals history includes temperature History response maps stored temperature to float
Vitals history with missing temperature History response returns temperature=None
Update existing vitals Returned vital includes updated temperature
Designated area enum includes help Area enum exposes help
Area list includes help station Area endpoint logic includes DesignatedArea.help

Test Commands Run:

pytest tests/test_api/test_patient_routes.py tests/test_api/test_stations_routes.py tests/test_enums/test_designated_area.py tests/test_services/test_patient_service.py -q

Result: not run because pytest is not installed as a direct command in this environment.

uv run pytest tests/test_api/test_patient_routes.py tests/test_api/test_stations_routes.py tests/test_enums/test_designated_area.py tests/test_services/test_patient_service.py -q

Result: not run. The sandbox could not write to the uv cache directory, and elevated execution was not approved.

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)
  • .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

  • Focused tests were updated, but they were not executed in this environment due to missing direct pytest and denied elevated uv run execution.
  • Full lint, format, coverage, and security scans were not run in this environment.

Additional Notes

  • Target branch assumed: develop.
  • Branch: fix/temp-helparea.
  • The working tree was clean before this MR markdown file was added.

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
Edited by Vandana reddy Balannagari

Merge request reports

Loading