Stream: terminology
Topic: ConceptMaps targeting ValueSets
Michael Lawley (Feb 28 2018 at 03:00):
For secondary use of data it is common to want to map large sets of clinical codes to a small number of category/classification codes. Currently the only way to express these maps is to explicitly enumerate all the correspondences. However, it may be that these large source sets can be efficiently / succinctly described in a ValueSet with a few inclusion/exclusion filters. Having to then effectively expand this ValueSet to enumerate the mapping is inefficient and a potentially significant maintenance burden.
What we'd like to be able to do is have a ConceptMap whether the source and/or target (ConceptMap.group.element and/or ConceptMap.group.element.target) can be a ValueSet reference (URI) instead of a code
Michael Lawley (Feb 28 2018 at 03:03):
As a simple example, you could easily express that a parent code and all of its descendants map to the same target in just one entry
Richard Townley-O'Neill (Feb 28 2018 at 03:12):
Should
(ConceptMap.group.element and/or ConceptMap.group.element)
be
(ConceptMap.group.element and/or ConceptMap.group.element.target)
?
Michael Lawley (Feb 28 2018 at 03:19):
yes, corrected :)
Robert McClure (Feb 28 2018 at 22:03):
@Michael Lawley this makes a lot of sense to me.
Michael Lawley (Feb 28 2018 at 22:33):
Excellent, I’ll start putting together a Gforge ticket for a specific proposal
Rob Hausam (Feb 28 2018 at 23:02):
Yes, that would be good. How often do you think you (or anyone) will want to have a parent code and all of its descendants map to the same target (a single concept, I presume)? Of course that will be needed at times, but I'm not sure how often. I assume you probably have some other more complex cases in mind? And I guess I can wait for the tracker to find out.
Michael Lawley (Feb 28 2018 at 23:11):
Very often in fact. Of course there are other use cases with more complex or curated ValueSets, but it’s a major thing when going from clinical data to secondary use contexts
Grahame Grieve (Mar 01 2018 at 01:23):
so the question is whether this is solvable by adding a 'and descendents' flag - which seems like a pretty common use case to me, actually. Or whether there's more that is needed
Michael Lawley (Mar 01 2018 at 03:42):
More is needed, definitely. The descendants use case is just a simple one, but normally a ValueSet will be required, eg to exclude one or two selected concepts from a descendants query, or because there's already one or more code lists (ValueSets) being maintained in another context that describe the mapping
Rob Hausam (Mar 01 2018 at 03:45):
Do you have one or more specific examples that you can share?
Michael Lawley (Mar 01 2018 at 04:02):
Sure, consider a secondary use where you need to report whether or not a patient has diabetes. This would by type 1 / 2 but not gestational, and the source data is SNOMED codes. In this case you might have a ValueSet that is all descendants of Diabetes mellitus, but excluding Diabetes mellitus in remission and its descendants as well as excluding Gestational diabetes mellitus and its descendants. These would map to YES. You might then map No abnormality detected and its descendants to NO, with unmapped giving a null flavour. (Although I may be over cooking the example by going for a three-valued logic instead of just YES/NO.)
Michael Lawley (Mar 02 2018 at 04:33):
Task created: GF#15687
Nicholas Oughtibridge (NHS) (Mar 05 2018 at 08:10):
Michael is spot on.
Its really important to have richness in the expressivity if these maps. We want to dramatically reduce the clinical burden of providing information to politicians, managers and regulators and expressive maps are a key component. We either do this within the FHIR environment or as a bolt-on afterwards with all the challenges that leads to.
A particular use case will be for subscription to published message flows to meet privacy concerns. If we can tie secondary use of the care data to a specific legal purpose we can avoid subscribing to data we don't need which removes a critical barrier to taking the data we do need.
Last updated: Apr 12 2022 at 19:14 UTC
