3 Implementing the Adverse Event: InForm and Argus Safety Integration

This chapter discusses the steps you must complete to integrate data in Oracle Health Sciences InForm and Oracle Argus Safety Integration. It covers:

• Section 3.1, "Prerequisites for Implementing the Integration for a Trial"

• Section 3.2, "Data Requirements"

• Section 3.3, "Study Design for Oracle Health Sciences InForm and Oracle Argus Safety Integration"

• Section 3.4, "Setting up Participating Applications"

• Section 3.5, "Configuration Properties for the Adverse Event: InForm and Argus Safety Integration"

• Section 3.6, "Updating Server Information for Oracle Health Sciences InForm and Oracle Argus Safety"

• Section 3.7, "Identifying Cross-references"

• Section 3.8, "Working with Domain Value Maps"

• Section 3.9, "Using the Message Resubmission Utility"

• Section 3.10, "Updating DVMs Used for Configurations"

• Section 3.11, "Extending the Integration"

• Section 3.12, "Finding Oracle Enterprise Manager Instances Using Composite Sensors"

• Section 3.13, "Error Handling"

3.1 Prerequisites for Implementing the Integration for a Trial

• Review the forms in your study design to see if any additional hidden fields are required to collect the data you want to send to Oracle Health Sciences InForm.

  For example, sometimes lab forms do not collect the lab test name in an item but instead have it as a label or prompt on the form. For more information, see Section 3.3.2.4.

• Decide if you want Argus case number, status, and reason to go back to Oracle Health Sciences InForm. If yes, add fields to the AE or SAE form. For more information, see Section 3.3.2.2.

• Determine which data you want to send to safety system and map the items in the Safety Logical Schema. For more information, see Section 3.3.4.1.

• Determine which items you want to trigger follow-up when they are changed. Map these items in the Significant data series of the Safety Logical Schema. For more information, see Section 3.3.2.1.

• Map the required fields in the Configuration Data Series of the Safety Logical Schema. For more information, see Section 3.3.4.1.

• Add the trial to the HS_TRIAL_SAFETY_CONFIG DVM. For more information, see Section 3.10.

• For the items that are being sent to safety, many will have codelists configured in Central Designer. The value defined as the code will be sent by Oracle Health Sciences InForm Publisher in the message. These codelist values need to be mapped to the equivalent Argus codelist values using the Domain Value maps included in this integration. You must review and update the DVMs to ensure the values for your trial are mapped. For more information, see Section 3.8.

• If you have enabled any user-defined text fields in Argus and the data is collected in Oracle Health Sciences InForm, follow the steps in Section 3.11 to enable this additional data to come over.

• Review and set the configuration settings for the integration appropriately for your business process. For setting up the configuration properties, see Section 3.5.

• If you are using the Acknowledgement flow, register your trial with Oracle Health Sciences InForm Adapter. For more information, see InForm Adapter 1.3.6 Interfaces Guide.

• Decide on the time frames that you want to determine whether AEs, ConMeds or Labs are possibly related to the case. Configure these values in Oracle Health Sciences InForm Publisher for this trial.

• When you are ready to start using the Integration, start the Oracle Health Sciences InForm Publisher subscriber for the trial. For more information, see Oracle® Health Sciences InForm Publisher On Demand 1.0.2.0 Installation Guide.

3.2 Data Requirements

This section discusses the data requirements. Data requirements indicate the mandatory data that must be provided to make the integration flows successful.

In order for an E2B file to be accepted into Argus as a new case, the following data must be sent:

• Adverse Event description - This is the verbatim text entered by the site to describe the adverse event triggering the case. If this is not entered by site user, the integration will send ”Event Description not Filled in by InForm User”.

• Report type - This will always be sent as ”Report from Study”.

• Patient information - The Subject number from InForm will be sent as the Patient ID.

• Reporter - The full name of the user that marked the adverse event as serious will be sent as the Reporter. The Site Mnemonic and Name will be sent as the reporter organization (displays in Institution field in Argus) and the site address will be the reporter address.

• One Suspect Product must be sent - This can be collected on a form and mapped to MedicinalProductName or MedicalDeviceName in Logical Schema. If not filled in or mapped, the value stored in the InForm database as SponsorStudyDrug will be sent. If this is not populated and items were mapped to the SuspectDrug Data Series of the Safety Logical Schema, the string ”StudyDrug” will be sent. If items were mapped to the MedicalDevice data series of the Safety Logical schema, ”StudyDevice” will be sent.

• Either Country of Incidence or Reporter (also known as Primary Source Country) must be sent - Country of Incidence can be mapped in the SafetyCase data series of the Logical schema and be sent to safety. Primary Source Country comes from the country specified in the Site address in Oracle Health Sciences InForm. You must either enter country of incidence or enter the country of the site in Oracle Health Sciences InForm. If neither of these is available when the message is sent, Argus will reject the E2B file.

3.3 Study Design for Oracle Health Sciences InForm and Oracle Argus Safety Integration

This section describes the study design requirements for integrating the Oracle Health Sciences InForm and Oracle Argus Safety applications and describes the objects you need to create in the Central Designer application to support the integration. This section contains the following topics:

• Section 3.3.1, "Overview of Designing for Integration"

• Section 3.3.2, "Designing Items on Forms"

• Section 3.3.3, "Designing Rules"

• Section 3.3.4, "Designing Logical Schemas/Data Mappings"

• Section 3.3.5, "Sample Studies and Logical Schema/Data Mapping"

• Section 3.3.6, "Data Set Definitions-System Data Sets"

• Section 3.3.7, "Data Set and Data Series Definitions-Message Body Data Sets"

3.3.1 Overview of Designing for Integration

To design a study for Oracle Health Sciences InForm and Oracle Argus Safety integration, you use the Central Designer application to add the forms, items, rules, and logical schemas/data mappings that trigger and direct the transmission of safety event data from the Oracle Health Sciences InForm application to the Oracle Argus Safety application.

For successful integration, the study requires:

• Specific items that:

  • Trigger the rules that initiate transmission of safety event data

  • Convey additional information needed by the integration

  • Store data returned to the Oracle Health Sciences InForm application from the Oracle Argus Safety application

• Rules that send safety events to the Oracle Health Sciences InForm Publisher application, which transmits the safety event data to the Oracle Argus Safety application.

• Mappings that specify how safety event data items on InForm forms correspond to safety event entities in the Oracle Argus Safety application. The mappings are defined using the logical schema or data mapping feature of the Central Designer application.

The integration supports the following design models:

• Adverse Events (AE) and Serious Events (SE) data is collected in a single, combined AE/SE form.

• AE and SE data is collected in separate, standalone forms.

  There can be multiple versions of the these forms. For example, one for typical AE/SAEs and a different one for pregnancies, if they are reportable events.

The integration package includes:

• A complete sample study for each model, packaged as a CSML file that you can import into your Central Designer instance and use as a reference or as a basis for study design. The sample studies include forms, items, rules, and fully mapped logical schemas/data mappings.

• A library containing a logical schema/data mapping in which all data sets and data series required for integration are present. To configure the mappings for a study, you copy the logical schema/data mapping into the study and use the logical schema/data mapping user interface to specify the mappings.

• A DLL file for the custom _SavetoDB function, which is called in rules that determine whether to send data to the InForm Publisher queue. Before creating integration rules for a study, you must import the DLL into the study.

3.3.2 Designing Items on Forms

Certain items on forms are required for enabling transmission of safety data from an Oracle Health Sciences InForm study to the Oracle Argus Safety application. This section contains the following topics:

• Section 3.3.2.1, "Items that Trigger Rules"

• Section 3.3.2.2, "Items for Information Returned from the Oracle Argus Safety Application"

• Section 3.3.2.3, "Items Not Entered in the InForm User Interface"

• Section 3.3.2.4, "Hidden Items"

• Section 3.3.2.5, "Fixed Items in a Repeating Data Itemset"

• Section 3.3.2.6, "AE Start Date Item"

• Section 3.3.2.7, "Death Date and Patient Autopsy Completed Code Items"

• Section 3.3.2.8, "Sequence Number Item"

3.3.2.1 Items that Trigger Rules

The Oracle Health Sciences InForm and Oracle Argus Safety integration uses rules to initiate the transmission of safety event data. These rules fire when the forms on which they are designed are submitted. The value of specific items on the combined AE/SE form or the standalone AE and SE forms determines the outcome of the rule.

According to your requirements for safety event data transmission, the AE and SE forms must include one or more of the following items, which must evaluate to Yes or No (True or False). You can create the items with Yes and No codelists, or you can create a single item with check boxes for each of the controls:

• An item indicating that safety event data is ready to send (the ready-to-send item)

• An item indicating that an adverse event is serious (the serious item)

• An item indicating that an adverse event that is not serious should still be reported to the Oracle Argus Safety application (the reportable item)

You can create these items with the Yes No Item type, which has a built-in codelist with Yes and No codelist items.

Your requirements to transmit safety event data immediately or at a configured interval determine the logic of the data-entry rules on the AE and SE forms and determine the items that are required on each form.

For more information, see Section 3.3.3.3.

3.3.2.2 Items for Information Returned from the Oracle Argus Safety Application

If your installation is integrated with the InForm Adapter Safety interface, the Oracle Argus Safety application can send data back to the Oracle Health Sciences InForm application after receiving a transmission of safety event data. This data is stored in the following fields. If you want this information to appear in the Oracle Health Sciences InForm study, you must include these fields in your form design:

• SE Case ID - Stores the case ID of the safety event as assigned in the Oracle Argus Safety application

• SE Current Reason - Stores the rejection reason given by an Oracle Argus Safety user if a file transmitting a safety event is rejected by the Oracle Argus Safety application

• SE Current Status - Stores the accepted or rejected status of the most recent safety transmission file in the Oracle Argus Safety application

These items should have a data type of Text.

You can design these items as read only or hidden by selecting Read Only or Hidden as the value of the Display Override property in the Properties Browser for each item.

Note:

In the Oracle Health Sciences InForm application, administrator users can override the display properties of an item for each rights group.

3.3.2.3 Items Not Entered in the InForm User Interface

Some forms might require items to hold data that is not collected through the user interface in the InForm study but that needs to be transmitted to the Oracle Argus Safety application. For example, in a typical InForm study, a lab form might not include the lab test name as a user-entered data item. Instead, the lab test name might appear as a text label on the form. However, the Oracle Argus Safety application requires the lab name, so you need to design the form so that the lab name is transmitted as a data item.

• In the InForm 4.6 or 5.5 application, you can design such items as hidden items and use a rule to populate them with the required text.

• In the InForm 6.0 application, you can use either of the following design methods:

  • As in previous versions of the InForm application, design such items as hidden items and use a rule to populate them with the required text.

  • Design such items as fixed items in a fixed repeating section. A fixed repeating section is deployed to the InForm application as a Repeating Data itemset.

After using either method to design the items, map them along with user-entered items to the appropriate data series for transmittal to the Oracle Argus Safety application.

3.3.2.4 Hidden Items

Use the following design practices to create a hidden item and transmit it to the Oracle Argus Safety application:

• Item - When you create the item, in the Properties Browser, select Hidden as the value of the Display Override property

• Rule - Create a calculation rule using the SetValue action

• Mapping - Map the lab test name to the Test_Name data series in the Subject_LabTest data set

In the following example, when the Labs Local Hematology form is submitted, a calculation rule populates the hidden HemoglobinLabNameLL2 item with the value Hemoglobin if a value is entered in the HemoglobinValueLL2 item.

Table 3-1 Calculation Rule to Set the Value of a Hidden Field to the Name of the Lab

Rule Part	Specification
Precondition	Evaluate on Form Submission
Expression	value = (this.sctHemoglobin.HemoglobinValueLL2.Empty) && !this.sctHemoglobin.HemoglobinLabNameLL2.Empty ? 2 : (!this.sctHemoglobin.HemoglobinValueLL2.Empty) && (this.sctHemoglobin.HemoglobinLabNameLL2.Empty || ("Hemoglobin" != this.sctHemoglobin.HemoglobinLabNameLL2.Value)) ? 1 : 3
Action	Set Value check box is selected. Set Value clause: when value == 1 set this.sctHemoglobin.HemoglobinLabNameLL2.Value = "Hemoglobin" when value == 2 set this.sctHemoglobin.HemoglobinLabNameLL2.Empty = true

3.3.2.5 Fixed Items in a Repeating Data Itemset

Use the following design practices to create a fixed item in a fixed repeating section and transmit the item to the Oracle Argus Safety application.

Note:

This functionality is available starting with Central Designer 2.0 and InForm 6.0.

• To designate a section as fixed and repeating, in the Section Editor, select the Fixed and Repeating check boxes.

• Design each non-user-entered item that you plan to transmit to the Oracle Argus Safety application as a fixed item. A fixed item must:

  • Be a top-level item with no nested items.

  • Be a text, integer, or float item.

  • Have a control type of radio button or pull-down.

  • Have a codelist and at least one codelist item defined for it. The codelist item contains the text to be transmitted to the Oracle Argus Safety application, for example, the lab test name.

• Map the fixed items to the appropriate data series. For example, map the lab test name to the Test_Name data series in the Subject_LabTest data set.

3.3.2.6 AE Start Date Item

The onset date for an adverse event can be used to associate the adverse event with related safety data based on date ranges configured in the InForm Publisher application. If an instance of a related form has a start date within the specified range of the AE onset date, the safety event data from the related form is transmitted to the Oracle Argus Safety application with the AE data.

For example, if the AE Start Date is March 1, 2013 and the timeframe for collecting related adverse events is 14 days, an AE that occurred on Feb 25, 2013 would be sent to the Oracle Argus Safety application to be considered as related to the serious adverse event.

The types of forms that can be related to a serious event (SE) based on start dates are:

• Adverse Events (AE)

• Concomitant Medications (CM)

• Labs

For information about configuring the relationship of safety event data based on dates, see the InForm Publisher documentation.

3.3.2.7 Death Date and Patient Autopsy Completed Code Items

The Oracle Health Sciences InForm to Oracle Argus Safety integration supports collecting the patient death date and the code indicating whether a patient autopsy was completed on either a flat form or a repeating form. If your study is designed to include the death date and patient autopsy completed code on a repeating form, such as an AE/SE form, make sure that only one death date and patient autopsy completed code can be entered. If you do not, and a user mistakenly enters different death dates or patient autopsy completed codes on multiple instances, incorrect data might be transmitted to the Oracle Argus Safety application.

To prevent this, you should create a rule to check for the entry of multiple different death dates or patient autopsy completed codes.

3.3.2.8 Sequence Number Item

A sequence number item is required if your study has separate AE and SE forms. When an AE is serious, an SE is completed for that AE instance. The sequence number item, a text or integer item on the SE form, holds the number of the AE instance for which the SE form is entered.

3.3.3 Designing Rules

To populate safety events in the InForm Publisher queue, you create a rule on the combined AE/SE form or the standalone AE and SE forms. This rule must contain a function call to the _SaveToDb function, which evaluates the state of specific controls on the form to determine whether to load the InForm Publisher queue with data from the form.

The Oracle Health Sciences InForm to Oracle Argus Safety integration package includes a DLL file containing the _SaveToDB function. You must import the DLL file into each study in which you create integration rules. For more information, see Section 3.3.3.2.

The integration package also includes sample studies containing rules that you can use or modify to fit the requirements of your study.

This section contains the following topics:

• Section 3.3.3.1, "_SavetoDB Function"

• Section 3.3.3.2, "Importing the _SavetoDB Function"

• Section 3.3.3.3, "Sample Rule Scenarios"

• Section 3.3.3.4, "Optional Rules"

3.3.3.1 _SavetoDB Function

The _SavetoDB function is called in rules that determine whether to send data to the InForm Publisher queue.

Syntax: _SaveToDB(<Message>,<Trialname>);

• Message (string) - Parameter that triggers the InForm Publisher application to do one of the actions listed below. The rule expression loads the message parameter with a value based on the value of specific items in the form. For more information, see Section 3.3.2.1.

  The text of the message parameter is fixed. The library in the Oracle Health Sciences InForm and Oracle Argus Safety integration package includes the following constants defining enumerations for the required strings. Using these SafetyConstants enumerations to specify the required strings is strongly recommended.

  • IsReadyToSend - Sends safety event data to the Oracle Argus Safety application immediately

  • IsReportableOrSerious - Marks the safety event as serious and sends it to the Oracle Argus Safety application after a time interval that is configured in the InForm Publisher application

  • IsCancelled - Does one of the following:

    Cancels a pending submission

    Sends a nullification submission to the Oracle Argus Safety application if the safety event was submitted previously

    Does nothing if the safety event was not marked serious previously

• Trialname (string) - Name of the study, populated by the GetTrialName() predefined function.

  Sample call to _SaveToDB:

  _SaveToDB('SafetyConstants.IsReportableOrSerious',GetTrialName());

3.3.3.2 Importing the _SavetoDB Function

Before you can use the _SavetoDB function in the integration rules for a study, you must import the .NET assembly containing the function into the study.

1. In the study, select the Functions tab.

2. Click Import Function.

   The Function File dialog box appears.

3. Locate the .NET assembly (a DLL file) containing the _SavetoDB function definition, and click Open.

   The function is stored in the Central Designer database and added to the list of functions in the grid of the Functions tab.

3.3.3.3 Sample Rule Scenarios

The Oracle Health Sciences InForm to Oracle Argus Safety integration package includes sample rule scenarios that you can use or modify to fit the design of your study. In all of the sample rule scenarios, the rules are defined at the form level and are executed when the form is submitted.

Note:

The descriptions of rule scenarios indicate typical usage on combined AE/SE forms or standalone AE and SE forms. However, the action of a rule depends only on the triggering items on each form, not on whether the form is combined or standalone.

3.3.3.3.1 Safety_IsReportableOrSerious_Scenario1

Description of Safety_IsReportableOrSerious_Scenario1 Rule

Characteristic	Description
When to use	This rule is typically used when you want to indicate explicitly that the safety event information is ready to be sent to the Oracle Argus Safety application. You might use this rule when: The InForm user wants to make sure that any related labs or concomitant medications have been entered before transmitting the AE to the Oracle Argus Safety application A review process is in place This rule can be used for a combined AE/SE form or for a separate SE form.
Purpose	Ensures that for a safety event to be sent immediately to the Oracle Argus Safety application, the safety event must be marked either reportable or serious and must be marked ready to send.
Triggering controls	Y or N codelists or check boxes for the following: Item marking the safety event ready to send (the ready-to-send item) Item marking the safety event reportable (the reportable item) Item marking the safety event serious (the serious item)
Action when rule is triggered	Reportable or serious item value is Y, and ready-to-send item value is Y: Message - IsReadyToSend Result - The safety event data is sent to the Oracle Argus Safety application immediately Reportable or serious item value is Y, but ready-to-send item value is N: Message - IsReportableOrSerious Result - The safety event data is sent to the Oracle Argus Safety application after an interval that is configured in the InForm Publisher application Ready-to-send item value is Y, but neither the reportable nor the serious item value is Y Message - IsCancelled Result - The _SaveToDB function does one of the following: Cancels a pending submission Sends a nullification submission to the Oracle Argus Safety application if the safety event was submitted previously Does nothing if the safety event was not marked reportable or serious previously
Rule expression	(!this.AEInfoSct.IsSerious.Empty && this.AEInfoSct.IsSerious.Value != 'N')|| (!this.AEInfoSct.IsReportable.Empty && this.AEInfoSct.IsReportable.Value != 'N')? (!this.AEInfoSct.IsReadyToSubmit.Empty && this.AEInfoSct.IsReadyToSubmit.Value != 'N') ? _SaveToDb("SafetyConstants.IsReadyToSend", GetTrialName()) : _SaveToDb("SafetyConstants.IsReportableOrSerious", GetTrialName()): _SaveToDb("SafetyConstants.IsCancelled", GetTrialName())

3.3.3.3.2 Safety_IsReportableOrSerious_Scenario2

Description of Safety_IsReportableOrSerious_Scenario2 Rule

Characteristic	Description
When to use	Use this rule when you want the safety event data to be sent immediately on form submission, and you do not require the InForm user to indicate that the data is ready to send.
Purpose	Sends a safety event immediately to the Oracle Argus Safety application if the safety event is marked reportable or serious.
Triggering controls	Y or N codelists or check boxes for the following: Item marking the safety event reportable (the reportable item) Item marking the safety event serious (the serious item)
Action when rule is triggered	Reportable or serious item value is Y: Message - IsReadyToSend Result - The safety event data is sent to the Oracle Argus Safety application immediately Neither reportable nor serious item value is Y: Message - IsCancelled Result - The _SaveToDB function does one of the following: Cancels a pending submission Sends a nullification submission to the Oracle Argus Safety application if the safety event was submitted previously Does nothing if the safety event was not marked reportable or serious previously
Rule expression	(!this.AEInfoSct.IsSerious.Empty && this.AEInfoSct.IsSerious.Value != 'N')|| (!this.AEInfoSct.IsReportable.Empty && this.AEInfoSct.IsReportable.Value != 'N')? _SaveToDb("SafetyConstants.IsReadyToSend", GetTrialName()): _SaveToDb("SafetyConstants.IsCancelled", GetTrialName())

3.3.3.3.3 Safety_IsReportableOrSerious_Scenario3

Description of Safety_IsReportableOrSerious_Scenario3 Rule

