This would not be proprietary communication at all.
Clinicians needing to make a query would use the XDS consumer (clinical front end). 1. Initiating gateway in Hospital A would be convert the local ID to NHS no, and pass it to another Trust B within the community requested by the clinician (transaction similar to a PDQ query which an XDS consumer does to populate the patient banner anyway). 2. Responding gateway would map the NHS ID to local ID and do a local XDS registry query--to pass the information back to the initiating gateway for display by the XDS consumer .
If you look at the transactions required by the XCA gateway, it is very similar to what is required by the XDS consumer. It seems like a logical grouping from a clinicians perspective--WE need to define when and which hospital to query for XDS documents.
In fact, it says : "When a Responding Gateway is NOT grouped with a Document Consumer actor it is expected to be using non-IHE specified interactions to collect local information in response to a Cross Gateway Query or Cross Gateway Retrieve. These proprietary interactions are not further described within any IHE profile."
The TF covers two deployment scenarios for the Initiating Gateway.
The Gateway can be integrated in the Registry. In that case whenever a query is sent to the gateway, it is performed in the local registry database through the internal mechanism of the application. This is what the TF describes as "non-IHE specified interactions".
The Gateway can also be a stand-alone product. When consumers send a query to the gateway, and they expect to receive both local and cross-domain results, then the Gateway will get the cross-domain requests through the cross-gateway query, but it cannot use that on the local registry. Instead, it must use ITI-18 for that, and IHE describes this adding of functionality as: "the gateway must be grouped with a consumer".
This terminology sometimes causes confusion, but the fact is that many applications are built up from multiple actors. This is not a matter of putting two entities in one box, but rather supporting a set of transactions that causes it to comply with the requirements of multiple actors. In the case of the Gateway/Consumer grouping, this means that the gateway must support ITI-18 and ITI-43 as a server (to satisfy consumer requests) and ITI-18, ITI-38, ITI-39 and ITI-43 as a client. Since ITI-18 and ITI-38 are very similar, they will usually be handled by the same module, which could choose the type of transaction based on a flag in the list of Affinity Domain Query URL's that tells it that this is the local Registry.
The whole purpose of this mechanism is to encapsulate the XCA mechanism and allow existing consumers to work with XCA as if it was all happening locally. Giving every consumer its own gateway would make administration quite complex.
"On the XDS consumer he has an icon which on clicking allows him to do a XCA query into a neighbouring XDS domain" I think it is a good requirement for a consumer to be able to query multiple domains. But this should be as simple as selecting the right URL to send the ITI-18 query to, not to encapsulate the whole Gateway mechanism.
"WE need to define when and which hospital to query for XDS documents" Yes, and this leads to requirements for the Gateway vendors. They should give enough flexibility by allowing users to define multiple URL's that correspond to logical groupings of Affinity Domains, to avoid having to choose only between local and the whole world.
This is my simple clinical take on this -When an XDS consumer is launched by the clinical user from PACS/RIS/other IT application--it will do a local registry query to display the list of images and documents indexed in the local XDS Registry. --However, the XDS consumer should also be able to do a XCA gateway query on an ad-hoc basis--to query 1 or more regional XDS registries, which can be interrogated by the XCA gateway. This will require sharing agreements being in place and query to be based on the XDS consumer sending the NHS no to the XCA gateway. XDS consumer should then provide a consolidated list of images and documents on the metadata list display for both local and regional XDS registries queried by the clinical users.
Does this make sense in what I am trying to say from a clinical point of view, Pim?
posted on Tuesday, February 02, 2016 - 02:58 pm
These are perfectly valid use cases. And since the XCA profile is silent about how the user interface of an XDS consumer should allow a user to select sources of information, it is a good idea to mention this in the additional consumer requirements.
>3. On the XDS consumer he has an icon which on clicking allows him to do a XCA query into a neighbouring XDS domain
Ideally, the consumer should not be aware of whether he queries a registry or a gateway, as long as he can perform the ITI-18 transaction. Likewise, one could shift the responsibility of the transformation of the Patient ID to the Initiating Gateway, since that is aware of the Patient ID Assigning Authority of the Affinity Domain behind each Responding Gateway.
posted on Tuesday, February 02, 2016 - 03:07 pm
I atree with Pim, and although I stated it in a different way in an earlier response, the key issue is that a consumer sends its queries to one single system (either the local registry [in case there is no XCA gateway], or to the XCA gateway [which will redirect to both the local registry as well as any other communities it is connected with]).
Note that a consumer, in its query to the XCA gateway, may wish to use a parameter to indicate it wishes to see the metadata as present in a specific [set of] communities. So even if one wishes to only see 'local metadata', the query would still go to the XCA gateway. A consumer has one single point of contact which it uses to query for metadata.
It is the intent that a XDS community has just one single XCA gateway, and not multiple installations thereof.
posted on Wednesday, February 03, 2016 - 09:29 pm
Thanks Pim and Rene, Your comments are much appreciated.
XDS CONSUMERS SUPPORTING FEDERATED XDS QUERIES: 1. LOCAL XDS QUERY: When an XDS consumer is launched by the clinical user from PACS/RIS/other IT application--it will do a local XDS registry query to display the list of images and documents indexed in the local XDS Registry. 2. FEDERATED XDS QUERY--XDS consumer should also have an icon, which on clicking, allows the user to do a federated XDS query to one or more neighbouring XDS registries within a Clinical Network (This would be via XCA gateway query). A federated XDS query would provide a consolidated list of document and images within the clinical network served by the XCA gateway. On the consumer the user should be able to define which registries he wishes to query. NB: XCA gateway would be required to support the XDS consumer in the federated query by transformation of the Patient ID.
It would be nice to have a choice in the consumer whether to avoid the trip through XCA or not. I guess there are some use cases where we are only interested in documents published in the local domain, and we want a quick response back. There is surely a time penalty if the local XCA has to connect to several remote XCA actors to return what they know about a particular patient (identified by NHS number). It might be better if the local client could do the local query first, return those results to the client, and then asynchronously perform an XCA query to fill in additional content as a background task. (without locking up the client, waiting for everything to complete).
I think we also need to continue to work with our suppliers so that in the event of a local (to the affinity domain) PDQ not returning a patient, that a Spine-2 service be called, so if there is an NHS number for the patient in question in Spine PDS - or possibly a list of patients that match the search criteria, that it is returned to the client for the user to select one for a subsequent XCA query.
posted on Thursday, February 04, 2016 - 06:05 pm
Nick, I completely agree.
1. The default position when an XDS consumer is launched --is for it to do a local XDS registry query (without involving an XCA gateway)--to get a instant response. Most of the time we may not need a network XCA query at all. 2. However, the XDS consumer should be able to an ad-hoc query to the XCA gateway for 1 or more Trusts within the Clinical Network. (The suggestion from Pim is for the XCA gateway to the do Patient ID transformation--i.e. conversion from Hospital/PAS ID to national ID/NHS no--and forward the query to responding gateway--I think that is a sensible view)
We would still need a PDQ supplier within the Enterprise--for 2 purposes. 1. Display up-to-date patient banner information 2. Provide Patient demographics to an XDS source--e.g if a source uses a barcode scanner to input just the ID.
I am really proud of our suppliers who have used the XDS standards to prove interoperability between themselves:
1. Multiple XDS sources-- a. XDS source for radiology requests (scanned card or elecrtonic request from ICE Ordercomms)--as PDF documents wrapped with XDS metadata--from Rogan-Cannon RIS b. XDS-I source for radiology images--Lexmark acting as our VNA supplier for DICOM Archive and XDS-I source (sub-contracted through Fujifilm) 2. XDS Registry and Repository--Lexmark (sub-contracted through Fujifilm) 3. Multiple Consumers: a. Fujifilm XDS consumer b. Rogan-Cannon XDS Consumers 4. PDQ supplier from Fujifilm--to provide up-to-date demographics to XDS sources and XDS consumer banner 5. Multiple formats--DICOM for images and PDF/a for documents.
We now have a proof concept for a Multi-specialty, multi-format Enterprise Archive where the content is accessible to ANY vendors viewer, provided the viewer supports XDS consumer!