Functional Use Cases

Figure 7 shows the use case diagram for the Public Health Complaint SPL. All use cases were adapted from Healthwatcher - Requirements document [18], but the UC05, UC15, UC16 use cases, that were included based on the domain analysis (Section 5.1).

Figure 7: Public Health Complaint SPL use case diagram

Query information [UC01]
Use Case Name: Query information
Description: This use case allows a citizen to perform queries.

Query Health Guide. The citizen might query:

• Which health units take care of a specific specialty.
• What are the specialties of a particular health unit.

Query Speciality Information. The citizen might query:

• Information about a complaint made by a citizen:
  • Complaint details.
  • Situation (OPENED, SUSPENDED, or CLOSED).
  • Technical analysis.
  • Analysis date.
  • Employee that made the analysis.
• Information about diseases:
  • Description.
  • Symptoms.
  • Duration.

Priority: Important
Category: Optional
Inputs and pre-conditions: The data to be queried must be registered on the system
Outputs and post-conditions: The query result to the citizen
Main flow of events:

1. The citizen chooses the type of query
   1. In the case of query on specialties grouped by health units, the system retrieves the list of health units stored.
      1. The system retrieves the details of each health unit such as its description and specialties.
      2. The list of health units is presented to the user on their local display.
   2. In the case of a query on health units grouped by specialties, the system retrieves the list of registered specialties.
      1. The system retrieves the details of each specialty such as its unique identifier and name.
      2. The list of specialties is presented to the user on their local display.
   3. In the case of a query on diseases, the system retrieves the list of diseases.
      1. The system retrieves the details of each disease type such as its unique identifier and name.
      2. The list of disease is presented to the user on their local display.
2. The citizen provides the data for the query
   1. In the case of a query on specialties grouped by health units, the citizen selects the health unit to be queried.
      1. A unique identifier representing the selected health unit is sent to the server.
      2. The system ensures the health unit information is consistent.
      3. The unique identifier is used by the system to search the repository for the selected health unit.
      4. The details of the selected health unit are retrieved including its specialties.
      5. The specialties for the selected health unit are returned to the user.
   2. In the case of a query on health units grouped by specialties, the citizen selects the specialty to be queried.
      1. A unique identifier representing the selected specialty is sent to the server.
      2. The system ensures the health unit information is consistent.
      3. The unique identifier is used to retrieve the list of health units which are associated with the selected specialty.
      4. The details of the health units and specialties are retrieved.
      5. The retrieved health units are returned to the user.
   3. In the case of a query on complaints, the citizen provides the complaint code.
      1. The unique identifier representing the complaint to be retrieved is sent to the server.
      2. The system ensures the complaint information is consistent.
      3. The unique identifier is used to retrieve the complaint entry.
      4. The system must determine the complaint type as to retrieve the appropriate information.
         1. If the complaint is a special complaint the complainer's age, education level and occupation are retrieved (in addition to the standard complaint information).
         2. If the complaint is a food complaint the meal which was consumed, the number of people who ate the meal, the number of sick people, etc. are retrieved (in addition to the standard complaint information).
         3. If the complaint is an animal complaint the animal species and the number of animals affected (in addition to the standard complaint information).
      5. The complaint with all the appropriate information is returned to the user.
   4. In the case of a query on diseases, the citizen selects the disease to be queried.
      1. The unique identifier is used to retrieve the list of health units which are associated with the selected specialty.
      2. The details of the health units and specialties are retrieved.
      3. The retrieved health units are returned to the user.
   5. In the case of a query on complaints, the citizen provides the complaint code.
      1. The unique identifier representing the complaint to be retrieved is sent to the server.
      2. The system ensures the complaint information is consistent.
      3. The unique identifier is used to retrieve the complaint entry.
      4. The system must determine the complaint type as to retrieve the appropriate information.
         1. If the complaint is a special complaint the complainer's age, education level and occupation are retrieved (in addition to the standard complaint information).
         2. If the complaint is a food complaint the meal which was consumed, the number of people who ate the meal, the number of sick people, etc. are retrieved (in addition to the standard complaint information).
         3. If the complaint is an animal complaint the animal species and the number of animals affected (in addition to the standard complaint information).
      5. The complaint with all the appropriate information is returned to the user.
   6. In the case of a query on diseases, the citizen selects the disease to be queried.
      1. The unique identifier representing the disease type to be retrieved is sent to the server.
      2. The system ensures the disease type information is consistent.
      3. The unique identifier is used to retrieve the disease type to query.
      4. The symptoms for the selected disease type are retrieved.
      5. The complete disease information is returned to the user.
3. The query results are formatted and presented to the user on their local display.

