WO2017205938A1

WO2017205938A1 - Systems and methods for patient referral

Info

Publication number: WO2017205938A1
Application number: PCT/AU2017/050542
Authority: WO
Inventors: Peter DEMAIO
Original assignee: Automed Kiosk Pty Ltd
Priority date: 2016-06-03
Filing date: 2017-06-03
Publication date: 2017-12-07
Also published as: AU2017274577A1

Abstract

The present invention provides a system for communicating a referral document from a first health care service provider to a second healthcare service provider, the system comprising : a first computer of a health care referrer, the first computer having a database comprising information on a plurality of patients, the first computer configured to generate and transmit patient-specific referral information, a second computer of a health care referral recipient, the second computer having a database comprising information on a plurality of patients, and a third computer of a coordinating entity in operable communication with the first and second computers, the server configured to receive and store the patient-specific referral information transmitted by the first computer and permit importation of the patient-specific referral information into the database of the second computer.

Description

SYSTEMS AND METHODS FOR PATIENT REFERRAL

FIELD OF THE INVENTION

The present invention relates to the field of the electronic management of patients across two or more healthcare providers. In particular, the invention relates to systems and methods for electronic communication between two participants in a healthcare system.

BACKGROUND TO THE INVENTION

For many reasons, a doctor (or other primary care professional) may wish to refer a patient to another health care provider. For example, it is common for a general practitioner to refer a patient to a specialist medical practitioner for further investigation. As another example, the referral may be to a pathology or radiology provider for a diagnostic test or procedure. Another type of referral is to a pharmacist for the supply of medication. Currently, the referring doctor generates a paper referral document during the patient consultation. The referral document is handed to the patient who then travels to the referral recipient which then accepts the referral document from the patient and provides the required services or goods. There are number of problems with this arrangement. Firstly, dishonest patients are able to generate fraudulent referral documents (and especially prescriptions for controlled medicines), or to at least alter a document.

In many cases, data from the referral document must be manually entered into a computer system of the referral recipient leading to the need for further work and the propensity for the introduction of transcription errors.

As well as referring patients, a doctor may be required to receive communications from a referral recipient. For example, where the referral recipient is a pathology provider the doctor will expect to receive a communication detailing test results of the referred patient. Alternatively, a referral recipient who is a medical specialist may wish to communicate a diagnosis and recommendations for treatment to the referrer. Again, such communications are typically paper-based and require entry into the practice management system of the doctor's practice. It is not uncommon for such communications to be lost or go missing, requiring chase up telephone calls to retrieve results. The prior art provides a multitude of different software packages for use by in the health care sector to manage patients within the clinic environment. More often than not, the package used by a referring practice is different to that used by a referral recipient practice. Most the systems used in general practice clinics have evolved over many years and do not comply with any attempt at software integration. There is no clear financial benefit for a general practice to integrate its software system with that of a specialist who receive referrals from that general practice.

It is an aspect of the present invention to overcome or alleviate a problem of the prior art by providing improved systems and methods for communication between various health care providers. It is a further aspect of the invention to provide an alternative to current methods for communication between various health care providers.

The discussion of documents, acts, materials, devices, articles and the like is included in this specification solely for the purpose of providing a context for the present invention. It is not suggested or represented that any or all of these matters formed part of the prior art base or were common general knowledge in the field relevant to the present invention as it existed before the priority date of each provisional claim of this application.

SUMMARY OF THE INVENTION

In one aspect, but not necessarily the broadest aspect the present invention provides a system for communicating a referral document from a first health care service provider to a second health care service provider, the system comprising: a first computer of a health care referrer, the first computer having a database comprising information on a plurality of patients, the first computer configured to generate and transmit patient-specific referral information, a second computer of a health care referral recipient, the second computer having a database comprising information on a plurality of patients, and a third computer of a coordinating entity in operable communication with the first and second computers, the server configured to receive and store the patient-specific referral information transmitted by the first computer and permit importation of the patient-specific referral information into the database of the second computer.

In one embodiment of the first aspect, the system comprises a plurality of first computers, and a plurality of second computers, the patient-specific referral information comprising information to identify the referral recipient, the system configured to permit access to the patient-specific information only by the referral recipient identified by the patient-specific referral information.

In one embodiment of the first aspect, the patient-specific referral information is encrypted so as to be accessible only by the second computer.

In one embodiment of the first aspect, the patient-specific referral information has an associated encryption key. In one embodiment of the first aspect, the encryption key is a public encryption key specific to a referral recipient.

In one embodiment of the first aspect, the system comprises means for classifying the patient- specific referral information into one or more data types.

In one embodiment of the first aspect, the means for classifying the patient-specific referral information into one or more data types is a template.

In one embodiment of the first aspect, the means for classifying the patient-specific referral information into one or more data types is a protocol embodied in software of the first computer and/or the second computer and/or the third computer.

In one embodiment of the first aspect, the protocol is implemented by way of an application programming interface (API) or an application binary interface (ABI).

In one embodiment of the first aspect, the first computer comprises virtual printer software configured to transmit patient-specific referral information, and/or the second computer comprises virtual printer software configured to transmit patient-specific report information. In one embodiment of the first aspect, the patient-specific referral information and/or report information is provided so as to conform to an industry standard.

In one embodiment of the first aspect, the industry standard is Health Level 7 or equivalent. In one embodiment of the first aspect, the protocol is configured to provide patient-specific referral information so as to conform with a structure of the database of the second computer. In one embodiment of the first aspect, the system is configured so as to allow transmission of patient-specific referral information from the second computer to the first computer via the third computer. In one embodiment of the first aspect, the protocol is configured to provide patient-specific referral information so as to conform with a structure of the database of the first computer.

In one embodiment of the first aspect, the patient-specific referral information comprises work flow information, or invokes a workflow.

In one embodiment of the first aspect, the workflow information comprises a computer- readable instruction or a human readable instructions.

In one embodiment of the first aspect, the workflow information defines a series of steps involved in provide a patient or a referring doctor with information or a good or a service defined in the patient-specific referral information.

In one embodiment of the first aspect, the workflow information defines a step of instructing the server or the second computer to transmit an electronic communication to a patient.

In one embodiment of the first aspect, the electronic communication provides means for a patient to book an appointment for the referral recipient.

In one embodiment of the first aspect, the workflow information defines a consultation, a service, a procedure, a good, a report generation, or a report transmission.

In one embodiment of the first aspect, the system comprises an automated check-in kiosk at a premises of a referral recipient. In one embodiment of the first aspect, the kiosk comprises means for scanning a hard copy referral document

In one embodiment of the first aspect, the system comprises electronic means for a patient to book an appointment for the referral recipient, and an automated check-in kiosk at a premises of a referral recipient configured so as to allow the patient to check-in about the appointment time. In one embodiment of the first aspect, the referrer is a general medical practice or other primary healthcare practice, and the referral recipient is selected from the group including a medical specialist practice, a pathology practice, a radiology practice, a pharmacy, and an allied health practice.

In a second aspect, the present invention provides a method for referring a patient to a referral recipient, the method comprising the steps of: providing the system of the first aspect, or any embodiment of the first aspect, generating patient-specific referral information on the first computer, and transmitting the patient-specific referral information from the first computer to the second computer via the computer.

In one embodiment of the second aspect, the method comprises the step of providing a public encryption key to securely encrypt the patient-specific referral information before transmission. In one embodiment of the second aspect, the method comprises the step of providing a private encryption key so as to allow access to the patient-specific referral information after transmission.

