User Stories

User Stories

US-AUTH-01 — Patient Registration

User Story

As a visitor, I want to register as a patient by providing my personal, identification, contact, health, and account information so that I can securely access SaludVital's patient services.

Acceptance Criteria

1. First Names

1. The first_names field must be required.
2. The field must accept text with a maximum length of 50 characters.
3. The system must reject empty values and values containing only whitespace.
4. The system must reject values exceeding 50 characters.

2. Last Names

5. The last_names field must be required.
6. The field must accept text with a maximum length of 50 characters.
7. The system must reject empty values and values containing only whitespace.
8. The system must reject values exceeding 50 characters.

3. Phone Number

9. The phone_number field must be required.
10. The field must accept a phone number with a maximum length of 15 characters.
11. The system must validate the phone number against the supported phone-number format.
12. The same phone number must be allowed in multiple patient accounts.
13. The system must reject values exceeding 15 characters or values that do not comply with the supported format.

4. Date of Birth

14. The date_of_birth field must be required.
15. The field must use a date input control.
16. The system must accept only valid calendar dates.
17. The system must reject dates later than the current date.

5. Document Type

18. The document_type field must be required.
19. The field must use a single-selection dropdown.
20. The dropdown must offer only the following options:
    • CC — Cédula de Ciudadanía.
    • CE — Cédula de Extranjería.
21. The system must reject document types outside the supported options.

6. Document Number

22. The document_number field must be required.
23. The field must accept a maximum of 15 characters.
24. The corresponding database field must use VARCHAR(15).
25. The system must reject empty values, values containing only whitespace, and values exceeding 15 characters.
26. The document number must comply with the validation rules for the selected document type.
27. The combination of document type and document number must not already belong to another patient account.

7. Department

28. The department field must be required.
29. The field must use a single-selection dropdown populated with supported departments.
30. The system must reject values that do not correspond to valid department options.

8. Municipality

31. The municipality field must be required.
32. The field must use a single-selection dropdown populated with municipalities belonging to the selected department.
33. The municipality dropdown must remain disabled or unavailable until a department is selected.
34. When the user selects a department, the system must display only the municipalities associated with that department.
35. When the department changes, the system must clear any previously selected municipality that is no longer valid.
36. The system must validate the department-municipality relationship on the server before creating the account.

9. Residential Address

37. The address field must be optional.
38. The field must accept text with a maximum length of 150 characters.
39. The corresponding database field must support a maximum length of 150 characters, using VARCHAR(150) where appropriate.
40. The system must reject values exceeding 150 characters.
41. Leaving the field empty must not prevent registration.

10. Blood Type

42. The blood_type field must be optional.
43. The field must use a single-selection dropdown.
44. The dropdown must offer the eight standard blood types: A+, A-, B+, B-, AB+, AB-, O+, and O-.
45. The system must reject unsupported blood-type values.
46. Leaving the field empty must not prevent registration.

11. Allergies

47. The allergies field must be optional.
48. The field must allow the patient to enter free-form text.
49. The field must accept a maximum of 255 characters.
50. The corresponding database field must support a maximum length of 255 characters, using VARCHAR(255) where appropriate.
51. The system must reject values exceeding 255 characters.
52. Leaving the field empty must not prevent registration.

12. Existing Medical Conditions

53. The existing_conditions field must be optional.
54. The field must allow the patient to enter free-form text describing existing medical conditions.
55. The field must accept a maximum of 255 characters.
56. The corresponding database field must support a maximum length of 255 characters, using VARCHAR(255) where appropriate.
57. The system must reject values exceeding 255 characters.
58. Leaving the field empty must not prevent registration.

13. Email Address

59. The email field must be required.
60. The field must accept a maximum of 100 characters.
61. The corresponding database field must support a maximum length of 100 characters.
62. The system must validate the email address format.
63. The system must reject email addresses exceeding 100 characters.
64. An email address already associated with an account must not be accepted for a new registration.

14. Password

65. The password field must be required.
66. The password must contain at least 10 characters.
67. The password must contain at least one uppercase letter.
68. The password must contain at least three lowercase letters.
69. The password must contain at least one numeric digit.
70. The password must contain at least one special character.
71. The system must reject passwords that fail any of these requirements.
72. The system must provide clear feedback about the password requirements.
73. The password must never be stored as plain text.

15. Confirm Password

74. The confirm_password field must be required.
75. The confirmation field must enforce the same password requirements as the password field.
76. The confirm_password value must match the password value exactly.
77. The system must reject registration when the values do not match.
78. The system must not store the confirmation password as a separate credential.

16. General Registration Validation

