In the previous articles we have covered several topics:
Part 1 – Levels-of-Depth – The concept that the system should only expose complexity as a user needs to dive deeper into details.
Part 2 – The Incident – The Incident provides the key information that allows someone to understand the basics of what is happening. It also serves to link together the more detailed information that relate to an Incident.
This article, Part 3 – The Log is all about creating a logging capability that makes for a world-class system.
If there is a single capability to invest in for a basic IMS it is The Log. When the Log is done well, it is singularly the best tool for gathering information and getting a handle on a situation. If The Log is done poorly the whole IMS is at risk of not being used or jettisoned in favour of clipboards and notepads.
The Log allows capture of simple text information and it should automatically record the date and time that the system recorded the entry (i.e. when it was entered); the date and time that the entry occurred (you will still have paper notes for rapid call logging); the operator (name and role) that made the entry; and perhaps the workstation that was used to make the entry.
There are a minimum of two Log tools that you should have and a third level-of-depth will help if you manage a large number of incidents or have a large organization that is brought to bear – the General Log, the Incident Log, and for some larger agencies, the Duty Log.
GENERAL LOG
At the highest level you’ll need a General Log for items that are either routine and non-incident related (e.g. shift changes, general weather statements, administrative items) and to record significant occurrences that affect the whole operations of your organization (e.g. EOC activation/deactivation, Area-wide severe weather) or all of the active incidents. You will want to consider allowing the lower-level logs to be referenced so you can add an item at the General Log level but have it copied/linked to one or more of the Incidents that are active.
INCIDENT LOG
For every Incident you will need an Incident Log. The Incident Log provides a place to log key events and occurrences during an incident. Any information that is relevant to the incident, either immediately or post-incident should be logged in the Incident Log. The audience of the Incident Log is incident-centric, either for situational awareness or for
When an entry is made in the Incident Log you will want to allow the user to automatically add the entry to the General Log as well. This capability will allow your operators to keep the overall organization up to date without having to take extra steps.
DUTY LOG
Following the levels-of-depth approach, if an Incident is large-scale or is supported by many distinct groups in your organizations it may warrant the addition of Duty Logs. Duty Logs keep domain-specific information separate so it doesn’t clutter up the information that users that aren’t in that domain see. For example, under an ICS organization there may be Operations, Logistics, Finance, etc. Other organizations may break Duty Logs out by supporting organization (e.g. Public Works, Health, Security). The ICS and non-ICS approach can also be combined.
Access to the creation of Duty Logs (i.e. the addition of a particular Duty Log category to an Incident) and the ability to add information to a particular Duty Log may be restricted to avoid confusion.
When an entry is made in the Duty Log you will want to allow the the user to automatically add the entry to the Incident Log as well. This capability allows the Duty staff to keep the Incident current with key Incident-level information that they are providing.
ACTIVITY LOG (AUTOMATED LOGGING)
There is a second kind of log that you should consider when creating IMS software. This is an automated log that captures all of the changes that are made during the prosecution of an incident. Changes in resource assignment, task status, incident description, and other items should not require a manual log entry to be made. The system should keep a running activity log of all changes. This can be used in the heat of an event for situational awareness or after the incident has been closed as a post-mortem tool. All Activity logs should contain the user that made the change, the date and time of the change, and if possible, the data that was changed (both before and after).
You will want to limit the events that automatically create General and Incident Log entries to ensure that you don’t overwhelm…
KEY DESIGN DECISIONS
The following decisions need to be made as you implement The Log.
LINKING TO LOG ENTRIES
Where there are existing log entries you will want to allow users to link an existing entry to another log. For example a General Log entry about the weather situation may be directly relevant to a particular incident so you will want to link a copy of that log entry in to the Incident Log. The linkage should be a “shallow copy” (i.e. points to the original and doesn’t duplicate the entry) and store the date and time that it was linked in to the incident.
EVENT-DRIVEN LOGGING
Though the system should capture all of the activity in an incident through the Activity Log, there will be key changes that will warrant creating an entry in the General or Incident Log. For example, the creation and closure of an Incident should automatically create an entry in the General Log. This will allow people reading the General Log to get an idea of when major events happened and it means that the users don’t need to make manual entries. Consider event-driven log entries for event such as Incident creation/closure/re-opening, SOP Activations, SOP completion, etc.
LOCATION
If the location of the computer or mobile device is available for a log entry you may want to consider adding it to the log. The value of the location data will depend on your GIS implementation though (a later topic). This capability would be more “bleeding edge” than the norm, but location information is becoming more and more relevant for operational use.
EDIT or DELETE – A decision needs to be made about whether your log will allow editing and/or deleting of log entries. Regardless, the system should never actually modify the original entry.
EDITING A LOG ENTRY:
In the heat of an incident there are often log entries made with spelling, grammar, and other minor errors. A business decision needs to be made about whether the log should allow editing of these minor errors to allow the log to be cleaned up. If the system allows editing, the user should be presented with the original log entry that they can modify (the text, and the date & time). The system must never modify the original log entry, it should simple be marked the original log entry as “old” and a new entry should take its place.
When editing is allowed, Log entries that have been edited should have an explicit way to view the original entry. Additionally you will want to consider showing any edited entries in log reports. Nobody wants to see the errors, but when an edited log entry is shown, knowing that the changes were immaterial is very important.
DELETING A LOG ENTRY:
Deleting log entries should only be considered in an advanced system where the system has been in use for a long period of time. The confusion that can result from missing log entries is one thing. The legal ramifications are another. Regardless, if a system will support entry deletion there must be an explicit indication in all user-facing parts of the system that an entry has been deleted – the user interface, reports, and other records need to reflect any deletions. The simplest way to provide this capability is to present the original log entry with strike through text. The system may also provide the ability for a user to provide reason for deletion. If the system does support adding a reason for deletion that information should be available to users and in reports.
TAMPER PROOF:
Regardless of whether your system should support Editing or Deleting entries, you will want to consider how the back-end prevents modification of the Log entries. If there is a high need for legal support of a logging system there may be a need to use some kind of cryptographic approach to prove that the contents of a Log entry have not been modified without the proper system-generated audit trail being subverted by modifying the database directly. There are various approaches that can be used to support making a log entry tamper proof but they are beyond the scope of this article. The key thing to consider is whether you need this kind of capability or not.
In this next article we will cover another key area that will ensure your organization is well prepared – Contacts.
