Inside eRA, July 9, 2003 (Volume 4, Issue 8)

CDC and NIH Plan to Use Common eRA System

The Centers for Disease Control (CDC) and the NIH are partnering to consolidate the processing of all CDC research grants under eRA in FY 2004. This collaboration is in concert with the Administration’s emphasis on E-government, the Health and Human Services (HHS) Enterprise Information Technology (IT) Strategic Plan, and Office of Management and Budget (OMB) guidance to “…consolidate internal grants management systems.”

In 2002, about 62 percent of CDC’s $6.7 billion budget––distributed through extramural grants, cooperative agreements, and program contracts––was spent on public health work performed by CDC’s partners. To a lesser degree, CDC funds extramural research through initiatives such as the Prevention Research Centers Program, which supports a prevention research agenda at 24 schools of public health throughout the country.

The CDC currently uses an in-house Grants Management Information System (GMIS) to track the use of funds allocated to specific grants, monitor grantee compliance with grants terms, conditions and regulations, and provide reports for CDC management, HHS and Congress on grants funds allocation. The GMIS application was developed in Natural programming language using the ADABAS database management system. It runs in CDC’s central IBM mainframe environment. As part of its future direction, the CDC Office of Information Resources Management, under the direction of Chief Information Office (CIO) James Seligman, plans to migrate GMIS functionality to a Web-enabled system.

NIH and CDC technical teams, under the respective leadership of Penelope Colbert and Teresa Kinley, have been meeting to gather and analyze requirements. They determined that the NIH eRA system meets 60 percent of CDC’s 300 requirements. Some of the outstanding CDC requirements can be resolved with workarounds and policy changes; however, others will require eRA system-level changes.

Planners propose to phase in the CDC workload, beginning with pre-award processing for research grants in FY2004. Ultimately, the goal is to process CDC research grants for their entire lifecycle under the eRA system.

There will be a two-part pilot for each phase of the consolidation. Testing will begin with a proof of concept using dummy records in the eRA system. The second step will be to conduct end-to-end parallel processing in the eRA and GMIS systems.

Several HHS Operating Divisions (OPDIVs) already use eRA’s IMPAC II grants processing system to varying degrees, reflecting eRA’s flexibility in negotiating partnerships. Agency for Healthcare Quality and Research (AHRQ) grants are received, reviewed and funded through eRA. CDC’s National Institute for Occupational Safety and Health (NIOSH) also uses eRA systems, but has developed workarounds to meet its own business processing needs. Substance Abuse and Mental Health Services Administration (SAMHSA) applications are entered into the eRA database, but are processed elsewhere. eRA recently established a new partnering arrangement with the National Center for Infectious Diseases (NCID). eRA also met with the Food and Drug Administration (FDA) on June 5 to explore teaming. HHS currently is evaluating eRA for department-wide use.

Send questions about the NIH/CDC grants processing integration to Scarlett Gibb.

Grants.gov Pilot Underway This Summer

The first phase of the Grants.gov (formerly E-Grants) pilot begins this July with the primary objective of testing grantee ability to download, fill in and submit SF424 applications electronically. Grants.gov will be the central storefront on the Web for all customers of federal grants to find funding opportunities and to submit applications. Grants.gov also is designed to improve the coordination, quality and efficiency of grant administration operations for both grantors and grantees.

Grants.gov will provide PureEdge™ downloadable electronic grant application forms. PureEdge supports off-line application preparation, including extensive data edit and validation at the user’s desktop and the automated propagation of data among forms. Work-in-progress can be stored and managed on the grantee’s machine. Once complete, the forms and attached files are submitted to Grants.gov.

In the future, all applicants will submit their electronic grant applications (as fillable XML-enabled forms or XML files) to the Grants.gov “trusted broker.” At the Grants.gov site, Northrop Grumman InFlowSuite™ software will authenticate the submitter and enforce role-based security rules, check for viruses, verify data format, send acknowledgement to the customer, and route the application in printable and XML format to the NIH or appropriate agency. The agency then will review the grant proposal and consider it for funding. Throughout the planning and development, eRA has been working with the Grants.gov team to ensure that the new grant submission process meshes seamlessly with the eRA Commons.

The July release will pilot test the submission of SF424 “core” data elements and attachments. The second phase of the pilot will include “non-core” (research and agency-specific) data elements such as those on the PHS 398 used by the NIH. eRA has participated in Grants.gov planning and will take part in both phases of the pilot. In July, eRA will work with Grants.gov to test the download of electronic applications from the Grants.gov site. These will be test applications in the “core” format. During the summer, the NIH electronic Competitive Grants Application Process (CGAP) project will continue working with Grants.gov to prepare for a limited live pilot in the October-November timeframe based on the full set of core and non-core data for the PHS 398 application.

