IHE ITI TF Vol2

3.18 Registry Stored Query [ITI-18]

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

3.18.1 Scope

The Registry Stored Query transaction supports a variety of pre-defined queries. Examples include the following:

Query for DocumentEntry objects by patient (Id) for a time interval on creation time and/or service time, by document type(s), by practice setting(s), by author person
Query for SubmissionSets by Document Source
Query for Folders updated during a time interval
Query for all contents in a Folder or SubmissionSet
Query for SubmissionSets by time of submission

Depending on the value of the returnType parameter, all queries return:

Metadata for one or more types of registry object (see ITI TF-3: 4.1.3), or
Object references for one or more types of registry object

3.18.2 Use Case Roles

Actor: Document Consumer

Role: Requests a query by identifier (UUID), and passes parameters to the query. A parameter controlling the format of the returned data is passed; it selects either object references or full objects.

Actor: Document Registry

Role: Services the query using its stored definitions of the queries defined for XDS.

Actor: Initiating Gateway

Role: Services the stored query by initiating transactions with a selected set of Responding Gateways, Document Registries or other appropriate systems.

3.18.3 Referenced Standards

ITI TF-3:4 Metadata used in Document Sharing Profiles.

Implementors of this transaction shall comply with all requirements described in ITI TF-2: Appendix V: Web Services for IHE transactions.

ebRIM OASIS/ebXML Registry Information Model v3.0
ebRS OASIS/ebXML Registry Services Specifications v3.0

3.18.4 Messages

Figure 3.18.4-1: Interaction Diagram

3.18.4.1 Registry Stored Query

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

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

3.18.4.1.1 Trigger Events

This message is initiated when the Document Consumer wants to query/retrieve document metadata.

3.18.4.1.2 Message Semantics

The semantics of Stored Query are defined in Section 6.3 Stored Query Support of ebRS version 3.0. This transaction corresponds to Section 6.3.2 Invoking a Stored Query and 6.3.3 Response to a Stored Query Invocation. This profile does not specify how the queries come to be stored in the Registry nor how they are to be translated for other database architectures.

3.18.4.1.2.1 Version 3.0 ebXML Registry Standard

This transaction uses ebXML Registry version 3.0.

3.18.4.1.2.2 Sample Query Request

The sample query is included under Section 3.18.4.1.3 Expected Actions.

3.18.4.1.2.3 Query Request Parameters – Coding Style

Registry Stored Query supports the following parameters:

returnType – 'LeafClass' or 'ObjectRef'
Query ID – a UUID from Section 3.18.4.1.2.4
Query Parameters – as defined in the subsections under Section 3.18.4.1.2.3.7, that correspond to the Query ID

3.18.4.1.2.3.1 Parameter returnType

Registry Stored Query supports the following values for the parameter returnType:

ObjectRef – a list of object UUIDs (references)
LeafClass – list of XML elements representing the leaf class of the object returned

The 'LeafClass' returnType is meant for returning a small amount of fully specified ebXML objects (such as a list of ExtrinsicObject (XDSDocumentEntry) elements with full contents: slots, external identifiers, classifications etc.). This type of query result is self-contained, everything known about the object(s) is returned. The specific query documented in this section describes which object types will be included. ObjectRef elements are also returned. These represent objects not included in the returned object list that are referenced by objects in the returned object list. These ObjectRefs are optional by the registry standard version 3.0.

The 'ObjectRef' returnType returns references to the registry objects that match the query. This type query is recommended when the returned object list could be large. An initial query returning ObjectRefs for all objects of interest followed by secondary queries requesting full metadata (query type LeafClass) is an efficient way to query for large bodies of metadata. This strategy is particularly easy to use when querying for a single object type (XDSDocumentEntry or XDSSubmissionSet are examples) since only a single object type is involved.

An ObjectRef looks like:

<ObjectRef id="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"/>

3.18.4.1.2.3.2 Parameter Query ID

This parameter holds the UUID assigned to the query to be invoked. UUIDs are assigned by this profile (see Section 3.18.4.1.2.4) to each of the queries defined in Section 3.18.4.1.2.3.7.

3.18.4.1.2.3.3 Date/Time Coding

All Date/time values are to be inclusive for the lower bound and exclusive for the upper bound, interpreted as:

$XDSDocumentEntryCreationTimeFrom <= XDSDocumentEntry.creationTime < $XDSDocumentEntryCreationTimeTo

for example.

The 'From' time or the 'To' time may be omitted.

3.18.4.1.2.3.3.1 Comparing serviceStartTime and serviceStopTime

Special consideration is needed when processing the query parameters related to serviceStartTime and serviceStopTime since these DocumentEntry metadata attributes may not be present:

If the DocumentEntry.serviceStartTime attribute of a DocumentEntry contains no value and if the query includes a value for $XDSDocumentEntryServiceStartTimeFrom or $XDSDocumentEntryServiceStartTimeTo, those query parameters shall not be used for deciding whether this DocumentEntry matches the query.
If the DocumentEntry.serviceStopTime attribute of a DocumentEntry contains no value and if the query includes a value for $XDSDocumentEntryServiceStopTimeFrom or $XDSDocumentEntryServiceStopTimeTo, those query parameters shall not be used for deciding whether this DocumentEntry matches the query.

3.18.4.1.2.3.3.2 Handling partial dates/times

Both the query parameters and the metadata attributes themselves are in DTM format. The DTM format allows for a varying degree of specificity by allowing a particular year, month, date, hour, minute, or second to be specified (See ITI TF-3: Table 4.2.3.1.7-2: Data Types for a description of the DTM format). This introduces additional complexity when determining whether a particular metadata attribute matches the supplied query parameters.

If the query parameters and the metadata attributes are specified at the same specificity level, then comparison is simple string comparison. The following table illustrates some examples of this comparison:

From Search Parameter	Metadata Value	To Search Parameter	Metadata Matches Query?
20210101	20210527	20211231	Yes, May 27 2021 is between Jan 1 2021 and Dec 31 2021
20210527	20210527	20211231	Yes, May 27 2021 is between May 27 2021 and Dec 31 2021 (inclusive)
20210528	20210527	20211231	No, May 28 2021 is after May 27 2021
20210101	20210527	20210526	No, May 26 2021 is before May 27 2021
20210101	20210527	20210527	No, May 27 2021 is not between Jan 1 2021 and May 27 2021 (exclusive).

If the query parameters are less specific than the metadata attributes, then the from query parameter should be increased in specificity by selecting the earliest possible instant that matches that parameter, while the to query parameter should be increased in specificity by selecting the latest possible instant that matches that parameter. The following table illustrates some examples of this comparison:

From Search Parameter	Metadata Value	To Search Parameter	Metadata Matches Query?
2021	20210527	2021	Yes, May 27 2021 is between Jan 1 2021 and Dec 31 2021
2021	20210527	20210526	No, May 26 2021 is before May 27 2021
20210528	20210527	2021	No, May 28 2021 is before May 27 2021
2020	20210527	2020	No, May 27 2021 is not in the year 2020.
2020	20210527	2022	Yes, May 27 2021 is between Jan 01 2020 and Dec 31 2022

Finally, if the metadata attributes are less specific than the query parameters, then the metadata attributes should be considered to match the query parameters as if the query parameters had been reduced in specificity to the level of the metadata attributes. The following table illustrates some examples of this comparison:

From Search Parameter	Metadata Value	To Search Parameter	Metadata Matches Query?
20210701	2021	20210701	Yes, the query covers a range of time in 2021
20211231	2021	20221231	Yes, the query covers a range of time in 2021
20200101	2021	20210101	Yes, the query covers a range of time in 2021
20100101	2021	20201231	No, the query does not cover a range of time in 2021
20220101	2021	20301231	No, the query does not cover a range of time in 2021

3.18.4.1.2.3.4 Coding of Code/Code-Scheme

When specifying a coded value parameter, an abbreviated form of the HL7 V2.5 CE format shall be used. Only the first (identifier) and third (coding scheme) elements shall be specified. Both are required. The second element shall be empty. The HL7 V2.5 length limits shall not apply. The ebRIM limit on Slot Value size does apply. An example of this format is:

code^^coding-scheme

