| Oracle® Clinical Getting Started Release 5.1 E53563-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Getting Started Release 5.1 E53563-01 |
|
|
PDF · Mobi · ePub |
This section describes the new features and enhancements included in recent releases of Oracle Clinical and Remote Data Capture (RDC Onsite).
Release 5.1 includes the following enhancements:
Oracle Clinical and RDC Onsite now support creating a risk-based source data verification (SDV) plan that identifies only a subset of data requiring verification in RDC.
An SDV plan can have one or both of the following components:
A Critical Forms Plan identifies CRFs that need to be verified against the original data for all patients.
A Patients Plan identifies patients in the study that must have 100% of their data verified. The percentage of patients requiring 100% verification can be different for different study sites. Patients can be individually selected for SDV or automatically selected based on either or both of these options:
A count of initial patients to be 100% source data verified.
A default rate of automatic selection of patients for source data verification.
You set system-wide default SDV plan values in Oracle Clinical and publish default plans based on those values for all study sites. You can then make changes to the plan for any study site in RDC Onsite.
When a patient SDV plan is published, automated patient selection begins. With the appropriate privileges you can see in the RDC Onsite user interface which patients and CRFs have been selected for SDV.
You can introduce partial source data verification in an ongoing study.
There are new privileges to support this functionality, and you must update existing users' privileges, including explicitly assigning them the BROWSE_VERIFY privilege if they should be able to view CRF verification status information. See the RDC Onsite Administrator's Guide.
To facilitate centralized monitoring in RDC Onsite, you can create custom review types (similar to the predefined Verify and Approve review types) to enable and track reviews by users with a specific role such as data manager, safety expert, or adjudicator. After you define review types and assign privileges to users, default activity links appear in RDC Onsite specific to each review type, allowing privileged users to search for CRFs requiring their review.
Users with Update privileges can also update the CRF custom review status—with comments—either individually or with a group action. There is also a Browse All custom review privilege that allows view-only access to current CRF review status and review history for all custom review types.
Each review type you define comes with a set of five possible statuses that can be assigned to CRFs: No Review Status, Review Required, Review Undone, Awaiting Re-review, Review Complete, and Review Not Required. These statuses are visible next to the CRF icon to users with privileges. The system reverses a CRF's Review Complete status (to Awaiting Re-review) under the same circumstances in which it reverses Approved and Verified statuses, with either data or discrepancy updates, but does not reverse Complete status after form version migration.
Create custom review types and their corresponding privileges in the CUSTOM REVIEW TYPE installation codelist in Oracle Clinical.
The RDC Onsite data entry window now provides a CRF History Report which provides CRF audit history not otherwise available in the data entry window, including initial CRF creation data, prior history for deleted rows, and prior history if the CRF was ever deleted.
The complete CRF Report can also be generated directly from the data entry window providing all the sections normally provided in a Patient Data Report (PDR): the CRF rendering itself with complete audit history and discrepancy details.
The study data deletion batch job can now be run with or without auditing the deletions. Data deleted with audit is still considered hard-deleted and is no longer available in the system, but it is written to new tables with the same structure as the tables it is deleted from, and you can generate reports on deleted data and discrepancies in SQL*Plus.
There are now two menu items for batch deleting data, both under the Conduct menu. One job, Delete Study Information with Audit, always audits data deletion. The other job, Delete Study Information, has a parameter that allows users to choose whether to audit the deletion or not. Using menu roles, you configure which users you want to have access to which menu option. By default, existing users with privileges with to the pre-5.1 version of Delete Study Information will have access to the new Delete Study Information job, not the job that always audits data deletion.
Release 5.0 includes the following modifications:
Release 5.0 includes upgrades to the technology stack, including the Oracle Database 11g Optimizer, which offers many performance-related enhancements.
Because databases have traditionally been constrained to run only on a single server, customers have typically followed a hardware "scale-up" strategy for the database tier. Whenever the database server becomes a bottleneck to overall application performance, the server is replaced with a larger, faster machine. While this approach is well understood, it can be highly disruptive to ongoing business.
Oracle Real Application Clusters (RAC) provides an alternative approach for scaling database performance. It is designed to tolerate server failures with little impact to mission-critical applications and users. As workloads and user connections are increased, additional nodes (servers) can be easily added to the cluster. Each server runs against the same database simultaneously. This approach is less disruptive to ongoing business operations, more reliable, and less expensive to implement.
PSUB has been re-architected in Release 5.0 to support an Oracle Real Application Cluster (RAC) installation across multiple nodes. Instead of using dbms_pipes, which can be used only within a single database instance, to communicate between the user session and the PSUB service, Release 5.0 uses Oracle Advanced Queuing.
Changes include:
The RXCPROD account formerly responsible for starting and stopping PSUB (RXCPSDPS) has been eliminated. The PSUB start and stop privilege is now held by the opapps account, which continues to be responsible for the installation. If your company has previously allocated these responsibilities to separate individuals, be aware that your PSUB administrator now requires access to the opapps account.
The opapps account will not only execute the RXCPSDPS (PSUB) process, but all of the batch jobs launched by that process, such as batch validation and batch data load, using a proxy database account. These jobs will no longer be executed by individual users' operating system accounts.
The connection information for the proxy account is securely stored in Oracle Wallet, with information you provide when you run the Oracle Clinical Installer. Oracle Wallet replaces the Secure Shell, which replaced Remote Shell (rsh, remsh, and rlogin) used in earlier Oracle Clinical releases.
Users who need to submit PSUB jobs no longer need:
a user account beginning with OPS$
an individual operating system account
Instead, a new property identifies users as PSUB users and grants them access to the new ocpsub proxy database account account. To grant this access to existing user accounts, run the migration script oclupg50migrateusers.sql provided with Oracle Clinical 5.0 and described in the Oracle Clinical Administrator's Guide.
Some PSUB jobs require input files and/or produce special output files that are still stored on the file server, not in the database.. You can choose to have user-specific directories to store these or to store them all together. If you choose to have user-specific directories, you must create them yourself.
The local reference codelist OCL_STATE has new settings to configure the changed PSUB implementation.
There are small changes in the Oracle Clinical user interface to support these changes.
SAS Data Extract jobs are run by PSUB, so its changes in 5.0 affect SAS as well. Users no longer have individual operating system accounts and are no longer members of the oclsascr user's group.
Like other PSUB users, SAS Data Extract users no longer need individual operating system accounts, and therefore these accounts do not need to belong to the oclsascr user group. Only opapps needs to belong to oclsascr.
Since Oracle Clinical no longer uses individual operating system accounts to run SAS jobs, the authentication method must change. You can set up SAS authentication two different ways:
Using Oracle Wallet
Using SAS proxy encryption file
New OCL_STATE settings support these options.
Four Data Extract jobs require input and output files in addition to the usual output files (.log and .out) that in Oracle Clinical 5.0 are stored in the database. Three of the four jobs are very similar in structure, in that they each require execution of two jobs. The first job creates files that are to be executed by SAS in the second job. New settings in the OCL_STATE local reference codelist allow you to execute these two jobs separately. This can be useful when SAS resides on a separate server from the PSUB server.
Note:
SAS files generated in earlier releases of Oracle Clinical cannot be re-used in Release 5.0 because they contain a database connection string that is no longer usable. You can regenerate all your SAS view files to include the correct database connection string using the existing gen_views utility.There are small changes in the Oracle Clinical user interface to support these changes.
Oracle Clinical Remote Data Capture (RDC) Onsite has the following enhancements:
In the Patient Casebook Page you can now toggle between the Multiple view, which is the traditional view showing records for multiple patients at a single visit, and the new Single view, which shows records for a single patient at multiple visits.
Group Approve and Verify actions provide additional CRF inclusion and exclusion options: Exclude batch-loaded CRFs, Exclude non-migrated CRFs and Include CRFs for this visit only (from the multi-page casebooks page). An administrator can configure the initial values for the settings and whether or not the settings are updateable at the time the action is performed.
The Group Approve and Verify sequences includes fewer dialogs, requiring fewer clicks to accomplish the action.
The Logout page in RDC Onsite includes a link back to the Login page.
The word here in the below messages is a hyperlink that routes you back to the Login page.
You are successfully logged out. Click here to log in again.
Your session timed out. Click here to log in again.
Your Password has been changed successfully. Click here to log in with new credentials.
Many of the following enhancements are provided by the migration to AS 11g:
All RDC Onsite Surround pages come with a new, more esthetically pleasing look and feel provided by AS 11g Fusion middleware.
Continuous scrolling on all pages replaces the Next / Prev controls to view another set of records.
Shift-click and Ctrl-click provide a faster way to select multiple records than checkboxes. Select the left-most column header to select all rows.
CRFs opened from the Review pages (CRFs, Discrepancies, Investigator Comments and Special Listings) allow you to open the Next or Previous CRF in the list without returning to the Review page. The new Single Patient Casebook page also provides this functionality. Earlier releases provided this capability only when the CRF was opened from the Patient Casebooks page.
You can select an Action with a single click, without having to select the 'Go' button in addition to the action itself.
You can expand and collapse the News, Activities and Links pane, which now appears with all the Surround pages in addition to Home.
Many Surround pages provide the ability to filter results using one or more column headers. Select the Query by Example icon (a funnel) to display the filter boxes in the column headings.
On the Multi-Patient Casebooks page, there are changes in the triplet of fields formerly labeled Set Visit Focus:
If this is a non-flexible study, the Patient field no longer appears. (The field was not updateable in earlier releases.)
If this is a flexble study, the Patient field is now labeled 'Visit Set for Patient' to more accurately reflect its purpose. The default value is 'All' so the Visit selection list will display all possible visits. (In earlier releases, the default value was the first patient in the list, and the Visit selection list included only the visits relevant for that patient.)
Release 4.6.2 included the following new features:
It is now possible, through an enhancement to Thesaurus Discrete Value Groups (DVGs), to filter the list of values displayed for a question in RDC Onsite data entry based on the user's current Study and Site context. For example, in a study with 300 sites, for a question asking which physician performed a procedure, display a list of physicians at the local site rather than the complete list of physicians at all 300 sites.
RDC Onsite data entry now supports capturing long comments and narratives as required to document serious adverse events or a patient case history, for example. These extended text fields hold up to 10,000 characters and are fully audited with date and time stamps, the modifying user, and reason for change, and are included in the Patient Data Report.
An Oracle Application Integration Architecture (AIA) Process Integration Pack (PIP) integrates Oracle Clinical with Siebel Clinical to automatically pass certain data and metadata from one system to the other, including:
Creates Oracle Clinical Sites, Investigators and Study Sites based on Protocol Site information sent from Siebel Clinical
Passes information about patients and visits from Oracle Clinical to Siebel Clinical
Allows you to define Oracle Clinical/Remote Data Capture (RDC) data collection events that should be treated as visits/activities in Siebel Clinical and passes information to Siebel Clinical to signal the completion of visits/activities for patients
New user interfaces are now included in Oracle Clinical to enable integration and define activities.
In addition, you can use the same tools used to develop the Siebel Clinical integration to develop your own integration with a different system. New web services are available to create and update Oracle Clinical Sites, Investigators and Study Sites. Oracle Clinical writes information about patient visit/activity completion to the CLINICAL_STUDY_AQ activities queue in the database where a web service can pick it up and send it to another application.
Release 4.6 included the following new features:
You can use the DCI (Data Collection Instrument) Book Assignment function to manage changes to an ongoing study definition. This function lets you identify and redirect selected patient populations to a new DCI Book in a single action.
New DCI books are typically assigned in the following circumstances:
A book is assigned to all patients in a study when the changes made are relevant to the entire study patient population.
A book is assigned to all patients at a specified study site when the changes made are relevant to a single study site within a study patient population.
A book is assigned to all patients of a particular patient range when the changes made are relevant to a patient range within a study patient population.
A book is assigned to patients who have been previously assigned to another DCI book within a study patient population.
Each assignment and reassignment is recorded and can be reproduced at any time.
Study builders limit user access to a subset of DCIs based on the user role hence, each change in the DCI access scheme is traceable. DCI-level access is study specific and can be applied for all DCIs of any status. The user role may have access to one set of DCIs for one study and a different set of DCIs for another study. Study builder limits a user access to browse-only access to specified DCIs for a specific study. User interface for specifying DCI access schemes is available from Oracle Clinical to the same group of users who define Study DCIs.
Access to RDC content and the content of the Patient Data Report is also restricted based on the DCI access. Access to generate the Patient Data Report is restricted by the DCI access level.
A study builder is responsible for interpreting schedules and creating studies consistent with the study protocol. The deployment of a study build in RDC effectively defines the expected measurements during each visit for each study segment. This is handled with DCI Books and assignment for each subject.
A new interface lets study builders manage the DCI books more efficiently by providing the following features:
You can define DCI Book in logical parts based on the study schedule; display of the DCI books is also organized.
The expected completion of the CRF pages is known through the DCI pages during the study intervals.
You can define navigation instructions based on protocol rules for measurement appropriateness and interval sequencing.
You can copy pages within DCI books.
A study builder is provided with a method to work on DCI books by study interval and CPEs (Clinical Planned Event). It facilitates the process of making changes to a study.
You can copy a CPE and insert it within a DCI book, including its assigned DCI book pages and branch definitions.
You can delete a CPE, assigned to another CPE, including its assigned DCI book pages and branch definitions.
Re-sequencing and re-numbering of DCI book pages is automated when page tracking is not enabled. Re-numbering and re-sequencing takes place for the entire book when intervals or CPEs are inserted or removed from the DCI books.
You can set or modify the Page expectedness for DCI books. Page expectedness identifies that the CRF page is expected to be completed for the patient as defined by the study protocol.
DCI book copy includes copy of branch definitions.
Branching occurs when a data entry interface user is directed to a different set of questions on a form, depending upon the responses entered for a question. Indicator branching supports two branches of a question; conditional branching supports multiple branches of questions.
Conditional branching functionality is provided along with the enhanced functionality of the Indicator branching. The following branching functionality is provided with this release:
Defining In-CRF Conditional Branching: You identify a question as a conditional source question and define different branch rules for the expected responses or range of responses.
Defining Indicator Branching: You identify a question as an indicator question and define an 'indicator value' that enables the remaining questions in the question group.
Leveraging Legacy Branch Definitions: When conditional or indicator branching definitions are already used for Oracle Clinical, existing definitions can be activated for use in graphic DCI Form layouts for HTML data entry.
Configuring Visual Representation: You are provided with options to specify a visual mechanism by which questions are represented as disabled in the HTML data entry window. You can select an option to represent the disabled questions as either 'grayed out' or you can completely hide the section of the form representing the conditional target blocks.
In-CRF Conditional Branching in HTML Data: Questions in all conditional and indicator target blocks are disabled until a response to the source question is entered. Once it is entered, questions in the appropriate target block are enabled and focus goes to the first question in the target block.
You can designate a study as Flexible, when it is created in Oracle Clinical 4.6. You can choose an option in the Clinical Study States form to indicate whether the study is Flexible or Non-Flexible. This setting can be changed for a study that has no test or production data. It is possible to designate an existing traditional (i.e., Non-Flexible) study as Flexible, and a Flexible study as Non-Flexible.
Setting Intervals to Expected Definition: A study builder can define a question that can set intervals to expected. Study builders can identify a DCI page that contains a question, which can set the interval to Expected. This can be done for any DCI page in a book including the pages marked as 'conditional'. The intervals must be positioned after the DCI page containing the source question and they need not be sequential. As the interval becomes expected, all its CPEs and all DCIs within those CPEs become expected. Users can edit and add additional intervals or DCI pages expected definitions during the course of the study.
Setting DCI Page(s) to Expected Definition: A question can be defined that can set DCI pages to expected. A study builder can identify a DCI page that contains a question, which can set the DCI pages to expected. This can be done for any DCI page in a book including the pages marked as conditional. DCI Pages marked as expected can be within CPE, within the same interval or across intervals. The DCI containing the source question must be positioned within the same CPE or in a CPE that precedes the CPE containing the DCI Pages that are set to expected.
The source question must be in a specific format and should conform to the Expected Definition Rules.
Modifying Intervals or DCI Pages: You can add and edit additional intervals or DCI page expected definitions during the course of the study.
Intervals or DCI pages become no longer expected as a result of modification to the source question data. However, if the data exists for these Intervals or DCI pages, any DCIs with data that are no longer expected will continue to be available through RDC user interface at runtime.
The application audits all changes made to branch intervals or DCI page definitions.
Tracking Expected Pages for Each Subject: When source question expected rules are met, conditional DCI pages or intervals are marked as 'expected' for a subject. If a response for a source question changes, the source question expected rules are no longer met and conditional DCI pages or intervals marked as 'expected' are reverted to the status 'not expected' for a subject.
Batch validation is run at the same time the data is entered in the application, without impacting application performance. The support for RDC data entry and batch validation is available at all times without interruption.
The following enhancements facilitate concurrent data entry and batch validation:
Batch validation is performed concurrently with data entry, without hanging the sessions.
Batch validation is run without failures when documents are locked by RDC.
Batch validation is successful even if a user has a document containing a response that has a validation status change since the last batch validation.
Two versions of a derived response are created, if an online or DCM procedure and batch validation are running at the same time.
It is possible to run a batch validation when documents are undergoing Pass 1 data entry without corrupting the documents.
TMS derives the data back to Oracle Clinical at the time of batch validation, without any deadlocking or crashing issues.
Locked documents are tagged and are processed during the next batch validation run. Documents containing the questions connected to TMS are processed during the next TMS process.
Batch validation is run successfully without data corruption for new or existing documents that become accessible for the first time, before the last batch validation was performed. The documents are tagged and are processed in the next batch validation.
If manual discrepancies exist, the role of the user who created the discrepancy is displayed, along with the discrepancy ID in the discrepancy details window of the HTML data entry page. You can view the discrepancies based on your role.
You can answer or route a discrepancy that is not active for you. In RDC, you can hide the discrepancies based on the user role and review status of the discrepancy.
Access control to update other discrepancies is configured at the database level, preventing unauthorized modification of other discrepancies.
In addition to the foregoing, the following enhancements are made in the application:
A new zero footprint HTML data entry interface is provided to replace the PDF interface.
The phase name in the multi-patient casebook page is prefixed to the current visit name.
With improved scalability of the middle tier, the application supports additional concurrent users, minimizing the requirement for additional hardware.
The application provides a mechanism for capturing relevant details required for troubleshooting data entry problems.
|
 Copyright © 2003, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
