Major Release 2025.2.0.0 |  Planned Release Date:  July 1st 2025

        Please note that these release notes are preliminary and may be subject to updates.

New features and / or  enhancements

System Access | New Browser & Operating Support Policy

Study teams (clinicians, researchers etc.) accessing CDMS with an unsupported browser or operating system (OS) will now be blocked from logging in and shown a clear error message. This ensures a reliable experience by enforcing access only through allowlisted environments. This change is applicable to all CDMS users that are required to log into the system.

Two new messages have been introduced as part of Castor's Browser and Operating System Policy enforcement for study teams.  If both the OS and browser are unsupported, the OS message takes priority.

Unsupported Browser Message:

Unsupported OS Message:

Note: The above messages apply only to clinician-facing CDMS interfaces

For study participants accessing CDMS functionality (web-surveys), dedicated new messages will only be active by default for new studies created on or after July 1st, 2025. This means that, while the policy is still applicable, participants from existing studies will not encounter these upgrade messages regardless of their browser/OS combination. Upon request, our Support team can activate the warning screen functionality for existing studies.

Supported and validated versions for v2025.2.0.0

Clinicians:

• Chrome 125 or newer
• Microsoft Edge 124 or newer
• Firefox 127 or newer
• Safari 17 or newer (macOS)
• Safari on iOS 17 or newer

Participants:

• Chrome 125 or newer
• Microsoft Edge 124 or newer
• Firefox 127 or newer
• Safari 17 or newer (macOS)
• Safari on iOS 17 or newer
• Samsung Internet 27 or newer

Validations Management

A new "Validation" permission has been introduced, to give study admins more granular control over who can manually update validation statuses, without granting full query rights. This permission is now visible and assignable in the Roles and Permissions overviews, with dedicated tooltips for clarity. For all existing studies, roles with the “Query” permission have automatically received the “Validation” permission to ensure a seamless transition. This update improves compliance and role precision across both legacy and the modern Validations logic.
All changes are logged in the Audit Trail.

We have added a new "Confirm validation updates" setting in the ‘Good Clinical Practices’ tab. Enabling this study setting will require a reason for manual validation status edits and will add a static system generated reason for any automatic changes of the validations status (i.e. when a validation is auto-closed after a value update event). This setting is going to be enabled by default for all new studies, but kept disabled for existing studies to prevent any workflow disruptions. Existing studies can opt in by simply toggling it on, as it enhances traceability.

To strengthen audit traceability and compliance, users updating validation statuses in studies with the “Confirm validation updates” setting enabled will now be prompted to enter a mandatory reason for change.
This reason is logged in the Audit Trail. 

For system-triggered status changes, the static note "Automatically updated by the system" is recorded automatically. For studies where the “Confirm validation updates” setting is disabled, the status updates can be completed without inputting a reason.

Users can now update the status of Information and Warning Validations directly within the CRF views in modern Data Entry, eliminating the need to switch to the Validations overview. If the user does not have 'Validations' permissions, the status button will be read-only. If Monitoring is disabled, thin this will not shown in Data Entry.

Status changes are permission-based, logged in the Audit Trail, and reflected instantly across all views with confirmation toasts. If Monitoring is not enabled for the study, validation statuses remain read-only. This update streamlines workflows for data managers and monitors by reducing clicks and context switching.

Applicable only for studies using the newly released using the updated Validations logic (CDMS v2024.4.0.0): 

Validation status updates now include a full change history within the status update modal. Users can view the status change history including who made each change, when it was made, and the reason for it, if the “Confirm validation updates” setting is enabled. For studies without the setting enabled, reasons are omitted or marked as “N/A.” 

Entries are listed from newest to oldest, providing transparency and auditability directly within the workflow. 

A new button-based trigger replaces the old dropdown, aligning with the improved user experience.

For studies that have not adopted the new Validations logic, the validations status change flow remains as before. Only some visual changes apply.

