e Loader 31 User Manual

7/28/2019 e Loader 31 User Manual

http://slidepdf.com/reader/full/e-loader-31-user-manual 1/122

eLoader - Data Loading and Conversion Tool

Version 3.1

User Manual

This manual is an unpublished work containing confidential and proprietary information

of Complete Software Solutions, Inc. Use, disclosure, reproduction or transfer of this

manual without the express, written consent of Complete Software Solutions, Inc. is

1255 Post Street, Suite 500, San Francisco, CA 94109

phone: 415-441-4810 fax: 415-441-4818 e-mail:[email protected]

Complete Software Solutions, Inc



eLoader 3.1 User Manual

prohibited.

CSS, Inc. Confidential and Proprietary 2




TABLE OF CONTENTS

TABLE OF CONTENTS.............................................................................................................3

1. INTRODUCTION......................................................................................................... ...........6

1.1.OVERVIEW...............................................................................................................................61.2.ELOADER FUNCTIONS..............................................................................................................61.3.I NVOKING ELOADER ................................................................................................................71.4.TITLE SCREEN..........................................................................................................................71.5.ELOADER USER SCREEN..........................................................................................................81.6.ELOADER ADMIN SCREEN.......................................................................................................9

2. CONVERSIONS.................................................................................................................. ..11

3. DATASETS.............................................................................................................................13

3.1.CREATE DATASETS FROM ORACLE TABLES OR VIEWS.........................................................133.2.CREATE DATASETS FOR USE WITH TEXT FILES.....................................................................143.3.IMPORT DATASET FILES........................................................................................................143.3.1. MANUAL IMPORT...............................................................................................................153.3.2. AUTOMATIC SCAN AND IMPORT FROM DATASET FILES TAB............................................163.3.3.IMPORTING XML TYPE FILES (ODM FORMAT)..................................................................173.4.FORMATS...............................................................................................................................183.4.1. DELIMITED FORMATS........................................................................................................193.4.2. FIXED FORMATS.................................................................................................................223.4.3. SPECIAL FORMATS.............................................................................................................273.4.4.CONDITION..........................................................................................................................28

4. MAPPING.............................................................................................................................. .29

4.1.COPY MAPPED DATASET I NFO..............................................................................................294.2.MAPPING K EYS......................................................................................................................304.2.1. DEFAULT K EYS..................................................................................................................314.2.2. K EYS METADATA FIELDS..................................................................................................324.2.3.VERIFYING METADATA......................................................................................................344.2.4.CONDITIONS........................................................................................................................364.2.5. DATASET DCI K EY / OC DCI K EY...................................................................................364.3.MAPPING R ESPONSES.............................................................................................................374.3.1. AUTOMAP...........................................................................................................................374.3.2. MANUAL MAPPING............................................................................................................384.3.3. DISPLAY I NCOMING DATA VALUES...................................................................................40

4.3.4. APPLYING FORMULAS........................................................................................................414.3.5. GENERATING DECODE STATEMENTS.................................................................................414.3.6. SKIP R EPEATS....................................................................................................................474.3.7.QUALIFYING QUESTIONS....................................................................................................484.3.8. R EPEAT S N.........................................................................................................................484.3.9.DATASET QG K EY AND OC QG K EY................................................................................494.3.10.CONDITIONS......................................................................................................................514.3.11.I NVESTIGATOR COMMENT................................................................................................51





4.3.12.COMMENT.........................................................................................................................514.3.13.R ESTRICTION ON MAPPING ..............................................................................................514.3.14.SPECIAL MAPPING NOTES.................................................................................................524.3.15.PSEUDO COLUMNS............................................................................................................52

5. REPORTS.............................................................................................................................. .53

5.1.R EPORT SET-UP......................................................................................................................535.2.K EYS AND R ESPONSES R EPORT.............................................................................................545.3.MAPPING VALUES R EPORT....................................................................................................54

6. LOADING DATA...................................................................................................................57

6.1.CONVERSION R UN CREATION ...............................................................................................576.2.CONVERT OPTIONS................................................................................................................596.2.1. MAX R ECORDS IN BDL FILE.............................................................................................606.2.2.EXECUTION OPTIONS..........................................................................................................606.2.2.1.EXECUTE IN BATCH.........................................................................................................606.2.3. PROCESSING OPTIONS........................................................................................................616.2.3.1.IGNORE R ESPONSES FOR U NCHANGED R ECORDS............................................................61

6.2.3.2.K EEP BDL R ECORDS FOR DELETE..................................................................................616.2.3.3.R ELOAD ALL R EPEATS....................................................................................................616.2.3.4.R ELOAD ALL SUBEVENTS................................................................................................636.2.4. OC LOAD OPTIONS............................................................................................................636.2.4.1.LOAD GENERATED DATA INTO OC..................................................................................636.2.4.2.OC TRANSFER MODE......................................................................................................646.2.5. DESTINATION PATH...........................................................................................................646.3.EXECUTING THE CONVERSION...............................................................................................646.3.1. PREPARE............................................................................................................................646.3.2. GENERATE.........................................................................................................................646.3.3.VALIDATE...........................................................................................................................646.4.CONVERSION SUBMISSION OPTIONS......................................................................................66

6.5.ADDITIONAL CONVERT SCREEN BUTTONS............................................................................697. DELETING DATA ............................................................................................................... 73

7.1.DELETE BY FILE.....................................................................................................................737.2.DELETE BY PROCESS..............................................................................................................747.3.DELETE SCREEN.....................................................................................................................757.4.FILTERING R ECORDS IN THE DELETE SCREEN.......................................................................767.4.1. NULL AND DERIVED R ESPONSES.......................................................................................777.4.2. R EFRESHING DELETE R ECORDS.........................................................................................77

8. STATISTICS...........................................................................................................................79

8.1.VIEW CONVERSION STATISTICS.............................................................................................79

9. ERRORS..................................................................................................................................80

10. COPY MAPPINGS...............................................................................................................81

10.1.COPY DATASET METADATA................................................................................................8110.2.COPY CONVERSION METADATA..........................................................................................81

11. TMS LOAD FEATURES................................................................................................. ....83

11.1.SETUP IN TMS SYSTEM.......................................................................................................83





12.6.1ELOADER TMS LOAD PROCESS.........................................................................................8311.2.1.CREATE THE TMS LOAD CONVERSION............................................................................8311.2.ELOADER TMS FORMATS....................................................................................................830.1.ELOADER TMS DATASETS....................................................................................................840.2.ELOADER TMS DATASET FILES............................................................................................840.3.ELOADER TMS MAPPING......................................................................................................84

11.2.6.EXECUTING THE TMS LOAD............................................................................................8611.2.7.ELOADER TMS R EPORTS..................................................................................................86

12. ADMINISTRATIVE MODULE .........................................................................................87

12.1.USER CREATION AND PRIVILEGES.......................................................................................8712.2.AUTOLOAD TAB..................................................................................................................8812.3.DIRECTORIES........................................................................................................................8912.4.SCANNING FILES..................................................................................................................9012.4.1.AUTOLOAD AND SCANNING SETUP..................................................................................9012.4.2.SCANNING R ULES AND SETTINGS.....................................................................................9012.4.3.I NITIATING THE SCAN.......................................................................................................9312.4.4.AUTOLOAD PROCESS........................................................................................................95

12.4.4.1.IMPORT THE FILES.........................................................................................................9512.4.4.2.CONVERT FILES.............................................................................................................9512.4.4.3.PROCESS DELETE FILES.................................................................................................9512.5.IMPLEMENTING ALERTS.......................................................................................................9612.6.VALIDATE CHECKS..............................................................................................................9712.6.1DEFINING CUSTOM CHECKS..............................................................................................9812.7.FILE LOG..............................................................................................................................9812.8.R UN LOG..............................................................................................................................9912.9.R EPORTS............................................................................................................................10012.10.CONTROL SETTINGS.........................................................................................................10112.10.1. PARAMETER SETTINGS.................................................................................................10112.10.2. OPTIONS SETTINGS......................................................................................................102

12.10.3. ADDITIONAL PARAMETERS:.........................................................................................10312.10.NEW USERS......................................................................................................................10412.11.ELOADER BATCH PROCESS..............................................................................................10412.12.FORMAT FOR LOADING INTO ORACLE CLINICAL............................................................10412.13.CHANGE R EASON AUDIT TRAIL WHEN USING ELOADER DELETE FUNCTION..................104

13. QUICK START GUIDE.....................................................................................................105

14. EXAMPLES........................................................................................................................111

14.1.SAMPLE MAPPING – O NE FILE TO 2 DCMS - K EYS, DCI K EYS, R ESPONSES, QG K EYS..11114.2.CONVERTING A FILE THAT IS ALREADY IN THE OC BATCH DATA LOAD FORMAT..........11614.3.MAPPING MULTIPLE DATASET COLUMNS TO THE SAME OC QUESTION..........................119

14.4.GENERATING A BATCH LOAD FILE FROM OC VIEWS.......................................................11915. ICON DESCRIPTIONS.............................................................................................. .......121





1. Introduction

1.1. Overview

eLoader was developed by Complete Software Solutions, Inc. (CSS) to provide a

streamlined method for pre-processing and loading data from any legacy system or external source (e.g., lab data files) into Oracle Clinical™ (OC), and into Oracle ThesaurusManagement System TMS™.

eLoader is tightly integrated with OC’s security and metadata structures. eLoader’sflexible structure allows data from different sources to be loaded in OC. The columnsfrom the source data file or table are mapped to Keys (patient, event, etc.) and DCMQuestions in OC. Once a ‘mapping’ is completed it can be re-used to allow automatedloading of data from multiple sources.

1.2. eLoader Functions

The following functions have been implemented in eLoader 3.1:

• Read data from delimited files, fixed files, ODM1.1 files, and Oracle tables and views.

• Create formats manually or automatically based on incoming file structure.

• Map columns from incoming data (file or table) to Keys (patient, event, etc.) and DCM

Questions in OC.

• Automap incoming data items to OC Questions.

• View incoming data values and frequencies.

• View OC data from DCM Questions.

• Apply SQL formulas manually or automatically to incoming data to convert or decode.

• Check formulas used in converting data for syntax errors.

• Add comments for each conversion to identify problems/issues.

• Automatically generate Subevent Numbers.

• Automatically generate Repeating Sequence Numbers.

• Validate incoming data against OC study design and definition structures to identify

problems before loading (e.g. invalid keys, duplicate records, invalid formats).

• Allow validate checks to be enabled or disabled globally or for a selected study and

identify whether an error detected will abort the processing for a file or reject thediscrepant record only.

• Eliminate records from batch load files that have already been loaded into OC (reduce

load times).

• Identify records in OC but missing from Cumulative files (potential deletes).

• Identify potential deletes directly via file.





• Delete records directly from OC using eLoader (soft key delete or update).

• Generate batch files and load directly into OC.

• View input files, generated batch files and OC log files from eLoader

• Automatically scan designated directories to detect new load files.

• Import new load files automatically and process through eLoader and OC without user

intervention.

• Provide separate Administrator and User modules.

• Provide the ability to add custom reports.

• Provide the ability to add custom validation checks.

• Load data into TMS

1.3. Invoking eLoader

eLoader can be used as a client-server or web application. The Administrator will either setup the icon on your PC or identify the url to log into eLoader. The eLoader entry screen isdisplayed. Log in to eLoader with the same user name and password as you would for Oracle Clinical.

1.4. Title Screen

The Title Screen displays the version of eLoader, userid, instance and current date in thetitle bar.

The user can:

• Select an existing conversion from the list of all conversions (for all studies the user is

authorized to access in OC). Clicking on Conversion opens the selected conversion.

• Create a new conversion. Click on Continue without putting any value in the Select

Conversion box.

• Click on the Admin button (if the user has the appropriate privilege) to perform eLoader

administrative tasks.

The User form provides a layer of security by restricting access to only the conversions for the studies the user has access to in OC.

Clicking on the Conversion button opens the User screens of the application. Clicking on

the Admin button opens the Administrative screens. Most of the column headings in theeLoader forms can be used as sort buttons.





1.5. eLoader User Screen

The following activities are performed from different tabs in the main eLoader User screen:

• Formats – Create Formats to be used in loading files.

• Datasets - Create Datasets that contain the structure of the files or tables expected to

be used by the conversion.

• Dataset Files – Import files to be processed by eLoader or review files automaticallyscanned into eLoader.

• Keys – Map Dataset columns to the Keys required by Oracle Clinical for the batch

load file.

• Responses - Map Dataset columns to the OC Questions and apply conversion formulas

if required.

• Convert - Convert data from Dataset files to OC batch data load format and generate a

text file ready to be loaded into OC or load directly into OC.

• Errors – View Errors generated from the eLoader processing steps.

• Stats – View conversion statistics.

• Reports - Run reports.

• TMS – Convert and load data into Oracle’s TMS system.





1.6. eLoader Admin Screen

The following activities are performed from different tabs in the eLoader Admin screen:

• File Log – Displays listing of all files submitted to eLoader.

• Run Log – Displays status of all eLoader Conversion Runs.

• Batch Jobs – Batch job submission and status screen.

• Alert Log – Displays all alerts generated from eLoader.

• Alerts – Screen for the creation and maintenance of Alert messages.

• Directories – Form used to manage activities allowed from eLoader accessible

directories.

• Scan – Screen for the creation and maintenance of directory scanning rules.

• AutoLoad – Form used to enable the AutoLoad capability for a conversion.

• Validate – Maintenance form to provide global settings for eLoader Validate checks.

•

Users – Form used to manage access to eLoader.• Reports – Report maintenance and submission screen.

• Control – Sets eLoader default parameters and options.







2. Conversions

Each OC study requires a conversion to be created in eLoader. A conversion identifies a setof structures (datasets), files or tables (dataset files), and mapping rules to load data into anOC study. Multiple conversions can point to the same study (a conversion can only point to

one study). Once the set-up has been performed for a conversion, it can be copied in one stepto other conversions.

From the eLoader title screen, leave the Select Conversion box blank and click on theConversion button to create a new conversion. The system opens the user screens. Tocreate a new conversion:

Enter a unique Conversion name.

Associate this new conversion with the OC Study.

Click on the button next to the Study field to see all studies you are allowed to access in OC,

and select the study for this conversion. When the record is saved, eLoader assigns a uniquenumeric ID to the conversion. The system also automatically populates the Created by andCreated on fields with the user’s login ID and the current Date/Timestamp.

The Locked field may be checked to prevent changes from being made to a conversion butdoes not prevent processing to occur (Convert screen). Changes may not be made to theConversion while the Locked flag is checked however any user who has Administrator or Developer privileges and has access to this Conversion may update the Locked flag.

The Active field controls whether the OC Lookup table is refreshed for that conversionduring the nightly batch job. This would be turned off by the Administrator when aconversion is no longer in use to prevent unnecessary nightly processing.

