Note:
You must Set Up Argus Safety Middle and Client Tiers before installing Argus Integrations, and follow all the chapters from 3 to 13.Click Argus Safety to start the installation.
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 installer installs the website and its related components and shows the progress of the installation.
In the Setup Completed screen, click Finish.
Click OK to reboot the system.
To set up the Argus Cryptography Key, refer to the section Section 21.1.3, "Argus Safety 8.1.1 Application Servers.".
to 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).
Argus Web Service Interface supports outbound Interface (MedDRA, WHO Drug and LOT Number) which provides capability to integrate with customer hosted web services and inbound web services (Product-Study-Load Interface) hosted on Argus Safety web server.
All web service based interfaces communicate with the standard SOAP 1.2 Protocol and use WS-Addressing and WS-Security. Argus web service interface leverage Windows Communication Foundation to generate the WS-Addressing and WS-Security header information. It is recommended to test this message before moving too far into business testing. Information on these specifications can be found at the OASIS and W3C websites.
By leveraging WCF, maximum flexibility is provided to the user allowing the selection of which integrations to enable, the transport protocols to use, authentication, etc. by simply updating a standard .config file.
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. Argus Safety web service interface in this release supports the following integrations through Web Service:
| Interface | Description |
|---|---|
| MedDRA (outbound) | MedDRA (outbound) |
| 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/query PSL data via web services hosted on Argus Safety Web server |
In a multi-tenant Argus system:
Endpoint configuration of central MedDRA and WHO Drug web service is at global level. Enterprise if configured to use MedDRA and WHO Drug web service interface will use same endpoint to connect.
Endpoint configuration of Lot Number Interface is defined at an enterprise level. Enterprise if configured to use Lot Interface will use enterprise specific endpoint configuration.
Outbound Interface: Message payload will have 'EnterpriseShortName'.
Inbound Interface: Argus Safety mandates 'EnterpriseShortName' as part of message payload.
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 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
(Example: C:\Progam Files\Oracle\ArgusWeb\ASP\Integrations\XSD)
The web.config file located in the root of the ArgusWeb directory contains all the configuration required for outbound integrations. Two default bindings have been provided, one for basic HTTP traffic and one for SSL communication. For the most basic configuration, simply updating the "address" attribute of the "endpoint" nodes to point to the correct web service address would be sufficient.
To use encryption, the "bindingConfiguration" attribute of the "endpoint" node can be set to "WSHttpBinding_IRelsysService_Secure", a binding configuration provided out of the box. As the framework utilizes WCF, additional binding configurations may be created and used as well. Note that the binding configurations between the host and the client must be compatible for successful communication.
Basic user authentication is also supported by the framework. Each endpoint has a counterpart in the ClientCredentials section of the web.config. Simply adding the proper credentials here will instruct WCF to transmit the authentication information.
The framework provides the ability to transform messages using either a custom transformation assembly or an XSLT. Some interfaces, like Lot Number and WHO Drug coding, currently leverage this feature. Activating the transformer is a simple matter of updating the 'TransformerConfiguration' section to map an endpoint to a transformer. If multiple transformers are specified for a particular endpoint, they will be executed in the order in which they appear in the configuration file. The transformers configured by Oracle should not be modified, but additional ones may be added if necessary.
All inbound integrations (file based) are handled by the Argus Safety Windows Service. This service's configuration is located in the RelsysWindowsService.exe.config file located in the .\ArgusWeb\ASP\Argus.NET\Bin directory. This configuration file's primary function is to reference configuration files of configured integrations. The RelsysConfigurationFiles section has several commented "add" nodes. To enable or disable an integration, it is a simple matter of uncommenting or commenting out the node.This configuration file additionally houses a DatabaseConfiguration section in which the proper database credentials must be specified within the attributes.
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:
| Interface | Description |
|---|---|
| Type | An enumeration (currently either "Request" or "Response") to identify the directionality of the message |
| EnterpriseShortName | If Argus Safety is setup as Multi-Tenant system:
EnterpriseShortName will be part of message payload for all outbound interfaces. EnterpriseShortName is mandatory attribute for Inbound Interface In single tenant setup, this attribute is not part of outbound message payload and is not required as part of inbound message payload. |
| EXTENSION | Every Safety Message may also contain an EXTENSION node with CUSTOM sub nodes. These are for future expandability and currently unused. |
MedDRA Encoding Web Service Interface provides a mechanism to integrate customer hosted central MedDRA dictionary web service with Argus Safety. Argus Safety expects the data from central MedDRA dictionary web service in defined format as specified by MedDRA dictionary schema.
In a multi-tenant setup, endpoint configuration of central MedDRA web service is stored at global level and all enterprises in Argus Safety uses the same web service endpoint. EnterpriseShortName attribute present in the request message payload identifies which Enterprise has initiated the web service request.
Both English and Japanese MedDRA dictionary is supported through this interface. For integrating MedDRA Encoding Web Service Interface with English dictionary refer version 1.0 and for Japanese refer version refer 1.1 (without Japanese current term details) and refer 2.0(to get Japanese current term details for LLT) of MedDRA schema.
MedDRA Interface supports (v2.0, v1.1 and v1.0) versions of the XMLs. The difference between them is that v2.0 includes support for Japanese Terms including Japanese current term details for LLT. While V1.1 also supports Japanese terms but does not include the detail whether J term is current or noncurrent. The following example uses Pain as the search term for encoding for each version of the XML.
<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/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">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/IRelsysService/RelsysServiceRequestResponse</a:Action><ActivityId CorrelationId="12dda93b-e6fa-4d3a-8d2f-a5cc34588e8a"xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">00000000-0000-0000-7600-0060000000f3</ActivityId></s:Header><s:Body><RelsysServiceRequestResponsexmlns="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_MESSAGExsi:noNamespaceSchemaLocation="http://www.oracle.com/Argus/MedDRA_Response/v2.0 file:///C:/SS/6 - Argus Interfaces/ASI6x/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/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">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/IRelsysService/RelsysServiceRequestResponse</a:Action><ActivityId CorrelationId="12dda93b-e6fa-4d3a-8d2f-a5cc34588e8a"xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">00000000-0000-0000-7600-0060000000f3</ActivityId></s:Header><s:Body><RelsysServiceRequestResponsexmlns="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_MESSAGExsi:noNamespaceSchemaLocation="http://www.oracle.com/Argus/MedDRA_Response/v1.1 file:///C:/SS/6 - Argus Interfaces/ASI6x/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:Actions:mustUnderstand="1">http://www.oracle.com/Argus/Contract/v1.0/IRelsysService/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">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.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:Actions:mustUnderstand="1">http://www.oracle.com/Argus/Contract/v1.0/IRelsysService/RelsysServiceRequestResponse</a:Action><ActivityId CorrelationId="12dda93b-e6fa-4d3a-8d2f-a5cc34588e8a"xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">00000000-0000-0000-7600-0060000000f3</ActivityId></s:Header><s:Body><RelsysServiceRequestResponsexmlns="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 Integration14-10 Oracle Argus Safety Installation Guide<tnsa:SAFETY_MESSAGExsi:noNamespaceSchemaLocation="http://www.oracle.com/Argus/MedDRA_Response/v1.0 file:///C:/SS/6 - Argus Interfaces/ASI6x/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.
Validate the MedDRA Interface request and response 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
Sub level file: \v1.0\Base.xsd
Version 1.1
Top level file: \v1.1\MedDRA_Request.xsd
Sub level file: \v1.0\Base.xsd
Version 2.0
Top level file: \v2.0\MedDRA_Request.xsd
Sub level 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
where, v 1.0,1.1, 2.0 is the version of the schema
Node/Attribute Name Description
The MEDICAL_DICTIONARY node is the first child node identifying MedDRA integration.
Argus Safety expects central MedDRA dictionary to send the response in this format.
| Node/Attribute Name | Description |
|---|---|
| Action | An enumeration supporting the following values (currently only one): Auto
Auto—This attribute will 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 / returned, the system will open the MedDRA Browsers 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 will be used. |
| Source | An enumerated value that specifies additional information that may be required for coding based on origination as follows:
|
| Term
(v 1.0)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 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. |
Argus Safety expects central MedDRA dictionary to send the response in this format.
Schema File
Version 1.0
Top level file: \v1.0\MedDRA_Response.xsd
Sub level 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
where, v 1.0,1.1, 2.0 is the version of the schema
Node/Attribute Name Description
| Node/Attribute Name | Description |
|---|---|
| Primary | The primary attribute will contain 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 available on the Primary Term. |
| PATHS/PATH
(version 1.0) |
MedDRA Hierarchy with English Terms only. |
| PATHS/PATH(version 1.1) | MedDRA Hierarchy with English and Japanese Terms without Currency_J (Japanese term is current or noncurrent) Details. |
| PATHS/PATH
(version 2.0) |
MedDRA Hierarchy with English and Japanese Terms with Currency_J(Japanese term is current or noncurrent) Detail for LLT term. |
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 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 (MedDRA Browser does not open on the Case Bookin Screen). The encoded term is placed on the case form if auto-encoding is enabled an exact match is found of the searched term in the XML. If multiple matches are returned for an exact match, the primary path is used. If the web service does not return any results or is unavailable, Argus Safety loads the MedDRA browser with local dictionary information, if the system is configured to allow this.
Argus Console
MedDRA integration must be enabled using Argus Console. This can be done by opening Console from Argus Safety Web and selecting System Configuration > System Management from the menu. Expand the Case Processing tree branch and select Dictionary Browser.
Argus Safety MedDRA Coding Method—Select the radio button to use web services.
Use Local MedDRA if Term not found by Web Services—An optional checkbox available to determine whether Argus has to use the local MedDRA instance if the web service hosting MedDRA is not available, fails, or does not return a valid match.
Use Local MedDRA for Japanese terms
Web.config
web.config file on each web server under ArgusWeb/ASP/ must have the endpoint with the name attribute of MedDRA 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/MedDRAAutoEncode.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IRelsysService_ Unsecure" contract="IRelsysService" name="MedDRA">
Besides, the Argus .Net/web.config file on each web server should also have the correct Value for the Key MedDRAXMLVersion depending on which version of MedDRA XML is used. For example:
<add key="MedDRAXMLVersion" value="2.0"/>, or
<add key="MedDRAXMLVersion" value="1.1"/>, or
<add key="MedDRAXMLVersion" value="1.0"/>
Additionally, the ArgusNet/web.config mentions the paths for both the Request and Response XSDs depending on the version used.
<add InputXSD="..\..\Integrations\XSD\v2.0\MedDRA_Response.xsd" />
<add InputXSD="..\..\Integrations\XSD\v2.0\MedDRA_Request.xsd" />
This section provides information for integrating with an external Product Study License configuration system.
In the Integrations folder in the following path <Installation Path>\Oracle\ArgusWeb\ASP\Integrations, open the file Service.config. Search for the section called DatabaseConfiguration:
<DatabaseConfiguration DBName="" DBUser="" DBPassword="" />
The DBName, DBUser and DBPassword need to be populated manually.
DBName: This is the TNS of the Argus database.
DBUser: This is the user name of a AG Service user. The PSL web service uses this User Context to perform updates in the Argus Safety Database.
DBPassword: Generate new encrypted string, as mentioned in the Generate Encrypted String section.
A sample configuration would be:
<DatabaseConfiguration DBName="ARGOLDDEMO" DBUser="agservice1" DBPassword="BC90A10363A26C147DEF172D61AAEC110296FA9E181E7FFA687D58CE08610C08" />
Security Configuration
If the PSL web service is desired to be run under security, appropriate binding configurations need to be configured in web.config under the Integrations folder. This can be done either manually or through the Service Config Utility.
Logging
PSL Web service performs two kinds of logging. One is file logging using the Relsys Logger. This involves logging information about the errors, warnings, and processing of the PSL web service code. The configuration for this type of logging is present in web.config, under the section <logConfig>. There are four types of logging - Error, Warning, Information, and Verbose. By default, the logger is configured to be of Error level. The logger internally uses log4net component to perform the logging. The RollingLogFileAppender which is by default present in web.config needs to be configured to log information to a specific file on a local folder. Ensure that read/write permissions are available to the web service for this folder.
Another type of logging is the SOAP message logger, called the RequestLogger. This logger 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 in this release. This logging can be turned off by setting the Enabled attribute to false in Service.config as shown below:
<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>
Note:
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/Customer Support teams.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.
<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
Sub level 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
Sub level 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 |
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.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>
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.
<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
Sub level 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
Sub level 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 |
|
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.
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.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.
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>
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.
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)
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
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>
For details, refer to the ICSR Extension Guide.