Site users and subject data

Form status isn't updated correctly when questions are auto-populated

Site users now see the form status marked as Complete after auto-populated questions are answered, allowing actions such as dispensing to proceed as expected. Previously, completed 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 applied fix adds a retry logic so that form and visit statuses are reliably updated even if a database error occurs.

(Issue 38209696)

Lab form status now correctly updates after data entry

Lab forms with repeating sections 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)