For several months now it has not been clear what the future of the FreeB project would be. Yesterday I spent several hours talking to David Uhlman about a new
approach to medical billing. As a result of this discussion I have
decided to hand over the reigns of FreeB development to him and his new
company, Uversa
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.
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
https://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