| Oracle® Health Sciences Data Management Workbench User's Guide Release 2.4 E52292-02 |
|
|
PDF · Mobi · ePub |
Home > User's Guide > Administration
| Oracle® Health Sciences Data Management Workbench User's Guide Release 2.4 E52292-02 |
|
|
PDF · Mobi · ePub |
Home > User's Guide > Administration
Some administration tasks are done partially or entirely in the Oracle Health Sciences Data Management Workbench (Oracle DMW) user interface, while others require logging in to the Oracle E-Business Applications Suite.
The File Watcher utility checks a file system location that you specify for data files whose name matches a pattern you specify and loads them into Oracle DMW.
Prerequisites These tasks are documented in the Oracle Life Sciences Data Hub Installation Guide:
Set up the Oracle LSH Distributed Processing (DP) Server and, as part of it, the File Watcher service. The File Watcher service detects files to be loaded.
Define at least one DP Service Location and SAS and Text for SQL*Loader DP Server services in the Oracle LSH user interface. These services load data from files into the Oracle DMW database. See the Oracle Life Sciences Data Hub System Administrator's Guide.
Create nested directories for files to be loaded. They can be on one or more computers to which the DP Server has access:
A root folder on each computer from which files are loaded into Oracle DMW.
Either three or six subfolders:
Three folders, one for each lifecycle. Both SAS and text files are placed in the same folder.
Six folders, one for each lifecycle/file type combination. Each folder is used for only one file type, either SAS or text.
Create nested directories for loaded files to be archived:
A root folder on each computer where you plan to archive data files. Oracle recommends archiving files on the same computer and same file system for efficiency of moving the files to the archive folders.
Either three or six subfolders for archiving. These must correspond to the three or six subfolders you set up for loading data.
Security for the folders.
Compatible time zone configuration on each computer.
Register the location of the subfolders for loading and archiving files in Oracle LSH system profiles; see "Registering Folder Locations".
For each study, specify a study-specific folder name; see "Creating and Modifying Study File Watchers".
For each file data source in each study, create an input clinical data model with a File Watcher file specification; see "Creating a Study Clinical Data Model" and "Configuring File Watcher".
For each data source across all studies, register the data source in the Oracle DMW; see "Viewing and Setting Up Lab Data Sources".
Log in to Oracle LSH as system administrator. See "How to Log In to Oracle Applications Profile Forms".
Register the root folder locations in Oracle LSH profiles; see "Registering Root Folders for File Watcher Watched Folders".
Changing the root folder location is disruptive to the flow of work in Oracle DMW and should only be done with caution. However, you can modify the location if necessary:
Create new root folders in the new location for both watched and archive folders.
Change the value of the LSH profiles to the new location. See "Registering Root Folders for File Watcher Watched Folders" and "Registering Root Folders for File Watcher Archive Folders".
Restart the Distributed Processing Server that includes the File Watcher service. Instructions are in the Oracle Life Sciences Data Hub System Administrator's Guide.
Open each study File Watcher in Edit mode and click Regenerate to apply the new settings in the study; see "Creating and Modifying Study File Watchers".
The system then:
Migrates all existing Study File Watchers to the new root folders.
Processes any files already submitted for data load at the time of the change.
Does not move existing files to the new location.
The system does not move any files. You must: .
Determine which files have not been loaded, if any, and move them to the new location.
Determine which loaded files have not been archived or deleted, if any, and move or remove them.
Specify the Distributed Processing (DP) Service Location to use for loading SAS and text files. These settings apply to all Study File Watchers of the corresponding file type.
Note:
The DP Server should have been set up during Oracle DMW installation. See the Oracle Life Sciences Data Hub Installation Guide and the Oracle Health Sciences Data Management Workbench Installation Guide for more information.In the Watcher Listing pane of the Administration page, click the DP Servers for File Watcher icon. The DP Servers for File Watcher window opens.
Text DP Server: From the drop-down list, select the DP Service Location to use to detect text data load jobs.
SAS DP Server: From the drop-down list, select the DP Service Location to use to detect SAS data load jobs.
Click OK to save.
To improve File Watcher performance, minimize the number of data files in the watched folders by either permanently deleting them or moving them to an archive folder automatically.
When you create a study File Watcher you must specify a number of days after the load date to delete data files. If you prefer to archive the files, specify fewer days before archiving them. The system either archives or deletes data files, depending on which number of days is smaller.
When the system moves a file to an archive folder, it appends the current timestamp to the file name to ensure uniqueness.
To set up archiving:
Log in to Oracle LSH as system administrator. See "How to Log In to Oracle Applications Profile Forms".
Register the archive root folder locations in Oracle LSH profiles. See "Registering Root Folders for File Watcher Archive Folders".
Enable archiving and specify the number of days after loading data to move the file to an archive folder, using Oracle LSH profiles; see "Registering Root Folders for File Watcher Archive Folders".
For each study File Watcher, specify a larger number of days in the Delete Files After field than in the Oracle DMW:FWR_ARCHIVE_SCHEDULE_DAYS profile.
Note:
If you enable archiving after setting up a study File Watcher, open the study File Watcher in Edit mode and click Regenerate to apply the new archiving-related profile settings to the study.For each study, define a study folder name. The system uses this folder name to create study-specific File Watchers and archive folders in the root folders you create and register; see "Registering Folder Locations".
To create study file watchers:
In the Administration page, click File Watcher in the left pane. The Watcher Listing window opens.
Click The Add Icon. The Create Study File Watcher window opens.
Note:
You get an error if you try to create Study File Watchers before the folder locations are defined in the LSH profiles; see "Registering Folder Locations".Study: Select the name of the study from the drop-down list. The list includes studies with no existing study File Watcher.
Study Folder Name: Enter a valid UNIX case-sensitive directory name with no underscores (_) to be used as the final directory of the watched folder path after each root folder. The Study folder name must be unique within the Oracle DMW instance and you will receive an error if the name you enter is already in use. You can see existing folder names on the File Watcher Listing pane.
The system creates the study folders in the locations you specified in "Registering Folder Locations". If you have enabled archiving and specified locations for archiving files, it creates study-specific archive files as well.
Delete Files After: To permanently delete files, enter the number of days after the load date to delete each file. To archive the files instead of deleting them, enter a higher number here than in the archiving profile value.; see "Registering Folder Locations".
Click OK.
If you have changed File Watcher profile values since you created the study File Watcher, click Regenerate to apply the current settings; see "Changing the Root Folder Location".
Click File Watchers at the bottom of the right-hand pane in the Administration page to see the File Watcher Listing pane. It displays information about each File Watcher, including:
Watcher Status (Running or Suspended). To change the status, click the Resume Watcher or Suspend Watcher icon.
Note:
If the Distributed Processing (DP) Server status is Offline, the Watcher cannot run, even if its status is Running. To start the DP Server, follow instructions in the Oracle Life Sciences Data Hub Installation Guide or the Oracle Life Sciences Data Hub System Administrator's Guide chapter on stopping and starting services and queues.You can suspend or resume data loading for a particular data source in the File Specification pane or in the corresponding clinical data model.
Exception messages for errors creating the study or archive folder. Possible problems include:
The UNIX user that executes the DP Server process does not have permission to create a directory in the File Watcher root folders.
The study folder name is not a valid directory name on the UNIX system.
There is a UNIX system issue, such as the file system's running out of space.
To read the error message, drag the column edge to make it wider.
Data load parameter values for text files for Release 2.3 File Watchers only.
To see the list of data load jobs for a study, their end status and a link to their log file, go to the Home page, Data Loads tab.
If you are using Oracle DMW in a hosted environment, the Study Folder Name/File Name Mismatch Report icon appears in the File Watcher Listing pane. The report is a listing of files that have not been loaded into any study because File Watcher did not recognize them as belonging to a study. This can occur if:
The study folder has not yet been created by the File Watcher service.
The file name does not follow the naming convention that is required in hosted environments of starting with the study folder name followed by an underscore.
Note:
This is different from the files listed in the Files Not Processed tab. Those files are associated with a study but do not match the required file specification.The system places such files in the Unknown_Study subfolder for the relevant lifecycle. The report lists all files contained in the folder, grouped by lifecycle. For each file, the report displays:
The file name.
The file modification date.
The file size, in bytes.
Correct the problem and resubmit the file to the hosted environment. When the file has been loaded successfully, request that the old file be removed from the Unknown_Study subfolder.
To run the report, click the Study Folder Name/File Name Mismatch Report icon and choose to open or save the file.
Create a list of all the labs that send files to be loaded into the system. This list populates the list of values for input clinical data models.
To add a data source:
Go to the Administration page, click Data Sources, click Lab, and then click the Add icon.
The system uses only the value of the data source name. All other fields are for your own records.
Data Source Name: Enter the name of the data sourceâfor example, Central Lab. This value appears in the list of data sources in the File Watcher configuration tab for clinical data models.
Description: Enter a description of the data source.
Contact: Enter the name of the person who should receive discrepancies.
Address: Enter the address of the lab or other data source.
Contact Number: Enter the telephone number of the contact.
Email Address: Enter the email address of the contact.
Send All Open Discrepancies?: This field has no effect in Release 2.4.
To change a lab data source definition, click the Modify Data Source icon, make changes, and click OK. See "Adding a Lab Data Source" for field details.
The Oracle Health Sciences Data Management Workbench Installation Guide for the first steps required to integrate Oracle Health Sciences InForm with Oracle DMW.
In the InForm tab under Data Sources on the Administration page you can define remote locations and web service locations for InForm studies. These definitions are available for use in the InForm Configuration tab of the Study Configuration page. They can be created, edited, and deleted there as well as here.
Create a database link to the InForm reporting database for the study:
Enter values for:
Name: Enter a name for the InForm database. Do not use spaces, slashes, or special characters other than underscore (_).
ConnectString: Enter the text for the Using clause of the Create Database Link SQL statement. This is normally the same as the Description Clause of a TNSNAMES definitionâfor example:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host_name.company_domain.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=trial_name.world)))
Note:
Do not use spaces.Username: Enter the name of the Oracle DMW read-only access account that has been set up in the InForm database for this remote location. See the section "Create Oracle Accounts for the Oracle DMW InForm Connector" in the Oracle Health Sciences Data Management Workbench Installation Guide for further details. The system will use this account to connect.
Note:
Do not use spaces or special characters other than underscore (_) in the username or password.Password: Enter the password required for the same user account. The system changes and encrypts the password after creating the database link.
In the unlikely event that you need to change the password, your InForm database administrator must change the password for the Oracle DMW read-only access account. You can then select Enable Password Entry? in the Edit Remote Location window and enter the new password. The system then recreates the database link and changes and encrypts the password.
Click Test Connection to make sure it is set up correctly. The system returns a success or failure message above the Test Connection button.
Click OK.
Study configurators add or edit a remote location database link in an InForm model, but only if data loading is not enabled and Development was selected as the current lifecycle area on the Home page.
Enter a value for:
Name: Enter a name for the web service location.
WSDL URL: Enter the web service URL for the InForm Adapter's Enhanced Discrepancy Interfaceâfor example:
http://your_InForm_Adapter_Server_name/InFormAdapter/Discrepancy/ DiscrepancyService.svc?wsdl
Authentication Trial Name: Enter the study name as defined when the trial was registered in the InForm Adapter; see the Oracle Health Sciences InForm Adapter Installation Guide for details.
SSO Organization: If your InForm installation, specifically the InForm Adapter, is hosted by Oracle, you must enter the organization associated with the DMW_QUERY user as provisioned for Single Sign-On use. Otherwise you must not enter anything in this field as it will cause harm.
Username: Enter the name of the account set up for authenticating Oracle DMW web service transactions. The default name is Oracle DMW_AUTH. See the section "Create Users in InForm" in the Oracle Health Sciences Data Management Workbench Installation Guide.
Note:
The Username and Password fields are not displayed if your company chose to install Oracle DMW supporting HTTP, not HTTPS.Note:
Do not use spaces or special characters other than underscore (_) in the username or password.Password: Enter the password required for the same user account. The system encrypts the password.
Click Test Connection to make sure it is set up correctly. The system returns a success or failure message above the Test Connection button.
Click OK.
Study configurators can add or edit a web service location database link for a particular study in the study's InForm clinical data model.
To remove a remote location or web service location, select it and click the corresponding Delete icon
To modify a remote location or web service location, select it and click the corresponding Modify icon. Modify values as required; see "Adding or Modifying a Remote Location" or "Adding or Modifying a Web Service Location".
You can make InForm metadata and operational tables available in Oracle DMW studies. The tables and views you select in the Administration page become the default selection for all studies. These choices can be overridden at the study level.
The system displays selected InForm tables and views in the Listings pages with their data and in the Transformations page as source tables. The system stores the tables and views in two internal clinical data models named Operational Data and Metadata.
Some InForm tables and views are required for internal Oracle DMW processing. These are displayed with a gray check mark. You cannot select or deselect them.
To select tables and views:
In the Administration page, click InForm tables and views under Data Sources.
The system displays all available InForm tables and views alphabetically. To sort by the internal data model they are part of if selected, click the heading of the Internal Data Model column.
Select the tables and views you want to include by default in Oracle DMW studies.
Save.
The system creates two internal clinical data models to store the InForm Metadata and Operational Data tables and views.
These tables represent the InForm metadata for the study. The metadata loading process uses these tables to define the tables in the InForm input data model.
All available InForm metadata tables and views are listed below. Those that are required in Oracle DMW and cannot be disabled are preceded by an asterisk (*).
In addition, the Metadata model includes the following required Oracle DMW tables:
These tables contain information collected during the course of the study that supports the clinical data, including InForm queries, form state flags, comments, and subject information. Tables that are required in Oracle DMW and cannot be disabled are preceded by an asterisk (*).
A category is a label that can be applied to discrepanciesâeither by a validation check or by a user directly in the Discrepancies pageâor to validation checks or flags. Categories allow you to group flags, validation checks, and discrepancies to make them easier to find. A discrepancy, validation check, or flag can have only one category at a time. Users can filter these objects by category.
If a category is applied to a validation check, the validation check applies the category to all discrepancies it creates.
Categories allow you to group flags by which data they are appropriate for. For example, the InForm flags imported with InForm queries are available only to data that originated in InForm. You can create other flags for lab data. For example, by linking categories to clinical data models of type Input and subtype File. In Release 2.4 linking categories to model types and subtypes is possible only by using a public API; see the Oracle Health Sciences Life Sciences Warehouse Application Programming Interface Guide.
You define any categories you needâfor example Range, Date Alignment, CTC Grading Rules, Preprocessing.
To create a category:
Click Categories at the bottom of the right-hand pane in the Administration page, then click the Add icon.
Enter values in the following fields:
Category Name: The label is displayed in the user interface as a filter and in all places where a user can read or apply it.
Description: (Optional) Enter a description explaining the intended use of the category. The maximum length is 500 characters. The description is displayed only on the Administration page.
For Discrepancies?: Select this option to allow users to assign the category to discrepancies.
For Validation Checks?: Select this option to allow users to assign the category to validation checks. All discrepancies created by validation checks assigned to the category will also be assigned to the category.
For Flags?: Select this option to allow users to assign the category to flags.
Note:
Flags are applied to data records, not discrepancies. Flags appear in the user interface as available to assign to a particular record only if they are assigned to a category that has been mapped to the type of data model the record is in. For example, the predefined InForm flags belong to the category InForm Flags which has been mapped to the clinical data model type Input and subtype InForm. You can create a category for flags appropriate to data in models of type Input and subtype File, or models of type Target.In Release 2.4 you must use public API createModelFlagcatMap to map a category to a clinical data model type or subtype. See the Oracle Health Sciences Life Sciences Warehouse Application Programming Interface Guide for more information.
You can map the same category to more than one model type or subtype. For example, you might have flags that you wanted to assign to input data no matter whether it was from InForm or a lab. You could create a category called Input Data Flags and run the API twice to assign it to both subtypes of Input models. A model type or subtype can have more than one category mapped to it.
Save. The system assigns an ID to the category that you can see in the Category Listing page.
A tag is a label that a user can apply to one or more discrepancies with an action. A discrepancy can have only one tag at a time. Tags have several uses:
Users can filter the data they view in the Discrepancies page by tag.
You can use tags to effectively create discrepancy substates. Define actions whose start and end state is the sameâfor example, Openâbut in which one applies a tag as a result tag and the others specifies the same tag as its start tag.
You can use tags to direct communication among teams while the discrepancy remains in the same state.
The system comes with a set of predefined system tags and actions; see "Out-of-the-Box Workflow" for a list of system tags as well as the system actions that apply them. You can change the name of system tags and enable or disable them. You can also create custom tags and custom actions, and you can use custom actions to apply system or custom tags.
Tags are available in all studies.
Click Tags at the bottom of the right-hand pane in the Administration page, then click the Add or Modify icon.
Enter values in the following fields:
Tag Name: This text is visible in the Discrepancies page. Spaces and special characters are allowed. The maximum length is 100 characters.
Description: Enter a description to help users decide if they should apply the tag.
Enabled?: Check to allow the tag to be used.
Note:
System Tag indicates whether a tag was created by the system (checked) or by a user (unchecked). You cannot change its value. You cannot modify system tags.Click OK.
All existing tags are displayed in the Tag Listing page. The System Tag? column check box is selected if the tag is predefined and shipped with the system and unchecked if your company created the tag. User-defined tags are listed first. All tags have a system-generated ID in the first column.
You can edit each tag, including system tags, as follows:
Tag Name: Any changes you make here are reflected in the user interface wherever the tag name is displayed.
Description
Enabled: Select this check box to allow the tag to be used when creating or updating actions. Deselect it to prevent its use, except in existing actions that already use the tag.
Flags are a data review tool. Flags can be applied to records (not discrepancies) by validation checks and by users in the Listings pages.
Users can filter records and discrepancies by flag values.
The system imports InForm flags with the InForm records they are assigned to in InForm. These flag assignments cannot be changed in Oracle DMW, but you can use them to analyze records and apply custom flags.
You can create any number of custom flags, each with any number of states, for use within the system. These flag assignments are not sent to InForm. A record can have multiple flags applied, each with a single state.
You can define flags for two basic purposes:
The clinical data review process
Tracking subject visit completeness.
For a validation check to apply a flag to records it must call the Flag API from a custom program. You must write the program in either SAS or PL/SQL and create a Program definition in Oracle LSH to store and version it, then associate the program with a validation check; see "Creating a Custom Validation Check" for more information.
Each flag you define has a Subject Visit attribute. If set to Yes, the flag should be applied only to records in the Subject Visit table. You can use Subject Visit flags to track the state of data completeness and cleanliness for each subject visit. To do this, define clinical record flags to track completeness and cleanliness (number of discrepancies) for each CRF record in other tables, write a program to analyze records and apply those flags, and write a program to aggregate these values to set the Subject Visit flag for each subject visit.
Clinical Record Flag Examples You could create the following flags and accompanying custom programs to help track the review process of individual subject data records:
Create a flag called Record Complete with two states: Yes and No. Write a custom program to ascertain that all required fields in a record have a value and apply the flag with the state Yes if they do. You can use this flag to filter for missing data and to calculate Subject Visit completeness.
Create a flag called Validation Checks with the states Validation Not Done, Validation Incomplete, andValidation Complete. Write a custom program that compares the timestamp of the last data update for each unlocked record to the execution timestamp for all validation checks run for that study and sets the Validation Checks flag for each record with the appropriate state.
Create a flag called Number of Discrepancies with the states 0, 1, 2, 3 and so on. Write a custom program to count the number of discrepancies in a record and set the state to the corresponding number.
Create a flag called Data Readiness with states: Not Clean, Clean for Medical Review, and Clean for Analysis. Write a custom program that uses the above flags or others to set its values.
Subject Visit Flag Example Create a subject visit flag called Subject Visit Complete with a single state of On. Write a custom program based on aggregating flag values for the individual clinical record flags in the examples above: loop through each subject/visit combination and set the Subject Visit Complete flag to On when every record for the current subject and visit in the Adverse Events, Concommitant Medications, and Vital Signs tables, for example, has the Record Complete flag set to On, the Validation Checks flag set to Validation Complete, and the Number of Discrepancies set to an acceptable number.
Flag Assignment Auditing The system audits changes in flag assignments to records with the timestamp and user name, by category, in the internal table DME_FLAG_DATA_A. To have a single flag's values audited separately, you can create a separate category for it.
Navigate to Administration, then Flags, then click the Add icon.
Enter values in the following fields:
Name: Enter the text you want to appear in the user interface for the flag; in the examples above: Record Complete, Validation Checks, or Data Readiness. The maximum length is 80 characters.
Description: Enter a description or explanation of the purpose of the flag. The maximum length is 256 characters.
Category (Mandatory): Select a single category for the flag. You can define the list of categories if you have the required privileges; see "Viewing and Creating Categories".
Subject Visit Flag Select this option if the flag is to be applied to records in the Subject Visit table. Leave it deselected (the default value) if the flag is to be applied to clinical data records.
User Settable If selected, users can set this flag in the Listings pages. If not selected, the flag is imported from InForm and cannot be changed in Oracle DMW. All flags you create have this attribute selected.
States: You can define any number of mutually exclusive states for each flag. You can delete and add states, but the flag must have at least one state or it cannot be applied to records.
Flag State Priority: Select High, Medium, or Low relative to other states of the same flag and other flags. In the Listings pages, the system displays an icon representing the highest priority flag state currently applied to each flagged record.
Click OK.
The following rules apply to flags:
A record can have any number of flags applied to it.
A record can have only one state of each flag applied to it at a time.
The system does not enforce any rules concerning the transition of a record from one flag state to another.
A user can apply a flag to a record once and change the state any number of times. The user cannot apply a flag to the same record more than once at a time.
A user can clear a flag's association with a record. No history of the flag's previous association is preserved.
The following table compares flags, tags, and categories. All are available for use in any study.
Table 8-1 Flags, Tags, and Categories
| Object | Applied To | Applied By | Used as Filter? | Has Multiple States? |
|---|---|---|---|---|
|
Flag |
Records |
User, if flag is user-settable; otherwise, system. |
No |
Yes |
|
Tag |
Discrepancies |
User, via actions |
Yes |
No, but can be used to create discrepancy substates |
|
Category |
Discrepancies, Validation Checks, Flags |
Validation check or user |
Yes |
No |
Oracle Thesaurus Management System (TMS) is a coding tool that you can integrate with Oracle DMW to code source data to terms in dictionaries (terminologies) such as MedDRA and WHO-Drug, so that data can be presented consistently and analyzed correctly.
When Oracle DMW is integrated with TMS, transformation jobs have an additional step: they send source data (terms) you specify to TMS and run the TMS autoclassification (automatic coding) job. Terms that cannot be automatically coded must be manually coded in TMS. TMS then codes all future occurrences of the same term the same way within the same domain. See "About TMS Processing".
You specify which information to derive by creating one or more TMS Sets for each dictionary on the Administration page; see "Defining TMS Sets". On the Home page you associate TMS domains and their terminologies to a study; see "Associating a Study with a TMS Domain Element". On the Study Configuration page you associate TMS Set columns with target data model columns; see "Linking a TMS Set to a Table in a Target Clinical Data Model".
If a TMS user cannot classify the term because, for example, it is really multiple terms, like nausea and headache, he or she can send a TMS action back to Oracle DMW as discrepancy text.
You must define TMS domains in TMS. These allow you to customize terminologies differently for different studies by creating domain-specific terms and classifications. Domains also determine default TMS system behavior, including whether explicit approval is required for manual classifications.
See the Oracle Thesaurus Management System User's Guide for information on setting up dictionaries and TMS domains, and on manually coding (classifying) terms. When you create TMS domains, remember that Oracle DMW displays the description, if there is one, for the user to select a TMS domain for use with a particular study. If there is no description, the system displays the TMS domain name.
Define a TMS Set to specify the information to derive back from a particular terminology (dictionary) to Oracle DMW for source system data that is coded in TMS. You can define any number of TMS Sets for a single terminology.
You can derive terms in other dictionary levelsâfor example, from WHO-Drug you could derive Synonym, Drug Constituents, and Anatomical-Therapeutic-Chemical Classification Group. From MedDRA you could derive System Organ Class, Preferred Term, and Special Category. You must define TMS Set columns for each derived item, and the study configurator must map each TMS Set column to actual table columns.
The study configurator does not need to map all the columns in the TMS Set. You can either:
Define a single TMS Set for each dictionary in TMS with the maximum number of columns that might ever be required, and let the study configurator select and map the columns needed in each study.
Define multiple TMS Sets for each dictionary, each with exactly the columns required in a particular study. The study configurator can then map all TMS Set columns to target table columns in that study.
In the Administration page, TMS Sets pane, click the Add icon. The Add TMS Set window appears.
Enter a Name and Description for the TMS Set. Both are displayed on the Study Configuration page.
Select a Terminology to code against. All terminologies (dictionaries) defined in the local TMS instance are listed.
Click OK. The system displays the new TMS Set in the TMS Set pane.
Select the new TMS Set and click the Add icon in the TMS Set Columns pane.
Define the information to be derived from TMS to Oracle DMW for each coded term using this TMS Set. These "columns" are mapped to table columns on the Study Configuration page.
Select a TMS Set and click the Add icon.
Column Designation: Enter a descriptive name to enable the study configurator to map this TMS Set column to a table column that will store the derived data.
Column Type: You can only add columns of type Derived.
Each TMS Set also has one column of type Primary. The primary column must be mapped to the column containing items (terms) to be coded and always derives the dictionary term to which the source system term is coded in the level defined as the coding level of the dictionary in TMS.
Dictionary Level Name: Select the level from which to derive data into the mapped column. The choices include all of the dictionary's defined levels and Dictionary Informative Notes, which may be defined in TMS and apply to the dictionary as a whole.
TMS Field: The options vary depending on whether you specified a dictionary level or InFormative Notes.
If you specified a dictionary level, the TMS Field choices include:
TERM: The dictionary term related to the coded term in the selected level.
TERM_UPPER: The dictionary term related to the coded term in the selected level, in uppercase.
The choices also include optional, customizable, level details that your company may have defined for the dictionary level in TMS:
CATEGORY: A category value defined by your company in TMS.
DICT_CONTENT_ID: The unique ID generated by TMS for the dictionary level.
DICT_CONTENT_ALT_CODE: An alternate ID for the dictionary level; designed to cross-reference a legacy company dictionary.
DICT_CONTENT_CODE: The unique ID of the dictionary level. This column is indexed.
VALUE_1 through VALUE_4: Four customizable fields can store information about the dictionary level.
If you specified text Dictionary Informative Notes for Dictionary Level Name, you can select one of several types of Informative Note that your company may have defined for the dictionary as a whole:
DICTIONARY VERSION: The dictionary version as defined in an Informative Note for the base dictionary in TMS.
RDC ACTION TEXT: This data applies only if you are using Oracle Clinical Remote Data Capture Onsite.
DICTIONARY NOTE: Standard text informative note defined in TMS.
Click OK.
TMS processing occurs during table-level transformation post-processing.
TMS processing includes only target tables that have at least one column associated with a TMS Set primary column and meet at least one of the following conditions:
New records in the source table.
Updates to coded terms (data in the primary column) in the source table.
Updates made in TMS that affect Oracle DMW data.
Updates in DMW or the source system to TMS-originated discrepancies on data in the source tables.
Oracle DMW TMS processing first runs the TMS synchronization job, which checks for changes in the TMS repository that impact Oracle DMW terms in TMS, either coded or not yet coded.
TMS processing then loops through all records that meet the criteria in "New and Updated Data Processed in TMS" and calls autoclassification for each one.
Autoclassification looks for exact matches to source terms in the coding dictionary level and, for terms that do not exactly match a dictionary term, the job checks if a TMS user has previously classified another occurrence of the same term to a dictionary term (this is called a verbatim term assignment, or VTA), first in the same domain and if not, globally, in TMS.
For terms with an exact match to a dictionary term or to a VTA, TMS derives and sends information back to Oracle DMW during the same transformation job.
For terms that do not have a dictionary term or VTA match, TMS creates a discrepancy in Oracle DMW and, if the lifecycle is Production, an omission in TMS.
An Oracle DMW user can create a corresponding query in InForm by applying an action to the discrepancy that sends it to InForm or by setting the status to Investigator (INV) Review.
A TMS user can classify the term manually, creating a new VTA. During the next transformation, autoclassification finds the new VTA and TMS sends derived information, and answers the discrepancy in Oracle DMW.
If a term that was previously classified is updated to a value that cannot be classified, previously derived information is deleted.
If a source term is deleted in InForm and then Oracle DMW, it calls a TMS API to delete the source term in TMS as well.
Note:
TMS autoclassification, synchronization, derivation, actions, and Oracle DMW discrepancy management are the same in all three lifecycle areas. However, TMS omissions are created only in Production, so TMS users can do manual classification only in Production, and Force Derivation works only in Production.The same data passes through three systemsâInForm, Oracle DMW, and TMSâand conflicts may occur:
Oracle DMW cannot prevent user changes in InForm. At any time an InForm user may update a TMS-originated discrepancy, changing its text or status, or the underlying data. Those changes are loaded as updates into the Oracle DMW discrepancy system, triggering TMS autoclassification and passing any new discrepancy text to TMS.
State changes in InForm may conflict with the results of autoclassification in TMS. For example, an InForm user might close a discrepancy thinking that the term is a valid one while TMS does not recognize it. In this case, even though the Closed status is loaded into Oracle DMW, TMS opens a new discrepancy when autoclassification cannot find a match for the term.
TMS classification might overwrite status changes made in InForm.
Oracle DMW uses four statuses to help coordinate the interaction of the three systems. The first two are set by the system:
TMS EVALUATION is set by Oracle DMW either when a Oracle DMW user adds comment to a TMS-originated discrepancy (that is not marked as an internal comment) or when an InForm user answers a discrepancy (either with or without a data change) and the update is loaded into Oracle DMW. The purpose of TMS EVALUATION is to trigger autoclassification on the data again during the next transformation. Without it, autoclassification would run only if there was a data change or if a TMS user had altered the record.
TMS IN PROGRESS is set by TMS when autoclassification creates or updates an omission. TMS users can manually classify an omission only when its state is TMS IN PROGRESS.
Oracle DMW users cannot update a discrepancy at status TMS IN PROGRESS. If the discrepancy has previously been sent to InForm, InForm users can update it. However, InForm users will not have new data yet from TMS - until the TMS INV Review status is applied.
TMS users can apply the following statuses during omission management or as defined actions:
TMS DM Review Prevents TMS users from updating. A Oracle DMW user may update with a comment, which sets the discrepancy and omission to TMS EVALUATION so that TMS runs autoclassification on the term during the next transformation.
TMS INV Review Sends the discrepancy to InForm for Investigator review and prevents TMS users from updating.
Click Force Rederivation in the TMS tab of the Create Study window to run the Force Rederivation job once, immediately. A confirmation message appears because running the job may take a long time.
Normally, transformations process only new or changed data. Use the Force Rederivation job to process all data when you have made structural changes related to TMS in an ongoing study such as:
Adding columns to target tables to hold derived data.
Updating a dictionary to a new version with a different structure from the old one.
Changing domain-related settings in the TMS reference codelist TMS_CONFIGURATION.
This section contains the following topics:
Studies, data models, transformations, and validation checks are all objects. Users are allowed to perform an operation on an object when they:
Belong to a user group that is assigned to the object either explicitly or by inheritance.
Are assigned to a role within that user group that allows the operation on the object.
To view data, users must have the above privileges and also a blinding-related application role that allows them to see the relevant type of data: nonblinded, unblinded, or currently blinded.
Oracle Health Sciences Data Management Workbench (Oracle DMW) is installed on top of Oracle LSH and uses its security system, which is itself based in part on the Oracle Applications (Oracle E-Business Suite) security system.
The following tasks are done in the Oracle LSH and Oracle Applications user interface and are documented in the Oracle Life Sciences Data Hub System Administrator's Guide.
Assign specialized administrative roles to a few users to create Domains to contain and organize studies, grant blinding-related privileges, and add users to user groups.
Create user accounts for all users, including application roles for all users.
Create user groups.
Assign object security roles to user groups. You can use shipped roles created for use with Oracle DMW or modify them as required. See Appendix B, "Predefined Object Security Roles" for more information.
Assign users to object security roles within user groups.
Assign user groups to objects in Oracle DMW. This is the only task that is performed in the Oracle DMW user interface. See "Applying Security" for more information.
Assign application roles to users to allow access to the Oracle DMW user interface. See "Predefined Oracle DMW Application Roles" for more information.
Assign blinding-related roles to users to allow viewing rights to nonblinded, unblinded, or currently blinded data. See "Predefined Blinding-Related Roles" for more information.
Using the predefined object security roles and predefined application roles as they are, you can set up a security system as follows:
Create a single user group and assign all the predefined roles to it in the Oracle LSH user interface. The predefined roles all begin with "Oracle DMW" and are described in Appendix B, "Predefined Roles." Object security roles determine which actions a user can take on which objects.
Create a user account for each user and give each user account the appropriate Oracle DMW application role. In some cases a user may need two rolesâfor example, developers who should be able to create library data models and code lists as well as study objects. Application roles control access to Oracle DMW user interface pages.
Blinding-specific application roles are required to view sensitive, currently blinded data (Blind Break) and to unblind data (Unblind) so that people with lesser blinding-related privileges (Read Unblind) can view sensitive data that is no longer blindedâfor example, at the completion of a study. The predefined roles all include blinding-related privileges on objects (table instances), but both this object security and the corresponding blinding-related application role are required for a user to access blinded data.
Assign the user group to the study as a whole in the Oracle DMW Home page by selecting the study in the list of studies, then clicking the Security key icon at the top of the list of studies; see "Applying Security". Assign the user group successively to Metadata, Development, QC, and Production. The object security roles control which users can perform which operations on objects in the each lifecycle area.
Assign the user group to the InForm Family adapter domain in Oracle LSH; see the Oracle Life Sciences Data Hub System Administrator's Guide.
Note:
In the rest of this document this adapter is referred to as the InForm Connector to distinguish it from the InForm Adapter that is a separately installed product whose purpose is to integrate InForm with other products. The adapter to which you assign user groups is shipped as part of Oracle LSH and Oracle DMW for the purpose of integrating Oracle DMW with InForm.Object security privileges on library models and code lists are not included in any of the predefined roles. In order to allow some users to create library models and code lists you can create a role in Oracle LSH with these privileges and assign it to the same or a different user group, and assign the user group to the study category domain that contains the study. The users will then be able to create library models and code lists available in all studies.
You can customize your security setup in many ways:
Modify the shipped object-security roles or create entirely new roles.
Create multiple user groups with different roles.
Assign user groups to objects within a study rather than the entire study; see "Object Ownership" to help you understand what the possibilities and effects are.
Create roles with privileges on library models and code lists and use them as in the "Simple Security Setup".
Oracle DMW uses Oracle LSH domain objects as containers to hold studies, study templates, clinical data models and code lists intended for reuse.
When a user creates something that is stored in a libraryâa study, library model, or code listâor when they create a study model based on a library model, he or she must first select a library.
By default, the label in the user interface is "Therapeutic Area" so that you can categorize studies and models by therapeutic area. However, you can configure this label to be whatever you want, and you must create the corresponding valuesâlibrariesâfor the user to select; therapeutic areas or other categories.
For example, if you use the default categorization of Therapeutic Area, you need to create therapeutic areas to serve as libraries, such as Cardiology and Immunology, including all that your company works on. Alternatively, you could categorize by Drug Program or Drug.
You must decide how to categorize and name your libraries. Consider:
You can create only one flat list of values. So to categorize all studies by drug as well as therapeutic area you must create categories such as "Cardiology Drug 12345" and "Cardiology Drug 678910."
To create a library of data models that are generic enough to be used in multiple therapeutic areas, you might want to create a category called "Generic."
When a user creates a new study or library data model and selects the name of the library, the selected library becomes its namespace. This has implications for object security; you can assign a user group to the library and by default that user group assignment is inherited by all studies, models, validation checks and transformations contained in the domain. You can revoke this inherited assignment at any level, or assign a user group at a lower level.
To configure the label and values:
Classification Label Therapeutic Area is the default value of the label, so to classify your studies by therapeutic area, you do not need to set a new label value. To use a different label, you must set profile Oracle DMW_STUDY_CLASSIFICATION_UI_LABEL as described in "Change Study Category User Interface Label". Your custom label then appears in the user interface in place of "Therapeutic Area."
Classification Values To create the list of valuesâa list of therapeutic areas or other categoriesâyou must define a set of Oracle LSH domains in the root domain Oracle DMW_DOMAIN in Oracle LSH. These domains also serve as the namespace for studies and library clinical data models.
You can create Oracle LSH domains two ways:
In the Oracle LSH user interface; for instructions see the Oracle Life Sciences Data Hub Application Developer's Guide at http://docs.oracle.com/cd/E54418_01/doc.24/e54089/dev_ui.htm#CHDHIIHA.
By running an Oracle LSH API; for instructions see the Oracle Health Sciences Life Sciences Warehouse Application Programming Interface Guide at http://docs.oracle.com/cd/E54418_01/doc.24/e53659/domains_api.htm#BABDIJFG.
To create a custom program or function for use in a transformation from one clinical data model to another or in a validation check, programmers must create a program in Oracle Life Sciences Data Hub (Oracle LSH); see "Creating a Custom Program". These programs must be created in the Oracle DMW_UTILS domain in Oracle LSH which is created during Oracle LSH post-installation.
You can create application areas within the Oracle DMW_UTILS domain to help users find appropriate custom programs and functions and reuse them, promoting standardization.
The process is similar to creating domains to organize studies and libraries; see "Setting Up Library and Study Categories".
Note:
For performance reasons, Oracle recommends creating application areas instead of domains inside DMW_UTILS to organize programs and other objects.When a user creates a study in Oracle DMW, he or she must specify a study size of either Small, Medium, or Large in terms of the volume of data expected, relative to other studies. The system uses this value, together with lookup values that you can modify, to determine which database partition to use for storing certain types of data in internal cross-study tables.
Partitioning is an Oracle Database feature that allows tables and indexes to be subdivided into smaller pieces and managed cost-effectively on different disk storage tiers with a finer level of granularity to improve access performance.
When a user specifies the study size and saves, the system assigns two partition IDs to the study: one for Development and Quality Control and the other for Production. Both IDs are unique across all studies in the instance.
The tables that use partitioning do not store clinical patient data, but they do store data that is likely to be created in proportion to the volume of clinical data, especially the discrepancies table.
The system adds a column for the partition ID in all affected tables. The internal SYS_CONTEXT tracks the partition ID as well as the current study and lifecycle area. All internal queries to affected tables must include the partition ID and call an internal API to get the ID from the SYS_CONTEXT to run most efficiently.
The tables are:
DME_CTXT_SKEYS_MAP: This table is used to trace the lineage between source and target tables used in transformations. It contains data that maps between specific source and target records. Each record in the target table of a transformation has at least one corresponding record in the DME_CTXT_SKEYS_MAP table, and for some transformations there are multiple records. For example, in a direct map there is one record per target table record; in a join of three tables, there are three record per target table record.
DME_OPOBJ_CONTEXT_MAP: This table is used to highlight discrepancies on the Listings display. The table contains an entry for each primary discrepancy and all of its secondary discrepancies that are traced through the transformation data lineage. The secondary discrepancies are traced to data items both upstream and downstream through the connected transformations. This table is also used to obtain the primary source data item for a discrepancy.
DME_DISCREPANCIES: This table stores discrepancy-related information such as the table, column, model, study, and lifecycle of the record on which each discrepancy is created. This table also records discrepancy state, comments, and discrepancy ID.
DME_FLAG_DATA: This table stores flag assignments to records that that users add and modify in the Listings pages.
DME_DISC_ACTION_HISTORY: This table stores the history of actions performed on specific discrepancies.
DME_DISC_CSV_FILES: This stable stores sets of discrepancies exported as CSV files.
Oracle recommends that you develop guidelines to help study designers categorize studies as small, medium, or large, and to help you in Specifying the Number of Similarly Sized Studies per Partition.
You can develop guidelines based, for example, on the number of subjects and the number and size of CRFs in the protocol.
The maximum number of small, medium, and large studies using a single partition is determined by lookups called DME_PARTITION_DEVQC and the DME_PARTITION_PROD that control the Development/Quality Control partition and the Production partition respectively. The default settings for both are:
Small studies: 20
Medium studies: 5
Large studies: 1
You can change these values; see "Setting Lookup Values."
For example, if you have a relatively small amount of data in your Development and Quality Control lifecycle areas and a huge amount of data in Production, you might change to settings like:
For the Development/QC partition:
Small studies: 20
Medium studies: 15
Large studies: 11
For the Production partition:
Small studies: 10
Medium studies: 4
Large studies: 2
There is a limit to the number of partitions that can be created for a database table: max=1024k-1.
Each partition can hold any number of records for each study; that is, any number of discrepancies or flags for given study.
Each lookup value must be different from the others; you cannot have the same number of small and medium studies per partition, for example.
Studies are assigned to partitions according to their defined size and in the order they are added.
For example, using the default value of 5 medium studies per partition, the system creates two partitions the first time a medium study is created, one for Development/QC and the other for Production, and assigns that study and the next 4 medium studies to those partitions. When the 6th medium study is created the system creates two new partitions (Development/QC and Production) and assigns the 6th through 10th medium studies to those partitions, and so on.
You can use Oracle LSH to apply snapshot labels to data in a clinical data model lifecycle area.
Log in to Oracle LSH.
In the Applications tab, Select Domain field, search for and select Oracle DMW_DOMAIN. The system displays the Oracle DMW_UTILS domain and the Study and Library category domains (see "Setting Up Library and Study Categories").
Expand the node for the appropriate category. The system displays all studies in that category.
Expand the node for the appropriate study. The system displays the Development, Quality Control, and Production lifecycle application areas for the study.
Click the link for the appropriate lifecycle area. The system takes you to the properties page for the lifecycle area, with a list of work areas, one for each installed clinical data model. The model name is included in the work area description.
Click the link for the appropriate work area. The system takes you to the properties page for the work area, with a list of installed tables and other objects in the clinical data model.
You can then follow instructions in the section "Managing Table Instance Snapshot Labels in a Work Area" in the Work Areas chapter of the Oracle Life Sciences Data Hub Application Developer's Guide.
If you have a library of lookup, or conversion, tables, you can upload them to Oracle LSH, where your custom programs and functions can reference them. Use Oracle LSH load sets to upload them.
If your lookups are contained in SAS files, you can upload many at once in SAS CPort or XPort format using an Oracle LSH SAS load set.
If your lookups are Oracle database tables, you can upload many at once by using an Oracle LSH Oracle Tables and Views load set.
If your lookups are in any other format, you can create metadata files in a required format and use a Oracle LSH Text load set to upload many at once; see "Required Syntax for Table Metadata Text Files".
The basic steps required are:
Log in to Oracle LSH.
In the Applications tab, Select Domain field, search for and select Oracle DMW_DOMAIN. The system displays domains, including the Oracle DMW_UTILS domain. You may want to load your reference tables into the Oracle DMW_UTILS domain, which will also contain your custom programs, but this is not required.
Click the domain you want to use. The system opens its properties page.
Create an application area and then a work area inside it in the Oracle DMW_UTILS domain.
Create the load set in the work area you created.
Install the target tables in the same work area.
Run the load set to load the data.
When referencing these lookups from custom programs, use static reference type source code.
For instructions, see the Oracle Life Sciences Data Hub Application Developer's Guide chapter on load sets.
You can integrate an external data visualization tool so that users can view data graphically and interactively with the protection of Oracle DMW security and blinding access privileges, one clinical data model at a time. If you select the Business Area option when you create a clinical data model, the system generates an Oracle LSH generic type Business Area object in the database with views of all tables in the model. Third-party tools that use generic type Business Areas to work with Oracle LSH will then work with Oracle DMW.
An adapter for the purpose of integrating Oracle Business Intelligence Enterprise Edition (OBIEE) is included with Oracle LSH. You must create an OBIEE-type Business Area in Oracle LSH. Instructions are included in the Oracle Life Sciences Data Hub Application Developer's Guide. The Oracle Life Sciences Data Hub System Administrator's Guide and the Oracle Life Sciences Data Hub Installation Guide have additional information on integrating OBIEE.
You can also create your own adapter to another tool; see the Oracle Life Sciences Data Hub Adapter Toolkit Guide.
Several profile settings are required in Oracle DMW. In addition, see the Oracle Life Sciences Data Hub System Administrator's Guide for information on using profiles to set password requirements.
You follow the same basic procedure for setting all profiles.
To log in, do the following:
Open your Oracle LSH URL.
Log on with the system administrator account. An E-Business Suite screen opens.
In the Main Menu pane, expand the System Administrator (not System Administration) node, then the Profile node, and then click System.
Note:
This user interface requires Java 6 Update 7 (1.6.0.0.7). If you do not have it installed, you can download it fromhttp://www.oracle.com/technetwork/java/javase/archive-139210.html. To use this feature, you must accept all warnings.A new browser screen opens with several windows open and the Find System Profile Values window on top.
Tip:
If you lose the Find System Profiles window at any point, click the Search icon in the toolbar or click System Profiles in the Top Ten list.On each computer where you install Oracle DMW, you must set the Oracle Applications profile LSH: Use Character Semantics for Workarea Installation to Yes, as instructed in the Oracle Life Sciences Data Hub Installation Guide.
If you did not already do this when installing Oracle LSH, do it now:
Open your Oracle LSH URL.
Log on with the system administrator account. An E-Business Suite screen opens.
In the Main Menu pane, expand the System Administrator (not System Administration) node, then Profile, and then click System.
A new browser screen opens with several windows open and the Find System Profile Values window on top.
Note:
If you lose the Find System Profiles window at any point, click the Search icon in the toolbar.In the Profile field, enter LSH: Use Character Semantics for Workarea Installation
Click Find.
In the Site column, select YES.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
LSH: Domain Nesting Levels should be set to at least 6 because three levels of domains are predefined for Oracle DMW and you will need more to create categories such as Therapeutic Areas. The maximum allowed value is 9.
Follow instructions in "Use Character Semantics" except in the Profile field, enter LSH: Domain Nesting Levels and in the Site column, enter a number between 6 and 9.
This profile determines the default setting for a check box in the Oracle DMW discrepancy creation user interface. Users can override the setting.
If you want the default behavior to be that the check box is not checked, so that by default the username is not added to the discrepancy text, you do not need to set this profile.
This profile determines the default setting for a check box in the Oracle DMW discrepancy creation user interface. Users can override the setting.
To set the default behavior for appending the username to discrepancy text, do the following:
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter Oracle DMW: Append Username to Discrepancy Text
Click Find.
In the Site column, select Yes or No.
If set to No, the default setting is not to append the username of the person creating the discrepancy to the discrepancy text. This is the shipped setting. Note that the system tracks the username in the database regardless of this setting.
If set to Yes, the default setting is to append the username of the person creating the discrepancy to the discrepancy text. When discrepancies are sent to InForm, this information is displayed in InForm.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
This profile determines the label that appears in the user interface in several places for the category of a study or library. By default, the label is Therapeutic Area.
If you prefer to organize studies and libraries in a different way, you can change this label. For example, if you want to organize by Drug Program, change this profile value to "Drug Program" and "Drug Program" will appear in the user interface instead of "Therapeutic Area."
See the chapter on administration in the Oracle Health Sciences Data Management Workbench User's Guide for further information.
To change the label, do the following:
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter Oracle DMW_STUDY_CLASSIFICATION_UI_LABEL
Click Find.
In the Site column, enter the label exactly as you want it to appear in the user interface, including upper- and lowercase.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
This set of profiles tells the system where to look for SAS and text files that should be loaded into Oracle DMW. There are nine profiles. You enter values for either:
Three folders, one for each lifecycle. Both SAS and text files are placed in the same folder.
Six folders, one for each lifecycle/file type combination. Each folder is used for only one file type: SAS or text.
You must create the root folders in the locations you specify here. All studies in this Oracle DMW instance must use the same three or six root folders for their input data files. The system creates a study-specific subfolder in each root folder using the name you specify; see "Creating and Modifying Study File Watchers". The study-specific subfolders become the watched locations for the study.
Note:
If you change these profile values after using them, you must stop and restart the File Watcher service to initialize the new values in the application; see "Changing the Root Folder Location".See the sections on File Watcher in the chapters on clinical data models and administration in the Oracle Health Sciences Data Management Workbench User's Guide for further information.
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter Oracle DMW:FWR_ROOT_FOLDER%
Click Find.
In the Site column, enter the full path to the subfolder for the profile's file type/lifecycle combination. Oracle recommends using a naming convention so that it is easy to tell which folder should hold which files. Enter values for either the first six profiles or the last three.
If you want to use six file type-specific root folders, enter values for these profiles:
DME:FWR_ROOT_FOLDER_TEXT_DEV for text files in the Development lifecycle.
DME:FWR_ROOT_FOLDER_TEXT_QC for text files in the Quality Control lifecycle.
DME:FWR_ROOT_FOLDER_TEXT_PROD for text files in the Production lifecycle.
DME:FWR_ROOT_FOLDER_SAS_DEV for SAS files in the Development lifecycle.
DME:FWR_ROOT_FOLDER_SAS_QC for SAS files in the Quality Control lifecycle.
DME:FWR_ROOT_FOLDER_SAS_PROD for SAS files in the Production lifecycle.
If you want to use three folders for both file types, enter values for these profiles:
Oracle DMW:FWR_ROOT_FOLDER_ALL_DEV for all files in the Development lifecycle.
Oracle DMW:FWR_ROOT_FOLDER_ALL_QC for all files in the Quality Control lifecycle.
Oracle DMW:FWR_ROOT_FOLDER_ALL_PROD for all files in the Production lifecycle.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
To archive data files instead of deleting them after loading their data into Oracle DMW, you must create archive folders and register them using this set of profiles.
There are nine profiles, corresponding to the nine profiles that register root folders for watched folders. You must choose the same setupâthree or six root foldersâfor archive folders that you did for watched folders. The system creates a study-specific folder in each root folder using the name you specify; see "Creating and Modifying Study File Watchers".
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter Oracle DMW:FWR_ARCHIVE%
Click Find.
In the Site column, enter the full path to the subfolder for the profile's file type/lifecycle combination. Oracle recommends using a naming convention so that it is easy to tell which folder should hold which files. Enter values for either the first six profiles or the last three, corresponding to the six or three you chose in "Registering Root Folders for File Watcher Watched Folders".
If you want to use six file type-specific root folders, enter values for these profiles:
DME:FWR_ARCHIVE_TEXT_DEV for text files in the Development lifecycle.
DME:FWR_ARCHIVE_TEXT_QC for text files in the Quality Control lifecycle.
DME:FWR_ARCHIVE_TEXT_PROD for text files in the Production lifecycle.
DME:FWR_ARCHIVE_SAS_DEV for SAS files in the Development lifecycle.
DME:FWR_ARCHIVE_SAS_QC for SAS files in the Quality Control lifecycle.
DME:FWR_ARCHIVE_SAS_PROD for SAS files in the Production lifecycle.
If you want to use three folders for both file types, enter values for these profiles:
Oracle DMW:FWR_ARCHIVE_ALL_DEV for all files in the Development lifecycle.
Oracle DMW:FWR_ARCHIVE_ALL_QC for all files in the Quality Control lifecycle.
Oracle DMW:FWR_ARCHIVE_ALL_PROD for all files in the Production lifecycle.
In addition, you must set the following profile values:
Oracle DMW:FWR_ARCHIVE_ENABLE Set to Y to enable archiving. The default value is N.
Oracle DMW:FWR_ARCHIVE_SCHEDULE_DAYS Enter the number of days to elapse between loading the file and moving it to the archive folder. The default value is 7.
Note:
Be sure to set the file deletion time period for individual study File Watchers to a greater number of days.In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
If this profile is set to Y, any tables that contain columns based on InForm hidden items are created with column-level blinding. The columns that are blinded will have a default masking value.
The default value is Y.
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter Oracle DMW:BLIND_INFORM_HIDDEN_ITEMS
Click Find.
In the Site column, enter:
Y so that any tables that contain columns based on InForm hidden items are created with column-level blinding on the hidden items. Blinded columns will have a default masking value.
N to create all tables with their blinding flag set to N. Users can manually define blinding for tables in the data model in Oracle DMW.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
Set this profile to Yes to require a manually created discrepancy to have an assigned category. See "Viewing and Creating Categories."
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter DMW_DSC_CATEGORY_MANDATORY.
Click Find.
In the Site column, enter:
Yes to require manually created discrepancies to have a category assigned.
No to make these categories optional.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
Set this profile to Yes to require a manually created discrepancy to have an assigned action. The action sets the state and tag of the discrepancy. See "Actions."
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter DMW_DSC_ACTION_MANDATORY.
Click Find.
In the Site column, enter:
Yes to require manually created discrepancies to have an action assigned.
No to make these actions optional.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
This profile must be set to Y if the installation is in an environment hosted by Oracle, to support Single Sign-on functionality. The default value is N, which is the required setting for on-premise installations.
Log in. See "How to Log In to Oracle Applications Profile Forms".
In the Profile field, enter LSW_SSO_INTEGRATED
Click Find.
In the Site column, enter:
Y if the installation is in an environment hosted by Oracle, to support Single Sign-on functionality.
N if the installation is maintained by your company.
In the File menu, select Save and Proceed. The system displays a message that the transaction is complete.
Click OK. The transaction message window disappears.
Click the X in the upper right corner of the System Profile Values window to close the window.
Follow instructions in the Oracle Life Sciences Data Hub System Administrator's Guide control various login and password-related requirements.
To modify lookup values, do the following:
Open your Oracle LSH URL and log in as a user with the LSH Administrator application role.
From the Navigator drop-down, select LSH Setup Admin, then Setups, then Lookups. An Oracle Applications window opens with the Oracle Life Sciences Data Hub Lookups window displayed.
Press the F11 key. The window enters Query mode and changes the background color of some of the fields.
In the Type field, enter the name of the lookup you want to see. You can enter part of the name and use the % wildcard. You can enter cdr% to retrieve all Oracle LSH lookups or dme% to retrieve all Oracle DMW lookupsâthen use the down arrow on the keyboard to view them in alphabetical order.
Note:
During its initial development, Oracle LSH was known as CDR. Therefore many internal names contain the stringcdr. Please think of CDR as a synonym for LSH.
Please think of DME as a synonym for Oracle DMW for the same reason.
Press Ctrl+F11 to enter the query. The system displays the lookup and all its current values, including predefined values and those your company has previously added (if any). If your query retrieved more than one lookup, use the Down arrow on your keyboard to view each lookup in turn.
The following information is displayed for each value:
Code is the internal name for the value.
Meaning is the text that appears on the user interface, exactly as it appears here.
Description is an explanation of the value.
Tag is an optional descriptor.
Effective Dates. The From column contains the date the value was created in your location. The To column may contain a date; if so, this is the date on which the value became or will become unavailable for use. If there is not a date in either column, the value is in effect.
To enable users to select from a list of predefined reasons for change to discrepancies, add values to the lookup DME_DSC_ACTION_REASON. The access level is User. For each value, add a code and a meaning. The meaning text appears in the user interface as the reason for change.
If you define meaning text that is the same as Reason for Change text in InForm, when an InForm user applies a Reason for Change that is then imported to Oracle DMW, Oracle DMW recognizes that the text is the same and stores the code as well as the meaning.
(DME_PARTITION_DEVQC and DME_PARTITION_PROD) The access level is User. When users define a study in Oracle DMW they must specify whether they expect the amount of data collected in the study to be small, medium, or large relative to other studies. These lookups set the maximum number of small, medium, and large studies' data that can be stored in a single partition of certain cross-study internal tables in the Development, Quality Control and Production lifecycle areas. Development and QC data are stored in the same partition, while Production data is stored in a separate partition. The default values are: 1 large study, 5 medium studies, and 20 small studies for both lifecycle partitions.
You can change the default values in the Meaning column. Each value must be different from the others in the same lookup.
|
 Copyright © 2013, 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|