IHE Profile – ITI 8 (Patient Identity Feed)

ITI-8 is the HL7v2 format of ITI-44. Both ITI-8 and ITI-44 performs same action (i.e) Sending Patient Identity Feed. Based on the requirement of HIE, the EHR’s are expected to send the corresponding data. Some HIE expects ITI-8 (HL7v2 format) format and some HIE expects ITI-44 (HL7v3 format).

While communicating this message from an EHR entity to HIE, sometimes the HIE expects data to be sent in a VPN tunnel as IP/PORT socket connection. At times, the data communication happens through webservices interaction where the HIE will expect the HL7 data to be bind inside a soap envelope and then communicate to them.

This message is a transaction between EHR to HIE, EHR is described here as Patient Identifier Cross-Reference Consumer and HIE is described as Patient Identifier Cross-Reference Manager as well as Document Registry. Even though the working of  Patient Identifier Cross-Reference and Document Registry are not the same.


What exactly is Document Registry?

The Document Registry is an Actor that (actually a software/Database) maintains metadata about each registered document in a document entry or each patient records. Note that it maintains only meta-data (index of main data). The Document Registry responds to queries asked to it regarding documents meeting specific criteria.

What is Patient Identifier Cross Referencing (PIX) ?

The concept of transmitting the patient identifier information (patient id) from patient identifier source (EHR in our scenario) to the patient identifier cross reference manager is called Patient identifier cross referencing (so called PIX)

The Patient Identifier Cross Reference Manager is basically a software that receives data from any patient identity source and provides the data to document registry for performing query operations as shown in the picture below:


Actions performed in ITI – 8 :

The EHR will send the HL7 ADT messages to the HIE to do the following activities:

  1. ADT^A01 – Patient Admit Message
  2. ADT^A04 – Patient Registration Message
  3. ADT^A05 – Patient Pre-Admission Message
  4. ADT^A08 – Patient Update Message


But note that, in real-time an HIE might or might not adhere to this IHE profile standards.

Let’s logically discuss the above statement.

A04 : A “register patient” message (A04 event) signals that the patient has arrived or checked in as an outpatient, recurring outpatient, or emergency room patient. This message contains the information of patient as well as other information like next of kin, insurance or guarantor information as well.

A08 : Whenever any important information related to the patient is updated then this will be communicated as A08 message (for eg: visit information of patient, name, date of birth, or any information related to the patient).

Scenario :1
consider a scenario, Where a patient named zzzz is registered in a hospital and his details are sent to the HIE in the form of ADT A04 message.
Now, no demographics information of a patient zzzz is changed except his physical location upon which he was admitted. Like he is moved from Bed Number 305 to 405. In this case, it does not make sense to send this message as patient update because all the demographics fields are intact and same. And it is good to send an A02 message a Patient Transfer Message instead of Patient Update Message.

When A02 is sent, then it makes more sense because this message will contain change in assigned patient location in PV1-3 segment, while the old patient location appears in PV1-6-(prior patient location) and other demographic changes will be same.

According to HL7, if only the patient location change happens then EHR is expected to send an A02, but if the location change and demographic change both happened, then EHR should send an A08, But never both the messages i.e both A08 and A02 shouldn’t be sent.

Reference : http://www.hl7.eu/refactored/ch03.html

Similarly, If the patient is going to a temporary location (such as the O/R, XRAY, LIMBO, the HALLWAY) it is recommended that the A09 (patient departing tracking) and A10 (patient arriving tracking) events be used instead of A02.

But in the diagram provided above is IHE profiles suggested as per the document Vol2a there is no ADT A02 specified. Which makes this topic even more debatable.

Scenario 2:

Consider a scenario, where patient’s mother name is updated here patient’s mother is a Next of Kin, basically NK1 segment is changed. According to the above diagram, we have to send this as ADT^A31 message.

But, by the definition of ADT^A31 it is shown that it is “An update of any person information & the person need not be patient”. Which means it can be a patient as well. Now, to send the change of mother name, the EHR have the license to send either A31 or A08.

Reference : http://www.hl7.eu/refactored/ch03.html

An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application specific needs.

The right way to proceed this ITI-8 transaction is to get the details clarified from the HIE or the EHR person to determine what message to be sent based on the HIE acceptance.

A01 : The ADT A01 message will be used only for Inpatients. In other words this message is for ‘admitted patients only’. Not for clinic visits or outpatients.

A05 : The ADT A05 is a pre-register message, if the patient is scheduled for an operation, then the operation theater, setup and post-operation bed setup all information will be sent in this message.



HIE – Terminology definitions


The word “Enterprise” is used in IHE / HIE manuals to mean a separate hospital or separate medical clinic. If HIE is receiving patient data form 7 different medical clinics, 4 different lab facilities and 3 different hospitals.

In this scenario, we will refer that this HIE has 14 enterprises inside it. So, basically the term “Enterprise” is used to refer the entities (labs, hospitals or clinics) registered with a HIE, regardless of them being an enterprise hospital group or not.


MPI is simply abbreviated as Master Patient Index. It’s basically provided by a software/database used by hospitals/organization to maintain single source of medical record across multiple departments for a patient.

Imagine a patient named patient-x entering to the hospital where each department of the hospital is using different software of their ease. The patient visits an outpatient clinic inside the hospital where the physician provides a unique patient id (MM565465) for the patient-x. Then patient-x enters to the radiology area where a different software is used and the radiology people assigns a different id for the patient (1234), the same patient-x goes to the lab to take some more tests and lab uses another lab software and provides him with the patient id (4567).

Now the single patient-x is assigned with multiple patient Id’s based on different software used in different department of the same hospital. As shown in the picture below


The hospital with multiple departments are expected to have single software or the master Database where the patient-x’s different Id’s from different departments will be provided with one unique id, this ID is called Master Patient Index (MPI) and the software used for this is called PIX manager.

Community & Cross-Community:

we come across terminology “Community” in HIE/ IHE manuals. The word “Community” is an alias name for single HIE.

The communication across the HIE entities are represented in the below picture.hie_communication
when HIE B has to communicate with HIE F for patient data, it is referred as “Cross Community Access”. Here the cross-community gateway is basically a software that connects, transfers the data from one HIE to another HIE.


The abbreviation of this simple three letter word is “Cross Enterprise Document Sharing” and one can notice that this terminology is used across multiple places of any HIE document.

Imagine  if an HIE has 7 (Eg: 3 hospital, 3 clinics & 1 lab) enterprises bound with it. This HIE is storing the patient named X from all these 7 hospital or clinics or labs (i.e) 7 different enterprises, then it is referred as XDS.

If suppose as referred in the picture above, if the HIE A wants to send a patient information with HIE F, this cannot be called “Cross Enterprise Access”. This  is called as “Cross Community Gateway” as mentioned above. Since, each HIE has multiple enterprises and one HIE is considered as one community when one HIE communicates with another it is termed as cross community access. But within one HIE when communication takes place the term Enterprise comes to picture.

Data Source:

It is one of the common terminology used in the definition document of several IHE profile ITI messages. Consider the QPD segment of the QBP^Q23 message, this is bound to the ITI version 9

QPD | IHE PIX Query | QRY124518648946312 | 14583058^^^NIST2010&2.16.840.1.113883.3 . | ^^^&2.16.840.1.113883. |

Here QPD 3.4 refers the Assigning Authority and QPD 4 refers to the Data source. Imagine if 14583058 is a  Medical Record Number used by EHR named EHR-x by the clinic “Good Health Medical Clinic”.

The OID for “Good Health Medical Clinic” is 2.16.840.1.113883.3 . The physician from the Good Health Medical Clinic wants to search for the patient in St.Joseph hospital.

The OID provided for the St.Joseph Hospital is 2.16.840.1.113883., so basically the Data Source here specifies the St.Joseph Hospital that is the location of the hospital upon which the patient has to be searched for. This target search location is often termed as Data source.


IHE Profile – ITI 9 (PIX Query)

ITI-9 is the HL7v2 format of ITI-45.  Both ITI-9 and ITI-45 performs PIX Query. Based on the requirement of HIE, the EHR’s are expected to send the corresponding data. Some HIE expects ITI-9 (HL7v2 format) format and some HIE  expects ITI-45 (HL7v3 format).

