**[MINUTES]{.underline}**
![](media/image1.gif){width="0.9736111111111111in"
height="0.5680555555555555in"}

NIH Commons Working Group (CWG) Meeting

**[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}**

Date: Wednesday May 16, 2001

Time: 8:30am-4:00pm

Location: State Plaza Hotel, 2117 E Street, N.W. Washington DC

**[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}**

**[Next Meeting:]{.underline}**

[**Follow up from last meeting:**]{.underline} At the January 2001
meeting of the CWG, two subgroups were formed. The focus of the first,
the Interface Specifications Subgroup, is to provide the NIH with
feedback on existing NIH Commons interfaces and to provide insight as to
desired functionality for the next version of the Commons (V 2.0). The
second subgroup will be devoting efforts to evaluate the noncompeting
award process, with an eye toward further streamlining. Following
recommendations for streamlining, this subgroup with then assist with
interface requirements for the newly-defined business process.

The current daylong meeting was divided such that the Interface
Specifications Subgroup met in the morning, and the Noncompeting Award
Subgroup met in the afternoon. While specific members of the CWG have
volunteered for each of the subgroups, all CWG members attended both
subgroups and participated actively in the discussion.

**[Attendance:]{.underline}**

***CWG Members***

Lynette Arias and Bob Oster -- Team from Oregon Health & Science Univ.,

Tom Wilson - Baylor College of Medicine

Ellen Beck - UCLA

Nancy Wilkinson - Emory Univ.

Nancy Wray - Dartmouth

Steve Dowdy - MIT

David Wright - UTMB

Kenneth Forstmeier - Penn State

Jane Fant - UMDN/NJMS

Jill Keezer - Sidney Kimmel Cancer Center

Tolliver McKinney - St. Jude's

Jim Randolph - Univ. of Michigan

Sandi Robins, Mark Sweet, and Jim Tracy -- Team from Univ. of Wisconsin

Pamela Webb - Northwestern Univ.

***Others Institutional Representatives***

Bob Beattie - Univ. Michigan

Gradon Kirk - Emory Univ

***NIH Staff and Contractors***

# Bud Erickson - NCI

# Bob Reifsnider -- NIH, Microtechnologies Plus

# George Stone -- NIH/OPERA

John McGowan -- NIH/NIAID

Megan Columbus -- NIH/OPERA

Paul Markovitz -- NIH/OPERA

Tim Twomey -- NIH/OPERA

Brent Stanfield - NIH/CSR

Paula Mac Lellan - NIH/LTS Corp.

Mary Kirker - NIH/NIAID

James Cain - NIH/OPERA

Marcia Hahn - NIH/OPERA

Al D'Amico - NIH/Z-Tech, Inc.

Carol Tippery - NIH/OPERA

Chris Lambert - NIH/OPERA

Virginia Van Brunt -- NIH/LTS Corp.

##### Other Agency Representatives

Jean Feldman - NSF

### Morning Session 8:30 -- 11:30: Commons Interface Specifications Subgroup

The discussion began with an acknowledgement of the importance of the
CWG in the overall NIH eRA Project. The CWG represents a formal conduit
to receive input from the extramural community. As CWG members solicit a
wider group of extramural eRA users for feedback, it will ensure that
the NIH Commons will continue to be designed with an optimal set of user
interfaces. Moreover, user input will also benefit as NIH Commons user
requirements are acknowledged and incorporated into the design of the
Federal Commons.

-   ***[CWG Responses to Existing Commons (V 1.0) Interface
    Specifications]{.underline}***

***Commons Registration, Accounts Administration, Status***

As a result of the last meeting, NIH devised a survey instrument to
allow Subgroup members to evaluate existing Commons (V 1.0) interfaces.
Responses to the survey were received over the last several months.
Prior to this meeting the NIH analyzed the survey responses. Discussion
sought to confirm the dimension of the responses and arrive at a
consensus set of recommendations. Further, the discussion focused on the
extent to which the recommended changes could be made in Commons V 1.0,
or deferred to Commons V 2.0.

#### 

George Stone presented a summary of the survey responses concerning the
V 1.0 interfaces that support Institutional Registration, Accounts
Administrations, and Application/Award Status (an attachment is provided
that contains the complete screen-by-screen survey summary). Major
points included:

-   **Dated Appearance:** There appeared to be a general consensus that
    for most screens the icons are too large icons, and graphics are not
    intuitive; there is too much wasted space.

-   **Dated navigation and flow:** The best web interfaces of today
    assume greater user sophistication than circa 1996. The V 1.0
    Commons screens have too many menus, too many links, and require too
    much navigation.

-   **Help screens:** There exists a whole new set of help screen
    technology now relative to when Commons V 1.0 was developed.
    Existing interfaces do not have adequate context, text is not always
    accurate, and FAQ's need improvement. George indicated that even in
    advance of this meeting, new help functionality is being previewed.
    By the next CWG meeting a demo will hopefully be available for
    discussion. One aspect of the new approach, consistent with the
    survey findings, is that FAQ's will have greater context. User help
    for a specific topic will lead only to FAQs for that topic rather
    than an all-inclusive FAQ list.

-   **Screen layout:** While dated, screen layout per se was not seen as
    bad. Links to subordinate screens should be minimized to improve
    continuity. Screens with table-type layouts should be consistent:
    aligned columns and rows. While limiting links internal to a
    specific module, there should always be ways to link to other
    modules and to link to relevant sites outside the eRA Commons.

-   **Screen functionality, search capabilities**: For all cases where
    the user must select from a list, there must be an improved way to
    search. Instead of scrolling through a long list to find a specific
    item, a search must be possible.

-   **Screen functionality, presentation of tabular data:** For all
    cases where the user views a list, there must be an improved way to
    sort. Functionality should be included that allows for sorting by
    any column.

