IHE ITI TF Vol2

3.51 Multi-Patient Stored Query [ITI-51]

This section corresponds to transaction [ITI-51] of the IHE Technical Framework. Transaction [ITI-51] is used by the Document Consumer and Document Registry Actors.

3.51.1 Scope

The Multi-Patient Stored Query supports a variety of queries for multiple patients. It is based on the Registry Stored Query [ITI-18] transaction. The main difference is the set of queries, which is specified in this transaction.

3.51.2 Use Case Roles

Actor: Document Consumer

Role: Issues a Multi-Patient Stored Query to retrieve metadata or object references associated with multiple patients based on query parameters

Actor: Document Registry

Role: Responds to a Multi-Patient Stored Query by providing the metadata or object references of registry objects which satisfy the query parameters

3.51.3 Referenced Standard

ebRIM

OASIS/ebXML Registry Information Model v3.0

This model defines the types of metadata and content that can be stored in an ebXML Registry, a basis for and subset of Document Sharing metadata.

ebRS

OASIS/ebXML Registry Services Specifications v3.0

This defines the services and protocols for an ebXML Registry, used as the basis for the XDS Document Registry

See ITI TF-2: Appendix V for other referenced standards for SOAP encoding.

See ITI TF-2: 3.18 for the Registry Stored Query [ITI-18] transaction.

See ITI TF-3: 4.2 for other referenced standards for metadata element encoding.

3.51.4 Messages

Figure 3.51.4-1: Interaction Diagram

3.51.4.1 Multi-Patient Stored Query Request

This is a query request from the Document Consumer to the Document Registry. The query request contains:

A reference to a pre-defined query stored on the Document Registry Actor
Parameters to the query

3.51.4.1.1 Trigger Events

The message is initiated when a Document Consumer wants to query for metadata based on criteria spanning multiple patients (multiple Patient IDs).

3.51.4.1.2 Message Semantics

The message semantics are identical to those documented for the Registry Stored Query [ITI-18] transaction except where noted below. The following sections document the differences.

Document Consumer and Document Registry Actors that support the Asynchronous Web Services Exchange Option shall support WS-Addressing based Asynchronous Web Services requirements as defined in ITI TF-2: V.3.

3.51.4.1.2.1 Query Definitions

This transaction defines the following Stored Queries that may query for multiple Patient Ids.

3.51.4.1.2.1.1 FindDocumentsForMultiplePatients

This Multi-Patient Query is semantically identical to the FindDocuments Stored Query (see ITI TF-2: 3.18.4.1.2.3.7.1 ) except:

$XDSDocumentEntryPatientId is optional (may have zero values).
$XDSDocumentEntryPatientId may contain multiple values.
At least one of $XDSDocumentEntryPatientId, $XDSDocumentEntryClassCode, $XDSDocumentEntryEventCodeList, or $XDSDocumentEntryHealthcareFacilityTypeCode shall be specified in the provided set of parameters.

Returns: XDSDocumentEntry or ObjectRef objects matching the query parameters

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryPatientId 2	XDSDocumentEntry.patientId	O	M
$XDSDocumentEntryClassCode 1 2	XDSDocumentEntry.classCode	O	M
$XDSDocumentEntryTypeCode 1	XDSDocumentEntry.typeCode	O	M
$XDSDocumentEntryPracticeSettingCode 1	XDSDocumentEntry.practiceSettingCode	O	M
$XDSDocumentEntryCreationTimeFrom	Lower value of XDSDocumentEntry.creationTime	O	--
$XDSDocumentEntryCreationTimeTo	Upper value of XDSDocumentEntry.creationTime	O	--
$XDSDocumentEntryServiceStartTimeFrom	Lower value of XDSDocumentEntry.serviceStartTime	O	--
$XDSDocumentEntryServiceStartTimeTo	Upper value of XDSDocumentEntry.serviceStartTime	O	--
$XDSDocumentEntryServiceStopTimeFrom	Lower value of XDSDocumentEntry.serviceStopTime	O	--
$XDSDocumentEntryServiceStopTimeTo	Upper value of XDSDocumentEntry.serviceStopTime	O	--
$XDSDocumentEntryHealthcareFacilityTypeCode 1 2	XDSDocumentEntry.healthcareFacilityTypeCode	O	M
$XDSDocumentEntryEventCodeList 1 2	XDSDocumentEntry.eventCodeList 3	O	M
$XDSDocumentEntryConfidentialityCode 1	XDSDocumentEntry.confidentialityCode 3	O	M
$XDSDocumentEntryAuthorPerson 4	XDSDocumentEntry.author	O	M
$XDSDocumentEntryFormatCode 1	XDSDocumentEntry.formatCode	O	M
$XDSDocumentEntryStatus	XDSDocumentEntry.status	R	M
$XDSDocumentEntryType 5	XDSDocumentEntry.objectType	O	M

