Compiler system, method for providing drug library to patient device, and computer system for providing drug library to infusion pump

Abstract

A compiler system, a method for providing a drug library to a patient device, and a computer system for providing a drug library to an infusion pump are disclosed. A compiler system and method for providing a drug library to a patient device includes a memory and processing circuitry. The memory stores a drug library 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 administrate a drug to a patient according to a regimen determined at least in part by a user. The processing circuitry is configured to identify a type of the patient device from pre-stored patient device types and select a compiler program from pre-stored compiler programs. The drug library is converted from the first format to the selected second format using the selected procedure. The converted drug library in the second format is stored, and the converted drug library in the second format is dispensed to the identified type of patient device.

Description

[0001] This application is a divisional application of the patent application for invention with the application date of April 4, 2019, application number 201980031847.7 (international application number PCT / EP2019 / 058492), and invention title "Drug Library Compiler for Patient Devices".

[0002] Cross - reference to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 671,412, filed on May 14, 2018, which is incorporated herein by reference in its entirety. This application is related to U.S. Provisional Patent Application No. 62 / 671,424, filed on May 15, 2018, which is incorporated herein by reference in its entirety. Background Art

[0004] Infusion pumps are commonly used in clinical settings to administer drugs and other pharmaceuticals to patients. The infusion pump provides a controlled amount of the pharmaceutical 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 working 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. Some healthcare facilities may have several different types of patient devices. Drug libraries or other data sets need to be created, published, and distributed to different types of pumps. Sometimes, a new type of patient device is added to a healthcare facility, and a drug library needs to be created, published, and distributed for the new type of patient device. Summary of the Invention

[0006] According to one aspect, there is provided a compiler system for providing a drug library to a patient device, comprising: a memory configured to store a drug library in a first format, the drug library including drug data to be used by software on the patient device to program the patient device to administer a drug to a patient according to a regimen at least partially determined by a user; and processing circuitry disposed within a healthcare facility and configured to: read the drug library; identify the type of the patient device from a plurality of locally pre-stored patient device types, and prompt the user to load a new compiler program if the type of the patient device is not identified among the plurality of locally pre-stored patient device types; receive a new compiler program for the new patient device type and store the new compiler program together with the plurality of locally pre-stored compiler programs; select a compiler program from the plurality of locally pre-stored compiler programs, each locally pre-stored compiler program being configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device; use the selected compiler program to convert the drug library from the first format into the selected second format; store the drug library in the selected second format; and distribute the drug library in the selected second format to the identified type of patient device. The drug library is for an infusion pump to provide additional configurations beyond the software released by the device manufacturer and already working on the device.

[0007] According to another aspect, there is provided a method of providing a drug library to a patient device, comprising: storing a drug library in a first format, the drug library including drug data to be used by software on the patient device to program the patient device to administer a drug to a patient according to a regimen at least partially determined by a user; reading the drug library; identifying the type of the patient device from a plurality of locally pre-stored patient device types, and prompting the user to load a new compiler program if the type of the patient device is not identified among the plurality of locally pre-stored patient device types; receiving a new compiler program for the new patient device type and storing the new compiler program together with the plurality of locally pre-stored compiler programs; selecting a compiler program from the plurality of locally pre-stored compiler programs, each locally pre-stored compiler program being configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device; using the selected compiler program to convert the drug library from the first format into the selected second format within a healthcare facility; storing the drug library in the selected second format; and distributing the drug library in the selected second format to the identified type of patient device.

[0008] According to another aspect, a computer system for providing a drug library to an infusion pump is provided, including: a compiler circuit, including: a memory configured to store a drug library in source code format, the drug library including drug data to be used by software already programmed on the infusion pump to program the infusion pump to administer a drug to a patient according to a regimen determined at least in part by a clinician, wherein the drug library includes hard and soft limits on parameters to be programmed by the clinician; and a processing circuit disposed within a healthcare facility and configured to: identify the type of the infusion pump from a plurality of locally pre-stored infusion pump types, and prompt the clinician to load a new compiler program in the event that the type of the infusion pump is not identified among the plurality of locally pre-stored infusion pump types; receive a new compiler program for the new infusion pump type and store the new compiler program together with the plurality of locally pre-stored compiler programs; select a compiler program from the plurality of locally pre-stored compiler programs, each locally pre-stored compiler program being configured to compile the drug library from source code format into a corresponding machine code format, each machine code format being different for each type of infusion pump; use the selected compiler program to convert the drug library from source code format into the selected machine code format; store the drug library in the selected machine code format; and distribute the drug library in the selected machine code format to a patient device of the identified type; a drug library editor circuit including a first dedicated user interface configured to receive drug library parameters from a pharmacist; and a publishing circuit including a second dedicated user interface configured to publish the converted drug library in a second format to an infusion pump of the identified type. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a functional diagram of a product architecture of a drug library distribution system for a patient device according to an exemplary embodiment;

[0010] Figure 2 is a block diagram of a product architecture of a drug library distribution system for a patient device according to an exemplary embodiment;

[0011] Figure 3 is a block diagram showing components of a drug library distribution system for a patient device according to an exemplary embodiment;

[0012] Figure 4 is a block diagram of an application server according to an exemplary embodiment;

[0013] Figure 5 is a block diagram of a system architecture for a user interface according to an exemplary embodiment;

[0014] Figure 6 is a block diagram of a system architecture for a database according to an exemplary embodiment;

[0015] Figure 7 is a functional diagram showing the system architecture of a drug library distribution system for a patient device with a compiler according to an exemplary embodiment;

[0016] Figure 8 is a block diagram of a processing circuit in which one or more of its components can be used in a computer or other processing component described herein; and

[0017] Figure 9 is a flowchart of a method for compiling a drug library for distribution to an infusion pump according to an exemplary embodiment. Detailed Description

[0018] In some embodiments, a distribution system for a dataset to a patient device is provided, which is flexible and secure.

[0019] In some embodiments, a distribution server can provide the ability to compile the same drug and / or treatment data defined by a pharmacist into drug libraries in different formats for different infusion pumps.

[0020] In some embodiments, virtually the same and common user interface can be used to generate drug libraries for very different pump types and pump families.

