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

An administrator adds a new user which can be either a doctor, a nurse or a patient. Another possibility is a doctor to add a new patient. They can create a new user profile by filling in the information that is required for the type of user which they want to create. Afterwards they can save it and automatically will get an updated list with patients.

3.4. Preconditions

1. Information for the new user of type patient must be accessible (name, surname, PIN, genre, GP).
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 intended 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

Must.

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

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

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

Doctor

• Go to Add new patient.
• Fill in information.
• Save.