This style parameter always accepts multiple values so example codings in context look like:

<Value>('code1^^coding-scheme1')</Value>

<Value>('code1^^coding-scheme1','code2^^coding-scheme2')</Value>

within the parameter Slot.

3.18.4.1.2.3.5 Coding of Single/Multiple Values

Single values are coded as

123 - without quotes for numbers
'urn:oasis:names:tc:ebxml-regrep:StatusType:Approved' - in single quotes for strings.
'Children''s Hospital' - a single quote is inserted in a string by specifying two single quotes
202108231600 - without quotes for datetime parameters, as datetimes are to be treated as numbers in Document Sharing metadata. See DTM in ITI TF-3: Table 4.2.3.1.7-2: Data Types. Note: Because prior revisions of this specification were ambiguous about the data type of datetime parameters, some existing implementations might treat datetime parameters as strings by enclosing them in single quotes. Responders to ITI-18 transactions should accept and properly parse datetime parameters both without and with single quotes.

For parameters defined to be compatible with the SQL 'LIKE' keyword:

Underscore ('_') matches an arbitrary character
Percent ('%') matches an arbitrary string (0 or more characters)

Format for multiple values is

(value,value,value,…)

(value) if only one value is to be specified.

where each value is coded as described above for single values.

When coding multiple values there is a potential conflict between needing to code a long list of values and the length restriction imposed by Schema on the size of the value of the <Value/> element. Slot values shall never exceed the Schema-enforced limit. Therefore, the use of multiple Value elements within the Slot shall be acceptable. Splits may occur only between values, where each Value element is surrounded by parentheses. The following example shows multiple values, split across multiple Value elements:

<Slot name="$uuid">
  <ValueList>
    <Value>('urn:uuid:a96d7361-6617-488a-891c-ee3f37d1f218','urn:uuid: 5655a680-1b6a-11dd-bd0b-0800200c9a66')</Value>
    <Value>('urn:uuid:ae315e81-2056-4829-a5b4-cf9531941f96')</Value>
  </ValueList>
</Slot>

This example shall be treated as equivalent to:

<Slot name="$uuid">
  <ValueList>
    <Value>('urn:uuid:a96d7361-6617-488a-891c-ee3f37d1f218','urn:uuid: 5655a680-1b6a-11dd-bd0b-0800200c9a66','urn:uuid:ae315e81-2056-4829-a5b4-cf9531941f96')</Value>
  </ValueList>
</Slot>

Character comparisons shall be performed in accordance with the rules in ITI TF-2: Appendix F Character String Comparisons.

And/or semantics for the coding of parameters shall be available only on parameters for multi-valued metadata elements (such as $XDSDocumentEntryEventCodeList). Multi-valued parameters shall be coded in two ways with different interpretations.

A parameter specified as a Slot with multiple values shall be interpreted as disjunction (OR semantics). For example:

<rim:Slot name="$XDSDocumentEntryEventCodeList">
  <rim:ValueList>
    <rim:Value>('a')</rim:Value>
    <rim:Value>('b')</rim:Value>
  </rim:ValueList>
</rim:Slot>

shall match an XDSDocumentEntry object with an eventCodeList attribute containing either 'a' or 'b'. The following coding of the parameter shall yield the same results:

<rim:Slot name="$XDSDocumentEntryEventCodeList">
  <rim:ValueList>
    <rim:Value>('a','b')</rim:Value>
  </rim:ValueList>
</rim:Slot>

A parameter specified as multiple Slots shall be interpreted as conjunction (AND semantics). For example:

<rim:Slot name="$XDSDocumentEntryEventCodeList">
  <rim:ValueList>
    <rim:Value>('a')</rim:Value>
  </rim:ValueList>
</rim:Slot>
<rim:Slot name="$XDSDocumentEntryEventCodeList">
  <rim:ValueList>
    <rim:Value>('b')</rim:Value>
  </rim:ValueList>
</rim:Slot>

shall match an XDSDocumentEntry object with an eventCodeList attribute containing both 'a' and 'b'.

Furthermore, the following specification of the $XDSDocumentEntryEventCodeList parameter:

<rim:Slot name="$XDSDocumentEntryEventCodeList">
                    <rim:ValueList>
    <rim:Value>('a','b')</rim:Value>
  </rim:ValueList>
</rim:Slot>
<rim:Slot name="$XDSDocumentEntryEventCodeList">
  <rim:ValueList>
    <rim:Value>('c')</rim:Value>
  </rim:ValueList>
</rim:Slot>

shall be interpreted as matching a document having eventCode (a OR b) AND c.

3.18.4.1.2.3.6 Valid Document Status Values

The Registry Object status values, in ebRIM v 3.0 format, used by XDS are:

urn:oasis:names:tc:ebxml-regrep:StatusType:Approved
urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated

If the Document Registry receives in a Registry Stored Query transaction a value for the $XDSDocumentEntryStatus parameter that it does not understand then the Document Registry shall ignore the value and process the Registry Stored Query transaction as if the not understood value were not specified. This means that if the only value present is one that is not understood an error will be generated because the $XDSDocumentEntryStatus parameter is required.

3.18.4.1.2.3.6.1 Valid AdhocQueryResponse Status Values

The status attribute of AdhocQueryResponse shall contain one of the following values:

urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure

See ITI TF-3: 4.2.4 Error Reporting for the interpretation of these values.

3.18.4.1.2.3.6.2 Valid DocumentEntryType Parameter Values

The objectType attribute on an ExtrinsicObject (DocumentEntry) is used to distinguish Stable DocumentEntries from On-Demand DocumentEntries.

The following objectType values are used:

urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 – Stable
urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 – On-Demand

The valid DocumentEntryType parameter values used in the Registry Stored Query are:

urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 – requests Stable Document Entries be included in the response. This is the default value.
urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 – requests On-Demand Document Entries be included in the response. Used only by Document Consumers which support the On-Demand Documents Option.

If no value is specified for DocumentEntryType, the value requesting only Stable Document Entries shall be assumed. To get all Document Entry types, the query shall contain both of the valid values in the request.

3.18.4.1.2.3.7 Parameters for Required Queries

The sections below document the queries defined in the Registry Stored Query [ITI-18] transaction. These sections document a collection of Stored Queries. Document Registry Actors implementing this transaction shall support all queries in this collection and all parameters defined for each query. Document Consumer Actors implementing this transaction shall implement one or more of these queries as needed to support the use cases it implements.

Note that dollar sign ($) prefix on query parameters is required by ebRS 3.0.

In the query parameter tables below, each row represents a query parameter. Optional parameters which are not included in the query invocation have no effect on the query. Queries return registry objects that match all the supplied parameters. See Section 3.18.4.1.2.3.5 for information on specifying multiple values for a parameter.

3.18.4.1.2.3.7.1 FindDocuments

Find documents (XDSDocumentEntry objects) in the registry for a given patientID with a matching availabilityStatus attribute. The other parameters can be used to restrict the set of XDSDocumentEntry objects returned.

Returns: XDSDocumentEntry objects matching the query parameters

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryPatientId	XDSDocumentEntry.patientId	R	—
$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 Section 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

³ Supports AND/OR semantics as specified in Section 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)

⁵ See Section 3.18.4.1.2.3.6.2

⁶ CreationTimeFrom and CreationTimeTo are ignored when evaluating an On-Demand Document Entry's selection for inclusion in the query response.

3.18.4.1.2.3.7.2 FindSubmissionSets

Find submission sets (XDSSubmissionSet objects) in the registry for a given patientID with matching 'status' attribute. The other parameters can be used to restrict the collection of XDSSubmissionSet objects returned.

Returns: XDSSubmissionSet objects matching the query parameters

Parameter Name	Attribute	Opt	Mult
$XDSSubmissionSetPatientId	XDSSubmissionSet.patientId	R	—
$XDSSubmissionSetSourceId	XDSSubmissionSet.sourceId	O	M
$XDSSubmissionSetSubmissionTimeFrom	XDSSubmissionSet.submissionTime Lower value	O	—
$XDSSubmissionSetSubmissionTimeTo	XDSSubmissionSet.submissionTime Upper value	O	—
$XDSSubmissionSetAuthorPerson ¹	XDSSubmissionSet.authorPerson	O	—
$XDSSubmissionSetContentType ²	XDSSubmissionSet.contentTypeCode	O	M
$XDSSubmissionSetStatus	XDSSubmissionSet.availabilityStatus	R	M

