The Multiple Joys of HL7 V3

An intelligent post from Keith Boone on his Healthcare Standards blog on the need for greater architectural oversight in the HL7 v3 community, to protect against burgeoning modeling inconsistencies:

One of the joys of HL7 Version 3 are the many different ways that you can say the same thing depending upon the context of your message. Let's look at a laboratory test result for example. Using the HL7 RIM, this will be encoded as an observation. Using the 2008 Normative Edition there are at least 7 ways within the published standards to say the same thing. These seven different ways appear in the following HL7 Version 3 standards:

• Care Record

• Clinical Genomics Pedigree


• Clinical Document Architecture


• Clinical Statement


• Common Message Element Types


• Public Health Reporting: Individual Case Safety Report


• Periodic Reporting of Clinical Trials


• Laboratory Results

The picture [here] shows how these HL7 standards support this concept slightly differently in each case.

I've shown how the names of the XML Element, and the constraints on the content of the Observation class vary using a bold red font, or where the RIM attribute is missing, a red background

As Boone points out, "Arguably, there's a reason for this [multiplicity], but I challenge anyone to determine why."

Update August 12, 2009

Some interesting responses to Boone on the HL7 Listserv, illustrating (inter alia) the problems which arise when 'observation' is made to do duty for so many different things.

From: Amnon Shabo [mailto:SHABO@il.ibm.com]

Sent: Wednesday, August 12, 2009 3:38 AM

To: Lloyd McKenzieCc: austin.j.kreisler@saic.com; charlie.mead@booz.com; Boone, Keith W (GE Healthcare); owner-strucdoc@lists.hl7.org; strucdoc@lists.hl7.org

Subject: Re: Use of Domain Models

Hi Keith,

Regarding documenting requirements - I fully agree that it's the most important task in the standards development process and we should do a better job here.You start with saying "Let's look at a laboratory test result for example"and then bring a list of specs that presumably have the capacity of representing lab test results. However, none of those specs is the Lab spec which should be the natural & first choice for that purpose. You then continue to show that there are differences in the way the RIM Observation class was refined in each of the specs on your list. But isn't it looking at the empty half of the glass? After all - we can think of it in this way: here are specs that serve a broad spectrum of use cases (from clinical trials through healthcare to public health) and they all use the same class! And if you add to it the availability of a dedicated lab spec then the example you bring up is nicely covered I believe.

Regarding domain models, I don't think that 'all-in-one' new CDA is the way to bring about consistency across various domain models nor does a very generic Clinical Statement (CS) model which in fact becomes another 'RIM'in the attempt to accommodate so many requirements from all domains. Instead, a CS spec that is modeled to serve a single statement as part of some larger composition (in analogy to natural language) is perhaps a way to achieve consistency across domains at the statement level.

By the way, in the Pedigree spec, the clinical observation we put there was meant to be replaced by the CS CMET which wasn't available yet at the time we finalized this spec.

Thanks,

Amnon.

Sent by: Lloyd McKenzie

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

07/08/2009 04:37

Subject: Re: Use of Domain Models

Hi Keith,

I don't think this has anything to do with issues embedding domain models in CDA R3. You can express the same content in a CDA model 50 different ways if you like. Clinical statement is nearly (though unfortunately notquite) as expressive as the RIM. There's no question that increased consistency on representing equivalent data would be useful. However, there are also circumstances where the same piece of information needs to be represented at different levels of granularity. When referencing a diagnosis as the indication for prescribing a drug you don't need the same level of detail as you do when you're capturing the diagnosis as the focus of a trackable problem. The benefit of leveraging domain models in CDA R3 is that at least there is *some* guidance on how to model the content and consistency with a given domain. 7 models is better than 50+. And for a given document, it should be possible to narrow down which domain model more appropriately covers the document content which means you'll be working with less than 7 choices.

Lloyd

From: "Boone, Keith W (GE Healthcare)" <keith.boone@ge.com>Date: 12 augustus 2009 16:24:55 GMT+02:00

To: "Amnon Shabo" <SHABO@il.ibm.com>, "Lloyd McKenzie" <lloyd@lmckenzie.com>Cc: <austin.j.kreisler@saic.com>, <charlie.mead@booz.com>, <strucdoc@lists.hl7.org>

Subject: RE: Use of Domain Models

Amnon,

