The Kitchen Sink: See everything OpenClinica forms can do for you

In just thirty minutes, explore all of OpenClinica’s form capabilities, each doing its part to ensure better data, faster! See how skip logic, autocomplete, clickable image maps, real-time edit checks, autosave and a LOT more all work together on beautiful UX to drive cleaner data from the start.

Recording now available. Enter our webinar library.

Download the kitchen sink form (customers only)


What can cross-form do for you? (Part 3 of 3)

In the examples given here and here, our cross-form logic depended on data with a known location. In the first case, we knew exactly which event, form, and item to turn to in order to retrieve participate sex and date of birth. In the second case, each of our event dates marked the start of a unique, one-time event, so “finding their address” within the database was a straightforward process.

Now where did I leave that item value?

But what happens when we need to reference data with an indeterminate location, supposing that it even exists? In these cases, we may need to walk around a remote neighborhood, comparing building shapes and sizes, before we find what we’re looking for.

Consider a study that requires drug cessation if a certain adverse event recurs within 90 days. For an Alzheimer’s study, that adverse event may be detection of ARIA (amyloid-related imaging abnormalities) on an MRI scan. Suppose that a second presentation of ARIA within 90 days of the first means that the participant must discontinue study drug. What better occasion could there be for “checking the records” than while reporting a new ARIA? Checking the records here means:

  • retrieving the start dates of any previous AE whose report indicated ARIA
  • calculating the days’ difference between the most recent of the dates above with the new ARIA presentation date
  • showing an alert if that difference is less than 91 days

It’s hardly complex, but a busy CRC working with dozens of participants in multiple trials may forget to follow the process. Cross-form logic, on the other hand, never forgets. The screenshots below depict the result of a third AE report for a single participant. Of the two previous reports, the first indicated detection of ARIA on 1-Nov-2018.  Because the newest ARIA, on 24-Jan-2019, falls within 90 days of the prior one, the form displays instructions to discontinue study drug. 


The AE log for this participant shows two reports. The first, documenting an AE on 1-Nov-2018, indicates ARIA.
Here the CRC is reporting a new presentation of ARIA, on 24-Jan-2019. That date is fewer than 91 days after the previous ARIA of 1-Nov-2018. As a result, the form displays the relevant instructions from the protocol.

Few questions are too complex for cross-form logic to answer and act upon. If you can state a rule in logical or mathematical terms, you can most likely implement it using a straightforward expression, no matter how many other forms you need to reference. The OpenDataKit library of XPath functions offers a wealth of tools you can combine to create smart, versatile forms that collaborate with researchers.  So don’t let your innovation stop with drug development or study design: carry it through to your forms!

What can cross-form do for you? (Part 2 of 3)

In the previous post, we presented a cross-form example of clinical data collected in one event factoring into the normal lab range for a subsequent event. But clinical data aren’t the only factors that drive decisions. When an event occurred may determine when it should happen next. Dosing visits provide a common example. Depending on the protocol, dosing might occur at precise intervals (e.g. exactly 21 days between doses) or within windows (e.g. at least 7 days and no more than 10 days from the previous dose). Your EDC system should be able to enforce either type of scheduling, by reading not only the dates entered into forms, but dates found in form and event metadata.

In the example illustrated below, the form makes calculations between the start of a current event (“Dosing Visit 2”) and the start of the previous visit (“Dosing Visit 1”). According to this imaginary protocol, no fewer than 7 and no more than 10 days may elapse between these two visits.

  • If dosing visit 2 occurs within this range, the form guides the site-based user on how to prepare the dose.
  • If dosing visit 2 has a start date fewer than 7 days after dosing visit 1, the form displays instructions not to proceed, and provides the earliest and latest start dates for the visit.
  • Finally, if dosing visit 2 has a start date greater than 10 days after dosing visit 1, the form displays instructions to submit a protocol deviation note.

All of these calculations and feedback take place instantaneously.

For this participant, Dosing Visit 2 is within window.
For this participant, Dosing Visit 2 has been scheduled for too early a date.
For this participant, Dosing Visit 2, were it to occur, would happen beyond the 10 day maximum from Dosing Visit 1.

Up next: check for recurring Adverse Events

What can cross-form do for you? (Part 1 of 3)

