[Gnumed-devel] Billing/LedgerSMB gap analysis

[Chris Travers]

There are a few specific challenges regarding medical billing which
break down into some larger more general problems which LedgerSMB is
not prepared to gracefully handle.  There are ways to accomplish this
provided that specific functionality.  The major issue here is third
party billing.  You have a patient who accrues billable amounts, and
some of that may need to be collected after insurance pays their
portion.  In other words, this billing split is a bit of a challenge.
What you need to be able to do is to be able to track what insurance
paid vs co-pay, or if it is pushed back, what the total owed is.

i don't htink this is reasonably doable in 1.2 for a number of
reasons.  At least with 1.3, we have better payment handling and
separation of duties to ensure integration isn't a mess.

Minimally this could be handled by turning each insurance company into
a pricegroup or business type.  These are ways of classifying
customers and could be used for a payment processing routine to select
customers per insurer.  A payment selection could be made and an
arbitrary file format generated from it which can then be sent to the
insurer.  This can then be processed as a payment later when money
comes in.  This would have to be tracked using prefixes on source
numbers which is awkard but doable in the short run.  It;s not really
what I would recommend in the long run.

What I think we'd need to do this with a minimum of grace would be an
add-on for handling third party payments.  In this model, you'd have
an additional bill-to contact that would get the first invoice, and a
second bill-to contact that would get the invoice if declined,
refused, etc.  For private pay, there would be no additional bill to
contact.

In this model you;d have to also have to have the billing gateways,
and probably something that would allow you to import payments as
well.....  Then these could be reviewed and approved as a batch.
These would probably be the task of the billing gateway layer, but the
payment model would have to be to be extended slightly to make this
work.

The second issue involves local regulatory and billing needs.    I am
not sure at this point we have any idea what this requires on more
than one or two locations.    In terms of additional price factors,
that would require an add-on as well.  However I think the best
approach here would be to look at this as a locale by locale basis
rather than insisting that this be everything to everybody.

The third party payment module is something we have gotten other
requests from logistics businesses, etc.  So that at least is a
general problem.

Does it sound like I am missing anything fundamental in terms of the
accounting system (narrowly-defined)?

Best Wishes,
Chris Travers