While communicating this message from an EHR entity to HIE, sometimes the HIE expects data to be sent in a VPN tunnel as IP/PORT socket connection. At times, the data communication happens through webservices interaction where the HIE will expect the HL7 data to be bind inside a soap envelope and then communicate to them.

This message is a transaction between EHR to HIE, EHR is described here as Patient Identifier Cross-Reference Consumer and HIE is described as Patient Identifier Cross-Reference Manager



Message Type:

  • The ITI-9 uses HL7V2.5 as a reference model

Message communication :


The Identifier QBP^Q23 is the Message ID/Identifier (MSH.9) of the Request sent from the EHR to the HIE. Similarly, RSP^K23 is the response sent from the HIE back to EHR (MSH.9).

The PIX Query ITI-9 shall contain the following segments with it, the same HL7v3 of <queryByParameter> is represented as QBP here in HL7v2.



  • MSH.3.1 – SENDER ID (Any Mnemonic from the sending Facility (clinic/hospital/healthcare organization) – Facility Identifier)
  • MSH.4.1 – SENDER APPLICATION (Mnemonic used by the sending (EMR) of the facility)
  • MSH.5.1 – RECEIVER APPLICATION (EMR/Interface Engine/ used at HIE end)
  • MSH.6.1 – RECEIVING FACILITY (Facility ID of the HIE)
  • MSH.7.1 – Date and Time at which the message is sent (System generated current date/time of format YYYYMMddHHmmss)
  • MSH.9.1– Says the type of the message, QueryByParamter is referred here as QBP
  • MSH.9.2 – Says the subtype (Event) action of this message. Here Q23 is a request for getting identifiers.
    Q23 – Get Corresponding Identifiers
  • MSH.9.3 – It implies that the message with the event type Q23 and Q21 are similar in structure.
  • MSH.10 – Control ID (Generated By EHR can be anything unique from the sending application)
  • MSH.11 – This component is similar to the <processingCode> in HL7v3 message which implies the environment upon which this message is communicating with HIE. Either Testing (T) or Production environment (P) correspondingly
  • MSH.12 – Version Number (2.5) hard-coded
    /*Optional Entry*/
  • MSH.8 – Implies a security field which is optional.

QPD|IHE PIX Query|QRY124518648946312|14583058^^^NIST2010&2.16.840.1.113883.3 .|^^^&2.16.840.1.113883.

  • QPD.1 – Is of Length to a maximum of 250 characters and this defines the Message Query Name. This can be as literal as IHE PIX Query or anything that the EHR would like to send. (Required)
    But By 2.5 standards QPD.1 can have multiple sub-components which can be used by the EHR as they need (on demand). Although all the below mentioned sub-components are the fields described by HL7v2.5 standards, but IHE standards does not expect all the values to be occupied while communicating to HIEQPD.1 segments
  • QPD.2 – Is of Length to a maximum of 32 characters and this defines the Query Tag, this is a unique query number tag, just like the control Id sent in the MSH segment. This is a alpha-numeric field. The purpose this field is to keep track of the queries been sent to the HIE and to uniquely identify the query messages. (Required)
    By 2.5 standards the QPD.2 segment contains only one field. That is String value.
  • QPD.3.1 – This is the patient identifier (can be numeric/alpha-numeric) which will uniquely identify the patient within the given patient domain*.
    Patient Domain : Is the hospital/clinic/healthcare organization upon which given particular patient has to be searched.
  • QPD3.4 – This specifies the Assigning authority of the patient. You may have a doubt why QPD3.2,3.3 where not specified. Basically QPD3.1, QPD3.2 & QPD3.3 all refers to the patient ID segment. The sender EHR will have to provide definitely the patient Identifier value in any of these fields.

    For Example: The EHR can send the Patient ID value in either 3.1,3.2 or 3.3. The Assigning authority mentioned in 3.4 will just have to be specific to patient id sent in any of these three fields.

    If the EHR believes that more than one patient specific details has to be sent, in that case they can send the basic patient Id in the 3.1 segment and send other information like SSN or patient account number in 3.2 and 3.3

    In the above case, when all the three segments are filled with value. The first component will be taken as a reference for determining the 3.4 value. Which means the Assigning Authority has to define authority of the assigned patient Id. On the Example it is provided with the NIST&OID&ISO this is also a way of representing the assigning authority but for clear example refer this site here 

    The above provided segment is  an example of  QPD.3 segment. As per the specification you must have the QPD 3.1 and QPD3.4 is required entity which means your PID and assigning authority is required field

  • QPD4 : This specifies the domain at which the patient has to be searched. Note: this is an optional segment. This means that if this value is not provided then the HIE software will search for this patient ID across domain* (use this link to know what is across domain)
    The responding system shall return the Patient ID value for each requested domain if a value is known.

