Kulcare Docs
DeveloperAuthentication Documentation04 featuresPrescription migration

Manual Test Plan: Systematic Careplan to Prescription Migration

Overview

This test plan provides a systematic approach to migrate from "careplan" to "prescription" terminology while maintaining system functionality. Each phase can be tested independently, allowing for parallel frontend development and incremental validation.

Prerequisites

Environment Setup

# 1. Backup your database
pg_dump kulcare_development > backup_before_migration.sql

# 2. Ensure you're on the correct branch
git checkout enh-health-record

# 3. Start development servers
# Terminal 1 - Backend
cd backend && rails server

# Terminal 2 - Frontend  
cd frontend && pnpm dev

# 3. Have testing tools ready
# Postman/Insomnia for API testing
# Browser dev tools for frontend testing
# Database client (pgAdmin/TablePlus) for data verification

Test Data Setup

# Create test clinic and patient data
cd backend
rails console

# Create test data (run in Rails console)
clinic = Clinic.create!(name: "Test Clinic", phone_number: "+1234567890")
doctor = Doctor.create!(first_name: "Test", last_name: "Doctor", email: "test@doctor.com")
patient = Patient.create!(first_name: "Test", last_name: "Patient", phone_number: "+1234567891")
clinic_patient = ClinicPatient.create!(clinic: clinic, patient: patient)

# Note the IDs for testing
puts "Clinic ID: #{clinic.id}"
puts "Patient ID: #{patient.id}"
puts "Doctor ID: #{doctor.id}"
puts "ClinicPatient ID: #{clinic_patient.id}"

Phase 1: Core Prescription Model Testing

Goal

Test that basic prescription model operations work after renaming from Careplan to Prescription.

Backend Changes Required

  1. Rename parts/doctor/models/careplan.rb → prescription.rb
  2. Update class name class Careplan → class Prescription
  3. Keep all existing associations and methods

Manual Test Steps

1.1 Test Model Rename

# In Rails console
rails console

# Test basic model operations
prescription = Prescription.new(
  clinic_id: 1,  # Use your test clinic ID
  patient_id: 1, # Use your test patient ID
  doctor_id: 1,  # Use your test doctor ID
  prescription_date: Date.current
)

# Test save
prescription.save!
puts "✅ Prescription model save works: #{prescription.id}"

# Test find
found = Prescription.find(prescription.id)
puts "✅ Prescription model find works: #{found.id}"

# Test associations (should still work with old table name initially)
puts "✅ Associations work: #{found.clinic.name}" if found.clinic

1.2 Test API Endpoints (Before Route Changes)

# Test existing careplan API endpoints still work with renamed model

# GET request
curl -X GET "http://localhost:3000/api/careplans/#{prescription_id}" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json"

# Expected: Should return prescription data (even though route says "careplans")

1.3 Test Frontend Integration

  1. Open browser: http://localhost:3000/cms/careplan/patient/YOUR_PATIENT_ID
  2. Verify page loads without errors
  3. Check browser console for any JavaScript errors
  4. Test creating a new prescription through the UI
  5. Verify data saves and displays correctly

Success Criteria for Phase 1

  • Prescription model can be created, read, updated, deleted
  • Existing careplan API endpoints still work
  • Frontend careplan pages load without errors
  • No broken associations or foreign key errors

Rollback Plan for Phase 1

If issues occur:

# Revert model file name
git checkout HEAD -- parts/doctor/models/prescription.rb
mv parts/doctor/models/prescription.rb parts/doctor/models/careplan.rb

Phase 2: Prescription Medicine Module Testing

Goal

Test prescription medicines functionality after model rename and association updates.

Backend Changes Required

  1. Rename careplan_medicine.rb → prescription_medicine.rb
  2. Update class name and associations
  3. Update foreign key references

Manual Test Steps

2.1 Test Medicine Model

# In Rails console
prescription = Prescription.first
medicine = PrescriptionMedicine.new(
  prescription: prescription,
  medicine_name: "Test Medicine",
  dosage: "500mg",
  frequency: "BID"
)

medicine.save!
puts "✅ PrescriptionMedicine save works: #{medicine.id}"

