Proposed Agenda for CWG Meeting, May 16, 2001 Morning Session

1
Proposed Agenda for CWG Meeting, May 16,
2001Morning Session

• Consensus on existing interfaces
• Analysis of feedback from CWG members
• Commons V 2.0 Architecture
• J2EE Concept and Benefits
• Timeline for design and development
• Anticipation of V 2.0 Functional Requirements
• Institutional Registration DUNS
• Profiles Single point of ownership
• Status Improved Reporting to include
  institutional view

2
Proposed Agenda for CWG Meeting, May 16,
2001Afternoon Session

• Why is there a Noncompeting Award Process?
• Grants Policy Considerations
• Historical Perspective
• What weve tried before
• Proposed changes in current SNAP process
• Administrative information
• Scientific Progress Report and Related
  information
• Assurances and Certifications

3
Progress ReportingPolicy Historical Perspective
4
Scientific Reporting Requirements45 CFR Pt 74.51
(A-110)

• At least annually, not more frequently than
  quarterly
• Final report within 90 days after expiration
• Should include 1) comparison of actual
  accomplishments w/goals objectives 2) reasons
  why established goals were not met 3) other
  pertinent info e.g., cost overruns
• Should immediately report developments that have
  significant impact on the award-supported
  activities, including problems, delays or adverse
  conditions

5
Scientific Reporting Requirements(HHS GAM)

• HHS GPD 2.04 B.2 Optional Policy for
  Noncompeting Continuation Applications
• OPDIVs can accept progress reports in lieu of
  complete application packages when evaluating
  noncompeting continuation award.

6
Fiscal Monitoring (45 CFR Pt 74.52)

• Financial Status Report (SF269 or SF269A)
• Due 90 days after the end of each specified
  reporting period
• Annual requirement can be waived when PMS272 will
  provide adequate information to meet its needs.
  However, final FSR still required at completion
  of the project period
• Report of Federal Cash Transactions
  (PMS-272)--Quarterly submission

7
Efforts to Streamline Progress Report

• FDP T-5 Simplification Pilot
• Began 10/1/89
• Eliminated Budget Page (unless change of scope)
• Eliminated Other Support (unless changed)
• NIH Withdrew from pilot 9/30/92

8
Efforts to Streamline Progress Report (cont.)

• SNAP Phase 1 (FY 95)
• Eliminated budget page
• Eliminated estimated report of expenditures
• Added SNAP Qs on key personnel changes,
  significant rebudgeting, other support,
  unobligated balances gt 25

9
Efforts to Streamline Progress Report (cont.)

• SNAP Phase II (FY96)
• For T-5s, eliminated categorical awards (lump sum
  DC FA costs only)
• Simultaneously implemented total cost commitments
  for future years for all awards
• Also implemented most recent definition of
  significant rebudgeting

10
Efforts to Streamline Progress Report (cont.)

• SNAP Phase III (July 1996)
• Eliminated annual FSR--required only at end of
  competitive segment
• NIH staff uses PMS 272 as fiscal monitoring tool
• Still have 1 SNAP question that addresses large
  balances

11
Efforts to Streamline Progress Report (cont.)

• Revised 2590 (4/98)
• SNAP Process incorporated in instructions
• Eliminated Checklist unless change in performance
  site that affects FA
• 7/99 Amended instructions to include requirement
  of checklist if program income anticipated

12
Efforts to Streamline Progress Report (cont.)

• E-SNAP
• Development began FY97
• Pilot began 7/99
• Pilot concluded 3/01
• Revised NIH GPS (3/01)
• Redefined Significant Rebudgeting (now only a
  change in scope indicator)

13
Efforts to Streamline Progress Report (cont.)

• Revised 2590Proposed Changes FY01
• Changed name to Progress Report
• Eliminates concept of Application
• SNAP Q on significant rebudgeting eliminated

14
SNAP Progress Reporting
SCIENCE REPORTING CURRENT SNAP MASTER AGREEMENT IFA NIH REINVENTION CONCEPT
Abstract Part of Competing Application Only (Public) Same as Current SNAP Updated with Progress Report (Public) Updated Annually in the Fall (Public)
15
SNAP Progress Reporting
SCIENCE REPORTING CURRENT SNAP MASTER AGREEMENT IFA NIH REINVENTION CONCEPT
Progress Report Annual Submission 2 Months Prior to Start Date Same as Current SNAP Same as Current SNAP Anytime But Must Be Submitted in the Fall (Confidential)
Research Accomplishments Part of Progress Report Same as Current SNAP Same as Current SNAP Submit in the Fall as a Brief Narrative (Public)
16
SNAP Progress Reporting
SCIENCE REPORTING CURRENT SNAP MASTER AGREEMENT IFA NIH REINVENTION CONCEPT
SNAP Questions Part of Progress Report Same as Current SNAP Same as Current SNAP Not Addressed
Citations Listed in Annual Submission 1 Copy Same as Current SNAP Same as Current SNAP Anytime with Web Link to Publication
17
SNAP Progress Reporting
Administrative Assurance. Certifications CURRENT SNAP MASTER AGREEMENT IFA NIH REINVENTION CONCEPT
Human Subjects Information Required with Annual Progress Report Same as Current SNAP Once A Year Reporting on All Grants Not Addressed
Animal Subject Information Required with Annual Progress Report Same as Current SNAP Once A Year Reporting on All Grants Not Addressed
Other Signature on Face Page Same as Current SNAP Part of Agreement No Institutional Signature Not Addressed
18
SNAP Progress Reporting
Other SNAP issues CURRENT SNAP MASTER AGREEMENT IFA NIH REINVENTION CONCEPT
Financial Reporting Quarterly PMS 272 and FSR at End Competitive Segment Same as Current SNAP Same as Current SNAP Not Addressed
Notice of Grant Award Total Direct and Indirect Costs for Each Grant 1 Award for All SNAPs at 1 Time Same as Current SNAP Same as Current SNAP
19
IPF Number

