This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions . Page versions: R5R4BR4R3R2
This page provides an overview of how the FHIR specification supports validation of resources.
Validating a resource means, checking that the following aspects of the resource are valid:
Structure: Check that all the content in the resource is described by the specification, and nothing extra is present
Cardinality: Check that the cardinality of all properties is correct (min & max)
Value Domains: Check that the values of all properties conform to the rules for the specified types (including checking that enumerated codes are valid)
Coding/CodeableConcept bindings: Check that codes/displays provided in the Coding/CodeableConcept types are valid
Invariants: Check that the invariants (co-occurrence rules, etc.) have been followed correctly
Business Rules: Business rules are made outside the specification, such as checking for duplicates, checking that references resolve, checking that a user is authorized to do what they want to do, etc.
There are multiple ways to validate resources. This table summarizes the options
described in this specification, and which of the aspects above they can validate:
Schematron generated for a profile can test cardinality and invariants, but not bindings, and slicing is not really supported well
JSON schema generated for a profile can test cardinality, and slicing is partially supported
ShEx can enforce some bindings for well understood terminologies, but this is an ongoing area of development
It is at the discretion of the server how much validation to perform, but most servers offer the same services as or even use the common validators.
Some servers also offer a web interface
Note that all these validation methods are incomplete; they
can only validate the computable aspects of conformance. There are always
additional rules made in narrative that they are not able to check (e.g. a rule
such as "All the clinically important content in the data SHALL be in the
narrative", which might be made in an implementation guide, but could never be checked
by a conformance tool).
In case of disagreement between these conformance methods, note that:
The schema/schematron is the least capable - mainly because it is not connected to a terminology server
The validators are only as good as the underlying definitions, and depend on whether the underlying terminology servers support all the relevant terminologies
In general, the server validation operations use or derive from the validation code in the common validators, so have the same caveats
The final arbiter is human inspection of the content of the resources, and the relevant implementation guides and base specification
Also, note that static testing of resource content is not enough to
prove conformance to the specification. For further information, see
FHIR Conformance Testing icon.
7.6.1 Correct Use of Validation
Servers and clients may be configured to validate content when it is received (e.g. some of
the public testing services validate resources on create/update). This can be done both
during development and in production use of applications in healthcare processes.
While use during the development cycle is highly recommended, use during production
might not always be a good idea:
Validation - particularly full validation including terminology - can be quite computationally demanding.
This can impose unacceptable time delays in a production system
In production, validation can cause the loss of critical health care data (e.g. one field
has an unexpected value due to poor data entry, so all data associated with the resource is lost)
Validation may fail poor historical data that cannot be fixed - and this is usually difficult to test (and poorly tested)
On the other hand, validation during production use may be very important:
Validation may be required for security reasons. In particular, validation of narrative may be required to prevent active content or external references.
Validating resources at specific control points in the data flow can allow for better detection and recovery as opposed to specific application logic failing on bad data
An implementation should be conservative in its sending behavior, and liberal in its receiving behavior.
Applications should consider carefully how much validation beyond the security related issues to perform at run-time, and how errors will be handled.
7.6.2 Using the XML schema
The XML schema can be used to validate XML representations of the resources.
When validating a resource, you can nominate one of the following schema:
fhir-all.xsd: links in all the individual modular schemas
fhir-single.xsd: a single large file, mainly provided for schema processors that can't support circular references
In addition, the validation schema includes schematron
that can be initiated with transform "iso_svrl_for_xslt2.xsl" included in the
XML Tools download. Note that
XSLT2 is required to run the schematrons.
When running the schematron, use the file "fhir-invariants.sch". This
includes all the schematrons. The individual schematron files for each
resource are provided to allow implementers to build their own smaller
combined file that covers the relevant resource types for them.
7.6.3 Using the JSON schema
The JSON schema can be used with JSON schema validation software.
Links:
The operationvalidate can
be used to check whether a resource conforms to a profile. The simplest way to execute this operation is
to post the resource to a server:
POST [base]/Observation/$validate?profile=http://hl7.org/fhir/StructureDefinition/heartrate
[other HTTP headers]
<Observation>... resource to check as the body
The server will return an OperationOutcome resource listing issues found in the resource.
There are several things to consider when using this operation:
Not all servers support the $validate operation, though some of the public test servers do
Servers support the $validate operation generally will only validate against profiles already registered with the server
Servers may choose to support either XML, JSON, or both
7.6.6 Via a web interface
Some servers expose the $validate functionality
through a web page. For known public implementations,
see the FHIR Confluence page icon