The Autoload field controls whether the conversion will allow files to be automaticallyimported and processed by eLoader. Any user who has Administrator or Developer privileges and has access to this Conversion may update the Locked flag.

The Use field indicates the form of the data source for the conversion and has three options:Oracle Tables, Data Files or Both. This pick list applies to the Datasets screen.









3. Datasets

Within eLoader, Data is grouped in objects called Datasets. A Dataset can be either for a:

Group of input files that have the same format

Oracle table or view

The Dataset defines the metadata mappings. In case of input files, eLoader will create atable (owner: ELOADER_STORAGE) to store the data from the input files.

Datasets can be created in two ways:

Define the Dataset structure based on a Format (typically from a sample file).

Create an Oracle Table or View in the database and assign it to a Dataset in eLoader.

Multiple Datasets may be defined for each conversion. Based upon what was selected in the

Use field the system will accept the identification of Oracle Table Datasets, File Datasets or Both. Multiple table owners are allowed within a conversion. The Dataset Name must beunique within the conversion. Choose the table owner from the list of values when creating adataset from an existing table or view.

3.1. Create Datasets from Oracle Tables or Views

Datasets may be created from Oracle Tables or Views, if the Use field is set to either ‘Oracle Tables’ or ‘Both’. Any Oracle account can be selected as the owner of a Datasetwithin a particular Conversion





Note: Grant select on all tables/views that would be used as Datasets to the ELOADER

account. As an alternative, the system privilege “select any table” can be granted to

eLoader.

First enter a name for the Dataset. Select the owner of the table or view from the list of values. Once the owner has been selected the Table Name field will contain a list of values

displaying all Oracle tables and views owned by the selected owner. Choose the correcttable or view. Tick the ‘Cum’ column when successive loads for this dataset should beconsidered as Cumulative. In case Cumulative is checked on, eLoader will be able toidentify records that are potentially deletes (see chapter “Deleting Data”).

For each selected Dataset, a list of the columns in that table is displayed in the DatasetColumns on the right hand side of the screen. These columns will be mapped to OracleClinical Keys and Responses fields (see sections 4.2 and 4.3).

3.2. Create Datasets for use with Text Files

Datasets can be created for use in importing data directly from text files if the Use field is

set to either ‘Data Files’ or ‘Both’. The Dataset defines the format and mappinginformation for a group of files to be assigned to it in the Dataset Files tab. This processeliminates the need to duplicate mappings for different files of the same structure within aConversion and allows an automated scanning, import and load utility to run. If Data Fileswill be automatically scanned, the creation of the Dataset must be performed prior toscanning. If Data Files are to be identified manually, the Dataset may be created at thesame time through the Dataset Files tab (skip to section 3.3).

Enter a unique name for your Dataset. If the setting of the Use field is ‘Both’, the Owner field has to be manually entered as ELOADER_STORAGE, to identify that this datasetwill be used for loading text files; if the setting of the Use field is ‘Data Files’, eLoader assigns ELOADER_STORAGE as the owner of the Dataset automatically. This account

owns all Oracle Tables for the Datasets created for the importing of text files, and wascreated and password encrypted during the installation process. It provides a secure way tomanage the data tables created during eLoader’s import process. eLoader assigns a Table Name to the Dataset consisting of the Dataset name appended with the unique ConversionID number.

Select a pre-defined Format from the LOV to identify the structure of the Dataset (seesection 3.4 to create a new Format). Alternatively, select a file from the LOV in theFormat File field to determine the structure of the Dataset. A list of the columns in theDataset table created will be displayed in the Dataset Columns section on the right handside of the screen. These columns will be mapped to Oracle Clinical Keys and Responsesfields (see sections 4.2 and 4.3 to map Keys and Responses).

3.3. Import Dataset Files

Data may be imported for processing in eLoader from text files. To import text files, first place the files in an accessible server directory.

Note: Directories on the database server must be identified and marked as Input

directories in the Admin module. See the installation instructions for information on

adding database server directories.







eLoader attempts to import the file in the specified directory using the Format assigned tothe referenced Dataset. If the import is successful, a message is displayed and the Status isupdated automatically to Imported. If the import fails, the Error box will be checked. Click on the Show Errors icon to display errors for the selected file.

Show errors icon.

By displaying the Dataset Files screen at any time, a list of all Dataset Files imported for

this conversion can be displayed.

Imported data may be deleted by clicking the Remove Imported Data button. After imported data has been removed, the dataset file entry may be deleted (except when the filehas been linked to the dataset by the Scan process).

Remove Imported Data for current file icon.

3.3.2. Automatic Scan and Import from Dataset Files Tab

The Administrator may choose to set up the Autoscan feature of eLoader for the

Conversion (see section 12.4 for setup details). If this has occurred, designated directoriesmay be searched for new files and these files will be assigned to the appropriate Datasetswithin the Conversion.

The user may initiate a search for new files or search and/or import any new files foundfrom the Dataset Files tab. Click on the Scan button to search directories, and assign filesto datasets (scanning rules must first be created in the Admin module to scan). Anymatching files will create an entry in the Dataset Files tab. To import the files into thedataset table, check the Select box for the entry and click on the Import button.


Im ort Selected Files




Both Scan and Import actions can be initiated simultaneously by use of the Scan andImport button.

Important Notes:

• Invoking a manual scan/scan+import affects not only the current conversion, butaffects all conversions.

• Further eLoader processing of Prepare, Validate and Generate will not be

submitted automatically when the scan is initiated from the Dataset Files screen.Only when the Autoscan and AutoLoad process is submitted from theAdministrator module will the processing continue (see section 12.4).

• The Show All Files flag will display all files scanned even if they were not

assigned to a Dataset in the Conversion.

The Status field will be updated automatically based on the processes that have completedfor each Dataset file. Possible Statuses include:

• Entered – Entry manually entered but not yet imported.

• Scanned – Completion of scan step.

• Assigned – File attributes assigned to Dataset.

• Imported – File imported into Dataset.

• Imported/R – File imported with errors

• Generated – Completion of eLoader Convert process.

• Generated/R – Completion of eLoader Convert process with some rejected records.

• Generated/0 – Completion of eLoader Convert process with no resulting records to

load into OC.

• Loaded - Completion of Load into OC.

• Loaded/R – Completion of Load into OC with some rejected records.

• Del Ready – Completion of files with possible deletes.

• Del Ready/R – Completion of files with possible deletes plus records that had no

match in OC.

3.3.3. Importing XML type files (ODM format)

When importing a file of type XML, as a first step, the system creates a XMT – type filewhich is then actually imported. Within eLoader, the extension of the file name of theimported file as it appears on the Dataset Files screen will be changed by eLoader to“.xmt” once this file has been imported.





3.4. Formats

A format defines to eLoader the structure of the incoming file and is required whenever aDataset is used to import a file (tables/views do not require formats). If a Dataset needs to be created for which an appropriate format does not already exist, a new format should becreated. To access the Formats screen, click on the Formats tab.


Scan

Scan and Im ort




Formats can be of type Delimited, Fixed or Special.The condition on the Format tab gives the possibility to filter records during import. Note that each defined format is available for each dataset in each conversion, andupdating existing formats might affect datasets in various conversions. Note: the Fields ‘Multiple Records’, ‘Rec 1’ and ‘Rec 2’ are reserved for futurefunctionality.

3.4.1. Delimited Formats

A delimited format is used for a file in which the columns are separated by a specialcharacter. Currently: comma, pipe, semicolon, asterisk and tab are valid delimiters.

To create a format, enter a unique name. Select Delimited as the format type. Enter the delimiter in the Column Delimiter field (LOV available).

If any of the column data in the incoming file is enclosed in double quotes then the box ‘Data Enclosed in Double Quotes’ should be checked on. eLoader strips thedouble quotes.

If the incoming text files have column names on the first line, then check on ‘Column Names in 1st Line’. eLoader uses these names as column names for the Dataset tableit creates, and skips the 1st line when importing the file.

If the data file has no column names in the first line, the column names will bereferred to generically in eLoader as C1, C2, C3, etc. These tend to be hard to work with as it is difficult to know what the labels stand for and therefore you should assignmeaningful column names manually in the Column Name field (e.g. EKG, BP_SYS,… instead of C1, C2, C3, …). Entering the column names created the followingformat:





This format can be used with text files that are comma delimited and have 9 datacolumns. The names shown in the Column Name fields are used as column names for the Dataset.

An alternative (and recommended) approach is to let eLoader generate the format based on a sample file structure. This provides some benefits: (1) Displays the columnnames if they are in the first row of the file and allows them to be changed; and (2)Displays the data values from either the first line (no column headings in 1 st line) or from the second line (if there are column headings in the 1 st line).

You would almost always want to generate a format if there were no column headingsin the file. This would allow you to see the first row of data and rename C1, C2, etc.to meaningful names.

To generate a format based on a file, create the format as described above. Then enter or select from the LOV, the file location. Display the LOV by pressing F9 or clickingon the search icon. A pick list is available which displays a list of server directoriesaccessible to eLoader. Once a directory is selected, a second list appears with the filescontained within the chosen directory. Select the file and Save. Click on the Generate button. The system reads in the first line of the file and parses it to get the columnnames or uses C1, C2, etc (if there are no column names in the first row). The

following shows a result of the Generate:





Values from the first data line are displayed in the “Value from 1 St data line” column.This provides a way to quickly verify the structure of the incoming data file.

If Generate is used and no column names exist in the first line of the file then thecolumns will be named C1, C2, etc. The user may replace these placeholders withmeaningful names.





3.4.2. Fixed Formats

Fixed formats are created in the same way as delimited formats with a fewmodifications.

For Fixed Format, the columns of data in the file must start and end at the same

positions. All columns must be identified including their starting and ending position.

Similar to the Delimited Format, column names for Fixed format can be either enteredor generated from a file. Following is a Fixed format with entered columns:

Note that Column Delimiter and Data Enclosed in Double Quotes are disabled. Start position and end position must be specified for all columns.

If the file used to generate the format has column names on the first line, then the box‘Column Names in 1st Line’ should be checked on. eLoader uses these names ascolumn names. Note that the width of the right most column might have to beadjusted, as eLoader limits it to the number of positions of the column heading.

To generate a format based on a file, use the same method as for Delimited Formats.

eLoader assumes that the column names in the first line of the file or the data columnsare separated by at least two blanks. The first line is used to generate the format.

The following shows a result of the Generate:





This format was generated from following file:

The following example shows how Value from 1st Data Line is parsed according tothe entered start and end positions.





This format was generated from following file:

The first line contains column names. Each name starts in the starting position of thecolumns. Note: the user should check the ending position in the last data column aseLoader may not be able to determine the appropriate ending column position.

A user can change any Start Position, End Position or Column Name. Delete or addany row. In the format we just generated the first column was shortened to be from position 1 to 4, a new column was added from position 5 to 8, and the last columnlength was specified.





The Value from 1st data line is refreshed either by saving changes or clicking on therefresh button. The columns are re-sorted be eLoader after saving the changes.

The following is the result of pressing the Save button.





If the first line of the data file didn’t contain the column names eLoader generatesformat below. The column names are set to generic names.

eLoader checks the fixed format before saving any changes and displays warningmessages if any columns are overlapping or any positions are missing from the

format.

In the example below positions 12 – 17 are missing in the format.





In the example below columns are overlapping.

3.4.3. Special Formats

eLoader supports the creation of Special Formats following the CDISC ODM 1.1 model.The CDISC ODM 1.1 model is supported with a single Dataset with all DCMs contained





within it. The structure of this dataset will directly match the structure of the incomingXML file.

3.4.4. Condition

The condition on the Format tab gives the possibility to filter records during the import process. Column names from the format (LOV is available) can be used to set up thecondition. In addition to the column names, the following pseudo-columns can be used in

the condition:

Pseudo column Description

&conversion Name of the conversion

&study Name of the study

&dataset Name of the dataset

&type C(cumulative), I (incremental), D (Delete), T (TMS)

&lab Name of the lab

When records are found failing the Condition, they will be sent to the error file, and thestatus will be set to: Imported/R.





4. Mapping