• Basic Identifier for Grantee Institution
• IPF is absolutely fixed for grant award
• No IPF No Award
• 7 digits (8 available)
• Fixed relationship between IPF and EIN
• One to many (There may be several EINs for a
  single IPF)

20
IPF Limitations

• Not Universal unique only to NIH
• Limited number of combinations
• Will need to retool for 8 digits within the
  coming year
• Not easy to adjust to new institutional
  hierarchies
• e.g. institutional relationships with
  foundations, sub-campus hierarchies

21
DUNS Numbers

• Dunn Bradstreet
• Leading provider of business information for
  credit, marketing, purchasing, and receivables
  management decisions worldwide.
• 9 digit number ( 4 optional)
• 9 digits verified, 4 digits at institutional
  discretion
• e.g. university campus first 9, additional 4
  school/dept etc.
• Obtained free
• Via Web
• Confirmed by DB staff
• Verifiable on-lineanytime

22
DUNS Benefits

• Universal number adopted by 62 million businesses
  worldwide
• DUNS provides links to describe organizational
  hierarchies
• Used as identifier by U.S. Govt. Contracting
• Required for Central Contractor Registry
• Promoted by Federal Commons for grantee unique
  identifier

23
Current NIH Procedure for IPF Validation

• Entry of EIN number appearing on hard copy
  grant application via I2 RR interface
• Software business rule compares EIN with
  acceptable values for given institution
• If acceptable, application proceeds by
  assignment of corresponding IPF
• If no match, application purposely receives
  negative IPF (e.g. 1)
• Further processing requires manual confirmation
  of EIN, e.g. via telephone

24
Current IPF Implementation
IMPAC II
Grantee Organization
Paper Application Electronic Application
Assignment of IPF by DEIS staff to correspond
with one or more EINs
Entry of EIN to IPF specification in IMPAC II
CSR R R Interface compare EIN on form with
IMPAC II
Include EIN on Form 398
25
Proposed Implementation of DUNS
IMPAC II
NIH Commons
Grantee Organization
Paper Application Electronic Application
Assignment of DUNS number(s) by D B
Commons Registration

• . Verification of DUNS by IMPAC II Staff
• . Inclusion of DUNS in IMPAC II institutional
  profile

Creation/ modification of Commons IPF to include
DUNS numbers
CSR R R Interface compare DUNS on form with
IMPAC II
Include DUNS on Form 398
Log onto Commons with DUNS
Access to Restricted Commons Interfaces
eventual submission of electronic applications
26
DUNS Implementation Questions

• Necessary modifications to IMPAC II database and
  related interfaces?
• Necessary modifications to Commons database and
  related user interfaces?
• Outreach institutional awareness and receipt of
  DUNS numbers?
• Deployment of Commons to support extended use of
  DUNS?
• Must allow for transitional use of IPF and DUNS
• Must allow for tansitional use of DUNS on 398 and
  DUNS via electronic applications

27
Single Point of Ownership for PPF-Related
Information

• Premise
• PPF-related information name, address,
  expertise, employment record, educational
  experience, publications, funding record, can be
  likened to similar information found in a
  curriculum vitae. In this respect it must be
  treated as personal property. Without the
  expressed permission of the owner of the
  information, others should not modify such
  elements of a personal electronic record any more
  than they would modify a paper-based c.v. record.
  

28
Benefits of Single Point of PPF Ownership

• Data Accuracy Owner has most accurate
  assessment of information. Allowing any second
  party to change the information potentially
  affects accuracy
• Data Timeliness The owner is the first to know
  of any bone fide changes in the information, e.g.
  change in name or address. They can have the most
  timely effect to maintain an accurate record

29
Single Point of Ownership Benefitscont.

• Removal of Multiple Profiles Multiple profile
  records can be resolved (once and for all) with
  singly-owned profiles. This will save
  2,000,000/year currently being spent to resolve
  and remove duplicate profiles.
• Streamlining of Commons/IMPAC II Replication
  Replication design for Race conditions can be
  streamlined with singly-owned profiles. This
  also translates into lower operations and
  maintenance costs

30
Single Point of Ownership Benefitscont.

• Simplified Interagency Information Exchange
  Federal Commons-related information exchange will
  be more reliable with uniform singly-owned
  profiles.

31
Single Point of Ownership Drawback

• Inconvenience to IC Staff IC staff rely on
  preferred version of personal information.

32
Suggested Design to Accommodate Single Point of
Ownership

• Observe single point of ownership
• Profile creation yields unique IMPAC II person
  profile I.D.
• I.D. is immutable
• I.D. always points to same profile
• Can only be modified by profile owner
• Allow for NIH staff to create surrogate profiles
• Variants of any profile created by NIH staff
• Variant always bounded by singly-owned profile
  through IMPAC II person profile I.D.
• i.e., NIH view can change, but profile is constant