Code Red? No. Just what the doctor ordered.

image In the July/August edition of Washington Monthly author Phillip Longman, a senior fellow at the New America Foundation, delivers what I think is a misguided punch to the commercial software industry.  His article, “Code Red—how software companies could screw up Obama’s health care reform” offers up a couple of examples where CPOE/HIS implementations using proprietary commercial software solutions went terribly wrong.  He then uses these as evidence for why open source software, particularly the VistA solution that came out of code developed by the Veteran’s Health Administration, is what’s needed to fix the IT mess in healthcare.

I don’t think the argument is about open source vs. commercial software.  The argument should be about what works and what’s required to address the needs of healthcare workers and the health industry.  Over the years, I’ve written and lectured extensively about what it is that healthcare workers must have from the information systems they use; the best information worker tools on the planet, a multitude of data input options, a more standardized and intuitive user interface, applications that extend to and work well on mobile devices, solution interoperability, and a lower total cost of ownership.  On that last point alone, there’s plenty of evidence that open source is often not the lowest cost option.

Mr. Longman and I would agree that dumping billions of federal dollars in incentives on hospitals and physicians may not be the best way digitize healthcare; not without careful analysis of what it is we are trying to improve and how software contributes to that improvement.  I can also agree with another passage in Mr. Longman’s article where he writes; “because proprietary systems aren’t necessarily able to work with similar systems designed by other companies, the software has also slowed what should be one of the great benefits of digitized medicine: the development of a truly integrated digital infrastructure allowing doctors to coordinate patient care across institutions and supply researchers with vast pools of data, which they could use to study outcomes and develop better protocols.”

imageThat sounds to me like a clear endorsement for Microsoft’s  Amalga Unified Intelligence System.  Amalga liberates unstructured health data from systems and silos (proprietary, open, or other) and provides a truly integrated digital infrastructure where powerful yet intuitive analytics tools can be applied to turn data into knowledge and insight into action.

The health industry has been woefully underserved by the information technology industry.  Too much of what’s out there was designed way too long ago by software engineers, not clinicians.  But that is beginning to change.  In fact, here at Microsoft we now have scores of clinicians working on the solutions we develop.  Superb contemporary EMR and HIS solutions (both proprietary and open) are now coming to market.   But we mustn’t get distracted or lose focus on what it is all about.  It’s not about whether proprietary or open source software is better.  It’s about how we use that software to improve the cost, access, safety, care team collaboration and quality of patient care and the health of citizens around the world.

Bill Crounse, MD    Senior Director, Worldwide Health     Microsoft

Comments (5)
  1. opurcarea says:

    Dear Bill,

    I totally share your view on this matter. The point is not about the openess of the source code but abour usability of the software (including interace and functionalities) and the way it support the clinical process. Without clinical decison support systems and real time workflow management the EHRs/EPRs have little chances to improve the outcome of healthcare in US and in other parts of the world. Moreover, without an integration with PHR (such as HealthVault), the communication between health professionals and the patient is much more difficult. We would then lose the precious involvement of patients in their own care.  The Red Code woudl be the implmentaion of IT systems without a vision and without involvement of users.  

    Octavian Purcarea

  2. I would agree that there is lot of gap between Health Industry and IT/Software industry. Perhaps our programmers are too busy and making too much developing new games, new websites or new social networks than focusing on health care.

  3. John Lynn says:

    Nice analysis except for the obvious bias towards Amalga.

    I agree that there are finally a number of really excellent EMR out there.  They aren’t perfect (and never will be), but they have made amazing strides over the past couple years.

    The question is how doctors are going to find those EMR that are excellent and avoid those that are unusable, but have a ton of marketing dollars.

    There’s a great digital divide right now between the practical needs of doctors and finding the right EMR software even with $18 billion of EMR stimulus money out there.

  4. Good post, Bill, with an admitted point of view.  Interoperability is the key.  If open source can compete, then good on ya open source.  Physicians need to remember that the goal is a smoothly operating information system, not just software.  Productivity gains come after training, re-tasking, equipment and culture changes—not at the moment of installation. I thought that Longman’s focus on VAH software took little into account of the differences between VA culture and that of most acute general hospitals.

  5. Aditya Pathak says:

    I agree with your perspective Bill. This debate is not about Open Source vs Proprietary software. It is about what solution is right for the current state of a particular health system.

    Most of the health systems are still in the early stages of care delivery using IT applications. Proverbially, they are still learning to walk, and there is a lot more to be learnt and a lot more to be practiced, before they can start to run.

    In my view, there are basic solutions (Open Source or Proprietary) that are required for most of these organizations. These solutions need to be easy to implement, easy to learn and easy on the budgets. Once the basic adaption is in place, then the enhanced functionalities and complex applications with more bells and whistles can be considered as an evolution step to the next level.

Comments are closed.

Skip to main content