# Proof of Concept Demonstration for Electronic Reporting of Clean Water Act Compliance Monitoring Data With T hird

- P arty So ftware Providers
Final Report

Public Rec ord for the NPDES Electronic Reporting Rule
EPA Docket Number EPA

– HQ

– OECA

– 2009

– 0274 (www.regulations.gov)

12 January 20122 TABLE OF CONTENTS

Page
1.0 O VERVIEW

................................ ................................ ................................ ................................ .............. 3 2.0 S OLICITATION OF P ROOF OF C ONCEPT P ARTICIPANTS

................................ ................................ ..................... 5 3.0 C ONDUCTING P ROOF OF C ONCEPT

- T WO

- P HASED A PPROACH

................................ ................................ ........ 7 4.0 R ESULTS OF P ROOF OF C ONCEPT T ESTING

................................ ................................ ................................ .... 9 5.0 L ESSONS L EARNED

................................ ................................ ................................ ................................ . 12 6.0 N EXT S TEPS

................................ ................................ ................................ ................................ .......... 14

Appendices

A Proof of Concept Federal Register Notice

B Proof of Concept Checklist3 

## 1.0 O VERVIEW

EPA announced on July 6, 2009, that it would develop a Clean Water Act Action Plan to enhance public transparency regarding clean water enforcement performance at federal and state levels, to strengthen that performance, and to transform EPA’s water quali ty and compliance information systems. A consensus suggestion across co

- regulators and stakeholder groups was to implement electronic reporting from facilities that are required to submit reports to a regulatory agency. To fully realize the transformation of reporting and data management into the 21st century, OECA is developing a rule to require Clean Water Act (CWA) National Pollutant Discharge Elimination System ( NPDES ) permittees to provide a variety of environmental information electronically.
EPA’s in formation about point source water pollution and their compliance with the CWA is largely built on paper

- based reporting developed nearly forty years ago and initially focused on a subset of point source pollution. Since then, the universe of permitted fac ilities has grown from 100,000 to clos e to a million. There is significant interest in the electronic reporting of information for this expanded universe of regulated facilities. Electronic data collection and transmission could potentially: (1) aid regulated facilities in reporting their NPDES compliance monitoring data; (2) reduce burden on states and improve data quality as electronic data submissions eliminate the need for tran sferring data from paper

- based forms to state and EPA databases; (3) provide more timely and accurate data for enforcement targeting and reporting; (4) increase transparency on regulatory compliance; and (5) enhance EPA’s oversight and states’ management o f the NPDES program. EPA and many states already have built electronic reporting tools for some of the CWA NPDES compliance monitoring information. For example, in June 2009, EPA made publicly available an electronic reporting tool, Network Discharge Monit oring Report (NetDMR), for the electronic reporting of Discharge Monitoring Report (DMR) data from the regulated facilities to EPA. 1 EPA is exploring other electronic reporting options to enable NPDES regulated facilities to electronically submit their NP DES information ( e.g. , compliance monitoring data ) to EPA and states

. As part of this effort , EPA conducted a technical proof of concept to demonstrate the electronic reporting of NPDES compliance monitoring data from regulated facilities via an ‘open plat form e

- file’ electronic reporting option. The open platform e

- file proof of concept demonstration focus ed on the electronic transmission of NPDES DMRs from a third

- party commercial software provider (“provider”) to EPA. If EPA were to fully implement this option, any provider that meets the Agency’s data exchange standards, protocols, and specifications would be able to offer electronic reporting services to the regulated community for the NPDES program ( e.g. , NPDES permitted facilities). This open platfor m model would likely be similar to the Internal Revenue Service (IRS) model for

1 See: www.epa.gov/netdmr/.4 electronic reporting, which uses third

- party software providers for tax data collection and transmission ( e.g. , TurboTax, TaxACT, or others [no endorsement intended or implied] ) from private citizens and businesses. Under this option , the Agency would not purc hase services from any provider. A ll financial transactions would be between the providers and members of the regulated community

. EPA held several meetings with IRS to lea rn from their experiences ( see DCN 0041 )

. I f EPA were to fully implement the open platform e

- file option, EPA would need to review and determine whether the providers ’ software meets the criteria to successfully exchange , submit and load the electronic reports into EPA data systems or to states’ system that would, in turn electronically submit these data to EPA

