Draft: Resolve "feat: New backend end points for visit_history and consultation details"

Description

There is a requirement to introduce backend API endpoints to support fetching visit history and consultation details for users in the EHRS application.

The data flow requires:

1. Fetching visit_history using a user_id
2. Extracting camp_visit_id from the visit history response
3. Using camp_visit_id to fetch detailed consultation information

Currently, the backend does not provide dedicated endpoints that fully support this flow in a structured and reusable manner.

---

Requirements

1. Visit History API (Using user_id)

• Add a backend endpoint to fetch visit history for a given user using user_id
• The response should return a list of visits, each containing:
  • camp_visit_id
  • Visit date and time
  • Camp details
  • Visit status or type

This endpoint serves as the primary source for obtaining camp_visit_id.

---

2. Consultation Details API (Using camp_visit_id)

• Add a backend endpoint to fetch consultation details using camp_visit_id
• The response should include:
  • Doctor or consultant details
  • Diagnosis information
  • Consultation notes or observations

---

Expected API Behavior

• Endpoints should accept user_id and camp_visit_id as path or query parameters
• Proper validation should be performed for:
  • Invalid IDs
  • Unauthorized access
• Responses should follow existing backend response standards
• Meaningful error messages should be returned for failure cases

---

Benefits

• Enables frontend to retrieve visit and consultation data in a clean, sequential flow
• Improves clarity and maintainability of visit-based data access
• Reduces the need for complex client-side data mapping
• Supports future enhancements such as visit analytics and reporting

---

Acceptance Criteria

• Visit history endpoint implemented using user_id
• Visit history response includes camp_visit_id
• Consultation details endpoint implemented using camp_visit_id
• Authorization and validation checks enforced
• Error handling implemented for invalid or missing parameters

---

Notes

• The frontend will first call the visit_history API using user_id
• The returned camp_visit_id will then be used to fetch consultation details
• Both endpoints should be optimized for reuse across different frontend views

##screenshots of working endpoints implemented