Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

The SNOMED on FHIR working group (Terminology Binding Stream) have spent some time on trying to identify an equivalence mapping from SNOMED CT for a selection of FHIR Valueset codes, as identified by Grahame Grieve.  The group, consisting of a mixture of SNOMED and HL7 FHIR expertise, have achieved a range of results, which have been classified Red, Amber or Green according to the group's confidence level for each mapping.  See Free SNOMED CT set for FHIR for a more detailed background and notes on each Valueset.  In presenting some provisional work, the mappings are being addressed as follows:

RedDiscussion with SNOMED International (SI) Head of Terminology to consider either inclusion of additional concepts into SNOMED CT, or, confirmation that content should be considered out of scope
AmberDiscussion with appropriate working groups in HL7
GreenForwarding to Grahame Grieve for a first pass review


The following sections list the "Red" mappings where the working group were unable to perform a mapping with any level of confidence, and would like to ask SNOMED International's Head of Terminology Jim Case if he thinks the values listed should either a) be adding to the SNOMED International Edition such that a mapping could then be performed, or b) that they are out-of-scope / not-desirable for inclusion in the International Edition, in which case the working group's recommendation to HL7 would be to continue to use their existing value set.

In addition to the value sets listed below, the working group felt confident that use of SNOMED CT in AllergyIntolerance.Category would not add value to the resource as the mapping that was done was little more than finding matching words.   See also comments from Bruce Goldberg in the parent document.

AdverseEvent.Outcome

Note that relapse is not covered here.  Note the potential for overlap with ConditionClinicalStatusCodes - would it not be better to seek a generic solution across both?

HL7 Value

Suggested SNOMED Term

resolved413322009|Problem resolved (finding)|
recoveringNot Found
ongoingNot Found
resolvedWithSequelaeNot Found
fatal419099009|Dead (finding)| (preferred due to also being a finding ie describes the current state of the patient)
unknownNot Found


Condition.ClinicalStatus

The working group's thoughts here were to  consider enhancing << 394731006 |Problem statuses (qualifier value)|  and possibly include Clinical Groups (eg Nursing) in any discussion about proposed new concepts.  This valueset does seem like its use would go beyond just that of FHIR and may have broader usage.

HL7 Value

Suggested SNOMED Term

ActiveNot Found
..RecurrenceNot Found
..RelapseNot Found
InactiveNot Found
..Remission

Not Found. Note that the use of this value would lead SI to recommend that Condition.code only ever be populated with the plain disorder eg 118600007 |Malignant lymphoma (disorder)| and not try to have the context of status supplied in two places through the use of 427141003 |Malignant lymphoma in remission (disorder)|

Similarly for recurrence - 452241000124100 Recurrent malignant neoplastic disease

..ResolvedNot Found



Response by Jim Case

Taken from April 2019 Business meeting at 00:19:44

Jim: The red value sets are our sets of qualifiers that essentially describe the status of the element within the resource. The issue with some of those is that the same terms are contained within different value sets, but they have different meanings, and so that would require that we add context to all of FHIR to determine how that qualifier is supposed to be used, which is not really what the purpose of a qualifier is. 

Secondly, the values in the valueset are only of use within the context of the binding to the element within the resource. So it's not something that might be analytically collapsed or joined with data from other resources, or other elements within a resource. So because these are primarily qualifier values (and really, the definition is implicitly or explicitly defined within the resource for each of the values), they don't fit into the SNOMED model all that well as qualifier values.  They they look more like fully defined contextual terms that are used in association with an element of the resource.

So the choice is to either:

  •  just provide a qualifier as a word within SNOMED without any explicit definition or implication about how it's going to be used, and allow the context of use to be defined by the element that it's bound to, OR
  • we would have to create fully specified situation type concepts that represent all the context that was implied within the qualifiers themselves, OR
  • we could say that there's really not much benefit in creating four or five terms that are only going to be used in the context of this one element that they're bound to and thus, there's no real benefit in using SNOMED terms to represent them. 

So those are the three options that we have in determining what to do with these these values.

Peter: I know your feelings on not wishing to add more context into SNOMED. Do you have a preference, then, for these valueset items?

Jim: Do I have a preference? Yes, I think because of the nature of the way the terms are being used that there's really not much benefit in adding them to SNOMED, and that they should be local value sets that are defined by FHIR, maintained by FHIR and used by FHIR. 

Update July 2019:

Jim:  While SNOMED International might, in general, wish to avoid adding a large number of context-less adjectives to the qualifier value hierarchy, we have to consider their use in a particular information model - in this case a FHIR Resource. Resource elements provide comprehensive definitions as to their meanings and thus provide adequate context; so that the use of a qualifier value - bound to that resource element - has an unambiguous meaning. The current hierarchical structure of the qualifier values causes more confusion than benefit. The use of standardized (coded) values in value sets bound to a data element reduces the variability in representation of equivalent values where lexical and language differences exist.

The challenge comes when SNOMED CT users try to find appropriate qualifiers to use in value sets and choose words instead of looking at the location in the terminology to determine the implied meaning. For example, the term "above" is a synonym for the concept 352730000 |Supra- (qualifier value)|, which is a topographic modifier. This then restricts the use of that "word" to a specific context.

If we look at some of the terms requested by HL7, such as "resolved", this could have many meanings, but when it is bound to a specific data element, the intended meaning is clear. It would be unmanageable to try and represent all of the intended meanings of the word "resolved" in SNOMED CT and would provide little benefit to users since the meaning is intrinsic to its use in the information model. The information model itself completes the full semantics of an instance of a data element. Since values from a particular element binding should usually not be mixed with values from another element, there is little risk for erroneous analytical results.

We are never going to stop users from using the same word to mean different things in their implementations, but we can at least provide them with the words they need in a standardized way. However, I do not believe we should go down the path of creating findings, nor do I recommend the use of clinical findings for these types of ordinal/nominal value sets.

As for the hierarchical relationships of qualifier values, these too are context dependent and should not be instantiated in SNOMED, CT since the needed hierarchical relationships would be inferred from the element binding.  This, in essence, means that the definition of the hierarchy within a value set would need to be used for subsumption testing as opposed to relying on the SNOMED CT hierarchy.

See also:

20190601 - Response on free set content addition by Jim Case