Guidance on Data Exchange 1

Transcription

1 GUIDANCE OF EFSA Guidance on Data Exchange 1 European Food Safety Authority 2, 3 European Food Safety Authority (EFSA), Parma, Italy This guidance, published on 11 November 2010, replaces the earlier version published on 5 November ABSTRACT Data collection is an important task of EFSA and a fundamental component of many of its risk assessment activities. With the assistance of the Technical Working Group on Data Collection, EFSA has developed two guidance documents to facilitate the exchange of data between Member States and EFSA. The Standard Sample Description for Food and Feed, published in January 2010, aimed at harmonising the data content of submissions. The current document is complementary to the first guideline in that it addresses the transmission mechanisms, file formats, security requirements and message exchange protocols (including validation messages) to be used. These two guidance documents are intended to provide the basis for a general model to harmonise the collection and transmission of a wide range of measurements in the area of food and feed safety assessment. KEY WORDS Standard, Format, Chemical, Occurrence, Transmission, XML, Data, Security, Protocol. 1 On request of EFSA, Question No EFSA-Q , issued on 28 October Correspondence: [email protected] 3 Acknowledgement: EFSA wishes to thank the members of the Technical Working Group on Data Collection for the preparation of this EFSA scientific output: Jens Hinge Andersen, Eileen O'Dea, Luisa Oliviera, Jean Cédric Reninger, Renata Del Rosario, Stijn Saevels, Lars Wiehle, Josef Wolf and Roger Wood and EFSA s staff members Fabrizio Abbinante, Stefano Cappè, Marco Leoni, and Jane Richardson for the support provided to this EFSA scientific output. For citation purposes: European Food Safety Authority; Guidance on Data Exchange [50 pp.]. doi: /j.efsa Available online: European Food Safety Authority,

2 SUMMARY Data collection is an important task of EFSA and a fundamental component of many of its risk assessment activities. EFSA receives an increasing volume of data from different providers (e.g. Member States, the European Commission, industry etc.) in support of its scientific activities. The Technical Working Group on Data Collection (TWG-DC) was mandated by EFSA to develop a proposal to harmonise the collection of analytical measurement data for the presence of harmful or beneficial chemical substances in food and feed. The TWG-DC was requested to produce two guidance documents: A Guidance on Standard Sample Description for Food and Feed published on 25 January 2010 covering the harmonised description of analytical measurement data for food and feed samples including a list of standardised data elements (items describing characteristics of samples or analytical results such as country of origin, product, analytical method, limit of detection, result, etc.), controlled terminologies and validation rules to enhance data quality. This Guidance on Data Exchange prescribing procedures to efficiently transmit and exchange data between Member States and EFSA including specific file formats for data transmission (e.g. XML, Microsoft Excel etc.) and specific data transmission protocols to support electronic data exchange. The TWG-DC aimed to develop the Guidance document on Data Exchange to be sufficiently generalised to be applicable to a wide range of data collection processes undertaken by EFSA, even if these data collections require a different data structure from that described in the Standard Sample Description for Food and Feed covering chemical and pesticide occurrence data. The TWG-DC agreed that the establishment of these guidance documents is only the first step in supporting the harmonisation of data transmissions between Member States and EFSA. Another necessary element for a successful implementation of an efficient European data collection system is the construction of a maintenance and development program to ensure that the guidance documents continue to evolve in line with the changing needs of the data analysis and risk assessment stakeholders. Additionally the standardisation effort should be extended to areas not currently in the scope of the guidance on Standard Sample Description to simplify the reporting requirements from the Member States perspective. The group finally recognises that, at the present time, the ability of each Member State to transmit data to EFSA according to the guidance will vary. Therefore this guidance should also be taken into account by member states when planning future developments and evolution of local, regional and national systems with the objective of harmonising data transmissions. 2

3 TABLE OF CONTENTS European Food Safety Authority (EFSA), Parma, Italy... 1 This guidance, published on 11 November 2010, replaces the earlier version published on 5 November Abstract... 1 Summary... 2 Table of contents... 3 Background as provided by EFSA... 4 Terms of reference as provided by EFSA... 4 Consideration Introduction Transmission Methods File Formats Security Requirements Automated Messages Exchange Protocol Type of operations supported Protocol for message exchange FTP implementation Web services implementation XML messaging Data message MRN message Acknowledgment Message Error Codes and Messages General business rules Specific business rules Conclusions and Recommendations Conclusions Recommendations References Appendices Appendix 1 Description of the MRN and ACK as currently implemented in EFSA A1.1 MRN message A1.2 Acknowledgement message A1.3 Transaction Identifier Synchronisation Appendix 2 Description of the business rules applied to the elements of the standard sample description

4 BACKGROUND AS PROVIDED BY EFSA Guidance on Data Exchange Data collection is an important task of EFSA and a fundamental component of risk assessment (Articles 22 and 23 of Regulation EC No 178/ ). EFSA receives from different providers an increasing volume of data in support of its scientific activities. Data may be submitted to EFSA by a variety of providers: national competent authorities, local authorities, laboratories, universities and others. The increasing volume of data transmitted to EFSA involves a number of challenges: Efficient use of human resources in data collection processes, both on the side of the data senders and on the EFSA side where data have to be collected, collated and analysed. Quality of transmitted data, which may differ in origin, language, description and codification. A standard data quality facilitates the task of collating and preparing data for analysis. Capacity of managing high volumes of data; many data collections contain a huge quantity of analytical results, such as data from control and monitoring programs and targeted surveys. The quantity of these data makes their manual processing unfeasible and introduces the need for automated methods of formatting, transmitting, processing and analysing the data. Capacity to analyse the data and to produce valuable reports for the different stakeholders; the increased volume of data requires more advanced techniques for storing and analysing the data. Data should be, as far as possible, readily available for standardised analysis functions to harmonise processing among the different food data stakeholders. EFSA requests that the Data Collection and Exposure Unit, through a self-tasking mandate, harmonise the collection of analytical measurement data for the presence of harmful or beneficial chemical substances in food and feed. The Data Collection and Exposure Unit (DATEX) in coordination and cooperation with the Pesticide Risk Assessment Peer Review Unit (PRaPeR) will establish, for this purpose, a working group of technical experts (Technical Working Group on Data Collection). The working group should report to the Chemical Occurrence Expert Group and to the Networking Group on Pesticide Residues. These networking groups will review and approve all deliverables of the Working Group. TERMS OF REFERENCE AS PROVIDED BY EFSA The working group should focus on both chemical occurrence and pesticide residue data, due to the close similarities between these areas. The working group should build on, expand further and finalise the effort of harmonising the analytical measurement data descriptions already started by the EFSA internal working group on controlled terminology and define the data exchange model format to be used. The working group is requested to produce guidance documents on: 4 Regulation (EC) No 178/2002 of the European Parliament and of the Council of 28 January 2002 laying down the general principles and requirements of food law, establishing the European Food Safety Authority and laying down procedures in matters of food safety. OJ L 31, , p

5 the harmonised description of data on analytical measurements in food and feed samples (Guidance on Standard Sample Description for Food and Feed); The Standard Sample Description contains a list of data elements that are standardised and can be conveniently used by both data senders and data recipients to fully describe samples and analytical parameters for evaluation purposes. This standard provides: name and structure of the defined data elements to be used; controlled terminologies, where needed, with exclusion of the food dictionary which will be addressed by a specific working group; validation rules to assess the validity of the information supplied, to ensure an adequate level of data quality in data export, transmission and storage. The proposal for standardised sample description is based on the initiative developed by the EFSA internal Working Group on Controlled Terminology. The group elaborated a draft standard for the description of chemical contaminants and pesticide residues data. This document was presented at the IT Expert Meeting on February 2009 and was also the basis for a pilot project on pesticide residues data transmission and for an EFSA grant on chemical contaminant data. the methods to efficiently transmit and exchange data between Member States and EFSA (Guidance on Data Exchange); The working group should propose a Guidance on Data Exchange to define methods for the transmission and the exchange of data which would be suitable for the data collected with the standard sample description for food and feed. The guidance should take into account the software tools already set up by the EFSA IT Unit and provide inputs for their enhancement. The guidance should promote the use of semi-automated or automated methods for the data transmission to lower the costs of manual human intervention. The guidance documents should be presented for approval to the EFSA Chemical Occurrence Expert Group and to the EFSA Networking Group on Pesticide Residues. 5

6 CONSIDERATION 1. Introduction The Guidance on Data Exchange takes the logical structure defined in the Guidance on Standard Sample Description for Food and Feed (hereinafter referred to as SSD) and specifies: the file formats for the transmission of data (e.g. Microsoft Excel, Comma Separated Values - CSV, Extensible Markup Language - XML 5, etc.); the protocol for exchanging data between the sender and the receiver; the internet protocol supported to transmit the data electronically; the file formats for the validation rules; additional technical information and specifications to make the electronic transmission possible (error codes, security requirements, etc.) Specifically, the Guidance on Data Exchange will describe the transmission of data between Member States and EFSA, but the methods described can be applied for transmissions between any data senders and any data receivers. The data transmission system needs to meet the following requirements: 1) Simplicity: the system for both the sender and the receiver should be simple to ensure easy implementation. Simplicity should prevail, where possible, over other requirements such as memory occupation, disk occupation, bandwidth occupation; 2) Ensure secure transmissions; 3) Require minimum maintenance; 4) Flexibility: the system needs to be sufficiently flexible to ensure it can keep pace with scientific developments in the field of food and feed risk assessment. Changes should be predominantly managed through routine amendments to the controlled terminology dictionaries in consultation with relevant stakeholders. For more significant changes to the SSD elements, consultation with stakeholders and impact analysis would need to be made prior to implementation; 5) Involve minimal human resources: as far a possible the data collection process should be fully automated and ensure the most efficient use of human resources; 6) Cost effective: the implementation and maintenance costs for the sender organisation should be kept to the absolute minimum. 5 W3C Consortium - Extensible Markup Language (XML) 1.0 (fifth edition) available on line at last accessed on 14/07/2010 6

