Reporting QA Measures to EBAS – and a Word on Flagging Markus Fiebig, Paul Eckhardt, Cathrine Lund Myhre, Ann Mari Fjæraa, Richard Rud, Anne Hjellbrekke and Wenche Aas NILU - Norwegian Institute for Air Research

What Is Meant With Quality Assurance (QA) Measure? Nature of QA measure depends on type of measurement Round-robin: several laboratories analyse the same sample, reference value (“true value”) calculated from all results, used for offline methods on filter samples. Off-site comparison: Instrument is sent to inter-comparison workshop, lab reference traceable to primary metrological standards, used for online gas- & particle phase measurements. On-site comparison: Traveling standard instrument is calibrated against primary standard, and sent around to stations for comparison while testee is running, used for online gas- & particle phase measurements. …

How Is Quality Assurance Documented With EBAS Data? 2 sets of metadata items: Describing QA measure as a whole (off-site comparison, on-site comparison, round-robin, …) Describing individual execution of measure (individual instrument level) One QA measures has several instances (each station, instrument, …) Documentation provided by responsible calibration centre. QA measure QA instance ID date Description outcome (pass / no pass / not participated) title document name (describing result) Type (off-site comp., on-site comp., …) document URL (describing result) responsible instance Numeric outcome: bias URL (description of whole measure) Numeric outcome: variability

How Does This Look Like in Practice? Example from ozone template: Several relevant QA measures can be reported at the same time. Numerical (bias / variability) and non-numerical result (pass / nopass / not participated) By default, don’t correct data for bias found in QA measure.

A Few Words on Flagging General: Data are supposed to serve several types of applications (“use cases”). Points invalid in one case may be valid for another. Flag data invalid only for instrument malfunctions or breaches of SOP (“smoking below the inlet”) Other conditions (regional influence, etc.) are flagged, not invalidated. State today: Application of flags is very heterogeneous, even within frameworks. Makes data more difficult to use – user can’t rely on presence or non-presence of flags, e.g. when filtering data. Being homogeneous in flagging is an end in itself! Approach: Make data providers actively QA their data manually before submission. Implement automated checks during data upload process (planned). Simplify set of flags recommended for primary use.

Short-List of Flags Flags on short-list should be first to choose from V/I Description 000 V Valid measurement 390 Data completeness less than 50% 392 Data completeness less than 75% 394 Data completeness less than 90% 559 Unspecified contamination or local influence, but considered valid 683 I Invalid due to calibration 684 Invalid due to zero/span check 999 Missing measurement, unspecified reason Flags on short-list should be first to choose from Modifications of short-list depending type of instrument and observation. Full list of EBAS flags (http://www.nilu.no/projects/ccc/flags/flags.html) can still be used if reporter really has special condition not covered by short-list Note: many flags on full list are targeted towards offline, sampling-based observations. Need flag 110 to implement outlier check service. How detailed should information coveyed to user be? Indicate possible reason for contamination? Use detailed data completeness flags or just a few. Allow flags that invalidate outliers for unspecified reason?