Oracle Clinical One Analytics

Data Hub APIs for several datasets retrieve data with delays

Data Hub APIs now respond within the expected time frames for all Oracle Clinical One Analytics datasets, including the Study Codelist dataset and the Subject Form Items dataset. Previously, users may have encountered delays - sometimes over 15 minutes - or API failures when retrieving data. This fix improves how study data is handled during API calls, resulting in faster response times across multiple endpoints. Users can now reliably run APIs without unexpected timeouts or performance issues.

(Issue 38489911)

Data Hub APIs for the Subject dataset may time out

Data Hub APIs now return results quickly when accessing the Subject dataset or other data sets, such as the Subject Form Items or Subject Forms datasets.. Previously, users may have experienced timeouts when retrieving code list data due to slow back end processing. This was caused by back end queries taking a longer time to complete. With this fix, data retrieval through APIs works as expected for code lists and other data types.

(Issue 38515304)

Testing mode didn't surface Advanced Study Versioning (ASV) changes in Oracle DMW and Oracle Clinical One Analytics

Now, when a study version that includes ASV changes is moved to Testing mode, any subject data collected for forms and questions introduced or modified through the ASV process is correctly sent to Oracle DMW and Oracle Clinical One Analytics. Previously, data entered in Testing mode for Active study versions that used these ASV items wasn't transferred, resulting in incomplete runtime data for Testing mode in Oracle DMW and Oracle Clinical One Analytics.

Note:

This fix applies only to data captured after the fix is deployed. Existing Testing mode data from before the fix remains unavailable in Oracle DMW and Oracle Clinical One Analytics.

(Issue 38359126)

Incremental data load takes too long to process

An optimized algorithm now more efficiently identifies and processes only the relevant changes, significantly reducing the incremental load execution time by up to 40%. Previously, the incremental load process may have exceeded 30 minutes under certain scenarios observed in Production, as all candidate records were considered for a data update. With this enhancement, the system is more responsive and puts less unnecessary load on the database, while maintaining data accuracy.

(Issue 38055482)

ODM API doesn't return demographic fields when authorized

The unblinded ODM extract now consistently includes subject demographic fields - date of birth, gender, race, and ethnicity - when the API caller's study roles has the required data classifications and permissions. Previously, these read-only items were omitted from the JSON response even for authorized users, because the extract logic skipped hidden or read-only demographics and applied outdated access checks for users. This caused incomplete data in reconciliation and safety database uploads. The fix updates the API's permissions framework to use the new access control view introduced in the Oracle Clinical One Analytics architecture, ensuring demographics and other restricted items are properly returned. Similar improvements were applied across related datasets for consistent item access: Subject Forms dataset, Subject Form Items dataset, Subject Item SVFL dataset, and the Queries dataset.

(Issue 38469837)

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)