WO2002075612A1

WO2002075612A1 - System and method for optimisation of practice for medical specialists practicing in a multi-site environment or for multi-site general practice groups

Info

Publication number: WO2002075612A1
Application number: PCT/AU2002/000284
Authority: WO
Inventors: John Boyages; Steven Constantine Boyages; Howard Paul Gurney; Andrew Peter De La Harpe; Peter Bruce Loder; Owen Allen Ung
Original assignee: Specialist Information Services Pty Ltd
Priority date: 2001-03-16
Filing date: 2002-03-18
Publication date: 2002-09-26
Also published as: AUPR377101A0

Abstract

The present invention provides a system and/or method for professional management of medical specialists functioning in a multi-site environment, and also a computer readable medium of instructions to facilitate the aforementioned system or method. This can allow professional management of medical specialists functioning in a multi-site environment that facilitates business process outsourcing. Software can be provided on one (or multiple) central server(s) with access from a client terminal using commonly available Internet browser applications, without requiring software to be installed or stored on the client terminal. There is a means to provide support functions such as, but not limited to: multi-site booking including procedure and protocol booking; waiting room management; records collection management, and; accounting functions. The work functions are integrated to workflow, business and clinical logic layers and monitored via a practice manager's module.

Description

System and method for optimisation of practice for medical specialists practicing in a multi-site environment or for multi-site general practice groups

Technical Field

The present invention broadly relates to a computer based management system and/or method for the medical profession, and also to the provision of software facilitating application services and clinical practice services including Internet technologies, relational database population, workflow management and clinical early warning systems to be provided in a manner suited to medical practitioners consulting or treating in multiple sites.

Background Art

As it relates to current clinical practice the current art sees specialist doctors as highly mobile people practicing from more than two sites and operating/doing procedures from multiple sites. Specialist doctors see themselves primarily as medical practitioners and not business people. As such many medical practitioners do not apply the same rigour to efficient practice management that they apply to their clinical work. In this event business management fundamentals may be absent including: maximisation of revenue producing event (managing the revenue cycle); financial key performance indicators (KPIs); clinical KPIs; Business process KPIs; Marketing data and management; leveraging 'corporate' information.

Current information systems available to medical specialists are either those produced for the non-specialist markets (a generally non-mobile group) or those systems within the public health system. Although many aspects of clinical practice overlap (pharmacy orders, diagnostic orders and results, billing/claims and note taking), the multi-practice and highly specialised treatment regimens are a fundamental and enormous difference that can only be ignored to the detriment of systematic efficiency and patient care. The current art is not fundamentally multi-practice in design and no known systems address the 'multi-site/mobility' aspect of specialist clinical practice. Prior art systems may offer the basics for practice software but do not provide valuable services such as business process outsourcing, and business intelligence though data analysis.

Many specialists practice as part of a multi-disciplinary team so that one part of a 'package' of treatment is handled by one specialist and another part by another specialist (surgeon /medical oncologist /radiation oncologist for breast cancer or surgeon / endocrinologist for thyroid disease). Appointment systems to manage these 'packages' are disjointed using an array of secretaries, booking systems (manual and electronic) and are not integrated or synchronised. Currently no system exists to manage this common practice in a synchronised manner.

That known prior art systems are targeted at the non-mobile non-specialist also results in difficulties for traditional record keeping. In many cases a physical record is created which needs to be moved from site to site. This concurrence of time and place needs to happen with specialist, patient, medical record and diagnostic reports at the time of consultation and between medical correspondence and specialist for reporting to the referrer. Incidents where the former concurrence fail, provides strong potential for legal liability exposure. The latter poor turnaround of information to the referrer is also a potential for legal liability exposure.

A component of presently known practice is recruitment of patients to, and assessment of patients during, clinical trials. This involves trawling though physical records to find suitable criteria (disease type, status, age, sex and other parameters as defined by the trial). Clinical data is written into the medical record (source document). Research staff transcribe selected data from the source documents (medical records, investigation reports) into a case report form (CRF). The CRF is checked by a clinical research associate (CRA) and sent to the central coordinating centre. Data is entered onto a database and checked for discrepancies. A Discrepancy Resolution Form (DRF) is sent back to the study site. The site staff review and complete source verification and return the DRF to the coordinating site for review. This process is repeated until all identified discrepancies are resolved. However, this process often leads to duplication, discrepancies, redundant query identification points and transcription errors and omissions in the process of undertaking clinical trials.

In a networked data communications system, users have access to terminals that are capable of requesting and receiving information from local or remote information sources. In such a system a terminal may be any type of computer or computerised device, a personal computer (PC), a mobile or cellular phone, a mobile data terminal, a portable computer, a personal digital assistant (PDA), a pager, a thin client, or any other similar type of electronic device. The capability of the terminal to request and/or receive information can be provided by an application program, hardware or other such entity. A terminal may be provided with associated devices, for example an information storage device such as a hard disk drive.

In such a system an information source may be a server or any other type of terminal (for example, a PC computer) coupled to an information storage device (for example, a hard disk drive). The exchange of information (ie. the request and/or receipt of information) between the terminal and the information source, or other terminal(s), is facilitated by a connection referred to as a communication channel. The communication channel can be physically realised via a metallic cable (for example, a telephone line), semi-conducting cable, an electromagnetic signal (for example, a radio frequency (RF) signal), an optical fibre cable, a microwave link, a satellite link or any other such medium or combination thereof connected to a network infrastructure.

The computer network itself may take a variety of forms. It may be located within a local geographic area, such as an office building, and consist of only a limited number of terminals and information sources. This type of computer network is commonly referred to as a Local Area Network (LAN). On a broader scale, it may be larger and support more users over a wider geographic area, such as across a city. This type of network is commonly referred to as a Wide Area Network (WAN). On an even broader scale LAN and WAN networks may be interconnected across a country or globally. An example of a globally connected computer network is the Internet. Files may be stored at various information sources. A user can access files from an information source, if authorised, by connecting to a computer network and requesting the files for viewing or downloading.

This identifies a need for a new type of computer based management system and/or method for the medical profession, and/or a computer readable medium of instructions for effecting such, that overcomes or at least ameliorates the problems inherent in the prior art.

Disclosure of Invention

The present invention, according to a particular aspect, seeks to provide a system and/or method for professional management of medical specialists functioning in a multi-site environment. The present invention, according to another aspect, seeks to provide a computer readable medium of instructions to facilitate the aforementioned system or method. The present invention, according to another particular aspect, seeks to provide a computer readable medium of instructions for professional management of medical specialists functioning in a multi-site environment that facilitates business process outsourcing.

In one form, the computer readable medium of instructions is a software application which emulates the responsiveness of a traditional client/server application whilst using web technologies that is useable over a conventional dial-up modem. In one form, the software application requires no proprietary software to be manually installed by a user (or client or customer) and consequently has a minimal additional entry cost for new users (or clients or customers). The present invention, according to another particular aspect, seeks to provide software on one (or multiple) central server(s) with access from a client terminal using commonly available Internet browser applications, without requiring software to be installed or stored on the client terminal.

According to a further aspect of the present invention, there is a means to provide support functions such as, but not limited to: multi-site booking including procedure and protocol booking; waiting room management; records collection management, and; accounting functions. According to a further possible aspect, the work functions are integrated to workflow, business and clinical logic layers and monitored via a practice manager's module.

According to another possible aspect of the invention, the present invention seeks to provide a means to view on a terminal aspects of the practice of importance to the clinician, and again from a holistic multi-site perspective, such as, but not limited to, patient histories, clinical contact event recording, resource access, orders entry and results receiving, medical typing interactions, and specific requirements of specialist treatment regimens such as medical oncology, surgery, anaesthesia, radiation oncology and endocrinology. Non-clinical functions include practice and clinical key performance indicators, escalation processes, internal action requests and clinical cost tracking for ordered tests and pharmaceuticals.

In yet another aspect of an embodiment of the invention, the invention seeks to provide a means to provide aspects of the clinical process to a mobile device, including, for example, clinical diary with patients scheduled, patient medical information, treatment information and letters awaiting sign-off. In a further aspect of an embodiment of the invention there is provided a means for monitoring core practice processes and key marketing information via key performance indicators presented in a 'real-time' manner as well as, for example, month-on-month performance, or other time periods, and the ability to record intervention points. This can include means to incorporate business rules in reporting, graphical reporting, escalation reporting based on inaction, and supplies ordering.

In another form of the present invention, there is provided a means to provide dictated data to typists, facilitate the typist-originator interaction and letter sign-off processes. This can include a means to incorporate business rules including escalation based on inaction or persistence of the trigger event. Such means may be integrated to workflow, business and clinical logic layers and monitored via a practice manager's module. In yet another form of the present invention, there is provided a means to provide an external parties interface as a means of communicating with external parties via mutually suitable means with, where possible, secure encrypted transmissions which include, but are not limited to: Health Level 7 (HL7), Wireless Application Protocol (WAP), Short Message service (SMS), facsimile or hardcopy printout. Such means may be integrated to workflow, clinical and business logic layers.

In one particular embodiment of the present invention there is provided a system for use in medical practice, the system able to facilitate a medical practitioner to work from multiple sites, the system including: a central server, the central server hosting a software application; a database, the database able to communicate with the software application and the database able to store or produce information or data in response to a request from the software application; at least one client terminal, the at least one client terminal able to communicate with the central server, the at least one client terminal used by the medical practitioner to access functions provided by the software application; whereby, the software application includes at least a user presentation layer, a network services layer, a clinical and business logic layer, and a data access layer for access to the database.

