A forum to discuss ideas, approaches, standards, and architecture to establish and support open interoperability among healthcare IT systems.

Friday, June 16, 2006

Why Measure Interoperability?

There is global interest right now in health systems interoperability. Be it the RHIOs connecting community healthcare organizations in the states, or the National e-Health Transition Authority(NeHTA) connecting states in Australia, there is tremendous focus, activity, and spending right now on making health systems work together.

What is needed is an "Interoperability Maturity Model" -- an independent framework against which interoperability solutions can be objectively measured. So, given the seemingly insurmountable challenges in making health systems interoperate would we spend effort in measuring interoperability? Let's explore this topic a bit and the rationale will become clearer.

In the present environment, every vendor and integrator on the planet is peddling solutions that will interoperate. Standards are plentiful. Collaboration is king. Every healthcare IT decision-maker being driven to interoperate by business drivers, internal or external pressures, or their own objectives must find a way to differentiate the marketplace and various marketplace offerings. Similarly, Governments are selecting standards and protocols to address interoperability challenges in various contexts. Which is the best standard to promote demogramics data sharing? How will patient health summary information be communicated? And so on...

As significant decisions affecting health information sharing are being made, there is a very wide spectrum of alternatives available, each with implications. Some solutions are elegant but not yet available to deploy today. Others are stopgap measures that may inhibit the progress of tomorrow. And some are placeholders for more rich solutions that are emerging. The challenge to the CIOs and architects is to select the right solution for thier context.

Enter the Interoperability Maturity Model. An objective metric against which solutions could be measured would provide the basis for informed decision-making. It would allow CIOs and architects to choose solutions based upon their strengths and not market hype. It would allow for more strategic planning and informed investment. Finally, it would also allow those working on interoperability solutions (such as standards) to identify and address shortcomings, improving the overall work.

Maturity Models are not new, and instituting them is not without pain. One need only look at the Carnegie-Mellon CMMI as an example. That said, providers and consumers alike have reaped benefits from understanding CMMI assessment ratings, even if they do not choose to become CMMI certified themselves.

If industry analysts would take on the challenge of creating an objective maturity model for interoperability, I think they would find a huge audience interested. After all, if you're the one entrusted to make these difficult decisions, wouldn't you want a confidence that you're choosing wisely?


Blogger Alan Honey said...

Ken, I agree with most of this. In terms of the reasons for doing SOA, I believe that the biggest for us is the promise of the much heralded business agility. This arises from the interface centric or design-by-contract nature of SOA, as well as the separation of process from service logic, but at last we do have some technology that enables this to happen in a fairly interoperable manner.

20 June, 2006 12:12

Blogger Alan Honey said...

Of course my previous comment was aimed at your "SOA for the right reasons" posting, not the maturity model one, all this new fangled technology!

20 June, 2006 12:14

Blogger Richard Veryard said...

Ken, you talk about the CMMI, but have you looked at the stuff that the SEI is doing specifically on acquisition and on interoperability?

07 September, 2006 11:50


Post a Comment

<< Home