Skip to content

feat: add retrieve repeated medicine functionality

ashritha kunjeti requested to merge repeated_medicine_new into develop

Feature

No existing functionality was modified intentionally. This MR adds a new feature to retrieve previously prescribed medicines for a patient.

What does this MR do and why?

Adds functionality to fetch a patient’s previous medicines.

Motivation: Helps reduce repeated prescriptions, ensures safer medication practices, and improves patient history tracking, faster entry of medicines

Approach: Introduced a new API endpoint /patients/{id}/previous-medicines that returns all past medicines for a given patient.

Changes Made

Added new route /patients/{id}/previous-medicines in patient_routes.py.

Added service method get_previous_medicines(patient_id) in patient_service.py.

Added Pydantic response model PreviousMedicinesResponse for structured API responses.

Updated database query to fetch medicines linked to patient history.

Technical Details

Database: Added optimized query to retrieve medicines based on patient_id and prescription_date descending.

Service Layer: Returns structured data with medicine name, dosage, frequency, and date prescribed.

API: Endpoint is GET, requires valid patient ID, returns 404 if patient not found.

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

Closes #57 (closed)

Screenshots or Screen Recordings

How to Validate Locally

Testing Done

image

  • Unit tests added/updated
  • API endpoint tests passing

Test Cases Covered:

Scenario Expected Result Status
/
/
/

Test Commands Run:

# Example: Run all tests
pytest

# Example: Run specific test file
pytest tests/test_api_v1/test_patient_routes.py -v

# Example: Run with coverage
pytest --cov=app

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)
  • CHANGELOG.md updated (if applicable)

Known Limitations / Technical Debt

Additional Notes


MR Acceptance Checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by ashritha kunjeti

Merge request reports

Loading