The Parker Institute for Cancer Immunotherapy (PICI) uses Veeva’s EDC in Vault CDMS to run more agile platform trials.
Gary Smith, the senior EDC programmer at PICI shares how to create dynamic cycles, visits, and forms with simple rules and configurations, and without custom functions. The following is an edited version of the original presentation.
Why oncology trial designs are complicated to build in traditional EDCs
ADVANCED PROTOCOL DESIGNS MADE EASY IN VAULT EDC
Traditional systems lack the architecture to segregate individual arms and manage different schedules. They need to build each cycle individually and require an amendment to add additional cycles or days to the study. This causes downtime to perform the migrations and testing. And all of that is required for post-production changes. With these systems, we need to manage matrices separately. And it's difficult to remember what form belongs in which folder. Also, cohort and treatment changes required multiple dynamics or custom functions to implement. All of this requires significant programming to provide the dynamics and edit checks to make the flow performed properly. Also, multiple matrices are required, which become difficult to track and test during QA. So, Veeva has a unique design structure that allows more flexibility and study builds. The building blocks that all systems need to build a clinical trial database are cycles, visits, forms, fields, but Veeva provides a design for speed and reuse of these objects. With this system, we can create repeating event groups with configurable labels. This allows easy deployment of changes. In addition, the rules engine is very powerful and easy to use. The nesting of forms in treatment cycles saves a lot of time in the study build. Using rules to place the forms in the right location is also a time-saver. Lastly, not having to create and test custom functions saves a great deal of time, effort, and money. Making changes to the design in Veeva is quite simple, like adding cycles, adding cycles and days to the studies, adding new arms, and jumping subjects from one to treatment group to another.
Veeva has a unique design structure that allows more flexible study builds
CONFIGURING DYNAMIC CYCLES, VISITS, AND FORMS
Veeva has a unique design structure that allows more flexibility in study builds. This slide shows the structure of the system. The study is designed much like other systems, but it's put together a little differently in Veeva. First you create the form, for example, let's talk about the vitals form. Then we create an item group. This holds the fields in the vitals form, like pulse, blood pressure, etc. Then we add the item group to the form, we add the form to the event. And lastly, the events to the event group. In this case, we call On Treatment Evaluations Arm A. An event group can contain more than one event, which are called with different requirements. So this is how we dynamically add forms to a visit. For each arm, we place all the forms that are used in that arm in one event group. And it is designated as a repeating event group. This allows the repeat maximum to appear, which can be modified post-production. The custom labels for the cycles and days are added, which are named for the protocol visit structure. Then the individual forms are populated using dynamic rules. And this is a screen grab of a typical rule that dynamically adds three forms to Cycle One Day One, in the High Arm when the user selects the date. So this is the only code that's needed. And we show here, that the sequence number is Sequence One, where if you recall, on the last slide, there is a sequence number next to the description, and then these particular forms are added. Now we have a screen grab of what the data entry screen looks like. So the custom label is dynamically applied, CD8 High Cycle One Day One, and this rule adds the body weight, prostate specific antigen, and the Nivo drug to Cycle One Day One of the CD8 High Arm. The disposition appears at each visit, so it was not marked as dynamic, which allows it to appear without calling it from a rule. So the event group cycle, each event group contains its own compartmentalized visit structure. Dynamic rules control whether visits and forms are added to a relevant arm or visit, like we saw in the last couple of slides. This is all achievable without custom programming. The event groups also enabled teams to minimize the effort associated with oncology design. Event groups can be marked as repeating, therefore teams can minimize the number required across the master protocol design. For example, a cycle could be built for Arm A, and set to repeat 15 times. Each instance can be uniquely named as appropriate using the custom label functionality. This approach to cycle design, significantly reduces the build and testing time and effort, and allows teams to easily extend the number of cycles in the study, by simply increasing the number of repeats. Any variation in visit and CRF data collected at that cycle, can be controlled via simple dynamic rules. We can start by creating an event group for one treatment arm, containing the super set of all visits and forms. Then cycles and days can be added for different cohorts. In this case weekly. Again, with bi-weekly injections, the visits and forms can be easily modified as well as weekly and biweekly.
A single schedule of events replaces hundreds of separate matrices
TRANSPARENCY AND CONTROL
So let's take a look at how the study schedule is created. First, let's look at some of the issues we face with older traditional systems. In older systems, creating the folders and matrices are time-consuming and cumbersome. In my last platform study using one of these systems, I needed to create 292 matrices to accommodate the folder and form structure for all of the arms and it was a three-arm study. With this many matrices, it's difficult to adequately test for the QAT. It's easy to get lost in the spreadsheet style layout when adding or removing forms from folders in a multi-armed study. This is an example of a spreadsheet that I needed to create to document what form was in what folder for our testers in an older traditional system. One of the many issues with this type of documentation is that it can't be printed and must be viewed in an electronic form. Veeva has a schedule editor that clearly shows what form is in each event group and each arm. This is what it looks like when you edit relationships. Here you can choose what form goes into each visit and the forms can be added, removed, modified, and reordered from one location. This all can be developed with the schedule editor tool that provides a single matrix for the entire study. The overview shows the schedule as it is designed. The schedule has two study parts and is set up as different repeating event groups. Part A: twenty-five repeating cycles. Part B has twenty cycles. And Part A has a day eight; Part B does not. The lightning bolt icons indicate that there's a dynamic in place. The green ticks are where the form will show without any dynamics. And the whole view is scrollable and can be reordered.
Updating configurations not code provides agility throughout the trial
QUICK CONFIGURATION CHANGES
Let's see how to make changes in a production study. The properties of the event groups, events and forms, can be edited from within this screen. Here in this event group is where we can update the repeating maximum to be more. For example, we need to change the maximum from 25 to 30 cycles. After that change has made a new dynamic rule or rules must be created to add the required forms. To add the treatment cycles, we open the existing event group, then add 20 more cycles, for example, modify the naming of the custom labels, and lastly, build new dynamics. So, the requirement for this could be, add these new cycles if the next visit date is populated or, if the question is asked, Start the new treatment cycle? = "Yes" and then you can dynamically generate the new treatment cycle related events and forms. In some of our studies the subject can jump from one arm to another, depending on certain circumstances, for example, lab tests. In a case like this, we write an edit check or rule that calls the forms, in the other arm's event group, which is generally triggered by an answer on a form. So, in this case, the subject, because of a lab result, jumped from CD8 low arm to CD8 high arm.