NIH concurred with the recommendations and a commitment was expressed to incorporate these general types of user requirements into Commons Version 2.0. It was agreed that once NIH has derived new Commons screen prototypes, the CWG would be asked to offer feedback and help refine the new look and feel of Commons V 2.0.

Other potential V2.0 requirements, as listed below, were also presented and discussed.

The CWG generally supported the use of DUNS as a unique identifier for grantee institutions, as well as the single-point-of-ownership concept. The NIH agreed to solicit the group for further details as to the best means by which these two requirements could be incorporated into V 2.0. The receipt and analysis of such details comprise a portion of the current CWG meeting (see below).

Grant Applications Subgroup
The grant applications subgroup concentrated on analysis of the SNAP progress report. The survey devised by NIH following the January meeting asked for input on various major components of the SNAP application, as summarized below.

The survey asked specific questions to determine the extent to which any of these areas of the SNAP process might warrant change. The minutes from the May CWG meeting provide a detailed review of the survey responses for each of these components. In general, the grant applications subgroup did not recommend major changes to the SNAP paper-based submission process. By contrast, various changes were proposed to streamline submission via e-SNAP. As a means for the NIH to confirm these observations, a follow up survey was provided to the grant applications subgroup following the May meeting. The responses to this survey are the focus of the current meeting of this subgroup.

The Current CWG Meeting

The current CWG meeting was held in conjunction with the NCURA national ERA meeting. A total of 3 hours were allotted for the meeting. It was divided such that the Grant Applications Subgroup discussion took place for the first 90 minutes, followed by the same amount of time for the Interface Specifications Subgroup. All CWG members attended both subgroups and participated actively in the discussion.

Attendance:

CWG Members
Lynette Arias and Bob Oster - Team from Oregon Health & Science Univ.,
Tom Wilson - Baylor College of Medicine
Ellen Beck - UCLA
Graydon Kirk (for Nancy Wilkinson) - Emory Univ.
Nancy Wray - Dartmouth
Steve Dowdy - MIT
David Wright - UTMB
Kenneth Forstmeier - Penn State
Jane Fant - UMDN/NJMS
Jill Keezer - Cal Poly San Luis Obispo
Tolliver McKinney - St. Jude's
Jim Randolph - Univ. of Michigan
Mark Sweet, - Univ. of Wisconsin
Pamela Webb - Northwestern Univ.
Denise Clark - Cornell University

Vendors
Chris Harker - Cayuse Software
Dave Rubin - Cayuse Software
John Kostecki - Oracle Corp.

NIH Staff and Contractors
Bob Reifsnider - NIH, Microtechnologies Plus
George Stone - NIH/OPERA
Paul Markovitz - NIH/OPERA
Tim Twomey - NIH/OPERA
James Cain - NIH/OPERA
Al D'Amico - NIH/Z-Tech, Inc.
Carol Tippery - NIH/OPERA
Chris Lambert - NIH/OPERA
Scarlett Gibb - NIH/OPERA
Michael Cox - NIH/OPERA
Cathy Walker - NIH/NIGMS

Status of Design/Development of Commons V 2.0

The meeting began with a presentation by George Stone of the progress that has been made on the design and development of Commons V 2.0. (Additional details available in presentation slides #2-5: see attachment)

Confirmation of this progress was well received by the CWG. An informal poll of the CWG members, and specific comments indicate that the use of the current Status interface continues to wane due to the lack of consistent and accurate information. It was agreed that once it is known that information can be obtained reliably use will again increase. The CWG continued to express and interest in further enhancements of Status to allow for improved searching and a more complete display of information related to grant application status. George reflected on the fact that a portion of the current survey was devoted to Commons reporting requirements. Many of the requirements suggested through the survey pertain to Status-related information.

Grant Applications Subgroup: Recommendations for Changes in the SNAP Application Process

As noted above, a survey instrument was devised to solicit further input from the Grant Applications Subgroup (all CWG members responded) to confirm consensus recommendations that were expressed at the May meeting. Once NIH received the responses to the survey, they were analyzed and summarized. George provided copies of the verbatim responses to the survey, as well as the consensus summary (see documents attached). Carol Tippery, Acting Director of the NIH Office of Policy for Extramural Research Administration (OPERA) led the subsequent discussion of each aspect of the SNAP process. The objective of the discussion was to reach a final consensus upon which NIH could formalize changes in the SNAP process. Such changes could then be designed into the next version of the NIH Commons e-SNAP module.

Carol indicated that following the May CWG meeting, CWG recommendations were discussed widely at the NIH. Key NIH committees generally supported the CWG recommendations, as follows:

SNAP Science Reporting

The SNAP Abstract

The SNAP Progress Report Narrative

SNAP Research Accomplishments and Other Significant Changes

SNAP Questions

Literature Citations

SNAP Administrative Assurances and Certifications

Human Subject Assurances

Animal Subject Assurances

Other Administrative Assurances and Certifications

Discussion continued to center around whether the existence of such master agreements would actually save administrative burden. From both the NIH staff and institutional perspectives, the need to be able to account for terms and conditions, as well as track financial obligations was seen to outweigh the intuitive benefits of having far fewer numbers of NGAs.

Based on this lack of overwhelming support, it was agreed that no change would be made currently to either the paper submission process, or the e-SNAP-related process. It was agreed that both CWG and NIH staff would continue to study the strengths and weaknesses of this concept in various informal ways. The concept could be revisited again in the future.

The e-SNAP process will relieve this burden to some degree in that the system will be designed to at least provide the most recent personnel information from the previous submission. In this way at least it will not be necessary to generate the information de novo. Only changes in personnel will need to be introduced.

This procedure will continue through FY2002. Beginning in FY2003 such a notification will become electronic only via the NIH Commons Status System. The CWG requested that the notification also be sent to the institutional authorizing official, and principal investigator on each award via e-mail. It was argued that this type of "push" of information would create greater awareness on the part of the institutional officials, and thereby lead to better compliance of submission deadlines. NIH staff agreed that such an e-mail notification would be included in the design of the Status system.

Summary of Action Items

Interface Specifications Subgroup: Responses to Requirements Survey to Define Priorities

George began this portion of the CWG meeting by indicating he planned to raise issues relative to the survey topics out of order compared to how they were presented in the survey. He suggested that he wanted to save the most complex issues: organizational hierarchy definition and institutional approvals to the end of the agenda.

Institutional Reporting Requirements

Results from the survey appeared very straightforward in relation to defining institutional reporting requirements. In short, institutional representatives indicated that at one time or another they would like to know something about every possible combination and permutation of information about either Commons users from their institution, or content of the NIH eRA system: grant application and award status.

George indicated that in many ways this is really the easiest of requirements to meet. What has to be designed is a means by which every interaction between the grantee and the NIH, including the essence of any information that was exchanged, could be recounted through customizable reports. George provided several handouts summarizing the types of reporting requirements that were gleaned from the survey (see attachments).

To further refine the requirements, the types of report parameters that would be used by P.I.s was made distinct from A.O.s, distinct from S.O.s. There is a high degree of similarity in the information to be made available to any of the user types. The greatest difference is that the PI type user would only be able to generate reports for his/her applications and awards, while A.O. and S.O. types would have the need to generate reports for multiple investigators within their account hierarchy (in the case of the A.O.), and across the institution: across multiple account hierarchies (in the case of the S.O.).

The CWG generally concurred with this interpretation. It was agreed that in light of the significant magnitude of information that could possibly be contained in an institutional report, it would be important for the NIH to design an interface that would allow especially for A.O.s. and S.O.s to be able to carefully control the query parameters of such reports. It was agreed that the eventual use of portal technology as a means to customize and store specific "views" of the institution would be very valuable. The group was reminded to Dr. McGowan's presentation at the May meeting during which he spoke of the efforts currently underway at NIH to begin to analyze portal technology as a way to solve similar issues for NIH staff responsible for similarly complex sets of information. The ultimate benefit of portal technology should allow for customized views for both NIH and grantee staffs.

One issue that the CWG members were asked to comment on involved the definition of account hierarchies as they relate to institutional reporting. The question related to the extent to which account hierarchies at an institution should be strictly observed for the purposes of reporting. George presented an animated slide to illustrate the point. The topic was deemed important in light of comments received during the requirements analysis phase of the Commons Status system. Concern was expressed during that process for the fact that P.I.s definitely did not want A.O.s to know all the specific details about the status of their pending applications. There would appear to be a similar issue as it relates to more general reporting.

In an open account hierarchy it would be possible for any S.O. to obtain reports concerning staff at any other component of the institution. In the same way, and A.O. from one department at a university would have the ability to view information related to a P.I. in a different department (in potentially a completely unrelated part of the university).

This is in sharp contrast to a closed account hierarchy, where only the S.O. (or A.A.) or A.O. who created specific accounts would be able to view information within that account "tree". This would preclude the "lateral spread" of information.

The CWG was very clear in their position that any reporting system would need to strictly observe a closed account hierarchy.

To conclude this topic, George indicated that these requirements would be carried forward to the designers and developers of the next version of the Commons. Further, he indicated that once the requirements for such a reporting system were available, they would be shared with the CWG for review and comment.

Summary of Action Items for Reporting Requirements

Single Point of Ownership

The good news from the CWG survey was that there appeared to be clear consensus for the benefits of a single point of ownership for institutional and professional profiles. That is, once the profile is created for an institution by the S.O. (or designee), or for an individual by the P.I., the only party who should be able to change the content of the profile should be it's creator.

While there was strong support for the concept, the survey also revealed a strong statement: that the profiles for PI.s would never be current if the P.I. was left to make time changes. In short, unless under duress, P.I.s would not practice diligence at maintaining their professional profiles.

In response to this concern, it was agreed by all that the next version of the Commons needed to provide delegation authority. Using delegation, P.I.s could allow for assistants to have access to their profile so as to keep it current and accurate. The NIH agreed with the importance of this requirement, and agreed to include it. At a high level, the way in which this type of functionality would work would be for the P.I. to issue an "account" to a designated party. With this formal account, the designated party would have edit access to the P.I.'s profile.

Another area in which the CWG expressed a clear suggestion for profiles was the need for the NIH to work with third party vendors who offer profiling systems. This would allow universities who subscribe to such services to enter profile information once into the vendor's system. Through the designed interaction between the vendor's system and the NIH Commons, it would support the population of the NIH Commons profile automatically. In response to this recommendation, George reiterated that the NIH had been "advertising" to all such third party vendors whenever possible a desire to want to work toward these common benefits. While the NIH would not be able to offer any financial incentive to any vendor to create such an integration, NIH has produced an API to support such an interaction, and has repeatedly offered to work with any vendor who wishes to test an implementation that they have created for their customers.

There was a general consensus among the assembled group that any specifications that were being created to support profiles in the next version of the NIH Commons should also be complementary to Federal Commons specifications. This was view as crucial such that once the Federal Commons is available, any profile information contained in the NIH Commons would be able to be submitted to the Federal Commons profile repository.

A final suggestion that was made in the meeting was the possible benefit of notifying investigators of "dormant" profiles. The supposition here is that if a profile is being actively maintained, it should change on some reasonably reliable basis. There was not real consensus or directive on this. George pointed out that since changes (or lack of changes) in all such information would be auditing in the next version of the Commons, it would be possible to monitor and see just how frequently profiles change. With these types of statistics available, it would be possible in a future release of the Commons to introduce additional triggers that would send such notifications based on real trend data.

Summary of Action Items for Single Point of Ownership

DUNS as a Unique Institutional Identifier

There was some debate at the May CWG meeting as to whether the DUNS number would represent a good successor to the current NIH IPF number (7 digit identifier unique to each NIH grantee institution).

The survey responses helped clarify this point. There appears to be no argument but that the DUNS number can be a very good institutional identifier. At the same time, there is strong opinion that it would not work as the means by which an institution identifies subcomponents. Thus, the 9 digit DUNS would serve aptly to identify university "X". The non-standardized use of the four additional optional DUNS digits would represent an administrational nightmare. George actually expressed relief on the part of NIH at this finding in that NIH was also not willing to consider the use of DUNS as a means to identify grantee organization subcomponents (e.g. schools, institutes, departments, divisions). Out of this it was agreed that DUNS will only be employed as a way to identify at the highest level of the organization.

When questioned about the logistics of applying for, and agreement to use the same DUNS number for the entire grantee organization, CWG members indicated that the approach would be acceptable. It was generally agreed by CWG members that the early stages of DUNS implementation would likely be challenging, but that value of having a universal identifier for the purpose of grants administration activities across the government would be worth the challenge.

The CWG survey uncovered another issue in relation to DUNS that had not been considered previously: namely that the introduction of yet another identifier would be seen as difficult to endorse and apply by many investigators. The comment was made that investigators already complain about how many different usernames, password and unique identifiers they need to track. In response to this concern NIH agreed to design the next version of the Commons such that the user would only need to insert username and password for logon. The analysis conducted by NIH toward this conclusion indicated that many other secure systems across the government and industry require only two unique parameters for logon. The NIH Commons will adopt this model. The only change that will be required to allow for the omission of the institutional identifier will be to ensure that the username is unique across the Commons database. This will be necessary, since in the next Commons version, username will serve as unique to identify a particular user at a particular institution.

Summary of Action Items for DUNS as Unique Institutional Identifier

Having resolved the fact that the DUNS number is not a reasonable candidate to define institutional hierarchy, the discussion turned to the responses on the survey regarding other standard ways to identify hierarchy. George presented several slides as an introduction to the discussion. The underlying notion being that the need for accountability at various levels in any institution/organization requires a well-defined hierarchy. This accountability is particularly relevant for approval of binding decisions, audit of actions, oversight of reporting obligations, and control of budget and management.

From the survey question that asked for a description of institutional hierarchies, George crafted a spreadsheet that identified four basic levels (see attachment). In generic terms these appear as the institution, school, division, and department. Interestingly, the NIH allows for definitions for each of the 4 levels as part of any grant application. The IPF (would be DUNS) defines the institution, the organization type defines the "school", the major subdivision defines the "division", and the "department, service, lab or equivalent" defines the "department". Where difficulties arise is in the fact that currently only the IPF and organization type are standardized: major subdivision and department… entries by the institution as part of the application face page are open text.

George indicated that in conversations with NIH DEIS staff there was desire to make all four defined levels standard in the next version of the Commons. By so doing, an institution could represent its hierarchy uniquely within it institutional profile. The Commons would have flexibility built into the design, recognizing that institutions may have multiple lower level hierarchies: schools, divisions, and departments.

The definition of standard hierarchies would relieve NIH staff of having to interpret the current range of open text entries that represent the 2,000+ grantee institutions. Sorting and identification of grantee organizations as part of NIH reports to congress, for example, could be done based on standard combinations of defined hierarchies.

The CWG offered strong support for this approach, since existing NIH-derived profiles for institutions are not accurate relative to how institutions define themselves.

Summary of Action Items for Organizational Hierarchy

Institutional Approvals - User Roles and Rights

The additional role for hierarchies at institutions involves approvals prior to submission of grant applications. Given the fact that NIH awards are made to institutions as opposed to individuals, all applications, though created by P.I.s, must be reviewed, approved and submitted by the grantee institution.

The need to obtain such approvals has proven to be perhaps the greatest challenge in the design of any eRA system. The difficulties appear to be based on the diversity of organizational hierarchies and diversity of workflow involved in approvals at any particular institution. In short, despite efforts by the FDP EARS committee attempting to define a generic means for routing and approval of applications prior to submission, or efforts by the NIH toward the same end, there continues to be a lack of complete satisfaction by all grantee institutions.

The CWG survey attempted to tackle this issue yet again by asking CWG members to identify the roles and rights that should be provided to support grant application approval and award administration. In an effort to facilitate reaching consensus on this issue, the roles and rights that defined in the MIT COEUS system were offered as a starting point. These roles and rights were recommended as part of the May CWG meeting, since many schools have adopted the COEUS system.

The summary of the survey responses that were provided as part of the meeting continue to point to the uniqueness of each institution with consequent suggestions for specific changes to be made to the COEUS roles and rights. At the same time, several broad recommendations were made and reiterated as part of the discussion that NIH agreed needed to be addressed in the next version of the Commons.

As a means to further this discussion, George presented a slide that set forth the scope of roles and rights that NIH would be likely to undertake as part of Commons V 2.0. In short, the NIH eRA system will support generic roles and rights to allow for approval of grant applications. NIH will not be able to design a software application, however, that supports institutional workflow. George pointed out that the uniqueness of workflow has resulted in the creation of a specific market in such applications. To expect the government to mount such an effort is not realistic.

George went on to describe what he referred to as the "Gold" version of roles and rights software that would be considered for Commons V 2.0. The system would be built upon the same four roles that are currently represented in the Commons: S.O., A.O., A.A., and P.I. To address concern that these exact role types would not support all institutional roles, George introduced the concept of a Commons user roles and rights interface that would allow for customizing each role, including creating a unique title for each user. By such and interface each institution would have flexibility to ascribe specific rights to a particular role type consistent with the status of the corresponding staff in the institution's approval hierarchy. In this way, it would be possible, for example, to define two users with a role of S.O. to have radically different sets of rights. Once a customized role with associated rights was established it would become part of the individual's professional profile; it would be saved, with the potential of modification by authorized users (A.O. or S.O.) at the institution. Such an interface would be created as part of the Commons Admin interface. Slides that George presented offered an animated example of how the interface would work.

Though a bit skeptical of the approach, the CWG did express support for this as a step in the right direction toward providing a meaningful way to define approval hierarchies within the Commons. CWG members were quick to provide useful comments as to specific requirements that should be included in such a Commons role and rights system. General comments follow:

NIH agreed to solicit the CWG institutions as this interface is being designed. This would allow the CWG to assist in creating the initial rights categories.

Summary of Action Items for Institutional Approvals - User Roles and Rights