ePIAF: D itching the Paper and Ink

1. ePIAF:Ditching the Paper and Ink David Gindhart Research Information Systems 2011 ACOR Retreat

2. Topics • Background • New process • Review of prototypes

3. Background • Project chartered by URC Subcommittee on Research Administration Innovation • Vision: Implement electronic proposal routing system to replace paper and ink signatures • Replace current PIAF with new “smart form” • Key features • Parallel, electronic approvals to reduce signature time • Simplified form and questions • New data fields (abstract, budget, NSF categories) • Paperless – all attachments uploaded • Notifications and reminders • Accurate record of approvals • FedEx-like status tracking

4. Proposal Started as soon as opportunity identified Completed prior to proposal submission Completed not later than 10 business days after submission PI, co-PI’s, Dept Head(s), Research Dean(s) review and approve Research Admin starts ePIAF PI & co-PI’s answer few questions AOR reviews and approves Opportunity IDEA Compliance Checklist PI can expedite award process by starting compliance activities early PI completes compliance activities (IRB, IACUC, etc) Award Compliance offices review and approve PI, co-PI, Dept Head(s), Research Dean(s) review and approve (if necessary) PSU receives notice of award from sponsor Research Admin completes additional required info OSP accepts award OSP negotiates award

5. Key Changes • Faculty will have to login and provide information prior to proposal submission • AOR must review and approve prior to proposal submission • Compliance issues addressed prior to award acceptance instead of account setup • AIAF process replaced by ePIAF • Clear rules on when new budget and/or ePIAF is required

6. Overall Project Schedule • Front-loaded with prototypes and reviews with URC, OSP, Colleges, Compliance Offices • Goal: Pilot in January with few colleges • Training following pilot • Full rollout in 2012

7. Development Schedule

8. Prototypes • Pictures of what we envision the system to be • Will review from perspective of: • Research administrator and AOR • PI and Co-PI • Department Head and Research Dean

9. Research Administrator Perspective • Tasks • Creating ePIAF’s • Review and approve (AOR) • Checking status of ePIAF

10. Entry Page • First page after user logs in (unless they clicked URL from email) • Action Required: List of proposals and awards that are in work and awaiting user’s approval. • In work: List of proposals and awards that the user is associated with (creator or approver) • Completed Proposals: List of proposals that have completed workflow process and are awaiting funding decision. • Completed Awards: List of awards that have completed workflow process and PSU has accepted.

11. Submission Type • Accessed when user clicks “Create ePIAF” from top menu. • Three Options • Create blank proposal. • Copy an existing proposal or award. Note that some fields will intentionally not copy over. • When a proposal has been funded, create an award from a proposal. Note that you can also create award from Completed Proposals tab on login screen. • This screen will likely change to “wizard.”

12. Proposal Basics • First page of ePIAF data entry. • Many fields can be pre-populated from SIMSbudgets. • Required fields must be filled out before the ePIAF can be saved for the first time. • Other tabs should be disabled before this one filled out or at least a warning that doesn’t let the user leave until required fields filled out.

13. Budget • Can be pre-populated from SIMSbudgets, otherwise requires manual data entry. • Budget with salary details (file) not accessible to co-PI’s and their Department Heads and Research Deans when reviewing and approving. • Budget without salary details accessible to all approvers.

14. Personnel • Names and % credit can be pre-populated from SIMSbudgets. • Department is not editable. • % effort is from first period. Check box if % effort varies across periods.

15. Waivers • Not viewable by PI and co-PI. • Waiver approval form only required if F&A is completely waived.

16. Proposal Info • Abstract or SOW should be cut and paste. • Proposal’s science should be allocated against the NSF categories by %, adding to 100%.

17. Human Subjects • When first entering, only top question is visible. If answered yes, rest of page appears. • Protocol #’s are optional at proposal time and required at award time. • Clinical trial questions only appear if type of research is Clinical Trial.

