Trusting the Process: What We’ve Learned about Interoperability

Having been involved with the various aspects of interoperability in healthcare for over two decades, I’ve seen a lot of definitions and comparisons. I used to think the work we were doing with interface engines as just integration; you know, getting the registration system talking to the lab system, the ordering systems talking to the lab system, the lab system to talk to the reporting system, etc. I’ve heard some refer to those processes as interoperability and not integration. I’ll let you be the judge.

When we started to implement EHRs in physician practices, they were all from different vendors; no one vendor had an enterprise EHR that did it all, those came much later.

At one point in time, while working in Georgia, the health system had five different EHRs that needed to interoperate/integrate, the interface engines and HL7 were the tools at hand. Were we successful? Not totally; however, we were able to create processes where patients registered in one EHR were known to all the other EHRs and we were able to get orders that were entered in the ambulatory EHRs to connect to the hospital lab, and the lab results to return to the appropriate EHR and connect the result with the order, closing the order.

No, it wasn’t magic — just hard work, with a lot of discussion and compromise. What we were creating was an “enterprise or private” HIE (health information exchange), although we didn’t know it at the time. We wanted to take it further, to connect with the other health system in town and with the DOD hospital that referred to our specialist, but that’s a topic for another post.

Defining interoperability

HIMSS is proposing an updated/revamped definition of interoperability. There are others, like the one contained the 21st Century Cures Act. However, for the sake of not turning this post into a research project or Wiki page, I’ll stick with the new HIMSS definition for this discussion.

In true HIMSS, big-tent fashion, it covers as many bases as possible. Here’s the revamped definition: “Interoperability is the ability of different information systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders, with the goal of optimizing the health of individuals and populations.”

It’s a little long, but it hits all the targets that the healthcare industry has been shooting at. And unlike other definitions, it has the end result in mind of optimizing the health of individuals and populations. Isn’t that the main reason that most of us are in this field in the first place?

Having a new and more encompassing definition isn’t really going to get us any further down the road; but it will help bring the destination into a little clearer focus. What’s important, however, is that the industry adjusts its course.

It’s the process, stupid.

I think we’ve been so focused on just getting EHRs implemented, data in discrete format (well, at least some of it) and the data/information moving, that we’ve forgotten what the real goal was all along (or at least what I thought it was): making the data/information available to the right clinicians, at the right time, so as to have the greatest impact upon the care of the patient. Now that most every hospital and physician practice has an EHR, I could also add putting the information within their normal EHR workflow. So easy to say, so hard to accomplish.

Healthcare is a very complex system; not just one complex system, but a series of complex processes and systems, intertwined and at times almost wrapped around its own axle. I was reminded of this when I reading the recent “Curbside Consult with Dr. Jayne,” a feature of HIStalk. As a side note, I’m not a total fan of everything that you can find on that particular site, but there are times where the nail is hit squarely on the head.

The gist of her post was that even with the most diligent communications, care hand-offs, complete documentation (paper based due to hospital related policy), personal/professional relationships, phone calls and follow up, the care coordination of a patient still failed. As I reread the post, looking for ways that data exchange/interoperability might have helped, I came to realize that no level of automation will fix the human side the equation; it’s the process, stupid.

This was the point that many of us in the industry, while commenting on the Meaningful Use NPRMs (notice of proposed rule-making) was trying to make. Just having an automated system will not affect the desired change; the hospital teams must be given the opportunity to design, test, implement, and review the new processes required to put the newly minted automation to work.

We can spend a great deal of time getting the information where it needs to be, but if the processes that have been around a long time are not enhanced/updated to take advantage of the new information, what have we accomplished? Maybe we have a much better informed, albeit broken process. Just because we get all the data right, doesn’t mean the outcome is going to be improved, IMHO.

I’d like to think of myself is a fairly good woodworker; well what I produce/build/create pleases my wife, therefore, I get new projects to tackle, each one a little more complex and challenging. Having great data available is like having great materials and excellent tools; however, if I don’t know how to use either of them in the right way, then what I make is very expensive sawdust.

Process interoperability

A recent Becker’s Review article mentioned an Allscripts On Call podcast, which called out “Process Interoperability.” It got me to thinking about how we’re not focusing on the right targets. For the golfers reading this, we’re working on our long game and missing the importance of the short game. Getting the ball up the fairway is the easy part, getting it close to and in the hole requires a much different level of skill and tools. Just moving the data with interfaces, APIs, etc. won’t scratch the itch (have I used enough metaphors yet?). It’s the process, stupid.

I’ve had lots of physicians say, “don’t tell me what I already know. Don’t give me a bushel basket of data to search through. Tell me what I don’t already know about my patient.” And lately they say, “Don’t make me have to ask for it.” The last one is the tallest order of all. I used to think that physicians wanted some type of neural interface or they wanted the computer to read their mind. But as I listened to more physicians and listened more carefully, I think I understand what they are really asking.

They are not asking for magic or smoke and mirrors; they’re asking for the same experience within their EHR as they get when they are ordering from Amazon or other sites that have “learned” what their habits are and can anticipate the next order and/or question. Why can’t we make the EHRs that smart?

The short answer is, we can — or, we should.

There is a good deal of research currently underway to “teach” the systems to “learn” the habits of physicians. Using key characteristics of a patient history/encounter, what information the physician routinely reviews, whether there associated practice guidelines (read clinical decision support). Please don’t read into this that I believe that the systems can take the place of the physician in the process of medical decision making, I only suggest we can use the systems as tools to support those processes and offer information (in a non-intrusive manner) that is pertinent during the course of the clinical encounter.

About this time you may be asking yourself, what does this have to do with interoperability? Let me explain.

The primary idea of interoperability is to bring data from various sources together within the clinical workflows. Depending upon where the patient has received care, that data could reside in lots of locations, or it could reside in a normalized clinical data repository that is curated by your local/regional/state-wide HIE. For the sake of this example, let’s use the HIE as the data source, since they have already gathered the data from the various care locations, matched the patient to the data, and normalized/coded it appropriately.

As the physician reviews the patient’s recent labs, the system (in the background) is looking into the HIE’s clinical data repository for other similar lab test for comparison and lets the physician know they are available if he/she would care to review that level of history. If the physician has determined that an MRI study is required, during the ordering process, the system is looking in the HIE’s data to see if the patient has had the same MRI study recently, and if they have, alerts the physician and offers to display the report and/or potentially retrieve the images (depending upon the image archive integration).

These are just a few process-related examples that come to mind. There are many others. The interesting thing is that with a little work, these ideas can become reality and actually may be in some places. If you’ve not heard or read about “CDS Hooks” check it out here. I think you’ll find the concept interesting at the very least.

To wrap this up, I’d like for the industry to finally start looking at the ultimate goal of all the automation we’ve been busily putting into place for the last 10 years (it’s actually been longer, but I thought I just go back as far as HITECH); implementing methods to enhance the care processes and inform the clinicians within the established workflows. I’m sure along the way we can find ways to remove work from the systems that we’ve designed.

I’ve been in healthcare all of my adult life, which is just a few decades. I’ve had the pleasure of working with a great number of very dedicated and really smart professionals who want to provide an extremely high level of care and provide for the best possible outcomes for our patients. Let’s give them a helping hand by designing systems and applications that help them in this endeavor.

Many thanks for reading, your comments and thoughts are always welcomed and encouraged.

This piece was originally published on Chuck Christian’s blog, The Irreverent CIO. After spending decades in the CIO role, Christian now serves as VP of Technology & Engagement with the Indiana Health Information Exchange.