79. The form must clearly distinguish required fields from optional fields.
80. The system must validate submitted values on both the client and server sides.
81. Client-side validation must not replace server-side validation.
82. The system must display clear and specific validation messages for missing, invalid, or oversized values.
83. If validation fails, the system must not create the patient account.
84. The system should preserve valid form values when displaying validation errors, except for password fields when security requires clearing them.
85. The system must create the patient account only after all required fields and applicable validation rules pass.
86. Optional fields left empty must be stored consistently according to the database design.
87. After successful registration, the system must display a confirmation message and provide a clear next step for signing in.
88. The system must protect personal and health information against unauthorized access.
89. The system must enforce document and email uniqueness rules at the database level where supported, preventing duplicate accounts during concurrent registration attempts.

US-AUTH-02 — User Login

User Story

As a registered Patient, Doctor, or Administrator, I want to log in securely so that I can access the features authorized for my role.

Acceptance Criteria

1. The system must provide a login form for registered users.
2. The user must provide the required credentials to submit the form.
3. The system must validate the credentials against the registered account.
4. If the credentials are incorrect, the system must deny access and display a generic error message that does not reveal whether the account or password was incorrect.
5. The system must not establish an authenticated session when authentication fails.
6. When authentication succeeds, the system must establish an authenticated session using the application's approved authentication mechanism.
7. The system must identify the authenticated user's assigned role.
8. After successful login, the system must redirect the user to the dashboard corresponding to their role: Patient, Doctor, or Administrator.
9. The system must not allow the user to choose a role in the login form to gain permissions they have not been assigned.
10. The system must initialize the inactivity timeout policy when the authenticated session begins.
11. The system must not expose passwords, authentication secrets, or sensitive token values in error messages or application logs.

US-AUTH-03 — Password Recovery

User Story

As a registered user who has forgotten my password, I want to recover access to my account so that I can sign in again securely.

Acceptance Criteria

1. The login page must provide an option to initiate password recovery.
2. The system must allow the user to submit the account identifier required by the recovery process.
3. The system must display a generic confirmation that does not disclose whether an account exists for the submitted identifier.
4. The system must use a secure, time-limited recovery mechanism to authorize a password change.
5. Recovery credentials must be unique, unpredictable, and invalidated after use or expiration.
6. The system must reject expired, invalid, or previously used recovery credentials.
7. The new password must satisfy the application's password requirements.
8. The system must request confirmation of the new password and reject the change if the values do not match.
9. The system must store the new password securely and must never store it as plain text.
10. The system must confirm when the password has been changed successfully.
11. The system must not change the password when any required validation fails.
12. After recovery, the user must authenticate using the new password.
13. The system must handle recovery failures without revealing sensitive account information.

US-AUTH-04 — Secure User Logout

User Story

As an authenticated Patient, Doctor, or Administrator, I want to log out securely or have my session close automatically after inactivity so that my account and personal information remain protected.

Acceptance Criteria

1. The system must provide an explicit logout option to authenticated users.
2. When the user selects logout, the system must end the authenticated session according to the application's session-management policy.
3. The system must clear the client's authentication state and remove locally stored authentication credentials where applicable.
4. After logout, the system must redirect the user to the login page or another designated public page.
5. The system must prevent access to protected pages and resources after logout unless the user authenticates again.
6. The system must automatically log out the user after 3 consecutive minutes (180 seconds) without qualifying activity.
7. The inactivity timeout must apply equally to Patients, Doctors, and Administrators.
8. Qualifying user activity must reset the inactivity timer according to the defined session policy.
9. Background polling, automatic refreshes, and other system-generated requests must not count as user activity unless explicitly defined by the session policy.
10. When the inactivity limit is reached, the system must clear the client's authentication state and redirect the user to the login page.
11. A user must not be able to regain access to protected resources simply by navigating backward in the browser after logout or session expiration.
12. Logout and automatic expiration must not expose authentication credentials or sensitive personal information.
13. The system must provide a clear message when the session expires due to inactivity.

US-AUTH-05 — Role-Based Access Control

User Story

As an authenticated user, I want the system to enforce permissions according to my assigned role so that I can access only the features and information authorized for me.

Acceptance Criteria

1. The system must recognize the roles Patient, Doctor, and Administrator.
2. Each protected feature must require authentication before access is granted.
3. The system must verify the user's permissions on the server for every protected operation.
4. Patients must not access doctor-only or administrator-only operations unless explicitly authorized by a separate permission.
5. Doctors must not access administrator-only operations unless explicitly authorized by a separate permission.
6. Administrators must access only the operations permitted by the administrator role and the application's authorization rules.
7. Hiding a menu item or button in the interface must not be considered sufficient authorization.
8. If an authenticated user attempts an unauthorized operation, the system must deny the request without exposing protected data.
9. The system must return or display an appropriate unauthorized or forbidden response according to whether authentication or permission is missing.
10. Changing client-side values, URLs, or submitted role information must not grant additional permissions.
11. The system must apply the same authorization rules to browser requests and direct requests to protected endpoints.

