| Oracle® Clinical Getting Started Release 4.6.2 E18819-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Getting Started Release 4.6.2 E18819-01 |
|
|
PDF · Mobi · ePub |
This section describes the new features and enhancements included in recent releases of Oracle Thesaurus Management System (TMS). All changes are included in the current release.
Release 4.6.2 includes 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 or RDC Classic Data Entry, 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, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