Your study database has just locked. To celebrate, you decide to treat your two in-house monitors to dinner in the city. You’d like to offer your colleagues a choice of three restaurants. Take a moment and imagine which three restaurants you’d choose. Got it? Now suppose you recall that one of your monitors follows a gluten-free diet. Does that change your selection? If all of your initial picks specialized in wheat pasta, it ought to.

What’s good for dinner plans is essential for study conduct, when data quality and safety are on the line. An unremarkable value for height in one participant ought to trigger a query for another; for example, for a teen and a six-year-old enrolled in a pediatric trial. To evaluate the input in one field based on data in another, data managers rely on cross-field edit checks. If the fields are part of distinct forms, that evaluation is known as a cross-form edit check.

At OpenClinica, we extend this capability. We give data managers a tool to make their forms responsive to any element they choose from their database, from the participant’s most recently recorded blood pressure to the start date of the last dosing visit. Using easy-to-understand syntax in the form definition, data managers may reference any item in the database to trigger dynamic edit checks, make calculations, show/hide relevant information, and even change the content and logic of the active form. Your forms can now “know it all” to present a fully contextualized data capture experience.

We developed this feature to help our users:

  • capture more consistent, higher quality data,
  • drive protocol compliance,
  • highlight potential safety issues, and
  • mitigate the risk of unnecessary study procedures.

The capability goes far beyond cross-form edit checks. This is total study intelligence. Below is the first of three case studies we’ll present this month that illustrate the difference. If your study has requirements that resemble these, don’t hesitate to contact us for a more in-depth guided tour.

Case #1: Age- and Sex-Dependent Normal Lab Range

One person’s high blood pressure is another person’s normal. Why? The primary reasons are differences in age and sex. When it comes to lab results, “normal” may also be a function of the specific lab conducting the analysis. But not all studies rely on lab-specific ranges. For clarity’s sake, let’s imagine a study that will evaluate lab values against standards that are lab-independent. Known as “textbook ranges”, these ranges define the upper and lower bound of normal based solely on patient-specific factors. Below is a table indicating the lower and upper limits of normal for DHEA-S in adult males and females:

Chances are that a form associated with a screening event has already captured a participant’s sex and date of birth. A subsequent event may include a lab form. It’s inefficient to ask for the participant’s sex and age on this lab form. Sex has already been documented, after all, and age requires a calculation that compares the specimen collection date with the participant’s date of birth. Asking a CRC to make that calculation opens the door to error, especially if collection occurred close to the participant’s birthday. But age and sex information is required to determine whether an entered value is above or below the limits of normal.

Enter cross-form logic, which handily “pulls in” the required data from an external form. In the current case, an expression within the form compares the specimen collection date with the externally-supplied date of birth, to calculate participant age. That age, together with the externally-supplied sex and lower and upper limits indicated within the lab form, are all it takes to instantly evaluate the lab value against the appropriate range for the participant. Results of that evaluation may trigger or hide additional fields, get piped into question or response text for a separate item, or simply provide instructions, as shown in this video.


Up next: comparing event dates to ensure that dosing occurs within window.

Get better dates (in your eCRFs)

Dating is hard, especially if you’re not aware of the relevant conventions and etiquette. The same could be said for collecting date information in your EDC. As technologists enamored with data above all, those of us here at OpenClinica probably aren’t your best source for romantic advice. But if you’re searching for the most efficient way to capture unambiguous and properly formatted date information in your eCRF, prepare to swoon. Here are four tips for working with dates.

Tip #1: Allow for full and partial dates.

Requiring a full date when only a certain month or year are known to a CRC or participant is a major hazard for analysis. If that full date field is required, it’s quite possible that the user will select a placeholder for day of the month–the 1st or 15th, say–when that piece of information is unavailable to her. The value in the database, then, implies a level of specificity that wasn’t intended.

To avoid this pitfall, ensure that the individual entering the date indicates which portions are known and which are unknown (“UNK”). Then, offer the corresponding field for input.



During analysis, your statisticians will need to convert entered partial dates into imputed ones, using clear and consistent rules. So it’s important that your EDC support aggregating full and partial dates into a single item.

Tip #2: Offer a user-friendly UI that boosts accuracy.

