The Rise and Fall of HL7

Interfaceware is a Toronto-based HL7 solutions provider whose customers include the CDC, Cerner, GE Medical Systems, IBM, Johns Hopkins Medical, the Mayo Foundation, MD Anderson Cancer Center, Mount Sinai Hospital, Partners Healthcare Systems, Philips, Quest Diagnostics,  the VA, and Welch Allyn.

At 2.57pm EDT today, March 31, 2011 -- on what will surely prove to be a historic day in the advance of healthcare information technology in the direction of reason and light -- Eliot Muir, founder and CEO of Interfaceware, posted the following comment, which I here reproduce in full:

The Rise and Fall of HL7

The title of this post might seem unusual might seem an unusual comment from what is supposed to be an HL7 middleware vendor. But times are changing and that is not where I see our future.

Standards do not exist in a vacuum. To be successful standards must address market needs and solve real problems so people can make or save money.  Writing code costs money. Less than 0.01% of code gets written for free. The majority of code is written by people that are being paid to solve problems with it.

There are plenty of standards which are not worth the paper they are printed on because are are not sufficiently useful or practical.

Complicated standards can be pushed for a while but ultimately markets reject them. Even governments will ultimately reject complicated standards, through a democratic correction process. Although they usually waste a fair amount of other people's money along the way.

So back to HL7. Why was it successful?

Version 2.X of HL7 solved a very big problem for many people in healthcare IT back in the 90's. It replaced a lot of adhoc data sharing mechanisms used in the industry at the time. It gave three points of value. Ironically the first point is one which is not even an official part of the standard.

1. The so called "defacto LLP standard" defined a uniform way to transport HL7 over a TCP/IP socket - this meant vendors could write standard socket implementations to exchange data.
2. The EDI format of HL7 with it's classic | and ^ separators meant vendors could write standard HL7 parsers.
3. The HL7 definitions gave some good suggestions on places to look for data

And that is where the value stops.

It is a lie when a vendor tries to claim they are "HL7 compliant".

The term is meaningless.

The best any vendor can ever do is provide a stream of messages with fields that map adequately to most of the data from their application. HL7 interfaces always end up being a thin wrapper around the structure of the database of the application which feeds them. The standardization comes about because there are common ways of structuring a lot of the data. The pain comes from areas where it is unclear how to structure the data.

There are good reasons for the lack of "standard data models". Technology and society change which means data models must also be changed to best describe new data requirements. Medicine changes. New entrepreneurs come up with clever new solutions and invent ways of using data that improves on old models.

HL7 is working on creating the final solution for healthcare interoperability - the Reference Information Model (RIM) which underlies the structure of version 3 (v3) of HL7.

I think that effort is doomed to fail for these reasons:

1. There is no such thing a single optimal data model to serve all purposes. A formal data model is always going be a square peg going into a round hole. Some problems are best solved by small simple models. There are approximations which work for certain problems but are not valid for others. If there was a single solution to everything then one person would invent it and the rest of us would be out of work.
2. There is substantial academic criticism of RIM that points to the semantic inconsistency within the model itself.
3. It is creating complicated standards which are expensive to implement.

The only organisations spending money on v3 are governments and some big corporations like Oracle that based their health care transaction base (HTB) on it. Oracle salespeople can sell ice to eskimos but I have not heard a lot of great success stories for that product.

Now let us fast forward to what I think will become the future. JSON based web services over HTTPS. Let us look at the benefits:

1. HTTPS with authentication is analogous to LLP - only it comes with authentication and security baked in.
2. JSON - the simplest format imaginable with free parsers in every language and environment, including Javascript which is strategic as the language of the web.
3. JSON data names and values give good suggestions on places to look for data.

Hmmm. Notice something? The value is more than what HL7 offers. In fact a lot more since these are very mainstream technologies that extend far beyond just the healthcare market.

That is why I am not betting the future of my company on HL7. Our value was never really as an HL7 implementation tool. The value our tools provide is the wiggle room we provide for our customers to handle the incompatibilities that occur with real world data. The Iguana Translator is all about making it easy to grab data from anywhere – be it HL7, X12, XML, JSON, databases or web services and making it easy to munch, transform and consume that data.

That is the future I am betting on.

Eliot Muir - CEO of iNTERFACEWARE




Update April 5, 2011


A new comment on "The Rise and Fall of HL7" has appeared at http://blog.interfaceware.com/hl7/the-rise-and-fall-of-hl7/ responding to Elliot's assertion to the effect that "The only organisations spending money on v3 are governments and some big corporations like Oracle":

Rik Smithies

APRIL 5, 2011 AT 10:07 AM

Eliot,

plenty of companies apart from Oracle are “spending money” on the V3 RIM. Here are just a few that are basing their strategy on it (and not just their interfaces):

http://wiki.hl7.org/index.php?title=Category:RIMBAA

Rik

As one might respond: this means that after more than ten years there are some 22 companies with RIM-based products. Are any of these products particularly impressive in nature? Have they demonstrated some exceptional power of the RIM?

An Australian View on HL7 V3

The Australian Health Information Technology blog has posted here a valuable discussion of the item headed Cries for Help published earlier in these pages. This discussion is interesting not least because of the large number of contributions it contains which -- unusually -- are signed by their authors. It seems that, in Australia at least, there are individuals who are willing to commit themselves publicly to a critical position as concerns the HL7 project (where the vast majority of my US informants are willing to have their views communicated only anonymously).

As David More points out in his introduction to the discussion, the implementation success of V3 thus far (and this means after some 14 years of development work) "has been somewhat patchy, with at least some proponents scaling back their enthusiasm for full adoption of the V3 Standard as some see it is lacking the necessary robustness and internal consistency for ongoing use." Dr More goes on to point out that, "While I am not sufficiently across the details of some of this to be able to form a trustworthy opinion a number of very smart people I have chatted with have expressed similar concerns."

In a comment, Grahame Grieve writes on behalf of HL7:

There's no reason for anyone to be afraid to comment. HL7 is not a police state, and there's an endless list of people who criticise and carp. They can expect a vigorous in kind response, but nothing more.

v3/RIM is not perfect. But it's not intended to be an ontology of everything. If only Barry would understand. It's just a model that has some use for interoperability. It's got some go-down-with-the ship type supporters, of course.

As does v2 (and all the other standards - they all have the folks who are going to go down with the ship). It's not enough to say it's simpler. There's more to it than that. The discussion is being had elsewhere, and here is not the place for it. HL7 continues to produce v2 (v2.7 is coming) but the community that is HL7 is switching to v3 because of it's power.

v3 itself does have a patchy record. I'm on record as saying that there won't be another full v3 implementation. People will cherry pick the parts that work - like CDA - and use them as they want.

I've got more to say but it's starting to rain and I'm out in the bush camping. Have a good weekend."

These remarks raise many interesting questions. Grahame asserts that commentators -- whom he divides into critics and carpers -- can expect nothing more than a "vigorous in kind response". Why, then, are so many people reluctant to use their names when commenting critically on HL7? I also fully understand that HL7 V3 is not intended to be an "ontology of everything". Indeed its scope is a tiny, tiny fraction even of the healthcare domain. The problem, as I see it, lies rather on the part of HL7's own advocates when they advance claims for example to the effect that HL7 is "the data standard for biomedical informatics". Such claims give rise in turn to multiple efforts to reinvent various well-functioning wheels in somewhat less-well-functioning proprietary versions inside the walls of HL7. Over time, in result, HL7 becomes ever more complicated, ever more difficult to teach, and ever more difficult to apply successfully. Raising the inevitable question: who benefits from such developments? The following remarks were sent to me by the Asian health IT specialist (henceforth 'S') who was the author of the Cries for Help which originally provoked Grahame's comments:

Grahame (henceforth: G): "v3/RIM is not perfect. But it's not intended to be a ontology of everything. If only Barry would understand. It's just a model that has some use for interoperability. It's got some go-down-with-the ship type supporters, of course."

It's just a model that has some use for interoperability -- That's pretty lame! When a patient's life is on the line "some use for interoperability" is not good enough. The system has to be 100% perfect. Imagine using "some interoperability" to loosely move data across hospitals with the possibility of data errors. The more complex and opaque a system, the more are the chances of errors.And this is simply because it could be almost impossible to detect the tiny but fatal coding flaw that could be hidden under tons of code, trying to helplessly interpret overly complex V3 rules.

G: "the community that is HL7 is switching to v3 because of it's power."

S: What power?!! V2.6 can actually do every thing that V3 does - only more elegantly, simply and transparently.

G: "I'm on record as saying that there won't be another full v3 implementation." 

S: So does that mean that V3 is dead, long live V2? 

G: "People will cherry pick the parts that work - like CDA - and use them as they want" 

S: Why is HL7 diluting it's focus? It's main aim was to create and encourage a messaging standard for interoperability. Than why create a CDA? Why hijack a perfectly good CCR? The way it is going, tomorrow they may think of creating an EMR, EHR and later a HIS all of course based on the RIM!

S continues as follows:

I say, Focus dear friends, focus. Make HL7 simple enough to be easily implementable. And make the HL7 standards more open/accessible. 

On accessibility, this is what I have to say. Have you seen the latest restrictions on use of the HL7 standards? They were restrictive in the past, it has now gotten worse. Today the standard is totally commercialized. You cannot use it to create a professional, usable, realworld (aka 'commercial') app till you pay the HL7 group with a pound of your flesh. You cannot teach HL7 to any one - ditto, share it with a colleague in your hospital? - ditto .

So how does one spread the message of interoperability far and wide, how does one advocate use of the HL7 standard world wide, how does one make hospitals share records, when at each step you are told to cough up money! 

So let HL7 frankly admit that it is in it for the money or go truly open and offer the standards to all like say, LOINC or ICD.

So, in conclusion, here is the true (no hidden agendas) mantra to making HL7 (V2x) a truly international standard.

1. Drop V3, simplify V2x and make it easily implementable

2. Make the HL7 standard truly open by offering it free for use.

Amen...

Readers of this blog are warmly recommended to read the further comments at Australian Health Information Technology, which are of interest especially as concerns the views expressed on the potential implications of HL7 standards for the Australian National E-Health Transition Authority.

Postscript: March 27, 2011

Graham Grieve posted a comment here parts of which are addressed to the above-mentioned A>sian healthcare specialist, specifically:

S: HL7 becomes ever more complicated, ever more difficult to teach, and ever more difficult to apply successfully.

G: Yes. These are all true, and concerning. But complexity is complex. As are committee designed standards. Name a standard that hasn't got more complex over time... 

S: That's pretty lame! When a patient's life is on the line "some use for interoperability" is not good enough

G: oh? Patient's lives are on the line? I'd never thought!

S: Imagine using "some interoperability" to loosely move data across hospitals with the possibility of data errors.

G: To be serious, it's hard to know how to respond to this. There's no context, no ground rules. As for this... "V2.6 can actually do every thing that V3 does - only more elegantly, simply and transparently" I can only assume that the "expert" hasn't implemented both CDA and v2. Perhaps not even read them. Or they have a very peculiar definition of "everything". 

S: Have you seen the latest restrictions on use of the HL7 standards? 

G: Errr, I've not heard that anything changed. What, specifically, has changed? I'm personally against charging for the standards, but developing standards is a costly business that has to be funded somehow. (Do I need to repeat for slow readers that I do *not* speak for HL7?) 

S: So in conclusion here is the true (no hidden agendas)... 

G: No hidden agendas? from an anonymous contributer? I don't even know why I'm bothering to respond.

S himself has now responded, as follows:

This is what I was afraid of ...I have deep respect for every individual who has worked on HL7(including Grahame), but what I have stated is based on 30 plus years of experience, both as a clinician and Healthcare informatician. Further, my knowledge, certification and work on HL7 over the last decade+ qualifies me, I think, to speak on this topic. This kind of blistering "who the hell do you think you are!" kind of a retort, including personal aspersions, are not conducive to scientific progress. If this is not a police state, then what is? This is the very reason for the cloak of anonymity. I have, very simply presented a point of view, and if one were in a responsible position, one should accept criticism and examination of how we could work at improving the usability of the standard.

Please convey to Mr. Grahame my respect for his point of view.I do assure all that I am just as eager as any HL7er to grow HL7 to be a highly usable standard (especially in a way that keeps costs under control. President Obama, I am sure, would appreciate this).I do hope HL7.org is also listening.Good bye. Over and out. End of transmission.

Two comments, received more or less simultaneously:

Dear "S",
Last I heard, police states involve imprisonment, torture and summary execution, whereas in free countries, we both say what we think. Which I do think is what is happening here. 
I'm sorry that you felt my comments were a blistering attack on yourself. I certainly was sarcastic. It's hard not to be, given the circumstances, but I will try hard not to from now on. I don't know how I could make personal aspersions regarding yourself, when I do not know who you are (though I expect that I know you). Now you claim 30+ years of experience, including a decade of HL7, but how could this have qualified your comments when made anonymously without even identifying that fact? You say my response was a "who the hell do you think you are?", when in fact, I want to know, "who are you?" 

Turning from that, I'm happy to work with you to accept criticism and examine how we could improve the standard. Where would you like to do that? Here, or at an HL7 meeting? Or somewhere else?
Grahame 

