Major release 2023.2.0.0 - Release date 7th June 2023 

Overview/Important Alerts

We are rolling out a brand new feature for source data verification, available directly for all new studies. Given the potential implications of transitioning mid-study, we will keep the current SDV capabilities in place for all studies that are already running monitoring activities. 

We have also updated participant data entry, with a new participant data summary in the left-side bar and a refreshed survey overview page.

New features and / or  enhancements

SDV plans

Managing SDV plans

• Study users with all default management permissions enabled (study admins, data managers, study designers) can create and manage SDV plans.
• When a plan has the required fields filled in the modal, a corresponding SDV plan card is created. This contains the name of the plan, the allocated sites, a reference number indication and a color.

• Once an SDV plan card is successfully saved, the user will automatically be redirected to the SDV plan builder view. 

• In the builder view, data point fields can be selected from the study structure tree view. individually or in bulk. The final selection made here will be applied to each participant while calculating SDV completion, as well as to the 'Pending SDV' list
• A search field is available in the SDV plan builder, allowing an easy search for fields, based on their label or variable name
• Some field types are excluded from this view, as those cannot be verified. These are: Image, Calculation, Add survey, Add report, Link, Remark, Summary, QR code, Repeated measurement, Randomization
• In the next step, the review plan, users can see all relevant details and selected fields. Before publishing an SDV plan, users can decide if any changes are still needed
• Only one plan can be assigned to a site, therefore the site selection list is updated according to any other active SDV plans your study has.  An informative text is shown regarding sites that are already assigned to another active SDV plan. 

• If no plan is assigned to a site or if a plan has no site(s) assigned, this means there are no defined requirements for source data verifications. Users with required permissions can still optionally SDV fields, forms, forms collections, but the 'Pending SDV' list will not have any information about these sites.
• When making changes to the study's sites, users will get additional information. When a new site is created, users will be warned about assigning an SDV plan to the new site, whilst when a site is removed and there is an SDV plan already assigned only to that site, the user will get informed about the possibility to update the associated SDV plan.
• Users with all default management permissions enabled can delete each card corresponding to an SDV plan. A list of all sites that will remain without an SDV plan assigned is shown in the confirmation dialog, so that  an immediate action can be taken if it is needed.

SDV plan(s) automatically updated by the system

• The SDV plan(s) as well as the SDV plan tree view will be  automatically updated and reapplied to all participants, after form structure changes have taken place in the system, such as adding or removing data points
• When a participant is moved to another site, the system applies the plan of the new site (if any) for that participant and automatically (re)computes the verification status. 

SDV status automatically recomputed by the system

• The automatic (re)computation(s) will be applicable for both possible cases:
  • participants belong to site(s) that are not assigned to any SDV plan
  • participants  belong to site(s) that are not assigned to any SDV plan
• The source data verification status will be automatically (re)computed and updated by the system to ensure keeping the verification status on participant's CRFs is up to date, following events that occurred in the system regarding:
  • field value update
  • data import
  • field dependency changes
  • structure changes
  • automation engine events that show or hide CRF parts

Visit specific

 This covers two scenarios:

• When the visits has data points in an SDV plan, all of the plan's fields must to be verified
• When the visits has no data point in an SDV plan, all visible data points must be verified

System verification of forms, visits and repeating data instances

• When the last field of the SDV plan has been verified within a visit or repeating data form, the form is marked as verified as well.
• Alternatively, if the form has no fields in the SDV plan (requiring source data verification), then when all of the available and verifiable fields in that form have been verified, then the form will get the SDV icon added.
• As soon as the last field of the SDV plan has been verified within a visit, the visit is marked as verified as well.
  • For visits that have fields in the SDV plan, all available data points must be verified in order for the visit to be marked as verified.
• When all available forms within that visit  are individually source data verified,  the visit is marked as verified as well.

System removal of visit verification

• When at least one form within a visit is no longer verified (removed by the user or dropped as a consequence of another event), the form’s verification is dropped as well  as a direct consequence. The SDV icon on the Visit is removed accordingly. 
• When at least one of the available data points requiring source data verifications (part of active SDV plan) in a visit's form is unverified by the user, the form’s verification is dropped automatically.
• If the verified form has no field that requires SDV, when any visible data point in that form is unverified by the user,  the form’s verification is dropped as well.
• In both cases, the SDV icon is removed in the CRF navigation panel accordingly.

Repeating data instances

• When all available forms within a repeating data instance  are individually source data verified by the user, the form collection is marked as source data verified (SDV) as well.
• As soon as all data points  belonging to the SDV plan within a repeating data instance are verified, individually or in bulk, the form collection is  as well verified.
• For repeating data instances  that have no field in an active SDV plan, when all  data points within that form collection are  verified  individually or in bulk, the form collection is also verified.
• When all data points requiring SDV in a repeating data form have been verified, the form is marked as verified automatically by the system, If no data points require SDV in a form, when all available data points in a  repeating data form have been verified, the form is marked as verified automatically by the system.
  • The  form's SDV banner is shown as soon as the form is automatically marked as verified by the system.
