Pest record specification (v 1.0) and data vocabularies for plant health surveillance
Retrieved 07-Jul-2022
1 Glossary
| Abbreviation/Term | Definition |
|---|---|
| Collating system | Higher-level information system that collates records from multiple source systems. |
| Data protocol | A protocol that describes the required fields and controlled vocabulary to produce a valid pest record. |
| ISPM | International Standards for Phytosanitary Measures. |
| NPHSP | National Plant Health Surveillance Program |
| NPPP | National Priority Plant Pests |
| NSP | National Surveillance Protocol |
| NSPWG | National Surveillance Protocol Working Group in SNPHS |
| Pest record | A valid set of completed data fields relevant for a particular pest and surveillance activity. |
| PHS | Plant Health Surveillance section of the Plant Health Policy Branch, Department of Agriculture, Fisheries and Forestry |
| PHSDS | Plant Health Surveillance Data Store |
| PRS | Pest Record Specification |
| PSNAP | Plant Surveillance Network Australasia-Pacific |
| SNPHS | Subcommittee on National Plant Health Surveillance |
| Source system | IT system that is used by a surveillance program to record primary information against the required data fields. |
| Taxonomic Reference Service | A standalone system, purpose-built to provide search services and an expert platform for maintaining the information that underpins an accurate nomenclature and taxonomy. |
2 Introduction
Use of consistent data standards by Australia’s plant biosecurity surveillance programs will ensure that information from across programs can be collated and analysed to build a robust evidence-base for risk management decisions. Implementation of these standards requires the ongoing support of contributors to the national plant health surveillance system. This document guides users through the components of the data standards so that they can store surveillance data in source data systems and share it with collating data systems.
3 Key products
Products that contribute to plant health surveillance data standards will be published on the Plant Surveillance Network Australasia–Pacific (PSNAP) website. The website is maintained by Plant Health Australia (PHA) to provide a centralised repository and gateway to online plant surveillance information for collaboration and sharing.
3.1 Pest record specification
The Pest Record Specification (PRS) is a flexible set of data fields for plant health surveillance that are consistent with the Darwin Core standard for biological occurrence records (Table 4). Where Darwin Core fields are used, data must be compatible with those descriptions. The PRS provides supplementary interpretation of relevant fields as they apply to plant health surveillance. The PRS defines the content that may be stored in each field but does not specify whether fields are required for any specific pest or program. When implemented within a program, some PRS fields may be deemed mandatory to create a valid pest record, for example to meet requirements for ISPM 6, AUSPestCheck™ or program-defined needs. While the PRS contains descriptions for over 60 fields, most operational data collection will be based around 6 mandatory fields and around 20 core fields. Some common usage templates are given in Table 6.
The Pest Record Specification is maintained by Department of Agriculture, Fisheries and Forestry (DAFF) and will be accessible to all stakeholders. Feedback should be directed towards Plant Health Surveillance section in DAFF (planthealthsurveillance@agriculture.gov.au) and revisions will be coordinated through the Subcommittee on National Plant Health Surveillance (SNPHS).
3.2 National surveillance protocols
National Surveillance Protocols (NSP) are technical reference guides that detail the accepted methodologies for conducting surveillance on a specific pest, or group of pests. NSPs will be maintained by the National Surveillance Protocol Working Group (NSPWG) under SNPHS to ensure they stay up to date. Each National Surveillance Protocol is supported by a Data Protocol which provides a link from surveillance records back to the endorsed materials and methods.
3.3 Data protocols and controlled vocabularies
Data Protocols are specific to a pest group. They describe the PRS fields that need to be completed to create a valid pest record, so that presence and absence records can be interpreted consistently for analysis and reporting. Data Protocols draw from the broader set of controlled vocabularies for PRS fields to define the allowable set of values for the pest group (e.g. trap and lure types, hosts). Changes to data protocols will be managed by the NSPWG.
Controlled vocabularies are for use across plant health surveillance applications and provide standard names for inspection methods, non-host substrates, trap and lure combinations, identification methods. A controlled vocabulary for taxonomy is under development.
Guidelines governing PRS fields and the implementation of the controlled vocabulary lists are described below.
4 Information system responsibilities
4.1 Source information systems run by surveillance agencies
The responsibility to maintain and provide records that are consistent with the PRS and free from errors rests with the owners of source information systems, such as the jurisdictional agencies and industry bodies that collect surveillance information. It is recommended that PRS field names and controlled vocabulary be adopted within source systems to facilitate data quality checking against Data Protocols at the source and to simplify the upload of source data into collating systems.
4.2 Collating systems
Standards enable the sharing of plant health surveillance data across programs into collated datasets. AUSPestCheck™ is one such data collation system, managed by Plant Health Australia, but DAFF is also developing complementary systems for enabling analysis. Each program in AUSPestCheck™ requires a data standard specification (such as for NPHSP and NBPSP) that should be compatible with PRS. Some field names in AUSPestCheck™ differ from the names in PRS but their definitions have been mapped directly across. Correct usage of data field formats and controlled vocabulary is validated in the AUSPestCheck™ system before data is allowed to be uploaded.
Contributors to national collating systems will either use the PRS standard terminology in their source systems or create algorithms and processes to translate the data so that it fulfills the standards in the PRS and data protocols.
5 Implementing the Pest Record Specification
5.1 Mandatory fields
A pest record must have responses to a minimum set of data fields, as defined by the program, to create evidence of pest status. AUSPestCheck™, as a collating system, requires the following data fields – a unique occurrenceID (UID), eventDate (dateOfActivity), scientificName (entityName), occurrenceStatus (status), decimalLatitude (latitude) and decimalLongitude (longitude). The PRS also considers these fields as mandatory, although there may be future options to consider surveillance records from more general spatial descriptions.
5.2 Core fields
Further core fields will be required to meet the standard pest record needs of a surveillance program, for example inspectionMethod, protocolID (samplingProtocol) and a record of the substrate examined (hosts, non-hosts, traps) will be needed for almost all applications, including NPHSP and DAFF programs. Depending on pest data protocol, further fields such as trap and lure type, host, or non-host material may be required to characterise the inspection method. Core fields that are required for standard pest records are described below and will appear in data protocols for pest groups.
5.3 Optional fields
Optional data fields may be available under some data protocols, including recording host census information or hosts associated with traps. The use of optional fields fields with a consistent definition may be enforced by a surveillance program. Surveillance programs may recommend additional program-based fields for a particular purpose, for example in emergency responses.
Use of the Pest Record Specification and controlled vocabularies within the plant health surveillance system and by surveillance programs
5.4 Location information
It is strongly recommended that sites are defined as a meaningful epidemiological unit for analysis. Cadastral boundaries often make useful definitions for a site as the entry of risk material is controlled by, and is the responsibility of, a legal owner. Where properties are large or broken into separate crop management areas further subdivisions may be appropriate.
Sites should remain consistently identifiable over time, particularly when host census information is used to build historical risk profiles of an area. As such, the data field “locality”, should be explicit enough to find the surveillance site if the GPS coordinates are incorrect. If locality details are considered sensitive for sharing, they do not necessarily need to be provided to collating systems, but the source systems must be able to verify the spatial data if required. If locality information is presented at a low resolution, such as a suburb, then individual sites should be defined by a unique locationID. A locationID within a source database system should always be available for sharing so that the number and history of unique sites visited can be analysed. As a data element, locationID will be resolvable to a spatial geometry that may be a point, polygon or a line.
GPS location data fields decimalLatitude and decimalLongitude, should be recorded to at least five decimal places (approx. 1 m) and stored in source databases and collating systems in this format. GPS coordinates may be field collected or retrieved from stored spatial feature in a GIS system. It is preferable for all source databases to maintain the geodetic datum that is used for GPS records and other spatial information. If multiple datums are used within a source database, then it is preferable to explicitly store the datum for each record. All information exported to collating systems must provide this information in the output. Where coordinate uncertainty is known, it should be recorded within the pest record.
5.5 Occurrence information
Scientific names for pests must be verifiable against a valid taxonomic source. A Taxonomic Reference Service is under development and, once operational, it is intended that all names are resolvable to a scientific name within the service. Taxonomic name must be recorded without “sp.” or qualifiers. Other qualifiers such as “nr. species x” or “c.f. species y” should only appear in an identification qualifier field and not the scientific name field. The occurrenceStatus should only be recorded as present, absent, pending or inconclusive. Pests can be recorded as absent in the field. If a sample is taken as a result of an inspection method, then the detection status will be recorded as pending against those pests that could be diagnosed as a positive target. Once diagnosed, the detection status for the target can be updated.
5.6 Inspection method
For specific surveillance programs, every pest record must include a response to the inspectionMethod data field, selected from the controlled vocabulary of inspections methods (Table 1). Surveillance data protocols may offer multiple options for valid inspection methods for a pest, such as trapping, sweep netting and visual inspection.
The eventDate is the date the surveillance took place or, in the case of multi-day trapping, the date the trap was cleared. Date formatting should be consistent within a program, either set by the source system or an agreed upon format for manual input. The preferred format is “yyyy-mm-dd”.
The sampleSizeValue (and sampleSizeUnit) identify the amount of host or other material inspected during a survey event. These effort quantities enable analysis to relate surveillance sensitivity to the potential pest population. A measure of effort can be critical for inferring pest status but for some data protocols, this measure may be optional, provided the less complete record satisfies the analysis and reporting requirements of the program.
Table 1 Every pest record must include an inspection method chosen from the controlled vocabulary below.
| MethodDescription |
|---|
| Alcohol wash |
| Beating trays |
| Comb bump |
| Dipping |
| Drone uncapping |
| Floral sweep netting |
| Frame inspection |
| Fruit inspection |
| Insecticide application |
| Isolation from vector |
| Nest collection |
| Plant dissection |
| Public report |
| Public submission |
| Rainbow bee eater pellet collection |
| Sugar shake |
| Swarm collection |
| Sweep netting |
| Timber excavation |
| Tissue sampling |
| Trapping |
| Vacuum |
| Visual surveillance |
5.7 Trap and lure type
Trapping fields (trapType and lureType) must be chosen from a controlled vocabulary list (Tables 2 and 3). Lure type is defined as anything that provides an attractant for the pest, therefore non-specific attractants such as baits are also to be captured in this data field. Baits used in addition to a lure e.g. ‘Khapra lure kairomone and wheatgerm’, are also to be recorded in this field. Where pests have a range of baits that can be used, e.g. ants or snails, they will be recorded in the controlled vocabulary under a broad category, such as a carbohydrate or protein. All pest records that are trapping inspection methods must have a lure response in the lure type data field. Where traps are physical only (e.g. refuges and light traps), the choice of ‘no lure’ is used.
Trap type is defined as any device that is able to capture (but not always retain) a pest. Therefore, snail and ant refuges are considered to be trap types for the purposes of this data field. The trap type list contains specific trap names.
Table 2 Trap types. Every pest record associated with a trapping surveillance event, must include a response in the trap and lure field, as described in the appropriate data protocol.
| trapType |
|---|
| Ant canopy trap |
| Ant gutter trap |
| Ant in-house trap |
| Ant lured pitfall trap |
| Ant refuge trap - vial |
| Bee catchbox |
| BMSB live capture trap |
| Bucket trap |
| Clear sticky trap |
| Cross vane panel trap |
| Delta trap |
| Dome trap |
| Heliothis mesh net trap |
| Homemade trap |
| Light trap |
| Lynfield trap |
| Multi-funnel trap |
| No trap |
| Paton trap |
| Pitfall trap |
| Red sticky trap |
| Rescue traps |
| Snail buster |
| Snail refuge trap - besser blocks |
| Snail refuge trap - commercial |
| Snail refuge trap - polystyrene |
| Snail refuge trap - tile |
| Snailer |
| Steiner trap |
| Sticky mat |
| Sugar feeder |
| Tall black pyramid trap |
| Termite refuge - pine stake |
| Termite refuge - pot |
| Termite refuge - PVC pipe |
| Vespa catch |
| Wall trap |
| Yellow sticky trap |
| lureType |
|---|
| Alpha-ionol and cade oil |
| Alpha-pinene and ethanol |
| Alpha-pinene, ethanol and P333 |
| Alpha-pinene, ipsenol and methyl butenol |
| Anoplophora lure |
| Apiguard |
| Apistan |
| Apivar |
| Asian citrus psyllid lure |
| Bayvarol |
| BMSB lure |
| Capilure |
| Carbohydrate |
| Cellulose lure |
| Cocoa pod borer lure |
| Cuelure |
| Disparlure |
| Fruit fly protein bait |
| Hessian fly lure |
| Khapra pheromone |
| Khapra pheromone kairomone |
| Khapra pheromone kairomone and wheatgerm |
| Khapra pheromone wheatgerm |
| MAQS |
| Melolure |
| Methyl eugenol |
| No lure |
| Nun moth lure |
| Pine lure |
| Protein |
| Queen pheromone |
| Sawyer beetle pheromone and kairomone |
| Spotted wing drosophila lure |
| Standard FAW lure |
| Sugar syrup |
| Trimedlure/capilure and terpinyl acetate |
| UV light |
| White light |
| Wine, vinegar and soap |
| Zingerone |
6 Pest Record Specification (v 1.0) fields for plant health surveillance
Table 4 – Pest Record Specification (v 1.0). Relevant fields are aligned to Darwin Core (DwC) classes and definitions where possible. Alt names identify names that have been used in AusPestCheck™ (where different) and are provided for convenience but are not part of the specification. The system column identifies data responsibilities for record collectors and information system management.
7 Data Protocols
The following pest data protocols support the National Surveillance Protocols and are maintained by SNPHS and Plant Health Surveillance, Department of Agriculture, Fisheries and Forestry. Contact: NSPWG via the SNPHS Secretariat (snphs@agriculture.gov.au) to request additions and reviews and PHS (planthealthsurveillance@agriculture.gov.au) to notify of minor errors. Scientific names for hosts and pests must resolve to a valid taxon described in an accepted taxonomic source. Taxonomic descriptions of hosts and pests must not include extraneous information such as “sp.” “spp.” or “unknown”. All information must be translatable into an accurate scientific name when imported or entered into the source database. Host lists for polyphagous pests are not comprehensive. Major hosts for target pests that may be used to automatically trigger absence records after examination with an appropriate method are provided below. Taxa that will not generate absence information but constrain the valid host range of a pest are identified with an asterisk. More complete host lists, or a link to an online host list, are provided within the National Surveillance Protocols. A summary of all current data protocols is given in Table 5. Full descriptions of the required fields and valid combinations of responses under each surveillance method are given in a separate document, Plant Health Surveillance Data Protocols (v 1.0).
Table 5 – Proposed controlled vocabulary fields for surveillance targets. Responses are provided only where relevant for the pest.
* Broad taxa that may contain hosts for validating data. Plantae is used when host lists for polyphagous pests are too difficult to maintain.
8 Data Templates
Data templates are used to define the minimum fields that are required for particular surveillance methods used in data protocols. Where a field has a controlled vocabulary (such as lure type, scientific name or locality) only the text representation is provided, although in practice, codes may be used. Fields for the collection of sample material and diagnostics will be dependent on samples and are not displayed.
Table 6 – Core data templates