Characteristic	Description
When to use	This rule is typically used on a standalone AE form in conjunction with a Scenario4 rule that is designed on an SE form.
Purpose	Queues a safety event for sending to the Oracle Argus Safety application after an interval that is configured in the InForm Publisher application if the safety event is marked reportable or serious.
Triggering controls	Y or N codelists or check boxes for the following: Item marking the safety event reportable (the reportable item) Item marking the safety event serious (the serious item)
Action when rule is triggered	Reportable or serious item value is Y: Message - IsReportableOrSerious� Result - The safety event data is sent to the Oracle Argus Safety application after an interval that is configured in the InForm Publisher application Neither reportable nor serious item value is Y:� Message - IsCancelled� Result - The _SaveToDB function does one of the following:� Cancels a pending submission� Sends a nullification submission to the Oracle Argus Safety application if the safety event was submitted previously� Does nothing if the safety event was not marked reportable or serious previously
Rule expression	(!this.AEInfoSct.IsSerious.Empty && this.AEInfoSct.IsSerious.Value != 'N')|| (!this.AEInfoSct.IsReportable.Empty && this.AEInfoSct.IsReportable.Value != 'N')? _SaveToDb("SafetyConstants.IsReportableOrSerious", GetTrialName()): _SaveToDb("SafetyConstants.IsCancelled", GetTrialName())

3.3.3.3.4 Safety_IsReadyToSend_Scenario4

Description of Safety_IsReadyToSend_Scenario4 Rule

Characteristic	Description
When to use	Typically used for a standalone SE form in combination with an AE form that has a rule using Safety_IsReportableOrSerious_Scenario3. If the AE form has a rule using Safety_IsReportableOrSerious_Scenario3, when the AE instance reporting the SE is submitted, data from that instance is queued for transmission after a configured time interval if the data is marked reportable or serious.
Purpose	Sends a safety event immediately to the Oracle Argus Safety application if the safety event is marked ready to send.
Triggering controls	Y or N codelist for an item marking the safety event ready to send (the ready-to-send item).
Action when rule is triggered	Ready-to-send item value is Y: Message - IsReadyToSend Result - The safety event data is sent to the Oracle Argus Safety application immediately
Rule expression	(!this.sctSeriousAdverseEvent.IsReadyToSubmit.Empty && this.sctSeriousAdverseEvent.IsReadyToSubmit.Value != "N") ? _SaveToDb("SafetyConstants.IsReadyToSend", GetTrialName()): 0

3.3.3.3.5 Safety_IsReadyToSend_Scenario5

Description of Safety_IsReadyToSend_Scenario5 Rule

Characteristic	Description
When to use	Typically used for a standalone SE form in combination with an AE form that has a rule using Safety_IsReportableOrSerious_Scenario3. If the AE form has a rule using Safety_IsReportableOrSerious_Scenario3, when the AE instance reporting the SE is submitted, data from that instance is queued for transmission after a configured time interval if the data is marked reportable or serious.
Purpose	Sends a safety event immediately to the Oracle Argus Safety application if the SE form references an instance of the AE form reporting the SE.
Triggering controls	Seq number item containing the number of the related instance of the AE form. The rule is triggered if the seq number item has any value.
Action when rule is triggered	Seq number item has a value: Message - IsReadyToSend Result - The safety event data is sent to the Oracle Argus Safety application immediately
Rule expression	!this.SESeqNo.Empty? _SaveToDb("SafetyConstants.IsReadyToSend",GetTrialName()) : 0

3.3.3.4 Optional Rules

Along with the rules that manage the queuing and sending of safety data, you could design rules that:

• Send email to the safety team when an adverse event is marked as serious

• Generate a query if a form is submitted without an entry in the fields that trigger transmission of safety data

• Generate a query when a serious AE instance is submitted to remind the user to create a related SE instance

• Populate the SE form with data from related forms, such as AE, Medical History, Concomitant Medication, or Lab forms

For details about designing these types of rules, see the Central Designer documentation.

3.3.4 Designing Logical Schemas/Data Mappings

In the Central Designer application, a logical schema/data mapping is data grouping that provides an alternate data view of a study. The Oracle Health Sciences InForm and Oracle Argus Safety integration uses the logical schema/data mapping feature of the Central Designer application to configure how safety event data items on InForm forms correspond to safety event entities in the Oracle Argus Safety application.

Note:

In release 1.4.x of the Central Designer application, the object used to design data mappings is called a logical schema. In release 2.0 and later, the object is called a data mapping. This document refers to the object as a logical schema/data mapping.

A logical schema/data mapping is made up of data sets, and each data set is made up of data series:

• A data set is a grouping of one or more related data series

• A data series is a grouping of one or more items with the same clinical meaning, such as or more items that collect medical history

When you design a study, you map the data series in each data set to the InForm items that provide the source data to transmit to the Oracle Argus Safety application. Mappings for almost all of the data series are optional; you map only the data series that provide applicable safety event information for your study.

This section contains the following topics:

• Section 3.3.4.1, "About the SafetyLogicalSchema Logical Schema/Data Mapping"

• Section 3.3.4.2, "Mappings for Flat Data Sets"

• Section 3.3.4.3, "Mappings for Repeating Data Sets"

• Section 3.3.4.4, "Mappings for Items that Occur in More than One Form or Visit"

• Section 3.3.4.5, "Mappings for Coded Items"

• Section 3.3.4.6, "Mapping Items Coded in the Oracle Health Sciences InForm Application"

• Section 3.3.4.7, "Mapping Items to Be Coded in the Oracle Argus Safety Application"

• Section 3.3.4.8, "Mapping the MedDRA Version for Coded Items"

• Section 3.3.4.9, "Mappings for Items with Units"

• Section 3.3.4.10, "Mapping an Item That Includes Units"

• Section 3.3.4.11, "Mapping an Item with a Separate Units Item"

• Section 3.3.4.12, "Mappings for Multiple AE Forms"

• Section 3.3.4.13, "Mappings for Custom Data Series"

3.3.4.1 About the SafetyLogicalSchema Logical Schema/Data Mapping

The logical schema/data mapping used to transfer data from an InForm study to the Oracle Argus Safety application contains the following data sets:

• Safety_Config - Identifies items and forms used by the InForm Publisher application for safety processing. For example, the Safety_Config data set includes a required data series mapped to a control in the AE form so that the InForm Publisher app can identify the AE forms in the study.

  For more information, see Section 3.3.6.1.

• Safety_Significant - Identifies items that are monitored for changes after initial transmission to determine whether update transmissions are needed. The items mapped to data series in the Safety_Significant data set are considered significant for safety and trigger an update transmission when changed. For example, if an AE item containing data about a reaction recurrence is mapped to a data series in the Safety_Significant data set, an update transmission is triggered when a user changes the data in the reaction recurrence item.

  For more information, see Section 3.3.6.2.

• Multiple message body data sets - These data sets make up the main message body sent to the Oracle Argus Safety application. The data set names indicate the type of data that is mapped. For example, the Subject data set is used to map demographic data about the patient.

  For more information, see Section 3.3.7.

3.3.4.2 Mappings for Flat Data Sets

Most data sets are associated with elements in the safety event transmission that occur only once. You map the data series in these data sets to a specific instance of an item. A specific instance of an item you can map to a data series in a flat data set is an item that is:

• In a non-repeating section (that is, not an InForm itemset).

• On a non-repeating form.

• In a non-repeating visit.

• On the instance of the AE form that is being submitted. Although the AE form is most often repeating, or flat data sets, only the data in the current instance of the AE form being submitted is transmitted.

If the item is on a form that occurs in multiple visits, you must map the data series to a specific instance of the study event and form. For more information, see Section 3.3.4.4.1.

3.3.4.3 Mappings for Repeating Data Sets

The data series in repeating data sets are mapped to items that can occur multiple times in a safety event transmission message. You can map these data series to items in repeating sections, forms, and visits, and each data series in a repeating data set must be mapped to the same repeating section, form, and visit. When a form containing repeating data is submitted, the safety event transmission message includes the mapped data from all applicable instances of the form.

Note:

If you have configured the InForm Publisher application to select related data based on dates, the configuration could affect the number of instances that are sent in a safety event transmission message. For example, multiple AEs might be sent with the submitted AE if their dates are within the configured range for related data.

Only the following data sets are repeatable:

• Subject_AdverseEvent

• Subject_ConMed

• Subject_LabTest

• Subject_MedicalHistory

• Subject_PastDrugHistory

• Subject_SuspectDrug

Map the data series in the following data sets to the same form as the Subject_SuspectDrug data set:

• Subject_SuspectDrug_ReactionRecurrence

• Subject_SuspectDrug_ReactionRelatedness

• Subject_Death

Map the data series in the following data sets to the same form as the Subject_Death data set:

• Subject_CauseOfDeath

• Subject_Autopsy

• MedicalDevice

Map the data series in the following data sets to the same form as the MedicalDevice data set:

• MedicalDevice_Evaluation

• MedicalDevice_EventProblem

• MedicalDevice_RemedialAction

• MedicalDevice_Reprocessor

If an item occurs in multiple forms or visits, you can map a data series to the item in a specific form or in a specific form and visit by using the Data Series Summary tab of the form or study event. For more information, see Section 3.3.4.4.

You can map multiple items to the same data series, and you can map similar items from different forms to the same data series in a repeating data set. For example, you could map items from a Lab Local and a Lab Central form to the same data series in the Subject_LabTest data set. When you do this, the safety event transmission treats the items as coming from different instances, so the transmission message contains a different element for each form.

3.3.4.4 Mappings for Items that Occur in More than One Form or Visit

When you map a data series to an item that occurs in more than one form or visit in the study, you must specify the instance of the item that you intend to map. You do this on the Data Series Summary tab of a study event or form.

When you add an item to a data series in the Data Series Summary tab of the Form or Study Event editor, you can specify the instances of the item that you want to be mapped to the data series:

• None - The item is not added to the data series.

• Always - The item is always mapped to the data series, on every form, in every study, and in the library.

• Form - The item is mapped to the data series only when the item appears on a specific section (or form, if the form has no sections). You can select this option for multiple sections or forms.

• Study Event - (Available only when a study event is selected.) The item is mapped to the data series only when it appears on any form in a specific study event. You can select this option for multiple study events.

• Study Event & Form - (Available only when a study event is selected.) The item is mapped to the data series only when it appears on a specific form in a specific study event.

3.3.4.4.1 Mapping to a Specific Instance of a Visit and Form

To map to a specific instance of a visit and form, use the Data Series Summary tab of the study event:

1. In the Project Explorer, select a study event.

2. Select the Data Series Summary tab.

3. Optionally, use the drop-down lists to filter the selection of logical schemas/data mappings, data sets, and data series.

4. In the Items column, select the item to map.

5. In the column for the data series, click the arrow on the right side of the selected row, and select Study Event & Form.

3.3.4.4.2 Mapping to a Specific Instance of a Form

To map to a specific instance of a form, use the Data Series Summary tab of the form:

1. In the Project Explorer, select a form.

2. Select the Data Series Summary tab.

3. In the Items column, select the item to map.

4. In the column for the data series, click the arrow on the right side of the selected row, and select Form.

3.3.4.5 Mappings for Coded Items

The Oracle Health Sciences InForm to Oracle Argus Safety integration supports the transmission of several items that typically are collected and encoded for safety reporting. The mapping for these items depends on how you do the coding.

• Items coded in the Oracle Health Sciences InForm application before transmission - If the InForm study is integrated with an external coding application, such as Oracle® Health Sciences Central Coding, you can map the items so that the encoded data is transmitted to the Oracle Argus Safety application.

  For more information, see Section 3.3.4.6.

• Items coded in the Oracle Argus Safety application - If you want the items to be encoded by the coding module of the Oracle Argus Safety application or to be encoded manually by Oracle Argus Safety users, you can map the items so that the verbatim data is transmitted to the Oracle Argus Safety application for coding.

  For more information, see Section 3.3.4.7.

The following items have data series for transmitting encoded or verbatim data:

Item	Data Set	Data Series
AE description (verbatim)	Subject_AdverseEvent	AE_VerbatimTerm
AE description (coded to MedDRA lower-level term)	Subject_AdverseEvent	AE_LowLevelTerm
AE description (coded to MedDRA preferred term)	Subject_AdverseEvent	AE_PreferredTerm
Indication for concomitant medication	Subject_ConMed	ConMed_Indication
Indication for suspect drug use	Subject_SuspectDrug	SuspectDrug_Indication
Indication for past drug use	Subject_PastDrugHistory	PastDrugHistory_Indication
Reaction to past drug use	Subject_PastDrugHistory	PastDrugHistory_Reaction
Medical history condition	Subject_MedicalHistory	MedicalHistory_Name
Cause of death	Subject_CauseOfDeath	CauseOfDeath
Autopsy cause of death	Subject_Autopsy	AutopsyCauseOfDeath

3.3.4.6 Mapping Items Coded in the Oracle Health Sciences InForm Application

To specify that the data transmitted from the Oracle Health Sciences InForm application is encoded:

• AE description item - Map the following data series to the corresponding items, as identified in the table in Section 3.3.4.5:

  • AE_VerbatimTerm

  • AE_LowLevelTerm

  • AE_PreferredTerm

  • AE_LLTMedDRAVersion

  • AE_PTMedDRAVersion

  When the Oracle Argus Safety application receives an AE description, if all of the items mapped to these data series have data, the Oracle Argus Safety application does not attempt to code the verbatim. However, if the Oracle Argus Safety application receives the verbatim before the item is encoded in the Oracle Health Sciences InForm application, the Oracle Argus Safety application attempts to encode the item and places the encoded values in the appropriate Oracle Argus Safety fields.

  Note:

  To make sure that the data sent to the Oracle Argus Safety application is encoded in the Oracle Health Sciences InForm application, you can map the data series listed above in the SafetySignificant data set as well as in the Subject_AdverseEvent data set. When the external coding application returns encoded values to the InForm application, the updated values on the form trigger a follow-up transmission to the Oracle Argus Safety application. A user in the Oracle Argus Safety application can accept the follow-up, and the InForm codes replace the Oracle Argus Safety codes.

  When you use this approach, make sure that the MedDRA dictionary used for coding in the Oracle Health Sciences InForm application is the most recent version.

• Other codable items:

  1. Map the appropriate data series to the item containing the encoded MedDRA lower-level term. For example, map the ConMed_Indication data series to the lower-level term for the concomitant medication indication.

  2. Map the data series for the MedDRA version to the item containing the version of the MedDRA dictionary used to encode the item.

  Note:

  For these items, the data mappings enable you to transmit either the verbatim or the encoded value, but not both. If you want the Oracle Argus Safety application to have both the verbatim and the encoded value, map the verbatim item and let the Oracle Argus Safety application encode it. For more information, see Section 3.3.4.7.

3.3.4.7 Mapping Items to Be Coded in the Oracle Argus Safety Application

To specify that transmitted data is verbatim and should be encoded in the Oracle Argus Safety application:

• AE description item:

  • Map the AE_VerbatimTerm data series to the item in which the InForm user enters the AE description

  • Do not map the following data series:

    AE_LowLevelTerm

    AE_PreferredTerm

    AE_MedDRAVersion

    For more information, see Section 3.3.4.8.

• Other codable items:

  • Map the appropriate data series to the item containing the verbatim entered by the InForm user. For example, map the MedicalHistory_Name data series to the item in which the user entered a medical history event.

  • Do not map the MedDRA version data series.

  When the Oracle Argus Safety application receives the data and creates a case, it attempts to encode the verbatims. If it cannot encode them, a warning appears when the Pending E2B file is accepted, and a user can encode the items manually through the Oracle Argus Safety user interface.

3.3.4.8 Mapping the MedDRA Version for Coded Items

Each data series for an item that can be coded has a corresponding data series, called <dsname>MedDRAVersion. <dsname> is the name of the data series to which the MedDRA version applies.

• Coded data - If the transmitted data is encoded in the Oracle Health Sciences InForm application or in a coding application that is integrated with the Oracle Health Sciences InForm application, map the <dsname>MedDRAVersion data series to an item that holds the version of the MedDRA dictionary used to encode the transmitted data.

  When you map the <dsname>MedDRAVersion data series, you signal the Oracle Argus Safety application that the corresponding data is encoded, and the coding module in the Oracle Argus Safety application does not encode the data.

• Verbatim data - If you want the coding to take place in the Oracle Argus Safety application, do not map the <dsname>MedDRAVersion data series.

  Leaving the <dsname>MedDRAVersion data series unmapped signals the Oracle Argus Safety application that the corresponding data is verbatim and should be encoded in the Oracle Argus Safety application.

3.3.4.9 Mappings for Items with Units

In the Central Designer application, you can design items that are entered along with an indication of the unit in which the measurement is reported. The unit definition can be part of the item definition, or you can create a separate item to hold the unit selection. The Oracle Health Sciences InForm to Oracle Argus Safety integration accommodates both models, using two data series for each item with units:

• A data series to hold the value of the item

• A data series to hold the units in which the value is entered

The following illustration shows an item in which the unit is specified as part of the item definition. When you map this type of item, you use only the data series for the item value. For more information, see Section 3.3.4.10.

The following illustration shows an item in which a separate item is designed to hold the unit selection. When you map this type of item, you use both the data series for the item value and the data series for the unit. For more information, see Section 3.3.4.11.

The InForm Publisher application sends the data value for an item and the units in which it is reported to the same field in the Oracle Argus Safety application.

3.3.4.10 Mapping an Item That Includes Units

To map an item in which the unit selections are included in the item definition:

1. In the Data Series editor, select the item to map.

   The Item has units dialog box appears.

2. Select Entered Value, and click OK.

   The item is mapped to the data series. You do not need to create a separate mapping for the units. When the InForm Publisher application generates the data transmission message, the InForm Publisher application populates the element for the corresponding unit data series with the unit.

For example, to map the duration data in the example, map the AE_Duration data series to the Adverse Event Duration item. The InForm Publisher application automatically populates the element corresponding to the AE_DurationUnit data series with the unit selection for the item.

Note:

The automatic mapping of units is supported only for data series that have a corresponding unit data series, and it is not supported for custom data series. To map an item with included units to a custom data series, you must also create a custom data series for the units and map the two data series to the item value and units separately.

If you map an item that is designed with units included, and you map its corresponding unit data series to another item, the unit value of the item designed with units overrides the manual data series mapping for the unit.

3.3.4.11 Mapping an Item with a Separate Units Item

If the study design includes a separate item to hold the unit used to record the measurements taken with an item, you must map the unit item to a separate unit data series. The logical schema/data mapping for the Oracle Health Sciences InForm to Oracle Argus Safety integration includes a unit data series for each item that has units.

For example, to map the dosage data in the example illustrated in Section 3.3.4.9, in the Subject_SuspectDrug data set:

• Map the SuspectDrug_Dosage data series to the Dosage (float) item (value is 5.0)

• Map the SuspectDrug_DosageUnit data series to the Dosage Units item (value is Gram)

In the Oracle Argus Safety application, the Dose Units field is populated with the value 5.0 Gram.

3.3.4.12 Mappings for Multiple AE Forms

If your study design contains secondary AE forms, and your study is based on the model of collecting AE and SE data on a combined form, the Oracle Health Sciences InForm to Oracle Argus Safety integration supports transmitting safety event data from all AE forms. The integration does not support mappings for multiple AE forms when the study uses the model of separate AE and SE forms.

To create mappings for multiple AE forms, map the corresponding items from each AE form to the same data series.

For example, if you have a primary AE form and a Pregnancy AE form:

• In the Safety_Config data set:

  • Map an item from the primary AE form and an item from the Pregnancy AE form to the Any AE Form Control data series. The Oracle Health Sciences InForm to Oracle Argus Safety integration uses this data series to identify the AE form or forms in the study.

  • Optionally, map items from both the primary AE form and the Pregnancy item to the other data series.

    Note:

    To enable inclusion of form instances based on date range, as configured in the InForm Publisher application, you must map a date time item from the primary AE form and a date time item from the Pregnancy AE form to the AE Start Date Control data series.

• In the other data sets, map items from the primary AE form and the Pregnancy AE form to the applicable data series. For example, map the AE Start Date from each form to the AE_StartDateTime data series in the Subject_AdverseEvent data set.

3.3.4.13 Mappings for Custom Data Series

In addition to the predefined data series in the SafetyLogicalSchema logical schema/data mapping, you can add custom data series to the following data sets:

• Safety_Case

• Subject

• Subject_AdverseEvent

• MedicalDevice

Custom data series support transmitting data collected in the Oracle Health Sciences InForm application to custom fields in the Oracle Argus Safety application.

Note:

The Oracle Health Sciences InForm and Oracle Argus Safety integration uses the DrugSafetyReport EBO, an XML schema definition that contains elements required for drug and device trials, as well as information that exists in safety systems and is collected in EDC systems for sharing with safety systems. Data from the Oracle Health Sciences InForm application is transmitted in an Enterprise Business Message (EBM), which operates on the DrugSafetyReport EBO. The EBM used by the Oracle Health Sciences InForm and Oracle Argus Safety integration is the ReportDrugSafetyReport EBM. For more information, see Industry AIA Components.

3.3.4.13.1 Creating a Custom Data Series

To create a custom data series, add a data series to one of the data sets that allows custom data series.

• The RefName and Title are user-defined. Oracle recommends that you use a naming convention that is similar to the names of other data series in the data set.

