Skip to content

feat: added the temperature column

Vandana reddy Balannagari requested to merge feat/temp-api into develop

Merge Request: Backend Support for Temperature Vitals

Overview

This MR adds backend support for recording and retrieving a patient's Temperature during camp visits. It involves updating the database schema, Pydantic validation schemas, and the service layer responsible for vitals persistence.

What does this MR do and why?

Body temperature is a fundamental vital sign that was previously missing from the backend data structures. This change enables the clinical team to track fevers and objective health changes over time, integrated directly into the PatientVisitDetails lifecycle.

The approach taken ensures high precision (Numeric(10, 2)) and data integrity through database-level constraints.

Changes Made

  • Modified app/models/patient_visit_details.py: Added temperature column and check_temperature_range constraint (0 < value < 150).
  • Modified app/schemas/patient.py: Added temperature field to VitalBase, VitalCreate, VitalUpdate, and VitalWithCampInfo schemas.
  • Modified app/api/v1/routes/patient_routes.py: Updated the vitals update endpoint to pass temperature to the service layer.
  • Modified app/services/patient_service.py: Updated create_vital and update_vital functions to iterate over and persist the new field.

Technical Details

New Feature Integration:

  • Database Schema: Added temperature as a Numeric(10, 2) column. This choice supports precision (e.g., 98.6) and is more reliable than floats for medical data storage.
  • Service Layer: The create_vital function now explicitly handles temperature in both the "update existing" loop and the "create new record" constructor.
  • Mapping Fix: Resolved an issue where the API endpoint was not including the new field in the VitalCreate schema passed to the service.

Type of Change

  • ✨ New feature (non-breaking change that adds functionality)
  • 🐛 Bug fix (mapping error fix)
  • ♻️ Refactor

Screenshots or Screen Recordings

OpenAPI Documentation (/docs): The VitalUpdate and VitalWithCampInfo schemas now show the temperature property as an optional float with range validation.

How to Validate Locally

  1. Previous Behavior: Vitals update API only accepted BP, Pulse, Heart Rate, RBS, Height, and Weight.
  2. Changes Made: Migration added temperature column; Services updated to map the field.
  3. New Behavior:
    • Perform a PUT /api/v1/patients/vitals/{book_no} with {"temperature": 98.6}.
    • Verify the response contains the temperature.
    • Query the DB: SELECT temperature FROM patient_visit_details WHERE visit_id = ....

Testing Done

  • Unit tests updated (Check constraints tested)
  • API endpoint tests passing

Test Cases Covered:

Scenario Expected Result Status
Valid float (98.6) 200 OK / Saved to DB ✅
Negative value (-1) 422 Validation Error / DB Constraint Fail ✅
Extremely high value (200) 422 Validation Error / DB Constraint Fail ✅

Code Quality Checklist

  • Code follows project conventions
  • No unused imports
  • Type hints defined for all service functions
  • Ruff/Format checks passing

Python & FastAPI Best Practices

  • Pydantic models used for validation
  • Error handling captures DB constraint failures

Database & Migrations

  • Database migrations created (Alembic)
  • No raw SQL used

closes #107 (closed)

Merge request reports