Suppose that a participant knows that she took a dose of medication on the first Monday of the month. You don’t want her to leave the ePRO form in search of a calendar to retrieve that date. Similarly, for a CRC who prefers point-and-click wherever possible, you want a UI that works with her style, to encourage prompt entry. The same is true for a CRC who prefers to type.

Human factors like these impact both data quality and speed. That’s why they are a major design consideration for OpenClinica, and ought to be for you, as well. The datepicker shown here is the clear and flexible standard we rely on, supporting point-and-click, typed entry, and convenient scrolling through months, years, and even decades. Make sure your mechanism offers the same virtues.

Tip #3: Let your forms do the math.

Exclusion criteria for some trials require no history of a certain condition for a specified amount of time; for example, no history of melanoma for the last five years. In this case, performing the “date math” mentally may not pose a big challenge. But the situation becomes more complex when, rather than being disqualified, a potential participant is assigned to a particular cohort based on the date of some clinical event (or even multiple events). Error-free calculation then becomes as difficult as it is paramount. A capable form engine is your saving grace in these situations. Your EDC ought support real-time calculations, and respond in a protocol-compliant way based on the results. Use your system’s calculation and logic functions to hide or require certain fields, enforce eligibility rules, makes assignments, and otherwise ensure proper workflows.

For optimal viewing, expand the video to fill size using the arrows icon in the lower right-hand corner.

The example shown here employs skip logic and date math to assign a cohort based on the date that a CT scan confirmed the absence of melanoma. Three years or more of complete response triggers assignment to cohort A, less than three years to cohort B.

Tip #4: Follow the standards.

The final step when working with dates is to format them in accordance with a recognized standard. CDISC is arguably the most recognizable and robust. Following ISO 8601 standards, CDISC takes YYYY-MM-DD as its date format.

Portion of a CDISC ODM XML 1.3 extract from OpenClinica.

Register for “Good Form: Designing Your eCRFs for Better Data, Faster”

Want to maximize data quality and speed? Focus on your forms. From layout to item order, skip logic to edit checks, there are no “minor factors” when it comes to getting clean data from the start.

Understand these factors by attending our webinar, “Good Form: Designing Your eCRFs for Better Data, Faster,” taking place Monday, December 3 at 11am EST (4pm UTC). You’ll learn to look at your eCRFs through the eyes of your CRCs, monitors, and participants. You’ll see proven best practices in eCRF design that minimize queries and time to entry, while maximizing the integration potential of your data through standardization.

If designing study forms is among your responsibilities, you can’t afford to miss this webinar. Topics include:

  • The optimal form layout for different users, settings, and data types
  • Edit check strategies (e.g. how strict is too strict)
  • When to use pick lists, multi-select, radio buttons, likert scales, and more
  • Ensuring usability across devices
  • Building for import, automation, and eSource
  • … and more

Configurable roles, participant limits, and more now part of OC4

Starting today, data managers building their studies in OC4 will find a whole new level of control at their fingertips.  Our newest release allows data managers to:

  • Enforce a Participant ID naming convention of their choosing (e.g. [site number]-[participant ordinal])
  • Restrict users from adding participants once an expected number of participants is reached
  • Configure roles and permissions
    • “Clone” and apply a unique name to a pre-defined user role
    • Grant users of that role, and only such users, access to particular forms
  • Leverage REST API services to:
    • add a participant
    • add participants in bulk
    • export a list of participant IDs
    • import data into forms

While role configuration is arguably the keynote of this release, all of these features enable managers to exert fine-grained control when study size, design, or duration require it.

Participant ID Naming Conventions

Consider a large, multi-center study expected to enroll hundreds or even thousands of participants. In these cases especially, data managers, trial managers, and monitors need a compact, informative lexicon to quickly gain insight into study progress, put issues into context, and refer questions to the best source of information. A standardized, meaningful participant ID is a key component of that lexicon.

Enforcing a standardized ID in an OC4 study is simple. Just head to your Settings tab, edit the Participant ID Settings, and select System-generated as your method of ID creation. Then apply or adapt the template provided.

