AU2017100309A4 - Method and system - Google Patents

Abstract

H:\dxl\Intrwovn\NRPortbl\DCC\DXL\l3510996_ .docx-17/03/2017 A method performed by one or more computer processors, the method including: generating data representing a unique code for a script of a patient; generating data for to printing the unique code to a unique label for application to a duplicate script associated with the script; receiving a digital image of the duplicate script including the unique label; processing data representing the digital image to match the digital image to the unique code; and storing the digital image data in association with data representing the unique code in at least one database. D >> ((Ni ':4 CD > --- '4 \N ( A"> \Ell ------------------------- -- --------------------------------------------------------------------------------------- zozN >~

Description

H:\dxltfnterwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 - 1 -

METHOD AND SYSTEM

TECHNICAL FIELD

[001] The present invention generally relates to methods and systems for processing scripts (i.e., doctor's prescriptions) and associated repeat authorisations (i.e., “repeats”) in pharmacies.

BACKGROUND

[002] In pharmacies (or ‘chemists’), registered pharmacists are permitted to dispense pharmaceutical products (‘drugs’) to patients when the patients present prescriptions (or ‘scripts’) from medical doctors. The procedure to dispense these products is somewhat inefficient and slow, with multiple paper-handling steps; however, as strict requirements are imposed by legislation on many of the steps in the process, there is a lack of tools to make the process more efficient and/or reliable.

[003] It is desired to address or ameliorate one or more disadvantages or limitations associated with the prior art, or to at least provide a useful alternative.

SUMMARY

[004] Described herein is a method performed by one or more computer processors, the method including: generating data representing a unique code for a script of a patient; generating data to print the unique code to a unique label for application to a duplicate script associated with the script; receiving a digital image of the duplicate script including the unique label; processing data representing the digital image to match the digital image to the H:\dxl\Interwoven\NRPortbl\DCC\DXL\l 3510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -2- unique code; and storing the digital image data in association with data representing the unique code.

[005] The unique code can be a virtual script draw (VSD) code, e.g., based on a pharmacy identifier and/or a dispense transaction identifier, e.g., a count of transactions. The script represents a medical prescription. The unique label can be a sticker. Generating the data to print the unique code to the unique label included rendering the unique label. The data representing the digital image can be referred to as “digital image data”, and is the digital image data of the duplicate script.

[006] The method can include any one or more of: receiving data (“patient details data”) representing patient details to identify the patient, and storing the patient details data in association with the unique code in the database; receiving data representing repeat information (“repeat details”) associated with the script (including the patient details, doctor details, pharmacy details, and product details); accessing data representing a repeat template document (approved by legislation); generating at least one data file (“repeat file”) representing a repeat script for the patient (i.e., the “virtual repeat”), incorporating the repeat template document and the repeat information; and storing the repeat data file in association with the unique code data in the database.

[007] The method can include: receiving data representing a search, including requested patient details; selecting the repeat file by matching the requested patient details with stored patient details associated with the repeat file; generating data representing a request for user input from a pharmacist to view the repeat file; H:\dxl\Interwoven\NRPortbl\DCQDXL\13510996_l .docx-17/03/2017 2017100309 17 Mar 2017 -3- on receiving the user input, accessing and displaying simultaneously (on an electronic display): the repeat file, and the digital image of the duplicate script that is associated with the repeat script in the database; generating data representing tally information based on the repeat information associated with the repeat script; generating a further data file (“further repeat file”) representing the repeat script with the tally information applied; displaying (on an electronic display) the repeat script with the tally information applied; receiving patient input data representing a signature on the repeat script with the tally information applied; and generating and storing data representing a signed further repeat file that includes the repeat script with the tally information applied and the signature applied in association with the unique code data in the database.

[008] Described herein is a method performed by one or more computer processors, the method including: generating data representing a virtual repeat authorisation (VRA) for an original medical prescription (OMP) based on: (i) a repeat authorisation layout; (ii) a selected legal prescription identifier (LPI) provided by a medical authority; and (iii) repeat details associated with the OMP; rendering the VRA as a image for storage, wherein the rendering includes rendering the pharmaceutical details and the LPI onto the repeat authorisation layout.

[009] The selected LPI can be from a stored set of LPIs supplied to a pharmacy.

[010] The repeat details can be represented by data received (i.e., a downloaded “payload”) from a prescription data system, e.g., “eRx”, using a scannable code, e.g., a barcode or a QR code on the original medical prescription.

[011] The method can include: generating data representing a virtual claim sticker (VCS) based on legal details of supply (i.e., tally information, which includes: date of supply, the number of the H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -4- supply, the drug, the quantity, and the cost, and the pharmacist initials); and rendering (and storing) as an image the VRA with the VCS (e.g., on top, e.g., for later signing by a patient).

[012] The method can include: receiving data representing a signature from a patient; and storing as an image the signature on the virtual repeat authorisation with the VCS.

[013] The method can include: recording a selection time when selection data are received representing a patient selecting a stored VRA; and recording a signature time when signature data are received representing the patient signing the image of the VRA with the VCS.

[014] The method can include: storing a virtual duplicate of the OMP as an image; retrieving the duplicate and the VRA as images; and displaying an image of the VRA next to an image of the virtual duplicate.

[015] Described herein is a system including one or more computer processors, and one or more modules configured to perform the methods.

[016] Described herein are storage media including machine-readable instructions to control one or more processors to perform the methods.

BRIEF DESCRIPTION OF THE DRAWINGS

[017] Some embodiments of the present invention are hereinafter further described, by way of example only, with reference to the accompanying drawing, in which: [018] Fig. 1 is a flow diagram of a method for processing scripts (i.e., doctor's prescriptions) in pharmacies; H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -5- [019] Fig. 2 is an architecture diagram of a system for processing the scripts in pharmacies; [020] Fig. 3 is a flow chart of a configuration process performed by the system; [021] Fig. 4 is a flow chart of an original dispense process performed by the system; [022] Fig. 5 is a flow chart of a queuing virtual repeat process performed by the system; [023] Figs. 6A and 6B are a flow chart of a dispense virtual repeat process performed by the system; and [024] Fig. 7 is a flow chart of a virtual script signing process performed by the system.

DETAILED DESCRIPTION

[025] Described herein are a method and a system for processing scripts (i.e., doctor's prescriptions) in pharmacies so as to mitigate and/or remove at least some of the inefficiencies and/or reliability issues associated with storage and usage of repeat scripts in pharmacies. As pharmacies store paper repeat scripts in script drawers—where they can be accessed for dispensing a repeat—the method and system described herein may be referred to as providing a “virtual script drawer” (VSD), or “electronic script drawer”, or “digital script drawer”. Thus the system can be referred to as a VSD system, or simply a VSD, and the method can be referred to as a VSD method. The VSD (virtual script drawer) is a tool with data processing and storage technology that can allow a pharmacy to store documents required for dispensing repeat scripts digitally (which can be more efficient and/or reliable than paper storage), allow the pharmacy to rapidly access and dispense the repeat scripts when required, and allow the pharmacy to comply with legislative requirements in an efficient and reliable manner. The VSD can improve the accuracy and speed of the H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -6- dispensing process from the initial patient visit, subsequent return visits and fulfilment of their prescriptions.

[026] As described in more detail hereinafter, the VSD method includes encoding a printed paper script for digital recognition and digital storage in a digital filing system, and encoding, matching and retrieval (lookup) of the corresponding digital script, for incorporation into existing pharmacy dispensing workflows.

[027] As shown in Figure 1, a virtual script drawer dispensing process 100 includes a plurality of steps. Some of the steps are performed by people (the patient, the pharmacist (or equivalently an authorised technician), or a staff member—who can be the pharmacist or another unqualified person working for the pharmacy), and some of the steps are performed by the VSD system. The steps performed by the system are in the VSD method.

[028] As shown in Figure 1, the process 100 includes 3 phases: a first phase 102, in which an original script or a hardcopy paper repeat authorisation (or “repeat”) is first received, and a product is first dispensed (steps 1 to 5); a second phase 104, in which the digital scripts are stored and accessed (steps 6 and 11); and a third phase 106, in which repeats are dispensed, i.e., subsequent dispenses of the product (steps 7 to 10).

[029] As shown in Figure 1, the process 100 commences with the patient presenting a paper script to the pharmacist for the first time (step 1). The paper script may be the original prescription, or an outside repeat that has not previously been seen by this pharmacy (i.e., a Repeat Authorisation from a different pharmacy attached to the original prescription). The paper script, which can be the original script or a repeat script, is accompanied by a paper duplicate script, i.e., a duplicate of the original prescription, e.g., attached by a staple.

[030] When the patient presents in step 1, the system receives data (“patient details data”) representing the patient’s details to identify the patient, e.g., from a dispense management system (e.g., a commercially available system separate from, and in electronic communication with, the VSD system), and stores the patient details data in association with the unique code in a database of the VSD system. When the patient H:\dxl\fnterwoven\NRPortbl\DCC\DXL\l 3510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -7- presents, the patient is identified, and patient details data are selected by a staff member using a portable computer (which can be a laptop or tablet computer, also referred to as a “mobile device”), in communication with (e.g., via WiFi) the VSD system, in the pharmacy. The patient can be selected from a list of customers already stored in the database of the system (e.g., patients who leave scripts on file). The system also receives data representing repeat information (“repeat details”) associated with the original medical prescription (including the patient details, doctor details, pharmacy details, and product details), e.g., from the dispense management system. Alternatively, the repeat details may be entered manually into a UI form by the pharmacist or technician from script information on the paper script. The repeat details include the following: (i) patient details; (ii) doctor details; (iii) drug details; (iv) dosage details; (v) the total number of repeats authorised; and (vi) a repeat number of the next dispensing, e.g., “5/1” indicates 1 original and 5 repeats authorised, and when dispensed that repeat will be the first repeat. If repeats are not authorised on an original script, the number of repeats is 0, and the method ends at this step.

[031] After presenting the paper script in step 1, the pharmacist dispenses a product defined by the paper script (step 2).

[032] In prior art paper processes, the paper duplicate script could then be stored in a physical drawer in the pharmacy, in case the patient returns for a repeat of the script; however, to provide the virtual script drawer, after or during the dispensing in step 2, the system receives an initiation signal (e.g., from the pharmacy management system, e.g., including commercially available dispense management software, or manually initiated by the pharmacists), and in response to the initiation signal, the system generates data representing a unique code (referred to herein as the VSD code), based on a pharmacy identifier and a dispense transaction identifier (e.g., a count of transactions) for the dispensed script in step 2; the system then generates data for printing the VSD code to a unique hardcopy label (or sticker), referred to herein as the VSD label, for application to the paper duplicate script associated with the script (step 3). A section of the VSD label with the VSD code is referred to as a “coded section” or “encoded section”. Thus prescription labels are encoded with the machine-readable VSD code for relating the H:\dxl\Interwoven\NRPortbl\DCC\DXLM3510996_l .docx-17/03/2017 2017100309 17 Mar 2017 -8- duplicate paper prescription and an electronically dispensed prescription: the unique code provides a form of bridge to match the paper script to the electronic representation. To generate the VSD label in step 3, the system may include a “DevExpress” reporting engine, with a “Code 128 Auto” label to support alpha-numeric characters. The VSD code includes the following components from the repeat details and received by the system as a result of the dispensing step (e.g., from the dispense management system): (i) the repeat number; (ii) a script identifier (ID), e.g., a transaction number (e.g., a serial number generated or received by the system to distinguish successive scripts); and (iii) a pharmacy ID, e.g., an approval number, which can be a location ID.

[033] The VSD label may be generated by executing machine-readable instructions based on the following C# code, showing the components of the unique code: xrBarCodePaperless.Text = string.Format("{0}{ 1 };{2}", _script.RepeatNumber == 0 ? "1" : "2", _script.ScriptId.ToString("X"), DispenseApplication.Pharmacy.ApprovalNumber).

[034] The “Repeats” section of the encoded VSD code is a flag to denote "1" for original dispensing and "2" for a repeat.

[035] The VSD label may be incorporated in data already prepared for printing labels in the pharmacy system, e.g., for other labels, not including the VSD code, that are printed for other purposes in the pharmacy.

[036] After the dispensing in step 2, the patient signs the paper original script to fulfil legislative and auditing requirements (step 4).

[037] After the dispensing in step 2, the system determines whether a further repeat is available, based on a duration (which may have expired) and a number of available repeats (which may have been completed) in the received details.

[038] If a further repeat is available, the system generates a virtual repeat (i.e., a virtual repeat authorisation (VRA), “electronic repeat” or “digital repeat”) that can be stored electronically rather than on paper (step 5). To generate the virtual repeat, the H:\dxl\Interwoven\NRPortbl\DCC\DXL\l3510996_l .docx-17/03/2017 2017100309 17 Mar 2017 -9- system accesses data representing a repeat authorisation layout in a repeat template document (based on a paper template approved by legislation); generates at least one data file (“repeat file”) representing a repeat script for the patient, incorporating the repeat authorisation layout and the repeat details; and stores the repeat data file in association with the unique code data in the database (step 11). The repeat template document may be stored as a document image file in the image filing system.

[039] The virtual repeat can be generated for storage as an image representation that includes predefined repeat fields, i.e., standard areas for information defined by legislation and/or existing pharmacy practice.

[040] The virtual repeat can be generated using a Tenderer (which can include a standard Tenderer and a Tenderer interface, e.g., based on the code in Code Appendix C hereinafter) with a file format provided by a template file, e.g., Repeat.XML in Code Appendix A hereinafter.

[041] After the VSD label is printed, a staff member physically attaches the VSD label to the paper duplicate, and scans / photographs (i.e., digitally captures an image) the paper duplicate with the unique label attached (step 6). Once the digital image has been captured in step 6, the system receives the digital image of the duplicate script including the VSD label. The digital capture can occur on a daily basis for all processed duplicates.

[042] The system processes data (“digital image data”) representing the digital image to match the digital image to the VSD code.

[043] The system can parse the uploaded image to identify the VSD label therein (e.g., using the “ZXing”, or Zebra Crossing, library to parse the VSD label, which can be in the form of a scannable code) from the uploaded image. The scannable code can be an optically scannable code, e.g., a barcode or QR code, can be parsed to extract the approval number (the location ID) to validate the location, and to extract the script ID to match to the dispensed script in the database. Thus the matching can include matching one or more of the components of the VSD code to data in the script details stored in the system. H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 - 10- [044] The system stores the digital image data in association with metadata representing the VSD code in at least one database (step 11).

[045] The system can match the digital image data (i.e., the virtual duplicate) with the virtual repeat using its association to the VSD code.

[046] As shown in Figure 1, the system can be used in a scenario in which a repeat on file is requested, i.e., when the patient requests a repeat prescription from the repeats on file (step 7).

[047] On receiving an appropriate user input, e.g., from a staff member using the portable computer, the system provides a patient user interface (UI), e.g., an HTML5 Web application for displaying data directly from the database.

[048] The system receives data from the UI representing a search, including requested patient details, e.g., patient name. The system selects at least one repeat file by matching the requested patient details with stored patient details associated with the repeat file. The system generates data for the UI to display available virtual repeats, and receives user input from the patient representing a selection of which virtual repeats to fulfil. The system generates data for a pharmacist UI (which is different from the patient UI, e.g., on a computer in a product area) representing a dispense request in a queue, i.e., a queued request (step 8).

[049] When the pharmacist is ready to dispense the queued request, the pharmacist enters a selection of the dispense request, the system accepts the selection, the system accesses and displays simultaneously (on an electronic display for the pharmacists): the repeat file (i.e., the virtual repeat), and the digital image of the duplicate script that is associated with the repeat script via the VSD code in the database (step 9). Thus the related duplicate and latest dispensed repeat is visible, while dispensing, for visual confirmation by the pharmacist.

[050] After the system detects that the repeat dispense is complete in step 9 (e.g., based on a signal received from the dispense management system: the pharmacist can complete the relevant transaction using various interfaces, including by clicking a H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_l .docx-17/03/2017 2017100309 17 Mar 2017 - 11 - "Dispense" button, hitting “enter” on a keyboard, etc., once all required information is filled and validated), the system generates and stores a further virtual repeat, unless the system determines that the duration or number of repeats has been reached, thus returning to step 5.

[051] After the dispensing in step 9, the system generates data representing tally information (also known as “coding information”) based on the repeat information associated with the repeat script. The tally information includes: a tally number (e.g., “023”), a drug name, the script number, the pharmacist ID, and other information relevant for benefit claiming. The system renders the tally information on a virtual claim sticker (VCS) based on a VCS layout, and generates a further data file (a “further repeat file” or further virtual repeat) representing the repeat script with the tally information applied in the form of the VCS.

[052] The system generates data to display the virtual repeat with the VCS on the patient UI, so the patient can sign the further virtual repeat, e.g., using a touch pad or touch screen with the patient UI. The system receives patient input data representing a signature on the repeat script with the tally information applied, and generates and stores data representing a signed further repeat file that includes the repeat script with the tally information applied and the signature applied in association with the VSD code data in the database (step 10). The signature is stored electronically against the repeat, e.g., in the same image file, or in an associated image file. The system may include an HTML5 canvas for capturing the signature and storing this image as a layer on the dispensed repeat.

[053] The tally information (which is applied as the VCS or “label”) can be generated using a Tenderer (which can include the standard Tenderer and the Tenderer interface, e.g., based on the code in Code Appendix C hereinafter) with a file format provided by a template file, e.g., Codingsticker.XML in Code Appendix B hereinafter.

[054] The image files, including the uploaded duplicates, the repeat template document, the virtual repeats, and the signatures, are stored as digital electronic files in an electronic filing system (or store). The image files are indexed or accessed by file storage H:\dxltfnterwoven\NRPortbl\DCC\DXL\l3510996_l .docx-17/03/2017 2017100309 17 Mar 2017 - 12- references in the database. The file storage and database systems can be commercially available systems. The image files can be stored as JPEG fdes.

[055] Storage media, e.g., hard discs or digital media discs, include machine-readable instructions to control one or more processors to perform the method, e.g., a compiled and compressed version for installation, or installed for operation.

[056] The system includes one or more computer processors (e.g., general-purpose microprocessors), and one or more software modules configured to perform the method.

[057] The data generation, data storage and data communications operations relate to digital data operations. The digital data may include electronic data defined by logic circuits—which may include binary logic circuits—represented by electronic quantities, which may include voltage, current and/or resistance. The boundaries between the modules and components in the modules of the system may be merged, or decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Some or all of the system may be embodied in the structure of circuitry firmware programmed into programmable or erasable/programmable devices, the configuration of a field- programmable gate array (FPGA), the design of a gate array or full-custom application-specific integrated circuit (ASIC).

[058] “Unique” means quasi unique, i.e., for unique identification within the database.

[059] As shown in Figure 2, an implementation of the VSD system 200 includes: instore components 202 and cloud components 204.

[060] The instore components 202 include a dispense system 206, and an image uploader 208.

[061] The dispense system 206 includes the dispense management system of the pharmacy, which includes the electronic display for the pharmacists, and the label printer connected thereto. H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 - 13 - [062] The image uploader 208 is an application (e.g., a local Windows “forms’ application that runs on an instore PC) that photo-scans documents (e.g., the original hardcopy duplicates) to generate and upload corresponding document images to an archive service 220. The image uploader 208 is typically used at the end of each business day to scan in documents generated from prescriptions filled that day for audit purposes, including original duplicates.

[063] The cloud components 204 include: the archive service 220, a VSD app 210, a queue web app 212, a virtual repeat generator (VRG) 214, a VSD service 216, a queue service 218, VSD storage 222, and archive storage 224.

[064] The archive service 220 (or “archive application service”) is a cloud service (e.g., written in C#) that stores and processes the uploaded document images. The archive service 220 stores, indexes and provides access to the image data and the metadata in the archive storage 224, including: an index of the archived images (to enable retrieval); images of the signed virtual repeats for audit and history purposes; and images of the uploaded original duplicates.

[065] The VSD app 210, which includes the patient UI, is a user-facing application (e.g., a world-wide-web-based application or in-browser application, e.g., written in Angular) for an instore operator to view information that identifies patients (e.g., name etc.) and their next virtual repeat (as recorded in the VSD). The VSD app 210 allows the instore operator to queue one or more stored virtual repeats for the identified patient by selecting the respective repeats. The selected available stored virtual repeats are added to the queue web app 212 (where they are shown for dispensing. The VSD app 210 displays an image of the dispensed virtual repeat for signing, receives a signature from the patient, and provides the signature for addition to the dispensed virtual repeat. The VSD app 210 accesses stored patient names for searching, accesses and displays the queue (of queued virtual repeats). The VSD app 210 receives selections to add a virtual repeat to the queue. The VSD app 210 receives selections to configure the VSD. The VSD app 210 receives input of at least one legal prescription identifier (LPI), typically a range of available LPIs, e.g., based on a range of LPIs on hardcopy repeat authorisations received by the pharmacy. H:\dxl\Interwoven\NRPortbl\DCC\DXL\l3510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 - 14- [066] The queue app 212, which includes the pharmacist UI, is a user-facing application (e.g., a world-wide-web-based application or in-browser application, e.g., written in Angular) that: a. accesses and displays (by schedule time, filters for source and patient) the queue of queued virtual repeats for the Instore Operator to view and dispense; and b. receives input from the instore operator indicating that one or more selected ones of the queued virtual repeats are going to be dispensed, and in response injects the respective script references into the dispense system 206).

[067] The VRG 214 is a cloud service (e.g., written in C#) for the dispense system 206 to retrieve the next virtual repeat image and generate the next virtual repeat after dispensing.

[068] The VSD service 216 is a cloud service (e.g., written in C#) to display the VSD repeats, orchestrate queueing virtual repeats to be dispensed (including adding virtual repeats to the queue), and store the signed virtual repeat after dispensing.

[069] The queue service 218 is cloud service (e.g., written in C#) to display the queued virtual repeats for the queue app 212. The queue service 218 displays and searches the queue of virtual repeats. The queue service 218 executes actions on the virtual repeats in the queue, including cancelling a selected virtual repeat, or dispensing a selected virtual repeat.

[070] The queue service 218 reads (i.e., determines) and writes (i.e., selects) the state of each virtual repeat. The state of each virtual repeat is one of: a. “script drawer”, which is selected when the virtual repeat has been generated and stored, and is available for selection into the queue; b. “script queue”, which is selected when the virtual repeat has been selected for the queue; H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_l .docx-17/03/2017 2017100309 17 Mar 2017 - 15 - c. “script sign”, which is selected when the virtual repeat has been marked as dispensed with the tally information, e.g., in the form of a virtual claim sticker (VCS), for signing; and d. “script history”, which is selected when the virtual script with the VCS has been signed.

[071] The VSD storage 222 is a cloud storage system (e.g., in Microsoft’s Azure) that stores: a. image data representing the rendered images of (i) the generated virtual repeats, (ii) the virtual repeats with the VCSes, and (iii) the signed virtual repeats; b. metadata for each of the rendered images in the image data; and c. the queue of scripts (including the queued virtual repeats), and related identifiers: a pharmacy store ID, a local script ID, a global script ID, and the LPI.

[072] The archive storage 224 is a cloud storage system (e.g., in Microsoft’s Azure) that stores image data and corresponding data for scanned documents from the image uploader 208, including the scanned original duplicates, and the signed virtual repeats (for auditing purposes).

[073] As shown in Figure 2, the image uploader 208 communicates with the archive service 220 to send the scanned document images. The archive service 220 communicates with the archive storage 224 to store and access the scanned images. The dispense system 206 communicates with the VRG 214 to initiate generation of the virtual repeat, with the archive service 220 to access the scanned original duplicate, and with the queue app 212 to read and write to the queue. The VSD app 210 communicates with the VSD service 216 to select one or more available virtual repeats (in the “script drawer” state) for queuing, to add selected virtual repeats to the queue (i.e., advancing these virtual repeats to the “script queue” state), to configure the VSD system 100, to access and display a virtual repeat with H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_l .docx-17/03/2017 2017100309 17 Mar 2017 - 16- a VCS (i.e., in the “script sign” state) for signing, and to receive a signature to generate a signed virtual repeat and to move it to the “script history” state. The VSD service 216 can advance the state by writing directly to the VSD storage 222. The queue app 212 communicates with the queue service 218 to read (i.e., to determine) and write (i.e., to advance) the states of the virtual repeats (in the VSD storage 222), and with the dispense system 206. The VRG 214, VSD service 216 and queue service 218 communicate with the VSD storage 222 to store and to access the image data and the metadata of the virtual repeats. The archive service 220 communicates with the archive storage 224 to store and to access the image data and metadata of scanned duplicates (and other scanned documents). The VSD service 216 communicates with the archive service 220 to send the signed virtual repeats for archiving in the archive storage 224.

[074] The metadata in the VSD storage 222 are stored according to a schema, e.g., written using C#, and represent information for generating each virtual repeat and corresponding VCS, including: a. the script ID obtained using a unique scannable code (e.g., an “eRx SCID” barcode) than is scanned by the dispense system 206 to access a unique data payload for this prescription from a remote server / cloud service (e.g., the “eRx” service)- e.g., defined in the schema as “public string ErxScid { get; set; }”; b. an original script number of the original script-the original number is generated by the dispense system 206 when the dispense system 206 receives the unique data payload by scanning the unique scannable code-e.g., public long Originals crip tNumber { get; set; }; c. a script number of this script-the script number is generated by the dispense system 206 when the dispense system 206 dispenses a virtual repeat or a hardcopy repeat-public long ScriptNumber { get; set; }; d. a unique basket identifier (ID) and corresponding friendly name that is used to link two or more virtual repeats in a group (or “basket”), e.g., virtual H:\dxl\Interwoven\NRPortbl\DCC\DXL\l 3510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 - 17- repeats for different members of a family-e.g., public Guid Basketldentifier { get; set;, and public string BasketFriendlyName { get; set; }; e. recorded times (i.e., dates and times) of events in the method executed by the VSD system 100, including: i. when the virtual repeat was created (i.e., the last dispensed date), ii. when the virtual stript was selected into the queue, and iii. when the queued virtual repeat was selected for dispensing; f. identification of the individual(s) who: i. queued the virtual repeat for dispensing, as determined by the VSD app 210; ii. started the dispensing, as determined by the dispense system 206, iii. completed dispensing the script, as determined by the dispense system 206, and iv. witnessed the script being signed, as determined by the VSD app 210; g. details of the prescriber, including name, date/time, and comments; h. patient details, including name, address, date-of-birth, family ID (for members of a family); and i. drug details.

[075] As shown in Figures 3 to 7, the VSD method includes a plurality of subprocesses performed by one or more computer processors, including: a configuration process 300, an original dispense process 400, a queuing virtual repeat process 500, a dispense virtual repeat process 600, and a virtual script signing process 700. H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -18- [076] As shown in Figure 3, in the configuration process 300, the VSD app 210 receives the at least one legal prescription identifier (LPI), which is typically a range of available LPIs associated with a range of LPIs on respective hardcopy repeat authorisations received by the pharmacy, as mentioned hereinbefore (step 302). The LPIs, which may be referred to as “prescription IDs”, can be entered manually by the instore user operating the VSD app 210. As shown in Figure 3, the VSD service 216 receives the entered LPIs from the VSD app 210 (step 304), and sends the LPIs to the VSD storage 222 for storage (step 306).

[077] As shown in Figure 4, in the original dispense process 400, the dispense system 206 receives input from an instore user indicating that an original script is being dispensed (step 402). In step 402, the instore user selects the VSD method, and the VRG 214 constructs the virtual repeat as described hereinbefore (step 404), including by retrieving the next local script ID based on the stored script ID described hereinbefore (step 406) from the VSD storage 222, and the VRG 214 renders and stores the newly constructed virtual repeat ready for the next patient visit and associated expected dispense (step 408), and stores the metadata corresponding to the virtual repeat in the virtual script drawer, including the metadata described hereinbefore, e.g., the identifiers and VSD code associated with the repeat (step 410). After dispensing the original script in step 402, the dispense system 206 also prints the VSD code on the hardcopy VSD label (step 412), and allows the VSD label to be placed on the hardcopy duplicate (step 414), after which the hardcopy duplicate with the VSD label thereon can be scanned and uploaded, e.g., at the end of the day, by the image uploader 208 (step 416). The archive service 220 receives the uploaded document image from the image uploader 208, and stores the uploaded image, and deciphers the VSD code to determine the internal ID, as described hereinbefore (step 418). The archive service 220 sends the internal ID associated with the VSD code to the VRG 214, which generates a link between the uploaded duplicate data (including the image data and the metadata) and the virtual repeat (including its image data and metadata) in step 420, after which the VRG 214 sends the uploaded and linked duplicate data (which may be referred to as the “virtual duplicate”) to storage, e.g., the VSD storage 222 (step 422). H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -19- [078] As shown in Figure 5, in the queuing virtual repeat process 500, the VSD app 210 receives an input from the instore user, e.g., an instore operator selecting patient details when the patient enters the pharmacy (step 502). The VSD app 210 uses the VSD service 216 to search for available virtual repeats in the virtual script drawers stored in the VSD storage 222 (steps 504 and 506). The VSD app 216 receives user inputs to select one or more of the available scripts for this patient, which may include a plurality of the virtual repeats, e.g., for family members associated by the family ID, to generate identifiers of the selected scripts (step 508), and the VSD app 210 generates instructions for the VSD service 216 to add the selected scripts to the queue (step 510), and the VSD service 216 instructs the VSD storage 222 to move the selected scripts from the “script drawer” state to the “script queue” state in the VSD storage 222 (steps 512 and 514). In the queuing virtual repeat process 500, the VSD app 210, the VSD service 216 and/or the VSD storage 222 record a time stamp representing a selection time, when the selection data are received, representing the patient selecting the stored virtual repeat. This time stamp can be used for auditing processes, including determining time taken between selection of a virtual repeat and a signature time, when the signature is received from the patient, as described hereinafter.

[079] As shown in Figures 6A and 6B, the dispense virtual repeat process 600 commences with the dispense system 206 accessing the in-pharmacy queue, e.g., in a separate queuing application, such as “NXT Q” (step 602). The dispense system 206 communicates with the queue app 212 to display the queue in the dispense system 206 (step 604), e.g., as a pull-out screen or a pop-up screen in the electronic display for the pharmacists (step 604). To display the queue in step 604, the queue app 212 uses the VSD service 216 to retrieve the queue data from the VSD storage 222 (steps 606 and 608).

After displaying the queue at step 604, the queue app 212 receives a selection from the pharmacist of one of the queued virtual repeats to dispense (step 610), and the queue app 212 sends the script data from the virtual repeat to the dispense system 206 in step 610, for the dispense 206 to receive a user input indicating that the dispense has started (step 612). When the dispense system 206 receives the dispense-start user input in step 612, the dispense system 206 sends a time stamp to the VSD service 216, which stores the time stamp in the metadata of the queue in the VSD storage 222 (steps 614 and 616), thus H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -20- recording a queue time when the selection data is received, representing the pharmacist selecting a queued script for dispensing. The recorded dispense time can be used for subsequent auditing processes. After the dispense is started in step 612, the dispense system 206 generates a simultaneous display of the virtual duplicate and the virtual repeat on the electronic screen for the pharmacist to approve (step 618), which includes the dispense system 206 receiving the digital images of the virtual duplicate and the virtual repeat from the archive service 220 via the VSD service 216 (steps 620 and 622). When the pharmacist has viewed and approved the dispense based on the side-by-side comparison of the virtual duplicate and the virtual repeat in step 618, the dispense system 206 receives an input that the dispense is complete (step 624), and subsequently generates the dispensed script information, including the tally information, as described hereinbefore (step 630), and sends the tally information to the VSD service 216, which in turn constructs the virtual claim sticker (VCS) (step 632) and applies that VCS image to the virtual repeat image, i.e., the same virtual repeat image retrieved in steps 620, 622 and viewed in step 618 (step 634), e.g., by again accessing the virtual repeat metadata from the VSD storage 222 that they are associated with the dispense virtual repeat (step 636). After the VCS is applied to the virtual repeat in step 634, the VSD service 216 updates the image data for the virtual repeat in the VSD storage 222 (step 638), and stores the virtual repeat with the VCS applied in the archive service 220 (step 640), and advances the state of the dispensed virtual repeat from “script queue” to “script sign” in the VSD storage 222 (step 642). In the dispense virtual repeat process 600, the VSD service 216 or VSD storage 222, or another component, records a tally time when the VCS is applied to the virtual repeat, and the state is advanced in step 642, thus providing an auditable time for application of the VCS and tally information. After the tally information is applied to the virtual repeat in step 634, the VSD service 216 constructs the virtual repeat with the VCS (step 644) by retrieving the next serial script ID from the VSD storage 222 (step 646), and stores the digital image of the virtual repeat with VCS (step 648) and the metadata representing the virtual repeat information and the tally information in the VSD storage 222 (step 650).

[080] As shown in Figure 7, in the virtual script signing process 700, which may occur some time after the dispense virtual repeat process 600, e.g., if the patient forgets to sign for their dispensed repeat, the VSD app 210 displays the patient scripts, i.e., the H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_1 .docx-17/03/2017 2017100309 17 Mar 2017 -21 - dispensed virtual repeats for the selected patient(s) in step 702, by retrieving the scripts or virtual repeats that are identified with that patient ID or family ID, and have the state “script signed” in the VSD storage 222 (step 704 and 706). The VSD app 210 then receives a user input to select which scripts to sign (step 708), and displays the virtual image for the patient to view (step 710) by accessing the virtual repeat with corresponding VCS from the VSD storage 222 via the VSD service 216 (steps 712 and 714). The VSD app 210 receives the input representing the patient signature, as described hereinbefore (step 716), and the VSD app 210 executes a verification step on the user signature, e.g., a further user input from an instore operator, and saves the data representing the signature, including image data representing the image of the signature (step 718), by sending the signature data to the VSD services 216. The VSD service 216 sends the signature data to the archive service 220 for storage in association with the corresponding virtual repeat as a signed virtual repeat (steps 720 and 724), and the VSD service 216 advances the state of the virtual repeat, in its metadata, from “script signed” to “script history” (step 722). In the virtual script signing process 700, the VSD app 210, the VSD service 216 and/or the VSD storage 222 record a time stamp representing a signature time, when signature data are received representing the patient signing the image of the VRA with the VCS. This time stamp can be used for auditing processes, including determining the time taken between the selection of the virtual repeat and the signature time.

INTERPRETATION

[081] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

[082] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention. H:\dxlMnterwoven\NRPortbl\DCC\DXLM 3510996_l.docx.-17/03/20l 7 2017100309 17 Mar 2017 -22-

CODE APPENDIX A — Repeat.XML <?xml version='1.0' encoding='utf-8' ?> <root> <background>repeat.jpg</background> 5 <! — ========== —> <!— Serial Number Field —> 10 <! — ========== —> <!— One Line —> 15 ctext x='165' y='220'>SerialNumberlLinel</text> <!— Two Line —> ctext x='165' y='195'>SerialNumber2Linel</text> ctext x='165' y='240'>SerialNumber2Line2c/text> 20 c! — ========== —> c!— Serial Number Field --> 25 <! — ========== -_> <!-- One Line --> 30 ctext x='830' y='220'>PrescriberNumberlLinelc/text> c!— Two Line --> ctext x='830' y='195'>PrescriberNumber2Linelc/text> ctext x='830' y='240'>PrescriberNumber2Line2c/text> 35 c! — ========== —> c!— Claim Type Field —> 40 <! — ========== —> ctext size='20' x='1255' y='205'>ScriptTypeGc/text> 45 ctext size='20' x='1255' y='305'>ScriptTypeCc/text> ctext size='20' x='1255' y='405'>ScriptTypeEc/text> ctext size='20' x='1255' y='505'>ScriptTypeRc/text> <! — 50 =================================================== ========== —> c!— Patients Medicare Number Field —> c! — 55 ========== —> H:\dxlMnterwoven\NRPortbl\DCC\DXLM 3510996_l.docx.-17/03/20l 7 2017100309 17 Mar 2017 -23- 10 15 20 25 30 35 40 45 50 55 <text x='310' y='330'>Erx</text> <barcode x='410' y='305' width='750' height='100'>BarCodeErxSCID</barcode> <! — ========== --> <!-- Patients Address Fields --> <! — ========== --> <text x='210' y='410'>PatientName</text> <text x='210' y='465'>PatientAddressLinel</text> <text x='210' y='520'>PatientAddressLine2</text> <text x='930' y='520'>PatientPostalCode</text> <! — ========== --> <!— On Hold —> <! — ========== —> <text x='70' y='520'>Hold</text> <! — ========== —> <!— Authority Number —> <! — ========== —> <!— One Line —> ctext font='consolas' x='270' y='620'>AuthorityNumberlLinel</text> <!— Two Line —> <text font='consolas ' x='270' y='600'>AuthorityNumber2Linel</text> <text font='consolas' x='230' y='650' size='5'>AuthorityNumber2Line2</text> <! — ========== —> <!— Entitlement Number —> <! — ========== —> <!— One Line —> <text font='consolas' x='735' y='620'>EntitlementNumberlLinel</text> <!— Two Line —> <text font='consolas' x='715' y='595'>EntitlementNumber2Linel</text> H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_l.docx-17/03/2017 2017100309 17 Mar 2017 -24- <text font='consoles' x='715' y='645'>EntitlementNumber2Line2</text> <! — 5 ========== —> < ! — Drug —> <! — 10 > <!— One Line —> ctext font='consolas ' x='55' y='778' size='9'>DrugPrescription[0]</text> ctext font='consolas' x='55' y='813' size='9'>DrugPrescription[1]</text> 15 <! — ========== —> <!— Directions —> <! — 20 ==================== —> ctext f ont= consolas' x= 55 ' y= 820 ' size='8 '>DrugInstructions [0 c/text> ctext f ont= consolas' x= 55 ' y= 850 ' size='8 ' >DrugInstructions [1 c/text> ctext f ont= consolas' x= 55 ' y= 880 ' size='8 ' >DrugInstructions [2 c/text> ctext f ont= consolas' x= 55 ' y= 910 ' size='8 '>DrugInstructions [3 c/text> ctext f ont= consolas' x= 55 ' y= 940 ' size='8 ' >DrugInstructions [4 c/text> <! — 30 ====================================== ========== —> <!— Repeat, Doctor, Repeats Left —> <! — 35 ========== —> ctext font='consolas' x='55' y='975' size='8'>RemainingRepeats</text> ctext font='consolas' x='390' y='975' size='8'>DoctorName</text> ctext font='consolas' x='1060' y='975' size='8'>RepeatNumberc/text> 40 c! — ========== —> c!— SafteyNetDR —> 45 ci — —> ctext font='consolas' x='55' y='1015' size='8'>SafetyNet20DRc/text> 50 c! — ========== —> c!— Script Creation Date —> 55 ci — > H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_l.docx-17/03/2017 2017100309 17 Mar 2017 -25- <text x='75' y='1180'>OriginalScriptCreationDate</text> <! — 5 ======================================================== ========== —> <!— PBS Approval —> <! — 10 ========== —> ctext x='420' y='1160'>OriginalPharmacyApprovalNo</text> < ! — 15 ========================================================= ========== —> <!— Original Script Number —> <! — 20 ========== —> ctext x='75' y='1300'>OriginalScriptNumber</text> < ! — 25 ================================================== ========== —> <!— Authorized Repeats —> <! — 30 ========== —> ctext x='600' y='1240' size='12'>NumberOfAuthorisedRepeats</text> <! — 35 ================================================================== ========== —> <!— ERX Label —> <! — 40 ========== —> ctext font='consolas' x='75' y='1350'>LabelErxSCIDc/text> c! — 45 ========================================================== ========== —> c!— Supply Number —> c! — 50 ========== —> ctext x='825' y='1240' size='12'>SupplyNumberLinelc/text> ctext font='consolas' x='815' y='1300' size='12'>SupplyNumberLine2c/text> 55 ci — > H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_l.docx-17/03/2017 2017100309 17 Mar 2017 -26- <!— ERX Barcode —> <! — ========== —> 5 <static x='1045' y='1230'>eRx&amp;gt;</static> <static font='consolas' size='6' x='1045' y='1280'>EXPRESS</static> <qrcode x='1165' y='1235' size='160'>BarCodeQRCodeSCID</qrcode> 10 <! — ========== —> <!— Valid To —> <! — 15 ========================================================================= ========== —> ctext x='165' y='1480'>ValidTo</text> cbarcode x='70' y='1545' width='590' height='100'>BarCodeRepeat</barcode> 20 <text x='240' y='1660'>Reg25</text> <! — ========== —> 25 <!— Pharmacy Details —> <! — 30 —> ctext x= ' 730 ctext x= ' 730 ctext x= ' 730 ctext x= ' 730 ctext x= ' 730 35 y='1480'>PharmacyName</text> y='1530' size='7'>PharmacyDetailsLinel</text> y='1565' size='7'>PharmacyDetailsLine2</text> y='1600' size='7'>PharmacyDetailsLine3</text> y='1645' size='7'>PharmacyDetailsLine4</text> <text x= ' 730 ' y: '1690'>DispenseDatePharmacistInitials</text> 40 <text x='85' y='1935'>TodaysDate</text> </root> 2017100309 17 Mar 2017 H:\dxl\Interwoven\NRPortbl\DCC\DXL\l 3510996_ I .docx-17/03/2017 -27- CODE APPENDIX B — Codingsticker.XML <?xml version='1.0' encoding='utf-8' ?> <root> <background>codi ngsti cker.j pg</background> <!— One Line —> <text font='consol as' size='8' x='4' y='0'>LabelCodingLinel</text> <text font='consol as' size='7' x='4' y='0' backcolour='Black' forecolour='white'>LabelCodi ngLi nelAlternate</text> <text font='consol as' size='7' x='4' y='50'>DrugLine[0]</text> <text font='consol as' size='7' x='4' y='85'>DrugLine[l]</text> <text font='consol as' size='7' x='4' y='120'>DrugLine[2]</text> 15 <text font='consol as' size='7' x='4' y='165'>LabelCodingLine3</text> <text font='consol as' size='6' x='4' y='165'>LabelCodi ngLi ne3Smal1er</text> <text font='consolas' size='5' x='4' 20 y='165'>LabelCodi ngLi ne3Smal1est</text> <text font='consolas' size='7' x='4' y='200'>LabelCodingLine4</text> </root> H:\dxl\Interwoven\NRPortbl\DCC\DXL\l 3510996_ I .docx-17/03/2017 2017100309 17 Mar 2017 -28- CODE APPENDIX C — WinForaisRenderer.es using System; usi ng System.Col1ections.Generic; 5 using System.Drawing; usi ng System.Drawi ng.Drawi ng2D; using System.10; namespace Vi rtualPrescription.Renderer 10 { public class winFormsRenderer<T>: lRenderer<T>, iDisposable where T : class { private Bitmap _bitmap; 15 private Graphics _graphics; private Dictionary<string, Font> _fontcache = new Dictionary<string, Font>(); private Dictionary<string, Brush> _brushcache = new Dictionary<string, Brush>(); 20 public void SetBitmap(Bitmap bitmap) { _bitmap = bitmap; 25 } public void LoadlmageFromFi1e(string imageName) _bitmap = (Bitmap)lmage.FromFile(imageName); _graphics = Graphics .Fromlmage(_bitmap); public void LoadlmageFromStream(Stream reader) _bitmap = (Bitmap) Image.FromStream(reader); 35 _graphics = Graphics .Fromlmage(_bitmap); public void OverlayBitmap(int x, int y, Bitmap bitmap, bool makeTransparent = true) 40 {

Graphics g = Graphics.Fromlmage(_bitmap); if (makeTransparent) { g.CompositingMode = CompositingMode.SourceOver; 45 bitmap.MakeTransparent(); } bi tmap.SetResoluti on(_bitmap.Hori zontalResoluti on, _bitmap.Vertical Resolution); ?.Drawlmage(bitmap, x, y); public void RenderText(string fontName, int fontsize, string backColour, string forecolour, PointF location, string text) 55 if (_bitmap == null) throw new Exception("Renderer bitmap not initalized"); if (_graphics == null) throw new Exception("Renderer graphics canvas not initalized"); 60 string fontCacheName = fontName + fontsize; string foreColor = forecolour .ToLowerQ; 2017100309 17 Mar 2017 60 H:\dxl\Interwoven\NRPortbl\DCC\DXL\13510996_l.docx.-17/03/2017 -29- string backColor = backColour.ToLowerC); if (!_fontCache.containsKey(fontcacheName)) _fontCache[fontCacheName] = new Font(fontName, fontsize); if (!_brushcache.ContainsKey(foreColor)) _brushCache[foreColor] = new SolidBrush(Color.FromName(foreColor)); if C!_brushcache.containsKey(backColor)) 10 _brushCache[backColor] = new SolidBrush(Color.FromName(backColour)); if (backColor != "white") { var size = .graphics.Measurestring(text, _fontCache[fontCacheName]); 15 var rect = new RectangleF(location.X, location.Y, size.width, size.Height) ; _graphics.FillRectangle(_brushcache[backColor], rect); 20 .graphics .DrawString(text, .fontCache[fontCacheName], .brushcache[forecolor], location); public T GetBitmapO 25 { return .bitmap as T; } bool .disposed; 30 protected virtual void Dispose(bool disposing) if (i.disposed) 35 if (disposing) foreach (Font font in .fontCache.Values) font. Dispose (); .fontCache = null; 40 foreach (Brush brush in .brushcache.Values) brush.Dispose(); .brushcache = null; 45 .graphics . Dispose(); .graphics = null; .bitmap.Dispose (); .bitmap = null; 50 } } .disposed = true; public void Dispose() {

Dispose(true); GC.SuppressFinalize(this);

Claims (10)

1. THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

   1. A method performed by one or more computer processors, the method including: generating data representing a unique code for a script of a patient; generating data for to printing the unique code to a unique label for application to a duplicate script associated with the script; receiving a digital image of the duplicate script including the unique label; processing data representing the digital image to match the digital image to the unique code; and storing the digital image data in association with data representing the unique code in at least one database.
2. 2. The method of claim 1, including any one or more of: receiving data representing patient details to identify the patient, and storing the patient details data in association with the unique code in the database; receiving data representing repeat information associated with the script; accessing data representing a repeat template document; generating at least one data file representing a repeat script for the patient, incorporating the repeat template document and the repeat information; and storing the repeat data file in association with the unique code data in the database.
3. 3. The method of claim 1 or 2, including: receiving data representing a search, including requested patient details; selecting the repeat file by matching the requested patient details with stored patient details associated with the repeat file; generating data representing a request for user input from a pharmacist to view the repeat file; on receiving the user input, accessing and displaying simultaneously: the repeat file, and the digital image of the duplicate script that is associated with the repeat script in the database; generating data representing tally information based on the repeat information associated with the repeat script; generating a further data file representing the repeat script with the tally information applied; displaying the repeat script with the tally information applied; receiving patient input data representing a signature on the repeat script with the tally information applied; and generating and storing data representing a signed further repeat file that includes the repeat script with the tally information applied and the signature applied in association with the unique code data in the database.
4. 4. A method performed by one or more computer processors, the method including: generating data representing a virtual repeat authorisation (VRA) for an original medical prescription (OMP) based on: (i) a repeat authorisation layout; (ii) a selected legal prescription identifier (LPI) provided by a medical authority; and (iii) repeat details associated with the OMP; rendering the VRA as a image for storage, wherein the rendering includes rendering the pharmaceutical details and the LPI onto the repeat authorisation layout.
5. 5. The method of claim 4, including: generating data representing a virtual claim sticker (VCS) based on legal details of supply; and rendering as an image the VRA with the VCS.
6. 6. The method of claim 5, including receiving data representing a signature from a patient; and storing as an image the signature on the virtual repeat authorisation with the VCS.
7. 7. The method of claim 6, including: recording a selection time when selection data are received representing a patient selecting a stored VRA; and recording a signature time when signature data are received representing the patient signing the image of the VRA with the VCS.
8. 10. The method of any one of claims 4 to 7, including: storing a virtual duplicate of the OMP as an image; retrieving the duplicate and the VRA as images; and displaying an image of the VRA next to an image of the virtual duplicate.
9. 11. A system including one or more computer processors, and one or more modules configured to perform the method of any one of claims 1 to 10.
10. 12. Storage media including machine-readable instructions to control one or more processors to perform the method of any one of claims 1 to 10.