For more information, visit the Grants.gov Web site. Contact Jean-Jacques Maurer for eRA-specific details.

eRA to Begin Five-Phase IRDB Redesign

eRA is completing cost estimates for a five-phase initiative to redesign its IMPAC II Reporting Database (IRDB). There will continue to be two eRA databases: an On-Line Transaction Processing (OLTP) database to support business operations functions; and an IRDB for querying, reporting and decision support. The content, structure and method of loading the IRDB will change to improve overall system performance and usefulness.

The original architectural approach of having two separate databases (transaction and reporting) still is valid. Separating reporting from transactions reduces the traffic to the OLTP, enables each database to be tuned according to its purpose, supports security delineation for data access, and establishes a repository for archived records. Nevertheless, in spite of the benefits of separating reporting and transactions, the IRDB as currently implemented has several inadequacies. As a result, many ICs download data from the OLTP to local file servers for processing by IC systems, which can have a negative impact on OLTP performance.

The purpose of the IRDB redesign is to satisfy user-reporting requirements for data that is complete, accurate, and timely. eRA plans to accomplish these objectives using a five-step plan:

1. Replicate selected tables required by existing OLTP and IRDB users. 
2. Design and build a new IRDB structure and acquire an Extract/Transform/Load (ETL) product to populate it. 
3. Migrate users to the new IRDB structure. Eliminate the old IRDB bridge. 
4. Migrate users from replicated OLTP tables to the new IRDB structure. Promote replacement of individual IC applications with the enterprise solution. 
5. Retire replicated OLTP tables when feasible.

eRA will issue a project schedule in the near future. Address questions about the redesign to Pete Morton or Carol S. Martin, eRA advocates for the IRDB.

eRA Reconsiders Its Vision in Light of New Requirements

Dr. John McGowan, eRA Project Manager, called for a re-evaluation of the eRA vision to ensure that the project remains in synch with federal and departmental policy, current technology, budget realities, and emerging user requirements, especially for new e-tools. Widening the scope of eRA’s vision is likely to have an impact on priorities and affect plans and schedules. Dr. McGowan urged eRA advocates and their business communities to set reasonable expectations regarding the timeframe for change.

eRA’s original vision statement was formulated in FY 2000 and contains the following goals:

• Achieve end-to-end electronic research grants administration and reporting.    
• Recommend strategies for re-engineering grants management business processes to increase efficiency.    
• Electronically link the external grantee community with NIH staff and establish one common database.    
• Enable business processing in aggregate mode instead of on a grant-by-grant basis.

Over the past two years, multiple forces have begun driving the modification of the eRA vision. They include:

• The desire among NIH Institutes and Centers (ICs) to retire their extension systems when eRA is able to satisfy their processing requirements.    
• The requirement to build enterprise reporting tools.    
• The need for better data quality and security.    
• The potential use of eRA as the common system for processing research grants or all grants throughout the Department of Health and Human Services (DHHS). See article in this issue. 
• The migration of legacy data from all DHHS Operational Divisions (OPDIVs) to the eRA system.    
• The incorporation of HHS OPDIV requirements into the eRA system.

In addition to these forces, specific new business requirements have emerged for:

• Integration of a Scientific Management System (SIMS) to enable technology staff to track every stage of an initiative from concept development through implementation.    
• Creation of a document generator for Program Announcements (PAs) and Requests for Applications (RFAs) to standardize language across OPDIVs for the announcement of initiatives in the NIH Guide.    
• Links between NIH Guide announcements and grants records in the eRA system.    
• Integration of the assurance process for animal and human protection into eRA.    
• Enterprise budget and finance reports to simplify and standardize reporting across the NIH.    
• Reconciliation and data reporting between eRA and financial systems.    
• Development of a flexible workflow design for all ICs.    
• Development of a Council Operations module to support the Council Operations phase of the grants lifecycle and link the business processes of program, grants management and budget.    
• Integration of an electronic Contract Management System (eCMS) to support the administration of research and development contracts.    
• Incorporation of knowledge discovery and business intelligence tools.    
• Development of an enterprise-wide coding system to map individual IC codes into common elements for system-wide reporting and trend analysis.    
• Development of a system and common electronic interface for the reporting of adverse events.    
• Other requirements related to the Clinical Road Map effort.

Contact John McGowan to provide input regarding the eRA vision.

Web QT Pilot Begins in August

