MirrorMed and OpenEMR merger. Proposal 2

synseer wrote on Tuesday, May 09, 2006:

Hi,
    As many of you may not know, Fred Trotter(me) and Uversa have had a split. At Uversa I felt that I had too many restraints placed on me regarding ClearHealth as an Open Source project. ClearHealth (CH) is fine software, but Uversa simply does not yet have the Open part of the "Open Source" equation. At Uversa, I felt that the community was viewed as a nessecary evil rather than an asset. Uversa does generate high quality code and this is something that we, as the FOSS community need to take advantage of.

    MirrorMed, my new project, is an attempt to make the new CH codebase more open and to create some community around the code. Here are some issues that MirrorMed addresses using the same codebase.

1. MirrorMed is a friendly fork. Until Uversa makes bad technical decisions they will remain in control of the general direction of the codebase. There is too much duplication of errort to do otherwise. 

2. MirrorMed will focus on stablizing the codebase. RC2 of CH is totally different product than RC3. Almost half a million dollars of development of new features were introduced. MirrorMed will have reasonable version numbering that is not based on marketing.

3. MirrorMed will focus on community, that means embracing community contributions. Already several major features have been developed by the MirrorMed community.

4. MirrorMed will focus on community, that means community decisions. MirrorMed will form a council of interested parties, and they will make decisions. The MirrorMed trademark will be used to give this council power. This will not be a dictatorship.

5. MirrorMed will focus on community, that means giving community members full subversion access.

As you can see the philosophy of the MirrorMed project is very different from CH, and more compatible (intentionally) with the openemr community.

I am proposing is that MirrorMed become the codebase for OpenEMR 3.x (or 4.x). I am proposing that we maintain support for the current codebase as a legacy system. As far as organization, I think we need to talk about who would take responsibility for what, but generally, there is no particular power that I would reserve to myself.

ClearHealth is a great starting codebase, and the next version will be at least a generation ahead of anything else. However, Uversa has not yet invested in community. MirrorMed is in a position to be that community. The MirrorMed codebase, with the OpenEMR community could survive if Uversa disappeared, or took development in a poor direction. However, currently, the OpenEMR codebase is holding the community back. This seems like the best of both worlds.

Comments welcome.

sunsetsystems wrote on Tuesday, May 09, 2006:

Fred, in the OpenEMR project I believe we have a mandate to build on the OpenEMR code base.  There’s nothing wrong with anyone chucking it all and going with something else, but then it wouldn’t be OpenEMR, would it?

In part this would mean discussing proposed changes to OpenEMR on their own individual merits.  So to suggest that “MirrorMed become the codebase for OpenEMR” is not in itself useful or interesting to happy users of OpenEMR – it doesn’t come from a point of view of “how can we add feature X” or “how can we improve feature Y”.

On the other hand, ideas for incorporating specific features/code from MirrorMed, ClearHealth or anything else into OpenEMR are fair game for discussion here.  The key, I think, is to make sure these changes are incremental and have thoughtfully considered approval and support from our users.

Why don’t you consider becoming a contributor to OpenEMR, discussing and winning approval for your improvements piecemeal and from a technical/clinical perspective?  The end result may very well be precisely what you desire.

Best regards,

– Rod
www.sunsetsystems.com

sankar1234 wrote on Tuesday, May 09, 2006:

Fred :
IN the past, you were critical of everything about openemr.  You have to try to join the forces and try to win over, instead of just bad mouthing openemr and my own projects.

Please let us know why OpenEMR is bad for Physicians.  How many physicians have you seen that mentioned that OpenEMR is bad? Are the physicians really considered OpenEMR and selected some other products.  Please do not worry about the codebase, architecture, design, style, file naming conventions, bugs, packages, and attitude of people.

From a CEO/PM point of view, consider all department of the product and shell it out convincingly, not say your product is not worth mentioning nor needs attention.  It doesn’t take a peer like you anywhere except some miniscule pleassure in trashing someone/projects. I learnt a lot from OpenEMR and particularly people here.  They hey have class and professionalism.  We can always acquire talent, but “class” can’t be taught.

