A tracker item has been created to clarify the behaviour of $validate-code
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17218
This came from a discussion of the ambiguity regarding the validation that should be done for the display term. For SNOMED CT for example, should this return true (i.e. valid) if the term provided to $validate-code matches
- the term specified in the ValueSet, if provided?
- the preferred term? If so, in which language reference set?
- any of the acceptable synonyms? Again, if so in which language reference set?
- any of the active synonyms?
- any active description? (i.e. any active synonym or FSN)
- any description, current or historic?
This comes partly down to the use case for performing this validation. Validating a code against a ValueSet makes sense to determine if someone has sent a valid code for the binding.
Validating the display is perhaps a bit more subtle. The most obvious use case is to validate if it is likely there is a mistake or not. For example it may be useful to know if a coded element's display term matches the code in the terminology as confirmation.
- code = 387517004, term = Paracetamol - matches preferred term
- code = 387517004, term = Acetaminophen - not the preferred term, but still a valid term
- code = 387517004, term = Amoxicillin - a mistake has probably been made!
In the above case it is useful to know from $validate-code whether the term is a valid description for the code - at least all active descriptions. Receiving the FSN as the display is perhaps odd, and probably wrong (wouldn't imagine many clinical systems where it is valid for it to be the display term), but not unsafe (it is supposed to be unambiguous) and still useful for validation/confirmation.
In this scenario, requiring the specified term to be the preferred term is problematic - which language reference set is the first problem, but also if the version of the code system being used isn't specified it may not be possible to determine the right value even if the language reference set is known. Similarly if the version of the terminology isn't known, then matching inactive descriptions may be useful when dealing with old versions...but then descriptions are inactivated for a reason.
Perhaps a ternary valued response of "valid", "matches inactive description", and "invalid" would solve this issue...but adds complexity for something that is perhaps an edge case.
Questions
- what are the use cases for $validate-code involving validating the term?
- based on that, what should be considered "valid" for an input code and term generally for a FHIR CodeSystem and ValueSet combination?
- then specifically, for SNOMED CT what should the interpretation be and is any supporting clarification necessary in the Using SNOMED CT with FHIR page?
Group Discussion
26 June 2018 - Basically we really need to know what SNOMED Edition is being used, then we can come up with sensible behaviour.
In general, valid codes should return "valid = true" and term issues should be identified as a warning in the message. Any matching term should result in positive validation.
RH: If we had an option to specify a "strict" flag, then we could validate the term in a more exacting way.
DM: Developers want finer grained responses to enumerate the validation result of the term, distinct from the code. Ontoserver currently validates the term if it's either the PT or FSN. If not specified, the latest "default" edition for the server is used ie AU langrefset. Note: Potential to make two calls - one without the term to check the code and then another with the term to check that also.
PJ: The value-set will define the language used, but this would not apply when validating against the code-system.
If the URI that is passed is an edition, then hopefully we could look up a default (set?) of language reference sets.
Case sensitivity: To be discussed.