• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• R3 Conversions

2.45 Resource OperationOutcome - Content

FHIR Infrastructure Work Group

Maturity Level: N

Normative (from v4.0.0)

Compartments: Not linked to any defined compartments

This page has been approved as part of an ANSI standard. See the Infrastructure Package for further details.

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

2.45.3 References

This resource is referenced by GuidanceResponse and MessageHeader.

This resource does not implement any patterns.

2.45.4 Resource Content

 

See the Profiles & Extensions and the alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis a

2.45.4.1 Terminology Bindings

Path	Definition	Type	Reference
OperationOutcome.issue.severity		Required	IssueSeverity
OperationOutcome.issue.code		Required	IssueType
OperationOutcome.issue.details		Example	http://hl7.org/fhir/ValueSet/operation-outcome

2.45.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", 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.45.6 Using the Expression

Each issue in an operation outcome SHOUD have an expression that reports a location for the issue. A correctly populated expression can allow client systems to:

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

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

Error locations are always reported using a simplified FHIRPath statement in the expression element. In addition to the simplified FHIRPath restrictions, the expression SHALL not contain a .resolve() function. These examples are legal:

 <expression value="Patient.identifier"/>

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

but this is not:

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

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

Expresson	Description
http.code	A reference to the search parameter "code"
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.

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.