On this page:

6.4Repository 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.4.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.

6.4.2Methods

 

Repository Validation can be enabled using either a custom Java based interceptor, a JavaScript based script, or by adding your own validation beans to the validation chain. The two interceptor modes are functionally equivalent. The bean mode offers finer-grained validation support.

See: