I got this question through the “Ask an HL7 Question” page. Thanks Erica

1. It’s the outcome of a committee process

The HL7 standards are the product of a consensus based committee process. Lot’s of people have eyeballed them and argued greatly about every single detail. They’re all volunteers, and they have a passionate commitment to making sure that the standards meets the functional requirements that people identify.That’s got it’s good points – it leads to real quality in those terms. Where it’s not so good is in non-functional requirements, like, “how do you make this thing work”. And it doesn’t lead to a coherent architecture either. The problem with coherent architectures is that they get coherent by rejecting efficient solutions for some things.

So you can have more reliance on the functionality of the standards that you can have ease implementing them.

2. Healthcare is really a mess

I see this all the time – Healthcare really is a mess. Everyone is doing everything differently. HL7 can’t change that – we’re not chartered to. So HL7 standards just have to absorb that mess, to allow everyone to do things their own way. What you see in the standard follows from that reality.

No one likes it, but we all get to live with it. Blaming HL7 is like shooting the messenger (yeah, it’s never stopped me before either).

3. It helps to know someone

If you’re going to work with the HL7 standards, you’re going to have questions. The volunteer (or “voluntold”) insiders are imbued with the culture and know the thinking that underlies the standards, but no one has invested the money it would take to make that knowledge explicit. So when implementing HL7 standards, it helps a lot to have access to the insiders. Most of the insiders are pretty open – you can just ask, though the amount of detail you’ll get is somewhat limited. For instance, when someone emails me and ask for a detailed comparison of openEHR archetypes and HL7 templates, along with implementation notes in Java appropriate to their particular circumstances, and explains that they’re not really sure what a RIM or an archetype thingy is, then instead of spending a week or more writing a comprehensive self explanatory treatise on the matter, I’ll brush them off with references to the various specifications (I get a variation of that question every few weeks).

Simply getting on HL7 email lists and asking questions without context isn’t going to help either – the HL7 email lists are open to all, but exist to run the committees.

If there’s really no one you know, and the economics mean you can’t buy – I guess you can ask here.

Well, that’s my 3 things. That’s a hard question – I’m not really sure that if I thought about another few more days, or in another context, I wouldn’t come up with a different list altogether.