In one embodiment of the second aspect, the method comprises the step of invoking a work flow so as to facilitate the provision of a good, a service or information to the referrer or the referral recipient.

In one embodiment of the second aspect, the method comprises the step of the referrer and or patient receiving a good, a service or information from the referral recipient.

In a third aspect, the present invention provides an electronic template for referring a patient to a referral recipient, the template comprising (i) one or more fields configured to contain patient-specific information and (ii) a public encryption key associated with a referral recipient. In a fourth aspect, the present invention provides computer executable virtual printer software configured to capture patient-specific referral information.

In one embodiment of the fourth aspect, the patient-specific referral information is in an industry standard format.

In one embodiment of the fourth aspect, the industry-standard software is HL7 or equivalent. In a fifth aspect the present invention provides a system for communicating a referral document from a first health care service provider to a second health care service provider, the system comprising: a first computer of a health care referrer, the first computer having a database comprising information on a plurality of patients, the first computer configured to generate and transmit patient-specific referral information, and computer executable virtual printer software configured to capture the patient-specific referral information.

BRIEF DESCRIPTION OF THE DRAWING FIG. 1 is a schematic diagram of a preferred embodiment of the present system.

FIG. 2 is diagram showing a process flow of a referral document printing process in a preferred embodiment of the system. FIG. 3 is a diagram showing a process flow of a computer in receipt of the referral document in a preferred embodiment of the system.

FIG. 4 is a diagram showing a work flow in a preferred embodiment of the system.

DETAILED DESCRIPTION OF THE INVENTION

After considering this description it will be apparent to one skilled in the art how the invention is implemented in various alternative embodiments and alternative applications. However, although various embodiments of the present invention will be described herein, it is understood that these embodiments are presented by way of example only, and not limitation. As such, this description of various alternative embodiments should not be construed to limit the scope or breadth of the present invention. Furthermore, statements of advantages or other aspects apply to specific exemplary embodiments, and not necessarily to all embodiments covered by the claims.

Throughout the description and the claims of this specification the word "comprise" and variations of the word, such as "comprising" and "comprises" is not intended to exclude other additives, components, integers or steps. Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may.

It is not represented that all embodiments of the invention have all advantages disclosed herein. Some embodiments may have a single advantage while other embodiments may have no advantage and are merely useful alternatives to the prior art.

In a first aspect, the present invention provides a system for communicating a referral document from a first health care service provider to a second care health service provider, the system comprising: a first computer of a health care referrer, the first computer having a database comprising information on a plurality of patients, the first computer configured to generate and transmit patient-specific referral information, a second computer of a health care referral recipient, the second computer having a database comprising information on a plurality of patients, and a third computer of a coordinating entity in operable communication with the first and second computers, the server configured to receive and store the patient-specific referral information transmitted by the first computer and permit importation of the patient- specific referral information into the database of the second computer.

Applicant proposes that use of a central server configured to interchange patient-specific referral information provides advantage in the art of communications between healthcare providers. The central server is able to provide, for example, a secure "mailbox" arrangement such that patient information is accessible only by the intended referral recipient. Another advantage is that the server may facilitate the interchange of data between practice management systems of a referrer and referral recipient. Moreover, the server may coordinate the workflows of the referrer and/or the referral recipient.

In the context of the invention as described herein the first computer is a computer of a health care referrer. Typically, the referrer is a general medical practice or other primary care practice. Such practices have a constant need to refer patients to other health care providers. The referral recipient may be a medical specialist practice (such as a physician or a surgeon practice). Such practices rely on the referral of patients from primary care practices.

The term "computer" as used herein may refer to a single computer, or to two or more computers which are interconnected. Many health care practices comprises a number of practitioners, with each practitioner having a computer acting as a client in a client/server system. In many configurations, the server comprises the patient database, billing software, appointment software, referral letter generating software, prescription generating software and the like (often referred to collectively as "practice management software") with the client computers merely transmitting/receiving data to/from the server. Some practices may have a single practitioner and a single computer, with the single computer performing both the client/server functions of larger practices.

In the present invention, the first computer is configured to generate and transmit patient- specific referral information. As used herein, the term patient-specific referral information may include any information pertaining to a patient that is useful to the referral recipient (and optionally information useful to other parties). The information may include any one or more of patient name, patient age, patient date of birth, patient address, patient health insurance details, patient social security number. The information may further include short or long notes on the patient's clinical history as relevant to the reason for referral (such as present and past symptoms and any pathology results), and a possible diagnosis. The information will typically include a request for action on the part of the referral recipient. For example, the referral information may simply request further investigation of the patient and optionally return of a written report. More specific requests may be included, typically where the referral recipient is a pathology service or a radiology service. In such cases, a specific test or procedure may be defined in the patient-specific referral information. Where the referral recipient is a pharmacy, the patient-specific information may comprise a request to supply a certain medication to the patient subject of the referral.

The patient-specific referral information may be entered into the first computer by the practitioner preparing the referral. In some embodiments, the system is configured so as to provide a number of electronic templates for completion by the referring practitioner on his/her computer. Many fields in the template may be prepopulated by basic information already stored in the patient database such as patient name, age, sex, Medicare number, address, telephone number and the like. The template may provide for selection of a request from a range of possible requests such as "review", "cardiac function test", and "biopsy". A selection of very specific requests may be provided for in the template such as "measles virus antibody test", "cerebrospinal fluid cytology" and "thrombin time".

Another field of the template may be a text box into which the referring practitioner may freely type notes. For example, the practitioner may write "patient has type 1 diabetes with history of poor, hence query macular degeneration". In the context of the present system, the patient-specific referral information must be routed to the second computer (being the computer of the referral recipient). Accordingly, the referral information may be associated with routing information. In some embodiments, the referral information is actively routed only to the third computer where it remains in a virtual "mailbox" until retrieval by the second computer.

Advantageously, the referral information may be associated with an encryption key. The encryption key may be a public encryption key for the referral recipient. In that regard, the encryption key may perform the function of securing the referral information and also identifying the referral recipient. The system may be configured so as to route all referral information to the third computer, then once received by the third computer the referral information is stored in a virtual mailbox. The referral information is accessible only by use of the private key associated with the public key, and as available only to the referral recipient. Thus, the means of transmission of the referral information may be caused by the combined functions of the first, second and third computers.

In one embodiment, the present system comprises means for classifying the patient-specific referral information into one or more data types. The aim of such classification is to allow for the automatic insertion of certain data into the database of the second computer. For example, the data types may be name one or more of: patient name, patient address, patient Medicare number. Such datatypes may be automatically detected by means known to the skilled artisan. Patient name may be assumed to be the string of characters following the characters "Mr.", "Mrs." or Ms." Patient address may be taken to be the string of characters surrounding any of the characters "Street", "Road", "Avenue" or "Court". The Medicare number may be taken as any string of 1 1 numerical characters having a valid checksum digit in the ninth position.

In the present system the means for classifying the patient-specific referral information into one or more data types may be embodied in software-based algorithmic form on either the first computer or the third computer.

As will be appreciated, while generally operable such strategies of identifying datatypes are prone to error. Alternatively, the use of templates is preferred such that address data is entered into an address field of a template. A template may be a general template that is likely to be generally acceptable to one or more referral recipients. Where the referral is to a specialist physician, a general template having patient details (name, address etc) and a text window for entering free text) may be useful. In other embodiments, the template is specific to a certain referral recipient. Thus, the referral recipient may design a template to ensure that all necessary information required for efficient operation of its business is included. Where the referral recipient is a urologist, for example, the template may include a mandatory field for prostate serum albumin level, and any family history of prostate cancer.

