eRA OneView

1. eRA OneView Gateway to eRA

2. Agenda • Business Case • Functional Case • Prototype • Technical Case • Timeline

3. Business Case: Simplifying The Grant Process • Workflow begins with eReceipt • Downstream Processing – electronic instead of paper • eRA View should be consistent • Login • Notification • Managing requests • Support Different Processes • OPDIVS • ICs • Workload Management • eRequests – One Infrastructure for processing • Whether Application, Correction, Change of PI, • Regardless of user, PI to SO to SRA to PO to GS to PI/SO

4. Business Case: OneView Solution • OneView is an integrated approach to initiate and process all eRA transactions electronically • eRA Single Login: Same view for all users across all eRA applications • Workflow: Single interface to initiate and process a request with HHS and Grantee Community • eNotification: Single method for notification of actions/events throughout eRA

5. Dependencies on OneView • eSubmissions for electronic Corrections • eCGAP RR (currently has their own) • OPDIVs • Commons • Grants Management • Training Activities Note: Without a Centralized Workflow Solution each business area will need to build a customized solution.

6. Business Case: History • eRA Portal Prototype 2001 • eRA Project Team Retreat 2003 – Hot topics: (Workflow, SSO, eNotification) • Single Sign On Initiative Priority 2004 • OMB memorandum “e-Authentication Guidance for federal agencies” (M04-04 dated December 16, 2003). • Workflow Tool Evaluation & Elaboration 2004 • GM/OneView task order awarded April, 2005 • ACR/ARA (eRequest) task order awarded Sept., 2005

7. Business Case: Advocate Support • Project Team approved proposed solution on Feb. 9th 2005. • eRA teams are working closely with User Groups (OPDivs, R&R, SRAs, POs, GM, Grantees) who have invested time and energy in defining requirements for the following: • ACR & ARAs • Commons Electronic Requests • GM & PGM internal approval processing • User Groups are engaged in identifying upstream & downstream processing requirements to support electronic grant applications.

8. Business Case: Current Status • OneView in Test now (SSO, Workflow infrastructure, eNotifications) • User Admin in Test now to support SSO • Jan. ’06 OneView & User Admin Release to Production • Jan. ’06 ACR User Pilot in Stage • Feb. ‘06 GM, Closeout & Checklist integration with OneView.

9. Business Case: Future Needs • ’06 - Integrating all J2EE Applications with OneView • ’06 - Defining other types of eRequests • ’06 – ‘07 – Developing other eRequests • ’06 - Supporting Administration Tool Upgrade (User Admin Module) on the critical path • ’06 - Internal Routing and Approvals (GM & PGM) • ’06 – VOL (Org Hierarchy) • ’07? - Integrating with NIH SSO

10. Functionality: Solutions • Single Point of Entry to all eRA Applications • One step closer to integrate with NIH SSO • Integrated Home Page and Menu structure • Uniform Look and Feel • Immediate Access to assigned Action items and Notifications • Uniformed and Centralized way to submit and process electronic requests

11. Functionality: Solutions (Cont.) • Increased communications and content management of it – eNotification • Support of existing and upcoming electronic processes • Retirement of paper-based processes • Better Workload management • Increased data mining abilities for various processes and identification of bottlenecks • OPDIVs support • Centralized Rules for Validation and Processing

12. Functionality: Demonstration

13. eRA SSO • Single point of entry into eRA applications • First step to eventually integrate with NIH SSO • Facilitates easier and manageable deployments (e.g. easily separate IAR and Commons) • Centralized Menu integrates applications based on the user permissions • Authentication is outside the application code – industry best practices • Removes overhead-intensive authentication process – will help reduce the database and LDAP load • Provides a more flexible approach for implementing authorization • User can continue to use same userid/password for both C/S and SSO applications

14. eRA Workflow • Removes the inconsistent workflows out of the application code • Makes the actual applications light weight • Reduces new design and development cost - in time and resource • Performance & Ease of Use • Focuses the user work on the event based processes rather than expensive (database) searches • Manageability • Changes to the workflow does not require significant application changes (reducing the maintenance) • Configurable workflow provides flexibility to adopt changes in business processes • Centralized management of process definitions and its implementation • Seamless integration in and out of eRA applications enabled by SSO • Scalable and abstracted solution • Designed to migrate to other and emerging technologies • Vertically and Horizontally scalable middle-tier • Standard based business rules implementation • Easier changes in the business rules as the NIH policies change

15. OneView requirements don’t fit current technical implementation

16. Planned implementation meets OneView requirements

17. ProjectSchedule - 2005 Timeline

18. ProjectSchedule - 2006 Timeline

19. The Bottom Line • Are we going paperless? • Multiple task orders are dependent on the OneView workflow functionality • Current architectures does not support integration with NIH Single Signon • "This is the vision for eRA that I've been looking for."