I was in another meeting last week discussing getting a field, total charges, from the hospital billing system to the auditing tool of the coding system. We are right now in a starting position for this type of endeavor, we don't have centralized charging ororder entry yet, so the only place to obtain centralized charging is from the system that has all the data. We have to get from point a to point b in a timely manner, my suggestion was to interface the data through the integration engine. The interface analyst and hospital billing analyst just want to add another point to point interface.
It's just another interfaceand there we have the quintessential problem.
Interfaces are data feeds, and they are relatively straightforward. In some organizations, this is a strategic plan that is well thought through with consideration to architecture and interoperability. In others integration is actually an afterthought, an added service. One has the application, the data, and the integration. Sentiments like the above over a long period of time result in one largely unplanned environment that is basically uncontrollable and unmanageable. Especially with the view of that everyone needs all of the data elements from everyone else.
So our problem can be relayed in this picture with a small snap shot of 4 applications. Most healthcare organizations have above 50 applications.

For example, let’s just say we have a number of applications and a number of data sources. So if we
want to interface the applications to the available applications data sources, we need to be able to manage all of the application multiplied by all of the available applications. How hard can that be? Let’s take a look:
| Total Applications | Available other Applications | Point to Point Interfaces |
| 1 | 0 | 0 |
| 2 | 1 | 2 |
| 3 | 2 | 6 |
| 10 | 9 | 90 |
| 25 | 24 | 600 |
| 50 | 49 | 2,450 |
The overhead for the “just another interface” mentality is heavy. Not to begin to add to the picture the effects of misinterpreting and incorrectly using the source data…This approach does not lead to a long term stable environment.
So how do we fix this problem? IT is in the business of implementing new applications.The customer desire is fierce and there is a definite need.So we really can’t reduce the number of applications.The other item is that each application will have its own data source, hopefully just one. Although we can several data sources within one application, therefore it is unlikely we will reduce the number of data sources.What if instead of implementing all
applications interfacing to all data sources, we had an application interface to a hub and the hub can disperse the information.So if we have four applications that we need to exchange data, we have

| Applications | Point to Point Interfaces | Integration Interfaces |
| 1 | 1 | 2 |
| 2 | 4 | 4 |
| 3 | 9 | 6 |
| 10 | 100 | 20 |
| 25 | 625 | 50 |
| 50 | 2,500 | 100 |
The other value added benefit, is to exchange one solution for another.After a period of time, all one needs to do is just unplug one, and replace it with another one. All of the receiving and exchanging interfaces are predefined. Healthcare is getting there with HL7. It facilitates and simulates a real-time business. Of course one could always do the SOA route of life.


