United States
Environmental Protection
Agency
Office of Air Quality
Planning and Standards
MD-14
EPA-454/R-97-004g
July 1997
vvEPA
BMP Volume VII
Data Management Procedures
U S. Environmental Protection Agency
Region 5, Library (PL-12J)
77 West Jackson Boulevard, 12th Floor
Chicago, IL 60604-3590
-------
PREFACE
ex)
3 As a result of the more prominent role given to emission inventories in the 1990 Clean
Q Air Act Amendments (CAAA), inventories are receiving heightened priority and
resources from the U.S. Environmental Protection Agency (EPA), state/local agencies,
and industry. More than accountings of emission sources, inventory data are now
providing the prime basis for operating permit fee systems, State Implementation Plan
(SIP) development (including attainment strategy demonstrations), regional air quality
dispersion modeling assessments, and control strategy development. This new emphasis
on the use of emissions data will require significantly increased effort by state/local
agencies to provide adequate, accurate, and transferrable information to meet various
agency and regional program needs.
Existing emission inventory data collection, calculation, management, and reporting
procedures are not sufficient or of high enough quality to meet all of these needs into
the next century. To address these concerns, the Emission Inventory Improvement
Program (EIIP) was created. The EIIP is a jointly sponsored endeavor of the State and
Territorial Air Pollution Program Administrators/Association of Local Air Pollution
Control Officials (STAPPA/ALAPCO) and the U.S. EPA, and is an outgrowth of
recommendations put forth by the Standing Air Emissions Work Group (SAEWG) of
STAPPA/ALAPCO. The EIIP Steering Committee and technical committees are
composed of state/local agency, EPA, industry, consultant, and academic representatives.
In general, technical committee participation is open to anyone.
The EIIP is defined as a program to develop and use standard procedures to collect,
calculate, store, and report emissions data. Its ultimate goal is to provide cost-effective,
reliable, and consistent inventories through the achievement of the following objectives:
• Produce a coordinated system of data measurement/calculation methods as
a guide for estimating current and future source emissions;
• Produce consistent quality assurance/quality control (QA/QC) procedures
applicable to all phases of all inventory programs;
• Improve the EPA/state/local agency/industry system of data collection,
reporting, and transfer; and
• Produce an integrated source data reporting procedure that consolidates
the many current reporting requirements;
-------
EIIP goals and objectives are being addressed through the production of seven guidance
and methodology volumes. These seven are:
• Volume I: Introduction and Use of EIIP Guidance for Emissions
Inventory Development
Volume II: Point Sources Preferred and Alternative Methods
Volume III: Area Sources Preferred and Alternative Methods
Volume IV: Mobile Sources Preferred and Alternative Methods
Volume V: Biogenics Sources Preferred and Alternative Methods
Volume VI: Quality Assurance Procedures
Volume VII: Data Management Procedures
The purpose of each volume is to evaluate the existing guidance on emissions estimation
techniques, and, where applicable, to identify the preferred and alternative emission
estimation procedures. Another important objective in each volume is to identify gaps in
existing methods, and to recommend activities necessary to fill the gaps. The preferred
and alternative method findings are summarized in clear, consistent procedures so that
both experienced and entry-level inventory personnel can execute them with a reasonable
amount of time and effort. Sufficiently detailed references are provided to enable the
reader to identify any supplementary information. Users should note that the number of
source categories or topics covered in any volume is constantly expanding as a function
of EIIP implementation and availability of new information.
It is anticipated that the EIIP materials will become the guidance standard for the
emission inventory community. For this reason, the production of EIIP volumes will be
a dynamic, iterative process where documents are updated over time as better data and
scientific understanding support improved estimation, QA, and data management
methods. The number of individual source categories addressed by the guidance will
grow as well over time. The EIIP welcomes input and suggestion from all groups and
individuals on how the volumes could be improved.
-------
PROTOTYPE VERSION EIIP EDI
IMPLEMENTATION GUIDELINE (FOR
AIR EMISSION MODELING DATA)
Prototype Version
Draft
April 1997
Prepared by:
Technology Planning & Management
Corporation
DynCorp Information & Engineering
Technology
Prepared for:
Data Management Committee
Emission Inventory Improvement Program
-------
Prototype Emission Modeling Implementation Guideline
TABLE OF CONTENTS
SECTION 1 — INTRODUCTION 1-1
1.1 Purpose of Guideline 1-1
1.2 Scope and Applicability 1-1
1.2.1 Project Overview 1-2
1.2.2 EDI Objectives and Approach for EIIP 1-2
1.3 Responsible Entity 1-5
1.4 Introduction to EDI 1-6
1.4.1 EDI and ANSI/ASC X12 Standards 1-7
1.5 How to Use the Implementation Guideline 1-8
1.6 References 1-8
SECTION 2 — BUSINESS ISSUES 2-1
2.1 Implementation Considerations 2-1
2.1.1 Establishing an EDI Committee 2-2
2.1.2 Implementation Suggestions 2-2
2.1.3 EDI Cost Justification 2-4
2.1.4 Strategy for Implementation 2-5
2.1.5 Transaction Sets 2-5
2.1.6 Pilot Program 2-6
2.1.7 Education 2-6
2.2 Timing of Transactions 2-7
2.3 Modes of Operation 2-7
2.4 Security 2-8
2.5 Backup and Recovery Procedures 2-10
2.5.1 Disaster Recovery Considerations 2-11
2.6 Audit Considerations 2-11
SECTION 3 — LEGAL CONSIDERATIONS 3-1
3.1 General Introduction 3-1
3.2 Record Keeping 3-2
3.3 Authentication 3-3
3.4 Trading Partner Agreement 3-4
3.5 Third-Party Agreements 3-5
3.6 Laws, Rules, and Regulations 3-6
SECTION 4 — ENVIRONMENTS 4-1
4.1 System Architecture 4-1
4.2 Application Integration 4-3
4.3 Translation 4-4
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 5 — MAINTENANCE 5-1
5.1 Maintaining Guidelines 5-1
5.2 Maintaining ASC X12 Standards 5-1
5.3 Version/Release 5-1
SECTION 6 — COMMUNICATIONS 6-1
6.1 General Introduction 6-1
6.2 Protocols 6-2
6.2.1 EDI Data Transfer Protocol 6-2
6.2.2 Transmission Protocols 6-4
6.3 Point-to-Point (Dedicated Network) 6-4
6.4 Third Party Services 6-5
6.5 Network Interconnects 6-7
6.6 The Internet 6-7
SECTION 7 — MISCELLANEOUS 7-1
7.1 Industry Business Models 7-1
7.1.1 Introduction 7-1
7.1.2 Transaction Sets 7-1
7.2 Related Industry Topics 7-1
7.3 EDI Vendor References 7-1
SECTION 8 — GLOSSARY OF TERMS 8-1
SECTION 9 — FORMS AND DOCUMENTS 9-1
9.1 ASC X12 Transaction Sets 9-1
9.1.1 Header/Trailer Format 9-1
9.1.2 841 Specifications/Technical Information 9-1
9.2 ASC X12 Documents 9-1
9.3 EIIP XI2 841 Convention Document Organization and Convention-for-Use . 9-2
9.4 Cross Reference Matrix of Phase I Core Data Model vs. Modeling Data Set vs.
EIIP X12 841 Convention Document 9-6
9.5 EIIP Code Tables Contained in the EIIP X12 841 Convention Document ... 944
SECTION 10 — AGENCY CONVENTIONS, INTERCHANGE CONTROL &
TRANSACTION SETS 10-1
10.1 Introduction 10-1
10.2 X12 EDI Transmission Control Structure 10-4
10.2.1 Control Segments 10-7
APPENDIX A — GETTING STARTED WITH EDI A-l
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
APPENDIX B — EPA'S GENERIC TERMS AND CONDITIONS AGREEMENT B-1
APPENDIX C — CROSS REFERENCE MATRIX OF PHASE I CORE DATA MODEL vs.
EIIP X12 841 CONVENTION DOCUMENT C-l
APPENDIX D — EIIP X12 841 CONVENTION DOCUMENT D-l
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March?, 1997
Revision Date: April 11, 1997 vii
-------
Prototype Emission Modeling Implementation Guideline
SECTION 1 — INTRODUCTION
1.1 Purpose of Guideline
This implementation guideline is provided by the U.S. Environmental Protection Agency (herein
referred to as USEPA) Emission Inventory Improvement Program (EIIP). This guideline
specifically supports the Phase I goals of the EIIP Electronic Data Interchange (EDI) project.
This phase of the EIIP EDI project is a prototype. It is not a pilot or a production EDI system. A
prototype system differs from a pilot and production system in a number of ways. The pilot is
geared toward immediate evolution into a production environment. A production system fully
supports the routine exchange of business information between trading partners. The prototype
is a proof-of-concept step that is initiated to demonstrate the basic performance of the EDI and
supporting systems. The prototype does not take into account many of the issues that must be
addressed for a pilot and/or production system. This guideline is includes information that
directly applicable to a pilot environment. Although the document is intended to support the
initial, prototype effort, an understanding of the more developed, pilot-oriented information is
important for future activities.
This Implementation Guideline provides trading partners with an outline for the implementation
of EDI for the submission of air emission modeling information to the USEPA Emission Factor
and Inventory Group. It also provides the information necessary to understand the general EDI
goals of the EIIP and USEPA, provide an overview of the EIIP EDI project, and communicate
the general information needed for the prototype.
1.2 Scope and Applicability
As this phase of the EIIP EDI project is a prototype and does not address all the
components/issues of a pilot or production system, actual implementation is somewhat
simplified. However, for the prototype to be effective, it must highlight those areas that will be
required for future expansion of the project.
The scope and applicability of the Implementation Guideline encompass all aspects of
implementing an EDI system that supports the reporting of air emission modeling information as
defined by the EIIP initiative. Specific reference is made where the prototype implementation
diverges from typical pilot/production system requirements.
In order to provide a comprehensive reference document, including EDI implementation
requirements of the USEPA, the EIIP guideline is written to include information specified in the
USEPA EDI Implementation Guideline. Although this implementation guideline contains
guidance regarding the USEPA's implementation of EDI, more information about the USEPA
Issue Date: March?, 1997
Revision Date: April 11, 1997 1-1
-------
Prototype Emission Modeling Implementation Guideline
EDI perspective or other EDI projects within the USEPA may be found in the USEPA EDI
Implementation Guideline dated September 23, 1994.
1.2.1 Project Overview
The Clean Air Act Amendments (CAAA) require that many State and Local agencies collect
emission inventory data as a basis for planning and demonstrating attainment with National
Ambient Air Quality Standards (NAAQS). Emission inventories are a basic component to air
quality modeling and other air pollution management analyses which are used to demonstrate
that proposed air pollution control strategies are sufficient to attain the State and Federal air
quality standards. The availability of emissions data is of primary importance to support urban
and regional air quality attainment demonstration, emission control strategy development,
emissions trading, regulatory and economic impact analyses, geographic and satellite information
systems, and scientific research. These data are essential to the infrastructure in managing
environmental air pollution at the Local, State, Regional and Federal levels.
The Emission Inventory Improvement Program was formed as a joint effort of State and Local
air agencies and USEPA for the purpose of improving the quality of the emissions data collected,
and the way the data is transferred and shared among users. The EIIP Data Management
Committee (DMC) is responsible for developing and implementing a common data transfer
format, and for facilitating data sharing within the emission inventory/modeling community.
The USEPA published its Policy on Electronic Reporting (FRL-3815-4, vol. 55, no. 146, July
30, 1990), endorsing an approach commonly known as EDI for electronic reporting of
environmental data. This policy was consistent with the anticipated government-wide mandate
for EDI, published as FIPS PUB 161 (September, 1991). USEPA's Policy on Electronic
Reporting was intended to promote electronic reporting, and a uniform USEPA approach that is
compatible with current industry and Federal sector practices. The policy recommends a
standards-based approach, and encourages the use of American National Standards Institute
(ANSI) Accredited Standards Committee (ASC) XI2 standards for EDI. The DMC has adopted
this approach to develop the EIIP common data transfer format for the emission
inventory/modeling community.
1.2.2 EDI Objectives and Approach for EIIP
An objective of the EIIP is to implement EDI for the submission of air emission inventory and
modeling information. This initiative is intended to allow data to be directly transmitted and
shared between the different computer systems of trading partners. The EIIP EDI initiative is
designed to allow the reporting of air emission inventory and modeling data from the following
emission source areas:
Point Source
Issue Date: March 7, 1997
1 -2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
• Area Source
• Nonroad Engines and Vehicles Source
• Mobile Source
• Biogenic Source
For this phase of the project, the implementation guideline incorporates a level of detail that is
appropriate for use with all five areas. Within each of the areas, several specific reporting
functions (e.g., State Inventory Plan (SIP) inventories, Annual Point Source inventories, etc.)
may be identified. As each function may have different ans some overlapping information, each
one must have a separate, report-specific guideline. Each individual guideline will explain the
use of EDI with respect to specific practices and assist in clarifying the use of the transaction set
between trading partners. For Phase I of the EIIP EDI prototype project, air emission modeling
data (as defined by the Environmental Council of States (ECOS)) is the intended reporting
function. This implementation guideline is written to provide the details for reporting this
information via EDI.
When realized, the EIIP EDI objectives will provide economies in exchanging information with
internal and external partners. The EIIP has developed an approach to EDI that will benefit all
participants (trading partners), including the regulated community, Federal and State
environmental program offices, and other related organizations. This approach includes:
• Implement EDI using the American National Standards Institute (ANSI)
Accredited Standards Committee (ASC) XI2 standards;
Apply the ANSI/ASC X12 841 Specifications/Technical Information
transaction set and developing the corresponding EllP-specific convention
document;
• Develop national standards for the implementation of emission inventory and
modeling reporting;
• Avoid the development and proliferation of proprietary software, standards,
procedures, and conventions;
• Reduce the volume and necessity of paper reporting;
• Increase the speed of reporting and analysis of the data;
Issue Date: March 7, 1997 ~ ~~
Revision Date: April 11, 1997 1_3
-------
Prototype Emission Modeling Implementation Guideline
• Enhance the level and effectiveness of quality control associated with reported
data;
• Facilitate data sharing among partners; and
• Seek voluntary collaboration with the regulated community, Federal and State
agencies, educational institutions, and support contractors.
Electronic Reporting
The U.S. Government Policy on EDI, as published in the Federal Information Processing
Standards (FIPS PUB 161) became effective on September 30, 1991. Its objectives are to:
• Have Federal Agencies achieve the benefits of EDI (e.g., reduced paperwork,
fewer transcription errors, faster response time for procurement and customer
needs, reduced inventory requirements, more timely payment of vendors);
• Ease the electronic exchange of data by the use of standards for data formats
and transmission envelopes; and
• Minimize the cost of EDI implementation by preventing duplication of effort.
Prior to implementing an EDI project, FIPS PUB 161 should be reviewed in detail. Listed below
are some of the highlights.
The transmission of reports using EDI is consistent with the USEPA's electronic reporting (ER)
policy. Notice of USEPA policy was published in the Federal Register, Notice No. FRL-3815-4,
Volume 55, Number 146, July 30, 1990 and was entitled "USEPA's Policy on Electronic
Reporting." This policy establishes a uniform USEPA approach to electronic reporting. In
addition, this policy is intended to promote the adoption of electronic reporting by USEPA
Program Offices and to ensure that as they implement this technology, they do so in a manner
that is both consistent across the USEPA and compatible with the current electronic reporting
practices in industry.
The USEPA also recently published guidance related specifically to the use of EDI. The notice
of the USEPA's policy on employment of EDI was published in the September 4, 1996 Federal
Register, Volume 61, Number 172, FRL-5601-4. The notice is entitled "Notice of Agency's
General Policy for Accepting Filing of Environmental Reports via Electronic Data Interchange
(EDI)". The notice provides an overview of the USEPA perspective for the use of EDI, the
history of EDI within the USEPA, and how to use EDI for reporting to the USEPA.
1.3 Responsible Entity
Issue Date: March?, 1997
1 -4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EDI is a partnership that involves several individuals or functional groups within each
organization. EDI is a new way for the government to conduct environmental reporting. For
EDI to be successful, all who are involved must work together in an open and informed
environment. With every EDI system that is implemented, including the EIIP EDI project, each
organization must secure and maintain staff that fulfill the following positions/responsibilities:
The Trading Partner (e.g., a governmental agency, an emission source, a municipality, a
corporate entity, etc.) is responsible for its EDI software and successfully communicating data to
its collaborating trading partner. Communicating data includes acquiring the data, presenting it
to a translator for conversion to the XI2 Standard and transmitting it via a prescribed route. Each
trading partner is also responsible for acquiring required software and hardware and for problem
resolution with its associated trading partners.
As each trading partner is responsible for its own part of the overall EDI system, business and
technical decisions must be based on the resources and needs of that organization. Each trading
partner will develop their EDI system to fit their organization. Once developed, communication
and cooperation will be necessary to form the essential relationships between trading partners.
In an EDI system environment, trading partners function in pairs. Although an individual
organization may interact with numerous trading partners, it shares a unique, one-to-one
relationship with each. Because each relationship has unique characteristics, each pair of trading
partners must communicate EDI-related decisions in order to be successful.
In the case of the EIIP EDI project, the EIIP is responsible for providing the necessary
Implementation Guidelines and testing assistance during the initial implementation to ensure
successful delivery of the data.
The participants in the EIIP EDI prototype project consist of the following entities:
USEP A Office of Air Quality Planning and Standards (OAQPS) Emission
Factor and Inventory Group (EFIG) Emission Monitoring and Analysis
Division (EMAD); and
• State/local environmental agencies responsible for air emission modeling data.
The specific state trading partners involved in the EIIP prototype
implementation are California Air Resources Board (CARB) and
Pennsylvania Department of Environmental Protection (PADEP).
.An EDI project requires the services of individuals educated in both EDI and the applications
that handle the data. For the purposes of identifying the various functions involved, this
publication has assigned the following titles and identified functions with those titles: Program
Officer, EDI Coordinator, EDI Application Programmer and Telecommunication Coordinator. A
Issue Date: March 7, 1997 " ~~~
Revision Date: April 11, 1997 • i_5
-------
Prototype Emission Modeling Implementation Guideline
successful EDI implementation is dependent upon having the responsibility of the functions
assigned, not the titles.
The Program Officer is responsible for the USEPA program interface. The Program Officer is
responsible for ensuring that each project participant is in compliance with USEPA and EIIP
regulations and EDI agreements, thus ensuring the integrity of the EIIP EDI transmissions.
The EDI Coordinator is responsible for the application program that uses the EDI data and for
all problems at the application level including EDI documentation (e.g., wrong field, wrong data
in field, missing fields, etc.). The Coordinator works closely with the EDI Application
Programmer and may assume some of the Program Officer duties.
The EDI Application Programmer is responsible for developing and maintaining the interface
program that bridges trading partner applications to their EDI system. The Application
Programmer is also responsible for all modifications and enhancements to the EDI system. This
includes the resolution of problems that may arise between the trading partners' translator
software.
The Telecommunications Coordinator is responsible for ensuring that the services provided
under the Value Added Network (VAN), or other means of communication, are compatible with
the prototype EDI requirements.
1.4 Introduction to EDI
EDI is the transmission in ANSI ASC XI2 syntax, of unambiguous information of business or
strategic significance between computers of independent organizations. The definition can be
expanded further to include the electronic transmission of business documents from the
application program of one computer to the application program of another computer within the
framework of a standard format. The key elements in the definition are computer-to-computer
and standard format. EDI reduces costs and errors associated with a paper document
environment. EDI replaces the mail delivery and reentry of documents with the electronic
mailbox and the delivery of business data directly to your computer application program.
1.4.1 EDI and ANSI/ASC XI2 Standards
The American National Standards Institute (ANSI) was founded in 1918 as the national
coordinator of the voluntary standards system for the United States. The system meets national
standards needs by marshaling the competence and cooperation of commerce and industry,
standards developing organizations, and public and consumer interests. ANSI coordinates the
voluntary development of national consensus standards, approves standards as American
National Standards, and serves as a clearinghouse and information center for American National
Standards and international standards.
Issue Date: March 7, 1997
1 -6 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
In 1979 ANSI chartered a new committee, known as Accredited Standards Committee (ASC)
XI2, Electronic Data Interchange, to develop uniform standards for electronic interchange of
business transactions. This charter permits the adoption of national standards for EDI and
enables all organizations to use a single agency (ASC X12) to develop and maintain transaction
set standards.
ASC X12 develops Draft Standards for Trial Use (DSTU's) and publishes the entire set as a
Version/Release annually. The purpose of the Release is to put current approved draft standards
into the hands of users on a more frequent schedule, to speed implementation, reflect user needs
in the standards more quickly and allow the user to gain experience with the draft standards
before solidifying them as American National Standards.
Draft Standards for Trial Use undergo the ANSI-required public review process approximately
every three to five years. ANSI-approved, published standards, including ASC XI2 DSTU's, as
of May 1994 number 198 with an additional 102 draft standards that are under review.
In developing the ASC X12 series of American national standards, the ASC X12 subcommittees
seek to minimize the need for users to reprogram their internal data processing systems to
achieve an interchange. Consequently, the standards are structured so that computer programs
can translate data from internal to external formats and vice-versa. In this way, either through
internally or externally developed translation software and public-communications vendors, all
sizes of firms and institutions using intelligent computational devices may benefit from the use
of the standard.
Through the use of this standard, all institutions can enjoy the efficiencies of a common
interchange language rather than experience the difficulties of a proliferation of methods and
procedures which could occur if each institution were to impose its own formats on every other
institution with which it does business.
1.5 How to Use the Implementation Guideline
These guidelines follow the recommended format specified in the "ASC XI2 Guideline for
Electronic Data Interchange (EDI) Implementation Guidelines", ASC X12D/90-856, approved
February 1991. Chapters 1-10 of this guideline contain information necessary for trading
partners to fulfill the requirements for implementing the exchange of air emission modeling data
using EDI.
These sections include the EDI business background and history, as well as policy and logistic
issues that should be addressed. The appendices contain a checklist on how to get started with
EDI, and provide conventions of the specific X12 transaction sets needed to satisfy the EDI
information requirement for transmittal of data electronically.
Issue Date: March?, 1997
Revision Date: April 11, 1997 . \.j
-------
Prototype Emission Modeling Implementation Guideline
1.6 References
Questions, comments, and suggestions regarding this EIIP EDI Implementation Guideline may
be referred to:
Ms. Lee Tooly
U.S. Environmental Protection Agency
Emission Factor and Inventory Group
EIIP Data Management Committee
Research Triangle Park, NC 27711
Telephone: (919)541-5292
Standards publications, guidelines, and technical reports disseminate the technical and logical
concepts reflected in the XI2 Standards. Data Interchange Standards Association publishes a
catalog of the available standards. The information available from DISA includes Part I, which
is a document entitled "An Introduction to Electronic Data Interchange". Part II is also available,
which is a catalog of the ANSI/ASC XI2 Publications. Any general or technical questions about
EDI, ASC X12 committees, or the ANSI/ASC X12 Standards, can be directed to:
Data Interchange Standards Association, Inc. (DISA)
Technical Department
1800 Diagonal Road, Suite 200
Alexandria, VA 22314-2852
Telephone: (703)548-7005
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 2 — BUSINESS ISSUES
2.1 Implementation Considerations
When implementing EDI, a multitude of business and technology questions must be asked and
answered. As the application of EDI technology becomes more prevalent within the USEPA and
the regulated community, many of the general issues associated with EDI implementation have
already been addressed. Through the efforts of the EIIP DMC and their partners, an informed,
receptive support team has developed. This team understands the issues related to EDI
implementation and is working to ensure the success of ANSI/ASC XI2 EDI as a means to
electronically transfer air emission modeling data.
Although a majority of the business issues have already been considered during the development
of this EDI project, a general overview of the prominent issues is presented in the balance of this
section. As this phase of the EIIP EDI project is a prototype, not all the issues are of immediate
concern. However, the information provided below must be addressed as the project moves
toward a production environment.
At this time, because the initial implementation is a prototype activity, many of the requirements
outlined below have not been finalized. Several issues that must be addressed for a production
environment will be specified based on the result of the prototype efforts. These essential areas
include, but are not limited to:
• Establishment of a formal EDI committee;
• Production implementation;
• Timing of transactions;
• Modes of operation;
• Security;
• Back-up and recovery procedures; and
• Audit considerations.
Issue Date: March 7, 1997
Revision Date: April 11,1997 - 2-1
-------
Prototype Emission Modeling Implementation Guideline
2.1.1 Establishing an EDI Committee
An EDI coordinating committee should be established. It is imperative that the EDI committee
have a well defined and understood mission statement for itself and the designated project teams.
This committee will be the focal point and control element for direction and communication. It
should include representatives from all of the involved functions such as information systems,
materials management, purchasing, sales, legal, audit, etc. The EDI committee will designate
Project Teams to manage segments of the total project.
Another essential role of the committee is to interface with ASC X12. Because ASC X12 is
responsible for the EDI standards that are implemented, a close relationship must be maintained
by the EDI committee. Not only will this relationship help ensure that the EIIP's data
maintenance requests are adopted, but that the EIIP has a presence and plays a role in the overall
development of the national standards.
The EIIP DMC is currently serving this function. The DMC provides subject area expertise for
project reporting requirements, USEPA guidance for implementing the EDI system, management
support to ensure the success of the project, and oversight of maintenance issues related to all
components of the EDI system.
2.1.2 Implementation Suggestions
In developing the EIIP EDI air emission modeling project, the DMC performed rigorous analysis
activities to ensure a successful approach and implementation. Although the planning and
implementation of an EDI system is a complex under taking some general approach
recommendations can be made:
• Talk with experienced EDI users;
• Get involved with industry associations and standards organizations;
• Determine EDI objectives;
• Gain commitment from management, business units and support groups;
• Establish an EDI Implementation Team;
• Consider the extent to which internal systems are suitable for EDI;
• Select prototype/pilot partners with experience in EDI;
• Limit the initial effort to a few partners and transactions;
Issue Date: March 7,1997
2-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Identify appropriate products with which to start;
Begin with partnerships where transaction volumes are high;
Integrate EDI with existing systems;
Review tax, audit, and legal requirements;
Evaluate hardware/software alternatives and make selections, carefully
weighing the use of PC software for data entry and high transaction volumes;
Provide an EDI training program (including training on EDI standards) for
users;
Enlist the assistance of experienced consultants and third parties;
Establish agreements with trading partners;
If applicable, be sure links exist to allow transmissions to flow between third
parties;
Have frequent progress discussions with partners and assign
coordinator/contact;
Define methods to handle exceptions and problems;
Exchange documents in parallel mode for at least several cycles before
initiation of live EDI data;
Discontinue paper documents when EDI is operational;
Publicize EDI benefits internally;
Expand EDI efforts by establishing trading relationships with partners of
varying sizes, EDI experience, and computer sophistication;
Pursue EDI with only those partners where it makes business sense to do so;
Participate in EDI industry and standards activities;
Plan for significant up-front costs;
Issue Date: March?, 1997
Revision Date: April 11, 1997 " 2-3
-------
Prototype Emission Modeling Implementation Guideline
• Resist trading partners who want to use proprietary formats; and
• Get help from marketing, purchasing and other functional groups in the
development of your EDI plans and architecture.
2.1.3 EDI Cost Justification
Short- and long-term benefits should be forecast when justifying the cost involved in
implementing an EDI program. Trading partners face four general cost categories related to the
implementation of an EDI system. These categories include:
• Application development costs;
• Supporting encryption when required;
• Modifying applications to capture the reporting data required (including
hardware and software); and
• Message costs.
The cost of application development impacts all trading partners. Typically, existing
applications with which EDI will be used require some modification. Trading partners that have
no existing application will certainly incur application development costs. When evaluating the
cost of application development or modification, three major cost areas should be addressed:
• Modification of EDI software to access the application systems;
• Support of encryption when required; and
• Modification of applications to capture the reporting data required.
Modifying applications may also entail upgrading system hardware and software platforms. The
cost of these activities vary depending upon the current system architecture versus the required
environment. Translation software costs also vary depending on the hardware and translation
software selected for use. Consult with EDI translation software providers to determine the
costs.
Message costs are a function of the transactions implemented, number of transactions, volume,
frequency of transmission, time of day transmitting, method of transmission (direct, VAN, dial-
up, etc.), VAN costs, and other factors.
2.1.4 Strategy for Implementation
Issue Date: March 7, 1997
2-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Information needs to be collected to develop a successful strategy for implementing an EDI
project. Consider the following when planning your implementation strategy:
• Develop a business applications/trading partners matrix;
• Designate EDI business contacts;
• Obtain contact information for Value-Added Networks (VAN);
• Obtain contact information for software providers;
• Determine what partner identification scheme should be used, (e.g., DUNS
number);
• Define terms of exchange and establish an agreement between trading
partners; and
• Develop an overall system data flow design.
Based on the information collected from business partners, develop an overall EDI plan.
Conduct meetings/conferences with trading partners to define EDI plans and dates.
Consideration should be given to those trading partners capable of doing EDI and having the
desire to participate.
2.1.5 Transaction Sets
Determine the applicable ANSI/ASC XI2 transaction sets that will be used and the minimum
data that will be necessary to satisfy the application data requirements. Determine which
acknowledgments shall be used.
The EIIP implementation uses the ANSI/ASC XI2 841 Specifications/Technical Information
transaction set. This transaction set is mapped in detail in the EIIP EDI XI2 Convention
Document which is located in the Appendix D of this document.
The ANSI/ASC X12 997 Functional Acknowledgment Transaction Set is employed in a
production system. The use of the Functional Acknowledgment is a requirement of the USEPA
for all EDI implementations. As this phase of the project is a prototype, this transaction set will
not be employed.
2.1.6 Pilot Program
Issue Date: March?, 1997
Revision Date: April 11, 1997 - 2-5
-------
Prototype Emission Modeling Implementation Guideline
As stated previously, this phase of the EIIP EDI project is a prototype which differs from a pilot
in a number of ways. The pilot is geared toward immediate evolution into a production
environment. The prototype is a proof-of-concept step that is initiated to demonstrate the basic
performance of the EDI and supporting systems. The prototype does not take into account many
of the issues that must be addressed for a pilot and/or production system. Although this
implementation guideline is produced for the prototype efforts, an understanding of the pilot
program is important for future activities.
A pilot program is a method of initiating EDI that provides the ability to test concepts, practices,
and EDI policies. A pilot program is the initial step of a production implementation schedule.
The schedule should encompass the inclusion of all applicable trading partners into the EDI
system. An integral part of a pilot program is to establish test criteria. These criteria must
include:
• Coding and testing the interface to in-house system(s);
• Conducting system tests with translation software and network (if used);
• Conducting system tests with the trading partners using a test data file and/or
testing with live data;
• Sending sample XI2 data to trading partner; and
• Initiating parallel processing.
2.1.7 Education
Regardless of whether the EDI system is in prototype, pilot, or production stages, educating
internal and external personnel in EDI is vital to the success of any EDI project. User personnel
should be educated as to what EDI is, what implementation entails, why the organization is
implementing the standards, and what impact it may have on the current procedures. Trading
partner education regarding EDI transactions and future plans can be accomplished on an
individual basis or through sponsoring trading partner conferences.
2.2 Timing of Transactions
A number of timing issues to be considered and resolved with trading partners when determining
the timing of transactions include:
• When the business transaction(s) will be made available to the trading partner;
Issue Date: March?, 1997
2-6 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
• Rules for acceptance/rejection of transmissions including time stamp of the
transmission;
• Retention periods for both sender and network message storage transmission;
• Timings of the transaction acknowledgment;
• Methods of handling legal holidays;
• Deadlines for submission of the information and receipt of functional
acknowledgments; and
• Abilities of the existing computer systems to respond within a specific time
frame.
2.3 Modes of Operation
The two modes of operation are Production and Test. Production is used when both partners
agree both systems are communicating the agreed upon data for the transaction sets
implemented. The test mode is used when implementing a new transaction, when making a
modification to implemented transactions, or when upgrading to a new version/release. The
trading partners should be aware of when the test mode will be used in order to provide
assistance to each other. Identification of the mode of operation is contained in the ISA
(Interchange Control Header) Position ISA15, Data Element 114. A "P" identifies production
data and "T" identifies test data. Trading partner systems must have the provision to handle both
production and test transaction sets.
The initial activities for the EIIP EDI project are a proof-of-concept and are considered to be a
test environment. Therefore, the transactions that will be transmitted for the prototype will be
designated as Test. Upon completion of the prototype further activities and decisions will be
made to move to the production environment. Trading partners will be informed of the decisions
and additional requirements for the Production system as appropriate.
Issue Date: March 7, 1997
Revision Date: April 11, 1997 . 2-7
-------
Prototype Emission Modeling Implementation Guideline
2.4 Security
The risks inherent in the EDI process are based on the lack of paper documentation to backup the
transactions. EDI involves the transmission of electronic messages, or records, that may never
be converted to hard copy. Therefore, the electronic records must be able to stand alone as
submission data. These records are subject to the same security requirements as are all types of
USEPA data.
The EDI process must include all steps necessary to ensure that the records are authentic, are
properly authorized, and are retained in a manner that will ensure the integrity of the records.
Audit trails must be maintained for accountability.
The integrity of EDI messages is essential. Security controls must be in place to ensure that the
message is not modified and that electronic records are protected from loss or destruction. In
addition, if EDI messages contain sensitive or Confidential Business Information (CBI),
adequate controls must be in place to protect the data from inappropriate disclosure.
The authentication of the originator is a critical security issue for EDI. The process must be able
to ensure that the source of the message is the named originator.
Computer security plans must be developed for EDI. The resources allocated to protecting EDI
systems must be based on the risk and magnitude of potential harm that could result from the
loss, misuse, or inappropriate access to or modification of EDI data. Specific controls should be
implemented for the following aspects of the EDI system:
Integrity - Controls, such as audit trails, access control mechanisms, and separation of duties
must be in place to protect the integrity of EDI data. Controls within the EDI environment for
protecting data integrity include the following techniques:
• Recalculating and verifying real totals and hash totals for critical parameters;
• Repeating messages or parts of messages rather than using only a functional
acknowledgment; and
• Including unique identifier codes within each message to define each message as
a separate distinct message.
Confidentiality - EDI systems processing confidential data, such as Privacy Act, CBI, or
enforcement data must include access controls to restrict access to authorized personnel only.
Access controls include technical controls, such as passwords or encryption, as well as
procedural controls, such as restricted access to physical areas processing confidential data.
Issue Date: March?, 1997
2-8 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Availability - Contingency plans must be prepared to provide for continuity of operations in case
of system failure or system degradation. Contingency plans should include backups on a
periodic basis commensurate with the importance of the data maintained within the system. The
contingency plan must also be tested periodically to ensure that it accounts for all possible threats
to system and data availability.
Authentication - Authentication controls must be in place to ensure that the source of the
message is the named originator. Non-repudiation should be used when authentication is a
critical issue. Specific techniques for authentication include:
• Returning an acknowledgment for each message sent. A valid message will send
an acknowledgment to the originator within a pre-specified time period;
• Utilizing specific log-on techniques; and
• Including secret (known only to the parties involved) reference numbers or
passwords within the body of the message.
Written agreements - The use of written agreements can stipulate the specific security and
authentication mechanisms to be used. When employed, they are valuable tools for ensuring
communication and understanding between trading partners. If used correctly, written
agreements clearly and formally state the requirements and conditions under which the trading
partners will operate.
In addition, cryptographic techniques should be considered, especially for high-risk systems, to
protect the confidentiality, integrity, and authentication of EDI systems.
Procedural controls can be implemented to protect the integrity, availability and confidentiality
of information and systems. Procedural controls may be less expensive and easier to implement
than technical controls. Procedural controls can include activities such as limiting physical
access to data entry or computer areas, providing security training, creating security procedure
manuals, and requiring separation of duties.
The laws and regulations mandating safeguards mandating safeguards for Federal information
and information systems include:
The Privacy Act of 1974 (P.L. 93-579);
The Freedom of Information Act (5 U.S.C. 552);
The Paperwork Reduction Act of 1980 (P.L. 96-511);
Issue Date: March 7, 1997
Revision Date: April 11, 1997 . 2-9
-------
Prototype Emission Modeling Implementation Guideline
The Computer Security Act of 1987 (P.L. 100-235); and
U.S. Code, Title 18, Section 1905.
The organization that initiates an EDI system should take care to avoid making unreasonable
demands of its trading partners. While the initiating trading partner may have the resources and
expertise to handle an EDI system easily, this may not always be true of the other partner(s).
These limitations of resources and expertise should be taken into account.
For the prototype efforts, at a minimum, the EIIP EDI trading partners will be required to support
the current USEPA standards for security. The trading partner will be responsible for keeping
their VAN log-on and local dial-up access numbers secure. If the trading partner suspects a
security breach, it must contact the Program Coordinator immediately. USEPA, as an initiating
trading partner, reserves the right to change trading partner access identification numbers (ID)
and passwords at any time.
2.5 Backup and Recovery Procedures
Backup and recovery procedures are necessary to provide:
• Retransmission capabilities;
• Translator re-run capabilities;
• Minimum 24- to 48-hour immediate access backup; and
• Archive and recovery capabilities for individual EDI transactions.
The backup and recovery procedures must be thoroughly documented to allow anyone with the
proper authority to access the system to retransmit data.
It will be up to each EDI partner to keep their own records and archives of EDI transactions sent
and received. Either partner must have the capability to retransmit an EDI message.
The Functional Acknowledgment (997) transaction set can be used to provide a level of
automation in the backup and recovery area. If the EDI system expects to receive a Functional
Acknowledgment for every transaction it sends, the EDI message should be available for
retransmissions until a Functional Acknowledgment corresponding to a specific EDI message is
received. Once the Functional Acknowledgment is received, the original EDI message can be
archived regardless of the normal archive timing.
Issue Date: March 7, 1997
2-10 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
The USEPA requires the use of the Functional Acknowledgment. The Functional
Acknowledgment is used to confirm receipt of the trading partner's transmission and indicate
acceptance or rejection of the transaction set by the translator. A Functional Acknowledgment is
not required for a transmission of Functional Acknowledgments. Because this phase of the EIIP
EDI project is a prototype effort, the Functional Acknowledgment will not be employed.
2.5.1 Disaster Recovery Considerations
Disaster recovery becomes correspondingly critical to the amount of business that is conducted
through the EDI channels. Consider the consequences to you and your trading partners if you
were suddenly unable to exchange transmissions for an extended period. It is unwise to assume
that you can fall back on a paper-based system. Your trading partners may not be able to quickly
switch from EDI messages to mailing their business transactions to you. You may not have
immediate access to the resources within your organization needed to process paper transactions.
Develop a plan to deal with extreme problems, such as a total loss of a Data Center or computer
system and a loss of a phone company switch station servicing your area.
2.6 Audit Considerations
One of the first questions raised when considering the use of EDI relates to its impact on
controls. Without a signed document and a paper audit trail, how will one know when a
transaction is valid and approved?
A major issue associated with the use of EDI relates to its impact on controls, particularly
without a paper audit trail which includes hardcopy signatures. The same elements of control
will exist in an EDI-based system that exists with a paper-based system. Most controls related to
EDI fall into three categories: confidentially, integrity, and authenticity. Confidentiality is the
control that allows only authorized persons access to the transactions. Integrity controls
validations of the data. Authenticity is the control that ensures the receiver that the transaction
received is theirs and is valid.
The following are specific examples of controls within the confidentiality, integrity, and
authenticity control categories.
Confidentiality
Encryption is a method of logically scrambling the EDI information with an
encryption key and giving the key only to persons who have a right to that
information. The key is an electronic code for this procedure;
Issue Date: March 7, 1997 ~
Revision Date: April 11, 1997 . 2-11
-------
Prototype Emission Modeling Implementation Guideline
• Password protection is a method used to control access to files. Passwords should
be changed often for maximum effect; and
• The use of a stand-alone computer for receiving EDI transmissions controls
access to the main computer. Once the EDI data is on the stand-alone computer,
it can be validated and uploaded to the main computer for use in applications.
Integrity
• Communications protocols provide bit count checking;
• Every XI2 transmission contains Segment, Transaction Set, and Functional Group
counts. Hash Total and selective segment counts are provided by certain
transactions. Functional Acknowledgments are available to confirm transaction
receipt and compliance to the standard; and
• Translators provide code validation and syntax checking.
Authenticity
• Value Added Networks (VANS) validate sender/receiver identifications and
passwords;
• Translator Trading Partner Profiles validate sender identification, passwords,
version/release, transmission sequence, and transaction set;
• Application programs validate personal Identification Numbers (PIN) and
specified data contained in the transaction set (i.e., dates, reference numbers).
Issue Date: March?, 1997
2-12 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 3 — LEGAL CONSIDERATIONS
3.1 General Introduction
The information outlined below is essential for a production environment and should be
considered when implementing a full EDI system. As this phase of the EIIP EDI implementation
is a prototype, many of the components/issues identified have not been addressed. The necessary
legal considerations will be fully addressed based on results of the prototype. The primary issues
that will be address include, but are not limited to:
• Record keeping;
• Authentication;
• Trading Partner Agreements;
• Third-party Agreements; and
• Laws, rules, and regulations.
The EIIP EDI project was established to support facilities that voluntarily wish to share
emissions data electronically. During the prototype phase of this project all requirements
currently in affect for the reporting of air emission modeling data must continue. Regulations as
currently written require the forms and signatures.
Businesses require control over their contractual and regulatory correspondence. Such control
includes the determination of when correspondence is transmitted, to whom it is transmitted,
when it reaches the recipient, and an appraisal of the accuracy, integrity and risks of the
communication. Some of the legal issues include:
• Various offer and acceptance rules;
• The propriety of EDI in lieu of hard copy documents;
• The competency of sufficiency and evidence;
• Electronic mailbox controls;
• Legal and regulatory record retention issues;
• Ownership and liabilities; and
Issue Date: March?, 1997
Revision Date: April 11, 1997 . 3-1
-------
Prototype Emission Modeling Implementation Guideline
• Various risks of transmissions.
Most commercial law has been developed without specifically addressing electronic message
systems. The precise legal status of EDI transmissions is therefore unclear in many cases.
EDI has been used successfully for a considerable number of years. For many companies, legal
uncertainties have not posed a substantial obstacle to the adoption of EDI. In many instances, the
legal risks of using EDI, when compared to the risks associated with traditional paper-based
trading systems, have been considered to be manageable. Certain legal risks have been
addressed with special agreements between trading partners and the adoption of appropriate in-
house policies.
It is important that new users consult with counsel throughout the EDI implementation process.
This chapter provides a very brief introduction to some of the issues counsel should consider
when a new user implements EDI. The full range of issues that must be dealt with, and the
importance of any particular issue, will vary from one user to the next.
EDI implementation should initiate a process by the business entity of rethinking its entire
records management and retention policies. The ultimate decision regarding scope and retention
period of electronic records depends on the company's overall business strategy and
requirements.
3.2 Record Keeping
The Phase I EIIP EDI prototype project is intended to facilitate the submission of data from
State/Local Air Quality Agencies to the USEPA. The hard copy retention of forms is an
individual program consideration that may be specified in regulations.
Internal control systems should be reevaluated in the context of EDI to assure responsibility for
data maintenance, including audit trail, transaction reconciliation, and backup capability.
When business transactions are recorded on paper documents, businesses can store those
documents as evidence of what took place. The intent of EDI is to eliminate the transmission of
paper documents. Internal record keeping systems should therefore be reevaluated in the context
of EDI. The ideal EDI record retention system meets the following record keeping criteria:
• Copies of all EDI transmissions must be retained;
• EDI transactions must be retained in both the original and translated format in
addition to normal application file retention;
• Storage medium for EDI transactions must be determined;
Issue Date: March 7, 1997
3-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
• Transmission activity logs containing pertinent time information must be retained;
• All programs used in the EDI system must be retained for the life of the record
retention;
• Records must be able to be retrieved in a form that can be admissible in any
judicial or other proceedings; and
• Record retention periods must be established.
At this time, requirements for record have not been finalized. At a minimum, the EIIP EDI
Trading Partners will be required to support the current USEPA standards for record keeping.
3.3 Authentication
Authentication refers to the establishment or verification of a claimed identity. This may be the
sender or receiver associated with a message. Authentication of an EDI transaction is contained
within the transaction. All EDI transactions have the ability to identify all parties involved.
It is important that the source and the integrity of data transferred between the trading partners be
assured before the data is manipulated. The security and controls needed to provide a proper
level of assurance is a business decision that should be based on an assessment of the risks
involved. The decision to implement a Message Authentication Code (MAC) should be mutual
between trading partners and stated as a requirement in the Trading Partner Agreement.
Traditionally, paper documents and signatures have been used to authenticate the data that
constitute commercial transactions. Authentication of EDI transmissions requires different
methods of authentication. With the implementation of any particular EDI system, users and
their counsel should ask the following questions within the context of the user's particular needs:
• Will the integrity and completeness of data transferred between trading partners
be adequately assured before it is relied upon?
• Will the source of a message, and the legal authority of that source, be
satisfactorily verified before the message is relied upon?
• If determined necessary, will adequate records be kept to show that authenticity of
messages was tested?
EDI poses no different threat from any automated system that utilizes telecommunications. The
issue is automation and electronic data vs a paper-based system. EDI formats simply provide a
structure to that data.
Issue Date: March?, 1997
Revision Date: April 11, 1997 . 3.3
-------
Prototype Emission Modeling Implementation Guideline
3.4 Trading Partner Agreement
Trading Partner Agreements (TPA) are an important part of any EDI system. They serve as the
"interface specification" between trading partners and provide specific details of the legal
agreements that define how the electronic commerce is to be conducted. Qualified legal advice
is required when a TPA is drafted.
However, the TPA must be more than a legal agreement between two organizations that
exchange data. Because the use of an electronic medium affects the trade relationship, TPA's are
generally recognized as fundamental to the EDI trade relationship. TPA's can:
• Bolster the enforceability of electronic transactions;
• Reduce confusion and potential misunderstanding;
• Apportion liability between the trading partners;
• Define confidentiality and security obligations;
• Serve as an educational tool and implementation checklist; and
• Provide an important audit and control mechanism.
The scope and treatment of issues addressed by a TPA generally depend on:
• The nature of the anticipated transactions;
• The policies and perspectives of the trading partners;
• An assessment of the risk; and ultimately
• The issues upon which the trading partners reach agreement.
The TPA should have the following characteristics:
• Administrative efficiency;
• Simplified legal approval;
• Defmiteness; and
• Certainty to expedite trade.
Issue Date: March?, 1997
3-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Appendix B contains the USEPA's generic Terms and Conditions Agreement for the use of EDI
for Environmental Reporting. Although this agreement is not referred to as a trading partner
agreement, it serves the same purpose. The document and other information pertinent to the use
of EDI within the USEPA can be found in the notice posted in the September 4, 1996 Federal
Register, Volume 61, Number 172, FRL-5601-4
For the prototype efforts, TPAs are not being initiated by the USEPA, however, as the EDI
system moves into production, they should be implemented.
3.5 Third-Party Agreements
If a user employs a third party, such as a VAN, to facilitate its EDI system, the company that
supplies the services will probably require that the user enter into a data communications
agreement with it. Among the issues the user should consider addressing in such agreement are
the following:
• A description of the services to be provided;
• The warranty by the VAN of its services;
• The liability of the VAN for a breach of the agreement or any damages resulting
from the mistakes of the VAN or its employees;
• The security, confidentiality, and integrity of messages handled by the VAN;
• The responsibility of the VAN in the event of a system failure or disaster;
• The disposal of data stored by the VAN in the event of a disagreement or an
interruption or termination of services;
• A description of the applicable pricing structure;
• The termination of the agreement; and
• An assumption of an independent, third-party review of the third-party vendor.
For the prototype, VANs or other third party vendors are not being employed. Therefore, as with
TPA's, Third-party agreements are not being initiated by the USEPA. As the EDI system moves
into production, agreements should be implemented as appropriate.
3.6 Laws, Rules, and Regulations
Issue Date: March?, 1997
Revision Date: April 11, 1997 . 3.5
-------
Prototype Emission Modeling Implementation Guideline
There is no adequate or comprehensive source of EDI law, but there are a few sources of laws,
rules and regulations that users may wish to consult. They are available through the American
Bar Association (ABA). Other sources may be applicable for transactions within specific
markets, industries or jurisdictions.
When implementing EDI, users and their counsel should consider whether any special laws, rules
or regulations apply to the users. Utilities and government contractors should carefully consider
whether regulations applicable to them restrict the implementation of EDI. It is not uncommon,
for example, for government regulations to require documents to be written on paper or have ink
signatures.
Users should also be aware that the International Chamber of Commerce has adopted Uniform
Rules of Conduct For Interchange of Trade Data by Teletransmission (UNCID). UNCID
purports to set forth voluntary rules of communication by EDI users. A copy of the UNCID
rules may be obtained from the ICC Publishing Corporation, 156 5th Ave., New York, New
York 10010. It should be noted that ANSI X12 neither endorses nor opposes UNCID.
Issue Date: March?, 1997
3-6 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 4 — ENVIRONMENTS
4.1 System Architecture
The graphic description of how the software and hardware are assembled to support the needs of
the user is called the system architecture. The system architecture relates primarily to the needs
of the end user rather than technique or technology. The system designer, as with any other
architect, must satisfy the user's requirement within the constraints of serviceability and cost.
There are three basic EDI system architectures:
Stand-alone Microcomputer: Outbound transactions are keyed into the microcomputer.
Inbound transactions are transferred to an attached printer. Translation software (to/from ANSI
standard) resides within the microcomputer. Communication software/hardware handles both
inbound and outbound transactions.
Microcomputer/Minicomputer Front-End: The microcomputer serves as a front-end
processor to the mainframe. The translation software (to/from ANSI standard) resides within the
microcomputer.
Mainframe/Minicomputer: All processing is performed within the mainframe. Inbound
transactions are received by the mainframe, translated, and forwarded for further processing.
Outbound transactions are consolidated, translated, and transmitted. Network communications
hardware/software are under the control of the mainframe.
With the addition of Value-Added Network services, you can "mix and match" the basic
architectures and let the network manage the complexity of different hardware/software. The
networks provide the capability of indirect communications through the use of electronic
mailboxes and support code, speed, and protocol conversion. Specifics may be found in the
applicable project EDI guideline.
The EIIP EDI prototype project will employ the Microcomputer/Minicomputer Front-End
scenario. The data that will be transferred using the EIIP EDI XI2 Specifications/Technical
Information Transaction Set will reside in the database system of the sending trading partner.
The EDI translation and communication software will reside on a microcomputer (PC) that is
capable of interfacing with the database system. An application program interface (API) will
also reside on the PC and will serve as the mechanism to extract the data to be transmitted from
the database system.
To initiate the process, the trading partner will access the database system using the API. The
API reformats the database output into an ANSI/ASC X12 formatted file and loads the data into
the EDI translation software. The EDI translation software translates the data into the
Issue Date: March 7, 1997
Revision Date: April 11, 1997 - 4.1
-------
Prototype Emission Modeling Implementation Guideline
ANSI/ASC XI2 841 Specifications/Technical Information Transaction Set per the EIIP X12 EDI
Convention Document. The transaction set is transmitted to the receiving trading partner.
For the EIIP EDI prototype project, communication will be performed point-to-point (refer to
Section 6 for more information). Therefore, the data will be sent directly between the sending
and receiving trading partners. If a VAN or other third party service were used, the data would
be transmitted through the service provider to the receiving trading partner's mailbox.
For the EIIP EDI prototype project, both trading partners will have similar architectures (i.e.,
microcomputer/minicomputer front-end). Therefore, the EDI transmission will be received by a
PC, where the data will be translated from the XI2 format to one that is able to be loaded into the
receiving database system. The receiving API residing on the receiving trading partner's PC is
responsible for loading the transmitted data into the appropriate database system.
The following outline organizes the steps that are needed to report air emission modeling
information for the EIIP EDI prototype project.
A) Air emission modeling data is collected by the trading partner and entered into
their database system. It is retained until it is ready for reporting to the
appropriate USEPA trading partner.
B) The trading partner initiates the EDI transmission by retrieving the data from the
database system through the application program interface (API) where it
reformatted for translation by the EDI translation software.
C) The EDI translation software processes the information, putting it into ANSI/ASC
X12 syntax. If syntax errors are noted, the data must be corrected to eliminate the
errors and the translation process is repeated until completed.
D) The EDI transmission is uploaded to the receiving trading partner over a dedicated
point-to-point communication network or other means of point-to-point
communication. A copy of the transmission data is maintained by the trading
partner as a record.
E) The EDI transmission is retrieved by the receiving trading partner. A copy of the
transmission is maintained by the trading partner as a record.
F) The receiving trading partner enters the transmission into the translation software,
verifies the transmission, and translates the data. A copy of the translated data is
maintained by the trading partner as a record. The ANSI/ASC XI2 997
Functional Acknowledgment Transaction Set is generated by the translator and
returned to the sending trading partner.
Issue Date: March 7, 1997
4-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
G) If retransmission is necessary due to errors, the initiating trading partner is
contacted to retransmit the data. Upon receipt, the receiving trading partner
begins the retrieval activities again until the transmission is completed.
H) The translated data is downloaded into the receiving database system via the
receiving trading partner's API.
4.2 Application Integration
Application refers to the current functional processes which may or may not be automated. To
take full advantage of EDI, the EDI solution should become part of the functional processes and
not an "add-on". EDI will change the way you conduct your business. Planning for integration
will reduce the impact of this change and allow a smooth transition to an environment which
maximizes your return on investment.
Total integration does not have to be achieved before starting EDI, but it should be an established
goal. Failure to achieve integration will result in the attainment of some short-term benefits, but
the real benefits which come from increased automation will be unattainable.
For the EIIP EDI prototype project, the goal is to electronically integrate the database systems of
reporting entities (e.g., USEPA Regional offices, State/local agencies, industry, etc.) currently
storing air emission modeling data with a mechanism to electronically transmit the data. By
doing so, the burden of manual reporting of modeling data will be reduced and the availability
and quality of the data can be increased.
To achieve this end, an API will be used to electronically retrieve data from the databases that
store the appropriate modeling data. The API will also reformat the data for EDI translation.
The EDI translation software formats the data from the API into the ANSI/ASC X12 EDI
standard format for transmission. Likewise, the reverse process will be performed by the
receiving trading partner's system. Ultimately, in a full production system, each of the data
management steps will be seamless to the trading partners and the air emission modeling
application will be fully integrated.
Issue Date: March 7, 1997
Revision Date: April 11,1997 - 4-3
-------
Prototype Emission Modeling Implementation Guideline
4.3 Translation
Translation is the automated process of converting application data in a proprietary format to
ANSI/ASC XI2 Standard format for sending transactions. The process is reversed when
transactions are received in the ANSI/ASC X12 formats. The core translation program uses
"table driven" subroutines to generalize processing regardless of the actual application being
processed. Specifications are taken by the program, depending on the data being processed and
the particular tables associated with the transaction set. The ANSI/ASC X12 standard provides a
specific structure for the data. It does not affect the program design or the program function. As
a result, there are many commercial software packages which provide "core translation" and
other related functions that are designed to support different EDI environments.
Some of the factors to be considered when deciding whether to make or to buy translation
software are the efforts required for programming, maintenance, testing, incorporating upgrades
to the ANSI/ASC XI2 Standard, and the development of the administrative programs necessary
to satisfy EDI audits. The availability of relatively inexpensive proven commercial software
packages supported by a growing industry should make development unnecessary. EDI software
should be managed as "system software" rather than "application software".
The EIIP EDI prototype project is using a PC-based EDI translation software package. The
software supports the ANSI/ASC XI2 standard that the program is implementing (the 841
Specifications/Technical Information) and provides functionality to verify ANSI/ASC X12
syntax rules, support communications, and import/export data to database systems/APIs.
Issue Date: March?, 1997
4-4 Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 5 — MAINTENANCE
5.1 Maintaining Guidelines
During the prototype implementation, maintenance of this guideline, the attached EIIP XI2 841
Convention Document, and the EIIP Phase I Core Data Model is the responsibility of the EIIP
Data Management Committee. Questions are to be referred to:
Ms. Lee Tooly
U.S. Environmental Protection Agency
Emission Factor and Inventory Group
EIIP Data Management Committee
Research Triangle Park, NC 27711
Telephone: (919) 541-5292
5.2 Maintaining ASC XI2 Standards
ANSI/ASC XI2 has a standard procedure for developing new transaction sets and maintaining
existing sets. Refer questions regarding the national standard to the EIIP EDI Coordinator
indicated above. Should additional information be required, the question will be referred to:
Data Interchange Standards Association, Inc (DISA)
Technical Department
1800 Diagonal Road, Suite 200
Alexandria VA 22314-2852
Telephone: (703) 548-7005
5.3 Version/Release
ANSI/ASC XI2 publishes a new Version/Release of the national EDI standards annually. The
publication contains the new transaction sets and the maintenance approved by the ANSI/ASC
X12 Committee. New Version/Releases are neither upward nor downward compatible with
respect to other version/releases of the standards. The new publication may not affect current
implementations. However, if it contains functionality necessary to the particular implemented
project, the EIIP EDI Project Coordinator will initiate the necessary actions to notify the
implementors, develop an implementation schedule, revise and distribute the implementation
guidelines and convention documents and coordinate an orderly transition to the new
Version/Release.
The ASC Draft Standard for Trial Use (DSTU) Version 3, Release 6 (003060) was chosen for the
EIIP EDI prototype project. Support for versions other then 003060 will be handled on a case-
issue Date: March 7, 1997
Revision Date: April 11, 1997 - 5-1
-------
Prototype Emission Modeling Implementation Guideline
by-case basis and will be controlled by the EIIP EDI Project Coordinator. The EIIP DMC will
retain the option of updating standards as new transaction sets and standards are approved.
Issue Date: March?, 1997
5-2 Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 6 — COMMUNICATIONS
6.1 General Introduction
This section provides an overview of the communication options available to trading partner(s)
planning to implement EDI. The section's purpose is to highlight the areas where key data
communication decisions must be made. There is no single or preferred solution. Each trading
partner must determine the proper approach based on current and projected transaction volumes
and desired level of investment.
Communications is the transport of information in an EDI environment and may be by physical
or telecommunication means. Physical means include the use of magnetic tape or courier
service. Data communication means the use of a public or private telecommunications network
to exchange data. Criteria to be considered when determining the communication mode for data
transfer include the following:
• Distance of transport;
• Number of destinations;
• Costs;
• Delivery time frame;
• Frequency of transport;
• Security;
• Volume of transactions;
• Compatibility of media; and
• Reliability
Each exchange method should be analyzed to determine whether or not the approach meets the
trading partners' communication needs. No matter which approach is selected, a contingency
plan should be formulated to address the possible event of a communication failure.
Issues to consider are procedures to address system failures, transmission error recovery
including establishing the maximum number of retransmission attempts, security, network
response time, and error reporting.
Issue Date: March?, 1997
Revision Date: April 11, 1997 . 6-1
-------
Prototype Emission Modeling Implementation Guideline
6.2 Protocols
Protocols are a set of conventions between communicating devices. Simple protocols define
only hardware configuration. More complex protocols define timings, data formats, error
detection, and correction techniques.
6.2.1 EDI Data Transfer Protocol
Communication capability, security, and data integrity are communication protocol issues to be
addressed by EDI trading partners.
Communication Compatibility
• Electrical Signaling
• Signaling between communication hardware, modem communication, and
channel modem;
• Modem types; and
• Transmission speed compatibility
• Line Control Protocol
• Between communications software, such as asynchronous, binary
synchronous, and other protocols;
• Call establishment;
• Data blocking and organization;
• Acknowledgment and signaling for handshaking and error control;
• Line turnaround procedures;
Issue Date: March?, 1997
6-2 Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
• Character synchronization; and
• Escape interrupt disconnect
• Data Transfer Protocol
• Compatible EDI data transfer programs and techniques for managing data
transfer.
Security
• EDI data going only to the intended trading partner;
• Control over access to communications and business systems;
• Identification and authorization of trading partners; and
• Authentication
Data Integrity
Data Transfer Process Integrity refers to the actions taken to prevent problems. An objective of
the EDI communication system is to provide a high degree of data process integrity to:
• Minimize potential loss of data by providing intermediate safe storage,
interchange authorization, retransmission approval, and mutual results
commitment;
• Minimize the potential for data duplication by providing temporary data
suspension; and
• Minimize the potential for situations that require human intervention by providing
status retention and transfer restart capabilities.
Error detecting protocols should be considered as the minimum communication requirement for
EDI. Asynchronous and binary synchronous communication protocols provide error handling
techniques based on the specific implementation.
Issue Date: March?, 1997
Revision Date: April 11, 1997 - 6-3
-------
Prototype Emission Modeling Implementation Guideline
6.2.2 Transmission Protocols
Transmission or data link protocols are either character-oriented or bit-oriented.
• Character-oriented protocols use a particular code set for transmission with some
of the characters in the code set reserved for control functions. Asynchronous and
binary synchronous protocols are examples of character-oriented protocols.
• Asynchronous protocol is synchronized by sending and receiving Data
Transmission Equipment (DTE) before each character is sent. Each character has
a start and stop bit to indicate beginning and end of each character. The start and
stop bits are the mechanism by which synchronization is established. Typical
asynchronous communications accommodated by microcomputers are transmitted
at a baud rate ranging between 300-9600 bits per second (EPS). Asynchronous
accuracy is inversely proportional to the speed of the data transfer. Higher levels
of accuracy can be obtained through the use of XMODEM, KERMIT, and others.
• Binary synchronous or bi-sync bit synchronization is established for a much
longer duration, usually for the time it takes to transmit several thousand bits.
This results in less transmission overhead but requires more complex circuitry.
Typical binary synchronous communication is transmitted at a baud rate ranging
between 2400-9600 BPS. Binary synchronous accuracy is not dependent on the
speed of the data transfer.
• Bit-oriented protocols are independent of any particular code set and no character
codes are reserved for control functions. High Level Data Link Control (HDLC)
and Advanced Data Communication Control Procedures (ADCCP) are examples
of this protocol. The major advantages are in speed and standardization.
6.3 Point-to-Point (Dedicated Network)
At this time, the EIIP EDI prototype project will employ the point-to-point type of
communication network. A genera] description is provided below. The actual details for the
implementation of a point-to-point network will be developed based on the prototype results.
Point-to-point or direct connect service is communication between two trading partners. Point-to-
point may employ dedicated circuits, or dial circuits, or a combination of the two. The type of
circuit used depends on a number of factors, two of which are volume and speed or timing of the
transmissions. An EDI user that elects direct communication with trading partners must have the
necessary in-house staff capable of managing the network and must address a number of issues
with each individual trading partner. Some of these issues are:
Issue Date: March?, 1997
6-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
• Service Levels;
• Communication Speeds;
• Transmission Modes;
• Modem Capabilities; and
• Line Protocols
Additionally, an EDI user electing to implement direct connections must be aware that not all
trading partners will have similar capabilities and therefore the trading partner may by necessity
elect to use a third party service.
6.4 Third Party Services
Although the EIIP EDI prototype project is not employing third party services at this time, a
general overview of this type of communication service is provided below.
Third-Party Services are those utilizing switched network technology and providing value-added
services. Switched networks connect and disconnect circuits as required to exchange data. The
three common switched network methods are circuit switching, message switching, and packet
switching.
Circuit Switching is used in public telephone systems. A circuit is dedicated between the
source and destination for the duration of the transmission. The sender and receiver must be
available at the same time.
Message Switching networks package the data in messages and pass the messages from switch
to switch. The sender and receiver do not have to be available at the same time, since the
message is stored at each intermediate step. For this reason, message switched networks are also
referred to as store and forward networks.
Packet Switching is similar to message switching, but it divides the data into smaller, equal-
sized pieces called packets. It takes less time to move data through the network, since large
messages don't have to be stored at each intermediate switch. The reduced delay, over message
switching, allows the two users to carry on a dialogue, referred to as an interactive process. In
addition, the reduced delay aids transaction processing by moving the transactions to their
designation quickly. The advantage of packet switching over circuit switching is that packet
switching makes efficient use of the data lines. Each packet carries a destination address, so
packets from multiple sources heading to different destinations can be transmitted down the same
data line.
Issue Date: March 7, 1997
Revision Date: April 11, 1997 - 6-5
-------
Prototype Emission Modeling Implementation Guideline
The above facilities and services may be obtained from commercial networks called Value
Added-Networks (VAN) rather than developed in-house. The commercial networks provide the
network management and knowledgeable staff to support your communication requirements.
Commercial networks now offer more than moving data from one site to another. Services
provided include mailbox service, data storage, speed and format conversion, and translation.
Not all companies have the communication facilities to accommodate the multiple
communication protocols that may be used by their potential trading partners. Third-party
service providers eliminate the need for a trading partner to invest heavily in communication
hardware, software, and personnel. A third-party service provider allows the convenience of a
single data transfer link to multiple trading partners independent of operating schedules, protocol
conversion, hardware interface, and conversion requirements.
When selecting a third-party service provider, a trading partner should evaluate the service
capabilities and performance offered. Issues to consider include:
• Speed of delivery;
• Dial out capabilities (e.g., auto-dial, scheduled);
• Data integrity;
• Reliability;
• Job queuing options;
• Interconnect capabilities; and
• Tracking and control reporting (audit, historical, and exception reporting)
Before data transfer begins with a third-party service, communications should be mutually
defined and agreed upon. The use of third-party communications should be transparent to
trading partners.
When establishing an EDI partnership, it is necessary to determine how the costs of third-party
services will be apportioned. These costs are usually split equally between the trading partners.
Costs associated with the use of a third-party service include:
• Start-up charges;
• Mailbox fees;
Issue Date: March 7, 1997
6-6 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
• Connect charges;
• Data storage;
• Network interconnect;
• Character charges; and
• Reports
A third party agreement between the trading partner and a telecommunications provider should
be signed. Section 3.5 lists items that should be included in a third party agreement.
6.5 Network Interconnects
As with the use of third-party services, the EIIP EDI prototype project is not currently employing
network interconnects. However, they should be noted as a viable means of exchanging data
when each trading partner wishes to use its preferred VAN. It is the responsibility of each
partner to research whether its preferred VAN has the full complement of desired interconnect
capabilities with the other.
6.6 The Internet
Although not currently employed with the EIIP EDI prototype project, the Internet is type of
third-party service that can be used to transmit data using EDI. The Internet can be a more cost
affective means to exchange information using the ANSI/ASC XI2 standards, but the level
added value is reduced as compared to the use of a VAN. The Internet supports message
switching and telecommunication access, but no other more robust types of messaging support.
Functional issues such as audit reporting, security verification, user support, and any other
system requirements must be evaluated prior to implementing the Internet as a
telecommunications mechanism.
Issue Date: March?, 1997
Revision Date: April 11, 1997 • 5.7
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March 7, 1997
6_8 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 7 — MISCELLANEOUS
7.1 Industry Business Models
7.1.1 Introduction
The USEPA has implemented a number of ANSI/ASC X12 Transaction Sets. Selection of a
transaction set is based on the specific business issue to be solved and the defined purposed of
the transaction set. It is the intention of the USEPA to use national standards where they exist
and to avoid developing specific purpose transaction sets.
The following is an overview of the ANSI/ASC XI2 Transaction Sets used by the EIIP in the
implementation of EDI.
7.1.2 Transaction Sets
The EIIP implementation currently uses the ANSI/ASC X12 841 Specification/Technical
Information Transaction Set. Under other USEPA initiatives, this Transaction Set is also used by
the Pennsylvania Department of Environmental Protection (PADEP), Bureau of Air Quality
(BAQ) to receive air emission inventory data.
For the Phase I of the EIIP EDI prototype project, the transaction set is used to transmit air
emission modeling data between reporting State Agencies and the USEPA. This implementation
will be expanded in the future to include reporting from regulated industries to the State
Agencies and/or USEPA Regions.
The ANSI/ASC X12 997 Functional Acknowledgment Transaction Set is also employed in a
production system. The use of the Functional Acknowledgment is a requirement of the USEPA
for all EDI implementations. As this phase of the project is a prototype, this transaction set will
not be employed.
7.2 Related Industry Topics
Not Currently Used.
7.3 EDI Vendor References
EDI is offered as a standard interface so trading partners, software manufacturers and VANs can
interact without concern for proprietary features. To achieve this, trading partners must obtain
and employ the necessary and appropriate XI2 translator software and communications software.
These software components can be obtained from a number of sources, including: purchasing the
package from a vendor for use on the trading partner's computer system, purchasing the services
Issue Date: March?, 1997
Revision Date: April 11, 1997 • 7.1
-------
Prototype Emission Modeling Implementation Guideline
of a VAN to administer the software remotely, or developing the software in-house. Before
developing an in-house translator, examine the development costs and the maintenance costs. A
new version/release of the ANSI/ASC X12 Standard is released annually with sub-releases
available for standards approved for publication in February or in June. When updated EDI
standards are available, they may or may not need to be implemented. Implementation of an
updated Version/Release is governed by the enhanced business support it provides, the need for
that enhanced support by the trading partners, and the desirability on the part of the trading
partners to maintain previous Versions/Releases.
For the purpose of the EIIP EDI projects, trading partners shall acquire the EDI software that best
meets their needs for interfacing with the USEPA Program Offices and with other trading
partners they may have.
The USEPA does not recommend or endorse any vendors translation or communication
software. Listings of EDI software and service vendors can be obtained through ANSI/ASC
X12, EDI periodicals, and trade journals. The following provides some ideas for minimum
capabilities/criteria to consider. The software should support the following specifications:
Operating System
• Support the operating platform and operating environment configuration specified
by the organization.
Communications and Security
• Support the capability for sending and receiving EDI-formatted data.
• Support all connections to multiple VANs or direct connects to trading partners.
• Support multiple communications protocols including async, bisync, and
X.400/X.25.
• Support the use of EDI transactions over the Internet, including appropriate
security measures.
Issue Date: March?, 1997
7-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Security
• Support security options such as password, Personal Identification Number (PIN),
menu and access type security.
• Provide built-in virus protection.
• Provide automatic recovery in the event of a system shutdown.
Reporting and Auditing
• Automatically verify inbound and outbound data to determine whether they are in
compliance with EDI standards.
• Automatically notify user when errors occur.
• Maintain detailed history logs of all processes performed to determine error status
and track processing activity.
• Provide automatic matching of audit trail reports of inbound and outbound
functional acknowledgments with their associated outbound transaction set.
• Provide flexible error processing conditions and allow a variety of reports that
describe and diagnose errors.
• Provide reports on document types, document numbers, control numbers, file
names, error status, acknowledgment status, and transaction volume statistics
based on user-selected criteria.
Data Management
• Provide the capability for an application system interface program to extract data
from an application system and create fixed-length files for subsequent translation
to an EDI format. The reverse is also required.
• Support manual data entry of outbound EDI data through data entry screens.
• Support batch downloads from an application interface linking the translation
software to an organization's application system.
• Support flexibility in defining pre- and post-communication processes which
could include interface routines, programs, and command procedures.
Issue Date: March 7, 1997
Revision Date: April 11, 1997 - 7.3
-------
Prototype Emission Modeling Implementation Guideline
Support scheduled or manual file purging.
Support the ability to import from and export to flat file formats.
Support the ability for inbound transactions to be printed or viewed on-line in a
human readable format.
Support the ability to archive all intermediate input and output data files.
The software should provide a facility that monitors the use of internal business
document identification numbers, such as manifest numbers, to avoid duplication.
Translation
• Support ANSI/ASC XI2 standards, all current and future versions, releases and
implementations and all XI2 transaction sets.
• Include predefined tables of standard transactions, segments, and elements and
allow copying of standard tables to create customized standards.
• Support the ability to define cross reference tables. These tables are used to
reconcile codes if trading partners use different codes from recipient and/or the
standard.
• Provide the capability for automatically sending and receiving Functional
Acknowledgments to identify the successful receipt of information by Trading
Partners and the highlighting of unacknowledged transaction sets that have been
sent.
• Allow customizing of core translation and error notification scripts.
Mapping and Trading Partner Configuration
• Support automated data-mapping procedures embedded in the EDI translation
software that creates fixed-length files according to the user's requirements for
subsequent translation to an EDI format. The reverse process should also be
provided.
• Provide for multiple conditional processing. This is the ability to use multiple
data elements from a transaction set to generate a single data element for the
output flat file and vice versa.
Issue Date: March 7, 1997
7-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
• Allow maps, profiles, and other user-defined tables are able to be migrated from
one X12 version to another without having to manually reenter the information.
• Provide the facility to maintain a profile of each Trading Partner that identifies the
name, Dunn &Bradstreet number, organizational identifier, phone numbers, and
segments in a transaction set required by the Trading Partner.
Application System/Database
• Allow database definitions, operations, algorithms, and other processing rules to
be defined through dynamic, table-driven tools. All tables should not be
imbedded in code - only program functions should be in the executables.
Ease of Use
Support
Provide straight-forward, well-organized, intuitive user interface with a point-and-
click Graphical User Interface (GUI).
Provide table-driven utilities to modify/create transactions, trading partner data,
and maps.
The software vendor should provide technical documentation, user
documentation, maintenance support, help desks, tutorial packages and training
support to assist the Trading Partners in the use of the translation software.
Provide software and software upgrades as applicable and within an appropriate
time frame.
Miscellaneous
Proven track record in EDI as indicated by its use other sites and the provision of
references of other users.
Issue Date: March 7, 1997
Revision Date: April 11, 1997 7-5
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March 7, 1997
7-6 Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 8 — GLOSSARY OF TERMS
AFS, AIRS Facility Subsystem, Federal database.
AIRS, Aerometric Information Retrieval System, Federal database.
ANSI, The American National Standards Institute (ANSI) is the national coordinator for
standards in the United States.
ANSI Standard, A document published by ANSI that has been approved through the consensus
process of public announcement and review. Each of these standards must have been developed
by an ANSI committee and must be revisited by that committee within five years for update.
ASC X12, An abbreviation for Accredited Standards Committee (ASC) XI2. It is comprised of
a non-profit clearing house and coordination body for voluntary data standards activities in U.S.
The purpose is to develop uniform standards for the electronic interchange of business
transactions for submission to ANSI for subsequent approval and dissemination.
Authentication, A mechanism that allows the receiver of an electronic transmission to verify the
sender of the integrity of the content of the transmission through the use of an electronic "key" or
algorithm, which is shared by the trading partners. This is sometimes referred to as an electronic
signature.
CAAA, Clean Air Act Amendments of 1990.
CFR, The Code of Federal Regulations contains the detailed regulations, written by Federal
Agencies, to implement the provisions of laws passed by Congress. Regulations in the CFR are
equivalent to Federal law.
Compliance Checking, A checking process that is used to ensure that a transmission complies
with ASC X12 syntax rules.
Composite Data Element, One or more component data elements delimited by sub-element
separators.
Condition Designator, An indicator assigned to each data element in a segment and defines
how it is to be used in the segment. Data elements may be designated as Mandatory (M),
Optional (O) or Relational (X). Refer to ANSI/ASC XI2.22 Data Segment Directory
Introduction and ANSI/ASC X12.6 Application Control Structures, paragraph 3.7.2.2 -
Condition Designator.
Issue Date: March?, 1997
Revision Date: April 11, 1997 - 8-1
-------
Prototype Emission Modeling Implementation Guideline
Control Segment, A control segment has the same structure as a data segment but is used for
transferring control information for grouping data segments. Examples of types of Control
Segments are Loop Control Segments (LS/LE), Transaction Set Control Segments (ST/SE),
Functional Group Control Segments (GS/GE), and Interchange Control Segments (ISA/IEA,
TA1). Control segments are defined in ANSI/ASC XI2.6 - Application Control Structures,
paragraph 3.10 - Control Segment. Interchange segments are control segments and are defined in
ANSI/ASC X12.5 - Interchange Control Structures. Diagrams of the segments appear in
ANSI/ASC X12.22 - Data Segment Directory and are identified as 'control segment'.
Conventions, Common practices and/or interpretations of the use of the ASC X12 standards, as
agreed upon by two or more trading partners. Conventions define what is included in a specific
implementation of an ASC XI2 standard.
Data Element, A data element can represent a qualifier, a value, or text (such as a description).
Each data element is identified by a number used for reference in ANSI/ASC XI2.3 - Data
Element Dictionary.
Data Element Dictionary (XI2.3), Defines specifications for each data element.
Data Element Length, This is the range, minimum to maximum, of the number of character
positions available to represent the value of a data element. A data element may be of variable
length with range from minimum to maximum, or it may be of fixed length in which the
minimum is equal to the maximum.
Data Element Reference Number, Identifier assigned to each data element as a unique
identifier. It is used in all segments to aid in locating the data element definitions in ANSI/ASC
XI2.3 - Data Element Dictionary.
Data Element Requirement Designator, A code defining the need for a data element value to
appear in the segment if the segment is transmitted. The codes are mandatory (M), optional (O),
or relational (X).
Data Element Separator, A unique character preceding each data element that is used to delimit
data elements within a segment.
Data Element Type, A data element may be one of the following types: numeric (Nn), decimal
number (R), identifier (ID), string (AN), date (DT), time (TM), binary (B), or fixed-length string
(FS).
Data Model, A description of the principles of organization of a database, including data
entities, attributes, relationships, and data specifications.
Issue Date: March 7, 1997
8-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Delimiters, The delimiters consist of two levels of separators and a terminator. The delimiters
are an integral part of the transferred data stream. Delimiters are specified in the interchange
header and may not be used in a data element value elsewhere in the interchange. From highest
to lowest level, the separators, and terminator are segment terminator, data element separator,
and sub-element separator.
DISA, Data Interchange Standards Association. A non-profit organization which serves as the
Secretariat for X12.
Direct Transmission, The exchange of data from the computer of the sending party directly to
the computer of the receiving party. A third-party value added service is not used in a direct
transmission.
DMC, Data Management Committee of the U.S. US EPA Emission Inventory Improvement
Program responsible for the administration of issues related to air emission modeling data.
Draft Standard for Trial Use (DSTU), A document approved for publication by the full XI2
committee following membership consensus and subsequent resolution of negative votes (Final
Report of XI2 Publications Task Group). The Draft EDI Standard for Trial Use document
represents an ASC X12 approved standard for use prior to approval by ANSI.
ECOS, Environmental Council of States, air emission modeling workgroup.
EIIP, Emission Inventory Improvement Program sponsored by the USEPA to address the
collection and use of air emission inventory/modeling information.
Electronic Data Interchange (EDI), The abbreviation for electronic data interchange, which is
commonly defined as "the computer-to-computer exchange of business information in a standard
format." An EDI transmission is a highly structured message intended for automated processing
by a computer. It is meant to be machine-readable so that it doesn't require human intervention
to be interpreted and understood. EDI is primarily used for intercompany communication. All
references to EDI under USEPA programs refers to the utilization of ASC X12 standards.
EDI Translation, The conversion of application data to and from the ANSI/ASC XI2 standard
format.
EDI Translator, Computer software used to perform the conversion of application data to and
from the XI2 standard format.
EFIG, Emission Factor and Inventory Group of the USEPA.
Issue Date: March 7, 1997
Revision Date: April 11, 1997 - 8-3
-------
Prototype Emission Modeling Implementation Guideline
Electronic Envelope, Electronic information that groups a set of transmitted documents being
sent from one sender to one receiver.
Element Delimiter, A single-character that follows the segment identifier and each data element
in a segment except the last.
Electronic Mailbox, The place where an EDI transmission is stored for pickup or delivery
within a third-party service provider's system.
Encryption, A process of transforming clear text (data in its original, uncoded form) into
ciphertext (encrypted output of a cryptographic algorithm) for security or privacy.
EMAD, Emission Monitoring and Analysis Division of the USEPA.
USEPA, The United States Environmental Protection Agency (USEPA). Established in 1970 by
presidential executive order, it brings together parts of various government agencies involved
with the control of pollution. Note that some State environmental authorities may be called EPA
also, as in Illinois EPA.
FOIA, Freedom of Information Act.
Functional Acknowledgment, A transaction set (997) transmitted by the receiver of an EDI
transmission to the sender, indicating receipt and syntactical acceptability of data transmitted
according to the ANSI/ASC X12 Standards. The functional acknowledgment allows the
receiving party to report back to the sending party problems encountered by the syntax analyzer
as the data is interpreted. It is not intended to serve as an acknowledgment of data content.
Functional Group, One or more transaction sets bound together by a functional group header
segment and a functional group trailer segment.
Functional Group Control Segments, Group delineated by the functional group header (GS
segment) and the functional group trailer (GE segment). GS starts and identifies one or more
related transaction sets and provides a control number and application identification information.
GE defines the end of the functional group of related transaction sets and provides a count of
contained transaction sets.
Guidelines, Instructions on the use of EDI. Guidelines provide additional information about
conducting EDI and may provide assistance on how to implement EDI.
Interchange, The actual transfer of data between trading partners.
Issue Date: March?, 1997
8-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Interchange Control Envelope, The outer envelope that holds multiple functional group
envelopes for transmission. The structure of the envelopes within the Interchange Control
Envelope impacts the efficiency of the processing.
Interchange Control Segments, ISA/IEA segments identify a unique interchange being sent
from one sender to one receiver.
Interchange Control Structure, The interchange header and trailer segments envelope one or
more functional groups or interchange related control segments and perform the following
functions: 1) defines the data element separators and the data segment terminators, 2) identifies
the sender and receiver, 3) provides control information for the interchange, and 4) allows for
authorization and security information. (X12.5).
Loop, A group of semantically related segments; these segments may be either bound together or
not.
Loop Repeat, Maximum number of times a specified loop can be used at this location in a
transaction set.
Mandatory (M), A data element/segment requirement designator that indicates that the presence
of a specified data element is required.
Mapping, The process of identifying the relationship between the data elements in the standard
transaction set and the data elements in the application.
Max Use, The maximum number of times a segment can be used at the location in a transaction
set.
NAAQS, National Ambient Air Quality Standards.
OAQPS, Office of Air Quality Planning and Standards of the USEPA.
Optional (O), A data element/segment requirement designator that indicates that the presence of
a specified data element/segment is at the option of the sending party, which can be based on the
mutual agreement of the interchange parties.
Qualifier, A data element that identifies or defines a related element, set of elements, or a
segment. The qualifier contains a code taken from a list of approved codes.
Relational Condition (X), A data element requirement designator that indicates that the
presence of a specified data element is dependent on the value or presence of other data elements
in the segment. The condition must be stated and must be computer processable. The condition
Issue Date: March?, 1997
Revision Date: April 11, 1997 . 8-5
-------
Prototype Emission Modeling Implementation Guideline
may be paired or multiple (P); required (R); exclusion (E); conditional (C); or list conditional
(L).
RFP, Reasonable Further Progress is a type of air emission report.
Security, System screening that denies access to unauthorized users and protects data from
unauthorized uses.
Segment, Logically related data elements in a defined sequence. A data segment consists of a
segment identifier, one or more data elements each preceded by an element separator, and ending
with a segment terminator. Each segment shall have a stated purpose, which should be
sufficiently generic as to encourage the segment use in other transaction sets.
Segment Directory (XI 2.22), Provides the purposes and formats of the segments used in the
construction of transaction sets. The directory lists each segment by name, purpose, identifier,
the contained data elements in the specified order, and the requirement designator for each data
element. A segment directory is developed to standardize permissible segments.
Segment Identifier, A unique identifier for a segment composed of a combination of two or
three uppercase letters and digits. The segment identifier occupies the first character positions of
the segment. The segment identifier is not a data element.
Segment Terminator, A unique character appearing at the end of a segment to indicate the
termination of the segment.
SIP, State Inventory Plan is a type of air inventory report.
Standards, The technical documentation approved by ASC XI2, including transaction sets,
segments, data elements, codes and interchange control structures. Standards provide the
structure for ASC XI2.
Sub Element Separator, A unique character used to delimit the component data elements within
a composite data element.
Syntax, The grammar or rules that define the structure of the EDI standards (i.e., the use of
loops, qualifiers, etc.). Syntax rules are published in ANSI XI2.6.
Trading Partner, The sending and/or receiving party involved in the exchange of electronic data
interchange transmissions.
Issue Date: March?, 1997
8-6 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Trading Partner Agreement (TPA), Serves as the "interface specification" between trading
partners and provides specific details of the legal agreements that define how the electronic
commerce is to be conducted.
Transaction Set, A semantically meaningful unit of information exchanged between trading
partners.
Transaction Set Control Segment, Delineators for the transaction set — transaction set header
(ST segment) and the transaction set trailer (SE segment). The header starts and identifies the
transaction set. The trailer defines the end of the transaction set and provides a count of the data
segments, which includes the ST and SE segments.
Transaction Set ID, An identifier that uniquely identifies the transaction set. This identifier is
the value in the first data element of the transaction set header segment.
VAN, Value Added Network. Third-party service organizations.
Version/Release, Identifies the publication of the standard being used for the generation or the
interpretation of data in the XI2 standard format. May be found in the Functional Group Header
Segment (GS) and in the Interchange Control Header Segment (ISA), (e.g., Version 003040
means Version 3 Release 4).
X12, The ANSI committee responsible for the development and maintenance of standards for
Electronic Data Interchange (EDI).
XI 2.5, Interchange Control Structure. This standard provides the interchange envelope of a
header and trailer for the electronic interchange through a data transmission, and it provides a
structure to acknowledge the receipt and processing of this envelope. X12.5 includes separate
segments and data elements not in X12.22 or X12.3.
XI 2.6, Application Control Structure. This standard describes the control segments used to
envelop loops of data segments, to envelop transaction sets, and to envelop groups of related
transaction sets.
Issue Date: March?, 1997
Revision Date: April 11,1997 • 8-7
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March 7, 1997
Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 9 — FORMS AND DOCUMENTS
9.1 ASC XI2 Transaction Sets
The EIIP EDI complies with the ASC XI2 standards for Electronic Data Interchange for its
Program. The EIIP Data Management Committee will support the following ASC XI2
transaction sets:
ISA/IEA, GS/GE, ST/SE Header and Trailer Formats; and
• 841 - Specifications/Technical Information
9.1.1 Header/Trailer Format
The USEPA has defined the element to be used in the Interchange Control Header/Trailer
(ISA/IEA), Functional Group Control Header/Trailer (GS/GE), and the Transaction Set
Header/Trailer (ST/SE) for all transmissions to and from program trading partners.
The interchange header and trailer segments envelop one or more functional groups or
interchange related control segments and perform the following functions:
• Define the data element separators and data segment terminators;
• Identify the sender and receiver;
• Provide control information for the interchange; and
• Allow authorization and security information.
9.1.2 841 Specifications/Technical Information
The 841 Specifications/Technical Information Transaction Set is used to transmit air emission
inventory or modeling data. More information regarding the 841 Transaction Set is located in
Appendix D.
9.2 ASC XI2 Documents
The following ASC XI2 documents should be referenced for additional information, standard
format, and implementation issues.
ASC X12 Draft Standards, Version 003 Release 060, Document Number ASC X12S/95-533 is
available through:
Issue Date: March 7, 1997
Revision Date: April 11, 1997 • 9.1
-------
Prototype Emission Modeling Implementation Guideline
Data Interchange Standards Association, Inc. (DISA)
1800 Diagonal Road, Suite 200
Alexandria, VA 22314-2852
Telephone: (703) 548-7005
Reference to the EIIP Phase I Core Data Model and code lists identified in the convention
document are available through:
Ms. Lee Tooly
U.S. Environmental Protection Agency
Emission Factor and Inventory Group
EIIP Data Management Committee
Research Triangle Park, NC 27711
Telephone: (919) 541-5292
9.3 EIIP XI2 841 Convention Document Organization and Convention-for-Use
The EIIP EDI prototype project has developed a Convention Document for use with the
electronic transfer of air emissions data. The Convention Document follows the standards set by
the ANSI/ASC X12 for EDI. The document includes the EIIP's implementation of the
ANSI/ASC XI2 841 Specifications/Technical Information transaction set.
The ANSI/ASC X12 841 Specifications/Technical Information is a complex transaction set that
is based on a design concept that uses hierarchical levels. This type of organization is similar to
that commonly used with organizational charts. In this type of scheme, where there is a primary
level which has one or more subordinate sub-levels, which in turn may have one or more
subordinate sub-levels. This transaction set is based on the same principle.
The following outlines the hierarchical levels defined by the EIIP for use in the prototype EDI:
Header (H) Data that applies to the entire modeling data set. The information includes:
confidentiality indicator; inventory type; general notes, comments, and
descriptions; data model version; transmission date and time; data collection
period; DARS quality rating score for the transaction set; organization
name(s) and location data; and contact information. The standard requires that
there only be a single header per transaction set. Therefore, there will only be
a single header-level, to which all other levels are subordinate.
Site/Source (4) Data that applies to the site/source for which the data is being reported. The
information includes: confidentiality indicator; site identification information;
geographic location pointer (actual data collected in the header-level); general
Issue Date: March 7, 1997
9-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
message; site/source type; Standard Industry Classification (SIC) code;
number of employees; map reference data; and chemical speciation data.
By convention of the EIIP implementation, this level may be used multiple
times per transaction set as long as each occurrence shares the same source
type. As a result, the site/source-level will always be subordinate to a single
header-level, but may have multiple physical-levels subordinate to it.
Physical (5)
Process
(6)
Data that applies to the physical unit for which the data is being reported. The
information includes: confidentiality indicator; physical unit identification
information; geographic location pointer (actual data collected in the header-
level); general message; physical unit type; emission unit, emission release
point, and control equipment information; grid/county area data; physical unit
operational status, and emission path data.
By convention of the EIIP implementation, this level may be used multiple
times per transaction set. As a result, the physical-level will always be
subordinate to a single site/source-level, but may have multiple process-levels
subordinate to it.
Data that applies to the process for which the data is being reported. The
information includes: confidentiality indicator; process identification
information; general message; description of materials; emission process
information; Source Classification Code (SCC); Standard Industry
Classification (SIC) code; process growth factor information; operating
schedule; seasonal adjustment factors; and process characteristic information.
By convention of the EIIP implementation, this level may be used multiple
times per transaction set. As a result, the process-level will always be
subordinate to a single physical-level, but may have multiple activity-levels
subordinate to it.
Activity (C) Data that applies to the activity (throughput) for which the data is being
reported. The information includes: confidentiality indicator; activity
(throughput) identification information; DARS quality rating score;
throughput method code; activity (throughput) schedule; seasonal adjustment
factors; meteorological data; and typical day information.
By convention of the EIIP implementation, this level may be used multiple
times per transaction set. As a result, the activity-level will always be
subordinate to a single process-level, but may have multiple emission-levels
subordinate to it.
Issue Date: March?, 1997
Revision Date: April 11, 1997
9-3
-------
Prototype Emission Modeling Implementation Guideline
Emission (9) Data that applies to the emission for which the data is being reported. The
information includes: confidentiality indicator; emission-specific pollutant
identification; control strategy information; rule effectiveness information;
total capture/control efficiency data; rule penetration information; aggregate
control efficiency, rule effectiveness, estimated emissions, and emission
factors method codes; estimate emissions data; emission factors data; and
DARS quality rating score.
By convention of the EIIP implementation, this level may be used multiple
times per transaction set. As a result, the emission-level will always be
subordinate to a single site/source-level, but as it is the lowest level in the
hierarchy, it will never have any subordinate levels.
The hierarchical organization of the Convention Document is illustrated below, including the
corresponding XI2 code values that they are referenced by.
HEADER
SITE/SOURCE-LEVEL (HL03 = 4)
PHYSICAL-LEVEL (HL03 = 5)
PROCESS-LEVEL (HL03 = 6)
ACTIVITY-LEVEL (HL03 = C)
EMISSION-LEVEL (HL03 = 9)
Each HL segment is comprised of two to four data elements that define it. These data elements
identify the individual HL segments and specify the relationships between the individual HL
segments. The specific uses of each of the data elements is described below.
HL01 (Hierarchical ID Number) - This data element must contain a unique label for each
occurrence of the HL segment in the air emissions modeling transaction. An HL segment is
required to define each level in the hierarchial "organization". For example, in a basic modeling
data set with three processes being reported for a single physical unit from a single site/source,
five occurrences of the HL segment are required: one for the site/source level, one for each
physical unit, and one for each physical unit's emission process. By convention, the hierarchical
ID number will start with "1" for the first occurrence of the HL segment I the transaction set and
increment by one for each occurrence thereafter within the same transaction set. The number
will return to "1" for the next transaction set.
HL02 (Hierarchical Parent ID Number) - This data element identifies the Hierarchical ID
Number of the HL segment to which it is subordinate. In our example above, the Hierarchical
Issue Date: March 7, 1997
9-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Parent ID Number of each of the process-level occurrences of the HL segment will be "2",
identifying the physical-level HL segment. The HL02 value for the physical-level will be "1" as
the site/source HL segment is its parent. The value of HL02 for the site/source HL segment will
be null because it has no parent HL segment. HL02 is mandatory for all other occurrences of the
HL segment.
HL03 (Hierarchical Level Code) - This data element provides the level of detail implied by the
series of segments that follow the current HL segment, up to the next occurrence of the HL
segment in the transaction set. In other words, the data contained in HL03 indicates the grouping
of the information at the current HL-level. For example, if HL03 is "4", it indicates the
following segments in that HL-level, form a logical grouping of data relating to site/source-level
information. Likewise, if HL03 is "6", it indicates that the following segments are associated
with process information.
HL04 (Hierarchical Child Code) - This data element indicates whether there are subordinate
(i.e., child) HL segments to the current HL segment. Use of this data element is optional. If
used, a value of "0" indicates no subordinate HL segments and value of "1" indicates one or
more subordinate HL segments.
The example below illustrates the relationships between the various HL segments as described.
SITE/SOURCE-LEVEL
(HL01 = 1)
(HL02 = blank)
(HL03 = 4)
(HL04 = 1)
PHYSICAL-LEVEL
(HL01 = 2)
(HL02 = 1)
(HL03 = 5)
(HL04 = 1)
PROCESS-LEVEL*! PROCESS-LEVEL#2 PROCESS-LEVEL#3
(HL01 = 3) (HL01 = 4) (HL01 = 5)
(HL02 = 2) (HL02 = 2) (HL02 = 2)
(HL03 = 6) (HL03 = 6) (HL03 = 6)
(HL04 = 1 if HL follows) (HL04 = 1 if HL follows) (HL04 = 1 if HL follows)
By convention, for the EIIP prototype project, a transaction set will consist of the data being
reported for a single source type (e.g., point, area, nonroad, mobile, and biogenic). A transaction
set can not contain data for more than one source type. Within each transaction set, data for
multiple sites/sources may be reported. Likewise, multiple sets of physical unit, process,
activity, and emission data, may be reported for each site/source.
If data for multiple source types must be reported, they can be submitted in the same
transmission as multiple transaction sets can be included in a single transmission. However, as
Issue Date: March 7, 1997
Revision Date: April 11,1997 ' 9-5
-------
Prototype Emission Modeling Implementation Guideline
stated above, each source type must be reported as a single transaction set. Refer to Section 10
for more definition of transaction set organization and use.
9.4 Cross Reference Matrix of Phase I Core Data Model vs. Modeling Data Set vs. EIIP
XI2 841 Convention Document
This table is a cross reference between the EIIP XI2 841 Convention Document, the EIIP Phase I
Core Data Model, and the modeling data set that is being implemented for the prototype effort.
The table displays each data attribute specified in the data model and where the corresponding
data element is located in the convention document relative to the data elements that comprise
the modeling data set. As such, the cross reference indicates the location of each emissions
modeling data element within the convention document. The modeling data elements that are
indicated are those that are required for transmission under the prototype EDI activities. The
data model entities and attributes are for reference use only.
Appendix C contains the cross reference between the Phase I Core Data Model and the EIIP XI2
841 Convention Document. The table shows the location of each data model attribute within the
convention document.
Cross Reference Matrix of Phase I Core Data Model vs.
Modeling Data Set vs. EIIP X12 841 Convention Document
EIIP
Entity
Activity/
Schedule
Activity/
Schedule
EIIP
Attribute
Start
Date/Time
Process Rate/
Throughput
X12 Data Element
Activity (throughput) beginning date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
DTM01 in LX loop = '196'
Activity (throughput) data:
MEA03 in LX loop (pos. 545) if
HL03 = 'C' and
MEA01 in LX loop = TR'
Modeling
Attribute
Name
Average
Summer
Weekday
Emissions
Annual
Emissions
Average
Summer
Weekday
Emissions
Activity Level
Fuel Use
Activity Level
Comments
Each day and
pollutant
emission have
separate
instances in the
Emissions
entity.
9-6
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP
Entity
Activity/
Schedule
Aggregate
Controls as
Applied
Aggregate
Controls as
Applied
Aggregate
Controls as
Applied
Control
Equipment
Control
Equipment
Emission
Factors
EIIP
Attribute
Unit of
Measure
Total Capture/
Control
Efficiency
Rule
Effectiveness
Rule
Penetration
Percent
Control
Efficiency
Device Type
Numeric Value
X12 Data Element
Activity (throughput) data:
MEA04 [composite] in LX loop (pos. 545) if
HL03 = 'C'
Total capture/control efficiency:
MEA03 in CID loop (pos. 741) if
HL03 = '9' and
CID04 in detail level = 'CE' and
MEA01 in CID loop = 'AH'
Rule effectiveness:
MEA03 in CID loop (pos. 741) if
HL03 = '9' and
CID04 in detail level = 'CE' and
MEA01 in CID loop = 'AG'
Rule penetration:
MEA03 in CID loop (pos. 741) if
HL03 = '9' and
CID04 in detail level = 'CE' and
MEA01 in CID loop = 'PM'
Percent control efficiency:
MEA03 in LX loop (pos. 229) if
HL03 = '5' and
MLAU^i in LA loop - t/U I
Physical unit code:
PID04 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP'
Emission factor data:
STA02 in CID loop (pos. 751) if
HL03 = '9' and
CID04 in detail level = 'EF'
Modeling
Attribute
Name
Activity Level
% Control
Efficiency
Rule
Effectiveness
% Rule
Penetration
Primary
Control
Efficiency
Primary and
Secondary
Control
Devices (and
additional)
Control
Device Code
Emission
Factor
Emission
Factor
Comments
Each pollutant-
specific control
efficiency has a
separate
instance in the
Aggregate
Controls as
Applied entity.
Each pollutant-
specific control
efficiency has a
separate
instance in the
Aggregate
Controls as
Applied entity.
Handled as
separate
instances of the
Control
Equipment entity
and linked
through the path
entity.
Assume EGOS
'Control Device
Code' is the
'type' of control
device, not a
unique identifier.
ECOS specifies
the emission
factor to be in
SCC units. Unit
of Measure =
SCC Units
Issue Date: March?, 1997
Revision Date: April 11,1997
9-7
-------
Prototype Emission Modeling Implementation Guideline
EIIP
Entity
Emission
Process
Emission
Process
Emission
Process
Emission
Process
Emission
Process
Emission
Process
EIIP
Attribute
sec
Process SIC
AMS Code
Winter
Throughput
Percentage
Spring
Throughput
Percentage
Summer
Throughput
Percentage
X12 Data Element
Source Classification Code (SCC):
PID04 in detail level (pos. 345) if
HL03 = '6' and
Standard Industry Classification Code (SIC) code:
REF02 in detail level (pos. 371) if
HL03 = '6' and
REF01 in detail level = 'IJ'
AIRS Area and Mobile Sources (AMS) code:
PID04 in detail level (pos. 345) if
HL03 = '& and
PID02 in detail level = '12'
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate winter if
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 in CID loop = '721
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate spring if
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 in CID loop = 'ZZ'
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate summer if
Modeling
Attribute
Name
Emission
Factor
Source
Classification
Code
Source
Classification
Code
Standard
Industrial
Classification
Code
Standard
Industrial
Classification
Code
Area Source
Category
Code
Winter
Throughput %
Winter
Throughput %
Spring
Throughput %
Spring
Throughput %
Summer
Throughput %
Comments
Each pollutant-
specific control
efficiency has a
separate
instance in the
Emission Factor
entity. Unit of
Measure = Ibs/
activity unit of
measure.
Winter activity
may be reported
as a percentage
of the annual
activity.
Spring activity
may be reported
as a percentage
of the annual
activity.
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 in CID loop = 'ZZ'
9-8
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
BMP
Entity
Emission
Process
Emission
Process
Emission
Process
Emission
Process
Emission
Process
Emission
Process
Emission
Process
EIIP
Attribute
Fall
Throughput
Percentage
Hours Per Day
Days Per
Week
Weeks Per
Year
Heat Content
Sulfur Content
Ash Content
X1 2 Data Element
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate fall if
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 in CID loop = '22'
Operating schedule data:
STA03 (C00101) in CID loop (pos! 435) = 'HR' and
STA03 (C001004) in CID loop = 'DA' and
STA07 (C00105) in CID loop indicates '-1' if
HL03 = '6' and
CID04 in detail level = 'S' and
STA01 in CID loop = '30'
Operating schedule data:
STA03 (C00101) in CID loop (pos. 435) = 'DA' and
STA03 (C001004) in CID loop = 'WK' and
STA07 (C00105) in CID loop indicates '-1' if
HL03 = '6' and
CID04 in detail level = 'S' and
STA01 in CID loop = '30'
Operating schedule data:
STA03 (C00101) in CID loop (pos. 435) = 'WK1 and
STA03 (C001004) in CID loop = 'YR' if
STA07 (C00105) in CID loop indicates '-1' if
HL03 = '6' and
CID04 in detail level = 'S' and
STA01 in CID loop = '30'
Heat content:
STA02 in CID loop (pos. 435) if
HL03 = '6' and
CID04 in detail level = 'HC' and
STA01 in CID loop = '34'
Sulfur content:
STA02 in CID loop (pos. 435) if
HL03 = '6' and
CID04 in detail level = 'SC1 and
STA01 in CID loop = '34'
Ash content:
STA02 in CID loop (pos. 435) if
HL03 = '6' and
CID04 in detail level = 'AC' and
STA01 in CID loop = '34'
Modeling
Attribute
Name
Summer
Throughput %
Fall
Throughput %
Fall
Throughput %
Hours/day in
operation
Hours/day in
operation
Days/week in
operation
Days/week in
operation
Weeks/year
in operation
Weeks/year
in operation
Heat Content
Sulfur
Content
Ash Content
Comments
Summer activity
may be reported
as a percentage
of the annual
activity.
Fall activity may
be reported as a
percentage of
the annual
activity.
Issue Date: March?, 1997
Revision Date: April 11,1997
9-9
-------
Prototype Emission Modeling Implementation Guideline
EIIP
Entity
Emission
Release
Point
Emission
Unit/
Physical
Unit
Emission
Unit/
Physical
Unit
Emissions
Emissions
Emissions
EIIP
Attribute
Federal ID
Code
Federal ID
Code
Design
Capacity
Start
Date/Time
Pollutant Code
Numeric Value
X12 Data Element
Federal identifier code:
SPI03 in detail level (pos. 165) if
HL03 = '5' and
SPI02 in detail level = 'PE'
Federal identifier code:
SPI03 in detail level (pos. 165) if
HL03 = '5' and
SPI02 in detail level = 'PE'
Design capacity:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'VOL'
Activity (throughput) beginning date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
HL03 = 'C' and
DTM01 in LX loop = '196'
Note: Emissions holds a child relationship to the
Activity-level which contains these data.
CAS number/pollutant:
SPI03 in detail level (pos. 639) if
HL03 = '9' and
CID04 in detail level = 'ES'
Pollutant-specific estimated emissions data:
STA02 in CID loop (pos. 751) if
HL03 = '9' and
CID04 in detail level = 'ES'
Modeling
Attribute
Name
AIRS Stack
Number
AIRS Point ID
Boiler Design
Capacity
Year of
Inventory
SEROAD
Pollutant
Code
Average
Summer
Weekday
Emissions
Average
Summer
Weekday
Emissions
Annual
Emissions
Comments
NOTE: Found
in:
RDT04 (pos.
012) if
RDT03 = '196'
The DMC
discussed
SAROAD coding
and dropped it
from the data
model. A
Pollutant Code
will be used to
identify
pollutants in the
EIIP Data
Model. Each
pollutant
emission (Nox,
VOC, CO, S02,
PM-10)hasa
sEparate
instance in the
Emissions and
Emissions
Factors entities.
Unit of Measure
= tons/day
9-10
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP
Entity
Emissions
Geographic
Coordinates
Geographic
Coordinates
Geographic
Coordinates
Geographic
Location
EIIP
Attribute
Method Code
UTM Zone
X Coordinate
Y Coordinate
State/Province/
Territory (FIPS)
X1 2 Data Element
Estimated emissions method code:
REF02 in STA loop (pos. 755) if
HL03 = '9' and
CID04 in detail level = 'ES' and
REF01 in STA loop = 'C3'
Universal transverse mercator - zone:
REF04 (C04006) in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '05' and
REF04 (C04005) in LX loop = 'XW
Latitude:
REF04 (C04004) in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '05' and
REF04 (C04003) in LX loop = 'LQ'
Longitude:
REF04 (C04002) in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '05' and
REF04 (C04001) in LX loop = 'LK'
State or province:
N402 in header level (pos. 054)
Modeling
Attribute
Name
Annual
Emissions
Peak or Hot
Summer Day
Emissions
Peak or Hot
Summer Day
Emissions
Average
Summer
Weekday
Emissions
Average
Summer
Weekday
Emissions
Estimation
Method
UTM Zone
Longitude or
UTM Easting
Latitude or
UTM Northing
State FIPS
Code
State FIPS
Code
State FIPS
Code
Comments
Unit of Measure
= tons/year
Unit of Measure
= Maximum
Each day and
pollutant
emission have
separate
instances in the
Emissions
entity. Unit of
Measure =
tons/day
Issue Date: March?, 1997
Revision Date: April 11, 1997
9-11
-------
Prototype Emission Modeling Implementation Guideline
EIIP
Entity
Geographic
Location
Geographic
Location
Process
Growth
Factors
Process
Growth
Factors
Process
Growth
Factors
Process
Growth
Factors
Process
Growth
Factors
Site/Source
Site/Source
Site/Source
EIIP
Attribute
County/Parish/
Reservation
/cipc\
\r\t~s)
Municipality
Initial Year
Projected Year
Growth Factor
Growth Factor
Reference
Growth Factor
Units
Site Name
Physical
Address
SIC
X12 Data Element
County/parish code:
REF02 in header level N1 loop (pos. 057) if
Municipality:
N 102 in header level (pos. 045) if
N 101 in header level = 'C6'
Process growth factors start year:
DTM07 in LX loop (pos. 393) if
HL03 = '6' and
DTM01 in LX loop = '196' and
DTM06 in LX loop = 'CY'
Process growth factors projected action end date:
DTM07 in LX loop (pos. 393) if
HL03 = '6' and
DTM01 in LX loop = '575' and
DTM06 in LX loop = 'CY'
Process growth factor data:
MEA03 in LX loop (pos. 387) if
HL03 = '6' and
MEA01 in LX loop = 'AG' and
Process growth factor reference text:
REF03 in LX loop (pos. 395) if
HL03 = '6' and
REF01 in LX loop = 'ZZ'
Process growth factor data:
MEA04 (C00101) in LX loop (pos. 387) if
HL03 = '6' and
MEA01 in LX loop = 'AG'
Name:
N102 in SPI loop (pos. 019) if
HL03 = '4' and
N101 in SPI loop = 7C'
Address information:
N301 in header level (pos. 051) and
N302 in header level if
HL03 = '4' and
N101 in SPI loop = 7C' and
N 103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 7C'
Standard Industry Classification (SIC) code:
REF02 in detail level (pos. 055) if
HL03 = '4' and
REF01 in detail level = 'IJ'
Modeling
Attribute
Name
County FIPS
Code
County FIPS
Code
County FIPS
Code
City FIPS
Code
Annual
Average
Growth Rate
(%)
Annual
Average
Growth Rate
(%)
Annual
Average
Growth Rate
(%)
Origin of
Growth Rate
Annual
Average
Growth Rate
(%)
Plant Name
Plant Street
Address
Standard
Industrial
Classification
Code
Comments
(BEA, EGAS, .
Local, etc.)
9-12
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP
Entity
Site/Source
Site/Source
Stack
Physical
Parameter
Stack
Physical
Parameter
Stack
Physical
Parameter
Stack
Physical
Parameter
Stack
Physical
Parameter
Stack
Physical
Parameter
Attribute
Federal ID
Code
Physical Zip
Code
Stack Height
Stack Diameter
Exit Gas
Temperature
Exit Gas
Velocity
Exit Gas Flow
Rate
Plume Height
X12 Data Element
Federal key identifier code:
SPI03 in detail level (pos. 007) if
HL03 = '4' and
SPI02 in detail level = 'IJ'
Postal code:
N403 in header level (pos. 054) if
HL03 = '4' and
N101 in SPI loop = '7C' and
N 103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N 103 in header level = '93' and
N101 in header level = 7C'
Height above ground:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = '5F'
Inside diameter:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'ID'
Exit gas temperature:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = TE'
Exit gas velocity:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'ZZZ'
Flow rate:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'FR'
Plume height data:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'BA'
Modeling
Attribute
Name
AIRS Plant ID
The actual,
physical ZIP
code of the
source
Stack Height
Stack
Diameter
Stack Exit
Temperature
Stack Exit
Velocity
Stack Exit
Flow Rate
Plume Height
Comments
9.5 EIIP Code Tables Contained in the EIIP XI2 841 Convention Document
There are three types of code lists employed in the EIIP X12 841 Convention Document. There
are codes that are used as data element qualifiers. These codes are part of and defined by
ANSI/ASC X12. The code values have been developed for use with all ANSI/ASC X12
standards and are maintained by the committee.
Issue Date: March 7, 1997
Revision Date: April 11, 1997
9-13
-------
Prototype Emission Modeling Implementation Guideline
The second type of code list consists of those codes that are used by the EIIP by reference (e.g.,
Standard Industry Classification (SIC) code, Dun & Bradstreet number, Chemical Abstract
Service (CAS) Registry Number, etc.). These codes are used by the air emission programs
implementing the Convention Document, but are maintained by a specific outside organization
(not ANSI/ASC X12). Therefore, the values for these codes would be obtained from the
responsible organizations.
The final type of code list, the type contained in this table, are those that are developed by the
EIIP and are physically contained in the Convention Document. These are codes are not related
to the ANSI/ASC XI2 standards and are not administered by outside organizations. They are
identified and used to meet specific air emission inventory/modeling needs. These codes are
maintained by, and can be obtained from, the EIIP.
This table presents the EIIP code lists as they are used in the Convention Document. Within the
ANSI/ASC XI2 standards, each code (identified as "ID") has a preceding qualifier. This
qualifier indicates the type/source of the code. For example, the source type of Point Source
(code 01) is qualified by Source Type (code 06). Both the code and its related qualifier are
detailed in this table. Additionally, the data element number, as specified in the standard, and the
position location are included to ensure accurate reference. As the other types of codes are
administered by other organizations and clearly referenced within the Convention Document,
they are not detailed in this table.
Note: Code IDs indicated in parentheses are the values found in this version of the Convention
Document that must be changed due to conflict with other code values. The Code IDs preceding
them, although not found in the document, should be applied in their place
EIIP Code Tables Contained in the EIIP X12 841 Convention Document
Position
Reference
header - 009
header - 009
Qualifier
Element
128
128
Qualifier
ID
17
17
Data
Element
127
791
Code
ID
01
02
03
EMIS
EPA
EPARFP
EPASIP
Code Definition
Level 1 (EIIP Phase 1)
Level 2 (EIIP Phase II)
Level 3 (EIIP Phase III)
Annual stationary major source
inventory data submittal
USEPA required data submittal
Reasonable Further Progress(RFP)
inventory data
Base year State Implementation
Plan(SlP) inventory data submittal
9-14
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
header - 054
header - 057
detail - 055
detail - 055
Qualifier
Element
309
128
128
128
Qualifier
ID
RG
6E
06
T7
Data
Element
310
127
127
127
Code
ID
LOG
NON
PLAN
REGION
SPEC
SUBNON
SUPER
03MOD
03OTR
CO
03EXT
03MAR
03SER
03SEV1
03SEV2
03UNC
PM10
PM25
01
02
03
04
01
02
03
04
05
GEO
LIGHT
Code Definition
Data submittal between local and state
agency
Nonattainment modeling data submittal
Planning inventory (e.g., seasonal) data
submittal
Regional area modeling data submittal
Special data submittal
Sub-nonattainment area modeling data
submittal
Super-regional area modeling data
submittal
Ozone Moderate
Ozone Transport Region
Carbon Monoxide
Ozone extreme
Ozone marginal
Ozone serious
Ozone severe 1
Ozone severe 2
Ozone unclassified
Particulate Matter 10
Particulate Matter 2.5
Static Grid
Line
Point
Polygon
Point Source
Area Source
Mobile Source
Biogenic Source
Nonroad Engines and Vehicles Source
Geogenic
Lightning
Issue Date: March 7, 1997
Revision Date: April 11, 1997
9-15
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 079
detail -093
detail -187
detail - 225
Qualifier
Element
128
559
750
235
Qualifier
ID
6E
EP
PP
ZZ
Data
Element
127
751
751
234
Code
ID
SOIL
VEG
05
06
MONO
OVOC
VOC
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
CO
HC
ISO
MONO
NMHC
NMOC
NMOG
NO
Code Definition
Soil
Vegetation
)ynamic Grid
Projection System Name
Monoterpines
Other Volatile Organic Compounds
Volatile Organic Compounds
Stack
Control Unit
Emission Unit
Storage Tank
Vehicle Group
Process
Flare
Equipment Leak Fugitives
Loading
Cooling Towers
Incinerators
Accidental Release/Upset
Start up/Shut Down
Wastewater
Area
Other
Carbon monoxide
Hydrocarbons
Isoprene
Monoterpines
Nonmethane hydrocarbons
Nonmethane organic compounds
Nonmethane organic gases
Nitric oxide
9-16
Issue Date: March 7, 1997
Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 237
detail - 409
detail - 439
and
detail - 597
Qualifier
Element
128
559
128
Qualifier
ID
zz
EP
72
Data
Element
127
751
127
Code
ID
NOX
NOY
OVOC
PB
PM
PM10
PM25
ROG
SOX
TOG
VOC
A
B
C
D
E
F
AC
HC
OF (A)
OS (S)
SC
T
01
02
03
04
05
06
Code Definition
Nitrogen oxides
Nitrogen oxides plus secondary
compounds
Other volatile organic compounds
Lead
Particulate matter
Particulate matter >= 10
Particulate matter >= 2.5
Reactive organic gases
Sulfer oxides
Total organic gases
Volitile organic compounds
Operating
Under Construction
Under Modification
Mothballed
Closed - Dismantled/Removed From
Site
Closed - Remaining On Site
Ash Content
Heat Content
Seasonal Operating Adjustment Factor
Operating Schedule
Sulfer Content
Maximum Actual Throughput
Ozone Season
Peak Ozone Season
CO Season
Peak CO Season
Particulate Matter Season
Modeling Episode
Issue Date: March 7, 1997
Revision Date: April 11, 1997
9-17
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 439
and
detail - 553
Qualifier
Element
128
Qualifier
ID
PG
Data
Element
127
Code
ID
ABR
ABSP
ACEAL
ACID
ACIDFN
ACIDPR
ACRNL
ACROL
ADH
ADN
ADPN
AGNT
ALLY
ALMA
ALMO
AMM
ANILN
ASB
ASP
ASPSL
BATT
BAUX
BEAN
BEANGR
BEETRW
BNZN
BOD
BORD
BRED
BRIK
Code Definition
Abrasive
ABS Polymer
Acetaldehyde
Acid
Acid Final
Acid Pure
Acrylonitrile
Acrolein
Adhesive
ADN
Adipronitrile
Agent
Alloy
Alumina
Aluminum Molten
Ammonia
Aniline
Asbestos
Asphalt
Asphalt Shingle
Batteries
Bauxite
Beans
Beans Green
Beets Raw
Benzene
Bodies
Board
Bread
Brick
9-18
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
BUTDN
BUTDN13
CAD
CAN
CAPLM
CAR
CARTOT
CAST
CATL
CBLK
CC14
CEM
CFC133
CHAR
CHRMORE
CHXN
CIG
CL
CLAY
CLBNZ
CLFRM
CLMET
CLNK
CLOT
COAL
COALSTG
COAT
COKE
COKEFR
COKERW
CON
Code Definition
Butadiene
1.3-Butadiene
Cadmium
Cans
Caprolactam
Car(s)
Cargo Total
Castings
Catalyst
Carbon Black
CC14
Cement
CFC-133
Charcoal
Chromite Ore
Cyclohexene
Cigarettes
Chlorine
Clay
Chlorobenzene(s)
Chloroform
Chloromethane(s)
Clinker
Clothes
Coal
Coal Storage
Coating
Coke
Coke Free
Coke Raw
Concrete
Issue Date: March 7, 1997
Revision Date: April 11, 1997
9-19
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
COPLY
CORE
COREOL
COTT
COW
CTET
CU
CULL
CUM
CURR
CUSC
DBZF
DCS
DCE
DIST
DMF
DMTP
DRAN
DRUM
EAFDT
EDC
EDCVC
ELEC
ELECRD
ENER
EPCH
ETCSOL
ETH
ETHBNZ
ETHBST
ETHCL
Code Definition
Copolymer
Cores
Core Oil
Cotton
Cattle
Carbon Tetrachloride
Copper
Gullet
Cumene
Current
Copper Scrap
Dibenzofuran
1 ,4-Dichlorobenzene
1 ,2-Dichloroethane
Distance
DMF
Dimethyl Terephthalate
Drains
Drums
EFA Dust
EDC
EDC-VC
Electricity
Electrode
Energy
Epichlorohydrin
Etching Solution
Ethylene
Ethylbenzene
Ethylbenzene/Styrene
Ethyl Chloride
9-20
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
ETHDB
ETHDC
ETHOX
EXP
EXTFC
FABR
FDNHCO
FEED
FEEDDR
FEEDFR
FEEDMT
FELTST
PERT
FIBR
FISH
FISHML
FISHRW
FISHSC
FLC1112
FLC22
FLSP
FORM
FORM37
FRMGS
FRSH
FUEL
GAS
GLSS
GLSSBD
GLYET
GRAD
Code Definition
Ethylene Dibromide
Ethylene Dichloride
Ethylene Oxide
Exposed
Extractor Feed Cake
Fabric
Feed NaHCO3 Dry
Feed
Feed Dry
Feed Fresh
Feed Material
Felt Saturated
Fertilizer
Fiber
Fish
Fish Meal
Fish Raw
Fish Scrap
Florocarbon 11/12
Florocarbon 22
Fluorspar
Formaldehyde
37% Formaldehyde
Ferromanganese
Fresh
Fuel
Gas
Glass
Glass Beaded
Glycol Ethers
Graders
Issue Date: March 7, 1997
Revision Date: April 11, 1997
9-21
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
GRIT
CRN
GYPCR
HAMB
HCL
HEATIN
HXCBNZ
HYC
INK
IRON
LAB
LEAD
LEADOX
LIME
LIMHYD
LIMSTN
LOG
MAIL
MATLRW
MCBNZ
MEAL
MEAT
MERC
METL
METLHT
METLSPR
MLCAHD,
MTHCFRM
MTHCHL
MTHCLFR
NAPT
Code Definition
Grit
Grain
Gypsum Crude
Hamburger
Hydrochloric Acid
Heat Input
Hexachlorobenzene
Hydrocarbons Total
Ink
Iron
LAB
Lead
Lead Oxide
Lime
Lime Hydrated
Limestone
Logs
Material
Material Raw
Monochlorobenzene
Meal
Meat
Mercury
Metal
Metal Hot
Metal Sprayed
Meleic Anhydride
Methyl Chloroform
Methylene Chloride
Methylene Chloride Fresh
Naphthalene
9-22
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
NEOP
NICK
NITELST
NTRBZN
OCRSL
OIL
ORE
OREGON
OVRBUR
P205
PAINT
PAPR
PCB
PCE
PCECC
PCETCE
PCETH
PCETHFR
PCPHNL
PELLT
PEST
PHNL
PHSGN
PHSPH
PHSPHRK
PHSPRS
PIGIRN
PIGMNT
PILE
PIPE
PIPECST
Code Definition
Neoprene
Nickel
Nitrile Elastomer
Nitrobenzene
O-Cresol
Oil
Ore
Ore Concentrated
Overburden
P205
Paint
Paper
PCB
PCE
PCE & CC14
PCE & TCE
Perchloroethlyene
Perchloroethlyene Fresh
Pentachlorophenol
Pellets
Pesticide
Phenol
Phosgene
Phosphate
Phosphate Rock
Phosphorous
Pig Iron
Pigment
Pile
Pipe
Pipe Cast
Issue Date: March?, 1997
Revision Date: April 11,1997
9-23
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
PLCANHD
PLSTC
PLYWD38
PM
POLVNL
POLY
POM
PROD
PRODDR
PRODFN
PRODSA
PRPLYN
PULP
PULPABD
PULPADU
RAYN
REF
RESD
RESN
RESNPA
RESNTN
ROCK
SALT
SAND
SAWDST
SBR
SCMNGS
SCRP
SCRPRS
SEAL
SHOT
Code Definition
Phthalic Anhydride
Plastic
Plywood 3/8 Inch
PM
Polyvinal
Polymer
POM
Product
Product Dry
Product Finished
Product Surface Area
Proplyene
Pulp
Pulp Air-Dried Bleached
Pulp Air-Dried Unbleached
Rayon
Refinery
Residues/Skimmings
Resin
Resin Polyester/Alkyd
Resin Thinned
Rock
Salt
Sand
Sawdust
SBR
Silicomanganese
Scrap
Scrapers
Seals
Shot
9-24
Issue Date: March?, 1997
Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
SINT
SLAG
SLBLKL
SLDG
SLDGDR
SOLNCT
SOLNFRM
SOLV
SOLVCT
SOLVFR
SOLVIN
SOLVMU
SOLVRC
SOLVTN
SOUR
STEL
STELSP
STM
STON
STOR
STRCH
STYR
SULF
SULFAC
SUMP
SURF
TCB2N
TECLN
TECLNFR
TCEN
TDI
Code Definition
Sinter
Slag
Solids Black Liquor
Sludge
Sludge Dried
Solution Coating
Solution 37% Formaldehyde
Solvent
Solvent Coating
Solvent Fresh
Solvent in Ink
Solvent Make-Up
Solvent Reclaimed
Solvent Thinned
Sour Gas
Steel
Steel Specialty
Steam
Stone
Storage
Starch
Styrene
Sulfer100%
Sulfuric Acid
Sump
Surface
1 ,2,4-Trichlorobenzene
Trichloroethylene
Trichloroethylene Fresh
1,1,1-Trichlorothane
TDI
Issue Date: March 7, 1997
Revision Date: April 11, 1997
9-25
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 439
and
detail - 553
Qualifier
Element
128
Qualifier
ID
su
Data
Element
•
127
Code
ID
TETHLD
TIRE
TNT
TOLN
TONE
TOPSL
TPLCAC
TRCKHL
UREA
VAC
VEHCL
VNLC
VNLCM
VNLDC
WATCO
WAX
WFR
WFRBRD
WOOD
WOODDF
WOODDR
WSTE
WSTWTR
XLN
XLNM
XLNO
XLNT
ZINC
ZINCOX
ADD
Code Definition
Tetraethyl Lead
Tires
TNT
Toluene
Toner
Topsoil
Terephthalic Acid Crude
Trucks Haul
Urea
Vacuum
Vehicles Light/Medium
Vinyl Chloride
Vinyl Chloride Monomer
Vinyldiene Chloride
Water Cooling
Wax
Wafers/Chips
Waferboard
Wood
Wood Dry Flakes
Wood Dried
Waste
Wastewater
Xylene(s)
m-Xylene
o-Xylene
Xylene(s) Total
Zinc
Zinc Oxide
Added
9-26
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
APPL
AREA
BAKE
BLOW
BURN
CAP
CAST
CHAR
CHRG
CLND
COAT
CONS
CRSH
DGRS
DRIL
DRY
EMIT
FEDD
FEED
GIN
GRAN
HAND
IAD
ICT
IINF
IINK
INOC
INPT
IOPP
LEAK
LIQK
Code Definition
Applied
Area
Baked
Blown
Burned
Capicity
Cast
Charbroiled
Charge(d)
Cleaned
Coated
Consumed
Crushed
Degreased
Drilled
Dried
Emitted
Fed into Dryer
Feed
Ginned
Granulated
Handled
In Adhesive Applied
In Coating
In Influent
In Ink
Inoculated
Input
In Operation
Leaked
Liquified
Issue Date: March?, 1997
Revision Date: April 11, 1997
9-27
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
Qualifier
Element
Qualifier
ID
Data
Element
Code
ID
LOAD
MELT
MILL
MINE
MIX
OPRG
PICK
PLAT
PRDT
PROC
PROD
PRODCAP
PUMP
RECD
REDD
REMD
ROAS
SAW
SHIP
SHPRCD
SMOK
SPUN
STOR
STRP
TRFD
THRU
TPRT
TRAV
TRTD
UNLD
USED
Code Definition
Loaded
Melted
Milled
Mined
Mixed
Operating
Picked
Plated
Product
Processed
Produced
Production Capacity
Pumped
Received
Reduced
Removed
Roasted
Sawed
Shipped
Shipped or Received
Smoked
Spun
Storage
Stripped
Transferred
Throughput
Transported
Traveled
Treated
Unloaded
Used
9-28
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 553
detail - 567
detail - 595
Qualifier
Element
128
559
1250
Qualifier
ID
IX
EP
UN
Data
Element
127
751
1251
Code
ID
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
AF (A)
AS (S)
M
01
02
03
04
05
06
07
Code Definition
Calculated based on physical principles
Estimated based on expert judgement
Calculated based on manufacturer-
specified throughput capacity
Calculated based on direct continuous
measurement of an activity surrogate
Calculated based on direct intermittent
measurement of an activity
New construction, not yet operational.
Emissions are zero.
Operations ceased. Emissions are zero.
Calculated based on modeling activity
Derived from Highway Performance
Monitoring System (HPMS) data
Derived from census data
Derived from trade association/industry
group data
State agency generated data
Local agency generated data
Federal agency generated data
Proprietary database
Based on survey results
Calculated based on statistical method
Season Adjustment (Throughput)
Adjustment Factor
Activity (Throughput) Schedule
Meteorological
Issue Date: March 7, 1997
Revision Date: April 11,1997
9-29
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 639
detail - 661
detail - 725
detail - 729
detail - 745
Qualifier
Element
128
559
559
559
128
Qualifier
ID
9
EP
EP
EP
ZZ
Data
Element
127
751
751
751
127
Code
ID
CO
HC
SO
MONO
NMHC
NMOC
NMOG
NO
NOX
NOY
OVOC
PB
PM
PM10
PM25
ROG
SOX
TOG
VOC
04
05
06
CE
EF
ES
C
U
AA (A)
CC (C)
DD (D)
Code Definition
Carbon Monoxide
Hydrocarbons
soprene
Monoterpines
Nonmethane hydrocarbons
Nonmethane organic compounds
Monmethane organic gases
Citric oxide
Nitrogen oxides
Nitrogen oxides plus secondary
compounds
Other volatile organic compounds
Lead
Particulate matter
Particulate matter >= 1 0
Particulate matter >= 2.5
Reactive organic gases
Sulfer oxides
Total organic gases
Volatile organic compounds
Site/Source
Physical
Process
Aggregate Control Information
Emission Factor
Estimated Emissions
Controlled
Uncontrolled
Area Source Questionnaire
Direct Calculation of emissions by
solvent use, all solvents emitted in time
period
80% - Default value
9-30
Issue Date: March 7, 1997
Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 745
and
detail - 755
detail - 755
Qualifier
Element
128
128
Qualifier
ID
C3
6E
Data
Element
127
127
Code
ID
EE (E)
HH (H)
LL (L)
MM (M)
NN (N)
PP (P)
SS (S)
UU (U)
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
Code Definition
Source in compliance due to irreversible
process that eliminates solvent use
90% - Default - enhance monitoring
Local category-specific rule
effectiveness factor - not USEPA
regulated
Continuous emission factor
Source not subject to regulation
Point Source Questionnaire
USEPA Single Source Category
Determination Protocol Study
Uncontrolled emission
Calculated based on source test or other
emission measurement
Calculated based on material balance
using engineering knowledge of the
process
Calculated based on best
guess/engineering judgement
Calculated based on vendor emission
factor specification
Calculated based on ratio in order to
measure pollutant
Calculated based on pilot bench study
State Stack Test
State Material Balance
State Efficiency of Control Device
Company Material Balance
Company Efficiency of Control Device
Continuous Emission Monitoring
Calculated based on AP-42 emission
factor
Calculated based on state/local
emission factor
New construction, not yet operational -
emissions are zero
Operations ceased - emissions are zero
Issue Date: March 7, 1997
Revision Date: April 11, 1997
9-31
-------
Prototype Emission Modeling Implementation Guideline
Position
Reference
detail - 755
Qualifier
Element
128
Qualifier
ID
DO
Data
Element
127
Code
ID
17
18
19
20
21
22
23
24
25
26
27
28
A
B
C
D
E
F
Code Definition
Calculated based on FIRE emission
factor
Calculated based on user-supplied
emission factor
Calculated based on USEPA
specification factor
Calculated based on state/local
Specification factor
Calculated based on trade association
emission factor
CO Stack Test Approved by State
Other CO Stack Test Approved by State
State Factor Used by State
State VOC Calculation
Company SCC Factor
Company VOC Calculation
Other miscellaneous emission method
code
AIRS Rating A
AIRS Rating B
AIRS Rating C
AIRS Rating D
AIRS Rating E
AIRS Rating F
9-32
Issue Date: March 7, 1997
Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
SECTION 10 — AGENCY CONVENTIONS, INTERCHANGE CONTROL &
TRANSACTION SETS
10.1 Introduction
Section 10 contains the descriptions of the information used in the Interchange Header (ISA),
Interchange Trailer (IEA), Group Start (GS), Group End (GE), and the control segments.
To help understand how the standards work, it is useful to begin by defining some terminology
and explaining some of the components that make electronic communications possible. It is
important to note that in the transaction set implementation guidelines all text shown in italics is
an EIIP convention. Non-italicized text contain definitions and comments directly from the XI2
standards.
A "transaction set" is the term used in business data interchange to describe the electronic
transmission of a single document (purchase order, Emission Statement, shipping notice, etc.)
between one organization's computer and the computer of the other trading partner. The data
included in a transaction set conveys the same information as a conventional printed document.
A transaction set generally but not always, consists of three areas - Header or Table 1, Detail or
Table 2, and a Summary or Table 3. The Header Area contains information that is of an
administrative nature and pertains to the entire document (document dates, identities, names of
contacts, etc.). The Detail Area is used to convey the actual business transaction such as
quantities, prices, items. Data in the Detail Area overrides equivalent Header Area data (i.e. if a
contact is specified in the Header and another contact is specified with a single item, the second
contact takes priority). The Summary Area contains control information and may contain other
data that relates to the entire transaction.
Transaction sets are a collection of a series of segments. A segment is a group of data used to
convey a logical grouping of data. The data within a segment are contained within data
elements.
Please note that in the design of Composite Data Elements, sub-elements are still referred to as
elements.
EDI transmissions are created from information extracted from internal information systems,
translated into ASC XI2 format and punctuated with control characters. Quantity, unit of
measure, unit price, catalogue number is typical purchase order or invoice information. In an
invoice transaction the information becomes a segment of five data elements grouped in a
specific sequence as follows:
Issue Date: March 7, 1997
Revision Date: April 11,1997 10-1
-------
Prototype Emission Modeling Implementation Guideline
ITl**Quantity*Unit of Measure Code*Unit Price** Product
Service Qualifier*Product/Service Identification N/L
The ANSI/ASC X12 format requires each element be separated by an element separator and the
last element be followed by a segment terminator. Graphic representations of the control
characters usually use the asterisk as a element separator, N/L as the segment terminator and a
colon(:) as a sub-element separator.
The segment in an actual transmission would appear as:
IT1**1*CA*1.08**CT*141151 N/L
In the ANSI/ASC X12 code list "CA" is the unit of measure code for case, and "CT is the
product identification qualifier for carton.
The following list identifies terms associated with data segments and provides references to
codes and terms used in the XI2 standard. The actual transmission does not include all of the
listed items as only the segment identifier characters, the values for each data element, the data
element separators and the segment terminator characters are transmitted.
Segment Identifier, Two or three characters assigned to identify the segment. The identifier
occupies the first character positions of the segment.
Data Element Reference Number, A number assigned to the data element to provide a
reference to the ASC XI2 Data Dictionary which defines specifications for each data element.
Data Element Reference Designator, A structured code assigned to each data element in a
segment to indicate its unique position in the segment. It is composed of the segment identifier
and its sequential position within the segment.
Data Element Name, This is the name assigned to the data element in the ASC XI2 Data
Dictionary.
Attributes, Each data element has three ASC XI2 attributes: element usage or Condition
Designator, data element type, and Minimum/Maximum length.
Condition Designator
M - Mandatory
The element is required to appear in the segment.
O - Optional
Issue Date: March?, 1997
10-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Appearance of the data element is at the option of the sending party or is based on
the mutual agreement of the trading partners.
X - Relational
Condition that may exist between two or more data elements based on the
presence or absence of one of the data elements. Additional codes are used to
identify the condition i.e. P - Paired or Multiple, R - Required, E - Exclusion, C -
Conditional, or L - list Conditional. Refer to the X12 Standards Manual,
Introduction to X12.22 Segment Directory.
Data Element Type
ID Identifier
The data element must always contain a value from a predefined list of values that
is maintained by XI2 or by other bodies that are recognized by XI2 and identified
by reference in Appendix A in the Data Element Dictionary. The value is left
justified. Trailing spaces should be suppressed.
AN String
Alpha-numeric sequence of characters containing at least one non-space character.
The significant characters must be left justified. Leading spaces, if used are
assumed to be significant characters. Trailing spaces should be suppressed.
FS Fixed Length String
A sequence of any letters, spaces, and/or special characters with spaces filled, if
necessary, to satisfy minimum length.
DT Date
The format is YYMMDD where YY is the Year, MM is the month and DD is the
day of the month.
TM Time
Values for a time-type data element are in the HHMMSSd..d format expressed
using the 24-hour clock. HH expresses the hour (00-23), MM expresses the
minute (00-59), SS the seconds (00-59), and d..d is the numeric expression of
decimal seconds.
Issue Date: March?, 1997
Revision Date: April 11,1997 • 10-3
-------
Prototype Emission Modeling Implementation Guideline
Nn Numeric
Numeric data element where N indicates a numeric and "n" indicates the decimal
places to the right of a fixed, implied decimal point. The decimal point is not
transmitted in the character stream. If the max length of the data element was five
position and the Type was N2, the values sent would always have two decimal
positions; an NO would contain no decimal positions.
R Decimal
A numeric data element where the decimal point is optional for integer values, but
required for fractional values. Leading zeros should be suppressed unless
necessary to satisfy a minimum length requirement. The decimal point and the
minus sign when transmitted are not counted when determining the length of the
data element value. If the max length of the data element was three positions, the
following represent the values that could be sent: NNN, .NNN, N.NN, NN.N, -
N.NN, etc.
B Binary
Any sequence of octets ranging in value from binary 00000000 to
binary 11111111. Binary may only exist in the BIN Segment.
Minimum/Maximum, This is the range, minimum to maximum, of the number of character
positions available to represent the data element value. It may be of variable length with a
minimum to maximum, or it may be of fixed length in which the minimum is equal to the
maximum.
10.2 XI2 EDI Transmission Control Structure
The XI2 Transmission is a hierarchical structure of headers and trailers to allow transaction sets
of different types to be transmitted in the same transmission and allows the data to be separated
or segregated logically for easy interpretation and internal routing by the receiver.
Transaction sets begin with an ST segment and end with an SE segment. Multiple transaction
sets of the same functional group are transmitted together beginning such a group with a GS
(Group Start) and ending with a GE (Group End) segment. One or more functional groups are
bound together for transmission within an interchange envelope that starts with an ISA segment
and ends with an IEA segment. There are other segments available for Security and Interconnect
control when using the services of third party communications providers (e.g., VAN).
The interchange control structure is the interchange envelope consisting of a Header (ISA) and a
Trailer (IEA) for the electronic interchange through a data transmission, and provides a structure
to acknowledge the receipt and processing of the envelope.
Issue Date: March 7, 1997
10-4 Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
The ISA and the IEA envelope one or more functional groups or interchange-related control
segments and perform the following functions:
• Define the segment terminator, and the element and sub-element separators;
• Identify the sender and receiver;
• Provide control information for the interchange; and
• Allow for authorization and security information.
The GS and GE envelope transactions sets of the same type. Each type of transaction is
contained in a separate Functional Group to allow the receiver to parse the information to the
appropriate application. The GS segment provides the identity of the Version and Release of the
standard used to create the transaction. Both the GS and the GE provide control information to
ensure the validity of the interchange.
Every transaction set begins with an ST (Transaction Start) segment and is ended with a GE
(Group End) segment.
Translators normally strip off the ISA/IEA and GS/GE segments during translation. It is the
responsibility of the trading partners to make provisions to archive the transmissions before and
after translation to satisfy EDI Audit Requirements.
The structures of the transaction set and functional group headers and trailers are found in the
Segment Directory. The structures of the interchange control header and trailer are found in the
Interchange Control Structure Standard (ANSI/ASC X12.5-1989).
See the following EDI Transmission schematic. The schematic illustrates a typical format for
electronically transmitting a series of diverse business transactions.
Issue Date: March 7, 1997 ~ ~
Revision Date: April 11, 1997 - jQ-5
-------
Prototype Emission Modeling Implementation Guideline
Schematic of an EDI Transmission
/Communications Transport Protocol
ISA ,
GS -
ST
SE
ST
SE
GE
GS
ST
SE
GE
IEA
/ Interchange Control Header
/ Functional Group Header
/ Transaction Set Header
Detail Segments
(e.g. .Purchase Older)
\Transaction SetTrailer
/ Transaction Set Header
Detail Segments
(e.g.. Purchase Older)
^\ Transaction Set Trailer
\ Functional Group Trailer
FUNCTIONAL GROUP
/ Functional Group Header
/ Transaction Set Header
Detail Segments
^.g..Recehrhg Attvice)
\ Transaction Set Trailer
\y Functional Group Trailer
FUNCTIONAL GROUP
INTERCHANGE ENVELOPE
\. Inte ic ha nge Co ntiol Trailer
COMMUNICATIONS SESSION
^Communications Transport Protocol
EDI Transmission Structure
10-6
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
10.2.1 Control Segments
ICS Interchange Control Structures
Functional Group ID=
Introduction:
The purpose of this standard is to define the control structures for the electronic interchange of one or more encoded
business transactions including the EDI (Electronic Data Interchange) encoded transactions of Accredited Standards
Committee XI2. This standard provides the interchange envelope of a header and trailer for the electronic
interchange through a data transmission, and it provides a structure to acknowledge the receipt and processing of
this envelope.
Notes:
indicates an element not-used.
Not Used
Pos.
Nfi,
010
020
030
040
050
Seg.
m
ISA
TA1
GS
GE
IEA
Name
Interchange Control Header
Interchange Acknowledgment
Functional Group Header
Functional Group Trailer
Interchange Control Trailer
Req. Loop
Des. Max.Use Repeat
M 1
O 1
O 1
O 1
M 1
Notes and
Comments
Issue Date: March?, 1997
Revision Date: April 11,1997
10-7
-------
Prototype Emission Modeling Implementation Guideline
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Interchange Control Header
010
Mandatory
1
To start and identify an interchange of zero or more functional groups and interchange-
related control segments
Th& value of tb$ data.
TEA Ihat «otH|iktes &$ ttattssni^ioa &r» ^gwi^d friibs ISA> Byte 4* f<
bytes ibat eonjpfk«: to ISA* *3e&$H?a'to «f to ijeader* kused to se^iat^ Ib
»
doa f»«Je as«s the asterisk C
the s«b-«Je«ieGt: sepaiator fbrougfe iie «i«l of this ltAt "t
the <5ol&» (i) a$ Ike
The
segment tecmiwafeES jnestl* eitatact^cs. fljat wSMuofbe 4aife ^Isacactefs
Ace^pt^bfe c&wvtm,
*00%xxxsxx^^
Ref.
DCS.
ISA01
ISA02
Data
Element
101
102
Data Element Summary
Name Attributes
Authorization Information Qualifier M ID 2/2
Code to identify the type of information in the Authorization Information
00 No Authorization Information Present (No Meaningful
Information in 102)
03 Additional Data Identification
Authorization Information M AN 10/10
Information used for additional identification or authorization of the interchange
sender or the data in the interchange; the type of information is set by the
Authorization Information Qualifier (101)
10-8
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
» ISA03 103 Security Information Qualifier M ID 2/2
Code to identify the type of information in the Security Information
00 No Security Information Present (No Meaningful
Information in 104)
» ISA04 104 Security Information M AN 10/10
This is used for identifying the security information about the interchange sender
or the data in the interchange; the type of information is set by the Security
Information Qualifier (103)
t&is dementis I5x.«d leiigtk It ta«&t be space filled
» ISA05 105 Interchange ID Qualifier M ID 2/2
Qualifier to designate the system/method of code structure used to designate the
sender or receiver ID element being qualified
01 Duns (Dun & Bradstreet)
» ISA06 106 Interchange Sender ID M AN 15/15
Identification code published by the sender for other parties to use as the
receiver ID to route data to them; the sender always codes this value in the
sender ID element
» ISA07 105 Interchange ID Qualifier M ID 2/2
Qualifier to designate the system/method of code structure used to designate the
sender or receiver ID element being qualified
01 Duns (Dun & Bradstreet)
» ISA08 107 Interchange Receiver ID M AN 15/15
Identification code published by the receiver of the data; When sending, it is
used by the sender as their sending ID, thus other parties sending to them will
use this as a receiving ID to route data to them
» ISA09 108 Interchange Date M DT 6/6
Date of the interchange
» ISA10 109 Interchange Time M TM 4/4
Time of the interchange
» ISA11 110 Interchange Control Standards Identifier M ID 1/1
Code to identify the agency responsible for the control standard used by the
message that is enclosed by the interchange header and trailer
U U.S. EDI Community of ASC X12, TDCC, and UCS
» ISA12 111 Interchange Control Version Number M ID 5/5
This version number covers the interchange control segments
ISmt
00304
Draft Standard for Trial Use Approved for Publication by
ASC XI2 Procedures Review Board.
Issue Date: March 7, 1997
Revision Date: April 11,1997
10-9
-------
Prototype Emission Modeling Implementation Guideline
ISA13
112
ISA14
ISA15
113
114
ISA16
115
Interchange Control Number
A control number assigned by the interchange sender
M NO 9/9
Acknowledgment Requested M ID 1/1
Code sent by the sender to request an interchange acknowledgment (TA1)
1 Interchange Acknowledgment Requested
Test Indicator M ID 1/1
Code to indicate whether data enclosed by this interchange envelope is test or
production
P Production Data
T Test Data
Component Element Separator M AN 1/1
This field provides the delimiter used to separate component data elements
within a composite data structure; this value must be different than the data
element separator and the segment terminator
a
10-10
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
GS01
GS02
GS03
GS04
GS05
GS06
vJ>J Functional Group Header
030
Optional
1
To indicate the beginning of a functional group and to provide control information
Data Element Summary
Data
Element Name
Attributes
479
142
124
373
337
Functional Identifier Code M ID 2/2
Code identifying a group of application related transaction sets
FA Functional Acknowledgment (997)
SP Specifications/Technical Information (841)
Application Sender's Code M AN 2/15
Code identifying party sending transmission; codes agreed to by trading partners
Application Receiver's Code M AN 2/15
Code identifying party receiving transmission. Codes agreed to by trading
partners
Date M DT 6/6
Date (YYMMDD)
Date seadsr '$ trngnttftl 8 fuac$sr
-------
Prototype Emission Modeling Implementation Guideline
» GS07 455 Responsible Agency Code M ID '/2
Code used in conjunction with Data Element 480 to identify the issuer of the
standard
X Accredited Standards Committee X12
» GS08 480 Version / Release / Industry Identifier Code M AN 1/12
Code indicating the version, release, subrelease, and industry identifier of the
EDI standard being used, including the GS and GE segments; if code in DE455
in GS segment is X, then in DE 480 positions 1-3 are the version number;
positions 4-6 are the release and subrelease, level of the version; and positions 7-
12 are the industry or trade association identifiers (optionally assigned by user);
if code in DE455 in GS segment is T, then other formats are allowed
Tfcfc Sd$&ste #&# j&tito EJH> is; 0$20$>>
003060 Draft Standards Approved for Publication by ASC X12
Procedures Review Board
Issue Date: March 7, 1997
10-12 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Functional Group Trailer
040
Optional
1
To indicate the end of a functional group and to provide control information
Ref.
DCS.
Data
Element
Data Element Summary
Name
Attributes
GE01
GE02
97 Number of Transaction Sets Included M NO 1/6
Total number of transaction sets included in the functional group or interchange
(transmission) group terminated by the trailer containing this data element
28 Group Control Number M NO 1/9
Assigned number originated and maintained by the sender
Issue Date: March 7, 1997
Revision Date: April 11, 1997
10-13
-------
Prototype Emission Modeling Implementation Guideline
Segment:
Position:
Loop:
Level:
Interchange Control Trailer
050
Usage: Mandatory
Max Use:
1
Purpose: To define the end of an interchange of zero or more functional groups and interchange-
related control segments
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Data Element Summary
Ref.
Des.
IEA01
IEA02
Data
Element Name
Attributes
116 Number of Included Functional Groups M NO 1/5
A count of the number of functional groups included in an interchange
112 Interchange Control Number M NO 9/9
A control number assigned by the interchange sender
10-14
Issue Date: March 7,1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
APPENDIX A — GETTING STARTED WITH EDI
(Check List)
Issue Date: March?, 1997
Revision Date: April 11,1997 A-l
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March 7, 1997
A-2 Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
How To Get Started With
Electronic Data Interchange (EDI)
This is a check list for implementing EDI for the Emission Inventory Improvement Program EDI
prototype project. Although it is intended for use with the prototype efforts, the content is geared
toward a pilot environment. As a result some information provided may not be necessary for
prototype performance. EDI is the computer-to-computer (application-to-application)
interchange of pre-designated message types in standardized formats. The purpose of the EIIP
EDI prototype project is to address the task of electronically transferring air emission modeling
data between interested parties.
Check List for Prototype Participants
1. Startup
Contact the EIIP DMC to get materials and set up a schedule. Materials include the EIIP
EDI Implementation Guideline and information about EDI software.
2. Orientation Meeting/Communication
Meet/communicate with the EDI coordinator for an orientation of the project activities.
The meeting will give an overview of EDI and specific instructions on how to obtain and
use the materials provided.
3. Equipment S etup
To operate the EDI translator system being used for the prototype efforts (Supply Tech's
STX PC-based translation software), it is recommended that your microcomputer have
the following configuration:
80386 PC-compatible
16 or 20 MHZ processor
150 K conventional and 1.012 extended available RAM
60-80 Megabyte Hard Drive
PC-DOS or MS-DOS, version 3.3 or higher
EGA video adapter card with EGA monitor
Asynchronous or bisynchronous modem (if applied)
132-column printer
In addition, you must have access to a data line (if applied). Most EDI systems are stand-
alone, but the software may be configured to run on a Local Area Network (LAN) and
use LAN modems.
Issue Date: March 7, 1997
Revision Date: April 11,1997 - A-3
-------
Prototype Emission Modeling Implementation Guideline
4. Installation
Install software and test communication facilities (if applied). The EDI coordinator will
provide assistance if needed.
5. Test Transmissions
Enter and transmit several emission modeling transactions to assure that the process
works correctly.
6. Operations Mode
Once you are assured that the transmissions are reliable, begin to send real air emission
modeling data to your trading partner. The USEPA will maintain a database of air
emission modeling data. All regulatory reporting that is currently performed in a hard
copy format must continue as required..
7. Evaluation
Evaluate the effort for reliability, data accuracy and time savings.
Check List for USEPA Program Offices
1. Feasibility Analysis
Initial analysis is important to the success of the EDI implementation. The following
issues should be considered before starting the implementation.
• Funding
• Level of interest in the reporting community
• Regulatory language - determine legal applicability of electronic submission
• Information systems support - determine effort needed to manage emission
modeling data. Identify the applicable in-house applications and develop an
interface to the EDI translation software. If no system already exists, consider
building or buying software to manage the data.
2. Select Prototype Participants
Issue Date: March?, 1997
A-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Identify good candidates for prototype participation. The EDI coordinator can contact
them and introduce them to the prototype.
3. Set up EDI Hardware and Software
The EDI coordinator will provide and set up the EDI software, establish a communication
service (if applied), and provide technical support for the Program Office. This may
require some coordination with internal information systems. The Regional or State
Program Office should have access to a microcomputer, and become familiar with using
the EDI software.
4. EDI Orientation
Each prototype participant should attend an orientation meeting to introduce them to the
technology and give them specific instructions for using the prototype system. The EDI
coordinator will conduct the meeting.
5. Test Reception
The EDI coordinator will test your EDI system by receiving several emission modeling
transmissions from the same or another system. Transmissions must be received reliably
before the pilot participants start transmitting.
6. Organize Air Emission Modeling Data
Become familiar with a tool for managing emission modeling data. This is software
developed in-house, purchased, or provided by the EDI coordinator. Make sure you can
at least add, remove, find and view emission modeling records from the database.
7. Schedule Participants
The EDI coordinator will setup a schedule with the pilot participants. For each pilot
participant, schedule a time to:
• Do a test transmission
• Begin sending "live" transmissions
8. Receive Test Air Emission Modeling Data
The EDI coordinator will assist each prototype participant in setting up and testing their
EDI system. Once a prototype sight has EDI equipment set up and configured, they
Issue Date: March 7, 1997
Revision Date: April 11, 1997 • A-5
-------
Prototype Emission Modeling Implementation Guideline
should create several "dummy" transmissions and attempt to send them via EDI. At the
receiving end, these test transmissions can be received and verified.
9. Receive Operational Air Emission Modeling Data
Once a prototype participant's system is set up and tested, they may begin to send real
emission modeling data. At this point, it is unnecessary for both the trading partner and
States to be in contact during the routine transmissions.
10. Evaluation
Evaluate the process of electronic submission for reliability, data accuracy and time
savings.
Issue Date: March 7, 1997
A-6 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
APPENDIX B — EPA'S GENERIC TERMS AND CONDITIONS AGREEMENT
Issue Date: March?, 1997
Revision Date: April 11, 1997 B-l
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March 7, 1997
B-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
This appendix is the generic EPA Terms and Conditions Agreement for the use of EDI for
Environmental Reporting. It is an excerpt from the September 4, 1996 Federal Register Notice,
Volume 61, Number 172, FRL-5601-4.
Notice of Agency's General Policy for Accepting Filing of Environmental Reports
via Electronic Data Interchange (EDI)
AGENCY: Environmental Protection Agency.
ACTION: Interim final notice.
II. TEXT OF EPA GENERIC TERMS AND CONDITIONS AGREEMENTS MODEL
Scope:
Use of this generic Terms and Conditions Agreement (TCA) model applies when EPA requires
certification and/or authentication by the Submitter of a report. Where neither certification or
authentication is required but use of a TCA is desired by EPA, the Agency may modify this TCA
to eliminate unnecessary paragraphs. The model TCA is designed to promote consistency in
implementing EDI by Program Offices within the Agency.
Model:
EPA Generic Terms and Conditions Agreement (TCA) Model for Submission of Environmental
Reports via Electronic Data Interchange (EDI)
THIS ELECTRONIC DATA INTERCHANGE TERMS AND CONDITIONS AGREEMENT
(the "Agreement"), by and between the United States Environmental Protection Agency
("EPA"), 401 M St., SW, Washington, D.C., a federal governmental agency, and reporting party
("Submitter") who has signed and returned the Terms and Conditions Agreement (TCA)
Memorandum, included in today's notice referenced above, is effective on the date on which
EPA issues the initial PIN(s), in response to receipt and acceptance of Submitter's signed TCA
Memorandum. (When a program is not using a PIN system, some other determinant for the
effective date will be specified in the program-specific notice.) Or, in the case where PIN is not
required, as otherwise noted in the program-specific notice.
1. Recitals.
The intent of this agreement is to create legally binding obligations upon the parties using
EDI and to ensure that (a) use of any electronic functional equivalent of documents
referenced or exchanged under this agreement shall be deemed an acceptable practice in
the ordinary course of Submitter-to-EPA environmental reporting and (b) such electronic
Issue Date: March 7, 1997
Revision Date: April 11, 1997 . B-3
-------
Prototype Emission Modeling Implementation Guideline
records shall be admissible as evidence on the same basis as paper documents. The
parties intend to be legally bound by them.
2. Validity and Enforceability.
2.1 This Agreement has been executed by the parties to evidence their mutual intent to create
binding regulatory reporting documents using electronic transmission and receipt of such
records.
2.2 Any records properly communicated pursuant to this Agreement shall be considered to be
a "writing" or "in writing"; and any such records which contain or to which there is
affixed, a Signature, as defined by para. 6 of this Agreement, ("Signed Documents") shall
be deemed for all purposes (a) to have been "signed" and (b) to constitute an "original"
when printed from electronic files or records established and maintained in the normal
course of business.
2.3 The conduct of the parties pursuant to this Agreement, including the use of Signed
Records properly communicated pursuant to the Agreement, shall, for all legal purposes,
evidence a course of dealing and a course of performance accepted by the parties in
furtherance of this Agreement.
2.4 The Submitter agrees not to contest the validity or enforceability of Signed Documents
under the provisions of any applicable law relating to whether certain agreements are to
be in writing or signed by the party to be bound thereby. Signed Documents, if introduced
as evidence on paper in any judicial, arbitration, mediation or administrative proceedings,
will be admissible as between the parties to the same extent and under the same
conditions as other business records originated and maintained in documentary form.
Neither party shall contest the admissibility of copies of the Signed Documents under the
Federal Rules of Evidence as inadmissible or in violation of either the business records
exception of the rule on hearsay, or the best evidence rule, or on the basis that the Signed
Documents were not originated or maintained in documentary (paper) form.
3. Receipt.
A Document shall be deemed to have been properly received by EPA when it is
accessible to EPA, can be fully processed by the translator at EPA's Receipt Computer,
and is syntactically correct to applicable EDI standards. No Document shall satisfy any
reporting requirement or be of any legal effect until it is received.
4. Verification.
Issue Date: March 7, 1997
B-4 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Upon receipt of any Document, the receiving party shall promptly and properly transmit a
functional acknowledgment in return within "x" business day of receipt to verify that the
Document has been received. If a positive functional acknowledgment is not received in
return for a Document, the party initially transmitting the Document shall be responsible
for re-sending the Document. The number of days shall depend on specific program
needs and will be specified in the Program-Specific Notice or related documents (e.g.,
Implementation Guideline, TCA).
5. Date of Receipt.
EPA will consider an electronically filed report received when it can be fully processed
by the translator at the EPA's receipt computer, i.e., when the document is retrievable
from the electronic mailbox by EPA, syntactically conforms to applicable EDI standards,
and is able to be successfully translated by EPA. A positive functional acknowledgment
indicating no syntactical errors will constitute conclusive evidence that EPA has properly
received a report and will establish the "Received Date".
6. Re-transmission.
If the Submitter does not receive a functional acknowledgment promptly after its
transmission to the EPA, then the Submitter must re-send the document and follow any
recovery procedures stated in the applicable EPA EDI Implementation Guidelines.
"Promptly" shall be determined by each program-specific EDI application and defined in
the program-specific notice or related documents (e.g., Implementation Guideline, TCA).
The Submitter must retransmit any document within "X" days of receiving a
re-transmission request by EPA. Likewise, EPA will re-send any transmission originated
by EPA at the Submitter's request. The number of days shall depend on specific program
needs and will be specified in the Program-Specific Notice or related documents (e.g.,
Implementation Guideline, TCA).
7. Inability to Transmit.
Circumstances, both foreseeable and unforeseeable, may prevent a reporting party from
conducting EDI. Nevertheless, no Submitter will be excused from the requirement to file
reports with the Agency by the appropriate regulatory deadline. If a party is unable to
electronically file a required report by such deadline, it must submit a paper report on
forms required by the applicable regulation.
8. Signature.
The Submitter shall adopt as its signature an electronic identification consisting of
symbols (i.e., the Personal Identification Number (PIN) which is affixed to or contained
Issue Date: March 7, 1997
Revision Date: April 11, 1997 • B-5
-------
Prototype Emission Modeling Implementation Guideline
in each Document transmitted by the Submitter ("Signature"). The Submitter agrees that
any such Signature affixed to or contained in any transmitted Document shall be
sufficient to verify such party originated and possessed the requisite authority both to
originate the transaction and to verify the accuracy of the content of the document at the
time of transmittal. Unless otherwise specified in the TCA, affixing the Personal
Identification Number (PIN) issued to the Submitter by EPA to any transmitted
Document constitutes a valid Signature. The Submitter expressly agrees that it will sign
each and every report it submits by using its PIN(s) (or other electronic identification, if
provided for in the TCA), and that the use of the PIN(s) (or other electronic identification,
if provided for in the TCA) constitutes certification of the truth and accuracy, upon
penalty of perjury (or other program specific requirement), of the information contained
in each such report.
9. Definitions.
Whenever used in this Agreement or any documents incorporated into this Agreement by
reference, the following terms shall be defined as follows:
9.1 Compromise. When the PIN is intentionally or unintentionally disclosed to individuals
and organizations who are not authorized to know or use the PIN.
9.2 Data. Facts or descriptions of facts.
9.3 Document/Record. Information that is inscribed on a tangible medium or that is stored in
an electronic or other medium and is retrievable in perceivable form.
9.4 Electronic Agent. A computer program designed, selected or programmed by a party to
initiate or respond to electronic messages or performances without review by an
individual. An electronic agent acts within the scope of its agency if its performance is
consistent with the functions intended by the party who utilizes the electronic agent.
9.5 Electronic Message/Transaction. A record generated or communicated by electronic,
optical or other analogous means for transmission from one information system to
another. The term includes electronic data interchange and electronic mail.
9.6 Functional Acknowledgment. Is the sending of a 997 transaction set (under ANSI ASC
X12 Standards) indicating the results of the translator's syntactical analysis of the
electronically submitted file. A positive acknowledgment indicates that the syntax of the
submitted file conforms to the standard and can be processed by the translator. A negative
acknowledgment indicates nonconformance to the standards.
9.7 Guidelines. Federal Register Notice and EPA Implementation Guidelines.
Issue Date: March 7, 1997
B-6 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
9.8 Message. Data structured in accordance with the protocol specified in the Guidelines and
transmitted electronically between the parties and relating to a Transaction.
9.9 Personal Identification Number (PIN). Assigned by EPA, each PIN will consist of a
sequence of alpha-numeric characters.
9.10. Receive/Receipt. To take delivery of a record or information. An electronic record or
information is received when it enters an information processing system in a form
capable of being processed by that system if the recipient has designated that information
system for the purpose of receiving such records or information.
9.11 Date of Receipt. EPA will consider an electronically filed report received when it is
accessible to the receiver (i.e., EPA) at its receipt computer. Upon receipt of any report,
EPA will promptly submit a functional acknowledgment in return. A positive functional
acknowledgment indicating no syntactical errors will constitute conclusive evidence that
EPA has properly received a report and will establish the "Received Date". No document
shall satisfy any reporting requirement until it is received.
9.12 Report. The report required by (Program-specific notice will insert applicable
regulatory/statutory cite for program-specific report).
9.13 Signed. For the purposes of EDI, a transaction is "signed" if it includes a symbol and/or
action that is adopted or performed by a party or its electronic agent with the present
intent to authenticate or manifest assent to a record, a performance, or a message. Actions
or symbols adopted or performed by an electronic agent serve to authenticate with present
intent a record or message on behalf of a party if the party designed, programmed or
selected the electronic agent with an intent that the agent produce the result and the
electronic agent performs in a manner consistent with its intended programming. That a
record or message is signed is conclusively presumed as a matter of law if the parties
agreed to an authentication procedure and the symbol or action taken complies with that
procedure. Otherwise, that a document is signed may be proved in any manner including
by a showing that a procedure existed by which a party must of necessity have taken an
action or executed a symbol in order to have proceeded further in the use or processing of
the information.
9.14 Transaction. Any communication made or transaction carried out and identified as the
communication or transaction to which a Message refers including but not limited to the
filing of a specific report.
9.15 Transmission Log. Must be retained by all parties using EDI for reporting purposes. The
Transmission Log includes the date, time, destination address and telephone number, and
a copy of the file transmitted; it also documents the persons who had access to the
Issue Date: March 7, 1997
Revision Date: April 11, 1997 - B-7
-------
Prototype Emission Modeling Implementation Guideline
Submitter's system during the creation of the files and during their transmission. The
Submitter shall create an official Transmission Log of all transactions and maintain it
without any modification. Each Submitter shall designate one or more qualified
individuals with appropriate authority to certify the accuracy and completeness of the
Transmission Log and this designation shall be retained as part of the records. Each
Submitter shall also maintain records concerning the assignment and revocation of PINs,
as discussed elsewhere in this notice.
9.16 Transaction set. (Cite for specific program).
9.17 User Manual. (Cite, if any).
9.18 Writing. Any document properly transmitted pursuant to this Agreement shall be
considered to be a "writing" or "in writing". For the purpose of interpreting federal
statutes, "writing" is defined to include 'printing and typewriting and reproductions of
visual symbols by photographing, multi graphing, mimeographing, manifolding, or
otherwise'. Although the terms of contracts formed using EDI are stored in a different
manner than those of paper and ink contracts, they ultimately take the form of visual
symbols .... it is sensible to interpret federal law in a manner to accommodate
technological advancements .... It is evident that EDI technology had not been
conceived nor, probably, was even anticipated at the times section 1501 and the statutory
definition of "writing" were enacted. Nevertheless, we conclude that, given the legislative
history of section 1501 and the expansive definition of writing, section 1501 and 1 U.S.C.
Section 1 encompass EDI technology." U.S. Comptroller General decision, "Use of
Electronic Data Interchange Technology to Create Valid Obligations," File: B-245714
(13 December 1991).
9.19 Other Definitions. (As required, additional Definitions may be included in
Program-specific TCAs.)
10. EDI Transaction Parameters.
Each party may electronically transmit to or receive from the other party any of the
transaction sets listed in the Appendix and transaction sets which by agreement are added
to the Appendix (collectively referred to as "Documents" or "Reports"). All
Documents/Reports shall be transmitted in accordance with the standards set forth herein
and in the Appendix. Appendix(es) are hereby incorporated herein by reference. Any
transmission of data which is not a Document/Report (i.e., which is not one of the
specified transaction sets) shall have no force or effect between the parties.
10.1 Implementation Guidelines. All Documents/Reports transmitted between the parties shall
strictly adhere to published Accredited Standards Committee (ASC) X12 standards for
Issue Date: March 7, 1997
B-8 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
Electronic Data Interchange (EDI) and shall comply with data conventions and
implementation guidelines set forth in this Agreement and Federal Register notice
("Guidelines") and all modifications of the Guidelines.
10.2 Modifications of Standards. Whenever EPA intends to upgrade to a new version and
release of the ASC XI2 standard or modify the Guidelines, EPA shall give notice of its
intent and shall establish a conversion date. The Submitter shall have a minimum of sixty
(60) days from the conversion date to upgrade to the new standard. EPA can discontinue
support of the previous standard no sooner than ninety (90) days after the conversion
date. These dates may vary with specific program requirements. These dates may vary
with specific program requirements.
11. System and Operation Expenses.
Each party, at its own expense, shall provide and maintain the equipment, software,
services and testing necessary to effectively and reliably transmit and receive Documents.
12. Security.
The parties shall take reasonable actions to implement and maintain security procedures
necessary to ensure the protection of transmissions against the risk of unauthorized
access, alteration, loss or destruction including, but not limited to those set forth (in
Appendix A, in guidelines set forth in F.R., etc.).
12.1 Creation of PIN. Where EPA requires certification to insure the authenticity of
electronically submitted documents, EPA will generally require the Submitter to use a
PIN assigned by EPA. If EPA agrees to enter into a trading partner relationship with a
Submitter, EPA will assign PIN(s) upon receipt and receipt by EPA of the Submitter's
signed TCA. EPA will mail the PIN(s) directly to each authorized representative(s)
identified in the PIN request. The Agency will issue a new PIN at the written request, on
company letterhead, of a responsible corporate officer of the submitter. In addition, EPA
will change PINs where Submitters undergo personnel changes that affect the identity of
their authorized representatives, or where there is evidence of compromise. Depending on
the reporting cycle, EPA will then cancel such authorized representative's individual PIN
before the next reporting cycle to which the PIN applies, or no later than fourteen (14)
business days of receiving such notice, whichever comes first.
12.2 Protection of PIN. Each party must protect the security of its PIN(s) from compromise
and shall take all necessary steps to prevent its loss, disclosure, modification, or
unauthorized use. The Submitter shall notify EPA immediately if it has reason to believe
the security of any PIN(s) has been compromised and must request a change. If EPA has
reason to believe that PIN security has been compromised, the Agency will consult with
Issue Date: March?, 1997
Revision Date: April 11, 1997 • B-9
-------
Prototype Emission Modeling Implementation Guideline
the Submitter and initiate PIN changes where necessary. Also, the Submitter is
responsible for immediately notifying EPA (in writing and on company letterhead and
signed by an authorized corporate officer) of termination of employment, or
reassignment, of any authorized representative, and of any new or newly assigned
employee(s) who will act as authorized representative(s).
12.3 Access Control. (If required, additional program-specific measures to control access to
the transmitted files.)
12.4 Confidentiality. (If Applicable, program-specific clause.) The submitter may claim as
confidential information submitted to EPA pursuant to this agreement. In order to assert a
claim of confidentiality, the Submitter must mark the response CONFIDENTIAL
BUSINESS INFORMATION or with a similar designation, and must clearly specify
which information in the Document is so claimed. (The program may wish to insert here
specific instructions for asserting confidentiality claims for electronic submissions.)
Information so designated will be disclosed by EPA only to the extent allowed by, and by
means of, the procedures set forth in, 40 CFR Part 2. If the Submitter fails to claim the
information as confidential in accordance with the provisions of this paragraph, 10.4, the
information may be available to the public without further notice.
12.5 Other Specific Security Requirements. (If required, other program-specific measures.)
13. Misdirected and Corrupted Transmissions.
If EPA has reason to believe that a Message is not intended for EPA or is corrupted, EPA
shall notify the Submitter and shall delete from EPA's system the information contained
in such Message (where allowed by applicable law) but not the record of its receipt.
Where there is evidence that a Message has been corrupted or if any Message is identified
or capable of being identified as incorrect, EPA shall notify the Submitter and it shall be
re-transmitted by the Submitter as soon as practicable with a clear indication that it is a
corrected Message. (Dependent on circumstances, corresponding requirement may be
needed if EPA will be sending messages.)
14. Communications Connections.
Unless otherwise stipulated in program-specific notice, documents shall be transmitted
electronically to each party through a third party service provider ("Provider"),
designated in the program-specific Implementation Guidelines, who shall be considered
the designated provider. The Submitter may transmit through EPA's designated Provider
or through a third party service provider of their choice. In either case, the Submitter
assumes all risks associated with their interaction with third party service providers. Upon
written consent of EPA, at Submitter's own expense and at sender's own risk, documents
Issue Date: March?, 1997
B-10 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
may be electronically transmitted to EPA directly. EPA will specify procedures for doing
so. Upon thirty days advance notice EPA may change its third party service providers.
14.1 Third-Party Service Provider Fees. (Apportionment of the following fees: (could be
incorporated by reference from guidelines, appendix etc.)) EPA does not foresee clause
12.1 being included in it's TCA during the Interim Policy Phase and is uncertain if such
provisions will be included in future TCAs.
14.2 Third-Party Service Provider Liability Apportionment. Each party shall be responsible for
ensuring the correctness of its transmission except as otherwise provided in this
Agreement.
14.3 Records Transmitted Through Provider. The parties agree that either of them may have
access to Providers' copies of the records, at the expense of the requesting party.
15. Record Retention and Storage.
15.1 Transmission Log. The Transmission Log shall be maintained by the Submitter without
any modification for as long as required for the paper record (Specific program must
insert applicable regulations). The Submitter shall designate one or more individuals with
appropriate authority to certify the accuracy and completeness of the Transmission Log.
15.2 Record Retention. Nothing herein is intended to release the Submitter from or waive any
requirement of law applicable to the Submitter pertaining to record or document
retention, or to create new or additional requirements for retention of records or
documents except as specifically noted herein or in the Appendix(es). Sender shall retain
all records, regardless of the medium on which they are recorded, used in the derivation
of the Documents/Reports or information therein transmitted pursuant to this Agreement
for the period which would be required for functionally equivalent paper records.
16. Conflicting Terms and Conditions.
This Agreement and all appendices attached constitute the entire agreement between the
parties. As the parties develop additional capabilities respecting EDI, additional addenda
may be added to this Agreement. EPA will publish notice of new Addenda appending this
Agreement and their effective date in the Federal Register. Upon the effective date, each
Addendum shall be appended to this Agreement. If the Submitter does not agree to
specified changes in the terms and conditions of this Agreement, as provided in the newly
published Addenda, the Submitter must notify EPA in accordance with paragraph 15
below. In the absence of such notification, each addendum shall be appended to this
Agreement and the date published in the Federal Register notice shall be the effective
date.
Issue Date: March?, 1997
Revision Date: April 11, 1997 • B-ll
-------
Prototype Emission Modeling Implementation Guideline
17. Termination.
This Agreement shall remain in effect until terminated by either party with not less than
30 days prior written notice, which notice shall specify the effective date of termination;
provided, however, that any termination shall not affect the respective obligations or
rights of the parties arising under any Documents or otherwise under this Agreement
prior to the effective date of termination. Termination of this Agreement shall not affect
any action required to complete or implement Messages which are sent prior to such
termination. Emergency temporary termination of computer connections may be made to
protect data from illegal access or other incidental damage.
18. Survivability.
Notwithstanding termination for any reason, Clauses #2 (Validity and Enforceability),
#10 (Security), #13 (Record Retention and Storage), #21 (Governing Law), #22 (Choice
of Language), and #23 (Dispute Resolution) shall survive termination of this Agreement.
19. Assignability.
This Agreement is for the benefit of, and shall be binding upon, the Submitter and their
respective successors and assigns.
20. Severability.
Any provision of this Agreement which is determined to be invalid or unenforceable will
be ineffective to the extent of such determination without invalidating the remaining
provisions of this Agreement or affecting the validity or enforceability of such remaining
provisions.
21. Notice.
All notices or other forms of notification, request or instruction required to be given by a
party to any other party under paragraphs 10, 14, and 15 of this Agreement shall be
delivered by hand, or sent by first class post or other recognized carrier to the address of
the addressee as set out in this Agreement or to such other address as the addressee may
from time to time have notified for the purpose of this clause, or sent by electronic means
of message transmission producing hard copy read-out including telex and facsimile, or
published in the Federal Register notice, and shall be deemed to have been received:
• if sent by electronic means: at the time of transmission if transmitted during
business hours of the receiving instrument and if not during business hours, one
Issue Date: March?, 1997
B-12 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
hour after the commencement of the next working day following the day
transmission;
• if sent by first-class post or recognized carrier: 3 business days after posting
exclusive of the day of posting;
• if delivered by hand: on the day of delivery.
Notwithstanding the above, EPA may at its discretion provide notices under paragraphs
7.2, 13, and 17 of this Agreement via publication in the Federal Register. Notice shall be
deemed to be received on the day of publication of the Federal Register notice.
Notice address for EPA follows: USEPA, .
22. Inability to File Reports via EDI.
No party shall be liable for any failure to perform its obligations in connection with any
EDI Transaction or any EDI Document, where such failure results from any act or cause
beyond such party's control which prevents such party from transmitting or receiving any
Documents via EDI, except that the Submitter is nonetheless required to submit records
or information required by law via other means, as provided by applicable law and within
the time period provided by such law.
23. Governing Law.
This Agreement shall be governed by and interpreted in accordance with the Federal laws
of the United States.
24. Choice of Language.
(Optional Program-specific application clause) The parties have requested that this
Agreement and all Documents and other communications transmitted via the EDI
Network or otherwise delivered with respect to this Agreement be expressed in the
English language. (Should include translation.)
25. Dispute Resolution.
All disputes, differences, disagreements, and/or claims between the parties arising under
or relating to this agreement that are not resolved by negotiation and that the parties
cannot agree to submit for arbitration or other procedure for the resolution of disputes,
shall be subject to the jurisdiction of U.S. Courts.
Issue Date: March?, 1997
Revision Date: April 11, 1997 • B-13
-------
Prototype Emission Modeling Implementation Guideline
26. Entire Agreement.
This Agreement (and the Implementation Guide and Appendix) constitute the complete
agreement of the parties relating to the matters specified in this Agreement and supersede
all prior representations or agreements, whether oral or written, with respect to such
matters. No oral modification or waiver of any of the provisions of this Agreement shall
be binding on either party. As the Partners develop additional capabilities respecting EDI,
additional Addenda may be added to this Agreement. EPA does not intend to change
guidelines without just cause or without consulting industry, however, as a practical
matter it is too cumbersome to obtain formal agreements from each Submitter when
technical or procedural changes are required, particularly to the Implementation
Guidelines. Therefore, EPA will publish notice of new Addenda appending this
Agreement and their effective date in the Federal Register. Upon the effective date, each
Addendum shall be appended to this Agreement.
This Agreement is for the benefit of, and shall be binding upon, the parties and their
respective successors and assigns.
(To be signed by the Delegated Authority in specific EPA Office)
Dated:
Name of Delegated Authority
Title of Delegated Authority
III. MODEL OF EPA TERMS AND CONDITIONS AGREEMENT MEMORANDUM
Program-specific notices will contain the memorandum, similar to this model agreement
memorandum, which the Submitter will sign and return to EPA. The program-specific TCA will
stipulate what actions will constitute acceptance by EPA of a Submitter's signed and returned
agreement memorandum and the effective date of the agreement.
Issue Date: March 7, 1997
B-14 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
APPENDIX C — CROSS REFERENCE MATRIX OF PHASE I CORE DATA MODEL
vs. EIIP X12 841 CONVENTION DOCUMENT
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March?, 1997
C-2 Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
This table is a cross reference between the EIIP XI2 841 Convention Document and the EIIP
Phase I Core Data Model. The table displays each data entity and data attribute specified in the
data model and where the corresponding data element is located in the convention document.
The data model entities and attributes are for reference use only.
EIIP Entity
EIIP Attribute
X12 Data Element
Activity/Schedule
Start Datemme
Activity (throughput) beginning date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
HL03 = 'C' and
DTM01 in LX loop = '196'
Activity/Schedule
Process Rate/Throughput
Activity (throughput) data:
MEA03 in LX loop (pos. 545) if
HL03 = 'C' and
MEA01 in LX loop = TR'
Activity/Schedule
Confidentiality Indicator
Confidentiality indicator:
SPI01 in detail level (pos. 481) if
HL03 = 'C'
Activity/Schedule
Maximum Throughput
Maximum throughput:
MEA06 in LX loop (pos. 545) if
HL03 = 'C' and
MEA02 in LX loop = TR'
Activity/Schedule
End Date/Time
Activity (throughput) end date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
HL03 = 'C' and
DTM01 in LX loop = '197'
Activity/Schedule
Throughput Method Code
Throughput method code:
REF02 in LX loop (pos. 553) and
REF03 in LX loop if
HL03 = 'C' and
REF01 in LX loop = 'IX'
Activity/Schedule
Reliability Indicator
DARS quality rating score:
REF02 in LX loop (pos. 553) if
HL03 = 'C' and
REF01 in LX loop = 'DO'
Activity/Schedule
Unit of Measure
Activity (throughput) data:
MEA04 [composite] in LX loop (pos. 545) if
HL03 = 'C'
Aggregate Controls as Applied
Pollutant Code
CAS number/pollutant:
SPI03 in detail level (pos. 639) if
HL03 = '9' and
CID04 in detail level = 'CE'
Aggregate Controls as Applied
Total Capture/Control Efficiency
Total capture/control efficiency:
MEA03 in CID loop (pos. 741) if
HL03 = '9' and
CID04 in detail level = 'CE' and
MEA01 in CID loop = 'AH'
Issue Date: March?, 1997
Revision Date: April 11, 1997
C-3
-------
Prototype Emission Modeling Implementation Guideline
E1IP Entity
EIIP Attribute
X12 Data Element
Aggregate Controls as Applied
Rule Effectiveness
Rule effectiveness:
MEA03 in CID loop (pos. 741) if
HL03 = '9' and
CID04 in detail level = 'CE' and
MEA01 in CID loop = 'AC'
Aggregate Controls as Applied
Rule Penetration
Rule penetration:
MEA03 in CID loop (pos. 741) if
HL03 = '9' and
CID04 in detail level = 'CE' and
MEA01 in CID loop = 'PM1
Aggregate Controls as Applied
Rule Effectiveness Method Code
Regulation identifier for rule effectiveness:
REF02 in MEA loop (pos. 745) if
HL03 = '9' and
CID04 in detail level = 'CE' and
MEA01 in CID loop = 'AG' and
REF01 in MEA loop = '72'
Control Equipment
Pollutant Code
CAS Number/Pollutant code:
LINOS in LX loop (pos. 225) if
HL03 = '5'
Control Equipment
Percent Capture Efficiency
Percent capture efficiency:
MEA03 in LX loop (pos. 229) if
HL03 = '5' and
MEA02 in LX loop = 'IGR'
Control Equipment
Percent Control Efficiency
Percent control efficiency:
MEA03 in LX loop (pos. 229) if
HL03 = '5' and
MEA02 in LX loop = 'COT'
Control Equipment
Device Type
Physical unit code:
PID04 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP'
Control Equipment
Method Code
Currently no mapping - to be include in future version
of convention document
Control Equipment
Description
Description:
PID05 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP' and
PID04 in detail level = '02'
Control Equipment
Capacity
Volume:
MEA03 in LX loop (pos. 229) if
HL03 = '5' and
PID04 in detail level = '02' and
MEA02 in LX loop = 'VOL'
Control Equipment
Capacity Units
Control unit data:
MEA04 (C00101) in LX loop (pos. 229) if
HL03 = '5' and
PID04 in detail level = '02' and
MEA02 in LX loop = VOL'
C-4
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
Control Equipment
Control Strategy
Control Strategy
Control Strategy
Defined Areas
Defined Areas
Defined Areas
Dynamic Grid
Dynamic Grid
Dynamic Grid
Dynamic Grid
EIIP Attribute
Status
Rule/Regulation Name
Permit Requirements
Geographic ID Code
Geographic ID Code
Nonattainment Area Code
Area Name
Geographic ID Code
Grid ID
Number of X Cells
X Cell Size
X12 Data Element
Operational status:
REF02 in LX loop (pos. 237) if
HL03 = '5' and
PID04 in detail level = '02' and
REF01 in LX loop = 'ZZ'
Control strategy description:
MSG01 in SPI loop (pos. 655) if
HL03 = '9'
Control strategy description:
MSG01 in SPI loop (pos. 655) if
HL03 = '9'
Place of occurrence - identification code:
N 104 in header level (pos. 045) if
HL03 = '5' and
N101 in SPI loop = 7C' and
N103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N 103 in header level = '93'
Note: Control Strategy holds a child relationship to the
Physical-level which contains these data.
Place of occurrence - identification code:
N 104 in header level (pos. 045)
Nonattainment area data:
N406 in header level (pos. 054) if
N405 in header level = 'RG'
Place of occurrence:
N 102 in header level N1 loop (Pos. 045)
Place of occurrence - identification code:
N 104 in header level (pos. 045) if
HL03 = '4' and
N101 in SPI loop = 7C' and
N 103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N 103 in header level = '93'
Dynamic grid:
REF03 in LX loop (pos. 079) if
HL03 = '4' and
REF01 in LX loop = '6E' and
REF02 in LX loop = '05'
Dynamic grid data:
MEA03 in LX loop (pos. 071) if
HL03 = '4' and
MEA01 in LX loop = 'PO' and
MEA02 in LX loop = 'WD'
Dynamic grid data:
MEA03 in LX loop (pos. 071) if
HL03 = '4' and
MEA01 in LX loop = 'PO' and
MEA02 in LX loop = 'WD'
Issue Date: March 7, 1997
Revision Date: April 11, 1997
C-5
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Dynamic Grid
Number of Y Cells
Dynamic grid data:
MEA03 in LX loop (pos. 071) if
HL03 = '4' and
MEA01 in LX loop = 'PO' and
MEA02 in LX loop = 'HT
Dynamic Grid
Y Cell Size
Dynamic grid data:
MEA03 in LX loop (pos. 071) if
HL03 = '4' and
MEA01 in LX loop = 'PO' and
MEA02 in LX loop = 'HT'
Dynamic Grid
Projection System Name
Projection system name:
REF03 in LX loop (pos. 079) if
HL03 = '4' and
REF01 in LX loop = '6E' and
REF02 in LX loop = '06'
Emission Factors
Start Date/Time
Activity (throughput) beginning date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
HL03 = 'C' and
DTM01 in LX loop = '196'
Note: Emission Factors holds a child relationship to
Activity-level which contains these data.
Emission Factors
End Date/Time
Activity (throughput) end date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
HL03 = 'C' and
DTM01inLXIoop = '197'
Note: Emission Factors holds a child relationship to
Activity-level which contains these data.
Emission Factors
Pollutant Code
Pollutant:
SPI03 in detail level (pos. 639) if
HL03 = '9' and
CID04 in detail level = 'EF'
Emission Factors
Factor Type Code
No mapping - to be removed from model
Emission Factors
Numeric Value
Emission factor data:
STA02 in CID loop (pos. 751) if
HL03 = '9' and
CID04 in detail level = 'EF'
Emission Factors
Unit of Measure
Emission factor data:
STA03 (C00101) in CID loop (pos. 751) if
HL03 = '9' and
CID04 in detail level = 'EF'
Emission Factors
Material
Activity (throughput) product:
REF02 in LX loop (pos. 553) if
HL03 = 'C' and
REF01 in the LX loop = 'PG'
Note: Emission Factors holds a child relationship to
Activity-level which contains these data.
C-6
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
Emission Factors
Emission Factors
Emission Factors
Emission Process
Emission Process
Emission Process
Emission Process
Emission Process
Emission Process
Emission Process
Emission Process
Emission Process
EIIP Attribute
Calculation Method
Control Status
Reliability Indicator
Start Date/Time
Description
sec
Process SIC
Material
Material Description
Federal ID Code
End Date/Time
AMS Code
X1 2 Data Element
Emission factor method code:
REF02 in STA loop (pos. 755) if
HL03 = '9' and
CID04 in detail level = 'EF' and
REF01 in STA loop = 'C3'
Emission factor control type:
TMD03 in CID loop (pos. 729) if
HL03 = '9' and
CID04 in detail level = 'EF'
DARS quality rating score:
REF02 in STA loop (pos. 755) if
HL03 = '9' and
CID04 in detail level = 'EF'
REF01 in STA loop = 'DO'
Operating schedule beginning date:
DTM02 in STA loop (pos. 437) if
HL03 = '6' and
DTM01 in LX loop = '196'
Process identifier comments/description:
SPI05 in detail level (pos. 323) if
HL03 = '6'
Source Classification Code (SCC):
PID04 in detail level (pos. 345) if
HL03 = '6' and
PID02 in detail level = 'SC'
Standard Industry Classification Code (SIC) code:
REF02 in detail level (pos. 371) if
HL03 = '6' and
REF01 in detail level = 'IJ'
Process product:
REF02 in STA loop (pos. 439) if
HL03 = '6' and
REF01 in STA loop = 'PG'
Material description:
MSG01 in SPI loop (pos. 339) if
HL03 = '6'
Federal identification code for a process:
SPI03 in detail level (pos. 323) if
HL03 = '6' and
SPI02 in detail level = 'PE'
Operating schedule date:
DTM02 in STA loop (pos. 437) if
HL03 = '6' and
DTM01 in LX loop = '197'
AIRS Area and Mobile Sources (AMS) code:
PID04 in detail level (pos. 345) if
HL03 = '6' and
PID02 in detail level = '12'
Issue Date: March 7, 1997
Revision Date: April 11, 1997
C-7
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Emission Process
Winter Throughput Percentage
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate winter if
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 in CID loop = 'ZZ'
Emission Process
Spring Throughput Percentage
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate spring if
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 inCIDIoop = 'ZZ'
Emission Process
Summer Throughput Percentage
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate summer if
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 inCIDIoop = 'ZZ'
Emission Process
Fall Throughput Percentage
Seasonal operational adjustment factor data:
STA02 in CID loop (pos. 435) and
DTM01 in STA loop (pos. 437) indicate fall if
HL03 = '6' and
CID04 in detail level = 'A' and
STA01 inCIDIoop = 'ZZ'
Emission Process
Hours Per Day
Operating schedule data:
STA03 (C00101) in CID loop (pos. 435) = 'HR' and
STA03 (C001004) in CID loop = 'DA' and
STA07 (C00105) in CID loop indicates '-1' if
HL03 = '6' and
CID04 in detail level = 'S' and
STA01 in CID loop = '30'
Emission Process
Days Per Week
Operating schedule data:
STA03 (C00101) in CID loop (pos. 435) = 'DA' and
STA03 (C001004) in CID loop = 'WK' and
STA07 (C00105) in CID loop indicates '-V if
HL03 = '6' and
CID04 in detail level = 'S' and
STA01 in CID loop = '30'
Emission Process
Weeks Per Year
Operating schedule data:
STA03 (C00101) in CID loop (pos. 435) = 'WK' and
STA03 (C001004) in CID loop = 'YR' if
STA07 (C00105) in CID loop indicates '-1' if
HL03 = '6' and
CID04 in detail level = 'S' and
STA01 in CID loop = '30'
Emission Process
Hours Per Year
Operating schedule data:
STA03 (C00101) in CID loop (pos. 435) = 'HR' and
STA03 (CO01004) in CID loop = 'YR' if
STA07 (C00105) in CID loop indicates '-1' if
HL03 = '6' and
CID04 in detail level = 'S1 and
STA01 in CID loop = '30'
CO
-O
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
Emission Process
Emission Process
Emission Process
Emission Process
Emission Release Point
Emission Release Point
Emission Release Point
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emission Unit/Physical Unit
EIIP Attribute
Maximum Actual Throughput
Heat Content
Sulfur Content
Ash Content
Emission Release Point Type
Federal ID Code
Status
Federal ID Code
Description
Emission Unit Type Code
Number of Units
X12 Data Element
Maximum actual throughput:
STA02 in CID loop (pos. 435) if
HL03 = '6' and
CID04 in detail level = T and
STA01 in CID loop = '34'
Heat content:
STA02 in CID loop (pos. 435) if
HL03 = '6' and
CID04 in detail level = 'HC' and
STA01 in CID loop = '34'
Sulfur content:
STA02 in CID loop (pos. 435) if
HL03 = '6' and
CID04 in detail level = 'SC' and
STA01 in CID loop = '34'
Ash content:
STA02 in CID loop (pos. 435) if
HL03 = '6' and
CID04 in detail level = 'AC' and
STA01 in CID loop = '34'
Physical unit code:
PID04 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP'
Federal identifier code:
SPI03 in detail level (pos. 165) if
HL03 = '5' and
SPI02 in detail level = 'PE'
Operational status:
REF02 in LX loop (pos. 237) if
HL03 = '5' and
REF01 in LX loop = 'ZZ'
Federal identifier code:
SPI03 in detail level (pos. 165) if
HL03 = '5' and
SPI02 in detail level = 'PE'
Description:
PID05 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP' and
PID04 in detail level = '03'
Physical unit code:
PID04 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP'
Number of units:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'CT
Issue Date: March 7, 1997
Revision Date: April 11, 1997
C-9
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emission Unit/Physical Unit
Emissions
Emissions
EIIP Attribute
Confidentiality Indicator
Date Installed/Modified
Rule Applicability
Design Capacity
Capacity Units
State/Local Emission Unit ID
Code
Status
Start Date/Time
Pollutant Code
X12 Data Element
Confidentiality indicator
SPI01 in detail level (pos. 165) if
HL03 = '5'
Time period associated with operational status:
DTM02 in LX loop (pos. 235) and
DTM05 in LX loop if
HL03 = '5' and
DTM01 in LX loop = '169' and
REF01 in LX loop = '22' and
REF02 in LX loop has a value
Currently no mapping - to be include in future version
of convention document
Design capacity:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'VOL1
Design capacity data:
MEA04 (C00101) in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD'
MEA02 in PID loop = 'VOL'
State identification code/description:
SPI03 in detail level (pos. 165) if
HL03 = '5' and
SPI02 in detail level = 'G5'
and
Local identification code/description:
SPI03 in detail level (pos. 165) if
HL03 = '5' and
SPI02 in detail level = 'WF
Operational status:
REF02 in LX loop (pos. 237) if
HL03 = '5' and
PID04 in detail level = '03' and
REF01 in LX loop = '22'
Activity (throughput) beginning date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
HL03 = 'C' and
DTM01 in LX loop = '196'
Note: Emissions holds a child relationship to the
Activity-level which contains these data.
CAS number/pollutant:
SPI03 in detail level (pos. 639) if
HL03 = '9' and
CID04 in detail level = 'ES'
C-10
Issue Date: March 7, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Emissions
Emission Type
Type of estimated emission measurement:
STA01 in CID loop (pos. 751) and/or
STA07 in CID loop and/or
STA08 in CID loop if
HL03 = '9' and
CID04 in detail level = 'ES'
Emissions
Numeric Value
Pollutant-specific estimated emissions data:
STA02 in CID loop (pos. 751) if
HL03 = '9' and
CID04 in detail level = 'ES'
Emissions
Unit of Measure
Pollutant-specific estimated emissions data:
STA03 [composite] in CID loop (pos. 751) if
HL03 = '9' and
CID04 in detail level = 'ES'
Emissions
Method Code
Estimated emissions method code:
REF02 in STA loop (pos. 755) if
HL03 = '9' and
CID04 in detail level = 'ES' and
REF01 in STA loop = 'C31
Emissions
Reliability Indicator
DARS quality rating score:
REF02 in STA loop (pos. 755) if
HL03 = '9' and
CID04 in detail level = 'ES' and
REF01 in STA loop = 'DO'
Emissions
End Date
Activity (throughput) end date and time:
DTM02 in LX loop (pos. 551) and
DTM03 in LX loop and
DTM05 in LX loop if
HL03 = 'C' and
DTM01 in LX loop = '197'
Note: Emissions holds a child relationship to the
Activity-level which contains these data.
Geographic Coordinates
Sequence Number
Dynamic grid cell:
MEA03 in LX loop (pos. 071) and
MEA04 [composite] in LX loop = 'EA' if
HL03 = '4' and
MEA01 in LX loop = 'PO'
Geographic Coordinates
Geographic ID Code
Place of occurrence - identification code:
N104 in header level (pos. 045)
Geographic Coordinates
XY Coordinate Type
Dynamic grid coordinate:
REF04 [composite] in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '05'
Note: Coordinate type specified by qualifier employed.
Geographic Coordinates
UTM Zone
Universal transverse mercator - zone:
REF04 (C04006) in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '05' and
REF04 (C04005) in LX loop = 'XW
Issue Date: March 7, 1997
Revision Date: April 11, 1997
C-ll
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
Geographic Coordinates
Geographic Coordinates
Geographic Coordinates
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
Geographic Location
EIIP Attribute
X Coordinate
Y Coordinate
Elevation
Geographic ID Code
Country
EPA Region
State/Province/Territory (FIPS)
County/Parish/Reservation
(FIPS)
Air Basin
Municipality
Grid ID
iCell
jCell
Air Quality Control Region
City
Highway Link/TAZ ID
X12 Data Element
Latitude:
REF04 (C04004) in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '05' and
REF04 (C04003) in LX loop = 'LQ'
Longitude:
REF04 (C04002) in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '05' and
REF04 (C04001) in LX loop = IK'
Currently no mapping - to be include in future version
of convention document
Place of occurrence - identification code:
N104 in header level (pos. 045)
Country code:
N404 in header level (pos. 054)
EPA Region:
N406 in header level (pos. 054) if
N405 in header level = 'RJ'
State or province:
N402 in header level (pos. 054)
County/parish code:
REF02 in header level N1 loop (pos. 057) if
REF01 in header level N1 loop = 'ZX'
Air basin data:
REF02 in header level N1 loop (pos. 057) if
REF01 in header level N1 loop = 'ZZ'
Municipality:
N102 in header level (pos. 045) if
N101 in header level = 'C6'
Projection system name:
REF03 in LX loop (pos. 079) if
REF01 in LX loop = '6E' and
REF02 in LX loop = '06'
Currently no mapping - to be include in future version
of convention document
Currently no mapping - to be include in future version
of convention document
Currently no mapping - to be include in future version
of convention document
City name:
N401 in header level (pos. 054)
N405 = 'Fl'
Highway link/TAZ ID:
REF02 in header level N1 loop (pos. 057) if
REF01 in header level N1 loop = WT
C-12
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EHP Entity
EIIP Attribute
X12 Data Element
Meteorology
Geographic ID Code
Place of occurrence - identification code:
N104 in header level (pos. 045) if
HL03 = '5' and
N101 in SPI loop = 7C'and
N103 in SPI loop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93'
Note: Meteorology holds a child relationship to the
Physical-level which contains these data.
Meteorology
Start Date/Time
Meteorological parameter beginning date and time:
DTM02 in MEA loop (pos. 585) and
DTM03 in MEA loop and
DTM05 in MEA loop if
HL03 = 'C' and
CID04 in detail level = 'M' and
DTM01 in MEA loop = '196'
Meteorology
End Date/Time
Meteorological parameter end date and time:
DTM02 in MEA loop (pos. 585) and
DTM03 in MEA loop and
DTM05 in MEA loop if
HL03 = 'C' and
CID04 in detail level = 'M' and
DTM01 in MEA loop = '197'
Meteorology
Wind Speed
Wind speed:
MEA03 in CID loop
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Meteorology
Humidity
Relative humidity:
MEA03 in CID loop (pos. 583) if
HL03 = 'C' and
CID04 in detail level = 'M' and
MEA01 in CID loop = 'EN' and
MEA02 in CID loop = 'RA'
Meteorology
Humidity Units
Relative humidity data:
MEA04 (C00101) in CID loop (pos. 583) if
HL03 = 'C' and
CID04 in detail level = 'M' and
MEA01 in CID loop = 'EN' and
MEA02 in CID loop = 'RA'
Meteorology
Diurnal Temperature Change
Diurnal temperature change:
MEA03 in CID loop (pos. 583) if
HL03 = 'C' and
CID04 in detail level = 'M' and
MEA01 in CID loop = 'EN' and
MEA02 in CID loop = 'AD'
Meteorology
Visible Radiation
Visible radiation:
MEA03 in CID loop (pos. 583) if
HL03 = 'C' and
CID04 in detail level = 'M' and
MEA01 in CID loop = 'EN' and
MEA02 in CID loop = 'BR'
Meteorology
Visible Radiation Units
Visible radiation data:
MEA04 (C00101) in CID loop (pos. 583) if
HL03 = 'C' and
CID04 in detail level = 'M' and
MEA01 in CID loop = 'EN' and
MEA02 in CID loop = 'BR1
Path
Origin Type
Physical unit code:
PID04 in detail level (pos. 187) if
HL03 = '5' and
MEA02 in LX loop = 'DIS' and
REF01 in LX loop = '5M' and
REF02 in LX loop has a value and
PID02 in detail level = 'PP'
Path
Destination Type
Physical unit code:
PID04 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP'
Note: Path is defined by identifying the physical unit in
an emission path which immediately precedes the unit
being reported in the current iteration of the loop.
Therefore, the destination of the path is equivalent to
the physical unit being reported in the current iteration
of the loop.
Path
Percent Flow from Origin
Path split data:
MEA03 in LX loop (pos. 229) if
HL03 = '5' and
MEA02 in LX loop = 'DIS' and
C-14
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Process Growth Factors
Initial Year
Process growth factors start year:
DTM07 in LX loop (pos. 393) if
HL03 = '6' and
DTM01 in LX loop = '196' and
DTM06 in LX loop = 'CY'
Process Growth Factors
Projected Year
Process growth factors projected action end date:
DTM07 in LX loop (pos. 393) if
HL03 = '6' and
DTM01 in LX loop = '575' and
DTM06 in LX loop = 'CY'
Process Growth Factors
Growth Factor
Process growth factor data:
MEA03 in LX loop (pos. 387) if
HL03 = '6' and
MEA01 in LX loop = 'AG' and
Process Growth Factors
Growth Factor Reference
Process growth factor reference text:
REF03 in LX loop (pos. 395) if
HL03 = '6' and
REF01 in LX loop = 'ZZ'
Process Growth Factors
Control Factor
Currently no mapping - to be include in future version
of convention document
Process Growth Factors
Growth Factor Units
Process growth factor data:
MEA04 (C00101) in LX loop (pos. 387) if
HL03 = '6' and
MEA01 in LX loop = 'AG'
Site/Source
Geographic ID Code
Place of occurrence - identification code:
N104 in header level (pos. 045) if
HL03 = '4' and
N101 in SPI loop = 7C'and
N103inSPI loop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93'
Site/Source
Site Name
Name:
N102 in SPI loop (pos. 019) if
HL03 = '4' and
N101 in SPI loop = 7C'
Site/Source
Physical Address
Address information:
N301 in header level (pos. 051) and
N302 in header level if
HL03 = '4' and
N101 in SPI loop = '7C'and
N103 in SPI loop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 7C'
Issue Date: March 7, 1997
Revision Date: April 11, 1997
C-15
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Site/Source
Mailing Address
Address information:
N301 in header level (pos. 051) and
N302 in header level if
HL03 = '4' and
N101inSPIIoop = 7C'and
N103inSPIIoop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'FE'
Site/Source
Parent Company
Parent company:
N102 in header level (pos. 045) if
HL03 = '4' and
N101 in SPI loop = 7C'and
N103 in SPI loop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'B4'
Site/Source
Parent Company Mailing
Address
Address information:
N301 in header level (pos. 051) and
N302 in header level if
HL03 = '4' and
N101inSPIIoop = 7C'and
N103 in SPI loop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'B4'
Site/Source
Inventory Contact Name
Preparer:
PER02 in header level (pos. 060) if
HL03 = '4' and
N101inSPIIoop = 7C'and
N103 in SPI loop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'P1' and
PER01 in header level = 'PI'
Site/Source
Inventory Contact Phone
Number
Communication number:
PER04 in header level (pos. 060) or
PER06 in header level if
HL03 = '4' and
N101 in SPI loop = 7C'and
N103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'P1' and
PER01 in header level = 'PI' and
PER03 in header level = TE' or
PER05 in header level = TE'
C-16
Issue Date: March 7,1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Site/Source
Inventory Contact Fax Number
Communication number:
PER04 in header level (pos. 060) or
PER06 in header level if
HL03 = '4' and
N101 in SPl loop ='7C'and
N103 in SPl loop = '93' and
N104 in SPl loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'P1' and
PER01 in header level = 'PI' and
PER03 in header level = 'FX' or
PER05 in header level = 'FX'
Site/Source
Inventory Contact E-mail
Address
Communication number:
PER04 in header level (pos. 060) or
PER06 in header level if
HL03 = '4' and
N101 in SPl loop = VC'and
N103 in SPl loop = '93'and
N104 in SPl loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'P1' and
PER01 in header level = 'PI' and
PER03 in header level = 'EM' or
PER05 in header level = 'EM'
Site/Source
Owner
Owner:
N102 in header level (pos. 045) if
HL03 = '4' and
N101 in SPl loop = 7C' and
N103 in SPl loop = '93' and
N104 in SPl loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'HA'
Site/Source
SIC
Standard Industry Classification (SIC) code:
REF02 in detail level (pos. 055) if
HL03 = '4' and
REF01 in detail level = 'IJ'
Site/Source
Number of Employees
Numbers of employees:
MEA03 in LX loop (pos. 071) if
HL03 = '4' and
MEA01 in LX loop = 'CT
Site/Source
Description
Comments for a site/source:
SPI05 in detail level (pos. 007) if
HL03 = '4' and
SPI02 in detail level = 'IX'
Site/Source
Federal ID Code
Federal key identifier code:
SP103 in detail level (pos. 007) if
HL03 = '4' and
SPI02 in detail level = 'IJ'
Site/Source
Federal ID Code #2
Federal identification code:
SPI03 in detail level (pos. 007) if
HL03 = '4' and
SPI02 in detail level = 'PE'
Issue Date: March?, 1997
Revision Date: April 11,1997
C-17
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Site/Source
ORIS Utility Plant Code
ORIS utility plant code:
SPI03 in detail level (pos. 007) if
HL03 = '4' and
SPI02 in detail level = 'ZZ1
Site/Source
Source Type
Source type code:
REF02 in detail level (pos. 055) if
REF01 in detail level = '06'
Site/Source
Jurisdiction
Jurisdiction:
N102 in header level (pos. 045) if
HL03 = '4' and
N101 in SPI loop = 7C'and
N103inSPIIoop = '93'and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = 'JU'
Site/Source
State/Local ID Code
State identification code/description:
SPI03 in detail level (pos. 007) if
HL03 = '4' and
SPI02 in detail level = 'G5'
and
Local identification code/description:
SPI03 in detail level (pos. 007) if
HL03 = '4' and
SPI02 in detail level = 'WF
Site/Source
Physical Zip Code
Postal code:
N403 in header level (pos. 054) if
HL03 = '4' and
N101 in SPI loop ='7C'and
N103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = '7C'
Site/Source
Census Block ID
Census block:
REF02 in header level N1 loop (pos. 057) if
HL03 = '4' and
N101 in SPI loop = 7C' and
N103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N103 in header level = '93' and
N101 in header level = '7C'
REF01 in header level N1 loop = 'ZV
Speciation Profiles
Pollutant #1 Code
Chemical mechanism:
CID04 in detail level (pos. 093) if
HL03 = '4'
Speciation Profiles
Pollutant #2 Name
Chemical surrogate:
REF03 in detail level (pos. 113) if
HL03 = '4' and
REF01 in detail level = M9'
Speciation Profiles
Pollutant #2 Code
Chemical surrogate:
REF01 in detail level (pos. 113) if
HL03 = '4'
C-18
Issue Date: March?, 1997
Revision Date: April 11, 1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Entity
EIIP Attribute
X12 Data Element
Speciation Profiles
Numeric Value
Chemical surrogate data:
MEA03 in detail level (pos. 109) if
HL03 = '4' and
REF01 in detail level = '19'
Speciation Profiles
Unit of Measure
Chemical surrogate data:
MEA04 (C00101) in detail level (pos. 109) if
HL03 = '4' and
REF01 in detail level = '19'
Stack Physical Parameter
Emission Release Point Type
Physical unit code:
PID04 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP'
Stack Physical Parameter
Description
Description:
PID05 in detail level (pos. 187) if
HL03 = '5' and
PID02 in detail level = 'PP' and
PID04 in detail level ='01'
Stack Physical Parameter
Stack Height
Height above ground:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = '5F
Stack Physical Parameter
Stack Diameter
Inside diameter:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'ID'
Stack Physical Parameters
Geographic ID Code
Place of occurrence - identification code:
N104 in header level (pos. 045) if
HL03 = '5' and
N101 in SPI loop ='7C'and
N103 in SPI loop = '93' and
N104 in SPI loop = N104 in header level and
N103 in header level = '93'
Stack Physical Parameter
Exit Gas Temperature
Exit gas temperature:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = TE'
Stack Physical Parameter
Exit Gas Velocity
Exit gas velocity:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'ZZZ'
Stack Physical Parameter
Exit Gas Flow Rate
Flow rate:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'PD' and
MEA02 in PID loop = 'FR'
Issue Date: March 7, 1997
Revision Date: April 11, 1997
C-19
-------
Prototype Emission Modeling Implementation Guideline
EI1P Entity
Stack Physical Parameter
Stack Physical Parameter
EIIP Attribute
Plume Height
Height Above Terrain
X12 Data Element
Plume height data:
MEA03 in PID loop (pos. 193) if
HL03 = '5' and
MEA01 in PID loop = 'BA'
Currently no mapping - to be include in future version
of convention document
The following table details those EIIP Attributes indicated in the EIIP Core Data Model as being
unique identifiers (UID). These elements are intended for use in developing relationships
between various EIIP Entities. They are not intended for specific use in the design or
development of a database system. However, the structure represented by them must be
accounted for in the system in order to maintain the integrity of the entity relationships. The XI2
data elements that are correspond are provided for reference to the data model attributes only.
Table of Unique Identifiers Specified in the EIIP Data Model
EIIP Attribute
X12 Data Element
Process UID
Hierarchical ID number:
HL02 in detail level (pos. 319) if
HL03 = '6'
Note: Activity/Schedule holds a child relationship to
the Process-level which contains these data.
Site UID
Hierarchical ID number:
HL02 in detail level (pos. 003) if
HL03 = '4'
Note: Activity/Schedule holds a child relationship to
the Site/Source-level which contains these data.
Unit UID
Hierarchical ID number:
HL02 in detail level (pos. 161) if
HL03 = '5'
Note: Activity/Schedule holds a child relationship to
the Physical-level which contains these data.
Control Strategy UID
Hierarchical ID number:
HL02 in detail level of the level indicated if
HL03 = '9' and
PID04 in detail level (pos. 661) has a value and
HL03 of the level indicated has a value
Note.' The value in HL02 equals the HL iteration tp
which the strategy is applied.
Control Equipment UID
Hierarchical ID number:
HL02 in detail level (pos. 161) if
HL03 = '5'
Emission Release Point UID
Hierarchical ID number:
HL02 in detail level (pos. 161) if
HL03 = '5'
C-20
Issue Date: March 7, 1997
Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
EIIP Attribute
X12 Data Element
Origin UID
Hierarchical ID number:
HL02 in detail level (pos. 161) if
HL03 = '5'
Note: The value in HL02 equals the HL iteration
which contains the intended origin. Path is defined
by identifying the physical unit in an emission path
which immediately precedes the unit being reported
in the current iteration of the loop. Therefore, the
destination of the path is equivalent to the physical
unit being reported in the current iteration of the
loop.
Destination UID
Hierarchical ID number:
HL02 in detail level (pos. 161) if
HL03 = '5'
Note: The value in HL02 equals the HL iteration
which is being reported (i.e., the destination). Path
is defined by identifying the physical unit in an
emission path which immediately precedes the unit
being reported in the current iteration of the loop.
Therefore, the destination of the path is equivalent to
the physical unit being reported in the current
iteration of the loop.
Issue Date: March 7, 1997
Revision Date: April 11, 1997
C-21
-------
Prototype Emission Modeling Implementation Guideline
APPENDIX D — EIIP X12 841 CONVENTION DOCUMENT
Issue Date: March 7, 1997
Revision Date: April 11,1997
-------
Prototype Emission Modeling Implementation Guideline
[This page intentionally left blank.]
Issue Date: March 7, 1997
D-2 Revision Date: April 11, 1997
-------
841 Specifications/Technical Information
Functional Group ID=
ID=SP
Introduction:
This Draft Standard for Trial Use contains the format and establishes the data contents of the
Specifications/Technical Information Transaction Set (841) for use within the context of an Electronic Data
Interchange (EDI) environment. The transaction set can be used to transmit or request specifications or technical
information between trading partners. It can be used to transmit engineering change and engineering change
requests. It can also be used to allow EDI trading partners the ability to exchange a complete or partial technical
description of a product, process, service, etc. over the same path as any other EDI transaction. The detail area can
include graphic, text, parametric, tabular, image, spectral, or audio data. A transmission includes identification
information to assist the receiver in interpreting and utilizing the information included in the transaction. Further
action as a consequence of the receipt and initial processing of the specification or other technical data may or may
not require human intervention. The transmission and receipt of the data may require private agreement between the
trading partners to automate the receipt of the data. The total transaction must be in the general form of all ASC
X12 transactions so that an EDI computer system will be able to automatically recognize it as a
Specification/Technical Information Transaction Set and pass it on for processing of the data itself. The transaction
set is not media dependent. The detail area of the Specification/Technical Information Transaction Set provides a
structure which allows for the exchange of a variety of specification information. For example, if the transaction
contains information describing a complete assembly, it would be necessary to include the assembly model, the
models for each of the individual parts, and the associated specifications. In the case of a process it may be
necessary to transmit the specification of the product along with the specifications of the process and raw materials.
This transaction set can also be linked to other transaction sets. This transaction set is not limited to a specific
transmission protocol and uses other standards as applicable where they do not conflict with these requirements for
specification transaction.
Heading:
Pos. Seg.
No. ID
003 ST
Name
Transaction Set Header
Req.
Des.
M
Max.L'se
1
Loop Notes and
Repeat Comments
009
012
015
030
045
048
051
054
057
060
SPI
RDT
NTE
REF
Nl
N2
N3
N4
REF
PER
Specification Identifier
Revision Date/Time
Note/Special Instruction
Reference Identification
M
O
O
Name
Additional Name Information
Address Information
Geographic Location
Reference Identification
Administrative Communications Contact
O
O
O
O
0
O
Emission Inventory Improvement Program
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Detail:
Pos. Seg.
No. ID
003 HL
007 SPI
019 Nl
023 MSG
055 REF
065
071
079
109
113
LX
MEA
REF
093 CID
097 TMD
MEA
REF
Name
Req.
Des. Vlax.Use
Loop Notes and
Repeat Comments
LOOPID-HL
Hierarchical Level
>l
JA-, ~: ,..fc~-
M
nl
LOOP fl>-SPI, -•*:
Specification Identifier
Name
Message Text
>1
O
o
O
LOOP U>-REF
•i^, lf^-j-_-s^rt
Reference Identification
Assigned Number
Measurements
Reference Identification
Characteristic/Class ID
Test Method
O
O
M
O
O
O
cl
c2
161 HL
-
Hierarchical Level
M
165
177
181
187
193
223
225
229
235
237
SPI
Nl
MSG
P1D
MEA
LX
LIN
MEA
DIM
REF
319 HL
323 SPI
339 MSG
Specification Identifier
Name
Message Text
O
O
O
?M^
r#aȣv&>ii"~
Product/Item Description O 1
O >1
Measurements
-Sfc^
Assigned Number
Item Identification
Measurements
Date/Time Reference
Reference Identification
LOOPm-HI*-*
„ .^, >& ,^
Hierarchical Level
M
UX*&.S&"-*&:-•&,•*
^ • ~':<&f - WW »i>!*^l«Si£i,,
Specification Identifier
Message Text
•01
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
345 PID
371 REF
381
387
393
395
LX
MEA
DTM
REF
409 CID
435
437
439
STA
DTM
REF
477 HL
539
545
551
553
LX
MEA
DTM
REF
567 CID
583
585
593
595
597
MEA
DTM
STA
DTM
REF
635 HL
639
655
SPI
MSG
661 PID
725
729
CID
TMD
Product/Item Description
LOOP ID-REF
Reference Identification
O
1
Assigned Number
Measurements
Date/Time Reference
Reference Identification
O
M
O
O
;,-.,£--..-;...•.:>:.. -T&^OTOl
.'.»f_Z,, '3-. ,;','.= --,«*-j ikA-as - *--»•••*
1
LOOTED
Characteristic/Class ID
Statistics
Date/Time Reference
Reference Identification
WJafe^diiwfciCil^
O
O
O
•c l* K '
^yte**i*~
Hierarchical Level
M
481 SPI Specification Identifier
Assigned Number
Measurements
Date/Time Reference
Reference Identification
O
M
O
O
L00^W*'
Characteristic/Class ID O
Measurements O
Date/Time Reference
O
Statistics
Date/Time Reference
Reference Identification
O
O
O
Hierarchical Level
Specification Identifier
Message Text
O
O
LQOfrHX«KB^te*'*JrLj^ V1
Emission Inventory Improvement Program
-------
PROTOTYPE 841 CONVENTION DOCUMENT
Summary:
Pos.
No.
003
Seg.
ID
SE
Name
Transaction Set Trailer
02/97
741
745
751
755
MEA
REF
STA
REF
Measurements
Reference Identification
IS^E:e£.'; -\^~. .-/ j-i:
Statistics
Reference Identification
0 1
0 >1
. •;;/>^fe;;;T ." .".-*' fz-J-' r.;'&?.
6 i " J*'^"
0 >1
Req.
DM.
M
Max.Uit
1
Notes and
Comments
Transaction Set Notes
1. To be meaningful, at least one of the SPI, PID, REF, MEA, EFI or CID loops must be present with each
occurrence of the HL loop.
Transaction Set Comments
1. The HL segment may be used to define the hierarchical relationship of product-related specifications reported
in the associated HL loop. Product-related specifications may refer to the product in its entirety or to subunits
of the product. For example, if the top level refers to an assembly, the second-level HL segment may refer to
parts or subassemblies of the top assembly. This pattern may be repeated as often as required.
2. The CID segment may be used to define either a general class of properties, such as physical properties, or an
individual property within a class. The CID loop allows the user the ability to define specifications such as
the properties of the item or class, the environmental conditions under which the specifications apply, the test
methods to be used, and other parameters related to properties within the current HL hierarchical level.
Emission Inventory Improvement Program
-------
02/57
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
^ J. Transaction Set Header
003
Heading
Mandatory
1
To indicate the start of a transaction set and to assign a control number
1 The transaction set identifier (STO1) used by the translation routines of the
interchange partners to select the appropriate transaction set definition (e.g., 810
selects the Invoice Transaction Set).
Emission Inventory Improvement Program
ittfethe entire transaction set (
tKosfcdaf^fefmc^wate :,, t
rn
••'i ^felJSpft f'r'y^;g"_ggV-' 'fr';r>*SS'?|hl|y
iMM'IlsEji- • --* ''AW^SslSS^SafeiS
tjSsfe -fc^T^Ji^a?'?;.- lf?»%*
^
-------
PROTOTYPE 841 CONVENTION DOCUMENT 02/97
< 841 transaction set identified as 0001 > - f . - I,
Data Element Summary
Ref. Data
Des. Element Name Attributes
» ST01 143 Transaction Set Identifier Code M ID 3/3
Code uniquely identifying a Transaction Set
841 X12.51 Specifications/Technical Information
» ST02 329 Transaction Set Control Number M AN 4/9
Identifying control number that must be unique within the transaction set
functional group assigned by the originator for a transaction set
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
SPI01
OJL A Specification Identifier
009
SPI
Heading
Mandatory
1
Purpose: To provide a description of the included specification or technical data items
1 If either SPI02 or SPI03 is present, then the other is required.
format
Data Element Summary
Data
Element Name
786 Security Level Code
Attributes
M ID 2/2
Code indicating the level of confidentiality assigned by the sender to the
information following
I. Thiselemcafioniamsi
Emission Inventory Improvement Program
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
SPI02
128
SPI03
127
SPI05
791
in the entire transaction set. Select one from die following list:;
00 Company Non-Classified
02 Company Confidential
90 Government Non-Classified
92 Government Confidential
Reference Identification Qualifier X ID
Code qualifying the Reference Identification
1.
iteration
17
2/3
is
''^&,.}^ "
C1 ient Reporting Category
Code assigned by the client to categorize participants
for reporting requirements
~
IX
PE
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Level 1 (EIIP Phase I)
Level 2 (EIIP Phase II)
Level 3 (EIIP Phase III)
01
02
03
Entity Purpose O AN 1/80
The reason for the existence of the data item specified by the electronic data
item independent of its presence in an EDI transaction
SPI06
EMIS
EPA
EPARFP
EPASIP
LOG
NON
PLAN
REGION
SPEC
SUBNON
SUPER
792 Entity Status Code
Annual stationary major source inventory data submittal
EPA required data submittal
Reasonable Further Progress (RFP) inventory data
submittal
Base year State Implementation Plan (SIP) inventory
data submittal
Data submittal between local and state agency
Nonattainment modeling data submittal
Planning inventory (e.g., seasonal) data submittal
Regional area modeling data submittal
Special data submittal
Sub-nonattainment area modeling data submittal
Super-regional area modeling data submittal
O ID 1/1
Emission Inventory improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
SPI07
SPI12
353
Code indicating the current status of the data item specified by the electronic
data item
£7.*?^
A
J
Approved Version
Proposed
A specification that has yet to be accepted or approved
by both trading partners
Mutually Defined
Pi
Transaction Set Purpose Code
Code identifying purpose of transaction set
O ID
554 Assigned Number O NO 1/6
Number assigned for differentiation within a transaction set
Emission Inventory Improvement Program
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
RDT01
RDT02
RDT03
IvU I. Revision Date/Time
012
SPI
Heading
Optional
To specify the revision level of the electronic data item
1 If RDTO1 is present, then RDT02 is required.
2 If RDT06 is present, then RDT05 is required.
3 If RDT03 is present, then at least one of RDT04 or RDT05 is required.
1. This';
Data Element Summary
Data
Element Name Attributes
795 Revision Level Code O ID 1/1
Code indicating the revision or engineering change level of the data items
referred to by the specification number
*> >_<*•»•:. , &.'\K 'f *S>;tK>~
796
374
RDT04
373
H Version Level
Revision Value X AN 1/30
Revision or engineering change level of the data items referred to by the
specification number
Date/Time Qualifier O ID 3/3
Code specifying type of date or time, or both date and time
I. m element indicates tmer^o^
the data bttogr^pOTte^^^^^^^^^SSll^^DfiW&^pi^-^gt^^''^
097 Transaction Creation
196 Start
197 End
Date X DT 6/6
10
Emission Inventory Improvement Program
-------
02/9 7 PRO TO TYPE 841 CONVENTION DOCUMENT
Date (YYMMDD)
1. This element contains the value associated with the code specified in
RDT03.
RDT05 337 Time X TM 4/8
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or
HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-
59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds
are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
r.
,• •, ,, .. ., •
2. When RDT03 is "097?. this erement contains die time this transaction was
- '•• ' - -
Emission Inventory Improvement Program 11
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
NTE01
ii 1 H/ Note/Special Instruction
015
SPI
Heading
Optional
>1
To transmit information in a free-form format, if necessary, for comment or special
instruction
The NTE segment permits free-form information/data which, under ANSI X12
standard implementations, is not machine processable. The use of the NTE segment
should therefore be avoided, if at all possible, in an automated environment.
2. Segment Exam.
NTE02
Data Element Summary
Data
Element Name Attributes
363 Note Reference Code O ID 3/3
Code identifying the functional area or purpose for which the note applies
RPT Report Remarks
352 Description M AN 1/80
A free-form description to clarify the related data elements and their content
12
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
REF03
Reference Identification
030
REF
Heading
Optional
1
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
DO
352 Description
Data Reliability Code
X AN 1/80
A free-form description to clarify the related data elements and their content
Emission Inventory Improvement Program
13
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Nl
Name
045
Nl
Heading
Optional
1
To identify a party by type of organization, name, and code
1 If either N103 or N104 is present, then the other is required.
2 At least one of N102 or N103 is required.
1 This segment, used alone, provides the most efficient method of providing
organizational identification. To obtain this efficiency the "ID Code" (N104) must
provide a key to the table maintained by the transaction processing party.
2 N105 andN 106 further definejhe type of entity in N101.
>'_ _^'?*s_ *3«l¥?"ii Ii:«j . _ V. -F.,,. , ,»"**.• "•-'f^V' -ftS-^
< name (over 35 characters) and of me o
set ami thenanwrbf the inventory preparar
14
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
9. Segment Example: "".-'„•• i
Nl*RL*Smim, Jones, Johnson, Murphy, and *1* 123456789- 1
< name (over 35 characters) and DUNS number an organization that is transmitting the i
transaction set >»^ .^ :_•..".:,.„• , •. ... ,;•'«•" , j
Data Element Summary
Ref. Data
Des. Element Name Attributes
N101 98 Entity Identifier Code M ID 2/2
Code identifying an organizational entity, a physical location, or an individual
L~ Codes "re*antf?I^*appJ|wMPp^T SOURCE reporting only. j
2. This eiememmctfca&mft name o^ being transmitted with j
' ~£ ; — - ' s& •»**, f^-vS..,"'-^ ^-i-*^*™k-^**ia«^^-**^*i-™v*- •• A-*, **> r •* ° 3
• • f_ t< -' 't' •> .w^«r-*i-«<'s'
thisiteration 6
7C™
B4
C6
FE
HA
JU
PI
RC
with data (
transactiCTij
Parent Company
The organizational entity which, by virtue of
organization, ownership, and/or management, exercises
control over a subordinate but separate business entity
,fK.ftg:1R&&r> flf, -S~5Sr>' \r^f »<•_ V*"« '"•*•» i '" *
associatedwrth the data:
Preparer
The firm, organization, or individual who determines
the tax liability from information supplied by the
taxpayer
r^r_-.otme;fiTO(pertaais to Pomt Source 1
only), organi^oi^dfmdividual who prepares the }
inventory dataiS^ute&iom|i™-a. M-/.- . "1
Receiving Location
mdicates me rjarty reviving the data within this I
Emission Inventory Improvement Program
15
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
N102
N103
N104
93
66
67
transaction set
Reporting Location
RL
UX
Name X AN 1/35
Free-form name
1. This element contains the entr^associatGi£^
Identification Code QualifieT "* ** * X ID * 1/2
Code designating the system/method of code structure used for Identification
Code (67) __
"^~''"~™^~t&jji
oner*" •*""*""" ""
1 D-U-N-S Number, Dun & Bradstreet
93 Code assigned by the organization originating the
transaction set
In
Identification Code
Code identifying a party or other code
AN 2/20
16
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
N2
Additional Name Information
Ref.
DCS.
N201
N202
048
Nl
Heading
Optional
2
To specify additional names or those longer than 35 characters in length
tiie location/party entry
Data Element Summary
Data
Element Name
93 Name
Free-form name
93 Name
Free-form name
Attributes
M AN 1/35
O AN 1/35
Emission Inventory Improvement Program
17
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
N3
Address Information
Ref.
Des.
N301
N302
051
Nl
Heading
Optional
2
To specify the location of the named party
1. Thisse
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
N401
N402
N403
N404
N405
IN 4 Geographic Location
054
Nl
Heading
Optional
1
To specify the geographic place of the named party
1 If N406 is present, then N405 is required.
1 A combination of either N401 through N404, or N405 and N406 may be adequate to
specify a location.
2 N402 is required only if city name (N4(M) is in the USA or Canada.
1.
Data Element Summary
Data
Element Name
19 City Name
Free-form text for city name
Attributes
O AN 2/30
156 State or Province Code
O ID
Code (Standard State/Province) as defined by appropriate government agency
116 Postal Code
Code defining international postal zone code excluding punctuation and blanks
(zip code for United States)
1,
26
309
Country Code
Code identifying the country
Location Qualifier
Code identifying type of location
O ID
ID
FI
MS
RG
Federal Information Processing Standards (FIPS) 55
(Named Populated Places)
Metropolitan Sampling Area (MSA) Region Code
Region Code
Qualifies a code that identifies a geographic area where
transportation rates apply
Emission Inventory Improvement Program
19
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
N406
RJ
1. This code does riot^app^wifc BIOGENICSOURCE, j
reporting. : ',-;;-• -:* "';'"* •.t4-J*-5*%iS%iA;';^»J^f & .,,..'" . ""'j
Region
A geographical section of the country
Indicates an EPA)
310 Location Identifier
Code which identifies a specific location
I.
A-a^^Xf^t.f^.. _ * «g +,, . -v-. -j
O AN 1/30
03MOD
03OTR
CO
O3EXT
O3MAR
O3SER
O3SEV1
03SEV2
O3UNC
PM10
PM25
Ozone moderate
Ozone Transport Region
Carbon Monoxide
Ozone extreme
Ozone marginal
Ozone serious
Ozone severe 1
Ozone severe 2
Ozone unclassified
Paniculate Matter 10
Paniculate Matter 2.5
20
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
lvlL.r Reference Identification
057
Nl
Heading
Optional
>1
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
1 ."• Tnis segment provides me map-specific
specified HI
' ." .T* js :'-^M^^^^^i^y^^M^^^
• JU A-'1i^^^^^^-;^^^?^^@i't^i®l
—^ - . «_. * ^ . **>«-4^H^'^*>&.^*.»-r
• ^**^i^"_« _ _ *_ _ , _" L^ a ?'1_? *^'^"^- «-
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
6E
6J
UQ
UU
WH
zv
zx
zz
Map Reference
Census Tract
Section Number
The number corresponding to a section within a
township and range
Township Number
Master Reference Link
Indicates highway link/Titmsporiation Assessment Zone j
Block
Number assigned by a regulatory agency which
describes a producing oil or gas offshore area
^ , .
County Code
* - •• ; .,, <.,,*, .,,.*.*^^*
Mutually Defined
Indkates Air Basin data
Emission Inventory Improvement Program
21
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
REF02
REF03
REF04
C04001
C04002
C04003
127
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
1. This element contains the vahie associated with the code specified m".£^' *
REFOLD;;,,,:,. ; ,
2. WnenREF01is"M
Select
Static Grid
—*<" 'X+.'&Z'^vw*-;*,
tncacafinu
Line
Point
Polygon
352
02
03
04
Description X AN 1/80
A free-form description to clarify the related data elements and their content
C040 Reference Identifier O
To identify one or more reference numbers or identification numbers as
specified by the Reference Qualifier
r:
128
Reference Identification Qualifier
Code qualifying the Reference Identification
M ID
Multiple Listing Service Map Y Coordinate
Longitude expressed in Degrees, Minutes and Seconds
1. Wneb-t
.ju ^ssrsssuff
Universal Transverse Mercator - North
127
JN
LK
XU
Reference Identification M AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier^
CTnlse?
128
ID 2/3
Reference Identification Qualifier
Code qualifying the Reference Identification
^^
**S«»i^^*«^«l^4***B^j^ ,/.,,! - > * jfo ,- •*
22
Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENT/ON DOCUMENT
C04004
C04005
C04006
127
128
127
from the following list: ,, ,.c»u.,-=;«.£"•-li'?X^.L-'.t "A-i*-.-.
JM Multiple Listing Service Map X Coordinate
1. When this cwie is appl^REF04C0400rajde^ vl
"JN" must be applied^* j'-M/^iJ Clc:''iiiJi£^*3l
LQ Latitude Expressed in Degrees, Minutes and Seconds
1. Whei this code is applied, REFQ4 C04001 code > -^
"M^vS'^^W ^PRPe^»:;4-.'lF.r ''•£?•£ ^^&:^&^'^:Z^a"f''fM
XV Universal Transverse Mercator - East
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Reference Identification Qualifier
Code qualifying the Reference Identification
ID 2/3
Universal Transverse Mercator - Zone
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Emission Inventory Improvement Program
23
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
DCS,
PER01
PER02
PER03
A H
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
PER04
364
PER05
365
PER06
364
EM
EX
FX
TE
Electronic Mail
Telephone Extension
Facsimile
Telephone
Communication Number X AN 1/80
Complete communications number including country or area code when
applicable
Communication Number Qualifier X ID 2/2
Code identifying the type of communication number
AP
EM
EX
FX
TE
Alternate Telephone
Electronic Mail
Telephone Extension
Facsimile
Telephone
Communication Number X AN 1/80
Complete communications number including country or area code when
applicable
Emission Inventory Improvement Program
25
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
HL
Hierarchical Level
Notes:
003
HL
Detail
Mandatory
1
To identify dependencies among and the content of hierarchically related groups of data
segments
The HL segment is used to identify levels of detail information using a hierarchical
structure, such as relating line-item data to shipment data, and packaging data to
line-item data.
HL01 shall contain a unique alphanumeric number for each occurrence of the HL
segment in the transaction set. For example, HL01 could be used to indicate the
number of occurrences of the HL segment, in which case the value of HL01 would
be "1" for the initial HL segment and would be incremented by one in each
subsequent HL segment within the transaction.
HL02 identifies the hierarchical ID number of the HL segment to which the current
HL segment is subordinate.
HL03 indicates the context of the series of segments following the current HL
segment up to the next occurrence of an HL segment in the transaction. For example,
HL03 is used to indicate that subsequent segments in the HL loop form a logical
grouping of data referring to shipment, order, or item-level information.
HL04 indicates whether or not there are subordinate (or child) HL segments related
to the current HL segment.
26
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Ref.
Des.
HL01
HL03
HL04
LX*1~:V ,-'. . - , ' ' -,
MEA*CT**500*ffi~ > „
< company sending non-classified information has a local identification number of X123,
produces steel, is a point source with a SIC code of 33, and employs 500 people >;
.
stransactioa set that contains site/source-level information; *
Data Element Summary
Data
Element Name
628 Hierarchical ID Number
Attributes
M AN 1/12
A unique number assigned by the sender to identify a particular data segment
in a hierarchical structure
735 Hierarchical Level* Code M ID 1/2
Code defining the characteristic of a level in a hierarchical structure
4 Group
Code identifying a group of charges on the bill
736 Hierarchical Child Code "6 ID™" i'/'l
Code indicating whether if there are hierarchical child data segments
subordinate to the level being described
1 Additional Subordinate HL Data Segment in This
Hierarchical Structure
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
SPI01
SPI02
ijJL A Specification Identifier
007
SP1
Detail
Optional
I
To provide a description of the included specification or technical data items
1 If either SPI02 or SPI03 is present, then the other is required.
-confidentiality
- site1 identificati0n«inj
Data Element Summary
Data
Element Name Attributes
786 Security Level Code M ID 2/2
Code indicating the level of confidentiality assigned by the sender to the
information following
" ••
00
02
90
92
Company Non-Classified
Company Confidential
Government Non-Classified
Government Confidential
128
Reference Identification Qualifier
Code qualifying the Reference Identification
1.
ID 2/3
2. This element indicatothe^type
28
Emission Inventor/ Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
SPI03
SPI05
127
791
reported with this iteration of the loop. Select one from the following list J
1 J Facility ID Number
a site "
G5
1.
Provider Site Number
A unique code identifying the provider's specific
department or office location for internal routing of
electronic claims
«• >-.»; «*'t-j;..*-*1V '"~i**" ^v^'-^a^'t*^'^**'*"^'-*^-^!^^ — ft^ *«t * ^-
Indicates the state identificatiott codeAtesonption for a
' ;_i,f' •*• ^ :*.*"tT^rw*!... ~ -- •*?; ".^.x-X^4*«y? ,t*l'i^iJfiiiL2.s>,-x^i8'^.;_Et ^_ *^'..t*"r ** '•^
IX
PE
Plant Number
L
Locally Assigned Control Number
WF
ZZ
(<
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Entity Purpose O AN 1/80
The reason for the existence of the data item specified by the electronic data
item independent of its presence in an EDI transaction
tswi
Emission Inventory Improvement Program
29
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
N101
N102
N103
N104
Nl Name
019
SPI
Detail
Optional
To identify a party by type of organization, name, and code
1 If either N103 or N104 is present, then the other is required.
2 At least one of N102 or N103 is required.
1 This segment, used alone, provides the most efficient method of providing
organizational identification. To obtain this efficiency the "ID Code" (N104) must
provide a key to the table maintained by the transaction processing party.
2 N105 and N106 further define the type of entity in N101.
Data Element Summary
Data
Element Name Attributes
98 Entity Identifier Code M ID 2/2
Code identifying an organizational entity, a physical location, or an individual
7C Place of Occurrence
93 Name X AN 1/35
Free-form name
66 Identification Code Qualifier X ID 1/2
Code designating the system/method of code structure used for Identification
Code(67)
" " " Tfcil
67
93 Code assigned by the organization originating the
transaction set
Identification Code X AN 2/20
Code identifying a party or other code
«*£*•» 1&*
i in the N104 c
30
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Ref.
DejL
MSG01
Message Text
023
SPI
Detail
Optional
To provide a free form format that would allow the transmission of text information
1 MSG02 is not related to the specific characteristics of a printer, but identifies top of
page, advance a line, etc.
Notes: 1. This segment provides a site/source-levermeasage.
2, Segment Example:, fi
Data Element Summary
Data
Element Name
933 Free-Form Message Text
Free-form message text
Attributes
M AN 1/264
Emission Inventory Improvement Program
31
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
REF02
REF04
Reference Identification
055
REF
Detail
Optional
1
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
]. Thisloop/se^nenfpro
Classrfr
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
System Number
A unique number assigned by the manufacturer to
identify the initial computer system sold to the customer
127
IJ Standard Industry Classification (SIC) Code
Reference Identification X AN
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
t.ta
REFW
1/30
-
one front
"""o "
02
03
04
05
C040
Point Source
Area Source
Mobile Source
Biogenic Source
Nonroad Engines and Vehicles Source
Reference Identifier O
To identify one or more reference numbers or identification numbers as
specified by the Reference Qualifier
1. This composite & applied^
- *
32
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
2. This composite is only applied when REF02 is "04": r V -
3. When REF02 is "04", this composite provides a biogenic source category.
» C04001 128 Reference Identification Qualifier M ID 2/3
Code qualifying the Reference Identification
1. This element indicates a biogenic source category. ?**>-;•- :-: -/.
_.iK .* *(i»i ~ -..•" lint V -A.j-g ~ '.s*.. .'«;.<, ... • *,-.' ,x ' • * ™^^ " . 4 4* >*».,,-
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
» LX01
Assigned Number
065
LX
Detail
Optional
1
To reference a line number in a transaction set
NONROAIX and BIOGENIC
Data Element Summary
Data
Element Name Attributes
554 Assigned Number M NO 1/6
Number assigned for differentiation within a transaction set
34
Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
MEA01
JVLH/A Measurements
071
LX
Detail
Mandatory
To specify physical measurements or counts, including dimensions, tolerances, variances,
and weights (See Figures Appendix for example of use of COO 1)
1 If MEA05 is present, then MEA04 is required.
2 If MEA06 is present, then MEA04 is required.
3 Only one of MEA08 or MEA03 may be present.
4 If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
5 At least one of MEA03 MEA05 MEA06 or MEA08 is required.
1 MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
1 When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
«DNROAD,andBK
Data Element Summary
Data
Element Name
Attributes
737 Measurement Reference ID Code O ID 2/2
Code identifying the broad category to which a measurement applies
ri-MM «tf ,*-;fi,'\»..S™,.< t i-.'v; « • « ^ -"*-• -_ _n_ H- i i_ ,, • n_ _n_ jTjnjJrua-y <•
PO
changeabl^defiDitHUi aikicfuuiges with respect to it£%§fjj
Emission Inventory Improvement Program
35
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
MEA02
MEA03
MEA04
738
739
1. This code is applied to AREA, NONROAD, and
BIOGENIC SOURCE nqxofag only;; -^ '":,,.-*
Measurement Qualifier 6* ID 1/3
Code identifying a specific product or process characteristic to which a
measurement applies
I, T&K element is:appliedwitf AI^KOKROAD, and KbC£NICf?ff'-
cIoncnt mdicatesthedirrcnon
""
'.-; :>• &*• r^'-f'T'. -j','*-**- -'liet»jjte'
a,m^,ffif?ran^m€asorraa^^-
"**"HT """*H7ight
WD Width
Measurement Value
The value of the measurement
C001 Composite Unit of Measure X
To identify a composite unit of measure (See Figures Appendix for examples
of use)
» C00101 355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
03
DD
DH
DK
EA
IE
Seconds
Degree
Miles
Kilometers
Each
MJ
Minutes
36
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
DCS.
REF01
REF02
REF03
REF04
JtvlLr Reference Identification
079
LX
Detail
Optional
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
1. ThisTsef!
SOURCE reporting
2. This segment brovidesinap reference data (grid start point) and projection s
name associated with dynamic grids as specified in the MEA01 (prior segment) code is,,|
K^ DTTTTnt i«.wria»<^/v\iMhfna*ir«rio VifPITC'rtit /
€04003,004004,
, ;2**,sx&&:'ysim
4.
.- .-.. .. , . ,
pomfat 54 degrees foogitude an
degrees I
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
,-£&\ V-^l
sappjropnate combinations of REF04 C0400H v i|
l^tid^ro^jmust^applfedEj-^.;; _ /J._,4*J
6E Map Reference
127 Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
^^^^^^^^SftH5ST."f;;:?;f?tl
Dynamic Grid
»a dynamic grid which has a"
. - af ^ * •".- -* ,*• i <• * »™
05
s-.ii'r.-i.-sprtirvi
c'-iSSSSKU/ta
06 Projection System Name
352 Description X AN 1/80
A free-form description to clarify the related data elements and their content
1.
C040 Reference Identifier
^
O
Emission Inventory Improvement Program
37
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
C04001
C04002
C04003
To identify one or more reference numbers or identification numbers as
specified by the Reference Qualifier
1. This composite is only applied when REF02 is "05f J;,,;, ^t.> ' I
2. This composite provides map coordinate^ data associated with REFOl.
128 Reference Identification Qualifier M ID 2/3
Code qualifying the Reference Identification
r coordinate.
' ;".tt^iati'jj**^«<&s-«i
Multiple Listing Service Map Y Coordinate
Longitude expressed in Degrees, Minutes and Seconds
Universal Transverse Mercator - North
128
t. This element it
"JN~~
LK
XU
127 Reference Identification M AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Reference Identification Qualifier
Code qualifying the Reference Identification
X ID 2/3
C04004
C04005
C04006
127
128
127
Multiple Listing Service Map X Coordinate
fl
Latitude Expressed in Degrees, Minutes and Seconds
Universal Transverse Mercator - East
JM
LQ
XV
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Reference Identification Qualifier X ID 2/3
Code qualifying the Reference Identification
Universal Transverse Mercator - Zone
C
XW
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
38
Emission Inventory Improvement Program
-------
02/3 7 PRO TO TYPE 841 CONVENTION DOCUMENT
I. This element contains the map zone associated with C04005.
Emission Inventory Improvement Program 39
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
CID
Characteristic/Class ID
Notes:
Ref.
Des.
CID03
CID04
093
CID
Detail
Optional
1
To specify the general class or specific characteristic upon which test results are being
reported or are to be taken
1 If CID06 is present, then both CID03 and CID04 are required.
2 If CID07 is present, then at least one of CID04 or CID05 is required.
3 If either CID03 or CID04 is present, then the other is required.
4 At least one of CIDOI CID02 CID04 or CID05 is required.
I1.-
CID06 specifies the individual code list of the agency specified in CID03.
CID07 refers to whether or not the characteristic identified in CID04 or CID05 or
both is affected by the product change. If it is affected, the value is "Y". A value of
"N" is used when it is known that it will not be affected. Any other value indicates it
is indeterminate.
Data
Element
559
Data Element Summary
Name
Agency Qualifier Code
Code identifying the agency assigning the code values
Attributes
X ID 2/2
751
EP United States Environmental Protection Agency (EPA)
Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
40
Emission Inventory Improvement Program
-------
02/97 PROTOTYPE 841 CONVENTION DOCUMENT
1. This element indicates the major class of chemical mechanism being
reported. , \ '
MONO Monoterpines
OVOC Other Volatile Organic Compounds
VOC Volatile Organic Compounds
CID05 352 Description X AN 1/80
A free-form description to clarify the related data elements and their content
1. This element contains a descriptionrpf any major chemical mechanism not
supplied in.CID04/ . •"'>£ '. ,vl --^.'V.v'• •'" .- '
** , , « *v -«„* ^ ,, i^K* fe,j ^^v*-w,^^«ffl,si**: •AZb - .
Emission Inventory Improvement Program 41
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
TMD01
TMD06
TMD Test Method
097
CID
Detail
Optional
>1
To describe the nature of the test performed
1
2
1
2
1
1.
If TMD09 is present, then TMD02 is required.
If either TMD02 or TMD03 is present, then the other is required.
TMD07 is the date of the test method as assigned by the issuing organization.
TMD08 is the document revision number.
TMD09 specifies the individual code list of the agency specified in TMD02.
Data
Element
750
Data Element Summary
Name Attributes
Product/Process Characteristic Code O ID 2/3
Code identifying the general class of a product or process characteristic
352
Description O AN 1/80
A free-form description to clarify the related data elements and their content
42
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
JVlJirA Measurements
Semantic Notes:
Comments:
Ref.
DCS.
MEA03
MEA04
C00101
109
MEA
Detail
Optional
1
To specify physical measurements or counts, including dimensions, tolerances, variances,
and weights (See Figures Appendix for example of use of COO 1)
1
2
3
4
5
1
1
Notes: I.
2.
If MEA05 is present, then MEA04 is required.
If MEA06 is present, then MEA04 is required.
Only one of MEA08 or MEA03 may be present.
If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
At least one of MEA03 MEA05 MEA06 or MEA08 is required.
MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
r^fe.* "jsi-TT0 , "*-.j*-*^;r:J*.7'£'*^ - .
3. This segmentprbv
surrogate mfbrmatio
'""'
4. Loop (segments
*v.y*,&£3&6S
specific chenu
V/TT|1 ~T<
4. Segment
Data Element Summary
Data
Element Name
739 Measurement Value
The value of the measurement
I. ThiFelement contains
C001
355
Attributes
X R 1/20
Composite Unit of Measure X
To identify a composite unit of measure (See Figures Appendix for examples
of use)
1. This composite provides -^m^ofjS»saBJ^^»CK5ia^fwrti6BffiA03» "
Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
1. This element provides the unit of measure associated with MEA03.
UN " "~ *""Unit~ " ~ """ ' ."
Emission Inventory Improvement Program
43
-------
PROTOTYPE 84 7 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
REF03
rvJL-r Reference Identification
113
MEA
Detail
Optional
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
1
Attributes
M ID 2/3
19 Pollutant
352 Description X AN 1/80
A free-form description to clarify the related data elements and their content
44
£mission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
U.L/ Hierarchical Level
161
HL
Detail
Mandatory
1
To identify dependencies among and the content of hierarchically related groups of data
segments
1 The HL segment is used to identify levels of detail information using a hierarchical
structure, such as relating line-item data to shipment data, and packaging data to
line-item data.
2 HL01 shall contain a unique alphanumeric number for each occurrence of the HL
segment in the transaction set. For example, HL01 could be used to indicate the
number of occurrences of the HL segment, in which case the value of HL01 would
be " 1" for the initial HL segment and would be incremented by one in each
subsequent HL segment within the transaction.
3 HL02 identifies the hierarchical ID number of the HL segment to which the current
HL segment is subordinate.
4 HL03 indicates the context of the series of segments following the current HL
segment up to the next occurrence of an HL segment in the transaction. For example,
HL03 is used to indicate that subsequent segments in the HL loop form a logical
grouping of data referring to shipment, order, or item-level information.
5 HL04 indicates whether or not there are subordinate (or child) HL segments related
to the current HL segment.
Notes: 1. This leveVwopM
- confli
- physical imit Identification
- geographic Iocs 1*-*?"'-' -"""-^- -'
-physical-!
- physical ra
- emission:
- emissic
-control
1!
- control xrnft
-'•:• -
tf»b*u^,oBfy>€*l<:'~/:JI -.,u^ •> * "•
:»owi«itaib&tceonfy>^^.-j^;;;,
:•> ^j,'^^^_-i._^^^,
- physical oratOfxaraiKmalst^^ -.;••-*-• - .
- emission p^ data^Cppioi^ a \,-:_, >,; ' < •
2. ThistooiHii^telMfiliM^ .. •
3. This note pertaffis toPOM^ SOURC^ OTly£"Examples of physical-level data are
:< , ', &? •• v *" _ * ">,Ji"J ,.;**V ,l,u ' llv?" Z-f. ^>^ . , '/*••"'"_ ' - '-,>>••> ,>. ;
ernissn
"•'''ji ••'•nie'-r'-/' -• *,-.?,
4. TTiiswrt).,.„..,_..,..„,.,...........^...^. ;.^ ^ . .__
only. Examples of physical-level data are geographic subdivision (grid; cell), county,
subcountyyUghwaylinkretc^'Cs"-':^-:;:^'-^-11 '','^~fr'-.,"\\•'"•••'•, •;-'."'. ]'*-*
5. Loop (segments HL, SPf^NI, MSG, P!D,ME&. DC LIN, MEA, DIM, REF>
Example: * •-'• " >••".'•; -"•"-..«-•> "•••s^t .%.--,.•;~ . • ."•
Emission Inventory Improvement Program
45
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Ref.
Des.
HL01
HL02
HL03
HL04
HL*02*Ol*5*l~
SPI*00*G5*PA J23**Brick 43-
PID»X*PP*EP*ai*Brict
V -•„«•* ' y szJy$£t-,?% - - '."•„' >„ r '» ftr-:g^W^'J 2U|-.:*S4'i* * ^*-.';;'^" ,'- 11
s?^>:?*.t^rV4v^;:-- - -s ..-- •-•' *"i3«*^r^^,v;-^^|
x^i23^6^cife *',: v. :.-.. ^ v_ i., ^»:gft:^^- ¥.:o.::-.:.? vjrvi
Data Element Summary
Data
Element Name Attributes
628 Hierarchical ID Number M AN 1/12
A unique number assigned by the sender to identify a particular data segment
in a hierarchical structure
734 Hierarchical Parent ID Number O AN 1/12
Identification number of the next higher hierarchical data segment that the data
segment being described is subordinate to
735
Hierarchical Level Code M ID 1/2
Code defining the characteristic of a level in a hierarchical structure
736
Category
Code identifying the sub-division of the group
Hierarchical Child Code O ID 1/1
Code indicating whether if there are hierarchical child data segments
subordinate to the level being described
1 Additional Subordinate HL Data Segment in This
Hierarchical Structure
46
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
O± JL Specification Identifier
165
SPI
Detail
Optional
I
Purpose: To provide a description of the included specification or technical data items
Syntax Notes: 1 If either SPI02 or SPI03 is present, then the other is required.
Semantic Notes:
Comments:
Notes: I. This loop proyfdes thefbll(
' &
- cot^B^^-iia^B^^i^^M^M^^^^^^ -Kpr&.s'*.
- physical imit identification infbi
Ref.
Des.
SPI01
SPI02
- .i-
2. This segment provides the
physical unit identirlcation infc
Data Element Summary
Data
Element Name Attributes
786 Security Level Code M ID 2/2
Code indicating the level of confidentiality assigned by the sender to the
information following
1 . * Tni^eleffient contains thctCofll^^ the datasi -
00
02
90
92
Company Non-Classified
Company Confidential
Government Non-Classified
Government Confidential
128 Reference Identification Qualifier
Code qualifying the Reference Identification
I. This element applies w
ID 2/3
Emission Inventory Improvement Program
47
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
SPI03
SPI05
791
2. This element indicates the type of physical unit identifier being reported
with this iteration of the loop. Select one from the f "
G5
Provider Site Number
A unique code identifying the provider's specific
department or office location for internal routing of
electronic claims
Indicates me state'Bettf
Item Number
IX
PE
WF
127 Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Locally Assigned Control Number
Entity Purpose O AN 1/80
The reason for the existence of the data item specified by the electronic data
item independent of its presence in an EDI transaction
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
N101
N102
N103
N104
Nl Name
177
SPI
Detail
Optional
>1
To identify a party by type of organization, name, and code
1
2
If either N 1 03 or N 104 is present, then the other is required.
At least one of N 1 02 or N 1 03 is required.
This segment, used alone, provides the most efficient method of providing
organizational identification. To obtain this efficiency the "ID Code" (N104) must
provide a key to the table maintained by the transaction processing party.
N 1 05 and N 1 06 further define the type of entity in N 1 0 1 .
in the
< locarion roUy detaUed in the header with a pointer/identifier nurnber
Data Element Summary
Data
Element Name
98 Entity Identifier Code
Attributes
93
66
M ID 2/2
Code identifying an organizational entity, a physical location, or an individual
'^i^1^iK^^l^jira*^«v:ift^il^!i^j«jfciAA*^tf j^^^^^^^—'•CT^^^J^^tj'^^'^!'' IPti^T '^jjTfcf "j^m^^nZ^^i'^^^f^jt' * " * J^"^5
. • vinis element: inoicaKS me gejo^Bpiucr locaooa~ miormaupn associated wrtnt
t^^^SliS^Miii^^^l^^^l^
7C Place of Occurrence
Name X AN 1/35
Free-form name
Identification Code Qualifier X ID l/2~^
Code designating the system/method of code structure used for Identification
Code (67)
L
67
93 Code assigned by the organization originating the
transaction set
Identification Code X AN 2/20
Code identifying a party or other code
i. ThiseremOTtpomtstomefceai^
code associated wim it specific location/party^ The information in this element
directly matches the Mcinnatioam meN104 contained within the header Nl
Emission Inventory Improvement Program
49
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Pes.
» MSG01
MSG Message Text
181
SPI
Detail
Optional
To provide a free form format that would allow the transmission of text information
1 MSG02 is not related to the specific characteristics of a printer, but identifies top of
page, advance a line, etc.
K3tiHJ&"'~
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
PID
Comments:
Notes:
Ref.
Des.
PID01
Product/Item Description
187
PID
Detail
Optional
1
To describe a product or process in coded or free-form format
1
2
3
4
1
2
3
If PID04 is present, then PID03 is required.
If FIDO? is present, then PID03 is required.
If FIDOS is present, then PID03 is required.
At least one of PID04 or PID05 is required.
Use PID03 to indicate the organization that publishes the code list being referred to.
PID04 should be used for industry-specific product description codes.
PID08 describes the physical characteristics of the product identified in PID04. A
" Y" indicates that the specified attribute applies to this item. A "N" indicates it does
not apply. Any other value is indeterminate.
If FIDO 1 = ' ' F", then PID05 is used. If FIDO 1 = ' ' S", then PID04 is used. If FIDO 1 =
"X", then both PID04 and FIDOS are used.
Use PID06 when necessary to refer to the product surface or layer being described in
the segment.
FIDO? specifies the individual code list of the agency specified in PID03._
I. This
- physical unit'
r ' -;. isxf'-l,
- emission janit
- control
- grid/cdunl¥;att«
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
PID02
750
PID03
559
PID04
751
PID05
352
Product/Process Characteristic Code O ID 2/3
Code identifying the general class of a product or process characteristic
1. This element indicates physical unit ^pe Monhationr' if * 71ft ?"
PP Process/Production Unit
Agency Qualifier Code X ID 2/2
Code identifying the agency assigning the code values
1. This element identifies me ^
~" "** "' ^^B.xWii'OrV^^lj* ""'"
EP United States Environmental Protection Agency (EPA)
Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
Stack
Control Unit
Emission Unit
Storage Tank
Vehicle Group
Process
Flare
Equipment Leak Fugitives
Loading
Cooling Towers
Incinerators
Accidental Release/Upset
Start Up/Shut Down
Wastewater
Area
Other
16
Description X AN 1/80
A free-form description to clarify the related data elements and their content
52
Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
lV±jLA. Measurements
193
PID
Detail
Optional
To specify physical measurements or counts, including dimensions, tolerances, variances,
Syntax Notes:
Semantic Notes:
Comments:
Notes:
and weights (See Figures Appendix for example of use of COO 1)
1 If MEA05 is present, then MEA04 is required.
2 If MEA06 is present, then MEA04 is required.
3 Only one of MEA08 or MEA03 may be present.
4 If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
5 At least one of MEA03 MEA05 MEA06 or MEA08 is required.
1 MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
1 When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
I.
provides em
parameter
segment).?
MEA*PDfi
< physical
Data Element Summary
Ref.
Des.
MEA01
Data
Element Name
737 Measurement Reference ID Code
Code identifying the broad category to which
Attributes
O ID 2/2
a measurement applies
BA
CT
PD
Base Point
""•rsr-JKsrr &»» -r ^-z^n- *, *&m
--*-^-»f« - *•>",- t£ * *<••'* ^S
^.3*8jfl^-* H - " /•';: ^'fxt*;
rast.%.i?w*«i. "r^ *?X,^ss: — »^.s?
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
MEA02
MEA03
738
code is defined as indicating grid or county area data,
TE Temperature
Indicates exit gas temperature " "£<•rj -^-j.i-.v "'-*• ', i-*jrf ™*<*.i£. 'vS, *" -s «5*X
Measurement Qualifier O ID 1/3
Code identifying a specific product or process characteristic to which a
measurement applies
^mj^m^mmgGEmcf^'\
SOURCE Wx?S9?nlif!p&8M^^ be applied* ',*
5F
FR
ID
M4
PRL
VOL
ZZZ
739 Measurement Value
The value of the measurement
Height Above Ground
Flow Rate
Inside Diameter
Area
Product Level
X R
1/20
MEA04 C001 Composite Unit of Measure X
To identify a composite unit of measure (See Figures Appendix for examples
of use)
ft ^^h^Wt-y-t-fr**f-4,jtai»*i»ii»*,O,Jt ;"*^"*Jf > x«,j4Jr*v*
C00101 355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
•which a measurement has been taken
2L
41
8U
EA
FA
FS
Cubic Feet Per Minute
Rate of flow
Meters Per Second
Measure of linear speed
Square Kilometer
Each
t
Fahrenheit
Feet Per Second
54
Emission Inventory Improvement Program
-------
02/97 PROTOTYPE 841 CONVENTION DOCUMENT
Measure of linear speed
FT Foot
HQ Hectare
PI Percent
SM Square Meter
Emission Inventory Improvement Program 55
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
LX01
Assigned Number
223
LX
Detail
Optional
1
To reference a line number in a transaction set
1. Thiiloop/segn
Data Element Summary
Data
Element Name Attributes
554 Assigned Number M NO 1/6
Number assigned for differentiation within a transaction set
56
Emission Inventory Improvement Program
-------
02/57
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
LIN
Item Identification
Semantic Notes:
Comments:
Notes:
Ref.
DCS.
LIN01
LIN02
LIN03
225
LX
Detail
Optional
1
To specify basic item identification data
1 If either LIN04 or LINOS is present, then the other is required.
2 If either LIN06 or LIN07 is present, then the other is required.
3 If either LIN08 or LIN09 is present, then the other is required.
4 If either LIN 10 or LIN 11 is present, then the other is required.
5 If either LIN 12 or LIN 13 is present, then the other is required.
6 If either LIN14 or LIN15 is present, then the other is required.
7 If either LIN 16 or LFN17 is present, then the other is required.
8 If either LIN 18 or LIN 19 is present, then the other is required.
9 If either LIN20 or LIN21 is present, then the other is required.
10 If either LIN22 or LIN23 is present, then the other is required.
11 If either LIN24 or LIN25 is present, then the other is required.
12 If either LIN26 or LIN27 is present, then the other is required.
13 If either LIN28 or LIN29 is present, then the other is required.
14 If either LIN30 or LIN31 is present, then the other is required.
1 LIN01 is the line item identification
1 See the Data Dictionary for a complete list of ID's.
2 LIN02 through LIN31 provide for fifteen (15) different product/service ID's for each
item. For Example: Case, Color, Drawing No., UPC No., ISBN No., Model No.,
SKU.
and NONROAD SOURCETpjorting onfy.
"* ~J££v ~ v^.r*3w'*" ' ,J**j< .^-^^^c-'^'t^'v^^^y.ii"
ion associated with acontrolunit"
4'-?3& -'--:' 'f uV'>S-^'^/'i*t*'i«
"" *'""' ''"ft
I. TDIS
• *
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Identifying number for a product or service
1. When LIN02 is "CO", this element contains a Chemical Abstract Service
(CAS) number. - .. , r :
' "' ' • .•••'-•••'' - .- „ " *:;,;,? : ",*'-"
2. .When LIN02 is "Z2T, this element contains a pollutant code.: Select one;
from me foHpwmg list: >;* , ••- ['-.*K.-r''~*f-, ' •-• /-yf/iX: -..-iX- ;•».'
CO Carbon monoxide
HC Hydrocarbons
ISO Isoprene
MONO Monoterpines
NMHC Norunethane hydrocarbons
NMOC Nonmethane organic compounds
NMOG Nonmethane organic gases
NO Nitric oxide
NOX Nitrogen oxides
NOY Nitrogen oxides plus secondary compounds
OVOC Other volatile organic compounds
PB Lead
PM Paniculate matter
PM10 Paniculate matter >= 10
PM25 Paniculate matter >= 2.5
ROG Reactive organic gases
SOX Sulfur oxides
TOG Total organic gases
VOC Volatile organic compounds
58
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
DCS.
MEA02
MEA03
Measurements
229
LX
Detail
Mandatory
>1
To specify physical measurements or counts, including dimensions, tolerances, variances,
and weights (See Figures Appendix for example of use of COO 1)
1 If MEA05 is present, then MEA04 is required.
2 If MEA06 is present, then MEA04 is required.
3 Only one of MEA08 or MEA03 may be present.
4 If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
5 At least one of MEA03 MEA05 MEA06 or MEA08 is required.
1 MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
1 When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
1. This segment i
2. This segment
segment (prior
3.
MEA**COT*
< control
Data Element Summary
Data
Element Name
738 Measurement Qualifier
Attributes
O ID 1/3
Code identifying a specific product or process characteristic to which a
measurement applies
i£l
739
COT
DIS
FR
IGR
VOL
Measurement Value
The value of the measurement
Content
The amount of specified material contained
Dispersion
The ease with which one substance mixes with another
Input Gas Rate
Volume of gas input during a 24-hour test period
. *».T ^T"*T*T»:".X-*"-*"V*"V"?p3ps>?J*" •v£*#**"^f+
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
1. This element contains the value associated with MEA02.
MEA04 C001 Composite Unit of Measure X
To identify a composite unit of measure (See Figures Appendix for examples
of use)
1. This composite provides, the unit of measure asspciatedlyndJ-MEAOJ^j 'r •'
C00101 355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
I. This elemetstcontams the unit of measure associated with MEA03. Select;
one
21
2L
41
4U
4W
BR
BY
CE
CF
EA
FA
FS
FT
GA
HM
HR
HT
MR
PI
SF
T6
nm^M
i * SfeiSM
British Thermal Units (BTUs) Per Hour
British thermal units per hour
Cubic Feet Per Minute
Rate of flow
Meters Per Second
Measure of linear speed
Pounds Per Hour
Rate of flow
Ton Per Hour
Rate of flow
Barrel
British Thermal Unit (BTU)
Centigrade, Celsius
Cubic Feet
Each
Fahrenheit
Feet Per Second
Measure of linear speed
Foot
Gallon
Miles Per Hour
Hours
Half Hour
Meter
Percent
Square Foot
Thousand Gallons
60
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
»
Ref.
Des.
DTM01
DTM02
DTJVl Date/Time Reference
235
LX
Detail
Optional
>1
To specify pertinent dates and times
1 If either DTM06 or DTM07 is present, then the other is required.
2 At least one of DTM02 DTM03 or DTM06 is required.
' ^-*-^*---^
KjggjURGB reporting:5-?•
operational status of a physical
igKfv ^xjgt.fts-1
^^'^f^f!!^4'!
Data Element Summary
Data
Element Name Attributes
374 Date/Time Qualifier M ID 3/3
Code specifying type of date or time, or both date and time
196
373 Date
Date (YYMMDD)
Start
X DT 6/6
DTM05 624 Century O NO 2/2
The first two characters in the designation of the year (CCYY)
Emission Inventory Improvement Program
61
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
REF02
Reference Identification
237
LX
Detail
Optional
>1
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
127
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
A
B
C
D
Operating
Under Construction
Under Modification
Mothballed
Indicatd'tbaf
Closed - Dismantled/Removed From Site
62
Closed - Remaining On Site
Emission Inventory Improvement Program
-------
02/3 7 PRO TO TYPE 841 CONVENTION DOCUMENT
Indicates that a unh remains on site with no possibility
of reuse " - ""• '/•""-.. ";*" '':"jL". ',
REF03 352 Description X AN 1/80
A free-form description to clarify the related data elements and their content
t. This element contains a textual description'associated with REF02.
Emission Inventory Improvement Program 63
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Hierarchical Level
319
HL
Detail
Mandatory
1
To identify dependencies among and the content of hierarchically related groups of data
segments
The HL segment is used to identify levels of detail information using a hierarchical
structure, such as relating line-item data to shipment data, and packaging data to
line-item data.
HLOl shall contain a unique alphanumeric number for each occurrence of the HL
segment in the transaction set. For example, HLOl could be used to indicate the
number of occurrences of the HL segment, in which case the value of HLOl would
be "1" for the initial HL segment and would be incremented by one in each
subsequent HL segment within the transaction.
HL02 identifies the hierarchical ID number of the HL segment to which the current
HL segment is subordinate.
HL03 indicates the context of the series of segments following the current HL
segment up to the next occurrence of an HL segment in the transaction. For example,
HL03 is used to indicate that subsequent segments in the HL loop form a logical
grouping of data referring to shipment, order, or item-level information.
HL04 indicates whether or not there are subordinate (or child) HL segments related
to the current HL segment.
" ~
LX*0l~
MEA*AG**!Q*P1~<1 ' x:»->^'
DTM*196*****CY*19?T-
«../.>• ^-'^^AZi-fX^f-tk?^-
64
Emission Inventory Improvement Program
-------
TECHNICAL REPORT DATA
(PLEASE READ INSTRUCTIONS ON THE REVERSE BEFORE COMPLETING)
1. REPORT NO.
EPA-454/R-97-004g
3. RECIPIENT'S ACCESSION NO.
4. TITLE AND SUBTITLE
Emission Inventory Improvement Program
Data Management Procedures
Preferred And Alternative Methods
5. REPORT DATE
7/25/97
6. PERFORMING ORGANIZATION CODE
7. AUTHOR(S)
Emission Inventory Improvement Program
Data Management Committee
8. PERFORMING ORGANIZATION REPORT NO.
9. PERFORMING ORGANIZATION NAME AND ADDRESS
U.S. Environmental Protection Agency
Office Of Air Quality Planning And Standards (MD-14)
Research Triangle Park, NC 27711
10. PROGRAM ELEMENT NO.
11. CONTRACT/GRANT NO.
68-D2-0160
12. SPONSORING AGENCY NAME AND ADDRESS
Office Of Air Quality Planning And Standards, Office Of Air And Radiation,
U. S. Environmental Protection Agency
Research Triangle Park, NC 27111
13. TYPE OF REPORT AND PERIOD COVERED
Technical
14. SPONSORING AGENCY CODE
EPA/200/04
15. SUPPLEMENTARY NOTES
16. ABSTRACT
The Emission Inventory Improvement Program (EIIP) was established in 1993 to promote the
development and use of standard procedures for collecting, calculating, storing, reporting, and
sharing air emissions data. The EIIP is designed to promote the development of emission
inventories that have targeted quality objectives, are cost-effective, and contain reliable and
accessible data for end users. To this end, the EIIP is developing inventory guidance and
materials which will be available to states and local agencies, the regulated community, the public
and the EPA.
Volume VII presents preferred and alternative methods for managing, reporting, and exchanging
emissions data.
17.
KEY WORDS AND DOCUMENT ANALYSIS
a. DESCRIPTORS
Air Emisisons
Air Pollution
Emission Inventory
Inventory Guidance
IDENTIFIERS/OPEN ENDED TERMS
Air Pollution Control
Emission Inventory
Guidance
c. COSATI FIELD/GROUP
18. DISTRIBUTION STATEMENT
21. NO. OF PAGES
455
22. PRICE
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
Feedback from prior demonstrations to the EIIP/DMC will be used to refine a demonstration
approach.
The output that will be generated by this task consists of the following:
• A demonstration of the integrated prototype to users specified by DOPO
No specific resource requirements have been identified for this task.
2.1.4 Support Technology Transfer
Technical summary reports will be provided as deemed necessary by the DOPO throughout this
project.
Technology Planning and Management Corporation
March 20,1997 -&vs. GOVERNMENT PRINTING OFFICE: 1*97 -529-018
Page 34
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
A proposed approach to the prototype demonstration will be reviewed by the DOPO before
scripting the demonstration and assembling presentation materials. The demonstration may be
limited to presentation materials only or a partial demonstration of the software combined with
presentation materials. For example, the software demonstration could be limited to data
transfer starting with an EDI XI2 file that has been received. If the DOPO desires a full
demonstration of the software, a sending side participant may need to be specified and
arrangements made for them to participate in the send side of the demonstration on a specified
date.
2.1.3.2 Develop Demonstration/Presentation Materials
A script enumerating the steps of the demonstration will be compiled and refined through dry
runs to produce a polished presentation. After a presentation approach is devised, effective
presentation materials will be assembled.
The output that will be generated by this task consists of the following:
• Demonstration Script And Presentation Materials
2.1.3.3 Perform prototype demonstration forDMC
All aspects of the data transfer prototype will be demonstrated to the Data Management
Committee to show the feasibility of an integrated system.
The output that will be generated by this task consists of the following:
• A professionally executed demonstration of the prototype.
No specific resource requirements have been identified for this task.
2.1.3.4 Modify Demonstration/Presentation Materials based upon input from DMC
The first demonstration of the prototype will, undoubtedly, reveal improvements that can be
made in the presentation. Input from prototype demonstration to the Data Management
Committee will be used to improve the presentation before demonstrating to agencies outside
of the EPA.
The output that will be generated by this task consists of the following:
• Revised Demonstration/Presentation Materials
No specific resource requirements have been identified for this task.
2.1.3.5 Perform prototype demonstration to outside users
Technology Planning and Management Corporation
March 20,1997
Page 33
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
The resources that are required to complete this task are shown in the table below.
I Resource :
API Design
Test Plan
Format .:
Electronic
Hardcopy
: Provided By
TPMC
TPMC
Oate Required
7/22/97
7/22/97
2.1.2.7 Integrate the Data Transfer Prototype Components
If components need to be tightly coupled, they will be integrated before proceeding with
integrated testing. An integrated approach will allowthe transmission of the same data through
all stages of the transfer prototype. This will also enable a comparison of data in the sending
and receiving databases.
2.1.2.8 Perform Integrated Testing for the Data Transfer Prototype
Comprehensive testing will be carried out according to the test plan. This includes, but is not
limited to, the following items:
• Validation of Data File Stream Extracted from Pilot Partners) Database in the organization
specified by the ADF File specification.
• Validation of EDI X12 Code After Translation.
• Validation of ASCII File Contents After ADF Compliant Translation at EPA/EFIG.
• Validation of EIDP Prototype Database Contents After Loading.
• Validation of Source-to-Receiver Data Transfer.
The resources that are required to complete this task are shown in the table below.
; : Resource
Completed Test Plan
Format
Hardcopy
Provided By :
TPMC
"... Date Required
8/25/97
2.1.3 Demonstrate Prototype
The task addresses the demonstration of all aspects of the prototype to interested parties. Focus
will begin within the EIIP so that the demonstration can be refined before presentation to
outside agencies.
2.1.3.1 Review prototype with DOPO
Technology Planning and Management Corporation
March 20,1997
Page 32
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
• State EDI Translator Configuration Report
No specific resource requirements have been identified for this task.
2.12.6.2 Design PADER Application Program Interface
DynCorp and TPMC will work with PADER to design an API which generates an ASCII file
from PADER's database that will be passed to the translator in a format consistent with the
ADF specifications. DynCorp will provide EDI expertise while TPMC will concentrate on the
database aspects of the design. TPMC's portion of the task consists primarily in determining
how to unload data from PADER's database into a file that conforms to the ADF
specifications. This may have to be a two step process if the software which must be used to
extract the data from the database does not provide enough control over the form of the
extracted data. It is anticipated that PADER will make a very significant contribution to
completing this task. This has been taken into account in the current schedule. TPMC may need
read access to PADER's database or a local example database with the same structure in order
to participate in developing and testing the software that will extract the data.
The output that will be generated by this task consists of the following:
• PADER Application Interface
The resources that are required to complete this task are shown in the table below.
Resource
Prototype Architectural Design
(Portion describing PADER's
environment)
ADF specification
Read access to PADER's Database or
another database of similar structure.
Format
Hardcopy
Hardcopy
Electronic
Provided £y
TPMC
DynCorp
Penn.
Date Required
7/7/97
7/7/97
7/7/97
(optional)
2.12.6.3 Code And Test PADER's Application Program Interface
The PADER API will be coded according to specifications. The code will be tested according
to TPMC's test plan.
The output that will be generated by this task consists of the following:
• Completed test report(s).
• Operational Application Program Interface
Technology Planning and Management Corporation
March 20,1997
Page 31
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
The resources that are required to complete this task are shown in the table below.
-.-."• ; Resource
API Design
Test Plan
i Format L
Hardcopy
Hardcopy
;; Provided By :
TPMC
TPMC
Date Required;
6/3/97
6/10/97
2.1.2.5.5 Build EPA's Viewer for Data Received
The queries developed for the prototype database demonstration may satisfy the need for a tool
to enable users to browse through loaded test data. If not, they can be augmented by expanding
existing queries or adding additional queries to whatever query tool was chosen.
• Queries tailored for loaded data.
The resources that are required to complete this task are shown in the table below.
Resource
SQL*Net for the client workstation
Oracle ODBC driver
Oracle Data Browser, Microsoft Access,
or other third-party ad hoc query tools
I Format :;
Electronic
Electronic
Electronic
I Provided By : !
TPMC
TPMC
TPMC and/or EFIG
; Date Required
Complete
Complete
6/16/97
(optional)
2.1.2.6 Develop PADER's Data Transfer (Send) Prototype Components
This process should be very similar to the development of CARB's Data Transfer Components.
Lessons learned from the CARB transfer prototype should reduce the amount of time needed
to perform some tasks. The process of unloading of data from PADER's database will not
benefit as much from lessons learned during the CARB prototype transmission if the databases
are dissimilar (i.e., different database types and/or data storage methods).
2.1.2.6.1 Install EDI Translator And Transmission Software for PADER
The mapped EDI translator must be installed and configured as per PADER's operating system
and telecommunications environment. Transmission software must also be installed. The same
translator mapping will be used by all participants.
The output that will be generated by this task consists of the following:
Technology Planning and Management Corporation
March 20,1997
Page 30
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
2.1.2.5.2 Install EDI translator and transmission software for EPA
The mapped EDI translator must be installed and configured as per EPA's operating system
and telecommunications environment. Transmission software must also be installed. The same
translator mapping will be used by all participants.
The output that will be generated by this task consists of the following:
• EPA EDI Translator Configuration Report
No specific resource requirements have been identified for this task.
2.1.2.5.3 Design EPA's Application Program Interface
Design of the application program interface will be done as a joint venture between DynCorp
and TPMC with TPMC having the lead coordination and development role. The application
will read the required data from an EIIP EDI X12 format, convert it to an ASCII file according
the ADF, and load the data into the prototype database. DynCorp will provide EDI expertise
while TPMC will provide database loading expertise. The output that will be generated by this
task consists of the following:
• EPA Application Interface Design
The resources that are required to complete this task are shown in the table below.
Resource
ADF specification
Format
Hardcopy
Provided By
TPMC
Date Required
5/20/97
2.1.2.5.4 Code EPA's Application Program Interface
The API that creates a data file based on the ADF specifications and loads it into the EIIP
prototype database application interface at EPA will be coded according to specifications. This
may actually consist of two separate programs. One program is needed to create the data file
using the ADF. The other program will load the data file into the prototype database. The code
will be tested according to TPMC's test plan.
The outputs that will be generated by this task consist of the following:
• Test notes
• Operational EPA Application Interface
Technology Planning and Management Corporation
March 20,1997
Page 29
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
2.1.2.4.4 Code And Test CARB's Application Program Interface
The CARB API will be coded according to specifications. The code will be tested according
to TPMC's test plan.
The output that will be generated by this task consists of the following:
Completed test report(s)
Operational Application Program Interface
The resources that are required to complete this task are shown in the table below.
Resource
ADF specification
Read access to CARB's Database or
another database of similar structure
Test Plan
Formal :
Hardcopy
Electronic
Hardcopy
i Provided ay ;
DynCorp
DynCorp
TPMC
Date Required
4/3/97
4/3/97
(optional)
4/10/97
2.1.2.5 Develop EPA's Data Transfer (Receiver) Prototype Components
This task consists of designing, building, configuring, and testing translation and interface
software to:
• Define an ADF file format.
• Translate an XI2.841 transaction containing emissions inventory data into an ASCII data
file as per ADF file format.
• Load the ASCII data file contents into the EIIP prototype database located at EPA/EFIG.
2.1.2.5.1 Design ADF file for EDI translation
DynCorp will design an ADF file format suitable for generating a file which the prototype API
can load into the EIIP prototype database.
The output that will be generated by this task consists of the following:
• A completed ADF file design specification (DynCorp)
No specific resource requirements have been identified for this task.
Technology Ranning and Management Corporation
March 20,1997
Page 28
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
No specific resource requirements have been identified for this task.
2.1.2.4.2 Install EDI Translator And Transmission Software for CARB
The mapped EDI translator must be installed and configured as per CARB's operating system
and telecommunications environment. Transmission software must also be installed. The same
translator mapping will be used by all participants.
The output that will be generated by this task consists of the following:
• State EDI Translator Configuration Report
No specific resource requirements have been identified for this task.
2.1.2.4.3 Design CARB's Application Program Interface
DynCorp and TPMC will work with CARB to design an API which generates an ASCII file
from CARB's database that will be passed to the translator in a format consistent with the ADF
specifications. DynCorp will provide EDI expertise while TPMC will concentrate on the
database aspects of the design. TPMC's portion of the task consists primarily in determining
how to unload data from CARB's database into a file that conforms to the ADF specifications.
This may have to be a two step process if the software which must be used to extract the data
from the database does not provide enough control over the form of the extracted data. It is
anticipated that CARB will make a very significant contribution to completing this task. This
has been taken into account in the current schedule. TPMC may need read access to CARB's
database or a local example database with the same structure in order to participate in
developing and testing the software that will extract the data.
The output that will be generated by this task consists of the following:
CARB Application Interface Design
The resources that are required to complete this task are shown in the table below.
Resource \
Prototype Architectural Design
(Portion describing CARB's environment)
ADF specification
Read access to CARB's Database or
another database of similar structure
Format
Hardcopy
Hardcopy
Hardcopy
Provided By
TPMC
DynCorp
CARB
Date Required
3/17/97
3/17/97
3/17/97
Technology Planning and Management Corporation
March 20,1997
Page 27
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
listed in the following table indicate when the software will need to be installed. The translator
software must first be configured (mapped) before it can be installed.
Resource
Transmission software for GARB
EDI translator software for CARS
Database software from CARB
Transmission software for EPA/EFIG
EDI translator software for EPA/EFIG
Transmission software for PADER
EDI translator software for PADER
Database software from PADER
Microsoft C++ compiler
List of additional software needed
Format
Electronic
Electronic
Electronic
Electronic
Electronic
Electronic
Electronic
Electronic
Electronic
Hardcopy
Provided 8y
Pilot Participant
DOPO/DynCorp
CARB
DOPO
DOPO/DynCorp
Pilot Participant
DOPO/DynCorp
Penn.
EFIG
TPMC
Date Required
5/12/97
5/12/97
4/1/97
(Optional)
6/30/97
6/30/97
8/14/97
8/14/97
5/1/97
(Optional)
5/12/97
(Optional)
3/5/97
(Optional)
2.1.2.4 Develop CARB's Data Transfer (Send) Prototype Components
This task consists of designing, building, configuring, and testing translation and interface
software to:
• Extract data from the state database into an ADF compliant ASCII file.
• Translate the ASCH file into an X12.841 transaction suitable for transmission via the
translator.
2.1.2.4.1 Design ADF file for EDI translation
DynCorp will design an ADF file format that will document the format that the data stream
must be in to communicate the data in a manner that is consistent with the Convention
Document and translator.
The outputs that will be generated by this task consist of the following:
• A completed ADF file design specification. (DynCorp)
Technology Planning and Management Corporation
March 20, 1997
Page 26
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
ASCII file send side
Pilot Database
ASCII file receive side
El IP Prototype DB
Translator, ADF, and
Transmission Software
All of above
Automated1
Manual
lrThe feasibility of this depends on how the translator is implemented.
Another aspect of the test strategy that is important is keeping track of the state (versioning)
of various software modules. Although an elaborate configuration management scheme is not
appropriate for this project, a systematic approach to storing of modules and versions will be
applied to facilitate efficient correction of problems detected during testing. It is sometimes
more effective to revert to a previous version when "fixes" to the software introduce perplexing
anomalies. A systematic approach to storing versions ensures that the previous versions are
available if this situation should arise.
DynCorp will assist TPMC in the development of the test strategy.
The output that will be generated by this task consists of the following:
• An outline of the test strategy with a summary description of the testing approach.
No specific resource requirements have been identified for this task.
2.12.2.2 Create Test Plan
Once more detail is available about the operating systems and types of software that will be
used in the prototype, a more specific plan can be written that enumerates the steps needed to
implement the test strategy in particular environments. To some extent, the operating systems
and application software packages dictate the best approach to validation techniques. Tools
which can be used to automate validation may also be identified.
The output that will be generated by this task consists of the following:
• A Detailed Testing Plan/Checklist
2.1.2.3 Obtain and install required software
It may be necessary to obtain additional software needed to support the prototype
development. Whether additional software is needed should become apparent when the
architectural design has been completed and the early stages of the API design has begun.
TPMC will provide to the DOPO a list of the additional software needed. The software listed
below will be provided either by the DOPO or purchased through ODCs if needed. The dates
Technology Planning and Management Corporation
March 20,1997
Page 25
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
The resources that are required to complete this task are shown in the table below.
Resource
List of available translators (including
those held by the states and local
agencies)
Infrastructure information from EPA
Infrastructure information from CARS
Infrastructure information from PADER
Documentation on the business
process(es) to be prototyped
; Formal :: 'i.J
Hardcopy
Hardcopy
Hardcopy
Hardcopy
Hardcopy
i Prowled; By T;fi
DynCorp
TPMC/DOPO
TPMC/CARB
TPMC/PADER
DOPO
;H;;Dste Required
Completed
3/17/97
3/17/97
3/17/97
Completed
2.1.2.2 Develop Test Plan
A systematic test plan is needed to insure that no data corruption occurs at any point in the path
from the sending database to the receiving database. Testing should also identify software
failures such as core dumps, General Protection Faults, infinite loops, or annoying user
interface idiosyncracies.
2.1.2.2.1 Identify Test Strategy
The transfer of data occurs in several steps like links in a chain. Since a problem in any link in
the chain affects the integrity of the whole chain, each link should be tested individually. If data
from the source and destination database compare well, it indicates that data transfer at each
link was successful. If the source and destination data does not compare favorably, the
problem(s) cannot be pinpointed without the application of some sort of validation technique
for each data transfer. Therefore, a means will be devised to verify that data is accurately
transferred for each of the steps in the table below.
From
Pilot Database
ADF compliant ASCII File
X12 (send)
X12
ADF compliant ASCII File
To \
ADF compliant ASCII file
X12
X1 2 (receive)
ADF compliant ASCII file
EIIP Prototype DB
Transfer Mechanism .
Dependent on database
X12 Translator and ADF File
Transmission Software
X12 Translator and ADF File
SQL*Loader
"!:J::}itettfVI -.
Manual
Manual
Manual
Manual
Manual
Technology Planning and Management Corporation
March 20, 1997
Page 24
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
No specific resource requirements have been identified for this task.
2.1.2.1.5 Map Transmission Translator
The translator must be mapped to be consistent (i.e. reflect) the Convention Document. This
will be done once the Convention Document is complete. The translator vendor, Supply Tech,
will do the work which will take approximately four weeks. This work will be performed
concurrently with other tasks. The same mapping (called an overlay) will be used by all
participants.
2.1.2.1.6 Develop Prototype Architectural Design
After the pilot participant(s) and the business process(es) to be prototyped have been identified
it will be possible to define the architectural design for the prototype. The architectural design
will take into consideration the existing information technology infrastructure for the pilot
participants) and EPA/EFIG. TPMC will conduct a survey to analyze the computing
platforms, software environment, and telecommunications capabilities for each pilot participant
to determine the architecture that will most effectively allow integration with the EPA/EFIG
infrastructure and support the goals of the data transfer method prototype. An architecture
design document will be created that describes the architecture of each pilot participant site and
EPA/EFIG. The document will also describe the proposed telecommunication links between
each of the pilot participant sites and EPA/EFIG. Any additional resources that are needed to
implement the architectural design will be described in the design document. However, it is
expected that the architectural design will focus on using existing infrastructure wherever
possible.
The output that will be generated by this task consists of the following:
• The architectural design documentation for the prototype
Technology Planning and Management Corporation
March 20,1997
Page 23
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
The resources that are required to complete this task are shown in the table below.
Resource :
List of available translators (including
those held by the states and local
agencies)
Formal
Hardcopy
Pfovweia;^-;;
DynCorp
i Date Required
Completed
2.1.2.1.3 Identify Inventory Type(s) to be Prototyped
There are several types of inventory transactions that provide information that is incorporated
into the emissions inventory database. The major types of emissions inventory data are Point
Source, Area Source, Mobile Source and Biogenic Source. Some examples of the transactions
that require the submittal of these source inventory types are:
• State Implementation Plans (SIP)
• Annual Inventories
• Modeling Inventories
The output of this task is the identification of the inventory type(s) to be prototyped.(DOPO)
This task is completed. Data transfer will be demonstrated for the emission inventory data
needed for regional air quality modeling as specified by ECOS.
2.1.2.1.4 Submit Prototype Version of the EIIP EDI X12 Convention Document and
Implementation Guideline
The EIIP's EDI Implementation Guideline will serve as a guide for parties who wish to
electronically submit their emission data to the EPA, or others that accept the EIIP EDI data
format. The document will be developed by DynCorp. The Implementation Guideline will
incorporate the Convention Document as an appendix. Itwill be finished approximately two
weeks after the Convention Document. The Convention Document will be a technical guide
that will be used to map the translator. The Implementation Guideline will also provide a
crosswalk that enables the reader to locate each attribute in the EIIP data model and the
corresponding location in the Convention Document. The Implementation Guideline will
specify business rules which apply to the data transfer (i.e., rules for modeling inventory data).
This will affect how the API is designed.
The output that will be generated by this task consists of the following:
• EUP Draft EDI Convention Document for Prototype (2118/97 DynCorp)
• EIIP Draft EDI Implementation Guideline for Prototype (3/3/97 DynCorp)
• EIIP EDI Implementation Guideline for Prototype (3/17/97 DynCorp)
Technology Planning and Management Corporation
March 20,1997
Page 22
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
2.1.2.1.1 Identify Available EDI Translators
The goal of this task is to identify any EDI translators that are available to be used for the
purpose of this data transfer method prototype with minimal cost to EFIG and EIIP/DMC.
Other workgroups within the EPA might have a translator that is not being used and may be
borrowed for this prototype on a temporary basis. Some vendors may also provide an
evaluation copy of their EDI translator product for use with the prototype. Another alternative
is to select pilot participant(s) that have an EDI translator and are willing to allow it to be
utilized as part of their participation in the demonstration project. If no EDI translators are
located then it will be necessary to purchase the needed translators) to complete the prototype
demonstration. It is understood that DynCorp will work with the DOPO under a separate
Delivery Order (ITAS-008) to provide this information.
The output that will be generated by this task consists of the following:
• A list of available EDI translators that are available for use with this prototype. (DynCorp)
This task is completed. The translator which will be used is STX by Supply Tech.
No specific resource requirements have been identified for this task.
2.1.2.1.2 Identify Pilot Participants
One of the goals of the prototype demonstration is to include one or two states or local
agencies from the EUP user community as pilot participants in the prototype development and
demonstration. The selected participants should have a working knowledge of EDI and how
it is being applied to this data transfer method prototype. The DOPO will select the
participant(s) based upon information that is gathered by this task. An example of the criteria
that will be used for pilot participant selection includes a working knowledge of EDI and
available resources (equipment, software, and staff) that can be committed to the prototype.
The output that will be generated by this task consists of the following:
• The names of one or two pilot participants.
This task has been completed. The two pilot participants are PADER and the California Air
Resource Board (CARB).
Technology Planning and Management Corporation
March 20,1997
Page 21
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
2.1.1.18 Modify the database design and "viewer"
After TPMC has received feedback from the EFIG and Pechan users, we will return to the
appropriate point in this action plan to modify the database design and/or "viewer." Depending
upon the complexity of the modification(s) it might be necessary to repeat one or more of the
previous tasks. Simple modifications might only require a memo describing the changes to be
issued to the users and then evaluating any feedback the users provide. Major changes may
require additional design review and training sessions to be held.
This task will attain successful completion when no modifications have been identified by the
EFIG and Pechan users during the previous task (Get feedback from EFIG/Pechan about
database design and "viewer"). At that time, TPMC will provide an export of the logical and
physical database design from the Oracle Designer/2000 so that EFIG/Pechan will have it for
any future modifications.
The output generated by this task consists of the following:
• Export of the logical and physical database design from Designer/2000.
No additional resource requirements have been identified for this task.
2.1.2 Develop Data Transfer Prototype
This task consists of integrating the various components, modules and manual procedures that
are needed to perform data transfers for the EIIP EDI X12 datasets within the scope of this
Delivery Order. The scope of the data transfer prototype encompasses the retrieval of a
specified dataset from the pilot partners) database, translation of that data into the EDI X12
standard dataset, transmission of the EDI XI2 dataset to EPA/EFIG over available
telecommunication links, translation of the data back out of the transmitted EDI X12 dataset,
and loading of the data into the EIIP prototype database.
2.1.2.1 Finalize Detailed Design
There are several steps that must be completed before the data transfer prototype design can
be considered finalized. These steps define the structure under which the prototype must
operate to successfully demonstrate the data transfer method.
Technology Planning and Management Corporation
March 20,1997
Page 20
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
database design as part of the training session. It is anticipated that all of the EFIG and Pechan
users will be trained during a single half-day session.
The outputs generated by this task consists of the following:
• List of tables/columns and their descriptions
• Relational database theory notes
No resource requirements have been identified for this task.
2.1.1.16 Provide training on the prototype demonstration "viewer"
TPMC will provide training on the use of the "viewer" to the EFIG and Pechan staff. Training
will consist of how to use the "viewer" for running the "canned" queries and how to use the
"viewer" for creating their own ad-hoc queries. A list of the "canned" queries and a brief
description of each will be prepared for the training session by TPMC. It is anticipated that all
of the EFIG and Pechan users will be trained during a single half-day session.
The outputs generated by this task consists of the following:
• List of "canned" queries
No resource requirements have been identified for this task.
2.1.1.17 Get feedback from EFIG/Pechan about database design and "viewer"
After the EFIG and Pechan users are trained on the database design and the use of the
"viewer," they will use the "viewer" to evaluate the database design and ensure that it satisfies
their functional requirements. A follow-up meeting with the EFIG and Pechan users will be held
to discuss their experiences with the "viewer" and the prototype database. All suggestions will
be discussed by the group to determine whether they should be implemented in the database
design or "canned queries." It may also be determined that another "viewer" or different
"canned queries" would be more appropriate for evaluating the prototype.
The output from this task will be a list of database and "viewer" modifications that should be
implemented.
No additional resource requirements have been identified for this task.
Technology Planning and Management Corporation
March 20,1997
Page 19
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
Successful completion of this task is attained after the "viewer" and all of the canned queries
are verified to execute properly. There are no formal outputs created by this task.
The resources that are required to complete this task are shown in the table below.
. .
Kesource . .....
Additional client workstation for testing
Oracle Data Browser, Microsoft Access,
or other third-party ad hoc query tools
« • t •-
\- ronnat ..":
n/a
Electronic
" "" n ---j- j»-&j
; .rfOWKIedHy •::::••:
TPMC
TPMC and/or ERG
" tt 4 TV ' ' *" .1 —
" • : .Pate K6C] uirea
4/28/97
4/28/97
(optional)
2.1.1.14 Install "viewer" at EFIG/Pechan for prototype demonstration purposes
The "viewer" and "canned" queries are installed on EFIG and Pechan workstations and/or
servers during this task. TPMC will assist the EPA/EFIG and Pechan desktop support staff
with the initial installation and help to resolve any installation problems that may arise. TPMC
will provide an installation disk(s) that contains the "canned" queries and any scripts or
procedures needed to install the queries. EFIG/Pechan must provide the appropriate "viewer"
for installation on (or accessible from) each of the targeted workstations.
The resources that are required to complete this task are shown in the table below.
Resource
"Canned" query installation disk(s)
Oracle Data Browser, Microsoft
Access or other third-party ad hoc
query tool for each targeted
workstation
Oracle SQL*Net for each targeted
workstation
Forma!
Electronic
Electronic
Electronic
ProvktedBy
TPMC
EFIG/Pechan
EFIG/Pechan
Date Required
4/29/97
4/29/97
(optional)
4/29/97
2.1.1.15 Provide database design training to EFIG/Pechan
TPMC will provide training on the database design to the EFIG and Pechan staff. Training will
consist of learning how the database is organized and how it can be used to formulate ad-hoc
queries with the "viewer." A list of the database tables and columns will be prepared for the
training session by TPMC. A brief description of each table and column will also be included
in the list. TPMC is prepared to review relational database theory in relation to the prototype
Technology Planning and Management Corporation
March 20,1997
Page 18
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
It should be noted that performance evaluation of this prototype may not accurately reflect the
performance provided by a production database that has a significantly larger volume of data.
However, the procedures developed for evaluating the performance can be used by
EFIG/Pechan in the future as additional data is loaded into the database.
The output from this task consists of the following:
• Performance and operation evaluation procedures document
No resource requirements have been identified for this task.
2.1.1.12 Develop a "viewer" for prototype demonstration purposes
The "viewer" is essentially a tool that can be used to look at the database structure and the
actual data content. It is anticipated that a commercial-off-the-shelf (COTS) application, such
as Microsoft Access or Oracle Data Browser, will be used as the viewer. The development will
consist of creating a limited number of "canned" queries that can be used by EFIG and Pechan
staff to view the data content. The EFIG and Pechan staff can then use the "viewer" to generate
their own queries to evaluate the database design.
The output that will be generated by this task consists of the following:
• A limited number of "canned" queries for the selected "viewer"
The resources that are required to complete this task are shown in the table below.
Resource
SQL*Net for the client workstation
Oracle ODBC driver
Oracle Data Browser, Microsoft Access or
other third-party ad hoc query tools
Format
Electronic
Electronic
Electronic
Provided By
TPMC
TPMC
TPMC and/or EFIG
Date Required
4/17/97
4/17/97
(optional)
4/17/97
(optional)
2.1.1.13 Test the prototype demonstration "viewer"
This task consists of formally testing the "viewer" to ensure that it will operate successfully
after installation at EFIG/Pechan. The "viewer" application and all of the "canned" queries will
be installed on a workstation where they had not previously been installed. The "viewer" and
queries will then be tested to make sure that they will work after being properly installed.
Technology Planning and Management Corporation
March 20,1997
Page 17
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
user accounts for EFIG and Pechan staff prior to prototype installation. The Oracle access
privileges will need to be granted to the users by the Application Administrator soon after the
prototype is installed.
Once the prototype database is installed on the EPA/EFIG Database Server, the EFIG/Pechan
staff can evaluate database design by performing queries against the data that has been loaded.
Additional resources such as the Oracle Open Data Base Connectivity (ODBC) driver or the
Oracle Data Browser may be needed to support the prototype database review process
performed by the EFIG/Pechan staff. Other third-party tools, such as Lotus, Microsoft Access,
and Crystal reports may also be used to review the database.
The output that will be generated by this task consists of the following:
• Prototype database installed on EPA/EFIG server
The resources that are required to complete this task are shown in the table below.
Resource
Oracle Relational Database Management
System at EPA/EFIG
Application Administrator at EPA/EFIG
SQL*Net for all client workstations
Oracle ODBC driver
Oracle Data Browser, Microsoft Access or
other third-party ad hoc query tools
; Format
Electronic
n/a
Electronic
Electronic
Electronic
Provided By
EFIG
EFIG
EFIG
TPMC
EFIG
Date Required
Completed
5/9/97
5/9/97
5/9/97
(optional)
5/9/97
(optional)
2.1.1.11 Define user requirements for database performance and operations
Part of the evaluation of the prototype database design is an evaluation of whether the database
satisfies user requirements for performance and operations. This task consists of identifying the
performance and operational requirements that will be used to evaluate the prototype database.
These requirements may have been identified during the previous task (Conduct a requirements
gathering workshop for the NET database) but are reviewed and refined during this task. One
or more meetings may be needed to define the performance/operational requirements, identify
the evaluation criteria, and select the measurement tools. The results of the meetings will be
a document describing the procedures for evaluating the performance and operational aspects
of the database.
Technology Planning and Management Corporation
March 20,1997
Page 16
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
Any discrepancies and errors that occur during the loading process will be documented and
resolved before successful completion of the task can be attained. We will specifically be
looking for problems involving referential integrity with the base (or reference) tables, conflicts
with unique identifiers and inconsistencies with data values.
The plans, scripts, procedures, and programs will be modified to reflect any corrections that
were made due to errors that were encountered.
The outputs that will be generated by this task consist of the following:
• Loaded prototype database
• NET dataset loading plan
• AIRS-AFS dataset loading plan
• SQL*Loader scripts and control files (optional)
• SQL*Plus scripts (optional)
• C/C++ programs (optional)
• PL/SQL procedures (optional)
• Prototype database load summary report
The resources that are required to complete this task are shown in the table below.
: Resource
EIIP Phase I Data Model To Prototype
Database Correspondence Report
NET Database To Prototype Database
Correspondence Report
AIRS-AFS Dataset To Prototype
Database Correspondence Report
Format
Hardcopy/
Electronic
Hardcopy/
Electronic
Hardcopy/
Electronic
Provided By
TPMC
TPMC
TPMC
Date Required
5/2/97
5/2/97
5/2/97
2.1.1.10 Move the prototype database to an EPA/EFIG Oracle Database Server
Moving the prototype database to the EPA/EFIG Oracle Database Server will put the database
on a server where the EFIG/Pechan staff can effectively perform an evaluation of the prototype.
Prior to moving the prototype database, EFIG must have the infrastructure in place to support
the database. The required infrastructure includes the availability of an Oracle Database Server
(system and RDBMS kernel), sufficient disk space, network connection, and Oracle SQL*Net.
An Application Administrator should also be available that can perform tasks such as creating
Oracle user accounts, tuning database performance, backing up the database, and importing the
prototype database provided by TPMC. The Oracle database server must be installed before
the prototype database can be moved. The Application Administrator should also have created
Technology Planning and Management Corporation
March 20,1997
Page 15
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
• Create Status Quality Control Report
• Invalid Database Objects Quality Control Report
• Package/Procedure Quality Control Report
• Database Table and Index Size Estimates Report
In addition to the reports listed above, the physical database will be created as a product of this
task. The database will be created on an Oracle database server located at the TPMC facilities
and will be available for on-line review by the EFIG/Pechan staff. However, since no data will
be loaded into the database as part of this task, any review would be limited to the physical
structure of the database.
No resource requirements were identified for this task.
2.1.1.8 Get feedback from EFIG/Pechan on database design
Review sessions will be held with EFIG and Pechan staff to discuss the physical prototype
database created during the previous task by TPMC. Appropriate reports will be generated
from Designer/2000 and distributed to the review team prior to meeting. TPMC will describe
the physical database structure in detail during this working session. Completion of this task
will be attained when the EFIG/Pechan staffs accept the physical database. Any problems,
discrepancies, or omissions that are identified during the review session will be corrected in the
logical data model and/or the physical database design. A modified physical database will be
created and additional review sessions will be held as needed. Advancement to the next task,
where the physical database is built, will not occur until the logical data model is approved.
The outputs that will be generated by this task consist of modified entity-relationship diagrams
and reports that will be used to update the Designer/2000 data dictionary. New reports and
diagrams will be generated from Designer/2000 as needed.
No specific resource requirements have been identified for this task.
2.1.1.9 Load formatted datasetfs) that have been mapped into the prototype database
This task consists of loading of the NET and AIRS-AFS data into the prototype database. The
EIIP formatted dataset will not be available until the design phase of EPA's Application
Program Interface (API) that is discussed in the section of this document entitled "Develop
Data Transfer Prototype." The loading plans, scripts, and procedures will be developed for
each of the databases during this task. The correspondence reports from the mapping process
will be used as a guide in creating the loading software.
Technology Planning and Management Corporation
March 20,1997
Page 14
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
2.1.1.6.3 Map AIRS-AFS formatted dataset into physical prototype database
This task follows the same process as the previous task where the EIIP and NET datasets were
mapped to the prototype database. However, in this task we will be mapping the AIRS-AFS
formatted dataset to the prototype database. The AIRS-AFS dataset is considered to be a single
submittal (containing multiple records) from one state.
The outputs that will be generated by this task consist of the following:
• AIRS-AFS dataset to Prototype Database Correspondence Report
The resources that are required to complete this task are shown in the table below.
; L: Resource : : ;
AIRS-AFS dataset documentation
H' Format ::
Hardcopy
Provided By
EFIG. IMG/ITPID
Date Required :
Completed
2.1.1.7 Build the physical prototype database
After approval of the logical data model by EFIG and Pechan, TPMC will proceed with
building the physical database. This process follows the data mapping described above because
the source of the data will determine the field lengths of attributes that must be defined in the
prototype database. Oracle's Designer/2000 will be used to build the physical prototype
database. Tables, columns, constraints, primary keys, foreign keys, and indexes will be created
within the data dictionary. SQL scripts that can be used to create the database will be generated
from the Designer/2000 data dictionary after the TPMC analyst has completed the physical
database design.
Several outputs will be generated by this task that will be used by EFIG, Pechan, and TPMC
staff in subsequent tasks to review the physical database design. Some examples of the outputs
that can be generated by the Designer/2000 as products of this task include:
• Database Definition Report
• Sequence Definition Report
• Cluster Definition Report
• File, Record, and Field Definition Report
• File Definition Report
• File and Field Definitions for a Given Record Report
• Tablespace Definition Report
• Rollback Segment Report
• Storage Parameters Report
• Database Objects Report
Technology Planning and Management Corporation
March 20,1997
Page 13
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
The following three sections are described sequentially but will actually be performed
concurrently as they are all interrelated.
2.1.1.6.1 Map EIIP formatted dataset into physical prototype database
The primary benefit in mapping the EIIP dataset into the physical prototype database is that the
EIIP Phase I Data Model document will provide a general guide for determining the location
of individual attributes within the entities of the prototype data model. Field lengths for the
attributes will be determined by other mappings.
The outputs that will be generated by this task consist of the following:
• EIIP Phase I Data Model to Prototype Database Correspondence Report
The resources that are required to complete this task are shown in the table below.
Resource
EIIP Phase I Data Model
Format
Hardcopy
Provided By \
ERG
Date Required ,
Completed
2.1.1.6.2 Map current NET (Foxpro) dataset into physical prototype database
This task is similar to the previous task where the EIIP dataset was mapped to the prototype
database. However, in this task we will be mapping the NET (Foxpro) dataset to the prototype
database. The NET dataset is considered to be one year of emissions inventory data and the
supporting data that is contained in the Foxpro file sets.
The outputs that will be generated by this task consists of the following:
• NET Database to Prototype Database Correspondence Report
The resources that are required to complete this task are shown in the table below. It may be
necessary to have a copy of Foxpro supplied to TPMC if it is determined that we need to use
it for viewing/manipulation of the dataset prior to exporting it for loading into the prototype
database.
Resource
QUICKREPTS User's Manual for NET
database
NET software and sample dataset
Format
Hardcopy
Electronic
Provided By ;
ERG
EFIG/Pechan
Date Required
Completed
Completed
Technology Planning and Management Corporation
March 20,1997
Page 12
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
The data mapping will also help the analyst determine the most effective method for actually
loading the datasets into the physical prototype database and provide the basis for the dataset
loading plan. The plan includes the sequence of events that must be followed in order to satisfy
the referential integrity rules (constraints) that are enforced by the database. For example, it is
necessary to create a site in the database before any point source emission data values can be
loaded for a site.
The results of the mapping process will help to define the best method for loading the dataset
into the prototype database. For example, it may be beneficial to create a table in the database
which mirrors the dataset to be loaded. The original dataset can then be loaded into the
"temporary table" in the database and then SQL*Plus scripts can be used to transfer selected
information from the "temporary table" into the prototype tables. Another method may be to
use Oracle's SQL*Loader utility to load directly into the prototype database tables. A third
alternative is to write a C/C++ program that uses Oracle's Pro*C precompiler product for
accessing the prototype database. The final alternative is to develop a PL/SQL procedure that
reads the original ASCII dataset and loads the data into the prototype database.
Three differing datasets have been selected to be mapped into the physical prototype database.
The datasets selected are:
• EIIP EDI X12 standard formatted dataset
• Current NET dataset
• AIRS-AFS dataset
EIIP EDI X12 standard formatted dataset Mapping this dataset is essential for
demonstration of the prototype and evaluation of the results. Once the mapping is complete for
the datasets received by EFIG it is applicable for the entire EIIP user community. However,
each EIDP user will most likely need to map their database to the source dataset format.
Current NET dataset. Mapping the NET (Foxpro) dataset provides the opportunity for
migrating the existing NET database into a prototype database that supports both emissions
inventory data submitted by the EIIP user community and the NET database analysis and
reporting activities performed by EFIG and Pechan.
AIRS-AFS dataset Mapping this dataset demonstrates that data submitted to AIRS-AFS by
states and local agencies can be loaded into the physical prototype database. Subsequently, a
single repository for all national emissions inventory data can be demonstrated by this
prototype.
Technology Planning and Management Corporation
March 20,1997
Page 11
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
The resources that are required to complete this task are shown in the table below. TPMC
already has in place the UNIX servers, Oracle Relational Database Management System
(RDBMS), and Designer/2000 tools that are needed.
: Resource
Oracle Designer/2000 software
Oracle Relational Database Management
System
UNIX Server
Format
Electronic
Electronic
n/a
Provided By ;
TPMC
TPMC
TPMC
Date Required
Completed
Completed
Completed
2.1.1.5 Conduct review session on logical data model with EFIG/Pechan
A review session will be held with EFIG and Pechan staff to discuss the logical data model
designed by TPMC. Appropriate reports will be generated from Designer/2000 and distributed
to the review team prior to meeting. TPMC will describe the proposed logical data model in
detail during this working session. Modifications to the EHP/DMC Data Model which were
required to satisfy the requirements of the NET database will be highlighted. Completion of this
task will be attained when the EFIG/Pechan staffs accept the logical data model design. Any
problems, discrepancies, or omissions that are identified during the review session will be
corrected in the logical data model; additional review sessions will be held as needed.
Advancement to the next task, where the physical database is built, will not occur until the
logical data model is approved.
The outputs that will be generated by this task consist of modified entity-relationship diagrams
and reports that will be used to update the Designer/2000 data dictionary. New reports and
diagrams will be generated from Designer/2000 as needed.
No specific resource requirements have been identified for this task.
2.1.1.6 Map selected datasets into the physical prototype database
The process of mapping a dataset to the physical prototype database requires each source field
in the dataset to be analyzed and a plan designed for transferring the field into the proper tables
and columns in the prototype database. Analysis of each dataset field and how it correlates to
the prototype database will identify whether any type of data conversion, expansion, or
truncation must be performed. This process will proceed the building of the prototype database
because the data lengths of the source fields will determine the lengths of the individual fields
in the prototype database. This level of detail is not addressed by the EIIP Phase I Data Model
document. Each field length in the prototype database will usually be the largest common
denominator of the source fields that map into it.
Technology Planning and Management Corporation
March 20,1997
Page 10
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
2.1.1.3 Conduct a requirements gathering workshop for the NET database
A requirements gathering workshop is needed to identify new requirements for the NET
database that Pechan will implement in the new user interface. New application requirements
typically require modification to a database design to effectively implement the requirement.
Multiple workshops may be needed to finalize a functional specification that documents the
functionality of the new application.
The TPMC analyst should participate in the workshop(s) to gain a better understanding of the
user requirements. A copy of the generated functional specifications is also needed for analysis
to ensure that the database design allows the Pechan staff to implement the functional
requirements.
There are no formal outputs from this task; however, the analyst should create some notes and
document any questions/responses that are generated during the review process.
2.1.1.4 Define logical data model for the prototype database
After the TPMC analyst obtains the needed information from the data model reviews and
functional specifications, the logical data model for the NET prototype database will be
defined. The analyst will use Oracle's Designer/2000 CASE tool to define the logical model.
This tool supports full life cycle development of the database design from analysis through
implementation of the physical database. The analyst will document the business rules,
processes, and notes on the design in the Designer/2000 data dictionary. This information will
be useful for subsequent modifications to the design after evaluation of the prototype database.
Several outputs will be generated by this task that will be used by EFIG, Pechan, and TPMC
staff in subsequent tasks. Some examples of the outputs that can be generated by the
Designer/2000 as products of this task include:
• Entity-Relationship Diagram
• Entity Model Information Report
• Entities and their Descriptions Report
• Entity Definition Report
• Attribute Definition Report
• Unique Identifiers for an Entity Report
• Relationships Report
• Quality Checking of Relationships Report
• Attributes in a Domain Report
• System Glossary Report
Technology Planning and Management Corporation
March 20,1997
Page9
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
requested copies of any revisions/updates to the EIIP Phase I Data Model document, the
updates may not be incorporated into the prototype database if they are received beyond a
critical point in the logical database design. However, the updates not implemented in the
prototype database will be documented in the Approach Study to reflect the need to modify the
database design based upon the data model refinements made by the DMC and ERG.
Resource i
Latest version of the EIIP Phase I Data
Model document
Revisions/updates to the EIIP Phase I
Data Model document
Format
Hardcopy
Hardcopy
Pwf¥idte
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
Systems design is used to create database definitions, business rules and procedures, screen
prototypes, and workflow definitions. Logical and physical database schemas, GUI style
preferences, application menu structure definitions, module data usage, screen prototypes,
report prototypes, and stored procedures are typically defined during systems design. Data
diagrams provide complete database designs. Module structure diagrams identify the
functionality the system will present to the users and how the modules are arranged to support
their tasks. Module data diagrams specify the internal structure of individual modules and are
used to support rapid prototyping of screens and reports.
System generation is used to build databases and applications from information contained in
the repository. Database objects, screens, and reports can all be generated from the information
recorded by the other modeling/design tools. Preferences and templates can be specified prior
to generation to allow a custom and consistent application to be developed.
The CASE modeling/design tools described above will be used at appropriate times during the
various phases of the system development life cycle. The diagrams and reports that can be
generated from the repository will be used as supporting information for many of the
deliverables that are created during each phase.
2.1.1.2 Review logical data models
The logical data model that is being created by EIIP/DMC and the existing logical data model
for the NET database must be reviewed to gain an understanding of the data requirements and
data relationships that exist in both of the models. The process of reviewing the two logical
models will allow TPMC to identify requirements in each model, recognize differences between
the two models, and begin the process of blending the two data models together. Details about
the logical review of the data models are described in the following two sub-tasks.
2.1.1.2.1 Review EIIP logical data model created by EIIP/DMC
The first step in developing the prototype database requires a review of the EIIP logical data
model to gain an understanding of the logical design. The logical model has been created by
the EIIP/DMC through contractual support from Eastern Research Group (ERG). This task
consists of reviewing the EIIP Phase I Data Model document from an analytical perspective
to identify database requirements that will effect the physical database design. There may be
a need to interact with ERG staff to clarify some data model questions to insure that we have
a clear understanding of why some design decisions were made and can effectively convert the
data model into a physical database design.
There are no formal outputs from this task; however, the analyst should create some notes and
document any questions/responses that are generated during the review process. The resources
that are required to complete this task are shown in the table below. Although we have
Technology Planning and Management Corporation
March 20,1997
Page 7
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
Rapid Application Development (RAD) becomes a viable option within the life cycle
methodology when CASE tools are used. A RAD methodology requires extensive user input
throughout the development and generates iterative working versions of application
components to provide a basis for end-user review and approval. This iterative development
approach with end-user review allows design flaws to be identified earlier in the process, can
be used to sell users and management on new concepts, and results in reducing the costs and
time for system development.
The CASE tool used must be repository based and must be team-oriented. When the CASE
tool is repository based the developers are able to reuse each other's work and share common
definitions. This sharing and reuse supports rapid development and consistency within the
system. Without a shared repository, effective reuse and sharing is impossible and consistency
and quality checking is much more difficult and time consuming. A team-oriented CASE tool
allows sharing where it is useful, provides a secure environment for work-in-progress, supports
repository browsing for component reuse, and maintains accurate documentation for the next
developer who needs to use a component.
CASE tools typically support process modeling, systems modeling, systems design, and systems
generation. Each modeling/design phase is used to create and refine information that describes
the system and is stored in the repository. For example, organization units, processes, data
flows, entities, relationships, business rules (constraints), and system development guidelines
are all contained within the repository. Once in the repository, they can be used to create the
database, forms, reports and database trigger, and stored procedure logic.
Process modeling is used to graphically model business processes that are performed to create
or add some kind of value for the customers or end-users. Each business process has well-
defined start and end points that are associated with an end-user. The models are usually
developed in a hierarchical arrangement, with major processes at the top and each having a
number of sub-processes. The process models help one understand what currently happens and
ensure that all of the identified processes are implemented in the system. The models can also
be used as a focus for people to agree on changing a process.
Systems modeling is used to create graphical function hierarchy diagrams, dataflow diagrams,
and entity-relationship diagrams. The function hierarchy diagrams are used to decompose the
business functions and show how the functions use data. The dataflow diagrams are used to
show functions, datastores, data flows and external datastores or functions. Dataflow diagrams
can be used to identify data dependencies, system components, and the context of the project.
The entity-relationship diagram identifies the information needs of the organization, the
properties (attributes) of the information, and the relationships among the various types of
information.
Technology Planning and Management Corporation
March 20,1997
Page 6
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
2 Technical Approach
This section of the Action Plan describes the technical approach that will be used to attain the
desired results of the delivery order. The tasks and sub-tasks required to attain the desired
results are described in detail in the following sub-sections.
2.1 Task Descriptions for Delivery Order Execution
The major tasks that must be performed are described in detail in subsequent sub-sections.
2.1.1 Develop Prototype Database
This task addresses the development of the prototype database based upon the logical data
model defined by the EIIP/DMC and the NET database design. Within this major task the
logical database will be designed, the physical database will be built, and selected datasets will
be loaded into the database for evaluation purposes. Additional modifications to the prototype
database may be made after evaluation by EPA/EFIG.
The following sections give an explanation of the database development methodology and a
description of each sub-task required to complete this major task.
2.1.1.1 Methodology
Computer-Aided Software Engineering (CASE) tools are used within the software
development life cycle with the goal of improving the efficiency of the development effort.
Improvements are typically obtained in the form of:
• Productivity gains
• Quality improvements
• Increased maintainability
• Reusability benefits
• Overall consistency
Productivity gains are realized through reduced development labor which usually also reduces
the elapsed time frame of the development project. The other improvements reduce the effort
required to support the system throughout its useful life. The proper use of CASE makes the
system easier to maintain and enhance the system, as well as making it easier to integrate with
other systems. One of the major benefits of a CASE tool is its ability to perform an impact
analysis prior to making any modifications.
Technology Planning and Management Corporation
March 20,1997
PageS
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
by the EIIP. The infrastructure requirements and the general responsibilities of the EIIP user
community will be delineated in the approach study.
Provide Technology Transfer. This major task involves providing a technical summary of the
EIIP data transfer prototype results. The technical summary will be used by the EDP/DMC as
a "lessons learned" document. Presentation materials that will be used by the DMC in the EIIP
technical transfer meetings will also be prepared as part of this task.
The major tasks just summarized and their individual sub-tasks are described in detail in
subsequent sections of this Action Plan.
Technology Planning and Management Corporation
March 20,1997
Page 4
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
retrieve data from the repository at the source and transmit it to the receiver(s). The
transmission will be in the EIIP data transfer format (for example, EDI X12).
The major tasks that must be performed during the execution of this project are:
• Develop a prototype database.
• Develop a prototype for electronic transmission of the EIIP formatted datasets (EDI
X12 standard) between pilot partners.
• Demonstrate the integrated electronic transmission and database prototypes to the
EIIP/DMC user community for evaluation.
• Develop an approach study.
• Provide technology transfer.
Develop a prototype database. This major task consists of designing and developing a
prototype database that is based upon the EIIP/DMC logical data model and the NET database
design. The prototype database will serve as the repository for EIEP formatted datasets that are
electronically submitted by pilot partners for the purposes of this database. The prototype
database will also serve as a model for the next-generation NET database which supports EFIG
reporting activities for emissions data.
Develop a prototype for electronic transmission of the EIIP formatted datasets (EDI X12
standard) between pilot partners. This major task consists of integrating multiple
components (modules) and manual procedures that demonstrate the viability of electronic
transmission of EIIP EDI X12 formatted datasets from one or more pilot partners (for example,
CARB and PADER) to EFIG. The scope of the prototype includes extraction of data from the
pilot partners database, translation of the data into an EICP X. 12 standard dataset, transmission
of the dataset to EFIG, translation of the data back out of the X. 12 dataset, and loading of the
data into the prototype database.
Demonstrate the integrated electronic transmission and database prototypes to the
EIIP/DMC user community for evaluation. This major task provides the EIIP/DMC user
community with the opportunity to review and evaluate the results of the prototype in regards
to the electronic transmission of EIIP inventory datasets using the EDI XI2 standard. The
demonstration will be comprehensive enough to illustrate clearly all of the steps required to
effectively perform an electronic transmission of an EIIP/DMC EDI XI2 standard dataset from
a pilot participant (for example, CARB and PADER) to EFIG. The demonstration will include
extraction of data from the pilot participant(s) database and the loading of the data into the
EFIG prototype database after being electronically transmitted as an X. 12 standard dataset.
Develop an Approach Study. This major task consists of documenting the actions required
to expand the data transfer method demonstrated by the prototype to the entire EIIP user
community. The approach study will be structured as an implementation plan for consideration
Technology Planning and Management Corporation
March 20, 1997
PageS
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
transfers can be effectively implemented based upon the results of the prototype
demonstrations.
The anticipated scope of the prototype is shown diagrammatically in the figure below.
El IP Data Transfer Method
Pilot
Participant's
Database
EFIG
Prototype
Database
At each location the same basic architecture will be provided by the prototype. A viewer
program to display the data in the local format will be used. An application interface to convert
the data to/from the recommended data model subset for transmission will be developed. The
transferred data will be held in an Oracle relational database designed according to the EIIP
data model. A transmission program (for example, ProComm, Crosstalk, FTP or Mosaic) will
Technology Planning and Management Corporation
March 20,1997
Page 2
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
1 Project Description
This section of the Action Plan provides a basis for understanding the project in regards to the
background, purpose, and scope of the project.
1.1 Project Background
The Clean Air Act Amendments of 1990 (CAAA) require that many States collect emission
inventory data that is an essential part of the infrastructure in managing environmental air
pollution at the local, state, regional, and federal levels. This has caused emissions inventory
data needs to be shared among many users for air quality modeling and the development of air
pollution control strategies. The Emissions Inventory Improvement Program (EIIP) is a joint
effort of state and local air agencies together with the EPA for the purpose of improving the
quality of the emissions data that is collected, as well as improving the way the data is
transferred and shared among users. The Data Management Committee (DMC) of the EIIP is
currently developing a standard data transfer format and will recommend a protocol for
electronic transmission of the inventory data within the user community.
It is these recommendations and data transfer standards being developed by the DMC that this
Delivery Order will demonstrate and assess. The prototype developed by this Delivery Order
will demonstrate the feasibility and practicality of the recommendations as well as provide the
documentation on how the data transfer protocol works. The Delivery Order team will also
develop an Approach Study to assess the impact in manpower, cost, and technological
resources necessary to implement the recommendations within the emission inventory user
community.
1.2 Project Scope and Purpose
The purpose of the project is to develop a prototype that tests the use of Electronic Data
Interchange (EDI) data transfer technology for exchanging emission inventory information
among trading partners. The prototype being developed under this Delivery Order consists of
integrating multiple components (modules) and manual procedures that demonstrate the
viability of electronic transmission of EIIP EDI X12 formatted datasets from one or more pilot
partners (for example, Pennsylvania Department of Environmental Resources (PADER) and
California Air Resources Board (CARB)) to EPA/EFIG. The scope of the prototype includes
extraction of data from the pilot partners) database into a data file compliant to A Data Format
(ADF) file specifications, translation of the data file via the ADF into an EIIP EDI X12
standard dataset, transmission of the dataset to EPA/EFIG, translation of the data out of the
X12 dataset into a second data file using a second ADF, and loading of the data from the
second data file into the prototype database. The project will also document how the data
Technology Planning and Management Corporation
March 20,1997
Pagel
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
Technology Planning and Management Corporation
March 20.1997
Page Hi
-------
Prototype Demonstration for Data Transfer Method with Approach Study
TSOSSS012(v.2.a)
Final Action Plan
1 Project Description 1
1.1 Project Background 1
1.2 Project Scope and Purpose 1
2 Technical Approach 5
2.1 Task Descriptions for Delivery Order Execution 5
2.1.1 Develop Prototype Database 5
2.1.2 Develop Data Transfer Prototype 20
2.1.3 Demonstrate Prototype 33
2.1.4 Support Technology Transfer 34
Technology Planning and Management Corporation
March 20,1997
-------
PROTYPE DEMONSTRATION FOR
DATA TRANSFER METHOD WITH
APPROACH STUDY
Final Action Plan
March 1997
Prepared by:
Technology Planning & Management
Corporation
DynCorp Information & Engineering
Technology
Prepared for:
Data Management Committee
Emission Inventory Improvement Program
-------
Report on Convention Maintenance 4/97
day rebuttal ballot (Step 8).
7. If the DM is provided to the subcommittee, it is evaluated and modified for return to
X12J, where the DM is submitted to the voting membership for a 45-day rebuttal ballot
(Step 8).
8. The voting membership votes on the 45-day rebuttal ballot. If the DM is approved, it is
included in the next version/release of the standard. If it is disapproved or invalid, the DM
is returned to the subcommittee for distribution to the voting membership. All DMs which
are continuing disapprovals are discussed at an open forum at the next triennial general
meeting (Step 9).
9. If, after the open forum, the DM maintains more than 10% continuing disapproval votes, it
is returned to Step 2. If it has less than 10%, it is included in the next version/release of
the standard.
Emission Inventory Improvement Program
-------
APPENDIX B
X12 DATA MAINTENANCE PROCESS
The ANSI/ASC X12 standards are updated three times a year (February, June, and October),
following general membership meetings. New versions/releases of the standard are issued and
published in paper form annually. There are interim releases issued in electronic form following
the February and June updates.
Any changes (DMs) to ANSI ASC XI2 Transaction Sets, data segments, data elements or code
lists must be submitted to the X12 committee for evaluation and membership approval before
being included in the standard. The process for DMs is detailed in theASC Standing Document
2: Operating Manual. A condensed version of the steps is as follows:
1. Each DM is submitted to Data Interchange Standards Association (DISA), which assigns
the request to X12J subcommittee (Technical Assessment).
2. Technical Assessment reviews the DM with respect to the current ANSI ASC X12 syntax
and design rules. The DM can be accepted or referred to another subcommittee at the
request of that subcommittee. If the DM is accepted, it moves to Step 5.
3. The subcommittee reviews the DM at the next triennial meeting. At the meeting, the
subcommittee may approve the DM; approve the DM with modifications; table the DM
until the next triennial meeting; or disapprove the DM. If the DM is accepted or accepted
with modifications, it moves to Step 4. If it is disapproved, the submitter of the DM is
notified.
4. All DMs and associated actions are reviewed by Technical Assessment at the same
triennial meeting in manner similar to Step 2. During the acceptance review, the
committee may modify a DM or send it to a subcommittee for review and modification. If
the DM is approved, it is submitted to the general membership for voting on the 90-day
ballot (Step 5). If it is disapproved, the submitter of the DM is notified.
5. On the 90-day ballot, the general membership votes on those DMs found by Technical
Assessment to be acceptable for voting. The vote can result in an approval, disapproval,
or invalid (if fewer than 20% votes are returned or more than 33 1/3% votes indicate
disapproval). If the DM is approved, it is included in the next version/release of the
standard. If it is disapproved or invalid, it moves to Step 6.
6. Technical Assessment reviews the ballot and determines whether modifications to the DM
are required. If the DM is disapproved, it is returned to the responsible subcommittee
(Step 7). If the vote was invalid it may be submitted to the voting membership for a 45-
Emission Inventory Improvement Program B-1
-------
Report on Convention Maintenance 4/97
This page intentionally left blank.
A-4 Emission Inventory Improvement Program
-------
4/97 Report on Convention Maintenance
X12 standards and the convention document.
EPA, The abbreviation for the United States Environmental Protection Agency. Established in
1970 by presidential executive order, it brings together parts of various government agencies
involved with the control of pollution. Note that some state environmental authorities may be
called EPA also, as in Illinois EPA.
Implementation Guideline, Instructions on the use of EDI for an individual business use of
EDI. Guidelines provide additional information about conducting EDI and may provide
assistance on how to implement EDI.
Standards, The technical documentation approved by ASC X12, including transaction sets,
segments, data elements, codes and interchange control structures. Standards provide the
structure for ASC X12.
Syntax, The grammar or rules that define the structure of the XI2 standards (i.e., the use of
loops, qualifiers, etc.). Syntax rules are published in ANSI/ASC XI2.6.
Third-Party Agreement, A legal agreement between the EDI trading partner and the third-
party service provider.
Third-Party Services, Organizations that provide value-added communication/transmission
services. Also see VAN.
Trading Partner, The sending and/or receiving party involved in the exchange of electronic
data interchange transmissions.
Trading Partner Agreement (TPA), Serves as the "interface specification" between trading
partners and provides specific details of the legal agreements that define how the electronic
commerce is to be conducted.
Transaction Set, A semantically meaningful unit of information exchanged between trading
partners.
VAN, The abbreviation for Value-Added Network. Also see Third-Party Services.
Version/Release, Identifies the publication of the standard being used for the generation or the
interpretation of data in the X12 standard format (e.g., Version 003040 means Version 3 Release
4).
Emission Inventory Improvement Program A-3
-------
Report on Convention Maintenance _ 4/97
Data Model, A description of the principles of organization of a database, including data
entities, attributes, relationships, and data specifications.
Data Set, The grouping of data that is being exchanged between the automated systems of
trading partners via EDI.
DISA, The abbreviation for the Data Interchange Standards Association. A non-profit
organization which serves as the Secretariat for X12.
DM , The abbreviation for a Data Maintenance Request. A formalized procedure by which
proposed changes to the existing X12 standards are presented for ANSI/ASC X12 committee
consensus and adoption into the standard.
DMC, The abbreviation for the Data Management Committee of the U.S. EPA Emission
Inventory Improvement Program responsible for the administration of issues related to air
emission modeling data.
EIIP, The abbreviation for the Emission Inventory Improvement Program sponsored by the EPA
to address the collection and use of air emission inventory/modeling information.
EDI, The abbreviation for electronic data interchange. Commonly defined as "the computer-to-
computer exchange of business information in a standard format." An EDI transmission is a
highly structured message intended for automated processing by a computer. It is meant to be
machine-readable so that it doesn't require human intervention to be interpreted and understood.
EDI is primarily used for intercompany communication. All references to EDI under U.S. EPA
programs refers to the utilization of ASC X12 standards.
EDI Translation, The conversion of application data to and from the X12 standard format.
EDI Translator, Computer software used to perform the conversion of application data to and
from the X12 standard format.
EDI Translator Configuration, The activity of inputting trading partner and EDI system
specifications into the EDI Translation Software. This process provides the translator with
essential information needed for translation and transmission of data. This information is often
documented in the Implementation Guideline and/or the Trading Partner Agreement.
EDI Translator Overlay, The computer code designed in the EDI translator which reflects the
requirements of the convention document and is consistent with the ASC X12 standards. It
functions to translate the data set to or from the required XI 2 format.
EDI Translator Overlay Mapping, The development of the overlay within the EDI
translation software in accordance with the requirements of the translator characteristics, the ASC
Emission Inventory Improvement Program
-------
APPENDIX A
GLOSSARY
ADF, The abbreviation for A Data Format. A textual description, usually in the form of a table,
that specifies the structure and data content of the flat file that is the input to or output from the
EDI translator. It is a technical document that is use in designing the application program
interface between the EDI translation software and the database system.
ANSI, The abbreviation for the American National Standards Institute (ANSI). The
national coordinator for standards in the United States.
API, The abbreviation for the application program interface (API). A computer program that
functions between the EDI translation software and the database system associated with the data
being exchanged.
ASC X12, The abbreviation for Accredited Standards Committee (ASC) X12. It is comprised
of a non-profit clearing house and coordination body for voluntary data standards activities in
U.S. The purpose is to develop uniform standards for the electronic interchange of business
transactions for submission to ANSI for subsequent approval and dissemination. X12 is the
subcommittee responsible for the development and maintenance of standards for Electronic Data
Interchange (EDI).
Communications, The transport of information in an EDI environment that may be by
physical (i.e., magnetic tape or courier service) or telecommunication (i.e., public or private
telecommunications system) means.
Convention Document, Common practices and/or interpretations of the use of the ASC XI2
standards, as agreed upon by two or more trading partners. Conventions define what is included
in a specific implementation of an ASC X12 standard.
Convention Document Mapping, The development of the convention document by
selecting the appropriate X12 structures for implementation in accordance with the requirements
of the ASC X12 standards and the business process.
Database System, In this usage, it is the automated data storage mechanism (i.e., database,
spreadsheet, etc.) for data being exchanged within an EDI system. Also referred to as Automated
System.
Data Element, A data element can represent a qualifier, a value, or text (such as a
description).
Emission Inventory Improvement Program A-1
-------
Report on Convention Maintenance 4/97
for the EIIP EDI project include the EPA, state and local agencies, and industries related to air
emission reporting.
The communication between trading partners is often formalized through the use of Trading
Partner Agreements (TPAs), memorada of understanding, and/or conventions of use. These
agreements serve as the "interface specification" between trading partners and provide specific
details of the legal agreements that define how the electronic commerce is to be conducted.
Qualified legal advice is required when a TPA is drafted.
The TPA must be more than a legal agreement between two organizations that exchange data.
Because the use of an electronic medium affects the trade relationship, TPAs are generally
recognized as fundamental to the EDI trade relationship. TPAs can bolster the use of the EDI
system, ensure the validity of the transmissions, open communication, define legal considerations,
and help educate partners.
As with the use of a third-party agreement, the TPA is a legal document that must be maintained
in accordance with changes to the business processes and requirements, trading partner
relationships, and the EDI system. To facilitate this maintenance, individuals knowledgeable in
the various aspects of the EDI systems should be involved, as should the support of legal staff.
5-12 Emission Inventory Improvement Program
-------
4/97 Report on Convention Maintenance
Before data transfer begins with a third-party service, communications should be mutually defined
and agreed upon. The use of third-party communications should be transparent to trading
partners. To assist in this transparency, when establishing an EDI partnership, it is necessary to
determine how the costs of third-party services will be apportioned. These costs are usually split
equally between the trading partners. Costs associated with the use of a third-party service often
include:
• Start-up charges;
• Mailbox fees;
• Connect charges;
• Data storage;
• Network interconnect;
• Character charges; and
• Management reports.
When employing a third-party service provider to facilitate its EDI system, certain contractual
agreements should be made. These agreements are typically made in the form of a third-party, or
data communications, agreement. Among the general issues that the agreement might include are:
specific services to be provided; warranties by the VAN; the liability of the VAN; security,
confidentiality, and integrity of messages handled by the VAN; system failure or disaster;
applicable pricing structure; and termination of the agreement.
As the implementation of the EDI system changes, the requirements for EDI communications may
as well. Changes including fluctuation in the number of transaction sets being transmitted, level of
activity, security needs, cost effectiveness, and a host of other business and EDI-related needs can
affect the communications being used. If a point-to-point type of communication is being used,
its maintenance should be the responsibility of an individual experienced in telecommunications.
If a VAN is being employed, changes to the EDI system affect more than just the physical
communications lines. Although the maintenance of communications lines is not a direct concern,
the third-party agreement that was entered into upon initiating the communications relationship
will have to be maintained. The maintenance of this component should involve not only staff
familiar with the specific EDI implementation, but legal support as well.
TRADING PARTNERS
Trading partners, or those organizations with which business information is exchanged, are
perhaps the most important aspect of a functional EDI system. Without solid relationships with
other organizations, the exchange of information via EDI can not be optimized. Trading partners
must be identified who are willing and able to use EDI. Once identified, these relationships must
be formalized and maintained. Open communication between trading partners with respect to
EDI capabilities, information requirements, and business needs is essential. The trading partners
Emission Inventory Improvement Program 5-11
-------
Report on Convention Maintenance 4/97
the trading partners' communication needs. No matter which approach is selected, a contingency
plan should be formulated to address the possible event of a communication failure.
The EDI communication system includes the determination and use of EDI data transfer protocols
and transmission protocols. Protocols are a set of conventions between communicating devices.
Simple protocols define only hardware configuration. More complex protocols define timings,
data formats, error detection, and correction techniques. In the case of EDI data transfer
protocols, issues related to communication capabilities, security, and data integrity, must be
addressed. Transmission protocols pose more technical issues as they specify the type of
transmission that will occur. Transmission protocols include: character-oriented, asynchronous,
binary, and bit-oriented protocols.
EDI communications can be accomplished in two manners, point-to-point or through the use of a
third-party service provider. Point-to-point or direct connect service is communication between
two trading partners. Point-to-point may employ dedicated circuits, or dial circuits, or a
combination of the two. The type of circuit used depends on a number of factors, two of which
are volume and speed or timing of the transmissions.
An EDI user that elects direct communication with trading partners must have the necessary in-
house staff capable of managing the network and must address a number of issues with each
individual trading partner. Some of these issues include: service levels; communication speeds;
transmission modes; modem capabilities; and line protocols. Additionally, an EDI user electing to
implement direct connections must be aware that not all trading partners have similar capabilities,
and therefore may, by necessity, elect to use a third-party service.
Third-party services use switched network technology and provide value-added services.
Switched networks connect and disconnect circuits as required to exchange data. The three
common switched network methods are circuit switching, message switching, and packet
switching.
Such facilities and services may be obtained from commercial networks called Value-Added
Networks (VANs) rather than being developed in-house. The commercial networks provide
network management and knowledgeable staff to support an organization's communication
requirements. Commercial networks now offer more than moving data from one site to another.
Services provided include mailbox service, data storage, speed and format conversion, and
translation.
Not all companies have the communication facilities to accommodate the multiple communication
protocols that may be used by their potential trading partners. Third-party service providers
eliminate the need for a trading partner to invest heavily in communication hardware, software,
and personnel. A third-party service provider allows the convenience of a single data transfer link
to multiple trading partners independent of operating schedules, protocol conversion, hardware
interface, and conversion requirements. The Internet can also be considered a third-party service.
It is, however, a limited value-added network as it only provides data transfer capabilities.
-*" *0 Emission Inventory Improvement Program
-------
4/97 Report on Convention Maintenance
documented and communicated to the party responsible for the API.
In addition, if the data or their organization within the database system changes, modifications to
the convention document may be necessary. If the data or data relationships are affected by
enhancements to the database system, and therefore the convention document, all components
related to the EDI system may require maintenance. The actual level of maintenance varies from
occurrence to occurrence, but the maintenance of the database system must be recognized as a
significant source of maintenance.
SYSTEM HARDWARE
In order for the EDI system to function optimally, it must be supported by the appropriate
computer hardware infrastructure. Whether the EDI system is functioning on a stand alone
workstation, a networked PC, or a mainframe system, the associated hardware must be
maintained and upgraded to accommodate the EDI transmissions. The data storage devises and
media, telecommunication pieces (i.e., modems), and other hardware components must be
accounted for in the general maintenance of the EDI system. As with many other aspects of the
system, the level of maintenance varies widely based on the organization's environment and
implementation. Regardless of the complexity of the maintenance, it typically requires specific
expertise and should be the responsibility of the appropriate technical staff.
COMMUNICATIONS
Communications is the transport of information in an EDI environment and may be performed by
physical or telecommunication means. Physical communication includes the use of magnetic tape
and/or courier service. Telecommunication includes the use of a public or private
telecommunications network. There is no single or preferred solution. Each trading partner must
determine the proper approach based on current and projected transaction volumes and desired
level of investment. Criteria to be considered when determining the communication mode of data
transfer may include:
• Di stance of transport;
• Number of destinations;
• Associated costs;
• Delivery time frame;
• Frequency of transport;
• Security;
• Volume of transactions;
• Compatibility of media; and
• Overall reliability.
Each communication method should be analyzed to determine whether or not the approach meets
Emission Inventory Improvement Program 5-9
-------
Report on Convention Maintenance 4/97
An important function of the API is to enforce the data requirements and rules detailed in the
implementation guideline. The API is the component of the EDI system that manages the data
being transmitted within the context of the business process. As the EIIP EDI X12 Convention
Document contains other inventory types and therefore necessitates the creation of an
implementation guideline for each, an API may need to be developed for each as well.
Similar to accounting for the requirements of the data associated with a specific inventory type, if
any level of quality assurance or data validation is to occur, the necessary functionality must be
included in the API. Generally, the quality assurance functions are directly related to rules
specified in the convention document; however, if additional levels of data validation or quality
assurance are necessary, they must be included at this point in the EDI process.
As each EDI system has at least two trading partners involved with each EDI transaction, there
are also two APIs. For the sender function, the API accesses the data set(s) containing the data
to be transferred, performs the required data management/quality assurance, creates a flat file as
defined by the ADF, and then transfers the data, in the ADF format, to the EDI translator. The
initial function of the API is to access the appropriate data set(s). As a result, because the
translator must be programmed to provide interaction with the data set(s), the architecture of the
data set(s) must be identified and incorporated into the design of the API.
Upon receipt, the reverse process takes place. The API first retrieves the flat file from the
translator (both the sender and the receiver have individual translators). This flat file is structured
according to the ADF appropriate for the receiving translator. The data in the flat file is then
structured to allow updating of the application data set(s). Also at this point, the data is
processed according to any quality assurance or data validation that is required by the receiver.
The output of the receiving API is an updated application data set.
The API is the component of the EDI system that is most dependant upon the rest of the system.
The convention document, the implementation guideline, the ADF, the translator, and the
database system all have an impact on the API. As a result, the maintenance of this piece of
software can be demanding. Changes to any of the processes, documentation, or components of
the EDI system may force the API software to be changed. The scope of the maintenance for the
API varies widely depending upon the source and significance of the change being imposed. In
the case of the API, as with any other software components, an individual with expertise in
software development should be employed for this maintenance.
DATABASE SYSTEM
The database system associated with the EDI system also plays a role in the maintenance of the
EDI system. Although much of the EDI system is designed to be relatively independent of the
database system, changes to it can affect the API directly. Because the API bridges the database
system and the EDI translation software, any modifications to the database system must be
5-8 Emission Inventory Improvement Program
-------
Report on Convention Maintenance
expands. Similarly, this sort of information is found in the implementation guideline. Therefore,
revisions to the implementation guideline may generate some maintenance to the translator
configuration. Like maintaining the overlay, updates of this nature should be performed by an
individual skilled with the translation software.
A DATA FORMAT
A data format (ADF) is a textual description, usually in the form of a table, that specifies the
structure and data content of the flat file that is the input to, or output from, the EDI translator.
As each EDI translator has unique requirements in order to operate, it is required that the data
being received by, or output from, it be in the appropriate structure. As discussed previously, a
primary function of the application program interface (API) is to ensure that the data flat file
meets the structure described in the ADF requirements. The API developer relies on the structure
and data specified in the ADF to program the API. At a minimum, the developer is provided with
the following information:
• Application field name;
• ADF field name/structure;
• Data type;
• Data field length;
• Number of field occurrences; and
• Any comments, descriptions, or X12 positions that are applicable.
Depending upon the EDI translation software being used, this information may be automatically
generated as a function of the translator.
The ADF communicates the data requirements for the EDI system and is therefore based on the
convention document and implementation guideline. This being the case, changes to either of
these documents may introduce changes to the ADF. The ADF should be maintained by an
individual that is versed in the specifications of the convention document and implementation
guideline and is familiar with the data structure requirements of the translation software. This
person is typically the EDI support technician.
APPLICATION PROGRAM INTERFACE
The application program interface (API) is a computer program that functions between the EDI
translator and the data set that is being transferred. A primary function of the API is to process
the flat file of the data as specified by the ADF. To accomplish this, the API is designed to, at a
minimum, ensure that the data elements and formats required by ANSI/ASC X12, the convention
document, and the implementation guideline are present and in the correct order and format for
proper translation.
Emission Inventory Improvement Program 5-7
-------
Report on Convention Maintenance 4/97
communication of the EIIP data requirements. The convention document is the "blue print" for
the overlay.
The scope of the mapping effort is in direct relation to the content and complexity of the
convention document on which it is based, the data structure that is inherent to the translator, and
the mapping utilities, if any, that are included with the translator.
The data requirements of the translator also affect other software-related EDI components.
These requirements impact the development of a data format (ADF) and subsequently the
application program interface, which are explained later in this section. The program structure
often necessitates the inclusion of data elements and/or data formats that are not part of the X12
standards, but are necessary for the performance of the translator. As the accommodation of the
ADF is an essential function of the API, the translator structure also impacts the development of
the API.
Because the translator overlay corresponds to the convention document, its maintenance is
directly related to convention document maintenance activities. Any adjustment to the convention
document, must also be made to the overlay. As such, the changes must be communicated to the
party responsible for the overlay, typically the technical EDI support staff. The level of effort
associated with maintaining the overlay is dependant upon the magnitude of the changes and the
update functions of the translation software. In all cases, the responsibility for actually updating
the overlay should be with an individual familiar with the translation software.
EDI Translator Configuration
Once the overlay is created, the translator is configured for the specific trading partner that will be
using it. As with previous activities, the characteristics of the translator have a direct effect on
how it is configured; however, this step also takes into account the characteristics of the user
environment. More highly functional translators provide intuitive configuration features, but all
translators must be configured to some extent. The configuration of the translator generally
includes, but is not limited to, specifying within the software the following information:
• The system environment on which the translator will function;
• The type of telecommunication (e.g., modem type) that will be used to transmit the
data;
• The EDI interchange information; and
• Trading partner information including, trading partner organization names, log-on
identifiers (IDs), and other pertinent information for the trading partners that the
translator will connect with.
This type of information would have to be modified with each change in trading partners. As a
result, routine maintenance to this part of the translation software is necessary as the EDI system
5-6 Emission Inventory Improvement Program
-------
4/97 Report on Convention Maintenance
essential step in the EDI system because it is the XI2 standard format that allows the data to be
communicated between dissimilar automated systems. Each EDI transmission system is
comprised of two EDI translators, one at the sender's end to translate the data into XI2 format
and one at the receiver's end to retranslate the data from XI2 format to the format necessary for
their system.
The characteristics of individual EDI translators vary widely. Some translators are designed to
perform on a personal computer (PC) platform, while others operate from a minicomputer or
mainframe environment. There are also differences in the telecommunication options that
translators will accommodate. Many of the translators are more "user friendly" than others,
providing easier transaction set mapping utilities. Each type of translator also has a different
internal program structure which affects the development of other components of the EDI system.
A final important aspect of the EDI translation software is the actual functionality of the
translator. Less complex translators simply translate the data into X12 format, while others with
enhanced functions, perform edits for compliance with X12 syntax and semantics. Most all
translators provide some form of automated verification feature which checks for proper structure
(as specified by the translator) and X12 syntax requirements during translation. Based on the
verification, varied error messages are generated to indicate discrepancies in the data being
transferred. It must be noted that thqLEDI Translator does not perform quality assurance or
validation of the data for completeness or correctness with respect to the user's application. This
function must be performed with the application program interface.
The maintenance required for EDI translation software is dependant upon the specific translator
being employed. Because the characteristics of each translator vary, maintenance levels also vary.
However, certain maintenance points are common to all software, such as license renewal, version
updates, support agreements, etc. Maintenance of the software may also be impacted by the
maintenance of the environment on which it operates (i.e., server upgrades, operating platform
changes, etc.). All of these issues are typically the responsibility of the information systems
technical staff that is supporting the EDI system.
EDI TRANSLATOR OVERLAY
Upon the selection of the translator, an overlay is created by mapping the specifications of the
convention document and the implementation guideline into the translator software. The
requirements from the convention document specify transaction set-specific information (e.g.,
data elements, data types, data format, etc.), and the implementation guideline requirements
include transmission-specific information (e.g., trading partners, transmission timing, location
identification, etc.). The translator software is pre-programmed to accommodate the various
transaction set standards developed by ANSI/ASC X12. In the case of the EIIP EDI project, the
841 Transaction Set contained in the translation software is customized to the specifications
detailed in the EIIP EDI X12 Convention Document. As the overlay is the electronic equivalent
of the convention document, it is the primary tool that ensures the consistent electronic
Emission Inventory Improvement Program 5-5
-------
Report on Convention Maintenance 4/97
• Background about ANSI/ASC X12;
• Discussion about the use, and issues related (i.e., points of contact, security, and
roles and responsibilities, etc.) to EDI implementation; and
• How to employ the convention document within the context of the business
process.
This later role is essential because it communicates information between the trading partners (i.e.,
sender and receiver) that is critical for effective data usage. With respect to a given business
process, the implementation guideline describes the type of data being transmitted, the format of
the data, and rules by which the data are applied (e.g., mandatory fields, number of iterations,
viable codes, etc.). Although some of this information is also detailed in the convention
document, the implementation guideline provides application context and usage rules to the data.
An implementation guideline is developed for each business process supported by the convention
document. In the case of the EIEP EDI project, the convention document is designed to transfer
data for 11 inventory types. As a result, a minimum of 11 separate implementation guidelines
must exist. As the EIIP EDI XI2 Convention Document is built to provide flexibility in the types
of data able to be transferred, use of it without specific implementation guidelines to provide
context would limit the usefulness of the data transferred.
Like most of the EDI system documentation, the implementation guideline must be updated to
support changes to the program's activities. Because the guideline provides so much essential
information to the trading partners, it must be maintained to reflect all information that has a
direct impact on the EDI implementation. The EICP EDI Implementation Guideline must be
updated to reflect changes in the data requirements (i.e., changes to inventory reporting
requirements) and overall EDI implementation (i.e., security, points of contact, responsibility,
etc.). In addition to the content of the guideline itself, its appendices must also be maintained. As
the EIIP EDI X12 Convention Document is a major component of the implementation guideline,
the maintenance of both documents are related and essential.
Because the EIIP EDI Implementation Guideline is a document that integrates several aspects of
the EDI system, its maintenance becomes the responsibility of a number of parties. Typically, the
individuals who developed the implementation guideline are responsible for ensuring its
maintenance. As it contains information about the program's requirements, the program
coordinator must play a role and, with the convention document as an attachment, the party
responsible for technical EDI support/development must also be included in maintaining the
guideline.
EDI TRANSLATION SOFTWARE
The EDI translator is a software program that converts the data being transferred into, or from, a
format specified by ANSI/ASC X12 for transmission between the trading partners. This is an
5 -4 Emission Inventory Improvement Program
-------
4/97 Report on Convention Maintenance
critical. In order for the convention document to be viable (as it directly reflects the data model),
the data model must be accurate and timely with respect to business process (i.e., air emission
inventory) requirements. Maintenance of the data model includes routine analysis of the model
relative to the program's data and data relationship requirements. Updates to the data model
must be performed in a consistent manner and be well documented for use with convention
document development activities. Any changes to the data model will be incorporated into the
EHP EDI X12 Convention Document for implementation.
In addition to the data model, any other process-related documentation must also be maintained.
These documents may include, coding conventions, forms/data sheets, reporting
requirements/regulations, educational papers, project overviews, system descriptions — any
document that defines some aspect of the business process.
The program administrator is responsible for the maintenance of these documents because they
are associated with the overall program. In the case of the EHP, the DMC is responsible for the
maintenance and documentation of the Phase IEIIP Data Model and other program/ process-
related information.
IMPLEMENTATION GUIDELINE
The EIIP EDI Implementation Guideline is a textual document that describes, in business terms,
the use of the EIIP EDI X12 Convention Document for the exchange of data under a specified
emission source type and inventory type (e.g., Base Year State Implementation Plan Inventory,
Reasonable Further Progress Inventory, etc.). The guideline is based on \heEPA EDI
Implementation Guideline, the specifications in the EIIP EDI X12 Convention Document, and
most importantly, the reporting rules related to the individual process to which the EDI system is
employed.
The EIIP EDI Implementation Guideline was developed through the cooperative efforts of
individuals knowledgeable in X12 standards and the EIIP EDI X12 Convention Document, and
those individuals with in-depth knowledge of the reporting and data requirements of the business
process for which the guideline is being written. These process champions serve the most
important role in the development of the guidance. They are responsible for identifying the
processes with which the EDI system will be interfaced and providing information about the data
specifically associated with the process. In many cases, the business process is directly based on a
specific form, report, or data file. When this is the case, the implementation guideline is designed
to reflect the content of the applicable form, report, or data file.
An implementation guideline includes, but is not limited to, the following information:
Background about the EDI project to which it pertains;
A general description of EDI;
Emission Inventory Improvement Program 5-3
-------
Report on Convention Maintenance 4/97
performs its intended role, stays aligned with other electronic commerce initiatives within the
organization, is an asset, expands to meet the demands of the business and technology, and
provides a basis for future efficiencies.
Similarly, business issues that may impact the EDI system must also be identified, analyzed, and
managed/maintained. Because EDI serves a specific business process, it is subject to change
based on the dynamics of that business. This can often be a very vulnerable position when the
EDI system is being relied upon to exchange mission critical information or to support other
essential business needs. The EDI system must be attuned to, and work harmoniously with, the
business (and related issues) it supports. As such, the system must be maintained in a manner that
takes business issues into account and attempts to adapt to the issues before it is forced to merely
react.
The maintenance of management support and business issues is the responsibility of everyone who
is involved with the EDI system. The system only functions optimally when it is fully integrated
and maintained. As such, any party responsible for a given component has an impact on the
maintenance of management support and other business issues. Although this is a team approach,
management support is often the ultimate responsibility of the EDI program administration or the
individual(s) who actually manage the overall project. These individuals are typically the primary
interface with other organizational management. As a result, this individual(s) must stay informed
about the status of each EDI component, future development plans, and any issues that may affect
the EDI system and/or higher level management support.
DATA MODEL/PROCESS DOCUMENTATION
The Phase IEIIP Data Model details the data elements and their interrelationships as identified by
the EIIP Data Management Committee (DMC). The data model is the foundation of the EIIP
EDI data transfer activities and is essential for directing the prototype activities.
The data model is driven by the practical knowledge of the DMC participants regarding
programattic reporting requirements, processes, and associated data. The content of the data
model addresses the most widely used or relevant reporting requirements of the major emission
sources (point, area, mobile, and biogenic).
Each of the four emission source data models provides a graphical representation of the data
domains, their relationships, and an associated data dictionary. The dictionary contains the data
elements, the description of each data element as applied to the EIIP, the type of data that is valid
for each element, the entity in which the individual elements are applied, the element's domain (if
applicable), and an indication of the relationship of each element to the table structure (e.g.,
foreign key, required attribute, etc.).
Because the data model is a foundation piece for the whole EDI system, its maintenance is
5-2 Emission Inventory Improvement Program
-------
5
EDI SYSTEM COMPONENTS
OVERVIEW OF EDI SYSTEM COMPONENT MAINTENANCE ISSUES
A production EDI system is comprised of several integrated components. These components
include:
Management Support
Data Model
XI2 Transaction Set
Convention Document
Implementation Guideline
EDI Translation Software
A Data Format
Application Program Interface
Database System
System Hardware
Communications
Trading Partners
Each plays an integral role in enabling the electronic transfer of data between the automated
systems of trading partners. This section provides a general overview of each of the primary EDI
components and briefly outlines their function and maintenance requirements. The information
provided is focused specifically on its relationship to the EDI system. Many of the components
may require maintenance outside of that which is necessary for the functioning of the EDI system.
These elements are not specifically discussed.
MANAGEMENT SUPPORT/BUSINESS ISSUES
Management support is an essential component of a successful EDI system. In order for a system
to be initiated, implemented, and maintained, it must be viewed as an asset by an organization's
management. Management support for an EDI system often provides specification of the business
processes that will employ EDI, initial and ongoing financial investment, direction regarding the
implementation of the EDI system, decision making related to information systems, and the
development of trading partner relationships. Although these are only a few of the roles that
management and its support may play in an EDI system, they are certainly essential.
Management support is the first and underlying component to every aspect of the EDI system and
therefore its maintenance is of utmost importance. Steps must be taken to ensure the continued
support of management. Maintenance of this support involves ensuring that the EDI system
Emission Inventory Improvement Program 5-1
-------
Report on Convention Maintenance 4/97
understanding of both facets.
An equally significant maintenance issue, that is more directly under the control of the EH?, is
related to changes in the program itself. As the EIIP evolves, the modifications to the data
exchange needs must be mapped into the EIIP EDI X12 Convention Document. This mapping
activity is performed by analyzing the appropriate version/release of the X12 Transaction Set to
identify the necessary data structure(s) needed relative to the business process. For example, the
EIIP is currently employing the ASC X12 841 Transaction Set version/release 3060 for
exchanging air emission inventory data. If this data transfer application were to change (e.g., add
data attributes) the convention document would have to change accordingly (e.g., add X12 data
elements).
Once the ASC X12 data structures are identified, the convention document is updated in
accordance with the specifications of the standard (transaction set). If data needs are identified
that are not currently present in the standard, the DM process describe in Section 3 would be
pursued. Through this process, the data structures needed by the program may be added to the
national standard. Upon adoption by ASC XI2, those structures could then be added to the EIIP
EDI XI2 Convention Document.
Similarly, the EIIP EDI X12 Convention Document contains many code lists which are unique to
the emission inventory application and the EIIP implementation. As such, the codes are not
maintained by ANSI/ASC X12. To avoid confusion during implementation, it is imperative that
the EIIP codes are maintained in a consistent and controlled manner so that all users of the EIIP
EDI X12 Convention Document apply the same codes with their data. This is another major
maintenance facet that impacts the convention document and could affect other EUP documents,
such as the data model.
In summary, the activities associated with maintaining the EDI convention document include:
• Map the selected transaction set relative to the intended implementation;
• Monitor changes in the business process relative to the transaction set and update
the convention document accordingly;
• Monitor changes in the transaction set relative to the business process and update
the convention document accordingly; and
• Maintain programmatic code lists (i.e., not X12-related codes) to ensure accuracy
of data.
4-2 Emission Inventory Improvement Program
-------
4
CONVENTION DOCUMENT
EDI CONVENTION DOCUMENT MAINTENANCE ISSUES
The EUP EDI X12 Convention Document is the textual representation of the X12 Transaction
Set being employed with the EHP EDI project. The document is a subset of the ANSI/ASC X12
841-Specifications/Technical Information Transaction Set. The subset is designed based on the
requirements detailed in the Phase IEITP Data Model and complies with all X12 design rules.
The convention document is the basis for all EDI implementations under the EHP EDI project and
is essential for directing the program's EDI prototype effort.
The convention document development effort was completed through the cooperative efforts of
individuals knowledgeable in XI2 standards/procedures and champions of the specific emission
source models and the information included with the Phase IEIIP Data Model. The convention
document is a single document that encompasses each four of the four defined emission sources
(point, area, mobile, and biogenic). It contains all of the transaction set components required by
XI2 (e.g., loops, segments, elements, usage notes, etc.), all data elements and related attributes
specified in the data model, notes that highlight differences in transaction set components (i.e.,
semantics of data with respect to usage for multiple emission source reporting), and examples of
data structure with respect to the transaction set architecture.
The EHP EDI X12 Convention Document is directly linked to the X12 standard on which it is
based. Therefore, its maintenance is related to changes to the transaction set. As indicated at the
end of Section 3, the EIIP must evaluate each version/release of the X12 Transaction Set to
determine whether it contains changes that should be included in the program's implementation.
These changes are ultimately driven by ASC X12 and will have a varied in impact to the EIIP. If
it is determined that the changes to the standard are significant enough, the program would decide
to upgrade to the new version/release.
If the decision is made to upgrade to the next version/release, as the content/requirements of the
X12 Transaction Set changes, so must the convention document. Although the EIIP EDI X12
Convention Document is developed by, and subject to, the management decisions of the EIIP, it
must always remain consistent with the corresponding version release of the X12 841 Transaction
Set on which it is based. This is essential because the convention document is the cornerstone
technical document for the other components of the EDI system, including the EDI translator, the
implementation guideline, application program interface, and other system documentation.
As with transaction set maintenance, convention document maintenance is usually the
responsibility of the program's EDI coordinator or equivalent. Because this function brings
together knowledge of X12 and the program's business needs, the responsible party must have an
Emission Inventory Improvement Program 4-1
-------
Report on Convention Maintenance 4/97
This page intentionally left blank.
3 -4 Emission Inventory Improvement Program
-------
4/97 Report on Convention Maintenance
• Monitor changes in the business process relative to the transaction set; and
• Monitor changes in the transaction set relative to the business process.
Emission Inventory Improvement Program 3-3
-------
Report on Convention Maintenance 4/97
structures have been necessary. These modifications have been developed and submitted in a
manner consistent with the XI2 guidelines. To help ensure that the needs of the program are
realized, EIIP representatives presented the DMs to ASC X12. Attendance at the committee
meetings provides additional emphasis on the need for the requested changes. This personal
involvement in the DM process is often essential to ensure the timely adoption of DMs.
As the EIIP EDI project matures and its scope expands, additional modifications to the
transaction set are likely. If future releases/versions of the 841 Transaction Set do not support the
structures or codes needed for the EIIP implementation, further DMs will be necessary. The
awareness of the transaction set relative to the dynamic needs of the program and the subsequent
modification activities constitute a major maintenance factor.
In general, the significant issues related to the maintenance of the ANSI/ASC X12 841
Transaction Set that are driven by the EIIP include: understanding the standards and the business
needs, identifying the changes in both, submitting the necessary DMs in accordance with X12
guidance, and personally representing the program. The responsibility for these maintenance
issues is typically associated with the program's EDI coordinator or other party that is versed in
XI2 and the business needs of the EIIP.
A second major category of transaction set maintenance issues are those changes that are imposed
by the gradual evolution of the standard itself. Just as the EIIP submits DMs to ASC XI2, other
users of the 841 Transaction Set do the same. The combined affect of the DMs results in overall
enhancement of the transaction set.
As alluded to above, attention must be paid to each version/release of the ANSI/ASC X12 841
Transaction Set. As each version may include changes that may be necessary for the EIIP's
implementation, the program must be aware of the content of each standard. Once the changes
have been identified, they should be evaluated to determine whether to adopt that version/release
(i.e., upgrade) for use with the program.
It is not required that the EIIP EDI program upgrade with each version/release of the X12
standards. The decision must be based on the scope of the changes included in the version/release
and whether they provide functionality that is required for optimal use with the EIIP EDI system.
Although these changes may impact the program's implementation in varying amounts, their
possible impact poses a significant maintenance concern. The EIIP EDI project is currently using
version/release 3060. However with the adoption of the DMs requested, the program will
upgrade to the next full version/release.
In summary, the activities associated with maintaining the ANSI/ASC X12 EDI standards include:
• Identify the appropriate transaction set relative to the intended implementation;
• Identify the necessary enhancements (if necessary) to the standard;
• Present the proposed changes in the manner specified by ASC XI2 for DMs;
• Represent the DMs, in person, at the ASC X12 meeting to help ensure adoption;
3-2 Emission Inventory Improvement Program
-------
3
ANSI/ASC X12 TRANSACTION SETS
ANSI/ASC X12 EDI STANDARDS MAINTENANCE ISSUES
The ANSI/ASC X12 Transaction Set is the standard that allows automated systems to exchange
data. As mentioned above, the transaction sets are maintained by the subcommittees of the ASC
X12. Within these committees new standards (transaction sets) are developed, current standards
are modified, and the rules by which the standards are implemented are maintained. As the
transaction sets are administered by ANSI/ASC X12, individual users can not directly change the
standards. The development and evolution of transaction sets is initiated at the request of an
individual implementer, such as the EIIP, but actual adoption is the ultimate responsibility of the
ASC XI2. The standards modification process and the impact that it has on the EIIP EDI project
are described below.
The modification of ANSI/ASC X12 standards impacts the EIIP EDI implementation in two
significant ways. The first type are changes that are driven by EIIP's use of the standard. In
order to develop a standard that optimally supports the data requirements of the EUP, certain
modifications to the existing ANSI/ASC XI2 841- Specifications/Technical Information
Transaction Set were necessary. These changes were recorded and presented to ASC XI2 as
data maintenance (DM) requests. A data maintenance request is a formalized procedure by which
proposed changes to the existing X12 standards are presented for ASC X12 committee consensus
and adoption into the standard.
The overall process by which the standards are developed, and DMs are approved, is performed
in accordance with strict guidelines and is often complex and time consuming. The nature of the
standards development and modification process adds to the scope of transaction set maintenance.
The process by which a standard is reviewed by ASC X12 is detailed in Appendix B. This
evaluation process and the subsequent changes to the XI2 standards have a profound impact on
the maintenance of the transaction set being used with the EUP EDI project. Therefore, the
detailed description provides important insights for the EIIP implementation.
The minimum time to accomplish any change to the ANSI/ASC X12 standard is nine months. All
DMs associated with the transaction set being used by the EUP EDI project will be assessed in
accordance with the X12 procedures. This includes any DMs to modify the ANSI/ASC X12 841
Transaction Set segments, data elements, code lists, or syntax/usage rules that are currently
specified by the standard.
The EIIP EDI project has already required modifications to the 841 Transaction Set. Through the
EIIP EDI project, additional data element qualifier codes, units of measure, and even X12
Emission Inventory Improvement Program 3-1
-------
Report on Convention Maintenance 4/97
Transaction Set. This transaction set was selected because it is designed to exchange technical
information and therefore, the structure and syntax of the standard enables the air emission
inventory data required by the project to be transferred.
EDI CONVENTION DOCUMENTS
When an organization implements an EDI solution to exchange business-related data, a number of
components critical to the EDI system must be secured. Along with obtaining the necessary
technology (e.g., computer hardware, software, and telecommunications), the organization must
apply the appropriate ANSI/ASC X12 Transaction Set for their business needs. As stated above,
each standard (transaction set) is designed to support a specific type of data. Therefore, it is
essential that a transaction set be selected that appropriately corresponds with the business
application.
Once an transaction set has been selected, it is analyzed and mapped to the individual data
element requirements specified by the organization's business systems (e.g., EIIP application for
transferring air emission inventory data). The mapping activity generally entails analyzing the data
requirements of the business application using a structured techniques (i.e., data modeling and/or
data flow analysis) and identifying the appropriate location within the transaction set where the
data requirements can be supported. Mapping is performed in accordance with strict use and
syntax rules specified by ANSI/ASC X12.
The result of this effort is an EDI convention document. This document details technical, X12-
related information as it pertains to the particular business use. It specifies the required X12 data
structures, use and syntax rules, and important user notes that must be applied when exchanging
data using the organization's EDI system. The convention document differs from the transaction
set on which it is based in that it contains only those standards-based data structures that are
required to perform the business function and meet the standard syntax rules.
The EIIP has developed the EIIP EDI X12 Convention Document, based on the ANSI/ASC X12
841 Transaction Set, for the exchange of air emission inventory data. The design of the document
is consistent with X12 rules and contains the data structures specified and/or required by the X12
standards and the Phase I EIIP Data Model.
The ANSI/ASC XI2 standards are the foundation of the EIIP EDI solution and the EDI
convention document is the definitive application of those standards to the program's business
needs. Due to the nature of both components, the complexity of their development, and their
importance to the implementation of an EDI system, their maintenance is essential. Sections 3
and 4 provide EIIP trading partners with information about the general issues related to
maintaining the ANSI/ASC XI2 841 - Specifications/Technical Information Transaction Set and
the EIIP XI2 EDI Convention Document.
2-2 Emission Inventory Improvement Program
-------
2
EDI STANDARDS
EDI STANDARDS OVERVIEW
Electronic Data Interchange is the automated communication of business-related data between
trading partners. As each trading partner organization has a different information system
architecture, it is typical for data to be stored as unique, proprietary data sets. The differences
between the systems make exchanging information difficult. This communication of data between
dissimilar automated systems, that otherwise can not interact, is accomplished through the use of
a standard EDI data format.
The national EDI standards are approved for use by the American National Standards Institute
(ANSI) and are developed by ANSI/Accredited Standards Committee (ASC) X12. The
membership of ASC X12 is comprised of a host of technical, trade, consumer, and professional
organizations and individuals. ASC X12 is responsible for maintaining the various X12 standards
and developing new national EDI standards.
The maintenance and development of the X12 standards is performed in a manner that ensures
their integrity, and, as the membership is made up of EDI users, that the standards meet the
specific business-related data transfer needs. Through this process, hundreds of standards are
available for use, each able to meet specific and unique business applications.
The process of standards development, modification, and enhancement is based on strict analysis
and consensus by the various ASC XI2 committees. To ensure that each standard meets its
intended use and the rules required for standards development, the activities associated with their
administration are intensive and complex. Although the process is structured and often time
consuming, this level of rigor helps ensure that business data is transferred in a consistent manner
between trading partners when ANSI/ASC XI2 standards are used.
ANSI/ASC X12 TRANSACTION SETS
The ANSI/ASC XI2 standards are organized into transaction sets. The transaction set is the
standard that is used to exchange business data and, as such, it is the unit of information that is
communicated between trading partners. Each transaction set has a unique and significant
structure of loops, data segments, and data elements that are designed to work in a manner that
meets specific data transfer needs. Each transaction set has a general purpose for use. This
intended use and the associated structure defines the transaction set.
The EIEP EDI project employs the ANSI/ASC XI2 841 - Specifications/Technical Information
Emission Inventory Improvement Program 2-1
-------
Report on Convention Maintenance 4/97
EIIP BACKGROUND
The Emission Inventory Improvement Program (EIIP) is a joint effort of state and local air quality
monitoring agencies and the United States Environmental Protection Agency (EPA). The
program is organized for the purpose of improving the quality of the emissions data collected and
the way the data is transferred and shared among users. The EIIP Data Management Committee
(DMC) is responsible for developing and testing a common data transfer format that can facilitate
data sharing within the emission inventory community.
The DMC has developed the EIIP Phase I Core Data Model to help facilitate the transfer of data
within the emission inventory community. The data model organizes the four unique and different
perspectives of point, area, mobile, and biogenic source components. The final data model is the
basis for developing a standard data transfer format for use among industry, state and local
agencies, EPA and other organizations to share emission inventory data. The DMC is developing
and applying Electronic Data Interchange (EDI) as the data transfer format for the program.
1 -2 Emission Inventory Improvement Program
-------
1
INTRODUCTION
INTRODUCTION
Electronic Data Interchange (EDI) is the automated flow of business information between the
computer systems of trading partner organizations. In order to successfully perform EDI, a
specialized system must be developed. Through necessity, the system is comprised of a number
of essential, interrelated components. Each of these key components must be well developed and
work in harmony to accomplish the organization's goals. The characteristics of the system and its
components are based on, and must directly support, the specific needs and goals of the
implementing organization.
Developing a production EDI system can be a complex undertaking. Aside from the issues that
impact all system development efforts (i.e., organizational issues, financial concerns, business
relationships, technology, and expertise), the assembly of the components and their business-
specific characteristics provides definite challenges. Once in place and functioning, the system is
still sensitive to these matters. Because an organization's business environment is dynamic and
technology is constantly evolving, the maintenance of an EDI system is a significant activity. The
long-term maintenance of a production system must be understood and considered prior to its
implementation and throughout its life cycle.
PURPOSE OF THIS REPORT
This report outlines the key components of a production EDI system and provides general
information about their maintenance. It specifically develops the primary maintenance issues
related to the backbone of any EDI system — the transaction set and convention document
(Sections 3 and 4). These two documents provide the mechanism for the automated systems of
trading partners to exchange data. Because they are of such critical importance and involve a set
process for development, a detailed description of these components, along with their related
maintenance, is provided. Appendix B supplements the detailed description of these maintenance
activities.
Because an EDI system is a composite of several parts, each is addressed separately. General
information about what the component is, how it is integrated with the other parts, and the typical
maintenance issues are outlined (Section 5). A glossary of terms is found in Appendix A.
Emission Inventory Improvement Program 1-1
-------
Report on Convention Maintenance 4/97
This page intentionally left blank.
Emission Inventory Improvement Program
-------
CONTENTS
Section Page
1 INTRODUCTION 1-1
INTRODUCTION 1-1
PURPOSE OF THIS REPORT 1-1
EIIP BACKGROUND 1-2
2 EDI STANDARDS 2-1
EDI STANDARDS OVERVIEW 2-1
ANSI/ASCX12 TRANSACTION SETS 2-1
EDI CONVENTION DOCUMENTS 2-2
3 ANSI/ASCX12 TRANSACTION SETS 3-1
ANSI/ASC X12 EDI STANDARDS MAINTENANCE ISSUES 3-1
4 CONVENTION DOCUMENT 4-1
EDI CONVENTION DOCUMENT MAINTENANCE ISSUES 4-1
5 EDI SYSTEM COMPONENTS 5-1
OVERVIEW OF EDI SYSTEM COMPONENT MAINTENANCE ISSUES 5-1
MANAGEMENT SUPPORT/BUSINESS ISSUES 5-1
DATA MODEL/PROCESS DOCUMENTATION 5-2
IMPLEMENTATION GUIDELINE 5-3
EDI TRANSLATION SOFTWARE 5-5
EDI TRANSLATOR OVERLAY 5-6
EDI TRANSLATOR CONFIGURATION 5-7
A DATA FORMAT 5-7
APPLICATION PROGRAM INTERFACE 5-8
DATABASE SYSTEM 5-9
SYSTEM HARDWARE 5-9
COMMUNICATIONS 5-10
TRADING PARTNERS 5-12
APPENDIX A: GLOSSARY A-1
APPENDIX B: X12 DATA MAINTENANCE PROCESS B-1
Emission Inventory Improvement Program i
-------
REPORT ON MAINTENANCE ISSUES
ASSOCIATED WITH THE EIIP
EDI X12 CONVENTION
DOCUMENT
April 1997
Prepared by:
Technology Planning & Management
Corporation
DynCorp Information & Engineering
Technology
Prepared for:
Data Management Committee
Emission Inventory Improvement Program
-------
Report on EDI Translators 4/97
This page intentionally left blank.
D-2 Emission Inventory Improvement Program
-------
REFERENCES
Electronic Commerce Strategies, Inc., Buyer's Guide to Electronic Commerce, Electronic Commerce
Strategies, Inc., 1995 edition.
EDI World Magazine, 1996 EDI Software Directory, EDI World, Inc., 1996 edition.
Phillips Business Information, Inc., 1996 EDI Yellow Pages, Phillips Business Information, Inc., 1996
edition.
Ravi Kalakota and Andrew B. Whinston, Frontiers of Electronic Commerce, Addison-Wesley
Publishing Company, Inc. 1996.
Richard Bort and Gerald R Bielfeldt, Handbook of EDI, "EDI Management Software", Warren,
Gorham & Lamont, 1996 edition.
Mike Witter, The EDI Project Planner, EDI Strategies, Inc, 1989.
Emission Inventory Improvement Program D-1
-------
Report on EDI Translators 4/97
6. The proposed version of the translator software must be in production at multiple users
sites. After bid opening and prior to award, the bidder must provide a minimum of three
references.
7. Maps, profiles, and other user-defined tables are migratable from one X12 version to
another without having to manually reenter the information.
8. Has built-in virus protection.
9. Has automatic recovery in the event of a system shutdown.
10. Upgrades and enhancements shall be provided at no extra charge during the contract
term. Software upgrades, including new versions/releases of the standards, are to be
provided within 90 days of publication.
III. TRAINING REQUIREMENTS
The (organization) will require a minimum of two days of on-site training. Training shall be provided for two
people and shall be conducted on dates mutually agreed upon between the contractor and the
(organization)
IV. SUPPORT REQUIREMENTS
The contractor shall provide telephone support for one year following the acquisition of the software.
Telephone support shall be available Monday through Friday, 8:00 AM to 5:00 PM, EST, excluding (State)
observed holidays.
V. CONTRACT REQUIREMENTS
The contractor agrees to comply with Attachment A, Provisions for (State) Contracts, as attached.
VI. HOLD HARMLESS
The contractor shall be responsible for and agrees to indemnify and hold harmless the (State) from and
against damages to property or injuries (including death) to any persons ans other losses, damages,
expenses, claims, demands, suits, and actions by any party against tt\e(State) in connection with the work
performed by the contractor.
Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
13. Flexible error processing conditions. Provide a variety of reports that describe and
diagnose errors.
14. Supports reports on document types, document numbers, control numbers, file names,
error status, acknowledgment status, and transaction volume statistics based on user-
selected criteria.
15. Ability to archive all intermediate input and output data files.
C. Mapping
1. Flat file format can be user-defined for any transaction set type regardless of trading
partner differences.
2. Ability to view the map definitions on-line.
3. Allowances for multiple conditional processing. This is the ability to use multiple data
elements from a transaction set to generate a single data element for the output flat file
and vice versa.
D. Database
1. Allows database definitions, operations, algorithms, and other processing rules to be
defined through dynamic, table-driven tools. All tables should not be imbedded in code -
only program functions should be in the executables.
E. Ease of Use
1. Straight-forward, well-organized, intuitive user interface.
2. Customizable on-line context-sensitive help.
3. Table-driven utilities to modify/create transactions, trading partner data, and maps.
4. Ability to copy maps, profiles, and job processes.
5. Has point-and-click Graphical User Interface (GUI).
F. Other
1. Ability to add new trading partners within 24 working hours.
2. Ability to implement new transaction sets within 40 working hours.
3. On-line document tracking providing statistics and other data on networks, trading partners,
and other transaction sets.
4. Password, Personal Identification Number (PIN), menu and access type security.
5. Proven track record in EDI.
Emission Inventory Improvement Program C-3
-------
Report on EDI Translators 4/97
1. Supports all connections to multiple VANs or direct connects to trading partners.
2. Supports multiple communications protocols including async, bisync, and X.400/X.25.
3. Operates in Windows NT and/or Windows 95.
4. Automatically notifies user when errors occur.
5. Allows customizing of core translation and error notification scripts.
6. Is flexible in defining pre- and post-communication processes which could include interface
routines, programs, and command procedures.
7. Keeps detailed history logs of all processes performed to determine error status and track
processing activity.
8. Allows option of EDI transactions over Internet, including appropriate security measures.
9. Able to perform scheduled or manual file purging.
10. Able to work with a TCP/IP compliant dial-up security product (DECs Tunneling Product)
B. Translation
1. Supports ASCX12 standards, all current and future versions, releases and
implementations.
2. Supports all X12 transaction sets.
3. Includes predefined tables of standard transactions, segments, and elements.
4. Has ability to copy standard tables to create customized standards.
5. Has ability to define cross reference tables. These tables are used to reconcile codes if
trading partners use different codes from recipient and/or the standard.
6. Automatically generates 997 Functional Acknowledgments for inbound transactions.
7. Ability to customize the editing criteria for the 997.
8. Audit trail reports automatically match inbound and outbound functional acknowledgments
with their associated outbound transaction set.
9. Inbound transactions can be printed or viewed on-line in a human readable format.
10. Supports manual data entry of outbound EDI data through data entry screens.
11. Supports batch downloads from an application interface linking the translation software to
an Oracle database.
12. Ability to import from and export to flat file formats.
C-2 Emission Inventory Improvement Program
-------
APPENDIX C
EXAMPLE TRANSLATOR
SOLICITATION
EXAMPLE TRANSLATOR SOLICITATION SPECIFICATIONS
The following is an example solicitation package for the procurement of EDI translation software.
It is intended to provide insight to the hypothetical translator needs and requirements for an
organization. It is not a comprehensive document for use with a specific translator procurement.
Prior to embarking on such a procurement, an organization must not only identify the technical
requirements to be solicited, but any procurement policies/regulations that must be adhered to.
The information provided below are the technical criteria that are required of a candidate vendor.
This specifications sheet is typically preceded by an official invitation for bid proposal document
that would be specified by the contracting organization.
SPECIFICATIONS
I. SCOPE OF WORK
The (organization) is seeking to obtain Electronic Data Interchange (EDI) translator software and a single
user license. The software will run on a 586 Pentium with 32 MB RAM running Windows NT version 3.51.
If not, the software will be run on a 486 Pentium with 16 MB RAM running Windows 95. The PC is a front
end to an Oracle relational database residing on a DEC VAX cluster.
Prior to acceptance of the software, the (organization) reserves the right to conduct a 30-day test of the
translator software using an implementation of ASC X12-841, version 3060. The result must be successful
inbound and outbound transactions as described in the program's EDI implementation guideline available
from the (organization). Bidders may obtain copies of this guide by contacting (point of contact) at (point of
contact telephone number). The purpose of this test is to allow the (organization) to evaluate how the
proposed translator software will conform to the requirements as described below. The intent of this bid is
to provide off-the-shelf software as opposed to custom software.
Any questions concerning the technical aspects of this bid should be direct to (point of contact) at (point of
contact telephone number). Questions concerning the contracting or bidding procedures should be
directed to (point of contact) at (point of contact telephone number).
II. SOFTWARE REQUIREMENTS
A. Communications and Process Control
Emission Inventory Improvement Program C-1
-------
Report on EDI Translators
4/97
Does is support a wide range of printers and work when the printer is off?
Does is support multiple versions of ANSI X1 2 standards?
Does is operate in the background so the computer can perform other tasks?
Does is allow transaction edit function to reduce functional acknowledgment rejects?
Does it provide audit trails?
Does it provide password security for a variety of functions and applications?
Is it Table Driven for ease of upgrading standards?
Will the vendor provide source code?
Can it be customized to meet specific needs?
Can the software be tested internally?
VENDOR SUPPORT
Is the vendor experienced in your industry?
Has vendor received any applicable industry EDI guidelines and is system compatible?
Does the vendor provide a customer service hotline?
Does the vendor offer on-site training?
Does the vendor provide software upgrades?
Does the vendor offer ongoing software enhancements?
Is the vendor's reputation recommendable?
Does the vendor supply a maintenance contract?
Vendor 1:
YES
NO
Vendor 2:
YES
NO
B-2
Emission Inventory Improvement Program
-------
APPENDIX B
TRANSLATOR COMPARISON
WORKSHEET
EDI TRANSLATOR SOFTWARE COMPARISON WORKSHEET
The following is a checklist of typically desirable EDI translator software features. It is intended
to assist with comparing products from EDI software vendors for use with the EIIP EDI System.
The checklist can be customized to include any special feature that were identified through the
internal evaluation process. In addition, any specific evaluation points outlined in Section 4 that
are of importance to an individual implementation and are not otherwise included should be
considered.
Software
Basic cost of software:
Annual maintenance contract:
Period of license (years)
Any additional vendor support costs:
Does the software operate in your computer environment?
Does the software support your performance requirements?
Does the software support the EDI standards to be used?
Are all needed transaction sets available?
Does the software support the version/release(s) required?
Is the package operating in your industry?
Does the package offer features to support the specific needs of your industry?
Is communications capability built in?
Are the required communications protocols and systems supported?
Does the translator support Internet connection?
Is the communications automated to enhance security?
Is an application-link generator built in?
Is a tutorial or demo available for installation ease?
Vendor 1:
YES
NO
Vendor 2:
YES
NO
Emission Inventory Improvement Program
B-l
-------
Report on EDI Translators 4/97
This page intentionally left blank.
A-4 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
EPA, The abbreviation for the United States Environmental Protection Agency. Established in
1970 by presidential executive order, it brings together parts of various government agencies
involved with the control of pollution. Note that some state environmental authorities may be
called EPA also, as in Illinois EPA.
Functional Acknowledgment, A transaction set (997) transmitted by the receiver of an EDI
transmission to the sender, indicating receipt and syntactical acceptability of data transmitted
according to the ASC XI2 standards. The functional acknowledgment allows the receiving party
to report back to the sending party problems encountered by the syntax analyzer as the data is
interpreted. It is not intended to serve as an acknowledgment of data content.
Implementation Guideline, Instructions on the use of EDI for an individual business use of
EDI. Guidelines provide additional information about conducting EDI and may provide
assistance on how to implement EDI.
Standards, The technical documentation approved by ASC X12, including transaction sets,
segments, data elements, codes and interchange control structures. Standards provide the
structure for ASC XI2.
Third-Party Services, Organizations that provide value-added communication/transmission
services. Also see VAN.
Trading Partner, The sending and/or receiving party involved in the exchange of electronic data
interchange transmissions.
Transaction Set, A semantically meaningful unit of information exchanged between trading
partners.
VAN, The abbreviation for Value-Added Network. Also see Third-Party Services.
Version/Release, Identifies the publication of the standard being used for the generation or the
interpretation of data in the X12 standard format (e.g., Version 003040 is Version 3 Release 4).
Emission Inventory Improvement Program A-3
-------
Report on EDI Translators 4/97
Data Model, A description of the principles of organization of a database, including data entities,
attributes, relationships, and data specifications.
Data Set, The grouping of data that is being exchanged between the automated systems of
trading partners via EDI.
DISA, The abbreviation for the Data Interchange Standards Association. A non-profit
organization which serves as the Secretariat for X12.
DMC, The abbreviation for the Data Management Committee of the Emission Inventory
Improvement Program responsible for the administration of issues related to air emission
modeling data.
EUP, The abbreviation for the Emission Inventory Improvement Program which is chartered to
address the collection and use of air emission inventory/modeling information.
EDI, The abbreviation for electronic data interchange. Commonly defined as "the computer-to-
computer exchange of business information in a standard format." An EDI transmission is a
highly structured message intended for automated processing by a computer. It is meant to be
machine-readable so that it doesn't require human intervention to be interpreted and understood.
EDI is primarily used for intercompany communication. All references to EDI under U.S. EPA
programs refers to the utilization of ASC X12 standards.
EDI Translation, The conversion of application data to and from the X12 standard format.
EDI Translator, Computer software used to perform the conversion of application data to and
from the XI2 standard format.
EDI Translator Configuration, The activity of inputting trading partner and EDI system
specifications into the EDI Translation Software. This process provides the translator with
essential information needed for translation and transmission of data. This information is often
documented in the Implementation Guideline and/or the Trading Partner Agreement.
EDI Translator Overlay, The computer code designed in the EDI translator which reflects the
requirements of the convention document and is consistent with the ASC X12 standards. It
functions to translate the data set to or from the required XI2 format.
EDI Translator Overlay Mapping, The development of the overlay within the EDI translation
software in accordance with the requirements of the translator characteristics, the ASC X12
standards and the convention document.
A-2 Emission Inventory Improvement Program
-------
APPENDIX A
GLOSSARY
ADF, The abbreviation for A Data Format. A textual description, usually in the form of a table,
that specifies the structure and data content of the flat file that is the input to or output from the
EDI translator. It is a technical document that is use in designing the application program
interface between the EDI translation software and the database system.
ANSI, The abbreviation for the American National Standards Institute (ANSI). The national
coordinator for standards in the United States.
API, The abbreviation for the application program interface (API). A computer program that
functions between the EDI translation software and the database system associated with the data
being exchanged.
ASC X12, The abbreviation for Accredited Standards Committee (ASC) X12. It is comprised of
a non-profit clearing house and coordination body for voluntary data standards activities in U.S.
The purpose is to develop uniform standards for the electronic interchange of business
transactions for submission to ANSI for subsequent approval and dissemination. XI2 is the
subcommittee responsible for the development and maintenance of standards for Electronic Data
Interchange (EDI).
Communications, The transport of information in an EDI environment that may be by physical
(i.e., magnetic tape or courier service) or telecommunication (i.e., public or private
telecommunications system) means.
Convention Document, Common practices and/or interpretations of the use of the ASC X12
standards, as agreed upon by two or more trading partners. Conventions define what is included
in a specific implementation of an ASC X12 standard.
Convention Document Mapping, The development of the convention document by selecting
the appropriate X12 structures for implementation in accordance with the requirements of the
ASC X12 standards and the business process.
Database System, In this usage, it is the automated data storage mechanism (i.e., database,
spreadsheet, etc.) for data being exchanged within an EDI system. Also referred to as Automated
System.
Data Element, A data element can represent a qualifier, a value, or text (such as a description).
Emission Inventory Improvement Program A-1
-------
Report on EDI Translators 4/97
The level of effort associated with these maintenance points is typically minimal if they are
associated with a vendor that the organization has a standing relationship with and are planned
for. They are generally carried out as a routine activity by the EDI coordinator.
The cost of translator maintenance, as with many other aspects of the translator and overall EDI
system, is related to the individual organization. The cost is linked to the translator that is
selected for use, the number of licenses held, and the level and period of support required. As a
result, financial information must be obtained from the vendor selected to support the
organization's implementation. As stated previously, the costs of translators vary from free of
charge to several hundreds of thousands of dollars depending upon the functionality, quality, and
support included in the package.
Apart from these, typically software-related maintenance issues, unplanned maintenance events
may also occur. The scope and impact of these issues is not possible to judge until they occur.
However, if the EDI system is relied upon for heavy production use or the exchange of mission
critical data, these maintenance activities often have dramatic impacts on the organization. As a
contingency for unplanned maintenance, it is essential that the organization have a system
failure/back-up plan to activate as situation arise.
-4 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
• If the organization modifies its implementation or convention documentation to
allow for changes in a business application, the mapping of the translator (overlay)
must be modified accordingly.
• If the organization expands its use of EDI in such a way that additional convention
documents are created, the additional associated translator mappings (overlays)
must be included to support the new implementations.
• If the organization changes to employ new or different information systems and
technology, the translator may also need to be enhanced or modified to function in
the new computing environment,
As with routine management activities, these activities are often the responsibility of the EDI
coordinator and/or EDI technician. However, as many of the matters are related to changes to
the organization, business processes, or overall implementation, management must also play a
role. The level of effort and associated staff and financial resources associated with this
management share the same variables stated for above. As a result, the actual cost of this
management is also a factor of the organization's characteristics.
EDI TRANSLATOR MAINTENANCE
Planned translator maintenance is performed more routinely and often in a more definitive
manner. It is often driven by forces outside the immediate organization and is related to those
parties that support the organization's implementation. Some of the factors that constitute this
maintenance include, but are not limited to, the following items.
• Upgrades to new releases of the resident software that are provided by the vendor.
These upgrades typically include enhancements to the overall functionality of the
software or increases in performance. They also include updated EDI-related
details, such as transaction sets, segment and element structures, and code tables,
which are generated through ANSI/ASC X12 activities. The period that these
upgrades are provided is typically stipulated as part of the software licensing
agreement.
• Renewal of maintenance/support agreements with the vendor. These agreements
are typically renewed annually, but are usually available for extended periods.
• Renewal of software licensing agreements. As with support agreements, these
typically have a one year term, but are usually extendable.
Emission Inventory Improvement Program 5-3
-------
Report on EDI Translators 4/97
related issues; and
• Various other internal coordination activities with the users of the translated data.
These routine, administrative activities are typically part of a EDI coordinator and/or EDI
technician's responsibilities. As such, they should be evaluated in a manner similar to other
information systems management activities. The level of effort and associated staff and financial
resources are a function of a combination of the following factors and many interrelated variables.
• Organization's management goals and support (as it, drives the implementation);
• Size and complexity of the overall implementation and EDI system (as it impacts
the translator used);
• Quality and functionality of the translator; and
• Level of expertise and experienced provided by the staff.
As each of these variables, and others that are associated, are directly related to the implementing
organization, actual dollar amounts will vary. In order to effectively project the long-term cost of
this type of translator management, the organization must have a well defined understanding of
the environment in which it will perform, the business function that it will support, and the goals it
must achieve. Once this understanding is gained, cost/benefit analysis can be performed based on
initiatives of similar scope, either inside or outside the immediate organization, and the actual
costs associated with the software and hardware. This research, as it will be performed relative to
the actual characteristics of the implementing organization will yield the most accurate
information. It should be noted that, even with such information, a definite result from
costftenefit analysis is difficult to obtain because the use of EDI is often related to other initiatives
such as business process reengineering.
Management for Programmatic Dynamics
Another form of translator management is that which arises out of programmatic changes. This
sort of management is performed as situations demand adjustments to the functionality or
application of the software. Although the actual activities for a specific translator are not able to
be fully identified until it is selected, installed, and functional, a number of general impacts and
activities are likely. These action points include, but are not limited to, those outlined below.
• As trading partners are added or removed from the organization's EDI program,
modifications to the software configuration (e.g., trading partner profiles,
telecommunication information, etc.) that must be performed.
c 9
J~^ Emission Inventory Improvement Program
-------
5
MANAGEMENT AND MAINTENANCE
To ensure that EDI translation software continues to perform in the manner required by the
program, it must be managed and maintained. The successful implementation of an EDI system is
not a one-time investment. Translation software must be viewed as a dynamic tool that adapts to
changes in the organization, business applications, information systems, technology, users, and
trading partners.
The management and maintenance of an EDI translator is multifaceted and variable. As discussed
previously, the environments in which translators operate and the functions they provide vary
widely. As a result, so do the requirements for their management and maintenance. The level of
use, the complexity of the implementation, the quality of the translator, and a number of other
factors, dictate the amount of effort and support that must be invested in a translator.
EDI TRANSLATOR MANAGEMENT
An EDI system is intended to be an integrated component of a business process. As a result, it
must be managed in a manner similar to any other automated system that supports the process.
Some of these activities are routine while others occur with changes to the business process.
Because the EDI translator software is major component of the overall EDI system, it shares
these types of management necessitates.
Routine System/Software Administration
The management associated with routine, production-related activities include those things that
are generated by EDI traffic. The magnitude and frequency of these activities varies widely based
on the overall level of system performance and the software that is being used. However, some of
the more typical activities may include, but are not limited to:
• The administration of the performance of the overall EDI system and translation
software;
• Observation and evaluation of transmission activity (incoming and outgoing);
• Generation and review of system administration and transmission activity reports;
• Coordination with trading partners and software vendors regarding translator-
Emission Inventory Improvement Program 5-1
-------
Report on EDI Translators 4/97
• Are there any "add-on " charges?
The vendor should be able to provide documentation regarding pricing schedules for all
supported aspects of the translator.
OTHER INFORMATION
• Haw long has the translator software been in use?
This will provide an indication of the vendor's presence in the EDI community and the
general ability for the translator to support user needs.
• What is the distribution of the translator?
This information will provide insight about the industries that use the translator, the size of
organizations using it, and its overall acceptance in the marketplace. This information will
illustrate whether the vendor supports the exchange of environmental data.
• What is the performance of the translator?
Although a relatively subjective question, the answer may provide insight as to the
strengths and weaknesses of the software.
• Is the EDI version and transaction set to be used currently in production and
functioning?
This information will indicate whether the software is actually being implemented and
functioning in a production environment. It will provide a measure of the viability of the
software.
• Are references available?
References should be provided freely by the vendor. The other users will provide
information about the actual performance of the software and the vendor support.
4-10 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
• Will the translator software be supported by a telephone hotline?
This is an essential feature when immediate personal technical assistance is needed.
• Will the translator software be supported by an Internet on-line "help "junction?
This is an essential feature for technical assistance when personal interaction is not
required.
• Will the translator include an on-line "help " module?
This is an essential feature for technical assistance when personal interaction is not
required.
• Will the vendor supply training?
The vendor must offer this support if specified through the internal evaluation.
• Will the vendor supply software and software upgrades?
This is a basic essential factor in the evaluation of a vendor.
• Will the vendor supply copies of the technical documentation?
This is a basic essential factor in the evaluation of a vendor.
• Will the vendor supply copies of end-user documentation?
This is a basic essential factor in the evaluation of a vendor.
ADMINISTRATION
Cost
• What is the cost of yearly license renewal or maintenance fees?
This an obvious factor to consider. The vendor should be able to provide documentation
regarding pricing schedules for all supported aspects of the translator.
Emission Inventory Improvement Program 4-9
-------
Report on EDI Translators 4/97
Data Entry/User Interface
• Will the translator support manual data entry through data entry screens?
Although not intended for use with the prototype efforts, this may be a useful feature for
importing test data or special transmissions where data will not be retrieved from an
automated system.
• Will the translator automatically notify the user of errors?
This feature is helpful in the reduction of error introduction and reduce quality assurance
time during the testing activities.
• Will the translator allow transactions to be printed or viewed on-line in a human
readable format?
This feature assists with quality assurance activities as the data set can be reviewed prior
to being transmitted or introduced into the automated system.
• Is the translator user interface logical, well-organized, and intuitive?
This feature assists in overall use and management of the system as it makes the software
more user friendly and understandable.
• Will the translator provide table-driven utilities to modify/create configurations?
Again, this feature assists in overall use and management of the system as it makes the
software more user friendly and understandable.
• Will the translator have a point-and-click graphical user interface ?
Again, this feature assists in overall use and management of the system as it makes the
software more user friendly and understandable.
User Support/Documentation
• What level of user support is offered by the vendor?
The vendor must offer the level of support specified through the internal evaluation.
4-8
Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
• Will the translator support the import and export of flat file formats?
This is essential for the prototype efforts as it will assist with system testing and test
transmission processing.
• Will the translator allow flexible report generation?
This may be a useful function if customized report generation is needed at the point of
translation.
Security
• Will the translator have built-in security options (e.g., password protected, personal
identification number (PIN))?
Although not a requirement for the prototype efforts, this may be an essential feature for
future program initiatives involving sensitive or mission critical data.
• Will the translator support security measures at various levels (e.g., menu, tables, code
lists)?
Although not a requirement for the prototype efforts, if the translator is to operate in a
secure environment, this may be an essential feature.
• Will the translator have built-in virus protection?
This may be an essential feature if the translator operates on a stand-alone station or other
environment that does not have similar functionality to protect the associated systems.
• Will the translator have automatic recovery in the event of a system shutdown?
Although not a requirement for the prototype efforts, this may be an essential feature for
future program initiatives involving sensitive or mission critical data.
Emission inventory Improvement Program 4-7
-------
Report on EDI Translators 4/97
Although not specified for the prototype efforts at this time, any communication
connection should be supported if required for future initiatives.
• Will the translator allow communication sessions be performed concurrently?
This feature is essential in a production system that is heavily used or exchanges mission
critical data as it allows increased activity to occur.
MANAGEMENT/SECURITY
Data Management
• Will the translator keep detailed history logs of all processes performed to determine
error status and track processing activity?
Although not a requirement for the prototype efforts, this is an essential feature for a
production environment.
• Will the translator be able to perform records management activities (e.g., file purging) ?
Although not a requirement for the prototype efforts, this is an essential feature for a
production environment.
• Will the translator generate audit trail reports that automatically match inbound and
outbound functional acknowledgments with their associated outbound transaction set?
Although not a requirement for the prototype efforts, this is an essential feature for a
production environment.
• Witt the translator support batch downloads from an application interface?
This may be a useful feature that will allow data to be retrieved from the translator.
• Will the translator support reports on document types, document numbers, control
numbers, file names, error status, acknowledgment status, and transaction volume
statistics based on user-selected criteria?
This may be a useful feature that will allow information about translation volume and
overall management to be collected for analysis.
4-6 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
The definition of a flat file format is an essential component in the development of an
application program interface (API) and as such is an important feature.
• Will the translator be flexible in defining pre- and post-communication processes which
could include interface routines, programs, and command procedures?
Although the prototype is employing an application program interface (API) to perform
these functions, if an individual organization implements the EIIP EDI system without an
API, this feature would be necessary.
• Will the translator support the customizing of core translation and error notification
scripts?
This feature is essential when specialized translation and reporting functions are required
beyond the functionality pre-programmed with the software.
• Will the translator allow the mapping to be viewed on-line?
This feature often assists in trouble-shooting errors and viewing data in lieu of report
generation.
• Will the translator maps, profiles, and other user-defined tables be able to be migrated?
This feature is essential if the an organization were to change translators. It also allows
implementation-specific information to be maintained without the necessity of redefining
or developing maps, profiles, and other related components.
Communication
• Will the translator allow multiple communications protocols (e.g., asynchronous,
bisynchronous, etc.)?
Although not specified for the prototype efforts at this time, each communications
protocol should be supported if required for future initiatives.
• Will the translator allow the option of EDI transactions over the Internet, including
appropriate security measures?
This is an essential feature, as the Internet may be used for data transfer with future
initiatives.
• Will the translator allow all connections to multiple VANs or direction connects?
Emission Inventory Improvement Program 4-5
-------
Report on EDI Translators 4/97
specialized implementations. In such a case, the flexibility to copy and customize the
standards tables may be necessary.
• Will the translator be able to define cross reference tables to reconcile codes between
different trading partners?
Although not a requirement for the prototype efforts, when an organization uses different
codes from those used by the recipient and/or standard, cross reference tables assist in
automatically reconciling the associated business information.
• Will the translator automatically generate the 997 Functional Acknowledgments
Transaction Set for inbound transactions?
Although not a requirement for the prototype efforts, future implementations of the EIIP
EDI project may require return acknowledgments. As such, this function should be
specified.
• Will the translator allow the editing criteria for the 997 Functional Acknowledgments
Transaction Set to be customized?
Although not a requirement for the prototype efforts, future implementations of the EIIP
EDI project may require return acknowledgments. These implementations may require
specialized use of the transaction set to meet business needs.
Translator Coding/Mapping
• Will the vendor create the overlay?
Due to the expertise of the vendor, the availability of the vendors support to map the
overlay may be a valuable feature. If internal expertise is limited, this feature may be
essential to the project.
• Will the vendor customize the translator?
Although the prototype is using an ASC X12 standard that is fully supported by most
translators, future initiatives may require specialized implementations. In such a case, the
flexibility to customize the software may be necessary.
Will the translator support the development of a flat file format that can be user-defined
for any transaction set regardless of trading partner differences?
4-4 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
• Will the translator perform on the other platforms and operating systems?
As this is a prototype effort, actual implementation at future stages of the project may
require the use of other platforms or systems. As such, this information should be
considered.
EDI Standards
• Does the translator support ANSI/ASC XI2 standards?
The prototype efforts use the ANSI/ASC X12 standards. Therefore, the translator needs
to support these standards. However, if the trading partner intends to use the translator
for international data exchange, it should support EDIFACT.
• Does the translator support all past, current and future versions/releases of the
ANSI/ASC XI2 standards?
The prototype efforts use the 3060 version/release, however upgrading is likely.
Therefore the translator must support this requirement.
• Does the translator support the ASC XI2 841-Specifications/Technical Information
Transaction Set?
The prototype efforts use the ASC XI2 841-Specifications/Technical Information
Transaction Set, therefore the translator must support it fully.
• Witt the translator support multiple transaction sets?
Although the prototype efforts are only using a single transaction set, future
implementations may require the use of more. As a result, this feature should be
considered.
• Will the translator include predefined tables of standard transactions, segments, and
elements?
This feature is important because the EIIP EDI project is complying with the ASC X12
standards and the translator should have these standards predefined for use.
• Will the translator be able to copy standard tables in order to create customized
standards?
Although the prototype is using the ASC X12 standards, future initiatives may require
Emission Inventory Improvement Program 4-3
-------
Report on EDI Translators 4/97
Magazines such as EDI World also provide informative annual supplements discussing and
comparing EDI translator software products. Other resources such as the EDI Yellow Pages may
also provide other sources of information. The Internet is also an excellent source of product and
contact information.
Some of the basic questions that should be asked of potential translator vendors are outlined
below. Because this report is intended for use by EIIP EDI trading partners, only those research
points that may be applicable to the EIIP EDI project are presented. Along with the pertinent
questions, a brief rational or description of the importance of the reference feature is given. The
examples/explanations that are included with the rationales are based on the current EIIP EDI
prototype activities. These examples are provided for informational purposes and are intended to
give potential users some insight regarding the scope of the current project. The specifications
that are presented may change as the project develops.
This information will help guide the user through the selection process for a translator for use
with the EIIP EDI initiative. If a translator is to be used for other implementations there may be
other questions that may be required to identify the required additional functionality.
As with the internal evaluation, it should also be noted that some questions have answers that are
dependant upon the unique characteristics of the implementing organization. Therefore they can
only be answered within the context of the specific organization that will use the software. These
points are indicated accordingly and are provided as a guideline only. The specific answers and
corresponding functional criteria must be ascertained by the user.
INFORMATION SYSTEMS
Operating Environment/Configuration
• Will the translator perform on the required platforms and operating systems?
The software must support the overall operating environment and configuration specified
through the internal evaluation step. As the prototype effort does not stipulate a single
environment or configuration, this specification is unique to the individual trading partner.
• Will the translator support the system performance specifications that are required?
Although specific performance specifications are determined through evaluating the
system configuration, some variance may be a reality and should be clarified with the
vendor. In some cases, if the performance requirements for software do not match the
system's current configuration, some adjustment to the system may be necessary. Again,
this specification is unique to the individual trading partner.
4-2 Emission Inventory Improvement Program
-------
4
EDI TRANSLATOR SELECTION
SELECTING AN EDI TRANSLATOR
The features, functionality, and vendor support vary widely between translator software packages.
Some translators are expensive, but may be more user friendly and provide a multitude of
functional and support options. Other less expensive options may not offer as much flexibility or
user ease, but may be more appropriate for intended level of use of the system.
The answers to the internal evaluation questions outlined in Section 3 will generate essential
information about the type and features required of a candidate translator. However, identifying
the actual translator and collecting the necessary information about it is another step in the
selection process.
Each EDI translator software package varies widely in what functionality they offer. The
software is dependant upon the environment in which it functions and the features it offers. Many
may be applicable for one organization's implementation, but would not be suitable for use by
another. As a result, a trading partner must research candidate translators relative to the results of
their own internal evaluation. Through the process of matching the available translators with the
functional requirements obtained from the internal evaluation, the user will focus their search on
only those translators that most closely meet their needs. Ultimately, the translation software
package selected for implementation should fully support the needs and requirements of the
organization.
The primary source for specific information about individual translators can be obtained directly
from the developers and/or vendors of the software. Other useful and practical information may
be gained from other parties currently using or familiar with the software for similar
implementations. These organizations or individual users can be identified through resources like
the EDI Yellow Pages that is available from Phillips Business Information, Inc. or through EDI
user groups. These groups are also identified in theED/ Yellow Pages and can often be located
on the Internet. Another source of information regarding EDI translators, users, and user groups
is the Data Interchange Standards Association (DISA). This organization is the secretariat for
ASC X12 and provides varied resources to users of EDI.
Identifying translators and their vendors, as well as identifying other important information such
as user groups and individual users, can be done though referencing various EDI publications.
Books such as Buyer's Guide to Electronic Commerce published by Electronic Commerce
Strategies, Inc. can provide valuable insight regarding the selection of an EDI translator.
Emission Inventory Improvement Program 4-1
-------
Report on EDI Translators
This page intentionally left blank.
3-8 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
• Will on-site training be required?
Depending upon the user's level of experience and expertise with EDI and the translator,
as well as the organization's needs, it must be determined whether on-site training would
be affective.
ADMINISTRATION
Licensing
• What are the terms required for the license(s) needed?
The number of translator licenses, and the associated terms and period of performance,
must be determined. This determination must be made relative to the expected level of
use of the translator and the number of users for an organization.
Cost
• What funding is available (i.e., what is affordable)?
Although funding is often initiated by identifying the cost of a service or product, a general
idea of budget limitations should be considered. Translators range in cost from being free
of charge to several hundreds of thousands of dollars. The wide variance is dependant
upon the quality and functionality of the software and its support. As with all other
points, the needs and limitations of the user should be identified and considered.
Staff
• Are staff resources available to use and maintain the translator?
Adequate staff resources must be available to use and maintain the translator. This
includes individual with expertise in not only the software but the system(s) with which it
is integrated.
Emission Inventory Improvement Program 3-7
-------
Report on EDI Translators 4/97
• Will the data populate the database using an API?
For the prototype efforts, data will be loaded into the database system using an API.
Some translators have special functionality that can be programmed to serve this function.
The necessary functionality should support the requirements that best suit the user's
environment.
Security
• What is the sensitivity of the data being transferred?
If confidential or sensitive information is intended to be transferred it must be considered.
Although it does not directly impact the translator, it may affect the type of
communication used. Therefore, the translator selected must support the communication
type that will accommodate any security requirements.
• Are there any policies/regulations associated with the security of the data?
If there are any policies or regulations (i.e., Federal, state, organizational) that impact the
data to be transferred or the systems it will reside in, they must be considered. Although it
does not directly impact the translator, they may affect the type of communication used.
Therefore, the translator selected must support the communication type that will
accommodate any security requirements.
Data Entry/User Interface
• Will data be input to the translator manually or through an automated system?
For the prototype efforts, the data will be retrieved from and stored in an automated
system. As a result, data entry will not occur on-line at the translator. If this functionality
is desired, a translator must be selected that supports this requirement.
User Support/Documentation
• What level user support is required (e.g., seven days per week, 24 hours per day) ?
Depending upon the user's level of experience and expertise with EDI and the translator,
the level of user support necessary to ensure success must be identified.
3 -6 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
For the prototype efforts, point-to-point data transfer will be used. Although this is used
for the prototype, other forms of communication may be considered for future initiatives.
The type of communication must support the requirement that best suit the user's
environment.
• If a network is used, will the data transfer use a third-party service?
For the prototype efforts, as point-to-point (direct connection) is being used, the Internet
or a VAN will not be employed. However, if the use of a network is selected for future
initiatives, it should support the requirements that best suit the user's environment.
MANAGEMENT/SECURITY
Data Management
• If you are sending data, what database -will data be retrieved from?
For the prototype efforts, participating trading partners will exchange data from existing
database systems. The location of the data to be transmitted must be identified to ensure
successful access to the data.
• Will the data be retrieved using an application program interface (API) ?
For the prototype efforts, data will be retrieved from trading partner database systems
using an API. Some translators have special functionality that can be programmed to
serve this function. The necessary functionality should support the requirements that best
suit the user's environment.
• If you are receiving data, what database will data be stored in?
For the prototype efforts, the EPA will store the exchanged data in a database system
specifically developed for the prototype initiative. The location for the storage of the data
to be received must be identified to ensure successful access to the data.
Emission Inventory Improvement Program 3-5
-------
Report on EDI Translators 4/97
version/release 3070 in order to incorporate future enhancements. All trading partner
systems must accommodate at least version/release 3060 at this time.
What ANSI/ASC XI2 Transaction Set will be employed?
The selection of the appropriate transaction set is dependant upon the business application
to be implemented. For the prototype efforts, the ANSI/ASC X12 841-
Specifications/Technical Information Transaction Set will be used. If other business
applications or data sets are expected to be implemented, this flexibility must be factored
into the selection process.
Translator Coding/Mapping
• Will the translator be an "off-the-shelf" package or custom designed?
For the prototype efforts, a commercially available software package will be used. As the
program is using a standard that is commonly supported by commercial software vendors,
the translator will be acquired from a vendor. However, if the implementation suits the
modification of a package currently in use, this point should be considered.
• Will the translator be customized by the vendor?
For the prototype efforts, the translator will not be customized. The functionality is
included with the translator is sufficient for the prototype. However, if the implementation
suits the modification of a package currently in use, this point should be considered.
• Will the translator be mapped (i.e., develop overlay) by the user or by the vendor?
For the prototype efforts, the translator overlay is being developed by the vendor. Due to
their experience, it is most efficient to employ their services. However, if the user has
experience with overlay development, this factor should be considered.
Communication
• What communications protocol will be used (asynchronous, bisynchronous, etc.) ?
The communications protocol for the prototype efforts has not been determined at this
time. The translator selected should support the requirement that best suits the user's
environment. Most PC-based translators will support either protocols.
• Will the data transfer be point-to-point or through a network?
3 -4 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
• What is the central processing unit (e.g., 80486 - 66MHz, Pentium - 100MHz) ?
For the prototype efforts, the PC to be employed is expected to be a Pentium -100 MHZ
or above. This is not a requirement and the translator selected should support the
requirement that best suits the user's environment. Most PC-based translators with
enhanced functionality require machines with increased processing speed (above a 80486 -
33MHz).
• What is the computer memory (e.g., 4MB or 8MB RAM)?
For the prototype efforts, the PC to be employed is expected to have 4MB or greater.
This is not a requirement and the translator selected should support the requirement that
best suits the user's environment. Most PC-based translators with enhanced functionality
require machines with increased memory.
• What is the size of the hard drive (e.g., 60MB or 80MB) ?
For the prototype efforts, the PC to be employed is expected to have 80MB or greater
hard drive space. This is not a requirement and the translator selected should support the
requirement that best suits the user's environment. Most PC-based translators with
enhanced functionality require machines with increased hard drive size.
Business Applications
• What data will be transferred?
For the prototype efforts, modeling inventory data will be exchanged. If the translator is
expected to be used for other business applications or data sets, this flexibility must be
factored into the selection process.
EDI Standards
• What EDI standard will be employed?
For the prototype efforts and other EPA initiatives, the national ANSI/ASC XI2 standards
for EDI will be used. If the organization is planning to perform international EDI, the use
of EDIFACT may be necessary. If the translator is expected to be used in this manner,
this flexibility must be factored into the selection process.
• What version of the ANSI/ASC XI2 standard will be used (e.g., 3060, 3070) ?
For the prototype efforts, version/release 3060 will be used. The program will upgrade to
Emission Inventory Improvement Program 3-3
-------
Report on EDI Translators
It should be noted that the answers to some of the questions are dependant upon the unique
characteristics of the implementing organization and can not be determined in this forum.
Therefore they can only be answered within the context of the specific organization being
evaluated. These points are indicated accordingly.
As appropriate, a rationale for the question is provided to assist in developing a response. This
information is intended to provide a guideline only. The specific answers and corresponding
functional criteria must be ascertained by the user. The rationales include examples/explanations
based on the current EIIP EDI prototype activities. This information is provided for
informational purposes and is intended to give potential users some insight regarding the scope of
the current project. The specifications that are presented may change as the project develops.
INFORMATION SYSTEMS
Operating Environment/Configuration
• Will the translator software reside on a mainframe, a networked computer, or a stand-
alone workstation?
For the prototype efforts, the translator is a networked PC. This is not a requirement and
the translator selected should support the requirement that best suits the user's
environment.
• Will the translator software reside on a hard drive or a network?
For the prototype efforts, the translator is PC-based and resides on the hard drive of the
PC to be used in the implementation. This is not a requirement and the translator selected
should support the requirement that best suits the user's environment.
• What platform will the translator operate on (e.g., Macintosh, IBM)?
For the prototype efforts, the translator will operate on a PC compatible platform. This is
not a requirement and the translator selected should support the requirement that best
suits the user's environment.
• What is the computer operating system (e.g., DOS, Window NT, Windows 95)?
For the prototype efforts, the translator will function in a Windows 95 or Windows NT
environment. This is not a requirement and the translator selected should support the
requirement that best suits the user's environment.
3 -2 Emission Inventory Improvement Program
-------
3
EDI TRANSLATOR CRITERIA
DETERMINING EDI TRANSLATOR FUNCTIONAL CRITERIA
The selection of the appropriate translator is essential for the successful implementation of an EDI
system. Before an EDI translator can be selected, the user must evaluate the intended operating
environment, business limitations, and a host of other organization-specific considerations. These
"internal" factors must be identified, evaluated, and defined prior to pursuing the selection and
procurement of the actual translator. This information is essential because it will dictate the
required functional criteria and often limit the number of translators that may be applicable.
The internal characteristics that must be addressed include, but not limited to, funding availability,
expertise and experience of system users, the computer environment in which the translator will
function, and the level of internal technical support. The areas of concern can be divided into a
few general topics, including information systems, management/security, and administration.
Within each of these general topics, there are specific questions that each organization planning to
implement EDI with the EIIP EDI project should asked themselves. This internal evaluation will
form the foundation for determining the functional requirements that a translator must have
(relative to the organization's specific needs) in order to perform effectively under the EIIP EDI
project. This is a critical step in the selection of an EDI translator for two reasons: Each
organization is different and has unique needs and requirements and There are numerous
translators, each with unique functions and abilities. To search for a translator in an effective,
efficient manner, the characteristics of the environment in which it will ultimately function must be
well defined. Then the characteristics of the translator can be evaluated against the organization's
requirements.
The results of the internal evaluation will define the minimum functional criteria that the translator
must have. In other words, once completed, the results of the evaluation will assist in focusing
the population of applicable translators to only those that have the specific features and
functionality that are necessary for successful implementation of the EIIP EDI project with an
individual organization.
Some of the basic questions that must be answered prior to launching the EDI translation
software selection process are outlined below. Because this report is intended for use by EIIP
EDI trading partners, EllP-specific answers/requirements that have already been defined by the
program are indicated. This information will help guide the user through the evaluation.
Emission Inventory Improvement Program 3-1
-------
Report on EDI Translators 4/97
Standards Maintenance
As ANSI/ASC XI2 standards are enhanced and updated, the EDI translation software
also needs to be updated. This update function, although accommodated by the software,
must be initiated by the user. This function is directly related to the organization's
decision to upgrade to a new version/release of the X12 standard. EDI translation
software must support and be able to recognize which version of the X12 standards is
being used by a trading partner and respond appropriately.
Administration
In some cases, depending upon the EDI translation software functionality, data regarding
transactions can be queried for special administrative reporting. Additionally, some
software packages have utilities that support reporting related to internal performance
(i.e., overlays, trading partner configurations, etc.). All of these administrative functions
assist in the management of the translator and the EDI system.
Each of these functions has different characteristics between sending and receiving operations.
To accomplish these functions the EDI translation software package typically contains a
communications module to control the modem and establish the dialogue with the trading
partner's computer, and a database of trading partner profiles. The software uses these profiles in
the translation process to distinguish among trading partners. In addition, the software must
provide the ability to add trading partner profiles to the database and to maintain the database
with new data on existing trading partners.
2-4 Emission Inventory Improvement Program
-------
4/97 Report on EDI Translators
Generation
The software accepts data from the application's internal format and translates that data
into an ANSI/ASC X12 format for transmission to a trading partner. This activity is the
reverse of interpretation (see below).
Interpretation
The software accepts data transmitted from a trading partner in an ANSI/ASC X12 format
and translates that data into the receiving application's internal format for processing.
This activity is the reverse of generation (see above).
Functional Acknowledgment
A function acknowledgment message from the receiver of a document is sent back to the
sender by the EDI translation software. The functional acknowledgment informs the
sender that the document was received, and the receiver is able to interpret it. It does not
address the content of the transaction or whether it can be processed. The functional
acknowledgment is similar to a registered mail receipt of the U.S. Postal System. It is
recommended that all transaction sets be accompanied by a functional acknowledgment.
Enveloping
When generating, the software groups all documents of the same type (transaction set)
and destination (trading partner) into an electronic envelope. The software then groups
multiple envelopes of different document types into an interchange envelope. Finally, the
software places a communications envelope (identifying protocols, line speeds, etc.)
around the interchange envelope.
Transmission Management
Interchange control tracks functional acknowledgments coming back from trading
partners and reports on an exception basis. It assumes that, if a transmission is sent out,
then a functional acknowledgment can be expected within a reasonable time (for example,
the next business day).
Emission Inventory Improvement Program 2-3
-------
Report on EDI Translators
4/97
Communications
Softwae
T Stephens Network Moctem
THE EDI CYCLE
A graphical representation of the information flow for typical EDI System is displayed below.
In order to exchange data efficiently, each EDI relationship must have at least two trading
partners. Each trading partner must have its own EDI system. Although the specific components
and actual implementation may be different, the basic functionality must be present in both.
Although the hardware, software, and communications components may be different, the key to a
successful EDI system is the use of the same XI2 standard format by each trading partner. The
EIIP is using the ANSI/ASC XI2 841 - Specifications/Technical Information Transaction Set
EDI TRANSLATION SOFTWARE
Translation of business-related data to the standard X12 format is an integral part of the overall
EDI solution. In performing the translation of data to or from the ANSI/ASC X12 format, EDI
translation software performs several other essential functions. These functions are the actual
activities that allow a data transmission to be sent and received in a manner that is consistent,
predictable, and traceable. These functions include:
2-2
Emission Inventory Improvement Program
-------
2
EDI TRANSLATION SOFTWARE
EDI SYSTEM OVERVIEW
An Electronic Data Interchange system is comprised of a number of interrelated components,
each designed to work harmoniously to accomplish the goals of the user. In general, an EDI
system contains the data system that stores the data, a software program that is the interface
between that system and the EDI translation software, the translation software, and a
communications mechanism.
On the sending end, data is retrieved from the database system containing the data set to be
exchanged. This retrieval is accomplished by the application program interface (API). The API
arranges the data set in a manner that is specified by the EDI translator. This format known as the
ADF or A Data Format. The data is then translated in the translation software into the X12
standard format. The data set, in the standard format, is able to be communication to the
receiving trading partner.
Performance of the communications portion can occur in several different ways. Data can be
transferred in a physical manner (i.e., via diskette or tape) or using some sort of communication
network. Telecommunication may be the use of dedicated line, the use of the Internet, or
connection to a third-party service provider (e.g., Value-Added Network (VAN)). A dedicated
line connects trading partners directly, which allows them to transmit data point-to-point without
interaction with other parties. The Internet is also a viable data transfer option that provides
relatively easy connection between partners. Data transfer can also be facilitated by a third-party
service provider, such as a VAN. However, unlike the Internet, a VAN offers additional services
that support specific trading partner needs.
As production EDI environments are designed to be integrated and minimize human interaction,
access between trading partners is typically achieved automatically using telecommunications. In
any case, the communication function, which can be part of the translation software or a separate
application, connects to the application system maintaining the data to the telecommunication
system being used for the transmission. Because the communications system is an essential
component of the overall EDI system, the issues related to its selection and maintenance should
be addressed as a specific issue/topic.
Upon the completion of the transmission, the receiver's translator will "reconvert" the data from
the XI2 standard format to a format meeting the requirements, as specified by the recipient's
ADF, of their API. The API then loads the data into their database system for use.
Emission Inventory Improvement Program 2-1
-------
Report on EDI Translators 4/97
The information is presented with examples/explanations based on the current EIIP EDI
prototype activities. These examples are provided for informational purposes and are intended to
give potential users some insight regarding the scope of the current project. The specifications
that are presented may change as the project develops.
EIIP BACKGROUND
The Emission Inventory Improvement Program (EIIP) is a joint effort of state and local air quality
monitoring agencies and the United States Environmental Protection Agency (EPA). The
program is organized for the purpose of improving the quality of the emissions inventory data
collected and the way the data are transferred and shared among users. The HTTP Data
Management Committee (DMC) is developing and testing a common data transfer format to
facilitate data sharing within the emission inventory community.
The DMC has developed the EIIP Phase I Core Data Model to help organize and standardize the
transfer of data within the emission inventory community. The data model is the basis for a
common data transfer format for use among industry, state and local agencies, EPA and other
organizations to share emission inventory data.
The DMC is developing and applying Electronic Data Interchange (EDI) to facilitate the
exchange of data for the program. The American National Standards Institute (ANSI) Accredited
Standards Committee (ASC) X12 standards for EDI will be used for this implementation.
The EPA has provided guidance for the use of EDI specifically for environmental reporting. The
Agency published the notice in the September 4,1996 Federal Register, Volume 61, Number 172,
FRL-5601-4. The notice is entitled Notice of Agency's General Policy for Accepting Filing of
Environmental Reports via Electronic Data Interchange (EDI) and provides an overview of the
EPA perspective for the use of EDI, the history of EDI within the EPA, and how to use EDI for
reporting to the EPA.
Emission Inventory Improvement Program
-------
1
INTRODUCTION
OVERVIEW
Electronic Data Interchange (EDI) is the automated flow of business information between the
computer systems of trading partner organizations. Typically, each trading partner has a different
information system architecture and therefore, the data to be exchanged are stored as unique,
proprietary data sets. The differences between the systems make sharing the information difficult.
This communication of data between dissimilar automated systems, that otherwise can not
interact, is accomplished through the use of a standard EDI data format.
In an integrated EDI system, data is retrieved from the automated system of the sending trading
partner, translated into the EDI format, and transmitted to the receiving partner. Upon receipt,
the reverse process occurs, with the data being translated from the EDI format and then loaded
into the appropriate automated system. An essential step in this process is the translation to and
from the EDI format. This step is performed by specialized EDI translation software that is
integrated and maintained with each trading partner's EDI system. The software is designed to
convert data between varied, proprietary data formats and the standard EDI format being used to
exchange the data.
The role and performance of EDI translation software is critical to the success of an EDI system.
The software must not only support the data transfer needs of the organization employing it, but it
must also be suited for the organization's unique characteristics. To ensure that the requirements
of different users and implementations are met, EDI translation software and its vendor support
are available with a wide range of features and functionality.
PURPOSE OF THIS REPORT
This report is intended to provide potential EIIP EDI trading partners with information to assist
them in identifying the most appropriate translation software for the purpose of EIEP data
transfer. Information that will be detailed includes: an overview of EDI translation software
(Section 2); the necessity for, and general content of, a preliminary internal evaluation to define
the functional criteria for an EDI translator (Section 3); a general overview of EDI translator
evaluation points to assist in comparing EDI translation products (Section 4); an overview of
management and maintenance issues associated with EDI translators (Section 5); a glossary of
terms (Appendix A); a worksheet to assist EDI translator evaluation (Appendix B); and an
example translator solicitation package (Appendix C).
Emission Inventory Improvement Program 1-1
-------
Report on EDI Translators ___^_ 4/97
This page intentionally left blank.
Emission Inventory Improvement Program
-------
CONTENTS
Section Page
1 INTRODUCTION 1-1
OVERVIEW 1-1
PURPOSE OF THIS REPORT 1-1
EIIP BACKGROUND 1-2
2 EDI TRANSLATION SOFTWARE 2-1
EDI SYSTEM OVERVIEW 2-1
EDI TRANSLATION SOFTWARE 2-2
3 EDI TRANSLATOR CRITERIA 3-1
DETERMINING EDI TRANSLATOR FUNCTIONAL CRITERIA 3-1
4 EDI TRANSLATOR SELECTION 4-1
SELECTING AN EDI TRANSLATOR 4-1
5 MANAGEMENT AND MAINTENANCE 5-1
EDI TRANSLATOR MANAGEMENT 5-1
EDI TRANSLATOR MAINTENANCE 5-3
APPENDIX A: GLOSSARY A-1
APPENDIX B: TRANSLATOR COMPARISON WORKSHEET B-1
APPENDIX C: EXAMPLE TRANSLATOR SOLICITATION C-1
REFERENCES: D-1
Emission Inventory Improvement Program
-------
REPORT ASSESSING THE
PROCUREMENT AND MANAGMENT
OF EDI TRANSLATORS
April 1997
Prepared by:
Technology Planning & Management
Corporation
DynCorp Information & Engineering
Technology
Prepared for:
Data Management Committee
Emission Inventory Improvement Program
-------
This page intentionally left blank.
-------
PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE 08/95
At a minimum, FTP is demonstrated using simple FTP protocol. If time permits, using a
graphical FTP interface such as Rapid Filer or Netscape is desirable. Minimal technical
requirements include the following:
• FTP software
• A network connection
• The file(s) to be transmitted
DATA COMPRESSION REQUIREMENTS
Data compression is generally useful on larger file to compress them prior to file transfer,
thereby reducing transmission time. The proof of concept examines when file compression is
advantageous. Minimally, data compression is tested and results are reported. However,
upon request, data compression is demonstrated as part of the prototype demonstration.
Data compression requirements include the following:
• Large EIIP formatted data file(s) or a set of duplicated smaller files
• PKWARE file compression software (shareware versions are readily available)
• Testing the transmission of compressed versus non-compressed files
A-12 Emission Inventory Improvement Program
-------
08/95 PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE
4. Examine the file after executing the macro
5. Write the EIIP formatted file from Lotus
Processing
Database Loading at the EPA node is implemented through a series of manipulations using
Oracle database tools. SQL*Loader is used to load the EIIP formatted data into the
database. SQL*Plus is used to insert lookup table information into the database, to
incorporate the data into the database structure, and to view information once in the database
structure. SQL*Plus is also used to extract data from the database in the form of Translator
4.
Once the AIRS data are extracted from the database, the AIRS file is read into a Lotus
spreadsheet. Translation from the AIRS format to the EIIP format is provided by executing
a spreadsheet macro written to perform the conversion. Similar to Translator 1, the
Translator 5 macro includes a spreadsheet which incorporates lookup table information
needed to populate the EIIP formatted file. Once converted to EIIP format, the file is
written out to be viewed.
TRANSFER PROTOCOL REQUIREMENTS
The prototype uses and compares two protocols to transfer the data. One protocol
mechanism is a PC based communication package; and, the other transfer mechanism is FTP
based. Many survey respondents use PC based communication packages such as ProComm
or Crosstalk and significant interest was shown in using FTP and the Internet.
Crosstalk is the EPA standard for PC communications and it is used for the prototype
demonstration. The minimal requirements are as follows:
• Crosstalk for Windows software
• Dial-up capabilities via a modem or a network connection
• A Crosstalk transmission script
• The file(s) to be transmitted
Emission Inventory Improvement Program A-11
-------
PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE 08/95
Inputs
The EIIP formatted file is mapped as input to the database. All corresponding lookup table
information is inserted into the database. The mapping is used to create a SQL*Loader
script that relates each field to the database. The SQL*Loader script, or Database Loader
(Translator 3) is executed to insert the contents of the EIIP formatted file into the database.
An SQL*Plus script is executed to incorporate the loaded data into the database structure.
The database provides input to create an AIRS formatted file. The input is extracted from
the database into the AIRS format using SQL*Plus: this is Translator 4. Subsequently, the
AIRS formatted data are translated into the EIIP format using Translator 5, conversion from
AIRS to EIIP using a Lotus spreadsheet macro.
Sequencing
EPA Node as Receiver (Translator 3).
1. Examine the file prior to loading it into the database
2. Manually map the contents of the EIIP formatted file to the database
3. Manually insert the supporting lookup table information into the database
4. Execute the SQL*Loader script to load the EIIP data
5. Execute the SQL*Plus script(s) to incorporate the loaded data into the database
6. Examine the data in its database format
EPA Node as Source (Translator 4).
1. Execute the SQL*Plus script to build the AIRS formatted data file
2. Examine the AIRS formatted file
EPA Node Conversion from AIRS to EIIP (Translator 5).
1. Read the AIRS formatted file into Lotus
2. Examine the file prior to executing the macro
3. Execute the Lotus macro
A-10 Emission Inventory Improvement Program
-------
08/95 PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE
EPA NODE (RECEIVER) REQUIREMENTS
Translator 3, actually the "Database Loader," loads the content of the EIIP formatted file
into the database. Various Oracle tools are used to perform this function. Translator 3 has
the following requirements:
• The EIIP formatted file from the local node
• An Oracle account with appropriate privileges
• Build database tables
• Build lookup tables
• SQL*Loader to load the file into Oracle
• SQL*Plus and PL/SQL to incorporate the loaded information into the database
• SQL*Plus, Oracle Report, or Oracle Data Browser to view the database entries
A separate translator extracts records from the database and creates an AIRS formatted file.
It requires the following:
SQL*Plus or Oracle Report to write an output file in AIRS format
Translator 5 demonstrates translating to the EIIP format from the AIRS format. This is
implemented using a spreadsheet macro similar in scope to Translator 1 and requires the
following:
• Lotus 1-2-3 for Windows software
• Data file in AIRS format created by Translator 4
• Lookup tables incorporated into the File Conversion Macro
• File Conversion Macro
If difficulties arise writing the spreadsheet macro or SQL*Loader script to convert between
formats, then writing third generation language (3GL) programs, such as C, FORTRAN, or
COBOL, may be required.
Emission Inventory Improvement Program A-9
-------
PRELIMINARY DESIGN FOR E1IP PROOF OF CONCEPT PROTOTYPE 08/95
State Node (Translator 2).
1. Examine the file prior to loading it into the temporary database table
2. Execute the SQL*Loader script to load the locally formatted data into the temporary table
3. Execute the SQL*Plus script(s) to build the EIIP formatted data file
4. Delete the temporary table
5. Examine the file in the EIIP format
6. Transfer the file
Processing
Processing at the local or state nodes is implemented by reading the local file, translating it
into the EIIP data format, and writing it out to be transmitted to the EPA node. Two
translation methods are demonstrated: using a Lotus spreadsheet macro and using Oracle
Tools.
At one of the source nodes, reading and writing the local and EIIP formatted files are
accomplished using the menu driven options from within Lotus. Translation from one format
to the other is provided by executing a spreadsheet macro written to perform the conversion.
This macro includes a spreadsheet which incorporates lookup table information needed to
populate the EIIP formatted file.
Alternatively, processing at the other source node is implemented by inserting the locally
formatted data into a temporary database table. The temporary table is translated into the
EIIP format using a SQL*Plus script, at which point the temporary table is discarded. The
data are viewed before and after translation. Neither viewing nor storing of the data takes
place while it resides in the temporary database table. Implementing the EIIP data format
into a database is demonstrated at the EPA node and is therefore not repeated at either source
node.
A-8 Emission Inventory Improvement Program
-------
08/95 PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE
Translator 2 may be implemented using a number of Oracle tools to be demonstrate an
alternative conversion method to Translator 1. This translator requires the following:
• Data file in local format
• An Oracle account with appropriate privileges
• Base database requirements built
• SQL*Loader to load the file into Oracle
• SQL*Plus or Oracle Report to write an output file in local format
If difficulties arise writing the spreadsheet macro or SQL*Loader script to convert from the
local formats to the EIIP format, then writing third generation language (3GL) programs,
such as C, FORTRAN, or COBOL, may be required.
Inputs
The local files need to be mapped to the EIIP data format and provided by test participants,
otherwise, they can be built from sample data. In either case, sample data need to be
provided to the prototype project. Since it provides a more robust test, the preference is to
receive actual local files; however, these files will be trimmed down to limit the size and
scope of required lookup tables.
For the source using Oracle Tools, the data are inserted into a temporary database table that
matches the EIIP file structure using SQL*Loader. SQL*Plus is used to translate the
information into the EIIP format.
Sequencing
Local Node (Translator 1).
1. Read the locally formatted file into Lotus
2. Examine the file prior to executing the macro
3. Execute the Lotus macro
4. Examine the file after executing the macro
5. Write the EIIP formatted file from Lotus
6. Transfer the file
Emission Inventory Improvement Program A-7
-------
PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE
08/95
Figure A-3: Receiver Data Flow
PROTOTYPE FUNCTIONAL REQUIREMENTS
STATE/LOCAL NODE (SOURCES) REQUIREMENTS
Translator 1 is implemented using a spreadsheet macro to convert the locally formatted file
into an EIIP formatted file. Lotus is used to perform this conversion and implies the
following requirements:
• Lotus 1-2-3 for Windows software
• Data file in local format
• Lookup tables incorporated into the File Conversion Macro
• File Conversion Macro
A-6
Emission Inventory Improvement Program
-------
08/35
PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE
data are transferred to the EPA node. Optionally, data are viewed before and after the
translation. The diagram below depicts the local and state nodes represented in the
prototype.
Figure A-2: Sources Data Flow
EPA Node (Receiver) Data Flow
The purpose of the EPA node is to illustrate receipt of emissions inventory data in the EIIP
transfer format and conversion or translation of the data into the EPA AIRS transaction
format. The EPA node receives the EIIP formatted data generated by and transmitted from
the local node. After receipt of the data file, the EPA node loads or translates the data into
the EIIP formatted database. The database contains the information from each dataset it
receives. This process demonstrates the ability to translate the EIIP data format into a
database.
The data from the EIIP database is unloaded or translated into an AIRS transaction file.
Subsequently, the AIRS formatted file is processed or translated into the standard EIIP file
transfer format. This process demonstrates the ability to create an AIRS formatted file from
the database, and create an EIIP formatted file to and from the AIRS format.
Optionally, the data and files are viewed prior to and after each translations. Numerous
viewing and processing alternatives exist as a result of holding the data in the form of a
database: these are limited to viewing and reporting with Standard Query Language (SQL)
based tools.
Emission Inventory Improvement Program
A-5
-------
PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE
08/95
FUNCTIONAL FLOW
Data from two local or state agencies is translated from their local format into the EIIP data
format and then transferred to the receiving (EPA) node. The EPA node receives the data
and consolidates it in the database. Next, the EPA node translates an EIIP formatted file into
an AIRS formatted file. The diagram below represents the functional flow of data between
and within the various emission inventory data sources and receivers.
Source 1
(Local)
Receiver
(EPA)
Local!
Systetn
Figure A-l: Functional Flow
State/Local Node (Sources) Data Flow
The purpose of the local and state data flow is to illustrate translating locally formatted
emissions inventory data into a common format (EIIP file transfer format), and transferring
or sending the data to a receiving participant, such as EPA. The state/local node represents
the first data source of the prototype. Each local or state node uses a local translator to
convert the emissions inventory data. After conversion or translation, the EIIP formatted
A-4
Emission Inventory Improvement Program
-------
08/95 PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE
to file transfer, thereby reducing transmission time. The proof of concept examines when
file compression is advantageous. Desired file sizes are created and used to evaluate
compression alternatives.
The proof of concept prototype contains an Oracle database that is representative of the EIIP
data transfer format. The database may be viewed as a repository for EIIP formatted data.
The database is a subset of the complete data model but is sufficient to demonstrate file
transfer. The database contains a limited set of values in code or lookup tables.
To support the proof of concept prototyping effort, members of the EIIP community are
mapping their databases and local data formats into the EIIP data transfer format. These
mappings will provide the logical basis for the specific prototype translators in sufficient
detail for implementation.
The technology used to implement the proof of concept prototype is typical of the responses
from the EIIP data transfer survey. Survey respondents indicated that a majority use a
minimum of 486 class processors in the Windows environment. They also used PC based
communication packages such as ProComm or Crosstalk; significant interest was shown in
using FTP and the Internet. The proof of concept prototype uses 486 class processors, PC
based communication packages, and FTP.
EIIP PROOF OF CONCEPT DATA FLOW
CONCEPTS
The EIIP proof of concept consists of three components that represent local, state, and
federal agencies. Each component is capable of sending or receiving emissions inventory
data. In the prototype, two components (state or local data sources) transfer their EIIP
formatted data files to the database. The third component (EPA) converts the EIIP data
format to an AIRS format file. In addition, the EPA component, is chosen for the prototype
location of the database to receive and consolidate state and local data.
Emission Inventory Improvement Program A-3
-------
PRELIMINARY DESIGN FOR EIIP PROOF OF CONCEPT PROTOTYPE 08/35
INTRODUCTION
PURPOSE
The purpose of this proof of concept prototype is to demonstrate an improved transfer
mechanism for sharing emissions inventory air data. The data transfer mechanism is
consistent with the EIIP Data Transfer Survey Results and Analyses, and the Phase I EIIP
Core Data Model.
BACKGROUND
The Emissions Inventory Improvement Program (EIIP) was formed as a joint effort of
state/local agencies, industry, and the Environmental Protection Agency (EPA) for the
purpose of improving the quality of emissions inventory data, and the transfer and sharing of
that among users. The EIIP is developing and coordinating recommendations for data
collection, and a data transfer protocol for the emissions inventory community. This proof
of concept prototype investigates the use of high performance computer communications for
its ability to enhance the transfer and sharing of data by state and local agencies, EPA,
industry and public analysts.
SCOPE
The EIIP proof of concept prototype is a limited system designed to demonstrate data sharing
techniques using the EIIP data file transfer format. The proof of concept prototype consists
of three partners or components that share emissions inventory data. The components
represented in this prototype are local, state, or federal (EPA) agencies. The prototype uses
and compares two protocols to transfer the data. One protocol mechanism is a PC based
communication package; and, the other transfer mechanism is Internet based via FTP (File
Transfer Protocol). The source data formats are representative of local, state, and federal
usage.
The proof of concept prototype requires development of data format translators. Each
translator changes the physical representation of the data. Two translators convert data from
the local file format into the EIIP data transfer format. A second pair of translators will
process the EIIP data format into and out of a database. Another translator converts data
from the AIRS transaction format into the EIIP data format. A number of data viewers are
used to examine the data. These viewers are not an integral part of the prototype, but are
used to examine the data before and after translations. The viewers consist of editors,
spreadsheets, reports, and word processors.
Another aspect of the proof of concept prototype is examining data compression of files that
are transferred. Data compression is generally useful on larger file to compress them prior
A-2 Emission Inventory Improvement Program
-------
This page intentionally left blank.
-------
APPENDIX
Preliminary Design
for
EIIP Proof of Concept Prototype
Emission Inventory Improvement Program A-l
-------
NEXT STEPS 08/95
6. Transmit EIIP data format to remote database
7. Provide a basis for demos and education to interested parties in the
concept
8. Document prototype steps, experience and results for the EIIP community
PROVIDE ASSISTANCE IN IMPLEMENTING THE RECOMMENDED EIIP DATA FORMAT AND
DATA TRANSFER PROCEDURES.
Other areas where the EIIP/DMC plans to assist the emissions inventory user community are
provided below.
EIIP Data Management Products and Documentation Available as 'Primers'
The DMC can develop primers and documentation to assist understanding and
implementation of data management objectives by the emissions inventory community. Some
examples of items that can be provided are listed below:
Standard EIIP Data Format/Data Model. The work on the data format should be
completed and user oriented documentation provided describing its use and implementation.
Data Transfer Prototype Proof-of-Concept Demonstration and Results. The lessons
learned from the prototype proof-of-concept should be documented and made available as
primers. The Approach Study deliverable should be completed so that users can effectively
plan their implementation of the data transfer protocol.
Internet Home-page. An EIIP Internet home page can be established describing these
concepts in broad terms and directing the users to the detailed primer documents through
hypertext. These can be made available through Net browsing software such as Netscape or
Mosaic.
Information Available Over CHIEF Bulletin Board. The DMC will continue to publish
and promote all of our primer material and concept documentation through CHIEF.
FY96 Grant Funds for (EIIP) Data Delivery Project
The FY96 105 Grant Funds have been allocated by EPA, and include a project for (EIIP)
Data Delivery. These funds are intended to position state and local agencies with a choice in
implementing the data management recommendations of the EIIP. It is expected that those
choices will be based on DMC products and documentation (as described herein) that are
made available to the inventory community through the first quarter of FY96.
5-2 Emission Inventory Improvement Program
-------
NEXT STEPS
Many participants of the emissions inventory community are not involved with information
technology skills as their primary responsibility. Although many are familiar with the use of
PC packages, other topics discussed here may be foreign to our audience. These topics
include, for example, the widespread use of Internet, the new EIIP data format including
EDI X.12 considerations, and the ideas of data modeling, translation and repositories. The
DMC will focus on education and promotion of the advantages of the new approaches in
order to obtain buy-in, understanding, and hopefully enthusiasm from the emission inventory
community.
IMPLICATIONS AND FOLLOW-UP USING PROTOTYPE
Based on the concept described above, the DMC has prepared an initial proof-of-concept
design that will form the basis for implementing a prototype. The final project plan and
scope of the prototype still remains to be finalized. For example, source and receiver
formats need to be chosen and the mapping (conversion) of those formats to the EIIP data
format needs to be provided. Listed here are the current objectives and scope of the proof-
of-concept for prototype demonstration. (Please refer to Appendix for the initial proof-of-
concept design.)
OBJECTIVES AND SCOPE OF THE PROTOTYPE PROJECT
1. Prove out the technological support of the concepts described in this paper
2. Evaluate mapping and test conversion of EIIP data format to/from specific
State/local fixed formats and to/from AIRS format. (Mapping to be
provided by EIIP pilot participants and programmatic groups).
3. Evaluate ease of programming for EIIP data format
4. Investigate and test operational characteristics of using EIIP data format
over high speed modems
5. Investigate and test operational characteristics of using EIIP data format
over Internet by FTP
Emission Inventory Improvement Program 5-1
-------
DESCRIPTION OF CONCEPT 08/95
This page intentionally left blank
4-14 Emission Inventory Improvement Program
-------
08/95 DESCRIPTION OF CONCEPT
compression can outweigh the benefits, so PKZIP-type approaches should be used with
discretion.
Emission Inventory Improvement Program 4-13
-------
DESCRIPTION OF CONCEPT 08/95
Encryption involves scrambling the data using secret keys and/or algorithms. Anybody
obtaining the scrambled transmission must not be able to decipher it without the key and/or
algorithm. This approach is very secure, and is used for Automated Teller Machine (ATM)
Personal Identification Numbers (PIN secret codes). It is also quite expensive and may be
used only where strong security requirements exist.
Another encryption technique that is receiving much attention by Internet users is the Public
Key approach. Here again the algorithm is published, but now there are multiple keys for
each set of sharing partners. At least two keys are required for each source/receiver pair,
one required at the source for encryption of the data, and a different key at the receiver
allowing deciphering of the transmission.
Other alternatives that are not quite so secure are security boxes that encode/decode the
transmitted message at the modem, so that anything traveling over the transmission lines is
encrypted according to keys stored directly in the boxes, but all data in the source and
receiver processors are not encrypted.
Authentication
Authentication means verifying that the sender or receiver of the data is really who you think
he/she is, and that the data has not been modified. Assuming that the passwords and keys
are held secret, the above methods of access control and encryption can be viewed as
authentication techniques since the senders and receivers are the only individuals knowing the
password or key code. A less expensive technique than encryption, but more selective than
access control, is known as Message Authentication Coding (or MACing). This technique
again uses a secret code known only to the sender and receiver. Rather than encoding the
whole message, however, an algorithm is used based on the text in the message and the
secret code to generate a MAC which is added to the end of the message. Messages are
transmitted as clear text, but the MAC can verify that the message has not been changed and
is from the expected sender. MACing as a technique is much less complicated and requires
much less processing time than DES or Public Key encryption.
COMPRESSION OF DATA MAY REDUCE TRANSMISSION TIME AND STORAGE
REQUIREMENTS
The EIIP data format is expected to compress the data by removing redundancies and not
transmitting null values. Further compression may be achieved using publicly available
software such as PKZIP. This will reduce transmission time and/or band-width requirements
for transmission. Further, if the data to be transmitted is stored locally at the source and or
the receiver, then storage requirements are likewise reduced. For small files the cost of
4-12 Emission Inventory Improvement Program
-------
08/95 DESCRIPTION OF CONCEPT
OTHER APPLICATIONS CHARACTERISTICS IMPORTANT TO THE DATA
TRANSFER CONCEPT
MUST BE SIMPLE TO USE, NOT INVOLVING TIME-CONSUMING OPERATIONS AND SET-
UP
Given the variable frequency of transmission and the fact that use of this data is often less
than a full-time responsibility for someone not always well versed in information technology,
any recommendations or tool development from EIIP projects must bear in mind simplicity in
operations.
SENSITIVE DATA
Over a third of the survey respondents indicated that they transmitted sensitive emissions
inventory data. As more industry partners enter the emissions inventory data arena, security
considerations can be expected to increase. The EIIP data transmission concept may
accommodate security in the ways described below:
Contra/ of Access to a Computer Processor From a Network
This is the technique that most users will already be familiar with. The most widely
accepted approach uses a logon identification and a password known only to the user. The
approach is only as secure as the secrecy with which the password is held.
Automatic dial back (to a phone number at which the receiver should be located) is another
approach to access control which is feasible using some types high-speed dialed modems
available now. Once the receiver has dialed in, the receiver hangs up and the source modem
automatically calls the receiver back. The source has then verified the number at which the
receiver is located.
Control of Access to Individual Data and Applications Within a Computer Processor
Once a user has accessed a particular processor, he/she may have access to any data and
applications residing within that processor. The administrator of the particular system must
design and construct "firewalls" such that data and applications which external users have no
business accessing are totally unavailable to them. Within a given application different levels
of security may exist. For example, access to confidential data may need to be restricted to
authorized individuals. Logon with userid and password to a database package may provide
a sufficient level of protection by data entity or data set, and should be investigated according
to individual project needs.
Encryption
Emission Inventory Improvement Program 4-11
-------
DESCRIPTION OF CONCEPT 08/95
• High-speed communications file transfer. Three methods of data
transmission are being considered in the initial concept:
— Minimum 14.4 Kbps modems over dialed phone lines. Almost all
respondents to the survey already have this level of high-speed modem,
many have or are contemplating purchase of 28.8 Kbps modems.
— Internet FTP
— Internet linked WWW home page use
• Transmission volumes to be supported. We recommend the following
techniques based on the volumes from the survey. The vast majority of
transmissions appear to be in the middle range. Use of the EIIP data format
and file compression software (such as PKZIP) can potentially decrease these
volumes.
— Less than 1M - floppy disks or high-speed communications file transfer
— 1M to 10M - High-speed communications file transfer
— Greater than 10M - High-speed communications file transfer or
consider magnetic tape usage
• Transmission frequencies to be supported. The frequencies indicated in the
survey and recommended solutions under the concept are as follows:
— Daily or more frequent - prefer use of Internet dedicated access. At
this level of frequency the vagaries and operational characteristics of
dialed phone lines may be replaced by a dedicated access line to Internet.
Internet is not without performance problems at peak times, and if
volumes are large, thought should be given to scheduling transmissions at
off-peak.
— Concept designed around monthly to twice per week frequency -
relatively intermittent. The typical frequency from the survey was in
the monthly to twice weekly range. Internet FTP of high-speed dialed
modems both have operational characteristics suitable for this frequency.
4-10 Emission Inventory Improvement Program
-------
08/95 DESCRIPTION OF CONCEPT
PROPOSED TECHNOLOGICAL INFRASTRUCTURE
From our survey, the current technology available to emissions inventory sharing partners
has become clear. This is described below and forms the basis for the concept development,
as well as the proof-of-concept project. These are the initial proposed hardware and software
requirements for implementing the concept.
• Hardware and systems software. A part of the EIIP data transfer concept is
the minimum prerequisite hardware and software configuration on which the
concept is designed to operate. In general, this specification is built around
the results of the data transfer survey, and is shown in the subsections below.
— IBM PC compatible 486 or better. Most EIIP participants already
have 486 class processors in the 50 MHz and above power range. Some
already have Pentiums, many are planning their purchase. 80% of
respondents in our survey indicated that they were willing to increase
their processing power as a direct result of the EIIP recommendations.
— Windows family of operating systems. This is the clear system of
choice among survey participants.
— Transmission software. ProComm or Crosstalk for modem
transmission is recommended but not required. Most of the survey
respondents have one of these software packages. Any transmission
software used should support Zmodem and Kermit file transmission
protocols for reliable data transmission.
— FTP for simple file transmission over Internet. The prototype proof-
of-concept will test FTP transmission. Anonymous FTP appears
particularly well suited to the needs of receivers retrieving data from
working repositories at sources. Almost all participants in the survey
already have Internet FTP access.
— Netscape or Mosaic for Internet WWW implementation. Further
consideration will be given to World-Wide -Web (WWW)
implementations on Internet during continued development of the
concept. Tools such as Netscape and Mosaic make browsing the Web
for emissions inventory data very simple. On-line help via linked home
pages for additional documentation on data availability and metadata
could serve the EIIP user well, and encourage and simplify use and
retrieval of data.
Emission Inventory Improvement Program 4-9
-------
DESCRIPTION OF CONCEPT
08/95
DISTRIBUTED REPOSITORY TOPOLOGIES
Figure 4-4. Repository Topologies - Distributed
The capabilities for distributed databases provided with modern Relational Data Base
Management Systems (RDBMS) such as Oracle or Sybase, allow distribution of data to owning
sources. This approach is shown in figure 4-4 above. The receiver issues a single data base
request to the RDBMS, just as if the data was stored locally. The RDBMS has tables indicating
the location of individual data items in remote data bases. The RDBMS takes responsibility for
retrieving (and if necessary controlling updates to) multiple remote source locations. This
approach requires that all of the participating organizations use a common RDBMS, and that
some central group then acts as data base administrator (this requires maintaining the tables
indicating where individual data attributes are located). Using this type of approach, limited
processing and update can be performed directly on the remote data bases as if they were located
locally. Performance and design considerations for a distributed data base are paramount and not
easy to overcome. The big advantages of this type of approach is first making programming for
the applications programmer accessing the data very simple, and secondly putting responsibility
for access, storage and control of the source data back at each source location.
4-8
Emission Inventory Improvement Program
-------
05/35
DESCRIPTION OF CONCEPT
REMOTE AT SOURCES
"Ui.i.|imnii..lli (.«
s>^. . •'•«tjs-^
Xv*>*""""^
• *W*** .,- -"?}'*»;*
r/r:.7l'<
Figure 4-3. Repository Topologies - Remote at Sources
This configuration is shown in figure 4-3. In this approach each source accepts the responsibility
and cost of making their own data available in the standard EIIP data format. Receivers must
know the location of the data that they require, but then can request from the source at any
convenient time. An example of this approach is the use of Internet anonymous FTP at multiple
source locations.
Emission Inventory Improvement Program
4-7
-------
DESCRIPTION OF CONCEPT
08/95
CENTRAL
Figure 4-2. Repository Topologies - Central
With a central data repository, sources send their data periodically to a central location which
makes the data available to all authorized receivers. This approach is shown in figure 4-2 above.
For example, some states that are regionally related for air quality modeling purposes, are using
such a "centralized" database approach to compile and share data. This approach makes life
simple for sources because they only have to send their data once in the standard EIIP data
format. Likewise receivers can retrieve at any time and vary their requests as necessary.
However some group must take responsibility for the cost, operation and security of the central
data repository.
4-6
Emission Inventory Improvement Program
-------
08/95 DESCRIPTION OF CONCEPT
standard EIIP data format as the "source" or "receiver" format.
One of the expected operating similarities between the X. 12 format and the EIIP data format
is the reduction of data redundancy in multiple records, and subsequent transmission of only
valid fields, i.e., not null values. This can often result in significant compression of the data
in conversion into these formats. The end effect is to reduce the transmission time required
for the data set, thus allowing more data or smaller bandwidth (or modem speed) to be used
in the same amount of transmission time.
OVERVIEW OF DATA REPOSITORY CONSIDERATIONS
Any two participating sites can use the concept described above. The data can be made
available by the source in the EIIP data format on a timeframe suitable for the receiver
without involving any type of long term database. As remarked earlier, the transmission can
be initiated by either the source or the receiver. The data is required to exist in EIIP data
format only when it is made available by the source or until it is translated to a local
processing format by the receiver. Though the EIIP data transfer concept does not require a
data repository, it is compatible with a data repository. As part of the proof-of-concept, the
standard EIIP data format will be processed into a data base providing a repository that can
consolidate and hold EIIP formatted data sets. This will allow an illustration of data
availability for access and potential use of the data.
While data repository considerations are not a focal point of either the data format project or
the data transfer study, it is important to understand how a data repository might fit into the
concept. There is no requirement to adopt a single topology and/or database for all
emissions inventory data. Different programmatic needs have different organizational and
operational characteristics. The flexibility of our repository consideration allows each
programmatic area to choose their own approach, which may be combined into a common
database with other programmatic needs where this makes sense from an organizational,
procedural or cost standpoint. The following examples consider some of the factors
regarding the topology of the repository, and are provided for general understanding and
comparison. The topology means how the data is distributed physically around multiple
locations. Using the concepts described in this paper does not tie the emissions inventory
data to a single structure for a repository database. The data base may be centralized at a
single location, remotely located at the sources, or distributed through the use of advanced
relational database products.
Emission Inventory Improvement Program 4-5
-------
DESCRIPTION OF CONCEPT 08/95
format is probably not the format that will be used locally at the source and receiver for
processing, this satisfies the users requirement to store the data, independently, in formats
for a variety of tools including:
• Flat files for other application formats (e.g. AIRS)
• Lotus and Excel spreadsheets
• Word or WordPerfect text files
• User-friendly PC databases (Paradox, FoxPro, dBase, Access)
• Advanced relational databases (e.g. Oracle and Sybase) - capable of distributed
data repository systems.
The EIIP data format is analogous to an Import/Export format from a spreadsheet. The
spreadsheet cannot process the Import/Export files directly, but the use of the standard
Import/Export format allows for transfer between different versions of the spreadsheet with
unlike formats, and even between different spreadsheets, or spreadsheets and other packages
such as word processors and databases. The EIIP data format allows the data to be
"exported" from the source and "imported" to any receiver understanding and able to
convert the EIIP data format for local use. The ability for unlike systems to convert, or
"map", to the EIIP data model/format is a very critical and non-trivial task, and one that is
basic to the concept. Developing data format translators that can convert from a local source
format to the common EIIP data format may be a relatively modest effort for some, or a
more difficult and resource-intensive effort for others.
X.I2 SCIENTIFIC FORMAT FRIENDLY
The EIIP data format hopes to provide a structural approach that may accommodate the
ANSI standard for Electronic Data Interchange (EDI) X.I2. This format is a more general
standard that can be used for transmission of environmental data, but is not receiving wide
use for that purpose at this time. The EDI X. 12 format is currently being used more in
industry and governmental entities for exchanging business information. Although the EDI
X.12 format may appear complex at first sight, the complexities can be hidden through
translation software so that they only need be considered one time by the developer of the
conversion software. There are commercially available packages for X. 12 format
conversion, and there are investigations regarding the use and suitability of these packages
for translating environmental data formats. The DMC, through its industrial and
governmental representation may engage in a pilot investigation of EDI X. 12 based on the
4-4 Emission Inventory Improvement Program
-------
08/95 DESCRIPTION OF CONCEPT
DEFINITION OF SOURCE AND RECEIVER FILE TRANSFER CONCEPT
The basic concept for the EIIP data transfer recommendations is based on file transfer from a
'source' (that has created or stored emissions data for use by others) to a 'receiver' which
desires to process emissions data from other sources (potentially in addition to local source
emissions data). Two types of program-specific users are defined, sources and receivers.
EIIP participants are often likely to be both sources and receivers for different emissions
data.
The transmission may be initiated by either the source or the receiver. In one
implementation a particular source may have to send data on a regular basis, for example
once per month, to a specific receiver. The source performs the conversion to the EIIP data
format and initiates the data transfer to the receiver. The central receiver then saves the data
transmitted and converts and processes the data on a schedule at the receiver's discretion. In
a second implementation it may make sense for the source to convert the data and make it
available to a group of receivers on an as needed basis. The source may use an anonymous
FTP server, for example, located at the source containing a set of data in the EIIP data
format. Then any receiver needing the data can investigate what is available, and initiate
retrieval of only what that receiver needs.
In either case, the source converts and makes available or sends emissions data file in EIIP
data format, which the receiver can then retrieve or accept, and subsequently convert to a
local format appropriate to his/her use. The scheduling and data processing of the data at the
source or the receiver is entirely independent of the file transmission.
FLEXIBLE TRANSLATION TO AND FROM SOURCE AND RECEIVER
FORMATS
The EIIP data format gives both source and receiver a great deal of latitude in operating
within their own local formats. Below we highlight some of the reasons for this.
THE EIIP DATA FORMAT DECOUPLES USE AND FORMAT AT SOURCE FROM THAT
AT RECEIVER
File transmission in the EIIP data format is uncoupled from local use and application
dependencies at both the source and receiver. The EIIP data format focuses on the format to
be used for data transmission. Both the source and the receiver are free to choose whatever
local tools they wish to process and store the data. They use whatever format and data
structures they need for the particular type of processing they require. For example data
formats used at a receiver for CIS applications are likely to be very different from data
formats used in the statistical analysis of point-specific sample data. Since the EIIP data
Emission Inventory Improvement Program 4-3
-------
DESCRIPTION OF CONCEPT 08/95
Two types of program-specific users are defined, sources and receivers. 'Sources' are
emissions inventory data providers. They have data that is useful and desired by other
'Receiver' emissions inventory data processors. By providing a common data transfer
format, the individual source or receiver need only concern itself with converting the shared
data to or from a standard EIIP data format (data translation). This approach will promote
data sharing because once the format has been converted to the EIIP data format, it will be
available for all other users that can process that same common format. The concept
simplifies and streamlines the data transfer process by acknowledging standard transmission
techniques using Internet and dialed access for initiating data flow. The process is based on
using existing, commercially available packages - as far as possible - for processing, data
translation and data transmission.
DATA TRANSFER ISSUES
Two data transfer issues that are being addressed in the development of the EIIP data transfer
format are described below. The first provides for a transmitted file to contain an identifying
file header, and the second to allow the data attributes to a real extent to be self defining.
FILE HEADER TO INDICATE DATA CONTENTS, SOURCE AND RECEIVER
A file header can be transmitted as the first record of every emissions inventory data
transmission. This header will self-identify the data that follows. It will provide date of
creation, and source and receiver of the data. In this way the receiving application can track
which data sets it has received. Double processing of a file can be avoided. If data is
received on a regular basis, missing transmissions can be identified. This adds significantly
to the quality assurance of the processing of transmitted data.
NEED FOR METADATA OR INFORMATION ON USABILITY OF DATA
Metadata is data about data and includes such items as the method used to collect the data,
the precision of the data, the units used to measure the data, and the typing of the data
(numeric, exponential, character, etc.). By including these type of attributes in the EIIP data
format, quality assurance of the use of the data at once becomes possible, and improper use
of the data is discovered before significant time has elapsed or expenditure made on analysis.
Usually the metadata for a particular attribute will be a constant for that source, and will be
known at that source. It can therefore be added relatively easily during the data translation
process, and becomes part of the quality assurance at the source and receiver for the data
being shared if it is explicitly stated in the data being transmitted.
4-2 Emission Inventory Improvement Program
-------
4
DESCRIPTION OF CONCEPT
INTRODUCTION
The purpose of the concept described here is to promote, streamline, and simplify data exchange
and sharing of emissions inventory data. Today, many independent data bases containing
emissions inventory data exist, especially at the state/local level. These independent logical
databases use a variety of physical tools for support, from word processors (such as WordPerfect
and MS Word), spreadsheets (such as EXCEL and Lotus 1-2-3), PC data bases (such as FoxPro,
Paradox, Access and dBase) to specially programmed systems. Each independent data base has
its own data format and may or may not contain specific data elements available in another
database, or required by a specific application.
Internet
or
Dialed File
Transfer
Standard
EIIP data
Format
Tool Independent
Tool Independent
Figure 4-1: Overview of EIIP Concept
The concept recommended here is shown in Figure 4-1 above, and separates the program-
specific use and storage of the emissions inventory data from the transmission and sharing of the
data. At the program specific level the user is free to choose whatever tool and format is most
suitable for his/her processing purposes. To facilitate the data exchange, a standard EIIP data
format is being proposed. The EIIP common data format is the key to ensuring the quality of the
data being transmitted, and improving the ability to exchange data between unlike systems.
Emission Inventory Improvement Program
4-1
-------
PURPOSE A ND BA SIS OF THE CONCEPT PA PER 08/95
This page intentionally left blank
3-4 Emission Inventory Improvement Program
-------
08/95 PURPOSE AND BASIS OF THE CONCEPT PAPER
• Internet access available and increasing. Internet access is available to or planned
by almost all respondents in the survey. Of the Internet users, all indicated that they
had FTP capabilities, and almost all users indicated that they had access to, or plan to
have access, to the World-Wide Web ("Mosaic").
• Little use of other value-added networks. Of the individuals using "direct network
access", it is clear that the Internet and the EPA NDPD SNA network are the only
significant wide area networks in use. The Value Added Networks (CompuServe,
Prodigy, etc.) were virtually non-existent in the results. Respondents in the survey
using EPA NDPD SNA connections expect a decline in planned usage over the next
two years from 36% to 15%.
• Almost all respondents have high speed modems for data transfer. The most
common current speeds are 9600 and 14.4 Kbs, though the majority of respondents
plan to upgrade to 28.8 Kbs. Almost all respondents having high speed modems have
access to data transfer software (primarily ProComm and Crosstalk) that includes de
facto file transfer standard techniques such as Xmodem, Ymodem, Zmodem, and
Kermit.
• Data transfer volume and frequency variable. Volumes and frequency of data
transfer varied widely among respondents. The mean of volumes being transmitted is
in the half megabyte to 10 megabyte range. Only 13% of respondents indicated an
average transmission range that exceeded 10 Mbytes. Only 10% of respondents
indicate an average transmission volume that was less than 500K. The frequency of
transmissions for the majority of respondents is in the once per month to twice per
week range.
Emission Inventory Improvement Program 3-3
-------
PURPOSE AND BASIS OF THE CONCEPT PAPER 08/95
subsequent interpretation by the DMC, have helped to define the average computer
processing and telecommunication capabilities, current or planned in the participating
community. Understanding and establishing that baseline medium has lead to initial
recommendations regarding procedures that may be used to improve data transfer. The full
results and conclusions have been documented in deliverable "EIIP Data Transfer Survey
Results and Analyses". This document is available through the CHIEF bulletin board (on
EPA's Technology Transfer Network), as document "ANALYSES.WP". A summary of the
conclusions from the survey is given below.
• Use of paper and floppy disks. Though general use of paper and floppy disks was
noted by all, survey participants expected the use of paper for data transfer to decline
by 30% in terms of the number of users including these media in their two year
plans. The analysis of the survey results addresses alternative technologies available
that can improve the quality and generate automated data associated with these manual
transfer techniques. At this time there are no further DMC projects associated with
these manual recommendations.
• Predominance of powerful IBM-compatible PCs. The Intel 486-series was, by a
wide margin, the most prevalent type of PC workstation in use by the survey
respondents. Other responses mentioned UNIX workstations, UNIX servers, Unisys
A16, Mac Quadra, Sun SPARC 29, Novell LAN, Hewlett-Packard model 9000 series
735/125 and a HP755 workstation. Some responses indicated that they were either
using, or intending to purchase, the new Pentium series of processors.
• ASCII file format. A very high percentage of respondents use ASCII files for
transferring inventory data. No other file type can be considered significant.
Spreadsheets (split almost equally between Lotus and Excel with some Quatro Pro)
and word processors (split almost equally between Word and WordPerfect) are used
by over half the respondents. Overall, the responses to this group of questions
suggests that a wide range of file formats are being used by individual groups.
Popular data base formats that were indicated are primarily dBase derivatives or user-
oriented relational databases including dBase, Paradox, MS Access, and FoxPro.
• AIRS, and "other" record formats heavily used. Record format responses
revolved, for the most part, around AIRS (64%), "Other" (31%), and EPS-input
(26%). We believe that this mix reflects the current range of applications that are
used to store or process emissions data, with AIRS being the most predominant.
However, the wide range of formats in the "Other" category indicates that there are a
number of other applications (mostly PC databases) that are storing or manipulating
emissions data.
3-2 Emission Inventory Improvement Program
-------
PURPOSE AND BASIS OF THE
CONCEPT PAPER
PURPOSE OF CONCEPT PAPER
The concept paper explains the basis for the initial recommendations from the DMC, and
provides the inventory community the opportunity to understand and comment as their input
toward the final recommendations. Specific objectives of the concept paper are to:
• Interpret the conclusions from the survey, by taking into consideration what the
emission inventory community is capable of technologically, based upon their
responses to the survey.
• Present the conceptual basis for the recommendations from the DMC, by abstracting
from the detailed survey findings to a set of overall concepts that will be used as the
basis for subsequent projects.
• Provide an integrated and organized view of data format activities within a proposed
data transfer protocol, bringing together the diverse activities that have been pursued
by the EIIP/DMC.
• Provide a basis for the initial proof-of-concept design that will be implemented and
tested in the prototype project.
• Seek input from the emission inventory community in order to refine the initial
recommendations through discussion before they are finalized.
The results and analysis of the data transfer survey provide, in part, the foundation for the
concept. The survey findings are summarized as follows.
DATA TRANSFER SURVEY RESULTS
The intent of the DMC data transfer survey was to query a representative sample of the
emissions inventory community regarding their current and future capabilities for transferring
inventory data. Questions were asked regarding the frequency and quantity of emissions data
transfer. Also the survey attempted to determine the file and record formats used during data
transfer and individual preferences regarding formats and transfer methods. Of secondary
concern was determining the general nature of the hardware and software currently used by
those individuals who transfer emissions inventory data. The survey results, and their
Emission Inventory Improvement Program 3-1
-------
PROPOSED APPROA CH FOR IMPROVING DA TA EXCHANGE 08/95
The EIIP data model/data format should be developed and approved for use as soon as
possible. The EIIP data format is the key to ensuring the quality of the data being
transmitted, and improving the ability to exchange data between unlike systems at
participating sites (i.e., state/local, industry, EPA). The ability for unlike systems to
convert, or "map", to the EIIP data model/format is acknowledged to be a very critical and
non-trivial task, and one that is basic to the described community concept. Developing data
format translators that can convert from a local source format to the EIIP format can be a
relatively modest effort for some, or a more difficult and resource-intensive effort for others.
The emission inventory community will be requested to actually conduct a "mapping"
exercise as part of their review of the EIIP data model. Such an intensive review is
necessary to help confirm that the EIIP data format will be practical and feasible for use by
the broad community. The translation step will also be demonstrated in the prototype.
2-2 Emission Inventory Improvement Program
-------
PROPOSED APPROACH FOR
IMPROVING DATA EXCHANGE
This paper describes some concepts that can be beneficial to improving the quality and
efficacy of emission inventory data transfer through automated transmission. The EIIP is
promoting the community's technological capabilities toward electronic transmission by
developing this data transfer concept for implementation. In this concept, the program-
specific use and storage of the emissions inventory data is separated from the transmission
and sharing of the data. Cost, timely availability, and quality of data, are some of the
considerations of this approach. To standardize and establish an improved data transfer
protocol by the means described here, may require some adjustments to data management
philosophies, and to operating infrastructure. The EIIP only intends to promote a data
management strategy that is demonstrated and considered achievable by the emission
inventory community.
A full and systematic investigation is being performed to understand how the availability and
sharing of emission inventory data may be improved for the user community. This holistic
approach is intended to proceed through a logical and disciplined sequence of events, which
are reflected in the current and planned DMC activities. While this investigation is
considered timely and necessary, it is also acknowledged to be a very ambitious
consideration for the emission inventory community. The inventory community is being
provided review and comment opportunities in order to assess and understand the possible
improvements. Inherent in this process, is the necessity that the participating community
validate the concepts being promoted, the approach being taken, and the potential for success
of establishing an improved data transfer protocol.
It is key that the prospective users of these concepts understand the benefits that they provide
and their proper use. To this end an initial proof-of-concept design has been developed
(Appendix) to supplement and illustrate an implementation of the described concept. This
proof-of-concept system may then be used as the basis for demonstrations, user education,
and promotion of the EIIP recommendations. Aspects which will be demonstrated include:
• Translation of local user formats to the common EIIP data format
• Use of Internet FTP (File Transfer Protocol) to transmit the EIIP data format
• Demonstration of other high-speed dialed file-transfer transmission techniques for the
EIIP data format
Emission Inventory Improvement Program 2-1
-------
BA CKGROUND 08/95
This page intentionally left blank
1-4 Emission Inventory Improvement Program
-------
08/95 BACKGROUND
Data Transfer Concept Paper
The concept paper describes a practical and effective operating procedure that may improve
the availability and exchange of emission inventory data between state/local agencies, EPA,
and industry. It proposes a consolidated approach that integrates and promotes the use of the
EIIP common data format with efficient data transfer techniques. Included is a preliminary
proof-of-concept design that may be used to test and demonstrate the concept.
Prototype Demonstration
A prototype will be designed and implemented as a pilot project in order to test the concept,
i.e., proof-of-concept. The steps taken for implementing the prototype, and the results, will
be documented for demonstration purposes.
Approach Study
As a concluding activity, the DMC will formulate its recommendations for the emission
inventory community in the form of an approach study. The approach study is intended to
capture and document the experience from implementing the prototype using the EIIP data
format. The approach study will provide an effective planning tool for the community.
Emission Inventory Improvement Program 1-3
-------
BACKGROUND 08/95
management recommendations for the emission inventory community. The DMC activities
specifically include the following:
Development of Data Model/Common Data Transfer Format
In order to establish a consistent and common format for data transfer, the initial emphasis
for the DMC has been to develop a robust core data model (core model containing basic set
of data elements. The data model is being constructed based on input provided by the EIIP
point, area, mobile, biogenic and quality assurance committees. The approach taken with the
EIIP data model includes some provision for flexible data entities and attributes, thereby
making the model amenable to updates in an efficient, timely, and cost-effective manner.
Code tables will be used to operate the flexible attributes, making it possible to accommodate
data from all types of emissions inventory programs and to store the data in a consistent
format. The flexible attributes require the source of the data to be specific about the content,
and also define for the receivers the data they are getting.
The EIIP data model / format is being developed in three phases. Each phase is expected to
build upon previous phases, emphasizing the extensible nature of the data model. The three
phases are:
• Phase I Core Data Model - The primary focus of this data model development is to
support regional air quality modeling. The goal of this phase is to facilitate data
transfer between state/local agencies and the EPA. This phase of the data model
development is currently underway. A draft of the Phase I core data model will be
available on the CHIEF Bulletin Board in early August 1995.
• Phase II - The focus of this phase will be to incorporate additional emission inventory
data elements that overlap into other program areas, for example; Title V permits
related data, and Title III toxics data. The data model will be developed to a greater
level of detail than the Phase I model and will support additional data transfer
between states and between industrial facilities and state agencies. Some aspects of
the data model development for Phases I and II are occurring concurrently.
• Phase III - The focus of the Phase III model is the implementation of complete data
set transfer between facilities and state agencies. Additional data elements will be
incorporated, as necessary to improve data transfer from facility-to-state and state-to-
state.
Data Transfer Survey
The DMC has conducted a survey with the emission inventory community as a means of
gauging the user capabilities for data transfer. The analysis of those survey results form, in
part, the basis for this concept paper and the supplemental proof-of-concept design document
(included as Appendix to this document).
1-2 Emission Inventory Improvement Program
-------
1
BACKGROUND
EIIP/DMC MISSION
The Clean Air Act Amendments of 1990 (CAAA) require that many state and local
agencies collect emission inventory data as a basis for planning and demonstrating
attainment with National Ambient Air Quality Standards (NAAQS). Emission
inventories are a basic component to air quality modeling and other air pollution
management analyses which are used to demonstrate that proposed air pollution control
strategies are sufficient to attain the state/local and federal air quality standards. This
data is an essential part of the infrastructure in managing environmental air pollution at
the local, state, regional and federal levels.
The Emission Inventory Improvement Program (EIIP) has been formed as a joint effort
of state and local air agencies and EPA for the purpose of improving the quality of the
emissions data collected as well as the way the data is transferred and shared among
users. The EIIP is developing standard procedures for collecting, calculating, storing,
and reporting of emissions data. The ultimate goal of the EIIP is to provide cost-
effective, reliable inventories by improving the quality of emissions data collected and
providing for uniform reporting of this information within the emission inventory
community.
EMP/DATA MANAGEMENT COMMITTEE
The EIIP Data Management Committee (DMC) is developing and coordinating
recommendations for technology and procedures to be used in sharing data among the
emissions inventory community. The primary goals of the DMC are:
• to develop a recommended standard EIIP data format for organizations to use in
sharing emission inventory data; and
• to recommend methods for transferring emissions data among State/local air agencies,
EPA, and other organizations.
DATA MANAGEMENT COMMITTEE ACTIVITIES
The Data Management Committee has, on behalf of the EIIP, undertaken a number of
diverse but related activities. These activities are expected to culminate in a series of data
Emission Inventory Improvement Program 1-1
-------
FIGURES
Figure Page
4-1. Overview of EIIP Concept 4-1
4-2. Repository Topologies - Central 4-6
4-3. Repository Topologies - Remote at Sources 4-7
4-4. Repository Topologies - Distributed 4-8
A-l. Functional Flow A-4
A-2. Sources Data Flow A-5
A-3. Receiver Data Flow A-6
VI Emission Inventory Improvement Program
-------
CONTENTS
Section Page
Prototype Functional Requirements A-6
State/Local Node (Sources) Requirements A-6
Inputs A-7
Sequencing A-7
Processing A-8
EPA Node (Receiver) Requirements A-9
Inputs A-10
Sequencing A-10
Processing A-ll
Transfer Protocol Requirements A-ll
Data Compression Requirements A-12
Emission Inventory Improvement Program
-------
CONTENTS
Section Page
Proposed Technological Infrastructure 4-9
Other Applications Characteristics Important to the
Data Transfer Concept 4-11
Must Be Simple to Use, Not Involving Time-Consuming Operations
and Set-Up 4-11
Sensitive Data 4-11
Control of Access to a Computer Processor From a Network . . 4-11
Control of Access to a Individual Data and Applications
Within a Computer 4-11
Encryption 4-12
Authentication 4-12
Compression of Data May Reduce Transmission Time and Storage
requirements 4-12
5. Next Steps 5-1
Implications and Follow-up Using Prototype 5-1
Objectives and Scope of the Prototype Project 5-1
Provide Assistance in Implementing the Recommended EIIP Data
Format and Data Transfer Procedures 5-2
EIIP Data Management Products and Documentation
Available as 'Primers' 5-2
FY96 Grant Funds for (EIIP) Data Delivery Project 5-2
Appendix: Preliminary Design for EIIP Proof of Concept Prototype A-1
Introduction A-2
Purpose A-2
Background A-2
Scope A-2
EIIP Proof of Concept Data Flow A-3
Concepts A-3
Functional Flow A-4
State/Local Node (Sources) Data Flow A-4
EPA Node (Receiver) Data Flow A-5
IV Emission Inventory Improvement Program
-------
CONTENTS
Section Page
1 Background 1-1
EIIP/DMC Mission 1-1
EIIP/Data Management Committee 1-1
Data Management Committee Activities 1-1
Development of Data Model/Common Data Transfer
Format 1-2
Data Transfer Survey 1-2
Data Transfer Concept Paper 1-3
Prototype Demonstration 1-3
Approach Study 1-3
2. Proposed Approach For Improving Data Exchange 2-1
3. Purpose and Basis of the Concept Paper 3-1
Purpose of Concept Paper 3-1
Data Transfer Survey Results 3-1
4. Description of Concept 4-1
Introduction 4-1
Data Transfer Issues 4-2
File Header to Indicate Data Contents, source and Receiver 4-2
Need for Metadata or Information on Usability of Data 4-2
Definition of Source and Receiver File Transfer Concept 4-3
Flexible Translation to and from Source and Receiver Formats 4-3
The EIIP Data Format Decouples Use and Format at Source
From that at Receiver 4-3
X.12 Scientific Format Friendly 4-4
Overview of Data Repository Considerations 4-5
Central 4-6
Remote at Sources 4-7
Distributed Repository Topologies 4-8
Emission Inventory Improvement Program Hi
-------
EIIP DATA TRANSFER
CONCEPT PAPER
Efficiency and Efficacy of Emissions Inventory Data
Transfer Through Automation
August 1995
Prepared by:
Technology Planning & Management
Corporation
Prepared for:
Data Management Committee
Emission Inventory Improvement Program
-------
EIIP goals and objectives are being addressed through the production of seven guidance
and methodology volumes. These seven are:
• Volume I: Introduction and Use of EIIP Guidance for Emissions
Inventory Development
Volume II: Point Sources Preferred and Alternative Methods
Volume III: Area Sources Preferred and Alternative Methods
Volume IV: Mobile Sources Preferred and Alternative Methods
Volume V: Biogenics Sources Preferred and Alternative Methods
Volume VI: Quality Assurance Procedures
Volume VII: Data Management Procedures
The purpose of each volume is to evaluate the existing guidance on emissions estimation
techniques, and, where applicable, to identify the preferred and alternative emission
estimation procedures. Another important objective in each volume is to identify gaps in
existing methods, and to recommend activities necessary to fill the gaps. The preferred
and alternative method findings are summarized in clear, consistent procedures so that
both experienced and entry-level inventory personnel can execute them with a reasonable
amount of time and effort. Sufficiently detailed references are provided to enable the
reader to identify any supplementary information. Users should note that the number of
source categories or topics covered in any volume is constantly expanding as a function
of EIIP implementation and availability of new information.
It is anticipated that the EIIP materials will become the guidance standard for the
emission inventory community. For this reason, the production of EIIP volumes will be
a dynamic, iterative process where documents are updated over time as better data and
scientific understanding support improved estimation, QA, and data management
methods. The number of individual source categories addressed by the guidance will
grow as well over time. The EIIP welcomes input and suggestion from all groups and
individuals on how the volumes could be improved.
-------
PREFACE
As a result of the more prominent role given to emission inventories in the 1990 Clean
Air Act Amendments (CAAA), inventories are receiving heightened priority and
resources from the U.S. Environmental Protection Agency (EPA), state/local agencies,
and industry. More than accountings of emission sources, inventory data are now
providing the prime basis for operating permit fee systems, State Implementation Plan
(SIP) development (including attainment strategy demonstrations), regional air quality
dispersion modeling assessments, and control strategy development. This new emphasis
on the use of emissions data will require significantly increased effort by state/local
agencies to provide adequate, accurate, and transferrable information to meet various
agency and regional program needs.
Existing emission inventory data collection, calculation, management, and reporting
procedures are not sufficient or of high enough quality to meet all of these needs into
the next century. To address these concerns, the Emission Inventory Improvement
Program (EIIP) was created. The EIIP is a jointly sponsored endeavor of the State and
Territorial Air Pollution Program Administrators/Association of Local Air Pollution
Control Officials (STAPPA/ALAPCO) and the U.S. EPA, and is an outgrowth of
recommendations put forth by the Standing Air Emissions Work Group (SAEWG) of
STAPPA/ALAPCO. The EIIP Steering Committee and technical committees are
composed of state/local agency, EPA, industry, consultant, and academic representatives.
In general, technical committee participation is open to anyone.
The EIIP is defined as a program to develop and use standard procedures to collect,
calculate, store, and report emissions data. Its ultimate goal is to provide cost-effective,
reliable, and consistent inventories through the achievement of the following objectives:
• Produce a coordinated system of data measurement/calculation methods as
a guide for estimating current and future source emissions;
• Produce consistent quality assurance/quality control (QA/QC) procedures
applicable to all phases of all inventory programs;
• Improve the EPA/state/local agency/industry system of data collection,
reporting, and transfer; and
• Produce an integrated source data reporting procedure that consolidates
the many current reporting requirements;
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Transaction Set Trailer
Ref.
Des.
SE01
SE02
003
Summary
Mandatory
1
To indicate the end of the transaction set and provide the count of the transmitted
segments (including the beginning (ST) and ending (SE) segments)
1 SE is the last segment of each transaction set.
i.' TiisiefflinsBtilll^ —^"Jf^^t^.r," •
'. •'•"
itewithift.-
Data Element Summary
Data
Element Name Attributes
96 Number of Included Segments M NO 1/10
Total number of segments included in a transaction set including ST and SE
segments
329 Transaction Set Control Number M AN 4/9
Identifying control number that must be unique within the transaction set
functional group assigned by the originator for a transaction set
142
Emission Inventory Improvement Program
-------
02/97 PROTOTYPE 841 CONVENTION DOCUMENT
specification
05 Calculated based on ratio in order to measure pollutant
06 Calculated based on pilot bench study
07 State Stack Test
08 State Material Balance
09 State Efficiency of Control Device
10 Company Material Balance
11 Company Efficiency of Control Device
12 Continuous Emission Monitoring
13 Calculated based on AP-42 emission factor
14 Calculated based on state/local agency emission factor
15 New construction, not yet operational - emissions are
zero
16 Operations ceased- emissions are zero
17 Calculated based on FIRE emission factor
18 Calculated based on user-supplied emission factor
19 Calculated based on EPA speciation factor
20 Calculated based on state/local agency speciation factor
21 Calculated based on trade association emission factor
22 CO Stack Test Approved by State
23 Other CO Stack Test Approved by State
24 State Factor Used by State
25 State VOC Calculation
26 Company SCC Factor
27 Company VOC Calculation
28 Other miscellaneous emission method code
A AIRS Rating A
B AIRS Rating B
C AIRS Rating C
D AIRS Rating D
E AIRS Rating E
F AIRS Rating F
Emission Inventory Improvement Program 141
-------
PRO TO TYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
REF02
J\ji/.r Reference Identification
755
STA
Detail
Optional
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
1. This
Data
Element Name
Data Element Summary
128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
j^tfXKt&Cni.tl&f' ,-*-:'* *a$
sferSi^Sdi&g^l;;,. ..? £.t-.>;v^
Customer specification number
1 r*•-«"<*P*i*8^*«i*>a2s;£E22Es«;-.,< ».• a«sv-• ;i'i»^,-..5v
DO
127 Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
I,
02
03
04
**•«-•. x^ssi
**r: 'i'i'.^ti »
:s»vjvi.:*-.':tf]
iiV^.v-- •,•««
rn^rf'1
Calculated based on source test or other emission
measurement
Calculated based on material balance using engineering
knowledge of the process
Calculated based on best guess/engineering judgment
Calculated based on vendor emission factor
140
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
STA07
STA08
741
935
Power to which a unit is raised
1. This element is only applied when CID04 (prior segment) code is "ES".
2. This element contains the exponent allowing the formulation of the
complex expression that is required as the unit of measure associated with,
STA02, : --- '.'•<•'••. •*..: :, ,E~ ,. ,-•.•"•'•;.
3. When applying a complex expression (e.g., kilograms per day), apply me *s ^
exponent of$4": as pear^Aeexiamplenoted"n|STA03. ; ^i. i,u
Range Maximum O R 1/20
The value specifying the maximum of the measurement range
Measurement Significance Code O ID 2/2
Code used to benchmark, qualify or further define a measurement value
31
71
76
85
Calculated
Indicated all> "
Low
Medium
Indies
<• * .'w»1
High
Indfcatesan
mgrn T - - -.X*. ***# *-
m&'<* -\'-f.- -..',„
&t :jsKuui*tai
U *^- -—//"'• ,;
%$£S£;:^r.Z£&
¥~
Emission Inventory Improvement Program
139
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
1 . This element contains the value associated with the emission specified in ,
'
STA03
C00101
C00104
COOl Composite Unit of Measure O
To identify a composite unit of measure (See Figures Appendix for examples
of use)
I. This composite is only applied when CID04 (prior segm
;; "",.•"', .'-Sir "... ' .:-•;• •« . »--* V-.'f.", .<_../ -\'"">
'
imust be«
(1
355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
59
61
CO
F5
GR
KG
LB
M5
MP
PI
TN
Megagram
Unit of mass
Parts Per Million
Parts Per Billion
Cubic Meters (Net)
MOL
Gram
Kilogram
Pound
Microcurie
Metric Ton
Percent
Net Ton (2,000 LB).
355 Unit or Basis for Measurement Code
ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
C00105
DA
DK
YR
1018 Exponent
Days
Kilometers
Years
O R
1/15
138
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
STA01
STA02
IS 1 A Statistics
751
STA
Detail
Optional
1
To provide summary statistics related to a specific collection of test result values
n3E^^irlwr«®BHait> is "EF* or "ES":
by an estimate based on
-'? " -- ^-" - - < '-"*- -4
Data Element Summary
Data
Element Name
950 Statistic Code
A code specifying the specific statistic being reported
Attributes
M ID 2/2
15
16
Maximum Average
Process Capability Upper
30 Average
739 Measurement Value
The value of the measurement
M R 1/20
Emission Inventory Improvement Program
137
-------
PRO TO TYPE 841 CONVENTION DOCUMENT 02/9 7
following alphabetic list: .....
01 Calculated based on source test or other emission
measurement
02 Calculated based on material balance using engineering
knowledge of the process
03 Calculated based on best guess/engineering judgment
04 Calculated based on vendor emission factor
specification
05 Calculated based on ratio in order to measure pollutant
06 Calculated based on pilot bench study
07 State Stack Test
08 State Material Balance
09 State Efficiency of Control Device
10 Company Material Balance
11 Company Efficiency of Control Device
12 Continuous Emission Monitoring
A Area Source Questionnaire
C Direct calc. of emissions by solvent use, all solvents
emitted in time period
D 80% - Default value
E Source in compliance due to irreversible process that
eliminates solvent use
H 90% - Default- enhance monitoring
L Local category-specific rule effectiveness factor - not
EPA regulated
M Continuous emission factor
N Source not subject to regulation
P Point Source Questionnaire
S EPA Single Source Category Determination Protocol
Study
U Uncontrolled emission
136 Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
REF02
lvIl<.F Reference Identification
745
MEA
Detail
Optional
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
2. This!
3. WheBNfEAOt(pnorseg^enOis"AG^JAJp
fit^CB".w;^-.v?•/-> ..-•>•
it provides method codes
A* s<-- 2^ *y4«*-," • •. .,ii--w ^4-m*JA;rf»*w,.'"j"4#i*-.'«r-ft,;^.s;^
^^^^^^^•'^'^^^^^••:^^;^
rotibasedmaoaoi'^cte
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
., "«j.«f?»> >-•*-- if.-s-NF.'s-1- ,,t/ -"«£7i^;r-a**1'*'' -"rjaKJ**"*--v"'"-.',.-•<•;* *<•- 'H-a
2. REFOi:code;"ZZ" is only applied when MEAOI (prior segment) is "AG".V:
,- „ -=^x4iH^»iaii;i.s^*&:5^;t:fiafe&-^»frfe>»^Sfcc.i&:,rSt,, ,<•*.- i-.^.^-.e*?
3.: This element
re(L
C3
Customer specification number
ZZ
127 Reference Identification
I.
Mutually Defined
•sw*"**?*~ "fc-i^E**^* i* ^^ '""• v*" "*F'~t*&s~ '"• "•<•* '** •» •* •»" ' ; y s
jdentifStt for rule effectiveness -1
K^p*^ ';,...,.,«,afi*t.*KJtJi>:?ti^'-**-*h *, ^, •" - , . , - .
"AQV1:-;
X AN "7/30"
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
1. When REFO I is "CJ'Y this
associated with MEAO>I iSw sooAHSdtt* on^ from me
' '
2. When REFO I is "C3", mis element contains an appropriate method code • 4
associated with MEAOt (prior segm^>o^|A6?/Select;oiie from me 1
Emission Inventory Improvement Program
135
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
MEA03
MEA04
AH
PM
Gross Compliance Total
,,
Permitted -
The condition or activity approved by the appropriate
regulatory agency
Indicates tie level of ndej^^o^^;?^*^ vT^I
.,• ..-. .„.:, „. . -. >,.,.. ^jiaJFjK. ,-iv.w..'A*:tejs&-^i*,RS-v.r;iSI>«
739 Measurement Value X R 1/20
The value of the measurement
C001 Composite Unit of Measure * """"*'' °" '""'"" ' ..... ^*-Jfc*.^-™««.w
To identify a composite unit of measure (See Figures Appendix for examples
of use)
C00101 355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
.
PI Percent
MEA07 935 Measurement Significance Code O ID 2/2
Code used to benchmark, qualify or further define a measurement value
22
23
31
Actual
Predicted
Calculated
134
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
MEA01
Measurements
741
MEA
Detail
Optional
1
To specify physical measurements or counts, including dimensions, tolerances, variances,
and weights (See Figures Appendix for example of use of COO 1)
1
2
3
4
5
1
1
1.
If MEA05 is present, then MEA04 is required.
If MEA06 is present, then MEA04 is required.
Only one of MEA08 or MEA03 may be present.
If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
At least one of MEA03 MEA05 MEA06 or MEA08 is required.
MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
2. This; segment only applies when CID04 (prior segment) is "CE".
3. This loop ptb^vid^
-^'^^^^iS^^lit "*•;-,-•.** 7*
- aggregate control efficiency metilod code-r *^ -
4. Ww»_ _
capture/controli
(prior segment) is "CE", ibis seieflt provides rule effectiveness^tofal «2
• •-'• ~ " -
***«:£•"•* ••-,';«";•-v^v-hJ*,""-^'" - ' •.- •-•";"-". • -,-'v xv.&g-*!
: ^ s. Jl'**^T J , , ' i~ • *.}~-$!.--^^''^t$-- ~,l i. \ -,.^^v «;-^i; *'._-,-.^f^^^,1 '|*
I eflffciency of ^iwrcenfebased on" a «kaJafiw>^^|^^^^
Data Element Summary
Data
Element Name Attributes
737 Measurement Reference ID Code O ID 2/2
Code identifying the broad category to which a measurement applies
I. This element indicates the type of aggregate control information is being
reported with th& iteration, of the loop. Select one from the following list
AC Compliance Total
Indicates the level of rule effectiveness '
Emission Inventory Improvement Program
133
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
TMD02
TMD03
TIVLD Test Method
729
CID
Detail
Optional
To describe the nature of the test performed
1 If TMD09 is present, then TMD02 is required.
2 If either TMD02 or TMD03 is present, then the other is required.
1 TMD07 is the date of the test method as assigned by the issuing organization.
2 TMD08 is the document revision number.
1 TMD09 specifies the individual code list of the agency specified in TMD02.
mot apply with BIOGENICSOURC
whether the emission
Data
Element
559
751
Data Element Summary
Name
Agency Qualifier Code
Code identifying the agency assigning the code values
1. ThSelementideiuifiestge£
Attributes
X ID 2/2
EP United States Environmental Protection Agency (EPA)
Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
m
c
u
Controlled
Uncontrolled
132
Emission Inventory Improvement Program
-------
02/37 PROTOTYPE 841 CONVENTION DOCUMENT
1. This element identifies the agency maintaining the code values applied with >
this segment '_" • _ _ '• ,., ^ ,t> 'r .~'
EP United States Environmental Protection Agency (EPA)
CID04 751 Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
1. Ttmnote-pertMsto^ "J
***; **-^|^- - , j
2. TTiis element indiratesAeinfonnatioiibemg reported wife ;
AeJ«^)^leJe^a^|R^^foI^w|B^ ; ]
CE Aggregate Control Information
EF Emission Factor
ES Estimated Emissions
Emission Inventory Improvement Program 131
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
CID
Characteristic/Class ID
Notes:
Ref.
Des.
CID03
725
CID
Detail
Optional
1
To specify the general class or specific characteristic upon which test results are being
reported or are to be taken
1 If CID06 is present, then both CID03 and CID04 are required.
2 If CID07 is present, then at least one of CID04 or CID05 is required.
3 If either CID03 or CID04 is present, then the other is required.
4 At least one of CIDO 1 CID02 CID04 or CID05 is required.
CID06 specifies the individual code list of the agency specified in CID03.
CID07 refers to whether or not the characteristic identified in CID04 or CID05 or
both is affected by the product change. If it is affected, the value is "Y". A value of
"N" is used when it is known that it will not be affected. Any other value indicates it
is indeterminate.
following informa
i*s . ~ " ~ • », «•.- "> -.. ub» i»fai*'»»-
130
Data Element Summary
Data
Element Name Attributes
559 Agency Qualifier Code X ID 2/2
Code identifying the agency assigning the code values
Emission Inventory Improvement Program
-------
02/37 PROTOTYPE 841 CONVENTION DOCUMENT
05 Physical
06 Process
PID08 1073 Yes/No Condition or Response Code O ID 1/1
Code indicating a Yes or No condition or response
1. This segment does not apply whhBICXjENIC SOURCE repbrtrng.-•'••''*-??>v|
2. This element indicates whether the control strategy indicated in MSG01
(prior segment) applies to the level specified P1D04. Select one from toe •
N No
Y Yes
Emission inventory Improvement Program 129
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
PID01
PID03
PID04
A JJLJ Product/Item Description
661
PID
Detail
Optional
1
To describe a product or process in coded or free-form format
1
2
3
4
1
2
3
If PID04 is present, then PID03 is required.
If PID07 is present, then PID03 is required.
If PID08 is present, then PID03 is required.
At least one of PID04 or PID05 is required.
Use PID03 to indicate the organization that publishes the code list being referred to.
PID04 should be used for industry-specific product description codes.
PID08 describes the physical characteristics of the product identified in PID04. A
" Y" indicates that the specified attribute applies to this item. A "N" indicates it does
not apply. Any other value is indeterminate.
If PID01 = "F", then PID05 is used. If PID01 = "S", then PID04 is used. If FIDO 1 =
"X", then both PID04 and PID05 are used.
Use PID06 when necessary to refer to the product surface or layer being described in
the segment.
PID07 specifies the individual code list of the agency specified in PID03.
Data Element Summary
Data
Element Name
- 349 Item Description Type
Code indicating the format of a description
3»W!«l^™^^*--'*wr^»W»?«i*».*»*-'-i.«-f - *5~i-i jjAWnn*
fPEte'^itt^-mdiraleK^s:
;1-;g-i»—i 'ii-^ifl!_i.-' .»•;,':.',' -dias:J%t~n&tf3:i,
Attributes
M ID 1/1
S Structured (From Industry Code List)
559 Agency Qualifier Code X ID 2/2
Code identifying the agency assigning the code values
EP United States Environmental Protection Agency (EPA)
751 Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
1.
the loop^ Select one from me fbUowmg list
04 "Site/Source™"
128
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 84 J CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
MSG01
MSG Message Text
655
SPI
Detail
Optional
To provide a free form format that would allow the transmission of text information
1 MSG02 is not related to the specific characteristics of a printer, but identifies top of
page, advance a line, etc.
I.'Jf&°&£jmij$^ ; \
". •saaj^'ii V',*.<;~ **"<• '^^'.spS^'Cafi^"-*VS"feJ^ ' '. . •*'• d •'"-''*' •'"-•• .-""""' *- 1
':-•-.c- r*r^H 'r^
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
8D Chemical Abstract Service Number
19 Pollutant
SPI03 127 Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
1. When SPI02 Is "8D", this etenertcontams aChemJcal A&steactServi"c^l1
2. When SPI02is^I9\&is element cotttains a poflutaa^
'- ' *"'-'-V.*-"' -- - .• •~-'"
CO
HC
ISO
MONO
NMHC
NMOC
NMOG
NO
NOX
NOY
OVOC
PB
PM
PM10
PM25
ROG
SOX
TOG
VOC
-'efi
Carbon monoxide
Hydrocarbons
Isoprene
Monoterpines
Nonmethane hydrocarbons
Nonmethane organic compounds
Nonmethane organic gases
Nitric oxide
Nitrogen oxides
Nitrogen oxides plus secondary compounds
Other volatile organic compounds
Lead
Paniculate matter
Paniculate matter >= 1 0
Paniculate matter >= 2.5
Reactive organic gases
Sulfur oxides
Total organic gases
Volatile organic compounds
S£'sr-S
126
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
dJr 1. Specification Identifier
639
SPI
Detail
Optional
1
Purpose: To provide a description of the included specification or technical data items
Syntax Notes: 1 If either SPI02 or SPI03 is present, then the other is required.
Semantic Notes:
Comments:
Notes: I. This foopprovidesffiell
-con:
- emission-
- control
- '-.-ffrA
2. This segmeirtpToyidestfecon:
Number, and
Ref.
Des.
SPI01
SPI02
Chemical Abstract Service (CAS)|
"
3. This
or "19" and the associated
*-«*» ,~.~zi?
Mf toprovidfe eimer SPI(K:5c<3de,
4. Loop (segments SP
TJ,
< informatfon
control" "**
ithficirbdn monoxide with respect to a
" ""
Data Element Summary
Data
Element Name
786 Security Level Code
Attributes
M ID 2/2
Code indicating the level of confidentiality assigned by the sender to the
information following
1 .,
00
02
90
92
Company Non-Classified
Company Confidential
Government Non-Classified
Government Confidential
128 Reference Identification Qualifier
Code qualifying the Reference Identification
ID 2/3
2. This elementindicates the type of pollutant-specific identifier being
reported with thfe iteration^of flic loop. Select one from die following list:
Emission Inventory Improvement Program
125
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Ref.
Des.
HL01
HL02
HL03
HL04
200'59~ : - ." V ' :-.-•
02^' . ; ', ." ~"~ ' "•*<*-• *?< ***• -
STA*30*20G»59~
REF*C3*02
< information that is non-classified, associated with an imcontroUedcar
estimated emission of an average of 200 parts per million; me estimate
material balance using engineering knowledge of theprocess>vsJ*-
.* «, M "&•* ^ jt+^.A
~ • - - ». •"• ft"
* *•
5. Segment Example: * r * ȣ *^
HL*40*20*9*0~ ^ ,, ,
< fortieth HL loop is subordinate tametwentksth HlJocp^^
HL loop contains,-"-•—'**--*—-*'—*2-^-ii-£-i~-—*m^-^-^a^x:
Data Element Summary
Data
Element Name Attributes
628 Hierarchical ID Number M AN 1/12
A unique number assigned by the sender to identify a particular data segment
in a hierarchical structure
1.;
HLjoL_ . _.
734 Hierarchical Parent ID Number O AN 1/12
Identification number of the next higher hierarchical data segment that the data
segment being described is subordinate to
735
736
Hierarchical Level Code M ID 1/2
Code defining the characteristic of a level in a hierarchical structure
Line Detail
Code identifying the supporting detail associated with
the charge or group
Hierarchical Child Code O ID
Code indicating whether if there are hierarchical child data segments
subordinate to the level being described
0 No Subordinate HL Segment in This Hierarchical
Structure ""
124
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Hierarchical Level
635
HL
Detail
Mandatory
1
To identify dependencies among and the content of hierarchically related groups of data
segments
1 The HL segment is used to identify levels of detail information using a hierarchical
structure, such as relating line-item data to shipment data, and packaging data to
line-item data.
2 HL01 shall contain a unique alphanumeric number for each occurrence of the HL
segment in the transaction set. For example, HL01 could be used to indicate the
number of occurrences of the HL segment, in which case the value of HL01 would
be " 1" for the initial HL segment and would be incremented by one in each
subsequent HL segment within the transaction.
3 HL02 identifies the hierarchical ID number of the HL segment to which the current
HL segment is subordinate.
4 HL03 indicates the context of the series of segments following the current HL
segment up to the next occurrence of an HL segment in the transaction. For example,
HL03 is used to indicate that subsequent segments in the HL loop form a logical
grouping of data referring to shipment, order, or item-level information.
5 HL04 indicates whether or not there are subordinate (or child) HL segments related
to the current HL segment.
TMD**EPnrr^
Emission Inventory Improvement Program
for each: Chemical Abstract §ei*ipe (GAS>
"
3. TWs note pertains to BICX5ENIC
4. Loop (segments
123
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
JxJKjJr Reference Identification
597
STA
Detail
Optional
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
2. This segment
schedule specified in 60
3. Segment
< adjustment factt^
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
M
Attributes
M ID 2/3
Schedule Reference Number
Identifies a number for a program schedule (for
example, a logic type of network) or working schedule
to complete a specific task or set of tasks
REF02
REF03
127
352
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
01
02
03
04
05
06
Description
Ozone Season
Peak Ozone Season
CO Season
Peak CO Season
Paniculate Matter Season
Modeling Episode
X AN 1/80
A free-form description to clarify the related data elements and their content
t/Tffifi
122
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
DTM06 1250 Date Time Period Format Qualifier X ID 2/3
Code indicating the date format, time format, or date and time format
UN Unstructured
DTM07 1251 Date Time Period X AN 1/35
Expression of a date, a time, or range of dates, times or dates and times
1. Tii&eIiOTetii$o^i^l^
: ' -'> "**~~"?/^;*i^ i,-~^r",'V^* ' '•'""'" ° "* *~- '• ( ''•' '
2. Tills eI^«atMint8uaiw6yaftie associated with DTMOl code "239". Select >
the code ajrrespondjDg to the typical day of flic week being reported ftom the -
_ ••'- '. ^•:-^:rf:Tr«'-X^i,-*£:-Jr'f,f>K'«*' ••-*': t';... - -^ -i
01
02
03
04
05
06
07
Emission Inventory Improvement Program
121
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
» DTM01
DTM02
LJ 1 JV1 Date/Time Reference
595
STA
Detail
Optional
To specify pertinent dates and times
1 If either DTM06 or DTM07 is present, then the other is required.
2 At least one of DTM02 DTM03 or DTM06 is required.
eefimia&and end dates for
Data Element Summary
Data
Element Name Attributes
374 Date/Time Qualifier M ID 3/3
Code specifying type of date or time, or both date and time
fit
373
196
197
239
Date
Date (YYMMDD)
IT
Start
End
Baseline
The baseline or original plan that progress is measured
against ^
3!3Si3£&£9@HBI9H!l^liflBBMB&BBMH5Etf3BH
fejnmjEB^iMB^^BBm^HHgmmBMH
¥TJ*iaiTm^fiifflV''lTillrianT%Vi1
X Df" 6/6'
120
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Des.
STA01
STA02
STA03
C00101
COO104
COO105
Element Name Attributes
950 Statistic Code M ID 2/2
A code specifying the specific statistic being reported
1. When code "ZZ" is applied m STAOl, COOI01 miSt fjeTl1*?^: '
2. This element indicates the type of measurement being reported with this
iteration of die tooguSelecfcone from the following list:
30 Average
ZZ Mutually Defined
Indicates
739
Measurement Value
The value of the measurement
•J^ST^T*;
"iVs'fSSi^^P^mw
1/20
I,-':
^-"^r^isfe^.
O
C001 Composite Unit of Measure
To identify a composite unit of measure (See Figures Appendix for examples
of use)
l.'Thisconipo
355
Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
e j
DA
HR
PI
WK
Days
Hours
Percent
Week
355
2/2
Unit or Basis for Measurement Code O ID
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
DA Days
HR Hours
YR Years
1018 Exponent
Power to which a unit is raised
O R
1/15
i the unit ofmeasunr associated
Emission Inventory Improvement Program
119
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
STA
Statistics
593
STA
Detail
Optional
1
To provide summary statistics related to a specific collection of test result values
I. This loop/segment doeihot
2. Thi&loop
- activity (throughp«t)5 sclie^«KlpDtf
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
DTM01
DTM02
DTM03
DTM05
U 1 JV1 Date/Time Reference
585
MEA
Detail
Optional
>1
To specify pertinent dates and times
1 If either DTM06 or DTM07 is present, then the other is required.
2 At least one of DTM02 DTM03 or DTM06 is required.
1.
mi
-j-.y^-y. —-.t-Ta.........JiMHl en^da^ancftimes associated with me'
Data Element Summary
Data
Element Name Attributes
374 Date/Time Qualifier M ID 3/3
Code specifying type of date or time, or both date and time
196 Start
197 End
373 Date
Date (YYMMDD)
COT
DT 6/6
„ JalL.fi
X TM 4/8
337 Time
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or
HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-
59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds
are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
624 Century O NO 2/2
The first two characters in the designation of the year (CCYY)
tliiiiiHrcif^^ the"P"
« >. >£*i "iS-ift."- '-"-^Ji^.ifj'iLjt ,*_ '. ^'""J^ *„ «.. '_^JW: . - . "_ <^ *
^«T3 ''K-' •»<.'••>• • .--r- '»
Emission Inventory Improvement Program
117
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
C00107
355
C00108
1018
MEA05
MEA06
740
741
per second), apply the exponent of "-1" as per the example noted in MEA04.
Unit or Basis for Measurement Code O ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
I/This element contaim me second unit in the complex unit of measure
expression associated with MBACS.^ ^2 : ;> - „-•. _ _;" . /..,_.;
03 Seconds
Exponent O R 1/15
Power to which a unit is raised
1. This element cbntams the^xpOT
complex expression ftatniay be required as me unit of measure associated . r
1
Range Minimum X
The value specifying the minimum of the measurement range
Range Maximum X
The value specifying the maximum of the measurement range
1/20
1/20
116
Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
MEA03
MEA04
C00101
C00102
C00104
C00105
BR
R7
RA
TC
ZZZ
Brightness
Indicates visible radiatioa
Speed
Six1 »-in?, •»..' ~" t JS»
Relative Humidity
Temperature
Mutually Defined
• „-
X R 1/20
'witft the code specified in' .
739 Measurement Value
The value of the measurement
t . , Tfi^>
C001 Composite Unit of Measure X
To identify a composite unit of measure (See Figures Appendix for examples
of use)
2..Unit»$5on«^^
manner similar to the;"fonmm^ae^tU^^a^aalK per hour per meter perp
355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
Centigrade, Celsius
MOL
Fahrenheit
Miles Per Hour
Percent
Power to which a unit is raised
O R 1/15
the unit of measure associated *
iastf^iy
square miles per hour per ineter
:£K anmpi|ii(^iFui M^04,>^
355 Unit or Basis for Measurement Code O ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
MR Meter
1018 Exponent
Power to which a unit is raised
I. This element c
O R 1/15
inKtbefotmuIatiottofthe
2. When atrorying a complex expression (e.g., square miles per 1
Emission Inventory Improvement Program
^^
115
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
DCS.
MEA01
MEA02
IVJ.Ji<.A Measurements
583
MEA
Detail
Optional
1
To specify physical measurements or counts, including dimensions, tolerances, variances,
and weights (See Figures Appendix for example of use of COO 1)
If MEA05 is present, then MEA04 is required.
If MEA06 is present, then MEA04 is required.
Only one of MEA08 or MEA03 may be present.
If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
At least one of MEA03 MEA05 MEA06 or MEA08 is required.
MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
ThisJfcwp provides meteorological1
«
2. This segment
Data Element Summary
'Data
Element Name
737 Measurement Reference ID Code
Attributes
O ID 2/2
Code identifying the broad category to which a measurement applies
738
Environmental Conditions
The data values to be reported reflect the environmental
conditions surrounding a situation including but not
limited to test environments
Measurement Qualifier O ID 1/3
Code identifying a specific product or process characteristic to which a
measurement applies
I.
« « » •'• "-~ ' T
this iteration
. .,-
conel
Ambient Temperature
udlc^^ diurnal temperature
. ^WB,<-*_, -. 1,-^i.-. ,iJLA.m$ix:
114
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Ref.
Des.
CID03
C1D04
< a diurnal temperature change of 25 degrees Fahrenheit recorded for thettme period ?
starting January 1,95 and ending December 31, 95; a seasonal activity (throughput) *-,v
adjustment factor of 15 percent reported for the time period starting January l,95and :;.
ending March 31,95; a seasonal activity (throughput) adjustment factor of 60 percent g
repotted: for me time period starting April 1» 95 and ending June 30,J5j'alseasonaP*7-"^
activity (throughput) adjustment factor of 15 percent reported for the time period starting^«
July 1,95and ending September 30,,95; a seasonal activity (throughput) adjustment -: *$
r* _, £ * ** * . 1; ' * "&~ **r _ hi.4 '. • *• * «••'.* ^ ***. L•_ t_'_ .«. f*^ •** '*• _«>i,- "••^ '''.' '•, ^ »
factor of
< meteorological data
• ^V^J*" »'"
dD***EP*
< a seasonal
Data Element Summary
Data
Element Name
559 Agency Qualifier Code
Code identifying the agency assigning the code values
Attributes
X ID 2/2
EP United States Environmental Protection Agency (EPA)
751 Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
A
M
S
Seasonal Activity (Throughput) Adjustment Factor
Meteorological
Activity (Throughput) Schedule
Emission Inventory Improvement Program
113
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
CID
Characteristic/Class ID
567
CID
Detail
Optional
1
To specify the general class or specific characteristic upon which test results are being
reported or are to be taken
1 If CID06 is present, then both CID03 and CID04 are required.
2 If CID07 is present, then at least one of CID04 or CID05 is required.
3 If either CID03 or CID04 is present, then the other is required.
4 At least one of CIDO1 CID02 CID04 or CID05 is required.
1 CID06 specifies the individual code list of the agency specified in CID03.
2 CID07 refers to whether or not the characteristic identified in CID04 or CID05 or
both is affected by the product change. If it is affected, the value is "Y". A value of
"N" is used when it is known that it will not be affected. Any other value indicates it
is indeterminate.
Notes: 1. This loop
- activity (throughput]
- seasonal
- meteorological*
- typical dayi
- activity (1
*H *' **
2. This note pel
only.
(throughput)
f-W3
3^ fe."%fBAA. ^ <
S£-M4r*S**lf K,A*S Al
REF*72*06~
112
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
HAND
IAD
ICT
IINF
IINK
INOC
INPT
IOPP
LEAK
LIQF
LOAD
MELT
MILL
MINE
MIX
OPRG
PICK
PLAT
PRDT
PROC
PROD
PRODCAP
PUMP
RECD
REDU
REMD
ROAS
SAW
SHIP
SHPRCD
SMOK
SPUN
STOR
STRP
TFRD
THRU
TPRT
TRAV
TRTD
UNLD
USED
Handled
In Adhesive Applied
In Coating
In Influent
In Ink
Inoculated
Input
In Operation
Leaked
Liquified
Loaded
Melted
Milled
Mined
Mixed
Operating
Pickled
Plated
Product
Processed
Produced
Production Capacity
Pumped
Received
Reduced
Removed
Roasted
Sawed
Shipped
Shipped or Received
Smoked
Spun
Storage
Stripped
Transferred
Throughput
Transported
Traveled
Treated
Unloaded
Used
Emission Inventory Improvement Program
111
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
REF04
C04001
C040
128
REF04 C04002 lack an appropriate code, this element contains an activity
(throughput) description. This description most include the identification, of
both a product and a process. „ _., , ^. JV~^"\V:.V£liUjr ,, J
Reference Identifier O
To identify one or more reference numbers or identification numbers as
specified by the Reference Qualifier
L When REFOt is "PG", this composite provides an activity process. '?*~~
2.
an appro
in conjunction with REF01 code "PG" and* |
alpha-numeric code HI order to identify an activity:
•^^^"^«^";:^^^^a^^tf«^4;^^: v£ , •
>,- X 5. <**-*•'< 3 .it. ti»»^w>*****i..'.-•»*»&•-*!*'-, -i =5f t ,-,.../S* • Vf,
Reference Identification Qualifier
Code qualifying the Reference Identification
C04002
127
SU Special Processing Code
Unique code identifying the special handling
requirements for the claim
Indicate&i
• j--iAt&S3ht3et*n.-
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
STRCH Starch
STYR Styrene
SULF Sulfer 100%
SULFAC Sulfuric Acid
SUMP Sump
SURF Surface
TCBZN 1,2,4-Trichlorobenzene
TCELN Trichloroethylene
TCELNFR Trichloroethylene Fresh
TCEN 1,1,1-Trichlorothane
TDI TDI
TETHLD Tetraethyl Lead
TIRE Tires
TNT TNT
TOLN Toluene
TONE Toner
TOPSL Topsoil
TPLCAC Terephthalic Acid Crude
TRCKHL Trucks Haul
UREA Urea
VAC Vacuum
VEHCL Vehicles Light/Medium
VNLC Vinyl Chloride
VNLCM Vinyl Chloride Monomer
VNLDC Vinyldiene Chloride
WATCO Water Cooling
WAX Wax
WFR Wafers/Chips
WFRBRD Waferboard
WOOD Wood
WOODDF Wood Dry Flakes
WOODDR Wood Dried
WSTE Waste
WSTWTR Wastewater
XLN Xylene(s)
XLNM m-Xylene
XLNO o-Xylene
XLNT Xylene(s) Total
ZINC Zinc
ZINCOX Zinc Oxide
REF03 352 Description X AN 1/80
A free-form description to clarify the related data elements and their content
2. V^'JREj&lb^
Emission Inventory Improvement Program 109
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
POLY Polymer
POM POM
PROD Product
PRODDR Product Dry
PRODFN Product Finished
PRODSA Product Surface Area
PRPLYN Propylene
PULP Pulp
PULPADB Pulp Air-Dried Bleached
PULPADU Pulp Air-Dried Unbleached
RAYN Rayon
REF Refinery
RESD Residues/Skimmings
RESN Resin
RESNPA Resin Polyester/Alkyd
RESNTN Resin Thinned
ROCK Rock
SALT Salt
SAND Sand
SAWDST Sawdust
SBR SBR
SCMNGS Silicomanganese
SCRP Scrap
SCRPRS Scrapers
SEAL Seals
SHOT Shot
SINT Sinter
SLAG ^ Slag
SLBLKL Solids Black Liquor
SLDG Sludge
SLDGDR Sludge Dried
SOLNCT Solution Coating
SOLNFRM Solution 37% Formaldehyde
SOLV Solvent
SOLVCT Solvent Coating
SOLVFR Solvent Fresh
SOLVIN Solvent in Ink
SOLVMU Solvent Make-Up
SOLVRC Solvent Reclaimed
SOLVTN Solvent Thinned
SOUR Sour Gas
STEL Steel
STELSP Steel Specialty
STM Steam
STON Stone
STOR Storage
108
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
MEAT
MERC
METL
METLHT
METLSPR
MLCAHD
MTHCFRM
MTHCHL
MTHCLFR
NAPT
NEOP
NICK
NITELST
NTRBZN
OCRSL
OIL
ORE
OREGON
OVRBUR
P205
PAINT
PAPR
PCB
PCE
PCECC
PCETCE
PCETH
PCETHFR
PCPHNL
PELLT
PEST
PHNL
PHSGN
PHSPH
PHSPHRK
PHSPRS
PIGIRN
PIGMNT
PILE
PIPE
PIPECST
PLCANHD
PLSTC
PLYWD38
PM
POLVNL
Meat
Mercury
Metal
Metal Hot
Metal Sprayed
Meleic Anhydride
Methyl Chloroform
Methylene Chloride
Methylene Chloride Fresh
Naphthalene
Neoprene
Nickel
Nitrile Elastomer
Nitrobenzene
0-Cresol
Oil
Ore
Ore Concentrated
Overburden
P205
Paint
Paper
PCB
PCE
PCE&CC14
PCE & TCE
Perchloroethlyene
Perchloroethylene Fresh
Pentachloropheno I
Pellets
Pesticide
Phenol
Phosgene
Phosphate
Phosphate Rock
Phosphorous
Pig Iron
Pigment
Pile
Pipe
Pipe Cast
Phthalic Anhydride
Plastic
Plywood 3/8 inch
PM
Polyvinyl
Emission Inventory Improvement Program
107
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
FDNHCO
FEED
FEEDDR
FEEDFR
FEEDMT
FELTST
PERT
FIBR
FISH
FISHML
FISHRW
FISHSC
FLC1112
FLC22
FLSP
FORM
FORM37
FRMGS
FRSH
FUEL
GAS
GLSS
GLSSBD
GLYET
GRAD
GRIT
CRN
GYPCR
HAMB
HCL
HEATIN
HXCBNZ
HYC
INK
IRON
LAB
LEAD
LEADOX
LIME
LIMHYD
LIMSTN
LOG
MAIL
MATLRW
MCBNZ
MEAL
Feed NaHCO3 Dry
Feed
Feed Dry
Feed Fresh
Feed Material
Felt Saturated
Fertilizer
Fiber
Fish
Fish Meal
Fish Raw
Fish Scrap
Fluorocarbon 11/12
Fluorocarbon 22
Fluorspar
Formaldehyde
37% Formaldehyde
Ferromanganese
Fresh
Fuel
Gas
Glass
Glass Beaded
Glycol Ethers
Graders
Grit
Grain
Gypsum Crude
Hamburger
Hydrochloric Acid
Heat Input
Hexachlorobenzene
Hydrocarbons Total
Ink
Iron
LAB
Lead
Lead Oxide
Lime
Lime Hydrated
Limestone
Logs
Material
Material Raw
Monochlorobenzene
Meal
106
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
CLNK
CLOT
COAL
COALSTG
COAT
COKE
COKEFR
COKERW
CON
COPLY
CORE
COREOL
COTT
COW
CTET
CU
CULL
CUM
CURR
CUSC
DBZF
DCB
DCE
DIST
DMF
DMTP
DRAN
DRUM
EAFDT
EDC
EDCVC
ELEC
ELECRD
ENER
EPCH
ETCSOL
ETH
ETHBNZ
ETHBST
ETHCL
ETHDB
ETHDC
ETHOX
EXP
EXTFC
FABR
Clinker
Clothes
Coal
Coal Storage
Coating
Coke
Coke Free
Coke Raw
Concrete
Copolymer
Cores
Core Oil
Cotton
Cattle
Carbon Tetrachloride
Copper
Gullet
Cumene
Current
Copper Scrap
Dibenzofuran
1,4-Dichlorobenzene
1,2-Dichloroethane
Distance
DMF
Dimethyl Terephthalate
Drains
Drums
EAF Dust
EDC
EDC-VC
Electricity
Electrode
Energy
Epichlorohydrin
Etching Solution
Ethylene
Ethylbenzene
Ethylbenzene/Styrene
Ethyl Chloride
Ethylene Dibromide
Ethylene Dichloride
Ethylene Oxide
Exposed
Extractor Feed Cake
Fabric
Emission Inventory Improvement Program
105
-------
PROTOTYPE 841 CONVENT/ON DOCUMENT
02/97
ACRNL
ACROL
ADH
ADN
ADPN
AGNT
ALLY
ALMA
ALMO
AMM
ANILN
ASB
ASP
ASPSL
BATT
BAUX
BEAN
BEANGR
BEETRW
BNZN
BOD
BORD
BRED
BRIK
BUTDN
BUTDN13
CAD
CAN
CAPLM
CAR
CARTOT
CAST
CATL
CBLK
CC14
CEM
CFC133
CHAR
CHRMORE
CHXN
CIG
CL
CLAY
CLBNZ
CLFRM
CLMET
Acrylonitrile
Acrolein
Adhesive
ADN
Adipronitrile
Agent
Alloy
Alumina
Aluminum Molten
Ammonia
Aniline
Asbestos
Asphalt
Asphalt Shingle
Batteries
Bauxite
Beans
Beans Green
Beets Raw
Benzene
Bodies
Board
Bread
Brick
Butadiene
1,3-Butadiene
Cadmium
Cans
Caprolactam
Car(s)
Cargo Total
Castings
Catalyst
Carbon Black
CC14
Cement
CFC-133
Charcoal
Chromite Ore
Cyclohexene
Cigarettes
Chlorine
Clay
Chlorobenzene(s)
Chloroform
Chloromethane(s)
104
Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
IX
Item Number
Indicates a throoghput method code ~"
1. This code appBeswHh POINT SOURCE reporting
PG
Product Group
Indicate* an activity product
must afco be
,1
I
REF02 127 Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
L" -a***.,*.****. **~—
- .a^t^^^^fc^A^-ss^Wt,*^,^.^^^
appropriate method code :•
4, Wiai>__
, • .4SP!i5"<*'
value.*
"oT*
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
ABR
ABSP
ACEAL
ACID
ACIDFN
ACIDPR
Calculated based on physical principles
Estimated based on expert judgment
Calculated based on manufacturer-specified throughput
capacity
Calculated based on direct continuous measurement of
an activity surrogate
Calculated based on direct intermittent measurement of
an activity
New construction, not yet operational. Emissions are
zero.
Operations ceased. Emissions are zero.
Calculated based on modeling activity
Derived from Highway Performance Monitoring
System (HPMS) data
Derived from census data
Derived from trade association/industry group data
State agency generated data
Local agency generated data
Federal agency generated data
Proprietary database
Based on survey results
Calculated based on statistical method
Abrasive
ABS Polymer
Acetaldehyde
Acid
Acid Final
Acid Pure
Emission Inventory Improvement Program
103
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
IX FJ r Reference Identification
553
LX
Detail
Optional
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
-, --i__-^*
1. TTiiS
Data Element Summary
Ref. Data
Des. Element Name
REF01 128 Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
iteration of the loop.; S
DO Data Reliability Code
102
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des,
DTM01
DTM02
DTM03
DTM05
\J 1 JVl Date/Time Reference
551
LX
Detail
Optional
To specify pertinent dates and times
1 If either DTM06 or DTM07 is present, then the other is required.
2 At least one of DTM02 DTM03 or DTM06 is required.
Data Element Summary
Data
Element Name Attributes
374 Date/Time Qualifier M ID 3/3
Code specifying type of date or time, or both date and time
373
337
196 Start
197 End
Date
Date (YYMMDD)
X DT 6/6
Time X TM 4/8
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or
HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-
59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds
are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
624
Century
The first two characters in the designation of the year (CCYY)
Emission Inventory Improvement Program
101
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
C00105
C00107
C00108
MEA06
which a measurement has been taken
1. This element contains the second unit in me complex unit of nieasure *
expression associated with MEA03. Select one from me following list:
HR " Hours " " " " """"
MR Meter
YR Years
1018 Exponent O R 1/15
Power to which a unit is raised
1. This element contains
complex expression
hour per
Sfi^^flSK3
355 Unit or Basis for Measurement Code O ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
1,
w1thMEAa3.-S.lcctWfro
03 Seconds
1018 Exponent
Power to which a unit is raised
I*>
***<*•
complex
O R 1/15
741 Range Maximum
The value specifying the maximum of the measurement range
1/20
100
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
C00102
1018
C00103
FT
GA
GE
HJ
HM
HQ
HR
IE
IN
K7
Power to which a unit is raised
Foot
Gallon
Pounds per Gallon
Horsepower
Miles Per Hour
Hectare
Hours
Person
Inch
Kilowatt
Measure of electrical power
Kilogram
100 Kilograms
Pound
Liter
Minutes
Millimeter
Meter
Parts Per Thousand
Percent
Square Mile
Square Foot
Thousand Gallons
Thousand
Thousand Feet (Board)
Net Ton (2,000 LB).
Thousand Feet
Thousand Square Feet
Thousand Cubic Feet
Head
O
1/15
hX-H*^"' j«4--,^i1 , v*-'^*'^1^^^*'-^*™^^^^" •'«?<''"'"*\*r^ ' - ""*'- "* » ,
-•;*. ~../r --;
O R 1/10
649 Multiplier
Value to be used as a multiplier to obtain a new value
; formulation of the
COO104
;ion (e.g., square kilometers per hour per
1 as pejEAeexampIe noted ittMEA04.
355 Unit or Basis for Measurement Code O ID 2/2
Code specifying the units in which a value is being expressed, or manner in
Emission Inventory Improvement Program
99
-------
PROTOTYPE 84 1 CONVENTION DOCUMENT 02/37
manner similar to the fbllowing,example:
second = *DK;2::HR:-l::03:-l* ,; •{'-;-'":V.'> --^-^
» C00101 355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
1." This elementVontains tlk'fir&ra»i£^^
expression associated wi&ME^flf !};SeJ^ wig "'
1A "" ....... Car Mile' *""" ""*"
One freight car moving one mile
21 British Thermal Units (BTUs) Per Hour
British thermal units per hour
2L Cubic Feet Per Minute
Rate of flow
2U Megagram
Unit of mass
41 Meters Per Second
Measure of linear speed
4U Pounds Per Hour
Rate of flow
4W Ton Per Hour
Rate of flow
68 Ampere
86 Joules
AC Acre
BA Bale
BQ Brake horse power
Quantity of product ordered for shipment but not
available so a replenishment stock has been ordered
BR Barrel
BU 'Bushel
BZ Million BTU's
CE Centigrade, Celsius
CF Cubic Feet
CH Container
CM Centimeter
CY Cubic Yard
DA Days
DH Miles
DK Kilometers
DR Drum
EA Each
F5 MOL
FA Fahrenheit
FC 1000 Cubic Feet
FM Million Cubic Feet
FS Feet Per Second
Measure of linear speed
98 Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
MEA01
MEA03
MEA04
Measurements
545
LX
Detail
Mandatory
To specify physical measurements or counts, including dimensions, tolerances, variances,
and weights (See Figures Appendix for example of use of COO 1)
1 If MEA05 is present, then MEA04 is required.
2 If MEA06 is present, then MEA04 is required.
3 Only one of MEA08 or MEA03 may be present.
4 If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
5 At least one of MEA03 MEA05 MEA06 or MEA08 is required.
1 MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
I When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
L This segment does nc^ar^ry with BIOGEWCSOUI
2. This segment provides individual
activity (throughput) specified in the REF segment (fo
'''^
3. This segment inay only be applied one
- rvtf£Te, x , n.%"'!*1"'*" • >^**Hfc4AA^^Vs»«t3iB#''1
*KJt#*«&*iMiK3wl^tat*i+li^ 'I
Composite Unit of Measure X
To identify a composite unit of measure (See Figures Appendix for examples
of use)
l.TTus composite pnivictememit of measure assw
ma
Emission Inventory Improvement Program
97
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
LX01
Assigned Number
539
LX
Detail
Optional
1
To reference a line number in a transaction set
I . . This loop/segment does not
«•-•.-. ., . '"t ~, ' ,'Mt^-A.i:
2.
- DARS quality rating score associ
j ••««. -•*— • y T*. " * TT"% ''.rL *, j^^., #&i
tmethod code•__
- activhy (throughput) identi
' -V? x ' ''"i .{'l-'ij^
3. This segment is an X12 syn
Loop (segments LX, ME&
Data Element Summary
Data
Element Name Attributes
554 Assigned Number M NO 1/6
Number assigned for differentiation within a transaction set
96
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
SPI01
>JA L Specification Identifier
481
SPI
Detail
Optional
1
To provide a description of the included specification or technical data items
1 If either SPI02 or SPI03 is present, then the other is required.
Data Element Summary
Data
Element Name Attributes
786 Security Level Code M ID 2/2
Code indicating the level of confidentiality assigned by the sender to the
information following
~ " "" "" " OK'-&!m£naK*mrf?-
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
HL03
735
1. This note pertains to POINT, AREA, abifNONROAD SOURCE only. This 1
element indicates that this level of the transaction set points to the HL loop ':-.'. |
parent containing the HL03 code "6" for process-level data./ , y~; 1
- , / •-'',-."^r<- < /^- "-•'-'* /'•"• *'"'^'•&*•,*- " -^T^-'v:'^-''''"-"""''!""'- ••*~~ "~~ 1
2. This note periaiiBteMOBnJE and B^ ; 1
element indicates that mis level of the transaction set points to the HL loop
parent containing rae HL03,code-*5" forpfiyi^l-level,daKkfj;.'.^, ^ ;;. •
Hierarchical Level Code M ID 1/2
Code defining the characteristic of a level in a hierarchical structure
Date
HL04 736 Hierarchical Child Code O ID 1/1
Code indicating whether if there are hierarchical child data segments
subordinate to the level being described
1. ThisHEloop/Ieverniay^
0
1
No Subordinate HL Segment in This Hierarchical
Structure
Additional Subordinate HL Data Segment in This
Hierarchical Structure
94
Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
MEA*TR**100e*TN;::YR:.I~ 1
~
Ref.
DCS.
HL01
HL02
cm***Ep*A«*gmiii
STA*ZZ*B*
DTM?19«*
DTM*l9i*9
REE*f2,-,
< mformation that fc:n
activity (thtoughput>
foe the time period
Data Element Summary
Data
Element Name Attributes
628 Hierarchical ID Number M AN 1/12
A unique number assigned by the sender to identify a particular data segment
in a hierarchical structure
734
A unique number assigned by the sender to ide
in a hierarchical structure
I""-""-iif-*.*•* *»«>—-t-^ *.--;-~<^"""«yr<^»wav"yg--r*-y.y«-y^ar^ *~3.-—
I. T"«?^'gm^^grwtam^ A"ttf^ignTii^t%ftrii!gef
Hierarchical Parent ID Number
iinKa- used to kfentiry the IteratioQ of an
. _' '„ ja,-. - * -
O AN 1/12
Identification number of the next higher hierarchical data segment that the data
segment being described is subordinate to
Emission Inventory Improvement Program
93
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
JtlJ-j Hierarchical Level
477
HL
Detail
Mandatory
I
To identify dependencies among and the content of hierarchically related groups of data
segments
The HL segment is used to identify levels of detail information using a hierarchical
structure, such as relating line-item data to shipment data, and packaging data to
line-item data.
HL01 shall contain a unique alphanumeric number for each occurrence of the HL
segment in the transaction set. For example, HL01 could be used to indicate the
number of occurrences of the HL segment, in which case the value of HL01 would
be " 1" for the initial HL segment and would be incremented by one in each
subsequent HL segment within the transaction.
HL02 identifies the hierarchical ID number of the HL segment to which the current
HL segment is subordinate.
HL03 indicates the context of the series of segments following the current HL
segment up to the next occurrence of an HL segment in the transaction. For example,
HL03 is used to indicate that subsequent segments in the HL loop form a logical
grouping of data referring to shipment, order, or item-level information.
HL04 indicates whether or not there are subordinate (or child) HL segments related
to the current HL segment.
1.
. confidentia
-activity;
-D.
- throughput
must be associated with an appi
4. Loop (segments HL
REF) Example
LX*20~
92
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
PROD
PRODCAP
PUMP
RECD
REDU
REMD
ROAS
SAW
SHIP
SHPRCD
SMOK
SPUN
STOR
STRP
TFRD
THRU
TPRT
TRAV
TRTD
UNLD
USED
Produced
Production Capacity
Pumped
Received
Reduced
Removed
Roasted
Sawed
Shipped
Shipped or Received
Smoked
Spun
Storage
Stripped
Transferred
Throughput
Transported
Traveled
Treated
Unloaded
Used
Emission Inventory Improvement Program
91
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
1. "This element contains a code associated w^C0400lf Select one from the
..... ' " "*"' * '"" '
. _
Added
Applied
Area
Baked
Blown
Burned
Capacity
Cast
Charbroiled
Charge(d)
Cleaned
Coated
Consumed
Crushed
Degreased
Drilled
Dried
Emitted
Fed into Dryer
Feed
Ginned
Granulated
Handled
In Adhesive Applied
, In Coating
In Influent
In Ink
Inoculated
Input
In Operation
Leaked
Liquified
Loaded
Melted
Milled
Mined
Mixed
Operating
Pickled
Plated
Product
Processed
ADD
APPL
AREA
BAKE
BLOW
BURN
CAP
CAST
CHAR
CHRG
CLND
COAT
CONS
CRSH
DGRS
DRIL
DRY
EMIT
FEDD
FEED
GIN
GRAN
HAND
IAD
ICT
IINF
IINK
INOC
INPT
IOPP
LEAK
LIQF
LOAD
MELT
MILL
MINE
MIX
OPRG
PICK
PLAT
PRDT
PROC
90
Emission Inventory Improvement Program
-------
02/57
PROTOTYPE 841 CONVENT/ON DOCUMENT
REF03
REF04
C04001
C04002
352
C040
128
127
VAC
VEHCL
VNLC
VNLCM
VNLDC
WATCO
WAX
WFR
WFRBRD
WOOD
WOODDF
WOODDR
WSTE
WSTWTR
XLN
XLNM
XLNO
XLNT
ZINC
ZINCOX
Description
Vacuum
Vehicles Light/Medium
Vinyl Chloride
Vinyl Chloride Monomer
Vinyldiene Chloride
Water Cooling
Wax
Wafers/Chips
Waferboard
Wood
Wood Dry Flakes
Wood Dried
Waste
Wastewater
Xylene(s)
m-Xylene
o-Xylene
Xylene(s) Total
Zinc
Zinc Oxide
AN 1/80
A free-form description to clarify the related data elements and their content
__ ^Sweiiaini^ctia^^
flier" ~" "~ ' "f "' " ':" ""••-•"*"•• •••
Reference Identifier O
To identify one or more reference numbers or identification numbers as
specified by the Reference Qualifier
iff order to identify an activity
.,„•« ^.f,, „,-,<. •-<,•*•:, , ... *."
*B as tftc^ woul&oe iwtside tife:
Reference Identification Qualifier ft
Code qualifying the Reference Identification
I. Tjj&eflie^lW^ '^"^r^-^r^"
SU Special Processing Code
Unique code identifying the special handling
requirements for the claim
Indicates a process activity '•'"''. ""'/•'
Reference Identification M AN
ID 2/3
Emission Inventory Improvement Program
1/30
89
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
SBR SBR
SCMNGS Silicomanganese
SCRP Scrap
SCRPRS Scrapers
SEAL Seals
SHOT Shot
SINT Sinter
SLAG Slag
SLBLKL Solids Black Liquor
SLDG Sludge
SLDGDR Sludge Dried
SOLNCT Solution Coating
SOLNFRM Solution 37% Formaldehyde
SOLV Solvent
SOLVCT Solvent Coating
SOLVFR Solvent Fresh
SOLVIN Solvent in Ink
SOLVMU Solvent Make-Up
SOLVRC Solvent Reclaimed
SOLVTN Solvent Thinned
SOUR Sour Gas
STEL Steel
STELSP Steel Specialty
STM Steam
STON Stone
STOR Storage
STRCH Starch
STYR Styrene
SULF ' SulferlOO%
SULFAC Sulfuric Acid
SUMP Sump
SURF Surface
TCBZN 1,2,4-Trichlorobenzene
TCELN Trichloroethylene
TCELNFR Trichloroethylene Fresh
TCEN 1,1,1-Trichlorothane
TDI TDI
TETHLD Tetraethyl Lead
TIRE Tires
TNT TNT
TOLN Toluene
TONE Toner
TOPSL Topsoil
TPLCAC Terephthalic Acid Crude
TRCKHL Trucks Haul
UREA Urea
88
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
PAINT Paint
PAPR Paper
PCB PCB
PCE PCE
PCECC PCE&CC14
PCETCE PCE & TCE
PCETH Perchtoroethlyene
PCETHFR Perchloroethylene Fresh
PCPHNL Pentachlorophenol
PELLT Pellets
PEST Pesticide
PHNL Phenol
PHSGN Phosgene
PHSPH Phosphate
PHSPHRK Phosphate Rock
PHSPRS Phosphorous
PIGIRN Pig Iron
PIGMNT Pigment
PILE Pile
PIPE Pipe
PIPECST Pipe Cast
PLCANHD Phthalic Anhydride
PLSTC Plastic
PLYWD38 Plywood 3/8 inch
PM PM
POLVNL Polyvinyl
POLY Polymer
POM POM
PROD Product
PRODDR Product Dry
PRODFN Product Finished
PRODSA Product Surface Area
PRPLYN Propylene
PULP Pulp
PULPADB Pulp Air-Dried Bleached
PULPADU Pulp Air-Dried Unbleached
RAYN Rayon
REF Refinery
RESD Residues/Skimmings
RESN Resin
RESNPA Resin Polyester/Alkyd
RESNTN Resin Thinned
ROCK Rock
SALT Salt
SAND Sand
SAWDST Sawdust
Emission Inventory Improvement Program
87
-------
PRO TC 'PE 841 CONVENTION DOCUMENT
02/97
GAS
GLSS
GLSSBD
GLYET
GRAD
GRIT
CRN
GYPCR
HAMB
HCL
HEATIN
HXCBNZ
HYC
INK
IRON
LAB
LEAD
LEADOX
LIME
LIMHYD
LIMSTN
LOG
MATL
MATLRW
MCBNZ
MEAL
MEAT
MERC
METL
METLHT
METLSPR
MLCAHD
MTHCFRM
MTHCHL
MTHCLFR
NAPT
NEOP
NICK
NITELST
NTRBZN
OCRSL
OIL
ORE
OREGON
OVRBUR
P205
Gas
Glass
Glass Beaded
Glycol Ethers
Graders
Grit
Grain
Gypsum Crude
Hamburger
Hydrochloric Acid
Heat Input
Hexachlorobenzene
Hydrocarbons Total
Ink
Iron
LAB
Lead
Lead Oxide
Lime
Lime Hydrated
Limestone
Logs
Material
Material Raw
Monochlorobenzene
Meat
Meat
Mercury
Metal
Metal Hot
Metal Sprayed
Meleic Anhydride
Methyl Chloroform
Methylene Chloride
Methylene Chloride Fresh
Naphthalene
Neoprene
Nickel
Nitrile Elastomer
Nitrobenzene
0-Cresol
Oil
Ore
Ore Concentrated
Overburden
P205
86
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
DBZF Dibenzofuran
DCB 1,4-Dichlorobenzene
DCE 1,2-Dichloroethane
DIST Distance
DMF DMF
DMTP Dimethyl Terephthalate
DRAN Drains
DRUM Drums
EAFDT EAF Dust
EDC EDC
EDCVC EDC-VC
ELEC Electricity
ELECRD Electrode
ENER Energy
EPCH Epichlorohydrin
ETCSOL Etching Solution
ETH Ethylene
ETHBNZ Ethylbenzene
ETHBST Ethylbenzene/Styrene
ETHCL Ethyl Chloride
ETHDB Ethylene Dibromide
ETHDC Ethylene Dichloride
ETHOX Ethylene Oxide
EXP Exposed
EXTFC Extractor Feed Cake
FABR Fabric
FDNHCO Feed NaHCO3 Dry
FEED Feed
FEEDDR Feed Dry
FEEDFR Feed Fresh
FEEDMT Feed Material
FELTST Felt Saturated
PERT Fertilizer
FIBR Fiber
FISH Fish
FISHML Fish Meal
FISHRW Fish Raw
FISHSC Fish Scrap
FLC1112 Fluorocarbon 11/12
FLC22 Fluorocarbon 22
FLSP Fluorspar
FORM Formaldehyde
FORM37 37% Formaldehyde
FRMGS Ferromanganese
FRSH Fresh
FUEL Fuel
Emission Inventory Improvement Program
85
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
BOD
BORD
BRED
BRIK
BUTDN
BUTDN13
CAD
CAN
CAPLM
CAR
CARTOT
CAST
CATL
CBLK
CC14
CEM
CFC133
CHAR
CHRMORE
CHXN
CIG
CL
CLAY
CLBNZ
CLFRM
CLMET
CLNK
CLOT
COAL
COALSTG
COAT
COKE
COKEFR
COKERW
CON
COPLY
CORE
COREOL
COTT
COW
CTET
CU
CULL
CUM
CURR
CUSC
Bodies
Board
Bread
Brick
Butadiene
1,3-Butadiene
Cadmium
Cans
Caprolactam
Car(s)
Cargo Total
Castings
Catalyst
Carbon Black
CC14
Cement
CFC-133
Charcoal
Chromite Ore
Cyclohexene
Cigarettes
Chlorine
Clay
Chlorobenzene(s)
Chloroform
Chloromethane(s)
Clinker
Clothes
Coal
Coal Storage
Coating
Coke
Coke Free
Coke Raw
Concrete
Copolymer
Cores
Core Oil
Cotton
Cattle
Carbon Tetrachloride
Copper
Gullet
Cumene
Current
Copper Scrap
84
Emission Inventory Improvement Program
-------
02/57
PROTOTYPE 841 CONVENTION DOCUMENT
Indicates a process product: " ,{,"" \ .i": ^
1. When mis code is applied, REF04 must also be |
applied. .A.-V. .. .' -.- • ' "';-^.', r~" "v^*-:4P"--*"!l.'-'•'. *1
REF02 127 Reference Identification - • - • - -— AN ""^1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
1. When REFOt fa T2^ && ?l«nentr contains the operating schedule line itenv-1
being reported with tills iteration of the loop: Select one from the following.'l -
numeric(CH'^'O^Ksfc,,,'"!|il'>"'*!*;-*> :?-, ,'S -'I*,"'. ~* '.',}*:'•'''',-l',J;^ji;.•:-:'"", '•"" ~f,-^.'a <
'•'•'- ''f"L'^f:^f^i^:"^:f:f^ \-I^y£,b •-^ '."X-1-^'">-.'-, "'•- '• -.
' • • .. ••* ^-:- *:< te~ ^ •, r ^* -, , '' * -*~i' , ~~ \ ,i> '' ^--:-~ ^J' 't^
3. When REFOl is "PG", mis element contains the appropriate product c^
yahife>JW^w.fir^i»^tt«w^^l*S^ow^
01 Ozone Season
02 Peak Ozone Season
03 CO Season
04 • Peak CO Season
05 Paniculate Matter Season
06 Modeling Episode
ABR Abrasive
ABSP ABS Polymer
ACEAL Acetaldehyde
ACID Acid
ACIDFN Acid Final
ACIDPR Acid Pure
ACRNL Acrylonitrile
ACROL Acrolein
ADH Adhesive
ADN ADN
ADPN Adipronitrile
AGNT Agent
ALLY Alloy
ALMA Alumina
ALMO Aluminum Molten
AMM Ammonia
ANILN Aniline
ASB Asbestos
ASP Asphalt
ASPSL Asphalt Shingle
BATT Batteries
BAUX Bauxite
BEAN Beans
BEANGR Beans Green
BEETRW Beets Raw
BNZN Benzene
Emission Inventory Improvement Program
83
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
Reference Identification
439
STA
Detail
Optional
>1
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
2. This segment
* -,
and the process characteristic information specified in tiieGID segment (pjri«r segment)
- ifi '• ,-*.„ ..' • ',' , Tjai'Bt--^:"«S»«.- "^ »:^Si.,---i">..S*I«^LlaSSSgiJ>t .TWA. S,.!"J,.5 !O^SS3 "»*?«-"* '
3. REF01 c^e"PG'XLe:; product) and REF04(ie., process) must be;
-, "SS-f"* 1^;* - i-'"''T'u'^,-^rV '£* "IV-V^^'" "ws^"iv^ - ^^111^^'^I^^^Sr^fe
conjunction in order, to identify aw activity
.
4. To report m activity (
* -
001 code-SUrandselecf the
,^^.^ ,^^^|^^ -a^j (."S^
1.^ »?—A.-a^* ----^-^'- ^JH^ „•»!& r^J^J^L. _ "Tatl ,
REF02 code h'st. Then
list An example of an ac
that can t>e identified is coal burnedl where coal is the
in die form of a text c
5 '
REiS
;M
«. .: . Jf- •: , i«¥•»*.•••..»u*5?Hr"^«*H"»>*K'SK.- 'V '''•" vi- ^StSs^'W
2. This elementmdicatestiie type of informatKm 6eing:iepoitec|wi
iteration of fte loopl Select one from the f
72 Schedule Reference Number
Identifies a number for a program schedule (for
example, a logic type of network) or working schedule
to complete a specific task or set of tasks
Indicates the operating scho
PG Product Group
82
Emission Inventory Improvement Program
-------
02/37
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
DTM01
DTM02
JJ 1 JV1 Date/Time Reference
437
STA
Detail
Optional
To specify pertinent dates and times
1 If either DTM06 or DTM07 is present, then the other is required.
2 At least one of DTM02 DTM03 or DTM06 is required.
I. This segment does not
2. This segment provid
associated with the
segment), T • -^^vp
^*ora»eafi^in 'the CID segment ftaior
^fSpf^^^-:/^^--^., :*
«»,3lp*iiS?4r- r-I*-1^--"=•". •'•-felS'V"'"-"'"^* •'&
BgM»Ei?;l^fevr%v.^4gi^3fe>i; •&
Sterf^Vi*?'
?ii«lit'*!f?rf
Data Element Summary
Data
Element Name Attributes
374 Date/Time Qualifier M ID 3/3
Code specifying type of date or time, or both date and time
1. This'ef
.- jfi ifc.rassu^i-Ji * w -«'i-_ - .- - -.,,-- ._ . ^
or adjustment factor specified m
Emission Inventory Improvement Program
81
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
C00105
C00106
WK Week
YR Years
1018 Exponent
Power to which a unit is raised
O R 1/15
I. This element contaim me exponent allowmg me formulation of the' ;-:".
complex expression that may be required as the unit of measure'associated
2. When applytag'a complex expression (e.g., million btu per gallon), apply
649 Multiplier""""" * "~~" " "' " ""' O "" R""~T/ '
Value to be used as a multiplier to obtain a new value
ffinariirmuffiplKr allowing meformulation of the
comple^expressionlhatmaybe required as the unit of measure associated
* t,-t J1^*-*.!^**** ^i.-fc. .>•*;.« , •s\'iii. , * •y-'-j!! ' ' ' •' •< •*•' s'<'"' -< * " ' "K -\
!||!|l|£|£|^^^
2,. Whea^rymg it complex expression (e.g., million bto,|>e| yt&jajf r" ^—**
80
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 341 CONVENTION DOCUMENT
STA02
STA03
739
C001
C00101
355
COO103
649
COO104
355
Measurement Value M R 1/20
The value of the measurement
I. This element contains the value associated with the code specified in the *
CID segment (prior segment). .....,,^-fc..-.. . /;,.,... .... , 1"J v" ""=;': '-••• :' I
Composite Unit of Measure O
To identify a composite unit of measure (See Figures Appendix for examples
of use)
I. This onnposite provides the units of measure associated with STA02. |
2. Tliet^oiftnewire is |
"34" and CBD04 (prior segment) is :!JHC? most be reported in the REF segment j
in a
3.
manner similar to the following example: million btu per gallon
'''' • • •1"-' ''-
Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
1. WhenTSTAOt:
"AC"
British Thermal Unit (BTU)
Days
Hours
Percent
Week
BY
DA
HR
PI
WK
Multiplier
Value to be used as a multiplier to obtain a new value
O
1/10
- < -"jrljriB' t ""^ "'V **•*-"•'*£ " an? *J •» " V"*
1. This element contains
2.
,.>Jp$
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
STA01
STA Statistics
435
STA
Detail
Optional
1
To provide summary statistics related to a specific collection of test result values
,
2. This loop provides the foUowing information:
'*
3.-'TIS'
Data Element Summary
Data
Element Name
950 Statistic Code
A code specifying the specific statistic being reported
iteration of the loop,-S
< , » *. S*,-*^^ _«iijJ * ', JB_j£ISr*pi
30 Average
34 Calculated
Attributes
M ID 2/2
ZZ
Mutually Defined
- f*™"****.^** a**, *. sw ^-wf
Indicates percenfc,
-- .-jj-ti , ww. ^*.s4i"3»
"
iH
1. WBenapplymg
78
Emission inventory Improvement Program
-------
02/97 PROTOTYPE 841 CONVENTION DOCUMENT
EP United States Environmental Protection Agency (EPA)
CID04 751 Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
I. This element indicates the type of information being reported with this
iteration of the loop. Select one from the following list: ;
A Seasonal Operating Adjustment Factor
AC Ash Content
HC Heat Content
S Operating Schedule
SC Sulfur Content
T Maximum Actual Throughput
Emission Inventory Improvement Program 77
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
CID
Characteristic/Class ID
Notes:
Ref.
DCS.
CID03
409
CID
Detail
Optional
1
To specify the general class or specific characteristic upon which test results are being
reported or are to be taken
1 If CID06 is present, then both CID03 and CID04 are required.
2 If CID07 is present, then at least one of CID04 or CID05 is required.
3 If either CID03 or CID04 is present, then the other is required.
4 At least one of CID01 CID02 CID04 or CID05 is required.
1 CID06 specifies the individual code list of the agency specified in CID03.
2 CID07 refers to whether or not the characteristic identified in CID04 or CID05 or
both is affected by the product change. If it is affected, the value is "Y". A value of
"N" is used when it is known that it will not be affected. Any other value indicates it
is indeterminate.
Data Element Summary
Data
Element Name
559 Agency Qualifier Code
Code identifying the agency assigning the code values
1. This elemebt identifies the
;; • ~> -, "*^ „,„„ i-lT •TP' i- ^-4" v-**^^^^-~?*^ - ^;™- -
Attributes
X ID 2/2
76
Emission inventory Improvement Program
-------
02/57
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
REF01
REF03
r\Jii.r Reference Identification
395
LX
Detail
Optional
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
1.
2..
specified
?*\:
_ „.,,,, V.'j." ","»;f..".' -'.^.•'•"-.••i"^.,'4.. „ „, . .
This segment provides growtia factor reference text associated with, the process
•.-^"..-i0^- '"c&i*-'.*«»- 'Vt,,-^-•^^-5^»v*^v«B^* .*.-.- -'-;••-:• K.'2.- --
Data Element Summary
Data
Element Name
128 Reference Identification Qualifier
Code qualifying the Reference Identification
352
Attributes
M ID 2/3
Description X AN 1/80
A free-form description to clarify the related data elements and their content
Emission Inventory Improvement Program
75
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
DTM01
DTM06
DTM07
DTJV1 Date/Time Reference
393
LX
Detail
Optional
>1
To specify pertinent dates and times
1 If either DTM06 or DTM07 is present, then the other is required.
2 At least one of DTM02 DTM03 or DTM06 is required.
Data Element Summary
Data
Element Name
374 Date/Time Qualifier
Code specifying type of date or time, or both date and time
Attributes
M ID 3/3
196 Start
575 Projected Action End Date
1250 Date Time Period Format Qualifier X ID 2/3
Code indicating the date format, time format, or date and time format
1251
CY Year Expressed in Format CCYY
Date Time Period
AN 1/35
Expression of a date, a time, or range of dates, times or dates and times
74
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
JYllLA. Measurements
Semantic Notes:
Comments:
Notes:
Ref.
DCS.
MEA01
MEA03
MEA04
C00101
387
LX
Detail
Mandatory
To specify physical measurements or counts, including dimensions, tolerances, variances,
and weights (See Figures Appendix for example of use of COO I)
1 If MEA05 is present, then MEA04 is required.
2 If ME A06 is present, then MEA04 is required.
3 Only one of MEA08 or MEA03 may be present.
4 If MEA07 is present, then at least one of MEA03 MEA05 or MEA06 is required.
5 At least one of MEA03 MEA05 MEA06 or MEA08 is required.
1 MEA04 defines the unit of measure for MEA03, MEA05, and MEA06.
1 When citing dimensional tolerances, any measurement requiring a sign (+ or -), or
any measurement where a positive (+) value cannot be assumed, use MEA05 as the
negative (-) value and MEA06 as the positive (+) value.
Vi •*» * -***-<£^f" ,:£ST^*- '*. *;>'•;",$'-•",'-I-..
'<£it£K*rf' T^; -•' ?*v ^3t» .t •.»: ~ *."*P5
Data Element Summary
Data
Element Name Attributes
737 Measurement Reference ID Code O ID 2/2
Code identifying the broad category to which a measurement applies
AG
739 Measurement Value X R 1/20
The value of the measurement
~-T ~x"'::
-••-"f^.i*Mrffi7iitirt^rf-'T'Mi'''---^^^ •• -' " ' -•• ">-•-• -. ......
C001 Composite Unit of Measure X
To identify a composite unit of measure (See Figures Appendix for examples
of use)
355 Unit or Basis for Measurement Code M ID 2/2
Code specifying the units in which a value is being expressed, or manner in
which a measurement has been taken
1. This element coi
PI Percent
Emission Inventory Improvement Program
73
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
LX01
Assigned Number
381
LX
Detail
Optional
1
To reference a line number in a transaction set
1. Thislool*
Data Element Summary
Data
Element Name Attributes
554 Assigned Number M NO 1/6
Number assigned for differentiation within a transaction set
72
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
DCS.
REF01
REF02
Reference Identification
371
REF
Detail
Optional
1
To specify identifying information
1 At least one of REF02 or REF03 is required.
2 If either C04003 or C04004 is present, then the other is required.
3 If either C04005 or C04006 is present, then the other is required.
1. IB?
reporting.
Data
Element
128
127
Data Element Summary
Name
Reference Identification Qualifier
Code qualifying the Reference Identification
Attributes
M ID 2/3
Hbn (SIC) code. ^*-'!
IJ Standard Industry Classification (SIC) Code
Reference Identification X AN 1/30
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
ttiervah)i''a^fei*etf^itaREFOL- '-':-• "' "" ',""
Emission Inventory Improvement Program
i\
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
PID03
PID04
PID06
559
751
752
1. This code allies whh AREA, MOBBOgfflid- "
NONROAI>ENGlfcE 'sOURCEir^^^2^^^ •
SC Source
Indicates 1
Agency Qualifier Code ----•->•-< - •*•* ~^ ^ ^
Code identifying the agency assigning the code values
i:
EP United States Environmental Protection Agency (EPA)
Product Description Code X AN 1/12
A code from an industry code list which provides specific data about a product
characteristic
1.
Surface/Layer/Position Code O ID 2/2
Code indicating the product surface, layer or position that is being described
70
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Ref.
Des.
PID01
PID02
L J.JLJ Product/Item Description
345
FID
Detail
Optional
1
To describe a product or process in coded or free-form format
1
2
3
4
1
2
3
If PID04 is present, then PID03 is required.
If PID07 is present, then PID03 is required.
If PID08 is present, then PID03 is required.
At least one of PID04 or PID05 is required.
Use PID03 to indicate the organization that publishes the code list being referred to.
PID04 should be used for industry-specific product description codes.
PID08 describes the physical characteristics of the product identified in PID04. A
"Y" indicates that the specified attribute applies to this item. A "N" indicates it does
not apply. Any other value is indeterminate.
If FIDO 1 = "F", then PID05 is used. If FIDO 1 = "S", then PID04 is used. If FIDO 1 =
'' X", then both PID04 and PID05 are used.
Use PID06 when necessary to refer to the product surface or layer being described in
the segment.
FIDO? specifies the individual code list of the agency specified in PID03.
Notes: I. This loop/:
-. ;-..rf. ^-*trf
j^^l-itC-^fci
. JW«»»jSiK^J^'- t-* - " 4%-1,-m •- .jr-i " - • - i—
|«;*'ft^jf"*k3r •~'i*«- ^a^JpSfe-T1* --•••:., V
Stf. J$ * *^ "S^'* **^ " J *'-•* i"!'" 'r fS "*•'•-,
ne to pro vide tfie emission process
»'*^^*s>.*5 *»- i- >'.» . .'->„. '-'., .£*&.. -x *-; ,
_ ,.i-._v-.,--_-_....„_.._-_..-,.... ;j a*secondairy"emfesiqn'i.;^-|
P^S^i^O^^lii^S^^Mto^^^^**^^^..- v^'J^-'.t.f . *i*&' -m« ^'-~, . -1 '-•„»„. .3
Data Element Summary
Data
Element Name
349 Item Description Type
Code indicating the format of a description
I. Tn&elimeaFmdican^^
codefcbe^pmeaj^itt^ /'-.: ".;;•;'*• ^-,'"-/r
S Structured (From Industry Code List)
Product/Process Characteristic Code O ID 2/3
Code identifying the general class of a product or process characteristic
1. Code-fl*
Attributes
M ID 1/1
of emission process |
750
2. This element indicates the type of emission process code information being
reported with mis iteration.of the loop. Select one from the following list;
12 Type and/or Process
Indicates the AIRS Area and Mobile Sources (AMS) or
Area Source Category (ASCT) code
Emission Inventory Improvement Program
69
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ret
Des.
» MSG01
MSG Message Text
339
SPI
Detail
Optional
To provide a free form format that would allow the transmission of text information
1 MSG02 is not related to the specific characteristics of a printer, but identifies top of
page, advance a line, etc.
Data Element Summary
Data
Element Name
933 Free-Form Message Text
Free-form message text
Attributes
M AN 1/264
68
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
SPI03
SPI05
127
791
Code qualifying the Reference Identification
1. This element applies with POINT SOURCE reporting only. T
2. This element must be applied at least one (1) time to provide code "2EV
3. This element indicates the type of process identifier being reported with this J
iteration of the loop,^Sjefact one ffojathefoUowmgUst^ f'J
21
IX
PE
WF
Tracking Number
•BffiSSSteS&tiCiia-JcI
Item Number
;--"T£>;S'*''Ki*'-"'r««rfisK**i*a.a
X AN 1/30
Reference Identification
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
^reporting
with a.
Entity Purpose O AN 1/80
The reason for the existence of the data item specified by the electronic data
item independent of its presence in an EDI transaction
Emission Inventory Improvement Program
67
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Ref.
Des.
SPI01
!JA I. Specification Identifier
323
SPI
Detail
Optional
1
To provide a description of the included specification or technical data items
1 If either SPI02 or SPI03 is present, then the other is required.
Data
786
Data Element Summary
Name Attributes
Security Level Code M ID 2/2
Code indicating the level of confidentiality assigned by the sender to the
information following
00
02
90
92
Company Non-Classified
Company Confidential
Government Non-Classified
Government Confidential
SPI02
128 Reference Identification Qualifier
ID 2/3
66
Emission Inventory Improvement Program
-------
02/97
PROTOTYPE 841 CONVENTION DOCUMENT
Ref.
Des.
HL01
HL02
HL03
HL04
DTM*575*****CY*199*~
CID***EP*S~<
STA*30*24*HR:::DA:-1~
DTM*196*9605(H~
DTM*197*960930~
REF*72*06~ "•;£',. * : _;' .V - - . „" "A,:; / ' ;V ?•;'.• '• JC- l^;';•'-;
< information that is non-classified, associated with a process that is identified with a
Federal segment code of 1234567, is being reported in a structured format indicating an
SCC of Z234aniian SIC code of 33; has a process growth factor of 10 percent for the
period starting in 1997 and ending in 1998; has an operating schedule that averages 24
hours per day for the period beginning May 1,96 and ending September 30,96 and
"-•••- -.--.-• , - »" - J" • •*" ,-^:"-*|;'?i,4sfe*'- •„ •
ZK .w-'*v- ^l^t-.-^|?sv^r-''^" :'-• * • •?£?Wi~~~*> '- •* '
Sit .'-,:<-»»*J t*'4 •".* -lr fhff ,'^S,','- ' >
rsf-.-jji'&r^-V'^'s /... ' *f?i*^*^~-- '-.'..--'---
.v-ferw-.-SiS^&fv^1'-* "'•r.|?*"f '"• --^
, , „„,, ,^v^_
SB":'..,"„',:, ijil^iv*-'-.",™--'*^;;-^ '"!• •*;""• "-,-- ' st-v~~—, • ,
ff^^i^^fy^f''\if'?!^^^:^i^I^- •''" •'"'' 'T~'j*"",.''- -
ftouW;secondHLIoopof
Data Element Summary
Data
Element Name Attributes
628 Hierarchical ID Number M AN 1/12
A unique number assigned by the sender to identify a particular data segment
in a hierarchical structure
734
735
736
identify the iteration of an
' ' " ' """"" " '
AN 1/12
Hierarchical Parent ID Number O
Identification number of the next higher hierarchical data segment that the data
segment being described is subordinate to
----- •- -
Hierarchical Level Code
Code defining the characteristic of a level in a hierarchical structure
Sub-Category
Code identifying a further breakdown of the category
Hierarchical Child Code O ID 1/1
Code indicating whether if there are hierarchical child data segments
subordinate to the level being described
I Additional Subordinate HL Data Segment in This
Hierarchical Structure
Emission Inventory Improvement Program
65
-------
PROTOTYPE 841 CONVENTION DOCUMENT
02/97
Segment:
Position:
Loop:
Level:
Usage:
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
JtI.Aj Hierarchical Level
319
HL
Detail
Mandatory
1
To identify dependencies among and the content of hierarchically related groups of data
segments
1 The HL segment is used to identify levels of detail information using a hierarchical
structure, such as relating line-item data to shipment data, and packaging data to
line-item data.
2 HL01 shall contain a unique alphanumeric number for each occurrence of the HL
segment in the transaction set. For example, HL01 could be used to indicate the
number of occurrences of the HL segment, in which case the value of HL01 would
be " 1" for the initial HL segment and would be incremented by one in each
subsequent HL segment within the transaction.
3 HL02 identifies the hierarchical ID number of the HL segment to which the current
HL segment is subordinate.
4 HL03 indicates the context of the series of segments following the current HL
segment up to the next occurrence of an HL segment in the transaction. For example,
HL03 is used to indicate that subsequent segments in the HL loop form a logical
grouping of data referring to shipment, order, or item-level information.
5 HL04 indicates whether or not there are subordinate (or child) HL segments related
to the current HL segment.
MEA*AG**tO*Pl~*
DTM*196*****CY*1997~
64
Emission Inventory Improvement Program
-------
02/9 7 PRO TO TYPE 841 CONVENTION DOCUMENT
Indicates that a unit remains on site with no possibility 1
ofreuse " • ""• -_•*•*-... ;;'-"/'":j^,'. '. ,1
REF03 352 Description X AN 1/80
A free-form description to clarify the related data elements and their content
1. Tm's element contains a textual description'associatedwith REF02.
- . . - . , , ,-> - .,-..-*^-,,#,'^-JK,:± ,, . > -v -5., , * • •
Emission Inventory Improvement Program 63
------- |