Implementation system and method of chemical request

Abstract

To provide a system for implementation of a chemical request corresponding to a chemical inclusion unit and a related method.SOLUTION: The system of the invention can comprise a request implementation logic for providing determination data which is used for selecting one out of plural different implementation places by which a given chemical request is implemented, to a care provider of a patient. A request router can send the chemical request to the selected one out of the plural implementation places. The implementation place can provide chemical request metadata (for example, data related to preparation and handling of the chemical) to a chemical request database corresponding to the chemical request implemented by the implementation place. The chemical request metadata can be stored in the chemical request database, and to which access is possible for promoting improvement of a management function related to a chemical which is distributed by a care provider of a patient.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] (Related Application) This application claims priority based on U.S. Provisional Patent Application No. 61 / 695,831, entitled "Drug Request Fulfillment System and Method," filed on August 31, 2012, the entire disclosure of which is incorporated herein by reference.

[0002] The present invention relates to a drug request fulfillment system and related methods to be dispensed by a patient's care provider for administration to a patient.

Background Art

[0003] A patient's care provider routinely dispenses drugs for administration to a patient during the process of providing medical services. In this regard, the dispensing and administration of drugs may require permission from the relevant regulatory authorities. Drugs may be prepared and / or otherwise dispensed by a pharmacy located at the care provider's location for a given patient or by another pharmacy in partnership or by a third-party source. For example, many hospitals have an in-house pharmacy where drugs can be dispensed after being prepared.

[0004] Numerous factors may pose logistical challenges to a patient's care provider in fulfilling drug requests. For example, drugs dispensed by a given patient's care provider on a per-occurrence basis may have different associated fulfillment timing requirements to ensure timely dispensing and administration of the drugs to the corresponding patient. Further, it can be difficult to maintain the range of inventory that a pharmacy needs to hold to accommodate a wide range of potential drugs, especially in relation to drug components with expiration dates, handling / storage conditions, and / or that have experienced supply shortages. Also, preparing certain types of drugs generally requires special devices, equipment, and skills that may not be readily available, thereby limiting the outsourcing options. Additionally, cost-effectiveness may not be applicable to many patient care providers.

[0005] In addition to the above, there is a growing emphasis in the medical field on maintaining detailed records regarding medications. Such record keeping may involve obtaining and storing various data related to the preparation and handling of medications. In this regard, the administrative burden associated with such record keeping continues to increase. Current existing methods for obtaining medications primarily involve a source selection process in which limited and / or static data is used for selection and / or a source selection process in which the options for source selection are otherwise restricted.

SUMMARY OF THE INVENTION

[0006] The present disclosure generally relates to an improved system and related methods for fulfilling a medication request to be dispensed by a patient's care provider for administration to a patient.

[0007] In one aspect, the improved system comprises a request generator and request fulfillment logic provided for a patient's care provider. The request generator can be used to generate a medication request for at least one medication-containing unit to be dispensed by a patient's care provider and administered to a patient. The request fulfillment logic can be implemented by means of a computer for providing decision data used in selecting one of a plurality of different fulfillment locations for processing the medication request and fulfilling the medication request. The decision data may be at least partially based on one of the medication request fulfillment cost data and / or medication request fulfillment timing data corresponding to each of the plurality of fulfillment locations. The system may further include a request router for sending a given medication request to a selected fulfillment location selected from a plurality of fulfillment locations for preparing the medication request.

[0008] Thus, the system liberates and / or assists the user of the patient's care provider in intellectual tasks such as recording the inventory / availability of drugs at the fulfillment location. Further, the user can obtain drugs optimal for the needs of the patient's care provider from the appropriate fulfillment location. Also, the system enables an improved human-machine interaction since the request router can send drug requests to the selected fulfillment location without the need for interaction with the user of the patient's care provider. As used herein, the term user of the patient's care provider may, but is not limited to, relate to a human such as an employee or owner of the patient's care provider.

[0009] It will be appreciated that providing a system having request fulfillment logic that provides decision data can facilitate achieving an improved cost-effectiveness and / or timely fulfillment of drug requests by a patient's care provider. For example, the decision data can be provided to assist the patient's care provider in evaluating the trade-offs between different fulfillment locations for a given drug request.

[0010] In an envisioned embodiment, at least one or two or more of the plurality of fulfillment locations may be remote from the patient's care provider. Further, at least another one of the plurality of fulfillment locations may be at the location of the patient's care provider corresponding thereto. For example, the patient's care provider may have an in-house pharmacy or other partnering pharmacy. Thus, the system enables the user of the patient's care provider to automatically select the optimal one of a number of fulfillment locations without the need to access each individual fulfillment location. Further, the user of the patient's care provider can reduce the processing power at the location of the patient's care provider by accessing and / or utilizing the processing power of one or two or more fulfillment locations.

[0011] In an intended embodiment, the patient's care provider may consist of an entity permitted by the regulatory agency to dispense drug requests. Further, the patient's care provider may be an entity permitted by the regulatory agency to create drug requests.

[0012] As a primary example, the patient's care provider may be · an emergency treatment location · a hospital · a home infusion pharmacy (HIP) · a clinic or · an independent infusion clinic and may include at least one of these.

[0013] In connection with the intended system, a drug-containing unit corresponding to a given drug request can be obtained by the patient's care provider from a selected fulfillment location and dispensed by the patient's care provider for administration to the patient. In this regard, the drug-containing unit can include · a patient-specific unit containing a drug designated for administration to a specific patient · a non-patient-specific unit containing a drug to be later designated for administration to a specific patient or · a unit of a drug component source used in the preparation of a patient-specific unit or non-patient-specific unit (e.g., a unit designated for administration to a specific patient after preparation). and can include one of these.

