Build or buy Health IT? Some assembly required.


BuildBuyFor as long as I can remember there’s been a great debate in health IT—build or buy? Every few years the pendulum seems to swing more to one side or the other which totally defies the laws of physics in the real world. Today that pendulum is showing signs that it squarely favors the buy side of the equation. Larger hospitals and health systems have been dumping homegrown solutions and spending tens of millions and sometimes billions of dollars for hospital information systems and electronic health record solutions from major industry solution vendors. A recent example comes from the Mayo Clinic where they have announced a rip and replace initiative to switch out their long-standing homegrown solution with a solution from global ISV, Epic.

Although this is certainly the trend right now, I am beginning to see a few cracks in the strategy. In a recent article in HealthcareITNews, HIMSS Media Executive Editor, Tom Sullivan, provides examples of hospitals and health providers who are bucking the trend by building their own solutions. The article, Innovation Pulse: The bold art of build-your-own IT makes it clear that rolling your own isn’t for everybody, but does have its place for institutions confident enough to give it a try.

In my world travels I’ve often come across homegrown health IT solutions that quite frankly are far less costly and provide a much better user experience than many of the commercially available HIS/EMR solutions on the market today. Homegrown solutions, especially the newer ones, are often built using commodity development tools and contemporary commercial software from either open source providers or consumer  software companies. Whereas the global health industry IT vendors may have solutions that are deep in functionality, they are frequently out of scope for small to medium-sized institutions. Often these big vendor solutions have evolved over the years from what was originally financial system software to something upon which clinical functionality was later added. These “legacy solutions” while comprehensive are sometimes not best-in-class when compared to some of the recently developed home-grown solutions I’ve seen that have been built using more contemporary enterprise framework architectures with wireless mobility, a modern user interface, and cloud-based services in mind.

I was heartened to read recently that Athenahealth and Beth Israel Deaconess Hospital have formed a partnership to develop a cloud-based, hospital HIS/EMR solution. It is clear to me that cloud-based solutions are the future of health IT. What hospitals and health systems ultimately need are solutions that are more or less “plug and play” and don’t require huge IT staffs to maintain. Around these lower-cost, highly scalable subscriber-based solutions hospitals can then add other cloud software solutions for mail, messaging, voice and video communication,  care team collaboration, analytics, forecasting, project management, customer relationship management, and more. While such a plan isn’t strictly a “build your own software” kind of strategy, it is a “build-your-own” health enterprise solution made from building blocks of contemporary cloud services.

AssembleOne struggle for healthcare organizations is how to get from where they are today to where they ultimately need to go. Fortunately, there are solution providers that have positioned themselves to fill in the gaps. An example might be Infomedix from Object Consulting. Infomedix provides a path for hospitals in Australia to turn old paper records into organized files of scanned electronic documents that are fully searchable and always available. Another example might be OneView Healthcare, a company based in Dublin, Ireland, that sells a portal “platform” upon which institutions can plug in customer-facing IT services to provide patients with entertainment on-demand, patient education, communication with friends and family, attendant call services, dietary menus, satisfaction surveys and more. Using the OneView portal interface, clinical staff can access information from lab, pharmacy, and other departmental systems. Yet another example might be a solution such as the one offered by Imatis Visual Heath in Norway. It can turn an archaic electronic medical record interface into something that is not only highly intuitive, but visually stunning.

Should you build or buy? Perhaps you should be doing a little of both—what I might call the “assemble” approach. Those are the choices. For the time being and for the best results, I tend to favor a model that says, “some assembly required”.

Bill Crounse, MD                      Senior Director, Worldwide Health                   Microsoft 

 

 


Comments (2)

  1. Steve Luke says:

    The build vs buy debate may never end.  However, in the real world building your own will never cost less than buying?  Having and IT Staff in a hospital or any other business is not the same as having a software development team dedicated on building a software solution.  An IT Staff may become intimately aware of the needs of the healthcare facility and be able to cobble together a good system for one or even a few departments.  However, to keep up with the demands of the current world, I find it hard to believe an in-house team of software developers can build a solutions that will compete with even a mid-level software vendor in the healthcare market.   Think about it, a mature healthcare vendor most likely has hundreds of hospitals or clinics using their software, they are receiving request form thousands of users and working every quarter to compete with other vendors.  The pressure to stay competitive keeps most vendors on their toes and makes their products better and better.  No company truly does a build these days.  Even the software vendors are using an OS from one or more vendors, a database, web service,  a report writer, form design, document generation system etc.  

    The average caliber of developers that make a lifelong career working for a software company versus a developer working as part of an IT Staff is pretty dramatic.  Don't get me wrongs there are genius level people working in areas that are below their skill set.  In the end, the dedication and focus of a hospital or a software vendor should be "To Do What They Do Best".  This doesn't mean that a hospital can't have a strong IT staff that knows how to cobble together and manage a great system.  It just means they should focus on what is important, serving their customers!  They can't do that if some portion of their focus is in building their own mouse trap.  With all this said, even the software vendor will be faced with the build vs buy decision for some components of their product.  So, yes some assembly is required!

  2. Peter MacIsaac says:

    Some Assembly Required – more like Some Design Required.

    Purchasing systems such as any of the  large integrated multi component EMR system is not like running MS Word or Excel – more like SharePoint or Access – some considerable design is required to "build your system"  Its not like buying a flat pack set of shelves from IKEA,  pullout the hex key and hey presto. More like buying a kitchen in 500 components, with some loose marching orders and consultation over the phone, and hoping your spouse will be happy with the end result.

    The rewards of customizing the product to what you need can be great, and the cost of less than usable implementations are obvious – see the problem when the nurse triage system didn't talk to the physician clinical documentation – a recent Ebola exposed patient gets shown the hospital door.  More is spent on implementing these systems than the size of the  cheque to the vendor!  Beware the  total cost of "assembly".

    A more pressing strategy problem is faced by  hospital and organizations who have incrementally build part of a total solution by purchasing one off "best of breed" systems as resources and strength of "business case" allowed. Another driver of this scenario is  mergers which bring together a strange lot of IT bedfellows.   The major challenge is in Integrating these components into a workable total system, when each  seems to think it is the centre of the application universe.    Yet in many parts of the world (where GDP spend on health is less than 10%) hospitals or networks can't afford the upfront expenses in either buying a total new solution or building one – they have to make what they have work and grow.

    Love to hear from hospitals/networks that have made this work – not vendors or pretenders

Skip to main content