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 dan.russler@oracle.com
Date: 23 May
2009 4:52:26 GMT+02:00
To: Jean-Henri Duteau jean.duteau@gpinformatics.com
Cc: "patientcare@lists.hl7.org" , MNM List , HL7terminfo ,
"vocab@lists.hl7.org " vocab@lists.hl7.org
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.

Respectfully,

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.
Sincerely,
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.
Keith

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.

The Data Model That Nearly Killed Me

A very interesting post:

The Data Model That Nearly Killed Me

in which Joe Bugajski describes how far we are from an electronic health record environment that would serve the patient. The situation described is one in which the patient, as he moves through the healthcare system, is called upon to answer questions, over and over again, in ways that give rise to multiple opportunities for inconsistency. Authoritative data about the patient's condition from the patient's own doctor is treated, at best, as just one minor ingredient in the mix.

One heroic medical professional, the first nurse I met in ICU, worked to create a consistent record of my condition, allergies, and medications in the hospital’s electronic health information system. She spent over one hour searching for previously entered data, correcting errors, and moving or reentering data. She argued with one doctor whose concurrent access to the hospital’s system blocked my nurse’s access to my information. She called the hospital’s pharmacy repeatedly to get my medications delivered. She met and called doctors several times. She even convinced one doctor and a pharmacist to come to my room to resolve data errors in person. Despite these heroic efforts, I never received correct medications during my stay. Indeed, my wife snuck one of my inhalers into my room. After I used it, I finally began to recover.

The inconsistencies arise, in part at least, from the absence of any consistent common framework for data entry on the side of the electronic health record. The HL7 RIM might conceivably contribute to filling this gap; but the RIM, as we know, is focused not on the patient's condition, or on the events transpiring on the side of the patient, but rather on the transactions of healthcare professionals. It rests, in other words, on a view of the electronic health record as a collection of statements “not about what was true of the patient but [about] what was observed and believed by clinicians” [1].

The exact causes of the problems documented by Bugajski are still to be determined. One way of summarizing the argument of this blog is that it seeks to make the case for a more incremental, evidence-based, and patient-centered approach to the EHR, and for a regime in which standards are imposed only when they have been proven in use.

[1] Rector AL, Nolan WA, and Kay S. Foundations for an Electronic Medical Record. Methods of Information in Medicine 30: 179-86, 1991.

Postlude (1) May 1, 2009
Another version of Bugajski's narrative can be found here, which points to do major problems which must be addressed if the vision of seemless interoperability of healthcare records is to be realized: the problem of building a consistent ontology of the enormous and rapidly evolving medical domain; and the shortage of people with the skills and training needed to realize this goal:

The first problem with modeling healthcare data is that models must represent certain concepts (and not others) that will remain stable and true long enough to be built into computer software then used by healthcare providers and patients. Mr. Obama, have you noticed just how much knowledge has, is, and will be accumulating in the medical sciences? Knowledge is codified using words - medical knowledge uses copious quantities of difficult words taken from several languages. Words that recur frequently in a particular context become imbued with a meaning that includes the context (e.g., the White House). Such words then come to symbolize a bigger idea than originally intended (i.e., a "house" that happens to be "white", versus your administration and not the house). In medicine, how many stable words exist? These words - nay, well-formed concepts, repeatable, agreed by the medical community - can be modeled and added to computers to store records. Go one step further. Specialization in ER, ICU, cardiac care, pulmonology, oncology, radiology, and other medical subjects exists because the cumulative knowledge defines a large ontology. The ontology, taxonomy, skills, and knowledge of an medical subject area then can be referenced with one word - the name of the specialty. Unfortunately, words that refer to a concept in one specialty often mean something different in another specialty.
The second problem is the lack of good modelers. These people, specialists in data engineering, a subfield of software engineering, transform concepts into graphical and lexical patterns that are used to create computer records. The concepts they model are words (nouns and verbs) plus concepts used by practitioners to describe a patient's medical condition, or a critical care pathway, medications, instructions to patients and nursing staff, tests, and diagnoses. Who among us has the modeling skills to encode this data? As information varies across specialties, how should it be encoded? Empirical evidence suggests that engineers who built the electronic health records network at the two facilities that "cared for me" tried to do this, but they failed. Their data model had irreconcilable silos of information spread across specialties and expressed as incomplete taxonomies (entities), inadequate ontologies (attributes), and poor associativity (relationships). Hence, when programmers added those bad data models to the health information systems, those systems later lost critical information about patients' condition, listed wrong medications,isolated prior diagnoses from current observations, in short, made very bad medicine.

Postlude (2): July 4, 2009
Joe Bugajski's Reply to "Proper Perspective Needed..." (April 21, 2009):

I admire, voted for, and strongly support President Obama. I support his vision of a National Health Network (NHN). I strongly disagree with his administration’s $20 billion conclusion that technology and technologists stand ready to build the NHN today. While I know little about practicing medicine, I am an authority (30 experience and many publications) in data interoperability and system integration. Hence, I cannot comment about treatment effectiveness - you and others generously provided these insights. I can write about data in the context of a system design.

The crux of the data model issue is this. If data cannot be made reliably available across silos in a single EHR, then this data cannot be made reliably available to a huge, heterogeneous collection of networked systems. Furthermore, poor quality data models and low quality user interface design convolve into serious data access and use problems for practitioners and their patients. Data models are my immediate concern relative to the NHN, but interface design also needs attention (also a fit subject for study in the NHN context). Further to data models, integration of information across an exceedingly complex, networked, data storage and retrieval topology remains an area of active research. (Indeed, my clients in every industry worldwide struggle with the issues daily - just for in-house systems.) Contrast data integration for NHN with the technology and expertise used to build the interstate highway system – 30 years of networked data knowledge versus 3000 years of road building knowledge. Consider too that technologically advanced, caring, and world-class medical institutions own and operate the troubled systems in question. These experts have immediate access to the best minds in computer, data, and network technologies. If they cannot reliably move data from one department to another, or across the street to from one to the other, how then do the rest of us cope?

--

New HL7 Ballot: Signs of Hope, but Confusion Remains

In 2007 the HL7 Board of Directors identified the need to review existing HL7 documentation in light of multiple unclarities and inconsistencies, some of them referred to in this blog (and also here). In the recently released Ballot Version 0226 of May 2009, we are perhaps beginning to see some evidence of the workings of this review, most notably in the fact that a much-cited nonsense passage present in earlier versions of the RIM documentation, according to which

there is no distinction between an activity and its documentation,

has been removed.

This is an important step, given the fundamental unclarity which has pervaded the RIM hitherto as concerns whether the items which the RIM calls 'Acts' are real processes (intentional actions) or records of such processes. HL7's official answer to this question thus far has been, absurdly, that the issue is moot, because there is no distinction between real processes and the records of such processes.

We hope now that the opportunity will be taken for further steps towards much needed clarity as concerns the interpretation of 'Act'. In the mentioned Ballot documentation we read:

Acts are the pivot of the RIM: domain information and process records are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.

Contrast earlier versions, where we were told that: "An Act-instance is a record of such an intentional action" (italics added). Are there now also some non-intentional actions the records of which we are allowed to count as Act-instances? If so, which ones? And what is a 'non-intentional action'? And what of of non-intentional events of other sorts, for instance snake bites, accidental poisonings, processes of infection, drug interactions, symptoms of disease?

Following on in the text, we read:

An Act-instance represents a "statement," according to Rector and Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30.]

What is the meaning of 'represents' in such assertions? And what (if any) is the distinction between an Act and an Act-instance? Are we to accept three distinct entities: the action performed in the real world, the record of this action (which record?), the statement in the electronic medical record? Or is the record identical with the statement in the electronic medical record.

Acts as statements are the only representations of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through the combination (and arbitration) of such attributed statements only ...

