Smile CDR v2024.05.PRE
On this page:

9.2.1Validation Support Repository Options

 

This page describes various setting that can be applied to the validation support repository in order to control validation.

Note that these settings apply to the FHIR Storage (RDBMS) module that is being used for Validation Support.

9.2.2Validating References

 

The Local Reference Policy setting can be used to control the behavior when validating a reference from one resource to another. This setting should be carefully considered, since validating a reference usually means loading the target resource and potentially parsing it and extracting parts of it. In performance sensitive environments, this can have a measurable effect on throughput, although it does improve the quality of the validation.

This setting should be configured on the FHIR Storage repository whose resources are being validated (as opposed to the FHIR Storage repository being used for validation support, if these are not the same repository).

The following values may be used:

  • NOT_VALIDATED – Don't validate references.
  • VALIDATE_EXISTS – Validate that the reference is valid and the target exists, but do not validate that the target resource is fully appropriate as a target for the reference.
  • VALIDATE_TARGET – Validate that the reference is valid, but also that the target resource is appropriate for the given reference (it conforms to the right profiles, is of the right type, etc.)

9.2.3Handling Missing CodeSystems

 

The Unknown CodeSystem Validation Policy determines what the validator should do if it encounters a Coding in a resource where the CodeSystem (Coding.system) value can not be resolved.

  • GENERATE_ERROR – (default) Add an error to the validation results (will cause validation to fail)
  • GENERATE_WARNING – Add a warning to the validation results (will not cause validation to fail)

9.2.4Handling Multiple Codings

 

The default behaviour for validation of CodeableConcept elements is to validate each Coding within the element, and consider the CodeableConcept to be valid if at least one coding is valid. This means that a CodeableConcept with one valid coding and one non-valid coding will be considered valid in the default behavior. This is generally desirable, but may cause problems in certain scenarios.

In some scenarios, it may be more desirable to consider the CodeableConcept as valid only if all Codings pass validation.

One example is a Patient message containing two communications languages, one incorrect (en_US) and the other correct (en), which is POSTed to {Smile CDR URL}/Patient/$validate:

{
    "resourceType": "Patient",
    "name": [
        {
            "family": "Doe",
            "given": [
                "John"
            ]
        }
    ],
    "birthDate": "1912-04-14",
    "communication": [
        {
            "language": {
                "coding": [
                    {
                        "system": "urn:ietf:bcp:47",
                        "code": "en_US",
                        "display": "US English"
                    },
                    {
                        "system": "urn:ietf:bcp:47",
                        "code": "en",
                        "display": "English"
                    }
                ]
            }
        }
    ]
}

The response would contain the following issue:

{
   "severity": "error",
   "code": "processing",
   "diagnostics": "Unknown code 'urn:ietf:bcp:47#en_US' for in-memory expansion of ValueSet 'http://hl7.org/fhir/ValueSet/languages'",
   "location": [
       "Patient.communication[0].language",
       "Line 15, Col 14"
   ]
}

This contrasts with what happens with a request containing a single incorrect language: en_US:

{
    "resourceType": "Patient",
    "name": [
        {
           "family": "Doe",
           "given": [
              "John"
           ]
        }
    ],
    "birthDate": "1912-04-14",
    "communication": [
        {
            "language": {
                "coding": [
                    {
                        "system": "urn:ietf:bcp:47",
                        "code": "en_US",
                        "display": "US English"
                    }
                ]
            }
        }
    ]
}

In this case, the smilecdr response would contain the following, which contrasts sharply with the first scenario:

        {
            "severity": "information",
            "code": "processing",
            "details": {
                "coding": [
                    {
                        "system": "http://hl7.org/fhir/java-core-messageId",
                        "code": "Terminology_TX_NoValid_3_CC"
                    }
                ]
            },
            "diagnostics": "None of the codings provided are in the value set 'Common Languages' (http://hl7.org/fhir/ValueSet/languages|4.0.1), and a coding is recommended to come from this value set) (codes = urn:ietf:bcp:47#en_US)",
            "location": [
                "Patient.communication[0].language",
                "Line 15, Col 14"
            ]
        }

If you want to require all Codings within the CodeableConcept to be valid in order to consider the CodeableConcept valid, you may set the Accept All Codings Only setting to true (the default is false).

After setting this configuration to true, the response to the first two communication language request above will contain:

{
   "severity": "information",
   "code": "processing",
   "diagnostics": "None of the codings provided are in the value set 'Common Languages' (http://hl7.org/fhir/ValueSet/languages|4.0.1), and a coding is recommended to come from this value set) (codes = urn:ietf:bcp:47#en_US, urn:ietf:bcp:47#en)",
   "location": [
      "Patient.communication[0].language",
      "Line 15, Col 14"
   ]
}

9.2.5Code Display Mismatch Policy

 

When storing and communicating coded fields, it is generally a good idea to transmit the concept display name as well as the actual code. This is helpful for consumers of your data because it allows them to display meaningful text to users even if they do not have the given CodeSystem locally available in their own system.

In this context, coded fields refers to the datatypes CodeableConcept and Coding. The code datatype is also used to convey coded elements, but it does not allow for a display name, so it is not relevant here.

When validating these coded fields, it is a good idea to ensure that the display name is actually correct for the given code. The Code Display Mismatch Policy determines how strict the validator should be in validating these display names.

If the coded element being validated does not have a display name present, this is treated by the validator as if the display name is correct (i.e. no error is generated), unless the profile being validated explicitly requires a display name to be present.

The options for the Code Display Mismatch Policy setting are:

  • ERROR – If the display name is not correct, an error is generated. The concept is considered to be invalid, and additional errors may also be raised if the profile requires a valid concept from a specific ValueSet.
  • WARNING – If the display name is not correct, a warning is generated. If the concept is otherwise valid for the ValueSet being validated against, no further errors are generated.
  • INFORMATION – No validation messages are emitted even if the display name is not correct.