US-AUTH-06 — Authentication Session and Token Validation

User Story

As a user of SaludVital, I want the system to validate my authentication session continuously so that expired, invalid, or inactive sessions cannot be used to access protected resources.

Acceptance Criteria

1. The system must validate authentication credentials or tokens before granting access to protected server resources.
2. The system must reject expired, invalid, malformed, or incorrectly signed authentication tokens.
3. The system must enforce the 3-minute inactivity limit for Patients, Doctors, and Administrators.
4. The inactivity policy must be enforced consistently by the client and the server; client-side timers alone must not be sufficient.
5. Qualifying user activity must update the session's last-activity state through the approved session-management mechanism.
6. The system must ensure that automatic requests or background activity do not unintentionally keep an inactive session alive.
7. When 3 minutes of inactivity have elapsed, the server must reject further protected requests from that session.
8. The authentication mechanism must enforce expiration in a way that remains consistent with the inactivity policy, including any required token renewal or server-side session tracking.
9. After expiration, the client must clear its authentication state and redirect the user to the login page.
10. Requests made with an expired or invalid session must not return protected data or perform protected actions.
11. A user must authenticate again before accessing protected resources after session expiration.
12. The system must not trust client-provided role, expiration, or last-activity values without appropriate server-side validation.
13. Authentication failures must be handled without exposing token contents, secrets, or sensitive implementation details.
14. The system must preserve consistent authentication behavior across the Patient, Doctor, and Administrator areas.

US-AUTH-07 — Patient Dashboard Access

User Story

As an authenticated Patient, I want to access my patient dashboard so that I can use the services available to my account.

Acceptance Criteria

1. After successful login, a Patient must be redirected to the patient dashboard.
2. The dashboard must be accessible only to authenticated users with the Patient role.
3. The system must display the patient-facing interface and the features authorized for that role.
4. The dashboard must not expose another patient's private information.
5. If a Patient attempts to access a doctor-only or administrator-only resource, the system must deny access.
6. If the Patient's session is logged out or expires, the system must deny further access to protected dashboard resources.
7. After session expiration, the system must redirect the Patient to the login page.
8. The dashboard must display an appropriate error or feedback message when required information cannot be loaded.
9. Reloading or directly opening a protected dashboard URL must not bypass authentication or authorization.

US-AUTH-08 — Doctor Dashboard Access

User Story

As an authenticated Doctor, I want to access my doctor dashboard so that I can use the clinical and appointment-management features authorized for my account.

Acceptance Criteria

1. After successful login, a Doctor must be redirected to the doctor dashboard.
2. The dashboard must be accessible only to authenticated users with the Doctor role.
3. The system must display the doctor-facing interface and the features authorized for that role.
4. The Doctor must access only patient and appointment information permitted by the application's authorization rules.
5. The Doctor must not access administrator-only resources unless explicitly authorized.
6. If a Doctor attempts to access a protected resource without the required permission, the system must deny access.
7. If the Doctor's session is logged out or expires, the system must deny further access to protected dashboard resources.
8. After session expiration, the system must redirect the Doctor to the login page.
9. The dashboard must display appropriate feedback when required information cannot be loaded.
10. Reloading or directly opening a protected dashboard URL must not bypass authentication or authorization.

US-AUTH-09 — Administrator Dashboard Access

User Story

As an authenticated Administrator, I want to access the administrator dashboard so that I can manage the system using the permissions assigned to my role.

Acceptance Criteria

1. After successful login, an Administrator must be redirected to the administrator dashboard.
2. The dashboard must be accessible only to authenticated users with the Administrator role.
3. The system must display the administrative features authorized for that role.
4. The system must validate administrator permissions on the server before performing protected operations.
5. Patients and Doctors must not access administrator-only resources.
6. Modifying client-side data or directly entering an administrator URL must not grant administrator permissions.
7. If the Administrator's session is logged out or expires, the system must deny further access to protected dashboard resources.
8. After session expiration, the system must redirect the Administrator to the login page.
9. The dashboard must display appropriate feedback when required information cannot be loaded.
10. Reloading or directly opening a protected dashboard URL must not bypass authentication or authorization.
11. Administrative actions must be performed only when the authenticated user has the required permissions.