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

-------