MINUTES, REVIEW USERS GROUP
3/26/01

Eileen Bradley brought the meeting to order shortly after 1:00.

The meeting consisted of three parts - first a demonstration of the Grant Folder; second, some discussion about the summary statement pilot; and finally, a start at working through the list of priorities for enhancements.

1. DEMONSTRATION

Michael Cox, technical director of the "Scanning Project," OER, led the demonstration, with comments and clarifications from Daniel Fox and Andy Greenleaf.

As of the last release of the module, a new button ("Grant Folder") was added to the List of Applications screen. The concept of the Grant Folder had been raised by the Review JAD early on, and, in combination with the Scanning Project and the availability of PDF summary statements in IMPAC II, the possibility of implementing the Grant Folder became a reality, even if not all functions are yet available and some bugs may remain. The decision was made to release the Folder on the assumption that it would be worthwhile even if it is a work in progress.

By way of preamble (while a working projector was sought!) it was explained that there may well be a variable speed of image acquisition (or worse problems) based on three aspects of each user's software: the operating system, the web browser, and version of Adobe being utilized. The three will interact in various ways, so that one browser will work well on one platform but not another, etc. However, the IMPAC II design, by fiat, is based on Windows 2000; while the developers will make attempts to optimize performance with other systems, they do not guarantee results and may have to advise users that they must switch systems if incompatibilities are too much of a problem.

The first phase of the Scanning Project has been to scan in the entire application for the set of BECON applications (and only these) received for this round. Through manual intervention, an index for each of these applications was developed which allows users to "hot link" to particular pages of the application (based essentially on the Table of Contents in the application). A couple of the applications were displayed in the demonstration with excellent performance. Another factor in retrieving the application image, of course, will be the size of the PDF file - the larger the application, the longer it will take to load. However, with an optimal configuration, loading of an "average" application can be accomplished in as little as a few seconds.

The plans for the Scanning Project include extending scanning to the AIDS review groups in May, and, hopefully, to all applications in the next 18 months. Currently, a copy of each BECON application is siphoned off as soon as it enters the Referral Office and is forwarded to the contractor for scanning. The process takes about a week. In response to a question about receipt of electronic applications, it was stated that the Scanning Project is looked upon as an interim fix to allow users access to an electronic version of the application sooner rather than later. Users other than those involved in reviewing the BECON applications will NOT be able to see the Grant Images for the immediate future.

Other advantages of the scanned applications include the presence of an OCR (optical character recognition) version of the application "in the background" which can be searched for terms and from which sections can be cut and pasted (such as the abstract). However, users would need to be aware that the OCR software will not be 100% accurate (98% accuracy is claimed).

In response to a question on the handling of the submission of revised application pages, Cox noted that this is on the list of issues to be addressed.

To address other aspects of the Grant Folder, the following buttons are displayed, although many/most will currently be grayed out:

1. Summary Statement - (summary statement for the current application/grant)
2. Prior Summary Statement(s)
3. Abstract
4. Notice(s) of Grant Award
5. Grant Image (discussed above)
6. E-Snap - (info on type 5 applications)
7. Grant History - (status type report)
8. Close

REV users should be aware that this screen will be available to all NIH users, so some features are designed for other audiences.

If a button is grayed out, that function may not yet be available, that function may not be one which the user has the rights to access, or the image may not yet be available for display.

With regard to Prior Summary Statements, Fox noted that, to date, roughly 150,000 summaries have been converted to PDF format, with an estimated completion for that project of Friday. However, that cohort of applications will only include those already in IMPAC II - roughly five years worth. Older summaries will need to be retrieved either through IMPAC I or, in IMPAC II, through CRISP or IQR (IRDB Query Reporting, where IRDB stands for IMPAC II Reporting Database).

With regard to the Grant History report, it was noted that this report is based on a report designed for Receipt and Referral; as such it currently lacks information on the Program Official assigned to the application (name, phone, and e-mail). It was the request of the Users Group that this information be added. ACTION ITEM FOR PROGRAMMERS (Note that this will need to be assigned a priority.)

2. SUMMARY STATEMENT PILOT

In response to concerns raised at the last meeting, Fox reported that, sometime in May, the programming will be altered so as to prevent testers from uploading a summary statement body for an application which already has a final summary statement entered through the IMPAC I system and bridged to IMPAC II. This will serve to block inadvertent changes to the official version, as bridged from IMPAC I. In the meantime, it is possible for testers to overwrite print req'd summaries should they press the Rel Final SS button in IMPAC II. The conservative approach would be to suggest to users that they only test the module on applications which have not yet been print req'd. However, if none are available to the user, they may test the system by constructing Draft summaries but should be careful NOT to press the Rel Final SS button. (As a point of clarification, the text version of the summary stored in IMPAC II will NOT be affected; however, PDF versions, which CAN be accessed through some IC modules WOULD be affected if a user were to Release a Final SS in IMPAC II.) If a summary requires revision, the user may test that aspect of the IMPAC II module, but must upload and print req the official revision in IMPAC I.

3. DISCUSSION OF SUGGESTED ENHANCEMENTS TO THE REVIEW MODULE

