WO2020115493A1

WO2020115493A1 - Method and system for compliant data acquisition and automated matching based on complex rule sets

Info

Publication number: WO2020115493A1
Application number: PCT/GB2019/053443
Authority: WO
Inventors: Adiel BENAYAHU; David Ezra
Original assignee: Vantage Diagnostics Limited
Priority date: 2018-12-05
Filing date: 2019-12-05
Publication date: 2020-06-11
Also published as: GB201819869D0

Abstract

The present invention relates to software for the application of multiple complex sets of rules to input data. More particularly, the present invention relates to a method, apparatus and system for automatically matching multiple datasets of rules used for healthcare with input data for patients in order to more accurately identify services available to patients based on the input data. According to one aspect, there is provided an automatic referral method, comprising the steps of: receiving a first input, comprising one or more elements of user data; applying the first input to a model operable to adapt according to the one or more elements of user data; generating from the model one or more options for the user; and verifying that the one or more options are viable.

Description

METHOD AND SYSTEM FOR COMPLIANT DATA ACQUISITION AND AUTOMATED MATCHING BASED ON COMPLEX RULE SETS

Field

The present invention relates to software for the application of multiple complex sets of rules to input data. More particularly, the present invention relates to a method, apparatus and system for automatically matching multiple datasets of rules used for healthcare with input data for patients in order to more accurately identify services available to patients based on the input data.

Background

When the referral of a patient to a medical specialist is required, one or more template forms held in a database typically need to be completed, and if digitised these forms may include one or more automated basic checks such as to ensure the format of the date of birth is entered correctly. Other checks may be performed manually by the referrer or by staff within a referral management centre. This can lead to a fractured workflow owing to the use of multiple forms, the use of paper and regular manual intervention being required to process the forms. Paper forms are notoriously insecure and error prone and digital forms are routinely completely incorrectly or not fully completed.

For each set of medical services, there are typically guidelines available to allow medical professionals to understand what services are available for patients. The manuals for UK practice were developed by a central specialist body of the National Health Service (NHS), with clinical support. Each manual comprises approximately 50 to 100 pages, and a separate manual is typically required for each medical specialty.

General (medical) practitioners are usually the first medical professional to consider the referral of a patient and are expected to refer to or have memorised the content of the relevant manual prior to making any referral of a patient to a specialist medical practitioner, in order to ensure that the correct procedures according to the multiple guidelines have been followed.

Regularly, the work required to complete a referral has been delegated to other professionals who lack the required experience and/or qualifications to make such a referral correctly.

The current arrangement typically results in inefficient referrals, or incorrect referrals, resulting in wasted medical professional, administrative and patient time and the resulting costs of this. Summary of Invention

Aspects and/or embodiments seek to provide a method, apparatus and system for automatically applying multiple complex health compliance rules to patient data that has been input in order to determine a set of services available to a patient based on the input data.

According to an aspect, there is provided a computer implemented method of preparing referral data for a patient, comprising the steps of: determining one or more relevant sets of rules from rules data; determining relevant patient data required to apply the one of more relevant sets of rules and obtaining the determined relevant patient data from a patient database; receiving input data from a user; determining a relevant set of provider data by applying the one or more sets of rules to the determined relevant patient data and the input data; obtaining the relevant set of provider data from one or more provider databases; and determining an output referral data from applying the one or more sets of rules to the determined relevant patient data and the input data and the relevant set of provider data from the one or more provider databases.

By identifying relevant rules from rules data, or from a rules dataset or rules database, rules can be applied to the various input data that is provided to prepare the referral data. Each set of rules will require different input data, so by selecting the relevant rules the input data required can be identified that is relevant to the referral data to be generated.

By identifying relevant patient data, some of the input data required to apply the relevant rules can be obtained from a patient database without needing a user to input this data.

By receiving input from a user, data that is not in the patient database or which cannot be obtained from a provider database can be input in order to apply the relevant rules.

By determining what data is required from one or more provider databases, several providers can be queried in order to prepare the referral data.

By determining output referral data using a set of relevant rules data with relevant patient data, input data from a user and data from one or more providers, a substantially immediate and accurate referral can be made by a user as referral data has been compiled using the relevant rules data with the required input data to apply the relevant rules.

Optionally, the step of determining one or more relevant sets of rules from rules data comprises any or any combination of: receiving one or more relevant sets of rules from rules data; a user selecting one or more relevant sets of rules from rules data; or identifying one or more relevant sets of rules from rules data based on the probability of each of the one or more relevant sets of rules being above a predetermined threshold.

In some embodiments, determining the relevant set or sets of rules can be done by receiving the relevant rules, or by a user selecting one or more relevant sets of rules for the referral being considered; or using a probability-based approach to select one or more rules from the rules dataset based on a threshold-based approach as to which rules have sufficiently high probability to be relevant.

Optionally, the step of determining relevant patient data required to apply the one of more relevant sets of rules and obtaining the determined relevant patient data from a patient database comprises identifying what patient data is required to apply the one or more relevant sets of rules and obtaining available relevant patient data from the patient database.

In some embodiments, the rules will require a set of input data and some of this input data will be available in a patient database and can be extracted for processing of the rules deemed relevant while other input data won’t be available from the patient database.

Optionally, the step of receiving input data from a user comprises presenting to the user a set of further data required to apply the one or more relevant sets of rules and receiving the further data required to apply the one or more relevant sets of rules as the input data.

In some embodiments, the user will be presented with the fields for which data needs to be obtained so that the user can enter the required data in order for the rules to be applied. In some embodiments, these fields can include any or any combination of: further patient information; availability information; financial information; pre-populated information obtained from patient data for confirmation by a user; a referral reason; examination data; symptom data; medication data.

Optionally, the step of determining a relevant set of provider data by applying the one or more sets of rules to the determined relevant patient data and the input data comprises determining a set of queries to send to the one or more provider databases.

In some embodiments, once the patient data and input data are obtained and allow the relevant rules to be applied, a set of providers needs to be identified to which the referral data can be sent according to the relevant rules, but to do this the provider databases need to be queried so a query needs to be sent to one or more providers thus this query needs to be created based on the data and rules processed. In at least one embodiment, there is a step of identifying a set of providers from a list of providers to which the query is sent. In some embodiments, the query can include any or any combination of: a request for a list of personnel having a certain capability; availability information for the personnel; facility information; availability information for the facility capabilities; cost information; geographic information.

Optionally, the step of obtaining the relevant set of provider data from one or more provider databases comprises receiving a set of provider specific data from one or more providers to be used to apply the one or more sets of rules.

In some embodiments, information will be provided in response to a query sent to one or more provider databases. In some embodiments, the response/provider data can include any or any combination of: a list of personnel having a certain capability; availability information for the personnel; facility information; availability information for the facility capabilities; cost information; geographic information.

Optionally, the step of determining an output referral data from applying the one or more sets of rules to the determined relevant patient data and the input data and the relevant set of provider data from the one or more provider databases comprises identifying one or more of the providers to send the output referral data.

In some embodiments, a rating system can be applied to automatically select a provider from the list of providers to which to send the referral data, based on the determined relevant rules and the patient data, input data and the responses from all of the providers queried.

According to another aspect, there is provided an automatic referral method, comprising the steps of: receiving a first input, comprising one or more elements of user data; applying the first input to a model operable to adapt according to the one or more elements of user data; generating from the model one or more options for the user; and verifying that the one or more options are viable.

The referral system according to any aspect presented thereby can reduce or eliminate the need for manual referral management processes. Conventional referrals may take days or even weeks where referral management centres are used and where a referral management centre blocks a referral due to incomplete or invalid patient data. The referral system disclosed herein according to any aspect is operable to obtain clinically relevant decisions for patients in a much shorter time frame, and transfer this accurately and in a usable format between medical records systems and according to referral processes, so reducing the waiting time for the patient and improve the efficiency of the transfer of patient data between medical records systems. Therefore, limited clinical services may be used more efficiently and effectively, and may further lead to a reduction in associated costs.

In such a way, according to any aspect presented, relevant data or patient data may be extracted where available, for example from a General Practitioner (GP) records system and accessible external databases, in order to pre-populate or constrain the options for referrals and hence make the referral process more efficient. If insufficient user data is supplied, for example if one or more relevant items are not known because they have not been provided as input data for the patient, then the missing details are requested from a user.

Optionally, the one or more elements of user data comprise one or more of: patient details; patient demographics; medical history; medication; patient allergies; and/or family history. Optionally, the model is operable to adapt further according to one or more of: local pathways; and/or regulatory guidelines. Optionally, the regulatory guidelines comprise one or more guidelines from one or more regulatory bodies. Such details may affect the referral made by the referral system. For example, if a patient has a particular medical condition, then the local regulatory guidelines may require a GP to refer the patient to a particular specialist within a certain time frame. In the UK, the National Institute for Health and Care Excellence (NICE) provides the regulatory guidelines to be followed by health professionals.

Optionally, the one or more options for the user comprise one or more referral options, optionally wherein one or more referral options are compliant with the regulations established by one or more regulatory bodies. Such regulatory bodies may include for example NICE and/or the NHS Electronic Referral Service (eRS).

Not all the referral options may be accessible for a patient using the referral system. For example, the patient may be in a different country and cannot make a specific appointment time. Therefore it is advantageous to provide a range of options. Options are available based on rules. Rules can also be applied to data retrieved from other sources. Data from other sources may be parsed and rules can apply for data retrieved from a third party system.

Optionally, the generation of the model comprises the use of data held in one or more repositories.

