[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Billing revisited
From: |
James Busser |
Subject: |
Re: [Gnumed-devel] Billing revisited |
Date: |
Thu, 05 Mar 2009 15:13:14 -0800 (PST) |
-----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.