[0021] In some embodiments, the systems and methods described herein can simplify the management of deployment environments including various infusion pumps.

[0022] In some embodiments, additional compilers for new types of infusion pumps can be easily added to the distribution system.

[0023] In some embodiments, a compiler system is configured to provide a drug library to a patient device, and the compiler system includes a memory and an electronic processing circuit. The memory can be configured to store a drug library in a first format, which includes drug data that is to be used by software on the 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.

[0024] The processing circuit can be configured to read the drug library, identify the type of the patient device from a plurality of pre-stored patient device types, select a compiler program from a plurality of pre-stored compiler programs, each pre-stored compiler program being configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device. The processing circuit can also be configured to use the selected program to translate the drug library from the first format into the selected second format, store the translated drug library in the second format, and distribute the translated drug library in the second format to the identified type of patient device.

[0025] In some embodiments, the drug library may include programming parameters that provide default values and limitations (hard and / or soft limits) on the user's ability to program the infusion pump. The drug library may include different sets of programming parameters for different drugs. The drug library may include a "Drug X" data set for drugs not known to the database.

[0026] In some embodiments, a drug library may be created in a first workspace, a release process may be completed in a second workspace, and a distribution process may be completed in a third workspace. In some embodiments, each workspace may include a file system where files of interest for common functions are located, whether the file system is on a single computer or across several computers. In some embodiments, each workspace may include defined entry criteria and / or exit criteria for the user, such as user accounts, user credentials, user characteristics, etc. In some embodiments, each workspace may include a corresponding dedicated user interface, database, and / or data rule verification algorithm.

[0027] In some embodiments, a workspace separate from the drug library creation workspace may be configured to compile the database. The workspace for compilation may use a pump-specific or pump type-specific compiler program to compile the drug library.

[0028] In some embodiments, a workspace separate from the compiler workspace or the release workspace may be configured to provide a drug library editor for use by a pharmacist or others to edit multiple drug libraries. The drug library editor may be configured to require user authentication before a person can access the functions of the drug library editor.

[0029] In some embodiments, a release workspace separate from the editor workspace may be configured to release the drug library in a read-only format.

[0030] In some embodiments, an infusion pump in a workspace separate from the release workspace may request infusion pump data from the release workspace. The infusion pump may then receive a data set or an updated infusion pump data set from a server computer in the release workspace. In some embodiments, the infusion pump is configured to require user input, such as by cycling the power on the infusion pump, to install or activate the new data set. In some embodiments, once the installation is complete, the infusion pump may notify the server computer in the release workspace that the new data set has been installed. The infusion pump may be configured to disconnect from the server computer or end the communication session with the server computer after the notification.

[0031] In some embodiments, a drug library user interface can be configured to receive edits to a drug library from a person. The drug library user interface can also receive input for defining a distribution configuration for defining which drug library to publish to which medical device or medical devices and when to publish.

[0032] In some embodiments, each data set can include one or more of parameters, limits, configurations, values, or other data for defining the operation of one infusion pump or multiple infusion pumps. In some embodiments, each data set is not the operating software, but rather a data set used by the operating software to define the functionality of a medical device.

[0033] In some embodiments, a distribution server can be configured to publish a drug library and also publish device configurations such as screen timeout, screen brightness, and other parameters for general use across infusion pumps of different drug libraries.

[0034] In some embodiments, a computer presents a distribution user interface to receive a distribution strategy from a person. The distribution strategy can define which drug libraries, configuration files, etc. to distribute to which infusion pumps and optionally when (e.g., date / time, immediately, etc.) to distribute.

[0035] In some embodiments, a method of providing a drug library to a patient device includes storing a drug library in a first format. The drug library can include drug data that is to be used by software on the 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 method can include: reading the drug library; identifying the type of the patient device from a plurality of pre-stored patient device types; selecting a compiler program from a plurality of pre-stored compilers; and using the selected program to convert the drug library from the first format into a selected second format. Each pre-stored compiler program can be configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device. The method can further include: storing the converted drug library in the second format and distributing the converted drug library in the second format to the identified type of patient device.

[0036] In some embodiments, a processing circuit is configured to convert drug library data input by a person such as a pharmacist into a drug library data format required by a pump. The processing circuit can store pump-specific compiler instances, programs, or data files in a memory to enable generation of drug libraries in different pump formats. In some embodiments, each compiler can be configured to compile a drug library for a specific type of pump or a specific family of pumps (e.g., volumetric pumps, syringe pumps, patient-controlled analgesia pumps, etc.).

[0037] In some embodiments, the linker may include the following execution thread components of an application server: the execution thread components are configured to link selected drug library data to a data set of a target pump type by combining multiple configurations (e.g., care areas such as neonatal intensive care unit or NICU, surgery, ambulatory care, etc.) into a single data set binary file.

[0038] In some embodiments, the compiler may include the following execution thread components: the execution thread components are used to receive drug library parameters from a person via a first dedicated user interface of an application server. The compiler may be configured to verify the drug library data against defined pump drug library rules to compile the drug library data to a target infusion pump. In some embodiments, after compilation, the compiled data set may be distributed or sent to a patient device via a computer network.

[0039] In some embodiments, the memory may be configured to store a drug library in a first format (e.g., source code format). In some embodiments, the drug library may include drug data (e.g., drug name, hard / soft limits on user-programmable dosing parameters, bolus defaults, etc.). In some embodiments, the compiler may be configured to: read the stored drug library from the memory, identify the type of the patient device from multiple pre-stored patient device types, select a compiler program from multiple pre-stored compiler programs, and use the selected compiler program to convert or compile the drug library from the first format to a second format. In some embodiments, the second format may be a lower-level code format than the code format of the first format, e.g., machine code.

[0040] In some embodiments, the type of the patient device may be identified by reading code embedded in a database. In some embodiments, the type of the patient device may be identified by receiving user input data from a user interface. In some embodiments, each second format may be different for different types of patient devices. In some embodiments, each second format may share one or more common features, such as machine code, object code, binary file, etc.

[0041] In some embodiments, the compiler may perform one or more of preprocessing, lexical analysis, parsing, semantic analysis, conversion of the input program to an intermediate representation, code organization, code generation, etc.

