9.3    Conformance Data
  • Validation and Conformance
  • 9.0 Introduction
  • 9.1 Validation Support Repository
  • 9.2 Validation Support Repository Options
  • 9.3 Conformance Data
  • 9.4 Repository Validation
  • 9.5 Repository Validation: Java
  • 9.6 Repository Validation: Javascript
  • 9.7 Repository Validation: Validation Bean
  • 9.8 Endpoint Validation
  • 9.9 Packages and Implementation Guides
  • 9.10 Package Registry Endpoint Module
  • 9.11 Remote Terminology Services
  • 9.12 Suppressing Messages
  • 9.13 Validation Performance
  • 9.14 Automatic Provenance Injection
    • 9.5    Repository Validation: Java   
       Table of Contents

    Repository Validation

    9.4.1Repository 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

    9.4.2Validation 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.

    9.4.3Methods

     

    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:

       9.3    Conformance Data
  • Validation and Conformance
  • 9.0 Introduction
  • 9.1 Validation Support Repository
  • 9.2 Validation Support Repository Options
  • 9.3 Conformance Data
  • 9.4 Repository Validation
  • 9.5 Repository Validation: Java
  • 9.6 Repository Validation: Javascript
  • 9.7 Repository Validation: Validation Bean
  • 9.8 Endpoint Validation
  • 9.9 Packages and Implementation Guides
  • 9.10 Package Registry Endpoint Module
  • 9.11 Remote Terminology Services
  • 9.12 Suppressing Messages
  • 9.13 Validation Performance
  • 9.14 Automatic Provenance Injection
    • 9.5    Repository Validation: Java