Castor CDMS 2025.3.0.0 Release notes |  Release Dates: 14-15 Oct 2025 

New features and / or  enhancements

Field Validations (system edit checks): Extended configuration options 

Starting with version 2025.3.0.0, Castor CDMS will introduce additional configuration options for Field Validations.  The new capability makes it easier to catch and act on timeline errors, in both clinician and participant data entry views.

The list of changes begins by providing study designers and data managers with the ability to easily create field validation rules (edit checks) that directly compare the values of two fields of type date. This aims to enable more robust and intuitive checks for logical date sequences, without relying on workaround calculations.

Available for studies using the new Validations logic, rolled out with CDMS v2024.4.0.0 on December 17th 2024 (internal feature flag Validations V2) this enhancement allows compatible date fields to be selected as a reference field, during the configuration of an edit check on a source field. 

The compatibility rules have been designed to ensure logical rules and prevent misconfigurations.  Available field compatibility rules are as follows:

• Encrypted fields cannot be selected as a reference field 

• Date-to-date validations can be configured between two fields that are within the same form or across forms in the same instance, namely the bellow use cases are possible

  • Visit field → Visit field

  • Survey field → Visit field 

  • Repeating Data field → Visit field

  • Repeating Data field → Repeating Data field, but only within the same instance 

  • Survey field → Survey field, but only within the same instance 

⚠️ Please be advised the the following scenarios are not permitted:

• Visit field → Repeating Data field 

• Visit field → Survey field 

• Repeating Data field → Survey field 

• Survey field → Repeating Data field

In scope for v2025.3.0.0 the following Validation Types are supported: information, warning and exclusion. The ‘Error’ type is currently not available, see more details in the Known limitations box below
Example: 
A study designer could configure an exclusion validation to trigger if an “Admission Date” is set later than a “Discharge Date,” automatically flagging the participant. 

CDMS v2025.3.30 will also support field validations that work with partial dates, allowing study designers and data managers to catch logical date errors even when full dates are not collected (i.e you can configure a validation so that an year-only date is still checked against a full date field).

When setting up the validation (on a source field), you can choose a handle method (via the input 'Handling partial dates'). The handle method selected dictates how the validation should be evaluated (whether to ignore partial dates, compare by matching month or matching year, or round them to the beginning or to the end of the period). This flexibility better reflects real-world clinical data entry scenarios, reduces false validation triggers and ensures higher data quality.

Example: 
A study tracking follow-up visits can set a rule that triggers a warning if a “Follow-up Date” (month/year only) occurs before a “Surgery Date” (full date), using the “Trigger on matching month/year” method.

Enabling encryption on a field will now trigger a clear static warning in the field’s dialog, if that field is used as a reference in any validations. If you agree to proceed, all validations referencing that field will be automatically removed, the form builder will update instantly, and each event will be logged in the audit trail.

Example: If Date of Birth is used as a reference in an Age Check validation and you encrypt Date of Birth, the Age Check validation is removed to maintain data integrity.

When a field’s type is changed and the field is used in a validation configuration - either as a source or a reference - the system will automatically remove all related validations and auto-closes associated validation messages to maintain study integrity. Study designers are shown a static warning in the field’s dialog before proceeding, ensuring they understand the impact of their change. 
All removals and closures are logged in the Audit Trail for compliance. This update prevents broken or invalid validation logic and provides greater transparency and control for study designers managing study structure.

As part of the changes, we have extended Form Sync to fully support field validations that compare two date fields. When cloning or syncing studies, date-to-date validation rules are now copied, previewed, and merged with complete accuracy. 
Changes such as operator updates, reference field changes, or deletions are clearly shown in the Form Sync preview and logged in the audit trail with the appropriate events (Validation created, replaced or removed).

The Form Sync’s Interim Data Impact Report also fully supports reference-based fields, giving study designers and data managers clearer visibility into the preliminary impact of the changes implemented for mis-study updates. Any modification to validation logic such as changing operators, reference fields, or field types is logged as a distinct change, with participant-level impacts listed in detail across the report files.
Example:
If a validation comparing two date fields (If field A >  field B) is updated and the participant’s data no longer meets the condition, the report will predict an auto-close; If the reverse applies, it will predict a new trigger. 

All other related CDMS areas have also been updated to fully support date-to-date field validations.
Importing field validations that reference another field are possible via XML structure import, enabling study designers and data managers to migrate complex validation logic accurately between environments. During import, the system validates that referenced fields exist, are of compatible type (DATE-to-DATE supported so far), and are not encrypted. If invalid references are detected, the import is stopped, and users receive clear error messages. Successfully imported validations appear immediately in the Form Builder and are logged in the Audit Trail. 

The Empty CRF export (PDF) is also fully compatible with date-to-date field validations. When validations compare one date field against another, they are displayed in a clear, consistent format such as “Warning: field is smaller than <ReferenceFieldName>” or “Information: field is equal to <ReferenceFieldName>”.  Handling of encrypted fields in the PDF remains unchanged.

The Validations Overview Grids & API changes

The 'Reference value' column in both global and participant-level Validations grids now displays the actual value from the referenced field (dynamic) or of the referenced value (static) when a validation is triggered. This allows data managers to more easily review the context of each validation.

Example: If Date of Birth is validated against Date of Visit and the rule is triggered, the grid will now show the Date of Visit value (e.g. 2024-01-01) alongside the Date of Birth value (e.g. 2025-06-08)

