Implementation of Electronic Transmission of. Chemical Occurrence Data (CFP/EFSA/DATEX/2010/03/02) 1

Transcription

1 Supporting Publications 2012:EN-313 EXTERNAL SCIENTIFIC REPORT Implementation of Electronic Transmission of Chemical Occurrence Data (CFP/EFSA/DATEX/2010/03/02) 1 SUMMARY Eileen O Dea, Steven Webster and Donal McCoy Food Safety Authority of Ireland, Ireland To support EFSA s overall objective to collect accurate data for risk assessment purposes, the Food Safety Authority of Ireland has implemented and tested an electronic system for collecting, transforming and transmitting sample based results of chemical or physical food investigations to EFSA according to EFSA standards. This project raised the degree of harmonisation of data from different Irish data sources in the national data repository as well as the efficiency of the complete business process including improving our ability to trace data transmissions. A key benefit of the new system is a greatly improved responsiveness to EFSA calls for data on previously unsolicited parameters (e.g. Chromium and Nickel, 2012). The ability of the Food Safety Authority of Ireland to select, transform and transmit data to EFSA is now much faster and less labour intensive. KEY WORDS Key words: Chemical Occurrence, Standard Sample Description, SSD, Transmission, Data, Contaminants, Food, XML DISCLAIMER The present document has been produced and adopted by the bodies identified above as author(s). In accordance with Article 36 of Regulation (EC) No 178/2002, this task has been carried out exclusively by the author(s) in the context of a grant agreement between the European Food Safety Authority and the author(s). The present document is published complying with the transparency principle to which the Authority is subject. It cannot be considered as an output adopted by the Authority. The European Food Safety Authority reserves its rights, view and position as regards the issues addressed and the conclusions reached in the present document, without prejudice to the rights 1 Question No EFSA-Q Any enquiries related to this output should be addressed to DATEX@efsa.europa.eu Suggested citation: Eileen O Dea, Steven Webster, Donald McCoy, Electronic Transmission of Chemical Occurrence Data in Ireland. Supporting Publications 2012:EN-313. [19 pp.]. Available online: European Food Safety Authority, 2012

2 TABLE OF CONTENTS Summary... 1 Table of contents... 2 List of Tables:... 2 Background as provided by EFSA... 3 Terms of reference as provided by EFSA... 3 Introduction and Objectives Introduction Objectives... 4 Materials and Methods Software, Database System and Tools Implementation Data Upload Systems Development: FOODEX Coding Systems Development: National to EFSA Mapping Systems Development: Web Services EFSA Values Creation SSD Data Integrity Checking Extraction and Transmission Production phase... 9 Results Overview Implemented System Data Collection, Transformation and Extraction for EFSA Generating XML and Transmitting XML to EFSA Benefits of the new system Difficulties Encountered and Assessment of SSD Implementation Maintenance of SSD and Controlled Terminologies Conclusions and Recommendations Bibliography Appendix A. Tasks to improve transmission and Maintenance Glossary and abbreviations LIST OF FIGURES: Figure 1: Screenshot of FoodEx Coding Application 6 Figure 2: Screenshot of National-EFSA Terminology Mapping 7 Figure 3: Screenshot of Web Service Application 8 List of Tables: Table 1: Benefits of the new system Table 2: Data Fields for which availability of Lab data needs improvement Supporting publications 2012:EN-313 2

