Should the DoD Buy Epic, or Cerner, or GE, or…?

Thought you might find this interesting


The Department of Defense (DoD) is in the market for an EHR solution… again. After a lengthy foray into building its own EHR from scratch (AHLTA), with miserable results, and another shorter detour through the fantasy land of an open-source integrated EHR (iEHR) with the Veteran Administration (VA), during which no material progress was made, other than spending taxpayers’ money of course, the DoD announced that it will begin looking for a commercially available product to suit the DoD’s unique needs. This decision is the source of much angst for some and much excitement for others, because no matter what the DoD decides to do, many more billions will be flowing out of taxpayers coffers and into the hands of a lucky few.

On one hand, since most people served by a DoD EHR will eventually be served by a VA EHR, it makes sense that these two government agencies should use the same product and aggregate a lifelong record for their patients. On the other hand, the VA EHR (VistA), although held in high esteem by its creators and users, is very old, and the VA itself is engaged in a major refurbishing effort through a public open-source framework. Answering to a highly frustrated House Committee on Veterans’ Affairs, looking for explanations and bemoaning the death of the iEHR, the DoD’s Frank Kendall reiterated the insurmountable costs and difficulties inherent in building a brand new EHR from scratch (better late than never, I guess) and highlighted the reasons why VistA is not as obvious a choice for the DoD as it is for the VA. Since the VA has VistA already deployed in all its facilities and it already employs an army of experienced VistA developers, a salvage operation for the aging VistA may make perfect sense for the VA, but none at all for the DoD which will be conducting a complete rip and replace program in the next couple of years.

Now that the self-developed iEHR delusion is dead, the technical controversy is focused on whether the DoD should select an open-source product, either VistA or a derivative thereof, or a proprietary system, such as Epic, Cerner, GE, Siemens, etc. The main arguments against a commercial solution are that the DoD should leverage the billions of dollars already invested in VistA, and that it should adhere to this administration’s preference for transparency and open-source technology. To better understand this conundrum, perhaps some terminology clarifications are in order.

Computer software comes in several flavors, and you may recognize most of these flavors if you researched your own EHR purchase recently:

  • Proprietary – Commercially Licensed Software – Licensed commercial proprietary software is software you purchase as a black box. You can install it on your computer and use it as is for as long as you want. This is a license to use the software, and implies no ownership rights for the product. The vendor will usually charge you for upgrades. Most often, particularly for business software, you can supplement this one-time acquisition with a maintenance and support subscription fee that will provide you with upgrades and assistance from the vendor. Think Microsoft Office.
  • Proprietary – Commercially Licensed Software + Source Code – Commercial proprietary software may include the source code (for additional fees) and rights to extend the original product for private use. Sometimes instead of the entire source code, or in addition to it, selected integration points (Application Programming Interfaces – APIs) are exposed to clients so they can add/customize certain functionalities on their own. Rights to enhance and augment the original source code for commercial resale are usually corporate arrangements not really intended for mere users of software.
  • Proprietary – Subscription Based Software – A more modern variation on the above is software-as-a-service (still commercial and proprietary), where you don’t purchase a license for the product, but instead pay monthly fees for using the software, which is maintained and operated by your vendor. These fees are usually a bit higher than the maintenance and support fees for licensed software, mainly because the vendor has to bear the infrastructure costs in this scenario. This goes by the name of “cloud”. Although the vendor may expose APIs for third party developers, this type of arrangement almost never comes with source code, since the buyer is not running the software. Think Microsoft Office 365.
  • Proprietary – Free Software – Free software is software you can obtain without paying either a license fee or maintenance fees. Free software may refer to software that you can download and use for free, or more often, free services provided through software residing in the developer’s datacenters (“cloud”). The larger the provider and the more individually geared the software is, the more likely it is that the provider will expose APIs to third party developers. Think Google anything.
  • Open Source – Free Software + Source Code – This is what comes to most people’s minds when they say open-source. This type of software is usually developed and managed in a public framework by an all-volunteer squad of techies who have an irresistible urge to donate their labor to better humanity. There are mountains of open-source projects, some highly professional, others not much more than a hobbyist pastime, and there are almost none in wide consumer use, other than a handful of exceptional non-profit foundations (e.g. the Mozilla Foundation and its Firefox browser or the Apache Foundation and its development tools and modules). Open-source pieces of software are often utilized by commercial software companies to speed up their internal development process. For example, IBM’s Watson includes various open source modules, but Watson itself is neither free nor open source.
  • Open Source – Maintenance Subscription Services + Source Code – A slightly different business model is an arrangement by which the software itself is provided for free, including source code, but maintenance, improvements, installation and training are billed on an ongoing basis. Sometimes special requests for features or premium functionality are also available for purchase. The software products available through this model are either developed in house by the service vendor, or obtained from a conventional community developed open-source project and enhanced by the service vendor. This model allows clients to customize the software on their own, if they wish to do so, but it may void or complicate maintenance agreements with the vendor.

Regardless of the model employed to obtain software, extensive APIs may or may not be available to third party developers who may be actual users, but most often are not. Software products that expose a good amount of well documented APIs are said to have an open architecture, which is based on accepted and open standards. APIs come in various flavors as well. Some are just plug-ins allowing third party developers to add minimal functionality that does not affect the main product in any way, and certainly does not affect the data layer. Tighter integration that may affect data integrity in the main product is harder to come by and usually requires approval from the original vendor if the software is proprietary. If you have access to the source code, either free or purchased, you can obviously do whatever you want, if you are reasonably certain that you can maintain the software on your own going forward. People or businesses without an IT department are rarely interested in tinkering with source code, so this conversation is really between IT shops, large businesses and true believers in this or that paradigm for software development.

Before returning to the DoD situation, one more word about vendor lock-in is in order. There is no doubt that having the source code (open source or purchased source), and particularly the database schema, makes transferring your data from one product to another a lot easier, if and only if, you have proper IT resources at your disposal. It is possible though, and most often very likely, that if your old product and your new product are very different, data loss will occur no matter how good your IT guys are and no matter how open both products are. Also, it is usually not necessary to have access to every line of code in order to migrate data from one system to another. A clean open architecture based on widely accepted standards is much more important for preventing vendor lock-in and for interoperability in general. Unfortunately none of the choices available to the DoD fit this bill currently, although some may be better than others. So what are the options available to the DoD?

  1. Adopt the VA VistA – The DoD rejected this option, but it may be helpful to review it just in case they change their mind again. The DoD could of course obtain the entire VA source code for free, and could also benefit from the VA meritocracy-based framework of open-source freebies donated by selfless defense contractors and eventually by some guy in the Ukraine that is inclined to help the U.S. military save money on software development.
  2. Obtain a different open-source product – There are none. The only viable open-source EHR option for large systems, other than the VA VistA is the privately enhanced and maintained VistA offered by Medsphere, which is also contributing enhancements to the VA open source framework. The other VistA derivative is WorldVistA.
  3. Buy a commercial EHR – None of those are of course open-source, although if you buy Epic for example, you get the source code, and I would assume that the same is available from all others. A commercial EHR will most likely still need to be tweaked and enhanced for military purposes, whether by the vendor or by the DoD, but it should come out of the box with a lot more bells and whistles than VistA, some useful and others not so much, depending on which one is selected.

Basically, no matter what the DoD chooses to do, they will have access to the source code, and significant programming effort will be required to tailor the product to DoD needs. Most products that could be considered by the DoD have some useful APIs and increasing adherence to standards, but open architecture is not a term that comes to mind in this context. The DoD could hope and pray that the open-source framework established for VistA will produce the software improvements the military needs, or most likely, the DoD will have to pay for all enhancements and new features. In addition to software programming, deploying an EHR requires funds for training and implementation which can easily exceed the software costs by orders of magnitude, particularly since the military has very unique deployment locales.

We may believe that software purchased or built with taxpayers money should reside in the public domain, which almost never happens by the way, but this entire discussion is not really about open-source vs. proprietary products, which is largely irrelevant for the DoD itself, but very much about the plum Pentagon contracts to oversee this mammoth change to its medical records system. The choices are: internally developed DoD resources, a ragtag team of VistA veterans, a newer service entity like Medsphere, a commercial EHR vendor like Epic, or an entrenched usual suspect like SAIC, and most likely a combination of a defense contractor with any one of the lottery winners above. No doubt that as is always the case, the Pentagon will be making a wise, frugal decision, free of biases and bereft of the undue influence of special interests.