[0042] In some embodiments, the compiler is a cross-compiler, a bootstrap compiler, or a source-to-source compiler.

[0043] In some embodiments, a drug library or treatment data file may be defined by a pharmacist via a user interface and compiled into different second formats for different types of infusion pumps. In some embodiments, a compiler may be configured to transform a drug library in source code format into multiple different machine code formats using different patient device type compilers for different corresponding patient device types.

[0044] In some embodiments, a distribution database may be configured to store a compiled data set before distributing the compiled data set in a second format to corresponding patient devices of an associated type.

[0045] In some embodiments, each of the workspaces may include its own dedicated database and / or entry criteria and / or exit criteria for a user.

[0046] In some embodiments, a release workspace may be configured to generate a release report based on the transformed drug library and receive a release authorization via a dedicated user interface. In some embodiments, the release authorization may include a dual signature requiring two people to sign electronically.

[0047] In some embodiments, a compiler may be configured to receive a new compiler program for a new patient device type and store the new compiler program along with multiple pre-stored compiler programs.

[0048] In some embodiments, a computer system provides a drug library to an infusion pump. A compiler circuit may include a portion of an electronic processing circuit for running a compiler algorithm. A memory may store a drug library in source code format that includes drug data to be used by software already programmed on the infusion pump to program the infusion pump to administer a drug to a patient according to a regimen determined at least in part by a clinician. The drug library may include hard limits and soft limits on parameters to be programmed by the clinician. Hard limits may include parameter limits that cannot be overridden by an end user of the medical device, while soft limits may include parameter limits that trigger an alert for the end user but can be overridden by the end user.

[0049] In some embodiments, the processing circuit may be configured to identify the type of infusion pump from a plurality of pre-stored infusion pump types and select a compiler program from a plurality of pre-stored compiler programs based on the identified type of infusion pump. Each pre-stored compiler program may be configured to compile a drug library from source code format into a corresponding machine code format, and each machine code format is different for each type of infusion pump. In some embodiments, the processing circuit may use the selected program to convert the drug library from source code format into a selected machine code format, and store the converted drug library in machine code format and distribute the converted drug library in machine code format to the identified type of patient device.

[0050] Some embodiments may include a drug library editor circuit including a first dedicated user interface, the drug library editor circuit being configured to receive drug library parameters from a pharmacist.

[0051] Some embodiments may include a publishing circuit including a second dedicated user interface, the publishing circuit being configured to publish the converted drug library in a second format to the identified type of infusion pump.

[0052] In some embodiments, if the identified and / or the patient device type read from the drug library is not among the types of patient devices stored in the memory, the user may be prompted to load a new compiler. In some embodiments, a notification for downloading a compiler from a website link may be provided to the user.

[0053] Now referring to Figure 1 , a flowchart of a system for programming a patient device using a data set from a server computer will be described. In this example, the patient device is an infusion pump 10 of a first type 10a or a second type 10b, although in alternative embodiments, the patient device may be any medical device, e.g., any device configured to provide a medical function or service to a patient (including a blood or organ donor) through an invasive procedure (e.g., using a needle during the procedure) or otherwise in any clinical, hospital, home care, or other environment. The infusion pump 10 may be any of a variety of infusion pumps, e.g., a large volume 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, etc. In Figure 1At step 1, a user (e.g., a pharmacist, a 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, a healthcare facility, a clinic, etc.). The data sets may include data used by the infusion pump in its operation. For example, the data set may be a library of drug programming parameters that provides 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 or other user can be published (step 2) and distributed (step 3) using the server computer to configure, update, and / or otherwise program the infusion pump 10. 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 may be a clinician-programmable infusion pump, where the data set includes hard and soft limitations on the parameters to be programmed by the clinician.

[0054] In Figure 1 an exemplary implementation, the architecture separates each of workflow steps 1, 2, and 3 via independently defined data and processing concepts to provide the desired value-added functionality. As graphically indicated by lines 11 and 13, creating the drug library (step 1) can be done in a data workspace separate from the workspace of the publishing process (step 2), and both of these spaces are workspaces separate from the workspace of the distribution process (step 3). A workspace may refer to a file system where files of interest for a common function are located, whether the file system is on a single computer or across several computers. In some implementations, the workspace may also include a dedicated database (and actually may have other dedicated databases on a single computer, a separate computer, a server farm, or in a cloud computing environment where computers share tasks). In some implementations, the workspace may also include defined entry criteria and / or exit criteria for the user, such as user accounts, user credentials, user characteristics, user qualifications, etc. In Figure 1In an embodiment, each of the drug library editor workspace 20, the publishing workspace 30, and the distribution workspace 40 may require dedicated entry criteria and / or exit criteria for a user. Each workspace may also be configured to generate defined output data based on the provided input data. In Figure 1 each of the workspaces or phases of the user workflow described in may be supported by a dedicated user interface, database, and / or data rule verification process to ensure that the deployment of the product drug library to the supported pumps is completed in a secure, effective, and efficient manner.

[0055] In one example, the drug library editor workspace 20 may be configured to generate or receive a drug library created by a pharmacist 22. The workspace 20 may require the pharmacist 22 to enter the required drug information and / or treatment information. The workspace 20 may be configured to generate one or more drug library data structures, which may then be passed to the publishing workspace 30 of the user workflow. In this embodiment, the publishing workspace 30 may be configured to compile the drug library data, for example, using a pump-specific or pump-type-specific compiler program. The distribution workspace 40 may be configured to receive the compiled drug library data and distribute one or more drug libraries to the pumps 10. The distribution may occur directly to a single pump each time using the direct interface 42 (e.g., via a programming computer using a universal serial bus interface, an Ethernet interface, a Wi-Fi interface, a Bluetooth interface, etc.) and / or indirectly and simultaneously to multiple infusion pumps 10 via the distribution mechanism provided by the distribution server 44.

[0056] In some embodiments, the database editor workspace 20 may provide multi-user access to shared data using a master drug library view. In some embodiments, the workspace 20 may be configured to provide a report of offline comments, for example, via printing, saving the data to a memory, and / or sending the data to another computing device. In some embodiments, the workspace 20 may be configured to require user authentication and / or user authorization, which may be completed using a directory service such as an Active Directory domain before a pharmacist or other user can access one or more functions of the workspace.

