Stability of Propietary EMR Vendors vs. Open Source EMR

In the comments of one of my open source (free) EMR posts, we started an interesting discussion about the way that you evaluate a proprietary vendor and how the same methods of evaluation aren’t always possible once you start talking about an open source EMR. To keep things simple, I’ll just focus on one part of the evaluation of an EMR vendor: Stability.

I’m not talking about whether the EMR vendor’s software product is stable. I’m talking about the stability of the company behind the EMR vendor. There are a lot of aspects to consider, but probably the most important is how successful the company is doing financially. Are they making new sells? Is the EMR vendor expanding the business or is their business contracting? Are their current customers renewing or fleeing to other software products? At the end of the day, you’re basically making a judgement on the financial viability of the company. No one wants to deal with the challenge of an EMR vendor going bankrupt, being sold, or going out of business (see my previous post about when a SaaS EMR goes out of business). So, this is a really important issue to consider. Your EMR vendor becomes your partner and you want a reliable one.

The problem is that the same analysis can’t be done on an open source EMR. There is no company behind an open source EMR (usually) and so you can’t look at the company to make a prediction on whether the open source EMR software will be around a couple years from now. Instead you have to look to other indicators.

The most important point to consider with an open source EMR is the health of the community surrounding the open source EMR. If the community is strong, then you’ll see some amazing things happen. If the community is weak, then the open source EMR will still be around in a few years, but no improvements to the software will be made. The way technology progresses means that your software must improve or it will be outdated in a couple years time.

What makes a strong open source community? It can come in a variety of ways. Here’s just a few of them:
-Number of software releases that are made
-Method for delivering software releases
-Number of people with commit privileges on the project
-Number of people contributing code to the project
-Commercial entities backing the project
-Online activity and discussion around the project
-Software downloads over time

I’m sure there’s a lot more. I hope that people like open source EMR fanatic, Fred Trotter, will add to my short list.

It’s just as important to evaluate the health of the open source EMR community as it is for you to evaluate the financial stability of a commercial EMR vendor.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

11 Comments

  • John,

    Good analysis.

    In the past, buyers wanting “stability” have been forced to look at the stability of the IT vendor. The unfortunate tradeoff has been being locked in to a proprietary platform.

    In the future, buyers wanting stability should look more to the community and ecosystem supporting an IT platform — not just an individual vendor.

    If ONC is successful in creating interoperability and modularity in EHRs, there should be far less opportunity for lock in by vendors.

  • While I think what is written is true about open source vendors, proprietary vendors do not guarantee stability either. Plenty of public and private companies go bankrupt and leave customers hanging.
    To what extent do open-source vendors rely on the community for contributions?
    I think Redhat and Apache are examples of successful open-source products that have gone mainstream and are now maintained by their respective companies and but not totally reliant on community support.

  • Jonathan,
    I think that’s a major part of assessing the stability of the open source community around a project. Apache and Linux are strong communities because a number (now an incredibly large number) of strong companies rely on it for their company’s success.

  • John-

    Great topic and good post. One of the interesting things about open source “products” (EMR or otherwise) is the transparency it provides to organizations evaluating the software. Proprietary vendors cannot match the depth to which someone can investigate an open source ecosystem.

    The criteria you layout for evaluating the project hits the major areas — I’d add that understanding the quality assurance and governance processes would be top on my list. I would also suggest that a given distribution should be able to provide a number and/or references to the system running in production environments. Further how closely do those references match the setting of the organization evaluating the software?

    Thanks for posting on this topic, Ben

  • When it comes to being buyers, hospitals and doctors are conservative and risk averse — typically not innovative, early-adopters.

    In the past, this has meant choosing stable “vendors”.

    The key to change mindset — which is not easy. While it’s not likely that hospital/doctor need for “stability” will go away, it might be possible to redirect that need toward the ecosytem/community rather than an individual vendor.

    Companies in network markets (which healthcare is just in early stage of development) need to think very differently about stability, competition and openness. For example, see this blog post on openness/transparency by Google SVP Jonathan Rosenberg:

    http://googleblog.blogspot.com/2009/12/meaning-of-open.html

  • Vince,
    I’d read that Google post on openness before. It’s just interesting the dichotomy that Google is open in many regards, but still keeps certain things proprietary (their ad system). There are advantages and disadvantages to both. It’s more about what a company is willing to embrace.

  • John,

    Many HIT vendors choose to commercialize open source systems. Depending on their particular implementation and customization of the open source code and dbs, the end-user is likely in the same boat if their open source vendor fails (for any given reason).

    Given the new federal mandates, is the open source community willing and able to keep up?

    Now that many HIT vendors have congregated around Microsoft tools, platforms, patterns/practices, and SQL dbs; not very much is really that “proprietary” any more.

    FULL DISCLOSURE
    Silverlight 4 PM+EMR on the runway

  • Just a few thoughts ..

    What is the scheduled release pattern? every 6, 12, 18 or longer months.. you want the cycle to be long enough to allow for new development, bug fixing and regression testing.

    If the project is using agile methods, then a shorter period isn’t necessarily a killer, but not using agile is.

    Personal opinion, I think anything over a years duration is probably to long for stable project.

    Is there a stated policy for emergency e-fixes?

    Is the a formal tracking system.. bugzilla, Trak.. something that lets registered users of the software submit bug reports and feature requests. Any tracking system will do, it just needs to be a tracking system and not a discussion forum or email list

    What language is the project written in? C/C++, Java, javascript are all pretty common, but Erlang, assembler, Lisp, etc are not. Common language means more people able to jump in and keep the project running.

    A good open source front end is not necessarily matched to an open source backend.. it could just as easily be talking to Oracle, Informix, DB2 or Rational instead of MySQl, Postgres or a home grown db.

    Personal opinion, I would be leary of any EMR system running on a home grown db, unless I had the opportunity to do my own due diligence on it.

    Now as far as open source projects failing .. it happens all the time and usually (not always), it is because some other project has a better implementation of the idea…think of it in proprietary terms as a hostile take over 🙂

  • Without a doubt the strength of the project is a consideration. It mirrors the typical requirement you see in RFI’s to provide vendor financial information. But I think the argument is really the same. A traditional vendor who lacks a quality product and support of users will undoubtedly sunset the product or go out of business. An open source project that lacks support of a community and fails to provide what is needed in the market will similarly fall away. The metrics for evaluating the open source vendor have been outlined in the other posts and I think it becomes part of any RFI that is looking to add an open source solution to the list.

Click here to post a comment
   

Categories