-   **Reports:** With increased audit capabilities in the database,
    enhanced reports should be available. This should include ways to
    allow for closer monitoring of Commons use by institutional
    administrators, e.g. user session time, specific interface used,
    changes made in the database, last logon etc. Also, more complete
    reports of status should be available, including pending application
    deadlines for P.I.s, and cumulative reports of anticipated award
    dates and budget amounts. It is important to have contact
    information for NIH staff correct, as well as links to study section
    rosters and dates of review meetings. Ultimately, ad hoc report
    functions in a portal-type environment would be ideal.

-   **Navigation:** Navigation between modules, while represented in the
    V 1.0 interfaces, is not well characterized. NIH recognizes the need
    to have a better way to navigate between modules. The navigation bar
    seen at the top of existing screens has the right idea, but the
    presentation needs refinement. Also, the need to navigate within
    each interface must be kept to a minimum.

-   **Profiles:** Currently every user is encouraged to create a
    complete professional profile. The question was raised whether the
    extent of profile should be defined by the type of user. For
    example, investigators establish different profiles than
    consultants. It was agreed that since there is considerable overlap
    in roles, including situations where the same individual is a P.I.
    and administrator, it would be best to keep the same structure.

-   **Creating New Accounts.** One of the most challenging aspects of
    the current Commons is the means by which a new account is created.
    Due to the need to positively identify the prospective account
    holder in the IMPAC II database, a unique person algorithm has been
    created. It relies on capture of unique identifying information
    about the account holder that can be used to challenge the IMPAC II
    database. It has been a longstanding problem that such an algorithm
    is slow, and not always accurate. The discussion centered on ways to
    improve this aspect of the system. It was agreed that the unique
    identification within IMPAC II would improve if the search were
    limited to within the user's institution, and P.I.s (i.e.
    individuals who are likely to be represented in IMPAC II). Any
    duplication in P.I. profile within the use's institution could be
    reconciled by manual selection. Creation of new accounts for
    administrators (A.O. or S.O. user types) would not use the unique
    person algorithm. Their profiles would be created de-novo. Since a
    unique IMPAC II person number is created commensurate with
    establishment of any profile, and that ID number is always
    associated with that profile, any subsequent changes to the
    profile-related information would not threaten the uniqueness for
    either P.I., A.O., or S.O. types. Implementation in this ways will
    also have the benefit of cleaning up duplicate profiles that
    currently abound in IMPAC II.

-   **Institutional Hierarchy:** For institutional profiles there is
    inadequate functionality to establish the institutional hierarchy.
    This is seen in that information currently reflected in existing
    institutional profiles are not correct in the minds of institutional
    officials, and yet the current Commons interface functionality will
    not allow for editing of institutional components. The CWG requested
    that new functionality be created to resolve this shortcoming. To
    work toward this objective, CWG members were given the assignment to
    identify acceptable level of institutional hierarchy that they would
    require in the Commons. With this information, the NIH eRA staff
    will be able to make proposals to NIH staff components to clarify
    hierarchy choices.

-   **Integration into FastLane and Federal Commons:** NIH acknowledged
    that they will continue to work to integrate all NIH Commons changes
    into Federal Commons specifications. Further, Commons data
    dictionary and design will take into consideration wherever possible
    any similarities with the NSF FastLane system.

-   In relation to all of the topics discussed, George indicated that an
    analysis would be done to identify which of the proposed changes
    could still be incorporated into V 1.0, and which deferred to V2.0.

## 

## Commons V 2.0 Architecture

##### N-Tiered Architecture; J2EE; Design, development timeline

Bob Reifsnider, an NIH contractor, presented slides to update the CWG on
plans to move the Commons to a new architecture for V 2.0. The major
points of his presentation were as follows:

-   **Current Commons Architecture:** The current NIH Commons involves a
    2-Tiered architecture. This approach that has been considered
    state-of-the-art since the mid '90s allows for clients to address a
    single database. Its shortcoming is that business applications
    coding must exist in both the database and front end to support
    complex business rules. This limits performance and requires
    substantial oversight as part of software change management. Changes
    in code potentially need to be made in several places to ensure that
    the desired changes work correctly. Within the last year or so,
    N-Tier architecture has been introduced. It removes the business
    application coding from the database and front end, to reside in a
    middle tier. The result is a system with better performance
    characteristics and greater modularity and flexibility when
    requirements changes are introduced. After review of the high level
    requirements for the next version of the Commons, NIH has decided to
    move to an N-Tiered architecture. Bob included additional details as
    to the benefits of this architecture.

-   **J2EE:** J2EE (Java 2 Enterprise Edition) is a non-proprietary open
    framework/methodology for development of enterprise applications.
    Bob provided additional detail as to why NIH had decided to use this
    approach for developing the Commons V 2.0., including the fact that
    it is an open standard, has reusable components, is portable and
    easily integrates with COTS products.

-   **Development Timeline:** A Gantt chart was presented that indicates
    the Commons V 2.0 will be developed in phases. The first phase will
    be complete by the end of CY2001, though it will not involve
    deployment to the extramural community. Phase 2, providing Admin,
    Status, X-Train, and Profiles functionality will be deployed around
    May 2002. A concern was express as to how the introduction of this
    version of the Commons will coincide with integration with the
    Federal Commons. It was perceived that overlap could result in
    duplication of effort. The NIH is aware of this possibility and will
    reassess schedule and priority in light of where Federal Commons
    development is compared to the NIH Commons.

```{=html}
<!-- -->
```
-   ***[Planned Deployment of X-train v1.5]{.underline}***

######  

George Stone restated the purpose and functionality included in the
X-Train module. Consistent with what was mentioned at the January
meeting of the CWG, NIH continues to work toward a September 2001
deployment of X-Train V 1.5. It will have essentially the same
functionality as X-Train V 1.0 (that was not deployed in light of the
conclusion of the Commons development contract). The only difference is
that V1.5 will not call the PPF module, but instead include all
profile-related information within the X-Train interface. Any
profile-related information will, however, be retained in the profile
portion of the IMPAC II database. Deployment is expected for the end of
the summer 2001. If all continues on schedule NIH hopes to conduct a
demo of the X-Train V 1.5 interface at the NCURA ERA meeting in
Portland, OR in August.

