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

[Chris Travers]

On Thu, May 19, 2011 at 11:18 PM, Sebastian Hilbert
<address@hidden> wrote:
> 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).


There are two reasons people might want to purge data, honestly.

The first is that people might want to reduce privacy implications of
data breaches, and the second might be performance.

The performance problem can be handled in better ways than deleting
data.   The privacy issue does not require deleting accounting data.

As for minimally what LedgerSMB would need:

For each invoice:
1)  Patient's contact/billing info on a new patient
2)  Which patient is involved
3)  Identifier for the invoice......

For each line item on the invoice
1)  An identifier for the part or service
2)  Any price adjustment factors (discounts, etc)
3)  Quantity.
4)  Notes (technically optional but should be sent for reasons of
being able to track down "I don't know what to put here" scenarios)


> 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)

That is my sense too.

>
> 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.

I think that one thing that is important in thinking these things
through is to try to be anything to anybody rather than everything to
everybody.   If the doctor is the accountant bookkeeper and accountant
though, often this means that the doctor will need to have access to
some sort of accounting system that will track expenses against
revenue.

>
>> > 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.

Yeah.   I personally think one of the big limiting factors is going to
be GL stuff.  Most people can figure out how to enter invoices in
LSMB, but GL stuff requires some actual accounting knowledge.

I think that one of the things that is going to be required here is to
sit down with doctors who are not so knowledgeable about accounting
and find out how some of the screens can be altered to make it easier.
 I can just imagine now.....  "What?  I CREDIT the bank account I am
transferring money from and DEBIT the one I am depositing into???"
Fortunately this is becoming quite possible to do now.

>
>>       - 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.

Yeah.......  I think this is going to take a while, and some pilot
users, and a lot of evolution of the software....
>
>>       - 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.

That is correct.
>
> 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).


Honestly I would probably do this as an LSMB plugin, which would use
dblink, DBI-link or similar to query the EMR db via a view.
>
> 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.

Well, more looking at workflows here.  Someone maybe once a week,
selects all invoices going out to a provider, clicks a button
somewhere and bam, FreeB, etc is called......    Unfortunately LSMB
isn't quite there to be able to do this as sanely as I would like.

Best Wishes,
Chris Travers
>
> GNUmed <-> LSMB <-> gateway/data mangler -> REMITT
> GNUmed <-> LSMB <-> gateway/data mangler -> PÄV (private patient claims
> processing house)
>
Pretty much.

>
>>       --> 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
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnumed-devel
>