Smile CDR v2024.08.PRE
On this page:
   9.0    Introduction
  • 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.2    Validation Support Repository Options   
       Table of Contents

    Validation Support Repository

    9.1.1Validation Support Repository

     

    When validating FHIR resources, the validator needs access to several support functions that provide information to the validator:

    • If a resource being validated declares conformance to a specific Profile (e.g. the US Core Patient Profile), the validator will attempt to locate the StructureDefinition resource corresponding to this profile. This StructureDefinition contains the machine-processable rules dictated by the profile, and tells the validator what it should be looking for.

    • If a Profile requires a field in the resource to use codes from a specific ValueSet, the validator needs to call terminology service operations in order to check that any codes found in the resource being validated are actually valid codes, and are allowed by the given ValueSet.

    Both of these functions are provided by a feature in Smile CDR called Validation Support.

    If you only wish to validate conformance against the base FHIR specification (as opposed to validating against specific Profiles and Implementation Guides) the validator has all of the information it needs built-in. In all other cases (i.e. if any specific Profiles must be validated) you will need a FHIR Storage (RDBMS) module which will play the role of a Validation Support Repository.

    The validation support repository should have all relevant conformance resources (StructureDefinition, ValueSet, CodeSystem, etc.) loaded into it, and will use these resources to provide validation services. In addition, it may have specific terminology loaded in (e.g. LOINC, SNOMED CT, custom project terminology, etc.)

    In most cases, a specific module dependency between the module performing validation and the module providing terminology support must be configured. This module dependency is called Validation Support.

    9.1.2Potential Architectures

     

    The sections below show several architectures that can be used to enable profile validation. The validation architecture you choose will largely depend on the specific problems you are trying to solve and the modules you are already using to solve them.

    9.1.3Single FHIR Repository (RDBMS)

     

    When Smile CDR is operating as a FHIR Repository (meaning that it has a FHIR Storage module paired with a FHIR Endpoint module) and the FHIR Storage module is a RDBMS module, the FHIR Storage module can be used to store both clinical resources and conformance resources. Note that in this case we use the term clinical resources to mean anything that is actively being validated, so this may actually also include resources with a non-clinical function as well.

    In the case that Endpoint Validation is being used, a Validation Support module dependency must be configured between the FHIR Endpoint module and the FHIR Storage module. In the case that Repository Validation is being used, no explicit module dependency is needed.

    Only RDBMS-based storage modules may be used as a validation support repository. If you are using a different storage technology such as MongoDB for FHIR Storage, you will need a dedicated validation support repository as described below.

    Validation Support: FHIR Repository (RDBMS) Architecture

    9.1.4Dedicated Validation Support Repository

     

    When Smile CDR is operating as a FHIR Repository, it is also possible to use a separate FHIR Storage (RDBMS) module as a dedicated validation support repository. If you are using a different storage technology such as MongoDB for FHIR Storage, this is the only option.

    For clarity, this does mean that if you want to use profile validation with a non-RDBMS FHIR Storage module, you will still need a small RDBMS-based FHIR Storage module as well. This secondary storage module is typically quite small compared to the primary FHIR Storage module used for clinical data.

    Validation Support: FHIR Repository (RDBMS) Architecture

    9.1.5Non-Repository Models

     

    For models other than FHIR repository, such as Hybrid Providers and FHIR Gateway

    When Smile CDR is operating as a FHIR Repository, it is also possible to use a separate FHIR Storage (RDBMS) module as a dedicated validation support repository. If you are using a different storage technology such as MongoDB for FHIR Storage, this is the only option.

    For clarity, this does mean that if you want to use profile validation with a non-RDBMS FHIR Storage module, you will still need a small RDBMS-based FHIR Storage module as well. This secondary storage module is typically very small compared to the primary FHIR Storage module used for clinical data.

    Validation Support: FHIR Repository (RDBMS) Architecture

       9.0    Introduction
  • 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.2    Validation Support Repository Options