3 BACKGROUND AS PROVIDED BY EFSA CFP/EFSA/DATEX/2010/03/02 IE Data collection is an important task of EFSA and a fundamental component of risk assessment (Articles 22 and 23 of Regulation EC No 178/2002). EFSA has prepared a standard data model which is defined in an XML schema document and a set of standard vocabularies collectively referred to as the Standard Sample Description (SSD) (EFSA, Jan, 2010). The SSD was completed by EFSA with the assistance of the Technical Working Group on Data Collection. In addition, the mechanism of transmission of data to EFSA was defined in the Guidance on Data Exchange (GDE) (EFSA, Nov, 2010). These two Guidance Reports define the requirements for data transmission format, content and mechanism for the Article 36 call for proposals for Chemical Occurrence Data (CFP/EFSA/DATEX/2010/03). TERMS OF REFERENCE AS PROVIDED BY EFSA Electronic Transmission of Chemical Occurrence Data, Call for proposals CFP/EFSA/DATEX/2010/03/02. This Call for proposals was restricted to the National Competent Authorities for the collection of chemical occurrence data included in the list adopted by EFSA Management Board according to article 36 of European Parliament and Council Regulation (EC) No 178/2002. This grant was awarded by EFSA to: Beneficiary: Food Safety Authority of Ireland, Abbey Court, Lower Abbey St. Dublin 1, Ireland Grant title: Electronic Transmission of Chemical Occurrence Data Grant number: CFP/EFSA/DATEX/2010/03/02 Supporting publications 2012:EN-313 3

4 INTRODUCTION AND OBJECTIVES 1. Introduction This project was established to implement and test an electronic system for the formatting and transmission of food sample-based data relating to chemical contaminant analysis in the official laboratories from the Irish National Food Safety Surveillance database (NFSS2) to EFSA according to the EFSA published standards. EFSA s overall objective is to support Member States (MS) in introducing an electronic system for the transmission of data for risk assessment purposes. 2. Objectives The project objective was to implement technology-supported processes to match national sample data elements and values to EFSA sample data elements and values, then to extract, validate and transmit the available data to EFSA from the FSAI national database system (NFSS2) according to EFSA s published SSD. In particular, the sample data elements had to be coded according to EFSA s SSD requirements, using only values which are valid within the SSD Controlled Terminologies to ensure the applicability of the transmitted data for EFSA exposure assessments. It was important to keep a record of the transmitted EFSA codes assigned to Irish national data as well as the timing of transmission. The reason was both to ensure avoidance of duplicated data being transmitted to EFSA as well as to ensure changes made within the Irish national dataset after data transmission to EFSA could be identified and corrections provided to EFSA to ensure the quality of EFSA data warehouse. The project had to test the operation of the implemented electronic data transmission web services process. The validation of the system was based on the transmission of 3 datasets of chemical contaminants data. The process and the technical tools implemented can support the transmission of chemical contaminants in food and feed and eventually occurrence of pesticide residues in food and feed. It is anticipated that the system could also support, with minimal adjustments, other EFSA data collection domains. The project proposal was based on the assumption of Irish national data being already collated within the national database. Work on the receipt, quality assurance and upload of data from the contributing data sources was explicitly excluded from the proposal. The technical and human resources needed to complete the project were estimated in the FSAI project proposal. Also detailed in the proposal were the data sources and numbers of available sample laboratory analysis results within the Irish Food Safety Official Controls process for which data would be transmitted. The final objective of the project was to document the challenges encountered in restructuring a national data system and to make recommendations regarding how other member states might approach such future projects and recommendations to EFSA on the implementation and use of the SSD. Supporting publications 2012:EN-313 4