From S:

I can understand, and see, that Grahame is a true V3 loyalist (I respect that), but unfortunately to the degree that he is perhaps unable (or unwilling?) to look at its fundamental flaws. I really did not want to get into a slanging match with a respected colleague since I believe that is not right. End of the day, we both have strong beliefs - only in different directions. As a professional and a board certified clinician, I do believe that at such a juncture the right thing for gentlemen to do is to discuss and come to an agreement or respectfully agree to disagree.

Thank you Grahame for agreeing to listen to my critique:Here are a few issues that I have with the fundamentals of V3 messaging (CDA not included) vis-a-vis the V2.6 standard. I shall be happy if you can resolve my issues:

(1) One of the strong points of V3 is conformance. Why does V3 bring about 'Conformance' in an extremely opaque, convoluted and complex process (using multiple tools which are proprietary (some open source, some commercial)), when V2.6 can do the same with just use of the standards document and an ASCII editor?

(2) As a clinician I require my clinical message to be transferred accurately to the recipient. How does V3 do a better job as compared to V2.6? (Please do not bring in points like conformance, security, permissions, confidentiality and encryption, since all of this can easily be configured in V2.6)

(3) V3 XML vis-a-vis V2.6 XML is massive and convoluted. How is this better?

a) The human readable component is so deeply buried in the code that it requires super human effort to extract it manually (even for a small message) so is it really human readable? 

b) Coming to the next part, machine readable information - the effort required to human-engineer an application to ergonomically extract information from clinical data (as required by V3) puts a huge load on the end user (clinician). In fact there are studies that clearly show non-acceptance of HC IT apps by clinicians because of use of complex forms to input data in a way that is different from the normal flow of a clinician's writings. These are some of the problems that reduce acceptance of Healthcare IT apps by clinicians. Do you not think that by trying to make data machine readable for V3 you would be actually reducing adoption of HC IT apps by clinicians? End of day there are other methods by which data can be extracted from free flowing text for BI, CDSS and EBM (evidence based medicine). So why complicate?

(4) V2.6 can easily transport any kind of media with lower overheads as compared to V3. So why V3?  

(5) V2.6 can, from the end user point of view, transfer the same clinical content as robustly as V3. So why V3?  

(6) V2.6 messages can be coded by nothing more than Notepad and the standards document. Why this complex process in V3? Since in the end after all this goes through the grinder (Funnel the RIM to a DMIM (actors, story boards, acts, moods....) to a RMIM, CMETs yada, yada, yada, run it through automated tools) we are finally handed over ready message templates for each domain - as is present in V2x. This message (from the end user point of view) is nothing more than the equivalent of a ready made message from one of the chapters of the V2.6 standard (it is as as simple as simply selecting the appropriate V2.6 message from the standard and going ahead). So why would one waste time, effort and scarce manpower to do the same thing in a more complex way?

(7) Has a study been done on the cost overheads of V3 (in $ terms) vis-a-vis V2.6 (including conversion of data, maintaining of 2 standards, training, new apps,etc)? If so what is it and are the costs commensurate?

(8) What are the time overheads of changing over to V3 (in man days) vis-a-vis say, V2.5 to V2.6 (including training)?

(9) How much time does it take to train a productive HL7 analyst in V3 vis-a-vis V2.6? Is the time/cost commensurate? 

(10) I am sure you agree that the more the parts, the more are the chances of a breakdown (or error or worse still a SILENT error). Complexity, if it improves outcomes to the end user, would be worth the risk. But how does V3, realistically, improve outcomes for the enduser (as compared to V2.6)?

(11) Do you think it would be a good idea to wrap up all the RIM based complexity into a black box (only to be handled by the WGs) and simply present ready message templates to the end user in the form of a 'V3Simplified' Standards Document, something similar to a V2x document? (This is, in any case, gradually happening.) These messages could be mapped to V2x messages for easy portability.

Grahame provides his responses here:
                   http://www.healthintersections.com.au/?p=33

NCI Report on caBIG

Just released:

AN ASSESSMENT OF THE IMPACT OF THE
NCI CANCER BIOMEDICAL INFORMATICS GRID

Report of the NCI Board of Scientific Advisors Ad Hoc Working Group

See: http://cancerletter.com/downloads/20110304_2/download

There is much that is of interest in this document, which does not however get to the heart of the reasons for the technical failures of so much of the caBIG software. About which more anon.

Update April 12, 2011

See now also here.

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’.