Externally held data, for example a database of medical records, can provide a useful source of relevant information to a referrer. A patient may not be familiar with their own medical history and so it can be useful to have one or more records readily available. This depends on the Application Programming Interface (API) available by the external third party. For example, NHS Digital are working on a Summary Care Record (SCR) API which will allow access to the relevant clinical history of a patient. The available data can then be parsed and the rules applied accordingly.

Optionally, the verifying that the one or more options are viable comprises the use of a rules editor. Optionally, there is provided the method as disclosed herein, further comprising the steps of: recognising that one or more further elements of user data are required; and requesting the one or more further elements of user data are provided.

The rules editor as described herein can provide a fast and accurate means for creating one or more complex rule-based referral pro formas. Such pro formas may include: a question editor used to view and edit questions and assigning question types such as single choice or multiple choice; a conditions editor to view and edit conditions which trigger one or more rules to be fired, including rules which may include a mixture of logical arguments such as AND, OR, NOT, Equals to, Greater than, and/or Contains; and/or an Action editor to view and edit actions to execute when a rule is fired. Therefore a user with little to no knowledge of coding or any specific programming language may still create the rules they require. The rules editor is graphical user interface (GUI) based and may require minimal training to use effectively. Further rules may be created and/or existing rules amended if the need arises. Once a rule is created it can be applied to a range of scenarios in real-time.

Optionally, the step of receiving a first input comprises extracting one or more elements of user data from a remote database. Optionally, the remote database is a cloud database.

A remote database such as a cloud database can provide a secure and scalable means for storing information such as patient data.

Optionally, there is provided the method as disclosed herein, further comprising the step of: outputting a completed report comprising one or more verified options for the user.

Optionally, the method as disclosed herein is operable to initiate automatically upon the launch of a predetermined computer program.

According to a further aspect, there is provided an automatic referral system, comprising: a first input, comprising one or more elements of user data; a model operable to adapt according to the one or more elements of user data; a means operable to generate from the model one of more options for the user; and a means operable to verify that the one or more options are viable.

Optionally, the system disclosed herein further comprises a rules editor. Optionally, the rules editor comprises a graphical user interface (GUI). Optionally, the rules editor enables a user to create one or more rule-based referral queries. Optionally, the rule editor comprises one or more of: a question editor; a conditions editor; and/or an action editor. Optionally, the question editor is operable to: view; edit questions; and/or assign question types. Optionally, the conditions editor is operable to: view and/or edit conditions which trigger one or more rules to be initiated. Optionally, the action editor is operable to: view and/or edit actions to execute when a rule is initiated.

Optionally, the rules editor is operable to accept one or more medical coding systems and/or a natural language input. The one or more medical coding systems may include Systematized Nomenclature of Medicine (SNOMED) coded information, optionally including the subset Systematized Nomenclature of Dentistry (SNODENT) coded information. Both SNOMED and SNODENT can provide a widely used and efficient means for communicating medically relevant information between healthcare providers. In the embodiment wherein the rules editor is operable to accept a natural language input, there is provided a converter. The converter is operable to take a natural language input, such as a description of a symptom, and convert it to a format which may be understood by the rules editor. For example, a layperson description of a symptom may be converted to SNODENT coded information before being transmitted to the rules editor for further processing.

Optionally, the rules editor is operable to generate one or more rules comprising one or more logical arguments. Optionally, the rules editor is operable to intelligently display data held in one or more remote databases. The rules editor can use the GUI to enable a user to create complex rule-based referral pro formas. Such pro formas may include one or more of:

1 . A question editor used to view and edit questions and assigning question types such as single choice or multiple choice;

2. A conditions editor to view and edit conditions which trigger one or more rules to be fired, including rules which may include a mixture of logical arguments such as AND, OR, NOT, Equals to, Greater than, and/or Contains; and/or

3. An Action editor to view and edit actions to execute when a rule is fired.

In one embodiment, the following rule based pro forma may be created:

When on Object A:

(Condition 1 AND Condition 2 OR Condition 3) is TRUE;

Then, do the following:

Action 2 on Object B;

AND

Action 3 on Object C;

The rules editor can also take into account coded information received from the GP system for example:

IF the patient has: a Simple cyst, which

is over 5cm AND

is Mild OR Solid but NOT

Very Strong THEN

fire a certain rule.

The rules editor is capable of intelligently displaying data held in various repositories, in the back-end of the system such as a provider repository. A list of appropriate providers, for example in the form of a directory of services (DoS), is then generated in real-time, based on the patient’s location and various needs to be displayed at the time of referral. For example, if a patient is registered with a GP and the GP is part of a certain Clinical Commissioning Group (CCG), AND the patient has a specific health problem AND requires wheelchair access, the system will only display the relevant providers that are capable of caring for the patient taking into account both the“business requirements” as mandated by the commissioner of the service and the health requirements of the patient. Distance and waiting times are also displayed in at least one embodiment. Information may be used that resides and is maintained within a local library, or obtained through a query to third party databases such as the national Organisation Data Service (ODS).

