gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Introducing myself and questions on billing/accountin


From: Jim Busser
Subject: Re: [Gnumed-devel] Introducing myself and questions on billing/accounting
Date: Wed, 18 May 2011 17:37:54 -0700

On 2011-05-18, at 4:25 PM, Chris Travers wrote:

> On Wed, May 18, 2011 at 3:52 PM, Jim Busser <address@hidden> wrote:
> 
>> - where charges arise as part of (during) the delivery of care, it is 
>> reasonable that it be some record in the EMR that gives rise to the billing. 
>> This is important for a couple of reasons:
>>        - to provide / channel / supply data needed for the billing
>>        - where the above cannot be done automatically, to assist a lookup
>>        - as an audit check of missed billings
>>        - to be able to reference, if questioned, the actually-delivered 
>> service
> 
> In GNUmed terms this is an "encounter," even if the patient isn't
> actually encountered, is it not?


In the example where a new doctor would ask me to prepare a summary and/or to 
transfer records (along with a form, signed by a patient, authorizing me to do 
so) I would create an entry in the EMR to support the fact that I had had an 
"encounter with their clinical records" even though the patient was not there.

Similarly our public insurer is now paying specialists to provide telephone 
advice (even without themselves seeing the patient) to a family doctor asking 
for assistance. This is care-by-proxy but I would create a record for this 
patient in the EMR and link it to the billable that arises from giving the 
advice.

...

> There are a couple other important cases that crop up in the
> not-so-perfect real world.
> 
> The first is something like 'We just got these H1N1 vaccines in and
> trying to bill for them but the it's is not showing up in the list.'
> In this case, the best option IMO is to have an 'unknown good/service'
> record which can be annotated, and let accounting adjust it in the
> process of the entry.

Which is partly why I used the term "placeholder" … which translates to

--> Dear staff, I know that I am (we are)  am supposed to be able to bill 
*something* for the work that I just did , but I either do not know the code, 
or do not know the best one from among the options applicable to this 
situation, or I don't know which additional information is needed (or how to 
format it).

> You want to capture the data as quickly as
> possible and with as much data as possible.

Yes!

1) ensure that no capture is *missed*
2) ensure that incomplete captures are at least traceable / fixable

and, to the extent possible, get them close to correct the first time and/or 
(at minimum) provide a context note

> Hmmm as I think about this I am actually rethinking my structure here
> a bit....  Instead of the components in the order I was looking at
> them, the following would probably work better:
> 
> GNUmed -> import schema (probably on LedgerSMB db) -> accounting
> system -> billing gateway.
> 
> My reason for changing the proposal to this linear approach is to
> support the following overall workflow:
> 
> 1)  Doctor enters EMR info, including billing stuff
> 2)  Bills get input into accounting system
> 3)  Bills get reviewed by billing department and posted to the books
> as receivable.
> 4)  Bills get submitted (either to private pay individuals or to
> insurers whether public or private).

This is where the LedgerSMB might populate an EMR-agnostic billing broker.

> This human review is absolutely critical in every business I have ever
> looked at.  It reduces data entry errors, provides some level of
> sanity checks, and avoids a lot of problems.  Then the data can be
> pulled and sent to the billing gateway through a third party engine.

-- Jim





reply via email to

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