To strengthen data privacy, when a validation is triggered on an encrypted field, the 'Reference value' and 'Operator' are now shown as *hidden* in the Validations Overview grids and returned as *hidden* by the public API. The source's 'Field value' continues to remain encrypted as before. This applies to all studies and prevents sensitive values or logic from being inferred while preserving visibility of validation events for monitoring and audit.

Castor CDMS additionally supports field-to-field validations also in the Print Participant Data export. Validations are displayed in a clear, consistent format, such as “is > than [ReferenceFieldName]” or “is = to [ReferenceFieldName]”, making it easier for study designers and data managers to review validation logic alongside participant data. 

A new beta API endpoint GET /study/{study_id}/validations/{validation_id}/history has been introduced to allow data managers and monitors to retrieve the full history of validation status changes for any triggered validation within a study. 
This includes detailed information on previous and new statuses, who performed the update (or if it was system-triggered), timestamps and any associated Reason for Change entries (where applicable). 
This addition enhances the transparency and auditability of data cleaning activities by making it easier to review how and when validation statuses have evolved over time. 

The new endpoint is available for studies using the new Validations logic, rolled out with CDMS v2024.4.0.0 on December 17th 2024 (internal feature flag Validations V2).  For studies without this feature, the endpoint will simply return no history data. Users are required to have View permissions to use this endpoint.

Known limitations for Field validations in v2025.3.0.0

• This change is only compatible with studies using the new Validations logic, rolled out with CDMS v2024.4.0.0 on December 17th 2024 (internal feature flag Validations V2) and cannot be used in studies that are on the legacy validations logic.

• Validations of type ‘Error’ are not currently included; These are being under review and will be part of future iterations

• To ensure smooth study execution on Castor Connect (mobile app for ePRO), Castor CDMS now helps study designers avoid unsupported validation configurations. When configuring field-to-field validations (such as date-to-date comparisons) within surveys marked for Castor Connect, a warning banner is displayed to inform users that these validations are not supported in the mobile app.
  
  Note:  Castor Connect does not currently support validations using a referenced field. Please be aware that the system does not currently block or restrict CDMS users from configuring field validations using a reference field (i.e date-to-date) on any type of survey field . This prevention mechanism for Castor Connect surveys fields  will be added in a future iteration.

• In addition, any surveys that already contain field-to-field validations are automatically excluded from the list of selectable surveys when creating or editing a Castor Connect survey package. This prevents study teams from unintentionally including unsupported logic in mobile-enabled surveys.
  These changes apply only to Castor Connect survey packages in studies with the Record Scope feature flag enabled. Standard web-based surveys remain unaffected.
  

Field Validations (system edit checks): Export Report

We've expanded the export capabilities for Field Validations (system edit checks), to give users more control, flexibility, and additional reporting tools.

Users can now export all validations in either CSV or Excel format, with each export respecting configured permissions and form blinding settings. Exports can be filtered using the active filters applied in the Validations Overview, making it easy to extract only the most relevant data.

In addition to exporting the complete list, users can also select or filter specific validations from the overview and export just those items. We've also added the ability to export validation data for a single participant directly from the Participant Validations view. 
All exports are asynchronous and can be downloaded from the Exports page when ready. These updates streamline validation review and reporting workflows across global and participant-level contexts.

With CDMS v2025.3.0.0, we have also  updated the Batch Export API endpoint (POST /study/{studyId}/export) to support the new Validations export.

Participant experience | ePro 

Language & Localization

• Castor CDMS’s web-based surveys have been updated to allow the selection and display of the Arabic language in right-to-left format.

• The On-site ePRO module now supports right-to-left presentation for Arabic.
  

On-site ePRO Configuration & Visibility

• Whether a remote copy of a survey is sent when administering an On-site ePRO is now configurable per study. It can be set to: on by default, off by default (no email sent), or configurable per use.

• For studies using the On-site ePRO module, additional columns and data are now included in the survey listings to distinguish between surveys completed on-site vs. remotely.

Data Entry & Collection 

• Archiving actions in CDMS now cascade automatically to child instances, reducing manual effort and ensuring consistency across study data. When a parent item (such as a Participant, a Repeating Data Instance, or Survey Package Instance) is archived, all its children are archived at the same time, with clear warnings shown in the confirmation modal. The system enforces safeguards, as archiving an entity (i.e a Participant or a Repeating data instance) is blocked if any child is fully or partially locked or fully blinded for the user's role. Appropriate error messages are displayed. All archive actions are logged in the audit trail for both parents and children, giving study designers and data managers greater efficiency and stronger compliance control.
  
  

• To improve data integrity and prevent submission conflicts, we have updated the logic in CDMS Data Entry so that individual input fields can be temporarily disabled during data submission. This occurs while a user-submitted value (i.e. via a slider, a dropdown) is being processed. 
  During processing, the specific input becomes non-interactive (read-only) and displays a visual spinner. Once the value is successfully saved to the database, the input is re-enabled automatically. 
  For grid fields, the system will be blocking all the cells configured for the grid while data is being saved. This enhancement applies to clinician views, ensuring accurate data capture without disrupting navigation or interaction with other fields on the form.

• We’ve updated the icon used to indicate empty fields in the CDMS Data entry Clinician Views (applicable to the modern UI, not the legacy one). The previous red asterisk shown in front of the field's label has been replaced with a new red outlined circle icon. 
  This distinction was introduced to avoid confusion with required fields. These will continue to show a red asterix icon (*), after the field's label. 
  
  This empty-state icon now appears consistently on both required and optional fields when they are empty, with a tooltip labeled “Empty.” 
  