The template may have internal validation mechanisms to prevent entry of incorrect data. The patient-specific referral information may be transmitted as unstructured information (albeit with data classified in datatypes) or in a structured form such as a readable document.

In a preferred embodiment of the system, the first computer at least comprises virtual printer software configured to allow patient-specific referral information is transmitted from the first computer by way of a virtual printer. In such embodiments, the doctor may prepare a referral letter that is the same, or similar to a prior art referral letter and "print" the letter via a virtual printer. An advantage of this embodiment of the system is that virtual printer software is relatively simple software which may be coded to be executable on a range of computer types and across various operating systems. Thus, the computer systems of many and varied healthcare providers will be capable of participating in the present system with the incorporation of a virtual printer software on a computer. Thus, by the present invention a doctor may refer a patient electronically using a legacy printer interface without impacting on the existing hardware/software systems of the practice. Moreover, virtual printing is very simple for a user (such as a referring doctor) to implement in everyday practice. To transmit a referral letter via the present system to a referral recipient, the user only need perform a simple "file > print" and then select the virtual printer of the present system in order to transmit the patient specific referral information to the third computer. Such actions are well known to even a person with little experience in computer operation. Thus, minimal training of personnel is required in implementing the present system.

Given the benefit of the present specification, the skilled person will be enabled to provide virtual printer software useful in the context of the present invention. Such software may be based on, or a modification of, prior art virtual printer software such as Ghostscript, RedMon, CC PDF Converter, cups-PDF, Microsoft XPS Document Writer, DoPDF, PDFCreator, PrimoPDF, Microsoft Office Document Image Writer, NovaPDF, Print&Share, Universal Document Converter and the like. Some virtual printer software has associated software development kits (SDK) which allows for customization so as to achieve the transmission of patient-specific referral data to the third computer. As one example "printer⁺⁺" is a Windows virtual printer that allows printing from many applications (such as Microsoft Word) with the output customizable to specific needs.

In terms of executable steps, a virtual printing task typically includes the following steps:

The user prints a document to the virtual printer from any application.

The virtual printer intercepts the print job and saves each printed page as EMF file.

The virtual printer converts EMF files to specified output formats. All files are saved in the current user temporary directory or specified output directory.

The virtual printer creates an INI file with print job information and paths to the generated files.

The virtual printer sends the path of this INI file to a specified application using one of following transfer modes:

Command line transfer mode. The virtual printer will run the specified application with the path of the INI file in the command line parameters.

WM COPYDATA transfer mode. The printer runs the specified application (or looks for a running instance) and sends it the path of the INI file using a WM COPYDATA message.

- Clipboard transfer mode. (This is obsolete and intended for legacy applications.) The printer runs the specified application (or looks for a running instance), puts the path of the INI file on the clipboard and notifies the application.

The required application receives the INI file and parses it.

In one embodiment, the system is configured such that the virtual printer is resident on or in operable communication with the third computer such that the patient-specific information is transmitted to the third computer over the Internet. This is similar to printing on a local port except that the address is a URL. For example, on the first computer the referral document is printed by the client application (such as Microsoft Word or Adobe Acrobat) with the virtual printer software invoking an HTTP call over the Internet to a print server spooler of the second computer. As will be appreciated, such process may be reliant on the Internet Printing Protocol (IPP). This protocol may be used advantageously in the present system by virtue of its support for access control, authentication, and encryption, making it a more capable and secure means of data transmission. In some embodiments of the system, at least two computers provide or interchange referral information via an industry standard protocol. In such circumstances, it will be understood that an API configured for information interchange may be unnecessary. As an example, the present system incorporate the Health Level 7 (HL7) standards (Health Level Seven International, Ann Arbor, Ml). These standards define how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. As defined under HL7 Version 2.7 Standard, Chapter 1 1 defines the message set used in patient referral communications between mutually exclusive healthcare entities. Such transactions may traverse a path connecting primary care providers, specialists, payors, government agencies, hospitals, labs, and other healthcare entities. The chapter describes the various events and resulting transactions that make up the referral message set. When a patient is referred by one healthcare entity (e.g., a primary care provider) to another (e.g., a specialist or lab) or when a patient inquiry is made between two separate entities, little is known about the information each party requires to identify or codify the patient. The receiving entity may have no knowledge of the patient and may require a full set of demographics, subscriber and billing information, eligibility/coverage information, pre-authorization information, and/or clinical data to process the referral. If the receiving entity already has a record of the patient, the precise requirements for identifying that patient record will vary greatly from one entity to another. The existing record of a patient residing in the database of a specialist, a lab, or a hospital may require updating with more current information. In addition, providers receiving a referral often require detailed information about the provider making the referral, such as a physician's name and address. The message set that encompasses these transactions includes the referral, requests for information, and the returned patient information. The referral message originates a transaction and a return patient information message concludes the transaction.

The present system may require that any patient-specific referral information complies with a standard for information interchange such as HL7.

In one embodiment, the system embodies a protocol to allow for patient-specific information (however classified or transmitted) to be saved into an appropriate field in the database of the second computer. The present systems may be configured such that a communication from the second computer is transmitted to the first computer. This would be required where a referral recipient (having a second computer according to the invention) wishes to transmit a report on a referred patient back to the referrer (having a first computer according to the invention). Thus, the first computer becomes the second computer and the second computer becomes the first computer. Similar considerations may apply such as the use of templates for generation of a referral recipient report so as to classify data according to certain datatypes so as to conform with a patient database structure of the referrer. For example, the template may comprise the fields "test results", "diagnosis", and "recommendations" so as to accord with the referrers requirements. Alternatively, the report may be sent as a simple PDF for entry into the patient's electronic history file. The present system may comprise an application programming interface (API) or an application binary interface (ABI) resident on any one or more of the first compute, the second computer or the third computer. Typically, at least the first computer comprises an API/ABI configured to implement a data interchange protocol configured to facilitate to efficient and dependable transfer of data from the first computer to the second computer (and optionally vice versa), or from the first computer to the third computer (and optionally vice versa), or from the third computer to the second computer (and optionally vice versa), o enable the exchange of information among systems that use different technologies, when an API implements a protocol, it can prescribe a language-neutral message format: e.g. SOAP uses XML as a general container for the messages to be exchanged, similarly REST API can use both XML and JSON.

Typically, an API is configured for use with a practice management software of the type used by a medical practice or other healthcare service provider. Thus, in some embodiments the present systems are incorporated so as to integrate with, overlay or otherwise form operable communications with prior-art computer systems and software of a medical practice. Exemplary prior art medical practice software and systems include: prognoCIS, NueMD, Office Practicum, Kareo, WRS Health, MediTouch PM, Chirotouch, Electronic Medical Assistant, Velocidoc, WebPT, ADP AdvanceMD, ECLIPSE, PT Practice Pro, Nextech, Centricity, CareCloud Central, qualifacts, praxis EMR, Greenway, eClinicalWorks, ACOM Health RAPID, athenaClinicals, iO Practiceware, IntelleChart, The Digital Office, iSALUS EHR, MDCOnnection, TotalMD, PayDC, A.l.med, ChartLogic EHR Suite, CureMD, Therabill and iDoc, coreplus, boxtech, Shexie, Stat Health, Genie, Pracsoft, Medical Director, Jayex products such Enlighten, and Practix. Where the referral recipient is a large corporate entity (such as a national pathology provider) the API may be configured to integrate with enterprise level software. The API may be configured so as to be operable in extracting information or entering information into a physical database that is ordinarily in place in a medical practice (such as any of those database structures used by the aforementioned medical practice software). Medical practices typically obtain and retain patient data such as name, address, date of birth, email address, billing information and the like. Some practice also incorporate computer- based patient histories, accounting and appointment management software. Thus, in some embodiments the present systems are incorporated so as to integrate with, overlay or otherwise form operable communications with prior-art computer systems and software of a medical practice.

The present systems may be useful for facilitating workflows in simple or complex task sets resulting from the referral of a patient. One type of workflow relates to the need for a patient to make an appointment with the referrer. Typically, the patient must attend for consultation/examination, or for a test procedure to be carried out, or for a biological sample to be taken. The referral recipient will typically have its own appointment scheduling which cannot be accessed by the referrer hence the need for a patient to independently contact the referral recipient. In some cases, the patient will simply neglect to make the appointment or will at least have trouble making the appointment. Accordingly, the present system may be configured such that an electronic communication is automatically transmitted to the patient when the referrer transmits the patient-specific referral information into the system.

The communication may originate from either the second or third computer, and may have an embedded link which directs the patient to an appointment making facility. In one embodiment, the communication is transmitted to the patient's smartphone by way of email or SMS messaging and includes a link to a web page allowing for available appointments to be viewed and for any appointment to be made. In another embodiment, a link to a telephone number is provided allowing the patient to confer with an appointment clerk to settle the appointment. There may be further configuration allowing for reminder communications to be sent to the patient to lessen the probability that an appointment is missed.

The system may comprise a patient self-check in kiosk, which is typically in operable connection to the second computer. Thus, upon arrival the patient may enter his/her name or scan a Medicare card so as to be recognisable to the second computer. The second computer will have already stored details of the patient (by way of the patient-specific referral information), and also the appointment date and time (by way of the appointment made earlier by the patient) thereby facilitating the self-check in process. Once the patient is recognised and his/her details identified by reference to stored details, the system may be configured to retrieve referral information relating to (i) the patient and (ii) the patient's scheduled appointment on the day that the patient presents at the kiosk. In particular, the kiosk may display via a user interface any referral information stored by the system, and the patient is permitted by the user interface to verify that the referral information relates to (i) him/her (i.e. the patient) and (ii) the reason for his/her visit to the referral recipient on that day. The referral information may be presented in tabulated or point from for ease of comprehension by the patient, or may be presented in the form of a copy of the referral letter issued by the referrer.

In some embodiments of the system, a kiosk is provided (which may be the same kiosk discussed immediately supra, or may be a different kiosk) configured to process a hard copy referral document. The kiosk is typically disposed about an entry or reception area of the referral recipient premises. The kiosk may be configured with a document scanner of the kind known to the skilled artisan, with the patient being prompted by a sign or an electronic user interface to insert or otherwise provide the referral document for scanning. The scanner is configured to output an electronic image file which is subsequently processed by optical character recognition software which may be executed by a processor of the kiosk or by another computer.

In some embodiments, the scanned referral document as presented by the patient at the kiosk is processed by software means to remove extraneous elements such as letterhead, footer, signature, any graphical elements, and the like. The removal of such elements may facilitate the extraction of relevant text by any optical character recognition software.

Typically, the scanned referral document is stored by the system in linked association with the patient's details in the form of an image file. In addition or alternatively, information extracted from the referral document via optical character recognition means is stored in linked association with the patient's details.

In some circumstances, the patient attends the referral recipient premises without an appointment. This is not uncommon where the patient has been referred to a pathology practice for the purpose of giving a biological sample (such as a blood sample) for subsequent analysis. In that case, the patient may present the pathology request form issued by the referring doctor at a kiosk in the pathology practice. The request form is scanned and stored in the system (as an image file and/or extracted information), and may be accessed and viewed by a staff member at the pathology practice. Any transmission and/or storage of referral information or referral document image file occur firstly to a third party coordinating entity server (that server being in operable communication with the kiosk, the kiosk being owned or operated or administered by the coordinating entity). The third part coordinating server may then transmit the information or file to the pathology practice server.

It will be apparent from the above that the information contained in a referral document may, in some circumstances, be sufficient so as to identify a patient at a referee practice and without the need for further input into the user interface by the patient.

Irrespective of how the patient is identified at the referral recipient premises, the system may be configured such that the patient arrival is recorded and the patient inserted into a software- based queuing system. Moreover, the kiosk may be configured to issue a paper or electronic ticket for the patient having a queue number. The system typically displays queue number in turn (such as on an overhead display screen), so as to prompt a patient to enter into a consulting room when his/her turn arises.

A kiosk disposed in the referral recipient premises may be configured to function as a patient identification means, optionally with attendant configuration of the system.. The kiosk is generally processor-controlled (for example by an incorporated personal computer), and comprises output means including a video display screen viewable by the patient, or a speaker audible by the patient. In some embodiments the video display screen is touch sensitive allowing the patient to input data as required.

Upon arrival, the patient sights or hears the output means imparting an instruction (in text and/or graphical and/or audio form) to utilize the patient identification means before proceeding further. While the patient identification means may rely on patient input (such as by text input, or voice recognition) it is preferred that the means does not rely on patient input. For example, the patient identification means may rely on an identification document issued by a health care provider, or by any other third party. In one embodiment, the system utilizes a medical practice-issued document (such as a card, an appointment card, or an adhesive-backed label that may be affixed to another document or a card, an invoice, a prescription, a referral letter or a pathology service request form) . The medical practice document may be configured to uniquely identify each patient of the practice. Graphical means such as a bar code or a QR code (implementation of both are known to the skilled artisan) may be applied in this regard. Laser-based readers of such codes are well known and may be incorporated into the system.

Alternatively, optical character recognition means may be used in the system to ascertain the patient's identification from a practice-issued document. The optical character recognition means may be configured to establish the identity of the patient by recognising the patient's name (in text) or a patient-specific number (in text) issued by the medical practice.

Other methods of encoding data capable of identifying a patient are also including within the scope of the invention including the use magnetic-based media (such as encoded strips or magnetic inks). Readers of such media are also known in the art, and therefore readily incorporated into the present systems. Where the system comprises a kiosk, the kiosk may therefore comprise an optical or magnetic based reader.

In some embodiments, the practice-issued patient identification means is not a document, and may be a purely electronic means. It is contemplated that a personal electronic device of the patient (such as a smart phone) may comprise practice-issued patient identification means. The screen of such devices can display a unique bar code or QR code or even simply a string of text which is optically recognised.

Alternatively, the patient's personal electronic device may transmit an electronic signal (such as by radio means including WiFi™, Bluetooth™ or ANT™) to the patient identification means. In this embodiment, the data encoded in the signal is a unique patient identifier issued by the practice. A system configured in this way may allow for a patient to simply enter a practice, and without any interaction with an arrival kiosk to be identified by the system and recognized as having arrived. In other embodiments, the system is configured to identify a patient based on means issued by a third party. Preferably, the third party issued means is a document that would normally be carried by a patient when entering a medical practice. As one example, a government issued health care card is used. Examples of such cards include the Medicare Card (Australia), the European Health Insurance Card (European Economic Area countries), and the Social Security Card (United States of America). Non-government issued health-related cards such as private health insurance cards are also contemplated.

Non-health related government issued identification cards which are carried by the majority of patients may be utilized in some embodiments of the present systems. Documents such as a drivers' license, a concession card, a pension card, a national identity card, a passport, a taxation card, a utility bill and the like may be incorporated into the present systems.

Non-health related non-government issued cards such as a credit card (including chip-based cards), or a banking card are also contemplated.

Information from a third party card may be read by the patient identification means by laser, optical recognition, or magnetic means as discussed supra. It will be appreciated that biometric means may also be utilized in the present systems. Unique (or virtually unique) identifiers such as finger prints, facial features, voice recognition, iris pattern and the like are contemplated. Hardware and software for exploiting biometric identification means are well known, and within the ability of the ordinary skilled person to incorporate into the present systems.

A kiosk disposed in the referral recipient premises may be configured for use as a payment means, optionally with attendant configuration of the system. The visual display / user interface may alert the patient of a fee payable for the upcoming consultation or service. The fee may be varied according to the time of day (with higher fees payable at higher demand times of the day, after hours, or on a weekend), a speciality of the referral recipient, or a standard gap fee payable by all non-exempt patients. The system may request the patient to confirm (by way of touch screen activation) acceptance of the fee. Where the fee is not accepted, the display means may inform the client that the appointment has been cancelled. In terms of patient-specific financial information, the visual display means / user interface may inform that the patient has an outstanding account with the practice and that they must proceed to reception to organize payment. Where payment is not forthcoming, the appointment may be cancelled. The status of the patient's account is found by reference of the system to patient-specific financial data on a patient database.

In some embodiments, the system kiosk is configured so as to accept payment from a patient, optionally with attendant configuration of the system. The kiosk may comprise internet based means for payment such as by PayPal™, EFTPOS, credit card, debit card, or cash. Alternatively, the kiosk may comprise card reading means (such as a magnetic reader or chip reader), or other means (such as a touch screen) by which a payment can be made. In an exemplary use of the system, after registration at the kiosk the patient is requested by way of the kiosk visual display to make an electronic prepayment (for example by swiping or "touching" a credit card to a dedicated device proximal to the kiosk), or a cash payment (by way of a bank note or coin deposit machine). This payment may be a base payment, a proportion of the expected fee, or a minimum fee, or a maximum fee, or a surcharge fee, or a facility fee. This amount may change from referral recipient to referral recipient, or from day to day, or be dependent on the time of day or the age of patient, or a concession status for example.

Where the prepayment is a surcharge fee the patient is informed of that by the visual display / user interface of the kiosk and also the reason (such as "weekend consultation surcharge" or "gap fee charge"). The fee may be displayed on the kiosk visual display / user interface, along with the reason, and optionally an explanation of the fee structure of the referral recipient. In one embodiment, the pre-payment is not directed for any medical service, and may be a facility fee or other surcharge.

The system may be configured to provide a patient with the option to proceed (or to not proceed) with securing the consultation given the need for a prepayment.

Where charged, the amount charged as prepayment is stored in the system.

At the conclusion of a consultation or service, the referral recipient charges the amount for the consultation and the pre-payed amount is added to the patient account and a receipt is printed out at the practitioner's desk for the full amount of the consultation in the name of the patient. As an option to the foregoing, the system is configured to allow the referral recipient to reverse the pre-payment, and print a receipt having only the amount deemed chargeable by the referral recipient. For example, the prepayment may have been a gap fee (to cover the short fall between the payment provided by a government or insurer, and the actual consultation fee) and the referral recipient may decide for any reason (economic, patient relationship or otherwise) to not levy a gap fee and charge only the fee that is payable by the government or insurer. Where the prepayment is not reversed, the full amount of the consultation (with or without refund of prepayment) is payable. In some circumstances, a government or insurer may settle at least part the invoice such as the part that is covered by the government or insurer. The settlement may be made directly to the practice, or indirectly via the patient.

In any event the system may be configured such that the full amount of the consultation (i.e. any pre-payment as well as a charge levied by the referral recipient at the end of the consultation or provision of service) is shown on the receipt. Systems configured to accept pre-payments, and optionally configured to allow a referral recipient to refund in part or full a pre-payment provide advantage in so far as the need for a patient to attend reception to make a prepayment, or to seek a refund of a prepayment is lessened or abolished. Furthermore, the present systems may render unnecessary the need for a referral recipient to maintain cash on site.

A kiosk disposed in a referral recipient premises may be further configured to allow for a patient to set a follow up appointment with the referral recipient, the health care referrer or any other health care provider, optionally with further configuration of the system. In addition or alternatively, the system may comprises a second kiosk (optionally disposed about an exit of the referral recipient premises) configured to allow for a patient to set a follow up appointment.

The present systems may comprise means for allowing a patient to set a follow-up appointment after a consultation or a service provided. It is often the case that a practitioner will wish to review a patient's progress or a pathology result at some future time. In some embodiments, no further hardware components are added to the system, with the patient utilising the same kiosk as used on arrival. More typically, the system comprises a dedicated follow-up appointment kiosk for patient use after a consultation. Generally, this follow-up kiosk will be located in the waiting area of the clinic, or about an exit of the service/consultation room.

The follow-up appointment kiosk may be configured to utilize patient identification means of the types disclosed supra for the arrival kiosk. In some embodiments, the follow-up appointment kiosk is configured so as to allow for entry of practitioner preferences by the patient, including complex Boolean filtering of preferences as disclosed supra for the arrival kiosk. However, this second kiosk may provide for even greater complexity allowing for the patient to consider a range of other appointment parameters in the course of selecting a follow-up appointment. For example, alternative days and times of the appointment can be reviewed for one or more practitioners. The patient may search for an appointment with the practitioner just consulted on a week day afternoon at a time when no gap fee is payable. The display means may display a number of appointment options, with the client selecting a convenient date and time.

Alternatively, the patient may browse a practitioner's entire schedule in calendar form and select a convenient date and time. Complex Boolean search may also be incorporated into the follow-up kiosk, for example to allow a patient to avoid appointment times where are surcharge is payable, or to identify times when a female doctor is in attendance.

In making a follow-up appointment, the system may be configured such that the patient need not remember the practitioner's name, this information already being stored in the patient database and extracted when the patient schedules a follow-up appointment on the same day.

In some embodiments, the system is configured to read information from a document provided to the patient during the consultation or service. For example, the referral recipient may hand the patient a document related to a further referral recipient or to be taken to the original health care referrer.

In one embodiment, the referral recipient prints a medical or paramedical test request form during the consultation/service. The document provided to the patient during the consultation may be a referral letter (for example a letter to a medical specialist, a speech pathologist, a physiotherapist, a counsellor, a social worker and the like). Where the letter is sealed in an envelope, the envelope may have the bar code or QR code affixed or printed thereonto.

In some embodiments, the document provided to the patient during the consultation/service may be dedicated only to facilitate the making of a follow-up appointment. The document may specify in computer-readable text, code or other means a time period after which a follow-up appointment may be made, or may instruct the system to retrieve the time period from a computer memory. In some embodiments, the document provided to the patient during the consultation, may be an accounting document such as an invoice or a statement of account. In some embodiments, the document provided to the patient during the consultation may be an electronic document (such as a text file) transmitted electronically to a patient device, such as a smart phone. The kiosk may be configured to print an appointment confirmation document (such as a card or slip) for later reference by the patient. In some embodiments, the system is configured to transmit an electronic meeting request to the patient's email address (as retrieved from the database) allowing importation of the appointment into the patient's electronic calendar (such as Microsoft Outlook™). Alternatively, a local message via Bluetooth™ may be transmitted directly from the kiosk to the patient's smart phone. A medical practice-specific application software stored in the smart phone may receive the message and issue an alarm to remind the patient of the impending appointment. In another alternative, the system may dispatch an SMS text message to the patient's smart phone as a reminder.

