Cries for Help

One of the disturbing aspects of the HL7 phenomenon is the degree to which so many of those who have strong critical views are reluctant to express these criticisms in public. Here a sample criticism of the HL7 RIM, by a leading healthcare IT specialist in Asia who has given me permission to quote from his email communications, as follows:

It is abundantly clear that V3 is an unnecessarily complex, incoherent and confusing messaging standard while V2 is simple, workable, elegant and deployed at more than 95% of healthcare institutions wherever HL7 is used.

Why not scrap V3 and simply work on improving the V2.x standard (say V2.7)?

...

I am concerned about the growth and proliferation of a meaningless standard because it is fraught with danger and is leading to:
(a) Increase in the cost of Hospital IT implementation
(b) Making coding complex which could lead to errors and thereby lower care of (and even endanger) patients
(c) Increasing the cost of software
(d) Increasing the cost of training and implementation
(e) Forcing the use of two standards in parallel when one could have sufficed
(f) Diverts funds from useful IT apps to feed V3

The only people/groups that could possibly gain from this are:
(a) HL7 org and their collective egos
(b) Trainers who will make money from teaching this "complex" 'new' standard
(c) IT companies that make money from pushing newer versions and widgets to "upgrade" to V3

SADLY, it is finally the patient who pays (even if it is a govt or insurance run system) while the doctor, who is already overstressed, is made to learn 'new and improved' processes. As a doctor with more than 30 years of practice, this situation is clearly not acceptable to me.

We need to put together a strong official lobby consisting of sane minded people, organisations and vendors to be heard by the US govt and to forcefully close down such (criminally) wasteful activities.

...


Here is another example of a desperate push through a back door: Pushing and converting a perfectly good CCR to a CCD by unnecessarily insisting on a RIM based approach (where none was required) shows desperation to push the RIM, come what may.

It is my personal opinion that there should be no shame in accepting that a certain approach has failed. We are doctors and scientists and accept, humbly, that we do not always succeed. The real shame and loss would come from stubbornly trying to flog a dead horse putting time, money and people at stake, just so as not to declare failure. I say, be brave enough to move on and use the excellent collection of thinkers at HL7 to develop a fresh, focused and simple solution. To try and capture the complete medical domain (present and future) into one core model is not only foolish but also unachievable. We as doctors know that and therefore only focus on our core specialty.

One Last Effort to Save the Concept Orientation

I am grateful to Werner Ceusters for giving me permission to reproduce the following letter, which was sent by him to the HL7 Vocabulary List. The letter expresses Ceusters’ reaction to discussions (appended below) of HL7’s current attempts to clarify its Core Principles, specifically as these relate to the proper use of ‘concept’ and related terms. In sum: The concept orientation, because it encourages a focus on the heterogeneous perspectives of separate groups, is responsible for the extra effort required to connect distinct systems using V2 messages. This very same failed approach was then used as basis for a 15 year project to solve the problems of V2 by creating semantic interoperability in terms of the RIM, and it has led to what is now widely perceived as the disaster of version 3.

*******

On Sat, Feb 12, 2011 at 11:18 AM, Werner Ceusters wrote:

[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:

• 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

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

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?

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

HL7 Clarifies Everything

In my “Beyond Concepts”, published in 2004, I draw attention to a series of problems associated with the widespread use of the term ‘concept’ in knowledge representation circles. I show that the term is rarely defined by those who use it, with the result that it is used with a variety of conflicting and sometimes intrinsically incoherent interpretations, sometimes within one and the same sentence. The resultant problems affect not only human beings but also computer systems, since the latter must rely on  artifacts afflicted with the same incoherence. These problems are now, increasingly, being acknowledged in other circles, for example by the IHTSDO, whose most  recent (2010) release of SNOMED CT provides the following definition  for ‘Concept’:

An ambiguous term. Depending on the context, it may refer to:

1. A clinical idea to which a unique ConceptId has been assigned.

2. The ConceptId itself, which is the key of the Concepts Table (in this case it is less ambiguous to use the term ‘concept code’).

3. The real-world referent(s) of the ConceptId, that is, the class of entities in reality which the ConceptId represents (in this case it is less ambiguous to use the term ‘meaning’ or ‘code meaning’).

As Solbrig and Chute point out:

The term “concept” continues to be used in models to reference categories, classes, universals, individuals and other less well defined artifacts. The fact that this obfuscates the purpose and usefulness of the model itself has already been well documented. Here, we show how the use of the term “concept” as a class name in a model can introduce serious confusion and propose a simple way that such confusion can be avoided. (2009, p. 123) 

It is thus heartening that HL7, too, with its vision of ‘creating the best and most widely used standards in healthcare’ in  a way that exhibits ‘timeliness, scientific rigor and technical expertise,’ should have turned its attention to its own use of the term ‘concept’. In a new draft document on the representation of concepts that has been posted by the HL7 Vocabulary Group we are told that the concept is ‘The fundamental unit of meaning in HL7 with respect to vocabulary’. We are told further that: 

As defined in HL7, “a concept is a unitary mental representation of a real or abstract thing – an atomic unit of thought.”  As such, we have to do some work to make concepts computationally tractable.

A concept, as used in HL7, has two fundamental characteristics (it often has other characteristics that are immaterial to this discussion, such as relationships to other concepts):

    1.  A concept can be identified

    2.  A concept can be represented

The HL7 model of concept covers #1 by having 1..m identifiers each one of which uniquely identifies the concept.  These are required to be easily machine-processable with simple recognition and indexing algorithms.

The HL7 model of concept covers #2 by having 1..m representations, each of which represents the concept in some way.  These are usually human-readable, and may or may not be easily machine processable, but are almost always machine renderable.  For instance, an image, or video, that represents a particular concept would be a representation of that concept that can be consumed by a human being, and likely rendered by a machine, but generally not easily indexed or matched and recognized with 2011 technology.

... The HL7 model defines a group of concepts with their associated identifiers and representations that are handled as a managed collection.  HL7 calls such managed collections Code Systems.  The organizations that publish these often use different words to describe the identifiers and representations in their collection, but they all publish identifiers and representations of the concepts in their Code Systems.

HL7 has been using nomenclature for these for years, and some of it is also widely used in the informatics community – but often used slightly differently.  It has been shown to be unclear how the different words used related to these fundamental characteristic items are precisely defined, and we have not had an easy way to ensure consistency of use.  To make things more challenging, some words that we often use in everyday discussion of vocabulary may be used to mean either or both an identifier or a representation.

The following table attempts to disambiguate this nomenclature we commonly use in HL7:

HL7 Nomenclature Used	Is it an Identifier?	Is it a Representation?	Should it be our preferred nomenclature?
Code	Yes	Sometimes
Term	Sometimes	Yes
Designation	Generally Not	Yes
Concept Representation	Generally Not	Yes
Concept Identifier	Yes	No
Display Name	No	Yes

We conclude from the above that HL7 has a long way to go on the vocabulary front if its existing resources are to advance the sort of precision in use of language that would be required to support the ambitious goal of semantic interoperability in the complex domain of  healthcare. We remain convinced that a helpful step towards achieving this goal would be to abandon entirely the use of the term ‘concept’.