Actions that need to be performed to respond to the incident are directed at a role which will subsequently have users assigned to it. All interactions with the system are tagged with the user identifier and logged in an audit trail that can’t be modified.

Reliability is a key consideration and therefore it is possible to save action cards and other information as PDFs that can be printed and distributed in case of, for example, a major internet outage.

All the information related to the incident is stored in the application and can be viewed (dependent on authorisation) by incident participants. Since the system is continually updated as actions are performed, the current state of the response is always available. 

The information is stored in such a way that it can be viewed from a variety of perspectives. For example actions can be shown as a report showing all actions in the incident that are overdue or all the actions for a particular role organised by priority.

Although the initial steps of most incident plans are well defined, many plans will have to evolve as the incident evolves and some incidents may have no predefined plan at all. A software based system can start with an initial response and add further responses as required. These can range from a single action such as “check drinking water is widely available” to a predefined set of actions and supporting information such as “prepare admissions for decontamination” (an objective).

Active notifications alert people by various channels to the presence of the incident and inform them of actions they are required to carry out. The notifications provide information on several levels:

Informational – a general notice – “Major Incident Declared, multiple casualties, more information to follow”.

Action required – a direct request for something – “Ensure at least 20 units of O neg in stock – see action <link to action>”.

Immediate action required – to Director on Call – “Major incident initiated – review and action <link to incident>”.