• The Alias must match the user-defined field to be populated in the Oracle Argus Safety application. Use the naming convention in the following table. For example, to populate custom string field 1 on the General tab of the Oracle Argus Safety application, map a custom data series in the Safety_Case data set using the alias Cust_General_Str_1.

Note:

The index numbers must be unique within each data set. For example, in the Subject data set, you can create Cust_General_Str_1 and Cust_General_Num_2, but you cannot create Cust_General_Str_1 and Cust_General_Num_1.

Alias Names in Custom Data Series

Data Set Title	Tab in the Oracle Argus Safety application	Alias Naming Convention
Safety_Case	General	String fields: Cust_General_Str_<1...12> Number fields: Cust_General_Num_<1...12> Date fields: Cust_General_Dt_<1...12>
Subject	Patient	String fields: Cust_Patient_Str_<1...12> Number fields: Cust_Patient_Num_<1...12> Date fields: Cust_Patient_Dt_<1...12>
Subject_AdverseEvent	Event	String fields: Cust_Reaction_Str_<1...12> Number fields: Cust_Reaction_Num_<1...12> Date fields: Cust_Reaction_Dt_<1...12>
MedicalDevice	Medical Device	String fields: Cust_Device_Str_<1...12> Number fields: Cust_Device_Num_<1...12> Date fields: Cust_Device_Dt_<1...12>

For example, in the sample studies delivered with the Oracle Health Sciences InForm and Oracle Argus Safety integration package, the Subject_AdverseEvent data set has a custom data series with the following properties:

• RefName - DSRReaction_Cust_float_1

• Title - AE_Cust_float_1

• Alias - Cust_Reaction_Num_1

This mapping means that in the Event tab of the Oracle Argus Safety application, the user-defined float field 1 receives data from the InForm item mapped to the AE_Cust_float_1 data series.

3.3.4.13.2 Validation for Mappings

When the InForm Publisher service starts, an optional validation runs on the mappings defined in the logical schema/data mapping to make sure that no required mappings are missing and that the logical schema/data mapping does not contain mappings that are unsupported by the InForm Publisher application. This validation is useful for catching common mapping mistakes in the logical schema/data mapping that could cause unexpected results in the data published by the InForm Publisher application. The validation checks that:

• All required mappings have been defined.

• Every item that is mapped in the Safety_Significant data set is also mapped in the message body data sets.

• Data series in non-repeating data sets are mapped to a specific instance of an item. For more information, see Section 3.3.4.2.

• Data series in repeating data sets are not mapped to both flat items and itemset items within the same repeating form.

To enable or disable the validation, set the RunStartupValidation attribute when configuring the InForm Publisher application. For more information, see Oracle® Health Sciences InForm Publisher Installation Guide.

3.3.5 Sample Studies and Logical Schema/Data Mapping

The integration package includes:

• Complete sample studies for two models of AE and SE data collection:

  • Adverse Events (AE) and Serious Events (SE) data is collected in a single, combined AE/SE form

  • AE and SE data is collected in separate, standalone forms

  Each study is packaged as a CSML file that you can import into your Central Designer instance and use as a reference or as a basis for study design. The sample studies include forms, items, rules, and fully mapped logical schemas/data mappings.

• A library containing a logical schema/data mapping in which all data sets and data series required for integration are present. To configure the mappings for a study, you copy the logical schema/data mapping into the study and use the logical schema/data mapping user interface to specify the mappings.

If you import the sample studies into your Central Designer instance, you must also import the library and associate it with each sample study that you import. Associating the library with a study supplies the study with the constants used in integration rules. If you do not associate the library with the sample studies, the sample studies fail validation.

This section contains the following topics:

• Section 3.3.5.1, "Installing the Sample Studies and Logical Schema/Data Mapping Library"

3.3.5.1 Installing the Sample Studies and Logical Schema/Data Mapping Library

To install a sample study or logical schema/data mapping in the Central Designer application:

The Import Study wizard appears.

1. Create a study or library and save it.

2. In the Project Explorer, right-click the study or library, and select Actions > Import Study.

3. Following the prompts and accepting the defaults, select the CSML file to import, and click Finish on the final page of the wizard.

An import job runs, and when it is complete, the study objects in the sample study or library are loaded into the Project Explorer.

For more information, see the Central Designer InForm Design Guide.

3.3.6 Data Set Definitions-System Data Sets

This section describes the following data sets, which contain information used by the Oracle Health Sciences InForm and Oracle Argus Safety integration software to process data transmissions:

• Safety_Config

• Safety_Significant

3.3.6.1 Safety_Config Data Set

The Safety_Config data set identifies items and forms used by the InForm Publisher application for safety processing. For example, the Safety_Config data set includes a required data series mapped to a control in the AE form so that the InForm Publisher app can identify the AE forms in the study.

Data Series in the Safety_Config Data Set

Data Series Title	Description
Any AE Form Control	Control used to identify the AE form. Map this data series to any item on the AE form. Required.
Any SE Form Control	Control used to identify the SE form in a design with separate AE and SE forms. Map this data series to any item on the SE form. Required in a design with separate AE and SE forms.
SE Case ID Control	Item used to store the Case ID returned from the Oracle Argus Safety application. Typically this item is on the AE or SE form. Used only if the InForm Adapter Safety interface is integrated into your installation.
SE Current Status Control	Item used to store the accepted or rejected status of the most recent safety transmission file. Typically this item is on the AE or SE form. Used only if the InForm Adapter Safety interface is integrated into your installation.
SE Current Reason Control	Item used to store the rejection reason given by an Oracle Argus Safety user if a file transmitting a safety event is rejected by the Oracle Argus Safety application. Typically this item is on the AE or SE form. Used only if the InForm Adapter Safety interface is integrated into your installation.
SE Related AE Sequence Number Control	Item on the SE form containing the sequence number of the AE instance for which the SE was entered. Required in a design with separate AE and SE forms.
AE Start Date Control	Onset date of the AE. This data series is used to identify by date range the related safety event data that appears on other forms.

3.3.6.2 Safety_Significant Data Set

The Safety_Significant Data Set is an empty data set in which you must create the data series and mappings for items that are monitored for changes after initial transmission to determine whether update transmissions are needed. The items mapped to data series in the Safety_Significant data set are considered significant for safety and trigger an update transmission when changed.

Note:

Compound items can include both items that are mapped as significant in the Safety_Significant data set and items that are not mapped as significant. When any item in a compound item is updated, all items in the compound item are updated, and therefore even an update to a non-significant item triggers an update transmission.

The data series in the Safety_Significant data set are a subset of the data series in the data sets that make up the main message body sent to the Oracle Argus Safety application. Every item that is mapped in the Safety_Significant data set must also be mapped in the message body data sets.

Additionally, the data series in the Safety_Significant data set must have the same aliases as the corresponding data series in the message body data sets. Therefore, copy and pasting data series from the message body data sets into the Safety_Significant data set is recommended.

3.3.7 Data Set and Data Series Definitions-Message Body Data Sets

The tables in this section describe the data sets and data series used to map InForm items to entities in the Oracle Argus Safety application.

The logical schema/data mapping user interface for the sample studies in the Central Designer application also includes definitions of each data series. To view the definitions of the data series in a data set, open the Data Set editor.

This document lists the data sets and data series by title. To view study objects by title in the Central Designer application, in the menu bar for the Project Explorer, select Options > Display Names > Titles.

This section contains the following topics:

• Section 3.3.7.1, "Safety_Case Data Set"

• Section 3.3.7.2, "Subject Data Set"

• Section 3.3.7.3, "Subject_AdverseEvent Data Set"

• Section 3.3.7.4, "Subject_Autopsy Data Set"

• Section 3.3.7.5, "Subject_CauseOfDeath Data Set"

• Section 3.3.7.6, "Subject_ConMed Data Set"

• Section 3.3.7.7, "Mapping Dosage Frequency Items in the Subject_ConMed Data Set"

• Section 3.3.7.8, "Subject_Death Data Set"

• Section 3.3.7.9, "Subject_LabTest Data Set"

• Section 3.3.7.10, "Subject_MedicalHistory Data Set"

• Section 3.3.7.11, "Subject_PastDrugHistory Data Set"

• Section 3.3.7.12, "Subject_SuspectDrug Data Set"

• Section 3.3.7.13, "Mapping Dosage Frequency Items in the Subject_SuspectDrug Data Set"

• Section 3.3.7.14, "Subject_SuspectDrug_ReactionRecurrence Data Set"

• Section 3.3.7.15, "Subject_SuspectDrug_ReactionRelatedness Data Set"

• Section 3.3.7.16, "MedicalDevice Data Set"

• Section 3.3.7.17, "MedicalDevice_Evaluation Data Set"

• Section 3.3.7.18, "MedicalDevice_EventProblem Data Set"

• Section 3.3.7.19, "MedicalDevice_RemedialAction Data Set"

• Section 3.3.7.20, "MedicalDevice_Reprocessor Data Set"

• Section 3.3.7.21, "Reporter Data Set"

3.3.7.1 Safety_Case Data Set

Data Series in the Safety_Case Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
SeriousIndicator	Indicates whether the case is serious.	Case Form / Analysis / Case Serious
OccurenceCountryCode	Country where the adverse event occurred.	Case Form/ General / General Information / Country of Incidence
SeriousnessDeathIndicator	Indicates whether the case resulted in death.	Case Form / Analysis / Case Serious / Notes
SeriousnessLifeThreatening Indicator	Indicates whether the case is life threatening.	Case Form / Analysis / Case Serious / Notes
SeriousnessHospitalization Indicator	Indicates whether the case requires inpatient hospitalization or prolongation of existing hospitalization.	Case Form / Analysis / Case Serious / Notes
SeriousnessDisablingIndicator	Indicates whether the case results in persistent or significant disability or incapacity.	Case Form / Analysis / Case Serious / Notes
SeriousnessCongenital AnomalyIndicator	Indicates whether the case results in a congenital anomaly or birth defect.	Case Form / Analysis / Case Serious / Notes
SeriousnessOtherIndicator	Indicates whether the case contains a medically important condition.	Case Form / Analysis / Case Serious / Notes

3.3.7.2 Subject Data Set

Data Series in the Subject Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
NameInitials	Patient initials.	Case Form / Patient / Patient Information / Initials
BirthDateTime	Patient date of birth.	Case Form / Patient / Patient Information / Date of Birth
OnsetAge	Age at the time of onset of the reaction.	Case Form / Patient / Patient Information / Age
OnsetAgeUnit	Unit for the age at time of onset of the reaction (for example, years, months).	Case Form / Patient / Patient Information / Age Units
GestationPeriod	Gestation period when the adverse event was observed in the fetus.	Case Form / Patient / Patient Information / Pregnancy Details / Weeks at Onset If a valid value is entered, the Pregnant field is selected as well.
GestationPeriodUnit	Unit for the gestation period (weeks, months, trimester).	Case Form / Patient / Patient Information / Pregnancy Details / Weeks at Onset If a valid value is entered, the Pregnant field is selected as well.
AgeGroupCode	Patient age group (for example, adolescent, adult).	Case Form / Patient / Patient Information / Age Group
Weight	Patient weight.	Case Form / Patient / Patient Information / Weight
WeightUnit	Unit for the patient weight (for example, lb, kg).	Case Form / Patient / Patient Information / Weight The integration process converts this value to kilograms if entered in pounds.
Height	Patient height.	Case Form / Patient / Patient Information / Height
HeightUnit	Unit for the patient height (for example, in, cm).	Case Form / Patient / Patient Information / Height The integration process converts this value to centimeters if entered in inches.
SexCode	Patient gender.	Case Form / Patient / Patient Information / Gender
LastMenstrualDateTime	Date of the last menstrual period before the adverse event occurred.	Case Form / Patient / Patient Information / Date of LMP
MedicalHistory	Text item used to summarize the medical history and concurrent conditions of the patient.	Case Form / Patient / Notes
InvestigationResult	Results of tests and procedures relevant to the investigation of the patient. Map this data series when structured information is not available.	Case Form / Patient / Relevant Test
RaceCode	Patient race.	Case Form / Patient / Patient Information / Ethnicity
BreastFeedingIndicator	Indicates whether the patient is a mother who breast feeds an infant.	Case Form / Patient / Patient Details / Breastfeeding
OccupationCode	Occupation of the patient.	Case Form / Patient / Patient Details / Occupation
PregnancyDueDateTime	Due date for the pregnancy.	Case Form / Patient / Pregnancy Information / Due Date
ProspectiveIndicator	Indicates that the sponsor was aware of the pregnancy before the birth.	Case Form / Patient / Pregnancy Information / Prospective
RetrospectiveIndicator	Indicates that the sponsor became aware of the pregnancy after the birth.	Case Form / Patient / Pregnancy Information / Retrospective
FetusCount	Number of fetuses in the pregnancy.	Case Form / Patient / Pregnancy Information / Fetus Count

3.3.7.3 Subject_AdverseEvent Data Set

Data Series in the Subject_AdverseEvent Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
AE_VerbatimTerm	Symptom or description of the adverse event as entered by the InForm user. Required.	Case Form / Events / Event Information / Description as Reported
AE_LowLevelTerm	MedDRA lower-level term (LLT) for the adverse event or reaction. Note: Do not map this data series if the item will be encoded in the Oracle Argus Safety application.	Case Form / Events / Event Encoding / Lower Level Term
AE_PreferredTerm	MedDRA preferred term (PT) for the adverse event or reaction. Note: Do not map this data series if the item will be encoded in the Oracle Argus Safety application.	Case Form / Events / Event Encoding / Preferred Term
AE_LLTMedDRAVersion	Version of MedDRA that was used to code the verbatim term to the lower-level term. Note: Do not map this data series if the item will be encoded in the Oracle Argus Safety application.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application
AE_PTMedDRAVersion	Version of MedDRA that was used to code the verbatim term to the preferred term. Note: Do not map this data series if the item will be encoded in the Oracle Argus Safety application.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application
AE_TermHighlilghtedCode	Term highlighted by the reporter (for example, Highlighted as serious, Highlighted as not serious, Serious and not highlighted, not Serious and not highlighted).	Case Form / Events / Event Information / Term Highlighted by Reporter
AE_StartDateTime	Onset or start date of the adverse event.	Case Form / Events / Event Information / Onset Date/Time
AE_EndDateTime	End date of the adverse event.	Case Form / Events / Event Information / Stop Date/Time
AE_FirstDoseToOnset Duration	Duration between the first dose of the study drug and the onset date of the adverse event if exact start and end dates are not known or the duration is less than one day.	Case Form / Events / Event Information / Onset Latency
AE_FirstDoseToOnsetDuration Unit	Unit for the first dose to onset duration (Minutes, Hours).	Case Form / Events / Event Information / Onset Latency
AE_LastDoseToOnset Duration	Duration between the last dose of the study drug and the onset date of the adverse event if exact start and end dates are not known or the duration is less than one day.	Case Form / Events / Event Information / Onset From Last Dose
AE_LastDoseToOnsetDuration Unit	Unit for the last dose to onset duration (Minutes, Hours).	Case Form / Events / Event Information / Onset From Last Dose
AE_OutcomeCode	Outcome of the adverse event at the last observation (for example, Recovered, Fatal).	Case Form / Events / Event Information / Outcome of Event
AE_SeverityCode	Severity of the adverse event (for example, Severe, Moderate, Mild).	Case Form / Events / Event Information / Event Intensity
AE_HospitalizationStart DateTime	Date that the patient was admitted to the hospital as a result of the adverse event.	Case Form / Event / <event name> / Seriousness Criteria / Hospitalization / Details / Start Date
AE_HosptializationEnd DateTime	Date that the patient was discharged from the hospital after having been admitted as a result of the adverse event.	Case Form / Event / <event name> / Seriousness Criteria / Hospitalization / Details / End Date
AE_CaseNarrative	Overall case narrative to send to the Oracle Argus Safety application. This data series can be mapped to one or more items on the AE or SE form. Note: Only the narrative from the instance of the AE or SE that triggers the data transmission is sent. Case narrative data from other AE or SE instances that occur within the timeframe for relatedness is not included in the transmission.	Case Form / Analysis / Case Analysis / Narrative
AE_InterventionRequired Indicator	Indicates whether the adverse event required intervention.	Case Form / Event / <event name> / Seriousness Criteria / Intervention Required
AE_Duration	Duration of the adverse event if exact start and end dates are not known or if the duration is less than one day.	Case Form / Events / Event Information / Duration
AE_DurationUnit	Unit for the duration of the adverse event.	Case Form / Events / Event Information / Duration
AE_SeriousnessDeathIndicator	Indicates whether the adverse event resulted in death.	Case Form / Event / <event name> / Seriousness Criteria / Death
AE_SeriousnessLifeThreatening Indicator	Indicates whether the adverse event was life threatening.	Case Form / Event / <event name> / Seriousness Criteria Life Threatening
AE_SeriousnessHospitalization Indicator	Indicates whether the adverse event resulted in hospitalization or prolonged existing hospitalization.	Case Form / Event / <event name> / Seriousness Criteria / Hospitalization
AE_SeriousnessDisabling Indicator	Indicates whether the adverse event resulted in persistent or significant disability or incapacity.	Case Form / Event / <event name> / Seriousness Criteria / Disability
AE_SeriousnessCongenital AnomalyIndicator	Indicates whether the adverse event resulted in a congenital anomaly or birth defect.	Case Form / Event / <event name> / Seriousness Criteria / Congenital Anomaly
AE_SeriousnessOtherIndicator	Indicates whether the adverse event was a medically important condition.	Case Form / Event / <event name> / Seriousness Criteria / Other
AE_SeriousnessOtherComment	Description of the medically important condition indicated by the Other Indicator item.	Case Form / Event / <event name> / Seriousness Criteria / <Other Comment Text>
AE_MedicallySignificant Indicator	Indicates whether the adverse event was medically significant.	Case Form / Event / <event name> / Seriousness Criteria / Medically Significant
AE_SubjectDroppedFromStudy Indicator	Indicates whether the subject dropped out of the study because of the adverse event.	Case Form / Event / <event name> / Diagnosis / Dropped From Study Due to Event
AE_RelatedToStudyConduct Code	Indicates whether the adverse event was related to a study procedure.	Case Form / Event / <event name> / Diagnosis / Related to Study Conduct?
AE_ReceivedTreatmentCode	Indicates whether the patient received treatment for the adverse event (Yes, No, Unknown).	Case Form / Event / <event name> / Diagnosis / Treatment Received
AE_SubjectHasPriorHistory Code	Indicates whether the patient had experienced the adverse event in the past (Yes, No, Unknown).	Case Form / Event / <event name> / Diagnosis / Patient Has Prior History
AE_LackOfEfficacyIndicator	Indicates whether the adverse event indicates a lack of efficacy of the study drug.	Case Form / Event / <event name> / Diagnosis / Lack of Efficacy
AE_DiseaseProgression Indicator	Indicates whether the adverse event caused the disease to progress.	Case Form / Event / <event name> / Diagnosis / Progression of Disease
AE_AdverseDrugWithdrawal ReactionIndicator	Indicates whether the adverse event was caused by withdrawal of the drug.	Case Form / Event / <event name> / Diagnosis / Adverse Drug Withdrawal Reaction
AE_InfectionIndicator	Indicates whether the adverse event resulted in an infection.	Case Form / Event / <event name> / Diagnosis / Infection

3.3.7.4 Subject_Autopsy Data Set

Data Series in the Subject_Autopsy Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
AutopsyCauseOfDeath	Cause of death as determined by autopsy. This can be a repeating itemset. For more information, see Section 3.3.4.3. Map to the user-entered verbatim or to the encoded MedDRA lower-level term.	Case Form / Patient / Death / Autopsy Results / Preferred Term Case Form / Events / Seriousness Criteria / Death / Details / Autopsy Results / Preferred Term
AutopsyCauseOfDeath MedDRAVersion	Version of MedDRA used to code the autopsy cause of death if the autopsy cause of death is mapped to a lower-level term. Note: If AutopsyCauseOfDeath is mapped to the user-entered cause, do not map this field.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application

3.3.7.5 Subject_CauseOfDeath Data Set

Data Series in the Subject_CauseOfDeath Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
CauseOfDeath	Reported cause of death. This can be a repeating itemset. For more information, see Section 3.3.4.3. Map to the user-entered verbatim or to the encoded MedDRA lower-level term.	Case Form / Patient / Death / Cause of Death / Preferred Term Case Form / Events / Seriousness Criteria / Death / Details / Cause of Death / Preferred Term
CauseOfDeath MedDRAVersion	Version of MedDRA used to code the cause of death if the cause of death is mapped to a lower-level term. Note: If CauseOfDeath is mapped to the user-entered cause, do not map this field.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application

3.3.7.6 Subject_ConMed Data Set

Note:

How you map dosage frequency data depends on your study design. For more information, see Section 3.3.7.7.