-   ***[Future Commons Requirements]{.underline}***

***Role of NIH and the Extramural Commons Community (see slide).***

JJ McGowan presented slides to update the CWG on the eRA project,
including progress toward recruitment of eRA contractors, a reiteration
of both short term and long-term goals and objectives, and
accomplishments since the eRA Management Team was formed in April 2000
(see attached slides). JJ paid particular emphasis on two new high-level
long-range concepts. The first he described as a so-called "universal
module". The universal model is comparable is some ways to the approval
and routing software that is present for the existing e-SNAP module of
the Commons. JJ projected a similar set of roles that could be
incorporated into the eRA system so as to allow for NIH staff from
respective Institutes and Centers to render decisions. The vision that
JJ includes in the module would be for ICs and institutions to have the
ability to customize roles and rights for specific users. JJ was quick
to emphasize that this universal module concept was extremely
preliminary, and would not likely be developed or deployed in this form
for several years. In the interest of gathering additional information
to scope such an approval hierarchy, the CWG was asked as an assignment
to identify the organizational roles and rights that they consider
necessary to support grant application administration at their
respective institutions. Steve Dowdy of MIT indicated that he had
developed a list of roles and rights for the MIT COEUS system, and
offered to provide it as a starting point to develop a similar set for
the NIH Commons. The CWG agreed to use what Steve could provide. (See
"COEUS Roles and Rights" attachment)

The second module provides advanced reporting capabilities to support
the information requirements for various eRA user types. Such an
interface takes advantage of the fact that application-related
information that is contained in IMPAC II can be used in similar ways by
both NIH Staff as well as Commons users. For the Commons user reports
can be seen as an extension of the status interface. Especially for
institutional administrators, advance reports could include, at the
discretion of the user, lists of pending applications that include both
requested and recommended budget information, the date each was
reviewed, the predicted date of award, along with contact information
for each of the applications. Further information could be made
available based on documented requirements. In preparation for the next
CWG meeting, participants were asked to provide a list of the types of
reports that should be considered for this type of Commons
functionality. Though it is seen as extremely long term (i.e.
2003-2004), JJ did introduce the notion that such reports would lend
themselves to customized displays in a portal environment.

-   ***[Proposed Use of DUNS Number as Unique Identifier]{.underline}***

###### Basic Identifier for Grantee Institution

-   Since the inception of the IMPAC database in the mid '60s, grantee
    institutions have been identified uniquely using the IPF number.
    George Stone presented slides to the effect that IPF number is
    becoming limiting as a 7 digit identifier. An eighth digit will soon
    be needed to accommodate the cumulative number of institutions.
    Further, with the planned integration of the NIH eRA system into the
    trans-government Federal Commons, a new more universal identifier
    will be needed. George presented position now being adopted by
    several agencies that the DUNS number will be the identifier of
    choice. Several important attributes of such an identifier were
    presented (see attached slides), along with a schema as to how a
    transition could be made from the current IPF numbering system to
    DUNS. The CWG raised several issues including concern that many
    institutions already have numerous DUNS numbers already assigned,
    some of which are not known or well implemented. Another issue
    addressed the extent of modifications that would need to be made in
    the IMPAC II database, as well as changes in configuration and
    modifications to the Commons as well. Notwithstanding the effort
    that will required to sort out existing DUNS numbers and modify the
    NIH databases and interfaces, such changes are deemed necessary to
    prepare for future eRA implementation. Paul Markovitz, the NIH point
    person for the Federal Commons confirmed that changes made to adopt
    DUNS would be consistent with what is planned for the Federal
    Commons.

Without committing to specific details, the CWG was polled for a
consensus on DUNS. There was general support for the concept of using
DUNS as a universal identifier for the NIH Commons. NIH staff agreed to
convey this sentiment, and begin in earnest the analysis necessary to
transition from IPF to DUNS.

-   ***[Single Point of Ownership for Professional
    Profiles]{.underline}***

***(Please see slide)***

The concept of a single point of ownership was first introduced for eRA
at NIH in 1996 by Dr. John Mathis. The concept prescribes that a
specific extramural user who creates a profile is the owner of that
information, and they should be the only source of any modification of
the information. George Stone presented slides to support this concept,
likening it to ownership of information on a curriculum vita.
Historically, NIH has not observed this single point of ownership
concept. NIH staff have been given the ability within IMPAC and IMPAC II
to modify P.I. profiles, e.g. change names and other personal
information. This has resulted in creation of duplicate profiles for the
same person. In some cases there are as many as 15 different profiles
for the same person! Adherence to single point of ownership would ensure
that such duplicates could be resolved once and for all. This would be
guaranteed in that a unique I.D. number is now created for each unique
profile in IMPAC II. Once such a number is generated, it cannot be
changed, regardless of what attributes within the profile are modified.
Using this approach, even if NIH staff were allowed to create a variant
on a specific profile to suit specific needs within their IC, the
original profile would prevail since it has the unique I.D. number.

As with DUNS number, the CWG was asked whether they supported this
concept for NIH eRA implementation. The CWG recommends use of a single
point of ownership for profile information to ensure positive and unique
identification of extramural users.

####### 

###### [Summary of CWG Action Items]{.underline} Assignments for feedback from the CWG to define Commons Requirements

George Stone concluded the morning session of the CWG by summarizing the
action items to be undertaken by the CWG. Gathering of requirements for
each of several areas will assist the NIH define an optimum set of
functionality for the next version of the NIH Commons.

1\. Provide list of reports needed by P.I.s and institutional
administrators. Such reports pertain to

application/award status, and Commons user administration.