# Test associations
puts "✅ Medicine -> Prescription: #{medicine.prescription.id}"
puts "✅ Prescription -> Medicines: #{prescription.prescription_medicines.count}"

2.2 Test Medicine API Endpoints

# Test medicine CRUD through careplan API (before route changes)
prescription_id=1  # Use your test prescription ID

# Add medicine to prescription
curl -X POST "http://localhost:3000/api/careplans/#{prescription_id}/medicines" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "medicine": {
      "medicine_name": "Aspirin",
      "dosage": "100mg",
      "frequency": "Once daily"
    }
  }'

# Get medicines for prescription
curl -X GET "http://localhost:3000/api/careplans/#{prescription_id}/medicines" \
  -H "Authorization: Bearer YOUR_TOKEN"

2.3 Test Frontend Medicine Management

  1. Navigate to prescription detail page
  2. Test adding a new medicine
  3. Test editing medicine dosage/frequency
  4. Test removing a medicine
  5. Verify all changes persist after page reload

Success Criteria for Phase 2

  • PrescriptionMedicine model operations work
  • Medicine associations with Prescription work
  • Medicine API endpoints function correctly
  • Frontend medicine management works

Phase 3: API Routes Migration Testing

Goal

Gradually update API routes from /careplans to /prescriptions and ensure frontend integration.

Backend Changes Required

  1. Update routes in parts/doctor/routes.rb
  2. Update controller file names
  3. Update controller class names

Manual Test Steps

3.1 Update Routes File

# In parts/doctor/routes.rb
# Change from:
resources :careplans
# To:
resources :prescriptions

3.2 Test New API Endpoints

# Test new prescription routes
curl -X GET "http://localhost:3000/api/prescriptions" \
  -H "Authorization: Bearer YOUR_TOKEN"

curl -X GET "http://localhost:3000/api/prescriptions/1" \
  -H "Authorization: Bearer YOUR_TOKEN"

# Test POST to new endpoint
curl -X POST "http://localhost:3000/api/prescriptions" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "prescription": {
      "clinic_id": 1,
      "patient_id": 1,
      "doctor_id": 1,
      "prescription_date": "2024-01-15"
    }
  }'

3.3 Update Frontend API Calls (Gradually)

  1. Update frontend/apps/cms/src/services/careplanApi.ts
  2. Change API endpoints one by one: 
    // Change from:
const response = await fetch('/api/careplans')
// To:
const response = await fetch('/api/prescriptions')
  3. Test each API call change immediately

3.4 Test Frontend After Each API Change

  1. Test the specific feature you just updated
  2. Verify data loads correctly
  3. Test CRUD operations for that feature
  4. Check for console errors

Success Criteria for Phase 3

  • New /api/prescriptions endpoints work
  • Frontend API calls updated successfully
  • All prescription CRUD operations work through new endpoints
  • No regression in existing functionality

Phase 4: Frontend Route Migration Testing

Goal

Update frontend routes from /cms/careplan/ to /cms/prescription/ systematically.

Frontend Changes Required

  1. Update route definitions
  2. Update component names
  3. Update navigation links
  4. Update TypeScript types

Manual Test Steps

4.1 Update Route Definitions

// In frontend route files
// Change from:
{ path: '/cms/careplan', component: CareplanList }
// To:
{ path: '/cms/prescription', component: PrescriptionList }

4.2 Test Route Navigation

  1. Navigate to new prescription routes manually:

    • http://localhost:3000/cms/prescription
    • http://localhost:3000/cms/prescription/patient/1
    • http://localhost:3000/cms/prescription/new

  2. Test navigation links and buttons

  3. Test browser back/forward functionality

  4. Test deep linking to specific prescriptions

4.3 Update Component Names

// Rename components gradually
CareplanList → PrescriptionList
CareplanDetail → PrescriptionDetail
CareplanForm → PrescriptionForm

4.4 Test Each Component Update

  1. Test component renders correctly
  2. Test component props and state
  3. Test component interactions
  4. Verify no TypeScript errors

Success Criteria for Phase 4

  • All frontend routes use prescription terminology
  • All components renamed and working
  • Navigation between pages works correctly
  • No TypeScript compilation errors