18. AOR Review • When a PI, co-PI, Department Head, or Research Dean is reviewing the ePIAF, a review interface is provided. • Header includes days to deadline (proposal) or days since award notification (award) to reinforce time constraints. • Approve Proposal button takes user to approval screen. • PI/co-PI’s do not see Waivers tab. • Investigators (and their Department Head and Research Dean) see only their financial/business interest answers. • Co-PI’s and their Department Head/Research Dean don’t see detailed budget.

19. AOR Approval • Approver will be presented list of approval/assurance statements based on their role and the details of the proposal/award. • For example, protection of human subjects assurance statement only appears to PI and co-PI’s if human subjects question is Yes. • Check boxes next to each approval/assurance statement default to unchecked.

20. Entry Page • First page after user logs in (unless they clicked URL from email) • Action Required: List of proposals and awards that are in work and awaiting user’s approval. • In work: List of proposals and awards that the user is associated with (creator or approver) • Completed Proposals: List of proposals that have completed workflow process and are awaiting funding decision. • Completed Awards: List of awards that have completed workflow process and PSU has accepted.

21. Workflow Status • Shows who is required and when they completed their action.

22. PI and co-PI Perspective • Tasks • Answering PI and co-PI-only questions • Review and approve

23. PI Inputs • Only PI will see this page. Each PI and co-PI will see their own page, not each others. • Only page that PI must fill out prior to proposal submission. All others can be filled out by research administrator.

24. co-PI Inputs • Only co-PI’s will see this page. Each co-PI will see their own page, not each others. • Only page that co-PI(s) must fill out prior to proposal submission. All others can be filled out by research administrator.

25. Proposal Review (PI) • Header includes days to deadline (proposal) or days since award notification (award) to reinforce time constraints. • Approve Proposal button takes user to approval screen. • PI does not see Waivers tab. • PI can edit if needed. AOR will be notified of their changes. • Investigators (and their Department Head and Research Dean) see only their own financial/business interest answers.

26. Proposal Review (co-PI) • Header includes days to deadline (proposal) or days since award notification (award) to reinforce time constraints. • Approve Proposal button takes user to approval screen. • co-PI’s do not see Waivers tab. • Investigators (and their Department Head and Research Dean) see only their financial/business interest answers. • Co-PI’s and their Department Head/Research Dean don’t see detailed budget.

27. PI Approval • Approver will be presented list of approval/assurance statements based on their role and the details of the proposal/award. • For example, protection of human subjects assurance statement only appears to PI and co-PI’s if human subjects question is Yes. • Check boxes next to each approval/assurance statement default to unchecked. • PI will be shown protocol-related answers to verify that those are correct.

28. Co-PI Approval • Approver will be presented list of approval/assurance statements based on their role and the details of the proposal/award. • For example, protection of human subjects assurance statement only appears to PI and co-PI’s if human subjects question is Yes. • Check boxes next to each approval/assurance statement default to unchecked.

29. Department Head and Research Dean Perspective • Tasks • Review and approve • Delegation

30. Proposal Review (Dept Head and Research Dean) • Header includes days to deadline (proposal) or days since award notification (award) to reinforce time constraints. • Approve Proposal button takes user to approval screen. • Investigators (and their Department Head and Research Dean) see only their financial/business interest answers. • Co-PI’s and their Department Head/Research Dean don’t see detailed budget.

31. Approval (Dept Head and Research Dean) • Approver will be presented list of approval/assurance statements based on their role and the details of the proposal/award. • For example, protection of human subjects assurance statement only appears to PI and co-PI’s if human subjects question is Yes. • Check boxes next to each approval/assurance statement default to unchecked.

32. Delegation • Department Heads and Research Deans can delegate their approval authority to multiple people. • DH/RD decided whether a delegate receives the same notification emails that DH/RD do. • Delegation can be for no more than one year at a time. • System sends out an email notification to delegate when a delegation is made. • Confirmation screen will pop-up because of sensitive nature of delegation.

33. Future Plans • Monitor metrics on approval timelines • Streamline and automate account setup process (AURA) • Track all pending reviews during negotiation period (not just compliance offices) • Incorporate related processes (subcontract request, waivers, etc.)