A few weeks ago, I was working on an HL7 v3 project with an outside partner and the discussion turned to market adoption. We came to the conclusion that it’s not exactly taking off — at least, not as quickly as you might expect. Apart from meaningful-use initiatives around CDA in the US and the big push by Canada Health Infoway, I don’t really see much traction in North America. I’m going to come right out and say this: from a vendor perspective, the incentives to embrace the new standard are just not there in 2011.
My thoughts were kicked off by a post from HL7 guru René Spronk. René wrote that the focus to date has been on modeling and that implementation-related material is missing. René also listed 5 improvements that would help implementers adopt HL7 v3. He raises some great points. Even if the post is almost a year old, the list still holds… In a large volunteer organization like HL7, there are no quick changes.
So what exactly is limiting HL7 v3 adoption? To build on René’s list, here are a few more points to consider.
1. Cultural Hurdle: HL7 V.3 Implementation Needs a Change in Mindset
HL7 v3 is a completely different standard than HL7 v2.x. Because HL7 v3 isn’t backward-compatible, when you migrate, you need to change the way you look at interfaces. In the HL7 v2.x world, many analysts treat HL7 messages as strings of data elements. They see their key task as follows: look for the data, find it in the “right string”, and map the string to the right data element in the new system under deployment. What about the semantic gaps, you may ask? The answer in this world: we’ll worry about them during system validation and patch in a workaround. What’s more, in this world, message schemas are manually specified in Microsoft Word documents much of the time.
So from a provider perspective, HL7 v3 is going to demand a change in mindset. The message schema is programmatically specified and modified (if needed). If you’re a big Word fan, you’ll probably have a hard time finding your schema in a familiar format. Most likely, you’ll be encountering a new set of tools for data element mapping. This is a big shift from business-as-usual in the HL7 v2.x world.
2. Steep HL7 V3 Learning Curve
Interface analysts in the HL7 v2.x world are a mixed bunch. Some come from the clinical side of the business, others from the development side. A surprising number are non-technical (which is terrific — we need a range of skill sets in our industry). This works fine for now, since the HL7 v2.x format is quite straightforward. At a minimum, as long as you’re able to count pipes and basically grasp the data being exchanged, you’re good to go. You can start quickly with minimal training. With some help from basic open-source or home-grown tools, you don’t really need deep technical knowledge.
But migrate to HL7 v3 and the game changes. Again, you need a new mindset. The technical skills are different and the way you build or configure interfaces is different as well. Just take a look at this HL7 v3 primer. It’s perfect if you want to understand where the standard comes from. But it’s far too complex if all you need is to learn how to configure an interface. So there’s a learning curve, and it’s not just for analysts. Implementers need to create new material to support analyst learning. And that won’t happen overnight, especially if the market is slow to materialize.
3. No Clear Benefits for Most Healthcare Systems
Healthcare systems have been using v2.x interfaces for decades. Sure, the standard and related processes are issue-laden, and the typical interface deployment process is bumpy at best. HL7 v2.x is far from perfect. It’s probably more expensive and intense to run an HL7 v2.x environment than a future-state HL7 v3.
But most organizations have learned to live with these faults. For most organizations, HL7 v2.x works. It feels safe. It’s become standard business practice.
So HL7 v3 comes along. It’s unknown. And the unknown feels risky, right? Very few healthcare systems are going to jump in with both feet as long as the ROI remains elusive. From what I’m seeing in the field, organizations are not rushing to spend money to fix what amounts to a non-broken process.
The Caveat: CDA and Document Exchange
Despite what I said about the unknown, there is a pretty encouraging caveat to all this. And that is the push for CDA templates and the need for document/data exchange. This is new, and driven by meaningful use in the US, so organizations have to act. HL7 v3 seems to be answer here, and I predict greater adoption related to data exchange.
4. HL7 V2.x Compatible Interfaces Still Needed
Obviously, supporting HL7 v3 doesn’t mean you’re going to be done with HL7 v2.x. HL7 v2.x interfaces are going to stick around, well into any foreseeable HL7 v3 future. Some will start by integrating v3 components, but vendor and hospital infrastructures will remain HL7 v2.x centric over the course of migration. Even if the upgrade benefits were clear, the process could take over 20 years. Meanwhile, related HIS technology will keep rolling along and evolving, and vendors would get stuck with even more to support.
5. Missing Tools
As we speak, the HL7 v3 toolset is thin on the ground, compared to the rich pickings in the v2.x world. We need a more robust toolset in order to get to the productivity levels and skill sets that HIT vendors and healthcare providers expect. Tools will emerge as adoption grows. But for now, the missing toolset is yet another risk for early adopters to manage.
What’s Next for HL7 V3?
Now that I’ve said my peace, don’t get me wrong.
HL7 v3 is an elegant step forward in healthcare system interoperability. But the design quality of the standard isn’t a compelling migration driver. We’ve been using HL7 v2.x for so long that we’re used to its weaknesses. For us to shift, we’re going to need stronger, clearer market drivers. Change — even good change — is risky within organizations. We shouldn’t underestimate our own reactions to risk.
Comments
Readers, what are your thoughts? Does HL7 v3 adoption touch a nerve? Let’s hear it in the comments.