After attending the referral recipient, a report may be generated by the recipient for return to the referrer. In that circumstance, the report is entered into the system (typically by way of the second computer) and is automatically routed to the referrer via the third computer. In this way, there is no possibility for a report to remain unsent, leaving the referrer to contact the referral recipient to check on progress.

Once the report is transmitted from the referral recipient to the referrer, the system may be configured to allow the referral recipient to recommend the patient book a follow-up appointment with the referrer to discuss results. This is a further task in a workflow. For example, where a pathology result is abnormal the system may be configured to dispatch an electronic communication to the patient facilitating the making of a follow-up appointment as another task in the workflow. Similar embedded links as discussed above may be incorporated into such communications. Where all pathology results are in normal range the patient may receive an electronic message confirming same and leaving to the patient's or referrer's discretion whether a follow-up appointment is necessary.

SMS gateways useful in the present systems may be any type deemed suitable by the skilled person having benefit of the present specification. A true fixed-wire SMS service type may be used, based on extensions to the European Telecommunications Standards Institute (ETSI) Global System for Mobile Communications (GSM) SMS standards and allow messaging between any mix of fixed and mobile equipment. These use frequency-shift keying to transfer the message between the terminal and the SMSC. Terminals are usually based on Digital Enhanced Cordless Telecommunications (DECT), but wired handsets and wired text-only (no voice) devices may be used. Messages are received by the terminal recognising that the Caller ID is that of the SMSC and going off-hook silently to receive the message. The gateway may be configured by any means deemed suitable by the skilled person having benefit of the present specification. For example, in a GSM gateway appliance a direct-to- mobile gateway is a device which has built-in wireless GSM connectivity. It allows SMS text messages to be sent and/or received by email, from Web pages or from other software applications by acquiring a unique identifier from the mobile phone's Subscriber Identity Module.

The connection to the mobile network is made by acquiring a SIM card number from the mobile operator and installing it in the gateway. Some devices are designed with SIM management to regulate the number of SMS messages per SIM, ODBC to connect to a database, and HTTP interfaces to interact with third party applications.

The electronic communications to a patient may rely on a direct-to-short message service center (SMSC) gateway being a software application, or a component within a software application, that connects directly to a mobile operator's SMSC via the Internet or direct line connections. The Short Message Peer-to-Peer (SMPP) protocol is typically used to convey SMS between an application and the SMSC.

In one possible implementation, an SMS gateway may sit between the end user who needs to send/receive SMS and a mobile network's SMSC. Such gateways provide a choice of protocols, including HTTP, SMTP, SMPP and Web services. Providers of SMS gateway services include SMS aggregators and mobile operators. SMS gateways are also available as part of messaging services such as AOL, ICQ and others.

An SMS gateway connects with (i) mobile network SMSCs in order to send/receive messages and/or (ii) other SMS gateways in order to reach mobile subscribers on multiple mobile networks. It is therefore possible that an SMS gateway has a combination of mobile network SMSC connections and connections with other SMS gateways in order to provide its services. However, there is the increasing potential for delivery problems with SMS the greater the number of SMS gateways in the delivery chain.

A Spreadsheet-to-SMS gateway may be used allowing the sending of SMS messages from Excel or a spreadsheet with a configurable message to some or all of the numbers in the document. Google Sheets (also known as Google Docs spreadsheets and Google Drive spreadsheets) allows such sending via a component called an "Add-on" accessible via the "Get Add-ons" menu within the online application. The Add-on connects directly to a mobile operator or Tier 1 aggregator's SMS Gateway via the Internet.

The workflows executable by the present systems may be configured differently according to the desired outcome, typically configured around the tasks associated with provided the desired good, service or information to the patient or the referrer. Implementation of workflows in the present systems is typically by way of the second computer, which is typically administered by a coordinating entity (as distinct from the referrer or the referral recipient), or the second computer. The workflows may be executable by scripts written de novo for the task, or by implementation of an established workflow system, and may be based on integration-centric workflow system, a human task-centric workflow system, or XCFG. Examples of established workflow managements systems that are potentially configurable for operation in the present systems include Activiti, Apache ODE, Apache Taverna, Bitrix24, Bonita BP, CEITON, IBM BPM, Imixs-Workflow, Intuit QuickBase, jBPM, Kissflow, Microsoft Windows Workflow Foundation, PRPC, Pyrus, SAP Business Workflow, Workgroups DaVinci, YAWL. In one embodiment of a system comprising workflow functionality, a referral template designed for use by a referral provider such that upon transmission of the completed template by the referrer a predetermined workflow is instigated. For example, the template may comprise a predefined list of requests. For example where the referral recipient is a radiology practice some of the predefined requests may be: X-Ray left ankle, barium meal analysis of small bowel, CT scan of head. Clearly, different workflows are required for each request. Upon receipt of the completed template at the computer of the radiology practice the request selected by the referrer is read and the specific workflow for that request is invoked.

Much of the foregoing description is directed toward the referral recipient being a provider of a service. However, some embodiments of the system extend to providers of healthcare goods such as a pharmacy (or druggist) which supplies a controlled substance under the order of a medical practitioner. In such an embodiment, the patient-specific referral information comprises all the usual information provided on a prescription such as patient name, medication prescribed, dosage, and any specific instructions for administration. This information is transmitted to the second computer, and then onto the third computer (being the pharmacy computer, the pharmacy being the referral recipient). The patient-specific referral information may be routed to a specific pharmacy defined by the referrer. Alternatively, it may be a pharmacy which is closest to the referrer's address or to the patient's address. In any event, the patient-specific referral information may comprise a public key of a certain pharmacy and so the information is routed to that pharmacy. A workflow at the pharmacy may be invoked such that the pharmacist on duty prepares the medication for sale, with an automated SMS text message being sent to the patient when the medication is ready for collection.

Such pharmacy transactions may be recorded on the second computer which may comprise algorithmic means embodied in software for the detection of multiple prescriptions being filled by the same person which is indicative of substance abuse.

The invention may be embodied in program instruction set executable on one or more computers. Such instructions sets may include any one or more of the following instruction types:

Data handling and memory operations, which may include an instruction to set a register to a fixed constant value, or copy data from a memory location to a register, or vice-versa (a machine instruction is often called move, however the term is misleading), to store the contents of a register, result of a computation, or to retrieve stored data to perform a computation on it later, or to read and write data from hardware devices.

Arithmetic and logic operations, which may include an instruction to add, subtract, multiply, or divide the values of two registers, placing the result in a register, possibly setting one or more condition codes in a status register, to perform bitwise operations, e.g., taking the conjunction and disjunction of corresponding bits in a pair of registers, taking the negation of each bit in a register, or to compare two values in registers (for example, to see if one is less, or if they are equal).

Control flow operations, which may include an instruction to branch to another location in the program and execute instructions there, conditionally branch to another location if a certain condition holds, indirectly branch to another location, or call another block of code, while saving the location of the next instruction as a point to return to.

Coprocessor instructions, which may include an instruction to load/store data to and from a coprocessor, or exchanging with CPU registers, or perform coprocessor operations. A processor of a computer of the present system may include "complex" instructions in their instruction set. A single "complex" instruction does something that may take many instructions on other computers. Such instructions are typified by instructions that take multiple steps, control multiple functional units, or otherwise appear on a larger scale than the bulk of simple instructions implemented by the given processor. Some examples of "complex" instructions include: saving many registers on the stack at once, moving large blocks of memory, complicated integer and floating-point arithmetic (sine, cosine, square root, etc.), SIMD instructions, a single instruction performing an operation on many values in parallel, performing an atomic test-and-set instruction or other read-modify-write atomic instruction, and instructions that perform ALU operations with an operand from memory rather than a register.