7 2. Transmission Methods Guidance on Data Exchange The SSD defines the content for the transmission of data between data senders and data receivers. This can be a manual process requiring user interactions or an automated process using procedures developed within information systems. In summary: Manual transmission methods: o Manual posting of files on the EFSA Data Collection Framework (DCF) Web Application; Automatic transmission methods: o Automatic transmission via Secure File Transfer Protocol (FTPS 6 ); o Automatic transmission via SOAP 7 (originally Simple Object Access Protocol). This protocol relies on the extensible Markup Language (XML) as its message format and other Application Layer protocols (mainly Remote Procedure Call (RPC 8 ) and Hypertext Transfer Protocol (HTTPS 9,10 ) for message negotiation and transmission). Automation of transmissions is considered to be a practical way in which large numbers of files and volumes of data can effectively be transmitted without incurring significant human resource demands both for the data sender and data receiver. The Working Group recognises that full automation of the data transmission may not be feasible for all Member States in the short term; however, the publication of this guidance is intended to assist Member States in developing their systems to allow automation in the future. The Working Group acknowledges in addition that for annual monitoring programs, manual transmission is often sufficient. It is anticipated that, for large data collections, batching the data into multiple transmissions (e.g. maximum of 300MB each) may be a pragmatic way to minimise any difficulties in transmitting very large files. 3. File Formats The WG recognises that the transmission format for the Standard Sample Description is XML. The automatic transmission with Web Services and FTPS will be supported in XML only. Tools such as XSLT to format the XML files (data and error messages) into human readable format such as HTML will be provided by EFSA. The main benefits of the XML file structure are: 6 IETF RFC Securing FTP with TLS available on line at based on FTP (RFC 959) and TSL (RFC 2246) last accessed on 17/03/ World Wide Web Consortium - SOAP Version 1.2 Part 1: messaging Framework (Second edition) available on line at last accessed on 17/03/ IETF RFC 707 A High-Level Framework for Network-Based Resource Sharing available on line at last accessed on 17/03/ IETF RCF Hypertext Transfer Protocol -- HTTP/1.1 available on line last accessed on 17/03/ IETF RFC 2818 HTTP over TSL available on line last accessed on 14/07/

8 it is an open standard and based on text files, therefore files can be opened without the need of specific tools; it is easy for machine interaction: information is structured, therefore it is easy for a computer program to read; it is currently broadly supported: there are parsers and tools in several programming languages and technologies; it supports UNICODE encoding therefore is natively appropriate to support a multilanguage user community such as the EU; it is easy to implement compared to other transmission standards and is platform independent; each data element is assigned a specific data type through the XML schema, resulting in improved data quality; basic file validation, which can be performed automatically on the sender side using an XML schema (XSD), prior to transmission to the receiver. This can reduce the number of errors and re-transmissions. Since some senders may not be ready to implement XML transmissions, the WG recommends that EFSA supports manual transmission of other formats (e.g. CSV and Microsoft Excel) using the Data Collection Framework for a limited, defined period. However the WG recognises the following limitations of these transmission formats: CSV: the presence of special characters in the data values (e.g. double quote character ) can result in uploading failures. In addition, the inclusion of delimiter characters within the data values can result in import errors which can seriously compromise the quality of the submitted results; Excel file: the wrong data type assignment (e.g. number formatted as text) can result in data values being converted so missing values during the upload process. Frequently the import tool provides no warning message and the missing values are only detected later in the analysis process. In contrast with XML, for CSV and Excel formats, no automatic validation can be performed by the sender prior to transmission resulting in either an increase in the number of cycles of resubmission of data or potentially onerous manual validation by the sender or receiver or both. The Working Group recommends also batching large transmission into files of approximately 300Mbyte or less (uncompressed) for efficient transmission and data management. In addition, it is recommended that the files are transmitted compressed using zip compression (with programs compliant with MIME type: application/zip or application/x-zip-compressed) in order to reduce the transmission time. 4. Security Requirements The main security requirements connected to data transmission are identified below. It should be noted that whilst the first two requirements are critical, the third is currently seen by the working group as desirable. 8

9 Identification of the sender: the receiver can identify the sender performing the data transmissions. Confidentiality of the transmission: the information involved in the data transmission is accessible only to the sender and to the receiver, even though a public network might have been used to deliver the message. Non-repudiation: the receiver has proof of participation by the sender in the data transmission that cannot be denied. There are Internet standards such as the AS1 and AS2 originally defined for Electronic Data Interchange (EDI), that can equally be used to transmit XML files and that address the three requirements. However the possible use of these standards would require difficult in-house development or the purchase of gateway software. It would also involve the implementation and the maintenance of client and server certificates to be used to digitally sign and encrypt the data transmissions. In order to reduce the complexity of the implementation and the financial impact of specific software or services for the data senders, a simplification of the security requirements is suggested by the Working Group. For the automatic transmission methods, the identification of the sender organisation is performed assigning a user identification and password to be used by the software performing the operation. The confidentiality is implemented using a standard Internet application protocol (FTP, HTTP, etc.) through SSL or TSL. The usage of these protocols implies the installation and the maintenance of server certificates on data receiver side. For the manual transmission methods, the identification of the sender is performed with user identification (USERID) and password. Specific requirements for the length, format and duration of the password are defined. The confidentiality is implemented using the standard HTTPS internet protocol, which requires the installation and the maintenance of a server certificate on data receiver side (e.g. EFSA), but it does not require client certificates for the users. The implementation of the non-repudiation requirement for both automatic and manual transmission methods is not seen as critical at this point, since the user community consists of competent authorities of Member States and EFSA. The implementation of this requirement would imply the usage and maintenance of digital certificates and the implementation of digital signatures by data senders which is currently seen as a significant work burden at the current stage of development of the data exchange through the Standard Sample Description. The working group recommends that the security requirements are re-assessed periodically with the growth of the user community. In case the Member States and EFSA would envisage the need to fully support all the security requirements for data transmission, the technical working group recommends the usage of some gateway software and the implementation of existing Internet standards, which involve the usage of certificates for electronic signature and encryption of the electronic transmissions. 5. Automated Messages Exchange Protocol 5.1. Type of operations supported The Message Exchange Protocol defines a file transmission as the unit of data to exchange between the sender and receiver. The file transmission is identified by the transmissionid (datatrx:receivertrxcode). This identifier allows the file transmission to be retrieved in the DCF and 9

10 should be included in all messages. Since the unit of data exchange is the file transmission, when it is necessary to change a single sample or result, all the samples and results belonging to the same file transmission should be retransmitted. This process, which at first implies bigger file sizes, allows much easier database management processes both at data sender and receiver side. The protocol defines a message framework to perform the following operations: Insert: A new data transmission file is inserted in the data receiver s database. Delete: A data transmission file included in the receiver s database is nullified. The data transmission file should never be deleted by the receiver s database, only flagged as noncurrent. Archiving procedures of nullified files should be set up on receiver s side. Update ( Replace ): A new data transmission file, provided by the sender, replaces entirely a transmission file previously loaded in the receiver s database. The update operation is a more complex combination of the delete followed by the insert procedure 11. The update operation uses a mechanism for tracking the IDs of updated transmissions, so that a link is kept with the old transmission. In addition the update operation should be performed in one transaction, so that in case of system errors at the end of transaction either the new transmission is loaded and the old is deleted or the old is active and the new transmission returned an error. During an update operation there should never be a case where two or more linked transmissions are current or flagged as deleted. The message initiating the data transmission will trigger the different operations using the datatrx:optype attribute. The datatrx:receivertrxcode must also be present for delete and update procedures Protocol for message exchange The Message Exchange Protocol describes the exchange of messages between Member States and EFSA: the data message, the MRN message and the acknowledgment message. Since the term message can be used in different contexts in information systems, it is fundamental to recognise that the term message refers to the EFSA XML message layer (i.e. the data message, the MRN message and the acknowledgment message) which is shown in Figure 1. This layer interfaces with EFSA s and Member States applications for sending and receiving data. This layer is independent and transparent from the specific transport layer protocol defined for this protocol (e.g. SOAP and FTP), therefore the term message should not be confused with FTP messages or SOAP messages. Transport Layer: Transport protocol (SOAP, FTP) EFSA XML message layer: Data message, MRN message, ACK message Application layer: Chemical Occurrence Data/ Pesticide residues data Figure 1: Protocol layers. 11 Currently EFSA Data Collection Framework does not implement an update procedure, therefore the tracking requirement between the different transmissions is not supported. Updates should therefore be downgraded to a delete plus an insert procedure. 10