¹ 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).

² Shall be coded according to specification in Section 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

3.18.4.1.2.3.7.3 FindFolders

Find folders (XDSFolder objects) in the registry for a given patientID with matching 'status' attribute. The other parameters can be used to restrict the collection of XDSFolder objects returned.

Returns: XDSFolder objects matching the query parameters

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

¹ Shall be coded according to specification in Section 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

² Supports AND/OR semantics as specified in Section 3.18.4.1.2.3.5.

3.18.4.1.2.3.7.4 GetAll

Get all registry content for a patient given the indicated status, format codes, and confidentiality codes.

Returns:

XDSSubmissionSet, XDSDocumentEntry, and XDSFolder objects with patientId attribute matching $patientId parameter
Association objects with sourceObject or targetObject attribute matching one of the above objects

Note: Associations may be returned that reference objects not in the return set. For example, this could occur when:

the $XDSDocumentEntryStatus parameter is Approved and a submitted DocumentEntry has been replaced and is, therefore, Deprecated, or
a SubmissionSet is linked to a DocumentEntry with a different Patient ID, i.e., for a mother and child.

Document Consumers should be prepared to handle these situations.

Parameter Name	Attribute	Opt	Mult
$patientId	XDSFolder.patientId, XDSSubmissionSet.patientId, XDSDocumentEntry.patientId	R	—
$XDSDocumentEntryStatus	XDSDocumentEntry.availabilityStatus	R	M
$XDSSubmissionSetStatus	XDSSubmissionSet.availabilityStatus	R	M
$XDSFolderStatus	XDSFolder.availabilityStatus	R	M
$XDSDocumentEntryFormatCode ²	XDSDocumentEntry.formatCode	O	M
$XDSDocumentEntryConfidentialityCode ^1,2	XDSDocumentEntry.confidentialityCode ¹	O	M
$XDSDocumentEntryType ³	XDSDocumentEntry.objectType	O	M

¹ Supports AND/OR semantics as specified in Section 3.18.4.1.2.3.5.

² Shall be coded according to specification in Section 3.18.4.1.2.3.4 Coding of Code/Code-Scheme

³ See Section 3.18.4.1.2.3.6.2

3.18.4.1.2.3.7.5 GetDocuments

Retrieve a collection of XDSDocumentEntry objects. XDSDocumentEntry objects are selected either by their entryUUID or uniqueId attribute.

Returns: XDSDocumentEntry objects requested

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryEntryUUID ³	XDSDocumentEntry.entryUUID	O¹	M
$XDSDocumentEntryUniqueId ³	XDSDocumentEntry.uniqueId	O ¹	M
$homeCommunityId	None	O ²	—

¹ Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified. This transaction shall return an XDSStoredQueryParamNumber error if both parameters are specified.

² The homeCommunityId value is specified as the home attribute on the AdhocQuery element of the query request, as in: <AdhocQuery id="…" home="urn:oid:1.2.3" … >. Document Consumer Actors shall specify the homeCommunityId value if they received a value for this attribute as part of the previous Registry Stored Query response entry which contained the specified EntryUUID or UniqueID. See Section 3.18.4.1.2.3.8 for more details.

Note: A query for a single XDSDocumentEntry.uniqueId can return multiple results. See ITI TF-3: 4.1.4 under the topic of Document metadata duplication for explanation.

³ If the Stored Query specifies a returnType of LeafClass then the Document Registry shall verify that all requested DocumentEntry objects to be returned will contain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata shall be returned.

3.18.4.1.2.3.7.6 GetFolders

Retrieve a collection of XDSFolder objects. XDSFolder objects are selected either by their entryUUID or uniqueId attribute.

Returns: XDSFolder objects requested.

Parameter Name	Attribute	Opt	Mult
$XDSFolderEntryUUID ³	XDSFolder.entryUUID	O ¹	M
$XDSFolderUniqueId ³	XDSFolder.uniqueId	O ¹	M
$homeCommunityId	None	O ²	—

¹ Either $XDSFolderEntryUUID or $XDSFolderUniqueId shall be specified. This transaction shall return an XDSStoredQueryParamNumber error if both parameters are specified.

³ If the Stored Query specifies a returnType of LeafClass then the Document Registry shall verify that all requested Folder objects to be returned will contain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata shall be returned.

3.18.4.1.2.3.7.7 GetAssociations

Retrieve Association objects whose sourceObject or targetObject attribute match $uuid.

Returns: Association objects

Parameter Name	Attribute	Opt	Mult
$uuid	None	R	M
$homeCommunityId	None	O ¹	-

¹ The homeCommunityId value is specified as the home attribute on the AdhocQuery element of the query request, as in: <AdhocQuery id="…" home="urn:oid:1.2.3" … >. Document Consumer Actors shall specify the homeCommunityId value if they received a value for this attribute as part of the previous Registry Stored Query response entry which contained the specified EntryUUID or UniqueID. See Section 3.18.4.1.2.3.8 for more details.

3.18.4.1.2.3.7.8 GetDocumentsAndAssociations

Retrieve a collection of XDSDocumentEntry objects and the Association objects surrounding them. XDSDocumentEntry objects are selected either by their entryUUID or uniqueId attribute. This is the GetDocuments query and GetAssociations query combined into a single query.

Returns:

XDSDocumentEntry objects
Association objects whose sourceObject or targetObject attribute matches one of the above objects

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryEntryUUID ³	XDSDocumentEntry.entryUUID	O ¹	M
$XDSDocumentEntryUniqueId ³	XDSDocumentEntry.uniqueId	O ¹	M
$homeCommunityId	None	O ²	—

¹ Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified. This transaction shall return an XDSStoredQueryParamNumber error if both parameters are specified.

3.18.4.1.2.3.7.9 GetSubmissionSets

Retrieve the XDSSubmissionSet objects used to submit a collection of XDSDocumentEntry and XDSFolder objects. The XDSDocumentEntry and XDSFolder objects of interest are identified by their UUIDs in the $uuid parameter.

Selection: XDSSubmissionSet objects are selected because Association objects exist that have:

Type HasMember
targetObject attribute containing one of the UUIDs provided in the $uuid parameter
sourceObject attribute referencing an XDSSubmissionSet object

Returns:

XDSSubmissionSet objects described above
Association objects described in the Selection section above

Parameter Name	Attribute	Opt	Mult
$uuid ²	XDSDocumentEntry.entryUUID and XDSFolder.entryUUID	R	M
$homeCommunityId	None	O ¹	—

Parameter Name

Attribute

Opt

Mult

$uuid ²

XDSDocumentEntry.entryUUID and

XDSFolder.entryUUID

$homeCommunityId

None

O ¹

—

² If the Stored Query specifies a returnType of LeafClass then the Document Registry shall verify that all requested Submission Set objects to be returned will contain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata shall be returned.

3.18.4.1.2.3.7.10 GetSubmissionSetAndContents

Retrieve a SubmissionSet and its contents. SubmissionSet objects is selected either by its entryUUID or uniqueId attribute. The DocumentEntry objects returned may be constrained by their formatCode and confidentialityCode attributes. More specifically, the DocumentEntries returned shall be limited by the following rules:

If the $XDSDocumentEntryConfidentialityCode parameter is present in the query, then DocumentEntries shall be returned only if they match this parameter.
If the $XDSDocumentEntryFormatCode parameter is present in the query, then DocumentEntries shall be returned only if they match this parameter

Returns:

SubmissionSet identified
DocumentEntries linked to the SubmissionSet by HasMember Associations (DocumentEntries shall pass the above rules)
The HasMember Associations identified in the previous rule
Folders linked to the SubmissionSet by HasMember Associations
The HasMember Associations identified in the previous rule
Associations linked to the SubmissionSet by HasMember Associations where the Associations link two objects already in the return set
The HasMember Associations identified in the previous rule

In the above rules, Associations are only returned if both of the objects they connect are part of the return set.

