Electronic prescription management system

Abstract

Disclosed is a computer-implemented bulk prescription tool that includes: (i) a script generation tool for creating a bulk prescription order having a plurality of order rows, each row including a patient data field and a medication data field. The script generation tool populates the order rows by: (a) manual data entry; (b) importation of a digital list that includes patient data; and / or (c) a user selecting a standing order that defines a set of medications associated with a healthcare professional, facility, and / or medical procedure. Selecting a standing order populates a nominated set of rows with the medications defined that standing order. The bulk prescription tool also includes: (ii) a bulk approval tool for approving all order rows within the bulk prescription order in a single action and transmitting the approved order to an ePrescribing tool to generate an eScript for each order row.

Description

ELECTRONIC PRESCRIPTION MANAGEMENT SYSTEMRelated Application

[0001] This application is related to Australian Provisional Patent Application No. 2023904234 titled “Computer-Implemented Method And System For Bulk Prescriptions” and filed 22 December 2023, the entire content of which is incorporated by reference as if fully set forth herein.Technical Field

[0002] The present disclosure relates to a computer-implemented method and system for bulk prescriptions. In particular, the present disclosure relates to a computer-implemented method and system for creating and approving bulk prescription orders.Background

[0003] A prescription is a legal document that is prepared by a registered health practitioner that authorises dispensation of a specified medicine for a nominated patient. Health practitioners that are able to write prescriptions typically include medical doctors, dentists, and veterinarians. Dispensation is typically performed by a pharmacist. Prescriptions are often colloquially referred to as “scripts”.

[0004] Traditionally, prescription pads have been issued to health practitioners and the health practitioner completed a prescription for a patient by manually entering the patient information and prescribed medication information by handwriting the required information onto a page of the prescription pad. The prescribed medication information includes the name of the prescription medication, the dosage, and dosage regime. The dosage regime may include, for example, when to take the prescription medication and any associated requirements, such as the need to take the prescription medication with food.

[0005] There are three clinical environments at which doctors prescribe medications: general practitioner / specialist consulting rooms; hospitals, and nursing homes / aged care facilities. In each of these clinical environments, a doctor prescribes medication in relation to a single patient file or single medication chart.

[0006] Many doctors, particularly specialists, practise within a particular area of medicine and thus there is often some commonality among the conditions for which patients are being treated. Consequently, a doctor often prescribes the same medication for multiple patients. For example, an orthopaedic surgeon performing knee replacementswill typically prescribe pain medication and anti-inflammatory medication to patients following surgery. In order to do so, the doctor must complete individual prescriptions for each patient, completing each prescription with the required information that is often the same across multiple patients. This takes a significant amount of time, which prevents the doctor from attending to other patients.

[0007] In the hospital environment or day surgery environment, patients are generally supplied medications directly by the hospital, but medications can also be supplied by an external pharmacy if a script was written for the patient. Writing a single prescription is often too tedious for doctors and thus the hospital pays for the medications directly. If there was a script could be approved and written, the medications could be claim from a Pharmaceutical Benefits Scheme (PBS), saving the hospital from paying for the medications directly and thus saving the hospital a lot of money.

[0008] Thus, a need exists to provide a method and system for handling the bulk creation and transmission of prescriptions.Summary

[0009] The present disclosure relates to a computer-implemented method and system for creating and transmitting bulk prescription orders.

[0010] A first aspect of the present disclosure provides a computer-implemented bulk prescription tool comprising:(i) a script generation tool for creating a bulk prescription order that includes a plurality of order rows, each order row including a patient data field and a medication data field, wherein the script generation tool populates the order rows by at least one of:(a) manual data entry;(b) importation of a digital list from an external source, the digital list including at least patient data; and(c) a user selecting a standing order from a set of stored standing orders, wherein each standing order defines a set of medications associated with at least one of a healthcare professional, a healthcare facility, and a medical procedure, wherein selecting a standing order populates a nominated set of order rows with the set of medications defined by the selected standing order; and(ii) a bulk approval tool having a practitioner interface that includes: a display region for displaying, to an authorised user, the bulk prescription order; anda submission button for receiving input from the authorised user to approve all order rows within the bulk prescription order in a single action; wherein the bulk prescription tool transmits the approved bulk prescription order to an ePrescribing tool to generate an eScript for each order row of the approved bulk prescription order.

[0011] A second aspect of the present disclosure provides a system comprising:(i) a patient link tool configured to interface with practice management software at a healthcare facility to: extract patient data from the practice management software; and populate a digital list with the patient data;(ii) a script generation tool for creating a bulk prescription order that includes a plurality of order rows, each order row including a patient data field and a medication data field, wherein the script generation tool populates the order rows by importing the digital list from the patient link tool; and(iii) a bulk approval tool having a practitioner interface that includes: a display region for displaying, to an authorised user, the bulk prescription order; and a submission button for receiving input from the authorised user to approve all order rows within the bulk prescription order in a single action;(iv) an ePrescribing tool for generating an eScript for each order row of the approved bulk prescription order.

[0012] A third aspect of the present disclosure provides a computer-implemented bulk prescription tool comprising: a presentation interface for receiving input relating to a bulk prescription order, wherein the bulk prescription order includes multiple order rows, each order containing a patient data field and a medication data field; a processor; a second computer-readable storage medium for storing computer code instructions that when executed on the processor perform the method steps of: based on the received user input, creating a bulk prescription order; populating patient data fields and medication data fields for a plurality of rows; and approving all order rows in the bulk prescription order.

[0013] According to another aspect, the present disclosure provides an apparatus for implementing any one of the aforementioned methods.

[0014] According to another aspect, the present disclosure provides a computer program product including a computer readable medium having recorded thereon a computer program that when executed on a processor of a computer implements any one of the methods described above.

[0015] Other aspects of the present disclosure are also provided.Brief Description of the Drawings

[0016] One or more embodiments of the present disclosure will now be described by way of specific example(s) with reference to the accompanying drawings, in which:

[0017] Fig. 1 is a schematic block diagram representation of a bulk prescription ordering system in accordance with an embodiment of the present disclosure;

[0018] Fig. 2 is a schematic block diagram representation of an example of an information technology architecture for a medical practice utilising the bulk prescription ordering system in accordance with an embodiment of the present disclosure;

[0019] Fig. 3 illustrates a flow of information input to a presentation interface of a bulk prescription tool;

[0020] Fig. 4 is a screenshot of a patient order window of the presentation interface;

[0021] Fig. 5 is a schematic block diagram representation of the functional modules of a bulk prescription tool;

[0022] Fig. 6A is a schematic block representation of importing data from a dispensing system to a bulk prescription tool;

[0023] Fig. 6B is a screenshot of a Dispense System Import Screen that enables a user to import scripts from a dispensing system;

[0024] Fig. 7 is a schematic representation illustrating importation of data from a patient link tool;

[0025] Fig. 8 is a schematic representation illustrating data flow in relation to a Standing Orders Module;

[0026] Fig. 9A shows a bulk order user interface;

[0027] Fig. 9B shows a standing orders user interface;

[0028] Fig. 10 illustrates the functionality of a Script Approval Screen;

[0029] Fig. 11 illustrates functionality of a Views Module Screen;

[0030] Fig. 12 illustrates the functionality of an ePrescribing Module;

[0031] Fig. 13 is a schematic block diagram representation of a system on which the electronic document management system of the present disclosure may be practised;

[0032] Fig. 14 is a schematic block diagram of a system that includes a general purpose computer that may be configured to provide a bulk prescription tool in accordance with the present disclosure;

[0033] Fig. 15 is a schematic block diagram representation of a computer-implemented bulk prescription system that includes an optional automated dispensing module and an optional government services module;