RCP Segment:

  RCP|I |

This segment is abbreviated as Response Control Parameter. This segment has 7 meaningful segments according to the HL7v2.5 standards. All the available segments are shown below:RCP segmentsAccording to HL7 standards RCP is a required segment for a QBP message. But, IHE does not require PIX query to be sent to HIE with all the values specified by the HL7 standards.

IHE standards requires the value to be sent on the first segment of RCP segment. This segment stands for Query Priority. This can have only two value I for immediate and D for Deferred as shown in the picture below:

RCP first segmentThe RCP segment will always be set to the value I indicating that the response to the request should be sent immediately.


IHE Profile – ITI 45 (PIX V3 Query)

The explanation of this IHE profile is done under the assumption that any EHR who would like to communicate to HIE will adhere to IHE standards. The following ITI – 45 specifications are explained in such a way what an EHR would need to send to HIE to get the communication going further.

What is ITI – 45:

ITI – 45 is a PIX Query established in HL7V3 format. An ITI – 45 message profile is used between Patient Identifier Cross Reference Consumer and Patient Identifier Cross Reference Manager actors


In our scenario, the Patient Identifier Cross-reference Consumer is a EHR and Patient Identifier Cross-reference Manager is HIE.

Actions Performed:

  1. The EHR will send queries as request for HIE to fetch a list of corresponding (patient identifiers)*.
  2. The HIE would accept the request from EHR and references the patient identifier (across domains)* and returns a list of patient identifiers back to EHR assuming the HIE finds the patient identifier match.

* patient identifier:
Suppose patient A is admitted to XYZ hospital  on /1/2016.
XYZ Hopsital assigned medical record Number 12345
Patient again admitted, but at a different hospital called LMN
LMN hospital assigned medical record number D8

This medical Record Number is called Patient Identifier

* across domains: 
Imagine a Patient AAA exists
Patient AAA is admitted to XYZ hospital on 2015
Patient AAA is admitted to LMN hospital on 2015
Patient AAA admitted to QQQ hospital on 2015
Patient AAA treated by DDD clinic on 2015
XYZ, hospital, LMN hospital, QQQ hospital, DD Clinic are all called Domains. Other name for each one of the is “Enterprise”
If PIX manager search for patient “Medical Record numbers” in multiple domains (in response to PIX query), then the language is “across domains” or “cross domains” search X = across or across

The first action performed by the first actor is called Patient Registry Query Placer (Application Role : PRPA_AR201303UV02) and the second action performed by the second actor is called Patient Registry Query Fulfiller (Application Role: PRPA_AR201304UV02)
(Application Role * will be explained in a separate blog post, for understanding: An application Role can be any device or software who send/Receive message)

Note: PRPA_AR201303UV02 is not a message ID
PRPA_AR201303UV02 is a software component ID
The software that performed PIX placing action and software that performs PIX fulfilling action are assigned Application Role Identifiers.


Note:  PRPA_IN201309UV02 is called message Identifier/ID ( Not application Role identifier/ID)
PRPA_IN201310UV02 is called message Identifier/ID ( Not application Role identifier/ID)
Do not confuse between message ID vs application Role ID terminology used by HIE

It is clear from above diagram that the EHR will send a request message and this message is called Patient Registry Get Identifiers Query also referred as PRPA_IN201309UV02 meaning it is a request from EHR to HIE.

The response from the HIE to the EHR (a.k.a response message) is called Patient Registry Get Identifiers Query Response also referred as PRPA_IN201310UV02 meaning it is a response from the HIE to EHR.

Sample HL7V3 PRPA_IN201309UV02 Request from EHR to HIE is provided below


The schema document of this message ITI-45 can be found in Pg number: 98 of this document. Here is the direct link for schema document.

