This page is part of the FHIR Specification (v1.0.2: DSTU (v3.0.2: STU 2). 3). 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 R3 R2

2.7 7.5 Validating Resources

FHIR Infrastructure Work Group

Maturity Level : N/A

Ballot Status : DSTU 2 Informative

This page provides a quick overview of how the FHIR specification supports validation of resources.

In principle, resources can be validated: Validating a resource means, checking that the following aspects of the resource are valid:

• Against Structure : Check that all the original specification content in the resource is described by the specification, and nothing extra is present
• Against 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
• Profiles : Check that any rules in profiles have been followed (including those listed in the Resource.meta.profile , or in CapabilityStatement , or in an implementation guide ImplementationGuide , or otherwise required by context)
• Against Questionnaires : Check that a specific profile QuestionnaireResponse is valid against its matching Questionnaire
• 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.

Resources There are multiple ways to validate resources. This table summarizes the options described in this specification, and which of the aspects above they can be tested for conformance by: validate:

Method	XML	JSON	RDF	Structure	Cardinality	Values	Bindings	Invariants	Profiles	Questionnaires	Business Rules
Using the XML Schema - for
XML instances only Schema + Schematron									1
JSON Schema									2
ShEx							3
Using the FHIR Validator -
Validation Operation 4

Notes:

1. Schematron generated for a java jar provided as part of the specification profile can test cardinality and invariants, but not bindings, and slicing is not really supported well
2. Asking JSON schema generated for a FHIR Server - using the $validate operation profile can test cardinality, and slicing is partially supported
3. ShEx can enforce some bindings for well understood terminologies, but this is an ongoing area of development
4. It is at the discretion of the server how much validation to perform, but most servers use the validation jar, or code derived from it, and offer the same services. Some servers also offer Via a web interface - using a web form on a test server

Note that all these validation methods are incomplete; they can only validate the computable aspects of conformance, but there 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 java validator is only as good as the underlying definitions, and in particular particular, depends on whether the underlying terminology server supports all the relevant terminologies
• In general, the server validation operations use or derive from the java validation code, 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 .

2.7.1 7.5.1 Using the XML schema

The XML schema can be used to validate XML represenations 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.5.2 Using the JSON schema

The JSON schema can be used with JSON schema validation software. Links:

• JSON Schema
• JSON Validation Software

2.7.2 7.5.3 Using the FHIR Validator

The FHIR Validator is a Java jar that is provided as part of the specification, and that is used during the publication process to validate that all the published examples. To execute the FHIR validator, follow the following steps:

• Download the FHIR Validator
• (optional) Download One of the FHIR definitions (with or without text)
• Execute the validator, providing the path to the definitions, and a reference to the resource to validate

Here is an example windows batch file that demonstrates the process (using the common utilities wget and 7z :

 @ECHO OFF

@ECHO OFF


 ECHO get the validator and unzip it 
 wget.exe http://hl7.org/fhir/validator.zip

 wget http://hl7.org/fhir/STU3/validator.zip

 7z.exe x validator.zip

 ECHO Get the validation source file (dictionary)
 wget.exe http://hl7.org/fhir/validation-min.xml.zip

 wget http://hl7.org/fhir/STU3/definitions.xml.zip


 ECHO get an example to validate
 wget.exe http://hl7.org/fhir/patient-example.html -O test-obs.xml

 ECHO 1. First example shows how to validate against the base spec:
 ECHO   a. get an example to validate
 wget http://hl7.org/fhir/STU3/patient-example.xml -O pat-ex.xml


 ECHO validate it. The DAF profile will be loaded out of the definitions in validation-min.zip
 java -jar org.hl7.fhir.validator.jar test-obs.xml -defn validation-min.xml.zip -profile http://hl7.org/fhir/StructureDefinition/daf-patient

 ECHO   b. validate it
 java -jar org.hl7.fhir.validator.jar pat-ex.xml -defn definitions.xml.zip 


 ECHO 2. Second example shows how to validate against a profile in the spec:
 ECHO   a. get an example to validate
 wget http://hl7.org/fhir/STU3/observation-example-heart-rate.xml -O obs-ex.xml

 ECHO   b. validate it
 java -jar org.hl7.fhir.validator.jar obs-ex.xml -defn definitions.xml.zip -profile http://hl7.org/fhir/StructureDefinition/heartrate

 ECHO 3. Third example shows how to validate against a profile in an implementation guide:
 ECHO   a. get an example to validate
 wget http://hl7.org/fhir/STU3/observation-example-heart-rate.xml -O obs-ex.xml

 ECHO   b. validate it. note that you have to tell the validator where to get the implementation guide information
 java -jar org.hl7.fhir.validator.jar obs-ex.xml -defn definitions.xml.zip -ig http://hl7.org/fhir/us/core -profile http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient

 ECHO Press Any Key to Close

 pause

Note that it is not necessary to download the resource first; the http address can be supplied directly:

 java -jar org.hl7.fhir.validator.jar http://hl7.org/fhir/patient-example.html -defn validation-min.xml.zip -profile http://hl7.org/fhir/StructureDefinition/daf-patient

 java -jar org.hl7.fhir.validator.jar http://hl7.org/fhir/STU3//patient-example.html -defn validation-min.xml.zip -profile http://hl7.org/fhir/StructureDefinition/Patient

The validator requires an underlying terminology server. TODO: document By default, this part. for now, hard coded is http://fhir3.healthintersections.com.au. Use the parameter -tx to http://fhir-dev.healthintersections.com.au. specify another server. For a full list of parameters and options, just run the validator.jar without any parameters.

2.7.3 7.5.4 Asking a FHIR Server

The operation validate 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]/Patient/$validate?profile=http://hl7.org/fhir/StructureDefinition/daf-patient

 POST [base]/Observation/$validate?profile=http://hl7.org/fhir/StructureDefinition/heartrate

 [other HTTP headers]
 
 <Patient>.. resource to check as the body

 <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

2.7.4 7.5.5 Via a web interface

Some servers expose the $validate functionality though a web page. For known public implementations, see the FHIR wiki