[0034] Fig. 16A is a flow diagram representation of a paper based prescription generation and approval process; and

[0035] Fig. 16B is a flow diagram representation of a computer-implemented paperless prescription generation and approval process in accordance with the present disclosure.

[0036] Method steps or features in the accompanying drawings that have the same reference numerals are to be considered to have the same function(s) or operation(s), unless the contrary intention is expressed or implied.Detailed Description

[0037] The present disclosure provides a computer-implemented method and system for creating, approving, and transmitting bulk prescription orders relating to multiple patients and multiple medications. In particular, embodiments of the system described herein provide a bulk prescription tool that incorporates a graphical user interface by which a registered health practitioner or other authorised user is able to create and complete bulk prescription orders. Each bulk prescription order includes multiple prescriptions relating to multiple patients and multiple medications.

[0038] The bulk prescription tool captures the clinical consent of the health care practitioner as bulk prescription orders in a conformant system and transmits the bulk prescription orders to a conformant prescribing system via a communications network.

[0039] In some embodiments, the bulk prescription tool of the present disclosure includes two components: (i) a presentation interface; and (ii) an intermediary component. The presentation interface is a graphical user interface presented to a display of a computing device utilised by a health practitioner to create a digital list that can beconverted to a bulk prescription order for multiple patients and multiple medications. The presentation interface is configured to interact with practice management system software that stores patient data, in order to populate a bulk order with that patient data.

[0040] The bulk prescription tool includes a practitioner interface that includes an authentication device that validates the health practitioner with a single sign-on. The intermediary component generates a compliant bulk prescription order using a compliant prescribing software application in order to generate electronic prescriptions.

[0041] A doctor logs into a the practitioner interface using a unique username and password. In some embodiments, the practitioner interface forms part of a software application executing on a practitioner computing device. In other embodiments, a web-based application executes on a practitioner computing device, with the web-based application hosted on a web-based computer server or cloud-hosted computing environment.

[0042] The authentication device of the practitioner interface validates the username and password, such as by comparing the entered information against a stored set of user profiles. Once the doctor has been authenticated, the practitioner interface enables the doctor to approve a new bulk prescription order. In some embodiments, the bulk prescription order includes preloaded medication orders. The medication orders are preloaded to save the doctor from entering the medication orders manually. The doctor may also create a new bulk prescription order and add medication orders manually to existing bulk prescription orders.

[0043] In some embodiments, for example, the bulk prescription tool ingests external data to auto-populate medication orders in the bulk prescription order. In particular, some embodiments utilise the presentation interface interacting with local practice management software and / or manual data entry performed at a healthcare practice to create a digital list of patients. The digital list may also include corresponding medications and / or corresponding surgical procedures. The digital list is ingested by the bulk prescription tool to preload the new bulk prescription order, ready for approval by the doctor.

[0044] In cases in which the digital list includes a medical or surgical procedure, the bulk prescription tool optionally maps each medical or surgical procedure against a set of standing orders in order to preload the bulk prescription order with medications corresponding to that procedure.

[0045] The practitioner interface includes a set of order rows, with each row corresponding to a patient. Each row includes fields for patient data and medication data.Each row optionally includes other fields, such as procedure, other medication data, allergies, and the like. Thus the practitioner interface allows multiple patients to be listed within a single order screen by displaying multiple order rows.

[0046] The doctor is able to review and approve a set of medications for each listed patient. As described above, medications can be preloaded to save the doctor time from manually entering that information. Thus, a single order screen relates to multiple patients and multiple medications. There is no technical limit to the number of patients that can be listed within a single order screen of the practitioner interface, but particular embodiments may set a predefined limit to the number of patients.

[0047] The order screen is configured so as to satisfy clinical and legal requirements pertaining to the writing of prescriptions. In some embodiments, the practitioner screen includes a set of mandatory patient fields to be completed. These patient fields may include, for example, but are not limited to, patient name, patient date of birth, and patient address.

[0048] The mandatory data fields for prescriptions may vary across jurisdictions. For Australia, the mandatory data fields include: patient first name, patient last name, sex, date of birth, address, Medicare Number, Medicare Reference Number, Doctor Prescriber Number, Date, Location, Status, and Procedure. When a doctor logs into the bulk prescription tool, the bulk prescription tool auto-populates new bulk orders with the relevant information associated with the doctor (e.g., Doctor Prescriber Number, Date, and Location). The other order fields are completed during creation or editing of a bulk order.

[0049] In some embodiments, existing patient information is stored as a set of patient profiles and the presentation interface provides an interface by which a clinical assistant or doctor is able to select from the set of patient profiles stored in the Practice Management System. On selecting a patient from the set of patient profiles, such as from a drop-down list or browsing window, the bulk prescription tool populates an order row with patient information associated with the selected patient. This saves time and minimises human error. As long as the patient information stored in the patient profiles is accurate, then the patient information entered in the order form will be accurate.

[0050] In some embodiments, a user utilises a barcode scanner to scan a barcode, such as a 2D barcode or QR code, associated with a patient record in order to identify a patient. The presentation interface reads the scanned barcode and populates patient data fields of an order row.

[0051] A user optionally scans a barcode of medication in order for the presentation interface to populate a medication field of an order row. Alternatively, the user utilises an input method to input the medication for an order row. Medication input methods may include, for example, drop-down lists, searchable databases, a browsing window displaying available medications, or the like.

[0052] In some embodiments, the practitioner interface includes search functionality to enable a user to search for patient data, medication data, dates, and the like.

[0053] In some embodiments, the practitioner interface includes search functionality to enable a user to search and review past order information.

[0054] In some embodiments, search functionality provided with the practitioner interface is presented as a separate display region within a window displayed on a screen. In other embodiments, the search functionality is provided as a separate window of the practitioner interface.

[0055] Depending on the implementation, search functionality provided with any embodiment of the practitioner interface optionally includes filters that enable a user to search and / or sort based on user, patient, creation date, medication, procedure, order submission date, or any combination thereof.

[0056] Once a doctor has finished entering data for a current set of patients, the doctor activates a submission button on the practitioner interface, thus approving the entire order with a single action. Depending on the implementation, the submission button may be an on-screen button activated by a mouse-click, gesture, keyboard press, or the like. Thus, the bulk prescription tool enables bulk approval of multiple medications for multiple patients.

[0057] Once a doctor has submitted a bulk order, the bulk prescription tool checks that all mandatory fields have been completed. If there are any fields that require attention, the practitioner interface alerts the user. The bulk prescription tool then converts the bulk medication orders into electronic prescriptions (eScripts) via electronic prescribing software, such eRx Script Exchange.

[0058] That is, the bulk prescription tool transmits the approved bulk order to ePrescribing software that generates prescription orders. Prescription orders are then sent to an approved prescription vendor, such as eRx. The approved prescription vendor converts the prescription orders into eScripts, such as by generating tokens based on the received bulk order. The approved prescription vendor stores the tokens and transmits the tokens to all participants. eScripts are “electronic scripts” and are prescriptionspresented in a digital format. eScripts are readily transmitted by email, SMS text message, computer messaging services, or the like.

[0059] In the case of eRX, which is presently the only government approved prescription network in Australia, ePrescribing software sends a “prescription order” to eRx, which then turns the prescription order into a token / eScript and stores the tokens / eScripts in a central government repository. eRX stores and send and receives tokens / eScripts to whoever needs the tokens / eScripts. Tokens / eScripts are only generated by eRX based on a “prescription order” received from an ePrescribing software.

