Answer to, “Will OpenEMR die?” And how we worked with the OSS project.

Rumors about the death of OpenEMR are greatly exaggerated

Recently I found an article online that posed the question, "Will OpenEMR die?" The author was trying to explain why he chose to cut his own path into developing a proprietary EMR. He says that OpenEMR lacks critical pieces and he found the community had lost passion. There are already enough rebuttals about this article on the blog page itself, so I bring this article up not to rebut it but to show you how we can navigate this common thought process. I am going to take the apprehensions mentioned by the author at face value, for I had the same ones at first.

Working with an online community is difficult. People are not very polite. For the most part, they are not intentionally rude. But the new style of brevity in e-conversations coupled with the anonymity of the correspondents lead most people to be cavalier in their expressions.

There is also an intrinsic mistrust of profit motives in many open source communities. Even within the OpenEMR community I have felt that the term "Vendor" has almost become an expletive. Add to that the severe positions techies tend to take when it comes to specific approaches or tools, and you have a very sensitive crowd.

Like the author of the article, I found a lot of missing pieces in OpenEMR, but unlike him I chose to stay and work with the project. The simple reason is this: unlike the author, I did not find that the community lacked passion. In fact there was too much of it, if that is at all possible. I also found that like every other community or organization or group or country or economy, it is the few who drive things forward and the rest are silent. And OpenEMR has that "few."

When I first came in to the project I was welcomed with open arms: we still extend the same courtesy and love to anyone who offers to help the project.

I also understood the importance of market feedback. The OpenEMR forum had its fingers on the pulse of the physician community. I would never get that kind of insight with any amount of paid market research. The community has a lot of doctors in the active "few" and the collective wisdom of these people was like having an expert panel of advisors—unpaid!

So we stayed.

I have disagreed with many in the community about the strict interpretation of the open source concept. There has to be a revenue model for open source communities lest they die a death of attrition and exhaustion. And our path will be in that direction: an open source/proprietary hybrid.

True, the community does not want vendors to take advantage of the product. However it is also true that these so-called vendors have contributed most of the code or have directed sponsors to develop code and contribute them back to the community. In any case, vendors have played a critical role in the development and sustenance of the community.

It is also true that some individuals in the community have spent an average of 4-5 hours every day over the better part of the past decade . So we do have a combination of volunteers and vendors working together: you see the “Hybrid” model in the development of the project too.

With the boom in mobile platforms we realized that we needed to improve our technology to move forward. This is where we found our next challenge. OpenEMR had become a hotchpotch of code written by a lot of different people over a period of 16 years. Much of the code could not be tracked to an owner, which left a hole in the licensing under GPL. I was told that this was holding back adoption by bigger institutions.

It became apparent to us at ZH Healthcare that we needed to rewrite the code to embrace the platforms and devices of the new century, refactor the DB, and also make the interface independent of the code without sacrificing the great features OpenEMR had.

Even though hundreds of thousands of people have downloaded and used OpenEMR, not many have stepped forward to fund such a massive project. True, they would contribute to smaller projects like getting MU certification or adding an interface, but no one has funded the rewrite of the code.

Even if someone did, philosophical differences about the platform rendered a decision impossible. People threw around Zend, Sencha, Ruby on Rails, or whatever they like at the moment. Others just did not want to change the status quo because it required more learning and investment.

So how did we at ZH Healthcare navigate this? In two ways.

We wanted to introduce the community to the benefits of the new framework. So we created a "Module Installer" in a framework we chose: Zend. We allowed that module installer to be flexible enough to allow installation of modules developed in the old PHP or the new framework. And we believe we can slowly ease the community into the new platform by introducing modules developed in a MVC architecture. The first module in this category is the ZH Care Coordination Module, which is critical to MU2 Certification.

Secondly, we rewrote the entire code base in the new framework, Zend: And we call it BlueEHS. It took us over 160,000 hours , and counting, to rewrite and test the code. That is an investment between $5and $8 million. No individual could have done that alone.

We released BlueEHS as free SaaS platform that showcases the best of open source and proprietary code. When we feel the community is ready for this version, we will open source it. But we will not force it on the community, nor are we going to fork the project. We will stay with OpenEMR and support it.

Why did we go to such a length to work with the community? Out of love and respect—love for open source and respect for the participants. The difference between Dr Chrono's choice and mine, I would like to believe, is the choice between an autocratic and a democratic system. Yes, democracy is messy, but it works and it brings people along.