Form Sync

We’ve expanded the Interim Data Impact Report for studies using the new Validations logic to show how structural changes might affect participant data validations. A new column, data_validation_impact, has been added to the structural_changes.csv file, and detailed participant-level impacts are available in a new data-validations-impact-per-participant.csv file. 

This enhancement helps study designers anticipate and minimize validation disruptions before merging updates to production, supporting better study quality and decision-making.

In this new report file, we preserve the granularity of the detected changes and their predicted impact as before. This means that for each change to validation configurations, the system evaluates the impact at the most granular level.

Since this is a preview report, it shows the individual impact of each change independently. In reality, once both changes are merged together into production, and validations are fully re-evaluated, the system might retain or reset the validation differently based on the combined final expression.

Form  Builder 

We have standardized the date format in Form Builder field previews to ISO format (YYYY-MM-DD) for clarity and consistency. A tooltip now informs users that data entry formats may vary by site settings.

We have made additional changes to the Form Builder page to make better use of the available space, given longer field labels and/or smaller screen sizes. Returned results in the search list are ordered alphabetically within each section.

We have extended the interactive preview in the Form Builder to also cover template-based fields (i.e. calculation, summary, QR). Users can now view the configured template and test it with dummy values directly in the field preview, in the same way that is available in the Calculation helper tool.

• When expanding a field card, you can now immediately see the configured template, input dummy variables (up to six), and preview the resulting calculation outcome, helping you validate templates faster, stay in the form builder flow, and reduce reliance on extra test participants.
• If a template has more than six variables, a message will inform you that the template is too complex to preview interactively.
• Please note that previews for template-based fields (like Calculations, Summaries, and QR Codes) currently do not carry specific field configurations, and date and time fields are shown as plain text in the preview, which may lead to differences compared to live data entry where dates are treated as Date objects. 
• A warning message is shown in the preview to highlight this. 

In future updates, we plan to connect previews to actual field types and apply the same data entry logic to further improve accuracy.

Empty CRF export in PDF format

We have added a new export type: you can now request a PDF export of an empty CRF from the Study Structure, Forms, and Option Group pages. When generating the export, you can customize:

• Page size and layout, including title page, table of contents, and whether each form starts on a new page
• Which Visit, Repeating Data, and Survey forms to include
• What information to display, such as hidden calculation fields, field details, and calculation templates

Once the export is ready, it will be available for download from the Exports page.

Requesting and downloading exports via the API

We’ve introduced three new API endpoints to request, monitor, and download exports. More information can be found in the API documentation.

• POST /study/{study_id}/export: This endpoint allows you to submit export requests by specifying the desired export types, formats, filters, and options.
  Please note that this endpoint is currently in beta and implementation details may change.
• GET /study/{study_id}/export: This endpoint allows you to view the status of previously requested exports.
• GET /study/{study_id}/export/{id}/download: This endpoint allows you to download completed exports.

System defects fixes

Validations Logic & Behaviour

• We have fixed an issue where decimal values (i.e. 1.1 or 1.10) were incorrectly treated as equal in field validation expression checks. The system now correctly distinguishes between such values.
• We have fixed a defect, where triggering an Exclusion validation message on a Repeating Data or a Survey field incorrectly marked the participant's progress as excluded in the Participants Overview, which indicated that data collection is no longer possible on that participant. Now, participant exclusion status is only updated when exclusion validations are triggered on Visit fields, as intended. 
  As per the current CDMS logic, exclusion validations messages that have been triggered on a Repeating Data or a Web- Survey field will only prevent further data entry on the instance where they occurred. 

 Form Builder & Data Entry 