11 The main participants in the electronic transmission protocol are represented in Figure 2. The Sender represents the reporting organisation (e.g. a competent authority of a Member State). The Receiver represents the organisation receiving the data (e.g. EFSA). Protocol sendresumedata * «extends» «extends» «extends» * * * Send Data Message Send MRN send Acknowledgment Sender (Member State) * * * * Validate XML «extends» «extends» * «extends» Receiver (EFSA) Validate data message Validate MRN Validate ACK Business rules validation * Figure 2: Participants in the protocol The basic steps of the protocol are the following: 1. The Data Sender creates, validates against the agreed schema and transmits an XML file with data to the Data Receiver. Data will be wrapped in an XML message envelope designed to support the protocol which will be defined in the paragraph The Data Receiver will send back a Message Receipt Notification (MRN) to confirm the transmission. At this stage the Data Receiver verifies whether the XML message is a wellformed XML file and also whether it is valid against the provided standard XML schema. 3. The Data Receiver will validate the XML message against a standard set of validation rules (e.g. validation rules published in the guidance on Standard Sample Description p. 39). On the basis of the result of the validation, an acknowledgment message is prepared The Data Receiver will then transmit the acknowledgment message back to the Data Sender, reporting on the positive/negative result of the data transmission. 5. The Data Sender will confirm the receipt of the acknowledgment message through a message receipt notification MRN. The sender should validate the acknowledgment before transmitting back the MRN since a positive MRN confirms also to the receiver that the acknowledgment was well-formed and valid XML. No business rules are applied prior to the 12 Currently the DCF only validate the XML messages against the defined controlled terminology, all the other validations specified in the standard sample description are implemented manually by the data receiver after the receipt of the message. 11

12 acknowledgment message. The MRN is sent back asynchronously calling the Data Sender Web Service. The sender will have to check for a well-formed XML. In Figure 3 the term XML validation refers to both checking for a well-formed XML file and a valid XML file against the specified schema since the XML file cannot be valid without being well-formed first. Sender (Member State) Receiver (EFSA) Data message XML validation MRN Business rules validation Acknowledgment XML validation MRN Figure 3: Message exchange protocol. This definition of the message exchange protocol is only logical and independent from the specific application protocol used for the physical delivery of the message itself. These can be: the File Transfer protocol (FTP); Web Services (WS). There are cases where the MRN may be not generated by the system: Network issues: the data transmission could be lost and the error will be indicated with a proper exception (it could be an HTTP error code for WS or a proper FTP error). 12

13 Security issues: In case of authentication failure the error will be indicated by the transmission protocol with the proper exception (an HTTP error code for WS or a proper FTP error in case of FTP usage). XML validation: In case of successful transmission of an invalid XML document within the transmission file there is no guarantee about the content and delivery of the MRN. Therefore it is always recommended for the Data Sender to validate the XML files against the provided schemas prior to transmission to avoid this problem. In these cases the sender should contact the receiver to find out the result of the transmission. In transmissions performed using mechanisms which allow for some synchronous transmission (e.g. in case of Web Services), a synchronous transmission confirmation will be implemented in order to reduce the possibility of MRNs not being generated by the receiver system. This case will be further explained in the web service section FTP implementation The sender opens an FTP connection on the receiver s FTP server. The Sender authenticates itself using the credentials provided and sends the file. Each Sender organisation will have its own FTP folder on the EFSA system where their files will be saved. Accounts will be created and distributed to each Data Sender by the EFSA Data Manager. In order to signal the completion of FTP file sending, the sender shall put a file with the same name of the transmitted data file, plus the suffix.go. For example: data file = dataprovider1.xml trigger file = dataprovider1.xml.go The content of the trigger file is irrelevant therefore does not need to contain data. It is necessary to put a go file for each transmitted XML file. No further processing will start until the.go has been placed in the target directory of the FTP site. The DCF checks the input file to verify that it is valid according to the defined XML schema. The system will send back asynchronously an MRN via using the information defined for the logged-in organisation. The MRN contains detailed information about the uploaded data file and the result of the XML validation. MRN also contains the transaction identifier (contained in the receivertrxcode of the MRN and of the acknowledgment) that can be used on the DCF web interface to check the complete validation of the message. The Sender will be able to find the file under the Data transmissions table, accessible through the DCF web interface. The file will be removed from the FTP folder once uploaded by the DCF. 13

14 The DCF will execute further validations applying business rules on the original file asynchronously 13. At the end of the process an acknowledgment will be sent to the Sender containing the validation result via . This FTP implementation contains some differences in respect to the Web service implementation proposed in the paragraph below. These differences are due to the fact that the FTP protocol is totally asynchronous while the WS protocol allows synchronous communication Web services implementation Both the data senders and the data receivers will use WS technology to allow back and forward 14 interaction (for MRN and acknowledgment exchange) during each transmission. The interface (WSDL) of the WS installed on the data sender s side is defined by EFSA and this interface is the same for all organisations involved in the electronic transmission. For simplicity also the interface installed on EFSA s side follows the same WSDL. The WSDL are therefore all the same with the exclusion of the URL address of the web service located in the element soap:address attribute location. This element must be modified manually by the sender in the WSDL obtained by the EFSA system. A Web Service interface contract (WSDL) is available and can be downloaded from Each organisation has the responsibility to implement and maintain the WS of their organisation as reported in Figure 4. The WSDL file includes three methods: sendfilename: This method is for internal EFSA use. Senders are not requested to implement this method ping: This method is for checking if the web service is up and running without the need of performing an actual data transmission. The synchronous response of this method is a text string reporting TRXOK. sendresumedata: This method is the only method available for transmitting all the XML messages (data messages, MRN messages and acknowledgment messages). The synchronous response of this method is a text string reporting TRXOK if the receipt of the XML file was correct otherwise TRXKO if the transmission of the XML was not correct. Therefore the Web Service transmission protocol proposed in 4 should be interpreted as described below. 13 Currently the DCF only validate the XML messages against the defined controlled terminology, all the other validations specified in the standard sample description are implemented manually by the EFSA data managers after the receipt of the message. 14 The transmission of each data message, MRN and ACK is a actually a one-way communication although in the WSDL the methods have been defined as two-ways communications: (this to overcome some library limitations) 14

15 Sender (Member State) Receiver (EFSA) 1.sendResumeData(Data message) TRXOK Minimum info in the header XML validation 2.sendResumeData(MRN) TRXOK 3.sendResumeData(ACK) Business rules validation XML validation TRXOK 4.sendResumeData(MRN) TRXOK Figure 4: Web service implementation. 1. The Sender (e.g. Member State) sends the data message to the Receiver side (e.g. EFSA) using a WS installed on the Receiver side, calling the method sendresumedata. The Data Receiver WS is protected and requires authentication: each Sender will be provided with its own credentials to be used to access the WS. The authentication will be based on the generic HTTP-basic mechanism but this may change to strengthen security. The receiver will verify that the essential information is present in the data message and contains valid information: a. sendercode must exist and be registered in DCF and for the data collection described in the dccode element; b. A valid reference to an XML schema is reported in the document. c. receivercode must be EFSA ; d. type must be a supported document type (e.g. dcfmsg ); e. version contains a supported version of the protocol (e.g. 1.0 ); f. sendertrxcode contains an identifier 15

16 g. receivertrxcode contains a valid and existent receivertrxcode in case of optype of update or delete; h. dccode: contains a valid data collection code registered in the DCF system. Where these checks are positive then the Receiver will confirm the transmission with a synchronous response TRXOK and the protocol will proceed with the MRN generation; otherwise the Receiver will generate a TRXKO and the transmission will be terminated. 2. The Receiver checks asynchronously whether the input file is well-formed and valid according to the XML schema. The Receiver will send back a MRN calling the sendresumedata method WS exposed function on the Data sender side. The Sender WS shall be security protected and the sender shall provide EFSA with a user ID and password to access their WS. The Receiver expects a positive response to the MRN transmission through a TRXOK. In case a TRXKO is received, the protocol is stopped and the data message is considered not to have been received. If the MRN was positive, the receiver moves to point 3; otherwise the protocol stops and the data message is considered not to have been received. 3. The Receiver will execute further validations applying business rules on the original file asynchronously. At the end of this process the Receiver will send back an Acknowledgment to the Sender containing the validation results calling the sendresumedata method of the WS of the Data Sender. The Receiver expects a positive response to the MRN transmission through a TRXOK. When a TRXKO is received, the protocol is stopped and the data message is considered not to have been received. 4. The Sender will validate the acknowledgment message and sends back an MRN to the Receiver calling again the sendresumedata method to notify the receipt of the acknowledgment message. The Receiver will validate the MRN and generate a positive response to the MRN transmission through a TRXOK. In case of errors in the MRN a TRXKO is sent back by the receiver, the protocol is stopped and the data message is considered not to have been received. In addition, the data message is considered not to have been received if the MRN transmitted by the sender is negative. 16

17 MemberState EFSA WebService Provider EFSA_WSDL IDs WebService Client elect Backend WebService Provider Internet SOAP / HTTPS Backend MS_WSDL WebService Client elect Figure 5: Web services architecture diagram. The Article 36 beneficiaries in CFP/EFSA/DATEX/2009/01 and EFSA IT will investigate possible enhancements in the implementation of the SOAP protocol particularly the synchronous MRN and the option of including information from the data message in the SOAP message. 6. XML messaging EFSA has currently set up a system, supporting XML messages to pilot this type of data transmission during the article 36 projects CFP/EFSA/DATEX/2009/01 and Pesticide Residues Monitoring This system already includes a data message, an MRN message and an acknowledgment message. The Working group revised and modified the XML schemas for the data message, the MRN and the acknowledgment. Particularly the names of some data elements were changed. The main changes were performed to the acknowledgment message to support a better reporting of the detected errors and warnings to the sender. The acknowledgment now includes only an error summary, while the detailed error report has been moved to a separate file which can be downloaded by the sender after the acknowledgment has been received. While the EFSA system already supports the new version of the data message, the MRN and ACK are still aligned to their former versions, which, for completeness, are listed in Appendix 1. The new versions of the data message, MRN and acknowledgment, as agreed by the Working Group, are described in the paragraph below Data message The Data Message is comprised of three complex elements containing data fields: The message header: contains information to allow the communication protocol to deliver the MRN message to the sender. 17

