COMPENSATION COURT OF NEW SOUTH WALES

 

 

Phoenix Court and Case Management System

 

 

Introduction - the Court

 

The Compensation Court of New South Wales is established as a Court of record under the Compensation Court Act 1984. The Court has jurisdiction under the Workers Compensation Act 1987 to resolve workers compensation disputes arising out of work related injury or disease suffered by a worker in New South Wales. The Court also has a review or appellate jurisdiction under associated workers compensation and other legislation. The Court deals with an average of 20,000 matters each year.

 

The Court is composed of a Chief Judge and 18 other Judges. There are four Commissioners. There are also three Registrars, who hear interlocutory matters, a Chief Medical Officer who is responsible for Medical Panels, and a total of approximately 160 staff, some 79 of whom work in the Registries of the Court.

 

Judges are based at 88 Goulburn Street, Sydney which is the location of the Court’s principal Registry. Two Judges sit on a rotational basis at Parramatta.

 

Judges travel throughout New South Wales to hear cases. There are approximately 200 country circuits each year, held in 44 different locations throughout the State or in capital cities of other States where those cities provide specialist medical services for regions of New South Wales.

 

Commissioners are based at 85 George Street, Parramatta. From time to time Commissioners undertake circuit work. The Court provides registry services at Parramatta.

 

Two Judges of the Court and a Commissioner sit at Newcastle on a rotational basis to hear cases. Registry services are also provided at Newcastle.

 

The Court has premises at Wollongong where a Judge hears cases there approximately every two weeks.

 

As well as court hearings, the Court also holds medical panel examinations. As a consequence of these examinations two or more doctors, appointed by the Chief Judge as medical referees, certify as to a worker’s condition or fitness for employment or as to any matter relevant to a question arising in proceedings before the Court or a conciliation officer. In certain circumstances the certificate may be conclusive evidence as to the matters certified. Medical panels are held in Sydney, Newcastle and Wollongong.

 

The Registry’s essential working tool is a computer based case-flow management system called Phoenix. The Court’s Information Technology Branch maintains a Wide Area Network (WAN) service to provide ready access to core systems for Newcastle, Parramatta and the medical section.

 

Background to Phoenix III

 

The Phoenix Court Management System was conceived in late 1989. The initial system delivered was small in terms of functionality, number of users and the amount of data stored. This system was built using AREV (Advanced Revelation Database Management Systems) and installed first on an Apricot and then on a Compaq server.

 

The system was event-driven, that is, to bring a matter to fruition a series of events had to occur in a given sequence. These events were to a large extent in the hands of practitioners and outside the control of the Court. As each event occurred it was recorded in the computer system and the next event, usually procedurally triggered, was entered into the system. That system was, on the whole, a recording mechanism which stored historical data relating to a matter’s progress through Court and allowed the generation of various notices as required.

 

Why the need to change

 

The development approach of that initial system was driven very much from a user’s perspective. It emphasised the front-end look and feel of the final system, with little attention to Database Design Concepts. The result of this approach was a system that met a proportion of user requirements but had no meaningful documentation. It had lost referential integrity over a number of files, was unnecessarily complex and cumbersome and unable to be maintained in the long term.

 

Phoenix III features

 

The current Phoenix III system is a complete redevelopment of the initial system and incorporates such features as:

 

 

 

 

 

 

 

 

 

 

 

 

 

Technical overview

 

Phoenix is based on client/server architecture. This type of architecture allows the processing to be split between a client machine (the user’s PC) and a server which stores the database itself.

 

The Phoenix client program with supporting libraries and drivers is loaded from a NetWare 4.11 file server, to the user’s PC. This ensures that all users are using the same version of Phoenix, and makes it easy to update. The client interface is developed in PowerBuilder 5, while the Database component uses the SYBASE 11 database engine. The database component of the application currently runs on a Compaq 4000 series quad processor file-server under a Windows NT 4 operating system. The Phoenix client and server database communicate over a network through one of a number of common protocols. The application is accessed through 180 workstations from various locations on the Court's WAN. On average Phoenix processes daily 4MB of live data and manages 4GB of archival data.

 

The system is interactive and the user-interface is a windows MDI frame where multiple sheets can be opened within the frame. The frame has a toolbar providing access to a large number of "power buttons" (each with micro help) which operate in the same way throughout the application. This gives rapid access to modules in line with the ‘one stop shop’ concept and an interface, which is consistent and easy to use. The application is fully supported by comprehensive on-line help facilities and a detailed on-line procedures manual, both of which were developed using the help authoring tool HDK.

 

The application also has its own security system which only gives users access to those Phoenix functions required for the performance of their duties. Options to which a user has not been granted access will be "greyed" out and not accessible if selected or else they will not appear at all, depending on a global setting in the Applications System Parameters. An encryption routine is run within the application to prevent unauthorised access to the database outside the application.

 

 

Phoenix Modules

 

Phoenix consists of 15 Core Modules, accessed from a windows type menu system. The menu system allows appropriate actions to be carried out within each module depending on a user’s access rights.

 

The Phoenix modules are:

 

This module records results, and produces for the parties a formal Award which sets out in detail the determination of the Court.

 

Judicial circuits are planned in a yearly calendar which takes into account a Judicial Officer’s availability. (See attachment which is a print-out from the system HELP).

 

This module allows the issue of subpoenas and the management of all documents returned under subpoena. Access to these documents is also recorded and tracked.

 

This is a tracking module for recording details and locations of the Court's paper files.

 

Here all documents lodged by the parties in the progress of a matter are recorded. The events that move a matter through its "life-cycle" are the lodging of documents and Court Hearings. As a result, the document processing module is linked to a Database "stored procedure" which manages the workflow of a matter.

 

This module provides facilities for recording and maintaining the details that are unique to a matter, such as the injuries involved, the role of the various parties in the matter, unique listing requirements, etc.

 

Rather than a system module, this component of Phoenix is a whole sub-system which provides all the features required for management of Medical Panel examinations.

 

This module creates and maintains details of all persons or organisations who are in some way involved with the Court.

 

This module is used to create the core details of a matter. It allocates a matter number and issues a seal for the Application for Determination (the Court’s initiating document). This function facilitates more rapid processing of new matters at the Court's counter and to minimise delays for clients.

 

This module records details of Applications which have been rejected under the Court Rules and procedures, and rejection letters are produced.

 

This module:

(i) allows for automatic scheduling of matters to available circuits on the calendar;

 

(ii) allows manual adjustments;

 

(iii) automatically constructs and assigns notices, eg the Preliminary Advice (issued 12 weeks before a Hearing), Confirmation Advice (issued 8 weeks before a Hearing) and the notice of hearing and

 

(iv) generates a variety of lists, eg the proposed list, daily lists, individual Judicial Officer’s lists and Results Sheets.

 

This module generates orders for transcripts. It also tracks receipt of transcripts by the Court and the collection of transcripts by clients. In addition, it provides the facility for uploading and electronic storage of transcripts.

 

This module records orders made in Court. It is also linked to the listing module, allowing users to list matters for a future hearing if required. It is also linked to the "workflow stored procedure" so as to automatically give effect to Court Orders by triggering changes in the matter status (ie by moving it to the appropriate new phase in its lifecycle.)

 

This module provides access to all the information regarding a matter in one place. It also provides a sophisticated system for managing the printing and historical retrieval of all outputs produced by the system. One of the features of the application is that any output produced by the system does not need to be stored in paper form but is capable of being reproduced as it was originally dispatched through the system.

 

This module is a comprehensive set of tools for administering the application. The applications security module, system parameters, reference codes and document templates are all maintained through this module.

 

In addition to these modules, Phoenix currently supports 44 separate management and operational reports. These provide a detailed view of the Court’s case-load.

 

The system also has functions available to certain users to enable minor changes and variations to be introduced to practice and procedures without having recourse to programmers. (See attached).

 

 

Present position

 

Phoenix III has been in operation for a little over two years. Since its introduction a number of enhancements have been carried out to make it more fully functional, both in terms of its operation and its management. Phoenix can now be considered a mature application, that is functionally complete and runs with minimal maintenance overheads whilst fully supporting the operations of the Court's Registry. It is envisaged that minor alterations may be required from time to time to accommodate changes in Registry procedures, legislation or Government policy in relation to workers compensation. The application's design is of a high quality and is flexible enough to accommodate a fair degree of change over time. This, together with the fact that it is based on current "state of the art" technology, will ensure the longevity of the application. This application was designed to be, and will be capable of, supporting the operations of the Court into the next century.

 

The Court believes that the Phoenix application is of commercial quality and is the leading system of its type in this country at the very least. To validate the commercial viability and flexibility of the application, it was given to the Department of Industrial Relations (DIR). The Court's Phoenix application was customised to meet the specific and very different requirements of the newly formed Worker’s Compensation Resolution Service (WCRS). This customisation was completed and an application known as FELIX was successfully implemented which specifically met the requirements of the WCRS. The WCRS now possesses an application which is specifically tailored to their business requirements and supporting their business processes. The level of functionality provided to WCRS could only have been achieved at a cost and with a development time many magnitudes higher than was required, without using Phoenix.

 

The success in customising the Phoenix application to provide the WCRS with an application has prompted DIR to formulate a proposal and tactical plans for the development of a major corporate application known as Prosecution Information Management System (PIMS) which will support DIR’s core business activities: prosecuting and licensing. The proposal is based on utilising client/server architecture and reusing a significant quantity of Phoenix codes to dramatically reduce development times and costs. Development of this project has just commenced and the completed application is due to be delivered in June 1998.

 

The Attorney General's IT Branch is currently evaluating the Phoenix application to assess its suitability for use in other jurisdictions. It is felt the application could be marketed as a packaged software application and implemented as such in other jurisdictions. At worst Phoenix could be viewed as a fully functional prototype.

 

 

Future

 

The implementation of the Phoenix application was the first part of a two part strategy. The second part of that strategy is the electronic delivery of the Court's services to its clients. This has now become a feasible proposal. Having a robust secure database, the Court is now well placed to use technologies such as the Internet as a foundation for the electronic delivery of its services.

 

More recently, there has been project work concerning development of a computerised system for the Dust Diseases Tribunal of New South Wales. This application is seen as part of the next generation of Court Systems. It will encompass a fully functioning application which delivers services electronically as well as the scanning and electronic storage of all court documents, thereby bringing the "paperless court" a step closer.

 

This new application will use an enhancement of the Phoenix architecture and developments which relate to electronic service delivery and electronic storage will be able to be fed back into Phoenix.

 

 

 

 

 

 

 

 

 

 

Information Technology Branch

March 1998