Inside eRA, May 30, 2003 (Volume 4, Issue 7)

Visit eRA’s New Virtual School on the Web

Visit eRA’s new virtual school on the Web at http://era.nih.gov/virtualschool/ to try the Financial Status Report (FSR) tutorial, the first of many planned Web-based classes for NIH staff and grantees. eRA’s goal is to offer instruction to all users anywhere, at any time. The only requirement is access to the Internet. According to Patty Austin, “principal” of the virtual school, the Web-based tutorials will serve both as alternatives and supplements to on-the-job training and formal classroom instruction. 

The underlying technology for the virtual school is RoboDemo^® software, which enables the creation of animated, interactive simulations of user applications. RoboDemo records the instructional demonstration, including mouse clicks and keystrokes, as a high-resolution, compressed movie. Training staff can enhance the movie with text annotations, audio effects, and images; users are able to participate interactively through click boxes and text-entry fields.

This calendar year, the eRA Communications and Outreach Branch (COB) plans to offer tutorials for key eRA Commons applications: iEdison, Internet Assisted Review, Status, and possibly eSNAP including Population Tracking. Classes for internal staff also will be added, starting with Committee and Grants Management, closely followed by the Review and Program modules. Future upgrades are planned. For example, next year, the tutorials will be enhanced with voice overs.

Training Scheduled for CM Web

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 during June and July. These classes will prepare CM staff to use the new Web interface, which will become available to the entire community this summer.

The CM Web pilot now is in full swing, as participants from nine ICs use the new software to perform meeting and roster transactions. For more than a year, CM representatives have been working closely with eRA technical staff to redesign the CM client-server application from the ground up in a Java 2 Enterprise Edition (J2EE) Web environment.

According to Anna Snouffer, eRA advocate for CM, the pilot is going very well. “CM Web has incorporated a number of new features that CM users really needed and wanted… Every day, more CM users request to be a part of the pilot.” Developers have met with the pilot group on a monthly basis to receive constructive feedback and suggestions for enhancement. As a result of user input, the new application has improved screen layout and usability, robust querying capabilities, logical grouping of functions, and accessibility from home or wherever the user can connect to the Internet.

The first production release of CM Web will support meeting and roster functionality, including meeting and roster maintenance and five reports: Committee Roster, Meeting Roster, NIH-1715, Mailing Labels and Invitation to Travel Reports. All other CM transactions (i.e., Committee Administration, Federal Register Notices, Nomination Slates, Vouchers, OFM Uploads and Check Register) need to be performed using the client-server version. The CM Web module will run in parallel with the CM client-server application until all functionality is supported by the new Web version.

The CM technical team, COB and USB have been working together to provide a comprehensive training program for the community. In addition to the classroom instruction posted below, an online class will be available in eRA’s Virtual School. There also will be user manuals and quick-reference guides. Patty Austin, eRA training program administrator, expressed her gratitude to Krishna Collie, eRA analyst, for his assistance with preparing the CM training materials.

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.

New Role for PGM, Checklists and ICO

The July 2003 release of the new Program (PGM) and Checklists modules and the Institute and Center Operations (ICO) module will include a separate, new role for Program Analysts/Assistants. This role will permit Program Analysts/Assistants to assist Program Officials by preparing required pre-award checklists, draft Program Official (PO) notes, and sign-notes, but will not permit sign-offs (approvals). Only individuals granted the Program Official role by their IC can sign-off (approve) that scientific and programmatic requirements have been met and that the notes are satisfactory.

The current PGM and ICO modules support only the Program Official role. The creation of the limited Program Analyst/Assistant role is eRA’s accommodation to user requirements. Several ICs and POs have expressed their reluctance to use the ICO module because of their inability to restrict approval authority to Program Officials. Many ICs have Program Analysts or Program Assistants that assist Program Officials but do not have approval authority. The differentiation of the Program support role from the Program Official role (as a result of Office of Management and Budget (OMB) Circular A-76) also has highlighted the need for a separate role for Program support staff.

After the July release, ICs and POs can assign individuals to either the Program Official or Program Analyst/Assistant role using the eRA user Administration module. The name of this role will be announced prior to the deployment. A future release of the PGM module will allow an IC to limit approval on a grant to designated Program Officials, Branch Chiefs, or others with the PO role.

AHRQ Conducts Survey on eRA Extension Systems

The Agency for Healthcare Research and Quality (AHRQ), a current user of the eRA system, is conducting a survey of NIH Institutes and Centers (ICs) to gather information about their grant-processing extension systems (also known as shadow systems). Robert Borotkanics (AHRQ) and Nathan Faut (Xcalibur Software) made a presentation to the eRA Project Team on May 13 to explain the purpose of their fact-finding endeavor.

AHRQ, the Health and Human Services (HHS) division that focuses on improving access to quality medical care, migrated to IMPAC II after using the mainframe IMPAC I system. On a nightly basis, AHRQ downloads its grants information from the eRA database into its AHRQ-specific GIAnT shadow system. AHRQ decided to look at other IC systems because both IMPAC II and GIAnT fail to satisfy all AHRQ requirements. The agency also is interested in learning how to keep their system in synch with changes to eRA. 

