This page is part of the FHIR Specification (v1.6.0:
STU
3 Ballot 4). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
This is the narrative for the resource. See also the
XML
or
or
JSON
format.
format.
OPERATION:
Validate
a
resource
OPERATION: Validate a resource
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:
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
URL:
[base]/Resource/$validate
URL: [base]/Resource/$validate
URL:
[base]/Resource/[id]/$validate
URL: [base]/Resource/[id]/$validate
Parameters
| Use | Name | Cardinality | Type | Binding | Documentation |
| IN | resource | 0..1 | Resource |
|
|
| IN | mode | 0..1 | code |
http://hl7.org/fhir/ValueSet/resource-validation-mode
|
|
| IN | profile | 0..1 | uri |
|
|
| OUT | return | 1..1 | OperationOutcome |
|
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 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.
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.