5 MATERIALS AND METHODS 3. Software, Database System and Tools Database system (server): Our RDMS is Microsoft SQL Server 2008 Standard Edition. SQL Server contains a variety of technologies that we used to develop our solution, namely the Database Engine and Integration Services. Data Mapping National to EFSA: FSAI used Visual Studio 2010 to develop a web based application to enable data analysts to easily apply FOODEX codes to sample data. Xml processor (server and PC): Altova MapForce, XMLSpy WebService (client/server): The FSAI used Visual Studio 2010 to develop a windows form application in VB.Net using the.net 4 Framework to consume web services made available by EFSA. Microsoft Office Standard PC-Software. 4. Implementation 4.1. Data Upload In order to transmit sample data to EFSA, a project pre-requisite was to have data from the necessary laboratories stored in the national data repository (NFSS2). At the time of commencing this project, this process was nearly completed. This task was not specified in the project scope as it was expected to be complete prior to the start of the project. Unfortunately complications were encountered and the preparation of the national database was more time consuming than anticipated. This had a knock-on effect on the schedule for the DATEX project. In any case during April 2012 (month 15 from the kick off meeting) the acquisition of the data was completed and the test phase was initiated Systems Development: FOODEX Coding A web based application was developed to enable Data Analysts to apply FOODEX codes to sample data. It was developed in Visual Studio 2010, using VB.Net as the chosen programming language. The objective of building the application was to ensure that FOODEX codes could be applied to several sample records with common attributes with the minimum amount of intervention by the end user. The application is a web form that consists of 4 dropdown lists to display each hierarchy level of FOODEX codes. Based on the selection made by the user in the first dropdown Supporting publications 2012:EN-313 5

6 list, the subsequent list is populated with data related to that selection. A searchable textbox is also provided that returns possible matches in FOODEX based on what the user types in. This uses a web service to search a function in the database that returns the selected FOODEX code and populates the dropdown lists based on the hierarchy of the code selected. A filterable grid view is provided to display grouped sample data. The user can select a number of records on this grid view and use buttons under each of the dropdown lists to apply the appropriate FOODEX codes to those records. Figure 1: Screenshot of FoodEx Coding Application The FOODEX coding application was used to filter all available sample analysis results in the NFSS2 database to display only those for which results within the EFSA required datasets existed. The sample details regarding these were examined and the lowest (most detailed) FOODEX code applicable was chosen and applied to the records. This was done for groups of samples with the same or sufficiently similar sample characteristics. The chosen FOODEX code was then saved on the national database record. This process will be done periodically throughout the year as data is collected nationally; FSAI anticipate performing this function quarterly. Supporting publications 2012:EN-313 6

7 4.3. Systems Development: National to EFSA Mapping CFP/EFSA/DATEX/2010/03/02 IE FSAI uses an ASP.Net Dynamic Data site to manage our National Values. Early in the design process we identified a number of our National Value tables that would correspond to EFSA s controlled terminology tables. EFSA s tables were imported into our own National Values database and, where applicable, an EFSACode column would be created in our National Value tables, and a foreign key constraint implemented on that column to create a relationship to the relevant EFSA table. To create and maintain these mappings, a Windows form was created since we found that the ASP.Net Dynamic Data site was inefficient for managing this specific aspect. The form consisted of 2 panels, one on the left which displayed a list of tables where relationships exist and one on the right which displayed a grid view with our National Value Name and dropdown where the relevant EFSA code could be chosen. This new system of mapping made it much easier for Data Analysts to ensure appropriate mapping from national to EFSA controlled terminologies Figure 2: Screenshot of National-EFSA Terminology Mapping In order to derive MATRIX codes, a slightly different process was used which involved Supporting publications 2012:EN-313 7

8 defining a mapping table between the FOODEX codes assigned using the application detailed above and the MATRIX codes. This mapping was uploaded directly into the database table. An access mechanism to allow Data Analysts to maintain this table will be addressed in a further development phase Systems Development: Web Services FSAI created a simple Windows based client to consume web services made available by the Data Collection Framework (DCF) for uploading documents. A web reference was added to point to the URL (as supplied by EFSA) and code was written to consume the sendresumedata and Ping functions. There were problems with outbound connections from FSAI to EFSA, but these issues were rectified by passing credentials to our proxy server. The Windows client allows the end user to select an XML file from file system and upload the document to the DCF. Figure 3: Screenshot of Web Service Application 4.5. EFSA Values Creation During the uploading of data from each source to the NFSS2 database, the national standardised data is used to create the relevant EFSA codes and store these in NFSS2. This is done by an update process which reads from the National-EFSA Mapping table described in 4.3 above. Where no mapping exists for a data field or national value, the EFSA value in NFSS2 will remain blank. Similarly, where an Supporting publications 2012:EN-313 8