2\. Definition of institutional hierarchies for inclusion in the
definition of institutional profiles

3\. Development of a set of Commons user roles and rights, using the MIT
COEUS roles and rights as a

starting point.

###### [Plans for next Interface Specification Subgroup Meeting]{.underline}

***To be held as part of the NCURA ERA VI meeting in Portland, OR in
August***

The Interface Specifications Subgroup agreed that the next meeting would
take place in Portland, Oregon in conjunction with the National NCURA
ERA meeting in August. Ms. Nancy Wray, the CWG representative from
Dartmouth and program chair of the NCURA meeting agreed to make
arrangements for a room in which to hold the meeting.

Between now and the meeting, the CWG agreed to provide information on
the actions items as a basis for further discussion at the August
meeting.

### Afternoon Session 1:00 -- 4:00: Grant Applications Subgroup: The NIH SNAP Noncompeting Award Process

The afternoon session was lead by Carol Tippery, the Acting Director of
NIH Office of Policy for Extramural Research Administration (OPERA). She
involved Marcia Hahn, also of OPERA and Mary Kirker of the National
Institute of Allergy and Infectious Diseases to assist in the discussion
of the NIH Noncompeting Award Process.

The discussion began with an historical perspective of how the
noncompeting award process has evolved, with particular emphasis on
previous efforts to streamline the process. The details are best
summarized in the slides that Carol Tippery presented (see attachment).

Following the historical perspective, an interactive discussion of
potential next steps to refining the noncompeting award process were
initiated with the use of a tabular representation of other proposed
changes for each of the noncompeting award application areas that had
been tried over time. Below is a summary of each of the areas along with
a set of observations and consensus recommendation, if one was put
forward.

###### [Science Reporting]{.underline}

***The CWG supports the concept of a noncompeting "progress report"
rather than an "application"***

Several aspects of the science reporting portion of the award were dealt
with, as detailed below.

# Abstract

-   There was no support on the part of the CWG for the idea to require
    annual updates of the abstract. Those that participated in the
    initial e-SNAP pilot indicated PIs rarely updated their abstracts.
    Instead they merely copied the version of the abstract that was
    submitted with the competitive application.

> When NIH staff pointed out the value in updating the abstract to
> support the need for highlights of accomplishments as part of the
> annual NIH appropriations process, CWG indicated that if the P.I.s
> were more aware of this purpose for the abstract, they might devote
> more attention, and be willing to provide annual updates.

-   **As of now, however the following recommendation was made: To leave
    the current business practice in place. Require an abstract only
    with the competing application, with no interim updates required.**

# Progress Report

-   One possibility that was considered was to have all progress reports
    for all awards due once a year in the Fall. NIH put this option
    forward as a means to gather information that could be used for
    appropriations hearing occurring in the following spring. The CWG
    did not favor this approach, and instead indicated a preference for
    submission of the narrative progress report portion of the award
    annually on the anniversary of the award.

-   The one adjustment to current practice that was requested was for
    NIH to consider either a 30-day or 45-day window for submission
    prior to the anniversary date. Creation of such a window would
    relieve institutional administrators from having to process an
    extreme number of awards on the first-of-the-month basis that is
    currently practiced. Moving to the middle-of-the-months submission
    would also allow grantees some greater flexibility because this
    cohort of submissions would then be on a different cycle than
    competing application submissions.

-   The CWG also wanted consideration for the feasibility of submitting
    narrative progress other than annually. The argument was made that
    often times, especially for clinical research, significant progress
    may take more than a year to come about. One possibility that was
    mentioned was an FDP pilot allowing for submission of the narrative
    progress report on either an 18 or 24 month basis. NIH staff
    indicated that this may require deviation from policy.

-   An issue that has been raised frequently over the last year is
    whether it would be possible for the NIH to accept a noncompeting
    progress report directly from the PI without institutional official
    signature. The CWG expressed general support for the ability for
    direct submission from the PI with option of an automatic cc: or
    other notification to the Authorized Institutional Official (AO). An
    additional source of notification could be to incorporate the,
    "receipt of the progress report by the NIH" as an indicator in the
    Commons status interface. In this way AOs would have several ways to
    be informed that the submission had occurred, and when.

```{=html}
<!-- -->
```
-   Currently, the narrative progress report is confidential: releasable
    only subject to a FOIA request. The CWG agrees that this portion of
    the noncompeting progress report should remain under FOIA
    protection.

> A general observation that was made by NIH staff and corroborated by
> the CWG is that there needs to be better education of the grantee
> community, especially PIs, as to how the NIH uses these reports; e.g.,
> Congressional reports, budget justifications.

# Research Accomplishments & Significant Changes in the Research Project

-   "Research Accomplishments" are now an integral part of the progress
    report narrative. One suggestion by NIH is to break out this area
    and have it as a separate entry, reflecting bullets of scientific
    highlights and "Other Significant Changes". These would still be
    submitted at the same time as the narrative Progress Report.
    However, the system would also provide the ability for the PI to
    provide interim updates on an ad hoc basis. The CWG concurred with
    this recommendation.

-   Commensurate with the submission of such information, NIH staff
    (Grants Management and Program Officials) will be notified, as will
    institutional administrators.

-   The consensus of the CWG was that research accomplishment and
    significant changes in the research project should remain
    "confidential", i.e. subject to FOIA. Members of the CWG could see
    the potential benefit to the NIH of allowing this type of
    information to be freely available to the public, by including such
    items in the abstract. However, the group felt this was problematic,
    especially in light of the fact that the abstract would only be
    updated on the competitive cycle. This frequency would render such
    accomplishments or changes less relevant. In addition, NSF staff
    indicated they initially planned to have their "nuggets" public but
    3 years later are still struggling with this issue and have not
    changed their practice yet.

-   It was agreed that a better label had to be created for "research
    accomplishments." NSF uses the term, "*science nuggets*." There
    appeared no overwhelming support for this term. One other
    possibility that was suggested was, " science highlights." The CWG
    was asked to provide additional suggestions.