Specify complaint [UC02]
Use Case Name: Specify complaint
Description: This use case allows a citizen to register complaints. Complaints can be related to Food, Animal, Drugs, or Special. The four kinds of complaints have the following information in common: Complaint data: description (mandatory) and observations (optional);
Priority: Essential
Category: Optional
Inputs and pre-conditions: None
Outputs and post-conditions: The complaint saved on the system
Main flow of events:

1. The citizen selects the kind of complaint.
2. The system shows the specific screen for each type of complaint.
3. The system registers the kind, date and time of the complaints.
4. The citizen provides the complaint specific data.
5. The system saves the complaint.
   1. The information entered by the user is sent to the server.
   2. The system parses the data entered by the user.
   3. The system creates a new instance of the appropriate complaint type.
   4. The system generates a unique identifier and assigns this to the new complaint.
   5. The complainers address is parsed and saved.
   6. The common complaint information is parsed and stored with the OPENED state.
   7. The specific complaint data is then extracted and stored accordingly.
   8. The system ensures the data is left in a consistent state.
6. The unique identifier is returned and presented to the user on their local display.

Extension Points:
E1. Send data over the internet
The Send data over the internet extension point occurs before step 5

Food complaint specification [UC03]
Use Case Name: Food complaint specification
Description: Food Complaint - DVISA

• Cases where there is a suspicion infected food being eaten.

Priority: Essential
Category: Mandatory
Inputs and pre-conditions: none
Outputs and post-conditions: The food complaint is saved on the system
Main flow of events:

1. The citizen chooses Food as the kind of complaint.
2. The system shows the Food complaint screen.
3. The system registers the kind, date and time of the complaints.
4. The citizen provides the complaint specific data.
5. The system saves the complaint.
   1. The information entered by the user is sent to the server.
   2. The system parses the data entered by the user.
   3. The system creates a new instance of the appropriate complaint type.
   4. The system generates a unique identifier and assigns this to the new complaint.
   5. The complainers address is parsed and saved.
   6. The common complaint information is parsed and stored with the OPENED state.
   7. The specific complaint data is then extracted and stored accordingly.
   8. The system ensures the data is left in a consistent state.
6. The unique identifier is returned and presented to the user on their local display.

Animal complaint specification [UC04]
Use Case Name: Animal complaint specification
Description: This use case allows a citizen to register food complaints
Animal Complaint - DVA

• Sick animals.
• Infestations (rodents, scorpions, bats, etc.)
• Diseases related to mosquitoes (dengue, filariose).
• Animal maltreatment

Priority: Essential
Category: Optional
Inputs and pre-conditions: none
Outputs and post-conditions:The animal complaint is saved on the system
Main flow of events:

1. The citizen chooses Animal as the kind of complaint.
2. The system shows the Animal complaint screen.
3. The system registers the kind, date and time of the complaints.
4. The citizen provides the complaint specific data.
5. The system saves the complaint.
   1. The information entered by the user is sent to the server.
   2. The system parses the data entered by the user.
   3. The system creates a new instance of the appropriate complaint type.
   4. The system generates a unique identifier and assigns this to the new complaint.
   5. The complainers address is parsed and saved.
   6. The common complaint information is parsed and stored with the OPENED state.
   7. The specific complaint data is then extracted and stored accordingly.
   8. The system ensures the data is left in a consistent state.
6. The unique identifier is returned and presented to the user on their local display.

Drug complaint specification [UC05]
Use Case Name: Drug complaint specification
Description: Required information for a drug complaint:

• Patient information: Patient identifier; patient age; patient weight in kilograms or pounds
• Type of problem (check at least one of the following): Adverse event; Product use error; Product problem (e.g. defects, malfunction); Problem with different manufacturer of same medicine
• Outcomes attributed to adverse event (check at least one of the following): Death (specify the date); Life-threatening; Hospitalization - initial or prolonged; Disability or permanent damage; Congenital anomaly/Birth defect; Required intervention to prevent permanent impairment/damage (devices); Other serious (important medical events)
• Date of event
• Date of this complaint (automatically filled)
• Describe the event, problem or use error textually (up to a total of 6400 characters allowed.)
• Relevant tests/Laboratory data, including dates (textual description up to a total of 2000 characters allowed.)
• Other Relevant History, Including Preexisting Medical Conditions (e.g. allergies, race, pregnancy, smoking and alcohol use, liver/kidney problems,etc.) Textual description up to a total of 2000 characters allowed.
• Product Available for Evaluation (check one of the following): yes, no, returned to the manufacturer on (specify the date)
• Suspected products information: Product name; Label strength; manufacturer/labeler; dose/amount; frequency; route; dates of use (If unknown, give duration) from/to (or best estimate); Diagnosis or Reason for Use (Indication); Event Abated After Use Stopped or Dose Reduced? (check one of the following): yes, no, doesn't apply; lot number; expiration date; Event Reappeared After Reintroduction? (check one of the following): yes, no, doesn't apply; NDC number or Unique ID.
• Suspected medical device: brand name; common device name; manufacturer name, city, and state; model number; catalog number; serial number; lot number; expiration date; other number; operator device (check one of the following): health professional, lay user/patient, other (specify); if implanted, give date; if explanted, give date; is this a single use device that was reprocessed and reused on a patient? (check one of the following): yes, no; if yes to previous item, enter name and address of reprocessor (textual description up to a total of 450 characters allowed)
• Product names and therapy dates (exclude treatment of event). Up to a total of 2000 characters allowed
• Reporter information: name; address; city; state; zip code; phone number; email; health professional (check one of the following): yes, no; also reported to (check as many as you want): manufacturer, user facility, distributor/importer; If you do NOT want your identity disclosed to the manufacturer, check here (checkbox)

