ML18199A235
| ML18199A235 | |
| Person / Time | |
|---|---|
| Issue date: | 09/05/2019 |
| From: | Patricia Vokoun NRC/NRO/DLSE/LB3 |
| To: | |
| Vokoun P / 3470 | |
| Shared Package | |
| ML18199A232 | List: |
| References | |
| LIC-115 | |
| Download: ML18199A235 (3) | |
Text
Revision 2 Office of New Reactors Summer 2018 Do you need to write an RAI?
When insufficient information has been docketed, such that the staff is unable to reach a reasonable assurance determination related to a licensing application or amendment, the staff member should compose an RAI.
To assess whether sufficient information has been docketed, adequate alternatives should be considered, such as discussions with fellow reviewers and supervisors, public meetings, focused audits, or e-mail correspondence from the Project Manager to the entity. This is especially true when addressing complex or detailed subject areas where issuing an RAI as a first step may not be as efficient in resolving staff concerns.
Six Qualities for RAIs:
Necessity-RAIs are necessary when the information being requested is (1) not available through another docketed source and (2) technically relevant to the discussion and conclusions in the safety evaluation.
Regulatory Basis-The regulatory basis and underlying relevant guidance should be clearly stated in the body of the RAI.
Clarity-Ensure that the RAI states what information is required or what information has been omitted or presented in an unclear fashion and the context surrounding it so that the applicant can fully respond to the issue.
Conciseness-Ensure the RAI is succinct.
Comprehensiveness-Ensure the RAI asks the entire question. Is there other relevant subject matter or topical material related to the RAI that must also be considered?
Significance-Ensure the information requested in the RAI clearly documents the safety, security, risk, or environmental significance of the issue with respect to the licensing acceptance criteria that must be met to provide a reasonable assurance determination.
Request for Additional Information Job Aid Things to Avoid
Do not use the term requirement when asking for information related to guidance contained in the SRP or Regulatory Guides (RG).
Only regulations and orders are requirements. The SRP and RGs are guidance and the applicant may propose an alternate means to meet regulations.
RAIs should not make determinations on the adequacy of the application. Staff evaluations/conclusions belong in the SER.
Do not provide the answer to your RAIs. However, explanatory examples of the kind of information you need may be included to provide context for the RAI.
Do not request reports. Rather, request relevant, specific information from reports or a summary report, as appropriate.
Do not phrase the RAI in a way that could be answered with a yes or no answer.
The use of subquestions within an RAI is discouraged.
Do not put SGI, SUNSI, CEII, or ECI in eRAI.
Best Practices Offer a converse or contrarian statement to clearly point out what information is missing from the specific portion of the text provided by the entity to assist both the reviewers and the entity in determining what specific information is being requested.
Review the regulations statements of consideration, as necessary, to ensure that the application of the regulation(s) is consistent with the Commissions intended interpretation.
For follow-up questions, describe the preceding question at the start of the new question. Then discuss how the preceding response answered part of the question, but did not resolve the part you are again asking about and enter the preceding RAI and question number in the relates to question field in eRAI.
For Multiple Question RAIs follow these points:
o If the regulatory basis is the same for all questions in the RAI, it is acceptable to only include the regulatory basis at the start of the first question and state that it applies to all questions in the RAI o
Each question must meet the Six Qualities for RAIs (except for regulatory basis) o Each question should provide enough information that it does not require referencing another question within the RAI (except for regulatory basis).
Simply state the facts. Take emotion out of the question.
Always spell out acronyms the first time they are used in an RAI.
Part 50/52 Review Process Information
NRO will continue to use the eRAI workflow accessed through EPM/SharePoint for processing RAIs regarding licensing application submitted under Parts 50 or 52. The eRAI Workflow uses Questions, which are transmitted in RAI letters.
Use statements to identify your information needs.
For COLA reviews, RAIs related to concerns you may have about the DC should be asked in the ongoing DC review.
Note that certified designs have design finality and can only be changed under the provisions of 10 CFR 52.63.
Any follow-up RAIs should identify the original RAI within the text, identify what additional information is needed and use the relates to question field in eRAI.
Do not request that report(s) be provided in a response to an RAI, rather request specific information within a report or a summary of the report(s).
Abbreviations BC - Branch Chief RG - Regulatory Guide COLA - Combined License Application SGI - Safeguards Information SRP - Standard Review Plan CEII - Critical Electrical Infrastructure Information SUNSI - Sensitive Unclassified Non-Safeguards Information FSAR - Final Safety Analysis Report LBC - Licensing Branch Chief TBC - Technical Branch Chief TBR - Technical Branch OGC - Office of General Counsel Reviewer RAI - Request for Additional Information TDM - Technical Division Management RAI Quality Control Checklist:
To ensure that an RAI is of sufficient quality, confirm that the RAI has the following attributes:
The regulatory basis is clearly stated at the beginning of the RAI.
If applicable, relevant guidance document(s) are provided that help clarify the information being requested (e.g., SRPs, etc.)
The RAI clearly identifies the location of the issue in the document being reviewed (e.g., FSAR Section X.Y).
The RAI clearly explains why the information provided does not meet the requirements cited in the regulatory basis
The RAI clearly specifies potential impacts of the missing information (such as the safety, security, risk, or environmental significance of the question).
The RAI clearly specifies the specific information being requested from the applicant or licensee to support the reasonable assurance determination.
Additional considerations for Branch Chief Reivew:
Ensure that the context of the RAI has a clear logical basis, information sought is provided in plain and all acronyms are defined.
Confirm that the RAI is objective, factual and written for an audience of suitably qualified safety and environmental reviewers.
Determine if any questions are duplicative of other questions generated by the branch
Determine if coordination with other technical Branches is needed.
Ensure the RAI uses the appropriate format for multiple or follow-up questions.
Additional considerations for Technical Division Manager Review:
Determine if RAI could potentially introduce new policy issues and coordinate issuance with Office management as necessary.
Determine if question has been consistently addressed across all projects as appropriate.
Determine if Office or other Division level alignment is needed prior to issuance.
Confirm that the scope and level of detail of questions across technical Branches in the Division are appropriately uniform, given consideration of the relative importance of technical topics and unique aspects of the design.
Where can you find more information?
Talk to your Branch Chief or a senior technical reviewer
NRO-REG-101 Revision 2, Processing Requests for Addtional Information (ML14091A802)
eRAI guidance documents - eRAI Guidance Documents
Quality RAI Examples (ML18199A234)
NRO RAI Audit Report (ML18096B419)
Memo from NRO Office Director on the effective use of RAIs (ML18110A398)