# Citations

-   Any new citations that are reported as part of the progress report
    should become part of the PI's professional profile.

-   Links should exist such that any progress report will link to the
    professional profile of the P.I.

-   It is important for electronic version of the noncompeting progress
    report to allow for the selection by the P.I. from a total list of
    their citations, the 10 they consider most relevant to the
    submission.

-   Any professional profile-related information contained in the
    progress report should automatically update the professional profile
    (perhaps with approval by the P.I. prior to changes being made).

-   Rather than requiring the P.I. to key in all new citations, the
    system should accept NLM accession numbers (Note: this already
    exists in the current Commons design). Also, the NIH should consider
    allowing P.I.'s to make reference to on-line journals or remote web
    sites to identify citations. Ideally, the specific reference
    information should be able to be uploaded into the P.I.'s
    professional profile, rather than requiring the information to be
    keyed in.

# Personnel Data Page

-   One of the most confusing aspects of the current noncompeting award
    application is the personnel data page. Carol Tippery indicated that
    attempts had been made previously to do away with this application
    page. The CWG strongly recommended that NIH determine if there was
    any way to revisit its omission from the progress report.

> It was pointed out that its value is to allow for monitoring of level
> of effort of personnel so as to be able to derive a total effort
> across all awards for a particular person. This value could be felt by
> both NIH and the institution. It also has current value for NIH staff
> as a tool to help clean up existing personal profile data.
>
> It was also pointed out that the burden associated with creation of
> the personnel data page would be reduced after the first year, in that
> the stored information would be retrieved from the IMPAC II database
> each year for easy update rather than having to re-key from scratch.

# SNAP Questions

-   The 4 SNAP questions were introduced in the mid '90s to facilitate
    completion of the SNAP application. Each of the questions allowed
    the P.I. to focus on a specific aspect of the application. If the
    answer to any of the questions was, "no", it relieved the P.I. of
    having to provide any information on that portion of the
    application. Within the last several years, the question on
    "Significant Rebudgeting" question was eliminated, and only 3 SNAP
    questions are now included in the application. With more than 5
    years of experience with the SNAP questions overall, the issue now
    is whether even the remaining 3 questions are really necessary?

> One could argue that they serve only a minimal purpose. An informal
> survey has indicated that in approximately 90% of the noncompeting
> applications, currently, the answer to the questions is, "no." A
> question was raised as to whether there was any anecdotal data on how
> many answer "No" when it's really "Yes", or what actions, if any, have
> been taken once an error was discovered. NIH will attempt to provide
> further perspective on this possibility.

-   A proposal by the CWG was that the three remaining questions; for
    changes in % effort, changes in key personnel, and unobligated
    balances greater than 25% of the approved budget for the award
    period, be eliminated as individual questions.

-   This doesn't necessarily relieve the grantee from the responsibility
    of addressing these issues as they pertain to progress, particularly
    if any of these would be change-of-scope indicators, just not as
    separate questions. Instead, the noncompeting progress report
    instructions would be modified to require that these issues be
    addressed as "Other Pertinent Information". It would be important to
    provide adequate help text and directions so as to minimize
    confusion over such a change in the submission.

> A possible implementation of this concept that, in fact, challenges
> its applicability involves whether the P.I. could adequately respond
> to concern about a large unobligated balance. Most CWG members felt
> that the typical P.I. does not track such issues, and so would not
> know to address this as part of the progress report. However, some
> felt this information is most likely monitored at the PI/Department
> level. An alternative way to handle such inherently administrative
> issues would be as a separate administrative question that would have
> to be addressed by an institutional official separate from the
> progress report.

###### [Administrative & Other Issues]{.underline}

***Human Subjects, Animal Subjects***

# Human Subjects

In general, the discussion about this portion of noncompeting awards
centered on ways that the burden of oversight can be diminished. The
points below represent ideas toward this end that need to be considered
further.

-   As of now, monitoring of annual IRB review is accomplished by Grants
    Management and Program review of the assurance \# and IRB Approval
    dates submitted on the face page of the application. The CWG
    concurred with a suggestion that this oversight could be streamlined
    if this role was relegated to the grantee.

> Institutions would have the responsibility of assuring compliance
> before any funds have actually been drawn down. With this kind of
> oversight in place, it could obviate the need for annual reporting to
> the NIH as part of the progress report.
>
> To test the concept, as part of the pilot, participating institutions
> would agree to provide a retrospective annual list for NIH review, so
> as to demonstrate that reviews were indeed completed prior to the draw
> down of funds.
>
> On a longer-term basis, monitoring and degree of compliance could be
> handled as part of a compliance site visits by either NIH and/or OHRP.
> Within the last year NIH has begun to conduct Proactive Noncompliance
> Site Visits. As part of this formal outreach effort, institutional
> understanding of this approach, and integrity of their records could
> be checked. An alternative that was raised by the CWG was that this
> information could theoretically be monitored through the A-133 audit
> process.

-   The CWG supported having assurance #s as part of the Institutional
    Profile. Challenges here include when multiple affiliated
    institutions are involved. It was agreed that the Commons system
    could potentially handles such instances by providing a
    table/picklist type of field that would allow the institutional
    administrator to identify the appropriate assurance \# for a
    specific award.

-   Though it would require coordination with OHRP, it was agreed by
    both NIH staff and the CWG that integration between the IMPAC II
    profile data for a specific institution and the approved assurances
    that are indicated in OHRP databases would allow for further
    validation. With appropriate business rules in the software, the
    institution could be notified if there was a lack of reconciliation
    between the NIH and OHRP systems.

-   All projects that involve human subjects must include tracking of
    populations of clinical subjects. It was agreed that for the
    noncompeting progress report such tracking would only be needed (the
    interface would only allow population tracking) if the scope of the
    project required it. The accuracy of this interface functionality
    would be incumbent upon NIH where the coding of each project takes
    place. Aside from relying on the interface to direct the user as to
    whether or not tracking is required, a separate notice to the
    institution as to NIH's expectations could be expressed as an added
    term of the award. This would get around the fact that many grantees
    would not be aware of whether their project requires or is exempt
    from tracking*.*

# Animal Subjects

As was suggested for human subjects-related information, in the case of
animal welfare steps should also be taken to less the burden of
providing repetitive information as part the annual progress report.

> As of now, monitoring of annual IACUC review is accomplished by Grants
> Management and Program review of the assurance \# and IACUC Approval
> dates submitted on the face page of the application. . The CWG
> suggested that this oversight could be streamlined if this role was
> relegated to the grantee.
>
> Institutions would have the responsibility of assuring compliance
> before any funds have actually been drawn down. With this kind of
> oversight in place, it could obviate the need for annual reporting to
> the NIH as part of the progress report.
>
> To test the concept, as part of the pilot, participating institutions
> would agree to provide a retrospective annual list for NIH review, so
> as to demonstrate that accurate records have been kept by the
> institution.
>
> On a longer-term basis, monitoring and degree of compliance could be
> handled as part of a compliance site visits by either NIH and/or OLAW.
> Within the last year NIH has begun to conduct Proactive Noncompliance
> Site Visits. As part of this formal outreach effort, institutional
> understanding of this approach, and integrity of their records could
> be checked. An alternative that was raised by the CWG was that this
> information could theoretically be monitored through the A-133 audit
> process.

-   The CWG supported having assurance #s as part of the Institutional
    Profile. Challenges here include when multiple affiliated
    institutions are involved. It was agreed that the Commons system
    could potentially handles such instances by providing a
    table/picklist type of field that would allow the institutional
    administrator to identify the appropriate assurance \# for a
    specific award.

-   Though it would require coordination with OLAW, it was agreed by
    both NIH staff and the CWG that integration between the IMPAC II
    profile data for a specific institution and the approved assurances
    that are indicated in OLAW databases would allow for further
    validation. With appropriate business rules in the software, the
    institution could be notified if there was a lack of reconciliation
    between the NIH and OLAW systems.

# Other Administrative Assurances & Certification

-   In the current Commons design, assurances and certifications are
    included as part of the Institutional Profile, including: Civil
    Rights, Handicap, Age, & Sex Discrimination; Debarment & Suspension;
    Drug-Free Workplace; Lobbying; Federal Debt; Misconduct-in-Science,
    Financial Conflict-of-Interest; and Smoke-Free Workplace. The
    current design offers a check box as to whether the institution has
    or does not have an assurance. To emphasize the importance of this
    information the suggestion was made to include dates that an
    institution "assured" each requirement. In cases where assurances
    needed to renewed, the system would notify both NIH and the
    institution of the pending renewal. This would allow action to be
    taken if the assurance or certification was not renewed in a timely
    way. Ultimately, if a requirement changed or a new requirement was
    added and the institution did not act upon it, the Commons would
    reject submission of the progress report by the Institution.

# Financial Report

-   There was no discussion of the financial status report as part of
    this CWG meeting.

# Notice of Grant Award

-   An issue that was raised by NIH involves the desirability of a
    Master Award Agreement. Implementation of such an agreement would
    allow for a lump sum award to the institutions at the beginning of
    the FY for all SNAP Commitments for that FY. The single master award
    would include an itemized list of which grants and how much for each
    is included. Implementation of such a process would require that the
    NIH system still generate individual transactions, and the Payment
    Management System would still show individual authorizations.

> Subsequent discussion focused on whether such an agreement would
> represent a saving in administration, or cause additional burden.
> Several issues were identified that would have to be addressed prior
> to implementation of such a system. For example,

-   How would revisions of individual awards be handled?