Phase 5: Database Migration Testing

Goal

Rename database tables from careplan to prescription and ensure data integrity.

Database Changes Required

-- Core table renames
ALTER TABLE careplans RENAME TO prescriptions;
ALTER TABLE careplan_medicines RENAME TO prescription_medicines;
ALTER TABLE careplan_complaints RENAME TO prescription_complaints;
ALTER TABLE careplan_advices RENAME TO prescription_advices;
ALTER TABLE careplan_diets RENAME TO prescription_diets;
ALTER TABLE careplan_procedures RENAME TO prescription_procedures;
ALTER TABLE careplan_test_lists RENAME TO prescription_test_lists;

-- Template table renames
ALTER TABLE careplan_template_medicines RENAME TO prescription_template_medicines;
ALTER TABLE careplan_template_test_lists RENAME TO prescription_template_test_lists;
ALTER TABLE careplan_template_tests RENAME TO prescription_template_tests;
ALTER TABLE careplan_tests RENAME TO prescription_tests;
ALTER TABLE doctor_careplan_templates RENAME TO doctor_prescription_templates;

-- Foreign key column renames
ALTER TABLE prescription_medicines RENAME COLUMN careplan_id TO prescription_id;
-- (Apply to all tables with careplan_id foreign keys)

Manual Test Steps

5.1 Create Migration File

cd backend
rails generate migration RenameCareplanTablesToPrescription

5.2 Test Migration on Development

# Run migration
rails db:migrate

# Verify tables renamed
rails dbconsole
\dt prescription*
\dt careplan*  # Should show no results

# Test data integrity
SELECT COUNT(*) FROM prescriptions;
SELECT COUNT(*) FROM prescription_medicines;

5.3 Test Application After Migration

  1. Restart Rails server
  2. Test all prescription CRUD operations
  3. Test associations and foreign keys
  4. Run any existing test suite

Success Criteria for Phase 5

  • All tables successfully renamed
  • All data preserved during migration
  • Foreign key relationships maintained
  • Application functions normally after migration

Phase 6: LHR Integration Testing

Goal

Test patient-centric Longitudinal Health Record functionality.

API Endpoints to Test

# Main LHR endpoint
curl -X GET "http://localhost:3000/api/patients/1/longitudinal_health_record" \
  -H "Authorization: Bearer YOUR_TOKEN"

# Individual FHIR endpoints
curl -X GET "http://localhost:3000/api/patients/1/clinical_observations" \
  -H "Authorization: Bearer YOUR_TOKEN"

curl -X GET "http://localhost:3000/api/patients/1/medication_requests" \
  -H "Authorization: Bearer YOUR_TOKEN"

Manual Test Steps

6.1 Test LHR Data Aggregation

  1. Create multiple prescriptions for the same patient
  2. Add different medicines, complaints, and tests
  3. Call LHR API and verify it aggregates data across all prescriptions
  4. Check data format matches FHIR R4 standards

6.2 Test Frontend LHR Page

  1. Navigate to /cms/prescription/patient/1 (updated route)
  2. Verify all 6 tabs load:
    • Vitals
    • Observations
    • Medications
    • Investigations
    • Advice
    • Next Visit
  3. Test adding data in each tab
  4. Verify data persists across page reloads

Success Criteria for Phase 6

  • LHR API returns patient data across all appointments
  • FHIR endpoints work for all 6 resource types
  • Frontend LHR page displays aggregated patient data
  • All 6 tabs functional for data entry

Comprehensive System Testing

Final Integration Tests

Test Critical User Workflows

  1. Doctor creates prescription:

    • Login as doctor
    • Navigate to patient
    • Create new prescription
    • Add medicines, complaints, advice
    • Finalize prescription

  2. View patient history:

    • Navigate to patient LHR page
    • Verify all historical data shows
    • Test each tab functionality
    • Verify timeline and trends

  3. Update existing prescription:

    • Find existing prescription
    • Modify medicines/dosages
    • Save changes
    • Verify updates in patient history

Performance Testing