In one particular embodiment of the present invention there is provided a computer readable medium of instructions residing on a host server, a user able to access functions provided by the computer readable medium of instructions from one of a plurality of remote client terminals, the computer readable medium of instructions for use in assisting in the management of a medical practice and including procedures for: allowing the user to remotely access a database of information via one of the client terminals; providing the user with access to clinical functions; and providing the user with access to non-clinical functions.

In one particular embodiment of the present invention there is provided an Internet based software application which resides on a host server, the functions provided by the software application able to be accessed from a Web browser which resides on a remote terminal, the software application for use in assisting to manage a medical practitioner's practice, the software application providing an integrated interface to: front desk functions; practice manager functions; clinical functions; and medical typing functions. In one particular embodiment of the present invention there is provided a method for use by a medical practitioner to assist in providing medical services to a patient, the method assisting the medical practitioner to work from multiple sites, the method including the steps of: the medical practitioner logging into a network based management software application; profile information for the medical practitioner being passed to the management software application; the management software application retrieving and displaying patient lists to the medical practitioner; the medical practitioner selecting a particular patient record from the displayed list, the medical practitioner thereby able to retrieve medical information pertaining to the selected patient from a database associated with the management software application; the medical practitioner able to update the medical information in the patient record on the database.

In one particular embodiment of the present invention there is provided a method for use by a medical practice manager to assist in providing medical services to a patient, the method assisting the medical practice manager to work from a site remote to the medical practice, the method including the steps of: the medical practice manager logging into a network based management software application from a terminal remote to a server hosting the management software application; the management software application retrieving and displaying medical practice information to the medical practice manager; the medical practice information including key performance indicators pertaining to the routine functioning of the medical practice.

In one particular embodiment of the present invention there is provided a method for use by a medical practice receptionist to assist in providing medical services to a patient at a medical practice, the method including the steps of: the medical practice receptionist logging into a network based management software application from a terminal remote to a server hosting the management software application; a patient requesting an appointment from the medical practice receptionist; the management software application displaying a booking software tool to the medical practice receptionist; the medical practice receptionist entering patient details into the management software application; the booking software tool presenting medical practitioners and medical practice sites available to the patient; an appointment being made for the patient; at the time of the appointment the medical practice receptionist starting a clinic function of the management software application; and on completion of the clinic post clinic statistics are stored in a database and an end of clinic financial report is generated.

A feature of a broad form of an embodiment of the invention is a means to ensure the correct sequencing of data collection and processing from an 'ideal workflow' perspective. Another feature of an embodiment of the invention is a means to ensure clinical rules are applied and enforced, any exceptions being alerted to the responsible clinician. A further feature of an embodiment of the invention is a means to enforce security policy from a patient information perspective. According to a particular broad aspect of the invention there is provided a data source layer that contains the actual data structures that form the repository for system data. In yet a further broad form, the present invention provides that the computer network can be any network of two or more communicating computers or terminals including but not limited to, an internetwork, an intranetwork, a LAN, a WAN, or the Internet.

Brief description Of Figures

The present invention will become apparent from the following description, which is given by way of example only, of a preferred but non-limiting embodiment thereof, described in connection with the accompanying figures, wherein:

Figure 1 illustrates an embodiment of the present invention wherein, the figure shows a schematic of the general functional design.

Figure 2 illustrates an embodiment of the present invention wherein, the figure shows a simple overview of the preferred pre-clinic and post clinic workflow.

Figure 3.1 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for preferred flow - Bookings component.

Figure 3.2 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for preferred flow - Confirmation component. Figure 3.3 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for preferred flow - Records Gathering component. Figure 3.4 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for preferred flow - Clinic Setup component.

Figure 3.5 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for preferred flow - Waiting Room and post clinic functions.

Figure 4 illustrates an embodiment of the present invention wherein, the figure shows a management perspective of the simple overview preferred front pre-clinic and post clinic workflow.

Figure 5 illustrates an embodiment of the present invention wherein, the figure shows a schematic layout for practice manager providing rapid review of practice status - across sites - for core processes.

Figure 6 illustrates an embodiment of the present invention wherein, the figure shows a simple overview of preferred clinical consultation process.

Figure 7 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for preferred consultation flow.

Figure 8 illustrates an embodiment of the present invention wherein, the figure shows a schematic of the clinician interface with the 'add-note' tab clicked.

Figure 9 illustrates an embodiment of the present invention wherein, the figure shows a schematic of clinician interface ('m' - medical record view). Figure 10 illustrates an embodiment of the present invention wherein, the figure shows the Clinical Quality Indicators arising from an embodiment of the invention as illustrated in figures 6, 7 and 8.

Figure 11 illustrates an embodiment of the present invention wherein, the figure shows a management perspective of the Simple Overview preferred consultation flow. Figure 12 illustrates an embodiment of the present invention wherein, the figure shows a typist perspective of a simple overview of preferred Medical Typing Process.

Figure 13 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for preferred medical typing process.

Figure 14 illustrates an embodiment of the present invention wherein, the figure shows a management perspective of the simple overview of preferred medical typing process. Figure 15 illustrates an embodiment of the present invention wherein, the figure shows the standard format for the representation of key performance indicators.

Figure 16 illustrates a simple overview of a preferred radiation oncology process. Figure 17 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for the preferred radiation oncology workflow.

Figure 18 illustrates a simple overview of a preferred medical oncology process. Figure 19 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for the preferred medical oncology workflow.

Figure 20 illustrates an embodiment of the present invention wherein, the figure shows the preferred surgical workflow.

Figure 21 illustrates an embodiment of the present invention wherein, the figure shows the systematic support for the preferred surgical workflow.

Modes for Carrying out the Invention The present invention provides a computer based management system and/or method for the medical profession, and/or a computer readable medium of instructions for effecting such. In the figures, incorporated to illustrate the features of the present invention, like reference numerals are used to identify like parts throughout the figures. The following modes are described in order to provide a more precise understanding of the subject matter of the present invention. These examples are intended to be merely illustrative and not limiting of the scope of the present invention.

A preferred embodiment of the present invention is illustrated in the figures. The following legend refers to figure 1 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention: Front desk (100): Functions related to the role of front desk/reception within a specialist medical practice.

Booking (105): Functions related to the booking process. The booking process in simple process context is shown in figure 2. More detail of how the system and method supports the preferred booking process is shown in figure 3.1. Waiting Room (110): Functions related to the waiting room process. The waiting room process in simple process context is shown in figure 2. More detail of the how the system and method supports the preferred waiting room process is shown in figure 3.5. Billing (115): Functions related to the billing process. The billing process in simple process context is shown in figure 2.

Back-office (120): Functions related to non-patient contact related administration a preferred but non-limiting embodiment includes: Clinical Follow ups; Operational; Quality & Performance; Financial; Billing Processes (non-patient payers); Marketing;

Supplies; Practice preference management; Human Resources Management, and;

Payroll.

Practice Manager (125): Functions related to the role of practice manager within a specialist medical practice. Managers dashboard (130): An application and method which is outlined in figure 5 and provides detail on process status described in figures 4, 10 and 13.

Practice KPIs (135): Key performance indicators used to monitor process and financial performance.

Medical Typing (140): Functions related to the role of medical typist within a specialist medical practice.

Clinical (145): Functions related to the role of medical specialist within a specialist medical practice.

Clinical Workspace (150): The primary work area for specialist doctors to view patient records and record clinical events. Library and research (155): On-line access to medical journals such as 'medline' and 'Harrisons' as well as new products and drug information. A preferred embodiment would also include the submission of a 'research request' to a 'librarian'.

Specialists lounge (160): A preferred embodiment of the specialist's lounge includes access to non-medical areas of interest. This area is tailored to the specialist's interests but includes common features such as: financial and insurance services.

Education (165): A preferred but non-limiting embodiment of the education services includes video links to cases of interest (eg. Surgical cases), lectures and publications and other datacasting services.

Mobile facility: The provision of clinical information and access to relevant clinical processes via a personal data assistant (PDA) or mobile phone.

User presentation layer (170): The client application (browser) and code that defines what the user sees whether from a standard computer or mobile device. Workflow logic layer (175): The server code that ensures the correct sequencing of workflow events.

Clinical and business logic layer (180): The server code and rules that define and monitor actions according to predefined rules and escalation sequences and periods. External parties interface (185): Server code that interfaces and authenticates data extracts and formats data according to rules and protocols defined for the particular party.

Interested parties: Parties that have an interest in the specific case. HIC (186): Australia's health insurance commission, this may be any government payer, from any country /region.

Registers (187): Any official register of patient conditions such as the cancer registry.

Diagnostics: Providers of pathology or medical imaging services. Drug companies (188): Providers and manufacturers of pharmaceuticals. Insurers (189): Private health insurance companies.

Data access layer (190): Server code that receives a request for data and returns the requested data.

Medical record access security: A component of the data access layer that checks record and user status, allows authorised access, stores the fact that a record has been accessed and in the event of record modification records that pre-and-post-modification results.

Data source layer (195): The databases that store all system information, m-avert: A term applied to the code which applies clinical rules and escalates issues in pre-defined periods, to pre-defined people as a component of the clinical and business logic layer.

Multi-site design: The fundamental system and methods used to enable authorised staff to access other sites from where a clinician works allowing among other features multi-site booking.

The following legend refers to figure 2 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention: Booking (205): Actions associated with scheduling a patient to see a clinician. As it relates to the present embodiment this allows scheduling of a patient across any site from which the clinician practices for which the user has permission to do so.

Confirmation (210): A process step whereby the scheduled patients are contacted and the booking confirmed or cancelled. The appointment vacated by a cancellation may be filled from a waiting list.

