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
The picture [here] shows how these HL7 standards support this concept slightly differently in each case.
- 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
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
No comments:
Post a Comment