Project Definition


This BC billing project adds modules and enhancements to the current OSCAR BC billing system, using a component based approach. Here, we shield our volunteers from the vast and extensive OSCAR codebase by defining the entry and exit point for each component then developing it as a blackbox that satisfies the requirements. 

This way, there is no risk of accidentally messing up the OSCAR code which is in use in many clinics in Canada and other Countries in the world. The Volunteers have a very low barrier of entry and a very small learning curve. basically, all you need to know is Java and XML!

The Purpose (Mission)

  • Add a gui to allow users to write billing rules/advisories.
  • Create a mechanism for users to add billing rules/advisories¬†to their systems, and to choose which billing rules/advisories they have activate.
  • Create a mechanism for users to share billing rules
  • To Create a template for future collaboration of short-term volunteers

These are the targets we want to meet

  • Define components needed for this project
  • Define the input and output of each component
  • Define the business rules for each component
  • Implement the component
  • Define deployment strategy for each component

This is how our organisation will gain.

  • Exposure of OSCAR to the volunteer FLOSS developer community
  • Better quality for our current users
  • Increase the attractiveness of OSCAR for new users
  • Increase the dynamic pool of volunteers for OSCAR development
  • Reduce the workload of current volunteers
  • Rapid response to user feedback and wish lists


Measurable Objectives:

  1. Project definition
  2. Project Architecture
  3. Deployable components


The Project follows an Agile-openup methodology. the first deliverable includes project definition, XSD files and diagrams for input and output of the management module. the component consists of a Tomcat servlet that would read the XML rules and display them to the user in a friendly manner, lets them edit/add/delete rules and saves the result back.

The next component uses a web service to gather, store, and share these rules with the first component. this way, OSCAR users need not redefine a rule, if it is exactly the same as one another colleague has made. this component also needs to be able to notify the main OSCAR base of any changes to its repository, so that the OSCAR users can decide if they want to apply the change to their local rule base.

Project Constraints

For ease of use and deployment, all the technologies, solutions, code samples, etc. used in this project should be GPL V3. Creating a Java Servlet is greatly encouraged as to limit the technologies OSCAR is using that would later result in compatibility and maintenance issues. Ubuntu code of conduct has to be observed strictly in all aspects of cooperation in this project.