Proof of Concept Demonstration for 

Electronic Reporting of Clean Water Act 

Compliance Monitoring Data

With Third-Party Software Providers

Final Report

Public Record for the NPDES Electronic Reporting Rule

EPA Docket Number EPA–HQ–OECA–2009–0274 (www.regulations.gov)

12 January 2012
2

TABLE OF CONTENTS 

Page

1.0 OVERVIEW..............................................................................................................................................3

2.0 SOLICITATION OF PROOF OF CONCEPT PARTICIPANTS.....................................................................................5

3.0 CONDUCTING PROOF OF CONCEPT - TWO-PHASED APPROACH........................................................................7

4.0 RESULTS OF PROOF OF CONCEPT TESTING....................................................................................................9

5.0 LESSONS LEARNED .................................................................................................................................12

6.0 NEXT STEPS ..........................................................................................................................................14

Appendices

A Proof of Concept Federal Register Notice

B Proof of Concept Checklist
3

1.0 OVERVIEW

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 quality 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 information 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 facilities has grown from 100,000 to 

close 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 transferring 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 of 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 Monitoring 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 NPDES 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 platform e-file’ electronic 

reporting option. The open platform e-file proof of concept demonstration focused 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 platform 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 purchase services from any provider. All financial 

transactions would be between the providers and members of the regulated community. EPA held 

several meetings with IRS to learn from their experiences (see DCN 0041).

If 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 providers would share these 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 platform e-file option, as EPA has authorized 46 states to manage the NPDES 

permit program. Full implementation of the open platform e-file option would require compliance with 

the Cross Media Electronic Reporting Regulation (CROMERR), 40 CFR 3, and any future requirements of 

the NPDES Electronic Reporting Rule. Participation 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 reporting of DMR data via a thirdparty software provider through CDX to EPA’s national database, the Integrated Compliance Information 

System National Pollutant Discharge Elimination System (ICIS-NPDES). The 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 proof of concept was conducted with software providers in the 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 potential future related data exchange projects. Additionally, participation in the proof 

of concept was voluntary and EPA did not provide any funds to the providers for their participation. 

Finally, EPA did not use this proof of concept or its results to endorse the commercial products or 

services from any of the participants. 

This report provides a summary of this effort, lessons learned, and next steps for fully

implementing an EPA open platform e-file option.
5

2.0 SOLICITATION OF PROOF OF CONCEPT PARTICIPANTS

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. Additional information 

was provided via webinars. EPA used the providers’ orientation webinar to provide information on the 

overall proof of concept effort (i.e., scope, schedule) and the specifics on the requirements for 

participating in the proof of concept. The orientation webinar was open to all interested software 

providers but was 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-governmental (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 Network web services that support the open platform e-file option.

• Technical 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 standards, 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 of the 

States (ECOS).

The technical proof of concept was open to all providers; however, EPA required that providers 

describe and provide examples of their work and technical experience in exchanging data, and their 

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 Message Transmission Optimization Mechanism 

(MTOM).
6

EPA required that the providers include in their letter of interest detailed information on the 

following items to illustrate their experience in meeting the requirements identified above:

• Connecting using https

• Submitting files to an EPA Node using the published WSDL

• Supporting Trading Partners in Exchange Network data exchanges using Node 2.0 specifications

• Generating data in XML format

• Operating schema validation tools

• Parsing XML files

• Gathering and storing DMR data from facilities

• Providing monthly DMR data in an electronic format

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

• Checking the submission status with CDX, and download processing results from CDX

• Generating 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 reviewed these written submissions and identified the providers that generally met EPA’s 

eligibility requirements for participation in the technical proof of concept. EPA determined 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 permit 

program (see previous paragraph). Based on these written submissions EPA identified five providers and 

notified them of their acceptance for the proof of concept. Three of the providers used Microsoft .NET 

Framework (pronounced dot net) to develop their 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 CONDUCTING PROOF OF CONCEPT - TWO-PHASED APPROACH

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 providers’ 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, software providers were given a twohour training session by ICIS-NPDES staff and provided with sample limits in ICIS-NPDES along with 

relevant ICIS-NPDES documentation, such as:

• The ICIS-NPDES Batch User Guide,

• An example XML Instance Document,

• The Data Exchange Template,

• The DMR reporting technical specifications, and

• Expected DMR schedule 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-seasonal 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 reported 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) parameters 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 duration 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 RESULTS OF PROOF OF CONCEPT TESTING

All five software providers passed the Exchange Network connectivity 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 asked for two week extension.

Provider 2 Yes

Provider did not provided the necessary artifacts 

to prove they met the criteria.

Provider 3 Yes

Provider 4 Yes

Provider 5 N/A Provider did not participate in Phase 2.

Software Provider 1

Status: Partly Complete.

Summary: Software Provider 1 claimed to have submitted files that passed CDX validation but was

unable to successfully load any files into ICIS.

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

notes that this provider did not complete the following items on the proof of concept checklist:

• Provider tool can generate an XML file of DMR data in the format required by the ICIS schema.

• Provider tool can generate an XML file containing valid monthly DMR data according to the business rules 

specified 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, 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 for multi-seasonal 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 monthly, 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 unscheduled 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 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 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 provided 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 change, 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 parameters for one or more sewage treatment plants being reported for one or more 

permitted facilities.

Software Provider 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 Provider 4

Status: Complete.

Summary: Software Provider 4 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. 

Software Provider 5

Status: Incomplete, did not fully participate 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 notes 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 LESSONS LEARNED

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 proof 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 learning 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 DMRs

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

DMR-related technical specifications describing how ICIS-NPDES would 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

understanding how to build an XML file for submission. However, there were problems with the 

software vendors understanding the criteria checklist. Most 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 an 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 also 

found it valuable to copy all participants on any email responses to the original requestor, ensuring 

all software providers were dealt with fairly.

• The final lessons learned from the ICIS-NPDES Team were the differences in assistance needed to 

participate 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 less 
13

assistance and explanations than the others. However, providers with limited 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, 

focus on key parts of the specifications, protocols, and flow configuration document (FCD). While 

several of the providers were able to review the specifications and the FCD to determine what was 

needed to connect, use the services, and pass the correct parameters to submit DMRs, 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 completed 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 software interface. 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 

connecting 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 from 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 messages. These messages 

required MTOM. EPA noted that these 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. Only one 

of the providers had a commercial interface developed at the time of the 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 would 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 NEXT STEPS 

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

the concept into production. Additional funding and FTE resources will be required to pursue the open 

platform e-file electronic reporting option and take the concept from 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 electronic 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) 

and 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 providerdeveloped software for other EPA program areas in the near 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,

• Developing test plan,

• Developing test cases,

• Performing testing,

• Performing CDX testing,

• Performing load testing,

• Supporting beta, UVT, and UVA testing,

• Implementation,

• Operation and Maintenance (O&M), and

• Participating with OEI in the governance process and coordinating with vendors.

OEI would require additional funding to develop the services within CDX to be leveraged by 

provider-developed software for compliance and program reporting and set up the governance for use 

of these services. Specifically OEI would utilize 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 development 
15

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 limited 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 services);

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 application;

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 cases, performing testing, load testing, 

etc.) with each software provider.

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

• Coordinating moving from a test environment to production.

• Annual operations and maintenance (O&M).

EPA will need to implement these next steps to support implementation of the NPDES Electronic 

Reporting Rule.

Once resources for this effort have been identified, the OEI and OECA Third-Party Software 

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