Sunday, May 24, 2009

HL7 RIM: still no coherent way to track concerns

One standing theme of this blog is the inability of HL7 v3, and its RIM 'reference information model', to represent clinical concerns, problems, conditions -- including diseases, such as your influenza and my diabetes. The RIM, familiarly, leaves us only two options for the coding of such information: either to identify diseases as Acts (which we take to mean 'intentional actions on the part of human beings'), or to identify diseases as Entities (roughly, those things -- such as persons, bedding, pills -- which are 'made of molecules').

To normal persons both of these options seem equally unacceptable. To the RIM, however, a stunningly creative work-around is at hand: diseases are identified as Acts of Observation. Roughly: a disease is an observation of a disease.

One of the many problems with this work-around is that there are often many observations of one and the same disease (for instance of my diabetes or Jim's arthritis), and the RIM provides us with no satisfactory answer to the question of how we can identify what each given series of such observations have in common. The obvious answer -- that they are all observation of the same disease / problem / condition -- is ruled out.

When Werner Ceusters and I made this surely obvious point at the Medical Informatics Europe meeting in August 2006 (see here), G√ľnther Schadow responded on behalf of HL7 to the effect that steps would be taken to add new classes to the RIM in order to address the obvious need to refer to items such as diseases, medical problems, clinical conditions which are not Entities, and thus not made of molecules, but yet such as to endure self-identically through time.

Two new classes -- of Concern and Condition (with abbreviations 'CONC' and 'COND') -- were selected, and a number of important HL7v3 players have been using these classes -- in reflection of the fact that they address an urgently felt need. Unfortunately, the ISO RIM standard and the ANSI HL7v3 standard did not see fit to support such usage.

We therefore have a new bifurcation of different RIMs (where the RIM itself was introduced 13 years ago precisely in order to solve the problem of multiple different dialects plaguing HL7v2).

Why was the change of adding CONC and COND not made to the official RIM standard, given the obvious benefits of simplicity and greater ontological coherence such a change would bring? This question is being raised also inside the HL7 community, as for example in the following email exchange, which hints at serious problems regarding the quality of HL7's decision-making process:

From: Dan Russler
Date: 23 May
2009 4:52:26 GMT+02:00
To: Jean-Henri Duteau
Cc: "" , MNM List , HL7terminfo ,
" "
Subject: Modifying
Problem list in the CCD standard: was Patient care harmonization Was:Re: NIB
forms for next ballot

I am semi-retired now fom HL7, but I am still heavily involved in HL7-based implementations and feel a need to help avert a "crisis of confidence" in HL7. There have been important events since the Nov. 2006 harmonization votes on Concern (CONC), Condition Node (CNOD), and Condition (COND) despite the missing voting records regarding CONC in the RIM. One of the most important is that the CCD, with the Patient Care Concern Tracking Structure embedded in the Problem List and Allergy List (Alert) sections is now named in US HITSP-based regulations and is live in State government-based patient care activities such as in Alabama Medicaid HIE and the State of Tennessee Shared Health HIE. It would be horrible for a relatively minor missing voting record incident to cause a crisis of confidence in HL7 in the middle of the US Federal Recovery Act initiatives. CCD training, Schematron testing, registered templateID OIDs all support the Concern Tracking Structure in the CCD.

History: As referenced in this Cover document for the HL7 RIM proposal introducing the new Act.classCode "CONC (Concern)," a great amount of consensus building preceded the introduction to harmonization. The use of the term "Concern" rather than Condition Node in the patient care models for problem and allergy lists was suggested by OO (by then representative Gunther Schadow). Patient Care accepted the recommendation and brought the proposal to harmonization. At the same time, Structured Documents implemented a highly constrained version of the newly renamed "Concern Tracking Structure" in the CCD. Due to the limited ability of CDAR2 to support new classCodes, the instance of the "Concern Class" in the CCD had to be implemented as an "Act Class." However, the CCD Act.classCode used in the problem list and alert sections of the CCD is structurally the same as the CONC class in the Patient Care Concern Tracking Structure. The intent at that time was to implement the CONC class in the CCD with CDA R3 when new classCodes were supported. I was the harmonization steward for Patient Care and submitted the harmonization proposal. During discussion, I accepted a friendly ammendment from Woody Beeler to hold off on formally deprecating CNOD until we could make sure that no other committee wanted to use the class. In addition, it was thought wise by others to maintain the COND class as was. My recollection of the vote was that all clinical committees including PC, OO, Structured Docs voted to accept the CONC class as defined in the RIM and leave CNOD and COND in place. It might be helpful to poll the other stewards and find any who recollected voting against the proposal. In January, 2007, the Patient Care minutes show that Woody agreed to submit a definition modification proposal to harmonization to change the definition of CONC by substituting "issue" for "worry." This vote indicates that Woody at that time understood CONC to be "in the RIM."

Comment: Since Nov, 2006, no other TC has decided to utilize CNOD. After being present in the RIM, but unused for almost 10 years now, it seems reasonable to consider removing CNOD from the RIM. A number of implementations that I am aware of have found COND to be valuable in subtyping OBS (thereby differentiating a diagnosis from other kinds of observations). It seems reasonable at this time to continue RIM support of COND. However, in my humble opinion, it seems risky to HL7's reputation for M&M/Vocab to demand revoting on an established standard simply because someone misplaced some voting documents. It seems better to ask
the stewards who were present if anyone remembers voting against adding CONC to the RIM. If a majority do not remember voting against CONC, the reasonable solution is to add CONC to the HL7 RIM as a technical correction rather than requiring the whole process to be repeated. Again, this is no minor decision on
the part of an HL7 committee. This decision has ramifications throughout the US Federal Government, the vendor community, and the user communities using CCD in patient care. It is fair to consider a backwards-compatible revisions to the Concern Tracking Structure in the future based on the evidence from real users of the CCD. However, these revisions should occur through careful HL7 revision processes and with the representation of real CCD users, and not through clumsy process repair efforts in a single HL7 committee, most of whom are not direct users of the standard today.


Dan Russler, MDVP Clinical
InformaticsOracle Global Health Sciences Strategy

Jean-Henri Duteau wrote:

Although I agree with Keith that we should try to locate the final consensus, I do want to point out that the intent of a new submission was less due to the fact that it was missed so many years ago and more to do with the fact that the world has probably changed since the proposal was raised. Woody's point at the MnM Facilitator's Roundtable was that rather than PC stating that the old proposal should be resurrected and simply actioned, that PC should instead work to find the proposal and then resubmit it after ensuring that it is still valid with today's RIM and vocabulary and model requirements. It could very well be that the previous agreed direction is entirely valid and PC just needs the original proposal actioned. But it behooves us to ensure that is true.
Jean DuteauBoone

Keith W (GE Healthcare) wrote: I would push back on this. This was a rather long discussion over several months that was resolved and closed. We should make appropriateefforts to locate the final consensus. Re-opening this as a new Harmonization proposal because someone failed to keep up with the discussion seems to be an abuse of the process that we went through to come to that consensus. I'd be concerned that the direction it takes would be different from what was agreed upon previously.

Further reading:

Werner Ceusters and Barry Smith, “What do Identifiers in HL7 Identify? An Essay in the Ontology of Identity”, Proceedings of InterOntology 2009 (Tokyo, Japan, February 27-March 1, 2009), 77-86.

Richard H. Scheuermann, Werner Ceusters, and Barry Smith, “Toward an Ontological Treatment of Disease and Diagnosis”, Proceedings of the 2009 AMIA Summit on Translational Bioinformatics, 2009, 116-120.


Grahame Grieve said...

Hi Barry

I think your quoting Dan's email in this way is highly inappropriate. You have also cherry picked the various responses to Dan. For instance, you didn't include mine. Your comment is: "Why was the change of adding CONC and COND not made to the official RIM standard" is highly disingenuous - trying to portray a technical mistake as a policy issue.

I think you may have a point about condition vs act, but the continued errors of reporting and perspective this blog entry shows make it really hard to bother listening to your point.

KevinCoonanMD said...

I too wish to echo's Grahame concern that you seem quite liberal in quoting comments out of context and seem all to eager to find the most minute publication error as further evidence to support your "interesting" theory about how HL7 works or what you can do with the organizations work products.

While you at times do happen upon a legitimate concern about HL7, you do a great disservice to those who read your blog by misconstruing ongoing self critique by HL7, and discussion of very difficult technical issues as flaws. Should more people read (or care) what you publish, it could have a detrimental effect by stiffing the public discourse which marks a healthy SDO.

Since you are such an ardent lurker of the lists, perhaps you might wish to attend some of the frequent tutorials to give you a better working knowledge of HL7 methods and models, and then consider directly contributing to the ongoing efforts to find workable solutions.