Skip to content Skip to navigation

Integrated Information Technology: A Contradiction of Terms?...I really want to know!

January 14, 2009
by Pete Rivera
| Reprints

I am often asked to evaluate organizations that have different clinical systems, financial systems, practice management and charge entry. These run the full range of top healthcare vendors. The question is normally the same: Should we be on the same platform across the enterprise or select from the best of each?

I think that vendors like to seize on clients that do not have their full product offering. Vendors like to make them think that they are not fully exploiting their system’s capabilities or that they can not fully support them because they rely on other systems.

I see some vendors like religious affiliations. They expect you to live and breathe the brand, drink the kool-aid, and never again blasphemy by mentioning another vendor’s name.

I guess I am agnostic when it comes to vendors, and I can see both sides of the argument; “Best of Breed” or “Total Enterprise” System. However, when you have the same vendor across your enterprise, don’t you still interface within the same product? I really would like to hear from folks that have encountered issues with either scenario.



Single vendor versus Best of Breed - a debate that has raged for decades. Not only in healthcare but also in all other industries.

Since anything larger than a 25 bed facility is going to have at least a few 'interfaces' there really is no such thing as a true single vendor solution. In fact many single vendor systems have a myriad of interfaces working under the covers. The difference is they are clearly the responsibility of the one vendor and the hospital doesn't have to worry about them - only suffer through the outages when they occur and plead with the vendor to fix them ASAP!

Ever since CIO's decided to get out of internal development and started pushing a 'single vendor' or 'single suite vendor' they have morphed from IT managers to Master Contract Administrators (maybe IT should report to the Purchasing Department?). I am not suggesting hospitals get back into writing code (although I would argue that there really are some situations where it would make sense) but I do believe the role of the CIO has to be more than a purchasing agent.

Since no vendor can cover all the bases of all department requirements, especially in large facilities, the role of the CIO has to be the 'Chief Master Integrator' (CMI). The CMI is the one responsible for making sure all the varied department or suite solutions work together. He/she must set, evaluate and enforce the standards third party systems must meet to insure reliable interoperability in his/her organization. The CMI acquires and deploys tools necessary to maintain reliable interoperability. In effect the CIO via the CMI takes on the role of middle-man and referee so the diverse needs of key departments are not ignored in the name of integration through single source simplicity. This is not an easy task, being in the middle never is, but if we are ever going to realize benefits from a systems oriented architecture (SOA) or true enterprise architecture (EA) somebody has to take on this role.

Meanwhile the simple single vendor approach really amounts to a 'less work for mother' - mother being of course the CIO!

Pete: It strikes me that there should be better qualification of the term integrated when it is used to market healthcare IT systems. For some vendors it means that all their products come from that single vendor even if some of the individual applications were developed by different firms then purchased. In this context, integrated really means that the interfaces are prebuilt and even these usually need to be tweaked to get them to address the specific implementation configuration.

When I evaluate systems I like to reserve the term for systems with modular application functionality (clinical and financial) that ultimately produces a single database of patient data with well established data definitions and a common lexicon. As we evolve from using clinical and financial systems to display stored data to actively using that data for decision support, business intelligence, and similar data analysis, the need for a "single source of truth" when making decisions based on data looms large.

My experience has been that trying to achieve that "single source of truth" master database through interfaces and multiple ETL processes with merging of data into a common database or data warehouse is a very long road with constant manual tweaks. Reliability and validity of the data seems to require much more diligence than a true integrated database since so much more attention needs to be paid to how the data is being linked between files.

It is a deep philosophical divide whether the pain of the many (users who are giving up "best of breed" features that might improve usability and productivity) supersedes the pain of the few (the IT programmers, database analysts, and decision support analysts who devote their time to bringing the separate database sources together and try to produce reliable information from what results).

For most, the compromise is to integrate as far as the quality of the software allows and interface in the rest. Hopefully the database of the integrated "master" system will be able to accommodate the data elements flowing in from the interfaced applications.

The terms Integrated, Interfaces and Intrinsic or used interchangeably. I am a true believer in Service Oriented Architecture. Maybe then (if they all used it) we could get away from cranky HL7 mapping.

Pete Rivera

Director Informatics, Hayes Management Consulting

Pete Rivera