Use Case Scenario: Adding user

1. Guidance

This use case is intended to explain the process of adding a new user into the system, by who it can be done and what type of users can be created.

2. Use Case Identification

2.1. Use Case ID: 1.0

2.2. Use Case Name: Adding user

2.3. Use Case History

• Created by: Sashko M.
• Date created: 01.11.2017
• Last updated by: Dajana S.
• Date last updated: 02.11.2017

Use Case Definition

3.1. Actors

• System Administrator
• Doctor

3.2. Trigger

A doctor or a system administrator needs to add a new user into the system. It can be a new patient or a new employee/staff.

3.3. Description

1. An administrator adds a new user which can be either a doctor, a nurse or a patient.
2. A doctor adds a new patient.

3.4. Preconditions

1. Information for the new user of type patient must be accessible (name, surname, PIN, genre).
2. Information for the new user of type doctor or nurse must be accessible (name, surname, PIN, genre, specialization*, working_time).

3.5. Post-conditions

1. The system administrator has added doctors, nurses and patients.
2. A doctor has added patients.
3. The staff can have a look at the patients list in the hospital.
4. The patients can have a look at all the staff information (name, surname, specialization, working_time/shift and room).
5. Each doctor has an access to the full report data for all patients at which they are assigned to be a GP.

3.6. Normal Flow

1. A system administrator or a doctor login into the system.
2. Go to the module for adding new user.
3. The new user's profile information are entered.
4. The new user (patient/employee) is created.

3.7. Alternative Flows

3.1. Information for the user are missing, therefore their user profile cannot be created until all required data at provided (system will not let the user to be created at all and will throw errors on the UI).

3.8. Exceptions

1.1.E.1. The patient hasn't been registered into the system, but they are emergency case. The system allows registration afterwards, so the data for the case will be entered after registration.

3.9. Includes

This scenario goes along with use cases for editing and deleting user profiles.

3.10. Priority

High priority.

3.11. Frequency of Use

Estimation: 2 patients per day.

3.12. Business Rules

All patients must be registered into the system before they are able to make appointments and visit the doctor. Exception can be emergency cases only.

3.13. Special Requirements

The system must be available 99% of the time during the hospital working hours, plus 95% of the time that is not during the working hours.

3.14. Assumptions

All patients agree to give their data to be kept into the system and be accessible by their doctors.

3.15. Notes and Issues

Issue 1: *task description*, assigned to: *name*, (a link to the task can be added here instead writing for each);

Issue 2: Add a special table for the doctors specialists? Nurse and Doctor inherit out of Employee.

Note 1: Field specialization is optional. It is required only for doctors specialists. The GP and nurses can have a default value of this attribute 'GP' or 'nurse' respectively.

Note 2: Is it needed an admin to approve the patient that the doctor has added and why?

4. Use Case List

System administrator

• Click button Add new *user*, where user can be either a patient, a nurse or a doctor.
• Fill in information.
• Click Save

Doctor

• Click button Add new patient.
• Fill in information.
• Click Save