RCRAInfo
From Exchange Network Wiki
INTRODUCTION / BACKGROUND
RCRAInfo is EPA's comprehensive information system, providing access to data supporting the Resource Conservation and Recovery Act (RCRA) of 1976 and the Hazardous and Solid Waste Amendments (HSWA) of 1984. RCRAInfo replaces the data recording and reporting capabilities of the Resource Conservation and Recovery Information System (RCRIS) and the Biennial Reporting System (BRS).
The RCRAInfo system enables cradle-to-grave waste tracking of many types of information regarding the regulated universe of RCRA hazardous waste handlers. RCRAInfo characterizes facility status, regulated activities, and compliance histories in addition to capturing detailed data on the generation of hazardous waste from large quantity generators and on waste management practices from treatment, storage, and disposal facilities.
RCRAINFO HISTORY
RCRAInfo is currently at Version 4 (released December 15, 2008). RCRAInfo replaced two legacy systems, RCRIS and the Biennial Reporting System (BRS). Each subsequent version of RCRAInfo has implemented a number of recommendations that were formulated by an EPA/State partnership. This partnership has helped ensure that RCRAInfo continues to support the state’s as well as EPA’s core business needs.
RCRAInfo has been developed in a modular fashion, with each module being separate, yet all connected to the Handler ID. RCRAInfo consists of 7 modules:
- Handler: The Handler Module is the starting point for all information about hazardous waste handlers entered into RCRAInfo. The Handler Module is currently available for Exchange Network Flows.
- Compliance Monitoring and Enforcement (CME): EPA and State personnel maintain RCRA regulation compliance evaluation, violation, and enforcement action information for hazardous waste handlers in RCRAInfo with the CME Module. The CME module is currently available for Exchange Network Flows.
- Corrective Action (CA): The RCRAInfo CA Module is used to track the specific corrective action information needed to regulate facilities found to have hazardous waste releases. The Exchange Network Flow for CA will be released as part of Version 5.
- Permitting: The universe in RCRAInfo which includes all units that are or were at some time required to obtain a RCRA permit to operate as a TSD. This module is designed for reports to track accomplishments in the permitting, closure, and post-closure areas. The Exchange Network Flow will be released as part of Version 5.
- Financial Assurance (FA): The Financial Assurance Module assures that the owner operator will have the financial resources to close a treatment or disposal facility properly. The Exchange Network flow for the FA module will be released as part of Version 5.
- Geographic Information System (GIS): The Geographical Information System (GIS) Module was created to enhance RCRAInfo spatial data tracking of location coordinates at the facility, permit unit, and corrective action (CA) area level. The module also stores acreage data that will be used to track cross-program land revitalization efforts. The Exchange Network Flow for the GIS Module will be released as part of Version 5.
- A separate set of tables also exist to support the Biennial Reporting process. This module is referred to as the Waste Activity Reporting (WAR) module.
EXCHANGING DATA WITH RCRAINFO
The RCRAInfo Network Exchange provides data services used by trading partners to submit data to RCRAInfo. Data is submitted by authorized states to EPA to meet Program requirements. RCRAInfo Data services are provided through the Exchange Network and accessed through CDX (Central Data Exchange). RCRAInfo V4 supports both Node 1.1 and Node 2.0 of the EN Web Service node specifications.
RCRAInfo is designed as a node-to-node data exchange. States may use either a full network node or a node client to submit data to EPA. Currently EPA only supports a ‘push’model for sending data to EPA. EPA does not currently support the ability for EPA to query or solicit data from State systems.
In order to submit data to EPA, States must comply with the RCRAInfo XML Schema, and meet all of the relevant RCRAInfo business rules. Validation of submittals is a two-step process:
- A submitted file is validated against the RCRAInfo Schema
- A submitted file is validated against the RCRAInfo business rules
For those states who have not yet developed the ability to generate/submit XML files, EPA also offers an alternative method for submitting data to EPA. States may generate flat files that meet the RCRAInfo flat-file specifications defined in the RCRAInfo Translator Guide. For more information on submitting flat-files, see How do I get started for Flat-File submissions
HOW DO I GET STARTED / WHO DO I CONTACT?
How Do I Get Started for XML Submissions
Step 1. Get a RCRAInfo ID
- Please contact your state representative to acquire a 3-character RCRAInfo ID. State representatives can be found under Contact Lists under the RCRAInfo Main Menu under the link News Alerts and General Information. Please contact Dwane Young if you are still not able to locate your State Representative.
- Once a user registers for the 3-character RCRAInfo User ID and an Exchange Network NAAS (Network Authentication and Authorization Service) account, they should contact the CDX Node Help Desk and request that their RCRAInfo ID be associated with their Exchange Network NAAS ID.
- Once all of these accounts are established, contact your Regional System Administrator to receive the necessary permissions on the modules (i.e. Handler, CME) that you want to submit data for. You will also need to contact the RCRAInfo team to receive the necessary privileges to ‘translate’ data.
Step 2. Become familiar with the XML schema
- See the TOOLS AND RESOURCES for more information on tools that are available to assist you in understanding the RCRAInfo schema.
Step 3. Testing your XML Submission
- Start with small file sizes to ensure your XML mapping is correct
- Test the schema by using the schema validation tool located at http://tools.epacdxnode.net/
- XML files must be compressed (i.e. zipped) when sent via the CDX node.
- Be mindful of how you populate the Header in your XML document. In the Header is where you specify your 3-character RCRAInfo ID, the State for which you are submitting data, and any relevant notifications (people who you’d like to have receive an email when the submittal either succeeds or fails). See the FREQUENTLY ASKED QUESTIONS about Notifications for more information about how to set-up the Header so that RCRAInfo will send out notifications upon completion.
- Submit the file to Pre-production. EPA maintains both a testing and a production environment. The two environments are identical, and the testing environment is meant to provide an area where states can test their submittals. In order to submit to pre-production, use the following endpoint: https://testngn.epacdxnode.net/cdx-enws10/services/NetworkNodePortType_V10
If you pass both the schema validation and the business rules (i.e. your file returns with a status of ‘Completed’) then you are ready to submit to production.
Step 4. Submit to Production
- Depending on whether or not you have submitted to RCRAInfo before, you may need to have CDX give your NAAS account privileges to submit data to RCRAInfo production. You can do this by contacting the CDX Node Help Desk.
- Submit the compressed XML file to RCRAInfo. For production, use the following endpoint:
https://cdxnodengn.epa.gov/cdx-enws10/services/NetworkNodePortType_V10
- If you used notifications, you should receive an email updating you on the status of your submissions. Otherwise, you can call the Get Status and Download services to get the status of your submission and download any relevant error reports. As a third alternative, you can also log into RCRAInfo and view the error reports there. EPA also recommends that you log into RCRAInfo to ensure that your data are being loaded correctly.
Who Do I Contact?
Dwane Young - RCRAInfo Data Flow EN Lead for XML Submissions Email – young.dwane@epa.gov Phone Number (703) 347 – 8578
How Do I Get Started for Flat File Submissions
Step 1 Get a RCRAID
- As in the case of XML submissions please contact your please contact your state representative to acquire a 3-character RCRAInfo ID. State representatives can be found under Contact Lists under the RCRAInfo Main Menu under the link News Alerts and General Information. Please contact Idali Gotay if you are still not able to locate your State Representative.
Step 2 User Access and Permissions
- Users must have the following access and permissions to successfully submit flat files to RCRAInfo:
- User ID and password for the RCRAInfo production application
- Must be granted the translation role within the database
- Must have Level 4 (read, add, update, and delete) permissions for the module being submitted.
- Be the implementer of record for the information being submitted.
Step 3 Flat files transfer to Production
- Flat files are transferred to the RCRAInfo Database via the RCRAInfo application. The data is transferred in the form of ZIP files. The RCRAInfo Flat File transfer process extracts the files from these ZIP files and stores the data in the Oracle database ‘staging’ tables for further processing.
- Before the file is uploaded, the RCRAInfo interface will validate the zip file name by the following criteria:
- The first 3 characters are the Program abbreviation: RCR
- The next 4 characters are program specific: 2 – Letter state abbreviation followed by the submission number (e.g. MD01)
- The last 3 characters are the TSSMS ID of the user submitting the files.
Who Do I Contact
Idali Gotay - RCRAInfo Data Flow Lead for Flat File Submission Email – gotay.idali@epa.gov Phone Number (703) 308 – 0512
TOOLS AND RESOURCES
- Updated DET (Data Exchange Template)
- Link [Http://exchangenetwork.net/exchanges/waste/rcra.htm http://exchangenetwork.net/exchanges/waste/rcra.htm]
- The DET is a companion to the Translator Guide. It has the business rules and data elements for the schema in an abbreviated format.
- FCD (Flow Configuration Document)
- Link http://exchangenetwork.net/exchanges/waste/rcra.htm
- Document defining the data services as well as the approaches and processes that are used to exchange information.
- Translator Guide
- The Translator Guide has the flat file specifications necessary for translation to RCRAInfo. The business rules in the Translator Guide enforce data quality validation rules.
- Example XML Files
- Link http://exchangenetwork.net/exchanges/waste/rcra.htm
- EPA has provided an example V4 Handler and V4 CME XML file to assist states in understanding the RCRAInfo schema.
FUTURE PLANS FOR RCRAINFO
EPA has identified several key areas to focus on over the next several years. Primarily, EPA will focus on completing the RCRAInfo schema development (i.e. develop schemas for all RCRAInfo modules). EPA is also expecting a new release of RCRAInfo (version 5) early in 2010. EPA is also committed to developing a series of web services that will allow for better access to data in RCRAInfo. Several states have expressed a strong desire to have outbound web services developed that would help with the management of the data at the state level, and to ensure that the data are consistent between the states and EPA. Several different types of web services have been identified. These services would need some additional evaluation and scoping. EPA has identified the following types of services as possible new web services to add to RCRAInfo:
- Generate RCRA ID service: This service would auto-generate a RCRAID for the assignment of an ID to any given Handler.
- Data syncing services: These services provide for the ability to sync data between RCRAInfo and the state systems (i.e. download any Region entered data). There are two possible approaches for achieving this. The first approach would be to develop services that would provide all of the data based on a provided change data. The other approach would just provide the ‘key’ information based on a provided change date.
- Data Catalog Services: These services provide summary information on what data are available to allow for a user to browse data and discover data at a higher level to better guide a user in the particular data that they are interested in.
- EnviroFacts/Public web services: These services provide public access to the data (similar in data types and elements as to those currently available via EnviroFacts).
- Outbound publishing for Direct RCRAInfo users: These services would allow for direct users (i.e. states) to query the database and receive the data via an outbound web service.
Geographic based querying has been identified as an important consideration for all of these services.
RCRAInfo Exchange Network Component Schedule
RCRAInfo Exchange Network Component Schedule
| Milestone | Target Completion Date |
| System Readiness for V4 Handler and CME | Completed |
| System Readiness for V4 Corrective Action, Permitting, GIS, and Financial Assurance Data | Completed (03/2010) |
| Schemas available for evaluation for Handler for V5 | Completed (11/2009) |
| System Readiness for testing V5 | Completed (01/2010) |
| System Readiness for XML Translation for V5 | Completed (03/2010) |
| Begin Web Services evaluation | 10-May |
| Initial Web Services Implementation | 10-Oct |
| Web Services Testing / Evaluation | November 2010- March 2011 |
| Final Outbound Web Services | 11-Sep |
| | |
| |
FREQUENTLY ASKED QUESTIONS (FAQs)
Q. When do you use Flat file versus XML Translation? When do you use the RCRAInfo flat file translation versus the Exchange Network?
A. It is at the discretion of the user whether they choose to use XML versus Flatfile transmissions. XML transmissions require a more robust technical architecture and the user must go through the CDX node for their transmission. XML submissions will provide a state with more flexibility in how to share data and allow for the process to be automated. XML submission also allow for the submittal to be contained within one file, as opposed to being a group of separate files. States should be aware, however, that there is a significant technical hurdle in developing the capability to generate XML files.
Q. What are the benefits of using XML over the Flatfile process?
A. There are many benefits of using XML over the Flat File process. Using XML helps in the re use of the Data standards. The user does not have to include all of the data elements because the data elements and those elements are in XML are re usable and are self describing. Also, using XML allows for faster processing of data leading to overall higher customer satisfaction and yields better data quality and higher performance.
Q. What are some of the differences between submitting data as XML versus submitting data as Flat Files?
A. Because XML is meant to be stand-alone and self describable, there are a number of differences between how the data are structured in XML versus flat files. Within RCRAInfo, some of the major differences are:
- When using XML, the child data element inherits the unique key or identifier from the parent so that key does not have to be repeated from one table to the next.
- With XML you submit 1 file as opposed to multiple related files. The relationships between the data in the XML are inherent to the XML structure.
- Flat files require you to provide the entire length of the data element. For example, if the data element allows 80 characters, you must provide all 80 characters even if you’re only using 5 characters. XML does not require this.
- Flat files require you to consider all of the data elements in the flat file specification. At a minimum you have to at least include empty spaces for the data elements, even the ones you don’t use. XML doesn’t require this. If you don’t use the data element, XML doesn’t require you to provide it. This is important in that if the RCRAInfo structure changes, you MUST always change your process to match RCRAInfo. For XML, you only have to change your structure if you’re including those new data elements. (Keep in mind that you are still subject to the RCRAInfo business rules so your submission will still fail in XML if you don’t provide the necessary fields.)
For examples of these differences, please see the XML schema in Exhibit 1.1 for the Handler Module. This XML schema is highlighting how to submit Facility Owner/Operator information, and shows how you would include two new entries for Facility Owner/Operator.
As you can see below, the key data elements such as Handler ID, SourceTypeCode, SourceRecordSequenceNumber only have to be included once in the Handler data block. The FacilityOwnerOperator data block, being a child of Handler, inherits this key information. In flat files, this key information must be repeated in each file, and for each record.
Also, unlike the Flat Files, when using XML, we do not have to be concerned with the limitation of having the starting position and the ending position for each of the date elements. Rather using the XML schema format allows the user to use more of a ‘free flow’ format as long as all of the XML schema rules are being followed.
For the purposes of this illustration, we are showing an excerpt of a file developed in both XML and Flat File format to demonstrate some of the differences between the two (for the sake of space, not all of the data are shown. The marks ‘…..’ indicate where other data exist in the XML schema that are not shown).
Exhibit 1.1 a submittal as an XML file
<RC:FacilitySubmission>
<RC:TransactionCode>A</RC:TransactionCode>
<RC:HandlerID>KSR00054DEMO</RC:HandlerID>
<RC:PublicUseExtractIndicator>X</RC:PublicUseExtractIndicator>
<RC:Handler>
<RC:ActivityLocationCode>KS</RC:ActivityLocationCode>
<RC:SourceTypeCode>N</RC:SourceTypeCode>
<RC:SourceRecordSequenceNumber>1</RC:SourceRecordSequenceNumber>
<RC:ReceiveDate>2008-11-03</RC:ReceiveDate>
<RC:HandlerName>Waste Emporium</RC:HandlerName>
………
<RC:FacilityOwnerOperator>
<RC:TransactionCode>A</RC:TransactionCode>
<RC:OwnerOperatorSequenceNumber>1</RC:OwnerOperatorSequenceNumber>
<RC:OwnerOperatorIndicator>CO</RC:OwnerOperatorIndicator>
<RC:OwnerOperatorTypeCode>P</RC:OwnerOperatorTypeCode>
<RC:CurrentStartDate>1998-01-01</RC:CurrentStartDate>
<RC:ContactAddress>
<RC:Contact>
<RC:FirstName>Bob</RC:FirstName>
<RC:LastName>Brown</RC:LastName>
<RC:EmailAddressText>BobB@zzz.com</RC:EmailAddressText>
<RC:TelephoneNumberText>5055552222</RC:TelephoneNumberText>
</RC:Contact>
<RC:MailingAddress>
<RC:MailingAddressText>2345 123RD Road</RC:MailingAddressText>
<RC:MailingAddressCityName>Sabetha</RC:MailingAddressCityName>
<RC:MailingAddressStateUSPSCode>KS</RC:MailingAddressStateUSPSCode>
<RC:MailingAddressCountryName>US</RC:MailingAddressCountryName>
<RC:MailingAddressZIPCode>66534</RC:MailingAddressZIPCode>
</RC:MailingAddress>
</RC:ContactAddress>
</RC:FacilityOwnerOperator>
<RC:FacilityOwnerOperator>
<RC:TransactionCode>A</RC:TransactionCode>
<RC:OwnerOperatorSequenceNumber>1</RC:OwnerOperatorSequenceNumber>
<RC:OwnerOperatorIndicator>CP</RC:OwnerOperatorIndicator>
<RC:OwnerOperatorTypeCode>P</RC:OwnerOperatorTypeCode>
<RC:CurrentStartDate>1998-01-01</RC:CurrentStartDate>
<RC:ContactAddress>
<RC:Contact>
<RC:FirstName>Bob</RC:FirstName>
<RC:LastName>Brown</RC:LastName>
<RC:EmailAddressText>BobB@zzz.com</RC:EmailAddressText>
<RC:TelephoneNumberText>5055552222</RC:TelephoneNumberText>
</RC:Contact>
<RC:MailingAddress>
<RC:MailingAddressText>2345 123RD Road</RC:MailingAddressText>
<RC:MailingAddressCityName>Sabetha</RC:MailingAddressCityName>
<RC:MailingAddressStateUSPSCode>KS</RC:MailingAddressStateUSPSCode>
<RC:MailingAddressCountryName>US</RC:MailingAddressCountryName>
<RC:MailingAddressZIPCode>66534</RC:MailingAddressZIPCode>
</RC:MailingAddress>
</RC:ContactAddress>
</RC:FacilityOwnerOperator>
……..
</RC:Handler>
</RC:FacilitySubmission>
Flat File
Below is an example of a flat file submission to translate the same information for the Facility Submission Block in XML per Exhibit 1.1 in the XML section above. In this example, notice how the exact field positions must be followed for each of the Flat File submissions. Also, when using Flat File you do not have the ability to inherit data elements from one submission to the next and therefore each of the primary keys must be repeated.
Exhibit 1.2 A submittal as a Flat File
Exhibit 1.2 for Flat File is displaying portions of the HANDLER Flat File (HD2) (Transaction Code, Handler ID, Source Type, Sequence Number, Extract Flag, Receive Date and Handler Name).
Note: In the case of Sequence Number, the Flat file is using leading 0s even though value is 1 in the XML schema. Since the Field Length is defined as 6 required characters, we need to have 5 Leading 0s preceding the Value of 1. As you can see, the Flat File format is less forgiving and requires the entire field to be populated with the required values whereas in XML having just the value of 1 for the Sequence Number is acceptable (**Note that the flat files are not delimited with a ‘|’ as shown below. This was added to this example to make it easier to see the different data elements. We’ve also used ‘_’ to represent spaces. Also, since the flat files are not self-describable, we’ve included numbers above the data that correspond with the description table below).
1 2 3 4 5 6 7 A|KSROOO54DEMO|N|000001|X|03112008|Waste Emporium_________________________
Flat File Details of Exhibit 1.1
| Field Name | Field No. | Starting Column | Field Length | Field Value | Comments |
| Transaction Code | 1 | 1 | 1 | A | |
| Handler ID | 2 | 2 | 12 | KSROOO54DEMO | Exact Position and Length required |
| Source Type | 3 | 14 | 1 | N | |
| Seq # | 4 | 15 | 6 | 1 | Even thought the actual value is 1, 5 leading 0s are required to fulfill the Field length requirement. |
| Extract Flag | 5 | 21 | 1 | X | |
| Receive Date | 6 | 22 | 8 | 3112008 | |
| Handler Name | 7 | 30 | 80 | Waste Emporium | The actual value for this field is 13 characters long whereas the Field Length is defined as 80. The ensuing field must start at the 110 position and the extra characters must be filled with spaces to accommodate the field length. |
| |
For a complete flat file submission we must include all of the relevant tables. For this example, we are showing the OWNER_OPERATOR Table (HD3) in Flat File format to allow users to compare it to the XML schema above in Exhibit 1.1 for XML. This example illustrates how each character must be in the exact correct position as notated by the Translator Guide. Notice how the unique fields such as Handler Id, Source Type, and Seq Number are repeated for each row.
1 2 3 4 5 6 7 8 9 10 11 12 A|KSROOO54DEMO|N|000001|0001|CO|BobBrown |P|19980101| |2345 |123RDRoad 13 14 15 16 17 18 | |Sabetha |KS|US|666534 | |
Flat File Details of Exhibit 1.2
| Field Name | Field No. | Starting Column | Field Length | Field Value | Comments |
| Transaction Code | 1 | 1 | 1 | A | |
| Handler ID | 2 | 2 | 12 | KSROOO54DEMO | Exact Position and Length required |
| Source Type | 3 | 14 | 1 | N | |
| Seq # | 4 | 15 | 6 | 1 | Even though the actual value is 1, 5 leading 0s are required to fulfill the Field length requirement. |
| Owner Operator Seq | 5 | 21 | 4 | 1 | Leading 0s required to fulfill field length requirement even though value is 1 |
| Owner Operator Indicator | 6 | 25 | 2 | CO | |
| Owner Operator Name | 7 | 27 | 40 | Bob Brown | The actual value for this field is 8 characters long whereas the Field Length is defined as 40. The ensuing field must start at the 67 position and the extra characters must be filled with spaces to accommodate the field length. |
| Owner Operator Type | 8 | 67 | 1 | P | |
| Date Current | 9 | 68 | 8 | 19980101 | |
| Ended Date | 10 | 76 | 8 | Blank | Even though there is no end date we must notate the blank date with empty spaces. |
| Street Number | 11 | 84 | 12 | 2345 | Even though there are 4 characters in this field, since our field length is 12 we must fill up the remaining 8 characters with spaces. |
| Street1 | 12 | 96 | 30 | 123RD Road | Even though there are 8 characters in this field, since our field length is 30 we must fill up the remaining 22 characters with spaces. |
| Street 2 | 13 | 126 | 30 | Blank | Unlike XML in Flat file even though a field is blank it still has to be filled with spaces. |
| City | 14 | 156 | 25 | Sabetha | Even though there are 7 characters in this field, since our field length is 25 we must fill up the remaining 18 characters with spaces. |
| State | 15 | 181 | 2 | KS | |
| Country | 16 | 183 | 2 | US | |
| ZIP | 17 | 185 | 14 | 666532 | Even though there are 6 characters in this field, since our field length is 14 we must fill up the remaining 8 characters with spaces. |
| Phone | 18 | 199 | 15 | Blank | Even though there is no phone number to fulfill the rules of Flat file we must notate the blank date with empty spaces. |
| |
Q. What are the differences between the various releases of RCRAInfo?
A. RCRAInfo is a regulatory system that changes when new rules and statues are introduced to the RCRA Program. Each subsequent version of RCRAInfo implements recommendations that were formulated by an EPA / State partnership. RCRAInfo started with Version 1 which replaced RCRIS and the Biennial Reporting System (BRS) with RCRAInfo). Version 2 was released in June 2002, and addressed PAA comments regarding the Site ID form, implemented the Waste Activity module, and began efforts on integrating with the Central Data Exchange. Version 3 implemented improvements to the Handler and CME modules as well as introduced a new feature called USITS (User Support Issue Tracking System) to track bugs and user questions. Version 4 implemented improvements to the Permitting and Corrective Action module; and introduced the Financial Assurance and GIS module. Version 5 will provide improvements to the Handler and Biennial Reporting modules, and implement rules that have been approved since the implementation of Version 4. In Version 5, there will be no changes to the CME schema. Version 5 of RCRAInfo will implement all of its modules, except for the Waste Activity Module, to allow for XML Translation.
Q. How does RCRAInfo handle communication and outreach so I can get more involved?
A. The RCRAInfo Team has set up some of the following communication channels to enable it’s stakeholders to get involved with the activities supported by RCRAInfo:
- IPT (Integrated Project Team) Calls
- Monthly Calls to update the EN community on RCRAInfo. Point of contact is Dwane Young.
- Change Management
- Team responsible for managing all of the communication issues related to RCRAInfo. Point of contact is Debbie Goodwin
- RCRAInfo Conference
- The next RCRAInfo Conference will be in March 2010 in San Diego California. EPA is soliciting a ‘Call for Papers’ for users interested in presenting at the Conference. Stay tuned for further information and a Conference Registration Web Page.
- List Serve
- Primary means of email communication for the RCRAInfo community to participate in RCRAInfo discussions. To register for the List Serve send a blank message to RCRAInfoList-subscribe@lists.epa.gov. Once you are registered you will receive a Welcome Message.
- National Monthly Data Calls
- Monthly Data calls to cover general RCRAInfo business and issues. Point of contact is Debbie Goodwin.
Q. What are the types of Translation methods and what are the differences between them?
A. There are 3 Translation Methods that are described below.
- Full Replacement
- The full replacement method deletes all data (including child records in RCRAInfo) for the specified module for that state and replaces it with the data in the current submission.
- Partial Replacement
- The partial replacement method is similar to the full replacement method in that data is deleted from both parent and child tables, however, with the partial replacement method only the data associated with that Handler Id is deleted.
- Transactional Method
- Unlike the partial and full replace methods, the transactional replace method enables the user to change (Add or Delete) data in a transactional manner one record at a time.
The Translation methods that are supported for each of the Modules vary depending on the RCRAInfo Module in question. The chart below describes in detail each of the operations that are supported for each of the Modules in RCRAInfo. For the newer modules that are being introduced for XML translation in Version 5 (Permitting Module, Corrective Action, Geographic Information System, and Financial Assurance), only the Transactional Method will be supported for translation.
| Module Parameter | Module Name | Operations Supported |
| HD | Handler | RCRA-FullReplace |
| | | RCRA-FullReplaceByHandler |
| | | RCRA-Transactional |
| CE | Compliance Monitoring and Enforcement | RCRA-FullReplace |
| | | RCRA-FullReplaceByHandler |
| | | RCRA-Transactional |
| PM | Permitting | RCRA-Transactional |
| CA | Corrective Action | RCRA-Transactional |
| GS | GIS | RCRA-Transactional |
| FA | Financial Assurance | RCRA-Transactional |
| |
Q. How Do I Get Error Reports for RCRAInfo Data Submissions?
A. There are 3 of the following methods to retrieve error reports:
- Download
- Use the Exchange Network ‘Download’ method to retrieve error reports from CDX. Email
You can have the error reports be available in your email box. The capability also exists for users to be notified via email.
- RCRAInfo
By logging into RCRAInfo, a user can view the error report for their most recent submission. RCRAInfo keeps only one error report at a time, and you will only see the error report for the most recent submission that you made.
Q. Why don’t I see my data after what I believe is a successful submittal?
A. You must wait for the universe calculators to run before a message will appear. These universe calculators run every 3 hours.
Q. Does my data have to be 100% correct before the submittal will be successful?
A. Yes. RCRAInfo functions as an All or None data flow. Any errors in the submittal will result in the entire submittal to fail and none of the data will be loaded.
Q. What is an IOR?
A. An IOR is an ‘Implementer of Record’. It is the term used to describe the agency (EPA or State) responsible for the data entry and management of the RCRA handler identification and program activity data.
Q. How do I receive Notifications?
A. RCRAInfo allows a user to specify who will receive notifications upon completion of the data loading process. There are two methods you can use for this, and which one you use depends on whether you are a Node 1.1 state or a Node 2.0 state. For Node 1.1 users, add the following property to your Header:
<hdr:Property> <hdr:name>notificationURI</hdr:name> <hdr:value>MyEmail@epa.gov</hdr:value> </hdr:Property>
- You will of course change the address to be the email address that you want to have the notification sent to.
For Node 2.0 users, the Header is not used for Notification, rather you use notificationURI parameter from the Node 2.0 specification. The notification type is intended to only send notifications for specific types of events such as errors or warnings. Please note that CDX will ignore any value specified in this attribute. Notifications will be sent to the email address specified, regardless of success or failure.
Q. How do I specify whether my submission is a Full, Partial, or Transactional translation?
A. Within the submittal file, there is an ‘Operation’ attribute that is part of the ‘Payload’ element. Depending on which type of translation you’re doing, provide the following: For Transactional: <hdr:Payload Operation="RCRA-Transactional|HD"> For Full Replace: <hdr:Payload Operation="RCRA-FullReplace|HD"> For Partial Replace: <hdr:Payload Operation="RCRA-FullReplaceByHandler|HD">
- Note that the ‘HD’ signifies that this submission is for Handler. If you’re doing a CME submission, replace ‘HD’ with ‘CE’. In similar fashion, for each submission that is being translated, the Payload Element needs to be updated respective to each of these modules. For example, for a Financial Assurance submission you will use FA, for a Permitting submission you will use PM and continue to follow the same method for the rest of the modules.
Q. As one of the states who will be translating data in Version 5 how can I prepare myself for Translation once V5 is released?
A. Translators should familiarize themselves with the document RCRAInfo Version 5 Schema Changes where all of the new schema changes are identified. This document can be found on the link http://exchangenetwork.net/exchanges/waste/rcra.html. This document provides in detail, the comparison of what data elements will be changed from Version 4 to Version 5 in RCRAInfo.
There will be updates on what the translators need to do to prepare for Version 5 via the RCRAInfo News Alerts to instruct users how to prepare for the submitting their data in RCRAInfo Version 5.
In addition, to prepare for the Version 5 schemas, the Translators can begin to take the following actions:
- Begin mapping to Version 5 schemas by referencing the Schemas for each of the modules found on the exchangenetwork.net Website.
- During the test period, begin testing their submittals and understanding the error reports they receive.
- Participate in the IPT calls. The IPT calls are held the first Monday of every month at 12:00 pm Eastern Time. Please contact Dwane Young if you are interested in participating in these calls.
Due to the new Definition of Solid Waste and the new Laboratory Rule, there are new groups of data elements that can be provided by states that are authorized to implement these Rules. If your state has not been authorized to implement these new Rules, then your state should not include these data elements.
The groups of data elements that are required for states to include only if they have been authorized are the following:
- Hazardous Secondary Material
- Provide these elements only if the facility is declaring that they have managed Hazardous Secondary Material as an initial notification or as a re-notfication as defined under DSW Rule, or if the facility has been operating under these alternate regulations, but is now choosing not to.
- Laboratory Hazardous Waste (CFR 262 SubPart K)
- Required only if a state is authorized for SubPart K and the facility is either opting into or out of SubPart K. If neither of these cases are true, then this data block is not required.
Q. What standard is RCRAInfo using for the GIS module? What are the advantages to using this new schema and what features does it have?
A. For the Version 5 Release of RCRAInfo, we will be implementing the GeoRSS GML (Geographic Markup Language) which is embedded in the XML schema for the use of exchanging geographic information.
GeoRSS has emerged as a defacto standard to provide a basic approach for encoding basic geographic information in RSS (feeds, blogs, etc.) and other web applications. EPA selected GeoRSS because it provides a balance of simplicity and features that match typical Exchange Network schema content and also supports the current RCRAInfo Data structure. The RCRAInfo Version 5 GIS schema will support basic geometries such as handlers with points, lines and polygons.
One of the main advantages of using GeoRSS is that in our future implementation of Web Services, users will be able to leverage standard mapping technologies to display their Handler on a map.
Below we will give examples of how to use GeoRSS in the RCRAInfo Schema. See the RCRAInfo example files found on the ExchangeNetwork.net website for a complete example of the schema.
Points
Points are used when you choose to define a single point for the Handler. The coordinates must be in the order of latitude followed by a longitude. Below is an example of a Point submittal using GeoRSS in the XML Schema.
<georss:where> <gml:Point> <gml:pos>39.7759 -99.3289</gml:pos> </gml:Point> </georss:where>
Polygons
Polygons are used to define the entire boundary of the Handler area or unit. Below is the code that defines the polygon portion of the XML schema and the format that the Polygon schema uses. For all polygons, the first and the last coordinate MUST be exactly the same. The points in between define the vertices along the boundary of the polygon.
<georss:where> <gml:Polygon> <gml:exterior> <gml:LinearRing> <gml:posList>39.7744 -99.3364 39.7724 -99.3222 39.7789 -99.3310 39.7763 -99.3372 39.7744 -99.3364</gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </georss:where>
It should be noted that the coordinate pairs must also be provided in the order that they would be drawn.
