Release 5

This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Example OperationDefinition/Resource-validate (Narrative)

FHIR Infrastructure Work GroupMaturity Level: N/AStandards Status: InformativeCompartments: No defined compartments

This is the narrative for the resource. See also the XML, JSON or Turtle format.

Note that this is the formal definition for the validate operation as an OperationDefinition on Resource. See the Operation documentation


URL: [base]/Resource/$validate

URL: [base]/Resource/[id]/$validate

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INresource0..1Resource

Must be present unless the mode is "delete"

INmode0..1codeResource Validation Mode (Required)

Default is 'no action'; (e.g. general validation)

INprofile0..1canonical

If this is nominated, then the resource is validated against this specific profile. If a profile is nominated, and the server cannot validate against the nominated profile, it SHALL return an error

INusageContext TU0..*UsageContext

Indicates an implementation context that applies to this validation. Influences which additionalBindings are relevant. NOTE: Expectations around subsumption testing, etc. are not yet defined and may be server-specific.

OUTreturn1..1OperationOutcome

If the operation outcome does not list any errors, and a mode was specified, then this is an indication that the operation would be expected to succeed (excepting for transactional integrity issues, see below)

This operation may be used during design and development to validate application design. It can also be used at run-time. One possible use might be that a client asks the server whether a proposed update is valid as the user is editing a dialog and displays an updated error to the user. The operation can be used as part of a light-weight two phase commit protocol but there is no expectation that the server will hold the content of the resource after this operation is used, or that the server guarantees to successfully perform an actual create, update or delete after the validation operation completes.

This operation returns a 200 Ok provided that it was possible to perform validation, irrespective of whether validation issues were found. However, it is possible that certain errors in the validated content (e.g. invalid character set, broken JSON, etc.) may cause the overall validation operation to fail with a 4xx or 5xx series response.

Note: the correct behavior of validation with regard to language (especially for Coding.display) is currently undefined, and further development and testing may lead to specific requirements or recommendations in subsequent releases

Future versions of this specifcation may add additional validation parameters. A candidate list is maintained with the FHIR Validator Documentation


 

 

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.