[0057] In some embodiments, the publishing workspace 20 may provide a publishing process that requires strict rule verification. The publishing workspace may also be enabled by a default dual-user publishing requirement and may also publish data files in a read-only format.

[0058] At step 3, the infusion pump 10 can be configured for wired and / or wireless communication with the server computer 44. Each of the pump 10 and the server computer 20 can include network interface circuitry configured for network communication. The pump 10 is configured to send requests for infusion pump data - such as data sets like a drug library of infusion data - and the server 20 is configured to receive requests for infusion pump data. Infusion pump data requests can be initiated by the infusion pump 10 and can occur periodically, intermittently, occasionally, every few minutes, several times a day, or at other regular or irregular frequencies. The pump 10 can be configured to request whether a newer version of the data set is available for download from the server computer 20 and download the data set. The downloaded data set can be stored in non-volatile memory. The pump 10 can be configured to display a notification (e.g., an icon or other notification) that a new data set has been downloaded and is available for programming.

[0059] A nurse, biomedical engineer, or other user can cycle the power on the pump once the notification is seen to install or activate the new data set. The pump 10 can be configured to confirm via the notification that the data set is available for upgrade or update. Once the data set is upgraded, the pump 10 can notify the server computer 20 of the upgrade status (e.g., upgrade complete or successful, upgrade failed or error, etc.). Then, for security purposes, the pump 10 can disconnect communication with the server computer 20. After cycling the power, the nurse can perform an infusion under the control of the downloaded new data set.

[0060] The server computer 20 can be configured to store the upgrade status received from the pump 10, record transaction timestamps (e.g., the time the pump was upgraded, the time the upgrade confirmation message was received, or other times), and generate distribution report notifications to another user (e.g., a biomedical engineer) on demand or periodically. Reports can be generated in a pre-scheduled manner or on demand based on user input to the system. Reports can also be automatically sent on a scheduled basis without the need for user input, or in response to meeting certain rules (e.g., triggering an alarm, triggering a certain number of alarms, a certain number of overrides or reprogramming events, etc.).

[0061] The dedicated database 46 stores the compiled data sets in a secure manner using network security protection, a firewall, or other protection for security-related data. Data integrity measures can also be employed at the database 46. Additionally, as described above, the database 46 can be set up in a workspace separate from the workspaces 30 and 20 for additional security and integrity.

[0062] Now referring to Figure 2 , a block diagram of the product architecture of a drug library distribution system for a patient device will be described. Figure 2including functional components that implement the features described above with reference to Figure 1 The block diagram shows a user interface, a database, application programs / utilities, and an interface to an external system / device. Each component of the architecture can be implemented by one or more computing devices. As in Figure 1 , the pharmacist 22 uses the drug library user interface 24 to edit the drug library and display the release configuration and release report for pharmacist review. The release configuration can be shared between the controller 32 (e.g., as part of the release workspace 30) and the drug library user interface 24. The release report can be provided to other external devices, such as a printer 26. An error log can be generated by any component of the system shown and stored in the error log memory 50.

[0063] The compiled drug library can be published to the distribution server 46 for transfer to the pump 10 via the direct pump interface 42 or via the server computer 44.

[0064] The distributed data set can include parameters, limits, configurations, values, or other data to be used by the software 60 on the patient device 10 to perform patient-related functions (e.g., treatment, blood component collection, etc.). In some embodiments, the data set is not operating software, but is used by the operating software on the pump 10 to determine the options that the user may have for programming the patient device 10. As mentioned, the data set can include a drug library having drug names and hard and / or soft limits on the drugs to be infused, the limits being determined by the pharmacist. In some embodiments, the data set can be configured by an end user such as a pharmacist, while the software is not user-configurable and can only be configured by the manufacturer of the patient device 10 or the server.

[0065] The biomedical engineer 64 can use the dedicated device configuration user interface 60 to configure the device using drug-independent parameters (e.g., screen timeout, screen brightness, etc.). The device configuration 62 can be published to the database 46 for distribution to one or more pumps according to a distribution strategy. The biomedical engineer 64 can also use the distribution user interface 68 to define the distribution strategy 66 and share the distribution strategy with the database 46 to guide the distribution of the data set to the patient device. Notably, in this embodiment, neither the device configuration data nor the distribution strategy needs to be controlled by the controller 32, however, in an alternative embodiment, release functions such as compilation can also be applied to these data elements. The distribution status can be reported back from the database 46 to the biomedical engineer 64 using the distribution user interface 68.

[0066] The database 46 can provide the release report 70 to the drug library user interface 24 to report the status of the data set to be released to the pharmacist or other users.

[0067] Now referring toFigure 3 , a block diagram of components in a data distribution system will be described. One or more of the components of the data distribution system may include executable computer instructions presented on a tangible medium (e.g., compact disk, digital versatile disk, memory, or other medium). An installer program 300 is provided to install the data distribution system on a computer serving a healthcare facility. A user interface 302 is provided that requests the user's login credentials and facilitates the input and display of data for other users. A commercially available database management system 304 is provided that communicates with the computer operating the data distribution system for hosting one or more data stores required by the data distribution system. A commercially available web server 306 may be provided, and the web server 306 may be configured to host one or more system user interfaces generated by the data distribution system.

[0068] The data distribution system implementation on the memory includes a user interface component 308 that generates and maintains one or more of the user interfaces described herein. Reference will be made to Figure 4 The application server component 310 will be described in more detail. The data storage component 312 may be configured to operate a database, memory, or other data storage requirements of the data distribution system that can be implemented using the DBMS 304.

[0069] Now referring to Figure 4 , a block diagram of an application server architecture will be described. The application server 310 may include a drug library compiler 400, a drug library linker 402, a distribution manager 404, a synchronization manager 406, and a log manager 408. The drug library compiler 400 may work with specific compiler versions 410, 412 for each of a plurality of supported pumps. The drug library linker 402 may include a pump-specific linker 414 for a specific type of pump. Some types of pumps will not have a drug library linker. The distribution manager 404 may include an interface 416 for the pump and an interface 418 for a separate distribution server that distributes data sets to the pump. The synchronization manager 406 may include a hospital pharmacy system pharmacy interface 420. The log manager may manage the recording of data from one or more components of the system.

