[Care2x-general] sobre freeb

[Walter Nunez]

Fundamentally the current FreeB suffers from several design decisions
which in my opinion just didn't pan out, was a great leap none the less
(still great work by fred, no question).

1) Compiling the psuedo-xml into perl, the compiler has tended to be
more problematic than the actuall billing work.

2) Fractured XML-RPC api, way too many different functions and due to
the "dumbness" of the compiler a tendancy to call the same functions
over and over again. This certainly contributes to the mind-numbng
slowless at least in OpenEMR's case. It is interesting to realize that
freeb and anything that completely implements it's api is at the leading
edge of what web services can do, by last count there are 100+ api
function calls as well as a typical round trip taking as many as 500. I
can't think of another application which uses half that many, by
contrast the accounting integration in OpenEMR uses 2, possibly 3 calls.

4) Spaghetti code and more often than not incorrect code documentation,
take a look at the actual formatbin files as well as my personal
favorite Loop.pm .

5) FreeB has/had a flawed packing algorithm so that individual codes are
not spread across HCFA's as efficiently as possible which appears to be
an issue with some payers, mainly clearing houses.

So anyway with that out of the way, the lessons I learned are:

X124010A is an un-standard, it will not be possible to have a universal
format or translator as each payer requires different and frequently
mutally exclusive things. Ideally the different formats will subclass a
master format, worst case every payer has a totally different format and
to makes changes across all you have to find/replace.

A claim needs to be processed in less that 1 second including the web
services call. Many other applications are able to meet this requirement
doing things of similar complexity.

Callbacks are a bad idea, I actually implemented freeb and openemr and I
would love to have that time back and I blame callbacks for the most
part. When making a call to FreeB the calling application has to know
what payer it is sending a claim to and must supply all of the suitable
data(this sounds more problematic than it is in practice), both XML-RPC
and SOAP support complex nested data structures that makes this
reasonable. A minimum set being required is a good idea and extended
information should be added using flexible "data soup" type structures
rather than something more rigid or formal.

The result of the call must be returned as part of the services response
even if its a PDF and needs to be base64ed. This is a step for
scalability, large payers are interested in freeb but if it uses local
file system that makes horizontal scalability difficult.

Possible solutions:

PHP using a templating engine like smarty where PHP has a few simple WS
function calls like startClaimTransation(specify payer format based on
lookup table of supported options, loadPatient, LoadResponsiblePerson,
loadInsurer, loadCodeData, endClaimTransaction. These build an in
session structure and when endClaimTransaction it errors and gives you a
chance to recall any of the loadFunctions, or rollback or if successful
returns the completed claim data in the format you asked for. PHP takes
the in session structure and maps it into templates structures that a
different smarty templates turn in to x12 or HCFA formatted files.
Smarty supports includes so common things like header etc can have
defaults or you have the option of reimplementing should the particular
payer require it. I have been using smarty to generate PHP code lately
and this concept works very well.

Python is also a good choice because almost all platforms have it
natively and it also supports being built into a standalone executable.
It could potentially use a very similar architecture to above.

I should also say that while I have heard several people groan at the
use of PHP for this it is important to recognize the most of the people
who potentially/probably will could do the work for this are involved
with PHP based EMR's so that should be taken in to consideration.

While in an ideal world it might be neat to build an XML structure of
the data and XSLT it into that payer formats having experimented with
this recently it is difficult because XSLT is somewhat limited in areas
where having functionality will make building this a lot faster. In a
nutshell this would take a really long time, XML just doesn't like being
dumbed down to HCFA and X12. There are a few schemas for X12 out there
but I am not aware of a professional one yet, just institutional, so
that would have to be created as well which is no small undertaking.

The upside is that the knowledge about particular payers including
Zirmed, Proxymed, Medi-cal, CMS, BCBS is already there or close to
there. This is the hard part when you really get down to it, in my
estimation there are about 600 different payer formats but the use of
clearing houses mitigates this quite a bit for most.

Probably a bit long winded, sorry for that.

-- 
Sincerely,
David Uhlman

-- 
Walter Alfonso Núnez Rivera
Médico - Programador
Pascual de Andagoya 140 Lima 32 Perú