These components cover key areas, including:
- Team support
- Virtual Incident room
- Publish and subscribe nodes
- Software agents
- Asset management - people and equipment
- Support for standardised procedures
- Third party integration
Any incident will involve a team of people and equipment. IncidentKit's team support enables participants, their roles and resources to be associated with an incident. Teams provide a way to isolate an incident and enable all the relevant information to be shared amongst the participants.
Information shared, depending on the team's characteristics, may include things such as the team's members' GPS position.
Participants may come from different organisations, but still be able to share information, regardless of their location.
A key resource of a team is a virtual incident room.
The incident room is the key focal point that facilitates communication between all the participants. When 'events' happen they will be posted to the incident room and pushed to the devices of all the participants. For example:
- If the location of a participant changes this would be posted to the incident room.
- If someone took a photo or video of the incident this would be posted to the incident room.
- Even if a special appliance or someone with a specific skill was needed, this request would be posted to the incident room.
As you can imagine, you could end up with a lot of information being posted to the incident room. To tackle this filters can be applied, allowing you to view GPS fixes on a map or other data as a timeline, for example.
Interestingly information may be posted to an incident room automatically or manually by a user, but from the incident participants' perspective these are the same.
To illustrate this a participant could be automatically posting their location via the GPS received on their smartphone, or their position could be manually entered by someone.
This ability to use both 'software agents' or humans to post information to the incident room provides a high degree of flexibility and resilience.
Publish and subscribe
The data managed by teams is stored in publish and subscribe (pubsub) nodes. Pubsub nodes allow a fine degree of control over who can access and update the data as well as who gets notified when a node changes. So for example a user’s location is published to their 'location' node.
If a user is a member of a team managing an incident then the rules defined for that team may mean that all other team members will receive notifications when the user’s location node is updated.
Pubsub nodes can contain all sorts of different data, from GPS coordinates to photos and videos. To cater for these different sorts of data it is easy for an app to display the content of a node in different ways, for example a map or text.
Automation - software agents
As mentioned, a software agent, for example running on a participant's smartphone, can automatically post their location to the incident room. But specialised agents can be used for other purposes, including handling requests.
So a software agent that is able to retrieve an organisation's standard procedures may be a participant of an incident room. When a user posts a request to get 'procedures for handling a chemical fire' then the software agent can retrieve this and post it back to the incident room.
You could even have a software agent that sets up a telephony conference call if required.
Asset Management - people and equipment
Clearly to successfully deal with complex incidents it is important to know who is available and what skills they have. The same applies to any equipment needed.
Using an IncidentKit based app on their phone, users can record information about themselves and their current status. Using their smartphone to do this means they are most likely to keep this information up to date.
When a request is made via the incident room for someone with specific skills or a special appliance, a participating software agent can handle this request by searching for available assets and reporting back to the incident room.
Standard Procedures and Checklists
In addition to the incident room, checklists are another resource that may be associated with an incident. As specific procedures or checklists need to be used for a given incident these can be retrieved and made accessible from any device a participant is using.
Checklists or procedures can be stored in pubsub nodes so when updated these changes will be pushed to all of the incident participants, enabling everyone involved to be kept up to date by knowing what procedures are being followed and what checks have been completed.
Activity in the incident room is logged, photos and other media stored along with other resources such as checklists so that these are easily accessible for any post incident reviews. For some information it may be desirable to ‘tag’ this information so that it can be used subsequently - e.g. 'a good example of an exotic metals fire'. This tagging of photos could happen during an incident or subsequently in a review.
There will always be the need to integrate an Incident management app with other systems, for example a command and control system. IncidentKit is based on Open Standards, which is a good basis for integration with other systems, but additionally there is support for some standard mechanisms such as HTTP, SMS and email to make integration simple.Software agents can be easily implemented to utilise these integration facilities to provide integration with any third-party solution.