Records Gathering (215): A means of requesting a physical medical record from another site. The embodiment incorporates providing a preferred means of contact (which may be overridden) including various electronic means.

Clinic preparation (220): The process of setting up specialist consulting rooms according to the preferences of the specialist.

Waiting room (225): The functions and process steps from the point that the patient presents at the consulting rooms.

Post clinic bookings (230): The scheduling of patients for subsequent visits including complex bookings associated with treatment plans.

Billing (235): The calculation of fees, production of invoices and receiving of payments.

Debtor follow-up (240): The production and management of account 'reminders' in accordance with preferred periods.

The following legend refers to figure 3.1 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(301): Set appointment search criteria as required, submit data and display results (302): Check details submit query and return results to client

(303): Retrieve available appointments

(304): Enter part or all of caller/patient's name, submit data and display results (305): Check details submit query and return results to client (306): Retrieve patient result set (307): Enter part or all of referring doctor's name, submit data and display results

(308): Check details submit query and return results to client (309): Retrieve referring doctor result set

(310): Select appropriate appointment, patient record and optional referring doctor record

(311): Display booking confirmation and collect optional additional information

(312): Check details, submit query and return results to client

(313): Create booking record, store patient details and return confirmation id number

(314): Authentication and data access check

The following legend refers to figure 3.2 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(315): Select date and site for which to confirm bookings.

(316): Retrieve scheduled appointments according to information entered.

(317): Display all scheduled patients and contact information. (318): If accepted apply confirmation logic. If cancelled apply cancellation logic.

(319): Update the original booking records accordingly.

(320): If required display patients wait listed for this specialist.

(321): check which wait lists this user has access to.

(322): If required replace the vacated appointment with the one selected from the waiting list.

The following legend refers to figure 3.3 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(323): User selects the date and location of clinics for which they require records.

(324): Check user permissions as to which clinics they are allowed to request records.

(325): Gather appointments lists, requesting sites and preferred modes of requesting records. (326): Modify requesting method, if required.

(327): Apply rules for requesting according to selected criteria. (328): Update database status. (329): Send information via external party's interface. (330): Gather transmission requirements. External Parties interface: Send requests.

(331): Receive records where such mechanisms are required. (332): Update record received status.

The following legend refers to figure 3.4 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(334) Select specialist and location, display preferences. (335) Check clinics this user has permission to access. (336) Retrieve clinicians preferences.

The following legend refers to figure 3.5 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention: (337): User selects manage current waiting room option from the menu.

(338): User and location information is sent to the database. (339): Current waiting room information is retrieved for those waiting rooms for which the user has been granted access.

(340): Waiting room information is gathered for each clinic that the user has been granted access to.

(341): Status of each aspect is interpreted and passed to the browser. (342): Browser displays data for the current waiting room (343): Start clinic

(344): Gather the clinic statistics for commencement of the clinic (345): Store commencement information and send statistics ID back to browser.

(346): Displays status of registration information and allows on-click access print (349 function) and receive registration forms. Data 'refreshes' after each modification showing 'real-time' status.

(347): Pre-clinic measures status. Displays those measures required by the clinician (349 function) prior to consultation and allows direct access to record measures. (348): Consents status. Allows direct on-click access to print (349 function) and receive consents.

(349) See 346 to 348. (350) Update status in database as each of these processes progress. (351) Post clinic appointment (After patient has seen specialist). (352) Check rules input by clinician during consult (if any) ad apply. Includes procedure-booking rules.

(353) Gather available appointment dates for selection. (354) Billing. Receive payment and print receipts. (355) Apply billing rules either from quote and/or input by the clinician during the consultation. Apply rules for receiving payments of various types. Print receipt.

(356) Update billing information in database. (357) Finalise clinic for the specialist. (358) Gather required post clinic statistics and send to database. (359) Store post clinic statistics. External Parties interface: For Did-not-attends auto send a notification to the referring doctor. Produce receipts.

The following legend refers to figure 4 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(400): Key performance indicator showing the extent to which bookings are optimised.

(405): Key performance indicator showing the extent to which cancelled slots are filled from the waiting lists. (410): Key performance indicator showing the extent to which records are available at the point of consultation.

(415): Key performance indicator showing the level of patient comfort. (420): Key performance indicator showing the level of 'did-not-attends' (DNA). (425): Key performance indicator showing the level of 'booking efficiency' . (430): Key performance indicator showing the level of 'accounting efficiency' .

(435): Key performance indicator showing the level of bad debts. (440): Controlling report 1. Report on cancellation actions to ensure medico- legal aspects addressed.

(445) Financial report of daily controls. (450) Financial report of monthly controls. (455) Financial report of debtor controls. (460) Monthly marketing report.

The following legend refers to figure 5 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention: (510): Standard 'top menu' including to-do list, establish a 'net-meeting', access email.

(520): Standard graphical representation of key performance indicator data

(530): Scrolling access to next, previous, start, or end KPI graph.

(540): External parties interface absolute numbers and detailed status (550): Absolute numbers at various stages of diagnostics orders/results. Detail

Available.

(560): Absolute numbers at various stages of medical typing process. Detail available.

(570): Absolute numbers at various stages of accounting process. Detail available.

(580): Status of system reports where such reports (whether manual or automatic).

(590): Scrolling message of critical KPIs eg. Number of appointment slots available in next x days.

The following legend refers to figure 6 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

Waiting Room (605): Specialists view of the waiting room ('real-time'). Clinical consultation (610): The process of information gathering, assessment of data and formation of a plan for the patient's care.

Inform patient (615): Informed consent for patient treatment. Diagnostic services order (620): Doctors request for pathology or medical imaging services.

Electronic medical record (625): Database and associate controlling functions for the storage of patient related data.

Electronic order: (630) Order sent to diagnostic provider.

Next appointment/Discharge (635): Decision on next treatment steps or discharge from the care of the specialist.

Dictation (640): Method for recording voice input from doctor.

Electronic dictation system(645): System for managing voice input from doctor.

Typing process (650): Physical aspects of medical typing (facilitated by dictation system).

Clinician approval (655): Final review of correspondence prior to reporting.

Report to interested parties (660): Sending of correspondence to interested parties.

The following legend refers to figure 7 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(701): Specialist logs into system and profile information is passed to the business logic layer. The clinicians workspace is opened with links to patient data. The entire workspace is opened (see figure 8).

(702): Checks if the specialist currently has a clinic and requests clinic information from data source layer.

(703): Specialists patient lists are retrieved.

(704): A patient is selected by one of the means in the left of the page.

(705): The information is sorted for display.

(706): Patient information is retrieved for 'each tab' and passed back to the browser.

(707): Add note method is a means of collecting clinical information in a very flexible format. The method supports the subjective, objective, assessment and plan consultation structure, 'progress note' format, simple contact recording (eg. phone call, email or other). Supports the electronic health summary. Entry may be specifically tailored to the requirements of a clinical trial. (708): Clinical logic layer sorts input information to appropriate data target for storage. Security standards are applied to the record, as it is stored.

(709): Summary information is stored as well as specific components being stored into the medical histories tables in the electronic medical record. (710): Prescribe method allows prescriptions to be added or stopped in the standard prescription structure.

(711): Medication chart function allows an order by doctor of medication for administration by a second party (eg nurse).

(712): Allows checking and validation of medication order by second party (eg pharmacist).

(713): Allows recording when drug is administered by second party (eg nurse) (714): Pricing information on all drugs ordered be extracted. Cross reactions checked and a physical prescription printed.

(715): Medication orders are checked for drug interaction. Linked to prescription function.

(716): The order details are recorded in the patient's electronic health record, as is the drug pricing.

(717): Drugs ordered and administered are recorded in patients electronic medical record. (718): Information and consents contains a list of consents that may be selected and printed. In addition, information provided to patients including choices and risks is also entered.

(719): Standard information and consents for this specialist are examined. (720): Information provided is recorded in the patients electronic medical record.

(721): Principle Diagnosis allows rapid entry of the diagnosis via a graphical means and functionally- layered drop down menus.

(722): The clinical layer encodes the diagnosis into ICD-10 code format. (723): Diagnosis is stored in the patients electronic medical record. (724): Treatment reports tailored to the specific specialty or clinical trial.

(725): Clinical logic as defined by the trial or specialist is applied and events triggered. (726): Treatment reports are stored in the patients electronic medical record.

(727): Reminders or actions may be entered and sent to the specialist (self- reminder) or to any other person in the system.

(728): Reminder status is tracked and inaction alerted via the m-avert method.

(729): Reminders details are stored in the database.

(730): Patient Histories are dual purpose allowing display of previously gathered medical histories and the addition of new ones.

(731): History elements are handled according to pre-defined rules for that history type.

(732) History element stored in database. (733) Finalise consultation event. (734) Check previous billing and booking information and pass for display.

Trigger action into 'to-do' list for deferred dictation.

(735) Store booking, billing and dictation information. (736) Reminder creation and viewing. (737) Route the reminder with escalation information to correct recipient (738) Store reminder details and status.

The following legend refers to figure 8 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(810): Modes for selecting the patient to work on. Modes in the current embodiment include Waiting room; All patients in system; List by diagnosis/disease code; List by interested party.

(820): When selecting from the waiting room the current patient, patients already seen, patient in waiting room and those scheduled to arrive are colour coded.

(830): Key patient information (From the specialists viewpoint) is displayed for the selected patient at all times.

(840): Key information (from the specialist viewpoint) about current medications is displayed at all times. (850): Key information (from the specialists viewpoint) about allergies and alerts for the selected patient is displayed at all times.

(860): Reminders requested on this patient and their status is displayed. (870): Tab selection for actions on the selected patient. Tabs include but are not limited to:

