Stack 13: What's New?

Read-only User Role

The new Site Viewer and Study Viewer user roles provide read-only access in Study Runner. These user roles can view data but cannot edit, create queries, perform source data verification, or run extracts. These users have permission to view all forms unless permission tags are used to restrict their access.

Tabular Data Import

Tabular Data Imports have been improved with the following:

  • Match and Update: In addition to the Match and Skip functionality, you can now use match criteria to update an existing form instead of skipping it or adding a new form.
  • Set Form Status: You can change the post-import form status from Initial Data Entry (the default status) to Complete.
  • Configure Reason For Change: You can configure a reason for change to use when importing data into a complete form.
  • Configure Import to Use Columns: You can specify columns to use for the Event Start Date and Event Repeat Key when importing into repeating visit events. This allows you to schedule events as part of the import or update records in specific occurrences of repeating visit events.
  • Configure Import to Ignore Columns: You can configure the import to ignore specific columns that contain extraneous data you want to exclude from the import. For example, you might want to exclude non-clinical data such as metadata.
  • Bulk Actions Log: New imports appear on the Bulk Actions Log. Existing logs will remain on the Import screen. The downloaded Bulk Actions Log for tabular imports is now multiple files contained in a .zip file (instead of one file).

Note: Tabular imports previously used the endpoint /auth/api/clinicaldata/pipe. This has been deprecated and replaced with /auth/api/clinicaldata/import/tabular. The deprecated endpoint will still function, but any automated import pipelines should be updated to use the new one.

XML Data Import

XML imports can now be used to import attributes beyond clinical data. Queries, annotations, SDV status, and historical signatures can all now be included in an XML import. These can be imported in addition to the item data or separately from the item data. This can be used to assist in migrating complete data into OpenClinica, or to update these attributes in bulk.

Note: API endpoints have changed. XML imports previously used the endpoint /auth/api/clinicaldata/import. This has been deprecated and replaced with /auth/api/clinicaldata/import/xml. The deprecated endpoint will still function, but any automated import pipelines should be updated to use the new one.

Next Form Auto-Advance 

A new auto-advance feature can be configured for repeating common event forms in Study Designer. 

If enabled, it allows a data entry user to create another entry of the same form when they close or complete the first one. This makes data entry more efficient, as the user does not need to return to Study Runner first before beginning data entry on the next form. 

For example, if a study has a repeating ConMeds form configured with Allow Add Another checked in Study Designer, with data on one medication per form, data entry users will see an Add another checkbox at the end of the form. If the data entry user checks this before Clicking Close or Complete, they will automatically create the next ConMeds form and can begin data entry on it.

Form Engine Updates

These can be configured via Form Designer or the Form Definition Spreadsheet.

Dynamic Defaults

Dynamic Defaults allow you to set a starting value for an item that appears when a form is first started or for items in repeating groups when a  new repeat is added. Unlike items with calculations, items with dynamic defaults are not required to be read-only, so the user can change the starting value.

Triggered Calculations

You can configure an item have a calculation that is triggered only when another item's value changes. 

For example, you could set up a calculation to trigger only when a user clicks a checkbox to consent to participate in a study and have it calculate and save the timestamp of this action.

This is different from existing, non-triggered calculations which were evaluated at form load and throughout the data entry process to ensure they stayed in sync with the source values in their logic. Triggered calculations are also useful for setting initial values for items when they first become relevant on the form.

Unlike existing calculations, triggered calculations are not required to be read-only, so the user can change the calculated value.

Background Calculations

Items with no label or hint are now treated as background calculations instead of appearing on the form. This means you can set the data type of a background calculation item as needed.  For example, you can have an integer type item with a calculation but no label or hint. It does not appear on the form and performs a background calculation. This is like the existing calculate item type, except the data type can be fully defined.

Values and Labels in Audit Trail

For single-select and multi-select form items, the audit trail will now capture both the value selected and the user-facing label it corresponds to for each change. For example, if an item has code choices Red and Green with database values 1 and 2, the audit trail will now record a change from Red to Green as changed from Red (1) to Green (2). Previously the audit trail only captured the change as from 1 to 2.

This update only applies to data changes made after Stack 13's deployment. User-facing labels are also not listed for items using an external code list.

Performance Improvements and Bug Fixes

Performance improvements have been made throughout the system, including the following: the Participant Matrix, study publish, data extracts, scheduled rules, and Participate. This release also contains many other bug fixes and enhancements.

See full release notes for Stack 13 here.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.