[0014] In some examples, the drug-containing unit may include a nutritional supplement or a component of a nutritional supplement for which administration is requested by the patient's care provider. As an example, the drug-containing unit may consist of a parenteral nutritional supplement (e.g., total parenteral nutrition or total nutrient admixture). In some embodiments, the drug-containing unit may be received by the patient's care provider from a remote fulfillment location, and the drug-containing unit may be associated with a kit that includes a plurality of drug-containing units (e.g., a container used for handling a corresponding plurality of drugs). The association may be obtained and defined in a database and / or a table of the database that identifies the corresponding kit for each drug-containing unit. Thus, there may be a direct relationship between exactly one specific drug-containing unit and one specific kit for each drug-containing unit and for each kit. In this regard, various drug requests corresponding to a plurality of drug-containing units including the kit can be associated with the corresponding kit identifier, thereby facilitating various record-keeping functions (e.g., obtaining and maintaining specific drug request metadata referred to below in this specification). For example, a kit identifier (e.g., a machine-readable label on a container used for handling a corresponding plurality of drugs) can be used to facilitate data collection related to the location, handling, etc. of the related drugs. Thus, this system can provide a large number of drug-containing units (i.e., kits of drug-containing units) for a specific drug-containing unit simply and efficiently, and maintain records regarding it without the need to separately obtain / record information for each individual / specific drug. In particular, in view of the complexity of systematizing a series of products, this system provides a kit of drugs and at the same time enables easy and automatic access to specific drugs. This system particularly comprises a computing environment that executes or is part of a request generator and / or request fulfillment logic and / or request router.

[0015] As described above, the system can include request fulfillment logic for providing decision data based at least in part on at least one of drug request fulfillment cost data and / or drug request fulfillment timing data corresponding to each of a plurality of fulfillment locations. Such data may be stored in a drug request database or maintained in another manner.

[0016] The drug request fulfillment timing data is · Medication request fulfillment lead time data · Medication request availability data · Medication request delivery schedule data · Medication request effectiveness timing data and / or · Medication component effectiveness timing data can include at least one of.

[0017] Medication request fulfillment cost data can include data indicating the cost of fulfilling a given medication request at a given fulfillment location.

[0018] In an envisioned system implementation, each of a plurality of fulfillment locations can provide all or at least a portion of the medication request fulfillment cost data and / or medication request fulfillment timing data corresponding to a given fulfillment location. That is, such data (simply referred to as medication request data) can be provided to a medication request database by a fulfillment location. For example, this data may be provided based on a periodic request / response or otherwise. As another example, this data may be provided in relation to a given type or other specified medication.

[0019] In some implementations, the request fulfillment logic can have one or more algorithms (e.g., a computer-readable medium) for processing medication requests in relation to the medication request fulfillment cost data and / or medication request fulfillment timing data stored in a medication request database. In one approach, the algorithms can selectively establish a weighting of parameters associated with each of the medication request fulfillment cost data and / or medication request fulfillment timing data (e.g., via instructions of a software program / user input).

[0020] In some applications, the request fulfillment logic may be provided to be customizable by a given patient's care provider. By way of example, a given patient's care provider may set the weighting parameters of the algorithm and / or define additional logic parameters.

[0021] In certain embodiments, the request fulfillment logic can be made operative to automatically select a fulfillment location for fulfilling a given drug request based on the generated decision data. It will be appreciated that such an automatic selection function may be established in connection with a given type of drug request. Further, in some embodiments, the request router may be operative to automatically send the drug request to the automatically selected fulfillment location. Thus, this system can enable efficient fulfillment of pharmaceutical drug requests without the need for human interaction. In particular, since the router is less likely to generate errors that humans may make, the system can be made more fail-safe and thereby improve efficiency.

[0022] In some configurations, the selected fulfillment location may be configured to selectively, automatically and / or semi-automatically reject a given drug request sent (e.g., in the event of an unexpected or other situation). In response, the rejection of the request may be communicated (e.g., selectively, automatically and / or semi-automatically) by the fulfillment location to the fulfillment logic and the drug request database, and the request fulfillment logic is further utilized to provide decision data used to select a different fulfillment location. Accordingly, the drug request database can be updated in connection with the drug request.

[0023] In an intended embodiment, a fulfillment location selected to fulfill a given drug request can be configured to supply drug request metadata to a drug request database regarding fulfillment of the drug request. In this regard, the selected fulfillment location may follow a predetermined procedure and / or utilize data collection means to obtain drug request metadata related to the preparation, handling, etc. of the drug corresponding to a given drug request and supply the drug request metadata to the drug request database. In response thereto, the system may be provided such that a patient's care provider corresponding to a given drug request can access at least a portion of the corresponding drug request metadata from the drug request database.

[0024] The drug request metadata can include one or more of the following types of data. · Drug source data indicating at least one of the following - Manufacturer of the components of the drug-containing unit corresponding to the drug request - Lot number of the components of the drug-containing unit corresponding to the drug request - Expiration date of the components of the drug-containing unit corresponding to the drug request - Manufacturing number of the components of the drug-containing unit corresponding to the drug request - Drug code indicating the identification of the components of the drug-containing unit corresponding to the drug request · Production and circulation management (COC) data indicating at least one of the following - List of the components of the drug-containing unit corresponding to the drug request or the entities owning the drug-containing unit corresponding to the drug request - List of users who have taken actions related to the drug-containing unit corresponding to the drug request, correlated with the specific actions taken by each user - Tracking information corresponding to the physical movement of the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request · Fulfillment data indicating at least one of the following - Image data leading to the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request - Scan data obtained from the components of a drug-containing unit corresponding to a drug request - Analysis data regarding the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request - Pharmacist review data corresponding to at least one pharmacist review regarding the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request - Compliance data corresponding to best practices related to the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request - Evaluation data of the sterilization state corresponding to the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request - List of procedures corresponding to the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request - Timestamp data corresponding to the procedures corresponding to the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request or - List of events related to the life cycle that occurred in relation to the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request or · Environmental data indicating at least one of the following - Temperature to which the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request have been exposed - Temperature to which the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request have been exposed and the corresponding time - Whether the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request are refrigerated - Whether the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request are frozen - Temperature profile received by the components of a drug-containing unit corresponding to a drug request or the drug-containing unit corresponding to the drug request or - Component of a drug-containing unit corresponding to a drug request or accelerometer data corresponding to a force received by a drug-containing unit corresponding to a drug request.

