2 Designing and Using the Oracle Life Sciences Data Hub

Organizational Structure

You must design an organizational structure in which to physically store your defined objects, the data on which they operate, and the outputs—reports such as tabulations, listings, and figures—that they produce. In the library analogy, the Oracle LSH organizational structure is equivalent to the rooms and sections of shelves where books are stored.

You can use the organizational structure in the security system you design. Using the library analogy, you can allow some groups access to the medical reference room, for example, but not the history reference room. (What people in the group can do in the room depends on their role; see "Security System".)

Oracle LSH's organizational structure consists of three nested defined objects: Domains, Application Areas, and Work Areas. Domains are intended to contain Application Areas and a library of validated object definitions (such as Tables, Programs, Report Sets, Load Sets, and Workflows) suitable for reuse. Application Areas contain Work Areas and a library of object definitions in various stages of development. Work Areas contain instances of the object definitions contained in Domains and Application Areas. By maintaining separate Work Areas for development, quality control testing, and production, you can create distinct database environments for each development phase and keep production data clean.

Organizational concepts and design issues are covered in Chapter 3, "Designing an Organizational Structure".

Security System

The security system controls access to everything in Oracle LSH: defined objects, data, outputs, and the user interface itself.

In the library analogy above, we see that you can allow access to different rooms or sections to different user groups. However, the actions a particular user can take in the room or section depends on his or her role within the group. Someone with the role of Librarian, for example, might be able to add new books to the collection and remove books that become outdated. Other people might be allowed to check books out, while others might be allowed only to look at books.

In Oracle LSH, you can assign user groups to containers in the organizational structure: Domains, Application Areas, and Work Areas. By default, objects inherit the user group assignments of their container. For example, a Work Area inherits the user group assignments of the Application Area. However, you can revoke the inheritance at any level and assign additional groups at any level.

The privileges a particular user in the group has on a particular object in a container depend on the role(s) assigned to the user within the group. For example, you might create a Programmer role with Create and Modify privileges for all object types in Application Areas and Work Areas, and View privileges on all object types in Domains. Any user assigned the Programmer role in a user group assigned to Domain X has all those privileges within that Domain.

In addition, Oracle LSH includes predefined application roles that give access to portions of the user interface. Every user must have at least one application role in order to use Oracle LSH. For example, everyone who needs to view reports on data in Oracle LSH must be able to see the Reports tab in the user interface, which requires the Consumer application role.

Security concepts and design issues are covered in Chapter 4, "Designing a Security System".

Classification System

The classification system allows you to label outputs and defined objects so that users can more quickly find what they are looking for. You can label the same object or output multiple ways to make it easier to find, like looking up a library book by its title or a keyword regardless of where it is physically located.

You can define hierarchies to create labels that are related to each other in a logical way, and use these relations in Oracle LSH's advanced search facility. Oracle LSH also uses these hierarchies to create a custom user interface for displaying outputs in the Reports screen.

For example, you could create a two-level hierarchy called Project/Study, populate the Project level with the names of all your ongoing and past projects, and populate the Study level with the names of all your ongoing and past studies, linking each study to the appropriate project.

In the Reports screen, Oracle LSH displays folders, subfolders, and outputs in about the same way that your personal computer does, using hierarchy values for the folder and subfolder names. If you define a Project/Study hierarchy, Oracle LSH displays the Project/Study hierarchy as a top-level folder. Within it are a set of folders, one for each project, labeled with the name of the project. Within each project folder are a subfolder for each study and any reports that are classified to the project as a whole. Within each study folder are reports that are classified to each particular study.

In addition, if your company is a pharmaceutical company, you could define a single-level "hierarchy" called CROs, and populate it with the names of all the Contract Research Organizations with which you work. Users could then search for a report, or for the Program that generated the report, by its project and study, or by the CRO that collected the data.

Or if your company is a CRO, you could define a single-level "hierarchy" called Pharmas and populate it with the names of all the pharmaceutical companies with which you work. Your users could then search for a report, or its generating Program, by its project and study or by the pharmaceutical company sponsor of the study.

You define hierarchies that reflect your business organization and practices, populated with values, or labels, from your environment, to make the organization of the Reports screen and the categories available for use in searching as intuitive as possible for your users.

You can classify the containers—Domains, Application Areas, and Work Areas—you define as your organizational structure, and set up classification by reference, so that the objects and outputs you specify are classified the same way (for a particular hierarchy level) as their container. For example, if an Application Area is classified, or labeled, as Study 01, you can set up your classification system so that by default all Program definitions there are automatically classified to Study 01 as well. You can change a reference classification to an explicit classification at any time if you have the necessary privileges.

Classification concepts and design issues are covered in Chapter 5, "Designing a Classification System for Searching and Browsing".

Subtypes

You can define one or more subtypes for each of the predefined primary object types: definitions and instances of Tables, Programs, Load Sets, Report Sets, Workflows, Data Marts, and Business Areas. Subtypes allow you to define broad categories of objects and outputs and different classification and security requirements for each category.

