Halaman

    Social Items

/ Without Label / Should the DoD Buy Epic, or Cerner, or GE, or…?
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.

Correction 7/14/2013: The original text mistakenly and regrettably stated that WorldVistA is not in active development based on this WorldVistA page. According to the WorldVistA home page, the EHR is very much active and Meaningful Use certified. My sincere apologies to the WorldVistA folks.

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

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.

Correction 7/14/2013: The original text mistakenly and regrettably stated that WorldVistA is not in active development based on this WorldVistA page. According to the WorldVistA home page, the EHR is very much active and Meaningful Use certified. My sincere apologies to the WorldVistA folks.

No comments

Subscribe to: Post Comments (Atom)