An instruction may be defined according to its parts. According to more traditional architectures, an instruction includes an opcode that specifies the operation to perform, such as add contents of memory to register— and zero or more operand specifiers, which may specify registers, memory locations, or literal data. The operand specifiers may have addressing modes determining their meaning or may be in fixed fields. In very long instruction word (VLIW) architectures, which include many microcode architectures, multiple simultaneous opcodes and operands are specified in a single instruction.

Some types of instruction sets do not have an opcode field (such as Transport Triggered Architectures (TTA) or the Forth virtual machine), only operand(s). Other unusual "0-operand" instruction sets lack any operand specifier fields, such as some stack machines including NOSC.

Conditional instructions often have a predicate field— several bits that encode the specific condition to cause the operation to be performed rather than not performed. For example, a conditional branch instruction will be executed, and the branch taken, if the condition is true, so that execution proceeds to a different part of the program, and not executed, and the branch not taken, if the condition is false, so that execution continues sequentially. Some instruction sets also have conditional moves, so that the move will be executed, and the data stored in the target location, if the condition is true, and not executed, and the target location not modified, if the condition is false. Similarly, IBM z/Architecture has a conditional store. A few instruction sets include a predicate field in every instruction; this is called branch predication. The instructions constituting a program are rarely specified using their internal, numeric form (machine code); they may be specified using an assembly language or, more typically, may be generated from programming languages by compilers. The program may be embodied as computer-executable software written so as to be operable in the context of any computer, system or methods described herein. As indicated to supra, various components of the invention are provided as computer-executable software components. These components, and the functionality associated with each, may be used by client, server, or peer computer systems. These various components can be implemented into the system on an as-needed basis. These components may be written in an object-oriented computer language such that a component oriented or object-oriented programming technique can be implemented using a Visual Component Library (VCL), Component Library for Cross Platform (CLX), Java Beans (JB), Enterprise Java Beans (EJB), Component Object Model (COM), or Distributed Component Object Model (DCOM)), or other suitable technique. These components are linked to other components via various APIs and then compiled into one complete server and/or client application. The method for using components in the building of client and server applications is well known in the art. Further, these components may be linked together via various distributed programming protocols as distributed computing components.

Where the software may be embodied in the form of a "machine readable medium". This term may be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "machine-readable medium" shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies illustrated herein. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

Some embodiments of the invention may require distributed computing components and protocols. An embodiment may include remote procedure calls being used to implement one or more of the above-illustrated components across a distributed programming environment. For example, a logic level may reside on a first computer system that is located remotely from a second computer system including an interface level (e.g., a GUI). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The various levels can be written using the above-illustrated component design principles and can be written in the same programming language or in different programming languages. Various protocols may be implemented to enable these various levels and the components included therein to communicate regardless of the programming language used to write these components. For example, an operation written in C++ using Common Object Request Broker Architecture (CORBA) or Simple Object Access Protocol (SOAP) can communicate with another remote module written in Java™. Suitable protocols include SOAP, CORBA, and other protocols well-known in the art.

As described herein, some embodiments may require the transmission of data between two computers such as a server and a client. Some embodiments may utilize the Open Systems Interconnection (OSI) model or Transmission Control Protocol (TCP)/IP protocol stack model for defining the protocols used by a network to transmit data. In applying these models, a system of data transmission between a server and client, or between peer computer systems, may comprise a series of layers comprising: an application layer, a transport layer, a network layer, a data link layer, and a physical layer. In the case of software having a three-tier architecture, the various tiers (e.g., the interface, logic, and storage tiers) reside on the application layer of the TCP/IP protocol stack. In an example implementation using the TCP/IP protocol stack model, data from an application residing at the application layer is loaded into the data load field of a TCP segment residing at the transport layer. This TCP segment also includes port information for a recipient software application residing remotely. This TCP segment is loaded into the data load field of an IP datagram residing at the network layer. Next, this IP datagram is loaded into a frame residing at the data link layer. This frame is then encoded at the physical layer, and the data transmitted over a network such as an Internet, LAN, WAN, or some other suitable network. These networks may use a variety of protocols for the exchange of data, including the aforementioned TCP/IP, or some other suitable protocol. These networks may be organized within a variety of topologies (e.g., a star topology) or structures.

Where the invention is embodied in the form of a computer or a computer system, this may comprise a machine that executes a set of instructions to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server- client network environment or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a Personal Computer (PC), a tablet PC, a PDA, a cellular telephone, a Web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. Example embodiments can also be practiced in distributed system environments where local and remote computer systems, which are linked (e.g., either by hardwired, wireless, or a combination of hardwired and wireless connections) through a network, both perform tasks such as those illustrated in the above description.

The computer will typically comprise a disk drive unit including a machine-readable medium on which is stored one or more sets of instructions and data structures (e.g., software) embodying or used by any one or more of the methodologies or functions illustrated herein. The software instructions may also reside, completely or at least partially, within the main memory and/or within the processor during execution thereof by the computer system, the main memory and the processor also constituting machine-readable media. The instructions may further be transmitted or received over a network via a network interface device using any one of a number of well-known transfer protocols (e.g., Hyper Text Transfer Protocol (HTTP), Secure Hyper Text Transfer Protocol (HTTPS)).

It will be appreciated that in the description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following are hereby expressly incorporated into this Summary section, with each claim standing on its own as a separate embodiment of this invention.

Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination. In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as fall within the scope of the invention. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that the invention may be embodied in many other forms. The present invention will now be more fully described by reference to the following preferred embodiment.

PREFERRED EMBODIMENTS OF THE INVENTION

This preferred embodiment is disclosed in reference to a scenario whereby a doctor in a general practice (primary care) wishes to refer a patient to a recipient medical specialist for further investigation.

Reference is made to FIG. 1 which shows the computer of a referring doctor 10, the computer of the recipient medical specialist 12, and the computer of a coordinating entity 14. Computers 10 and 14 have APIs incorporating protocols allow data interchange therebetween, via the computer 12. Where the interchange of data between the referring doctor and medical specialist is compliant with an industry standard (such as HL7) there may be no need for APIs to govern the interchange. The referring doctor opens a template 16 on the computer 10. The template 16 has a predefined format having a series of empty fields 18 for completion. The doctor selects a recipient specialist from a scrollable menu (e.g. "Dr. Smith, Oncologist") and the public key associated with that specialist is automatically populated. Patient details (name, address, sex, age, Medicare number, patient number) are extracted from the patient database of computer 10 are inserted into the "Re:" field of the template 16. Under the "Request" field the doctor selects "Review of Patient and Provide Report" from a scrollable menu. The doctor inserts free text into the "Notes" field, for example "Suspicious skin lesion on upper left arm". The "From" field is prepopulated with the doctor's name, address, and Medicare provider number.

In one embodiment, the specialist recipient has previously uploaded the template to the third computer (the template typically being HL7 compliant) specifying the type and form of referral information required.

In some embodiments, the referral information is not entered into any template as described above. In some embodiments the referring simply doctor prepares a standard referral document using Microsoft Word or similar application and allows software means to electronically capture the patient-specific referral information from the referral document. The software means for capture may be resident on the first computer or the third computer. Upon completion of all mandatory fields in the referral document 16 letter the referring doctor selects the virtual print server of computer 10 to extract the information in the referral document 16 (and optionally via the API of computer 10) sends referral information to the computer 12 of the coordinating entity where it is stored in a virtual mailbox.