18 The data transmission (datatrx): contains the information if the Sender is performing an insert (code 01), update (code 03) or a delete (code 02) operation. It defines also the data collection to which the data contained must be appended. Dataset: contains the analytical measurement data as defined in the Standard Sample Description (SSD). The Data message diagram reports the structure of the MRN message, which is then further detailed in Data message elements. The element datatrx related attributes is defined as an attribute in the data message and as an element in the MRN and ACK messages. This is only due to compatibility and historical reasons. 18

19 Figure 6: Data message diagram. 19

20 Table 1: Data message elements. Element Name Type Description Mandatory Message Element Message element Header Element Message header type xs:string (20) Values: dcfmsg version xs:decimal (5, 2) Values: 1.0 Type of transmission Message version supported in this transmission. code xs:string (100) Unique code for the file transmitted, the file name could be used if unique. receivercode* xs:string (100) Code representing the organisation receiving the data transmission sendercode* xs:string (100) Code representing the organisation sending the data. sentdate xs:datetime Date the message has been sent from the sender; in case this date cannot be produced this element should include the date the data message was created. datatrx Element The data transmission part of the message contains the data for a specific data collection. receivertrxcode xs:string (100) Identifier of the data message (identified by the element message ) inserted in the receiver database. This Identifier is returned in MRN message by the receiver of the Data message (= EFSA) after the first insert operation and must be used for all further message based communication. sendertrxcode xs:string (100) Identifier of the data message (identified by the element message ) inserted in the receiver database. No optype xs:string (2) Values: Operation to be performed on the dataset: Insert=01, Delete=02, Update=03 15 dccode* xs:string (100) Identifier for the data collection. dcname* xs:string (500) Name for the data collection. No trxcomm xs:string (100) Text comment for this transmission No * These codes are defined by EFSA and provided to the sender at the beginning of the reporting period. 15 The update procedure is not implemented in the current version of the Message Transmission Protocol 20

21 6.2. MRN message The message structure is made up of two elements containing data fields: The message header: contains information to allow the communication protocol to deliver the MRN message to the sender The message MRN: contains the information if the message has been accepted for processing by the receiver and whether the file is well formed. In addition the MRN body contains the transmissionid (receivertrxcode) which allows the sender to find the transmitted dataset in the receiver s database. Even if the message transmission receives a positive MRN, the actual acknowledgment message could be negative. The MRN contains only the information that the message is well-formed and valid according to the defined XML schema, and can be processed by the receiver. The MRN does not contain the actual result of the business validation of the content of the XML message. The actual result of the business rules validation process is delivered by the acknowledgment message. The MRN message diagram reports the structure of the MRN message, which is then further detailed in Message MRN elements, where all elements included in the MRN message are listed. Figure 7: MRN message diagram. 21

22 Table 2: Message MRN elements. Element Name Type Description Mandatory header Element Message Receipt Notification (MRN) message header. The message header has the same elements as in the XML message mrnbody Element Content of the MRN message sendertrxcode xs:string (100) Identifier of the data message (identified by the element message ) inserted in the receiver database. receivertrxcode xs:string (100) Identifier of the data message (identified by the element message ) inserted in the receiver database. This Identifier is returned in MRN message by the receiver of the Data message (= EFSA) after the first insert operation and must be used for all further message based communication. msgreceivedate xs:datetime This field specifies when the message has been received by the receiver's system. dccode xs:string (100) Identifier for the data collection. dcname xs:string (500) Name for the data collection. No mrndate xs:datetime This field specifies when the MRN message has been created by the receiver's system. mrncode xs:string (2) Values: This field contains the MRN code. "01" means transmission accepted. "02" means transmission not accepted because of parsing errors in the message, or for errors at security level. parsingerror xs:string (4000) This element will contain the parsing error generated checking if the transmission file is a well-formed XML file and if it is valid according to XML schema. No To facilitate the reading of the acknowledgment message from users an XML Transformation Stylesheet to HTML will be produced by EFSA and an example can be found in the annexed zip file (XML.zip) with the name formatmrn.xslt Acknowledgment Message The message structure is embodying three elements containing data fields: The message header: Contains information to allow the communication protocol to deliver the acknowledgment message to the sender. The message acknowledgment (msgack): Contains information on the result of the entire message processing. If the transmission acknowledgment code (trxackcode) contains the value: 22

23 o o o 01 : the message was loaded by the receiver system without errors and warnings. No further action is required by the sender of the message. 02 : the message was not loaded by the receiver system because of errors in the message. The sender has to correct the message and resubmit the data to the receiver : the message was loaded by the receiver system with warning, but with no errors. The sender may decide to correct the fields generating warnings but the action is not required. In addition this entry contains the transmissionid which allows the sender to find the transmitted dataset in the receiver s database. It is paramount that the sender keeps track of the transmissionid held in the receivertrxcode. The sender will have to use the transmissionid for any further operation of replacement or nullification (deletion) of the dataset. The transmission acknowledgment (trxack): This entry contains the result of the validation of the data contained in the data message in the form of error codes and error descriptions. The data fields in this entry provide to the sender information with the necessary information required to prepare a new data submission with the identified errors corrected. If no errors or warning have been detected by the receiver s system, then the entity transmission acknowledgment (trxack) is not generated. The Acknowledgment diagram reports the structure of the acknowledgment message, which is then further detailed in Acknowledgment elements, where all elements included in the acknowledgement are listed. 16 The element ackcode specifies a value 03 for warning to keep compatibility between the trxackcode of the ACK message and the mrncode of the MRN code. 23

24 Figure 8: Acknowledgment diagram. 24

25 Table 3: Acknowledgment elements. Element Name Type Description Mandatory ack element Acknowledgment element header element Message Acknowledgement (ACK) header. The message header has the same elements as in the XML message ackbody element Message Acknowledgement Body. msgack element This entity contains information on the overall validation of the message. msgreceivedate xs:datetime This field specifies when the message has been received by the receiver's system. msgackdate xs:datetime This field specifies when the acknowledgment message has been created by the receiver's system. trxackcode xs:string Values: This field contains the acknowledgment code. "01" means transmission successful. 02 means transmission not successful because of errors in the message. "03" means transmission successful with warning. 03 sendertrxcode xs:string Identifier of the data message (identified by the element (100) message ) inserted in the receiver database. receivertrxcode xs:string Identifier of the data message (identified by the element (100) message ) inserted in the receiver database. This Identifier is returned in MRN message by the receiver of the Data message (= EFSA) after the first insert operation and must be used for all further message based communication. dccode xs:string This field contains the code of the data collection which is (100) involved in the data transmission. dcname xs:string This field contains the name of the data collection involved (500) in the data transmission. trxack Entity List of elements reporting the summary acknowledgment information. errref xs:string This attribute contains the place where the detailed error list (500) can be downloaded. ErrorInfo Entity This entity provides summarised information regarding warnings and errors. errortype xs:string (1) The type of information the acknowledgment is returning. "E" Error, "W" Warning, I information. rulecode Xs:string Code of the validation rule applied to the element. (10) errorcode xs:string This field contains the error code generated by the receiver (10) system. errordescription xs:string This field contains the text description of the error, warning (500) generated by the receiver's system. var xs:string The name/s of the elements/s tested in the validation rule (can (1000) contain $ separators). example xs:string An example of the combination of data message values that (4000) failed the validation rule (can contain $ separators). records xs:long Number of records (Results in case of Standard Sample Description message) which failed this validation. No No No No No No 25

26 To facilitate the reading of the acknowledgment message from users an XML Transformation Stylesheet to HTML will be produced by EFSA and an example and an example can be found in the annexed zip file (XML.zip) with the name formatack.xslt. The acknowledgment message, as anticipated, contains only a summary of the errors detected in the sender s message. In case the sender wants to access the full list of errors, they can be downloaded following the URL link contained in the acknowledgment message, in the attribute errref. The XML schema for the detailed error file is displayed in Figure 9 Detailed error report, which is then further detailed in Acknowledgment elements, where all elements included in the error report are listed. Figure 9: Detailed error report. 26

27 Table 4: Error report elements. Element Name Type Description Mandatory errackdetails element List of detailed errors encountered during the business rules validation process. receivertrxcode xs:string (100) Identifier of the data message (identified by the element message ) inserted in the receiver database. This Identifier is returned in MRN message by the receiver of the Data message (= EFSA) after the first insert operation and must be used for all further message based communication. errackdetail element This entity contains the output of an individual validation using the business rules. errorseq xs:long Identification number of the error in the file. errortype xs:string (2) The type of information the acknowledgment is returning. "E" Error, "W" Warning, I information. rulecode Xs:string (10) This field contains the code of the rule generating the error. errorcode xs:string (10) This field contains the error code generated by the receiver system. errordescription xs:string (500) This field contains the text description of the error, warning generated by the receiver's system. Var xs:string (250) List of the variables involved in the validation rule. No varval xs:string (250) List of variable values that are involved in the validation rule. recordcode xs:string (20) The "resultcode" from the data message file, identifying the result which failed validation. No No To facilitate the reading of the acknowledgment message from users an XML Transformation Stylesheet to HTML will be produced by EFSA and an example can be found in the annexed zip file (XML.zip) with the name formatdetailederror.xslt. 7. Error Codes and Messages In general three steps of validation can be distinguished during the processing of an XML file. The steps are strongly consecutive. The three steps must be executed in sequence and the following step cannot be performed if the previous step was not successfully completed. 1. Check whether the XML is "well-formed": The file is tested to verify that it satisfies a list of general XML syntax rules, provided in the XML W3C specification, to verify if a generic file is an XML file. This control is performed automatically by any XML parser. The data message is verified well-formed upon arrival at EFSA and the output of this parsing process is part of the MRN message. The parsing error messages, if generated, will be inserted in the element parsingerror. 27