UX & Accessibility 

To enhance the user experience and prevent unexpected logouts, CDMS now keeps your session active based on user interaction and not just database updates. Mouse movement, clicks, keyboard input etc will automatically refresh your session in the background, ensuring you stay logged in while actively working or reviewing study data. Sessions will still expire after 20 minutes (as default) of inactivity. 

Please note that this update applies to activity within the active browser tab only.

We’ve also introduced a session expiry warning in CDMS. Users will now see a pop-up 60 seconds before their session ends, giving them the option to continue working or log out. If no action is taken, the session will expire automatically, and the user will be logged out. This warning applies to the active browser tab only and helps prevent unexpected logouts during active use.

We have improved usability in SDV and Validations grids by making the Participant ID column sticky. The Participant ID column is now fixed to the left side of the grid, ensuring it always remains visible when scrolling horizontally. The Site column is positioned immediately to the right of Participant ID for easier context. 
This update applies to the global grids for Pending SDV, Dropped (verifications), Performed (verifications), and Validations, as well as the participant-level Pending SDV grid. Monitors and data managers can now more easily track participants across wide datasets without losing sight of the key identifier.

We have reintroduced a warning in the Form Builder when creating field dependencies where the parent field appears later in the structure than the child. This warning is now shown as a banner at the top of the Field Dependency tab in both Add and Edit Field dialogs.The updated message  “You are creating a dependency on a field that appears later in the structure. Please check if this is intentional.”  helps study designers avoid unintended logic issues by making the dependency order explicit.

We have introduced unique and meaningful titles for all pages in Castor CDMS to improve accessibility and usability. Each page now displays a descriptive title in both the browser tab and the page content (i.e. Audit Trail, Study Settings, Participant Queries), helping users, especially those relying on screen readers,  quickly identify the page’s purpose.

Please be aware that for legacy pages, only the browser tab title has been updated.

We have added a tooltip to the study logo in Castor CDMS. When hovering over the logo, users will now see the text “Study logo.” This tooltip improves clarity without interfering with screen readers, ensuring accessibility is maintained.

Improved Flow for Query & Validation Status Update

We have updated the Query Status update flow to require explicit status selection. When opening the Query Status Update modal, the status dropdown now defaults to “Please select” instead of showing a pre-filled value. Users must actively choose a status before saving, even if they intend to keep the same status.
If no status is selected, the system displays an error message and prevents submission. This change ensures that query status updates are always a deliberate action, reducing the risk of accidental or overlooked saves.

 

We have improved access to the Validation Status modal for users with View-only permissions. Users who do not have Validations permissions can now open the Validation Status modal to review the full history of status changes. The modal will appear in a read-only mode, meaning that while these users can see all details (including reasons for change and audit history), they cannot edit or update the validation status. This ensures consistency with the API behavior and improves transparency for data managers and monitors who need oversight without requiring edit permissions.

Upgraded Interface for Automations

The Automations Overview page has been fully rebuilt using the modern React framework, delivering a faster, more accessible and more intuitive experience for study builders and data managers. While maintaining all existing functionality, including the ability to view, enable/disable, edit, and delete automations, the new version introduces a refreshed interface with streamlined layouts, improved keyboard navigation and real-time updates that reflect changes instantly. 
The Automation Engine Logs page has also been upgraded and was integrated with the Automations Overview page, under a single main menu item. 

Users can now easily switch between the Overview and Engine Log tabs and experience improved table layouts.  The column naming  was cleaned up and new visible details such as Participant ID and Trigger Event were added directly in the grid. 
Search and filtering are now consolidated into a single Filters menu for a cleaner UI, and row-level detail dialogs make it easier to inspect log entries without leaving the page.

This update delivers a faster, more accessible and more intuitive experience for study builders and data managers, while maintaining full feature parity with the legacy view. The new page is available to all studies with the Automation Engine enabled.

AI powered chatbot

CDMS now includes a new AI Support Assistant, accessible directly from the platform, to help users find answers without interrupting their workflow. A chatbot icon is now visible in the left navigation panel as soon as this feature has been enabled for your study.

Note: This feature is currently not available to all studies by default. In order to try out the AI Support Assistant, please reach out to our Support team in order to have this enabled for your study.

Clicking it opens a responsive chat window, where users can ask platform-related questions -like how to add users or manage studies- and get instant answers pulled from the Castor knowledge base.  

The AI chatbot assistant supports basic formatting, preserves chat history during the session and handles unknown or unsupported questions clearly and explicitly.  The model automatically recognizes the input language and continues in that language.

The chatbot also now seamlessly connects users to the Castor support team when they request additional assistance. The system now detects phrases such as “pass me to someone”, “I need a human”, or “Castor support” with high accuracy. When triggered, the chatbot prompts the user to provide their name and email address, captures the full conversation history, and automatically forwards a structured support request—including a clear issue summary and urgency level—to the Castor support team.

Empty CRF export & Participant Casebooks Enhancements

Note: The Participant Casebook is not a standard offering and it can be enabled upon request via Support.

We have introduced an option to inline Repeated Measurement forms in the Empty CRF export. Study designers can now choose to display Repeating Data forms linked to Repeated Measurement fields directly after the parent field, instead of under a separate “Repeating Data” section. A new setting, “Inline forms for Repeated Measures fields”, is available in the Empty CRF export dialog (unchecked by default). 

When enabled, child forms are shown inline with a clear visual distinction (e.g., indentation), receive their own bookmarks in the PDF, and appear in the table of contents. The Repeated Measures table is hidden in this mode, making review easier and more intuitive.

We added a section in the Participant Casebook and Empty CRF exports for Option Group listings. For Fields using Option Groups containing more than 10 options, we will only print the active option(s) -if any are selected-. A hyperlink to the Option Group section is available.

We’ve added full support for NRS sliders in both Casebook and Empty CRF exports. This means study admins can now review and share participant data with slider responses clearly displayed, including configurable limits and labels, with selected values highlighted for easy interpretation. This enhancement ensures that survey data collected with NRS sliders is accurately captured in exports, improving clarity and usability for both monitoring and reporting.

On top of the above change, a series of smaller updates have also been implemented:

• We now include a hyperlink to the associated Repeating Data for Repeated Measure fields in the Empty CRF export. 
  
  

• EQ5D sliders are now properly printed in the Empty CRF and Participant Casebook exports.

• We added support for rendering QR Code fields in the Participant Casebook exports.

• Location fields are now rendered correctly in the Empty CRF and Participant Casebook exports.

• Dependency information is now included for Remark fields in the Empty CRF exports, aligning the layout with regular field types.

• We now render compiled Summary fields in the Participant Casebook exports, including the referenced data in the templates.

• We have addressed an issue where the "Generated By" item on the Empty CRF Export title page would not get populated, so users can easily see who generated the export.

 API Improvements

See the API documentation and the Changelog for more information.

• We extended the GET Field API endpoint to return Domain Variable name information per domain. 

• We added a new API endpoint to retrieve the available Domains in the study under GET /api/study/{studyId}/domains. 

• A new beta API endpoint GET /study/{study_id}/validations/{validation_id}/history has been introduced to allow data managers and monitors to retrieve the full history of validation status changes for any triggered validation within a study
• We have also  updated the Batch Export API endpoint (POST /study/{studyId}/export) to support the new Validations Report export

Removed features and / or functionalities 

Exports

• We have removed the "Participant Details" block from the title page of the Empty CRF export, as it is not applicable.

System defects fixes

Participant experience | ePro

• When administering participants in the On-site ePRO module, the participant dropdown now becomes searchable if more than 250 participants are available (previously limited to 25 and not searchable).
• Fixed a race condition in Castor Connect that could prevent some file uploads from completing when submitting surveys with multiple upload fields for the first time per participant.
• Resolved an issue where the archive/unarchive audit trail events for survey package instances were incorrectly listing the instance ID as the participant ID.
• We have fixed an issue affecting web-surveys displayed on small screens (e.g. 360px width, such as on Samsung Galaxy S8+). Previously, the unit labels for number entry fields were cut off because the input box was not fully responsive, making the labels partially unreadable. With this fix, number entry inputs now resize correctly so that unit labels remain fully visible on all screen sizes, improving readability and usability for participants completing surveys on mobile devices.

Data Entry & UI Improvements

• We have resolved an accessibility issue in modern data entry (visits forms) where keyboard focus did not return to the field’s menu button after closing the menu with the Escape key.

Form Configuration & Builder

• Study builders and designers can now seamlessly update Grid field configurations by adding new rows, without triggering incorrect validation errors. This fix restores flexibility during form setup and ensures smoother configuration of complex data collection fields.

• When columns are removed from a Grid field (especially those configured as Dropdowns), the Option Group settings now correctly realign to reflect the updated column structure. Before this fix, leftover references caused visual inconsistencies and confusion in the configuration UI.

• We fixed an issue where the EQ5D slider field preview would not work correctly in Form Builder.

Validations & Logic Handling

• We have fixed a defect where validations (configured to be triggered based on static values or current date) were incorrectly triggered when a field was marked as Value Missing (with a predefined reason, i.e. Measurement failed). These value-based validations will now ignore Value Missing codes, ensuring they only trigger on actual user-entered data.

• A defect was identified and fixed, where updates to validation operators are not being correctly reflected in the Validations grid or Audit Trail events. When a user edited an existing validation by changing the operator, i.e. from “>” to “!=”, the system continued to display and log the old operator. 
  The issue only applied to studies using the new Validations logic, rolled out with CDMS v2024.4.0.0 on December 17th 2024 (internal feature flag Validations V2).

Access & Security

• We have fixed an issue where users without two-factor authentication (2FA) were redirected to the studies list without explanation when trying to access a study with 2FA enforcement enabled. A clear error message is now displayed, informing users why access is blocked and what steps they need to take.

Exports

• We fixed a rendering issue in the Participant Casebook exports where fields with many active validations would be rendered outside the boundaries of the page.

• We fixed a long-standing issue where semicolons in field values would be replaced by dashes in several of the export formats. This is now no longer the case, semicolons will be persisted in the exported data. 
  Note: this is a potentially breaking change. If you relied on custom post-processing to revert the semicolon-to-dash replacement, you will need to remove this post-processing step from your workflows following this release.

• We fixed an issue where large Option Groups could not be rendered in the Participant Casebook and Empty CRF exports.

• We fixed several small alignment issues in the Empty CRF and Participant Casebook exports.

• We fixed an issue in the Empty CRF export where deeply nested field numbers would overlap with the field label. Long field numbers now continue on a new line.

