Version 23 (modified by 9 years ago) ( diff ) | ,
---|
CAP Broker Use Cases
Table of Contents
This page accommodates all the micro-evel use caases associated with the warning functions facilitated through http://eden.sahanafoundation.org/wiki/Deployments/SAMBRO SAMBRO].
Configure Parameters
Manage Users
Subscribe to Alerts
Create CAP Templates
Create CAP Messages
Acknowledge Message
The use case diagram describes how at the time of implementation, the Admin (Implementer) generated subscriber group, termed as first-responders, are assigned to acknowledge (ACK) to a message and the process of recording those acknowledgements.The process flow is intuitive from the use-case diagram as well.
Process Flow
Process | Description |
assign a ACK to group | First we must get subscriber groups and select the desired group. These groups are created by the Implementer. Second the Implementer would assign event type, assign warning priority, and assign location to a ACK. We may not require that low priority messages for certain event types in some location are acknowledged and are simply informative alerts. |
issue CAP alert msg | At the time of authoring a message, the Editor would set the Event Type, Location, and Warning Priority, which would determine the first-responder groups that should receive CAP alert msg through the deliver CAP alert msg process. In the CAP alert msg they would receive a URL with the link to acknowledge the message. This link would typically be a CAP <resource> element. |
send msg "ACK" | The first-responder has two options to send msg acknowledgement: 1) click on the link, login, and press the ACK button or 2) send an SMS with keyword ACK or "ACKNOWLEDGE" with the <identifier> and user login details |
record ACK | The process will get subscriber ID (or Person ID) and get CAP identifier (i.e. message id) to record the acknowledge for a particular message by a particular message recipient. |
Use Case Diagram
Report SOP Status
Often first-responders must follow a Standard Operating Procedure (SOP). The use case diagram describes the process for creating SOP check-lists and requesting that each first-responder update the status of the SOP.
Process Flow
Process | Description |
create SOP check-lists | The implementers will generate a set of SOP check-lists that are event and first-responder specific. SOPs for the police with evacuation procedures for a given event are different from the SOPs medical technicians would follow with tracking emergency patients. |
configure SOP check-list | First we must get event type and get subscriber groups. A SOP check-list will be assigned for the group for a particular event. We would also set a flag that the check-list is requested for specific warning priorities (i.e. low priority messages are informative and do not require activating a SOP) |
request SOP status | The request is sent our as a separate alert, not necessarily as a CAP message but a simple alert. The process would get CAP alert area because the SOP request is sent out to recipients in the location defined by the CAP alert area. The process must get CAP identifier and must get subscriber to associate with the SOP check-list responses. |
update SOP check-list | The first-responder would click on the link, login, and complete the check-list (questionnaire) and save it. They may update the SOP at various stages of the SOP. For example, the police might update the SOP indicating they have begun evacuating people. Once the evacuation is complete, they would count the number of people and update the SOP check-list with the people count. |
record SOP status | The process will get SOP check-list ID, get subscriber (or Person ID) and get CAP identifier (i.e. message id) to update the status of the check-list with the information provided by the first-responder |
Use-case Diagram
Attributes
NOTE - this is simply a list of attributes and is not a database table. Developers must convert this to a normalized database with related tables.
SOP check-list TEMPLATE
Attribute | Data Type | Description |
SOP Name | Varchar(50) | A name to identify the SOP check-list |
Title | Varchar(100) | The title that would be displayed |
Description | Varchar(200) | A description explaining the intent of the SOP check list |
Instructions | Varchar(200) | Any instructions for the first-responders on how, when, and where to complete the SOP check-list |
Item Num | Integer | A sequence number that indicates the order of the question |
List Item | Varchar(200) | A question related to the SOP element (e.g. What is the casualty-illness count) |
Data type | Varchar(20) | Indicate the expected data type for validation; namely, string, integer, decimal, boolean |
SOP check-list UPDATES
Attribute | Data Type | Description |
Person | Varchar(50) | An identifier that relates to the first-responder who submitted the SOP check-list |
SOP Name | Varchar(50) | The name of the SOP check-list |
Item Num | Integer | The sequence number that indicates the the question |
Response | Varchar(200) | The expected answer related to the SOP element (e.g. 20 indicating the casualty-illness count is 20) |
Submit Time | DateTime | The date and time the answer to the particular question was submitted |
Attachments (4)
-
use_case_request_ack.png
(55.8 KB
) - added by 9 years ago.
Acknowledgement request use case
-
use_case_report_SOP_status.png
(70.0 KB
) - added by 9 years ago.
SOP Checklist use-case
-
use_case_report_SOP_status.2.png
(70.2 KB
) - added by 9 years ago.
SOP Checklist use-case
-
SOP_Check_List_ERD.png
(7.4 KB
) - added by 9 years ago.
SOP Checklist entity relationship diagram
Download all attachments as: .zip