Environmental Response Laboratory Network (ERLN) Data Management Strategies

1. Environmental Response Laboratory Network (ERLN)Data Management Strategies EPA Quality Management Conference Presented By: Sean Kolb Schatzi Fitz-James and Terry Smith, OEM Sean Kolb and Lisa Modigliani, CSC

2. ERLN Data Management Strategies • Overview • Developing Minimum Requirements • Background • Establishing Business Rules • Minimum Data Elements • Developing the ERLN Data Exchange Template • Laboratory Domain Model • Standards • Data Exchange Template Structure

3. Developing Minimum Requirements - Background • In September 2007, the ERLN adopted an interim emergency response electronic data deliverable (EDD). • Spreadsheet format for reporting laboratory results and limited laboratory quality control information • Developed to bridge the perceived gap between data users needs and laboratories ability to generate EDD • In February 2008 EPA established an Incident Response Data Management Workgroup to develop the necessary data standards and elements to support the needs of ERLN data users. • While ERLN’s focused on the laboratory, elements associated with both field and laboratory activities were evaluated and considered • In October 2008, the workgroup agreed upon a set of minimum electronic data elements that would be required to support decisions made during the emergency response phase of the incident.

4. Developing Minimum Requirements - Background • Data elements associated with the following activities were addressed • Site Assessment - Monitoring and Field Screening, • Site Assessment - Definitive Field Analytics, • Site Assessment - Off-Site or Field Lab, and • Processing and evaluating laboratory results. • Consensus minimum electronic data elements were selected from elements included in: • EPA OEM’s IT Forum’s Data Standards for Scribe, • “Interim Emergency Response Electronic Data Deliverable, September 26, 2007” and • a list of 272 commonly used data elements used to support electronic data submissions in the Superfund Program (SEDD).

5. Developing Minimum Requirements- General Business Rules • The following business rules were established to ensure that the data elements were developed in a appropriate context. • The minimum electronic data elements apply only to those incidents where the Incident Commander (IC) determines that electronic data are necessary. • Electronic data are defined as computer readable data presented in a format that facilitates exchanging and importing data into project-level or enterprise-level relational databases. • Word processed documents, e-mails and PDFs are not considered electronic data in this context. • All data submissions are project specific and are associated with an IC-assigned project number. • Submission of data is based on shared responsibilities between field personnel and laboratory for collecting and submitting data. • Field personnel will be responsible for collecting and reporting: • Project Level and Monitoring Location Data Elements • Monitoring Measurement Data Elements • Sample Collection Data Elements • Laboratories will be responsible for collecting and reporting: • Laboratory Results Data Elements

6. Developing Minimum Requirements- General Business Rules • If a targeted activity is performed, ALL data elements associated with that activity are required. This means that ALL data elements MUST be populated for every record. Blank or empty data fields are not acceptable. • Only exceptions are CAS Registry Number (non-chemical analysis), Laboratory Qualifiers and Results Uncertainty (non-radiochemical analysis). • Data element formats, lengths and names are independent of the current tools used for data collection and will be modified to use EPA’s Environmental Sampling, Analysis and Results Data Standards [EX000001.1 – 5.1] where applicable. • Format of all data elements is string/text except for date fields. • All date fields are date/time fields with EPA’s ISO-based Representation of Date and Time Data Standard, Standard No.: EX00001.1 (e.g., YYYY-MM-DD hh:mm:ss) as the recommended format. However, if other formats used, time MUST be based on a 24 hour clock. • Longitude and latitude elements may require an additional exception to string/text in order to support their special formatting

7. Developing Minimum Requirements- General Business Rules • Several data elements will require the data recipient to maintain additional metadata in order to place data into an appropriate context. • Examples of metadata are included in ESAR Project Standard No.: EX000002.1, EPA’s Method Data Standard No.: EX000011.1 and EPA’s Contact Information Data Standard No.: EX000019.2. • Data submissions are scalable. • Elements can be submitted as a specific activity is completed or after all activities are completed as determined by the IC. • Data provided for specific activities will require duplicated data elements in order to properly associate data with other functions (e.g., Project Identifier and Field Sample Number in Laboratory Results Data Elements)

8. Developing Minimum Requirements- General Business Rules • Data generated by a deployed laboratory asset associated with the analysis of a sample will be submitted using the Laboratory Results Data Elements • Includes PHILIS, TAGA and Regional Mobile laboratories Laboratory Results Data are limited to the final results as determined by the laboratory for the analysis of field samples for only the contaminants of concern. • Results for laboratory generated samples (e.g., blanks, LCS, etc) and non-target analytes (e.g., surrogates, internal standards, etc.) will not be reported. • Laboratory Results Data Elements, when used with field sampling records, are sufficient to enable users to perform Level One Analytical Data Verification Checks (see OSWER No. 9200.1-85) • A supplemental laboratory narrative may be requested in order to identify issues that could affect data quality identified during sample analysis.