[0060] Fig. 1 is a schematic block diagram representation of a bulk prescription ordering system 100 in accordance with an embodiment of the present disclosure. The system 100 includes three sites: a medical practice 110; a cloud-computing environment 150; and a dispensing location 180. The medical practice 110 may be any location at which prescriptions are written, including general practitioner or specialist consulting rooms, a hospital, or nursing home.

[0061] The cloud-computing environment 150 may be a cloud-hosting environment, such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, vmware, AlertLogic, SoftLayer, or the like. Alternatively, the cloud-computing environment may relate to a computer server connected to a communications network. The communications network may comprise one or more wired communications links, wireless communications links, or any combination thereof. In particular, the communications network may include a local area network (LAN), a wide area network (WAN), a telecommunications network, or any combination thereof. A telecommunications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network (PSTN) or a cellular mobile telephony network, the Internet, or any combination thereof.

[0062] In the example of Fig. 1 , the medical practice 110 includes a practice management system 112. In the example of Fig. 1 , the practice management system is implemented using BP VIP.NET, but any other practice management system may equally be utilised. The practice management system 112 stores patient data associated with patients that visit the medical practice 110.

[0063] The medical practice 110 also includes a presentation interface 114, which may be embodied as a graphical user interface presented to a display of a computing device. The practice management system 112 and presentation interface 114 may beimplemented using separate software applications executing on a single computing device or separate computing devices.

[0064] The presentation interface 114 is associated with a bulk prescription tool server 155 in the cloud-computing environment 150 and provides a tool by which to import data to the bulk prescription tool in order to preload bulk prescription orders. As described above, the presentation interface 114 may be implemented as a native software application executing on a computing device located at the medical centre 110.Alternatively, the presentation interface 114 may be implemented as a web-based application accessed through a browser that communicates with an application hosted on the bulk prescription tool server 155. The presentation interface 114 may also be implemented as an extension of existing software, such as practice management software or pharmacy dispensing software.

[0065] The presentation interface 114 is programmed to communicate with the practice management system 112 in order to import patient data. Depending on the implementation, the presentation interface 114 optionally imports doctor data, medication data, procedural data, surgical lists, and the like.

[0066] In use, a user accesses the presentation interface 114 by signing in and then creating a digital list for multiple patients. The digital list may also include medication data, doctor data, procedural data, surgical procedure data, and the like. The presentation interface 114 transmits the digital list, via a communications network, to the bulk prescription tool server 155. The bulk prescription tool server 155 preloads a new bulk prescription order based on contents of the ingested digital list for approval by an authorised practitioner. The bulk prescription tool then transmits the bulk order to the dispensing location 180. The dispensing location 180 receives the bulk order and adds the bulk order to a pharmacy worklist.

[0067] In the example of Fig. 1 , the dispensing location 180 interfaces with an external agency, such as the Provider Digital Access (PRODA) online platform, to verify repeats for the prescriptions on the pharmacy worklist.

[0068] Fig. 2 is a schematic block diagram representation of an example of an information technology (IT) architecture 200 for the medical practice 110 of Fig. 1 , relating to the ingestion of data by the bulk prescription tool from a practice management system. The IT architecture 200 includes a local communications network 230 that may be implemented using one or more wired communications links, wireless communications links, or any combination thereof. In particular, the local communications network mayinclude a local area network (LAN), a wide area network (WAN), or a combination thereof. In the example of Fig. 2, the IT architecture 200 also includes a wireless communication network 240, which may be implemented using Wi-Fi, Bluetooth, or any other suitable wireless communication protocol. The wireless communication network 240 may be separate or integral with the local communications network 230.

[0069] Practice management software executes on a server 210 that is coupled to the local communications network 230. In the example of Fig. 2, the IT architecture includes a computing device 220 in the form of a personal computer running Microsoft Windows and executing a local web server that produces a presentation interface 114 for practice staff to access securely in the context of the local network. It will be appreciated that other computing devices may equally be practised to deliver the presentation interface to practice staff. The IT architecture 200 also includes a portable computing device 250, which may be implemented as a tablet computing device, laptop computer, smartphone, or the like. The portable computing device 250 includes a wireless transceiver that enables the wireless computing device 250 to couple to the wireless communications network 240.

[0070] The IT architecture 200 further includes a desktop computing device 260. Depending on the implementation, the desktop computing device 260 is able to couple to the wireless communications network 240, the local communications network 230, or a combination thereof. For example, the desktop computing device may be implemented as a personal computer with an Ethernet port and Wi-Fi connectivity.

[0071] A user is able to utilise either the portable computing device 250 or the desktop computing device 260, or any other computing device coupled to the local communications network 230, to access the presentation interface 114 in order to import data from the practice management system to create a digital list for export to the bulk prescription tool.

[0072] Fig. 3 illustrates a flow of information into the presentation interface when executing on the computing device 260 of Fig. 2. The presentation interface receives from the practice management system executing on the server 210 various patient data. The patient data may include, for example, name, date of birth, sex, address, Medicare details, health fund details, and the like.

[0073] The presentation interface also optionally receives medication data as an input. In the example of Fig. 3, the medication data includes medication date, date of delivery, and batch number. Depending on the implementation, the medication data is input by auser manually using a keyboard associated with the computing device 260, input via a scanning device, or selected by a user using a graphical user interface of the presentation interface.

[0074] Fig. 4 is a screenshot of a patient order window 400 of the presentation interface for receiving input pertaining to an order row of a digital list that will be sent to the bulk prescription tool for conversion to a bulk order. The patient order window 400 includes a patient field 410 that displays patient information, a medication window 420 that displays medication data, and a prescribing doctor window 430. In the example of Fig. 4, the prescribing doctor window 430 includes a selection device in the form of a drop-down list for selecting a doctor, along with a date field.

[0075] In the example of Fig. 4, the patient order window 400 also includes a menu bar 440 with options for starting a new bulk order, viewing a patient list, and viewing past orders. Thus, the presentation interface provides options for pulling data from the practice management system, thus saving time and minimising clerical errors. In the example of Fig. 2, the computing device 220 runs a web server for hosting the presentation interface and thus controls the extraction of data from the practice management system, receipt of manually entered data, creation of digital lists, and exportation of digital lists to the bulk prescription tool server 155.

[0076] The intermediary component forms part of the bulk prescription tool server 155 of Fig. 1 . The intermediary component performs the functions of exporting data to the dispensing location 180, and importing patient data and clinical data.

[0077] The intermediary component receives a digital list from the presentation interface, preloads data from the digital list into a bulk order for approval, and then processes the approved bulk order into a format compatible with an existing conformant prescribing software, such as Best Practice, RxPad, and the like.

[0078] Processing of the bulk order also optionally includes secondary clinical checks by a pharmacist before creation of the order in a conformant prescribing software. In some scenarios, prescriptions are straightforward, with well-defined dosages prescribed for a patient. In other scenarios, such as for complex and / or expensive medications, special permission is first need from the government (e.g., PRODA), before medications can be dispensed. Permission is only granted if the correct number of repeats, indications, patient details, etc. are provided. So the pharmacist needs to check all the details before the script is generated that has all the right codes, so the script can be dispensed properly.

[0079] The intermediary component includes functionality for importing clinical patient demographic information and medication orders to allow patients and their medications to be added to the order. The data can be from paper records that is manually entered into the system or data imported from the patient management system of a healthcare practice. The system can also import paper medications orders or preloaded orders from a pharmacy dispensing system.

[0080] In many cases, a doctor will prescribe a set of standard medications for a procedure. That is, a doctor will generally prescribe the same medications for all patients undergoing a particular clinical procedure (e.g., cataracts, colorectal surgery, knee replacement, ...). The set of standard medications for a particular procedure may be referred to as “standing orders”.