• When at least one field that is part of an SDV plan within a repeating data instance is unverified by the user, the instance’s verification is dropped. Alternatively, if no data points require SDV in an RDI, when at least one visible field in that instance is unverified by the user, the instance’s verification is dropped.

SDV plans in data entry view

• The SDV plan will also be automatically reapplied when opening a single participant’s CRF, if any changes to that CRF were done.  
• With the introduction of SDV plans, we're also changing how fields are shown in the data entry views. All data points that are included in the active SDV plan for the site on which the participant has been created will display a gray 'SDV' icon to indicate they require source data verifications. Once SDV is applied, the icon will turn green.
• Each form or form collection that has data points included in an active SDV plan that have not yet been verified will display the same gray 'SDV' icon, to help differentiate from forms that can be optionally & additionally verified. Once any form or form collection has been fully verified, the icon will turn green.
• An SDV status banner is displayed in Data Entry once a form is verified. If the verification was done by a study user, that user's name will be shown in the banner. If the verification was computed by the system, that will be specified within the same banner.
• Users without decrypt permissions cannot verify single data points that are encrypted.
  Similarly, single data points that are encrypted are skipped from bulk verifications.
• A new modal has been introduced on visit and repeating data instance levels, when the user attempts to bulk source data to verify the existing fields. This is meant to make the user aware of potential data missing cases, as the batch operation will be completed across multiple forms. 
• Alternatively to single data points verifications, the user can also opt to manually verify in bulk all data points or all data points in the SDV plan for a single form, visit or repeating data instance.
• Users can now manually remove in bulk all data points verifications from forms, visits and repeating data instances.
• When a user manually verifies all data points of a form in bulk, the visit or the repeating data' form is marked as verified as well. This scenario allows you to mark a form as verified even if it contains no fields assigned to an active SDV plan, as long as the form at hand has at least one field that is a collection data point.
• When the user manually verifies all data points in the SDV plan of a repeating data  instance in bulk, the instance is marked as verified as well. Alternatively, if no plan was defined or the instance has no data points in the active plan, the user can still verify all data points, thus marking the instance as verified outside of the plan.
• We have replaced the previous option to verify a visit. Now the user has the option to manually verify all data points in the plan for any given visit in one go. Once the last field requiring source data verification is verified, the visit is marked as verified as well.
• The user has now the possibility to manually remove all data point verifications in bulk directly from the visit.
• Users are able to verify in bulk all data points of a visit. If the visits contains no data points that are requiring SDV, this bulk option will till be shown, to cater the need to verify visits additionally, outside of the SDV plan.
• When a user manually verifies all data points assigned to an active SDV plan within a form in bulk, the visit or the repeating data' form is marked as verified as well. This scenario allows you to mark a form as verified by selecting and targeting only those data points for which source data verification is required.
• After having verified at least one data point in a visit form, the user can directly remove all applied verifications  in bulk from that form.
• If some CRF parts are hidden for the current user's role, those are skipped when verifying data points in bulk. That means that, if unverified forms are hidden for the user and the user has individually marked all other visible forms within a form collection (visit or repeating data instance) as source data verified, that form collection will not be marked as SDV-ed.
• In line with the SDV plan per site, the 'Pending SDV' listing has been updated to reflect the new underlying logic. It now shows a list of all data points that are part of an active SDV plan, have had data collected or have been marked as user missing, but are still yet to be source data verified. 

 Audit Trail

• Within the context of SDV plans, all related source data verification actions are logged in the audit trail. All events for direct actions related to SDV performed by the logged in study user are stored with the study user's credentials. 
• All events for indirect outcomes on the SDV status such as an automatic computation of SDV status for a visit when all data points that require SDV have been verified, will be logged by the system user.

Important considerations SDV plans

• All new studies that use the Monitoring feature will have the SDV plans feature by default. 
  • This includes a new linked study being build automatically using Form sync
• All running studies will keep using the current SDV capabilities. SDV plans could potentially be enabled via CS request only for studies that have not gone live yet.

 Repeating data overview

•  On the global Repeating Data Instances page, users are now able to filter the results based on 
  • their data entry progress status by using the new ‘Data collection progress’ criteria. Three options are available here: ‘Not started’ ‘In progress’ and 'Completed'.
  • the  ‘Participant status’ 
• Additionally, we’ve reworked the filter for sites. Users can see the available sites, grouped by countries. The default remains on the list view, but now you can choose to change it to a tree view, to better accommodate your specific needs.
   

Participant summary