[0025] It will be understood that the management function of the drug fulfillment system can be improved by the availability and accessibility of drug request metadata. Drug request metadata is particularly used and / or stored by a computer, liberating and / or assisting the user of the patient's care provider from the (intellectual) work of recording and / or collating the above data. In particular, without the (computer-assisted) system according to the present invention, the above data management and data processing would not be possible.

[0026] In various embodiments, the contemplated system may include a distributed drug request management system that operatively communicates with a request router to receive drug requests from the request router at each of a plurality of fulfillment locations. In response thereto, the system may further include a drug request management network including a distributed drug request management client, a drug request database, and a request router. In such embodiments, at least a portion of the corresponding drug request metadata may be maintained at a remote physical location.

[0027] In another aspect, a distributed drug request management system can comprise a request generator that generates a drug request for at least one drug-containing unit for dispensing by a patient's care provider, and a drug request database operable to store the drug request. The system may further include a plurality of drug request management clients at a plurality of fulfillment locations capable of fulfilling the drug request. A drug request management network may be provided to operatively communicate with each of the plurality of drug request management clients, the drug request database, and the request generator, and the drug request management network is operable to provide the drug request to a drug request management client at a selected fulfillment location chosen from the plurality of fulfillment locations. The system may be provided such that a patient's care provider obtains a drug-containing unit corresponding to the drug request from the selected fulfillment location for dispensing and administration to the corresponding patient, and the selected fulfillment location provides drug request metadata to the drug request management network for storage in the drug request database corresponding to the drug request.

[0028] It will be appreciated that various ones of the above-described features and combinations thereof may be utilized in a distributed drug request management system.

[0029] In another aspect, a method for fulfilling a drug request to be dispensed by a patient's care provider for administration to a patient is provided. In some embodiments, the method may include the patient's care provider generating a drug request by using a request generator, the drug request being for at least one drug-containing unit for administration to the patient. The method further includes the patient's care provider using request fulfillment logic, which is implemented by means of a computer, to process the drug request, and the processing provides decision data used in selecting one of a plurality of fulfillment locations for fulfilling the drug request. In this regard, the decision data may be at least partially based on one of drug request fulfillment cost data or drug request fulfillment timing data corresponding to each of the plurality of fulfillment locations. Further, the method may include a request router sending the drug request to a selected fulfillment location selected from a plurality of fulfillment locations for creating the drug request.

[0030] In some embodiments, the method may further include automatically selecting a selected fulfillment location based at least in part on the decision data by operation of the request fulfillment logic. Additionally or alternatively, the method may further include automatically sending the drug request to the selected fulfillment location for fulfillment of the drug request by operation of the router. In various method embodiments, the method may employ a system having any of the features of the systems described herein.

[0031] According to yet another aspect, a computer program product is provided that can be stored on a computer-readable medium and / or executed as a computer-processable data stream, the computer program product including computer-processable instructions that, when read into a computer's memory and executed by the computer, cause the computer to perform the method outlined above and described in further detail below with additional examples.

[0032] Many additional features and advantages of the present invention will become apparent to those skilled in the art upon consideration of the following description of the embodiments provided below.

Brief Description of the Drawings

[0033]

Figure 1

Figure 2

Best Mode for Carrying Out the Invention

[0034] FIG. 1 illustrates an embodiment of a system 100 for fulfilling a drug request. The drug request may correspond to at least one drug-containing unit. The containing unit may be, for example, · a syringe · a medicine bottle · a bag or · another drug container used for administering drugs to a patient or used in the process of preparing drugs for administration to a patient and may include one of them.

[0035] System 100 may include a number of components that can be used to generate a drug request, create decision data for use in selecting a fulfillment location for fulfilling the drug request, and send a given drug request to the selected fulfillment location. In this regard, the components of system 100 may each include a request generator 20, a request fulfillment logic 30, and a request router 40. By way of example, the request generator 20, the request fulfillment logic 30, and the request router 40 may be located at the location of the patient's care provider 10.

[0036] The request generator 20 can generate a drug request corresponding to the drugs used or dispensed by the patient's care provider 10 for administration to the patient 70. The request generator 20 may be operable to generate a drug request automatically or partially automated based on a command including a data stream. By way of example, this command may correspond to the drugs prescribed by a physician.

[0037] In one approach, the request generator 20 may be operable to analyze data from a data stream or otherwise extract data for generating a drug request. Additionally or alternatively, the request generator 20 may generate a drug request based on data received directly from a user (such as by data input via a user interface).

[0038] The request generator 20 may be operable to provide a drug request for processing by the request fulfillment logic 30. The request fulfillment logic 30 may comprise computer - implemented means (including hardware and / or software, etc.) for providing decision data used in selecting one of a plurality of fulfillment locations for fulfilling a given drug request. The computer - implemented means can include a memory operable to store persistent machine - readable instructions executable by a processor. The request fulfillment logic 30 may further include or access a database that may be used by the request fulfillment logic 30 for generating the decision data.

[0039] The data utilized by the request fulfillment logic 30 for providing the decision data may at least include drug request preparation cost data and / or drug request preparation timing data corresponding to a plurality of potential fulfillment locations having the ability to fulfill the drug request. For example, as shown in FIG. 1, the remote fulfillment location 60a, the remote fulfillment location 60b, or the fulfillment location 55 may all be potential fulfillment locations for fulfilling the drug request.

