According to Wikipedia, Health information exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system. HIE provides the capability to electronically move clinical information among disparate health care information systems while maintaining the meaning of the information being exchanged.
That seems really straight forward, at least to me. I find it helpful to whittle complex ideas down to a point that enables me to explain them to my parents, without either of us having to reach for the Tylenol.
In its simplest form, an HIE is a pipe, a pipe that transports ones and zeroes. Back in the days when I still had hair, one of my clients was the CEO of a large cable television company. He explained his business this way; “We are just like the water department. We put a pipe in the ground, send something through it, and every month people mail me money.”
He also sent ones and zeroes.
Now, there are those around us, apparently thousands of them, who have made it their mission to convince those in the minority that HIEs are far more complex than they really are. Maybe I just do not understand the concept of ones and zeroes.
You probably know that several hundred HIEs are in the process of being built—and they are all being built by people who have little to no experience building HIEs. Now, here is where everything gets a little hairy. Let us look back on the definition of an HIE and let us focus our conversation on building just one HIE. The tricky part about getting the HIE to work is that pesky little word “disparate,” as in disparate health information systems, and the last time I counted EHRs, I hit 300 before giving up.
That is where all that disparate clinical information comes from. However, when push comes to shove, the information from all of those different EHRs is pretty much the same, but the various EHR vendors just line up their ones and zeroes differently, thus enabling them to prevent others from playing in their sandbox.
There is another disparity surrounding HIEs, one that is unspoken. Suppose you and I decide to build an HIE, a good one. After some period of time, we get rid of all the little disparities among the various EHR vendors and are able to zip those little ones and zeroes from one end of the HIE pipe to the other. Let us also suppose we used a very long pipe, so we could use this HIE anywhere. It would work for a hospital, or at an Integrated Delivery Network (IDN), or across a region.
Our HIE is able to move our individual healthcare information from one end of the pipe to the other wherever the other end may be.
I forgot to mention the disparity. The unaddressed HIE disparity is the one created from having hundreds of HIEs, each designed in its own vacuum by people who have little experience filling vacuums. And when those HIEs have been built, what will they do? Exactly. They will move clinical information among disparate healthcare information systems. In laymen’s terms—ones and zeroes from EHR vendors who do not play well together.
The new ones are identical in functionality to the one we just built, only now there are 500 of them.
Now to the meat of the issue. If we build an HIE correctly, and build it to be able to handle any disparity, is there any more need for HIE 2, since in theory HIE 2 will be able to do the same things as HIE 1? Let us extend this same thinking from HIE 1 through HIE 500. At some point—irrespective of certain technical issues—can it be concluded that the total number of HIEs needed to move ones and zeroes is one?
Other than the redundancy and expense of building a few hundred things that each perform the same function, the real problem of having multiple HIEs is that each new HIE greatly increases the complexity of moving a personal health record from point A to point B. If HIE 2 is the same as HIE 1, we do not need HIE 2. If the two HIEs are not alike, when we try to transport a personal health record from a patient in HIE one and move it to a doctor in HIE 2, the disparity created between the two almost requires a new HIE to resolve the problem. We will have infinitely compound the complexity of moving ones and zeroes by deploying 500 HIEs and hundreds of thousands of healthcare providers and a few hundred million patients, and we have designed quite a mess.
And why does the mess exist? It exists to move those same ones and zeroes we were moving quite nicely by the HIE we built. One can argue that scale may create its own design issues, but those issues do not make this idea dead in the water. Issues of scale are solvable; those of compounded complexity are self-imposed due to an overzealous design.
The proposed way to solve the upcoming problem of compounded complexity is to build the National Health Information Network, the NHIN. We need the NHIN to act as a super HIE, to remove the disparities that result from having multiple disparate HIEs.
Adding further unwarranted complexity to the multi-HIE model is the fact that each HIE has resulted in several hundred providers designing and retooling their healthcare IT systems to adapt to these anomalous HIEs.
Sometimes the most difficult solution to envision is the least difficult one to implement.