Bradley told the group that an important and pressing task before the group is to examine the list of enhancements that were proposed by the JAD and either reconfirm or alter the priorities that had been assigned to them by the JAD. In response to a concern by one of the members that, at least at the beginning of the process, it would be hard for the newcomers to compare the priority of one suggestion with another, it was agreed that the first pass through would be designed to educate the entire group as to what each issue was about as well as to identify those items which have already been done.

In working through the set of suggestions, the group used the detailed 33 page document which had been forwarded to the group by Bradley. In summarizing the discussions, these minutes will not attempt to capture all of the discussion which surrounded each item since, in several cases, explanations and comments at the meeting were aided by reference to displays of the screens in question. Should members who were not present for the discussion need additional detail, they are first referred to the PDF document; in cases where that is insufficient, Eileen Bradley, Richard Panniers, Mike Sesma, or Ev Sinnett (the latter three being former JAD members) have agreed to provide additional details.

The format for reporting progress at the meeting will be to provide the reference number (e.g., REV 1115), followed by the initial (JAD produced) priority, followed by any comments or decisions.

NOTE - A number of items with a priority of 95 relate to the redesign of the Assignment (1500) screen. As noted before, it is more efficient for the programmers to address all suggestions related to a given functionality at one time, even though some suggestions might, on their own, have a lower priority, than to slavishly follow the priority list and return multiple times to the same screen. Thus, a number of issues related to the 1500 screen were all assigned a priority of 95, since that was the overall priority assigned to the redesign of the 1500 screen, even though they might individually have gotten a lower score.

REV 1115 - 100 - In progress; replaces IMPAC I function. Greenleaf noted that a focus group will need to be formed in the coming month to see whether any changes should be considered in moving from IMPAC I procedures to the IMPAC II environment.

REV 1113 - 100 - In progress and nearly completed; replaces IMPAC I function.

(NOTE - Replacing current IMPAC I functions is the highest priority. In response to a question, there was reassurance that no (useful) IMPAC I function will be turned off until an IMPAC II replacement is available.

REV 0310 and 0051 - 95 - CLOSED; these related issues have been addressed. It was agreed that the hierarchy of column designations currently in the system provides sufficient flexibility so that programming so as to allow user designation of column ordering need not be considered further.

REV 0177 - 95 - There was considerable discussion on the utility of this request and the programming required to implement it. Greenleaf suggested that when the Assignment screen is redesigned, the goals of this suggestion could be met more simply through a better display of the scientific terms entered by the users.

REV 1194 - 95 - CLOSED; this issue has been addressed.

REV 0047 and 0046 - 95 - Sinnett described the issues. Greenleaf noted that Quick Assign functionality is closely tied with the 1500 screen, so it was agreed to leave these bundled with other 1500 screen issues.

REV 1207 - 95 - There was considerable discussion on this issue, with strong tastes being expressed on both sides of the issue. Despite the additional programming required, the group felt that the only way to satisfactorily address the issue would be to modify the assignment reports so as to include a check box to allow users to select whether or not designations such as P1, P2, S1, R1, etc will be displayed on their reports. The default will be for the box to be unchecked. The default WILL still cause a P to print next to primary assignments.

REV 1587 - 95 - This was deemed to be a potential bug. Sinnett agreed to recheck to see if it still happens. On checking, this issue can be CLOSED. The programming now provides a warning even if you try to assign someone with a User Defined Conflict in the role of Mail Reviewer, and the non-Oracle exception did not occur.

REV 0324 - 95 - This was agreed to be a bug, if it still occurs. On checking, this item, too can be CLOSED, since it seems to be fixed.

REV 1680 - 95 - Sinnett explained that the exact issue described (lack of display of an IPF code in Reviewer Details) need not be addressed (since the conflict checking procedures will access the IPF codes whether they are displayed or not), but the larger issue of what information on a reviewer is brought into the 1500 screen (and its source) definitely does need to be addressed. There was agreement from others on this point.

REV 1697 - 95 - There was agreement that a final "edit check" button would be very useful. This would prevent assignment lists from being mailed out with an inadvertent (non)conflict blocking the reviewer from knowing that (s)he was actually assigned to review the application. In the meantime, SRA vigilance is required!

REV 0347 - 95 - 1500 screen issue.

REV 1686 - 95 - ditto

REV 1703 - 95 - ditto

REV 1184 - 93 - DEFER. Others (eRA, Carol Martin (Reports Advocate)) are working on solutions which seem likely to address this problem. This issue can be reexamined once these other tools are available.

REV 0036 - 92 - While individual summary statements are now available through the Grant Folder, the group felt that it would be very useful to have a feature which would allow users to easily bundle the request for all (or a selected list of) prior summary statements for a given meeting into a batch job.

REV 1204 - 92 - CLOSED. See Grant Folder and REV 0036 just above.

REV 1633 - 91 - While there was some debate on how this feature might work, it was noted that a more detailed solution, agreed upon by the CSR IRG Chiefs (the only review staff directly affected) had been mailed to the developers but had not been included in the notes. The developers will follow that plan for implementation.

At this point Dr. Bradley noted that the meeting would need to close but that proceeding with the review of priorities, while tedious, really needed to be accomplished both with care and expediency. Thus, the group will meet on April 2 to continue the process.

The meeting was adjourned at approximately 3:40.

Many thanks to Dr. Ev Sinnett for the preparation of these minutes

Attachments

No attachments.