| Oracle® Clinical Conducting a Study Release 4.6.2 E18821-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Conducting a Study Release 4.6.2 E18821-02 |
|
|
PDF · Mobi · ePub |
This chapter contains the following topics:
Oracle Clinical provides the Mass Changes utility for correcting error s in multiple records at the same time. You can update patient response data, RDCM keys, or RDCI keys. For example, if many patient positions were logged into an incorrectly spelled site, instead of correcting each record individually, you can apply the correct spelling to all of them in one operation.
To use the Mass Change utility, you need an understanding of SQL and of Oracle Clinical tables and columns. For information on Oracle Clinical's tables and columns, see the Oracle Clinical Stable Interface Technical Reference Manual, available from Oracle Support.
Complete the following tasks to make a mass change:
Identify the change type — RDCM Key, RDCI Key, Soft-delete RDCI, or Responses — as you open the Mass Change utility.
Specify the records you need to change by defining a Mass Change Specification (MCS) consisting of a few basic identifiers such as the DCM and/or Discrepancy Type, plus one or more SQL statements identifying further criteria for inclusion in the mass change. See "Defining the Mass Change Specification". You can count the records that meet the criteria and refine your MCS before using it to generate a set of records called a Candidate Data Set (CDS).
Generate the Candidate Data Set. The system includes all the records that meet the criteria defined in the MCS.
Within the context of the CDS, change records by performing one or more group updates, one at a time, excluding any records you do not want changed from a particular group update, either with a SQL Where clause or by explicitly excluding individual records. You can also update records in the CDS individually. You can test the validity of changes before applying them to the database.
Apply changes to the database. Records marked for change are changed in the database if the change is valid. Those records cannot be changed again through the same CDS. If you want to change them again as a group, you can copy the MCS and generate another CDS from the same criteria (see "Copying a Mass Change Specification"). Any records that were marked for exclusion, or which could not be changed because the change was invalid, can still be changed through the original CDS.
Oracle Clinical stores all of the details of applied mass changes in the following Oracle Clinical tables: RESPONSES, RDCI_HISTORY, and DISCREPANCY_ENTRIES.
After completing the mass changes job, the system automatically runs the incremental expectedness calculation job for all patients whose data changed. See Oracle Clinical Creating a Study for more information.
To perform all types of mass changes, you must have one of the following database roles: RXC_MC, RXC_SUPER, or RXC_SUPER_NOGL. To test mass change options only, you must have the database role RXC_MC_TEST. In addition, you can make changes with the Mass Change utility only on data that you are allowed to update through Data Entry. Privileged update is required for changing locked data, or the data of "frozen" patients.
For an explanation of RDCIs and RDCMs, question groups and questions, see the Oracle Clinical Creating a Study manual.
There are four types of data changes you can make with the Mass Changes utility, described below. From the Conduct menu, select Mass Changes, and choose the kind of change you need to make. The choices are:
RDCI Key Changes changes errors in DCI Header information (the keys that identify the RDCI) entered during Data Entry Log-In, such as logging the data for one patient under the identifier of another patient, or the wrong visit identifier for multiple patients.
RDCI keys include: Document_number, Patient, Clinical_Planned_Event_Name, DCI_Date, DCI_Time, Subevent_Number, DCI_short_name, Investigator, Site, Blank_Flag, and Comment_Text.
Note:
In RDCI Key Changes, you can change the DCI name. However, if you enter the name of a DCI that includes DCMs that are qualified in any way — by event, subevent, qualifying value, lab, etc. — you get a failure.RDCI Soft Deletes soft-deletes whole RDCIs; this would be necessary, for example, if an operator logged in many RDCIs under the wrong study. Soft-delete means that the system keeps a record of the change. You cannot use Mass Changes to correct these errors; the RDCIs must be properly re-entered. The process for mass RDCI soft deletes is somewhat different from other mass changes; see "Soft-Deleting RDCIs".
RDCM Key Changes changes errors made to a specific RDCM Header within an RDCI, in one or more of the following fields: Qualifying Value, DCM_DATE, DCM_Time, Clinical_Planned_Event, Blank Flag, Subevent_Number, Data_Comment_Text, and Comment_Text. You can change header information for one or more RDCMs in an RDCI at a time.
Response Changes changes responses to particular questions. This might be necessary, for example, if a data entry operator incorrectly transcribed a coded value for a particular question. You can change responses to one question group in an RDCI/RDCM combination at a time. If you need to change responses in multiple question groups, you must create a separate MCS for each one.
This section contains the following topics:
The Mass Change utility has two panels. The top panel, which shows the change type and study name in its title bar, is where you define the MCS you want to perform by giving it a name, description, and other details (see "Defining the Mass Change Specification"). The CDS Criteria panel, below, is where you build a SQL statement to specify the records to which you want to apply the mass change (see "Defining Candidate Data Set Criteria").
In the top panel, create an MCS that describes the records you need to update. The Mass Change utility opens with this panel in multi-record view. To view all of the fields for one record at once, click the Single button.
Enter the fields as follows:
Name Enter a unique name for the change.
Description Describe the change in a way that will help you and other users know why you are making the change and whether the MCS is appropriate for reuse.
Status The system sets the MCS's status automatically throughout its lifecycle. You cannot manually change the status. MCS statuses include:
SPECIFIED. The MCS has been defined.
CREATED. The CDS has been generated.
COMPLETE. The MCS is closed and its records cannot be changed again through this MCS. Either changes have been successfully applied in the database to all CDS records, or the MCS has been manually closed.
Change Reason Choose a value from the List of Values (LOV).
The Change Reason LOV for Response changes is derived from the installation reference codelist DATA CHANGE REASON TYPE CODE. The Change Reason LOV for RDCI and RDCM Key Changes and RDCI Soft Deletes is derived from the installation reference codelist RDCI CHANGE REASON TYPE CODE.
Audit Comment Enter a comment detailing the change to be made.
The parameters required to define the particular records to be changed vary, according to the type of change you select. All possible parameters are listed below:
DCM Name From the LOV, choose the name of the DCM associated with the records you need to change. The LOV includes all DCMs defined for the study. This field is required for Response changes. For other types of mass changes you can enter either a DCM Name, a DCI Book, or both.
DCI Book From the LOV, choose the name of the DCI Book associated with the records you need to change. The LOV includes all DCI Books defined for the study. This field is always optional.
Start Pg # If you entered a value in the DCI Book field, you must also enter the first page of the DCI Book that is associated with the records you need to change.
Disc Type If you need to change multiple records that have raised discrepancies of a certain type, choose the type from the LOV.
Max CDS Records Enter the maximum number of records you want to change in this transaction. Limiting the size of the CDS before you create it can help avoid having the system labor excessively over a mistake in the selection criteria. The default value is set in the local reference codelist OCL_MC_PREFS; initially it is set to 1000.
Question Group Name This field appears only for Response changes. From the LOV, choose the name of the question group that contains the question whose responses you need to correct. The LOV displays the names of all the question groups in the DCM you specified above.
Question Names This field appears only for Response changes. There are four Question Names fields. Enter the name(s) of the questions whose responses you need to correct. You must enter a value in the first Question Names field or CDS creation will not work.
The lower panel of the Mass Change Utility window, titled Criteria, is a self-validating SQL statement editor. Use it to refine the criteria limiting the number of records to be retrieved for the CDS of the mass change, beyond those specified in the top panel.
Note:
Your CDS does not have to be an exact match with the records you want to update. You can selectively exclude extraneous records from the CDS after you have created it. See "Excluding Records from the Group Update".The panel is set up so that entering values in the fields as required results in a valid SQL statement in each row. The statements are treated as nested statements, executed in the order they appear, from top to bottom. You can rearrange their sequence with the Up and Down buttons.
Note that the system does not validate these statements until you save the criteria by clicking the Save button in the upper panel. For further information see:
Note:
You can move the cursor to the CDS Criteria window from the RDCI Key Changes, RDCI Soft Deletes, RDCM Key Changes, or Response Changes window using the keyboard shortcut Ctrl+Shift+F8.For each criterion, you can create a SQL statement that specifies a value for a particular key or question and the condition (in the Expression field) under which records that do or do not have that value for that key or question, will be added to the CDS. Two examples follow. For detailed instructions, see "CDS Criteria Syntax" and "CDS Criteria Definition Rules".
The following table shows a sample entry in the CDS Criteria panel that limits the CDS to records for patients who are 22 years old:
| Crit Typ | ( | Key/QuesGrp Ques | Expr | Value | ) | AND/OR |
|---|---|---|---|---|---|---|
| RESP | <XXX.AGE$V> |
= |
'22' |
The following table shows a sample entry in the CDS Criteria panel that limits the CDS to records whose patient position is between 0021 and 0030:
For each line include the following information:
Crit Type Criterion Type. From the LOV choose one of the following values for each line: RDCI or RDCM Key Criteria, Response Criteria, or Discrepancy Criteria.
If you include statements for more than one criterion type, you must sort them in key, resp, and then disc order, and you must include an AND in the And/Or column between each different criterion type set of statements.
( If you are using more than one criterion, or statement, and you need parentheses in your SQL statement to override default precedence such as ORs, then enter an opening parenthesis here and a closing one at the end of the statement.
Key/Ques Grp Ques The value you enter here is either a key column or a question group question, depending on whether the Criterion Type is RDCI or RDCM Key Criteria, Response Criteria, or Discrepancy Criteria. An LOV is available.
This field is required, but the system does not validate your entry until you save your criteria.
For criteria of type RDCI Key or RDCM Key, enter a key column whose value you want to use as a filter to specify which records to change:
You can choose columns not in the LOV as long as they are of the format table_alias.column_name
where:
table_alias is one of the table aliases in the LOV.
column_name is any column in the table_alias table.
For Response criteria, enter a question group question whose response value you want to use as a filter to specify which records to change:
<question_group_name-n.question$X>
Where:
question_group_name specifies a Question Group Name, if applicable.
A period (.) separates Question Group Name from Question Name, if you state both parameters.
question specifies Question Name, if applicable.
-n (where n is a non-zero occurrence) If the question has multiple occurrences, you can specify a specific occurrence. You can obtain this number from the field's LOV. This parameter is optional.
A dollar symbol separates question values from column occurrence values.
X specifies a column occurrence with one of the following values:
v specifies value text (Use for numeric comparisons.)
e specifies exception value text
d specifies data comment text
f exception_value_text (If present; otherwise value text. Use for character string comparisons.)
For Discrepancy criteria, choose a discrepancy attribute from the LOV. The choices vary, depending on the type of discrepancy you specified in the top panel of the MCS. They include:
For Manual, Indicator, and Manual Header discrepancies: comment text, creation timestamp, discrepancy review status code, internal comment text, and irresolvable flag.
For univariate discrepancies, you have all the choices listed above, plus discrepancy type code.
For multivariate discrepancies you have all the choices listed above plus Procedure name and Procedure detail test order sequence.
All attributes have the prefix "DE" for the DISCREPANCY_ENTRIES table.
Expr Choose a standard SQL expression from the LOV. Choices include: In, Not in, Is, Is not, Like, Not like, <, <=, =, <>, !=, >=, >.
Value Enter a valid value for the key or question you entered in the Key/Ques Grp Ques field. Depending on the type of mass change, the LOV shows valid keys or column names. You can manually enter contextually valid entries not in the LOV. Enclose character data values in single quotes ('value').
Note:
If you enclose numeric values in single quotes, the system treats the value as a character string, so '15' is greater than '1234' for strings but not for numerics.Do not enclose column names in quotes.
) If you used an opening parenthesis at the beginning of the statement, use a closing parenthesis here.
AND/OR If you are using more than one criterion, you must enter a Boolean relationship between each sequential pair: either AND or OR. Only the final statement should not be followed by either AND or OR.
As you define your criteria you must follow these rules:
Unless you specified a DCM Name or DCI Book in the top panel, you must create at least one row in the bottom panel in order to generate a CDS.
You must enclose non-numeric data values in single quotes ('). See the example entries in the Value column in "CDS Criteria Examples".
You can specify only one discrepancy criterion per mass change operation, and the discrepancy criterion must be the last one defined.
Include criterion types in the following order, with all Key-type criteria first, then all Response-type criteria, then the Discrepancy-type criterion:
Key
Response
Disc
You must enter AND between criterion types.
After you have defined the MCS, before or after specifying the CDS criteria, you can count the number of records the CDS contains, or would contain if it were created as currently defined. You can use the count as a test that the actual number of records you are to work on is within a reasonable and expected range. Obtain the CDS count at any time by clicking the Count CDS button.
If an existing MCS shares many of the attributes of the mass change you want to make, you can copy it as a starting point. From the Special menu, choose Copy Mass Change, and give the new mass change record a unique name. The system takes the copied record's change type as the default, but you can change it.
Note:
If you choose a change type for which you do not have access privileges, the system prevents you from viewing it.You can view the MCSs that have already been created by running a report; from the Conduct menu, select Conduct Reports, then select Mass Change Reports, and finally, Mass Change Specifications. For each MCS the report shows the associated status, change reason, DCM, question group, question, and discrepancy type, as applicable.
You can also run a query in the Mass Change Specifications window.
This section includes the following topics:
See also "Correcting Records".
When you have specified the records to change, click the Create CDS button to generate the CDS, which includes all records that match the conditions defined in the MCS. The system changes the MCS status from SPECIFIED to CREATED. If no records meet all the criteria, the system does not generate a CDS.
You can delete a CDS while the MCS's status is either SPECIFIED or CREATED; that is, until you actually use it to apply one or more changes to one or more records.
|
Note: After the MCS has a status of CDS Created (or higher) you can no longer add criteria. However, you can add a Where clause to the CDS itself, or copy the MCS and modify the copy. You can also clear the CDS. See "Excluding Records from the Group Update", "Copying a Mass Change Specification", and "Clearing a CDS". |
To view the CDS, click the Go CDS button or press the keyboard combination Shift+Ctrl+F2. The Candidate Data Set window opens, displaying a row for each data entry record that meets the criteria you defined in the MCS.
In most cases, each row represents an RDCI. An RDCI corresponds to a Case Report Form (CRF) and has its own Document Number. There may be more than one row per RDCI for Response changes.
For RDCI Key Changes and RDCI Soft Deletes, each row is an RDCI.
For RDCM Key Changes, each row is an RDCM. However, because you can include only one RDCM in an MCS, each row also represents one RDCI.
For Response Key Changes, you can include only one question group (and up to four questions) from one RDCM in the MCS. Each question has its own column, displayed in the order you listed them in the MCS. If the question group is not a Repeating question group, there will be one row per RDCI. However, if it is a Repeating question group, there is one row for each repeat.
The columns displayed vary somewhat according to which type of change you are making. RDCI Keys are displayed for all types of changes. RDCM Keys are included for RDCM Key changes and for Response changes. Question Groups and questions are also displayed for Response changes.
The columns whose values you can change also vary, depending on the change type. Each one has a duplicate column with a white background labeled "New" For example, in addition to grayed fields for these columns, an RDCI Key Changes CDS also contains New Site, New Investigator, and New DCI Date columns. The system initially populates these fields with their current values.
When you make and save changes in the CDS, the system displays the new value in the column labeled "New" when you apply the changes to the database, the system changes the background color of all columns in each row with applied changes to gray, and you can no longer make changes to that row through the current CDS.
The status of each record is displayed in the ST (Status) field:
UN - Unchanged
IG - Ignore (do not process)
CH - Changed in the CDS (but not yet in the database)
VS - Successfully validated (but not applied to the database)
VF - Validation failed (and not applied to the database)
AS - Successfully applied changes to the database
AF - Application of changes to the database failed
Oracle Clinical processes the records in the order in which they are displayed. Therefore, be careful to arrange them in such a way that they will not fail validation or application because they conflict with an existing record in the database.
You can sort records on four fields: Patient, Visit Number, Subevent Number, and DCI Short Name. You can designate any of these four as the primary, secondary (and so on) field on which to sort, and choose either ascending order or descending order for each.
If you have Patient E8, Visit 1, with four subevents, numbers 0-3, and you want to increment each subevent number by one, write a group update that reads:
subevent_number_new = subevent_number+1 where patient = 'E8'
You must arrange the records with subevent number sorted in descending order because only Subevent 3 will not conflict with an existing record when incremented by 1; there is no existing Subevent 4, but there are existing Subevents 1-3.
Click the Reorder button or enter keyboard combination Ctrl+Shift+F11.
Select the field you want to serve as the primary sort field.
Use the Up or Down arrow to move that field to the top of the list.
Repeat Steps 2 and 3 for the other fields.
Choose either Ascending or Descending sort order for each field.
Click OK. Oracle Clinical rearranges the records and you return to the CDS window.
If your criteria returned few target records or is not inclusive enough, it may make sense to clear it and start over with the criteria specification. This is possible only when the MCS status is CREATED. To clear the CDS, from the Special menu, select Clear CDS. This action clears all records from the CDS and changes the status of the MCS back to Specified. You can then edit the specification and recreate the CDS.
Use the Audit Comment field to document the reason for this change. The system adds the comment to each record in the CDS.
This section contains the following topics:
Before you apply changes to the database, you can work on the CDS to specify the changes you want to make, using group updates and/or changes to individual records. You can perform more than one group update to a CDS, but only one at a time. You must also be careful to exclude any records you do not want changed during each group update, either with a SQL Where clause or by explicitly excluding individual records.
This section describes group updating — making the same change, or changes, to more than one record in one operation. The steps include:
Excluding Records from the Group Update (optional)
Testing that the Changes Are Valid (optional)
Additional information is available by:
From the Candidate Data Set window, click the Grp Updates button or enter the keyboard combination Ctrl+A to open the Group Updates pop-up window. The window has two columns. The left column, labeled 'Column/Question' lists all the fields you can change.
To specify the changes, do the following:
For each key or question whose value you want to change, enter the new value to the right of the key or question name. Do one of the following:
Select a value from the LOV. Each field contains a list of the valid values for that field.
In the case of keys, the LOV also contains the values key and new_key; for example, Site and New_Site. If you enter the value (not new) key, when you run the group update, the value is changed back to the value the records had when the CDS was created. The new_key value is equivalent to the most recent value set for the field. You can use it, for example, to change the value to the existing value concatenated with a suffix, such as new_key||'_XX'. For example, where the site has already been changed to General_Hospital, you could change it to General_Hospital_Oncology.
In the case of responses, the LOV includes value and new_value, where value is the value of the question response when the CDS was created and new_value is the most recent change. You can use these values the same way you use key and new_key.
Enter a fixed value surrounded by single quotes; for example: 'value'. To update to a fixed date value, use the format 'MM-DD-YYYY' (including the single quotes). The system converts the date to the internal 'YYYYMMDD' date format.
Enter a SQL statement. For example, to add 40 days to value dci_date, enter: to_char(to_date(dci_date,'YYYYMMDD')+40,'YYYYMMDD') in the update column of a expression.dci_date_new
(Optional) Enter a Where clause to specify which records in the CDS should be updated. Do not include the word "where" in the clause; it is supplied by the system.
If you are making a response change, refer to the question response values as VALUE_TEXT1, or VALUE_TEXT2, and so on, where VALUE_TEXT1 is the current value of the first question you entered in the MCS. See Example 6-1, "Response Change". Do not use the question name in the Where clause.
(Optional) If you want to explicitly exclude individual records from the group update, you can click the Back button and exclude the records, then return to the Group Update window to run the update. The system saves your settings in the Group Update window. See "Excluding Records from the Group Update".
Update the records within the CDS. See "Running the Group Update on the CDS".
To change the value of the Child Bearing Potential question to "No" for all male patients, where "Sex" is the first question displayed and "Child Bearing Potential" is the second question displayed, do the following in the Group Update window:
In the Where... field enter: VALUE_TEXT1='MALE'
In the child_bearing_potential_new field, enter 'NO' for the new value.
If a data entry operator logged information collected at Visit 6 for Patient 11 for Patient 111 instead, you can correct the mistakes for all of Patient 11's Visit 6 records by doing the following:
In the Where... field enter: CLINICAL_PLANNED_EVENT_NAME='VISIT6' AND PATIENT=111 AND DATE=20050606
In the patient_new field enter: 11
If there are records you want to exclude from a particular group update, you must exclude them before running the update. You can use two methods to exclude them:
Manual Exclusion. Select the record(s) you want to exclude from the update, and click the Exclude button. To select the records, do one of the following:
Use Shift+Click or Ctrl+Click.
From the Special menu, select Select All. You will then need to select the subset you do want to change and click Include.
Note:
If the CDS is very large relative to your system's resources and throughput, the response to invoking the Select All function can be slow.Note:
Selecting multiple records in the CDS serves no other purpose than to include or exclude records. Any change you apply to a CDS applies to all included records, whether they are selected or not selected.Enter a Where clause in the Group Update window to specify records to include in the update, effectively excluding those records that do not meet the conditions of the Where clause. See "Specifying Group Update Changes" for further information.
Excluding a record changes its status to IG, for Ignore. To reinstate a record's candidate status, select it and click the Include button.
When you finish specifying the group update, click the Do Grp Update button in the Group Updates dialog box. The system makes the changes to the CDS only, and makes a record of the group change.
The changes you enter will be applied to all the records in the CDS unless:
They have a status of IG (because they were manually excluded; see "Excluding Records from the Group Update") or AS (because changes have already been applied to the database for the record through this CDS).
You can write a Where clause in the appropriate field in this window to identify a smaller group of records to which to apply the change.
Before you commit your changes to the database, you can test if the changes are valid. Validation is optional. If you proceed directly to applying the changes to the database, the system runs the same validation test as part of the process and does not apply changes that would result in invalid data.
Running validation explicitly, in advance, gives you the opportunity to correct problems before you try to apply the changes.
To validate pending changes, click the Validate button in the Candidate Data Set window. The system displays a message when it completes testing the changes. Close the message box and review the Status field for each record:
VS. The specified change(s) would result in valid data.
The next time you apply changes to the database for this CDS, this record will be updated.
VF. At least one of the record's specified change(s) would result in invalid data. A message is displayed in the Validation Comment field explaining the reason for the failure.
The next time you apply changes to the database for this CDS, records with a status of VF will not be updated.
For all types of changes except RDCI Soft Delete, the system does not run validation tests on records with a status of either UN or IG (explicitly excluded from change). These records retain the same status after validation. For RDCI Soft Deletes, the system does validate records with a status of UN (see "Soft-Deleting RDCIs").
See "Applying the Changes to the Database".
Note on Faulty Error Messages:
The system gives incorrect error messages under certain circumstances when you attempt to update locked data, whether the data was explicitly locked or locked as part of "freezing" the patient, study, Investigator, or study site. System behavior is correct in terms of what data you are allowed to update, but the error message is incorrect.If you do not have Privileged Update, you are not allowed to update locked data. The system correctly prevents you from updating data but may give an error message like "No update allowed to the RDCM buffer" or "Visit Name [or some other field] is not updateable."
If you do have Privileged Update, you are allowed to update locked data and soft-delete locked RDCIs. The system correctly allows you to update the data. However, instead of warning you that the data is locked, it may give an error message like "RDCI is not protected because at least one of its RDCMs is locked and you have privileged update."
In addition, if you try to update a record that contains no data (not a null value) you receive an error message that the record has been changed since the CDS was created. The error message is incorrect, but it is true that you cannot update the record using mass changes. Records with no data occur, for example, when a question is added to a DCM question group after data has been collected for the DCM, or when an indicator question response is entered but no data was collected. You must update these records in Data Entry Update.
You can print a report that lists, record by record, all the changes specified in the CDS; from the Conduct menu, select Conduct Reports, then select Mass Change Reports, and finally, Change Type. Choose the name of the CDS from the drop-down list.
To view a history of a CDS's group updates, click the Grp Updates button, and then the Grp Update Hist button. The field Grp Upd # (Group Update Number) tells how many group updates have been performed on the CDS. Query for any change by number to see the SQL statement(s) generated by that group update to the CDS.
In addition, the How Changed field in the CDS window indicates how each record was last updated; either manually (a change to an individual record performed through this utility), or by a group update (includes the sequential number of the update).
Changes you make to records in the CDS, whether individual record changes or group updates, are reflected only in the CDS until you explicitly apply the changes to the database.
To apply changes to the database, save the CDS and click the Apply button. The system applies changes to records with a status of CH and VS; in the case of RDCI Soft Deletes only, it also applies changes to (soft-deletes) all records with a status of UN (see "Soft-Deleting RDCIs").
The system displays a message when it completes applying the changes. Close the message box and review the Status field for each record:
AS. The specified change(s) have been successfully applied to the real record in the database.
AF. Because at least one of the record's specified change(s) would result in invalid data, none of the changes specified for the record were applied. A message is displayed in the Validation Comment field explaining the reason for the failure.
The system gives the wrong error message when you try to apply locked data or data for frozen patients; see "Note on Faulty Error Messages".
If you successfully apply changes to all records, the system then changes the mass change record's status to Complete, which prevents any more changes from this MCS.
An RDCI corresponds to a CRF, or Oracle Clinical "document". The only change you can make to an RDCI through the RDCI Soft Deletes Mass Change utility is to delete the entire CRF. You might want to do this, for example, if an operator logged in many RDCIs under the wrong study. You cannot use Mass Changes to correct these errors; the RDCIs need to be properly re-entered.
The system maintains a record of the existence of the RDCI for audit purposes; it is not deleted entirely (hard-deleted).
To soft-delete RDCIs, do the following:
From the Conduct menu, select Mass Changes, then select RDCI Soft Deletes.
Create an MCS the same way you do for other types of mass changes; see "Defining a Mass Change Specification and Its Criteria".
Click Create CDS to generate the CDS containing all the RDCIs that meet the criteria you set in the MCS.
Click Go CDS to view the generated CDS. Each row represents one RDCI, or CRF, identified by its document number.
Carefully review each RDCI to determine if you really want to delete it. If not, select it and click the Exclude button. You can use Shift+Click and Ctrl+Click to select more than one record at a time, or from the Special menu, select Select All and then select records and click Include to delete just those records.
The system changes the status of the excluded records to IG.
(Optional) Click the Validate button to test the changes. The system tests all records with a status of UN.
Click Apply to apply the changes to the database. The system soft-deletes all RDCIs in the CDS with a status of UN or VS. The system retains a record of each soft-deleted RDCI for audit purposes, but no longer uses or processes the data in any way.
If you have specified a manageable number of records, or if the changes you need to make are not uniform, it may be an efficient strategy to make changes to the CDS's values one at a time. To make changes to a single record in a CDS, do the following:
Select the record you want to change.
Make the changes you want. You can change the value in any field that has a white background. Select a field and enter a value, or choose a value from the LOV if there is one.
Repeat Steps 1 and 2 with a different record (optional).
Save. The system sets the status of the changed records to CH (Changed). It does nothing to records you have not changed.
Click the Validate button (optional). The system tests the validity of the changes you made. If the change(s) made to a record are valid, the system sets the status of the record to VS for Validation Succeeded. If a record's change(s) are not valid, the system changes the status to VF for Validation Failed and inserts a reason for the failure in the Validation Comment field (see "Testing that the Changes Are Valid").
Click the Apply button to apply the changes to the database (see "Applying the Changes to the Database"). The system attempts to apply all changes made since the last Apply. If you ran group updates on the CDS as well as making individual record changes to the database, both the group update and the individual changes are applied.
If you ran a validation check before applying the changes, the system applies changes to all records with a status of VS and sets their status to AS.
If you did not run a validation check before applying the changes, the system attempts to apply changes to all records with a status of CH. If a record's change is valid, the system applies the change and sets the record's status to AS. If the change is invalid, the system does not apply the change and sets the record's status to AF.
Records with a status of AS and AF are not changed.
The system gives the wrong error message when you try to update locked data or data for frozen patients; see "Note on Faulty Error Messages".
If you successfully apply changes to all records, the system then changes the MCS's status to Complete, which prevents any more changes being made from this MCS.
You can also explicitly close an MCS: from the Special menu, select Close. The system changes the MCS's status to Complete.
Note:
You can still copy MCSs when they have a status of Complete. You can then use the copy to generate a new CDS using the same criteria, or modify the criteria and then generate a new CDS.
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
