Billing in Oscar

Oscar's billing is localized to support electronic billing in each of two different requirements environments (which I'll here call locales), Ontario CANADA and British Columbia, CANADA.

The tables are not as cleanly separated as I would think desirable. The core table definitions file oscarinit.sql contains some tables used only by Ontario, and other tables with mixed use (some columns re-used by BC, others used purely by Ontario). Supplemental locale-specific tables are specified in _locale .sql script files. Proposed clean-up is appended below as is Configuration and Backend.

It's undocumented whether or where the program code for the regions overlaps, but the applicable program code is controlled by the billregion setting in the oscar_mcmaster (or locally equivalent-named) .properties file located, in Debian, in usr/share/tomcat4/. Some extra care is required in decommenting some of the .properties file lines on account of their not yet being clearly grouped by function or locale.

The BC version has had the greatest recent activity, and it is possible that it has the greater overall functionality. Its code lives in FIXME <=WEBINF/oscar/source/oscar/>

Billing functional description (British Columbia version)

BIlling can be initiated from the Appointments screen (which stores, in its table field status whether or not anything had been billed); from a patient Encounter screen; or from the patient's Master demographic record sidebar, by clicking the link Create Invoice. This accesses a "Create Invoice" screen, completion of which results in:
  • one record in the billing table linked to...
  • between one and three billed items, one per fee code, which get written as individual records in the billingmaster table (a substitute for the Ontario billingdetail table).

The rationale behind the above construct is undocumented. Possibly it was built around arbitrary Ontario payor requirements? Possibly the billing record was meant to aggregate multiple items within it, but by consequence is limited to three items which must carry identical values for date (and time) of service and other values, including the payor or "financially responsible agency". Which can complicate matters if one item, billed originally to one FRA, is unpaid or partly paid with reassignment of the balance to an alternate FRA, which in health care can easily happen. (-- I wonder how the value of status in billing is handled?) Note: as at February 2007 this code is being refactored to make (or to at least store) each fee as a distinct item.

Each billed item is characterized by a status which gets updated depending on subsequent activity. The field billingmaster_billingstatus can take on the values in the table that follows (programmatically deployed in the class mspreconcile).

mysql> select * from billingstatus_types;
+---------------+-------------+-----------+
| billingstatus | displayName | sortOrder |
+---------------+-------------+-----------+
| X             | BAD         |         1 |
| P             | BILLPAT     |         2 |
| H             | CAP         |         3 |
| T             | COLL        |         4 |
| C             | DCC         |         5 |
| D             | DEL         |         6 |
| N             | DNB         |         7 |
| Z             | HELD        |         8 |
| A             | PAIDPRIV    |         9 |
| E             | PWE         |        10 |
| F             | REF         |        11 |
| R             | REJ         |        12 |
| S             | SET         |        13 |
| B             | SUB         |        14 |
| W             | WCB         |        15 |
| O             | NOSUB       |        16 |
+---------------+-------------+-----------+

Proposed changes to SQL scripts:

The scripts would benefit from more/better in-line comments.

Proposed refactoring of table structures and data:
  • oscarinit.sql
    • move to oscarinit_on.sql the tables clinic_view, clinic_no, billcenter, billingdetail, billinginr, billcentral, clinic, cliniclocation, batchEligibility, `billingservice`
    • move to oscarinit_bc.sql the table billactivity provided Ontario confirms it does not use it
    • drop table study2004?
  • oscarinit_on
    • move from oscarinit.sql tables clinic_view, clinic_no, billingdetail
  • oscarinit_bc.sql
    • consider reordering the tables if it would make the code more understandable
  • oscardata.sql
    • delete * from scheduleholiday
    • in place of those outdated records, supply oscarholidays2006_bc.sql etc
  • oscardata_bc.sql
    • move ctl_billingservice data to new file oscardemodata_bc.sql?
    • provide ctl_billingservice data as separate scripts? It is, I suppose, easy enough using the Admin tool, to delete these

Configuration and Backend

A setting in the oscar "properties" file (e.g. billregion=BC) determines the parts of the core code that control billing, including the display of billing options for example the Admin area's "Generate Teleplan file".

Presently, regardless of province, and within any one patient, the table "billing" serves as a root item, spawning one to one or one to many billable items in a related table. That related table is different in BC (billingmaster) from Ontario (core table billingdetail).

In BC, the above construct is used for both appointment based billing as well as billing from the patient's demographic record, and applies across all payors, including Workmen's Comp or private.

The BC billingmaster table contains, among its columns, some used for internal purposes. It is otherwise largely, but not purely, conforming to provincial Medical Services Plan specifications. For example, it does not appear to provide a position for the sequence number. Only the first of its successfully-acknowledged ("original") trip values can be preserved in the column original_claim.

While the billingmaster table includes a column office_number varchar(7) which is meant to serve as the "office folio" (or internal reference, or "claim") number, this ought to be a keyed field, unless it may repeat once it --- together with billingmaster_no int(10) --- exceeds 999,999.

Many extension tables that serve combined clinical and billing functions (forms) are also defined in oscarinit_bc and are apparently referenced from or to billingmaster.

It appears that in the course of generating a submission file to go to MSP, a constraint arises from the core table billactivity that had been structured to serve Ontario's limits. In Ontario, only the claims of one single provider could be included in any one batch file.

Each of the index provider's "ready" claims may get assigned an auto-incremented sequence number from the BC table log_teleplantx column log_no. The auto-incremented values, being numberic, must first be translated into the character-based, length 7, right-justified, zero-filled "sequence numbers" required by Medical Services Plan (Teleplan).

Presumably each value gets inserted into the appropriate position within each claim (or interdigitating note) and the complete batch of claims and any notes are assembled into a blob stored in billactivity. Presumably, as part of the exercise, a text file gets written into some directory.

For the sequence number it needs to be recognized that once the value of log_no hits 10000000 the computed sequence number needs to roll back over to 0000001 ergo must be the zero-filled equivalent of log_no-9999999, and so on, with each multiple of 9999999.

ToDo: find out what is 'simulation'

-- JamesBusser - 09 Sept 2006
Topic revision: 08 Mar 2007, JamesBusser
 
Download.png
This site is powered by FoswikiCopyright © 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