Missing verified records after data update

Now, SDV actions on standard repeating forms (Sign, Verify, Freeze, Lock) are stored with the correct INNER_REPEAT number, so Oracle Clinical One Analytics displays them against the right items. Previously, when completing form-level verification on a standard repeating form, the INNER_REPEAT number could be saved incorrectly for these tracking records. As a result, Oracle Clinical One Analytics displayed actions on the wrong repeat, even though the core Oracle Clinical One Platform showed statuses correctly and the study data tables had the correct repeat links.

(Issue 37999017)

Oracle Clinical One Analytics API pagination issues

Oracle Clinical One Analytics APIs now return consistent, complete results regardless of limit values, ensuring API pagination is stable across data sets and studies. Previously, applying limits returned varied or mismatched result sets, hindering data reliability and complicating data analysis. The applied fix standardizes the pagination logic and ordering, so users receive predictable API results that can be aggregated safely.

(Issue 38331231)

The Subject Forms dataset doesn't show full audit history

The Subject Forms dataset now shows both current records and the full audit history of form updates, rather than only displaying the current status. Previously, users couldn't view all past status changes - records that were version ended were omitted from the dataset, which made it difficult to track historical form status changes. After this fix, users can see a comprehensive audit of all form updates, including historical data related to form status, improving transparency and traceability.

(Issue 38274625)

Visit status updates prevent duplicate visit IDs and lock errors

Visit status updates now create only one record per visit, even after long-running queries or database disconnections. Previously, partial commits or connection failures caused duplicate visit instance IDs in the DC_VISITS_INFO table in Oracle DMW, leading to inconsistent data and lock errors. This fix ensures each update or data insert runs only when appropriate, aligning the visit schedule and status APIs with actual database content. Users will now see accurate visit status without duplication or data conflicts.

(Issue 38120683)

Advanced Study Versioning (ASV) changes now correctly applied to approved study versions

ASV changes are now applied only to approved study versions when a study is moved from Testing to Approved. Previously, ASV updates intended for Testing mode could unintentionally affect both test and approved study versions, leading to metadata differences between older and newer Oracle DMW metadata points. This fix ensures that ASV changes affect only the intended study versions, preventing unintended data changes and improving consistency across studies in Testing and Production modes. Users will now see accurate metadata for Production studies.

(Issue 38278228)

Oracle DMW form values display incorrect data

Numeric values in ITEM_F fields are now displayed correctly. Previously, the system captured data from an incorrect source, resulting in numeric item types to display inaccurately.

(Issue 38239994)

ITEM_F columns display incorrectly for measurement item types in Oracle DMW

Now, the ITEM_F columns in Oracle DMW are visible and display the correct values for measurement item types from the current schema, ensuring values are populated accurately. Previously, if a measurement item was set as text in the previous architecture, some data extraction errors would occur. This fix ensures that each item's value is sourced using up-to-date information, preventing type mismatches and improving data reliability.

(Issue 38219969)

ITEM_F data element displays inaccurate data

ITEM_F data elements in Oracle Clinical One Analytics now correctly display both date and time, and future dates are no longer shown as past dates. Previously, after a system architecture change, ITEM_F data elements dropped the time component and incorrectly displayed future dates as dates in the past. This happened because the system truncated timestamps, removing the time and misinterpreting some dates. The issue was resolved by adjusting the logic to preserve the full date and time values, using a more accurate conversion method.

(Issue 38144855)