Electronic Submission Process for the IRB: Yale University

1. Electronic Submission Process for the IRB: Yale University Adam Schechter, PhD Coordinator: Systems, Compliance, Education Human Research Protection Program Yale University

2. Goals • To identify the main elements of the electronic submission process as it applied to the IRB. • To demonstrate the process for creating routing maps, business rules, and meta-rules. • To show how an institution’s particular business practices can be designed in the Coeus system. • To illustrate the Yale experience as an example throughout.

3. Electronic Submission: The Basics • The main purpose of electronic routing is to simulate an IRB’s business practice with paper submissions. • Routing is the process of electronically moving a protocol submission through the various required review components of an institution. • Rules are tests that determine how the submission will be routed.

4. Initial Swimlanes • At Yale, the established paper submission process involved not only approval from the HIC, but also approval from other committees and offices external to the HIC. As such, these needed to be incorporated into the electronic routing schema where appropriate:

5. Example: Yale School of Nursing (Draft)

6. Maps • Unit Hierarchy • Routing is dependent upon a well-structured hierarchy

7. Maps • Maps are tied to a unit • Each unit can have multiple maps

8. Maps • Maps are made up of stops or levels. • Stops are made up of one or more users. • Each level of the unit hierarchy can have maps. • Within the hierarchy each unit’s rules will be evaluated and the appropriate maps are inserted into the routing.

9. Maps • Users are placed in “stops” in each map. • Within each stop, users can represent approvers or alternate approvers.

10. Maps • Maps can utilize multiple levels within which stops and users can be placed by requirement.

11. Maps • And from the Lite side:

12. Business Rules • Roles that can setup business rules: • Business Rules Maintainer – Department • System Administrator – Department • Application Administrator – Research Office

13. Business Rules • Business rules are the nuts and bolts of electronic routing. • They also represent the various components of the swimlane diagram we saw earlier. • When creating a business rule, you can choose from four types: • Notifications • Questions • Routing • Validation

14. Business Rules • Note that Functions, Questionnaires, and Columns can be used as conditions to build business rules: • Functions: Developed at the database level with the capacity to execute a true/false query and return the result. • Questionnaires: Developed within Coeus by combining (pre-generated) questions and returning user responses. • Columns: Simple values found in specified code tables in Coeus.

15. Business Rules • Here is an example of a business rule “shell”:

16. Business Rules • As with any logic proof, business rules can be built upon and modified depending on the conditions and functions that are incorporated. • For instance, a very basic business rule might require any protocol submission to be reviewed by a particular group of people (identified by the maps we discussed earlier). In this case, the business rule would look like this:

17. Business Rules • Note that the function “All Protocols” was used in combination with the conditional “Equal to” and the truth value “True”, along with the selected map “Triager”. • In plain-speak, the rule says that whenever any protocol submission is submitted electronically to the IRB, it must be routed to the “Triager” map in order to await review by the people associated with that map. • The submission is also routed to each reviewer’s inbox along with the basic protocol information and the date of the submission.

18. Business Rules • If we were to create a business rule with two conditionals, it would look like this: • In plain-speak, this business rule indicates that when a submission is the initial submission for a protocol and a subject population of “children” (pre-selected) has been chosen by the investigator, the submission should route to the “Regulatory/PPRC Scientific Review” map.

19. Business Rules • And from the Lite side: + =

20. Business Rules

21. Business Rules • If we add the previous two conditionals together, we get the following “if-then” business rule: • Again, in plain-speak, this indicates that if a submission meets the criteria for “Test Rule 2” (first submissions and children, it should route to the “Regulatory/PPRC Scientific Review” map. Otherwise, all submissions (including those in Test Rule 2) should be routed to the “Triager” map.

22. Meta-Rules • Once business rules have been established within a particular route, meta-rules can be used to organize and prioritize them as necessary. • At least one business rule must be present in order for a meta-rule to be created for a unit. • A unit can only have one meta-rule for each type of rule (Notifications, Questions, Routing, Validation). • Three “Rule Criteria” are used in the creation of meta-rules: “Next”, “If True”, and “If False”.

23. Meta-Rules • For example, choose which of your available business rules will serve as the “Parent Node” (i.e., the first one used):

24. Meta-Rules • Next, follow the same procedure for “Child Nodes”, each of which should exist in a pre-determined order under the Parent Node, following the logic of the Rule Criteria. • So, if a node is selected with “Next” as the criterion, it will automatically follow the previous node without any assessment of truth value. “If True” and “If False” will verify truth value before sending the submission to the next node, accordingly:

25. Testing • As always, testing is extremely important to the development of a good routing schema. • The more a tester can mimic the possible actions of both Lite and Premium users, the more confident she can be that the routes will work as expected once they hit prime time. • In this way, having clearly defined roles (user, administrator, approver, etc.) for each of the testers involved can only help ensure that the test will be as successful as possible. • It is also important to have as many of the “real world people” as possible involved in the testing process. For instance, if an external review committee will be reviewing protocol submissions involving children, inviting actual reviewers from that committee to participate in the route tests will both emulate the Production instance and provide de facto training for the reviewers as well.

26. Education & Trainings • There are three main groups to focus on when providing training for newly-created routes: • Department Users (Research Community, Lite) • Technical Users (IRB Administrators, Premium) • Tangential Users (External Committee Approvers, Both) • Each group requires a carefully tailored explanation not only of the technical “how-to’s” involved in the routing functionality, but also of their respective roles in the bigger picture of the electronic submission process.

27. Education & Trainings • A variety of materials can be used for good education. Here is a (non-exhaustive) list of some effective ones: • Comprehensive manuals for administrators and end users. • Quick guides offering abbreviated “how-to” instructions on individual topics. • Correspondence (usually by email) to the community at large notifying them of the pertinent details of the release. • Large group training sessions with the purpose of outlining the updates/changes/enhancements forthcoming. • Small group training sessions with the purpose of offering individualized assistance for users. • Multimedia-based presentations or training sessions offered on a website.

28. Education & Trainings • Yale’s HRPP utilizes all of the above methods for training where possible. Here is an example of the website we use to provide our end users with updated information and training materials:

29. Go-Live! • Once it is clear that the electronic route is accurate and the potential users are trained, the route can be placed into Production. • A good method for “testing” while in Production is to begin routing with a Pilot group first. This may require initial and subsequent refinements to the various components we’ve discussed so far. • Keep in mind that as user groups grow, office procedures change, and system enhancements are released, routing should be viewed as a malleable process. Don’t assume that because your routes work now, they will work without tweaking for years on end.

30. Thanks! Adam Schechter, PhD Coordinator for Systems, Compliance, & Education Human Research Protection Program Yale University adam.schechter@yale.edu (203) 737-5564