[0070] Now referring to Figure 5, a block diagram depicting the architecture of the user interface system will be described. The user interface 500 may include multiple separate dedicated interfaces, and each interface may have its own login credentials, access criteria, and / or exit criteria, user lists, user criteria, etc. The drug library editor 502 allows pharmacists or other qualified users to create and edit the drug library. The policy editor 504 allows pharmacists or other qualified users to generate distribution policies for a healthcare facility or medical clinic. The distribution policy may specify where and / or how to distribute the data from the data file (e.g., distribute to all pumps at all locations, distribute to pumps at a specific location, distribute to a specific pump, etc.). The synchronization editor 506 provides synchronization of the data between the data distribution system and the pharmacy interface. Each of the editors 502, 504, 506, 508 can be accessed via the user interface 308 and / or the network server 306. An editor refers to any program capable of editing a file, e.g., a text file editor. For the purpose of viewing the data log files retrieved from any of the components described herein, the log manager 408 can also be accessed by the user interface 308.

[0071] Figure 6 is a block diagram of the data storage model system architecture according to one embodiment. In this embodiment, the data storage 312 includes three databases: the drug library database 600, the system data database 602, and the log data database 604. The drug library data database 600 may include three main data schemas: the drug library edit data 606, the drug library release data 608, and the drug library distribution data 610. The DBMS 304 ( Figure 3 ) is deployed and managed by the drug library administrator. In some embodiments, the system will need to install the DBMS 304 before the installer 300 deploys the drug library distribution system.

[0072] Now referring to Figure 7 , a functional diagram of the system architecture for a drug library distribution system including a compiler will be described. The compiler 732 may be presented as a programming processing circuit configured to perform certain functions. The processing circuit 732 is a component of the ODL and requires the ODL to provide the function of converting the drug library data input by the pharmacist into the drug library data format required by the supported pumps. The processing circuit 732 may include pump-specific compiler instances to enable the generation of drug libraries in different pump formats. Compilers can be developed to support specific pump types and / or pump families, e.g., volumetric pumps, PCA pumps, etc. The drug library editor 24 ( Figure 2 ) may be a user interface component for providing an editing function for the common drug library data to the pharmacist. The drug library linker 402 ( Figure 4) can be a component for linking a published drug library into a pump-supported format. The linker 402 can include the following execution thread component of an application server: the execution thread component is configured to link selected drug library data to a dataset of a target pump type by combining multiple configurations (e.g., care areas such as neonatal intensive care unit or NICU, surgery, ambulatory care, etc.) into a single dataset binary file.

[0073] In some embodiments, the compiler processing circuit 732 can be the following execution thread component of the application server 310( Figure 3 ) : the execution thread component is configured to verify drug library data against defined pump drug library rules to compile the drug library data to a target infusion pump. One or more datasets (e.g., drug libraries) 700 can be distributed to one or more patient devices (e.g., infusion pumps) 10. The memory 720 can be configured to store a drug library in a first format (e.g., source code format). The drug library 700 can include drug data (e.g., drug name, hard limits / soft limits on user-programmable dosing parameters, etc.), and the drug data is to be used by software on the patient device 10 to program the patient device 10 to administer drugs to a patient according to a regimen determined at least in part by the user. For example, a user can program an infusion pump to deliver amoxicillin according to a regimen including a set rate and time, where the parameters of the regimen are restricted by the drug library. The memory 720 can include a database that can be different from other databases of the system (e.g., the distribution database 746). The databases 720, 746, etc. can be configured as relational databases or other databases.

[0074] The processing circuit 732 can be configured to read the drug library 700 from the memory 720 or otherwise receive the drug library 700. The processing circuit 732 can be configured to identify the type of the patient device from among multiple pre-stored patient device types. The pre-stored patient device types can be stored locally in the processing circuit 732 or in a memory otherwise accessible to the processing circuit 732. The type of the patient device can be any one of a variety of types, e.g., syringe pump type, volumetric pump type, PCA pump type, a specific model of one of these pump types, or other pump types. The type of the patient device can be identified in a variety of ways, e.g., by reading a part of the database 700 or a code embedded in the database 700, by receiving the type of the patient device from one of the user interfaces described herein, etc.

[0075] The processing circuit can be configured to select a compiler program from a plurality of pre-stored compiler programs 710, 712, and use the selected program to convert the drug library from a first format to a selected second format. Each pump type can have a different corresponding and / or associated compiler program, e.g., pump version 1.0 compiler 710, pump version 2.0 compiler 720, etc. Each pre-stored compiler program 710, 712, etc. can be configured to compile the drug library 700 from the first format into a corresponding second format, and each second format is different for each type of patient device. For example, the drug library 700 can be in source code format, and compilers 710, 712 can convert the source code format into a lower-level code format, e.g., a machine code format compatible with pump version 1.0 and a second machine code format compatible with pump version 2.0, respectively. Note that although the second format is different for each pump, they can still share common characteristics, such as common characteristics as machine code, object code, binary files, etc. In some embodiments, the first format can include source code format, and the second converted format can include assembly code format. In addition to compilers, other conversions can also be envisioned. The compiler can perform one or more of preprocessing, lexical analysis, parsing, semantic analysis, conversion of the input program to an intermediate representation, code optimization, code generation, etc. The compiler can also include any type of compiler, e.g., cross-compiler, bootstrap compiler, source-to-source compiler, etc.

[0076] In some embodiments, the same drug and / or treatment data defined by a pharmacist can be compiled into different formats of drug libraries for different infusion pumps. One advantage of this structure is that it enables the product to retain an essentially identical and common user interface to produce drug libraries for very different pump types and pump families, thus simplifying the management of deployment environments including various infusion pumps. The processing circuit 732 can be configured to use different patient device type compilers for different corresponding patient device types to convert the drug library in source code format into a plurality of different machine code formats.

[0077] The processing circuit 732 can be configured to store the converted drug library in the second format, and the converted drug library in the second format can be stored in the distribution database 746. The distribution database 746 can be configured to distribute the drug library in the second format to patient devices of the identified type.

