IHE ITI Technical Framework
The Final Text ITI Technical Framework is published here in HTML format and is no longer published as PDF. Trial Implementation supplements are available from the Volume 1 Table of Contents.

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

Interaction Diagram

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:

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, 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.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>

or

<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

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,…)

OR

  • (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 1 XDSDocumentEntry.classCode O M
$XDSDocumentEntryTypeCode 1 XDSDocumentEntry.typeCode O M
$XDSDocumentEntryPracticeSettingCode 1 XDSDocumentEntry.practiceSettingCode O M
$XDSDocumentEntryCreationTimeFrom 6 Lower value of XDSDocumentEntry.creationTime O
$XDSDocumentEntryCreationTimeTo 6 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 XDSDocumentEntry.healthcareFacilityTypeCode O M
$XDSDocumentEntryEventCodeList 1 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.availabilityStatus R M
$XDSDocumentEntryType 5 XDSDocumentEntryobjectType O M

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

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

6 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 1 XDSSubmissionSet.authorPerson O
$XDSSubmissionSetContentType 2 XDSSubmissionSet.contentTypeCode O M
$XDSSubmissionSetStatus XDSSubmissionSet.availabilityStatus R M

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

2 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

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

2 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 2 XDSDocumentEntry.formatCode O M
$XDSDocumentEntryConfidentialityCode 1,2 XDSDocumentEntry.confidentialityCode 1 O M
$XDSDocumentEntryType 3 XDSDocumentEntry.objectType O M

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

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

3 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 3 XDSDocumentEntry.entryUUID O1 M
$XDSDocumentEntryUniqueId 3 XDSDocumentEntry.uniqueId O 1 M
$homeCommunityId None O 2

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

2 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.

3 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 3 XDSFolder.entryUUID O 1 M
$XDSFolderUniqueId 3 XDSFolder.uniqueId O 1 M
$homeCommunityId None O 2

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

2 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 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 1 -

1 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 3 XDSDocumentEntry.entryUUID O 1 M
$XDSDocumentEntryUniqueId 3 XDSDocumentEntry.uniqueId O 1 M
$homeCommunityId None O 2

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

2 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 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.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 2

XDSDocumentEntry.entryUUID and

XDSFolder.entryUUID

R M
$homeCommunityId None O 1

1 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.

2 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 5 XDSSubmissionSet.entryUUID O 1
$XDSSubmissionSetUniqueId 5 XDSSubmissionSet.uniqueId O 1
$XDSDocumentEntryFormatCode 4 XDSDocumentEntry.formatCode O M
$XDSDocumentEntryConfidentialityCode 4 XDSDocumentEntry.confidentialityCode 2 O M
$homeCommunityId None O 3
$XDSDocumentEntryType 6 XDSDocumentEntry.objectType O M

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

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

3 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.

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

5 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.

6 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 5 XDSFolder.entryUUID O 1
$XDSFolderUniqueId 5 XDSFolder.uniqueId O 1
$XDSDocumentEntryFormatCode 4 XDSDocumentEntry.formatCode O M
$XDSDocumentEntryConfidentialityCode 4 XDSDocumentEntry.confidentialityCode 2 O M
$homeCommunityId None O 3
$XDSDocumentEntryType 6 XDSDocumentEntry.objectType O M

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

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

3 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.

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

5 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.

6 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 1
$XDSDocumentEntryUniqueId XDSDocumentEntry.uniqueId O 1
$homeCommunityId None O 2

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

2 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.

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 1
$XDSDocumentEntryUniqueId XDSDocumentEntry.uniqueId O 1
$AssociationTypes Not a named attribute R M
$homeCommunityId None O 2
$XDSDocumentEntryType 3 XDSDocumentEntry.objectType O M

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

2 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 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 5 XDSDocumentEntry.referenceIdList 3 R M
$XDSDocumentEntryClassCode 1 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 XDSDocumentEntry.healthcareFacilityTypeCode O M
$XDSDocumentEntryEventCodeList 1 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.availabilityStatus R M
$XDSDocumentEntryType 6 XDSDocumentEntry.objectType O M

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

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

6 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.:

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

OR

  • 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:

  1. Accept a parameterized query in an AdhocQueryRequest message
  2. Verify the required parameters are included in the request. Additionally, special rules documented in the above section 'Parameters for Required Queries' shall be verified.
  3. 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.

  1. 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.
  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.
  1. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Note: The Registry is already required to return only documents that match the requested confidentialityCode (filter) indicated in the Registry Stored Query.
  6. 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:

Shall be able to record IHE - ITI-18 Document Consumer audit message. Where:

  1. Source.ActiveParticipant.UserId: If Asynchronous Web Services Exchange is being used, the content of the <wsa:ReplyTo/> element. Otherwise, not specialized.
  2. Source.ActiveParticipant.AlternativeUserId: The process ID as used within the local operating system in the local system logs
  3. Destination.ActiveParticipant.UserID: SOAP endpoint URI
  4. HumanRequestor.UserID: Identity of the human that initiated the transaction
  5. Patient.ParticipantObjectID: The patient ID in HL7 CX format
  6. QueryParameters.ParticipantObjectID: Stored Query ID (UUID)
  7. QueryParameters.ParticipantObjectQuery: the AdhocQueryRequest, base64 encoded
  8. QueryParameters.ParticipantObjectDetail:
    1. The ParticipantObjectDetail element shall occur at least once.
    2. One element shall contain:
      1. type: “QueryEncoding” (literal string)
      2. value: the character encoding, such as “UTF-8”, used to encode the ParticipantObjectQuery before base64 encoding
    3. If the homeCommunityId is known, another element shall contain:
      1. type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal string)
      2. value: value of the homeCommunityId
3.18.5.1.2 Document Registry audit message:

Shall be able to record IHE - ITI-18 Document Registry audit message. Where:

  1. Source.ActiveParticipant.UserId: If Asynchronous Web Services Exchange is being used, the content of the <wsa:ReplyTo/> element. Otherwise, not specialized.
  2. Destination.ActiveParticipant.AlternativeUserId: The process ID as used within the local operating system in the local system logs
  3. Destination.ActiveParticipant.UserID: SOAP endpoint URI
  4. Patient.ParticipantObjectID: The patient ID in HL7 CX format
  5. QueryParameters.ParticipantObjectID: Stored Query ID (UUID)
  6. QueryParameters.ParticipantObjectQuery: the AdhocQueryRequest, base64 encoded
  7. QueryParameters.ParticipantObjectDetail:
    1. The ParticipantObjectDetail element shall occur at least once.
    2. One element shall contain:
      1. type: “QueryEncoding” (literal string)
      2. value: the character encoding, such as “UTF-8”, used to encode the ParticipantObjectQuery before base64 encoding
    3. If the homeCommunityId is known, another element shall contain:
      1. type: “urn:ihe:iti:xca:2010:homeCommunityId” (literal string)
      2. value: value of the homeCommunityId
  8. Where: use of XUA would add an ActiveParticipant as defined in XUA Profile