Specifically, AHRQ is seeking a system that supports grants portfolio management, uploading of non-CSR-cleared grants, tracking of matching funds, generation of funding recommendation documents, intramural grants tracking and free-text search. Another objective of the survey is to canvas the ICs about their current and future requirements. 

AHRQ intends to make its survey results available to the NIH so that ICs can pool and share their extension system knowledge. In the past, eRA has benefited from modules built by other ICs including NIMH’s grants closeout system and NIAID’s Internet assisted review.

eRA Staff and CWG Met to Discuss Project Progress

Representatives from 16 grantee institutions met with eRA staff to discuss the progress of the eRA Commons 2 deployment, the development of an electronic competitive grant application, and other eRA plans for the future at the April 30 meeting of the Commons Working Group (CWG) in Washington, D.C. For more than two years, the CWG has played a critical role in shaping, evaluating and fine-tuning the new eRA interface to the extramural NIH grantee community.

Highlights of Agenda

• eRA Commons Deployment Update

Dan Hall, eRA Commons lead analyst, provided up-to-date statistics on the growth of eRA Commons registration and usage: 6,500 accounts created, 84 eSNAPS and 1,900 FSRs submitted, 230 reviewers using IAR. Dan also summarized the accomplishments of the March software release, including improvements to eSNAP and FSR, a new eRA Commons demo/training facility, merger of the IMPAC II and eRA Commons databases, and the addition of “Other Relevant Documents” to the Project Detail screen.

• CGAP/E-Grants News

JJ Maurer, lead eRA analyst for the electronic Competitive Grant Application Process (CGAP) initiative, reported that the project team now is fully staffed and expects to proceed on schedule. CGAP documentation is available to the public on the eRA website at http://era.nih.gov/Projectmgmt/SBIR/. eRA continues to coordinate its efforts closely with the federal E-Grants initiative.

• eSNAP Pilot Discussion

The general consensus was that overall the electronic Simplified Non-competing Application Process (eSNAP) system is working well. Several of the issues raised by pilot testers were resolved. The CWG suggested that the pilot group be expanded to allow more institutions to provide feedback.

• FSR Module Discussion

Most thought the system was working adequately and did not need any major changes. It was noted that the government plans to adopt a common financial reporting form. As a result, there will not be any significant changes to the FSR system until the new form is issued.

• eRA Project Status Update

Dr. John McGowan, eRA project manager, announced that the NIH IT Board of Governors had approved an eRA budget increase of $6.56 million for FY 2003. He also informed the CWG that the installation of hardware for load balancing and the recompetition of the primary development contract may impact the deployment schedule for July and October.

• Future eRA Direction

Dan Hall led a discussion of possibilities for how the representation of institutional hierarchies and approval could be implemented in future eRA Commons versions. The CWG was asked to provide feedback to assist with the establishment of a “best-practices” set of requirements.

• Experience of Institutions in Implementing the eRA Commons

Several CWG members, who have experience in implementing eRA Commons, said they would share documentation they have developed to aid in this effort and offered to send these materials to the CWG mailing list.

New Load Balancer to Direct Incoming eRA Commons Traffic

eRA plans to implement load-balancing technology this June to ensure good performance and consistent availability for eRA Commons users. Many eRA Commons applications are scaling up in usage. Specifically, Internet Assisted Review (IAR) and electronic Simplified Non-competing Application Process (eSNAP) will be moving from pilot to production mode this summer. eRA Commons registration also has been growing steadily. Approximately 400 institutions and 3,000 grantees already have enrolled.

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 all incoming requests will be received by the active server. 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 will take advantage of 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.

During eRA’s installation of the new load-balancing technology, there were initial delays during setup and configuration. Later, troubleshooting and research resulted in discovery of a bug with the load-balancing software. The vendor has issued a fix, and although the setback resulted in some delay, the initiative is back on schedule. At the present time, eRA technicians are testing the system using software that mimics multiple users accessing the system. By early June, they expect to implement load balancing for eRA Commons users. eRA plans to introduce load balancing for internal NIH staff at a later time.

To ensure that eRA will be able to handle the steadily increasing eRA Commons workload, load balancing must be implemented before existing modules are enhanced. As a consequence, the planned summer application deployment (currently scheduled for late July or early August) is contingent on load-balancer implementation by early June. eRA will notify the user community if the schedule changes.

eRA Studies NIAID CAAP System

eRA is studying the National Institute of Allergy and Infectious Diseases (NIAID) Council Action and Approval Program (CAAP) as part of its quest to enable end-to-end electronic research administration. The eRA system currently does not support the Council Operations phase of the grant lifecycle, which includes IC Advisory Board/Council meetings, generation of the ranking list, selection of grants for funding, creation of the funding authorization (paylist), completion of the administrative review, and award negotiation. As a first step in developing its own Council Operations module, eRA is looking at IC-extension systems designed for this purpose.

