This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions . Page versions: R5 R4B R4 R3 R2

• Content
• Examples Detailed Descriptions
• Detailed Descriptions Search Params
• Mappings
• Examples
• Operations
• Profiles & Extensions
• R2 Conversions Extensions

2.44 2.10 Resource OperationOutcome - Content

Responsible Owner: FHIR Infrastructure Work Group

Maturity Level : 5   Normative (from v4.0.0)

Trial Use Security Category : Anonymous

Compartments : Not linked to any No defined compartments

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

This resource is referenced by

2.10.3 References to this Resource

• Resource References: GuidanceResponse , MeasureReport and MessageHeader
• Extension References: Messages

2.44.3 2.10.4 Resource Content

 

Alternate Additional definitions: Master Definition ( XML , + JSON ), , XML Schema / Schematron (for ) + JSON Schema , ShEx (for Turtle ) + see the extensions , the spreadsheet version & the dependency analysis

2.44.3.1 2.10.4.1 Terminology Bindings

Path	Definition ValueSet	Type	Reference Documentation
OperationOutcome.issue.severity	IssueSeverity	Required	How the issue affects the success of the action.
OperationOutcome.issue.code	IssueType	Required	IssueSeverity OperationOutcome.issue.code A code that describes the type of issue. Required IssueType
OperationOutcome.issue.details	A AuditEventOutcomeDetailExample (a valid code that provides details as the exact issue. from Operation Outcome Codes )	Example	Operation Outcome Codes Example values to indicate more detailed reason for outcome.

2.44.4 2.10.5 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", "error", indicating the reason for the failure.

Operation outcomes must include at least one issue. See the All OK example for a template for an operation that returns no errors.

2.44.5 2.10.6 Using the Location Element Expression

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

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

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

2.44.5.1 Reporting Errors in Resources

While resources may be represented in XML, JSON, or other forms, error 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: FHIRPath 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 statement in JSON, and because applications will often process the XPath directly (e.g. expression element. In addition to determine the relevant widget), the XPath statement must be simple. Specifically, simplified FHIRPath restrictions, the XPath expression SHALL only NOT contain element names and repetition indicators. So this is a .resolve() function. These examples are legal:

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

 <expression value="Patient.identifier"/>

  "expression" : "Patient.identifier[2].value"

but this is not:

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

  "expression" : "Patient.identifier.where(system.value='http://example.com/mrn').value"

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.

2.44.5.2 2.10.6.1 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 expression that has two parts, a fixed "http" "http" and the header or query parameter name separated by a ".". ".". Some examples:

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

This specification follows the convention that HTTP headers start with an uppercase character, and URL parameters start with a lowercase character. Implementations are encouraged to follow this convention, so that no name collisions occur.

2.10.7 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource , and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

(No search parameters for this resource)