The intelligent coding strategies used by the referral system are operable to take into account a plethora of variables in order to form an algorithm. Such variables may include one or more of:

• patient demographics;

• patient medical history;

• patient medication;

• patient allergies;

• family history;

• local pathways; and/or

• regulatory guidelines such as NICE guidelines in the UK.

Optionally, the one or more remote databases comprise one or more cloud storage facilities. Cloud storage can provide reliable and scalable storage facilities, as well as off-site backups in case of emergency.

Optionally, there is provided a document uploader module which allows a clinician to upload relevant patient documents directly from their patient record system and for these documents to be attached to the referral system disclosed herein. Clinicians may use the export document option within their patient record system to export one or more documents to a predefined folder. Once exported, these documents can be automatically uploaded and are attached to the referral currently being worked on. Once uploaded the documents may then be deleted from the folder so as to ensure that they will not be uploaded erroneously to another referral. Further, documents extensions may be validated at the time of upload and hence automatically classified based on rules as documents or images. For example:

Documentname . rtf = document

Documentname . jpeg = image

Document names containing proprietary extensions, appended by 3rd party software, may in some embodiments automatically be uploaded with universal extension names so as to make them readable by systems other than one specific third party system. For example, for a filename“Documentname. rtf.xx2”, the system may recognise that the extension“xx2” has been appended by one particular third party system. The referral system will then save the file in the predefined upload folder as“documentname.rtf” without the proprietary extension before uploading and attaching it to the referral.

The document uploader module eliminates the need to manually export files from the patient record system to a local folder one by one, then manually upload these files to another system, manually remove the appended extensions and then manually delete these files from the local folder. It also reduces the clinical risk of uploading and attaching wrong files to a referral.

Embodiments will now be described, by way of example only and with reference to the accompanying drawings having like-reference numerals, in which:

Figure 1 shows a flow chart of a conventional referral process;

Figure 2 shows a high-level overview of the referral system disclosed herein;

Figure 3 shows a flow chart of the referral system disclosed herein; and

Figure 4 shows an exemplary data entry page.

A conventional referral process is shown in Figure 1 . The process starts when a health professional such as a GP has come to the decision that a patient needs to be referred to a different point of care. In order to start the conventional referral process, a referral template is accessed in step 1 10. The referral template creation process requires the referrer, for example the GP, to select“document” and then“letter” from their user interface.

Once the template option is selected, the correct type of template is selected in step 1 15. For example, a template in relation to a heart condition might comprise different wording from a template in relation to a skin condition. A list of templates may be presented to the referrer in step 1 15 so that they might select the most appropriate template for their specific referral they are making. The list of templates may include pre-approved templates, in order to save the referrer time in checking the wording of the template.

Once the chosen template is selected, the template must be completed in step 120. The completion process of step 120 requires the referrer to switch their user interface to an “edit” mode, select a referral category, check and/or enter demographic info, and check one or more relevant boxes.

The referral system can identify patient demographic factors, for example age, gender, home postcode, residential status, and/or data relating to one or more Clinical Commissioning Groups (CCGs). The referral system may then subsequently present the appropriate list of pathway options and/or reasons for referral.

In one example, the referral system populates the information that a patient is male. Such information may be extracted from a records system from a GP practice. By linking the referral system with the GP records system the relevant data can be extracted into the referral system to enable a more efficient referral process. Therefore as the patient is male, the gynaecological pathways are unlikely to be relevant and hence are hidden. In a further example, the referral system populates the information that a patient is over 18 years old. Therefore, pathways in relation to children and adolescents are hidden. In a further example, a patient whose GP practice is in Ealing but resides in a Hillingdon postcode would result in one or more Hillingdon-based pathways being displayed.

This capability can provide the advantage of ensuring greater efficiency and accuracy in supporting local rules. The referral system of at least one embodiment thereby includes the logic of displaying providers on the DoS based on one or more factors mentioned herein.

The referral system can display a different DoS based on local rules. For example, if a provider is available on the eRS, the eRS DoS will display. However, if this is not the case, a non-eRS DOS will appear. In a further example, if a patient requires two referrals to two separate providers, one of which is available on eRS, then both DoS’s will appear.

The referral system may be operable to automatically identify whether a clinic on the eRS does not appear, for example if the provider fails to manage their clinics. In such a case, the referral system may suggest an alternative option based on local rules, while amending all relevant existing rules to support this change. The referral system may further be operable to report the absence of a clinic to the CCG.

In one example, after all provided information has been validated on the referral system, the eRS fields may be populated as:

• Urgency: Routine

• Speciality: Optometry

• Clinic: Cataract

However, after a user of the referral system selects the“search” option to display one or more providers, the list is returned as empty as no matches have been found in this exemplary case. The referral system will then regenerate to an amended set of fields:

• Urgency: Routine

• Speciality: Optometry

• Clinic: General eye care

