Use Case 1: The system SHALL allow patients to create

Use Case : Patient Creates Account

Actor : Patient

Scope: Account Management System

Brief: Patient registers a new account by providing required details.

Stakeholders: Patient, System Administrator (ensures system availability).

Preconditions: Patient does not already have an existing account.

Postconditions: A new patient account is successfully created.

Trigger: Patient selects "Create Account."

Basic Flow:

• Patient selects "Create Account."

• System prompts for personal details (name, email, password).

• Patient enters details and submits.

• System validates input.

• System creates a new patient account.

• Confirmation message is displayed.

Extensions:

• 3a. Invalid or missing details → system shows error and requests correction.

• 4a. Email already exists → system rejects and suggests login.

Use Case 2 : The system SHALL allow patients to update their personal account details.

Use Case : Patient Updates Account Details

Actors: Patient

Scope: Account Management System

Brief: Patient modifies personal details like email, phone, or address.

Stakeholders: Patient, System Administrator.

Preconditions: Patient is logged in.

Postconditions: Updated account details are saved.

Trigger: Patient chooses "Update Account Details."

Basic Flow:

1. Patient logs in.

2. Patient selects "Update Account."

3. System displays current details.

4. Patient edits details.

5. System validates input.

6. System saves updated details.

7. Confirmation is shown.

Extensions:

• 5a. Invalid details entered → system prompts correction.

• 6a. System error → update not saved, error shown.

Use Case 3: The system SHALL allow patients to change their account password.

Use Case 3: Patient Changes Password

Actors: Patient

Scope: Account Management System

Brief: Patient updates their account password securely.

Stakeholders: Patient, System Administrator.

Preconditions: Patient is logged in and remembers the old password.

Postconditions: Password is updated successfully.

Trigger: Patient selects "Change Password."

Basic Flow:

1. Patient logs in.

2. Patient selects "Change Password."

3. System prompts for old and new password.

4. Patient enters required details.

5. System validates old password and new password rules.

6. System updates password.

7. Confirmation displayed.

Extensions:

• 4a. Old password incorrect → system rejects request.

• 5a. New password weak → system requests stronger password.

Use Case 4 : The system SHALL allow patients to securely delete their account.

Use Case 4: Patient Deletes Account

Actors: Patient

Scope: Account Management System

Brief: Patient securely deletes their account.

**Stakeholders: **Patient, System Administrator.

Preconditions: Patient is logged in.

Postconditions: Account and related data are permanently removed.

Trigger: Patient selects "Delete Account."

Basic Flow:

1. Patient logs in.

2. Patient selects "Delete Account."

3. System asks for confirmation.

4. Patient confirms.

5. System deletes account data.

6. Confirmation shown and session ends.

Extensions:

• 3a. Patient cancels → deletion aborted.

• 4a. System error → account not deleted, error shown.

Use Case 5: The system SHALL allow doctors to create accounts.

Use Case 5: Doctor Creates Account

Actors: Doctor

Scope: Account Management System

Brief: Doctor registers a new account by providing required details.

Stakeholders: Doctor, System Administrator.

Preconditions: Doctor does not already have an existing account.

Postconditions: A new doctor account is successfully created.

Trigger: Doctor selects "Create Account."

Basic Flow:

1. Doctor selects "Create Account."

2. System prompts for professional and personal details.

3. Doctor enters details and submits.

4. System validates input and verifies doctor credentials (if required).

5. System creates doctor account.

6. Confirmation displayed.

Extensions:

• 3a. Invalid or missing details → system shows error.

• 4a. Verification fails → account not created.

Use Case 6: The system SHALL authenticate user credentials using encryption

Use Case 6: Authenticate User Credentials

Actors: Patient, Doctor, Admin

Scope: Healthcare Management System

Brief: Validates user login using encrypted credentials.

Stakeholders: All users, Security Admin

Preconditions: User has an account.

Postconditions: User logged in or rejected.

Trigger: User enters login credentials.

Basic Flow:

1. User enters username and password.

2. System encrypts password and compares with stored hash.

3. If matched → access granted.

Extensions:

• 3a. Invalid login → error message shown.

• 3b. Multiple failed attempts → account locked.

Use Case 7: The system SHALL send daily reminders to patients for scheduled therapy exercises.

Use Case 7: Send Daily Reminders

Actors: Patient

Scope: Healthcare Management System

Brief: System sends daily exercise reminders to patients.

