Health information exchanges: How to think about interoperability
InfoWorld: There seem to be a couple of sets of issues that people are wrestling with. One is the exchange among providers. There's this whole notion of health information exchanges [HIEs] and so forth. The impression I get is that they're all over the map. Some won't even sign BAAs [business associate agreements, obligating them to legal responsibility for information management], which sounds to me as if they're really not in the business if they won't do that. But there seem to be questions around "Who do I trust?" "Is there really a set of common exchange formats?" "What does it mean to have exchanges of batch processing for transferring a patient from one facility to another?" "Is it supposed to be more real time, such as if it's an emergency room situation or you've got personal multiple providers who may have several appointments in the same week, so you don't want to have information that is outdated?" I've talked to providers who do all these models, and each seems to focus on one model or another. I wonder if there's something about the model that isn't clear, or maybe that's just life -- there're several models and they need to shake themselves out.
Fridsma: The first thing is that when they talk about interoperability and exchange, I think people have different definitions of what interoperability is, so we follow the IEEE definition. Basically, interoperability has two parts. The first part is the ability of two systems to exchange information, so to be able to move information from one place to another. Then the second part is the ability of the system to use the information that was received. There are these exchange and use pieces.
A lot of people will talk about exchange as kind of moving information around, and using it as being kind of semantic piece or the ability to understand the information and know how to use it effectively.
Given that, it's important to recognize that there are a lot of different uses that people have, and you articulated some of those in your question. Health care as an industry is complicated, and there are lots of different ways to communicate. We've taken the approach that we've tried to model after the Internet, the TCP/IP framework that basically has different layers of the architecture. The technical details of it are less important, but it means we want to provide the fundamental building blocks that people can use to solve the use, the kind of interoperability they want to achieve.
Within the exchange piece -- distinct from the interoperability piece -- we've essentially said we want to enable ways of pushing information from one system to another. So we have put into the 2014 Certification Criteria this notion of the Direct protocol as a way of pushing information from one provider to another. We found there's a lot of use cases in which that's a very valuable way to do it. Some people have said, "I just want to be able to send a consult in my multispecialty practice down the hall or into a different building on the campus or whatever, and it seems silly that I need to upload it to an HIE and then they have to download it and I have to query for it," and there're all these other complexities that might be about that. For their use, we want to be able to push that information, so we included the Direct specifications as a way of creating that functionality.
We also included, as an optional certification criterion in the 2014 edition, a protocol called Web Services, which is a more system-to-system way of having the communication occur. It's based on a slightly different protocol, and it serves as the underpinning for some of the standards that many of the vendors use already. It certainly was one of the standards used as part of the Nationwide Health Information Network and now what's called the eHealth Exchange.
Many of the HIEs are using those kinds of protocols to help exchange information. I think we would likely not succeed if we relied on a single solution to solve the complex communication and exchange problems we have in health care. So providing ways to push information from one place to another or to be able to query and ask questions of different systems and get responses back is going to be important.
What we want to create is those building blocks: the way we format the data so that it can be computer-readable, and the way we exchange that data. We're really trying to create a portfolio of solutions, both for exchange and for the different uses that people might have for the data.