[0081] In some scenarios, a surgeon has a surgical list of 10 to 20 patients for the same medical procedure. If the surgeon prescribes the same three medications for each of the patients, that surgeon will have to handwrite up to 60 prescriptions each day. There is also the physical handling of patient files, incurring a large administrative overhead.

[0082] The bulk prescription tool provides an automated process for creating bulk orders for multiple patients and multiple medications. In some embodiments, the bulk prescription tool stores a set of standing orders. Each standing order relates to at least one of a particular healthcare professional, a medical procedure, and a healthcare facility. That is, a standing order may relate to a single healthcare professional or, in more particular cases, may be created in relation to a healthcare professional performing a particular procedure at a particular healthcare facility.

[0083] The bulk prescription tool stores the set of standing orders in a computer- readable storage medium, such as a database. In some embodiments, the set of standing orders are stored in a cloud-hosted platform, so as to be accessible from anywhere.

[0084] When a user creates a digital list or modifies a bulk order, the user is able to select from the set of standing orders in order to populate the medications for one or more of the patients on the digital list or bulk order, or for all of the patients on the digital list or bulk order. For example, a user utilises the presentation interface to create a digital list based on importing a surgical list of 20 patients from practice management software, with each patient having a cataracts procedure.

[0085] Similarly, when a user accesses the presentation interface, the user can select from the stored set of standing orders to populate medications on a digital list.

[0086] The user selects a standing order for cataracts and selects that standing order to populate for all patients on that digital list. The bulk prescription tool populates the medication field for each patient with the medications stored in the selected standing order for cataracts.

[0087] The set of standing orders provides further efficiency in the creation of a bulk order of prescriptions. Further, such standing orders reduce human errors in the writing and interpretation of handwritten scripts, as well as saving doctors significant amounts of time on a regular basis.

[0088] Fig. 5 is a schematic block diagram representation of the functional modules of a bulk prescription tool 155 in accordance with an embodiment of the present disclosure. In the example of Fig. 5, the bulk prescription tool 155 includes a Script Generation Module 510, a Standing Orders Module 520, a Script Approval Module 530, and an ePrescribing Module 540.

[0089] In the example of Fig. 5, the Script Generation Module 510 imports medication orders for a doctor to approve. Medication orders can be imported from a dispensing system 504, a patient linking tool 506, imported from a standing order / patient list 502, or any combination thereof.

[0090] In the example of Fig. 5, the Script Generation Module 510 includes: a Dispense System Import Module 512 that interfaces with a dispensing system 504; and a Patient Link Tool Module 514 that interfaces with a patient linking tool 506 of a practice management system. Each of the dispensing system 504 and patient linking tool 506 is able to generate a digital list for ingestion to the Script Generation Module 510. As described above, the digital lists may include patient data, medication data, doctor data, surgical procedure data, and the like, or any combination thereof.

[0091] The Standing Orders Module 520 stores a set of standing orders that can be selected by a user to assist in completing a digital list that will, in turn, form a bulk prescription order. To create a standing order, a user enters a list of medications associated with a procedure. As indicated above, the standing order may also be associated with a particular healthcare facility.

[0092] In some embodiments, a user imports a surgical list of patients for a particular procedure, such as from a patient linking tool of a practice management system. The bulk prescription tool 155 populates patient fields in a new bulk order based on an imported digital list. In creating the digital list, a user, such as a clinical assistant, uses a user interface of the presentation interface to select a standing order corresponding to theparticular doctor, the particular procedure, and the healthcare facility at which the procedures are to be performed. The presentation interface then populates order rows of the digital list with the medications from the selected standing order.

[0093] Similarly, a doctor reviewing a bulk order via the practitioner interface is able to modify one or more order rows of the bulk order by selecting a standing order corresponding to the particular doctor, the particular procedure, and the healthcare facility at which the procedures are to be performed. The bulk prescription tool 155 then autopopulates the medication fields for the respective patients in the bulk order. This provides a quick, accurate, and consistent mechanism to generate a bulk prescription order.

[0094] The Script Approval Module 530 provides an interface that enables a doctor to approve loaded medications from a single Approval Screen 532 (corresponding to screen 116). The doctor is able to view multiple patients and associated medications in bulk orders. A Views Module 534 enables the doctor to sort and filter based on one or more viewing parameters. The viewing parameters may include, for example, selected date, date range, medication, location, procedure, patient name, and the like. Relevantly, the doctor is able to approve the bulk order, directed to a plurality of patients and a plurality of medications, in a single step.

[0095] The ePrescribing Module 540 converts approved bulk orders into prescription orders, which then sent to eRx to convert into eScripts / tokens. In some embodiments, the conversion is performed by the ePrescribing Module 540. In other embodiments, the ePrescribing Module 540 interfaces with an external ePrescribing tool, such as eRx script exchange 550, to generate the eScripts.

[0096] Fig. 5 also shows a User / Web Interface 580 accessed by a doctor 590 in order to interact with the bulk prescription tool 155. The User / Web Interface 580 interacts with the Standing Orders Module 520 and the Script Approval Module 530 to create, edit, and view bulk prescription orders.

[0097] Fig. 6A is a schematic block representation of importing data from a dispensing system 604 to the bulk prescription tool 155. A pharmacy 602 is associated with the pharmacy dispensing system 604. The pharmacy dispensing system 604 interacts with the Dispense System Import Module 512 of the bulk prescription tool 155.

[0098] The pharmacy 602 receives a paper list of patients and associated medications to be approved before being dispensed. The pharmacy 602 loads the scripts into the pharmacy dispensing system 604. The bulk prescription tool 155 extracts the scripts for approval into the Dispense System Import Module 512.

[0099] Fig. 6B is a screenshot of a Dispense System Import Screen 620 that enables a user to import scripts from a dispensing system 604. The Dispense System Import Screen 620 provides the user with the option of filtering based on doctor and / or date range and provides a status region that indicates the number of scripts imported, the number of patients imported and status of the importation of data.

[0100] Fig. 7 is a schematic representation illustrating importation of data from the patient link tool 114. Practice management software 112 stores all patient demographic information and interfaces with the patient link tool 114. The patient link tool 114 interfaces with the Patient Link Tool Module 514 of the bulk prescription tool 155.

[0101] The Patient Link Tool Module 514 extracts and imports patient data and medication data from the patient link tool 114. The patient link tool 114 is associated with the bulk prescription tool 155 and is software available within a healthcare practice 110, as described with reference to the web server executing on the computing device 220 of Fig. 2.

[0102] Thus, the patient link tool is able to read data from the practice management software 112 to extract and import into the patient data stored by the bulk prescription tool 155. The patient link tool 114 provides a user interface to enable a practice user to enter patient data and medication data, such as by scanning a patient file or medication barcode, or manually entering using a keyboard, or other input means.

[0103] Fig. 8 is a schematic representation illustrating data flow in relation to the Standing Orders Module 530 of Fig. 5. In the example of Fig. 8, the pharmacy receives a surgical list of patients, but no medications. The pharmacy dispense system 604 transmits patient data to the Dispense System Import Module 512 of the bulk prescription tool 155. In this example, the patient data includes patient name, date, hospital, and procedure data. The patient data may also include patient sex, patient address, and the like.

[0104] Depending on the implementation, the pharmacy dispense system 604 pushes the data to the bulk prescription tool 155 or the bulk prescription tool pulls data from the pharmacy dispense system 604.

[0105] The Dispense System Import Module 512 populates a new bulk order with the imported patient data. The doctor 590 utilises the Web / User Interface 590 to access the bulk prescription tool, in order to manage the bulk order

