2nd DSTU Draft For Comment

This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Operation-resource-validate

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

Validate a resource

OPERATION: Validate a resource

The validate interaction checks whether the attached content would be acceptable either generally, or as a create, or an update or delete to an existing resource.

The action the server takes depends on the mode parameter:

  • [missing]: 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 validate 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 level.

The return from this operation is an OperationOutcome

URL: [base]/Resource/$Validate a resource

URL: [base]/Resource/[id]/$Validate a resource

Parameters

UseNameCardinalityTypeDocumentation
INresource0..1Resource

Must be present unles the mode is "delete"

INmode0..1string

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

INprofile0..1uri

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

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 succesfully perform an actual create, update or delete after the validation operation completes.

 

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.