Forms, visits, and rules

Adding new rules and updating existing data takes an inadequate time to process in Production mode

When adding a new rule or updating saved data, the application now processes these changes in an adequate amount of time. Previously, changes made to existing data took over 30 seconds to be saved, while adding a new rule took more than a minute for the application to finish processing.

(Issue 38267486)

Duplicate queries no longer block closing automated queries

Users can now successfully close automated queries using custom JavaScript rules, even when duplicate or deleted entries exist. Previously, attempts to close such queries failed with an error if the application encountered duplicate records - including deleted ones - which prevented it from finding the correct open query. This fix updates how queries are identified for closure, ensuring that only active, relevant queries are targeted. As a result, users no longer experience errors when closing queries in these situations.

(Issue 36465916)

The getValues() helper function does not return accurate results when data flags are present (former known issue)

Using the getValues() helper function returns accurate results when questions include data flags. Previously, using the getValues() helper function to check for NULL (missing data) on date/time questions on a repeating form did not return accurate results if questions included a data flag such as Not Done, Not Applicable, or Unknown.

(Issue 36496392)

Date and time items display inaccurately in forms

Date and time form items display correctly. Previously, date and time components appeared inaccurately for certain columns.

(Issue 38144855)

Unable to complete the randomization visit for a subject

You can now complete randomization visits without unexpected errors, allowing the visit status to update properly. Previously, when the configuration service was down, the system couldn't complete the visit status update, leaving visit stuck in a status of In Progress and preventing progression to the next visit.

(Issue 37102836)

Saving the Visit Start Date field might take longer when numerous visits exist in a study (former Known Issue)

When you save the Visit Start Date in a study that includes a large number of visits, the time it takes the system to save the data has improved to a more acceptable time frame.

(Issue 32342403)

Rule validation text is not displayed for read-only questions

Now, validation error text displays for read-only items. Previously, when a validation rule failed for a read-only question, a red border indicated validation failure, but the associated validation description text, for example, You have not selected the required option, did not display.

(Issue 34785185)

Cannot screen subjects due to a mix of mandatory and optional questions

A screening form now works as expected, allowing users to screen subjects without answering all questions. Previously, the system incorrectly prevented the screening if a non-mandatory question had dynamic dependent questions, requiring users to answer those items even if the initial question was left blank.

This fixed issue is part of a new feature. For more information, see Improved data entry workflows for Data Collection and Randomization and Trial Supply Management (RTSM).

(Issue 37077702)

Dynamic question item continues to appear intermittently after changing the initial answer value

Now, when you change an initial answer for a dynamic question that is configured to trigger additional questions, the new question is cleared and hidden. Previously, when an answer value was changed for an item containing a Show Question rule that elicited additional questions, the new questions would intermittently display and disappear.

(Issue 36626039)

Unable to enter data into dynamic visits in cycles

Now, users are able to enter data into dynamically triggered visits in cycles. Previously, when Day 1 Dispensation for a cycle was initiated, the Day 1 visit in any cycle would not display, and the visit would be moved to the next cycle. This prevented users from accessing the visit entirely.

(Issue 37375355)