| Oracle® Health Sciences Data Management Workbench User's Guide Release 2.3.1 Part Number E35217-02 |
|
|
View PDF |
| Oracle® Health Sciences Data Management Workbench User's Guide Release 2.3.1 Part Number E35217-02 |
|
|
View PDF |
The following administration tasks are done in the Oracle Health Sciences Data Management Workbench (Oracle DMW) user interface:
The following administration tasks are done outside the Oracle DMW user interface:
See also the Oracle Life Sciences Data Hub System Administrator's Guide for additional administrative tasks in the Oracle Life Sciences Data Hub, including the chapters on services and profiles.
In the Administration page, you can create a list of all the labs or other entities that send files to be loaded into the system. This list populates the list of values for File Watcher data sources. You can view the existing file data sources in the Lab tab.
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 Labs. This value appears in the list of data sources in the File Watcher configuration tab for clinical data models during study configuration.
Description: Enter a description of the data source.
Contact: Enter the name of the person who should receive discprepancies.
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.3.1.
To change any part of a lab data source definition, click the Edit (pencil) icon, make the changes you need, and click OK. See "Adding a Lab Data Source" for details about each field.
In the InForm tab of 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.
You must information about the InForm reporting database for the study:
Enter a value 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:
No spaces are allowed.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 DMW InForm Connector" in the Oracle Health Sciences Data Management Workbench Installation Guide for further details. The system will use this account to connect.
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.
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
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.
Username: Enter the name of the account set up for authenticating Oracle DMW web service transactions. The default name is DMW_AUTH. See the section "Create Users in InForm" in the Oracle Health Sciences Data Management Workbench Installation Guide.
Enter the name of a valid user account on the web service location. The system will use this user name to connect.
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.
To remove a remote location or web service location, select it and click the Delete icon (the red X).
To modify a remote location or web service location, select it and click the Edit icon (the pencil). Modify values as required; see "Adding a Remote Location" or "Adding a Web Service Location".
This section contains the following topics:
You must create six folders, one for each combination of file type—SAS or text—and lifecycle—Development, Quality Control, and Production—to be used by all Study File Watchers. Oracle recommends using a naming convention that includes the file type and lifecycle mode so people can be sure they are putting data files in the right place.
These six folders do not need to be in the same folder or even on the same machine.
Both the File Watcher service(s) and the DP Server(s) must have access to these folders; for example, you can set up an NSF mount of the file system to each machine where one of these DP Servers is installed.
In addition, you must register their locations in the Oracle LSH profiles listed below; see the Oracle Life Sciences Data Hub System Administrator's Guide for instructions.:
DME:FWR_ROOT_FOLDER_TEXT_DEV for text files in the Development life cycle area
DME:FWR_ROOT_FOLDER_TEXT_QC for text files in the Quality Control life cycle area
DME:FWR_ROOT_FOLDER_TEXT_PROD for text files in the Production life cycle area
DME:FWR_ROOT_FOLDER_SAS_DEV for SAS files in the Development life cycle area
DME:FWR_ROOT_FOLDER_SAS_QC for SAS files in the Quality Control life cycle area
DME:FWR_ROOT_FOLDER_SAS_PROD for SAS files in the Production life cycle area
Note:
You must define all six folders for File Watcher to work. However, if you do not need one or more of them for a particular study or even for any studies, you do not have to use them.Changing the Root Folder Location
Changing the root folder location is disruptive to the flow of work in DMW and should only be done with caution. However, you can modify the location if necessary:
Create one or more new root folders in a new location.
Change the value of the LSH profile to the new location.
The system then:
Migrates all existing Study File Watchers to the new root folder(s).
Does not move existing files to the new location.
You must determine which files have not been loaded, if any, and move them to the new location.
Any files already submitted for data load at the time of the change will be processed.
For each Study, define a Study Folder Name; see "Creating and Editing Study File Watchers" and create a subfolder of that name under each of the six file type/lifecycle area combination root folders; see "Setting Up Root Folders for File Watchers".
The six root folders should contain one subfolder for each study in the DMW instance. Study folder names must be unique across the DMW instance.
The File Watcher service detects files that have been placed in watched folders so the system can then load them into DMW. Instructions for setting up the File Watcher service are included in the Oracle Health Sciences Data Management Workbench Installation Guide.
The File Watcher service must have access to the root folder; the root folder must be located either on the same machine or NFS mounted to the machine.
You can have one or two File Watcher services:
If you are using the same machine for processing both SAS and text files, you need only one service.
If your SAS and text data loading installations are on separate machines that do not share file systems, you need a File Watcher service on each machine.
The operating system account that runs the Distributed Processing (DP) Server, which runs the File Watcher Service, must have read, write, and delete privileges on the files to be processed by File Watcher, including the root folder and any study folders that contain data files.
The Distributed Processing (DP) Server communicates with the database and processing engine to run data load jobs. You can use DP Servers on multiple machines, not necessarily just the one or two computers where the File Watcher service is installed. The DP Server also requires access to the root folder for the data files to be loaded.
For each machine where you have installed SAS or SQL*Loader to run SAS and text data loads, respectively, you must define the following in Oracle LSH:
One Service Location for the computer.
One or more Services for the Service Location of the following types:
SAS to load SAS files
Text for SQL*Loader to load text files
Each Service has a priority assigned. If your data loads will have different priorities, you should define one Service for each priority (Low, Normal, or High) you may need. For each Service you must also specify the number of Service Instances to create. You should specify a number equal to the number of data loads of the same priority that "Setting Up Root Folders for File Watchers"may run at the same time.
You can define DP Service Locations and Services on other computers with access to the machine where the root folders are located and use those services to run data load jobs as well; see "Selecting the Distributed Processing Server".
In addition, you must start the DP Server service on the machine, entering values for the following parameters related to File Watcher:
FW_ENABLED Set to Yes to start the File Watcher Service or No if you are not using Oracle DMW.
FW_FREQ Refresh frequency in seconds. This value specifies the minimum interval between requests to the database to check if there is a new set of Watcher Configurations. This value cannot be set lower than 60 seconds. A high setting will result in a delay between the user's addition or adjustment of a Watcher Configuration in Oracle DMW and the changes' taking effect in file detection behavior.
FW_POLL Polling frequency in seconds. The polling frequency represents the minimum interval at which a File Watcher Service may run to detect if there are any files in the watched location that should be loaded into Oracle DMW. The minimum value permitted is 60 seconds.
You define DP Service Locations and Services in the Oracle LSH user interface and start the service in UNIX. See the Oracle Life Sciences Data Hub System Administrator's Guide for more information.
This section contains the following topics:
After the administrator creates the Study File Watchers, the study designer or data manager must then configure File Watchers and File Specifications for each clinical data model in the study that loads data from files; see "Configuring File Watcher" for more information.
You can suspend and resume File Watchers; see "Restarting Watchers that Are Not Working" and "Suspending and Resuming Automatic Data Loading".
For each study you must specify a single folder name to be used for loading data from files. The system uses this folder name to create six study File Watchers, one for each combination of the two possible input file types—SAS and text—and each of the three lifecycle stages—Development, Quality Control, and Production. Each Watcher watches a different directory path ending in a folder of the name you specify here.
You must create the actual directories with this folder name in the six locations you specify in the LSH profile values; see "Setting Up Root Folders for File Watchers".
Edit You cannot change the study or folder name. You can change the file deletion period.
Create To create study File Watchers:
In the Administration tab, 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 will receive an error if you try to create Study File Watchers before the root folders are defined in the LSH profiles.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 file type/lifecycle area root folder. The Study Folder Name must be unique within the 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 Watcher Listing pane of the Administration page.
You must create six directories matching this name; see "Setting Up Study Watched Folders".
Delete Files After: Enter the number of days after the load date when the file should be deleted. If the file cannot be loaded because it does not meet the file specifications for the folder, the system deletes the file this number of days after the file detection date.
Files are permanently deleted. If you do not want your files deleted, enter a very large number. However, Oracle recommends archiving your files in a different secure location and keeping them in the watched folders for a minimal amount of time after they have been loaded.
Click OK to save a new set of study Watchers or Regenerate to save changes to existing ones.
Specify the Distributed Processing (DP) Service Location(s) where the the File Watcher service is installed. These settings apply to all the Study File Watchers for the Oracle DMW instance.
In the Watcher Listing pane of the Administration page, click DP Server. The DP Servers for File Watcher window opens.
Text DP Server: From the drop-down list, select the DP Service Location you want to use to detect text data load jobs. Both the DP Server and the SQL*Loader processing engine must have access to the root folders for the text file type.
SAS DP Server: From the drop-down list, select the DP Service Location you want to use to detect SAS data load jobs. The DP Server and the SAS processing engine must have access to the root folders for the SAS file type.
Click OK to save.
This section contains the following topics:
The Watcher Listings page displays all File Watchers in the DMW instance with their current status, including six for each study, one for each file type—SAS or text—and lifecycle—Development, Quality Control, and Production—combination.
To see all Watchers for a single study, enter all or part of the study name in the blank field above Study Name and press Enter.
To see if a Watcher is for text or SAS files, display the File Type column. In the View drop-down list, select Columns, then File Type. Columns displaying the data load parameter values are also available.
To see a Watcher's File Specifications, select the Watcher in the Watcher Listing pane. The system displays its File Specifications in the File Specifications pane.
Note:
This displays the File Specifications from all Data Models for the study that match the file type and lifecycle for the selected Watcher.For information on each field, see "Configuring File Watcher". 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.
See also "Changing User Interface Display" and "Querying By Example".
In this window you can:
To detect files and load data, the Watcher's status must be Running and the Distributed Processing (DP) Server status must be Online. If not:
Resume the Watcher File Specification: You can resume a Watcher or one of its File Specifications that has been suspended by selecting it and clicking Resume.
Note:
If the DP Server status is Offline, the Watcher cannot run, even if its status is Running.Restarting the DP Server: If the DP Server status is Offline you can restart it using instructions in the Oracle Life Sciences Data Hub System Administrator's Guide chapter on stopping and starting services and queues.
If you have set up scheduled data loading and need to stop it temporarily; for example, because a lab is sending files using the wrong format, you can suspend loads for the Watcher or a single File Specification and resume them when the issue is resolved.
To conserve system resources, suspend data loading for all of a study's File Watchers at the end of a study.
To stop or start a File Watcher:
Go to the Administration page and click File Watcher in the left pane. The Watcher Listing window opens. If necessary, click the Filter icon to query for the Watcher by its study or status.
Select the File Watcher you want to stop or start.
If it is currently stopped, click the Resume button to start it.
If is it currently running, click the Suspend button to stop it.
Or, to start or stop only one of the filename patterns a Watcher looks for, select the File Specification you want to stop or start.
If it is currently stopped, click the Resume button to start it.
If is it currently running, click the Suspend button to stop it.
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. If a category is applied to a validation check, the validation check automatically applies the category to all discrepancies it creates.
A particular discrepancy, validation check, or flag can have only one category. Users can filter these objects by category.
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.3.1 linking categories to model types and subtypes is possible only by using a public API; see the Oracle Life Sciences Data Hub 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.3.1 you must use public API createModelFlagcatMap to map a category to a clinical data model type or subtype. See the Oracle Life Sciences Data Hub 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 call 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.
To create a tag:
Click Tags at the bottom of the right-hand pane in the Administration page, then click the Add (+) icon..
Enter values in the following fields:
Tag Name: This text will be 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.
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 an important data review tool. Flags can be applied to records (not discrepancies) by validation checks and by users in the Listings page.
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.
Navigate to Administration, then Flags, then click the + 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 this state and add others, but the flag must have at least one state or it cannot be applied to records.
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 |
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
and are assigned to a role within that user group that allows the operation on the object
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 blind break and unblind 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 Roles.".
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".
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 "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, and 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 if you want to categorize all studies by drug as well as therapeutic area you must create categories such as "Cardiology Drug 12345" and "Cardiology Drug 678910."
If you want 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 if you want to classify your studies by therapeutic area, you do not need to set a new label value. If you want to use a different label, you must set profile DMW_STUDY_CLASSIFICATION_UI_LABEL as described in the Oracle Life Sciences Data Hub System Administrator's Guide. 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 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
By running an Oracle LSH API; for instructions see the Oracle Life Sciences Data Hub Application Programming Interface Guide
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 "Defining a Custom Program". These programs must be created in the DMW_UTILS domain in Oracle LSH which is created during Oracle LSH post-installation.
You can create domains within the DMW_UTILS domain to help users find appropriate custom programs and functions and reuse them, promoting standardization.
The process is the same as for creating domains to serve as libraries; see "Setting Up Library and Study Categories".
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 the chapter on look-ups in the Oracle Life Sciences Data Hub System Administrator's Guide for more information.
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 DMW_DOMAIN. The system displays the 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 life cycle 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 DMW_DOMAIN. The system displays domains, including the DMW_UTILS domain. You may want to load your reference tables into the 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 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 the system with an external data visualization tool so that users can view data graphically and interactively, one model at a time. Oracle Business Intelligence Enterprise Edition (OBIEE) is included for this purpose, and there are third-party tools such as JReview and Spotfire available for use with Oracle LSH that will work with Oracle DMW. You can also create your own adapter to another tool; see the Oracle Life Sciences Data Hub Adapter Toolkit Guide.
Install OBIEE or the third-party tool with access to the database and integrate it with Oracle LSH. Instructions for OBIEE are included in the Oracle Life Sciences Data Hub Installation Guide and the Oracle Life Sciences Data Hub System Administrator's Guide. For third-party tools, follow instructions provided by the maker.
You must define an Oracle LSH Business Area in the Work Area of a clinical data model and map it to each table instance whose data you want to make available in the visualization tool, ; see the chapter on Business Areas in the Oracle Life Sciences Data Hub Application Developer's Guide.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|