9 EFSA value has already been created and stored, it will not be overwritten since changes over time to the controlled terminologies of the SSD will necessitate national-efsa mapping changes which should not be reflected in data already sent to EFSA. During this project, this step was iterative as we enhanced the completeness of the value mappings. As regular weekly data now flows into the system from sources, EFSA codes are automatically created and stored. The results in automatic creation of records which are largely SSD compliant at receipt stage, greatly reducing the work required at the stage of extracting and transmitting data to EFSA for each data collection SSD Data Integrity Checking Within the national database, a view was created to display EFSA formatted data. This accessed stored data in the data repository from appropriate fields e.g. Sample Description is a free text field in the national data and is taken directly into the EFSA SSD dataset; FOODEX code is a field created for EFSA only. See Appendix A for details of the view. A filter on the view based on the parameters for extraction for each transmission was applied. This approach enabled Data Analysts to examine records to be extracted and transmitted to ensure their SSD compliance. Validation of Business rules was done during mapping of data to the SSD schema and upload to the test DCF Extraction and Transmission Altova MapForce was used to create a map from the filtered EFSA database view to the required XML Schema. Header information and record keeping regarding transmissions was stored in a spreadsheet. Ideally this will be moved into a database table during the system support & maintenance phase which will allow the Web Services application to store incoming massages within the database system. The Web Services interface was deployed for Data Analysts to allow them to browse to the generated XML file on the FSAI network and transmit the data. MRN and ACK messages from EFSA were received via Production phase Following the completion of the system development project, EFSA coding happens routinely as data flows through the national data system. Refinements of the system need to be completed over the next months to build additional steps into our weekly production process. This will ensure that the vast majority of Irish chemical contaminants sample data will be available and coded according to the EFSA SSD. Thus only checking for uncoded items (due to national or controlled terminology changes over time) followed by export and transmission will be necessary in order to respond to future EFSA calls for data. Supporting publications 2012:EN-313 9

10 RESULTS 5. Overview 5.1. Implemented System The EFSA system is well integrated with our national NFSS2 system and business processes have been defined to ensure the effective management and coding of data throughout the year. A number of system refinements were identified during the project which were not critical to achieving project objectives but were desirable for the ongoing efficient management of official control data and the data sharing process. These are listed in Appendix B and will be addressed during the system support and maintenance phase Data Collection, Transformation and Extraction for EFSA Data for the years for chemical contaminants data sources is now live in the NFSS2 national database. All records needed for the 3 DATEX project transmissions are fully SSD compliant. The remaining data will also be partially compliant based on the national-efsa values mappings. Records which are required for the EFSA Continuous calls for data (deadline 1 October 2012) can now be identified and FOODEX/MATRIX coded. Their extraction and transmission is thereafter very straightforward. The DATEX system will begin the processing of 2012 data shortly. And we anticipate having all the 2012 data SSD compliant be the end of quarter 1/ Generating XML and Transmitting XML to EFSA The mapping of national data fields (either codes or descriptions as required in the SSD) onto the EFSA view is complete and remains the same for all future data transmissions. Similarly, the mapping of the database view onto the EFSA SSD Schema via Altova MapForce will only require modification when the schema changes. For future data transmissions to EFSA, the EFSA view will be filtered to display the appropriate records for transmission and XML will be generated from that for transmission. Supporting publications 2012:EN

