In DMW you can blind data in your study using different levels of blinding types (table, column, row, cell), and you can specify how the blinded data should be masked, e.g. using hardcoded ‘999999’ for numeric values, or ‘XXXXXX’ for character values. But more advanced blinding can also be accomplished, e.g. blinding of data using random date within FPFV and LPLV, random values from a codelist applied for field validation, e.g. simple Yes/No, or AE relation to trial product: LIKELY, UNLIKEY, POSSIBLE, PROBABLE.
You can use the Oracle database package DBMS_RANDOM and its function to generate a random value, e.g. random integer from 0..6, and then use the DECODE to set a value depending on the random value generated.
Example: Random value generated from codelist for Action taken to Trial Product in SDTM-AE (Adverse Events):
Codelist Value assignment
DOSE NOT CHANGED
Random codelist value assignment for use with Bliding and masking criteria in Oracle DMW.
Note: For random date you will need to write a function to lookup and return a valid date from within FPFV to LPLV.
If you want to know more or need help to implement more advanced blinding solutions in Oracle DMW, please contact us.
In order to read study data in DMW from visualisation tools like QlikSense or Oracle Analytics Cloud (OAC) you must first initialize read on Business Area (BA) in LSH database before you can issue a SELECT statement to query data in the business area. The problem is, that QlikSense and OAC only allows you to issue a SELECT statement, but not a procedure call, which is required to initialize read on BA via API procedure call in LSH database.
The problem can be resolved by use of a trigger solution, that automatically initialize read on selected BA’s after logon and connection to LSH database is established.
Please contact us if you would like to know more about this solution.
If your company is moving from Oracle Clinical (OC)/TMS to DMW/TMS we have a solution in place for bringing over the TMS Learnings (VTAs) that your medical coders have created over the past many years.
The number of manually created TMS codings is typically in the houndreds of thousands for large pharmas coducting many large scale trials.
Most companies want to bring over the TMS Knowledge database when migrating to a new platform, e.g. DMW/TMS, where TMS is new fresh install with new dictionaries and no previous coding knowledge (VTAs).
Note: TMS Learnings (VTAs) can be created in TMS target system prior to verbatim arriving from DMW.
TMS VTA copy solution can be used for:
Migration of TMS knowledge database from OC/TMS -> DMW/TMS
Migration of TMS knowledge database from one environment to another, e.g. Prod to Train for training of medical coders.
Please Contact us if Your company is interested in hearing more about our solutions for bringing over TMS learnings from one TMS source instance to another TMS target instance, e.g. if your company is moving from OC/TMS to DWM/TMS, or if you want to copy the TMS knowledge database from one TMS instance to another, e.g. copy from TMS production to TMS training environment.
OC: Oracle Clinical | DMW: Data Management Workbench | TMS: Thesaurus Management System | VTA: Verbatim Term Assignment (TMS learning created during manual coding (classification) of verbatim term to a dictionary term).