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

[Sebastian Hilbert]

Am Freitag, 20. Mai 2011, 06:41:01 schrieb Jim Busser:
> On 2011-05-19, at 5:05 PM, Jim Busser wrote:
> > On 2011-05-19, at 4:36 PM, Chris Travers wrote:
> >> Currently LSMB doesn't even support purging old data.
> > 
I don't see any need for purging data. With today's computers there is no 
reason resource wise.

Later on the status of a record could be marked differently (after a certain 
period) but the data will stay available anyway.

Let's talk some numbers here. Even if a larger practice (e.g. 5 radiologists) 
see 100 patients per day and write 100 invoices per day this should translate 
to 36500 invoices per year at most. Given how few data an invoice is made of I 
cannot imagine there should be any problem for a Postgres database handling 
this data for a 10 year period (365000 invoices).

> > Don't in any way apologize… there is a lot to be said for data integrity.
> > Also, the accounting records are unlikely to b individually large as I
> > do not imagine that accounting much stores large image or sound or video
> > files!
> 
+1

> So… what more remains to be clarified before some schematizing and/or
> prototyping might be able to begin?
> 
> > 1)  Where should the data be entered?
> 
>       I think we agreed to accept flexibility
> 
>       - where clinically relevant, in the EMR
>       - where not clinically relevant, directly in billing/accounting software
>       - clinic gets to decide what is clinically relevant
> 

I believe we need to cleanly seperate a few scenarios here. In an ideal world 
you would simply bill what you did and what you used (materials) just like a 
carpenter.

This could be the very first implementation. For that we have identified that 
we currently lack a way to enter billables.

There could be 
a) a plugin where one would manually enter billables (e.g. fetching billable 
items from LSMB) sending it off to LSMB

b) some sort of tagging /marking) medical data (procedures, diagnoses) in the 
EMR as billable item so it will appear in said plugin before sending off to 
LSMB

In a lot of health systems doctors == accountant so doctors are under the 
impression that the EMR is providing them the billing software while in 
reality the billing software is inclueded into the EMR (abstracted so far that 
the doctor does not notice)

To make this clear. Here in Germany I am not aware of any software that could 
automatically detect billable items. These softwares need the doctor to enter 
an abstract billing code which is connected to a certain amount of money.

So you would enter code 1 for an initial assessment of the patient and this 
code is then translated into a human readable billable item and associated 
amount of money.

Furthermore those integrated billing systems rarely have any clue to properly 
handle invoices when looking from bookkeepers perspective. I am not aware of 
any sofware that is used to balance income and cost. It is not the norm that a 
practice uses software to track used ressources (drapes and stuff) , bills for 
those and at the end of the day looks at the cost.

The situation here in Germany is like this:

patient comes in
doctor does some vodoo
doctor enters some billing codes for that vodoo (mostly top of the head) into 
some plugin
rules on combination of billable items are checked
doctor presses 'create invoice' at any time
invoice is printed and amount is added to 'unpaid bills'

That is it.

May in some cases you can change the bill later on but that mainly involves 
going to a list of bills, opening one of them, adding or removing codes and 
pressing 'print this now' again.

I am not even sure the change is tracked. Anyhow keep in mind that the doctor 
is the accountant in the majority of the cases so whatever we come up with it 
might help the uptake of the software if a doctor (rather then accountant) can 
handle the above steps.

> > 2)  Who reviews that data?
> 
>       I think we agree it should be
>       - the biller / accounts manager

they will be identical in many cases and many doctors have little knowledge on 
how to operate a full fledges ledger.

>       - working and viewing from the billing / accounting software

This will be critical. Doctors so far are used to view but more importantly 
change invoices form "their EMR". This is not feasible in our case where we 
explicitely want the smart of LSMB to handle this properly. At the end of the 
day it boils down to the question wether or not the physician (being the 
accountant) can hanle LSMB or not.

>       - with some sane way to acquire clinical information as needed to 
> support
> payment - EMR may push it

In Germany this is implied by the textual representation of the billing code 
one enters. In our scenario billable items (articles) in LSMB will have item 
code (which for Germany could be identical to the billing codes of the GOÄ 
coding system) and a textual representation.

I am not aware that other clinical information will be needed for billing (it 
might even be forbidden to have this information on an invoice)  

>               - billing ./ accounting daemon / service might be allowed to 
> query 
it

you mean clinical data or billable items ? This is about push/pull. Depending 
on the flexibility of LSMB the EMR billing plugin would push data to LSMB and 
maybe keep a reference on the invoice number (created in LSMB) and status of 
said invoice (open for additional data, closed). But that would lure us away 
form doing it inside LSMB and I imagine it to be hard to keep data consistent 
(EMR pushing data into invoice which is closed/finalized in LSMB).

A future EMR plugin could try to interact with LSMB in realtime but that would 
mean to replicate the LSMB GUI inside the EMR (which is what most doctors are 
used to). This is definetely *not* first working version material. 

>               - failing the above the MOA or doctor might have to manually 
> provide 
it

Inside LSMB that is ?

> 
> > 3)  How does it get sent out as an insurance claim or patient bill?
> 
>       This is maybe where Chris was wondering about whether & how to support
> on-line claiming?
> 

LSMB could look at interfacing to FreeB or REMITT. This is independent of the 
EMR.

GNUmed <-> LSMB <-> gateway/data mangler -> REMITT
GNUmed <-> LSMB <-> gateway/data mangler -> PÄV (private patient claims 
processing house)      


>       --> suggest see this page, second section ("Q & A with a Mediclaim
> developer") http://wiki.gnumed.de/bin/view/Gnumed/BillingBritishColumbia
> 
>       --> re insurer's data specification requirements:
> 
>               yes, this could be integrated to be pushed out *by* the EMR
> 

We want to keep away as far as possible :-) Maintaining changes is a PITA.


>               *or*
> 
>               it could be integrated into the accounting program provided it 
> would 
be
> granted an EMR user account that would permit a daemon / background
> process to fetch the needed data from the schema… yes??
> 

or rather extended. There could be a LSMB <-> REMITT gateway


Our intial consideration would be to have something working that completely 
ingnoes this step and works like this

GNUmed <-> LSMB

Regards,
Sebastian