Talk:Value Set binding
Versions and Value Set Binding
Harold Solbrig (excerpt from 2/18/2009 e-mail): alue set definition versions (note the word definition, in contrast with the set itself) should not be considered a component of the binding equation. If it is found that they become such, we need to back off and say that value set definition identity is the set. Some of the documentation below may be unnecessarily complex because this component has been factored in.
Jobst Landgrebe (2/19/2009 e-mail response to Harold Solbrig): Do you mean that the binding is agnostic of the version because it takes the value set definition "as is" upon binding? If yes, I agree and we should try to simplify the binding section based on this idea. However, I do not know whether I will have the time to do this in this cycle ... for now, I will keep your idea in the document as a comment.
Ted Klein (2/19/2009 e-mail response to Jobst): Bindings also have an optional 'Version' identifier. This is *NOT* the "version" of the value set definition or expansion! This is used when performing the resolution of the value set definition to properly access the correct version of the code systems involved, and the particular expression of the definition (if it has changed over time). The version identifier of the value set definition is merely a state label to differentiate a definition from a modified definition.
--Hsolbrig 16:20, 19 February 2009 (UTC) This is the very complexity that I had been hoping to avoid. Perhaps this is just an issue of semantics? I would argue that there is nothing that can be said about a value set if you don't know its definition. There are no rules about how little or much a value set definition can change before it is considered a new value set definition, and I don't believe that it would be fruitful to try to make such rules. This means, however, that any meaningful discussion about a value set definition must include the version, which is another way of saying that the identity of a value set definition changes whenever the definition changes. Whether we choose to label two definitions as "VSD A" and "VSD B" or "VSD A R1" and "VSD A R2" is immaterial.
What does matter is what code system versions are used whenever one of these definitions is resolved. By resolved, I mean whenever (a) the definition is used to produce a partial or complete list of valid values (== permissible value + concept identifier) or (b) the definition is used to valid a possible value for an instance of the associated attribute. In either of these cases, we need to record the combination of the value set definition and code system version(s) that were used to answer the question. We could assign this its own identifier, but I wonder whether this might be overkill, as the typical answer would be one value set definition name and one code system version identifier.
Alan Honey (2/19/2009 e-mail in response to Ted and Harold): Maybe I am missing something, but there seems to be a level of complexity in this discussion that I just don't see as necessary. Maybe as Harold points out it is an issue of semantics. To separate out the points as I understand them:
Alan 1) Some terminology clarification. I am assuming each "concept" can have a "code value" (i.e. the "l", "CA", "uk", "m", "M" or whatever), and one or more "designations" which give a language specific rendering of the meaning (basically "names"). In some (very rare) cases, the actual code values may have synonyms (in the oft quoted UCUM upper and lower case code values) - but these are not different "designations". Is this right? If so...
--Hsolbrig 19:45, 19 February 2009 (UTC) I try to avoid the use of the word "concept" whenever possible, as it can have so many different meanings. Referring back to the marked up 11179 diagram, I would argue that a value set represents a collection of "permissible value" / "value meaning" tuples. A permissible value must be unique within the context of the value set, and, in the HL7 world, value meaning is represented by a globally unique identifier. A globally unique identifier is typically constructed by combining an identifier for a code system and an identifier that uniquely references a "concept" within the context of the code system. In the CTS and LQS models, this identifier within the code system is called "code", but the latest UML models seem to have assigned the term "code" a slightly different meaning.
Normally the permissible value is usually the same as the identifier within the code system, but this isn't always the case. Exceptions include:
- Situations where two or more permissible values map to the same unique identifier (e.g. "K" and "k" in units of measure prefix)
- Situations where there is more than one code system with overlapping identifier namespaces (e.g. "M" in administrative gender and "M" in marital status)
- Situations where the permissible values are dictated by other organizations or standards bodies
- Situations where the code system doesn't practice good hygiene. (see the Common Practices document for details)
Alan 2) Do Value Sets have "versions" or is each change an entirely new different value set? At a conceptual level I would agree with Harold that you can do this either way and neither is "wrong". At a practical level, the notion of allowing changes to be represented as versions seems reasonable to me, and so from a practical perspective, CTS II needs to support the "ability" to be able to deal with and handle different versions. Different situations/agreements/implementations can easily constrain things to single version only as appropriate.
--Hsolbrig 19:45, 19 February 2009 (UTC)* What do you mean by "value set"? We have the value set definitions and value set resolutions. The latter, at bare minimum, depends on the version of the code system(s) that are used to resolve the definition. If we are talking "value set definitions", I'm not sure I would agree with your use of the word "practical". On the surface, it seems that this should happen, but the amount of complexity that it potentially introduces is anything but practical. That said, I have no problem with the identifier of a value set definition being a name plus a time stamp. We need to understand, however, that the name (or OID!) by itself lacks attributes beyond the simple fact that it has versions.
Alan 3. Value Set Definition vs Value Set Resolution. I still don't understand this. I thought the "definition" was the expression of the set of rules and metadata for a value set (or value set version). In the case of extensional, this included explicitly listing the named "concepts", i.e. the actual codes themselves. In the case of intensional, it defined a set of rules which could be executed at any given point in time to return a list of Concept Codes (and also designations - see below?). In the discussion, there seems to be an intent to restrict the nature of the rule expression, when I dont see the point in doing so. Surely it needs to be able to "resolve" to ANY combination of 1 or more: Code Systems, Code System Versions, Concept Codes, Designations. So if the value set definition "needs to" refer to a code system version, then it should, if it doesnt then it doesnt. It could also be "point in time" based, i.e. whatever version is extant at point x without explicitly referencing the version. I dont really understand why we would constrain this more than necessary.
--Hsolbrig 19:45, 19 February 2009 (UTC) I, in turn, am not certain why you wish to differentiate a statement that "Value Set A contains "M", which maps to unique identifier 2.16.840.1.113883.6.1:M" and "Value Set A contains "M" which maps unique identifier 2.16.840.1.113883.6.1:M as well as any codes and unique identifiers that are subtypes of 2.16.840.1.113883.6.1:M". They both seem like rules to me. More importantly, they both need to be resolved against a specific version of a code system, as "2.16.840.1.113883.6.1:M" may have been retired since the value set was defined.
I see a need to state a minimum set of possible rules, but, if you are going to argue against it, I don't see why you would make an exception for "extensional" type rules.
Alan So in my understanding, the notion of "resolution" is only relevant in the intensional case, since the extensional already explicitly defines the code values, unless it is referring to the designations (but why would these also not be explicitly defined? --Hsolbrig 19:45, 19 February 2009 (UTC) I disagree for two reasons. The first is stated above. The second is that there is little or no relationship between the permissible value in a value set and the designation associated with a unique identifier in a code system. If, for instance, I had a transaction that mandated that "Male" be identified by a code of "M117", would this mean that I'd have to go to HL7 and say we need to add "M117" as a designation to administrative gender? What if we were using SNOMED-CT instead?
This isn't saying that you can't do early resolution - a statement that "Value Set A contains "M", which maps to unique identifier 2.16.840.1.113883.6.1:M in version 1147 of code system 2.16.840.1.113883.6.1" is a resolved value set definition. This is equally applicable, however, whether the set just names identifiers or names identifiers and rules for inclusion of additional identifiers.
Alan Related questions:
- Does the extensional definition (by listing the actual Concepts) include or allow explicitly identifying the designations? If NOT, which designations are allowed, is it assumed to be all?
--Hsolbrig 19:45, 19 February 2009 (UTC) I don't believe that it is necessary that a permissible value be a designation. In many cases, it is the unique identifier. In other cases, we have no control over the target code system, so we can't make it a designation whether we want to or not.
Alan
- Similarly, for intensional value sets, I am assuming that the rules need to be able to "resolve" to a set of codes and/or a set of code designations.
--Hsolbrig 19:45, 19 February 2009 (UTC) Same answer.
Alan Overall, I don't understand why the "code" is seen as "definition" and the "designation" seen as resolution.
--Hsolbrig 19:45, 19 February 2009 (UTC) I don't either. Further discussion needed.
Alan I am also assuming that "permissible value" as expressed by Harold is the designation - is this correct? --Hsolbrig 19:45, 19 February 2009 (UTC) No. See above.
