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

Can result from the failure of a REST call or be part of the response message returned from a request message. If sent with extensions overriding particular issues, might even appear as part of a request message.

An error, warning or information message that results from a system action.

May be used to represent additional information that is not part of the basic definition of the element, and that modifies the understanding of the element that contains it. Usually modifier elements provide negation or qualification. In order to make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Indicates whether the issue indicates a variation from successful processing.

Indicates how relevant the issue is to the overall success of the action.

This is labeled as "Is Modifier" because applications should not confuse hints and warnings with errors.

Describes the type of the issue. The system that creates an OperationOutcome SHALL choose the most applicable code from the IssueType value set, and may additional provide its own code for the error in the details element.

Expresses the issue in a human and computer-friendly way, allowing the requesting system to behave differently based on the type of issue.

Additional details about the error. This may be a text description of the error, or a system code that identifies the error.

A human readable description of the error issue SHOULD be placed in details.text.

A reference to a code defined by a terminology system.

Allows for translations and alternate encodings within a code system. Also supports communication of the same instance to systems requiring different encodings.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labelled as UserSelected = true.

The identification of the code system that defines the meaning of the symbol in the code.

Need to be unambiguous about the source of the definition of the symbol.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should de-reference to some definition that establish the system clearly and unambiguously.

The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured. and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.

Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

Need to refer to a particular code in the system.

A representation of the meaning of the code in the system, following the rules of the system.

Need to be able to carry a human-readable meaning of the code for readers that do not know the system.

Indicates that this coding was chosen by a user directly - i.e. off a pick list of available items (codes or displays).

This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.

Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.

A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Very often the text is the same as a displayName of one of the codings.

Additional diagnostic information about the issue. Typically, this may be a description of how a value is erroneous, or a stack dump to help trace the issue.

Typically this field is used to provide troubleshooting information about the error.

A simple XPath limited to element names, repetition indicators and the default child access that identifies one of the elements in the resource that caused this issue to be raised.

Allows systems to highlight or otherwise guide users to elements implicated in issues to allow them to be fixed more easily.

The root of the XPath is the resource or bundle that generated OperationOutcome. Each XPath SHALL resolve to a single node. The XPath syntax is used whether the referenced instance is expressed in XML or JSON.