Alternatively, or additionally, a non-eRS DoS can be displayed, and an exception report sent to alter logic and/or alert one or more CCGs. Once the editing stage is completed, access guidance is performed in step 125. Edit mode is switched off, and a link to an access guidance page is selected by the referrer. Once the link is selected, the referrer is taken to the access guidance page, in which they can filter by relevant clinical area, select a relevant document to review, and/or access further information which they may require.

The referrer then reverts back to edit mode in step 130, in which they complete the template. Further relevant boxes may be checked, and the referrer may be further required to check the patient medical history (PMHx). Details can also be added to the template.

The template is then saved in step 135. Details may be added in relation to the code information used in the Egton Medical Information Systems (EMIS®) software used in primary care in the UK. If required, the eRS option can be launched in step 140 and selected in step 145 by the referrer from a range of external links and a hence the referral added.

The referral details are then confirmed in step 150 and a clinical check performed. The referrer then searches through a DoS in step 155. Step 155 can comprise the option to add one or more of: a request type, a priority rating, a speciality, a clinic type, and/or other search refinements.

An appropriate care provider is then selected in step 160. A list of available appointment slots are then displayed in step 165, one of which is selected by the referrer or the patient who is being referred. The referral letter is then uploaded in step 170 within the framework of the conventional referral system. One or more further attachments may be uploaded in step 175. A file to be attached is selected in step 180, which in this example is a saved pro forma. The process then concludes in step 185, with the confirmation and printing of a final referral request.

Optionally, more than one referral may be generated from a single session. For example, a patient may be referred for an oral surgical procedure and for orthodontic treatment.

Flowever as shown in Figure 2 and Figure 3, there is provided one or more intelligent coding strategies and integration within existing IT systems. The referral system disclosed herein is operable to automatically validate a referral against locally defined administrative and clinical criteria alongside an existing booking screen used as part of an existing GUI. The relevant booking screens may be shown where the referral system is used in the jurisdiction of different regulatory bodies.

The referral system according to the embodiment described herein uses a plurality of data sets, also referred to as“relevant information”. The first set of data comprises patient data 1000. The patient data 1000 may comprise data which is held on behalf of a patient at a GP practice. For example, patient data 1000 for a specific patient may comprise vaccination records, relevant familial health data, and the nature of the current health issue from which the patient is suffering.

The second set of data is rules data 1005. The rules data 1005 comprises one or more policies established by a healthcare provider and may be relevant to the care of the patient making use of the referral system. The rules data 1005 sets out one or more treatment programmes and/or clinical practices to be followed if certain diseases or symptoms are present, which may limit or guide the options available for a GP treating the patient or when making a referral. For example, if the patient is halfway through a dose of medication, then the guidelines may indicate that the patient be compelled to complete the treatment before they can see a consultant or similar specialist for that issue.

The third set of data comprises provider data 1010. The provider data 1010 comprises further information potentially relevant to the treatment of the patient. Such information may be less medicinally focussed and more practical, such as dates of availability for different medical practitioners and opening hours of particular clinics. Such data is relevant for the patient so that they are provided with medical practitioners actually available to see them on a particular date, as well as being sent to clinics or hospitals which are actively operating and able to accommodate them.

The three data sets are used together to provide a referral for a patient which is appropriate and feasible. Relevant rules data 1005 is used to prepare an initial referral form. Patient data 1000 from is populated into the referral form, and any gaps in the referral form which cannot be filled may be raised to the patient or GP themselves and they can provide an answer. The provider data 1010 is then used to find a medical practitioner capable of accommodating the patient as part of an overall referral 1020, while complying with the rules data 1005 and the patient data 1000. If a plurality of medical practitioners capable of accommodating the patient are available, then the overall referral 1020 may provide the available options, from which a particular medical practitioner may be selected or may pre select one of the options.

The referral system disclosed herein comprises the step of selecting a pathway or reason for referral in step 210. Step 210 can comprise the steps of: checking and/or confirming the identity of the referrer; entering a speciality required and/or reason for referral; and selecting the option for the referrer to continue to the next stage of the referral process. The referral can then be completed in step 215 by entering the reason for referral if not entered previously and considering the automatic population of the required fields presented to the referrer. If the automatically populated fields are correct, then the status of the referral can be added. Otherwise the automatically populated fields may be corrected or updated manually.

If required, access to relevant information can be provided in step 220 through the selection of a single link by the referrer. Such relevant information may comprise regulatory guidelines set by a governing medical body. The eRS system or equivalent can then be accessed in step 225. The eRS is then completed in step 230, by populating with data in relation to the speciality, clinic type, and/or urgency of the referral. One or more clinics can then be presented to the referrer if they fit the required criteria. The eRS is then completed and the referral letter is transmitted.

A user (for example a patient or a doctor) is thereby offered a view of relevant information such as the appropriate speciality and clinic type populated, allowing the user to view and select a list of providers from the DoS. The arrangement of this embodiment is operable to facilitate the full processing of referrals in less than one minute. Further, all patients will be referred to the right place at the right time, with all relevant information available to the provider.