Margalit writes regularly about intersection of healthcare & technology on her site: On Health Care Technology

  • RT @hitconsultant: Should the DoD Buy Epic, or Cerner, or GE, or…? #healthit #hcit

  • @ HIT Consultant Should the DoD Buy Epic, or Cerner, or GE, or…?

  • Should the DoD Buy Epic, or Cerner, or GE, or…? Department of Defense in the market for an EHR solution via @lmsergio

  • Should the DoD Buy Epic, or Cerner, or GE, or…? Department of Defense in the market for an EHR solution via @lmsergio

  • RT @hitconsultant: Should the DoD Buy Epic, or Cerner, or GE, or…? #healthit #hcit #EMR #EHR

  • Should the DoD Buy Epic, or Cerner, or GE…? by @margalitgurarie RT @hitconsultant (types of #EHR software)

  • RT @Brad_Justus: Should the DoD Buy Epic, or Cerner, or GE, or…? – #HealthIT #HITsm

  • observer12

    Great article! Although I like Cerner’s software, the inability to control the source code will steer the DoD in another direction. I bet they will go with Epic.

  • Thank you. I am not sure, but do you think Cerner would refuse to share the source code, if the DoD was willing to buy? It would be a spectacular opportunity for them….

  • Avernus

    Epic is probably the most extendable of the EMRs out there, especially when the department has the resources to hire it’s own programmers. It having at least 40% of the commerical market share at this point also helps for inter compatibility.

  • KM102

    As a healthcare worker, Cerner is the way to go! You will have better follow-up care as well as innovative thinking to not only plan the current state, but preparation into future state.

  • Daniel J. Dick

    Proprietary solutions and accepting vendor lock-in is both pound foolish and penny foolish. If VistA were seriously lacking, which I understand it is not, bringing it up to par with the commercial solutions would not likely require the billions of dollars expected to implement Cerner or Epic.

    I question whether political manipulation and corruption is playing a part in the DoD even considering spending billions of dollars on a commercial solution when VistA is the most widely used EHR and can be downloaded, where the DoD can hire people or pick and choose consulting firms qualified to handle maintenance, installation, customization, training and such.

    What justifies the BILLIONS? What justifies the vendor lock-in?

    I feel I have experienced some some of the commercial bullying of customers, their employees, and their management, and that I have seen many other people experience the same thing when commercial companies like this barge in with their political manipulation and bullying, threatening people’s jobs, back-stabbing anyone who might not favor their company over others, and such. I was fired for the first time in my life just short of turning 59 after I reported something that in my opinion smacked of fraud, conflict of interest, and defamation of character. And I believe it had much to do with pressure that was likely put upon my management by Epic. My reviews were excellent. I got along well with all my coworkers. My performance was said to be excellent. But in my opinion, I believe Epic lied through their teeth in some of their testing and certification practices, allowed no accountability for their scoring, maintained a conflict of interest offering a huge discount to customers who were fully trained and certified, and I believe they lied when they scored the exam either to keep those large discounts or else to use those discounts to keep management in fear giving the discount on grace as long as management continued to do what they wanted. But I believe they would do what was necessary to silence you if you brought attention to anything that appeared to be corrupt.

    So, why should the DoD opt for a company that may want you to spend billions of dollars for the privilege of being owned by that company? Why should the DoD spend billions to lose their freedom of choice?

    Why should the DoD spend billions of dollars of taxpayer money on imprisoning the DoD and taking away their choices when they could be spending that money on giving Veteran’s better health care?

    If you ask doctors, many much prefer using VistA. Many feel it is easier to use and allows them to spend more time on the patient rather than on trying to figure out how to enter everything.

    The only advantage I have heard mentioned about a commercial solution such as Epic is their billing. But how in the world would it cost BILLIONS to improve VistA far beyond where the commercial solutions are today? Why not let doctors enjoy their better experience working with VistA and then develop improvements to the billing side of VistA?

    Is someone trying to send business over to a family member or a friend for kick-backs? Why the billions in additional expenses? Is it because someone is afraid they will be fired due to some political wrangling of the DoD?

    Why the horrible, unnecessary expense?

    When I lost my job with Community Medical Centers, out of curiosity, I set up a virtual Linux installation on my laptop and installed GT.M and VistA onto it. Then I installed the client software under Windows and had it up and running quickly free of charge.

    I would not try to suggest that setting up a large system for managing dozens or hundreds of hospitals would be anywhere near that trivial. But it did leave me feeling curious about setting up VistA into a Docker image. I was busy completing my Android app for sale, but I have been keeping that thought in the back of my mind as a possibility. I do not believe it would be difficult to do. If it were set up with proper volume management, best practices, proper replication/shadowing/mirroring/clustering–whatever, ETL, etc., my guess is that the resulting system would not be nearly as complex as Epic or Cerner for instance either to install or maintain or deal with upgrades properly or disaster recovery.

    But I would really like to test out that theory. I am curious how it would work with, say, Nutanix or Pure SANs and various solutions based on Linux. Or Windows.

    With Epic, our Cache systems were on HP. Some prefered IBM, but it was nice to have a choice. Others used Linux. I am not sure if Solaris was available or not. I enjoyed using Solaris, True64 (back in the days of DEC), and Linux, but it seems there should be many possible alternatives, especially if you have a choice of several consulting companies or hardware companies to support it.

    It would seem possible to develop good ETL solutions based on the database engine of the hospital’s preference–freedom to use Oracle, for instance, or MS SqlServer, Sybase, or the free postfix–SQL engines of various vendors with good support that would work, say, with Crystal Reports. Perhaps it could integrate well with, say, PeopleSoft or various solutions from Oracle, SAP, etc. Of course, that’s getting back into proprietary solutions. But then you have choices. And if you just look at hospital billing solutions, there are tons of them available.

    So, the justification for spending BILLIONS to lose your freedom to vendor-lock-in just doesn’t seem to be real or reasonable.

    Just my opinion, but a very, very, very strong concern. We should be taking care of our veterans responsibly as we promised and not blowing our money on making billionaires richer as a reward for taking our freedom and choices away.