Future of FreeB

FreeB is designed to be a medical billing engine that has a simple web service interface. It is designed to be used by any Practice or Hospital Management System. So far it supports paper billing and EDI (HCFA and X12 professional)

The development of FreeB has stalled since I made the decision to join the United States Marine Corps. But discussion about what needed to be fixed has been ongoing. There are several stakeholders in the FreeB project. TK family practice, FreeMED and OpenEMR all have working implementations and are capable of using it for billing. While several other applications have expressed interest in implementing the code. The most lucrative use of the project has been the result of work Walt Pennington and David Uhlman with the OpenEMR project. There have been thousands of claims filed using their optimized version of FreeB.

Unfortunately it is not clear that I will be able to continue to work on FreeB for personal reasons. I may have to take a 9-5 type job that will not allow me to continue to be the project manager. Therefore it is my responsibility to choose a successive project manager.

Yesterday I spent several hours talking to David Uhlman about a new approach that he developed. As a result of this discussion I have decided to hand over the reigns of FreeB development to him and his new company, uversa (http://www.uversainc.com/) For a good few of you, that is really all you will care to know about this issue. FreeB development will continue, and its main goals, to be a separate biller useful to several projects will continue. Some of you will be curious as to why... so that rather lengthy technical monologue follows.

Technical Reasons:

First let me describe briefly what is wrong with FreeB.

1. FreeB is written in Perl
This means that the FreeB server has very dumb objects. FreeB should have a mini-billing-emr that it dynamically creates and then discards with every billing run. Perl has very rich data structures but the OOP functions are arcane and hard to access or read. Python would be an ideal replacement and PHP would also work if you could make it a little less stateless. (which is what David is planning)

2. FreeB uses way to many XML-RPC calls.
Because I had no higher level objects I decided to use the XML-RPC hierarchy as my way of simulating rich objects. XML-RPC is a great control language but a poor data transfer language. I should be using XML or something more compressed. This makes FreeB too slow for any real billing environment.

3. FreeB uses an clunky XML programming language. This was intended to make the formats in FreeB accessible, but instead it ended up being far to perlish to comprehensible. Nonetheless it is important to note that whatever the "next version" is will have to find some way to make formats more accessible to non-programmers and novices. Seemed like a good idea at the time...

There are other features that are missing from FreeB but these are the ways in which I consider FreeB broken as opposed to just needing more features.

Why is Remitt broken:
Remitt is a second generation billing engine written by Jeff Buchbinder

1. Remitt is also written in Perl.
Granted it is Jeff Buchbinders Perl rather than my perl, which is from what I have seen much cleaner code. But perl is still difficult to maintain and develop, making it a poor choice for this type of application.

2. Remitt has a complex format system.
Jeff is using some very interesting but rather complex methods to move between an XML page and some format. The problem with this is it violates one of the original design goals of FreeB; make format variations easy. The method is likely powerful, but that is less relevant that making it accessible. The key to formats is to develop a public repository of variations, so that making new variations is less common that just looking up the variation that you need. Remitt makes this too hard, especially when compared to what David has shown me (more on that later)

3. Patent Cloud/Licensing Issues
Portions of Remitt are patented and the patent is licensed under the Mozilla Public License. There have been numerous discussions of this issue on the various lists. Ultimately some members of the community feel uncomfortable with this move. I would rather let them speak for themselves.

http://www.freeb.org/pipermail/freeb/2004-October/000261.html
http://www.linuxmednews.com/linuxmednews/1098376300/index_html

So lets talk about what David has proposed and why they are such good ideas.
The first is to port FreeB to PHP. This is much easier when you consider how good PHP is at handling web services and full blown objects.
Then you use the smarty templating language for your formats and format variations. This concept is so simple and elegant that it makes the PHP approach far more effective and simple than anything else.
David has already done proof of concept to generate X12 files, and has generated files that have lines that look like this...


NM1*IL*1*{$patient->get_last_name()}*{$patient->get_first_name()}* {$patient->get_middle_name()}**{$patient->get_suffix_name()}**{$patient- >get_identifier()}~
N3*{$patient->get_street()}~
N4*{$patient->get_city()}*{$patient->get_state()}*{$patient->get_zip()}*
{$patient->get_country()}~

And loops that might look like this...

CLM*{$claim->get_identifier
()}*40***11::1*Y*A*Y*Y*C*AA:::NV*01****P****3~
{foreach from=$claim->dates item=dtp}

DTP*{$dtp->get_code()}*{$dtp->get_code()}*{$dtp->get_date_iso ()}~
{/foreach}


now for anyone unfamiliar with billing this might look just awful. But anyone who is familiar with the X12 format can see that it is really just a simple markup of the already awful X12 format. Essentially all you have to understand is a fairly straight forward mini-emr in php objects and the format that you are working with.
This, in my mind is a far superior way of making the formats accessible than either the really bad method in FreeB or the marginally bad way in Remitt. It has been my experience that the coding of the billing engine must be the work of a single or team of developers who are funded for a considerable period of time. That is how FreeB was made, that is how Remitt was made and I think FreeB v.2 will be no different. The opensource model of many parties evolving a code bases does not work because there are simply too few interested parties. However once a good billing engine exists, and if variations of formats in that language is simple enough then I believe the community will implement the engine and begin generating format variations.
Once there is a base of several different formats, the benefit of implementing the engine will increase. As the new implementation gets used more formats will be generated which will increase the attractiveness of implementing the engine.
David is in an excellent position to pull this off because,
1. He came up with the better solution and has working demo code.
2. He is the most prolific biller and format variation generator with the original FreeB code
3. Pennington Firm shares a code base with Uversa which means that Davids work will apply to two projects for the price of one.
4. Although FreeMED may be entrenched with the Remitt solution, it has the option of implementing FreeB .2 and would able to do so easily since it is in PHP.


As a result I will be handing over the reins of the freeb project to David. I will, as soon as possible, give him ftp access to the freeb.org site and admin access to the freeb mailing list. I am not sure what availability I will have upon starting a new job, but I will be funneling all freeb v.1 support questions through him. Also, I will be providing whatever design and implementation help I can to him with the next version.

Regards,
Fred Trotter

<  |  >