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