Billing Example

Patient comes into praxis (office) 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 auto-creation is enabled

• encounter-creation logic waits for the user to commit the encounter type
• on update of the encounter_type, a trigger or the client software checks the encounter_type table for the value of the field create_billable
• provided create_billable is not FALSE
  • create a record in the billables table
  • set value bill_this from encounter_type.create_billable {null, true)
  • set values for datetime, encounter key, practitioner etc

The above has happened invisibly to the user. Nothing more happens until a user loads the Billing plugin

• 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

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 "Commit" 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

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.

The user could have skipped the first "Commit" and clicked the "Commit all" button.

The user knows the patient is supposed to pay for the vaccination at the front desk and so clicks the "Dispatch" 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 Billed and later gone through the Broker to the clearinghouse or payer and later been acknowledged there.