Once you mentioned OpenEMR is old.  Okay, Right. Any software that is written last week is old with current technologies.  Even MirrorMed codebase will be like this sometime in future. but your solution for openemr project : drop it and join MM.

Join MirrorMed?  What is your market share?  Is your cash register ringing all hour long? You think OpenEMR is taking away or not marketshare significantly. If yes,  please publish the numbers for others to join you (if the numbers are impressive) instead of you sending proposals.

The reason I started my projects (in addition to OpenEMR) is to provide the best to clients, not necessarily to compete with any open source products.  My vision of OS EMR is completely different from MM, OpenEMR, CH, …I am not going to ask everyone to join me.  The situation will come when they all join and compete against the commercial products. That is the true success of OS projects. 

markleeds wrote on Tuesday, May 09, 2006:

I like the idea of associating forms with a patient chart as well as with an encounter.  That’s a good idea from MirrorMed we could use.

One way that we could move towards a common "code base" is to layout a really good database design that could be used by OpenEMR, MirrorMed and others.  Maybe we could agree on an open source program for doing database diagrams and put ideas and proposals in the wiki.

Once there is a good database, there are many ways to build nice interfaces to it.

Ruby on Rails is supposed to be excellent.  I just heard of a similar Perl project called Jifty for building web apps.

I am committed to the crufty old OpenEMR right now because it does exactly what I need right out of the box.

Fred: I have looked through some of your code.  I think that you are right to use advanced techniques like OOP and templates.  I think that you should write more documentation, because complex data structures need to have their interfaces well documented.  Much of the simple code in OpenEMR is self-documenting, because anyone can follow it and see what it does.  I would be much more open to using and contributing to your projects if your documentation was better.  Forgive me if I have overlooked documentation, but when I have looked for it on your website and in projects, I have not been able to find much.  I do appreciate all of the work that you have done.  Thank you very much for freeb.

synseer wrote on Thursday, May 11, 2006:

Rod,
     I agree that new work would need to be based on the work that has been done. But MirrorMed is based on OpenEMR, it is just signifigantly re-architected. There is a rapidly narrowing feature gap between MirrorMed and OpenEMR. During my review, I discovered many things that OpenEMR does that I did not expect. A feature by feature comparison is definately in order. As for contributing to OpenEMR, billing is my baby and I will help just about anyone port FreeB 2. Perhaps that would be a good start. However, in generaly I think my time would be better spent creating features in MirrorMed that OpenEMR already has.

Regards,
FT

synseer wrote on Thursday, May 11, 2006:

There are some things that I should point out here. I HAVE been very critical of the OpenEMR codebase. I still think there are a lot of problems with it. Still, there are really good things about the OpenEMR project and I have been careful to praise those things. Consider the the review on ehr.gplmedicine.org I give OpenEMR just as high marks as I did the other two projects. Please do not take my criticisms on the codebase as personal attacks.

As for my comments about your personal project, I understood that you intended to create yet another EHR project. A new project would further fracture a community that I am trying to unite. Later you indicated that your project was not intended to compete with OpenEMR, but was more of an add-on. At which point I recended my comments.