[0106] The Web / User Interface 590 communicates with the Standing Orders Module 520 in order to provide the doctor 590 with the option of selecting a standing order from aset of stored standing orders. In some embodiments, each standing order is associated with a prescribing doctor, hospital, and procedure. The Web / User Interface 580 only presents standing orders that match the doctor 590. The Web / User Interface 580 also enables a doctor or other user to create or modify standing orders.

[0107] The doctor 590 can select the standing order to apply to one, some, or all of the patients in the bulk order. For example, if the surgical list received by the pharmacy 602 related to 20 patients, of whom 10 were undergoing procedure 1 , 6 were undergoing procedure 2, and 4 were undergoing procedure 3, the doctor 590 may approve three different standing orders (corresponding to procedure 1 , procedure 2, and procedure 3, respectively) to complete the bulk order.

[0108] Fig. 9A shows a bulk order user interface 910, such as that provided by the User / Web Interface 580 to the doctor 590 in relation to creating or modifying a bulk order. The bulk order user interface 910 includes an order row for each patient. Each order row includes a set of fields that may include, for example, patient data and medication data. Other fields may include, for example, prescription data, location, quantity of medication, notes, and status.

[0109] Each order row relates to a single patient-medication combination, which corresponds to a single prescription to be generated. Thus, if Patient A needs 3 medications, then there will be 3 order rows corresponding to Patient A-medication 1 , Patient A-medication 2, and Patient A-medication 3.

[0110] Fig. 9B shows a standing orders user interface 920, such as that provided by the User / Web Interface 580 to the doctor 590 in relation to creating, modifying, or selecting a standing order from the Standing Orders Module 520. In the example of Fig. 9B, the standing orders user interface 920 displays a set of 3 standing orders from which the doctor 590 may select to view or download.

[0111] A first standing order corresponds to the procedure Cataracts, for all locations, and defines a set of 3 medications (including the dosage regime). A second standing order corresponds to the procedure Refractive Lens Exchange, for all locations, and defines a set of 4 medications. A third standing order corresponds to the procedure ICL surgery, for all locations, and defines a set of 5 medications. Each of the standing orders is associated with a creation date.

[0112] Fig. 10 illustrates functionality of the Script Approval Screen. The doctor 590 accesses the Web / User Interface 580 and is presented with a Login Screen 584. The doctor 590 enters a unique username and password, the combination of which is a legalsubstitute for a signature in some jurisdictions. The username is linked to a Doctor Prescriber Number. The username and password are verified by an authentication module (not shown) of the bulk prescription tool 155.

[0113] Once the doctor 590 has successfully logged in, the Script Approval Module 530 generates an Approvals Screen 582 displayed on a screen that displays all unapproved medications, based on the Doctor Prescriber Number associated with the username. The Approvals Screen 582 enables the doctor 590 to approve multiple patients and multiple medications in a single screen.

[0114] Fig. 11 illustrates functionality of the Views Module Screen. The doctor 590 accesses the Web / User Interface 580 and is presented with a Views Module Screen 586. The Views Module Screen 586 enables the doctor 590 to view medications to be approved based on the Doctor Prescriber Number associated with the username of the doctor 590. The Views Module Screen 586 enables the doctor 590 to filter and sort medications to be approved based on one or more viewing parameters. Depending on the implementation, the viewing parameters may include, for example, selected date, date range, medication, location, procedure, patient name, and the like, or any combination thereof.

[0115] Fig. 12 illustrates the functionality of the ePrescribing Module 540 of Fig. 5. The ePrescribing Module 540 optionally interfaces with one or more external ePrescribing Tools 570 in order to generate prescription orders for transmission to the eRx script exchange 550, or similar provider.

[0116] The ePrescribing Module 540 converts a list of approved medications into prescription orders to be transmitted to eRx script exchange 550 that will then create a legal eScript / Token

[0001] Fig. 13 is a schematic block diagram representation of a system 1300 on which one or more embodiments of a bulk prescription tool of the present disclosure may be practised. The system 1300 includes a bulk prescription tool 1350 coupled to a communications network 1305. The communications network 1305 may comprise one or more wired communications links, wireless communications links, or any combination thereof. In particular, the communications network 1305 may include a local area network (LAN), a wide area network (WAN), a telecommunications network, or any combination thereof. A telecommunications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network (PSTN) or a cellular mobile telephony network, the Internet, or any combination thereof.

[0117] In the example of Fig. 13, the bulk prescription tool 1350 is shown as a computer server. However, in practice the bulk prescription tool 1350 may be implemented using one or more computing devices, such as a general purpose computer, computer server, distributed cloud-based architecture, a combination thereof, or any similar architecture that is programmed to perform one or more of the functions shown and described in relation to Figs 1 to 12, thus giving rise to a new and improved computing device for the creation and distribution of bulk prescription orders relating to multiple patients and multiple medications.

[0118] The bulk prescription tool 1350 includes a User Interface module 1352 that implements the presentation interface described herein. The User Interface module 1352 also presents, to a display of a computing device, log in screens, viewing screens, and the like. The bulk prescription tool 1350 also includes a Script Generation module 1354, a Script Approval module 1356, an ePrescribing Module 1362, a processor 1364, a Standing Orders module 1366, a local storage device 1358, and an optional external storage device 1368.

[0119] Each of the User Interface 1352, Script Generation module 1354, Script Approval module 1356, ePrescribing Module 1362, processor 1364, Standing Orders module 1366, and local storage device 1358 communicate via one or more communication links, including buses, represented by the bus 1391 .

[0120] The local storage device 1364 and external storage device 1368 may store computer code instructions relating to a bulk prescription tool, patient data, medication data, standing orders, or any combination thereof.

[0121] In the example of Fig. 13, the bulk prescription tool 1350 includes an optional Application Programming Interface (API) 1360, which enables communication between the bulk prescription tool and third party software applications developed in according with the protocols of the API 1360.

[0122] The system 1300 also includes a healthcare practice computer 1310 coupled to the communications network 1305. The healthcare practice computer 1310 includes a communications module for managing communications with external computing devices, such as the bulk prescription tool 1350. The healthcare practice computer 1310 also includes a healthcare storage device for storing patient data relating to patients of that healthcare practice, as well as practice management software. The practice management software executes on a microcontroller 1314.

[0123] The system 1300 further includes an eRX Script Exchange 1390, with which the bulk prescription tool 1350 optionally interacts to generate electronic prescriptions from completed bulk prescription orders.

[0124] A doctor 1320 accesses a doctor computing device 1325 coupled to the communications network 1305 in order to access the bulk prescription tool 1350. The doctor computing device 1325 may be implemented using a general purpose computing device and need not be specific to the doctor 1320. For example, the doctor computing device 1320 can be implemented as a personal computer, laptop computer, tablet computing device, phablet computing device, smartphone or the like.

[0125] An initial authentication procedure requires the doctor 1320 to enter a unique username and password. The bulk prescription tool 1350 authenticates the doctor 1320 by matching the input username and password against stored prescriber profiles. The usernames are unique and identify the doctor, enabling the bulk prescription tool to validate the doctor 1320 as a user able to write prescriptions, as each prescriber profile stores a prescriber name and registered prescriber number.

[0126] In some implementations, a software application associated with the bulk prescription tool executes on the doctor computing device 1325 and exchanges information with the bulk prescription tool 1350 via the communications network 1305. In other implementations, the bulk prescription tool provides a web-based application accessible to the doctor 1320 via a browser executing on the doctor computing device 1325. In yet other implementations, both a native software application and web-based application are available in association with the bulk prescription tool 1350.

[0127] The doctor 1320 utilises the doctor computing device 1325 to access the bulk prescription tool 1350. The presentation interface of the bulk prescription tool 1350 enables the doctor 1320 to create, view, and modify bulk prescription orders.

[0128] The bulk prescription tool 1350 receives user input from doctor computing device 1325, as input by the doctor 1320, in order to create and complete a bulk prescription order.

[0129] To facilitate the creation of bulk prescription orders, the Script Generation module 1354 is configured to import patient data from the healthcare practice computer 1310. In some scenarios, the imported patient data is derived from surgical lists. The bulk prescription tool 1350 auto-populates a new bulk prescription order with the imported patient data.

[0130] The User Interface 1352 enables the doctor 1320 to select a standing order from a set of stored standing orders, wherein each standing order defines a set of medications and relates to at least one of a specified doctor, specified location, or specified medical procedure.

[0131] For example, the doctor 1320 wants to create a bulk prescription order in relation to 10 patients on a surgical list to undergo the same cataracts procedure. The Script Generation module 1354 imports the surgical list from the healthcare practice computer 1310. In this example, the doctor 1320 then uses a drop-down list presented by the User Interface 1352 to select a standing order corresponding to the doctor 1320 and the medical procedure “cataracts”. The User Interface 1352 filters the viewing standing orders to correspond to those standing orders related to the doctor 1320 or the medical procedure. In some embodiments, the User Interface 1352 provides filtering options, so that the doctor 1320 is able to filter the available standing orders. Filtering options may include, for example, medical procedure, medication, location, and the like.

[0132] The bulk prescription tool populates medication fields in the bulk prescription order created by the doctor 1320, or arising from the importation of a surgical list from the healthcare practice computer 1310. Depending on the user input from the doctor 1320, the medications defined by the selected standing order are populated for order rows of the bulk prescription order corresponding to one selected patient, multiple selected patients, or all patients.

[0133] The Script Approval module 1356 presents an approval screen to the doctor computing device 1325. The approval screen includes a submission button that, when activated, enables the doctor 1320 to approve a bulk prescription order for multiple medications for multiple patients in a single action. In some embodiments, the submission button is an on-screen button activated by one of a mouse-click, screen gesture, or keyboard input.

[0134] In some implementation, the bulk prescription tool 1350 is able to generate electronic prescriptions from completed bulk prescription orders. In order to do so, the bulk prescription tool 1350 parses each approved bulk prescription order into order rows, as each order row defines a patient-medication combination. The bulk prescription tool uses each order row, along with the prescriber number associated with the doctor 1320, as authenticated during the login procedure, to generate an electronic prescription for each order row.

[0135] In other implementations, the bulk prescription tool 1350 interacts with an external eScript provider, such as eRx Script Exchange 1390, to generate electronic prescriptions.

[0136] Some embodiments of the bulk prescription ordering system described herein further include a government services module that is programmed to interact with one or more application programming interfaces (APIs) of one or more online government data sources. Such government data sources may relate, for example, to identity verification, medical benefits, government concessions, government subsidies, and prescription eligibility. Other government data sources may equally be coupled to the government services module without departing from the spirit and scope of the present disclosure.

[0137] For example, the bulk prescription tool 1350 utilises a government services module to validate the identity of a patient by sending a validation request over a communication network to a government data source of a government agency, such as Medicare or Services Australia. The government data source receives the request (which includes patient information) validates requested information, and returns a reply confirming or denying the validity of the patient identity.

[0138] In another example, the bulk prescription ordering system utilises the government services module to send an eligibility request to a government data source, such as the PBS system, to determine whether a patient is eligible for a prescription and / or whether any concessions are applicable.

[0139] In some circumstances, a predefined limit is imposed on a medication and the PBS system determines whether that predefined limit has been exceeded by the patient associated with the eligibility request. In other circumstances, a government agency may offer a concession or discount once a predefined dispensing threshold has been exceeded. For example, in some scenarios the predefined dispensing threshold is a predefined expenditure threshold. Once a patient exceeds the predefined expenditure threshold within a predefined concession period, concessions are activated, such that a discount is applied for the remained of the concession period.

[0140] In other embodiments, the bulk prescription ordering system sends a subsidy request to a government data source in relation to a dispensed prescription. The government data source receives the subsidy request, processes the subsidy request, and delivers a subsidy amount. Depending on the implementation, the subsidy amount is returned to the bulk prescription ordering system for reconciliation against a patient account or is processed by the government agency associated with the receivinggovernment data source and is then sent directly to the patient, such as in the form of a credit to a patient bank account.

[0141] In other embodiments, the bulk prescription ordering system sends a request via the Government Services Modules to PBS Online Authorities system to enquire about the status of PBS Authority approvals for medications generated by the bulk prescription ordering system that require PBS Authority Approval. The PBS Online Authorities system receives these request and sends a response to the bulk prescription ordering system informing of the approval status of each specific prescription.

[0142] In other embodiments, the bulk prescription ordering system sends requests via the Government Services Modules to start a new request for PBS Authority approval for medications generated by the bulk prescription ordering system that require PBS Authority Approval. The PBS Online Authorities system receives these requests and sends a series of responses and, if required, further information is sent by the bulk prescription ordering system informing, to complete a conformant request that is able to be submitted online via the PBS Online Authorities system for instant approval. The bulk prescription ordering system can also send requests via the Government Services Modules to PBS Online Authorities system to edit, amend, or cancel an existing request for PBS Authority Approval application.

[0143] Some embodiments of the bulk prescription ordering system described herein further include an automated dispensing module that is configured to dispense prescribed medications using an automated dispensing system. Some implementations of the automated dispensing system utilise robotics and associated robotic management software to perform one or more of the following functions: selecting medications, packaging medications, labelling packaged medications, and delivering packaged medications.

[0144] The automated dispensing module automates one or more steps of retrieving, packing, and labelling of prescribed medications. In so doing, the automated dispensing module delivers efficiencies and reduces human error.

[0145] For example, some embodiments of an automated dispensing system include an automated picking system for automated retrieval of selected medications from a storage area. Such automated picking systems retrieve selected medications and deliver the retrieved medications to a packing area.

[0146] Some embodiments of an automated dispensing system include an automated packing system, which may be used in conjunction with an automated picking system ofthe type described above. Automated packing systems pack selected medications for shipment. Automated packing systems can include, for example weighing equipment, bagging equipment, boxing equipment, and labelling equipment.

[0147] Some implementations of an automated dispensing module interact with the bulk prescription tool server 155 to obtain and / or verify patient information, such as patient name and identity. Some implementations obtain details regarding any discounts, such as might be available due to the patient being a pensioner, veteran, or other predefined discount class. In some implementations, the automated dispensing module interacts with one or more online rebate systems to claim rebates and subsidies. Such rebate systems may include, for example, but are not limited to, the PBS system, health care funds, and the like.

[0148] Fig. 15 is a schematic block diagram representation of a computer-implemented bulk prescription system 1500 that includes an optional automated dispensing module and an optional government services module. It will be appreciated that embodiments including the automated dispensing module without the government services module and embodiments including the government dispensing module without the automated dispensing module may equally be practised.

[0149] The bulk prescription system 1500 includes a bulk prescription tool server 155, such as that described above with reference to Fig. 5 and Fig. 7, for example. The bulk prescription tool 155 is implemented using a computing device, such as an online server or cloud hosting computer environment. The bulk prescription tool 155 is coupled to an ePrescribing Module 540, which may be integral with the bulk prescription tool 155 or external to the bulk prescription tool 155.

[0150] The system 1500 includes a government services module 1510, which is coupled to the bulk prescription tool 155 and optionally coupled to the ePrescribing Module 540. The government services module may be integral with the bulk prescription tool 155 or external to the bulk prescription tool 155. The government services module is programmed to interact with one or more APIs of one or more online government data sources 1515. In the example of Fig, 15, the government data sources 1515 include a Medicare system 1520, a PBSOnline system 1530, and a Services Australia system 1540.

