A persistent identifier for the bundle that won't change as a bundle is copied from server to server.

Persistent identity generally only matters for batches of type Document, Message, and Collection. It would not normally be populated for search and history results and servers ignore Bundle.identifier when processing batches and transactions. For Documents the .identifier SHALL be populated such that the .identifier is globally unique.

A series of links that provide context to this entry.

Why this entry is in the result set - whether it's included as a match or because of an _include requirement, or to convey information or warning information about the search process.

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.

See Patient Match for the EMPI search which relates to this element.

In a transaction or batch, this is the HTTP action to be executed for this entry. In a history bundle, this indicates the HTTP action that occurred.

Note that FHIR strings SHALL NOT exceed 1MB in size

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

Note that FHIR strings SHALL NOT exceed 1MB in size

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

Note: This is intended for where precisely observed times are required, typically system logs etc., and not human-reported times - for them, see date and dateTime (which can be as precise as instant, but is not required to be) below. Time zone is always required

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

Note that FHIR strings SHALL NOT exceed 1MB in size

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 "?").

Note that FHIR strings SHALL NOT exceed 1MB in size

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.

Note that FHIR strings SHALL NOT exceed 1MB in size

The location header created by processing this operation, populated if the operation returns a location.

see http://en.wikipedia.org/wiki/Uniform_resource_identifier

The Etag for the resource, if the operation for the entry produced a versioned resource (see Resource Metadata and Versioning and Managing Resource Contention).

Etags match the Resource.meta.versionId. The ETag 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 (meta.lastUpdated) if a resource is included.

An OperationOutcome containing hints and warnings produced as part of processing this entry in a batch or transaction.

For a POST/PUT operation, this is the equivalent outcome that would be returned for prefer = operationoutcome - except that the resource is always returned whether or not the outcome is returned.

This outcome is not used for error responses in batch/transaction, only for hints and warnings. In a batch operation, the error will be in Bundle.entry.response, and for transaction, there will be a single OperationOutcome instead of a bundle in the case of an error.

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

A Signature holds an electronic representation of a signature and its supporting context in a FHIR accessible form. The signature may either be a cryptographic type (XML DigSig or a JWS), which is able to provide non-repudiation proof, or it may be a graphical image that represents a signature or a signature process. This element allows capturing signatures on documents, messages, transactions or even search responses, to 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.