• The existing participant summary indicating progress and status has been removed from data entry and added to the leftmost sidebar; functionality and content remains the same, but will allow us to expand in future
• Additionally, the participant summary block will display when a participant has requested their Castor Connect PIN be reset, and when a clinician has initiated the remote reset process.
• Activation management for Castor Connect studies is now available by clicking on the participant's activation status within this block

Clinician facing survey overview for a participant

• The clinician facing survey overview page for a single participant has been migrated to use the same UI and filters as our new study-level (global) survey and repeating data listing pages

User management

• We have added a PUT API endpoint that allows you to change the permissions of users who have been added to the study.
• We have added a new DELETE API endpoint that allows you to remove users from studies.

Forms

• We have removed the support for the use of randomization outcomes in the calculation field. New studies and studies that have not used the randomization field tag in calculations are no longer permitted to use these tags. A tag that returns if the participant is randomized can be used instead.
  • In addition: we will remove Randomization fields from the Study data export in the 2023.3.0.0 release as they are redundant due to the dedicated Randomization Group column. We kindly ask you to update your analysis scripts to use this column rather than the value of a manually added Randomization field.
• We have added the variable "{participantWasRandomized}" which can be used in calculation fields to determine whether or not a participant was randomized. If the participant is randomized, the variable returns 1; otherwise, it returns 0. 
• We have added the ability to drag the 'Add/Edit Field Modal'. You can now move the modal across your screen to see the fields listed beneath it.
• We have added a restriction for moving fields: fields within Repeating Data or Surveys can no longer be moved outside of their current Repeating Data or Survey.
• We have updated the repeated measure field. The date formats used in the field do now reflect the date formatting preferences set in the Study Settings.

Miscellaneous

• Audit trail
  • We have limited the counter in the audit trail's pagination component for performance gains. Now, once 1000 results are found, the pagination component will show ‘1000+’  and the exact (total) number of found events will not be displayed anymore. A tooltip has been added on the pagination itself to guide the end user to the filters. For audit trail views that have thousands of events already logged, the loading time on this page will be faster due to this change.
• Participants
  • We have extended the use of the View randomization site permission to the corresponding filter criteria. Now, beyond users needing these permissions to see information regarding the randomization allocation itself, they will also require it to see filtered results based on the randomization status. The information text associated with this filter criteria has been updated accordingly.
  • On hovering over the progress bar in the list ‘List', ‘Visit’ and ‘Form’s view of the participants listing, you can now see the percentage value of data collection completion.
  • Users can now clear the previous row selection easily from the global study participants listing. The  selection is not automatically cleared after the action has been performed, as long as the user stays on the same study, does not reload during a continuous session.
• Clinician facing Survey views
  • Users can search by the participant ID by typing into the new search bar shown in the study-level (global) surveys overview that clinician can access in CDMS. The search functionality works based on 'contains', without any minimum restriction of the required number of characters.
  • The user selection for the column visibility, as well as for the column width, is persistent all the time, throughout multiple sessions.
  • Users can now clear the previous row selection easily from the global survey package invitations listing. The same is available on the participants page.
  • The character limits for mobile survey notifications have been extended and clarified - allowing 50 characters for titles, 200 for content
• For users of Form Sync, we've changed the routing behavior to allow a redirect on the  Form Sync page when switching between the linked test and production studies.
• On the Dashboard, users can now increase or decrease the default size of the metrics widgets.  The first column of tables is now fixed, so that users can scroll horizontally without losing sight of the row’s details.
• We’re enabling the edit function for both the email subject and the invitation message inputs within the Automation Engine for all survey package invitations using Castor Connect. This was previously available only for survey package invitations sent via email.
• We have added an option to display a custom button with a link on the login page for private server instances.

 System defects fixes