On your first point, that I should have used the lab spec, I would point out that my analysis was only covering published standards and DSTUs from the 2008 Normative edition. Lab isn't in there, so I didn't use it. Yes, it would have been the obvious choice. The fact that after 10 years we still don't have a balloted standard for laboratory reporting is another topic for another time.

On your second point, I would have to agree with what you've said below if they used the same class consistently. However they do not, and some of the differences are critical for interoperability.

For example, two of the published standards disagree on what the vocabulary domain should be for observation.code. Most seem to agree that it should be ObservationType, but Clinical Genomics doesn't restrict it and Clinical Trials Lab uses the broader ActCode. So what happens when I try to tranfer data from a Clinical Genomics message that uses something not in the Observation Type domain to another message that has the restricted domain? Lack of interoperability. Yes, I can certainly impose those limitations on a system that uses two or more of the standards, but WHY should I have to?

Finally, the point of this post was not to pat HL7 on the back. I still honestly believe that it's doing a decent job fulfilling its mission of providing the best standards for healthcare. However, there are still challenges that it needs to address, and I'd like to be able to exchange the word "decent" for "good" and eventually "great". The whole point of the post was to identify some of the current deficiences, and offer a possible solution or two.

Keith

Would Tightening the Definitions in HL7 Make Things Worse?

In a recent post I pointed to errors created by the flexibility of HL7, for example because it allows the NK code for 'next of kin' to be used in a message also, for example, when referring to a nurse. Graham Grieve has entered a Comment to this post, defending a view of the NK code as 'a field that users can put what they need into'.

As he points out:

The question is, for any particular use, is that use consistent with the definition of the field? I don't think it is in the hoot example. But consulting the standard, the definition is loose - like the definition of next of kin in the real world. Of course, in a competition to find the worst case of egragarious mis-use of a standard, HL7 regulars would line up to bring forward their favorite cases. But HL7 is not alone here. HTTP is the same too. As for web services ... . What this does betray is a flaw in the whole picture: the standards body defines a logical structure, but business use cases require things to be done, and how are they going to be done? So some partially educated analyst makes a (variably) bad decision under considerable pressure, usually with some input from actual implementers. The outcomes are unpredictable. Actually tightening the definitions (like in a proper ontology) can make things worse, and so can loosening them. Though either can make things better for at least some users in some circumstances. It's just something we have to live with.

I fear that Graham's relaxed attitude to the dilemmas of bad coding ignores an overwhelming problem in the current (v3) architecture of HL7, a problem which does much to explain the peculiar features of some of the discussions on HL7's email lists, and which explains also why HL7 needs to devote so much effort to the consideration of questions like 'Is Diet a subclass of SupplyAct?' or 'Is a car accident an intentional action?'

The problem is that the RIM rests on a counter-intuitive upper level ontology, one in which anything that is not an Entity has to be classified as an Act. This counter-intuitive ontology -- in which a disease, for want of any more appropriate category, is identified with an act of observation of a disease -- not only makes it hard for HL7 analysts to avoid making bad decisions; it is also likely to be responsible for medical (coding) errors downstream, and it also places obstacles in the way of simple remedies for such errors.

Consider, for example, the case described in part 4 of the interesting series "Are Health IT Designers, Testers and Purchasers Trying to Kill People?" by Scot M. Silverstein. The chart below represents a problem list presentation page generated in an Electronic Medical Record system via auto-population based on what its makers refer to as an 'artificial intelligence' function.


As Silverstein points out, a number of issues are illustrated here. For present purposes we focus only on those pertaining to the diagnosis 'atrial fibrillation.' This is, as Silverstein notes, an important piece of information for the clinician to know.

Except, however, when the patient does not have atrial fibrillation. This entry was auto-populated when a nurse ordered a blood clotting test and erroneously entered the reason for the test as "atrial fibrillation" (a common reason, just not the case here) to expedite the order's completion. Voila! Now Mrs. Jones carries this diagnosis, and the next clinician to come along might order her anticoagulated with heparin or coumadin for a history of A. fib, introducing yet more chance of an iatrogenic injury.

And I am told it takes going back to the vendor to have this erroneous entry permanently removed. Sheer idiocy! For instance, if the patient moves to a different unit, is discharged and returns to this hospital, or to an outpatient clinic or another hospital branch with this on the record, the chances of a screwup are not insignificant

