Validation Support Repository Options
This page describes various setting that can be applied to the validation support repository in order to control validation.
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:
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.
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"
]
}
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: