Agenda for CWG Meeting, May 16, 2001 Morning Session

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

• CWG Responses to Existing Commons Interface
  Specifications Survey Tool
• Commons V 2.0 Architecture
• J2EE Concept and Benefits
• Projected timeline for design and development
• Planned Deployment of X-Train v1.5
• Anticipation of Future Requirements
• Institutional Registration DUNS
• Profiles Single point of ownership
• Providing Customized Views of Application/Award
  Status Information

2
CWG Responses to Existing Commons Interface
Specifications Survey Tool

• General Comments
• Specific Issues
• Screen layout
• Text and Page flow
• Screen Functionality
• Navigation
• Help Features
• Other Functionality Needed

3
General Comments

• No surprizes many comments supportive of the
  current functionality
• Dated appearance
• Too large icons, not intuitive
• Too much wasted space
• Dated navigation and flow
• Too many menus too many links
• Help screens
• Text, context, FAQs need improvement

4
Specific Issues

• Screen Layout
• Smaller icons and graphics reduce wasted space
• Maintain contact with user in header e.g display
  user name and role
• Icons consistent in size and purpose
• Icons more descriptive of action
• Better alignment of rows and column when
  applicable

5
Specific Issues2

• Text and Page Flow
• Recommended changes in wording
• Improve descriptions
• Change wording to be more declarative
• Consolidate activities that relate to single user
• Administrative modifications
• Profile-related information
• Consolidate sub-screens with links into single
  screen
• Administration
• IPF-related information
• PPF-relate information

6
Specific Issues3

• Screen Functionality
• Need to incorporate better search capabilities
• For user administration
• For application/award status
• Clarify functions associated with specific
  links/icons
• Clarify file upload features
• Provide confirmation screens/pop-ups
• Confirm adherence to 194 standard
• Confirm purpose and use of information types
• Address types
• Human and Animal Assurance numbers
• Improve citation functionality
• Clarify do not save vs. reset actions

7
Specific Issues4

• Navigation
• Improve navigation icons
• Inter-module navigation
• Provide better navigation bar
• When necessary provide link to next screen in
  series
• Intra-module navigation
• Always provide navigation to previous screen in
  module
• Minimize need to go back to main menu
• Make navigation to help obvious (same location on
  every page)

8
Specific Issues5

• Help features
• Provide better context-sensitive contact
  information
• NIH IC staff
• Help desk live staff
• Use pop-up help to keep user on same screen
• Provide context-sensitive link to FAQs as part
  of context-sensitive help
• Improve help text and be sure context is correct
• Provide examples of acceptable field content
  format
• Consistent appearance of help on every screen

9
Specific Issues6

• Other needed features/functionality
• Redesign/define institutional hierarchy options
• Allow for definition of institution at school
  level
• Allow for definition (add/delete) at department
  level
• Provide more complete user administration reports
• Number of accounts by type, when created, when
  modified
• Session time, modules visited, last logon, when
  profile changes and how, password administration
• number of proposals submitted, upcoming
  application deadlines
• Comment field
• Revisit user types, roles, permissions, approvals
• Password for associates to access/assist

10
Specific Issues7

• Other needed features/functionalitycont.
• Improve creation of new user accounts
• Need better performance of unique person
  algorithm
• User-driven selection of correct person
• Consider having PPF as path driven
• Separate information by role P.I.-related info,
  consultant-related info, administrative official
  info,

11
NIH Commons

• Version 2.0

12
Current Architecture (Commons Version 1.0)

• Primarily 2-Tier Client Server

Web - External
Client Layer HTML, CGI-Perl, Steel Blue on
WEBSERVER (Presentation Biz Logic)
SQL
Database Server (Oracle DBMS),Stored
Procedures (Biz LogicData Access)
Commons Data
13
Considerations

• Cost-effective adaptation to business process
  changes
• Time-to-market
• Readily incorporate new technologies
• Protect IT Investment
• Integration with Federal Commons, others
• Scalable

14
Recommended N-tier Architecture
External Systems
Clients
Services
Data Services Layer
Database X
Database Y
Flat Files
15
What is J2EE?

• Specification
• Multi-tiered Distributed Application Model
• Provides the Containers for Components
• Component-based approach to the design and
  development of enterprise apps

