Forms, visits, and rules
Validation rule update does not work for updated Age field (former known issue)
Study designers: Now, when you update the validation rule of an age question and apply that change to an existing live study version, the updates are displayed in Production mode, as expected. Previously, whenever you performed this type of advanced study versioning update, you may have noticed that the changes were not appearing in the live study version.
Retracted workaround: None. (Issue 32591313)
Certain visit types are missing from older versions of the Visit Status API (former known issue)
Users working with REST APIs: Now, you can use any version of the Visit Status API endpoint and you will get an expected response of 200 (if the parameters are correctly specified). Previously, when using the Visit Status API endpoint (versions 2, 3, and 5), you may have noticed that the response was missing certain visit types. The missing visit types were: unscheduled, unscheduled_dispensation, optional, adverse_event, and randomization (specifically for version 2 of the Visit Status API).
Retracted workaround: You no longer have to exclusively use the latest version of the Visit Status API endpoint. (Issue 33545732)
Decimal number can be entered in Count of Cycles field (former known issue)
Study designers: Now, on the Create Branch and Edit Branch dialog, you can only enter a whole number in the Count of Cycles field, such as 12 or 5. Previously, the application let you add decimal numbers.
Retracted workaround: You no longer have to double check the Count of Cycles field to make sure that you didn't enter a decimal number. The application does not save the changes unless you enter a whole number. (Issue 32096978)
Effective range validation rule must be defined first (former known issue)
Study designers: Now, when defining the details of a number type of question that must be used in a randomization design, it does not matter if the range validation rule is placed first in the list of validation rules, for your randomization design to work. Previously, if the number type of question had to contain other types of validation rules, but the range validation rule wasn't first in the list, the question could not be selected when defining the stratified or demographic cohort randomization. Other times, on the Randomizations tab, the cohorts were not even displayed properly.
These issues are now fixed.
Retracted workaround: You no longer have to make sure that the range validation rule is defined as the first rule for the number type of question. (Issues 32279735, 32279746)
Inserted and updated visit is not displayed for subjects (former known issue)
- When you update an inserted visit to have it displayed for future subjects only (after it was previously displayed for both future and past subjects), this could result in the visit that was previously displayed for a subject to disappear, as a result of this update.
- When you update an inserted visit to have it displayed for future and past subjects (after it was previously displayed only for future subjects), this may result in the visit appearing for subjects when it wasn’t previously displayed.
Retracted workaround: None. (Issue 33179207)
A screening visit’s status is affected by a newly added form (former known issue)
Study designers: Now, when you add a new dynamic form to a Screening visit in a live study (through advanced study versioning), the status of that updated Screening visit remains Complete. Previously, after performing this update, you may have noticed that the screening visit to which that form was assigned had a different status, even though the form was not even displayed.
Retracted workaround: None. (Issue 33497799)
Dynamically displayed visit incorrectly placed in the schedule (former known issue)
Study designers: Now, when you dynamically schedule a visit, that visit is properly displayed in a subject's schedule. Previously, there were issues with a dynamic visit was included in a subject's schedule.
Retracted workaround: You no longer have to enter a visit start date for the dynamically displayed visit. The visit is already correctly placed in the study schedule. (Issue 33625797)
Slower than expected response time for an aeCount API request
Users working with REST APIs: Now, you will no longer experience increased response times when using the aeCount REST API to retrieve a list of adverse event visit counts for a given list of subjects. Previously, when using the aeCount REST API you may have noticed it was taking longer than expected, sometimes minutes to receive a reply.
Retracted workaround: None (Issue 32606237)
Fix Version: 21.4.0.6
Parent topic: Fixed issues