. The software would need to use standards, protocols and specifications for electronic reporting, and follow guidance on how the software provide rs would share th e s e data with EPA or states through the EPA’s Central Data Exchange (CDX) using the Environmental Information Exchange Network (“Exchange Network”) services. EPA would also need to coordinate with states to fully implement the open platfor m e - file option , as EPA has authorized 46 states to manage the NPDES permit program. F ull implementation of the open platform e

- file option would require compliance with the Cross Media Electronic Reporting R egulation (CROMERR), 40 CFR 3, and any future re quirements of the NPDES Electronic Reporting Rule. P articipation in the proof of concept does not affect the potential for providers to participate in future open platform e

- file efforts.
EPA conducted a technical proof of concept for the electronic repor t ing of DMR data via a third

party software provider through CDX to EPA’s national database, the Integrated Compliance Information System National Pollutant Discharge Elimination System (ICIS

- NPDES)

. Th e goal of the proof of concept was to assess the level of interest among providers for this new reporting option and to assess the ability of EPA and the providers to technically transmit DMR data from third

- party software products to ICIS

- NPDES. The p roof of c oncept was conducted with software providers in th e summer and fall of 2011. EPA did not use participation in the proof of concept or its results as part of any certification process and EPA will not use participation in the proof of concept or its results as an eligibility factor for participation in pot ential future related data exchange projects. Additionally, p articipation in th e proof of concept wa s voluntary and EPA did not provid e any funds to the providers for their participation

. Finally , EPA did no t use this proof of concept or its results to end orse the commercial products or services from any of the participants. This report provides a summary of this effort , lessons learned, and ne x t steps for full y implementing an EPA open platform e

- file option

.5 

## 2 .0 S OLICITATION OF 

## P ROOF OF 

## C ONCEPT 

## P ARTICIPANTS

EPA started the proof of concept with a Federal Register notice soliciting interested software providers. This Federal Register notice provided context for the proof of concept . A dditional information was provided via webinars. EPA use d the provider s’ orientation webinar to provide information on the overall p roof of c oncept effort ( i.e. , scope , schedule) and the specifics on the requirements for participating in the proof of concept

. The orientation webinar wa s open to all interested software providers but w as mainly focused on providing information to those providers interested in participating in the open platform e

- file proof of concept

. Seventy seven attendees participated on the orientation webinar , which included: non - governmenta l (44) , state/local (30), and Federal participants (4)

. Topics covered included an overview of:

**•** EPA ’s Clean Water Act Action Plan, the NPDES Electronic Reporting Rule, and the potential role for the open platform e

- file option.

**•** EPA’s CDX and Exchange Netwo rk web services that support the open platform e

- file option.

**•** T echnical proof of concept scope for the open platform e

- file option (DMR data).

**•** Schedule and requirements for providers interested in participating in the technical proof of concept ( see standa rds, protocols, and specifications below)

.
**•** Question and answers from the webinar participants on the technical proof of concept demonstration. In addition to the software provider webinars, EPA conducted webinars with EPA Regions, states, ASIWPCA ( the state clean water association now known as ACWA) , and the Environmental Council o f the States (ECOS)

. The technical proof of concept wa s open to all providers; however, EPA required that providers describe and provide examples of their work and technic al experience in exchang ing data, and the ir knowledge of the NPDES permit program. In order to participate in the technical proof of concept , interested providers were required to submit a letter indicating their interest in participating in the technical proof of concept demonstration along with a short description of their company, contact information, and work experience (including examples) in using the following standards, protocols, and specifications required to use EPA Exchange Network services:

**•** The Node 2.0 Functional Specifications and Protocols

**•** ICIS

- NPDES Flow Configuration Document, DMR Extensible Markup Language (XML) Schema, ICIS

- NPDES DMR Batch User Guide, ICIS

- NPDES DMR Data Exchange Template, and ICIS

- NPDES DMR Example XML Instance Document

**•** Exchange standards that include: Extensible Markup Language (XML); Simple Object (SOAP) v 1.2; Web Services Description Language (WSDL) v1.1; Secure Hypertext Transfer Protocol (https) (see NIST 800

- 52); WS

- Security v 1.0; and Mes sage Transmission Optimi zation M echanism (MTOM).6 EPA required that the providers include in their letter of interest detailed information on the following items to illustrate the ir experience in meeting the requirements identified above:

**•** Connect ing using https

**•** Submit ting files to an EPA Node using the published WSDL

**•** Support ing Trading Partners in Exchange Network data exchanges using Node 2.0 specifications

**•** Generat ing data in XML format

**•** Operat ing schema validation tools

**•** Pars ing XML files

**•** Gather ing and stor ing DMR data from facilities

**•** Provid ing monthly DMR data in an electronic format

**•** Transferring files through the CDX node on the Exchange Network,

**•** Check ing the submission status with CDX, and download processing results from CDX

**•** Generat ing monthly DMR data in XML format as required by ICIS

- NPDES EPA also required providers to include in their letter of interest a short written statement of their experience and understanding of the NPDES program and of their experience with assisting regulated entities or states with completion of DMR submissions , whether these submissions used the DMR XML schema, and the use of the technical specification, protocols, and standards in these data exchanges. Finally, EPA required that providers include in their letter of interest a statement certifying that they were not on the General Services Administration's Excluded Parties List System.
EPA review ed these written submissions and identif ied the providers that generally met EPA’s eligibility requirements for participation in the t echnical proof of concept. EPA determine d eligibility based on the providers ’ written submissions of their work experience (including examples) in using data exchange standards, protocols, and specifications ( see set of three bullets above ) and the NPDES p ermit program ( see previous paragraph). Based on these written submissions EPA identif ied five providers and notif ied the m of their acceptance for the proof of concept

. Three of the providers used Microsoft .NET Framework (pronounced dot net ) to develop th eir software user interface . Another provider used the open source Java Development Kit (JDK) 7. One provider was not able to complete the proof of concept.7 

## 3 .0 C ONDUCTING 

## P ROOF OF 

## C ONCEPT


## - T WO


## - P HASE D 

## A PPROACH

Two phases were used for conducting the proof of concept. The first phase , regarding Exchange Network connectivity , demonstrated whether the third

- party commercial software met the standards, protocols and specifications for electronic reporting through EPA’s CDX Node on the Exchange Network. In this phase, software providers were given a two

- hour training session by CDX staff and provided with information on :

**•** Node 2.0 functional specifications and protocols,

**•** ICIS

- NPDES flow configuration document and the criteria for exchanging data using XML,

**•** SOAP v1.2, WSDL 1.1, https,

**•** WS

- Security v1.0 , and

**•** MTOM. Using the information and tools provided, the providers had to prove they could generate data in XML format, operate XML schema validation tools , connect to CDX using https, transfer files to other partners on the Exchange Network through CDX using its associated WSDL, check on the submission status , and download processing results in XML format. The second phase , regarding ICIS

- NPDES submission , demonstrated the provider s’ ability to generate DMRs containing monthly measurements that could be processed for existing limits within ICIS

- NPDES according to its defined XML schema. In this phase, soft ware providers were given a two

hour training session by ICIS

- NPDES staff and pr ovided with sample limits in ICIS

- NPDES along with relevant ICIS

- NPDES documentation, such as :

**•** T he ICIS

- NPDES Batch User Guide,

**•** An e xample XML Instance Document,

**•** The Data Exchange Template,

**•** The DMR reporting technical specifications , and

**•** E xpected DMR s chedule technical specifications containing the algorithm to anticipate when DMR values were due at ICIS

- NPDES

. With this information, software providers were instructed to submit data that met the following criteria with a 100% success rate . EPA created a checklist to help the software providers with EPA’s expectations at each stage of the proof of concept and for the software providers to track their own performance ( see Appendix B).

**•** DMRs with change, replace , and mass delete transactions being submitted at the same time for one or more permitted facilities;

**•** One permitted facility having over 25 unique outfalls with parameters being reported at the same time;

**•** One permitted facility having over 25 unique parameters being reported at the same time;8 **•** Multi

- se asonal parameters being reported with non

- seasonal parameters at the same time for one or more permitted facilities;

**•** Parameters monitored monthly, quarterly, annually , and semi

- annually being reported at the same time for one or more permitted facilities;

**•** Scheduled parameters and unscheduled parameters being reported at the same time for one or more permitted facilities;

**•** Monitored and optionally monitored parameters being reported at the same time for one or more permitted facilities;

**•** Biosolids data being r eported with parameter values at the same time for one or more permitted facilities;

