Stream: terminology
Topic: Concept Maps and terminology operations
Grahame Grieve (Aug 10 2017 at 23:14):
In the past few days, I've been discussing the use of concept maps in combination with terminology operations with @Michael Lawley
Grahame Grieve (Aug 10 2017 at 23:15):
Here's some requirements:
- expand a value set, and use a conceptmap to translate it before returning it
- validate a code, and specify for the server to translate it before validation
- expand a value set, using subsumption logic from a mapped code system
Grahame Grieve (Aug 10 2017 at 23:15):
other requirements...?
Jim Steel (Aug 10 2017 at 23:19):
I don't know much about it, but could fhirpath be useful for this kind of thing?
Michael Lawley (Aug 10 2017 at 23:19):
As a simple building block, being able to $translate a list of codes in a single request (without the overhead of a batch transaction) would help
Michael Lawley (Aug 10 2017 at 23:28):
To provide a specific use-case context for the requirements list, consider a server that has a bunch of Conditions stored which are coded using one or more code systems (call them A & B) for which there also exist maps A -> SNOMED and B -> SNOMED (and the composite map A/B -> SNOMED). What you want to do is retrieve all Conditions with code:below=http://snomed.info/sct|123456 after applying the composite map.
Peter Jordan (Aug 11 2017 at 00:24):
In those use cases, maybe implement the mapping via an Expansion Profile? Returning value sets is definitely more efficient than batching individual translation requests.
Grahame Grieve (Aug 11 2017 at 00:31):
well, the easiest changes here are:
- add a reference to a concept map in ExpansionProfile and as an expansion parameter. Server performs the translation, and blows up if there's no appropriate translation
- add a parameter valueset to $translate, and server returns outcome value set, or blows up if there's input codes that don't have an appropriate translation
... for whatever "appropriate translation" means
Rob Hausam (Aug 11 2017 at 02:33):
I think both of those would be useful additions, and should be fairly straightforward
your third requirement for "expand a value set, using subsumption logic from a mapped code system" probably could be done by leveraging the first one? - I think you should be able to expand an intensional value set based on the subsumption logic and then translate it to the other one
Peter Jordan (Aug 11 2017 at 02:40):
Wouldn't favour making breaking changes to $translate to return a ValueSet rather than a Parameters resource. If you want to pass a ValueSet ("bunch of codes") and receive another ValueSet of translation results then maybe add another operation to ConceptMap such as $convert.
Grahame Grieve (Aug 11 2017 at 04:19):
somehow I feel as though we're going to end up with TranslateProfile (equivalent to ExpansionProfile) and some pipelining mechanism...
Robert McClure (Aug 24 2017 at 14:56):
@Peter Jordan When mapping from one code system to another, I think this has to be a concept (code) by concept activity, do you agree? I think this must be true in all cases - this has been my experience unless one evokes very complicated logic. Given that, I think an operation that delivers the result of mapping should take as input an expansion, not a value set definition.
Rob Hausam (Aug 24 2017 at 15:19):
I think that what Grahame suggested and Peter commented on assumed the presence of ConceptMap(s) with all of the mappings for the individual concepts. We don't have a ValueSetExpansion resource (and we don't necessarily need one), so a ValueSet parameter makes sense, but to be able to process the translations the value set would need to be expanded, so probably we would need to be considering the parameters (ExpansionProfile?) for that. That's my take, anyway.
Peter Jordan (Aug 24 2017 at 20:50):
I agree with @Rob Hausam that we'd need to pass an Expansion Profile reference as an additional, and optional parameter to the $translate operation. @Robert McClure has a purist's perspective that translation is a concept(code) by concept activity, however we have to be aware that in practice there are description-based maps out there, such as the UK Read to SNOMED CT maps, which is why source and target concept descriptions were added to the ConceptMap resource.
Robert McClure (Aug 24 2017 at 21:28):
@Peter Jordan By
description-based maps out there, such as the UK Read to SNOMED CT maps,
You mean for a specific concept from a specific code system, you want to map from one specific description, to another specific description, associated with a concept in a different code system. RIght? If so, then that is just a special case of the basic approach I mentioned - you still need a specified concept on both sides of the map.
Peter Jordan (Aug 24 2017 at 22:05):
Right...and agreed, definitely still need specified source and target concepts. The description-based mapping from Read Codes to SCT was done by NHS Digital, but from an implementation perspective it's all about concepts. In the case of Read, we've added the 2 digit description id to the 5 digit Read Code to form a source code with a single description, but the target code is a 'pure' SCT Concept Identifier because all those descriptions are effectively properties of that code (and we use the preferred term as the target description). That also allows us to persist the map in an RF2 formatted Reference Set.
Last updated: Apr 12 2022 at 19:14 UTC