Stakeholders: Patients, Doctors

Preconditions: Patient has active therapy schedule.

Postconditions: Patient receives reminder notification.

Trigger: Daily scheduler triggers reminder.

Basic Flow:

1. Scheduler checks patient’s therapy plan.

2. System prepares reminder message.

3. System sends via email/SMS/app notification.

Extensions:

• 3a. Network issue → reminder queued for retry.

Use Case 8: The system SHALL use the device camera to capture patient exercise sessions.

Use Case 8: Capture Exercise Session

Actors: Patient

Scope: Healthcare Management System

Brief: System uses device camera to capture exercise sessions.

Stakeholders: Patients, Doctors, Therapists

Preconditions: Patient has camera-enabled device.

**Postconditions: **Session video stored securely.

Trigger: Patient starts exercise session.

Basic Flow:

1. Patient launches exercise capture.

2. System requests camera access.

3. Patient performs exercises.

4. Session recorded and stored.

Extensions:

• 2a. Camera not available → error displayed.

• 4a. Storage full → recording stopped with warning.

Use Case 9: The system SHALL store exercise history for each patient.

Use Case 9: Store Exercise History

Actors: Patient, Doctor

Scope: Healthcare Management System

Brief: Saves patients’ exercise activity history.

Stakeholders: Patients, Doctors

Preconditions: Patient performed exercises.

Postconditions: Exercise history stored in database.

Trigger: End of exercise session.

Basic Flow:

1. System collects exercise data.

2. Validates data.

3. Stores into patient’s history log.

4. Confirms storage success.

Extensions:

• 2a. Data invalid → system discards.

• 3a. Database unavailable → retry queued.

Use Case 10: The system SHALL provide doctors with a dashboard to view weekly progress and adherence.

Use Case 10: Doctor Views Dashboard

Actors: Doctor

Scope: Healthcare Management System

Brief: Doctor reviews patient progress via dashboard.

Stakeholders: Doctors, Patients

Preconditions: Patients have recorded exercise history.

Postconditions: Weekly progress charts displayed.

Trigger: Doctor selects “Dashboard”.

Basic Flow:

1. Doctor opens dashboard.

2. System retrieves weekly exercise data.

3. System generates charts/tables.

4. Doctor reviews adherence and progress.

Extensions:

• 2a. Data retrieval error → error shown.

• 3a. No patient history → message displayed.

Use Case 11: The system SHALL notify doctors when a patient misses multiple therapy sessions.

Use Case: Notify Doctor of Missed Sessions

Actor: System (primary), Doctor (secondary)

Scope: RehabEdge – Remote Physical Therapy

Brief: The system automatically tracks patient exercise sessions. If a patient misses multiple therapy sessions, the system notifies the doctor so appropriate action can be taken.

Stakeholders: Patient, Doctor, System Administrator

Preconditions:

• Patient is registered and has assigned sessions.

• System is actively tracking attendance.

Postconditions:

• Notification sent to Doctor.

• Patient record updated with missed session details.

Triggers:

• Patient misses multiple scheduled therapy sessions.

Basic Flow:

1. System monitors patient session attendance.

2. Patient misses more than the allowed number of sessions.

3. System automatically generates a notification.

4. Notification is sent to the Doctor.

5. Doctor reviews patient status and may take necessary action.

Extensions (Alternate Flows):

• 2a. Grace Period: If the patient has a valid excuse (pre-approved leave), the system does not notify the doctor.

• 2b. System Error: If tracking fails due to technical error, the system alerts the administrator instead of the doctor.

Use Case 12: The system SHALL NOT store passwords in plain text.

Use Case Name: Secure Password Storage

Actors: System, System Administrator

Scope: Application Security

Brief:

The system must ensure that user passwords are stored securely using hashing and/or encryption, so that plain text passwords are never stored.

Stakeholders:

• System Administrator: Ensures security compliance.

• Users: Their passwords are protected from unauthorized access.

Preconditions:

• User account exists.

• Password is being created or updated.

Postconditions:

• Password stored securely in hashed/encrypted form.

• Plain text password is never retrievable.

Triggers:

• User creates a new account.

• User updates their password.

Basic Flow:

1. User/System Administrator submits a new password.
2. System hashes/encrypts the password using secure algorithms (e.g., bcrypt, SHA-256 with salt).
3. System stores only the hashed/encrypted password in the database.
4. User can authenticate later using the stored hashed password.

Exceptions / Alternative Flows:

