Technical information about occurrence reporting

Technical information about reporting channels and data format, and directions for use of taxonomy.

Reporting channels and data format

Today reporting to CAA Norway can be done via NF-2007 in Altinn or with E5X files via secure file transfer protocol (SFTP). Reporting via Altinn will in the near future no longer be possible.

For small organisations and individuals manual reporting will be possible through the aviation safety reporting portal. If you file an occurrence report in the European portal, it is automatically transmitted into the correct channels. CAA Norway will in due time inform when the switch shall happen.

As an alternative to manual entry of data Europe has developed a standard interface to comply with the requirement to report in an Accident/incident Data Reporting (ADREP) taxonomy and ECCAIRS Software compatible format. This interface is specially designed for organisations reporting a significant volume of incidents and/or targeting organisations with extended IT capabilities. This method of data file exchange is a standard interface and an E5X file.

The E5X file to be submitted is constructed and named in a particular way so that ECCAIRS can process the file automatically. The XML sits in the outer layer of the E5X file alongside a folder of the same name. This folder contains the full PDF (named after the E5X file and folder), and may also contain any additional attachments which can be named independently. One of the aims behind the introduction of a compliant format and the Reduced Interface Taxonomy (RIT) is to reduce the manual entry of routinely reported attributes into ECCAIRS by Safety Data teams. To achieve this aim all attributes which form part of your regular reports and also appear in the RIT are to be mapped into the XML file. Depending on the aviation sector you are reporting from, certain attributes can be hard coded into your XML

For information on how to produce E5X files, use this link.

If your organization creates E5X files, these must be transmitted via SFTP.
Note: E5X files allow attaching files to the occurrences contained in the file. However, this feature should be carefully implemented as it is not possible in the current setup to limit the size of the attachments.

In preparing the implementation of this technical solution, there are two aspects clearly distinguished:

  1. The technical support to build a compliant E5X file (IT wise) and transfer it via SFTP to the authority. Technical support:
  2. The agreement with the competent authority on the content of the E5X file (aviation wise). Content support:  

Occurrence Class "Accident" and "Serious Incident" will still automatically be forwarded to the Accident Investigation Board Norway (AIBN).

Use of taxonomy

In order to ensure a minimum quality of the data transferred from your reporting system to the national authority, as required by Regulation 376/2014, it is necessary to define not only the attributes to be sent, but also the minimum content of those attributes and some basic directions to follow while filling them in.

These directions should be followed in the use of the RIT:

  1. Each attribute in the RIT and each value in the value list contain their definition and own rules of use. Definitions and rules are included in the documentation items in the XSD scheme. Your reporting system should use attributes and provide their values consistently with those definitions.
  2. Should the information of any attribute be unknown or not relevant, the attribute should be transmitted blank or with the value “Unknown”. However, “Unknown” should be only left to those cases where an effort to get the information will be done, and therefore the right value could be expected in a later report. This rule should also apply to those mandatory attributes listed in Annex I of the Regulation 376/2014.
  3. In a value list with more than one level, always the lowest level in the tree should be envisaged. However, failing to find an appropriate value in that lowest level, immediate upper level should be checked. This escalation should be iterated until the most adequate value, though more generic, is found.
  4. Some attributes may contain more than one value; hence the most complete information should be provided.
  5. Some attributes allow code value and free text. In this case, free text should be used to complete the coded value where the coded value is not entirely describing the intended information.
  6. The free text fields should not contain personal information like person’s names. In any case, your reporting system may agree with their competent authority deviations from these basic rules.

Contact information: