Stream: terminology
Topic: Task 11910
Grahame Grieve (Nov 04 2016 at 11:44):
GF#11910 - @Robert McClure I don't follow why you think that this should be an immutable value set, or what you think it means to mark a revision of a value set as immutable
Robert McClure (Nov 04 2016 at 23:08):
What I mean is that when you say that the meaning of a value set is "All codes in code system" then any change would be a breaking change in the meaning. Therefore the value set should be Immutable so no change can occur. This means NO other versions of the value set (no other CLDs) can be created because it would mean a significant change in the scope of the value set definition. Obviously this results in different expansion sets over time.
Grahame Grieve (Nov 04 2016 at 23:15):
I think you have the cart before the horse here. There's 2 different issues:
- should the value set be immutable?
- does it include all codes?
Grahame Grieve (Nov 04 2016 at 23:15):
if you say that a value set is immutable, then you get to ask, can an immutable value set say 'all codes in a version-less system', and what does that mean for immutability. that I understand as a valid question
Grahame Grieve (Nov 04 2016 at 23:16):
if, on the other hand, you don't say that the value set is immutable, why does it matter whether you say that it includes all codes or not between versions?
Grahame Grieve (Nov 04 2016 at 23:16):
I fail to see why saying 'all codes' suddenly means 'must be immutable'
Grahame Grieve (Nov 04 2016 at 23:16):
unless you are going to claim that all value sets must be immutable, which we won't be coming to agreement about
Rob Hausam (Nov 04 2016 at 23:42):
I think that the two notions of "all codes" and "immutable" are independent. You define a value set with a particular purpose (scope) in mind, and the VSD reflects that. If a definition of "all codes" is the proper fit for that scope, then that's how you define it. But if the code system changes over time and "all codes" no longer is the best fit for that scope, then you would want to make a change to the definition accordingly. So, declaring the value set to be "immutable" at the outset would be both unnecessary and counterproductive for that case. That's the way I'm seeing it, anyway.
Robert McClure (Nov 06 2016 at 00:26):
We are talking past each other. Rob is close. The intended scope of the value set is what the value set definition (the CLD) is focused on, that definition is almost always an approximation because it's pretty hard to make sure you have every concept that meets the scope, particulary as the code system changes. So we have versioning to allow the definition (the CLD) to change over time so the code system query (the definition - the CLD) produces the best scope-matching expansion set possible. When you create a value set that has a scope of "All concepts in the code system” then the CLD will be "All concepts". To make sure no one screws that up, the value set should be immutable so the CLD, the definition, can never change because it’s perfectly accurate as is.
Now, if your scope is something different than "All codes in this code system," like "Any code that is a location” but you have a situation where the code system only includes location codes, you would not make that value set Immutable even though the CLD for the version available might say "all codes in the code system" because in this case the scope is NOT all codes in the code system, it just turns out that the CLD is.
So to clarify, a value set that has as its scope "All codes in the code system" should be immutable. This is true for all the value set = code system you make for your FHIR code systems.
It makes no difference if the code system is versioned or not IMO. I'd make all of these ACTIVE ONLY = F but you could choose to make one with and one without, both immutable.
Lloyd McKenzie (Nov 06 2016 at 14:04):
The purposes of a valud set shouldn't (usually) be "all codes from code system x", it should be "all codes appropriate for use in circumstance y". Let's say there was a code system whose sole purpose was conveying drug codes. Then after 5-10 years of operation, the responsible organization expanded the value set to include a subset of devices too. It'd be perfectly reasonable to change the value set that used to say "all codes from code system x" to say "all codes from code system x, less this particular subset of codes dealing with devices". The only time you'd want to make a value set immutable is if the purpose of the value set was intrinsically tied to the code system rather than tied to some other use-case. There certainly are such circumstances, but I don't think you can infer them by how the value set happens to be defined.
Grahame Grieve (Nov 06 2016 at 22:28):
I agree. these are orthogonal issues
Robert McClure (Nov 06 2016 at 22:37):
Glad you agree. So you should make all the value sets you have created that exist to have expansions that include all the codes in the code system IMMUTABLE. This is also true for many of the HL7 value sets that exist to mimic a code system that has been created for one specific purpose that directly aligns with a model element need therefore the value set bound to has a scope "all the codes in code system" because the code system exists solely to meet the need of that model element.
For situations these are not true, then don't make them IMMUTABLE.
Grahame Grieve (Nov 06 2016 at 22:38):
I agree with Lloyd, and disagree with you.
Grahame Grieve (Nov 06 2016 at 22:39):
and I don't even understand why including all the code system is related to immutability. As for the definition of the element, when we have immutable element definitions, then it would make sense to have immutable value sets
Robert McClure (Nov 06 2016 at 23:04):
Sorry Graham but I've been very clear. Immutable occurs when the value set scope is such that no change in the CLD/definition should occur. I have no idea why this is so difficult for you. Let's make this a disucssion point for a vocab call.
Grahame Grieve (Nov 06 2016 at 23:13):
ok. fine. When no change to the CLD should occur, the value set is immutable. That's obvious. But what the rest of us don't understand is why using all of a code system means that no change should occur.
Grahame Grieve (Nov 06 2016 at 23:14):
in fact, I think you're just wrong: if the value set is immutable, and the value set uses all codes in a code system, then the code system has to be immutable, or the code system reference has to be fixed, or the value set is in error. Sorry
Michael Lawley (Nov 07 2016 at 01:43):
There does seem to be some misunderstandings going on here: I think @Robert McClure is talking about immutability of the CLD, but not immutability (constancy) of the expansion. Following this, some instances where the CLD is "all codes in code system" should be immutable, but in other cases this might only be a convenient way to express the CLD at a point in time, but it may not always be the correct way to express the CLD.
@Grahame Grieve seems to be saying that if the CLD is "all codes in code system (no version)" and the valueset is immutable then this also requires the expansion to be constant (immutable) and thus the code system must be immutable, but I don't follow this line of reasoning; the immutability flag references the CLD, not the expansion.
Robert McClure (Nov 07 2016 at 02:08):
IF Michael is correct then Graham simply is not reading the prior posts nor has he read the VSD spec. Graham, what is it?
Grahame Grieve (Nov 07 2016 at 02:19):
at the end I was being devil's advocate about the notion that you would freeze the CLD and not the expansion. I'm not sure I follow the utility of that, but I don't feel strongly about that. But I agree with Michale: there are some instances where you want immutability, but @Robert McClure is saying that all value sets the include all a code system must be immutable, and no one else in this thread has agreed that this makes sense
Robert McClure (Nov 07 2016 at 14:26):
@Grahame Grieve Please re-read my 11/4 post. Immutable is tied to the CLD, not the expansion. Immutable exists to communicate to users that the CLD is tightly bound to the scope and no change in the CLD should occur for that value set. When the scope of the value set is "ALL CODES IN THIS CODE SYSTEM" then obviously the CLD should say the same thing. Why in the world would you ever change the CLD to something different if the scope is ALL CODES IN THE CODE SYSTEM???
If this is so confusing then please just move on, it's really not that important.
Grahame Grieve (Nov 07 2016 at 22:51):
well no one else has agreed to what you claim is obvious. And we've provided 2 use cases for why you would change the CLD: 1. it's not immutable in meaning at all. and (b) the code system scope changes.
Lloyd McKenzie (Nov 08 2016 at 03:09):
@Grahame Grieve Immutability has to do with the value set definition, not the expansion. Immutable value sets can easily have different expansions at different times. That said, a valueset that is "all codes from code system X" should only be made immutable if the purpose of the value set is defined as "this value set represents all codes from code system X". If the value set is "all drug codes supported by EHR A", then the value set is absolutely not immutable, even if the value set definition is the same because the definition and purpose aren't intrinsically tied.
Grahame Grieve (Nov 08 2016 at 03:13):
I'm not entirely persuaded. the point of immutability is to manage the contents of the expansion, yes?
Lloyd McKenzie (Nov 08 2016 at 03:33):
No. The point of immutability is to allow trust in referencing the value set.
Lloyd McKenzie (Nov 08 2016 at 03:34):
If I say this value set represents all the codes in ActMood, you want to be sure I'm not going to change my mind later.
Lloyd McKenzie (Nov 08 2016 at 03:34):
But the expectation is that if the set of codes in ActMood changes, the contents of the expansion would change too.
Lloyd McKenzie (Nov 08 2016 at 03:34):
That's how it's been used in v3.
Lloyd McKenzie (Nov 08 2016 at 03:35):
If you just want immutability of expansion, then you declare a lockedDate.
Grahame Grieve (Nov 08 2016 at 03:46):
that wasn't quite what I meant, but I'm going to stop beating a dead horse here. I still don't see any need to say that if a value set includes all codes from a code system, it must be immutable.
Rob Hausam (Nov 08 2016 at 03:50):
Lloyd is correct that immutability refers to the value set definition. If you actually want (for whatever reason) an immutable expansion you would need both an immutable definition and a lockedDate to accomplish that. I think we got into this discussion primarily because GF#11910 refers to "When the CLD is all codes in a code system...", rather than "When the scope of a value set is all codes in a code system...". If we had started out grounding this in the value set scope it would have been clearer. But I can't really imagine that there is much of a use case for value sets with a scope of "all codes in code system x...", as that still doesn't tell you anything about what you want to use the value set of "all codes in code system x..." for. It doesn't say anything about the "Model Context: A statement that describes how this Value Set is to be used in an artifact.", which VSD describes.
Grahame Grieve (Nov 08 2016 at 03:57):
what's the difference between '"When the CLD is all codes in a code system...", and "When the scope of a value set is all codes in a code system..."?
Grahame Grieve (Nov 08 2016 at 03:58):
but I'm happy with if we look at it the other way around: if a code system nominates a value set as the value set that includes all the contents of the code system, then, indeed, that value set must be immutable
Lloyd McKenzie (Nov 08 2016 at 04:12):
"CLD being all codes in a code system" could be definitional - e.g. the purpose of the ActMood value set is to represent all codes in the ActMood code system. In that case, it *should* be immutable. It would be wrong for anyone to ever change the CLD to, say, include some codes from ActClass too. On the other hand, you could have a CLD that said "all codes in a code system" where that *wasn't* the purpose of the value set. It just happened that, at the moment, the purpose was met by all codes from that code system. In the future, the evolution of the code system or the conceptual space could evolve such that only a subset of codes was needed or codes from other code systems would also be needed. So if the CLD is not definitional, then the value set needs to be mutable.
Lloyd McKenzie (Nov 08 2016 at 04:13):
@Robert McClure is assuming that a value set with a CLD of "all codes in a code system" must always be definitional, but that's not the case.
Rob Hausam (Nov 08 2016 at 04:15):
yes - that's the difference
Rob's original statement implied that "all codes ..." is always definitional, and I agree that is not necessarily the case
Rob Hausam (Nov 08 2016 at 04:18):
although I guess we had better be careful about talking what it means for a "content logical definition" to not be "definitional" - what we mean by that, I think, is that the CLD isn't tied definitionally to the value set scope
Grahame Grieve (Nov 08 2016 at 04:21):
ok, so I'm fine to say that if the code system says the value set represents the entire code system, the value set is immutable. I'm fine to update the tools to just mark them accordingly too
Lloyd McKenzie (Nov 08 2016 at 04:24):
I'm a bit confused. The code system says what the value set represents? Shouldn't the value set itself declare what it represents?
Rob Hausam (Nov 08 2016 at 04:24):
I don't think code systems say anything directly about value sets?
value sets reference code system(s), not the other way around
Rob Hausam (Nov 08 2016 at 04:25):
yes - the value set should declare what it represents, along with what code system(s) it draws from
Grahame Grieve (Nov 08 2016 at 04:27):
CodeSystem.valueSet
Rob Hausam (Nov 08 2016 at 04:29):
ok - yes, that's the exception - for the "all codes" case
that one, since it doesn't have anything additional in the scope, logically would be immutable
Grahame Grieve (Nov 08 2016 at 04:30):
yes. so
- if a value set is referred to from CodeSystem.value, it SHALL be immutable, and it SHALL only reference the code system
- otherwise, it is at the discretion of the author of the value set to mark it as immutable
Grahame Grieve (Nov 08 2016 at 04:31):
you'll all be pleased to know that we have not defined either an element or an extension for 'immutable' so we might want to get to and define an extension for it
Rob Hausam (Nov 08 2016 at 04:32):
yes - CodeSystem.valueSet - I think that should work
and yes, looks like we need an extension
Lloyd McKenzie (Nov 08 2016 at 04:35):
I'm ok with that.
Grahame Grieve (Nov 08 2016 at 04:38):
Robert McClure (Nov 08 2016 at 21:10):
Praise Be! We made it home! Yes - agree.
As for how a scope and the CLD intermingle: The scope says what the human author wants the value set expansion to include. The CLD is the operational attempt to get codes that match that scope into the expansion sets. Immutablility is tied to the scope but restricts the CLD when we know the CLD should not change because that would mess up the alignment with scope. Very few situations but your value sets = code system are the classic example. The CLD should not define the scope even though we've been doing that FOREVER. It is the Scope that dictates the CLD, not the other way around. That way we know when we find a concept that fits into the scope and is not identified by the CLD, we should change the CLD to get it in.
Grahame Grieve (Nov 08 2016 at 21:25):
ok. updated task 11910 with a comment linking to this thread
Last updated: Apr 12 2022 at 19:14 UTC
