Looking at Health IT: When integration isn’t enough

I really liked the article by the Fred Bazzoli, editor in chief at Health Data Management., The article, titled "Why EHR implementation is only half the battle", explains succinctly that good adoption of electronic health records, at first pass a positive sign, is not really yielding the expected business (i.e. patient) benefits., I'd like to summarise the key points of the article more clearly:

"The Office of the National Coordinator for Health IT reported soaring percentages in tracking the adoption of EHRs by U.S. non-federal acute care hospitals. Announced in conjunction with its annual meeting in Washington, D.C., the survey reported that adoption of basic EHRs increased to nearly 84 percent of hospitals. As recently as 2010, only 16 percent of U.S. hospitals had this technology in place."

Despite this high degree of system adoption and integration, the data flowing between these and other systems are inconsistent. Technology has been adopted but business processes and practices, related to information governance and the value and priority of data, have not been adopted. Huge costs have been absorbed without any corresponding increase in yield on that data initiative.  Let's look at these points in detail.

On integration but lack of interoperability: 

"About 4 in 10 hospitals had the capability to integrate data into their EHRs without manual entry," ONC reported. Further, only 18 percent of respondents to the interoperability survey say they often use patient health information received electronically from outside providers when treating patients, and another 35 percent say they sometimes use others' data."

On excess costs over return on investment (yield):

"[T]he federal government has spent more than $30 billion on incentives, and the healthcare industry has spent multiple times that amount to invest in technology. That doesn't take into account the manpower required to install the system, teach others to use them, and the challenges the technology have imposed on medical practices during the learning phase, and beyond.

I have a belief that the issue is not about technology or its adoption, yet that has been the focus of the mandates and the reward systems for hospitals. I believe that there is a difference in understanding for what is needed, not unlike what we see with many clients we speak to every day that sign-off on investments in data programs and initiatives only to find out later that they didn't steepen their yield curve and generate quantified benefits: in some cases these investments flatten the yield curve and so returns-on-investments actually fall.

Will the Really Guilty Victim Please Stand Up?

Interoperability, correctly called out in the article, is a fascinating concept.  We can agree what it is in principle: the idea that two things, designed by different people, can work together easily.  But therein lays the hidden complexity: I think that there are different forms of interoperability and most IT shops don't understand the nuances. We do not even all agree on this difference either.

Most IT shops assume that two APIs, designed by different teams, work perfectly if they can integrate easily.  This is thought to be the meaning of interoperability. Worse, many folks argue that "integration" includes interoperability – yet it does not.  It does not because, in the context of interoperability, the vast majority (say, upwards of 95%) of integration work focuses on technology, not business or semantic integration and the necessary shared information governance needed.  Time and again, over and over, systems like these are implemented and the business benefit and ease of so called integration is never fully realised.  We see it all the time today in our work with clients. The fact is that here are different forms and levels of interoperability and there is a hierarchy here too:

1.     Process interoperability

2.     Data interoperability

3.     Technical (i.e. Integration) interoperability

I had the luck and fortune to be involved in the development of an innovative business application that had to tackle all three, whereas most IT shops only tackle the lowest element. The application I refer to was one that had to support a shared (i.e. collaborative) business process, that required shared (i.e. semantically consistent) data. The form of integration, as in how the data was physically moved and delivered, was almost irrelevant. If you focused on technology integration first, you rarely get semantic integration; if you focus on process design and interoperability first, you cannot proceed without semantic alignment and then the value of the technology investments pays off handsomely.  So few organisations experience this 'ah ha" kind of think. Typically those that build high-performance multienterprise business process or applications get the needed experience. Those that focus on integration, and even multienterprise integration, also do not have to go through the same learning curve.

Be wary: technicians and integration specialists will say, "Of course semantic consistency is important" but in the same breath they will then say, "It takes too much effort to align all that data", which misses the point. You only have to design very limited data set for interoperability to place.

The driver for such a successful development is the key: if the outcome was the need for a shared business process and metric, then Health IT participants would first look at process interoperability, then application design, then minimalist information governance, then integration. As it stands most of what I read in the press about Health IT is upside down. I might be wrong – I am not in the healthcare industry vertical nor do I have any firsthand experience of Health IT standards setting. I have, however, worked for many years on the thorny problem of interoperability and also been involved in other industry standards focused on the same topic.

Health IT policy leaders need to design their mandates around an understanding of the shared outcomes between stakeholders, a shared process, and shared data. Then, with the right metrics in place, IT shops and vendors alike will behave accordingly. Alas, since the idea of interoperability seems to be incomplete, there is little chance that this will take place. Health IT yield curves will remain unchanged and ROI will continue to struggle.