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

For example, 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.

The proposed change is to add:
* ConceptMap.group.element.valueSet and
* ConceptMap.group.element.target.valueSet

Both would be of type uri and have cardinality 0..1

see zulip discussion: https://chat.fhir.org/#narrow/stream/terminology/subject/ConceptMaps.20targeting.20ValueSets