• 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.1    Validation Support Repository   
       Table of Contents

    Introduction

    9.0.1Validation

     

    This page describes validation strategies that can be employed with Smile CDR.

    9.0.2Validation Modes

     

    There are two validation modes that can be used to provide data validation in Smile CDR: Endpoint Validation, and Repository Validation. These two modes each have their advantages and tradeoffs.

    Both validation modes use the official FHIR "Instance Validator", which is considered the reference validator for the FHIR standard.

    9.0.2.1Repository Validation

    Repository Validation Mode

    Repository Validation places a validator directly in the FHIR Storage module, where it can be applied to every write operation that passes through the system. This mode has several key advantages:

    • It applies to all sources of data equally. This means that regardless of whether data is being written due to a FHIR REST transaction, and ETL Import job, an HL7 v2.x Listener, etc. you can be sure that the data will be subjected to whatever validation rules you have configured.

    • Because the validator is deeply integrated with the storage engine in this mode, incremental operations such as the Patch Operation can be validated as well. In the case of a patch the target resource will be validated as though the patch had been applied, but before the storage operation actually occurs, giving the validator a chance to block the operation.

    This validation mode applies only to Smile CDR FHIR Repositories, meaning systems where a FHIR Storage module is being used to actually store the FHIR data. It cannot be used with other types of FHIR servers, such as Hybrid Providers or the FHIR Gateway.

    See Repository Validation for more information on this feature.

    9.0.2.2Endpoint Validation

    Endpoint Validation Mode

    Endpoint validation mode involves a validator that is placed inside the HTTP Server module, validating requests as they enter the system. This mode can be used on any FHIR HTTP server module, including FHIR Endpoints that have been paired with a FHIR Storage module, but also modules such as Hybrid Providers and the FHIR Gateway.

    Unlike the repository mode, this mode is only able to perform a superficial validation of Patch Operations. It can validate that the patch itself is valid, but can not provide guarantees that the target resource will be valid after the patch is applied.

    See Endpoint Validation for more information on this feature.

  • 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.1    Validation Support Repository