Summary

This article summarizes the key changes of the 24.1 release, based on the Release Notes content in the Technical File.

Updated Enrollment Configurations for Subject DOB

ClinSpark has a unique environment condition called ‘headless mode’. When this configuration is active, functionality is limited to features that enable late-phase study site setup and trial workflows. Features that are related to volunteer database management (further early-phase functions such as medical coding, lab/sample management, etc.) are disabled. Learn more about that here: Late Phase Multi Site Guides

For late-phase users of the system, an important feature in ‘headless mode’ is the ability to manage study site enrollment configurations. These are setup by system administrators and then used by study teams in the creation and management of study-sites.

Open

Administration | General Settings | Data Collection | Enrollment Settings

When managing these settings, a number of options are available for users to specify based on study specific enrollment requirements.

Open

Example of enrollment settings that can be configured.

Prior to this change, certain enrollment settings and default logic for determining birth month and day can results in either invalid or incorrect demographic collections. This was due to the default behavior where ClinSpark would ‘hard code’ 01Jan for the YYYY enrollment configuration. This had an undesirable downstream impact on study conduct workflows and device integrations that rely on subject demographics.

Now in 24.1, changes give study designers a greater amount of control towards what day and month of birth will be established with certain enrollment configurations.

Additionally, these settings will now also be present for site users who perform enrollments to know specifically what day and/or month values will be defaulted for workflows that require sites to only collect month/year of birth or just year of birth.

These changes help ensure DOB patterns match protocol expectations, reduce queries on incorrect DOB values on enrollments, and optimize site workflows by reducing the need for extra training or workarounds.

Other changes

There were not many other ‘visible’ changes in the release in terms of features immediately available to end users. However, it’s worth noting a few other enhancements that were made.

User Access & Audits

Customers often ask about reports or views in the application that support the ability to review user’s study access controls. Solutions that often get proposed are requests for custom reports built to interrogate user and study audits (and perhaps other areas) to determine what access users were granted over time. We also see potential to build better areas in the user interface to view this kind of information as well.

In 24.1, changes were introduced to establish an improved mechanism to detect and collect information associated with a given user account, related to actions or conditions that would impact effective permissions for study access. The result of these changes is an improved audit structure within the database, but not altering the existing audit tables and views in the user interface. These changes are focused on enabling the development of custom reports that can be built for purpose off these new audit records.

New services exist that evaluate security for all users and all study sites when changes to certain entities occur (for example, adding or removing study/site/role from a given user account). These can be computationally expensive though and may impact system performance under certain conditions. As such, the feature is disabled by default, and customer must opt into using it upon request. We encourage customers to reach out and discuss the performance implications of using this in the 24.1 release. The performance of the feature is intended to be improved and revised in later releases.

Processing Inbound Volunteer Monitoring Data

Certain device integrations utilize unique configuration parameters that enable them as ‘monitoring’ style devices. The data for these are often associated with volunteer records and are often brought into ClinSpark by way of workflows that rely on Agent or SparkPlug workflows. Some additional details on these kinds of device interfaces and configurations can be reviewed here:

Device Interfaces - Extra

On rare occasion, uploaded volunteer monitoring data parameters are sometimes not properly processed through inbound workflows, resulting in a scenario where it appears parameters are missing as part of the overall data set through certain exports (reports) and dashboard components. While engineering teams investigate these 'missing parameter' conditions, it can lead to the delay in further processing and reporting of the overall study data set.

Due to these challenges, 24.1 introduces improved logic into the mechanisms that process uploaded volunteer monitoring data to mitigate the condition from occurring and offer an ability for the uploaded data to be re-processed by way of Dashboard components. The release also offers more information accessible to engineers to investigate the root cause of these scenarios, reducing the support burden that these sometimes cause.