Do the authors of this documentation really mean 'The truth about the real world'? Or do they rather mean something like: the picture of or beliefs about the real world implied by a given body of documentation? What if the patient is dead, but the records do not show it?

A factual statement may be made about recent (but past) activities, authored (and signed) by the performer of such activities, e.g. a surgical procedure report, clinic note, etc. Similarly, a status update may be made about an activity that is presently in progress, authored by the performer (or a close observer), and later superseded by a full procedure report. Both status update and procedure report are acts, distinguished by mood and state (see Act.statusCode) and completeness of information: neither has any epistemological priority over the other except as judged by the recipient of the information.

Is a surgical procedure report truly an activity? Are a status update and a procedure report truly 'acts, distinguished by mood and state'? If so, are they also Acts? Lingering unclarities such as these are not resolved by the list of 'examples' presented by HL7 in the same document to help us understand correct usage:

Examples:
The kinds of acts that are common in health care include (1) clinical observations, (2) assessments of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) acts of assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others.

If editing and maintaining documents are acts, then are the records (and if so which records?) of these processes of editing and maintaining documents Acts? What is the relation between 'acts' and 'Acts', and between both of these and activities (and actions)? And how can a goal be a kind of act? (or Act?)

Big HIT

In an article in the New England Journal of Medicine [1], Kenneth Mandl and Isaac Kohane argue that spending billions of dollars of federal funds to stimulate the adoption of existing forms of health record software would be a costly policy mistake -- because current health record suppliers are offering pre-Internet era software, which are costly and wedded to proprietary technology standards that make it difficult for customers to switch vendors and for outside programmers to make upgrades and improvements. (We note that exactly this mistake was made in the United Kingdom with its Connecting for Health program.)

Mandl and Kohane propose instead that the government should be a rule-setting referee whose role would be to encourage the development of an open software platform on which innovators could write electronic health record applications in a way which would open the door to competition, flexibility and lower costs. They point to an analogy with Apple's IPhone platform, that anyone can use or write applications for.

This is, of course, a good idea, since it would bring in its wake the opportunity for thorough testing of particular applications before they are extended to larger communities of users. The potential flaw, of course, is that it leaves open the question of what the government-imposed framework of rules should be. The HL7 organization (founded in 1987) continues to be mightily influential in government circles. Consider, to take one simple example, the case of XML. Will it be XML itself that is government imposed? Or will it be HL7-XML, a peculiarly complicated non-standard version of XML resting on an idiosyncratic approach to development that is at odds with the approaches taken by developers with XML expertise?

[1] Kenneth D. Mandl, M.D., M.P.H., and Isaac S. Kohane, M.D., Ph.D. "No Small Change for the Health Information Economy", New England Journal of Medicine, Volume 360:1278-1281, March 26, 2009. See also New York Times, "Doctors Raise Doubts on Digital Health Data", March 25, 2009.

Why Make It Simple If It Can Be Complicated?

In a document entitled

Ten good reasons why an HL7-XML message is not always the best solution as a format for a CDISC standard

Jozef Aerts, an XML expert at XML4Pharma, has examined the on-going attempts to format new CDISC standards as HL7-XML messages.

These attempts reflect the desire for integration, given that HL7 is well-established in the healthcare world, that XML is itself a global standard of growing importance, and that the FDA is already using a number of HL7-XML-based standards.

As Aerts points out, however, there are a number of problems: 1. it is an XML-free HL7 v2.x that is well-established; 2. HL7-XML is an embarrassingly complex non-standard version of XML, with little in the way of software tool support; 3. HL7-XML causes problems which standard versions of XML avoid; 4. the movement to HL7-XML seems to be especially supported by people that have never been actively been involved in XML development (and to be supported often for reasons political rather than computational, clinical or economic).

HL7-XML messages take years to develop and are nearly always overcomplicated:

Those who have ever inspected an HL7 aECG-XML file in detail, may have been surprised by the enormous complexity of the XML. One of the reasons for this is that the XML structure (as defined in its XML-Schema) is not developed by XML specialists, but is derived from UML diagrams. I have been teaching a lot of XML in the last ten years and have experienced that CDISC ODM can be learned in a one day course. No chance however to accomplish this with aECG. Therefore, the amount of people that really understand aECG-XML is very limited, this in contradiction to the amount of people that understand ODM-XML.

Similarly, though XML is usually defined as being “as well machine-readable as human-readable”, one may question whether the latter is applicable to some HL7-XML messages such as aECG: not only the complexity is overwhelming, but it also uses a lot of code ununderstandable for the human reader.

In 2006, Gartner issued a Note entitled "HL7 V3 Messages Need a Critical Midcourse Correction", stating that “HL7 must act vigorously to make Version 3 messages easier to use and more compact” (See e.g. here.)
The direct consequence of this overcomplexity is that it is much harder (and thus much more expensive) to develop software to read and write HL7-XML than it is for ODM-XML. From my personal experience (30 years) in software development, I estimate that the cost of developing softwarefor a complex HL7-XML message is at least the twentyfold than it is for ODM-XML.

Once again, therefore, HL7 chooses an idiosyncratic approach to development that is at odds with the approaches that have been tried and tested elsewhere -- with results which might have been anticipated (some of which were indeed anticipated on this blog, for example here).

As Aerts continues:

HL7-XML messages are developed in a somewhat curious way: first of all one or more UML diagrams are developed, and then the XML-Schema is derived from the UML. The UML is derived from the RIM (HL7 Reference Information Model) which currently has over 70 versions (!). Though the use of UML may be the perfect and well-established way for translating a software design to software classes, it is considered bad practice by XML specialists. Transformation of UML to XMLSchema in general leads to “spaghetti XML”, introducing unnecessary complexity. Of course it is an “easy” way: the world has much more UML specialists than it has XML-Schema specialists.

Personally, I would consider transformation of UML to XML-Schema the “lazy man's way”. The result can however be catastrophical. By the way, none of the most popular XML-based standards, such as MathML, VoiceXML, XHTML or XForms etc. have ever been developed using UML.

Aerts provides a series of examples to illustrate the problems and costs caused through use of HL7-XML, problems which are avoided if one uses XML in the standard way recommended by XML experts.

Addendum (April 10, 2009):

Some comments on Hacker News:

I don't know anything about HL7 or HL7-XML, but this sounds like letting loose people that dont know zilch about the implementation side of things. In this case HL7 is translated into UML because the people involved know UML, not XML. Then the UML is translated into XML by the push of a button, generating monstrous XML. Rant: dont let your tools substitute for personal knowledge of the domain.

How can someone not know XML when it's actually relevant to their job? It's just a tree with a fairly simple structure. Anybody who avoids learning XML because they already know UML is just not even trying. Seriously, learning it takes like half an hour at most.

HL7... what a nightmare! I remember having to work with it, and it was a convoluted solution where every provider and vendor had a different interpretation. As bad as 2.3.1 is, it's still worlds better than 3. The best thing that can happen is for 3 to be scrapped. The worst part is its model. I worked with it for the purposes of PHIN-LDM, and I've never seen a worse clusterfuck. It made dailywtf look positively logical.

I've written my own HL7 (pre-XML v2.x) message parser and generator in Java for work. I'd really like to not have to touch that code again, if possible. My code is easy enough to understand, but I don't want to have to rewrite it support this non-standard XML. Just putting XML on the name of something doesn't instantly make it all easier.

Information and Communication Technologies Standards in the Health Sector

A new study has been released on behalf of the Enterprise & Industry Directorate General of the European Commission on the topic of ICT standards in the health sector: current situation and prospects.

The study contains a number of interesting remarks on HL7, for example welcoming the current initiative towards greater collaboration between HL7, ISO and CEN.

But there are also critical remarks, for example to the effect that:

Small or medium-sized ICT manufacturers may not be willing to adopt commonly used standards because these are very complex and thus difficult and expensive to implement. This applies for example to HL7 version 3. It may be less costly to develop proprietary standards on their own. (p. 21)

And also this:

HL7’s v2.x standards were important steps towards standardising clinical messaging. However, several issues caused difficulties, above all different options to implement the standard. To correct this issue, the RIM was developed for v3.0, eliminating most of the implementation options. The concept behind HL7 v3.0 has been generally well received. However, the RIM caused new problems. Firstly, it is unlikely that the defined RIM classes and attributes could be applied to every domain in healthcare – which is what they are intended to do. Secondly, the RIM documentation is described as being “disastrously unclear”, poorly integrated with HL7 v3.0 documentation, and inconsistent.

Under these circumstances, it may be difficult for HL7 v3.0 to establish a large user base. ... HL7’s involvement in the joint initiative with ISO and CEN may have the objective to move faster to international adoption of HL7 standards. The outcome of this convergence work as well as the organisation’s ability to create a satisfactory RIM may determine the future importance of HL7. (p. 37f.; emphasis added)

Does the emperor have clothes?

This set of slides from a recent presentation by Eric Browne at an Australian national e-health conference provides some reassurance that the arguments I have been making on this blog are perhaps not simply the product of my own ignorance. Summary: "Basing clinical information interoperability on the HL7 v3 RIM is severely flawed. It is too complex; the underlying principles are unproved and highly suspect. The complexity leads to bad models, glacial progress, compromised quality and safety."

Postscript: Feb. 15, 2009
A more recent post by Eric Browne documenting problems with HL7 Clinical Document Architecture (CDA) is here.

Barriers, approaches and research priorities for integrating biomedical ontologies

Alan Rector has published an impressive survey of what we can expect for terminologies and ontologies in healthcare in the next ten years. Summarizing a long document, Rector believes:

• HL7 (a mix of versions) will dominate the standards for messaging.
  
• The standard for EHRs is likely to be a combination or amalgam of the HL7 CDA and Archetype based standards from OpenEHR, CEN EN 13606.
  
• Terminologies from biomedicine, particularly the Gene Ontology and the associated ontologies in the Open Biomedical ontologies consortium will become of increasing importance to clinical medicine.
  
• Following the example of the bioinformatics community, open systems “owned” by their community are likely to make an increasing contribution.

Rector echoes a number of what one might be tempted to call 'philosophical' points addressed in this blog as concerns the relations between ontologies and information models. He nicely summarizes these points as follows:

The relationship between knowledge representation and ontologies remains controversial and plagued by confusion of substance compounded by loose use of language. A second closely related notion is that of an “information model” of “model of data structures”. Both Archetypes and HL7 V3 Messages are examples of data structures. Formalisms for data structures bear many resemblances to formalisms for ontologies. ... However, there is a clear difference.

• Ontologies are about the things being represented – patients, their diseases. They are about what is always true, whether or not it is known to the clinician.For example, all patients have a body temperature (possibly ambient if they are dead); however, the body temperature may not be known or recorded. It makes no sense to talk about a patient with a “missing” body temperature.
  
• Data structures are about the artefacts in which information is recorded. Not every data structure about a patient need include a field for body temperature, and even if it does, that field may be missing for any given patient. It makes perfect sense to speak about a patient record with missing data for body temperature.

A key point is that “epistemological issues” – issues of what a given physician or the healthcare system knows – should be represented in the data structures rather than the ontology. This causes serious problems for terminologies coding systems, which often include notions such as “unspecified” or even “missing”. This practice is now widely deprecated but remains common.

Under 'desirable outcomes', he lists:

The methods will become increasingly formal. The conflict between the scaling problems presented by pre-coordinated terminologies and the difficulty of maintaining consistency with post-coordinated terminologies will be overcome. To this end, the formal structure of SNOMED-CT and will be radically revised to take advantage of its purported underpinnings in description logic. HL7 v3 and/or Archetypes will likewise be reformulated to take advantage of modern technologies to ensure their mutual consistency and consistent binding to the new terminologies. Common links to terminologies from OBO and others used in molecular biology will be forged.

And under 'outcomes to be avoided':

enormous resources will be spent on over-ambitious plans for semantic interoperability that inevitably fail. In either case, communication will take place by going around rather than via the clinical information systems. In countries where it is mandated, SNOMED and HL7 V3 will become taxes on healthcare, absorbing significant resources while returning no, or in some cases negative, benefits.

The document as a whole contains a wealth of important material on HL7 V3 -- and SNOMED CT -- and on the problems associated with each. It draws special attention to HL7 15 year-long planning process designed to produce a '“version 3” that is not yet in routine use'.

Flavors of Null

Interesting post from Ananda Mohan concerning the problems created by HL7 v3's lack of support for any kind of optionality. One result of this policy is that codes need to be provided in advance to cover all cases where information is missing -- hence the multiple 'flavors of null', which, are listed by Mohan on the basis of the latest HL7 v3 ballot pack as follows:

1. NI: "no information" - this is the most general and default exceptional value. There is no information which can be inferred from this exceptional value.

2. MSK: "masked" - this particular item has a known proper value, but it cannot be released in a given context due to security, privacy or other reasons.

3. OTH: "other" - there is a value, but it is not an element in the value domain of a variable, with particular cases:
- NINF: "negative infinity of numbers"
- PINF: "positive infinity of numbers"

4. UNK: "unknown" - a proper value is applicable, but not known. In particular:

- ASKU: "asked but unknown" – information was sought from the source but not known (e.g., patient was asked but didn't know)

- NAV: "temporarily not available" - information is not available at this time but it is expected that it will be available later.

- NASK: "not asked" - the Information was not requested from the patient

- QS: "sufficient quantity" – The actual quantity is not known but sufficient enough to achieve a specific goal. For example the advice can be: add a sufficient quantity of water to 10 mg of medicine.
- TRC: "trace" – The content is too small to measure but still a non-zero value.

5. NA: "not applicable" – There is no proper value for this data item for this patient; for example, the date of the last menstrual period is not applicable for a male.

All of these “flavors” are provided for every data type. Thus for example “null” is a possible value of an integer or real alongside actual integer and real values As Mohan points out, this might lead to reasoning problems: the HL7 definition of 'Boolean', in contrast to every working formalism, implies a 3-valued logic. The null flavors are causing problems also for the (surely in any case premature) attempts by ISO to model its health data types standard (ISO 20190) on HL7 v3 data types. Organizations such as CEN have, it seems, opposed the current ISO draft, in part because of the problems generated by the usage of null flavors.
These problems were described in detail already five years ago in a document on the openEHR Data Types Information Model, the latest version of which is here:

All HL7 data types inherit from the ANY class (equivalent to the DATA_VALUE class in openEHR) which contains the attributes:

BL nonNull;
CS nullFlavor;
BL isNull;

The purpose of these attributes is to indicate whether a datum is Null, and for what reason. Since some data type classes also appear as the attributes of other data types, the Null markers also ndicate whether any part of a datum is null. ... this allows an interval with missing ends and width to exist as a structured type. The consequence of the approach is that the entire model is essentially a model of "partial" data types; any attribute and any function call may return a Null value, as well as the true values of its type (in fact, in the specification, Null values are defined to be valid values of all data types).
This design decision was taken in HL7 so that any datum, no matter how unknown, would be structurally representable in the same way as completely known data, enabling it to be processed in the same way as all other instances of the same type. However, an important object-oriented design principle has been ignored in this approach. In the proper design of classes, properties and class invariants are stated. Invariants are statements which describe the correctness conditions of instances of the class; the general rule is that the post-condition of a creation routine (constructor) of a class must be that the invariants are satisfied. For example, an invariant of the HL7 IVL class could be:

(exists(low) and exists(high)) or else
(exists(low) and
exists(width)) or else
(exists(width) and exists(high))

When an instance of this class is created, this condition should be satisfied, and remain satisfied for the life of the instance. To do otherwise is to create instances ofdata which other software can make no assumptions about, and is forced to check every single field, and then determine what to do in an ad hoc way. ... Possible consequences of the built-in Null marker design approach include:

• since even HL7’s basic types ST, INT, REAL, LIST<>, SET<> include null markers, processing of null values will be pervasive at the lowest level;

• software will be more complex, both implementations of the data types, and of software which handle them. This is because the software always has to deal with the possibility of calls to routines and attributes returning Null values. Most clinical information systems to date have taken the approach that a datum is either represented as an instance of a formal type if fully known, or else as narrative text if only partial;

• data may not be always be safely processable, since some software may not properly handle the null values associated with attributes of partially known data items.

Essentially, all software which processes the data has to be “null-value aware”, and make no assumptions at all about whether a particular data instance is valid or not.

For all of these reasons the HL7 data type model is in stark contrast with the much simpler approaches used in CEN and in openEHR.


Postscript May 23, 2011

See also now here: http://wolandscat.net/2011/05/18/the-hl7-null-flavor-debate-part-2/

How does one refer to an organism in a microbiology report?

Is an organism an entity? Or an observation of an entity (thus, presumably, an observation of an organism)? Can it really be true that, after ten years of HL7 RIM development, the answer to this question is still not clear?

As the useful Resources page of HL7 Australia makes clear:

At first site the RIM is quite simple. The RIM backbone has just five core classes and a number of permitted relationships between them.In HL7 V3, every happening is an Act, which is analogous to a verb in English. Each Act may have any number of Participations, in Roles, played by Entities. These are analogous to nouns. Each Act may also be related to other Acts, via Act-Relationships.Act, Role and Entity classes also have a number of specialisations. For example, Entity has a specialisation called Living Subject, which itself has a specialisation called Person. Person inherits the attributes of both Entity and Living Subject.

Organism, too, is a specialization of Entity, we might reasonably suppose. Thus an organism is not a Role, not a Participation, not a Relationship, and also, we presume, not an Act. That an organism is an Entity is indeed the view embraced by advocates of HL7 in their oral discussions with me over the question whether the RIM can be taken seriously as a representation of the healthcare domain.

Not so for everyone in the world of HL7, however – at least not according to what we can infer from this:

Hi,
I have been working with people at CDC on using V3 messaging to convey microbiology reports among other things. In discussions today, the question came up of where in the Microbiology specification was the observation that identified the organism for which susceptibility results were being passed. I said, well no, the organism was indicated as an entity playing the role of isolate and participating in the "specimen observation cluster". But, I was told, the CDA hospital acquired infection report carried this as an observation, and indeed it does. Is this a problem to be addressed? Or a characteristic of V3 to be managed? It does seem clear that the two specifications have been underway in parallel [*], so it is, if not pointless at least difficult, to say which should be allotted precedence. What ideas do people have?
Mead

*This is exactly the thesis defended here.

News from Stockholm

More from Stockholm County Council, and its ambitious healthcare IT system, the GVD, sometimes advanced as a success story of HL7 V3:

We chose Oracle Healthcare Transaction Base because it complies with the worldwide HL7 standard for clinical data, and because it comes from a major international company, committed to supporting, developing, and refining the product over time. When we conducted a market evaluation, Oracle also came in at the right price. – Jack Robinson, IT Manager, Stockholm County Council

In an article entitled "Missarna som knäckte GVD" (roughly: Flaws in the Cracked GVD"), Madeleine Bäck reports on the recent history of the GVD project, which continues to move from crisis to crisis:

Heavy criticism is directed towards the choice of storage system for GVD, the so-called HTB database, which was acquired from WM-Data and its partner Oracle in 2004. 'Our pilot tests point to catastrophic performance when loading data to the system. We also observed that it would be incredibly complicated and expensive to adapt HTB to the GVD', explains one involved person (who however chose to remain anonymous). The suppliers who built the GVD are aware of the criticism, but they do not agree with all aspects: Pia Kullstrom, head of Public Sector and Healthcare at WM-Data, pushes back specifically as regards criticism of the HTB system. This is not based on facts she claims, but rather on people having a different product-religion.

I am told that features of the GVD marked out as problematic include:

1. The poorly functioning BAT&Portal (for authentication and authorisation services), which uses HL7's CCOW (Clinical Context Object Workgroup) standard protocol, and is supposed to be a web-based, single point of entry and single sign-on access route to the different parts of the system.

2. For writing data to HTB the performance is 'still horrendous', even though Oracle re-wrote the whole implementation for reading data through their API after Stockholm had already accepted the HTB product.

3. GVD has a strongly centralized architecture, but its protagonists did not address the question of how to handle the legacy systems during the transition period. Many of the latter are fully functional, mission critical, clinical systems. Centralized architectures, in which the attempt is made to consolidate semantically non-interoperable data from hundreds of databases into one, are show-stoppers.

As a whole, GVD is a classical "big bang" project, where the thinking has been quantitative, not qualitative, and the Stockholm political leadership has admitted that GVD is an "IT-fiasco".

But the responsible civil servants remain in denial, and there have not as yet been any signals to the effect that they are going to back down from HTB. This raises one further problem: GVD has Oracle HTB, and thus HL7 V3, as central component. One can state with high confidence that HL7 V3 is not going to be the standard at national level for interchange of clinical data in Sweden. So what is Stockholm going to do?

The weight of the baby

HL7 RIM, as we have pointed out on too many occasions, confuses observations with the entities observed. To illustrate this confusion once again, we provide the following scenario, from Werner Ceusters (WC), with reactions from Dan Russler (DR), as they appeared on the HL7 vocabulary list. (Dan played a key role in the development of the HL7 Reference Information Model.)  We added some small clarifications and corrected some spelling errors (and perhaps, by trying to work our way through the numerous levels of comments on comments, we might have overlooked some dependencies). Dan and Werner are free to suggest corrections. (To access the Archives of HL7 lists one can go to: http://www.hl7.org/listservice)

Here we go:

WC to DR: I am in a delivery room, and there is that baby and his weight. When I want to register something about that baby's weight, I will use the symbol "#w-1234" to denote that baby's weight. The numbers are there to differentiate that baby's weight from some other baby's weight. The baby's weight is something that has different values at different times. The baby's weight endures through time. It is a continuant.

I want to obtain a value for the baby's weight, for which I have to perform an act of measurement, for which I will use the symbol "#m-5678". The ID numbers are there to differentiate that measurement from other measurements I might perform, even from the measurement which I might do a few minutes later when I weigh the same baby for a second time. The act of measuring occurs at a time. It is an occurrent.

The act of measuring gives me a magnitude, which in this case is something we have been taught to register as "4.7 kg". Now registering that (entering "4.7" into a computer, for instance) is an act in its own right, and when I want to refer to that registering act, I will use the symbol #r-881 (you get the picture, I hope).

Now you (Dan) seem to argue that I am not allowed to assign some of these symbols, though I can't figure out from your comments which one(s) precisely you object to. You should clarify. Here are the symbols again, for easy reference:

#w-1234 : THAT baby's weight
#m-5678 : THAT process (which occurred during THAT time) of measuring THAT baby's weight
4.7 kg : the value obtained for THAT baby's weight through THAT process
#r-881 : the further process of entering the obtained value in some record

DR: The baby is a collection of molecules ...

WC: Sure; but that is not relevant here.

DR: Why isn't the fact that the baby is made of molecules relevant? ... The baby wouldn't have a weight without being made of molecules.

WC: If the task is to register the magnitude of that baby's weight in a record, there is no reason to mention his molecules. We also don't talk about those other molecules on the side of the Earth that attract the baby's molecules, do we ?

DR: The weight is the measurement of the force of attraction between the baby's molecules and the earth at that location and at that point in time.

WC: "No" on several things. First, the weight of the baby is not a measurement at all.

DR: You will need to go back to the physics definition of weight. Objects have mass, which create a mutual force of attraction.

WC: Thanks for this lesson, again; although I said in my mail that I knew that. It is simply not relevant.

DR: Weight is simply the concept of putting a scale in between two masses and measuring the force of attraction between two masses, the baby and the earth. You could abstract out the idea of measurement, but then we would just say "force of attraction," not weight. Of course the force of attraction between the baby and the earth is less in Denver than at sea level. So perhaps you could alter your discussion to match the real physics of the situation?

WC: That doesn't change anything to the simple task at hand: putting a baby on the scale, and reading what the instrument gives as weight. Dan, stick to the topic.

DR: Now this illustrates the problem with comparing "your reality" to "my reality."

WC: There is only one reality, but we can describe it in different ways. Your way seems to be to lump important things together (e.g. that baby's weight and my activity of measuring that weight), and to add irrelevant things (such as the molecules of the Earth)

DR: You invent things in your mind in the discussion below that I have not invented in my mind.

WC: I didn't invent anything. I gave a description of a simple scenario and I introduced 4 symbols. You started to mix and confuse the symbols, and bring in others.

DR: When you communicate what you invent, you use words that mean something different to me (and to many other people). Although I respect the inventions of your mind, I don't understand them, and when you explain them, I don't always agree with them.

WC: Then, if you still don't understand the scenario I described, and what the four symbols stand for, give me a language in which I can describe it so that you will understand it.

There is something that you can measure (the baby's weight), and an act of measurement, which is a different thing. The value for the weight that you obtain by measuring it is yet another thing. The word "measurement" is often used ambiguously to denote the last two things: the measuring act and the value obtained through the measuring act. It would be good for everybody's understanding not to use language ambiguously in this way. (Compare it with the noun phrase "the cut" which is used for both the act of cutting and the gap that results from this act.)

[Ceusters here tries to describe what at first might seem hard to swallow: the weight of this baby is the same entity from one time to the next. It is an enduring attribute of the baby. Certainly the baby's weight changes over time, but then so also does the baby. But just as the baby stays the same individual from one time to the next as it changes, so also does its weight. The baby's weight is a continuant. At any point in time, that weight has a precise magnitude, but which magnitude this is changes from one time to the next. - BS]

The discussion continues:

WC: All that gravity stuff is irrelevant here, because if I or a nurse put a baby on a scale to measure it's weight, I know what I'm measuring. I was and I am not talking about other stuff you can measure.
Again, I will use the symbol "#w-1234" to denote that baby's weight.

DR: Werner has in his mind the idea of "the force of attraction" and created a symbol #w-1234 to communicate the force of attraction between the baby's molecules and the earth at that point in time.

WC: No on several things, again: I had nothing regarding forces of attraction in my mind. In fact, I was describing a concrete delivery room situation.

DR: Doesn't gravity exist in the delivery room? Gravity sounds pretty concrete to me.

WC: Sure, but this fact is irrelevant. There are at least a billion other things in that room, such as the molecules in the door knob. I used explicitly demonstrative particles to make it clear: There is "THAT" baby. I'm not talking about conceptual representations of babies and delivery rooms, but simple things: babies and rooms.

"#w-1234" is the symbol that I use to denote that baby's weight in a description, NOT the magnitude of the weight.

DR: Now this symbol "#w-1234" has attributes associated with the symbol, such as:

time (since the weight will vary with time);
location (since the weight will vary with the location, e.g. altitude);
identity of the baby (weight will vary with different babies).

WC: Many more "no's". The symbol "#w-1234" may have attributes associated with it, but I did not talk about that.

DR: on the contrary, you gave the symbol attributes "the symbol #w-1234 ... to denote that baby's weight". To transform to a formal propositional grammar:

the symbol #w-1234 dentotes the weight of that baby
object of the predicate: "that baby"
predicate: "denotes the weight"

WC: Dan, the symbol I introduced here is "#w-1234". I told you what the symbol stands for: that baby's weight. You can decompose that in as many ways as you want and I can give fifteen other grammars and NLU paradigms for you to analyse the way I said things; but you must at some stage get back to the topic. We are not analysing the lines of text that I produced, we are analysing what the lines of text try to convey. But the fact that you insist on analysing it this way, demonstrates that you are not able to get passed the language level.

Let's try it this way: "#w-1234" is a symbol. It is composed of the characters "#", "w", etc. I use it in a language to refer to / to stand for that particular baby's weight, a particular entity in reality, not an element of a language. I could use another symbol for that baby's weight. Thus I could use the symbol "that baby's weight'. I could then say "that baby's weight" stands for that baby's weight.

Attributes of the symbol may be the number of characters, the font used, etc. I am not studying symbols for the sake of this discussion. But interestingly, Dan, it is becoming clear at this point that you (perhaps because of the inadequacy of the representation language you choose to use) confuse the symbol with what the symbol stands for, a common mistake made by people who misunderstand semiotics, and a confusion which pervades the entire RIM, as we and others have shown.

Dan, it is surely the case that the words I used in the language of that paragraph are symbols, but we are not talking about the language in that paragraph. We are talking about the state of affairs in reality of which that paragraph is a linguistic representation. And you darned well know it, Dan, come on.

DR: I just tried to understand what you mean (perhaps not always in the same way as what is in your mind) or what the relationship is in your mind to what is occurring in the delivery room.

WC: I told you: that is irrelevant. That is "Wusteria". If I am talking to you about my mother, then I am not talking to you about some neuronal blurb in my brain. I am talking about my flesh and blood mother.

DR: If there is a problem with me understanding what you created in your mind, is that your problem, my problem or both our problems?

WC: If I was obscure or ambiguous, it would be my problem. But I was, repetitititititively, quite specific.

DR: Surely, my difficulty in understanding what you invented doesn't change what happened in the delivery room!

WC: The weight of the baby will change over time, the symbol will not. You may perhaps not like my symbol and would use another one. That is fine with me, as long as we make it clear for each other that these symbols denote the weight of THAT baby, not the magnitude of THAT baby's weight.

Thus, again, I use the symbol ONLY for THAT baby's weight, not for any other baby's weight. I made that quite clear, but you ignore it, and I am interested in knowing why you ignore it. I repeat thus about that symbol: "The numbers are there to differentiate that baby's weight from some other baby's weight."

DR: I am happy to be corrected on what you meant to say. Can you explain how I know how to figure out the baby's identity and the name of the force of attraction (not the magnitude of the force as you suggest) from the symbol #w-1234?

WC: Excuse me ? Do you not know how a baby looks like ? If I am in a delivery room, and they ask me to take the weight of that baby, I don't think I would grasp some bucket and measure its diameter. Or do you mean literally what the name is of that baby? I don't see what that has to do with that baby's weight. It has to do of course with putting the value in the right record. But again, that adds nothing here to the discussion.

DR: Symbol #w-1234 has common name: "weight"

WC: No! that symbol denotes the weight of THAT baby. The symbol itself certainly does not have the common name "weight". It might be given the common name "symbol" though. You can use the common name "weight" to denote that baby's weight, but that is imprecise and may lead to exactly the sort of confusions that you exhibit.

DR: I can agree to narrowing down my understanding of #w-1234 if you can teach me how to make sure the symbol unambiguously represents the baby's identity and other things that affect the force of attraction between the baby and the earth.

WC: Because I told you. "#w-1234" is the symbol that I use to denote that baby's weight. If you were there, I would have pointed to the baby. If not, I could show you a picture, or you would get other information related to the parents, etc. All that information could be put in some symbol dictionary or look-up table. And no, the idea is NOT to infer it from the form of the symbol itself. I think that the notion of no meaning IN the code is broadly accepted.

DR: Symbol #w-1234 has definition: "the force of attraction between the baby's molecules and the earth at that location and at that point in time

Symbol #w-1234 "has location: delivery room "latitude-longitude-altitude"

Symbol #w-1234 has time: TS

Symbol #w-1234 has baby: identity of baby

WC: No ! I did not give a definition. And if I would have done so, it would have been a quite different one.

DR: Since a physicist, or a physician, would give the definition I inferred from your use case, which would you supply?

WC: That is irrelevant in this case. We are talking about the simple notion of weight.

DR: Once the symbol "#w-1234" is created in Werner's mind and written down and re-created in my mind ...

WC: The symbol is on some bearer medium. Whatever happens in my brain is irrelevant here. The symbol is for sure not "created" there. Something will happen there, of course, some state of affairs involving neurons and neuro-transmitters and so forth, and there is some relationship between the symbol on the medium and the state of affairs in my brain. If I would wish to say something about that particular state, I would use another symbol for that. At that point, I could imagine that you would say: "Ah, you see, you assign another symbol to that symbol", but if you did, then clearly you did not get the point.

DR: We can communicate using the symbol.

WC: Right, and independently of whatever our brain does in this case, because we agreed (I hope, finally) that we use "#w-1234" ONLY to refer in descriptions to THAT baby's weight (NOT its magnitude, NOT the act of measuring in order to determine this magnitude, ...)

DR: However, the weight is still the force of attraction between the baby's molecules and the earth.

WC: probably, but irrelevant.

DR: Not irrelevant to me, because the force of attraction, the earth, the baby, the people like you and me, are the only things really existing in my reality. Everything else is made up in your mind. What is in your mind is important to me, but I don't confuse what is in your mind with my reality.

...

DR: When you say "obtain a value for the baby's weight, for which I have to do a measurement" you add a new attribute to the symbol for weight: "value"

WC: no ! In the sentence above, I didn't mention or introduce another symbol at all. The symbols I introduced were:

#w-1234 : THAT baby's weight
#m-5678 : THAT process (which occurred during THAT time) of measuring THAT baby's weight
4.7 kg : the value obtained for THAT baby's weight through THAT process
#r-881 : the process of entering the obtained value in some record

I did not introduce the symbol "value".

DR: Your whole paragraph is made up of symbols. Above, you just pick out several symbols from the paragraph and throw away the rest.

WC: Try not to confuse the readers by throwing in another level of symbols. I was quite specific about what the symbols I was talking about are. All, except the "4.7 kg" started explicitly with #.

DR: In any case, I now see you added to your story the term "process".

WC: ... in a humble attempt to make you see the difference between (1) what is to be measured, (2) measuring itself, (3) and the value obtained through the measuring.

DR: ... and defined 2 processes:

1) #m-5678 : THAT process (which occurred during that time) of measuring THAT baby's weight
2) #r-881 : the process of entering the obtained value in some record

WC: I didn't define these processes. In the scenario, these are two processes which are relevant to our discussion (because you confused them) and for which I introduced two different symbols.

DR: It is helpful for me to know that you feel these are two processes, which represent the movement between three states. Thank you for the extra detail. In my mind, that communicates the standard state transition model where process describes the movement from state to state.

WC: I am not responsible for the limitations in your language of choice, i.e. the standard language of state transition models. If you don't get the right results by using that state transition stuff when addressing this scenario, then don't blame me; blame your language.

DR:
State 1: pre-condition to Process #1

Process #1: #m-5678 : THAT process (which occurred during that time)of measuring THAT baby's weight

4.7 kg : the value obtained for THATbaby's weight through THAT process

State 2 is both the post-condition of Process #1 and the pre-condition to Process #2

Process #2: #r-881 : the process of entering the obtained value in some record

State 3: is the post-condition of Process #2.

DR: You said, "When I want to register something about that particular measurement, I will use the symbol #m-5678".

Here you identify the measurement with a symbol and fill in the value with a symbol:

#m-5678{symbol #w-1234
has common name: "weight"
has definition: "the force of attraction between the baby's molecules and the earth at that location and at that point in time ...

The act of measurement, which gives a magnitude which in this case is something that we have been taught to register as '4.7 kg' , he identifies with the symbol

r-881
has location: delivery room "latitude-longitude-altitude"
has time: TS
has baby: identity of baby
measurer: Werner
value: #r-881

WC: No ! Again, you confuse the measurement (the act of measuring) with the weight of the baby. It is for THAT measurement act, that was performed to get a value for THAT baby's weight, that I use the symbol "#m-5678". I can then use that symbol to document, for instance, that the measuring act took 55 seconds to perform.

Furthermore, I didn't fill in any value.

Furthermore, you erroneously equate #r-881 with that weight, which I clearly (or so I thought) explained r-881 to be the act of registering the obtained value in a record. I wrote that:

The measurement gives me a magnitude which in this case is something that we have been taught to register as '4.7 kg'". Now that act of registering (entering "4.7" into a computer, for instance) is an act in its own right, and when I want to refer to that act, I use the symbol #r-881 (you get the picture, I hope).

But clearly, you didn't get the picture, confusing now THREE things.

DR: I must apologize for not clearly discovering what is in your mind. Again, is that my problem or our problem? If what you want to achieve is good communication, you have to be very clear for those of us who can't read your mind.

WC: You didn't have to read my mind. You only had to read what appeared on your screen after opening my message. Again, if you are not able to distinguish the symbols that I introduced from the natural language that I used to try to describe to you what they stand for, then suggest a better language.

DR: I see from your explanation of process above, that you meant to use the symbol "#r-881" to represent "the process of entering the obtained value in some record".

WC: Yes !!!!!!!! Great !!!!!!!!!

DR: ... and not the magnitude of the force of attraction. I would ask however, other than communicating the symbol"#r-881," what gets communicated along with the symbol in process #2, the process of entering the value in the record?

WC: I didn't say anything about that, as yet. But stuff that might go there is, for example, how long it takes to enter weight values in a record (interesting for comparing user interfaces from an ergonomic and effort required perspective) or who entered the data (that gives you the culprit in case of mistyping) or when the data was entered (the weight was taken at time t, but the registration at t+1).

DR: Summary: I believe these are the symbols you assigned in your own mind and communicated in your paragraph.

WC: As I explained above, your belief is wrong.

DR: Here is how I created the communication in my mind and communicated it back -- is my creation in my mind wrong from your point of view?

WC: yes, indeed. You confused several different entities.

DR:

Act.ii = #m-5678
Act.code = "3-1234 (weight--the force of attraction between the baby's molecules and the earth at that location and at that point in time)
Act.effectiveTime = TSAct.observation.value = #r-881
Act.participantMeasurer = Werner
EntityPatientRole = identity of baby
Entity.location = "latitude-longitude-altitude"

WC: On the basis of what I described above, you must identify at least 2 acts in HL7-speak, and not just one as you came up with: one is for measuring the weight of that baby, the other for registering the value obtained through the former in a record. Furthermore, there must be at least three non-act entities: the baby, its weight and the magnitude of this weight at the time of the measurement (i.e., first act). Now I can accept that this detail is not relevant for many purposes and that therefore you don't want to register these things (although then I don't understand why you consider the baby's molecules and the gravity of the earth to be of relevance here - and please, don't take the latter statement as an indication that I don't know what weight physically is about, it is simply irrelevant). But you should NOT come up with a representation as you did - in HL7-speak, I believe - that CONFUSES the different elements.

Compare with this analogy: if you take a picture of some scene (say of your best friend and his wife), and parts of the scene are irrelevant (say his wife), you can cut out these parts of the picture. The remaining parts (the picture of your friend) still depict faithfully the corresponding parts of the scene. One should not, in contrast, use some analogous technique of removing irrelevant parts if this means that the relevant parts will get distorted as well.

Your analysis of my use case was clearly wrong: I pointed out precisely where you went off track. The $60M question is now: WHY ? I can come up with several possibilities, but prefer, as Anthony asked and we agreed to, to keep the discussion germane to the issue. Thus I argue here (as before and as a few others have done earlier) that the semiotic and speech act theories and architecture of the "HL7-language" are such that they mislead even experts like you: HL7, in many cases, lets you build representations which are such that removing irrelevant detail leads to distortion of what is relevant.

DR: Certainly, I have learned more about how your mind works in this exchange.

WC: Sure ?

DR: That is important because as I communicate back to you what I heard from you, I make misinterpretations unless your language is VERY clear.

WC: Wasn't it ? I think the problem is that from the very beginning you lumped different things together. As you know, getting things-lumped-together apart is harder than lumping things together. Third time: propose me a more formal language then.

DR: Of course, our communication patterns don't change what happens in the delivery room, and we have to decide why we are bothering to communicate if it doesn't change what happens in the delivery room!

WC: I don't get your point.

DR: Perhaps you can try again to make clearer language, and we can see if you succeed in getting a more accurate return communication. I've given you some hints of how my mind works such that you can craft a more understandable version for my brain.

WC: It seems, as I indicated above, that you cannot make, or do not wish to make, links from what is IN language, to what it is in reality which the language is ABOUT. I guess that is the brain-washing effect of HL7.

HL7 Watch Watch

In the first two years of its existence this weblog has drawn a significant response from the wider HL7-interested community. Positive appreciations are to be found inter alia in the following weblogs:

HL7 Connection
"Should Governments Rely on HL7?"

Future of Health IT: Trends and Scenarios
"HL7 Watch: Is HL7v3 Overrated by being rated at all?"

Australian Health Information Technology
"Is SNOMED CT a Practical Usable Clinical Terminology Today?"
Here Alan Rector is also quoted, with his wise words to the effect that:

Unless we can formalise the mutual constraints ... HL7 v3 + SNOMED = Chaos.
The documentation is beyond human capacity ... to write or to understand.

Update March 2008:

Gratifying post also at Trusted.MD:

The argument that HL7 RIM is incoherent is compelling. I'll admit that I've found HL7 RIM to be impossibl[y] confusing for years. The problem is that as a foundation for all-things-HL7, RIM causes a lot of trouble.

Update February 2009:

See also Health Informatics Blog

Update October 2009:

Interesting post from Bruce Lemma:

If you want to get something done - just stick with version 2.x. Version 3.0 was meant to remove the ambiguity that exists in version 2.x by following a more rigorous theoretical modeling framework. In practice though it doesn't. v3 is more ambiguous than v2 ever was. v3 is very complicated. A lot of effort is required just to understand the basic concepts of version 3.0.

The only people game enough to really try and work with HL7 version 3.0 are governments and universities - organizations which can afford to dissipate a lot of resources without tangible results. It's very hard to find a real v3 success story. Have a look into what the NHS (UK) and Infoway (Canada) are doing.

Both organizations have a lot in common - billion dollar budgets, strong advocates of v3 and almost nothing tangible to show for it. It will take a few more billions before people will start to admit that v3 has serious problems.

It's a bit like the children's fairy tale - "The Emperor's New Clothes". Because so many people close to the standard have invested so much into it no one wants to admit it's not working as a standard. You'll find that people from HL7 get extremely defensive if you even hint at the idea that v3 has problems. You've gotten a taste of it already on this list.

Most vendors are extremely careful to avoid being openly negative about the standard because they are afraid of being seen as anti HL7. No one wants to risk annoying organizations like the NHS and Infoway or members of the HL7 organization that have influence over buying decisions at hospitals.

Infoway practically bank rolls the HL7 organization these days. They almost managed to stop v2 education from happening at the next HL7 meeting in Canada.

So it's a pretty pickle that the HL7 organization has gotten itself into - it is almost
impossible politically for it back down at this stage.

To get a more objective view of v3 you need to look at the opinions of people that do not have so much invested in it. One amusing website I can suggest is

http://hl7-watch.blogspot.com/

Good luck with your integration - and don't feel embarrassed about the problems you have with version 3.0 - you're just the little boy that's pointing out that the emperor is not wearing any clothes.

Source: HL7 Anwendergruppe Österreich.

The OBO Foundry: Coordinated Evolution of Ontologies to Support Biomedical Data Integration

The Open Biomedical Ontologies (OBO) Foundry is an attempt to develop a suite of reference ontologies to support data integration across the entire domain of biomedical research. Thus it shares some of the goals of HL7, including the desire to bring about prospective standardization in support of interoperability and cumulativity of biomedical data. In contrast to HL7, however, the Foundry takes a modular approach that is rooted in the division of expertise of biological scientists.

The OBO Foundry welcomes criticism, and a description of the initiative, published in Nature Biotechnology, is now available here. Alternative link here.

The Dialects of RIM

The latest Minutes of Evidence of the House of Commons Select Committee on Health, on the UK National Programme for IT, contain this comment from Richard Granger:

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.

Dr Granger goes on:

We have had to put an awful lot of effort into specifying the standards for messages, around demographics, around booking, around prescriptions, and then the software that BT have built with a number of sub-contractors is brand new software that has been custom-built for the NHS; so that is high-risk, new build software. There was no other way of doing it. I am very pleased a number of other jurisdictions are getting very interested in using that.

He thereby inadvertently touches on another issue currently causing concern in HL7 circles. The HL7 Reference Information Model or 'RIM' was, we will remember, introduced as the solution to the problems created by the appearance of multiple dialects in earlier versions of the HL7 standard. HL7 would prevent the appearance of dialect versions by enforcing conformity to the RIM. Now, however, it is becoming increasingly clear that the RIM itself exists in multiple dialects.

This is more than just a problem of successive, incremental improvements. As the RIM Document Editorial Assessment from 8 June 2007 points out:

... the 2006 Normative Edition contains a RIM document based on the last balloted RIM [from 2003]: this gap creates the opportunity for conceptual conflict between the document and current practice. A reader must choose between a normative edition of the RIM published for ANSI, which contains nothing extraneous but is out of date; an extract of the current RIM as maintained by MnM, which will be the most up-to-date, but which is not readily available to the membership at large; or, which is most probable, the RIM document published in the Normative Edition, which both contains extraneous information and is out of date.

It seems, in fact, that we have at least:

1. the version of the RIM adopted by ISO as an international standard

2. the balloted RIM document that describes those parts of the RIM designated as 'normative', the latest (and still current) version of which, it seems, dates back to June 2003

3. an ANSI publication based on 2.

4. a CEN Standard EN 14822-1:2005 Health informatics - General purpose information components - Part 1: Overview (see also CEN Standard EN 14720-1:2005), based on 3.

5. the 'living' RIM UML model (regularly updated through harmonization) as it exists at any given stage. This RIM contains content that existed at the time of balloting in 2003 but was not then balloted, together with four years worth of cumulated changes. Some of this material is, I am told, intended to be balloted in the future; some (e.g. in CoreInfrastructure subject area) is not.

6. an idealized 'frozen' version consisting of those parts of 5. which have, at any given stage, passed through the process of harmonization,

7. the UK rebuild.

As I understand matters (and as always this understanding may be for various reasons imperfect) the RIM documentation included in any publication of the V3 standard more recent than 2003 should be based on the latest working version of the model as maintained by the Modeling and Methodology (MnM) committee. The publication label “Normative Edition” may cause confusion, however, if it is taken by the reader as suggesting that the contents so labeled are all normative (though this issue should be addressed in the relevant document preface).

Normativity, Completeness and Flexibility

As we have argued at some length, there is a fundamental incompatibility between the claims made on behalf of HL7 as "the data standard for biomedical informatics" and the need for openness to new discoveries that lies at the heart of the scientific method. To repeat: HL7 V2 is an in some ways impressively successful tool for supporting messaging between healthcare institutions, but with one central flaw: it did not prevent the proliferation of local dialects. HL7 V3 was born to overcome this flaw, effectively by removing the possibility of optionality in the formulation of messages, by imposing a 'normative' set of coding options from which all messages must be derived through combination. And it does not work:

Mead,
Yes - it is possible and most of the information is available, it is just not as easy for implementers to find and use as it would be if things were optimal. From what is in the repository, it sure looks like someone intended to put in a definitive list, but it never got completed.

There are some problems, though, as Rene has pointed out: there exists no definitive list of all Trigger Events or Interactions. We could generate one for those that are explicitly defined in the normative ballot, but then it would produce a different kind of problem for implementers: the supplied table (value set) would be incomplete, even though it would be presented as complete. I am trying to start a conversation about whether we need something to indicate that a value set for the normative ballot material is known to be incomplete and is not intended to be used 'as is', but is intended to be extended. Other than creating a new value set and redefining the binding for a realm, we don't have other machinery to do this with (to my knowledge). This tells me that either we need to describe and document this for implementers, or we need to explicitly assert the value sets as 'examples' or
a 'starter set'. Which means that they would NOT be bound in the universal realm, and would not be used in strict conformance.

There are a lot of loose gears floating around in the machinery from my viewpoint. I don't know how an implementer can find all the reference material and necessary vocabulary to actually sit down and build an implementation prescriptively based on what we have currently. There is a lot of stuff that is referenced in the normative sections that is not normative or not complete, yet not erroneous. This is very confusing to me, and I don't really know what the right answer is.

-Ted

See http://lists.hl7.org/read/messages?id=113501.

A piece of good news

The HL7 leadership has not merely recognized the problems of (un)intelligibility of the V3 documentation adverted to on this blog and elsewhere; they have also set in train a strategy to rectify these problems. We send our good wishes to all of these involved in realizing this strategy:

cc August 31, 2007
To: HL7 Co-chairs
FR: Chuck Meyer, Chair, HL7 Board of Directors
RE: Version 3 Editing project

Dear Co-chairs:

The HL7 Board of Directors has identified the need to review the existing V3 portfolio of standards for clarity, consistency, and ease of use. To that end, it has approved a renewal of contract to review existing documentation, identify issues, and propose tactics for making the V3 standard and supporting materials easier to understand and use. It is important to note that the members of the editing team are just that: editors. They will not be authoring materials. They will work with committees to enhance and organize existing materials and make suggestions for new content. Each committee continues to be responsible for its own content. The current effort is beginning at the Atlanta WGM after taking a hiatus since the Spring WGM.

In addition, an advisory group is being formed to act as a liaison between the V3 editors and the membership. Details about that group, meetings and other means of communication will be made shortly. We are seeking volunteers to participate in this group. Please contact HL7 HQ if you are interested in aiding in this critical endeavor. This should require about 2 hour per month of your time

The work is being performed by Ockham Information Services, and the primary contacts are Sarah Ryan and Jay Lyle, under the HL7 direction of Charlie Mead. The team expects that you, as technical committee members, have some issues you would like to ensure are addressed, or that you are already addressing. They will be contacting you to coordinate their activities and to ensure they do not spend time on deprecated assets, perform redundant work, or proceed with assumptions you believe are incorrect.

The timeframe for the entire V3 review is still under development, so don't be surprised if it takes a while for your specific committee to be contacted. The Board has recommended that the focus for review in fall '07 be vocabulary, datatypes and the RIM. The editorial team will endeavor to make their inquiries as specific as possible: we invite you to share your observations and issues with them. If it seems that their process is less efficient than it might be, do not hesitate to provide them any ideas you may have for improving it. Thank you for your help.

Sarah Ryan: ryansaraha1@earthlink.net
Jay Lyle: jay@lyle.net

At the same time we cannot resist the temptation to express our scepticism. How, for example, will the editorial team make intelligible such gems as the recent proposal "to treat telephone as an Observation, with value having datatype Telecom". And how will they make intelligible the long list of org.hl7.rim.decorators, as defined for example in passages such as the following Class AcknowledgementDecorator:

Implementation of org.hl7.rim.Acknowledgement as an abstract decorator, i.e., a class that returns NULL/NA or nothing for all property accessprs [sic] amd [sic] that raises UnsupportedOperationExceptions for all mutators. This is used to adapt custom application classes to the RIM class interfaces and only bother about mapping those properties that actually apply to the application class. This can be done in one of two ways: (1) the client class can extend the decorator directly, and implement the applicable properties, or (2) the abstract decorator can be extend [sic] to a concrete decorator, which would hold a reference to the client object and method bodies to delegate and adapt the applicable properties. (See already here May 17, 2007.)

Dutch HL7 Concerns

In his HL7 Connection blog the Dutch healthcare management consultant Matthew Clapp seeks to provide an open forum for collaboration between and dialog between advanced and beginner professionals in the HL7 field. In his posting "Should Governments Rely on HL7?" of August 3, 2007 he points to what he sees as the the HL7 organization's failure to foster a more open, collaborative structure:

I’ve even received emails telling me that this site is a waste of time - that no one will bother reading it because I’m not on some HL7 committee. A community that insulates itself from criticism cannot be successful.

The Course of Life blog by the Dutch scientist and entrepreneur Albert de Roos contains two recent postings in a similar vein. The first, Some practical experiences with HL7 version 3, concludes that HL7v3 seems 'too complex to work with in a multidisciplinary environment":

The complexity of HL7v3 is a general problem and also causes delays in implementation at the technical level. I hoped it has been solved now, but in 2006 not all XML schemes that were distributed could be read by the most common XML parsers available, indicating some of the problems with the complexity of HL7v3 messages. ... These apparently trivial issues may cause many delays and frustration for software developers, I can tell you.

The release frequency is also a problem, introducing problems with the different versions. This can be illustrated by the many different versions of the DMIM and RMIMs that are available on the web. I don’t think any of these have been implemented in the field, so while trying to get the thing to work, the international organization rolls out new normative editions. The Dutch implementation of HL7v3 does not follow the international release schemes, but has been frozen in an earlier version. Trying to keep up with the updates is a full-time job. Combine this with the two releases of the complete Dutch documentation each year, which may include changes in the HL7 messages, and the chaos is complete. Of course, we are only in the proof-of-concept phase, so we can expect changes but is there a any guarantee that HL7 enters a relatively stable phase? What will happen to HL7v3 messages when HL7 international moves on to the clinical document architecture, is there a migration path?

In HL7 as standardization organization de Roos points to certain problematic consequences of the fact that the Dutch government "seems to have completely outsourced the entire process of healthcare standardization to HL7:

The different members of the technical committees of HL7 version 3 modeling are employees of software suppliers, consultant or work in a hospital or other health institution. Given the complexity of the modeling in HL7v3 and the limited number of people or organizations involved, it is doubtful whether the models represent indeed a consensus standard way of working. For instance, the involvement of commercial software suppliers may cause the models to closely represent their own software giving them a competitive edge.

To me, it is clear that HL7 is a lobby organization for its own products and that they try to sell their product wherever possible. There is nothing wrong with a lobby organization and its members can spend their money how they want. The problem here is that HL7v3 is sold as a finished product and as a de facto standard, but in fact is not a complete and finished product and never successfully implemented outside of a laboratory setting. It changes continually, indicated by the fact that the organization now moves towards a new product, clinical document architecture, to largely replace the HL7v3 framework. This shift of HL7 has consequences for the national EHRs that are based on HLv3, showing that national governments are not in control of the apparently evolving requirements for the EHR and its implementation. It is strange that the government puts its ambitions in the hands of an organization that they can’t control and where its members clearly have commercial interests or other ambition that are not in line with public or governmental ambitions.