16
N-tier J2EE Solution (Conceptual View)
Business Services Layer Application Server EJB
Container Security, Persistence,
Transactions Biz Logic (Java Beans)
XML
Web Forms EDI Files XML Files
Data Source Layer Object-To-Relational Mapping
Tool Access Engine (JDBC,ODBC), XML parser/loader
XML Files
Flat File/s-binary, ASCII
Oracle
Others
17
Recommended J2EE N-Tier Architecture
Presentation Layer
Web Container
JSP Engine
Java Servlet Engine
Browser html
Business Services Layer Application Server (EJB
Container)
IIOP
Session Bean
External Systems
Entity Bean
Entity Bean
Data Services Layer Object-To-Relational Mapping
Tool Access Engine (JDBC,ODBC)
E-mail
Flat Files
Oracle
18
Why J2EE??

• Open Standard
• Reusable Components
• Portable
• Leverage COTS versus development
• Protect IT Asset Investment

19
Organizational Structure

• Technical Management
• DEIS.NIH eRA Mgmt Team
• Z-TECH George Stone
• Logicon Advocates
• Silicon Spirit

20
First Step Define Technical Charter

• Build Commons Infrastructure
• System Services (Auditing, archiving, etc)
• Account Administration
• Profiles
• Develop Xtrain Version 2.0
• Evaluate Results ? Expand the Charter

21
Status - Completed

• Planning Phase
• Documentation
• eRA Technology Overview
• eRA Platform and Tools Recommendations
• eRA Project Management Plan
• Development Methodology (RUP, UML, etc.)
• Business Analysis
• Preliminary Tools Selection

22
Status - Next Steps

• Requirements Analysis
• Revisit Business Analysis
• Architecture Phase
• Development

23
Commons Version 2.0 Implementation Schedule
2001
2002
Apr May Jun Jul Aug Sep Oct Nov Dec Jan
Feb Mar Apr May Jun Jul Aug Sep
Commons Version 2
Phase 1 Infrastructure
Phase 2
X-Train 2.0
Admin Module
Profiles
Status
Phase 3
BPR only
SNAP Progress Report
BPR only
Competing Application (R01)
Legend Analysis
Development
Deployment
Start
Continuing
Includes business process reengineering and
design
24
Electronic Trainee Activities System (X-Train)

• Secure Interactive Web Site for statement of
  appointment, reappointment and termination notice
  of extramural trainees
• Program Director or Trainee to prepare
  appointment information
• Program Director to approve/edit appointment
  information
• Program Director to review and submit termination
  notice
• Integration/Replication of Information into IMPAC
  II
• NIH Staff to approve appointment with
  notification to Program Director

25
X-Train Version 1.5

• First pilot deployment of X-Train
• Similar functionality as Version 1.0
• Appointment, reappointment, termination
• Professional Profile information captured within
  the interface
• Uses Commons Version 1 technology
• X-Train Version 1.5 will serve as discovery
  vehicle for X-Train Version 2.0 requirements

26
Commons Version 2.0 Implementation Schedule
2001
2002
Apr May Jun Jul Aug Sep Oct Nov Dec Jan
Feb Mar Apr May Jun Jul Aug Sep
Commons Version 2
Phase 1 Infrastructure
Phase 2
X-Train 2.0
Admin Module
Profiles
Status
Phase 3
BPR only
SNAP Progress Report
BPR only
Competing Application (R01)
X-Train
Version 1.5
Version 2.0
Legend Analysis
Development
Deployment
Start
Continuing
Includes business process reengineering and
design
27
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)

28
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

29
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

30
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

31
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
32
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
33
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 transitional use of DUNS on 398
  and DUNS via electronic applications

34
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.
  

35
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

36
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 significant
  resources 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.

37
Single Point of Ownership Benefitscont.

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

38
Single Point of Ownership NIH IC Staff
Requirement

• NIH IC staff rely on preferred version of
  personal information.

39
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 versions
• Alternate version of any profile created by NIH
  staff
• Version always bounded by singly-owned profile
  through IMPAC II person profile I.D.
• i.e., NIH view can change, but profile is constant

40
NIH Commons User Types - Permissions
ERA Function/User Type S.O. A.O.
A.A. P.I.

• Create S.O. A.O. Accts. X X
• Create additional A.O. Accts. X X X
• Create P.I. Accts. X X X
• Review Sci. and Admin. Info. X X X
  X
• Update Sci. and Admin. Info. X X
  X
• Review Institutional Profile X X X X
• Update Institutional Profile X
• Review Professional Profile X X X X
• Update Professional Profile X X X
  X
• Submit Appl. To NIH X

Ability for SRO staff to prepare and/or edit
scientific information is an option determined by
individual grantee organizations.