Data Series in the Subject_ConMed Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
ConMed_SeparateDoseCount	Number of separate dosages	Case Form / Products / Dosage Regimens / Frequency
ConMed_DosageIntervalUnit Count	Number of units in the dosage interval	Case Form / Products / Dosage Regimens / Frequency
ConMed_DosageIntervalUnit	Units in which the dosage interval is defined (for example days, months)	Case Form / Products / Dosage Regimens / Frequency
ConMed_DosageFrequency	Frequency that the dosage was given to the patient (for example, 2 times per day).	Case Form / Products / Dosage Regimens / Frequency
ConMed_Dosage	Number of units in the dosage (for example, 20)	Case Form / Products / Dosage Regimens / Dose Units
ConMed_DosageUnit	Units in which the dosage is defined (for example, mg)	Case Form / Products / Dosage Regimens / Daily Dosage Units
ConMed_CumulativeDosage	The total dose administered before the first sign, symptom, or reaction occurred.	Case Form / Products / Total Dose to Primary Event
ConMed_CumulativeDosage Unit	Units in the cumulative dosage (for example, mg).	Case Form / Products / Total Dose to Primary Event
ConMed_DosageDescription	Description of the dosage. Use this item if it is not possible to provide structured dosage information.	Case Form / Products / Dosage Regimens / Dose Description
ConMed_DosageFormCode	Pharmaceutical form of the dosage (for example, tablets, capsules, syrup).	Case Form / Products / Product Information / Formulation
ConMed_AdministrationRoute Code	Route of administration of the drug (for example, intravenous, oral).	Case Form / Products / Dosage Regimens / Patient Route of Administration
ConMed_StartDateTime	Start date of the dosing regimen.	Case Form / Products / Dosage Regimens / Start Date/Time
ConMed_EndDateTime	End date of the dosing regimen.	Case Form / Products / Dosage Regimens / Stop Date/Time
ConMed_RecurReAdministration Code	Indicates whether the adverse event recurred when the drug was readministered (Yes, No, Unknown).	Case Form / Products / Product Details / Rechallenge Results
ConMed_ActionTakenCode	Action taken by the doctor or patient with the drug in response to the adverse event.	Case Form / Products / Product Details / Action Taken
ConMed_AdditionalInformation	Additional information about the concomitant medication.	Case Form / Products / Notes
ConMed_MedicinalProduct Name	Proprietary medicinal name of the concomitant medication.	Case Form / Products / Product Information / Product Name
ConMed_Indication	Reason that the concomitant medication was prescribed. Map to the user-entered verbatim or to the encoded MedDRA lower-level term.	Case Form / Products / Product Indication / Coded Indication
ConMed_IndicationMedDRA Version	Version of MedDRA used to code the indication if the indication is mapped to a lower-level term.Note: If Indication is mapped to text entered by the user, do not map this field.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application
ConMed_ParentAdministration RouteCode	If the patient is a fetus, the route by which the drug was administered to the parent.	Case Form / Products / Dosage Regimens / Parent Route of Administration
ConMed_FirstDoseToOnset Duration	If the exact start and end dates are not known or the interval is less than one day, the time between the first administration of the drug and the onset of the adverse advent.	Case Form / Products / Time Interval Between First Dose/Primary Event
ConMed_FirstDoseToOnset DurationUnit	Unit for first dose to onset duration (for example, minutes, hours).	Case Form / Products / Time Interval Between First Dose/Primary Event
ConMed_LastDoseToOnset Duration	If the exact start and end dates are not known or the interval is less than one day, the time between the last administration of the drug and the onset of the adverse advent.	Case Form / Products / Time Interval Between Last Dose/Primary Event
ConMed_LastDoseToOnset DurationUnit	Unit for last dose to onset duration (for example, minutes, hours).	Case Form / Products / Time Interval Between Last Dose/Primary Event
ConMed_TreatmentDuration	Duration of the dosing regimen if exact start and dates are not known.	Case Form / Products / Dosage Regimens / Duration of Regimen
ConMed_TreatmentDuration Unit	Unit for the treatment duration (for example, days, months).	Case Form / Products / Duration of Administration
ConMed_OngoingIndicator	Indicates whether the patient is still taking the concomitant medication.	Case Form / Products / Product Detail / Ongoing

3.3.7.7 Mapping Dosage Frequency Items in the Subject_ConMed Data Set

The Subject_ConMed data set includes the following data series for mapping dosage frequency:

• Dosage quantity:

  • ConMed_Dosage - Number of units in the dosage (for example, 20)

  • ConMed_DosageUnit - Units in which the dosage is defined (for example, mg)

  • ConMed_SeparateDoseCount - Number of separate dosages

• Timing interval of dosage administration:

  • ConMed_DosageIntervalUnitCount - Number of units in the dosage interval

  • ConMed_DosageIntervalUnit - Units in which the dosage interval is defined (for example days, months)

• Complete dosage information selected from a codelist:

  • ConMed_DosageFrequency - Frequency that the dosage was given to the patient (for example, 2 times per day).

The way you map to these data series depends on how you collect dosage frequency in the study.

• Single item with a codelist - If users select all components of the dosage frequency as codelist items (for example, 2 times per day, 3 times per day, twice per week), map the dosage frequency item to the ConMed_DosageFrequency data series.

• Single text item - If users enter all components of the dosage frequency as text (for example, if they enter 3mg, once every 2 days):

  • Create hidden items to capture each component of the dosage frequency definition, and populate those items with a rule

  • Map the hidden items representing the components of the dosage frequency definition to the appropriate data series. In the above example, the values that would be transmitted are:

    • ConMed_Dosage - 3

    • ConMed_DosageUnit - mg

    • ConMed_SeparateDoseCount - 1 (that is, one time every two days)

    • ConMed_DosageIntervalUnitCount - 2

    • ConMed_DosageIntervalUnit - days

    If the user enters 3mg, once daily, the values transmitted are:

    • ConMed_Dosage - 3

    • ConMed_DosageUnit - mg

    • ConMed_SeparateDoseCount - 1 (that is, one time every day)

    • ConMed_DosageIntervalUnitCount - 1 (that is, daily, or every 1 day)

    • ConMed_DosageIntervalUnit - days

    If the user enters 3mg, twice daily, the values transmitted are:

    • ConMed_Dosage - 3

    • ConMed_DosageUnit - mg

    • ConMed_SeparateDoseCount - 2

    • ConMed_DosageIntervalUnitCount - 1

    • ConMed_DosageIntervalUnit - days

  • Multiple items - If users enter the dosage frequency in multiple items, map each item to the data series for the appropriate component of the dosage frequency definition.

Note:

Map dosage frequency items either to the dosage quantity and dosage interval data series or to the DosageFrequency data series, but not to all six data series. Mapping all six data series raises a warning.

3.3.7.8 Subject_Death Data Set

Data Series in the Subject_Death Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
DeathDateTime	Date of patient death.	Case Form / Patient / Death / Date of Death Case Form / Events / Seriousness Criteria / Death / Details / Date of Death
PatientAutopsyCompleted Code	Indicates whether an autopsy was performed (Yes, No, Unknown).	Case Form / Patient / Death / Autopsy Done, Autopsy Results Available Case Form / Events / Seriousness Criteria / Death / Details / Autopsy Done, Autopsy Results Available

3.3.7.9 Subject_LabTest Data Set

Data Series in the Subject_LabTest Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
Test_DateTime	Date and time of the lab test or procedure.	Case Form / Patient / Lab Data / Lab Data / Date
Test_Name	Name of the lab test or procedure performed to diagnose or confirm the adverse event or to investigate a non-drug cause.	Case Form / Patient / Lab Data / Lab Data / Test
Test_Result	Result of the lab test or procedure.	Case Form / Patient / Lab Data / Lab Data / Results
Test_UOMCode	Unit of measure for the result of the lab test or procedure.	Case Form / Patient / Lab Data / Lab Data / Units
Test_NormalLowRange	Normal low range for the lab test or procedure.	Case Form / Patient / Lab Data / Lab Data / Norm Low
Test_NormalHighRange	Normal high range for the lab test or procedure.	Case Form / Patient / Lab Data / Lab Data / Norm High
Test_AdditionalInformation AvailabilityIndicator	Indicates whether additional information is available for the lab test or procedure.	Case Form / Patient / Lab Data / Lab Data / Notes

3.3.7.10 Subject_MedicalHistory Data Set

Data Series in the Subject_MedicalHistory Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
MedicalHistory_Name	Condition, disease, or surgical procedure in the patient's medical history. Map to the user-entered verbatim or to the encoded MedDRA lower-level term.	Case Form / Patient / Other Relevant History / Description
MedicalHistory_MedDRA Version	Version of MedDRA used to code the medical history name if the medical history name is mapped to a lower-level term. Note: If MedicalHistory_Name is mapped to a text field entered by the user, do not map this field.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application
MedicalHistory_StartDateTime	Start date of the condition, disease, or surgical procedure.	Case Form / Patient / Other Relevant History / Start Date
MedicalHistory_Continuing Indicator	Indicates whether the patient still has the condition or disease (Yes, No, Unknown).	Case Form / Patient / Other Relevant History / Ongoing
MedicalHistory_EndDateTime	End date of the condition, disease, or surgical procedure.	Case Form / Patient / Other Relevant History / Stop Date
MedicalHistory_Comment	Description of the relevant medical history for the patient. Used when more structured information such as dates and terms is unknown.	Case Form / Patient / Other Relevant History / Note

3.3.7.11 Subject_PastDrugHistory Data Set

Data Series in the Subject_PastDrugHistory Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
PastDrugHistory_DrugName	Name of a drug previously taken but not used concomitantly and not potentially involved in the adverse event.	Case Form / Patient / Other Relevant History / Description
PastDrugHistory_StartDate Time	Date when the previously taken drug was started.	Case Form / Patient / Other Relevant History / Start Date
PastDrugHistory_EndDate Time	Date when the last dose of the previously taken drug was given.	Case Form / Patient / Other Relevant History / Stop Date
PastDrugHistory_Drug Indication	Reason for taking the previously taken drug. Map to the user-entered verbatim or to the encoded MedDRA lower-level term.	Case Form / Patient / Other Relevant History / Indication
PastDrugHistory_Indication MedDRAVersion	Version of MedDRA used to code the indication if the indication is mapped to a lower-level term. Note: If Indication is mapped to a text field entered by the user, do not map this field.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application
PastDrugHistory_Drug Reaction	Adverse event experienced when taking the previously taken drug. Map to the user-entered verbatim or to the encoded MedDRA lower-level term.	Case Form / Patient / Other Relevant History / Reaction
PastDrugHistory_Reaction MedDRAVersion	Version of MedDRA used to code the reaction if the reaction is mapped to a lower-level term. Note: If Reaction is mapped to a text field entered by the user, do not map this field.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application

3.3.7.12 Subject_SuspectDrug Data Set

Note:

How you map dosage frequency data depends on your study design. For more information, see Section 3.3.7.13.

Data Series in the Subject_SuspectDrug Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
SuspectDrug_SeparateDose Count	Number of separate dosages	Case Form / Products / Dosage Regimens / Frequency
SuspectDrug_DosageInterval UnitCount	Number of units in the dosage interval	Case Form / Products / Dosage Regimens / Frequency
SuspectDrug_DosageIntervalUnit	Units in which the dosage interval is defined (for example days, months)	Case Form / Products / Dosage Regimens / Frequency
SuspectDrug_Dosage Frequency	Frequency that the dosage was given to the patient (for example, 2 times per day).	Case Form / Products / Dosage Regimens / Frequency
SuspectDrug_Dosage	Number of units in the dosage (for example, 20)	Case Form / Products / Dosage Regimens / Dose Units
SuspectDrug_DosageUnit	Units in which the dosage is defined (for example, mg)	Case Form / Products / Dosage Regimens / Daily Dosage Units
SuspectDrug_Cumulative Dosage	The total dose administered before the first sign, symptom, or reaction occurred.	Case Form / Products / Total Dose to Primary Event
SuspectDrug_Cumulative DosageUnit	Units in the cumulative dosage (for example, mg).	Case Form / Products / Total Dose to Primary Event
SuspectDrug_Dosage Description	Description of the dosage. Use this item if it is not possible to provide structured dosage information.	Case Form / Products / Dosage Regimens / Dose Description
SuspectDrug_DosageForm Code	Pharmaceutical form of the dosage (for example, tablets, capsules, syrup).	Case Form / Products / Product Information / Formulation
SuspectDrug_Administration RouteCode	Route of administration of the drug (for example, intravenous, oral).	Case Form / Products / Dosage Regimens / Patient Route of Administration
SuspectDrug_Gestation PeriodAtExposure	Gestation period at time of exposure to the drug.	Case Form / Patient / Patient Information / Pregnancy / Weeks at Exposure or Trimester of Exposure
SuspectDrug_Gestation PeriodAtExposureUnit	Unit in which gestation period at exposure is reported (for example, trimester, week).	Case Form / Patient / Patient Information / Pregnancy / Weeks at Exposure or Trimester of Exposure
SuspectDrug_StartDateTime	Start date of the dosing regimen.	Case Form / Products / Dosage Regimens / Start Date/Time
SuspectDrug_FirstDoseTo OnsetDuration	If the exact start and end dates are not known or the interval is less than one day, the time between the first administration of the drug and the onset of the adverse advent.	Case Form / Products / Time Interval Between First Dose/Primary Event
SuspectDrug_FirstDosageTo OnsetDurationUnit	Unit for first dose to onset duration (for example, minutes, hours).	Case Form / Products / Time Interval Between First Dose/Primary Event
SuspectDrug_LastDoseTo OnsetDuration	If the exact start and end dates are not known or the interval is less than one day, the time between the last administration of the drug and the onset of the adverse advent.	Case Form / Products / Time Interval Between Last Dose/Primary Event
SuspectDrug_LastDoseTo OnsetDurationUnit	Unit for last dose to onset duration (for example, minutes, hours).	Case Form / Products / Time Interval Between Last Dose/Primary Event
SuspectDrug_EndDateTime	End date of the dosing regimen.	Case Form / Products / Dosage Regimens / Stop Date/Time
SuspectDrug_Recur ReAdministrationCode	Indicates whether the adverse event recurred when the drug was readministered (Yes, No, Unknown).	Case Form / Products / Product Details / Rechallenge Results
SuspectDrug_ActionTaken Code	Action taken by the doctor or patient with the drug in response to the adverse event.	Case Form / Products / Product Details / Action Taken
SuspectDrug_Additional Information	Additional information about the drug.	Case Form / Products / Notes
SuspectDrug_Medicinal ProductName	Proprietary name of the medicinal product name. If SuspectDrug_MedicinalProduct Name is not mapped, the Sponsor Drug Name is transmitted.	Case Form / Products / Product Information / Product Name
SuspectDrug_Indication	Reason that the drug was prescribed. Map to the user-entered verbatim or to the encoded MedDRA lower-level term.	Case Form / Products / Product Indication / Coded Indication
SuspectDrug_Indication MedDRAVersion	Version of MedDRA used to code the indication if the indication is mapped to a lower-level term. Note: If Indication is mapped to text entered by the user, do not map this field.	For items to be encoded in the Oracle Argus Safety application, MedDRA version is required by the format used for transmitting data but does not appear in the Oracle Argus Safety application
SuspectDrug_BatchNumber	Batch or lot number of the drug.	Case Form / Products / Dosage Regimens / Batch / Lot #
SuspectDrug_Parent AdministrationRouteCode	If the patient is a fetus, the route by which the drug was administered to the parent.	Case Form / Products / Dosage Regimens / Parent Route of Administration
SuspectDrug_Treatment Duration	Duration of the dosing regimen if exact start and dates are not known.	Case Form / Products / Dosage Regimens / Duration of Regimen
SuspectDrug_Treatment DurationUnit	Unit for the treatment duration (for example, days, months).	Case Form / Products / Duration of Administration
SuspectDrug_Overdose Indicator	Indicates whether the patient took more than the prescribed amount of the drug before experiencing the adverse event.	Case Form / Products / Product Detail / Overdose
SuspectDrug_AbuseIndicator	Indicates whether the patient abused the drug (for example, took pain medication without pain).	Case Form / Products / Product Detail / Abuse
SuspectDrug_Tampering Indicator	Indicates whether the product appeared to be tampered with before it was taken.	Case Form / Products / Product Detail / Tampering
SuspectDrug_TakenPreviously AndToleratedCode	Indicates whether the patient had taken the drug previously and had tolerated it (Yes, No, Unknown).	Case Form / Products / Product Detail / Taken Previously And Tolerated
SuspectDrug_InteractingIndicator	Indicates whether it is believed that the interaction of this non-study co-suspect drug with the study drug(s) caused the adverse event.	Case Form / Products / Product Detail/ Interacting
SuspectDrug_Ongoing Indicator	Indicates whether the patient is still taking the drug.	Case Form / Products / Product Detail / Ongoing

3.3.7.13 Mapping Dosage Frequency Items in the Subject_SuspectDrug Data Set

The Subject_SuspectDrug data set includes the following data series for mapping dosage frequency:

• Dosage quantity:

  • SuspectDrug_Dosage - Number of units in the dosage (for example, 20)

  • SuspectDrug_DosageUnit - Units in which the dosage is defined (for example, mg)

  • SuspectDrug_SeparateDoseCount - Number of separate dosages

• Timing interval of dosage administration:

  • SuspectDrug_DosageIntervalUnitCount - Number of units in the dosage interval

  • SuspectDrug_DosageIntervalUnit - Units in which the dosage interval is defined (for example days, months)

• Complete dosage frequency information selected from a codelist:

  • SuspectDrug_DosageFrequency - Frequency that the dosage was given to the patient (for example, 2 times per day).

The way you map to these data series depends on how you collect dosage frequency in the study.

• Single item with a codelist- If users select all components of the dosage frequency as codelist items (for example, 2 times per day, 3 times per day, twice per week), map the dosage frequency item to the SuspectDrug_DosageFrequency data series.

• Single text item - If users enter all components of the dosage frequency as text (for example, if they enter 3mg, twice daily):

  • Create hidden items to capture each component of the dosage frequency definition, and populate those items with a rule

  • Map the hidden items representing the components of the dosage frequency definition to the appropriate data series. In the above example, the values that would be transmitted are:

    • SuspectDrug_Dosage - 3

    • SuspectDrug_DosageUnit - mg

    • SuspectDrug_SeparateDoseCount - 1 (that is, one time every two days)

    • SuspectDrug_DosageIntervalUnitCount - 2

    • SuspectDrug_DosageIntervalUnit - days

    If the user enters 3mg, once daily, the values transmitted are:

    • SuspectDrug_Dosage - 3

    • SuspectDrug_DosageUnit - mg

    • SuspectDrug_SeparateDoseCount - 1 (that is, one time every day)

    • SuspectDrug_DosageIntervalUnitCount - 1 (that is, daily, or every 1 day)

    • SuspectDrug_DosageIntervalUnit - days

    If the user enters 3mg, twice daily, the values transmitted are:

    • SuspectDrug_Dosage - 3

    • SuspectDrug_DosageUnit - mg

    • SuspectDrug_SeparateDoseCount - 2

    • SuspectDrug_DosageIntervalUnitCount - 1

    • SuspectDrug_DosageIntervalUnit - days

• Multiple items - If users enter the dosage frequency in multiple items, map each item to the data series for the appropriate component of the dosage frequency definition.

  Note:

  Map dosage frequency items either to the dosage quantity and dosage interval data series or to the DosageFrequency data series, but not to all six data series. Mapping all six data series raises a warning.

3.3.7.14 Subject_SuspectDrug_ReactionRecurrence Data Set

Data Series in the Subject_SuspectDrug_ReactionRecurrence Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
SuspectDrug_RecurredAE	MedDRA lower-level term (LLT) for the reaction that recurred when the drug was readministered.	Case Form / Events / Associated with Rechallenge? / Product

3.3.7.15 Subject_SuspectDrug_ReactionRelatedness Data Set

Data Series in the Subject_SuspectDrug_ReactionRelatedness Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
SuspectDrug_Assessment	Source of assessment (for example, investigator).	Case Form / Events / Assessments / Causality / As Reported, As Determined
SuspectDrug_Assessment	Method of assessment (for example, global introspection).	Case Form / Events / Assessments / Causality / As Reported, As Determined
SuspectDrug_Assessment	Result of assessment (for example, related, possibly related).	Case Form / Events / Assessments / Causality / As Reported, As Determined
SuspectDrug_ReactionID	MedDRA lower-level term (LLT) for the reaction that was assessed for relatedness to the drug.	Case Form / Events / Assessments / Causality / As Reported, As Determined

Note:

The value of the item mapped to the SuspectDrug_AssessmentSource data series for an adverse event that has been coded determines whether the reaction relatedness data for the adverse event specified in the SuspectDrug_ReactionID and SuspectDrug_MedicinalProductName data series appears as Determined Causality or Reported Causality in the Oracle Argus Safety application.

• PHARMACEUTICAL COMPANY - As Determined

• Any other value - As Reported

3.3.7.16 MedicalDevice Data Set