'M' : Medical record summary as per figure 7 (704).

Add note: As per figure 7 (707). Order Test: A method and process for ordering pathology including the innovative steps of allowing multiple providers, storing and updating the most common tests ordered by the specialist for 'quick request' . Business logic layer calculating the value of tests ordered and storing with the medical record and clinic statistics. A further feature is the system and method for Point-Of-Care (POC) pathology services.

Prescribe: As per figure 7 (710).

Inform & Consent: As per figure 7 (718). Principle diagnosis: As per figure 7 (721) and figures 6 and 7. Treatment Report: As per figure 7 (724). Reminder: As per figure 7 (727).

(880): Button selection of actions on the selected patient. These buttons, in many cases provide rapid access to a sub-item on the tabs described in (870). The buttons include but are not limited to the following actions:

No action: Stores current information. Order Test: As per (870) Order test.

Prescribe: As per (870) Prescribe.

Referral: Create a referral to another specialist.

Inform & Consent: As per (870) Inform & Consent. Major Treatment: As per (870) Treatment report. Add Diagnosis: As per (870) Principal Diagnosis.

Finalise: As per Make appointment, Billing and Dictation below. However this option sequences these events in a logical clinical flow. Make appointment: Allows selection of criteria to make an appointment but pass the task of actually scheduling the appointments to the front desk or actually creating the appointments for the patient at that point in time.

Billing: Allows viewing of intended billing policy for this patient and allow changes that are passed back to the front desk to actually receive payment.

Dictation: Provides a view of interested parties and the option to dictate now or later. The dictate now option launches the electronic dictation system. The dictate later adds a reminder task for the specialist. When the reminder is clicked a summary of all actions taken during the consultation are displayed by way of reminder for the specialist while dictating.

Reminder: As per (870) Reminder.

The following legend refers to figure 9 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(910): Record access-permissions whereby the specialist that owns the record may extend this access to another specialist or team for a limited period after patient consent. (915): Permission to participate in the NSW and/or Commonwealth electronic health record program. The application promotes an 'opt-in' policy. (920): Key reasons for treating the patient are prominent. (925): Summary of clinical events is a brief description of major events for the patient.

(930): The feature of introducing 'sticky notes' whereby the specialist can record any non-clinical information that may be of interest.

An embodiment of the present invention includes access to historical (recorded at some stage in the past) information, a preferred but non-limiting embodiment of the history functions as shown in figure 9 are as follows:

(935): Progress notes lists and allows, subject to security and access status, modification of previous and addition of new notes. (940): Medical history and problem list lists and allows, subject to security and access status, modification of previous and addition of new medical histories and problems.

(945): Family history lists and allows, subject to security and access status, modification of previous and addition of new family histories. This embodiment includes the ability to click a family tree and condition lists for rapid recording.

(950): Medications and allergies lists and allows, subject to security and access status, modification of previous and addition of new medications and allergies.

(955): Social history and alerts lists and allows, subject to security and access status, modification of previous and addition of new social histories and alerts. This embodiment includes the ability to rapidly record common social factors of smoking and alcohol consumption. This embodiment also includes an area for recording confidential information that the patient may not want passed on to another party (eg HIV status, sexual history). (960): Measures lists and allows recording of pre-clinic measures.

(965): Tests Lists tests ordered and status. Allows graphical display of selected pathology analyses.

(970): Demographics displays and allows modification to patient demographic information. (975): Consents lists any medical consents completed by the patient.

(980): Interested parties lists and allows modification to any person or group interested in the case and whether they are to receive correspondence.

The following legend refers to figure 10 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

Patient Workload (1010): Monthly patient numbers split by type and procedure.

Casemix (1020): Monthly report on the diagnoses of patients being seen.

Diagnostic Tests (1030): Monthly report in type of tests, turn-around and value.

Workload Statistics (1040): Monthly patient numbers and average consultation duration.

Ad-Hoc Contacts (1050): Monthly numbers of non-scheduled contacts.

Complications (1060): Monthly numbers of complications following treatment. The following legend refers to figure 11 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(1110): Key performance indicator for diagnostic turnaround (each phased of process).

(1120): Key performance indicator showing relative performance/efficiency of medical typing function.

(1130): Management information report on value of pathology, radiology and pharmaceutical orders by modality.

The following legend refers to figure 12 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

Electronic dictation system (645): System for managing voice input from doctor. Work pending (1210): List of dictation waiting and in progress. Type (1220): System and method for typing reports including pre-defined preferred templates for specialists and a method where desired to have the input elements entered into the medical record.

Clinician review (1230): System and method for returning completed typing to the specialist for final acceptance. This includes mobile technologies to make this process available on a 'point-of -presence' basis.

Clarification request (1240): System and method for typists to partially type and ask for clarification from the specialist about a word used.

The following legend refers to figure 13 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(1310): Typist enters the system and is presented with a list of all outstanding typing including originator, referring doctor, patient, priority, status, date and time dictated, length of dictation and status. Double clicking the record opens the word processor and the dictation file. (1320): On opening the preferred template for that specialist is opened and data retrieved from the database populating pre-defined components of the template. (1330): Typing status is updated and any requests for clarification are sent to the business rules layer and on to the originating specialist.

(1340): The originating specialist may listen to the dictation while viewing the typed information. They may choose to complete the typing themselves or dictate the clarification.

(1350): Rules are applied according to the action undertaken by the specialist. When typing is complete it is queued for final approval by the specialist.

(1360): Data status is updated and any changes to dictation or the letter or record entry are stored. (1370): The specialist may accept or change the information including the recipients

(1380): Any changes are stored and the letter submitted to the business logic layer and to the external parties interface. Record entry is stored in patients electronic record. External parties interface (1390): When the letter is printed copy numbers are incremented and the medical record data associated with that consultation is set to read only.

The following legend refers to figure 14 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(1410): Key performance indicator showing letter progress and turn around. (1420): Key performance indicator showing typing error rates by specialist and by typist.

(1430): Controlling report. Number of letters awaiting sign-off, printing or typing.

The following legend refers to figure 15 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(1510): The title of the indicator. (1520): Line graph of indicator for each clinic day.

(1530):Visual indicator showing what trend direction is desirable for the indicator. (1540) intervention point. Detail of the intervention are also stored along with the date and by whom.

(1550):Y-Scale (The X scale is always 'time')

(1560): Vertical bar graph of indicator for each clinic day.

(1570):Description of how the indicator is measured.

(1580) description of what operational factors influence the indicator.

The following legend refers to figure 17 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(1710): User selects manage current waiting room option from the menu.

(1711): User and location information is sent to the database.

(1712): Current waiting room information is retrieved for those waiting rooms for which the user has been granted access.

(1713): Standard clinical function (figures 6 to 10) with additional radiation oncology data collection. Within this embodiment the specialist may select a treatment plan for radiation oncology that may involve other aspects such as chemotherapy. The treatment would indicate a requirement for a mould.

(1714): Standard clinical rules described in figures 6 to 10 are applied.

(1715): Requirements stored in database. (1716): Available appointment slots are displayed and may be selected to establish bookings.

(1717): Treatment requirements are passed to the business logic layer and defined rules applied.

(1718): Appointment information is stored in the database. (1719): The waiting room may apply appropriate billing in the manner described in figure 3.5 and associated descriptions.

(1720): Business and clinical rules applied for billing.

(1721): Billing data is stored in the database.

(1722): Mould room staff may view patients scheduled for moulds on the day selected via the 'mould waiting room'. A fitting date may be applied/altered. If the simulator is required at that time it may also be scheduled. (1723): Clinical information is filtered such that only information required for the mould room processes is available.

(1724): Status of mould room is recorded and a date input for fitting. (1725): The mould waiting room also displays patients for fitting. By clicking on the patient all previous work up information may be displayed.

(1726): Clinical information is filtered such that only information required for the mould room processes is available.

(1727): Mould status is updated.

(1728): Simulation waiting room shows patient lists for the selected day. By clicking on the patient name relevant information can be displayed.

(1729): Clinical information is filtered such that only information required for the mould room processes is available.

(1730): Simulation status is updated making information available to the planning room. (1731): Patients awaiting planning are displayed. Key planning information may be recorded.

(1732): Business & clinical logic associated with planning. (1733): Planning information is stored in the database. (1734): Clinician sign off and booking of treatment (1735): Accelerator diaries are queried to provide booking dates.

(1736): Booking dates are stored in the database. (The system has the ability to book patients for daily radiotherapy excluding weekends and machine service days). Treatment occasions of service will be linked to standardise Medicare Billing rules, or other Government health systems. (1737): Treatment room may check treatments.

(1738): Breaks in the treatment or 'did-not-attends' trigger action to specialist. (1739): Data related to treatments is stored.

(1740): Specialist may perform a review during the treatment phase and adjust treatment. (1741): Apply standard rules to outputs from treatment review.

(1742): Store specialist input. External parties interface: Correspondence to referring doctor, connection to pathology and radiology orders, connection to other patient systems.

The following legend refers to figure 19 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention: (1910): Chemotherapy is booking creation. (1911): Apply protocol rules to booking. (1912): Retrieve suitable appointment slots.

(1913): Patients scheduled for chemotherapy that have not had write-up. (1914): Gather patients that have not had write-up.

(1915): Store write-up information. (1916): Create prescription.

(1917): Apply protocol rules and send prescription to pharmacy. (1918): Store prescription information. (1919): Pharmacy check drug formulations and dose

(1920): Prints off order tags (with user sign-off sections) that accompany drugs (1921): Status of order is updated.

