Method for generating database based on entity relationship model, drug library storage and distribution system, and drug library editing and distribution system
Through the drug library database and the dose error reduction system (DERS) based on the entity relationship model, the programming error problem caused by the one-to-one relationship between drugs and clinical solutions in the existing drug library model is solved, and the flexible configuration of the drug library and the improvement of infusion accuracy is achieved.
Patent Information
- Application Number
- CN202510332318.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2018-05-15
- Filing Date
- 2019-03-22
- Publication Date
- 2025-07-18
AI Technical Summary
Existing drug library models are usually based on drug name indexing, which makes the same drug unable to be used in different clinical programs, prone to programming errors, and lacks effective protection for the system of reducing dose errors.
A database is generated using an entity-based relationship model, through a one-to-many relationship between a drug entity and a therapy entity, allowing the same drug to have multiple delivery regimens, and introducing a dose error reduction system (DERS) into the infusion pump to prevent programming errors.
It realizes flexible configuration of the drug library, reduces programming errors, improves infusion accuracy, enhances the protection of dose errors, and supports flexible applications of a variety of clinical solutions.
Smart Images

Figure CN120340787A_ABST
Abstract
Description
[0001] This application is a divisional application of the patent application for invention titled "Therapy-Based Database Model for Generating a Drug Library" with the filing date of March 22, 2019, application number 201980031848.1 (international application number PCT / EP2019 / 057225).
[0002] Cross - reference to related applications
[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 671,424, filed on May 15, 2018, which is incorporated herein by reference in its entirety. This application is related to U.S. Provisional Patent Application No. 62 / 671,412, titled "Drug Library Compiler for Patient Devices", filed on May 14, 2018, which is incorporated herein by reference in its entirety. Background of the invention
[0004] Infusion pumps are commonly used in clinical settings to administer drugs and other medicaments to patients. The infusion pump delivers a controlled amount of the medicament over time. This amount is administered based on parameters entered into the pump by a clinician using the pump user interface.
[0005] Drug libraries are used with infusion pumps to provide additional configurations beyond the software released by the device manufacturer and already operating on the device. The drug library can be user - configurable, for example, by a pharmacist, and can include drug names, dosages, limits on upper and / or lower bounds of dosing parameters, and other operational configurations or parameters.
[0006] Some drug libraries use a drug - based model in which the entries in the drug library are indexed only by drug name and concentration. Summary of the invention
[0007] According to one aspect, a method for generating a database based on an entity relationship model is provided, including: receiving a drug identifier from a user; storing the drug identifier in a drug entity in the database; receiving from the user drug delivery therapies for a plurality of different therapies; storing each drug delivery therapy for the drug identifier in a therapy entity in the database, where the drug entity and the therapy entity have a one-to-many relationship in the database; generating a drug library based on the drug entity and the therapy entity; and sending the drug library to a medical device for use when programming the medical device to deliver a medicament, the medical device including an infusion pump having a Dose Error Reduction System (DERS) function, wherein the infusion pump includes a control algorithm for preventing errors in programming; recording data of the programmed dose that triggers a dose limit alarm in a log in the infusion pump; using log analysis software to collect warning information from the logs of multiple pumps; and deciding whether a revision of the drug library is needed based on the log analysis.
[0008] According to another aspect, a drug library storage and distribution system is provided, including: a processing circuit and a memory configured to generate and store a drug library database, the drug library database including: a drug entity that specifies a drug name and a drug concentration; and a therapy entity that specifies a clinical protocol for the delivery of the drug, the drug entity and the therapy entity having a one-to-many relationship, both the drug entity and the therapy entity being included in a drug library entity, wherein the processing circuit is configured to distribute the drug library from the drug library entity to an infusion pump having DERS function, wherein the infusion pump includes a control algorithm for preventing errors in programming, a log in the infusion pump that records data of the programmed dose that triggers a dose limit alarm, and log analysis software that collects warning information from the logs of multiple pumps.
[0009] According to another aspect, a drug library editing and distribution system is provided, including: a memory and a processing circuit. The memory is configured to store drug identifiers and a therapy drug library in a database in a first format. The drug library includes drug data, which is to be used by software on a patient device to program the patient device to administer drugs to a patient according to a regimen determined at least in part by a user. The processing circuit is configured to: receive a drug name and concentration programmed by a user; receive a name of a therapy programmed by a user; receive a clinical regimen programmed by a user; generate a drug record based on the drug name and concentration; generate a therapy record separate from the drug record based on the name of the therapy and the clinical regimen, the therapy record being associated with the drug record, wherein the drug record is configured to be associated with a plurality of therapy records, each therapy record having a therapy name and a clinical regimen; generate a drug library file including the drug record and the therapy record; and send the drug library for distribution to one or more infusion pumps having DERS functionality, wherein the infusion pump includes a control algorithm for preventing errors in programming; record data of a programmed dose that triggers a dose limit alert in a log in the infusion pump; use log analysis software to collect warning information from the logs of multiple pumps; and decide whether a revision of the drug library is needed based on the log analysis. BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Figure 1 is a flowchart showing the application background for the systems and methods described herein according to an exemplary embodiment;
[0011] Figure 2 is a flowchart showing the medication management workflow for the systems and methods described herein according to an exemplary embodiment;
[0012] Figure 3 is a flowchart showing the drug library editor workflow for the systems and methods described herein according to an exemplary embodiment;
[0013] Figure 4 is an entity relationship diagram for the systems and methods described herein according to an exemplary embodiment;
[0014] Figure 5 is a flowchart of a method for generating a database based on an entity relationship model according to an exemplary embodiment; and
[0015] Figure 6 is a block diagram of a processing circuit in which one or more components thereof may be used in a computer or other processing component described herein. DETAILED DESCRIPTION
[0016] In some embodiments, a therapy-based model can be used for drug library creation to allow programming of multiple library entries for the same drug.
[0017] In some embodiments, a therapy-based model can be used for drug library creation to avoid unclear drug names that might be used only for drug-based models.
[0018] In some embodiments, the concept of a therapy is used to separate drug names from clinical protocols, such that a single drug can have multiple groups of protocols available for the delivery of the drug in the drug library.
[0019] In some embodiments, the need to program multiple "versions" of the same drug with unclear descriptions is avoided.
[0020] In some embodiments, the one-to-one relationship between drugs and clinical protocols is avoided.
[0021] In one embodiment, a method of generating a database based on an entity relationship model includes: receiving a drug identifier from a user; storing the drug identifier in a drug entity in the database; receiving from the user drug delivery therapies for a plurality of different therapies; storing each drug delivery therapy for the drug identifier in a therapy entity in the database, where the drug entity and the therapy entity have a one-to-many relationship in the database; generating a drug library based on the drug entity and the therapy entity; and sending the drug library to a medical device for use in programming the medical device to deliver a medicament. The database can include a drug library created using a drug library application that enables a pharmacist to create a drug library and / or distribute the created drug library to supported infusion pumps. The medical device can be configured to provide a medical function or service to a patient. The medical device can provide the service by way of an invasive procedure—e.g., by using a needle during the procedure. The medical device can include an infusion pump.
[0022] The drug library can include components of a Dose Error Reduction System or DERS. The DERS can warn a clinician of a possible over-delivery or under-delivery of fluid by checking the programmed dose against a preset limit within the drug library. The limit can be a soft limit or a hard limit.
[0023] In some embodiments, once a change is made to the drug library using the drug library application, a server computer can be used to publish or distribute the drug library to program an infusion pump.
[0024] In some embodiments, the drug library can include a list of drug entities organized by subcategories. The subcategories can include clinical locations, e.g., care areas. The subcategories can be associated with physical locations in a hospital. The subcategories can be named according to therapy types such as epidural therapy.
[0025] In some embodiments, a drug entity includes a drug name and a concentration. The drug entity may include default values for concentration, dosage unit, and / or dosage limits. In some embodiments, the drug entity includes only the drug name and / or concentration and does not include delivery parameters or therapies.
[0026] In some embodiments, a pump having DERS functionality may include a data log file that records data of a programmed dose that triggers a dose limit alert.
[0027] In some embodiments, a drug library storage and distribution system may include an electronic processing circuit and a memory configured to generate and store a drug library database. The drug library database may include drug entities and therapy entities. The drug entities specify drug names and drug concentrations, and the therapy entities specify clinical protocols for the delivery of the drugs. The drug entities have a one-to-many relationship with the therapy entities, and both the drug entities and the therapy entities are included in the drug library entity. The processing circuit may be configured to distribute the drug library from the drug library entity to an infusion pump.
[0028] In some embodiments, a computer running a drug library editor program may be used to facilitate the creation of a drug library through input from a pharmacist on an input device (e.g., keyboard, touch screen, data upload, etc.). The computer may publish the drug library to a medical device. In some embodiments, the computer may be configured to receive approval input from a competent authority via the input device before publishing the drug library to the medical device.
[0029] In some embodiments, each drug library may include definitions of drugs and therapies. The drug library application may be configured to provide a "publish drug library" function. The publish drug library function may be a programmed function that enables a pharmacist to organize a drug library into a profile based on a selected device configuration. This function may provide an option for clinical evaluation and approval by a clinician before distribution to a pump.
[0030] In some embodiments, a distribution drug library may be provided that enables a selected drug library to be distributed to a single pump or a group of pumps via one or more computer networks.
[0031] In some embodiments, the database may include a drug library having an entity relationship model. The model may be a data structure that defines the drug to be infused by name and / or concentration. In some embodiments, the drug to be infused is not defined with reference to a delivery protocol. In some embodiments, the drug name or the identified drug name may be separated from the clinical protocol (e.g., a continuous rate protocol) with respect to the therapy. A single drug may have multiple groups of protocols available for delivery, such as multiple groups of protocols stored in a relational manner within the drug library.
[0032] In some embodiments, a drug library may include a drug entity data structure. The drug entity data structure may include a drug name field and optionally a drug concentration. In some embodiments, the drug entity data structure does not include delivery parameters or protocol data fields. The drug library may define a therapy data structure that includes a therapy name and defines one or more delivery parameters, such as a protocol, rate, bolus, ramp rate, loading dose, etc.
[0033] In some embodiments, a "master" list of drugs is stored, with each drug having a corresponding therapy (linked in a one-to-many manner to the therapies in the therapy entity via one or more pointers or other data constructs), and an individual drug library for a particular clinical area can be constructed according to the corresponding therapy. In some embodiments, more than one therapy can be defined for a single drug within a single drug library.
[0034] In some embodiments, the master drug list entity may include a link to the drug in the drug entity, thus having a one-to-many relationship with the drug entity.
[0035] In some embodiments, all programming modes of a therapy or therapy entity can be delivered through a single channel and can be programmed within a single therapy.
[0036] In some embodiments, a drug library editing and distribution system may include a computer memory and an electronic processing circuit. The memory may be configured to store drug identifiers and a therapy drug library in a database in a first format, the drug library including drug data to be used by software on a patient device to program the patient device to administer a drug to a patient according to a protocol at least partially determined by a user. The processing circuit may be configured to: receive a drug name and concentration programmed by the user; receive a name of a therapy programmed by the user; receive a clinical protocol programmed by the user; generate a drug record based on the drug name and concentration; generate a therapy record separate from the drug record based on the name of the therapy and the clinical protocol. In some embodiments, the therapy record may be associated with the drug record. In some embodiments, the drug record may be configured to be associated with multiple therapy records, each therapy record having a therapy name and a clinical protocol. In some embodiments, the processing circuit may be configured to generate a drug library file including the drug record and the therapy record, and send the drug library for distribution to one or more infusion pumps.
[0037] In some embodiments, drug entries and therapy entries can be created and / or managed separately. In some embodiments, a processing circuit can be configured to receive a drug identifier from a user and store the drug identifier as a drug entity in a database. In some embodiments, the processing circuit can be configured to receive, from the user, drug delivery therapies for a plurality of different therapies and store each drug delivery therapy for the drug identifier as a therapy entity in the database. In some embodiments, a drug entity can have a one-to-many relationship with a therapy entity in the database.
[0038] In some embodiments, any one of a plurality of profiles can be created. A profile can correspond to a care area or the use of a particular medical device within a healthcare facility. In some embodiments, a profile can be associated with a drug library.
[0039] In some embodiments, a dataset or a drug library can be created. The dataset or the drug library can include one or more profiles to be associated with a pump or a pump group or other medical devices.
[0040] In some embodiments, creating a drug entity can include a user specifying a drug name, a drug concentration, a drug class (e.g., analgesic, antiviral, etc.), and the like.
[0041] In some embodiments, creating a therapy can include: first selecting a drug name and then selecting a therapy protocol, parameters, and / or configurations. The parameters can include a dose unit, whether the protocol is fixed or user programmable within a range of values, a default programmed value, a drug concentration, a text message to be displayed on a medical device, whether the drug is configurable with respect to a flow rate or a dose rate (or only the flow rate), and / or other parameters.
[0042] Referring Figure 1 , a Dose Error Reduction System (DERS) can include at least two components. A first component of the DERS is an infusion pump 10, which can include a control algorithm implemented in the pump to prevent errors in dose programming. The DERS allows the infusion pump to warn the user of incorrect medication sequences, calculation errors, or incorrect infusion programming that would result in an underdose or overdose of a drug. The DERS can provide a defense mechanism against pharmacy programming errors. A second component of the DERS is a drug library application 24, which enables a pharmacist 14 to create a drug library and distribute the created drug library to supported infusion pumps 10.
[0043] DERS can be applied to a variety of medical devices or patient devices, e.g., devices configured to provide a medical function or service to a patient (including a blood or organ donor) through an invasive process (e.g., using a needle during a procedure) or otherwise in any clinical, hospital, home care, or other setting. The infusion pump 10 can be any of a variety of infusion pumps, e.g., a large volume infusion pump or a general purpose infusion pump (i.e., an infusion pump configured to dispense from a bag rather than a syringe), a patient controlled analgesia (PCA) pump, an elastomeric pump, an injection pump, an enteral or parenteral feeding pump, an insulin pump, an ambulatory pump, etc. An infusion pump having DERS can be referred to as a "smart" pump.
[0044] DERS can warn a clinician (e.g., a nurse, doctor, etc.) of a possible over-delivery or under-delivery of fluid by comparing a programmed dose (programmed by an end user at the pump) to a preset dose (within a drug library or data set), the preset dose being specific to the drug and / or specific to a clinical application or location or care area (e.g., epidural, neonatal intensive care unit (NICU), medical / surgical unit, etc.). If the programmed dose is outside the limits, the pump will warn the clinician and may require confirmation (soft limit) before starting the delivery or may not allow the delivery at all (hard limit).
[0045] To program, create, or edit a drug library, a user 64 (e.g., a pharmacist, biomedical engineer, etc.) logs into a server computer or a terminal communicating with the server computer (e.g., a pharmacy computer located or set in a pharmacy to be programmed by a pharmacist). The user creates, edits, and / or selects one or more data sets to be programmed into or downloaded to the infusion pump 10 to meet the needs of the end-user workflow in a deployment environment (e.g., a hospital, healthcare facility, clinic, etc.). The data set may include data used by the infusion pump in its operation. For example, the data set may include drug names and / or concentrations, as well as drug programming parameters that provide default values and limitations on the user's ability to program the infusion pump. For example, the data set may include hard and / or soft limitations on different pump programming parameters - such as infusion rate, dose, infusion time or duration, etc. The limitations on the data set may vary for different drugs and may include a "Drug X" data set for drugs unknown to the database. Once changes are made to the data set or database, the new data set created by the pharmacist can be used to publish and distribute the data set using a server computer (e.g., a drug library distribution server, a publishing server, or other server computer) to configure, update, and / or otherwise program the infusion pump 10, and the above configuration, update, and / or programming operations can be done independently, by care area, generically, etc. The user can select the date and time after which the infusion pump will receive the new data set. The patient device can be a clinician-programmable infusion pump.
[0046] Clinical staff (usually nurses, pharmacists, and / or physicians) collaborate to develop a customized drug library for matching the specific care practices of the facility. The library can be created on a dedicated application 24 and then distributed to each pump, and the library can be updated periodically as new drugs or new uses of existing drugs emerge. The drug library may be revised every few months or so to add new drugs and change dosing limitations to better adapt to clinical practice.
[0047] In some embodiments, the drug library is based on the facility's dosing scheme and includes a list of drug entities organized by subcategories identified by the facility. These subcategories may be informally referred to as "clinical locations", or these subcategories may be designated regardless of the facility selection. While the subcategories typically match the care areas (e.g., NICU, medical / surgical, etc.), the subcategories may also be named according to the physical location in the hospital (e.g., West Wing 5) or according to the type of therapy (e.g., epidural). Each drug entity includes the drug name and optionally the concentration, and may also include default values or parameters for the concentration, dosing unit, dosing limit, etc. When the user selects a drug entity from the library, the pump uses the associated default values and additional user input to program the infusion. In this way, a well-designed library helps control dosing errors by reducing the need for manual entry and calculations. In some embodiments, the drug entity includes only the drug name and / or concentration and does not include delivery parameters or therapies.
[0048] A nurse, biomedical engineer, or other user may cycle the power on the pump once they see a notification at the pump 10 that a new drug library has been downloaded to install or activate the new data set. The pump 10 may be configured to confirm via the notification that the data set is available for upgrading or updating the pump. Once the data set is upgraded, the pump 10 may notify the server computer of the upgrade status (e.g., upgrade complete or successful, upgrade failed or error, etc.). Then, for security purposes, the pump 10 may disconnect communication with the server computer. After cycling the power, the nurse is able to perform infusions under the control of the downloaded new data set.
[0049] In some embodiments, a pump with DERS functionality may also include a log that records the data of the programmed doses that trigger dose limit alerts. Clinicians may then use log analysis software to aggregate the warning information from the logs of multiple pumps to look for opportunities to improve clinical practice and to determine if they need to revise the drug library. The data collected according to such log analysis would be useful for performing proactive risk assessments of high-risk procedures. In addition, log analysis enables the facility to examine the results of the changes that have been implemented.
[0050] By reducing programming errors when using DERS in the infusion management process, the use of DERS can improve - without changing - the existing infusion management workflow in a healthcare facility. Refer to Figure 2, a medication management workflow in which the systems and methods described herein can be deployed will be described. At line 21, a physician orders a therapy from a pharmacy within a facility. A pharmacist 14 may fill the therapy order (line 23), and the pharmacy may deliver the therapy to a patient 27 via a clinician (line 25) using a pump 10. A computer that operates a drug library editor or application 24 may be used to facilitate the creation of a drug library by the pharmacist 14, the publication of the drug library (which may include obtaining approval from a regulatory authority), and / or the distribution of the drug library.
[0051] Now referring to Figure 3 , the drug library application 24, which is a component of the DERS, can be used for: (1) creating a drug library; (2) publishing a drug library; and / or (3) distributing a drug library to supported pumps. Additionally, pump installation and pump configuration functions can be provided to simplify the deployment and configuration of the system prior to its first intended use. The drug library application 24 can be configured to provide a "create drug library" function that enables a pharmacist to create, modify, and / or delete a drug library using their definitions of drugs and therapies and other parameters (e.g., patient weight). The drug library application 24 can be configured to provide a "publish drug library" function that enables a pharmacist to organize a drug library into a profile using a selected device configuration and publish the complete profile for clinical evaluation and approval and subsequent distribution to pumps. The drug library application 24 can be configured to provide a "distribute drug library" function that enables a biomedical engineer to distribute a published drug library to selected pumps. A biomedical engineer can distribute a selected drug library to a single pump (line 27) via a direct connection to a serial cable or to multiple pumps (line 29) via a distribution mechanism provided by a server computer.
[0052] Now referring to Figure 4 , systems and methods for generating a database based on an entity relationship model will be described. In some embodiments, the database uses a model that represents a drug to be infused by name and / or concentration (e.g., amoxicillin, etc.), and in some embodiments, the model has no delivery protocol. Some drug-based data models suffer from the fact that the definition or name of a drug corresponds to a clinical protocol in a one-to-one relationship, so such models do not allow the same drug to be used for different sets of clinical protocols. For example, in a typical drug library model, when a drug is defined with the name amoxicillin and a continuous rate protocol, there can only be one way to administer amoxicillin (i.e., using the continuous rate protocol), unless "amoxicillin 1" or "amoxicillin one" is created with a different clinical protocol. This renaming can lead to programming errors if not all users are clear on the drug name distinctions.
[0053] In some embodiments, a therapy-based drug library model can be implemented. In some embodiments, drug names or identifiers can be separated from clinical protocols with respect to the concept of what is called a therapy, such that a single drug (e.g., amoxicillin) can have multiple sets of protocols available for delivery of the drug without creating another drug "version".
[0054] Referring again to Figure 4 , an entity relationship diagram illustrating a therapy-based drug library model according to an exemplary embodiment is shown. An entity relationship model is used to define the data or information structure that can be implemented in a database (e.g., a relational database). Each entity in the database can include multiple records. For example, the drug entity 402 can include multiple drug records, files, or entries within a table of the database. The therapy entity 404 can include multiple therapy records, files, or entries, each therapy data element including a therapy name and defining one or more delivery parameters. Although the embodiments are described with reference to an entity relationship model, other models or techniques can be used to implement the principles and teachings provided herein. In some embodiments, this model can have the following benefits: allowing synchronization of the drug list with a hospital pharmacy system without regard to the specificity of the infusion clinical protocol. As indicated, the drug entity 402 is synchronized with the pharmacy drug entity 410. In this case, the drug entity 402 includes the drug name and optionally the concentration, but does not include the delivery parameters or protocols. In some embodiments, a "master" list of drugs with the corresponding therapies for the drugs (linked in a one-to-many manner by pointers or other data constructs to the therapies in the therapy entity 404) is created, and an individual drug library for a particular clinical area can be constructed according to the corresponding therapies. In some embodiments, more than one therapy can be defined for a single drug within a single drug library.
[0055] The drug library storage and distribution system 400 can include processing circuitry or other computing resources and memory configured to generate and store a drug library database. The drug library database can include a drug entity 402 specifying a drug name and / or drug concentration. The drug library database can include a therapy entity 404 specifying a clinical protocol for delivering the drug. The clinical protocol can include one or more parameters, such as a bolus, continuous rate, ramp rate, loading dose, and / or other protocols.
[0056] As shown, the drug entity 402 and the therapy entity 404 can have a one-to-many or one - to - many relationship. A drug library entity 406 can be generated according to a user's specification, which can include data from the drug entity and / or from the therapy entity. The drug library can then be published, distributed, etc. to selected patient devices.
[0057] In some embodiments, a master drug list entity 408 is provided that includes or contains or is linked to the drugs in the drug entity 402, thereby having a one-to-many relationship with the drug entity 402.
[0058] In some embodiments, the drug library database may further include a pharmacy drug entity 410 that is synchronized with the drug entity 402. The pharmacy drug entity 410 designates data stored in a separate computer (hospital pharmacy computer entity 412) associated with a hospital pharmacy, such that synchronization of the pharmacy drug entity 410 with the drug entity 402 does not modify the therapy entity 404.
[0059] The drug library 406 may include one or more therapies for the drug names and drug concentrations specified in the drug entity, thereby allowing a user of the pump 10 to select a therapy for the drug and / or select a drug by drug name, thereby pulling up the parameters for the drug name.
[0060] In some embodiments, the therapy entity 404 may specify a single therapy that includes a combination of different clinical protocols - for example, protocols to be applied in sequence, at different times, etc.
[0061] In some embodiments, the model may have a one-to-many relationship of drug to therapy. In some embodiments, the therapy does not reference different pump types (e.g., such as, PCA pumps, etc.), but includes a definition of the delivery mode of the drug, including protocols such as continuous rate delivery and / or other parameters.
[0062] In some embodiments, Figure 4 the model may be implemented as an algorithm presented on a tangible medium. The algorithm may present various means for performing the steps shown in the model and / or described herein.
[0063] In some embodiments, the therapy entity may include a combination of different programming modes - for example, bolus dose, push, continuous rate, etc. - associated with a single therapy or therapy data file.
[0064] In some embodiments, all programming modes of the therapy or therapy entity may be delivered through a single channel and may be programmed within a single therapy.
[0065] Now referring to Figure 5, a method for generating a database based on an entity relationship model will be described. At block 500, a drug entry for the drug entity 402 can be created and / or managed. A therapy entry for the therapy entity 404 can also be created and / or managed. For example, the processing circuitry can be configured to receive a drug identifier from a user and store the drug identifier in the drug entity 402 in the database. Additionally, the processing circuitry can be configured to receive from the user a drug delivery therapy for multiple different therapies and store each drug delivery therapy for the drug identifier in the therapy entity 404 in the database. As mentioned, the drug entity 402 has a one-to-many relationship with the therapy entity 404 in the database.
[0066] At block 502, the processing circuitry can be configured to generate a drug library based on the drug entity and the therapy entity by allowing the user to select data from the entities for use in, for example, compiling a drug library to be distributed to a pump according to a distribution policy.
[0067] At block 504, a device configuration can be created and / or managed, such as the total amount of air allowed during a period before an air-in-line alarm in the trigger line, a silence key duration, a keep vein open (KVO) flow rate, or any of a variety of other device configurations.
[0068] At block 506, any of a plurality of profiles can be created and / or managed. For example, a user can enter the name of an operational profile that can correspond to a care area or the use of a particular pump with the profile within a healthcare facility. The profile can also be associated with the drug library from block 500, block 502.
[0069] At block 508, a data set can be created and / or managed. The data set can include one or more validated profiles to be associated with the pump, each profile also including one or more databases.
[0070] At block 410, the processing circuitry can be configured to send the drug library (as part of a data set, a profile, or otherwise) to a medical device for use when programming the medical device to deliver a medicament.
[0071] In some embodiments, the drug that creates the drug entity 402 may include specifying one or more of a drug name, a drug concentration, a drug class of the drug (e.g., pain reliever, antiviral, home care drug, hospital drug, vasopressor, etc.). Drug parameters (e.g., bolus, maximum / minimum limits, default delivery rate, etc.) may also be input, or, in an alternative embodiment, the drug entity 402 may include only the drug name, drug concentration, and / or drug class, where the later-defined therapy incorporates other delivery parameters.
[0072] In some embodiments, creating a therapy may include: first selecting a drug name previously created and optionally stored in the drug entity 402, and then selecting one or more therapy regimens, parameters, or configurations, such as a dose unit, whether the regimen is fixed or within a range (the latter allowing a minimum value, a default value, and a maximum value), a drug concentration, clinical information (e.g., recommendations), whether the drug is configurable with respect to flow rate or dose rate (or only flow rate), whether volume / time infusion is allowed, whether volume / rate infusion is allowed, whether time / rate infusion is allowed, whether the therapy will include a ramp mode (defined by a total volume, a total infusion time, ramp-up and ramp-down times, and / or a plateau flow rate), a continuous flow rate setting, a dose or volume setting over time, a volume to be infused setting, a loading dose setting, a programmed bolus setting, a direct bolus setting, or any other parameter including a constraint group or a delivery protocol on the pump. A clinical protocol may be a protocol for delivering a drug or other agent (or feeding formulation) that includes one or more of the parameters described above.
[0073] Figure 6is a block diagram of a processing circuit component, and one or more of the processing circuit components may be used in a computing device (e.g., a server computer, a pharmacy computer, a patient device, an uploader computer, etc.) described herein. In alternative embodiments, the systems and methods described herein may be implemented on a single server computer, multiple server computers, a server farm, a cloud server environment, or using other computer resources. The server and the patient device 10 may include analog and / or digital circuit components that form a processing circuit configured to perform the steps described herein. The processing circuit may include discrete circuit elements and / or programmed integrated circuits, such as one or more microprocessors, microcontrollers, analog-to-digital converters, application-specific integrated circuits (ASICs), programmable logic, printed circuit boards, and / or other circuit components. The server and the patient device 10 may each include a network interface circuit configured to provide communication between each other and / or with other devices via one or more networks. The network interface circuit in the device may include digital and / or analog circuit components configured to perform network communication functions. These networks may include one or more of a variety of networks, such as wired or wireless networks, wide area networks, local area networks, or personal area networks, proprietary networks, or standards-based networks, etc. These networks may include networks such as: Ethernet networks, networks operating according to the Bluetooth protocol, the IEEE 802.11x protocol, cellular (TDMA, CDMA, GSM) networks, or other network protocols.
[0074] Figure 6 is a block diagram of an example processor platform 800 capable of executing the instructions described herein and / or for implementing the example systems described herein. The processor platform 800 may be, for example, a server, a personal computer, a mobile device (e.g., a cellular phone, a smart phone, a tablet computer such as an iPad TM ), a personal digital assistant (PDA), an Internet appliance, or any other type of computing device.
[0075] The illustrated example of the processor platform 800 includes a processor 812. The illustrated example of the processor 812 is hardware. For example, the processor 812 may be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers from any desired family or manufacturer. In the illustrated example, the processor 812 is configured to be programmed with components for implementing the functions described herein (e.g., components for applying a standard to a software version indicator).
[0076] The processor 812 of the illustrated example includes a local memory 813 (e.g., a cache). The processor 812 of the illustrated example communicates with a main memory including a volatile memory 814 and a non-volatile memory 816 via a bus 818. The volatile memory 814 may be implemented by a synchronous dynamic random access memory (SDRAM), a dynamic random access memory (DRAM), a RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 816 may be implemented by a flash memory and / or any other desired type of memory device. Access to the main memories 814, 816 is controlled by a memory controller.
[0077] The processor platform 800 of the illustrated example also includes an interface circuit 820. The interface circuit 820 may be implemented by any type of interface standard (e.g., the interface standards described above).
[0078] In the illustrated example, one or more input devices 822 are connected to the interface circuit 820. The input devices 822 allow a user to input data and commands into the processor 812. The input devices may be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touch screen, a touchpad, a trackball, and / or a voice recognition system.
[0079] One or more output devices 824 are also connected to the interface circuit 820 of the illustrated example. The output devices 824 may be implemented by, for example, a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touch screen, a tactile output device, a printer, and / or a speaker). Thus, the interface circuit 820 of the illustrated example generally includes a graphics driver card, a graphics driver chip, or a graphics driver processor.
[0080] The interface circuit 820 of the illustrated example also includes a communication device, e.g., a transmitter, a receiver, a transceiver, a modem, and / or a network interface card (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular telephone system, etc.) for facilitating data exchange with an external machine (e.g., any kind of computing device) via a network 826.
[0081] The processor platform 800 of the illustrated example also includes one or more mass storage devices 828 for storing software and / or data. Examples of such mass storage devices 828 include a floppy disk drive, a hard disk drive, a compact disk drive, a Blu-ray disk drive, a RAID system, and a digital versatile disk (DVD) drive.
[0082] Represent Figure 5The flowchart or the encoded instructions 832 of other steps described herein can be stored in the mass storage device 828, volatile memory 814, non-volatile memory 816, and / or on a removable tangible computer-readable storage medium such as a CD or DVD.
[0083] Certain embodiments contemplate methods, systems, and computer program products for implementing the above functions on any tangible machine-readable medium. For example, certain embodiments can be implemented using existing computer processors, or by a dedicated computer processor combined for this or another purpose, or by a hardwired and / or firmware system.
[0084] Some or all of the above-described systems, devices, and / or articles of manufacture, or a portion thereof, can be implemented using instructions, code, and / or other software and / or firmware, etc. stored on a tangible machine-accessible or readable medium and executable by, for example, a processor system. Tangible computer-readable media include memories, DVDs, CDs, etc. that store software and / or firmware, but do not include propagated signals.
[0085] Additionally or alternatively, the example processes described herein can be implemented using encoded instructions (e.g., computer-readable instructions) stored on a non-transitory computer-readable medium - such as, for example, a hard disk drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and / or any other storage medium that stores information for any duration (e.g., for an extended period of time, permanently, briefly for temporary buffering and / or caching of information).
[0086] Some of the method steps can be omitted and / or the steps can be executed in an order different from the listed order in certain embodiments described herein. For example, certain steps may not be performed in some embodiments. As a further example, some steps can be executed in a time order different from the chronological order listed above - including simultaneously.
[0087] Although the exemplary embodiments have been described with reference to infusion pumps, the teachings herein can be applied to other medical devices, such as, for example, blood separation devices (e.g., plasmapheresis, blood treatment, etc.) or other invasive or non-invasive devices that interact with a human patient via a needle in the patient's skin, insulin pumps (e.g., internal or external to the body cavity), medical imaging devices (e.g., CT scanners, X-ray imagers, magnetic resonance imaging). The teachings can also be applied outside the medical field to any computing device, such as, for example, a mobile phone, a tablet computer, or other computers configured to operate when held in a person's hand, a laptop computer, a personal computer, and other networked computers.
[0088] Certain examples facilitate the management of medical devices, including blood collection or blood separation devices, infusion pumps, drug delivery pumps, and / or other medical devices. For example, an infusion pump infuses fluid, medication, or nutrients into a patient. For example, an infusion pump can be used intravenously, subcutaneously, arterially, and / or epidurally. For example, an infusion pump can deliver injections at various rates (e.g., a particularly small injection volume for an intravenous (IV) drip (e.g., 0.1 milliliters per hour), injections per minute, injections with repeated boluses, patient-controlled injections up to a maximum number per hour, or injections of fluid whose amount varies with the time of day, etc.).
[0089] In certain examples, an operator (e.g., a technician, a nurse, etc.) provides inputs to the patient device regarding the type, mode, and / or other device parameters of the infusion, where the protocol defined by a drug library includes a therapy. For example, a continuous infusion provides small infusion pulses (e.g., between 500 nanoliters and 10 milliliters), where the pulse rate is based on the programmed infusion rate. For example, an intermittent infusion alternates between high and low infusion rates using a timing that can be programmed to keep the cannula open. Patient-controlled infusion provides infusions with a pre-programmed upper limit on demand to avoid patient intoxication. For example, the infusion rate is controlled by a pressure pad or button that can be activated by the patient. An infusion pump can include a large-volume pump (e.g., for nutrient delivery to feed a patient), a small-volume pump (e.g., for drug delivery), etc.
[0090] Certain examples determine and / or update a dataset distribution strategy associated with a medical device data management system. If a dataset distribution strategy has been created, new or updated datasets (e.g., a new or updated drug library) can be distributed to one or more medical devices even if one or more of the target medical devices are currently running (e.g., a pump is currently infusing a drug into a patient). Thus, dataset distribution does not affect the activity of the pump.
[0091] In certain examples, a dataset defines a drug library and / or instruction set for a medical device (e.g., a “smart” infusion pump, a blood separation device, etc.). For example, a “smart” infusion pump utilizes a drug library or other dose error reduction software to perform functions that assist healthcare providers in programming and calculating drug doses and delivery rates. A drug library is a database or dataset for storing drug dosing information, e.g., the drug dosing information includes dosing limits, concentrations, infusion parameters, and drug-specific reports. For example, drug library instructions can help reduce or prevent medication errors and associated patient harm.
[0092] The distribution of a dataset to a medical device can occur directly at the device and / or remotely via a network (e.g., from a data management system to multiple medical devices, etc.).
[0093] In some examples, the pharmacy controls the data set and distribution, and does not give decision-making authority to the end user (e.g., nurse, technician, etc.). Instead, the end user must accept the data set to continue using the device. The device management system issues the data set, and the receiving device is configured to activate the new data set at the next restart. For example, the downloaded data set is saved in the download buffer, and once the device is powered on, the device programs the data set into the active memory. Then, the user is notified of the new data set and instructed to use the device or turn it off, but cannot revert to the previous version of the data set.
[0094] Although the embodiments have been described with reference to certain details, those skilled in the art will understand that various changes can be made and equivalents can be substituted without departing from the scope described herein. Additionally, many modifications can be made to adapt a particular situation or material to the teachings without departing from the scope described herein. Therefore, it is intended that the teachings herein not be limited to the particular embodiments disclosed, but include additional embodiments falling within the scope of the appended claims.
[0095] In addition, the present disclosure also provides the following configurations.
[0096] 1. A method for generating a database based on an entity-relationship model, comprising:
[0097] - Receiving a drug identifier from a user;
[0098] - Storing the drug identifier in a drug entity in the database;
[0099] - Receiving drug delivery therapies for a plurality of different therapies from the user;
[0100] Storing each drug delivery therapy for the drug identifier in a therapy entity in the database, where the drug entity and the therapy entity have a one-to-many relationship in the database; generating a drug library based on the drug entity and the therapy entity; and sending the drug library to a medical device for use when programming the medical device to deliver a medicament.
[0101] 2. The method according to configuration 1, wherein each drug therapy includes at least one clinical protocol selected from the group consisting of bolus, continuous rate, ramp rate, and loading dose.
[0102] 3. The method according to configuration 2, wherein the drug identifier includes a drug name and a drug concentration.
[0103] 4. The method according to configuration 1, wherein the drug entity includes a drug name and does not include delivery parameters.
[0104] 5. A drug library storage and distribution system, comprising: a processing circuit and a memory configured to generate and store a drug library database, the drug library database including:
[0105] - Drug entities that specify drug names and drug concentrations; and
[0106] - Therapy entities that specify clinical protocols for the delivery of drugs,
[0107] - There is a one-to-many relationship between the drug entities and the therapy entities,
[0108] - Both the drug entities and the therapy entities are included in a drug library entity,
[0109] wherein the processing circuit is configured to distribute the drug library from the drug library entity to an infusion pump.
[0110] 6. The drug library storage and distribution system according to configuration 5, wherein the drug library database further includes a master drug list entity that has a one-to-many relationship with the drug entities.
[0111] 7. The drug library storage and distribution system according to configuration 5, wherein the drug library database further includes pharmacy drug entities that are synchronized with the drug entities, the pharmacy drug entities specifying data stored in a separate computer associated with a hospital pharmacy, such that the synchronization of the pharmacy drug entities with the drug entities does not modify the therapy entities.
[0112] 8. The drug library storage and distribution system according to configuration 5, wherein the drug library includes multiple therapies for the drug names and drug concentrations specified in the drug entities.
[0113] 9. The drug library storage and distribution system according to configuration 5, wherein the clinical protocols of the therapy entities are selected from the group including bolus, continuous rate, ramp rate, and loading dose.
[0114] 10. The drug library storage and distribution system according to configuration 9, wherein the therapy entities can specify a single therapy including a combination of different clinical protocols.
[0115] 11. A drug library editing and distribution system, comprising: a memory and a processing circuit, the memory being configured to store drug identifiers and a therapy drug library in a database in a first format, the drug library including drug data to be used by software on a patient device to program the patient device to administer drugs to a patient according to a protocol determined at least in part by a user, the processing circuit being configured to:
[0116] - Receive a drug name and concentration programmed by the user;
[0117] - Receive the name of a user-programmed therapy;
[0118] - Receive a user-programmed clinical protocol;
[0119] - Generate a drug record based on the drug name and concentration;
[0120] - Generate a therapy record separate from the drug record and associated with the drug record based on the name of the therapy and the clinical protocol, the therapy record being associated with the drug record, wherein the drug record is configured to be associated with a plurality of therapy records, each therapy record having a therapy name and a clinical protocol;
[0121] Generate a drug library file including the drug record and the therapy record; and send the drug library for distribution to one or more infusion pumps.
[0122] 12. The system according to configuration 11, further comprising an infusion pump, the infusion pump including operating software, the infusion pump being configured to receive the drug library and restrict the operation of the operating software at least in part based on the drug library.
[0123] 13. The system according to configuration 12, wherein the infusion pump is a clinician-programmable infusion pump.
Claims
1. A method for generating a database based on an entity-relationship model, comprising: - Receiving a drug identifier from a user; - Storing the drug identifier in a drug entity in the database; - Receiving from the user a drug delivery therapy for a plurality of different therapies; Storing each drug delivery therapy for the drug identifier in a therapy entity in the database, the drug entity and the therapy entity having a one-to-many relationship in the database; generating a drug library based on the drug entity and the therapy entity; And sending the drug library to a medical device for use when programming the medical device to deliver a medicament, the medical device including an infusion pump having a Dose Error Reduction System (DERS) function, wherein the infusion pump includes a control algorithm for preventing errors in programming; - Recording data of a programmed dose that triggers a dose limit alarm in a log in the infusion pump; - Using log analysis software to collect warning information from logs of multiple pumps; - Deciding whether the drug library needs to be revised based on log analysis.
2. The method according to claim 1, wherein Each drug therapy includes at least one clinical protocol selected from the group consisting of bolus, continuous rate, ramp rate, and loading dose.
3. The method according to claim 2, wherein The drug identifier includes a drug name and a drug concentration.
4. The method according to claim 1, wherein, The drug entity includes a drug name and does not include delivery parameters.
5. A drug library storage and distribution system, comprising: A processing circuit and a memory configured to generate and store a drug library database, the drug library database including: - A drug entity that specifies a drug name and a drug concentration; and - A therapy entity that specifies a clinical protocol for the delivery of a drug, - The drug entity and the therapy entity have a one-to-many relationship, - Both the drug entity and the therapy entity are included in a drug library entity, wherein the processing circuit is configured to distribute the drug library from the drug library entity to an infusion pump having a DERS function, wherein the infusion pump includes a control algorithm for preventing errors in programming, - A log in the infusion pump that records data of a programmed dose that triggers a dose limit alarm, - Log analysis software that collects warning information from logs of multiple pumps.
6. The drug library storage and distribution system according to claim 5, wherein the drug library database further includes a master drug list entity having a one-to-many relationship with the drug entity.
7. The drug library storage and distribution system according to claim 5, wherein the drug library database further includes a pharmacy drug entity synchronized with the drug entity, the pharmacy drug entity specifying data stored in a separate computer associated with a hospital pharmacy, such that synchronization of the pharmacy drug entity with the drug entity does not modify the therapy entity.
8. The drug library storage and distribution system according to claim 5, wherein, The drug library includes multiple therapies for the drug name and the drug concentration specified in the drug entity.
9. The drug library storage and distribution system according to claim 5, wherein, The clinical protocol of the therapy entity is selected from the group consisting of bolus, continuous rate, ramp rate, and loading dose.
10. The drug library storage and distribution system according to claim 9, wherein, The therapy entity may specify a single therapy including a combination of different clinical protocols.
11. A drug library editing and distribution system, comprising: A memory and processing circuitry, the memory being configured to store drug identifiers and a therapy drug library in a database in a first format, the drug library including drug data to be used by software on a patient device to program the patient device to administer drugs to a patient according to a regimen at least partially determined by a user, the processing circuitry being configured to: - Receive a drug name and concentration programmed by a user; - Receive a name of a therapy programmed by a user; - Receive a clinical regimen programmed by a user; - Generate a drug record based on the drug name and concentration; - Generate a therapy record separate from the drug record and associated with the drug record based on the name of the therapy and the clinical regimen, the therapy record being associated with the drug record, wherein the drug record is configured to be associated with multiple therapy records, each therapy record having a therapy name and a clinical regimen; Generate a drug library file including the drug record and the therapy record; and transmit the drug library for distribution to one or more infusion pumps having DERS functionality, wherein the infusion pump includes a control algorithm for preventing errors in programming; - Record data of a programmed dose that triggers a dose limit alert in a log in the infusion pump; - Use log analysis software to collect warning information from logs of multiple pumps; - Decide whether the drug library needs to be revised based on log analysis.
12. The system according to claim 11, further comprising: An infusion pump including operating software, the infusion pump being configured to receive the drug library and restrict the operation of the operating software at least partially based on the drug library.
13. The system according to claim 12, wherein, The infusion pump is a clinician-programmable infusion pump.