Mary Kirker and David Wise demonstrated the NIAID CAAP at the eRA Project Team meeting on May 13. This extension system accesses eRA system (IMPAC II) data, which is downloaded daily from eRA to the CAAP database. Adhering to the logic of the old paper process, CAAP provides a user-friendly interface for Program staff to view application status and create NIAID funding plans.

CAAP supports the following functionality:

• Display of applications awarded and release dates     
• Display of applications still to be awarded      
• Display of applications that have received pre-Council clearance     
• Display of application scores     
• Display of portfolios     
• Preparation of materials for Council     
• Display of MERIT awards and MERIT extensions     
• Creation of RFA and PA funding plans for future Councils     
• Creation of requests for Administrative Supplements

eRA’s future Council Operations module will be Web-based and use J2EE technology. It will complement eRA’s new Program module (PGM), which currently is in pilot mode.

eRA to Eliminate Address Line 5

eRA will retire address line 5 from both person addresses and external organization addresses as part of the upcoming July deployment. For most addresses in the database, the information in line 5 breaks down into city, state, and zip for domestic addresses and city, country, and postal code for foreign addresses. Ultimately, in keeping with its goal of improving data quality, eRA plans to identify addresses by their component parts (e.g., department, mail stop, city, state) instead of by the generic lines 1 through 5. Storing addresses as component fields will improve reporting as well as enable the reuse of common address information, thereby reducing the total number of addresses that need to be stored and the multiplicity of address types.

The eRA team has written an algorithm to identify and convert domestic addresses by moving the data in line 5 into structured fields. This algorithm includes validations that use the city/state file provided by the U.S. Postal Service.

Although this conversion effort will clean out the majority of data from line 5, not all addresses can be converted successfully. For the remaining address records, data will remain in line 5.

The following bullets summarize the address changes that will take effect this July:

• Although the database column that represents address line 5 is not being removed from the database, eRA screens no longer will allow users to update the data in this line. Instead, users will be instructed to review the information in line 5, reenter that information as appropriate in lines 1 through 4, and erase the information in line 5.  
• eRA screens, documents, and reports that display address information will be modified to account for the conversion of line 5 address data. The addresses now will display line 5 only when there still is data in the field. For domestic addresses, if there is no data in line 5, the addresses will display city, state, and zip information instead.

Since the eRA Commons professional profile (PPF) only displays lines 1 through 4 of an address, eliminating line 5 does not greatly affect eRA Commons users. There will be a minor change to the eRA Commons Status screen to prevent the display of line 5.

Coding of Degree Information to Change

eRA will implement changes to the way academic and professional degree information is collected and displayed in the system. These changes, which will take effect in July, have three main objectives for improving data quality: simplification of degree coding, standardization of “earned degree” information, and reduction of duplicate degree entries.

• Simplification of Degree Coding

Although 98 percent of degrees fall into less than 40 degree codes, there currently are 560 distinct degree codes in the eRA database. The July release will reduce the number of degree codes to 39. Degrees that do not correspond to one of the 39 degree codes can be entered into the system in a new text field (“Other Degree Text”). All degrees entered into the system subsequently will be associated with the appropriate academic or professional degree category.

eRA plans to implement the above changes for both new and existing grant records. It is expected that the reduced list of values will be easier to use and maintain; the system will continue to satisfy all reporting requirements. 

• Standardization of “Earned Degree” Information

Until now, the determination of whether a degree has been earned has been inconsistently applied. Effective with the July release, the “earned degree” field for existing and future records cannot be blank. If blank, the system will default to “yes” or “no”, depending on the context in which the degree was entered (e.g., for trainees, the default assumption will be that the degree has not been earned).

• Reduction of Duplicate Degree Entries

The third initiative to improve degree data quality targets the incidence of duplicate degree data in the system. To address this problem, eRA has developed a process to collapse all degree records that are obvious duplicates. To reduce the creation of duplicate records in the future, eRA applications will issue a warning message if the user tries to enter a new degree code for a Principal Investigator (PI) or committee member and the code already exists for that person.

eRA Seeks Comprehensive, New Project Management Tool

eRA is evaluating commercial products, including PlanView, Oracle, Microsoft and Gensys software, to serve as eRA’s new enterprise project and resource management tool. Based on evaluations by Perot Systems (formerly Soza and Company), eRA’s project management oversight support contractor, eRA has determined that it has outgrown its current planning, scheduling and cost-tracking support systems. Centralizing the management of its resources under one system is an eRA goal for FY 2003.

In selecting a support system, eRA established the following criteria. The product must––

• facilitate the planning process and ensure the synchronization of initiatives    
• support full project life cycle    
• implement more rigorous project management processes    
• provide availability and utilization data to improve resource management    
• improve variance reporting

Some of eRA’s current planning and tracking tools will be phased out as their functions are migrated to a comprehensive, new system. These include a home-grown MS Access application for cost tracking and the Oracle Small Business Suite, which is used to collect staffing costs by specific endeavor. The project also uses MS Project and RequisitePro. RequisitePro is a tool for managing product requirements and requirement metrics. The latter tools may be integrated with the new software.

For more information, contact Donna Frahm.