(1922): Today's chemotherapy list recalled and specific requirements of the protocol displayed. Patient selected to reply to specific requirements. (1923): Clinical logic applied to specific chemotherapy being delivered according to protocol and passed to client. Clinic rules applied as each step completed.

(1924): Today's chemotherapy list retrieved from database. Database updated to 'track' each step.

(1925): Within the chemotherapy suite the nurse conducts standard checks. (1926): Check responses and trigger alters as required.

(1927): Store response in the database.

(1928): Specialist recalls chemotherapy information in post-chemotherapy review. And records toxicity, measure tumour response and alters dosing. (1929): Business/clinical logic applied specific for protocol. (1930): Stores measures, changes and flag for follow up during next chemotherapy write-up session. The following legend refers to figure 20 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

Booking: Standard booking process.

Surgery List (2010): List of patients, operation to be performed location time etc.

Operation report (2020): Standard recording of surgery conducted.

Post-operative review (2030): Outpatient visit at designated post-discharge time period.

Billing (2040): Generation of account for surgical procedure(s).

Electronic Dictation system (2050): Optional use of dictation system or direct recording in standard format.

The following legend refers to figure 21 and is provided by way of example only so that the reader may be assisted in understanding the scope of the invention:

(2110): Surgeon logs into system and requests current theatre list. Current list displayed.

(2115): Apply rules associated with this specialist and location.

(2120): Retrieve lists from database and pass back to rules layer.

(2125): Select patient to record operation report.

(2130): Apply any pre-defined rules for this operation type, specialist and/or location. Flag completed records for processing.

(2135): Store information recorded.

(2140): Option to record operation report using electronic dictation system.

(2145): Ability to use 'mobile clinician' features to sign off completed reports from any location at any time. (2150): Apply standard rules to mobile work.

(2155): Update database with any changes from mobile processes.

The present invention, in one particular embodiment, is a system or method for professional management of medical specialists functioning in a multi-site environment. A preferred, but non-limiting, embodiment of the present invention is herein disclosed with reference to figures 1 through 21 inclusive. The present invention also provides a computer readable medium of instructions for effecting the system and/or method. The invention encompasses process re-design as depicted in figures 2, 6 and 12 and underlying systematic support for the preferred process. The general design depicted in figure 1 shows the overall components. Figures 3.1 to 3.5, 7 and 13 show the systems support for the preferred process in a structure that demonstrates the tiers depicted in figure 1. An important aspect to an embodiment of the invention is the introduction of practice key performance indicators that are shown from a process perspective in figures 4, 11 and 14. The preferred system uses Internet and health standards to establish a model that enables business process outsourcing, an important feature in the health care industry.

From a general perspective the system comprises a database (figure 1 : data source layer). Data requests pass through the data access layer, if the data access layer deems access is allowed then the requested information returned to the browser (user presentation layer). Actions and the order of display of process steps within the user presentation layer are managed by the workflow logic layer. Each action is checked by the clinical and business logic layer to ensure rule compliance. A novel feature is the control provided by the clinical and business logic layer with the ability to manage within defined rules and encourage compliance by escalation due to inaction within predefined periods. A preferred, but non-limiting, embodiment in respect of each key process follows.

The various processes are accessed by the various 'roles' within a practice. The role of front desk performs process functions that support the specialist in pre and post clinical functions shown in figure 2. The practice manager role is one of control and monitoring the business. The present invention facilitates this by key performance indicators shown in figures 4, 11 and 14. The role of typist performs process functions shown in figure 12. The role of specialist medical doctor performs clinical functions a simplified representation of which is shown in figure 6.

The role of front desk (ie. reception) is supported in an embodiment of the invention as follows: With reference to figure 3.1, on commencement of the booking process caller information is collected (301). If the information contains a patient identification number information pertaining to that patient is retrieved (302 and 303) and presented for confirmation. Caller information is then stored (303) in a newly created booking record.

The workflow logic manager presents the clinicians and sites for the booking (304) based on the clinicians and sites to which the user has been granted access (305) and the clinician selected. The booking record is updated with the clinician and location information (306). The workflow manager displays appointment types and triage (307). If a procedure is selected gather the procedures performed by this specialist at the selected site (308) and store the selected type, triage and procedure (309). Select available appointments for specialists diary according to criteria sent and pass back to the browser. Display earliest appointments for each morning and afternoon session for each day of the week allowing the user to select the preferred day and AM/PM preference. Display appointments available for selected period (310). Provide a facility to select a suitable appointment, wait list the patient, force a booking, or refer to another clinician should those appointments not be satisfactory. If the patient is to be referred to another clinician check and apply referral rules. An internal referral 'loops back' through (307, 308, 309 and 310). A tentative booking is made in the clinicians diary.

If the workflow manager requires a patient identification number (following a check by the clinical and business logic layer (312) then allow entry of search criteria for patient (311) and store the selected patient against the booking record and set the booking from tentative to booked (313). If the workflow manager requires a referring doctor identifier (following a check by the clinical and business logic layer the referrer search page is presented and the database updated with the referrer identifier.

If the caller elects to complete registration forms the forms are displayed after first checking the components required by this specialist. Any changes are stored in the patient demographic database. In one, non-limiting, specific example the comprehensive registration forms include such data as religion or the like which may not be required by some specialists. System set-up parameters allow these segments to be bypassed using the workflow management layer. Display feedback on the booking and check for additional feedback items for the specialist and location selected. Store the fact that the information has been provided to the caller.

In another, non-limiting, specific example the location selected may have specific parking instructions, the specialist have specific billing requirements at that site and the procedure being carried out may require specific instructions such as fasting. If a quotation is required then the workflow manager displays the quotation information. Quick quote items are retrieved based on prior inputs and displayed in the browser. Billing rules are applied to the selected billing items and the quote stored in the database.

With reference to figure 3.2, the user selects the date and location for which to confirm bookings (315). Scheduled appointments are retrieved (316). All scheduled patients and contact information is displayed (317) such that the user can call the patient to confirm the booking. If accepted, confirmation logic is applied (318) and the booking status is updated to 'confirmed' (319). If cancelled, cancellation logic is applied (318) and the status is updated to 'cancelled' (319). For appointment slots vacated by cancellations allow selection from wait listed patients (320) following checking to which wait lists the user has access to. The vacated appointment is replaced with the one selected from the wait list (322).

With reference to figure 3.3, the user selects the date and location of clinics for which they require records (323), the business logic layer checks user permissions as to which clinics they are allowed to request records (324). Appointments lists, requesting sites and preferred modes of requesting records are gathered from the database (325) and returned to the browser (326). The user may modify the requesting method, if required (326). Rules for requesting records are carried out (327) according to selected criteria and requests are sent via the external parties interface (329) following the gathering of transmission requirements (330). Once requested the status is updated in the database (328). Once records arrive in the location they may be received into the systems (as a means of record tracking) (331) at which point the record received status is updated. With reference to figure 3.4, a list of specialists and locations is display (334) according to the permissions granted to the user (335). Clinician preferences for room set up are retrieved (336) and displayed (334).

With reference to figure 3.5, the user selects manage current waiting room option from the menu (337) and the user identification and location information is used (338) to retrieve current waiting room information (339). Detailed room information is gathered for each clinic (340) and the status of each aspect is interpreted (341) and passed to the browser for display (342).

When the specialist arrives, the user starts the clinic (343). The business logic layer gathers the clinic statistics for commencement of the clinic (344), stores it (345) and sends the statistics ID (344) back to browser. Modifications are stored in the database (350) and the new status displayed. Patients are 'received' into the waiting room at which point their arrival time and status is recorded and displayed. Non-scheduled patients may also be received into the waiting room. For each patient the status of registration information is displayed (346) and allows on-click access to print (349) and receive registration forms. Data 'refreshes' after each modification showing 'real-time' status. Modifications are stored in the database (350) and the new status displayed.

For each patient the status of pre-clinic measures is displayed (347). Clicking the status indicator displays those measures required by the clinician (349) prior to consultation and allows direct access to record measures. Any calculations required during the entry of measures are performed on entry (349) and displayed in the browser. Modifications are stored in the database (350) and the new status displayed. For each patient the status of consents is displayed (348). On-click access is provided to print (349) and receive consents. Modifications are stored in the database (350) and the new status displayed.

After the patient has seen the specialist a post clinic appointment can be made (351). As part of this process any rules input by clinician during consult (if any) are applied (352).

The information is passed to the database to retrieve available appointment dates for selection (353). Modifications are stored in the database (353) and the new status displayed. Typically payments would then be received for the consultation (354). The amount payable is determined following the application of billing rules either from quote and/or input by the clinician during the consultation (355). Apply rules for receiving payments of various types (355) and an invoice receipt printed (355). All changes are stored in the database (356). On completion of the clinic the clinic is finalised for the specialist (357) required post clinic statistics are gathered (358) and stored in the database (359). An end of clinic financial report is printed (358) and provided to the specialist with any monies received. Any rules such as 'did-not-attend' rules are auto- sent to the referring doctor via the external parties interface.

The role of clinical specialist is supported in an embodiment of the invention as follows: With reference to figure 7, the specialist logs into system and profile information is passed to the business logic layer (701). The clinicians workspace is opened with links to patient data. The entire workspace is opened as per figure 8. Prior to opening the system checks if the specialist currently has a clinic and requests clinic information from data source layer (702). Specialist patient lists are retrieved (703) and made available in the left frame of the browser (Figure 8: 810).

A patient is selected by one of the means in the left of the page (704 = fig 8: 810). On selection Patient information is retrieved (706) for 'each tab' (fig 8: 870) and passed back to the browser. Common data elements are sorted for display by the clinical logic layer (705). When a patient is selected all the following functions are activated and may be accessed in any sequence at any time after selection. Another feature is that an embodiment of the invention can provide multiple means of accessing similar functions for ease of use by the clinician. In addition the inputs are designed in a manner that the specialist may choose to what extent they wish to use the software/system. On selection key patient demographics (Fig 8: 830), current medications (Fig 8: 840), allergies and alerts (Fig 8: 850), and reminder status (Fig 8: 860) is displayed at all times. If any of these parameters are updated during the consultation the change is reflected (visually) immediately. Whenever a record is accessed the date, time and person accessing the record is recorded. If a modification is made, a pre and post modification 'snapshot' is taken and stored. This information is not accessible by any user of the system. The medical record overview (Fig 9) displays record access permission (Fig 9: 910), permission to participate in, for example, the NSW and Commonwealth electronic health record(Fig 9: 915), key reasons for treating the patient (Fig 9: 920), a summary of clinical events (Fig 9: 925) and 'sticky notes' (Fig 9: 930). In addition access is provided to histories within the record. These histories are aspects that have been recorded previously and include: Progress notes (Fig 9: 935); Medical history and problem list (Fig 9: 940); Family history (Fig 9: 945); Medications and allergies (Fig 9: 950); Social history and alerts (Fig 9: 955); Measures (Fig 9: 960); Tests (Fig 9: 965); Patient demographics (Fig 9: 970); Consents (Fig 8: 975), and; Interested parties (Fig 9: 980).

These features of this embodiment are described as: Record access permissions (Fig 9: 910) allows the specialist that owns the record to extend this access to another specialist or team for a limited period. The system promotes an 'opt-in' philosophy the feature in

Figure 9 915 allows the specialist to record whether the patient wishes to participate in the NSW electronic health record program, or other regional program. Information about the program is also available. The 'sticky notes' (Fig 9: 930) allows the specialist to record any non-clinical information that may be of interest and with a simple click delete items that are no longer relevant. In one, non-limiting, specific example of the use of the sticky note the specialist may record the fact that the patient was taking a holiday in June. The specialist may record the information such that it can be recalled as a discussion point to ease the stresses of the consultation or procedure. Once the information is no longer relevant it is removed.

Within the histories the follow features apply subject to security and access status of the record: The progress note (Fig 9: 935) lists all progress notes and allows modification of previous and addition of new notes. This may be added by the doctor or dictated for entry by the typist. The medical history and problem list (Fig 9: 940) lists and allows modification of previous and addition of new medical histories and problems. The family history (Fig 9: 945) lists and allows modification of previous and addition of new family histories. This embodiment includes the ability to click a family tree and condition lists for rapid recording. The medications and allergies (Fig 9: 950) lists and allows modification of previous and addition of new medications and allergies. The social history and alerts (Fig 9: 955) lists and allows, subject to security and access status, modification of previous and addition of new social histories and alerts. This embodiment includes the ability to rapidly record common social factors of smoking and alcohol consumption. The measures (Fig 9: 960) lists and allows recording of pre-clinic measures. The tests option (Fig 9: 965) lists tests ordered and their status. It allows graphical display of selected pathology analyses and the display of images from medical imaging. Interested parties (Fig 9: 980) lists and allows modification to any person or group interested in the case and whether they are to receive correspondence.

The preferred embodiment encompasses the following items that are presented as a preferred, but non-limiting, example of function available when a patient is selected. Any changes via these features are recorded in the database and subsequently appear in the appropriate section of the history described above.

The 'add note' method is a means of collecting clinical information in a very flexible format. The method supports: subjective, objective, assessment and plan consultation structure, 'progress note' format, simple contact recording (eg. Phone call, email or other). Supports the electronic health summary. Entry may be specifically tailored to the requirements of a clinical trial. When an entry is made the Clinical logic layer sorts input information to appropriate data target for storage. Security standards are applied to the record, as it is stored. Specific components are stored into the events and histories tables in the electronic medical record and summary information is stored.

The prescribe method allows prescriptions to be added or topped in the standard prescription structure or a quick format in the case of history. Pricing information on all drugs ordered is extracted, cross reactions checked and a physical prescription printed. The order details are recorded in the patients electronic health record as is the drug pricing. The information and consents tab contains a list of consents that may be selected and printed. In addition, information provided to patients including choices and risks is also entered. Requested information and consents are printed and recorded in the patients electronic medical record.

The principle diagnosis tab allows entry of the diagnosis via a graphical means whereby the specialist 'mouses-over' and area of the body, a list of aliments is presented in a popup menu style with sub-menus to select in more detail. Once selected the clinical logic layer encodes the diagnosis into ICD-10 code format and both the textual and codified versions of the principle diagnosis are stored in the patients electronic medical record.

The treatment reports tab provides access to treatment reports tailored to the specific specialty or clinical trial. The clinical logic as defined by the trial or specialist is applied and events triggered and information entered via the report is stored in the patients electronic medical record.

The specialist may enter a reminder that may be entered sent to the specialist themselves (self-reminder) or to any other person in the system. The reminder status is tracked and inaction alerted via the m-avert method. Reminder details are stored in the database.

The finalize consultation event tab provides sequenced events at the end of a consultation in a logical clinical flow. The events include: making a new appointment, Billing and dictation. These events are described as:

Make appointment: Allows selection of criteria to make an appointment but pass the task of actually scheduling the appointments to the front desk or actually creating the appointments for the patient at that point in time.

Billing: Allows viewing of intended billing policy for this patient and allows changes that are passed back to the front desk to actually receive payment.

Dictation: Provides a view of interested parties and the option to dictate now or later. The 'dictate now' option launches the electronic dictation system. The dictate later adds a reminder task for the specialist. When the reminder is clicked a summary of all actions taken during the consultation are displayed by way of reminder for the specialist while dictating.

A clinical trials module will be incorporated into the medical record. Study protocol data such as eligibility, investigation and treatment schedules, toxicity and response criteria can be held in a table and which can be cross-referenced with the patient's record. An 'eligibility alert' will be displayed on the clinical workspace if the patient is found eligible for the study. Appropriate Patient Information and consent forms can be printed off. Investigations and clinic visits for the clinical trial will be determined by the protocol. History, examination, adverse events and treatment records will be recorded and stored as per Figure 9. Research nurse can record entries in the progress notes. p_atient data can be de-identified and then made available for electronic transfer to an external clinical reporting form (CRF) made available by the monitoring company. Data transfer can be in the Clinical Data Interchange Standards (CDISC) format. Study monitors can review the CRF and patients electronic medical record before electronically transferring the CRF to the Trial Centre.

With reference to figure 10, the standard statistics include, but are not limited to:

• Patient Workload: Monthly patient numbers split by type and procedure.

• Casemix: Monthly report on the diagnoses of patients being seen including subspecialty codes • Diagnostic Tests: Monthly report in type of tests, turn arounds and value.

• Workload Statistics: Monthly patient numbers and average consultation durations.

• Ad-Hoc Contacts: Monthly numbers of non-scheduled contacts.

• Complications: Monthly numbers of complications following treatment.

The role of medical typist is supported in an embodiment of the invention as follows: The structure and design of the system facilitates outsourcing (optionally) of the medical typing processes. In this model the physical location of the typists is not a factor in the systems operation. This feature allows for business models where the specialist may still have access to medical typing services where they may not be able to justify the expense on their own. Similarly in another specific, but non-limiting, example a specialist seeking to establish a new practice could benefit from typing services they may otherwise not justify or want the additional distractions of hiring and managing staff. The electronic dictation system is an important feature of a particular embodiment of the invention. It manages voice input from a doctor and associates that with a patient.

With reference to figure 13, the typist enters the system and is presented with a list of all outstanding typing including originator, referring doctor, patient, priority, status, date and time dictated, length of dictation and status (1310). Double clicking the record opens the word processor and the dictation file. On opening the preferred template for that specialist is opened (1320) and data retrieved from the database populating pre-defined components of the template (1330). Typing status is updated and any request for clarification is sent to the business rules layer (1350) and on to the originating specialist (1340).

The originating specialist may listen to the dictation while viewing the typed information (1340). They may choose to complete the typing themselves or dictate the clarification. Rules are applied (1350) according to the action undertaken by the specialist. When typing is complete it is queued for final approval by the specialist. Typing status is updated and any changes to dictation or the letter or record entry are stored (1360). All completed work is sent to the specialist for approval (1370) before printing or storing in record. The specialist may accept or change the information including the recipients. Any changes are stored (1380) and the letter submitted to the business logic layer and to the external parties interface or in the case of record entry to the patients electronic medical record.

The role of practice manager is supported in an embodiment of the invention as follows: Again the structure and design of the system facilitates outsourcing (optionally) of the practice management function. In this model the physical location of the practice manager is not a factor in the systems operation. This feature allows for business models where the specialist may still have access to practice management services where they may not be able to justify the expense on their own. Similarly in another specific, but non-limiting, example a specialist seeking to establish a new practice could benefit from practice management services they may otherwise not justify or want the additional distractions of hiring and managing staff. In yet another, non-limiting, specific example practice groups may benefit by hiring fewer practice managers that have the ability to

10 monitor core processes and events across multiple site in a 'real-time' fashion. With reference to figure 5, the standard graphical representation allows scrolling access to 'next' , 'previous' , 'start' , or 'end' KPI graph.

The external parties interface absolute numbers and detailed status (Fig 5: 540) allow '5 viewing of hold-ups or potential problems in the external interface processes. The detail option allows the practice manager to see more information for an informed intervention. The absolute numbers at various stages of diagnostics orders/results (Fig 5 550). Provides a view on the status of diagnostic tests, the detail function allows specific patient instances to be viewed. Displaying contact information of the provider allows for ⁰ ease of contact of the provider. The absolute numbers at various stages of the medical typing process (Fig 5: 560) provide a view of workload and how the typing function is coping. The detail function allows specific patient instances to be viewed. The absolute numbers at various stages of the accounting process (Fig 5 : 570) provide a view of the accounting process, the detail function allows specific patient instances to be viewed. ⁵ The status of system reports manual or automatic (Fig 5: 580) allow the practice manager to monitor if tasks have been performed and intervene if necessary. The scrolling message of critical KPIs (Fig 5: 590) provide key information for maximising practice revenue and efficiency.

0 In a specific, non-limiting, example the number of appointment slots available in the next 'x' days may be scrolled. This may prompt action by the practice manager to have front desk staff use the waiting list function to fill the vacant appointment slots. Thus being pro-active in maximising the revenue event.

With reference to figure 4, included in the process controls for the pre-clinic and post- clinic work flows include:

Key performance indicator showing the extent to which bookings are optimised

(Fig 4: 400).

Key performance indicator showing the extent to which cancelled slots are filled from the waiting lists (Fig 4: 405).

Key performance indicator showing the extent to which records are available at the point of consultation (Fig 4: 410).

Key performance indicator showing the level of patient comfort (Fig 4: 415).

Key performance indicator showing the level of 'did-not-attends' (DNA) (Fig 4:

420).

Key performance indicator showing the level of 'booking efficiency' (Fig 4:

420).

Key performance indicator showing the level of 'accounting efficiency' (Fig 4:

425).

Key performance indicator showing the level of bad debts (Fig 4: 430).

A Controlling report on cancellation actions to ensure medico-legal aspects addressed (Fig 4: 440).

Financial report of daily controls including: receipts, banking, write-offs, reversals, and movements (Fig 4: 445).

Financial report of monthly controls including: receipts, banking, write-offs, reversals, and movements (Fig 4: 450).

Financial report of debtor controls: Aged trial balance and debtor index (Fig 4:

455).

Monthly marketing report: Top 20 referrers, for example, by volume and value;

Top 20 postcodes by volume and value; Bottom 10 referrers (Fig 4: 460).

With reference to figure 11, included in the process controls for the consultation work flows are: • Key performance indicator for diagnostic turnaround (each phased of process) (Fig 11: 1110).

• Key performance indicator showing relative performance/efficiency of medical typing function (Fig 11: 1120).

• Management information report on value of pathology, radiology and pharmaceutical orders by modality (Fig 11:1130).

With reference to figure 14, included in the process controls for the medical typing work flows are:

• Key performance indicator showing letter progress and turn-around (Fig 14: 1410).

• Key performance indicator showing typing error rates by specialist and by typist (Fig 14: 1420).

• Controlling report. Number of letters awaiting sign-off, printing or typing (Fig 14: 1430).

With reference to figure 16, the front desk/ reception staff select manage current waiting room option from the menu information is selected from the database based on the user profile and location and current waiting room information is retrieved from the database. The waiting room functions are the same as those in figure 3.5 and related commentary.

The Radiation oncology specialist uses the standard clinical functions (figures 6 to 10) with additional radiation oncology data collection. Within this embodiment the specialist may select a treatment plan for radiation oncology that may involve other aspects such as chemotherapy. Among other Radiation Oncology specific information the specialist would indicate whether the treatment requires a mould. The standard clinical rules described in figures 6 to 10 are applied and the consultation information stored in database.

Radiation Oncology services are queried to select available appointments slots that are displayed and may be selected to establish bookings. Treatment requirements are passed to the business logic layer and defined rules applied in retrieving the available slots. The booked appointment information is stored in the database. The waiting room may apply appropriate billing in the manner described in figure 3.5 and associated descriptions in addition Radiation Oncology specific billing may also be applied. These associate billings are processes using standard billing logic and billing data is stored in the database.

With reference to figure 16, mould room staff may view patients scheduled for moulds on the day selected via the 'mould waiting room' . A fitting date may be applied/altered and if the simulator is required at that time it may also be scheduled. Mould room status is recorded and a date input for fitting. The mould waiting room also displays patients for fitting. By clicking on the patient all previous work up information may be displayed. Clinical information is filtered such that only information required for the mould room processes is available and the mould status is updated. Simulation waiting room shows patient lists for the selected day. By clicking on the patient name relevant information can be displayed. Relevant clinical information is retrieved. Any updates to simulation data are stored making information available to the planning room. Patients awaiting planning are displayed. Planning information for the specialist may be recorded and business & clinical logic associated with planning applied. Planning information is stored in the database. The clinician reviews and signs-off the plan and creates a request for the treatment to be booked. The reception staff query outstanding treatment booking lists. Accelerator diaries are queried to provide booking dates and the selected booking dates are stored in the database and the patient notified. The application has the ability to book patients for daily radiotherapy excluding weekends and machine service days. Treatment occasions of service will be linked to standardised billing rules. The treatment room may check treatments. Any breaks in the treatment or 'did-not-attends' trigger action to specialist. Data related to treatments is stored and billing generated. At the completion of treatment, a standardised treatment summary will be generated, with the ability of the doctor to sign this off electronically. Standard QA statistics can be collected and standardised treatment QA can be recorded for each patient. The specialist may perform a review during the treatment phase and adjust treatment. Standard rules are applied to outputs from treatment review, letters generated and updates stored. With reference to figure 19, the initial chemotherapy booking is created (1910) as a series of bookings spaced according to the requirements of the protocol (1911) and may interact with orders for diagnostic services (1911), radiation oncology (figures 16 & 17) or surgery (figures 20 & 21). The series is requested (1911) from the database and suitable appointment slots returned (1912) from all calendars, appointments booked (1910) and the bookings saved to the database (1912).

The chemotherapy review group recalls all patients booked for chemotherapy that have not yet had write-up for their next administration of therapy (1913, 1914 & 1915). All relevant decision information is displayed (Weight, Height, BSA, Pathology results, tumour measures, toxicity information) (1913, 1914 & 1915) along with a standard chemotherapy medication chart (1913). The medications are formulated and notes taken by the group using (optionally) the clinical teaming workflow software (1913 & 1914). Updates via the interaction tool are stored to the database and the status is updated (1915).

The specialist writes up the prescription using the standard prescription writing software while viewing the medication chart information (1916). Internal checks may occur with the protocol (1917) and discrepancies alerted (1916). Prescription information is stored to the database and record status updated (1918).

The oncology pharmacist recalls the patient information and prescriptions for the selected clinic (1919, 1920 & 1921). Formulation tags (optional) may be printed (formulation tags contain a unique tag number - see chemotherapy nurse step) and applied to the syringes. Chemotherapy reception selects manage current waiting room option from the menu (1922) and the user identification and location information is used (1923) to retrieve current waiting room information (1924). Patients are 'received' into the waiting room at which point their arrival time and status is recorded and displayed. For each patient the status of pre-clinic measures is displayed (1922). Clicking the status indicator displays those measures required (1923) prior to administering of chemotherapy and allows direct access to record measures. Any calculations required during the entry of measures are performed on entry (1923) and displayed in the browser. Modifications are stored in the database (1924) and the new status displayed. Chemotherapy nurse selects manage current waiting room and receives a 'nursing view' (1925) including: medication formulations, formulation checking (record tag number which is crosschecked (1926), pathology results (1926 - if available), and administered formulation record. All entries are checked (1926) and stored in the database (1927). Any patients that failed to attend or have a 'not-completed' entry by the nurse are flagged as a protocol breach and alerted to the specialist for action.

The specialist accesses 'Post therapy' consultation information via the standard clinical module and applies chemotherapy information by selecting the 'post-chemotherapy' note type (1928). This note type allows entry of toxicity and tumour measures and allows changes to the planned therapy (1929 and 1930). If changes are made options to continue with the current schedule or re-schedule the protocol are allowed (1928, 1929, and 1930). Flags are then set and the process continues from the chemotherapy write-up stage until the protocol is complete, breached or the patient otherwise discharged.

Embodied in the prescribe function is a medication order for a medication is to be administered by a second party such as a nurse. The medication chart is a four-step procedure. Step one is the doctors order which incorporates prescribed drugs and includes the patient demographics and protocol names. Drugs are entered directly from the prescription field or typed manually by the doctor. Doses of medication must be added manually. A previous medication chart can be duplicated and then checked by the doctor. Selected investigation results are displayed. Step two allows a second party such as a pharmacist to check the drug order, send a query to the doctor if required and then confirms the order. Step three allows a second party such as a nurse to record that the medication has been administered. All steps are subject to security and access rights for each party. Each step allows comments to be manually added as a method of communication between health professionals regarding that patient. Step four is the completed medication chart that cannot be edited. The medication chart is stored in the patients electronic medical record and can be printed off for manual use. QA statistics can be reported each month by chemotherapy type, user and cost. With reference to figure 21, the surgeon accesses the system either via direct connection or mobile link (2110). After verification (2115) the theatre list is retrieved (2120), any standard rules for that specialist, location and operation combination are applied (2115) and the list presented (2110) to the surgeon. The surgeon may select any patient to record operation notes (2125) in a format preferred for that specialist, operation and location combination (2130). The surgeon may also select 'interested parties' (2125) to whom reports are to be sent (2130). Any changes are saved back to the database (2135), status updated and passed back to check for any 'clinical triggers' (2135). The view of the surgeon reflects the changes made (2125). The option (2140) is there for the report to be dictated rather than typed in which case it enters the standard typing process. Letters and reports may be signed off (2145) using the mobile clinician facility. Any rules will be applied (2150) and the database updated (2155).

It should be noted that the network as referenced in this specification should be taken to include all forms of connected or communicating computers or terminals having at least two terminals connected or communicating as hereinbefore described. That is, the term network should be taken to include any type of terminal as hereinbefore defined, computer, computerised device, peripheral computer equipment, computerised accessory, mobile or cellular phone, digital electronic device or other similar type of computerised electronic device or part thereof which is rendered such that it is capable of communicating with at least one of any of the aforementioned entities. Said communication of information or data can occur over any data communications network, computer network, wireless network, internetwork, intranetwork, local area network

(LAN), wide area network (WAN), the Internet and developments thereof, transient or temporary network, combinations of the above or any other type of network providing for computerised, electronic or digital devices.

Furthermore, references to the terms connecting, communicating, transmitting, requesting, receiving, exchanging and the like, and permutations thereof, as applied to the term computer network and/or components thereof should be taken to pertain to the transfer of information or data. Such transfers of information or data can be facilitated for by any form of entity /entities for facilitating such, including, but not limited to, metallic wires or cables, semi-conducting wires or cables, optical fibres and optical devices, wireless means, electromagnetic waves and the like and modulations thereof, acoustic waves and the like and modulations thereof, control of electric and/or magnetic fields, and/or the transportation of all forms of memory devices.

The invention may also be said broadly to consist in the parts, elements and features referred to or indicated in the specification of the application, individually or collectively, in any or all combinations of two or more of said parts, elements or features, and where specific integers are mentioned herein which have known equivalents in the art to which the invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth.

Although the preferred embodiment has been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein by one of ordinary skill in the art without departing from the scope of the present invention as hereinbefore described and as hereinafter claimed.

Claims

The claims:

1. A system for use in medical practice, the system able to facilitate a medical practitioner to work from multiple sites, the system including: a central server, the central server hosting a software application; a database, the database able to communicate with the software application and the database able to store or produce information or data in response to a request from the software application; at least one client terminal, the at least one client terminal able to communicate with the central server, the at least one client terminal used by the medical practitioner to access functions provided by the software application; whereby, the software application includes at least a user presentation layer, a network services layer, a clinical and business logic layer, and a data access layer for access to the database.

2. The system as claimed in claim 1, wherein more than one client terminal is provided, the client terminals residing at a different sites of the multiple sites.

3. The system as claimed in either claim 1 or claim 2, wherein more than one central server is provided.

4. The system as claimed in any one of the claims 1 to 3, wherein the software application includes an external parties interface layer and a workflow logic layer.

5. The system as claimed in any one of the claims 1 to 4, wherein the user presentation layer is facilitated by a Web browser.

6. The system as claimed in any one of the claims 1 to 5, wherein functions for multiple site booking, waiting room management, records collection management, or accounting functions are provided by the software application.

7. The system as claimed in any one of the claims 1 to 6, wherein functions for billing, back office, manager's dashboard, practice KPIs, clinical workspace, library and research, specialists lounge or education are provided by the software application.

8. The system as claimed in any one of the claims 1 to 7, wherein a medical typing function is provided by the software application.

9. The system as claimed in claim 8, wherein a medical typist has access to the software application via a client terminal.

10. The system as claimed in any one of the claims 1 to 9, wherein the software application is accessible via the Internet.

11. The system as claimed in any one of the claims 1 to 10, wherein the client terminal is a portable device able to be carried by the medical practitioner.

12. The system as claimed in any one of the claims 1 to 11, wherein a dictation database is provided which stores dictation made by the medical practitioner.

13. A computer readable medium of instructions residing on a host server, a user able to access functions provided by the computer readable medium of instructions from one of a plurality of remote client terminals, the computer readable medium of instructions for use in assisting in the management of a medical practice and including procedures for: allowing the user to remotely access a database of information via one of the client terminals; providing the user with access to clinical functions; and providing the user with access to non-clinical functions.

14. The computer readable medium of instructions as claimed in claim 13, wherein the clinical functions include patient records, clinical contact event recording, resource access, order entry, receipt of results, medical typing or specialist specific requirements.

15. The computer readable medium of instructions as claimed in either claim 13 or claim 14, wherein the non-clinical functions include key performance indicators, internal action requests or clinical cost tracking.

16. The computer readable medium of instructions as claimed in any one of the claims 13 to 15, wherein there is provided a front desk module, a practice manager module, a clinical module and a typing module.

17. The computer readable medium of instructions as claimed in any one of the claims 13 to 16, wherein the user is able to record dictation which is then accessible by a typist from a client terminal.

18. An Internet based software application which resides on a host server, the functions provided by the software application able to be accessed from a Web browser which resides on a remote terminal, the software application for use in assisting to manage a medical practitioner's practice, the software application providing an integrated interface to: front desk functions; practice manager functions; clinical functions; and medical typing functions.

19. The software application as claimed in claim 18, wherein the practice is a multi- site practice.

20. The software application as claimed in claim 18 or claim 19, wherein data transmissions over the Internet are encrypted.

21. The software application as claimed in any one of the claims 18 to 20, wherein the software application functions include any of the following functions: booking, waiting room, billing, back-office, practice manager, manager's dashboard, practice KPIs, medical typing, clinical, clinical workspace, library and research, specialists lounge, education, mobile facility, user presentation layer, workflow logic layer, clinical and business logic layer, external parties interface, interested parties, government body, medical registers, diagnostics, pharmaceutical companies, insurance, data access layer, medical record access security, or data source layer.

22. A method for use by a medical practitioner to assist in providing medical services to a patient, the method assisting the medical practitioner to work from multiple sites, the method including the steps of: the medical practitioner logging into a network based management software application; profile information for the medical practitioner being passed to the management software application; the management software application retrieving and displaying patient lists to the medical practitioner; the medical practitioner selecting a particular patient record from the displayed list, the medical practitioner thereby able to retrieve medical information pertaining to the selected patient from a database associated with the management software application; the medical practitioner able to update the medical information in the patient record on the database.

23. The method as claimed in claim 22, wherein the medical information includes demographic information, current medications, allergies or alerts, and reminder status information.

24. The method as claimed in either claim 22 or claim 23, wherein when the patient record is accessed, the date, time and person accessing the record is recorded.

25. The method as claimed in any one of the claims 22 to 24, wherein the medical information displays patient record access permission, patient eligibility to participate in Government health programs, key reasons for treating the patient, and/or a summary of clinical events.

26. The method as claimed in any one of the claims 22 to 25, wherein the patient record includes patient history information.

27. The method as claimed in claim 26, wherein the patient history information includes information relating to progress notes, medical history or problem list, family history, medications or allergies, social history and alerts, measures, tests, patient demographics, consents, and/or interested parties.

28. The method as claimed in any one of the claims 22 to 27, wherein the medical practitioner is a medical doctor, medical specialist, surgeon, clinician, or the like.

29. The method as claimed in any one of the claims 22 to 28, wherein the management software application provides the medical practitioner with appointment, billing or dictation functions.

30. The method as claimed in any one of the claims 22 to 29, wherein a typist is able to access the management software application and is presented with a list of outstanding dictation files, the typist being able to open a dictation file.

31. The method as claimed in any one of the claims 22 to 30, wherein practice management functions are provided by the management software application.

32. The method as claimed in any one of the claims 22 to 31, wherein front desk functions are provided by the management software application.

33. A method for use by a medical practice manager to assist in providing medical services to a patient, the method assisting the medical practice manager to work from a site remote to the medical practice, the method including the steps of: the medical practice manager logging into a network based management software application from a terminal remote to a server hosting the management software application; the management software application retrieving and displaying medical practice information to the medical practice manager; the medical practice information including key performance indicators pertaining to the routine functioning of the medical practice.

34. The method as claimed in claim 33, wherein a function of the management software application allows information specific to a patient to be reviewed.

35. The method as claimed in either claim 33 or claim 34, wherein a key performance indicator (KPI) provides: indications on the extent to which patient bookings are optimised; indications on the extent to which cancelled appointments are filled from waiting lists; indications on the extent to which records are available at the point of consultation; indications on the level of appointment booking efficiency; indications on the level of accounting efficiency; or indications on the level of bad debts.

36. The method as claimed in any one of the claims 33 to 35, wherein financial reports are generated by the management software application.

37. A method for use by a medical practice receptionist to assist in providing medical services to a patient at a medical practice, the method including the steps of: the medical practice receptionist logging into a network based management software application from a terminal remote to a server hosting the management software application; a patient requesting an appointment from the medical practice receptionist; the management software application displaying a booking software tool to the medical practice receptionist; the medical practice receptionist entering patient details into the management software application; the booking software tool presenting medical practitioners and medical practice sites available to the patient; an appointment being made for the patient; at the time of the appointment the medical practice receptionist starting a clinic function of the management software application; and on completion of the clinic post clinic statistics are stored in a database and an end of clinic financial report is generated.

38. The method as claimed in claim 37, wherein the booking software tool is a workflow manager.

39. The method as claimed in either claim 37 or 38, wherein the booking software tool requires a patient identification number.

40. The method as claimed in any one of the claims 37 to 39, wherein the booking software tool requires a referring doctor identifier.

41. The method as claimed in any one of the claims 37 to 40, wherein a billing quote is stored in a database accessible by the management software application.

42. The method as claimed in any one of the claims 37 to 41, wherein appointments vacated by cancellations are filled by selection from wait listed patients.

43. The method as claimed in any one of the claims 37 to 42, wherein medical practitioner preferences for clinic room set up are retrieved and displayed to the medical practice receptionist.

44. The method as claimed in any one of the claims 22 to 36, wherein the method facilitates business process outsourcing.