1 Shall be coded according to specification in ITI TF-2: 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

2 At least one of $XDSDocumentEntryPatientId, $XDSDocumentEntryClassCode, $XDSDocumentEntryEventCodeList, or $XDSDocumentEntryHealthcareFacilityTypeCode shall be specified.

3 Supports AND/OR semantics as specified in ITI TF-2: 3.18.4.1.2.3.5 .

4 The value for this parameter is a pattern compatible with the SQL keyword LIKE which allows the use of the following wildcard characters: % to match any (or no) characters and _ to match a single character. The match shall be applied to the text contained in the Value elements of the authorPerson Slot on the author Classification (value strings of the authorPerson sub-attribute)

5 See ITI TF-2: 3.18.4.1.2.3.6.2

3.51.4.1.2.1.2 FindFoldersForMultiplePatients

This Multi-Patient Query is semantically identical to the FindFolders Stored Query (see ITI TF-2: 3.18.4.1.2.3.7.3 ) except:

$XDSFolderPatientId is optional (may have zero values).
$XDSFolderPatientId may contain multiple values.
At least one of $XDSFolderPatientId or $XDSFolderCodeList shall be specified in the provided set of parameters.

Returns: XDSFolder or ObjectRef objects matching the query parameters

Parameter Name	Attribute	Opt	Mult
$XDSFolderPatientId 2	XDSFolder.patientId	O	M
$XDSFolderLastUpdateTimeFrom	XDSFolder.lastUpdateTime lower value	O	--
$XDSFolderLastUpdateTimeTo	XDSFolder.lastUpdateTime upper bound	O	--
$XDSFolderCodeList 1,2,3	XDSFolder.codeList	O	M
$XDSFolderStatus	XDSFolder.status	R	M

1 Shall be coded according to specification in ITI TF-2: 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

2 At least one of $XDSFolderPatientId or $XDSFolderCodeList shall be specified.

3 Supports AND/OR semantics as specified in ITI TF-2: 3.18.4.1.2.3.5 .

3.51.4.1.2.1.3 FindDocumentsByReferenceIdForMultiplePatients

This query shall be supported by Registries claiming the "Reference ID for Multiple Patients" Option.

This Multi-Patient Query is semantically identical to the FindDocumentsByReferenceIdList Stored Query (see ITI TF-2:3.18.4.1.2.3.7.14) except:

$XDSDocumentEntryPatientId is optional (may have zero values).
$XDSDocumentEntryPatientId may contain multiple values.

Returns: XDSDocumentEntry or ObjectRef objects matching the query parameters

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryPatientId	XDSDocumentEntry.patientId	O	M
$XDSDocumentEntryReferenceIdList ⁵	XDSDocumentEntry.referenceIdList ²	R	M
$XDSDocumentEntryClassCode ¹	XDSDocumentEntry.classCode	O	M
$XDSDocumentEntryTypeCode ¹	XDSDocumentEntry.typeCode	O	M
$XDSDocumentEntryPracticeSettingCode ¹	XDSDocumentEntry.practiceSettingCode	O	M
$XDSDocumentEntryCreationTimeFrom	Lower value of XDSDocumentEntry.creationTime	O	—
$XDSDocumentEntryCreationTimeTo	Upper value of XDSDocumentEntry.creationTime	O	—
$XDSDocumentEntryServiceStartTimeFrom	Lower value of XDSDocumentEntry.serviceStartTime	O	—
$XDSDocumentEntryServiceStartTimeTo	Upper value of XDSDocumentEntry.serviceStartTime	O	—
$XDSDocumentEntryServiceStopTimeFrom	Lower value of XDSDocumentEntry.serviceStopTime	O	—
$XDSDocumentEntryServiceStopTimeTo	Upper value of XDSDocumentEntry.serviceStopTime	O	—
$XDSDocumentEntryHealthcareFacilityTypeCode ¹	XDSDocumentEntry.healthcareFacilityTypeCode	O	M
$XDSDocumentEntryEventCodeList ¹	XDSDocumentEntry.eventCodeList ²	O	M
$XDSDocumentEntryConfidentialityCode ¹	XDSDocumentEntry.confidentialityCode ²	O	M
$XDSDocumentEntryAuthorPerson ³	XDSDocumentEntry.author	O	M
$XDSDocumentEntryFormatCode ¹	XDSDocumentEntry.formatCode	O	M
$XDSDocumentEntryStatus	XDSDocumentEntry.availabilityStatus	R	M
$XDSDocumentEntryType ⁴	XDSDocumentEntry.objectType	O	M

