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 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:
(RFOWGTN1, PORI3110, WELL9275, JOHN287) 111-MIN TAKARAU GORGE RD MAKARA. (XStr OHARIU VALLEY RD/MAKARA RD) .CAR FIRE DOWN . #F1938926
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.
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.