The sample message provided here is taken from OpenEMPI confluence link. The examples provided by the IHE schema in document volume 2b does not contain ITI-45 message type but all other ITI PIX Query message were available, you can find the actual examples provided by IHE specification here examples in this link

Message Breakdown:
This message contains two parts
a) Transmission Wrapper (a.k.a) HL7V3 Transmission Wrappers
b) Control Act Wrapper

a) Transmission Wrapper:

The first half of the entire XML is called Transmission Wrapper, which includes sender and receiver information as shown below


  1. <PRPA_IN201309UV02> is the message identification/ID tag, this denotes this message is Get Identifiers Query message. The ITI-45 profile contains only two messages PRPA_IN201309UV02 (request) and PRPA_IN201310UV02 (response). This tag will be different for different ITI messages, for Example: ITI-44 has types of message PRPA_IN201301UV02, PRPA_IN201303UV02 and PRPA_IN201304UV02
  2. <id root=””> provides a GUID value, This is a GUID value of the sender EHR, when the response message comes, it will also contain the same GUID, representing that the data is sent to this specific EHR. This GUID will be sent by the EHR dynamically from their system.
  3. <creationTime value=””/> Represents the time at which this request is triggered, this will be sent by EHR from their system generated time in the format of YYYYMMddHHmmss
  4. <interactionId root=”” extension=””>The Interaction root ID will be provided by the EHR to the HIE, although the extension will be same as that of the header tag. (Question: Who will provide this OID to the EHR?)
  5. <processingCode code=””> This can have only two values either P or T, meaning it can be either Production Environment or Testing Environment. This can be taken as static value depending on environments by the EHR.
  6. <processingModeCode code=””> This value will be sent dynamically by EHR as it might have 4 possible values A (Archive),T (Current  processing),I (Initial Load), R (Restore from archive). (Question: How does an EMR know what has to be sent in here?)
  7. <acceptAckCode code=””> Valid values are AL (Always), ER (Error/reject Valid values are AL (Always), ER (Error/reject  only), NE (Never) Ideally EHR will always expect the HIE to send a response back, it should be set to AL by default.

Receiver Information:

  1. <receiver typeCode> This will be a static value and it will be set to RCV meaning its a Receiver.
  2. <device classCode=”” determinerCode=””> The value of classCode will be set to DEV by default, but determinerCode can have two values either INSTANCE or KIND. Where, INSTANCE means particular id, person, device KIND is a literal meaning for KIND OF, kind of Id’s, people, devices, software’s etc.
  3. <id root=””> This id root will be provided by the HIE to the EHR. HR will be communicating with HIE to get their HR will be communicating with HIE to get their  respective OID. This id tag SHALL not require extension.

Sender Information:

  1. <sender typeCode=””> This will be a static value and it will be set to RCV meaning its a Receiver.
  2. <device classCode=”” determinerCode=””>The value of classCode will be set to DEV by default, but determinerCode can have two values either INSTANCE or KIND. Where, INSTANCE means particular id, person, device KIND is a literal meaning for KIND OF, kind of Id’s, people, devices, software’s etc.
  3. <id root=””> This should be one of the Baby OID that the EHR purchases and assigns for the device. Its a device OID from which the message will be sent to the HIE.

b) Control Act Wrapper:

The second half of the entire XML is called Control Act Wrapper, which includes Query parameters, which means the actual items needed for querying as shown below


  1. <controlActProcess classCode=”” moodCode=””> This is a static value and represents the starting of the control act transmission wrapper. This is a static data.
  2. <code code=”” codeSystem=””> The code PRPA_TE201309UV02 means that the queryByParameter message to request that HIE device/application to return all patient information. Also notice that a message with PRPA_IN201309UV02 will always have PRPA_TE201309UV02 by default. HIE will supply the coding system id to the EHR
  3. <author> is a optional segment/section which means the author of message request
  4. <queryByParameter> contains one root id and extension. EHR will provide this OID and the HIE will send a acknowledgement back with the same OID, Extension will also be provided by the EHR in the form of any unique combination so the each request sent by the EHR will have a unique id combining the OID and the extension value.
  5.  What is Data source?


6. What is Patient Identifier?



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:

  1. A reference to a predefined query
  2. 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.


  1. 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.
  2. <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^^^&amp;;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:


Blog at WordPress.com.

Up ↑