You can see how I might have been confused. Your initial emrupdate post (for those interested http://www.emrupdate.com/forums/thread/49493.aspx) Makes it seem that this is an OpenEMR competitor. Your new system does "Shared calendaring, HPI, Vitals, Examinations, ROS, PSFH,  Prescriptions, Medications, Immunizations, Encounters, ICD and CPT, document management for xrays, lap reports, physician referrals. " Further you wrote "I am looking for funds/grants to integrate the billing and other EMR related modules including faxes."

Now, as I read this, it still seems to me like you were trying to create yet another EHR project. I pointed out at emrupdate, and I repeat it here, that you are competing for funding against projects that are far more mature the SugarCRM-based system you were displaying.

MirrorMed is intentionally NOT a code fork from ClearHealth, in my initial proposal and in this proposal I am emphasizing working together rather than with competing codebases. I have been rather vocal and obstinate about this in the past, again this is not a personal attack, I was talking about the issue of a new project.

Regards,
FT

sunsetsystems wrote on Thursday, May 11, 2006:

Fred, if you have not already done so, be sure to check out the OpenEMR Screenshots section of my web site (below) for a pretty good rundown of OpenEMR features.  A couple of recent things like user-addressable patient notes are missing, but most if it is reasonably current.

I would be pleased to think that any new features going into OpenEMR will be useful enough and of sufficient quality to make their way into other FOSS projects such as MirrorMed.  Ultimately we’re all in the same boat and should be working together, regardless of project names.

– Rod
www.sunsetsystems.com

synseer wrote on Thursday, May 11, 2006:

Lots of good ideas in this post.

Ruby on Rails and other code generating systems work very well for rapid development projects. However, once you start to get into the complex db structures that are needed for an EHR they need so much modification that it is better just to have clean custom designed code.

Your criticism for documentation is not so easily set aside. I know this needs improvement. Because of the license, I cannot simply copy the ClearHealth documentation (although there is no reason that you can not go read that, I wrote a large portion of it). The documentation that is generated from the code is OK, but it needs to be far more expansive and specific. This is an area that needs work.

andres_paglayan wrote on Thursday, May 11, 2006:

Since I have been withdrown (study, vacation, family, work) for a while I rather abstain commenting,
…but,
about the comment on Rails, that’s not true since rails 1.1, the database relationship “many to whatever” which has been a problem for complex designs, is now in place.
I don’t see any limitation.
please correct me if I’m wrong,

synseer wrote on Thursday, May 11, 2006:

Rod,
    Its been too long since I visted your site. It looks great! The screen shots are going to be very helpful for both this current discussion and for my review!!

Here is my initial take. Because OpenEMR uses SQL-Ledger, there are some accounting things that look very strong. I was wondering however, how do you handle rebilling? I would think that would need to be a function of the AR system talking to the billing engine (btw sorry in advance if something I did with the original FreeB makes this hard) One of the things that I do not like is that it uses manual entry as the primary form of entering subscriber information. That will lead to duplicate information for the same person, which is not good.

I will have to look at your coding and perscription systems more carefully, but it looks like MirrorMed has a faster coding system, but you have a perscription engine. btw where are you getting your drug database? I have been interested in the VistA drug db, because I believe that it might have an interaction system that we might both be able to borrow.

I was also interested in your wishlist. The template system is just about already working in MirrorMed. Other things are in various stages…

I will look into this further and write more later…

Regards,
Fred Trotter

sunsetsystems wrote on Thursday, May 11, 2006:

Rebilling is handled via the “Needs secondary billing” checkbox in the EOB Invoice window.  If you go to http://www.sunsetsystems.com/node/17 and scroll down to about the middle of the page you’ll see some discussion of that.

The drug database comes from lookups on-the-fly to www.rxlist.com.  That code was there even before I got involved with OpenEMR.  Unfortunately this does not provide any solution for drug interaction checking.

Coding in OpenEMR is pretty fast and convenient if you use the Fee Sheet encounter form.  You’ll see illustrations of that (as well as prescriptions) at http://www.sunsetsystems.com/node/13.  Note that the Fee Sheet can be customized to provide fast access to your most frequently used codes.

I would be interested to learn more about what you are doing with templates.

Cheers,

– Rod
www.sunsetsystems.com

okhra wrote on Thursday, May 11, 2006:

<Ruby on Rails and other code generating systems work very well for rapid development projects. However, once you start to get into the complex db structures that are needed for an EHR they need so much modification that it is better just to have clean custom designed code.>

Are you sure you know what you are talking about Rails. Is it a put down in one swipe, or have you tried it ? Try out the recent RoR (1.1 ?)

braman at world dot std dot com