Conformance Data

The following are the definitions of the basic building blocks used for testing FHIR conformance.

StructureDefinition resources

These are the data models to validate against. They contain rules about which data elements are mandatory/forbidden/repeatable/etc., FHIR extensions that can be used, and other structural rules.

CodeSystem Resources

These resources are used to define codes that can be used for coded fields in FHIR. There are several flavors of CodeSystem resources, depending on the "content mode" specified in CodeSystem.content.

• In many cases the codes are defined within the resource itself, meaning that the complete list of valid codes is defined inside the CodeSystem itself. This is called a Complete CodeSystem. When validating a code that is defined in a complete CodeSystem, the validation will fail if the code is not found in the CodeSystem resource. These CodeSystems will have a CodeSystem.content value of complete.

• In many other cases, the set of codes is too large to fit within a CodeSystem resource. For example, the LOINC terminology contains roughly 100000 codes, which could technically be placed into a FHIR resource but in most real world scenarios this would be impractical to do. In other cases, copyright restrictions mean that it is not possible for FHIR to distribute actual sets of codes. For these scenarios, a type of CodeSystem called a Not-Present CodeSystem or alternately called an External CodeSystem is used. These CodeSystems will have a CodeSystem.content value of not-present. For this form, the actual list of codes are loaded into a dedicated set of database tables that exist within the FHIR Storage module database but are separate from the FHIR resource storage. See Uploading CodeSystems for information on how to load terminology.

• A third option is to create a CodeSystem called a Fragment CodeSystem. These CodeSystems will have a CodeSystem.content value of fragment. This form means that the CodeSystem directly contains codes, but only contains a subset of the codes for the given CodeSystem. This can be useful for providing a set of known codes in a system where the complete set is not known, is not knowable (e.g. a grammar-based code system), or is too large to realistically upload in complete form. When validating resources using a code from a fragment CodeSystem, any codes found in the resource but not in the CodeSystem will result in a warning (non-error) message and will not result in a validation failure.

ValueSet Resources

ValueSet resources define a set of codes that may be used for a specific data element within FHIR. This can be tricky to differentiate from CodeSystem resources for someone first learning about the FHIR specification. For clarity (note that the descriptions here do not apply to FHIR DSTU2 or earlier):

• CodeSystem resources define a set of codes. A code can not be defined by a ValueSet.

• ValueSet resources pull some or all codes from one or more CodeSystem resources, and a StructureDefinition will declare that for a given coded field in a FHIR resource, codes should be drawn from a specific ValueSet (this is called a ValueSet binding).

As an example, consider the US Core Observation Lab profile. It declares that the Observation.code field has a binding to the Observation Codes ValueSet, which has a canonical URL of http://hl7.org/fhir/ValueSet/observation-codes.

The Observation Codes ValueSet includes all codes defined in the LOINC CodeSystem. When an actual Observation resource uses one of these codes, it is the URL for the CodeSystem (LOINC in this case) that is included. E.g.:

{
   "code": [\
      {\
         "system": "http://loinc.org",\
         "code": "10888-6",\
         "display": "Lipase [Enzymatic activity/volume] in Urine"\
      }\
   ]
}

Copy

Validation Support Repository Options

Conformance Data

Validation and Conformance

Introduction Validation Support Repository Validation Support Repository Options Conformance Data Repository Validation Repository Validation: Java Repository Validation: Javascript Repository Validation: Custom Validation Beans Endpoint Validation Packages and Implementation Guides Package Registry Endpoint Module Remote Terminology Services Suppressing Messages Validation Performance Automatic Provenance Injection

Repository Validation