Parameter Name	Attribute	Opt	Mult
$XDSSubmissionSetEntryUUID ⁵	XDSSubmissionSet.entryUUID	O ¹	—
$XDSSubmissionSetUniqueId ⁵	XDSSubmissionSet.uniqueId	O ¹	—
$XDSDocumentEntryFormatCode ⁴	XDSDocumentEntry.formatCode	O	M
$XDSDocumentEntryConfidentialityCode ⁴	XDSDocumentEntry.confidentialityCode ²	O	M
$homeCommunityId	None	O ³	—
$XDSDocumentEntryType ⁶	XDSDocumentEntry.objectType	O	M

¹ Either $XDSSubmissionSetEntryUUID or $XDSSubmissionSetUniqueId shall be specified. This transaction shall return an XDSStoredQueryParamNumber error if both parameters are specified.

² Supports AND/OR semantics as specified in Section 3.18.4.1.2.3.5.

³ The homeCommunityId value is specified as the home attribute on the AdhocQuery element of the query request, as in: <AdhocQuery id="…" home="urn:oid:1.2.3" … >. Document Consumer Actors shall specify the homeCommunityId value if they received a value for this attribute as part of the previous Registry Stored Query response entry which contained the specified EntryUUID or UniqueID. See Section 3.18.4.1.2.3.8 for more details.

⁴ Shall be coded according to specification in Section 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

⁵ If the Stored Query specifies a returnType of LeafClass then the Document Registry shall verify that all requested Submission Set, Folder, and DocumentEntry objects to be returned will contain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata shall be returned.

⁶ See Section 3.18.4.1.2.3.6.2

3.18.4.1.2.3.7.11 GetFolderAndContents

Retrieve a Folder and its contents. The Folder object is selected either by its entryUUID or uniqueId attribute. The DocumentEntry objects returned may be constrained by their formatCode and confidentialityCode attributes. More specifically, the DocumentEntries shall be limited by the following rules:

If the $XDSDocumentEntryConfidentialityCode parameter is present in the query, then DocumentEntries shall be returned only if they match this parameter.
If the $XDSDocumentEntryFormatCode parameter is present in the query, then DocumentEntries shall be returned only if they match this parameter

Returns:

Folder identified
DocumentEntries linked to the Folder by HasMember Associations (DocumentEntries shall pass the above rules)
The HasMember Associations identified in the previous rule

In the above rules, Associations are only returned if both of the objects they connect are part of the return set.

Parameter Name	Attribute	Opt	Mult
$XDSFolderEntryUUID ⁵	XDSFolder.entryUUID	O ¹	—
$XDSFolderUniqueId ⁵	XDSFolder.uniqueId	O ¹	—
$XDSDocumentEntryFormatCode ⁴	XDSDocumentEntry.formatCode	O	M
$XDSDocumentEntryConfidentialityCode ⁴	XDSDocumentEntry.confidentialityCode ²	O	M
$homeCommunityId	None	O ³	—
$XDSDocumentEntryType ⁶	XDSDocumentEntry.objectType	O	M

¹ Either $XDSFolderEntryUUID or $XDSFolderUniqueId shall be specified. This transaction shall return an XDSStoredQueryParamNumber error if both parameters are specified.

² Supports AND/OR semantics as specified in Section 3.18.4.1.2.3.5.

⁴ Shall be coded according to specification in Section 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

⁵ If the Stored Query specifies a returnType of LeafClass then the Document Registry shall verify that all requested Folder, and DocumentEntry objects to be returned will contain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata shall be returned.

⁶ See Section 3.18.4.1.2.3.6.2

3.18.4.1.2.3.7.12 GetFoldersForDocument

Retrieve XDSFolder objects that contain the XDSDocumentEntry object provided with the query. XDSDocumentEntry objects are selected either by their entryUUID or uniqueId attribute.

Returns: XDSFolder objects that contain specified XDSDocumentEntry object. More specifically, for each Association object of type HasMember that has a targetObject attribute referencing the target XDSDocumentEntry object, return the object referenced by its sourceObject if it is of type XDSFolder.

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryEntryUUID	XDSDocumentEntry.entryUUID	O ¹	—
$XDSDocumentEntryUniqueId	XDSDocumentEntry.uniqueId	O ¹	—
$homeCommunityId	None	O ²	—

¹ Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified. This transaction shall return an XDSStoredQueryParamNumber error if both parameters are specified.

Note: A query for a single XDSDocumentEntry.uniqueId can return multiple results. See ITI TF-3: 4.1.4 under the topic of Document Metadata Duplication for explanation.

3.18.4.1.2.3.7.13 GetRelatedDocuments

Retrieve XDSDocumentEntry objects that are related to the specified document via Association objects. Also return the Association objects. The specified document is designated by UUID or uniqueId. The query shall return

Association objects where:

The sourceObject attribute OR the targetObject attribute references the specified document AND
Both sourceObject attribute and targetObject attribute reference documents AND
The associationType attribute matches a value included in the $AssociationTypes parameter

XDSDocumentEntry objects referenced by the targetObject attribute OR the sourceObject attribute of an Association object matched above.

Note: A side effect of the query is that the specified document is returned in the results if at least one Association is returned.

Note: A side effect of this query is that if the document specified by the $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId parameters has no associations linking it to other documents, then no documents and no associations are returned.

See ITI TF-3: 4.1.6 Document Relationships and Associations for background.

Returns: Association objects and related XDSDocumentEntry objects

Given: An XDSDocumentEntry object and a collection of association types.

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryEntryUUID	XDSDocumentEntry.entryUUID	O ¹	—
$XDSDocumentEntryUniqueId	XDSDocumentEntry.uniqueId	O ¹	—
$AssociationTypes	Not a named attribute	R	M
$homeCommunityId	None	O ²	—
$XDSDocumentEntryType ³	XDSDocumentEntry.objectType	O	M

¹ Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified. This transaction shall return an XDSStoredQueryParamNumber error if both parameters are specified.

³ See Section 3.18.4.1.2.3.6.2

Note: A query for a single XDSDocumentEntry.uniqueId can return multiple results. See ITI TF-3: 4.1.4 under the topic of Document Metadata Duplication for explanation.

3.18.4.1.2.3.7.14 FindDocumentsByReferenceId

This query shall be supported by Registries claiming the "Reference ID" Option. Find documents (XDSDocumentEntry objects) in the registry for a given patientID with a matching 'status' attribute. The other parameters can be used to restrict the set of XDSDocumentEntry objects returned.

This query is semantically identical to the FindDocuments Stored Query (see Section 3.18.4.1.2.3.7.1) except:

$XDSDocumentEntryReferenceIdList contains one or more values to match against the referenceIdList document entry. Since referencedIdList is a rim:Slot, entries in the referencedIdList are matched as exact matches against the query parameter values.

Returns: XDSDocumentEntry objects matching the query parameters

Parameter Name	Attribute	Opt	Mult
$XDSDocumentEntryPatientId	XDSDocumentEntry.patientId	R	—
$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 Section 3.18.4.1.2.3.4 Coding of Code/Code-Scheme.

³ Supports AND/OR semantics as specified in Section 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.

⁶ See Section 3.18.4.1.2.3.6.2.

3.18.4.1.2.3.8 Use of homeCommunityId

The Registry Stored Query makes use of the homeCommunityId which is a globally unique identifier for a community and is used to obtain the Web Services endpoint of services that provide access to data in that community. The homeCommunityId is structured as an OID limited to 64 characters and is specified in URI syntax; for example, the homeCommunityId of 1.2.3 would be formatted as urn:oid:1.2.3.

Its use is as follows:

It is returned within the response to Registry Stored Query and Cross Gateway Query transactions to indicate the association of a response element with a community. It is specified as the ebRIM 'home' attribute within the ExtrinsicObject, RegistryPackage and ObjectRef elements. Document Consumers process the value as an opaque unique identifier.
It is an optional parameter to Registry Stored Query requests, not requiring a patient id parameter, and Retrieve Document Set requests to indicate which community to direct the request.

For stored queries which do not require the patient id as a parameter, meaning query by EntryUUID or UniqueID:

If the Registry Stored Query is being addressed to an Initiating Gateway then the Document Consumer may have previously sent a Registry Stored Query to the Initiating Gateway which included a patient id and saved the homeCommunityId which was returned on the element containing the EntryUUID or uniqueID. If this is not the case the Document Consumer shall have access to the correct homeCommunityId through some other means.
If the Document Consumer received the EntryUUID or uniqueID in a previous Registry Stored Query response which contained a homeCommunityId, then the Document Consumer shall specify the homeCommunityId parameter.
The homeCommunityId value is specified as the home attribute on the AdhocQuery element of the query request, as in:
<AdhocQuery id="…" home="urn:oid:1.2.3" … >
Each query request can have at most one homeCommunityId value. If the Document Consumer specifies multiple entryUUID or uniqueID values they must all be associated with the same homeCommunityId value. Multiple individual query requests can be used to retrieve data associated with different homeCommunityIds.

3.18.4.1.2.3.9 Merge Patient ID

Patient identifiers can be merged via messages received through the Patient Identity Feed [ITI-8] or the Patient Identity Feed v3 [ITI-44] transaction. See Section 3.8.4.2 and ITI TF-2: 3.44.4.2.4 for details.

This section defines the effects that merged patient identifiers have on the Registry Stored Query transaction. The process of merging patient identifiers involves two patient identifiers: the subsumed patient identifier and the surviving patient identifier. The subsumed patient identifier stops being used and all patient records that were associated with that identifier are now associated with the surviving patient identifier. See Section 3.8.4.2.4 for how these identifiers map into the Merge Patient Identifier message.

Several transactions handle processing of merged patient identifiers, e.g.:

Patient Identity Feed [ITI-8] and Patient Identity Feed v3 [ITI-44] – accept the merge request
Register Document Set-b [ITI-42] – accepts metadata containing patient identifiers
Registry Stored Query [ITI-18] – retrieves metadata containing patient identifiers.

The above transactions and the profiles that use them do not specify how patient identifier merging is to be implemented. They do specify the results of the merge in terms of possible rejection of Register Document Set-b transactions and results returned in Registry Stored Query transactions.

The following two sections document the responsibilities of the Document Registry and the Document Consumer in processing Registry Stored Query transactions that reference patient identifiers that are involved in merges.

3.18.4.1.2.3.9.1 Responsibilities of the Document Registry Actor

The rules governing the handling of patient identity merges depend on the following factors:

Does the stored query contain patient identifier parameters?
Has the registry received a patient identity merge message which references the patient identity parameter as either the subsumed patient identifier or the surviving patient identifier?
The content of any previously received merge message can contribute to the result of a stored query.
More than one merge message may contribute to the results of a stored query (e.g., Patient ID A merged into Patient ID B merged into Patient ID C etc.)

The following assertions shall be met by a Document Registry when returning metadata in a Registry Stored Query transaction. The terms 'subsumed patient identifier' and 'surviving patient identifier' refer to the contents of any previously received merge message.

If the query includes a patient identifier parameter and that patient identity matches the subsumed patient identifier of a merge message then the query shall return no results or an XDSUnknownPatientId error, depending on XDS Affinity Domain policy.
If the query includes a patient identifier and that patient identifier matches the surviving patient identifier of a previous merge message then the query shall return the composite of:
Metadata registered against the surviving patient identifier
Metadata registered against the subsumed patient identifier
Metadata returned shall show the surviving patient identifier in these metadata attributes:

XDSSubmissionSet.patientId
XDSDocumentEntry.patientId
XDSFolder.patientId

Patient identifiers may be affected by multiple patient identity merges.
The subsumed patient identifier may have been referenced in a prior A40 Merge message as the surviving patient identifier.
The surviving patient identifier may have been referenced in a prior A40 Merge message as the surviving patient identifier.
Patient demographics in XDSDocumentEntry.sourcePatientInfo shall not be altered as a result of an A40 Merge.

3.18.4.1.2.3.9.2 Responsibilities of the Document Consumer Actor

The following assertions affect the Document Consumer:

The Document Consumer shall depend on the patient identity in the following metadata attributes after a patient identifier is merged:

XDSSubmissionSet.patientId
XDSDocumentEntry.patientId
XDSFolder.patientId

The Document Registry is required to return the surviving patient identifier of a merge in place of the original subsumed patient identifier.

The Document Consumer shall not depend on the patient demographics found in XDSDocumentEntry.sourcePatientInfo after a patient identifier is merged. Patient demographics should be accessed through PIX/PDQ services or their equivalent.

3.18.4.1.2.4 Stored Query IDs

The standard XDS queries are assigned the following Query IDs. These IDs are used in the AdhocQueryRequest to reference queries stored on the Document Registry Actor. Query IDs are in UUID format (RFC4122). An error shall be returned when an unsupported stored query ID is received.

Note: This query mechanism can be extended by adding a query by allocating a Query ID, defining query parameters, and implementing the query in the Document Registry.

Query Name	Query ID
FindDocuments	`urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d`
FindSubmissionSets	`urn:uuid:f26abbcb-ac74-4422-8a30-edb644bbc1a9`
FindFolders	`urn:uuid:958f3006-baad-4929-a4de-ff1114824431`
GetAll	`urn:uuid:10b545ea-725c-446d-9b95-8aeb444eddf3`
GetDocuments	`urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4`
GetFolders	`urn:uuid:5737b14c-8a1a-4539-b659-e03a34a5e1e4`
GetAssociations	`urn:uuid:a7ae438b-4bc2-4642-93e9-be891f7bb155`
GetDocumentsAndAssociations	`urn:uuid:bab9529a-4a10-40b3-a01f-f68a615d247a`
GetSubmissionSets	`urn:uuid:51224314-5390-4169-9b91-b1980040715a`
GetSubmissionSetAndContents	`urn:uuid:e8e3cb2c-e39c-46b9-99e4-c12f57260b83`
GetFolderAndContents	`urn:uuid:b909a503-523d-4517-8acf-8e5834dfc4c7`
GetFoldersForDocument	`urn:uuid:10cae35a-c7f9-4cf5-b61e-fc3278ffb578`
GetRelatedDocuments	`urn:uuid:d90e5407-b356-4d91-a89f-873917b4b0e6`
FindDocumentsByReferenceId	`urn:uuid:12941a89-e02e-4be5-967c-ce4bfc8fe492`

3.18.4.1.2.5 Compatibility of Options

The presence or absence of the optional $XDSDocumentEntryType parameter triggers different behaviors on the Document Registry. If this parameter is specified, and the Document Registry does not support it, the Document Registry shall ignore. If it is specified, and the Document Registry does support it, the proper information is returned.

If the Document Consumer does not support the On-Demand Documents Option, it will send a Registry Stored Query request which does not contain the $XDSDocumentEntryType parameter. The Document Registry will therefore not supply any On-Demand Document Entries in the query response.
If the Document Consume does support the On-Demand Documents Option<, then it will be able to specify the $XDSDocumentEntryType parameter containing the uuid for On-Demand Document Entries in a Registry Stored Query. A Document Registry with the On-Demand Documents Option will recognize the $XDSDocumentEntryType parameter and process accordingly. A Document Registry which does not support the On-Demand Documents Option will ignore the $XDSDocumentEntryType parameter. Since there cannot be any On-Demand Document Entries held by a Document Registry which does not support On-Demand Documents, this is a consistent response to the request.

3.18.4.1.2.6 Managing Large Query Responses

ebXML version 3.0 supports query results pagination (ebRS version 3.0 chapter 6.2). The interactions between the stored query capability and the query results pagination capability within the standard have never been reconciled and are not recommended for use together. It is recommended instead that query pagination be implemented within the Document Consumer Actor.

This can be accomplished by specifying returnType="ObjectRef" on all large queries. This returns a list of references (UUIDs) instead of full objects (large XML structures). This is practical for queries returning thousands of objects. To construct a page for display, a small number of objects can be retrieved through a second query. This is repeated for each page. As an example, the following sequence of queries could be used to list a large number of documents:

FindDocuments query with returnType="ObjectRef" which returns a large collections of ObjectRefs (UUIDs)
GetDocuments query with returnType="LeafClass" issued with a subset of the above returned UUIDs which returns the details to construct one page of listing