Priority: Essential
Category: Optional
Inputs and pre-conditions: None
Outputs and post-conditions: The drug complaint is saved on the system
Main flow of events:

1. The citizen chooses Drug as the kind of complaint.
2. The system shows the Drug complaint screen.
3. The system registers the kind, date and time of the complaints.
4. The citizen provides the complaint specific data.
5. The system saves the complaint.
   1. The information entered by the user is sent to the server.
   2. The system parses the data entered by the user.
   3. The system creates a new instance of the appropriate complaint type.
   4. The system generates a unique identifier and assigns this to the new complaint.
   5. The complainers address is parsed and saved.
   6. The common complaint information is parsed and stored with the OPENED state.
   7. The specific complaint data is then extracted and stored accordingly.
   8. The system ensures the data is left in a consistent state.
6. The unique identifier is returned and presented to the user on their local display.

Special complaint specification [UC06]
Use Case Name: Special complaint specification
Description: Special Complaint - DVISA

• Cases related to several reasons, which are not mentioned above (restaurants with hygiene problems, leaking sewerage, suspicious water transporting trucks, etc.)

Priority: Essential
Category: Optional
Inputs and pre-conditions: none
Outputs and post-conditions: The drug complaint is saved on the system
Main flow of events:

1. The citizen chooses Special as the kind of complaint.
2. The system shows the Special complaint screen.
3. The system registers the kind, date and time of the complaints.
4. The citizen provides the complaint specific data.
5. The system saves the complaint.
   1. The information entered by the user is sent to the server.
   2. The system parses the data entered by the user.
   3. The system creates a new instance of the appropriate complaint type.
   4. The system generates a unique identifier and assigns this to the new complaint.
   5. The complainers address is parsed and saved.
   6. The common complaint information is parsed and stored with the OPENED state.
   7. The specific complaint data is then extracted and stored accordingly.
   8. The system ensures the data is left in a consistent state.
6. The unique identifier is returned and presented to the user on their local display.

Login [UC07]
Use Case Name: Login
Description: This use case allows an employee to have access to restricted operations on the Health-Watcher system.
Priority: Essential
Category: Optional
Inputs and pre-conditions: None
Outputs and post-conditions: Password validated by the system
Main flow of events:

1. The employee provides the login and password.
2. The login and password are sent to the server.
3. The system retrieves the employee details using the login as a unique identifier.
4. The system validates the entered password.
5. The result of the login attempt is presented to the employee on their local display.

Extension Points:
E1. Send data over the internet
The Send data over the internet extension point occurs before step 2

Logout [UC08]
Use Case Name: Logout
Description: The employee logouts the system
Priority: Essential
Category: Optional
Inputs and pre-conditions: The employee is logged in
Outputs and post-conditions: The employee is not logged in
Main flow of events:

1. The employee clicks on Logout button
2. The system logs out the employee

Register tables [UC09]
Use Case Name: Register tables
Description: This use case allows the registration of system tables. The following operations are possible: insert, update, delete, search and print. The available tables include:

• Health unit (unit code, unit description).
• Specialty (code and description).
• Health unit / Specialty (health unit and specialty).
• Employee (login, name and password).
• Type of disease (code, name, description, symptom and duration).
• Symptom (code and description).
• Type of disease / Symptom (type of disease and symptom).

Priority: Essential
Category:
Inputs and pre-conditions: Verified employees
Outputs and post-conditions: Updated data on tables
Main flow of events:

1. The employee chooses the option to register (insert/update) in one of the tables.
2. The employee enters the data.
3. The system saves the data.

Extension Points:
E1. Send data over the internet
The Send data over the internet extension point occurs before step 3

Update complaint [UC10]
Use Case Name: Update complaint
Description: This use case allows the state of a complaint to be updated.
Priority: Essential
Category: Mandatory
Inputs and pre-conditions:

