Operation
Definition
<?xml version="1.0" encoding="UTF-8"?>
The validate operation checks whether the attached content would be acceptable either
generally, as a create, an update or as a delete to an existing resource. The action
the server takes depends on the mode parameter:
[mode not provided]: The server checks the content of the resource against any schema,
constraint rules, and other general terminology rules
create: The server checks the content, and then checks that the content would be acceptable
as a create (e.g. that the content would not violate any uniqueness constraints)
update: The server checks the content, and then checks that it would accept it as an update
against the nominated specific resource (e.g. that there are no changes to immutable fields
the server does not allow to change, and checking version integrity if appropriate)
delete: The server ignores the content, and checks that the nominated resource is allowed
to be deleted (e.g. checking referential integrity rules)
Modes update and delete can only be used when the operation is invoked at the resource
instance level. The return from this operation is an
Note that this operation is not the only way to validate resources - see
for further information.
(Required)
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
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 whether or not the resource is valid. A 4xx or 5xx error
means that the validation itself could not be performed, and it is unknown whether the
resource is valid or not.
Note: the correct behaviour 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
The validate operation checks whether the attached content would be acceptable either
generally, as a create, an update or as a delete to an existing resource. The action
the server takes depends on the mode parameter:
* [mode not provided]: The server checks the content of the resource against any schema,
constraint rules, and other general terminology rules
* create: The server checks the content, and then checks that the content would be acceptable
as a create (e.g. that the content would not violate any uniqueness constraints)
* update: The server checks the content, and then checks that it would accept it as an
update against the nominated specific resource (e.g. that there are no changes to immutable
fields the server does not allow to change, and checking version integrity if appropriate)
* delete: The server ignores the content, and checks that the nominated resource is allowed
to be deleted (e.g. checking referential integrity rules)
Modes update and delete can only be used when the operation is invoked at the resource
instance level. The return from this operation is an [OperationOutcome](operationoutcome.html)
Note that this operation is not the only way to validate resources - see [Validating Resources](vali
dation.html) for further information.
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 whether or not the resource is valid. A 4xx or 5xx error
means that the validation itself could not be performed, and it is unknown whether the
resource is valid or not.
Note: the correct behaviour 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](https://confluence.hl7.org/display/FHIR/U
sing+the+FHIR+Validator)
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
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)
<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir"> <id value="Resource-validate"/> <text> <status value="generated"/> <div xmlns="http://www.w3.org/1999/xhtml"> <p class="res-header-id"> <b> Generated Narrative: OperationDefinition Resource-validate</b> </p> <a name="Resource-validate"> </a> <a name="hcResource-validate"> </a> <p> URL: [base]/$validate</p> <p> URL: [base]/Resource/$validate</p> <p> URL: [base]/Resource/[id]/$validate</p> <h3> Parameters</h3> <table class="grid"> <tr> <td> <b> Use</b> </td> <td> <b> Name</b> </td> <td> <b> Scope</b> </td> <td> <b> Cardinality</b> </td> <td> <b> Type</b> </td> <td> <b> Binding</b> </td> <td> <b> Documentation</b> </td> </tr> <tr> <td> IN</td> <td> resource</td> <td/> <td> 0..1</td> <td> <a href="resource.html">Resource</a> </td> <td/> <td> <div> <p> Must be present unless the mode is "delete" or the operation is invoked
at the instance level</p>
</div> </td> </tr> <tr> <td> IN</td> <td> mode</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#code">code</a> </td> <td> <a href="valueset-resource-validation-mode.html">Resource Validation Mode</a> (Required) </td> <td> <div> <p> Default is 'no action'; (e.g. general validation). If the mode is <code> create</code> , the operation cannot be invoked on a particular resource. </p> </div> </td> </tr> <tr> <td> IN</td> <td> profile</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#canonical">canonical</a> ( <a href="structuredefinition.html" title="http://hl7.org/fhir/StructureDefinition/StructureDefinition">StructureDefinition</a> ) </td> <td/> <td> <div> <p> 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. The profile parameter is required for mode=profile,
and may be present in other modes</p>
</div> </td> </tr> <tr> <td> IN</td> <td> graph</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#canonical">canonical</a> ( <code> http://hl7.org/fhir/StructureDefinition/GraphDefinition</code> ) </td> <td/> <td> <div> <p> 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.</p>
</div> </td> </tr> <tr> <td> IN</td> <td> usageContext</td> <td/> <td> 0..*</td> <td> <a href="metadatatypes.html#UsageContext">UsageContext</a> </td> <td/> <td> <div> <p> Indicates an implementation context that applies to this validation. Influences
which
<a href="terminologies.html#binding">additionalBindings</a> are relevant. NOTE: Expectations around subsumption testing, etc. are not yet
defined and may be server-specific.
</p> </div> </td> </tr> <tr> <td> IN</td> <td> language</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#string">string</a> </td> <td/> <td> <div> <p> 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</p>
</div> </td> </tr> <tr> <td> IN</td> <td> jurisdiction</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#code">code</a> </td> <td> <a href="http://terminology.hl7.org/7.0.1/ValueSet-jurisdiction.html">Jurisdiction ValueSet</a> (Extensible) </td> <td> <div> <p> 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</p>
</div> </td> </tr> <tr> <td> IN</td> <td> hintAboutNonMustSupport</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> 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
<code> mustSupport</code> 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.
</p> </div> </td> </tr> <tr> <td> IN</td> <td> extension</td> <td/> <td> 0..*</td> <td> <a href="datatypes.html#string">string</a> </td> <td/> <td> <div> <p> 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</p>
</div> </td> </tr> <tr> <td> IN</td> <td> questionnaire</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#code">code</a> </td> <td/> <td> <div> <p> Whether to validate the questionnaire in QuestionnaireResponse. Values: <code> none</code> - ignore, <code> check</code> - validate if a questionnaire is specified, and <code> require</code> - a questionnaire must be specified, and will be checked. </p> </div> </td> </tr> <tr> <td> IN</td> <td> extensible-binding-warnings</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> 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.</p>
</div> </td> </tr> <tr> <td> IN</td> <td> display-issues-are-warnings</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> 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.</p>
</div> </td> </tr> <tr> <td> IN</td> <td> unknown-codesystems-cause-errors</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> 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.</p>
</div> </td> </tr> <tr> <td> IN</td> <td> level</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#code">code</a> </td> <td> <a href="valueset-issue-severity.html">Issue Severity</a> (Required) </td> <td> <div> <p> The minimum level to report issues - e.g. ignore hints and warnings. By default,
all issues are returned</p>
</div> </td> </tr> <tr> <td> IN</td> <td> best-practice</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#code">code</a> </td> <td> <a href="valueset-issue-severity.html">Issue Severity</a> (Required) </td> <td> <div> <p> The level to treat best-practice invariants etc as. By default these are treated
as warnings</p>
</div> </td> </tr> <tr> <td> IN</td> <td> current</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> If this is true, additional bindings marked as 'current' will also be enforced</p> </div> </td> </tr> <tr> <td> IN</td> <td> forPublication</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> 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.</p>
</div> </td> </tr> <tr> <td> IN</td> <td> html-in-markdown</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#code">code</a> </td> <td/> <td> <div> <p> 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)</p>
</div> </td> </tr> <tr> <td> IN</td> <td> no_unicode_bidi_control_chars</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> Whether the existence of hidden bidi control characters is treated as a warning
or an error. See
<a href="https://nvd.nist.gov/vuln/detail/CVE-2021-42574">CVE-2021-42574</a> . Server discretion for the default value, and servers can ignore this setting. </p> </div> </td> </tr> <tr> <td> IN</td> <td> verbose-mode</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> Turns on verbose output, which servers may use to provide explanation of the validation
process (e.g. slicing decisions).</p>
</div> </td> </tr> <tr> <td> IN</td> <td> allow-example-urls</td> <td/> <td> 0..1</td> <td> <a href="datatypes.html#boolean">boolean</a> </td> <td/> <td> <div> <p> Allow references in resources to refer to example.org, which are understood to
be example URLs. Server discretion for the default value</p>
</div> </td> </tr> <tr> <td> OUT</td> <td> return</td> <td/> <td> 1..1</td> <td> <a href="operationoutcome.html">OperationOutcome</a> </td> <td/> <td> <div> <p> 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)</p>
</div> </td> </tr> </table> <div> <p> 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.</p>
<p> 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.</p>
<p> 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</p>
<p> Future versions of this specifcation may add additional validation parameters.
A candidate list is maintained with the
<a href="https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator">FHIR Validator Documentation</a> </p> </div> </div> </text> <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm"> <valueInteger value="5"/> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status"> <valueCode value="normative"/> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-wg"> <valueCode value="fhir"/> </extension> <url value="http://hl7.org/fhir/OperationDefinition/Resource-validate"/> <version value="6.0.0-ballot4"/> <name value="Validate"/> <title value="Validate a resource"/> <status value="active"/> <kind value="operation"/> <experimental value="false"/> <date value="2025-12-18T07:07:42+11:00"/> <publisher value="HL7 International / FHIR Infrastructure"/> <contact> <telecom> <system value="url"/> <value value="http://hl7.org/fhir"/> </telecom> <telecom> <system value="email"/> <value value="fhir@lists.hl7.org"/> </telecom> </contact> <contact> <telecom> <system value="url"/> <value value="http://www.hl7.org/Special/committees/fiwg"/> </telecom> </contact> <description value="The validate operation checks whether the attached content would be acceptable
either generally, as a create, an update or as a delete to an existing resource.
The action the server takes depends on the mode parameter:
* [mode not provided]: The server checks the content of the resource against any
schema, constraint rules, and other general terminology rules
* create: The server checks the content, and then checks that the content would
be acceptable as a create (e.g. that the content would not violate any uniqueness
constraints)
* update: The server checks the content, and then checks that it would accept it
as an update against the nominated specific resource (e.g. that there are no changes
to immutable fields the server does not allow to change, and checking version integrity
if appropriate)
* delete: The server ignores the content, and checks that the nominated resource
is allowed to be deleted (e.g. checking referential integrity rules)
Modes update and delete can only be used when the operation is invoked at the resource
instance level. The return from this operation is an [OperationOutcome](operationoutcome.ht
ml)
Note that this operation is not the only way to validate resources - see [Validating
Resources](validation.html) for further information."/>
<jurisdiction> <coding> <system value="http://unstats.un.org/unsd/methods/m49/m49.htm"/> <code value="001"/> <display value="World"/> </coding> </jurisdiction> <affectsState value="false"/> <code value="validate"/> <comment value="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](https://confluence.hl7
.org/display/FHIR/Using+the+FHIR+Validator)"/>
<resource value="Resource"/> <system value="true"/> <type value="true"/> <instance value="true"/> <parameter> <name value="resource"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="Must be present unless the mode is "delete" or the operation is invoked
at the instance level"/>
<type value="Resource"/> </parameter> <parameter> <name value="mode"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="Default is 'no action'; (e.g. general validation). If the mode is `create`, the
operation cannot be invoked on a particular resource."/>
<type value="code"/> <binding> <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName"> <valueString value="ResourceValidationMode"/> </extension> <strength value="required"/> <valueSet value="http://hl7.org/fhir/ValueSet/resource-validation-mode|6.0.0-ballot4"/> </binding> </parameter> <parameter> <name value="profile"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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. The profile parameter is required for mode=profile,
and may be present in other modes"/>
<type value="canonical"/> <targetProfile value="http://hl7.org/fhir/StructureDefinition/StructureDefinition"/> </parameter> <parameter> <name value="graph"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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."/>
<type value="canonical"/> <targetProfile value="http://hl7.org/fhir/StructureDefinition/GraphDefinition"/> </parameter> <parameter> <name value="usageContext"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="Indicates an implementation context that applies to this validation. Influences
which [additionalBindings](terminologies.html#binding) are relevant. NOTE: Expectations
around subsumption testing, etc. are not yet defined and may be server-specific."/>
<type value="UsageContext"/> </parameter> <parameter> <name value="language"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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"/>
<type value="string"/> </parameter> <parameter> <name value="jurisdiction"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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"/>
<type value="code"/> <binding> <strength value="extensible"/> <valueSet value="http://terminology.hl7.org/ValueSet/jurisdiction"/> </binding> </parameter> <parameter> <name value="hintAboutNonMustSupport"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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."/>
<type value="boolean"/> </parameter> <parameter> <name value="extension"/> <use value="in"/> <min value="0"/> <max value="*"/> <documentation value="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"/>
<type value="string"/> </parameter> <parameter> <name value="questionnaire"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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."/>
<type value="code"/> </parameter> <parameter> <name value="extensible-binding-warnings"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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."/>
<type value="boolean"/> </parameter> <parameter> <name value="display-issues-are-warnings"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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."/>
<type value="boolean"/> </parameter> <parameter> <name value="unknown-codesystems-cause-errors"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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."/>
<type value="boolean"/> </parameter> <parameter> <name value="level"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="The minimum level to report issues - e.g. ignore hints and warnings. By default,
all issues are returned"/>
<type value="code"/> <binding> <strength value="required"/> <valueSet value="http://hl7.org/fhir/ValueSet/issue-severity|6.0.0-ballot4"/> </binding> </parameter> <parameter> <name value="best-practice"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="The level to treat best-practice invariants etc as. By default these are treated
as warnings"/>
<type value="code"/> <binding> <strength value="required"/> <valueSet value="http://hl7.org/fhir/ValueSet/issue-severity|6.0.0-ballot4"/> </binding> </parameter> <parameter> <name value="current"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="If this is true, additional bindings marked as 'current' will also be enforced"/> <type value="boolean"/> </parameter> <parameter> <name value="forPublication"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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."/>
<type value="boolean"/> </parameter> <parameter> <name value="html-in-markdown"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="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)"/>
<type value="code"/> </parameter> <parameter> <name value="no_unicode_bidi_control_chars"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="Whether the existence of hidden bidi control characters is treated as a warning
or an error. See [CVE-2021-42574](https://nvd.nist.gov/vuln/detail/CVE-2021-42574).
Server discretion for the default value, and servers can ignore this setting."/>
<type value="boolean"/> </parameter> <parameter> <name value="verbose-mode"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="Turns on verbose output, which servers may use to provide explanation of the validation
process (e.g. slicing decisions)."/>
<type value="boolean"/> </parameter> <parameter> <name value="allow-example-urls"/> <use value="in"/> <min value="0"/> <max value="1"/> <documentation value="Allow references in resources to refer to example.org, which are understood to
be example URLs. Server discretion for the default value"/>
<type value="boolean"/> </parameter> <parameter> <name value="return"/> <use value="out"/> <min value="1"/> <max value="1"/> <documentation value="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)"/>
<type value="OperationOutcome"/> </parameter>
</
OperationDefinition
>
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.
Conformance
|
Propose
a
change