Data Series in the MedicalDevice Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
DeviceOperatorCode	Type of person operating or using the suspect medical device on the patient at the time of the event (for example, Health Professional, Lay User, Patient).	Case Form / Products / Device Information / Operator of Device
ManufacturedDateTime	Date that the medical device was manufactured.	Case Form / Products / Device Information / Date of Mfr
ExpirationDateTime	Expiration date of the medical device.	Case Form / Products / Device Information / Expiration Date
ImplantedDateTime	For a medical device that is implanted in the patient, the implant date or best estimate.	Case Form / Products / Device Information / Date Implanted
ExplantedDateTime	If an implant medical device was removed from the patient, the explant date or best estimate.	Case Form / Products / Device Information / Date Explanted
EvaluatedIndicator	Indicates whether the medical device was evaluated by the manufacturer after being returned to the manufacturer.	Case Form / Products / Device MedWatch Info / Device evaluated by mfr?
EvaluationAvailability IndicationCode	Indicates whether the medical device is available for evaluation by the manufacturer (Yes, No, Returned to Manufacturer).	Case Form / Products / Device Information / Device Available for Evaluation
ReprocessedSingleUseDevice IndicationCode	Indicates whether the medical device was labeled for single use and was reused on the patient (Yes, No, Unknown).	Case Form / Products / Device MedWatch Info / Is this a Single use device that was Reprocessed and Reused on a patient
DeviceReuseCode	Indicates whether the use of the suspect medical device was the initial use, reuse, or unknown.	Case Form / Products / Device MedWatch Info / Usage of Device
ReturnedDate	Date the medical device was returned to the manufacturer.	Case Form / Products / Device Information / Returned to Manufacturer on
ManufacturerNarrative	Additional information, evaluation, or clarification provided by the manufacturer of the suspect medical device.	Case Form / Products / Device MedWatch Info / Additional Manufacturer Narrative
MedicalDeviceName	Trade or proprietary name of the suspect medical device as used in the product labeling or catalog. If this item is not mapped or if a value is not entered, the value in the SponsorStudyDrug item is used.	Case Form / Products / Device / Product Name
ApproximateAgeMeasure	Approximate age of the medical device.	Case Form / Products / Device Information / Device Age (Approx.)
ApproximateAgeMeasureUnit	Unit for the ApproximateAgeMeasure value (for example, years, months).	Case Form / Products / Device Information / Device Age (Approx.)
LotNumber	Unique number assigned to the lot that the medical device was part of. This number is on the packaging.	Case Form / Products / Device Information / Lot #
ModelNumber	Model number listed on the medical device label or accompanying packaging.	Case Form / Products / Device Information / Model #
CatalogNumber	Number used for ordering the medical device as the number appears in the manufacturer's catalog.	Case Form / Products / Device Information / Catalog #
SerialNumber	Unique identification number for the medical device as assigned by the manufacturer.	Case Form / Products / Device Information / Serial #
AdverseEventIndicator	Indicates that the medical device is suspected to have caused an adverse outcome in a patient.	Case Form / Product / Device / Med Watch Info / Adverse Event check box
ProductProblemIndicator	Indicates that the defect or malfunction in a product could lead to death or serious injury.	Case Form / Product / Device / Med Watch Info / Product Problem check box

3.3.7.17 MedicalDevice_Evaluation Data Set

Data Series in the MedicalDevice_Evaluation Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
MethodCode1	Applicable code from the Device coding manual for Form 3500A describing the method used to evaluate the medical device.	Case Form / Products / Device MedWatch Info / Evaluation Codes first row
MethodCode2	Applicable code from the Device coding manual for Form 3500A describing the method used to evaluate the medical device.	Case Form / Products / Device MedWatch Info / Evaluation Codes first row
MethodCode3	Applicable code from the Device coding manual for Form 3500A describing the method used to evaluate the medical device.	Case Form / Products / Device MedWatch Info / Evaluation Codes first row
MethodCode4	Applicable code from the Device coding manual for Form 3500A describing the method used to evaluate the medical device.	Case Form / Products / Device MedWatch Info / Evaluation Codes first row
ResultCode1	Applicable code from the Device coding manual for Form 3500A describing the result of the evaluation of the medical device (for example, alarms inadequate or absent, computer hardware problem).	Case Form / Products / Device MedWatch Info / Evaluation Codes second row
ResultCode2	Applicable code from the Device coding manual for Form 3500A describing the result of the evaluation of the medical device (for example, alarms inadequate or absent, computer hardware problem).	Case Form / Products / Device MedWatch Info / Evaluation Codes second row
ResultCode3	Applicable code from the Device coding manual for Form 3500A describing the result of the evaluation of the medical device (for example, alarms inadequate or absent, computer hardware problem).	Case Form / Products / Device MedWatch Info / Evaluation Codes second row
ResultCode4	Applicable code from the Device coding manual for Form 3500A describing the result of the evaluation of the medical device (for example, alarms inadequate or absent, computer hardware problem).	Case Form / Products / Device MedWatch Info / Evaluation Codes second row
ConclusionCode1	Applicable code from the Device coding manual for Form 3500A describing the conclusion based on the results of the evaluation of the medical device (for example, device evaluated and alleged failure could not be duplicated, device failure directly caused adverse event).	Case Form / Products / Device MedWatch Info / Evaluation Codes third row
ConclusionCode2	Applicable code from the Device coding manual for Form 3500A describing the conclusion based on the results of the evaluation of the medical device (for example, device evaluated and alleged failure could not be duplicated, device failure directly caused adverse event).	Case Form / Products / Device MedWatch Info / Evaluation Codes third row
ConclusionCode3	Applicable code from the Device coding manual for Form 3500A describing the conclusion based on the results of the evaluation of the medical device (for example, device evaluated and alleged failure could not be duplicated, device failure directly caused adverse event).	Case Form / Products / Device MedWatch Info / Evaluation Codes third row
ConclusionCode4	Applicable code from the Device coding manual for Form 3500A describing the conclusion based on the results of the evaluation of the medical device (for example, device evaluated and alleged failure could not be duplicated, device failure directly caused adverse event).	Case Form / Products / Device MedWatch Info / Evaluation Codes third row

3.3.7.18 MedicalDevice_EventProblem Data Set

Data Series in the MedicalDevice_EventProblem Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
PatientCode1	Patient code from the FDA Device Coding Manual for Form 3500A indicating the effect that an event may have had on the patient, including signs, symptoms and syndromes, or diagnosis.	Case Form / Analysis / MedWatchInfo / FDA Codes
PatientCode2	Patient code from the FDA Device Coding Manual for Form 3500A indicating the effect that an event may have had on the patient, including signs, symptoms and syndromes, or diagnosis.	Case Form / Analysis / MedWatchInfo / FDA Codes
PatientCode3	Patient code from the FDA Device Coding Manual for Form 3500A indicating the effect that an event may have had on the patient, including signs, symptoms and syndromes, or diagnosis.	Case Form / Analysis / MedWatchInfo / FDA Codes
DeviceCode1	Device code from the FDA Device Coding Manual for Form 3500A describing the device failure or issue related to the medical device that was encountered during the event.	Case Form / Analysis / MedWatchInfo / FDA Codes
DeviceCode2	Device code from the FDA Device Coding Manual for Form 3500A describing the device failure or issue related to the medical device that was encountered during the event.	Case Form / Analysis / MedWatchInfo / FDA Codes
DeviceCode3	Device code from the FDA Device Coding Manual for Form 3500A describing the device failure or issue related to the medical device that was encountered during the event.	Case Form / Analysis / MedWatchInfo / FDA Codes

3.3.7.19 MedicalDevice_RemedialAction Data Set

Data Series in the MedicalDevice_RemedialAction Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
RemedialAction_ActionCode	Remedial action that was taken (for example, recall, repair, replace, relabeling).	Case Form / Products / Device MedWatch Info / Remedial Action Taken
RemedialAction_Comment	Description of the remedial action. For example, if the ActionCode is Other, you can use the Comment item to describe the specific action in detail.	Case Form / Products / Device MedWatch Info / Remedial Action Taken Other

3.3.7.20 MedicalDevice_Reprocessor Data Set

Data Series in the MedicalDevice_Reprocessor Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
Reprocessor_ReprocessorName	Name of the company or organization that reprocessed the medical device.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_LineOne	Reprocessor street address.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_LineTwo	Reprocessor street address.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_LineThree	Reprocessor street address.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_LineFour	Reprocessor street address.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_LineFive	Reprocessor street address.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_CityName	City in which the reprocessor is located.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_StateName	State in which the reprocessor is located.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_Province Name	Province in which the reprocessor is located.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_Country Code	Country in which the reprocessor is located.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor
Reprocessor_Address_Postal Code	Postal code of the reprocessor location.	Case Form / Products / Device MedWatch Info / Name and Address of Reprocessor

3.3.7.21 Reporter Data Set

Data Series in the Reporter Data Set

Data Series Title	Description	Location in Oracle Argus Safety Application
QualificationCode	Qualification of the reporter of the case, for example, physician, pharmacist.	Case Form / General / Reporter Information / Reporter Type Note: If this field is not collected in the InForm study or is not mapped, the InForm Publisher application sends the value Physician to Oracle Argus Safety application.
JobTitle	Occupation of the reporter of the case.	Case Form / Reporter Information / Occupation

3.4 Setting up Participating Applications

This section describes how to set up Oracle Argus Safety and Oracle Health Sciences InForm to utilize the integration.

3.4.1 Setting up Oracle Health Sciences InForm

3.4.1.1 Configuring Oracle Health Sciences InForm Publisher

For setting up Oracle Health Sciences InForm Publisher for the integration, see Oracle® Health Sciences InForm Publisher On Demand 1.0.2.0 Installation Guide.

3.4.1.2 Registering the Trial with Oracle Health Sciences InForm Adapter

For registering the trial with Oracle Health Sciences InForm Adapter, see InForm Adapter 1.3.6 Interfaces Guide.

3.4.2 Setting up Oracle Argus Safety

This section describes the tasks and general procedures that you must complete to set up Oracle Argus Safety.

The Argus Interchange feature requires some information to be entered in the Argus Console for the Frequency codelist. Therefore, before using the integration the Argus administrator must go to the Argus Console and navigate to the Frequency codelist.

For each value that exists in the codelist for Frequency, enter the following three fields:

• Number of doses per day - Enter the number of doses to be taken each day.

• Dose - Enter amount of dose to be taken each time.

