A container for a collection of resources.

Indicates the purpose of this bundle- how it was intended to be used.

It's possible to use a bundle for other purposes (e.g. a document can be accepted as a transaction). This is primarily defined so that there can be specific rules for some of the bundle types.

If a set of search matches, this is the total number of matches for the search (as opposed to the number of results in this bundle).

Only used if the bundle is a search result set.

A series of links that provide context to this bundle.

A name which details the functional use for this link - see [[http://www.iana.org/assignments/link-relations/link-relations.xhtml]].

The reference details for the link.

An entry in a bundle resource - will either contain a resource, or information about a resource (transactions and history only).

A series of links that provide context to this entry.

The Absolute URL for the resource. The fullUrl SHALL not disagree with the id in the resource. The fullUrl is a version independent reference to the resource. The fullUrl element SHALL have a value except that: * fullUrl can be empty on a POST (although it does not need to when specifying a temporary id for reference in the bundle) * Results from operations might involve resources that are not identified.

fullUrl may not be unique in the context of a resource. Note that since FHIR resources do not need to be served through the FHIR API, the absolute URL may not end with the logical id of the resource (Resource.id), but if the fullUrl does look like a RESTful server URL (e.g. meets the regex, then it SHALL end with the Resource.id.

The Resources for the entry.

Information about the search process that lead to the creation of this entry.

Why this entry is in the result set - whether it's included as a match or because of an _include requirement.

There is only one mode. In some corner cases, a resource may be included because it is both a match and an include. In these circumstances, 'match' takes precedence.

When searching, the server's search ranking score for the entry.

Servers are not required to return a ranking score. 1 is most relevant, and 0 is least relevant. Often, search results are sorted by score, but the client may specify a different sort order.

Additional information about how this entry should be processed as part of a transaction.

The HTTP verb for this entry in either a change history, or a transaction/ transaction response.

The URL for this entry, relative to the root (the address to which the request is posted).

E.g. for a Patient Create, the method would be "POST" and the URL would be "Patient". For a Patient Update, the method would be PUT, and the URL would be "Patient/[id]".

If the ETag values match, return a 304 Not modified status. See the API documentation for "Conditional Read".

Only perform the operation if the last updated date matches. See the API documentation for "Conditional Read".

Only perform the operation if the Etag value matches. For more information, see the API section "Managing Resource Contention".

Instruct the server not to perform the create if a specified resource already exists. For further information, see the API documentation for "Conditional Create". This is just the query portion of the URL - what follows the "?" (not including the "?").

Additional information about how this entry should be processed as part of a transaction.

The status code returned by processing this entry. The status SHALL start with a 3 digit HTTP code (e.g. 404) and may contain the standard HTTP description associated with the status code.

The location header created by processing this operation.

The etag for the resource, it the operation for the entry produced a versioned resource.

This has to match the version id in the header if a resource is included.

The date/time that the resource was modified on the server.

This has to match the same time in the meta header if a resource is included.

Digital Signature - base64 encoded. XML DigSIg or a JWT.

This element allows capturing signatures on documents. It also allows signatures on messages, transactions or even query responses. It may support content-authentication, non-repudiation or other business cases. This is primarily relevant where the bundle may travel through multiple hops or via other mechanisms where HTTPS non-repudiation is insufficient.

The signature could be created by the "author" of the bundle or by the originating device. Requirements around inclusion of a signature, verification of signatures and treatment of signed/non-signed bundles is implementation-environment specific.