# Test database performance after migration
# Time these queries:
SELECT COUNT(*) FROM prescriptions;
SELECT * FROM prescriptions WHERE patient_id = 1;
SELECT p.*, pm.* FROM prescriptions p JOIN prescription_medicines pm ON p.id = pm.prescription_id;

Error Handling Testing

  1. Test invalid patient IDs
  2. Test missing required fields
  3. Test unauthorized access
  4. Test network failures

Success Criteria for Complete Migration

  • All careplan terminology replaced with prescription
  • All database tables renamed successfully
  • All API endpoints use prescription routes
  • All frontend routes use prescription paths
  • LHR functionality works end-to-end
  • No regression in existing functionality
  • Performance maintained or improved
  • All tests passing

Rollback Procedures

If Critical Issues Found

# 1. Database rollback
rails db:rollback

# 2. Code rollback
git checkout develop

# 3. Restore database backup if needed
psql kulcare_development < backup_before_migration.sql

Progressive Rollback

Each phase can be rolled back independently:

  • Phase 1: Revert model file names
  • Phase 2: Revert association changes
  • Phase 3: Revert route changes
  • Phase 4: Revert frontend changes
  • Phase 5: Rollback database migration

Testing Checklist

Before Starting

  • Database backup created
  • Test environment set up
  • Test data created
  • Development servers running

After Each Phase

  • All manual tests pass
  • No console errors
  • No database errors
  • Functionality preserved
  • Performance acceptable

Before Production

  • All phases completed successfully
  • Complete system test passed
  • Performance testing completed
  • Rollback procedures verified
  • Documentation updated

Additional Notes

Development Tips

  1. Work in small commits: Commit after each successful phase
  2. Test frequently: Don't accumulate untested changes
  3. Keep notes: Document any issues or unexpected behaviors
  4. Parallel development: Frontend and backend can be updated simultaneously
  5. Use feature flags: Consider feature flags for gradual rollout

Monitoring During Migration

  • Monitor database connection pool usage
  • Watch for increased error rates
  • Check application performance metrics
  • Monitor user experience for any degradation

This systematic approach ensures each change is validated before proceeding, minimizing risk and enabling quick rollback if issues arise.

Frontend Migration Guide: Careplan → Prescription

Previous Page

Prescription Migration History

Next Page

On this page

OverviewPrerequisitesEnvironment SetupTest Data SetupPhase 1: Core Prescription Model TestingGoalBackend Changes RequiredManual Test Steps1.1 Test Model Rename1.2 Test API Endpoints (Before Route Changes)1.3 Test Frontend IntegrationSuccess Criteria for Phase 1Rollback Plan for Phase 1Phase 2: Prescription Medicine Module TestingGoalBackend Changes RequiredManual Test Steps2.1 Test Medicine Model2.2 Test Medicine API Endpoints2.3 Test Frontend Medicine ManagementSuccess Criteria for Phase 2Phase 3: API Routes Migration TestingGoalBackend Changes RequiredManual Test Steps3.1 Update Routes File3.2 Test New API Endpoints3.3 Update Frontend API Calls (Gradually)3.4 Test Frontend After Each API ChangeSuccess Criteria for Phase 3Phase 4: Frontend Route Migration TestingGoalFrontend Changes RequiredManual Test Steps4.1 Update Route Definitions4.2 Test Route Navigation4.3 Update Component Names4.4 Test Each Component UpdateSuccess Criteria for Phase 4Phase 5: Database Migration TestingGoalDatabase Changes RequiredManual Test Steps5.1 Create Migration File5.2 Test Migration on Development5.3 Test Application After MigrationSuccess Criteria for Phase 5Phase 6: LHR Integration TestingGoalAPI Endpoints to TestManual Test Steps6.1 Test LHR Data Aggregation6.2 Test Frontend LHR PageSuccess Criteria for Phase 6Comprehensive System TestingFinal Integration TestsTest Critical User WorkflowsPerformance TestingError Handling TestingSuccess Criteria for Complete MigrationRollback ProceduresIf Critical Issues FoundProgressive RollbackTesting ChecklistBefore StartingAfter Each PhaseBefore ProductionAdditional NotesDevelopment TipsMonitoring During Migration