Your lead biller is sitting in your office complaining that the electronic health records (EHR) system you just deployed that was guaranteed to be interoperable with your practice management and laboratory data systems isn’t – or at least isn’t easily interoperable. “I thought these applications were integrated,” you say. “They are,” your IT person says, “it just takes a lot of work.”

Interesting words, “interoperability” and “integration” – but what do they mean?

Interoperability means two systems, in our case software applications like practice management (PM) or EHR systems, are designed to do some amount of sharing between them. At this level, systems share either data or function. Sharing of data is easier as it implies that the two systems can pass data back and forth, and more importantly can actually do something with the data from the other system. Sharing of function implies that the systems can share business processes or workflows (as well as data). This would mean that you could start a workflow (for a patient visit, for instance) in your PM system and continue it in your EHR with the data from the PM system. In this best case, these applications are interoperable at both the data and workflow levels, and you get a simplified and more efficient patient encounter. Interoperability will give you a greater understanding of the relationships among the data that you use in clinical and business operations, and may lead you to seek improvements to the quality of care you provide and the financial operations of your health center.

So what about integration? It is nice that your applications have been engineered to be interoperable, but how does data or workflow sharing actually happen? Integration is the technical work done to enable interoperability. The design and use of an integrated set of applications can greatly simplify both the clinical and business operations of your health center. Let’s go back to your PM and EHR systems. The person at your front desk has checked your patient in and she is waiting to see her provider. Some information from the PM system is transferred to the EHR application. These applications use a data sharing standard to structure the data that is passed. If your IT system uses an integration engine, these programs take the data from the PM and transfer it, via your network, to the EHR application. The EHR now takes the data and places in the right place in its database so that when the provider opens the application and starts their work with the patient, she sees the information from the PM system. In order for this to happen, your IT people had to use the user interface of the integration engine to allow it to recognize the PM application, understand what data would be transferred from it and know where to put it in the EHR. This is actually a lot of work. Your programmer has to understand what data is to be shared between applications, and work with the integration engine so the right thing gets done to the data on each side. This requires programming knowledge, knowledge about the relevant standards, and an understanding of how the data will be used. Tools such as integration engines make integration simpler, but it still takes a good deal of work.

If you are not using an integration engine, your IT staff would have to write code in a programming language to do what the integration engine is doing. This requires relatively complex code, takes considerably more programming expertise, more knowledge of standards than using an integration engine, and the same amount of knowledge about how a health center works. In both cases, testing is critical and it may take time to get everything right. After the provider is finished with the patient’s session, data is passed back to the PM in the same way. Even doing this the easy way, with an integration engine, takes real work.

What about other issues with integration and interoperability? There are a number of technical issues including those described above, as well as issues related to applications that either are not standards -compliant or implement a standard in their own (non-standard) way. It’s important to realize that just because an application is compliant with a standard, does not mean it is interoperable with your other applications, or easy to integrate. Just as important, however, and in some situations probably more important, are non-technical issues. These include cultural issues around data sharing, liability concerns related to data sharing and hurdles to adoption of new technologies caused by resistance to change.

Over the last several years, I was a technology consultant to one of the most visible data sharing efforts in healthcare. This was the Regional Health Information Organization (RHIO) in Santa Barbara, California known as SBCCDE (Santa Barbara County Care Data Exchange). This effort was started in 1999 and shut down at the beginning of 2007. There were many challenges with the effort, including technical issues, but the biggest problems were related to the lack of commitment on the part of several of the hospitals to share patient and clinical data with each other and the legal complications relating to assignment of liability for medical errors caused by shared data.

I know this example is about hospitals, labs, etc. sharing data in a RHIO, but health centers participate in RHIOs and the non-technical issues exist even if the data sharing is going on inside of a health center network or a single health center. Resistance to data sharing can be a substantial problem that must be dealt with by motivating people and organizations to do the sharing. Liability is even a bigger issue, unless you decide to treat it the way you treat medical liability in general – that is, as a fact that needs to be dealt with, not an impediment. Finally, there are training challenges. Using a single software application can be hard, but using several of them that are linked together can be truly daunting.

Thinking about interoperability and planning for the integration of the software applications that you use gives you an opportunity to really look at the work that needs to be done and the information that is associated with that work in your health center. Understanding these relationships is as important as comprehending the technical or socio-cultural issues relevant to this topic. This understanding may lead to broader uses of your data to improve outcomes and the financial viability of your health center.

Interoperability and integration can seem fraught with insurmountable problems, except for the very real advantages in both business and provision of care that they can enable. The ability to link information and workflow across departments, including front and back office, providers and administration, can give you simplified ways to do the work of your health center that make sense to the people doing that work.
The details are important, but the real focus should be on the work you need to get done and what information and tasks need to be shared to do it. That’s the actual advantage of interoperability and integration, and why they matter to your health center.

David Hartzband, D. Sc. is the Director for Technology Research at the RCHN Community Health Foundation.