Is Buy to Build as David is to Goliath???

In the January CIO Connection (the CHIME newsletter, no I'm not a member but a friend is) there was an interesting article on some questions asked by Insurer Executives at a Healthcare IT Summit. One of the questions was "Should our organization take a build versus buy approach to BI?". This is a good question.

When I first came to my organization it was literally in the basement as an operator changing tapes and printing UB94s. Well, before that I was a dialysis equipment tech but that was before my IT days while I was still in college. Once I got out of the basement I started working as a UNIX admin and that's how I got involved in a custom clinical portal development project. Basically two developers, a DBA and a UNIX admit had built a system that slurped up DI and Medical Records dictations in HL7 messages, dumped them to a UNIX box, loaded them into an Oracle database and presented them on the web via Cold Fusion. There were some other interesting apps that enabled physician to physician messages (almost a pre-twitter twitter really) and the ability for a MD to grab a rounding list from a Kiosk when they walked in the door. All of this before cascading style sheets and widespread use of XML. It was cool!

Until one of the key developers left and those of us who stayed behind were left the legacy of several undocumented VB4 programs running on an NT4 server that used a weird set of spaghetti like database links and PL/SQL scripts. For a long time we were afraid to touch a lot of it until we rewrote the pieces that we wanted to keep and a few years later we implemented our preferred vendor's physician portal product with great success. Now we spend some time customizing that portal so that it integrates well with some other apps that the physicians need.

So the CIO Connection article went on to point out pros and cons of both the build vs buy BI approaches. In a nutshell, build gives you depth and control while requiring more business engagement and solid processes. Buy gives you shorter time to value with less flexibility and more risk of creating information silos. Analysis like these make deciding the right path about as clear as mud. It also makes the article pretty accurate.

I've rolled the connundrum around in my head for a long while. Given the emerging maturity of the HITSP standards for integration (considered a "glimmer" on the Gartner Hype Cycle), accelerated adoption of EMRS, economic pressures and moral obligation to continue improving patient care I've fallen on the customize/build side when it comes to Business Intelligence. The need to understand, care for, manage and secure our organization's data REQUIRES that we have high levels of business engagement/sponsorship and effective process. The deep expertise required to customize/build that environment forces the issue and the facilitation in a way that "packaged" tools don't. Plus the addition of the packaged tool vendor adds a third relationship to an already complicated mix.

I feel less strongly about building other key functions, web and collaboration tools aside. The thing that might change the game over time would be widespread adoption of HITSP standards as the glimmer brightens to a beacon. Then the art of integrating systems or delivering information to the right stakeholders becomes much easier. The interfaces between systems become predictable and the data that passes in between is better defined. Organizing the components using techniques like SOA and SAAS improve flexibility and ability to respond without sacrificing supportability.

Then build would be to David and buy would be the Goliath...

Integration on my Mind

Lately, like a lot of other folks in this industry, I've had integration on my mind. Specifically tying together ambulatory and acute care visit data that resides in two or more different vendor's systems. It's not trivial. It depends on a lot of technical nuts and bolts with the most important being an enterprise master person identifier (EMPI, surprisingly the wikipedia entry isn't that robust) to crosswalk patient identifiers and records across the systems. Then a collection mechanism is needed. This could be collecting the information for a patient in a single view or the development of another repository that aggregates all of the pertinent information for display. All of this has to be done quickly and efficiently for the patient and/or provider.

Then we need to factor in the dynamic nature of these environments. Healthcare evolves faster and faster. So too is the technology used to support it so whatever the solution is needs to be capable of bobbing and weaving as software, requirements, processes and regulatory needs change. The current buzzword for this is agile. If we build something cumbersome and difficult to maintain then it will not survive. This is an important trait for all healthcare technologies but they don't often deliver even though it's the promise of nearly every new development environment.

As frustrating as this is it also makes the problem fascinating. I dream about it occasionally. I wonder how Software as a Service, Service Oriented Architecture, emerging standards and market forces will eventually drive towards (hopefully) sustainable solutions. There is a lot of work being done in this domain and a lot of opportunity for innovation even as our vendors struggle to align their product lines.

My advice for all healthcare IT vendors? Be the first and fastest to integrate your product with anyone else's and provide nothing but the best customer service. I think only the best are going to survive the next few years. May the best products win.