28 2. Check whether the XML is "valid": The validation of an XML file is the process that checks if a generic XML file follows a specific template defined by an XML schema. Its elements and attributes are declared in the schema and follow the grammatical rules specified in the schema. This control is also performed automatically by an XML parser. The data message is verified valid at EFSA after the initial check for XML well formed. The output of the validation process is part of the MRN message. The validation error messages, if generated, will be inserted in the element parsingerror. 3. XML is checked against the business rules 17 : Conformity to rules, which cannot be tested in step 2, but are necessary to verify the consistency and coherence of the data are checked in the last step. The business rules are verified at EFSA with custom software, which has yet to be developed. The output of the business rules check is reported in the acknowledgment message. Business rules describe the constraints used to accept data at the receiver side during the data transmissions. The receivers must always reply back to the sender through an acknowledgment transmission whether an SSD transmission is accepted or not. In case of failure of the transmission, the receiver should also describe the reasons which determined the failure of the message transmission. Though the entire validation process is executed on the EFSA side, in order to reduce the possible occurrence of transmission failures, the sender is recommended to implement the entire validation process including the business rules check prior to sending the data transmissions to EFSA. The business rules can generate an error or a warning message. Transmissions containing only warnings are still accepted by the receiver. Transmissions containing at least one error are rejected by the receiver. The SSD document describes a generic set of business rules; in addition specific data collections may implement their own specific validation rules depending on legislative and scientific requirements General business rules The following validations are always performed upon validation of the data file: If the data element is mandatory, the element must be present and the value must be reported; If the value reported is compliant with the type defined in the SSD; If the type requires a controlled terminology, then the code reported must be included in the controlled terminology specified. In addition, the following validations must be performed. In cases where a data element is not mandatory, the rule will only be applied if the optional data element is provided (e.g. the rule for the data element S.05 Area of sampling will be applied only if the element S.05 is provided). In cases where the rule involves a comparison of more optional data elements, the rule will only be applied if all the data elements involved in the comparison are provided or can be built or calculated from the provided data. In both previous cases, if at least one of the optional data elements involved in the comparison is missing, the rule is not verified and no errors or warnings concerning that particular business rule are generated. 17 In this guidance this type of check operations are called business rules in order not to confuse them with the XML validation. In the guidance on Standard Sample Description Error! Bookmark not defined. they were called validation rules. 28

29 Twelve validation rules have been identified as basic validation rules. These rules are generic and work as templates for the possible validation rules that can be applied to the data. These basic validation rules are listed in Table 5. Being generic template validation rules, they can be applied to different variables or with different parameters implementing all the current requirements of validation of the general and detailed validation rules. These variables are indicated in the column Parameter list. In case multiple variable and parameters are necessary for a validation rule, a dollar $ sign is used as separator. Some validation rules require lists of variables and parameters (variablelist and parameterlist). The items of these lists are then separated by a space character. Table 5: Basic business rules. Validation rule code BR01A BR02A Validation rule name Parameter list Applies When variable1 then variablelist is unique Variable1 is mandatory when at least one of variablelist is not null variable1$$$variablelist variable1$variablelist Data collection Result BR03A Variable1 variable1$$ Result BR04A BR05A Variable1 is null if variable2 Variable1 1 when variable2 2 param2 variable1$variable2$$ variable1$1$$variable2$ 2$param2 Result Result BR06A VariableList are constant for variable1 variable1$variablelist Data collection BR07A BR08A Area variable1 contained in country variable2 Variable1 is mandatory if variable2 variable1$variable2 variable1$variable2$$ Result Result BR09A Variable1 between and param2 variable1$$$param2 Result BR10A Partial date variablemonth1/variableyear1 parammonth2/parammonth2 variablemonth1$variableyear1$$v ariablemonth2$variableyear2 Result BR11A VariableDay/variableMonth/ variableyear is a valid date variableday$variablemonth$variableyear Result BR12A Date variableday1/variablemonth1/variable Year1 paramday2/parammonth2/ parammonth2 variableday1$variablemonth1$ variableyear1$$ paramday2$parammonth2$parammonth2 Result Table 5 describes the variables, the s and the parameters applying to the rule: Variable: elements of the Standard Sample Description or implicit values such as the current date (nowd,nowm,nowy) and the identifier of the organisation sending the data (orgid). Variables representing day, month, year are described as variableday, variablemonth, variableyear 29

30 VariableList: list of variables as defined above. The elements of the list are separated by spaces. Parameters: parameters can be variables or numeric constants (1, 2, 3.5, 700) or text constants ( RF-XXX-XXXX ). Most of the business rules validate the correctness of related data element within a single record of transmitted data (e.g. if the result type indicates a result below LOD then the LOD must be reported). Two rules (BR01A and BR06A) validate instead the correctness of an entire data collection (e.g. that a specific parameter measured for a sample has been only transmitted once even across transmissions). The basic validation rules must be associated with the relevant variables or parameters in order to create a validation rule instance and to provide the acknowledgment results. This association is described in Table 9 in Appendix 2. Element: Reference element code to which the validation rule instance is applied. Rule code: Validation rule code as listed in Table 5. Rule Name: Validation rule name as listed in Table 5. Rule: Description of the specific rule obtained with this instance of the basic validation rule Variables: Variables and parameters used to create the instance of the validation rule. The $ sign is used as separator for variable and parameters. When a variablelist of parameterlist is requested, the items of these lists are separated by a space character. Error Type: If this instance of the validation rule is creating an error this field report E Error Code: Code for this instance of the validation rule. Error Description: Additional description for the validation rule instance. Scope: Defines if the scope of the validation rule is applicable to all the data collection ( ) or only to a specific data collection Specific business rules While general validation rules apply to all data collections utilising the standard sample description, specific validation rules apply only to a specific set of parameters defined by the scope variable presented in Appendix 2. The specific validation rules are still instances of the twelve basic validation rules and are defined by each EFSA Data Collection Data Manager in conjunction with relevant stakeholders. 30

31 8. Conclusions and Recommendations 8.1. Conclusions The Technical Working Group on Data Collection have agreed that the Standard Sample Description, defining variables and terminologies, and this Data Exchange Guidance, defining transmission details, are the first steps to harmonising the transmission of sample level data from Member States to EFSA. The guidance documents have been developed specifically to address transmission of chemical occurrence and pesticides data and, to date, have only been piloted in the pesticides domain (2008 and 2009 Annual Data Collection). Feedback from this experience has been incorporated into the documents. The system will evolve as further experience in its use is gained. The Working Group considers it essential to plan for and put in place a process for further maintenance and development of these guidance documents to allow for improving and extending the overall process as it relates to the currently defined data collections (chemical contaminants and pesticides) to EFSA data collections supporting other risk assessment activities, e.g. zoonoses. The group recognises that the ability of each Member State to transmit data to EFSA according to the Standard Data Model and via the automated transmission mechanisms will vary. Therefore the guidance documents are also intended to assist Member States for planning future developments and evolution of local, regional and national systems with the objective of harmonising data transmissions. The working group acknowledges that further development work is required to support the functionalities described by EFSA in the document. Harmonisation of data collections is recognised as a fundamental step in the development of an effective EFSA Data Warehouse. The establishment of the EFSA Data Warehouse is seen as a resource for Europe-wide risk assessment by EFSA and - with appropriate access policies - for Member States Recommendations The Technical Working Group on Data Collection, after examining the details of the data transmission file formats, mechanisms and security considerations, makes the following recommendations which are aimed to harmonising the format and mechanism of transmission of data to EFSA for the Chemical Contaminants and Pesticides Residues domains. Common requirements for these domains are addressed in the guidance. In addition, during the development of this harmonised data exchange guidance, attention has been paid to commonality with the requirements for the collection of Zoonoses data, although domain specific adjustments have not been addressed. The following recommendations are addressed to the European Food Safety Authority as the leading organisation and it is anticipated that the work necessary to achieve these will be undertaken in conjunction with Member States and the Commission. Recommendation 1: XML Schema validation at source Error and warning codes are defined within the guidance to assist data senders in identifying and rectifying data quality issues in advance of transmission. Errors in transmitted data involves unnecessary processing, flagging of replaced data in the EFSA database and iterative communications which should be minimised, especially once data transmissions move from pilot/test into operational modes. 31

