On this page:

6.3Repository Validation


Repository Validation allows declarative rules to be applied to a FHIR Repository that makes specific validation rules mandatory for all data stored in the repository. This mode has the advantage of operating at a lower level than the HTTP interface, meaning that:

  • It can apply validation rules to sources of data other than HTTP FHIR Endpoints (e.g. ETL processes, other API calls)

  • It can apply validation rules to operations other than simple create/update operations (e.g. patch, embedded operations within FHIR transactions, etc.)

Repository Validation is generally the better way to apply validation rules in repository mode. This form of validation can not currently be used with Hybrid Providers or the FHIR Gateway (although if these components are ultimately directing requests to a Smile CDR repository, that repository can use Repository Validation).

Repository Validation Mode

6.3.1Validation Support Repository


When using Repository Validation, the FHIR Storage module containing the resources to be validated (the Clinical Resource Storage) may declare a module dependency on a different FHIR Storage module that is used as a Validation Support Repository (the Validation Support).

It is also possible for a single FHIR Storage module to be used for both purposes. In this case, no module dependency is specified and any required validation and conformance data is loaded into the same repository as the resources being validated.



The Repository Validation can be enabled using either a custom Java based interceptor, or a JavaScript based script. These modes are functionally equivalent, and which one you should pick depends mostly on the technology you are more comfortable using.


6.3.3Validating References


The Local Reference Policy setting can be used to control the behavior when validating a reference from one resource to another. This setting should be carefully considered, since validating a reference usually means loading the target resource and potentially parsing it and extracting parts of it. In performance sensitive environments, this can have a measurable effect on throughput, although it does improve the quality of the validation.

This setting should be configured on the FHIR Storage repository whose resources are being validated (as opposed to the FHIR Storage repository being used for validation support, if these are not the same repository).

The following values may be used:

  • NOT_VALIDATED – Don't validate references.
  • VALIDATE_EXISTS – Validate that the reference is valid and the target exists, but do not validate that the target resource is fully appropriate as a target for the reference.
  • VALIDATE_TARGET – Validate that the reference is valid, but also that the target resource is appropriate for the given reference (it conforms to the right profiles, is of the right type, etc.)