• Every N days (where you enter N) - Enter interval of dosage frequency (such as Every 2 Hours, Every 5 Days, Every 6 Weeks.

3.5 Configuration Properties for the Adverse Event: InForm and Argus Safety Integration

The table below describes the configuration properties.

Service Name	Property Name	Value	Description
ReportDrugSafetyReportInFormReqABCSImpl	Default.SystemID	INFORM_01	Default System ID is associated with this service. It is used for searching the DVMs, and XREFS when no other system IDs are found in the system registry.
ReportDrugSafetyReportInFormReqABCSImpl	INFORM_01.InFormURL	${ participatingapplications .inform.server.internetprotocol }${ participatingapplications .inform.server. url }:${ participatingapplications.inform.server.port }	URL to access InForm application. This is constructed from values entered in the Configuration Wizard.
ReportDrugSafetyReportInFormReqABCSImpl	INFORM_01.SenderCompanyName		Short abbreviation for your company name. This is used in the Sender Message ID required by E2B standard. This is populated by the value entered in the Configuration Wizard.
ReportDrugSafetyReportInFormReqABCSImpl	ABCSExtension. PreXformABMtoEBM	false (default), true	Enables the custom extension prior to the execution of transformation of Application Business Message (ABM) to Enterprise Business Message (EBM).
ReportDrugSafetyReportInFormReqABCSImpl	ABCSExtension.PreInvokeEBS	false (default), true	Enables the custom extension prior to the invocation of the Enterprise Business Service (EBS).
ReportDrugSafetyReportInFormReqABCSImpl	Routing.HealthSciencesDrugSafetyReportEBS.ReportDrugSafetyReport.RouteToCAVS	false (default), true	To test the requester Application Business Connector Service (ABCS) or when the provider ABCS is not available, you would want the requester ABCS to call a simulator instead of actual Oracle AIA services.
ReportDrugSafetyReportInFormReqABCSImpl	Routing.HealthSciencesDrugSafetyReportEBS.ReportDrugSafetyReport.CAVS.EndpointURI	oramds:/apps/AIAMetaData/AIAComponents/InfrastructureServiceLibrary/AIAValidationSystemServlet/asyncresponsesimulator	End point URL for CAVS, when RouteToCAVS property is set to true.
ReportDrugSafetyReportInFormReqABCSImpl	Routing.HealthSciencesDrugSafetyReportEBS.ReportDrugSafetyReport.MessageProcessingInstruction.EnvironmentCode	PRODUCTION (default), CAVS	Setting the value to PRODUCTION indicates that the request must be sent to a concrete endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS Simulator.
ReportDrugSafetyReportArgusProvABCSImpl	Default.SystemID	ARGUS_01	Default System ID associated with this service. It is used for populating the Target System ID when no routing rules match. The Target System ID is used for looking up DVMs and XREFs.
ReportDrugSafetyReportArgusProvABCSImpl	ARGUS_01.TruncateFields	warning (default), truncate, notruncation	This field is used for controlling truncation of certain fields that exceed maximum length accepted by Oracle Argus Safety. The options are described below: Warning - When set to warning, fields get truncated but a warning email about truncated fields is sent to configured users. Truncate - When set to truncation, fields get truncated but warning email is not sent. Notruncation - When set to notruncate, fields do not get truncated. Oracle Argus Safety rejects the case.
ReportDrugSafetyReportArgusProvABCSImpl	ABCSExtension.PreXformEBMtoABM	false (default), true	Enables the custom extension just prior to the execution of the EBM to ABM transformation.
ReportDrugSafetyReportArgusProvABCSImpl	ABCSExtension.PreInvokeABS	false (default), true	Enables the custom extension just prior to the invocation of the file adapter service to write the XML file to the Oracle Argus Safety Interchange server.
ReportDrugSafetyReportArgusProvABCSImpl	Routing.ReportDrugSafetyReportWriteE2BFileAdapter.RouteToCAVS	false (default), true	To test the provider ABCS or when the provider application is not available, you would want the provider ABCS to call a simulator instead of an actual provider application service.
ReportDrugSafetyReportArgusProvABCSImpl	Routing.ReportDrugSafetyReportWriteE2BFileAdapter.CAVS.EndpointURI	oramds:/apps/AIAMetaData/AIAComponents/InfrastructureServiceLibrary/AIAValidationSystemServlet/asyncresponsesimulator	End point URL for CAVS, when RouteToCAVS property is set to true.
ReportDrugSafetyReportArgusProvABCSImpl	Routing.ReportDrugSafetyReportWriteE2BFileAdapter.ARGUS_01.EndpointURI	http://${hostname}:${port}/soa-infra/services/default/ReportDrugSafetyReportWriteE2BFileAdapter/ReportDrugSafetyReportWriteE2BFileAdapter_Client_ep	End point URL for Oracle Argus Safety.
ReportDrugSafetyReportArgusProvABCSImpl	Routing.ReportDrugSafetyReportWriteE2BFileAdapter.MessageProcessingInstruction.EnvironmentCode	PRODUCTION (default), CAVS	Setting the value to PRODUCTION indicates that the request must be sent to a concrete endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS Simulator.
ReportDrugSafetyReportResponseArgusReqABCSImpl	Default.SystemID	ARGUS_01	Default System ID associated with this service. It is used for looking up DVMs, XREFS, when no other system IDs are found in the system registry.
ReportDrugSafetyReportResponseArgusReqABCSImpl	ABCSExtension.PreXformABMtoEBM	false (default), true	Enables the custom extension prior to the execution of transformation of the Argus acknowledgement message to the ReportDrugSafetyResponse message.
ReportDrugSafetyReportResponseArgusReqABCSImpl	Routing.HealthSciencesDrugSafetyReportEBSResponse.ReportDrugSafetyReportResponse.RouteToCAVS	false (default), true	To test the requester Application Business Connector Service (ABCS) or when the provider ABCS is not available, you would want the requester ABCS to call a simulator instead of actual Oracle AIA services.
ReportDrugSafetyReportResponseArgusReqABCSImpl	Routing.HealthSciencesDrugSafetyReportEBSResponse.ReportDrugSafetyReportResponse.CAVS.EndpointURI	oramds:/apps/AIAMetaData/AIAComponents/InfrastructureServiceLibrary/AIAValidationSystemServlet/asyncresponsesimulator	End point URL for CAVS, when RouteToCAVS property is set to true.
ReportDrugSafetyReportResponseArgusReqABCSImpl	Routing.HealthSciencesDrugSafetyReportEBSResponse.ReportDrugSafetyReportResponse.MessageProcessingInstruction.EnvironmentCode	PRODUCTION (default), CAVS	Setting the value to PRODUCTION indicates that the request must be sent to a concrete endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS Simulator.
ReportDrugSafetyReportResponseArgusReqABCSImpl	ABCSExtension.PreInvokeEBS	false (default), true	Enables the custom extension prior to the invocation of the Enterprise Business Service (EBS).
ReportDrugSafetyReportResponseInFormProvABCSImpl	Default.SystemID	INFORM_01	Default System ID associated with this service. It is used for populating the Target System ID when no routing rules match. The Target System ID is used for looking up DVMs and XREFs.
ReportDrugSafetyReportResponseInformProvABCSImpl	INFORM_01.InFormAdapterURL	${ participatingapplications.inform.server.adapterInternetProtocol}${ participatingapplications.inform.server.adapterhost}:${ participatingapplications.inform.server.adapterport } /${participatingapplications.inform.server.adapterpath}	URL for InForm Adapter. This is populated by the value entered in the Configuration Wizard.
ReportDrugSafetyReportResponseInformProvABCSImpl	ABCSExtension.PreXformEBMtoABM	false (default), true	Enables the custom extension prior to the execution of transformation of Enterprise Business Message (EBM) to Application Business Message (ABM).
ReportDrugSafetyReportResponseInformProvABCSImpl	Routing.InFormSafetyInterface.RouteToCAVS	false (default), true	To test the provider ABCS or when the provider application is not available, you would want the provider ABCS to call a simulator instead of an actual provider application service.
ReportDrugSafetyReportResponseInformProvABCSImpl	Routing. InFormSafetyInterface .CAVS.EndpointURI	oramds:/apps/AIAMetaData/AIAComponents/InfrastructureServiceLibrary/AIAValidationSystemServlet/syncresponsesimulator	End point URL for CAVS, when RouteToCAVS property is set to true.
ReportDrugSafetyReportResponseInformProvABCSImpl	Routing.InFormSafetyInterface .EnvironmentCode	PRODUCTION (default), CAVS	Setting the value to PRODUCTION indicates that the request must be sent to a concrete endpoint. Setting the value to CAVS indicates that the request must be sent to CAVS Simulator.
ReportDrugSafetyReportResponseInformProvABCSImpl	ABCSExtension.PreInvokeABS	false (default), true	Enables the custom extension just prior to the invocation of InForm Adapter web services.

3.6 Updating Server Information for Oracle Health Sciences InForm and Oracle Argus Safety

At times, applications are moved to new servers or databases for various reasons. This section describes how to update the information that was provided during install time when the integration is already installed and deployed.

3.6.1 Modifying Information About InForm Trial

To modify information about InForm Trial URL, perform either of the following methods:

Whenever InForm Adapter information such as URL, transaction user name are changed for a given trial, some configurations must be updated to ensure acknowledgement flow works correctly. Follow either of the following methods:

1. If trial URL is configured in HS_TRIAL_SAFETY_CONFIG.dvm for a given trial, update the INFORM_URL cell value in the DVM.

   You can update HS_TRIAL_SAFETY_CONFIG.dvm using the SOA composer application.

   For more information about working with DVMs, see Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite 11g Release 1.

2. If trial URL is configured using the Configuration Wizard, AIAConfigurationProperties.xml needs to be updated.

   Update $AIA_INSTANCE/AIAMetaData/config/AIAConfigurationProperties.xml using the following steps:

   1. Locate the property INFORM_URL under <ServiceConfiguration> element, where serviceName attribute value is http://xmlns.oracle.com/ABCSImpl/InForm/Core/ReportDrugSafetyReportInFormReqABCSImpl/V1}ReportDrugSafetyReportInFormReqABCSImpl

   2. Update the property value to the new value.

   3. Save the file.

   4. Upload the modified AIAConfigurationProperties.xml file to the MDS.

   5. Navigate to the $AIA_INSTANCE/config directory.

   6. Copy UpdateMetaDataDp.xml to a backup file.

   7. Edit UpdateMetaDataDp.xml file as follows:

      <?xml version="1.0" standalone="yes"?>
      <DeploymentPlan component="Metadata" version="3.0">
      <Configurations>
      <UpdateMetadata wlserver="fp">
      <fileset dir="${AIA_INSTANCE}">
      <include name="config/AIAInstallProperties.xml"/>
      </fileset>
      </UpdateMetadata>
      </Configurations>
      </DeploymentPlan>
      

   8. Navigate to the $AIA_INSTANCE/bin directory.

   9. Execute the following commands:

      For Windows: execute aiaenv.bat

      ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml

      For Linux: source aiaenv.sh

      ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml

   10. Wait till you see a build successful result.

3.6.2 Modifying Information About InForm

To modify information about InForm, perform either of the following methods.

Whenever InForm Adapter information such as URL, transaction user name are changed for a given trial, some configurations must be updated to ensure acknowledgement flow works correctly. Follow either of the following methods:

1. If InForm Adapter information is configured in HS_TRIAL_SAFETY_CONFIG.dvm for a given trial, update the INFORM_ADAPTER_URL and INFORM_ ADAPTER_TRANS_USER cell values in the DVM.

   You can update HS_TRIAL_SAFETY_CONFIG.dvm using the SOA composer application.

   For more information about working with DVMs, see Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite 11g Release 1.

2. Update the AIAConfigurationProperties.xml file if this information is configured using the Configuration Wizard.

   Update $AIA_INSTANCE/AIAMetaData/config/AIAConfigurationProperties.xml using the following steps:

   1. Locate the properties INFORM_01. InFormAdapterURL and INFORM_01. InFormAdapterTransUser.

      These properties are present under <ServiceConfiguration> element, where serviceName attribute value is http://xmlns.oracle.com/ABCSImpl/InForm/Core/ReportDrugSafetyReportResponseInFormProvABCSImpl/V1}ReportDrugSafetyReportResponseInFormProvABCSImpl

   2. Update the property value to the new value.

   3. Save the file.

   4. Upload the modified AIAConfigurationProperties.xml file to the MDS.

   5. Navigate to $AIA_INSTANCE/config.

   6. Copy UpdateMetaDataDp.xml to a backup file.

   7. Edit the UpdateMetaDataDp.xml file as follows:

      <?xml version="1.0" standalone="yes"?>
      <DeploymentPlan component="Metadata" version="3.0">
      <Configurations>
      <UpdateMetadata wlserver="fp">
      <fileset dir="${AIA_INSTANCE}">
      <include name="config/AIAInstallProperties.xml"/>
      </fileset>
      </UpdateMetadata>
      </Configurations>
      </DeploymentPlan>
      

   8. Navigate to the $AIA_INSTANCE/bin directory.

   9. Execute the following commands:

      For Windows: execute aiaenv.bat

      ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml

      For Linux: source aiaenv.sh

      ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml

   10. Wait till you see a build successful result.

3.6.2.1 Modifying the InForm Adapter Authentication Credential

If InForm Adapter authentication user name or password values change, these values need to be updated in the SOA server credential store. To update an existing key, perform the following:

1. Open Enterprise Manager.

2. Navigate to Farm_soa_domain > WebLogic Domain > soa_domain.

3. Click on the WebLogic Domain drop-down list and select Security > Credentials.

4. In the Credential Store Provider screen, select oracle.wsm.security and expand it.

5. Select the name of key specified in INFORM_ADAPTER_AUTH_KEY in HS_TRIAL_SAFETY_CONFIG.dvm or INFORM_01.InFormAdapterAuthKey property in the AIAConfigurationProperties.xml file.

6. Click Edit.

7. In the Edit Key screen, update the user name and password.

8. Click OK.

3.6.3 Configuring a Different Oracle Argus Safety Interchange Server

The SOA server accesses the Argus Interchange directories through a file mount. If these directories are moved to a new machine or location, the file mount must be updated to point to the new Oracle Argus Safety Interchange server.

On the integration pack SOA_server, change the file mount on SOA_server to point to the new Oracle Argus Safety Interchange (Electronic Submission Manager (ESM)) server.

If the location of DTD changes, ensure to update the DTD path property in <AIA_ HOME>/aia_instances/<AIA_instance_name>/config/AIAInstallProperties.xml on the SOA server following the instructions in Section 3.6.4.

3.6.4 Configuring a Different Folder for Oracle Argus Safety Interchange Server

To configure a different folder for Oracle Argus Safety Interchange server, perform the following.

The integration pack SOA_server has an existing folder that is mounted on to Oracle Argus Safety Interchange server. You may choose the integration pack to use a different folder on integration pack SOA_server to mount with Oracle Argus Safety Interchange server.

Update the $AIA_INSTANCE/config/AIAInstallProperties.xml file using the following steps:

1. Change the parent directory that contains in folder for E2B files, out acknowledgement files, ack-archive folder for archiving acknowledgement files.

2. Search for element <dir> and replace the value contained within the <dir> node with the new value.

   The <dir> node is present within the node structure of <properties>/<participatingapplications>/<argus>/<server>/<case>

   For more information about configuring Oracle Argus Safety, see Oracle® Health Sciences Adverse Event Integration Pack for Oracle Health Sciences InForm and Oracle Argus Safety Installation Guide.

3. If the location of the DTD file has changed on your Argus Interchange server, you must update the DTD path in the AIAInstallProperties.xml.

   Search for element <dtdsdir> and replace the value contained within the <dtdsdir> node with the new value.

   The <dtdsdir> node is present within the node structure of <properties>/<participatingapplications>/<argus>/<server>/<case>

   For more information about configuring Oracle Argus Safety, see Oracle® Health Sciences Adverse Event Integration Pack for Oracle Health Sciences InForm and Oracle Argus Safety Installation Guide.

4. Upload the modified AIAInstallProperties.xml file to the MDS before the deployment.

   1. Navigate to the $AIA_INSTANCE/config directory.

   2. Copy UpdateMetaDataDp.xml to a backup file.

   3. Edit the UpdateMetaDataDp.xml file as follows:

      <?xml version="1.0" standalone="yes"?>
      <DeploymentPlan component="Metadata" version="3.0">
      <Configurations>
      <UpdateMetadata wlserver="fp">
      <fileset dir="${AIA_INSTANCE}">
      <include name="config/AIAInstallProperties.xml"/>
      </fileset>
      </UpdateMetadata>
      </Configurations>
      </DeploymentPlan>
      

   4. Navigate to the $AIA_INSTANCE/bin directory.

   5. Execute the following commands:

      For Windows: execute aiaenv.bat

      ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml

      For Linux: source aiaenv.sh

      ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml

   6. Wait till you see a build successful result.

5. Create a custom deployment plan to deploy, ReportDrugSafetyReportReadAckFileAdapter and ReportDrugSafetyReportWriteE2BFileAdapter composites.

   1. Open the file $AIA_HOME/pips/AEInFormandArgus/DeploymentPlans/AEInFormandArgusCustomDP.xml.

   2. Replace <Deployments> </Deployments> with the following:

      <Deployments>
      <Composite compositeName="ReportDrugSafetyReportWriteE2BFileAdapter"
      compositedir="$AIA_HOME/services/core/ArgusSafety/AdapterServices/ReportDrugSafetyReportWriteE2BFileAdapter" revision="1.0" wlserver="pips.AEInFormandArgus" action="deploy" overwrite="true"/>
      <Composite compositeName="ReportDrugSafetyReportReadAckFileAdapter"
      Compositedir="$AIA_HOME/services/core/ArgusSafety/AdapterServices /ReportDrugSafetyReportReadAckFileAdapter" revision="1.0" wlserver="pips.AEInFormandArgus" action="deploy" overwrite="true"/>
      </Deployments>
      

   3. Save AEInFormandArgusArgusCustomDP.xml.

6. Run the CustomDP file by executing the following command:

   1. Set the environment variables by using the following command:

      For Windows: execute %AIA_INSTANCE%\bin\aiaenv.bat

      For Linux: source $AIA_INSTANCE/bin/aiaenv.sh

   2. Run the custom deployment command for deploying the customized artifacts using the following command:

      For Windows: ant -f %AIA_HOME%\Infrastructure\Install\AID\AIAInstallDriver.xml -DDeploymentPlan=%AIA_HOME%\pips\AEInFormandArgus\DeploymentPlans\AEInFormandArgusCustomDP.xml -DPropertiesFile=%AIA_HOME%\config\AIAInstallProperties.xml -l <location and name of the log file>

      For Linux: ant -f $AIA_HOME/Infrastructure/Install/AID/AIAInstallDriver.xml -DDeploymentPlan=$AIA_HOME/pips/AEInFormandArgus/DeploymentPlans/ AEInFormandArgusCustomDP.xml -DPropertiesFile=$AIA_INSTANCE/config/AIAInstallProperties.xml -l <location and name of the log file>

3.7 Identifying Cross-references

Cross-references map and connect the records within the application network, and enable these applications to communicate in the same language. The integration server stores the relationship in a persistent way so that others can refer to it.

Purpose of cross-reference is to maintain a mapping between the primary keys of the participating applications. InForm safety event can be uniquely identified using a composite primary key of the trial name, and the safety event ID fields. Oracle Argus Safety case can be uniquely identified using a composite primary key of enterprise name and case ID fields.

Note:

When Oracle Argus Safety is installed as a single tenant, enterprise name may be empty. In such cases, ARGUS_01 column will not have <ENTERPRISE_NAME>:: prefix.

Many InForm safety events can be mapped to one Oracle Argus Safety Case. This gives a many to one mapping between InForm Safety Event ID and Argus Case ID.

For more information about cross-references, see Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite.

The following are the cross-reference for Adverse Event Integration Pack for InForm and Oracle Argus Safety:

Table 3-2 Cross-reference for Adverse Event Integration Pack

XREFTABLENAME	COLUMN NAME	DESCR	USAGE
DRUGSAFETYREPORT_CASEID	INFORM_01	A composite primary key formed by combining the following data <TRIAL_NAME>::<SAFETY_EVENT_ID>	This column is populated when a row is created in the table when a new Serious Adverse Event is sent to Oracle Argus Safety.
DRUGSAFETYREPORT_CASEID	COMMON	System generated GUID to uniquely identify the case	This column is populated when a row is created in the table when a new Serious Adverse Event is sent to Oracle Argus Safety
DRUGSAFETYREPORT_CASEID	ARGUS_01	<ENTERPRISE_NAME>::<CASE_ID>.	This column is populated with the Case ID in Oracle Argus Safety that a new case or follow-up is accepted into. If a follow-up is accepted into a different case than the original product issue was accepted into, this field is updated with the new Case ID.

When a trial is no longer active, the data in the above table can be archived. Data that is ready for archival can be identified using the trial_name in the INFORM_01 column.

This XREF table is stored as its own table and not part of XREF_DATA table. There is no unique constraint on the ARGUS_01 column since multiple SAEs in Oracle Health Sciences InForm can belong to the same case in Argus. A composite primary key is represented by using :: as a separator for each part of the composite key.

3.8 Working with Domain Value Maps

Domain value maps (DVMs) are a standard feature of the Oracle SOA Suite and enable you to equate lookup codes and other static values across applications. For example, FOOT and FT or US and USA.

DVMs are static in nature, though administrators can add and update additional maps as needed. Transactional business processes never update DVMs; they only read from them.

This integration uses two qualifiers: TRIAL_NAME and ARGUS_ENT_NAME. Qualifier columns provide flexibility in maintaining code lists that vary by trial or Argus Enterprise.

• ReportDrugSafetyReportInFormReqABCSImpl uses INFORM_01 column to get the COMMON value. This service uses the TRIAL_NAME qualifier as well to get the COMMON value.

• ReportDrugSafetyReportArgusProvABCSImpl uses COMMON column to get the ARGUS_01 value from the DVMs. This service uses the ARGUS_ENT_NAME qualifier as well to get the ARGUS_01 column.

• If a DVM look up fails, ReportDrugSafetyReportInFormReqABCSImpl and ReportDrugSafetyReportArgusProvABCSImpl pass the original value from the payload.

The Information exchanged between Oracle Health Sciences InForm and Oracle Argus Safety is defined as codelists in Central Designer as well as in Oracle Argus Safety. However, the actual codelist values may differ between the two systems. The AIA layer handles this with Domain Value Map (DVMs). These are the DVMs used by Adverse Event Integration Pack for InForm and Oracle Argus Safety:

Table 3-3 list the mandatory DVMs used by Adverse Event Integration Pack for InForm and Oracle Argus Safety.

Table 3-3 Mandatory DVMs

DVM Name	DVM Column Name	Comments
HS_TRUE_FALSE	INFORM_01, COMMON, TRIAL_NAME(qualifier)	There are fields in Argus that require a True or false value. InForm may send different values that mean true and false (for example, (Y, N), (1, 0)). The following fields require true or false values: serious seriousnessdeath seriousnesslifethreatening seriousnesshospitalization seriousnessdisabling seriousnesscongenitalanomali seriousnessother breastfeedindicator_extension prospectiveind_extension retrospectiveind_extension interventionreq_extension droppedfromstudyind_extension lackofefficacyind_extension progressofdiseaseind_extension adversewithdrawalind_extension infectionind_extension deathind_extension lifethreateningind_extension hospitalizationind_extension disabilityind_extension congenitalanomalyind_extension medsignificantind_extension seriousotherind_extension overdoseind_extension abuseind_extension tamperingind_extension ongoingind_extension deviceevalbymanu_extension dvcadevtindicator_extension dvcprodprobindicator_extension If the integration sends these values, you must enter the codes from the InForm codelist that will be sent. If multiple values are sent for the same trial or different trials, you need to create a row for each value and include the trial name qualifier.
HS_YES_NO_UNKNOWN	INFORM_01, COMMON, TRIAL_NAME(qualifier)	The following fields in Argus require YES_NO_UNKNOWN values: relatedtostudy_extension receivedtreatment_extension priorhistory_extension patientmedicalcontinue patientautopsyyesno drugrecurreadministration reprocessedsingleuse_extension If you are sending these fields from InForm, you must enter the code from InForm codelist for YES, NO and UNKNOWN. If there are multiple per trial, you must add a row for each using trial name qualifier. If they differ per trial, you also need to add a row for each using trial name qualifier.

Table 3-4 list the optional DVMs with E2B codes used by Adverse Event Integration Pack for InForm and Oracle Argus Safety.

Caution:

You must not change the ARGUS_01 values in the following DVMs.

Table 3-4 Optional DVMs with E2B Codes

DVM Name	DVM Column Name	Comments
DRUGSAFETYREPORT_QUALIFICATIONCODE	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the qualification code sent by InForm Publisher to the qualification code in Oracle Argus Safety.
GENDER	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the SexCode in the Safety Logical Schema to the Patient Information / Gender in Oracle Argus Safety. For more information, see Section 3.3.7.2.
RACE	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the RaceCode in the Safety Logical Schema to the Patient Information / Ethnicity in Oracle Argus Safety. For more information, see Section 3.3.7.2.
DRUGSAFETYREPORT_AGEGROUP	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the AgeGroupCode in the Safety Logical Schema to the Patient Information / Age Group in Oracle Argus Safety. For more information, see Section 3.3.7.2.
DRUGSAFETYREPORT_ADVERSEEVENTREPORTEDOUTCOME	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the AE_OutcomeCode in the Safety Logical Schema to the Event Information / Outcome of Event in Oracle Argus Safety. For more information, see Section 3.3.7.3.
DRUGSAFETYREPORT_DRUGADMINISTRATIONROUTE	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the SuspectDrug_Administration RouteCode in the Safety Logical Schema to the Dosage Regimens / Patient Route of Administration in Oracle Argus Safety. For more information, see Section 3.3.7.12.
DRUGSAFETYREPORT_DRUGACTIONTAKEN�	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the SuspectDrug_ActionTaken Code in the Safety Logical Schema to the Product Details / Action Taken in Oracle Argus Safety. For more information, see Section 3.3.7.12.
DRUGSAFETYREPORT_TERMHIGHLIGHTED	INFORM_01, COMMON, ARGUS_01,TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps ReportDrugSafetyReport/DrugSafetyReportPatient/DrugSafetyReportReaction/TermHighlighted/Dosage with Argus E2B+ field ichicsr/safetyreport/patient/reaction/termhighlighted
COUNTRY	INFORM_01, COMMON, ARGUS_01,TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the country in the Site address to the Reporter address in Argus, the country of incidence entered in Inform to the Case Country in Argus, and the country in the Reprocessor Address to the Reprocessor address in Oracle Argus Safety.
HS_UNIT_OF_MEASURE	INFORM_01, COMMON, ARGUS_01,TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps units sent from InForm (either through codelist or native units) to the units value in Oracle Argus Safety.
DRUGSAFETYREPORT_STATUS	INFORM_01, COMMON, ARGUS_01	This DVM passes the correct values to InForm Adapter for the status of whether the Argus user accepted or rejected the E2B file. Note: Do not change the values in this DVM.

Table 3-5 list the optional DVMs used by Adverse Event Integration Pack for InForm and Oracle Argus Safety.

The following DVM values must match the Argus codelist and non E2B values.

Table 3-5 Optional DVMs

DVM Name	DVM Column Name	Comments
OCCUPATION	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the patient occupation and reporter occupation entered in InForm to the patient occupation and reporter occupation in Oracle Argus Safety.
DRUGSAFETYREPORT_ADVERSEEVENTSEVERITY	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the adverse event severity in Oracle Health Sciences InForm and Oracle Argus Safety. This maps the AE_SeverityCode in the Safety Logical Schema to the Event Information / Event Intensity in Oracle Argus Safety. For more information, see Section 3.3.7.3.
DRUGSAFETYREPORT_DRUGFORMULATION	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the SuspectDrug_DosageForm Code in the Safety Logical Schema to the Product Information / Formulation in Oracle Argus Safety. For more information, see Section 3.3.7.12.

Table 3-6 list the device trial specific DVMs used by Adverse Event Integration Pack for InForm and Oracle Argus Safety.

Table 3-6 Device Trial Specific DVMs

DVM Name	DVM Column Name	Comments
DRUGSAFETYREPORT_DEVICEOPERATOR	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the DeviceOperatorCode in the Safety Logical Schema to the Device Information / Operator of Device in Oracle Argus Safety. For more information, see Section 3.3.7.16.
DRUGSAFETYREPORT_DEVICEUSE	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the DeviceReuseCode in the Safety Logical Schema to the Device MedWatch Info / Usage of Device in Oracle Argus Safety. For more information, see Section 3.3.7.16.
DRUGSAFETYREPORT_DEVICEREMEDIALACTION	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the device remedial action in Oracle Health Sciences InForm and Oracle Argus Safety. Do not change the values in the COMMON and ARGUS_01 columns of this DVM because the values in these columns determine whether remedial action check box options should be checked or unchecked on the Oracle Argus Safety user interface.
DRUGSAFETYREPORT_DEVICEAVAILFOREVAL	INFORM_01, COMMON, ARGUS_01, TRIAL_NAME(qualifier), ARGUS_ENT_NAME(qualifier)	This maps the EvaluationAvailability IndicationCode in the Safety Logical Schema to the Device Information / Device Available for Evaluation in Oracle Argus Safety. For more information, see Section 3.3.7.16.
STATE	INFORM_01, COMMON, ARGUS_01	This maps the state in the Site and Reprocessor address in InForm to the Reporter and Reprocessor address in Argus. Trial _name qualifier is not available for this DVM. Therefore, you must standardize the state names across different trials.

Table 3-7 list the special DVMs used by Adverse Event Integration Pack for InForm and Oracle Argus Safety.

The following DVMs do not have Argus_01 values.

Table 3-7 Special DVMs

DVM Name	DVM Column Name	Comments
DRUGSAFETYREPORT_DOSAGEFREQUENCY	INFORM_01, COMMON, TRIAL_NAME(qualifier)	If you enter the entire dosage frequency (for example, once per day) as a codelist value in InForm, the Argus Provider ABCS will split the frequency value into three separate fields as follows: drugseparatedosagenumb drugintervaldosageunitnumb drugintervaldosagedefinition If you want to add a new row to this DVM, use the following format: <numeric> time/times every [numeric]/a minute/hour/day/week/month/year Note: Ensure that there is a single space after each parameter. For example, 4 times every 10 days 1 time a month 2 times a day
DRUGSAFETYREPORT_TAKENANDPREVIOUSLYTOLERATED	INFORM_01, COMMON, TRIAL_NAME(qualifier)	This maps the SuspectDrug_TakenPreviously AndToleratedCode in the Safety Logical Schema to the Product Detail / Taken Previously And Tolerated in Oracle Argus Safety. For more information, see Section 3.3.7.12. This DVM does not have an ARGUS_01 column because Argus requires specific values to be passed. You should not change the COMMON value and cannot add rows to this DVM. You have to just populate the INFORM_01 values including TRIAL_NAME qualifier where necessary.

Since DVMs may change whenever new trials are started and there are a lot of DVMs to modify, you may want to take the following approach:

• Keep the .DVM files that you use in a central directory on the SOA server (for example, /users/oracle/MyDvms/dvm). The subdirectory must be named dvm.

• Make all your modifications in this directory and when ready upload to the MDS using the following steps:

  1. Modify ${AIA_INSTANCE}/config/UpdateMetaDataDP.xml to have following content:

     <?xml version="1.0" standalone="yes"?><DeploymentPlan component="Metadata" version="3.0"><Configurations><UpdateMetadata wlserver="fp"><fileset dir="/prod/oracle/MyDVMs"><include name="dvm/**"/></fileset></UpdateMetadata></Configurations></DeploymentPlan>
     

     Note the following:

     fileset task's dir attribute should point to the parent folder of dvm directory.

     dvm directory contains files to be uploaded to MDS.

  2. Set the environment by executing the following command:

     For Windows: execute %AIA_HOME%\aia_instances\%AIA_INSTANCE%\bin\aiaenv.bat

     ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml

     For Linux: source $AIA_HOME/aia_instances/$AIA_INSTANCE/bin/aiaenv.sh

     ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml

The following is an example of Gender DVM using TRIAL_NAME qualifiers:

InForm	Trial	COMMON	Argus	Enterprise
M		Male	1
F		Female	2
1	STUDYB	Male
2	STUDYB	Female

In this example, the values M and F are entered for Male and Female respectively for all studies except for STUDYB.

Note:

All trial names must be in uppercase when used as a qualifier.

STUDYB has a codelist that sends 1 for Male and 2 for Female. The InForm Requester will use the TRIAL_NAME qualifier to find the correct common value. There can be only one row with the ARGUS_01 value populated unless it is qualified by ARGUS_ENT_NAME. The Argus Requester will use the COMMON value to get the ARGUS_01 value.

In this example, there is no qualifier for ARGUS_ENT_NAME. If the value differs per enterprise in Argus, another row will be created that contains the different ARGUS_01 values for each ARGUS_ENT_NAME.

ARGUS_ENT_NAME is case-sensitive and must match the directory name used on the Argus Interchange server.

For more information about working with DVMs and using Oracle SOA Composer with DVMs, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite 11g Release 1.

3.9 Using the Message Resubmission Utility

This section describes the steps for using the Resubmission utility when the flows fail. For example, if a flow fails because of a system fault like a server being down for maintenance, you can resubmit the flow when the server is up.

AIA provides Message Resubmission Utility to re-submit failed messages for both of the flow from Oracle Health Sciences InForm to Oracle Argus Safety and from Oracle Argus Safety to Oracle Health Sciences InForm. Both flows use sequencers that group the messages by safety event ID.

This means that if a message for a particular serious adverse event fails, subsequent messages for that same serious adverse event will be queued up in order and not sent. This ensures they will reach Argus in the order intended. On the flow from Oracle Argus Safety to Oracle Health Sciences InForm, the same holds true.

When you resubmit the messages you resubmit them as a group.

The following steps explain how to resubmit the flows.

Using Message Resubmission Utility for ReportDrugSafetyReport Flow (Oracle Health Sciences InForm to Oracle Argus Safety)

1. Set the following values in the ResubmissionParams.properties file located in $AIA_HOME/util/AIAMessageResubmissionUtil:

   • resourceType = 3

   • resourceName = Should be in the format default/<compositeName>!<version>. In this case, value of this field would be default/InFormDrugSafetyReportJMSConsumer!1.0.

   • messageID = Obtain this value from Enterprise Manager. Select InFormDrugSafetyReportJMSConsumer and under Faults and Rejected Messages, click Recovery. Enter the group ID shown as the value of messageID. Multiple groupIDs of a particular composite can be entered with comma ”,” as a delimiter.

   • jms.app.username=<weblogic admin username>

   • jms.app.password=<weblogic admin password>

   • jms.app.hostName=<weblogic admin hostname>

   • jms.app.admin.port=<weblogic admin port>

   • jms.app.soa.port=<weblogic managed server port>

2. Execute the command as per your platform:

   • For Windows: execute %AIA_INSTANCE%\bin\aiaenv.bat

   • For Linux: source $AIA_INSTANCE/bin/aiaenv.sh

3. Navigate to $AIA_HOME/util/AIAMessageResubmissionUtil and execute the following ant command:

   • For Windows: ant -f MessageResubmit.xml -l %AIA_HOME%\util\AIAMessageResubmissionUtil\MessageResubmit.log

   • For Linux: ant -f MessageResubmit.xml -l $AIA_HOME/util/AIAMessageResubmissionUtil/MessageResubmit.log

   The MessageResubmit.xml script references the edited ResubmissionParams.properties file. The script resets the message status to a ready state so that the transaction can resume its flow.

   For security reasons, you must remove the password from the ResubmissionParams.properties file after you run the Resubmission utility.

   For more information about AIA error handling and setting up and using error handling and logging, see Oracle Application Integration Architecture - Foundation Pack: Core Infrastructure Components Guide.

Using the Resubmission Utility for the Failure of Acknowledgement Flow (Oracle Argus Safety to Oracle Health Sciences InForm)

Follow these steps for using the resubmission utility when the Acknowledgement flow from Oracle Argus Safety to Oracle Health Sciences InForm fails:

1. Set the following values in the ResubmissionParams.properties file located in $AIA_HOME/util/AIAMessageResubmissionUtil:

   1. jms.app.userName=<weblogic administrator user> (for example, weblogic)

   2. jms.app.password=<weblogic administrator password>

   3. resourceType=3

   4. resourceName= default/ReportDrugSafetyReportReadAckFileAdapter!1.0

   5. messageID= Get the value of messageID by navigating to the Enterprise Manager from the link in the email notification. Click the Recovery link in the faults section. Enter the group ID shown as the value of messageID. Multiple groupIDs of a particular composite can be entered with comma "," as a delimiter.

2. For Windows: execute %AIA_INSTANCE%\bin\aiaenv.bat

3. For Linux: source $AIA_INSTANCE/bin/aiaenv.sh

4. Navigate to $AIA_HOME/util/AIAMessageResubmissionUtil and execute the following ant command:

   For Windows: ant -f MessageResubmit.xml -l %AIA_HOME%\util\AIAMessageResubmissionUtil\MessageResubmit.log

   For Linux: ant-f MessageResubmit.xml -l $AIA_HOME/util/AIAMessageResubmissionUtil/MessageResubmit.log

   The MessageResubmit.xml script references the edited ResubmissionParams.properties file. Once run, the script resets the message status back to a ready state so that the transaction can resume its flow.

   For security reasons, you must remove the password from the ResubmissionParams.properties file after you run the Resubmission utility.

3.10 Updating DVMs Used for Configurations

3.10.1 HS_TRIAL_SAFETY_CONFIG DVM

The HS_TRIAL_SAFETY_CONFIG DVM must be populated for each trial that will use the integration. Table 3-8 and Table 3-9 describes which values must be filled in (MANDATORY) and when the other values are necessary.

Table 3-8 HS_TRIAL_SAFETY_CONFIG.dvm

Column	Mandatory?	Description
INFORM_TRIAL_NAME	Y	Name of the InForm trial in all upper-case letters.
INFORM _URL	N	This is the portion of the URL to access InForm up to the trial name. You must enter this value only if this value differs per trial. If this value is the same for all your trials, you must enter this value in the Configuration Wizard during installation or update it in the AIAConfigurationProperties.xml file and upload it to the MDS as described in Section 3.6.
SENDER_COMPANY_NAME	Y	Short abbreviation of the company that is sending the safety event data. This value generates the SenderMessageID in the format required by E2B standard. You must enter this value in the DVM if it differs per trial. If not, you can enter this value during installation using Configuration Wizard or update it in the AIAConfigurationProperties.xml file and upload it to the MDS by following the instructions in Section 3.6.
ARGUS_ENT_NAME	Y, if using Argus multi-tenant	Name of Argus Enterprise. A multi-tenant Argus Safety install can support one or more enterprises. This value must match the directory name you created for the enterprise on the Interchange server. This should not be filled, if Argus is not multi-tenant.
ARGUS_STUDY_ID	N	Study identifier as defined in Argus. If this is same as trial name in InForm, this field need not be populated.
BLINDED_INDICATOR	N	Indicates whether study in Argus is blinded or not. If the value of this field in the DVM is blank, the integration will treat the trial as blinded.

The values of Table 3-9 are only required if you are using the Acknowledgement flow and if the values differ per trial.

If the values are the same for all your trials, you can enter this value during installation using the Configuration Wizard or update it in the AIAConfigurationProperties.xml file and upload it to the MDS by following the instructions in Section 3.6.

Table 3-9 HS_TRIAL_SAFETY_CONFIG.dvm

Column	Mandatory?	Description
INFORM_ADAPTER_AUTH_KEY	N	Key for InForm Adapter authentication. This key is used to look up credential store to obtain the InForm Adapter authentication user name and password. User name and password will be added to soap header when invoking InForm Adapter. You must enter this value only if there is a different authentication user name and/or password for each trial.
INFORM_ ADAPTER_TRANS_USER	N	Transaction user name is the name of the user that will be stored in the audit trial in InForm when the case ID, status, and/or reason is written to the database. If the same user is used for all your trials, you do not need to enter this value in the DVM. Transaction user must have two InForm rights: To enter data into a CRF To edit data on a CRF Transaction user name is placed in the audit trial in InForm against all update transactions.
INFORM_ADAPTER_URL	N	This is the URL to access InForm Adapter web service. If the URL does not differ per trial, you do not need to enter this value in the DVM.

3.10.2 HS_PRODUCT_SAFETY_CONFIG DVM

If you are using Argus 7.0.2, you can blind one product in a study and not blind the other products. In such case, you must enter the products in the HS_PRODUCT_SAFETY_CONFIG DVM. If the study has multiple arms in Argus 7.0.2, all data passed through the integration will be imported into the first study arm. Therefore, the blinded setting in this DVM must match the settings in Argus for the first arm of the study.

Table 3-10 describes which values must be filled in (MANDATORY) and when the other values are necessary.

Table 3-10 HS_PRODUCT_SAFETY_CONFIG.dvm

Column	Mandatory?	Description
PRODUCT_NAME	Y	Name of the drug or device product. This value must match the trade name in Argus, if not blinded.
INFORM_PRODUCT_CODE	N	Code for the drug or device sent by InForm. You can send a product code instead of product name to identify a drug or device. Although this value is not mandatory in the DVM, it is mandatory to enter the value for this integration.
BLINDED_INDICATOR	N	Indicates whether a product in Argus is blinded or not. If the value of this field in the DVM is true or blank, the integration will treat the product as blinded. If the value of this field is false, the integration will treat this product as not blinded.
SENDER_COMPANY_NAME	N	Leave this column blank. This value is not used for InForm and Argus Safety integration.
ARGUS_ENT_NAME	N	Leave this column blank. This value is not used for InForm and Argus Safety integration.
TRIAL_NAME	N	Qualifier column that is populated with the name of the trial. Although this value is not mandatory in the DVM, it is mandatory to enter the value for this integration.

If a row with the InForm Product Code is not found in this DVM, the blinded indicator from the HS_TRIAL_SAFETY_CONFIG DVM will be used for the product.

3.11 Extending the Integration

You can extend the integration in multiple ways by:

• Sending additional data from Oracle Health Sciences InForm to Oracle Argus Safety

• Performing custom transformations on the data being sent from Oracle Health Sciences InForm to Oracle Argus Safety

• Calling out to your own web services to retrieve additional information or do additional processing

This integration pack provides support for sending custom data from Oracle Health Sciences InForm to Oracle Argus Safety. It supports sending data to Argus user-defined text, number, or date fields in Argus case form General, Patient, Event, and Device tabs. For more information, see Section 3.11.1.

This integration also supports sending custom data from Oracle Health Sciences InForm to Oracle Argus Safety for non user-defined Argus fields. For example, you can customize the integration to send data to Oracle Argus Safety case form, which the standard integration does not import ready-to-use. For more information, see Section 3.11.2.

3.11.1 Sending Additional Data from Oracle Health Sciences InForm to Oracle Argus Safety

The current logical schema attempts to cover all the items you would need to send from Oracle Health Sciences InForm to Oracle Argus Safety that would appear in the standard Argus User interface (UI). If you are using user-defined fields in Argus and collect data for those fields in InForm, this integration provides an easy mechanism for sending these additional fields.

Argus has user-defined (UD) fields to collect user-defined data. This integration supports sending user-defined data from Oracle Health Sciences InForm to Oracle Argus Safety under the General, Patient, Event, or Device tabs of the Argus Safety user interface (UI). Each of these tabs support up to 12 UD fields either text, numeric, or date type. Using Argus Console, you can enable a field of one type for a given UD field on Argus Safety UI. For example, UD_text_1 and UD_number_1 fields cannot be enabled at the same time. However, UD_text_1 and UD_date_7 can be enabled at the same time.

These custom fields can be added to the InForm logical schema under data series titles Safety_Case, Subject, Subject_AdverseEvent, MedicalDevice. The alias specified for the custom field must follow a naming convention so that InForm custom fields can be auto-mapped to Argus user-defined fields. Auto-mapping of the fields happens in the integration layer on the SOA server. The alias for a custom field is named as "Cust-<Object Type>_<data type>_<Number1..12>"

where,

Object Type - can be one of General, Patient, Reaction, or Device.

Data type - Str, Num, or Dt

Number - number between 1 to 12.

For example, if Study Designer adds a custom field with alias Cust_General_Str_1 in Safety_Case logical schema data series, this custom field is mapped to UD_TEXT_1 field in the General tab in Argus Safety.

If Study Designer add a field Cust_Patient_Dt_10 in Subject logical schema data series, this custom field is mapped to UD_DATE_10 in the Patient tab in Argus Safety.

3.11.1.1 SOA Server Customization

This integration provides an auto-mapping of custom fields on the SOA Server layer and Argus, which must be enabled if you want to extend the EBO.

To enable customization, perform the following steps:

1. Navigate to the SOA_Server directory, <AIA_Instance>/bin and perform the following:

   • On Windows: execute aiaenv.bat

   • On Linux: source aiaenv.sh

2. Navigate to the SOA_Server directory, <AIA_HOME>/data/AEInFormandArgus/customization.

3. Execute the following command on the command line:

   On Windows:

   ant -f %AIA_HOME%\Infrastructure\Install\AID\AIAInstallDriver.xml -DPropertiesFile=%AIA_HOME%\aia_instances\<instance_name>\ config\AIAInstallProperties.xml -DDeploymentPlan=%AIA_HOME%\ data\AEInFormandArgus\customization\ AEInFormandArgusCustomMappingDP.xml -l %AIA_HOME%\data\ AEInFormandArgus\customization\AEInFormandArgusCustomMappingDP.log
   

   On Linux:

   ant -f $AIA_HOME/Infrastructure/Install/AID/AIAInstallDriver.xml -DPropertiesFile=$AIA_HOME/aia_instances/<instance_name>/ config/AIAInstallProperties.xml -DDeploymentPlan=$AIA_HOME/data/AEInFormandArgus/customization/ AEInFormandArgusCustomMappingDP.xml -l $AIA_HOME/data/ AEInFormandArgus/customization/AEInFormandArgusCustomMappingDP.log
   

4. Perform this step if there are custom elements under Argus E2B drug node that is displayed in the Product > Device tab of the Argus Safety Case Form. This is not necessary for other tabs because they are already added to the DTD.

   Note:

   The Argus E2B DTD does not support more than 90 child elements under a parent node. The DTD that is delivered with integration pack has 82 child elements. Therefore, you can add only up to eight custom elements under the drug node.

   For example, if InForm trial is sending a custom field called Cust_Device_Str_1, modify the Argus DTD at <AIA_HOME>/AIAMetaData/AIAComponents/ApplicationObjectLibrary/ArgusSafety/V1/schema/ich-icsr-v2.1-FDA-PIP.dtd.

   1. Add a field custdevicestr1_extension to this DTD.

      In the custdevicestr1_extension, str and 1 will change depending upon the user-defined field data type and number in Argus.

   2. Add element definition under the drug node as follows:

      Figure 3-1 Adding Element Definition

      
      Description of "Figure 3-1 Adding Element Definition"
      
      

   3. Add element details as follows:

      Figure 3-2 Adding Element Details

      
      Description of "Figure 3-2 Adding Element Details"
      
      

5. Save the DTD file.

3.11.2 Enabling Customization for Argus Safety Non User-Defined Fields

Certain fields in Argus case forms are not imported by the standard integration. If you want to import these fields, additional customization can be done. The following sections will use the example of sending data from InForm form field to Argus Safety Case Form > Product > <Product Name> > Device > Device Subcomponent Lot field.

Figure 3-3 Case Form

Description of "Figure 3-3 Case Form"

3.11.2.1 InForm Customization

Custom fields can be added to the InForm logical schema under data set titles Safety_ Case, Subject and Subject_AdverseEvent, MedicalDevice. The alias specified for the custom fields for sending data to non-user-defined fields in Argus Safety must not follow the same naming as the custom fields that are mapped to Argus user-defined fields.

For example, if Study Designer adds a custom field DeviceSubComponentLotID to send to Oracle Argus Safety. Study Designer can define the alias for this fields as custom_subcomp_lotid in the MedicalDevice dataset.

3.11.2.2 SOA Server Customization

To send non user-defined Argus Safety fields, perform the following on the SOA server:

1. Add a new element to InForm XSD and upload it to MDS.

   1. It is recommended to back up the .xsd file before adding a new element to it. For the example used in this section, DeviceSubCompLotId field may be added under DrugSafetyReportMedicalDevice.

   2. Using Oracle JDeveloper or any text or xml editor, open the file <AIA_HOME>/AIAMetaData/AIAComponents/ApplicationObjectLibrary/InForm/V1/schemas/InformToSafetyDrugSafetyReportEBO.xsd.

   3. Upload the modified XSD file to MDS using the following steps:

      1. Place the modified XSD file on the SOA server in the following location:

         <AIA_HOME>/AIAComponents/ApplicationObjectLibrary/InForm/V1/schemas�

      2. Update the fileset element in the UpdateMetaDataDP.xml file (at $AIA_INSTANCE/config) to point to the location of the XSD file as shown below:

         <fileset dir="${AIA_HOME}/AIAMetaData"><include name="AIAComponents/ApplicationObjectLibrary/InForm/V1/schemas/ InformToSafetyDrugSafetyReportEBO.xsd"/></fileset>
         

      3. Upload to MDS using the following commands:

         For Windows: execute %AIA_INSTANCE%\bin\aiaenv.bat

         ant -f %AIA_�HOME%\Infrastructure\Install\config\UpdateMetaData.xml�

         For Linux: source $AIA_HOME/aia_instances/<instance_name>/bin/aiaenv.sh

         ant -f $AIA_�HOME/Infrastructure/Install/config/UpdateMetaData.xml�

   4. Wait till you see a build successful result.

2. Add a new element to Custom EBO XSD and upload it to MDS.

   1. In this example, since a device extension field is being added, the component DrugSafetyReportMedicalDevice in the EBO is extended to include this field.

   2. It is recommended to back up the .xsd file before adding a new element to the EBO.

   3. Start Oracle JDeveloper and open the file <AIA_HOME>/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/Custom/EBO/DrugSafetyReport/V1/CustomDrugSafetyReportEBO.xsd.

   4. There are several custom types defined in the XSD. Each type name is a place holder for the Custom field it extends.

      For example, the custom field place holders for DrugSafetyReportMedicalDevice is CustomDrugSafetyReportMedicalDeviceType.

   5. Right-click CustomDrugSafetyReportMedicalDeviceType and Insert from complexType > Sequence.

   6. Right-click the new sequence and select Insert from Sequence > Element to add a new element to the sequence.

   7. Name the element as DeviceSubCompLotId.

   8. Set Datatype for the new element that is added.

   9. Right-click the element and select Set Type. Select corecom:StringType from the drop-down list.

   10. Save the xsd file.

   11. Upload the custom file to MDS using the following steps:

       1. Place the xsd file in the following directory:

          <AIA_HOME>/AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/Custom/EBO/DrugSafetyReport/V1/

       2. Update the $AIA_INSTANCE/config/UpdateMetaDataDP.xml to have following fileset entry:

          <fileset dir="${AIA_HOME}/AIAMetaData"><include name="AIAComponents/EnterpriseObjectLibrary/Industry/HealthSciences/Cus tom/EBO/DrugSafetyReport/V1/CustomDrugSafetyReportEBO.xsd"/></fileset>
          

       3. Upload to MDS using the following commands:

          For Windows: execute %AIA_INSTANCE%\bin\aiaenv.bat

          ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml

          For Linux: source $AIA_INSTANCE/bin/aiaenv.sh

          ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml

       4. Wait till you see a build successful result.

3. Add a new element to Oracle Argus Safety XSD and upload it to MDS.

   1. It is recommended to back up the .xsd file before modifying.

   2. Start Oracle JDeveloper and open the file <AIA_HOME>/ AIAComponents/ApplicationObjectLibrary/ ArgusSafety/V1/schemas/ich-icsr-v2.1_integration.xsd.

   3. Locate the element under which the new field should appear.

      In this example, the element devicesubcomplotid_extension is being added under ichicsr > safetyreport > patient > drug element.

      Ensure to add the custom element at the end of the sequence of child elements.

   4. Add the reference properties of newly created reference in the same XSD.

   5. Save the changes to the XSD.

   6. Upload the XSD to MDS using the following steps:

      1. Place the modified XSD file (ich-icsr-v2.1_integration.xsd) in the <AIA_HOME>/AIAComponents/ApplicationObjectLibrary/ArgusSafety/V1/schemas folder.

      2. Update the $AIA_INSTANCE/config/UpdateMetaDataDP.xml to have following fileset entry:

         <fileset dir="${AIA_HOME}/AIAMetaData"><include name="AIAComponents/ApplicationObjectLibrary/ArgusSafety/V1/schemas/ich-icsr-v2.1_integration.xsd"/></fileset>
         

      3. Upload to MDS using the following commands:

         For Windows: execute %AIA_INSTANCE%\bin\aiaenv.bat

         ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml�

         For Linux: source $AIA_INSTANCE/bin/aiaenv.sh�

         ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml�

      4. Wait till you see a build successful result.

4. Add custom transformations to custom XSL in ReportDrugSafetyReportInFormRequesterABCS composite.

   This scenario assumes that the Oracle JDeveloper is set up with the following configurations:

   • Resource Palette is configured to browse SOA_MDS database for a given database.

   • JWS application is configured to which the .jpr files can be added.

   1. Get the ReportDrugSafetyReportInFormReqABCSImpl and ReportDrugSafetyReportArgusProvABCSImpl composites from the application server to the local JDeveloper environment.

      This involves copying corresponding composite projects from the application server's folders <AIA_HOME>/services/core/InForm/RequesterABCS and <AIA_HOME>/services/core/ArgusSafety/ProviderABCS to the local JDeveloper environment.

   2. It is recommended to back up the .xsd file before mapping.

   3. In the Oracle JDeveloper, click Open and navigate to ReportDrugSafetyReportInFormReqABCSImpl.jpr.

   4. Expand the project and under the xsl folder, open Xform_ DrugSafetyReportABMReqMsg_to_DrugSafetyReportEBMReqMsg_ Custom.xsl.

   5. In the Oracle JDeveloper design view, map the new custom field DeviceSubCompLotId in InForm ABM and DeviceSubCompLotId in ReportDrugSafetyReportEBM.

   6. Navigate to the Source tab.

      A template contains the mapping that you created under the <xsl:template match="/"> element.

   7. There are multiple templates provided in the custom xsl.

      For example, there is DrugSafetyReportDrugType_ext for extending DrugSafetyReportDrug component of the ebo, ReportDrugSafetyReportMedicalDeviceType_ext for extending DrugSafetyReportDrug component of the ebo.

      Cut the content enclosed in <ebo:custom> tag and paste the same in the appropriate template.

      For this example, DrugSafetyReportDeviceType_exttemplate should be used.

      Remove the content enclosing <xsl:template match="/"> tag, which is auto-generated by the designer.

      Note:

      The xsl can also be modified using other text editors. Ensure that namespaces (for example: ebo, ns0) are appropriately assigned in such cases.

   8. Save your changes to custom xsl.

5. Add custom transformations to custom xsl in ReportDrugSafetyReportArgusProviderABCS composite

   This scenario assumes that the Oracle JDeveloper is set up with the following configurations:

   • Resource Palette is configured to browse SOA_MDS database for a given database.

   • JWS application is configured to which the .jpr files can be added.

     1. It is recommended to back up the .xsd file.

     2. In the Oracle JDeveloper, click Open and navigate to Xform_ DrugSafetyReportReqMsg_to_DrugSafetyReportRespMsg_Custom.xsl.

     3. In the Oracle JDeveloper design view, map the new custom field DeviceSubCompLotId in ReportDrugSafetyReportEBM to devicesubcomplotid_extension in Argus ABM.

     4. Navigate to the Source tab.

        There are multiple templates provided in the custom xsl.

        Design view adds the mapping created in step c in a default template <xsl:template match="/">.

        Modify the default template by cutting the content enclosed by "_extension" element and pasting the same in the appropriate template. For example, <devicesubcomplotid_extension> should be moved to deviceType_ext template.

        Remove the content enclosing <xsl:template match="/"> tag, which is auto-generated by the designer.

     5. Save your changes to custom xsl.

6. Create a custom deployment plan to deploy composites on SOA server.

   1. On the application server, ensure that ReportDrugSafetyReportInFormReqABCSImpl and ReportDrugSafetyReportArgusProvABCSImpl are updated with customizations.

      This involves copying the modified custom XSLs to the application server's folders $AIA_HOME/services/core/InForm/RequesterABCS/ ReportDrugSafetyReportInFormReqABCSImpl/xsl and $AIA_ HOME/services/core/ArgusSafety/ProviderABCS/ ReportDrugSafetyReportArgusProvABCSImpl/xsl correspondingly.

   2. Open the file $AIA_HOME/pips/AEInFormandArgus/DeploymentPlans/AEInFormandArgusCustomDP.xml.

   3. Replace <Deployments> </Deployments> with the following:

      <Deployments><Composite compositeName="ReportDrugSafetyReportArgusProvABCSImpl" compositedir="${AIA_HOME}/services/core/ ArgusSafety/ProviderABCS/ReportDrugSafetyReportArgusProvABCSImpl" revision="1.0" wlserver="pips.AEInFormandArgus " action="deploy" overwrite="true"/><Composite compositeName="ReportDrugSafetyReportInFormReqABCSImpl"compositedir="${AIA_HOME}/services/core/ InForm/RequesterABCS/ReportDrugSafetyReportInFormReqABCSImpl" revision="1.0" wlserver="pips.AEInFormandArgus" action="deploy" overwrite="true"/></Deployments>
      

   4. Save the file.

   5. Set the environment variables by executing the following command:

      For Windows: execute %AIA_HOME%\aia_instances\%AIA_INSTANCE_NAME%\bin\aiaenv.bat

      For Linux: source $AIA_HOME/aia_instances/$AIA_INSTANCE_NAME/bin/aiaenv.sh

   6. Run the following custom deployment command for deploying customized artifacts:

      For Windows: ant -f %AIA_HOME%\Infrastructure\Install\AID\AIAInstallDriver.xml -DDeploymentPlan=%AIA_HOME%\pips\AEInFormandArgus\DeploymentPlans\AEInFormandArgusCustomDP.xml -DPropertiesFile=%AIA_ INSTANCE%\config\AIAInstallProperties.xml -l <location and name where you want the log file written>

      For Linux: ant -f $AIA_HOME/Infrastructure/Install/AID/AIAInstallDriver.xml -DDeploymentPlan=$AIA_HOME/pips/AEInFormandArgus/DeploymentPlans/AEInFormandArgusCustomDP.xml -DPropertiesFile=$AIA_INSTANCE/config/AIAInstallProperties.xml -l <location and name where you want the log file written>

3.11.2.3 Argus Customization

To send non- user-defined Argus Safety fields, perform the following on the Argus Safety Interchange Server:

Create Custom Field in Oracle Argus Safety

1. Modify the DTD file.

   1. On the Oracle Argus Safety Interchange server, open the <ORACLE_ HOME>/Argus/�InterchangeService/DTDFiles/ich-icsr-v2.1-FDA-PIP.DTD.

   2. Add an extension field devicesubcomplot_extension under drug node.

      For example, create the following element as shown below in the DTD:

      Figure 3-4 Creating Element in the DTD

      
      Description of "Figure 3-4 Creating Element in the DTD"
      
      

      Add element properties to the DTD as shown below:

      Figure 3-5 Adding Element Properties to the DTD

      
      Description of "Figure 3-5 Adding Element Properties to the DTD"
      
      

      Note:

      The Argus E2B DTD does not support more than 90 child elements under a parent node. The DTD that is delivered with the integration pack has 82 child elements. Therefore, you can add only up to eight custom elements under the drug node.

   3. Save the DTD file and exit.

      Ensure that you always add the extension elements to end of the sequence of child elements. Note that the change in the DTD is equivalent to the change in the ich-icsr-v2.1_integration.xsd as described.

2. Add the extension field export and import logic.

   CFG_E2B table needs to have a row for each DTD_ELEMENT that is imported.

   The following SQLs is an example for importing devicesubcomplotid_extension. The values in the SQLs need to be modified depending on the type of field that is being added.

   1. Log in to SQL script execution tool such as SQL Developer or SQL Plus using ESM schema owner credentials for your Argus Safety database.

   2. Execute the following SQLs:

      Export SQL:

      insert into cfg_e2b (PROFILE, DTD_ELEMENT, HIE_LEVEL, DTD_TYPE, DELETED, DTD_LENGTH, LANGUAGE, MANDATORY_DTD_ELEMENT, MANDATORY, ORDER_OF_EXECUTION, AE_SELECT_STMT_ELEMENT_ASSOC, AE_SELECT_STMT_COL_POSITION, PARENT_ELEMENT, DATA_ELEMENT, AE_CASE_FORM_GUI, DTD_ELEMENT_TITLE, REPEATABLE, ALLOW_USER_ PROC, AE_SELECT_STMT, AE_USER_PROC, DTD_ELEMENT_TYPE, UPDATE_FOR_ NULLIFICATION, CHILD_ONLY_SQL, ALWAYS_IMPORT, DTD_ELEMENT_TITLE_J, ALLOW_ JAPANESE_CHARACTERS, FIELD_LOCATION, FIELD_LABEL)�values ('ICH-ICSR V2.1 MESSAGE TEMPLATE - FDA PIP', DEVICESUBCOMPLOTID_EXTENSION',�9, 'DEFINED', null, null, 'en', '', '',232.90, 'DRUG', 115, 'DRUG', '',�'Case Form/Products/ Device/Device Subcomponent Lot Id, ' Device Subcomponent Lot Id ', -1, null, null, null, 1, null, null, 0, '', null, '', '');�
      

      This SQL contains necessary information to create a new extension element in Oracle Argus Safety profile. It contains information such as, the order of execution of the imported element (232.90), position of the new extension element in an E2B difference report (115), parent node (DRUG), and so on.

      Import SQL:

      Update CFG_E2B�
      Set AE_USER_PROC =�
      'DECLARE'|| CHR(10) ||�
      ' v_xmlvarchar2(32767);'|| CHR(10) ||�
      ' l_returnnumber := 0;'|| CHR(10) ||�
      ' v_error_messagevarchar2(4000);'|| CHR(10) ||�
      ' l_valuevarchar2(25);'|| CHR(10) ||�
      ' v_prod_namevarchar2(32767);'|| CHR(10) ||�
      ' lb_returnboolean := FALSE;'|| CHR(10) ||�
      ' v_dtd_elementsesm_imp.vtab;  '|| CHR(10) ||�
      'BEGIN'|| CHR(10) ||�
      ' v_xml  := trim(ESM_IMP.F_READ_EXTENSION(:REPORT_ID,:DTD_ELEMENT));'|| CHR(10) ||�
      ' if v_xml is not null then'|| CHR(10) ||�
      'v_dtd_elements(1) := ''DRUGCHARACTERIZATION'';'|| CHR(10) ||�
      'v_dtd_elements(2) := ''MEDICINALPRODUCT'';'|| CHR(10) ||�
      'v_dtd_elements(3) := ''DRUGDOSAGEFORM'';'|| CHR(10) ||�
      'v_prod_name  := ESM_IMP.F_READ(:REPORT_ID,''MEDICINALPRODUCT'');'|| CHR(10) ||�
      'if v_prod_name is null then'|| CHR(10) ||�
      'v_dtd_elements(2) := ''ACTIVESUBSTANCENAME'';'|| CHR(10) ||�
      'end if;'|| CHR(10) ||�
      'lb_return := ESM_IMP.F_CHECK_AND_BUILD_KEY(:REPORT_ID,:PARENT_ELEMENT,v_�
      dtd_elements); '|| CHR(10) ||�
      'l_value := v_xml;'|| CHR(10) ||�
      '     l_return := ESM_IMP.F_WRITE(:REPORT_ID,:PARENT_ELEMENT,:DTD_ ELEMENT,:PROFILE,''CASE_PROD_DEVICES'',''SUBCOMPONENT_LOT'',l_value);'|| CHR(10)�
      ||�
      ' end if;'|| CHR(10) ||�
      'END;'�
      WHERE DTD_ELEMENT = 'DEVICESUBCOMPLOTID_EXTENSION' AND PROFILE = 'ICH-ICSR V2.1 MESSAGE TEMPLATE - FDA PIP';�
      