• We fixed an issue causing some characters in field labels to be double HTML-encoded in the XML form structure exports.

• Fixed an issue in the Empty CRF export where deeply nested field numbers would overlap with the field label. Long field numbers now wrap to a new line.

Workflow & misc. 

• We have improved the user experience when marking a form or form collection (such as a visit) as “Value Missing.” Previously, the system displayed a warning message if the form contained any fields that cannot technically be marked as missing (such as calculations or QR codes). This behavior was inconsistent with the intended design, where these fields should simply be ignored without disrupting the user flow. With this update, users will no longer see unnecessary warning messages when marking forms as missing; fields not applicable for missing data are now silently skipped, as originally intended.

• We fixed an issue that prevented filtering on users that have been removed from the Study in the Participants overview, the Pending and Performed SDV overviews, and the Queries overview.

• We have fixed an issue where participants could still be archived even when their associated  (and/ or child) visits & instances were locked. Previously, archiving bypassed these restrictions, creating inconsistencies in study data handling. With this update, participant archiving is correctly blocked if any participant CRF parts are locked.
   

Other known release limitations 

Data Entry & Collection 

As part of broader workflow improvements around actions that can be performed for child or parent entities (see above the ‘Archive’ action included in v2025.3.3.0), future iterations will extend the cascading effect from parent to children also for the following actions: ‘Delete’ & ‘Unarchive’. 

Supported Browser & OS versions for CDMS v2025.3

For more details you can review Castor’s Browser and Operating System (OS) Policy.

Supported Browsers 

Supported Operating Systems 

Castor CDMS 2025.3.1.0 Release notes |  Release Date: 4th Nov 2025 

New features and / or  enhancements

Data entry & collection

• Castor CDMS introduces clearer and more consistent rules for unarchiving participants, visits and repeating data instances (RDIs), ensuring data integrity and preventing accidental restoration of hidden or blinded data. 
  When a parent entity, such as a participant or visit, is unarchived, its child instances now remain archived by default, while unarchiving a child instance automatically unarchives its parent to maintain structural consistency. 
  To protect study integrity, unarchiving is blocked when a parent is fully blinded for the user’s role or when the entire participant is archived. Users will see clear on-screen messages in such cases, and all unarchive actions are recorded in the audit trail under the performing user. 
  These improvements create a more reliable, compliant and predictable data management process across complex study structures.

• We have addressed two performance bottlenecks in data retrieval and visibility checks that caused unnecessary database load and latency in larger studies.

Study design &  Form building 

• We’ve increased the maximum character limit for  slider's upper and lower limit labels in Castor CDMS to provide greater flexibility and support for multilingual studies.
  This change ensures that study designers can use complete and accurate field descriptions, even in complex or translated contexts, without losing information or needing to abbreviate important terms. Any labels exceeding the 200-character limit will still trigger the existing validation message.

  Previously, these labels were restricted to 100 characters, which often caused issues in translated studies where text expansion naturally occurs (translations can increase label length by 30–50%). With this update, users can now enter up to 200 characters for the Lower limit and Upper limit labels (for sliders, including NRS sliders). 

• We have also doubled the maximum character limit of field labels from 1024 to 2048 to accommodate longer labels

API

• We’ve enhanced the data-points API endpoints in Castor CDMS to improve performance and scalability for integrations with large studies. Integrators and study data managers can now retrieve only the data that matters, without downloading full datasets and filtering manually on the client side.
  This update introduces two new optional query parameters across all data-points endpoints:

  • field_ids — filter results by one or more specific field UUIDs (comma-separated)

  • updated_after — return only data points updated strictly after a given timestamp

  Both filters can be used individually or together to narrow down results efficiently. Timestamps support the ISO 8601 format (e.g., 2025-09-25T00:00:00Z) and default to UTC, ensuring precision and consistency across environments.

ePro & Participant experience

• We have revised the on-site EPRO flow so that, for those studies with both on-site ePRO and web survey access codes activated, surveys completed specifically on-site will not require an access code to be entered.

• We have improved the way we highlight archived Survey Package Invitations in our Surveys Overview table to make them stand out more clearly.

System defects fixes
Data Entry & Collection

• We have addressed an issue a data integrity issue, where hidden and inapplicable fields of type 'Calculation' were still being stored and exported,  in studies with the “Clear inapplicable child fields” setting enabled.
  Previously, when a calculation field became hidden due to dependency rules or automation, its value continued to be calculated and stored in the backend, resulting in incorrect zero values appearing in exports even though the field was invisible to users. This behavior was inconsistent with the “Clear inapplicable child fields” study setting and created discrepancies between what was visible in the UI and what was stored or exported.

  This fix enforces data integrity and compliance across all study types and aligns backend storage and export behavior with visibility & dependency logic and configured study settings.

  Impact on running studies
  While the impact is expected to be minimal, please note that existing studies may see empty values in exports where hidden data was previously stored. 

• Fixed an issue where long labels on numeric rating scale (NRS) sliders were being cut off when viewing surveys on mobile devices.

• We have fixed an issue where clearing a calculation field's source value(s) using the “Clear source value” option caused the 'Reason for Change' dialog to freeze when GCP compliance was enabled. Previously, cancelling the action would inconsistently clear values. With this fix, the 'Reason for Change' dialog now functions smoothly and clearing source values correctly updates all linked fields across forms, maintaining consistent and compliant data behavior in GCP-enabled studies.

Data Validations