The capture software means may firstly scan the characters of the document for a recipient specialist that is a participant of the system. If no recipient specialised is identified the referring doctor may be asked (by a user interface on computer 10). However the recipient specialist is identified, the system (and typically the computer 12) calls a template detailing the type and structure of information required by the recipient specialist. By the use of native HL7 compliant information of the referral document 16, or by processing of the information of the referral document by a protocol encoded by the API of computer 10, the template of the recipient specialist is completed by the system. The completed template is then deposited in the virtual mailbox of the referral recipient, for transmission to computer 14 upon provision of the correct private encryption key.

Reference is made to FIG. 2 showing a process flow of the third computer 12, and also to FIGS. 3 and 4 which show tasks carried out by computer 12 and also invocation of work flow.

The workflow implementation software of computer 12 directs dispatch of an SMS text message to the patient (not shown) instructing the patient to make an appointment with the recipient specialist. The workflow software of computer 12 also instructs the computer 14 to connect with the virtual mailbox of computer 10, and using its private key to access the referral information. The referral information is then transmitted to the patient database of computer 14 (optionally) via the API of computer 14. Once the patient has visited the specialist, the specialist prepares a report for the referring doctor using a template (not shown) including the referring doctor's details and public key. The report is transmitted via virtual print server of computer 14 to the virtual mailbox of computer 12. Upon receipt of the report, the computer 12 transmits an instruction to the computer 10 to access the report and import the information contained therein into the patient database of computer 10. The computer 12 also transmits an SMS message to the patient (not shown) directing that a follow-up appointment be made with the referring doctor. The referring doctor access the report and discusses the specialist's opinion with the patient at the follow up appointment.

With reference to the system of FIG. 1 , this preferred embodiment captures data which is normally printed on a typical paper-based referral form and securely transports the captured data to the specialist. The system comprises contains a virtual print service which is installed on the referring doctor's personal computer. The referring doctor prints to the associated printer port when he/she wishes to refer a patient to another medical service provider. The virtual print service captures the data, which would otherwise be printed on the referral form. The data is automatically scanned to detect the recipient. The referring doctor is prompted to select a recipient specialist if a recipient can't be detected automatically.

The referral information (as captured by the virtual print service) is then encrypted using the public key of the recipient specialist and stored in a virtual mailbox in a remote server which can only be accessed by the recipient specialist. The system associates the captured data with a template which is defined according to a unique referral form layout as designed by the recipient specialist. The template is configured so as to trigger a configurable workflow which governs the flow of the data through the system and dispatches automated messaging to keep all participants informed. The referring doctor and recipient specialist have both previously separately registered to access the system. A digital signature as well as a public and private key is provided per registration.

A referring doctor may request access to a recipient specialist by sending the recipient specialist a link request. If appropriate, the recipient specialist approves the link request so as to allow the doctor to transmit referrals to the specialist. A recipient specialist may invite a referring doctor to join his/her network of clients. All captured data is formatted into readable information and grouped into a single message blob which may be compliant to an industry standard such as HL7. The message blob is signed with the referring doctor's digital certificate to create accountability and encrypted with the recipient specialist's public key before being stored in the recipient's virtual mailbox on the cloud server. Only the recipient is able to decrypt the stored messages using its private key.

The high level of security ensures that all participants in the communications workflow are identified which eliminates the possibility of fraudulent referrals or fraudulent pharmaceutical prescriptions.

No manual re-entry of data is required between organisations due to the level of automated integration. All captured data is turned into valuable information by classifying printed fields and saving the information in a well-designed managed database.

Automated workflows can be developed to inform doctors of errors (or generate warnings) as and when the referral or pharmaceutical script is being submitted.

The virtual print service creates and manages a redirected printer port which is used to capture the raw printed data. This service is also responsible for formatting the message blob, digitally signing the blob, embedding the required certificates, identifying the recipient and transmitting the message blob to the cloud server (computer 12) for processing.

The central cloud server computer 12 applications implement the business logic and security of the system. The referring doctor and recipient specialist registration and configuration data is managed and stored by these applications. The virtual mailboxes are also managed by this suite of applications.

Claims

CLAIMS:

1 . A system for communicating a referral document from a first health care service provider to a second healthcare service provider, the system comprising:

a first computer of a health care referrer, the first computer having a database comprising information on a plurality of patients, the first computer configured to generate and transmit patient-specific referral information,

a second computer of a health care referral recipient, the second computer having a database comprising information on a plurality of patients, and

a third computer of a coordinating entity in operable communication with the first and second computers, the server configured to receive and store the patient-specific referral information transmitted by the first computer and permit importation of the patient-specific referral information into the database of the second computer.

2. The system of claim 1 comprising a plurality of first computers, and a plurality of second computers, the patient-specific referral information comprising information to identify the referral recipient, the system configured to permit access to the patient-specific information only by the referral recipient identified by the patient-specific referral information.

3. The system of claim 2, wherein the patient-specific referral information has an associated encryption key specific to a referral recipient.

4. The system of any one of claims 1 to 3, comprising an electronic template document configured to accept patient-specific referral information.

5. The system of any one of claims 1 to 4, wherein the first computer comprises virtual printer software configured to transmit patient-specific referral information, and/or the second computer comprises virtual printer software configured to transmit patient-specific report information.

6. The system of any one of claims 1 to 5, wherein the patient-specific referral information is provided so as to conform to an industry standard.

7. The system of any one of claims 1 to 6, comprising a protocol is configured to provide patient-specific referral information so as to conform with a structure of the database of the second computer.

8. The system of any one of claims 1 to 7, configured so as to allow transmission of patient-specific referral information from the second computer to the first computer via the third computer.

5 9. The system of any one of claims 1 to 8, wherein the patient-specific referral

information comprises work flow information, or invokes a workflow.

10. The system of claim 9, wherein the workflow defines a step of instructing the server of the second computer to transmit an electronic communication to a patient, the electronic o communication providing means for the patient to book an appointment for the referral recipient.

1 1 . The system of any one of claims 1 to 10, comprising an automated check-in kiosk at a premises of a referral recipient.

5

12. The system of claim 1 1 , wherein the kiosk comprising means for scanning a hard copy referral document

13. A method for referring a patient to a referral recipient, the method comprising the0 steps of:

providing the system of any one of claims 1 to 12,

generating patient-specific referral information on the first computer, and transmitting the patient-specific referral information from the first computer to the second computer via the computer.

5

14. The method of claim 13, further comprising the step of providing a public encryption key to securely encrypt the patient-specific referral information before transmission.

15. The method of claim 13 or claim 14, comprising the step of providing a private0 encryption key so as to allow access to the patient-specific referral information after

transmission.

16. The method of any one of claim 13 to 15, comprising the step of invoking a work flow so as to facilitate the provision of a good, a service or information to the referrer or the5 referral recipient.

17. An electronic template for referring a patient to a referral recipient, the template comprising (i) one or more fields configured to contain patient-specific information and (ii) a public encryption key associated with a referral recipient.

18. Computer executable virtual printer software configured to capture patient-specific referral information.

19. The software of claim 30 wherein the patient-specific referral information is in an industry standard format.

20. A system for communicating a referral document from a first health care service provider to a second care health service provider, the system comprising:

a first computer of a health care referrer, the first computer having a database comprising information on a plurality of patients, the first computer configured to generate and transmit patient-specific referral information, and

computer executable virtual printer software configured to capture the patient-specific referral information.