In part 1 of this series, I gave a high-level overview of what HL7 is and does and alluded to the vagueness that comes with many of the HL7 standards. This is not a shortcoming of the standard, but often a deliberate design choice. To fill in the cracks, numerous other organizations step in and create rules on top of the existing standards to make interoperability more seamless.
Why are Standards Vague?
It’s important to think of the HL7 standards as building blocks, not a panacea. There are numerous things that base-standards don’t, and probably shouldn’t, touch on:
- Lack of consistent coding systems: what identifiers do you use to identify certain pieces of data? HL7 provides a way to express the codes, but some kind of negotiation needs to happen so that systems can speak the same language.
- Optionality and cardinality of data: what is required and how many should there be? HL7 does provide some guidelines for these, but they can’t possibly accommodate every workflow that will ever exist, additional rules are inevitable.
- Exchange and connections: many real world entities need to be involved in hooking systems up. Best practices take on different flavors across regions and businesses as technology evolves.
- Regional differences: HL7 doesn’t design a standard for every country, but rather provides a framework to be adapted for local use.
Who’s Doing Things About It?
Integrating the Healthcare Enterprise (IHE) is what most people will think of first when you use the word profile. IHE works with experts in a number of areas to develop specifications about how various actors in a workflow should work together. Check out the wiki to see what areas they work in, and what a profile looks like. Also check out Connectathon, the best named event in all of healthcare.
Here are some IHE profiles you should know about:
- XDS/XCA/XDR/XDM: all designed to share CDA documents. They are at the core of Commonwell, numerous government efforts, Epic, HealtheWay, and are heavily intertwined with Meaningful Use.
- PIX: PIX is central to what Commonwell is trying to do, and may provide a foundation for a future common patient identifier. Check out TC’s post about patient identifiers.
While HL7 is mostly in the business of making base standards, they also publish what they call implementation guides. These guides set down strict rules for how data should be formatted, etc.
Here are some important implementation guides to know about:
- C-CDA: an attempt at harmonizing many different and often divergent attempts to profile CDA. This great blog post from 2011 compares life before C-CDA to Talmudic disputation.
- The MU Specs. Numerous public health menu objectives are in Meaningful use, and HL7 has their name on most of them. Electronic Lab Results Reporting, QRDA (Quality Reporting Document Architecture), and Cancer Reporting are a few examples.
It is not simply enough to “know” HL7 to have an interoperable product. The good news is that there are people working hard to make interoperability a real and tangible thing. The bad news is that we still need to comprehend 600-page specs and deal with technology the rest of the world left behind a decade ago (or never adopted in the first place).
Here in the US, there are numerous other bodies that I did not mention in this post. As the government continues to throw money at interoperability, you can bet that new committees, commissions, and panels will arise to create new profiles! Enjoy some XKCD while you wait.
Instead of bemoaning the lack of interoperability in healthcare, we believe in working to improve it. Check out our thoughts on Why the World Needs a New Kind of Interface Engine.