Log in as the Administrator.
Copy the installation package to the local directory of the target machine.
Open the Argus Safety folder and click setup.exe.
In the Argus Safety Setup screen, click Next >.
Enter the customer User Name and Company Name, and click Next >.
In the Default Directory screen, click Browse to select the default installation directory where the Argus Safety Solution Components will be installed and click Next >.
In the component list, select the modules to install and click Next >.
In the Argus Safety Solution Components Report Directory screen:
Click Browse, select the folder to store the temporary reports in and click OK.
Click Next >.
Argus installs and shows the progress of the installation.
Enter the Port for the Argus website (default is 8083, and can be changed to port 80 at any time) and click Next >.
The website and its related components are installed.
In the Setup Completed screen, click Finish.
Click OK to reboot the system.
Set up the Argus Cryptography Key. Refer to Section 21.1.3, "Argus Safety 8.1.2 Application Servers.".
Configure Argus Safety Service user passwords. Refer to Section 21.2.4, "Generate Encrypted String."
To make the latest data or configurations available to the rest of the system, reset IIS when the changes have been made to the following areas:
Changes in config files:
Argus.ini
Argus.xml
Changes in following screens through Console:
Common Fields
System Management
Enabled Modules
Loading of MedDRA and WHO Drug dictionaries (J Drug is optional).
The Argus Web Service Interface supports outbound Interfaces (MedDRA, WHO Drug and LOT Number) which provide the capability to integrate with customer-hosted web services and inbound web services (the Product-Study-License Interface) hosted on the Argus Safety Web Server.
All web service-based interfaces communicate with the standard SOAP 1.2 Protocol and use WS-Addressing and WS-Security. The Argus web service interface leverages Windows Communication Foundation to generate WS-Addressing and WS-Security header information. We recommended testing this message before moving too far into business testing. For more information on these specifications, see the OASIS and W3C websites.
You can edit a standard .config file to select which integrations to enable, which transport protocol to use, and authentication details.
All errors are handled through a SOAP fault. Should an error occur, logical or otherwise, a SOAP fault should be thrown by the host and caught by the client. The client application (web) of Argus displays the details of the SOAP fault to the user when possible. Argus web services throw SOAP faults when an error occurs.
The Argus Safety web service interface in this release supports the following integrations through Web Service:
| Interface | Description |
|---|---|
| MedDRA (outbound) | MedDRA Drug web service interface provides a mechanism to integrate customer-hosted MedDRA coding systems with Argus Safety via web services. |
| WHO Drug (outbound) | WHO Drug web service interface provides a mechanism to integrate customer-hosted WHO coding systems with Argus Safety via web services. |
| Lot Query (outbound) | Lot Number web service interface provides a mechanism to integrate customer-hosted central product information systems with Argus Safety via web services. |
| Product Study License(PSL) - (inbound) | PSL web service interface provides a mechanism to integrate customer central system to push or query PSL data via web services hosted on the Argus Safety Web Server. |
In a multi-tenant Argus system:
Endpoint configuration of central MedDRA and WHO Drug web service is at the global level. Enterprise if configured to use MedDRA and WHO Drug web service interface uses same endpoint to connect.
Endpoint configuration of Lot Number Interface is defined at an enterprise level. Enterprise if configured to use Lot Interface uses enterprise specific endpoint configuration.
Outbound Interface: Message payload must have an 'EnterpriseShortName'.
Inbound Interface: Message payload must have an 'EnterpriseShortName'.
Each outbound/inbound web service request/response is enclosed in a SOAP envelope that begins with a SOAP header, followed by a Body statement that contains a unique node under the SAFETY_MESSAGE node. This node uniquely identifies the Interface being used for Inbound/Outbound communication. When implementing the customer side of the interface, follow the structure defined by Oracle in the XSD/WSDL files located in the following directory:
<Argus Web Install Path>\Integrations\XSD
<Argus Web Install Path>\Integrations\WSDL
For example, C:\Progam Files\Oracle\ArgusWeb\ASP\Integrations\XSD
Navigate to the root of the ArgusWeb directory.
Open the web.config file in a text editor.
By default, the bindings are provided for:
basic HTTP traffic
basic SSL communication
Update the address attribute of the endpoint nodes to point to the correct web service address.
To use encryption, set the bindingConfiguration attribute of the endpoint node as WSHttpBinding_IRelsysService_Secure.
Additional binding configurations may also be created and used.
Note that the binding configurations between the host and the client must be compatible for successful communication.
To transmit the authentication information, add credentials in the ClientCredentials section of each endpoint node.
To transform messages, use either a custom transformation assembly or an XSLT. Lot Number and WHO Drug coding interfaces leverages this feature.
Update the TransformerConfiguration section to map an endpoint to a transformer.
If multiple transformers are specified for a particular endpoint, they are executed in the order in which they appear in the configuration file.
The transformers configured by Oracle should not be modified, but additional transformers may be added if necessary.
All inbound integrations (file based) are handled by the Argus Safety Windows Service.
Navigate to the .\ArgusWeb\ASP\Argus.NET\Bin directory.
Open the RelsysWindowsService.exe.config file in a text editor.
This configuration file provide reference configuration files of the configured integrations.
To enable an integration, in the RelsysConfigurationFiles section, uncomment the required add node (s).
To disable an integration, in the RelsysConfigurationFiles section, comment the required add node (s).
In the DatabaseConfiguration section, enter the database credentials.
The XML message required by each integration varies and is defined by its own schema. However, each schema follows a standard. The root node of every XML Safety Message in inbound and outbound interface is SAFETY_MESSAGE with the following node or attribute:
| Node/Attribute Name | Description |
|---|---|
| Type | This is an enumeration (currently either "Request" or "Response") to identify the directionality of the message. |
| EnterpriseShortName |
|
| EXTENSION | Every Safety Message may also contain an EXTENSION node with CUSTOM sub nodes. These are for future expandability and currently unused. |
The MedDRA Encoding Web Service Interface integrates customer-hosted central MedDRA dictionary web service with Argus Safety. Argus Safety expects the data from the central MedDRA dictionary web service in a defined format as specified by the MedDRA dictionary schema.
In a multi-tenant setup, endpoint configuration of central the MedDRA web service is stored at global level and all the enterprises in Argus Safety uses the same web service endpoint. The EnterpriseShortName attribute present in the request message payload identifies which enterprise has initiated the web service request.
This interface supports both English and Japanese MedDRA dictionaries. To integrate the MedDRA Encoding Web Service Interface with:
English dictionary, refer to Section 19.7.3.5, "Request (V 1.0)" and Section 19.7.3.4, "Response (V 1.1)".
Japanese dictionary (without support for the J term currency detail), refer to Section 19.7.3.3, "Request (V 1.1)" and Section 19.7.3.4, "Response (V 1.1)".
Japanese dictionary (with support for the J term currency detail), refer to Section 19.7.3.1, "Request (V 2.0)" and Section 19.7.3.2, "Response(V2.0)"
From Argus Safety Web, open Console and select System Configuration > System Management.
Expand the Case Processing tree branch, then and select Dictionary Browser.
To use web services, select the Argus Safety MedDRA Coding Method radio button.
If the web service hosting MedDRA is not available, fails, or does not return a valid match, check the Use Local MedDRA if Term not found by Web Services checkbox. (Optional)
To use local MedDRA J, check the Use Local MedDRA for Japanese terms checkbox.
Navigate to ArgusWeb/ASP.
Open the web.config file in a text editor.
Search for endpoint and update the following attributes:
address—to point to the correct web service address
name—MedDRA
bindingConfiguration—to use encryption
Note that the binding configurations between the host and the client must be compatible for successful communication.
The endpoint configuration might look something like this:
<endpoint address="http://remotewebservice/MedDRAAutoEncode.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IRelsysService_ Unsecure" contract="IRelsysService" name="MedDRA">
Navigate to ArgusWeb/ASP/Argus.NET.
Open the web.config file in a text editor.
Search for endpoint and update the following attributes:
address—to point to the correct web service address
name—MedDRA
key—version of MedDRA XML being used
For example,
<add key="MedDRAXMLVersion" value="2.0"/>, or
<add key="MedDRAXMLVersion" value="1.1"/>, or
<add key="MedDRAXMLVersion" value="1.0"/>
bindingConfiguration—to use encryption
Note that the binding configurations between the host and the client must be compatible for successful communication.
paths—to add path for both the Request and Response XSDs based on the version being used
For example,
<add InputXSD="..\..\Integrations\XSD\v2.0\MedDRA_Response.xsd" />
<add InputXSD="..\..\Integrations\XSD\v2.0\MedDRA_Request.xsd" />
When Argus Safety makes a call to the web service, it populates the REPORTED and CODED nodes with data entered by the user. The REPORTED term is essentially a verbatim term while the coded term is the term that is expected to be coded by the remote system. The returned message contains a PATHS node with PATH sub-nodes that have been encoded by the remote system. Argus Safety displays the returned LLTs in the MedDRA browser from which you can select the correct LLT. Note that the MedDRA Browser does not open on the Case Bookin screen.
If autoencoding is enabled and finds an exact match, Argus Safety places the encoded LLT term in the case form. If autoencoding finds multiple matches, the system uses the primary path. If autoencoding is not enabled or does not find any matches, or the web service is unavailable, Argus Safety loads the MedDRA browser with local dictionary information, if the system is configured to allow this.
The following examples use Pain as the search term for encoding of each version of the XML.
Note that the question mark (?) in the examples are in place of the Japanese characters.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1">http://www.oracle.com/Argus/Contract/v1.0/IRelsysService/Rels ysServiceRequest</a:Action> <a:MessageID>urn:uuid:c5b40ac0-a11e-44ea-b3c5-a39636058d63</a:MessageID> <ActivityId CorrelationId="1872b16d-c293-4abc-8e5c-9ecdab7d3147" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"> 00000000-0000-0000-3100-0060000000f0 </ActivityId> <a:ReplyTo> <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="1">http://10.178.87.5/interface/RelsysService.svc</a:To> </s:Header> <s:Body> <RelsysServiceRequest xmlns="http://www.oracle.com/Argus/Contract/v1.0"> <Msg xmlns:d4p1="http://www.oracle.com/Argus/Types/v1.0" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <d4p1:Version>1.0</d4p1:Version> <d4p1:TransformID /> <d4p1:SafetyMessage> <tnsa:SAFETY_MESSAGE xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:tnsa="http://www.oracle.com/Argus/MedDRA_Request/v2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tns:Type="Request"> <tnsa:MEDICAL_DICTIONARY Action="Auto" Source="INDICATION"> <tnsa:TERM> <tnsa:REPORTED>pain</tnsa:REPORTED> <tnsa:CODED>pain</tnsa:CODED> <tnsa:LANG>E</tnsa:LANG> </tnsa:TERM> </tnsa:MEDICAL_DICTIONARY> </tnsa:SAFETY_MESSAGE> </d4p1:SafetyMessage> </Msg> </RelsysServiceRequest> </s:Body> </s:Envelope>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> <a:Actions:mustUnderstand="1"> http://www.oracle.com/Argus/Contract/v1.0/IRelsysServic e/RelsysServiceRequestResponse </a:Action> <ActivityId CorrelationId="12dda93b-e6fa-4d3a-8d2f-a5cc34588e8a" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"> 0000000 0-0000-0000-7600-0060000000f3 </ActivityId> </s:Header> <s:Body> <RelsysServiceRequestResponse xmlns="http://www.oracle.com/Argus/Contract/v1.0"> <RelsysServiceRequestResult xmlns:b="http://www.oracle.com/Argus/Types/v1.0" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <b:Version>1.0</b:Version> <b:TransformID /> <b:SafetyMessage> <tnsa:SAFETY_MESSAGE xsi:noNamespaceSchemaLocation="http://www.oracle.com/Argus/MedDRA_ Response/v2.0 file:///C:/SS/6 - Argus Interfaces/ASI 6x/RelsysInterfaceLibrary.root/RelsysInterfaceLibrary/RelsysInterfaceComponents/ XSD/v2.0/MedDRA_Response.xsd" tns:Type="Response" xmlns:tnsa="http://www.oracle.com/Argus/MedDRA_Response/v2.0" xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tnsa:MEDICAL_DICTIONARY> <tnsa:PATHS> <tnsa:PATH Primary="Y"> <tnsa:LLT> <tnsa:TEXT>Pain</tnsa:TEXT> <tnsa:CODE>10033371</tnsa:CODE> <tnsa:TEXT_J>??</tnsa:TEXT_J> <tnsa:CURRENCY_J>Y</tnsa:CURRENCY_J> <tnsa:SYNS /> </tnsa:LLT> <tnsa:PT> <tnsa:TEXT>Pain</tnsa:TEXT> <tnsa:CODE>100333712</tnsa:CODE> <tnsa:TEXT_J>??</tnsa:TEXT_J></tnsa:PT> <tnsa:HLT> <tnsa:TEXT>Pain and discomfort NEC</tnsa:TEXT> <tnsa:CODE>10033372</tnsa:CODE> <tnsa:TEXT_J>????????NEC</tnsa:TEXT_J> </tnsa:HLT> <tnsa:HLGT> <tnsa:TEXT>General system disorders NEC</tnsa:TEXT> <tnsa:CODE>10018073</tnsa:CODE> <tnsa:TEXT_J>????NEC</tnsa:TEXT_J> </tnsa:HLGT> <tnsa:SOC> <tnsa:TEXT>General disorders and administration site conditions</tnsa:TEXT> <tnsa:CODE>10018065</tnsa:CODE> <tnsa:TEXT_J>?????????????</tnsa:TEXT_J> </tnsa:SOC> </tnsa:PATH> </tnsa:PATHS> </tnsa:MEDICAL_DICTIONARY> <tns:EXTENSION> <tns:CUSTOM tns:Name="string" tns:Metadata="string">string</tns:CUSTOM> </tns:EXTENSION> </tnsa:SAFETY_MESSAGE> </b:SafetyMessage> </RelsysServiceRequestResult> </RelsysServiceRequestResponse> </s:Body> </s:Envelope>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1">http://www.oracle.com/Argus/Contract/v1.0/IRelsysService/Rels ysServiceRequest</a:Action> <a:MessageID>urn:uuid:c5b40ac0-a11e-44ea-b3c5-a39636058d63</a:MessageID> <ActivityId CorrelationId="1872b16d-c293-4abc-8e5c-9ecdab7d3147" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"> 00000000-0000-0000-3100-0060000000f0 </ActivityId><a:ReplyTo> <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="1">http://10.178.87.5/interface/RelsysService.svc</a:To> </s:Header> <s:Body> <RelsysServiceRequest xmlns="http://www.oracle.com/Argus/Contract/v1.0"> <Msg xmlns:d4p1="http://www.oracle.com/Argus/Types/v1.0" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <d4p1:Version>1.0</d4p1:Version> <d4p1:TransformID /> <d4p1:SafetyMessage> <tnsa:SAFETY_MESSAGE xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:tnsa="http://www.oracle.com/Argus/MedDRA_Request/v1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tns:Type="Request"> <tnsa:MEDICAL_DICTIONARY Action="Auto" Source="INDICATION"> <tnsa:TERM> <tnsa:REPORTED>pain</tnsa:REPORTED> <tnsa:CODED>pain</tnsa:CODED> <tnsa:LANG>E</tnsa:LANG> </tnsa:TERM> </tnsa:MEDICAL_DICTIONARY> </tnsa:SAFETY_MESSAGE> </d4p1:SafetyMessage> </Msg> </RelsysServiceRequest> </s:Body> </s:Envelope>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> <a:Actions:mustUnderstand="1"> http://www.oracle.com/Argus/Contract/v1.0/IRelsysServic e/RelsysServiceRequestResponse </a:Action> <ActivityId CorrelationId="12dda93b-e6fa-4d3a-8d2f-a5cc34588e8a" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"> 0000000 0-0000-0000-7600-0060000000f3 </ActivityId> </s:Header> <s:Body> <RelsysServiceRequestResponse xmlns="http://www.oracle.com/Argus/Contract/v1.0"> <RelsysServiceRequestResult xmlns:b="http://www.oracle.com/Argus/Types/v1.0" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <b:Version>1.0</b:Version> <b:TransformID /> <b:SafetyMessage> <tnsa:SAFETY_MESSAGE xsi:noNamespaceSchemaLocation="http://www.oracle.com/Argus/MedDRA_ Response/v1.1 file:///C:/SS/6 - Argus Interfaces/ASI 6x/RelsysInterfaceLibrary.root/RelsysInterfaceLibrary/RelsysInterfaceComponents/ XSD/v1.1/MedDRA_Response.xsd" tns:Type="Response" xmlns:tnsa="http://www.oracle.com/Argus/MedDRA_Response/v1.1" xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tnsa:MEDICAL_DICTIONARY> <tnsa:PATHS> <tnsa:PATH Primary="Y"> <tnsa:LLT> <tnsa:TEXT>Pain</tnsa:TEXT> <tnsa:CODE>10033371</tnsa:CODE> <tnsa:TEXT_J>??</tnsa:TEXT_J> <tnsa:SYNS /> </tnsa:LLT> <tnsa:PT> <tnsa:TEXT>Pain</tnsa:TEXT> <tnsa:CODE>100333712</tnsa:CODE> <tnsa:TEXT_J>??</tnsa:TEXT_J> </tnsa:PT> <tnsa:HLT> <tnsa:TEXT>Pain and discomfort NEC</tnsa:TEXT> <tnsa:CODE>10033372</tnsa:CODE> <tnsa:TEXT_J>????????NEC</tnsa:TEXT_J> </tnsa:HLT> <tnsa:HLGT> <tnsa:TEXT>General system disorders NEC</tnsa:TEXT> <tnsa:CODE>10018073</tnsa:CODE> <tnsa:TEXT_J>????NEC</tnsa:TEXT_J> </tnsa:HLGT> <tnsa:SOC> <tnsa:TEXT>General disorders and administration site conditions</tnsa:TEXT> <tnsa:CODE>10018065</tnsa:CODE> <tnsa:TEXT_J>?????????????</tnsa:TEXT_J> </tnsa:SOC> </tnsa:PATH> </tnsa:PATHS> </tnsa:MEDICAL_DICTIONARY> <tns:EXTENSION> <tns:CUSTOM tns:Name="string" tns:Metadata="string">string</tns:CUSTOM> </tns:EXTENSION> </tnsa:SAFETY_MESSAGE> </b:SafetyMessage> </RelsysServiceRequestResult> </RelsysServiceRequestResponse> </s:Body> </s:Envelope>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1"> http://www.oracle.com/Argus/Contract/v1.0/IRelsysServic e/RelsysServiceRequest </a:Action> <a:MessageID>urn:uuid:c5b40ac0-a11e-44ea-b3c5-a39636058d63</a:MessageID> <ActivityId CorrelationId="1872b16d-c293-4abc-8e5c-9ecdab7d3147" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"> 0000000 0-0000-0000-3100-0060000000f0 </ActivityId> <a:ReplyTo> <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="1">http://10.178.87.5/interface/RelsysService.svc</a:To> </s:Header> <s:Body> <RelsysServiceRequest xmlns="http://www.oracle.com/Argus/Contract/v1.0"> <Msg xmlns:d4p1="http://www.oracle.com/Argus/Types/v1.0" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <d4p1:Version>1.0</d4p1:Version> <d4p1:TransformID /> <d4p1:SafetyMessage> <tnsa:SAFETY_MESSAGE xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:tnsa="http://www.oracle.com/Argus/MedDRA_Request/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tns:Type="Request"> <tnsa:MEDICAL_DICTIONARY Action="Auto" Source="INDICATION"> <tnsa:TERM> <tnsa:REPORTED>pain</tnsa:REPORTED> <tnsa:CODED>pain</tnsa:CODED> </tnsa:TERM> </tnsa:MEDICAL_DICTIONARY> </tnsa:SAFETY_MESSAGE> </d4p1:SafetyMessage> </Msg> </RelsysServiceRequest> </s:Body> </s:Envelope>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Header> <a:Action s:mustUnderstand="1"> http://www.oracle.com/Argus/Contract/v1.0/IRelsysServic e/RelsysServiceRequestResponse </a:Action> <ActivityId CorrelationId="12dda93b-e6fa-4d3a-8d2f-a5cc34588e8a" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics"> 0000000 0-0000-0000-7600-0060000000f3 </ActivityId> </s:Header> <s:Body> <RelsysServiceRequestResponse xmlns="http://www.oracle.com/Argus/Contract/v1.0"> <RelsysServiceRequestResult xmlns:b="http://www.oracle.com/Argus/Types/v1.0" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <b:Version>1.0</b:Version> <b:TransformID /> <b:SafetyMessage> MedDRA Integration 14-10 Oracle Argus Safety Installation Guide <tnsa:SAFETY_MESSAGE xsi:noNamespaceSchemaLocation="http://www.oracle.com/Argus/MedDRA_ Response/v1.0 file:///C:/SS/6 - Argus Interfaces/ASI 6x/RelsysInterfaceLibrary.root/RelsysInterfaceLibrary/RelsysInterfaceComponents/ XSD/v1.0/MedDRA_Response.xsd" tns:Type="Response" xmlns:tnsa="http://www.oracle.com/Argus/MedDRA_Response/v1.0" xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tnsa:MEDICAL_DICTIONARY> <tnsa:PATHS> <tnsa:PATH Primary="Y"> <tnsa:LLT> <tnsa:TEXT>Pain</tnsa:TEXT> <tnsa:CODE>10033371</tnsa:CODE> <tnsa:SYNS /> </tnsa:LLT> <tnsa:PT> <tnsa:TEXT>Pain</tnsa:TEXT> <tnsa:CODE>100333712</tnsa:CODE> </tnsa:PT> <tnsa:HLT> <tnsa:TEXT>Pain and discomfort NEC</tnsa:TEXT> <tnsa:CODE>10033372</tnsa:CODE> </tnsa:HLT> <tnsa:HLGT> <tnsa:TEXT>General system disorders NEC</tnsa:TEXT> <tnsa:CODE>10018073</tnsa:CODE> </tnsa:HLGT> <tnsa:SOC> <tnsa:TEXT>General disorders and administration site conditions</tnsa:TEXT> <tnsa:CODE>10018065</tnsa:CODE> </tnsa:SOC> </tnsa:PATH> </tnsa:PATHS> </tnsa:MEDICAL_DICTIONARY> <tns:EXTENSION> <tns:CUSTOM tns:Name="string" tns:Metadata="string">string</tns:CUSTOM> </tns:EXTENSION> </tnsa:SAFETY_MESSAGE> </b:SafetyMessage> </RelsysServiceRequestResult> </RelsysServiceRequestResponse> </s:Body> </s:Envelope>
Schema files for request and response are located in the <Argus Web Install Path>\Integrations\XSD directory.
Verify the MedDRA Interface request and response functions for the following schema files.
Argus Safety makes a web service request to the externally hosted central product information system as defined in this schema.
Schema File
Version 1.0
Top level file: \v1.0\MedDRA_Request.xsd
Sublevel file: \v1.0\Base.xsd
Version 1.1
Top level file: \v1.1\MedDRA_Request.xsd
Sublevel file: \v1.0\Base.xsd
Version 2.0
Top level file: \v2.0\MedDRA_Request.xsd
Sublevel file: \v1.0\Base.xsd
Namespace
http://www.oracle.com/Argus/MedDRA_Request/v1.0
http://www.oracle.com/Argus/MedDRA_Request/v1.1
http://www.oracle.com/Argus/MedDRA_Request/v2.0
Node/Attribute Name Description
The MEDICAL_DICTIONARY node is the first child node identifying MedDRA integration.
Argus Safety expects the central MedDRA dictionary to send the response in this format.
Schema File
Version 1.0
Top level file: \v1.0\MedDRA_Response.xsd
Sublevel file: \v1.0\Base.xsd
Version 1.1
Top level file: \v1.1\MedDRA_Response.xsd
Version 2.0
Top level file: \v2.0\MedDRA_Response.xsd
Namespace
http://www.oracle.com/Argus/MedDRA_Response/v1.0
http://www.oracle.com/Argus/MedDRA_Response/v1.1
http://www.oracle.com/Argus/MedDRA_Response/v2.0
Node/Attribute Name Description
| Node/Attribute Name | Description |
|---|---|
| Action | Must have the value Auto.
This attribute must be present in the request when a full hierarchy is required to be passed back to auto encode the term without using the MedDRA Browser. With an "Auto" message, the system requires that an LLT Term be passed in the request. If the full hierarchy is not found or returned, the system will open the MedDRA Browser and display the LLTs returned for manual encoding by the user using the local MedDRA instance. If multiple paths are returned, the Primary SOC path is used. |
| Source | An enumerated value that specifies additional information that may be required for coding based on origination as follows:
|
| Term
(v 1.0) |
The TERM node specifies the information about a specific term that is either being looked up or populated with data and supports Reported and Coded nodes. |
| Term
(v 1.1/2.0) |
The TERM node specifies the information about a specific term that is either being looked up or populated with data and supports Reported, Coded, and Lang nodes. |
| Primary | The Primary attribute is Y if the term is the Primary SOC path for the selected term. In the event that multiple terms are returned for a MedDRA level, this attribute is only be available on the primary term. |
| PATHS/PATH
(version 1.0) |
The PATHS node has a PATH subnode for each MedDRA hierarchy returned. MedDRA hierarchy with English terms only. |
| PATHS/PATH(version 1.1) | Contains MedDRA hierarchy with English and Japanese terms (without support for the J term currency detail). |
| PATHS/PATH
(version 2.0) |
Contains MedDRA hierarchy with English and Japanese terms (with support for the J term currency detail) for the LLT term. |
This section provides information for integrating with an external Product Study License configuration system.
Detailed steps and examples on using the PSL interface are available through the Technical Reference Manuals (TRMs). Customers can download these TRMs through the Oracle Consulting or Customer Support teams.
Navigate to <Install Path>\Oracle\ArgusWeb\ASP\Integrations.
Open the Service.config file in a text editor.
Search for DatabaseConfiguration, and update the following attributes:
DBName—TNS of the Argus database.
DBUser—User name of a Argus Safety Service user. The PSL web service uses this User Context to perform updates in the Argus Safety Database.
DBPassword—New encrypted password string. See Section 21.2.4, "Generate Encrypted String."
To secure the configuration, set the bindingConfiguration attribute either manually or through the Service Config utility.
Additional binding configurations may also be created and used.
Note that the binding configurations between the host and the client must be compatible for successful communication.
To add logging information, use one of the following:
Relsys Logger—Logs information about errors, warnings, and processing of the PSL web service code. The logger internally uses log4net component to perform the logging.
Update the logConfig attribute with one of the following values:
Error (default)
Warning
Information
Verbose
To save log as a specific file, update RollingLogFileAppender with the filename. Make sure the web service has read/write permissions to this folder.
SOAP Message RequestLogger—Logs all the incoming and outgoing SOAP messages of the PSL web service. The messages are stored internally in the Argus Safety Database and are not available for querying.
To disable this logging, set Enabled as false.
<TransformersConfiguration> <Transformers> <add Transformer="RequestLogger" InterfaceType="Inbound" RequestType="Request,Response" MessageType="SoapMessage" Enabled="False" Metadata="" Assembly="ConsoleInterface" Type="Relsys.ArgusConsole.ConsoleInterface.Common.DBLoggerFactory" /> </Transformers> </TransformersConfiguration>
WHO Drug web service Interface provides a mechanism to integrate customer-hosted central WHO Drug coding web service with Argus Safety. Argus Safety expects the data from central WHO Drug Coding system in defined format as specified by WHO Drug Coding schema.
In a multi-tenant setup, endpoint configuration of central WHO drug coding web service is stored at global level and all enterprises in Argus Safety will use the same web service endpoint. 'EnterpriseShortName' attribute will be present in the request message payload to identify which Enterprise initiated the web service request.
Argus Console
Drug Dictionary integration must be enabled using Argus Console. This can be done by opening Console from Argus Web and selecting "System Configuration > System Management" from the menu. Expand the "Case Processing" tree branch and select "Dictionary Browser". Select the radio button to use web services under the "Argus Safety WHO Drug Coding Method" section.
An optional checkbox is also available to determine whether Argus has to use the local WHODrug instance if the web service hosting the drug dictionary is not available, fails, or does not return a valid match.
Web.Config
Web.config file on each web server under must have the endpoint with the "name" attribute of "WHODrug" properly configured. At a minimum, the "address" attribute must be changed. Optionally, depending on the bindings employed, the "bindingConfiguration" attribute may also need to be changed. The 'BindingConfiguration' section must have a valid binding for the configured "bindingConfiguration" attribute.
Sample endpoint configuration with binding configuration:
<endpoint address="http://remotewebservice/WHODrugLookup.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IRelsysService_ Unsecure" contract="IRelsysService" name="WHODrug"></endpoint>
When Argus makes a call to the web service, it will populate the 'DRUG_NAME' node. Argus Safety expects the central drug dictionary to populate all possible information in the response XML as per define Drug Dictionary Interface response schema. Argus will display this information in a browser from which the user can select the correct drug.
If the web service does not return any results or is unavailable, Argus will present the user with the WHODrug browser with local dictionary information if the system is configured to allow this.
Note:
If an ingredient is returned that is not in the 'LM_INGREDIENTS' table of Argus, the ingredient will not be stored with the case. ATC code is also not stored with the case data. Both of these items are visible in the browser, however.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Actions:mustUnderstand="1">
http://www.oracle.com/Argus/Contract/v1.0/IRelsysService/RelsysServiceRequest
</a:Action>
<a:MessageID>urn:uuid:7a0f0c6e-f7f9-41f3-85bf-750a00cb16e7</a:MessageID>
<ActivityId CorrelationId="09440b01-70e2-4d24-b12c-202119e3adea"
xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">
0000000
0-0000-0000-8f0f-0060010000f1
</ActivityId>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To
s:mustUnderstand="1">http://10.178.87.5/interface/RelsysService.svc</a:To>
</s:Header>
<s:Body>
<RelsysServiceRequest xmlns="http://www.oracle.com/Argus/Contract/v1.0">
<Msg xmlns:b="http://www.oracle.com/Argus/Types/v1.0"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<b:Version>1.0</b:Version>
<b:TransformID>WHO_DRUG</b:TransformID>
<b:SafetyMessage>
<tnsa:SAFETY_MESSAGE tns:Type="Request"
xmlns:tnsa="http://www.oracle.com/Argus/WHODrug_Request/v1.0"
xmlns:tns="http://www.oracle.com/Argus/Base/v1.0">
<tnsa:DRUG_DICTIONARY>
<tnsa:DRUG>
<tnsa:DRUG_NAME>n22</tnsa:DRUG_NAME>
</tnsa:DRUG>
</tnsa:DRUG_DICTIONARY>
</tnsa:SAFETY_MESSAGE>
</b:SafetyMessage>
</Msg>
</RelsysServiceRequest>
</s:Body>
</s:Envelope>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header>
<a:Action
s:mustUnderstand="1">
http://www.oracle.com/Argus/Contract/v1.0/IRelsysServic
e/RelsysServiceRequestResponse
</a:Action>
<ActivityId CorrelationId="ffb00b07-d1f8-4fa9-ae9f-488d79dda872"
xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">
0000000
0-0000-0000-8f0f-0060010000f1
</ActivityId>
</s:Header>
<s:Body>
<RelsysServiceRequestResponse
xmlns="http://www.oracle.com/Argus/Contract/v1.0">
<RelsysServiceRequestResult
xmlns:d4p1="http://www.oracle.com/Argus/Types/v1.0"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<d4p1:Version>1.0</d4p1:Version>
<d4p1:TransformID />
<d4p1:SafetyMessage>
<tnsa:SAFETY_MESSAGE xmlns:tns="http://www.oracle.com/Argus/Base/v1.0"
xmlns:tnsa="http://www.oracle.com/Argus/WHODrug_Response/v1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.oracle.com/Argus/WHODrug_Response/v1.0
file:///E:/6%20-%20Argus%20Interfaces/ASI%2042%20SP3/RelsysInterfaceLibrary.r
oot/RelsysInterfaceLibrary/RelsysInterfaceComponents/XSD/v1.0/WHODrug_
Response.xsd" tns:Type="Response">
<tnsa:DRUG_DICTIONARY>
<tnsa:DRUGS>
<tnsa:DRUG>
<tnsa:DRUG_CODE>000200.01.005</tnsa:DRUG_CODE>
<tnsa:DRUG_NAME>TYLENOL</tnsa:DRUG_NAME>
<tnsa:GENERIC_NAME>PARACETAMOL</tnsa:GENERIC_NAME>
<tnsa:ATCS>
<tnsa:ATC>
<tnsa:CODE>65GGH</tnsa:CODE>
<tnsa:DESCRIPTION>ATC Desc 1a</tnsa:DESCRIPTION>
</tnsa:ATC>
<tnsa:ATC>
<tnsa:CODE>94534</tnsa:CODE>
<tnsa:DESCRIPTION>ATC Desc 2a</tnsa:DESCRIPTION>
</tnsa:ATC>
</tnsa:ATCS>
<tnsa:INGREDIENTS>
<tnsa:INGREDIENT>PARACETAMOL</tnsa:INGREDIENT>
</tnsa:INGREDIENTS>
<tnsa:MEDICINAL_PRODUCT_ID />
<tnsa:DRUG_MANUFACTURER>
MCNEIL LABORATORIES,
INCORPORATED
</tnsa:DRUG_MANUFACTURER>
</tnsa:DRUG>
<tnsa:DRUG>
<tnsa:DRUG_CODE>
004468.01 begin_of_the_skype_highlighting 004468.01
end_of_the_skype_highlighting.003
</tnsa:DRUG_CODE>
<tnsa:DRUG_NAME>TYLENOL ALLERGY SINUS</tnsa:DRUG_NAME>
<tnsa:GENERIC_NAME />
<tnsa:ATCS>
<tnsa:ATC>
<tnsa:CODE>4UUT1</tnsa:CODE>
<tnsa:DESCRIPTION>ATC Desc 1b</tnsa:DESCRIPTION>
</tnsa:ATC>
<tnsa:ATC>
<tnsa:CODE>13LLP</tnsa:CODE>
<tnsa:DESCRIPTION>ATC Desc 2b</tnsa:DESCRIPTION>
</tnsa:ATC>
</tnsa:ATCS>
<tnsa:INGREDIENTS>
<tnsa:INGREDIENT>PARACETAMOL</tnsa:INGREDIENT>
<tnsa:INGREDIENT>CHLORPHENAMINE MALEATE</tnsa:INGREDIENT>
<tnsa:INGREDIENT>
PSEUDOEPHEDRINE
HYDROCHLORIDE
</tnsa:INGREDIENT>
</tnsa:INGREDIENTS>
<tnsa:MEDICINAL_PRODUCT_ID />
<tnsa:DRUG_MANUFACTURER>JOHNSON</tnsa:DRUG_MANUFACTURER>
</tnsa:DRUG>
</tnsa:DRUGS>
</tnsa:DRUG_DICTIONARY>
<tns:EXTENSION>
<tns:CUSTOM tns:Name="" tns:Metadata="" />
</tns:EXTENSION>
</tnsa:SAFETY_MESSAGE>
</d4p1:SafetyMessage>
</RelsysServiceRequestResult>
</RelsysServiceRequestResponse>
</s:Body>
</s:Envelope>
Schema files for request and response are located in the <Argus Web Install Path>\Integrations\XSD directory.
Validate WHO drug coding request and response against the following schema files.
Argus Safety will make a web service request to externally hosted Central Drug Dictionary as defined in this schema.
Schema File
Top level file: /v1.0/WHODrug_Request.xsd
Sublevel file: /v1.0/Base.xsd
Namespace
http://www.oracle.com/Argus/WHODrug_Request/v1.0
where v1.0 is the version of the schema
| Attribute/Node name | Description |
|---|---|
| DRUG_DICTIONARY | First Child node under SAFETY_MESSAGE which represents the WHO Drug Dictionary integration |
| DRUG/DRUG_NAME | WHO Drug Name that needs to be searched in central WHO Drug Coding system. |
Argus Safety expects Central Drug Dictionary to send the response in this format.
Schema File
Top level file: /v1.0/WHODrug_Response.xsd
Sublevel file: /v1.0/Base.xsd
Namespace
http://www.oracle.com/Argus/WHODrug_Response/v1.0
where v1.0 is the version of the schema
| Attribute/Node name | Description |
|---|---|
| DRUG_DICTIONARY | First Child node under SAFETY_MESSAGE which represents the Drug Dictionary integration. |
| DRUGS/DRUG | WHO DRUG details |
Lot Number Interface provides a mechanism to integrate customer-hosted central product information systems with Argus Safety via Web service. Argus Safety expects the data from hosted web service in defined format as specified by Lot Number schema. Argus Safety stores the web service Configuration at an enterprise level to support integration with different central product information system per Enterprise. 'EnterpriseShortName' attribute will be present in the request message payload to identify which Enterprise initiated the web service request.
Lot Number Query Interface also provides a mechanism for central product information system to pass custom data to Argus Safety system using 'Lot/Custom' node defined in Lot Number Schema. Data passed in the custom node will be stored in Argus user defined fields of Dosage Regimen section.
Lot Number Interface needs to be enabled using Argus Console. This can be done by opening Console from Argus Web and selecting System Configuration > System Management from the menu. Expand the Case Processing tree branch and select Lot Number Processing. Following configurations are supported.
Use Centralized Lot Number Validation
Yes—Allows Lot Lookup in Case Form to query central product information system to get Lot Number Information.
NO—Lot Lookup in Case Form uses lot numbers defined in Product Configuration under Argus Console >Business Configuration.
Allow users to enter non-configured Lot Numbers
Yes—Allows user to enter non-configured Lot Number
No—Mandates user to only select Lot Number from Lot Lookup Dialog.
This switch is applicable when the lot validation service fails or is unable to provide a match for the lot number.
Lot Number Web Service Configuration XML
Lot Number Interface support endpoint, binding and transformation configuration of Web Service at an enterprise level. This allows customer to integrate an enterprise in Argus Safety with different central product information system.
Configuration file must have the endpoint with the "name" attribute of "LotQuery" properly configured.
At a minimum, the "address" attribute must be changed. Optionally, depending on the bindings employed, the "bindingConfiguration" attribute may also need to be changed. The BindingConfiguration section must have a valid binding for the configured "bindingConfiguration" attribute.
The endpoint configuration might look something like this:
<endpoint address="http://remotewebservice/LotValidate.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IRelsysService_ Unsecure" contract="IRelsysService" name=" LotQuery"></endpoint>
<add Transformer="LotQuery2" Assembly="RelsysInterfaceComponents" Type="Relsys.InterfaceComponents.XSLTTFactory" InterfaceType="Outbound" RequestType="Response" MessageType="RelsysMessage" Enabled="true" TransformID="LOT_NUMBER" Metadata="InputValidationXSD=/Integrations/XSD/v1.0/Lot_Response.xsd;" />
Lot Number Web Service XSLT
XSLT file required for transforming the response XML. This is only required in case Central Product Information system is passing custom attributes which need to be save as part of Case data in dosage regimen user defined fields.
Note:
Argus Safety provides sample config and XSLT files which can be accessed by clicking Create button in 'Lot Number Processing' configuration screen as discussed above.When Argus makes a call to the web service, it will populate the 'LOT_NUMBER' node with data provided by the user. The external lot validation system can provide zero, one, or many results in multiple LOT nodes.
Argus reaction to various counts of returned lots:
Zero—Argus displays a message that the lot number could not be validated; based on the system configuration, the user may be able to keep the entered lot number, in which case Argus creates a red denotation indicating that the lot number was not validated.
One—Argus keeps the user-entered lot number and creates a green denotation indicating a successfully validated lot.
Many—Argus displays a dialog from which the user can select the correct lot number; once selected, Argus creates a yellow denotation indicating that the lot number was validated, but the user had to select from multiple matches.
The lot validation interface also allows for custom data to be returned, such as Albumin or Thermisol which is not natively supported by Argus. This data is then stored in the user-defined fields available on the active case form page.
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header>
<a:Action
s:mustUnderstand="1">
http://www.oracle.com/Argus/Contract/v1.0/IRelsysServic
e/RelsysServiceRequest
</a:Action>
<a:MessageID>urn:uuid:4ea4a68c-9930-4681-a3dd-839b04821320</a:MessageID>
<ActivityId CorrelationId="b7b67964-6e82-46d7-97ed-ff0e9f36dc66"
xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">
0000000
0-0000-0000-0000-000000000000
</ActivityId>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
</s:Header>
<s:Body>
<RelsysServiceRequest xmlns="http://www.oracle.com/Argus/Contract/v1.0">
<Msg xmlns:d4p1="http://www.oracle.com/Argus/Types/v1.0"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<d4p1:Version>1.0</d4p1:Version>
<d4p1:TransformID>LOT_NUMBER</d4p1:TransformID>
<d4p1:SafetyMessage>
<tnsb:SAFETY_MESSAGE xmlns:tns="http://www.oracle.com/Argus/Base/v1.0"
xmlns:tnsa="http://www.oracle.com/Argus/ProductFamilyEntity/v1.0"xmlns:tnsb="http:
//www.oracle.com/Argus/Lot_Request/v1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tns:Type="Request">
<tnsb:LOT_LOOKUP>
<tnsb:LOT>
<tnsa:LOT_NUMBER>666</tnsa:LOT_NUMBER>
</tnsb:LOT>
</tnsb:LOT_LOOKUP>
</tnsb:SAFETY_MESSAGE>
</d4p1:SafetyMessage>
</Msg>
</RelsysServiceRequest>
</s:Body>
</s:Envelope>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">
http://www.oracle.com/Argus/Contract/v1.0/IRelsysServic
e/RelsysServiceRequestResponse
</a:Action>
<a:RelatesTo>urn:uuid:4ea4a68c-9930-4681-a3dd-839b04821320</a:RelatesTo>
</s:Header>
<s:Body>
<RelsysServiceRequestResponse
xmlns="http://www.oracle.com/Argus/Contract/v1.0">
<RelsysServiceRequestResult xmlns:b="http://www.oracle.com/Argus/Types/v1.0"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<b:Version>1.0</b:Version>
<b:TransformID />
<b:SafetyMessage>
<tnsb:SAFETY_MESSAGE
tns:Type="Response"
xmlns:tnsb="http://www.oracle.com/Argus/Lot_Response/v1.0"
xmlns:tns="http://www.oracle.com/Argus/Base/v1.0"
xmlns:tnsa="http://www.oracle.com/Argus/ProductFamilyEntity/v1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tnsb:LOT_LOOKUP>
<tnsb:LOT>
<tnsa:LOT_NUMBER>5043AX1</tnsa:LOT_NUMBER>
<tnsa:EXPIRATION_DATE>2010-06-07</tnsa:EXPIRATION_DATE>
<tns:CUSTOM tns:Name="Thermisol" tns:Metadata="Thermisol
Indicator">15</tns:CUSTOM>
<tns:CUSTOM tns:Name="Albumin" tns:Metadata="Albumin
Status">11.4mg/gC</tns:CUSTOM>
</tnsb:LOT>
<tnsb:LOT>
<tnsa:LOT_NUMBER>javascript</tnsa:LOT_NUMBER>
<tnsa:EXPIRATION_DATE>2014-12-15</tnsa:EXPIRATION_DATE>
<tns:CUSTOM tns:Name="Thermisol"
tns:Metadata="ThermisolIndicator">22</tns:CUSTOM>
<tns:CUSTOM tns:Name="Albumin" tns:Metadata="Albumin
Status">19.5mg/gC</tns:CUSTOM>
</tnsb:LOT>
</tnsb:LOT_LOOKUP>
<tns:EXTENSION>
<tns:CUSTOM tns:Name="string"
tns:Metadata="string">string</tns:CUSTOM>
<tns:CUSTOM tns:Name="string"
tns:Metadata="string">string</tns:CUSTOM>
</tns:EXTENSION>
</tnsb:SAFETY_MESSAGE>
</b:SafetyMessage>
</RelsysServiceRequestResult>
</RelsysServiceRequestResponse>
</s:Body>
</s:Envelope>
Schema files for request and response are located in the <Argus Web Install Path>\Integrations\XSD directory.
Validate Lot Number request and response against the following schema files.
Argus Safety will make a web service request to externally hosted central product information system as defined in this schema.
Schema File
Top level file:
\v1.0\Lot_Request.xsd
Sublevel file:
\v1.0\Base.xsd
\v1.0\ProductFamilyEntity.xsd
Namespace
http://www.oracle.com/Argus/Lot_Request/v1.0
where version 1.0 is the version of the schema
Nodes/Attributes
| Attribute/Node name | Description |
|---|---|
| LOT_LOOKUP | First Child node under SAFETY_MESSAGE which represents the Lot integration |
| LOT | Argus defined complex type element having following elements and attributes:
|
Argus Safety expects Central Lot Number Web service to send the response in this format:
Schema File
Top level file:
/v1.0/Lot_Response.xsd
Sublevel file:
/v1.0/Base.xsd
/v1.0/ProductFamilyEntity.xsd
Namespace
http://www.oracle.com/Argus/Lot_Response/v1.0
where v1.0 is the version of the schema
| Attribute/Node name | Description |
|---|---|
| LOT_LOOKUP | First Child node under SAFETY_MESSAGE which represents the Lot Number integration. |
| LOT |
|
If custom data is to be passed back by the lot validation service, then it is also necessary to modify the 'LotIncomingTransform.xslt' file, located in the '.\ArgusWeb\ASP\Bin' directory. This transformation file reads the CUSTOM tags passed back by the lot validation service and maps them to the Argus user-defined fields.
The CUSTOM tag has a "Name" attribute, which is used by the XSLT to identify to which Argus field to map. The corresponding "Metadata" attribute is used simply to display a label in the lookup dialog if necessary. The XSLT file must be synchronized between all web servers in a web farm scenario.
Specific Argus fields must be placed within the xsl:attribute tags of the XSLT in a comma delimited form. The system will attempt to populate each Argus field specified by the value of the CUSTOM tags. If a field does not exist, no exception is thrown. In this fashion, if different pages in the case form have different definitions for the user-defined fields, the system can still properly populate the values in the fields.
It is inadvisable to modify any piece of the XSLT file with the exception of the piece that is shown in the example below. Consider the web service returns a CUSTOM node like:
<CUSTOM Name="Albumin" Metadata="Albumin Status">19.5 mg/gC</CUSTOM>And the LotIncomingTransform.xslt contains the snippet:
<xsl:template match="@*" mode="CaseField">
<xsl:choose>
<xsl:when test=".='Thermisol'">
<xsl:attribute name="CaseField">CASE_DOSE_REGIMENS_UD_TEXT_1,CASE_DOSE_
REGIMENS_UD_TEXT_2</xsl:attribute>
</xsl:when>
<xsl:when test=".='Albumin'">
<xsl:attribute name="CaseField">CASE_DOSE_REGIMENS_UD_TEXT_3,CASE_DOSE_
REGIMENS_UD_TEXT_4</xsl:attribute>
</xsl:when>
</xsl:choose>
</xsl:template>
Then the value of 19.5 will be mapped to both user defined text fields 3 and 4. If only one of the fields is on the active case form page, the other field will be ignored.
This section provides information for integrating with an external system generating potential case data.
CASE_INTAKE is the first child node identifying a worklist intake integration.
Worklist Intake integration currently employs a file drop system. The drop directories should be on a shared path. The directories can be optionally unique to a user site and configured as such in Console. The first step is to set these directory references up in Console under the "User Sites" code list. For each user site, simply specify the UNC for the "Intake File Path" (they can all be the same or different).
Argus Safety Windows Service provides the mechanism by which the files are processed. Since a network resource is being accessed, it is essential that the service run as a domain account and not as the Local System Account (which is the default). To change this, stop the Argus Safety Windows Service by opening the Services control panel and double-clicking the Argus Safety Windows Service and clicking the Stop button. Next click the Log On tab and select the radio button for "This account". Enter valid domain user credentials and click OK.
The service itself contains additional configuration information in the RelsysWindowsService.exe.config file located in the .\ArgusWeb\ASP\Argus.NET\Bin directory. This file references the Intake.config file to obtain configurations specific to Worklist Intake. Simply uncomment the two "add" nodes in the "RelsysConfigFilesSection" that reference the Intake.config file in their "filePath" attributes. Also verify that the DatabaseConfiguration section in this file has a valid database and user credentials with which to connect to the database and access Argus data.
In the same folder the Service.config file also requires some changes to specify information about the assemblies needed to process Worklist Intake messages. Similarly to the RelsysWindowsService.config file, uncomment the two "add" nodes whose "name" attributes refer to "Case Intake" and "Case Intake Ack".
Once configured, use the Services control panel to restart Argus Safety Windows Service. A successful configuration is evident when four new folders are then created in the shared file path (IN, OUT, INTERMEDIATE, and FAILURES).
If the shared folder happens to be on the same physical machine as the server on which ”Argus Windows Service” is running, you can optionally configure the service to access the shared folder directly as a local folder instead of as a network shared path. The following configuration in Intake.config would enable this:
<FolderConfiguration>
<MonitorFolders MonitorAllConfiguredFolders="true"
MonitorLiteratureFolder="false">
<add FolderPath="<configured share in console>" Monitor="true"
AlternatePath="C:\CaseIntake"/>
</MonitorFolders>
</FolderConfiguration>
In the above configuration, MonitorAllConfiguredFolders can be set to false if you want to configure that server to accept Intake files only for the folders configured in the above section and for which Monitor is set to true.
When an XML file is dropped in the IN folder of the configured Intake folder, Argus picks up the file and does an initial verification. If there are any attachments specified in the XML, they and the XML are moved to a GUID-created subfolder of the Intermediate folder. All the relevant data is extracted from the XML and stored in the database. During the parsing and extraction, if there are any errors, the unique folder and its associated XML and file attachments are moved to Failures folder. A file called Error.xml will be generated in that folder which contains more information about the failure. If an e-mail address is configured in Intake.config, an e-mail is also generated and processed via AGService.
Worklists for intake are based on user site. They are populated based on either the path in which the initial file was dropped (as per the configuration in Argus Console the path is associated to a specific user site) or by the value of the SITE node contained within the XML itself. If there is a conflict, the SITE node value takes precedence.
The Intake records that are absorbed into Argus are visible to the Argus User in Worklist Intake screen in Argus or in Affiliate. The Argus user can do one of two operations on the Intake record.
Accept—When the user accepts an Intake, the case form book-in screen is shown which will contain information and attachments pre-populated from the Intake record.
If user books in a case, a response is generated which contains the case ID and case number. The attachment details and response XML are placed in the Out folder.
If user adds a follow up to an existing case, a similar response is generated as above and the response XML is placed in the OUT folder.
Reject—When the user rejects an Intake record, a response is generated which contains the Rejection Reason and the attachment details. This response XML is placed in the OUT folder.
Similarly, an Affiliate user can create a local event from an Intake record from within Affiliate. The flow is similar to that mentioned above with the exception that the response XML would contain the Local Event Number instead of the case number.
Request—Worklist Intake Safety Message (Multi-Tenant System)
<?xml version="1.0" encoding="utf-8"?> <tnsc:SAFETY_MESSAGE xmlns:tnszz="http://www.oracle.com/Argus/Base/v1.0" xmlns:tnsc="http://www.oracle.com/Argus/Case_Intake/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tnszz:Type="Request" tnszz:EnterpriseShortName ="ENT01"> <tnsc:CASE_INTAKE> <tnsc:CASES> <tnsc:CASE> <tnsc:CASE_TYPE>Spontaneous</tnsc:CASE_TYPE> <tnsc:COUNTRY_OF_INCIDENCE>UNITED STATES</tnsc:COUNTRY_OF_INCIDENCE> <tnsc:EVENT_PT>Pain</tnsc:EVENT_PT> <tnsc:EVENT_VERBATIM>Pain</tnsc:EVENT_VERBATIM> <tnsc:FLTH>LT</tnsc:FLTH> <tnsc:GENERIC_NAME>D-RIBOSE</tnsc:GENERIC_NAME> <tnsc:INITIAL_DATE>2012-01-31</tnsc:INITIAL_DATE> <tnsc:PRIORITY>1</tnsc:PRIORITY> <tnsc:PRODUCT_NAME>Cure All</tnsc:PRODUCT_NAME> <tnsc:REPORTER_TYPE>Health Care Professional</tnsc:REPORTER_TYPE> <tnsc:SITE>US</tnsc:SITE> <tnsc:STUDY_ID>STUDY 001</tnsc:STUDY_ID> <tnsc:SUR>No</tnsc:SUR> <tnsc:ATTACHMENTS xmlns:tnsc="http://www.oracle.com/Argus/Case_Intake/v1.0"> <tnsc:ATTACHMENT> <tnsc:FILENAME>Case12345.pdf</tnsc:FILENAME> <tnsc:DOCID>001219988776655</tnsc:DOCID> <tnsc:CLASSIFICATION>CIRM Case</tnsc:CLASSIFICATION> <tnsc:ATTACHMENT_DESC>Contains case data for 12345</tnsc:ATTACHMENT_DESC> </tnsc:ATTACHMENT> </tnsc:ATTACHMENTS > </tnsc:CASE> </tnsc:CASES> </tnsc:CASE_INTAKE> <tnszz:EXTENSION> <tnszz:CUSTOM tnszz:Name="My Name" tnszz:Metadata="My Metadata">My Value</tnszz:CUSTOM> </tnszz:EXTENSION> </tnsc:SAFETY_MESSAGE>
Response—Worklist Intake Safety Message (Multi-Tenant system)
<?xml version="1.0" encoding="utf-8"?> <tnse:SAFETY_MESSAGE xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:tnse="http://www.oracle.com/Argus/Case_Intake_Ack/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:a="http://tempuri.org/CaseIntakeResponse.xsd" tns:Type="Response"> tns:EnterpriseShortName="ENT01"> <tnse:CASE_INTAKE> <tnse:CASES> <tnse:CASE> <tnse:INTAKE_DATE>03-NOV-2014 10:08:49</tnse:INTAKE_DATE> <tnse:CASE_NUMBER>12US000000001</tnse:CASE_NUMBER> <tnse:CASE_ID>10285117</tnse:CASE_ID> <tnse:CASE_PRODUCT>Cure All</tnse:CASE_PRODUCT> <tnse:DATE_TIME>03-NOV-2014 15:40:07</tnse:DATE_TIME> <tnsc:ATTACHMENTS xmlns:tnsc="http://www.oracle.com/Argus/Case_Intake/v1.0"> <tnsc:ATTACHMENT> <tnsc:FILENAME>Case12345.pdf</tnsc:FILENAME> <tnsc:DOCID>001219988776655</tnsc:DOCID> <tnsc:CLASSIFICATION></tnsc:CLASSIFICATION> <tnsc:ATTACHMENT_DESC>Contains case data for 12345</tnsc:ATTACHMENT_DESC> </tnsc:ATTACHMENT> </tnsc:ATTACHMENTS> </tnse:CASE> </tnse:CASES> </tnse:CASE_INTAKE> <tnszz:EXTENSION xmlns:tnszz="http://www.oracle.com/Argus/Base/v1.0"> <tnszz:CUSTOM tnszz:Name="My Name" tnszz:Metadata="My Metadata">My Value</tnszz:CUSTOM> </tnszz:EXTENSION> </tnse:SAFETY_MESSAGE>
Request—Worklist Intake Safety Message (Single-Tenant System)
<?xml version="1.0" encoding="utf-8"?> <tnsc:SAFETY_MESSAGE xmlns:tnszz="http://www.oracle.com/Argus/Base/v1.0" xmlns:tnsc="http://www.oracle.com/Argus/Case_Intake/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tnszz:Type="Request" <tnsc:CASE_INTAKE> <tnsc:CASES> <tnsc:CASE> <tnsc:CASE_TYPE>Spontaneous</tnsc:CASE_TYPE> <tnsc:COUNTRY_OF_INCIDENCE>UNITED STATES</tnsc:COUNTRY_OF_INCIDENCE> <tnsc:EVENT_PT>Pain</tnsc:EVENT_PT> <tnsc:EVENT_VERBATIM>Pain</tnsc:EVENT_VERBATIM> <tnsc:FLTH>LT</tnsc:FLTH> <tnsc:GENERIC_NAME>D-RIBOSE</tnsc:GENERIC_NAME> <tnsc:INITIAL_DATE>2012-01-31</tnsc:INITIAL_DATE> <tnsc:PRIORITY>1</tnsc:PRIORITY> <tnsc:PRODUCT_NAME>Cure All</tnsc:PRODUCT_NAME> <tnsc:REPORTER_TYPE>Health Care Professional</tnsc:REPORTER_TYPE> <tnsc:SITE>US</tnsc:SITE> <tnsc:STUDY_ID>STUDY 001</tnsc:STUDY_ID> <tnsc:SUR>No</tnsc:SUR> <tnsc:ATTACHMENTS xmlns:tnsc="http://www.oracle.com/Argus/Case_Intake/v1.0"> <tnsc:ATTACHMENT> <tnsc:FILENAME>Case12345.pdf</tnsc:FILENAME> <tnsc:DOCID>001219988776655</tnsc:DOCID> <tnsc:CLASSIFICATION>CIRM Case</tnsc:CLASSIFICATION> <tnsc:ATTACHMENT_DESC>Contains case data for 12345</tnsc:ATTACHMENT_DESC> </tnsc:ATTACHMENT> </tnsc:ATTACHMENTS > </tnsc:CASE> </tnsc:CASES> </tnsc:CASE_INTAKE> <tnszz:EXTENSION> <tnszz:CUSTOM tnszz:Name="My Name" tnszz:Metadata="My Metadata">My Value</tnszz:CUSTOM> </tnszz:EXTENSION></tnsc:SAFETY_MESSAGE>
Response—Worklist Intake Safety Message (Single-Tenant system)
<?xml version="1.0" encoding="utf-8"?> <tnse:SAFETY_MESSAGE xmlns:tns="http://www.oracle.com/Argus/Base/v1.0" xmlns:tnse="http://www.oracle.com/Argus/Case_Intake_Ack/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:a="http://tempuri.org/CaseIntakeResponse.xsd" tns:Type="Response"> <tnse:CASE_INTAKE> <tnse:CASES> <tnse:CASE> <tnse:INTAKE_DATE>03-NOV-2014 10:08:49</tnse:INTAKE_DATE> <tnse:CASE_NUMBER>12US000000001</tnse:CASE_NUMBER> <tnse:CASE_ID>10285117</tnse:CASE_ID> <tnse:CASE_PRODUCT>Cure All</tnse:CASE_PRODUCT> <tnse:DATE_TIME>03-NOV-2014 15:40:07</tnse:DATE_TIME> <tnsc:ATTACHMENTS xmlns:tnsc="http://www.oracle.com/Argus/Case_Intake/v1.0"> <tnsc:ATTACHMENT> <tnsc:FILENAME>Case12345.pdf</tnsc:FILENAME> <tnsc:DOCID>001219988776655</tnsc:DOCID> <tnsc:CLASSIFICATION></tnsc:CLASSIFICATION> <tnsc:ATTACHMENT_DESC>Contains case data for 12345</tnsc:ATTACHMENT_DESC> </tnsc:ATTACHMENT> </tnsc:ATTACHMENTS> </tnse:CASE> </tnse:CASES> </tnse:CASE_INTAKE> <tnszz:EXTENSION xmlns:tnszz="http://www.oracle.com/Argus/Base/v1.0"> <tnszz:CUSTOM tnszz:Name="My Name" tnszz:Metadata="My Metadata">My Value</tnszz:CUSTOM> </tnszz:EXTENSION> </tnse:SAFETY_MESSAGE>
This section provides information for setting up Literature Intake. Argus accepts files of the following formats for Literature Intake.
WORLD MEDICAL & DRUG INFORMATION SERVICE (WMDIS) (in the form of .xls or .xlsx file format)
JAPIC (in the form of .txt fie format)
Literature Intake integration employs a file drop system. The drop folder should be on a shared path. The folder must be configured in Console under System Configuration > Common Profile Switches > Argus J.
The edit box provided for "Shared Path for Literature Intake" must be configured with the UNC file path of the shared folder. Argus Safety Windows Service provides the mechanism by which the files are processed. Since a network resource is being accessed, it is essential that the service run as a domain account and not as the Local System Account (which is the default).
To change this, stop the Argus Safety Windows Service by opening the Services control panel and double-clicking the Argus Safety Windows Service and clicking the Stop button. Next click the Log On tab and select the radio button for "This account". Enter valid domain user credentials and click OK.
The service itself contains additional configuration information in the RelsysWindowsService.exe.config file located in the .\ArgusWeb\ASP\Argus.NET\Bin directory. This file references the Intake.config file to obtain configurations specific to Worklist Intake. Simply uncomment the two "add" nodes in the "RelsysConfigFilesSection" that reference the Intake.config file in their "filePath" attributes. Also verify that the DatabaseConfiguration section in this file has a valid database and user credentials with which to connect to the database and access Argus data. In the same folder the Service.config file also requires some changes to specify information about the assemblies needed to process Worklist Intake messages.
Go to the Argus Web server machine.
Open the service.config file located at
C:\Program Files\Oracle\Argus\ArgusWeb\ASP\Argus.NET\Bin\
In the service.config file, the metadata configuration is:
<add Name="Case Intake" Assembly="CaseIntakeServiceComponent" Type="Relsys.CaseIntakeServiceComponent.FSWManager" Metadata="InvokeDirect=true;PollInterval=1000;CaseIntake=true;LitIntake=true; UseLocalInterimFolder=true; LocalInterimFolder=C:\Temp\CaseIntake" />
Similarly to the Service.config file, uncomment the "add" node whose "name" attribute refer to "Case Intake". Ensure that 'LitIntake' is set to true in the Metadata configuration as shown below:
<add Name="Case Intake" Assembly="CaseIntakeServiceComponent" Type="Relsys.CaseIntakeServiceComponent.FSWManager" Metadata="InvokeDirect=true; PollInterval=1000;CaseIntake=true;LitIntake=true" />
In the same folder, the Intake.config file needs some changes. Set the MonitorLiteratureFolder attribute to true in FolderConfiguration/MonitorFolders section as shown below:
<FolderConfiguration> <MonitorFolders MonitorAllConfiguredFolders="false" MonitorLiteratureFolder="true"> <!-- <add FolderPath="<configured share in console>" Monitor="true" AlternatePath="C:\LiteratureIntake"/> --> </MonitorFolders> </FolderConfiguration>
Once configured, use the Services control panel to restart Argus Safety Windows Service. A successful configuration is evident when four new folders are then created in the shared file path (IN, OUT, INTERMEDIATE, and FAILURES).
If the shared folder happens to be on the same physical machine as the server on which ”Argus Windows Service” is running, you can optionally configure the service to access the shared folder directly as a local folder instead of as a network shared path. The following configuration in Intake.config would enable this:
<FolderConfiguration> <MonitorFolders MonitorAllConfiguredFolders="false" MonitorLiteratureFolder="true"> <add FolderPath="<configured share in console>" Monitor="true" AlternatePath="C:\LiteratureIntake"/> </MonitorFolders> </FolderConfiguration>
When a WMDIS or JAPIC file is dropped in the IN folder of the configured Literature Intake folder, Argus picks up the file and does an initial verification. The file is first moved to a GUID-created subfolder of the Intermediate folder. All the relevant data is extracted from the file and stored in the database. During the parsing and extraction, if there are any errors, the unique folder and the file in it are moved to Failures folder. A file called Error.xml will be generated in that folder which contains more information about the failure. If an e-mail address is configured in Intake.config, an e-mail is also generated and processed via AGService. The Literature Intake Worklist shows all the records extracted from the above mentioned files.
The Argus user can do one of the following operations on the Literature Intake record.
Accept
Reject
Assign User
Assign Literature Type
Modify Product Family
For details, refer to the ICSR Extension Guide.