**•** Parameters for one or more sewage treatment plants being reported for one or more permitted facilities;

**•** Parameters with reported values, No Discharge Indicator (NODI) para meters with a combination of reported values , and NODI parameters reported at the same time for one or more permitted facilities; and

**•** DMRs that are able to pass all business rules specified in the ICIS

- NPDES Batch Technical Specification Document.
The dura tion of the ICIS

- NPDES phase was 17 business days. The ICIS

- NPDES Team held weekly status calls with the software providers during this phase to check their progress and answer questions

. The software providers were also given instructions on how to report issues along with the steps to follow when reporting them to the ICIS

- NPDES Team

.9 

## 4 .0 R ESULTS OF 

## P ROOF OF 

## C ONCEPT 

## T ESTING

All five software providers passed the Exchange Network c onnectivity testing phase, and four out of five providers participated in the ICIS

- NPDES submission phase. Two software providers met the criteria within the timeframe given. One software provider had made some progress but requested an extension of two weeks to complete the set of criteria

. The following section summarizes the results of the ICIS

- NPDES submission phase.
Results of the ICIS Submission Phase
Software Provider Criteria Met Comments
Provider 1 Partly Provider a sked for two week extension

. Provider 2 Yes Provider did n ot provided the necessary artifacts to prove they met the criteria

. Provider 3 Yes Provider 4 Yes Provider 5 N/A Provider d id not participate in Phase 2.



### Software Provider 1

Status: Partly Complete. Summary: Software Provider 1 claim ed to have submitted files that passed CDX validation but w as unable to successfully load any files into ICIS.

Comment: Software Provider 1 achieved partial success but did not complete the proof of concept

. EPA note s that this provider did not complete the following items on the proof of concept checklist:

**•** Provider t ool can generate an XML file of DMR data in the format required by the ICIS schema

.
**•** Provider t ool can generate an XML file containing valid monthly DMR data according to the business rules specif ied in the ICIS DMR technical specifications

.
**•** ICIS Batch accurately processes an XML submission file containing a combination of change, replace and mass delete transactions for one or more permitted facilities

.
**•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions for one permitted facility having over 25 unique outfalls with parameters being reported at the same time

.
**•** ICIS Batch accurately process an XML submission file containing change, re place and/or mass delete transactions for one permitted facility having over 25 unique parameters being reported at the same time

.
**•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions for multi

- sea sonal parameters being reported with non

- seasonal parameters at the same time for one or more permitted facilities

.10 **•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions for parameters monitored mon thly, quarterly, annually and semi

- annually being reported at the same time for one or more permitted facilities

.
**•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions for scheduled parameters and u nscheduled parameters being reported at the same time for one or more permitted facilities

.
**•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions for monitored and optionally monitored parameters be ing reported at the same time for one or more permitted facilities

.
**•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions biosolids data being reported with parameter values at the same time for one or more permitted facilities

.
**•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions parameters for one or more sewage treatment plants being reported for one or more permitted facilities

.



### Software Provider 2

Status: Mostly Complete. Summary: Software Provider 2 was able to successfully load most DMR files into ICIS; however, there
were a few DMR data files that this provider was unable to successfully load in ICIS.

Comment: Software Provider 2 p rovided some response files/e

- mails from CDX but they were not a complete set as indicated in the proof of concept checklist. EPA notes that this provider did not complete the following items on the proof of concept checklist:

**•** ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions for one permitted facility having over 25 unique outfalls with parameters being reported at the same time

.
**•** ICIS Batch accurately process an XML submission file containing ch ange, replace and/or mass delete transactions for one permitted facility having over 25 unique parameters being reported at the same time

. 

### • ICIS Batch accurately process an XML submission file containing change, replace and/or mass delete transactions param eters for one or more sewage treatment plants being reported for one or more permitted facilities

. 

### S o ftware P rovider 3

Status: Complete. Summary: Software Provider 3 was completely successful. The provider submitted files that passed CDX validation , successfully loaded files into ICIS

- NPDES, and was able to download error reports.

Comment: The provider should be ready for the pilot using CROMERR services for later this year.11 

### Software P rovid er 4

Status: Complete. Summary: Software Provider 4 w as completely successful. The provider submitted files that passed CDX validation , successfully loaded files into ICIS