For example, if you will be storing both clinical and financial data in Oracle LSH, create a financial and a clinical subtype for most object types. You can then, for example:

• Allow financial personnel to see financial reports but not clinical ones, and clinical personnel to see clinical reports but not financial ones.

• Classify financial reports, but not clinical reports, by fiscal quarter as well as by project and study.

Subtypes are covered in Chapter 4, "Designing a Security System" and Chapter 5, "Designing a Classification System for Searching and Browsing".

Object Validation Standards

Oracle LSH keeps all definitional objects—including Tables, Programs, Report Sets, Workflows, and Data Marts—under version control, and tracks which objects touched which data within Oracle LSH. All Oracle LSH definitional objects have a validation status that represents a stage in the object's life cycle: Development, Quality Control, Production, or Retired. You should develop validation requirements for objects at the Quality Control and Production stages.

Oracle LSH allows you to link documents and outputs with objects to demonstrate that they meet a validation requirement. For example, you can store documents such as Functional Requirements, Test Requirements, or Test Cases for a Program or Report Set, and an output such as a log file or generated report to demonstrate that the Program or Report Set was successfully executed.

Program outputs (reports) also have a validation status. You can specify whether you want a Program's outputs to inherit their validation status or to require manual validation. In the context of a Report Set, you can validate one output manually and continue to reuse that output in the Report Set even though you rerun the Report Set to generate other outputs. Further information is included in the Oracle Life Sciences Data Hub Application Developer's Guide in the chapters on common development tasks and Report Sets.

Oracle LSH enforces certain system behaviors based on validation status.

You can begin application development in Oracle LSH before arriving at your standards for definitional object validation, but you should not go into production until you have accomplished this task and validated all objects that affect production clinical data.

Validation concepts and design issues are covered in Chapter 6, "Validating Objects and Outputs".

Phase 1: Implementation Design

Before you can begin using the Life Sciences Data Hub (Oracle LSH), you must design and set up three systems, introduced in the following chapters. Detailed design information is included in subsequent chapters in this book, the Oracle Life Sciences Data Hub Implementation Guide. The three systems are:

• Organizational Structure

• Security System

• Classification System

In addition, to satisfy regulatory requirements you must develop your own standards for validating objects. See "Object Validation Standards".

Phase 2: Implementation Setup and Maintenance

The second phase involves setting up the structures and systems designed in the Implementation Design phase. You may need to extend and modify these systems over time, so the instructions are included in the manual intended for the people who will maintain each system.

• Setting up the organizational structure—Domains, Application Areas, and Work Areas—is covered in the Oracle Life Sciences Data Hub Application Developer's Guide.

• Setting up the security system includes creating user groups and roles, assigning user groups to Domains, Application Areas, and Work Areas, and assigning users to roles within user groups. Instructions are included in "Setting Up the Security System" in the Oracle Life Sciences Data Hub System Administrator's Guide.

• Setting up the classification system includes creating flat and/or multilevel hierarchies of categories with values that represent the organization and/or purpose of your company's work, and assigning these to Domains, Application Areas, and Work Areas. Instructions are included in "Setting Up the Classification System" in the Oracle Life Sciences Data Hub System Administrator's Guide.

• Setting up integration with external systems includes setting up the Distributed Processing Server, setting up Adapter Security, Registering Remote Locations, and creating Database Accounts. These tasks are all covered in "Setting Up Adapters to External Systems " in the Oracle Life Sciences Data Hub System Administrator's Guide.

The Oracle Life Sciences Data Hub System Administrator's Guide also includes monitoring and troubleshooting information on Oracle LSH job execution.

Phase 3: Application and Data Repository Development and Maintenance

In this phase, you work in a Work Area to define all the objects necessary to accomplish a particular business purpose (application), and install them to an Oracle LSH database schema.

You then load data into the schema and run the application to test the programs, tables, and other defined objects. When the application is ready, you clone the Work Area and install it to a different Oracle LSH schema to be used for quality control, load fresh data, and formally test the application.

When the application is thoroughly tested and all its objects validated, clone the quality control Work Area, install it to a new Oracle LSH schema to be used for production, load production data, and allow clinical and other personnel to see Oracle LSH outputs as appropriate. The production environment can be modified as necessary over time, using the development and quality control Work Areas.

Over time, if you design modular applications, you can reuse object definitions in various combinations to create new applications with a minimum of programming effort.

This information is covered in the Oracle Life Sciences Data Hub Application Developer's Guide. The programmers and data managers who develop applications in Oracle LSH are called Definers because they define objects.

Phase 4: Information Retrieval

When Oracle LSH applications are running on production data, Oracle LSH Consumers—end users with no knowledge of the database or definitional objects—can find existing reports and data marts and run them on current data at any time if they have the necessary security privileges. They can also use Oracle Business Intelligence Enterprise Edition to create onscreen data visualizations.

These tasks are covered in the Oracle Life Sciences Data Hub User's Guide.