¹ Shall be coded according to specification in ITI TF-2:3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

² Supports AND/OR semantics as specified in ITI TF-2:3.18.4.1.2.3.5.

³ The value for this parameter is a pattern compatible with the SQL keyword LIKE which allows the use of the following wildcard characters: % to match any (or no) characters and _ to match a single character. The match shall be applied to the text contained in the Value elements of the authorPerson Slot on the author Classification (value strings of the authorPerson sub-attribute)

⁴ Valid values for this parameter are those defined in ITI TF-2:3.18.4.1.2.3.6.2.

⁵ The value for this parameter is a pattern compatible with the SQL keyword LIKE which allows the use of the following wildcard characters: % to match any (or no) characters and _ to match a single character.

3.51.4.1.2.2 Multi-Patient Stored Query IDs

The following Query Ids shall be used to represent these queries.

Query Name	Query ID
FindDocumentsForMultiplePatients	urn:uuid:3d1bdb10-39a2-11de-89c2-2f44d94eaa9f
FindFoldersForMultiplePatients	urn:uuid:50d3f5ac-39a2-11de-a1ca-b366239e58df
FindDocumentsByReferenceIdListForMultiplePatients	urn:uuid:1191642d-86c4-42d8-b784-f95445f9f0d5

3.51.4.1.2.3 Web Services Transport

The requirements for Web Services transport for Synchronous and WS-Addressing based Asynchronous are described in this section.

For the support of both Synchronous and WS-Addressing based Asynchronous web service exchange cases the requirements are the following.

The query request and response shall be transmitted using Web Services, according to the requirements specified in ITI TF-2: Appendix V.3. The specific values for the WSDL describing the Multi-Patient Stored Query Service are described in this section.

The Document Registry shall accept a Multi-Patient Stored Query Request formatted as a SIMPLE SOAP message and respond with a Multi-Patient Stored Query Response formatted as a SIMPLE SOAP message. The Document Consumer shall generate the Multi-Patient Stored Query Request formatted as a SIMPLE SOAP message and accept a Multi-Patient Stored Query Response formatted as a SIMPLE SOAP message.

IHE-WSP201) The attribute /wsdl:definitions/@name shall be “DocumentRegistry”.

The following WSDL naming conventions shall apply:

wsdl:definitions/@name="DocumentRegistry ":

query message -> "MultiPatientStoredQuery_Message"

query response -> "MultiPatientStoredQueryResponse_Message"

portType -> "DocumentRegistry_PortType"

operation -> "DocumentRegistry_MultiPatientStoredQuery"

SOAP 1.2 binding -> "DocumentRegistry_Binding_Soap12"

SOAP 1.2 port -> "DocumentRegistry_Port_Soap12"

IHE-WSP202) The targetNamespace of the WSDL shall be “urn:ihe:iti:xds-b:2007”

These are the requirements for the Multi-Patient Stored Query transaction presented in the order in which they would appear in the WSDL definition:

The following types shall be imported (xsd:import) in the /definitions/types section:

namespace=" urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0", schemaLocation="query.xsd"

The /definitions/message/part/@element attribute of the Multi-Patient Stored Query Request message shall be defined as “query:AdhocQueryRequest”
The /definitions/message/part/@element attribute of the Multi-Patient Stored Query Response message shall be defined as “query:AdhocQueryResponse”
The /definitions/portType/operation/input/@wsaw:Action attribute for the Multi-Patient Stored Query Request message shall be defined as “urn:ihe:iti:2009:MultiPatientStoredQuery”
The /definitions/portType/operation/output/@wsaw:Action attribute for the Multi-Patient Stored Query Response message shall be defined as “urn:ihe:iti:2009:MultiPatientStoredQueryResponse”
The /definitions/binding/operation/soap12:operation/@soapActionRequired attribute shall be defined as “false”

