Smile CDR v2023.05.PRE
On this page:

9.2Validation 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.1Validating 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.2Handling 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.3Handling 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"
                    }
                ]
            }
        }
    ]
}

Then smilecdr response would contain the following segment:

{
   "severity": "error",
   "code": "processing",
   "details": {
       "coding": [
           {
               "system": "http://hl7.org/fhir/java-core-messageId",
               "code": "Unknown code 'urn:ietf:bcp:47#en_US' for in-memory expansion of ValueSet 'http://hl7.org/fhir/ValueSet/languages'"
           }
       ]
   },
   "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"
            ]
        }

To make the behaviour more consistent, we have introduced a configuration: accept_all_codings_only, which defaults to false.

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

{
   "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, urn:ietf:bcp:47#en)",
   "location": [
      "Patient.communication[0].language",
      "Line 15, Col 14"
   ]
}