• In the last release, the previously unavailable/inactive ‘Resend’ options for mobile survey packages became available erroneously, causing confusion for some users. We have hidden/removed this option again.
• We've fixed an issue that rendered a mismatch between the  “Randomized Participants” and “Randomization Overview” metrics shown in the Randomization tab of the dashboard. 
• We've addressed an issue regarding the logged user name in the audit trail for events of dropped signature on repeating data forms after import. When the value of a field in signed repeating data instance is updated through data import, both the form signature and instance signature audit trail events are now logged as being automatically done by the system.
• We have fixed an issue that did not return results after reloading any monitoring page with the data rage filter applied.
• We've fixed an issue that was temporarily (until page reload) removing the SDV icon from the form or the visit after the user has removed a previously applied custom verification.
• We have fixed a defect on data import, that did not correctly update the SDV status of all affected participants after values were changed via import fields
• We have resolved an issue where in some circumstances, importing/updating data via the data import feature that had already been SDVd would not drop the SDV already applied
• We've fixed a defect that did not notify the user of the wrong email being supplied in the signature flow. This was occurring solely after a page had been manually reloaded.
• We've fixed an issue rendering an error on the Form Sync page when Form Sync is giving an error when at least one instance of a repeating data was found in the production study and some of its forms has been deleted in the linked test study.
• We have resolved an issue that prevented proper validation on the participant email when the entered email address contained hidden whitespace(s).
• Resolved an issue where custom verifications for studies weren't being dropped when new data is imported for a patient using the study data import feature
• Updated the display of partial date values to use ‘UK’ (or not) consistently across data entry views
• We resolved issues in the as-yet unreleased web surveys pilot, including where dropdown options weren’t displaying correctly when contained within grid fields and enabling the display of partial date fields correctly in mobile view
• We have fixed a defect related to special characters in the file names of repeating data and surveys data exports. File names of exports are now escaped and do not contain special characters anymore.
• We fixed a defect related to the user import feature that allowed the same user to be imported twice in the same file and for the same site, but with different roles.
• We have fixed a defect related to autocorrect on mobile phones replacing the email address on the login page.
• We have fixed a defect related to copying repeating data with image fields.
• We have fixed a defect related to the FHIR import process.
• We have fixed a defect that resulted in no participant statuses being displayed during printing.

Ongoing pilots

• In our previous release (2023.1) we made a new web survey UI available on a request-only basis via our support team. Users can continue to request that the new UI be turned on for piloting to provide invaluable feedback, or turned off having finished piloting, through our support team. 
  • As we continue to assess and incorporate user feedback, Castor plans to make this new web survey UI the default for all new studies later this year

Advanced notice of API updates

• In our next release (2023.3) we plan on deprecating auto_send in the Castor public API in favor of available_from - functionally this will work in the same way, but will need to be considered by users of our API

Minor release 2023.2.1.0 - Release date 8th June 2023

• We have fixed a defect related to our database connections that was affecting system performance.

Hotfix release 2023.2.1.1 - Release date 13th June 2023

• We have resolved an issue where the planned send date for surveys would erroneously display an incorrect date. Surveys were/are being sent correctly - but the information being presented to users of the CDMS was incorrect, and implied they were not.
• We have fixed an issue that blocked users from creating a new linked study with Form Sync.
   

Minor release 2023.2.2.0 - Release date 6th July 2023

New features and / or  enhancements

Queued SDV status update processing

• The source data verification status (re)calculation will take place asynchronously (in the background) for some system events, to better support reflecting structural and SDV plan changes across a larger number of participants. 
  Note: Due to technical considerations (for studies with a large number of participants or complex structures), the SDV status will begin to be recomputed 2 minutes after the structural change has been completed. This fixed time-bound delay is actively being worked on and improvements will be rolled out in upcoming versions, to ensure a smooth update

Email assignment mandatory for Castor Connect study participants 

• In support of Castor Connect 2023.1, in which we add the ability for participants to request a remote PIN reset - which requires that a reset email and unique link be sent to the participant - we have added a number of checks when sending a mobile survey, or managing activation for a participant who does not have an email assigned. This is now required.

System defects fixes

• We have addressed an issue where  specific non-printable characters were causing unnecessary Form Sync changes to be detected. The underlying comparison logic has been updated to ignore these special non printable characters.
• We have added the "Find Annotation" modal to the redesigned Add/Edit Field Modal.
• We have resolved an issue where users were able to import repeating data into locked instances.
• We have fixed an issue that was preventing 'Multiline' text fields from properly expanding while previewing before printing.
• We have fixed a defect related to archived repeating data instances appearing in exports available through the API. The export files now only contain instances that are archived if the archived API parameter is set to 'true'.
• We have adapted the study invitation email sent to new users that are affiliated with an email domain that uses SSO.
• We have fixed a defect related to option group options not displaying when printing a single form.
• We have updated the study package name column for the survey overviews to make them expandable in the same way as other columns
• We have resolved an issue where 'Selecting all' on pages of the survey overview was replacing previous selections rather than adding to their total.
• We have resolved an issue where the bubble number indicator for the filters available on the survey overviews was double-counting surveys that are assigned to a visit or form.
• We have fixed a defect where users were not able to reset their password if their first and last name had not been set before.

Hotfix release 2023.2.2.1 - Release date 13th July 2023

• We have fixed an issue related to the escaping of negative numbers in generated exports. 
• We have improved the performance of opening data entry, listing repeated measures, and listing repeating data for a participant.

Hotfix release 2023.2.2.2 - Release date 19th July 2023

• We have resolved an issue where participants using Castor Connect who entered a data field with a ‘current date’ validation after the date the data was captured
• Improved performance for studies using the SDV plans feature with a large number of datapoints or participants that were experiencing slowdown when opening records

Hotfix release 2023.2.2.3 - Release date 16h August 2023

• We have fixed an issue with automatic emails, where these would not be sent out properly when users had a comma saved in their name details.