Note:

The above SQLs should be customized based on the datatype of the imported field, database table column values where the imported data will be stored.

3.11.3 Enabling Calling Out To Your Own Web Services

This integration lets you to call external web services from all the ABCS services.

Figure 3-6 shows various invocation points for external web services from a Requester ABCS - ReportDrugSafetyReportInFormReqABCS or ReportDrugSafetyReportResponseArgusReqABCS.

Figure 3-6 Calling Web Services From Requester ABCS

Description of "Figure 3-6 Calling Web Services From Requester ABCS"

Figure 3-7 shows invocation points for external web services for Provider ABCS - ReportDrugSafetyReportArgusProvABCS or ReportDrugSafetyReportResponseInFormProvABCS.

Figure 3-7 Calling Web Services From Provider ABCS

Description of "Figure 3-7 Calling Web Services From Provider ABCS"

To invoke an external web service in an ABCS, perform the following:

1. Open <AIA_HOME>/aia_instances/<instance_name>/AIAMetaData/config/AIAConfigurationProperties.xml.

2. Locate the ServiceConfiguration section of the ABCS that is being extended.

   For example, if you want InForm Requester ABCS to call an external web service, go to Service Configuration with service name as {http://xmlns.oracle.com/ABCSImpl/InForm/Core/ReportDrugSafetyReportInFormReqABCSImpl/V1}ReportDrugSafetyReportInFormReqABCSImpl.

3. Based on your requirement for control logic, set one of the following extension points to True.

   In a requester ABCS, enable one of the following:

   • PreXformABMtoEBM - Invokes an external web service before ABM to EBM transformation.

   • PreInvokeEBS - Invokes an external web service before invoking EBS.

   In a provider ABCS, enable one of the following:

   • PreXformEBMtoABM - Invokes an external web service before EBM to ABM transformation.

   • PreInvokeABS - Invokes an external web service before invoking Application Business Service (ABS).

4. Save AIAConfigurationProperties.xml.

5. Upload it to the MDS using the following steps:

   1. Navigate to the $AIA_INSTANCE/config directory.

   2. Copy UpdateMetaDataDp.xml to a backup file.

   3. Edit UpdateMetaDataDp.xml file as follows:

      <?xml version="1.0" standalone="yes"?><DeploymentPlan component="Metadata" version="3.0"><Configurations><UpdateMetadata wlserver="fp" ><fileset dir="${AIA_INSTANCE}/AIAMetaData"><include name="config/AIAConfigurationProperties.xml"/></fileset></UpdateMetadata></Configurations></DeploymentPlan>
      

   4. Navigate to the $AIA_INSTANCE/bin directory.

   5. Execute the following commands:

      For Windows: execute aiaenv.bat

      ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml

      For Linux: source aiaenv.sh

      ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml

   6. Wait till you see a build successful result.

6. Open the extension service concrete WSDL for the ABCS that is being extended. For example, if InForm Requester ABCS is being extended to call an external web service, open the file <AIA_HOME>/AIAMetaData/AIAComponents/ExtensionServiceLibrary/InForm/ ReportDrugSafetyReportInFormReqABCSImplExtensionConcrete.wsdl.

7. Locate the soap:address section of the WSDL towards the end of the file.

8. Replace the Mirror Servlet location (http://soaserverhost:soaserverport/MirrorServlet/mirror) with the actual web service endpoint.

9. Save the concrete WSDL.

10. Upload it to the MDS using the following steps:

    1. Navigate to the $AIA_INSTANCE/config directory.

    2. Copy UpdateMetaDataDp.xml to a backup file.

    3. Edit UpdateMetaDataDp.xml file as follows:

       <?xml version="1.0" standalone="yes"?>�
       <DeploymentPlan component="Metadata" version="3.0">�
       <Configurations>�
       <UpdateMetadata wlserver="fp">�
       <fileset dir="${AIA_HOME}/AIAMetaData">�
       <include name="AIAComponents/ExtensionServiceLibrary/InForm/ ReportDrugSafetyReportInFormReqABCSImplExtensionConcrete.wsdl"/>�
       </fileset>�
       </UpdateMetadata>�
       </Configurations>�
       </DeploymentPlan>
       

    4. Navigate to the $AIA_INSTANCE/bin directory.

    5. Execute the following commands:

       For Windows: execute aiaenv.bat

       ant -f %AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml�

       For Linux: source aiaenv.sh

       ant -f $AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml�

    6. Wait till you see a build successful result.

3.12 Finding Oracle Enterprise Manager Instances Using Composite Sensors

Oracle Enterprise Manager (OEM) can be used to monitor application servers, web services, and instance data of the integration pack. OEM allows administrator users to step through detailed flow trace for a given transaction, to view and search log files, and generate alerts for specific events.

You can monitor SOA composite instances at runtime using composite sensors. Composite sensors lets you search for instances using certain parameters. For example, a composite instance fails at some point in the flow. You can search for that failed composite instance on Enterprise Manager using a predefined composite sensor (for example, trial name) in the search field.

The following composite sensors are available to monitor composite instances during the runtime:

Table 3-11 Composite Sensors

Field Name	Composite Names
Trial Name	ReportDrugSafetyReportInFormReqABCSImpl, ReportDrugSafetyReportArgusProvABCSImpl
Subject ID	ReportDrugSafetyReportInFormReqABCSImpl, ReportDrugSafetyReportArgusProvABCSImpl
CASE ID	ReportDrugSafetyReportResponseArgusReqABCSImpl, ReportDrugSafetyReportResponseInFormProvABCSImpl
World Wide Unique Identifier	ReportDrugSafetyReportResponseArgusReqABCSImpl
Safety Event ID	ReportDrugSafetyReportResponseInFormProvABCSImpl

3.13 Error Handling

Table 3-12 Error Handling

Problem	Solution
Instances are not getting generated in the AIA layer when InForm user clicks Submit.	Perform one of the following: Check the Windows event log on the InForm Publisher machine to see if any errors occurred. For more details, see the InForm Publisher documentation. In the InForm Publisher Configuration screen, verify if the EndPoint URL is correct.
InFormDrugSafetyReportJMSProducer is in faulted state with an error message: Trial name (<name of the trial>) is not configured in the integration layer.	Verify that InForm trial name is present in upper cases in the INFORM_TRIAL_NAME column of HS_TRIAL_SAFETY_CONFIG dvm.
E2B files are not written to Argus in folder.	Perform one of the following: On Enterprise Manager console, verify that SOA composite instances are not in error status. If they are in error status, check for the root cause of the error by navigating to the detailed flow trace. Integration server admin user gets an email when there are errors. Check the mount point between the integration SOA server and Argus Interchange folder is intact. If Argus Safety installation is multi-tenant, ensure that enterprise-specific folders are created under in, out, and ack-archive directories. Also, ensue that HS_TRIAL_SAFETY_CONFIG.dvm has the correct enterprise name in ARGUS_ENT_NAME for a given InForm trial.
Email notifications are not coming.	Perform one of the following: Ensure the email addresses are entered correctly in the Oracle User Messaging Service standalone user interface: http://<soa-host>:<soa-port>/sdpmessaging/userprefs-ui Ensure that the messaging channel name you enter corresponds to an error handling user role name you have created. When logging into Oracle User Messaging Service, use the credentials of user role name not the credentials of WebLogic admin user.
Updates to AIAConfigurationProperties.xml are not reflected in the actual business flow.	Perform one of the following: Ensure that any changes to AIAConfigurationProperties.xml are uploaded to MDS. Update file set element at $AIA_INSTANCE/config/UpdateMetaDataDP.xml to point to the location of AIAConfigurationProperties.xml. Use the following commands to upload the file to the MDS: For Windows: %AIA_INSTANCE%\bin\aiaenv.bat ant -f \%AIA_HOME%\Infrastructure\Install\config\UpdateMetaData.xml For Linux: source $AIA_INSTANCE/bin/aiaenv.sh ant -f /$AIA_HOME/Infrastructure/Install/config/UpdateMetaData.xml
E2B file is rejected by Argus with the following error message: The element PRIMARYSOURCECOUNTRY MUST have a length of 2 or less as specified by the ICH. Current length: 3. Stored Procedure: M2_VALIDATION.	Ensure that COUNTRY.dvm has appropriate country codes listed in the INFORM_01 column. DVM values can be added or modified using the following: http://soaserverhost:soaserverport/soa/composer
E2B file is rejected by Argus with the following error message: No primary receive agency is configured for the message - <message identifier> File Name: <filename.xml>”.	Ensure that the Reporting Destination configuration in Argus Console has the agency identifier or company identifier values that match messagesenderidentifier and messagereceiveridentifier values. The default values are INFORM_01 and ARGUS_01 respectively.
Duration, Patient Weight, Patient Height fields are sent from InForm but they do not appear in Argus.	Check if unit of measure values are specified in InForm for each of these fields. If units are not specified, these fields are not written to Argus E2B. SOA administrator and certain users can be configured to get an email when such fields are not written to E2B file and thus do not appear in the Argus case.
Certain values are truncated in Argus.	When values of certain fields in E2B exceed maximum length of those fields in Argus Safety, then such E2B file is auto-rejected by Argus. Integration can be configured to truncate values of the fields that exceed maximum length. In AIAConfigurationProperties.xml, when the value of the property TruncateFields is set to truncate, the integration truncates value of fields that exceed maximum length. If it is set to warning, the integration truncates values of fields that exceed maximum length and sends a warning email notification to the users who are configured to receive such emails. When this property is set to notruncation, values are not truncated and Argus will auto-reject the message.
Safety event is not sent to the Integration layer and you see security error with the following message on event viewer log where InForm Publisher is running: MessageInformationHeaderRequired - SOAP fault	InForm Publisher is not sending the correct message security headers. Ensure that the trial is configured to send user name token authentication parameters in the InForm Publisher configuration screen. To send user name token to the integration, the integration endpoint must be SSL enabled. Ensure that SSL is enabled on the integration server.
Safety Event is not sent to Integration layer and you see one of the following security errors on event viewer log where InForm Publisher is running: Could not connect to the server Page not found SSLKeyException SOAP fault javax.net.ssl.SSLHandshakeException	Ensure that SSL is configured correctly on the integration layer. One of the reasons for SSL Handshake failure could be that https endpoint is not trusted by the InForm Publisher. Ensure that: SSL trust certificate of the AIA web service is loaded into InForm trust keystore Certificate in InForm keystore is not expired or invalid InForm Publisher retries sending the message to the target endpoint after the issue is resolved, provided maximum number of retries is not exceeded.
In the acknowledgement flow, case status is not getting updated on InForm.	Check InForm Adapter properties are configured correctly either in HS_TRIAL_SAFETY_CONFIG.DVM or AIAConfigurationProperties.xml. In HS_TRIAL_SAFETY_CONFIG.dvm, verify the values configured for INFORM_ADAPTER_URL, INFORM_ADAPTER_AUTH_KEY, and INFORM_ ADAPTER_TRANS_USER for the given trial. If you have used configuration wizard to set the InForm Adapter properties, verify the properties INFORM_01.InFormAdapterURL, INFORM_01.InFormAdapterTransUser, and INFORM_01.InFormAdapterAuthKey are configured correctly in AIAConfifugrationProperties.xml. If the values are not correct, update AIAConfigurationProperties.xml with the correct values and upload the file to the MDS. For more information, see Section 3.6.