Summary

The 23.1 release contains improvements supporting user account management, samples processing, study design, data collection, and recruitment workflows. It also contains security improvements and bug fixes. This article summarized several changes in the release, based on the Release Notes in the Technical File.

User Management

Changes were made user account management features, with regards to Site and Study restrictions. These changes were implemented as ‘opt in’ features, meaning, customers may choose not to use these features and continue managing accounts in current workflows.

Open

New options added to ‘update user’ workflows

When these configurations are established for a User, that User will not have any access to Studies and Sites until you explicitly grant them access in their User Profile.  

This article was also updated to explain these new changes and context on their use:
Restricting User Access

Preventing Item Length when Associated with Code Lists

Form locking validation has typically enforced that any defined Item length values match associated Code List string lengths. However, even after a Form successfully locks and is available for use, Item length values can be changed as well as associated Code List values, causing a mismatch in lengths. This means the form will no longer pass locking validation and cannot be used. This condition makes it incredibly difficult for design teams to determine where the offending Item or Code List exists. This can also cause issues in areas like cohort assignment activation, or when users want to add certain forms as unscheduled events in Data Collection.

Starting in 23.1, ClinSpark now prevents a length value from being defined on Items if there is a corresponding Code List. The goal is to ensure that study design teams are still allowed to freely modify code lists and other Item attributes as needed throughout a study after a form has been locked, without disrupting workflows elsewhere.

Open

Item Length field becomes unavailable when there is a Code List configured with the Item

Designing Study Forms to Support Sample Transfer and Lab Orders

Some customers experience challenges when required to process safety samples on site prior to sending to external labs for analysis. This may be due to unique protocol requirements or limitations on the receiving lab. When this occurs, the site would be expected to first process the parent tube (such as aliquoting or transferring) for the external lab. Sites are challenged to properly document and track these workflows to the same standards as PK samples, because the parent tubes (represented as Items in data collection) for safety draws are associated to a lab panel, but not any child tubes created during processing. Additionally, this raises challenges with the labeling and sites may be required to take on a “relabeling” process as a workaround. Workarounds and long-term challenges with external labs can be significant given the high volume of safety samples expected to be collected over time.

23.1 introduces functionality to try and address these challenges. With updated Item configurations and form designs, the successful completion of transfer processing steps with parent/child tubes will update corresponding Items. Additionally, the processing of these transfer tubes will also trigger lab orders.

Read more about how to use these new capabilities here! 

Improved Feedback When An Edit Check Fails

In prior versions of ClinSpark, if an edit check fails with an error, the application would not provide users context in the non-conformance message to the underlying error message. This could raise confusion as to why a particular edit check was failing and why the item is being marked out of range.

To improve the user experience and provide more information to data collectors that can be passed on to study teams who are responsible for programming edit checks, ClinSpark now shows the failure message back into the non-conformance message presented on the form Item.

This is a similar experience to what happens if an edit check returns a custom message. The overall goal is to ensure users are given greater context to why an edit check failed for a given Item, improve the visibility of the error message, and reduce support burdens with identifying root cause of edit check issues.

Further Restrictions on Actions Allowed for Locked or Archived Activity Plans

When studies are in a locked or archived state, few actions are expected to be allowed. In these study states, efforts are being taken to progress towards database lock and made only accessible to a limited set of users in the system. In 23.1, certain actions that were once permitted against activity plans in these study states are now prevented. This ensures that unauthorized or unintended changes against activity plans will impact the efforts leads towards database lock and end of study reporting. Users will still be able to access activity plans in a ‘read only' capacity and corresponding audits accordingly.

The full list of the restricted actions can be found in the Release Notes as well as in the dedicated article about database locking.  

Improved Sorting of Volunteers in the Recruit Module

A change was made to the way the Volunteers were being sorted in the Volunteer > Recruit module. Starting with ClinSpark 23.1, the default sort order will be based on date/time at which the volunteers were identified, then last name (with duplicates sorted on first name), then ID.

In addition to this improvement, we have added the “Identification” date to the Volunteer List in the Volunteer Column, as well as in the Recruitment Volunteer details that can be viewed here, if I click “Show” for a Volunteer and here it is in the “Recruitment Volunteer Details” section. 

Improving the Cohort Assignment Filter

Within the Study > Configure cohort management area, the assignment filter was impacted by a change made in the 22.2 release. Previously existing filtering capabilities against volunteer ID and study subject numbers were unintentionally removed.

The filtering capabilities have been fixed and brought back into alignment with the capabilities prior to the 22.2 release.

• Exact match on cohort specific assignment Subject number, case insensitive (example: S0001)

• Exact match on cohort specific assignment study subject screening / lead-in / randomization number, case insensitive (example: L0001)

• Exact match on cohort study site OID, case insensitive (example: ‘01' will return assignments with OID matching ‘01’ but not '012’)

• Exact match on volunteer ID (example: ‘78’ would return Vol ID matching ‘78’ but not ‘1278’)

• Partial match on assignment activity plan name, case insensitive

Going forward, we will continue to evaluate how these filters are used in cohort management workflows and review feedback from our customers to improve upon these capabilities further in later releases.

Fixing Subject Over-Volunteering Forms in Canceled State

We fixed an issue with cancelation workflows and Over-Volunteering forms in the Subject component. ClinSpark was incorrectly preventing users from being able to see canceled OV Forms in the Subject component, which was problematic if needing to quickly access or un-cancel the form.

It’s expected that for specialized ‘base’ forms of this type, interactions remain accessible via the Subject component, and not reliant on workarounds in the Study > Data component to interact with.

Going forward, even if an over-volunteering form is cancelled, it will remain accessible to users in the Subject component.

We’ve written a KB article in our service desk that outlines this condition as well, in case customers who have not yet up upgraded to the 23.1 release have troubles managing canceled forms.

https://foundryhealth.atlassian.net/servicedesk/customer/portal/9/article/3382312969

Security Improvements

Changes were implemented to enable stronger security checks for user authentication workflows involving password reset. Details regarding these changes are available in the Release Notes, accessible via Technical File for customers who are registered users of our service desk portal.