eRA will deploy Web Query Tool (Web QT) in pilot mode on August 1. Web QT will provide search parameters and data viewing, printing and exporting options already familiar to the NIH extramural community. Ultimately, Web QT will replace the existing Oracle Forms-based QuickView (QV) and IC Search Track Order Report (ICSTORe) applications as the generic eRA information retrieval tool. Support for business-area-specific queries will remain in the corresponding business area modules.

Web QT Capabilities -- Web QT pilot users will be able to:

• Run queries using user-defined search parameters.   
• Print hit list results.   
• Export hit list results to Microsoft Excel.   
• Create zip files containing selected documents (e.g., abstracts, summary statements).   
• Merge selected documents into one PDF file for viewing.   
• View/print the Grant Snapshot report.   
• Access the Grant Folder and view/print its contents.

Pilot Objectives -- eRA will incorporate user feedback from the August pilot into the general release slated for the fall 2003. Community participation will enable eRA to create an easy-to-use application that includes functions and features desired by end users. To achieve this goal, eRA is seeking answers to the following questions:

• Querying 
  • What additional search parameters are needed? 
  • What additional “hit list” data items are needed?
•  Ease of Use 
  • What parts of Web QT do you find the most difficult to use or understand and why? 
  • What parts of Web QT do you find the easiest to use? 
  • What would you do to make Web QT more intuitive? 
• Performance 
  • How do you rate the overall query performance of Web QT? 
  • Which queries have the slowest response time?
• General
  • Did you find the on-line user’s manual helpful in answering your questions?   
  • Did you find the content and layout of the user’s manual sufficient for your needs?

During the pilot, users should send comments to the eRA Helpdesk. If you would like to participate in the Web QT pilot, contact Sherry Zucker.

New Load Balancer Handles Incoming Commons Traffic

eRA Operations, in collaboration with the Center for Information Technology (CIT), successfully deployed a UNIX-based BIG-IP^® load balancer on June 6 to direct requests from external users. This enhancement will ensure good performance and consistent availability for the steadily growing number of eRA Commons users who will access new Commons applications. eRA plans to introduce load balancing for internal NIH staff at a later time.

A load balancer is a server that receives incoming traffic and intelligently routes requests to the least busy computer. To the outside world, it appears that a single server handles the work, but in reality, several machines in the background may be performing the processing. Initially, eRA will have one UNIX-based BIG-IP^® load balancer on the front end directing traffic to two servers that will process the requests. eRA also will have a second load balancer for full failover capability. These load balancers will be configured in an active-passive architecture where the active server will receive all incoming requests. If, for any reason, the active server fails, the passive server takes over the responsibility for load balancing. eRA plans to install additional application servers as the eRA Commons workload increases.

eRA also deployed the Secure Sockets Layer (SSL) acceleration feature of the BIG-IP load balancer. The server has a built-in SSL accelerator that is used to generate encryption keys for secure Web transactions. The process of encryption can severely overload a J2EE application server computer resulting in fewer transactions per second. The SSL accelerator in the load balancer takes over this process, reducing the load on the J2EE application server.

Direct questions about load balancing to Stephen Hughes, chief, eRA Architecture Branch.

New Release of Review to Include Export-to-Excel Feature

Users of the Peer Review module will be able to export four standard reports to Microsoft Excel after the August deployment. These reports include Administrative Data, Assignments–Master Copy, Voter Matrix and Composite Score. The new download option will appear on the Reports menu.

The ability to store report results in Excel has long been a priority of the Review Users Group (RUG), led by eRA Advocate Dr. Eileen Bradley. Using Excel functionality, users now will be able manipulate, sort and modify data as needed for multi-project applications. They also can create customized reports by removing, reordering and adding columns.

Initially, eRA planned to satisfy the RUG requirements by implementing Discoverer, an Oracle tool for ad hoc queries and reports. When budget constraints held up the Discoverer initiative, eRA decided to build the export-to-Excel capability, which was more cost effective. In the future, eRA will expand the number of Review reports that can be downloaded. RUG requested this capability for the following reports: Roster/Administration/Mailing/Summary Statement, Program Officials, Unique Institutions, Project Personnel, Competency Roster, Agenda, and Summary Statement Status and Dates.

Review Analyst Tracy Soto acknowledges the contribution of the Excel Reports Focus Group, who reviewed and evaluated the prototypes. Eileen Bradley, Bonnie Ellis, Phoung Pham, Brian Wojcik, Tracey David, Kathy Dinterman, Melissa Stock, Diane Lawson, Bobbie David, Thomas Tatham and Valerie Prenger participated in the focus group along with developers Daniel Fox and Lev Zeldin.

eRA and NINDS Build NIH Type 5 e-Notification System

