$validate
Introduction
The tool introduced by FHIR to provide a separate validation mechanism for 2-steps commit workflow or for development needs. It works for create, update and delete operations, is called using ?mode=
query parameter with values create
, update
, delete
but changes won't be committed. Instead a requester will get an OperationOutcome
with information about validation results. See http://hl7.org/fhir/resource-operation-validate.html for the official documentation.
#FHIR format endpoint:
POST /fhir/<resourceType>/$validate
POST /fhir/<resourceType>/<id>/$validate
#Aidbox format endpoint:
POST /<resourceType>/$validate
POST /<resourceType>/<id>/$validate
Such requests check the resource structure, internal business rules and return a list of problems if some exist.
200
OK — those requests always return status 200
Success and failure of a validation request is determined by id
of OperationOutcome
resource. allok
and validationfail
are self-descriptive.
$validate supports two ways to pass arguments:
POST .../$validate
resourceType: Parameters
parameter:
- name: mode
value: {string: <mode>}
- name: profile
value: {uri: <StructureDefinition.url>}
- name: esource
resource: <resource>
POST .../$validate?mode=<mode>&profile=<StructureDefinition.url>
<resource>
Parameter
Description
resourceType
Required. Type of the resource which needs validation
id
Optional for mode
=create
. Can either be passed in the resource body or be specified in the route params
resource
Optional for mode
=delete
, required otherwise. Resource to be validated
mode
Optional. Default is create
. Possible values are create, update, delete, patch
profile
Optional. Can be passed multiple times. Used to validate with specific profiles.
Value should be StructureDefinition.url
of the profile defined as zen schema
mode
Description
create
Ignores errors about attributesid
& lastUpdated
being required
update
Validates without ignoring errors about attributesid
& lastUpdated
delete
Checks if resource with such id
exists in Aidbox
patch
Merges the existing resource to the received resource and then validates as update
.
Patching strategy will be determined as described here
merge-patch
simple deep merge semantics (read more in RFC)
json-patch
advanced JSON transformation (read more in RFC)
Examples
Validation Success
# Request:
POST /fhir/Patient/$validate?mode=create
name: [{given: [John]}]
# Response
HTTP 200 OK
id: allok
resourceType: OperationOutcome
issue:
- {severity: informational, code: informational, diagnostics: all ok}
# Request:
POST /fhir/Patient/$validate
resourceType: Parameters
parameter:
- name: mode
value: {string: create}
- name: resource
resource: {name: [{given: [John]}]}
# Response
HTTP 200 OK
id: allok
resourceType: OperationOutcome
issue:
- {severity: informational, code: informational, diagnostics: all ok}
Validation Failure
# Request:
POST /fhir/Patient/$validate?mode=create
name: "Bob"
test: "foo"
# Response
HTTP 200 OK
id: validationfail
resourceType: OperationOutcome
text: {status: generated, div: Invalid resource}
issue:
- severity: fatal
code: invalid
expression: [Patient.name]
diagnostics: expected array
- severity: fatal
code: invalid
expression: [Patient.test]
diagnostics: extra property
# Request:
POST /fhir/Patient/$validate?mode=create
name: "Bob"
test: "foo"
# Response
HTTP 200 OK
resourceType: Parameters
parameter:
- name: mode
value: {string: create}
- name: resource
resource: {name: Bob, test: foo}
Last updated
Was this helpful?