oEPA
United States
Environmental Protection
Agency
Requirements for Environmental
Response Laboratory Network (ERLN)
Data Submissions 1
Version 1.5
1 The content of this document is subject to change based on decisions by EPA.
Office of Solid Waste and Emergency Response October 2011
www.epa.gov/erln
-------
-------
Requirements for ERLN Data Submissions
Table of Contents
TABLE OF CONTENTS I
LIST OF TABLES Ill
LIST OF FIGURES Ill
LIST OF ACRONYMS VI
SECTION 1.0: INTRODUCTION 1
1.1 Purpose 1
1.2 Scope 1
1.3 Intended Audience 1
1.4 References 1
1.4.1 Internal References 1
1.4.2 External References 2
SECTION 2.0: BACKGROUND 4
2.1 Goal 4
2.2 Responsibility 4
2.3 ERLN Laboratory Access Process 4
2.3.1 Measurement Quality Objectives (MQOs) 5
2.4 Creating a Model for Communication 5
2.4.1 Defining Data Requirements 6
SECTION 3.0: OVERVIEW OF REPORTING REQUIREMENTS 10
3.1 Requirements 10
3.2 High-Level Data Submission Requirements 10
3.2.1 Data Reporting Group Notification 11
3.2.2 Electronic 11
3.2.3 Data Reporting 12
3.3 Submission Types 12
3.4 ERLN Data Organization (Applicable to Type Two and Three Submissions) 13
SECTION 4.0: TYPE ONE DATA SUBMISSION 16
4.1 Type 1 Electronic Submission Requirements 16
4.1.1 Data Requirements 16
4.2 Type 1 Transitional (Type It) Electronic Submission Requirements 19
4.2.1 Data Requirements 19
4.3 Electronic Delivery Requirements 22
4.4 Data Reporting Requirements 22
4.4.2 Data Reporting Delivery Requirements 23
SECTION 5.0: TYPE ONE FACT SHEET 24
SECTION 6.0: TYPE TWO DATA SUBMISSION 26
6.1 Type 2 Electronic Submission Requirements 26
6.1.1 Data Requirements 26
6.1.2 Optional Data Requirements 27
6.2 Electronic Delivery Requirements 27
6.3 Data Reporting Requirements 27
6.3.2 Data Reporting Delivery Requirements 28
SECTION 7.0: TYPE TWO FACT SHEET 30
SECTION 8.0: TYPE THREE DATA SUBMISSION 32
8.1 Type Three Electronic Submission Requirements 32
8.1.1 Data Requirements 32
8.2 Optional Data Requirements 32
8.3 Electronic Delivery Requirements 33
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
-------
Requirements for ERLN Data Submissions
8.4 Data Reporting Requirements 33
8.4.2 Data Reporting Delivery Requirements 34
SECTION 9.0: TYPE THREE FACT SHEET 36
SECTION 10.0: CUSTOMER DELIVERY REQUIREMENTS 38
APPENDIX A: GLOSSARY 40
APPENDIX B: ERLN DATA EXCHANGE TEMPLATE (DET) 42
B. 1 High-Level Concepts 42
B. 1.1 Representative Groups 42
B.1.2 Relational Groups 43
B.2 Overview of Data Groups 43
B. 3 Data Element Reporting 44
B. 3.1 Data Element Value Formats 44
B.4 ERLN DET 44
B. 4.1 Example Measurements 52
B. 4.2 Example Characteristics 54
B. 4.4 DET Data Element Definitions 55
B.4.5 DET Valid Values 70
APPENDIX C: ERLN XML REPORTING GUIDE 72
C. 1 Characteristics of an Electronic Submission 72
C. 1.1 Organization of Electronic Submission 72
C. 1.2 XML Syntax Guidelines 73
C.1.3 Document Type Definition (DTD) 75
C.2 ERLN DTD OVERVIEW 75
C. 2.2 ERLN Data Hierarchy for Reporting 75
C.3 ERLN DTD REQUIRED Data ELEMENTS 76
C.4 XML Tools 77
APPENDIX D: USING THE SEDD TO REPORT ERLN DATA 78
D. 1 How Does SEDD Work? 78
D.2 What is the Basic SEDD Hierarchy? 79
D.3 Using SEDD for ERLN Reporting 79
D.3.1 Differences between SEDD and ERLN DET 79
D.4 ERLN DET SEDD Mapping 79
D. 4.1 SEDD Measure Mapping 86
APPENDIX E: ERLN DOMAIN MODEL OVERVIEW 90
E.l What is a Domain Model? 90
E.2 What Are Domain Models Used for? 90
E. 3 Basic Components of a Domain Model 90
E.3.1 Objects 90
E. 3.2 Data Elements 91
E. 3.3 Data Groups 91
E.3.4 Relationships and Cardinality 92
E.3.5 Incorporating EPA Standards 93
E.4 Web-based Electronic Data Review (WebEDR) Domain Model Concepts 93
E. 4.1 High-Level Relationships 93
E. 4.2 Parent-Child Relationships 98
E. 4.3 Disambiguation 104
E.5 ERLN Domain Model 105
APPENDIX F: ERLN TYPE 2 DOCUMENT TYPE DEFINITION (DTD) 106
APPENDIX G: ERLN TYPE 3 DOCUMENT TYPE DEFINITION (DTD) 110
APPENDIX H: ERLN PROPOSED DOMAIN MODEL 118
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy ii
-------
Requirements for ERLN Data Submissions
List of Tables
Table 1. Responsibility 4
Table 2. Summary of Submission Types 12
Table 3. Type 1 Data Requirements 17
Table 4. Type It Additional Data Requirements 20
Table 5. Type One Fact Sheet 24
Table 6. Type Two Fact Sheet 30
Table 7. Type Three Fact Sheet 36
Table 8. ERLN Data Group Definitions 43
Table 9. ERLN Data Exchange Template 45
Table 10. Examples of Measurements Possible with the MeasureDetails Data Group 52
Table 11. ERLN DET Data Element Definitions 56
Table 12 DET Valid Values 70
Table 13 DTD Required Data Groups 77
Table 14 DTD Conditionally Required 77
Table 15. ERLN DET - SEDD Mapping 80
Table 16. SEDD Measure Mapping 87
Table 17. Applied EPA Data Standards 93
List of Figures
Figure 3-1. ERLN DET Type 2 Data Group Organization 13
Figure 3-2. ERLN DET Type 3 Data Group Organization 14
Figure E-l. Domain Model Object 91
Figure E-2. Domain Model Data Group (within Parent Object) 92
Figure E-3. Domain Model Data Group (outside of Parent Object) 92
Figure E-4. One-to-one Object Relationship in Domain Model 94
Figure E-5. Commutative XML Hierarchy 95
Figure E-6. One-to-One Object Relationship in XML 95
Figure E-7. True One-to-Many Object Relationship in Domain Model 96
Figure E-8. True One-to-Many Object Relationship in XML 96
Figure E-9. Scoped One-to-Many Object Relationship in Domain Model 97
Figure E-10. Scoped One-to-Many Object Relationship in XML 98
Figure E-l 1. One-to-One Parent-Child Relationships in Domain Model 99
Figure E-12. One-to-One Parent-child Relationships in XML 99
Figure E-13. One-to-one Parent-child Relationship (Data Group) Relationally in Domain Model 100
Figure E-14. One-to-One Parent-Child Relationships (Data Groups) Relationally in XML 101
Figure E-15. One-to-One Parent-Child Relationships (Data Groups) Hierarchically in XML 101
Figure E-16. One-to-Many Parent-Child Relationship in Domain Model 102
Figure E-17. One-to-Many Parent-Child Relationship in XML 102
Figure E-18. Relationship Groups in Domain Model 103
Figure E-19. Equivalent to Relationship Group Notation Depicted in Figure E-18 104
Figure H-l. ERLN Proposed Domain Model 118
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy iii
-------
Requirements for ERLN Data Submissions
List of Exhibits
Exhibit 1 Generic Analytical Sequence 7
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy iv
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
-------
Requirements for ERLN Data Submissions
List of Acronyms
ASR
Analytical Service Request
CAS
Chemical Abstracts Service
CCB
Continuing Calibration Blank
CCV
Continuing Calibration Verification
CCVA
Continuing Calibration Verification Opening
CCVB
Continuing Calibration Verification Closing
CERCLIS
Comprehensive Environmental Response, Compensation, and Liability Information System
CRI
CRQL Check Standard
CRQL
Contract Required Quantitation Limit
CSV
Comma Separated Value
CWA
Chemical Warfare Agent
DET
Data Exchange Template
DRC
Design Rules and Conventions
DTD
Document Type Definition
EDD
Electronic Data Deliverable
ENLC
Environmental Network Leadership Council
EPA
U.S. Environmental Protection Agency
ERLN
Environmental Response Laboratory Network
ERT
Electronic Reporting Tool
ESAR
Environmental Sampling, Analysis, and Results
HPLC
High Performance Liquid Chromatography
HTML
HyperText Markup Language
ICB
Initial Calibration Blank
ICP
Inductively Coupled Plasma
ICS A
Interference Check Sample A
ICSAB
Interference Check Sample AB
ICV
Initial Calibration Verification
IMWG
Information Management Workgroup
LCS
Laboratory Control Sample
LIMS
Laboratory Information Management Systems
MQO
Measurement Quality Objective
MS
Matrix Spike
MSA
Method of Standard Addition
MSD
Matrix Spike Duplicate
NFG
National Functional Guidelines
PB
Preparation Blank
PDF
Portable Document File
PEM
Performance Evaluation Mixture
QC
Quality Control
SEDD
Staged Electronic Data Deliverable
SOW
Statement of Work
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
vi
-------
Requirements for ERLN Data Submissions
TIC Toxic Industrial Chemicals
W3C World Wide Web Consortium
WebEDR Web-based Electronic Data Review
XML Extensible Markup Language
XSD XML Schema Definition
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy vii
-------
Requirements for ERLN Data Submissions
Section 1.0: Introduction
1.1 Purpose
This document serves as a detailed reporting requirements specification for the Environmental Response
Laboratory Network (ERLN), including the Water Laboratory Alliance Laboratories. ERLN analyses are
requested by U.S. Environmental Protection Agency (EPA) data users in accordance with the
Environmental Response Laboratory Network (ERLN,) Laboratory Requirements Document and the
technical specification included in each project Analytical Service Request (ASR). Clearly defined data
reporting requirements are essential to the ERLN mission of providing consistent analytical data of
known and documented quality. The laboratory shall adhere to the requirements specified in this
document and the project specifications issued with each individual ASR for receiving, tracking, storing,
preparing, analyzing, and reporting data for environmental samples contaminated by toxic industrial
chemicals, chemical warfare agents (CWAs), biological agents, and/or radiochemical agents
1.2 Scope
This document provides detailed information and direction on how to properly report ERLN data. This
document is governed by the requirements outlined in the Environmental Response Laboratory Network
(ERLN) Laboratory Requirements Document and only expands when necessary. Users of this document
should obtain the full scope of requirements from the Environmental Response Laboratory Network
(ERLN) Laboratory Requirements Document.
1.3 Intended Audience
The audience intended for this document is all ERLN laboratories and ERLN data users.
1.4 References
Various references were used when creating this document. Except where noted, this document conforms
to requirements outlined in the documents listed below.
1.4.1 Internal References
The following ERLN documents are available as reference material:
• Environmental Response Laboratory Network (ERLN) Laboratory Requirements Document
• Environmental Protection Agency (EPA) Guidance for Accessing the Environmental Response
Laboratory Network (ERLN) Laboratories
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy 1
-------
Requirements for ERLN Data Submissions
1.4.2 External References
The following external reference material and links are applicable:
• EPA Information Policy CIO 2150.0 - Agency Network Security Policy at
http://www.epa.gov/irmpoli8/ciopolicv/2150-Q.pdf
• SEDD Specification 5.2 for the Staged Electronic Data Deliverable (SEDD)
• Guidance for Labeling Externally Validated Laboratory Analytical Data for Superfund Use, (July
2008)
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy 2
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
-------
Requirements for ERLN Data Submissions
Section 2.0: Background
2.1 Goal
The ERLN's reporting requirements support an EPA data user's analytical data needs by providing the
necessary amount and type of data to support decisions made in response to an event. The need for
detailed requirements regarding the scope of data is essential for EPA data users to ensure the method of
communicating the primary focus of an event is defined in a reproducible format. Reporting requirements
define how data are communicated between the laboratory and the EPA data user. By defining this
communication in a format that is reproducible and organized based on the overall laboratory process,
EPA data users can use automated tools to review and analyze the information provided. ERLN data
reporting business processes, specifications, and formats are designed to support the various ERLN
project's data needs by enabling laboratories to provide data submissions with rapid turnarounds, while
having sufficient data to support decisions made for each project. The ERLN reporting functions bring
new technologies to data generators and consumers alike. The ability of this new functionality to be
interoperable and to integrate with other electronic deliverables is particularly important. Examples
include tools that enable Web access and data exports from modern Laboratory Information Management
Systems (LIMS) where the ELRN can be integrated with Staged Electronic Data Deliverables (SEDD).
2.2 Responsibility
EPA data users rely on the specific analytical capabilities of a laboratory to support their wide variety of
data needs, which includes how a laboratory is capable of reporting data. The data provided for the ERLN
must be in a format that can be shared and used by other networks. To provide data that can be shared and
communicated electronically, laboratories must be capable of reporting data in a defined format.
Table 1. Responsibility
Role
Responsibility
EPA data user
Initiates a project, defines scope and reporting needs.
ERLN Laboratory
Performs analysis of samples and reports data according to project specifications.
2.3 ERLN Laboratory Access Process
The ERLN is a network of public and commercial environmental laboratories that have the capability to
analyze samples for chemical, biological, toxins, and radiochemical agents in environmental matrices.
The ERLN supports the analytical service needs of the U.S. EPA for emergency response,
removal/disposal actions, catastrophic events, or other appropriate projects including long-term low level
concentration cleanups. Membership in the ERLN is determined by EPA, and is based on qualifications
for the types of analyses performed by the laboratory. Laboratories must maintain the required
qualifications and adhere to the requirements in order to be a part of the ERLN.
Once a laboratory becomes an accredidated ERLN laboratory, it is eligible to receive project specific
orders for analytical services from EPA data users. The laboratory receives project information including
the methods and measurement quality objectives for the project. If the laboratory is selected for the
project, it is informed of the sample delivery schedule and prepares to analyze the samples according to
project specifications outlined in their ASR. The complete access process is detailed in the Environmental
Protection Agency (EPA) Guidance for Accessing Environmental Response Laboratory Network (ERLN)
Laboratories document.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
4
-------
Requirements for ERLN Data Submissions
2.3.1 Measurement Quality Objectives (MQOs)
USEPA Order CIO 2150.0 (formerly 5360.1 A2) requires that environmental programs and decisions be
supported by data of the type and quality needed and expected for their intended use. The type of data
required for the ERLN has been defined as analytical data of known and documented quality. MQOs
provide a mechanism for the ERLN to receive data that is at the level required for this order.
MQOs are defined as specified performance criteria used in a sampling and analysis plan for indicators
such as precision, bias, and completeness. MQOs define the criteria by which samples of a particular
environmental matrix, processed under a particular analytical method, are evaluated. MQOs also provide
laboratories with the information necessary to determine what is expected by the data user. They also
define what data should be reported to meet the data user's intended purpose. The use of MQOs in the
ERLN provides a way to check laboratory data for completeness, accuracy, and quality in an automated
fashion. Laboratories receive their MQOs with their Analytical Service Request (ASR) and report data
that pertains to the scope of the MQOs as defined in submission requirements.
2.4 Creating a Model for Communication
The ERLN determined that a communication model that is based on the business process, adheres to EPA
data standards, and is scalable is necessary in order to meet its communication needs.
To begin creating a communication model, the ERLN established a Data Management Workgroup
consisting of major stakeholders involved in the ERLN, including laboratories and data users. An
assessment was conducted to determine what information was necessary to ensure that data quality could
be verified and the needs of the data users could be met. The assessment determined that a group of data
elements required for emergency response activities could act as the minimum electronic data reporting
requirement for the ERLN. The assessment focused on those situations when there is a need for electronic
data in a computer-readable format.
The ERLN continued to research the best mechanisms for creating a format based on the minimum data
requirements that adhered to EPA standards. It determined that adopting an extensible Markup Language
(XML) schema associated with an EPA standards-based domain model would provide the best means of
ensuring that short- and long-term data needs could be met. However, the ERLN recognized that much of
public and the commercial environmental testing laboratory community is not familiar with this
technology. In addition, the data management workgroup expressed concerns regarding the laboratory
communities' current capability to produce files that are ideal for exchange and automated processing.
The ERLN recognized that there would need to be an evolutionary process in order to reach the desired
communication model. The ERLN established the technology to be used for the future of the program as
well as a method that can be used now by laboratories that still meets the needs of the EPA data users.
The ERLN Domain Model, discussed further in Appendix E, was developed to describe the entities
involved in the ERLN process and the relationships among them. It was also developed to describe and
constrain the scope in a manner to promote automated processing for the program. The model serves to
document key concepts and provide a common vocabulary that is compliant with EPA-approved data
standards and is within the scope of ERLN automated data evaluation.
In addition to serving as a communication bridge between technical and business teams, the Domain
Model is being used as a blueprint for the XML files used to transfer analytical data between
stakeholders. XML Schema Definition (XSD) files will also be generated based on the Domain Model to
validate these XML files. This model serves as the future of data exchange within the ERLN and is
provided as a way for the community to begin familiarizing themselves with the new organization of data,
naming conventions, and terms.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
5
-------
Requirements for ERLN Data Submissions
An ERLN Data Exchange Template (DET) was developed for the current ELRN reporting requirements,
and it serves as a transition to the Domain Model. The DET incorporates the necessary EPA Data
Standards and addresses some high-level data organization issues. EPA data users have varying levels of
information they wish to receive, and laboratories have differing capabilities for producing files that can
be used for automated data processing. Because of this, the DET organized data into three separate types
based on the type of information an EPA data user may need and the format in which this data can be
provided. Each type progressively addresses more data and enables expansion of the electronic data
delivery process. The types are Type 1, Type 2, and Type 3. Type It is also added to transition between
the less inclusive types.
2.4.1 Defining Data Requirements
The process followed in defining data requirements was derived by studying the process associated with
laboratory activities such as sample receipt, tracking, preparation, analysis, and delivery. By defining and
discussing the process, certain articles in the process required additional information in order to
adequately describe it or keep track of it. Also, by discussing the laboratory processes, inherent
relationships between articles were recognized, reviewed, and established.
The ERLN also had to consider the data needed in order to perform a review that could meet EPA Order
CIO 2150.0 (formerly 5360.1 A2) which requires environmental programs and decisions be supported by
data of the type and quality needed and expected for their intended use. The type of data required for the
ERLN has been defined as analytical data of known and documented quality. As a result, the ERLN
review process requires that laboratory testing data include all quality control samples associated with the
analytical batch/run.
Fortunately, laboratories typically use a fairly universal approach to collect sample data and associated
quality control data. The process is referred to as the "analytical sequence." Many EPA methods mandate
this analytical sequence as part of quality assurance planning. Exhibit I in Section 2.4.1.1 provides a
generic example of the analytical sequence used by a laboratory to collect analytical data. Notice that the
substances measured can include field and laboratory generated substances.
There are cases (i.e., emergencies) where the data reviewer's immediate automated assessment does not
require the evaluation to include the full analytical sequence. Other data require a detailed evaluation of
raw data from the analytical sequence to evaluate how the data performed against MQOs defined. This
more formal review includes not only the target substance raw results but also the raw data for all quality
control samples in the analytical batch that contains the non-target substance results. The more MQO's
included in the review of the quality control data in an analytical sequence, the more complete the
evaluation of completeness, sequence, frequency, correctness, and limits. This evaluation assures that
accuracy, precision, sensitivity, selectivity, and representativeness of the target results are well
documented.
ERLN laboratories should provide:
• the analytical method and assurance that the method was followed;
• the raw quality control data associated with the analytical sequence that defines target substance
results;
• any unique laboratory analytical specifications that are necessary to evaluate the raw data;
• the ability to provide an audit trail from laboratory data collection to its reporting to the client;
and
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
6
-------
Requirements for ERLN Data Submissions
• an electronic submission that is preferably in XML format. By providing this information, the
laboratory is able to review its final output to assure that all the data measurements submitted are
what was generated.
Identifiers must be associated with each piece of raw data that specify the unique target and quality
control (QC) samples in the analytical sequence. For QC data, this raw data must have a unique sample
number and links to the batch from which it is included. Links can include instrument identifiers (if the
data are generated and included in an instrument laboratory automation system) and batch references such
as a batch identifier. Some raw data also require associated substance specifications in order to evaluate
the data. Some target substances may also require static specifications such as units, limits, wavelength,
uncertainty, etc.
One of the goals of the Type Two and Three data submissions is to enable the data reviewer to reproduce
the analytical sequence at different degrees and use the raw data to evaluate MQOs. An example of the
innovative use of collecting raw data is how the time of a preparation step in an analysis can be viewed as
an analysis data element, similar to a target substance. The review of this preparation time in comparison
to sample login time can assure that preparation took place in timely fashion.
2.4.1.1 Generic Analytical Sequence
The typical analytical sequence for a laboratory is described below. Laboratory Certification/
Accreditation normally requires that these values be collected and made part of the quality assurance
review. Modern Laboratory Information Management Systems (LIMS) should have the ability to recreate
these for the laboratory to review before submitting to a client as part of the final report.
Exhibit 1 Generic Analytical Sequence
• Tune(s)
• Initial Calibration (Multiple Standards to develop the calibration curve)
• Initial Calibration Verification (ICV)
• Initial Calibration Blank (ICB)
• A Contract Required Quantitation Limit (CRQL) Check Standard
• Optional Interference Check Sample A (ICSA)
• Optional Interference Check Sample AB (ICSAB)
• Continuing Calibration Verification (CCV) Opening (Opening CCVA)
• Continuing Calibration Blank (CCB)
• Ten Samples
• Continuing Calibration Verification (CCV)
• Continuing Calibration Blank (CCB)
• Ten Samples
• Laboratory Control Sample (LCS)
• Matrix Spike (MS)
• Matrix Spike Duplicate (MSD)
• Closing Continuing Calibration Verification (CCVB) Optional
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
7
-------
Requirements for ERLN Data Submissions
The Data Reporting Group may require additional samples for each matrix, such as:
• Preparation Blank (PB)
• Field Spikes
• Additional Blanks (Method, cleanup, storage blank, instrument blank)
• Performance Evaluation Mixture (PEM)
• Serial Dilutions
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy 8
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
-------
Requirements for ERLN Data Submissions
Section 3.0: Overview of Reporting Requirements
The reporting requirements are designed to ensure that analytical data of known and documented quality
is communicated in a common language to facilitate rapid data review and assessment through the use of
an automated tool. ERLN data reporting requirements are designed to support the various project needs
by providing a framework that supports an EPA data user's project needs.
The ERLN established three types of data submissions (Type 1, Type 2, and Type 3), each of which is
focused on the type of data required for a project in order for U.S. Environmental Protection Agency
(EPA) data users to make decisions. The type requested for a project is determined by the EPA data user
and specified in the Analytical Service Request. EPA data users consider a laboratory's ability to report
the different submission types as a capability of a laboratory. To assist laboratories in building this
capability, each submission type builds on the previous type to limit proliferating formats and reduce the
work load in producing multiple formats. An EPA data user's needs for data solely determines the
submission type requested. Laboratories are selected based on the capability to report the requested
submission type.
3.1 Requirements
Laboratories are required to report information pertaining to the analytical process based on the type of
submission requested by an EPA data user. Laboratories must also report measurement quality indicators
that support the measurement quality objectives provided to the laboratory to define the analysis to be
performed. Data must be provided in a format that can be read and understood by computer-based
software (electronic). Additionally, data supporting the content in the computer-readable format, as well
as a summary of the content, should be provided to assist with an EPA data user's review of the
automated assessment; this format is referred to as Data Reporting.
Laboratories are informed of a project's Data Submission Type in the ASR and must report data
applicable to the type in the appropriate format. A laboratory will also group samples received for a
project into Data Reporting Groups. A Data Reporting Group is the basis for all data reporting as it
establishes what and how many samples are included in a Data Submission. The standard ERLN Data
Reporting Group is created for every 20 field samples received by the laboratory during a calendar week
(Sunday-Saturday). Field blanks, trip blanks and project-specific performance evaluation samples
associated with the field samples are also included in a Data Reporting Group but are not considered field
samples. It is important that the laboratory creates its Data Reporting Group upon receipt of the 20th field
sample because all data turnarounds are calculated from the date the Data Reporting Group is closed. For
additional information regarding laboratory responsibilities when providing an analytical service, please
review Section 3.3 in the Environmental Response Laboratory Network (ERLN) Laboratory
Requirements Document.
It is also important that the laboratory not deviate from project specifications without prior approval from
the ERLN personnel specified in the laboratory's ERLN agreement or within the project-specific ASR.
Any problems, deviations and their resolutions should be documented and reported in the appropriate data
package narrative.
3.2 High-Level Data Submission Requirements
Each Data Submission Type defines its required submission format. The following information provides
an overview of requirements regarding the different formats.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
10
-------
Requirements for ERLN Data Submissions
3.2.1 Data Reporting Group Notification
Once a Data Reporting Group is created, the laboratory must provide the authorized ERLN representative
with documentation that includes the project identifier, the data package identifier and the samples
included in the Data Reporting Group. This information enables the authorized ERLN representative to
track the laboratory's progress and to determine a data delivery schedule. This is required for all Data
Submission Types regardless of format and should occur prior to creating an electronic submission.
3.2.2 Electronic
An electronic submission, also referred to as an Electronic Data Deliverable (EDD), is defined as
information provided in a computer-readable format. The electronic submission consists of data whose
content is provided either as an unformatted spreadsheet, Comma Separated Value (CSV), or extensible
markup language (XML) format. The XML format is best for facilitating the import of data into project-
level or enterprise-level relational databases and its processing by automated electronic data review and
assessment software. Word processed documents and e-mails are not considered computer-readable
electronic data in this context. An electronic submission is required for every Data Submission Type.
3.2.2.1 Spreadsheet or CSV
For Type One submissions, a spreadsheet or CSV file is an acceptable format. A spreadsheet or CSV file
format provides the ability for laboratories to provide result information to EPA data users. Laboratories
may use any off the shelf product to create their submission. Please review Section 4.0 for specific
requirements regarding required content for this electronic delivery type.
3.2.2.2 XML
XML is an open standard that provides a common way to describe electronic submission in order to
transfer data between systems, databases, and organizations. XML files are hierarchal text-based files that
consist of elements that describe a piece of data. In order for XML files to remain useful as a common
language among systems, certain rules regarding organizing information and syntax used must be
followed. XML files must be validated to ensure the file adheres to any business rules (validation)
established for a program as well as to XML standards (syntax). Currently, there are two options for
determining proper syntax and validation of an XML File: either a Document Type Definition (DTD) or
an XML Schema Definition (XSD). A DTD indicates the allowed fields and describes the data each field
can contain, which helps maintain the structure of the file but does little for the content reported in the
file. XSDs are flexible and are more advanced in terms of quality control than a DTD. The XSD limits the
types of data that can be entered and provides a wider range of options for establishing data relationships.
XSDs are more closely designed as relational databases where identifiers are used, whereas DTDs
establish relationships by placement of content within the file.
The ERLN has established a single DTD that can be used for all Data Submission Types. The ERLN has
also established an optional schema that laboratories can use to assist with building an environment that
can report the content necessary for the different submission types. Laboratories may use any XML
generation software to assist with extracting data from their Laboratory Information Management
Systems (LIMS) and formatting it into well-formed XML files. Additionally, laboratories can use EPA's
Staged Electronic Data Deliverable (SEDD) format to report ERLN XML files. Refer to Appendix D:
Using the Staged Electronic Data Deliverable (SEDD) to Report Environmental Response Laboratory
Network (ERLN) Data for additional information regarding how to use SEDD to report ERLN data.
For additional information regarding how to create an XML file, see Appendix C: Environmental
Response Laboratory Network (ERLN) extensible Markup Language (XML) Reporting Guide.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
11
-------
Requirements for ERLN Data Submissions
NOTE: The future for data reporting involves the use of the ERLN Domain Model in conjunction
with XML Schema. Laboratories may choose to implement and use this methodology in
place of the Data Exchange Template (DET). Reporting requirements for the ERLN Domain
Model will be made available as they are further defined.
3.2.3 Data Reporting
Data Reporting is defined as compiling original copies of laboratory forms and documents that summarize
and support the data within the electronic submission. Data reporting requires that data provided in the
electronic submission be organized in a way to summarize the contents of the submission as well as
provide additional supporting information. Data Reporting shall be delivered to the designated recipient
on the Analytical Service Request. The information contained in the Data Report must be delivered as a
single, bookmarked, Portable Document File (PDF) and submitted with the electronic submission. EPA
data users may also request that the information be provided as a paper copy.
3.2.3.1 PDF Requirements
The PDF file shall be bookmarked using a hierarchal bookmark structure (i.e., an overview or "parent"
bookmark, and a subordinate or "child" bookmark nested underneath the "parent" bookmark) based on the
table of contents and shall include page numbers. Data shall be grouped by laboratory narrative, project
correspondences, sample receiving documentation and summary data forms for sample data (grouped by
analytical method).
For Type Three submissions, the table of contents shall include a parent bookmark, a bookmark for each
method groups, and book marks for measurement quality indicators, sample data, standards data, and raw
data for measurement quality indicators.
3.3 Submission Types
The ERLN has three possible types of data needs that are solely determined by the requirements of the
EPA data user. Each type correlates to data required to support the intended use by response personnel
and builds on the previous type in order to limit creating multiple formats. In determining the scope of the
types, various capabilities of ERLN laboratories were considered in order to ensure electronic data could
be produced.
Table 2. Summary of Submission Types
Type
Submission
Purpose
Scope
Required
Electronic
Format
Type
One
Type 1
Provides result information for
projects.
Results Only for target substances
of field generated samples.
Spreadsheet
or CSV file
Type 1t
Provides a broader picture of the
result information.
Result information for Target and
non-target substances of Field and
Lab Generated Samples
Spreadsheet
or CSV file
Type
Two
Type 2
Provides information in order to
perform an automated assessment
on field and laboratory generated
samples.
Type 1t + Substance information
for each analysis performed on a
field or laboratory generated
sample, including batch
information, as well as some
calibration information (optional).
XML
Type
Three
Type 3
Most extensive submission format.
Provides information necessary to
perform an extensive assessment
including recalculating results.
Type 2 + Instrument response (i.e.
tuning ) and data supporting
laboratory results
XML
VERSION 1.5 - 101811 For Official Use Only - Do Not Cite, Circulate or Copy 12
-------
Requirements for ERLN Data Submissions
3.4 ERLN Data Organization (Applicable to Type Two and Three Submissions)
The use of XML files provides a mechanism to report data that require a relationship in order to
accurately represent the data when performing an automated assessment. The DET organizes data
elements into Data Groups to associate individual pieces of information to an object that adequately
describes the group of information. XML files require validation in order to define the format of the file.
The ERLN DET uses a DTD as the validation method for XML files. A DTD defines the allowable fields
and structure in which data can be reported. The ERLN Type 2 DTD was designed to request only the
information that is required for the ERLN Web-based Electronic Data Review (WebEDR) tool. Type 3
data cannot yet be processed using WebEDR however the data group organization is based on the data
that can be reported in the ERLN. The DTD will be expanded as additional capabilities are added to the
automated assessment tool and will be compatible with previous versions.
The following diagrams depict the Data Groups defined by the DET, how they relate to one another, and
how they are organized for use by a DTD. The diagram provides a high-level picture of the Data Groups
referenced in the DET and detailed in the Data Submission Types. Laboratories must organize their XML
submissions so that a Data Group retains the same relationships established in order for their XML file to
pass DTD validation. For detailed information regarding how to create an ERLN XML file, please review
Appendix C: Environmental Response Laboratory Network (ERLN) extensible Markup Language (XML)
Reporting Guide.
Orrwii'/Bikin DeteiK
PoirKofContaot
Der.» 5
Substonos Sdcn'jf-caticn
Det?ils
ArsBlv.^b. Ite'.Wh
ChflfanieriS-lr. ("HrtKit*
Sa-nelcPropiiraioii
Dwrfc
Measure Dilate
Figure 3-1. ERLN DET Type 2 Data Group Organization
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
13
-------
Requirements for ERLN Data Submissions
'1
1
fin
PwnrfCoriaU
Ooai &
Project Details
Sample
As Irllj **)"• D^diiK
"»ulr 'jr,fu iiluntif lj'jCi
Derail >.
Insrrun <_ r.
Deft-ils
irviun *r. Reijunse
V1 tnmal DftpiK
Method Details
ftfeasuw Dixai s
PrflH Oust-lf In'K -lit r
Pfc-tsllf.
Characteristic Data
S Hni t.'li
M&asui
Characteristic Details
Moiismc Desai s
IVl» Oust ly Ir'rimlrf
Dfc-Wk
«-trr' i- Hrpfirtr.il nr
OwIhi! ,
Measure Details
Chrldt M'lfatk DhUs!^
iUf 1
Dfck QujHv Ircii.jlu
Defail--
MttP-HUF? DuUls
Data Qual ty Micax*
Details
Measure Details
D"tB Ouc?I tv l( nor/r
EM.-te
f\HM Qi.rtlilv lp:tic'i!ur
DMrllK
Osi? slity Irnit Ynr
Dt^UiK
Figure 3-2. ERLN DET Type 3 Data Group Organization
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
14
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 15
-------
Requirements for ERLN Data Submissions
Section 4.0: Type One Data Submission
The ERLN recognizes that in some instances EPA data users may only require that result information be
provided. In order to meet this need, ERLN Type One data provide the ability to report the most basic
results information for target substances of field samples. For Type 1, the only measurement quality
objective (MQO) quality indicator provided by the laboratory is a data qualifier. Type One submissions
do not require extensible Markup Language (XML) reporting to ensure more laboratories can provide
Type One submissions; instead data are provided as a spreadsheet or CSV. Type It builds upon Type 1.
The data formatting remains simple but Type It transitions to Type Two by adding laboratory generated
quality control substances such as blanks, Laboratory Control Samples, spikes, etc.
4.1 Type 1 Electronic Submission Requirements
Type 1 data shall include final result information for target substances of field generated samples, which
include Field Samples, Field Blanks, and Performance Evaluation Samples. The Type One format for
computer-readable data is limited to the final results of an analytical process for the substances of concern
as determined by the laboratory for samples received for a project. Results for calibrations; instrument
performance checks; laboratory generated positive and negative control samples (e.g., Laboratory Control
Sample (LCS), blanks, etc.); and non-target substances (e.g., surrogates, internal standards, tentatively
identified compounds, etc.) are not reported. Refer to Section 3.4.1 or 4.12 of the Environmental
Response Laboratory Network (ERLN) Laboratory Requirements Document for additional details
regarding the scope of Type 1 data reporting.
4.1.1 Data Requirements
Type 1 data submissions shall include the information detailed in the following table for every target
substance of a field generated sample.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
16
-------
Requirements for ERLN Data Submissions
Table 3. Type 1 Data Requirements
ERLN Data Exchange
Template (DET) Tag
Definition
Business Rules/Comments
Required
Format
AgreementNumber*
A client-defined number or identifier that
specifies the contract or agreement under
which the laboratory analyzes the samples.
Provide if a contract number exists. If not, leave
blank.
Conditionally
Required
Alphanumeric
AnalysisEndDate
The date (and time, if required) of the end of
the analysis period, if the sample aliquot or
standard was analyzed over a period of
time.
The date should reflect the end of the analysis
performed by an instrument; it does not relate to
the time in which an analyst completed their
review of an analysis.
Y
YYYY-MM-DD
hh:mm:ss
AnalyticalServiceRequestl
dentifier*
A client-defined number or identifier that
specifies the service request.
Obtain from ASR.
Y
Alphanumeric
CASRegistryNumber
The unique number assigned by Chemical
Abstracts Service (CAS) to a chemical
substance.
Provide when the substance has a defined CAS
number. If not, leave blank.
Conditionally
Required
Alphanumeric
DataPackageldentifier*
A laboratory-defined identifier for this data
submission package. This identifier applies
to a single EDD.
Y
Alphanumeric
LaboratoryResultQualifier
A laboratory-assigned string of result
qualifiers (usually a single character for each
qualifier), based on client-defined rules and
values.
In order to stay consistent from one submission
to another, the only qualifiers that will be used
are "U", "J", and "UJ". "U" indicates that the
substance was analyzed for but not detected. "J"
indicates an estimated value. The "J" qualifier is
used when a QC parameter indicates that the
reported quantity could be inaccurate, or when
the data indicates the presence of a substance
that meets the identification criteria, but the result
is less than the sample quantitation limit but
greater than zero. The "UJ" qualifier indicates
that the substance was analyzed for but not
detected, and a QC parameter indicated that the
reporting limit could be inaccurate.
Conditionally
Required
Alphanumeric
Methodldentifier
The identification number assigned by the
method publisher.
Obtain from Analytical Service Request.
Y
Alphanumeric
Organization Identifier*
A designator used to uniquely identify a
unique business establishment within a
context.
Obtain from Analytical Service Request. If one is
not provided, the laboratory shall include an
identifier for their name.
Y
Alphanumeric
Projectldentifier*
A designator used to uniquely identify the
project to organizations sharing data.
Y
Alphanumeric
ReportingLimit
The number or value below which data are
typically reported as 'not detected' for the
substance being measured.
Y
Alphanumeric
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
17
-------
Requirements for ERLN Data Submissions
ERLN Data Exchange
Template (DET) Tag
Definition
Business Rules/Comments
Required
Format
ReportingLimitType
One of a list of client, regulation, or
organization-defined acronyms or statistical
methodologies that specify the type of
reporting limit.
Use the SEDD Valid Values list for
"QuantitationLimitType" to determine an
appropriate value for this element.
Y
Alphanumeric
ReportingLimitUnits
Units associated with reporting limit as
determined by the laboratory.
Use the SEDD Valid Values list to determine an
appropriate value for this element.
Y
Alphanumeric
Result
The reportable measure of the result for the
chemical, microbiological, or other
characteristic being analyzed.
Y
Alphanumeric
ResultUncertainty
A value or set of values that characterizes
the dispersion of the values that could
reasonably be attributed to the measured
result value.
For Radiochemical Analysis only at this time.
Ensure that Uncertainty is expressed in the same
Result Unit as the Result. If there is no
uncertainty, leave blank.
Conditionally
Required
Numeric
ResultUnits
The code that represents the unit for
measuring the item.
Y
Alphanumeric
SampleCollectionEndDate
The ending date that a field activity was
finished.
Enter start date for grab samples.
Y
YYYY-MM-DD
hh:mm:ss
Sampleldentifier
A designator used to uniquely identify a
sample within a context.
Obtain from Chain of Custody. If reporting a
laboratory generated sample, provide the
laboratory sample identifier as the
Sampleldentifier.
Y
Alphanumeric
SampleMatrix
Sub-medium or matrix that is sampled.
Obtain from Chain of Custody. If reporting a
laboratory generated sample, provide the matrix
of the appropriate field sample. Alternatively, use
the SEDD Valid Values list for "MatrixlD" to
determine an appropriate value for this element.
Y
Alphanumeric
SubstanceName
The name assigned to a chemical,
biological, or radiological substance or
feature that describes it in terms of its
molecular composition, taxonomic
nomenclature, or other characteristic.
Use the SEDD Valid Values instructions for
"Analyte name" and "AnalyteNameContext" to
determine an appropriate value for this element.
Refer to the appropriate official publication for a
list of analyte name valid values. Approved
analyte name lists are provided by:
• The Chemical Abstracts Service (CAS)
nomenclature, based on the 9th Collective Index
rules
• The International Union of Pure and Applied
Chemistry
• The Environmental Protection Agency's
(EPA's) Substance Registry System
(www. epa.gov/srs/).
Y
Alphanumeric
* Repeat data for each row included in the electronic submission.
VERSION 1.5- 101811 For Official Use Only - Do Not Cite, Circulate or Copy 18
-------
Requirements for ERLN Data Submissions
4.2 Type 1 Transitional (Type It) Electronic Submission Requirements
Type It builds on Type 1 and supplies the foundation for Type 2 Data Submissions by including result
information for laboratory generated samples and non-target compounds. By providing this information,
EPA data users are able to view a broader picture of the data being submitted. Type It data shall include
final result information for target and non-target substances of field-generated and laboratory-generated
samples. Results from laboratory-generated positive and negative control samples (e.g., LCS, blanks, etc.)
should also be reported. Refer to Section 3.4.1.1 or 4.13 of the Environmental Response Laboratory
Network (ERLN) Laboratory Requirements Document for additional details regarding the scope of Type 1
data reporting.
4.2.1 Data Requirements
Type It data submissions shall include the following information for target and non-target substances for
any field or laboratory generated sample in addition to Type 1 data.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
19
-------
Requirements for ERLN Data Submissions
Table 4. Type 1t Additional Data Requirements
ERLN Data Exchange Template
(DET) Tag
Definition
Business Rules/Comments
Required
Format
AnalysisStartDate
The date (and time, if required) of
analysis of a sample aliquot or
standard. If analyzed over a range
of dates, this is the start date.
Y
YYYY-MM-DD hh:mm:ss
Comment
A free-form comment field.
O
Alphanumeric
ExpectedResult
The expected final result of a
substance that has been spiked into
an aliquot at any time during the
analysis process, or the true value
of a substance in the sample
analyzed.
Provide if spiked substance was
added to a sample for analysis.
The expected result is what
should be found in the
substance. If the substance was
not spiked, leave blank.
C
Alphanumeric
ExpectedResultUnits
Units associated with expected
result.
Provide if reporting expected
result. If not, leave blank.
C
Alphanumeric
LaboratorySampleldentifier
A laboratory-defined identifier for a
sample that uniquely identifies a
single sample that is subjected to an
analysis.
O
Alphanumeric
LaboratorySubstanceldentifier
A laboratory-defined identifier for a
substance.
O
Alphanumeric
Locationldentifier
A client-defined identifier of the
sampling location at a particular
site.
O
Alphanumeric
OrganizationName*
Descriptive name for the laboratory
performing this analysis.
O
Alphanumeric
PreparationEndDate
Date and time of sample
preparation. Preparation is used
generally to include method specific
techniques such as extraction,
digestion, and separation. If
prepared over a range of dates, this
is the start date.
Provide end date and time in
YYYY-MM-DD hh:mm:ss format
if a preparation was performed
on the sample. If a preparation
was performed, the start and
end date must be provided. If
not, leave blank.
C
YYYY-MM-DD hh:mm:ss
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
20
-------
Requirements for ERLN Data Submissions
ERLN Data Exchange Template
(DET) Tag
Definition
Business Rules/Comments
Required
Format
PreparationStartDate
The date and time of the
preparation of this sample aliquot.
Preparation is used generally to
include method specific techniques
such as extraction, digestion, and
separation. If prepared over a
range of dates, this is the start date.
Provide start date and time in
YYYY-MM-DD hh:mm:ss format
if a preparation was performed
on the sample. If a preparation
was performed the start and end
date must be provided, if not,
leave blank.
C
YYYY-MM-DD hh:mm:ss
ResultBasis
The basis upon which the final
results were calculated.
Provide the result basis if the
result has been modified to
account for a sample
characteristic such as %
moisture, % solids. Use the
SEDD Valid Values for
"ResultBasis" to determine an
appropriate value for this
element."
C
Alphanumeric
SampleCollectionStartDate
Date and time the sample was
collected. If collected over a range
of dates, this is the start date.
For laboratory-generated QC
samples not associated with a
field sample, enter the end
date/time QC samples were
prepared by the laboratory.
o
YYYY-MM-DD hh:mm:ss
SampleType
The client-defined term used to
define the specific type of QC
sample being analyzed.
Use the SEDD Valid Values list
for "QCType" to determine an
appropriate value for this
element.
Y
Alphanumeric
SubstanceType
A client-defined identifier that
identifies the type of substance
reported.
Use the SEDD Valid Values list
for "AnalyteType" to determine
an appropriate value for this
element.
Y
Alphanumeric
* Repeat data for each row included in the electronic submission.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
21
-------
Requirements for ERLN Data Submissions
4.3 Electronic Delivery Requirements
Type One data must be reported electronically for every Data Reporting Group. The following identifies
the specific requirements for electronic reporting. For a formal list of reporting requirements, please refer
to Section 4.12 and 4.13 of the Environmental Response Laboratory Network (ERLN) Laboratory
Requirements Document.
• Report in a computer-readable format which is defined as a spreadsheet, Comma Separated Value
(CSV) or XML file.
o Type One submissions only require that a spreadsheet or CSV file be used.
• The file must contain a column representing the required data with the ERLN DET Data Element
names as column names.
o A single substance for a sample will constitute a new row within the spreadsheet.
o Data must be present for all required fields.
o Several fields will be repeated in each row in order to ensure the project information can
be identified for each substance when processing the data.
• A single spreadsheet should only contain results associated to the designated Data Reporting
Group.
• The spreadsheet must not have any formatting that can be applied using off the shelf products
such as text formatting as well as page formatting.
4.4 Data Reporting Requirements
Type One data reporting requires the laboratory to include original1 copies of the following information.
Please refer to 4.12 and 4.13 of the Environmental Response Laboratory Network (ERLN) Laboratory
Requirements Document for a detailed list of requirements.
• Laboratory narrative, including the following information;
o ERLN Agreement Number;
o Project Identifier;
o Field Sample identifiers for samples included in the data submission;
o Data Package Identifier;
o Detailed documentation of any sample shipment;
o Any analytical problems encountered in processing the samples; and
o Signature of by the Laboratory Manager or designee, including printed name, title, and
date below the following statement: "I certify that this sample data submission is in
compliance with the terms and conditions of the ERLN agreement, both technically and
for completeness, for other than the conditions detailed above. Release of the data
contained in this data package and in the associate electronic submission has been
authorized by the Laboratory Manager or the Manager's designee, as verified by this
signature."
• Chain of custody documentation;
1 No photocopies of original documents shall be placed in the hardcopy data submissions unless the original data
were initially written in a bound notebook maintained by the laboratory, or the original data were previously
submitted with another project or hardcopy data submission. Copies of laboratory documents shall be photocopied
in a manner to provide complete and legible replicates.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
22
-------
Requirements for ERLN Data Submissions
• Sample login information;
• Sample tags (if used);
• Data summary forms for the final sample results for the substances measured;
• E-mail correspondences or documentation of telephone conversations with ERLN representatives
regarding problems encountered with sample included in the data submissions
• Original receiving documents, including but not limited to, sample log-in sheet; other receiving
forms or copies of receiving logbooks; air bills (if an air bill is not received, include a hardcopy
receipt requested from the shipping company or a printout of the shipping company's electronic
tracking information); sample chain of custody records; and sample tags (if present) sealed in
plastic bags.
4.4.1.1 Data Summary Form Requirements
Summary forms must be provided that organize measured results of the reported samples for each
analytical method used. If reporting for multiple methods, then repeat this information for each method.
Forms must contain the following descriptive information:
• ERLN Organization Identifier established for or by the laboratory;
• Project Identifier;
• Data Package Identifier;
• Field Sample Identifier; and
• Matrix.
The body of the form should be a tabular representation of the results and should include the following for
the reported sample:
• Name of the substance measured;
• CAS number (if applicable);
• Measured result;
• Units associated with the result;
• Laboratory data qualifiers;
• Substances reporting limit; and
• Measurement uncertainty.
4.4.2 Data Reporting Delivery Requirements
The Data Reporting package must be delivered as a single Portable Document File (PDF) that includes
page numbering and a bookmarked Table of Contents with the electronic submission. Please refer to
Section 3.2.3.1 PDF Requirements for detailed information regarding the appropriate organization of the
PDF file. Additionally, EPA data users may request that the Data Reporting package be provided in paper
format, which may be delivered to the designated person as defined by the Analytical Serive Request
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
23
-------
Requirements for ERLN Data Submissions
Section 5.0: Type One Fact Sheet
Table 5. Type One Fact Sheet
Submission
Option
Type 1
Submission
Option
Type 1t
Scope
Result information for Target
substances of Field Generated Samples
Scope
Result information for Target and non-target
substances of Field and Lab Generated
Samples
Electronic
Format
Spreadsheet, Comma Separated Value
(CSV, or extensible Markup Language
(XML)
Electronic
Format
Spreadsheet, CSV, or XML
Hardcopy
Portable Document File (PDF)
(Required), Paper (Upon Request)
Hardcopy
PDF (Required), Paper (Upon Request)
Required
Summary
Forms
Organize measured results of the
reported samples for each analytical
method used.
Required
Summary
Forms
Organize measured results of the reported
samples for each analytical method used.
Instrument
and Other
Not Required
Instrument
and Other
Not Required
Supporting
Data:
Supporting
Data:
Required Data Elements:
Additional Required Data Elements:
• SubstanceName
• All Type 1 Data Elements
• SampleMatrix
• SubstanceType
• Methodldentifier
• SampleType
• Sampleldentifier
• AnalysisStartDate
• SampleCollectionEndDate
• AnalysisEndDate
• Result
• ResultUnits
• ReportingLimit
• ReportingLimitType
• ReportingLimitUnits
• AnalyticalServiceRequestldentifier*
• Organizationldentifier*
• Projectldentifier*
• DataPackageldentifier*
*Element will be repeated for each substance provided.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
24
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 25
-------
Requirements for ERLN Data Submissions
Section 6.0: Type Two Data Submission
Type Two data provides ERLN data users with the ability to perform an automated data assessment based
on defined quality objectives. Type Two meets the need for automated data processing by requiring data
to be submitted using extensible Markup Language (XML) in order to establish the necessary
relationships for data validation. Type Two is more advanced, and the data are provided in a manner in
which relationships can be established.
Type Two focuses on arranging information into groupings that describe what needs to be represented as
a significant part or object of the analytical process so that the process can be re-created. Data required
from Type One are still required in Type Two but data are now organized under objects that define what
the data are related to. For example, "Sample Identifier" in Type Two submissions is under the heading
(data group) "SampleDetails" because it is descriptive information of a sample. The use of this format
also accommodates reporting additional data associated with sample characteristics (e.g., pH,
temperature, % moisture, etc.); sample handling; sample preparation; laboratory batching; and sample
analysis.
Type Two formatting enables the ability to provide a submission with or without calibration data. Type
Two data submissions will provide ERLN data elements; laboratory and methods used; data associated
with sample characteristics, sample handling, preparation, laboratory batching and sample analysis; data
associated with the substance measured and sample type; and measurements associated with the expected
result for non-target compounds. Type Two also offers the ability for laboratories to report a variety of
optional data that an EPA data user can request in order to provide background information regarding the
methods used, additional contact information, and additional details pertaining to a sample. Type Two
data elements provide information that enables testing for precision, accuracy, sensitivity, selectivity, and
representatives.
6.1 Type 2 Electronic Submission Requirements
Type 2 data shall include all of the elements included in Type It. However, additional elements are
included to enable the data user to perform a more extensive data assessment. Results are reported for
each analysis performed on a sample and laboratory generated positive and negative control samples [e.g.,
Laboratory Control Sample (LCS), duplicates, blanks, etc.]. Data are also reported for non-target
substances (e.g., surrogates, internal standards, tentatively identified compounds, etc.) with the results of
the sample and laboratory batching. EPA data users may also request that calibration information be
provided with a Type Two submission, which will require the laboratory to provide additional
information. The laboratory shall include only the data elements associated with the measurement quality
indicators specified in the project-specific Analytical Serive Request Refer to Section 3.4.2 or 4.14 of the
Environmental Response Laboratory Network (ERLN) Laboratory Requirements Document for additional
details regarding the scope of Type Two data reporting.
6.1.1 Data Requirements
The ERLN Data Exchange Template (DET) defines the specific data elements applicable to each
submission type. To determine the specific data elements necessary for this type and the data groups they
belong to, please review Appendix B: Environmental Response Laboratory Network (ERLN) Data
Exchange Template (DET).
Type 2 Data Submissions shall include the following data:
• Field Generated Samples;
• Laboratory Generated (positive and negative control) samples, (i.e., LCS, blanks, MS/MSD, etc.);
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 26
-------
Requirements for ERLN Data Submissions
• Target and non-target substances;
• Batching information;
• Instrument performance and general calibration information; and
• Tentatively identified compounds.
6.1.2 Optional Data Requirements
EPA data users may request additional information in an Analytical Serive Request r a laboratory may
voluntarily provide the additional information in their submission. Refer to Appendix B: Environmental
Response Laboratory Network (ERLN) Data Exchange Template (DET) to obtain a list of fields that may
be requested.
6.2 Electronic Delivery Requirements
Type Two data must be reported using a well-formed XML file. The following identifies the specific
requirements for electronic reporting. For a formal list of reporting requirements, please refer to Section
4.14 of the Environmental Response Laboratory Network (ERLN) Laboratory Requirements Document.
• Report in a computer-readable format, which is defined as an XML file.
o XML must include the following as the 2nd line in the XML file:
See Appendix F: Environmental Response Laboratory Network (ERLN) Document Type
Definition (DTD) for a detailed copy of the DTD.
o XML must include the appropriate XML syntax. See Appendix C: Environmental
Response Laboratory Network (ERLN) extensible Markup Language (XML) Reporting
Guide for information regarding proper syntax.
o XML must pass ERLN DTD validation.
6.3 Data Reporting Requirements
Type Two data reporting requires the laboratory to follow all Type One reporting requirements in terms
of organization as well as content. In addition to Type One content, the following information is required
for Type Two reporting. Please refer to Section 4.14 of the Environmental Response Laboratory Network
(ERLN) Laboratory Requirements Document for a detailed list of requirements.
• Laboratory narrative that includes the following information:
o Information differentiating between initial sample analysis and re-analysis
o Information pertaining to any calculations used by calculating measurement uncertainty
6.3.1.1 Data Summary Form Requirements
Type Two data reporting shall include all summary forms requested in Type One as well as forms for all
appropriate measurement quality indicators grouped with sample data per method. If reporting for
multiple methods, then repeat this information for each method.
Type Two forms must contain the name of the Measurement Quality Indicator.
The body of the form should be a tabular representation of the results and should include the following for
the reported sample:
• Any measurement associated with the indicator
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
27
-------
Requirements for ERLN Data Submissions
• The Indicator's acceptance criteria
6.3.2 Data Reporting Delivery Requirements
The Data Reporting package must be delivered as a single Portable Document File (PDF) that includes
page numbering and a bookmarked table of contents with the electronic submission. Please refer to
Section 3.2.3.1 PDF Requirements for detailed information regarding the appropriate organization of the
PDF submission. Additionally, EPA data users may request the Data Reporting package be provided in
paper format, which may be delivered to the designated person as defined by the Analytical Service
Requestor.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
28
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 29
-------
Requirements for ERLN Data Submissions
Section 7.0: Type Two Fact Sheet
Table 6. Type Two Fact Sheet
Submission Option
Type 2
Scope
Type 1 + Substance information for each analysis performed on a field or
laboratory generated sample, as well as any calibration sample (optional).
Electronic Delivery
Extensible Markup Language (XML)
Data Report Delivery
Portable Document File (PDF) (Required), Paper (Upon Request)
Required Summary Forms
Type 1 + measurement quality indicator information
Instrument and Other
Supporting Data:
Not Required
Required Data Elements:
• ProjectDetails
• DataPackageldentifier
• DateFormat
• LaboratoryNarrative
• LaboratoryQualifiersDefinition
• Projectldentifier
• OrganizationDetails
• Organizationldentifier
• MethodDetails
• Method Identifier
• SampleDetails
• Sampleldentifier
• SampleChainofCustodyldentifier
• SampleCollectionEndDate
• SampleMatrix
• SampleType
• AnalysisDetails
• AnalysisBatchldentifier
• AnalysisEndDate
• AnalysisStartDate
• AnalysisType
• Instrumentldentifier
• LaboratoryAnalysis Identifier
• Method Identifier
• RunBatchldentifier
• SubstanceldentificationDetails
Exclusionlndicator
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultUnits
SubstanceName
SubstanceType
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
30
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 31
-------
Requirements for ERLN Data Submissions
Section 8.0: Type Three Data Submission
Type Three data submission is all-encompassing. It includes data from all previous reporting types in
addition to information required to recreate the analysis as performed by the laboratory. Type Three
provides USEPA with the most thorough report in order to perform a comprehensive data assessment.
Type Three's electronic submission is the same as the Type Two extensible Markup Language (XML)
files with the addition of several data groups and data elements. The information obtained in Type Three
allows for the re-calculation of laboratory reported results for each analysis in order to verify its
correctness. Data associated with the instrument responses and other measurements used to generate the
results included in a Type Two data submission are submitted by the laboratory.
8.1 Type Three Electronic Submission Requirements
Type Three data submissions shall include all of the elements included in Type Two as well as elements
to associate various types of instrument responses with their associated analyses. The laboratory shall
include only the data elements associated with the measurement quality indicators specified in the project-
specific Analytical Serive Request. Refer to Section 3.4.3 or 4.15 ofthq Environmental Response
Laboratory Network (ERLN) Laboratory Requirements Document for additional details regarding the
scope of Type Three data reporting.
8.1.1 Data Requirements
The ERLN Data Exchange Template (DET) defines the specific data elements applicable to each
submission type. To determine the specific data elements necessary for this type and the data groups to
which they belong, please review Appendix B: Environmental Response Laboratory Network (ERLN)
Data Exchange Template (DET).
Type Three data submissions shall include the following data:
• Results of all analyses performed on field and laboratory generated samples received at the
laboratory;
• Associated calibrations and instrument performance checks, including tunes;*
• Laboratory generated positive and negative control samples (e.g., Laboratory Control Sample
(LCS), blanks, etc) used as measurement quality indicators;
• Data associated with the instrument responses including output and other measurements used to
calculate instrument based results;*
• Non-target substances such as those used to indicate measurement quality (e.g., surrogates,
internal standards, spikes); and
• Tentatively identified compounds.
* Indicates MQOs not included in Type 2 data.
8.2 Optional Data Requirements
EPA data users may request additional information in an Analytical Serive Request r a laboratory may
voluntarily provide the additional information in their submission. Refer to Appendix B: Environmental
Response Laboratory Network (ERLN) Data Exchange Template (DET) to obtain a list of fields that may
be requested.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
32
-------
Requirements for ERLN Data Submissions
8.3 Electronic Delivery Requirements
Type Three data must be reported using a well-formed XML file to ensure data can be processed using
web-based electronic data assessment and review software. The following identifies the specific
requirements for electronic reporting. For a formal list of reporting requirements, please refer to Section
4.15 of the Environmental Response Laboratory Network (ERLN) Laboratory Requirements Document.
• Report in a computer-readable format, which is defined as an XML file.
o XML must include the following as the 2nd line in the XML file:
.
See Appendix F: Environmental Response Laboratory Network (ERLN) Document Type
Definition (DTD) for a detailed copy of the DTD.
o XML must include the appropriate XML syntax. See Appendix C: Environmental
Response Laboratory Network (ERLN) extensible Markup Language (XML) Reporting
Guide for information regarding proper syntax.
o XML must pass ERLN DTD validation.
8.4 Data Reporting Requirements
Type Three hardcopy format includes all Type Two contents. It also follows the same structure and
organization as a Type Two submission. Type Three hardcopy data submissions include all data
associated with their receipt, storage, tracking, preparation, and analysis of samples included in the data
submission. This includes tracking forms, logbook analyst entries, and any other documents or artifacts
associated with the analysis. In addition to Type Two content, the following information is required for
Type Three reporting. Please refer to Section 4.15 of the Environmental Response Laboratory Network
(ERLN) Laboratory Requirements Document for a detailed list of requirements.
• Laboratory narrative that includes the following information:
o Information to allow for the recalculation of the same results from raw instrument output,
which includes equation or curve calculations (at least one per method) used by
calculating measurement uncertainty.
o Identification and explanation of any differences that exist between the analytical data
reported and supporting documentation provided in the data submission.
• All original data associated with receipt, storage, tracking, preparation, and analysis of samples
included in the data submission;
• All original laboratory records pertaining to sample transfer, preparation, and analysis including,
but not limited to, the following documents:
o Log book preparation entries documenting the steps and calculations of diluted and
working standards;
o Receipt of stock standards showing the lot number and date of receipt or date of
preparation for all standards and spiking solutions;
o Original preparation and analysis forms or copies of preparation and analysis logbook
pages;
o Internal sample and sample extract transfer chain of custody records; and
o Screening records.
• All other original data package-specific documents in the possession of the laboratory including,
but not limited to, the following documents:
o Telephone contact logs;
o Copies of personal logbook pages; and
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
33
-------
Requirements for ERLN Data Submissions
o Handwritten data package-specific notes;
• Information associated with the instrument output used to calculate results.
8.4.1.1 Data Summary Form Requirements
Type Three data reporting shall include all summary forms requested in Type Two. If reporting for
multiple methods, then repeat information for each method.
8.4.2 Data Reporting Delivery Requirements
The Data Reporting package must be delivered as a single Portable Document File (PDF) file that
includes page numbering and a bookmarked table of contents with the electronic submission. Please refer
to Section 3.2.3.1 PDF Requirements for detailed information regarding the appropriate organization of
the PDF submission. Additionally, EPA data users may request that the Data Reporting package be
provided in paper format, which may be delivered to the designated person as defined by the Analytical
Serive Requestor
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
34
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 35
-------
Requirements for ERLN Data Submissions
Section 9.0: Type Three Fact Sheet
Table 7. Type Three Fact Sheet
Submission Option
Type 3
Scope
Results of all analysis performed on field and laboratory generated samples,
instrument performance checks, and calibrations including instrument response
data associated to the analysis in order to recalculate instrument-based results.
Electronic Delivery
extensible Markup Language (XML)
Data Report Delivery
Portable Document File (PDF) (Required), Paper (Upon Request)
Required Summary Forms
Type 2
Instrument and Other
Supporting Data
Refer to Section 4.15 of the Environmental Response Laboratory Network
(ERLN) Laboratory Requirements Document for a list of detailed requirements.
Required Data Elements:
• All Type 2 Data Elements
• ProjectDetails
• LaboratoryReportedDate
• SampleDetails
• LaboratoryReceiptDate
• MethodDetails
• MethodCategory
• MethodCodeType
• MethodDescription
• MethodName
• MethodSourceName
• MethodType
• MethodVersion
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
36
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 37
-------
Requirements for ERLN Data Submissions
Section 10.0: Customer Delivery Requirements
ERLN data are delivered to clients using the Web-based Electronic Data Review (WebEDR) tool and in
accordance with the timeframes specified in the Analytical Serive Request WebEDR is a Web-based system
that performs automated data evaluation on ERLN electronic submissions. WebEDR uses tests derived
from the EPA National Functional Guidelines (NFGs) for data evaluation and review, combined with
method-defined limits to measure data. The system evaluates the overall quality of the data and provides
Data Reviewers with tools that are used to measure the data against different measurement quality
objectives (MQOs). Once laboratory data has been evaluated, the system serves as a review tool for EPA
Data Reviewers.
Laboratories must establish a user account and submit all electronic data including the Portable Document
File (PDF) version of the Data Report package using WebEDR. Laboratories will upload a file, verify or
change their delivery customer information, and verify/modify the methods their file is mapped to and
review a preliminary inspection of their file to ensure the format of the file is correct and the submission
contains enough information to process according to the selected methods. If WebEDR finds any issues
with the file, laboratories will be able to print a report of issues and correct their file to re-upload to
WebEDR. The Self Inspection process will check the content and structure of the electronic submission to
ensure it meets the ERLN standards and contains enough/the appropriate data to process the submission.
One of the checks that are performed is the use of valid values. Laboratories will be informed when a
value provided for a limited list field is different than the acceptable value. In some cases these changes
are not critical however some fields are critical. The Self Inspection will inform the laboratory which
changes must be corrected before submitting a file and which ones are recommended.
When the Laboratory is satisfied with the content and structure of their submission, they will submit it as
a Final Submission to EPA. WebEDR will then notify the delivery customer and processes the file against
the method's established MQOs and provide an assessment to EPA data users.
WebEDR requires that laboratories perform at least one Self Inspection before they can submit a file and
encourages that issues identified in the Self Inspection be corrected prior to submission to ensure an
accurate data assessment. For this reason, laboratories should allot adequate time for corrections indicated
in WebEDR's Self Inspection in their delivery schedules as due dates provided in the Analytical Serive
Request pply to Final Submissions.
For more information regarding the use of WebEDR, please access the online help available at
http://webedr.fedcsc.com/.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy 38
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 39
-------
Requirements for ERLN Data Submissions
Appendix A: Glossary
Analytical Service Request. Project specific requirements sent to an ERLN laboratory, by the
authorized ERLN Representative, when requesting services. An ASR is typically provided as a form and
includes the following elements: date of request, project identifier, point(s) of contact information,
sampling/shipping information, analytical request information, criteria for analytical method, special
requirements, and a section to document any known contaminants.
CAS Number. The Chemical Abstracts Service (CAS) unique numerical identifier for a chemical
element.
Data Reviewer. User role for reviewing results of electronic submissions processed by the Web-based
Electronic Data Review (WebEDR), creating user-defined method Measurement Quality Objectives
(MQOs), and adding a user-defined method. Data Reviewer users may also manager their own user
account.
DRC (Design Rules and Conventions) for the Environmental Information Exchange Network.
extensible Markup Language (XML) Design Rules and Conventions for the Environmental Information
Exchange Network [Version 1], published September 2003 and revised April 6, 2006 by the XML
Schema Design Rules and Conventions Interim Update for the Exchange Network [Version 1.]
Electronic Data Deliverable (EDD). Environmental sampling data submitted to U.S. Environmental
Protection Agency (EPA) in a pre-defined electronic format.
Environmental Response Laboratory Network (ERLN). A network of laboratories capable of
providing analytical services in response to environmental incidents.
Final Submission. WebEDR procedure for the official EDD submission to EPA.
Matrix. The media from which samples are taken. These can include air, soil, water, building
materials/debris, tissue, etc.
Method. Approved procedures for measuring the presence and concentration of physical and chemical
pollutants.
Measurement Quality Objective (MQO). Performance and acceptance criteria that clarify WebEDR
objectives, and specify tolerable types of potential decision errors that will be used as the basis for
establishing the quality and quantity of data needed to support decisions.
Qualifier. Code to indicate the result or status of the data upon submission for review.
Results (Final and Individual). Summary of laboratory results and qualifiers of target substances for
field-generated samples.
Self Inspection. Procedure used to inspect EDDs to determine completeness and compliance with
technical requirements, prior to delivery to EPA.
Staged Electronic Data Deliverable (SEDD). Format used to convert local database data into an
extensible Markup Language (XML)-compliant file for delivery to EPA.
Substance. A substance or chemical constituent that is determined in an analytical procedure.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
40
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 41
-------
Requirements for ERLN Data Submissions
Appendix B: ERLN Data Exchange Template (DET)
A Data Exchange Template (DET) is a standardized format that identifies the types of information
required or allowed in a particular document or data exchange. Data exchange templates contain no data,
but they define the format for exchange according to data standards and trading partner agreements. The
ERLN DET was developed to provide a communication model that was based on the business process,
adheres to U.S. Environmental Protection Agency (EPA) data standards, and can be easily expanded.
B.l High-Level Concepts
An ERLN Data Exchange Template (DET) was developed to govern the current ELRN reporting
requirements, meet the current data needs for automated processing, and serves as a transition to the
Domain Model. The DET incorporates the necessary EPA data standards and addresses some high-level
data organization issues. EPA data users have varying levels of information they wish to receive and
laboratories have differing capabilities for producing files that can be used for automated data processing.
For this reason, the DET organized data into three separate types based on the level of information an
EPA data user may need and the format in which this data can be provided.
Information included in the DET represents several different types of data necessary to eventually
recreate the analytical process of the laboratory. This includes information to indicate what laboratory and
instrument quality control samples are associated with field generated samples (Batching), what analyses
were used to come to a final result (Analysis grouping), and reporting substances that are the combination
of other substances (Substance grouping). This information is requested as part of the DET in order to
ensure the data is put in the appropriate context and EPA data users have a complete understanding of
how the information was derived.
B. 1.1 Representative Groups
One of the major concepts applied to the DET was the idea of categorizing like data together, identifying
similarities, and then summarizing this information so that one data element could be used to represent
multiple options. This concept helped solve a significant problem with using Document Type Definitions
(DTDs) as a validation method. DTDs are limiting when additions or modifications need to be made. If a
new data element needs to be added, an update to the DTD would be necessary and laboratories would
then need to change their methods for generating an extensible Markup Language (XML) document. By
providing a generic Data Group for these similar data elements, values can be added without impacting
the DTD or a laboratory's setup for generation of XML files.
The ERLN identified several categories of data that would require the ability to frequently modify over
time and that shared what information was needed when reporting the data. Examples of this are measures
and methods. Measures are a major component of any data associated to an analytical process and there is
a seemingly endless list of what can be considered a measure but a limited list of what is needed to know
about a measure. In previous exchange models, measurements are individual data elements in the model
and their associated data are reported with each measure under a different data element name. In the
ERLN DET, measures are reported as a Data Group and an individual measure is reported as a value for
an element in the group. An example of this is Amount Added. In a Staged Electronic Data Deliverable
(SEDD), Amount Added and its associated units and value are reported as individual data elements in the
XML File. In the ERLN DET, Amount Added would be the value for the MeasureName data element and
units a value of the MeasureUnitCode data element in the Measure Details data group. This concept allows
for the expansion of the data standard without disrupting the existing process for providing and validating
data.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
42
-------
Requirements for ERLN Data Submissions
This concept was applied to several groups in the DET including the MeasureDetails, and
CharacteristicDetails data groups. The groups should be repeated under their appropriate primary group
whenever a different measure or method is necessary.
B.1.2 Relational Groups
Another concept applied to the DET is a relational approach to reporting data in an XML file using
DTDs. Typically data can only be reported as a hierarchy when validating against a DTD, which is why
the future of ERLN is moving towards the use of XML Schemas for validation; however, in order to
introduce this technique in this transition phase, the OrganizationDetails, PointOfContactDetails, and
MethodDetails group are implemented as relational groups. A relational group does not need to be
included as a sub-group under a primary group. Instead, a data element exists within a data group that
provides information in order for automated systems to establish a relationship between the data group the
element is reported in and its related data group. In this case, method information should be listed out in
the MethodDetails data group for the entire submission with each method possessing a unique
Methodldentifier. When the laboratory must indicate the specific method used during for the data in
another data group such as an analysis, they will report the identifier of the method assigned as the client
method in the MethodDetails group in the Methodldentifier data element. By providing this, an
information system can establish the relationship it needs to link the two together instead of having the
laboratory report the data again under the AnalysisDetails data group. These groups also serve as
representative groups in that they can be repeated as many times as necessary under the ProjectDetails
group in order to provide the list of all methods, organization, and contacts the data may use.
B.2 Overview ofData Groups
A Data Group defines what type of information is being reported in the group. The following are the
ERLN DET data groups along with their associated descriptions.
Table 8. ERLN Data Group Definitions
Data Group Name
Definition
ProjectDetails
Describes the format and content unique to a specific electronic data
submission as it relates to a specific project.
OrganizationDetails
Describes the unique framework of authority within which a person or
persons act, or are designated to act, towards some purpose.
PoingOfContactDetails
Describes the particular termsregularly connected with a person so that
you can recognize, refer to, or address him or her.
SampleDetails
Describes one sample analyzed under the criteria established for the
project.
SampleHandlingDetails
Describes any manipulation ofthe sample (e.g., leaching, filtering, and
ashing) prior to taking a sample aliquot for analysis.
AnalysisDetails
Describes one complete sequence of events, from taking a sample aliquot
through the measurement process, as defined as part of one method.
SamplePreparationDetails
Describes a preparation or cleanup process as part of an analysis.
SubstanceldentificationDetails
Describes the substance level data from one analysis or one group of
analyses.
InstrumentResponseDetails
Identifies and reports the actual measurement data related to the analysis
of substance peaks.
InstrumentResponseAdditionalDetails
A group of data elements that identifies cross-peak comparisons, multiple
exposure readings, or data related to the comparison of two or more
substances such as those data elements that describe the effects of
potentially interfering substances on a peak.
CharacteristicDetails
Identifies and quantifies the intrinsic characteristics associated with a
sample as received by a laboratory or after the sample has been
processed through a handling or preparation method.
MethodDetails
Describes the procedures and techniques required to determine the
methods used to obtain a result.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
43
-------
Requirements for ERLN Data Submissions
Data Group Name
Definition
MeasureDetails
Identifies the value and the associated units of measure for measuring an
observation or analytical result value.
DataQualitylndicatorDetails
Describes the quantitative and qualitative descriptors that are used to
interpret the degree of acceptability or utility of data to the user.
B.3 Data Element Reporting
The ERLN DET will assist laboratories in determining the information required for data submissions to
the ERLN. The DET requires only the data elements that facilitate the automated processing of data or
puts the automated review in the appropriate context for visual inspection of electronic results. The DET
identifies data elements as required, conditionally required, optional or not required.
• Required Data Elements: Define the basis for information necessary to identify the project,
electronic submission, and minimum information necessary for the Data Submission Type.
Required data elements must contain a value and be reported in the data submission at all times.
Required is indicated by a "Y" in the ERLN DET.
• Conditionally Required Data Elements: Defines additional elements that are required should a
certain condition exist in the data submission. Conditional elements are only required if the
analytical methodology used requires the use of the elements indicated as conditional.
Conditionally Required is indicated by a "C" in the ERLN DET.
• Optional Data Elements: Defines information that an EPA data user may want to request or a
Laboratory my want to provide in addition to the required or conditionally required elements for a
submission type. Data elements identified as optional do not need to be reported unless requested
by the EPA data user. Optional is indicated by an "O" in the ERLN DET.
• Not Required Data Elements: Defines information that an EPA data user will not use and are
not necessary for automated processing. This is only applicable to Type 1, It or 2. Data elements
identified as not required cannot be electronically reported. Not required is indicated by a in
the ERLN DET.
£3.3.7 Data Element Value Formats
There are five types of data that can be used for a data element which define the value that can be
reported. The ERLN DET defines the value that is allowed for each data element. The five types include
Boolean, Date, Limited List, Numeric, and Text. Refer to Section B4.4.4 DET Data Element Definitions
to determine a data elements defined value format.
• Boolean: Allows only one of two values; true and false (Y or N).
• Date: The date format established is YYYY-MM-DD hh:mm:ss which is based on ISO 8601:2004.
The technical representation of this date is YYYY-MM-DDThh:mm:ss where T represents a
characters space. The date format must be used for all reported dates.
• Limited List: Defines a restricted list of values for a particular data element. Refer to the SEDD
Specification 5.2 Valid Values for a list of values applicable to a data element.
• Numeric: Allows for integer, decimal, or exponential formats for reporting numeric data.
• Text: Allows any value and format to be entered for a data element; this includes numeric values.
B .4 ERLN DET
The following table summarizes the ERLN DET. Type 1 and It Data Submissions do not require the Data
Group indication. Elements listed here must be reported in the Data Group they are associated with.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
44
-------
Requirements for ERLN Data Submissions
Table 9. ERLN Data Exchange Template
ERLN Data Group
ERLN Data Element
Type 1
Type1t
Type 2
Type 3
ProiectDetails
AqreementModificationDescription
-
-
O
O
ProjectDetails
AqreementModification Identifier
-
-
O
o
ProjectDetails
AqreementNumber
O
O
o
o
ProjectDetails
AnalyticalServiceRequestldentifier
Y
Y
Y
Y
ProjectDetails
Comment
-
O
O
O
ProjectDetails
DataExchanqeTemplateldentifier
-
-
-
O
ProjectDetails
Data ExchanqeTemplatelmplementation Identifier
-
-
-
O
ProjectDetails
DataExchanqeTemplatelmplementationVersion
-
-
-
O
ProjectDetails
DataExchanqeT emplateVersion
-
-
-
O
ProjectDetails
DataPackaqeldentifier
Y
Y
Y
Y
ProjectDetails
DataPackaqeName
-
-
O
O
ProjectDetails
DataPackaqeVersion
-
-
O
O
ProjectDetails
DateFormat
-
-
Y
Y
ProjectDetails
GeneratinqSystemldentifier
-
-
-
O
ProjectDetails
GeneratinqSystemVersion
-
-
-
O
ProjectDetails
LaboratoryNarrative
-
-
Y
Y
ProjectDetails
LaboratoryQualifiersDefinition
-
-
Y
Y
ProjectDetails
LaboratoryReportedDate
-
-
O
Y
ProjectDetails
Projectldentifier
Y
Y
Y
Y
ProjectDetails
ProjectName
-
-
O
O
ProjectDetails
Siteldentifier
-
-
-
O
ProjectDetails
SiteName
-
-
-
O
OrqanizationDetails
Comment
-
-
O
O
OrqanizationDetails
Orqanization Identifier
Y
Y
Y
Y
OrqanizationDetails
OrqanizationLocationAddress
-
-
O
O
OrqanizationDetails
Orq a n izati o n Locati o n Add ressC ity
-
-
O
O
OrqanizationDetails
OrqanizationLocationAddressCountry
-
-
O
O
OrqanizationDetails
Orq a n izati o n Locati o n Add ressState
-
-
O
O
OrqanizationDetails
OrqanizationLocationAddressZipCode
-
-
O
O
OrqanizationDetails
OrqanizationMailinqAddress
-
-
O
O
OrqanizationDetails
OrqanizationName
-
O
O
O
OrqanizationDetails
OrqanizationTelephoneNumber
-
-
O
O
OrqanizationDetails
OrqanizationType
-
-
O
O
PointofContactDetails
Comment
-
-
O
O
PointotContactDetails
ContactElectronicAddress
-
-
o
O
PointofContactDetails
ContactFullName
-
-
o
O
PointofContactDetails
Contactldentifier
-
-
o
O
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
45
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
Type 1
Type1t
Type 2
Type 3
PointofContactDetails
ContactTitle
-
-
O
O
PointofContactDetails
ContactType
-
-
O
O
SampleDetai
s
AlternateLaboratorySampleldentifier
-
-
-
o
SampleDetai
s
AnalysisRequestldentitier
-
-
-
o
SampleDetai
s
Billinq Identifier
-
-
-
o
SampleDetai
s
Bottleldentifier
-
-
-
o
SampleDetai
s
BottleType
-
-
-
o
SampleDetai
s
Comment
-
-
-
o
SampleDetai
s
Compositelndicator
-
-
-
o
SampleDetai
s
Contactldentifier
-
-
o
o
SampleDetai
s
Coolerldentifier
-
-
-
o
SampleDetai
s
CreatedDate
-
-
-
o
SampleDetai
s
FieldEquipmentBatch Identifier
-
-
-
o
SampleDetai
s
Filteredlndicator
-
-
-
o
SampleDetai
s
LaboratoryReceiptDate
-
-
o
Y
SampleDetai
s
LaboratoryReportingBatch Identifier
-
-
-
o
SampleDetai
s
LaboratorySampleldentifier
-
O
o
o
SampleDetai
s
LaboratoryType
-
-
-
o
SampleDetai
s
Locationldentifier
-
o
o
o
SampleDetai
s
LocationName
-
-
-
o
SampleDetai
s
MethodBatch Identifier
-
-
-
o
SampleDetai
s
Methodldentifier
-
-
-
o
SampleDetai
s
NumberOfBottles
-
-
-
o
SampleDetai
s
OriginalClientSampleldentifier
-
-
-
o
SampleDetai
s
OriginalLaboratorySampleldentifier
-
-
-
o
SampleDetai
s
PhaseAnalyzed
-
-
-
o
SampleDetai
s
Preservative
-
-
c
c
SampleDetai
s
PreservedBy
-
-
-
o
SampleDetai
s
Priorityldentifier
-
-
-
o
SampleDetai
s
QualityControlCategory
-
-
-
o
SampleDetai
s
QualityControlSampleLinkage
-
-
-
o
SampleDetai
s
Quarantinelndicator
-
-
-
o
SampleDetai
s
SampleChainofCustody Identifier
-
-
Y
Y
SampleDetai
s
SampleCollectionEndDate
Y
Y
Y
Y
SampleDetai
s
SampleCollectionStartDate
-
O
O
o
SampleDetai
s
Sampleldentifier
Y
Y
Y
Y
SampleDetai
s
SampleMatrix
Y
Y
Y
Y
SampleDetai
s
SampleMatrixMediumType
-
-
-
O
SampleDetai
s
SampleType
-
Y
Y
Y
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
46
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
Type 1
Type1t
Type 2
Type 3
SampleDetails
SamplingBatch Identifier
-
-
-
O
SampleDetails
ShippingBatch Identifier
-
-
-
O
SampleDetails
Siteldentifier
-
-
-
o
SampleDetails
SiteName
-
-
-
o
SampleDetails
StorageBatchldentifier
-
-
C
c
SampleHandlingDetails
Apparatusldentifier
-
-
-
o
SampleHandlingDetails
Bottleldentifier
-
-
-
o
SampleHandlingDetails
Comment
-
-
-
o
SampleHandlingDetails
Contactldentifier
-
-
-
o
SampleHandlingDetails
HandlingBatch Identifier
-
-
-
o
SampleHandlingDetails
HandlingEndDate
-
-
-
o
SampleHandlingDetails
Handlingldentifier
-
-
-
o
SampleHandlingDetails
HandlingStartDate
-
-
-
c
SampleHandlingDetails
HandlingType
-
-
-
c
SampleHandlingDetails
Methodldentifier
-
-
-
o
SampleHandlingDetails
SampleMatrix
-
-
-
o
SampleHandlingDetails
SampleMatrixMediumType
-
-
-
o
AnalysisDetails
AlternateLaboratoryAnalysisldentifier
-
-
-
o
AnalysisDetails
AnalysisBatch Identifier
-
-
Y
Y
AnalysisDetails
AnalysisEndBatchldentifier
-
-
-
c
AnalysisDetails
AnalysisEndDate
Y
Y
Y
Y
AnalysisDetails
AnalysisGroupldentifier
-
-
-
C
AnalysisDetails
AnalysisStartDate
-
Y
Y
Y
AnalysisDetails
AnalysisType
-
-
Y
Y
AnalysisDetails
Apparatusldentifier
-
-
-
O
AnalysisDetails
Autosamplerlndicator
-
-
-
O
AnalysisDetails
BackgroundCorrection Indicator
-
-
-
O
AnalysisDetails
BackgroundRawDatalndicator
-
-
-
O
AnalysisDetails
BackgroundType
-
-
-
O
AnalysisDetails
Bottleldentifier
-
-
-
O
AnalysisDetails
ClientAnalysisldentifier
-
-
-
O
AnalysisDetails
Column
-
-
-
C
AnalysisDetails
Comment
-
-
-
O
AnalysisDetails
ConfirmationAnalysisldentifier
-
-
-
O
AnalysisDetails
Contactldentifier
-
-
O
O
AnalysisDetails
Detectorldentifier
-
-
-
o
AnalysisDetails
DetectorType
-
-
-
o
AnalysisDetails
Exclusionlndicator
-
-
-
o
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
47
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
Type 1
Type1t
Type 2
Type 3
AnalysisDetails
HeatedPurgelndicator
-
-
-
C
AnalysisDetails
Instrumentldentifier
-
-
Y
Y
AnalysisDetails
InstrumentSerialNumber
-
-
-
O
AnalysisDetails
InterelementCorrection Indicator
-
-
-
O
AnalysisDetails
LaboratoryAnalysisldentifier
-
-
Y
Y
AnalysisDetails
LaboratoryFileldentifier
-
-
O
O
AnalysisDetails
Methodldentifier
Y
Y
Y
Y
AnalysisDetails
MobilePhase
-
-
-
O
AnalysisDetails
OriginalLaboratoryAnalysisldentitier
-
-
-
O
AnalysisDetails
PreparationBatch Identifier
-
-
C
C
AnalysisDetails
PreparationEndDate
-
-
-
O
AnalysisDetails
PreparationStartDate
-
-
-
O
AnalysisDetails
PreparationType
-
-
-
O
AnalysisDetails
QuantitationBasis
-
-
-
O
AnalysisDetails
ReferenceDate
-
-
-
O
AnalysisDetails
ResultBasis
-
O
o
O
AnalysisDetails
RunBatchldentifier
-
-
Y
Y
AnalysisDetails
Standardldentifier
-
-
-
O
AnalysisDetails
StandardSourceName
-
-
-
O
SamplePreparationDetai
s
Apparatusldentifier
-
-
-
O
SamplePreparationDetai
s
Bottleldentifier
-
-
-
O
SamplePreparationDetai
s
CleanupBatch Identifier
-
-
C
C
SamplePreparationDetai
s
CleanUpEndDate
-
-
-
C
SamplePreparationDetai
s
Cleanupldentifier
-
-
-
C
SamplePreparationDetai
s
CleanUpStartDate
-
-
-
O
SamplePreparationDetai
s
CleanupType
-
-
c
C
SamplePreparationDetai
s
Column
-
-
-
O
SamplePreparationDetai
s
Comment
-
-
-
O
SamplePreparationDetai
s
Contactldentifier
-
-
o
O
SamplePreparationDetai
s
LaboratoryResultStatus
-
-
-
O
SamplePreparationDetai
s
LotNumber
-
-
-
o
SamplePreparationDetai
s
Methodldentifier
-
-
o
o
SamplePreparationDetai
s
PreparationBatch Identifier
-
-
-
c
SamplePreparationDetai
s
PreparationEndDate
-
c
c
c
SamplePreparationDetai
s
Preparationldentifier
-
-
-
o
SamplePreparationDetai
s
PreparationStartDate
-
c
c
c
SamplePreparationDetai
s
PreparationType
-
-
-
c
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
48
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
Type 1
Type1t
Type 2
Type 3
SamplePreparationDetails
SampleDataGroupType
-
-
C
C
SamplePreparationDetails
SampleMatrix
-
-
-
O
SamplePreparationDetails
SampleMatrixMediumType
-
-
-
o
SamplePreparationDetails
Solvent
-
-
-
o
Substanceldent
ficationDetails
BackgroundType
-
-
-
o
Substanceldent
ticationDetails
CalibrationBasisldentifier
-
-
-
c
Substanceldent
ficationDetails
CalibrationType
-
-
-
o
Substanceldent
ficationDetails
CASRegistryNumber
C
C
c
c
Substanceldent
ficationDetails
Comment
-
-
-
o
Substanceldent
ficationDetails
Exclusionlndicator
-
-
Y
Y
Substanceldent
ficationDetails
ExpectedResult
-
c
C
C
Substanceldent
ficationDetails
ExpectedResultUnits
-
c
C
C
Substanceldent
ficationDetails
InstrumentResponseldentifier
-
-
-
C
Substanceldent
ficationDetails
IntermediateResult
-
-
-
c
Substanceldent
ficationDetails
IntermediateResultUncertainty
-
-
-
o
Substanceldent
ficationDetails
IntermediateResultUnits
-
-
-
c
Substanceldent
ficationDetails
LaboratoryResultQualifier
c
c
c
c
Substanceldent
ficationDetails
LaboratorySubstanceldentifier
-
o
o
o
Substanceldent
ficationDetails
LotNumber
-
-
-
o
Substanceldent
ficationDetails
Manual Integration Indicator
-
-
-
o
Substanceldent
ficationDetails
QuantitationBasis
-
-
-
o
Substanceldent
ficationDetails
ReportingLimit
Y
Y
Y
Y
Substanceldent
ficationDetails
ReportingLimitType
Y
Y
Y
Y
Substanceldent
ficationDetails
ReportingLimitUnits
Y
Y
Y
Y
Substanceldent
ficationDetails
Result
Y
Y
Y
Y
Substanceldent
ficationDetails
ResultBasis
-
-
-
O
Substanceldent
ficationDetails
ResultUncertainty
O
O
O
O
Substanceldent
ficationDetails
ResultUnits
Y
Y
Y
Y
Substanceldent
ficationDetails
Standardldentifier
-
-
-
C
Substanceldent
ficationDetails
StandardSourceName
-
-
-
C
Substanceldent
ficationDetails
SubstanceGroupldentifier
-
-
-
O
Substanceldent
ficationDetails
SubstanceName
Y
Y
Y
Y
Substanceldent
ficationDetails
SubstanceNameContext
-
-
-
O
Substanceldent
ficationDetails
SubstanceType
-
Y
Y
Y
InstrumentResponseDetails
BackgroundType
-
-
-
O
InstrumentResponseDetails
CalibrationType
-
-
-
C
InstrumentResponseDetails
Comment
-
-
-
O
InstrumentResponseDetails
Exclusionlndicator
-
-
-
C
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
49
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
Type 1
Type1t
Type 2
Type 3
nstrumentResponseDetails
InstrumentResponseldentifier
-
-
-
C
nstrumentResponseDetails
InstrumentResponseTypeName
-
-
-
c
nstrumentResponseDetails
IntermediateResult
-
-
-
c
nstrumentResponseDetails
IntermediateResultUncertainty
-
-
-
o
nstrumentResponseDetails
IntermediateResultUnits
-
-
-
c
nstrumentResponseDetails
LaboratoryResultQualifier
-
-
-
o
nstrumentResponseDetails
Manual Integration Indicator
-
-
-
c
nstrumentResponseDetails
ReportingLimit
-
-
-
o
nstrumentResponseDetails
ReportingLimitType
-
-
-
o
nstrumentResponseDetails
ReportingLimitUnits
-
-
-
o
nstrumentResponseDetails
Result
-
-
-
o
nstrumentResponseDetails
ResultBasis
-
-
-
o
nstrumentResponseDetails
ResultUncertainty
-
-
-
o
nstrumentResponseDetails
ResultUnits
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
AdditionalResponseldentifier
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
CASRegistryNumber
-
-
-
c
nstrumentResponseAdd
tionalDetai
s
Comment
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
InstrumentResponseldentifier
-
-
-
c
nstrumentResponseAdd
tionalDetai
s
InstrumentResponseTypeName
-
-
-
c
nstrumentResponseAdd
tionalDetai
s
IntermediateResult
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
IntermediateResultUncertainty
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
IntermediateResultUnits
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
LaboratoryResultQualifier
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
LaboratorySubstanceldentifier
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
Result
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
ResultBasis
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
ResultUncertainty
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
ResultUnits
-
-
-
o
nstrumentResponseAdd
tionalDetai
s
SubstanceName
-
-
-
c
nstrumentResponseAdd
tionalDetai
s
SubstanceNameContext
-
-
-
c
CharacteristicDetails
CharacteristicName
-
-
C
c
CharacteristicDetails
CharacteristicType
-
-
C
c
CharacteristicDetails
CharacteristicUnits
-
-
c
c
CharacteristicDetails
CharacteristicValue
-
-
c
c
CharacteristicDetails
Comment
-
-
o
o
MethodDetails
Comment
-
-
o
o
MethodDetails
MethodCategory
-
-
o
Y
MethodDetails
MethodCodeType
-
-
o
Y
MethodDetails
MethodDescription
-
-
o
Y
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
50
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
Type 1
Type1t
Type 2
Type 3
MethodDetails
Methodldentifier
-
-
Y
Y
MethodDetails
MethodLevel
-
-
O
C
MethodDetails
Method ModiticationDescription
-
-
O
C
MethodDetails
Method Modification Identifier
-
-
O
C
MethodDetails
MethodName
-
-
O
Y
MethodDetails
MethodSourceName
-
-
O
Y
MethodDetails
MethodType
-
-
O
Y
MethodDetails
MethodVersion
-
-
O
Y
MeasureDetails
MeasureName
-
-
C
C
MeasureDetails
MeasureQualifierCode
-
-
C
C
MeasureDetails
MeasureUnitCode
-
-
C
C
MeasureDetails
MeasureValue
-
-
C
C
DataQual
tylndicatorDetails
Comment
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorConfidencelnterval
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorConfidenceLevel
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorEquation
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorLimitSource
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorLimitType
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorLowerLimit
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorName
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorType
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorUnits
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorUpperLimit
-
-
-
O
DataQual
tylndicatorDetails
Qual
tylndicatorValue
-
-
-
O
Total Required:
15
18
29
38
Total Conditionally Required:
2
6
22
54
Total Optional:
2
9
48
163
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
51
-------
Requirements for ERLN Data Submissions
B.4.1 Example Measurements
ERLN DET allows laboratories to report any number of measures by using the MeasureDetails Data
Group. The following list is a list of typical measures names that a laboratory may provide and
suggestions regarding what information the measure should be provided for (Data Group). Each of the
measures listed here can have additional attributes such as units and value which should be reported using
the data elements available in the MeasureDetails Data Group. For example AmountAdded would be
reported in ERLN by populating the MeasureName data element with "Added Amount" and the
Measure Value data element with the actual value.
Table 10. Examples of Measurements Possible with the MeasureDetails Data Group
Measure Name
Applicable Data Groups
Added Amount
SubstanceldentificationDetails
Added Amount Step
SubstanceldentificationDetails
Aliquot Amount
AnalysisDetails, SamplePreparationDetails
Analysis Duration
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyzed Amount
AnalysisDetails
Bias Error Ratio
SubstanceldentificationDetails,
InstrumentResponseDetails
Calibration Factor
SubstanceldentificationDetails,
InstrumentResponseDetails
CoefficientaO
SubstanceldentificationDetails,
InstrumentResponseDetails
Coefficiental
SubstanceldentificationDetails,
InstrumentResponseDetails
Coefficienta2
SubstanceldentificationDetails,
InstrumentResponseDetails
Coefficienta3
SubstanceldentificationDetails,
InstrumentResponseDetails
Column Internal Diameter
AnalysisDetails, SamplePreparationDetails
Column Length
AnalysisDetails, SamplePreparationDetails
Correction Factor
AnalysisDetails, SamplePreparationDetails
Correlation Coefficient
SubstanceldentificationDetails,
InstrumentResponseDetails
Countinq Error
SubstanceldentificationDetails,
InstrumentResponseDetails
Counts
AnalysisDetails, InstrumentResponseDetails
Difference Error Ratio
SubstanceldentificationDetails,
InstrumentResponseDetails
Dilution Factor
AnalysisDetails
Drift
AnalysisDetails, InstrumentResponseDetails
Efficiency
SamplePreparationDetails, AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails
Enerqy
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Filter Size
SampleDetails, SampleHandlingDetails,
SamplePreparationDetails, AnalysisDetails
Final Amount
SamplePreparationDetails, AnalysisDetails
Flow Rate
AnalysisDetails
Frequency
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Gradient
AnalysisDetails
Handlinq Duration
SampleHandlinqDetails
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
52
-------
Requirements for ERLN Data Submissions
Measure Name
Applicable Data Groups
Handling Factor
SampleHandlingDetails
Initial Amount
SampleHandlingDetails, SamplePreparationDetails
Injection Volume
AnalysisDetails
SubstanceldentificationDetails,
Mass
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Mass Charge Ratio
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Mean Calibration Factor
InstrumentResponseDetails
Mean Relative Response
SubstanceldentificationDetails
SubstanceldentificationDetails,
Mean Relative Response Factor
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Mean Retention Time
InstrumentResponseDetails
Number Of Dilutions
AnalysisDetails
Organism Length
SampleDetails
Peak Ratio
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Percent Match
SubstanceldentificationDetails
SubstanceldentificationDetails,
Percent Breakdown
InstrumentResponseDetails
SubstanceldentificationDetails,
Percent Difference
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Percent Recovery
InstrumentResponseDetails
SubstanceldentificationDetails,
Percent Relative Standard Deviation
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Percent Valley
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Quench
AnalysisDetails
Relative Response
SubstanceldentificationDetails
SubstanceldentificationDetails,
Relative Response Factor
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Relative Retention Time
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Relative Percent Difference
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Relative Retention Time
InstrumentResponseDetails
Resolution
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Resolution Basis
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Response
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
Retention Time
InstrumentResponseDetails
Sample Amount
SampleDetails, SampleHandlingDetails,
SamplePreparationDetails, AnalysisDetails
Screen Result
SampleDetails
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
53
-------
Requirements for ERLN Data Submissions
Measure Name
Applicable Data Groups
Siqnal To Noise Ratio
SubstanceldentificationDetails,
InstrumentResponseDetails
Standard Concentration
SubstanceldentificationDetails
Standard Final Amount
SubstanceldentificationDetails
Standard Deviation
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Tailinq Factor
SubstanceldentificationDetails,
InstrumentResponseDetails
Wavelength
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Weiqhtinq Factor Type
SubstanceldentificationDetails,
InstrumentResponseDetails
Yield
AnalysisDetails
B.4.2 Example Characteristics
ERLN DET allows laboratories to report any number of characteristics by using the Characteristic Details
Data Group. The following is a list of typical characteristics that a laboratory should provide.
• Artifacts
• Boiling Point
• Clarity
• Color
• Column Diameter
• Column Length
• Conductance
• Density
• Melting Point
• Odor
• Percent Lipids
• Percent Moisture
• Percent Phase
• Percent Solids
• pH
• Refractive Index
• Temperature
• Texture
• Turbidity
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
54
-------
Requirements for ERLN Data Submissions
£3.4.4 DET Data Element Definitions
The following list provides definitions, the intended reporting format, and categorization for each data
element within the ERLN DET.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
55
-------
Requirements for ERLN Data Submissions
Table 11. ERLN DET Data Element Definitions
Data Element
Format
Category
Business Rule
Definition
AdditionalResponseldentifier
Text
Identification
A laboratory-defined identifier that identifies a
single peak measurement from a series of
replicate measurements.
AgreementModificationDescription
Text
Description
Text that describes any modifications made to
the laboratory's contract.
AgreementModification Identifier
Text
Description
A client-defined identifier for any modifications
made to the laboratory's contract.
AgreementNumber
Text
Identification
A client-defined contract number that specifies
the contract or agreement under which the
laboratory analyzes the samples.
AlternateLaboratoryAnalysisldentifier
Text
Identification
An alternate laboratory identifier for an analysis.
AlternateLaboratorySampleldentifier
Text
Identification
An alternate laboratory identifier for a sample.
AnalysisBatch Identifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple analyses done on one instrument,
associated with one or more instrument quality
control samples, at which the instrument is
checked to be in control at the beginning of an
analysis sequence.
AnalysisEndBatchldentifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple analyses done on one instrument,
associated with one or more instrument quality
control samples, at which the instrument is
checked to be in control at the end of the
analysis sequence.
AnalysisEndDate
Date
Date
The date (and time, if required) of the end of the
analysis period, if the sample aliquot or standard
was analyzed over a period of time.
AnalysisGroupldentifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple analyses performed on a single
instrument to generate a single substance result
that is dependent upon each individual analysis.
AnalysisReguestldentifier
Text
Identification
A client-defined identifier for the paperwork that
authorizes the analyses of specific samples by
listed methods.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
56
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
AnalysisStartDate
Date
Date
The date (and time, if required) of analysis of a
sample aliquot or standard. If analyzed over a
ranqe of dates, this is the start date.
AnalysisType
Limited List
Categorization
A term used to define the type of analysis (e.g.,
initial, confirmation, MSA). This term is also
used to uniquely identify a single analysis from
multiple analyses that are used to generate a
single result.
AnalyticalServiceRequestldentifier
Text
Identification
A client-defined number or identifier that
specifies the service request.
Apparatusldentifier
Text
Identification
The laboratory-defined identifier for the analytical
system used to process the sample or aliquot.
Autosamplerlndicator
Boolean
Indicator/Boolean
Indicates whether or not an autosampler was
used.
BackgroundCorrection Indicator
Boolean
Indicator/Boolean
Indicates whether or not background correction
was done.
BackgroundRawDatalndicator
Boolean
Indicator/Boolean
Indicates whether or not background raw data
was generated when background correction was
done.
BackgroundType
Limited List
Categorization
The type of background correction performed
during an analysis.
Billingldentifier
Text
Identification
A client-defined identifier to submit with the data
for billing purposes.
Bottleldentifier
Text
Identification
An identifier for the container containing the
sample being analyzed.
BottleType
Limited List
Categorization
The size and type of container used to contain
the sample.
CalibrationBasisldentifier
Text
Identification
The node (substance or Peak) that contains the
calibration information for a given substance.
CalibrationType
Limited List
Categorization
The calibration model used (for a particular
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
57
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
substance or peak) to define the initial calibration
curve for a method.
CASRegistryNumber
Text
Identification
The Chemical Abstract Service (CAS) registry
number for a substance.
CharacteristicName
Text
Description
A descriptive term used to identify the
characteristic being measured.
CharacteristicType
Text
Categorization
A term that identifies the type of characteristic
being reported.
CharacteristicUnits
Limited List
Categorization
Units for the value of a characteristic.
CharacteristicValue
A measured or observed value for the
characteristic being reported. The value can
either be numeric or text based on the
characteristic being reported.
CleanupBatch Identifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple sample aliquots that are cleaned up
together for processing by one method.
CleanUpEndDate
Date
Date
The date (and time, if required), of the end of the
cleanup period, if the sample aliquot was
cleaned up over a period of time.
Cleanupldentifier
Text
Identification
A laboratory-defined identifier for this cleanup
event for this aliquot.
CleanUpStartDate
Date
Date
The date (and time, if required) of any cleanup
procedure performed on the sample aliquot. If
cleaned up over a range of dates, this is the start
date.
CleanupType
Limited List
Categorization
A term that identifies the specific cleanup
performed when multiple options are given within
the referenced method.
ClientAnalysisldentifier
Text
Identification
A client-defined identifier for an analysis.
ClientSampleldentifier
Text
Identification
A client-defined identifier that uniquely identifies
a single sample that is subjected to an analysis.
ClientSubstanceldentifier
Text
Identification
A client-defined identifier for a substance.
ClientSubstanceName
Text
Description
A client-defined common name for a substance.
Column
Text
Description
The name or type of the column or cartridge
used by this method.
Comment
Text
Comment
A free-form remark, observation, explanation, or
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
58
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
expansion text that can occur in any parent data
element.
Compositelndicator
Boolean
Indicator/Boolean
Indicates whether or not the sample as received
by the laboratory is a composite.
ConfirmationAnalysisldentifier
Text
Identification
A laboratory-defined identifier for an analysis that
confirms the results of this analysis. Final results
are usually reported for a method from the
primary analysis.
ContactElectronicAddress
Text
Description
The electronic address (e-mail) of the person at
the laboratory who takes final responsibility for
the data.
ContactFullName
Text
Description
The person at the laboratory who takes final
responsibility for the data.
Contactldentifier
Text
Identification
Identifier shall be
used as the
relational key for
data groups to
reference a
particular contact.
A laboratory-defined unique identifier for an
individual within an organization.
ContactTitle
Text
Description
The job title of the person at the laboratory who
takes final responsibility for the data.
ContactType
Limited List
Categorization
The type of the person at the laboratory who
takes final responsibility for the data.
Coolerldentifier
Text
Identification
A client-defined unique identifier for the cooler or
other shipping container used to transport the
sample to the laboratory.
CreatedDate
Date
Date
The date (and time, if required) a Quality Control
(QC) sample was generated or derived in the
laboratory.
DataExchangeTemplateldentifier
Text
Identification
An identifier that specifies the format of an
electronic data deliverable.
Data ExchangeTemplatelmplementation Identifier
Text
Identification
An identifier that identifies the specific
implementation (Document Type Definition or
Schema) of an electronic data deliverable.
DataExchangeTemplatelmplementationVersion
Text
Description
A value that identifies the version of the specific
implementation (Document Type Definition or
Schema) of an electronic data deliverable.
DataExchangeT emplateVersion
Text
Description
A value that specifies the version of the format of
an electronic data deliverable.
DataPackageldentifier
Text
Identification
A laboratory-defined identifier for this data
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
59
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
deliverable package. This identifier applies to a
single deliverable.
DataPackageName
Text
Description
A laboratory-defined title for this data deliverable
package.
DataPackageVersion
Text
Description
If the laboratory resubmits a data package, this
data element distinguishes between the different
versions.
DateFormat
Text
Description
A value that specifies the format of all reported
date/time values in an electronic data
deliverable. This value can incorporate the time
zone, if required.
Detectorldentifier
Text
Identification
A laboratory-defined unique identifier for a
specific detector.
DetectorType
Limited List
Categorization
The type of detector used in the instrumental
analysis.
Exclusionlndicator
Boolean
Indicator/Boolean
Only report a
value when not
included.
Indicates whether or not this item is to be
excluded or evaluated as part of this data
packaqe.
ExpectedResult
Text
Result Measurement
The expected or theoretical result of a substance
that has been spiked into a sample aliquot or a
standard at any time durinq the analysis process.
ExpectedResultUnits
Limited List
Result Measurement
Units for the expected result.
FieldEquipmentBatch Identifier
Text
Association/Grouping
An identifier that is used to link multiple samples
collected using the same equipment in a defined
period of time. Operationally, this batch
associates a field equipment blank with a group
of samples.
Filteredlndicator
Boolean
Indicator/Boolean
Indicates whether or not the sample as received
by the laboratory was field filtered.
GeneratingSystemldentifier
Text
Identification
A laboratory-defined identifier that names the
software system used to generate an electronic
data deliverable. This identifier may be built into
commercial software.
GeneratingSystemVersion
Text
Description
A laboratory-defined version number of the
software system used to generate an electronic
data deliverable.
HandlingBatch Identifier
Text
Association/Grouping
An identifier that is used to link multiple samples
that are handled together. Together can imply
similarity of time, place, and manner of handling.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
60
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
HandlingEndDate
Date
Date
The date (and time, if required) of the end of the
handling period of the sample, if the sample was
handled over a period of time.
Handlingldentifier
Text
Identification
A laboratory-defined identifier for this handling
event for this sample.
HandlingStartDate
Date
Date
The date (and time, if required) of handling of
this sample. If handled over a range of dates,
this is the start date.
HandlingType
Limited List
Categorization
A client-defined term that identifies the specific
type of preliminary processing done to a sample,
prior to aliquotting, when multiple options are
given within the referenced method or when no
referenced method is available.
HeatedPurgelndicator
Boolean
Indicator/Boolean
Indicates whether or not a heated purge was
used forvolatiles analysis.
Instrumentldentifier
Text
Identification
A laboratory-defined identifier for an instrument.
InstrumentQualityControlSampleldentifier
Text
Identification
A laboratory-defined identifier that uniquely
identifies a single instrument Quality Control
(QC) analysis or group of analyses.
InstrumentReponseldentifier
Text
Identification
A laboratory-defined identifier that identifies a
peak associated with a substance. Its value
should be unique among all peaks for one
substance within a run sequence, but not
necessarily have physical meaning.
InstrumentResponseTypeName
Text
Description
Defines the instrument response being recorded.
Example: Peak
InstrumentSerialNumber
Text
Identification
The serial number of the instrument used for this
analysis.
InterelementCorrection Indicator
Boolean
Indicator/Boolean
Indicates whether or not Inductively Coupled
Plasma (ICP) interelement or intersubstance
correction factors were applied.
IntermediateResult
Text
Result Measurement
The results of this analysis, not for a method,
and would normally not include sample aliquot,
dilution or other sample information. This value
is normally the result obtained directly from a
calibration curve.
IntermediateResultUncertainty
Numeric
Result Measurement
The estimated amount, expressed as a
symmetric interval centered on the
IntermediatResult, by which the
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
61
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
IntermediateResult may differ from the true value
due to all effects related to analysis by the
laboratory.
IntermediateResultUnits
Limited List
Result Measurement
Units for an intermediate result.
LaboratoryAnalysisldentifier
Text
Identification
A laboratory-defined identifier for an analysis that
uniquely identifies a single run for a single
sample aliquot or standard. This identifier must
be unique for at least all of the analyses reported
in a single deliverable, in the context of one
method.
LaboratoryFileldentifier
Text
Identification
The file, and path if required, name where the
raw data from the analysis is stored in the
laboratory.
LaboratoryNarrative
Text
Description
A laboratory textual account that describes any
appropriate information about anomalies that
may have occurred during the analysis or review
of the data in the electronic data deliverable.
LaboratoryQualifiersDefinition
Text
Description
A formal statement of the meaning or
significance of any lab qualifier(s) reported by the
laboratory.
LaboratoryReceiptDate
Date
Date
The date (and time, if required) that the sample
was received in the laboratory.
LaboratoryReportedDate
Date
Date
The date (and time, if required) that the data
package was reported by the laboratory to the
client.
LaboratoryReportingBatch Identifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple samples reported as a group by the
laboratory. In addition, this batch can be used to
link certain quality control (QC) samples to field
samples.
LaboratoryResultQualifier
Text
Description
A laboratory-assigned string of result qualifiers
(usually a single character for each qualifier),
based on client -defined rules and values.
LaboratoryResultStatus
Text
Description
A laboratory-assigned state or condition for the
results of a particular sample and method.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
62
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
LaboratorySampleldentifier
Text
Identification
A laboratory-defined identifier that uniquely
identifies a single sample that is subjected to an
analysis. The Laboratory Identifier should only be
reported in addition to the Sample Identifier.
LaboratorySubstanceldentifier
Text
Identification
A laboratory-defined identifier for a substance.
LaboratoryType
Limited List
Categorization
Text that describes the laboratory analyzing the
sample.
Locationldentifier
Text
Identification
A client-defined identifier of the sampling location
at a particular site.
LocationName
Text
Description
A client-defined name of the sampling location at
a particular site.
LotNumber
Text
Identification
A manufacturer-assigned batch number for a
substance or other materials used in a particular
analysis.
Manual Integration Indicator
Boolean
Indicator/Boolean
Indicates whether or not manual integration was
used.
MeasureName
Text
Description
Describes the measure being recorded.
MeasureQualifierCode
Text
Description
A code used to identify any qualifying issues that
affect the results.
MeasureUnitCode
Limited List
Categorization
The code that represents the unit for measuring
the item.
MeasureValue
Text
Description
The recorded dimension, capacity, quality, or
amount of something ascertained by measuring
or observing.
MethodBatch Identifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple samples analyzed by one method and
treated as a group for quality control (QC)
purposes. A method batch should group
samples with similar matrices and potential
interferences.
MethodCategory
Limited List
Categorization
The general class or common name for the
group of substances being measured by a given
method for the sample.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
63
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
MethodCodeType
Limited List
Categorization
The published reference code of the method
used by the laboratory to analyze the sample.
MethodDescription
Text
Description
A brief summary that provides general
descriptive information about the method.
Methodldentifier
Text
Identification
Report the
WebEDR Method
Identifier listed on
the Method
Profile.
The published, unique identifier (usually
consisting of numbers or a combination of letters
and numbers) for the method used by the
laboratory to analyze the sample.
MethodLevel
Text
Description
The approximate level of substances in the
sample, usually specified in client-defined
concentration ranges and determined via a
screening procedure.
Method ModificationDescription
Text
Description
Text that identifies any modifications made to the
published reference method.
Method Modification Identifier
Text
Identification
A client-defined identifier that identifies
modifications made to the published reference
method.
MethodName
Text
Description
The published name or title of the method used
by the laboratory to analyze the sample.
MethodSourceName
Text
Description
The author or publishing agency of the method
used by the laboratory to analyze the sample.
MethodType
Limited List
Categorization
Laboratories must
always report the
Client method, all
other methods are
optional.
A term that identifies the technology or method
classification of the method used by the
laboratory to analyze the sample.
MethodVersion
Text
Description
The version or revision of the method used by
the laboratory to analyze the sample.
MobilePhase
Text
Description
The mobile phase composition used for High
Performance Liquid Chromatography (HPLC), or
other similar procedures.
NumberOfBottles
Text
Description
The number of containers received by the
laboratory for this sample analysis.
Organization Identifier
Text
Identification
The identifier associated with an organization
(e.g., laboratory, client, subcontractor, etc.)
performing a specific role in context of the
project.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
64
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
OrganizationLocationAddress
Text
Description
The primary street address of the location of the
laboratory performing this analysis.
Org a n izati o n Locati o n Add ressC ity
Text
Description
The city in which the laboratory performing the
analysis is located.
OrganizationLocationAddressCountry
Text
Description
The country in which the laboratory performing
the analysis is located.
Org a n izati o n Locati o n Add ressState
Text
Description
The state in which the laboratory performing the
analysis is located.
OrganizationLocationAddressZipCode
Text
Description
The ZIP or postal code of the laboratory
performing the analysis.
OrganizationMailingAddress
Text
Description
The secondary address of the laboratory
performing this analysis, if applicable. This
would include additional address information
(e.g., suite, maildrop, etc.).
OrganizationName
Text
Description
The name of an organization (e.g., laboratory,
client, subcontractor, etc.) performing a specific
role in context of the project.
OrganizationTelephoneNumber
Text
Description
The 10-digit telephone number of the laboratory
performing the analysis.
OrganizationType
Text
Categorization
The role of the organization in context of the
project.
OriginalClientSampleldentifier
Text
Identification
The client-defined identifier of the original regular
sample from which the Quality Control (QC)
sample was derived.
OriginalLaboratoryAnalysisldentifier
Text
Identification
The laboratory analysis identifier (LabAnalysisID)
of a previous or original analysis this analysis is
based on.
OriginalLaboratorySampleldentifier
Text
Identification
The laboratory-defined identifier of the original
sample from which the Quality Control (QC)
sample was derived.
PhaseAnalyzed
Text
Description
That portion or fraction of a multiphase sample
that was actually analyzed.
PreparationBatch Identifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple sample aliquots that are prepared
together for analysis by one method. "Together"
implies similarity of time, place, and manner of
preparation.
PreparationEndDate
Date
Date
The date (and times, if required) of the end of the
preparation period for the sample aliquot, if the
sample was prepared over a period of time.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
65
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
Preparationldentifier
Text
Identification
A laboratory-defined identifier for this preparation
event for this sample aliquot.
PreparationStartDate
Date
Date
The date (and time, if required) of the
preparation of this sample aliquot. Preparation is
used generally to include method specific
techniques such as extraction, digestion, and
separation. If prepared over a range of dates,
this is the start date.
PreparationType
Limited List
Categorization
A client-defined description used to define the
specific preparation performed when multiple
options are given within the referenced method.
Preservative
Text
Description
The chemical compound that was added to the
sample to protect against decay or
decomposition.
PreservedBy
Text
Description
The organization that added preservative to the
sample.
Priorityldentifier
Text
Identification
A client-defined term that identifies the priority
assigned to this data. The priority may affect the
desired turnaround time and the cost of the
analysis.
Projectldentifier
Text
Identification
A client-defined identifier for a project reporting a
particular set of data. Typically, a project
consists of samples from one site collected over
some defined period of time.
ProjectName
Text
Description
A descriptive name or label for the project for
which data is being reported for
QualityControlCategory
Limited List
Categorization
A term that identifies the basic properties or
category of a particular method Quality Control
(QC) sample.
QualityControlSampleLinkage
Text
Description
For a Quality Control (QC) sample, specifies
which batch is the basis for the association
between the QC sample and the regular
samples.
Quality IndicatorConfidencelnterval
Numeric
Measurement
The estimated range being calculated from a
given set of sample data.
Quality IndicatorConfidenceLevel
Numeric
Measurement
The probability values associated with a
confidence interval expressed as a percentage.
Quality IndicatorEquation
Text
Description
The name or arithmetic calculation used to
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
66
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
determine the value and or limits of the guality
indicator.
Quality IndicatorLimitSource
Limited List
Categorization
The author or publishing agency of the indicator
used by the laboratory to analyze the sample.
Quality IndicatorLimitType
Limited List
Categorization
The organization or entity that is responsible for
the limit.
Quality IndicatorLowerLimit
Numeric
Measurement
The lowest boundary or limit associated with a
guality indicator measurement.
Quality IndicatorName
Text
Description
The name of the data guality indicator being
measured.
Quality IndicatorType
Limited List
Categorization
A term that identifies the classification of the
guality indicator.
Quality IndicatorUnits
Numeric
Measurement
Units of the guality indicator.
Quality IndicatorUpperLimit
Numeric
Measurement
The uppermost boundary or limit associated with
a guality indicator measurement.
Quality IndicatorValue
Numeric
Measurement
The calculated value of the guality indicator
being measured.
QuantitationBasis
Text
Description
The conditions upon which sample guantitation is
performed (e.g., using internal standards).
Quarantinelndicator
Boolean
Indicator/Boolean
Indicates whether or not the sample, as received
by the laboratory, is to be guarantined.
ReferenceDate
Date
Date
The date (and time, if reguired) used for decay
correction in radiochemical analyses.
ReportingLimit
Text
Description
The reporting limit of the substance being
measured. Reporting limits are defined in terms
of a number below which data is typically
reported as 'not detected' for the substance
being measured.
ReportingLimitType
Limited List
Categorization
A term that identifies how the reporting limit was
determined or reported.
ReportingLimitUnits
Limited List
Categorization
Units for the reporting limit.
Result
Text
Result Measurement
The final calculated result for a substance
accounting for all sample aliguot amounts,
dilutions, moisture determinations, etc
ResultBasis
Text
Description
The basis upon which the final results were
calculated.
ResultUncertainty
Numeric
Result Measurement
The estimated amount, expressed as a
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
67
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
symmetric interval centered on the Result, by
which the Result may differ from the true value
due to all effects related to analysis of the
sample aliguot by the laboratory.
ResultUnits
Limited List
Result Measurement
Units for the result.
RunBatchldentifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple analyses performed on one instrument
and under the control of one initial calibration.
SampleChainofCustody Identifier
Text
Identification
A client-defined identifier for the chain of custody
document and/or tracking record associated with
receipt of this sample in the laboratory.
SampleCollectionEndDate
Date
Date
The date (and time, if reguired), of the end of the
sample collection period, if the sample was
collected over a period of time.
SampleCollectionStartDate
Date
Date
The date (and time, if reguired) the sample was
collected. If the sample was collected over a
range of dates, this is the start date.
SampleDataGroupType
Limited List
Categorization
Whether or not the data in this node is related to
a preparation or cleanup activity.
Sampleldentifier
Text
Identification
Report client
identifier for field
generated
samples and
laboratory
identifier for
laboratory or
instrument
samples.
A unigue identifier assigned to a sample. This
identifier should be what is assigned to the
sample by the client. This element should always
be reported. If reporting a laboratory generated
sample then report the laboratories unigue
identifier for the sample.
SampleMatrix
Limited List
Categorization
An identifier of the general sample substrate or
media.
SampleType
Limited List
Categorization
The client-defined term that identifies the specific
type of sample being analyzed.
SamplingBatch Identifier
Text
Association/Grouping
A sampler-defined identifier that is used to link
multiple samples collected together.
Operationally, this batch associates a field blank
with a group of samples.
ShippingBatch Identifier
Text
Association/Grouping
A sampler-defined identifier that is used to link
multiply samples shipped together, such as in
the same crate, cooler, or ice chest.
Operationally, this batch associates a trip blank
with a group of samples.
Siteldentifier
Text
Identification
A client-defined identifier for the broadly defined
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
68
-------
Requirements for ERLN Data Submissions
Data Element
Format
Category
Business Rule
Definition
site this data is being reported for.
SiteName
Text
Description
A descriptive name for the broadly defined site
this data is being reported for.
Solvent
Text
Description
The substance(s), usually a liquid that was used
to dissolve another liquid, gas or solid during the
extraction of the sample.
Standardldentifier
Text
Identification
A laboratory-defined identifier for a purchased or
laboratory-prepared standard, such as a spiking
material or a calibration standard, used in this
analysis.
StandardSourceName
Text
Description
The origin or manufacturer of a standard used in
this analysis.
StorageBatchldentifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
multiple samples that are stored together in a
defined period of time (e.g., samples stored in
the same refrigerator or freezer).
SubstanceGroupldentifier
Text
Association/Grouping
A laboratory-defined identifier that is used to link
together multiple substances to generate a single
substance result that is dependent upon each
individual substance.
SubstanceName
Limited List
Description
The published reference name for a substance
SubstanceNameContext
Limited List
Description
The published reference source for a
substance's name.
SubstanceType
Limited List
Categorization
A term that identifies the type of substance
reported.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
69
-------
Requirements for ERLN Data Submissions
B.4.5 DET Valid Values
The following list details the values that certain fields are limited to within the DET. Valid values help
ensure that automated processing can occur by providing a common language for important fields.
Laboratories should only report a value in this list when reporting information for the data element that
has a valid value list. Laboratories should use SEDD's valid value list as a reference for all valid values.
Table 12 DET Valid Values
Field
Valid Value
AnalysisType
lnitial_Calibration, Average, MSA, Detection_Limit, Initial,
Confirmation, Final
OrganizationType
Customer, Laboratory, Sampler
SampleDataGroupType
Preparation, Cleanup
Exclusionlndicator
NO
ReportingLimitType
CRRL, MDL, MDL sa, IDL, LOD, LOD sa, Ld, Ld sa,
ML, ML_sa, MRL, MRL_sa, Lc, Lc_sa, LCMRL,
LCMRL sa, LOQ, LOQ sa, Lq, Lq sa, PQL, PQL sa,
EQL, EQL_sa
SubstanceType
Target, Spike, TIC, lnternal_Standard, Surrogate,
System_Monitoring_Compound, Monitor, Tracer,
lnstrument_Performance,
Deuterated_Monitoring_Compound
MethodType
Client, Laboratory, Reference
SampleType
Cleanup_Blank, Duplicate, Field_Blank,
Field_Duplicate, Field_Reagent_Blank, Field_Sample,
lnstrument_Blank, Laboratory_Control_Sample,
Laboratory_Control_Sample_Duplicate,
Laboratory_Duplicate, Laboratory_Fortified_Blank,
Laboratory_Fortified_Blank_Duplicate,
Laboratory_Fortified_Sample_Matrix,
Laboratory_Fortified_Sample_Matrix_Duplicate,
Laboratory_Performance_Check,
Laboratory_Reagent_Blank, Matrix_Spike,
Matrix_Spike_Duplicate, Matrix_Spiking_Solution,
Method_Blank, Method_lnstrument_Blank, Non-
client_Sample, Performance_Evaluation_Sample,
Post_Digestion_Spike, PT_Sample, Reagent_Blank,
Serial_Dilution, Split_Samples, Storage_Blank,
Storage_Blank, Trip_Blank, Baseline,
Continuing_Calibration, Continuing_Calibration_Blank,
Continuing_Calibration_Verifi cation,
Detection_Limit_Check_Standard,
Florisil_Cartridge_Check, GPC_Calibration_Check,
lnitial_Calibration, lnitial_Calibration_Blank,
lnitial_Calibration_Verification,
lnstrument_Performance_Check_PEM,
lnstrument_Performance_Check_Resolution,
lnstrument_Performance_Check_Tune,
lnteranalyte_Correction_Factor,
lnterference_Check_Standard_A,
I nte rfe re n ce_C h ec k_Sta nd a rd_A/B,
Linear_Range_Verification,
Quantitation_Limit_Check_Standard,
ReslopeResolution_Check,
Standard_Reference_Material, Calibration_Blank,
Calibration_Standard,
Continuing_Calibration_Check_Standard,
Continuing Calibration Verification Standard,
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
70
-------
Requirements for ERLN Data Submissions
End Calibration Check Standard,
Initial Calibration Check Standard,
Initial Calibration Standards,
Instrument Performance Check Solution,
Tuning_Solution
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
71
-------
Requirements for ERLN Data Submissions
Appendix C: ERLN XML Reporting Guide
The ERLN Data Exchange Template (DET) specifies the data necessary to include in an ERLN electronic
submission and XML is the format in which Type Two and Three submissions will be provided. The
following guide provides an overview of how the XML can be used to report an ERLN electronic
submission.
XML is a general-purpose text-based markup language maintained by the World Wide Web Consortium
(W3C). It was created to address some of the limitations of HyperText Markup Language (HTML) (the
language used to display information in an Internet browser). XML is "extensible," which means that the
user is able to define elements. XML's purpose is to aid information systems in sharing structured data
and is especially useful for capturing complex data relationships and sharing this among different
software applications. XML is also an open source standard, which means it is readily available and
nonproprietary (which means that it is not the exclusive property of any individual, company, or
organization). Its primary purpose is to facilitate the sharing of structured data across different
information systems, particularly via the Internet.
C.l Characteristics of an Electronic Submission
An electronic submission is a term applied to a form of computer-readable file that contains data
applicable to a programs scope. The file must be written in a common language that computer systems
understand which ERLN defines as XML. An XML document has two levels of correctness: a well-
formed document that conforms to XML syntax rules and a valid document that conforms to acceptable
values.
C. 1.1 Organization of Electronic Submission
An XML-based electronic submission should contain the following information in the order listed below:
1. XML Declaration Line: XML documents should begin with an XML declaration which specifies
the version of XML being used. This should be the first line in the file and conform to the
standard format of declaring the version and encoding of the XML file. The standard format for
reporting this information is . The inclusion of any
characters or spaces not identified above may limit a systems ability to read the XML file.
2. Document Type Declaration Line: Typically the second line in an XML file, it provides the
location of the validation file the XML file will use to verify the file. The standard format for
reporting this information is . The inclusion of any characters (case sensitive) or spaces not
identified above may limit a system's ability to read the XML file.
a. The ERLN Document Type Definition (DTD) is called "ERLN GENERAL 1" and must
be reported in the DTD declaration as defined here.
3. Data Group Lines: Define the beginning of a group of data elements that relate to one another.
The Data Group begins to define a relationship of data within the file. The standard format for
reporting this information begins with an opening tag defined by angled brackets surrounding the
name of a Data Group. Once all data elements for the Data Group have been reported, an
indication must be provided that the Data Group is complete. A closing tag must be provided at
the end of all reported data elements within a group and should be defined by angled brackets and
the name of the data group with a forward slash before it.
a. Example opening tag for a Data Group:
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
72
-------
Requirements for ERLN Data Submissions
b. Example closing tag for a Data Group:
c. Example of Data Group in an XML file:
text
text
text
text
text
text
text
text
< S ampl eldentifi er>text
< S ampl eMatrix>text
< S ampl eTyp e>text
< StorageB atchldentifi er>text
NOTE: It is highly recommended to include leading spaces between opening and closing (start or
end) tags of data elements within a group as well as between Data Groups to help improve the
readability of a file.
4. Data Element Lines: Data Elements, also referred to as tags, are the most common item in an
XML document and are defined by angled brackets surrounding the name of the element. The
name of the element represents the content that will be provided for the element. For example, if
an element name is , one possible content option would be apple. Data Elements can
be empty as well, meaning no data is provided for the element; however, ERLN recommends
excluding empty elements from an XML file in order to limit the size of the file and improve
human readability. Data Elements, like data groups, must have an opening and closing tag. The
opening tag is represented by angled brackets surrounding the element name; the closing tag is
represented by angled brackets surrounding the element name with a forward slash in front of the
name.
a. Example opening tag for a Data Element:
b. Example closing tag for a Data Element:
c. Example of Data Element in an XML file:
Sample Text
C.1.2 XML Syntax Guidelines
An XML file is indicated by the file extension .xml. An XML file uses a tree-based structure, where the
data hierarchy is expressed by the level to which the text is indented. Information about the data is
indicated using text tags. An XML file is entirely made up of text, and can be read using any XML-
capable browser or tool. However, if viewing or editing an XML file is necessary, commercial software
designed for this purpose is available.
XML files must follow a specific structure and syntax so that other systems can read the contents. The
following list provides general syntax rules that must be followed by every XML file:
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
73
-------
Requirements for ERLN Data Submissions
• Non-empty elements are delimited by both a start-tag and an end-tag.
• Empty data elements can be reported and if so shall be indicated by a single tag indicating the
data element name followed by a space and a forward slash and surrounded by angled brackets.
Example:
o The ERLN prefers that empty elements be left out of the file entirely so that only
elements with data are reported.
• Spaces are not allowed between opening and closing tags unless they are part of the data being
reported for the element.
• Data element names are case-sensitive and should be reported as described in the DET.
• Blank lines are allowed and can occur anywhere in the XML document. Blank lines can greatly
improve the human readability factor of an XML file by providing visual separations in the data.
• Comment lines can occur anywhere in the XML document and are used to annotate the XML for
human readers. Comment lines are usually displayed and printed by XML readers as they are not
considered part of the data in the file. Comment lines are defined by angled brackets with the
content surrounded by an exclamation mark and two dashes. Example:
• Data Group and Data Elements names must exist in the DTD. Laboratories can report more data
than required for an ERLN Data Submission Type but the element must exist in the DTD and be
reported in the correct Data Group. Laboratories cannot add new Data Groups or Data Elements
to an XML document.
• Data Elements cannot appear more than once within the same Data Group.
• The ERLN DTD defines a particular order in which fields can be reported. XML files can have
fewer fields than the DTD but they must still appear in the same order. For example, in the
SampleDetails data group the Sampleldentifier element is listed above the SampleMatrix element.
This means that any ERLN XML file that reports Sampleldentifier and SampleMatrix must report
them in this same order.
• The occurrence of a data group and/or data element within a DTD as well as the absence of a
value can be defined in a DTD using XML syntax. The following is a list of syntax used
throughout the ERLN DTD to define how many times a data group can be reported as well as if a
data element requires a value or if a value is optional.
o ? data element or data group is not required and may only appear once under the
parent data group that uses this reference. Example: Under the SampleDetails
data group the SampleChainofCustodyldenifier appears with a ? after it. This
means this element does not have to be reported for this group but if it is it can
only appear once under the SampleDetails group.
o * data element or data group is not required and may appear zero or more times
under the parent data group that uses this reference. Example: The
OrganizationDetails group defines its relationship with the PointofContacts group
with an * meaning one organization can have 0 or more contacts reported under
it.
o + data element or data group is required and can appear more than one time
under the parent data group that uses this reference. Example: The ProjectDetails
group defines its relationship with the SampleDetails group with a +, meaning
the Project must have at least one sample reported but can have more than one.
o No syntax after an element (Ex. Sampleldentifier,) - data element is required,
must contain a value, and can only appear once under the parent data group that
uses this reference.
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
74
-------
Requirements for ERLN Data Submissions
C.1.3 Document Type Definition (DTD)
An XML DTD defines the building blocks of an XML document and is the most common way to specify
an XML document. It defines the document structure with a list of legal elements and attributes. A DTD
defines the structure of the XML document and validates the correctness of a file by providing the
acceptable values for the document. The Staged Electronic Data Deliverable (SEDD) and the ERLN DET
are all examples of exchange templates that use DTDs to validate their correctness. The DTD provides
Laboratories with an idea as to what their XML documents will be validated against but the ERLN DET
template describes what should be reported. See Appendix F: Environmental Response Laboratory
Network (ERLN) Document Type Definition (DTD).
C.2 ERLN DTD Overview
The ERLN DTD represents a technical implementation of the ERLN DET based on the programs current
capabilities for processing data, data necessary for data users to perform a thorough review, and data
required by measurement quality objectives necessary for a Level 2 review as defined by the Guidance
for Labeling Externally Validated Laboratory Analytical Data for Superfund Use, July 2008.
By basing DTD's on technical implementations the ERLN is able to ensure that future DTD versions are
expandable with minimal impact to the overall data hierarchy of the program. The ERLN is currently
capable of processing Type 2 submissions. The ERLN DTD is therefore based on Type 2 submissions. A
DTD for Type 3 submission is in draft format and is provided for review and comment.
C.2.2 ERLN Data Hierarchy for Reporting
The ERLN DET defines the Data Groups that organize the individual elements into groupings that define
the data. These grouping have inherent relationships and must be reported in a certain order to maintain
the relationship in the XML document. The ERLN DET uses a hierarchical relationship between most
data groups, with the exception of Contact Information which has a relational relationship to several data
groups. A hierarchical relationship means the placement of the data groups and data elements in the XML
document defines the relationship of the content. A 'relational' relationship provides the ability to
reference another data group by providing some form of an identifier, similar to how foreign keys in a
database table function. Refer to Appendix B: Environmental Response Laboratory Network (ERLN) Data
Exchange Template (DET) for additional information regarding these groups.
In a DTD that primarily uses hierarchical relationships, there is a defined order in which Data Groups can
be reported in a file. See Section 3.4 ERLN Data Organization for an overview of data groups. The
following depicts the order in which data groups must be reported in an ERLN XML document. The data
groups that appear as subs to the primary level can be reported in any order as long as they are under their
associated data group.
Type 2 Data Group Reporting Hierarchy:
1. ProjectDetails
2. OrganizationDetails
a. PointOfContactDetails
3. MethodDetails
4. SampleDetails
a. AnalysisDetails
i. SamplePreparationDetails
ii. SubstanceldentificationDetails
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy
75
-------
Requirements for ERLN Data Submissions
1. MeasureDetails
b. CharacteristicDetails
Type 3 Data Group Reporting Hierarchy:
1. ProjectDetails
2. OrganizationDetails
a. PointofContactDetails
3. MethodDetails
4. SampleDetails
a. AnalysisDetails
i. CharacteristicDetails
ii. SamplePreparationDetails
1. CharacteristicDetails
2. MeasureDetails
a. DataQualitylndicatorDetails
iii. SubstanceldentificationDetails
1. InstrumentResponseDetails
a. InstrumentResponseAdditionalDetails
i. MeasureDetails
1. DataQualitylndicatorDetails
2. MeasureDetails
a. DataQualitylndicatorDetails
iv. MeasureDetails
1. DataQualitylndicatorDetails
b. CharacteristicDetails
c. MeasureDetails
i. DataQualitylndicatorDetails
d. SampleHandlingDetails
i. CharacteristicDetails
ii. MeasureDetails
1. DataQualitylndicatorDetails
C.3 ERLN DTD Required Data Elements
The ERLN DTD has defined a minimum list of required data element based on required elements defined
in the ERLN DET for Type 1. By defining required fields in the DTD ERLN can ensure that data
submitted contains the minimum amount of information necessary to identify the submission before they
file is processed. Required elements are defined in the DTD by the lack of a character following a data
element (Example: Sampleldentifier,). The following is a list of the ERLN DTD required fields, a value
must be present in every instance of these fields in order for a submission to successfully be uploaded into
WebEDR.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
76
-------
Requirements for ERLN Data Submissions
Table 13 DTD Required Data Groups
ERLN Data Group
ERLN Data Element
ProjectDetails
AnalyticalServiceRequestldentifier
ProiectDetails
DataPackageldentifier
ProiectDetails
Projectldentifier
OrganizationDetails
Organization Identifier
SampleDetails
Sampleldentifier
SampleDetails
SampleMatrix
AnalysisDetails
Method Identifier
SubstanceldentificationDetails
SubstanceName
MethodDetails
Methodldentifier
The ERLN DTD also defines required data elements when reporting optional data groups. The following
list defines the conditionally required data elements defined in the ERLN DTD.
Table 14 DTD Conditionally Required
ERLN Data Group
ERLN Data Element
PointofContactDetails
Contactldentifier
CharacteristicDetails
CharacteristicName
CharacteristicDetails
CharacteristicValue
MeasureDetails
MeasureName
MeasureDetails
MeasureValue
C.4 XML Tools
XML is one of the most popular languages used for communicating data among information systems and
because of this a plethora of tools exist to assist people in the process of generating a well-formed XML
file from an in-house database and/or reading a file. Many Laboratory Information Management Systems
(LIMS) manufacturers provide this functionality as part of their system. Many of the tools available on
the market provide a mapping tool that allows a user to point and click to where data is located and map it
to a DTD and will generate a complete XML file based on this mapping. A laboratory must decide what,
if any, tools are necessary for their business needs.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
77
-------
Requirements for ERLN Data Submissions
Appendix D: Using the SEDD to Report ERLN Data
The SEDD Specification 5.2 is a set of business rules and data tags that can be used as a method to deliver
data requirement from a hierarchal Data Exchange Template (DET) in extensible Markup Language
(XML) format for the exchange of environmental analytical data. It is flexible in that it can satisfy diverse
customer requirements. Since SEDD's business rules were modeled on laboratory activities, it facilitates
generating XML files that can be created by a laboratory's Laboratory Information Management System
(LIMS). As data users require more supporting data, additional data elements can be added to the file.
One of the major advantages for both data users and laboratories is that SEDD can be implemented in
stages. These stages include:
• Stage 1 - A minimal number of data to report the results of analysis of field samples ONLY
• Stage 2a - Results PLUS some method-related quality control data
• Stage 2b - Results, method-related quality control data PLUS instrument quality control data
• Stage 3 - Results, method-related and instrument quality control data PLUS additional
measurement data to allow for independent recalculation of reported results, method-related and
instrument quality control data
SEDD Stage 4 is currently under development and will include results, method-related and instrument
quality control data, and additional measurement data to allow for independent recalculation PLUS raw
instrument data files.
D.l How Does SEDD Work?
SEDD is based on the use of XML format data files and Data Type Definitions (DTDs) that enforce the
data formats used within the XML. XML is a descendant of HyperText Markup Language (HTML) that
provides a language with greater flexibly to create user-defined tags to structure, store, and send
information. XML provides a more accurate and adaptable way to share data within a structured format
through the Web. The standards for XML are maintained by the World Wide Web Consortium (W3C)
and are open-source, which means that they are non-proprietary and open to anyone who wishes to use
them. This allows XML files to be created and used without the payment of licensing fees or proprietary
software, allowing the U.S. Environmental Protection Agency (EPA) to distribute the data to a wide
audience.
XML also provides the ability to enforce standard formats for data. There are two ways that XML
enforces data formats: DTDs (which SEDD uses) and XML Schemas. DTDs and XML Schemas both
provide descriptions of document structures. An XML DTD defines both the building blocks of an XML
document and the document structure with a list of legal elements and attributes. A DTD can be declared
inside an XML document, or as an external reference for the XML to be validated against to ensure the
XML meets a defined data structure. Like a DTD, an XML Schema defines the legal elements and
attributes for an XML document. In addition, it further controls the values by allowing the user to assign
data elements a specific data type.
XML editing applications can use DTDs and XML Schemas as frameworks, letting users create
documents that meet these expectations. Similarly, developers can use DTDs and XML Schemas as a
foundation on which to plan transformations from one format to another.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
78
-------
D.2 What is the Basic SEDD Hierarchy?
Requirements for ERLN Data Submissions
SEDD requires certain business rules in order to enforce its hierarchal structure. These business rules help
establish the basis for staged implementations of SEDD. One of the primary rules determines how data
are grouped together. Each data group contains multiple elements to describe the data contained within
the group. These data elements may be single elements or another data group. For example, an analysis
may require the measurement of many analytes. The data associated with each separate analyte becomes a
data element in the analysis data group. The data elements in the analyte data group uniquely identify the
measurement of each analyte. By maintaining this hierarchy, data relations are maintained and are
enforced by the file's structure. This allows laboratories to meet Electronic Data Deliverable (EDD)
requirements for multiple programs without having to overhaul their EDD-producing systems as agency
or program needs change.
D.3 Us ing SEDD for ERLN Reporting
The ERLN DET established the scope of data that must be reported for each type of submission as well as
the actual XML tag that should be used for the submission. The DET for ERLN focused on using tags
that are compliant with EPA data standards and organizing data in a way that would lead the community
to an eventual use of a XML Schema. However, the scope of data is essentially the same since each was
modeled on laboratory activities; the main difference is the syntax. If a laboratory is currently capable of
producing SEDD files they can also provide ERLN data using SEDD-based XML files. ERLN
submission types can be loosely related to the SEDD stages in the sense that the stages can provide the
information necessary for the ERLN types.
D.3.1 Differences between SEDD and ERLN DET
The main differences between SEDD and ERLN relate to the high-level concepts applied to the ERLN
DET. ERLN approached similar data elements a bit differently than SEDD by introducing the
Environmental Sampling, Analysis, and Results (ESAR) system of handling methods and measures.
Moreover, ERLN removed some of SEDD's grouping nodes and replaced them with individual fields in a
data group. In addition to the change made in the overall organization of the ERLN DET, ERLN's data
element tags and naming conventions are different due to the incorporation of ESAR standards.
Laboratories can use SEDD as a way to report ERLN Electronic Submissions as the SEDD stages are
very similar to the ERLN Types. A mapping has been provided below to assist laboratories in generating
an ERLN file using SEDD.
D.4 ERLN DET SEDD Mapping
The following table provides the SEDD data group and tag for every Required, Conditionally Required,
Optional, or Not required field in the ERLN DET. This mapping will provide laboratories with the
information necessary to report ERLN data using SEDD.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
79
-------
Requirements for ERLN Data Submissions
Table 15. ERLN DET - SEDD Mapping
ERLN Data Group
ERLN Data Element
SEDD Node
SEDD Data Element
ProjectDetails
AgreementModificationDescription
Header
LabContractModificationDescription
ProjectDetails
AgreementModification Identifier
Header
LabContractModificationID
ProjectDetails
AgreementNumber
Header
LabContract
ProjectDetails
AnalyticalServiceRequestldentifier
Header
Comment
ProjectDetails
Comment
Header
Comment
ProjectDetails
DataExchangeTemplateldentifier
Header
EDDID
ProjectDetails
DataExchangeTemplatelmplementation Identifier
Header
EDDI implementation ID
ProjectDetails
DataExchangeTemplatelmplementationVersion
Header
EDDImplementationVersion
ProjectDetails
DataExchangeT emplateVersion
Header
EDDVersion
ProjectDetails
DataPackageldentifier
Header
LabDataPackagelD
ProjectDetails
DataPackageName
Header
LabDataPackageName
ProjectDetails
DataPackageVersion
Header
LabDataPackageVersion
ProjectDetails
DateFormat
Header
DateFormat
ProjectDetails
GeneratingSystemldentifier
Header
GeneratingSystemID
ProjectDetails
GeneratingSystemVersion
Header
GeneratingSystemVersion
ProjectDetails
LaboratoryNarrative
Header
LabNarrative
ProjectDetails
LaboratoryQualifiersDefinition
Header
LabQualifiersDefinition
ProjectDetails
LaboratoryReportedDate
Header
LabReportedDate
ProjectDetails
Organization Identifier
Header
LabID
ProjectDetails
Projectldentifier
Header
ProjectID
ProjectDetails
ProjectName
Header
ProjectName
ProjectDetails
Siteldentifier
Header
SitelD
ProjectDetails
SiteName
Header
SiteName
PointofContactDetails
Comment
Contactlnformation
Comment
PointotContactDetails
ContactElectronicAddress
Contactlnformation
LabPointOfContactElectronicAddress
PointofContactDetails
ContactFullName
Contactlnformation
LabPointOfContact
PointofContactDetails
ContactTitle
Contactlnformation
LabPointOfContactTitle
PointofContactDetails
ContactType
Contactlnformation
LabPointOfContactType
PointofContactDetails
Organization Identifier
Contactlnformation
LabID
PointofContactDetails
OrganizationLocationAddress
Contactlnformation
LabAddressI
PointofContactDetails
OrganizationLocationAddressCity
Contactlnformation
LabCity
PointofContactDetails
OrganizationLocationAddressCountry
Contactlnformation
LabCountry
PointofContactDetails
OrganizationLocationAddressState
Contactlnformation
LabState
PointofContactDetails
OrganizationLocationAddressZipCode
Contactlnformation
LabZipCode
PointofContactDetails
OrganizationMailingAddress
Contactlnformation
LabAddress2
PointofContactDetails
OrganizationName
Contactlnformation
LabName
PointofContactDetails
OrganizationTelephoneNumber
Contactlnformation
LabTelephoneNumber
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
80
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
SEDD Node
SEDD Data Element
PointofContactDetails
OrganizationType
Contactlnformation
LabType
SampleDetai
s
AlternateLaboratorySampleldentifier
SamplePlusMethod
AlternateLabSamplelD
SampleDetai
s
AnalysisRequestldentitier
SamplePlusMethod
AnalysisRequestID
SampleDetai
s
Billing Identifier
SamplePlusMethod
BillingID
SampleDetai
s
Bottleldentifier
SamplePlusMethod
BottlelD
SampleDetai
s
BottleType
SamplePlusMethod
BottleType
SampleDetai
s
Sampleldentifier
SamplePlusMethod
ClientSamplelD
SampleDetai
s
Comment
SamplePlusMethod
Comment
SampleDetai
s
Compositelndicator
SamplePlusMethod
Composite
SampleDetai
s
Coolerldentifier
SamplePlusMethod
CoolerlD
SampleDetai
s
CreatedDate
SamplePlusMethod
CreatedDate
SampleDetai
s
FieldEquipmentBatch Identifier
SamplePlusMethod
EquipmentBatch
SampleDetai
s
Sampleldentifier
SamplePlusMethod
FieldSamplelD
SampleDetai
s
Filteredlndicator
SamplePlusMethod
Filtered
SampleDetai
s
LaboratorySampleldentifier
InstrumentQC
LablnstrumentQCID
SampleDetai
s
LaboratoryReceiptDate
SamplePlusMethod
LabReceiptDate
SampleDetai
s
LaboratoryReportingBatch Identifier
SamplePlusMethod
LabReportingBatch
SampleDetai
s
LaboratorySampleldentifier
SamplePlusMethod
LabSamplelD
SampleDetai
s
LaboratoryType
SamplePlusMethod
LabType
SampleDetai
s
Locationldentifier
SamplePlusMethod
LocationID
SampleDetai
s
LocationName
SamplePlusMethod
LocationName
SampleDetai
s
MethodBatch Identifier
SamplePlusMethod
MethodBatch
SampleDetai
s
NumberOfBottles
SamplePlusMethod
Bottles
SampleDetai
s
OriginalClientSampleldentifier
SamplePlusMethod
OriginalClientSamplelD
SampleDetai
s
OriginalLaboratorySampleldentifier
SamplePlusMethod
OriginalLabSamplelD
SampleDetai
s
PhaseAnalyzed
SamplePlusMethod
PhaseAnalyzed
SampleDetai
s
Preservative
SamplePlusMethod
Preservative
SampleDetai
s
PreservedBy
SamplePlusMethod
PreservedBy
SampleDetai
s
Priorityldentifier
SamplePlusMethod
PrioritylD
SampleDetai
s
QualityControlCategory
SamplePlusMethod
QCCategory
SampleDetai
s
QualityControlSampleLinkage
SamplePlusMethod
QCLinkage
SampleDetai
s
Quarantinelndicator
SamplePlusMethod
Quarantine
SampleDetai
s
SampleChainofCustody Identifier
SamplePlusMethod
CustodylD
SampleDetai
s
SampleCollectionEndDate
SamplePlusMethod
CollectedEndDate
SampleDetai
s
SampleCollectionStartDate
SamplePlusMethod
CollectedDate
SampleDetai
s
SampleMatrix
SamplePlusMethod
MatrixlD
SampleDetai
s
SampleMatrixMediumType
SamplePlusMethod
MatrixMedium
SampleDetai
s
SampleType
SamplePlusMethod
QCType
SampleDetai
s
SamplingBatch Identifier
SamplePlusMethod
SamplingBatch
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
81
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
SEDD Node
SEDD Data Element
SampleDetails
ShippingBatch Identifier
SamplePlusMethod
ShippingBatch
SampleDetails
Siteldentifier
SamplePlusMethod
SitelD
SampleDetails
SiteName
SamplePlusMethod
SiteName
SampleDetails
StorageBatch Identifier
SamplePlusMethod
StorageBatch
SampleDetails
Contactldentifier
SamplePlusMethod
RequestorlD, RequestorName
SampleHandlingDetails
Contactldentifier
Handl
ng
Analyst
SampleHandlingDetails
Apparatusldentifier
Handl
ng
ApparatusID
SampleHandlingDetails
Bottleldentifier
Handl
ng
BottlelD
SampleHandlingDetails
Comment
Handl
ng
Comment
SampleHandlingDetails
HandlingBatch Identifier
Handl
ng
HandlingBatch
SampleHandlingDetails
HandlingEndDate
Handl
ng
HandledEndDate
SampleHandlingDetails
Handlingldentifier
Handl
ng
HandlingID
SampleHandlingDetails
HandlingStartDate
Handl
ng
HandledDate
SampleHandlingDetails
HandlingType
Handl
ng
HandlingType
SampleHandlingDetails
Organization Identifier
Handl
ng
LabID
SampleHandlingDetails
OrganizationName
Handl
ng
LabName
SampleHandlingDetails
SampleMatrix
Handl
ng
MatrixlD
SampleHandlingDetails
SampleMatrixMediumType
Handl
ng
MatrixMedium
AnalysisDetails
Contactldentifier
Analysis
Analyst
AnalysisDetails
AlternateLaboratoryAnalysisldentifier
Analysis
AlternateLabAnalysisID
AnalysisDetails
AnalysisBatch Identifier
Analysis
AnalysisBatch
AnalysisDetails
AnalysisEndBatchldentifier
Analysis
AnalysisBatchEnd
AnalysisDetails
AnalysisEndDate
Analysis
AnalyzedEndDate
AnalysisDetails
AnalysisGroupldentifier
Analysis
AnalysisGroupID
AnalysisDetails
AnalysisStartDate
Analysis
AnalyzedDate
AnalysisDetails
AnalysisType
Analysis
AnalysisType
AnalysisDetails
Apparatusldentifier
Analysis
ApparatusID
AnalysisDetails
Autosamplerlndicator
Analysis
Autosampler
AnalysisDetails
BackgroundCorrection Indicator
Analysis
BackgroundCorrection
AnalysisDetails
BackgroundRawDatalndicator
Analysis
BackgroundRawData
AnalysisDetails
BackgroundType
Analysis
BackgroundType
AnalysisDetails
Bottleldentifier
Analysis
BottlelD
AnalysisDetails
ClientAnalysisldentifier
Analysis
ClientAnalysisID
AnalysisDetails
Column
Analysis
Column
AnalysisDetails
Comment
Analysis
Comment
AnalysisDetails
ConfirmationAnalysisldentifier
Analysis
ConfirmationAnalysisID
AnalysisDetails
Detectorldentifier
Analysis
DetectorlD
AnalysisDetails
DetectorType
Analysis
DetectorType
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
82
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
SEDD Node
SEDD Data Element
AnalysisDetails
Exclusionlndicator
Analysis
Inclusion
AnalysisDetails
HeatedPurgelndicator
Analysis
HeatedPurge
AnalysisDetails
Instrumentldentifier
Analysis
Instruments
AnalysisDetails
InstrumentSerialNumber
Analysis
InstrumentSerialNumber
AnalysisDetails
InterelementCorrection Indicator
Analysis
InterelementCorrection
AnalysisDetails
LaboratoryAnalysisldentifier
Analysis
LabAnalysisID
AnalysisDetails
LaboratoryFileldentifier
Analysis
LabFilelD
AnalysisDetails
MobilePhase
Analysis
MobilePhase
AnalysisDetails
Organization Identifier
Analysis
LabID
AnalysisDetails
OrganizationName
Analysis
LabName
AnalysisDetails
OriginalLaboratoryAnalysisldentifier
Analysis
OriginalLabAnalysisID
AnalysisDetails
PreparationBatch Identifier
Analysis
PreparationBatch
AnalysisDetails
PreparationEndDate
Analysis
PreparedEndDate
AnalysisDetails
PreparationStartDate
Analysis
PreparedDate
AnalysisDetails
PreparationType
Analysis
PreparationType
AnalysisDetails
QuantitationBasis
Analysis
QuantitationBasis
AnalysisDetails
ReferenceDate
Analysis
ReferenceDate
AnalysisDetails
ResultBasis
Analysis
ResultBasis
AnalysisDetails
RunBatchldentifier
Analysis
RunBatch
AnalysisDetails
Standardldentifier
Analysis
StandardID
AnalysisDetails
StandardSourceName
Analysis
StandardSource
SamplePreparationDetai
s
Contactldentifier
PreparationPlusCleanup
Analyst
SamplePreparationDetai
s
Apparatusldentifier
PreparationPlusCleanup
ApparatusID
SamplePreparationDetai
s
Bottleldentifier
PreparationPlusCleanup
BottlelD
SamplePreparationDetai
s
CleanupBatch Identifier
PreparationPlusCleanup
CleanupBatch
SamplePreparationDetai
s
CleanUpEndDate
PreparationPlusCleanup
CleanedUpEndDate
SamplePreparationDetai
s
Cleanupldentifier
PreparationPlusCleanup
CleanupID
SamplePreparationDetai
s
CleanUpStartDate
PreparationPlusCleanup
CleanedUpDate
SamplePreparationDetai
s
CleanupType
PreparationPlusCleanup
CleanupType
SamplePreparationDetai
s
Column
PreparationPlusCleanup
Column
SamplePreparationDetai
s
Comment
PreparationPlusCleanup
Comment
SamplePreparationDetai
s
LaboratoryResultStatus
PreparationPlusCleanup
LabResultStatus
SamplePreparationDetai
s
LotNumber
PreparationPlusCleanup
LotNumber
SamplePreparationDetai
s
Organization Identifier
PreparationPlusCleanup
LabID
SamplePreparationDetai
s
OrganizationName
PreparationPlusCleanup
LabName
SamplePreparationDetai
s
PreparationBatch Identifier
PreparationPlusCleanup
PreparationBatch
SamplePreparationDetai
s
PreparationEndDate
PreparationPlusCleanup
PreparedEndDate
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
83
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
SEDD Node
SEDD Data Element
SamplePreparationDetails
Preparationldentifier
PreparationPlusCleanup
PreparationID
SamplePreparationDetails
PreparationStartDate
PreparationPlusCleanup
PreparedDate
SamplePreparationDetails
PreparationType
PreparationPlusCleanup
PreparationType
SamplePreparationDetails
SampleDataGroupType
PreparationPlusCleanup
PreparationPlusCleanupType
SamplePreparationDetails
SampleMatrix
PreparationPlusCleanup
MatrixlD
SamplePreparationDetails
SampleMatrixMediumType
PreparationPlusCleanup
MatrixMedium
SamplePreparationDetails
Solvent
PreparationPlusCleanup
Solvent
SubstanceldentificationDetails
BackgroundType
Analyte
BackgroundType
SubstanceldentiticationDetails
CalibrationBasisldentifier
Analyte
CalibrationBasis
SubstanceldentificationDetails
CalibrationType
Analyte
CalibrationType
SubstanceldentificationDetails
CASRegistryNumber
Analyte
CASRegistryNumber
SubstanceldentificationDetails
Substanceldentifier
Analyte
ClientAnalytelD
SubstanceldentificationDetails
SubstanceName
Analyte
ClientAnalyteName
SubstanceldentificationDetails
Comment
Analyte
Comment
SubstanceldentificationDetails
Exclusionlndicator
Analyte
Inclusion
SubstanceldentificationDetails
ExpectedResult
Analyte
ExpectedResult
SubstanceldentificationDetails
ExpectedResultUnits
Analyte
ExpectedResultUnits
SubstanceldentificationDetails
IntermediateResult
Analyte
IntermediateResult
SubstanceldentificationDetails
IntermediateResultUncertainty
Analyte
IntermediateResultUncertainty
SubstanceldentificationDetails
IntermediateResultUnits
Analyte
IntermediateResultUnits
SubstanceldentificationDetails
LaboratoryResultQualifier
Analyte
LabQualifiers
SubstanceldentificationDetails
LaboratorySubstanceldentifier
Analyte
LabAnalytelD
SubstanceldentificationDetails
LotNumber
Analyte
LotNumber
SubstanceldentificationDetails
Manual Integration Indicator
Analyte
Manuallntegration
SubstanceldentificationDetails
InstrumentResponseldentifier
Analyte
PeakID
SubstanceldentificationDetails
QuantitationBasis
Analyte
QuantitationBasis
SubstanceldentificationDetails
ReportingLimit
Analyte
ReportingLimit
SubstanceldentificationDetails
ReportingLimitType
Analyte
ReportingLimitType
SubstanceldentificationDetails
ReportingLimitUnits
Analyte
ReportingLimitUnits
SubstanceldentificationDetails
Result
Analyte
Result
SubstanceldentificationDetails
ResultBasis
Not applicable
SubstanceldentificationDetails
ResultUncertainty
Analyte
ResultUncertainty
SubstanceldentificationDetails
ResultUnits
Analyte
ResultUnits
SubstanceldentificationDetails
Standardldentifier
Analyte
StandardID
SubstanceldentificationDetails
StandardSourceName
Analyte
StandardSource
SubstanceldentificationDetails
SubstanceGroupldentifier
Analyte
AnalyteGroupID
SubstanceldentificationDetails
SubstanceName
Analyte
AnalyteName
SubstanceldentificationDetails
SubstanceNameContext
Analyte
AnalyteNameContext
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
84
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
SEDD Node
SEDD Data Element
SubstanceldentificationDetails
SubstanceType
Analyte
AnalyteType
nstrumentResponseDetails
BackgroundType
Peak
BackgroundType
nstrumentResponseDetails
CalibrationType
Peak
CalibrationType
nstrumentResponseDetails
Comment
Peak
Comment
nstrumentResponseDetails
Exclusionlndicator
Peak
Inclusion
nstrumentResponseDetails
InstrumentResponseTypeName
Not applicable
nstrumentResponseDetails
IntermediateResult
Peak
IntermediateResult
nstrumentResponseDetails
IntermediateResultUncertainty
Peak
IntermediateResultUncertainty
nstrumentResponseDetails
IntermediateResultUnits
Peak
IntermediateResultUnits
nstrumentResponseDetails
LaboratoryResultQualifier
Peak
LabQualifiers
nstrumentResponseDetails
Manual Integration Indicator
Peak
Manuallntegration
nstrumentResponseDetails
InstrumentResponseldentifier
Peak
PeakID
nstrumentResponseDetails
ReportingLimit
Peak
ReportingLimit
nstrumentResponseDetails
ReportingLimitType
Peak
ReportingLimitType
nstrumentResponseDetails
ReportingLimitUnits
Peak
ReportingLimitUnits
nstrumentResponseDetails
Result
Peak
Result
nstrumentResponseDetails
ResultBasis
Peak
ResultUnits
nstrumentResponseDetails
ResultUncertainty
Peak
ResultUncertainty
nstrumentResponseDetails
ResultUnits
Peak
ResultUnits
nstrumentResponseAdd
tionalDetai
s
CASRegistryNumber
PeakComparison
CASRegistryNumber
nstrumentResponseAdd
tionalDetai
s
Comment
PeakComparison
Comment
nstrumentResponseAdd
tionalDetai
s
InstrumentResponseTypeName
Not applicable
nstrumentResponseAdd
tionalDetai
s
IntermediateResult
PeakReplicate
IntermediateResult
nstrumentResponseAdd
tionalDetai
s
IntermediateResultUncertainty
PeakReplicate
IntermediateResultUncertainty
nstrumentResponseAdd
tionalDetai
s
IntermediateResultUnits
PeakReplicate
IntermediateResultUnits
nstrumentResponseAdd
tionalDetai
s
LaboratoryResultQualifier
PeakComparison
LabQualifiers
nstrumentResponseAdd
tionalDetai
s
LaboratorySubstanceldentifier
PeakComparison
LabAnalytelD
nstrumentResponseAdd
tionalDetai
s
InstrumentResponseldentifier
PeakComparison
PeakID
nstrumentResponseAdd
tionalDetai
s
AdditionalResponseldentifier
PeakReplicate
PeakReplicatelD
nstrumentResponseAdd
tionalDetai
s
Result
PeakReplicate
Result
nstrumentResponseAdd
tionalDetai
s
ResultBasis
Not applicable
nstrumentResponseAdd
tionalDetai
s
ResultUncertainty
PeakReplicate
ResultUncertainty
nstrumentResponseAdd
tionalDetai
s
ResultUnits
PeakReplicate
ResultUnits
nstrumentResponseAdd
tionalDetai
s
SubstanceName
PeakComparison
AnalyteName
nstrumentResponseAdd
tionalDetai
s
SubstanceNameContext
PeakComparison
AnalyteNameContext
CharacteristicDetails
CharacteristicName
Characteristic
CharacteristicName
CharacteristicDetails
CharacteristicType
Characteristic
CharacteristicType
CharacteristicDetails
CharacteristicUnits
Characteristic
CharacteristicUnits
CharacteristicDetails
CharacteristicValue
Characteristic
CharacteristicValue
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
85
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ERLN Data Element
SEDD Node
SEDD Data Element
CharacteristicDetails
Comment
Characteristic
Comment
MethodDetails
Comment
One of the main differences between ERLN DET and SEDD is
how method information is reported. SEDD reports method
information as data elements in individual nodes based on the
source of the method (Laboratory or Client). To report ERLN
method information using SEDD, a laboratory will need to populate
the MethodDetails data group with the identification information of
a method and populate the MethodIdentifer field in the child
groups with the same value entered in the MethodDetails data
group. Laboratories are required to report all Client methods
(SEDD method fields pre-fixed with "Client"). For example, to
report the method used for an analysis the Laboratory will report
the Method in the MethodDetails group and assign a
Methodldentifier. In the AnalysisDetails group the laboratory will
report the identifier assigned in the Methodldentifier data element.
MethodDetails
MethodCategory
MethodDetails
MethodCodeType
MethodDetails
MethodDescription
MethodDetails
Methodldentifier
MethodDetails
MethodLevel
MethodDetails
MethodModificationDescription
MethodDetails
Method Modification Identifier
MethodDetails
MethodName
MethodDetails
MethodSourceName
MethodDetails
MethodType
MethodDetails
MethodVersion
MeasureDetails
MeasureName
To report ERLN measure information using SEDD, a laboratory
will need to populate the MeasureDetails group with the values
from the individual measure fields in SEDD. Review Section D.4.1
SEDD Measure Mapping below to determine which data elements
to populate in SEDD.
MeasureDetails
MeasureQualifierCode
MeasureDetails
MeasureUnitCode
MeasureDetails
MeasureValue
DataQual
tylndicatorDetails
Comment
Data Quality Indicator information is an ESAR concept the ERLN
DET uses. Review Section D.4.1 SEDD Measure Mapping below
to determine if a SEDD measure correlates to an identified quality
indicator
DataQual
tylndicatorDetails
Qual
tylndicatorConfidencelnterval
DataQual
tylndicatorDetails
Qual
tylndicatorConfidenceLevel
DataQual
tylndicatorDetails
Qual
tylndicatorEquation
DataQual
tylndicatorDetails
Qual
tylndicatorLimitSource
DataQual
tylndicatorDetails
Qual
tylndicatorLimitType
DataQual
tylndicatorDetails
Qual
tylndicatorLowerLimit
DataQual
tylndicatorDetails
Qual
tylndicatorName
DataQual
tylndicatorDetails
Qual
tylndicatorType
DataQual
tylndicatorDetails
Qual
tylndicatorUnits
DataQual
tylndicatorDetails
Qual
tylndicatorUpperLimit
DataQual
tylndicatorDetails
Qual
tylndicatorValue
D.4.1 SEDD Measure Mapping
ERLN DET allows laboratories to report any number of measures by using the MeasureDetails Data Group. In order for ERLN data to be reported using SEDD,
laboratories must determine the applicable SEDD data element for the measure name. The following list is a listing of typical measures names that a laboratory
may provide and suggestions regarding what SEDD node the measure is likely to appear in. Each of the measures list here can have additional attributes such as
units and value which should also be populated using the applicable data elements in SEDD. For example AmountAdded would be reported in ERLN by
populating the MeasureName data element with "Added Amount" and the MeasureValue data element with the actual value.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
86
-------
Requirements for ERLN Data Submissions
Table 16. SEDD Measure Mapping
Measure Name
ERLN Data Groups
Applicable SEDD Node
SEDD Data Element
Added Amount
SubstanceldentificationDetails
Analyte
AmountAdded
Added Amount Step
SubstanceldentificationDetails
Analyte
AmountAddedLocation
Aliquot Amount
AnalysisDetails,
SamplePreparationDetails
Analysis, PreparationPlusCleanup
AliquotAmount
Analysis Duration
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analysis, Analyte, Peak, Peak
Replicate
AnalysisDuration
Analyzed Amount
AnalysisDetails
Analysis
AnalyzedAmount
Bias Error Ratio
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
BiasErrorRatio
Calibration Factor
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
CalibrationFactor
CoefficientaO
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
CoeffaO
Coefficiental
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
Coeffal
Coefficienta2
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
Coeffa2
Coefficienta3
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
Coeffa3
Column Internal Diameter
AnalysisDetails,
SamplePreparationDetails
Analysis, PreparationPlusCleanup
Column InternalDiameter
Column Length
AnalysisDetails,
SamplePreparationDetails
Analysis, PreparationPlusCleanup
ColumnLength
Correction Factor
AnalysisDetails,
SamplePreparationDetails
Analyte Comparison
CorrectionFactor
Correlation Coefficient
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
CorrelationCoeff
Counting Error
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
CountingError
Counts
AnalysisDetails,
InstrumentResponseDetails
Analysis, Analyte, Peak
Difference Error Ratio
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
DifferenceErrorRatio
Dilution Factor
AnalysisDetails
Analysis
DilutionFactor
Drift
AnalysisDetails,
InstrumentResponseDetails
Analysis, Analyte, Peak
Drift
Efficiency
SamplePreparationDetails,
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails
PreparationPlusCleanup, Analysis,
Analyte, Peak
Efficiency
Energy
InstrumentResponseDetails,
Peak, Peak Comparison
Energy
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
87
-------
Requirements for ERLN Data Submissions
InstrumentResponseAdditionalDetails
Filter Size
SampleDetails,
SampleHandlingDetails,
SamplePreparationDetails,
AnalysisDetails
SamplePlusMethod, Handling,
PreparationPlusCleanup, Analysis
FilterSize
Final Amount
SamplePreparationDetails,
AnalysisDetails
PreparationPlusCleanup, Analysis
FinalAmount
Flow Rate
AnalysisDetails
Analysis
FlowRate
Frequency
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Peak, Peak Comparison
Frequency
Gradient
AnalysisDetails
Analysis
Gradient
Handling Duration
SampleHandlinqDetails
Handlinq
HandlinqDuration
Handling Factor
SampleHandlinqDetails
Handlinq
HandlinqFactor
Initial Amount
SampleHandlingDetails,
SamplePreparationDetails
Handling, PreparationPlusCleanup
InitialAmount
Injection Volume
AnalysisDetails
Analysis
InjectionVolume
Mass
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison,
Peak Replicate
Mass
Mass Charge Ratio
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Peak, Peak Comparison
MassChargeRatio
Mean Calibration Factor
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
MeanCalibrationFactor
Mean Relative Response
SubstanceldentificationDetails
Analyte
MeanRelativeResponse
Mean Relative Response Factor
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
MeanRRF
Mean Retention Time
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
MeanRetentionTime
Number Of Dilutions
AnalysisDetails
Analysis
NumberDilutions
Orqanism Lenqth
SampleDetails
SamplePlusMethodPlusMethod
OrganismLength
Peak Ratio
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Peak, Peak Comparison
PercentRatio
Percent Match
SubstanceldentificationDetails
Analyte
PercentMatch
Percent Breakdown
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
PercentBreakdown
Percent Difference
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
PercentDifference
Percent Recovery
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
PercentRecovery
Percent Relative Standard Deviation
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
PercentRSD
Percent Valley
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
PercentValley
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
88
-------
Requirements for ERLN Data Submissions
Quench
AnalysisDetails
Analysis
Quench
Relative Response
SubstanceldentificationDetails
Analyte
RelativeResponse
Relative Response Factor
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
RRF
Relative Retention Time
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
RelativeRetentionTime
Relative Percent Difference
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
RPD
Relative Retention Time
InstrumentResponseDetails
Peak
RelativeRetentionTime
Resolution
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analysis, Analyte, Peak, Peak
Replicate
Resolution
Resolution Basis
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analysis, Analyte, Peak, Peak
Replicate
ResolutionType
Response
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Replicate
Response
Retention Time
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
RetentionTime
Sample Amount
SampleDetails,
SampleHandlingDetails,
SamplePreparationDetails,
AnalysisDetails
SamplePlusMethod, Handling,
PreparationPlusCleanup, Analysis
SampleAmount
Screen Result
SampleDetails
SamplePlusMethod
ScreenValue
Signal To Noise Ratio
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
SignalToNoiseRatio
Standard Concentration
SubstanceldentificationDetails
Analyte
StandardConcentration
Standard Final Amount
SubstanceldentificationDetails
Analyte
StandardFinalAmount
Standard Deviation
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analyte, Peak, Peak Comparison
StandardDeviation
Tailing Factor
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
TailingFactor
Wavelength
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
Analysis, Analyte, Peak, Peak
Comparison
Wavelength
Weighting Factor Type
SubstanceldentificationDetails,
InstrumentResponseDetails
Analyte, Peak
WeightingFactor
Yield
AnalysisDetails
Analysis
Yield
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
89
-------
Requirements for ERLN Data Submissions
Appendix E: ERLN Domain Model Overview
E.l What is a Domain Model?
A domain model is a graphical representation of the way an enterprise conducts its business within the
scope of a specific business domain (also called the problem domain). A specific enterprise [e.g., U.S.
Environmental Protection Agency (EPA)] may have several business domains in which business is
conducted. A business domain may be as broad or as specific as necessary depending on the system for
which the domain is being defined and may contain as many sub-domains as necessary. For example,
"Water" may be a business domain within the EPA enterprise. "Water Security" and "Beaches" may be
business domains within the "Water" business domain. Regardless of how many parent domains or sub-
domains a specific domain may have, the domain model is designed to represent the business conducted
within that specific business domain only. Other domains may be taken into consideration when
designing a domain model to promote scalability, flexibility, and resource sharing; however, the scope of
the domain model should be focused solely on the business need at hand.
E.2 What Are Domain Models Used for?
Domain models are used to describe the entities involved in a system and the relationships among those
entities. They also serve to document key concepts, provide a common vocabulary of the system being
modeled, and constrain the system scope. In essence, the system being developed will be limited to the
entities, data elements, and relationships as described in the domain model (while noting that the domain
model may be a living document that is subject to change throughout the development life-cycle as
emerging needs arise). An important benefit of the domain model is that it is helpful as a communication
tool between technical and business teams. Where technical terms and business terms may be foreign to
the other team, the domain model provides a medium that is conducive for comprehension on both sides.
E.3 Basic Components of a Domain Model
A domain model consists of the following basic components:
• Objects
• Data Elements
• Data Groups
• Relationships and Cardinality
E.3.1 Objects
Objects, also referred to as classes, are logical containers for information and usually represent logical
entities in the problem domain. For example, if the problem domain is fashion, objects can be things like
shirts, pants, glasses, etc. The object name in the domain model should be identical to its real-life name.
For example, a shirt object should be named "Shirt" in the domain model.
There is no one (or correct) way to define the objects in a problem domain. However, there are
implementations that yield varying degrees of efficiency and challenges. For example, instead of using
the objects "Shirt," "Pants," and "Glasses" to describe the objects above, one could use more generic
objects like "Articles" and "Accessories." Though the former implementation is easier to implement and
maintain, the latter provides more flexibility allowing more types of clothing other than shirts and pants to
be captured without adding new objects to the domain model.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
90
-------
Requirements for ERLN Data Submissions
The object or class in the domain model is defined by its properties which are the data elements, also
referred to as attributes, that comprise it. These data elements may be logically grouped within an object
in what are called data groups. Figure E.l shows an object named "Glasses" with its data elements.
Lens
LensType
LensSide
Lens
Figure E-1. Domain Model Object
E.3.2 Data Elements
Data elements are the properties of an object that collectively define it. Data elements may also be
organized into data groups for various reasons (see Section E.3.3). Depending on the use of the domain
model, the datatype (e.g., number, string, date, etc.) of each data element may be included as well. Data
elements are listed within the lower partition of the object box. Each data element has a one-to-one
relationship with the parent object (i.e., each object may have only one instance of that data element, and
that data element belongs to only that object).
E.3.3 Data Groups
A data group is simply a collection of data elements within an object. Essentially, a data group is an
object because it is subject to the same relationship rules as other objects. However, unlike other objects,
the data group is dependent on (and cannot exist without) its parent object. Classifying the object as a data
group simplifies its interpretation in that it lets users know that the data group object is solely related to
that one object and is not a standalone entity. For example, the "Glasses" object may have a data group
called "Lens" that contains information about lens width, shape, size, whether it is the left lens or the right
lens, etc. The "Lens" data group is its own object per se, but because it is not a domain object, it is not
valid by itself. That is, it has no role in the fashion business domain if it is not part of a valid object in that
business domain (i.e., its parent object, "Glasses").
Data groups are particularly useful when an object has more than one of a particular set of properties. For
example, the "Lens" data group within the "Glasses" object. Since glasses can have more than one lens
with differing properties (e.g., bifocals), the "Glasses" object may be linked to the "Lens" data group
multiple times.
There are a couple of ways data groups can be represented in a domain model. In one representation, the
data group is contained within the parent object (see Figure E.2) with some indication of its cardinality
(see Section E.3.4). In another representation, the data group is related to its parent object the same way
other objects are linked to it (see Figure E.3). The former representation provides a more organized and
discernable representation. Furthermore, the latter representation may cause confusion as to whether an
entity linked to an object is a standalone entity or a data group.
Glasses
Glassesldentifier
GlassesBrand
GlassesStyle
GlassesColor
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
91
-------
Requirements for ERLN Data Submissions
Glasses
Glassesldentifier
GlassesBrand
GlassesStyle
GlassesColor
Lens
LensType
LensSide
Lens
Figure E-2. Domain Model Data Group (within Parent Object)
Glasses
Lens
Glassesldentifier
LensType
GlassesBrand
LensSide
GlassesStyle
Lens
GlassesColor
Figure E-3. Domain Model Data Group (outside of Parent Object)
E.3.4 Relationships and Cardinality
Relationships are depicted in the domain model by a line between two related objects (the same as
depicted in Figure E.3). When a line is present between two objects X and Y, it is said that "X is related to
Y." For example, if there is a line between the "Shirt" object and the "Pants" object, it is said that "Shirt is
related to Pants." The nature of the relationship may or may not be ascertainable from just the presence of
the line. For example, it cannot be ascertained whether the relationship between shirt and pants means that
a "shirt may be sold with a pair of pants" or that a "shirt was worn with a pair of pants."
Cardinality in a domain model applies numeric constraints to the relationship between two objects. It is
used to show the number of instances of an object to which one instance of an object can be related.
Objects can be related in one of three ways—one-to-one, one-to-many, or many-to-many.
A one-to-one relationship may be defined by the following business rule model:
• Each unique instance of object A is related to one and only one unique instance of object B.
• Each unique instance of object B is related to one and only one unique instance of object A.
A one-to-many relationship may be defined by the following business rule model:
• Each unique instance of object A is related to one or more unique instances of object B.
• Each unique instance of object B is related to one and only one unique instance of object A.
A many-to-many relationship may be defined by the following business rule model:
• Each unique instance of object A may be related to one or more instances of object B.
• Each unique instance of object B may be related to one or more instances of object A.
Cardinality also includes the concept of optionality, meaning that an object does not have to be related to
an object for which a relationship is present in the domain model. When a relationship is optional, "one
and only one" in the business rules above changes to "at most one," and "one or more" changes to "zero or
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
92
-------
Requirements for ERLN Data Submissions
more." Cardinality notation varies, but these indicators are almost always found on and at the ends of the
line representing the relationship between two objects.
E.3.5 Incorporating EPA Standards
In 1998 the State-EPA Information Management Workgroup (IMWG) formed to recognize the
importance of developing a common vocabulary (data standards) for citizens, local governments, States,
Tribes, Federal Agencies, and Private Sector Organizations to communicate about environmental data.
The IMG established the Environmental Data Standards Council in 1999 to oversee the consensus-based
process for developing and promoting environmental data standards which established twenty-four data
standards during its tenure. In 2005, the IMWG transferred responsibility to the Environmental Network
Leadership Council (ENLC). The standards are a decision jointly made by EPA, States, and Tribes
through the ENLC due to their recognition and need for a sharing and exchanging accurate data rather
than a Federal mandate.
A data standard is a documented agreement among Exchange Network organizations that share or
exchange data and includes data elements, definitions, notes, formats, and extensible Markup Language
(XML) tags. Due to the need for exchanging ERLN data, the standards listed in Table 12 were reviewed
and applied to the ERLN data reporting framework.
Table 17. Applied EPA Data Standards
Data Standard Number
Data Standard Name
EX000002.1
Environmental Sampling, Analysis and Results: Project
EX000003.1
Environmental Sampling, Analysis and Results: Monitoring Location
EX000004.1
Environmental Sampling, Analysis and Results: Field Activity
EX000005.1
Environmental Sampling, Analysis and Results: Analysis and Results
EX000009.1
Equipment
EX000011.1
Method
EX000013.1
Representation of Date and Time
EX000014.1
Sample Handling
EX000016.2
Chemical Identification
EX000018.2
Biological Taxonomy
EX000019.2
Contact Information
EX000020.2
Facility Site Identification
For some data elements and data groups, naming conventions in the XML Design Rules and Conventions
(DRC) for the Environmental Information Exchange Network, a document that defines the naming
conventions used for the standards, have superseded data element and data group names in the data
standards. This has been done in cases where 1) data standard inconsistencies may cause confusion to the
end users, and 2) data element and data group names in the data standards fail to follow Design Rules and
Conventions (DRC) recommendations that would prevent technical implementation issues.
E.4 Web-based Electronic Data Review (WebEDR) Domain Model Concepts
E.4.1 High-Level Relationships
High-level relationships are those relationships between the objects of the Domain Model and do not
include those relationships between an object and its data elements. There are generally three types of
high-level relationships in domain modeling—one-to-one, one-to-many, and many-to-many. This Domain
Model has two types of one-to-many relationship types (each of which is explained in much greater detail
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
93
-------
Requirements for ERLN Data Submissions
later)—true one-to-many which is the equivalent of a standard one-to-many relationship, and scoped one-
to-many which is used instead of the standard many-to-many implementation.
True one-to-many uses an organizational approach in which objects are solely implemented hierarchically
(i.e., the object of which there are many instances [the "many" object] in the relationship is implemented
hierarchically as a child of the object of which there is one instance [the "one" object] in the relationship).
True one-to-many is used when each instance of the "many" object is unique and cannot be shared among
other objects (see Section E.4.1.4).
Scoped one-to-many uses a programmatic approach in which objects are implemented relationally. In
such an implementation, information about one of the objects is stored in one place and references to that
object are implemented hierarchically as a one-to-many relationship as a child within another object (each
instance of that child object being unique within the scope of the parent object). In other words, that same
child object may appear more than once within the scope of a parent object, but that same instance of that
child object may only appear once within the scope of that parent object. That same instance of that child
object may, however, appear within several other parent objects (see Section E.4.2). For the purposes of
the Domain Model, the object that serves as the parent and the object that serves as the child were
evaluated on a case-by-case basis to determine the most effective implementation. For this reason, there
may be instances where the "one" object is the child of the "many" object.
E.4.1.1 One-to-One Object Relationships
A one-to-one object relationship may be defined by the following business rule model:
• Each unique instance of object A is related to one and only one unique instance of object B.
• Each unique instance of object B is related to one and only one unique instance of object A.
E.4.1.2 Implementation in the Domain Model
One-to-one object relationships are denoted by a line connecting the two objects with a" 1" on both sides
of the relationship (see Figure E-4).
ElectronicDataDeliverableDetails
ProjectDetails
EDDIdentifier
1 1
ProjectStartDate
EDDFormatName
ProjectEndDate
Figure E-4. One-to-one Object Relationship in Domain Model
E.4.1.3 Implementation in the XML Schema Definition (XSD)
One-to-one object relationships in the Domain Model are always represented hierarchically in the XML.
Though the relationships between the objects in the Domain Model are technically not hierarchical, some
level of hierarchy is necessary to represent the data using XML. Because the tree-structure of XML is
commutative, the relational implementation of the WebEDR can be represented hierarchically (see
Figure E-5).
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
94
-------
Requirements for ERLN Data Submissions
Figure E-5. Commutative XML Hierarchy
For the purposes of implementing the WebEDR in XML, the Electronic Data Deliverable (EDD) was
chosen as the top-level element (off the root) and subsequent "parent-child" relationships were chosen
based on their distance from this object.
In the XSD, the child object is listed as a complex-type XML tag within the parent object's complex-type
XML tag with a maxOccurs attribute of "1." Using the EDD and Project objects as examples, Figure E-6
shows the resulting XML from an XSD implementation of this type.
AB C -123
My Format
2008-ll-21
2009-ll-21
Figure E-6. One-to-One Object Relationship in XML
E.4.1.4 One-to-Many Object Relationships
In general, a one-to-many relationship (here referred to as a true one-to-many relationship) may be
defined by the following business rule model:
• Each unique instance of object A is related to one or more unique instances of object B.
• Each unique instance of object B is related to one and only one unique instance of object A.
This is what will be referred to as "true one-to-many" throughout the remainder of this document and is
contrasted to "scoped one-to-many" (explained later) which is the method used to represent many-to-
many relationships in the Domain Model and XSD. Using scoped one-to-many, many-to-many
relationships are implemented as one-to-many relationships relative to the scope within which the
relationship is applicable (see Section E.4.1.7).
An example of a true one-to-many relationship within the Domain Model is the relationship between the
analysis run and the instrument response. Each analysis run may yield one or more instrument responses;
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
95
-------
Requirements for ERLN Data Submissions
each instrument response may only be yielded by one and only one analysis run. This is an example of
true one-to-many because it is impossible, by definition of an instrument response, for an instrument
response to be yielded by more than one analysis run.
E.4.1.5 Implementation in the Domain Model
True one-to-many relationships are denoted by a line connecting the two objects with a " 1" on the side of
the object for which there is only once instance in the relationship and an "M" on the side of the object for
which there are many instances in the relationship (see Figure E-7).
InstrumentResponseDetails
InstrumentResponseldentifier
InstrumentResponseTypeName
Figure E-7. True One-to-Many Object Relationship in Domain Model
E.4.1.6 Implementation in the XSD
In the XSD, the object of which there are many instances in the relationship is listed as a complex-type
XML tag within the complex-type XML tag of the object of which there is one instance with a
maxOccurs attribute of "unbounded." Using the Analysis and Instrument Response objects as examples,
Figure E-8 shows the resulting XML from an XSD implementation of this type.
My Analysis Group
2008-ll-21T10:00:00-05:00
123 - AB C
Peak
456-DEF
Peak
Figure E-8. True One-to-Many Object Relationship in XML
E.4.1.7 Many-to-Many Object Relationships
In general, a many-to-many relationship (here referred to as a true many-to-many relationship) may be
defined by the following business rule model:
• Each unique instance of object A may be related to one or more instances of object B.
• Each unique instance of object B may be related to one or more instances of object A.
An example of a true many-to-many relationship in terms of real-world application can be depicted
between the analysis run and the method. Each analysis run may be associated with several methods.
Each method may be used in several analysis runs.
AnalysisDetails
AnalysisGroupTypeText
AnalysisStartDate
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
96
-------
Requirements for ERLN Data Submissions
XSD files do not lend themselves to effectively capturing true many-to-many relationships. Therefore, for
the purposes of the Domain Model and XSD, the concept of scoped one-to-many relationships has been
introduced to capture the many-to-many relationships for WebEDR. This method is used to capture those
objects that are shared across several scopes within the XSD. It is important to note that this method is a
relational approach rather than a standard hierarchical approach.
For purposes of the Domain Model and XSD, the definition of a many-to-many relationship (also referred
to as a scoped one-to-many relationship for purposes related to the Domain Model and XSD) is modified
as follows:
• Each unique instance of an object A may be related to one or more instances of an object B.
• Each unique instance of an object B may be related to one or more instances of an object A, but
as that object B is implemented within the scope of that unique instance of object A, that object B
is considered to be linked to one and only one of any instance of an object A.
Using the scoped one-to-many model, the example provided can be reworded to demonstrate how it is
regarded within the Domain Model and XSD. Each analysis run may be associated with several methods.
Each method may be used for several analysis runs, but because the method is implemented within the
scope of the analysis run, that instance of the method is considered to be linked to only that one instance
of an analysis run. This technique is used to minimize the complexity of the XSD which is not adequately
equipped to effectively and efficiently handle true many-to-many relationships.
E.4.1.8 Implementation in the Domain Model
Scoped one-to-many relationships are represented the same way as true one-to-many relationships—they
are denoted by a line connecting the two objects with a " 1" on one side and an "M" on the other. The " 1"
is on the side of the object for which there is only one instance within the scope of the relationship. The
"M" is on the side of the object for which there are many instances within the scope of the instance of that
"one" object in the relationship. The cardinality notation is circled on the child object to indicate that for
that particular relationship, the object is related by reference instead of hierarchically. There are some
relationships to that same object that are maintained hierarchically.
In the case shown in Figure E-9, the analysis run was chosen as the parent because each instance of the
method is more widely shared within several scopes, while a particular analysis run is not necessarily.
The reason that this many-to-many relationship can be represented in this way is because within the scope
of the analysis run, it is not important that an instance of the method can be related to several analysis
runs.
AnalysisDetails
MethodDetails
AnalysisGroupTypeText
AnalysisStartDate
1
MethodVersionText
Method DeviationT ext
Figure E-9. Scoped One-to-Many Object Relationship in Domain Model
E.4.1.9 Implementation in the XSD
The method used to implement the relational technique of relating by reference is to include a "localld"
attribute on all object tags when being defined. The value of the "localld" attribute is a natural number to
be assigned by the program generating the XML file. This number is used to reference the object and all
of its data elements. Please note that for consistency, all objects require the "localld" attribute even if they
are never related by reference. Data groups do not require "localld" attributes. Please also note that this
attribute was not included in previous examples so as not to distract readers from the concepts being
described.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
97
-------
Requirements for ERLN Data Submissions
As described above, the object tag includes a "localld" attribute. However, when being referenced, the
object is captured as a child of another object and includes a "localRelld" attribute which specifies the
instance being related. For example, an analysis run identified with a localld of "1" uses a method
identified with a localld of "2." Figure E-10 depicts how this relationship would be captured in the
resulting XML file.
My Group
2008-ll-21T10:00:00-05:00
2.1. 2
My Deviation
Figure E-10. Scoped One-to-Many Object Relationship in XML
E.4.2 Parent-Child Relationships
One of the goals of using an object-oriented implementation is to allow individual parts of the grand
design to be shared independently. When determining what data groups are to be included and where data
elements should be captured, ease of implementation is weighed against maintenance of a solid design
that accommodates the business need and minimizes the need for structural changes while allowing for
flexibility and scalability. By designing the Domain Model modularly to reflect real-world objects as
closely as possible, more benefits of a solid design are promoted at the slight expense of implementation
ease. This balance will be discussed in more detail in later examples.
A parent-child relationship is essentially the relationship between an object or data group and its data
groups or data elements. These are contrasted with object relationships in that there is no true hierarchy in
the relating of objects. With object relationships, there only appears to be hierarchy to implement those
relationships in XML, while with parent-child relationships, the hierarchy reflects the actual business
need. The relationships discussed in this section are true parent-child relationships because the data
elements are dependent on the object or data group to which they belong. There are two types of parent-
child relationships—one-to-one parent-child relationships and one-to-many parent-child relationships.
Because the Domain Model is implemented modularly, the only data elements and data groups found
within an object are properties of that object. For this reason, there are cases where one-to-one object
relationships have been preferred over the use of parent-child relationships. For example, being that there
is a one-to-one relationship between a sample and a biological organism, it could be argued that the two
data elements comprising a biological organism could be captured as data elements within the sample.
However, because a biological organism is its own object in reality, it has been implemented as such with
its own properties in the Domain Model. The benefit of this implementation is immediately clear in that
the biological organism on its own needs to be linked to its substance identification—a relationship that
would not have been possible had it been implemented as a property of the sample.
E.4.2.1 One-to-One Parent-child Relationships
One-to-one parent-child relationships are those relationships of which there is only one instance of a child
per instance of a parent. For example, an EDD (see Figure E-ll) has one and only one EDDIdentifier.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
98
-------
Requirements for ERLN Data Submissions
E.4.2.2 Implementation in the Domain Model
As seen in Figure E-l 1, child elements of an object are listed as data elements represented by their XML
tag names within the box for that object.
ElectronicDataDeliverableDetails
EDDIdentifier
EDDFormatName
EDDVersionText
EDDImplementationTypeName
EDDImplementationVersionText
DataPackageldentifier
DataPackageldentifierContext
Data Package Name
Data Package VersionText
DataPackageReportedDate
DataPackageNumber
GeneratingSystemTypeName
Ge ne rati ng Syste m Ve rsionText
Laboratory NarrativeText
Laboratory ReportedDate
Figure E-11. One-to-One Parent-Child Relationships in Domain Model
E. 4.2.3 Implementation in the XSD
Child elements of an object are listed as simple-type XML tags within the parent's complex-type XML
tag. Each simple-type XML tag representing a child is hierarchically located within the parent's complex-
type XML tag with a maxOccurs attribute of" 1." Figure E-12 shows a resulting XML from an XSD
implementation of this type. Please note that each XML tag is listed once and only once within a data
group. Simple-type XML tags within the WebEDR are never repeated within a data group.
Figure E-12. One-to-One Parent-child Relationships in XML
E.4.2.4 One-to-One Parent-Child Relationships (Data Group Implementation)
In very few cases, children of an object with a one-to-one relationship to that object have been
implemented using a data group. In these cases, a data group is preferred because 1) it is consistent with
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 99
-------
Requirements for ERLN Data Submissions
the EPA data standard, and 2) it is more scalable and anticipates an evolving need to treat that object as its
own data group.
For example, the chemical identification data elements are clearly properties of a substance. However,
they have been grouped into ChemicalldentificationDetails. An advantage in this specific case is seen in
its technical implementation. The identification of a substance as to whether it is a chemical or a
biological organism can be determined based on the existence or absence of a single parent tag (either
ChemicalldentificationDetails or BiologicalTaxonomyDetails) as opposed to confirming the existence or
absence of every tag comprising one or both substance types. Because a substance can be identified as
either chemical or biological (but not both), the "choice" XSD order indicator can be used to easily
establish this rule.
E.4.2.5 Implementation in the Domain Model
As seen in Figure E-13, child elements of an object (when implemented as a data group) are captured as a
data group itself, but within the parent object. Within this data group are the data elements that comprise
the property of the parent object. The one-to-one parent-child relationship is denoted by a line connecting
the parent to its child data group with a " 1" on both the parent and child sides of the relationship.
SubstanceldentificationDetails
SubstanceTypeName
1
ChemicalldentificationDetails
1
EPAChemicallnternalTrackingNumber
CASRegistry Number
EPAChemicalldentifier
ChemicalSubstanceSystematicName
EPAChemicalRegistryName
Figure E-13. One-to-one Parent-child Relationship (Data Group)
Relationally in Domain Model
E. 4.2.6 Implementation in the XSD
A data group with a one-to-one parent-child relationship with the parent object is listed as a complex-type
XML tag which is hierarchically located within the object's complex-type XML tag with a maxOccurs
attribute of" 1." Figure E-14 shows a resulting XML from an XSD implementation of this type that
applies the scoped one-to-many approach (see Section E.4.1.7). This is the implementation that is used in
the Domain Model. To further reiterate this concept, Figure E-15 shows a resulting XML from an XSD
implementation of this type if a true one-to-many approach (see Section E.4.1.8) were to be applied.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
100
-------
Requirements for ERLN Data Submissions
Figure E-14. One-to-One Parent-Child Relationships (Data Groups) Relationally in XML
Figure E-15. One-to-One Parent-Child Relationships (Data Groups) Hierarchically in XML
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
101
-------
Requirements for ERLN Data Submissions
E. 4.2.1 One-to-Many Parent-Child Relationships
One-to-many parent-child relationships are those relationships for which there are multiples of the same
data group per instance of an object. For example, a facility site may have one or more Facility Site
Identifiers. Please note that it is not possible for there to be multiples of the same data element per
instance of an object unless that data element is contained within a data group. Refer to the section on
Disambiguation (Section E.4.3) for more details.
E.4.2.8 Implementation in the Domain Model
As seen in Figure E-16, one-to-many parent-child relationships are captured as a data group within the
parent object. Within this data group are the data elements. The one-to-many relationship is denoted by a
line connecting the object to its data group with a "1" on object side of the relationship and an "M" on the
data group side of the relationship.
FacilitySiteDetails
(no data elements)
FacilitySiteldentificationDetails
FacilitySiteldentifier
Faci lity S ite I de nti fie rContext
Figure E-16. One-to-Many Parent-Child Relationship in Domain Model
E. 4.2.9 Implementation in the XSD
A data group with a one-to-many parent-child relationship with the parent object is listed as a complex-
type XML tag which is hierarchically located within the object's complex-type XML tag with a
maxOccurs attribute of "unbounded." Figure E-17 shows a resulting XML from an XSD implementation
of this type.
ABC123456789
USEPA Site ID
1234567
CERCLIS Site ID
Figure E-17. One-to-Many Parent-Child Relationship in XML
E.4.2.10 Many-to-Many Parent-Child Relationships
Because each data element within an object is a unique instance within the scope of that object, the
concept of many-to-many parent-child relationships is not valid. In order for a many-to-many parent-child
relationship to be valid, a data element within an object would need to be able to be shared by another
object. Based on to the fundamental concepts of the Domain Model, this is not possible.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
102
-------
Requirements for ERLN Data Submissions
E. 4.2.11 Property-less Objects
Property-less objects are those objects in the domain model that do not have data elements of their own.
These objects are denoted by a box with "(no data elements)" instead of a list of data elements. Property-
less objects are generally used for the sole purpose of grouping data elements and data groups or for
providing relationship-only information.
E.4.2.12 Relationship Groups
The WebEDR consists of many complicated relationships which collectively can create a potentially
incomprehensible web of lines. To remove some of the complexity, objects that are related to the same
objects as other objects are organized into groups. These groups are enclosed within a colored box (the
relation box) which corresponds to the object to which each of those objects in those groups is related.
The object to which these objects are related is surrounded by a box of the same color (the object box).
The cardinality notation is located on the colored connector and is distributive with respect to each of the
objects within the relation box.
As seen in Figure E-18, the Sample Handling and Sample Preparation objects both have a scoped one-to-
many relationship to the Equipment. Please note that the objects within the relation box may have other
relationships (not depicted in this diagram) and may also be contained within other relation boxes. Figure
E-19 shows the equivalent of this relationship without using Relationship Group notation.
EquipmentDetails
©
EquipmentName
EquipmentTypeText
r
| M
EquipmentldentificationDetails
Equipmentldentifier
EquipmentldentifierContext
SampleHandlingDetails
SampleHandlingName
SampleHandlingTypeText
SampleHandlingStartDate
SampleHandlingEndDate
I
I M
SamplePreservationDetails
M | ChemicalPreservativeUsed
ThermalPreservativeUsed
SamplePreparationDetails
SamplePreparationName
SamplePreparationTypeText
SamplePreparationStartDate
SamplePreparationEndDate
SamplePreparationSequenceNumber
Figure E-18. Relationship Groups in Domain Model
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
103
-------
Requirements for ERLN Data Submissions
EquipmentDetails
EquipmentName
EquipmentTypeText
u
EquipmentldentificationDetails
Equipmentldentifier
EquipmentldentifierContext
SampleHandlingDetails
SampleHandlingName
SampleHandlingTypeText
SampleHandlingStartDate
SampleHandlingEndDate
1
SamplePreservationDetails
I M ChemicalPreservativellsed
ThermalPreservativeUsed
SamplePreparationDetails
SamplePreparationName
SamplePreparationTypeText
SamplePreparationStartDate
SamplePreparationEndDate
SamplePreparationSequenceNumber
Figure E-19. Equivalent to Relationship Group Notation Depicted in Figure E-18
E.4.3 Disambiguation
The disambiguation technique is used throughout the data model to 1) allow for an unlimited number of a
single type of data element to be associated with an object and 2) to unambiguously qualify an instance of
a data element with respect to other data elements of the same type. As noted in Section E.4.2.3 each
XML tag is listed once and only once within an object or data group, and simple-type XML tags are never
repeated within an object or data group. However, there is a need to capture multiple of the same data
elements. The need for and the process of disambiguation is explained through the following example.
In the simplest implementation of the Facility Site module, the Facility Site would consist of any number
of Facility Site Identifiers [e.g., Comprehensive Environmental Response, Compensation, and Liability
Information System (CERCLIS) Site ID, EPA Site ID, Site Spill ID, etc.] and any number of Facility Site
Names [e.g., Site Name, CERCLIS Site Name, CERCLIS Site Short Name, etc.] and would be
implemented as shown below:
Demonstration Site Name for WebEDR
Demo WebEDR Site Name
ABC123456789
1234567
A problem with this implementation becomes immediately noticeable—there is no guaranteed method for
a human or parser to discern the type of facility site name or facility site identifier being transmitted. In
order for the facility site names and facility site identifiers to have meaning, they need to be accompanied
by a data element that provides the context within which they are being transmitted. It could be argued
that each type of facility site name could be transmitted in its own XML tag (e.g., ,
, , etc.); however, the possibilities for these site
name types are endless and it would be inefficient and illogical to change the XML for each new facility
site name or facility site identifier encountered. Therefore, generic XML tags (i.e., FacilitySiteName and
FacilitySiteldentifier) are used and each is accompanied by an appropriate context element in accordance
with Section 1.6.d, Metadata of EPA data standards. In this example, the context elements are named
FacilitySiteNameContext and FacilitySiteldentifierContext.
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 104
-------
Requirements for ERLN Data Submissions
The addition of these context data elements does not fully solve the problem because they introduce a
new problem as shown below:
Demonstration Site Name for WebEDR
CERCLlS Site Name
Demo WebEDR Site Name
CERCLfS Site Short Name
ABC123456789
U SEP A Site fD
i234567
CERCLfS Site fD
Though the intent of this XML is easily discernable by manual inspection, it is less than ideal for
implementation within an XSD. Though a parser may be able to successfully parse these data elements
based on the order in which they appear, it is impossible to implement a 100% flexible solution within the
XSD that will simultaneously enforce this order.
To guarantee flexibility, the final step for disambiguation is to group corresponding data elements within
the same data group as shown below:
Demonstration Site Name for WebEDR
CERCLlS Site Name
Demo WebEDR Site Name
CERCLfS Site Short Name
ABCi23456789
USEPA Site fD
f234567
CERCLfS Site fD
This final solution meets the goals of providing a generic method for providing an unlimited number of a
particular type of data element while unambiguously providing the context.
E.5 ERLN Domain Model
The diagram depicted in Appendix H: Environmental Response Laboratory Network (ERLN) Proposed
Domain Model shows the Domain Model currently under consideration for the ERLN. This model should
only be considered a draft; additional modifications will be made prior to finalization.
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
105
-------
Requirements for ERLN Data Submissions
Appendix F: ERLN Type 2 Document Type Definition (DTD)
-------
Requirements for ERLN Data Submissions
Locationldentifier?,
Preservative?,
SampleChainofCustodyldentifier?,
SampleCollectionEndDate?,
SampleCollectionStartDate?,
Sampleldentifier,
SampleMatrix,
SampleType?,
StorageBatch Identifier?,
AnalysisDetails+,
CharacteristicDetails*
)>
-------
Requirements for ERLN Data Submissions
)>
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 108
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
109
-------
Requirements for ERLN Data Submissions
Appendix G: ERLN Type 3 Document Type Definition (DTD)
-------
Requirements for ERLN Data Submissions
ContactTitle?,
ContactType?
)>
-------
Requirements for ERLN Data Submissions
)>
-------
Requirements for ERLN Data Submissions
SampleMatrix?,
SampleMatrixMediumType?,
Solvent?,
CharacteristicDetails*,
MeasureDetails*
)>
-------
Requirements for ERLN Data Submissions
InstrumentResponseldentifier,
InstrumentResponseTypeName,
IntermediateResult?,
IntermediateResultUncertainty?,
IntermediateResultUnits?,
LaboratoryResultQualifier?,
LaboratorySubstanceldentifier?,
Result?,
ResultBasis?,
ResultUncertainty?,
ResultUnits?,
SubstanceName?,
SubstanceNameContext?,
MeasureDetails*
)>
VERSION 1.5 - 101811 For Official Use Only - Do Not Cite, Circulate or Copy 114
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811 For Official Use Only - Do Not Cite, Circulate or Copy 115
-------
Requirements for ERLN Data Submissions
VERSION 1.5 - 101811 For Official Use Only - Do Not Cite, Circulate or Copy 116
-------
Requirements for ERLN Data Submissions
VERSION 1.5-101811
For Official Use Only - Do Not Cite, Circulate or Copy
117
-------
Requirements for ERLN Data Submissions
Appendix H: ERLN Proposed Domain Model
The following diagram depicts the Domain Model currently under consideration for the ERLN. This model should only be considered a draft; additional modifications will be made prior to finalization.
;= t-
Z §
;£
| x 5 S ^ i
<5 ® c c
list!
liSff i ,
2li->22£La.£LQ.Q-Q- S
DQDOD U (1 It !! (1 I!
UJUJLULUUDQOQQQC]
If s
t .5 ; ® c
illfli
5 ® a; a s -¦£
I
12 2 £
I <3 eg <3
5 § ®
* Z Q
= ss
11 ill
fill
sills
1
I
i
*
#
a
0
"ST
Q. 0.
2
1
3
E
5
I
®
*
1!
55
FP"
5
£
P
4
i.
a
*
§ q
11
uZiZ
>13 =
SJifl
11
a
0
6
3
*
?
R
, V
c
s
£ £
il
u
c
33
0
5
II
25
1
Z
|
1
i
**
2
c
1
11
22
L3
3
j§
®
X
3
i
1?
*
si
T H
a
£
c ®
E £
£ £
3
1 s s
'.= Sj
2 |f
0
-f = 2
I i
•j a:
ill
Ui O
tb d l±i
i si
^ u l. « ai
lllpfl
1IIflli
Ss|l|if
I 1|hIs3
stefsisa
fill?!
1
a
0
S
5
i
S
, V
i
S £
£ £
s
¦0
e c
Ui
h
O
fc
P
£
X
*
CO
IS
1
i!
CO
**
i I
ail
£ £ E
CO (3 CO
|
1
a
§
1
s
1
ff
!
I
c
i
s
O
s
O.
E
<0
I
ill?
I'i't1?
1
0
i
%
> i
a
E
£
S i
£ $
P F
a
Q
1
.
a
Sis
h
UJ
1 c c c "
g,2SS.!
ilil!
I Es
Jill
13
i S
'£'
Zhif£ IS i
MMMIliilffi
SgI?SgSl|ESSiS
<<<<<<'5
------- |