Defining mapping rules consists of mapping the Dataset columns to the appropriate OCobjects. This process consists of identifying which of the columns are Keys (Document#,Patient, Event, Subevent, DCI Date, DCI Time, Site, and Investigator) and which of the

columns contain actual data responses which will be mapped to DCM Questions in OracleClinical.

These mapping rules can be either defined from scratch by entering Keys and Responses or by copying existing rules defined for other datasets (also from different conversions). Themapping would typically be performed only once for a new Dataset.

4.1. Copy Mapped Dataset Info

To copy existing mapping rules, highlight the Dataset name for which you want to define themapping rules and click on the Copy Dataset Metadata button. This opens the followingform that displays all datasets across all conversions that have values mapped.

Records displayed in this screen can be sorted by clicking on the header buttons. Searchcriteria can be entered using Oracle Forms query functionality.

After finding the appropriate Dataset record, highlight it and click on OK. This starts the

Copy Dataset Metadata process.

For each Dataset that was the target of a Copy Dataset Metadata operation the Copy box ischecked, and the copy information is shown in the right bottom corner of the screen.





After the copy operation is completed any of the mappings can be changed. The Copy Info box will still show the source Conversion and Dataset used in the copy operation.

If there are differences between the source and target Dataset, then any columns that arenot valid are highlighted in red. For example if the source Dataset had three columns A, B,and C and the target only has two A and B, then only A and B will be copied. However, if column B has been defined using a formula that referred to Column C, then in the targetthis would not be valid since Column C does not exist and column B would be displayedin red. The Valid flag for the response would also be unchecked.

This process allows you to copy the entire metadata mapping previously done for a similar Dataset thus eliminating the Key and Response Mappings described in the next sections.Skip to Section 6 – if all mapping has been performed through the Copy Operation. Tomap manually proceed with the remainder of Section 4.

4.2. Mapping Keys

Oracle Clinical requires the Patient and Event (at a minimum) to be defined in every batchload file. Other Key Fields may be optionally predefined (Document#, DCI Date, DCITime, Site, Investigator, and Subevent)

The Document# can be left blank, in which case it will be assigned by Oracle Clinical.

The Site and Investigator may be left blank and will be calculated by Oracle Clinicalduring the load process (if the patient has been pre-assigned to a site/investigator).

The Subevent can be left blank and will be calculated by Oracle Clinical if there is a DCIDate in the load file. There are also numerous ways to calculate the Subevent in eLoader as





described below. In order for eLoader to be able to find out whether data should be treatedas an update or should be treated as a new subevent, a DCI key can be defined.

DCI Date is optional only if it is defined as not required in OC – otherwise it must beentered.

DCI Time is required if it is defined as required at the DCI level in OC.

eLoader provides you with the option of defining or leaving blank any of the optionalfields.

To map the Keys, select the Keys menu tab.

Keys can be mapped for all datasets at once using the Default Keys form or for eachdataset separately. The keys are defined is the same manner regardless of the method used.

4.2.1. Default Keys

The Default Keys forms should be used if all datasets have the same mapping for any or allkeys (e.g., the patient number is stored in the PATIENT_ID field in all datasets). Click on

the Defaults button to display the Default Keys form.





4.2.2. Keys Metadata Fields

The following describes how to use both the Keys Metadata area of the Keys form and theDefault Keys form.

Each field on the screen has a list of values that shows all columns of the selected Datasetor all common columns across all datasets if the defaults form is used. Use the list of values to select any Dataset column or enter any valid SQL expression or constant value.

Examples:

Example 1: In the Dataset, the VISIT_NUMBER is a single digit number such as 1,2, etc. But in OC, the visit is defined as VISIT1, VISIT2, etc. To convert the singledigit to the value expected by OC, the user would concatenate the word ‘VISIT’ to theDataset column value.

VISIT_NUMBER – Dataset column name

‘VISIT’ – string

In the metadata field for Visit, the user would enter the following SQL expression:

‘VISIT’||VISIT_NUMBER

Example 2: In the Dataset, dates are collected in the format MM/DD/RR. OC expectsdates to be loaded in the format YYYYMMDD. Enter one of the following SQLexpressions to convert the date to the desired format:

TO_CHAR(TO_DATE(COLLECTED_DATE,’MM/DD/RR’),’YYYYMMDD’)

CONVERT_DATE(COLLECTED_DATE) – calls stored function (CONVERT_DATE)





Patient

Required.

Visit

Required

Subevent Number

The Subevent can be entered in eLoader, derived by eLoader, or left blank in which caseOracle Clinical will derive it during the batch load (if the date is entered and records areunique). The advantage of allowing eLoader to calculate the Subevent is that eLoader provides (1) another level of sorting in addition to the Key fields; and (2) looks up theactual subevent already assigned to the record in OC (if this is an update – note eLoader determines on its own which records are updates) and uses this subevent number in loadingthe data. This allows multiple subevents to be loaded/updated in OC without DCI Dates –

otherwise impossible in OC.

For example, if Lab Tests have been drawn at the same event on the same date and time,Oracle Clinical will treat them as duplicates. eLoader would allow the Accession Number to be placed in the Subevent field and used as another level of sorting when it derivesSubevent Number (the DCI Key option should then be used to help eLoader to determinewhether in a consecutive load using the same dataset records should be treated as inserts or updates)

To derive Subevent, eLoader sorts all records with the Derive Subevent Flag checked on by:

• Patient

• Clinical Planned Event

• DCI

• Date + Time

• Subevent base (the formula entered in the Subevent field)

• Data rowid (rowid of the data table record)

eLoader searches OC for a record match and assigns the subevent number from OC to theincoming data. If the record does not exist in OC then eLoader assigns the next free

subevent number to the incoming record. For every subsequent record for the same patient,DCI, and clinical planned event eLoader assigns a new subevent number when the Date,Time, or value in the Subevent field (e.g. Accession Number) changes.

If Derive is checked and a value is entered in the Subevent field, then eLoader will use thevalue of the Subevent field as a final level of sorting before deriving the Subevent number.





Value in Subevent Field Derive? Result

No No Field left blank in batch load file

Yes No Value in Subevent field is assigned as the Subevent

No Yes Value is derived by sorting the keys and assigningsubevent number from OC (if there is a match) or assigning the next free subevent number

Yes Yes Value is derived by sorting by the keys plus thevalue in the Subevent field and assigning subeventnumber from OC (if there is a match) or assigningthe next free subevent number.

Records are also sorted by Data rowid (if available) to ensure consistency betweendifferent eLoader runs. Two separate conversion runs from the same Dataset will producethe same results.

During the Convert process (creation of the file and loading into OC), the option is given toreload all Subevents. If this flag is checked on then eLoader performs its calculations of Subevent starting with 0 and does not check Subevents in OC. If this flag is checked off,then eLoader searches OC for a record match and assigns the Subevent Number from OCto the incoming record. The Reload all Subevents function only has an affect if Derive ischecked on.

DCI Date

The DCI Date is required if it is a required field in Oracle Clinical. If the DCI Date isentered then eLoader will use that as part of the sort to calculate subevent and as part of thekey to match with subevents that already exist in OC.

DCI Time

The DCI Time is required if it is required at the DCI level in OC.

Site and Investigator

The Site and Investigator fields may be either mapped for the Dataset or left blank if the patient is assigned to a site (to allow Oracle Clinical to derive these based on the patientnumber).

Document Number

The Document Number field may be mapped to a Dataset column or left blank. If the fieldis left blank, Oracle Clinical will assign a document number when the data is loaded.

4.2.3. Verifying Metadata





After entering the Key Mapping information, click on the Verify button to check the SQLSyntax. If there are any SQL errors, the fields will be highlighted in red and an error message with the SQL error is displayed. If no syntax errors are found a message isdisplayed to confirm the Metadata is OK.

The following error was detected because the conversion formula for the DCI Date fieldwas missing the right parenthesis.





4.2.4. Conditions

For complex situations, a condition can be applied. For example, if certain patient numbersare padded with leading 0’s then you might want to treat these separately. In this case, twosets of keys would be created – one with the condition PT_NO LIKE ‘0%’ and one withthe condition PT_NO NOT LIKE ‘0%’. Click on the Up/Down arrow button on the right

of the Keys Metadata to create a new Keys record or display existing records.

4.2.5. Dataset DCI Key / OC DCI Key

The Dataset DCI Key and OC DCI Key are optionally used for additional criteria toidentify subevents in Oracle Clinical and to determine whether a subevent already existsand should be updated or is a new insert.

For example, a file is received from a lab and is loaded by eLoader and subevent iscalculated based on Date and Accession Number. An update file is received and we wantto make sure that when eLoader searches OC to find the subevent number it also looks atthe Accession Number (if eLoader does not look for the subevent number, it will concludethat the Accession Number has been updated, rather then to create a new subevent). Weadd the Accession Number to the DCI Keys – to ensure that the patient data (Accession Number) is checked in OC to find matches.

• Select the DCI from the list of values for which an additional DCI Key needs to be

defined. Note: multiple DCIs may be listed (each DCI can have exactly 1 DCI key,regardless of the dataset or conversion).

• Enter in the Dataset DCI Key field, the column or columns from the Dataset which

identify the key. The LOV contains all Dataset columns. Multiple columns may beselected and concatenated together (for example TESTDATE||ACCESSNO)





• Select the OC DCI Key. The questions from the non-repeating question groups in the

DCI selected will appear in the LOV. Select the OC Questions that match the incomingvariables (e.g. LPARM||ACCESSION_NO). Fields may be concatenated together, andconstants or formula may be used.

When the Key Mapping is complete you are ready to map the responses.

4.3. Mapping Responses

To map the Responses, select the Responses menu tab. Only datasets that have at least oneKey mapped will be displayed in the Responses menu tab. Responses can be mappedmanually or the Automap function can be used. Select the Dataset to work with from theLOV. eLoader will automatically remember the dataset that had been selected in the Keysscreen or change to work with another dataset.

4.3.1. Automap

To automap, click on the Auto Map icon to the right of the Dataset field. A window isdisplayed to select DCM(s) that will be searched through for questions to map to. Selectthe DCM(s) from the LOV.





When you click on OK, eLoader attempts to map each incoming data item against thequestions in the selected DCMs. eLoader attempts to automap using the following criteria:

• Checks all conversions for this study for mapping of the data item to a question in the

selected DCM(s). In case it finds a hit, the following message is stored in the mappingscomment:“Automapping (current Study Conversion xxx)”

• Checks the study in OC for an exact hit of the data item name in the questions of the

selected DCM(s). In case it finds a hit, the following message is stored in the mappingscomment:“Automapping (OC)”

• Checks all conversions regardless of the study for mapping of the data item to a question

in the selected DCM(s). In case it finds a hit, the following message is stored in themappings comment:“Automapping (not current study Conversion xxx)”

• Checks the study in OC for a hit (using Soundex) of the data item name in the questions

of the selected DCM(s). In case it finds a hit, the following message is stored in themappings comment:“Automapping (OC Using Soundex)”

All auto mapped items will have the Mapped Flag checked. Any auto mapping which isnot correct can be manually adjusted as described in the next Section.

4.3.2. Manual Mapping

To manually map, highlight the data item to be mapped to a question in Oracle Clinical.Place the cursor in the Question field and press F9 or use the icon to display the list of values.





This screen displays all DCI-DCM-DCM Subset-QG-Question-Occurrence combinations

that exist in this study along with any Qualifying Question Values. Query for theappropriate record or for the DCM or QG with which you want to work. The fields in thisscreen can be sorted by clicking on the raised button above the field.

eLoader retains the entered search criteria throughout the user session. For example, if records for the DCM Demography are queried and displayed then the form displaysDemography records every time the user opens the form. Press F7 (Enter Query) twice tosee current selection criteria or requery based on new selection criteria.


After selecting the columnon the left, click to displaythe uestions in OC




Once you’ve identified the Question to map to, select it, click on OK, and save . TheQuestion, Occurrence SN, DCI, DCM, DCM Subset, Question Group, QQ Value andConversion Formula fields are automatically populated based on the Question selected.

In the following case there is a one-to-one mapping between the incoming data item(MED_NAME) and the response inserted into Oracle Clinical question (MEDICATION).

In some cases, for other questions you may want to perform some manipulation of theresponse (e.g. decode responses to the proper DVG values in Oracle Clinical, apply aformula, etc.).

4.3.3. Display Incoming Data Values

You can display for any data item the raw data values and their frequencies. Select thedataset variable and click on the Source button. The Mapping Info screen displays thevalues and their frequencies. Note that the values for all files associated with this datasetwill be displayed. The Incl. Flag indicates whether this Original Value belongs to a recordthat meets the Condition as entered for this response.





4.3.4. Applying Formulas

A valid SQL formula can be applied to any data value. For example, you can apply ato_date function to any incoming date that must be converted to the RRRRMMDD format.The following screenshot displays an example of this.

4.3.5. Generating Decode Statements

You can also change the incoming data values and let eLoader automatically create theformula for you (for decodes). First, display the Mapping Info box (click on Source) toreview the incoming data values for that question. Change any values as appropriate andhave the system generate the decode statement for you.





In this example, the Dataset question GENDER has 2 incoming values (F, M) which are bydefault not modified in the Converted Value (note Converted Value also shows M, F).

In this example, you could use the OC Info button to display information from OracleClinical about the mapped Question in Oracle Clinical (in this case the DVG values areuseful).





We can see that in Oracle Clinical the valid responses for the question are actually MALEand FEMALE. You can use the decode functionality to convert the incoming values (M, F)to these values.

Enter the values to be decoded or use the List of Values in the Converted Value field todisplay all valid DVG values and select from the list.

Click on the Generate Decode Statement button and eLoader generates the new formula.





The new formula is inserted in the Conversion Formula field.

This Formula can also be manually entered and the Apply Conversion Formula button onthe Mapping Info form can be used to determine the result of the formula.

The Mapping Info form can also be used to modify the conversion formula. Assume thefollowing is displayed in the form:





Other values could be entered in the Original Value field to include them in the generateddecode statement.

After clicking on the Generate Decode statement button the following Decode statement isgenerated in the Conversion Formula field:

<NULL> can also be entered to represent a null value.





The following formula is generated:

Another example of using <NULL>:





The above mapping generates the following conversion formula:

4.3.6. Skip Repeats

The Skip Repeats Flag should be checked for non-repeating questions if the non-repeatingquestion is part of an incoming record which will be mapped to a repeating and non-repeating QG. For example, if you have lab data which also has demographic informationthat is repeated for each record – you will only want the demographic information to be





loaded once – not for every lab repeat for that visit. The flag indicates to eLoader to onlyload these items once for that unique DCM. The repeating data will be loaded as usual. Bydefault, the Skip Repeats box is checked for non-repeating questions.

4.3.7. Qualifying Questions

The Qual Question Value box will be highlighted (rather than gray) when the Question youhave mapped to belongs to a DCM requiring a Qualifying Value. When mapping to aquestion which has a predefined Qualifying Value, the value will be filled in automatically.The Qualifying Value may also be selected from the list of values which will contain theDataset columns as well as any Qualifying Values defined for the selected DCM.

4.3.8. Repeat Sn

eLoader can automatically generate the Repeat Sequence Number in several different waysfor repeating questions.

The Repeat Sn box field will be highlighted when a mapping has been made to a question

in a Repeating Question Group. If the question is non-repeating, the field is gray. Either aconstant or variable can be entered in this field. The meaning of this value depends on theDerive Repeats Flag.

If the Derive Repeats Flag is unchecked, then the value in this field is used as the actualrepeat number. This might be desirable if the incoming file has a sequence or actual repeatnumber and no repeats are missing.

If the Derive Repeats Flag is checked, then the value in this field is only used as anadditional sort. eLoader derives the actual repeat number based on other factors (describedin the following). This might be desirable if you wanted eLoader to calculate the repeatnumber, but wanted some control over the order in which the repeats were numbered.

If the Derive Repeats Flag is checked, and this field is null, then eLoader derives the repeatnumber without using this field as an additional sort level.

The Derive Repeats Flag is checked on by default for repeating questions.

When the Derive Repeats Flag is checked, eLoader sorts all records by:

• Patient

• Clinical Planned Event

• DCI

• Subevent

• DCM

• DCM Subset

• Qualifying Question Value Text

• Question Group





• Question

• Occurrence

• Repeat base (the formula entered in the Repeat field)

• Data rowid (rowid of the data table record)

eLoader looks for records with the same Patient, Clinical Planned Event, DCI, DCM, DCMSubset, Qualifying Question Value Text, Question Group, Question, Occurrence, andSubevent. The first record found gets Repeat Sn set to 1. For each following record theRepeat Sn is increased by 1.

Records are sorted by Data rowid (if available) to ensure consistency between differenteLoader runs. Two separate conversion runs from the same Dataset will produce the sameresults.

Value in Repeat Field Derive? Result

No No Field left blank in batch load file

Yes No Value in Repeat field is assigned as the Repeat

No Yes Repeat Value is derived by sorting the keys

Yes Yes Repeat Value is derived by sorting by the keys plusthe value in the repeat field

4.3.9. Dataset QG Key and OC QG Key

In order to reduce the number of records loaded in the batch data load file, to updaterepeats, and to identify potential deletes (in Cumulative mode), eLoader attempts toidentify for incoming records whether they are an insert, update, or duplicate of a recordalready existing in OC.

For non-repeating Question Groups, this is accomplished by comparing the incoming keyvalues and extended keys with the key values and responses in OC.

For repeating Question Groups, the keys are used to identify the Question Group – butadditional data is required to identify the actual repeat.

For example, if the following has been loaded into OC:

LPARM LVALUE

NEUTROPHILS 2.4

LYMPHOCYTES 4.7

BASOPHILS 1.9

An updated file is sent by the lab with the following information:





Test Name, Test Value

Lymphocytes, 4.8Basophils, 1.9Eosonophils, 8.5

We would like eLoader to update the responses for the Lymphocytes test, identify that theBasophils tests has the same response, insert Eosonophils as a new test, and identify thatthe Neutrophils test is missing from the latest file.

In order for eLoader to do this it must be able to match incoming values with existingrepeats in OC. To do this additional key information is required. This Key Information is provided to eLoader through the use of the Dataset QG Key and OC QG Key. The DatasetQG Key identifies the information from the incoming file to use to uniquely identify eachrecord. The OC QG Key identifies the information from Oracle Clinical to use to uniquelyidentify each repeat.

In the example above, Test Name is the Dataset QG Key. LPARM is the OC QG Key.

When the value of each of these matches, eLoader compares the response values todetermine if an update occurs. When the record is in the incoming file but not in OC,eLoader determines that the repeat is an insert. When the record is in OC, but not in theincoming file, eLoader is able to identify the record in OC a potential delete.

eLoader can use this information to set the Repeat SN (by finding the repeat in OC). Thisallows eLoader to reduce the number of records in the load file by removing recordsalready in OC (during Convert Stage) and identify potential deletes for cumulative files(during the Delete Process).

The Dataset QG Key and OC QG Key can only be set for a repeating question in aQuestion Group. Once the values are set for one question in the group, eLoader

automatically copies the same values to all other repeating questions in that QuestionGroup.

A list of values exists for both the Dataset QG Key and OC QG Key fields. The DatasetQG Key displays all items from the incoming file that have been mapped to repeatingquestions. The OC QG Key field displays all repeating questions from the mapped DCM inOC. Formulas or multiple fields can be entered for each Key. For example, to uniquelyidentify an Adverse Event – the AE Name, Start Date, and Severity values may need to beconcatenated in both Keys. Note: fields are concatenated using the double pipe ‘||’symbol.





4.3.10. Conditions

For complex situations, a Condition can be applied to restrict the use of a responsemapping. For example, when data has to loaded into a DCM only when the patient hasreached a certain age, the condition might be used. Also, each dataset column can bemapped to multiple OC questions. Click on the Down/Up buttons on the bottom right partof the Responses Metadata area to create a new conversion formula record or displayalready entered conversion formulas for the selected Dataset column. The little “D” buttoncan be used to Duplicate the mapping from the previous mapping.

4.3.11. Investigator Comment

The Inv Comments field is used to load Investigator Comments. Select the Dataset columnname from the LOV that holds the Investigator Comment for that particular question or enter a Text String.

4.3.12. Comment

The Comment field is used to record a text comment providing additional informationconcerning this particular mapping. Note: this comment is not placed in the batch load

file.

4.3.13. Restriction on Mapping

Although eLoader can handle quite some situations, there is a limitation - it is not possibleto set up mappings for loading into 1 DCI with different DCMs (DCI modules) when theseDCMs have a different Qualifying Question Value. If the DCMs are the same but havedifferent Qualifying Values it will work.





4.3.14. Special Mapping Notes

• Not all columns must be mapped (only those to be loaded into OC).

• Columns from the same Dataset can be mapped to different OC Questions.

• The same Dataset column can be mapped to multiple OC Questions with different

conditions. Use the Down arrow button to create a new mapping record and the ‘D’ button to duplicate a previous conversion record.

• Multiple Dataset columns can be mapped to the same OC Question

See Appendix B for an example of mapping two Dataset columns to one OC Question.

4.3.15. Pseudo columns

For use in conditions and formula, in both the Key and Response Mapping screens,additional (pseudo columns) can be used (note that these have to be written in lower case):

Pseudo column Description

&conversion_id Number of the conversion

&data_info_id Number pointing to this eloader.data_info record

&header_info_id Number pointing to this eloader.header_info record

&owner Name of the owner of the dataset table

&table_name Name of the dataset table

&dataset Name of the dataset

&column_name Name of the column being mapped

&dci Name of the DCI

&dcm Name of the DCM

&qq_value Qualifying Question value

&occ_sn Occurrence sequence number of this question

&question Name of the question





5. Reports

Mapping reports can be generated to show Keys and Responses, and Data Mappings fromthe Reports Tab. See section 11 for a description of the TMS Load Report.

5.1. Report Set-up

Select one of the available reports in the Report field. In the example above, the Keys and

Responses report was selected.

Report parameters are displayed on the right side of the screen. The parameter fieldsdisplayed will depend upon the Report selected. Enter values for the parameters beforeexecuting the report. If no Dataset is selected the report will display mappings for alldatasets in the conversion.

Select the Report Server, Destination Type, Destination Name, and Output Format.

The Report Server name can be entered manually or selected from the LOV. The LOVcontains all Report Servers listed in the OC Reference Codelist REPORT_SERVER. If theReport Server name is left blank then the report is executed by the Reports Runtime module

on the Web Server.

Select the Destination Type for the report - Printer, File, and Screen are allowed.

If Printer is selected, enter the name of the Printer in the Destination Name field. The printer name can be selected from a list of values or entered. The list of values contains all printers listed in the OC Reference Codelist PRINT QUEUE NAME. In this situation, theOutput Format parameter is disabled.





If File is selected, enter the name of the file in the Destination Name field. Select PDF or HTML in the Output Format field. Reports are created in a directory specified during theeLoader installation (in the ELOADER_REP_DIR registry entry of the Web Server).

If Screen is selected, then the Destination Name is disabled.

5.2. Keys and Responses Report

The Keys and Responses report can be generated for a selected Dataset. If no Dataset isselected, the report will be generated for all datasets in the conversion.

This report shows all Keys and Responses metadata defined for a Dataset.

5.3. Mapping Values Report

The Mapping Values report can be generated for a selected Dataset or for all datasets in theconversion if no Dataset is selected.





This report displays the responses metadata for each column together with the actualmapping of data. For each unique data value a converted value is displayed.





In many cases the conversion formula returns the original column value. The displayedoriginal and mapped values are equal. Users can suppress showing equal values on the report by checking off the Print Equal Mapping Values parameter.





6. Loading Data

After all necessary Keys and Responses have been mapped (manually or by copyingmetadata), select the Convert menu to generate the Oracle Clinical Batch Data Load filesand load the files into Oracle Clinical. Processing of a group of data is controlled by the

creation of Conversion Runs. Conversion Runs may be created by the user manually or created automatically by the system in certain cases. Processing of the data through theConvert steps and the optional loading into OC will occur by Conversion Run.In this screen, three small columns have the following meaning:

Heading Description

T Type of Run - Possible values areC – CumulativeD – DeleteFor Incremental loads, column is left empty

E Errors – indicates whether during the Prepare, Validate or Generate stage,errors have occurred.

L Locks - to indicate whether some DCMs are locked by other runs. It doesnot take into account whether the current run has to wait, or will load intonot locked DCMs.

6.1. Conversion Run Creation

All Datasets or Dataset files to be included in the Conversion Run should have the Selectflag checked on in either the Datasets or Dataset Files tabs. In case a dataset is based onDataset Files, in the Datasets/Dataset Files column the name of the dataset (in brackets)will prefix the name of each file. An initial Conversion Run will be automatically created





the first time the user navigates to the Convert tab. All DCMs are displayed for the targetstudy. For each DCM, any Datasets that have at least one question mapped to that DCMare displayed. If a DCM should be excluded from processing in the Conversion Run theSelect flag may be unchecked for that DCM in the DCM/Datasets for selected ConversionRun section.

Conversion runs provide a way to set Convert Options and track the load of one or morefiles. You can later review the Run and its output. Other users may create their own Runswhich will not affect or obliterate the results of your Run.

Additional Conversion Runs may be created by selecting the Datasets and/or Dataset Filesin their tabs and Clicking on the Create Run button.

Note: when using the Autoscan /Autoload feature of eLoader the system will create theConversion Run automatically for each scanned file.

When a Conversion Run is created, a unique Conversion ID is generated for the run. ThisID is used to track the Conversion Run through its processing steps. The Name of the run

can be updated by the user, it is defaulted by the system.

Multiple Conversion Runs may be referencing the same DCMs. When this occurs, a‘Lock’ may be placed on the DCM by the Conversion Run. This is noted by a check in the‘Lock’ flag of the Conversion Run. The first Conversion Run must complete processing prior to the second beginning if the DCM has been locked. The user may view the LockedDCMs clicking on the ‘Show Locked DCMs’ icon.

Show Locked DCMs.

The user may release the lock on the DCM manually by clicking on the Unlock button.





Conversion Runs not referencing the same DCMs may process concurrently.

6.2. Convert Options

Set the Convert options by selecting the desired Conversion Run and clicking on the Convert

Options button which displays the following screen.





6.2.1. Max Records in BDL File

Optionally select the max number of records to put in each batch file. Multiple load fileswill be generated if the limit is exceeded. This would be helpful if you had a very large loadand wanted to break the files up so they could be submitted separately. Important note: whenusing this option, the OC transfer mode should be set to Both.

6.2.2. Execution Options

6.2.2.1. Execute in Batch

eLoader performs two processes (prepare and generate) as well as an optional validate stage.These are submitted as background batch jobs by default. In the rare event that some type of debugging is required, CSS technical support may ask you to check this flag off so that the jobs are run in blocking mode. Otherwise leave the flag as set.





6.2.3. Processing Options

6.2.3.1. Ignore Responses for Unchanged Records

This setting is used to reduce the number of records in the OC batch load file. During its processing, eLoader checks if the record in an incoming file has already been loaded into OC

(using the Keys, DCI Keys, and DCM QG Key/Reverse QG Key). If the record has already been loaded it is excluded from the batch file loaded into OC.

The effect of this setting can be to greatly reduce the overall processing time. We have foundduring testing that eLoader is far more efficient in eliminating duplicate records than OC isduring its processing. We tested a 12,000 record file which only had two updates. Using thisoption, the total time for eLoader and OC processing was reduced by 90% compared to OC performing the processing on its own.

Note that non-repeating questions can always be identified because of the keys. For repeating questions, the QG Key and Reverse QG Key are required to identify if a repeat is aduplicate.

6.2.3.2. Keep BDL Records for Delete

This setting is used to identify records that have been previously loaded into Oracle Clinical but have subsequently been removed from the incoming data file. For example, if a lab sendsa file with 20,000 records and sends a cumulative file in which 2 records have been deleted,eLoader can use this option to identify the two records in OC that have been deleted from theincoming file. Subsequently, the user may invoke the Delete function in eLoader to removethese records from OC.

This setting works in conjunction with the Type Flag in the Datasets or Dataset Files screen.If the Type Flag is set to ‘C’ (cumulative) and this option is checked on, eLoader saves the

records from the incoming file for those datasets to compare with the records previouslyloaded into OC.

eLoader can always identify non-repeating question group records for delete using thestandard keys. For repeating question groups, the QG Key and Reverse QG Key are requiredto identify potential deletes. Records are reserved during the eLoader Generate stage. Usethe Delete function (see Delete) to review and delete desired records. DCI Keys may also benecessary to identify the correct subevent – when subevent calculation was based on a patient data field – like Accession Number.

6.2.3.3. Reload All Repeats

Reload all repeats function is used to determine whether the values in OC should beconsidered if eLoader is deriving repeats. If Reload all Repeats and Derive Repeat are set onthen eLoader ignores the values in OC and derives the repeat number starting with 1.

Typically you would have Reload all Repeats checked off. eLoader then performs thefollowing processing:

If there is a repeat value in the repeat_sn field and Derive Repeats is checked off, eLoader uses this number as the repeat_sn number. If Ignore Unchanged Responses is set on then





eLoader will check if this repeat exists in OC with the same value (if it does then it ismarked as a duplicate and will not be reloaded).

If Derive Repeats is on, and the DCM QG Key and Reverse Key are set, eLoader checks if this repeat exists in OC. If it does, it sets the repeat_sn in the batch load file to what it is inOC. If Ignore Unchanged Responses is also set on then eLoader will check if this repeat

exists in OC with the same value (if it does then it is marked as a duplicate and will not bereloaded). If the repeat does not exist in OC, eLoader will derive the repeat_sn by sorting therecords by the keys and the value in the repeat_sn field and taking the max repeat in OC for this page and starting with max + 1.

Reload all Repeats = ‘Y’ (Ignore Unchanged Responses cannot be set on)

Value in

Repeat_sn

field

Derive

Repeats

QG

Key

Set

Result OC responses

used to

calculate

repeat

Yes Yes Ignored Calculate repeat number by sorting records

using keys and value in Repeat_sn field andstarting with 1

No

Yes No Ignored Use value in Repeat_sn field as repeatnumber in batch load file

No

No Yes Ignored Calculate repeat number by sorting recordsusing keys and starting with 1

No

No No Ignored Repeat Number defaults to 1 in batch loadfile for all records – will fail during validateor load into OC if there is more than onerepeat per question group

No

Reload all Repeats = ‘N’ and QG Key Set

Value in

Repeat_sn

field

Derive

Repeats

QG Key Result OC responses

used to

calculate

repeat

No No Ignored Repeat Number defaults to 1 in batch loadfile for all records – will fail during validateor load into OC if there is more than onerepeat per question group

No

Yes Yes Used QG Key is used to set repeat number for matching records found in OC. Records notfound are sorted by the keys and the value

in the repeat_sn field and given a repeatnumber starting with max repeat_sn + 1.

Yes

No Yes Used QG Key is used to set repeat number for matching records found in OC. Records notfound are given a repeat number startingwith max repeat_sn + 1.

Yes

Yes No Ignored Value in Repeat_sn field is used as repeatnumber in batch load file

No





Reload all Repeats = ‘N’ and QG Key Not Set

Value in

Repeat_sn

field

Derive

Repeats

Result OC responses

used to

calculaterepeat

No No Repeat Number defaults to 1 in batch loadfile for all records – will fail during validateor load into OC if there is more than onerepeat per question group

No

Yes Yes Records are sorted by the keys and the valuein the Repeat Sn field and given a repeatnumber starting with max repeat_sn + 1.

Yes

No Yes Repeat SN is set by calculating repeatnumber starting with max repeat_sn in OC+ 1

Yes

Yes No Value in Repeat_sn field is used as repeatnumber in batch load file

No

If Ignore Unchanged Responses is set on, then only new/changed responses will be updatedor inserted. This can be especially time saving for large cumulative files. If IgnoreUnchanged Responses is set off, then all responses are loaded in all situations.

6.2.3.4. Reload all Subevents

This field only has an effect if Derive Subevent is checked on in the Keys screen

If the ‘Reload all Subevents’ flag is checked on, then eLoader derives Subevent by sortingrecords based on the Keys and starting with 0. Values in OC are not taken into consideration.

If this flag is unchecked, then eLoader derives Subevent as described in the Keys section.You would normally want Reload all Subevents checked off.

6.2.4. OC Load Options

These fields are used if you wish eLoader to automatically submit the OC Prepare, Load, andTransfer job after it has finished its own processing.

6.2.4.1. Load generated data into OC

If this flag is checked off, eLoader performs its own processing but does not submit the OCBatch Load job. eLoader creates the load file in the specified directory, and creates a recordin the OC Out of Study Load, Batch Load Data Files screen. This record is named using theConversion Name followed by a unique identifier. This name can be customized in theAdmin Control screen (OC File Name). The following variables are available: &conversion,&study, &dcm, &dataset, &datasetfile. Any combination may be used.





Note: the Batch Data Load file may be viewed from within eLoader by clicking on the ShowGenerated OS Files icon. eLoader always uses the standard format (ELOADER_FORMAT – created during the installation process).

If the Load Generated Data into OC flag is checked on, then eLoader will perform all thefunctions described above plus submit the actual Load/Prepare/Transfer job in OC. With this

setting on it is unnecessary to open OC in order to load batch files. This setting may also bedisabled from the Control screen.

6.2.4.2. OC Transfer Mode

If Load generated data into OC is checked on, these settings can be used to determine howthe OC Batch Load is run.

• Select Insert, Update, or Both

• Select Privileged or Non-Privileged – Note: Locked records must be updated

using Privileged Transfer. Only users who have Privileged Update in OC for a

study will have that privilege in eLoader.

6.2.5. Destination Path

Select the destination path on the server to store the batch load files. The LOV displaysavailable paths defined by the Administrator during setup.

6.3. Executing the Conversion

eLoader performs two required steps in creating the batch load file – Prepare and Generate.An interim Validate Step is also available. The steps may be performed separately or incombination. The status of each Conversion Run is displayed on the main Convert screen.

The status may also be viewed from the Batch Jobs screen.

6.3.1. Prepare

The Prepare Stage processes all records from the incoming file (minus any that have beenexcluded by conditions). All SQL formulas are applied to the incoming data. Subevent andRepeat are derived where marked. Data is compared to OC values to determine inserts,updates, duplicates, and deletes. The result of the Prepare Stage is a set of records loadedinto the eLoader batch_data_load table.

6.3.2. Generate

The Generate Stage creates the batch load file for OC. During this stage records already inOC will be omitted (if Ignore Unchanged Responses is set on). If the Load into OC Flag isenabled then after the file has been generated, eLoader will run the actual OC Batch DataLoad job. The results of this job will also be displayed in eLoader.

6.3.3. Validate

An optional Validate Stage may be executed to identify any potential errors in the data prior to loading into Oracle Clinical. Individual Validation checks may be enabled or disabled by





default for all conversions from the Admin module. The default settings may be overriddenfor an individual conversion run by clicking on the Validation Checks icon. In addition,validation checks may be set to reject the discrepant record when an error is found or to stop processing on the entire file. In case a record fails validation causing it to be rejected, allrecords that would be loaded for the same combination of Patient/Visit will be rejected.These records are marked with error code 99 in the reject and error files. This exclusion of

non-failing records will prevent loading of incomplete data (and this might lead to creationof unwanted subevents). Note: all records will be processed to get all error messages.

The Validate stage performs the following checks:

• Verifies that the patient exists in Oracle Clinical and is assigned to a site.

• Verifies that the event is valid in Oracle Clinical.

• Verifies that the DCI, DCM, Question Group, Question, Occurrence, and Repeat

Number are valid.

• Verifies that DCI Date and Time have been converted to an acceptable format.

• Verifies that DCMs with Qualifying Questions have a non-null Qualifying Value and

that those without a Qualifying Question do not contain a Qualifying Value.• Verifies that all fields do not exceed maximum length.

• Verifies that all required keys are non-null.

• Verifies that there are no duplicate records in the file.

• Verifies that the patient or study is not frozen.

• Verifies that a response for a question with a DVG is valid.


Click to display and modifyValidate Check Settings




• Verifies that the Investigator and Sites listed are valid for the study.

In addition to these checks, the administrator has the option to include additional (custom)checks. These checks start with Check# = 100.

If any of these errors are found, the error flag will be checked and either the discrepantrecords will be rejected or the processing stopped for the file based on the setting enabled.The user can view the errors by clicking on the Errors tab. The errors will also be written toa file. Each record in the error file will contain original data followed by a separator (‘##’)and an error message. The import process will skip any text followed by the separator sothat the file that contains the error messages can be processed by the import withoutremoving the error messages. The errors should be corrected before further processing isundertaken.

Following is a list of errors that could be reported in the Validation step:

Error # Error Description

1 Invalid subevent number. Should be between 0 and 99

2 Invalid repeat number. Should be between 1 and 999

3 Invalid patient

4 Patient is frozen

5 Study is frozen

6 QQ Value Text must be NULL

7 QQ Value Text is required

8 QQ Value Text is not valid

9 Invalid combination of DCI, DCM, QG, Q and DCM Subset

10 Patient not associated with investigator/site

11 DCI Time should not be NULL

12 Invalid DCI Time

13 DCI Time should be NULL

14 Both DCI Date and Subevent Number are NULL

15 DCI Date is not valid

16 Invalid Clinical Planned Event

17 Invalid repeat for a non-repeating Question Group

18 Duplicate Batch Data Load records

19 Invalid Site

20 Invalid Investigator

22 Response is longer than allowed

23 Response not in DVG

6.4. Conversion Submission Options





There are several options for submitting the Prepare, Validate, and Generate Stages. Eachstep can be run separately by clicking on the Prepare, Validate, Generate jobs. This typicallywould be done for debugging purposes.

Combined jobs can also be run:

P+V – Prepare and Validate

P+G – Prepare and Generate

P+V+G – Prepare and Validate and Generate

If a combined job is run and an error in processing occurs at the first or second stage, theError flag will be checked next to the Conversion Run. Processing will stop or thediscrepant records will be rejected based upon the options chosen. Errors can be displayed by clicking on the Errors tab. Note: Skipping the validation step will save time but will result in a greater risk that the

Generate or Batch Load Process in OC will fail.

Below is a sample of validation errors generated.

When the Generate step is selected (either separately or in a combined process) thefollowing window appears.





Each output file generated by eLoader will have a unique name. In case at the Dataset Filethe Lab has been specified, the value will be displayed here, or the appropriate value can be selected from the LOV on this screen.

Select No to Cancel or Yes to continue. After continuing, eLoader presents a Submissionnotification message for the job that was submitted.

eLoader displays the status of the job in the Convert screen. Click on the Refresh icon toautomatically refresh until the job is completed. If the Execution Option to Load generateddata in OC is on - the OC Batch Load job is automatically submitted as well.


Refresh




6.5. Additional Convert Screen Buttons

Remove Temp Records – Use this button to remove records from the batch_data_loadtable. The Administrator may want to perform this function to stop the table fromgrowing too large. This also can be used to reset the status of a run to new. Convertoptions may only be changed for a run when the status is ‘New’.

Refresh OC Lookup – Use this button to refresh the OC Look-up tables. Typicallythese would be set-up to refresh nightly. The Administrator may want to use this button to refresh at a greater frequency. Note that even if the tables are not refreshedthere is no affect on results as eLoader goes directly to OC for the responseinformation (however this is slower than using the Look-up table). eLoader automatically refreshes on its own and this feature should only be used byAdministrators if there is a problem.

Batch Jobs – Use this button to display the Batch Jobs screen (displayed below). Thisscreen displays both eLoader and OC Batch Data Load jobs.





Use the Refresh button to automatically update the status of the job. Note that the status isautomatically updated on the Convert Main screen. Use the Stop Job button to stopeLoader’s jobs (OC jobs cannot be stopped from eLoader). The ability to stop jobs mayhave been removed by the Administrator during the Installation.

Refresh – Use this button to toggle the refresh for the main Convert screen. Redindicates refresh is on and green indicates it is off.

Show Generated OS Files – Use this button to view the output files generated for theOC Batch Data Load process. A window will appear with the file name andlocation information. Click on the ‘View eLoader File’ button to view the eLoader generated batch data load file; click on the ‘View OC Output File’ button to viewthe output file generated by OC during the BDL process. Enter the OS Password for the database server to view the file.





You may need to enter the OS Password for the database server to view the file.

Click View File to review the file. Below is a sample.





Show Run Progress can be used to check the status of the current run.

This brings up a screen which displays the time prepare, validate, and generate takefor the run. It also displays information on the actual stage in the process beingcompleted. This enables users and administrators to verify the progress of their runs

and debug if necessary.





7. Deleting Data

Data in OC can be deleted by eLoader using two different methods:

• Deletes identified by special file.

• Deletes identified by process.

On the Control Tab of the Admin module, each of the delete options can beenabled/disabled.

7.1. Delete by File

The delete by file method allows potential Deletes to be identified in a text file. To use thedelete by file function, the File Delete Option must be enabled in the Control screen. TheDelete file must have the same format as other input files for that Dataset and will beimported by eLoader using the same mappings as for other files associated with theDataset. You do not need to create a separate Dataset for Delete files. The delete file must

be assigned a type of ‘D’ in the Scan rule or in the Dataset File screen if importedmanually.

The Delete file is processed using the same method as other files. Run Prepare andGenerate (and optionally Validate). The system compares the records in the file with therecords in OC using the mappings and Keys, DCI Keys, and QG Keys. The matches will be displayed in the Delete screen of the Convert tab. The user can review the records anddecide which responses should be deleted before initiating the delete process. eLoader does not delete any records before the user invokes the Delete function (see section 7.3).

Any records in the incoming Delete file that do not have matches in OC are rejected andsent to a reject file (error code: 999). In this event the job will end with a status of Del

Ready/R (for rejects). If all records match then the job will complete with a status of DelReady.





7.2. Delete by Process

Data may also be identified for deletion by allowing eLoader to review data in a cumulativeload file (or a cumulative dataset, in case of Oracle tables) and determine which records arein OC but missing from the cumulative file (and thus potential deletes). For example, if afile is loaded and then a new cumulative file is sent with one or more records removed,eLoader can identify the records, display them to the user, and optionally allow them to bedeleted from Oracle Clinical.

In order to invoke the Delete by process function, two flags must be set:

• Indication that cumulative data is available (column “T” on the Convert tab should

show a “C”):

o For a Dataset File that contains all the data for (a set of) DCMs, on the

Dataset Files screen the Type Flag should be set to ‘C’

o For an Oracle table dataset that contains all the data for (a set of) DCMs, on

the Datasets screen the Type Flag should be set to ‘C’.

• In the Convert Screen, in the Processing Options window, check on Keep BDL

Records for Delete.

When these options are set, the Delete button is enabled in the Convert screen. After executing Generate, click on the Delete button. eLoader searches all appropriate DCMs for potential deletes. A potential delete is a record in OC for that DCM which is not in theincoming file.





Deletes for non-repeating question groups are identified by comparing the keys (patient,DCI, Visit, DCI Date, Subevent, and DCI Keys). Deletes for repeating questions groups areidentified by first comparing the keys and then determining if each repeat is the same. Todetermine if a repeat is the same, the OC QG Key and Dataset QG Key are used. Note thatin order to identify potential deletes for repeating question groups, the OC QG/Dataset QGKey must be identified in the Responses screen.

7.3. Delete Screen

Once a delete file as been prepared or deletes have been identified through comparison of acumulative file with existing OC data, the Delete Responses screen may be displayed withall potential deletes.

By default all potential deletes are marked for delete (Del column is checked on). If youwish to delete all records, click on the Delete button.

To perform the deletion, click on Yes. The selected records are deleted from Oracle Clinicalusing the Data Capture API. If all responses of a repeat are selected for delete then the repeatis soft deleted and OC immediately reorders remaining repeats. If all the responses in anRDCM are selected, eLoader automatically marks the RDCM as Blank. If all the responsesin an RDCI are selected, then the RDCI is soft deleted.





When errors occur during the delete stage, these are displayed on the Errors screen. Theerror message numbers are those returned by the API, and information about the errors can be found in the Oracle Clinical documentation.

In the event that generate has not been run or no datasets have been marked as Cumulative,when the Delete button is pressed, the following message is displayed:

7.4. Filtering Records in the Delete Screen

All of the records identified as potential deletes do not have to be deleted. There are severalways to filter the records.

• A query can be performed on any field.

• The set of records can be sorted by any field by clicking on the field name button

above each column.

• Filters can be used to restrict the records displayed. To set up filters, click on the

Filters button. Enter any filters that are desired and the sequence in which theyshould be used.

In the following example, both filters would be used connected by ‘OR’

If the filters need to be connected by ‘AND’, put them in the same filter.





After the filter is entered and saved, click on the Back button to execute the filter. Therecords displayed are based on the filter. Additional queries performed in the Delete screenare based only on the records retrieved by the filter(s). Filters can be deleted or temporarily

disabled by unchecking the Use it Flag. When the Data Filter is in use, a message isdisplayed in the bottom right corner of the screen – Data Filter Set.

Records displayed can have the Del Flag (which marks them for Delete) manually checkedor unchecked on a record by record basis. Use the Set All button to turn the Del Flag on for all responses. Use the Reset All button to turn the Del Flag off for all responses.

Note that records not displayed on screen may still have the del flag checked on. Be sure toset the flag off for all responses that should not be deleted, regardless of whether they aredisplayed on screen.

7.4.1. Null and Derived Responses

By default eLoader does not display null or derived responses that are available for delete.This is done to simplify the selection process for the user. When all enterable and non-nullresponses for a DCM are selected for delete, eLoader automatically deletes the null andderived responses.

If this behavior is not desired, null and/or derived responses can be displayed and their DelFlag unchecked. Uncheck the Ignore Null Responses or Ignore Derived Responses Flag(s)as required to view and adjust these responses in the Delete screen.

7.4.2. Refreshing Delete Records

Once the Delete function is invoked, the records retrieved are maintained even if the screenis exited and re-entered. This is to enable a user to work with a set of records without havingthem change automatically based on changes to data in Oracle Clinical.

However, at times you may wish to refresh the data displayed in the screen. To refresh, usethe Clear button in the Delete screen to remove all records. Exit the screen and click on theDelete button, eLoader performs a new search to find all potential records for delete based





on the current state of the data in OC. Any records added, updated, or deleted since the lastgenerate will be reflected in the Delete screen. When the Delete screen is exited, the user is prompted if they want to retain those deletes for

use at a later time. It is not a good idea to retain deletes as this prevents them fromautomatically refreshing. Data may change by the next time the screen is entered – this can

result in the wrong data being deleted or a failure of the delete process if the record it istrying to delete no longer exists in OC. When delete records are not retained, the status of

the run is changed to: “del finished”

Note on Repeats:

When individual repeats are deleted from OC, OC resequences the repeat numbers. For example, if there are 10 repeats and repeat 5 is deleted, then repeats 6-10 are renumber 5-9.eLoader will not allow higher number repeats to be deleted (without a refresh) once this hasoccurred. This ensures that eLoader has the correct repeat sequence number for each repeatin OC.





8. Statistics

The Stats tab displays statistics generated by each Conversion Run.

8.1. View Conversion Statistics

Select the Conversion Run in the Convert tab then click on the Stats tab to view theconversion statistics for the particular run. An entry will be displayed for each DCMaffected by the Conversion Run.

The screen displays information for the incoming file (File Records), for each DCM mappedto (DCM Records), and for each file generated for OC (Bdl Responses) by Dataset.

For each file we have the total number of records and the number successfully imported. For each DCM, we have the number of records successfully prepared, successfully validated,and the number of records identified as inserts and updates. For each file generated to loadinto OC, we have the number of responses that were identified as inserts, updates, or

unchanged.





9. Errors

The Errors Tab displays any errors that resulted from the Prepare, Validate, or Generatestages. Select the appropriate Conversion Run in the Convert screen and then either click on the Errors Tab or the Show Errors icon on the right side of the screen.

The Errors screen displays by Run for each DCM and Dataset any errors encountered byeLoader or enabled Validation Checks that failed.

The button/heading next to “Error Message” (…) is to aggregate messages, which willshow each message only once (on/off).





10.Copy Mappings

Once the mapping has been completed for a Dataset, those mappings can be re-used bycopying them to another Dataset. This functionality can be used to copy individual Datasetmappings within or between Conversions.

If the mappings for an entire conversion need to be reused (migrating similar studies for example), the Copy Conversion feature would apply.

10.1. Copy Dataset Metadata

Create a new Dataset. Use the Copy Dataset button to copy the source Dataset’s metadata tothis Dataset. (see section 4.1 for further details) If the files are equivalent in columnstructure, no further mapping is required and the new Dataset can be immediately used toload files into OC.

If there are differences between the source and target Dataset, then any columns that are not

valid are highlighted in red.

10.2. Copy Conversion Metadata

Once mapping has been completed for a study, the mappings for all datasets can be re-usedfor a similar study. This functionality would be applicable if the mapping had beencompleted for one study and a study similar in structure needs to be converted and loadedinto Oracle Clinical.

• Create the new Conversion.

• Select the Copy Conversion button. The following screen appears.





• Select the source conversion in the Select Source Conversion field. After selecting

the source conversion, the study and datasets are displayed in the Conversion Infoarea.

• Click on the OK button to start the copy process. All Datasets, Keys and Response

mappings from the source conversion will be copied to the target conversion.

• If errors are encountered during the copy process, error messages will appear and

invalid columns will be displayed in red. The Valid flag for the Keys or individualresponse will also be unchecked. Make any changes to the Key and ResponseMappings that are necessary.

• Dataset Files may now be imported and processed using the copied Datasetmappings.

• The Copy Info section of the Datasets tab will show the source of the copied

Datasets.

• Both the Copy Dataset and Copy Conversion functions may be used in conjunction

with each other to meet the needs of different Conversion processes.





11.TMS Load Features

eLoader contains a TMS tab though which data may be loaded directly into Oracle’s TMSsystem to be classified. The data loaded though eLoader is integrated through a TMSExternal System and does not require the setup of metadata items in Oracle Clinical.

During the loading process the verbatim terms finding a match will be automaticallycoded. Those terms not finding a match will create omissions in TMS. The user is able tomanually code terms, apply actions, approve, reclassify, etc. in the same fashion as withterms sent to TMS from OC. The eLoader TMS feature can be used when it is desirable tohave TMS code your data, without the overhead of creating the study in Oracle Clinical.

11.1. Setup in TMS System

In order to use eLoader to load Verbatim Term data into Oracle’s TMS system, certainitems must be created in TMS prior to the load. Refer to your TMS process documentationfor specific instructions for setting up the TMS objects.

•An ‘External System’ must be created in the TMS, Definition, Define ExternalSystems menu. eLoader will make use of the external system to load the verbatimterms into TMS (bypassing OC). The user may wish to create entries in theAttributes section of the screen for columns in the file which will be useful duringthe Classification process (Patient, Site, Indication, etc).

• Create one or more domains, if necessary, and assign the dictionaries used for

coding to the new domains. Existing domains may be used.

• If Global Actions are to be used with this new External System, an entry will need

to be made for each Global Action to be used by the external system. In the bottom tab of the Global Action screen, select the External System and Omission

Status for each Global Action needed.

• No setup is required in Oracle Clinical.

12.6.1 eLoader TMS Load Process

The eLoader TMS module will take data from files, read and parse the data, then send thedata to TMS using the TMS APIs. The TMS tab provides the interface for mapping thefile data to the appropriate TMS fields.

11.2.1. Create the TMS Load Conversion

A conversion entry for a TMS load is created just as a standard eLoader conversion would be created (see section 2 of this document) with one exception. Because eLoader does notrequire the setup of a study in Oracle Clinical to load to TMS, the user should select theentry ‘TMS’ in the study list of values when creating the conversion.

11.2. eLoader TMS Formats

Formats will be created in the eLoader Formats tab for identifying the file structures usedin loading data to TMS. The creation of formats is described in Formats Section of this





document. The creation of formats is no different for a TMS file than it would be for anyfile being loaded into Oracle Clinical. The file structure may be delimited or of a fixedformat, it may contain column headings, data enclosed in double quotes, etc. – the rules of format creation are the same. Create a format for each file structure to be used in loadingdata.

0.1. eLoader TMS Datasets

A Dataset should be created for each unique format structure to be used to load data in theconversion. The creation of the Dataset is the same as described in the Dataset Section of this document.

0.2. eLoader TMS Dataset Files

The process for importing dataset files for a TMS load in eLoader is similar to the processfor a standard OC load. The files are placed in an eLoader import directory. Entries areeither made manually to select the files (see section 3.3), or autoscan parameters areentered to provide for the automatic scanning and importing of files from server

directories.

The file type for an eLoader TMS Dataset file entry must be designated as ‘T’ (rather than‘C’, ‘I’, or ‘D’). This identifies to the system that the file is intended for a TMS load. If amanual import is performed, check on the Sel box and click on the Import button to importthe file using the Dataset/Format identified.

0.3. eLoader TMS Mapping

The mapping of the file data to the TMS system is performed in eLoader through the TMStab. Note that no mapping is necessary through the Keys or Responses tabs as the data willnot be loaded into Oracle Clinical. Each dataset selected for the conversion will need to

have the TMS Metadata defined. The Metadata definitions may come from the file data,the TMS system, or a formula or constant (depending upon the field). If constants areincluded in the Metadata mappings they must be enclosed in single quotes.

• The Dictionary field defines the name of the dictionary to be used with the data.

The list of values for this field shows the column names from the dataset and thedictionary names from TMS.

• The Domain field defines the name of the TMS domain to be used in the

classification of the data. The list of values for this field shows the column namesfrom the dataset and the domains defined in TMS.

• The Term field defines which dataset column contains the source term to beclassified. Only the dataset column names appear in the list of values.

• The Source Term ID is a unique identifier for the particular term. This id can

come from a column in the dataset or a function may be used to generate an id.





• The Occurrence Id in combination with the Source Term Id creates a unique

identifier for the term. A list of values is available for this field. The list of valuescontains the column names from the dataset.

• The Source Term Alt Key provides an additional field to use as a key identifier for

the term. The list of values for this field contains the column names from thedataset.

• The No Omission Flag field controls whether omissions will be created for terms

which do not classify. You may select a column from the dataset file with the listof values or directly enter the constant ‘N’ or ‘Y’. If ‘N’ is entered, omissions will be created for terms which do not automatically classify. If ‘Y’ is entered, noomission will be created for terms which do not find a match.

• The Def Integration Key field defines the name of the External system from TMS

being used to process this data. A list of values is available showing the ExternalSystems from TMS and the columns from the dataset.

• Additional External System columns will appear once the Def Integration Key has

been selected. Up to eight additional fields may be identified for the externalsystem in TMS. The defined fields will appear with their appropriate labels if theDef Integration Key was populated with a TMS External System name. If the Def Integration Key was selected from a Dataset column (perhaps because the Externalsystem varies throughout the file data) then generic labels will be displayed (ExtValue 1, Ext Value 2, etc).





11.2.6. Executing the TMS Load

Once the TMS Metadata mapping is complete for a dataset, the Load can be performed.Click on the Load button to initiate the loading process. All files for this dataset whichhave the Sel flag checked on (in the Dataset Files tab) will be loaded. Statistics about theload will be returned in the ‘Load selected Dataset’ area. The system will return a Status

and give results of how many terms were loaded, classified, and created omissions (bothin terms of total numbers and unique occurrences). If problems were encountered,review the Error Message to assist in troubleshooting. The ‘Reload All’ feature may beused to load all files contained in the selected Dataset regardless of the status of the Selflag in the Dataset Files tab.

11.2.7. eLoader TMS Reports

One standard report, TMS Load, is provided with the eLoader Reports tab. The TMSLoad report lists the Unique Verbatim Terms, the Count of those terms, their classification status, any Actions applied to Omissions (and the associated ReviewStatus), and the Classification hierarchy of coded terms.

• Select the report TMS Load from the report list.

• Select a Dataset Name from the list of values if you wish to run the report for a

particular dataset. Leave the field blank if you wish to run the report for alldatasets in the conversion.

• The Print Details field controls whether the dictionary classification hierarchy will

appear in the report. For example, the items derived for Preferred Term, SOC,ATC codes, etc. Enter Y for the hierarchy to appear. If N is entered, only thesummary information is included (verbatim terms, classification status, counts).

• Select the Report Server, Destination, and Format options as you would for any

other eLoader report and click on the ‘Run Report’ icon.

• Below is a sample of data from the TMS Load report, with the Print Details option

set to Y.





12. Administrative Module

eLoader contains an administrative module through which many settings in the applicationare managed. These settings affect how eLoader appears and performs as well as settingaccess for users. A user must have Admin privilege to access these screens.

12.1. User Creation and Privileges

The Users Tab in the Admin module is used to manage account access and privilegeswithin eLoader. Enter the Oracle Clinical account names of all users who should begranted access to eLoader. A List of Values is available to select the user account. Check the privileges that should be assigned to the account.

Note that in order to add or modify information in the users screen:

• Scheduler must be stopped

Privileges include:

• Administrator – All privileges.

• Developer – Users who will perform setup and execute jobs.





• User – Users who will execute jobs and run reports.

• Delete – Access to Delete screen for users.

An email address for the user may also be entered to send alerts to the user resulting formeLoader processing.

12.2. AutoLoad Tab

The AutoLoad Tab is used to designate active Conversions within eLoader and to enable /disable the AutoLoad feature. Both of these settings are also available in the User module.

The Active field controls whether the OC Lookup table is refreshed for that conversionduring the nightly batch job. This would be turned off by the Administrator when aConversion is no longer in use to prevent unnecessary nightly processing.

The Autoload field controls whether the Conversion will allow files to be automaticallyimported and processed by eLoader.





12.3. Directories

The Directories screen is used to identify to eLoader directories available for input andoutput files. Enter each directory path (note these directories must already exist on thedatabase server). For each directory specify whether the directory is for input, output, or scanning activities.

A check in the Input box allows files in this directory to be accessible for import intoeLoader. A check in the Output box allows the directory to be a target for the output of theresulting batch load files. A check in the Scan box allows the directory to be scanned bythe eLoader AutoLoad function. An optional description field may also be entered. TheInclude SubDir Check Box is reserved for future use.





12.4. Scanning Files

eLoader provides the ability to automatically scan (input) directories for matching file patterns and import the file into eLoader. Depending on how the process is initiated,eLoader may also process the file through the eLoader Prepare, Validate, and Generatesteps and submit the output files to Oracle Clinical’s Batch Loader.

12.4.1. AutoLoad and Scanning Setup

The conversion that will be used with the AutoLoad feature should already be set up withDatasets mapped to Keys and Responses in the User module of eLoader (see section 4).The setup in the Admin module consists of the following steps:

• Check on the AutoLoad flag for the Conversion in the AutoLoad tab (see section

12.2).

• Check on the Scan flag for the directories to be searched for new files in the

Directories tab (see section 12.3).

• Make an entry for each scanning rule in the Scan tab and enable AutoLoad settings

(see below).

• Optionally setup Alerts (see section 12.5).

12.4.2. Scanning Rules and Settings

Scanning rules allow eLoader to search directories for files - automatically assign them toDatasets within Conversions and import the files. If the Dataset mapping has alreadyoccurred, eLoader can continue to run the Prepare, Validate, and Generate options as well





as the Batch Load into OC. This allows files to be automatically loaded into OracleClinical without any user intervention.

Conversion scanning rules and AutoLoad settings are identified in the Scan tab. TheAdministrator defines a set of rules to be applied to the scanned files by eLoader todetermine which Study and DCM they should be loaded into. The scanning rules also

identify whether the file is to be processed as incremental, cumulative, or for deletes.eLoader also tries to determine the Lab and Priority that should be assigned to the file for processing but this information is not optional for the AutoLoad.

Each file pattern can have the following attributes defined:

• Directory

• Conversion

• Dataset

• File Type

• Lab

The Administrator will define the logic to be used by eLoader in assigning the file byassociating the name with particular attributes. For example, if the Conversion ABC isassociated with the directory /home/eloader/abc – then eLoader will attempt to assign allfiles in this directory to the appropriate Datasets within this Conversion (note additionalcriteria would be required to indicate the correct Dataset). If all files that have the string‘EKG’ are associated with the Dataset STD_LAB, then all files that contain this string will be loaded into this Dataset.

Scanning rules are applied in a particular order:

• Directory level applied first – no file pattern given but directory selected meaningthe rule applies to all files in the directory.

• Directory with file pattern – rule applies to all files that match the pattern in the

designated directory.

• File pattern only – rule applies to files in all directories that match the pattern.

For example you cannot have the same file pattern that matches two different Datasets:

Demg% , Dataset A and Demg%, Dataset B

However, you may have the same pattern which invokes different level criteria:

Demg%, Dataset A and Demg%, Lab X

Priority will be used to determine which files should be processed first. Priority will be adigit from 1 to 9 with 1 meaning the highest priority and 9 the lowest. Since Priority can be assigned to different patterns that apply to one input file, eLoader will use the highest priority assigned to the pattern that applies to the input file.





Below is a sample of scanning rules :

AutoLoad settings may also be identified for each Scanning Rule by selecting the ‘SetAutoLoad Settings’ icon. The setting will initially have the default settings as assignedfrom the Control tab (see section 12.10). Those may be overridden for a particular scanning rule here. Each setting is explained in depth in section 6.2 of this document.Once the appropriate settings have been selected click on OK.





12.4.3. Initiating the Scan

The AutoScan process can be initiated in two ways: from the Admin module in the BatchJobs tab or from the User module in the Dataset Files tab. If initiated from the DatasetFiles tab, the user has the option of performing a Scan or Scan and Import. The processwill not continue on to the AutoLoad. If the process is initiated from the Admin module,then it scans and automatically starts the AutoLoad process (if AutoLoad is set on for thatConversion).

From the Batch Jobs screen, the Administrator may start or schedule AutoScan/AutoLoad jobs. Note: the Batch Jobs screen is also used by the Administrator to monitor the status of all batch jobs submitted from eLoader. The screen may be refreshed by clicking theRefresh button. Jobs may be stopped by selecting the Batch Job and clicking on the StopJob button.

The Scheduler must be started for eLoader to run batch jobs. Click on the Start Scheduler button if it is not running. This only needs to be done once by the Administrator.





The Administrator clicks on the Schedule AutoLoad button to submit or schedule theAutoScan / AutoLoad process.

The job may be submitted to run immediately or at a particular time. There is also a choicewhether to repeat or not with the option of repeating at a particular interval (minutes,hours, days, weeks, or months) or at a designated day of the week and time. If a value isselected for the Conversion field the Autoscan / AutoLoad will occur just for the chosenConversion, otherwise the process runs for all Conversions.

If the AutoScan is set to submit in the future and needs to be rescheduled, click on theReschedule button.

The AutoScan/AutoLoad job performs the following tasks:

• Checks eLoader for Active Directories

• Check for conversions with enabled AutoLoad tick box

• Scans the Active Directories for new files that end with the appropriate extension(s) as

identified in the Control tab (if none exists stops).

• Use the Rules defined for directories and file names to map the files to Conversions

and Datasets (if none can be mapped stops).

• Begins the AutoLoad process.

The Directory Scan process will scan each directory identified in eLoader as scannable tolook for new input files. Directory Scan will look at each directory and the files alreadyentered in them to determine which files have been added to the directory and which files





have been removed from the directory since the last scan. eLoader checks both thefilename and the date/timestamp to determine if a file is new.

The status will be set to ‘Assigned’ for files in the directory and not yet processed byeLoader. After the file is imported by eLoader its status will be set to ‘Imported’. If anyerrors are encountered during the import process then the Error Flag will be checked on.

The directory scanning process will also verify that all files previously identified byeLoader are still in the specified directory. If the file was removed then theREMOVED_FLAG will be set to ‘Y’ (in the Dataset Files screen the ‘R’ flag will bechecked). eLoader will set this flag and move the file record to the archive log.

12.4.4. AutoLoad Process

The AutoLoad Process consists of the following steps:

• Import the Files

•

Convert the Files• Process Delete Files

• Run the OC Batch Data Load process (Out of Study Load).

12.4.4.1. Import the Files

Once the directories have been scanned and the attributes of the file determined, eLoader will assign the file to a Conversion and Dataset and begin the Import process. All Inputfiles will be sorted by Study, date (from the file’s timestamp) and type (Incremental,Cumulative, Delete). The files will be processed in the order of the sort unless a Priorityhas been assigned. In this case the lower priority number will process first.

12.4.4.2. Convert Files

Once the files are imported they are automatically submitted by eLoader to the ConvertProcess. The Convert Process uses the mapping predefined for the Dataset to run thePrepare, Validate, and Generate steps.

The BDL File Options typically set manually (see section 6.2) will be set by default fromthe Control tab (see section 12.10) and can be set per Scanning rule from the Scan tab (seesection 12.4.2). The AutoLoad job will execute the batch job using these parameters.

Multiple files may be submitted to the same Conversion. Those with a higher priority will

process first. Those with the same or no priority will process concurrently if they referencedifferent DCMs. If multiple files reference the same DCMs, one must finish the OC BatchLoad before the next file submits for processing.

12.4.4.3. Process Delete Files

Those files identified as Delete files (Type ‘D’) will be scanned and imported into theDataset as are other input files. During the Prepare Stage, the delete records will be movedto the internal Delete table. The delete candidate records will be displayed to the user on





the Delete screen (invoked from the user Convert tab). The user can review the recordsand initiate the actual Delete function from this screen (see section 7 for details). Theseresult in OC updates, key changes or ‘Soft Deletes’ which are maintained in the OracleClinical Audit Trail.

12.5. Implementing Alerts

Alerts may be enabled so that messages are logged and optionally sent to users when processes complete (failures or successes). Alert messages are sent from the eLoader email account (set up in the Controls tab) to users designated in the Alerts tab.

The upper portion of the screen displays the possible alerts. Alerts have an ID number, aname, the alert text, and a Type (Scan, Load, or Admin).

The Administrator sets up the Alert Distribution in the lower half of the screen. A User Name is selected from the list of values. The Alert Type, Alert ID and Conversion fieldsare optional. If no additional criteria is selected the referenced user would have an alertlogged and optionally be sent a message for every Alert generated by the system. TheAlert Type if entered, corresponds to the Type field in the upper portion of the screen. For example, if an Alert Type of Admin is entered then the Alert Distribution rule created willonly be applicable for Admin Type Alerts. Enter an Alert ID if the message should apply

to a particular Alert. Enter a Conversion from the list of values if the Alert Distributionrule should be limited to a specific conversion.

Alert messages sent by eLoader may be viewed from the Alert Log tab.





12.6. Validate Checks

Validate Checks may be executed to identify any potential errors in the data prior toloading into Oracle Clinical. Individual Validation checks may be enabled or disabled. Inaddition, they may be set to Stop the processing of the file or Reject just the discrepantrecords. The default value for each Validation Check is set in the Admin, Validate tab.These settings can be manually modified per conversion in the Convert screen.There are 23 pre-defined checks, and additional custom checks can be added.





A check is enabled or disabled globally by checking or unchecking the Enabled flag. Thecheck will stop the processing for a file if the Type field is set to ‘Stop’. If the Type fieldis set to ‘Reject’ only the discrepant records will be rejected. Note: users may override theglobal setting for their Conversion in the Convert tab (see section 6.3.3).

Specified users will be notified by e-mail and the error will be logged in the system. Theuser or administrator will be responsible for investigating the records in the error file(s)and resubmitting the file(s) for processing. Each record in the error file will contain theoriginal data followed by a separator (‘##’) and an error message. The Import process willskip any text followed by the separator (‘##’) so that the file that contains the error messages can be processed by the Import without removing the error messages.

12.6.1 Defining Custom Checks

In addition to the pre-defined validation checks, custom checks can be added. The scopefor each of these checks can be either once per Run, or once per Batch_data_load record.

The administrator should indicate the type, name and the name of the PL/SQL procedure inthe validation checks screen. The actual validation procedure should be included in the package eloader.eloader_user_exits. Depending on the type of validation check (Run or Record), certain parameters will be passed to the procedure. The check will fail when theerror message variable is not null at the end of the procedure.

Sample custom validation checks are included in the file eloader_user_exits_example.sql.You can modify this file and execute it with the eloader account.

12.7. File Log

The File Log displays all Dataset files ever entered in eLoader. By default this screenshows files from all Conversions. The administrator can query on particular records if desired. The screen shows identifying information about the file (Conversion, Dataset,Directory, File Name, #, Type) and status information (Status, Status Timestamp, whether errors are present and if the file has been removed).

The administrator can perform the similar tasks from this screen as the user can from theDataset Files tab (see section 3.3), including:

Show Errors for selected file.

Show Status History for selected file.

View the current file.

Remove imported data for current file.





Scan.

The screen may be sorted by any of the column headings simply by clicking on the desiredcolumn heading.

12.8. Run Log

The Run Log allows the administrator to view status of all eLoader Conversion Runs. This

screen is similar to the Convert screen in the User module. By default, the screen displaysdata for all Conversions, however, you may query on any of the fields in the left side of thescreen (Conversion Runs section). Locked DCMs may also be displayed from this screen.

A new function bdl cleanup is available using the bottom far right icon. This prompts for the age of records (> x number of days) to be removed from the batch_data_load table.This can be used by the Administrator to clean up the table. Note that if the table hasnumerous records (millions) this process can be very slow. This process also does not takethe permanent place of rebuilding the batch_data_load table (see Install/UpgradeInstructions)





12.9. Reports

The Reports form in the Admin module can be used to execute User and AdministrationReports as well as register new reports. This tab is similar to the Reports tab in the User form. The Report Execution section in the Admin form has additional Conversion andStudy parameters. Admin Reports can be executed for any Conversion or Study. Reportsin the User form can only be executed for the selected Conversion.

The Report Setup section is available only in the Admin form. This allows the addition of

custom reports to eLoader. The administrator enters the Name of the Report and the Filewhich contains the report code. Select a report Type of User or Admin (User reports will be available from the User module while Admin reports will be available only from theAdmin module). Click on the flag for Conv (Conversion), Study, and Dataset to enableLOV for those fields when the parameters are selected for report execution. Up to threeadditional Parameters (specific to the report) may be identified to pass to the report.





12.10. Control Settings

The Control tab is used to set Installation and Control settings for the eLoader instance.Each setting is displayed below and identified as optional or mandatory.

12.10.1. Parameter settings





• Rollback Segment (O) – Stores the rollback segment used for eLoader processing.

Set during installation to the same rollback segment specified for OC batch loader it can be modified to any rollback segment.

• eLoader Client Path (R) - Stores the path to the eLoader client in the Web Version.

• OC File Name (O) – Is used to customize the naming convention for the OC OOS

File Record name. It defaults to conversion name and a sequence number.

The following variables can be used in any combination:

&conversion&study&dcm&datasetfile&dataset

• Reports Directory (R) – Stores the name of the directory on the Report Server in

which users’ eLoader reports are stored.

• Reports URL (R) – Stores the URL for report file viewing. This is the url that has

been mapped in the httpd.conf file to the physical Reports Directory.

• Xml DTD Directory (O) – Use to identify a non-standard directory for set-up of

xml file loading.

• File View Protocol (R)– Choose the default File view protocol of FTP, HTTP, or

File.

• SMTP Server Port (O) – Enter if a non-standard port is used, otherwise the defaultwill be used. This is for setting up sending e-mails from eLoader to users.

• SMTP Server (O) – internal SMTP email server. This field is required if email

alerts are used.

• eLoader email Account (O) – Account used to send email Alerts to eLoader users.

This field is required if e-mail alerts are used.

• eLoader email Password (O) – Password to eLoader email account. This field is

required if e-mail alerts are used.

12.10.2. Options Settings

• DC Triggers Option - Enables triggers in Oracle Clinical which are used to

maintain status of OC_LOOKUP table. When enabled the triggers are used toidentify when a change is made in OC. This change is recorded by Study/DCM inthe OC_LOOKUP_STATUS table. If these triggers are implemented then theOC_LOOKUP table is only refreshed for DCMs that become invalid in theOC_LOOKUP table (reduces eLoader processing). Otherwise the whole Lookup





table needs to be reloaded regularly. The triggers are defined in thecr_dc_triggers.sql script. Enabled by default.

• OC Lookup Option - Determines if OC_LOOKUP table will be used or not. If this

table is not used then all look ups are done by going directly to Oracle Clinical(which results in slower processing). Set to enabled by default.

• QG Key Option - Controls whether OC QG Key and Dataset QG Key are available

in the Responses screen. These are used to extend key for repeating questions todifferentiate between inserts, updates, and deletes. Set to enabled by default.

• DCI Keys Option – Controls whether DCI, Dataset DCI Key and OC DCI Key are

available in the Keys screen. These are used to extend the DCI key, to differentiate between inserts, updates and deletes. Set to enabled by default.

• Cumulative Delete Option - Controls whether delete processing is available

through eLoader using cumulative files. Cumulative Flag, Delete Flag, and Delete

button are all disabled when disabled. Enabled by default.

• File Delete Option – Controls whether a file can be submitted to identify potential

deletes. Enabled by default.

• AutoLoad Option – Controls whether AutoLoad is available through eLoader.

Enabled by default.

• Load into OC option – Controls whether processing can continue to automatically

run OC Batch Jobs. Enabled by default. If disabled then eLoader will generate thefiles but will not start the OC BD Load job.

• TMS Option – Controls whether the TMS load is available.

12.10.3. Additional Parameters:

• Import Stop – When enabled, this setting will cause the import process to stop if

any error is received. Otherwise only the record with an error is rejected and sentto the reject file while processing continues.

• Prepare Stop – When enabled, this setting will cause the prepare process to stop if

any error is received. Otherwise only the record with an error is rejected and sentto the reject file while processing continues.

• Import Ignore too many – When enabled, this setting will allow a file with too

many columns to be imported.

• Import Ignore too few – When enabled, this setting will allow a file with too few

columns to be imported.





• Max Processes – the maximum number of batch job processes eLoader will allow

at the same time. If empty, the number is determined by the databaseconfiguration settings.

• Scan File Extension - Record the file extensions which should be scanned by

eLoader in the AutoScan process. All files extensions (.txt, .out, .del, etc.) must belisted here.

• BDL File Options - Set the options for the Convert process. These settings can be

overridden at the Scan Rule level (see section 12.4.2) and at the Conversion level.Section 6.2 in this document provides a description of each of these fields.

12.10. New Users

Individuals use their Oracle Clinical account to log into eLoader. Oracle Clinical studysecurity is automatically maintained in eLoader. To provide an existing Oracle Clinicaluser with access to eLoader, designate the privileges for each account through the Usersform in the Admin module (section 12.1).

The following steps are identified in the set-up document but are re-iterated here for convenience.

12.11. eLoader Batch Process

eLoader uses its own batch queue for batch jobs. Enable Oracle’s DBMS_JOB package bysetting job_queue_process and job_queue_interval parameters in the INIT.ORA file

Example:Job_queue_process = 2Job_queue_interval = 30

Restart the database after updating the INIT.ORA file as described in this and the previous step.

12.12. Format for Loading into Oracle Clinical

eLoader uses a format called ELOADER_FORMAT when submitting batch jobs toOracle Clinical. Create a format in Oracle Clinical named ELOADER_FORMAT with allfields and a pipe delimiter. This step should have been completed during the installation(manually).

12.13. Change Reason Audit Trail when using eLoader Delete function

When the Delete function is used in eLoader, the Audit Trail is updated with the standardreason – ELOADER. This reason must be added to the OC Installation Codelist – DATACHANGE REASON TYPE CODE. This step should have been completed during theinstallation (manually).





13.Quick Start Guide

Once eLoader has been installed, you can follow these steps to set up a test conversion andlearn how eLoader’s basic features work.

• Verify Installation Set-up

Verify that all the steps in the Installation Set-up Instructions have been completed.This includes the settings in the Control screen of the Admin module.

• Set up Users

Log in to eLoader using the ELOADER account. Navigate to the Users screen.Enter any ops$ accounts that you want to have access to eLoader and grant themthe appropriate privileges. Note that the scheduler must be stopped (if it is running)to modify user information.

• Start Scheduler

Log in with an eLoader Administrator account. Navigate to the Batch Jobs screenand start the Scheduler (click on start Scheduler). It will go to a status of Startedafter about 15 seconds.

• Verify Validate Check Settings

In the Validate Settings screen (Admin module), verify or modify the Validationcheck Settings. All checks are enabled and set to stop file processing by default.

• Set up Directories

All directories from which files will be loaded to eLoader/OC or in which theoutput files that will go to OC are stored must be identified to eLoader. Enter thefull path (these are directories that already exist on the database server). For eachdirectory check whether you want to make it available for input or output and if for input whether eLoader scanning is enabled. A directory can be marked for multiple purposes.

• Set up Alerts

Alerts are logged when particular events occur in eLoader (e.g. - import failure,OC Load, etc.). Alerts can also be automatically e-mailed to the user if an e-mailaddress is identified in the Users screen. You may set up alerts now or at any time.

• Create a Conversion

Navigate to the Log in screen and select the conversion button (do not enter anything). Create a new conversion by entering a conversion name and selecting astudy (only studies this ops$ account has access to will appear in the list of values).





• Create Formats

Formats are created for each unique file structure that you will be using (not for each file). For example, if you have a weekly set of files from Lab ABC they may be in a particular format – so you would create one format in eLoader that would

be used to read all of the files in this structure (from Lab ABC or others and for any protocol). Create any required formats – for this test create one for a samplefile which you want to load. See Section 3.4 on creating formats for fullinstructions.

• Create Dataset

Datasets can be created in two ways – directly in the Datasets screen or whenassigning a file to load.

Navigate to the Datasets screen. Verify that the Use button in the top right corner is set to Data Files. Enter a dataset name and tab. Enter the format name (select

from the List of Values) and save.

• Load files

Navigate to the Dataset Files screen. Select the Dataset Name from the LOV.Click on the directory icon – select the directory and then the file you wish toload. Enter a type of ‘C’ for cumulative. Save.

Check the Select box on and click the Import Selected Files icon. Click on batch jobs and the job should run successfully. Return to this screen and verify thestatus of the file is imported.

Note that this entire process can be automated.

• Map Keys and Responses

Mapping can occur after the dataset has been created (but prior to the load of anyfiles). Mapping consists of mapping the keys and responses from the incoming fileto the appropriate items in OC. These tasks are described in detail in this manual.There is also a sample of a mapping in section 13.1.

• Convert and Load files

Verify that the Select box is still checked in the Dataset Files screen. Navigate tothe Convert screen. The system automatically creates the first Run whichidentifies the file and the DCM(s) to which it has been mapped.

Verify the Convert Options settings. Typically you would want the followingsettings on: Execute in Batch, Ignore responses for Unchanged Records, KeepBDL records for Delete, and Load generated data into OC. Of course – changethem as appropriate for your needs. Also enter or verify the Destination Path for the generated files.





You may also change the Validate Check settings – these were set by default inthe Admin module.

Select the P+V+G button. Respond OK to both prompts. Click on the batch jobs button to review the status of the job. The eLoader Prepare, Validate, and

Generate jobs will execute followed by the OC Batch Load.

If all are successful, then you can open OC to review the loaded data. From theConvert screen in eLoader, select the show Generated OS Files button from whichyou can open the file generated by eLoader.

If there are any failures, the error box for the run will be checked. Select theErrors screen to review the errors. A reject and text file are created in the directoryin which the original file was loaded. Review the errors, make any corrections andreload the files. The reject file can be loaded as is (eLoader will ignore themessage after the ## marks in the file).

You can review the statistics for the loaded file from the Stats screen. Thisdisplays for each dataset – records by file, by DCM, and by OC generated file.

• Deleting Data

There are two ways to delete data: (1) By loading a file with potential deletes; or (2) By loading a cumulative file with fewer records than are in OC.

• To test deletes by loading a delete file:

Make a copy of the server file that was loaded and remove all except one record.Import this file in the same manner as described above with the one exception that

the Type should be set to D instead of C. Check this file on in the Dataset Filesscreen (make sure the original file is checked off).

Navigate to Convert and select Create Run. Click on P+V+G and verify that the batch job is successful. The status of the job should be Del Ready. Click on theDelete button on the Convert screen. The records in the file should be displayed.Click on the Delete button and respond ok to the prompts. These records aredeleted from OC.

• To test deletes by loading a cumulative file:

Make a copy of the server file that was loaded and remove all except one record

(not the one that was deleted). Import this file in the same manner as described asthe original cumulative file. Check this file on in the Dataset Files screen (makesure the other files are checked off).

Navigate to Convert and select Create Run. Click on P+V+G and verify that the batch job is successful. The status of the job should be generated/0 (this is becausethere are no records in the file that are not in OC). Click on the Delete button onthe Convert screen. The records in OC that are not in the file should be displayed.





Click on the Delete button and respond ok to the prompts. These records aredeleted from OC.

• Running an automated load

Navigate to the Admin, Scan screen. Set up a scan rule to find the file and load it.

The following example is used to load cumulative files that contain the nameGENLAB in the directory /home/eloader/input files to the Dataset A1 in theConversion PDEMO1.

Make a copy of the first file that was loaded. Change the name so that it includesthe text string GENLAB in it. Change the data in the file or delete the original datathat was loaded.





Once the scanning rules have been created, files can be scanned or autoloaded. Navigate to the AutoLoad screen and check on the AutoLoad flag for your conversion.

Navigate to the Batch Jobs screen. Select the Schedule AutoLoad button. Click on

Submit. eLoader does the following:

• Scans all directories flagged as Scan in the Directories screen for files that

have extensions listed in the Control screen. Each of these files is loggedin eLoader.

• For each logged file, eLoader attempts to apply the Scanning rules. Each

files that can be unambiguously assigned to a Dataset in a Conversionwith a Type is set to a status of Assigned. Files than cannot be assigned based on the criteria (either no criteria apply or there is a conflict betweencriteria) is given a status of Entered. All files can be viewed in the FileLog in the Administrator module and in the Dataset files screen in the

Conversion module.

• Each file that has been Assigned is automatically imported. Since eLoader

knows the dataset that the file is assigned to and each dataset has a formatassigned, eLoader uses this format to load the file. If the import succeedsthe file is given a status of Imported. If the import files, the errors aredisplayed from the dataset files and File Log screen.





• Files that have been imported are automatically submitted for Prepare,

Validate, Generate, and Load to OC. Failures result in reject files or stopped processes depending upon the Control settings.

• From this point on simply move new files into the appropriate directory

and let the automated process run. You can submit the batch process toautomatically run at scheduled times.





14.Examples

14.1. Sample Mapping – One file to 2 DCMs - Keys, DCI Keys, Responses, QG Keys

The following demonstrates the techniques for loading a file into two DCMs. The file

contains records with Lab and Demographic data. Within the Lab DCM there is a repeatingand non-repeating question group. The techniques identified here can be used for a largenumber of scenarios.

• Mapping Keys

Two sets of keys are mapped for this dataset file. The first mapping handles the data for theinformation which will be mapped to the DEMG DCI (note the condition and use of thevariable &dci). We have mapped the variable pt_no directly to patient in OC; the visit has been converted from 1, 2, etc to DAY 1, DAY 2, etc. The subevent is derived by eLoader by a standard sorting of the keys and DCI Date.





The second mapping handles the data for the information which will be mapped to theLABD DCI. The patient, visit and DCI Date are mapped in the same way. The subeventrequires additional criteria to calculate the subevent. The file has records that haveduplicate Keys including DCI Date but different Accession Numbers. By putting theincoming Accession Number in the Subevent field, eLoader calculates subevent by sorting by the Keys plus Accession Number.

The condition identifies that these Keys will only be used for the LABD DCI.

The extended DCI Keys (at the bottom of the screen) are used by eLoader when trying tofind a matching record in OC. In the incoming data file there are lab records with the samekeys (patient, DCI, Visit, and DCI Date). Subevent is calculated by eLoader using theAccession Number as the last part of the sort.

When another file is loaded (with potential updates) eLoader tries to identify the subevent based on the existing data in OC. In order to determine which subevent to use, eLoader must look at patient data in addition to the keys. The Dataset DCI Key identifies the patientdata to check. In the following example, the Accession Number is checked (in addition to

the Keys) to determine if the record matches the data in OC.

• Mapping Responses

After the Keys are mapped the responses can be mapped.

In this example, we have variables mapped to two different DCMs - DEMG andLABDATA. In the LABDATA DCM, there are two question groups (LR for repeatingquestions and LNR for non-repeating questions).





The example below displays the mapping of the variable GENDER to the Question SEX.We perform the mapping by selecting the variable on the left and displaying the list of questions by clicking on the icon next to the Question field.

This question is non-repeating and eLoader automatically checks the Skip Repeats? Flagon. In the incoming file there are 6 records for patient 3001 and the patient’s sex isincluded in each record, but the key mapping combined with the skip repeats settinginstructs eLoader to load the Demographic data only once for each patient. In addition

eLoader has been instructed to decode the incoming values for this variable (M will beconverted to MALE and F to FEMALE) to avoid creating undesired DVG discrepancies inOC.

The example below displays the mapping of a variable (TEST) to a repeating question(LTEST).





In this case, eLoader has automatically checked the Derive Repeats flag on. ELoader willcalculate the repeat number by sorting the records within the Keys.

We also want eLoader to be able to update repeating records. To accomplish the eLoader requires more than the Keys – it needs to know which incoming record matches eachexisting repeat. The Dataset QG Key and OC QG Key provide eLoader with additionalinformation to match incoming records with existing repeats. In the example above, theTest Name is used as the unique identifier (we can do this because we know that within avisit/subevent there will never be duplicate lab tests). For Adverse Events, the unique QG

Key might be a combination of AE Name||AE Start Date||AE Severity (note that anycombination of fields can be concatenated).

Once the Dataset QG/ OC QG Key is added to one of the repeats, eLoader automaticallyadds it to all repeats in that QG as displayed below.





There are also variables that are mapped to the LABDATA DCM but the non-repeatingQG (LNR).

Looking at the incoming data file (below), based on the mappings eLoader will perform thefollowing tasks for the 6 records for patient 3001.

• Load all 6 lab tests – 3 of the lab tests will be loaded in subevent 0 corresponding to

Accession # 1 and 3 will be loaded into Subevent 1 corresponding to Accession #2.





• Load the non-repeating lab data (date taken, time taken, and accession #) twice – once

for each subevent.

• Load the demographic data (initials, gender, birthdate) only once into a separate

Demographics DCM.

14.2. Converting a File that is Already in the OC Batch Data Load Format

eLoader can be used to load files that are already in the OC batch data load format, butneed to be modified.

First import the data file into an eLoader Dataset.

Next define the Keys as follows:





Next define the Responses:

Only the response mappings for the VALUE_TEXT column have to be defined.VALUE_TEXT holds a response for each OC Question stored in the QUESTION_NAMEcolumn.

The response formula must be defined for every question stored in theQUESTION_NAME column. Map the VALUE_TEXT column to each selected OCQuestion where column QUESTION_NAME has that OC Question as a value. This is

achieved by having one mapping record for each OC Question and entering a condition torestrict loading only to records that belong to a selected OC Question.

Below a mapping is defined for OC Question UNITS. The condition of that mapping isquestion_name=’UNITS’. This assures that the value of VALUE_TEXT will only beloaded to the OC Question UNITS if the value of COLUMN_NAME is ‘UNITS’.





To define multiple mappings click on the Down Arrow button and then on the ‘D’ button.This would copy the previous mapping. Now change the OC Question and the condition.

If there are 10 questions in the input batch data load file then 10 mapping rules for VALUE_TEXT must be defined. In the case where OC Questions in the file belong tomore than one DCM or DCI then DCI_NAME and DCM_NAME must be included in thecondition.





14.3. Mapping Multiple Dataset Columns to the Same OC Question

Any number of Dataset columns can be entered in the formula field. In the example belowClinical Planned Event must be determined based on three Dataset columns Month, Week,and Day. The following mapping rules apply

Month Week Day CPE

1 2 3 M1W2D3

5 23 M5W23

4 7 W4D7

The formula must deal with “partial” visits with any of the M, W or D parts missing.

The following SQL statement performs the required conversion:

DECODE(NVL(month,'?'),'?',’’,’M’||month) || DECODE(NVL(week,’?’),’?’,’’,’W’||week)|| DECODE(NVL(day,’?’),’?’,’’,’D’||day)

In cases in which a complicated formula is used, it might be beneficial to define a storedfunction to perform the formula and call this function in eLoader’s Conversion Formulafield.

Please note that the Mapping Info form displays only one value for each Original Value.In the case of complicated formulas like this one, when the Converted Value is derivedfrom more than one column, only one Converted Value is shown for each Original Value.

14.4. Generating a Batch Load File from OC Views

eLoader can be used to generate batch load files to be loaded into Oracle Clinical from theOC Data Extract Views.

Create a new conversion.





Select the owner of the Data Extract Views for the study as the Dataset owner.

Select the Views from the study that are to be converted into batch load files.

Map the Keys to the appropriate columns from the incoming View.

Map the responses columns to the actual questions in OC.

Generate/Load the batch load files.





15.Icon Descriptions

General

List of Values Provides a list of values for that particular field.

Search for File or Directory Takes user to explorer window to find data file or displayslist of directories.

Datasets Tab

Create Dataset Tables Creates table for selected Dataset.

Drop Selected Dataset Table Drops table for selected Dataset.

Copy Dataset Metadata To copy existing conversion rules for Keys and Responsesfrom another Dataset.

Dataset Files Tab

Scan and Import Automatically scan selected directories for new files andimport any matching files.

Scan Automatically scan selected directories for new files andassign to appropriate dataset (does not import).

Import Selected Files Import data from selected files.

View Current File Displays the selected Dataset file.

Show Errors for current File Displays errors generated during the import of the selectedfile.

Remove imported data for

current File

Removed data from dataset tables for the selected file.

Batch Jobs Displays batch job status screen.

File Details Displays attributes and status of selected files.

Responses Tab

Auto Map Displays the window to enter DCMs to use in attemptingto automap incoming data items to questions

Convert Tab

Convert Options Set various options for executing the conversion.

Validation Checks Enable/Disable Validate checks and set options

Remove Temp Records Removes temporary records from the batch_data_loadtable that are stored during the Prepare step.

Refresh OC Lookup Refreshes the OC Look-up table in eLoader with the latestdata from Oracle Clinical.

Batch Jobs Displays the batch jobs screen.





Refresh Toggles the batch job refresh.

Show Generated OS Files Use this button to view the output files generated for theOC Batch Data Load process.

Show Run Progress Use this button to view the progress of a run and timingsfor each stage

Show Errors Displays the Errors tab to view Prepare and Validateerrors.

Show Locked DCMs Displays DCMs locked by a Conversion Run.

Reports

Run Report Submits a report for the specified parameters.

e Loader 31 User Manual

Documents