• If hashing/encryption fails, an error is logged and the password is not stored.

Use Case 13: The system SHALL generate visual progress reports for both patients and doctors.

Use Case Name: Generate Visual Progress Report

Actors:

Patient, Doctor, System Administrator (optional, for managing/report access)

Scope: RehabEdge – Remote Physical Therapy

Brief Description:

The system automatically generates visual progress reports (charts, graphs, summaries) to show a patient’s therapy performance over time. Both patients and doctors can view these reports to track improvement.

Preconditions:

• Patient has an account and therapy sessions recorded.

• Doctor has access to assigned patients.

• System is operational and has stored session data.

Postconditions:

• Visual report is generated and available for viewing.

• Reports may be downloadable or printable.

Triggers:

• Patient or doctor requests a report.

• Scheduled automatic report generation (optional).

Basic Flow:

1. Actor (Patient or Doctor) selects the “Generate Progress Report” option.
2. System retrieves relevant session and performance data.
3. System generates visual report (charts, graphs, summaries).
4. System displays report to the actor.
5. Actor may download or print the report.

Alternative / Extension Flows

• 3a. Missing Data

• If session data is incomplete or missing, the system generates a partial report.

• The report includes a warning that some sessions are unavailable.

Use Case 14: The system SHOULD generate a weekly summary of patient progress

Use Case Name: Generate Weekly Patient Progress Summary

Actors:

Patient – Receives the summary (optional if summary is only for doctors)

Doctor – Views the summary for monitoring patient progress

System Administrator – Ensures system generates summaries correctly

Scope: RehabEdge – Remote Physical Therapy System

Brief Description:

The system automatically collects data from patients’ exercise sessions and generates a summary report at the end of each week. This summary includes the number of sessions completed, improvements in performance, and areas needing attention. The report is made available to both the patient and the doctor.

Stakeholders:

• Patient (wants to track progress)

• Doctor (wants to monitor patient improvement)

• System Administrator (wants system functionality to work correctly)

Preconditions:

• Patient is registered and has completed sessions during the week

• Exercise data has been recorded accurately

Postconditions:

• Weekly summary report is generated and stored in the system

• Notifications may be sent to the patient and doctor that the report is available

Triggers:

• End of the week or doctor/patient request for the weekly summary

Basic Flow:

1. System collects exercise data for the patient during the week.
2. System analyzes performance metrics and progress.
3. System generates a summary report.
4. Report is stored in the system.
5. Notification is sent to patient and/or doctor that the summary is available.

Alternative Flows:

• If data is missing for some sessions, the report indicates incomplete data.

Use Case 15: The system SHOULD allow doctors to view historical exercise data for a patient

Use Case Name: View Historical Exercise Data

Actors:

Doctor – main actor who views the data

Patient – source of the exercise data

System Administrator – ensures system functions properly

Scope: RehabEdge – Remote Physical Therapy

Brief Description:

The doctor can access a patient’s historical exercise data, including completed sessions, performance trends, and missed activities. This helps in assessing progress and adjusting treatment plans.

Stakeholders:

• Doctor (wants to monitor and analyze patient’s past performance)

• Patient (wants accurate history to be available)

• System Administrator (wants reliable functionality)

Preconditions:

• Doctor is logged into the system

• Patient profile exists with stored exercise data

Postconditions:

• Historical exercise data is retrieved and displayed to the doctor

Triggers:

• Doctor selects a patient’s profile and requests historical data

Basic Flow:

1. Doctor logs into the system.
2. Doctor searches for a specific patient.
3. System retrieves stored exercise history.
4. Doctor views the historical exercise data in a readable format (charts, tables, summaries).

Alternative Flow:

• If no historical data exists, the system displays a “No Data Available” message.

Use Case 16: The system SHOULD allow Doctors to set personalized exercise plans per patient.

Use Case 16: Assign Personalized Exercise Plan

Actors: Doctor (primary), Patient (secondary), System Administrator (support)

Scope: RehabEdge – Remote Physical Therapy

Brief Description:

Doctor creates or updates an individualized exercise plan for a patient based on their medical condition and therapy goals.

Stakeholders:

• Doctor – wants to design appropriate therapy plans

• Patient – wants to receive personalized care

• System Administrator – ensures system works properly

Preconditions:

• Doctor is logged into the system

• Patient profile exists

Postconditions:

• Exercise plan is saved in the system and visible to patient

• Notifications sent to patient

