Hello,
My name is Fred Trotter and I am the project manager of ClearHealth and FreeB. I am formally proposing a consolidation between the ClearHealth, OpenEMR and FreeMED projects.

So far I have discussed this issue with the FreeMED BOD, and several OpenEMR community members. At this point, it is time to put the proposal to the community.
Read on for the full proposal.
I am formally proposing a consolidation between the ClearHealth, OpenEMR and FreeMED projects. (To give extra background. FreeMED, OpenEMR and ClearHealth are the most popular PHP/Mysql/Linux Medical Practice Management/EMR applications)

Why should there be a consolidation?
To avoid duplication of effort. Because we are all developing very similar EMR systems using the same fundamental technologies. Each of the three projects is separately generating incompatible code to meet exactly the same requirements. If the three projects combined their efforts we would have a better EMR and Medical Practice Management System in far less time than we might working apart.

What does �consolidation� mean in this context?
That is something that the community needs to come to an agreement on. I think this could mean anything from the complete refactoring of codebases, to friendly and structured exchange of code. I think the optimal solution would be a period of collaboration and communication, followed by a consolidation of code bases and the development of legacy support projects (or migration scripts) for the old code bases. But that is just my opinion, what does the community think?

We, as a collective community, have been spinning our wheels for a long time. Each community has strengths and weaknesses. Why can’t we combine strengths to eliminate weaknesses? First we need a candid assessment of what each project has and does not have. I do NOT mean this as hostile criticism, what I am trying to do is create an honest picture of what the real situation is, so that we as a community can figure out what to do next. I expect these criticisms to provoke strong feelings, and, hopefully, equally candid responses. I hope that the replies to this post will help us determine two things, where we are now, and given that status, where we should go. Feel free to disagree with my assessments, but to avoid a flame-war please try to back up your position with verifiable facts. At the beginning of your comments please introduce yourself, since you may not be known as well outside your community. I will cross posts relevant comments where possible. I believe the appropriate place for a central discussion is the new openhealth list, so that is where I will be talking most. I will leave out anything that I see as a positive or negative for all of the projects. This is intended to provoke discussion.

Here goes.

ClearHealth
ClearHealth is a young project funded by Uversa, Inc. Uversa has hired several of the key players to work on ClearHealth. I want to specifically mention three. The first is David Uhlman, who is well known in the OpenEMR community. The second is myself, Fred Trotter. There is a LinuxMedNews interview with me that explains who I am and what I think about things.

The third is Josh Eichorn, Josh and David are especially important because they are the primary architects of ClearHealth. Josh is well-known as the maintainer and author of phpDocumenter which is a standard within the PHP community. A look at Josh’s website to see more about his programming background.

As a result of the fact that Josh and David are first class architects, and David and I have a deep background in the current architecture of FreeMED and OpenEMR, I feel ClearHealth has the cleanest layout and most progressive core features of any of the three projects.

Specifically, we have an advanced Calendaring system. We also have FreeB2 which has some features that cannot be found in any other Medical Billing System, like claim revision control. FreeB2 is the centerpiece of the ClearHealth collaborative strategy, and there is already commitment from some non-PHP projects. Eventually this collaboration will generate a wealth of billing formats, which is the only reason to use a separate billing engine.

Our architecture also has what we are referring to as EMR Extensions and Dynamic Reports. EMR Extensions are a method for extending the EMR without programing. Dynamic Reports allows you to create searchable and editable reports. So that you can both query and modify the data in the same system, again without programming.

FreeMED
FreeMED has a lot of features. It handles faxes and has a system for handling images. It is based on lots of trail and error over a long history. It has a small but loyal community. It has some valuable international relationships. FreeMED has a nonprofit corporation that operates in FreeMEDs interest. It is also the oldest project, so it has had a long evolution.

While the system is modular, it is not OOP. The project manager, Jeff Buchbinder, is the only person who is familiar enough with the code to make major changes. Over time several people have tried to contribute to FreeMED, and been frustrated. As a result, FreeMED has been forked several times. FreeMED does have a second generation billing engine (REMITT) but adoption by other projects has stalled because of a patent cloud.

OpenEMR
A large and vibrant community. There are several companies that provide professional support. The code base is slightly more modern than FreeMED, and as a result changes are more possible and the culture of the project seems to encourage this. As a result the project is moving forward.

The project seems headless. There are several versions of the code in parallel. While there is a lot of activity, there does not seem to be to much publicly available documentation. There is no discernible project manager, or definite direction. OpenEMR is also supporting the original perl based FreeB. Which I am no longer maintaining. This makes the system very difficult to install and maintain, because it is not possible to take advantage of the improvements of Jeff Bucbinders REMITT or FreeB2. To be a viable project OpenEMR needs a supported billing system. The choice is either to merge with ClearHealth, integrate with FreeB2 , sort out REMITTs patent issues, or start a billing system from scratch. Given that most of the OpenEMR-only features could be implemented in ClearHealth without programing by EMR Extensions, porting FreeB2 seems more and more wasteful.

There are also issues with the main codebase. The PHP coding practices which are based in PHP 3. This includes the evil register globals, which makes OpenEMR almost impossible to secure. The amount of code rewrite that it will take to make the codebase modern and secure is considerable. Given that these things are already working in ClearHealth, is this worth working on?

Although I loath to put forward any specific plan, I will ask a pointed question. Why don’t we move toward using the clean architecture of ClearHealth, combined with the vibrant community of OpenEMR, and refactored feature set of FreeMED? The gap between OpenEMR and ClearHealth could be addressed using EMR Extensions. Some of the major features of FreeMED would need porting, but with an open invitation to Jeff Buchbinder to take a role as a developer on the combined project, those things could happen very quickly.

I am quite aware of that there are investments in current brands, companies and project mechanisms. I am not proposing any organizational merger, the various organizations should continue addressing their own priorities.

Many opportunities are being missed developing in parallel. Lets work together.

Regards,
Fred Trotter