U.K. Scrapping National Health IT Network

After nine years, and $18.7 billion in wasted expenditure, the British government is about to scrap its National Programme for IT, which was conceived as a massive, nationwide health IT network for the 52 million residents of England. 
   As we reported here already in 2007, one of the many reasons for this tragedy was an over-optimism on the part of Tony Blair and others as concerns the quality of available standards. If we use international standards, sanctioned by ISO, what, after all, can go wrong? 
   Yet as the head of the program, Richard Granger, expressed it in giving evidence to the UK House of Commons Select Committee on Health in 2007: 

In terms of the core Spine infrastructure, there was some mythology in the Health Informatics Community that the standards existed, HL7 was mature, and so forth. That was completely untrue.

And as the  UK Computing Research Committee pointed out in its evidence to the same Committee:

many of the technologies are new and have not been tested. In particular, at the heart of the EPR are two standards—HL7 v3 and SNOMED-CT. We understand that neither has ever been implemented anywhere on a large scale on their own, let alone together. Both have been criticised as seriously flawed. It is imprudent to base the Electronic Patient Record, which will be part of the UK's national critical infrastructure, on a technology experiment.

Sadly, as the many posts on this blog make clear, it seems that HL7 v3 is in no better shape now than it was in 2007.


Update October 3, 2011:

Lessons From Britain’s Health Information Technology Fiasco 

(New York Times, September 27, 2011)

The Wreck of HL7

An interesting ditty by Jean-Henri Duteau, reposted from the ever excellent Health Intersections Pty Ltd (after: The Wreck of the Edmond Fitzgerald)

The legend lives on from ANSI on down
of the SDO they called “HL7”.
Health Standards, it is said, never gives up her dead
when the skies of November turn gloomy.
With a load of designers twenty-six thousand tons more
than when HL7 started early,
that good SDO was a bone to be chewed
when “Semantic Interoperability” came early.

The SDO was the pride of the American side
coming back from some place in Ann Arbor.
As SDOs go, it was bigger than most
with a crew and CEO well seasoned,
concluding some terms with a couple of projects
when they left fully loaded for Orlando.
And later that night when the supper bell rang,
could it be the north wind they’d been feelin’?

The wind in the wires made a tattle-tale sound
and a wave broke over the railing.
And ev’ry man knew, as the CEO did too
’twas witch of Interoperability come stealin’.
The dawn came late and the breakfast had to wait
when Semantic Interoperability came slashin’.
When afternoon came it was freezin’ rain
in the face of a hurricane west wind.

When suppertime came the old Board chair came on deck sayin’.
“Fellas, it’s too rough t’feed ya.”
At seven P.M. a main hatchway caved in; he said,
“Fellas, it’s bin good t’know ya!”
The CEO wired in he had water comin’ in
and the good SDO was in peril.
And later that night when ‘is lights went outta sight
came the wreck of HL7.

Does any one know where the love of God goes
when the requirements turn the minutes to hours?
The searchers all say they’d have made Normative
if they’d put fifteen more miles behind ’er.
They might have split up or they might have capsized;
they may have broke deep and took water.
And all that remains is the faces and the names
of the wives and the sons and the daughters.

In a musty old hall in Ann Arbor they prayed,
in the “Health Informatics’ Cathedral.”
The church bell chimed ’til it rang twenty-nine times
for each man on the HL7 Board.
The legend lives on from ANSI on down
of the big SDO they call “HL7”.
“Health Standards” they said, “never gives up her dead
when Semantic Interoperability come early!”

HL7 and the Services Aware Interoperability Framework

Jobst Landgrebe is formerly Enterprise Architect at the International Institute for the Safety of Medicines
(ii4sm) and Co-Chair of the HL7 Vocabulary Workgroup. He and I recently collaborated on a paper entitled "The HL7 Approach to Semantic Interoperability" which was presented at the 2nd International Conference on Biomedical Ontology. The abstract is as follows:

Health Level 7 (HL7) is an international standards development organisation in the domain of healthcare information technology. Initially the mission of HL7 was to enable data exchange via the creation of syntactic standards for point-to-point messaging. For some 10 years, however, HL7 has increasingly conceived its mission as one of creating standards for semantic interoperability in healthcare IT on the basis of its 'version 3' (v3) family of standards. Unfortunately, v3 has been marked since its inception by quality and consistency issues, and it has not been able to keep pace with recent developments either in semantics and ontology or in computer science and engineering. To address these problems, HL7 has developed what it calls the 'Services-Aware Interoperability Framework' (SAIF), which is intended to provide a foundation for work on all aspects of standardization in HL7 henceforth and which includes HL7's Reference Information Model as general purpose upper ontology. We here evaluate the SAIF in terms of design principles that must be satisfied by a semantic interoperability framework, principles relating both to ontology (static semantics) and to computational behaviour. We conclude that the SAIF fails to satisfy these principles.

A video of Dr. Landgrebe's presentation is available here, and contains a number of interesting side remarks, including this (at 13:20):

The SAIF does not meet the needs of an interoperability framework. It can’t overcome the crisis of HL7 – and that’s a big problem because for example the IHE, the big organization that the government agencies are looking at to create interoperability in healthcare – it’s called "Integrating the Healthcare Enterprise" – is telling industry that it should use HL7 for everything in healthcare exchange .. , but if industry would do this nothing could work … My theory is that the IHE is set up exactly to make sure that nothing can work (but that’s – you know – conspiracy theory) … 

Update August 6, 2011:
I received the following comment:

Anonymous has left a new comment on your post "HL7 and the Services Aware Interoperability Framew...": 
I am not certain why your paper was accepted, other than the provocative subject matter. Much of what you state as fact is unsubstantiated opinion. Several of your premises are also faulty.
I am concerned, as this paper is quite misleading and/or misguided. 
You make sweeping generalizations without evidence of data or analysis. Many of these read more like bias rather than factual. Your paper contains several dubious citations. Many of the citations of your assertions don't logically support your argument. Some of the authoritative sources you cite are non-retrievable (404) URLs. Others simply not true. 
You often get tied up in knots in your logic, often based on a trifle (or misunderstanding). The line of reasoning is not clear and is encumbered by jargon, which seems to obscure rather than clarify. 

I can understand why correspondents who provide HL7 Watch with evidence of problems with HL7 request that they be allowed to remain anonymous -- criticizing HL7 can still, I am told, cause career problems in the health IT world. But why would someone who is taking the side of HL7 elect to remain anonymous in this way? Jobst Landgrebe and I provided arguments, and we provided an extensive list of references to support these arguments. (We regret that HL7 seems to have removed from the web some of the items for which we cited URLs since our contribution was first circulated.) Anonymous himself, however, provides assertions, which we would be more than happy to discuss. Perhaps he will reveal himself in order to allow such discussion to proceed.

Update August 18, 2011
One intriguing element of the SAIF literature is that it reveals that HL7 is now promoting the use of the word 'ontology' in application to the RIM. While in other circles there is increasing clarity as to the difference between an information model and an ontology (e.g. here and here), HL7 here seems to be once more muddying the waters.

HL7 attempts to get things clear about its own use of the word 'concept'

HL7 v3 has been under development since 1996. Now, at last, the HL7 organization is beginning to attempt to provide definitions for its basic terms. I provide the relevant document (in full) below, in the version of June 29, 2011. My comments are interspersed in red.

HL7 Nomenclature for Concept Representations

For many years, a number of words have been used to describe various bits and pieces of terminologies and their components. In an effort to precisely define these words, and use them consistently in the Core Principles document currently under ballot, this paper documents the current position of the Vocabulary WorkGroup with regards to these words, as used in the HL7 datatypes and the HL7 vocabulary model.

The fundamental unit of meaning in HL7 with respect to vocabulary is CONCEPT.

As defined in HL7, “a concept is a unitary mental representation of a real or abstract thing – an atomic unit of thought.” 

So:

1. A concept is a fundamental unit of meaning. 
2. A concept is a unitary mental representation.
3. A concept is an atomic unit of thought.

Are 1., 2. and 3. equivalent? 

However, there is not yet technology able to directly transmit or manipulate abstract thought. 

What is 'abstract thought'? Is it the same as: thought about what are referred to above as abstract things? Is this still thought of the sort that takes place in human brains? If yes, what sort of technology does the author of this sentence have in mind? If no, what sort of thought is it, that does not take place in human brains?

Furthermore, for useful computational interoperability, the set of concepts that can be captured, shared and manipulated must be standardized.  

If concepts are mental representations, as according to 1., or units of thought, as according to 2., how -- leaving aside complex brain surgery -- could concepts be captured or shared or manipulated? How could concepts thus conceived (i.e. as creatures of human mental activity) play a role in computational interoperability? 

Code Systems perform this function of concept standardization 

Does this mean that the concepts which are the atomic units of thought -- the concepts, presumably, with which human thinkers operate when they have thoughts -- are to be replaced by other, standardized, concepts when Code Systems are introduced? If so, where do these new standardized concepts live? Are they still 'units of thought'? And if so, who or what is the thinker who is having the relevant thoughts? 

and may perform other functions such as defining relationships between concepts.  Most importantly, they provide representations for the concepts they standardize. 

Our thoughts, or mental representations, are to be standardized by Code Systems. What does this mean? What is the end-result of such standardization? Concepts themselves, we are told, are representations of real or abstract things, and Code Systems provide representations of concepts. From this we can infer:

4. Code Systems provide representations of representations of real or abstract things.

But then a further problem arises; for if Code Systems provide representations of the very concepts they themselves standardize, does this mean that they provide representations of these concepts as they existed before standardization; or that they provide representations of the very concepts which they themselves have standardized? How can something be a representation of X and a standardization of X at one and the same time? 

A Concept Representation is some form of symbol that, when interpreted in the context of a given Code System, is understood to stand in for the meaning associated with the Concept. 

5. Meanings are associated with concepts.

According to 1. a concept is a unit of meaning. According to 5. there are meanings associated with concepts. Which is correct?  

6. Symbols can stand in for meanings 

What could this mean? Surely the symbols are the sorts of things that have meanings. 

While these representations may be graphical, or other media (e.g. barcodes, video clips, etc.), in the context of HL7 they are generally limited to character strings.  Code systems may provide multiple concept representations of different types for a single concept. Some concept representations might be intended for internal use by the code system, others for exchange by computer systems representing the concept, others for display to human users, and still others to "formally define" the underlying concept.

In many code systems, the same symbol might serve multiple purposes.  For example, the symbol "F" in the HL7 code system AdministrativeGender can be used internally in the definition of a Value Set, can be sent over the wire between computer systems and can be displayed to users.  In other code systems, a given concept representation might be intended for only a single use, or even variants of a given use.  For example, a code system might define both short and long descriptive name concept representations for human display in different types of user interfaces.  Depending on their intended use, types of concept representation may have varying characteristics in terms of whether they are unique within the code system and whether there can be multiple representations of that type for a given code system.

7. There are descriptive names which are concept representations.

This means, I think, that there are descriptive names such as 'person' or 'arm' which represent concepts. Such descriptive names, presumably, also have meanings. Are these meanings also concepts? If so, are they the same concepts as the concepts which the descriptive names represent? If not, are there some meanings of descriptive names which are concepts, and other meanings which are not concepts? And if so, how do we then tell the difference between the two? 

In other code systems, it may be possible to construct a representation by combining other representations according to a code-system-specific grammar.  This is called post-coordination.  For example, the symbol for "arm" might be combined in some way with the symbol for "left" to construct a concept representation for "left arm". 