[0078] Can be utilized Figure 7 The drug library distribution system shown to implement different workspaces as described with reference to Figure 1 For example, including the first dedicated user interface 24( Figure 2 ) or 502( Figure 5) The drug library editor workspace 721 can be configured to receive drug library parameters 700 from a pharmacist 22 ( Figure 1 ) The release workspace 740, including a second dedicated user interface 68 ( Figure 2 ) or 504 ( Figure 5 ), can be configured to distribute the transformed drug library in a second format to the patient device 10. Additionally, the drug library creation workspace 721 can include a first dedicated database 720 and first defined entry criteria and exit criteria for the user, such as login credentials, authorization checks, user authentication, etc. Similarly, the release workspace 740 can include a second dedicated database 746 and second defined entry criteria and exit criteria for the user.

[0079] In some embodiments, the release workspace 740 can be configured to generate a release report based on the transformed drug library and receive a signing authorization from the user via the second dedicated user interface. The signing authorization can be a dual-signature (i.e., two people must electronically sign) for the security of critical tasks before the data set is released to the pump 10. Requiring a dual-signature can enhance the security of the system at critical stages of the data set distribution process. In another embodiment, the release workspace 740 is configured to store the transformed drug library and the transformed drug library with the release authorization in a read-only format. Once the data is stored in the release database 746, releasing the data in a read-only format can prevent cyberattacks and other improper interventions on the data set.

[0080] In some embodiments, the processing circuit 732 can be configured to receive a new compiler program for a new patient device type (e.g., a new pump product release, a new version, a new pump type, etc.) and store the new compiler program together with a plurality of pre-stored compiler programs. The new compiler for the new pump type can be added to the system at will, thus simplifying the first rollout of the new pump.

[0081] Now referring to Figure 9 , a method for providing a drug library to a patient device will be described. At block 900, the method includes storing a drug library in a first format. The drug library can include drug data that is to be used by software on the patient device to program the patient device to administer drugs to the patient according to a regimen determined at least in part by the user. At block 902, the drug library is read and the type of the patient device is identified from a plurality of pre-stored patient device types 904. If the identified and / or read patient device type from the drug library is not among the types of the patient device (block 906), then at block 908, the user can be prompted to load a new compiler. Other notifications can be provided, such as a message to contact the manufacturer of the identified pump type to obtain the compiler, a link to the website to download the compiler, etc.

[0082] At block 910, if the device type is recognized, a compiler program is selected from a plurality of pre-stored compiler programs (912). Each pre-stored compiler program is configured to compile a drug library from a first format into a corresponding second format, with each second format differing for each type of patient device. The compiler program can be a one-to-one compiler program that converts a file from the first format to the second format. At block 914, the drug library is compiled or converted using the compiler program. At block 916, the converted drug library is stored and distributed to the pump, for example, according to a predetermined distribution strategy generated by a pharmacist or others.

[0083] An optional additional step 920 is shown. After block 914, at block 918, a release report can be generated and provided to a computer, terminal, or other user interface for approval by appropriate clinical staff. At block 920, the method attempts to obtain a first signature from the clinical staff, which can be done by way of an electronic signature or other indication of approval from an appropriately qualified person. At block 922, a second signature is sought from a second clinical staff member. At block 924, if both signatures are not obtained, the process exits at block 926 without distributing the drug library. If both signatures are obtained, the process proceeds to block 916 for distribution.

[0084] Figure 8is a block diagram of a processing circuit component, and one or more of the processing circuit components can 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 can be implemented on a single server computer, multiple server computers, a server farm, a cloud server environment, or using other computer resources. Server 20 and patient device 10 can include analog and / or digital circuit components that form a processing circuit configured to perform the steps described herein. The processing circuit can 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. Server 20 and patient device 10 can 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 can include digital and / or analog circuit components configured to perform network communication functions. These networks can 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 can 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.

[0085] Figure 8 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. Processor platform 800 can 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.

[0086] The illustrated example of processor platform 800 includes a processor 812. The illustrated example of processor 812 is hardware. For example, processor 812 can be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers of any desired family or manufacturer. In the illustrated example, processor 812 is configured to be programmed with components for implementing the functions described herein (e.g., components for applying a criterion to a software version indicator).

[0087] 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.

[0088] 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).

[0089] In the illustrated example, one or more input devices 822 are connected to the interface circuit 820. The input device 822 allows a user to input data and commands into the processor 812. The input device 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.

[0090] One or more output devices 824 are also connected to the interface circuit 820 of the illustrated example. The output device 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 haptic 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.

[0091] 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.

[0092] 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.

[0093] Represent Figure 9The flowchart or the encoding instructions 832 of other steps described herein can be stored in the mass storage device 828, the volatile memory 814, the non-volatile memory 816, and / or on a removable tangible computer-readable storage medium such as a CD or DVD.

[0094] 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.

[0095] Some or all of the above-described systems, devices, and / or articles of manufacture components, or a portion of the above, 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.

[0096] Additionally or alternatively, the example processing described herein can be implemented using encoded instructions (e.g., computer-readable instructions) stored on a non-transitory computer-readable medium - for example, a hard disk drive, flash memory, read-only memory, compact disc, digital versatile disc, 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 use in temporary buffering and / or for caching of information).

[0097] Some of the method steps can be omitted and / or the steps can be performed 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, certain steps can be performed in a time order different from the chronological order listed above - including being performed simultaneously.

[0098] Although the exemplary embodiments have been described with reference to an infusion pump, the teachings herein can be applied to other medical devices, 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, for example, a mobile phone, a tablet computer, or other computers configured to work while held in a person's hand, a laptop computer, a personal computer, and other networked computers.

[0099] 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 a liquid, drug, or nutrient into a patient. For example, an infusion pump can be used intravenously, subcutaneously, arterially, and / or epidurally. For example, an infusion pump can deliver an injection at various rates (e.g., a particularly small injection volume (e.g., 0.1 milliliters per hour) for an intravenous (IV) drip, an injection per minute, an injection with a repeated bolus, a patient-controlled injection up to a maximum number per hour, or an injection of a liquid whose amount varies with the time of day, etc.).

