Response to CIO Magazine Article - Why you need more than one software vendor

I posted this response at CIO.com in response to an article surrounding the need for more than one software vendor.  Text of response is below.

READER FEEDBACK

Spencer Hamons Tue, 2008-01-15 17:09

Although I agree with some points made here regarding negotiation position and the relatively small number of large software vendors available, I take issue with just stating that this is the best strategy.

This may well be the best strategy for organizations with mature enought IT departments capable of handling the complexity multiple vendors involves. It is also dependent upon the business of the organization and the risk tolerance and what data integrity means to the specific organization.

For example, I am the CIO of a hospital, and if I encounter a data integration problem that happens to result in some clinical data from one patient being transposed to another patient, I don’t have an upset customer on the end of the support line for an online order they placed. I have the potential for adverse drug interactions, incorrect lab or radiology data, or even death resulting from mistreatment. These are risks that I am not willing to take for the sake of a negotiation advantage. Likewise, if my IT staff were 250 employees capable of monitoring each and every HL7 transaction, my risk tolerance would be different than it is currently with my 10 IT staff members. Additionally, in healthcare, I never have the luxury of taking the entire system down for 24 hours over the weekend…not even a portion of the system. In a 24×7 operation, care must be taken on how do you keep systems active and functioning day and night. If a data integrity problem erupts, for the safety of our patients, we have to take systems off-line. With “one throat to choke”, combined with good contract metrics, the vendor is motivated to resolve our problems quickly rather that point fingers at integration points.

This is a topic that will be discussed on an upcoming podcast at ITPodcast.org for anyone in the healthcare industry (or interested in the healthcare industry) that would like to listen in.

Posted under Hospital Information Systems

This post was written by Spencer on January 15, 2008

Tags: , , , , , , , , ,

My take on various hospital information systems

Since we are going to be discussing the pros and cons of various Hospital Information Systems on our podcast, I thought I would add some comments here.

Being that the majority of my experiences have been in the community hospital market, I tend to give a lot of attention to “Integrated” hospital information systems.  When I talk with other CIO’s about these types of systems, I always hear comments about Meditech.  Just so you know, I have used Meditech MAGIC, Meditech C/S and even used the Columbia / HCA variant of Meditech.  At one time, I was a huge proponent of the Meditech system.  Although I never liked the look the software presented to the end user, I found the system reliable and fairly easy to manage.

 I have expanded my horizons a bit in the integrated HIS market over the past few years and there have some really nice developments in the marketplace.  Currently, at San Luis Valley Regional Medical Center (SLVRMC) where I am CIO, we are using McKesson’s Paragon HIS.  This system has impressed me more than just about any of the other systems that I have seen lately.  What is interesting is that when I was recruited to SLV Regional Medical Center, the executive team hired me because of my experience with Meditech C/S and Magic.  The executive team was disenchanted with Paragon and wanted to pull it and install something more “capable”.

What I found was that the system was a poor installation, not poor software.  I was nervous about what I was going to do to get this system working, because my experience with McKesson in the past was limited to Methodist Healthcare, where we were primarily a McKesson HealthQuest and Horizon shop.  The system was so complex that it required approximately 200 IT staff, numerous interface engineers, and we always seemed to be in the middle fixing some sort of interface “emergency”.  And god help you if you needed assistance from McKesson, because they were going to nickle and dime you for everything you were worth.  I never could figure out just what our maintenance dollars covered.

What I learned was that McKesson is like Ford Motor Company.  Ford is a huge company, and you can buy a Ford Festiva, an F150 pickup, a Lincoln Navigator, a Volvo S80, or a Land Rover Range Rover…but regardless of what you buy, you purchase a Ford.  Likewise, the quality of vehicle between the Ford Festiva and the Range Rover is completely different.  When you go for service, chances are you will have a different experience when you take in your F150 versus when you take in your Volvo S80. 

What I learned was that McKesson is the same way.  McKesson Provider Technologies has Healthquest, Series, STAR, and Paragon all as “hospital information systems”, each with its own market target.  Just like with the Ford example, the service experience is quite different between the various products.

McKesson’s Paragon group is completely different than my experiences with HealthQuest and Horizon.  I have a single group to contact for problems, they are responsible for any internal conversations that need to occur, and probably 90% of my issues are covered under my annual maintenance agreement.  I also get a Microsoft based product that runs on Microsoft SQL, only requires 4 servers to run both my test and live environments, and actually has a viable plan on keeping up with technology.

Posted under Hospital Information Systems

This post was written by Spencer on January 5, 2008

Tags: , , , ,