eRA is partnering with the National Institute of Neurological Disorders and Stroke (NINDS) to develop an NIH electronic notification system for Non-competing Continuation (Type 5) progress reports. This “push” notification is intended to remind Principal Investigators about upcoming due dates and late applications.

In the past, Type 5 grant kits were printed and mailed to grantees. Beginning in August 2002, NIH ceased mailing hardcopy reminders (see NIH Guide Notice NOT-OD-02-066) and created a Web site at http://era.nih.gov/userreports/pr_due.cfm for users to check progress reports due. When the new “pull” method proved inadequate, several ICs created their own notification systems to deal with the increased number of late submissions. As a result, grantees began receiving notices with different language and formats.

NINDS has developed an e-notification system, which it has shared with other ICs. NINDS has agreed to turn over its software to eRA for centralized and standardized administration. eRA already has used modified NINDS code to issue about 700 late notifications to grantees. Blind copies also were sent to each corresponding IC.

In the future, eRA intends to combine Type 5 e-notification into a comprehensive e-Notification system that will issue all notices to grantees. For more information, contact Tim Twomey or Michael Loewe.

eRA and NCI Schedule CM Web Training

The Committee Management (CM) development team, in collaboration with the eRA Communications and Outreach Branch (COB) and the User Services Branch (USB), has scheduled CM Web training this month. These classes will prepare CM staff to use the new Web interface, which will become available to the entire community on August 1. This release will include meeting and roster functionality. (See article in May 30 issue for details.)

To register for one of the classes below, email the eRA HelpDesk or call 301-402-7469 or toll-free 1-866-504-9552. For more information or reasonable accommodation, contact Patty Austin at patty.austin@nih.gov or 301-435-0690, x617.

The National Cancer Institute (NCI) also will offer CM Web training for its staff on July 11, 18 and 23. Interested NCI personnel should contact Kerry Peasland.

Visit http://impacii.nih.gov/applications/apps_cm_web.cfm for CM Web user manuals and release notes. Contact Patty Austin or Krishna Collie if you have questions.

August 1 Deployment Highlights

electronic Simplified Non-competing Application Process (eSNAP)

• Users will be able to submit Population Tracking Inclusion Enrollment reports.     
• Users will be able to enter a Signing Official (SO) as the Administrative Official (AO) on the face page of the eSNAP without having to create an AO role for the SO.     
• Users will be able to indicate that an individual page has been completed; the status of the page will be shown on the Manage eSNAP screen.

eRA Commons

• A new tool will be available for NIH validation of the historical data associated with an IAR/PI Commons account request.     
• The PI will be able to include additional NIH support to an account that is attached to another profile.

Grants Closeout Module (GCM)

• The module will be tuned for improved system performance.     
• The Closeout specialist and central IC email address (where summary statements currently are sent) will be copied on all emails. “Closeout” will be included in the email subject to enable staff to create Outlook forwarding rules.      
• Users will be able to search for an individual grant by serial number and mark it as pending or unfunded.      
• The council meeting date will be added to the Check Pending List      
• Users will be able to sort on any column of the Pending List, My Closeout, Show All, and FRC Report.     
• Three new data elements will be added: destroyed date, whether or not the Program Official received the final progress report, and whether the report is acceptable.

Grants Management (GM)

• Notices of Grant Awards will include Budget and Project Period Start and End dates for Fellowships after activation.     
• The wording of edit check result messages will be modified according to the recommendations of a user working group.     
• Users will be able to access the Subproject Maintenance Screen from GM.     
• The document number for Type 9 grants will be in the new format with the last character always equal to ‘A’. The business rule that validates the award document number will be modified to validate this new format.

IC Search Track Order Report (ICSTORe)

• Users will be able to query for and display Loan Repayment Program (LRP) applications.     
• Subprojects will be added to "Add Additional Grants" functionality.

Institute and Center Operations (ICO)

• Users will be able to “advance” the council date for an application from the October round to the preceding August or May round.     
• Loan Repayment Program (LRP) applications now will be included in the GUM hit list.     
• ICs will be able to require population tracking of any application with a human subjects exemption of E4 by setting the tracking exception code to "00."

Internet Assisted Review (IAR)

• The August release moves IAR into production. All SRAs and GTAs with an IMPAC II account will be able to use IAR.     
• A calendar on the Edit Dates screen will enable the user to choose a date from the calendar instead of typing it in.     
• A meeting-wide option for including reviewer names in the preliminary summary statement body will be available. Users can choose to include or omit reviewer names.     
• The grant application number will be a hyperlink for viewing the grant image.     
• If users submit or delete a critique for an application and then click back to the list of applications, they will return to the same application instead of the top of the list.     
• The ability to zip all preliminary summary statements into one zip file will be available.      
• The ability to view a critique on the Submit Successful screen will be added.      
• The option to view all meeting critiques (in Adobe PDF format) sorted by PI name will be available.

