Does XML and/or UML Solve All of Our Healthcare Integration Issues?
December 1st, 2006 by Dave Shaver
Posted in Healthcare Integration, HL7 Integration
I stumbled into a great article in the June 2006 issue of the ACM’s Component Technologies journal. The article is titled “Software Development Amidst the Whiz of Silver Bullets…” and was written by Alex Bell (who works outside of healthcare at Boeing.) The article addresses the question of “new school technologies” (say, XML and UML) and what magical value they really bring to the table when solving real world problems.
I thought Alex’s insights were good, and I thought I would share them and some thoughts of how this debunking applies to healthcare integration.
As a long time healthcare integration professional, I’m often faced with questions generated both internally and by students or customers regarding this weird, odd thing we call HL7. By HL7, I mean the HL7 2.X messaging standard that moves clinical information around a hospital, clinic, imaging center, or lab. HL7 2.X is a “triggered” and real time protocol. That is, systems within the facility want to know where a patient is right now. They want to receive lab results within seconds of them being entered. The pharmacy system needs notification when new prescriptions are written. And so on.
Like Alex, the longer I’m in the software development and healthcare integration game the more it seems the problems we face are the same again and again. Often someone new to integration will say something like, “Why are we using HL7? Can’t we just do a little XML and be done with it? XML would be so much easier!”
Here are some excerpts from Alex’s article:
[T]here are no silver bullets available now or in the foreseeable future with which to solve all difficulties.
…
I was recently reviewing a software design document … included the following commanding statement a number of times: “The configuration data will be stored in XML.” I immediately thought to myself, “Wow, this design must really be good” and was relieved from previous concerns that some form of ancient Egyptian hieroglyph may have instead been the representation of choice.
Funny, yes. But it reminds me of the typical first reaction that new users have to HL7: “Wow, it’s ugly and XML would be so much better.” They miss the point: HL7 2.X is about the data model and workflow of healthcare facilities. In fact, HL7 can be encoded in XML using the HL7 2.XML standard. Or, go for the brass ring and try to speak HL7 V3.0 (or more generically, HL7 3.X). Alex continues…
Still reeling from the powerful implications of what I had read, I began to wonder if placement of any content in the context of XML would somehow lead people to believe it to be of hallowed or divine origin, and having some implicit warranty of accuracy or correctness
…
XML is not the only silver bullet in the software engineering space to which sanctity seems to be automatically attached by simply using a particular technology. The fact that a diagram has been created using the UML leads some to believe that the associated design is guaranteed to be implementable and ready for development, even if the laws of physics were ignored as constraints.
Sure enough, there’s one view that HL7 V3.X falls into the space of ignoring some of those laws of physics.
[S]ome developers feel that their usage impacts the open-endedness and flexibility made possible by method signatures of the ilk:
XMLResult DoAnything (XMLDoc Arguments)
{
……
}
…
As opposed to having to devote significant efforts to the consideration of constraints such as network bandwidth, processor speeds, and the speed of light when developing system architectures, such annoyances are now overcome by creating reams of UML diagrams containing very vague entities and equally vague navigation between them.
Is HL7 perfect? Far from it. However, as I like to say in training class, “HL7 2.X is the best thing we have for now. ‘Everyone’ uses it and it is the de facto way to move clinical data.” The HL7 integration community is always improving the standard and has embraced XML. Let’s just not think that these new technologies are and end in themselves.
Last 5 posts by Dave Shaver
- HL7 Working Group Meeting Includes Strong International Attendance - September 16th, 2008
- Integrating EMRs with Reference Labs - September 3rd, 2008
- Massachusetts Hospitals Must Have CPOE by 2012 and CCHIT-Certified EHRs by 2015 - August 13th, 2008
- HL7 Dates and Times - July 25th, 2008
- HL7 Time Zone Qualification - July 25th, 2008

(2 votes, average: 4.5 out of 5)




I would think the following exists. “In fact, HL7 can be encoded in XML using the HL7 2.XML standard.”
Do you know where? If I had the schema, then I could easily have an HL7 mapper/integrator out of existing relatively inexpensive XML tools like the Altova XML suite instead of spending thousands for an HL7 mapper/integrator.
i m fully agreed with u bt i thk hl7 doin nothing but creating a discipline towards.