Skip to content

fix(patient-status): update UI handling for vitals and know your patient stages

Banuri Koushik Reddy requested to merge bug/patient-status-vitals-kyp-ui into develop

Overview

This MR updates the volunteer-facing patient progress tracker so the frontend matches the backend patient status flow. It adds the missing intermediate and queue-related steps so patient progression is shown accurately in the UI.

What does this MR do and why?

The frontend status flow was out of sync with the backend flow. In particular, the backend now includes know_your_patient and queue-related states, but the volunteer status page and shared status handling did not fully reflect that sequence.

This MR updates the frontend to align with the backend contract by adding Know Your Patient between Vitals Collection and Queue, adding Queue and In Consultation Queue to the progress tracker, and ensuring Know Your Patient is marked completed when the API returns know_your_patient.

This change is needed so volunteers see the correct current stage for each patient and the UI reflects the actual backend workflow without gaps.

Changes Made

  • Updated usePatientStatus.ts to include the new patient journey steps and status label mapping
  • Updated PatientStatus.tsx to render the revised progress flow in the volunteer UI
  • Updated api.ts to include know_your_patient in PatientStatusType
  • Updated PatientStatus.test.tsx with coverage for the new status flow and completion behavior

Technical Details

The root issue was a mismatch between backend status values and the frontend stepper logic.

This MR fixes that by:

  • Extending the patient status type definitions to support know_your_patient
  • Updating the step definitions used by the shared hook and volunteer status page
  • Updating status completion logic so know_your_patient is treated as a completed stage when returned by the API
  • Adding test coverage for the new step rendering and completion behavior

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
  • 🎨 UI/UX improvement
  • ♻️ Refactor (no functional changes)
  • ⚡ Performance improvement
  • 🧪 Test update
  • 🔧 Configuration change
  • 🚨 Security fix

Related Issues / References

Screenshots or Screen Recordings

Before After
image image

How to Set Up and Validate Locally

  1. Checkout this branch.
  2. Install dependencies if needed: 
    bun install
  3. Start the app: 
    bun dev
  4. Open the volunteer patient status page.
  5. Load a patient whose status progresses through:
    • vitals
    • know_your_patient
    • queue-related stages
  6. Verify:
    • Know Your Patient appears between Vitals Collection and Queue
    • Queue and In Consultation Queue are shown in the tracker
    • Know Your Patient is marked completed when the API returns know_your_patient

Optional verification:

bun run test --run tests/volunteers/PatientStatus.test.tsx
bun run lint

Testing Done

  • Manual testing completed
  • Unit tests added/updated

Test Cases Covered:

Scenario Expected Result Status
API returns know_your_patient Know Your Patient is displayed and marked completed ✅
Volunteer status tracker renders patient journey New queue-related steps appear in the correct flow ✅
User tries to access prescription before consultation completion Navigation is blocked and an error is shown ✅

Code Quality Checklist

Code Standards

  • Code follows project conventions (naming, structure, formatting)
  • No console.log() or debugger statements left in code
  • No unused imports, variables, or functions
  • No duplicate code and use of existing components for reusability
  • i18n check passed with no hardcoded strings in codebase for i18n support
  • TypeScript types are properly defined (no any unless justified)
  • ESLint and Prettier checks pass 
    bun run lint

React Best Practices

  • Components are properly split and single-responsibility
  • Hooks follow rules (no conditional hooks, proper dependencies)
  • State management is appropriate (local vs global state)
  • No unnecessary re-renders (memoization used where needed)
  • Event handlers are properly cleaned up

Component Patterns

  • shadcn/ui components used correctly
  • Tailwind classes follow utility-first approach
  • Responsive design considered (mobile-first if applicable)
  • Accessibility attributes included (aria-*, role, etc.)
  • Icons from lucide-react used consistently

API & Data Fetching

  • TanStack Query used for server state (if applicable)
  • Loading and error states handled
  • API types defined in src/types/api.ts
  • Axios interceptors handle auth tokens correctly
  • Use of Zod for data validations

Error Handling

  • Errors are caught and handled gracefully
  • User-friendly error messages displayed
  • Errors are being toasted properly
  • Network failures handled appropriately

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

The frontend status mapping still needs to stay updated whenever backend patient statuses change. Any future additions to the backend flow will require matching updates in the frontend tracker logic and tests.

Additional Notes

bun run test --run tests/volunteers/PatientStatus.test.tsx passed locally.

bun run lint completed without errors, but there are existing unrelated warnings in other files:

  • src/components/LanguageSwitcher.tsx
  • src/components/ui/badge.tsx
  • src/contexts/NotificationContext.tsx

MR Acceptance Checklist

Evaluate this MR against the MR acceptance checklist.

Edited by Banuri Koushik Reddy

Merge request reports