- NPDES, and was able to download error reports.

Comment: The provider should be ready for the pilot using CROMERR services for later this yea r
.



### Software Provider 5

Status: Incomplete, did not fully partic i pate in the proof of concept

. Summary: Software Provider 5 was only successful in the connectivity test (Phase 1) . The provider did not attempt to test actual submission of DMR files (Phase 2)

. Comment: EPA note s that this company has a strong understanding of the NPDES program but does not currently posses the technical capabilities to transmit data to ICIS

- NPDES.12 

## 5 .0 L ESSONS 

## L EARNED

This section discusses the lessons learned by OEI, OECA , and the software provider participants in this proof of concept

. OECA

**•** The five software providers who participated in the p roof of concept had varying levels of NPDES programmatic and IT experience. The ICIS

- NPDES Team found that it was easier for the providers with little or no NPDES programmatic experience to overcome the lea rning curve than it was for the providers with little or no IT experience.

**•** For the ICIS

- NPDES Submission, Phase 2 , the ICIS

- NPDES Team attempted to identify all possible materials that a third

- party software provider might need in order to build an exchange of its DMR s to the ICIS

- NPDES Data Flow, including the required Exchange Network Documentation, as well as DMR

- related technica l specifications describi n g how ICIS

- NPDES w ould process incoming DMR data. The software providers did not ask for clarification on these documents , and three of them experienced 100% success rates, which indicates that the documentation was sufficient for understand ing how to build an XML file for submission

. However, there were problems with the software vendors understanding the criteria checklist

. M ost of this was due to the ICIS

- NPDES Team’s not having experience dealing with software providers with a strong IT background and weak DMR background such as Software Provider 4

. Provider 4 stated in the final conference call, “the technical part was trivial and not a problem, the business domain/requirements took the most work.”

**•** The third

- party software is designed to collect daily, weekly , and bimonthly data for limits that are not in ICIS

- NPDES which caused the providers to rely on the limits data the ICIS

- NPDES Team provided for generating DMRs that could be processed by ICIS

- NPDES ( rather than using real data within their systems )

. Because of this, the ICIS

- NPDES Team recommends ICIS

- NPDES be enhanced to apply DMR values from incoming submissions to limits that are stored in ICIS

- NPDES and reject only those that do not have limits , rather than rejecting a n entire parameter just because one of a value’s limit is not on hand.

**•** A few issues and questions were sent to the ICIS

- NPDES Team during the ICIS

- NPDES submission phase, which provided an excellent forum on the weekly status calls. The ICIS

- NPDES Team al so found it valuable to copy all participants on any email responses to the original requestor , ensur ing all software providers were dealt with fairly.

**•** The final lessons learned from the ICIS

- NPDES Team were the difference s in assistance needed to partici pate and complete the proof of concept

. Overall , these providers required only minimal support from EPA staff. Software providers having a wealth of knowledge with DMRs required less13 assistance and explanations than the others. However, providers with limi ted knowledge on how to process and submit data are at a significant disadvantage and will require additional time to successfully submit DMR data to ICIS

- NPDES.
OEI
Several lessons were learned in the proof of concept :

**•** Focused Communication

. To be clear and help all of the software providers in the proof of concept, f ocus on key parts of the specifications, protocols, and flow configura tion document ( FCD). While several of the providers were able to review the specifications and the FCD to det ermine what was needed to connect, use the services , and pass the correct parameters to submit DMR s , others were not. In several e

- mails we had to focus on the essential items needed in order to successfully complete the submission ( e.g. , proper endpoints, parameters to pass , MTOM attachments for messaging )

.

**•** Clear criteria on what is considered success

. Although EPA provided a checklist for ensuring the provider’s software successfully comp leted the submission and loaded into ICIS, it did not clearly state the names of the artifacts ( e.g. , results files) that were needed as evidence of the software capability.

**•** Demonstration of s o ftware i nterface . As a final check , it would be useful to see the interface that would be developed for commercial use. This will be especially important in the next planned phase where CROMERR services will be used.
Third

- Party Commercial Software Providers EPA held a conference call with proof of concept participants on October 21, 2011 to gather their thoughts and comments on the proof of concept and EPA’s support