-   How would grant transfers between institutions (Type 7's) be
    handled?

-   How would project-specific terms be handled?

> Concerns were expressed about the need to separate individual award
> data at the Institution end to set up accounts. This could represent
> considerable additional burden over what is in place currently.

-   To study this possibility further, NIH requested that the CWG to
    gather pros & cons among institutional representatives. This will
    help work toward a more formal consensus that can be discussed as
    part of the next CWG meeting.

-   Subsequent to the current CWG meeting, Nancy Wray of Dartmouth
    provided further perspective as to how such a Master Agreement might
    be considered. Instead of an " award", maybe NIH would consider this
    as an "incremental funding notice" . It could be a website posting
    of the noncompeting yearly increments that grantees could access or
    ultimately be transmitted to grantees as a datastream. Any
    subsequent revisions could be posted/transmitted as incremental
    adjustment notices. It is asked that the CWG consider this idea as
    they gather more information of the value of this prospective
    approach to awards.

# Signatures

-   As was discussed in relation to the scientific portion of the
    progress report, there is also some desire to consider on a more
    general basis whether it would be possible for the entire
    noncompeting progress report to be submitted to the NIH either by
    the P.I. or following a limited institutional approval.

> Discussion continued to point up polarity that existing among both
> institutional representatives, as well as NIH staff. In light of this,
> and instead of expecting to reach any consensus that all would
> support, one possibility would be to allow each institution to choose
> the degree to which they would be willing to allow the P.I. to make
> the submission, or require full approval by administrative officials.
> The Commons software could easily be modified to accommodate this
> range of possibilities. In fact, the current version of the Commons
> offers a similar choice. Each institution can currently decide whether
> administrative users (A.O.'s and S.O.'s) have the ability to edit the
> scientific portions of the e-SNAP application.
>
> A recommendation made by the CWG is to consider a Pilot that would
> allow direct submission from PI (in line with NSF model) with AO
> notification (via e-mail), as well as tracking via the Commons Status
> interface. Alternatively, such a pilot might also include the
> above-mentioned option for the institution to allow or disallow
> submission by the P.I.

###### [Other Issues]{.underline}

> The following general topics were also raised as part of the
> discussion.

-   NIH may need to redefine what can be included in SNAP. This
    distinction becomes critical, and many times difficult to discern
    for projects that involve clinical research and/or clinical trials.
    In many cases (but not all) these types of projects require more
    detailed reporting/monitoring that SNAP is designed to support.

-   As an expansion of a point JJ made in his presentation to the
    Interface Specifications Subgroup, one way to think about the
    progress report submission is to separating administrative updates
    from science. Routine aspects of the project could occur separately
    from specific "events" that warrant immediate reporting. An
    outstanding issue that will need to be clarified in order to
    approach the progress report submission in this way is what
    constitutes routine from exceptional: what can be reported on an
    annual basis, and what would trigger an "event" report.

###### [Next Steps]{.underline}

####### In advance of the next meeting of the subgroup, several actions should be taken:

1.  Carol, Mary, and Marcia will provide a summary of the discussion and

recommendations.

-   These minutes represent such a summary. Further, a new iteration of
    the tabular presentation that Carol made at the meeting has been
    included below. The presentation has been changed to include what is
    perceived as the consensus for each of the areas of the noncompeting
    award, as discussed at the meeting.

2.  Carol and Marcia, as OPERA staff, will plan to meet with key NIH
    committees to float the

proposed changes in the noncompeting progress report.

3\. CWG members will solicit other representatives through their
respective institutions and professional

organizations (SRA, NCURA, COGR, FDP) to gather input and support for
the consensus that was

derived at the CWG meeting.

The subgroup agreed to convene the next meeting in conjunction with the
NCURA ERA VI conference in Portland, Oregon in August. Nancy Wray, the
program chair of the NCURA conference, will assist in finding a room and
designated time for us to meet.

# E-SNAP Pilot Recommendations from Commons Working Group (CWG)

On May 16, 2001 the Commons Working Group met with members of the NIH
eRA Project Management Team to share ideas for how best to reengineer
the e-SNAP Business Process. The chart below summarizes recommendations
generated from this discussion that will now form the basis for further
discussion within pertinent NIH functional groups; i.e., GMAC, POPOF, &
EPMC, as well as by CWG representatives through their respective
institutions and professional organizations (SRA, NCURA, COGR, FDP)

+----------+---------------+------------------------------------------+
| #### S   | **Current     | **CWG Recommendations (Pilot for E-SNAP  |
| cience R | (SNAP)**      | Business Process)**                      |
| eporting |               |                                          |
+----------+---------------+------------------------------------------+
| **Ab     | Part of       | -   No change in current business        |
| stract** | Competing     |     practice. Abstract will only be      |
|          | Application   |     required as part of the competing    |
|          | only.         |     application, with no formal process  |
|          | (Public)      |     for interim updates.                 |
|          |               |                                          |
|          | No updates    | -   Would remain available to the public |
|          | during        |     via CRISP                            |
|          | competitive   |                                          |
|          | segment       |                                          |
+----------+---------------+------------------------------------------+
| **       | Annual        | -   Retain rolling submission throughout |
| Progress | Submission 2  |     the year                             |
| Report   | months prior  |                                          |
| (PR)**   | to start date | -   Consider different submission        |
|          |               |     timing---30 days or perhaps 45 days  |
|          |               |     before start date (45 days preferred |
|          |               |     since it would cycle differently     |
|          |               |     from competing apps)                 |
|          |               |                                          |
|          |               | -   Allow submission of PR directly from |
|          |               |     PI as long as Authorized Business    |
|          |               |     Official gets either an automatic    |
|          |               |     cc: or notification via the "Status" |
|          |               |     system                               |
|          |               |                                          |
|          |               | -   Would remain "confidential"; e.g.,   |
|          |               |     not immediately released to the      |
|          |               |     public                               |
|          |               |                                          |
|          |               | -   Consider feasibility of submission   |
|          |               |     other than annual; e.g., 18 months   |
|          |               |     or 24 months. Could be a FDP Pilot,  |
|          |               |     may be deviation from policy         |
+----------+---------------+------------------------------------------+
| **       | Part of       | -   Have as a separate data area. Would  |
| Research | Progress      |     be bullets of science highlights and |
| A        | Report        |     other "Significant Changes"          |
| ccomplis |               |                                          |
| hments** |               | -   Require with PR but provide ability  |
|          |               |     to provide interim updates as well   |
|          |               |                                          |
|          |               | ```{=html}                               |
|          |               | <!-- -->                                 |
|          |               | ```                                      |
|          |               | -   Would remain "confidential"; e.g.,   |
|          |               |     not immediately released to the      |
|          |               |     public                               |
+----------+---------------+------------------------------------------+
| **SNAP   | Part of       | -   "Significant Rebudgeting" question   |
| Que      | Progress      |     already eliminated for all (with the |
| stions** | Report        |     2001 revision of the 2590)           |
|          |               |                                          |
|          |               | -   Three remaining questions; e.g.,     |
|          |               |     Changes in % effort, Changes in key  |
|          |               |     personnel, Unobligated balances \>   |
|          |               |     25%, would be eliminated as          |
|          |               |     individual questions.                |
|          |               |                                          |
|          |               | -   Still need to know about significant |
|          |               |     changes---those that might fall into |
|          |               |     the change-of-scope category. So,    |
|          |               |     instead of 3 questions, E-SNAP       |
|          |               |     instructions for PR would be         |
|          |               |     modified to require that these       |
|          |               |     issues be addressed as "Other        |
|          |               |     Pertinent Information                |
+----------+---------------+------------------------------------------+

