Oscar Overview

On this page:
Overview of Oscar's Code
Oscar's Backend
Recommended Changes & FixMes


Oscar's root proponent Dr David Chan has been admirably successful in leveraging some opportunities to get Oscar built and deployed within Canada. Deployment at the present time is estimated at between one and two dozen centres in Canada, with possibly sites in the US, where the status of anonymous downloads, and a possible fork, are unknown. There has also been some uptake of Oscar in Brazil.

Reasons to know about Oscar include
  • its ability to provide base office functionality
  • usable clinical functions and
  • its potential to interoperate with other software

Oscar can handle the administrative functions of demographics, scheduling and appointments, and limited billing. Billing can presently support paper invoicing and, in Canada, supports electronic billing in the provinces of Ontario and British Columbia. The status of electronic billing in other regions is unknown. It is known to have been deployed to support about 75-100 networked PCs in each of two clinics, the server at each site being a dual-xeon 4GB ECC RAM and one 15,000 RPM SCSI harddrive plus a much bigger IDE harddrive for internal backup.

Readers must recognize that Oscar, like all software, has strengths and weaknesses. I think its scheduling, in particular, has been really nicely done, it is described further in ModuleDeconstructions. Where any analyses point correctly to weaknesses, these should be considered caveats, and opportunities for improvement.

Overview of Oscar's Code

Oscar's code is written in Java, compiled into a .war file using Ant, and served by Apache/Tomcat on a (typically) MySQL backend.

Oscar was originally developed for Ontario, Canada. Significant sections of the code were hard-coded to Ontario and, at this writing, have been at best only partly refactored. Over its life Oscar has seen a number of programmers come and move on, tied to project funding, but has benefited from at least one longer-term coder. Many of the electronic forms originally stored their data in form-specific tables, but there is an effort to constrain this, to leverage existing data, and to limit fragmentation and clear out some redundancy.

Oscar's source code is maintained at Sourceforge. Its properties are written to Fedora/Redhat system configurations and directory structures which do require tailoring under other distros / OSs. Oscar has managed no "official" releases since one in 2004 and that particular one is now so old as to be recommended against. Oscar is thus, by default, deployed under a "rolling release" downloadable and built from CVS. This has the unfortunate effect of limited testing and consequent requirements for roll-backs when the most recent commit(s) periodically break things so anyone who advances to production usage should not update from CVS without first running a test instance!

Oscar's backend

Oscar was developed to use MySQL presumably on the basis that it was "fast" and familiar to locally-available programmers. It has been ported to PostgreSQL but may not have been refactored beyond i18N support. Concurrent record access is not managed, nor is referential integrity, at least not out of the box.

A variety of setup scripts (both initialization, and some locale add-ons) are provided in the Oscar CVS, browsable here. Updates to the database structure get checked-in, and are copied by email to the project developer list, who must apply the changes manually to production sites.

The setup scripts could benefit from some refactoring, on account of some of the fields in the primary script (oscarinit) being specific to one locale (Ontario). Some tables (e.g. study2004) would more properly be deprecated. Some data (e.g. all values in scheduleholidays and some provider rows) needs to be culled.

It would be nice if the backend could be better normalized, and the data re-used. For example the core table set does not include a table in which all doctors in the health system can be managed. In the locale "BC", a directory of doctor data is managed the table "billingreferral" but that is used purely for billing. Core tables "consultationRequests", "consultationServices" and "serviceSpecialists" contain partial redundant data but, instead of being managed as SQL row data, these get loaded into javascript (there is contemplation of using Ajax to better-handle large pools of potential referral doctors). Separately, referring doctors get hand-entered into patient demographic tables.

Some of the data gets stored within the "comment" column of a table in the form of an xml blob (e.g. where & how fax numbers combined with other data are stored, in the table "provider").

A number of parameters (like entity definitions doubling as "labels" for key value pairs) have tended to get defined in jsp or html code instead of in tables. Apparently this was on account of updated .war files being felt to be less work to rebuild, than to require or expect installed sites to maintain new table creation and table modification. This is not a justification, just an explanation.

This result is a need for code changes to support any extension of key-value pair types. The table "demographicExt" merely holds raw data as pairs (key_val, and value), without any extensible "controller" table. The data management, including the display, insertion, editing, labelling on-screen and the insertion of the key_val info and the value itself are handled by raw jsp/html code in the root oscar.properties file. Options to improve this would be to refactor the properties code to make the use of extended demographics something that could be turned on referencing an external file, something apparently used in the OscarCitizen project. A more highly structured approach would also include an additional "controller" table demographicExtRoot:

  • pk autoincrement
  • date_time
  • entity_label
  • entity_status (default live, vs edit-only, vs read-only, vs null for hide)

The demographic code could query the demographicExtRoot for any rows with non-null values, these would control whether any existing values for the current patient would be shown and editable, and whether or not any values that did not yet exist would be permitted to be created.

see also InstallationUnderDebian and ModuleDeconstructions

Refactoring of table structures and data:

* oscarinit.sql * fix secUserRole table inserts:
insert into `secUserRole` values('999998', 'doctor');
insert into `secUserRole` values('999998', 'admin');
insert into `secUserRole` values('999997', 'receptionist');
... 999997 and not 999998 should be oscaradmin which needs admin (and possibly doctor) rights; oscarrep (provider 999999) is totally missing from the statements

* also in oscarinit.sql
    • move to oscarinit_on.sql tables clinic_view, clinic_no, billingdetail
    • 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


Admin area:

- Add a Provider... that's OK
- Add a Group Number
... it is a name, not a number, that is intended so can we instead say "Add a new Group name, or Member"

in the resulting window: ... "Group No" is easily misconstrued as a heading ... failure to "check" a provider yields a cryptic error so can we instead say "Check at least 1, and name Group:" (can the column span be other than equally-split to accommodate the extra characters?)

can this row be positioned at the bottom of table, instead of the top? can a row be inserted above the providers, to say "Provider name" and (above check-boxes) "Include in named Group"

- Search/Edit/Delete Group No Records ... no search options are provided ... the only editing possible is the deletion of members ("New Group/Add a member" just jumps the user elsewhere) ... deletion of a Group happens when all members are deleted so can we instead call this option "Delete Group Member(s)"

in the resulting window, groups are only edited though their members can we change "Group No." to "Group Name" can we change "Provider's Name" to "Provider" (name is obvious) can we nest the checkbox with the Provider, instead of the Group can we remove the button New Group/Add a member (it is confusing... the user is taken to a place as if they had picked the menu item above)
- Add a Preference record
Is it important to enable this here or can the user just be left to adjust it on their own using the Pref tab?

Dropping the option in Admin would obviate the problem that in this Admin function, non-existent Provider numbers can be typed in.

If this is to be kept, then

- validation on Provider # needs to be added

- remove "Search by Preference No.", leave "Search by Provider No"? (People would have no way of knowing what a Preference No would be).

- as there can only be one Preference per Provider anyway (new ones overwriting the old), can we relabel this option:

Create a Preference record for Provider(s)


- unless fixed, remove "Group No" field here, and in Appointment browser's Pref tab, as entries have no effect on actual memberships in mygroup table

(people can modify the group membership using the Groups function)
Topic revision: 21 Oct 2006, JamesBusser
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