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. 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.