11 5.4. Benefits of the new system Implementation of this system yielded significant benefits which are detailed below. Benefits Harmonisation and better traceability of the business process. Data sent to EFSA is now recorded within the NFSS2 system so we know what we sent and when. Creation of EFSA Codes Automated. Since we now store and maintain a map from national EFSA codes, the creation of those codes (excluding FOODEX and MATRIX) is now done automatically as data arrives at FSAI. This reduces our manual workload in EFSA coding records and improves our responsiveness to planned and ad hoc data requests from EFSA. Similarly, FOODEX codes can be created via the coding application regularly throughout the year and MATRIX codes are automatically derived from these. Reduced work and improved speed. Workload involved in selecting, preparing in SSD format and sending data for a specific call for data is greatly reduced which also improves timeliness and responsiveness to ad hoc requests. Flexibility and Reuse: other Irish Data. The system has been built in a flexible way which facilitates its extension to code and transmit data to EFSA in SSD format. The national database NFSS2 is the national repository for all official control food samples analysed in Ireland. Already we are working on extension for use in transmission of: Pesticides data (possibly for 2011 data) Zoonosis in Food and AMR data (Food & Animals) (for 2012 data) Chemical Contaminants in Feed data (possibly for 2012 data) Flexibility and Reuse: FOODEX2 Coding. FSAI are currently investigating what changes would be necessary to facilitate the coding of data according to FOODEX2. We anticipate that use of existing FOODEX, Matrix and other coded data will facilitate the adjustment of the system to cater for the new classification. Flexibility and Reuse: System/Database Sharing. FSAI are currently investigating the possibility of re-use of our applications for the DATEX project in another Member State for whom, Ireland is acting as a mentor country. Table 1: Benefits of the new system Supporting publications 2012:EN

12 5.5. Difficulties Encountered and Assessment of SSD Implementation CFP/EFSA/DATEX/2010/03/02 IE A number of difficulties were encountered in implementing the processes needed to transmit SSD compliant data. Some of these difficulties led to the creation of new processes to cater for them while others were overcome on a case by case basis. These difficulties are summarised below. There were difficulties encountered in creating the EFSA values for Sampling Point (S.39). This was because these values are derived using two fields within our database (Business Type and Food Chain Stage) and did not constitute mapping a single national value to an EFSA one. The national Food Chain Stage item is highly summarised and derives from old EU legislation now repealed (Directive 89/397/EEC); the national Business Type item is much more detailed, with each Business type falling within 1 Food Chain Stage. EFSA Sampling Point is a mixture of these 2 which makes mapping difficult. In our view, Sampling Point controlled terminologies could benefit from a review. It was found that the hierarchy codes for the NUTS catalogue within the SSD did not descend to an appropriate level to allow for the accurate mapping of Sampling Area (S.05); our national data was more detailed and we had to summarise to match the SSD values but had difficulty accessing the NUTS level below what is specified in the SSD. The NUTS catalogue is maintained by the European Commission and information from their website was used to assist in the mapping of this field. There were a number of instances whereby a national value result name within our database did not have a corresponding EFSA value (within R.06). Examples include Dimethylarsinic Acid (as As) and PCB 56/60. In the absence of a relevant mapping destination, these were mapped to Not in List and the actual result name was mapped to Parameter Text (R.07). There is no direct mapping between FOODEX and the matrix catalogue (S.13) as it does not have the sufficient level of detail to be compatible with the pesticide residues matrix classification, for all types of food. Such a mapping structure would easily facilitate deriving S.13 and is due to be implemented as part of FOODEX2. The FOODEX codes assigned to EFSA Product Code (S.12) were found to be deficient in the categorisation of some sample descriptions. This restricted the level of detail to which a sample could be categorised. This was particularly found to be the case for fishery products (e.g. Haddock, Monkfish, Pollock). There were also numerous samples taken as part of the analysis of Food Contact Materials (e.g. cups, bowls, cutlery). There are no values for these items contained within the FOODEX matrix and were therefore excluded from any transmission. These may need to be added to the catalogue especially in light of the recent call for data on Bisphenol A data. Some of the mandatory fields needed to transmit as part of the project were not available within our database. Such fields included Sampling Method (S.35), Supporting publications 2012:EN