HL7 was not, for all I know, involved in any way in the creation either of this system or of the specific problem list here illustrated. But consider the difficulties created by the RIM for any rectification. Suppose, for instance, one wished to have a facility to allow users of the EMR to generate different sorts of problem lists for different purposes. These might include, for example, problem lists that would include only those entries in which a disease is ascribed to a patient on the basis of some act of observation by a clinician. To achieve this end, we would need to keep records of observations by clinicians clearly separate from records of diseases on the side of the patient, along the lines illustrated for example here. We have attempted to identify a way in which the RIM could allow a programme do this coherently. But thus far we have not been successful.

hoot72: An Ontology for HL7 v. 2.3

hoot72 is an interesting experiment by CDC to create an OWL ontology to capture in a coherent fashion the major entities recognized in HL7 v. 2.3.

The ontology is associated with a blog, which draws attention to some of the unfortunate consequences which flow from the fact that HL7 is flexible in the familiar ways (thus it allows the NK code for next of kin to be used also, for example, for nurses).

The OWL framework provides a clear perspective on HL7 v. 2.3, and avoids the usual problems (with act, observation, etc.) which plague v.3.

On Problems with HL7 Documentation and with HL7 XML

I respond below to two critical comments from Kevin Coonan which, following the earlier comments from Graham Grieve, point to a welcome new trend for those submitting comments to this blog, in that they are submitted non-anonymously. (Comments to HL7 Watch are moderated, but all signed comments are passed through automatically.)

Comment 1 (to HL7 RIM: still no coherent way to track concerns):

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

BS: I am afraid I do not yet have a theory about how HL7 works, because, like many others, I do not understand the HL7 documentation. This is in part because it is unclear -- a problem which HL7 has already acknowledged and is itself attempting to ameliorate -- but in part, and more seriously, because it is inconsistent. Gunther Schadow, Charlie Mead and Mead Walker defend this state of affairs by arguing that:

As different people edit parts of the specification, inconsistencies in form and quality may emerge; as some ambiguities are clarified, other previous systematic ideas may be corrupted; and well meant glossary entries may cause confusion. Sometimes irreconcilably opposed conceptualizations may coexist and one resorts to vague or ambiguous language in the interest of moving forward in areas where parties can not agree.

Some would argue, however, that this is a state of affairs that raises questions for an organization that is proposing standards for information exchange, especially in a critical domain such as health care, and especially in a context in which large government investments depend on making the right sorts of standards decisions.

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

BS: Such self-critique is of course an entirely positive thing. It would be a flaw in a system only if actual errors or inconsistencies or unclarities or ambiguities identified through such critique would be ignored at the stage where the artifacts in question become normative.

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

BS: Good point. I hereby commit to closing down this blog just as soon as there is evidence that it is succeeding in becoming influential.

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

BS: I devote a lot of time to the OBO Foundry standards efforts (we also organize many interesting tutorials). The developers of all the ontologies within the Foundry recognize the value of criticism from outsiders, since outsiders are able to provide a fresh perspective -- for example by exposing ways in which our documentation falls short. Science, I believe, makes progress only to the degree that it maintains a healthy culture of criticism from outsiders.

Comment 2 (to Big HIT) (responding to the identification of major problems with HL7 XML):
KC: HL7 XML is standard. It follows published W3C standards, which as far as most are concerned are the standards about XML which matter.
BS: Correct. But not all standards are equally good, I'm afraid. See, as concerns HL7 XML, the arguments here (summarized already here).
KC: HL7 itself is a ANSI SDO, and anything that HL7 publishes as normative BY DEFINITION is a standard.
BS: An ANSI standard, yes; all the more reason, therefore, to ensure that everything is checked very carefully before publication as normative, for example to ensure consistency.
KC: Finally, HL7 contributes, collaborates and uses the same ISO standard (21090) for data types, which is by-and-large the XML which makes up "HL7 XML."
BS: Unfortunately most HL7v2 and HL7v3 message standards do not follow this ISO standard. Moreover 21090 is not a full ISO standard. It is in the DIS-stage and therefore under development: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 [See update below]
KC: Please, when you make statements such as that, you should constrain yourself to the facts, and not make such invalid and irresponsible statements.
BS: I hope, with respect, that we are both doing our best to confine ourselves to the facts.

Update August 2011: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 now published as an ISO standard.