[Gnumed-devel] Billing revisited

[Jim Busser]

There is a company in my province that provides web-based billing and  
they are now building a connector to allow import of billable items  
from PDAs. The same connector can apparently be repurposed if there  
would be a GNUmed-side connector developed. I am therefore coming  
back around to billable items.

Maybe able to be considered for client version .6 and the next server  
(database) version?

Billable items will eventually require a billing plugin. Billing plug- 
in may only need to manage access to a single table (the billable  
items table), but it may want to at least reference look-up values  
from other tables.

- billables table:

1) if a single table, may raise no objection to being part of the  
GNUmed database schema

2) can we have configurability in GNUmed settings of whether  
billables functionality is to be enabled?
	hint: a "Billables" plug-in would detect this state and when raised  
would provide the user a message if billables functionality  
(tracking) had not been enables
	alternatively the loading of Billables plug-in might automatically  
enable billablity even if it had never before been enabled

3) billables will usually but not always (and not always 1:1) be  
spawned from encounters. The encounter types table could usefully  
include one additional field billability  (or bill_able or  
bill_eligibility) and this could help to regulate whether a billable  
record gets automatically spawned:

true (e.g. actual physicial visit types):
        billable record is created ( billability = true )

false (e.g. chart reviews):
        do not bother to create a billable record

null (e.g. when it depends, as with some telephone care)
        billable record is created ( billability = null )

4) in the billables widget it would be possible, inside any active  
(raised) patient, to see and update any filterable set of the  
patient's billables (Note: in the lines that follow, null false and  
true no longer refer to the field inside the encounter type table but  
in the resulting "billable" records):

        null remains null until a decision is made
        nulls can be set to "false" and can be made to disappear
        "false" can be made visible in case a mistake was made
        new billables can be created inside the widget for example
                - > 1 item required in some encounters
                  (can copy some values from the first billable)
                - encounter default was"false"
                - encounter not relevant

"trues" can be pre-populated with
        key to encounter (if encounter-derived)
        key to patient (if not encounter derived)
        date time (may need to be modified for billing)
        practitioner (may need to be edited for billing)
        proxy practitioner (locum etc - not sure about this)
        site of care (not sure about this, could come from encounter)

"trues" might also need:
        comment (free text to guide the billing clerk)
        data_narrative (where a report needs to be submitted)
        data_formatted

The data_formatted field could be in common to a variety of billing  
plugins and each of them could manage their own specification for how  
data would be internally formatted within the data_formatted field.  
Examples: HL7, ad hoc carat (^)-delimited. The plugin could perform  
lookups for example to assist selections of which diagnostic codes to  
use.

Would the insistence to avoid bloat in GNUmed require that a fee  
table be maintained in some separate database and not among the  
gnumed table structures? I am only thinking one table: fee_key,  
fee_code, fee_description but maybe even such a table is considered  
the slippery slope of bloat. ;-)

Anyone who has had to manage billings knows the importance to not  
miss doing the billing. That is why the notion of defaults for  
certain encounter types... to make sure that people do not simply  
forget to bill, There will be a need to run queries *across* patients  
in order to identify possibly billable items (nulls) on which no  
decision had yet been made, and also the billable items that have not  
yet been accepted by the connector that needs to transfer the items  
into a billing system. This IMO should be a different plugin (a  
"billing report" plugin).

This billing report plugin would generate a multi-patient list, which  
could be filtered by practitioner. Clicking on any patient would then  
jump the user into the billing detail widget.

Depending on the external billing system, the GNUmed XML-RPC may or  
may not be applicable. In the case of the web service that I  
describe, I imagine the XML-RPC is irrelevant. The user may however  
me able to trigger, from each of the billing detail and billing  
report plugins, the script or subsystem that would query the  
billables and transfer the appropriate ones to the external billing  
system. I would even envision some kind of prioritization in which  
triggering from inside a patient would tag their billables with an  
"immediate transfer" priority so that the subsystem upon encountering  
any high-priority items in its query would transfer only these in the  
current iteration, saving the regular priority items for the next  
iteration. I am thinking that this could shorten the amount of time  
that a patient may have to wait, if they are at the front desk and  
are asked to wait in order to pay a charge that they must pay  
themselves.