[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Billing/LedgerSMB gap analysis

From: Chris Travers
Subject: Re: [Gnumed-devel] Billing/LedgerSMB gap analysis
Date: Thu, 16 Jun 2011 00:57:28 -0700

On Thu, Jun 16, 2011 at 12:07 AM, Karsten Hilbert
<address@hidden> wrote:
> On Wed, Jun 15, 2011 at 01:26:45PM -0700, Jim Busser wrote:
>> > 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.
>> A fee of $35.00, which could work multiple ways:
>> 1) the bill for $35.00 is sent to the insurer InsurCo who refuses to pay
>>       --> the bill-to gets changed from InsurCo to patient-pay
>>       ? does LSMB allow it to be later seen that InsurCo was approached but 
>> refused?
>> 2) the bill for $35.00 is sent to the insurer InsurCo who will pay only $25
>>       --> does this remain a single bill, whose balance is paid by someone 
>> else?
>>       or is $10.00 "split off" to make a new bill?
>> 3) it is known in advance that insurCo will pay only $25.00
>>       --> $10.00 "split off" to make a new bill payable by patient
>>       --> the remaining $25.00 "is right away billed to InsurCo
>> Does LSMB already handle the above?
> Well, as far as I understood Chris' gap analysis, no, it
> does not. He also said that the current LSMB structure does
> not easily support this model.

> However, we are trying to define a use case even easier than that:
>        The bill for $35.00 goes to the patient and if they
>        don't pay up within, say, 4 weeks, we send out the Gang
>        of Five.
> That use case will apply in large swaths of the world.

Ok then.  So here, all we need are connectors.  Since both sides are
assumed to be information-complete, meaning sufficient supporting
information to generate and print the invoice exist in both systems,
at least within their domains (i.e. service codes in both systems, but
patient notes only in GNUmed, and pricing info only needs to be in
LSMB).  All we need to do then is pull the data into sales orders in
LSMB, which are then converted into invoices on review.  My suggestion
at this point is to spec out the connectors as using db relations,
allowing the implementation of those relations to vary depending on
how the databases are related to eachother (diff. schemas, diff db's,
diff. servers all are different cases).

I am starting to clear out my queue of LSMB work at present.  Next
week I might be able to take a first crack at this.

Best Wishes,
Chris Travers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]