. All of the providers noted that connect ing to CDX was very straightforward and easy. They all noted that participation in the proof of concept was a very positive experience. They commented that feedback and support fro m EPA was very responsive and helpful. They also appreciated the documentation that EPA provided to support the proof of concept effort

. One provider noted some initial difficulty in processing SOAP message s. These messages required MTOM

. EPA noted that th ese requirements were included in the project’s supporting documentation but also agreed that it could be better highlighted in the documentation . All providers noted that their work on the proof of concept would be the basis of any future development. Onl y one of the providers ha d a commercial interface developed at the time of th e proof of concept. Others that participate in the future will look to developing such an interface. They noted that additional work was necessary before their software w ould be ready for commercialization. All expressed an interest in EPA pursuing the open platform e

- file electronic reporting option and taking the concept into production.14 

## 6 .0 N EXT 

## S TEPS

Overall , all participants identified the proof of concept as a success and suggested that EPA take the concept into pro duction

. A dditional funding and FTE resources will be required to pursue the open platform e

- file electronic reporting option and tak e the concept fr om pilot

- scale to production. This funding will allow the Agency to develop services and provide the governance framework to support an open platform system that would be available to any commercial software provider that would want to offer a Federal elec tronic reporting service to their clients. EPA’s new open platform model would specify the protocols, services, and technical specifications for integrating the platform with Agency services and the requirements for electronic reports to be loaded into Agency data systems

. Expected benefits include lower processing costs for facilities, improved data quality and accuracy, greater data accessibility and transparency for the public, and an increased ability to target and address noncompliance that will improve and protect the environment. Initial next steps for this effort for OEI and OECA would be to develop the services needed for CDX to support NPDES Program reporting ( i.e. , eDMRs, eNOI, program reports , and CROMERR services )
a nd the governance framework to ensure that software provider

- developed software can readily use these services. The services developed through this effort could be reused to support similar provider

developed software for other EPA program areas in the nea r future. OECA will also need additional funds to prepare ICIS

- NPDES to receive this information via CDX. Specifically OECA would utilize the resources for the e

- flows for ICIS

- NPDES, including:

**•** Developing technical requirements ,
**•** Code development ,
**•** Developi ng test plan ,
**•** Developing test cases ,
**•** Performing testing ,
**•** Performing CDX testing ,
**•** Performing load testing ,
**•** Supporting beta, UVT, and UVA testing ,
**•** Implementation ,
**•** O peration and Maintenance (O&M) , and

**•** Participating with OEI in the governance process and coord inating with vendors

. OEI would require additional funding to develop the services within CDX to be leveraged by pro vi der

- developed software for compliance and program reporting and set up the governance for use of these services. Specifically OEI would ut ilize the resources for the NPDES e

- flows for:

**•** Establishing the governance framework and process for setting standards, guidelines, and procedures, and reviewing and certifying commercial software provider

- developed software.

**•** Defining data delivery protocols and technical specifications for each NPDES collection

.
**•** Communicating and coordinating with each provider throughout the entire development15 lifecycle

— from initial screening of provider capabilities to participate, orientation on the protocols and technical specifications, through development and testing, and requirements and feedback for certification and implementation.

**•** Expanding existing/developing new exchange services that include but are not li mited to the following:
o Registration/identity management (including identity proofing) ;
o Interoperate with vendor developed software (using standard protocols) ;
o Securely move data (including authentication, authorization, encryption and other security serv ices) ;
o Use designated system/services, which will needed to be modified/further developed for use by vendors, for exchanges subject to CROMERR ;
o Use data exchange services ( e.g. , archive, submit, query/solicit) ;
o Ensure valid data is provided by the vendor a pplication ;
o Provide transaction status/notifications ;
o Data transformation for use by ICIS

- NPDES if needed ;
o Aid in the distribution and exchange to ICIS

- NPDES ; and
o Help Desk support and coordination

.
**•** Performing collection

- specific testing (developing test c ases, performing testing, load testing, etc.) with each software provider

.
**•** Ensuring security controls, documentation, and agreements are in place.

**•** Coordinating moving from a t est environment to p roduction

.
**•** Annual operations and maintenance ( O&M ). EPA will need to implement these next steps to support implement ation of the NPDES Electronic Reporting Rule.
Once resources for this effort have been ide ntified, the OEI and OECA Third

- Party Software Provider Electronic Reporting Team will develop a work plan for moving forward on this effort.