*******
On Sat, Feb 12, 2011 at 11:18 AM, Werner Ceusters wrote:
[To Ted, Lloyd, Jan and others posting to the HL7 Vocabulary List]
[To Ted, Lloyd, Jan and others posting to the HL7 Vocabulary List]
Allow me to say that I do understand, and so it seems gradually do others who are more deeply involved in the HL7 business than I, what the Core Principles of HL7 V3 are based on: mud and quicksand, precisely because HL7 has been completely built around the gazillion meanings people associate with the term ‘concept’. Trying to narrow these meanings down to just one, and this after thousands of pages of documentation have been written, message templates and specifications produced, is not going to help much. Unless of course the goal is to convince otherwise misinformed decision makers – I do hope indeed that they are misinformed and not accomplices – to get some more industry and taxpayers’ money poured into this never ending story. If you would succeed, and if you would then do a good job of replacing each occurrence of an ambiguous term by one with a unique and precise meaning, then you would see for yourselves that the entire framework is incoherent and inconsistent. But is that worth the money and effort?
This having been said, though, what I never really understood is why you got so deeply involved in this mess. Of course, when designing V3, you were clearly aware of the many ambiguities in the source data that had to be transferred by means of your messages from one information system to another. And you were aware of the many distinct ways in which V2 messages were created over and over again for the same sort of information that they were intended to transmit. And I guess you wanted to solve that problem. I can only imagine that you didn’t realize that the reasons for these ambiguities in source data and for the development of redundant V2 message templates was the concept-orientation. And so you, too, used the concept-orientation around which to build your framework, with consequences that now became clear. You are as far I am concerned forgiven for that. I was myself for a long time a victim of the concept-orientation. And so were, and still are the people trying to work with the mess created by anything coming out of ISO TC 37 in whose work we find conceptology all over the place.
What I could not forgive, however (although, who am I to make such judgments?), is that now that you are finally becoming aware of the intrinsic problems, you continue to follow the same path. Thus stop NOW with V3 and start thinking about V4. I am willing to provide assistance.
Werner Ceusters, MD
Professor, Department of Psychiatry
Director, Ontology Research Group
NYS Center of Excellence in Bioinformatics & Life Sciences
701 Ellicott street
Buffalo, NY 14214
http://www.referent-tracking.com
*********
The context of the above letter is an exchange on the HL7 Vocabulary List that is reproduced below. An early version of the Ted Klein document referred to therein has already been summarized on this blog here.
At 05:15 PM 2/11/2011, Lloyd McKenzie wrote:
Hi Ted,
... Thus far, we've identified 4 distinct uses for concept representations:
Hi Ted,
... Thus far, we've identified 4 distinct uses for concept representations:
- Exchange - A representation intended to represent a concept when persisting data or communicating between two systems (commonly called 'codes')
- Internal reference - A representation intended for use in the development and maintenance of terminology artifacts (commonly called 'concept ids')
- Display - A representation intended to convey the meaning of a concept to humans when the concept is rendered (commonly called 'designation', or (when restricted to text) 'display name'. Sometimes also referred to as 'term')
- Semantic declaration - A representation intended to fully specify the semantic content of the concept (commonly called 'fully specified name')
A given concept representation must have one or more of these uses. In cases where more than one representation may satisfy a given use, it is good practice to designate one of the representations as preferred for that use. In addition, a given type of concept representation within a code system may have a number of characteristics:
- comprehensiveness: Indicates whether a representation of that type exists for every concept expressible within the code system.
- synonomy: Indicates whether it is possible for a single concept to have more than one representation of a given type. For example, multiple codes or display names for a single concept.
- homonymy: Indicates whether it is possible for more than one concept to have a representation with the same type and value. E.g. Display names with the same value for more than one concept.
I would like to see the above represented in the document somehow.
Lloyd McKenzie
Lloyd McKenzie
From: owner-vocab@lists.hl7.org [mailto:owner-vocab@lists.hl7.org] On behalf of W.Ted Klein
Sent: Friday, February 11, 2011 7:43 PM
To: Lloyd McKenzie
Subject: Re: concept representation
Lloyd,
Although I think I agree that all of what you say is true, this is not what I am attempting to solve with this document.
The proximate difficulty is that we were unable, on several calls, to reconcile several negative ballots on Core Principles to the satisfaction of the balloter, and there was general agreement of the participants that clarity was needed. The needed clarity was specifically around what the definition of, and difference between, the words 'concept representation', 'designation', 'concept identifier', 'display name', and 'code' being the specific words in question. The formal motioned request was for me to write a document explaining these words, and include a table that showed clearly their meanings and differences.
I have no interest at this time in attempting to boil the ocean before next Thursday's call. In this particular document, I want *ONLY* to clarify these five words to the satisfaction of the balloter, and get an agreement of which to use consistently in Core Principles. These are the last comments to be reconciled, and I want to be able to begin the narrow redrafting of only those portions that were negative balloted and reconciled; the plan is that all other parts of the document will remain unchanged from the last ballot.
The other ideas that you mention below are all worthy of further discussion, elucidation, and documentation. But I would argue that should be an additional effort, perhaps complementary, to this one. And how much of this conceptual definition needs to be added to this ballot cycle of Core Principles must also be decided (and my prejudice is to add as little as possible beyond the explicit addressing of the specific comments made on the last ballot, since if more than that is added, we are much more likely to fail to pass ballot this round). If we are unable to control our urges to constantly tinker with it before declaring "done for now", we will never pass ballot IMHO.
Ted
Sent: Friday, February 11, 2011 7:43 PM
To: Lloyd McKenzie
Subject: Re: concept representation
Lloyd,
Although I think I agree that all of what you say is true, this is not what I am attempting to solve with this document.
The proximate difficulty is that we were unable, on several calls, to reconcile several negative ballots on Core Principles to the satisfaction of the balloter, and there was general agreement of the participants that clarity was needed. The needed clarity was specifically around what the definition of, and difference between, the words 'concept representation', 'designation', 'concept identifier', 'display name', and 'code' being the specific words in question. The formal motioned request was for me to write a document explaining these words, and include a table that showed clearly their meanings and differences.
I have no interest at this time in attempting to boil the ocean before next Thursday's call. In this particular document, I want *ONLY* to clarify these five words to the satisfaction of the balloter, and get an agreement of which to use consistently in Core Principles. These are the last comments to be reconciled, and I want to be able to begin the narrow redrafting of only those portions that were negative balloted and reconciled; the plan is that all other parts of the document will remain unchanged from the last ballot.
The other ideas that you mention below are all worthy of further discussion, elucidation, and documentation. But I would argue that should be an additional effort, perhaps complementary, to this one. And how much of this conceptual definition needs to be added to this ballot cycle of Core Principles must also be decided (and my prejudice is to add as little as possible beyond the explicit addressing of the specific comments made on the last ballot, since if more than that is added, we are much more likely to fail to pass ballot this round). If we are unable to control our urges to constantly tinker with it before declaring "done for now", we will never pass ballot IMHO.
Ted
At 10:43 PM 2/11/2011, Wittenber, Jan wrote:
I think it’s reasonable to say that the HL7 “ballot” process (as well as in other standards) has some expected value as concerns getting people to pay closer attention so as to get robust vetting, hopefully spiriting out and prioritizing significant issues for further resolution, and this issue fits the bill, since it deals with first principles of a fundamental set of definitions on/with which potentially much will be built. What is “tinkering” in this case?
I think it’s reasonable to say that the HL7 “ballot” process (as well as in other standards) has some expected value as concerns getting people to pay closer attention so as to get robust vetting, hopefully spiriting out and prioritizing significant issues for further resolution, and this issue fits the bill, since it deals with first principles of a fundamental set of definitions on/with which potentially much will be built. What is “tinkering” in this case?
Jan
From: W.Ted Klein
Sent: Saturday, February 12, 2011 8:21 AM
Jan,
What I meant is that we *could* go on and on with deeper and fuller explanations until Core Principles becomes an encyclopedic reference for terminologic representation of meaning. And we would never finish. I want to resist the temptation to do this; the goal of Core Principles is to provide a foundation of understanding the principles upon which HL7 Version 3 is built, not a general explanation of terminology and modeling in computer science. We have been through five ballot cycles trying to get something to 'done', and I recognize that whatever we produce can always be improved. At some point we have to declare it 'good enough for this cycle' and move on to the next update. I do not intend Core Principles chapter 5 to be a general computer science terminology reference; only to illustrate where HL7 is using a subset of general terminology principles, and where it has a unique 'twist' on the more general uses of the technology and nomenclature. The places where we have added general definitions and references (at the request of balloters in earlier cycles) were only to make the text of chapter 5 readable, without constant cited references to external sources. It is intended to be illustrative prose, not a research paper. The document I distributed is intended to achieve agreement so that the redrafting of chapter 5 Core Principles addresses the last cycle negative comments on the use of these five words in a consistent and correct way.
Ted
Sent: Saturday, February 12, 2011 8:21 AM
Jan,
What I meant is that we *could* go on and on with deeper and fuller explanations until Core Principles becomes an encyclopedic reference for terminologic representation of meaning. And we would never finish. I want to resist the temptation to do this; the goal of Core Principles is to provide a foundation of understanding the principles upon which HL7 Version 3 is built, not a general explanation of terminology and modeling in computer science. We have been through five ballot cycles trying to get something to 'done', and I recognize that whatever we produce can always be improved. At some point we have to declare it 'good enough for this cycle' and move on to the next update. I do not intend Core Principles chapter 5 to be a general computer science terminology reference; only to illustrate where HL7 is using a subset of general terminology principles, and where it has a unique 'twist' on the more general uses of the technology and nomenclature. The places where we have added general definitions and references (at the request of balloters in earlier cycles) were only to make the text of chapter 5 readable, without constant cited references to external sources. It is intended to be illustrative prose, not a research paper. The document I distributed is intended to achieve agreement so that the redrafting of chapter 5 Core Principles addresses the last cycle negative comments on the use of these five words in a consistent and correct way.
Ted
No comments:
Post a Comment