Triggers:

• Doctor selects a patient to assign a new exercise plan

Basic Flow:

• Doctor logs into system
• Doctor selects a patient profile
• Doctor creates/updates an exercise plan (type, reps, schedule)
• System validates inputs and saves plan
• Notification sent to patient

Extensions / Alternative Flows:

• 3a: Patient profile incomplete → System requests missing details

• 4a: Schedule conflict detected → Suggests alternative times

Use Case 17 : The system SHOULD notify patients about upcoming virtual appointments.

Use Case 17: Notify Patients of Virtual Appointments

Actors: System (primary), Patient (secondary), Doctor (reference actor)

Scope: RehabEdge – Remote Physical Therapy

Brief Description:

• System automatically reminds patients of upcoming scheduled virtual appointments via notifications.

Stakeholders:

• Patient – wants timely reminders

• Doctor – expects patient attendance

• System Administrator – ensures notification system works

Precondition:

• Appointment scheduled in system

• Patient has valid contact details

Postconditions:

• Notification sent to patient

• Patient can confirm or reschedule

Triggers:

• Appointment time approaches (e.g., 24 hours or 1 hour before)

Basic Flow:

• System checks upcoming appointments
• System generates reminder message
• Notification delivered to patient
• Patient acknowledges reminder

Extensions / Alternative Flows:

• 3a: Invalid contact details → Notification fails, system logs error

• 4a: Patient chooses to reschedule → Appointment updated

Use Case 18 : The system MAY allow patients to schedule virtual appointments with doctors.

Use Case 18: Patient Schedules Virtual Appointment

Actors: Patient (primary), Doctor (secondary), System Administrator

Scope: RehabEdge – Remote Physical Therapy

Brief Description:

• Patients can request and schedule virtual appointments with available doctors.

Stakeholders:

• Patient – wants to book appointments easily

• Doctor – wants to manage schedule effectively

• System Administrator – ensures calendar availability works

Preconditions:

• Patient is logged in

• Doctor availability is published

Postconditions:

• Appointment booked and saved in system

• Notifications sent to doctor and patient

Triggers:

• Patient selects 'Schedule Appointment' option

Basic Flow:

• Patient logs into system
• Patient selects 'Schedule Appointment'
• System displays available doctor slots
• Patient selects preferred slot
• System confirms booking and sends notifications

Extensions / Alternative Flows:

• 3a: No slots available → System suggests alternatives

• 5a: Doctor rejects request → Patient notified with reschedule option

Use Case 19: The system MAY allow patients to manually log completed exercises.

Use Case 19: Patient Logs Completed Exercises

Actors: Patient (primary), System Administrator (secondary)

Scope: RehabEdge – Remote Physical Therapy

Brief Description:

• Patient records their exercise completion manually in the system.

Stakeholders:

• Patient – wants to track daily exercise

• Doctor – uses logs for monitoring progress

• System Administrator – ensures data is recorded properly

Preconditions:

• Patient is logged in

• Exercise plan assigned

Postconditions:

• Exercise completion recorded in patient history

Triggers:

• Patient selects 'Log Exercise' option

Basic Flow:

• Patient logs into system
• Patient selects assigned exercise
• Patient enters completion details (sets, reps, date/time)
• System validates and saves entry
• Updated progress shown in dashboard

Extensions / Alternative Flows:

• 3a: Patient enters invalid data → System prompts correction

• 4a: System error → Exercise not saved, error displayed

Use Case 20 : The system MAY allow patients to share progress reports with caregivers or family members.

Use Case 20: Share Progress Report

Actors: Patient (primary), Caregiver/Family Member (secondary), System Administrator (support)

Scope: RehabEdge – Remote Physical Therapy

Brief Description:

• Patient can share progress reports (weekly/monthly summaries) with caregivers or family members.

Stakeholders:

• Patient – wants family support

• Caregiver/Family – wants to monitor patient progress

• Doctor – ensures reports are consistent with treatment

Preconditions:

• Patient has generated progress report

• Patient is logged in

Postconditions:

• Report shared with selected caregiver(s)

Triggers:

• Patient selects 'Share Report' option

Basic Flow:

• Patient logs into system
• Patient selects 'Share Progress Report'
• Patient enters caregiver email/contact
• System shares report securely (link/email)
• Caregiver receives report notification

Extensions / Alternative Flows:

• 3a: Invalid contact info → System shows error

• 4a: Permission revoked → Report access disabled