»EPA
United States Environmental Protection Agency
MTS New Chemical Submission
System Requirement Specification Model
Report
July 2008
-------
Table of Contents
Chapter 1: Introduction 5
1.1 BACKGROUND 5
1.2 OVERVIEW 8
1.3 SYSTEM SCOPE 14
1.4 DEFINITIONS 19
1.5 REFERENCES 22
Chapter 2. User Perspective 23
2.1 USERS RELATIONSHIPS 23
2.2 ACTORS AND ASSOCIATED FUNCTIONALITY 24
MTS General User 24
MTS System Administrator 24
CBITS 25
NCS Application Administrator 25
Auditor 26
User Fee Processor 26
Mail Clerk 27
System Clock 28
Inventory Administrator 28
Inventory Chemist 29
Submission Processor 29
EPMN Lotus Notes 30
FMD 31
Quality Assurer 31
Prescreener 32
Archival Location (FR-RMR) 33
Submission Reviewer 34
Chemist & ACCELRYS 34
TDTS 35
CDX 35
Chapters. Process Flows 36
3.1 USE CASES 36
3.2 MODULES 50
Audit 50
Audit Non-Network Submissions 53
DCN Generation 55
Generate DCN 64
Process Consolidated Submission DCN 67
Generate Acknowledgement Letter 70
Modify Section 5 Submission 71
Interfaces with Other Systems 72
Search for Chemical Structure 85
Import Data from EPMN Lotus Notes 86
Obtain Files from EPMN Lotus Notes 87
-------
Import Submitter Information 88
Import User Fee Information from CBITS 89
Get User Fee Information from FMD 90
Identify Data for TDTS 91
Obtain Data from TDTS: 93
Mail Management 98
Capture Incoming Network Mail 104
Send Copy of Network Submission through CDX 107
Capture Incoming CD Mail 108
Capture Incoming Paper Mail 110
View Edit Incoming Mail Information Ill
Capture Outgoing Mail Information 113
Capture Email Log 116
Send CBI Email through CDX 118
View Edit Outgoing Mail Information 119
Review Undelivered Mail 121
MTS Access 122
Access MTS 124
Logout MTS 126
Prescreening 128
Prescreen Paper Submission 133
Prescreen Electronic Submission 135
Process Incomplete or Replaced Document 138
Capture Communication Log 139
Quality Assurance 143
Perform Quality Assurance Check 146
Perform Validation Check on Barcodes 148
Reports 149
Generate Predefined Reports 152
Submission Processing 154
Transfer Document to NCIC 162
Pickup Document 164
Review Case File 165
Retire a Paper Submission 167
Retire Electronic Submission 169
Unretire a Case File 171
Maintain Violations 174
Submission Scanning 176
Scan Submission 179
View Edit Submission 181
Submitter Management 183
Process Submitter in Incoming Mail 188
Add Submitter Information 189
Maintain Submitter Information 191
Support Document 193
Process Support Document 199
-------
Process Replacement Support Document 202
Submit Internal Support Document 204
Scan Support Document 207
Modify Support Document 209
System Administration 211
Assign Document Status 218
Change Document Status 220
Change Year 222
Delete Information 223
Maintain Lookup Table Information 226
Obtain Help 229
Query Last Sequential Number Used 230
Reprint Barcode 231
User Administration 233
Add MTS User 234
User fee Management 236
Associate User Fee Information 244
Complete User Fee Information 246
Determine Need to Refund User Fee 248
Edit User Fee Information 250
Process User Fee Refund 252
Query User Fee Status 254
Workload Assignment 256
Capture Workload Information 259
-------
Chapter 1: Introduction
1.1 BACKGROUND
The Environmental Protection Agency's (EPA's) New Chemicals Program, located in the Office of
Pollution Prevention and Toxics, was established to help manage the potential risk from chemicals new to
the marketplace. It is mandated by Section 5 of the Toxic Substances Control Act (TSCA). TSCA,
enacted by Congress in 1976, gives EPA broad authority to identify and control substances that may pose
a threat to human health or the environment.
The New Chemicals Program functions as a "gatekeeper" which can identify conditions, up to and
including a ban on production, to be placed on the use of a new chemical before it is entered into
commerce. Anyone who plans to manufacture or import a new chemical substance for a non-exempt
commercial purpose is required by Section 5 of TSCA to provide EPA with notice before initiating the
activity. This premanufacture notice, or PMN, must be submitted at least 90 days prior to the manufacture
or import of the chemical.
EPA classifies chemical substances as either "existing" chemicals or "new" chemicals. To determine if a
substance is a "new" chemical, EPA's TSCA Chemical Substance Inventory — commonly referred to as
the Inventory, which lists "existing" substances is consulted. Any substance that is not on the TSCA
Inventory is classified as a new chemical. Prior to manufacture or import of a new chemical for general
commercial use, a notice must be filed with EPA under Section 5 of TSCA. Some new chemical
substances are not subject to PMN reporting. These substances are either (1) excluded from TSCA
reporting or (2) exempt from all or part of PMN reporting because EPA has determined that they do not
warrant review or require only a short review. EPA has limited or no reporting requirements for new
chemical substances in the following cases:
• Low Volume Exemption (LVE)
• Research and Development
• Low releases and low exposures (LOREX)
• Test marketing (TMEA)
• Polymer.
PMN submissions require all available data on chemical identity, production volume, byproducts, use,
environmental release, disposal practices, and human exposure. If the identity of some reactants for
substance synthesis, or of the substance itself is unknown to the manufacturer, a Letter of Support can be
used to enable the Agency to have full identity information.
EPA also requires that the following information be submitted with the PMN:
• All existing health and environmental data in the possession of the submitter, parent company, or
affiliates, and
• Description of any existing data known to or reasonably ascertainable by the submitter.
-------
Information frequently requested by the New Chemicals Program for chemicals of commonly
submitted types is identified in the Chemical Categories document. All of this information is
considered by Agency risk assessors to determine whether the likely risk is unreasonable.
The Program can require submission of any additional data, including development of data through
testing, when the information included with the PMN, coupled with that available to its risk reviewers
from internal archives is not adequate to clarify for them whether the likely risk is unreasonable. The
Instruction Manual for Premanufacture Notification of New Chemical Substances explains all
reporting requirements. When a PMN form is requested, the instruction manual is included.
Once a PMN is received by EPA, the following diagram shows what happens to it:
FR Notice announcing
receipt by EPA
_ _
^X s^^^\
icomplete \ / Invalid \
MN ) V. PMN )
Regulatory
Determination
Made
No Action Taken
Action Taken
SNUR/Consent
Order
New Chemical exposure
Limit (NECL)
Boilerplates
Almost 90 percent of PMNs submitted to EPA complete the review process without being restricted or
regulated in any way. However, EPA may issue a TSCA Section 5(e) Order to prohibit or limit
activities associated with the substance, if EPA determines that:
there is insufficient information to evaluate the human health and environmental effects of the
substance, and
-------
• that the substance may present an unreasonable risk of injury to human health or the
environment (the "risk-based" finding), or
• that the substance will be produced in substantial quantities and may be anticipated to enter the
environment in substantial quantities or there may be significant or substantial human
exposure (the "exposure-based" finding).
In practice, these Section 5(e) Orders are almost always issued as "Consent Orders" that are signed by
both EPA and the chemical manufacturer. Given the "insufficient information" finding, most Section 5(e)
Orders require the PMN submitter to develop and submit to EPA certain toxicity or fate tests before
exceeding a specified production volume ("test trigger") designed to allow sales of the chemical to
generate enough revenue to pay for the testing. Exposure-based Section 5(e) Orders consist primarily of a
requirement to conduct triggered testing (plus recordkeeping and "risk notification" in case the test data
indicates a risk.) Risk-based TSCA Section 5(e) Orders, depending on the type of concerns identified by
EPA for a given PMN substance, typically also require exposure controls such as gloves, goggles,
respirators, specified disposal technologies or restrictions on releases to water, and hazard communication
such as material safety data sheets (MSDS), labels, and training.
EPA currently uses an Oracle Forms based system called the Confidential Business Information System
(CBITS) that tracks metadata about all submissions, including Section 5 submissions. CBITS tracks the
information about the submission until it gets a document control number (DCN) that makes the
document official. Currently, for chemists to review the submission, they need to logout a copy of the
submission, review and return the copy to the Confidential Business Information Center (CBIC).
The Manage Toxic Substance (MTS) system will replace CBITS to not only track metadata about the
submission, but to actually capture and track the submission itself. Note that only the submissions that are
received and processed in MTS will be tracked in MTS. Selective data from CBITS will be transferred to
MTS at this time. Support documents for the original submissions tracked in CBITS will not be tracked
in MTS. These support documents will be tracked in CBITS, including related mail receipt information.
Another key difference between CBITS and MTS is that MTS will maintain a portable document format
(PDF) file that users can view electronically, hence eliminating the need for making paper copies of
submissions. This change provides EPA a significant savings in the cost of processing and maintaining
paper copies that had a potential of being misplaced.
This document describes the functionality provided by the NCS (New Chemical Submission) application
within MTS system. MTS and NCS are used interchangeably here.. This document only pertains to the
New Chemical Submissions portion of MTS as MTS has and will include processing of all submission
types eventually.
-------
1.2 OVERVIEW
MTS is a data warehouse for all submissions within the Office of Pollution Prevention and Toxics
(OPPT). It captures, tracks, and manages information about a submission and the submission document
itself.
New chemical submission processing by MTS can be organized into several modules. The table below
lists the modules with their descriptions:
Module Name Description
User Administration
MTS Access
Mail Management
Workload Assignment
Presceening
Submission Scanning
Submitter Management
Quality Assurance
DCN Generation
Userfee Administration
Submission Processing
Support Document
Interface with Other
Systems
Contains functionality to maintain MTS user information.
Contains functionality to access and logout from MTS.
Contains functionality that pertains to both incoming and outgoing mail.
This includes information about capturing mail information, sending copy of
network submissions to submitters, viewing returned mail, processing
outgoing mail, and processing email.
Contains functionality to select submissions to work on.
Pertains to functionality to review a submission before a DCN is generated.
This includes prescreening paper and electronic submissions, and processing
incomplete submissions.
Pertains to only paper submissions and includes scanning, data extraction,
and editing of any data extraction or scanning errors.
Pertains to adding a new submitter and its related information or updating
existing submitter information based on information from a submission.
Pertains to functionality to check the electronic version of a submission
against the physical submission. For electronic format submissions, the
Quality Assurer reviews the data to see that it was captured correctly. It
also includes performing a completeness check every day that ensures
document barcodes are valid.
Contains functionality to ensure data is complete and consistent and a DCN
is generated for each submissions and any sanitized copy of a submission.
Barcodes are also generated for CD and paper submissions.
Pertains to functionality to process user fees associated with submissions.
PMN and SNUN submissions are charged a userfee.
Contains functionality to continue process that occur after a submission
receives a DCN. This includes reviewing asubmission, transferring any
sanitized paper copy to the NCIC, maintaining violations (if they occur), and
retiring a submission.
Contains the functionality to process any corrections, additions, or
amendments to a submission. Support documents may be submitted by the
submitter or submitted internally by EPA personnel.
Pertains to any interactions with the external systems that are not already
covered in the context of use cases in other modules.
-------
Module Name
Reports
Description
Contains reporting functionality to generate predefined parameterized
reports.
Audit
Pertains to functionality to perform and process a yearly audit of section 5
submissions.
Submission Tool
Contains functionality to allow submitters to submit an electronic PMN or
NOC to EPA through CDX. The submitter may also save the electronic
submission to a CD or print it for submission to EPA.
A submission can arrive at EPA in three ways - in electronic format through the Central Data eXchange
(CDX) network, in paper format through the U.S. mail, or in CD format through the U.S. mail. In all these
cases, the submitter will use a submission tool provided by EPA to create the submission form. Using a
submission tool fosters consistency amongst various submissions.
Submissions arriving through U.S. mail get a mail receive number upon arrival that identifies each
submission until a DCN is generated for it. For joint submissions, with multiple mail receive numbers,
only the mail receive number of the primary submitter is used while any other mail receive numbers are
captured as related mail receive numbers. Once mail information is captured, the submission is sent for
prescreening. In prescreening, a submission is checked for completeness by RDMB and CCD/EETD.
There is predefined criteria that the submission is checked against. If the submission passes prescreening,
it goes to the scanning process. Otherwise, the submission is held as pending until required information
arrives. If the Prescreener determines that the submission cannot be further processed due to incorrect or
information or a lack of information, the submission is declared "Incomplete" and retired. Based on a
recent clarification to policy, all submissions will now be kept as records and not be sent back to the
submitter even if deemed incomplete.
In the scanning process, an image of the submission is created and placed in a case file folder created to
capture all information about a submission. The data is also extracted from the submission using optical
character recognition. The Submission Processor will compare the data extracted with the data provided
in the submission. If there are discrepancies, the Submission Processor will edit extracted data to match
with the data in the paper submission. Next, the Submission Processor will request to generate a DCN and
a barcode for the submission (and the sanitized copy for CBI submissions). A barcode label will be
printed and affixed on paper submissions. The paper submission will be kept in a physical folder for
reference. The image of the submission will be tracked by the DCN and will be reviewed by EPA
chemists. MTS will export some submission data to ePMN Notes to aid chemists in reviewing and
capturing information from the submission. Any supporting documents for the submission will also get a
DCN and be placed in the case file folder and in the physical folder, if in paper format. At this time, if the
submission is PMN or SNUN, a userfee will be applied to it, if available. After the submission reaches its
retention period, it will be retired using an accession number and box number issued by FRC. Any
sanitized paper copy will be sent to NCIC. During the review, if there are any studies or reports that need
to be attached to a case, they will be added to the case file folder using the internal support document
process. After the chemist review is complete, related files and any data that is common between ePMN
Notes and MTS will be imported into MTS.
CD submissions that arrive through mail are initially tracked through the incoming mail process. Once
mail receive information is captured, the CD is uploaded into MTS. Metadata is captured in MTS and a
-------
PDF of the submission is saved in the case file folder. Since there is no paper submission to scan, there is
no scanning process involved. There is no need to edit the submission unless corrections arrive from the
submitter and there will be no data extraction errors to correct. Quality assurance is not as extensive for
CD submissions. The CD submission is retired per electronic submission retirement rules and box number
and accession number do not play a role..
Network submissions do not arrive through U.S. mail, but they still get a mail receive number through the
incoming network mail process. Network submissions arrive through the CDX secure server. Once MTS
receives the submission, it sends an electronic copy of the submission back to the submitter. Network
submission metadata gets captured in MTS as soon as it arrives, however, a PDF version of the
submission is saved in a casefile folder only after prescreening is complete and a case number is
generated. Violations do not apply to network submissions as there is no paper copy of the submission to
track.
The diagrams on the following pages show how various modules interact with each other and the general
process for paper, electronic, and CD submissions. Modules are represented as activities. Actions
represent the use cases that pertain to that Module.
10
-------
Paper Submission Overall Process
«Module»
User Administration
do/ Add MTS User
/ «Module»
/ MTS Access
V do/ Access MTS
\. exit/ Logout MTS
«Module»
Mail management
«Module»
Submitter Management
do/ Capture Incoming Mail Information
[Incomplete ]
«Module»
Prescreening
do/ Prescreen Paper Submission
event Missing Information/ Capture Communication Log
event Using Email/ Capture Email Log
event Hopelessly Incomplete/ Retire Incomplete or replaced submission
«Module»
Workload Assignment
do/ Capture Workload Information
event New submitter/ Add Submitter Information
event Existing Submitter/ Maintain Submitter Information^
[Else]
«Module»
Submission Scanning
[Edit]
/ «Module»
J Quality Assurance
r
«Module»
Mail Management
Vdo/ Capture Outgoing Mail Information
event Undefined/ Send CBI EMail
«Module»
Interfaces with other systems
do/ Import Data from EPMN Notes J
do/ Obtain files from EPMN Notes /
. do/ Search for chemical Structure /
A
do/ Scan Submission
event data extraction discrepancies/ Edit Submission
«Module»
Audit
do/Audit Non NetworkSubmissions
\ do/ Perform QA Check
«Module»
Reports
do/ Generate Predefined Report
«Module»
Submission Processing
event CBI / Transfer Document to NCIC
event Retention Period Expiry/ Retire Paper Submission
do/ Review Casefile
«Module»
Support Documents
«Module»
DCN Generation
do/ Generate DCN
exit/ Generate Acknowledgement Letter
event Consolidated Submission/ Process Consolidated DCN
event Internal reports/ Submit Internal Support Document
^do/ Process Support Document
«Module»
Userfee Management
do/ Associate Userfee with Submission
11
-------
CD Submission Overall Process
«Module»
User Administration
do/ Add MTS User
[ Incomplete ]
V
[Else]
«Module»
Mail Management
do/ Capture Outgoing Mail Information
event Undefined/ Send CBI EMail
V
«Module»
Userfee Management
«Module»
MTS Access
do/ Access MTS
exit/ Logout MTS
«Module»
Mail management
do/ Capture Incoming Mail Information
«Module»
Submitter Management
event New submitter/ Add Submitter Information
event Existing Submitter/ Maintain Submitter Information
«Module»
Prescreening
do/ Prescreen Electronic Submissions
event Missing Information/ Capture Communication Log
event Using Email/ Capture Email Log
„ event hopelessly incomplete/ Retire Incomplete or Replace
«Module»
DCN Generation
do/ Generate DCN
exit/ Generate Acknowledgement Letter
event Consolidated Submission/ Proces..
«Module»
Workload Assignment
do/ Capture Workload Information
«Module»
Audit
do/ Audit Non NetworkSubmissions
«Module»
Reports
do/ Generate Predefined Report
«Module»
Submission processing
do/ Associate Userfee with Submission /
event Retention Period Expiry/ Retire Electronic Submission
do/ Review Casefile
«Module»
Support Documents
event Internal reports/ Submit Internal Support Document
do/ Process Support Document
«Module»
Interfaces with other systems
V
do/ Import Data from EPMN Notes
do/ Obtain files from EPMN Notes
do/ Search for chemical Structure
V
12
-------
Network Submission Overall Process
«Module»
User Administration
do/ Add MTS User
«Module»
Mail Management
do/ Capture Outgoing Mail Information
event Undefined/ Send CBI EMail
«Module»
MTS Access
do/ Access MTS
exit/ Logout MTS
«Module»
Mail management
do/ Capture Incoming Mail Information
do/ Send copy of electronic submission
«Module»
Submitter Management
event New submitter/ Add Submitter Information
event Existing Submitter/ Maintain Submitter Information
«Module»
Prescreening
do/ Prescreen Electronic Submissions
event Missing Information/ Capture Communication Log
event Using Email/ Capture Email Log
event hopelessly incomplete/ Retire Incomplete or Replaced submission
«Module»
Workload Assignment
do/ Capture Workload Information
«Module»
DCN Generation
do/ Generate DCN
exit/ Generate Acknowledgement Letter
event Consolidated Submission/ Process Consolidated DCN
«Module» \
Reports \
«Module»
Userfee Management
„ do/ Generate Predefined Report / \ do/ Associate Userfee with Submission
«Module»
Submission processing
event Retention Period Expiry/ Retire Electronic Submission
do/ Review Casefile
V
«Module»
Interfaces with other systems
do/ Import Data from EPMN Notes
do/ Obtain files from EPMN Notes
do/ Search for chemical Structure
V
«Module»
Support Documents
event Internal reports/ Submit Internal Support Document
do/ Process Support Document
13
-------
1.3 SYSTEM SCOPE
The problem statement for MTS-NCS effort can be defined as "develop functionality to capture, process, and
review section 5 submissions using Electronic Content Management System (ECMS) Documentum and
enterprise architecture."
The functionality of MTS-NCS is described in the following use case diagram. This diagram shows major
functionality of MTS-NCS and the users of that functionality. The users are referred to in the Unified
Modeling Language (UML) methodology as actors. Use cases represent distinct pieces of functionality that
enlists interaction between the user and the system to satisfy a goal. The functionality of the system was
defined in various modules as defined above.
There are several system interactions that pertain to section 5 submission processing. The systems that MTS-
NCS intends to interact with and their priority (indicated by a number before the system name) are defined in
the diagram below.
1 .ACCELRYS
1.EPMN Notes
2.TDTS-CAS
LSMTPEMail
1.HPVIS
1.CDX
The interaction with these systems is indicated in the table below:
System Name
ACCELRYS
Interactions
This tool will be used to perform chemical structure search and to
provide, results to be used in new chemical reviews.
-------
MTS NCS Software Requirements Specification Model Report
CBITS
EMAIL
FRS
HP VIS
CDX
IUCLID
TDTS
EPMN Notes
FMD
CBITS will be used to obtain user clearance information. Data will
initially be transferred into MTS for existing user fees and submitter
information. Support documents that pertain to original submissions
that are in CBITS, will still be processed and captured in CBITS.
The email server will be used to send non CBI email to submitters.
There will be no direct interaction with FRS. Facility ID information
for section 5 submissions will be retrieved manually from FRS and
saved in MTS for later use.
HP VIS will provide ad hoc reports to be used by MTS.
CDX is a part of the overall MTS system and is used to transmit
electronic submissions from submitters, to send a copy of network
submissions back to the submitter, and to send CBI email.
IUCLID provides international new chemical submission information
to be stored in MTS (Organization for Economic Cooperation
and development Templates).
TDTS will provide results from the Chemical Abstract Service
(CAS), on inventory status, and refund requests for chemicals in a
submission.
EPMN Notes will provide internal support documents such as
chemical reports and studies to be put in case files. It will also receive
and send back section 5 submission information to MTS.
FMD will provide user fee information that the User Fee Processor
will use to complete user fee processes.
The diagram on the next page shows various modules or groups of functionality provided by MTS NCS and
the actor who uses each module.
15 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
«System Actor»
Lotus Notes E-PMN
Submission Reviewer
System
Administration
Submission Processor
Audit
Auditor
Mail
Management
Mail Clerk
NCS Application Administrator
«System Actor»
Lotus Notes E-PMN
Userfee processor
System Clock
T
Chemist
NCS Application Administrator
Workload
Assignment
Quality
Assurance
Quality Assurer
Prescreener MTS General User
Section 5 submissions consists of the following types of information and document types. These are:
- Premanufacture Notices
• PMN
16 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
• SNUN
• TMEA
• LVE
• LVM
• LOREX
• LOREXM
- Biotech Notices
• TIER I
• TIER II
• MCAN
• TERA
• Biotech SNUN
• Biotech TME
- Enforcement "Mock" Submission
- Enzyme Re-reporting Submission
- Polymer Exemptions (YSU)
Inventory Search/update Submissions
- Bona Fides
- Corrections
Parallel Process Submissions
- US Lead
- US Secondary
- US Observer
MTS NCS will provide submission tool to the industry to allow them to submit Section 5 submissions and
support documents. There are five types of forms envisioned and they are as follows:
PMN Form - This includes the submission form for PMN, SNUN, LVE, LOREX, LOREXM, and TMEA.
This functionality is planned to be delivered for the first release of the application.
Biotechs - This include MCANS, TERA, TIER! and TIER II. There is not currently an Office of Management
and Budget (OMB) approved form form for Biotechs so there will not be a submission tool for Biotechs in
release one.
Bonafides - This includes BONA. There is not currently an Office of Management and Budget (OMB)
approved form form for Bonafides so there will not be a submission tool for them in release one.
Notice of Commencement - This include NOC. This functionality is planned to be delivered for the first
release of the application.
Following are various kinds of support documents:
Amendments to:
*»* Notice Submissions
o Updates to pages 1-13
o Updates to other submission pages (e.g., Pchem data, Spectra, MSDS)
o Test Data (information which was not part of the original submission and may have come in as
a result of a regulation)
o Commune S (any other communication besides the three above)
17 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Biotech Submissions
Bona Fide Submissions
Correction Submissions
Parallel Process Submissions
Correspondences
• Letter of Support
• Withdrawal Letters
Suspensions
The requirements have been analyzed and represented using UML. A use case shows interactions between
the user of the system (the actor) and the system for a particular goal oriented process. A use case diagram
shows various use cases and relationships between them. Activity diagrams, like flowcharts show process
flows of MTS. Class diagrams are used to show business entities relationships.
This document is organized based on modules. For each module, a description, an overall process flow that
links all the use cases together, and considerations regarding the module are provided. Use case and activity
diagrams, workflow and lifecycle considerations, a state transition diagram, and a class diagram showing
business entities in that module are also shown.
18 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
1.4 DEFINITIONS
Term
NCS
Meaning
New Chemical Submissions
Identity
EPA classifies chemical substances as either "existing" chemicals or "new"
chemicals. The only way to determine if the substance you are working with is a
new chemical is by consulting EPA's TSCA Chemical Substance Inventory
(commonly referred to as the TSCA Inventory or just the Inventory). Any
substance that is not on the Inventory is classified as a new chemical. If a
substance is "new", it can be manufactured for a commercial purpose only if it is
subject to an exemption from PMN reporting or a TSCA reporting exclusion (for
example, a LVE, or exclusion as a naturally-occurring material). For substances
which are "existing", the Inventory can be used to determine if there are
restrictions on manufacture or use under TSCA. There are approximately 75,000
chemical substances, as defined in Section 3 of the TSCA, on the Inventory at
this time.
Letter of Support
In some cases, a manufacturer will want to use reactants whose identities are
held confidential by their suppliers from the manufacturer. In certain other
cases, a potential importer wants to bring into the U.S. a substance whose
identity is known only to its foreign manufacturer. In these cases a letter of
support from the domestic manufacturer or foreign reactant manufacturer is
sent directly to EPA, giving complete chemical identity, health and safety
information, etc., and can be used for Section 5 notification
Notice of
Commencement
(NOC)
A new chemical is eligible for addition to the TSCA Inventory after the PMN
review period has expired and the PMN submitter has commenced non-exempt
commercial manufacture. The submitter of a PMN must provide a Notice of
Commencement of Manufacture or Import (EPA Form 7710-56) to EPA within
30 days of the date the substance is first manufactured or imported for
nonexempt commercial purposes. It will then be listed on the Inventory. Once a
substance is listed on the TSCA Inventory, it is considered an "existing"
chemical.
Excess R&D substance may be used or sold after expiration of the PMN review
period without submission of an NOC; the material will not be placed on the
Inventory until NOC is received, however. NOC may not be submitted for use
of such material before initiation of manufacture for non-R&D purposes.
Low Volume
Exemption (LVE)
The PMN rule exempts certain categories of new low volume chemical
substances from full PMN review under Section 5 of TSCA. This rule provides a
limited exemption from PMN requirements for certain low volume substances
(i.e., chemicals manufactured at 10,000 kg/yr. or less). In 1985, the EPA
promulgated (50 FR 16477) the first LVE for substances produced at 1,000
kilograms per year (kg/yr) or less. The 1995 PMN amendments (60 FR 16336)
replace the earlier exemption in full and increase the production volume limit to
19 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Term
Meaning
10,000 kg/yr. LVE substances undergo a 30-day review and are not subject to a
user fee.
Research and
Development
Exemption
Section 5(h)(3) of the TSCA allows the Administrator of EPA to develop
regulations exempting manufacturers and processors of chemical substances
subject to the TSCA from the notice requirements of Section 5(a) if they
manufacture or process the substances "only in small quantities solely for the
purposes of scientific experimentation or analysis, or chemical research on, or
analysis of such substance, or another substance, including such research or
analysis for the development of a product." No application is required for the
exemption for R&D under Section 5(h)(3).
Low Releases and
Low Exposure
Section 5(h)(4) of the TSCA (15 U.S.C. 2604(h)(4)) allows the EPA, by rule, to
grant an exemption from any or all of the requirements of Section 5 if EPA
determines that the manufacture, processing, distribution in commerce, use, or
disposal of a substance will not present an unreasonable risk of injury to health
or the environment. Section 26(c) of the TSCA provides that any action
authorized under the TSCA for an individual chemical substance may be taken
for a category of such substances. The Agency has established a Section 5(h)(4)
exemption category for certain chemical substances with low environmental
releases and human exposures. The language establishing this exemption was
published in the Federal Register on March 29, 1995 (60 FR 16336-16351). To
ensure that these chemical substances will not present an unreasonable risk, EPA
has included procedural safeguards, including a 30-day review and other
conditions in the exemption
Test Marketing
Exemptions
The PMN rule provides a definition of test marketing for the purposes of Section
5 exemption, found at 40 CFR Section 720.3(gg). The purpose of the test
marketing exemption is to enable potential PMN submitters to focus on
customers' acceptance of a chemical substance, and the probable demand for a
product in a market where it will be competing with other goods. It requires
submission of a test market exemption application to EPA pursuant to 40 CFR
Section 720.38.
Chemical Categories
Report
Prior to 1987, nearly 20% of PMNs submitted underwent a detailed review
("standard review") by EPA, a highly resource-intensive effort that lasts most of
the mandated 90-day PMN review period. In 1987, after several years of
experience in the review of PMNs, EPA's Office of Toxic Substances (now
OPPT) had enough accumulated experience to group PMN chemicals with
shared chemical and toxicological properties into categories, enabling both PMN
submitters and EPA reviewers to benefit from the accumulated data and past
decisional precedents allowing reviews to be facilitated. The first category was
"acrylates and methacrylates."
Currently, there are a total of 45 categories. As expected, establishing these
categories has streamlined the process for Agency review of new chemical
substances. Based on current information, the Agency takes action to control
potential risks to health or the environment on approximately 10% of the PMNs
20 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Term Meaning
MTS
DCN
CBITS
FMD
FRS
EPMN Lotus Notes
TDTS
submitted. Only 2-3% of the total number of PMNs submitted (20-30% of the
above 10%) now undergo a standard review, while the remaining 7-8% are
identified as members of the New Chemicals Program chemical categories.
Manage Toxic Substances
Document Control Number
Confidential Business Information Tracking System
Financial Management Division
Facilities Registry System
Electronic Premanufacturer Notice Lotus Notes
Toxic Substances Control Act (TSCA) Data Transmittal System
21 of 260
3/10/2009 4:33 PM
-------
1.5 REFERENCES
CBITS documentation was consulted to develop this specification. User interviews, workshops, and
process diagram reviews (wall walks) were conducted to gather information that was used to model
business process flows.
• CBITS Software Requirement Specifications
• CBITS Data Requirements
• CBITS Use Case Specifications
• www.epa.gov/opptintr/newchems/index.htm
-------
MTS NCS Software Requirements Specification Model Report
Chapter 2. User Perspective
2.1 USERS RELATIONSHIPS
In UML, users of the system, even if they are other systems, are called Actors. An actor is a role that a
person may play. An actor must not be confused with an organization role. An actor is relevant to the
function it is related to. For example, a role of Submission Processor is assigned to show a role that
pertains to prescreening, scanning, editing, generating DCN and further processing a submission. RDMB,
CBIC or any other organization can play the role of submission processor if they are involved in that
process.
The following diagram shows various roles in the system and the relationship between them. Note that the
human actors are shown as stick figures, while system actors are shown as boxes and a particular system
component is shown as an entity.
NCS Application
Administrator
/\
Submission
Reviewer Quality Assurer Userfee processor Scanning
Personnel
Submission
Processor
«System Actor»
ACCELYRS
«System Actor»
Lotus Notes E-PMN
«System Actor»
FMD
«System Actor»
CBITS
«System Actor»
CDX
«System Actor»
Archival Location
System Clock
23 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
2.2 ACTORS AND ASSOCIATED FUNCTIONALITY
For each of the actors in MTS NCS, a description of the actor and the use cases that actor is involved in is
depicted below.
MTS General User
This represents a generic user that has access to the least amount of functionality. Essentially, all other
roles can do what a general user can do, plus more. All actors specialize from this role.
Following are use cases in which this actor is involved in:
Obtain Help
View Edit Outgoing Mail
Capture Communication Log |_ogout
Send CBI EMail
Access MTS
Capture Workload Information
Generate Predefined Reports
MTS General User
MTS System Administrator
This is the overall MTS system administrator that administers ECMS from the Research Triangle Park
(RTF) computer facility. The only functionality associated with this actor includes adding a user to MTS.
Following is the use case in which this actor is involved:
MTS System
Administrator
Add MTS User Information
24 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
CBITS
This is the current system that processes metadata about section 5 submissions.
Following are use cases in which this actor is involved in:
Process Support Document
Import Userfee Information
«System Actor"**
CBilS
Add MTS User Information
Import Submitter Information
Submit Internal Support
Documents
NCS Application Administrator
This is the administrator that will work with the actors to resolve any NCS application issues. This actor
will have access to all functionality.
Following are use cases in which this actor is involved:
25 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Change Document Status
Assign Document Status Change Year
Maintain Lookup Table Information
Delete Information
Add submitter information
Review Undelivered Email
Query Last Sequence Number
Used
Reprint Barcode
Import Submitter Information
Import Userfee Information
NCS Application
Administrator
Auditor
This actor performs yearly audits on documents and cases.
Following is the use case this actor is involved in:
Auditor
Audit Non-Network Submissions
User Fee Processor
This actor processes user fees and assigns refunds for user fees.
Following are use cases in which this actor is involved:
26 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Edit Userfee Information Process User Fee Refund
Complete Userfee Information
Associate Userfee with
Submission
Request userfee refund
Get Userfee Information from FMD
Userfee processor
Mail Clerk
This actor processes incoming and outgoing mail.
Following are use cases in which this actor is involved:
capture Incoming CD Mail
Information
View Edit Outgoing Mail
Capture Incoming Mail Information
View Edit Incoming Mail
Capture Incoming Paper Mail
Information
Capture Outgoing Mail Information
Mail Clerk
27 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
System Clock
The system clock is actually a component of the system and not really an actor. However, it is represented
as an actor to allow levying of requirements on the system to set and accept triggers to start an action.
Following are use cases in which this actor is involved:
Determine Userfees to be
Refunded
Get Userfee Information from FMD
Capture Incoming Network Mail
Information
Import data from ePMN Notes
System Clock
Inventory Administrator
This actor, as well as the Inventory Chemist, determines which submissions have submitted chemicals
that already exist in CAS and, therefore, require refunds. The Inventory Administrator is also notified
when an Inventory Chemist deems a chemical as on inventory so he can prepare on inventory letters in
EPMN Notes.
Following are use cases in which this actor is involved:
28 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Request userfee refund
Inventory
Administrator
Inventory Chemist
This actor identifies chemical data that will be sent to TDTS to support determination of inventory
statuses for chemicals. The Inventory Chemists selects chemical results file to be transmitted from TDTS
back to MTS with related status fields.
Submission Processor
This actor processes a submission after it has been prescreened. This includes scanning the submission,
performing edits, generating a DCN, generating an acknowledgement letter and then further processing
the submission, as needed after DCN generation.
Following are use cases in which this actor is involved:
29 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Pickup Document Re(ire E|ec(ronic Submissions
Maintain submitter information
Process Consolidated Submission
Transfer Document to NCIC
Maintain Violations
Process Support Document
Perform Validation on Barcodes
Modify Section 5 Submissions
View Edit Submission
Generate Acknowledgement Letter
Process Replacement Support
Document
Modify Support Documents / \ /- \ Unretire a casefile
Scan Support Document Scan Submissions
EPMN Lotus Notes
This external system provides files and data for MTS to update its information with once EETD and CCD
have reviewed the Section 5 submission. MTS also provides data to EPMN for use by chemists during
chemical reviews.
Following are use cases in which this actor is involved:
30 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Search for Chemical Structure
«System Actor»
Lotus Notes E-PMN
Import data from ePMN Notes
Obtain files from ePMN Notes
FMD
Generate DCN
This external system called the Financial Management Division system, will provide user fee information
to MTS to be used in user fee processes.
Following are use cases in which this actor is involved:
Get Userfee Information from FMD
Quality Assurer
This actor ensures consistency between the paper version and the system version of paper submissions as
edits may be performed on the system information. Electronic submissions are also checked for quality.
31 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Following are use cases in which this actor is involved:
-. ... . Perform Quality Assurance Check
Quality Assurer
Prescreener
A generalized role to represent the actors that review the submission for predefined criteria before it is
reviewed by EETD or CCD. This role consists of the Administrative Prescreener and the Chemical
Prescreener.
Following are use cases in which this actor is involved:
32 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Process Incomplete or Replaced
Document
Process Support Document
Prescreener
Prescreen Electronic Submission
Prescreen Paper Submission
Process Replacement Support
Document
Archival Location (FR- RMR)
This is a role that represents a location on the system where electronic submissions will be retired.
Following are use cases in which this actor is involved:
3 3 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
,Process Replacement Support
Document
«System Actor»
Archival Location
Retire Electronic Submissions
Submission Reviewer
This role represents users that review and further process section 5 submissions. They include EETD and
CCD and it is analogous to a PMN user.
Following are use cases in which this actor is involved:
Review Casefile
Submission Reviewer
Submit Internal Support
Documents
Chemist & ACCELRYS
This role represents the user of the ACCELRYS tool which is used by chemists to search for chemical
structure information.
Following are use cases in which both these actors are involved in:
34 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
«System Actor»
ACCELYRS
Chemist
Search for Chemical Structure
TDTS
This external system called the TSCA Data Transmittal System, will accept PDF files with chemical data
from MTS and provide back results, a PDF file and several fields, on chemical inventory status to MTS.
CDX
This is also part of the overall MTS but is external from the NCS perspective.
«System Actor»
CDX
Send Copy of Electronic
Submission
3 5 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Chapter 3. Process Flows
3.1 USE CASES
Use Case Name
Access MTS
Logout MTS
Audit Non Network
Submission
Generate
Acknowledgement Letter
Description
The use case entails the process of logging
into MTS. MTS will verify the MTS
General User's clearance level upon each
login.
The use case entails the process of logging
out of MTS. If the MTS General User does
not initiate a log out by a predefined time
each day, the system will force logout.
Upon logging out, any work the user self
assigned through the Capture Workload
Information use case will be unassigned.
This use describes the process of auditing
non-network submissions (received on
paper or CD) that are active and have been
assigned a DCN in MTS to ensure that EPA
has the original copies of the submissions.
For CD submissions there may be one or
several CDs, a cover letter, or a paper copy
of the CD content. Unique barcodes are
placed on each item during the DCN
generation process (see Generate DCN use
case). EPA maintains the paper and CD
media in files in a secure area.
The use case describes the process of
generating an acknowledgement that is sent
to submitters when their submission is
considered complete by EPA. This letter is
not generated until a DCN exists. The
Submission Processor can generate the
letter immediately after generating a DCN
or at some point after. The DCN number is
included in the letter for the submitter's use
on any future support documents.
Actors
MTS General User,
MTS System
Administrator,
CBITS
MTS General User
Module
Access MTS
Access MTS
Auditor
Audit
Submission Processor DCN Generatioi
36 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Generate DCN
Modify Section 5
Submission
Process Consolidated
Submission DCN
The use case describes the process of
generating a unique document control
number (DCN) for an MTS original
submission. Before the DCN is generated
by the system, a consistency check is done
on the data fields. MTS also checks data
fields to ensure they meet business rules,
e.g. if data is required in the field that it is
present and valid. The submission must
have a valid submitter abbreviation assigned
versus the "need to add" placeholder. After
the DCN is generated, a barcode is printed
out for non-electronic submissions. DCNs
for documents other than original
submission are generated through the
Process Support Document use case or the
Process Replacement Support Document
use case. DCNs for incomplete submissions
are generated through the Process
Incomplete Submission use case.
The use case describes the process of
editing the content of a submission after it
receives a DCN. (See the View Edit
Submission use case for modifications
before a document has a DCN.) The MTS
General User may edit certain fields as
defined in the Modify Section 5 Submission
data spreadsheet.
The use case describes the process of
generating a unique document control
number (DCN) for each chemical that is
part of a consolidated submission. The
system will generate sequential DCNs for
the chemicals in the consolidated
submission. This use case is an extension
of the Generate DCN use case.
Submission
Processor, ePMN
Lotus Notes
DCN Generatioi
Submission Processor DCN Generatioi
Submission Processor DCN Generatioi
37 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Incoming CD
Mail Information
Capture Incoming
Network Mail Information
Capture Incoming Paper
Mail Information
Send Copy of Network
Submission through CDX
View Edit Incoming Mail
Information
Get User Fee Information
from FMD
The use case entails the process of capturing
the receipt of a CD containing Section 5
submission information or support
document information. If the CD fails to
upload, the mail clerk can enter incoming
mail information using any cover letter and
the paper copy of the submission. The
submission is incomplete if the CD does not
load and no paper copy is provided. The
submission is promoted to prescreening
after it has completed this process. See the
Prescreen Electronic Submission Use Case.
Support documents are promoted to the
Process Support Document use case.
The use case entails the process of capturing
the receipt of an electronic Section 5
document, either a submission or a support
document, received through CDX. The
document is promoted to administrative
prescreening at the end of the process.
Original submissions complete several steps
not required for support documents.
The use case entails the process of capturing
the receipt of paper Section 5 submissions
and support document information. The
Mail Clerk manually enters incoming mail
information.
Mail Clerk
Incoming Mail
System Clock
Incoming Mail
Mail Clerk
Incoming Mail
CDX
Incoming Mail
Incoming Mail
The use case entails the process of sending a
copy of a network submission back to the
submitter. The submission may be an
original submission or a support document.
The use case entails the process of viewing Mail Clerk
and editing information previously captured
about the receipt of Section 5 documents.
This use describes the process of receiving FMD, System Clock Interfaces
information from the EPA Financial
Management Division (FMD) system
regarding user fees paid by submitters.
Submitters pay fees through a bank. EPA
FMD then receives bank data and maintains
it in the FMD system. MTS users require
user fee information from FMD to ensure
that a submitter has correctly paid for
submission processing.
3 8 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Import data from ePMN
Lotus Notes
Import Submitter
Information
Import User Fee
Information
Obtain Files from ePMN
Lotus Notes
Search for Chemical
Structure
Identify Data for TDTS
This use case describes the process of
pulling data fields from ePMN Lotus Notes
to MTS on a periodic basis. MTS will
import the data fields that were sent to
ePMN through the Send Data to ePMN
Lotus Notes use case after they are updated
by ePMN Lotus Notes users. The imported
fields will not overwrite the values saved in
MTS, both the original data and the ePMN
edited data will be maintained. MTS will
also import data fields that originated in
ePMN Lotus Notes to support PMN
reporting requirements.
The use case describes the process of
moving submitter information from CBITS
to MTS.
The use case describes the process of
moving user fee information from CBITS to
MTS.
This use case describes the process of
pulling data files from ePMN Lotus Notes
to MTS on a periodic basis.
This use case describes the process of
searching databases in MTS for chemical
structure information. The chemist searches
data to find structures needed to complete
new chemical reviews or reports. Searches
may also be used to answer questions from
EPA staff. The actual search is done using
Accelrys. The Chemist may choose several
output options including transfer of
chemical structure search results to ePMN
Lotus Notes.
This use case describes the first step in the
process of identifying if a new chemical is
already on inventory. MTS will interface
with the TSCA Data Transmittal System
(TDTS). MTS will allow an inventory
chemist to select data to be sent to TDTS in
a PDF file. Information is not requested by
the inventory chemist for every submission,
and the information sent may differ between
submissions (although it is often similar).
Outside of the MTS system, TDTS
interfaces with CAS. If CAS does not
ePMN Lotus Notes,
System Clock
Interfaces
NCS Application
Administrator,
CBITS
NCS Application
Administrator,
CBITS
ePMN Lotus Notes,
System Clock
Chemist, ePMN
Lotus Notes,
Accelrys
Interfaces
Interfaces
Interfaces
Interfaces
Inventory Chemist,
TDTS
Interfaces
3 9 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
accept the data request, the Inventory
Chemist may repeat this use case by
entering the appropriate DCN and creating
new PDF to send to TDTS.
a
Obtain Data for TDTS
Capture Email Log
Capture Outgoing Mail
Information
Review Undelivered Mail
This use case describes the process of
pulling data on a periodic basis from TDTS
and placing the data (a results file and
various fields) in appropriate case files in
MTS. Inventory Chemists review CAS
results in TDTS then determine on
inventory status, refund requests, and
comments on CAS results. When the
review is complete, the chemist flags the
file and its related fields for transfer to
MTS. The Inventory Administrator is
notified of chemicals that are on inventory
so they can create required on inventory
letters in ePMN Lotus Notes. The system
uses the business rules in this use case to set
refund field values (user fee status and
refund comment) that the User Fee
Processor will use when processing refunds.
This use case describes the process of
capturing email communications between
EPA and submitters. For example, EPA
may choose to request data or provide an
acknowledgement letter via email. Non-
CBI email content may be sent via EPA
email. CBI email content must be
encrypted and send via CDX.
The use case entails the process of capturing
outgoing mail information that is being sent
from EPA to a submitter. Some examples
of materials to be sent include incomplete
letters and acknowledgement letters.
The use case entails the process of
reviewing emails that were undeliverable.
The NCS Application Administrator may
choose to resend the emails as paper mail.
TDTS
Interfaces
MTS General User Outgoing Mail
Mail Clerk
Outgoing Mail
NCS Application
Administrator
Outgoing Mail
40 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Send CBI Email through
CDX
View Edit Outgoing Mail
Information
Capture Communication
Log
The use case entails the process of sending
CBI email through CDX. If a submitter
does not have a CDX account EPA may not
send CBI information to the submitter
through email. Non CBI email may be sent
through EPA email systems other than
CDX. See the Capture Email Log Use
Case.
The use case entails the process of viewing
and editing information previously captured
about outgoing mail from EPA to
submitters.
This use case describes the process of
capturing communications between EPA
and submitters. For example, EPA may
need to discuss submissions data or to
request missing data that is needed to make
a submission complete. EPA communicates
with the submitter during the prescreening
process, but any MTS General User may log
data about a communication at any time.
For example, the User Fee Processor may
communicate with a submitter regarding
user fee data. If the submitter submits new
data or changed data to EPA it will be
handled through incoming mail processes.
MTS General Users may not change
original data submitted to EPA without
written support from the submitter.
MTS General User Outgoing Mail
Mail Clerk
Outgoing Mail
MTS General User Prescreening
41 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
ZC^ZTZII lit :
Prescreen Electronic This use describes the process of Administrative Prescreening
Document prescreening electronic Section 5 Prescreener,
submissions for administrative or chemical Chemical Prescreener
errors. Electronic submissions may be
submissions on disk or they may be
transmitted directly to MTS, e.g., CDX
submissions. MTS performs validation
checks on the electronically submitted data
prior to this prescreening process to increase
submission quality. The chemical and
administrative prescreenings identify
incomplete submissions that will be sent
back to the submitter or put on hold until
additional data is received. Validation
checks performed on electronic submissions
should minimize the amount of data errors.
Incomplete at this stage refers to specific
prescreening criteria. A more thorough
examination of submission content is done
later in the MTS processes. The
prescreening process prevents EPA
employees from spending additional
resources on submissions that do not meet
basic requirements. Once the Chemical
Prescreener has completed prescreening
activities, a final "complete" or "
42 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Prescreen Paper
Submission
Process Incomplete or
Replaced Document
This use case describes the process of
prescreening paper Section 5 submissions
for administrative or chemical errors. The
paper submission process pertains to paper
submission; electronic submissions are
screened using the Prescreen Electronic
Submission use case. Prescreening
identifies incomplete submissions that will
be sent back to the submitter. Incomplete
at this stage refers to specific prescreening
criteria. A more thorough examination of
submission content is done later in the MTS
process. The prescreening process prevents
EPA employees from spending additional
resources on submissions that do not meet
basic requirements. The Administrative
Prescreener attempts to capture any missing
data and then forwards the submission for
chemical prescreening if the administrative
data is complete. Once the Chemical
Prescreener has completed prescreening
activities, a final "complete" or
"incomplete" decision is determined for
prescreening.
This use case describes the process of
retiring an incomplete document or replaced
page. Although the prescreening process
identifies incomplete documents when they
fail prescreening, there is also a need to
make document incomplete outside of the
prescreening process. For example, a CD
that will not load during incoming mail
processes and does not have a paper
document accompanying it would be
identified as hopeless and be processed
through this use case.
Administrative
Prescreener,
Chemical Prescreener
Prescreening
Prescreener
Prescreening
43 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Perform Quality
Assurance Check
Perform Validation on
Barcodes
Generate Predefined
Reports
Scan Submission
The use case describes the process of
performing a quality assurance check on
Section 5 submissions received in paper
format or electronic format. For paper
format submissions, the Quality Assurer
compares the paper submission to the data
in MTS. For electronic format submissions,
the Quality Assurer reviews the data to see
that it was captured correctly. If the data
does not match or there is some other type
of quality assurance issue, the Quality
Assurer logs a failure for the submission
quality assurance checks and the submission
is promoted back to the View Edit
Submission use case. The Quality Assurer
does not make changes to document data, he
or she only passes or fails the document.
The use case describes the process of
validating barcodes attached to non-
electronic submissions for quality assurance
purposes. This is typically done on a daily
basis to ensure that DCNs that have been
created in the system related to actual non-
electronic submissions. If a scanned DCN
is not found in the system, it is recorded as
an error for later investigation. Errors will
be investigated by a system administrator or
DBA to determine resolution.
This use case describes the process of
generating reports that have been predefined
for MTS. The user may provide values for
reports parameters, e.g., data ranges.
The use case describes the process of
scanning paper submissions after they have
completed prescreening, but before they
have received a DCN. The Submission
Processor reviews the scanned image for
readability. The Submission Processor also
reviews the data fields captured during the
scanner's OCR process. The processor may
choose to do a partial rescan or full rescan
of the document if either the image or the
data capture is not successful. If a user
finds problems with the scan or data capture
after this process is complete, the user must
Quality Assurer
Quality Assuran
Submission Processor Quality Assuran
MTS General User Reports
Submission Processor Scanning
44 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
rescan the entire document and delete the
old version. See the View or Edit
Submission Use Case.
Scan Support Document
View Edit Submission
The use case describes the process of
scanning paper support documents after
they have completed the Process Support
Document use case or the Submit Internal
Support Document use case. The
Submission Processor reviews the scanned
image for readability. No data extract is
done for support documents. The processor
may choose to do a partial rescan or full
rescan of the document if the image scan is
unsuccessful. If a user finds problems with
the scan after this process is complete, the
user must rescan the entire document and
delete the old version.
The use case describes the process of
editing the content of a submission before it
receives a DCN. (See the Modify Section 5
Submission use case for modifications after
a document has a DCN.) The MTS General
User may edit the submission to correct
errors identified in writing by the submitter
or to correct errors created during the
OCR/scanning process. All MTS General
Users may view a document. Edit
capability may be limited based on user
roles. MTS will maintain an original
version of data received by the submitter
that cannot be edited.
Submission Processor Scanning
MTS General User Scanning
45 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Workload
Information
Maintain Violations
Pickup Document
Retire Electronic
Submission
Retire Paper Submission
Review Case File
Transfer Document to
NCIC
Unretire a Case File
The use case describes the process of
selecting a submission to work on for any of
the MTS processes. It describes a self-
assignment process where a user assumes
workload by selecting a submission to work
on. If the user requests to logout of MTS
before completing the process the system
will request a status comment before
removing the work assignment. If the user
does not request to logout, the system will
logout them out at a predefined time each
day and force the removal of the work
assignment.
The use case describes the process of
adding to or editing the information about a
violation letter support document.
The use case describes the process of
capturing information about document
pickup by NCIC.
The use case describes the process of
retiring an electronic submission's case file
from active status. The entire case related
to the submission is retired at the same time.
The use case describes the process of
retiring a paper submission from active
status. The entire case related to the
submission is retired at the same time.
The use case describes the process of
reviewing a case file and selecting a
document in a case file to review or print.
The system verifies if the requestor has
appropriate CBI clearances before providing
files for review.
The use case describes the process of
recording the transfer of a sanitized version
of a submission over to NCIC.
The use case describes the process of
unretiring an entire case file, versus
unretiring just one document. Other
document status assignments or changes
must be done through the Assign Document
Status use case or the Change Document
Status use case.
MTS General User
Submission
Processing
Submission Processor
Submission Processor
Submission
Processor, Archival
Location (FR-RMR)
Submission Processor
Submission Reviewer
Submission Processor
NCS Application
Administrator
Submission
Processing
Submission
Processing
Submission
Processing
Submission
Processing
Submission
Processing
Submission
Processing
Submission
Processing
46 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Add Submitter
Information
Maintain Submitter
Information
Process Submitter in
Incoming Mail
Submit Internal Support
Document
The use case describes the process of
adding a submitter to MTS. Each
submission will be linked to a unique
submitter abbreviation. If the submitter
does not exist in MTS when a submission
arrives, a "need to add" status is given to the
submission submitter information until this
use case can be completed. The Add
Submitter use case allows the NCS
Application Administrator to add a new
submitter and corresponding abbreviation so
the "need to add" value can be updated with
an abbreviation. A submission will not
receive a DCN until it has been linked to a
submitter abbreviation.
The use case describes the process of
maintaining submitter information in MTS.
Each submitter is assigned a unique
abbreviation. The submitter information
includes data about plants, points of contact,
etc. that can change over time.
The use case describes the process of
attempting to match a new submission to an
existing submitter when the submission is
processed through incoming mail. The
prescreener will attempt to match the
submission to an existing submitter
abbreviation. If none can be located, the
abbreviation "need to add" is used until the
submitter is added through the Add
Submitter Information use case.
This use case describes the process of
creating a relationship between a support
document created internally by an EPA
employee, and an original submission. The
internal support document will be placed in
the submission case file and have a DCN as
a unique identifier.
NCS Application
Administrator
Submitter
Information
Submission Processor
Submitter
Information
Prescreener
Submitter
Information
PMN Reviewer
Suport Documet
47 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Process Replacement
Support Document
Process Support
Document
Modify Support Document
Assign Document Status
Change Document Status
The use case describes the process of
process an external support document sent
by a submitter to EPA that arrives while the
original submission is still in prescreening.
The data on the support document is needed
to complete the submission and make it
complete. A support document cannot
receive a DCN until the original submission
receives a DCN.
The use case describes the process of
process an external support document sent
by a submitter to EPA. The Submission
Processor identifies if the support document
has enough information to identify the
submission it is related to. If there is not
enough information, the processor will
contact the submitter using the Capture
Communication Log use case. If the
support document is to replace information
received prior to the support document it is
processed through the Process Replacement
Support Document use case.
The use case describes the process of
modifying metadata for a support document.
Metadata for support documents is initially
entered through the Process Support
Document use case and the Submit Internal
Support Document use case.
The use case describes the process of
assigning a document status to a document.
Valid paper document statuses are: active,
unaccountable, invalid, or retired. Valid
electronic document statuses are: active,
invalid, or retired. Changes to the status of
an unaccountable document to active, or a
retired document to active, must be done
through the Change Document Status use
case.
The use case describes the process of
changing a document status from
unaccountable to active, or from retired to
active. Other document status assignments
must be done through the Assign Document
Status use case.
Prescreener,
Submission Processor
Support Docurm
Submission
Processor, CBITS
Support Docum<
Submission Processor
Support
Documents
NCS Application
Administrator
System
Administration
NCS Application
Administrator
System
Administration
48 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Change Year
Delete Information
Maintain Lookup Table
Information
Query Last Sequential
Number Used
Reprint Barcode
Obtain Help
Add MTS User
Associate User Fee
Information
The use case describes the process of
temporarily changing the fiscal year or
calendar year for the purpose of generating
a DCN for a submission that needs to be
accounted for in a previous year. This
process is expected to be run as necessary
after normal operating hours.
The use case describes the process of
deleting information from the system.
Items that can be deleted include: mail
receipt information, users, officials, plants,
submitter abbreviations, technical contacts,
user fee data, violation data, scanned files,
submissions, and support documents. The
relevant records to be deleted are specific to
each type of deletion.
The use case describes the process of
maintaining information contained in
lookup tables. The NCS Application
Administrator can make changes as
necessary to meet changing requirements.
Initially, some CBITS lookup tables will be
transferred to populate lookup tables.
The use case describes the process of
determining the last Document Control
Number issued in a fiscal year for a specific
document type.
The use case describes the process of
reprinting a barcode that is unreadable,
corrupt, or missing.
The use case describes the process of a
providing an MTS General User with
context sensitive help.
The use case describes the process of
adding an MTS General User to the system
This use describes the process of associating
a user fee with a submission and
determining if the correct amount of fee was
provided. The User Fee Processor reviews
information regarding user fees that was
received from FMD. MTS users require
user fee information to ensure that a
submitter has correctly paid for submission
NCS Application
Administrator
System
Administration
NCS Application
Administrator
NCS Application
Administrator
NCS Application
Administrator
NCS Application
Administrator
MTS System
Administrator,
CBITS
User Fee Processor
System
Administration
System
Administration
System
Administration
System
Administration
MTS General User System Interface
User
Administration
User Fee
49 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
processing.
Complete User Fee
Information
Determine Need to Refund
User Fee
Determine User Fee to be
Refunded
Edit User Fee Information
Process User Fee Refund
Query User Fee Status
This use describes the processing user fees
so that they are ready for association to a
submission. If required information did not
arrive with the user fee, the User Fee
Processor obtains information by contacting
the submitter. See the Capture
Communication Log use case and the Edit
User Fee Information use case.
This use describes the process of
determining whether a submitter's user fee
should be refunded.
This use describes the process of
determining the user fee to be refunded to a
submitter.
This use describes the process of viewing
and modifying user fee information.
This use describes the process of requesting
and processing a refund of a user fee. If
EPA determines that the chemical is already
on inventory with CAS, EPA may refund
the user fee to the submitter.
This use describes the process of reviewing
that status of user fees and corresponding
associations.
User Fee Processor
User Fee
User Fee Processor,
Inventory
Administrator
System Clock
User Fee Processor
User Fee Processor
User Fee
User Fee
User Fee
User Fee
User Fee Processor
User Fee
3.2 MODULES
Audit
Description
An audit is conducted to ensure that all physical paper or CD submissions are accounted for. Every year
EPA defines the range of documents to be audited. As such, MTS has to be designed to accommodate
different ranges of documents. Since no paper copies are produced in NCS and submissions will be
50 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
electronic as well, audit will be a minimal process and the possibility of encountering unaccountable
documents will be small. The audit only pertains to documents that exist in MTS, and not documents that
exist in CBITS.
Overall Process
T "
V to audit J
/'request system admin to process X
status of document not found ~J
^ Audit Non Electronic )
V Submissions S
1
('compare physical document ^\
V status with electronic status J _^
¥
[ exists physically but not in MTS ] "]
/^ notify auditor that >y ^ ^ f audit passed X
V document is not in MTS J^ "^^^^ ^*V s
[ exists in MTS t
\
ut not exist physically ]
f <
-------
MTS NCS Software Requirements Specification Model Report
Considerations
1. It will be very rare to have a document that correctly and physically exists in a case file, but that does
not exist in the system. In this case, the document will not have a DCN and it will be up to the NCS
System Administrator to add the document to the case file, if he thinks it is appropriate.
2. There is another process available to the Submission Processor to check if a physical document exists in
the system. It is called a completeness check by EPA and is done through the Perofrm Validation on
Barcode use case. Hence, audit is a second check and a variance is not expected.
3. If an unaccountable document is found and is added to the case file, the NCS System administrator will
change the electronic document status to active.
Workflow and Life Cycle Placement
Audit is an isolated, yearly event in the submission lifecycle. Once a year this process is followed to ensure that
the physical status of the paper or CD submission is the same as the MTS system status. If a document is in the
system and does not exist physically, the status of the document becomes unaccountable. If it exists in the
system, is physically located in the case file, and the status of the document is "unaccountable"; it represents an
unaccountable document that was found and the status of that document needs to be changed to "active" by the
NCS Application Administrator.
doc exists in MTS but not physicalK
[ doc exssts physically and in MTS ]
Unaccountable
[ doc exists in MTS but not physically
doc exists physically and in MTS with status "unaccountable"
52 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
Auditor
Audit Non-Network Submissions
MTS
Administrator
Change Document Status
Use Cases and Associated Activity Diagrams
Audit Non-Network Submissions
Description: This use describes the process of auditing non-network submissions (received on paper or CD)
that are active and have been assigned a DCN in MTS to ensure that EPA has the original copies of the
submissions. For CD submissions there may be one or several CDs, a cover letter, or a paper copy of the CD
content. Unique barcodes are placed on each item during the DCN generation process (see Generate DCN use
case). EPA maintains the paper and CD media in files in a secure area.
Actors: Auditor
53 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Audit Non-Network l\, f Actor has access to paper
Submissions documents and CDs
fDCN has been j ' only paper and CD documents
/" request to \
£~
/provide time ranqe ^
V, and audit criteria y
1
[ No ] <^""^><; /'determine f more documents ~\
^-^^ \ in case file to audit ^
[Yes]
^scan barcode or manually enter "\
1
( acknowledge message j^
' ^
V casefile audit report,/
\l
V unaccountable documents J
mail receipt date
start range and end
code, CBI
/^ request time range \
'v and criter a for audit J.
[ no results 1
^ ^^~~~~~..^ -/C provide error message "\
"\T regarding null results )
[ results ] |
V meet audit criteria /
^ present contents of the casefile with ~^
1
/ request input of DCNs "V
x^from paper or CD mediay
,-^ , /notify incorrect^,
[invalid]^ DCN format )
^
/Determine if DCN provided exists in ^\
^system casefile even electronically i ^
[ valid ] j"
This could be a l^| . matcn i /"update audit status for DCN to "audited", and "\
"found" document ><^~^> 5? save current date and name of auditor _}
~y [ no match ]
\ 1 1
^notify DCN exists in a wrong casefile N[ exists in MTSJ^\ ( provide success N
V. providing name of correct casefile y- "'~-~ nicaaagc ^/
\i [ DCN does not exist in MTS ]
/" update audit status of system documents \ wfsave current date and ^\
V not audited as unaccountable ~} "v name of auditor J
f present documents in the ^v
^case with their audit status ^
^-~- [ More cases ]
1
[Done]
V
/" present complete audit report for each case with ~\
V number of docs aud ted and docs unaccountable J
I
54 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
DCN Generation
Description
The DCN is the unique identifier that is assigned to a submission. When a document or submission is complete,
a DCN is generated. Every document in a case file has a DCN, including support documents.
For paper and CD submissions, in addition to a DCN, a barcode is also associated with documents to uniquely
identify and make the physical document official. A barcode label is created for physical versions of the original
submission, sanitized copy, incomplete documents, and support documents. Barcodes are handled very
carefully. Printing of a barcode is done by the system automatically at the end of the Generate DCN use case.
The only exception is when the NCS Application Administrator reprints a barcode in case of a printer failure,
stuck label, or some other mishap. Each day, the barcodes generated during the day are checked with their
system existence. If there is a discrepancy, it becomes a potential violation.
There are several checks that are performed before a DCNI is generated for an original submission. Only when
the information in the submission is consistent and complete, is the DCN generated. A DCN for a support
document is generated only when the DCN for the parent submission it is associated with has been generated.
The consistency checks and completeness checks for the submission differs slightly with each Section 5
submission type. A list of checks is included in the appendix.
The format for a DCN is as follows:
DDDDMTTYYNNNNNN, where DDDD is a four digit document code, M is a letter media code, TT is a two
letter document type, YY is a two digit fiscal year and NNNNNN is a six digit sequential number that is
initialized at the beginning of each fiscal year. Each document code and document type combination has its own
55 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
series of sequential numbers. Please see the appendix for a description of document code, media code, and
document type for all section 5 submissions.
It is assumed that a DCN is generated after a paper submission has been scanned. If after scan editing, the
submission fails any of the consistency or completeness check, the submission edits are still saved, however a
DCN is not generated. On the other hand, if all checks pass, the system will generate a DCN for the submission.
If the submission is CBI, submitters are required to send a sanitized version of the submission. For CBI
submissions, the system also generates a barcode for the sanitized copy. The sanitized copy is transferred to
NCIC. Electronic sanitized copies are kept in MTS and not transferred to NCIC.
For NOC submissions, submitters are required to provide the DCN of the Section 5 submission that the NOC
submission is associated with. After a DCN for the NOC is generated, the original Section 5 submission is
updated to reflect the NOC it is associated with. Also, for NOC, a case number is not generated as it belongs to
the same case as its parent PMN or YSU. If the DCN of the PMN submission is not provided, a DCN for the
NOC is not created until the associated DCN is determined.
For consolidated submissions, the system will create one DCN for each chemical in the submission. The system
ensures that an appropriate number of sequential DCNs are reserved for the consolidated submission. Hence, a
set of DCNs, based on the number of chemicals in the submission, are reserved before the consolidated
submission information is edited or DCN generated.
Consolidated submission information consists of a consolidated flag, a primary DCN, and a PreCommunication
number (PC Number). A PC Number is originally provided by EPA, however, a company needs to provide it
for a consolidated submission. If a company does not provide a PC Number, RDMB determines it and
assigns it during prescreening. It is the consolidated flag together with the PC number and mail receive date
that uniquely identifies a consolidated submission. For example, if there is a PMN consolidated submission with
three chemicals, when the first chemical is added, the consolidated flag is set to "Y" and the PC Number and
Mail receive date from the submission is used. The primary DCN is the DCN of the first chemical in the
consolidated submission. For the second chemical in the consolidated submission, the consolidated flag is "Y",
the PC Number is same as the first one and the mail receive date is also same as the first one. Thus, a
consolidated submission will have "consolidated flag = Y", the same PC Number, and the same Mail Receive
Date.
Joint submission implies that two or more submitters are sending information about a submission. The
submission is not complete until information from all submitters is received. Even though there are multiple
mail receive numbers associated with a joint submission, there is only one DCN for a joint submission. A
primary submitter is identified by the submitters and is used for communication purposes i.e. as an "addressee"
when sending an acknowledgement letter, or an incomplete letter. The primary submitter is responsible for
informing other submitters in the joint submission regarding EPA communications.
A submission can be both a joint and a consolidated submission.
If the submitter abbreviation on the submission is "NeedToAdd", a DCN will not be generated as the submitter
has not been uniquely identified yet. Submitter information must be added to the system or resolved before a
DCN can be generated. Once a correct submitter abbreviation is associated with the submission, the submitter
56 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
abbreviation value is reflected back in the Mail Log as well. A latest mail date on the submission is used to
indicate the latest date any additional information was received from the submitter.
The CBI flag on the submission identifies if the submission contains any classified information. Minimally, this
information is provided before a submission can be saved. If the submission contains classified information, the
submitter also provides information regarding which data is claimed to be classified. There can be more than
one type of information that can be claimed as CBI. For all section 5 documents, CBI claims are the same. They
are:
Submitter
Chemical
Volume
Use
Plant Site
Process
Properties
Exposure
Environmental Release
Other
CBI "other" claims (only valid if CBI claim is "other") are only provided for some section 5 documents. Note
that the LVM and TMEA submissions do not have any attachment pages as one of the claim categories. For
more information about the CBI claims and other claims, see the Appendix.
If "use" information is claimed CBI, then the submitter is required to provide specific use information and
generic use information. This data is checked during prescreening. Also, if the submission has been claimed
CBI, a sanitized copy must be provided by the submitter. Failure to have this information will prevent
generation of a DCN. The Prescreener will gather and wait for this information before moving a submission to
the next process. If the information does not arrive in a certain time, the submission is deemed "incomplete" and
retired.
Chemical information consists of chemical name and a CAS number. There is no one-to-one correspondence
between the CAS Number and a chemical name. MTS does not provide any verification on the chemical name
(this is done in TDTS). The name is manually checked by the Chemical Prescreener during the prescreening
process. MTS does check the CAS number for format.
Plant information in the submission is specific to the submitter. The plant site information is validated against
the existing plant sites for that submitter. If the plant does not exist, it is added for the submitter and in the
submission.
There are two other DCNs provided on the PMN form. One is called "Related DCN" and the other is called
"Related Original DCN". Related DCN refers to a DCN provided by the submitter that shows association
between this submission and some other submission. The only check performed on the related DCN is a
check to see if the DCN exists in MTS or CBITS and that it is in a valid format. Related Original DCN and
Parent DCN are used to show parent child relationship between certain types of submissions. For example, a
company sends a PMN notice before a NOC submission. The PMN DCN is the parent DCN for NOC, as a
57 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
NOC is a follow up for a PMN submission. If a PMN DCN is not provided for a NOC, the NOC submission
will not make any sense. MTS will update the related original DCN of the PMN with the DCN of the NOC
implying that a notice of commencement is related to pre-manufacture notice for a chemical. PMN is also
related to YSU (polymer exemption submission) and YSU also follows a PMN submission always.
Once a DCN is generated, an option to generate acknowledgement letter is provided. An acknowledgement
letter is generated to communicate the DCN and case number for the submission to the submitter so that they
can use it to send related documents such as a NOC or YSU in case of a PMN or related case number, or to send
support documents. It also serves to notify the submitter that their submission is complete and is under review,
the date the submission was received, and the review length for the submission. A letter is generated based on a
predefined template that can be changed by the user. The letter can be printed and mailed, or sent electronically
via email. For letters that are mailed, a mailing label can be generated using address information from the
submission. The letter is sent to the agent, if provided, or the technical contact that is specified in the
submission. If the letter contains CBI, then CBI procedure for generating a letter or email are followed. For
more information, see the Mail Management section. The Submission Processor can, alternatively, choose to
generate multiple acknowledgement letters at one time.
58 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
Submission Processor
V
1
v
request to view edit \~
submission J
request to
assign DCN
\l
request to generate
acknowledgement letter
request to transfer
sanitized to NCIC
/request to modify section \
\ 5 submission ;/
EPMN Lotus Notes
«use case»
View/Edit
Submission
[ Else ]
save edits
Consistency & completeness check passed ]
assign status of submission
"ready for DCN generation"
«use case»
generate DCN
«use case»
process consolidated
submission
send common submission
information to ePMN
«use case»
Generate
Acknowledgement Letter
«use case»
Transfer documents
to NCIC
s/lvlodify Section
y5 submissions
makes incomplete^discard
' ^^ changes
)elSel J/
save
modifications
receive
common data
59 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Considerations
1. Only sanitized paper copies are transferred to NCIC. Electronic sanitized copies are kept in the system
and are not forwarded to NCIC.
2. Consistency and completeness checks are performed after a submission is edited for scanning error fixes
or changes requested in support documents. If the submission passes these checks, the generate DCN
process is executed.
3. the MTS DCN format is different from the CBITS DCN format.
4. A barcode is generated for paper and CD submissions. Barcode generation is controlled by the system.
The NCS System Administrator is the only actor who can reprint barcode in case of a barcode problem.
5. NOC and YSU are follow-ups to PMN submissions. Hence, a PMN DCN is always related to NOC
and YSU submissions. NOC and YSU do not have a case number, but are instead maintained with the
parent PMN case file.
6. Consolidated submissions are uniquely identified by a consolidated submission flag, PC number, and
mail receive date.
7. Consolidated submission DCNs are supposed to be contiguous. However, if a chemical that pertains
to a certain consolidated submission arrives later, it will be given a non-contiguous DCN.
8. A joint submission has a joint flag equal to "Y" and the same TS Number for all submission parts. A
primary Submitter is identified to whom all the correspondence is addressed.
9. An acknowledgement letter can be generated right after a DCN is generated or generated later by
selecting from a list of submissions awaiting acknowledgement letters.
10. A submission can be modified so long as the edit does not make the submission or DCN invalid. The
same checks are made when modifications are made as when a DCN is generated.
11. The mail receive number may be modified. If it is modified, MTS will nullify all the mail specific
information in the submission and will request new mail information.
12. When modifying a submission, if the sanitized copy from submitter value is set to "Y" and then is
modified to "N", the sanitized barcode is invalidated and the barcode is deleted from submission.
It is up to the submission processor to ensure that physical sanitized copy does not exist. On the other
hand, if the sanitized copy from the submitter value was "N" and is modified to "Y", then a
sanitized barcode is generated, if there isn't one already. The user can generate an
acknowledgement letter when submission information is modified.
13. An acknowledgement letter is generated after a DCN is generated. The letter informs the submitter of
the review period MTS tracks the notice end date based on the review period, but does not do
anything if the review period goes beyond the assigned review period time.
14. The acknowledgement letter templates are predefined but can be edited by the Submission Processor.
15. A DCN cannot be generated for a submission if the submitter abbreviation is "NeedToAdd."
16. An Acknowledgement letter is automatically added as a support document by the system when it is
generated. This includes adding the image of the submission in the case file and adding support
document information.
17. The consistency checks exist for only BONA, LOREX, LOREXM. LVE,MCAN, NOC, PMN, SNUN,
TIER I, TIER II, TERA, TMEA and YSU. All other document codes do not have consistency checks
defined.
18. Required field checks exist for only BONA, LOREX, LOREXM. LVE,LVM, MCAN, NOC, PMN,
SNUN, TIER I, TIER II, TERA and TMEA . All other document codes do not have required
field checks defined.
60 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
19. Case Number formats have not yet been defined for the following doc codes.
0022
0030
0034
0035
0052
8(b) Inventory Incoming (INV)
US Acts as Observer (PPO)
US Acts as a Secondary (PPS)
Us Acts as a Lead (PPL)
Section 5 Bona Fide Submission (BONA)
TBD
TBD
TBD
TBD
TBD
Workflow and Life Cycle Placement
The DCN is generated after the submission scan and subsequent edit to check scanning accuracy. If the
submission passes consistency and completeness checks, the system will generate a DCN based on predefined
rules and print barcodes to be affixed on the submission and a sanitized copy, if applicable. There is a state
associated with the submission before a DCN is generated. It is called ready for DCN. Once a DCN has been
generated, the submission goes into a state called "Active". Once "Active", the submission can go into "retire",
"transfer", "unaccountable", or "user fee paid" states. Only paper sanitized copies are transferred to NCIC.
When a submission is "unaccountable", it implies that a record of the submission exists in the system, but no
physical record exists. The following diagram illustrates various states of DCN generation process.
61 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
edit[ consistency and completeness failed
edfl[ consistency and completeness checks pass
Ready for
DCN
retention perio^expires/ withdrawn or modi
sanitized paper copy
Unaccountable [gone] Violated
Once a DCN is generated, an acknowledgement letter is generated. The letter can be generated right after the
DCN or can be generated later in a batch mode. If the latter happens, the submission status changes to "awaiting
acknowledgement letter". Once the letter is generated, the status changes to "active".
When a submission is modified, changes should not make the submission "pending" or incomplete, i.e., it
should not fail any checks that are performed when a DCN is generated. If that happens, edits are discarded.
Therefore, the modify process for submissions with a DCN assigned will make sure that the submission remains
in "active" state.
In terms of workflow, a submission can be saved in a state such that a DCN cannot be generated. However, in
order to get a DCN, a submission must pass several checks. Hence, after the edit submission process, if a
submission passes consistency and completeness checks, a DCN is generated.
62 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
Modify Section 5 Submissions
x «include»
Submissio
Processor
Generate Acknowledgement
Letter
/N
«include»
Generate DCN
«include»
«System Actor»
Lotus Notes E-PMN
Process Consolidated DCN
63 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases and Associated Activity Diagrams
Generate DCN
Description: The use case describes the process of generating a unique document control number (DCN) for an
MTS original submission. Before the DCN is generated by the system, a consistency check is done on the data
fields. MTS also checks data fields to ensure they meet business rules, e.g. if data is required in the field that it
is present and valid. The submission must have a valid submitter abbreviation assigned versus the "need to
add" placeholder. After the DCN is generated, a barcode is printed out for non-electronic submissions. DCNs
for documents other than original submission are generated through the Process Support Document use case
or the Process Replacement Support Document use case. DCNs for incomplete submissions are generated
through the Process Incomplete Submission use case
Actors: Submission Processor, EPMN Lotus Notes
64 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
65 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
66 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Process Consolidated Submission DCN
Description: The use case describes the process of generating a unique document control number (DCN) for
each chemical that is part of a consolidated submission. The system will generate sequential DCNs for the
chemicals in the consolidated submission. This use case is an extension of the Generate DCN use case.
Actors: Submission Processor
67 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
68 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submission Processor: Submission Proc...
Process Consolidated
Submission DCN
edit each chemical
record as appropriate
: MTS
DCN process is in progress for
a consolidated submission
Determine number of chemicals in
consolidated submission
V
reserve sequential DCNs equal to the
number of chemicals
Y
assign first DCN as the primary DCN
/'create one record for each chemical and \
V replicate submission information for eachy
V "
_/" present record for ^
yeach chemical for edit
notify of error
in information
/obtain consistency rules for this document type
and perform consistency check
consistent
perform required field check for this
document type
\ complete
/"generate DCN for each chemical,
V making first chemical the primary DCN
return to Generate
DCN use case
69 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Generate Acknowledgement Letter
Description: The use case describes the process of generating an acknowledgement that is sent to submitters
when their submission is considered complete by EPA. This letter is not generated until a DCN exists. The
Submission Processor can generate the letter immediately after generating a DCN or at some point after. The
DCN number is included in the letter for the submitter's use on any future support documents.
Actors: Submission Processor
Diagram:
Submission Processor: Submission Processor
Generate
Acknowledgement Letter
1
request to generate
acknowledgement letter
[else]
[requested as part of DCN generation
select DCN from list
edit acknowledgement text and
CBI status as appropriate
DCN for original submission has been generated
Barcodes have been printed for
non-network submissions
c
provide list of DCNs awaiting
acknowledgement letter
A
^ prepopulate DCN data based on ^
\^ DCN that was just generated J
DCN, CBI (y/n), document
type, joint submission,
consolidated submission,
email or print option.
/" provide acknowledgement letter template listing one or multiple DCNs with
~r^ recipient data, agent if cited, or technical contact, and identify if CBI or not CBI
/''save acknowledgement letter as PDF, generate support document DCN
~^ and related metadata, and place copy in case file of DCN
V
/'save CBI status \
^F
prepopulate outgoing
mail metadata
[ email ]
[paper]
«use case»
change status to awaiting
outgoing email
«use case»
change status to awaiting
outgoing mail
70 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Modify Section 5 Submission
Description: The use case describes the process of editing the content of a submission after it receives a DCN.
(See the View Edit Submission use case for modifications before a document has a DCN.) The MTS user may
edit certain fields as defined in the Modify Section 5 Submission data spreadsheet.
Actors: Submission Processor
Diagram:
: Submission Processor
Modify Section 5 L^.
Submissions
T
/^ request to modifv ^\
\^ submission ^/
f provide DCN ~\
V )
[edit]
V
f editfields as ~\
^provide reason ^\,
\^ for edits y~~
: MTS
f Submission has "1
DCN
V J
^/'request DCN of^
^\^ submission ^J,
~^^^ [invalid] / provide error \
^X^^^1 ^x^ message J
^alid]
/'present submission in same format as print form N
*y and allow edit of modifiable fields J.
l\
f check for "N ^^^^^er'3!'r' provide consistency "\
5\^ consistency ^/ ^^^^ ~\^ error message y
[valid]
/^ checkfor ^ .^^ [ error] /'provide required field ^s
\^ required fields y '><^^^^> -"v error message J
/'request reason"^ [vaMH]
V^ for edits J
save edits, reason, ^\ -^/^^\
user name, date, time J ^^SJ
71 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Userfee
TS Number
PaymentID
Company Name
FMDScheduleNumber
Status
CaseNumber
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
ChemicalName
GenericUse
Specificllse
Maillnformation
UserfeeStatus
Related DCN
RelatedOriginalDCN
Support DCNs
Consolidated Flag
PCNumber
TS Number
PaymentID
JointFlag ,
CBI
CBICIaim
CBIOther
DCN
Sanitized Flag
Sanitized DCN
Plant
PlantID
PlantAddress
SitelDFromFRS
SubmitterAbbreviation
0..nA
TechnicalContact
Name
Address
Telephones
Emai (Addresses
SubmitterAbbreviation
l.n
Interfaces with Other Systems
Description
MTS interacts with several systems to exchange information. The systems MTS interacts with and their
interactions are described in the sections below.
E-PMNNotes
72 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Interaction with EPMN Lotus Notes system primarily consists of transfer of data from MTS to EPMN notes and
then import of data and files from EPMN Notes. The former transfer of data is covered in DCN generation
module.
MTS exports certain data to EPMN notes when a submission DCN is assigned. This is done automatically by
the MTS system. A set of common data fields, identified before, are sent. This is incorporated as a part of the
DCN generation use case.
MTS also imports data and files from the EPMN Notes system. The data imported consists of common
information between the two systems and unique information from the EPMN Notes system. The common
information in MTS is updated with the information from EPMN notes, while the original information from the
submission is maintained. The unique information is overwritten and not tracked.
MTS interacts with EPMN notes to transfer chemical structure search results from MTS that were obtained
from ACCELYRS. This is depicted in the "Search chemical structure" use case.
MTS imports files from EPMN Notes system as well. Each file has a PMN number, which is the same thing as
the case number of the submission, associated with it.
FMD
Interaction with FMD is only one way. User fee information is pulled by MTS every night. This is described in
the user fee use case called "Get user fee information from FMD". The information obtained includes FMD
sShedule number, fee receive date, company name, TS#, payment ID, and user fee amount. If there are multiple
TS numbers associated with a single amount, it is assumed that FMD will create separate records for each TS
number and will associate the same amount and Payment ID with each TS Number record. This information is
used to associate user fee with the submission. No information is provided back to FMD at this time.
CBITS
CBITS is still a crucial piece of PMN processing. Until all records are migrated from CBITS, CBITS will have
to be up and running. Furthermore, any support document whose parent original is in CBITS, will be processed
in CBITS and not in MTS. This is an important decision that will impact processing. This means, CBIC will
have to continue processing some PMN support documents like they have in the past.
TSCA section 5 clearance information is also obtained from CBITS. The AXCON module from CBITS tracks
users and their clearances. MTS will utilize CBITS functionality to check for the clearances and will not
maintain this information within MTS. This is reflected in Access MTS user use case.
Submitter information from CBITS will be migrated into MTS prior to MTS deployment. Thereafter, submitter
information will be maintained in MTS. Also, user fee information will also need to be migrated into CBITS
one time prior to deployment of MTS. Since new user fee information is different from CBITS user fee
information, any changes or additions will be applied in MTS as the information is migrated.
ACCELRYS
73 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
ACCELRYS is used to perform chemical structure searches. MTS will use ACCELRYS to do chemical
structure searches and then use the search results for other purposes i.e. print, save, export to a specified
location, transfer to EPMN Notes, and create support documents.
FRS
FRS is used to obtain facility ID information. This information is captured from FRS manually and saved in
MTS. The process of obtaining this information is captured in the" Add Submitter Information" and the
"Maintain Submitter Information" use cases.
TDTS
The TSCA Data Transmittal System (TDTS) is a Lotus Notes-based system that interfaces with the Chemical
Abstract Service (CAS) to determine if chemicals submitted for EPA review are on inventory or not on
inventory. Chemicals that are on inventory do not have to complete the review process for new chemical
submissions. MTS will send and receive information from TDTS to support identification of on inventory
chemicals. Inventory Chemists will review submission that have received a DCN in MTS and identify data and
file attachments that will be sent in PDF format to TDTS. The Inventory Chemist will provide special
instructions to CAS as well as appropriate notations. The Inventory Chemist will not send data to TDTS for
every submission. The data that is sent is similar each time but differs enough that it is not efficient to have the
system preselect it.
Outside the scope of MTS, TDTS interfaces with CAS and receives a results file regarding the status of
chemicals in a submission. The Inventory Chemists reviews the results file in TDTS and when the review is
complete, the chemist flags the results file for transmittal to MTS. The chemist also provides an inventory
status, comments on CAS results, CAS regulatory comments, trademarked registered information, and any
refund request for on inventory chemicals. MTS will pull data from TDTS on a daily basis and save the
information in appropriate case files. If a chemical is on inventory, MTS will initiate notifications regarding on
inventory letters and refund requests.
Overall Process
E-PMNNotes
74 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
System Clock
I
v
/request to export PMN X
V data to EPMN Notes J
--/" request to import data "N
X from EPMN Notes ~)
-S request to import files X
X from EPMN Notes }
MTS
_^/-«usec...»^
• ( send data to )
VePMN Notes y
S «usecase» X
*••. 1 Import Data from ]
V ePMN Notes I
f save data v
•
/" «usecase» X
^ I Import files from J
\ ePMN Notes y
^.
\l
f «use case» ^\^W^6\
f add files as J ~^^B)
, , v internal support/
* '
/~ «usecase» X ^^t\
( capture outgoing J ^^^5'
V mail information /
EPMN Notes
< receive and update data X
with received data J
1
4
-^f provide data ^
\ J
)
_}
^/^ provide files and ^\
"\ information J
15 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
FMD
System Clock
T
f Q6t data from "\
v FMH /
MTS
^ request to aet userfee "\
-V data from FMD }
f Get Userfee N
V Information from FMD J
\l
m
FMD
^^ provide FMD ^
-^V data J
CBITS
76 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Application Ad
\
f request to
V submitter in
mini stra tor
[ F1
import X
ormation J
7 request to import X
V userfee information J
Submission Processor
•
aper]
f" request to capture support X
V document information J
t
( provide parent ^
V DCN J
|
^
MTS
^
^request parent > ( obtam Parent ^
^V DON J V DCN y
\l/
> y process support \
^-^^-- ^ document J
[ invalid DCN ]
A: heck if exists^.
V in CBITS }
\l
/^fc\^ /^notify invalid or non ^^^^l^-
^Sf^ V existent DCN J~NO 1^^^
w[yes]
/^notify that parent document in CBITS ^\
V and need to be processed there J
4
V
--, /- ,-,-Lisa ^33^-=.-=. \ /«usec...» \
"( access MTS ) ( Add MTS J
V y V user y
|
( Import submitter j MjB)
V information s ^~~^
(«usecase» X -_>
information J
CBITS
^_f provide access to "^
''Voriginal documentsy
4
ACCELRYS
77 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
EPMN Notes
receive search
results
T
request to search for
chemical structure
«use case»
search for
chemi...
obtain results
J
[ File ]
[ Print ]
sa\e results
/'export results
V to a file
c
print results
transfer results
to EPMN Notes
«use case»
submit internal
support document
execute query
78 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
FRS
NCS Application Administrator
1
request to add
submitter information
request to maintain
submitter information
import submitter
data from CBITS
/'request to lookup site
V information in FRS
note site ID
\/
Request to maintain
submitter information
/'provide site I
«use case»
Add submitter
information
(«use case»
maintain submitter
information
«use case» \
Import submitter )
information from CBITS /
obtain site
information
provide site
information
/^ «use case»
•M maintain submitter
\^ information
^
_Y~ request sitelD \
capture sitelD
for later use
f provide site
'y match
/
provide match Xs
results J
( Else ]
[ Nb match ]
notify no
match found
MITS
«TBD»
79 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
TDTS
Inventory Chemist
Overall TDTS
Diagram
t
( provide comments
and CBI status
request to identify data
to be sent to TDTS
Original submission has
received a DCN
provide submission and
request page selections
request special instructions^,
and CBI status }
save PDF and
request notations
'save PDF and N
sent to TDTS }
c
obtain data
from TDTS
f process each results file and \
X^place in appropriate case f\\e(s)y
/'confirm receipt X
\^ of PDF }
_
f send PDF and any required
V information to CAS
/'receive and review
V CAS results
provide status and
comment fields
V ~
/'flag results for
\^ transmittal
''review chemical data^N
and provide results J
Considerations
For all systems that MTS will interact with, interface agreements need to be developed. For instance, the
tagging of files and data within EPMN notes need to be developed.
EPMN Notes
a. Type of data transfer done between EPMN Lotus Notes and MTS need to be determined. It may
be ODBC or Web Services. EPMN may update their database in the near future.
b. EPMN Lotus Notes will have a "complete" or some other trigger field to identify which data is
ready to be pulled into MTS.
80 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
3. TDTS
a. The TDTS server is not currently part of the CBI local area network. EPA is coordinating
inclusion of TDTS in the CBI local area network, but if there are technical issues this could delay
the completion of this interface.
b. TDTS will require modifications to support the interface to MTS because TDTS does not
currently have the fields identified in the MTS requirements. Also, MTS requires specific data
on each chemical in a consolidated submission to accompany the one results file that is provided
by CAS.
c. Inventory Chemists should receive training in how to complete the fields that will be transmitted
to MTS. For example, for multi-component chemicals the comments on CAS results needs to
identify the results for each chemical in the multi-component chemical for use in later reviews
since there is only one status field for this type of submission. If some, but not all, chemicals
involved in a multi-component chemical are on inventory the inventory status should be recorded
as on inventory multi-component. Refund status options and inventory status options should also
be detailed to ensure consistency in use.
d. TDTS is available to users from 6:00 a.m. to 6:30 p.m. Monday through Friday. This may affect
when MTS should pull daily data from TDTS.
e. MTS requirements assume that TDTS will perform validation checks on data before it is passed
to MTS. These validations include:
• If the inventory status equals on inventory, then the refund from TDTS status can be yes or
no
• If the inventory status equals on inventory multi-component, then the refund from TDTS
status should be no
• If the inventory status equals not on inventory, then the refund from TDTS status should be
no
• If the inventory status equals incomplete, then the refund from TDTS status should be no.
Workflow and Life Cycle Placement
Use Cases Involved
E-PMN Notes
81 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submission
Processor
Generate DCN
Search for Chemical Structure
«System Actor»
Lotus Notes E-PMN
Import data from ePMN Notes
System Clock
Obtain files from ePMN Notes
«extend» ^ ^x
«extend»
Submit Internal Support
Documents
Capture Outgoing Mail Information
Submission
Reviewer
Mail Clerk
FMD
«System Actor»
FMD System
System Clock
Get Userfee Information from FMD
82 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
CBITS
Submission
Processor
NCS Application
Administrator
Submission
Reviewer
MTS General User
ACCELRYS
*Process Support Document
Import Submitter Information
Import Userfee Information
Add MTS User Information
Submit Internal Support
Documents
Access MTS
«System Actor»
CBITS
83 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Chemist
Search for Chemical Structure
«extend»
Submit Internal Support
Documents
TDTS
Insert Inventory Chemist Diagram
«System Actor»
Lotus Notes E-PMN
«System Actor»
ACCELYRS
84 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases and Associated Activity Diagrams
Note that uses cases that relate to specific MTS modules are shown in the specific module sections.
Search for Chemical Structure
Description: This use case describes the process of searching databases in MTS for chemical structure
information. The chemist searches data to find structures needed to complete new chemical reviews or reports.
Searches may also be used to answer questions from EPA staff. The actual search is done using Accelrys. The
Chemist may choose several output options including transfer of chemical structure search results to EPMN
Lotus Notes.
Actors: Chemist, EPMN Lotus Notes, Accelrys
Diagram:
C,8m,s,
Search for Chemical structure "|
Chemical data exists in MTS
Structure 1 >
Link exists to transfer chemical
structure data to ePMN
T
f request to search for "\
V chemical structure J
\f
/'select search "\
V form J
< provide parameters \
for search J
view results
• \, A
V
f select output "\
V option L
(»' S
^^/[ done 1 ^~~~~\^ ,
1 J [ else ]
r i i i \l'
[ i, .a igc aca i, ' 1^*. /" provide file name and "\
C^^^f exporEy location for export J
[ save ^
^select information from \
V search results to save J
S «use case» ^support do?J
V Support Document s \
[ transfer ]
:MTS
^/r provide list of "\
\. search forms J
£ provide selected search form "\
\" and request parameters J
\ A
\\/ . . ....
^^^ L iiivdiiuy- provide error message "N
<^~~~^> ^\_ regarding invalid data J
[wild] \!
f provide search ^
V results to Accelrys J
\
(present results ^\^
7s
^f export file "\_^^J\
^/'save selected ^\
^V information J
\l
/'verify Chemist wishes to transfer "\
•f transfer information "\
^ toePMN Notes }
: ACCELRYS
^/'perform search "N
"A^ J
V
(provide results "\
)
ePMN Lotus Notes
/[ save chemical structure ^\
V information for use in reports J
I
85 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Import Data from EPMN Lotus Notes
Description: This use case describes the process of pulling data fields from EPMN Lotus Notes to MTS on a
periodic basis. MTS will import the data fields that were sent to EPMN through the Send Data to EPMN Lotus
Notes use case after they are updated by EPMN Lotus Notes users. The imported fields will not overwrite the
values saved in MTS, both the original data and the EPMN edited data will be maintained. MTS will also
import data fields that originated in EPMN Lotus Notes to support PMN reporting requirements.
Actors: EPMN Lotus Notes
Diagram:
EPMN Notes
I Im port data from ePMN~L^
Lotus Notes
MTS is triggered by preset
pull time (i.e., nightly pull)
1
request to get ePMN
Lotus Notes information
add common fields into MTS database while maintaining
original snapshot of submission data before ePMN updates
V
capture unique fields received from ePMN
notes to be used for reports later on
/^provide ePMN Lotus Notes information
"^ that is "complete" since last pull
86 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Obtain Files from EPMN Lotus Notes
Description: This use case describes the process of pulling data files from EPMN Lotus Notes to MTS on a
periodic basis.
Actors: EPMN Lotus Notes
Diagram:
WITS
Obtain files from
ePMN Lotus Notes
r
MTS is triggered bythe predefined
time period, i.e., 24 hours
ePMN Lotus Notes has tagged
files for upload to MTS
MTS requests
files
S Add files to
V appropriate case files
[else
change status to awaiting
outgoing mail
\l
(«use case»
Submit Internal Support
Document
ePMN Notes
ePMN provides files tagged for upload to
MTS noting if outgoing mail is required
87 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Import Submitter Information
Description: The use case describes the process of moving submitter information from CBITS to MTS.
Actors: NCS Administrator, CBITS
Diagram:
NCS Application Administrator
Import Submitter Information AD
1
request to move submitter
information from CBITS
select one
obtain submitter
information from CBITS
[ Done]
Else]
Determine if CBITS submitter partial name and
zipcode match MTS submitter name and zipcode
: Else ]
[ Match(s) ]
present matches and
request to select one
Add submitter \,
information
FRS Site ID can be looked up and added
later via Maintain submitter information.
provide submitter
information from CBITS
88 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Import User Fee Information from CBITS
Description: The use case describes the process of moving user fee information from CBITS to MTS.
Actors: NCS Administrator, CBITS
Diagram:
NCS Application Administrator MTS CBITS
Import Userfee Information AD
1
request to import
userfee records
et userfee information for all records
that are not associated with a DCN
[ done ]
else ]
map CBIS userfee information to
MTS userfee information
\/
.'Determine if TS Number,
V company Name provided
. No l/'Save userfee information with
^ "Incomplete" status
[Yes]
Save userfee information with
"Unassociated" status
/'provide userfee \
information J
89 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Get User Fee Information from FMD
Description: This use describes the process of receiving information from the EPA Financial Management
Division (FMD) system regarding user fees paid by submitters. Submitters pay fees through a bank. EPA FMD
then receives bank data and maintains it in the FMD system. MTS users require user fee information from
FMD to ensure that a submitter has correctly paid for submission processing.
Actors: FMD, System Clock
Diagram:
Get User Fee Information from ^
FMD
T
(request to get user fee "^
Submission userfee status: 1^
naid, unpaid
V' request userfee
"V information from F
f capture userfee information >,
'v from FMD 7~
I
( for each userfee, determine if TS# and
V, Submitter Name is provided
J/ [ Else ]
<^\ -f assign sta
~^~~-^ V 'incomplete'
[ Company name and TS# provided ]
V v
/'assign status of userfee to "\ / «use c
V be "unassociated" J / Complete
y V Inform
Associa e Userfee j
with Submission J 3t
T «
m
User fee
informal io
userfee with submission
User fee status: k.
Incomplete, associated,
associated - insufficient funds,
associated -funds left,
unassociated, refunded, refund
needed, refund requested.
\
ADJ
3
us of N
userfee J
ase» X
Userfee
a ion J
•)
processor will obtain more
n to make userfee complete
Received user fee
information from the bank
If multiple TS Numbers are provided for one payment ID, the amount
provided for that payment ID is same for all TS#s for that payment ID
V information to MTS }
FMD schedules, Payment ID,
Submitter Name, TS#, Fee receive
date, amount received, Check
description, Deposit date, Deposit
number, Name of remitter, FMD
schedule total
90 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Identify Data for TDTS
Description: This use case describes the first step in the process of identifying if a new chemical is already on
inventory. MTS will interface with the TSCA Data Transmittal System (TDTS). MTS will allow an inventory
chemist to select data to be sent to TDTS in a PDF file. Information is not requested by the inventory chemist
for every submission, and the information sent may differ between submissions (although it is often similar).
The chemist may save a draft of the information that will be sent to TDTS prior to creating a PDF, then reenter
this process at a later time to finish and send the data to TDTS. Outside of the MTS system, TDTS interfaces
with CAS. If CAS does not accept the data request, the Inventory Chemist may repeat this use case by entering
the appropriate DCN and creating a new PDF to send to TDTS.
Actors: Inventory Chemist, TDTS
91 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
92 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Obtain Data from TDTS:
Description: This use case describes the process of pulling data on a periodic basis from TDTS and placing the
data (a results file and four fields) in appropriate case files in MTS. Inventory Chemists review CAS results in
TDTS then determine the chemical inventory status, any refund requests, and comments on CAS results. When
the review is complete, the chemist flags the file and its related fields for transfer to MTS. The Inventory
Administrator is notified of chemicals that are on inventory so they can create required on inventory letters in
ePMN Lotus Notes. The system uses the business rules in this use case to set refund field values (user fee status
and refund comment) that the User Fee Processor will use when processing refunds. A comment on regulatory
information and a trade mark registration (TMR) flag will also be provided by the Inventory Chemist to ensure
proper processing of inventory information.
Actors: TDTS
93 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Obtain data
from TDTS
Required time period has
been reached, e.g., 24 hours
TDTS has performed error checks on
data being passed to MTS
c
I
request data from TDTS that is new
since the last data pull
(
_
verify DCN related to results
file and data exists in MTS
[else]
[exists]
\
<>
consolidated ]
c
send error
notification to TDTS
save results file into
each related case file
discard results file and
data fields forthis DCN
save results file in case
file related to DCN
save inventory status, comment on CAS results
CAS regulatory comments, TMR, and refund status
save inventorystatus, comments on CAS results, CAS regulatory
comments, TMR, and refund status for each DCN into appropriate case file
\\l [at least one on inventory]
send notification of on inventory
status to Inventory Administrator
~
[not "on inventory and not "on inventory mur
send notification to
Inventory Administrator
determine if all chemicals in consolidated
submission are on inventory
\|/ [all on inventory]
'mpon
set userfee status related to consolidated
submission to "refund requested"
• set refund comment
^equal to "on inventory"
C
verify if there is more data
from TDTS to process
\/
no refund requested ]
refund status = yes ]
set userfee status related to
DCN to "refund requested"
/'set refund comment'V.
to "on inventory" J
[ more data ]
no more data ]
provide new data
94 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
EPMN Notes Business Entities
EPMNFiles
CaseNumber
OutgoingMailFlag
SupportDocumentFlag
FileLocation
Filelmage
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckllserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
ChemicalName
GenericUse
SpecificUse
MailReceiveNumber
BarcodeSanitzedFlag
UserfeeStatus
RelatedDCN
RelatedOriginalDCN
SupportDCNs
ConsolidatedFlag
PCNumber
TSNumber
PaymentID
JointFlag
CBI
CBICIaim
CBIOther
DON
SanitizedFlag
SanitizedDCN
SanitizedStatus
BarcodeOriginalFlag
JointMailReceiveNumber
DaylReviewDate
NumberOfChemicals
RetireCaseStatus
ViolationStatus
EPMNNotesCommonlnformationHistory
CaseNumber
DON
DateUpdated
TimeUpdated
EPMNNotesUniquelnformation
CaseNumber
DCN
95 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
FRS Interaction Business Entities
SitelDFromFRS is
stored here for
future use.
Submitter
Abbreviation
Name
Address
Technical Contacts
Plants
Official Agent
A
On n
Plant
PlantID
PlantAddress
SitelDFromFRS
SubmitterAbbreviation
CBITS Interaction Business Entities
96 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
1!
AXCONUserlnformation
CBICIearanceFlag
SectionSCIearanceFlag
UserlD
SSN
ActiveFlag
Support Document
DON
Barcode
Barcodeflag
SanitizedCopy
SanitizedBarcode
MailReceiveNumber
SubmitterAbbr
ParentDCNs
Comments
Status
CBI
DocumentCategory
DocumentType
Receive Date
DocumentSource
StaffAuthor
CBITS DocumentType
DON
CBITSSubmitterlmportlnformation
CBITSPIantlnformation
Userfeelmportlnformation
CBITSTechnicalContactlnformation
ACCELYRS Interaction Business Entities
ChemicalStructureSearchResults
ChemicalStructure
FMD Interaction Business Entities
FMDInformation
TS#
FMDScheduleNumber
ReceiveDate
Amount
SubmitterName
PaymentID
PaymentCode
Userfee
TSNumber
PaymentID
Company Name
FMDScheduleNumber
Status
CaseNumber
UserfeelD
97 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Mail Management
Description
Incoming Mail
While submissions can arrive through CDX (the network), most of the submissions arrive through U.S. mail.
Submissions arriving through the mail can be in paper or CD format. To be consistent, even though network
submissions do not arrive through traditional US Postal service, MTS still tracks submission arrival data.. MTS
also tracks information about all submission related information that leaves EPA. These two processes have
been classified as incoming mail and outgoing mail respectively.
When the submission first arrives at the EPA, its mode of arrival, date, time, postmark date, and submitter
information is captured. A unique number, called a Mail Receive number, is generated to identify a
submission's arrival. This number, in conjunction with other information, is used to identify a submission until
a case number or a DCN is generated.
The system assigns a "need to add" submitter abbreviation to incoming submissions. During prescreening, the
Prescreener will determine the correct existing submitter abbreviation or request the addition of a new submitter
for this submission. This abbreviation is temporary and helps avoid duplicate data being added into MTS. By
the time a DCN is generated, the "NEEDTOADD" abbreviation must be replaced with either a new
abbreviation or an existing abbreviation. Mail information captured can be edited and is one way to assign
appropriate submitter abbreviation to the submission.
For submissions arriving through the network CDX, a copy of the submission is sent back the submitter through
CDX. A copy of the paper and CD submissions are not sent back to the submitters.
Outgoing Mail
Outgoing mail captures information and provides processing for mail that is sent to a submitter. Outgoing mail
can be sent through the postal service or via email. MTS provides support for both types of mail. If mail is sent
through the postal service, MTS generates and allows the user to print mailing labels.
Any CBI mail must include a cover sheet that indicates that the contents are CBI. This cover sheet is manually
placed on the outgoing mail and is not generated by MTS. This is an indication to the submitter that the contents
were checked by EPA before they were mailed out.
MTS captures mailing information and prints mailing labels for the outgoing mail, in the case of paper
submissions.
Outgoing mail for NCS supports only the letters that MTS generates and assigns a status of "awaiting outgoing
mail" status. The letters that are generated by MTS and pertain to outgoing mail are:
• Incomplete letter
• Acknowledgement letter
98 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
A unique outgoing mail ID is generated that can be used to identify outgoing mail information that is to be
edited. Alternatively, a search capability is also provided.
99 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
i : : sir
Overall Process
C
T
(request to process ^N
V incoming mail y^
/'request to edit
V incoming mail
c
confirm
(
request to process
outgoing mail
request to edit
outgoing mail
[ Paper ] ^ «usecase» \
^f capture incoming J
ypapermail informationy
[CD]
[ Network ]
«usec...»
Mew/edit
incom...
c
«usecase»
.CD mail information
-^/ «use case»
1 capture incoming
V network m...
x *
/ «usecase»
f send copy of
V electronic submission
determine if duplicate ~^_
submission y-
upload CD
information
J>
i E|se i
[ Coh-upt CD ]
«usecase» N
f Retire incomplete or J
V replaced document y
retire incomplete or
replaced document
/" determine if both pieces of \
V joint submission ha\e arri\ed ^
No]
[ Postal ]
[ Email ]
«usecase»
capture outgoing
mail information
«use (...»
SendCBI
Email
View Edit
Outgoing Mail
«use case»
View returned
emails
/determine if CBI changed^,
V from NCBI to CBI y
100 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Considerations
1 . If a submission is a duplicate submission, which may not be determined easily until much later in the
life cycle, one of the submissions is retired. If the duplicate submission was sent in a different mode that
the original (i.e. one was paper and other was electronic), the paper submission is retired and the
electronic submission is used.
2. For a joint submission, there may be two mail information records associated with the submission. The
submission does not proceed to the next step of prescreening until all submissions that make up a joint
submission arrive. When the two pieces of submission arrive, one MR# (the one from the primary
submitter) is used for the subsequent processing. The mail information for the other piece is still tracked,
but as related mail information for the submission.
3. Day 1 review date and time is defaulted to the date and time the mail receive number is assigned.
4. For network submissions, mail information is automatically created. The submitter abbreviation is
assigned to be "NEEDTOADD" in this case. When the correct submitter information is identified, the
abbreviation is replaced.
5. For network submissions, a copy of the electronic submission received is sent back to the submitter
through CDX.
6. Certain information about incoming mail such as the postmark date or the mail tracking number does not
apply to Network submissions.
7. Outgoing mail can be sent via postal service or email. In both cases, there are processes and procedures
that are followed. CBI email can only be sent through CDX.
8. If the contents of an outgoing mail package are CBI, the outgoing mail package becomes CBI. Also, if
the contents are non-CBI, but the submitter and/or technical contact or agent have claimed to be CBI,
the mail becomes CBI. Even though system makes a determination based on these rules, the ultimate
decision lies with the Mail Clerk to designate if mail is CBI or not.
9. CBI mail is encrypted if sent via CDX email and is sent through certified mail, if sent via postal service.
10. For network submissions, it is assumed that MTS will be notified when a new submission arrives.
11. The following table shows information about the outgoing mail for CBI and Non-CBI packages:
CBI Packages Non CBI Packages
Always sent via certified mail, when sent through
postal service
Three mailing labels are printed
Mail is CBI, if any one or combination is true:
• contents are CBI
• submitter has been claimed as CBI
• agent or technical contact has been claimed as
CBI
If sent via email, the email with attachment needs to
be encrypted
May or may not be sent via certified mail
sent through regular First Class Mail.
. Generally
One mailing label is required
Mail is non CBI if all are true:
• contents are Non-CBI
• submitter has not been claimed as
• agent or technical contact has not
as CBI
CBI
been claimed
The mail is not encrypted.
12. Mostly letters or correspondence with "awaiting outgoing mail" designation is sent via outgoing mail.
This includes acknowledgement letters and incomplete letters from prescreening. However, any other
correspondence can also be sent through outgoing mail.
101 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
13. MTS provides the capability to view returned emails. Alternatively, the user can just log into the email
account and view undelivered emails.
14. If a submitter uses the same TS# for different submissions from their company, MTS would have a data
problem if the submitter were to send two joint submissions with another submitter - submitter B for
instance, and use same TS Numbers for both joint submissions. In this case, MTS will have four MR#
with four submissions and will not know which pieces are connected together. This is an unresolved
issue and its chance of occurrence is very low.
Workflow and Life Cycle Placement
Incoming Mail
Incoming mail is the first step in the lifecycle of a submission. This is where it is received and enters the MTS
system. Once a submission gets a mail receive number, it moves to prescreening, which is the next life cycle
phase. The state associated with this is called "awaiting prescreening". If it is a joint submission, the submission
stays in the same phase, until the other piece of the submission arrives. The waiting state assigned to the
submission is called "awaiting joint submission". If it can be determined that a submission is a duplicate of
another, one of the submissions is retired and the other becomes active. The determination is based on the mode
of submission.
regular submission arrives and not duplicate
first peice of joint submission arrives
duplicate determination made
retire
A
Duplicate
Retired
\/
while other piece of joint submission arrives
V
Awaiting
Prescreening
both pieces of joint submission arrives / identify primary submitter and relate MR#s
Awaiting joint
submission
Outgoing Mail
For correspondence that needs to go through outgoing mail, a status of "awaiting outgoing mail" is assigned.
This happens when:
a) The Prescreener determines that the submission is hopelessly incomplete and needs to retire it. In this
case, an incomplete letter is generated and is provided to the submitter.
102 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
b) The Submission Processor has generated a DCN for a submission and wants to notify the submitter that
the submission is in the review process and that any further correspondence needs to be done using the
DCN and case number provided. This is done by sending an acknowledgement letter.
There are not many states associated with the outgoing mail process. There is only one state, awaiting outgoing
mail and once mail is processed, the submission goes back to its original state. The following state transition
diagram shows various states:
Active
Incomplete
A
request to senoNacknowledgement letter
request to sefid incomplete letter
A
outgoing mail processed
awaiting
outgoing mail
outgoing mail processed
103 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
Capture Outgoing Mail Information
View Edit Outgoing Mail
View Edit Incoming Mail
«System Actor»
CDX
Mail Clerk
View Returned Email
Capture Incoming Mail
Information
capture Incoming CD Mail
Information
A
Capture Incoming Network Mail
Information
rCapture Incoming Paper Mail
Information
Retire Incomplete or Replaced
Document
Send Copy of Electronic
Submission
Use Cases and Associated Activity Diagrams
Capture Incoming Network Mail
Description: The use case entails the process of capturing the receipt of an electronic Section 5 document,
either a submission or a support document, received through CDX. The document is promoted to
104 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
administrative prescreening at the end of the process. Original submissions complete several steps not required
for support documents.
Actors: Automated Trigger
Diagram:
Automated Trigger
Capture Incoming Network
Mail Information AD
1
notify system to obtain electronic
document mail information
CDXhas sent
electronic files to MTS
«use case»
set submitter abbreviation to
"need to add"
«use case»
Send Copy of Network
Submission through CDX
[joint]
search for another submission with status
"awaiting joint information" and same TS#
assign submission status "awaiting joint information"
and make document available to prescreeners
[found]
/'promote to administrative
\ prescreening
relate MR#s for submissions and use
MR of primary joint submitter
update submission status to
"awaiting prescreening"
105 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
106 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Send Copy of Network Submission through CDX
Description: The use case entails the process of sending a copy of a network submission back to the submitter.
The submission may be an original submission or a support document.
Actors: CDX
Diagram:
MTS
CDX
Send Copy of Network
Submission through
CDX
encrypt submission and accompanying
attachments using MTS Node
V
send encrypted N^
file to CDX }
\l
/'record date and ti
V file sent to CDX
Incoming Mail has been captured
Submission is a
network submission
route encrypted file to
submitter
107 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Incoming CD Mail
Description: The use case entails the process of capturing the receipt of a CD containing Section 5 submission
information or support document information. If the CD fails to upload, the mail clerk can enter incoming mail
information using any cover letter and the paper copy of the submission. The submission is incomplete if the
CD does not load and no paper copy is provided. The submission is promoted to prescreening after it has
completed this process. See the Prescreen Electronic Submission Use Case. Support documents are
promoted to the Process Support Document use case
Actors: Mail Clerk
108 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Mail Clerk :Mail Clerk
Capture Incoming CD Mail Information AD
provide mail information for
the submission
^request to save mail information^—
v. about submission _y
[ valid ]
provide
or edit incoming \,
il information y"
(
stamp Mail receive number on submission documents
nd forward to administrative prescreeners J
ier copy provided ]
\L
t submitter abbreviation to "need to
add"
/" request to provide mail "
\T information for the submission
error }
c
'obtain submission data from CD "\
nd record upload information J
obtain mail information from CD data and set submitter
abbreviation to "need to add"
^ present incoming mail "\
^information and request editsj/
/'save incoming mail information^.
generate a Mail Receive
Number ^\
present mail receive number to mail clerk and
confirm sucess of incoming mail process
[ support ]
^/"obtain support document^
^\^ data and save ^)
(change status to awaiting
process support document
[not joint
[joint ] /"search for another submission with status "awaiting
V joint information" and same TS#
assi9n submission status "awaiting joint information"
and make document available to prescreeners
'change status to awaiting"\
prescreening J
[found ]
relate MR#s for submissions and
use MR of primary joint submitter
update submission status to "\
"awaiting prescreening" J
109 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Incoming Paper Mail
Description: The use case entails the process of capturing the receipt of paper Section 5 submissions and
support document information. The Mail Clerk manually enters incoming mail information.
Actors: Mail Clerk
Diagram:
Mail Clerk : Mail Clerk
Capture Incoming Paper Mail Information AD
request to capture mail \
infnrrnatinn /
/" provide incoming "V—
V mail metadata _/
request to save incoming ^T~
stamp Mail Receive Number on front page of the document
and send paper document to Administrative Prescreening
request incoming
mail information
capture mail information.
[ valid ]
[ invalid ]
notify Mail Clerk of error
/'"'save incoming mail information""
/'set submitter abbreviation to "need to add"
generate a Mail Receive Number
'"present mail receive number to mail clerk and "\
v confirm sucess of incoming mail process J
change status to awaiting j
process supportdocument^y
[originallsubmission ]
set day one date to current date
/^ search for another sub mission with status N
"awaiting joint information "and sameTS# J
[elsei;
/" assign submission status "awaiting joint information" ^
V^ and make document avail able to prescreeners _,
else]
/ \
/^relate MR#s for sub miss
\^ MR ofprimaryjoint
/ \l/
[fodnd]
^change status to awaiting"
prescreening
update submission status to
3 "awaiting prescreening"
110 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
View Edit Incoming Mail Information
Description: The use case entails the process of viewing and editing information previously captured about the
receipt of Section 5 documents.
Actors: Mail Clerk
Diagram:
View/edit Incoming
Mail Information
Incoming mail data
has been captured
^ request to view incoming ^V-
\. mail information J
/'select from list
provide date
range for MR#
provide MR#
/wew incoming mail
V information online
[ View ]
[ Edit ]
request to edit incoming
mail information
provide editable incoming A
mail information J
( edit incoming mail
V information
request to save edited ~~\
incoming mail information *
display list of last 25 MR# records allowing user to reset
number of records displayed and request selection or MR#
~T display MR#sN s s, Maj| c|efk
^ in data range J I nmvirifi «,liri MFW
[ MR# Matched ]
•provide existing incoming ^\ /'notify Mail Clerk that
mail information for MR# J \^ MR# not found
•<:
[ valid ]
-------
MTS NCS Software Requirements Specification Model Report
112 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Outgoing Mail Information
Description: The use case entails the process of capturing outgoing mail information that is being sent from
EPA to a submitter. Some examples of materials to be sent include incomplete letters and acknowledgement
letters.
Actors: Mail Clerk
113 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
114 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Outgoing Mail
Information
t^ f
Document has been
promoted to Outgoing Mail
request to capture outgoing \
mail information ^—
c
se ect from list
d-
contact information will t\
default to agent if agentexists,
otherwise technical contact is
used. The mail clerk can
select either.
provide information about submitter, site and \
contact information of receipient 7-
~>s_
(provide or edit outgoing mail __-
V information including CBI status,/
[ no labels
-j^ provide list of documents \
V awaiting outgoing mail J
/L prepopulate submitter address, contact \
y information, and outgoing mail information J
[ data not available
V
request the submitter, site and \
: contact information of sender s
c
determine if submitter, site or
contact has been claimed CBI
[ else ]
'yes'|
/'identity mail as
V CBI
—f- request outgoing mail
\_ information
•<
notify mail ^,
clerk of error J
/" request if mailing labels "\
V are to be printed J
generate 2 mailing labels for CBI and one A
for non CBI J
<9
115 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Email Log
Description: This use case describes the process of capturing email communications between EPA and
submitters. For example, EPA may choose to request data or provide an acknowledgement letter via email.
Non-CBI email content may be sent via EPA email. CBI email content must be encrypted and send via CDX.
Actors: MTS User
Diagram:
116 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
MTS User : MTS General User
Capture t^
Email Log
!
S~ request tn email "\
V submitter J
f provide submitter ~*\
V name J
- — — -
( select ^^
\^ submitter j- — ______
\i
/'select email address or "\
V provide email address J
/" provide DCN or ^\ [ email regarding subn
VMKff or suDmission^A
[ contact Information
[CBI]|
<^><
^~~^-^ ^
[nonCBI]
^
f provide email text and any non ^\
V CBI files for attachment }
: MTS
f Communication needs to be "1
made with the submitter
Additional information is sought to make submission
complete or company needs to be informed
/"Request for submitter name "\
fallowing them to search for \\J
---~>~
./" provide list of submitters "\
\_ to select from J
_ — —
/'provide email information about technical contact ^\
^^ [ update contact ] S
-<^> >l n
[ email exists ]
lission ] ^^^ [else]
^^^
/" «use case» ^\" ^^fr
^^^^ [elsej / Send CB| emai| \ (^
^^^ ^V through CDX J
\l
/'verify no CBI will be included ~\
\^ in text or attached to email y~
\/
( provide email functionality \
V J
7> saw text date time sender name and location of attac
^contact email and name and relate it to the document ident
^
( send email ^N
4
«use case» X
Maintain lookup j
tables J
nA
, •
ned files, and "\
fier, if applicabley'
117 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Send CBI Email through CDX
Description: The use case entails the process of sending CBI email through CDX. If a submitter does not have
a CDX account EPA may not send CBI information to the submitter through email. Non CBI email may be
sent through EPA email systems other than CDX. See the Capture Email Log Use Case.
Actors: MTS User, CDX
Diagram:
: MTS General User
Send CBI Em ail
through CDX
provide email text and attach
files as appropriate
Email has been
saved in MTS
Email is CBI and recipient
has aCDXaccount
Generic email account exists
for sending email from MTS
provide email
functionality
save text, user name, date, time, name of attached files, email
address, and attach data to document identifier if applicable
request to send
CBI em ail
encryptemail
using MTS node
\k
record date and
time
send to CDX
record delivery \
status as "sent'^y
f set delivery status
V to "failed delivery
< receive encrypted file and
notify submitter of email
[success
118 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
View Edit Outgoing Mail Information
Description: The use case entails the process of viewing and editing information previously captured about
outgoing mail from EPA to submitters.
Actors: Mail Clerk
119 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
View Edit Outgoing
Mail
request to yew outgoing
mail information
[view]
[edit]
request to edit the outgoing \
mail information -)—
edit outgoing mail ~\
information /
display list of last 25 outgoing mail records providing an option to
display a different number of records and request selection or identifier .
-/^provide outgoing mail information
y pertaining to the selection
-J£ prro\/ide editable outgoing
V mail information
^ validate \
V changes J
; valid] ¥ [invalid]
.^"generate 2 mailing labels
\. for CBI, 1 for non CBI
120 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Review Undelivered Mail
Description: The use case entails the process of reviewing emails that were undeliverable. The NCS
Administrator may choose to resend the emails as paper mail.
Actors: NCS Administrator
Diagram:
: NCS Application Administrator
DmiisMAf 1 1 nrln\\Mnrnrl l\
Mail
1
f request to review ~\
V undelivered mail J
f review A,
^undelivered email J/~
(§)<^
[ request status change ]
/" select "\
\^ documents J
\l
f requestto change status of selected documentto "\
\^ undelivered mail documentto "awaiting outgoing mail" J
:MTS
generic email account exists ~\
for sending MTS emails
^^\^ ^/" provide message ~\
^^^ ^^regarding null results^/
rei JL
/" present list of email from generic MTS N ^WJ
\^ account with delivery status of "fai... J ~
^--^
/^ changed status of document to ^\
\^ "awaiting outgoing mail" J
•
121 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
IncomingMailLog
MailReceiveNumber
SubmitterAbbreviation
TS Number
JointFlag
Consolidated Flag
ModeOfSubmission
MailTrackingNumber
MailReceiveDate
Postmark Date
Carrier
Related Mail Number
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
Chemical Name
GenericUse
SpecificUse
MailReceiveNumber
BarcodeSanitzedFlag
UserfeeStatus
Related DCN
RelatedOriginalDCN
Support DCNs
ConsolidatedFlag
PCNumber
TS Number
PaymentID
JointFlag
CBI
CBICIaim
CBIOther
DCN
Sanitized Flag
Sanitized DCN
SanitizedStatus
BarcodeOriginalFlag
JointMailReceiveNumber
DaylReviewDate
NumberOfChemicals
RetireCaseStatus
ViolationStatus
Acknowledgement Letter
DCN
CBI
SubmitterAbbreviation
SubmissionDCN
O..n
IncompleteLetter
CBI
SubmissionDCN
SubmitterAbbreviation
OutgoingMailLog
Outgo! ngMaillD
SubmitterAbbr
CBI
ModeOfTransmission
TypeOfLetter
DCN
Certified
EPACertificationReceiveDate
Mai I Date
SubmitterMailReceiveDate
MTS Access
Description
This module pertains to a user accessing MTS to perform a task. It also includes the user logging out of MTS to
close a user session. Session information including user ID, session start time, and session end time are recorded
and tracked by MTS for audit purposes. The retention time of session information is to be determined.
122 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
MTS User
?
f request to X
^ login J
f perform work y
MTS
/~ authenticate ~\
•"V user J
\l
5 clearance informationy
Access MTS J
(«use case» X
Capture Workload ]
Information J
\l
(«use c..»X
logout MTS J
1
MTS Administrator
CBITS
/" provideTSCA section 5 "\
Considerations
1. MTS user management is performed by ECMS and is outside the boundary of MTS. This means
password change notifications, forgotten password activities, and other user account maintenance
operations are handled by the ECMS Administrator and ECMS system, and not MTS.
2. This process supports a single sign-on concept, where the user will not be assigned a new user ID and
password to use MTS. They will be using their EPA user ID and password.
3. Based on the user ID, MTS will determine the level of access granted to MTS functionality. For
instance, only authorized TSCA Section 5 cleared CBI users will be allowed to see and maintain most of
the New Chemical Submission functionality. MTS will use the CBITS - AXCON system to check for
TSCA Section 5 Clearance every time a user requests to access MTS.
4. MTS will track the number of unsuccessful logins and will lock the user out from using the system after
several unsuccessful attempts for security reasons. The user will have to contact the MTS Administrator
to get their account unlocked.
5. When logging out, MTS will ensure that the submission that the user was working on is made available
to other users to work on. At any given time, a read only version of submission is available for the other
users to view, but not to edit.
6. Another important consideration for logout pertains to capturing the workflow and lifecycle location of
the submission when the user exits. This provides a starting point for another user to perform their work.
123 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
7. In an event of ungraceful shutdown, the workflow and lifecycle location will not be captured. The
strategy to handle that scenario is TBD.
8. If the user forgets to logout, the system will automatically log them out at midnight.
9. If someone logouts during the day then they will be asked for a comment regarding workflow and
lifecycle location. If they are timed out no comment is required.
Workflow and Life Cycle Placement
Login is the first stage of workflow for an MTS user. Before they can perform any activity within MTS, they
need to request access to MTS system. Once they are authenticated and authorized, they can perform activities.
At the end of the day, MTS user requests to logout that signals end of workflow for the MTS user.
Use Cases Involved
«System Actor»
CBITS
MTS General
User
Access MTS
MTS
Administrator
Use Cases and Associated Activity Diagrams
Access MTS
Description: The use case entails the process of logging into MTS. MTS will verify the MTS User's clearance
level upon each login.
Actors: MTS User, MTS Administrator, CBITS
124 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
SIT
Diagram:
: MTS System Administrator
Access MTS AD
request to change status
of account "active"
MTS user information
exists in the system
"" provide username ""
and password ,
contact system admin to -
^ unlock account
MTS user has been assigned username and a password and has been
provided access to use MTS. See Maintain MTS user information
^request username and
-X_ password
/"validate username and password and
V check if registered with MTS
/[ MTS User4
<. r ri
[ else ]
/" notifyuser of failed
V attempt
!equest to determine TSCA Section 5 :V-
clearance and active clearance J
f count number of times incorrect ^\
\ info provided J
[not reached limit]
, [ else ]
inform account is locked and to
contact system administrator
change status ^\
y to "active" J—
determine and provide functionality
, available in MTS based on clearance .
maintain log of transactions in~\
a login session J
[ all clearance expired ]
/^ notify and deny >,
V access to system J
^provide clearance information and ~"\
V TSCA section 5 clearance J
125 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Logout MTS
Description: The use case entails the process of logging out of MTS. If the MTS User does not initiate a log
out by a predefined time each day, the system will force logout. Upon logging out, any work the user self
assigned through the Capture Workload Information use case will be unassigned.
Actors: MTS User
Diagram:
MTS User
MTS
Logout MTS AD
N
1
request to
logout
V
provide comment
on document status
User requests to logout or predefined time period
has been reached for the day forcing logout
/^complete login session transactions
~X and capture in audit log
/'remove document(s) from N
y the user's workload J
V
( capture location in workflow where
V work ended when logged out
[userlog out]
[forced log out]
requestcomment \
on document status^/
comment regarding \
document status J
V
( assign submissions that MTS user
y was working on as "available"
V
126 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
127 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Session
SessionID
Session Start Time
Session End Time
Session Date
AXCON TSCA 5 Information
CBI Clearance
CBI Clearance Expiration Date
TSCA 5 Clearance
TSCA 5 Clearance Expiration
Prescreening
Description
Once a submission's mail information is captured, the submission is prescreened. Prescreening involves a
cursory review of the submission completeness before content review takes place. If a submission does not have
required information that is needed to proceed with review, the submission review and subsequent processing
will be futile. Hence, prescreening will check for certain information in the submission that will allow the
submission to proceed with the actual content review.
Prescreening is done for all section 5 submissions. The criteria for review for these Section 5 documents differ
slightly with each document type within section 5. The criteria for review is predefined but can be easily
modified. Criteria for prescreening is a prime candidate for being a Lookup Table.
The prescreening process can be split into three parts: Administrative Prescreening, Chemist Prescreening, and
Final Assessment. In administrative prescreening RDMB will review the submission for basics. If any
information that the Chemist Prescreener needs and is not provided, RDMB will get that information. RDMB
will make the determination whether to discontinue further processing or continue with pending information in
the hope to get information before a DCN is generated.
If the prescreener determines that the submission should go to the next step of Chemist Prescreening, it is sent
to the Chemists (CCD/EETD). They have their own criteria to determine if the submission is complete enough
to be reviewed thoroughly by them after a DCN is generated. Hence, the Chemists will review the submission
two times, once during prescreening and then during actual screening, after a DCN is generated. They document
the results of their assessment in MTS.
128 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
When RDMB gets the chemical review results in MTS, they will evaluate the incomplete information and make
a final determination as to whether a submission should proceed to the next step of DCN generation or should
be declared incomplete and retired. Until now, incomplete submissions were returned back to the submitter. The
new policy, based on records management rules, is to keep all documents provided to EPA by the submitter.
Hence, in this case, an incomplete letter is generated and sent to the submitter, while the submission itself is
retired based on the retention policy. Note that that submission does not have a DCN when information is
incomplete.
During prescreening, the Prescreener will attempt to get missing information from the submitter.
Communications with submitters will be documented using the Capture Communication Log use case. If there
is any missing information found during prescreening, the Prescreener will generate a notification for the
submitter conveying them a "Mail Receive Number" of the submission and ask them to use the number when
sending information about the submission. This is a mandatory number as in its absence, it is difficult for
Prescreener to associate a replacement document with a submission. Any missing information that arrives via
mail, gets a mail receive number and is treated like a support document. However, in this case, a support
document DCN cannot be generated for this missing information because the submission with which this
support is associated with, does not have a DCN. Hence, this is called a special type of support document called
a "replacement document". Assuming that Prescreener can find out the submission to which the replacement
document belongs, they will substitute the replacement document in the submission. The replaced document
will be retired and kept per EPA records management policy.
129 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
Considerations
1. All submission go through prescreening, with some receiving more scrutiny than others. Network and
CD submissions already go through some required checks at the submitter site, as the submission tool
does not allow submission to be sent if there are any critical errors. Hence, Network and CD
submissions are devoid of any legally required field errors. If the submission is composed using the
submission tool and then printed and sent as a paper submission, it will not have any legal required
information missing. Hence, prescreening is mostly a problem when data is manually entered on a
preprinted form and sent to EPA.
2. Possible duplicates are checked in the prescreening module. A submission may be a duplicate if it is not
a joint submission and it has a same TS# and is from the same company as another submission that
exists in the system. Also, if the mail receive date and mail information is the same for both
submissions, it is likely that the submission is duplicate. However, only a thorough review of the
submission by a human can confirm if a submission in duplicate. Companies are known to use the same
TS# for different submissions. In this event, the duplicate is just an alert, but the user will have to
investigate. Also, a TS Number is not required for all section 5 submissions.
3. If the submitter did not provide a TS# and a payment ID, and the prescreener has not been able to obtain
it by communicating with submitter. The Administrative Prescreener will make the submission
incomplete. Prescreening does not require for the actual fee to arrive; only that the two pieces of
information need to be provided.
4. Each submission type has a slightly different criteria that is used for prescreening.
5. Final submission prescreen pass or fail determination lies with the Administrative Prescreener.
6. The templates provided to generate incomplete letters can be customized by the prescreener. The
incomplete letter template is different for different document types.
7. A joint submission is prescreened as a one submission as it can only reach prescreen once both pieces of
the submission arrive.
8. If the network submission is corrupt or unusable, MTS will send the submission to the NCS Application
Administrator for further resolution.
9. A document type is finalized by the prescreener. That is why a case number for the submission cannot
be generated, until the Prescreener finalizes the document type for the submission. The finalization,
however, has to be done as a replacement support from the submitter to ensure consistency in data.
10. Even if all missing information is not in place, the submission can proceed to the next step in the hope
that the missing information will arrive soon. However, before a DCN is generated, missing information
must be in place, otherwise a DCN will not be generated. If information is missing, scanning is not
performed for paper submissions.
Workflow and Life Cycle Placement
The prescreening stage follows the mail receive stage in the life cycle of a submission. After a submission
arrives and some information about the submission is captured, it goes through preliminary review by the
Administrative Prescreener and the Chemical Prescreener. If they concur to proceed with submission
processing, the submission moves to the next state, which is scanning for paper submissions and DCN
generation for electronic submissions. If prescreening fails, the submission is deemed incomplete and is retired.
If the Prescreener is waiting for missing information, and it is agreed by the Prescreener to proceed with the
130 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
processing, the submission state will be "Prescreened". If after a certain number of days, missing information
does not arrive, the submission will be deemed "incomplete" and retired.
The following diagram shows various prescreening states:
Awaiting
Prescreening
missing information
prescreening fail
# of days and no missing information
131 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
Administrative
Prescreener
Mail Clerk
Capture Email Log
Capture Communication Log
/«extend»
«extend»
Prescreen Electronic Submission
Prescreen Paper Submission
extend»
Retire Incomplete or Replaced
Document
132 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases and Associated Activity Diagrams
Prescreen Paper Submission
Description: This use case describes the process of prescreening paper Section 5 submissions for
administrative or chemical errors. The paper submission process pertains to paper submission; electronic
submissions are screened using the Prescreen Electronic Submission use case. Prescreening identifies
incomplete submissions that will be sent back to the submitter. Incomplete at this stage refers to specific
prescreening criteria. A more thorough examination of submission content is done later in the MTS process.
The prescreening process prevents EPA employees from spending additional resources on submissions that do
not meet basic requirements. The Administrative Prescreener attempts to capture any missing data and then
forwards the submission for chemical prescreening if the administrative data is complete. Once the Chemical
Prescreener has completed prescreening activities, a final "complete" or "incomplete" decision is determined
for prescreening.
Actors: Administrative Prescreener, Chemical Prescreener
133 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Prescreen 1^, Prescreener has
Paper paper submission
that
subn
also
deen
inco
pres
Submission has been
captured in incoming mail
0 ^ request to perform administrative ^
prescreen
submissions l\,[ awaiting joint] J^~~\
o not have all <^^->
itter input will
me point be [MR#
ed
nplete bythe /
[select]
,/" provide MR# \
metadata -^
V orescreen result J.
[ need data jjj/ [ incomplete decision ]
X «use case» \
( attempt to capture missing data j
V using capture communication log J
i
process through Process Replacement Sup
Document use case. Then complete pres ere
[chemis
[ admin complete ]
promote submission to "X
chemical prescreen ng
1
Submission is
"hopeless"
X edit text as appropriate ^
ening. J^O PaPer letter 1 ,-\
^v"~ ^Tf""«]
X review chemical prescreen result
V prescreen
and provide final result of
ng ±7
requested data jj^ , comp|ete ,
[ incomplete ]
X editmetadata "X^
Joint submissions have been connected
p g J
[print]
[email]
X request to provide \
V. chemical prescreen result }
1
V
X select document \,
X present list of pending M R #s awaiting "\
^ prescreening sorted by document type ^/
V^ needed
-7\
1 [valid]
N/
)
^ provide metadata \ ^ Capture Incomina Mail use case /
~~~~~v--" ' ' A save metadata edits "\
record result of ^
p ee g
/ provide Incomplete Letter template based on document ~\
V, type with prepopulated mail receipt date and TS number }
•f capture letter as PDF "\
|
_^X print letter \ X change letter status to awaiting X
I
^T
f~ promote and record promotion data ^\ ^
X present list of pending MR#s awaiting X
\^ prescreening sorted by document type J
X present document ^\
Xrecord results of chemical prescreen in g"\
\|/
X promote document to ~\
V administrative prescreening J
X request revised day one date X
\ date J
^
>c P . — i_ — ~^
X provide error mess age \
M/
V unpaid for PMN and SNUN )
M/
V type and case number rules and present case number }
^V
^ change status of submission N
awaiting scanning "T^jK
134 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Prescreen Electronic Submission
Description: This use describes the process of prescreening electronic Section 5 submissions for administrative
or chemical errors. Electronic submissions may be submissions on disk or they may be transmitted directly to
MTS, e.g., CDX submissions. MTS performs validation checks on the electronically submitted data prior to
this prescreening process to increase submission quality. The chemical and administrative prescreenings
identify incomplete submissions that will be sent back to the submitter or put on hold until additional data is
received. Validation checks performed on electronic submissions should minimize the amount of data errors.
Incomplete at this stage refers to specific prescreening criteria. A more thorough examination of submission
content is done later in the MTS processes. The prescreening process prevents EPA employees from spending
additional resources on submissions that do not meet basic requirements. Once the Chemical Prescreener has
completed prescreening activities, a final "complete" or "incomplete" decision is determined for prescreening.
Actors: Administrative Prescreener, Chemical Prescreener
135 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Chemical Prescreener: Prescreener
Prescreen Electronic
Submission
Prescreening fields haua been checked
through the submission tool
f" request to perform
y administrative prescree
«use case» T^
get missing data using •=
, capture communication log _/
V prescreening J
f~ review chemical prescreen results and proyde final "\
yprescreen result and reused "day one" as appropriate^—
C provide incomplete reasons and edit
V, Incomplete Letter as appropriate
/" request to perform chemical ~\
V prescreen electronic submissions ~s
/'proyde chemical prescreening results^
<^ provide list of submissions awaiting \
y prescreening and request selection orMR# J
/""provide submission metadata and
V submission data content
/" provide list of submission x
4, awaiting chemical prescreening
—p provide submission data, metadata, and N
V administrate prescreening information for reviewy
record results \
j' promote submission to administrative
V prescreener, and record promotion data
print letter ~\
f change letter status to awaiting outgoing mail
/' record complete result "\
X and revised day one J
change status to awaiting DCN
Generation
136 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
137 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Process Incomplete or Replaced Document
Description: This use case describes the process of retiring an incomplete document or replaced page.
Although the prescreening process identifies incomplete documents when they fail prescreening, there is also a
need to make document incomplete outside of the prescreening process. For example, a CD that will not load
during incoming mail processes and does not have a paper document accompanying it would be identified as
hopeless and be processed through this use case.
Actors: Prescreener
Diagram:
,_
Retire Incomplete or l\
Replaced
Document
1
(request to retire "\
incompletesubmission J/
^ select document y
[in
/^provide edits to ~\.
V letter text J^~
1
1
JL [<
[ )aperm
/'affixbarcodeto "\,
\^ document J^
f provide boxnumber "V
\^and accession number^"
^
/"put submission^
\Jn assigned boxy
4
:MTS
Submission has been identified as incomplete through the prescreening process.
See Perform Electronic Prescreen and Perform Paper Prescreen use cases.
[Prescreener knows box num ber and "1
accession num ber for document retirement
/^provide a list of incomplete documents and ^\
\j replaced pages that have not been retired J
^L^ [else]
^~-~^>
om plete letter needed ] \l/
f provide incomplete lettertemplate "\
^preopulated with m etadata from DCN or MR J
S save letter as PDF "\
mail]
j^y'' initiate Capture "\
\ Email Log }
ail
iXset status to "awaiting "\
\^ outgoing mail" J
i
S print barcode rW6^!-^ < < H.t.rmin. if „*>„«„„ n.rinH (hr .Lrfmnin N
V y ^^~^\ electronic 1 T ^llhmi^^inn ha^ hppn rpanhprt )
y [else] „
/^ determine if retention period for >i <^ J> ^V00
V [else] [riached]
~~~~~-^ ' (^b) f change status oTsubmission to "incomplete N
[ reached ] J/ ^—^ \^ retired", save retired by nam e, and retired date J
f request accession "N
V numhpranrl hnxnumhpr / V
A / plUlllult! bULllllibbiull \
,| v *° archive location J
^><^' "^> ~^f provide error "\
^^1 V message J
I valid] |
/'record box num ber and accession num ber for "\
\^ submission J
1
/^ change submission status to 'Incomplete retired" and "\
Y save retired date and retired byname j
Archival Location
^S' archive "\
^V submission J
1
(4
W
138 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Capture Communication Log
Description: This use case describes the process of capturing communications between EPA and submitters.
For example, EPA may need to discuss submissions data or to request missing data that is needed to make a
submission complete. EPA communicates with the submitter during the prescreening process, but any MTS
User may log data about a communication at any time. For example, the User Fee Processor may communicate
with a submitter regarding user fee data. If the submitter submits new data or changed data to EPA it will be
handled through incoming mail processes. MTS Users may not change original data submitted to EPA without
written support from the submitter.
Actors: MTS User
139 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
140 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Hf
MTS User : MTS General User
: MTS
Capture Communication Log
[ new log ]
[ edit log
/ request to enter
ycommunication
provide
identifier
V
enter data related to
the communication
provide N
identifying
( select a
^communication log
( update >^-
ycommunication log^/
request communication log
search data
[ active document-}
;else]\j/
prepopulate with active
DCN, case number, o
request identifer to relate communication
log to (e.g. MR #, DCN, Case #)
validate identifier
provide prepopulated
communication log template
save log with user name, date, time,
and submission identifier
[ found ]
V
provide error
message
return communication logs
meeting search criteria
[ user is author]
provide read
only view of log
V
provide communication
log for edit
J
communication log revisions
and date, time, user information
141 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Incoming MailLog
MailReceiveNumber
SubmitterAbbreviation
TS Number
JointFlag
ConsolidatedFlag
ModeOfSubmission
MailTracking Number
MailReceiveDate
PostmarkDate
Carrier
RelatedMailNumber
Prescreeninglnformation
MailReceiveNumber
AdminPrescreenStatus
ChemistPrescreenStatus
Final PrescreenStatus
MissinglnformationFlag
DateCompleted
TimeCompleted
CompletedBy
1
Missing Inform at ion
SubmissionMailReceiveNumber
MissinglnformationNotes
SubmitterAbbreviation
MailReceiveNumber
DateMissing
TimeMissing
IncompleteFlag
IncompleteLetter
CBI
SubmissionDCN
SubmitterAbbreviation
O..n
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
Chemical Name
GenericUse
SpecificUse
MailReceiveNumber
BarcodeSanitzedFlag
UserfeeStatus
Related DCN
RelatedOriginalDCN
Support DCNs
ConsolidatedFlag
PCNumber
TS Number
PaymentID
JointFlag
CBI
CBICIaim
CBIOther
DCN
SanitizedFlag
Sanitized DCN
BarcodeOriginalFlag
JointMailReceiveNumber
Day1 ReviewDate
NumberOfChemicals
142 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Quality Assurance
Description
Quality Assurance pertains to ensuring that the information captured in the system matches with the information
that exist physically. For electronic format submissions, the Quality Assurer reviews the data to see that it was
captured correctly.
There are two types of Quality Assurance that are performed.
1. Quality checks of data within submissions. For paper submissions, this ensures that the information that
is edited matches the information in the physical submission. This happens when a paper submission is
scanned and data is extracted. The data extracted may not be 100% correct, thus leading to manual
editing of data to match the physical submission. Anytime data provided by a company is manually
edited, whether due to scanning errors or support documents, Quality assurance is performed on the
edits. For electronic submissions, the Quality Assurer reviews the data to see that it was captured
correctly.
2. Ensure that a physical document with DCN also exists in the system with the same DCN. This is known
as "Completeness Check" and is performed through the Perform Validation on Barcodes use case. This
is analogous to yearly auditing, except that auditing pertains to a certain group of documents, where this
check is done on case by case basis each day.
143 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
( request to check "\
vbarcode existence^/
assign status completeness \
check passed J
Considerations
1. This process pertains to paper submissions, CD, and Network submissions but the quality assurance step
for paper submissions is different in that each field is checked against the original paper submission or
an image of it.
2. When edits are made to the submission before a DCN has been generated, changes are not made to the
original submission. Changes are applied to the data fields, but the sanctity of the original submission is
maintained.
3. Quality Assurance is done whenever an edit is made to submission information before a DCN is
generated or after DCN generation. After a DCN is generated, amendments are kept as is and changes
are made in PMN notes, not in MTS. Hence, it is assumed that QA is always performed before a DCN
has been generated.
4. QA is done to validate electronic data of the submission against the physical data of the submission. The
comparison is made against the latest copy of the submission.
5. MTS will not allow the user to proceed with DCN generation unless the submission passes Quality
Assurance.
6. If the barcode scanned does not exist in the MTS system, there is a potential for a violation. MTS will
save the status of the document as "QA- failed" and proceed with the next document.
144 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Workflow and Life Cycle Placement
The two types of QA checks are performed at different points in the lifecycle of a submission. The first QA
check that pertains to checking sanctity of the submission is done before a DCN is generated and whenever
edits are performed on the submission as a result of fixing scanning errors. Two states that pertain to this type of
"Complete" and "Incomplete" that identifies outcome of the Quality assurance test, QA Pass and QA Fail
respectively. If QA passes, the submission is deemed "QA Pass" and is ready for DCN generation. If it is not, it
is assigned an "Incomplete" status to prevent DCN generation.
physical information = logical information
Consistent Information
event QA Check Pass/ Set QA Check pass flag to Yes
event QA Check Failed/ Set QA Check Pass flag to No
Physical Information != logical Information
V
Upon Edit[ physical information = logical information ]
Inconsistent
Information
The second type of QA check is performed at a predetermined time periodically. It ensures that the barcode
DCN on the physical copy actually exists in the system. The submission remains in "active" status if the
submission passes the completeness check. If the completeness check fails, it implies that a physical barcode
exists but there is no record of the submission in the system. The validation error is recorded and the user may
provide a related comment regarding the error. Inconsistencies between physical and logical submission are
reviewed by the MTS System Administrator.
145 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
[ Barcode exists in MTS or need to be added to MTS ]
[ Unretire ]
Active
event Completeness Check pass/ assign completeness check flag = yes
[ Barcode does not exist and need to be retired ]
[ Barcode does not exist and need to be transferred ]
Use Cases Involved
Quality Assurer
Perform QA Check
Submission Processor
*Perform Validation on Barcodes
MTS Administrator
Use Cases and Associated Activity Diagrams
Perform Quality Assurance Check
Description: The use case describes the process of performing a quality assurance check on Section 5
submissions received in paper format or electronic format. For paper format submissions, the Quality Assurer
compares the paper submission to the data in MTS. For electronic format submissions, the Quality Assurer
reviews the data to see that it was captured correctly. If the data does not match or there is some other type of
quality assurance issue, the Quality Assurer logs a failure for the submission quality assurance checks and the
146 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
submission is promoted back to the View Edit Submission use case. The Quality Assurer does not make
changes to document data, he or she only passes or fails the document.
Actors: Quality Assurer
Diagram:
Quality Assurer
Perform QA
Check
Paper submission has been scanned
Original Paper submission submitted by the
company is available to compare with
1
request to perform \
quality assurance cheeky
select document to
QA
reivew data and compare to paper
document for paper submissions
request to provide
QA result
v
provide QA
result
provide
comment
MTS
provide list of
documents awaiting QA
present document data
request QA result
[passed]
record result
[failed]
request
comment
«use case»
'record results and comment and change status
to awaiting view/edit submission
147 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Perform Validation Check on Barcodes
Description: The use case describes the process of validating barcodes attached to non-electronic submissions
for quality assurance purposes. This is typically done on a daily basis to ensure that DCNs that have been
created in the system related to actual non-electronic submissions. If a scanned DCN is not found in the system,
it is recorded as an error for later investigation. Errors will be investigated by a system administrator or DBA to
determine resolution.
Actors: Submission Processor
Diagram:
Perform
Validation on
Barcodes
Submission Processor
Submission is a non
network submission
T
Submission has been processed, DCN
generated, and a barcode has been printed
/'request to check barcode DCN on non network
V
submission against system DCN
>
scan barcode V±
or enter data J
[contini
c
provide error
comment
e]
I else ]
[ generate report ]
barcode validation
complete
request to generate
completeness check report
<
prompt for barcode
scan or manual entry
[DCN not found]
\l
provide error message
"DCN does not exist"
record validation errorwith DCNthatwas input
and update validation status to "errorfound"
<
request comment
regarding error
record e
comment
rror N
snt J
[ exists ]
/^provide "success"
V message
)
r-
update status of validation to "complete"
"and record current date, time, and user
«use case»
generate predefined
report
148 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Submission
CaselD
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckllserlD
QACheckPassFlag
Reports
Description
A minimal set of parametric reports are provided. Most of these reports are canned reports, i.e. their input,
output, and format is predefined. Some of these reports are based on CBITS reports, however, they do not
pertain to any submission copies or any processing of the copies as copies are no longer present in the MTS.
These reports also include reports that are created as a part of processing. A reference to such reports is included
in the use case itself.
These reports have specific format and template to which the system will adhere to. A sample for each report is
included with the requirements.
149 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
MTS User
MTS
T
request to
generate reports
request to print
report
«use case»
generate predefined
reports
V
present contents of
report to view
print report
Considerations
1. Reports are predefined. Hence format, parameters, and data obtained has been determined.
2. Since the MTS User is assumed to be CBI and TSCA Section 5 cleared, reports are viewable and
printable by the MTS user and the system does not check before displaying contents of the report.
3. Ad Hoc reports and reports from other systems are not part of the scope of MTS right now.
Workflow and Life Cycle Placement
Reports can be generated at any given point in the lifecycle of the submission, however, generally they are
generated after submission has been processed and has attained a DCN. There are no states associated with
reports.
Use Cases Involved
150 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
MTS General
User
Generate Predefined Reports
151 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
i M
Use Cases and Associated Activity Diagrams
Generate Predefined Reports
Description: This use case describes the process of generating reports that have been predefined for MTS. The
user may provide values for reports parameters, e.g., data ranges.
Actors: MTS User
Diagram:
MTS User : MTS General User
Generate ^
Predefined Reports
T
/^request to generate^
Va predefined report J
^^
f select report ^r-~
,^~^
/" provide report "V
V parameters J
f®)- ^\-
^f)^ ^^^^
^^ [ else ] ^^
[ print ]
MTS : MTS
f Reports have been predefined "1
and exist in the system
Information for the reports "1
exists in the system
^ )
f The MTS User has access "1
to the requested data
ff present list of reports including "\
\i report name and brief description J
^^
/ ± ^. ^\^^
/ request report T^.
^\^ parameters y"
^^
^^^ [ invalid ], pro^de error v
^^^^ \^ message J
1
/^generate report^N
\l [ no results 1
^^^^ --£ provide "no results" ^\
^^^^ '^ error message J
results ]
\l
f provide report results on screen for viewina, "\
^ and identify if report has CBI data J
^/'print r^p^rt in^ludinq ^\ ^(^^
'V identification of CBI } ^^^
152 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
153 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Report
InputParameters
OutputParameters
Importance
Frequency
Submission Processing
Description
Submission processing consists of various facets. These are:
Transferring Non Confidential documents to NCIC
All sanitized paper copies that accompany a CBI Section 5 submission are transferred to another EPA division
called NCIC (Non Confidential Information Center). Only paper sanitized copies are transferred. Electronic
sanitized copies are maintained within MTS. MTS tracks information about the transfer of sanitized copies to
NCIC. It also tracks receipt of sanitized copies by the NCIC.
Retire submissions
Submissions that are inactive or are obsolete are retired. Submissions are retired based on records retention
periods. Retire means that the paper submissions are physically transferred to a storage facility and are not
available for viewing and/or processing. Electronic copies are transferred to an archival location for storage.
Paper submissions are actually put into boxes and transferred to FRC (Federal Records Center) for archiving.
Information about the submission or electronic version of the submission information is copied into another
location for up to 20 years. After that time, the electronic copy is also sent to FRC. At any time, if for any
reason the submission needs to be brought back, MTS has the capability to reactivate the submission.
In the retire process, eligible documents are pulled from the shelves, audited for completeness, boxed and
inventoried. There are three kinds of retirements and the processes associated with them are described below:
1. Retire an active paper submission - FRC issues accession numbers in the beginning of the year. There
are a maximum of 25 boxes in an accession. Depending on how many boxes are needed and get used,
the boxes are numbered in reference to the total number of boxes used. As a document gets retired, its
status in the system changes and the physical submission is placed in the box. The box number and the
accession number is captured so that if the document needs to be un-retired, it can be done easily. A
folder description is captured to differentiate between consolidated and non-consolidated submissions as
consolidated submissions have multiple case numbers but are retired together.
2. Retire an incomplete/invalid submission - This happens if prescreening fails or legally required user fee
information for PMN and SNUN submissions are not provided. In this event the submission, which does
154 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
not have a DCN or even a case number, is retired. Note, that the submission is retired in the mode it
came in i.e. paper incomplete submissions are retired as paper submissions and electronic incomplete
submissions are retired as electronic submissions. In addition, if a page is replaced in a submission
before the submission gets a DCN, the replaced page is also retired as invalid page. In order to retire
these incomplete or invalid documents, a barcode with a mail receive number is created and applied to
the paper copies. For the electronic submission, the mail receive number is used as an identifier.
3. Retire an active electronic submission - Electronic submission retirement is trivial in the sense that their
status is changed and they are moved to a different location. They are still available in that different
location, but functionality to review or manipulate them is not available. If that is desired, the
submission can be made active again. The records are initially moved to the FR location. From there,
they are moved to RMR. After 20 years, the records are moved to the National Archives.
Maintain Violations
Violations happen when a document or a case exists in the system for a paper or CD submission, but does not
exist physically. When the documents are checked for completeness at the end of the day or when the
documents are audited, this situation may happen. The most likely cause for this is misplacement and this
situation is extremely rare. In the event this happens, the Submission Processor will notify TSCA TSS of the
violation. TSCA TSS will create a violation letter to notify the submitter of the violation or the breach of CBI
security. The original notice letter is captured as a support document, violation information is captured, and the
letter is mailed to the submitter via the outgoing mail process. Copies of the letter are filed in several places
within CBIC.
The violation letter is actually processed as a support document. A DCN is generated and a barcode is printed
and applied to it. The parent case for the support document is the case for which the document is missing. This
is an internal support document with a support document type of "COMMUN TSS". The staff author is the
name of the person who signed the violation letter. The technical contact and submitter information pertains to
the submission containing the violation.
Violation information is captured and tracked with the submission.
Review Case file
When a submission is assigned a DCN, it is placed on the server for review by MTS users. Both the image and
the metadata about the submission is available for review. Once a DCN is generated, any support documents
received from the submitter are tracked as amendments and are kept in the same case file. If there are studies or
additional comments that chemists or other reviewers want to attach with the submission, they can submit them
as internal support documents. These documents will be kept and made available with the case file.
155 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
Submission Processor
MTS
V
V
/ request to
V review casefile
A request to submit
V study/report
\l
request to transfer
sanitzed copy
f request to capture
y pickup information
create a
violation letter
\l
request to capture
violation information
request to retire
submission
select submission
to retire
«use (...
review
casefile
«use case»
submit internal
support document
«use case» X
transfer J
sanitized copy /
«use case»
pickup
sanitized copy
«use case»
Submit internal
support document
«use (...
Maintain
violations
present a list of submission
with "ready to retire" state
[ paper]/<>
. ( retire paper
\submisison
else
«use case»
retire electronic
submission
156 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Considerations
Transferring Non Confidential documents to NCIC
1. Only sanitized paper copies are transferred to NCIC.
Retire submissions
1. All documents in a case file are retired at one time.
2. It is assumed that the case file is audited before it is retired. This will minimize the possibility of
inconsistent physical and system case file contents.
3. In the event that a support document is associated with more than one case file, the electronic copy will
be retired according to electronic copy rules and the physical paper copy, if available, will be retired
with the primary case file.
4. If a document within a case file is unaccountable, the case file may still be retired. This determination is
up to EPA.
5. The system will notify the Submission Processor when the retention period of submissions are expiring
and submissions need to be retired. The system will designate their status to be "ready to retire".
6. For a consolidated submission, all the documents within a consolidated submission are retired at once.
The folder description for a consolidated submission consists of the first and last case number pertaining
to the chemical. For example, P-07-0001 thru P-07-0004 indicates that there are 4 chemicals in a
consolidated submission.
7. A case file inventory report is generated at the end of the retire process. For each case, if all the
documents were accountable and retired, the case is assigned "Closed" status. If a document is
unaccountable, the case file status remains "Open".
8. YSU and NOC submissions are also retired when a PMN submission is retired as they are stored in the
same case file as their parent PMN.
9. If there are different types of documents in a case file, i.e. some electronic and some paper, the paper
documents are retired according to paper retirement rules and electronic ones are retired according to
electronic rules. Note, when a case is unretired, both electronic and paper archival locations are checked
for information.
Maintain Violations
1. The support document associated with a violation is the violation letter that is sent to the submitter.
2. The parent DCN specified for the support document is the DCN for the document that is unaccountable.
3. Violation information consisting of the DCN of the violation letter and other information is captured and
tracked.
Review Case file
1. The case file review pertains to the internal EPA review of the PMN submission. Only people who are
qualified to view section 5 documents are allowed to review case files.
157 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
2. Any comments or studies that Reviewers want to attach with the submission are included as support
documents. The reviewer will have to complete the submit an internal support document use case for the
study/report.
Workflow and Life Cycle Placement
Transferring Non Confidential documents to NCIC
When a sanitized copy is transferred to NCIC, the status of the sanitized copy changes to "transferred". The
submission remains in the active state. Once the copy is transferred, it does not come back. When the copy is
picked up the NCIC personnel, the status of the sanitized copy changes to "PickedUp". The following diagram
shows various states of the sanitized copy:
These states do not apply to
submission but to the
sanitized copy of the
submission provided by the
submitter
Sanitized (fopy Transferred
Transferred 1 Pickup
PickedUp
Retire submissions
Retire has a couple of states associated with the submission. When the retention period expires for a
submission, the submission moves to a "ready to retire" stage. It remains in that state until the submission
processor retires the document, when it moves to a "retired" state. It remains in the retired state until a request is
made to reactivate or un-retire the submission. Then state of the submission then becomes "active" and the
information associated with the submission is either obtained from FRC (for paper submissions) or copied back
from the archival location, in the case of an electronic submission. Even for the paper submissions, the scanned
images and extracted data is saved to the archival location.
158 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
unretin
retention period expired ]
Maintain Violations
When a violation occurs with a submission, the violation status for the submission is changed to unaccountable.
The status of the submission still remains active, unless the whole submission is unaccountable. In this case the
submission itself is made unaccountable. The submission remains in this state unless that document or
submission is found, in which case the state of the submission becomes "active" again.
159 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
These states pertain to the state of a L
submission and not individual
contents of the submission
physical submission not found
Unaccountable
physical submission gone ]
Violated
document lost / document status = unaccountable
physical submission lost
Active
submission found
If the one or more of the contents of the case is L
unaccountable, the status of the content that is
unaccountable changes to "Unaccountable". The
overall status of the submission remains "active"
Review Casefile
There are no states associated with review of a case file.
160 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
Submission
Processor
Pickup Document
Transfer Document to NCIC
Retire E ectronic Submissions
Retire Paper Submissions
Submit Internal Support
Documents
Maintain Violations
161 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases and Associated Activity Diagrams
Transfer Document to NCIC
Description: The use case describes the process of recording the transfer of a sanitized version of a submission
over to NCIC.
Actors: Submission Processor
Diagram:
162 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submission Processor
Transfer Document to NCIC
Sanitized submission is in paper format
Sanitized version of CBI submission has
been identified during barcode generation
T
request to transfer
document to NCIC
V
/confirm transfer^
y date
/change transfer\_
V date J~
MTS
obtain submission
information
\l
default transfer date to
current date
\l
request confirmation
of transfer date
\l
save transfer date, time and
transferred by
\j/
update submission status
to "transfer to NCIC"
163 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
r^^^-^—--—jg^^^^^^^^^^^^^^^=^^^^^^^^^^^^^^^=
Pickup Document
Description: The use case describes the process of capturing information about document pickup by NCIC.
Actors: NCIC, Submission Processor
Diagram:
Pickup Document AD
NCIC has been notified that the sanitized
submission is ready to be transferred
T
requests to pickup a
submission
" request DCN of submission ~\
being picked up "/
«Use Case» N.
Transfer )
Document to NCIC J
requestto confirm
pickup to be saved
save pickup
information
Submission Processor
request system to capture
pickup information
^ confirm pickup
to be saved
164 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Review Case File
Description: The use case describes the process of reviewing a case file and selecting a document in a case file
to review or print. The system verifies if the requestor has appropriate CBI clearances before providing files for
review.
Actors: Reviewer
165 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Review Casefile AD
Submission has been assigned a DCN and
is available to be viewed in a case file folder
Reviewer is authenticated and
authorized to review a casefile.
review case
contents
/requesttoprintV-
ycase contents^/
identify content(s) and identify
-------
MTS NCS Software Requirements Specification Model Report
Retire a Paper Submission
Description: The use case describes the process of retiring a paper submission from active status. The entire
case related to the submission is retired at the same time.
Actors: Submission Processor
Diagrams:
Submission Processor
Process Retire Discrepancy AD
( provide DCNs of the documents
\ in physical case file
search for the missing
DCNs
[ found 1
request NCS admin to N
change status to active J
[ not found ]
/request NCS admin to change
V status to unaccountable
Submission processor has notified MTS that physical
contents of a case file do not match with system contents
i
f request to provide DCNs of the ^
~y documents in physical case filey
\ Physical docs > System docs ]
.'provide a list of DCNs that exist
y physically but not in system
c
\/
notify NCS Administrator to
add DCNs in system
[ Physical Docs < System Docs ]
provide a list of DCNs that exist in \
system but not physically J
167 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Retire Paper Submission AD
f Retention period for he submission "1
is known by the system
' FRC has issued an accession number.
There are typically 25 boxes in an accession
Submission Processor knows the accession number
and the box number for the document to be retired
Submission Processor knows the case numbers to be
retired and have the casefile(s) in their possession
System has alerted submission processor that a subm ssion is about to be "1
retired and the processor has confirmed retirement with program offices
0
V Section 5case(s) /
[ provide
c
f prov.de case >,
V numberfs) to retire J
( Select case >
V numberfs) to retire _/
V contents and reports discrepancy J
f provide Box Number, total number of N
f scan document \
This is based on retention period. t^
System determines when a document is
ready to retire.
determ ne and present a list of "ready to retire" cases and ^
[ select ] ^X^
^^ [ invalid \j^ jnfbrm inval d ^
[ va id ] 1
r e sell ~^ already retired /
^ present contents ofa case ^ Contents include: Original ^
Sanitized copy, if CBI
V
C Physical contents and report discrepancy^ £ Present contents ^
f [Else]
iNo more cases to retire ]
/^request Box Number, total number of \
V boxes, and Accession Number }
^^ [else] x inform "f°rr"r^
[ box and accession Number valid ]
V
f Request to scan barcode of S
V a document in case file 2
.^\ [ else ] ^ ^^ [ invalid^ ^ <
-------
MTS NCS Software Requirements Specification Model Report
Retire Electronic Submission
Description: The use case describes the process of retiring an electronic submission's case file from active
status. The entire case related to the submission is retired at the same time.
Actors: Submission Processor, Archival Location
Diagram:
169 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Retire Electronic Submission AD
Retention Period for the submission has been defined
Submission Processor knows the case numbers to be
System has provided alert about retirement and the processor
has confirmed retired with the appropriate program office
1.
request to retire electronic "\
PMN submissions )
/"determine and proyde PMN electronic submissions that ~"
-> are "ready to retire" based on retention schedule
t to identify "\
ts to retire )
''present contents ofthe case "
^/"determine if case is ~\
V consolidated case J
t [ consolidated f' add to list all cases in consolidated "\
^> ^ submission to retire J
f request to sa\e archival folders with
y archi\al informational archi\al location
170 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Unretire a Case File
Description: The use case describes the process of unretiring an entire case file, versus unretiring just one
document. Other document status assignments or changes must be done through the Assign Document Status
use case or the Change Document Status use case.
Actors: NCS Administrator
171 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
172 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
: NCS Application Administrator
Unretire a
Case Rle
i
request to unretire
a case file
provide case y
number J~
[ cancel ]
provide box numbers and
accession numbers
NCS Administrator knows the case number,
box numbers and accession numbers
request case
number
provide error
message
[ closed ]
provide error message
about active case file
present 11st of contents of case file and \
request confirmation of request to unretirey
determine which documents
are paper media type
[all electronic]
[paper]
request box numbers and accession
numbers of paper document
[ invalid ]
[valid] \|/
o-
[accountedfor] \j/
provide error message regarding
box or accession number
provide message about unaccountable documents
and record status as unaccountable
J
change status of
documents to active
( record reason for change as request to N
X. unretire, and save date, time and user name j
determine which files are
electronic in the case file
[no electronic]
[electronic]
liC' |
/obtain electronic file
V from archives
change status of documents to active, record reason as
request to unretired and save date, time, and user name
173 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Maintain Violations
Description: The use case describes the process of adding to or editing the information about a violation letter
support document.
Actors: Submission Processor
Diagram:
Submission Processor
Maintain Violations AD
A non-network document has been deemed
unaccountable as a result of Audit or review
Violation letter has been delivered to
submitter with date and time stamp
Documents are stamped
with TSCA CBI or Non CBI
A document type of 'Commun TSS" has been created
to represent that a document is missing
1
/"requestto maintain information X_
y about a violation J
/'provide violation
^ letter DCN
Notification support document
information includes:
DCN of support doc, mail receive
date, subject, document type
r\
review information
and inform next step
provide violation "V-
information or edits }
Violation information includes:
Technical contact Name, address, phone, email, DCN
of the missing doc, Addressee name (submitter name
to whom letter will be addressed), Comments
Support document
is the violation letter
provide a list of all support documents with
Commun TSS document type J
/"request DCN for notification su
~y document for missing doc
obtain and present information about the
notification support document
'request for violation
information
[edit]
/'present violation information associated with the^.
~X notification support document and allow edits y
~fr validate information "N,
provided
174 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
YSU and NOC submission
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
SubmitterAbbreviation
PlantID
TechnicalContacts
CfficialAgent
ChemicalName
BarcodeSanitzedFlag
UserfeeStatus
Related DCN
RelatedOriginalDCN
ConsolidatedFlag
PCNumber
TS Number
JointFlag
CBI
CBICIaim
CBIOther
DCN
SanitizedFlag
SanitizedDCN
BarcodeOriginal Flag
JointMailReceiveNumber
NumberOfChemicals
RetireCaseStatus
ViolationStatus
/ X
/ Violation Lotto
/ Violation DCN
/ ViolatedCaseNumber ^"
/ ViolationLetterDCN
SubmitterAbbr 0..1
StaffAuthor
0 1 ViolatedDCN
/ \
/ \
1 \ SanitizedCopy
1 TransferDate
TransferTime
DCN
PickupDate
PickupTime
^. Status
\^
1 \^
^\ Case
1 CaseNumber ^________
ListOfDocuments ^~
\ Status 1
\ 1 ContentsType "~~~~~ ^^^
\
\ ^ 1--n
\0..1 \
RetirePaperlnformation \
CaseNumber \
AccessionNumber V 1
Support Document
DCN
Barcode
Barcodeflag
SanitizedCopy
Sanitized Barcode
MailReceiveNumber
SubmitterAbbr
ParentDCNs
Comments
Status
CBI
DocumentCategory
DocumentType
Receive Date
DocumentSource
StaffAuthor
ImageOfSupport
O..n
0..1
FolderDescription
DateRetired
RelatedRetirelnformation
RetirelD
FolderlD
Contents type means whether t^
all documents in it are
electronic, or paper or both.
This is used when retiring a
case
ListCXCases
FolderDescription
FolderlD
CaseNumber
FolderDescription
DateRetired
RelatedRetirelnformation
RetirelD
RetireLocation
FolderlD
175 Of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submission Scanning
Description
This process only pertains to paper submissions. The idea is to digitize a paper submission so that it is readily
available for reviewing. The scanning process includes creating an image of the submission, extracting metadata
from the submission, and saving it on the server. Metadata is used for processing purposes, whereas the image
is used for reviews. This eliminates the need for making paper copies and processing the copies which is a
significant savings in the time and processing of the submission. It eliminates the need for login, logout, shred,
and auditing of copies amongst other things.
The success of the scanning process depends upon the technology used for the scanner. The goal is to minimize
scanner errors and and the need for reconciliation between the extracted data and the actual data on the paper
submission. Once the document is scanned and data is extracted, a Submission Processor has to compare
submission data extracted against the submission image with the actual data. If there are any discrepancies, the
data is corrected using the View Edit Submission process. Since data has to be accurate according to the
original submission, it goes through a quality assurance process.
If the scan of a portion of the submission is wrong, the Submission Processor can rescan just the portion that
was wrong if the submission image has not yet been saved on the server. However, if the image has been saved,
the submission will have to be rescanned. In this case, the case number is preserved and all its contents are
deleted.
Once the image is scanned and placed on the server, any MTS user should be able to view it.
176 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
1
V
request to edit \_
submission J
request to
delete
/'provide answer""^-
V. J~
submission with
case number
present image and
data extracted
-psave image and data extracted in
V case folder on server
«use c...»
edit
submission
Else J^change status
to "scanned"
\ consistency and, completeness pass ]
change status to
"ready for PCM"
-^ request delete casefile or \
V just contents /
~ delete based
on answer
^request to view\
y submission
177 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Considerations
1. In edit data, only the contents of the submission are checked and data in the attachments is not checked.
2. When editing data, a reason can be optionally provided to indicate why the edit was performed. This
information is saved for the edit session and is optional.
3. The Submission Processor is provided with the data extract so that they can determine if it is correct.
4. The technology used for the scanner and process used to scan need to ensure minimal rework on the
Submission Processor's part.
5. Once the edits are done, the submission is saved with the prescreened status. Only when a submission
passes the consistency checks and completeness checks will the submission state change to "ready for
DCN". Hence, every time edits are done, the system will determine if the state of the submission needs
to change to "ready for DCN".
6. If a user requests to view a submission, an image of the submission is provided.
Workflow and Life Cycle Placement
The scanning stage comes after prescreening and before DCN generation for paper submissions. Until scanning
is successful, the submission remains in the "prescreened" state. Once the scanning process is complete, the
submission moves into a state called "scanned". Note that this state only applies to paper submissions. For
electronic submissions, if the edit process fails the consistency and completeness check, the submission state
goes back to "Prescreened".
scan fail[ paper ]
edit[ consistency anrdcompleteness check fail ]
Scanned
edit[ consistency and completeness check pass ]
edit[ consistency and completeness check fail
edit[ consistency and completeness check pass
Use Cases Involved
178 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Scan Submissions
Submission
Processor
Edit Submission
MTS General
User
View Submission
Use Cases and Associated Activity Diagrams
Scan Submission
Description: The use case describes the process of scanning paper submissions after they have completed
prescreening, but before they have received a DCN. The Submission Processor reviews the scanned image for
readability. The Submission Processor also reviews the data fields captured during the scanner's OCR process.
The processor may choose to do a partial rescan or full rescan of the document if either the image or the data
capture is not successful. If a user finds problems with the scan or data capture after this process is complete,
the user must rescan the entire document and delete the old version. See the View or Edit Submission Use
Case.
Actors: Submission Processor
179 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
: Submission Processor
Scan Submission
request to scan
document
provide login and ^r~
authentication information -7-
\F
f provide document
V for scan
A
review scanned
image
provide page
numbers and order
[ error ]
' good scan ]
'eview extracted
data
[ reject ]
[accept]
provide M R# and case
number for scanned image
Submission or document has
completed prescreening
Paper document is available to
submission processor
Case number has
been established
request login and
authentication information
error ]
EPA would like to sign
on only once during
scanning process
\|/ [ success ]
request Submission Processor
place document on scanner
scan document on
scanner equipment
present scanned
image for review
-/^request new pages or order of "N
V pages to be rescanned J
partial rescan ]
[ entire rescan ]
delete previous
scan output ,
extract data and
provide it for review
_^Jrequest MR# and case
-\. number of scanned image
jgfsend image and data extract
\^ from scanner to server
save image under case number and A
data fields on sener in casefile folder^Z_
180 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
.mr
View Edit Submission
Description: The use case describes the process of editing the content of a submission before it receives a
DCN. (See the Modify Section 5 Submission use case for modifications after a document has a DCN.) The
MTS user may edit the submission to correct errors identified in writing by the submitter or to correct errors
created during the OCR/scanning process. All MTS users may view a document. Edit capability may be
limited based on user roles. MTS will maintain an original version of data received by the submitter that cannot
be edited.
Actors: MTS User
Diagrams:
View or Edit
Submission
iew Edit C\
ubmission
I
«subflow»
view
submission
[cancel]
edit fields
c
request to N^
save edits J
^provide reason for"
y edit (optional) _
C
request to edit ^V-
submission J
confirm
deletion J~
provide OCR data
check status ^
electronic submission has been received
and a copy of the data has been created
paper document is available if
edit is checking OCR quality
paper submission has been received
and scanned in to the system
«use case» N.
initiate ModifySection F
5 Document ./
ssigned
provide submission with editable
fields based on field rules
edits
pro vide error message N error found ]
regarding invalid information ^
[valid]
/request reason "\
^V for edits J
_J
_/^COl
V c
infirm OCR data
heck complete
f save edits, reason for edits if
^record OCR data V~^ provided, and audit trail information
V check status J
181 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
View Submission sub flow
T
request to view
a submission
\l
./
V
c
provide search criteria including ^T"
awaiting OCR option ~^~
\l
/'select from list^,
provide submission
identification
l\
N
_/
review
submission
~\
J
[edit]
lse]
request submission
identification
)
./request search N
s*y criteria J^_
[ no match ]
<
[ matches ] w
_!/present list of search results
V and request selection
provide message \
regarding null results J
validate
identifier
provide validation
error message
«use case»
editsubmission
182 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
ChemicalName
GenericUse
SpecificUse
MailReceiveNumber
BarcodeSanitzedFlag
UserfeeStatus
RelatedDCN
RelatedOriginalDCN
Support DCNs
ConsolidatedFlag
PCNumber
TSNumber
PaymentID
JointFlag
CBI
CBICIaim
CBIOther
DCN
SanitizedFlag
SanitizedDCN
BarcodeOriginalFlag
JointMailReceiveNumber
DaylReviewDate
NumberOfChemicals
Scanninglnformation
CaseNumber
Image
Status
MailReceiveNumber
ScanBy
ScanDateTime
Submitter Management
Description
This module pertains to adding and modifying submitters and related information. Submitter information
consists of Submitter, plant (also known as site or facility), Technical Contact, Official Agent and Embassy.
183 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submitters can be thought of as a parent and plant, technical contact, official agent and embassy information
associated with it as its children. However, if submitter information is updated, information associated with the
children may or may not be updated.
The plant site information consists of Plant ID, city, state and EPA region. EPA regions are predetermined and
are based on the location of various states. When a plant site is added, the EPA region is assigned. A plant ID,
assigned by the system, uniquely identifies a plant site as their can be more than one plant sites in the same city,
state, and EPA region. Also note that the plant site is manually looked up in FRS as well as a facility ID from
FRS, if a match is found.
184 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
T
1 T I
1
[ New]
V
/" updates "\
|
(A- <^V
^^K "^^
Y
f confirm new ~\
V submitter }
\
V to be added y
f request updated >
V information J
V track updates to submission J
4
^ determine if submitter information X
V from submission exists in MTS J
tXISTS
-^/ «use case» X if^i
I maintain submitter j ^®^
V information /
[ Does not (. xist ]
^ —
( Inform new X
V submitter J
^
^ opeuiy buumuiei auuieviauuri ^
i
abbreyation J
•b
( ensure submitter X
V abbreyat on is unique J
\
/'request submitter and *s
V related information J
f sa\« submitter information and X
V replace submitter abbreyation J
\i
^sa\« site ID from FRS X
Vwith Plant information J
4
Use submitter name and l\
zipcodeto do a partial
match
T request to add X
V new submittery
y
f proyde submitter >>
V. abbreyation J
^
f~ proyde submitter and related "\
V information if applicable J
Nf
( request to add X
VSitelDfrom FRSy1
^.request to maintain submitter or "\
v related information J
\
^V information J
Considerations
Existing submitter information from CBITS will be migrated into MTS initially. This includes
Submitter, Plant, Technical Contact and Official Agent. Thereafter, submitter information will be
maintained in MTS.
When the submission first comes in through mail, the Prescreener will attempt to match the submitter
with an existing submitter in MTS. Since there is no unique identifier provided by the submitter, the
match is made using partial company name (first 5 non-space letters) and a zip code provided with the
submission. The Prescreener determines if there is a match and identifies it, creates a new submitter, or
uses the "NeedToAdd" abbreviation.
185 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
3. A submitter is added or maintained by the NCS System Administrator.
4. When a submitter is added, the NCS System Administrator provides a new submitter abbreviation for
the submitter. The system ensures that the submitter abbreviation created by the administrator is unique.
5. When a submitter is added, the user checks site information in FRS. If a match is found, the user
manually adds the site ID obtained from FRS in MTS.
6. The process of updating a submitter or its related information is the same. Only the data is different.
Hence, there is one generic use case provided to show maintenance of submitter information.
7. Unique IDs for each type of information is as follows:
a. Submitter - Submitter Abbreviation
b. Plant - Plant ID or Site ID
c. Embassy - Country
d. Technical Contact - Full Name
e. Official Agent - Full Name
8. Submitter changes are tracked once the submission gets a DCN i.e. all updates to the submitter are
preserved. Once the submission review cycle is complete, the submitter change tracking is discontinued.
Workflow and Life Cycle Placement
Submitter information is added, if not there previously, when a submission comes in. In order to expedite the
process, the prescreener checks if the submitter exists, and if not, then uses the "NeedToAdd" abbreviation for
new submitters. This implies that the submission can continue with the review, however, it will not get a DCN
until submitter information has been added. Once the submission is ready to get a DCN, MTS checks to ensure
that the submitter abbreviation is not "NeedToAdd". If it is, the system will not assign a DCN and deems
submission incomplete. There are no states associated with adding a submitter, only that submission is not
complete until a submitter has been added.
[ Submitter abbreviation = NeedToAdd ]
Incomplete
[ Submission complete & subnitter abbreviation !-= NeedToAdd ]
V
Active
Once a submitter has been added, the submitter information can be modified. Changes to submitter information
are tracked by MTS until the review period begins. While a Prescreener determines if the submitter needs to be
added, a Submission Processor can edit submitter information during the course of submission process leading
186 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
up to DCN generation. It is the NCS System Administrator who actually adds the submitter as they need to
assign a unique submitter abbreviation to the submitter.
Use Cases Involved update diagram to show NCS System Administrator
Prescreener
Process Submitter in Incoming
Mail
Submission Processor Maintain submitter information
MTS Administrator
Add submitter information
187 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
^^^
Use Cases and Associated Activity Diagrams
Process Submitter in Incoming Mail
Description: The use case describes the process of attempting to match a new submission to an existing
submitter when the submission is processed through incoming mail. The prescreener will attempt to match the
submission to an existing submitter abbreviation. If none can be located, the abbreviation "need to add" is used
until the submitter is added through the Add Submitter Information use case.
Actors: Prescreener
Diagram:
Admin Prescreener
WITS
Process Submitter in
Incoming Mail
¥
request to process submitter
abbreviation for incoming mail
[no match ]
[find match]
/select matching submitter
\abbreviation
Paper submission submitter information has
been entered during incoming mail process
Network submission has
been loaded into MTS
CD submission
has been uploaded
obtain submitters that match
first letter of name and zipcode
3 or more match ]
[ no match ] / —— ———
-~/ record submitter abbreviation
as "need to add"
I
use abbreviation of
selected submitter
188 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Add Submitter Information
Description: The use case describes the process of adding a submitter to MTS. Each submission will be linked
to a unique submitter abbreviation. If the submitter does not exist in MTS when a submission arrives, a "need
to add" status is given to the submission submitter information until this use case can be completed. The Add
Submitter use case allows the Submission Processor to add a new submitter and corresponding abbreviation so
the "need to add" value can be updated with an abbreviation. A submission will not receive a DCN until it has
been linked to a submitter abbreviation.
Actors: Submission Processor
189 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
MTS Administrator
Add submitter information AD
submitter information to
be added is available
T
request to add \
submitter information J
select from list
identify if company exists
and notify system
/" select submitter
V that matches
provide unique
abbreviation
review submitter information
and edit as appropriate
provide FRS
site ID if known
provide list of submissions with
"need to add" abbreviation
provide list of companies with
names and zip code matches
( request to identify
y matching submitter
[does n
/"replace "need to add" abbreviation with N
identified submitterabbreviation J
k
^request unique abbreviation
^v for the new submitter
it exist]
provide error
message
[unique and valid ]
present submitter information for
review and edit
request FRS
site ID
[invalid]
[valid] |
provide error message
regarding invalid information
/'save new submitter \
V information J
replace "need to add" abbreviation
with new abbreviation
190 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Maintain Submitter Information
Description: The use case describes the process of maintaining submitter information in MTS. Each submitter
is assigned a unique abbreviation. The submitter information includes data about plants, points of contact, etc.
that can change over time.
Actors: Submission Processor
191 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Submission Processor
Maintain submitter information
T
request to update
submitter information
[ identifier known ]
c
( Else ]
V
provide submitter
related identifier
f request to search
V for submitter
/'provide search
V criteria
select submitter related
information
( change submitter
V related information
request submitter related
information identifer
Includes plant ID, technical
contact full name, official
name, embassy ID,
and submitter abbreviation
request search \g
criteria J
o
[ Else ]
notify no
match found
[ Match(es) found ]
-.^provide matching results and request toN
V select submitter related information J
\/
f obtain submitter related \
yinformation and present for edity
l\
validate submitter
information
[ invalid ]/-notify of error
[ valid ]
\/ [ related active submission ]
O
[ no related act ve submission
maintain history of submitter information
for active related submissions
C
save submitter
information
192 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
"Hf
Data Entities Involved
Submission
CaselD
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckllserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
Submitter
Abbreviation
Name
Address
TechnicalContacts
Plants
OfficialAgent
A 1
l.n
Plant
PlantID
PlantAddress
SitelDFromFRS
SubmitterAbbreviation
O..n
TechnicalContact
Name
Address
Telephones
EmailAddresses
SubmitterAbbreviation
OfficialAgent
Name
Address
Telephones
EmailAddresses
Support Document
Description
Support documents are documents that are sent in reference to an original case file that is established and is
under review by EPA staff. These documents may be submitted in response to a request from EPA for more
information, or to provide the missing information to make a submission complete. Support documents that are
sent by submitter are called external support documents and always have a mail receive number associated with
them. Examples of external support document include:
193 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
• Amendments
• Corrections
• Commun TSS documents
• Withdrawals and
• Letter of support.
Usually, mail receipt information is always associated with the external support document. However, if the
external support document is not received via mail, but is attained via fax, it will not get a mail receive number.
Internally to EPA, support documents may be generated when a section 5 submission is reviewed. These
documents are also included in the case. For internal documents, a mail receive number is not required. Some
examples of internal support document include:
• Chemistry Reports
• CAS Research
• Engineering Reports
• Exposure Reports
• Acknowledgement Letter and
• Suspension Letter/Requests.
A DCN and a barcode, for paper submissions, is generated for the support document if the information provided
for the support document is complete. Also, a sanitized DCN and barcode (for paper submission) for the
sanitized copy is generated if the support document is CBI and if a sanitized copy was provided by the
submitter.
One of the required pieces of information for the support document is a Parent DCN or the case number the
support document is associated with. If the case number of the support is not provided by the submitter, the
document is held by the Prescreener until the information is obtained. Only when a case number or DCN for the
parent is available, will the support document be processed.
A support document can be associated with more than one parent. In this event, a primary Parent is designated
and used to determine the DCN for the support document.
Information for a support document can be modified after a DCN has been generated, so long as it does not
invalidate the support submission. Also, a DCN and a barcode is generated for a support document if a sanitized
copy provided flag was set to yes by the Submission Processor. Sanitized copies of paper support documents are
transferred to NCIC.
194 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
SIT
Overall Process
Considerations
4.
If during modification, the flag for a sanitized copy is set to "N", it is the submission processor's
responsibility to delete the physical barcode. The system will delete the DCN for the sanitized copy. On
the other hand, if the flag was initially set to "N" and it is made "Y", a sanitized barcode and DCN is
generated if it does not exist already.
If a parent Section 5 case for a support document exists in CBITS, the support document will be
processed in CBITS as well.
When a support document is submitted and a parent original case number is not provided, it may be
because it is meant to be a correction and a parent case number is not available. In this instance, the
support document does not get a DCN but is replaces the incorrect information page (if sent via paper).
For electronic submission, once the original submission information received from submitter is saved,
any changes before DCN generation is made to the submission and not treated as a true support
document with a DCN.
When a replacement is made in original with a support document, the old document is retired with a
mail receive number barcode (if paper) or a mail receive number DCN if electronic.
If the mode of submission for parent original case is different from the support document, the support
document is made to be the same mode as the parent original case. For example, if the parent original
case is paper and the support document is electronic, the support document is printed so that it becomes
paper as well. This applies to replacement support documents.
195 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
6. For replacement support, if the parent original is electronic and support is paper, then support is scanned
and image is captured. If the support is electronic, then the change is made to the original while
maintaining the sanctity of the submission.
7. A support document can belong to more than one case file. In this case, the paper support document, if
applicable, is kept with the primary case file and its electronic copy with the same DCN is placed in the
other related case files. Only one DCN and a barcode will be created which will be applied to the
support document that goes to primary case file. For all other case files, an electronic copy of the
support document with the same DCN will be created for each case. MTS will ensure that if the Parent
DCNs are modified, the copies are adjusted accordingly. If another parent is added, MTS will add an
electronic copy to the newly related case. If a parent is removed, the electronic copy of the support will
be removed. It is up to MTS design team to decide whether they want to maintain a link to the support
document (preferable) or make an actual copy of the support document.
8. For replacement support documents, if the parent original is paper and the support document is paper,
then the support document replaces the old/incorrect page and the old/incorrect page is retired. If the
support document is electronic, it is printed and replaces the old/incorrect page. If the parent original
has already been scanned at this point, then support document is scanned and the image is saved.
The support document data is extracted in this case and replaces the older data, while the older
data is saved.
9. If an electronic support document is associated with multiple cases, all the parent DCNs are specified
either when the support document is created or when a support document is modified. MTS will ensure
that the electronic status of the support is same as the physical status, i.e., the electronic copy (image) of
support document is placed in all the Parent DCN case files.
Workflow and Life Cycle Placement
Support documents have almost the same states as an original submission. Once a support document comes in
through mail and is prescreened to see if all necessary information is present, it can either remain in a pending
state until all information arrives, go through DCN generation and become active, or it can replace a document
for an existing submission. All sanitized copies of an active support document with a DCN are transferred to
NCIC.
196 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
ccmplete ]
V
prescreeni
incomplete ]
V
Pending
[No
case number ]
modify[ com Dlefe] \ Prescreenin9[ complete ]
prescreening[ complete ]
Active
[ CBI and Sanitized copy provided ]
V
Sanitized
Paper copy ]
V
V
Replacement
Transferred
197 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
Submission
Processor
Prescreener
Modify Support Documents
Scan Support Document
*Process Support Document..
'Process Replacement Support
Document
«System Actor»
CBITS
Submission Reviewer
Submit Internal Support
Documents
198 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases and Associated Activity Diagrams
Process Support Document
Description: The use case describes the process of process an external support document sent by a submitter to
EPA. The Submission Processor identifies if the support document has enough information to identify the
submission it is related to. If there is not enough information, the processor will contact the submitter using the
Capture Communication Log use case. If the support document is to replace information received prior to the
support document it is processed through the Process Replacement Support Document use case.
Actors: Submission Processor
199 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Process Support Document AD
Document arrived has been determined as
support document. See Incoming Mail.
request to process support
External Support document meta data consists of:
Mail receive number, Document type, CBI, Sanitized
copy, received date, Parent DCNs and case numbers,
Primary DCN and case number, Support Document
:ategoty, document source, Submitter name.address,
:ity, state, and zip
provide meta data *—
information about support
A support document can be associated with
; than one original submission
If support is for an original that exists in CBITS,
the document will be processed in CBITS
provide a list of support documents awaiting processing
•^ and request selection or DCN or Case Number J
~~7*request meta data \
information about support
validate metadata
information J
f saw meta data \
information about support
1
^associate support document with all parent
V DCNs and record primary parent DCN
~
200 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
201 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Process Replacement Support Document
Description: The use case describes the process of process an external support document sent by a submitter to
EPA that arrives while the original submission is still in prescreening. The data on the support document is
needed to complete the submission and make it complete. A support document cannot receive a DCN until the
original submission receives a DCN.
Actors: Submission Processor
Diagram:
202 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Process Replacement Support
Document
Submission has not
received a DCNyet
Submission has not
been scanned yet
It has been determined that this document is a replacement
for an existing document/page in a submission
1
/^request to proces replacement
support document
Search criteria consists of
MR date, MR#, document
type, submitter name and is
applied to documents that do
not yet have a DON
^replace original document-page^X
V vvith support document >~
/ process old page using Retire
V Incomplete or Replaced Document
/'present a list of all support documents that "\
~ are replacement support documents J
equest search cntena for submission
association or provide MR number.
''associate original with support by saving "\
t of support _}
\_ MR# of original with MR# of support
J [ original electronic^ [ support electronic ]
[ original paper]
[support paper] ^
[[support paper]
[ support electronic ]
print electronic support document page(s) A
«use case»
scan support
document
^ incorporate electronic data into original ^
^ document while maintaining sanctity of original ^
203 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submit Internal Support Document
Description: This use case describes the process of creating a relationship between a support document created
internally by an EPA employee, and an original submission. The internal support document will be placed in
the submission case file and have a DCN as a unique identifier.
Actors: PMN Reviewer
204 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
205 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submit Internal Support Documents AD
DCN has been assigned
to a submission
request to process a document
{ request iu pruuebb a uuuumeru \
V as internal support document _J
C
identify media type^
of document x
/"" provide location of
V the electronic file
[ case known ]
«use case» "N
Scan Support )<
Document /
S^ request if document is "\
y paper or electronic J
[ paper]
[ electronic ]
request location of N
electronic file ^
<5>""e>'
[ exists ]
V
^n
/^notify file does "N
V. not exist J
f place electronic support document file(s) in primary
V electronic casefile folder and all related case files
/'generate barcode(s) for the \
y support document(s) /
[ paper]
ate status to "awaiting scanning" and request to scan document and
~ then place support document with physical primary case file
206 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Scan Support Document
Description: The use case describes the process of scanning paper support documents after they have
completed the Process Support Document use case or the Submit Internal Support Document use case
The Submission Processor reviews the scanned image for readability. No data extract is done for support
documents. The processor may choose to do a partial rescan or full rescan of the document if the image scan is
unsuccessful. If a user finds problems with the scan after this process is complete, the user must rescan the
entire document and delete the old version.
Actors: Submission Processor
Diagram:
207 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Scan Support Document
1
request to scan
support document
provide login and
authentication information
\/
/'provide document \
\^ for scan /~
[good ]
provide DCN, and
case number(s)
•£ request login and N
^authentication informationy
[error]
[else]
request processor place
document on scanner
s^'scan document
V image
\l
present scanned
image for review
^ request DCN and related case numberfs) 'N
send image from ^,
scanner to server J
\l
save image on server in primary case
file and in appropriate case files
208 Of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Modify Support Document
Description: The use case describes the process of modifying metadata for a support document. Metadata for
support documents is initially entered through the Process Support Document use case and the Submit
Internal Support Document use case.
Actors: Submission Processor
Diagram:
209 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Submission Processor
Modify Support Document
Support document that is to be modified exists
and is known to submission processor
/'provide search ~N
y criteria J
[do not confirm ]
I confirm ]
f obtain support documents ~\
-^ that match criteria J
—i—- confirm addition or removal of support \
y document copies in parent DCN case files y
place copyof support document in new parent
DCN, remove copyfrom removed parent DCN
210 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
l.n
Support Document
DON
Barcode
Barcodeflag
SanitizedCopy
SanitizedBarcode
MailReceiveNumber
SubmitterAbbr
Parent DCNs
Comments
Status
CBI
Document Category
DocumentType
Receive Date
DocumentSource
StaffAuthor
ImageOfSupport
IncomingMailLog
MailReceiveNumber
SubmitterAbbreviation
TSNumber
JointFlag
ConsolidatedFlag
ModeOfSubmission
MailTrackingNumber
MailReceiveDate
Postmark Date
Carrier
RelatedMail Number
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
Chemical Name
GenericUse
SpecificUse
MailReceiveNumber
BarcodeSanitzedFlag
UserfeeStatus
RelatedDCN
RelatedOriginalDCN
ListOfSupportDCNs
ConsolidatedFlag
PCNumber
TSNumber
PaymentID
JointFlag
CBI
CBICIaim
CBIOther
DCN
Sanitized Flag
Sanitized DCN
SanitizedStatus
BarcodeOriginal Flag
Joint MailReceiveNumber
DaylReviewDate
NumberOfChemicals
RetireCaseStatus
ViolationStatus
YSU and NOC submission
System Administration
Description
This module pertains to functions and processes for application administration. There is a distinction made
between the MTS System Administrator and the NCS Application Administrator. The MTS System
Administrator is the overall MTS System Administrator who is based in Research Triangle Park, North
Carolina. The NCS Application Administrator is a local administrator who is available to handle issues or
functions pertaining to the New Chemical Submission (NCS) application. Most of the functions, except for
assigning MTS NCS Users, are done by NCS Application Manager for New Chemical Submissions. The
various functions performed by the NCS Application Manager are described in the sections below.
211 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
212 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
NCS Application Manager
MTS
f request to change
\ year
Query Last \
\^ Sequence used J~
request to \_
^reprint barcodey
request to add, modify A_
lookup table information J
request to Delete X_
Information y
request to
proceed
request to assign
document status
request to change
document status
«use case»
Change Year
use changed year for
DCN generation
A
«use case»
Query last Sequence
Number used
o-
[ Else ]
[ DCN exists in MTS ]
V
«use case»
reprint barcode
«use case» X—
*f Maintain Lookup j
V Table Information/
_/" warn if deleting will
~ make records orphan
«use case»
Assign Document
Status
^ case»
f Change
V Docum...
213 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Considerations
1. Most of the time, a fiscal or calendar year will change at the designated calendar date. However,
sometimes the year will be changed after an actual year change so that DCN generation can be
consistent, since the year is used as a part of the DCN.
2. Querying the last DCN sequence number used for all document types allows the NCS Application
Administrator to obtain the number of submissions processed for that document type in that year. This
information is again used for DCN purposes as the sequence number is a part of the DCN.
3. Barcode printing is always controlled by the system as a barcode makes a document official and the
mishandling of a barcode can cause a CBI Violation. However, in the event a printer is not working or a
barcode gets corrupted or some other mishap occurs with the barcode, a NCS Application Administrator
can request for a barcode to be generated. In this case, the NCS Application Administrator will specify
the barcode. The DCN associated with the barcode must exist in MTS in order for the barcode to be
printed.
4. Lookup tables are introduced as a means to allow customization of predefined values that are used in the
system. This is a pure design mechanism, however, the tables need to be controlled by the NCS
Application Administrator. This pertains to any data items that have a set of predefined values. It allows
those predefined values to be modified or added to in real time, without having to reprogram the system.
Examples of such lookup tables include EPA Regions, CBI Claims, States, etc. If a new CBI claim
comes up after the system is delivered and different possible values of CBI Claims were programmed in
the system, the new value of CBI Claim will have to be reprogrammed into the system. However, if the
CBI Claims are in a lookup table, the NCS Application Administrator can request to add a new value
using the functionality provided, without the system needing to be reprogrammed.
5. Lookup tables are only created for the predefined lists where a value change or addition will not cause
the system to require reprogramming. For instance, even though there is a predefined list for document
types, a lookup table for a document type will not work as adding a new value to document type will
require some additional programming of the system.
6. Any information can be deleted by the NCS Application Administrator. However, if deleting of a record
will make other records inconsistent, the NCS Application Administrator will be warned and provided
with other records that will become inconsistent. The NCS Administrator will not be allowed to delete
record that will compromise data integrity. Once the NCS Administrator takes care of other records and
data integrity is not broken, the NCS Application Administrator will be allowed to delete the record in
original delete request.
7. The assign document status and change document status processes are similar because they both involve
changing the status of a submission. The submission is allowed to go from one state to another and the
possibilities are predefined in the system. Based on the change requested, additional processing is done
to ensure consistency. Following are the status changes that are allowed for paper submissions:
a. Unaccountable to Active
b. Retired to Active
Information about the change transaction is tracked.
8. When the NCS Administrator changes the fiscal year for DCN generation purposes, the NCS
Administrator notifies everyone before hand of the time the change will take place and requests
everyone to logout. If anyone is still logged out at the time, the system will automatically log them out
so the fiscal year can be changed.
214 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Workflow and Life Cycle Placement
The following sections describe workflow for each type of function:
Reprint Barcode
Reprinting of barcode does not impact workflow or submission life cycle significantly. It is important to know
that the document will remain in an unofficial state until it has a barcode. Since there is no way for system to
know that a barcode has issues, the Submission Processor will notify the system of barcode issues and
request the system to assign the status of the submission to be "invalid" so that submission cannot be
used. Once the barcode is reprinted, the submission status will become "active."
[ Barcode Issues & DCN generated ]
Delete Information
Deleting information is done judiciously as it may cause data integrity problems. When something need not be
removed from the system but is not be used, its status is changed to "Invalid." However, deleting information
will actually remove that record from the system completely.
reactivated or reused
Active
Invalid
Submission Withdrawn or not Needed
215 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Maintain Lookup Table Information
The maintaining lookup table information does not cause changes to the life cycle states. With respect to the
workflow, the lookup tables are maintained upon request from MTS users and in conjunction with the
developers.
Assign Document Status and Change Document Status
Assigning a document status and changing of document states have everything to do with submission lifecycle.
A submission can be assigned a state or change from one state to another only if it is supported by the business
process and it does not leave a submission in an inconsistent state. Following are various states of the
submission and how the submission goes into them:
Active - The active state is when the submission is complete and has a DCN generated for it. It still has not
gone through CCD or EETD Review, but is ready to be reviewed by EPA NCS personnel.
Invalid - This state is reached when a submission is withdrawn or is not in a state to be reviewed or processed
any further. EPA still wants to retain information about the submission but it is not to be used.
Retire - This state is reached when the retention period for a submission expires. This causes a paper
submission to be stored in a box and sent to FRC and causes an electronic submission to be stored in a location
that still allows them to retrieve information for up to 20 years. Once a submission is in this state, it cannot be
used for any other purposes. If anyone wants to review it, it needs to be brought back into "active" state through
the "unretire" process.
Transfer - This only pertains to the sanitized paper copies of the submission. Once a sanitized copy is
transferred to NCIC, nothing can be done to it.
Paid - Once a user fee arrives and is applied to a submission, it's user fee status changes to "Paid." Once paid,
the submission remains in that state. It does not go back to unpaid.
Unpaid - This is a user fee status associated with a submission. The submission is initially assigned this status.
Once the user fee is paid and applied, the status changes to "Paid."
Incomplete - If the submission does not pass prescreening criteria due to missing legally required fields or if
the Prescreener has deemed submission to be "incomplete", the submission becomes incomplete and is retired.
This is also an irreversible state, i.e., once a submission goes into this state, it does not come out of it. If there is
any user fee associated with an incomplete submission, it is returned.
Ready for DCN - This is a state that identifies that the submission has passed all the consistency and
completeness checks and is ready for DCN generation. This is an intermediate state defined in order to let users
generate DCNs for multiple submissions at a time. If due to edits or changes to the submission consistency
check fails, the submission goes back to the prescreened state
216 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Prescreened - This state identifies that the prescreener has reviewed the submission and certified the
submission is approved to proceed to DCN generation and subsequent review by the CCD/EETD. Once a
submission reaches this state, the paper submission is scanned and data is extracted. At this point, submission
can be edited to fix scanning errors. When errors are fixed, the submission is checked for consistency checks
and completeness checks. If the submission passes these checks, the submission goes into Ready for DCN state
and if it fails, it remains in a prescreened state.
Change Year and Query Last Sequence Number used
Changing a year or a querying for the last sequence number used does not impact the state of a submission. A
DCN will use the year assigned previously until the year is explicitly changed by the administrator. From a
workflow perspective, the user will be logged out when this change happens.
Use Cases Involved
Reprint Barcode
NCS Application
Administrator
'"Maintain Lookup Table
Information
Assign Document Status
Change Document Status
Change Year
Query Last Sequence Number
Used
Use Cases and Associated Activity Diagrams
217 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Assign Document Status
Description: The use case describes the process of assigning a document status to a document. Valid paper
document statuses are: active, unaccountable, invalid, or retired. Valid electronic document statuses are:
active, invalid, or retired. Changes to the status of an unaccountable document to active, or a retired document
to active, must be done through the Change Document Status use case.
Actors: NCS Administrator
218 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
: NCS Application Administrator
Assign Document Status AD
System Admin knows the new status of a document
I
request to change status of a X-
document within a case file J
[ known ]
V
provide DCN
[ unknown ]
request to search by submitter X-
name, receive date, TS_Number J
provide criteria^7
select DCN
/^provide new status, reasons X
V for change, date, time s
[else]
[ retire to active, or unacct. to active ]
Valid electronic document statuses are:
* Active
* Invalid
* Retired
The status assigned to a document IX
applies to all associated records.
f' request to provide DCN
~^_ of the document
validate DCN
[ else ]
c
notify error
[ valid & exists ]
/" present a list of
~y DCNs to select from ,
notify current status of the
document and request new status
assign new status to the document
and save reason, date, and time
(«UseCase»
initiate Change Document Status and
prepopulate DCN and status data
Valid paper document statuses are:
* Active
* Unaccountable
* Invalid
* Retired
219 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Change Document Status
Description: The use case describes the process of changing a document status from unaccountable to active,
or from retired to active. Other document status assignments must be done through the Assign Document
Status use case.
Actors: NCS Administrator
220 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
System Administrator
Change Document Status AD l\
f
/" request to change "\
V status of a document J
\|/ [ unknown ]
search J
[ \ :nown ] v
/'provide search N
V criteria J
\/
document DCN J
/'select change \,--
V option ^/
®< 0<
[ deny ]
confirm
\y
/" provide box number "\
Vand accession number y
^
/" provide comments, date, "\
Vtime and reason for change }
\
MTS
( When changing status from Ret re to Active, ^1
the documents are retrieved from FRC
/C request to identify document for
V status change
1
^,/VpqiiPst spamri'V..-
V criteria J
— >^ obtain results ^\
(
1 '
^S~^ [ no match
< — ^
)
Search by - MR#, Case#, ^
notify error N
v
] match ]
^"validate DCN existence "^
V and tormat
\|/ [ invalid or
^"valid,
/"present change optic
V and request to s
^f verify status ^\
^v^ change type J —
s~-
non ex is
)ns to ac
sleet one
Change options are: 1^
* Unaccou
tent Y notify of error >
^^
tor}
y
^ ^
•^ "^^
[ unacct to active ]
\l
/"present contents of the document \
V and request to confirm )
^ ^ — — f-ret.1 r j
^"change status ^\
V to active }
(request Box Nu
number re
\
<
^^^
itable to Active
Active
f «Use Case» "\
^\ 4» initiate Assign Document Status j
not retired or unacct. moving to active ]
d to active ]
^[ electronic]^ obtajn from
•^-^ ""v archival location
[ paper
\/
mber and Accession ^\
reived from FRC •&- ,
C match FRC box and accession ~\
number against system numbers J
^
^[no
^
match ]^-
V_
lotify that accession box \
number does not match -7— '
^ [ match ]
/"change the docume
V status to active
\
1
nt V
/
)
f" request comments, date "\
ytime and reason for changey
/* save information with the "\
Vtransaction and the documenty
J
D
221 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Change Year
Description: The use case describes the process of temporarily changing the fiscal year or calendar year for the
purpose of generating a DCN for a submission that needs to be accounted for in a previous year. This process is
expected to be run as necessary after normal operating hours.
Actors: NCS Administrator
Diagram:
System Administrator
MTS
Change Year
T
request to change
fiscal year
provide fiscal year or
calendaryearto be used
Process is run as
necessary after normal
operating hours.
disables generate DCN
functionality for other users
V
f request fiscal year or
•^calendar year to be usedy
~7^ temporarily change fiscal
y year or calendar year
/"«Use Case» X
( Generate DCN )
reset fiscal or calendar
year to current year
222 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Delete Information
Description: The use case describes the process of deleting information from the system. Items that can be
deleted include: mail receipt information, users, officials, plants, submitter abbreviations, technical contacts,
user fee data, violation data, scanned files, submissions, and support documents. The relevant records to be
deleted are specific to each type of deletion.
Actors: NCS Administrator
223 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
224 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
: NCS Application Administrator
Delete Information
/'request to delete
y information
/select type of information
V to delete record from
/provides information N,
V identification ^
do not confirm record
deletion
confirm record deletion
confirm record is
to be deleted
These are set deletion routines to ensure
proper cascading of deletions from the
system bythe administrator. The routines
provided to the administrator to delete
include records related to:
* Mail Receipt Information
* MTS User
* Official
* Plant
* Submitter Abbreviation
* Technical Contact
* Userfee
* Violation
"Scanning
* Submission
* Support Document
The relevant records to be deleted are
specific to each routine.
request type of N
information to be deleted^/
request identification of the
information to be deleted
determine if information is
used by other records
does not impact
other records
\l
/"provide view of information
V to be deleted
X' request confirmation that
y record is to be deleted
\l
impacts other records
inform that record is used by other
records and cannot be deleted
*
f generate and present list
V showing where record is used
225 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Maintain Lookup Table Information
Description: The use case describes the process of maintaining information contained in lookup tables. The
NCS Administrator can make changes as necessary to meet changing requirements. Initially, some CBITS
lookup tables will be transferred to populate lookup tables.
Actors: NCS Administrator
226 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
227 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
: NCS Application Adm
nistrator
Maintain Lookup Table Information l\
T
^reques
V loo
t to maintain >,
kup table J
i
^identify lookup "\
V
table J
^
/specify maintenance^
V option J
view J*
\ add
change
,/" provide inf
1 "V add
^
Dimation on ^\
tions J
f reque
Vsave a
st to ^<
ditions f~
from addition
j
~>( edit ^
'V information J
f request
1
f provide dec sion on "\
V cascading changes J
<
d
chanqes be ^V
aved S~~
jl{ cascade changes
^^
not cascade changes
f provide decis on on proceeding to ~\
V save change without cascading j
A
^-^
MTS
Some lookup table will be migrated l\
from CBITS.
^ display list of lookup tables and "\
V request ident fication of lookup table J
i
-S request "\
V maintenance option J
< request information on "\
addit ons J
< validate information in "N
additions J
no errors ^^x errors
^^
~^f save additions ^\
>(v J
\/
^^^\ ^ ,/provide validation errors "\
^~~~~~-^ v for lookup table J
A
from change
^f retrieve lookup "\
V table information }
^/"validate changes to "\
V information J
-]/
no errors ^^\ errors
^^
,
\ J
~Y provide lookup "\ \j/
"V table information } /^^
i
228 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
illl^IIIIIIII. ^||==^
Obtain Help
Description: The use case describes the process of a providing an MTS user with context sensitive help.
Actors: MTS User
Diagram:
MTS User
Obtain Help AD
Help files have been created and are
available for user interface
1
request help for a particular
screen or field on the screen
review help
V
MTS
else
available
Notify help is
not available
provide help for the screen and
context sensitive help for a field
V
allow user to do other work while
help information is presented
229 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Query Last Sequential Number Used
Description: The use case describes the process of determining the last Document Control Number issued in a
fiscal year for a specific document type.
Actors: NCS Administrator
Diagram:
: NCS Application Administrator
Query Last Sequential Number Used
i
( request to query last
V sequential number used
\l
provide fiscal year and
document type parameters
MTS
Default fiscal year = (current fiscal year -1)
request fiscal year and
document type parameters
validate
parameters
errors
no errors
< report errors with
query parameters
\l
matches found
\l
no matching records
X' report no records were found N
V for given parameters J
\l
report last assigned sequential numbers for
specified fiscal year and document type
\l
230 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
ii . j
Reprint Barcode
Description: The use case describes the process of reprinting a barcode that is unreadable, corrupt, or missing.
Actors: NCS Administrator
Diagram:
Submission Processor
Reprint Barcode
Paper and CD
submissions only
MTS
System Administrator
Submission Processor has requested
handling of invalid/corrupt barcode
request to provide
DCN to reprint
notify invalid
V barcode format
notify Admin that DCN
does not exist
/^reprint barcode^
\/
f record user name, time,
\^ and date of reprint
\l
1
determine that the
barcode is corrupted
\l
f request to \
Vreprint barcodey
231 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
O..n
Plant
PlantID
PlantAddress
SitelDFromFRS
SubmitterAbbreviation
TechnicalContact
Name
Address
Telephones
Emai (Addresses
SubmitterAbbreviation
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
ChemicalName
GenericUse
Specific Use
Maillnformation
BarcodeSanitzedFlag
UserfeeStatus
RelatedDCN
RelatedOriginalDCN
Support DCNs
ConsolidatedFlag
PCNumber
TS Number
PaymentID
JointFlag
CBI
CBICIaim
CBIOther
DCN
SanitizedFlag
SanitizedDCN
BarcodeOriginalFlag
Changes tat usTransact ion
OldStatus
NewStatus
DCN
UserlD
Date
Time
-n-
Userfee
TS Number
PaymentID
CompanyName
FMDScheduleNumber
Status
CaseNumber
UserfeelD
Workload
userlD
StartTime
SubmissionID
ChangesMadeComments
EndTime
Date
LifeCyclePhase
232 Of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
User Administration
Description
Most of the user administration activites are done via ECMS. Users needing access to NCS MTS are added to
ECMS and are provided roles. Based on the assigned roles, the user is granted access to MTS. The user's roles
are determined based on the TSCA Section 5 clearance which is retrieved from CBITS-AXCON system. The
user is not granted NCS access if their clearance has expired.
Overall Process
MTS Administrator
MTS
ECMS
request to capture user
as NCS MTS user
«use (...
Add MTS
User
Capture user as
MTS NCS User
Considerations
3.
MTS user management is performed by ECMS and is outside the boundary of MTS. This means
password change notification, forgotten password activities, and other user account maintenance
operations are handled by the ECMS Administrator and ECMS system, and not MTS.
The EPA user's TSCA clearance is checked before they are added as a NCS user. Since the clearance
can expire and be reinstated, the TSCA clearance status is always checked before a user accesses MTS
system.
The user's role and access to NCS MTS is defined in MTS and is driven via ECMS.
Workflow and Life Cycle Placement
This is the beginning of the life cycle for MTS user. This is where a MTS user is first created. When a MTS
user's clearance expires, they are disabled in CBITS AXCON and are refused access to NCS MTS.
233 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
«System Actor»
CBITS
NCS Application Add MTS User
Administrator
Use Cases and Associated Activity Diagrams
Add MTS User
Description: The use case describes the process of adding an MTS User to the system.
Actors: MTS Administrator
234 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
: NCS Application Administrator
Add MTS User AD
V
request to add a
new MTS user
( provide name N,
V information y
/'provide EPA I
c
\l
[>1 match]
select correct A
user y
provide new user
information including roles
User has requested
to be a MTS user
request for last name, first \
name and middle initial y
/capture name
\ information
\/
( provide user name information
V to look for user in CBITS
' match ]
-^ notify user info does
V not exist in CBITS
determine if user has
active clearance
notify user that
clearance has expired
create MTS user and save
name information, EPA ID
^/provide user clearance
~\ information
J
/^provide clearance information \
~~\on selected usery
235 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
AXCON TSCA 5 Information
CBI Clearance
CBI Clearance Expiration Date
TSCA 5 Clearance
TSCA 5 Clearance Expiration
User fee Management
Description
Perhaps the most complicated process of the PMN processing, pertains to payment for the review of PMN and
SNUN submissions. A PMN or SNUN submission requires a user fee based on submitter and submission
information. A small business must pay $100 for submission processing. For all other submitter types, the
submitter pays $1000 for intermediate PMN or SNUN submissions and $2500 for other PMN or SNUN
submissions. While the submission is sent to EPA OPPT, the payment for the submission is sent to a bank and
information about the submission payment is forward by the bank to EPA's Financial Department. EPA's
Financial Department forwards user fee information to EPA OPPT, who relates each submission with payment
information.
If a PMN or SNUN submission is for a chemical that already exists in EPA's chemical inventory, the
submitter's money is refunded. On inventory determinations are made through the TDTS use cases. Also, if the
submission is incomplete and 90 days elapse without missing information is not provided, the money is also
refunded.
If user fee information does not appear in the submission, the submission review continues until 30 days have
elapsed from the day one date. After that, the submission is declared "incomplete" and the submitter is informed
that their submission has been declared incomplete because the user fee was not received. If the user fee arrives
after 30 days, it is refunded after 90 days provided enough information exists to process the refund.
The submitter is allowed to send payment for more than one submission at a time. However, multiple TS
numbers should be provided in this case. In the absence of multiple TS numbers, there is no way for the user fee
processor to make the correct associations.
In the best circumstances, the submission will arrive with all required user fee information and the user fee will
arrive with all required information so that the user fee can be associated with the submission. In this case, a TS
number and Payment ID is provided with the submission and the user fee arrives with a Payment ID and a TS
number that pertains to payment for just that submission.
236 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Overall Process
1
«use case»
edit userfee
information
^check if TS# and Payment ID has
V been provided in submission
[Yes]
«use case»
Userfee processor
\^ with submission ^
\_ ^ / «usecase»
[ Userfee t nassigned ] (jjj / capture missing
V information
t
Nncomplete userfee ] S «use case» N,
[ < day 90 ] V Information /
[ Else ]
[ else ]
)
)
«use case»
get userfee
information from FMD,
request to edit "\
.userfee information )
^Request to get userfee
V information from FMD
237 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Refund overall process is defined in the following diagram:
System Clock
4=J
V
/request to determined
V refund needed ;J-
MTS
(«use case» X
determine userfee J
refund needed ^/
^
/update status of userfee N
V to "refund needed" y
/update status of userfee to ">
V "refund requested" J
l\
/" «use case» X <-
j process refund )
V request J
\k
/ update status of userfee \
V to "refund applied" J
•
(«use case»N, <-
request J
userfee refund y
Userfee processor
•-^c^jlj^, >(•!)
1
/ approve "refund N
V needed userfee" J
^
/ request to ^
V process refundy
Inventory Administrator
\
1
(request to \
apply refund J
Considerations
There are several scenarios that pertain when the needed user fee information is not provided. Most of these
situations and how they are handled are described below:
1. The submission arrives with incomplete userfee information, i.e., either the TS number or Payment
ID or both are missing and the userfee arrives later - the Prescreener will not allow the submission to
proceed any further unless this information is provided. Both the TS number and Payment ID are legally
required fields for PMN submissions. In the absence of this information, the submission review cannot
proceed. This is a change from the current process. The user fee will be refunded after 90 days if enough
information is provided to process the refund.
2. The submission arrives with a TS number and Payment ID, the userfee does not have TS number
information, but the submitter name and Payment ID match. In this case, the submission processing
continues as the user fee is matched using the Payment ID from the user fee and the submission. MTS
will use the TS number of the submission as the TS number of the user fee.
3. The submission arrives with a TS number and Payment ID, the userfee does not have a Submitter
Name, but the TS number and Payment ID are provided for the userfee. Since the TS number and
Payment ID are not unique for multiple companies, i.e., two submitters may submit a submission with
238 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
the same TS number and Payment ID, the user fee processor will attempt to match submitter names.
Once the submitter name is confirmed, the user fee will be assigned.
4. The submission arrives with complete user fee information, however the user fee never arrives. The
submission goes through prescreening, and the submission status is assigned as "Unpaid". The
submission processing continues while the user fee is checked every day until day 30 of the submission
review. If the user fee still has not arrived, the submission is deemed "incomplete" and it is retired.
5. The user fee is complete and arrives, however the submission never arrives. The user fee will be held
by EPA, unless the company calls and inquires about the user fee. The user fee is held up to 90 days
from its arrival, and if submission still does not arrive the user fee is refunded after 90 days.
6. The user fee is complete and arrives, the submission arrives with user fee information as well, but the
submission fails prescreening for some reason. The submission is deemed incomplete and is retired.
The user fee is refunded after 90 days.
7. The submission arrives with complete user fee information, the user fee arrives 30 days after day 1 of
the review and the submission has been deemed "incomplete." The submission is retired and the user
fee is refunded after 90 days. Even if the user fee information is incomplete, it is made complete with
the information from the submission.
8. The submission and user fee arrive with less money than needed. If the user fee arrives with less
money than necessary, EPA will contact the submitter to request additional money. The submitter will
send additional funds using the same TS number as before. EPA will wait for 30 days after the day one
date to obtain additional funds. If the money is not received by then, the submission will be deemed
incomplete and will be retired. EPA will wait 90 days (from day 1) after deeming a case incomplete
before the user fee received will be refunded.
9. The submission and user fee arrive with more money than needed with a single TS number. If the
user fee arrives with more money than was necessary, the extra money will be refunded.
10. The submission and user fee arrive with more money than needed with multiple TS numbers.
Multiple TS numbers from the user fee information will be matched with the multiple submissions. For
the matched submissions, the user fee will be applied. Remaining money will be refunded.
239 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Following illustration shows the policy and rules for user fee:
1
/'Check submission for\
V payment ID and TS# }
[ Else ] ( check FMD for Payment ID, TS# and ^\
$t Company Name that matches submission^
[ not present'
No Money
to refund
\l
( Deem submission
V incomplete and retire
Not Found
Found 1
while in review, check for
completeness
Not Found
/
FMD for 30 A
n is in review J
[ found ]
\
\
-------
MTS NCS Software Requirements Specification Model Report
days awaiting resubmission, i.e., a new submittion from the submitter. If after 90 days (from Day 1
or receive date) a case has not been resubmitted, the user fee will be refunded.
7. EPA only calls the submitter to find money in the bank to match up with a submission. EPA does not
call the submitter to request the money if it has not been submitted as yet. If the money is not in the
bank at the time of the call, the submission will be deemed incomplete.
8. If a user fee arrives without a TS number, submitter name, and payment ID or any combination of
these, the user fee processor will attempt to match existing submissions with the user fee. This may
involve talking to the submitter representatives to get that information. If the match is made, the user
fee will be applied. Otherwise, the user fee will be kept with the submitter name, if provided, for up
to 90 days and refunded afterwards.
9. If the user fee arrives with more money than was necessary, EPA will expect multiple TS numbers to
be provided with the user fee. If these are not provided, the User Fee Processor will attempt to match
money using the process as outlined in the steps above when the TS number is missing from the user
fee information. If multiple TS numbers are provided, multiple submissions will be associated with
the user fee.
10. The user fee is only charged for PMN and SNUN submissions. In the event a user fee is submitted
for any other document type, the user fee will be refunded after 90 days.
Workflow and Life Cycle Placement
The user fee has several states and the submission has several states pertaining to user fee. When a submission
first arrives, its user fee state is initialized to "unpaid." Once the user fee arrives and is associated with the
submission, the submission's user fee state changes to "paid". If the user fee arrives but the amount provided by
the submitter is less than the amount needed, the status of the submission remains "unpaid". It will remain in
this unpaid state, until a user fee with the same TS number and the amount needed arrives and can be applied.
Once applied, the status of submission will be "paid".
30 days since Day 1 & no or insufficient userfee
Unpaid I after 30 days from Day 1 ( incomplete \ [ Retired
A
Userfee associated completely
> Submission deemed incomplete
V
241 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Since user fee arrival and processing is done separately from submission processing, the user fee itself has
several states. When the user fee arrives, it is checked for TS number, amount, and submitter name. If any one
of these are not provided, the user fee is assigned to be "Incomplete." Otherwise, if all three pieces of
information are provided, the user fee is assigned to be "unassociated." If a matching submission is found (TS
number, submitter name and Payment ID), and if the funds sent matches the funds needed, then the user fee is
associated with the submission, and the user fee state changes to "associated." If the funds sent are more than
what is needed, the user fee status changes to "associated - funds left." Also, if the funds sent are less than what
is needed, the user fee state changes to "associated - insufficient funds." If there is not an exact match with the
amount, there is additional processing involved that can cause the submission to become incomplete and retired
or the user fee to remain in an "unassociated" state. If for some reason, the submission becomes incomplete or if
money has be to returned, the submission user fee state changes to "refund needed." When the user fee
processor approves the refund, the status of user fee changes to "refund requested." The status also changes to
"refund requested" directly if a chemist finds that the chemical in review is on inventory. Once the refund is
applied, the submission state changes to 'refunded."
The following diagram illustrates the various states of the user fee:
TS# and/or Company Name not pro)*
90 days elapsed[ company info not available ]
i# and Company Name Provided
TS# and Company name obtained
[ submission found and amount > needed 1
submission found and amount >= needed 1
associated
- funds left
chemical on inventory
submission found but amount < needed
associated -
insufficient funds
[ 90 days elapsed since userfee arrived ]
90 days elapsed since userfee ari|iv3d[ company info available
90 days elapsed since userfee arrived
242 Of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
Userfee processor
«include»
Process User Fee Refund
v«include»
Determine Userfees to be
Refunded
«include»
System Clock
Validate Identifier
Request userfee refund
Complete Userfee Information Capture Communication Log
«extend»
Get Userfee Information from FMD
Associate Userfee with
Submission
Edit Userfee Information
« System Actor>
Transfer existing userfee
information from CBITS to MTS
243 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases and Associated Activity Diagrams
Associate User Fee Information
Description: This use describes the process of associating a user fee with a submission and determining if the
correct amount of fee was provided. The User Fee Processor reviews information regarding user fees that was
received from FMD. MTS users require user fee information to ensure that a submitter has correctly paid for
submission processing.
Actors: User Fee Processor
244 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Diagram:
Userfee Processor
Associate Userfee with Submission ADl
1
/ request to associate unassociated _\_
V userfee with submission ~/
select userfee
select a submission with ^
.same DCN and Payment ID.,
^ request to determine
V amount for that DCN
[ override ]
[ accept ]
/""request to
y proceed
specify
amount
userfee information presented consists of 1^
TS#, submitter, amount, FMD schedule*,
Check#, Payment ID, Fee received date,
Userfee status
Submission information includes MR#, Submitter,
Mail Receive date, Submission type, submission
status, submission userfee status, TS#, Check#,
Payment ID#, Intermediate Flag, DCN if available
^obtain a list of userfees with "unassociated"
v "associated - insufficient funds" status
obtain a list of all submissions with status of "unpaid" status A
that matches TS# and Payment ID from userfee J
[ else ]
[ match(es) ]
wait for userfee
to arrive
[ else ]
There will be more than one
matches only in the event that one
userfee amount has several TS#s
[ Doc Type = PMN orSNUN ]
''detemine if submission(s) "N
are complete
' change userfee status "N
to "refund requested" J
[ complete
«use case»
process userfee
, refund
for all DCNs with same TS# and
Payment ID, do the following
[ else ]
^ [ none left ] /jjserfee amount = userfee amount - sum of alT
y userfee applied with same PaymentID
[ else ]
[ userfee amount > 0 1
associate DCN with
the userfee
/'assign userfee status to be ^
V "associated-funds left"
create a new userfee with any userfee amount
as leftover userfee amount and without TS#
f based on Intermediate flag and small business
y flag, determine and present amount needed
assign userfee status of new
userfee as "incomplete"
determine if userfee amount
__
""^matches with amount needed ~/
A[ userfee amount = amount needed ]
assign userfee status to be
"associated"
f assign amount applied to be userfee amount or amount
V specified by actor
l [ userfee amount < amount needed ]
/^change status of userfee to "associated - insufficient^
X funds" }
amount > amount needed ]
/'assign amount applied to be userfee amount - amount""
( needed for all userfees with same payment ID
assign submission userfee status to be "paid" and
, userfee status to be "associated"
assign amount applied to be amount specified ^
v by userfee processor or userfee amount J
/^assign submission userfee status to be "paid" and"
V userfee status to be "associated"
245 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Complete User Fee Information
Description: This use describes the processing user fees so that they are ready for association to a submission.
If required information did not arrive with the user fee, the User Fee Processor obtains information by
contacting the submitter. See the Capture Communication Log use case and the Edit User Fee Information
use case.
Actors: User Fee Processor
Diagram:
246 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Complete Userfee Information AD
payment ID is always
provided with the userfee
/"request to review userfee with'X
y a status of "incomplete" J
c
;elect userfee
to process
identify submission if ~X.
possible ^/
I not possible ]
' call submitter and request ^N
^ to capture communication J
In this case, for all submissions and userfees I
that have same payment ID and Submitter,
DCN assignment is made.
[ for each
(check with the company ^\
and provide decision ~J
Three pieces of information are I
critica : TS#, Submitter and
Payment ID. Payment ID is always
present with the userfee.
/^provide a list of userfees with 'N
~y "incomplete" status J
~~p* provide all information "\
y about the userfee J
C
determine if submitter *\
provided ^/
obtain all submissions that
match with Payment ID
capture missing
information
[ provided ]
obtain submission(s) that matches with Submitter and
Payment ID from Userfee with "unpaid" userfee status
[ > 1 submissions found \
assign TS# for
multiple userfees
[ no submissions found ]
issio
JM
[ one submission
T and userfee match ]
^
(find all userfees for the same compan
have "assoc - insufficient funds" st£
V
/^request actor to see if userfee can be a
, v userfee with assoc - insufficient funds
/ that \
itus }
/'provide payment information from ^\
^submission and request to confirm^/
^assign payment information from^
~^ submission to userfee J
assign DCN of
submission to userfee
)
f assign sta us of userfee to "\
V be "unassociated" J
associa e userfee with
submission
«use case»
capture missing
information
\U confirmation ]
"update TS# of "incomplete" userfee with
TS# of "assoc - insufficient tiinds"
update status of assoc - insuffic ent funds" "N
and " ncomplete" userfee to be "associated" J
(assign DCN of the "incomplete" userfee
with DCN of "insufficient funds" userfee
"assign amount needed, amount appli
to be same as userfee amount
lied "\
}
247 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Determine Need to Refund User Fee
Description: This use describes the process of determining whether a submitter's user fee should be refunded.
Actors: User Fee Processor, Inventory Administrator
Diagram:
248 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
System Clock
Determine Userfeestobe C\
Refunded AD
T
/'request to determine userfees toX
V be refunded everyday J
KITS
£ obtain "unpaid" submissions that are complete N, ( determine^ review datejs
1 /v 1
*
/'obtain submissions associated with userfee that \ ^^_ I No ]
V have status "associated - insufficient funds" J ~-~-_^'
\l
/" «use case» \
( Retire Incomplete or 1
V Replaced Document x
i
\i
(collect userfees that have status "associated - amount left" and have ^r '
one TS# associated with one payment ID J
(from State/Activity Models) /
^
(collect userfees that have status "associated - insufficient funds" X
and it has been 90 days from userfee receive date J
(from State/Activity Model 9) /
^
(collect userfees for submissions that were deemed incomplete and have "\
userfee status of "paid" and it has been 90 days from submission rece... J
(from State/Activity Model9) S
1
(collect userfees that have a status of "unassociated" X
and it has been 90 days from userfee receive date J
(from State/Activity Models) /
v
^assign a status of "refund ~\
V needed" for userfee ^/
.
.}
LS
249 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Edit User Fee Information
Description: This use describes the process of viewing and modifying user fee information.
Actors: User Fee Processor
Diagram:
250 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Userfee processor
Edit userfee information AD
Userfee information for
a submission exists
1
request to edit
userfee information
/^provide userfee \
V search criteriay
select one
( modify userfee
V information
MIS
Submitter name, TS Number, F
received date, amount, check#
request for userfee
search criteria
obtain userfees that
match criteria
f request to
V select one
\l
no match '
' else '
one match
\l
obtain userfee information
and present to modify
A
validate
changes
notify error
invalid 1 /• noti1y inva|id
' valid
data
determine if userfee status still valid by
checking new information against submission
\l
status change Kmodi1y userfee
^V status
no status change ]
\l
save changes
251 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Process User Fee Refund
Description: This use describes the process of requesting and processing a refund of a user fee. If EPA
determines that the chemical is already on inventory with CAS, EPA may refund the user fee to the submitter.
Actors: User Fee Processor
Diagram:
252 of 260 3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
MTS
Process Userfee Refund AD
provide list of userfees with
"refund requested" status
provide amount and
allow to edit
else ]
\L
amount provided != userfee amount
notify amount provided is not
equal to amount of userfee
capture amount verified with userfee
as amount refunded
User Fee Processor
V
save refund information for userfee
and set user fee status to "refunded"
report refund
data to FMD
Userfee refund request has been
made. See Request Userfee Refund
request to process
refunds
select userfee to
process refund for
provide new amount,
^ if necessary
A
verify amount
else
[ accept
253 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Query User Fee Status
Description: This use describes the process of reviewing that status of user fees and corresponding
associations.
Actors: User Fee Processor
Diagram:
Userfee processor
Query userfee status AD I
T
( request to review
V userfee status
\l
/^provide criteria^Y
[ else ]
[ generate
report ]
\l
request to generate
userfee report
send report to
FMD
MTS
request to provide criteria
for userfee selection
7
\l
no match
[ match found ]
inform no match found
and to revise criteria
obtain userfee that matches
the criteria with their status
generate report^
254 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Userfee
TS Number
PaymentID
Company Name
FMDScheduleNumber
Status
CaseNumber
DCN
UserfeelD
UserfeeArrivalDate
UserfeeAmount
AmountNeeded
AmountApplied
Submission
CaseNumber
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
Chemical Name
GenericUse
SpecificUse
MailReceiveNumber
BarcodeSanitzedFlag
UserfeeStatus
RelatedDCN
RelatedOriginalDCN
ListOfSupportDCNs
ConsolidatedFlag
PCNumber
TSNumber
PaymentID
UserfeelD
JointFlag
CBI
CBICIaim
CBIOther
DCN
SanitizedFlag
SanitizedDCN
SanitizedStatus
BarcodeOriginalFlag
JointMailReceiveNumber
DaylReviewDate
NumberOfChemicals
RetireCaseStatus
ViolationStatus
255 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Workload Assignment
Description
The concept of workload assigned is designed to enable anyone in the NCS team to select work to perform.
Hence, a user select works, performs the procees, then makes the submission available to others at the end of
the day. Hence, there is shared ownership of work. If the user forgets to logout, the system will automatically
log them out and make the submission available to be worked on by others. However, while someone is
working on a submission, other can view the submission but cannot modify it.
Overall Process
MTS User
MTS
request to work on
a submission
request to
checkin work
provide submission and make
it unavailable to edit by others
V
«use case»
capture workload
information
[ Logout]
[ else ]
V
make work available
to edit by others
256 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Considerations
1. While more than one person can view a submission at any given time, only one person can edit a
submission at a time.
2. There is a concept of shared ownership of a submission, i.e. once a person is done working on a
submission, they will allow others within a team to work on it. If they do not explicitly make the
submission available to others by the end of the day, the system automatically checks in the submission
at midnight. This is due to the time sensitive nature of the submission review process, to ensure that if a
person is unavailable someone else can work on it. In case of system failure, the system will reassign the
work to the person who was working on that submission previously, before the failure happened.
Workflow and Life Cycle Placement
This process of working on a submission and then making it available for others to use is inherent to the
workflow concept. It implies that more than one person can work on a submission in a particular life cycle
phase. In contrast with documents in other EPA systems such as IUR, PMN submissions are very time sensitive.
Hence, submissions are not assigned long term ownership. Whoever is ready and available to work on a
submission can select a submission to work on. At the end of the day or when the user logs out, the submission
is automatically made available to others, so that if the first user is unavailable the work can still proceed. The
work is initially assigned based on role, but there need not be an explicit check in of the submission. At a
predetermined time each day, MTS will automatically make the submission available for anyone to work on.
The submission has two states pertaining to this workflow - available and unavailable. When the submission is
available, anyone can select it to work on. While it is being worked on, no one else can work on it. Other users
can, however, view the submission. At the end of the day, the submission will be automatically made available
if the submission has not already been made available by the user.
work assigned ]
[ Logout, end of the day Or System Failure;
[ workday
257 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases Involved
MTS General
User
Capture Workload Information
Logout MTS
258 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Use Cases and Associated Activity Diagrams
Capture Workload Information
Description: The use case describes the process of selecting a submission to work on for any of the MTS
processes. It describes a self-assignment process where a user assumes workload by selecting a submission to
work on. If the user requests to logout of MTS before completing the process the system will request a status
comment before removing the work assignment. If the user does not request to logout, the system will logout
them out at a predefined time each day and force the removal of the work assignment.
Actors: MTS User
Diagram:
: MTS General User
Capture Workload t^
Information
^
/'request to select submission ^\
V to perform work on J
\l
f select "\
Vsubmission(s)y
: MTS
£ provide list of active submissions ~\
'C based on user's role J
S record assumption of workload ^\
^ information (user name, date, time) J
M/
®
f Documents will be removed from user workload upon user "1
logout or predefined time period each day. See MTS Logout.
259 of 260
3/10/2009 4:33 PM
-------
MTS NCS Software Requirements Specification Model Report
Data Entities Involved
Workload
userlD
Start Time
SubmissionID
ChangesMadeComments
EndTime
Date
LifeCyclePhase
O
Submission
CaselD
Status
CompletenessCheckFlag
CompletenessCheckData
CompletenessCheckUserlD
QACheckPassFlag
SubmitterAbbreviation
PlantID
TechnicalContacts
OfficialAgent
260 of 260
3/10/2009 4:33 PM
------- |