| Oracle® Life Sciences Data Hub Implementation Guide Release 2.1.4 Part Number E18308-01 |
|
|
View PDF |
| Oracle® Life Sciences Data Hub Implementation Guide Release 2.1.4 Part Number E18308-01 |
|
|
View PDF |
This section contains information on the following topics:
Regulatory agencies require that you validate the data you submit as part of your drug approval application. The Oracle Life Sciences Data Hub (Oracle LSH) includes tools to help you to do this, including validation statuses, validation supporting information, and coversheets that include validation information for every report you create.
Oracle LSH cannot certify the quality of the data that you load into Oracle LSH. It is your responsibility to validate data in your source data system(s). However, Oracle LSH can help you certify that Oracle LSH handled data in a valid manner. If you can demonstrate that your source data is valid, and that Oracle LSH manipulated your source data in a valid manner, then data reported or sent out of Oracle LSH must be valid. Each time you generate a report on Oracle LSH data, you can generate a report coversheet that includes the validation status of every defined object that affected the source data for the report, including Tables, Programs, and Load Sets, since the data entered Oracle LSH.
In addition, Oracle LSH allows you to manually validate Program outputs using the same methods you do now. In the context of a Report Set, where different sections may be at different stages of validation at any one time, the system reuses existing, validated outputs as long as any requested outputs would be duplicates of the validated one. Therefore you can continue to develop some sections of a Report Set, changing Parameter values and using new Program versions, and reuse the outputs of other sections as long as your changes do not affect those sections.
Oracle LSH keeps all defined objects under version control. Each version of each object has a validation status. Oracle LSH ships with predefined validation statuses that represent different stages in an object's life cycle: Development, Quality Control, Production, and Retired.
By default, all new objects and all new versions of objects have a validation status of Development. Oracle LSH does not enforce any conditions for promotion of an object to Quality Control or Production. You should develop the standards you require for promotion. Oracle LSH does enforce rules based on objects' validation status and on the interaction of a Work Area's validation status and its Usage Intent attribute value (see "Work Area Usage Intent and Validation Status"). These rules promote using validation status to create separate, clean, Quality Control and Production environments.
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 with a Program or Report Set, or an output such as a log file or generated report to demonstrate that the Program or Report Set was successfully executed. See "Validation Supporting Information" for further information.
You can begin application development in Oracle LSH before arriving at your standards for definitional object validation, and it is possible to use Oracle LSH without ever using another validation status beyond Development. However, if you plan to submit data to a regulatory agency, you should not go into production until you have developed standards and validated all objects that operate on or store production clinical data.
All objects that are contained directly in a Domain, Application Area, or Work Area have a validation status.
Oracle LSH allows you to apply the following validation statuses fo all objects that require validation: Development, Quality Control, Production, and Retired.
Oracle LSH automatically gives all new objects, and new object versions, a validation status of Development.
Organizational objects (Domains and Application Areas) have a permanent validation status of Development, which is never visible in the user interface.
This validation status is intended to be used for objects that have already undergone informal testing by a programmer and are currently being formally tested, perhaps by a separate group of people, such as Quality Control engineers.
It is your responsibility to develop standards for the use of the Quality Control (QC) validation status.
This status is intended for objects that have been thoroughly tested and certified as being ready for use with production clinical data suitable for preparatory to submission to a regulatory agency.
Oracle LSH protects data in a Work Area with a validation status of Production by preventing the use of Work Area installation modes that would delete data in the Work Area's tables.
You must develop standards for the use of the Production validation status.
This validation status is intended for objects you no longer wish to use.
Retired Object Rules Oracle LSH enforces the following rules on objects with a validation status of Retired:
You cannot create an instance of a Retired object definition. (However, existing instances of a definition whose status is changed to Retired can still have an active validation status and function as before.)
You cannot modify an existing object instance to point to an object definition whose validation status is Retired.
Executable object instances whose validation status is set to Retired cannot be run.
If you decide that you want to use a retired object, there are three ways to do so:
If you have the necessary privileges, you can reactivate the object, setting its validation status back to whatever it was immediately before retirement.
Copy the retired object. The system sets the validation status of the new object to Development.
Create a new version of an object by checking it out (object definitions only).
Retired Work Area Rules Retire the Production Work Area for a trial when you close the trial. Oracle LSH enforces the following behavior for Work Areas whose validation status is set to Retired:
No object contained in a Retired Work Area can be run.
Objects contained in a Retired Work Area retain their current validation status when the Work Area is set to Retired.
When you clone a Retired Work Area, the validation status of the clone is also set to Retired. The object instances contained in the original Retired Work Area retain the same validation status in the clone.
When you clone a Retired Work Area, any Retired object instances contained in the original Work Area are cloned along with all the other object instances.
Oracle LSH includes the following validation-related operations on object types:
Modify Validation Status QC. This privilege is required to set an object's validation status to Quality Control. Users with this privilege can also set the status to Retired.
Modify Validation Production. This privilege is required to set an object's validation status to Production. Users with this privilege can also set the status to Retired.
Manage Supporting Information. This privilege is required to link documents and outputs to an object as Validation Supporting Information.
In addition, Work Areas have a validation-related operation called Install Qualify Submit . No executables can be run in a Work Area until the Work Area's validation status is equal to or greater than its usage intent value, except by users with the special Install Qualify Submit privilege on the Work Area. This is to allow testing of the Work Area before making it generally available for use. See "Work Area Usage Intent and Validation Status" for further information.
Oracle LSH allows you to link an object to two types of supporting information for the purpose of documenting that one of your internal validation requirements has been met: Supporting Documents and Supporting Outputs.
Oracle LSH does not enforce the use of supporting information. It is possible to promote an object to a higher validation status even if the object is not linked to the supporting information you require in your standard operating procedure (SOP).
You can upload documents to Oracle LSH and create a link from an object to the document. Oracle LSH keeps each document under version control, creating a new version number each time the document is uploaded. Oracle LSH never deletes a supporting document.
Users with the Manage Supporting Information privilege can link objects to supporting documents and outputs.
For example, you could store the following types of documents as validation supporting information for an object:
a requirements document stating the purpose of the object and specifying functional requirements
a design document that specifies the way the functional requirements will be achieved technically
a test requirements document listing the functionality that must be formally tested
actual test cases to be used in testing the object
test results
The examples given above might all be appropriate requirements for promotion from Development to Quality Control, and require the last for promotion from QC to Production.
You can also create a link between an object and a particular output. For example, to demonstrate that you successfully ran a Program, you could create a link to one or both of the following outputs of the successful job:
a report generated by the Program
the log file of the successful Program execution
Supporting outputs may be appropriate requirements for promotion to Quality Control and Production status.
You can generate a summary or detailed coversheet for any output in Oracle LSH that lists the validation status of the defined objects that handle the data in the output.
The summary coversheet gives the validation status of the executable object that generated the output and of each Table instance from which the executable read data.
The detailed coversheet gives the validation status of each executable object and Table instance that handled the data from the time it was loaded into Oracle LSH to the executable that produced the output. The system examines the immediate source Table instances, then the executables that wrote data to those Table instances, then the Table instances that those executables read data from, and so on to the Load Sets that loaded data into Oracle LSH.
If you have developed good standard operating procedures using the tools provided by Oracle LSH for testing and validating defined objects to ensure that they do not corrupt data, and followed those procedures, then data that was valid when loaded into Oracle LSH should remain valid in Oracle LSH.
Whenever you change an object's validation status to a higher status, the system attempts to make the same validation upgrade to any objects contained by the object you are explicitly upgrading. In addition, if you upgrade an object instance to a status higher than the status of its underlying definition, the system attempts to upgrade the validation status of the definition as well. For example:
If you promote a Workflow definition from Development to QC, the system attempts to upgrade all the object instances owned by the Workflow, such as Programs and Load Sets. The system also attempts to upgrade the underlying definition of each instance.
If you promote a Work Area from QC to Production, the system attempts to upgrade all the object instances contained in the Work Area, and all the definitions on which they are based.
If the system is unable to upgrade the status of all affected objects, the validation fails. The system is unable to upgrade objects in the following circumstances:
The user performing the upgrade does not have the Modify Validation Status privilege on one of the other objects that must be upgraded as part of the operation.
One of the objects that must be upgraded is checked out by a different user.
An upgrade is changing validation status from Development to either Quality Control or Production, or from Quality Control to Production.
Downgrades include changing validation status from Production to any other status, changing from Quality Control to Development, and changing from any other status to Retired. There is no cascading of validation downgrades.
Work Areas have a special attribute called Usage Intent whose allowed values are Development, Quality Control, and Production. Oracle LSH enforces the following rules based on a Work Area's usage intent value and the validation status of the Work Area and all its object instances:
To be installed in a Work Area, object instances must have a validation status equal to or greater than the usage intent of the Work Area.
The Work Area cannot be promoted to a validation status higher than the validation status of any of its object instances.
No executables can be run in a Work Area until the Work Area's validation status is equal to or greater than its usage intent value, except by users with the special Install Qualify Submit privilege on the Work Area. This is to allow testing of the Work Area before making it generally available for use.
Full installation and Table instance replacement during partial installation are not allowed in Work Areas with a usage intent of Production. This is to protect production data from deletion.
These rules support the following intended Work Area usage:
Development. When you create a Work Area, the system sets both its Usage Intent attribute and its validation status to Development. When you create an object definition and/or instance, the system sets its validation status to Development. When a Definer has successfully conducted informal testing on an object, according to your organization's standards, he or she sets the object's validation status to Quality Control (or requests a privileged user to change the status, depending on your security design).
When all the object instances in a Work Area have a validation status of Quality Control, a privileged user clones the Work Area, creating duplicates of all object instances with pointers to the same object definitions and the same version number and validation statuses as the originals. The system creates a label for both Work Areas indicating that they are identical. The privileged user enters text for the label and creates the new Work Area with a usage intent of Quality Control. However, its validation status remains at Development.
Quality Control. Install the new Quality Control Work Area. While its validation status (Development) is lower than its usage intent (Quality Control), only a user with the Install Qualify Submit privilege can run executables. That privileged user loads fresh data and tests the installation. The privileged user then promotes the Work Area validation status to Quality Control. Users with normal access to the Quality Control Work Area can then test the objects.
If testers find bugs or other problems, developers should fix them in the Development Work Area. To do this, you can clone the QC Work Area as a new Development Work Area overwriting the old one, perform a full installation, and load fresh data. When all objects have been fixed and tested, and their validation status upgraded, you can clone the Work Area onto the QC Work Area. The cloning operation updates only objects that have been modified.
Promote each object definition and instance to Production when it meets your production standards. Clone the QC Work Area to create a Production Work Area.
Production. Install the new Production Work Area. While its validation status is lower than its usage intent, only a user with the Install Qualify Submit privilege can run executables. That privileged user loads fresh data and tests the installation. The privileged user then promotes the Work Area validation status to Production. Users with normal access to the Production Work Area can then run the application.
Run the application as necessary for your business purposes. Using the same cloning procedures described above, modify the objects as necessary over time. Make modifications through the Development Work Area, test each modified object definition in the QC Work Area, and clone the QC Work Area to the Production Work Area.
Note:
The cloning operation replaces only objects that have been modified. If the cloning operation would be destructive to Tables or data (for example, the cloned Work Area did not include an existing Table or Table column, or a Column length was shorter) you receive a warning, but are allowed to continue.Retired. When you close a trial, you can retire the Production Work Area that holds its data, preserving the data in a frozen state, recreatable as it was at any point in time. You can still write Programs that read the data. For example, you can combine and analyze the data with data from other closed or current trials.
The system enforces the following rules based on objects' validation status:
You can change an object's validation status only when it is checked in. If the object is not checked in, the system tries to checks it in. If another user has checked it out, you cannot change the validation status.
Changing the validation status of a checked-in object does not change the version number of the object.
You cannot promote an object instance to a validation status higher than its underlying object definition.
For example, if you create an instance of a Program definition whose validation status is Quality Control, you can promote the instance to a validation status of Quality Control, but you cannot promote it to Production until the definition has been promoted to Production. However, the system attempts to promote the definition to Production when you promote the instance, and if you have the necessary privileges on the definition, and if the definition is not checked out by a different user, the promotion succeeds.
Validation status is version-specific. Each time you create a new version of an object by checking it out (including checking out a definition through an instance) the system automatically gives the new version a validation status of Development. The system does not change the validation status of any existing versions.
When you copy an object, the validation status of the copy is set to Development no matter what the validation status of the original is.
You cannot run an Execution Setup whose validation status is less than the validation status of its owning object instance unless you have the IQ Submit security privilege on the Execution Setup.
To be installed in a Work Area, object instances must have a validation status equal to or greater than the usage intent of the Work Area.
The Work Area cannot be promoted to a validation status higher than the validation status of any of its object instances. However, if you try to promote a Work Area to a status above that of any of its objects, you have the opportunity to promote all the object instances and their underlying definition versions to the same status in a cascade operation.
The cascade validation fails if a different user has checked out any of the object definitions in need of promotion.
No executables can be run in a Work Area until the Work Area's validation status is equal to or greater than its usage intent value, except by users with the special Install Qualify Submit privilege on the Work Area. This is to allow testing of the Work Area before making generally available for use.
Full installation and the Replace operation on Table instances in partial installation are not allowed in Work Areas with a usage intent of Production. This is to protect production data from deletion.
You cannot remove a Table instance whose validation status is Production from a Work Area of any usage intent.
You should set standards for promotion to the Quality Control and Production validation statuses for definitions and instances of Tables, Programs, Load Sets, Report Sets, Workflows, Data Marts, and Business Areas. Oracle LSH automatically promotes component objects such as Parameters, Notifications, and Overlay Templates when you promote their containing object. However, you may also want to explicitly validate these object definitions and move them to a Domain for reuse.
If you are using object subtypes, you can set different validation requirements for different subtypes of the same object type.
Oracle LSH provides two types of requirements to use: Supporting Information and Security. You can create additional required operating procedures if you so choose.
Specify documents and/or outputs that you require for promotion to each validation status. Write and enforce your policy as you would any other company standard operating procedure (SOP). Oracle LSH stores supporting documents and links both documents and outputs to objects as Validation Supporting Information.
Considerations Oracle LSH does not enforce any system behavior in relation to Validation Supporting Information. However, the Data Validation Report lists all documents and outputs linked to an object as Validation Supporting Information.
Oracle LSH supplies the operations Modify Validation Status QC, Modify Validation Status Production, and Manage Supporting Information operation on all object types and subtypes. You must define one or more roles with each of these operations on object subtypes, assign the roles to user groups, and assign users to the roles within user groups.
Restrictions Users with a role that has the Modify Validation Status QC operation can promote an object from Development to Quality Control. They can also downgrade any validation status except Production, provided that Validation Rules are not violated.
Users with a role that has the Modify Validation Status Production operation can promote an object from QC to Production as well as from Development to QC. They can also downgrade any validation status, provided that Validation Rules are not violated.
Considerations You can assign both operations to the same role or to different roles. If you assign them to different roles, you can still assign both roles to the same user. However, if you always assign different users to each role, you can demonstrate that more than one person was involved in validating an object.
You can use the same roles for all object types and subtypes or differentiate them. For example, you might want to use a different role for promoting Load Sets than for promoting Report Sets.
|
 Copyright © 2006, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