There is an issue, here, of what is called the 'use-mention confusion', illustrated by the sentence "Swimming is healthy and has two vowels." The use-mention confusion occurs when it is not realized that "swimming" refers to swimming (and not to "swimming"), that "London" refers to London (and not to "London"), and so on.

We are told that we can put together the symbol for "arm" with the symbol for "left" in order to construct a concept representation for "left arm". Not so, however, The symbol for "arm" is '"arm"'. ("Arm" is the symbol, not for "arm", but for arm.) 

[See the second comment by Spero melior below on a further problem raised by this paragraph -- which is that it suggests that the combination of the concepts arm and left would itself constitute a concept, which conflicts with HL7's own definition of concept as an atomic unit of thought.]

The [accompanying table] of three different names for concept representations attempts to disambiguate the nomenclature we commonly use in HL7.  It also includes examples for these types of concept representations from some common healthcare-related code systems, including some post-coordinated examples.

Note that these terms [‘Code’, ‘ConceptID’, ‘Designation’] all refer to the use of a particular Concept Representation. In some code systems, such as the AdministrativeGender example given earlier, the same representation (e.g. "F") can be a considered a Code, a Concept Id and a Designation.

So that's clear, then.

Notes
1. The above continues my commentary here.
2. For an example of a set of definitions which, I believe, comes closer to the level of precision that is required, in this difficult field, see here, and especially the distinction between what are there called "levels 1, 2 and 3." For further discussion of the problems we face in understanding the meaning of the term 'concept' in computer science circles -- including arguments on behalf of the view that we should abandon this term entirely, see here.  
3. For a discussion of the historical source of some of the confusions conveyed in the above document, including the delightful passage concerning "technology able to directly transmit or manipulate abstract thought", see here.
4. Update June 30, 2011: See now Grahame Grieve and Thomas Beale discussion here.

Does anybody out there love the RIM?

From Grahame Grieve at Health Intersections:

The most remarkable aspect about the wide feedback I’ve received about the HL7 Fresh Look taskforce is the comments about the RIM. 

One person – just one solitary person – put it to me forcefully that the original direction of the RIM (+ design by constraint + the XML ITS) was the right direction, and that we should stay the course, becase in the end, the doubters will be overcome by the evidence. 

Just one person. It’s someone I respect greatly. And it troubles me to disagree with him, because this person is often proved right. But he’s the only one (so far) (And I’m not going to name who it is since our discussion was private). 

There was a long and at times passionate thread on the RIMBAA (RIM-based application architecture) email list defending the notion of the RIM, but even there the opinion there was pretty unanimous: the RIM should be reserved to specialists, and normal interoperability specifications should use simple forms where their innate RIM-ness is hidden from the normal population.

Generally, the feedback I got from my fresh look post told me loud and clear that HL7 is not reducing complexity, and that in particular, the RIM is not helping to tame complexity.
That should come as no surprise to anyone who’s read my piece on design by constraint: it simply externalises the complexity associated with achieving consistent semantics. But nevertheless, I was surprised at how  one-sided the feedback was in this area. 

Does anybody (else) out there love the RIM?

To keep track of the responses (if any) follow here.

Chocolate Teapot Not Otherwise Classified

The methodological approach which underlies this blog is based on the position of ontological realism. One standard objection from the HL7 community to this position is that the ontological realist strives for 'perfection', where HL7 and its ilk, more sensibly, strive for mere 'practical utility'.

Examination of the many concrete proposals made under the ontologically realist heading proves, however, that they are both (a) quite modest, and (b) of considerable practical utility.

In many respects these proposals echo the "Desiderata" advanced by Cimino in responding to the poor quality of many of the terminology artifacts created in the field of medical informations. In one central respect, however, they go beyond Cimino who still (in 1998, at least) sees the way forward as lying in a move from the orientation around terms to an orientation around what he calls "concepts". For inspection reveals that the concept orientation is itself one reason for the massive inconsistencies that exist, both between different specialist terminologies, and among the different versions of these terminologies produced at successive points in time. This is because the concepts in the minds of specialists are too etherial to serve as a constraint on the builders of terminologies, especially when the latter are themselves subject to the pressures of third-party payers, gatherers of public health statistics, patient groups and other stakeholder lobbies. The result is confusion; the waste of investment in the creation of poorly maintained mappings; ever more intensified forking leading to a failure of cumulativity of data and to a lack of IT support, for example, in areas such as continuity of care (for example when patients move from one hospital to another).

The solution proposed by ontological realism -- now embraced in part also by Cimino -- rests on the idea that terms in ontologies (or terminologies, or messaging standards) should as far as possible be oriented, not around concepts in people's heads, but rather around the types of entities in the corresponding domains of reality. In this respect, terminology work should mirror the practice of scientists, who as a matter of course use terms such as 'electron' or 'planet' or 'mammal' in describing their data, rather than terms such as 'electron NOS' or 'planet NEC' or 'mammal that is of interest to the human resources department'. Terms in the former group are used in remarkably stable ways, by multiple, ever expanding communities throughout the world, and there is empirical data associated with the corresponding types in reality deriving from large numbers of heterogeneous sources.

The proposal is (1) that representations of types of the mentioned sort should be used in terminology resources wherever possible, not merely as terms in their own right, but also in the definitions of further terms, and (2) that the term 'concept' should be avoided entirely. (A partial exception might be made in areas such as linguistics or psychology, where the scientists in question are able to define what the term 'concept' means.) In this way, terminologies will be anchored -- to some degree at least -- to a stable, empirical benchmark, following a pattern already realized by the OBO Foundry ontologies. Terminology resources will also be anchored to each other, through the use of a common set of feeder terms in their respective definitions, in ways which can support consistency over time and thereby also allow the more effective aggregation of data.

We do not see this solution as a magic bullet. But we do believe that it has the chance to constrain forking in some small areas of clinical research, and that putting it to the test in pilot experiments may provide a generalizable strategy for the formulation of coherent terminologies and associated definitions in broader areas in the future.

Moreover, we are absolutely sure that the negative results which have flowed from not following this proposal are immense. These results are visible, for example, when we examine some of the problems faced by users of SNOMED as a result of the fact that the latter has been subject to such a large number of changes in its successive versions -- changes that can be attributed precisely to the concept orientation, which infects SNOMED from the top down.

I now discover that these results have been documented in a beautiful piece by Malcolm Duncan entitled "Medical terminology version control discussion paper: The chocolate teapot (Version 2.3)" in relation to the Systematized Nomenclature of Kitchen Terminology (SNoKitch), and specifically to its two non-contiguous branches Crockery and Teamaking Related Findings in its n.3 release:

Crockery
---Teapot
----- Brown teapot
------White teapot
----------White china teapot
------Blue teapot
----------Blue china teapot
------China teapot
---------White china teapot
---------Blue china teapot
------Pink teapot
------Aluminium teapot
------Chocolate teapot
------Ornamental teapot
------Industrial teapot

Tea making related findings

---Teapot related findings

------Large teapot

------Full teapot

------Empty teapot

------Teapot with warm water

------Teapot with cold water.

The document in question is cited in a (long) HL7 discussion concerning the problems which arise in connection with the Cimino desideratum of "concept persistence". This discussion, incidentally, reveals one flaw in Cimino's formulation of his desiderata: for it shows that recommending "concept persistence" as a desideratum is a bit like recommending "life persistence" for the patients in your hospital. Life persistence is, certainly, a nice thing to recommend; but it would be even better, surely, if one can formulate a desideratum which identifies some specific strategy for achieving it -- in such a way that the desideratum of persistence will follow as by-product. It is something like this which ontological realism, in its stumbling fashion, is attempting to do. For its counterpart of 'concept persistence' -- to the effect that ontologies should be developed in such a way that versions should evolve gracefully in reflection of scientific advance -- follows immediately from the recommendation to use, as far as possible, the terms employed by scientists.

HL7 Refresh

Here, continuing the theme of "the fall of the RIM", are some recent contributions on the future of HL7:

• From Tom Beale at Woland's Cat: How could HL7 refresh?
• From Grahame Grieve at Health Intersections: HL7 Fresh Look Task Force
• From Barry Smith in The Cancer Letter: caBIG has another fundamental problem: it relies on "incoherent" messaging standard

The Fall of the RIM

In his comment of 4/02/2011 to our "The Rise and Fall of HL7" thread, Graham Grieve argues that, in spite of all the objections advanced by Elliot Muir and in the associated comments, there is value in HL7 V3 nonetheless -- because the RIM provides a 'semantic standard', and "the future of HL7 isn't about syntax or technology, it's about semantics."

Grahame and Jobst and I (and, I am sure, also Thomas) agree that there is "benefit in commonly agreed semantics". The thesis that has served as the central pillar of this blog since its inception, however, is that after 14 years of development effort, and after so many failures, we should finally accept that the RIM is not able to serve as basis for the needed commonly agreed-upon semantics.
HL7 Watch and others have provided considerable documentation that the RIM is both counter-intuitive and unnecessarily complex; that it is thus difficult to teach and difficult to document (and thus inconsistently documented); and that it is therefore difficult if not impossible to implement.
Moreover, multiple arguments have been provided to demonstrate that, even if it were implemented, the RIM would still not bring about the end which its defenders seek, namely: consistency of semantics. This is because the RIM's own semantics is so counter-intuitive, and thus so inconsistently documented, that its different users will inevitably produce semantically inconsistent implementations, thereby resurrecting the very problems which had led to the conception of the RIM in the first place.
We have learned much in the field of semantics in the 14 RIM years, and what has been learned can now be used as the basis for a better and simpler solution. It is time to start again.


Postscript 4/2/2011, 11:19 AM

So, you keep quoting me, and I keep having to respond ...

In his comment of 4/02/2011 to our "The Rise and Fall of HL7" thread, Graham Grieve argues that, in spite of all the objections advanced by Elliot Muir and in the comments above, there is value in HL7 V3 nonetheless -- because the RIM provides a 'semantic standard', and "the future of HL7 isn't about syntax or technology, it's about semantics." 

ummm no. I argued that there is value in a commonly agreed set of semantics. Elliot, if you look closely, didn't mention the need for it, and so that's what I was addressing. I didn't mention the RIM. But omission is not as clear as commission huh?

I do believe that the future of HL7 is semantics, not platform technologies. Well, duh. There's no need for HL7 to invent syntaxes and network protocols these days.

Is the RIM the future? I don't know yet. 

I think that the primary debate should be about design by constraint. Tom (who commented in the other thread) did openEHR, which is totally different to v3 and also exactly the same (and also much better and not nearly so good!). The reference model is both more and less abstract than the HL7 RIM, but the methodology is the same: design by constraint. 

First, we should figure out what kind of methodology can deliver consistent semantics where we need it, while allowing seamless customisation for particular use cases, where it is needed, without creating an engineering nightmare (one sequelae of that is that it should be usable in multiple architectures without building of extensive custom software stacks). Once we have that, then we can figure out what are the useful properties of an ontology that supports it. 

However my view is that no current approach meets such a criteria. We have some candidates on the floor now, and they have the rather useful property of being concrete and usable. v3, and openEHR are the primary ones I know about in health. I work with them both, and they both have strengths and weaknesses. The primary weakness of both is that you have to be steeped in them to understand how to leverage them. But once you are - you can leverage them well. Both v3 and openEHR.

Only in the final paragraph does Graham address my specific arguments concerning what so many now see as the dire state of HL7 V3:

To address your concerns directly. The RIM is trying to do a complex thing. So it's hardly a surprise that it's complex. You've been critical of it, but your criticisms have either been rather fractional, or marginal given the RIM's intended use. What's the alternative? 

Not sure what 'fractional' means when applied to criticism. I can well understand that many of the criticisms on this blog will seem 'marginal' to some of those who are caught up in the attempt to use and maintain the HL7 standards. On HL7's FAQ page, we find an odd entry headed "HL7's Mission", which reads as follows:

HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.

It is evident to those, such as myself, who are viewing HL7's processes -- for example as illustrated by some of the more untamed contributions to the HL7 Vocabulary forum -- from the outside, that they exhibit a  marked shortfall in timeliness, scientific rigor, transparency, accountability, and practicality. Why is this so? In part, surely, because of those marginal issues -- such as the inconsistency and counter-intuitive nature of the RIM -- which I have been attempting to draw attention to on this blog. 
And what is the alternative? 
I hope to address this question in more detail in a later post. But for the moment:

• First, recognize that the RIM rests on a series of rather simple confusions (for example between a disease and its diagnosis, between an action and its documentation, between an entity in reality and information about that entity in some record).
• Second, replace the RIM backbone hierarchy with an ontology that is not subject to these confusions, for example in the way that this is done in the Ontology for General Medical Science, which is based in turn on Basic Formal Ontology.
• Third, study the principles of Referent Tracking.

Postscript April 4, 2011: On Grahame Grieve's Comment on "The Fall of the RIM" 

I respond, here, to some of the remarks in Grahame Grieve's Comment of April 4 (reproduced in full below):

It may be, as you say, that the RIM confuses reality and information about reality. (Actually, I think you're confused. Reality is not a RIM - or even ontology - based existence. It may be that the RIM confuses information about reality and information about information about reality). But it's real hard for implementers to differentiate these things - so being strict about the difference actually makes things worse.

Grahame and I are addressing here what philosophers call the "use-mention confusion", as illustrated for example in: "Swimming is healthy and has two vowels" or "Our system is able to extract tumors from the patient database in 0.005 seconds". It is true that this confusion is common in many computer-related fields. But surely the goal, in message standardization, is to ensure accuracy of communication. 

And it may also be that the RIM and the underlying terminologies (including ones that HL7 doesn't define) are not good at distinguishing instance and class, and defining which instance is intended efficiently - I agree with that.

But replacing the RIM backbone with something like the ontology you talk about would be a problem because it doesn't have the semantic breadth of the RIM. Whether or not some of the thinking in that ontology is better than what is evident in the RIM or not, it's a 5% coverage replacement. ...

If I am right, then the RIM will, sooner or later, have to be abandoned. At that point an alternative will be needed. I have suggested some elements of an alternative. Of these BFO certainly has sufficient semantic breadth to represent any of the types of entity, and to annotate any of the types of information, that are relevant in healthcare. It has also been thoroughly tested in use, especially in biology. Moreover, BFO stands up well along a number of dimensions when compared to the RIM, as is revealingly shown by the Cecil Lynch saga documented here. What BFO lacks is semantic depth -- though with the OGMS work we are beginning to fill this gap. The RIM has this semantic depth because it has been extended in so many different directions by so many for so long. But because the RIM lacks coherence, these extensions typically do not work either, and they certainly do not work well when taken together. 

Finally, the real problem with your recommendations for what to do is that there is such a gap between your recommendations and the actual resistance and issues HL7 faces with v3. I continuously get feedback about what is not good about v3. Your prescriptions are something that would make a difference to playing the end-game with v3 - decision support, reasoning systems - but it costs so much to get to the field, that no one even sees the mid-game yet.

Again: if I am right, then the RIM will, sooner or later, have to be abandoned -- cost what it will. The groundswell of criticism can be held back for a bit longer, perhaps, through application of the existing strategies used to cow critics into anonymity. But what makes the case of Elliot Muir so interesting is that these strategies, too, are no longer working.

Postscript April 12, 2011

An interesting report on national health reporting standards in Norway contains the claim that:

"Most European countries that make use of HL7 messaging standards for new purposes uses HL7 version 3. This applies in particular [to] Britain, Germany and the Netherlands."

In fact, however, it seems that there is know one in Germany who is using v3 messaging, although CDA is in use in some places. In the UK there is some v3 legacy, but there seems to be no new development; rather, new work is being done within the framework of the 13606-based Logical Reporting Architecture (LRA), which seems (to me at least) to be a much more coherent modelling effort. Netherlands, it is true, is still using v3 messages, though it is not clear that they are actively developing anything new. And outside of those three countries? In Norway, for instance,  plans were indeed announced to mandate v3 - solely, it seems, in light of its status as an 'international standard'. But from the above-cited report it seems that Norway has pulled back from the brink. In the rest of Europe it is CDA that is being used, or 13606 or LRA.

In a comment by Rene Spronk (provided in full below), the question is raised as to HL7 Watch's view of openEHR in light of the fact that the latter has certain similarities with HL7. openEHR, too, I believe, has need of a more sophisticated upper ontology-based approach: it is thus far marked by a lop-sided focus on information models at the expense of representations of reality of the sort which ontology can provide. But there are leading figures in openEHR who would agree with this diagnosis, and I remain optimistic that openEHR - and similar ventures under the CEN-13606 heading - will take the steps needed to rectify problems in this regard. The HL7 community, unfortunately, which is currently advancing the RIM as an 'upper ontology' in the context of its new 'Services-Aware Interoperability Framework’ or SAIF, still gives no evidence of having understood what a well-designed ontology might look like, and what such an ontology is able to achieve. As addressed at length already elsewhere in this blog the RIM has fatal shortcomings not only because it contravenes the very basic rules of information modelling, but also because its backbone taxonomy of Act, Entity and Role is too narrow to allow serious ontological work.

openEHR and similar approaches differ from HL7 v3, too, in that they can be critiqued as can any other  ordinary object-oriented reference model approach, precisely because they conform to industry practices. This is not true of HL7 v3.

Referring to an earlier link posted by Rik Smithies listing 22 known software implementations based on the RIM, Rene argues that

This is just the tip of the iceberg in terms of known organizations that voluntarily embrace the RIM as either a persistence model or a in-memory business layer model. This is mainly done for research, public health and DSS purposes, although we've also seen implementations to support classic on line transaction processing applications. ... Calling the RIM "fallen" when at the same time it is increasingly being embraced as an internal model in all sorts of applications - your call, but curious to say the least.

One of the earliest posts on this blog, dated November 25, 2005 is entitled "Misleading Claims regarding HL7 V3" and concerns a 'white paper', edited by Rene, and containing a claim to the effect that "Significant V3 national implementations exist in many countries, e.g. in the UK (the English NHS), the Netherlands, Canada, Mexico, Germany and Croatia." Already at that time there were considerable grounds for scepticism concerning such claims. Now however we have a better view. In the UK, for example, we can see that at least one part of the reason for the massive failure of the Connecting for Health program was precisely that the use of HL7 v3 was imposed upon its designers. 

Use of HL7 v3 messaging is, certainly, widespread within the community to which Rene belongs. But it is questionable whether this is a large community. And it is still more questionable whether the members of this community are exuding confidence that they are riding the wave of the future.

Postscript August 3, 2012

See now also Graham's "Design by Constraint – not as useful as people think" (published on April 30, 2011) on "Implementation Disasters":

The inevitable outcome of wide scale adoption of [the Design by Constraint] technique is chaos. Different implementors want to live at different points on the general <-> specific curve, and there’s a variety of options to attempt to externalise costs from one implementor to another. 

There’s various approaches to handling this. You can be like HL7: put your head in the sand, claim that it all works (in other words, externalise the costs), and then be real confused about why your brilliant idea isn’t actually solving all the problems in the world. ...

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