Stream: implementers
Topic: Correct use of ConceptMap source/target
Niek van Galen (Nov 22 2021 at 11:31):
In the Dutch realm, we use ConceptMap resources to map codes from one ValueSet to the other. Mostly used on elements where the FHIR core ValueSet has a required binding but our information models (after this: zib) use a different (or broader) set of (required) concepts.
Our current ConceptMaps all define the zib ValueSet as .source and the FHIR core ValueSet as .target. A way of looking at this is from the perspective of a system that translates from data entered by a user in zib format and exchanged in FHIR format. We also make use of the concept-bidirectional extension to indicate that the mappings can be reversed, or not.
On elements/ValueSets where ConceptMaps apply, we add the permitted-value-conceptmap extension which states:
The source for the concept map is the value set the extension appears on. The target is the permitted-value-valueset.
This indicates that the way we design our ConceptMaps now is "the wrong way around". However, this is based on just the comment in the extension. The ConceptMap resource makes no specific statements on source and target.
Before we make the effort of converting all of our ConceptMaps: can someone help us out? We would like to know if there is consensus or any best practices on the use of ConceptMaps for use cases like ours?
Lloyd McKenzie (Nov 22 2021 at 15:43):
@Grahame Grieve
Grahame Grieve (Nov 23 2021 at 06:21):
you know, I'm not sure of the answer to this. I don't recall the discussion around making the definition of permitted-value-conceptmap so directional (and in a way that doesn't really feel right to me either). I expect that I defined it, and early, though it's possible that @Lloyd McKenzie did. Though since he tagged me... probably it wasn't him.
Grahame Grieve (Nov 23 2021 at 06:25):
but also , the 11179 definition of permitted value isn't quite what you're doing. So I wonder whether you should do what you suggest.
Anyway, here's the options I think you have
- ask HL7 to change the definition of the extension (might not be possible - constrained by 11179)
- ask HL7 to define an alternative extension that isn't encumbered by 11179-ness
- define your own extension
- flip your concept maps over
- do what I did in this value set, and have it both ways rather than using the bi-directional extension.
Honestly, I prefer 5. It means that if suddenly you run into a screwy mapping which isn't quite the same both ways, you don't need to restructure. Sure, it's more verbose (less than I thought at first because you also drop the extension URL), but it's also computationally simpler. Are you concept maps so big that the increase in size matters that much?
Grahame Grieve (Nov 23 2021 at 06:26):
though you could do 1|2|3 as well as 5 too
Niek van Galen (Nov 23 2021 at 12:32):
Doing option 5 does make a lot of sense, the increase in size won't matter imho. Thanks @Grahame Grieve, I'll discuss this with the Nictiz team.
Lloyd McKenzie (Nov 23 2021 at 14:42):
If you're not doing 11179, you shouldn't be using permitted-value-conceptmap. It's about converting between "what you share" and "what you store" - which I don't think is what you're doing.
Niek van Galen (Jan 24 2022 at 14:37):
@Grahame Grieve a (delayed) question regarding option 5:
The ConceptMap you mention does not contain a source[x] and target[x]. However, the definition of source[x] states: "If there is no source or target value set, there is no specified context for the map (not recommended)."
I can imagine that source[x] and target[x] are absent because the mapping is bidirectional thus it's hard to point either a source or a target because they can be both, however it would in my opinion be preferable to reference the ValueSets the ConceptMap is designed for. What's your opinion on that?
Also created an example of a bidirectional ConceptMap where source[x] and target[x] ValueSets are not included anymore (which feels a bit odd imho): https://github.com/Nictiz/Nictiz-R4-zib2020/blob/195/resources/zib/terminology/conceptmap-GeslachtCodelijst-to-AdministrativeGender.xml
Grahame Grieve (Feb 07 2022 at 20:58):
@Niek van Galen a (delayed) answer:
That's a reasonable question and I don't really know the answer. But I think we could assume that the source and target are implicitly reversible if the map contains both directions. I don't really like that answer a lot, but I don't have a better one
Niek van Galen (Feb 08 2022 at 08:52):
Sounds like a possible outcome, which we might want to document on the purpose element of the ConceptMap. Can you take this in consideration for the improvement of the ConceptMap resource?
Grahame Grieve (Feb 08 2022 at 10:16):
yes we can but it would be great if you create the task for that and reference this dsicussion
Niek van Galen (Feb 12 2022 at 20:15):
Task is created: https://jira.hl7.org/browse/FHIR-36020
Last updated: Apr 12 2022 at 19:14 UTC