[0151] When a prescription is processed through the bulk prescription tool 155 and / or the ePrescribing Module 540, patient information is sent, via the government services module 1510, to one or more of the government data sources 1515 to verify the patient identity, determine if any concessions or rebates are available for the patient, obtaindispensing approval for a prescribed medication for that patient, or any combination thereof.

[0152] The example of Fig. 15 also includes an automated dispensing module 1550, which is coupled to the bulk prescription tool 155 and optionally coupled to the government services module 1510. The bulk prescription tool 155 transmits eScripts to the automated dispensing module 1550 to process the eScripts and dispense the prescribed medications.

[0153] As described above, the automated dispensing module 1550 may have a range of capabilities, depending on the implementation. In particular, the automated dispensing module 1550 may perform a range of functions, including, but not limited to, picking, weighing, bagging equipment, boxing equipment, and labelling medications.

[0154] In the example of Fig. 15, the automated dispensing module 1550 is coupled to a RoboPharma Robotics module 1560. RoboPharma is an external automated dispensing provider and the Robotics module 1560 may be implemented using any internal or external automated dispensing service provider.

[0155] Depending on the implementation, the automated dispensing module 1550 performs one or more automated functions in processing eScripts, picking medications, and packing medications. Any one or more of the functions of processing eScripts, picking medications, and packing medications may be performed by an external service provider, such as the RoboPharma Robotics module 1560. In such cases, the automated dispensing module 1550 sends an eScript and dispensing instructions to the RoboPharma Robotics module 1560 via a communications interface, such as the Internet, for processing and dispensing by the RoboPharma Robotics module 1560.

[0151] Fig. 14 is a schematic block diagram of a system 1400 that includes a general purpose computer 1410 that may be configured to provide an instance of one or more of the doctor computing device 1325, the healthcare practice computer 1310, the eRx Script Exchange 1390, and the bulk prescription tool 1350. The general purpose computer 1410 includes a plurality of components, including: a processor 1412, a memory 1414, a storage medium 1416, input / output (I / O) interfaces 1420, and input / output (I / O) ports 1422. Components of the general purpose computer 1410 generally communicate using one or more buses 1448.

[0152] The memory 1414 may be implemented using Random Access Memory (RAM), Read Only Memory (ROM), or a combination thereof. The storage medium 1416 may be implemented as one or more of a hard disk drive, a solid state “flash” drive, an optical diskdrive, or other storage means. The storage medium 1416 may be utilised to store one or more computer programs, including an operating system, software applications, and data. In one mode of operation, instructions from one or more computer programs stored in the storage medium 1416 are loaded into the memory 1414 via the bus 1448. Instructions loaded into the memory 1414 are then made available via the bus 1448 or other means for execution by the processor 1412 to implement a mode of operation in accordance with the executed instructions.

[0153] One or more peripheral devices may be coupled to the general purpose computer 1410 via the I / O ports 1422. In the example of Fig. 14, the general purpose computer 1410 is coupled to each of a speaker 1424, a camera 1426, a display device 1430, an input device 1432, a printer 1434, and an external storage medium 1436. The speaker 1424 may be implemented using one or more speakers, such as in a stereo or surround sound system. In the example in which the general purpose computer 1410 is utilised to implement one or more of the functions of a bulk prescription tool 1350 or healthcare practice computer 1310, or doctor computer 1325, one or more peripheral devices may relate to scanners for use in scanning barcodes associated with patient files and / or medication.

[0154] The camera 1426 may be a webcam, or other still or video digital camera, and may download and upload information to and from the general purpose computer 1410 via the I / O ports 1422, dependent upon the particular implementation. For example, images recorded by the camera 1426 may be uploaded to the storage medium 1416 of the general purpose computer 1410. Similarly, images stored on the storage medium 1416 may be downloaded to a memory or storage medium of the camera 1426. The camera 1426 may include a lens system, a sensor unit, and a recording medium.

[0155] The display device 1430 may be a computer monitor, such as a cathode ray tube screen, plasma screen, or liquid crystal display (LCD) screen. The display 1430 may receive information from the computer 1410 in a conventional manner, wherein the information is presented on the display device 1430 for viewing by a user. The display device 1430 may optionally be implemented using a touch screen to enable a user to provide input to the general purpose computer 1410, such as through touching the screen, making gestures, and the like. The touch screen may be, for example, a capacitive touch screen, a resistive touchscreen, a surface acoustic wave touchscreen, or the like.

[0156] The input device 1432 may be a keyboard, a mouse, a stylus, drawing tablet, or any combination thereof, for receiving input from a user. The external storagemedium 1436 may include an external hard disk drive (HDD), an optical drive, a floppy disk drive, a flash drive, solid state drive (SSD), or any combination thereof and may be implemented as a single instance or multiple instances of any one or more of those devices. For example, the external storage medium 1436 may be implemented as an array of hard disk drives.

[0157] The I / O interfaces 1420 facilitate the exchange of information between the general purpose computing device 1410 and other computing devices. The I / O interfaces may be implemented using an internal or external modem, an Ethernet connection, or the like, to enable coupling to a transmission medium. In the example of Fig. 14, the I / O interfaces 1422 are coupled to a communications network 1438 and directly to a computing device 1442. The computing device 1442 is shown as a personal computer, but may equally be practised using a smartphone, laptop, or a tablet device. Direct communication between the general purpose computer 1410 and the computing device 1442 may be implemented using a wireless or wired transmission link.

[0158] The communications network 1438 may be implemented using one or more wired or wireless transmission links and may include, for example, a dedicated communications link, a local area network (LAN), a wide area network (WAN), the Internet, a telecommunications network, or any combination thereof. A telecommunications network may include, but is not limited to, a telephony network, such as a Public Switch Telephony Network (PSTN), a mobile telephone cellular network, a short message service (SMS) network, or any combination thereof. The general purpose computer 1410 is able to communicate via the communications network 1438 to other computing devices connected to the communications network 1438, such as the mobile telephone handset 1444, the touchscreen smartphone 1446, the personal computer 1440, and the computing device 1442.

[0159] One or more instances of the general purpose computer 1410 may be utilised to implement one or more functions of the bulk prescription system tool 1350 of Fig. 13. In such embodiments, the memory 1414 and storage 1416 are utilised to store data relating to standing orders, patient data, prescriber profiles, medication data, dispensing locations, and the like. Software for implementing the bulk prescription tool is stored in one or both of the memory 1414 and storage 1416 for execution on the processor 1412. The software includes computer program code for implementing method steps in accordance with the functional modules described herein. Programming the computer 1410 to perform the functionality of the bulk prescription tool described herein results in a new and improveduse of the computer 1410. The computer 1410 programmed in such a way is integral to the implementation of a bulk prescription tool.

[0160] Figs 16A and 16B compare and contrast the differences between a paper-based prescription generation process and an electronic, computer-implemented prescription generation system in accordance with one or more embodiments of the present disclosure.

[0161] Fig. 16A is a flow diagram representation of a paper based prescription generation and approval process. In a first step 1605, a user manually completes details in an order form. In a next step 1610, the user prints and signs a paper prescription generated from the manually completed form in step 1605. In a following step 1615, the user prints a form for an optical coherence tomography (OCT) scan, for cases in which the prescription relates to such a scan. In a further step 1620, a user needs to scan the paper prescription and / or printed OCT scan and upload the scanned document(s). The scanner documents are then sent away for approval 1625. As can be seen, this is a laborious and time-consuming practice.

[0162] Fig. 16B is a flow diagram representation of a computer-implemented paperless prescription generation and approval process in accordance with the present disclosure. In step 1630, a user logs in to an online verification and authentication system, such as PRODA (Provider Digital Access). In step 1635, the verified user generates eScripts using a computer-implemented bulk prescription tool, such as described herein. In step 1640, the system grants instant approval, as the user has already been verified in step 1630. It is evident that the computer-implemented, paperless system embodying a bulk prescription tool in accordance with the present disclosure provides an improved system for generating and approving prescriptions.Industrial Applicability

[0156] The arrangements described are applicable to the computing, medical, pharmaceutical, and information technology industries.

[0157] 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 foregoing describes only some embodiments of the present invention, and modifications and / or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

[0158] In the context of this specification, the word “comprising” and its associated grammatical constructions mean “including principally but not necessarily solely” or“having” or “including”, and not “consisting only of”. Variations of the word "comprising", such as “comprise” and “comprises” have correspondingly varied meanings.

[0159] As used throughout this specification, unless otherwise specified, the use of ordinal adjectives "first", "second", "third", “fourth”, etc., to describe common or related objects, indicates that reference is being made to different instances of those common or related objects, and is not intended to imply that the objects so described must be provided or positioned in a given order or sequence, either temporally, spatially, in ranking, or in any other manner.

[0160] Reference throughout this specification to “one embodiment,” “an embodiment,” “some embodiments,” or “embodiments” 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. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

[0161] 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 skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0162] Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention.

[0163] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practised 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.

[0164] Note that when a method is described that includes several elements, e.g., several steps, no ordering of such elements, e.g., of such steps is implied, unless specifically stated.

[0165] The term “coupled” should not be interpreted as being limitative to direct connections only. The terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other, but may be. Thus, the scope of the expression “a device A coupled to a device B” should not be limited to devices or systems wherein an input or output of device A is directly connected to an output or input of device B. It means that there exists a path between device A and device B which may be a path including other devices or means in between. Furthermore, “coupled to” does not imply direction. Hence, the expression “a device A is coupled to a device B” may be synonymous with the expression “a device B is coupled to a device A”. “Coupled” may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other.

Claims

We claim:1 . A computer-implemented bulk prescription tool comprising:(i) a script generation tool for creating a bulk prescription order that includes a plurality of order rows, each order row including a patient data field and a medication data field, wherein said script generation tool populates said order rows by at least one of:(a) manual data entry;(b) importation of a digital list from an external source, said digital list including at least patient data; and(c) a user selecting a standing order from a set of stored standing orders, wherein each standing order defines a set of medications associated with at least one of a healthcare professional, a healthcare facility, and a medical procedure, wherein selecting a standing order populates a nominated set of order rows with the set of medications defined by the selected standing order; and(ii) a bulk approval tool having a practitioner interface that includes: a display region for displaying, to an authorised user, the bulk prescription order; and a submission button for receiving input from said authorised user to approve all order rows within the bulk prescription order in a single action; wherein said bulk prescription tool transmits said approved bulk prescription order to an ePrescribing tool to generate an eScript for each order row of the approved bulk prescription order.

2. The bulk prescription tool according to claim 1 , wherein said digital list includes patient data pulled from at least one of a practice management system and a dispensing system.

3. The bulk prescription tool of either one of claim 1 or claim 2, further comprising: an ePrescribing tool for receiving said approved bulk prescription order to generate an eScript.

4. A system comprising:(i) a patient link tool configured to interface with practice management software at a healthcare facility to: extract patient data from said practice management software; and populate a digital list with said patient data;(ii) a script generation tool for creating a bulk prescription order that includes a plurality of order rows, each order row including a patient data field and a medication datafield, wherein said script generation tool populates said order rows by importing said digital list from said patient link tool; and(iii) a bulk approval tool having a practitioner interface that includes: a display region for displaying, to an authorised user, the bulk prescription order; and a submission button for receiving input from said authorised user to approve all order rows within the bulk prescription order in a single action;(iv) an ePrescribing tool for generating an eScript for each order row of the approved bulk prescription order.

5. The system according to claim 4, wherein said patient link tool further includes: a presentation interface configured to enable a user to: perform manual data entry relating to said digital list; and select a standing order from a set of stored standing orders, wherein each standing order defines a set of medications associated with at least one of a healthcare professional, a healthcare facility, and a medical procedure, wherein selecting a standing order populates a nominated set of order rows on the digital list with the set of medications defined by the selected standing order; and6. The system according to either one of claim 4 or claim 5, further comprising: a dispense import tool configured to interface with a pharmacy dispensing system so as to extract medication records; wherein said script generation populates said order rows by importing said extracted medication records from said dispense import tool.

7. The system according to any one of claims 4 to 6, wherein said script generation tool further populates said digital list by at least one of:(a) manual data entry; and(b) a user selecting a standing order from a set of stored standing orders, wherein each standing order defines a set of medications associated with at least one of a healthcare professional, a healthcare facility, and a medical procedure, wherein selecting a standing order populates a nominated set of order rows of said digital list with the set of medications defined by the selected standing order.

8. The system according to any one of claims 4 to 7, wherein said patient link tool further populates said order rows by at least one of:(a) manual data entry; and(b) a user selecting a standing order from a set of stored standing orders, wherein each standing order defines a set of medications associated with at least one of a healthcare professional, a healthcare facility, and a medical procedure, wherein selecting a standing order populates a nominated set of order rows with the set of medications defined by the selected standing order; and9. A computer-implemented bulk prescription tool comprising: a presentation interface for receiving input relating to a bulk prescription order, wherein the bulk prescription order includes multiple order rows, each order containing a patient data field and a medication data field; a processor; a second computer-readable storage medium for storing computer code instructions that when executed on the processor perform the method steps of: based on said received input, creating a bulk prescription order; populating patient data fields and medication data fields for a plurality of rows; and approving all order rows in said bulk prescription order.

10. The bulk prescription tool of claim 9, further comprising: a first computer-readable storage medium for storing a set of standing orders, wherein each standing order defines a set of medications associated with at least one of a healthcare professional, a healthcare facility, and a medical procedure; wherein the presentation interface provides the user with the option of selecting one of said standing orders; and further wherein the computer code instructions when executed on the processor perform the method step of: populating medication data fields of one or more selected order rows, based on medications defined by a selected standing order.11 . The bulk prescription tool of claim 10, wherein each standing order relates to a specified healthcare professional and a specified medical procedure.

12. The bulk prescription tool of any one of claims 9 to 11 , wherein approving all order rows is based on said user input including activation of a submission button.

13. The bulk prescription tool of claim 12, wherein said submission button is an on-screen button activated by one of a mouse-click, screen gesture, or keyboard input.

14. The bulk prescription tool according to any one of claims 9 to 13, further comprising: a script approval module for displaying an approval screen, said approval screen including a display region for said submission button.

15. The bulk prescription tool according to claim 14, wherein said script approval module provides filter options to enable a user to filter bulk orders based on one or more viewing parameters.

16. The bulk prescription tool according to claim 15, wherein said viewing parameters are selected from the group consisting of: selected date, date range, medication, location, procedure, and patient name.

17. The bulk prescription tool of any one of claims 9 to 16, further comprising: a script generation module for receiving patient data from an external source and populating a bulk prescription order with said received patient data.

18. The bulk prescription tool according to any one of claims 9 to 17, further comprising: an ePrescribing module for generating electronic scripts from an approved bulk prescription order.

19. The bulk prescription tool according to claim 18, wherein the ePrescribing module parses the approved bulk prescription order to generate said electronic scripts.

20. The bulk prescription tool according to claim 18, wherein the ePrescribing module interfaces with an external electronic prescription provider to generate said electronic scripts.

Images