[0100] In certain examples, an operator (e.g., a technician, a nurse, etc.) provides an input to the patient device regarding the type, mode, and / or other device parameters of the infusion. 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 a high infusion rate and a low infusion rate using a timing that can be programmed to keep the cannula open. A patient-controlled infusion provides an infusion 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.

[0101] 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, a new or updated dataset (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 in operation (e.g., a pump is currently infusing a drug into a patient). Thus, the dataset distribution does not affect the activity of the pump.

[0102] In certain examples, a dataset defines a drug library and / or an 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 similar 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.

[0103] The distribution of the dataset to the 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.).

[0104] In some examples, a pharmacy controls the data set and distribution, and does not give decision-making authority to end users (e.g., nurses, technicians, 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.

[0105] 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 are not limited to the particular embodiments disclosed, but include additional embodiments falling within the scope of the appended claims.

[0106] Furthermore, the present disclosure also provides the following configuration.

[0107] 1. A compiler system for providing a drug library to a patient device, comprising: a memory configured to store a drug library in a first format, the drug library including drug data to be used by software on the patient device to program the patient device to administer drugs to a patient according to a regimen at least partially determined by a user; and

[0108] processing circuitry configured to:

[0109] - read the drug library;

[0110] - identify the type of the patient device from a plurality of pre-stored patient device types;

[0111] select a compiler program from a plurality of pre-stored compiler programs, each pre-stored compiler program being configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device;

[0112] - use the selected program to convert the drug library from the first format into the selected second format;

[0113] - store the converted drug library in the second format; and

[0114] - distribute the converted drug library in the second format to the identified type of patient device.

[0115] 2. The compiler system according to Configuration 1, wherein the first format is a source code format, and the selected second format is a lower-level code format than the source code format.

[0116] 3. The compiler system according to Configuration 1, wherein the identified type of patient device is an infusion pump selected from the group including syringe infusion pumps and volumetric infusion pumps.

[0117] 4. The compiler system according to Configuration 1, further comprising:

[0118] A drug library editor workspace including a first dedicated user interface, the drug library editor workspace being configured to receive drug library parameters from a pharmacist; and

[0119] A publishing workspace including a second dedicated user interface, the publishing workspace being configured to publish the transformed drug library in the second format to the patient device.

[0120] 5. The compiler system according to Configuration 4, wherein the drug library creation workspace includes a first dedicated database and first defined entry criteria and exit criteria for the user, and wherein the publishing workspace includes a second dedicated database and second defined entry criteria and exit criteria for the user.

[0121] 6. The compiler system according to Configuration 5, wherein the publishing workspace is configured to generate a publishing report based on the transformed drug library and receive a signing authorization from the user via the second dedicated user interface.

[0122] 7. The compiler system according to Configuration 6, wherein the publishing workspace is configured to store the authorized transformed drug library and publish the authorized transformed drug library in a read-only format.

[0123] 8. The compiler system according to Configuration 1, wherein the processing circuit is configured to use different patient device type compilers for different corresponding patient device types to transform the drug library in the first format into multiple different second formats.

[0124] 9. The compiler system according to Configuration 1, further comprising: a linker configured to link multiple drug libraries to a binary data set for the identified type of patient device.

[0125] 10. The compiler system according to Configuration 1, wherein the processing circuit is configured to receive a new compiler program for a new patient device type and store the new compiler program together with the multiple pre-stored compiler programs.

[0126] 11. The compiler system according to Configuration 1, wherein the patient device is a clinician-programmable infusion pump, and wherein the drug library includes hard limits and soft limits on parameters to be programmed by the clinician.

[0127] 12. A method for providing a drug library to a patient device, comprising: storing a drug library in a first format, the drug library including drug data to be used by software on the patient device to program the patient device to administer a drug to a patient according to a regimen at least partially determined by a user; reading the drug library; identifying the type of patient device from a plurality of pre-stored patient device types; selecting a compiler program from a plurality of pre-stored compiler programs, each pre-stored compiler program being configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device; using the selected program to convert the drug library from the first format into the selected second format; storing the converted drug library in the second format; and distributing the converted drug library in the second format to patient devices of the identified type.

[0128] 13. The method according to Configuration 12, wherein the first format is a source code format and the selected second format is a machine code format.

[0129] 14. The method according to Configuration 12, further comprising:

[0130] receiving drug library parameters from a pharmacist via a first dedicated user interface of a drug library editor; and publishing the converted drug library in the second format to the patient device via a second dedicated user interface.

[0131] 15. The method according to Configuration 14, further comprising: generating a release report based on the converted drug library using the second dedicated interface and receiving a signing authorization from the user.

[0132] 16. The method according to Configuration 15, further comprising: storing the authorized converted drug library and publishing the authorized converted drug library in read-only format.

[0133] 17. The method according to Configuration 12, further comprising: converting the drug library in the first format into a plurality of different second formats using different patient device type compilers for different corresponding patient device types.

[0134] 18. The method according to Configuration 12, further comprising: linking a plurality of drug libraries to a binary data set for patient devices of the identified type.

[0135] 19. The method according to configuration 12 further includes: receiving a new compiler program for a new patient device type and storing the new compiler program together with the plurality of pre-stored compiler programs, wherein the patient device is a clinician-programmable infusion pump, and wherein the data set includes hard limits and soft limits on parameters to be programmed by the clinician.

[0136] 20. A computer system for providing a drug library to an infusion pump, comprising:

[0137] A compiler circuit, comprising:

[0138] A memory configured to store a drug library in source code format, the drug library including drug data to be used by software already programmed on the infusion pump to program the infusion pump to administer a drug to a patient according to a regimen determined at least in part by a clinician, wherein the drug library includes hard limits and soft limits on parameters to be programmed by the clinician; and

[0139] A processing circuit configured to:

[0140] Identify the type of the infusion pump from a plurality of pre-stored infusion pump types; select a compiler program from a plurality of pre-stored compiler programs, each pre-stored compiler program being configured to compile the drug library from the source code format into a corresponding machine code format, each machine code format being different for each type of infusion pump;

[0141] Use the selected program to convert the drug library from the source code format into a selected machine code format;

[0142] Store the converted drug library in the machine code format; and

[0143] Distribute the converted drug library in the machine code format to patient devices of the identified type;

[0144] A drug library editor circuit including a first dedicated user interface, the drug library editor circuit being configured to receive drug library parameters from a pharmacist; and

[0145] A publishing circuit including a second dedicated user interface, the publishing circuit being configured to publish the converted drug library in a second format to infusion pumps of the identified type.

Claims

1. A compiler system for providing a drug library to a patient device, comprising: A memory configured to store a drug library in a first format, the drug library including drug data to be used by software on the 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; and Processing circuitry disposed within a healthcare facility and configured to: Read the drug library; Identify the type of the patient device from a plurality of locally pre-stored patient device types, and prompt the user to load a new compiler program if the type of the patient device is not identified among the plurality of locally pre-stored patient device types; Receive the new compiler program for the new patient device type and store the new compiler program together with a plurality of locally pre-stored compiler programs; Select a compiler program from the plurality of locally pre-stored compiler programs, each locally pre-stored compiler program being configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device; Use the selected compiler program to convert the drug library from the first format into a selected second format; Store the drug library in the selected second format; And Distribute the drug library in the selected second format to the identified type of patient device.

2. The compiler system according to claim 1, wherein The first format is a source code format, and the selected second format is a lower-level code format than the source code format.

3. The compiler system according to claim 1, wherein The identified type of patient device is an infusion pump selected from the group including syringe infusion pumps and volumetric infusion pumps.

4. The compiler system according to claim 1, further comprising: A drug library editor workspace including a first dedicated user interface configured to receive drug library parameters from a pharmacist; And A publishing workspace including a second dedicated user interface configured to publish the drug library in the selected second format to the patient device.

5. The compiler system according to claim 4, wherein, The drug library editor workspace includes a first dedicated database and first defined entry and exit criteria for a user, wherein the publishing workspace includes a second dedicated database and second defined entry and exit criteria for a user.

6. The compiler system according to claim 5, wherein, The publishing workspace is configured to generate a release report based on the drug library in the selected second format and receive a signing authorization from the user via the second dedicated user interface.

7. The compiler system according to claim 6, wherein, The publishing workspace is configured to store the drug library in the selected second format and, if a signing authorization is received, publish the drug library in the selected second format in a read-only format.

8. The compiler system according to claim 1, wherein, The processing circuitry is configured to convert the drug library in the first format into a plurality of different second formats using different patient device type compiler programs for different corresponding patient device types.

9. The compiler system according to claim 1 further comprises: A linker configured to link a plurality of drug libraries to a binary data set for the identified type of patient device.

10. The compiler system according to claim 1, wherein, The patient device is a clinician-programmable infusion pump, wherein the drug library includes hard limits and soft limits on parameters to be programmed by the clinician.

11. A method for providing a drug library to a patient device, comprising: Storing a drug library in a first format, the drug library including drug data to be used by software on the patient device to program the patient device to administer a drug to a patient according to a regimen determined at least in part by a user; Reading the drug library; Identifying the type of the patient device from a plurality of locally pre-stored patient device types, and prompting the user to load a new compiler program if the type of the patient device is not identified among the plurality of locally pre-stored patient device types; Receiving the new compiler program for the new patient device type and storing the new compiler program together with a plurality of locally pre-stored compiler programs; Selecting a compiler program from the plurality of locally pre-stored compiler programs, each locally pre-stored compiler program being configured to compile the drug library from the first format into a corresponding second format, each second format being different for each type of patient device; Using the selected compiler program within a healthcare facility to convert the drug library from the first format into a selected second format; Storing the drug library in the selected second format; And Distributing the drug library in the selected second format to patient devices of the identified type.

12. The method according to claim 11, wherein, The first format is a source code format, and the selected second format is a machine code format.

13. The method according to claim 11, further comprising: Receiving drug library parameters from a pharmacist via a first dedicated user interface of a drug library editor; And Releasing the drug library in the selected second format to the patient device via a second dedicated user interface.

14. The method according to claim 13, further comprising: Using the second dedicated interface to generate a release report based on the drug library in the selected second format and receiving a signing authorization from the user.

15. The method according to claim 14 further comprises: Storing the drug library in the selected second format, and if a signing authorization is received from the user, releasing the drug library in the selected second format in read-only format.

16. The method according to claim 11 further comprises: Using different patient device type compiler programs for different corresponding patient device types to convert the drug library in the first format into a plurality of different second formats.

17. The method according to claim 11, further comprising: Linking a plurality of drug libraries to a binary data set for the identified type of patient device.

18. The method according to claim 11, wherein The patient device is a clinician-programmable infusion pump, wherein the data set includes hard limits and soft limits on parameters to be programmed by the clinician.

19. A computer system for providing a drug library to an infusion pump, comprising: A compiler circuit, comprising: A memory configured to store a drug library in source code format, the drug library including drug data to be used by software already programmed on the infusion pump to program the infusion pump to administer a drug to a patient according to a regimen determined at least in part by a clinician, wherein the drug library includes hard limits and soft limits on parameters to be programmed by the clinician; and A processing circuit, which is disposed within a healthcare facility and is configured to: Identify the type of an infusion pump from a plurality of locally pre-stored infusion pump types, and In the case where the type of the infusion pump is not identified among the plurality of locally pre-stored infusion pump types, prompt the clinician to load a new compiler program; Receive the new compiler program for the new infusion pump type and store the new compiler program together with a plurality of locally pre-stored compiler programs; Select a compiler program from the plurality of locally pre-stored compiler programs, each locally pre-stored compiler program being configured to compile the drug library from the source code format into a corresponding machine code format, each machine code format being different for each type of infusion pump; Convert the drug library from the source code format into a selected machine code format using the selected compiler program; Store the drug library in the selected machine code format; and Distribute the drug library in the selected machine code format to the patient devices of the identified type; A drug library editor circuit, including a first dedicated user interface, which is configured to receive drug library parameters from a pharmacist; and A publishing circuit, including a second dedicated user interface, which is configured to publish the converted drug library in the second format to the infusion pumps of the identified type.

Images