Billing Proposal

That a GNUmed configuration setting be added, to enable the auto-creation of billable events derived from
  • billable encounters
  • billable tasks (future)
  • name of default routing daemon (e.g. gm2mediclaim for British Columbia CA, or simpleinvoices)

In point of fact, an encounter_type may only predict that one or more services, or consumables, may need billing.

Assuming auto-creation is enabled, then as soon as a patient encounter has been created and the encounter_type committed, the keyed value for the encounter_types table field create_billable will govern any auto-creation of a record in the billables table, as follows:
  • create_billable = true e.g. with actual physical visits
    • a billables record is created with value bill_this = TRUE
  • create_billable = false e.g. resulting from chart reviews
    • do not bother to create a billables record
  • create_billable = null e.g. when it cannot be known, as with some telephone care
    • a billables record is created with value bill_this = null

Within the billables table
  • nulls will remain unprocessed, until the value for bill_this has been updated
  • trues will likely need a
    • key to encounter (if encounter-derived)
    • key to patient (if not encounter-derived)
    • key to practitioner under whom to bill (if not encounter-derived)
    • date time (for which the service is claimed)
    • bill_comments (RFE or other free text to guide the billing clerk)
    • bill_formatted (custom plugin would parse this)
    • bill_documentation (where a report may need to be included; in BC this could be additional diagnoses for complex consultations)
    • bill_statusinfo (return information, which custom plugin would parse)
    • amount_billed (numeric or currency, as fed back by billing software)
    • total_received (numeric or currency, as fed back by billing software)
    • state ("original", "committed", "relayed", "billed", "brokered", "acknowledged", "refused", "rebilled", "written off", "partly paid", "paid")
    • routing daemon (while this likely to be just one per installation of GNUmed, you never know)
  • false billables, where any had been created, could be made hidden by default, and could be made visible again, in case a record should need to be made billable

A billing plugin would default to show the current patient's billables, filtered under the following priority:
  • any billables which need completion or approval
  • any billables having a status other than "paid" or "written off"

The plugin should permit new billables to be created because
  • auto-creation may not have been enabled at the system level, or at the individual encounter_type level
  • some encounters may warrant more than one billable
  • some billables may be free-standing i.e. unrelated to an encounter

The plugin should allow the choice of whether to create billables as a second or third item (etc) derived from a single encounter, or whether to create it as a free-standing item. See BillingExample.

The plugin would permit the bill_this values to be altered, and would (on update) ensure appropriate encounter, patient, practitioner keys.

The bill_formatted field could be a single field in which variable content could be stored, depending on a variety of billing plugins. Each plugin could manage their own specification for how data would be internally formatted (HL7, ad hoc carat (^)-delimited) within the bill_formatted field. The plugin could perform filtered lookups to assist the selection of which diagnostic code sets (or fee code sets) to use. A plugin might accept to work only on items marked for a specific payer or (if "smart") could take into account requirements per intended payer. The alternative to payer-based plugins would be to interoperate with Mirth so that Mirth would perform payer-based pulls of data from the EMR.

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' billables in order to identify possibly billable items (nulls) on which no decision had yet been made, and also thse billable items that have not yet been approved for acceptance 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 web services (see example), the XML-RPC might be irrelevant. The user may however be 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. Mirth could very well fit into this and is being contemplated by the WorldVista? project to assist the transfer of information into OpenEMR? for WorldVista? users who may like to use OpenEMR?'s billing.

bill_formatted considerations

Content for this field could include:
  • unique identifiers for this GNUmed billable, patient, provider
  • identifier for the payer that is to pay this item (BC: BC, RCP-province, ICBC, WCB)
  • identifier for the service, or the inventory item to be billed (BC: fee code)
  • date (or date range) for which this item is to be claimed
  • duration, or units of time-based charges (e.g. after-hours charges, hospital visits across a range of dates)
  • quantity (number of days or units)
  • amount fields (base price, applied price, discount, taxField1, taxField2, total, received)
Topic revision: 29 Oct 2009, JamesBusser
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark