IHE Profile – ITI 18 (Registry Stored Query)
ITI – 18 is used by Document Registry and Document Consumer actors. Both of these actors may use Synchronous or Asynchronous web service exchange.
Definition : IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21 (Pg: 91)
When two actors referred as Requester and Provider want to exchange information in a request-response pattern, then this communication can happen in two ways as Synchronous and Asynchronous web service exchange pattern.
Synchronous web service exchange:
In Synchronous web service exchange the requester (system which send the request) will send a request and wait for the provider (system which will respond for the request) to respond in the same connection (socket connection) which the requester initially established.
In Synchronous web service exchange a provider will always be available to respond whenever the requester send their message. Here response sender is a HIE (i.e) provider is a HIE and Requester is a EHR Middleware
Asynchronous web service exchange:
In Asynchronous web service exchange the requester will send a request knowing that provider will eventually send the response. The provider may not be available by the time the request is sent.
When the provider receives the message it will send the acknowledgement back to the requester In simple words, Asynchronous is only concerned about sending a request. EMR will send only the request and whenever the HIE is available, it will receive it.
Definition : IHE_ITI_TF_Vol2x (Pg : 135)
The Document Consumer will send a request query by passing parameters to it. The Document Registry services the query based on the defined definition it has. In this scenario the Document consumer will be a EHR and the Document Registry is a HIE.
Registry Stored Query is the request query from the EHR to the HIE. It contains two elements:
- A reference to a predefined query
- parameters to a query
Message Breakdown:
The ITI 18 message follows ebXML Registry Information Mode Version (RIM) 3.0 . This ITI 18 ebXML stored query takes three forms of parameters
a) returnType
b) QueryID (an UUID) and
c)Query Parameters
Find the sample HL7v3 request from Document Consumer to Document Registry.
- The message that starts with <query:AdhocQueryRequest> is a root element or the header tag, this provides all the necessary namespaces for the document standards, this is a static data.
- <query:ResponseOption> contains two attributes returnComposedObjects and returnType. the default value of returnComposedObjects will be set to “true”, which literally means the request is expecting a response back
returnType: The returnType can have two values 1. LeafClass 2. ObjectRef,
The LeafClass returns a list of XML elements of fully specified ebXML objects. This type of query result is self-contained, everything known about the object(s) is returned.
The ObjectRef returns a list of UUID which references to the registry object that matches the query. This type query is recommended when the returned object list could be large.
In real time an information has to be provided from the EHR to determine what kind of returnType is expected either LeafClass or ObjectRef
3. <rim:AdhocQuery> contains only one attribute called id this is referred as QueryID. This is most important and required field. These are IDs (a list predefined) that are used in the AdhocQueryRequest to reference certain actions to be performed. For Example: EHR will request the HIE to Find Documents or Get Related Documents. Based on this request ID, the corresponding query parameters will change.
Query IDs are in UUID format (RFC4122). An error will be returned to the requester whenever unsupported query id is provided. The below provided are the list of actions and their corresponding Query ID
Definition: IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21 (Pg: 113)
You can notice that in the XML provided as sample the Query ID specified is <rim:AdhocQuery id=”urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d”> which refers to the QueryName Find Documents.
4. In the sample XML you can also see <rim:slot> beginning sections, and the number of parameters were passed. All these parameters depends on the Query ID provided, For Example if the QueryID provided is for the action of Find Documents, then the query parameters will have the following data with it.
Definition: IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21 (Pg: 99)
For the QueryID with the name of Find Document the table provides parameters that needed to be passed. The <rim:Slot name=””> must be filled with the Parameter Name column of the table <rim:Value></rim:Value> must contain the corresponding value of the parameter. Note: Not all parameters are required for this, only highlighted ones which are those mentioned as Required (R) in Opt column is needed.
Now comes another question.. in the provided XML sample you can notice that a patient ID is provided in this format <rim:Value>’st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO’</rim:Value> How will the EHR know what elements are these?
For this refer IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21.pdf document (pg number 95), these are nothing but the coding standards of ebXML specification. The general Syntax of this will be <value> (‘code1^^coding-scheme1’) </value> and it can have multiple values <Value>(‘code1^^coding-scheme1′,’code2^^coding-scheme2’)</Value>
For the Query ID with the name of Find Submission Sets the below are the expected parameters:
