Kulcare Docs
GeneralBrainstorms

Patient App Migration - Complete Issue Plan

Date: 2026-03-13 Status: Deep Dive Complete

Executive Summary

The patient app (/patient folder) is a separate React frontend application that provides patient-facing features. It's distinct from the CMS app which is for clinic staff. The patient app currently uses legacy backend endpoints (/api/v1/patient/* and /patients/*) from parts/patient.

Current Patient App Features

FeatureBackend EndpointStatus
Auth/identity/*✅ Already using new API
Dashboard/api/v1/patient/dashboard❌ Needs migration
Appointments/patients/appointments❌ Needs migration
Medical Records/patients/{id}/medical_records❌ Needs migration
Health Records (LHR)/api/v1/patient/health-records❌ Needs migration
Patient Profile/patients/profile❌ Needs migration
Family Members/patients/family-members❌ Needs migration
Vitals/patients/{id}/vitals❌ Needs migration
Symptoms/patients/{id}/patient_symptoms❌ Needs migration
Problems/patients/{id}/problems❌ Needs migration
Documents/patients/{id}/documents❌ Needs migration
Search/clinics/{id}/patients/search❌ Needs migration
Elective CareProcedure bid requests❌ Needs migration
Notifications/patients/notifications❌ Needs migration
Profile Photo/patients/profile_photo❌ Needs migration
Settings(likely patient settings)❌ Needs migration

Feature-Specific Issues

Issue 1: [Patient] Auth Migration (Identity Integration)

Task Description: Ensure patient authentication uses the new Identity domain API - this appears to already be done but needs verification.

This issue verifies that the patient app's authentication flow is fully integrated with the new Identity domain (/identity/* endpoints). The auth service already uses Identity API endpoints for sign in, sign up, verification, password reset, and logout. Need to verify complete flow including 2FA support.

Backend

  • Verify: /identity/sessions - POST (login with phone/password)
  • Verify: /identity/registrations - POST (patient signup)
  • Verify: /identity/registrations/verify - POST (OTP verification)
  • Verify: /identity/registrations/resend_otp - POST (resend verification)
  • Verify: /identity/sessions/refresh - POST (token refresh)
  • Verify: /identity/passwords/reset - POST (password reset flow)
  • Verify: /identity/passwords/verify_code - POST (verify reset code)
  • Verify: /identity/passwords/change - POST (change password)
  • Verify: /identity/sessions/logout - DELETE (logout)
  • Verify: /identity/two_factor/* - Two-factor authentication
  • Verify: Identity::Device model stores device info for session management
  • Verify: RLS policies allow patient to access own device records
  • Background Job: Session expiration cleanup (Identity::SessionExpirationJob)
  • SMS: Verify OTP delivery on registration/reset flows
  • Email: Verify welcome email on registration (if applicable)
  • Unit Tests: Write specs for authentication flows in domains/identity/spec/

Frontend

  • Verify: auth.service.ts uses /identity/* endpoints
  • Verify: signIn() calls POST /identity/sessions
  • Verify: signUp() calls POST /identity/registrations
  • Verify: verifyUser() calls POST /identity/registrations/verify
  • Verify: resendVerificationCode() calls POST /identity/registrations/resend_otp
  • Verify: refreshToken() calls POST /identity/sessions/refresh
  • Verify: resetPassword() calls POST /identity/passwords/reset
  • Verify: verifyResetPasswordCode() calls POST /identity/passwords/verify_code
  • Verify: changePassword() calls POST /identity/passwords/change
  • Verify: logout() calls DELETE /identity/sessions/logout
  • Check: Remove any remaining legacy /patients/* auth endpoints usage
  • Unit Tests: Write tests for auth service methods in patient/src/

Issue 2: [Patient] Dashboard Migration

Task Description: Migrate patient dashboard from /api/v1/patient/dashboard to new clinical/identity domain APIs.

The patient dashboard shows upcoming appointments, health score, vitals, medications, and recent activity. Currently uses mock data in development. Need to migrate to new APIs that pull from clinical domain (vitals, conditions, medications) and appointments.

Backend

  • Create: GET /identity/patient_dashboard - Main dashboard endpoint
  • Create Table: clinical.patient_dashboard_cache (optional - for caching dashboard data)
  • Verify: GET /clinical/appointments - Returns patient's appointments (add patient_id filter)
  • Verify: GET /clinical/observations - Returns patient's vitals
  • Verify: GET /clinical/medication_requests - Returns patient's medications
  • Verify: GET /clinical/conditions - Returns patient's conditions
  • Verify: GET /clinical/allergy_intolerances - Returns patient's allergies
  • Verify: GET /clinical/patient_histories - Returns patient's activity log
  • Create Service: Identity::PatientDashboardService - Aggregates dashboard data
  • RLS Policy: Add patient self-access policy for all clinical tables
  • Background Job: PatientDashboardCacheJob - Refreshes cached dashboard data
  • Notification: Create notification when new appointment booked
  • Notification: Create notification when prescription added
  • Unit Tests: Write specs for dashboard aggregation in domains/identity/spec/services/

Frontend

  • Update: dashboard.service.ts - Replace /api/v1/patient/dashboard with new endpoints
  • Update: Get health score from /clinical/observations (calculate from BMI, etc.)
  • Update: Get vitals from /clinical/observations (filter by category: vital_signs)
  • Update: Get upcoming appointments from /clinical/appointments (filter by status: booked)
  • Update: Get medications from /clinical/medication_requests (filter by status: active)
  • Update: Get recent activity from /clinical/patient_histories
  • Update: Handle loading states and error handling
  • Update: Update DashboardResponse type to match new API
  • Unit Tests: Write tests for dashboard service in patient/src/

Issue 3: [Patient] Appointments Migration

Task Description: Migrate patient appointments from legacy /patients/appointments to new /clinical/appointments API.

Patients need to view their appointments, book new ones, and manage existing appointments. Current implementation uses legacy patient endpoints. Need to migrate to clinical domain appointments API with patient-specific filtering.

Backend

  • Verify: GET /clinical/appointments - List patient's appointments
    • Add query param: patient_id for patient-specific filtering
    • Support filters: status, start_date, end_date, appointment_type
  • Verify: POST /clinical/appointments - Create new appointment
  • Verify: GET /clinical/appointments/:id - Get appointment details
  • Verify: PATCH /clinical/appointments/:id - Update appointment
  • Verify: POST /clinical/appointments/:id/cancel - Cancel appointment
  • Verify: DELETE /clinical/appointments/:id - Cancel appointment (alternative)
  • Verify: GET /clinical/facilities/:id/available_slots - Get available time slots
  • Verify: GET /clinical/practitioners/:id/availability - Get practitioner availability
  • Create Table: clinical.appointment_reminders - For scheduling reminders
  • Background Job: AppointmentReminderJob - Sends SMS/email reminders
  • Background Job: AppointmentCancellationJob - Handles auto-cancellation
  • SMS: Send appointment confirmation SMS
  • SMS: Send appointment reminder SMS (24h before)
  • SMS: Send appointment cancellation SMS
  • Email: Send appointment confirmation email
  • Email: Send appointment reminder email
  • Slack: Notify clinic staff of new appointment booking
  • Unit Tests: Write specs for appointment CRUD in domains/clinical/spec/requests/

Frontend

  • Update: appointments service - Use /clinical/appointments
  • Update: List appointments view - Display all patient appointments
  • Update: Appointment booking flow - Use new booking API
  • Update: Cancel appointment flow - Use new cancel API
  • Update: Reschedule appointment flow
  • Update: Show available time slots - Fetch from /clinical/facilities/:id/available_slots
  • Update: Handle appointment status display (proposed, pending, booked, arrived, fulfilled, cancelled, noshow)
  • Update: Add pull-to-refresh for appointment list
  • Unit Tests: Write tests for appointment service in patient/src/

Issue 4: [Patient] Medical Records (LHR) Migration

Task Description: Migrate patient medical records from legacy endpoints to new clinical domain LHR APIs.

Patients need to view their longitudinal health record including conditions, medications, allergies, vitals trends, and clinical assessments. Current implementation uses /api/v1/patient/health-records endpoints. Need to migrate to clinical domain with FHIR-aligned resources.

Backend

  • Verify: GET /clinical/patients/:id/conditions - List patient's conditions
  • Verify: GET /clinical/patients/:id/medication_requests - List medications
  • Verify: GET /clinical/patients/:id/observations - List vitals/observations
  • Verify: GET /clinical/patients/:id/allergies - List allergies
  • Verify: GET /clinical/patients/:id/encounters - List clinical encounters
  • Verify: GET /clinical/patients/:id/episodes_of_care - List episodes of care
  • Verify: GET /clinical/patients/:id/care_plans - List care plans
  • Verify: GET /clinical/patients/:id/patient_histories - List patient activity
  • Create: LHR aggregation service for combined view
  • Create: GET /clinical/patients/:id/lhr - Unified LHR endpoint
  • Verify: GET /clinical/diagnostic_reports - Lab/imaging results
  • Verify: GET /clinical/service_requests - Pending/completed tests
  • RLS Policy: Ensure patient can read own clinical data
  • Unit Tests: Write specs for LHR in domains/clinical/spec/services/

Frontend

  • Update: health-record.service.ts - Use /clinical/patients/:id/* endpoints
  • Update: Conditions tab - Fetch from /clinical/patients/:id/conditions
  • Update: Medications tab - Fetch from /clinical/patients/:id/medication_requests
  • Update: Vitals tab - Fetch from /clinical/patients/:id/observations
  • Update: Allergies tab - Fetch from /clinical/patients/:id/allergies
  • Update: Encounters tab - Fetch from /clinical/patients/:id/encounters
  • Update: Lab Results tab - Fetch from /clinical/diagnostic_reports
  • Update: Care Plans tab - Fetch from /clinical/patients/:id/care_plans
  • Update: History tab - Fetch from /clinical/patients/:id/patient_histories
  • Update: LHR summary view - Fetch from /clinical/patients/:id/lhr
  • Unit Tests: Write tests for health record service in patient/src/

Issue 5: [Patient] Profile & Settings Migration

Task Description: Migrate patient profile management from /patients/profile to new Identity domain API.

Patients need to manage their profile including personal details, contact info, emergency contacts, and settings. Currently uses legacy /patients/profile endpoints. Need to migrate to Identity domain with patient-specific fields.

Backend

  • Verify: GET /identity/patient_profiles/:id - Get patient profile
  • Verify: PATCH /identity/patient_profiles/:id - Update patient profile
  • Verify: POST /identity/patient_profiles/:id/photo - Upload profile photo
  • Verify: DELETE /identity/patient_profiles/:id/photo - Remove profile photo
  • Create Table: identity.patient_profiles - Patient-specific profile data
    • Columns: id, user_id, first_name, last_name, display_name, birth_date, gender, photo_url, communication_preferences (jsonb), created_at, updated_at
  • Add Column: identity.users - Add patient-specific fields if needed (abha_id, etc.)
  • Create Model: Identity::PatientProfile with associations to User and Clinical::Patient
  • Create Controller: Identity::PatientProfilesController
  • Add Route: resources :patient_profiles in identity routes
  • Verify: File upload to S3 for profile photos
  • RLS Policy: Patient can update own profile only
  • Unit Tests: Write specs for patient profile in domains/identity/spec/

Frontend

  • Update: patient.service.ts - Use /identity/patient_profiles/*
  • Update: getProfile() - Fetch from GET /identity/patient_profiles/:id
  • Update: updateProfile() - Update via PATCH /identity/patient_profiles/:id
  • Update: uploadProfileImage() - Upload via POST /identity/patient_profiles/:id/photo
  • Update: Profile form - Handle all profile fields
  • Update: Emergency contact section
  • Update: Communication preferences (language, notifications)
  • Settings: Appearance (dark/light mode) - Use localStorage (no backend)
  • Settings: Notification preferences - Save to patient profile
  • Settings: Privacy settings
  • Unit Tests: Write tests for profile service in patient/src/

Issue 6: [Patient] Family Members Migration

Task Description: Migrate family member management from /patients/family-members to new clinical domain.

Patients can manage family members who are also patients or can be added. Currently uses legacy endpoints. Need to migrate to clinical domain with proper family relationship modeling.

Backend

  • Create Table: clinical.patient_relationships - Family relationship mapping
    • Columns: id, tenant_id, patient_id (primary patient), related_patient_id (family member), relationship_type (enum: parent, child, spouse, sibling, other), is_emergency_contact (boolean), created_at, updated_at
  • Create Migration: Add GIN index on patient_relationships.patient_id
  • Create Model: Clinical::PatientRelationship with associations
  • Create Controller: Clinical::PatientRelationshipsController
  • Add Route: resources :patient_relationships in clinical routes
  • Create API: GET /clinical/patient_relationships - List family members
  • Create API: POST /clinical/patient_relationships - Add family member
  • Create API: PATCH /clinical/patient_relationships/:id - Update relationship
  • Create API: DELETE /clinical/patient_relationships/:id - Remove family member
  • RLS Policy: Patient can manage own relationships
  • Notification: Notify patient when family member is added
  • Unit Tests: Write specs in domains/clinical/spec/

Frontend

  • Update: patient.service.ts - Add family member methods
  • Update: getFamilyMembers() - Fetch from GET /clinical/patient_relationships
  • Update: addFamilyMember() - Add via POST /clinical/patient_relationships
  • Update: updateFamilyMember() - Update via PATCH
  • Update: deleteFamilyMember() - Remove via DELETE
  • UI: Family member list view with relationship type
  • UI: Add family member modal/form
  • UI: Emergency contact badge display
  • Unit Tests: Write tests in patient/src/

Issue 7: [Patient] Vitals & Symptoms Migration

Task Description: Migrate patient vitals and symptoms from legacy endpoints to clinical domain APIs.

Patients can view and add their vitals (blood pressure, weight, etc.) and symptoms. Currently uses /patients/{id}/vitals and /patients/{id}/patient_symptoms. Need to migrate to clinical domain observations and conditions.

Backend

  • Verify: GET /clinical/observations - List patient's observations
    • Add filter: patient_id, category (vital_signs, laboratory, etc.)
    • Support date range: effective_date_from, effective_date_to
  • Verify: POST /clinical/observations - Record new observation/vitals
  • Verify: POST /clinical/observations/record_vitals - Bulk record vitals
  • Verify: GET /clinical/observations/:id - Get specific observation
  • Verify: PATCH /clinical/observations/:id - Update observation
  • Verify: DELETE /clinical/observations/:id - Delete observation
  • Verify: GET /clinical/conditions - List patient's conditions (symptoms)
    • Add filter: patient_id, clinical_status, category
  • Verify: POST /clinical/conditions - Record symptom/condition
  • Create Table: clinical.patient_vital_defaults - Default vitals for patients
  • Background Job: VitalsTrendAnalysisJob - Analyze vital trends and alert
  • Notification: Alert when vital is out of range (critical)
  • SMS: Send SMS alert for critical vitals (if enabled)
  • RLS Policy: Patient can read/write own observations
  • Unit Tests: Write specs in domains/clinical/spec/

Frontend

  • Update: vitals service - Use /clinical/observations
  • UI: Vitals display with latest values
  • UI: Vitals trends chart (line graph over time)
  • UI: Add new vital reading form
  • UI: Critical vital alerts display
  • Update: symptoms service - Use /clinical/conditions
  • UI: Symptoms list view
  • UI: Add symptom form
  • UI: Symptom trends
  • Unit Tests: Write tests in patient/src/

Issue 8: [Patient] Documents Migration

Task Description: Migrate patient document management from legacy endpoints to clinical domain.

Patients can upload and view documents including medical records, prescriptions, and reports. Currently uses /patients/{id}/documents. Need to migrate to clinical domain with proper document storage.

Backend

  • Verify: Document storage integration (AWS S3 or equivalent)
  • Verify: File type validation (PDF, images, etc.)
  • Verify: File size limits
  • Verify: Virus scanning (if implemented)
  • Create Table: clinical.documents - Patient documents
    • Columns: id, tenant_id, patient_id, encounter_id, document_type, file_url, file_name, file_size, mime_type, uploaded_by_id, created_at, updated_at
  • Create Model: Clinical::Document
  • Create Controller: Clinical::DocumentsController
  • Add Route: resources :documents in clinical routes
  • Create API: GET /clinical/documents - List documents
  • Create API: POST /clinical/documents - Upload document
  • Create API: GET /clinical/documents/:id - Get document metadata
  • Create API: GET /clinical/documents/:id/download - Download document
  • Create API: DELETE /clinical/documents/:id - Delete document
  • RLS Policy: Patient can manage own documents
  • Background Job: DocumentProcessingJob - Process uploaded documents
  • Notification: Notify when document is processed/ready
  • Unit Tests: Write specs in domains/clinical/spec/

Frontend

  • Update: document service - Use /clinical/documents
  • UI: Document list view with thumbnails
  • UI: Document upload interface (drag & drop)
  • UI: Document viewer (in-app PDF viewer)
  • UI: Document download
  • UI: Document delete with confirmation
  • UI: Upload progress indicator
  • Unit Tests: Write tests in patient/src/

Issue 9: [Patient] Search Migration

Task Description: Migrate patient search for finding clinics and doctors from legacy endpoints.

Patients can search for clinics and doctors to book appointments. Currently uses /clinics/{id}/patients/search for patient lookup and similar for doctor search. Need to migrate to new domain APIs.

Backend

  • Verify: GET /clinical/facilities - List facilities
    • Add filters: search, city, state, specialty, available
  • Verify: GET /clinical/facilities/:id - Get facility details
  • Verify: GET /clinical/facilities/:id/services - Get facility services
  • Verify: GET /identity/practitioners - List practitioners
    • Add filters: search, specialty, facility_id, available
  • Verify: GET /identity/practitioners/:id - Get practitioner details
  • Verify: GET /identity/practitioners/:id/schedule - Get availability
  • Elasticsearch: Ensure facility and practitioner search is indexed
  • Create API: GET /clinical/facilities/search - Full-text search
  • Create API: GET /identity/practitioners/search - Full-text search
  • Unit Tests: Write specs in domains/clinical/spec/ and domains/identity/spec/

Frontend

  • Update: clinicSearch.service.ts - Use /clinical/facilities
  • UI: Clinic search with filters (location, specialty)
  • UI: Clinic detail page
  • Update: providerSearch.service.ts - Use /identity/practitioners
  • UI: Doctor/practitioner search with filters
  • UI: Practitioner profile page
  • UI: Practitioner availability calendar
  • Unit Tests: Write tests in patient/src/

Issue 10: [Patient] Notifications Migration

Task Description: Migrate patient notifications from legacy endpoints to new domain API.

Patients receive notifications about appointments, prescriptions, and updates. Currently uses /patients/notifications. Need to migrate to communication/logs system.

Backend

  • Create Table: growth.patient_notifications - Patient notification log
    • Columns: id, tenant_id, patient_id, notification_type, title, body, data (jsonb), read_at, delivered_at, channel (sms, email, push), status, created_at
  • Create Model: Growth::PatientNotification
  • Create Controller: Growth::PatientNotificationsController
  • Add Route: resources :patient_notifications in growth routes
  • Create API: GET /growth/patient_notifications - List notifications
  • Create API: GET /growth/patient_notifications/:id - Get notification
  • Create API: POST /growth/patient_notifications/mark_as_read - Mark as read
  • Create API: POST /growth/patient_notifications/mark_all_as_read - Mark all read
  • Create API: GET /growth/patient_notifications/unread_count - Unread count
  • Background Job: PatientNotificationDeliveryJob - Deliver notifications
  • Push Notification: Integrate with FCM/APNs for push notifications
  • SMS: Send SMS notifications (Twilio)
  • Email: Send email notifications (SendGrid)
  • RLS Policy: Patient can read own notifications
  • Unit Tests: Write specs in domains/growth/spec/

Frontend

  • Update: notification service - Use /growth/patient_notifications
  • UI: Notification list view
  • UI: Unread badge in header
  • UI: Mark as read on tap
  • UI: Mark all as read button
  • UI: Pull-to-refresh notifications
  • Settings: Notification preferences (per type)
  • Unit Tests: Write tests in patient/src/

Issue 11: [Patient] Elective Care / Procedure Bid Requests Migration

Task Description: Migrate elective care marketplace features from legacy endpoints.

Patients can browse elective procedures, submit bid requests, and receive proposals from clinics. Uses procedure bid requests system. Need to migrate to new domain or verify existing implementation.

Backend

  • Verify: Existing procedure bid request tables in parts/patient
  • Create Table: clinical.procedure_categories - Categories for procedures
  • Create Table: clinical.procedure_bids - Patient bid requests
    • Columns: id, tenant_id, patient_id, procedure_category_id, description, preferred_date, budget_range, status, created_at, updated_at
  • Create Table: clinical.procedure_proposals - Clinic proposals
    • Columns: id, tenant_id, procedure_bid_id, facility_id, proposed_price, proposed_date, notes, status, created_at, updated_at
  • Create Model: Clinical::ProcedureBid and Clinical::ProcedureProposal
  • Create Controller: Clinical::ProcedureBidsController
  • Add Route: resources :procedure_bids in clinical routes
  • Create API: GET /clinical/procedure_categories - List categories
  • Create API: POST /clinical/procedure_bids - Submit bid request
  • Create API: GET /clinical/procedure_bids/:id - Get bid details
  • Create API: GET /clinical/procedure_bids/:id/proposals - Get proposals
  • Create API: POST /clinical/procedure_bids/:id/proposals/:proposal_id/accept - Accept proposal
  • Background Job: ProcedureBidNotificationJob - Notify clinics of new bids
  • Background Job: ProcedureProposalNotificationJob - Notify patient of new proposals
  • Email: Notify patient of new proposals
  • Slack: Notify admin of new procedure bids
  • Unit Tests: Write specs in domains/clinical/spec/

Frontend

  • Update: elective-care.service.ts - Use new API
  • UI: Procedure category browsing
  • UI: Submit bid request form
  • UI: View submitted bids
  • UI: View received proposals
  • UI: Accept proposal flow
  • UI: Bid status tracking
  • Unit Tests: Write tests in patient/src/

Issue 12: [Patient] Care Packages Migration

Task Description: Migrate patient care package subscriptions from legacy endpoints.

Patients can purchase and manage care packages/subscriptions. Uses care package orders and patient care packages. Need to migrate to billing domain.

Backend

  • Verify: Existing care package tables in parts/billing
  • Verify: GET /billing/service_packages - List available packages
  • Verify: GET /billing/service_packages/:id - Get package details
  • Verify: POST /billing/package_subscriptions - Purchase package
  • Verify: GET /billing/package_subscriptions - List patient's packages
  • Verify: GET /billing/package_subscriptions/:id - Get subscription details
  • Verify: POST /billing/package_subscriptions/:id/cancel - Cancel subscription
  • Verify: GET /billing/package_subscriptions/:id/usage - Get package usage
  • Create Table: billing.package_usage_logs - Track package usage
  • Background Job: PackageExpirationJob - Notify before expiry
  • Background Job: PackageAutoRenewalJob - Handle auto-renewal
  • Payment: Integrate Razorpay for package purchases
  • SMS: Send package purchase confirmation
  • SMS: Send package expiration reminder
  • Email: Send package purchase confirmation
  • Email: Send package invoice
  • Slack: Notify admin of package purchases
  • Unit Tests: Write specs in domains/billing/spec/

Frontend

  • Update: care package service - Use /billing/package_subscriptions
  • UI: Package listing page
  • UI: Package detail page
  • UI: Purchase flow with payment
  • UI: My packages page
  • UI: Package usage details
  • UI: Cancel subscription flow
  • Unit Tests: Write tests in patient/src/

Issue 13: [Patient] Backend - Patient Domain Completion

Task Description: Ensure backend has all required patient-facing APIs in new domain architecture.

Many patient-facing endpoints need to be created or verified in the new domain architecture. This includes Identity domain for patient profiles and Clinical domain for patient data access.

Backend

  • Verify/Create: GET /identity/patient_profiles/:id - Patient profile
  • Verify/Create: PATCH /identity/patient_profiles/:id - Update profile
  • Verify/Create: POST /identity/patient_profiles/:id/photo - Upload photo
  • Verify/Create: GET /identity/patient_dashboard - Dashboard data
  • Verify/Create: GET /clinical/patient_relationships - Family members
  • Verify/Create: GET /clinical/patient_notifications - Notifications (or growth)
  • Verify/Create: GET /clinical/patients/:id/lhr - Longitudinal health record
  • Verify: RLS policies for all patient-facing tables
  • Create: Patient user role in Identity domain
  • Verify: Patient can only access own data (ownership checks)
  • Add Column: identity.users - signed_up_as (varchar), onboarding_data (jsonb), onboarding_completed (boolean)
  • Migration: Add indexes for patient lookups
  • Unit Tests: Write comprehensive specs for all patient APIs

Issue 14: [Patient] Legacy Cleanup

Task Description: Remove legacy patient API usage after successful migration.

Once all features are migrated to new domain APIs, clean up legacy code including removing or deprecating parts/patient routes and updating API documentation.

Backend

  • Deprecate: parts/patient/routes.rb - Mark routes as deprecated
  • Remove: Legacy patient controllers (after migration verified)
  • Remove: Legacy patient models (after migration verified)
  • Remove: Legacy patient migrations (keep historical)
  • Update: API documentation - Mark legacy endpoints as deprecated
  • Create: Redirect rules from old to new endpoints (if needed)
  • Log: Deprecation warnings in old endpoint responses

Frontend

  • Remove: /patient/src/constants/api.ts - Legacy endpoint constants
  • Remove: /patient/src/services/patient.service.ts - Legacy service file
  • Remove: Legacy API client configurations
  • Update: API_BASE_URL if changed
  • Unit Tests: Run full integration test suite

Summary

IssueFrontend WorkBackend WorkPriority
1. AuthVerify existingVerify IdentityHigh
2. DashboardSignificantCreate APIsHigh
3. AppointmentsSignificantVerify APIsHigh
4. Medical RecordsSignificantVerify LHRHigh
5. Profile & SettingsMediumCreate APIsHigh
6. Family MembersMediumCreate APIsMedium
7. Vitals & SymptomsMediumVerify APIsMedium
8. DocumentsMediumVerify APIsMedium
9. SearchMediumVerify APIsMedium
10. NotificationsMediumCreate APIsMedium
11. Elective CareSignificantCreate DomainMedium
12. Care PackagesMediumVerify APIsMedium
13. Backend Completion-SignificantHigh
14. Legacy CleanupMediumMediumLow

Notes

  • The patient app is a separate React app at /patient (not part of the monorepo apps/)
  • Auth is already using Identity API (/identity/*)
  • Most patient data needs to come from Clinical domain (/clinical/*)
  • Patient profile needs Identity domain with patient-specific extensions
  • Some features like Elective Care may need new domain creation

Brainstorm: New Identity Schema -- Signup, Onboarding & Auth

Previous Page

Design Patterns & Conventions

Next Page

On this page

Executive SummaryCurrent Patient App FeaturesFeature-Specific IssuesIssue 1: [Patient] Auth Migration (Identity Integration)BackendFrontendIssue 2: [Patient] Dashboard MigrationBackendFrontendIssue 3: [Patient] Appointments MigrationBackendFrontendIssue 4: [Patient] Medical Records (LHR) MigrationBackendFrontendIssue 5: [Patient] Profile & Settings MigrationBackendFrontendIssue 6: [Patient] Family Members MigrationBackendFrontendIssue 7: [Patient] Vitals & Symptoms MigrationBackendFrontendIssue 8: [Patient] Documents MigrationBackendFrontendIssue 9: [Patient] Search MigrationBackendFrontendIssue 10: [Patient] Notifications MigrationBackendFrontendIssue 11: [Patient] Elective Care / Procedure Bid Requests MigrationBackendFrontendIssue 12: [Patient] Care Packages MigrationBackendFrontendIssue 13: [Patient] Backend - Patient Domain CompletionBackendIssue 14: [Patient] Legacy CleanupBackendFrontendSummaryNotes