• We have fixed an issue where partial date validations were not correctly evaluated when compared to the current date under the “Trigger on matching month or year” handling method. Previously, when users entered partial dates (i.e **--Dec--2025 or --**--2026), the system failed to trigger validations that compared these values to the current date, incorrectly treating them as non-comparable.
  With this fix, partial dates are now accurately assessed against the current date, ensuring that validations such as “date greater than current date” behave as expected. 

Export & Casebooks 

•  We fixed an issue where semicolons present in calculation field values would be removed from export files.

•  We fixed an issue in the domain-based exports where studies with any option names or values exceeding 255 characters could not generate their export. 

•  We fixed an issue where in some cases Participant Casebooks could not be rendered in older studies.

•  We fixed an issue in the display of dependency information in the Participant Casebook exports where some fields with a dependency chain of multiple fields would not get rendered correctly.

•  Participant export files for Repeating Data are now ordered by Participant ID and Custom Name. Survey data is now ordered by Participant ID as well.

•  We fixed an issue in the SPSS export where quoted text in Survey exports could be misinterpreted, leading to failure to load the dataset into SAS.

•   We fixed text alignment, word-wrap and word-break issues in the Participant Casebook export.

ePro & participant experience

•  Translations added for error messages presented to users when web survey access code entered is incorrect.

•  We have resolved an issue where iOS restricted the display of special characters for numeric keyboards when viewing web surveys on mobile devices - an alphanumeric keyboard is now displayed.

•   Fixed an issue where long labels on numeric rating scale (NRS) sliders were being cut off when viewing surveys on mobile devices.

•   We have resolved an issue where survey dropdown fields were not displaying the 'Search...' help text in the selected participant language.

Misc

• Resolved an issue where user authentication via 2FA would strip any used redirect links after authentication

Castor CDMS 2025.3.1.1 Release notes   |  Release Date: 11th Nov 2025

System defects fixes

API & Export

• We have fixed an issue in /study/{study_id}/export/custom that renamed every uploaded custom export to a timestamped .zip (e.g., {study}custom_export_custom{YYYY_MM_DD-HH_MM_SS}.zip). 
  Uploads now preserve the original filename and extension you provide, and we only store a .zip when you actually upload a zip archive.

•  We have fixed an issue that caused the Export API to return errors when initiating a Query export.

Participant archival

We resolved a couple of issue relevant only for studies where reusing participant IDs after archival is enabled via the Admin settings:

• Previously, in studies where reusing participant IDs was enabled, archiving a participant did correctly update some historical audit trail events. The audit trail log would continue to retain the original participant ID, instead of the new one, prefixed with the string 'ARCHIVED-'.
  This fix ensures that when a participant is archived in studies where reusing participant IDs, the relevant audit trail entries are also updated.

• We have also fixed an issue where archiving participants failed when the “Allow reuse of participant IDs” setting was enabled in a study. Previously, attempting to archive such participants resulted in an error, with no audit trail entries recorded and no instances archived. With this fix, participants (and all their related instances) are now archived as expected.

Castor CDMS 2025.3.1.2 Release notes |  Release Date: 18th November 2025

System defects fixes

Automation Engine

• The Automation Engine now maintains data entry & collection stability when hiding forms that contain populated calculation fields, enabling researchers to use form visibility automations without encountering blocking errors. Previously, when an automation rule hid a form with calculation fields during data entry, the system would fail due to inconsistent error handling between the Automation Engine and calculation pathways. This fix aligns error handling across all execution contexts, allowing empty value updates to hidden calculation fields and preventing workflow interruptions in studies with complex automation rules.

Castor CDMS 2025.3.1.3 Release notes | Release Date: 27th Nov 2025

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

New features and / or  enhancements

ePro & Participant experience

We have introduced a configurable enhancement to improve participant experience in web surveys. When enabled, participants who exit a survey and return—whether by closing the browser, timing out, or switching devices—will now resume at the top of the last viewed form, rather than being dropped back into the last-entered field. This behavior supports more intuitive navigation and better compliance, enabling clinical trial participants to maintain natural survey progression when returning to incomplete assessments.

This  change resolves navigation complexity for eligibility screeners and studies requiring forward-only progression, where the previous behavior incorrectly returned participants to earlier pages when they had viewed but not entered data on subsequent forms. 

The implementation uses automatic fallback to existing behavior for legacy surveys, ensuring backward compatibility while preventing premature exclusion triggers and unauthorized data modifications in blinded studies. This improvement requires backend tracking of the last viewed form and works across devices and sessions. 

Important notes: 

• Participants will be redirected to their last viewed page, while logged in clinicians will continue to be directed to last datapoint entered when viewing surveys in CDMS. 

• For new studies, the feature is enabled by default. For existing studies, it remains disabled unless explicitly activated by Castor Support, as this is also configurable per-study.

A few key features below:

•  Applicable to participants, not logged in clinicians that are using Castor CDMS

• Preserves the integrity of exclusion logic, ensures smoother participant experiences when switching browsers or devices

• Aligns CDMS web-surveys with best practice behavior for form-based workflows

• Automatic fallback to legacy behavior ensures zero disruption for existing studies

System defects fixes

ePro & Participant experience

• Web survey exclusion evaluation has been refined to prevent premature participant blocking, ensuring eligibility criteria are applied only when participants reach the relevant form page. 
  Previously, exclusion rules triggered immediately upon value changes, which could incorrectly block eligible participants mid-survey. 
  The enhanced logic maintains immediate exclusion triggering for clinician-facing data entry (Visits and Repeating Data Instances) while giving survey participants flexibility to navigate and correct answers before final eligibility assessment is computed, improving data collection completion rates and participant experience.

• Survey exclusion logic now maintains stable eligibility status when participants modify their responses, preventing eligible participants from being incorrectly excluded in multi-form workflows. 
  The implementation addresses a state management issue where changing a date field that temporarily triggered exclusion criteria would permanently exclude participants even after the answer was corrected to meet eligibility requirements. 
  This resolves compliance concerns in participant screening where answer modifications during survey completion caused false exclusions, ensuring accurate enrollment decisions in clinical studies.

• Resolved an issue resulting from previous major release where dependent, hidden calculations with missing values submitted as part of surveys via Castor Connect could result in duplicate entries being submitted

Castor CDMS 2025.3.2.0 Release notes |  Release Date: 16th Dec 2025 

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

New features and / or  enhancements

Study structure & design

• The Add and Edit Field modals have been updated to display field types in the same order as the right-hand “Add Field” panel in the Form Builder. This change improves usability and consistency, ensuring that study designers can more intuitively locate and select field types across both interfaces.

• To ensure consistency and prevent unsupported configurations in mobile-enabled (using the Castor Connect app) studies, Castor CDMS now fully blocks the creation of field-to-field validations on survey fields that are part of a Castor Connect (mobile) survey package. Previously, users received only a warning; now, the system enforces this restriction at both the UI and API levels.
  
  When editing or adding a survey field within a Castor Connect–enabled package, the “reference field” option is disabled, and submitting such a configuration will trigger an error. A static banner warning remains visible to explain: “Field-to-field comparison is not available in the Castor Connect app.”
  
  This safeguard prevents study designers from creating unsupported validation logic that could otherwise cause mobile survey failures or study deployment delays.

Domain based exports

• Domain-based exports now support optional survey metadata inclusion, enabling researchers analyzing longitudinal studies to distinguish between multiple survey instances sent at different time points. The new "Include survey metadata" option adds eight contextual fields (survey package instance ID, survey instance ID, creation timestamp, sent timestamp, completion timestamp, progress status, package name, and package ID) to exported CSV files while maintaining backwards compatibility with existing export configurations. This implementation extends to SAS conversion workflows, ensuring that statistical analysis tools can leverage the temporal and instance-level metadata for studies with repeated survey administration protocols.

Automation Engine

• The Automation Engine now attributes all automated actions to a dedicated "System User" entity, enabling clear distinction between manual and automated operations in audit trails. This resolves compliance challenges where automation-triggered events were logged under creator accounts, causing attribution issues in blinded studies and role-based access control environments. The implementation maintains backwards compatibility.

API

• We’re extending GET /study/{study_id} to surface key study-level milestones and settings so admins and integrators can build richer exports and oversight dashboards without extra joins. The response now includes:
  •first_live_on (ISO 8601): timestamp of the first time the study was made Live, or null if never live
  •last_datapoint_collected_on (ISO 8601): most recent timestamp of any datapoint collected in the study, or null if none yet
  •encryption (boolean): whether study-level encryption is enabled
  
  These additions are backwards compatible (new optional fields only). API reference and API changelog will be updated accordingly.

• Validation monitoring via Public API has been enhanced with field-to-field validation context, allowing data managers and  integration partners to programmatically access complete validation details including referenced field values.
  Public API validation endpoints now expose field-to-field comparison context through opt-in metadata properties, enabling data managers to programmatically audit complete validation logic including cross-field dependencies.
  The implementation adds referenced_field_id and  reference_type properties to both participant-level and study-level validation endpoints, which distinguish between static value validations and dynamic field comparisons while maintaining backward compatibility through query parameter control.

  • referenced_field_id identifies the comparison field UUID in field-to-field validations

  •  reference_type property differentiates "field" vs "value" validation logic

  •  validation.value is now nullable to support both validation contexts

  • backward compatible via include_referenced_field query parameter (default: false)

EPRO & Participant experience

• The 'Survey locked' screen users see when attempting to open a locked web survey has been updated to include a language dropdown to enable users to view the page in the supported languages.

Data collection & Participants

• Hierarchical data deletion has been enhanced with automatic cascade functionality, allowing study designers and data managers to delete parent instances along with all child instances in a single action. The implementation enforces existing permission checks and restricts deletion when children are locked or fully blinded, ensuring data integrity and compliance requirements remain intact.

  • Automatic cascade deletion from Participants, Repeating Data Instances, and Survey Package Invitations to all children

  • Enhanced delete modals with clear warnings about cascading effects

  • Permission enforcement prevents deletion when child instances are locked or blinded 

  • Comprehensive audit trail logging for all parent and child deletions

  • User-friendly error messages guide resolution of deletion restrictions

• We’ve introduced a new feature that adds a Catalyst launch icon directly to the Participants Overview grid. This enhancement enables quick access to Catalyst by redirecting users to the corresponding participant view with a single click.
  This feature is controlled by a study-level feature flag and is disabled by default in all environments in v2025.3.2.0.

System defects fixes

Study structure & design

• Form and visit deletion in Study Design now functions reliably for studies containing calculation fields, resolving errors that previously prevented structure modifications. The implementation corrects step renumbering logic to avoid database conflicts, enabling study designers to modify complex form structures without encountering integrity constraint violations.

