Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, March 11, 2011

Open Source Software as a way forward for HealthIT

I'm a big fan of open source.  A lot of the software I use is open source, and much of the software that isn't relies on open source.  I've given a wee bit to the open source community, but not a whole lot.  I think my largest contribution has been publicizing it on this blog.

But I've been reading a number of posts and tweets lately that tout "Open Source" as the way forward for Healthcare IT.  Some of the recently posted links appear below.
In the interest of full disclosure, I work for a software vendor (see my profile).  You might think my views are skewed against open source.  I don't think they are, but I'll let you make your own decisions.

There's nothing inherently better or worse about the quality, features or capabilities of Open Source Software than of commercial offerings. In fact, for some things, the Open Source implementation is THE industry leader for the task.  I challenge you to find Java based applications that doesn't support Xerces for XML parsing or Xalan for XSLT transforms.  It's just hard enough of a task to show how these open source solutions dominate that space.

The two major benefits of open source seem to be cost, and the opportunity to modify the product to suit your own needs.  For the small physician office or hospital, the cost of the software seems especially attractive. For larger organizations with a skilled programming staff, the opportunity to modify the product may be even more attractive.  One of my own favorite benefits of open source is how close it brings product developers to their customers, because I think it has incredible value.  That may be the one reason why open source is viewed as a way forward.

The true costs of software ownership only start with the licensing or purchase price of the software.  The Total cost of ownership can be much higher, and many open source offerings don't include the same services that commercial offerings do.  Smaller providers need to be aware of the gaps, because organizations using open source software often have to make up for what is missing from open source.  This can include documentation, education and training, service, support, maintenance, and in the era of Meaningful Use: Certification.   Larger organizations will often have their own staff who can often fill those gaps, but that just shifts the cost from one place to another (it may in fact be cheaper, but can still require a substantial investment).

Because open source efforts are often volunteer supported, they don't always have funding to support things like Certification.  Getting an EHR ONC-ATCB certified is no small task.  It requires weeks of preparation, and person days committed to testing, and can include fees1  from around $20,000 to as high as $33,000 dollars to certify a complete ambulatory EHR.  Few Open source efforts have the funds to cover that kind of cost.  That responsibility would become a cost needing to be borne by the implementers of the product.  Smart implementers would be we well advised to partner up with other users in their community to share the cost of product certification in this case (see ONC FAQ 4).

Many Open Source efforts are supported by large software and/or hardware vendors.  For example, Intel has a fairly large commitment to open source supporting their processors.  If you take a look at the membership of Open Health Tools, you will see a number of large IT vendors, and several EHR vendors who participate.  Many of these have contributed substantial amounts of intellectual property, and development resources to these efforts.  Their staff are often very active in, or even leading open source efforts.  These vendors often provide services to fill in the gaps in conjunction with their involvement in the development of the software.  Other vendors or consultants may also offer services to backfill without necessarily being directly involved in the open source development efforts.  Some  vendors have created their own open source product offerings:  The code is completely free and downloadable, and you can contribute to it, but the open source effort is managed by the vendor (and in some but not all cases, the IP is retained by the vendor). These vendors often generate revenue by providing services, support, education, consulting, et cetera, around the implementation and use of the product.

The Federal Government has event supported a couple of Open Source efforts.  One of these is the CONNECT Open Source project which supports connection to the Nationwide Health Information Network.  Another appears to be the popHealth project designed to support Meaningful Use quality reporting.  In that particular case it appears (see Project Milestones on the project home page) that the project will also be ONC-ATCB certified for that purpose.  Federally supported projects have their own set of challenges.

Federal projects live as long as there is funding support from the agency, and even when the agency (or agencies) would like to renew the funding, it's not always the case that it does.  When it does, there is no guarantee that the supporting contractors will remain the same, or that they will do things the same way.  The contract for the CONNECT project was awarded to CGI/Stanley, but was protested by the original contract holder Harris.  The lights are currently on for CONNECT, but little work is happening until the dispute is resolved. This is very frustrating on two counts:  Some Federal agencies were relying on this activity to meet some of their objectives.  There are others who have invested time and effort into the activity, and in other intellectual property in the hopes of providing services that they won't be able to capitalize on as much as they had hoped to until the protest is addressed.  I don't know of any studies on risks for Federally supported open source activities.  Given my own experience with Federally funded initiatives, I would expect that there's about a two-year risk cycle to consider at the very least.

So, my advice:  Be aware of your needs.  Go into your software implementation project with your eyes open, and understand the total cost of the software you will be using. Do look at open source efforts (here is a list to consider).  If the open source efforts meet your needs, then by all means, consider them.  Don't assume that because the cost of the software license is 0, that it will be cheaper in the long run.  Do the analysis, and be aware of potential risks.  Take the same effort you would vetting an open source project as you would a software vendor.  If, in the end, you decide that open source is the way to go, then it will be the way forward for you.

  -- Keith

1 Not all ONC-ATCBs publish their fee structures for certification. These figures are from publicly available information.

1 comment:

  1. Nice Post ! I'm an open source fan too. Do you know iHRis, a health Open Source Information System ?