32 The Working Group recommends that data senders implement the XML schema validation including business rules at data extraction time within their own system prior to transmission to EFSA. Recommendation 2: Amendments to the XML schemas Pilot use of the SSD XML Schemas for transmission of Pesticides data (2008 and 2009) and the ongoing work of the Article 36 beneficiaries in CFP/EFSA/DATEX/2009/01 were based on an earlier version of the schemas. As this work is ongoing, implementation of the revised schema as defined in this guidance needs to take account of these data collection project requirements. Mechanisms for implementing the changes to the XML schemas (as proposed in this guidance) in existing systems will need to be addressed by EFSA and Member States. In order not to impact the operability of existing systems, the Working Group recommends that EFSA should support the use of both schemas defined in the ongoing projects and the new schema defined in this document until the end of Further, it recommends that all projects commencing after the publication of this document should use the new schema. Recommendation 3: Human readability of acknowledgement messages Error and warning codes are defined within the guidance and will be transmitted to data senders to indicate the status of receipt and processing of their submitted data. For data senders whose systems can import and interpret these codes, this is an efficient and effective mechanism. For those data senders whose system may still be evolving, the Working Group recommends that each EFSA data collection team should consider issuing a style sheet (XSLT) to transform XML message codes describing warnings and errors into human readable format in order to assist the data sender in rectifying the issues identified. Recommendation 4: Amendments to the update procedure The current pattern of data collections at EFSA typically covers a particular dataset for a time period (e.g. pesticides annual data collection) or a particular group of parameters for a defined time period (e.g. biogenic amines over the past 5 years). It is anticipated that these relatively infrequent data collections may become more frequent under new legislative arrangements in the future. Should that be the case, the update (or replace) function may become more critical as partial records in early transmissions need to be replaced with completed records. E.g. where one test result is available at the end of a month and another test result for the same sample becomes available early in the following month. The Working Group recommends that should more frequent transmissions be attempted, revision of the update (or replace) functionality be considered. Recommendation 5: Move terminology validation to the MRN The current guidance specifies that the MRN message (synchronous) will provide the sender with information regarding the validity of the transmitted XML file as compared with the defined schema. This does not include validation of the data provided for each element versus the relevant controlled terminology; that validation occurs with the business rules and is communicated back to the sender in the ACK message asynchronously. The Working Group recommends that validation of the received data against controlled terminologies synchronously for inclusion in the MRN message would be a beneficial development. Further, it states that a future mechanism integrated with the controlled terminology maintenance tool to export the terms in XML would be useful. 32

33 Recommendation 6: Feasibility study of standard internet protocols There was some discussion within the group regarding the potential use of commercially available internet protocols such as AS1 or AS2. These would have the advantage of addressing the nonrepudiation requirement which our recommendations do not address. However, in the interests of simplicity and taking a pragmatic approach, the anticipated benefits did not warrant pursuing these immediately. The Working Group recommends that this possibility be reviewed as availability of appropriate protocols evolves over time. Recommendation 7: Support for Member States in migration to SSD and XML There were some discussions within the group regarding the complexity of exporting the data in XML format. From the experience of the Working Group members, especially those already participating in the pilot transmissions, it was noticed that the major amount of work is the matching of the standard terminologies included in the SSD rather than the actual export of the data in XML format. The Working Group therefore recommends that Member States plan carefully the time needed to solve the data management issues of matching the standard terminologies in the SSD rather than concentrating on the XML export. EFSA should also provide guidance to Member States on how to perform this planning. Recommendation 8: Usage and maintenance of the data exchange guidance Data file formats, transmission mechanisms and security considerations are addressed in this guidance based on current best practice and widespread availability of the technology advocated. Contact points in the different Member States should be established to coordinate feedback on the implementation of the data exchange guidance. The existing networking groups may provide many of the appropriate contacts. As the industry standards for electronic data exchange evolve over time, the Working Group recommends planning for a maintenance process with a review group of experts including EFSA, Member states and network representatives to ensure ongoing harmonisation of this guidance. A first review is recommended to be organised late in 2011 involving appropriate EFSA and Member State stakeholders. Recommendation 9: Usage and maintenance of transmission message codes Transmission message codes for warnings and errors currently identified in the guidance are expected to cover most of the data quality issues. As the use of the SSD and Data Exchange Guidance extends beyond the pilot users, feedback on the implementation is expected to result in refinements and additions to these message codes. The Working Group recommends that, similar to the above process for the data exchange guidance, a review group of experts including EFSA, Member states and network representatives should ensure ongoing harmonisation of these message codes. A first review is recommended to be organised late in 2011 involving appropriate EFSA and Member State stakeholders. Recommendation 10: Specific business rules Since the implementation of business rules involves time and resources on the Member State as well as the EFSA side, the Working Group recommends that data collection specific business rules are kept to a minimum and that related data collection areas should use the same specific business rules list wherever possible. 33

34 Recommendation 11: Consider application of the guidance for local/national workflow Guidance on Data Exchange The data exchange guidance is written to address the need to standardise the transmission of data from Member States to EFSA. In addition, it is anticipated that it might be applicable, with some modification, also to transmission of food safety data, if needed, to the European Commission, Eurostat or other EU organisations. The Working Group recommends adaptation of the system to also assist in strengthening the data flows from local or regional organisations to national reporting organisations, which then collate and transmit national data to EFSA. This function is outside the scope of this Working Group and is only noted here as a potentially useful tool for some Member States to pursue themselves. 34

35 9. References IETF RFC 707. A High-Level Framework for Network-Based Resource Sharing available on line at last accessed on 17/03/2010. IETF RCF Hypertext Transfer Protocol -- HTTP/1.1 available on line last accessed on 17/03/2010. IETF RFC HTTP over TSL available on line last accessed on 14/07/2010. IETF RFC Securing FTP with TLS available on line at based on FTP (RFC 959) and TSL (RFC 2246) last accessed on 17/03/2010. Regulation (EC) No 178/2002 of the European Parliament and of the Council of 28 January 2002 laying down the general principles and requirements of food law, establishing the European Food Safety Authority and laying down procedures in matters of food safety. OJ L 31, , p Standard Sample Description for Food and Feed, EFSA Journal 2010; 8(1):1457 available on line at World Wide Web Consortium - Extensible Markup Language (XML) 1.0 (fifth edition) available on line at last accessed on 14/07/2010. World Wide Web Consortium - SOAP Version 1.2 Part 1: messaging Framework (Second edition) available on line at last accessed on 17/03/

36 APPENDICES APPENDIX 1 DESCRIPTION OF THE MRN AND ACK AS CURRENTLY IMPLEMENTED IN EFSA This appendix includes the specifications for the former version of the MRN and Acknowledgment messages currently supported by the EFSA system for XML messaging. A1.1 MRN message The MRN message structure is made up of two elements containing data fields: The Message Header: contains information to allow the communication protocol to deliver the MRN message to the sender. The Message Receipt Notification: contains the information if the message has been accepted for processing by the receiver and whether the file is valid according to the XSD. Even if the message transmission receives a positive MRN, the actual acknowledgment message could be negative. The MRN does contain the actual result of the validation of the content of the XML message (presence and validity of the minimum set of mandatory data, XML well-formed check, and validation of XML against the XSD). Particularly the MRN has the role to communicate to the sender, eventual XML parsing errors present in the XML transmission. The result of the business validation (at present foreign key validation, result of insert in the database) will be included in the Acknowledgement message. The Figure 10 - MRN message structure reports the structure of the MRN message, which is then further detailed in Table 6 Message MRN elements, where all elements included in the MRN message are listed. Figure 10: MRN message structure. 36

37 Table 6: Message MRN elements. Element Name Type Description Header element Message Receipt Notification (MRN) message header The message header has the same elements as in the XML message. mrnbody element Content of the MRN message sendermessagecode xs:string (100) This field contains the value of sendertrxcode in the data message. receivermessagecode xs:string (100) This field contains the transmission ID as assigned by the receiver system. This code should be returned in the receivertrxcode element of the data message for deletion procedures. messagereceivedate xs:datetime This field specifies when the message has been received by the receiver's system. mrndate xs:datetime This field specifies when the MRN message has been created by the receiver's system. mrncode xs:string Values: This field contains the acknowledgment code. "01" means transmission accepted. "02" means transmission not accepted because of parsing errors in the message, or for errors at security level. parsingerror xs:string (4000) This will contain the results of the validation of the transmission file against the XML schema. The error produced by the parser on sender's side is included here. A1.2 Acknowledgement message The message structure is embodying three elements containing data fields: The message header - Contains information to allow the communication protocol to deliver the acknowledgment message to the sender. The transmission acknowledgment - Contains information on the result of the entire message processing. If the transmission acknowledgment code contains the value: 01 : the message was loaded by the receiver system without errors and warnings. No further action is required by the sender of the message. 02 : the message was not loaded by the receiver system because of errors in the message. The sender has to correct the message, delete the previous transmission, and send the corrected data using the insert operation. The dataset acknowledgment - This entry contains the result of the operation on the dataset. This entry contains the transmission ID which allows the sender to find the transmitted dataset in the receiver s database. It is paramount that the sender keeps track of the transmission ID held in the receivermessagecode. The sender will have to use the transmission ID for any further operation of replacement or deletion of the dataset. The sample acknowledgment - This entry contains the result of the business validation of the data contained in the dataset element in the form of error codes and error descriptions. The data fields in this entry provide the sender with the necessary information required to prepare 37

38 a new data submission with the identified errors corrected. If no errors or warning have been detected by the receiver s system, then the entity sample acknowledgment (sampleack) will be empty with the exception of samplecode (errortype, errorcode, and errordescription are empty). The Figure 11 Acknowledgement diagram reports the structure of the acknowledgment message, which is then further detailed in Table 7 - Acknowledgment elements, where all elements included in the acknowledgement are listed. Figure 11: Acknowledgment diagram. 38

