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/19 So - I think you are agreeing with me other than not liking the use of the term Concept?

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 - 2/19 I mean the "definition". I dont see why this is so complex. Versioning in this way is a fairly standard pattern for any class in systems. Going back to my statement about "ability", if anyone sees the need for versions (and on todays call Grahame and others seemed to think there was) then we need to be able to support it. It is fairly easy at an interface level to allow the version to be stated when it is needed to or to default it when not.

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 - 2/19 I apologize. As I hinted in my response to Ted, I phrased things badly, still trying to be semantically roibust myself here. I dont think I am trying to differentiate between the options you state. Firstly I am trying to determine whether a value set is permitted to resolve to a list of "somethings" which includes specific "representations" or is just limited to the "identifiers" or "codes" (I still cannot seem to get an answer to this probably due to my bad phrasing). In the case of "extensional", I had assumed (possibly incorrectly) that by defining an explicit list of codes (in this case without additionally stating anything to do with code system version), then the value set definer is at least allowed to express a wish to use that list of codes without caring what happens to the code system after that point. I am also not trying to argue against rules for the value sets, just that I dont see why the rules "MUST ALWAYS" be tied to a Code System Version, it seems over restrictive at the individual value set level. (Based on todays CTS Call again, seems like we need date based very often for queries in any case)

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 - 2/19 Looks like ther eis still a mismatch in understanding of what a code is vs a designation. In the above, "M117" is called the code and then called the designation. I understoiod a Designation to be a representation of a "name" associated with a code, not the code itself.

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 - 2/19 Ah, I may be seeing what the issue is. I was assuming that when a developer is trying to use a Value Set he/she was trying to resolve primarily to a set of identifiers (codes) and then possibly to one or more additional associated designations for each code. It seems that you may be flattening these or conflating them together into something called permissible value. Is this true?

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.