Castor CDMS 2024.2.x.x Release notes
Discover the new features and updates included in the Castor CDMS 2024.2.x.x release.
Table of Contents
Major release 2024.2.0.0 - Release date June 12th
New features and / or enhancements
New interface for clinician side data entry
Accessing the new data entry interface
Any new study created after this release (v2024.2.0.0) will have the modern view for visits & repeating data instances enabled by default.
Existing studies
For eligible existing studies, the ones using SDV plans and the ones that do not use Monitoring at all, a new study setting option available.
This new setting was introduced to allow reviewing and validating the new interface, at your own pace. We recommend starting with a test study first, but we encourage adopting the new interface for your study as early on as possible, as it brings immediate added value and allows studies to continue benefiting from additional functionalities that will be rolled out with future iterations.
Castor will communicate in advance if any relevant changes will be brought to this study option.
An audit trail event will be logged every time this setting is toggled on or off. Reverting the study's data entry pages back to the legacy interface will trigger a warning, informing users about field configuration options that will no longer be available, due to technical incompatibilities with the old view.
For all other existing studies that have Monitoring but use the legacy SDV logic, due to compatibility limitations, enabling the new data-entry interface will not be possible and the above setting will not be visible.
General notes & improvements
Modern data entry setting
A new option called "Enable modern data entry” is available in the 'Study properties' tab of the Settings screen. Users that have access to the setting of studies eligible to see this new option will be able to try out the new interface on their study. A dialog is present when a user disables this, reverting the study's interface back to the legacy views.
Navigation
The form navigation, as well as the form's layout have been redesigned for data entry. All previous functionalities are present in the modern view.
Repeating data instances that are created and attached to a specific parent are shown in the navigation panel. A checkbox is presented on top of the navigation, allowing the user to optionally hide children instances that are of type 'adverse event', 'unscheduled visit' or 'measurement' from the visit view.
Please note that in order to also display instances of type 'repeated measure', this option needs to be configured in the "other" tab of the study settings page.
Repeating data instances that are attached and visible under a parent (a visit or another repeating data instance) can easily be opened to access all its forms and fields. As soon as repeating data instances have been opened, users can see a "Back to parent" button that helps navigate back to the previous page, where the parent was visible. This ensures an easy navigation between child and parent and allows for the data collection flow to continue seamlessly.
Forms/ visits / instances
In the navigation, each form, visit and instance can carry multiple icons, depending on the SDV, custom verification, signature, lock status it carries. The forms banners for custom verifications, SDV, lock and signature have been redesigned as well.
On the modern data entry views, users can now see the data collection progress bar in percentage added to Visit level. This progress bar is calculated based on all required and available data points in that visit, across all of its forms.
Repeating data instances that may be attached to the visits are not included. Their data collection progress is calculated and presented separately.
Similarly, we also display a data collection progress bar with number and percentage value for repeating data instances.
Custom verifications
Users with 'Verify' permissions can apply and remove custom verifications, if these have been configured for the study. When applying a custom verification, the user can decide if the verification status should be kept or dropped by the system with any value updates/ data change on that form or on the repeating data instance.
If more then 2 (two) custom verifications are available to choose from, these will be presented as options in a single select dropdown list. If less than 3 (three) exists, the users will see them as radio buttons, to allow a quicker final selection by the end user.
A banner is presented with information of each active custom verification that exists on a form.
Any available forms that are blinded for the user’s role are skipped from applying custom verifications. A warning toast is presented to the user when some forms have been skipped from the performed batch action. Any forms that are hidden by the automation engine are skipped from applying custom verifications. In this case, no warning is shown, as these forms are not available at all to the participants.
Lock & Unlock
Users with Lock permissions can lock or unlock a form or an entire visit / repeating data instance in the modern views. If the entire participant is locked, the lock/unlock actions are not allowed and therefore not longer visible in data entry.
We have improved the batch action for Lock and Unlock. Any forms that are blinded for the user’s role, or forms that have outstanding queries are skipped from batch action. A warning toast is presented to the user when some forms have been skipped from the performed batch action
Apply & Remove signature actions
The actions and flows to apply and remove a signature have been migrated into the react interface with feature parity. Users with 'Sign' permissions can add/remove signatures from visits, repeating data instances and forms. Users with 'Sign' & 'Lock' permissions can choose to additionally lock the entity while applying the signature.
It is required for the user to verify their account by authenticating themselves before applying a signature.
In the redesigned views of data entry, any forms that are blinded for the user’s role, that have outstanding queries or otherwise that are locked on studies that have 'Allow signing of locked forms' disabled are skipped from batch 'Sign' and 'Remove signature' action
A warning toast is presented to the user when some forms have been skipped from the performed batch action, showing all combinations of reasons from above (ie. in a visit with 3 forms, one form has outstanding queries, another is blinded and one can actually be signed).
Please note that if the participant itself is locked, then all actions corresponding to ’Signature', ‘Lock’, ‘Value missing’ are not allowed therefore not available in the interface.
Value missing / User missing
Any fields or forms for which value missing is not applicable or allowed to be skipped when “mark as value missing” is applied in bulk. Summary of changes:
- Any forms that are blinded for the user’s role are skipped from batch Value Missing action
- Any forms that are locked are skipped from batch ValueMissing action
- If the user has no Encrypt permissions and the form/ visit or instance contains encrypted fields, these are skipped from bulk Value missing
- A warning toast is shown once the action is completed and some encrypted fields have been skipped.
- Additionally, any forms that are hidden by the automation engine are skipped from batch Value Missing action.
Source data verifications
Source data verifications in the modern data entry views of repeating data instances follows the logic of SDV plans. All of the features and functionalities have been migrated over into the modern React framework.
Please note that the legacy logic of for source data verifications that predated the release of 'SDV plans' is incompatible with this view. Therefore, all studies that are still running their monitoring activities on the old logic cannot be migrated to start using the modern data entry views.
GCP Reason for change
The GCP enabled 'Reason for change' modal dialog has been migrated to the modern interface. Depending on the state of the form, additional information may be presented to the user regarding signature, custom or source data verification, as well as clearing data of dependent fields, where this is applicable in accordance to defined study settings.
Exclusion logic & validations
All configured validations will be triggered consistently within the new data entry interface. The Exclusion validation logic was migrated into the modern interface with no changes to its functionality.
Data collection on a single repeating data instance is prevented as soon as an exclusion validation message is triggered on a field in that instance. If an exclusion occurs on a repeating data instance form, data entry is blocked on that same instance, but not blocked on any other repeating data instances or study data.
If an exclusion occurs on a repeating data instance form, an exclusion banner is shown. Data collection on all repeating data instances of a single participant is prevented as soon as an exclusion validation message is triggered on a field in any visit.
Print
The "Print" functionality has been migrated and can be used in the same manner in the redesigned data entry views.
Fields
All field types and all field level actions and information have been migrated to the redesigned views to ensure feature parity and where possible or applicable, improved user experience.
The possible actions are directly available for users via a 3-dot menu presented at field level. Actions are shown in line with the user’s permissions for a specific site.
Some highlighted changes that can be seen now at field level are listed below.
The field icons for data collection have been updated and have a tooltip when hovering over them. A new icon was introduced, dedicated to showcase fields that have been marked as "missing value". Each field is bordered for better navigation within a form.
Comments
Users with "View" permissions can check and enter comments to fields using the dedicated action.
Queries
Query management is possible for studies that have the Monitoring module enabled in the same way it was possible up to this point. Users with 'View' permissions can view, reply to and update queries (status = Unconfirmed, Confirmed or Resolved), while users with 'View' and 'Query' permissions can create (status =New), reply to, update and close (status = Closed) queries.
History
Users with 'View' permissions can access the History option in the field menu in repeating data forms. All field value changes are logged and shown in the field’s history. For encrypted fields, values are always shown as *encrypted*.
Clear & Clear source values
The action(s) are not possible when the form, the instance or the participant is locked or otherwise when the form has an active 'Exclusion' validation.
Value missing / User missing
For clarity, this has been renamed to ‘Mark as missing value'
Source data verifications
Fields that are part of an SDV plan, but not yet verified, are highlighted with a blue SDV icon.
The Grid field
This now has an 'Expand' option, allowing users to better visualize the stored data when a larger number or rows or columns have been configured.
The repeated measure grid field
All previous configuration is possible alongside some improvements. A summary of this field type capabilities below
- entire configuration from the form builder is shown in the data entry forms (selected variables as columns, defined label for button, configured repeating data to add a new instance)
- if the grid field is configured to 'Show measurements of all visits?' , all instances of the configured repeating data will be displayed in the grid; otherwise, only the instances attached to the same visit where the grid field is configured will be displayed.
- the grid will show the total number of instances displayed
- values of encrypted fields are not shown in their respective column, the label *encrypted* is shown instead
- if the selected variables have a date, the expected date format of that site is used in the grid as well
- users with required permissions can create new instances from the grid field, can open the instance in form view and can return to parent view after, can can archive / delete instances from the grid directly
For locked participants or with active exclusions, the button of the Repeated Measure grid field is disabled.
Encrypted fields
Encryption works as expected in the modern visit & repeating data forms. When a form with encrypted fields is opened, a placeholder is shown instead of the value (default) for each of the encrypted fields.
The encryption key icon is now separated from the field level menu and other relevant field details. As long as the user has sufficient permissions, they will be able to more easily access relevant field actions or field information such as outstanding queries.
Users with required permissions can decrypt encrypted fields individually or in bulk from the form level.
- Decrypt permissions are required to see/access the collected data of an encrypted fields
- Encrypt permissions are additionally required to add / edit the collected data of an encrypted fields
Depending on the combination of individual permissions assigned to a role as well as the study's settings, the following may occur when encrypted fields are in use:
- If the study user has neither 'Encrypt', nor 'Decrypt' permissions, only the 'History' action is available.
- If user has 'Decrypt' permissions, but no 'Encrypt' permissions, the available, possible actions are: 'Comments', 'Add query', 'SDV' & 'History'
- If user has 'Encrypt' permissions, but no 'Decrypt' permissions, the available, possible actions are: 'Clear', 'Value missing' , 'Add query' & 'History'
Missing Value action & logic
Users with required permissions can mark each data point in any repeating data form as having 'missing value'.
Participant overview table of all repeating data instances
We have completely replaced the repeating data instances table presented at participant level, within the data entry view.
The change will be applicable to all studies.
The modern table allows displaying the custom columns on participant level, previously available only on the global / study level overview. Users can easily create new instances from the overview of all repeating data instances for a single participant, without having to navigate to anywhere else. The presented modal was updated for improved user experience.
More so, when creating multiple repeating data instances using the ‘Create and add another’ button, users can directly attach the new one to an instance created just before without having to close the modal or refresh the page.
Participant data export: Exporting data grouped by domain
In this release, we introduce domain-based exports, which allow you to reuse variable names in the export for multiple visits, repeating data, and surveys.
As part of the structure of your study, you can now specify a Domain (e.g., Vital Signs - VS) and Domain variable name (e.g., height) per field. The domain-based export 'regroups' variables by visit (including unscheduled visits and surveys), as well as by domain. Every domain is a separate export file (e.g., VS.csv), with each visit represented by a row (e.g., Visit 1) and the same types of variables grouped (e.g., height) in a single column.
Defining domains
- We have added a new Data standardization page under the Study design navigation item.
- On the Data standardization page you can see the domains added to your study, and add, edit, and delete domains.
- A domain consists of an abbreviation (e.g., VS) and a name (e.g., Vital Signs).
- When you edit a domain, you can assign fields to a domain (e.g., dem_height, and vis1_height).
-
After selecting fields, you can add domain-specific variable names for them (e.g., height for both fields).
- Domain-specific variable names have a maximum length of 32 characters, are lower case, and can only contain alphanumeric characters and the character ‘_’.
- An overview of the mappings between fields and domains can be exported from the page as well. The file contains the domain abbreviation, domain name, domain variable name, parent type (visit/repeating data/survey), and parent's name, as well as field information.
- We have added the option to assign visit numbers to Visits on the Study Structure page. This visit number will be used in the ‘Visit number’ column in the exports that are grouped by domain.
- We have added support for using Form Sync to synchronize changes in domains and domain variable assignments between a test and production study.
- We have added domain variable information in the Form Structure and Participant printouts, when the 'Additional info' checkbox is selected.
- We have added support for exporting domains and domain variable names via the Form Structure XML import & export.
Exporting data
We have added the option to export data grouped by domain in the Participant Data Export modal. If the CSV or SAS file type is selected, an option is presented to ‘Do not group data’ (default) or ‘Group data by domain’.
When data is grouped by domain, the exported file format follows the following structure, with one line per Visit/Repeating Data instance/Survey instance:
- Participant Id
- Participant Status
- Site Abbreviation
- Randomization Id
- Randomization Group
- Randomized On
- Participant Creation Date
- Visit name
- Visit number (as set on the Study Structure page)
- Type (Visit, Repeating data, Survey)
- Name (of the Visit, Repeating data, Survey)
- All dates (field values & metadata) are exported in YYYY-MM-DD hh:mm (date and time), or YYYY-MM-DD (date) format.
- Checkboxes are exported in the [domain variable name]_[option name] format, with a value of 1 representing a checked option, and 0 representing an unchecked option.
- Number and date fields are exported in the [domain variable name]_number and [domain variable name]_date format.
-
Grid fields are exported in the [domain variable name]_[row name]_[column name] format.
- Row and column names are cut off at 15 characters.
- Data marked as missing is handled the same way as our other exports.
- Form blinding permissions are taken into account while exporting data. In case the user is blinded, the related cells are empty in the export.
- View randomization permissions are taken into account while exporting data. Only randomization information from sites where a user has View randomization permissions for, are included in the export.
- In case variable names are generated, they are limited at 64 characters.
- A field variable list is added per domain ([domain abbreviation]_variablelist.[filetype]).
- If the user does not have decrypt permissions for the site the participant is assigned to, the encrypted value will be exported as *encrypted*.
Miscellaneous changes
Routing
We have updated our page routing system and some of the page URLs. Steps to ensure the most commonly used URLs will automatically redirect users to the new ones. If your study is using an external integration using our internal URLs, this might require a quick update on your part. You can read more about it in this dedicated article.
Audit trail / Validations
A new study level audit trail event has been included. The 'Validation status updated' event is logged every time a study user updates the validation status of a field found in a visit, repeating data instance or survey package invitation. The event can be opened to review additional details stored such as Validation type, Field ID and so on
Field configuration
Newly introduced slider configurations are available in combination with modern (react) visits & repeating data instance views. These configuration options are:
- updated 'Slider orientation'
- 'Show entered value'
- 'Display slider ticks'
- 'Show selection marker on left side before response is given'.
User Management
We have updated the 'All current sites' quick-select button in the Add/Edit User modal to 'All sites', now selecting all current and any new site.
Mobile SPIs
We have made it possible to assign a parent to a mobile survey package invitation. Next to that, when editing the invitation properties, the fields 'Email', 'Subject' and 'Invitation message' will be hidden.
Removed features and / or functionalities
Study settings
We have removed the setting to enable/disable modern web surveys for newly created studies, so web surveys will always be shown in a modern, mobile-friendly user interface. This change will not impact any existing studies. Existing studies will still have the ability to enable/disable this setting.
System defects fixes
Data entry
- We have addressed an issue that prevented loading data entry when some verifications were applied by a user with missing first or last name.
- In the 'Archive' modal dialog, we've updated the validation message shown to also include the maximum number of allowed characters.
- We have fixed an issue that resulted in the Reason for change dialog to display additional, irrelevant information regarding the form's verifications status after the status had been previously removed. This occurred in a specific situation only, when the “SDV all fields” option was being used at form level.
Monitoring
- Fixed a potential issue where structural changes that were followed immediately by an update of an SDV Plan could have caused some inconsistencies in the Dashboard views for studies with a large number of participants.
- We have addressed an issue that was sometimes causing errors when a user was moving a field from an SDV plan.
Participant data export
- We have fixed a defect related to retrieving that was decrypted using ZorgTTP. ZorgTTP credentials are now validated before being used to decrypt data during data-entry and export.
- We have fixed an issue in the Participant Data export where the '*encrypted*' placeholder was not showing up in the Date column of a Number & Date field.
Miscellaneous issues fixes
- We have addressed an issue that rendered a 500 error in the Study structure when a dependent field was deleted.
- We've fixed an issue in the Automation engine, where automations for web surveys did not account for Daylight Savings Time.
- We have fixed a visual issue on the interface, that resulted in having the icons and the text on 'My studies' page misaligned.
- We have resolved an issue where sliders that have no default slider position were not being displayed correctly in printables when there was no value selected.
- We have fixed an issue where a value of an archived survey could be updated through the API.
- Fixed an issue where in web surveys the exclusion error pop-up would always show in English, regardless of the selected language.
Hotfix release 2024.2.0.1 - Release date June 19th
System defect fixes
- We have fixed an issue that prevented users lacking 'Participant' management permissions from accessing the Participants and Repeating data views on live studies.
- We have fixed a defect that resulted in issues for the end user when expanding visits in the legacy interface of data entry.
Minor release 2024.2.1.0 - Release date July 2nd
New features and / or enhancements
API
- We have added two new API endpoints to expose triggered validations, either the validations for all participant (/study/{study_id}/monitoring/validation) or a single participant (/study/{study_id}/participant/{participant_id}/monitoring/validation).
- We have added a new (beta) API endpoint (/study/{study_id}/participant-progress/{participant_id}/repeating-data) to retrieve the process and status of repeating data (forms).
- We have added a new (beta) API endpoint (/study/{study_id}/participant-progress/{participant_id}/visit) to retrieve the process and status of visits (and their forms).
Castor Connect
- A new workflow is implemented to enable end-user to request & process a PIN reset of the ePRO mobile app (Castor Connect) without a third party involved (Site user). A new setting at the study level is created to select what workflow applies.
- Added support to configure the EQ-5D health box for Castor Connect through CDMS. The change to display it in the UI of Castor Connect will be done in a separate Castor Connect release.
System defect fixes
- We fixed an issue where gridfield values where not exported if duplicate row- or column names were present.
- We have resolved an issue where users of the modern UI could skip required pages within a form if repeatedly clicking the next button very quickly on a form with large numbers of pages and sub-forms (e.g. survey packages with many surveys).
Maintenance release 2024.2.2.0 - Release date July 15th
System defect fixes
- A defect on the legacy UI for data entry was fixed, that prevented the user from being automatically redirected to the newly created repeating data instance, when the 'Add repeating data' button was used in a form to create new instances.
- We have fixed an issue visible in the legacy data entry views, that was returning the user to the wrong form after having created a new repeating data instance from the "Repeated measure" button. If the user chooses to additionally add more instances after the first one was created, directly from the new instance page by clicking on the "Add another" button, the "Close & return" button will navigate back one view. If multiple instances are created as such, user can navigate back page by page until the first starting point (the form containing the "Repeated measure" field) is reached once more.
- We have reintroduced the search by instance name option in the participant level overview of all repeating data instances.
- We have fixed an issue that prevented the randomization modal dialog from being automatically closed when the user clicked on the "view form" icon.
- We have fixed an issue on modern data entry views that prevented opening the newly created repeating data instance when the starting point for the action was an "Add Repeating Data" button used in a form.
- We fixed an issue with error validation messages being displayed incorrectly. When the user inputs an incorrect password, the toast will now accurately show "Wrong password supplied.".
- We have fixed an issue that resulted in 'out of memory' error when trying to open repeating data instances that have been previously signed and locked by means of of bulk actions.
Maintenance release 2024.2.3.0 - Release date August 2nd
- We have improved the logic of some of our HTTP requests related to repeating data instances and their associated “Lock” and “Signature” banners to improve the loading time for extensive repeated data forms that are found on studies with a considerable number of active instances that are running on the legacy data entry interface.
- We have fixed a defect that prevented studies from being archived.
- We have resolved an issue where users were unable to edit the configuration of slider fields, requiring they create new fields or replace the original.
- We have fixed a defect where signature information was not being printed correctly for Repeating Data Instances.
- We have enhanced the loading performance of the Dashboard page, which should now load more quickly, especially for large studies.
- We have updated the logging of "Site ID" and "Updated By" information in the Audit Trail.
- We have fixed an issue in the underlying system, that resulted in OIDC SSO users being created in Castor Identity before these were invited to login for the first time.
Maintenance release 2024.2.4.0 - Release date August 26th
ePro/eCOA EQ-5D compliant VAS
- To facilitate the setup of a compliant EQ5D instrument, we have introduced a new slider configuration option for web surveys. This is not currently available out of the box but can be activated on demand. This new configuration option allows you to include the EQ-5D VAS in your web surveys and contains configuration fields specific to the EQ-5D VAS.
- When the 'EQ-5D' slider option is selected, participants filling in a survey will be shown a fully compliant and responsive EQ-5D VAS.
System defect fixes
- We have fixed an issue where users with full management permissions had access to data of fields hidden for their role in the 'Value change' overview in the Audit Trail.
- We have fixed an issue where users with full management permissions had access to the randomization number (note: not the randomization group) in the 'Value change' overview in the Audit Trail.
Hotfix release 2024.2.4.1- Release date August 26th
We resolved an edge case issue where it was not possible to update a field value when before and after the update a validation was active.