Release 5 FHIR CI-Build

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

Example OperationDefinition/Resource-validate (Narrative)

Maturity Level : N/A
Responsible Owner: FHIR Infrastructure Work Group Standards Status : Informative Compartments : 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

Generated Narrative: OperationDefinition Resource-validate

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

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

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

Parameters

Use Name Scope Cardinality Type Binding Documentation
IN resource 0..1 Resource

Must be present unless the mode is "delete" or the operation is invoked at the instance level

IN mode 0..1 code Resource Validation Mode (Required)

Default is 'no action'; (e.g. general validation) validation). If the mode is create , the operation cannot be invoked on a particular resource.

IN profile 0..1 canonical ( StructureDefinition )

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 error. The profile parameter is required for mode=profile, and may be present in other modes

IN graph usageContext TU 0..1 canonical ( http://hl7.org/fhir/StructureDefinition/GraphDefinition )

Indicates that the referenced resource should be treated as the 'root' as the specified graph, validating all references for the resource to ensure they follow the rules. This parameter is not widely supported.

0..* IN usageContext 0..* 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.

IN language 0..1 string

One or more language codes (W3C Language tags, with sub-tags). This has the same format as the HTTP accept header, and defaults to the value of the header

OUT IN jurisdiction return 0..1 code 1..1 Jurisdiction ValueSet (Extensible)

The jurisdiction is used for validating in some profiles where country specific bindings are defined. The default jurisdiction is at the discretion of the server. If you want to specify No jurisdiction, this is functionally equivalent to a jurisdiction of the 'the whole world', which is jurisdiction=uv

IN hintAboutNonMustSupport 0..1 boolean

In some cases (e.g. when creating examples for implementation guides or when checking for potential interoperability issues with a new communication partner), it can be useful to know when data elements are present in an instance when those elements are not mustSupport in the profile(s) the instance is being validated against. Identifying situations where this occurs might drive a change to the profile or cause a designer to drop an element from the instance. In other cases, the presence of the element can be fine and the information message ignored.

IN extension 0..* string

The extension parameter controls how extensions are validated. It allows extensions from the specified domain (by matching the URL for the extension), and also has the special values 'any' and 'none'. It is up to the server to choose default settings for this parameter

IN questionnaire 0..1 code

Whether to validate the questionnaire in QuestionnaireResponse. Values: none - ignore, check - validate if a questionnaire is specified, and require - a questionnaire must be specified, and will be checked.

IN extensible-binding-warnings 0..1 boolean

When the validator encounters a code that is not part of an extensible binding, add a warning to suggest that the code be reviewed. This turns the warning on or off. It's up to the server to decide what the default is.

IN display-issues-are-warnings 0..1 boolean

Whether it's an error or just a warning when the validator encounters a coding or CodeableConcept where the display value isn't consistent with the display(s) defined by the code systems. It's up to the server to decide what the default is.

IN unknown-codesystems-cause-errors 0..1 boolean

Whether it's an error or just a warning when the validator encounters a unknown CodeSystem. It's up to the server to decide what the default is.

IN level 0..1 code Issue Severity (Required)

The minimum level to report issues - e.g. ignore hints and warnings. By default, all issues are returned

IN best-practice 0..1 code Issue Severity (Required)

The level to treat best-practice invariants etc as. By default these are treated as warnings

IN current 0..1 boolean

If this is true, additional bindings marked as 'current' will also be enforced

IN forPublication 0..1 boolean

If this is true, additional validation regarding suitability for 'publishing' are also enforced. Note that HL7 defines a set of rules, but the meaning and use of 'publishing' is at the discretion of the server.

IN html-in-markdown 0..1 code

What to do when HTML is found in markdown fields. Values = ignore, warning, and error. It's server discretion what the default is, and servers may choose to ignore turning this off (for security consideration reasons)

IN no_unicode_bidi_control_chars 0..1 boolean

Whether the existence of hidden bidi control characters is treated as a warning or an error. See CVE-2021-42574 . Server discretion for the default value, and servers can ignore this setting.

IN verbose-mode 0..1 boolean

Turns on verbose output, which servers may use to provide explanation of the validation process (e.g. slicing decisions).

IN allow-example-urls 0..1 boolean

Allow references in resources to refer to example.org, which are understood to be example URLs. Server discretion for the default value

OUT return 1..1 OperationOutcome

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.