Automating Incident Reporting with the Decisions Platform API


There is an emerging trend in technology today of reducing the manual steps involved in an existing workflow, through intuitive “no interface” solutions, which automate any manual steps where possible. These can be as simple as smart car locks which automatically unlock when the key holder is near, or more complex to a level which creates a significant reduction in the administrative burden on an Organization when it comes to data entry tasks like populating Incident Report forms, as we’ll see in this post.


Through [D4H]™ Incident Reporting, we at D4H have seen countless customers lower their administrative burden by replacing generic or outdated tools such as spreadsheets or in the worst cases, pen and paper, in their reporting workflow. Since the release of the Decisions Platform API, we have started to see this taken further by some customers, by developing clever solutions to automate the manual steps involved in populating an incident report. In this post, I’d like the cover the range of functionality and technical details of a solution one of our customers kindly shared with us.

With the goal of reducing the administration workload when filling out Decisions incident report forms for the Wellington Rural Fire Authority, Blair Marshall developed a system which automatically generates incident report forms with all the information available from their paging call-out messages.

The Solution

The process begins with a software defined radio which receives the paging frequency. This then feeds the frequency into a digital signal processing program to decode the FLEX pager messages received from a callout.

These messages are then passed to a custom application written by Blair, which does some pattern matching on each message so it can ascertain how to handle each message. If it recognizes the message as a callout, it the will use some more clever pattern matching to break the paging message into it’s key components. For example, a callout like the following:


would be broken into the following:

Vehicles (array) = [RFOWGTN1, PORI3110, WELL9275, JOHN287]
Incident Call Method (string) = 111
Incident Type (string) = MIN
Location (string) =  TAKARAU GORGE RD MAKARA
Cross Streets (array) = [OHARIU VALLEY RD, MAKARA RD]
Details (string) = CAR FIRE DOWN
Reference (string) = F1938926 

The address is then taking from the message and passed to Google’s geocoding API to recognise the string, gather more details, and create a consistently structured data object. It then does some extra validation via the geocoding API to verify that address result is correct.

Components from this address data object are combined with the additional pager message details, along with the date and time the call was received, and then pushed to the Decisions API to create a report.

The application then sends the pager message via Google Cloud Messaging to any registered recipients through a mobile app, or by text for team members without a smartphone.

So to summarize, from a single pager message, a report is created in D4H Decisions, populated with the relevant information and members notified by also, all without any manual steps. A very impressive feat.

Future Plans

Blair also mentioned future plans to expand this system, where via Selcall, it will be able decode Vehicle statuses and accurately assign an end date to the report, as well as update what vehicles were used.

As the Decisions API expands, it will open up a host of options such as automatically updating incident attendance, which would further reduce admin overhead for the team.

Well done to Blair and the team in NZ for the creativity and dedication to build such a system, I personally look forward to seeing how it will evolve.

If you’re interested in any experimenting with the Decisions API and building an application of your own, you can try out our interactive API documentation sandbox.

If you’re interested in exploring with Incident Reporting solutions, why not request a free information pack.

All content provided on this blog is for informational purposes only. D4H Technologies Limited makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use.