United States
Environmental Protection
Agency
Requirements for Environmental
Response Laboratory Network (ERLN)
Data Submissions 1
Version 1.4
1 The content of this document is subject to change based on decisions by EPA.
Office of Solid Waste and Emergency Response January 2011 www.epa.gov/erln
-------
-------
Requirements for ERLN Data Submissions
Table of Contents
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 3
2.1 GOAL 3
2.2 RESPONSIBILITY 3
2.3 ERLN LABORATORY ACCESS PROCESS 3
2.3.1 Measurement Quality Objectives (MQOs) 4
2.4 CREATING A MODEL FOR COMMUNICATION 4
2.4.1 Defining Data Requirements 5
SECTION 3.0: OVERVIEW OF REPORTING REQUIREMENTS 9
3.1 WHAT is REQUIRED ERROR! BOOKMARK NOT DEFINED.
3.2 HIGH-LEVEL DATA SUBMISSION REQUIREMENTS 9
3.2.1 Data Reporting Group Notification 10
3.2.2 Electronic 10
3.2.3 Data Reporting 11
3.3 SUBMISSION TYPES 11
3.4 ERLN DATA ORGANIZATION (APPLICABLE TO TYPE Two AND THREE SUBMISSIONS) 12
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
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
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy i
-------
Requirements for ERLN Data Submissions
APPENDIX A: GLOSSARY 40
APPENDIX B: ERLN DATA EXCHANGE TEMPLATE (DET) 42
B.I HIGH-LEVEL CONCEPTS 42
B.I.I Representative Groups 42
B.I.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 ERLNDET 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.I CHARACTERISTICS OF AN ELECTRONIC SUBMISSION 72
C. 1.1 Organization of Electronic Submission 72
C.I.2 XML Syntax Guidelines 73
C.I.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.I 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.I 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.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
Requirements for ERLN Data Submissions
List of Tables
Table 1. Responsibility 3
Table 2. Summary of Submission Types 11
Table 3. Type 1 Data Requirements 17
Table 4. Type It Additional Data Requirements 20
Table5. 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 76
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 12
Figure 3-2. ERLN DET Type 3 Data Group Organization 13
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-ll. 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-l8 104
Figure H-l. ERLN Proposed Domain Model 118
VERSION 1.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
Requirements for ERLN Data Submissions
List of Exhibits
Exhibit 1 Generic Analytical Sequence 6
VERSION 1.4-012610 For Official Use Only- Do Not Cite, Circulate or Copy iv
-------
Requirements for ERLN Data Submissions
VERSION 1.4 - 012610 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
ICSA 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.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
VI
-------
Requirements for ERLN Data Submissions
TIC Toxic Industrial Chemicals
W3 C World Wide Web Consortium
WebEDR Web-based Electronic Data Review
XML Extensible Markup Language
XSD XML Schema Definition
VERSION 1.4-012610
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 fERLNj 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.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
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/ciopolicy/2150-0.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.4 - 012610 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
EPA data user
ERLN Laboratory
Responsibility
Initiates a project, defines scope and reporting needs.
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.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 4
-------
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.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
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.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
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.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
Requirements for ERLN Data Submissions
VERSION 1.4 - 012610 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.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
-------
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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 10
-------
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
Type
One
Type
Two
Type
Three
Submission
Type 1
Type 1t
Type 2
Type 3
Purpose
Provides result information for
projects.
Provides a broader picture of the
result information.
Provides information in order to
perform an automated assessment
on field and laboratory generated
samples.
Most extensive submission format.
Provides information necessary to
perform an extensive assessment
including recalculating results.
Scope
Results Only for target substances
of field generated samples.
Result information for Target and
non-target substances of Field and
Lab 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).
Type 2 + Instrument response (i.e.
tuning ) and data supporting
laboratory results
Required
Electronic
Format
Spreadsheet
or CSV file
Spreadsheet
or CSV file
XML
XML
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
11
-------
3.4
Requirements for ERLN Data Submissions
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.
project Details
Details
Method Details
Sample Details
Characteristic Details
PointofContact
Details
Analysis Details
Sampte Preparation
Details
Substanca Identification
Details
Measure Details
Figure 3-1. ERLN DET Type 2 Data Group Organization
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
12
-------
Requirements for ERLN Data Submissions
Project Details
Sample Details
Analysis Details
Substance Identification
Details
Instrument Response
Details
Instrument Response
Additional Details
Method Details
Measure Details
Data Quality Indicator
Details
Characteristic Details
Sample Handling Details
Measure Details
Characteristic Details
Measure Deans
Data Quality Indicator
Details
Charactffliettc Detars
* Preparation
ay lit,
Measure Deal's
Chardt.to-is.tlL Dslalls
Measure Details
Data Quality Indicator
Details
Measure Details
Data Quality Indicator
Details
Measure Details
Data Quality Indicator
Details
Data Quality Indicator
Details
Data Quality Indicator
Details
Figure 3-2. ERLN DET Type 3 Data Group Organization
VERSION 1.4 - 012610 For Official Use Only - Do Not Cite, Circulate or Copy
13
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 14
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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.4-012610 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
AgreementNumber*
AnalysisEndDate
AnalyticalServiceRequestl
dentifier*
CASRegistryNumber
DataPackageldentifier*
LaboratoryResultQualifier
Methodldentifier
Organizationldentifier*
Projectldentifier*
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Definition
A client-defined number or identifier that
specifies the contract or agreement under
which the laboratory analyzes the samples.
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.
A client-defined number or identifier that
specifies the service request.
The unique number assigned by Chemical
Abstracts Service (CAS) to a chemical
substance.
A laboratory-defined identifier for this data
submission package. This identifier applies
to a single EDO.
A laboratory-assigned string of result
qualifiers (usually a single character for each
qualifier), based on client-defined rules and
values.
The identification number assigned by the
method publisher.
A designator used to uniquely identify a
unique business establishment within a
context.
A designator used to uniquely identify the
project to organizations sharing data.
The number or value below which data are
typically reported as 'not detected' for the
substance being measured.
One of a list of client, regulation, or
organization-defined acronyms or statistical
methodologies that specify the type of
reporting limit.
Units associated with reporting limit as
determined by the laboratory.
Business Rules/Comments
Provide if a contract number exists. If not, leave
blank.
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.
Obtain from ASR.
Provide when the substance has a defined CAS
number. If not, leave blank.
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
Obtain from Analytical Serive Request.
Obtain from Analytical Serive Request If one is
not provided, the laboratory shall include an
identifier for their name.
Required
Conditionally
Required
Y
Y
Conditionally
Required
Y
Y
Y
Y
Y
Y
Y
Y
Format
Alphanumeric
YYYY-MM-DD
hh:mm:ss
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
17
-------
Requirements for ERLN Data Submissions
ERLN Data Exchange
Template (DET) Tag
Result
ResultUncertainty
ResultUnits
SampleCollectionEndDate
Sampleldentifier
SampleMatrix
SubstanceName
Definition
The reportable measure of the result for the
chemical, microbiological, or other
characteristic being analyzed.
A value or set of values that characterizes
the dispersion of the values that could
reasonably be attributed to the measured
result value.
The code that represents the unit for
measuring the item.
The ending date that a field activity was
finished.
A designator used to uniquely identify a
sample within a context.
Sub-medium or matrix that is sampled.
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.
Business Rules/Comments
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.
Enter start date for grab samples.
Obtain from Chain of Custody. |f reporting a
laboratory generated sample, provide the
laboratory sample identifier as the
Sampleldentifier.
Obtain from Chain of Custody. If reporting a
laboratory generated sample, provide the matrix
of the appropriate field sample.
Required
Y
Conditionally
Required
Y
Y
Y
Y
Y
Format
Alphanumeric
Numeric
Alphanumeric
YYYY-MM-DD
hh:mm:ss
Alphanumeric
Alphanumeric
Alphanumeric
Repeat data for each row included in the electronic submission.
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
18
-------
Requirements for ERLN Data Submissions
4.2 Type 1 Transitional (Type 1t) 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.4-012610 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
AnalysisStartDate
Comment
ExpectedResult
ExpectedResultUnits
LaboratorySampleldentifier
LaboratorySubstanceldentifier
Locationldentifier
OrganizationName*
PreparationEndDate
Definition
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.
A free-form comment field.
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.
Units associated with expected
result.
A laboratory-defined identifier for a
sample that uniquely identifies a
single sample that is subjected to an
analysis.
A laboratory-defined identifier for a
substance.
A client-defined identifier of the
sampling location at a particular
site.
Descriptive name for the laboratory
performing this analysis.
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.
Business Rules/Comments
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.
Provide if reporting expected
result. If not, leave blank.
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.
Required
Y
O
C
C
O
O
O
O
C
Format
YYYY-MM-DD hh:mm:ss
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
Alphanumeric
YYYY-MM-DD hh:mm:ss
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
20
-------
Requirements for ERLN Data Submissions
PreparationStartDate
ResultBasis
SampleCollectionStartDate
SampleType
SubstanceType
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.
The basis upon which the final
results were calculated.
Date and time the sample was
collected. If collected over a range
of dates, this is the start date.
The client-defined term used to
define the specific type of QC
sample being analyzed.
A client-defined identifier that
identifies the type of substance
reported.
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.
Provide if the result value
provided was calculated based
on different values. If the result
was not calculated, leave blank.
See Valid Values worksheet
See Valid Values worksheet
C
C
O
Y
Y
YYYY-MM-DD hh:mm:ss
Alphanumeric
YYYY-MM-DD hh:mm:ss
Alphanumeric
Alphanumeric
Repeat data for each row included in the electronic submission.
VERSION 1.4-012610
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.4-012610 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 abookmarked 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.4-012610 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
Supporting
Data:
Not Required
Instrument
and Other
Supporting
Data:
Not Required
Required Data Elements:
• SubstanceName
• SampleMatrix
• Methodldentifier
• Sampleldentifier
• SampleCollectionEndDate
• AnalysisEndDate
• Result
• ResultUnits
• ReportingLimit
• ReportingLimitType
• ReportingLimitUnits
• AnalyticalServiceRequestldentifier*
• Organizationldentifier*
• Projectldentifier*
• DataPackageldentifier*
*Element will be repeated for each substance provided.
Additional Required Data Elements:
• All Type 1 Data Elements
• SubstanceType
• SampleType
• AnalysisStartDate
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
24
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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.4-012610 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.4-012610 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 Serive
Requestor.
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 28
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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
Scope
Electronic Delivery
Data Report Delivery
Required Summary Forms
Instrument and Other
Supporting Data:
Type 2
Type 1 + Substance information for each analysis performed on a field or
laboratory generated sample, as well as any calibration sample (optional).
Extensible Markup Language (XML)
Portable Document File (PDF) (Required), Paper (Upon Request)
Type 1 + measurement quality indicator information
Not Required
Required Data Elements:
• ProiectDetails * SubstanceldentificationDetails
• DataPackageldentifier • Exclusionlndicator
• DateFormat • ReportingLimit
• LaboratoryNarrative • ReportingLimitType
• LaboratoryQualifiersDefinition • ReportingLimitUnits
• Projectldentifier • Result
• OrganizationDetails • ResultUnits
• Organizationldentifier • SubstanceName
• MethodDetails • SubstanceType
• Methodldentifier
• SampleDetails
• Sampleldentifier
• SampleChainofCustodyldentifier
• SampleCollectionEndDate
• SampleMatrix
• SampleType
• AnalysisDetails
• AnalysisBatchldentifier
• AnalysisEndDate
• AnalysisStartDate
• AnalysisType
• Instrumentldentifier
• LaboratoryAnalysisldentifier
• Methodldentifier
• RunBatchldentifier
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 30
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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. Referto Section 3.4.3 or 4.15 of the 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.4-012610 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.4-012610 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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 34
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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
Scope
Electronic Delivery
Data Report Delivery
Required Summary Forms
Instrument and Other
Supporting Data
Type 3
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.
extensible Markup Language (XML)
Portable Document File (PDF) (Required), Paper (Upon Request)
Type 2
Refer to Section 4.15 of the Environmental Response Laboratory Network
(ERLN) Laboratory Requirements Document fora 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.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
36
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 38
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 40
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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.1 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 MeasureDetails data group. This concept allows
for the expansion of the data standard without disrupting the existing process for providing and validating
data.
VERSION 1.4-012610 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.I.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 of Data 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
ProjectDetails
OrganizationDetails
PoingOfContactDetails
SampleDetails
SampleHandlingDetails
AnalysisDetails
SamplePreparationDetails
SubstanceldentificationDetails
InstrumentResponseDetails
InstrumentResponseAdditionalDetails
CharacteristicDetails
MethodDetails
Definition
Describes the format and content unique to a specific electronic data
submission as it relates to a specific project.
Describes the unique framework of authority within which a person or
persons act, or are designated to act, towards some purpose.
Describes the particular termsregularly connected with a person so that
you can recognize, refer to, or address him or her.
Describes one sample analyzed under the criteria established for the
project.
Describes any manipulation of the sample (e.g., leaching, filtering, and
ashing) prior to taking a sample aliquot for analysis.
Describes one complete sequence of events, from taking a sample aliquot
through the measurement process, as defined as part of one method.
Describes a preparation or cleanup process as part of an analysis.
Describes the substance level data from one analysis or one group of
analyses.
Identifies and reports the actual measurement data related to the analysis
of substance peaks.
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.
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.
Describes the procedures and techniques required to determine the
methods used to obtain a result.
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
43
-------
Requirements for ERLN Data Submissions
Data Group Name
MeasureDetails
DataQualitylndicatorDetails
Definition
Identifies the value and the associated units of measure for measuring an
observation or analytical result value.
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.
B.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.4-012610 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
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
OrganizationDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
ERLN Data Element
AgreementModificationDescription
AgreementModificationldentifier
AgreementNumber
AnalyticalServiceRequestldentifier
Comment
DataExchangeTemplateldentifier
DataExchangeTemplatelmplementationldentifier
DataExchangeTemplatelmplementationVersion
DataExchangeTemplateVersion
DataPackageldentifier
DataPackageName
DataPackageVersion
DateFormat
GeneratingSystemldentifier
GeneratingSystemVersion
LaboratoryNarrative
LaboratoryQualifiersDefinition
LaboratoryReportedDate
Projectldentifier
ProjectName
Siteldentifier
SiteName
Comment
Organizationldentifier
OrganizationLocationAddress
OrganizationLocationAddressCity
OrganizationLocationAddressCountry
OrganizationLocationAddressState
OrganizationLocationAddressZipCode
OrganizationMailingAddress
OrganizationName
OrganizationTelephoneNumber
OrganizationType
Comment
ContactElectronicAddress
ContactFullName
Contactldentifier
Typel
-
-
O
Y
-
-
-
_
_
Y
_
_
-
-
-
-
-
-
Y
-
-
-
-
Y
-
-
-
-
-
-
-
_
_
_
_
_
-
Type 1t
-
-
O
Y
O
-
-
_
_
Y
_
_
-
-
-
-
-
-
Y
-
-
-
-
Y
-
-
-
-
-
-
O
_
_
_
_
_
-
Type 2
O
O
O
Y
O
-
-
_
_
Y
O
O
Y
-
-
Y
Y
O
Y
O
-
-
O
Y
O
O
O
O
O
O
O
O
O
O
O
O
O
Type3
O
O
O
Y
O
O
O
O
O
Y
O
O
Y
O
O
Y
Y
Y
Y
O
O
O
O
Y
O
O
O
O
O
O
O
O
O
O
O
O
O
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
45
-------
Requirements for ERLN Data Submissions
ERLN Data Group
PointofContactDetails
PointofContactDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
ERLN Data Element
ContactTitle
ContactType
AlternateLaboratorySampleldentifier
AnalysisRequestldentifier
Billingldentifier
Bottleldentifier
BottleType
Comment
Compositelndicator
Contactldentifier
Coolerldentifier
CreatedDate
FieldEquipmentBatch Identifier
Filteredlndicator
LaboratoryReceiptDate
LaboratoryReportingBatchldentifier
LaboratorySampleldentifier
LaboratoryType
Locationldentifier
LocationName
MethodBatch Identifier
Method Identifier
NumberOfBottles
OriginalClientSampleldentifier
OriginalLaboratorySampleldentifier
PhaseAnalyzed
Preservative
PreservedBy
Priorityldentifier
QualityControlCategory
QualityControlSampleLinkage
Quarantinelndicator
SampleChainofCustodyldentifier
SampleCollectionEndDate
SampleCollectionStartDate
Sampleldentifier
SampleMatrix
SampleMatrixMediumType
SampleType
Typel
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
_
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Y
-
Y
Y
_
-
Type 1t
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
O
-
O
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Y
O
Y
Y
_
Y
Type 2
O
O
-
-
-
-
-
-
-
O
-
-
-
-
O
-
O
-
O
-
-
-
-
-
-
-
c
-
-
-
-
-
Y
Y
O
Y
Y
_
Y
Type3
O
O
O
O
O
O
O
O
O
O
O
O
O
O
Y
O
O
O
O
O
O
O
O
O
O
O
c
O
O
O
O
O
Y
Y
O
Y
Y
O
Y
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
46
-------
Requirements for ERLN Data Submissions
ERLN Data Group
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
ERLN Data Element
SamplingBatchldentifier
ShippingBatchldentifier
Siteldentifier
SiteName
StorageBatchldentifier
Apparatusldentifier
Bottleldentifier
Comment
Contactldentifier
HandlingBatchldentifier
HandlingEndDate
Handlingldentifier
HandlingStartDate
HandlingType
Method Identifier
SampleMatrix
SampleMatrixMediumType
AlternateLaboratoryAnalysisldentifier
AnalysisBatch Identifier
AnalysisEndBatchldentifier
AnalysisEndDate
AnalysisGroupldentifier
AnalysisStartDate
AnalysisType
Apparatusldentifier
Autosamplerlndicator
BackgroundCorrectionlndicator
BackgroundRawDatalndicator
BackgroundType
Bottleldentifier
ClientAnalysisldentifier
Column
Comment
ConfirmationAnalysisldentifier
Contactldentifier
Detectorldentifier
DetectorType
Exclusionlndicator
Typel
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
_
-
-
-
Y
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Type 1t
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
_
-
-
-
Y
-
Y
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Type 2
-
-
-
-
C
-
-
-
-
-
-
-
_
_
_
_
_
-
Y
-
Y
-
Y
Y
-
-
-
-
-
-
-
-
-
-
O
-
-
-
Type3
O
O
O
O
C
O
O
O
O
O
O
O
C
C
O
O
O
O
Y
C
Y
C
Y
Y
O
O
O
O
O
O
O
C
O
O
O
O
O
O
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
47
-------
Requirements for ERLN Data Submissions
ERLN Data Group
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
ERLN Data Element
HeatedPurgelndicator
Instrumentldentifier
InstrumentSeriaIN umber
InterelementCorrectionlndicator
LaboratoryAnalysisldentifier
LaboratoryFileldentifier
Method Identifier
MobilePhase
OriginalLaboratoryAnalysisldentifier
PreparationBatch Identifier
PreparationEndDate
PreparationStartDate
PreparationType
QuantitationBasis
ReferenceDate
ResultBasis
RunBatchldentifier
Standardldentifier
StandardSourceName
Apparatusldentifier
Bottleldentifier
CleanupBatchldentifier
CleanUpEndDate
Cleanupldentifier
CleanUpStartDate
CleanupType
Column
Comment
Contactldentifier
LaboratoryResultStatus
LotNumber
Method Identifier
PreparationBatch Identifier
PreparationEndDate
Preparation Identifier
PreparationStartDate
PreparationType
Typel
_
-
-
-
-
-
Y
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
-
-
-
-
-
Type 1t
_
-
-
-
-
-
Y
-
-
-
-
-
-
-
-
O
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
-
c
-
c
-
Type 2
_
Y
-
-
Y
O
Y
-
-
C
-
-
-
-
-
O
Y
-
-
-
-
C
-
-
-
C
-
-
O
-
-
O
-
c
-
c
-
Type3
C
Y
O
O
Y
O
Y
O
O
C
O
O
O
O
O
O
Y
O
O
O
O
C
C
C
O
C
O
O
O
O
O
O
c
c
O
c
c
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
48
-------
Requirements for ERLN Data Submissions
ERLN Data Group
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
ERLN Data Element
SampleDataGroupType
SampleMatrix
SampleMatrixMediumType
Solvent
BackgroundType
CalibrationBasisldentifier
CalibrationType
CASRegistryNumber
Comment
Exclusionlndicator
ExpectedResult
ExpectedResultUnits
InstrumentResponseldentifier
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LaboratoryResultQualifier
LaboratorySubstanceldentifier
LotNumber
Manuallntegrationlndicator
QuantitationBasis
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultBasis
ResultUncertainty
ResultUnits
Standardldentifier
StandardSourceName
SubstanceGroupldentifier
SubstanceName
SubstanceNameContext
SubstanceType
BackgroundType
CalibrationType
Comment
Exclusionlndicator
Typel
-
-
-
-
-
-
-
C
-
-
-
-
-
-
-
-
C
-
-
-
-
Y
Y
Y
Y
_
O
Y
-
-
-
Y
-
-
-
-
_
-
Type 1t
-
-
-
-
-
-
-
C
-
-
C
C
-
-
-
-
C
O
-
-
-
Y
Y
Y
Y
_
O
Y
-
-
-
Y
-
Y
-
-
_
-
Type 2
C
-
-
-
-
-
-
C
-
Y
C
C
-
-
-
-
C
O
-
-
-
Y
Y
Y
Y
_
O
Y
-
-
-
Y
-
Y
-
-
_
-
Type3
C
O
O
O
O
C
O
C
O
Y
C
C
C
C
O
C
C
O
O
O
O
Y
Y
Y
Y
O
O
Y
C
C
O
Y
O
Y
O
C
O
C
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
49
-------
Requirements for ERLN Data Submissions
ERLN Data Group
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
CharacteristicDetails
CharacteristicDetails
CharacteristicDetails
CharacteristicDetails
CharacteristicDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
ERLN Data Element
InstrumentResponseldentifier
InstrumentResponseTypeName
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LaboratoryResultQualifier
Manual Integration Indicator
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultBasis
ResultUncertainty
ResultUnits
AdditionalResponseldentifier
CASRegistryNumber
Comment
InstrumentResponseldentifier
InstrumentResponseTypeName
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LaboratoryResultQualifier
LaboratorySubstanceldentifier
Result
ResultBasis
ResultUncertainty
ResultUnits
SubstanceName
SubstanceNameContext
CharacteristicName
CharacteristicType
CharacteristicUnits
CharacteristicValue
Comment
Comment
MethodCategory
MethodCodeType
MethodDescription
Typel
_
_
_
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
_
-
Type 1t
_
_
_
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
_
_
_
_
_
-
Type 2
_
_
_
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
C
C
C
C
o
o
o
o
o
Type3
C
C
C
o
C
o
C
o
o
o
o
o
o
o
o
C
o
C
C
o
o
o
o
o
o
o
o
o
C
C
C
C
C
C
o
o
Y
Y
Y
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
50
-------
Requirements for ERLN Data Submissions
ERLN Data Group
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MeasureDetails
MeasureDetails
MeasureDetails
MeasureDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
ERLN Data Element
Methodldentifier
MethodLevel
MethodModificationDescription
MethodModificationldentifier
MethodName
MethodSourceName
MethodType
MethodVersion
MeasureName
MeasureQualifierCode
MeasureUnitCode
MeasureValue
Comment
QualitylndicatorConfidencelnterval
QualitylndicatorConfidenceLevel
QualitylndicatorEquation
QualitylndicatorLimitSource
QualitylndicatorLimitType
QualitylndicatorLowerLimit
QualitylndicatorName
QualitylndicatorType
QualitylndicatorUnits
QualitylndicatorUpperLimit
QualitylndicatorValue
Typel
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Type 1t
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Type 2
Y
O
O
O
O
O
O
O
C
C
C
C
-
-
-
-
-
-
-
-
-
-
-
-
Type3
Y
C
C
C
Y
Y
Y
Y
C
C
C
C
O
O
O
O
O
O
O
O
O
O
O
O
Total Required:
Total Conditionally Required:
Total Optional:
15
2
2
18
6
9
29
22
48
38
54
163
VERSION 1.4-012610
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
Added Amount
Added Amount Step
Aliquot Amount
Analysis Duration
Analyzed Amount
Bias Error Ratio
Calibration Factor
CoefficientaO
Coefficiental
Coefficienta2
CoefficientaS
Column Internal Diameter
Column Length
Correction Factor
Correlation Coefficient
Counting Error
Counts
Difference Error Ratio
Dilution Factor
Drift
Efficiency
Energy
Filter Size
Final Amount
Flow Rate
Frequency
Gradient
Handling Duration
Applicable Data Groups
SubstanceldentificationDetails
SubstanceldentificationDetails
AnalysisDetails, SamplePreparationDetails
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
AnalysisDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails, SamplePreparationDetails
AnalysisDetails, SamplePreparationDetails
AnalysisDetails, SamplePreparationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails, InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails
AnalysisDetails, InstrumentResponseDetails
SamplePreparationDetails, AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SampleDetails, SampleHandlingDetails,
SamplePreparationDetails, AnalysisDetails
SamplePreparationDetails, AnalysisDetails
AnalysisDetails
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
AnalysisDetails
SampleHandlingDetails
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
52
-------
Requirements for ERLN Data Submissions
Measure Name
Handling Factor
Initial Amount
Injection Volume
Mass
Mass Charge Ratio
Mean Calibration Factor
Mean Relative Response
Mean Relative Response Factor
Mean Retention Time
Number Of Dilutions
Organism Length
Peak Ratio
Percent Match
Percent Breakdown
Percent Difference
Percent Recovery
Percent Relative Standard Deviation
Percent Valley
Quench
Relative Response
Relative Response Factor
Relative Retention Time
Relative Percent Difference
Relative Retention Time
Resolution
Resolution Basis
Response
Retention Time
Sample Amount
Screen Result
Applicable Data Groups
SampleHandlingDetails
SampleHandlingDetails, SamplePreparationDetails
AnalysisDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails
SampleDetails
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
AnalysisDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
InstrumentResponseDetails
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SampleDetails, SampleHandlingDetails,
SamplePreparationDetails, AnalysisDetails
SampleDetails
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
53
-------
Requirements for ERLN Data Submissions
Measure Name
Signal To Noise Ratio
Standard Concentration
Standard Final Amount
Standard Deviation
Tailing Factor
Wavelength
Weighting Factor Type
Yield
Applicable Data Groups
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails, SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
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.4-012610
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.4-012610 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
AdditionalResponseldentifier
AgreementModificationDescription
AgreementModifi cation Identifier
AgreementNumber
AlternateLaboratoryAnalysisldentifier
AlternateLaboratorySampleldentifier
AnalysisBatch Identifier
AnalysisEndBatch Identifier
AnalysisEndDate
AnalysisGroupldentifier
AnalysisRequestldentifier
Format
Text
Text
Text
Text
Text
Text
Text
Text
Date
Text
Text
Category
Identification
Description
Description
Identification
Identification
Identification
Association/Grouping
Association/Grouping
Date
Association/Grouping
Identification
Business Rule
Definition
A laboratory-defined identifier that identifies a
single peak measurement from a series of
replicate measurements.
Text that describes any modifications made to
the laboratory's contract.
A client-defined identifier for any modifications
made to the laboratory's contract.
A client-defined contract number that specifies
the contract or agreement under which the
laboratory analyzes the samples.
An alternate laboratory identifier for an analysis.
An alternate laboratory identifier for a sample.
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.
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.
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.
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.
A client-defined identifier for the paperwork that
authorizes the analyses of specific samples by
listed methods.
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
56
-------
Requirements for ERLN Data Submissions
Data Element
AnalysisStartDate
AnalysisType
AnalyticalServiceRequestldentifier
Apparatusldentifier
Autosamplerlndicator
BackgroundCorrectionlndicator
BackgroundRawDatalndicator
BackgroundType
Billingldentifier
Bottleldentifier
BottleType
CalibrationBasisldentifier
CalibrationType
Format
Date
Limited List
Text
Text
Boolean
Boolean
Boolean
Limited List
Text
Text
Limited List
Text
Limited List
Category
Date
Categorization
Identification
Identification
Indicator/Boolean
Indicator/Boolean
Indicator/Boolean
Categorization
Identification
Identification
Categorization
Identification
Categorization
Business Rule
Definition
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.
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.
A client-defined number or identifier that
specifies the service request.
The laboratory-defined identifier for the analytical
system used to process the sample or aliquot.
Indicates whether or not an autosampler was
used.
Indicates whether or not background correction
was done.
Indicates whether or not background raw data
was generated when background correction was
done.
The type of background correction performed
during an analysis.
A client-defined identifier to submit with the data
for billing purposes.
An identifier for the container containing the
sample being analyzed.
The size and type of container used to contain
the sample.
The node (substance or Peak) that contains the
calibration information for a given substance.
The calibration model used (for a particular
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
57
-------
Requirements for ERLN Data Submissions
Data Element
CASRegistryNumber
CharacteristicName
CharacteristicType
CharacteristicUnits
CharacteristicValue
CleanupBatchldentifier
CleanUpEndDate
Cleanupldentifier
CleanUpStartDate
CleanupType
ClientAnalysisldentifier
ClientSampleldentifier
ClientSubstanceldentifier
ClientSubstanceName
Column
Comment
Format
Text
Text
Text
Limited List
Text
Date
Text
Date
Limited List
Text
Text
Text
Text
Text
Text
Category
Identification
Description
Categorization
Categorization
Association/Grouping
Date
Identification
Date
Categorization
Identification
Identification
Identification
Description
Description
Comment
Business Rule
Definition
substance or peak) to define the initial calibration
curve for a method.
The Chemical Abstract Service (CAS) registry
number for a substance.
A descriptive term used to identify the
characteristic being measured.
A term that identifies the type of characteristic
being reported.
Units for the value of a characteristic.
A measured or observed value for the
characteristic being reported. The value can
either be numeric or text based on the
characteristic being reported.
A laboratory-defined identifier that is used to link
multiple sample aliquots that are cleaned up
together for processing by one method.
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.
A laboratory-defined identifier for this cleanup
event for this aliquot.
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.
A term that identifies the specific cleanup
performed when multiple options are given within
the referenced method.
A client-defined identifier for an analysis.
A client-defined identifier that uniquely identifies
a single sample that is subjected to an analysis.
A client-defined identifier for a substance.
A client-defined common name for a substance.
The name or type of the column or cartridge
used by this method.
A free-form remark, observation, explanation, or
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
58
-------
Requirements for ERLN Data Submissions
Data Element
Compositelndicator
ConfirmationAnalysisldentifier
ContactElectronicAddress
ContactFullName
Contactldentifier
ContactTitle
ContactType
Coolerldentifier
CreatedDate
DataExchangeTemplateldentifier
DataExchangeTemplatelmplementationldentifier
DataExchangeTemplatelmplementationVersion
DataExchangeTemplateVersion
DataPackageldentifier
Format
Boolean
Text
Text
Text
Text
Text
Limited List
Text
Date
Text
Text
Text
Text
Text
Category
Indicator/Boolean
Identification
Description
Description
Identification
Description
Categorization
Identification
Date
Identification
Identification
Description
Description
Identification
Business Rule
Identifier shall be
used as the
relational key for
data groups to
reference a
particular contact.
Definition
expansion text that can occur in any parent data
element.
Indicates whether or not the sample as received
by the laboratory is a composite.
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.
The electronic address (e-mail) of the person at
the laboratory who takes final responsibility for
the data.
The person at the laboratory who takes final
responsibility for the data.
A laboratory-defined unique identifier for an
individual within an organization.
The job title of the person at the laboratory who
takes final responsibility for the data.
The type of the person at the laboratory who
takes final responsibility for the data.
A client-defined unique identifier for the cooler or
other shipping container used to transport the
sample to the laboratory.
The date (and time, if required) a Quality Control
(QC) sample was generated or derived in the
laboratory.
An identifier that specifies the format of an
electronic data deliverable.
An identifier that identifies the specific
implementation (Document Type Definition or
Schema) of an electronic data deliverable.
A value that identifies the version of the specific
implementation (Document Type Definition or
Schema) of an electronic data deliverable.
A value that specifies the version of the format of
an electronic data deliverable.
A laboratory-defined identifier for this data
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
59
-------
Requirements for ERLN Data Submissions
Data Element
DataPackageName
DataPackageVersion
DateFormat
Detectorldentifier
DetectorType
Exclusionlndicator
ExpectedResult
ExpectedResultUnits
FieldEquipmentBatch Identifier
Filteredlndicator
GeneratingSystemldentifier
GeneratingSystemVersion
HandlingBatch Identifier
Format
Text
Text
Text
Text
Limited List
Boolean
Text
Limited List
Text
Boolean
Text
Text
Text
Category
Description
Description
Description
Identification
Categorization
Indicator/Boolean
Result Measurement
Result Measurement
Association/Grouping
Indicator/Boolean
Identification
Description
Association/Grouping
Business Rule
Only report a
value when not
included.
Definition
deliverable package. This identifier applies to a
single deliverable.
A laboratory-defined title for this data deliverable
package.
If the laboratory resubmits a data package, this
data element distinguishes between the different
versions.
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.
A laboratory-defined unique identifier for a
specific detector.
The type of detector used in the instrumental
analysis.
Indicates whether or not this item is to be
excluded or evaluated as part of this data
package.
The expected or theoretical result of a substance
that has been spiked into a sample aliquot or a
standard at any time during the analysis process.
Units for the expected result.
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.
Indicates whether or not the sample as received
by the laboratory was field filtered.
A laboratory-defined identifier that names the
software system used to generate an electronic
data deliverable. This identifier may be built into
commercial software.
A laboratory-defined version number of the
software system used to generate an electronic
data deliverable.
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.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
60
-------
Requirements for ERLN Data Submissions
Data Element
HandlingEndDate
Handlingldentifier
HandlingStartDate
HandlingType
HeatedPurgelndicator
Instrumentldentifier
InstrumentQualityControlSampleldentifier
InstrumentReponseldentifier
InstrumentResponseTypeName
InstrumentSerialNumber
InterelementCorrectionlndicator
IntermediateResult
IntermediateResultUncertainty
Format
Date
Text
Date
Limited List
Boolean
Text
Text
Text
Text
Text
Boolean
Text
Numeric
Category
Date
Identification
Date
Categorization
Indicator/Boolean
Identification
Identification
Identification
Description
Identification
Indicator/Boolean
Result Measurement
Result Measurement
Business Rule
Definition
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.
A laboratory-defined identifier for this handling
event for this sample.
The date (and time, if required) of handling of
this sample. If handled over a range of dates,
this is the start date.
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.
Indicates whether or not a heated purge was
used forvolatiles analysis.
A laboratory-defined identifier for an instrument.
A laboratory-defined identifier that uniquely
identifies a single instrument Quality Control
(QC) analysis or group of analyses.
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.
Defines the instrument response being recorded.
Example: Peak
The serial number of the instrument used for this
analysis.
Indicates whether or not Inductively Coupled
Plasma (ICP) interelement or intersubstance
correction factors were applied.
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.
The estimated amount, expressed as a
symmetric interval centered on the
IntermediatResult, by which the
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
61
-------
Requirements for ERLN Data Submissions
Data Element
IntermediateResultUnits
LaboratoryAnalysisldentifier
LaboratoryFileldentifier
LaboratoryNarrative
LaboratoryQualifiersDefinition
LaboratoryReceiptDate
LaboratoryReportedDate
LaboratoryReportingBatch Identifier
LaboratoryResultQualifier
LaboratoryResultStatus
Format
Limited List
Text
Text
Text
Text
Date
Date
Text
Text
Text
Category
Result Measurement
Identification
Identification
Description
Description
Date
Date
Association/Grouping
Description
Description
Business Rule
Definition
IntermediateResult may differ from the true value
due to all effects related to analysis by the
laboratory.
Units for an intermediate result.
A laboratory-defined identifier for an analysis that
uniquely identifies a single run fora 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.
The file, and path if required, name where the
raw data from the analysis is stored in the
laboratory.
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.
A formal statement of the meaning or
significance of any lab qualifier(s) reported by the
laboratory.
The date (and time, if required) that the sample
was received in the laboratory.
The date (and time, if required) that the data
package was reported by the laboratory to the
client.
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.
A laboratory-assigned string of result qualifiers
(usually a single character for each qualifier),
based on client -defined rules and values.
A laboratory-assigned state or condition for the
results of a particular sample and method.
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
62
-------
Requirements for ERLN Data Submissions
Data Element
LaboratorySampleldentifier
LaboratorySubstanceldentifier
LaboratoryType
Locationldentifier
LocationName
LotNumber
Manuallntegrationlndicator
MeasureName
MeasureQualifierCode
MeasureUnitCode
MeasureValue
MethodBatch Identifier
MethodCategory
Format
Text
Text
Limited List
Text
Text
Text
Boolean
Text
Text
Limited List
Text
Text
Limited List
Category
Identification
Identification
Categorization
Identification
Description
Identification
Indicator/Boolean
Description
Description
Categorization
Description
Association/Grouping
Categorization
Business Rule
Definition
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.
A laboratory-defined identifier for a substance.
Text that describes the laboratory analyzing the
sample.
A client-defined identifier of the sampling location
at a particular site.
A client-defined name of the sampling location at
a particular site.
A manufacturer-assigned batch number for a
substance or other materials used in a particular
analysis.
Indicates whether or not manual integration was
used.
Describes the measure being recorded.
A code used to identify any qualifying issues that
affect the results.
The code that represents the unit for measuring
the item.
The recorded dimension, capacity, quality, or
amount of something ascertained by measuring
or observing.
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.
The general class or common name for the
group of substances being measured by a given
method for the sample.
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
63
-------
Requirements for ERLN Data Submissions
Data Element
MethodCodeType
MethodDescription
Methodldentifier
MethodLevel
MethodModificationDescription
MethodModificationldentifier
MethodName
MethodSourceName
MethodType
MethodVersion
MobilePhase
NumberOfBottles
Organizationldentifier
Format
Limited List
Text
Text
Text
Text
Text
Text
Text
Limited List
Text
Text
Text
Text
Category
Categorization
Description
Identification
Description
Description
Identification
Description
Description
Categorization
Description
Description
Description
Identification
Business Rule
Report the
WebEDR Method
Identifier listed on
the Method
Profile.
Laboratories must
always report the
Client method, all
other methods are
optional.
Definition
The published reference code of the method
used by the laboratory to analyze the sample.
A brief summary that provides general
descriptive information about the method.
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.
The approximate level of substances in the
sample, usually specified in client-defined
concentration ranges and determined via a
screening procedure.
Text that identifies any modifications made to the
published reference method.
A client-defined identifier that identifies
modifications made to the published reference
method.
The published name or title of the method used
by the laboratory to analyze the sample.
The author or publishing agency of the method
used by the laboratory to analyze the sample.
A term that identifies the technology or method
classification of the method used by the
laboratory to analyze the sample.
The version or revision of the method used by
the laboratory to analyze the sample.
The mobile phase composition used for High
Performance Liquid Chromatography (HPLC), or
other similar procedures.
The number of containers received by the
laboratory for this sample analysis.
The identifier associated with an organization
(e.g., laboratory, client, subcontractor, etc.)
performing a specific role in context of the
project.
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
64
-------
Requirements for ERLN Data Submissions
Data Element
OrganizationLocationAddress
OrganizationLocationAddressCity
OrganizationLocationAddressCountry
OrganizationLocationAddressState
OrganizationLocationAddressZipCode
OrganizationMailingAddress
OrganizationName
OrganizationTelephoneNumber
OrganizationType
OriginalClientSampleldentifier
OriginalLaboratoryAnalysisldentifier
OriginalLaboratorySampleldentifier
PhaseAnalyzed
PreparationBatchldentifier
PreparationEndDate
Format
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Date
Category
Description
Description
Description
Description
Description
Description
Description
Description
Categorization
Identification
Identification
Identification
Description
Association/Grouping
Date
Business Rule
Definition
The primary street address of the location of the
laboratory performing this analysis.
The city in which the laboratory performing the
analysis is located.
The country in which the laboratory performing
the analysis is located.
The state in which the laboratory performing the
analysis is located.
The ZIP or postal code of the laboratory
performing the analysis.
The secondary address of the laboratory
performing this analysis, if applicable. This
would include additional address information
(e.g., suite, maildrop, etc.).
The name of an organization (e.g., laboratory,
client, subcontractor, etc.) performing a specific
role in context of the project.
The 10-digit telephone number of the laboratory
performing the analysis.
The role of the organization in context of the
project.
The client-defined identifier of the original regular
sample from which the Quality Control (QC)
sample was derived.
The laboratory analysis identifier (LabAnalysisID)
of a previous or original analysis this analysis is
based on.
The laboratory-defined identifier of the original
sample from which the Quality Control (QC)
sample was derived.
That portion or fraction of a multiphase sample
that was actually analyzed.
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.
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.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
65
-------
Requirements for ERLN Data Submissions
Data Element
Preparationldentifier
PreparationStartDate
PreparationType
Preservative
PreservedBy
Priorityldentifier
Projectldentifier
ProjectName
QualityControlCategory
QualityControlSampleLinkage
QualitylndicatorConfidencelnterval
Quality IndicatorConfidenceLevel
Quality IndicatorEquation
Format
Text
Date
Limited List
Text
Text
Text
Text
Text
Limited List
Text
Numeric
Numeric
Text
Category
Identification
Date
Categorization
Description
Description
Identification
Identification
Description
Categorization
Description
Measurement
Measurement
Description
Business Rule
Definition
A laboratory-defined identifier for this preparation
event for this sample aliquot.
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.
A client-defined description used to define the
specific preparation performed when multiple
options are given within the referenced method.
The chemical compound that was added to the
sample to protect against decay or
decomposition.
The organization that added preservative to the
sample.
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.
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.
A descriptive name or label for the project for
which data is being reported for
A term that identifies the basic properties or
category of a particular method Quality Control
(QC) sample.
For a Quality Control (QC) sample, specifies
which batch is the basis for the association
between the QC sample and the regular
samples.
The estimated range being calculated from a
given set of sample data.
The probability values associated with a
confidence interval expressed as a percentage.
The name or arithmetic calculation used to
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
66
-------
Requirements for ERLN Data Submissions
Data Element
QualitylndicatorLimitSource
QualitylndicatorLimitType
Quality IndicatorLowerLimit
QualitylndicatorName
QualitylndicatorType
Quality IndicatorUnits
Quality IndicatorUpperLimit
QualitylndicatorValue
QuantitationBasis
Quarantinelndicator
ReferenceDate
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultBasis
ResultUncertainty
Format
Limited List
Limited List
Numeric
Text
Limited List
Numeric
Numeric
Numeric
Text
Boolean
Date
Text
Limited List
Limited List
Text
Text
Numeric
Category
Categorization
Categorization
Measurement
Description
Categorization
Measurement
Measurement
Measurement
Description
Indicator/Boolean
Date
Description
Categorization
Categorization
Result Measurement
Description
Result Measurement
Business Rule
Definition
determine the value and or limits of the quality
indicator.
The author or publishing agency of the indicator
used by the laboratory to analyze the sample.
The organization or entity that is responsible for
the limit.
The lowest boundary or limit associated with a
quality indicator measurement.
The name of the data quality indicator being
measured.
A term that identifies the classification of the
quality indicator.
Units of the quality indicator.
The uppermost boundary or limit associated with
a quality indicator measurement.
The calculated value of the quality indicator
being measured.
The conditions upon which sample quantitation is
performed (e.g., using internal standards).
Indicates whether or not the sample, as received
by the laboratory, is to be quarantined.
The date (and time, if required) used for decay
correction in radiochemical analyses.
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.
A term that identifies how the reporting limit was
determined or reported.
Units for the reporting limit.
The final calculated result for a substance
accounting for all sample aliquot amounts,
dilutions, moisture determinations, etc
The basis upon which the final results were
calculated.
The estimated amount, expressed as a
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
67
-------
Requirements for ERLN Data Submissions
Data Element
ResultUnits
RunBatchldentifier
SampleChainofCustodyldentifier
SampleCollectionEndDate
SampleCollectionStartDate
SampleDataGroupType
Sampleldentifier
SampleMatrix
SampleType
SamplingBatch Identifier
ShippingBatchldentifier
Siteldentifier
Format
Limited List
Text
Text
Date
Date
Limited List
Text
Limited List
Limited List
Text
Text
Text
Category
Result Measurement
Association/Grouping
Identification
Date
Date
Categorization
Identification
Categorization
Categorization
Association/Grouping
Association/Grouping
Identification
Business Rule
Report client
identifier for field
generated
samples and
laboratory
identifier for
laboratory or
instrument
samples.
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 aliquot by the laboratory.
Units for the result.
A laboratory-defined identifier that is used to link
multiple analyses performed on one instrument
and under the control of one initial calibration.
A client-defined identifier for the chain of custody
document and/or tracking record associated with
receipt of this sample in the laboratory.
The date (and time, if required), of the end of the
sample collection period, if the sample was
collected over a period of time.
The date (and time, if required) the sample was
collected. If the sample was collected over a
range of dates, this is the start date.
Whether or not the data in this node is related to
a preparation or cleanup activity.
A unique 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 unique
identifier for the sample.
An identifier of the general sample substrate or
media.
The client-defined term that identifies the specific
type of sample being analyzed.
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.
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.
A client-defined identifier for the broadly defined
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
68
-------
Requirements for ERLN Data Submissions
Data Element
SiteName
Solvent
Standardldentifier
StandardSourceName
StorageBatchldentifier
SubstanceGroupldentifier
SubstanceName
SubstanceNameContext
SubstanceType
Format
Text
Text
Text
Text
Text
Text
Limited List
Limited List
Limited List
Category
Description
Description
Identification
Description
Association/Grouping
Association/Grouping
Description
Description
Categorization
Business Rule
Definition
site this data is being reported for.
A descriptive name for the broadly defined site
this data is being reported for.
The substance(s), usually a liquid that was used
to dissolve another liquid, gas or solid during the
extraction of the sample.
A laboratory-defined identifier for a purchased or
laboratory-prepared standard, such as a spiking
material or a calibration standard, used in this
analysis.
The origin or manufacturer of a standard used in
this analysis.
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).
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.
The published reference name for a substance
The published reference source for a
substance's name.
A term that identifies the type of substance
reported.
VERSION 1.4-012610
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_Verification,
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,
lnterference_Check_Standard_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.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
70
-------
Requirements for ERLN Data Submissions
End_Calibration_Check_Standard,
lnitial_Calibration_Check_Standard,
lnitial_Calibration_Standards,
lnstrument_Performance_Check_Solution,
Tuning_Solution
VERSION 1.4-012610
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.1 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.4-012610 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
text
< S ampl eMatrix>text
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.I.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.4-012610 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.4-012610 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.4-012610 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. SubstanceIdentificationDetails
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: Sample Identifier,). 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.
Table 13 DTD Required Data Groups
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 76
-------
Requirements for ERLN Data Submissions
ERLN Data Group
ProjectDetails
ProjectDetails
ProjectDetails
OrganizationDetails
SampleDetails
SampleDetails
AnalysisDetails
SubstanceldentificationDetails
MethodDetails
ERLN Data Element
AnalyticalServiceRequestldentifier
DataPackageldentifier
Projectldentifier
Organizationldentifier
Sampleldentifier
SampleMatrix
Methodldentifier
SubstanceName
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
PointofContactDetails
Character! sticDetails
Character! sticDetails
MeasureDetails
MeasureDetails
ERLN Data Element
Contactldentifier
CharacteristicName
CharacteristicValue
MeasureName
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.4-012610
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.1 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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 78
-------
Requirements for ERLN Data Submissions
D.2 What is the Basic SEDD Hierarchy?
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 Using 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.4-012610 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
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
ProjectDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
PointofContactDetails
ERLN Data Element
AgreementModificationDescription
AgreementModification Identifier
AgreementNumber
AnalyticalServiceRequestldentifier
Comment
DataExchangeTemplateldentifier
Data ExchangeTemplatelmplementation Identifier
DataExchangeTemplatelmplementationVersion
DataExchangeTemplateVersion
DataPackageldentifier
DataPackageName
DataPackageVersion
DateFormat
GeneratingSystemldentifier
GeneratingSystemVersion
LaboratoryNarrative
LaboratoryQualifiersDefinition
LaboratoryReportedDate
Organizationldentifier
Projectldentifier
ProjectName
Siteldentifier
SiteName
Comment
ContactElectronicAddress
ContactFullName
ContactTitle
ContactType
Organizationldentifier
OrganizationLocationAddress
OrganizationLocationAddressCity
OrganizationLocationAddressCountry
OrganizationLocationAddressState
OrganizationLocationAddressZipCode
OrganizationMailingAddress
OrganizationName
OrganizationTelephoneNumber
SEDD Node
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Header
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
Contactlnformation
SEDD Data Element
LabContractModificationDescription
LabContractModificationID
LabContract
Comment
Comment
EDDID
EDDImplementationID
EDDImplementationVersion
EDDVersion
LabDataPackagelD
LabDataPackageName
LabDataPackageVersion
DateFormat
GeneratingSystemID
GeneratingSystemVersion
LabNarrative
LabQualifiersDefinition
LabReportedDate
LabID
ProjectID
ProjectName
SitelD
SiteName
Comment
LabPointOfContactElectronicAddress
LabPointOfContact
LabPointOfContactTitle
LabPointOfContactType
LabID
LabAddressI
LabCity
LabCountry
LabState
LabZipCode
LabAddress2
LabName
LabTelephoneNumber
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
80
-------
Requirements for ERLN Data Submissions
ERLN Data Group
PointofContactDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
ERLN Data Element
OrganizationType
AlternateLaboratorySampleldentifier
AnalysisRequestldentifier
Billingldentifier
Bottleldentifier
BottleType
Sampleldentifier
Comment
Compositelndicator
Coolerldentifier
CreatedDate
FieldEquipmentBatch Identifier
Sampleldentifier
Filteredlndicator
LaboratorySampleldentifier
LaboratoryReceiptDate
LaboratoryReportingBatchldentifier
LaboratorySampleldentifier
LaboratoryType
Locationldentifier
LocationName
MethodBatchldentifier
NumberOfBottles
OriginalClientSampleldentifier
OriginalLaboratorySampleldentifier
PhaseAnalyzed
Preservative
PreservedBy
Priorityldentifier
QualityControlCategory
QualityControlSampleLinkage
Quarantinelndicator
SampleChainofCustody Identifier
SampleCollectionEndDate
SampleCollectionStartDate
SampleMatrix
SampleMatrixMediumType
SampleType
SamplingBatchldentifier
SEDD Node
Contactlnformation
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
InstrumentQC
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SEDD Data Element
LabType
AlternateLabSamplelD
AnalysisRequestID
BillingID
BottlelD
BottleType
ClientSamplelD
Comment
Composite
CoolerlD
CreatedDate
EquipmentBatch
FieldSamplelD
Filtered
LablnstrumentQCID
LabReceiptDate
LabReportingBatch
LabSamplelD
LabType
Location ID
LocationName
MethodBatch
Bottles
OriginalClientSamplelD
OriginalLabSamplelD
PhaseAnalyzed
Preservative
PreservedBy
PrioritylD
QCCategory
QCLinkage
Quarantine
CustodylD
CollectedEndDate
CollectedDate
MatrixlD
MatrixMedium
QCType
SamplingBatch
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
81
-------
Requirements for ERLN Data Submissions
ERLN Data Group
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
ERLN Data Element
ShippingBatchldentifier
Siteldentifier
SiteName
StorageBatch Identifier
Contactldentifier
Contactldentifier
Apparatusldentifier
Bottleldentifier
Comment
HandlingBatch Identifier
HandlingEndDate
Handlingldentifier
HandlingStartDate
HandlingType
Organizationldentifier
OrganizationName
SampleMatrix
SampleMatrixMediumType
Contactldentifier
AlternateLaboratoryAnalysisldentifier
AnalysisBatch Identifier
AnalysisEndBatch Identifier
AnalysisEndDate
AnalysisGroupldentifier
AnalysisStartDate
AnalysisType
Apparatusldentifier
Autosamplerlndicator
BackgroundCorrectionlndicator
BackgroundRawDatalndicator
BackgroundType
Bottleldentifier
ClientAnalysisldentifier
Column
Comment
ConfirmationAnalysisldentifier
Detectorldentifier
DetectorType
SEDD Node
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
SamplePlusMethod
Handling
Handling
Handling
Handling
Handling
Handling
Handling
Handling
Handling
Handling
Handling
Handling
Handling
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
SEDD Data Element
ShippingBatch
SitelD
SiteName
StorageBatch
RequestorlD, RequestorName
Analyst
ApparatusID
Bottle ID
Comment
HandlingBatch
HandledEndDate
HandlingID
HandledDate
HandlingType
LabID
LabName
MatrixlD
MatrixMedium
Analyst
AlternateLabAnalysisID
AnalysisBatch
AnalysisBatchEnd
AnalyzedEndDate
AnalysisGroupID
AnalyzedDate
AnalysisType
ApparatusID
Autosampler
BackgroundCorrection
BackgroundRawData
BackgroundType
BottlelD
ClientAnalysisID
Column
Comment
ConfirmationAnalysisID
DetectorlD
DetectorType
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
82
-------
Requirements for ERLN Data Submissions
ERLN Data Group
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
AnalysisDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
ERLN Data Element
Exclusionlndicator
HeatedPurgelndicator
Instrumentldentifier
InstrumentSerialNumber
InterelementCorrection Indicator
LaboratoryAnalysisldentifier
LaboratoryFileldentifier
MobilePhase
Organizationldentifier
OrganizationName
OriginalLaboratoryAnalysisldentifier
PreparationBatchldentifier
PreparationEndDate
PreparationStartDate
PreparationType
QuantitationBasis
ReferenceDate
ResultBasis
RunBatchldentifier
Standardldentifier
StandardSourceName
Contactldentifier
Apparatusldentifier
Bottleldentifier
CleanupBatch Identifier
CleanUpEndDate
Cleanupldentifier
CleanUpStartDate
CleanupType
Column
Comment
LaboratoryResultStatus
LotNumber
Organizationldentifier
OrganizationName
PreparationBatchldentifier
PreparationEndDate
SEDD Node
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
Analysis
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
SEDD Data Element
Inclusion
HeatedPurge
InstrumentID
InstrumentSerialNumber
InterelementCorrection
LabAnalysisID
LabFilelD
MobilePhase
LabID
LabName
OriginalLabAnalysisID
PreparationBatch
PreparedEndDate
PreparedDate
PreparationType
QuantitationBasis
ReferenceDate
ResultBasis
RunBatch
StandardID
StandardSource
Analyst
ApparatusID
BottlelD
CleanupBatch
CleanedUpEndDate
CleanupID
CleanedUpDate
CleanupType
Column
Comment
LabResultStatus
LotNumber
LabID
LabName
PreparationBatch
PreparedEndDate
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
83
-------
Requirements for ERLN Data Submissions
ERLN Data Group
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SamplePreparationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
ERLN Data Element
Preparationldentifier
PreparationStartDate
PreparationType
SampleDataGroupType
SampleMatrix
SampleMatrixMediumType
Solvent
BackgroundType
CalibrationBasisldentifier
CalibrationType
CASRegistryNumber
Substanceldentifier
SubstanceName
Comment
Exclusionlndicator
ExpectedResult
ExpectedResultUnits
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LaboratoryResultQualifier
LaboratorySubstanceldentifier
LotNumber
Manuallntegrationlndicator
InstrumentResponseldentifier
QuantitationBasis
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultBasis
ResultUncertainty
ResultUnits
Standardldentifier
StandardSourceName
SubstanceGroupldentifier
SubstanceName
SubstanceNameContext
SEDD Node
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
PreparationPlusCleanup
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Not applicable
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
Analyte
SEDD Data Element
Preparation ID
PreparedDate
PreparationType
PreparationPlusCleanupType
MatrixlD
MatrixMedium
Solvent
BackgroundType
CalibrationBasis
CalibrationType
CASRegistryNumber
ClientAnalytelD
ClientAnalyteName
Comment
Inclusion
ExpectedResult
ExpectedResultUnits
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LabQualifiers
Lab Analyte ID
LotNumber
Manuallntegration
PeakID
QuantitationBasis
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultUncertainty
ResultUnits
StandardID
StandardSource
AnalyteGroupID
AnalyteName
AnalyteNameContext
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
84
-------
Requirements for ERLN Data Submissions
ERLN Data Group
SubstanceldentificationDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
InstrumentResponseAdditionalDetails
CharacteristicDetails
CharacteristicDetails
CharacteristicDetails
CharacteristicDetails
ERLN Data Element
SubstanceType
BackgroundType
CalibrationType
Comment
Exclusionlndicator
InstrumentResponseTypeName
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LaboratoryResultQualifier
Manuallntegration Indicator
InstrumentResponseldentifier
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultBasis
ResultUncertainty
ResultUnits
CASRegistryNumber
Comment
InstrumentResponseTypeName
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LaboratoryResultQualifier
LaboratorySubstanceldentifier
InstrumentResponseldentifier
AdditionalResponseldentifier
Result
ResultBasis
ResultUncertainty
ResultUnits
SubstanceName
SubstanceNameContext
CharacteristicName
CharacteristicType
CharacteristicUnits
CharacteristicValue
SEDD Node
Analyte
Peak
Peak
Peak
Peak
Not applicable
Peak
Peak
Peak
Peak
Peak
Peak
Peak
Peak
Peak
Peak
Peak
Peak
Peak
PeakComparison
PeakComparison
Not applicable
PeakReplicate
PeakReplicate
PeakReplicate
PeakComparison
PeakComparison
PeakComparison
PeakReplicate
PeakReplicate
Not applicable
PeakReplicate
PeakReplicate
PeakComparison
PeakComparison
Characteristic
Characteristic
Characteristic
Characteristic
SEDD Data Element
AnalyteType
BackgroundType
CalibrationType
Comment
Inclusion
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LabQualifiers
Manuallntegration
PeakID
ReportingLimit
ReportingLimitType
ReportingLimitUnits
Result
ResultUnits
ResultUncertainty
ResultUnits
CASRegistryNumber
Comment
IntermediateResult
IntermediateResultUncertainty
IntermediateResultUnits
LabQualifiers
Lab Analyte ID
PeakID
PeakReplicatelD
Result
ResultUncertainty
ResultUnits
AnalyteName
AnalyteNameContext
CharacteristicName
CharacteristicType
CharacteristicUnits
CharacteristicValue
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
85
-------
Requirements for ERLN Data Submissions
ERLN Data Group
CharacteristicDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MethodDetails
MeasureDetails
MeasureDetails
MeasureDetails
MeasureDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
DataQualitylndicatorDetails
ERLN Data Element
Comment
Comment
MethodCategory
MethodCodeType
MethodDescription
Methodldentifier
Method Level
MethodModificationDescription
MethodModificationldentifier
MethodName
MethodSourceName
MethodType
MethodVersion
MeasureName
MeasureQualifierCode
MeasureUnitCode
MeasureValue
Comment
QualitylndicatorConfidencelnterval
QualitylndicatorConfidenceLevel
QualitylndicatorEquation
QualitylndicatorLimitSource
QualitylndicatorLimitType
QualitylndicatorLowerLimit
QualitylndicatorName
QualitylndicatorType
QualitylndicatorUnits
QualitylndicatorUpperLimit
QualitylndicatorValue
SEDD Node SEDD Data Element
Characteristic 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 Methodldentifer 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.
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.
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
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.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
86
-------
Requirements for ERLN Data Submissions
Table 16. SEDD Measure Mapping
Measure Name
Added Amount
Added Amount Step
Aliquot Amount
Analysis Duration
Analyzed Amount
Bias Error Ratio
Calibration Factor
CoefficientaO
Coefficiental
Coefficienta2
CoefficientaS
Column Internal Diameter
Column Length
Correction Factor
Correlation Coefficient
Counting Error
Counts
Difference Error Ratio
Dilution Factor
Drift
Efficiency
Energy
ERLN Data Groups
SubstanceldentificationDetails
SubstanceldentificationDetails
AnalysisDetails,
SamplePreparationDetails
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
AnalysisDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails,
SamplePreparationDetails
AnalysisDetails,
SamplePreparationDetails
AnalysisDetails,
SamplePreparationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails
AnalysisDetails,
InstrumentResponseDetails
SamplePreparationDetails,
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails
InstrumentResponseDetails,
Applicable SEDD Node
Analyte
Analyte
Analysis, PreparationPlusCleanup
Analysis, Analyte, Peak, Peak
Replicate
Analysis
Analyte, Peak
Analyte, Peak
Analyte, Peak
Analyte, Peak
Analyte, Peak
Analyte, Peak
Analysis, PreparationPlusCleanup
Analysis, PreparationPlusCleanup
Analyte Comparison
Analyte, Peak
Analyte, Peak
Analysis, Analyte, Peak
Analyte, Peak
Analysis
Analysis, Analyte, Peak
PreparationPlusCleanup, Analysis,
Analyte, Peak
Peak, Peak Comparison
SEDD Data Element
AmountAdded
AmountAddedLocation
AliquotAmount
AnalysisDuration
AnalyzedAmount
BiasErrorRatio
CalibrationFactor
CoeffaO
Coeffal
Coeffa2
CoeffaS
Column InternalDiameter
ColumnLength
CorrectionFactor
CorrelationCoeff
CountingError
DifferenceErrorRatio
DilutionFactor
Drift
Efficiency
Energy
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
87
-------
Requirements for ERLN Data Submissions
Filter Size
Final Amount
Flow Rate
Frequency
Gradient
Handling Duration
Handling Factor
Initial Amount
Injection Volume
Mass
Mass Charge Ratio
Mean Calibration Factor
Mean Relative Response
Mean Relative Response Factor
Mean Retention Time
Number Of Dilutions
Organism Length
Peak Ratio
Percent Match
Percent Breakdown
Percent Difference
Percent Recovery
Percent Relative Standard Deviation
Percent Valley
InstrumentResponseAdditionalDetails
SampleDetails,
SampleHandlingDetails,
SamplePreparationDetails,
AnalysisDetails
SamplePreparationDetails,
AnalysisDetails
AnalysisDetails
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
AnalysisDetails
SampleHandlingDetails
SampleHandlingDetails
SampleHandlingDetails,
SamplePreparationDetails
AnalysisDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails
SampleDetails
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SamplePlusMethod, Handling,
PreparationPlusCleanup, Analysis
PreparationPlusCleanup, Analysis
Analysis
Peak, Peak Comparison
Analysis
Handling
Handling
Handling, PreparationPlusCleanup
Analysis
Analyte, Peak, Peak Comparison,
Peak Replicate
Peak, Peak Comparison
Analyte, Peak
Analyte
Analyte, Peak, Peak Comparison
Analyte, Peak
Analysis
SamplePlusMethodPlusMethod
Peak, Peak Comparison
Analyte
Analyte, Peak
Analyte, Peak, Peak Comparison
Analyte, Peak
Analyte, Peak, Peak Comparison
Analyte, Peak, Peak Comparison
FilterSize
FinalAmount
FlowRate
Frequency
Gradient
HandlingDuration
HandlingFactor
InitialAmount
InjectionVolume
Mass
MassChargeRatio
MeanCalibrationFactor
MeanRelativeResponse
MeanRRF
MeanRetentionTime
NumberDilutions
OrganismLength
PercentRatio
PercentMatch
PercentBreakdown
PercentDifference
PercentRecovery
PercentRSD
PercentValley
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
88
-------
Requirements for ERLN Data Submissions
Quench
Relative Response
Relative Response Factor
Relative Retention Time
Relative Percent Difference
Relative Retention Time
Resolution
Resolution Basis
Response
Retention Time
Sample Amount
Screen Result
Signal To Noise Ratio
Standard Concentration
Standard Final Amount
Standard Deviation
Tailing Factor
Wavelength
Weighting Factor Type
Yield
AnalysisDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
InstrumentResponseDetails
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SampleDetails,
SampleHandlingDetails,
SamplePreparationDetails,
AnalysisDetails
SampleDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
SubstanceldentificationDetails
SubstanceldentificationDetails
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails,
SubstanceldentificationDetails,
InstrumentResponseDetails,
InstrumentResponseAdditionalDetails
SubstanceldentificationDetails,
InstrumentResponseDetails
AnalysisDetails
Analysis
Analyte
Analyte, Peak, Peak Comparison
Analyte, Peak, Peak Comparison
Analyte, Peak, Peak Comparison
Peak
Analysis, Analyte, Peak, Peak
Replicate
Analysis, Analyte, Peak, Peak
Replicate
Analyte, Peak, Peak Replicate
Analyte, Peak
SamplePlusMethod, Handling,
PreparationPlusCleanup, Analysis
SamplePlusMethod
Analyte, Peak
Analyte
Analyte
Analyte, Peak, Peak Comparison
Analyte, Peak
Analysis, Analyte, Peak, Peak
Comparison
Analyte, Peak
Analysis
Quench
RelativeResponse
RRF
RelativeRetentionTime
RPD
RelativeRetentionTime
Resolution
ResolutionType
Response
RetentionTime
SampleAmount
ScreenValue
SignalToNoiseRatio
StandardConcentration
StandardFinalAmount
StandardDeviation
TailingFactor
Wavelength
WeightingFactor
Yield
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
89
-------
Requirements for ERLN Data Submissions
Appendix E: ERLN Domain Model Overview
E.1 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.4-012610 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.I shows an object named "Glasses" with its data elements.
Glasses
Glassesldentifier
GlassesBrand
GlassesStyle
GlassesColor
Lens
LensType
LensSide
Lens
Figure E-1. Domain Model Object
£.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 data type (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).
£.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.
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
91
-------
Requirements for ERLN Data Submissions
Glasses
Glassesldentifier
GlassesBrand
GlassesStyle
GlassesColor
L
Lens
LensType
LensSide
Lens
Figure E-2. Domain Model Data Group (within Parent Object)
Glasses
Glassesldentifier
GlassesBrand
GlassesStyle
GlassesColor
Lens
LensType
LensSide
Lens
Figure E-3. Domain Model Data Group (outside of Parent Object)
£.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.4-012610
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.
£.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
EX000002.1
EX000003.1
EX000004.1
EX000005.1
EX000009.1
EX000011.1
EX000013.1
EX000014.1
EX000016.2
EX000018.2
EX000019.2
EX000020.2
Data Standard Name
Environmental Sampling, Analysis and Results
Environmental Sampling, Analysis and Results
Environmental Sampling, Analysis and Results:
Environmental Sampling, Analysis and Results:
Project
Monitoring Location
Field Activity
Analysis and Results
Equipment
Method
Representation of Date and Time
Sample Handling
Chemical Identification
Biological Taxonomy
Contact Information
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.4-012610 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).
Electronic DataDeliverableDetails
EDDIdentifier
EDDFormatName
ProjectDetails
ProjectStartDate
Project End Date
E.4.1.3
Figure E-4. One-to-one Object Relationship in Domain Model
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.4-012610
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-2K/ProjectStartDate>
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.4-012610 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).
AnalysisDetails
Ana ly si sG rou pTy peTe xt
AnalysisStartDate
M
I nstrumentResponseDetails
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-2lTlO:00:Of>-05:00
l23-ABC
l^;ak
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.
VERSION 1.4-012610 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
Ana ly si sG rou pTy peTe xt
Ana ly si sSta rt Date
MethodDetails
MethodVersionText
MethodDeviationText
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.4-012610 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
£.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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 98
-------
Requirements for ERLN Data Submissions
£.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
Data Package Identifier
DataPackageldentifierContext
DataPackageName
DataPackageVersionText
Data Package Reported Date
DataPackage Number
GeneratingSystemTypeName
GeneratingSystemVersionText
LaboratoryNarrativeText
Laboratory Reported Date
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
£.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.4-012610 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.
£.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.
Substanceldent if i cation Details
SubstanceTypeName
1
1
ChemicalldentificationDetails
EPAChemicallnternalTrackingNumber
CASRegistryN jmber
EPAChemicalldentifier
ChemicalSubstanceSystematicName
EPAChemicalRegist-yName
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.4-012610
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.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
101
-------
Requirements for ERLN Data Submissions
£.4.2.7 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.
£.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)
1
M
FacilitySitcklentificat ion Details
FacilitySiteldentifier
FacilitySiteldentifierContext
Figure E-16. One-to-Many Parent-Child Relationship in Domain Model
£. 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
USEPASiteID
1234567
CERCLISSiteID
Figure E-17. One-to-Many Parent-Child Relationship in XML
£.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.4-012610 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
1
M
•Hill
EquipmentldentificationDetails
Equipmentldentifier
Equipment IdentifierContext
SampleHandlingDetails
SampleHandlingName
SampleHandlingTypeText
SampleHandlingStartDate
SampleHandlingEndDate
SamplePreservationDetails
ChemicalPreservativeUsed
Thermal PreservativeUsed
SamplePreparationDetails
SamplePreparationName
SamplePreparationTypeText
SamplePreparationStartDate
SamplePreparationEndDate
SamplePreparationSequence Number
Figure E-18. Relationship Groups in Domain Model
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
103
-------
Requirements for ERLN Data Submissions
tquipmeniueians
EquipmentName
EquipmentTypeText
1 M
EquipmentldentificationDetails
Equipmentldentifier
EquipmentldentifierContext
SampleHandlingDetails
SampleHandlingName
SampleHandlingTypeText
SampleHandlingStartDate
SampleHandlingEndDate
I M
SamplePreservationDetails
ChemicalPreservativeUsed
ThermalPreservativeUsed
SamplePreparationDetails
SamplePreparationName
SamplePreparationTypeText
SamplePreparationStartDate
SamplePreparationEndDate
SamplePreparationSequenceNumber
Figure E-19. Equivalent to Relationship Group Notation Depicted in Figure E-18
£.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.4-012610
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
CERCLISSiteName
Demo WebEDR Site Name
CERCLIS Site Short Name
ABC123456789
USEPASiteID
123 4567
CERCLISSiteID
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
CERCLISSiteName
Demo WebEDR Site Name
CERCLIS Site Short Name
ABC123456789
USEPASiteID
1234567
CERCLISSiteID
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.4-012610 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
Location Identifier?,
Preservative?,
SampleChainofCustody Identifier?,
SampleCollectionEndDate?,
SampleCollectionStartDate?,
Sampleldentifier,
SampleMatrix,
SampleType?,
StorageBatchldentifier?,
AnalysisDetails+,
Character! sticDetails*
)>
-------
Requirements for ERLN Data Submissions
)>
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 108
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 114
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 115
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 For Official Use Only - Do Not Cite, Circulate or Copy 116
-------
Requirements for ERLN Data Submissions
VERSION 1.4-012610 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.
IgSBSl
LJ UJ £ LJJ U C
lil.il.!
_c
• | S Q
ill
SI si
ilfi
Ji
3&S333
iil
iff!!
j£
6SL_.
IIIJ]
SSSl
llflt II
: s5 i saas
t
11111
islll
11 ]
Figure H-1. ERLN Proposed Domain Model
VERSION 1.4-012610
For Official Use Only - Do Not Cite, Circulate or Copy
118
------- |