CAP Broker Use Cases

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

Relay CAP Message

Process Flow

• The editors(alert editor + alert approver) based on their roles would see either link to Update/ Cancel/ Error previous alert or Relay previous alert to their organisation. If current user belongs to alert originating organisation, then they get link to Update/ Cancel/ Error; if not they get link to Relay Alert.
  

for example the DMH may issue the alert, and then when person from RRD login, they can Relay the Alert to their organisation, provided that they are editors.

Use Case Diagram

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