[0040] In this regard, the request fulfillment logic 30 may provide decision data to the user (such as being provided to the user at the patient's care provider 10 via a user interface device). Thereafter, the user may select (such as via an input in the user interface) one of a plurality of fulfillment locations for the fulfillment of the drug request. In one embodiment, the request fulfillment logic 30 may automatically select a fulfillment location based at least in part on the decision data regarding a given drug request. Optionally, the determination of whether the fulfillment location is selected by the user or automatically selected may depend at least in part on distinguishable features of a given drug request (such as depending on the drug type, the amount of the drug, timing requirements, or other data related to the drug request). In this regard, potential time savings and cost reduction can be achieved.

[0041] As described above, the request router 40 may be provided to send the drug request to a selected fulfillment location for the fulfillment of the drug request. As schematically shown in FIG. 1, at least one on-site fulfillment location (such as fulfillment location 55) and / or at least one off-site fulfillment location (such as fulfillment locations 60a, 60b, etc.) may be selectable to fulfill a given drug request.

[0042] Regardless of the relative position of the selected fulfillment location, the request router 40 may be operable to communicate the drug request to the selected fulfillment location. The request router 40 may receive an identification of the selected fulfillment location from a user (such as a user of the patient's care provider 10) or may automatically send a command for the drug request to the selected fulfillment location based on the automatic selection of the fulfillment location by the request fulfillment logic 30.

[0043] One or more fulfillment locations 60a, 60b may be configured to selectively, automatically, and / or semi-automatically reject a given sent drug request (e.g., in the event of an unexpected situation). In response thereto, the rejection of the request may be communicated (e.g., selectively, automatically, and / or semi-automatically) by the fulfillment location 60a or 60b to the request fulfillment logic 30 and the drug request database 90, and the request fulfillment logic 30 may be further utilized to provide decision data for use in selecting a different fulfillment location. Accordingly, the drug request database 90 may be updated in relation to the drug request.

[0044] As described above, the fulfillment location may include one or more remote fulfillment locations 60a, 60b that are remote from the patient's care provider 10. Additionally, the patient's care provider 10 may include the location of the patient's care provider that may include a pharmacy 50. In response thereto, the pharmacy 50 may include a fulfillment location 55 within the pharmacy 50. It will also be understood that the patient's care provider 10 may be partnered with a pharmacy 50 that is off-site relative to the location of the patient's care provider. In any case, each of the fulfillment locations 55, 60a, 60b may be able to fulfill a drug request and provide the drug corresponding to the drug request for the pharmacy 50. In response thereto, the pharmacy 50 may be operable to dispense the drug for administration to the patient 70.

[0045] Further, as illustrated in FIG. 1, the drug request management network 80 may operably communicate with the remote fulfillment locations 60a, 60b and the patient's care provider 10. The drug request management network 80 may operably communicate with the drug request database 90. The drug request database 90 may be operable to store one or more sets of data, or portions of data, corresponding to each of the given drug requests.

[0046] The medication request database 90 can be located at a single location remotely from or local to the location of one or more patients' care providers or remote fulfillment locations. The medication request database 90 may be provided at a separate different location from either the location of the patients' care providers or the remote fulfillment locations. Further, the medication request database 90 may have multiple parts or instances, each of which can be located at a separate location corresponding to or away from the location of the patients' care providers or the remote fulfillment locations.

[0047] For example, the medication request database 90 may store medication request metadata regarding the medication requests. Additionally, the medication request database 90 may store the medication request fulfillment cost data and medication request fulfillment timing data employed by the request fulfillment logic 30 and generate decision data for use in selecting one of a plurality of fulfillment locations for fulfilling the medication requests. In this regard, the remote fulfillment locations 60a, 60b may be in operative communication with the medication request database 90 to provide the medication request fulfillment cost data and medication request fulfillment timing data corresponding to their respective fulfillment locations to the medication request database 90.

[0048] The medication request database 90 may be remote from the remote fulfillment locations 60a, 60b as well as from the patients' care provider 10. Alternatively, the medication request database 90 may be at one of the remote fulfillment locations 60a, 60b or at the location of the patients' care provider 10. In any case, access to the medication request database 90 can be facilitated via the medication request management network 80.

[0049] It will be understood that the patient's care provider 10 may include an entity licensed by a regulatory authority (such as a pharmacy department) to distribute and prepare drug-containing units for administration to the patient. In this regard, the patient's care provider may include an entity licensed to compound or otherwise prepare drug-containing units for administration to the patient. Primarily, examples of the patient's care provider include · Emergency treatment sites · Hospitals · Home infusion pharmacies (HIP) · Clinics · Independent infusion clinics or · Other suitable medical entities permitted to prepare drugs and the like.

[0050] In one application, the patient's care provider may be a hospital with an affiliated pharmacy. It will be understood that the affiliated pharmacy may be within the hospital in relation to the hospital or the hospital may be affiliated with an off-site pharmacy. In any case, for drugs related to a drug request, they can be administered to the patient by the patient's care provider at the location of the patient's care provider. In the case of an off-site pharmacy, the off-site pharmacy may provide services at the locations of multiple different affiliated hospitals.

[0051] As described above, the drug requests generated by the request generator 20 may each correspond to a drug-containing unit for administration to the patient. The drug-containing unit may be a patient-specific unit consisting of the drug designated for administration to a specific patient. In one embodiment, the drug-containing unit may include a non-patient-specific unit that will be designated later for administration to a specific patient. In one embodiment, the drug-containing unit may be a drug supply source unit (such as compounded or other components) used in the preparation of patient-specific units and / or non-patient-specific units.

[0052] In various embodiments, the drug-containing unit may be adapted to various different substances for which preparation is subject to licensing or other authorization by a regulatory agency. Examples of drug-containing units that may respond to a drug request include · compounded sterile preparations · injectable drugs · chemotherapy preparations or · nutritional supplements (sterile injectable nutritional supplements) that require administration by a patient's care provider and the like.

[0053] The nutritional supplements may include total parenteral nutrition (TPN) or components of TPN. Additionally, the nutritional supplements may include partial nutritional supplements. The nutritional supplements may include premix bags, bases, and additional components, either separately or in combination or in other forms, of the nutritional supplements or their components. The nutritional supplements may be for administration via intravenous injection or may be in an ingestible form or for use purposes such as via a feeding tube.

[0054] The drug request generated by the request generator 20 may include data indicating one or more characteristics or requirements of the drug request. In this regard, the drug request may include · identification of the drug · quantity of the drug · concentration of the drug · information related to the patient to whom the drug related to the drug request is to be administered · schedule information (administration time) related to the drug related to the drug request or · other appropriate information related to the drug related to the drug request and the like may be included.

[0055] In one embodiment, a drug request that includes or is related to any of the aforementioned data or other related data corresponding to the drug request may be stored in the drug request database 90.

[0056] In any case, the request fulfillment logic 30 determines decision data used to determine which fulfillment location may or may be optimal for fulfilling the drug request. To do so, it receives a drug request and is operable to compare the drug request (drug identification, drug quantity, drug concentration, scheduled dispensing time, etc.) in relation to drug request preparation timing data and / or drug request preparation cost data for a plurality of fulfillment locations.

[0057] In one example, the request fulfillment logic 30 may determine whether a drug request can be fulfilled based on whether any one or more of a plurality of fulfillment locations can fulfill the drug request before the scheduled dispensing time for the drug request at that fulfillment location. In this regard, the drug request fulfillment timing data may include, for example, · drug request fulfillment lead time data · drug request availability data · drug request delivery schedule data · drug request validity timing data or · drug component validity timing data. and so on.

[0058] Of these fulfillment locations that can fulfill a drug request in accordance with a scheduled administration time, the drug request fulfillment cost data may then be used to determine which of the eligible fulfillment locations indicates the lowest cost with respect to fulfillment of the drug request. In this regard, the fulfillment location with the lowest fulfillment cost that can fulfill the drug request in time for the scheduled administration of the drug related to the drug request may be identified as the selected fulfillment location. However, other logic may also be applied, for example, taking different balances during the consideration of drug request fulfillment cost data, drug request fulfillment timing data, or other relevant information used in the generation of the decision data. In that case, the logic applied may be selectively established by the caregiver 10 of a given patient. For example, the algorithm may be established by a weighting parameter related to the relative importance of the drug request fulfillment cost data with respect to the drug request fulfillment timing data. In one example, the caregiver 10 of the patient may predetermine or govern the weighting of the data. Other factors or data may also be weighted in the algorithm used to arrive at the decision data.

[0059] In contemplated embodiments, the caregiver 10 of the patient may be able to customize the algorithm and / or factors considered in providing the decision data. For example, the caregiver of the patient may give overriding conditions that dictate the selection of the selected fulfillment location, regardless of the decision data. The overriding conditions may be based on a particular period, a particular type for administration during a particular period, or a drug request generated in other factors related to the drug request or fulfillment of the drug request.

[0060] Still further in connection with the request router 40, as noted above, the request router 40 may be operative to send a drug request to a selected one of a plurality of fulfillment locations. Accordingly, the request router 40 may communicate directly with each of the remote fulfillment locations 60a, 60b as well as the fulfillment location 55 at the pharmacy 50 of the patient's care provider 10. In one embodiment, sending a drug request from the request router 40 to the selected fulfillment location may occur substantially in real time upon selection of the fulfillment location. In one embodiment, sending a drug request to the selected fulfillment location may occur periodically and may be initiated by either the request router 40 or the selected fulfillment location. The request router 40 may be operative to simultaneously transmit a group or batch of individual drug requests to a single fulfillment location if the fulfillment location has been selected as the selected fulfillment location for a number of drug requests.

[0061] In one embodiment, the request router 40 may provide a drug request to a fulfillment location via a drug request management network 80. In this regard, the request router 40 may communicate with the remote fulfillment locations 60a, 60b via the drug request management network 80 rather than directly between the request router 40 and the remote fulfillment locations 60a, 60b.

[0062] Each fulfillment location may be operable to provide drug request metadata (such as directly or via the drug request management network 80) to the drug request database 90 regarding the fulfillment of drug requests at the fulfillment location. The drug request metadata may include details regarding the composition, preparation, transportation, or other data related to the drug request. The drug request metadata may be maintained corresponding to the drug request records in the drug request database 90. The drug request metadata may be periodically updated by the fulfillment location before, during, or after the fulfillment of the drug request. This may be particularly advantageous in the case of a remote fulfillment location since the patient's care provider 10 can access the drug request database 90 to obtain information regarding the drug request during fulfillment by the remote fulfillment location. However, even in the case of a local fulfillment location (such as fulfillment location 55), the drug request metadata may be further provided to the drug request database (such as to maintain records corresponding to the drug requests).

[0063] The drug request metadata may include data corresponding to multiple different classes of data related to the drug request, such as · drug source data · production and circulation management (COC) data · fulfillment quality data or · environmental data and the like.

[0064] The drug source data may include, for example · the manufacturer of the components of the drug-containing unit corresponding to the drug request · the lot number of the components of the drug-containing unit corresponding to the drug request · the expiration date of the components of the drug-containing unit corresponding to the drug request · the manufacturing number of the components of the drug-containing unit corresponding to the drug request or · the drug code indicating the identification of the components of the drug-containing unit corresponding to the drug request and the like.

[0065] The production and circulation management (COC) data may include, for example · A list of the constituents of the drug-containing unit corresponding to the drug request or the name of the entity that owns the drug-containing unit corresponding to the drug request · A list of users who have taken actions related to the drug-containing unit corresponding to the drug request, correlated with the specific actions taken by each user, or · Tracking information corresponding to the constituents of the drug-containing unit corresponding to the drug request or the physical movement of the drug-containing unit corresponding to the drug request It may include data indicating the like.

[0066] The performance quality data may be, for example, · Image data corresponding to the constituents of the drug-containing unit corresponding to the drug request or leading to the drug-containing unit corresponding to the drug request · Scan data obtained from the constituents of the drug-containing unit corresponding to the drug request · Analysis data regarding the constituents of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request · Pharmacist review data corresponding to at least one pharmacist review regarding the constituents of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request · Compliance data corresponding to best practices related to the constituents of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request · Evaluation data of the sterilization state corresponding to the constituents of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request · A list of actions corresponding to the constituents of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request · Timestamp data corresponding to the actions corresponding to the constituents of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request, or · A list of events related to the life cycle that occurred in relation to the constituents of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request, or It may include data indicating the like.

[0067] Environmental data includes, for example, · The components of the drug-containing unit corresponding to the drug request or the temperature to which the drug-containing unit corresponding to the drug request has been exposed · The temperature and corresponding time to which the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request have been exposed · Whether the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request are refrigerated · Whether the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request are frozen · The temperature profile received by the components of the drug-containing unit corresponding to the drug request or the · Accelerometer data corresponding to the force received by the components of the drug-containing unit corresponding to the drug request and may include data indicating such.

[0068] Therefore, the fulfillment location for fulfilling the drug request may provide drug request metadata related to the drug request, whether it is the local fulfillment location 55 or the remote fulfillment locations 60a or 60b.

[0069] In the case of the remote fulfillment locations 60a or 60b, the remote fulfillment location may send a drug request related to physical delivery to the patient's care provider 10 for administration to the patient 70. Therefore, the remote fulfillment locations 60a, 60b can transport the drug request to the patient's care provider 10 or send it by other physical means. Therefore, the remote fulfillment location may utilize a dedicated transport vehicle and / or a third-party delivery service. In any case, the method of sending the drug request by physical means may include tracking data related to the transport of the drug request.

[0070] In one embodiment, the remote fulfillment location may send one or more medication requests to the patient's care provider 10 in a batch. In this regard, a kit may be sent from the remote fulfillment location to the patient's care provider 10. The kit may include multiple medication requests that are destined for the same patient's care provider 10. Therefore, the kit may include a kit identification display. Each medication request allocated to the kit may be correlated with the kit identification display. In this regard, once the kit is received by the patient's care provider, the kit identification display may be used to determine that each of the multiple medication requests associated with the kit has been received as well. Furthermore, any one of the medication requests identified as being associated with the kit may indicate that each of the other medication requests associated with the kit has been received.

[0071] Accordingly, the remote fulfillment location may also provide the kit identification display and the correlated medication requests associated with the kit to the medication request management network 80. In response, data regarding the kit identification display and the correlated medication requests associated with the kit may be provided to the patient's care provider 10 and / or the medication request database 90 for storage.

[0072] In one embodiment, each fulfillment location may include a medication request management client. The medication request management client can operatively communicate with the medication request management network 80, and the medication request management client is operable to receive / transmit data corresponding to the medication requests with the medication request management network 80. In this regard, the medication request management client may be utilized by the fulfillment location to assist in the preparation of the medications associated with the medication requests so as to generate or document the medication request metadata as described above.

[0073] FIG. 2 illustrates an embodiment of a medication request creation management client 210 that may be used at fulfillment location 200 to assist in the preparation and / or management of medication requests. Client 210 may be a thick client or a thin client at the fulfillment location. For example, client 210 may be a thin client such as a web browser executed on a device by accessing a web service at the fulfillment location. In this regard, a request receiving interface 220 may be provided to receive medication requests. As long as the above is followed, request receiving interface 220 may communicate directly with request router 40 or may operably communicate with request router 40 via a medication request management network 80.

[0074] The medication request may be communicated to a request creation management system 230. Request creation management system 230 may be operable to systematize 232 the medication request received at medication request creation management client 210. Systematizing may include prioritization, scheduling, or other operations related to the systematization or management of the medication request. Request creation management system 230 may be operable to send 234 the medication request to an appropriate workstation 240. In this regard, a plurality of workstations 240 may be provided, each suitable for different operations or workflows. Therefore, depending on the nature of the medication request, a particular type of workstation 240 may be used to create the request.

[0075] In this regard, request creation management system 230 may operably communicate with one or more workstations 240. Sending 234 the medication request may be at least partially based on the nature or type of the medication and the capabilities of the various workstations 240. In one embodiment, for example, other parameters such as engineer schedules, workstation schedules, workstation locations, or other information may be used alone or in combination to send 234 the medication request to a particular workstation 240.

[0076] In workstation 240, a workflow for use in creating a drug request may be prepared 242. In this regard, a specific workflow for a drug request currently being created in workstation 240 may be created or presented to a user in workstation 240. Thus, the user may follow a series of steps for preparing the drug corresponding to the drug request based on the presented completed workflow.

[0077] During and / or after creation of the drug request, workstation 240 may be used to assist in checking 244 the creation of a medical instruction. For example, workstation 240 may enable recording of documents related to the preparation of the drug, such as product barcode scanning, images of the device during or after use in preparing the drug, or other information related to the preparation of the drug. This data may correspond to at least a portion of the above drug request metadata.

[0078] Such information collected for checking 244 may be stored for the purpose of being viewed by appropriate personnel (such as a pharmacist) so that the pharmacist can confirm the created drug request before it leaves the fulfillment location 200. In one embodiment, the information and / or data collected in workstation 240 may be made available to a pharmacist via a network (such as drug request management network 80). In this regard, it will also be understood that an alternative or additional pharmacist (such as a pharmacist in patient care provider 10) may provide a simultaneous or additional review of the drugs related to the fulfillment of the drug request. In any case, the pharmacist involved in confirming the drug request may remotely access the information and / or data via network 80 (e.g., outside the room where the drug was prepared but at the fulfillment location, or a location completely outside the fulfillment location premises).

[0079] Once a drug request is created and checked at the workstation 240 according to the completed workflow 242, the drug request creation management system 230 may store the drug request in the drug request database 90 and / or send the drug request metadata to the drug request management network 80 for the purpose of obtaining permission from the patient's care provider 10. In response thereto, the drug request creation management system 230 may manage the sending 238 of the drug request to the patient's care provider 10. In this regard, in addition to providing data related to the drug request to the drug request management network 80, the drug request creation management system 230 may monitor the physical sending of the drug request to the patient's care provider 10.

[0080] The patient's care provider has limited access to the sources of drugs required for the patient's care at present. This limitation mainly stems from the current limitations of these systems and processes that can only make static selections for each specific type of drug. These static selections are often determined through a completely manual procurement / evaluation process and are only reexamined temporarily. This often results in a higher cost than the optimal cost to meet the provider's drug needs and significantly limits the ability of the patient's care provider to respond efficiently and quickly to events that require different procurement approaches - such as drug shortages or local situations that cause significant supply / demand changes.

[0081] When implementing the present invention, the patient's care provider will be able to define a series of dynamically applied rules for selecting the source of each specific type of drug. This dynamic response ability makes it possible to meet the drug needs in a more reliable manner over time, enables a more efficient and effective response to local events and supply problems, and enables low-cost drugs considering new sources.

[0082] The foregoing description of the invention has been presented for purposes of illustration and description. Furthermore, this description is not intended to limit the invention to the form disclosed herein. Accordingly, changes and modifications commensurate with the above teachings and the skill and knowledge of the relevant art are within the scope of the invention. The above embodiments have been described for known modes of carrying out the invention and are further intended to enable a person skilled in the art to utilize the invention in such or other embodiments and with the various modifications required by the singular or plural particular applications or uses of the invention. The appended claims are intended to be construed to include alternative embodiments insofar as is permitted by the prior art.

Claims

1. 1. A system (100) for fulfilling a medication order to be delivered by a patient care provider (10) for administration to a patient (70), comprising: an order generator (20) for use by a patient care provider (10) to generate a drug order for at least one drug-containing unit for administration to a patient; a request fulfillment logic (30) for use by a patient care provider (10) and executed by computer-based means, where the request fulfillment logic (30) processes a drug request to provide decision data for use in selecting one of a plurality of fulfillment locations (50, 60a, 60b) for fulfilling the drug request, the decision data being based at least in part on one of drug request fulfillment cost data or drug request fulfillment timing data corresponding to each of the plurality of fulfillment locations (50, 60a, 60b); and a request router (40) for sending the drug request to a selected fulfillment location (50, 60a, 60b) selected from a plurality of fulfillment locations (50, 60a, 60b) for fulfillment of the drug request.

2. 2. The system (100) of claim 1, wherein at least one of the plurality of fulfillment locations (50, 60a, 60b) is a remote fulfillment location (60a, 60b) that is remote with respect to the patient care provider (10).

3. The system (100) of claim 1 or 2, wherein the request generator (20), the request fulfillment logic (30) and the request router (40) are located at the patient care provider's (10) location.

4. The system (100) of any one of claims 1 to 3, wherein another one (50) of the plurality of fulfillment locations (50, 60a, 60b) is at a patient care provider location corresponding to the patient care provider (10).

5. The system (100) of any one of claims 1 to 4, wherein the patient care provider (10) comprises an entity authorized by a competent regulatory agency to generate drug requests.

6. The patient care provider (10) includes: Emergency treatment locations, hospital, Home Inpatient Pharmacy (HIP), Clinic or Independent Infusion Clinic, The system (100) according to any one of claims 1 to 5, comprising one or more of:

7. The system (100) of any one of claims 1 to 6, wherein the patient care providers (10) include hospitals having affiliated pharmacies (50).

8. 5. The system (100) of claim 4, wherein drug-containing units matching the drug request are obtained by the patient's care provider (10) from a selected fulfillment location for distribution and administration to the patient (70).

9. The drug-containing unit is Patient-specific units that contain medications designated for administration to a specific patient - non-patient specific units that contain medicines that are subsequently designated for administration to a specific patient, or - Drug component source units used in the preparation of patient-specific or non-patient-specific units The system (100) of claim 8, comprising at least one of:

10. 10. The system (100) of claim 8 or 9, wherein the drug-containing unit comprises a nutritional supplement or a component of a nutritional supplement required for administration by a patient care provider.

11. 11. The system (100) of any one of claims 8-10, wherein the drug-containing unit is received by the patient care provider (10) from a remote fulfillment location (60a, 60b), the drug-containing unit being associated with a kit including a plurality of drug-containing units, the plurality of drug-containing units having a corresponding drug request associable with a kit identifier corresponding to the kit.

12. The system (100) of any one of claims 8 to 11, wherein the drug-containing unit is administered to the patient (70) at the patient's care provider's location.

13. The system (100) of any one of claims 8 to 12, wherein said drug order fulfillment cost data and said drug order fulfillment timing data are stored in a drug order database (90).

14. The drug request execution timing data is Drug request fulfillment lead time data, Drug request availability data; Drug request delivery schedule data, Drug request efficacy timing data or Drug component efficacy timing data; The system (100) according to any one of claims 1 to 13, comprising at least one of:

15. The system (100) of any one of claims 1 to 14, wherein each of the plurality of fulfillment locations (50, 60a, 60b) provides to the drug request database (90) a portion of the drug request fulfillment cost data and drug request fulfillment timing data corresponding to the respective fulfillment location.

16. The system (100) of any one of claims 1 to 15, wherein the request fulfillment logic (30) is at least partially customizable by the patient's care provider (10).

17. The system (100) of any one of claims 1 to 16, wherein the order fulfillment logic (30) comprises an algorithm for use in processing a pharmaceutical order.

18. 20. The system (100) of claim 17, wherein the algorithm includes selectable weighting parameters associated with each of the drug order fulfillment cost data and the drug order fulfillment timing data.

19. 20. The system (100) of claim 18, wherein weighting parameters associated with the drug order fulfillment cost data and the drug order fulfillment timing data are customizable by the patient care provider (10).

20. The system (100) of any one of claims 17 to 19, wherein the patient care provider (10) defines additional logic parameters used by the request fulfillment logic (30).

21. The system (100) of any one of claims 1 to 20, wherein the request fulfillment logic (30) is operable to automatically select a selected fulfillment location based at least in part on decision data.

22. The system (100) of any one of claims 1 to 21, wherein the request router (40) is operable to automatically route the drug request to a selected fulfillment location for fulfillment of the drug request.

23. 23. The system (100) of any one of claims 1 to 22, wherein the selected fulfillment location is configured to selectively, automatically or semi-automatically communicate a rejection of the request to order fulfillment logic and a drug request database regarding the drug request, and the order fulfillment logic is operable to reprocess the drug request to generate decision data for use in selecting another one of a plurality of fulfillment locations for fulfilling the drug request.

24. The system (100) of any one of claims 1 to 23, wherein the selected fulfillment location is configured to provide the drug request metadata to the drug request database (90).

25. 25. The system (100) of claim 24, wherein the patient care provider (10) is capable of accessing at least a portion of drug request metadata from the drug request database (90).

26. The drug request metadata, Drug source data indicating at least one of the following: Manufacturers of components of drug-containing units that respond to drug requests; Lot numbers of components of the drug-containing unit corresponding to the drug request; Expiration dates of components of drug-containing units corresponding to drug requests; The serial numbers of the components of the drug-containing unit corresponding to the drug request or a drug code indicating the identity of a component of a drug-containing unit corresponding to the drug request; Chain of Custody (COC) data indicating at least one of the following: a list of the components of the drug-containing unit serving the drug request or the entities that own the drug-containing unit serving the drug request; a list of users who have taken actions regarding drug-containing units corresponding to the drug request, correlated to the particular actions taken by each user; tracking information corresponding to the physical movement of components of a drug-containing unit corresponding to the drug request or a drug-containing unit corresponding to the drug request; Fulfillment data indicative of at least one of the following: Image data of components of a drug-containing unit corresponding to the drug request or image data of a drug-containing unit corresponding to the drug request; scan data obtained from components of drug-containing units corresponding to the drug request; analytical data relating to the components of a drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request; pharmacist review data corresponding to at least one pharmacist review regarding components of a drug-containing unit corresponding to the drug request or a drug-containing unit corresponding to the drug request; compliance data corresponding to best practices related to components of a drug-containing unit serving a drug request or a drug-containing unit serving a drug request; Evaluation data of the sterility status of the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request; a list of components of a drug-containing unit corresponding to the drug request or procedures corresponding to a drug-containing unit corresponding to the drug request; timestamp data corresponding to a component of a drug-containing unit corresponding to the drug request or a procedure corresponding to a drug-containing unit corresponding to the drug request; or A list of components of a drug-containing unit serving the drug request or life cycle events that have occurred in connection with a drug-containing unit serving the drug request; or Environmental data indicative of at least one of the following: the temperature to which the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request have been exposed; the temperatures and corresponding times to which the components of the drug-containing unit corresponding to the drug request or the drug-containing unit corresponding to the drug request have been exposed; whether the components of the drug-containing unit serving the drug request or the drug-containing unit serving the drug request are refrigerated; whether a component of a drug-containing unit corresponding to the drug request or a drug-containing unit corresponding to the drug request is frozen; The temperature profile experienced by the components of the drug-containing unit serving the drug request or the drug-containing unit serving the drug request; or accelerometer data corresponding to forces experienced by components of a drug-containing unit corresponding to the drug request or a drug-containing unit corresponding to the drug request; The system (100) of claim 25, comprising at least one of:

27. 27. The system (100) of any one of claims 1 to 26, further comprising a distributed drug request management system including a distributed drug request management client in operative communication with the request router to receive drug requests from the request router at each of a plurality of fulfillment locations.

28. 28. The system (100) of claim 27, further comprising a drug request management network (80) having at least the distributed drug request management client, the drug request database (90), and the request router (40).

29. 30. The system (100) of claim 28, wherein at least a portion of the drug request data is at a remote physical location, in particular drug request fulfillment cost data is at a remote physical location and / or the drug request fulfillment timing data is at a remote physical location.

30. 30. The system (100) of claim 29, wherein the drug request database (90) is operable to store the drug request, in particular the drug request database (90) is operable to store the drug request fulfillment cost data and / or the drug request database (90) is operable to store the drug request fulfillment timing data.

31. 31. The system (100) of claim 30, wherein a drug request database (90) stores the drug request metadata corresponding to the drug request.

32. an order generator (20) for generating a medication order for at least one medication-containing unit for delivery by a patient care provider (10); a drug request database (90) operable to store said drug request; a plurality of drug request management clients at a plurality of fulfillment locations (50, 60a, 60b) capable of fulfilling drug requests; a drug request management network (80) in operative communication with each of said plurality of drug request management clients, said drug request database (90), and said request generator (20), wherein the drug request management network (80) is operable to provide a drug request to a drug request management client of a selected one of said plurality of fulfillment locations (50, 60a, 60b); A distributed medicine request management system (100) comprising: the patient care provider (10) obtaining drug-containing units matching the drug request from the selected fulfillment location for distribution and administration to the patient (70), and the selected fulfillment location providing drug request metadata to the drug request management network (80) for storage in the drug request database (90) in response to the drug request. A distributed drug order management system (100).

33. 1. A method for fulfilling a medication order to be delivered by a patient care provider (10) for administration to a patient, comprising: generating, by a patient care provider (10) using a request generator (20), a drug request for at least one drug-containing unit for administration to a patient; processing the drug request by the patient care provider (10) using request fulfillment logic executed by computer-based means, wherein the processing provides decision data for use in selecting one of a plurality of fulfillment locations (50, 60a, 60b) for fulfilling the drug request, the decision data being based at least in part on one of drug request fulfillment cost data or drug request fulfillment timing data corresponding to each of the plurality of fulfillment locations (50, 60a, 60b); sending, by a request router (40), the drug request to a selected fulfillment location (50, 60a, 60b) selected from a plurality of fulfillment locations (50, 60a, 60b) for creating the drug request; and how to fulfill the drug request.

34. 34. The method of claim 33, further comprising automatically selecting a selected fulfillment location (50, 60a, 60b) based at least in part on decision data by operation of the request fulfillment logic (30).

35. 35. The method of any one of claims 33 or 34, further comprising automatically sending the drug request to a selected fulfillment location (50, 60a, 60b) for fulfillment of the drug request by operation of the router (40).

36. A method according to any one of claims 33 to 35, utilizing a system (100) according to any one of claims 1 to 32.

Images