Re: [Gnumed-devel] Billing revisited

[James Busser]

-----Original Message-----
> Date: Thu Mar 05 13:02:48 PST 2009
> From: "Karsten Hilbert" <address@hidden>
> Can you a expand a bit on the concept of "billable item" ?

Individual encounter_type records within the "starter set" that ship with 
GNUmed could have the new field "bill_these" set to "null", "true" or "false" 
where it would make sense to do so. There is no penalty because the table 
"billables" will collect no stray records until billing functionality is 
activated via configuration.

Example: Patient comes into praxis for review of some problem and, while there, 
receives a vaccination. This vaccination (Gardasil) is not covered by the 
public health or medicare system and the patient will need to pay for this 
privately.

At the point of creating this encounter, if billing is "on",
- encounter-creation logic waits for the user to commit the encounter type
- on update of encounter_type, trigger or client software checks the 
encounter_type table for the value of the field bill_these
- if bill_these field is not FALSE
  -> create a record in the billables table
   set value bill_this from encounter_type.bill_these {null, true)
   set values for datetime, encounter key, practitioner
   (optional further value setting... I did not yet resolve)

Nothing more happens until a user loads the Billing plugin
- detects that billing is active, or complains
- queries the billables table for this patient's records
- by default excludes (omits) fully-paid records as well as records whose 
bill_this value is FALSE
- by default shows billables whose bill_this value is either null or TRUE
- sorts according to date and time
- in the present example, assuming no previous billables for this patient, we 
would see one record, where bill_this = TRUE plus the bit of information from 
the original INSERT

- user can now input any additional information into the billable for the 
praxis (office) visit for example if this was a newbie doctor who did not even 
know the fee codes to use they could simply, in the free text comment, write 
"simple visit, Dx diabetes" and might click "Approve" to update the status of 
this billable

- user, if aware that the vaccination needs to be billed, clicks a "New" button 
to create a new billable for this patient, and this will by default, set 
bill_this = true. The question would arise whether this billable should be 
linked to the same encounter, and so maybe two different buttons:
  "Another" would link the billable to the same encounter
  "New" could perhaps unlink the resulting new billable, letting it be 
free-standing
and the user then can put in the vaccination billing information, maybe even 
pre-specify this to be a patient-pay item, and Approve this one too.
- user could have skipped the first "Approve" and clicked the "Approve all" 
button
- another word for "Approve" could be "Sign" but let us avoid that trap for now 
:-)

- user knows the patient is supposed to pay for the vaccination at the front 
desk and so clicks the "Submit" button

Patient goes to reception. Reception opens the billing widget and sees that 
as-yet unpaid items exist and their status might be "Dispatched". Reception can 
then:

1) log into the external billing software and complete the item for which the 
patient has to pay (the vaccination), perhaps printing an invoice and maybe 
even entering into the billing system that this item is now paid for.

2) complete what is required for the diabetes visit fee, in order for it to be 
able to be submitted to the payer (medicare, third party insurance, etc).

Notice that if the external billing software would support the retention and 
handling of a GNUmed "key", the connector could have the capacity to update the 
GNUmed billables to show that the vaccination had been paid, and that the 
diabetes visit status is further updated to show it's been Submitted to the 
clearinghouse or payer.