13 Parameter Type (R.08) and the Expression of Result (R.25). The relevant values were obtained directly from the source and were hard-coded as values within the database prior to being sent to EFSA. This is not a viable solution for large volumes of data flowing into the national system and we need to improve the availability of such data from our lab sources. Difficulties were also encountered in the management of Dioxin/PCB data. Results were reported to the FSAI at both congener and result group level (i.e. Dioxin like PCBs, Non-Dioxin like PCBs, Marker PCBs etc). There was no parameter code to record these results at the result group level within our database.. Furthermore, WHO- TEQ values were reported at both 1998 and 2005 levels. There was no distinction within Parameter Code (R.06) so we requested clarification and mapped only the 1998 values for transmission. We understand the inclusion of both in the Parameter catalogue will be considered by EFSA. FSAI continue to encounter resistance by sampling officers regarding the level of detail of the sample characteristics to be recorded. Whilst the national authority understands and supports EFSA s need for these details, the burden of data capture falls to labs and sampling officers who are under increasing time and resource constraints. FSAI would be keen to try to ease the burden of data capture with electronic mechanisms which would support the data quality required for SSD compliance. Overall, we found the SSD comprehensive in its capturing of data to fully describe analytical sample results for chemical contaminants. The denormalised (flat) structure of the SSD is an advantage. The data we currently receive from Irish labs is normalised in structure e.g. a sample record and one or more result records which we link together. This is more complex to manage that the denormalised SSD structure Maintenance of SSD and Controlled Terminologies Throughout the project duration, a number of versions of the SSD Controlled Terminologies became available with changes. We found it difficult to: 1. Know when a new version was available. Publication and circulation to interested parties was not always comprehensive and the link on the How to submit data EFSA page did not provide a version reference. 2. FSAI still need to devise an effective mechanism for reading new versions or the SSD controlled terminologies into the national database and identifying the changes and the implications for the national system (e.g. new or amended mappings required). The validfrom, validto and LastUpdated columns included Supporting publications 2012:EN

14 in the SSD controlled terminologies will be used to identify the necessary changes for implementation. Business rules have been built into the SSD schema to ensure data validation in Member States prior to transmission to EFSA. As new business rules and data domains with additional business rules are incorporated into the SSD, no changes to the schema are necessary. FSAI would support the establishment of an organised communication network amongst the data management experts from MSs to ratify proposed changes to the SSD and GDE documentation. This should include a range of experts in data management data analysis and data transmission involved in different data domains. This network should involve both MSs who have implemented SSD and those who have yet to do so. This network could also be organised as a virtual network where communication is performed mainly through teleconference, web conferences and information sharing using ScienceNet. Supporting publications 2012:EN

15 CONCLUSIONS AND RECOMMENDATIONS CONCLUSIONS The implementation of the NFSS2-DATEX system for creating, extracting and transmitting SSD compliant sample records to EFSA for chemical contaminants data has been successful. Three datasets have been successfully transmitted and the system will ensure future similar calls for data can be fulfilled with relative ease. The system has been designed with sufficient flexibility to allow its use for additional data domain transmissions (e.g. Pesticides and Feed) and also its extension to provide EFSA coding capability for additional classification systems (e.g. Zoonosis and FOODEX2). There remain additional opportunities for improvement in the quality of the data that FSAI receive from both the labs and at sampling point. The development of a system for electronic data capture would facilitate this process without a great impact in human resources involved. RECOMMENDATIONS We recommend that EFSA should: Continue to develop the SSD to support additional data domains Continue to support Member States in their implementation of the SSD Organise Member State data management experts to facilitate and support the ongoing maintenance of SSD controlled terminologies Improve the publication and communication mechanism for dissemination of SSD versions. Encourage Member States to improve data quality at the point of capture (e.g. sampling point) rather than at national data collation stage. Supporting publications 2012:EN

16 BIBLIOGRAPHY EFSA. (Nov, 2010). Guidance on Data Exchange. URL: EFSA Journal 2010; 8(1):1457 [54 pp.]. doi: /j.efsa EFSA. (2011). How to submit data. URL: EFSA. EFSA. (Jan, 2010). Standard sample description for food and feed. URL: EFSA Journal 2010; 8(1):1457 [54 pp.]. doi: /j.efsa Supporting publications 2012:EN