Peer Review

• Four reports will be available for output in MS Excel format: Assignments – Master Copy (landscape), Administrative Data, Composite Score, and Voter Matrix.     
• RFA/PA will be added to the IRG/SRG Reassignment hit list report.     
• SRA remarks will be added to the Assign Reviewers and IRG/SRG Reassignment screens.     
• Line 5 will be removed from addresses; the city, state, and zip code fields will be used to build the last line of the address.

Person Addresses

• Will convert address line 5 data where possible to city, state, and zip.     
• Will modify IMPAC II so that users will be forced to move data out of line 5 and into other lines of the address when they edit the address.     
• Will integrate the U.S. Postal Service database for city, state, and zip code into IMPAC II.

Person Degrees

• Will implement a  "trimmed down” list of degree codes for entry of degree information about a person.     
• Will provide the ability to enter less-common degrees in free-text fields, while still capturing degree categories for reporting purposes.     
• Will add a new list of degree categories that increases reporting granularity for degrees, while still maintaining the grouping of “highest” degrees.     
• Will improve the quality of information in IMPAC II relating to earned-degree information.     
• Will eliminate most duplicate degree information from the database and add restrictions to reduce the creation of new duplicates.

Population Tracking (Pop Tracking)

• Pop Tracking will be integrated with the eRA Commons eSNAP module.     
• Phase 3 Checklist will be available through the Application Program Interface (API). 

Program Class Code (PCC) Application Program Interface (API)

• Will implement wildcard capability in the PCC validation table to replace pattern-matching logic that currently is embedded in the business rules.     
• Will modify ICO's PCC Definition screen to remind users of the wildcard options. Also will add relevant help text to this screen.     
• Will replace current PCC validation table values with equivalent wildcard patterns. 

Program Module (PGM)

• Will separate portfolio pages for Pending Type 5's and Post Award/Active grants.     
• Will add ability to include/exclude grants not assigned to a PO for tracking/interest purposes.     
• Will enhance filtering of a portfolio list by FY, Council, PCC, and Subprojects.     
• Attention Flag column in each portfolio page will show concerns on a grant.     
• Will add ability to override the system-defined sort with user’s sort preference on each portfolio page.     
• Will integrate with new shared eRA modules: eRA Program Checklists and eRA Web QT.     
• Will add ability to view historical PO notes on each grant in a PO's portfolio.     
• Will add Signed/Unsigned column to indicate whether PO approval is complete     
• Will include new portfolio page for withdrawn grants.     
• Will add ability to expand/collapse sections of the eRA Grant Snapshot for printing.

Receipt and Referral Maintenance

• Will provide the ability to select the column on which to sort on the View Application Status screen.     
• Will implement changes to correspond to degree and address restructuring.     
• Will correct processing for setting Program Class Codes, for including Award Document Numbers, and for displaying review-meeting associations for reinstated applications.     
• Will modify mailer processing to suppress change mailers when only the group extension code has changed.

Subprojects

• Will reconcile subproject API business rules with those enforced on the Subproject screen.     
• Rollover will occur sooner when the subproject information is drawn from a noncompeting continuation award.     
• Subproject "total cost" business rules will be revised to account for supplemental award amounts.     
• Subproject API will be extended to allow upload of IC-assigned project terms.     
• Consistency of human-subject coding will be enforced among subprojects and parent applications. A subproject cannot be flagged with human subjects if no human subject involvement is indicated on the parent award. Conversely, users will receive a warning if the parent award indicates human subject involvement but none of the subprojects carries this indication.     
• Consistency of animal subject coding also will be enforced among subprojects and parent applications. A subproject cannot be indicated with animal subjects if no animal subject involvement is indicated on the parent award.     
• Overnight CRISP rollover processing will be retired. Rollover will be driven by system events.     
• Will fix bug that allows users without ICO_GRANT_UPDATE_ROLE to maintain subprojects via the Subproject screen.     
• Leaving the human-subject checkbox unchecked will result in human subject code “10” (instead of NULL).     
• Subproject screen will allow population tracking subprojects to be marked "awarded" and "IC approved."     
• Subproject screen will invoke newer version of the Edit Check module, with results for entire set of subprojects presented in one consolidated display.     
• Application Affiliation records will be created in the database to track the relationship between subprojects and their parent applications.