Click here to access the XCPD Initiating Gateway Simulator

Introduction

The XCPD Initiating Gateway simulator is developed in conformance with the IHE Technical Framework and especiallu the epSOS extension to the profile. The GUI of this simulator lets users to generate PRPA_IN201305UV02 messages (XCPD requests), and to send this type of messages to a responder endpoint.

Tools

• Generation of XCPD Request

This tool allows the generation of XCPD requests from many parameters, which are : family name, given name, birthdate, patient id (id.root and id.extension), gender, address (street, city, country, zipcode), and mother maiden name. These parameters let to generate the request for a patient, and there are two others parameters which are sender homeCommunityId and receiverHomeCommunityId, which let to identify the message's actors. The homeCommunityId used by the simulator is 2.16.17.710.812.1000.990.1 .

 

• Communication with Responding Gateway

This tool allows sending XCPD request to the endpoint of an XCPD responding gateway. The endpoint of the IHE XCPD Responding Gateway is http://jumbo-2.irisa.fr:8080/XCPDRESPSimulator-XCPDRESPSimulator/RespondingGatewayPortTypeImpl?wsdl. This tool lets to generate request and send it to the endpoint, or copy directly the XCPD request message, and send it.

This page allows also to validate the generated or the uploaded message before sending it to the responder endpoint. The validation is done by communication with the EVSClient. The validation done is a schema validation and a schematron validation, using IHE and epSOS schematrons.

 

Messages Transaction

All messages sent via this simulator are saved on its database. This simulator can be used by two way : using gazelle driven from tests launched with this simulator, or using the GUI. On the two cases, all messages are saved, and can be viewed on http://gazelle.ihe.net/XCPDINITSimulator/transaction/messages.seam.

On this table, for each message sent, we can view it, we can validate it, we can view also the response of the responding gateway and validate its content. Also we can notice that we can choose to view web application messages or gazelle driven messages. We can also notice that for each couple of request/response, we have a permanent link, specified by a unique Id, the permanent link has this form : http://gazelle.ihe.net/XCPDINITSimulator/transaction.seam?id=ID.

This permanent link contains the content of the request and the response, the date of the transaction, the responder endpoint, the message type, the transaction type, and the context of the transaction (GUI or gazelle driven message). We can also validate the request and the response directly from the permanent link.

Click here to enter the XCPD Initiating Gateway Simulator

The XCPD Initiating Gateway Simulator has been developed to replace the Initiating Gateway actor of the XCPD (Cross Community Access) integration profile in connectathon (or pre-connectathon) tests when needed. This tool can participate as an initiator in many tests like XCPD_Patient_Discovery thanks to its web service methods which provide to Gazelle a mean to communicate with it. A Web GUI is also available and enables the users to test their XCPD responding gateway outside of a connectathon context. From this GUI, connecthaton participants can sends HL7V3 XCPD request to a specified responding gateway web service. Note that this tool is able to send requests using TLS.

This simulator also supports the XUA (Cross Enterprise User Authentication) profile and can act as a X-Service User actor.

First developed for epSOS purposes, the epSOS instance of this simulator sends signed-body SOAP messages. 

Transactions and Messages supported

As an Initiating Gateway for XCPD, this simulator supports the ITI-55 transaction.

Communication between the simulator and Gazelle

All simulators developed for interacting with Gazelle are built on the same model. The following diagram represents the different steps performed during a test instance.

 

How to write tests involving XCPD Initiating Gateway actor

When a test instance is created with the XCPD Initiating Gateway Simulator as one of the test instance participants, Gazelle needs some additional information to be able to communicate with the tool. 

When you edit a test definition, for each step in which the XCPD INIT_GATEWAY actor acts as the initiator of the transaction, you are expected to give the following information:

• Transaction must be ITI-55
• You also need to fill the contextual information according the rules defined in the table present at the end of this page.
• If the communications have to be secured, make sure you have checked the TLS option.
• If the communications is xua, you have to add a contextual information "isxua" to the testSteps.

Installation and Documentation

You can download sources of the XCPDINITSimulator project from the INRIA Forge. This project required two additional modules: GSCommon-ejb and GSCommon-ui. Links to those sources are:

https://scm.gforge.inria.fr/svn/gazelle/branches/simulators/GSCommon-ejb

https://scm.gforge.inria.fr/svn/gazelle/branches/simulators/GSCommon-ui

https://scm.gforge.inria.fr/svn/gazelle/branches/simulators/XCPDINITSimulator

Javadoc relative to the XCPDINITSimulator will be soon available.

 

Contextual Informations

This table lists the input and output contextual informations that Gazelle is expected to send to the simulator for each step, during a test instance. For each test instance, the simulator stores the contextual informations so that it can retrieve them for the next steps. Information extracted from the responding gateway response are also stored. If XUA is used, you only need to fill the contextual informations for the first step.

Output Contextual Informations
label	path	description	possible values
is XUA	isxua	indicates whether the simulator must turn XUA mode on or off	true or false
family	family	optional : indicate the value of the family request, if no contextual informations about the request are specified, a default patient request will be used.	family name
given	given	optional: the given of the patient request , if no contextual informations about the request are specified, a default patient request will be used.	given name
birthdate	birthdate	optional: the birthdate of the patient request , if no contextual informations about the request are specified, a default patient request will be used.	birthdate of the patient request
root	root	optional: the root of the patient request , if no contextual informations about the request are specified, a default patient request will be used.	The root of hte patient
gender	gender	optional: the gender of the patient request , if no contextual informations about the request are specified, a default patient request will be used.	Male or Female
extension	extension	optional: the extension of the patient request , if no contextual informations about the request are specified, a default patient request will be used.	the extension of the patient
street	street	optional: the street of the patient request , if no contextual informations about the request are specified, a default patient request will be used.	The street
city	city	optional: the city of the patient request , if no contextual informations about the request are specified, a default patient request will be used.
postalcode	postalcode	optional: the postalcode of the patient request , if no contextual informations about the request are specified, a default patient request will be used.
maidenname	maidenname	optional: the postalcode of the patient request , if no contextual informations about the request are specified, a default patient request will be used.