• The complaint must be registered and have the OPENED state.
• Verified employee

Outputs and post-conditions: Complaint updated and with state CLOSED.
Main flow of events:

1. The employee selects the update complaint option.
2. The system retrieves the list of all registered complaints.
   1. The complaint list is populated with general and complaint type specific data.
3. The list of complaints is returned to the employee.
4. The complaints are formatted and presented to the employee on their local display.
5. The employee selects the complaint they wish to update.
6. The complaint unique identifier is sent to the server.
7. The system ensures the complaint data is consistent.
8. The system retrieves the complaint entry.
9. The complaint is returned to the employee.
10. The complaint is formatted and presented to the employee on their local display.
11. The employee enters the conclusion.
12. The conclusion is sent to the server.
13. The complaint status is set to closed; the date the conclusion was entered is set in addition to the employee who dealt with the complaint.
14. The system ensures the complaint is left in a consistent state.
15. The complaint information is updated to store the new information.

Extension Points:
E1. Send data over the internet
The Send data over the internet extension point occurs before steps 5 and 12

Register new employee [UC11]
Use Case Name: Register new employee
Description: This use case allows new employees to be registered on the system.
Priority: Essential
Category: Mandatory
Inputs and pre-conditions: Verified employee
Outputs and post-conditions:New employee registered on the system
Main flow of events:

1. The employee selects the insert employee option.
2. The employee provides the following information about the new employee: Name, Login ID, Password (with second password field for confirmation).
3. The employee confirms the operation.
4. The entered data is transmitted to the server.
5. The system verifies the entered data.
6. The system ensures employee data is consistent.
7. The system saves the new employee's data.

Extension Points:
E1. Send data over the internet
The Send data over the internet extension point occurs before step 4

Update employee [UC12]
Use Case Name: Update employee
Description: This use case allows of the employee's data to be updated on the system.
Priority: Essential
Category: Mandatory
Inputs and pre-conditions: Verified employee
Outputs and post-conditions: Employee's data updated on the system
Main flow of events:

1. The employee chooses the update employee option.
2. The employee provides the data to be updated: Name, New password (with second password field for confirmation), Current password
3. The employee confirms the update.
4. The entered data is sent to the server.
5. The system verifies the entered data.
6. The system ensures the employee data is consistent.
7. The system stores the updated employee information.

Extension Points:
E1. Send data over the internet
The Send data over the internet extension point occurs before step 4

Update health unit [UC13]
Use Case Name: Update health unit
Description: This use case allows the health unit's data to be updated.
Priority: Essential
Category: Mandatory
Inputs and pre-conditions: Verified employee
Outputs and post-conditions: Health unit's data updated on the system.
Main flow of events:

1. The employee chooses the update health unit option.
2. The system retrieves the list of all health units.
3. The list of health units is returned to the employee.
4. The list of health units is formatted and displayed on the employee's local display.
5. The employee selects the health unit to be updated.
6. The unique identifier for the selected health unit is sent to the server.
7. The system ensures the health unit data is consistent.
8. The system retrieves the data for the selected health unit.
9. The data retrieved is returned to the employee.
10. The health unit data is formatted and presented on the employee's local display.
11. The employee alters the necessary data.
12. The updated information is sent to the server.
13. The system ensures the health unit data is left in a consistent state.
14. The system stores the updated health unit information.

Extension Points:
E1. Send data over the internet
The Send data over the internet extension point occurs before steps 6 and 12

Change logged employee [UC14]
Use Case Name: Change logged employee
Description: This use case allows the currently logged employee to be changed.
Priority: Essential
Category: Mandatory
Inputs and pre-conditions: Verified employee
Outputs and post-conditions: First employee signed out and new employee logged-in.
Main flow of events:

1. The employee chooses the change logged employee option.
2. The system shows the login screen, and from this point on, the flow will follow the one described in [Login].
   

Receive alerts via feeds [UC15]
Use Case Name: Receive alerts via feeds
Priority: Desirable
Category: Optional
Inputs and pre-conditions: The citizen is using a browser which is capable of subscribing to feed
Outputs and post-conditions: The citizen receives feeds from Public Health Complaint SPL
Main flow of events:

1. The citizen clicks on the link to subscribe to Public Health Complaint SPL feed
2. The system displays some options for the citizen to choose how to subscribe the feeds
3. The citizen selects one option
4. The system registers the citizen

Publish feeds [UC16]
Use Case Name: Receive alerts via feeds
Priority: Desirable
Category: Optional
Inputs and pre-conditions: Update complaint (UC10)
Outputs and post-conditions: Feeds will be updated

Main flow of events:
This use case is triggered automatically after a complaint is updated by an employee [UC10]. Data related to the updated complaint is used to create a feed entry that will be published.