Overcoming the Barrier to Participating in the IHE Initiative

March 14th, 2008 by Jason Williams Print Friendly

Since it’s inception in 1998, IHE (Integrating the Healthcare Enterprise) has embarked on a commendable mission to “improve the way computer systems in healthcare share information.” Over the past 10 years the initiative has made great strides in standardizing the implementation of not-so-confining “standards” such as HL7.

In so doing IHE has developed a plethora of integration profiles across a dozen or so clinical and operational domains, from Cardiology and Radiology to Patient Care Devices and IT Infrastructure. These profiles take a lot of the interpretation and guesswork out of the implementation of the underlying standards and thus make the messages transmitted between clinical information systems much more consistent and predictable, at least amongst supporting systems.

Sounds great – so what’s the problem?

In the most recent North America Connectathon only 70 organizations tested just 130 systems for IHE profile compliance. Don’t get me wrong – that’s a really nice turnout that marks continued growth in support for the initiative. But when compared to the thousands and thousands of clinical information systems impacting patient care delivery in this country today, that total represents a disappointingly low percentage.

Why don’t more vendors participate? Quite simply, because doing so is difficult, and there’s been no surge in customer demands for IHE compliance in the marketplace to date to prompt most vendors to tackle that difficulty.

To be clear, the difficulty associated with participation isn’t attributable to any overly complex technical challenges to which vendors are subjected. On the contrary, the profiles, though imposing at first glance due to their length and exhaustive nature, spell implementation details out quite clearly. Nor is the difficulty attributable to the committee meetings, conference calls, and face-to-face meetings required to stay engaged with the ongoing developments of a particular domain, although that investment in time and energy certainly isn’t trivial.

Rather, the difficulty in participating stems from a fundamental flaw in the way vendors have historically addressed interface challenges. That flaw continues to plague their ongoing integration efforts today.

For most vendors, the world class system cart came long before the integration horse. When interfacing requests first began to surface, code was hastily added to the existing application code base in an effort to provide a solution as quickly as possible.

As connectivity demands have grown at an ever-increasing clip, that interfacing code not only grows with them but also undergoes innumerable changes to accommodate the customization required by so many interface partners. And each time a change is introduced the entire code base is recompiled and regression tested to ensure that customization did not have a deleterious effect on the core application.

As a result, growing software companies see deployment cycle times balloon and valuable development resources diverted from core technology to high tech plumbing.

Sounds a lot like initiatives to adopt IHE profiles and participate in Connectathon events, doesn’t it? Profile changed? Code, recompile, test. New profile? Code, recompile, test. Vendor X needs the message you’re communicating tweaked? Code, recompile, test.

The path to IHE compliance need not be so difficult!

Thankfully, healthcare middleware can go a long way toward remedying the difficulty felt by the vast majority of healthcare vendors today. Amongst many other things, middleware technology can:

Eliminate the need to alter existing import/export modules.Middleware can receive the existing feeds an application supports and transform those messages into an IHE compliant data stream.

Move interfacing logic outside the core application. In so doing supporting changes becomes a matter of reconfiguring, typically in a graphical user interface, rather than recoding.

Provide greater interfacing flexibility. Supporting IHE profiles is a great idea, but as mentioned above the number of non-IHE compliant systems far exceeds that of compliant systems.

Support IHE profile variability.Despite best intentions, much of the code written to conform to IHE tests ends up being thrown away, introducing variability outside of Connectathon events.

Free up development resources.Configuration of interfaces utilizing middleware requires analyst level skills, allowing development talent to refocus on the core application.

Don’t believe me? Just ask the vendors who have used healthcare middleware with their products in an IHE Connectathon.