+----------+---------------+------------------------------------------+
| ####     | **Current     | **CWG Recommendations (Pilot for E-SNAP  |
| Science  | (SNAP)**      | Business Process)**                      |
| Reportin |               |                                          |
| g (cont) |               |                                          |
+----------+---------------+------------------------------------------+
| **Cit    | Listed in     | -   Assumes citations will be part of    |
| ations** | annual        |     the Professional Profile (PPF) for   |
|          | submission &  |     each user                            |
|          | 1 copy        |                                          |
|          |               | -   Need to link PPF & Progress Report   |
|          |               |                                          |
|          |               | -   Need ability in the PPF to designate |
|          |               |     which are relevant to a particular   |
|          |               |     project                              |
|          |               |                                          |
|          |               | -   If entered as part of the Progress   |
|          |               |     Report, need to automatically update |
|          |               |     PPF (with edit check to eliminate    |
|          |               |     duplicate entries)                   |
|          |               |                                          |
|          |               | -   PI should only have to go to a       |
|          |               |     single site                          |
|          |               |                                          |
|          |               | -   Link to online journals for          |
|          |               |     published citations                  |
+----------+---------------+------------------------------------------+
| **Admini |               |                                          |
| strative |               |                                          |
| As       |               |                                          |
| surances |               |                                          |
| &        |               |                                          |
| Certific |               |                                          |
| ations** |               |                                          |
+----------+---------------+------------------------------------------+
| **Human  | Information   | -   For E-SNAP, shift the burden of      |
| Subjects | required with |     monitoring annual IRB review to the  |
| Assu     | annual        |     grantee.                             |
| rances** | progress      |                                          |
|          | report        | -   There would be no annual reporting   |
|          |               |     to the NIH as part of the progress   |
|          |               |     report                               |
|          |               |                                          |
|          |               | -   Institutions would have the          |
|          |               |     responsibility of assuring           |
|          |               |     compliance before any funds have     |
|          |               |     actually been drawn down.            |
|          |               |                                          |
|          |               | -   As part of the pilot, participating  |
|          |               |     Institutions would agree to provide  |
|          |               |     a retrospective annual list for NIH  |
|          |               |     review.                              |
|          |               |                                          |
|          |               | -   On the long term, monitoring of this |
|          |               |     could be handled as part of a        |
|          |               |     compliance site visit by either NIH  |
|          |               |     and/or OHRP. Some felt it            |
|          |               |     theoretically could be monitored     |
|          |               |     through the A-133 audit process.     |
|          |               |                                          |
|          |               | -   Discussion and support for having    |
|          |               |     assurance #s as part of the          |
|          |               |     Institutional Profile. Challenges    |
|          |               |     here include when multiple           |
|          |               |     affiliated institutions are          |
|          |               |     involved. May desire a               |
|          |               |     table/picklist type of field. In     |
|          |               |     many cases these are                 |
|          |               |     project-specific issues              |
|          |               |                                          |
|          |               | -   Suggestion to link institutional     |
|          |               |     profile automatically to OHRP lists  |
+----------+---------------+------------------------------------------+
| **Animal | Information   | -   Same recommendations as Human        |
| Subjects | required with |     Subjects                             |
| Ass      | annual        |                                          |
| urance** | progress      |                                          |
|          | report        |                                          |
+----------+---------------+------------------------------------------+

+----------+---------------+------------------------------------------+
| ***Admin | **Current     | **CWG Recommendations (Pilot for E-SNAP  |
| Issues   | (SNAP)**      | Business Process)**                      |
| (        |               |                                          |
| cont)*** |               |                                          |
+----------+---------------+------------------------------------------+
| **Other  | Signature on  | -   Incorporate the checklist of         |
| Admini   | Face Page     |     assurances & certifications as part  |
| strative |               |     of the Institutional Profile.        |
| As       |               |     (Includes: Civil Rights, Handicap,   |
| surances |               |     Age, & Sex Discrimination; Debarment |
| &        |               |     & Suspension; Drug-Free Workplace;   |
| Certific |               |     Lobbying; Federal Debt;              |
| ations** |               |     Misconduct-in-Science *\[with link   |
|          |               |     to ORI site for annual compliance    |
|          |               |     date\]*; Financial                   |
|          |               |     Conflict-of-Interest; Smoke-Free     |
|          |               |     Workplace)                           |
|          |               |                                          |
|          |               | -   Included would be dates an           |
|          |               |     Institution "assured" each           |
|          |               |     requirement                          |
|          |               |                                          |
|          |               | -   If a requirement changed or a new    |
|          |               |     requirement was added, no COMMONS    |
|          |               |     submission by the Institution would  |
|          |               |     be permitted until the Institutional |
|          |               |     Profile was updated                  |
+----------+---------------+------------------------------------------+
| **Other  |               |                                          |
| SNAP     |               |                                          |
| Issues** |               |                                          |
+----------+---------------+------------------------------------------+
| **F      | One SNAP      | -   SNAP Balance Question to be          |
| inancial | Question on   |     incorporated as part of PR           |
| Rep      | large         |     instructions to be addressed only as |
| orting** | balances      |     a change of scope indicator. No      |
|          |               |     longer a separate question.          |
|          | Quarterly     |                                          |
|          | PMS272        | -   NIH staff will continue to use PMS   |
|          |               |     272 reports                          |
+----------+---------------+------------------------------------------+
| **Notice | Total Direct  | -   Discussed Master Award               |
| of Grant | & F&A Costs   |     concept---lump sum award at the      |
| Award**  | for each      |     beginning of the FY which includes   |
|          | grant.        |     all SNAP T-5 Commitments for that    |
|          |               |     FY. Would include an itemized list   |
|          | (Non          |     of which grants and how much for     |
|          | -categorical) |     each is included. NIH system would   |
|          |               |     still need to generate individual    |
|          |               |     transactions. PMS would still show   |
|          |               |     individual authorizations.           |
|          |               |                                          |
|          |               | -   No specific recommendation to change |
|          |               |     current practice. CWG to gather pros |
|          |               |     and cons within the CWG as a next    |
|          |               |     step.                                |
+----------+---------------+------------------------------------------+