Using simple syntax, data managers can define a convention that makes an ID truly informative. When site users add a participant, the convention is automatically applied.  Following the example above, GER002-005 easily translates as the 5th participant enrolled at Site 002 in Germany. If participants GER002-005 and GER007-20 both show a randomization date of today, we can quickly and easily glean some useful information: at least 25 participants have been randomized in at least 2 activated sites in Germany, with Site 007 having randomized 4 times as many patients as Site 002. While users of OpenClinica Insight already have up-to-date metrics like this at their disposal, other users will now have an easier time extracting them from spreadsheets: it’s easy to parse out relevant information from a string in Excel when that information is always in the same place.

Participant Limits

Regulatory bodies frequently mandate enrollment caps in high-risk studies. Exceeding that cap then becomes a major compliance hazard. The latest release of OC4 offers a fail-safe to protect against that risk, which can be significant in fast-recruiting, multi-center trials.

When the checkbox below ‘Expected Number of Participants’ is selected, the expected number becomes a hard limit. No user can add a participant, whether at the site or study level, once the number of (non-removed) participants reaches that limit.

Role and permission configuration

Some forms are meant only for properly trained users. Cognitive assessment ratings provide one such example. Administering the MMSE or ADAS-Cog requires more than just knowing what those acronyms stand for. (Curious?) Those scales are only meaningful in the hands of trained cognitive raters. As such, a form including the MMSE or MoCA that’s available to any user with data entry responsibilities jeopardizes data quality and risks protocol deviations. The latest release of OC4 enables data managers to restrict access to these forms.

The first step is to tag those forms you need to restrict. You can customize the color and name.

Once created, you can apply the permission tag to all relevant forms.

Finally, you’ll create a custom role with permissions to access the forms you’ve tagged.

Custom roles are based on standard roles at either the study level (Data Manager, Data Specialist, Data Entry Person, and Monitor) or site level (Investigator, Clinical Research Coordinator, or site-specific Monitor). Customs roles come with the same core permissions as their standard counterpart. However, by allowing access to tagged forms, data managers enable only users with the custom role to access equivalently tagged forms. (These users may also access untagged forms.)

In the example above, only users with the RATER role have access to the MMSE and ADAS-COG forms. Other users will not be permitted to: open the form in edit mode, review-only mode, or read-only mode; view queries on the form; SDV the form; extract the form clinical data in a dataset or participant casebook; or view common event tables for the form on the Participant Details page. However, the clinical data can be piped (e.g. though a cross-form note or calculation) into a form that is readable by users without the RATER tag. In this way, read and write permissions are separable.

REST API services

The capabilities of our REST API continue to expand in this release as well. It’s not easier than ever to…

  • add a participant
  • add participants in bulk
  • extract a list of participants
  • import data

… through web services. OC4 uses the open source framework Swagger to help our users build and test their APIs. You can find the link on your study’s Administration page.

Last night’s release was the 5th overall since the creation of OC4 last year (not counting interim enhancements). It’s our most ambitious release to date, and in keeping with our mission to let data managers take total control with ease. As always, we welcome your input through the comments section below, and we look forward to continuing our close and successful collaboration with OC4 users. Not using OC4? Let us show you the power that awaits!

Dive into deep learning on October 16

We are excited to announce that MIT professor and MacArthur genius grant receipient Dr. Regina Barzilay will deliver OC18’s Tuesday keynote on the clinical applications of deep learning.

From every pixel of their MRI scan to each word in their medical chart, patients bring a wealth of data to their clinical trial or care journey. We can learn from this data? It may not be obvious to human minds, but neural networks trained on historic data and outcomes may be capable of producing models that predict, for new patients, everything from future morbidity to treatment fit. 

Don’t miss this fascinating talk. Register for OC18 while early bird rates are still in effect.

About Dr. Barzilay

Regina Barzilay is a Delta Electronics professor in the Department of Electrical Engineering and Computer Science and a member of the Computer Science and Artificial Intelligence Laboratory at the Massachusetts Institute of Technology. Her research interests are in natural language processing and the applications of deep learning to chemistry and oncology. She co-directs the pharmaAI consortium at MIT. She is a recipient of various awards including the NSF Career Award, the MIT Technology Review TR-35 Award, Microsoft Faculty Fellowship and several Best Paper Awards at NAACL and ACL. In 2017, she received a MacArthur fellowship, an ACL fellowship and an AAAI fellowship. She received her Ph.D. in Computer Science from Columbia University, and spent a year as a postdoc at Cornell University.

