Refinement of Patient Status Tracker Logic

Issue Summary

Refinement of Patient Status Tracker Logic & Terminology

The Patient Status Tracker was inaccurately marking stages (specifically "Medicine Prescription") as "Completed" prematurely. The logic did not correctly reflect the real patient journey, causing inconsistencies between UI state and actual workflow progression.

The expected behavior is that each stage should reflect accurate queue-based progression, ensuring that stages are only marked as completed after the patient has actually moved forward in the workflow.

Problem Statement

The "Medicines Prescribed" stage was marked as completed prematurely.
Terminology used past tense ("Prescribed"), implying completion even when the process was ongoing.
Status progression logic was event-driven instead of queue-driven.
UI indicators (icons/colors) did not reflect the correct stage state.
Volunteers encountered incorrect alerts such as: "Consultation is still in progress" even when the patient was already in the prescription queue.

Who is affected:

Volunteers
Pharmacists
Doctors
Coordinators

Impact:

Misleading patient status tracking
Workflow confusion
Incorrect UI feedback
Blocked or delayed operations

Steps to reproduce:

Register a patient
Move patient to consultation stage
Prescribe medicines
Observe that "Medicine Prescription" is marked as completed prematurely
Move patient to prescription queue and observe mismatch

Proposed Solution

Replace event-based logic with queue-aware progression logic.
Rename "Medicines Prescribed" to "Medicine Prescription" across:
- Components
- Translation files (en, te, hi)
- Volunteer manual
Update usePatientStatus.ts:
- Introduce queue-based completion logic
- Add isConsultationCompleted based on patient movement to subsequent queues
Fix UI behavior:
- Blue pulsing icon for "In Progress"
- Green checkmark only after completion
Fix volunteer workflow bug:
- Allow prescription actions when patient is already in prescription queue
Update documentation (Volunteer Manual)
Fix .husky/pre-commit hook to remove redundant commitlint blocking CLI commits

Test-Driven Development

Acceptance Criteria (Given-When-Then)

Scenario 1: Consultation Completion Based on Queue Transition

Given a patient is in consultation stage
  And the patient moves to prescription or subsequent queues
 When the status tracker is evaluated
 Then consultation stage should be marked as completed

Scenario 2: Medicine Prescription Stage Behavior

Given a patient is in the prescription queue
 When medicines are being entered
 Then the stage should show "In Progress"
  And display a blue pulsing icon

Scenario 3: Prescription Completion

Given a patient has completed medicine prescription
 When the patient moves to dispensing or counseling
 Then the stage should be marked as completed
  And display a green checkmark

Scenario 4: Volunteer Queue Access

Given a patient is in prescription queue
 When a volunteer attempts to add medicines
 Then the system should allow the action
  And should not show "Consultation still in progress"

Test Cases

Test ID	Test Description	Precondition	Test Steps	Expected Result	Priority
TC-001	Consultation completion logic	Patient in consultation	1. Move patient to next queue 2. Check status tracker	Consultation marked complete	High
TC-002	Prescription stage UI state	Patient in prescription queue	1. Open tracker 2. Observe icon	Blue pulsing icon shown	High
TC-003	Final completion state	Patient progresses further	1. Move to next stage 2. Check tracker	Green checkmark shown	High
TC-004	Volunteer action validation	Patient in prescription queue	1. Add medicines 2. Observe behavior	No error shown	High
TC-005	Terminology validation	UI loaded	1. Check labels	"Medicine Prescription" displayed	Medium

Unit Test Requirements

Components/Functions to Test:

Module/Component	Function/Hook	Test Cases to Cover
usePatientStatus.ts	status calculation logic	TC-001, TC-002, TC-003
PatientStatusTracker.tsx	UI rendering	TC-002, TC-003
Translation files	label rendering	TC-005

Test Assertions Required:

Renders correctly with initial state
Handles user input correctly
Validates input and shows errors
Calls API with correct payload
Handles loading state
Handles success response
Handles error response
Updates UI state appropriately

Implementation Details

Files to Change

File Path	Action	Purpose
src/hooks/usePatientStatus.ts	Modify	Implement queue-aware logic
src/components/PatientStatusTracker.tsx	Modify	Update UI state handling
src/i18n/*	Modify	Update terminology
docs/volunteer-manual.md	Modify	Align documentation
.husky/pre-commit	Modify	Fix commit hook
src/tests/usePatientStatus.test.tsx	Modify	Update unit tests
src/tests/PatientStatusTracker.test.tsx	Modify	Update unit tests

Technical Considerations

Shift from event-driven to queue-driven state logic
Ensure synchronization between backend queue state and frontend UI
Avoid hardcoded transitions
Maintain scalability for future stages

UI/UX Requirements

Accurate stage representation
Blue pulsing icon for "In Progress"
Green checkmark for "Completed"
Clear and consistent terminology
No misleading alerts
Smooth progression across stages

Mockups/Wireframes:

Not applicable

Testing Strategy

Manual Testing

Test Environment:

Browser: Chrome/Firefox
Viewport: Desktop
User Role: Volunteer/Doctor

Manual Test Steps:

Register a patient
Move patient through all queues
Observe status tracker at each stage
Validate icons, labels, and transitions

Automated Testing

Unit Tests:

Component render tests
User interaction tests
API integration tests
Error handling tests

Integration Tests (if applicable):

Multi-component interaction tests
Route navigation tests

Test Data Requirements

const mockTestData = {
  patient: {
    status: "consultation",
    nextQueue: "prescription"
  }
}