Skip to content

Connectathon homeCommunityId test

Bill Majurski edited this page Apr 10, 2019 · 2 revisions

This test has been redesigned to use the XDS Toolkit instead of the Public Registry. The vendor requirements are unchanged.

Background

This is a no-peer test to run once against the XDS Toolkit.

This test applies to both Document Consumer actors in the XDS.b profile and to Imaging Document Consumer actors in the XCA-I profile. Either your XDS.b Consumer OR XCA-I Img Doc Consumer runs this test against the XDS Toolkit.

The generic term "Doc Consumer" is used below to apply to both actors.

This tests the Doc Consumer’s handling of homeCommunityID (see ITI TF-2:3.18.4.1.2.3.8 (for Stored Query) and 2.43.4.1.2 (for Retrieve Doc Set-b)). A Document Consumer can be configured to point to an Initiating (Imaging) Gateway instead of a Document Registry.

Query

Primary queries (that have Patient ID as a parameter such as FindDocuments) do not include homeCommunityId but the response will include homeCommunityId. Secondary queries (that do not include Patient ID such as GetDocuments) are required to include homeCommunityId as a parameter. If your Document Consumer uses GetDocuments then the homeCommunityId returned in FindDocuments must be present in the GetDocuments request.

Retrieve

If the query returned homeCommunityId in the ExtrinsicObject then the Retrieve Document Set transaction must be issued to the Initiating (Imaging) Gateway for routing to the appropriate community. This is confusing in a Connectathon environment since the target Repository is directly available. The target community behind the Responding Gateway may be an XDS Affinity Domain or not.

Instructions

You will test against two specific endpoints listed below - one for query and one for retrieve. You can use either TLS or non-TLS for this test. These two endpoints point to an Initiating Gateway simulator running in the XDS Toolkit.

Endpoints

Stored Query endpoints

http://nist1:8080/xdstools/sim/cat__ig/ig/igq
https://nist1:8443/xdstools/sim/cat__ig/ig/igq

Retrieve Document Set endpoints

http://nist1:8080/xdstools/sim/cat__ig/ig/igr
https://nist1:8443/xdstools/sim/cat__ig/ig/igr

These endpoints are present in Toolkit with the system name cat__ig.

Test with this patient ID:

P20170106143728.2^^^&1.3.6.1.4.1.21367.2005.13.20.1000&ISO

You must execute one of the two options below.

Procedure - Option 1 - Start with FindDocuments returning ObjectRef

The endpoints and Patient ID to use are shown at the bottom of this page

  1. Send FindDocuments Stored Query for ObjectRef to the Stored Query endpoint below using the Patient Id listed below. The ObjectRef will include the home attribute.

  2. Send GetDocuments Stored Query for one of the returned ObjectRefs and include the home attribute (homeCommunityId) in the query.

  3. Send Retrieve request including the home attribute in the request.

  4. Find your GetDocuments event and your Retrieve event in the simulator log [here](http://xds1:8080/toolkit/Xdstools2.html#SimLog:cat__ig/rep/ret/all). Once you have selected the event its URL will display at the top of the tool. The event URL looks like:

This link is an example - the real link will be copied out of the tool.

Event Link: http://xds1:8080/toolkit/Xdstools2.html#SimLog:default__ig/reg/sq/2017_01_03_21_18_00_286
  1. Copy the URL for the GetDocuments event and the Retrieve event into the Gazelle chat window labeling them (one query the other retrieve):

    GetDocuments event: http://xds1:8080/toolkit/Xdstools2.html#SimLog:default__ig/reg/sq/2017_01_03_21_18_00_286
    Retrieve event: http://xds1:8080/toolkit/Xdstools2.html#SimLog:default__ig/ig/igr/2017_01_18_21_20_42_605

Procedure - Option 2 - Start with FindDocuments returning LeafClass

The endpoints and Patient ID to use are shown at the bottom of this page

  1. Send FindDocuments Stored Query for LeafClass to the Stored Query endpoint below using the Patient Id listed below. The ExtrinsicObject returned will include the home attribute.

  2. Send Retrieve request including the home attribute in the request.

  3. Find your FindDocuments event and your Retrieve event in the simulator log [here](http://xds1:8080/toolkit/Xdstools2.html#SimLog:cat__ig/rep/ret/all). Once you have selected the event its URL will display at the top of the tool. The event URL looks like:

This link is an example - the real link will be copied out of the tool.

Event Link: http://xds1:8080/toolkit/Xdstools2.html#SimLog:default__ig/reg/sq/2017_01_03_21_18_00_286
  1. Copy the URL for the FindDocuments event and the Retrieve event into the Gazelle chat window labeling them (one query the other retrieve):

    FindDocuments event: http://xds1:8080/toolkit/Xdstools2.html#SimLog:default__rg/reg/sq/2017_01_03_21_18_00_286
    Retrieve event: http://xds1:8080/toolkit/Xdstools2.html#SimLog:default__ig/ig/igr/2017_01_18_21_20_42_605

Monitors - how to evaluate this test

The Gazelle chat window for the test instance will contain an entry like this:

FindDocuments: http://xds1:8080/toolkit/Xdstools2.html#SimLog:default__rg/reg/sq/2017_01_03_21_18_00_286

You should be able to click on this link (or copy/paste it into your browser). It will launch toolkit in a separate browser tab and display the log for the transaction the vendor is claiming as evidence for the test.

The right half of the screen is dominated by two text displays at the top - one labeled Request Message and the other Response Message.

Inspect the vendor’s Request Message. The message will represent a query request or a retrieve request. On the left side of the screen is a list of transactions (only one present). It will be labeled as IG_Query or IG_Retrieve. Knowing whether it is a query or a retrieve will help you decipher the XML.

You are looking to verify that a GetDocuments or Retrieve Documents request includes the home (homeCommunityId) attribute.

In a query request it looks like this:

<query:AdhocQueryRequest xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
    xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
    <AdhocQuery id="urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4"
                home="urn:oid:1.1.4567334.1.1">

The important part is the home attribute (last line shown here). It must be present and formatted as shown (urn:oid: prefix and an OID value following). This XML snippet will be buried in the middle of the message following the SOAP header.

In a Retrieve Documents request it looks like this:

<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ihe:iti:xds-b:2007 file:/Users/bill/ihe/Frameworks/ITI-4/XDS.b/schema/IHE/XDS.b_DocumentRepository.xsd">
 <DocumentRequest>
    <HomeCommunityId>urn:oid:1.1.4567334.1.1</HomeCommunityId>
    <RepositoryUniqueId>1.1.4567332.1.1</RepositoryUniqueId>
    <DocumentUniqueId>1.42.20170118211859.2</DocumentUniqueId>
</DocumentRequest>

where it is coded as a HomeCommunityId element. This content will be at the end of the message.

If the home/homeCommunityID attribute is present then the test passes.

Building the test environment (for Test Event Managers)

The Red (catred), Green (catgreen), Blue (catblue) systems are already built as described at [[Building the Simulators for Connectathon]]. They contain Registry, Repository, and Responding Gateway. The only missing element is catig, an Initiating Gateway that forwards requests to only catred. This forwarding is established in the catig simulator config.

Next use the Manage PIDs tool to send the above Patient ID to catred. This is done by entering the above PID into the Add Existing PIDs box and pressing Add to Favorites. Select it in Favorites. Use the Send To facility at the bottom to send to the catred simulator ONLY.

While this Patient ID is on the Favorites list, use the XDS Provide and Register tool to send a single transaction to cat__red. This is the test data vendors are looking for when they query.

Now go back to Manage PIDs tool and remove this PID from the Favorites list. It is not needed there anymore.

Clone this wiki locally