From multi cohort Phase I’s to integrated Phase III’s, FDA eyes efficiency

Two guidance documents, released a month apart this summer, suggest that the FDA is taking up a concern that sponsors and patients feel all too acutely: the need for speed.

That’s not a word anyone involved in clinical research takes lightly, with lives and knowledge on the line. But by issuing guidance on EHR integration in July, followed this month by guidance on simultaneous cohorts in Phase I oncology trials, the United States’ foremost regulatory body is placing a premium on efficiency. It’s not fair, or accurate, to claim that the policymakers at the FDA have never been interested getting safe, effective medicines to market quickly.  Like the population they serve, these policymakers are moms and dads, brothers and sisters, and patients. But they are also stalwarts of caution. That’s why their recent guidance communicates so much, even beyond its content.

First, what is the content? July’s guidance document, Use of Electronic Health Record Data in Clinical Investigations,  “clarifies [the] FDA’s expectations when EHRs are used as a source of data in [prospective] clinical investigations.” Unabashedly, the guidance “encourages sponsors and clinical investigators to work with entities that control EHR systems, such as health care organizations, to use EHR and EDC systems that are interoperable or fully integrated.” (The guidance defines interoperable systems as those capable of piping data from one to the other through a validated process. Think of a well-tested and well-documented API. Fully integrated systems, by contrast, “allow clinical investigators to enter research data directly into the EHR.”) Guidance sections with the most specific recommendations include those on:

  • structured and unstructured data (the first being preferred, but the second allowed if additional reliability and quality measures are in place)
  • validation (required for the EDC, but not for the EHR)
  • data from multiple EHR systems (“data from another institution’s EHR system may be used and transmitted to the sponsor’s EDC system provided that data sharing agreements are in place”)
  • ONC Health IT Certification for EHR system (“FDA encourages the use of such certified EHR systems”)
  • data custody and audit trails
  • maintaining the blind across all relevant systems
  • Informed Consent that makes the use of EHR data clear

The recommendations are sound, if not surprising. But the scope, which includes prospective studies but excludes postmarketing and registry ones, signals a focus on investigations designed to make new therapies available, or existing therapies available for new indications. A need, in other words, for speed.

What about the August guidance? Expansion Cohorts: Use in First-In-Human Clinical Trials to Expedite Development of Oncology Drugs and Biologics aims to bring order–and a seal of acceptability–to trials that are “intended to expedite development by seamlessly proceeding from initial determination of a potentially effective dose to individual cohorts that have trial objectives typical of phase 2 trials (i.e., to estimate anti-tumor activity).” These trials pose particular risks, most salient among them the possibility of exposing more participants than necessary to toxic or suboptimal doses. Because of these risks, sponsors should only consider an expansion cohort design for studies related to indications without curative therapies.  What’s more, to mitigate these risks, the guidance states that “it is imperative that sponsors establish an infrastructure to streamline trial logistics, facilitate data collection, and incorporate plans to rapidly assess emerging data in real time and to disseminate interim results to investigators, institutional review boards (IRBs), and regulators.”

Sections V, VI, and VII, dealing with considerations based on cohort objectives, statistical considerations, and safety considerations respectively, don’t lend themselves to summary, mandating study conduct requirements for physicians, pharmacologists, pharmacovigilance officers and biostatisticians. (To get a sense of the detail, note that both guidance on Food-Effect Bioavailability and Fed Bioequivalence Studies and Pharmacokinetics in Patients With Impaired Renal Function — Study Design, Data Analysis, and Impact on Dosing and Labeling are pre-requirements.) That such specific directives are issued here in a draft guidance hints at an urgency understood: getting quickly to Phase III safety and efficacy findings starts with a Phase I that can transition quickly transition to a Phase II.

Beyond the text of these documents, the FDA’s response to the industry’s need for speed is audible, and commendable. Why did the response (or so explicit a response) come now? We can only speculate. Certainly, the roads to knowledge are getting faster by the day. Just consider the early successes of machine learning. And despite some therapeutic victories, cancer is by no means in retreat. The will and the way are clear. The FDA has just supplied a good deal of the how.

Unsure whether your data capture system is build for speed? Versatile study build features, a robust API, and forms that drive “quality on entry” are all must haves.