Stream: terminology
Topic: Proposal to tighten ConceptMap source and target cardinality
Rob Hausam (Mar 07 2018 at 19:13):
We would like to get implementer community input on GF#14710 regarding tightening the cardinality of ConceptMap source[x] and target[x] to 1..1, and whether there are use cases that have been identified that would support leaving one or both of them as optional at 0..1. Would welcome input from @Michael Lawley and other implementers and potential users of ConceptMap.
Michael Lawley (Mar 07 2018 at 23:06):
What would be the values to use when mapping to/from implicit codesystems (http://build.fhir.org/conceptmap.html#implicit) such as elements in a StructureDefinition or a MedicationResource?
Rob Hausam (Mar 07 2018 at 23:52):
That's a reasonable question. In that section we describe using the canonical URLs StructureDefinition.url and Questionnaire.url and also [base]/Medication as the 'system' (which presumably means to be used for group.source and group.target, as they are intended to refer to code systems). But prior to that in the Scope and Usage section we say: "Mappings between code systems are only defined in the context of the specified source and destination value sets ...". That's not consistent guidance. And I don't think our examples are entirely consistent, either. In the SNOMED CT / ICD-10 mapping example (103) we have the url http://hl7.org/fhir/sid/icd-10-us being used for both targetCanonical, which is intended to reference a value set and for group.target which references a code system. In the Using ICD-[X] Codes with FHIR page that url is specified as representing the code system. Again in ConceptMap Scope and Usage we say: "Note that all code systems have value sets that include the entire code system, and these value sets can be used for mappings that are valid in all contexts". For FHIR code systems we do designate the "all codes" value sets for each code system, which have different urls, but we haven't made that explicit (as far as I'm aware) for many of the external code systems such as ICD-10. Again, it doesn't seem like we're being consistent here. I wonder if it would be best to simplify this by removing source[x] and target[x] entirely and only specify group.source and group.target and allow those to be a reference to either a value set or a 'system' (code system or otherwise)?
Peter Jordan (Mar 08 2018 at 06:19):
ConceptMap.Group currently has a cardinality of 0..*, so that would also need 'tightening' if we are to dispense with source[x] and target[x]. Removing them would also represent a major breaking change and it might be hard to promote the maturity of this resource beyond it's current level of 3 if we made such a change. For example , lots of implementations and test scripts would need to change.
Grahame Grieve (Mar 08 2018 at 07:21):
I don't understand this proposal. the value set and code system references have quite different purposes.
Grahame Grieve (Mar 08 2018 at 07:22):
and i think the guidance is quite right - the context can be associated with a value set, but the mappings are between codes in code systems
Grahame Grieve (Mar 08 2018 at 07:23):
from concept map 103:
<sourceCanonical value="http://snomed.info/id?fhir_vs"/>
<targetCanonical value="http://hl7.org/fhir/sid/icd-10-us"/>
Grahame Grieve (Mar 08 2018 at 07:23):
the first is a value set. the second is a code system, and needs correcting.
Rob Hausam (Mar 08 2018 at 15:29):
@Grahame Grieve I agree that our intent probably is reasonable and the general guidance is correct. I'm not really comfortable myself with tightening the cardinalities. So if we fix some of the issues that I raised earlier, I would be happy with that. For example 103, I don't know that we have a url available for an "all codes" value set for ICD-10-US. Do we? For the ones that FHIR has defined (like this one), presumably we should have a rule that we can use for constructing the "all codes" value set references.
Michael Calderero (Mar 08 2018 at 16:48):
Hi - we just implemented ConceptMap and so far I don't see a use case for leaving either ConceptMap.source[x] or .target[x] blank. I could see a use case where both ConceptMap.source[x] and ConceptMap.target[x] are populated and both ConceptMap.group.source and ConceptMap.group.target are blank. My interpretation of this scenario would mean that when the .source[x] and .target[x] valuesets are expanded all the codes should only belong to one code system. group.source and group.target could then be implied based on those.
Of course, when either .source[x] or .target[x] are expanded and they contain codes from multiple codesystems (because ValueSets can .compose.include other valuesets), then group.source and group.target become mandatory (in my opinion).
Rob Hausam (Mar 08 2018 at 16:54):
Thanks for the input, Michael. That's very helpful. From what you said, I'm presuming that you probably didn't deal with the aspects described in 4.9.7 Implicit Code Systems in your implementation?
Michael Calderero (Mar 08 2018 at 17:17):
I admit we didn't look at that part and didn't consider it. How's a ConceptMap for those supposed to look like?
Rob Hausam (Mar 08 2018 at 17:23):
We don't have examples in the spec for those so far, and we will need to create them. If anyone already does have some examples using the implicit constructs that they can provide (@Michael Lawley, @Lloyd McKenzie, @Grahame Grieve, others?), that would be helpful.
Michael Calderero (Mar 08 2018 at 17:39):
http://build.fhir.org/terminology-service.html#4.6.5 last paragraph says:
Every code system has an implicit value set that is "all the concepts defined in the code system" (CodeSystem.valueSet)...Clients can refer to these implicit value sets by providing the URI for the code system itself.
So can we use this to assert that every code system (including implicit code systems) has an implicit valueset, and we can refer to the implicit code system's valueset by providing the URI for the implicit code system itself? This seems to fall apart when Medication resources are factored in however...
Michael Calderero (Mar 08 2018 at 17:42):
...or probably not if we use [baseurl]/Medication in source[x] and/or target[x]...
Rob Hausam (Mar 08 2018 at 20:33):
Good reminder that we did say that on the Terminology Service page. That's probably the simplest way to make it work, but if we're going to rely on it being available it probably shouldn't only be documented on the Terminology Service page. For many, but definitely not all, code systems we have a separate and distinct url for the "all codes" value set. So, in those cases, would we consider it to be correct to either use the specific "all codes" url or the code system url and and consider them both as legitimate references for the "all codes" value set and handle them in the same way?
Grahame Grieve (Mar 09 2018 at 12:50):
we haven't defined an all codes value set for ICD-10 - presumably that's why the example doesn't use it. I don't think we should allow the code system URI as a proxy for the value set. We haven't done that anywhere else
Carmela Couderc (Mar 09 2018 at 20:39):
Tracker 12314 was entered in October 2016 to loosen the cardinality.
Rob Hausam (Mar 09 2018 at 21:26):
Good pickup, Carmela. I remember it now, but until seeing this I had totally forgotten that we had made a change to relax those cardinalities due to the $closure considerations. That's certainly a valid use case for it, at least the way that $closure is architected now. But possibly we could reinstate the requirements for the cases that aren't involving initiation of a closure table, using an invariant? Or, at the very least we could document that this is the reason for the relaxed cardinality, so that we don't have to re-investigate this when the question comes up again at some time in the future.
Grahame Grieve (Mar 09 2018 at 23:34):
document for now
Last updated: Apr 12 2022 at 19:14 UTC