The referral system disclosed herein reduces the need for (GPs) to navigate through pathways on decision support tools or for letters to be vetted by a referral management centre (RMC). The referral system validates and directs referrals to the appropriate provider. The implementation of such a system would reduce or even eliminate the requirement to use referral letter templates and focus on the secure transmission of relevant data from GPs to the necessary service providers.

In use, when a GP or other health professional such as a dentist wishes to make a referral, they open a referral template within their clinical system. The referral system them pulls across all relevant patient information to avoid retyping it and hence potentially introducing error into the system. This relevant information can include demographics, medical history, drugs and other relevant data. If additional information is needed, relevant questions can be raised in one embodiment in the form of a pop-up query shown to the user. All the information may be collected and collated as structured data to make it easier and more accurate to analyse. Missing data, for example an NHS number, can be securely accessed from one or more relevant databases.

Once all the data is available it is checked against a predetermined algorithm. The referral system of one embodiment is operable to check which algorithm is the appropriate one to use for a particular type of care. The predetermined algorithm is operable to check for general administrative errors, such as the patient being an inappropriate age or the wrong sex for the care requested. It may also check the clinical appropriateness of the care by all potential providers. For example, the predetermined algorithm may request a particular blood test result prior to referral, if such a test is both required, and the result is missing. Such checks may be made significantly more rapidly than would be possible using a conventional method of a human reviewing the necessary requirements. After such checks are performed, the referrer is able to view that appropriate list of providers. A selection is made, and the referral is passed on to the chosen provider. The user of the referral system, also referred to as a“referrer”, can reach a state of having an approved choice of suppliers with the minimum “clicks” or“presses” on an automated electronic system. In at least one embodiment there is no manual intervention and the referrer remains in control of their patient’s referrals, and hence retains their clinical autonomy.

Clinical systems may utilise word processors, for example Microsoft Word, to generate referrals letters which merge information held in their systems. Such information can comprise patient demographics, history, medication, and/or allergies. This information is structured and held in a database.

In order to obtain this information and parse it, a software add-in has been developed which automatically launches when a predefined template is launched from within the GP system. When the template is launched, the add-in uses a POST request method to provide the information to a server operable to perform at least part of the method disclosed herein, which then runs a check on the data to identify if all the prerequisite information is completed

Data may be transmitted to the server through the use of a software add-in, which streamlines the data transfer process between the GP system and a server. The software add in streamlines the process by providing a secure, token based, method of uploading the data and ensuring that the data uploaded relates to the patient currently being worked on. Once the software add-in recognises that a predetermined template is launched through meta-data embedded within the document template, it will automatically trigger a new referral session and will present the clinician with the online proforma. No clicks or copying and pasting and manually uploading data is required.

If certain information is missing, the server will attempt to complete the information through an interface with external systems. For example, if an NHS number is missing on a referral, the server may search the NHS personal demographic service for a match based on the patient details for example using the patient’s first name, surname, and/or date of birth.

If the information is not available through external interfaces such as the patient phone number or email address, the system can prompt the user to enter it.

Once all the prerequisite information is available, the system can ask the user what to refer the patient for. Based on the answer, the system can display an online pro forma which has taken into account all the information that has been receive and only display relevant queries.

The online pro forma is dynamic where each question takes into account the information already provided and only displays the next relevant question. To ensure this, a sophisticated rule editor has been developed. The rules, also referred to as algorithms, are added to the referral system via an editor to ensure that all relevant referrals are checked accordingly. The rule editor enables a hierarchy to be determined. One or more factors may be indicated to show that the patient requires a routine referral, but if another response alerts to an urgent referral, the case can be directed along the more urgent pathway.

The referral system may further allow in at least one embodiment for logic to be applied to support training cases. Algorithms may be configured so that in a predetermined number of instances where the system would have automatically rejected a referral (Tier 1 ), patients will be offered the opportunity to be referred to hospital. To ensure equitability, the algorithms may be configured to ensure that the requests for training cases are spread across all practices. Hence once a site has filled a set quota, they will no longer be provided with the relevant option.

Figure 4 shows an exemplary data entry page for a user of the referral system, specifically in relation to a Benign Ovarian Cyst referral. It demonstrates the front end of a referral creation process. A clinician or other referrer selects a reason for referral. According to the relevant local guidelines, the patient record is reviewed and the following relevant information specific for this exemplary referral is recorded:

• Medication / hormonal contraceptives;

• Examination findings;

• Last consultation;

• Risk factors; and

• Family history.

The information is automatically and instantly populated, allowing in this example case the referring clinician to complete the referral in seconds.

Specifically, for the example of Figure 4, the rule logic may be represented as follows:

IF Reason for referral is: PRE - menopausal simple cyst 7.0 cm or more AND

patient is over 16 years AND from geographical area A OR geographical area D;

Then do the following:

Check patient record for Tamoxifen, IF

found, Look for examination findings; AND

display last consultation.

Check patient record for History of breast cancer, IF

found, Display message X, IF NOT

found, Check patient record for family history of breast / ovarian cancer etc. Based on rules and local criteria, the system may ask the user for a certain action such as to upload relevant images, documents, and/or information or to manually select an answer.

The system may further comprise a verification filter, to ensure that, for example, the relevant images, documents, and/or information required have actually been uploaded. If an erroneous image was uploaded, for example a magnetic resonance imaging (MRI) scan when an X-Ray was actually mandated, then the verification filter may prevent the erroneous image from being uploaded and/or send a message to a user or database reporting the error. As another example, the verification filter may be operable to detect the quality of data, for example whether a radiograph is of sufficient quality to be of use to the relevant audience. If the data is not of sufficient quality, then it may be rejected and an error messages transmitted to a user and/or a database. The verification filter may be operated and/or trained through the use of an artificial intelligence (Al) arrangement, optionally comprising one or more neural networks.

The referral system in one embodiment further includes seamless access to guidance, enabling the clinician to read the full guidance from within the same screen without having to look for or browse external resources.

An interface with the eRS allows for the referral system to accurately prepopulate the speciality and clinic type, which in turn, enables the referring clinician to shortlist appropriate providers and book an appointment for the patient.

Based on one or more reasons for referral, medical complexity patient variables, and local rules, the referral system can recognise that in some cases more than one referral is required. In such instances, the system will notify the user and prepare a query to choose relevant providers for the various referrals. The relevant referrals may then be issued to the appropriate providers. The referral system is operated from a single instance. The referrer may not know that more than one referral is required when deciding to refer the patient, but the system will recognise that it is needed ensuring that the rules are enforced.

In order to streamline the flow of data with minimal manual intervention, an interface engine has been developed to be used alongside at least one embodiment of the referral system that is capable of interfacing with various systems. Such systems to be interfaced with may include the national eRS and one or more local hospital systems.

Under pressure to deliver savings, Clinical Commissioning Groups (CCGs) have introduced a range of measures such as GP reviews of referrals, decision support tools and referral management centres (RMCs). Yet despite the substantial investment, there is little evidence of the clinical or financial effectiveness of these initiatives. Existing decision support tools (DXS or Map of Medicine) rely on manual processes and are poorly integrated. They require a clinician to complete a referral letter, often duplicating information, before manually completing the required fields within the national NHS Electronic Referral Service (eRS). Whilst such systems offer a useful repository, they are impractical, and administrative staff are often required to complete a referral leaving the patient confused about their next steps and excluded from the process.

Acting as an intelligent assistant the referral system reviews the relevant patient details, optionally including demographics, medical history, and/or medication, and offers the appropriate list of services in real time. The patient, who may still be with the GP or similar professional, then has a choice of providers given to them with a reduced delay. There is no need to wait a significant amount of time to receive a decision, or for the GP to make a decision on a patient’s behalf which may be against regulations.

Therefore, there is no need to employ additional staff to manage the referral process or to pay for the services of a referral management centre. Although it is appreciated that the option exists for manual intervention and/or review if required. Referring GPs and dentists therefore retain their autonomy in making the right decisions for their patients.

The referral system uses an agreed referral guidance consistently, and all decisions are transparent. A fully authorised referral can be with the healthcare provider in seconds rather than days, and fewer patients are likely to end up in hospital which may be the default for referrers who do not have the time to spend reading the pathways manuals and the options available.

Other similar advantages of the referral system include:

• the option of full automation of the referral system;

• a saving in relation to the cost of manual referral management;

• near-immediate decisions and referrals may be generated;

• quicker for referrers and hence reducing their workload;

• retention of clinical autonomy for the professionals making the referral;

• fewer referrals sent back with errors and omissions;

• improved clinical effectiveness;

• faster and safer referrals;

• interoperability between primary and secondary care;

• real-time reporting of GP referrals;

• savings in relation to medical expenses by directing patients to the best care provider; and/or

• an ability to send multiple referrals from a single instance using only a single form.

Any system feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure. Any feature in one aspect may be applied to other aspects, in any appropriate combination. In particular, method aspects may be applied to system aspects, and vice versa. Furthermore, any, some and/or all features in one aspect can be applied to any, some and/or all features in any other aspect, in any appropriate combination.

It should also be appreciated that particular combinations of the various features described and defined in any aspects can be implemented and/or supplied and/or used independently.

Claims

CLAIMS:

1. A computer implemented method of preparing referral data for a patient, comprising the steps of:

determining one or more relevant sets of rules from rules data;

determining relevant patient data required to apply the one of more relevant sets of rules and obtaining the determined relevant patient data from a patient database;

receiving input data from a user;

determining a relevant set of provider data by applying the one or more sets of rules to the determined relevant patient data and the input data;

obtaining the relevant set of provider data from one or more provider databases; and

determining an output referral data from applying the one or more sets of rules to the determined relevant patient data and the input data and the relevant set of provider data from the one or more provider databases.

2. The computer implemented method of claim 1 wherein the step of determining one or more relevant sets of rules from rules data comprises any or any combination of: receiving one or more relevant sets of rules from rules data; a user selecting one or more relevant sets of rules from rules data; or identifying one or more relevant sets of rules from rules data based on the probability of each of the one or more relevant sets of rules being above a predetermined threshold.

3. The computer implemented method of any preceding claim wherein the step of determining relevant patient data required to apply the one of more relevant sets of rules and obtaining the determined relevant patient data from a patient database comprises identifying what patient data is required to apply the one or more relevant sets of rules and obtaining available relevant patient data from the patient database.

4. The computer implemented method of any preceding claim wherein the step of receiving input data from a user comprises presenting to the user a set of further data required to apply the one or more relevant sets of rules and receiving the further data required to apply the one or more relevant sets of rules as the input data.

5. The computer implemented method of any preceding claim wherein the step of determining a relevant set of provider data by applying the one or more sets of rules to the determined relevant patient data and the input data comprises determining a set of queries to send to the one or more provider databases.

6. The computer implemented method of any preceding claim wherein the step of obtaining the relevant set of provider data from one or more provider databases comprises receiving a set of provider specific data from one or more providers to be used to apply the one or more sets of rules.

7. The computer implemented method of any preceding claim wherein the step of determining an output referral data from applying the one or more sets of rules to the determined relevant patient data and the input data and the relevant set of provider data from the one or more provider databases comprises identifying one or more of the providers to send the output referral data.

8. An automatic referral method, comprising the steps of:

receiving a first input, comprising one or more elements of user data;

applying the first input to a model operable to adapt according to the one or more elements of user data;

generating from the model one or more options for the user; and

verifying that the one or more options are viable.

9. The method of claim 8, wherein the one or more elements of user data comprise one or more of: patient details; patient demographics; medical history; medication; patient allergies; and/or family history.

10. The method of claim 9, wherein the model is operable to adapt further according to one or more of: local pathways; and/or regulatory guidelines.

1 1 . The method of claim 10, wherein the regulatory guidelines comprise one or more guidelines from one or more regulatory bodies.

12. The method of any of claims 8 to 1 1 , wherein the one or more options for the user comprise one or more referral options, optionally wherein the one or more referral options are compliant with the regulations established by one or more regulatory bodies.

13. The method of any of claims 8 to 12, wherein the generation of the model comprises the use of data held in one or more repositories.

14. The method of any of claims 8 to 13, wherein the verifying that the one or more options are viable comprises the use of a rules editor.

15. The method of any of claims 8 to 14, further comprising the steps of:

recognising that one or more further elements of user data are required; and requesting the one or more further elements of user data are provided.

16. The method of any of claims 8 to 15, wherein the step of receiving a first input comprises extracting one or more elements of user data from a remote database.

17. The method of claim 16, wherein the remote database is a cloud database.

18. The method of any of claims 8 to 17, further comprising the step of:

outputting a completed report comprising one or more verified options for the user.

19. The method of any of claims 8 to 18, operable to initiate automatically upon the launch of a predetermined computer program.

20. An automatic referral system, comprising:

a first input, comprising one or more elements of user data; a model operable to adapt according to the one or more elements of user data;

a means operable to generate from the model one of more options for the user; and

a means operable to verify that the one or more options are viable.

21 . The system of claim 20, further comprising a rules editor.

22. The system of claim 21 , wherein the rules editor comprises a graphical user interface (GUI).

23. The system of any one of claims 21 or 22, wherein the rules editor enables a user to create one or more rule-based referral queries.

24. The system of any one of claims 21 to 23, wherein the rule editor comprises one or more of: a question editor; a conditions editor; and/or an action editor.

25. The system of claim 24, wherein the question editor is operable to: view; edit questions; and/or assign question types.

26. The system of claim 24, wherein the conditions editor is operable to: view and/or edit conditions which trigger one or more rules to be initiated.

27. The system of claim 24, wherein the action editor is operable to: view and/or edit actions to execute when a rule is initiated.

28. The system of any one of claims 21 to 27, wherein the rules editor is operable to accept one or more medical coding systems and/or a natural language input.

29. The system of any one of claims 21 to 28, wherein the rules editor is operable to generate one or more rules comprising one or more logical arguments.

30. The system of any one of claims 21 to 29, wherein the rules editor is operable to intelligently display data held in one or more remote databases.

31 . The system of claim 30, wherein the one or more remote databases comprise one or more cloud storage facilities.

32. The system of any one of claims 21 to 31 , further comprising a document uploader module.

33. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any preceding method claim.

34. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of any preceding method claim.