GetDocumentsAndAssociations query with returnType="LeafClass" issued with a subset of the above returned UUIDs which returns the details to construct one page of listing. By retrieving the Association objects, the existence of document replacement, transformation, and amendment can be included into the display.

3.18.4.1.2.7 Web Services Transport

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

The Document Registry shall accept a Registry Stored Query Request formatted as a SIMPLE SOAP message and respond with a Registry Stored Query Response formatted as a SIMPLE SOAP message. The Document Consumer shall generate the Registry Stored Query Request formatted as a SIMPLE SOAP message and accept a Registry 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    -> "RegistryStoredQuery_Message"
query response   -> "RegistryStoredQueryResponse_Message"
portType         -> "DocumentRegistry_PortType"
operation        -> "RegistryStoredQuery"
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"

Document Registry: These are the requirements for the Registry Stored Query transaction presented in the order in which they would appear in the Document Registry 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 Registry Stored Query Request message shall be defined as "query:AdhocQueryRequest"
The /definitions/message/part/@element attribute of the Registry Stored Query Response message shall be defined as "query:AdhocQueryResponse"
Refer to Table 3.18.4.1.2.7-1 below for additional attribute requirements
To support the Asynchronous Web Services Exchange Option on the Document Consumer, the Document Registry shall support the use of a non-anonymous response EPR in the WS-Addressing replyTo header.

Table 3.18.4.1.2.7-1: Additional Attribute Requirements

Attribute	Value
/definitions/portType/operation@name	DocumentRegistry_RegistryStoredQuery
/definitions/portType/operation/input/@wsaw:Action	`urn:ihe:iti:2007:RegistryStoredQuery`
/definitions/portType/operation/output/@wsaw:Action	`urn:ihe:iti:2007:RegistryStoredQueryResponse`
/definitions/binding/operation/wsoap12:operation/@soapActionRequired	false

The following WSDL fragment shows an example of Registry Stored Query transaction definition:

<?xml version="1.0" encoding="utf-8"?>
<definitions …>
  …
  <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>
  <message name="RegistryStoredQuery_Message">
    <documentation>Registry Stored Query</documentation>
    <part name="body" element="query:AdhocQueryRequest"/>
  </message>
  <message name="RegistryStoredQueryResponse_Message">
    <documentation>Registry Stored Query Response</documentation>
    <part name="body" element="query:AdhocQueryResponse"/>
  </message>
  …
  <portType name="DocumentRegistry_PortType">
    <operation name="DocumentRegistry_RegistryStoredQuery">
      <input message="ihe:RegistryStoredQuery_Message" wsaw:Action="urn:ihe:iti:2007:RegistryStoredQuery"/>
      <output message="ihe:RegistryStoredQueryResponse_Message" wsaw:Action="urn:ihe:iti:2007:RegistryStoredQueryResponse"/>
    </operation>
    …
  </portType>
  …
</definitions>

A full WSDL for the Document Repository and Document Registry Actors is found online: see ITI TF-2: Appendix W.

3.18.4.1.2.7.1 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: Web Services for IHE transactions. 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.18.4.1.2.7.1.1 Sample Registry Stored Query SOAP Request

3.18.4.1.2.7.1.1.1 Synchronous Web Services Exchange

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegistryStoredQuery</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/IHEXDSRegistry.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:14d4debf-8f97-4251-9a74-a90016b0af0d">
        <rim:Slot name="$XDSDocumentEntryPatientId">
          <rim:ValueList>
            <rim:Value>'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryStatus">
          <rim:ValueList>
            <rim:Value>('urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved')</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryCreationTimeFrom">
          <rim:ValueList>
            <rim:Value>200412252300</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryCreationTimeTo">
          <rim:ValueList>
            <rim:Value>200501010800</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode">
          <rim:ValueList>
            <rim:Value>('35971002^^2.16.840.1.113883.6.96')</rim:Value>
          </rim:ValueList>
        </rim:Slot>
      </rim:AdhocQuery>
    </query:AdhocQueryRequest>
  </s:Body>
</s:Envelope>

3.18.4.1.2.7.1.1.2 Asynchronous Web Services Exchange

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegistryStoredQuery</a:Action>
    <a:MessageID>urn:uuid:a02ca8cd-86fa-4afc-a27c-616c183b2055</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://192.168.2.4:9080/XDS/DocumentConsumerReceiver.svc</a:Address>
    </a:ReplyTo>
    <a:To s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentRegistryReceiver.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:14d4debf-8f97-4251-9a74-a90016b0af0d ">
        <rim:Slot name="$XDSDocumentEntryPatientId">
          <rim:ValueList>
            <rim:Value>st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryStatus">
          <rim:ValueList>
            <rim:Value>('urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved')</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryCreationTimeFrom">
          <rim:ValueList>
            <rim:Value>200412252300</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryCreationTimeTo">
          <rim:ValueList>
            <rim:Value>200501010800</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode">
          <rim:ValueList>
            <rim:Value>('Emergency Department')</rim:Value>
          </rim:ValueList>
        </rim:Slot>
      </rim:AdhocQuery>
    </query:AdhocQueryRequest>
  </s:Body>
</s:Envelope>

3.18.4.1.2.7.1.2 Sample Registry Stored Query SOAP Response

3.18.4.1.2.7.1.2.1 Synchronous Web Services Exchange

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegistryStoredQueryResponse</a:Action>
    <a:RelatesTo>urn:uuid:def119ad-dc13-49c1-a3c7-e3742531f9b3</a:RelatesTo>
  </s:Header>
  <s:Body>
    <query:AdhocQueryResponse xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"/>
  </s:Body>
</s:Envelope>

3.18.4.1.2.7.1.2.2 Asynchronous Web Services Exchange

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">urn:ihe:iti:2007:RegistryStoredQueryResponse</a:Action>
    <a:MessageID>urn:uuid:D6C21225-8E7B-454E-9750-821622C099DB</a:MessageID>
    <a:RelatesTo>urn:uuid:a02ca8cd-86fa-4afc-a27c-616c183b2055</a:RelatesTo>
    <a:To s:mustUnderstand="1">http://localhost:2647/XdsService/DocumentConsumerReceiver.svc</a:To>
  </s:Header>
  <s:Body>
    <query:AdhocQueryResponse status="Success" xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
    <!-- Rest of AdhocQueryResponse message goes here -->
    </query:AdhocQueryResponse>
  </s:Body>
</s:Envelope>

3.18.4.1.3 Expected Actions

The Document Registry shall:

Accept a parameterized query in an AdhocQueryRequest message
Verify the required parameters are included in the request. Additionally, special rules documented in the above section 'Parameters for Required Queries' shall be verified.
Errors shall be returned for the following conditions:

Unknown query ID (error code XDSUnknownStoredQuery)
Required parameter missing (error code XDSStoredQueryMissingParam)

See ITI TF-3: 4.2.4 Error Reporting for additional error codes and general information on formatting error responses.

Process the query as appropriate:

For Document Registry Actors: Retrieve the internal implementation template of the query based on the Query ID supplied in the query request. Substitute appropriate parameters as indicated in Section 3.18.4.1.2.3.7 Parameters for Required Queries and execute the query. The Document Registry shall accept the homeCommunityId value if it is specified in a Registry Stored Query request. If a patient identifier specified as a parameter to the query is unknown to the Document Registry it shall return a successful response with no elements, or an XDSUnknownPatientId error, depending on XDS Affinity Domain policy.
For Initiating Gateway Actors:

Initiating Gateway receives a Registry Stored Query by patient id: It shall determine a) which Responding Gateways this request should be sent to and b) what patient id to use in the Cross Gateway Query. Detailed specification of these steps is not in the intended scope of this profile. Combination of this profile with other existing profiles (e.g., PIX/PDQ), future profiles or configuration mechanisms is possible. Please refer to ITI TF-1: E.7 XCA and Patient Identification Management for possible use of existing profiles PIX and PDQ. For each Responding Gateway identified, the Initiating Gateway shall update the query with the correct patient identifier corresponding to the Responding Gateway's community and initiates a Cross Gateway Query transaction to the Responding Gateway. If the Initiating Gateway is grouped with a Document Consumer it will also initiate a Registry Stored Query to the local Document Registry.
Initiating Gateway receives a Registry Stored Query by entryUUID or uniqueID: Verify homeCommunityId has been specified. If missing return Failure status with XDSMissingHomeCommunityId error code. If homeCommunityId not recognized return a Failure or PartialSuccess status with XDSUnknownCommunity error code. Determine which Responding Gateway to contact by using the homeCommunityId to obtain the Web Services endpoint of the Responding Gateway. The process of obtaining the Web Services endpoint is not further specified in this profile. If the homeCommunityId represents the local community the Initiating Gateway shall initiate a Registry Stored Query to the local Document Registry. The Initiating Gateway shall specify the homeCommunityId in the Cross Gateway Query by entryUUID or uniqueID which identifies the community associated with the Responding Gateway. For details regarding the homeCommunityId see Section 3.18.4.1.2.3.8 and ITI TF-2: 3.38.4.1.2.1.

Return XML formatted metadata in an AdhocQueryResponse message.

The Document Registry may specify the homeCommunityID attribute on any appropriate elements
The Initiating Gateway shall specify the homeCommunityID attribute on all appropriate elements. If the Initiating Gateway contacted a Document Registry, the Document Registry response might not contain the homeCommunityId. In this case the Initiating Gateway shall add the homeCommunityId of its local community to the Document Registry response prior to including it in the consolidated response to the Document Consumer. The homeCommunityId attribute corresponds to the 'home' attribute specified in the ebRIM standard. For more information on homeCommunityId see Section 3.18.4.1.2.3.8 and ITI TF-2: 3.38.4.1.2.1. The elements that shall include the home attribute are:
If returntype="LeafClass" the ExtrinsicObject and RegistryPackage elements shall contain the home attribute.
If returnType="ObjectRef" the ObjectRef element shall contain the home attribute
If the Initiating Gateway is unable to get an appropriate response from a selected Responding Gateway it shall include in its response to the Document Consumer an XDSUnavailableCommunity error code where the context identifies the unavailable Responding Gateway. In this case, and any other error from a Responding Gateway, the Initiating Gateway shall return to the Document Consumer either a Failure status (if no part was successful) or a PartialSuccess status.

When the Document Consumer receives the query response from the Initiating Gateway it must account for two aspects of the response; namely that a) the homeCommunityId attribute will be specified b) the Document Consumer may not be able to map the repository id value directly to the Document Repository. XCA assumes a common coding/vocabulary scheme is used across all communities. For example, all communities shall have common privacy consent vocabularies. The Document Consumer shall retain the values of the homeCommunityId attribute for future interaction with the Initiating Gateway.

This transaction may return both errors and results in an AdhocQueryResponse message. To do this, the returned AdhocQueryResponse message would contain both a RegistryObjectList element and a RegistryErrorList element. See ITI TF-3: 4.2.4 Error Reporting for additional details on formatting of error responses.

If the Document Consumer supports the Delayed Document Assembly Option it shall accept the following values of hash and size to indicate that the assembly of the document content has been delayed until the document is retrieved.

size = 0 (zero)
hash = da39a3ee5e6b4b0d3255bfef95601890afd80709 (SHA1 hash of a zero length file)

3.18.4.1.3.1 Sample Query Request

This example query specifies:

The FindDocuments query (id attribute of AdhocQuery element)
patientID st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO
Return Approved documents only
Time range (creation time) 200412252300 to 200501010800
Healthcare Facility Type Code of Emergency Department

Note that ebRS 3.0 specifies the use of Slot to specify name/value(s) pairs as parameters to a Stored Query.

<query:AdhocQueryRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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:14d4debf-8f97-4251-9a74-a90016b0af0d">
    <rim:Slot name="$XDSDocumentEntryPatientId">
      <rim:ValueList>
        <rim:Value>'st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value>
      </rim:ValueList>
    </rim:Slot>
    <rim:Slot name="$XDSDocumentEntryStatus"
      <rim:ValueList>
        <rim:Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</rim:Value>
      </rim:ValueList>
    </rim:Slot>
    <rim:Slot name="$XDSDocumentEntryCreationTimeFrom">
      <rim:ValueList>
        <rim:Value>200412252300</rim:Value>
      </rim:ValueList>
    </rim:Slot>
    <rim:Slot name="$XDSDocumentEntryCreationTimeTo">
      <rim:ValueList>
        <rim:Value>200501010800</rim:Value>
      </rim:ValueList>
    </rim:Slot>
    <rim:Slot name="$XDSDocumentEntryHealthcareFacilityTypeCode">
      <rim:ValueList>
        <rim:Value>('Emergency Department')</rim:Value>
      </rim:ValueList>
    </rim:Slot>
  </rim:AdhocQuery>
</query:AdhocQueryRequest>

The following example shows a get documents query for XDSDocumentEntry objects for a specified list of entryUUIDs (urn:uuid:aff99222-18e3-4812-bc71-c410b2860e18, urn:uuid:aff99222-18e3-4812-bc71-c410b2860e19, urn:uuid:aff99222-18e3-4812-bc71-c410b2860e20) and corresponding homeCommunityId value (urn:oid:1.2.3):

<query:AdhocQueryRequest … >
  <query:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
  <rim:AdhocQuery id="urn:uuid:5c4f972b-d56b-40ac-a5fc-c8ca9b40b9d4" home="urn:oid:1.2.3">
    <rim:Slot name="$XDSDocumentEntryEntryUUID">
      <rim:ValueList>
        <rim:Value>("urn:uuid:aff99222-18e3-4812-bc71-c410b2860e18","urn:uuid:aff99222-18e3-4812-bc71-c410b2860e19","urn:uuid:aff99222-18e3-4812-bc71-c410b2860e20")</rim:Value>
      </rim:ValueList>
    </rim:Slot>
  </rim:AdhocQuery>
</query:AdhocQueryRequest>

3.18.4.1.3.2 Intentionally Left Blank

3.18.4.1.3.3 Sample Query Response

This sample query response corresponds to the above query. Note that the query response message is coded in version 3.0 ebRIM and ebRS. This sample response and the ebXML Registry version 3.0 schema files are available online. The Implementation Guide found at https://wiki.ihe.net/index.php/ITI_Implementation_Guide contains such supplemental material.

