Death of Custom Functions

Custom functions are like mosquitos in that nobody would mind if they became extinct.

They evolved to supplement the functionality of Electronic Data Capture (EDC) systems. As protocol designs advanced and EDCs stagnated, the need for custom functions grew. Studies using a common legacy EDC today can require hundreds of custom functions, especially for oncology trials. Veeva designed Vault EDC to eliminate custom functions; and in 2021, Veeva’s new studies required a median of only two. This year, most studies in Vault EDC won’t have any custom functions at all.

Let me level-set on what custom functions are and why they are so pernicious in clinical trials. Custom functions are pieces of code written externally and loaded into an EDC system to perform an action. Effectively, they are coded workarounds to the limitations of an EDC. And most degrade your system performance, especially the complicated functions. The bigger problem is that custom functions are time-consuming to program, test, and validate. Plus, they add risk and fragility to the study, especially when making changes to the study or the system.

All of these challenges translate into staffing costs. Senior EDC programmers cost $225/hour or more. Assuming it takes approximately five hours for the initial programming, test cases, and writing documentation, it could cost over $1,000 per custom function and over $100,000 per study.

In the end, all this fragility and cost create a perverse incentive to simplify, or dumb-down, your study designs in exchange for higher reliability. But that runs contrary to the industry trend toward advanced designs that produce better trials, which places the burden of legacy technologies on the shoulders of data management.

Defining our Vision: Three Approaches to Eliminating Custom Functions

To eliminate custom functions, we engaged three different approaches to deliver equivalent functionality: 1) programming the rule within our rules engine, 2) making the rule configurable, or 3) eliminating the need for the rule all together. I’ll walk through each of the three approaches separately.

1) Programming rules in a powerful engine that’s easy to use

The rules engine was built specifically for clinical trials, hence we knew experienced EDC programmers would learn the rule syntax quickly and program checks faster than ever before. However, we also wanted technically-savvy data managers to be able to program common edit checks and basic dynamics. The interface provides tools such as intelligent auto-complete suggestions, point-and-click functions, and pre-defined casebook variables that simplify programming tasks.

As a result, users needn’t have deep programming and technical skills to script study rules themselves.

The steps required are shown below:

How it Works

1. Providing context. When specifying a rule, users first provide context by identifying the target form and fields using a point-and-click interface in which relationships have been established on the back end. Selecting a form surfaces all the related fields, including item names and descriptive labels. Clicking on a field loads it into the script editor. If the rule refers to other forms, users can search for any other form and click to select a related field.
2. Defining the expression. After establishing the context, users define the function to perform, whether that is mathematical, logical, or other. We have comparisons and determinations, calculations, and derivations. The function determines whether the rule will fire. For example, if the subject is female, take some action. If tumor size in visit Y is smaller than tumor size in visit X, then take some action.
3. Specifying the action. In the final step, users determine what action to take, or what the rule should do. They can choose from an expanding array of options in the system, such as adding visits or forms, firing a query, sending an email, or entering a patient’s calculated body mass index into the appropriate field.

Generally, rules will trigger one the following types of action (as shown in Figure 2):

• Data validation, which includes edit checks that generate queries.
• Casebook dynamics, in which data inputs drive corresponding outcomes, such as adding events, arms, cohorts, forms, and fields based on subject data.
• Automation, which encompasses actions that are performed downstream, such as sending emails, updating a subject’s status, driving payments, or deriving values.

If you are comfortable learning an easy form of clinical programming, then you can learn to write edit checks in Vault EDC.

2) Making Rules Configurable

A second approach for creating rules is to make them configurable, so no programming is required. In most legacy EDCs, univariate checks, such as making a field mandatory, can be configured. If a field is numeric, the EDC might provide a configurable range check, in which users simply enter the upper and lower bounds.

However, many rules are still focused on chronological relationships between the data, forcing companies to spend time and money to develop date comparison checks. Vault EDC eliminates the programming required for date comparisons by making them configurable. As a result, users need only specify the relationship between the dates as shown in Figure 3.

How it Works

In Vault EDC, within each clinical study, a date comparison tool displays every event that contains a date field. The user simply selects the initial date, specifies the comparison to make, and then selects the comparison date. For example, a user could click on the informed consent date, specify “cannot be after,” and then click on Day 1 to create a date check rule.

The system reads this configuration metadata and builds the rule in the background. Then, because the date comparison tools has been validated, there is no need to test configured rules. Thirty seconds of user configuration can replace 30 to 60 minutes of programming, testing, and validation.

3) Eliminating Rules All Together

Rules in Vault EDC are not just easier to create, there are also fewer of them. That’s right. Studies in Vault EDC have fewer total rules. How is that possible? Read our whitepaper on data-driven rules and dynamics to learn about the product features that have eliminated the need for rules.

Empowering People to Do More

By providing a powerful rules engine that simplifies clinical programming, we’ve equipped EDC programmers to write rules in a few minutes instead of a few hours. And technically savvy data managers are empowered to become casebook designers. They already know what they want to build—and now they have the tools to do it.