Stream: terminology
Topic: Feedback requested on proposed change to valueSet invariant
Robert McClure (Jan 27 2021 at 00:50):
Invariant vsd-1 when created was intended to require that within ValueSet.compose.include when a valueSet.compose.include.valueSet reference exists, ValueSet.compose.include.system should not be populated. In other words the invariant was intended to be an exclusive OR between valueSet.compose.include.system and valueSet.compose.include.valueSet reference. This is noted in Jira 30585. We are concerned that some users may have misinterpreted the “or” in the Description and the Expression as the non-exclusive (intersection) type or that exists in the Expression. The intent in R4B is to change both the description and the Expression to clarify that this is indeed an XOR.
We are seeking input from the community to determine if anyone has real use cases where the current non-XOR approach is needed. If such a use case exists we also need to understand how this was implemented. There appear to be two potential choices:
- The valueSet.compose.include.system (potentially with version) restricts the included members from the referenced value set to only the expansion members that match the system+/-version.
- The valueSet.compose.include.system (potentially with version) forces the included expansion members of that system from the referenced value set to match the system+/-version, but does not exclude expansion members from other code systems.
We intend to make this change to XOR in R4B as a clarifying change but due to it technically being non-conformant, we need users to contact us with concerns by replying to this thread.
@Lloyd McKenzie @Grahame Grieve @Peter Jordan @Michael Lawley @Andrea MacLean @Jim Steel @Dion McMurtrie @Bryn Rhodes
Michael Lawley (Jan 27 2021 at 04:10):
We used the machine-readable definition: valueSet.exists() or system.exists() as the basis for our implementation specifically to avoid the ambiguity surrounding natural-language use of "or".
The semantics we implemented follows the rule "Within an include, all the criterion apply -e.g. the value set contains the intersection of the criterion". Thus we restrict the expansion to just those members that match the system+/-version.
If a version is specified, then it may also influence any default version selection (i.e., where the $expand call and other uses of the same CodeSystem do not specify a version).
Michael Lawley (Jan 27 2021 at 04:12):
I would like to understand the motivation for making this change. Granted, the spec may not say what was originally intended, but there's a perfectly reasonable and clear semantics driven by the rule "Within an include, all the criterion apply -e.g. the value set contains the intersection of the criterion", so why suddenly make currently legal things illegal?
Michael Lawley (Jan 27 2021 at 04:16):
It is also a pretty convenient way of sub-setting an existing multi-system ValueSet.
The alternative would be to just add an additional include.valueSet URI using the "all codes in the CodeSystem" valueSet and you should get the same semantics.
Michael Lawley (Jan 27 2021 at 04:21):
A further undesirable effect of making this change is that intersecting an explicit list of codes with a ValueSet expansion becomes more cumbersome.
For example, I may have a list of unique codes drawn from clinical data and wish to identify which of these codes belong to a specific ValueSet (perhaps for cohort selection). While I could issue a series of $validate-code calls, it would be much more efficient to construct a ValueSet with a single include.valueSet and include.concepts and then POST it.
Rob Hausam (Jan 27 2021 at 04:25):
Rather than the change that is being suggested, clarifying and making explicit the "within an include, all the criterion apply" rule that @Michael Lawley described would likely be a better (and certainly more compatible) path forward.
Liam Barnes (Jan 27 2021 at 06:22):
We don't have any specific values sets including system and valueSet in the same include but I'd seen it as way to refine a valueSet by a system. This seems a reasonable thing to do.
Robert McClure (Jan 27 2021 at 15:53):
@Michael Lawley So you have chosen one of the two alternative approaches based on this being a intersecting OR, giving "full weight" to the impact of including a single system. To be clear, that was not the intent, hence the motivation. The edge-case use of this is essentially theoretical and "illegality" has nothing to do with it. The only use case I see is the ability to restrict the expansion of a multi-system value set. Are you saying you have real examples of this, or are just musing about the possibility? Your last theoretical advantage makes no sense to me and I don't see how this intersection OR of a system does something to support whatever you want. Of course clarifying the current ambiguous approach is more compatible for Michael, as long as someone else doesn't come in and say they interpreted this the other way.
@Liam Barnes By "refine" which of the alternatives noted in the OP are you referring to?
Michael Lawley (Jan 27 2021 at 21:47):
I wouldn't say we chose, I would say we followed the direction of the spec -- all constrains apply.
Michael Lawley (Jan 27 2021 at 21:49):
More importantly though is the case where you have valueSet, system, AND concepts - this is not an edge case for us
Michael Lawley (Jan 27 2021 at 21:52):
In fact it is the use case analogous to Condition/_search?code:in=http://example.com/myConditionsOfInterestValueSet
Robert McClure (Jan 27 2021 at 22:45):
@Michael Lawley No one would say that an intersection of a set of codes (by enumeration and/or filter) and a value set within one include does not make sense. What is confusing is why you need system too. how does that make it work better?
Michael Lawley (Jan 27 2021 at 23:24):
To specify codes you must have a system -- vsd-2
Liam Barnes (Jan 27 2021 at 23:30):
@Robert McClure I meant the first choice stated, where the value set members are restricted to the stated system.
I interpreted that constraint's purpose to enforce the minimum required for an include to be valid. I.e. Either a valueSet or a System
Michael Lawley (Jan 27 2021 at 23:32):
But, you still haven't answered the question of WHY make this change?
Robert McClure (Jan 28 2021 at 01:22):
@Michael Lawley We were making the change to align with the original intent. We assumed that others had interpreted it as an XOR and put this out to find out. We also would like to understand any use case that bolsters the need for intersectional OR versus the original intent. I understand that it was not specified as XOR originally and it sounds like you got out there and implemented as intersectional OR because that was what it said to do. Totally get that. It is our understanding that others have not. So we need to align. We understand that precedence, even incorrect precedence. needs to be gin due consideration - we have not made a final decision. So to best understand that, please help me understand the answer to
No one would say that an intersection of a set of codes (by enumeration and/or filter) and a value set within one include does not make sense. What is confusing is why you need system too. How does that make it work better?
Michael Lawley (Jan 28 2021 at 06:42):
Right. As I see it then, there are three options going forward:
- clarify the OR semantics as "intersectional"
- clarify the OR semantics as "version-narrowing"
- clarify the "XOR, NOT BOTH" semantics
We have implemented 1., and have ongoing significant use-cases that rely on this semantic, which is also (I argue) directly supported by wording in the spec.
We've yet to see anyone (here) indicate preference for, or implementation of 2.
- says the combination would be explicitly not allowed (what I meant by "illegal" above). As I understand it, this was the original intent, but I don't understand why it is a desirable outcome?
Rob Hausam (Jan 28 2021 at 16:23):
I think it's unclear if #3 was the original "intent". I think it possibly may have been the original "expectation", though never expressed as a requirement, but I'm also not certain of that. I believe that @Grahame Grieve is likely the only person who can (probably) answer the original intent question. But, as I think @Michael Lawley is expressing, even if we can answer the intent question, I'm not sure if now that is or should be the deciding factor or one of the highest priority factors for deciding how we should go forward with this.
Robert McClure (Jan 28 2021 at 19:01):
If we don't get anyone you fights as Michael has, for option #3 XOR, then I'm not going to stand in the way of clarifying vsd-1 means option #1. I'm being honest that I have not understood the use case @Michael Lawley says they "definitely have" because he's not answered my question on why system makes a difference. perhaps it's too obvious to need explaining.
Michael Lawley (Jan 29 2021 at 02:30):
Let's say I'm implementing something equivalent to the FHIR Search request Condition/_search?code:in=http://example.com/myConditionsOfInterestValueSet and I have a set of Condition instances in my database with the unique set of Condition.code values: http://snomed.info/sct#191044006, http://snomed.info/sct#74400008, and http://hl7.org/fhir/sid/icd-10#C94. Then I want to $expand the following ValueSet to see which of these codes are relevant (i.e., are members of the specified ValueSet).
{
"resourceType": "ValueSet",
"url": "http://example.com/query-type-example-vs",
"name": "Query_type_ValueSet",
"title": "Query-type ValueSet",
"status": "draft",
"compose": {
"include": [
{
"valueSet": [
"http://example.com/myConditionsOfInterestValueSet"
],
"system": "http://snomed.info/sct",
"concept": [
{
"code": "191044006",
"display": "Diabetes mellitus"
},
{
"code": "74400008",
"display": "Appendicitis"
}
]
},
{
"valueSet": [
"http://example.com/myConditionsOfInterestValueSet"
],
"system": "http://hl7.org/fhir/sid/icd-10",
"concept": [
{
"code": "C94",
"display": "Other leukaemias of specified cell type"
}
]
}
]
}
}
Michael Lawley (Jan 29 2021 at 02:31):
Our open source FHIR Analytics server, Pathling (https://pathling.csiro.au), uses this pattern to optimise FHIRPath member-of tests.
Grahame Grieve (Feb 04 2021 at 22:35):
I think that the intent was that you would have one or the other. But I can definitely see cases where value set designers choose to use system to ensure that they only get a subset of concepts in the included value set. I myself would say that this is not good design. and I expect that tx.fhir.org wouldn't handle this as @Michael Lawley says his one does, which I agree is what is stated.
So I favor, given that this is normative, #1
Last updated: Apr 12 2022 at 19:14 UTC