39 Table 7: Acknowledgment elements. Element Name Type Description Ack Element Acknowledgment element Header Element Message Acknowledgement (ACK) header The message header has the same elements as in the XML message. ackbody Element Message Acknowledgement Body messageack Element This entity contains information mainly on the validation of the message structure. The system checks that the message is a well formed XML message. sendermessagecode xs:string (100) This field contains the message code as defined in the sender's message. [DEPRECATED] receivermessagecode xs:string (100) This field contains the message code as assigned by the receiver system. [DEPRECATED] messagereceivedate xs:datetime This field specifies when the message has been received by the receiver's system. messageackdate xs:datetime This field specifies when the acknowledgment message has been created by the receiver's system. trxackcode xs:string Values: This field contains the acknowledgment code. "01" means transmission successful. "02" means transmission not successful because of error in the message. trxack Entity This entity describes the acknowledgement results for the transmission. sendertrxcode xs:string (100) This field reports the data transmission code as reported in the sender's message. receivertrxcode xs:string (100) This field reports the transmission ID for the receiver's system. This code must be preserved by the sender because it is needed for delete operations. dccode xs:string (20) This field contains the code of the data collection which is involved in the data transmission. dcname xs:string (50) This field contains the name of the data collection involved in the data transmission. sampleack Entity This entity groups the elements reporting the acknowledgment information for a specific sample. samplecode xs:string (20) Code sufficient to identify the record containing the analytical result in which the error was detected. Variable xs:string (100) The element name/s from sample which failed validation errortype xs:string (2) The type of information the acknowledgment is returning. "E" Error, "W" Warning, I information. errorcode xs:string (10) This field contains the error code generated by the receiver system. errordescription xs:string (500) This field contains the text description of the error, warning generated by the receiver's system. 39

40 A1.3 Transaction Identifier Synchronisation Table 8 shows how the transaction identifier is provided by the sender and the receiver of the message and where it is stored in the different messages, so that the protocol can be performed correctly. Table 8: Transaction identifier. Code Transmission ID Description Code to identify the file transmission in the receiver system. Local Code The sender organisations code to identify the file transmission. Organisation Code Data Collection Code Code to identify the sender organisation set by EFSA. Code to define the data collection the file transmission relates to (set by EFSA). Element in Data message Element in MRN message Element in Acknowledgement message receivertrxcode * receivermessagecode receivermessagecode **, receivertrxcode sendertrxcode sendermessagecode sendermessagecode **, sendertrxcode sendercode sendercode sendercode dccode - dccode * * This element is only filled in Data messages for a delete operation, for insert operations this value will not have been set. The ivertrxcode (for delete procnenord containing the analytical result in which the error was detected currently available when * ** These fields are deprecated. N.B.: sender identifies the initiator of the transmission (i.e. the Member States) whilst receiver indicates the receiver of the first message (i.e. EFSA). These two terms will always refer to the same entities through all of the information flow. 40

41 APPENDIX 2 DESCRIPTION OF THE BUSINESS RULES APPLIED TO THE ELEMENTS OF THE STANDARD SAMPLE DESCRIPTION Table 9 presents how the basic business rules are applied to the elements of the Standard Sample Description. It describes in more formal terms the business rules anticipated in the Standard Sample Description Error! Bookmark not defined.. Table 9: General validation rules. Element rulecode rulename Rule Variables errortype errorcode errordescription Scope S.01 BR06A VariableList are constant for variable1 S.05 BR07A Area variable1 contained in country variable2 S.07 BR07A Area variable1 contained in country variable2 S.11 BR07A Area variable1 contained in For s.03-s.39: all values in each data elements must be equal for all records with same labsampcode The area of sampling reported must be included in the country reported in Country of sampling The area of origin reported must be included in the country reported in Country of origin of the product The Area of processing reported labsampcode$lang sampcountry samparea origcountry origarea origfishareacode origfishareatext proccountry procarea EFSAProdCode prodcode prodtext prodprodmeth prodpack prodtreat prodbrandname prodmanuf prodingred prodcom prody prodm prodd expiryy expirym expiryd sampy sampm sampd progcode proglegalref progsampstrategy progtype sampmethod samplenum lotsize E ES01A Sample descriptors are not identical for all records with the same labsamplecode lotsizeunit samppoint samparea$sampcountry E ES05A The sampling area must be within the sampling Country origarea$sampcountry E ES07A The area of origin must be within the country of origin procarea$proccountry E ES11A The processing area must be within the processing country 41

42 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope country variable2 S.14 BR08A Variable1 is mandatory if variable2 S.22 BR03A Variable1 S.22 BR03A Variable1 S.22 BR03A Variable1 S.22 BR03A Variable1 S.23 BR09A Variable1 between and param2 S.23 BR02A Variable1 is mandatory when at least one of variablelist is not null S.23 BR10A Partial date variablemont h1/variableye ar1 parammonth2 /parammonth must be included in the country reported in Country of processing If Product code is equal to XXXXXXA (not in list) then prodtext must be provided Year of production has to be less or equal to the current year Year of production must be less than or equal to the Year of expiry Year of production must be less than or equal to Year of sampling Year of production must be less than or equal to Year of analysis Month of production has to be between 1 and 12 Month of Production has to be filled in if Day of production is filled in The partial date prodm/prody must be less or equal to the current partial date M/Y. prodtext$prodcode$=$"xxxx XXA" E ES14A Product text should be completed if code is XXXXXXA prody$<=$nowy E ES22A Production year cannot be greater than the current year prody$<=$expiryy E ES22B Production year cannot be greater than expiry year prody$<=$sampy E ES22C Production year cannot be greater than the year of sampling prody$<=$analysisy E ES22D Production year cannot be greater than the year of analysis prodm$1$12 E ES23A Production month must be between 1 and 12 prodm$prodd E ES23B Production month must be completed if production day is completed prodm$prody$<=$nowm$nowy E ES23C The combination of production month and production year must be less than the current month and year 42

43 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope 2 S.23 BR10A Partial date variablemont h1/variableye ar1 parammonth2 /parammonth 2 S.23 BR10A Partial date variablemont h1/variableye ar1 parammonth2 /parammonth 2 S.23 BR10A Partial date variablemont h1/variableye ar1 parammonth2 /parammonth 2 S.24 BR09A Variable1 between and param2 S.24 BR11A variableday/v ariablemonth/ variableyear is a valid date S.24 BR12A Date variableday1/ variablemont h1/variableye ar1 paramday2/pa rammonth2/p arammonth2 S.24 BR12A Date variableday1/ The partial date prodm/prody must be less or equal to expirym/expiryy. The partial date prodm/prody must be less or equal to sampm/sampy. The partial date prodm/prody must be less than or equal to analysism/analysisy Day of production has to be between 1 and 31 The prodd/prodm/prody must be a valid date date The date prodd/prodm/prody must be less or equal to the current date D/M/Y. The date prodd/prodm/prody prodm$prody$<=$expirym$expi ryy E ES23D The combination of production month and production year must be less than the expiry month and year prodm$prody$<=$samp$sampy E ES23E The combination of production month and production year must be less that the sample month and year prodm$prody$<=$analysism$an alysisy E ES23F The combination of production month and production year must be less than the analysis month and year prodd$1$31 E ES24A Production day must be between 1 and 31 prodd$prodm$prody E ES24B The combination of production day, month and year must be a valid date prodd$prodm$prody$<=$nowd $nowm$nowy prodd$prodm$prody$<=$expiry D$expiryM$expiryY E ES24C The combination of production day, month and year must be less than the current date E ES24D The combination of production day, month and year must be less than the 43

44 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope variablemont h1/variableye ar1 paramday2/pa rammonth2/p arammonth2 S.24 BR12A Date variableday1/ variablemont h1/variableye ar1 paramday2/pa rammonth2/p arammonth2 S.24 BR12A Date variableday1/ variablemont h1/variableye ar1 paramday2/pa rammonth2/p arammonth2 S.26 BR09A Variable1 between and param2 S.26 BR02A Variable1 is mandatory when at least one of variablelist is not null S.27 BR09A Variable1 between and param2 S.27 BR11A variableday/v ariablemonth/ variableyear is a valid date must be less then expiryd/expirym/expi ryy. The date prodd/prodm/prody must be less then sampd/sampm/samp Y. The date prodd/prodm/prody must be less then analysisd/analysism/a nalysisy Month of expiry has to be between 1 and 12 Month of expiry has to be filled in if Day of expiry is filled in Day of expiry has to be between 1 and 31 The date prodd/prodm/prody must be a valid date prodd$prodm$prody$<=$samp D$sampM$sampY prodd$prodm$prody$<=$analys isd$analysism$analysisy expiry date E ES24E The combination of production day, month and year must be less than the sample date E ES24F The combination of production day, month and year must be less than the analysis date expirym$1$12 E ES26A Expiry month must be between 1 and 12 expirym$expiryd E ES26B Expiry month must be completed if expiry day is completed expiryd$1$31 E ES27A Expiry day must be between 1 and 31 expiryd$expirym$expiryy E ES27B The combination of expiry day, month and year must be a valid date 44

45 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope S.28 BR03A Variable1 S.28 BR03A Variable1 S.29 BR09A Variable1 between and param2 S.29 BR02A Variable1 is mandatory when at least one of variablelist is not null S.29 BR10A Partial date variablemont h1/variableye ar1 parammonth2 /parammonth 2 S.29 BR10A Partial date variablemont h1/variableye ar1 parammonth2 /parammonth 2 S.30 BR09A Variable1 between and param2 S.30 BR11A variableday/v ariablemonth/ variableyear is a valid date Year of sampling must be less or equal to the current year year of sampling must be less than or equal to year of analysis Month of sampling has to be between 1 and 12 Month of sampling has to be filled in if Day of sampling is filled in The partial date sampm/sampy must be less or equal to the current partial date M/Y The partial date sampm/sampy must be less or equal to the partial date analysism/analysisy Day of sampling has to be between 1 and 31 The date sampd/sampm/samp Y must be a valid date sampy$<=$nowy E ES28A Sample year cannot be greater than the current year sampy$<=$analysisy E ES28B Sample year cannot be greater than the analysis year sampm$1$31 E ES29A Sample month must be between 1 and 12 sampm$sampd E ES29B Sample month must be completed if sample day is completed sampm$sampy$<=$nowm$now Y sampm$sampy$<=$analysism$a nalysisy E ES29C The combination of sample month and sample year must be less than the current month and year E ES29D The combination of sample month and sample year must be less than the analysis month and year sampd$1$31 E ES30A Sample day must be between 1 and 31 sampd$sampm$sampy E ES30B The combination of sample day, month and year must be a valid date S.30 BR12A Date The date sampd$sampm$sampy$<=$now E ES30C The combination of sample day, 45

46 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope variableday1/ variablemont h1/variableye ar1 paramday2/pa rammonth2/p arammonth2 S.30 BR12A Date variableday1/ variablemont h1/variableye ar1 paramday2/pa rammonth2/p arammonth2 S.38 BR02A Variable1 is mandatory when at least one of variablelist is not null R.02 BR03A Variable1 R.03 BR09A Variable1 between and param2 R.03 BR02A Variable1 is mandatory when at least one of variablelist is not null R.03 BR10A Partial date variablemont h1/variableye ar1 parammonth2 sampd/sampm/samp Y must be less or equal to the current date D/M/Y The date sampd/sampm/samp Y must be less or equal to the date analysisd/analysism/a nalysisy If the lot size is provided the lot size unit must be provided Year of analysis has to be less than or equal to the current year Month of analysis has to be between 1 and 12 Month of analysis has to be filled in if Day of analysis is filled in The partial date analysism/analysisy must be less or equal to the current partial date M/Y D$nowM$nowY sampd$sampm$sampy$<=$anal ysisd$analysism$analysisy month and year must be less than the current date E ES30D The combination of sample day, month and year must be less than the analysis date lotsizeunit$lotsize E ES38A Lot size unit must be reported when lot size is reported analysisy$<=$nowy E ER02A Analysis year cannot be greater than the current year analysism$1$12 E ER03A Analysis month must be between 1 and 12 analysism$analysisd E ER03B Analysis month must be completed if analysis day is completed analysism$analysisy$<=$nowm $nowy E ER03C The combination of analysis month and analysis year must not be greater than the current month and year 46

47 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope /parammonth 2 R.04 BR09A Variable1 between and param2 R.04 BR11A variableday/v ariablemonth/ variableyear is a valid date R.04 BR12A Date variableday1/ variablemont h1/variableye ar1 paramday2/pa rammonth2/p arammonth2 R.06 BR01A When variable1 then variablelist is unique R.07 BR08A Variable1 is mandatory if variable2 R.11 BR08A Variable1 is mandatory if variable2 R.13 BR08A Variable1 is mandatory if variable2 Day of analysis has to be between 1 and 31 The date analysisd/analysism/a nalysisy must be a valid date The date analysisd/analysism/a nalysisy must be less or equal to the current date D/M/Y analysisd$1$31 E ER04A Analysis day must be between 1 and 31 analysisd$analysism$analysisy E ER04B The combination of analysis day, month and year must be a valid date analysisd$analysism$analysisy$ <=$nowd$nowm$nowy Where paramcode <> "RF-XXXX-XXX- XXX" (Not in list) then (paramcode, labsampcode, labsubsampcode) must be unique for a data sender ; Where paramcode = "RF-XXXX-XXX- XXX" (Not in list) then paramtext must be provided If anmethcode is F001A (Classification not possible) then anmethtext must be provided If Type of result is different from BIN then Result unit paramcode$^=$"rf-xxxx- XXX-XXX"$labSampCode paramcode orgid paramtext$paramcode$=$"rf- XXXX-XXX-XXX" anmethtext$anmethcode$=$"f0 01A" E ER04C The combination of analysis day, month and year must not be greater than the current date E ER06A When parameter text equals Not in list then each recordcode should be unique for that sample code E ER07A Parameter text should be completed if code is RF-XXXX-XXX-XXX E ER11A Analytical method text should be completed if method code is F001A resunit$restype$=$"bin" E ER13A For results other then qualitative values the result unit must be reported 47

48 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope R.13 BR02A Variable1 is mandatory when at least one of variablelist is not null R.14 BR08A Variable1 is mandatory if variable2 R.14 BR03A Variable1 R.14 BR03A Variable1 R.15 BR08A Variable1 is mandatory if variable2 R.15 BR03A Variable1 R.16 BR08A Variable1 is mandatory if variable2 R.16 BR03A Variable1 R.16 BR03A Variable1 must be specified If at least one of reslod, resloq, CCalpha, CCbeta, resval, resvaluncertsd, resvaluncert, reslegallimit is provided then resunit must be provided. Result LOD has to be filled in if Type of result is equal to LOD. Result LOD must be greater than 0 Result LOD must be lower than or equal to Result LOQ Result LOQ has to be filled in if Type of result is equal to LOQ. Result LOQ must be greater than 0 CC alpha has to be filled in if Type of result is equal to CCA. CC alpha must be greater than 0 CC alpha must be lower than CC beta resunit$reslod resloq CCalpha CCbeta resval resvaluncertsd resvaluncert reslegallimit E ER13B If a numeric field is reported the unit should be reported reslod$restype$=$"lod" E ER14A The result LOD must be completed if the result type is LOD reslod$>$0 W WR14A If the LOD is reported it should be greater than 0 reslod$<=$resloq E ER14B The result LOD must be less than the LOQ resloq$restype$=$"loq" E ER15A The result LOQ must be completed if the result type is LOQ resloq$>$0 W WR15A If the LOQ is reported it should be greater than 0 CCalpha$resType$=$"CCA" E ER16A The result CC alpha must be completed if the result type is CCA CCalpha$>$0 W WR16A If the CC alpha is reported it should be greater than 0 CCalpha$<=$CCbeta E ER16B The result CC alpha must be less then CC beta 48

49 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope R.17 BR08A Variable1 is mandatory if variable2 R.17 BR03A Variable1 R.18 BR08A Variable1 is mandatory if variable2 R.18 BR03A Variable1 R.18 BR04A Variable1 is null if variable2 R.19 BR03A Variable1 R.21 BR03A Variable1 R.22 BR03A Variable1 R.23 BR09A Variable1 between and param2 CC beta has to be filled in if Type of result is equal to CCB. CC beta must be greater than 0 ResVal must be filled in if ResType is equal to VAL. ResVal must be greater than 0 ResVal has to be missing when restype is LOD. resvalrec must be greater than 0 resvaluncertsd must be greater than 0 resvaluncert must be greater than 0 MoistPerc has to be between 0 and 100. CCbeta$resType$=$"CCB" E ER17A The result CC beta must be completed if the result type is CCB CCbeta$>$0 W WR17A If the CC beta is reported it should be greater than 0 resval$restype$=$"val" E ER18A The result value must be completed if the result type is VAL resval$>$0 W WR18A If the result value is reported it should be greater than 0 resval$restype$=$"lod" W 18 ER18B If the result type is LOD the result value should not be completed resvalrec$>$0 W WR19A If result value recovery is reported it should be greater than 0 resvaluncertsd$>$0 W WR21A If result value uncertainty standard deviation is reported it should be greater than 0 resvaluncert$>$0 W WR22A If result value uncertainty is reported it should be greater than 0 moistperc$0$100 E ER23A The percentage moisture should be between 0 and In the guidance on standard sample description this business rule is flagged as error, but since comments where received on the possibility to have the value measured below LOD it was decided to report this check as warning. 49

50 Element rulecode rulename Rule Variables errortype errorcode errordescription Scope R.23 BR08A Variable1 is mandatory if variable2 R.24 BR09A Variable1 between and param2 R.24 BR08A Variable1 is mandatory if variable2 R.26 BR08A Variable1 is mandatory if variable2 R.29 BR02A Variable1 is mandatory when at least one of variablelist is not null R.30 BR05A Variable1 1 when variable2 2 param2 R.31 BR08A Variable1 is mandatory if variable2 MoistPerc must be provided if Expression of result is B002 dry weight FatPerc has to be between 0 and 100. FatPerc must be provided if Expression of result is B003 fat weight ResQualValue has to be filled in if ResType= BIN. If reslegallimit is provided then the reslegallimittype must be provided Where resval greater then reslegallimit then resevaluation must be different from J002A ( maximum permissible quantities (Compliant result)) Where resevaluation = J003A (> maximum permissible quantities (Non compliant result)) then acttakencode should be provided moistperc$exprres$=$"b002" E ER23B For dry weight results the percentage moisture must be reported fatperc$0$100 E ER24A The percentage fat should be between 0 and 100 fatperc$exprres$=$"b003" E ER24B For fat weight results the percentage fat must be reported resqualvalue$restype$=$"bin" E ER26A The result qualitative value (pos or neg) must be completed if the result type is BIN ResLegalLimitType$resLegalLim it resevaluation$>$resval$resevalu ation$^=$"j002a" acttakencode$resevaluation$=$" J003A" W WR29A The type of legal limit must be indicated in the legal limit type E ER30A Result Evaluation is incorrect Result value exceeds Result Legal Limit W WR31A For non compliant results the action taken code should be completed 50