DSTU2

This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

6.12 Resource OperationOutcome - Content

FHIR Infrastructure Work GroupMaturity Level: 2Compartments: Not linked to any defined compartments

A collection of error, warning or information messages that result from a system action.

6.12.1 Scope and Usage

Operation Outcomes are sets of error, warning and information messages that provide detailed information about the outcome of some attempted system operation. They are provided as a direct system response, or component of one, where they provide information about the outcome of the operation.

OperationOutcomes are used in the following circumstances:

  • When an RESTful operation fails
  • As the response on a validation operation, to provide information about the outcomes
  • As part of a message response, usually when the message has not been processed correctly

6.12.2 Boundaries and Relationships

This resource is not used for reporting clinical or workflow issues associated with a proposed or ongoing action; these would be handled using DetectedIssue or other resources. The resource is not designed to be persisted or referenced from other parts of the workflow.

It is possible to have both OperationOutcome and DetectedIssue together, where the OperationOutcome might indicate that a requested action was rejected due to a clinical issue and the Contraindication provides the details of the issue.

This resource is referenced by messageheader

6.12.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. OperationOutcome ΣDomainResourceInformation about the success/failure of an action
... issue Σ1..*BackboneElementA single issue associated with the action
.... severity ?! Σ1..1codefatal | error | warning | information
IssueSeverity (Required)
.... code Σ1..1codeError or warning code
IssueType (Required)
.... details Σ0..1CodeableConceptAdditional details about the error
Operation Outcome Codes (Example)
.... diagnostics Σ0..1stringAdditional diagnostic information about the issue
.... location Σ0..*stringXPath of element(s) related to issue

doco Documentation for this format

XML Template

<OperationOutcome xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <issue>  <!-- 1..* A single issue associated with the action -->
  <severity value="[code]"/><!-- 1..1 fatal | error | warning | information -->
  <code value="[code]"/><!-- 1..1 Error or warning code -->
  <details><!-- 0..1 CodeableConcept Additional details about the error --></details>
  <diagnostics value="[string]"/><!-- 0..1 Additional diagnostic information about the issue -->
  <location value="[string]"/><!-- 0..* XPath of element(s) related to issue -->
 </issue>
</OperationOutcome>

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. OperationOutcome ΣDomainResourceInformation about the success/failure of an action
... issue Σ1..*BackboneElementA single issue associated with the action
.... severity ?! Σ1..1codefatal | error | warning | information
IssueSeverity (Required)
.... code Σ1..1codeError or warning code
IssueType (Required)
.... details Σ0..1CodeableConceptAdditional details about the error
Operation Outcome Codes (Example)
.... diagnostics Σ0..1stringAdditional diagnostic information about the issue
.... location Σ0..*stringXPath of element(s) related to issue

doco Documentation for this format

XML Template

<OperationOutcome xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <issue>  <!-- 1..* A single issue associated with the action -->
  <severity value="[code]"/><!-- 1..1 fatal | error | warning | information -->
  <code value="[code]"/><!-- 1..1 Error or warning code -->
  <details><!-- 0..1 CodeableConcept Additional details about the error --></details>
  <diagnostics value="[string]"/><!-- 0..1 Additional diagnostic information about the issue -->
  <location value="[string]"/><!-- 0..* XPath of element(s) related to issue -->
 </issue>
</OperationOutcome>

 

Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire

6.12.3.1 Terminology Bindings

PathDefinitionTypeReference
OperationOutcome.issue.severity How the issue affects the success of the action.RequiredIssueSeverity
OperationOutcome.issue.code A code that describes the type of issue.RequiredIssueType
OperationOutcome.issue.details A code that provides details as the exact issue.ExampleOperation Outcome Codes

6.12.4 Using Operation Outcome Resources

On the RESTful interface, operation outcome resources are only relevant when a level of computable detail is required that is more granular than that provided by the HTTP response codes. This granularity could include:

  • more detail about the location of an issue
  • the ability to identify multiple distinct issues
  • provision of finer error codes that connect to known business failure states

Operation outcomes returned SHOULD be in alignment with the HTTP response code. For example, if the HTTP code indicates a failure (300+), at least one of the issues should have a severity of "error", indicating the reason for the failure.

6.12.5 Using the Location Element

Each issue in an operation outcome may have a location reported. Systems that create operation outcomes SHOULD populate the location of an error. A correctly propulated location can allow client systems to:

  • Connect return errors with the appropriate UI widget
  • Route errors to the corect application or system log
  • Develop more intelligent testing applications

In order to support these kinds of usages, this applications need to use the location element consistently. Applications can use the location element to refer to a location inside a resource, or some location in the HTTP request (when appropriate).

6.12.5.1 Reporting Errors in Resources

While resources may be represented in XML, JSON, or other forms, error locations are always reported using a simplified XPath notation: 

 <location value="/f:Patient/f:identifier"/>

The XPath must use the FHIR standard XPath prefixes f: and h: for the FHIR and XHTML namespaces respectively.

The XPath here can be used to automatically find the relevant XML element in a resource if the resource is represented in XML. Because resources are often represented in JSON, and because applications will often process the XPath directly (e.g. to determine the relevant widget), the XPath statement must be simple. Specifically, the XPath SHALL only contain element names and repetition indicators. So this is legal: 

 <location value="/f:Patient/f:identifier[2]/f:label"/>

but this is not: 

 <location value="/f:Patient/f:identifier[f:system/@value='http://example.com/mrn']/f:label"/>

Because the Xpath is required to be simple, it can be converted to JsonPointer by dropping the namespace prefixes, and correcting for array offsets. The XPaths above have these equivalent JsonPointer representations: 

 Patient/identifier
 Patient/identifier/2/label

Note that correcting for array offsets may require knowledge of which elements are Arrays in JSON. It is also possible to convert the XPath statements to JsonPath, though there is no single standard for JsonPath.

6.12.5.2 Reporting Errors in the HTTP Headers

Servers may also need to report errors in the HTTP headers - especially query parameters when processing searches. Errors are reported using a case sensitive location that has two parts, a fixed "http" and the header or query parameter name separated by a ".". Some examples:

Location Description
http.name:exact A reference to the search parameter "name" with the modifier ":exact"
http.Authorization A reference to the Authorization header - perhaps to indicate that it is missing, and some form of authentication is required.