And now even CDA is troubled

From: owner-strucdoc@lists.hl7.org  [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Bob Dolin
Sent: 28 November 2011 19:07
To: Structured Documents WG
Subject: RE: CDA or greenCDA

Wes,

Who is asking to have greenCDA sent over the wire, and what is their rationale?

I don’t agree with your learning curve statement. I would expect that most recipients would use a general purpose CDA parsing algorithm. In fact, if you deal with many types of CDAs, it can be harder to receive  greenCDA, because you must insert an intervening transform step.

As for the cover about 80% of the requiremen this is because greenCDA is a simplification, that removes some CDA bells and whistles. Is not that greenCDA cant express anything that is in CDA, but that we make design decisions when simplifying.

As for Robert Words proposed rule Every Green CDA instance should contain the URL of a transform to take it to the full CDA it is derived from I dont think that is sufficient. I think ll need to ballot  greenCDA schemas (e.g. a greenConsolidation) if we are to use it as a wire format.

Thanks,

Bob

Bob Dolin, MD, FACP

President and Chief Medical Officer

Lantana Consulting Group

t: 714.532.1130

c: 949.466.4035

www.LantanaGroup.com

From:  owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of robert worden
Sent: Tuesday, November 29, 2011 3:33 AM
To: 'Bob Dolin'; 'Structured Documents WG'
Subject:  RE: CDA or greenCDA

Hi Bob  -

I think HL7 has two distinct groups of customers:

A.     Those who understand the RIM and CDA; have several different use cases for CDA; and might have invested in a general-purpose CDA parsing algorithm

B.      Those who don’t understand the RIM; have just one or two use cases to address; and want to do it as simply as possible.

We need to listen to all our customers, in both groups.  I think those in group B greatly outnumber those in group A. In the UK I know they do, for a fact. Most healthcare providers and most IT suppliers simply dot want to know about the RIM; they just want to build the interfaces they need, with as little fuss as possible.

But it is the group A customers who have the time to invest in HL7 to come along to WGMs, attend weekly calls, follow threads like this, define the standards and take part in ballots. It is group A who have overwhelmingly defined the direction of HL7; whereas group B are the majority of our customers. I think this systematic bias in our process has misled us over the years.

Green CDA suits group B just fine. They look at a Green CDA instance and say Yeah, I can do that.; whereas a full CDA instance induces silence and shaking of heads.  So recommending Green CDA, without even saying: full CDA is the real thing; yd better send that over the wire is what suits group B.

But the great thing about Green CDA is this: provided we have reliable transforms in both directions (full <=> Green) we don’t have to choose between our customers, because both groups A and B can work the way they want to. The issue of what goes down the wire should become as trivial as to zip or not to zip; you just apply a transform to get the form you want. Also, Green CDA is a handy migration path for group B users who want to move to group A.

On your last point (transforms alone are not enough) I fully agree. The proposed rule was an additional requirement if Green CDA is to go on the wire, not the only requirement.  I had assumed without saying that to publish any Green CDA, you should at least publish a schema to define its structure; and also (more important) publish its semantics in a RIM-independent for so group B can know what it means.

Best wishes

Robert

mobile: 07970 197968

landline: 01353 777668

From: owner-strucdoc@lists.hl7.org  [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Pratt, Douglas (H USA)
Sent: Tuesday, November 29, 2011 9:52 AM
To: robert worden; Bob Dolin; Structured Documents WG
Subject: RE: CDA or greenCDA

In my experience helping implementers, the most frequent request I had was for examples of "how do you represent..." that may or may not be helped by Green CDA (as there currently is no Green CDA to evaluate). 

Some common ones:

- How do I represent no known food allergies?

- How do I represent that the patient has positively asserted no known allergies vs. no information (not asked, etc.)?

- How do I represent that this allergy had an onset of "adolescence", when CDA requires a date?

- How do I send legacy codes along with their translation to industry code(s)? 

- What data pertains to visits, and which across visits (CCD)?

I found that if I could provide an example, they could work with it. The markup was not really an issue in that case.

- Doug

From: Rishel,Wes [mailto:Wes.Rishel@gartner.com]
Sent: Tuesday, November 29, 2011 10:33 AM
To: Pratt, Douglas (H USA); robert worden; Bob Dolin; Structured Documents WG
Subject: RE: CDA or greenCDA

Are all the how do you represent questions you listed explicitly spelled out now in the CCDA?

I would note that the only guidance on the CCDA on sending blood pressures is a textual note under vital signs that says blood pressures should be sent as observations.

Wes Rishel
Gartner

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of  Bob Dolin
Sent: Tuesday, November 29, 2011 12:55 PM
To: Rishel,Wes; Pratt, Douglas (H USA); robert worden; Structured Documents WG
Subject: RE: CDA or greenCDA

Hi Wes,

What is CCDA?

Thanks,

Bob

From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com]
Sent: Tuesday, November 29, 2011 11:53 AM
To: Bob Dolin; Rishel,Wes; Pratt, Douglas (H USA); robert worden; Structured Documents WG
Subject:  RE: CDA or greenCDA

I presume it is Consolidated CDA

Seems this is an effort to make this seem like not-CDA.

We need to be very careful at how all of this is perceived by the thousands of people who only get to see these efforts when they come up to breath. By bringing in yet-another-acronym, there will be more confusion. We really dont need or want confusion, right? We need to be working together to bring down the FUD, not make more of it.

John

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of  Rishel,Wes
Sent: Tuesday, November 29, 2011 5:31 PM
To: Moehrke, John (GE Healthcare); Bob Dolin; Pratt, Douglas (H USA); robert worden; Structured Documents WG
Subject: significant concer re Moehke's response (was RE: CDA or greenCDA)

John: Seems this is an effort to make [Consolidated CDA] seem like not-CD

I take substantial umbrage that John implies that I have a deep and dark motive to somehow separate CCDA from CDA, particularly as my recent blog talked up the CCDA as a significant step forward for the CDA. This style of innuendo really does nothing to advance discussion on issues.  Many people properly discount ad hominem jabs like this, whereas for others it tends to deepen schisms rather than finding narrow points to build bridges.

A simple statement such as we must be careful that the acronym leads people to believe that the Consolidated CDA is something different than C would have raised the issue without appealing to conspiracy theory or implying that I had baser motives.

I make no bones that I have fear, uncertainty and doubt about the ability of the US to pull off a high degree of interoperability with the C32, how I think that CCDA is an improvement but that there is still more that needs to be done. However I do my best to address the issues, not the people, bring other experience into discussion and look for solutions. These are the same issues that I shared privately with Board when I was a member and held reasonably close until I had been off for awhile. After a while, though, I felt that the better thing to do was to express my issues on an HL7 list server rather than only in other venues.

Some would say that casting FUD is a bad thing. It is, when it is an attempt to obscure discussion on the issues. Just the same, decrying FUD is a bad thing if it is done for the same purpose.

I have actually learned a lot in the discussions over the last few weeks, some of which has been reflected in my blog. I would say, however, that if there are specific rules of decorum or a general sense on the blog that it should only be used for discussions that are pro the group sentiment, I would have to conform by going elsewhere.

This not the HL7 that I remember.

Wes Rishel
Gartner

 From: "Boone, Keith W (GE Healthcare)" <keith.boone@ge.com>

Subject: RE: significant concer re Moehke's response (was RE: CDA or greenCDA)

Date: 30 November 2011 05:03:10 CET

To: "Rishel,Wes" <Wes.Rishel@gartner.com>, "Moehrke, John (GE Healthcare)" <John.Moehrke@med.ge.com>, "Bob Dolin" < bob.dolin@lantanagroup.com>, "Pratt, Douglas (H USA)" <douglas.pratt@siemens.com>, "robert worden" <rpworden@me.com>, "Structured Documents WG" <strucdoc@lists.hl7.org>

Reply-To: "Boone, Keith W (GE Healthcare)" <keith.boone@ge.com>

Wes, frankly, I read something very different in what John had to say, and I’m certain it wasn’t intended as a personal attack on you. 

I deal with CIOs and CMIOs frequently enough who still stumble over CDA, CCR, CCD and C32 and cannot tell the difference between them, yet are responsible for making sure they’ve got whatever ‘it’ is, implemented correctly for their facility or practice.  We just shifted the ground from underneath them with a new acronym.  After all, if Bob Dolin doesn’t know what CCDA is, how could they possibly be expected to know it.  You don’t set out to create FUD, there is no conspiracy, and nobody (at least in my reading) has accused you of starting one.

When even Bob Dolin has to ask you what CCDA is, it clearly delivers the point that this thing we’ve been calling the Consolidated CDA Guide needs a better name, and needs some marketing and customer education to explain to folks what it is.  Adding YAA (yet-another-acronym) to the alphabet soup isn’t going to help.  I’m already getting questions from the people who follow you at a policy level about what is CCDA, and even worse, there’s been other industry press describing this work that misquotes and misrepresents what it is.

If there’s a failure to communicate what the Consolidated Guide is, and there’s more FUD because of it, it isn’t your problem Wes, and you didn’t cause it.  It’s HL7’s problem, and we need to fix it.  That’s what I take away from John’s point.

As for names, there was some discussion of renaming for publication.  It might well be worth bringing that back up and thinking about how to market this effort professionally.  There’s a brand to be built here, a story to tell about what when into this work and the communities that built it over the last six+ years, and a community to educate about these guides and what they mean for their end users.  HL7 as an organization doesn’t have a great history at doing that sort of marketing, but somehow we need to figure it out.

Keith

Keith W. Boone
Standards Architect
GE Healthcare

  

Some random news items

1. Exciting stuff from Grahame Grieve at Health Intersections. Summary: "HL7 v3 has failed".

2. And here an email of September 18 from Thomas Beale (with emphasis added by me) responding to Grahame's description of developments regarding RFH:

At the HL7 meeting last week in San Diego, Grahame Grieve presented something called Resources for Healthcare (RFH), essentially a replacement model for much of HL7v3, for 'practical use'. The driver was the well-known over-complexity of HL7v3. According to his report on the reception of RFH at the HL7 meeting, there appears to be a real appetite for change at HL7, which is good to see.

3. And an announcement from Gartner: HL7 V3 Messaging "has fallen off the hype cycle".

Snippets from the analysis by Wes Rishel in the current Gartner Hype Cycle report:

The V3 Messages (V3M) standard was conceived as being the direct analog of the Version 2 Messages standard — that is, XML documents designed to support the information necessary to be transferred when a specific event occurs, such as a patient being admitted or a lab result being approved for delivery to the provider. ... we describe the messaging part of the V3 suite as "obsolete before the plateau."... uptake has been so small and narrow that we cannot justify leaving V3M on the Hype Cycle.
Business Impact: V3M will not have impact except, perhaps, in a few locales.
Market Penetration: 1% to 5% of target audience

4. What is an 'Implementation Guide'

HL7 seems not to know how to define 'Implementation Guide' even as it pertains to its own standards:

Discussions with others revealed that there is not really any specific definition as to what an Implementation Guide is. The general impression is that anything that constrains a model is an implementation guide. The level of constraint is determined by the level of the guide (i.e. normative of informative). Given this fuzziness, calling this an implementation guide is not out of line with common use. (See here)

5. And finally this:

From: "Helen Stevens Love"
Subject: HL7 International Council Proxies - San Diego WGM
Date: 8 september 2011 21:53:09 GMT+02:00
To: "HL7 Affiliate Council"

Dear International Council Members,
Based on the pre-registered attendees for the upcoming San Diego meeting we may fail to reach quorum for our Council meetings. ...

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