<?xml version="1.0" encoding="UTF-8"?>
<AdhocQueryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0 file:/Users/bill/RegSchema/V3.0/query.xsd">
  <rim:RegistryObjectList>
    <rim:ExtrinsicObject id="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" isOpaque="false" mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
      <rim:Slot name="URI">
        <rim:ValueList>
          <rim:Value>http://localhost:8080/XDS/Repository/08a15a6f-5b4a-42de-8f95-89474f83abdf.xml</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="authorInstitution">
        <rim:ValueList>
          <rim:Value>Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="creationTime">
        <rim:ValueList>
          <rim:Value>200412261119</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="hash">
        <rim:ValueList>
          <rim:Value>4cf4f82d78b5e2aac35c31bca8cb79fe6bd6a41e</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="languageCode">
        <rim:ValueList>
          <rim:Value>en-us</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="serviceStartTime">
        <rim:ValueList>
          <rim:Value>200412230800</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="serviceStopTime">
        <rim:ValueList>
          <rim:Value>200412230801</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="size">
        <rim:ValueList>
          <rim:Value>54449</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="sourcePatientId">
        <rim:ValueList>
          <rim:Value>jd12323^^^wsh</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Slot name="sourcePatientInfo">
        <rim:ValueList>
          <rim:Value>PID-3|pid1^^^domain</rim:Value>
          <rim:Value>PID-5|Doe^John^^^</rim:Value>
          <rim:Value>PID-7|19560527</rim:Value>
          <rim:Value>PID-8|M</rim:Value>
          <rim:Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</rim:Value>
        </rim:ValueList>
      </rim:Slot>
      <rim:Name>
        <rim:LocalizedString charset="UTF-8" value="Sample document 1" xml:lang="en-us"/>
      </rim:Name>
      <rim:Description/>
      <rim:Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" id="urn:uuid:ac872fc0-1c6e-439f-84d1-f76770a0ccdf" nodeRepresentation="Education" objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>Connect-a-thon classCodes</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="Education" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:Classification>
      <rim:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" id="urn:uuid:f1a8c8e4-3593-4777-b7e0-8b0773378705" nodeRepresentation="C" objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>Connect-a-thon confidentialityCodes</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="Celebrity" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:Classification>
      <rim:Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" id="urn:uuid:b6e49c73-96c8-4058-8c95-914d83bd262a" nodeRepresentation="CDAR2/IHE 1.0" objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>Connect-a-thon formatCodes</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="CDAR2/IHE 1.0" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:Classification>
      <rim:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" id="urn:uuid:61e2b376-d74a-4984-ac21-dcd0b8890f9d" nodeRepresentation="Emergency Department" objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>Connect-a-thon healthcareFacilityTypeCodes</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="Assisted Living" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:Classification>
      <rim:Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" id="urn:uuid:fb7677c5-c42f-485d-9010-dce0f3cd4ad5" nodeRepresentation="Cardiology" objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>Connect-a-thon practiceSettingCodes</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="Cardiology" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:Classification>
      <rim:Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" id="urn:uuid:0a8a8ed9-8be5-4a63-9b68-a511adee8ed5" nodeRepresentation="34098-4" objectType="Urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification">
        <rim:Slot name="codingScheme">
          <rim:ValueList>
            <rim:Value>LOINC</rim:Value>
          </rim:ValueList>
        </rim:Slot>
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="Conference Evaluation Note" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:Classification>
      <rim:ExternalIdentifier id="urn:uuid:db9f4438-ffff-435f-9d34-d76190728637" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" objectType="ExternalIdentifier" registryObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" value="st3498702^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO">
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="XDSDocumentEntry.patientId" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:ExternalIdentifier>
      <rim:ExternalIdentifier id="urn:uuid:c3fcbf0e-9765-4f5b-abaa-b37ac8ff05a5" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" objectType="ExternalIdentifier" registryObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" value="1.3.6.1.4.1.21367.2005.3.99.1.1010">
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="XDSDocumentEntry.uniqueId" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:ExternalIdentifier>
    </rim:ExtrinsicObject>
    <rim:ObjectRef id="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
    <rim:ObjectRef id="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
    <rim:ObjectRef id="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
    <rim:ObjectRef id="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
    <rim:ObjectRef id="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
    <rim:ObjectRef id="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
    <rim:ObjectRef id="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
    <rim:ObjectRef id="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" xmlns:q="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"/>
  </rim:RegistryObjectList>
</AdhocQueryResponse>

The following query response is the same as above (repeated sections replaced with …) with the homeCommunityId attribute specified. Subsequent requests specifying entryUUID of urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf or uniqueID of 1.3.6.1.4.1.21367.2005.3.99.1.1010 shall include the homeCommunityId value of urn:oid:1.2.3 in the query.

<?xml version="1.0" encoding="UTF-8"?>
<AdhocQueryResponse … status="Success">
  <rim:RegistryObjectList>
    <rim:ExtrinsicObject … id="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" isOpaque="false" mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" home="urn:oid:1.2.3">
      …
      <rim:ExternalIdentifier id="urn:uuid:c3fcbf0e-9765-4f5b-abaa-b37ac8ff05a5" registryObject="urn:uuid:08a15a6f-5b4a-42de-8f95-89474f83abdf" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" objectType="ExternalIdentifier" value="1.3.6.1.4.1.21367.2005.3.99.1.1010">
        <rim:Name>
          <rim:LocalizedString charset="UTF-8" value="XDSDocumentEntry.uniqueId" xml:lang="en-us"/>
        </rim:Name>
        <rim:Description/>
      </rim:ExternalIdentifier>
    </rim:ExtrinsicObject>
  </rim:RegistryObjectList>
</AdhocQueryResponse>

3.18.4.1.3.4 Intentionally Left Blank

3.18.4.1.3.5 Basic Patient Privacy Enforcement Option

If the Basic Patient Privacy Enforcement Option is implemented:

All Document Consumer Actors may provide a list of confidentialityCode in XDS Registry Stored Query Transaction and the XDS Registry will return only document that have at least one matching confidentialityCode. In this way documents without at least one of the requested codes will not be returned.
The Document Consumer shall be able to be configured with the Patient Privacy Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary to understand and enforce the XDS Affinity Domain Policy. The details of this are product specific and not specified by IHE.
The Document Consumer shall not allow access to documents for which the Document Consumer does not understand at least one of the confidentialityCode returned. This assures that a Document Consumer will not improperly handle documents with confidentialityCode that may be more restrictive than the Document Consumer is configured to support.
The Document Consumer shall abide by the XDS Affinity Domain Policies represented by the confidentialityCode in the metadata associated with the document. The Document Consumer likely will have user access controls or business rule capabilities to determine the details of how confidentiality codes apply to query results. The details of this are product specific and not specified by IHE. These rules shall reduce the query results to only those that are appropriate to the current situation for that actor and user.
Note: The Registry is already required to return only documents that match the requested confidentialityCode (filter) indicated in the Registry Stored Query.
Note: Products implementing the Document Registry may be able to further filter Registry Stored Query results through looking at all the Patient Privacy Acknowledgement Documents registered for the patient that have the availabilityStatus of Approved and for which have not expired.

3.18.4.1.3.6 Basic Patient Privacy Proof Option

If the Basic Patient Privacy Consents Proof Option is implemented:

The Document Consumer shall be capable of querying for 'Approved' Patient Privacy Acknowledgement Documents in the XDS Affinity Domain. This query should be done by document class so as to catch both formats of document (Consent). The Document Consumer shall be capable of recognizing the eventCodeList from the resulting XDS Metadata. There is no required handling of Patient Privacy Consent Acknowledgement Document XDS Metadata. There is no requirement for the Document Consumer to retrieve the Patient Privacy Acknowledgement Document content.

3.18.5 Security Considerations

Relevant XDS Affinity Domain Security background is discussed in the XDS Security Considerations Section (see ITI TF-1: 10.7).

3.18.5.1 Audit Record Considerations

The Registry Stored Query [ITI-18] transaction is a Query Information event as defined in Table 3.20.4.1.1.1-1. If a status of PartialSuccess is returned, the Actors involved shall record both a success and a failure audit event. The Actors involved shall record audit events according to the following:

3.18.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	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-18”, “IHE Transactions”, “Registry Stored Query”)
Source (Document Consumer) (1)
Human Requestor (0..n)
Destination (Document Registry) (1)
Audit Source (Document Consumer) (1)
Patient (0..1)
Query Parameters (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	M	If 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 (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (Person)
	ParticipantObjectTypeCodeRole	M	“1” (Patient)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	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-18”, “IHE Transactions”, “Registry Stored Query”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	Stored Query ID (UUID)
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	M	the AdhocQueryRequest, base64 encoded.
	ParticipantObjectDetail	C	The ParticipantObjectDetail element may occur more than once. In one element, set “QueryEncoding”as the value of the attribute type , Set the attribute value to the character encoding, such as “UTF-8”, used to encode the ParticipantObjectQuery before base64 encoding. In another element, set “urn:ihe:iti:xca:2010:homeCommunityId” as the value of the attribute type and the value of the homeCommunityID as the value of the attribute value, if known.

3.18.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	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-18”, “IHE Transactions”, “Registry Stored Query”)
Source (Document Consumer) (1)
Destination (Document Registry) (1)
Audit Source (Document Registry) (1)
Patient (0..1)
Query Parameters (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	M	If Asynchronous Web Services Exchange is being used, the content of the <wsa:ReplyTo/> element. Otherwise, not specialized.
	AlternativeUserID	U	not specialized
	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)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	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-18”, “IHE Transactions”, “Registry Stored Query”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	Stored Query ID (UUID)
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	M	the AdhocQueryRequest, base64 encoded.
	ParticipantObjectDetail	C	The ParticipantObjectDetail element may occur more than once. In one element, set “QueryEncoding”as the value of the attribute type , Set the attribute value to the character encoding, such as “UTF-8”, used to encode the ParticipantObjectQuery before base64 encoding. In another element, set “urn:ihe:iti:xca:2010:homeCommunityId” as the value of the attribute type and the value of the homeCommunityID as the value of the attribute value, if known.