17 APPENDIX A. TASKS TO IMPROVE TRANSMISSION AND MAINTENANCE There are a number of tasks needed to make the regular transmission of SSD formatted data to EFSA more efficient. With reference to the quality of data received and how it is collated and analysed, the following items need further attention: The completion of the upload of data from remaining sources (which were not needed for DATEX transmissions) and the streaming of data through our database (e.g. Pesticides, OFMLs, VPHRL, DSL etc). Liaising with the data sources to improve upon the quality of extracts received. This is needed to ensure the receipt of fields needed as part of the transmission of chemical occurrence data. These fields are namely: L.2 Lab Accreditation R.14 LOD R.15 LOQ R.22 MOU R.19 Recovery Factor R.25 Expression of Result S.35 Sampling Method R.08 Parameter Type R.10 Analytical Method Code R.11 Analytical Method Text Table 2: Data Fields for which availability of Lab data needs improvement An addition to our Make Live Report is needed to generate information on the extent to which EFSA data fields are being automatically populated as the data flows into our national database. This will allow early identification of required national EFSA value mappings. Further this will allow early notification to EFSA of values which appear in our national data and have no equivalent in the EFSA controlled terminologies. Improve upon and enhance audit and reference table control. A defined method of reference table control in the national database (NFSS2) is needed. This should include restriction of user access to add/edit reference table values. This is to avoid inserting duplicate or conflicting values into our national value reference tables. Develop a mechanism to identify adjustments between version of SSD Controlled Terminologies which highlights both SSD changes and the implications within the NFSS2 system in terms of existing or newly required national-efsa mappings. Supporting publications 2012:EN

18 Establish a method to apply lab accreditation to various sources. Currently, lab accreditation is applied globally to all data sources as we know they are all accredited. However some of our data source labs are not accredited so when they are uploaded to the system, we need to remove the hard-coding which records them as accredited. We anticipate this will involve use of a table detailing accreditation status per lab including a start & end date for the status. Making hierarchy codes visible within our coding applications, as found within the SSD for controlled terminologies. This will enhance the value of our mapping application and allow for a greater speed of mapping details. A method is needed within our mapping application to cater for Sampling Point (S.39) (see section 5.6). Enhancements are needed to our FOODEX coding application to facilitate the ease of applying values according to EFSAProdCode (S.12). (i) Remove the primary filter of data source within the FOODEX coding application to provide the ability to apply codes to samples that are filtered by sample description as opposed to lab name (or to multi-select labs). In doing so, the duplication of coding can be avoided (i.e. a FOODEX code will apply to a sample description, regardless of its source). (ii) Manageable access to the FOODEX audit table to identify errors and to maintain consistency with coding. (iii) Having the application available remotely would allow for FOODEX codes to be applied at source (i.e. Lab), where there is a greater knowledge of the sample. Even better, we could investigate the use of the application on hand-held devices for sampling officers which would improve the capture of sufficient data to ensure quality recording of FOODEX2 including facets. A mechanism is needed to flag individual data records that have been extracted from our database and sent to the EFSA DCF. This is to ensure that data is not submitted more than once and that any subsequent amendments to data in the national dataset are easily identified and re-submitted as necessary. Supporting publications 2012:EN

19 GLOSSARY AND ABBREVIATIONS ACK DCA DCF EFSA FSAI LIMS MRN MS NFSS2 SSD XML XSD XSL XSLT Acknowledgment Message Data Collection & Analysis, data management group within FSAI Data Collection Framework European Food Safety Authority Food Safety Authority of Ireland Laboratory Information Management System Message Recognition Notification Member State of the European Union National Food Safety Surveillance Database Standard Sample Description Extensible Markup Language XML Schema Definition Extensible Stylesheet Language XSL Transformation Supporting publications 2012:EN