Repeating form status is inaccurate when adding or removing instances

Now, adding or removing a repeating form instance doesn't change the status of other instances in the database. Previously, creating or deleting a repeating form could unexpectedly mark earlier form instances as incomplete or completed, causing confusion and potential data issues in reports. With this fix, only the correct instance's status is updated, ensuring all repeating form statuses remain accurate and reliable.

(Issue 38198276)

Duplicate code list options appearing in forms

Choice questions (check boxes and radio buttons) show each choice only once, as specified in the associated code list. Additionally, users can change answers without errors, and dynamic questions appear correctly, if associated with any choices in the radio button question. Previously, some code list values differentiated only by trailing spaces, caused duplicate options and blocked answer changes. This issue also prevented dynamic elements (questions, forms, sections, form associations) from being displayed. For example, a question displayed two "Yes" options, and selecting either of them produced errors and hid a dynamic child question. We adjusted the process used to identify Advanced Study Versioning changes to the study to ensure only new, removed, or modified code list labels are updated, while leaving unchanged labels as is.

(Issue 38255228)

Forms incorrectly pre-filled with data

Now, lab forms with automated query custom rules only display data for the current visit, preventing confusion. Previously, data entered in a lab form associated with Visit A, for example, could incorrectly appear in the same lab form for Visit B, even though no data had been entered during Visit B yet and no data was actually saved in the database. The issue is fixed by adding a check for the current visit ID, making sure only the right data displays.

(Issue 38316955)

Errors occur when saving data for Route of Administration and Indication terms

Now, when both Route of Administration and Indication are used as context items in Oracle Central Coding, and both are populated by rules, they will be transferred, as expected. to Oracle Central Coding with the verbatim term. Previously, after the rules populated the values on the form, an error could occur during the transfer process to Oracle Central Coding that would result in the context items not being transferred as expected.

(Issue 37669804)

Visits are grouped incorrectly after study version and branch updates

The visit order now follows the schedule of the study version in which the most recent visits were completed. Previously, if multiple branch visits were completed by subjects in different study versions, and the visit branch schedule changes (for example, a visit or branch visit is removed, added, or re-ordered), visits could be incorrectly grouped at the end of the subject's visit schedule.

(Issue 36400347)

Form status isn't updated correctly when questions are populated by custom rules

Site users now see the form status marked as Complete after questions populated by calculation rules are answered, allowing actions such as dispensation to proceed as expected. Previously, completed non-repeating, one-section (flat) forms incorrectly displayed as In Progress when some fields were filled by custom JavaScript rules, preventing certain actions and impacting downstream integrations. The change ensures that form and visit statuses are updated appropriately when one or more questions within the visit are populated by a JavaScript calculation rule.

(Issue 38209696)

Status of lab form with hidden or optional questions doesn't update after data entry

Lab forms with only hidden or optional questions in the flat section now show a Complete status after all required questions are answered and data is saved. Previously, even when users completed all required questions, the lab form status remained Incomplete, causing confusion. This fix ensures that completing all required questions updates the lab form's status, aligning the visible status with the backend logic, and allowing clearer tracking of visit progress and completion.

(Issue 36505556)

System doesn't consider the latest study version for a locked and skipped visit

The system now correctly displays and locks forms from the current study version, even when a visit was skipped in an older version. Previously, when a visit was skipped in an older study version, and then locked in a new study version, forms in the new study version displayed incorrectly. Additionally, new forms associated with the new study version appeared as Not Answered in the old study version.

(Issue 38193545)

Unable to enter data in a subject visit due to duplicate form level signed records being created

Now, site users can enter data in a subject visit, and depending on whether the data is signed or unsigned afterwards, only one form level record, either signed or unsigned, is generated. Previously, site users were not able to enter data in a subject visit due to duplicate form level records, both signed and unsigned, being created, resulting in system errors.

This issue occurred when data was previously entered into a form through the execution of custom JavaScript rules.

(Issue 37845829)

Scheduled visits now display only after completing current visit

Scheduled visits are now displayed in a subject's schedule only after the current required visit is fully completed. Previously, if a user started an unscheduled visit after branch visits had begun, simply answering any question in it could incorrectly display the next scheduled visit in the subject schedule - even when the current visit was not completed. For example, entering a date in an unscheduled visit could cause Visit 5 to appear before Visit 4 was done. The fix excludes unscheduled visits from the scheduling logic to ensure accurate sequencing.

(Issue 38260677)

Unable to complete choice questions that contain more than 10 options

Now, the system saves selected answers for choice questions that contain more than 10 options. Previously, if you selected an option in position 10 or greater for a choice question, the system would present a misleading error message and prompt you to refresh the page. In turn, this blocked you from saving the form. This fix restores consistent data handling, ensuring forms with many choices work as expected.

(Issue 38235953)

Visit status remains as In Progress when all questions are populated by rules

Now, when all form questions in a visit are populated using custom JavaScript calculation rules, the correct visit status is displayed as Completed. Previously, the visit’s status remained In Progress even after all fields were populated by the calculation rules. In order to update the visit's status to Completed, site users had to manually re-enter the visit date as a workaround. With the fix, when all required fields in a visit's forms are populated by JavaScript rules, the visit status now correctly updates to Completed, with no need for further user input.

(Issue 38247383)

Extra visits are added in a subject’s visit schedule

Now, if a site user navigates to another subject, using the subject selection drop-down in the upper-right corner of the Visit page - while data is saving for the current subject - there is no longer a risk that unexpected visits will be added to the new subject's visit schedule.  Previously, navigating between subjects while subject data was saving for the original subject could result in visits that exist for the original subject, being incorrectly added to the second subject's visit schedule.

(Issue 37110046)

Lab normal updates not saved if rule execution fails

Lab normal values are now correctly saved and reflected in lab forms, even when the process of running a rule fails. Previously, if lab forms had custom JavaScript rules referencing lab normal ranges, any update to lab normals (such as adding or updating missing low or high values), or adding/updating referenced data (eg. gender, date of birth) failed silently due to a backend rule error. This prevented updates from appearing in subjects' forms. To fix the issue, the process of running custom JavaScript rules is separated from the process of saving data, allowing lab normals to be stored even if rules don't execute successfully.

(Issue 37914482)

Previous visit becomes the current visit in the schedule when cleared and its status moves to New

Now, when a previous visit's data is cleared and its status updates to New, the current visit remains the current cycle's visit. Previously, even when there were other visits in the schedules, a previous visit would become the current cycle's visit when its data was cleared and the status updated to New.

(Issue 37375385)

Dispensation Information dialog displays screening number

Now, after randomization is complete and drug dispensation is initiated, the Information dialog displays the randomization number. Previously, the Information dialog showed the screening number instead of the randomization number after randomization completed and drug dispensation was initiated.

(Issue 37768406)

System allows additional data entry before data fully refreshes

Now, after you enter data in a form containing date/time questions and click outside the form to allow saving and validating, the system disallows any additional data entry. Previously, after a user would enter data for a form that included date/time questions, the system would continue to allow additional data to be entered before the data could refresh through the saving and validating process. This resulted in a system generated error.

(Issue 37258410)