INTRODUCTION

In my previous blog I wrote about safety reporting regulatory requirements based on ICAO and (EU) No 376/2014.

When all management levels actively endorse safety as a priority it will encourage personnel to report more and more safety related events either through mandatory or voluntary reporting system.

As a result, safety office will daily receive a significant number of safety reports that would be impossible to manage effectively without adequate software support.

In this blog I am going to describe safety office team daily tasks and how these tasks have to be supported by appropriate software solution.

PROCESSING NEW SAFETY REPORTS

Perform daily overview of all previous and new received safety reports

Safety office team should be able to have a quick overview of all safety reports ever received. Reports should be searchable by various attributes and filtered by status/activity described below.

Identify new received safety reports

New safety reports are just received safety reports waiting to be processed/managed. “Every safety report shall be managed” shall be our policy. Therefore every new safety report has to be somehow processed based on its content and applicability.

Is occurrence already reported?

When more than one report have been received for the same occurrence (e.g. from captain, first officer, purser, any cabin crew member, Flight Data Monitoring, external source, … ) all of them should be grouped and analyzed together inside the same investigation.

Check accountability

If our organization is not accountable for reported occurrence, the software solution should be able to generate “Outgoing safety report to external service provider” and reroute this report for further investigation to selected external organizations (e.g. Ground service provider, Airport authority, ATM, …). This action has to be documented and stored in the system for further tracking of accountable organization activities.

Check applicability

Sometimes reports received are about not safety related occurrences. For an example, if it is about security related event, we should redirect it to Security department, if it is about code-share or wet lease-in operation event important for compliance monitoring purposes, we should redirect it to Compliance/Quality department.

Report might also be out of above mentioned scope and therefore consequently rejected, but in a controlled manner – nothing done, but still recorded by the system.

Mandatory or not mandatory reportable occurrence?

As mentioned in my previous blog, we should not put reporters into position to decide by themselves if certain occurrence is mandatory reportable or not. Therefore, this should be one of the first actions upon receiving new safety report. If the received report is about one of mandatory reportable occurrences listed in applicable regulation (e.g. (EU) No 2015/1018) or standard (e.g. IOSA), the mandatory classification label has to be assigned and due dates for exchanging data with applicable NAA (National Aviation Authority) have to be calculated automatically (e.g. in EU 72 hours for initial notification, 30 days for follow up report, 90 days for final report).

Assign investigator for new reportable occurrence

The most common option how new safety report will be processed is to assign investigator with appropriate competence and domain knowledge to perform investigation. Software should send an email notification to him/her and lock the report preventing anyone else to perform any action on this report.

When investigator completes the investigation, system should send notification to the safety office for investigation approval. If approved, report will be labelled as “closed”. If not, the investigation will be reopened for additional activities.

Report investigation is an important and demanding task and will be covered more detailed in my future blogs.

TIPS AND TRAPS

Keep reporters in the loop! Initial feedback to the reporter is a formal confirmation that his/her report has been received. Investigation closing feedback would be appreciated by the reporter as formal information that investigation of his/her safety report has been closed and as brief description of investigation results.

Safety report with unknown reporter's name is considered Anonymous. For external reporters it might be beneficial to have the option to stay anonymous as they are not part of our company culture. Internal reporters should instead have confidence in the Just Culture of the company and confidentiality (no name goes out of safety office) guaranteed by the safety office. In addition, reporters should be protected by applicable law (e.g. in EU are protected as defined in (EU) No 376/2014).

In smaller companies even anonymized (without personal details) safety reports directly visible to all staff might have negative effect on reporting. Declaring all safety reports confidential by default (only visible to safety team) would solve this. Someone might object regarding sharing safety data contained in safety reports. I would say, do not share raw safety data, share safety information instead (see ICAO Doc 9859 Fourth edition for difference between safety data and safety information).

Don't ever forget that the only purpose of managing safety reports is improving the safety. Therefore by default stay by your reporters. Don't give up even when judicial system attacks the aviation legacy of trustful exchange of “what went wrong” information for the benefit of our common safety.

Trust can not be bought, one wrongly managed case can destroy work of many years and even more years would be needed to re-establish the trust again. And without trust of our reporters we cannot speak about Just Culture or Effective Reporting.

Andrej Petelin

Aviation Safety and Compliance Consultant
November, 2019