The following WSDL fragment shows an example of Multi-Patient Stored Query transaction definition:

<?xml version="1.0" encoding="utf-8"?>

...

<types>

<xsd:schema elementFormDefault="qualified" targetNamespace="urn:ihe:iti:xds-b:2007">

<xsd:import

namespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"

schemaLocation="schema\query.xsd"/>

...

</xsd:schema>

</types>

<documentation>Multi-Patient Stored Query</documentation>

</message>

<documentation>Multi-Patient Stored Query Response</documentation>

</message>

...

<input message="ihe:RegistryStoredQuery_Message"

wsaw:Action="urn:ihe:iti:2009:MultiPatientStoredQuery"/>

<output message="ihe:RegistryStoredQueryResponse_Message"

wsaw:Action="urn:ihe:iti:2009:MultiPatientStoredQueryResponse"/>

</operation>

...

</portType>

...

</definitions>

A full WSDL for the Document Consumer and Document Registry Actors is found in ITI TF-2: Appendix W .

3.51.4.1.2.4 Sample SOAP Messages

The samples in the following two sections show a typical SOAP request and its relative SOAP response. The sample messages also show the WS-Addressing headers <a:Action/>, <a:MessageID/>, <a:ReplyTo/>…; these WS-Addressing headers are populated according to ITI TF-2: Appendix V.3. The body of the SOAP message is omitted for brevity; in a real scenario the empty element will be populated with the appropriate metadata.

Samples presented in this section are also available online: see ITI TF-2: Appendix W .

3.51.4.1.2.4.1 Sample Multi-Patient Stored Query SOAP Request (WS-Addressing based)

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
    <s:Header>
        <a:Action s:mustUnderstand="1">urn:ihe:iti:2009:MultiPatientStoredQuery</a:Action>
        <a:MessageID>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:MessageID>
        <a:ReplyTo s:mustUnderstand="1">>
            <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
        </a:ReplyTo>
        <a:To>http://localhost/service/IHEMPQRegistry.svc</a:To>
    </s:Header>
    <s:Body>
        <query:AdhocQueryRequest
            xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
            xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
            xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">
            <query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>

            
            <rim:AdhocQuery id="urn:uuid:3d1bdb10-39a2-11de-89c2-2f44d94eaa9f">
                <rim:Slot name="$XDSDocumentEntryStatus">
                    <rim:ValueList>
                        <rim:Value>('urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved')</rim:Value>
                    </rim:ValueList>
                </rim:Slot>



                



            </rim:AdhocQuery>
        </query:AdhocQueryRequest>
    </s:Body>
</s:Envelope>

3.51.4.1.2.4.2 Sample Multi-Patient Stored Query SOAP Response (WS-Addressing based)

                <rim:ExtrinsicObject/>
                <rim:ExtrinsicObject/>
                <rim:ExtrinsicObject/>
                <rim:ExtrinsicObject/>
                <rim:ExtrinsicObject/>
                <rim:ExtrinsicObject/>
            </rim:RegistryObjectList>
        </query:AdhocQueryResponse>
    </s:Body>
</s:Envelope>

3.51.4.1.3 Expected Actions

A Document Registry that supports the PatientId Only Option shall be able to process messages that include one or more $XDSDocumentEntryPatientId values and do not include $XDSDocumentEntryClassCode, $XDSDocumentEntryEventCodeList, or $XDSDocumentEntryHealthcareFacilityTypeCode values (for the FindDocumentsForMultiplePatients query) or $XDSFolderCodeList values (for the FindFoldersForMultiplePatients query).

A Document Registry that does NOT support the PatientId Only Option may return an XDSStoredQueryParamNumber error in this case.

See Registry Stored Query [ITI-18] for additional Expected Actions – ITI TF-2: 3.18.4.1.3 .

3.51.5 Security Considerations

All of the Security Considerations found in [ITI-18] apply with the following further profiling.

It is expected that the ATNA authentication would be used to restrict access to the Multi-Patient Query [ITI-51] transaction. It is expected that few systems would be allowed to request the LeafClass return result.

3.51.5.1 Security Audit Considerations

