wiki:BluePrint/CAPBroker/UseCases

Version 21 (modified by Nuwan Waidyanatha, 9 years ago) ( diff )

--

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

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 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.



http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/CAPBroker/UseCases/use_case_request_ack.png

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

http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/CAPBroker/UseCases/use_case_report_SOP_status.2.png

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. http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/CAPBroker/UseCases/SOP_Check_List_ERD.png

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
Question Num Integer A sequence number that indicates the order of the question
Question 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
Question Num Integer The sequence number that indicates the the question
Answer 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)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.