• Study design validation now detects and prevents circular field dependency configurations during both structure import and UI-based updates, ensuring system stability for all studies with field dependencies. The fix rejects infinite dependency chains before they enter the system, displaying clear error messages to study builders and preventing out-of-memory errors that previously occurred in monitoring and dependency-heavy operations. This comprehensive validation safeguards platform performance across XML imports, Study Design interface changes and downstream processing for studies with SDV Plans enabled.

• Backend calculation validation now recognizes all available static template variables, enabling study builders to activate automated re-execution of calculations without errors when using survey package metadata tags. The implementation aligns the calculation dependency analyzer with the complete set of static variables available in form templates, resolving validation failures that previously blocked enabling backend calculations for studies using tags like {surveyPackageAvailableFromDate}. This ensures seamless activation of automated calculations for studies leveraging survey package scheduling metadata.

EPRO & Participant experience

• Survey submission endpoints now validate completed survey status before accepting updates from Castor Connect, preventing data loss when participants submit surveys with stale app state. The validation rejects attempts to overwrite completed survey instances for repeatable, resumable surveys, returning contextual error responses with survey identifiers, timestamps, and submission source information to enable clear user messaging in the mobile app. This safeguards data integrity for studies using participant-reported outcomes without auto-locking, particularly workflows where site staff complete surveys on behalf of participants using uploaded photo documentation.

• Resolved an issue where longer NRS field label text was being cut off at the end of the field when presented in right-to-left / Arabic format

• Resolved an issue where surveys containing a triggered exclusion could not be fully navigated by clinicians in 'read-only' mode

• Resolved an issue where sliders in specific languages with longer text labels (e.g  German) were being cut off due to wrapping and text length.

Data collection & Participants

• Backend calculation fields now process data entry updates with improved event ordering, ensuring automation rules execute synchronously before asynchronous calculation updates.The applies fix will be preventing race conditions where calculation field values appeared stale in automation triggers. This resolves reliability issues affecting data entry interfaces, the Public API and automation workflows dependent on calculated field values.

• Resolved an issue where long survey or form titles could extend the container of a survey and make them stretch. Longer titles will now wrap.

• Resolved an issue where surveys triggered by a field update via data import were being created but erroring when variable names were incorrect

• Legacy data entry navigation now maintains accessibility when automation rules dynamically hide forms that were previously opened by users, preventing scenarios where participants become inaccessible due to stale navigation state. The system automatically redirects to an available visible form when the last-opened form is hidden by automation, ensuring uninterrupted study operations for data managers using automation-driven visibility controls. This resolves a critical issue where hiding forms through automation could lock users out of participant records in the legacy ExtJS interface.

Export

• Validations export functionality now properly enforces the Validations V2 feature flag (details here), ensuring data access  controls align with enabled platform capabilities across all interfaces. The implementation adds feature flag  validation to the top-level monitoring page, participant-level monitoring page, and Public Export API, preventing unauthorized access to validation export features in studies where the new Validations capabilities are disabled. This resolves configuration inconsistencies that could expose functionality not intended for specific study environments.

• We fixed a bug that would cause duplication of option group information in the `field_options` export file in domain-based exports.

Miscellaneous

• Audit Trail now correctly attributes automated system operations to "System User" instead of displaying "Unknown user", improving compliance audit trails for study administrators managing participant lifecycle events. The implementation maps the internal System User UUID to the user-friendly "System User" display name across all audit log entries, ensuring clear distinction between manual and automated actions.

• We fixed an issue that prevented new Participants from being created via the FHIR importer.

• We fixed an issue that would prevent the Audit Trail Export to skip over events under certain circumstances for studies created before 2023, ensuring complete export coverage for compliance-critical audit data.

Castor CDMS 2025.3.2.1 Release notes |  Release Date: 23rd December 2026 

System defects fixes

• We fixed an issue that would prevent data from being saved when it would trigger automations that would hide and clear forms/visits.

Castor CDMS 2025.3.3.0 Release notes | Release Date: 2nd January 2026 

System defects fixes

• Form builder text inputs now automatically detect and apply correct text directionality for right-to-left (RTL) languages, enabling proper text display and editing for international study teams. Previously, all form builder inputs rendered with left-to-right directionality, causing numbers and formatted text in RTL languages to display incorrectly and making field label editing impractical.

• We fixed a potential authorization bypass issue that allowed users to access repeating data instance(s) via direct URL navigation while blinded for its contents.

• We fixed a race condition in the handling of calculation fields that could cause a calculation to retrieve stale data and use that in the calculation.

• We've fixed an issue where the system overwrote the "Updated By" field on the Participants overview table with "System User" after single field changes. 

• User accounts who were migrated to Castor Identity were affected by the 7-day activity restriction on API usage that should only affect users who use SSO, even if they were not using SSO. This issue has been resolved, and now the 7-day activity restriction is correctly applied to SSO users only.

Castor CDMS 2025.3.3.1 Release notes | Release Date: 8th January 2026 

System defects fixes

• An issue has been fixed where survey package instances scheduled by the Automation Engine or manually through the UI would send successfully but fail to update their status or populate the "Sent On" timestamp. 

• Data entry forms now correctly clear field values for hidden calculation fields when dependency constraints become unsatisfied, ensuring calculations re-execute properly when dependencies are satisfied again. Previously, when a hidden calculation field's dependency became unsatisfied, the field's value persisted locally instead of being cleared, preventing automatic re-execution when the dependency was satisfied again.