• We have fixed an issue on the search input in the Form Builder. Long field names, labels, or variables are now fully rendered within the search box, without being cut off.
• We have fixed a layout issue, where long label descriptions on horizontal slider fields caused the preview to break on smaller screens. The slider now adjusts correctly.
• We have improved error handling when users attempt to use system reserved variable names like record_id or randomize_id. The system now displays a clear validation message instead of [object Object].
• We have reintroduced the missing warning text shown in the Delete modal when removing a custom Repeating Data field. Users are now informed if and when deleting the field will also remove its column from the Repeating Data Overview grid.
• We have fixed an inconsistency where the order of study elements in the SDV Plan Tree View did not match the order defined in the Study Structure tab. Users managing SDV plans will now see elements displayed in the correct, expected order, improving clarity and reducing confusion during configuration.
• We have aligned the public API behavior with the CDMS UI when it comes to the required permissions to create Repeating Data Instances (RDIs).  Users with only the “Edit” permission can now create Repeating Data Instances (RDIs) via the API in a consistent manner with the UI. Previously both "Add" and "Edit" were required to fully complete the action.
• We have improved the configuration of fields by ensuring consistent default width behavior when no field length is specified. Fields now default to the maximum width allowed, preventing layout inconsistencies.
• We've addressed an issue where the Data Entry interface would attempt to open a form that had just been hidden by an automation, leading to blank pages and confusing system errors. Now, if a hidden form is targeted for display, users will see an error.
• We have fixed a defect in the Add/Edit Field modal where it was possible to assign a field to a domain, without entering a domain variable.
• We have fixed a small issue in the Add/Edit Field modal where error messages for domain variables were not aligned correctly.
• We have fixed a defect where an error message was not shown upon importing a survey with a name that already exists in the study.
• We have added an additional check for uploading images in image fields. Uploads of webp files are not permitted anymore due to compatibility issues.

Exports

• We have fixed an issue where in the Participants exports grouped by domain and "Export missing values in separate columns", upload fields marked as User Missing would not appear in the correct column.
• We have fixed a defect where, in some cases, the download export button on the Exports page required multiple clicks before the export was successfully downloaded.

Miscellaneous

• We have fixed an issue that rendered query automations to be triggered incorrectly, when the field's value was being marked as "value missing", specifically when an automation that was set on a value-based condition of "equals zero".
• We have resolved an issue where duplicate "Form locked" events were logged in the Audit Trail when signing and locking a Repeating Data Instance with already locked forms. Now, redundant events are no longer recorded.
• We have fixed an issue in Modern Data Entry when using new Date(); in a calculation field. Pages now load correctly and calculations are updated as expected.
• We have aligned the public API behavior with the CDMS UI when it comes to the required permissions to create Repeating Data Instances (RDIs).  Users with the “Edit” permission can now create Repeating Data Instances (RDIs) via the API in a consistent manner with the UI.  A sunset notice will be included in API responses to guide users through the transition, as per the API developer policy.
• We have fixed an issue, where the native browser shortcuts using the 'Alt' key were not working in CDMS. These shortcuts now function as expected.
• We have fixed an issue where dates were not displayed or accepted in data entry when the browser language was changed. Date fields now render and function correctly across supported browser language settings.
• We have resolved an issue where incomplete Grid field configurations (caused by missing field type selections) could be saved and later break data export. The system now prevents saving unless all required field types are selected, and newly added columns or rows will have "Text" auto-selected by default to ensure export integrity.
• We’ve fixed an issue where studies could not be set Live if stale data was submitted from another browser tab. A versioning and locking mechanism has been added to prevent overwriting newer changes. Now, if outdated study settings are submitted, users will receive a clear message prompting them to refresh before proceeding.
• We've corrected the description for the {queryMessage} tag in the Notifications configuration panel for "New Query Created" and "Query Updated" event types. It now accurately reads: "the actual message entered when the query was created or updated", instead of incorrectly duplicating the description for {fieldLabel}. This helps clarify the purpose of each tag when setting up email notifications.
• We have resolved an issue where users on Firefox v133.0 were blocked from importing CSV files, due to an incorrect file validation error. Users can now successfully upload and preview CSV imports for participant data.