This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

• Content
• Examples
• Formal Definitions
• Mappings
• Profiles

6.11 Resource Query - Content

A description of a query with a set of parameters.

6.11.3 Resource Content

<Query xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: extension, modifierExtension, language, text, and contained -->
 <identifier value="[uri]"/><!-- 1..1 Links query and its response(s) -->
 <parameter><!-- 1..* Extension Set of query parameters with values --></parameter>
 <response>  <!-- 0..1 If this is a response to a query -->
  <identifier value="[uri]"/><!-- 1..1 Links response to source query -->
  <outcome value="[code]"/><!-- 1..1 ok | limited | refused | error -->
  <total value="[integer]"/><!-- 0..1 Total number of matching records -->
  <parameter><!-- 0..* Extension Parameters server used --></parameter>
  <first><!-- 0..* Extension To get first page (if paged) --></first>
  <previous><!-- 0..* Extension To get previous page (if paged) --></previous>
  <next><!-- 0..* Extension To get next page (if paged) --></next>
  <last><!-- 0..* Extension To get last page (if paged) --></last>
  <reference><!-- 0..* Resource(Any) Resources that are the results of the search --></reference>
 </response>
</Query>

Alternate definitions: Schema/Schematron, Resource Profile

6.11.3.1 Terminology Bindings

Notes about the Query resource:

• The id is usually a UUID (urn:uuid:...). Its sole use is to match request and response logically
• The parameters defined for use with the query the resource are all those described above, with the addition of an optional _type parameter, which is the name of the Resource type to limit the search on. Without this parameter, the Query effectively becomes a system-wide search.
• The extension type is used for parameters. The namespace "http://hl7.org/fhir/query" is used in the Extension.uri value for all the named parameters. Other namespaces may be used for parameters that would/could not appear in the named parameter list in a query url.
• Search parameter name, modifiers and chained parameters are added to the Extension uri as a fragment identifier, e.g.

    <parameter url="http://hl7.org/fhir/query#subject:Patient.name">
      <valueString value="odile"/>
    </parameter>
  

• Parameter names are mandatory, and values are optional. Parameters with missing values are ignored when processing the query
• Parameter names do not need to be unique. The interpretation of multiple search parameters is as described above
• There SHALL be at least one parameter provided with a search - a search request without any parameters cannot be processed
• The search engine SHALL return the parameters used to process the search so the client knows what search was performed
• The links to first, previous, next and last pages in the query result set are provided at the discretion of the server. The client performs a new query using those parameters to retrieve the specified pages. If no parameters are returned, there is no link to follow
• The references to the result set are usually version specific references
• The query resource contains an outcome code. There is no way to represent the code "limited" in a RESTful query where there is no query resource

6.11.3.2 Messaging based Queries

In order to initiate a message-based query, a sender sends a message consisting of a Message resource, and a Query resource. The message header resource routes the message to the correct destination, and the query contains the parameters of the search that is requested. See the examples for an example query request message.

The receiver processes the message, and then returns a message with a message header, a query with response details, and either an error in the query response, or a set of resources that meet the query criteria. See the examples for an example query response message.

If the sender wishes to retrieve additional pages from the original search, the sender constructs a new query with the parameters specified by the search processing system, and the cycle starts again.

6.11.3.3 Asynchronous Queries on a REST framework

The query resource can be used on a RESTful interface. Multiple interactions patterns are possible. This is a matter of ongoing investigation during the DSTU period.

6.11.4 Searching the Searches

As a consequence of the general framework, it is possible to search on a set of stored queries, though there is no known particular use case for doing so.

6.11.5 Search Parameters

Search parameters for this resource. The standard parameters also apply as described above.