9. Developing Minimum Requirements- Minimum Electronic Data Elements • Sample Collection • Project Identifier 1 • Organization Identifier 2 • Location Identifier1 • Field Sample Identifier • Matrix • Sample Collection End Date • Requested Analysis • Sample Chain of Custody Identifier • Laboratory Results • Project Identifier 1 • Organization Identifier 2 • Data Package Identifier • Field Sample Identifier 1 • Matrix • Method Identifier 2 • Analysis End Date • CAS Registry Number • Substance Name • Result • Result Units • Result Uncertainty • Reporting Limits • Reporting Limit Units • Reporting Limit Type • Laboratory Result Qualifiers Project Level/ Monitoring Location • Project Identifier 1,2 • Project Name • Location Identifier 1,2 • Latitude • Longitude • Horizontal Collection Method Name • Datum • Monitoring Measurement • Project Identifier 1 • Organization Identifier2 • Location Identifier 1 • Analysis End Date • Substance Name • Monitoring Result • Monitoring Result Units • Equipment Name • Equipment Identifier • Notes • Element links data associated with different activities together. • Element requires additional metadata.

10. Developing the ERLN Data Exchange Template General Business Rules • Additional data elements apply only to those incidents where the Incident Commander (IC) determines that his/her data needs require that Level 2 or greater Analytical Data Verification Checks be performed. (see OSWER No. 9200.1-85). • All data elements included in the emergency response minimum requirements are required for all other levels. • Additional data elements will be added to aid in the electronic assessment of measurement quality indicators associated with: • Precision - Accuracy • Sensitivity - Selectivity • Representativeness • Because flat file and spreadsheet formats will not be appropriate for the exchange of data for these levels, hierarchical or relational format will be used. • “Softcopy” data submissions in PDF are required and mirror the electronic requirements • Hardcopy paper data submissions are optional

11. Laboratory 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 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. • A domain model consists of the following basic components: • Objects - Also referred to as classes, are logical containers for information and usually represent logical entities in the problem domain. • Data Elements - Data elements are the properties of an object that collectively define it • Data Groups - A collection of data elements within an object. • Relationships – How data groups relate to one another. • Cardinality - Numeric constraints to the relationship between two objects (i.e., one-to-one, one-to-many, or many-to-many )

12. Domain ModelStandards

14. ERLN Data Exchange TemplateStructure • ERLN data submissions are separated into three types. • Type One • Type Two • Type Three • The Type One format for computer-readable data is either a spreadsheet or CSV that contains column headers for the 18 required ERLN data elements. • Includes only laboratory reported results • The Type One includes a supplemental transitional format available to data users who wish to spot check some of the measurement quality indicators associated with sample analysis.

15. ERLN Data Exchange TemplateStructure • Type Two data submissions are the predominant ERLN data submission type and are used for most of the ERLN responses. • Includes all of the Type One elements as well as additional elements that enable the data user to perform a more extensive data assessment. • Accommodates reporting additional data associated with sample characteristics (e.g., pH, temperature, % moisture, etc.); sample handling; sample preparation; laboratory batching; and sample analysis. • These data, along with data associated with the substance measured, sample type, and the expected result for spiked compounds, enables the laboratory to report data for a project’s measurement quality indicators that can be independently verified by the data user. • Type Two computer-readable format for submitting data is XML. This format is used in order to maintain the data relationships between the project, samples and their analysis by grouping these data together. This data grouping helps to limit redundant data in a laboratory’s data submission.

16. ERLN Data Exchange TemplateStructure • The Type Three format is considered the most extensive ERLN data submission format. • It includes all of the Type Two elements plus additional elements that enable the data user to perform a more extensive data assessment by recreating the analysis as it was performed in the laboratory. • 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 in a Type Three submission. • The Type Three computer-readable format for submitting data is XML. • Format includes additional data groups that associate various types of instrument responses with their associated analyses. • Data are used to recalculate a laboratory’s reported result for each analysis in order to verify its correctness.

17. ERLN Data Exchange TemplateStructure

18. ERLN Data Exchange TemplateStructure

19. ERLN Data Exchange TemplateStructure • ProjectDetails • PointOfContactDetails • SampleDetails • MethodDetails • MeasureDetails • DataQualityIndicatorDetails • CharacteristicDetails • SampleHandlingDetails • MethodDetails • CharacteristicDetails • MeasureDetails • DataQualityIndicatorDetails • AnalysisDetails • MethodDetails • CharacteristicDetails • MeasureDetails • DataQualityIndicatorDetails • SamplePreparationDetails • MethodDetails • CharacteristicDetails • MeasureDetails • DataQualityIndicatorDetails • SubstanceIdentificationDetails • MethodDetails • MeasureDetails • DataQualityIndicatorDetails • InstrumentResponseDetails • MeasureDetails • DataQualityIndicatorDetails • InstrumentResponseAdditionalDetails • MeasureDetails • DataQualityIndicatorDetails

20. Contacts Sean Kolb Computer Sciences Corporation skolb4@csc.com 703-818-4232 Terry Smith US EPA Office of Emergency Management smith.terry@epamail.epa.gov 202-564-2908