The actors involved shall record one audit event for each patient identity that has been included in the query according to the following. It is important for security auditing that the audit message contain only one patient identity to better handle these messages in the Audit Record Repository. If the query includes no patient identities, both actors shall record a single audit event with no Patient participant.

3.51.5.1.1 Document Consumer audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110112, DCM, “Query”)
	EventActionCode	M	“E” (Execute)
	EventDateTime	U	not specialized
	EventOutcomeIndicator	U	not specialized
	EventTypeCode	M	EV(“ITI-51”,“IHE Transactions”,“Multi-Patient Stored Query”)
Source (Document Consumer) (1)
Human Requestor (0..n)
Destination (Document Registry) (1)
Audit Source (Document Consumer) (1)
Patient (0..n)
Query Parameters (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	C	If WS-Addressing based Asynchronous Web Services Exchange is being used, the content of the <wsa:ReplyTo/> element. Otherwise, not specialized.
	AlternativeUserID	M	The process ID as used within the local operating system in the local system logs.
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	M	EV(110153, DCM, "Source Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	The machine name or IP address.

Human Requestor (if known) AuditMessage/ ActiveParticipant	UserID	M	Identity of the human that initiated the transaction.
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	U	Access Control role(s) the user holds that allows this transaction.
	NetworkAccessPointTypeCode	U	not specialized
	NetworkAccessPointID	U	not specialized

Destination AuditMessage/ ActiveParticipant	UserID	M	SOAP endpoint URI.
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	M	EV(110152, DCM, "Destination Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	The machine name or IP address.

Audit Source

AuditMessage/
AuditSourceIdentification

AuditSourceID

not specialized

AuditEnterpriseSiteID

not specialized

AuditSourceTypeCode

not specialized

Patient (if known) (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (Person)
	ParticipantObjectTypeCodeRole	M	“1” (Patient)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The patient ID in HL7 CX format.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized

Query Parameters (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (system object)
	ParticipantObjectTypeCodeRole	M	“24” (query)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Stored Query”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	Stored Query ID (UUID)
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	M	the AdhocQueryRequest, base64 encoded.3
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur at least once. The first element shall contain: Type: “QueryEncoding” (literal string) Value: the character encoding, such as “UTF-8”, used to encode the ParticipantObjectQuery before base64 encoding If the homeCommunityId is known, the second element shall contain: Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal string) Value: value of the homeCommunityId

3.51.5.1.2 Document Registry audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110112, DCM, “Query”)
	EventActionCode	M	“E” (Execute)
	EventDateTime	U	not specialized
	EventOutcomeIndicator	U	not specialized
	EventTypeCode	M	EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Stored Query”)
Source (Document Consumer) (1)
Destination (Document Registry) (1)
Audit Source (Document Registry) (1)
Patient (0..n)
Query Parameters (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	C	If WS-Addressing based Asynchronous Web Services Exchange is being used, the content of the <wsa:ReplyTo/> element. Otherwise, not specialized.
	AlternativeUserID	M	The process ID as used within the local operating system in the local system logs.
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	M	EV(110153, DCM, "Source Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	The machine name or IP address.

Destination AuditMessage/ ActiveParticipant	UserID	M	SOAP endpoint URI.
	AlternativeUserID	M	The process ID as used within the local operating system in the local system logs.
	UserName	U	not specialized
	UserIsRequestor	U	not specialized
	RoleIDCode	M	EV(110152, DCM, "Destination Role ID")
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	The machine name or IP address.

Audit Source

AuditMessage/
AuditSourceIdentification

AuditSourceID

not specialized

AuditEnterpriseSiteID

not specialized

AuditSourceTypeCode

not specialized

Patient (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (Person)
	ParticipantObjectTypeCodeRole	M	“1” (Patient)
	P articipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The patient ID in HL7 CX format.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized

Query Parameters (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (system object)
	ParticipantObjectTypeCodeRole	M	“24” (query)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(“ITI-51”, “IHE Transactions”, “Multi-Patient Stored Query”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	Stored Query ID (UUID)
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	M	the AdhocQueryRequest, base64 encoded.
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur at least once. The first element shall contain: Type: “QueryEncoding” (literal string) Value: the character encoding, such as “UTF-8”, used to encode the ParticipantObjectQuery before base64 encoding If the homeCommunityId is known, the second element shall contain: Type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal string) Value: value of the homeCommunityId