Distribution server for patient devices

Abstract

A distribution server and method for downloading a data set to a patient device is disclosed. The server has a network interface circuit, a memory, and a processing circuit. The memory receives a data set, the data set having parameters to be used by software on the patient device to perform a patient-related function. The data set has a software version indicator of the data set. The processing circuit compares the software version indicator of the data set to a current software version of the patient device and determines that there is an inequality. Based on the determination, the server distributes the data set to the patient device.

Description

Background Technology

[0001] Infusion pumps are commonly used in clinical settings to administer medications and other agents to patients. The infusion pump delivers a controlled dose of medication to the patient over time. This dose is based on parameters input into the pump by the clinician using the pump's user interface.

[0002] Drug libraries are used in infusion pumps to provide configurations beyond those released by the device manufacturer. Drug libraries can be user-configurable, such as by a pharmacist, and can include drug names, dosages, and upper and / or lower limits for dosing parameters. When a manufacturer releases new software and programs that new software into the infusion pump, an updated drug library is generated to ensure compatibility with the new software. Frequent software releases—even minor ones—result in unintended additional work for those programming the drug libraries. Attached Figure Description

[0003] Figure 1 This is a flowchart of a system and method for programming a dataset from a server computer into an infusion pump, according to an exemplary embodiment;

[0004] Figure 2 This is a block diagram of a distribution server, pharmacy computer, and patient device for downloading datasets according to an exemplary embodiment;

[0005] Figure 3 This illustrates a standard set of tables for determining whether to distribute a dataset to a patient device, according to an exemplary embodiment.

[0006] Figure 4 This is an illustration of a first scenario for determining whether to distribute a dataset to a patient device, according to an exemplary embodiment.

[0007] Figure 5 This is an illustration of a second scenario for determining whether to distribute a dataset to a patient device, according to an exemplary embodiment.

[0008] Figure 6 It is a table of software version indicators for the first functional code according to an exemplary implementation;

[0009] Figure 7 It is a table of software version indicators for second function code according to an exemplary implementation;

[0010] Figure 8 It is a block diagram of a processing circuit whose one or more components may be used in a computer or other processing unit described herein; and

[0011] Figure 9This is a flowchart of a method for determining whether to distribute a dataset to a pump, according to an exemplary embodiment. Detailed Implementation

[0012] In some implementations, a data set distribution system to patient devices is provided, which is flexible for different configuration environments.

[0013] In some implementations, the distribution server provides automatic redistribution of new datasets due to patient devices in response to upgrades / downgrades in the configuration of new datasets.

[0014] In some implementations, the distribution system allows for the wider distribution of appropriate datasets based on specific parameters of the patient device (e.g., type and software function code) without updating the dataset (a collection of dataset files) and according to a distribution strategy (a combination of pump location and datasets).

[0015] In some implementations, pharmacists’ workload can be greatly reduced by allowing the dataset to be considered pump-compatible when only minor software revisions are used to update the software on the pump.

[0016] In some implementations, the deployment of the dose error reduction system and pump can be accomplished independently due to the flexibility to allow datasets with minor incompatibilities to still be used during software upgrades.

[0017] In some implementations, a virtual machine manager can be implemented for new software features without interfering with the pumps implemented in the field, and vice versa.

[0018] Now refer to Figure 1 This document describes a flowchart of a system for programming a patient device using a dataset from a server computer. In this example, the patient device is infusion pump 10, although in alternative embodiments, the patient device can be any medical device, such as any device configured to provide medical functions or services to a patient (including blood or organ donors) via invasive procedures (e.g., using a needle) or otherwise in any clinical, hospital, home care, or other setting. Infusion pump 10 can be any of a variety of infusion pumps, such as a high-volume infusion pump, a patient-controlled analgesia (PCA) pump, an elastomeric pump, an injection pump, an enteral or parenteral feeding pump, an insulin pump, etc. Figure 1At step 1, a user (e.g., a pharmacist, biomedical engineer, etc.) logs into server computer 20 or a terminal communicating with server computer 20 (e.g., a pharmacy computer located in or set up in a pharmacy to be programmed by a pharmacist). The user selects one or more datasets to be programmed into infusion pump 10 or downloaded to infusion pump 10. The datasets may include data used by the infusion pump in its operation. For example, the dataset may be a library of drug programming parameters that provide default values ​​and limitations for the user's ability to program the infusion pump. For example, the dataset may include hard and / or soft limits for different pump programming parameters—e.g., infusion rate, dose, infusion time, or duration. The limitations of the dataset may vary for different drugs and may include a "Drug X" dataset for drugs unknown to the database. Once the datasets or database have been changed, the infusion pump 10 can be remotely downloaded, updated, or otherwise programmed using server 20 (e.g., by care area, general, etc.) using the new datasets created by the pharmacist or other user. The user can select the date and time on which the infusion pump will receive the new datasets thereafter. The patient device can be a clinician-programmable infusion pump, wherein the dataset includes hard and soft constraints on the parameters to be programmed by the clinician.

[0019] exist Figure 1 At step 2, the infusion pump 10 can be configured to communicate wirelessly with the server computer 20 via wired and / or wireless communication. Each of the pump 10 and the server computer 20 may include network interface circuitry configured for network communication. The pump 10 is configured to send requests for infusion pump data—e.g., datasets, such as 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 dataset is available for download from the server computer 20 and download the dataset. The downloaded dataset can be stored in non-volatile memory. The pump 10 can be configured to display a programmable notification (e.g., an icon or other notification) that a new dataset has been downloaded.

[0020] exist Figure 1At step 3, the nurse, biomedical engineer, or other user can cycle the power to the pump upon seeing the notification to install or activate the new dataset. Pump 10 can be configured to confirm via notification that the dataset is available for upgrade or update. At step 4, the user can command the pump to upgrade the dataset. Once the dataset has been upgraded, pump 10 can notify server computer 20 of the upgrade status (e.g., upgrade complete or successful, upgrade failed or error, etc.). Then, for security purposes, pump 10 can disconnect from server computer 20. After power-on, the nurse is able to perform infusions under the control of the downloaded new dataset.

[0021] In step 5, server computer 20 is configured to store upgrade status received from pump 10, record transaction timestamps (e.g., the time the pump was upgraded, the time an 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 sent automatically on a scheduled basis without user input, or automatically in response to the fulfillment of certain rules (e.g., triggering an alarm, triggering a certain number of alarms, a certain number of override or reprogramming events, etc.).

[0022] Now refer to Figure 2 The following describes a distribution server 20 for downloading datasets to patient devices. Server 20 may include network interface circuitry 22 configured to communicate with one or more patient devices 10 via network 12 and / or with memory 24. Network interface circuitry 22 may include one or more individual interface circuits configured to communicate via simple or complex networks—e.g., peer-to-peer networks, serial communication lines, Ethernet, the Internet, local area networks, personal area networks, Wi-Fi networks, Bluetooth networks, or other communication links. Memory 24 may be configured to receive datasets from pharmacy computer 30 via the network interface circuitry. Pharmacy computer 30 may include a computer, server, terminal, or other computing device configured to receive user input from pharmacists or other healthcare professionals regarding data in the dataset. Depending on the distribution strategy, pharmacy computer 30 may be used to generate various datasets for different hospitals, clinics, floors, nursing areas, etc.

[0023] The dataset (shown as distributed at dataset 40) may include parameters, limitations, 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, dataset 40 is not the operating software, but rather is used by the operating software 60 to determine the options a user may have for programming the patient device 10. As mentioned, dataset 40 may include a drug library with drug names and hard / soft limitations on the drugs to be infused, which are determined by a pharmacist. In some embodiments, dataset 40 may be configured by an end user such as a pharmacist, while the software 60 is not user-configurable, but rather configurable only by the manufacturer or server of the patient device 10. In some embodiments, changes to the software 60 must be compiled into machine code, and changes to dataset 40 may be stored in a documented format.

[0024] Data set 40 may include a software version indicator 42. The software version indicator 42 may include metadata or other data indicating the version of software 60 to which data set 40 is designed to operate. The software version indicator 42 may indicate compatibility between data set 40 and one or more specific versions of software 60. (See reference...) Figures 3 to 7 In the exemplary embodiment described, the software version indicator 42 may include one or more codes, hexadecimal values, or other data.

[0025] In some embodiments, server computer 20 includes processing circuitry configured to receive a dataset having a software version indicator 42 from pharmacy computer 30 and store the dataset in memory 24. Server computer 20 is also configured to receive the current software version (which may also be an indicator, code, metadata, or other form of data) for software 60 on patient device 10. Server computer 20 may be configured to compare the software version indicator of the dataset with the current software version of the patient device and determine if there is an inequality between the software version indicator of the dataset and the current software version of the patient device. For example, server computer 20 may determine whether the current software version of the pump is numerically greater than or equal to the software version indicator of the dataset. If the current software version of the pump is numerically greater than or equal to the software version indicator of the dataset, server computer 20 may be configured to distribute the dataset to the patient device based on the inequality determination. Other inequalities may be used, such as less than or equal to, not equal to, greater than, less than, etc. In some embodiments, a newer software version will have a higher software version number.

[0026] In some implementations, server computer 20 determines that a dataset can operate with the software if its software version indicator is less than or equal to the current software version of the software active or working on patient device 10, and therefore the dataset can be distributed (e.g., downloaded and / or programmed, activated, etc.) to the patient device. Conversely, if the dataset's software version indicator is greater than the current software version on patient device 10, server computer 20 determines that the dataset cannot operate with the software, and therefore the dataset is not distributed.

[0027] Reference Figure 3 This will help you better understand the description. Figure 3 This is a table showing a set of standards used to determine whether to distribute a dataset to a patient device. Server computer 20 can be configured or programmed to apply one or more of these standards (e.g., equality, inequality, or other standards) to the data. Each time a software version is created, a version number or code is given by the person generating the program. In this implementation, the code can include five parts: type, major DFV, minor DFV, major CFV, and minor CFV. Type refers to the type of pump the software is designed for, such as an infusion pump, a bag infusion pump, a patient-controlled analgesia pump, a specific model of these pumps, etc. Major refers to a major or significant software revision, such as one that affects the compatibility of the pump with a particular set of pump configuration data and / or datasets. If a programmer updates the software and changes (e.g., adds) the major code, it indicates that the old dataset cannot be applied to the pump (i.e., the parameters listed in the dataset are not applicable, and the pump will not be able to operate using those parameters). A major change could be a change that introduces new features to the pump. Minor refers to less significant software revisions (e.g., bug fixes, less important parameters such as screen brightness, etc.). If a programmer updates the software and changes minor code but not major code, it indicates that the old dataset is still compatible with the pump. Minor and major code can be modified numerically, for example, M=1, m=1; M=1, m=2; M=1, m=3; M=2, m=1; M=2, m=2...

[0028] In some implementations, changes to the major software version code may indicate updates to pump controls or pump mechanics that could lead to the introduction of new or major data structure updates or redesigns. In some implementations, changes to the minor software version code indicate updates to pump functions and / or pump parameters that are independent of the dataset, and / or retain changes to data structures that are related to the dataset.

[0029] DFV refers to the Drug Library Format Version, and CFV refers to the Care Area Format Version. These codes can be programmed by human programmers to indicate different versions of software code that run different functions on the patient device. In this way, DFV and CFV are predefined parameters for each software version. DFV and CFV can be embedded in the software configured on the pump. DFV and CFV can be automatically determined based on predefined values, pump type, and software. In one example, the first part of the software (identified as the DFV part) can be updated to a new version, while the second part of the software (identified as the CFV part) can remain unchanged. In this case, the DFV codes (major and / or minor) will increase or otherwise change, while the CFV codes (major and minor) will remain unchanged. The software version indicator for the dataset and the current software version for the patient device may each include a first set of function codes associated with the software that runs a first set of functions on the patient device (e.g., functions related to the storage, updating, and user interface of the dataset or drug library) and a second set of function codes associated with the software that runs a second set of functions on the patient device (e.g., functions related to the selection and configuration of the patient device for work based on which care area is selected for the device, such as intensive care, primary care, surgery, etc.).

[0030] The first criterion 300 compares the pump type of the pump with the pump type identifier of the dataset. If the pump type and pump type identifier are numerically equal or otherwise equivalent, the criterion is satisfied. In this implementation, the dataset is distributed if all criteria in the table are met; however, in alternative implementations, one or more of these or other criteria are used via AND, OR, or other logical linkages to determine when to distribute the dataset.

[0031] Criterion 302 compares the pump's primary DFV with the primary DFV of the newly created or updated dataset. If they are equal, the criterion is met. Criterion 304 compares the pump's secondary DFV with the secondary DFV of the newly created or updated dataset. If the pump's secondary DFV is greater than or equal to the dataset's secondary DFV, the criterion is met. Criterion 306 compares the pump's primary CFV with the primary CFV of the newly created or updated dataset. If they are equal, the criterion is met. Criterion 308 compares the pump's secondary CFV with the secondary CFV of the newly created or updated dataset. If the pump's secondary CFV is greater than or equal to the dataset's secondary CFV, the criterion is met. In this example, when all criteria are met, server 20 determines that the dataset should be distributed to the pump. In some implementations, the dataset is distributed to the patient device based on the determination that both the first function code (e.g., primary DFV) and the second function code (e.g., primary CFV) are unequal. Each of the primary DFV, secondary DFV, primary CFV, and secondary CFV can be a software version indicator or part of the current software version, and each can be considered as code within the software version code.

[0032] Now refer to Figure 4 This section describes the first scenario for determining whether to distribute a dataset to a patient device. In this example, to select an appropriate dataset based on a distribution strategy, server computer 20 compares the following parameters: pump type, major version of the first function code (e.g., major DFV), and major version of the second function code (e.g., major CFV). If these parameters are equal on both sides (pump and dataset), server computer 20 checks their respective minor versions of the first and second function codes. If the first and / or second function codes are equal, or if the pump minor code is greater than the dataset minor code (maximum value), server computer 20 sets a new target dataset for the pump.

[0033] Refer again Figure 4This example illustrates a dataset with the following software version indicator, which has five parts: DFV=32, CFV=13, and Type=3, representing a new target dataset of two identical pump types with different software versions. Pump 1 has software versions of DFV=32, CFV=13, and Type=3, while pump 2 has software versions of DFV=33, CFV=15, and Type=3. In this scenario, the values ​​of Type, Major DFV, Minor DFV, Major CFV, and Minor CFV match the corresponding dataset values, therefore server computer 20 determines to distribute the dataset to pump 1. Pump 2 has Type and Major DFV and Major CFV values ​​that are equal to or match the dataset's Type and Major DFV and Major CFV values, but pump's Minor DFV (=3) is greater than the dataset's Minor DFV (=2). Additionally, pump 2's Minor CFV (=5) is greater than the dataset's Minor CFV (=3). Since both pumps satisfy... Figure 3 The distribution criteria stated in the text are used to instruct server computer 20 to distribute the dataset to both pump 1 and pump 2.

[0034] Now refer to Figure 5 The following describes a second scenario involving determining whether to distribute the dataset to the patient's device. As in the first example, in order to select the appropriate dataset based on the distribution strategy, the server computer 20 again uses... Figure 3 The standard. The second case shows that memory 24 has multiple datasets—dataset ID 1 and dataset ID 2. Dataset ID 1 has a major DFV code of 3, a minor DFV code of 2, a major CFV code of 1, a minor CFV code of 3, and a type of 3. Dataset ID 2 has a major DFV code of 4, a minor DFV code of 2, a major CFV code of 2, a minor CFV code of 3, and a type of 3. Pump ID 1 has a major DFV code of 3, a minor DFV code of 2, a major CFV code of 1, a minor CFV code of 3, and a type of 3. As indicated by line 72, pump ID 1 will receive the dataset because all codes match / are equal. Pump ID 1 will not receive dataset ID 2 because the major DFV codes and major CFV codes, 4 and 2 respectively, do not match the major DFV codes and major CFV codes (3 and 1 respectively) of pump ID 1.

[0035] Figure 5Another aspect of this disclosure is shown at online location 74. In some embodiments, due to pump configuration upgrades / downgrades or other changes (e.g., via software updates), the system allows for the automatic redistribution of new datasets, such as dataset ID 2. Server computer 20 can be configured to receive an indication that patient device ID 1 has an updated software version. Server 20 can be configured to compare the updated software version with multiple datasets in memory, each dataset having a different software version indicator, for example, dataset ID 1 with a software version indicator including 3 2 1 3 3 and dataset ID 2 with a software version indicator including 4 2 2 3 3. Server computer 20 can be configured to determine at least one dataset having a software version indicator (which may be part of the numerical string shown) that is numerically less than or equal to the updated software version. In this case, the dataset minor DFV is 2, which is less than or equal to the updated pump DFV 3; the dataset minor CFV is 3, which is less than or equal to the updated pump minor CFV of 4. Therefore, server computer 20 determines that it is now ready to distribute dataset ID 2 to the upgraded pump ID 1. Automation can be applied to one or more of the following steps: receiving instructions for an updated software version; comparing the updated software version with multiple datasets; applying criteria, such as... Figure 3 The criteria in the data set; determining the dataset to be distributed; and distributing the dataset. These one or more steps can be automated by being performed automatically by the patient device and / or server computer 20 without manual user input (e.g., via a user interface to one or more computers with which it communicates).

[0036] Now refer to Figure 6 and Figure 7 An example DFV code is shown. Figure 6 ) and CFV code ( Figure 7 Table 600 illustrates patient device types 602, such as different types of infusion pumps (e.g., syringe pumps or SPs, volumetric bag pumps or VPs, total intravenous anesthesia (TIVA) pumps, patient-controlled analgesia (PCA) pumps, etc.). Each pump type may be associated with a different software version 604, such as version 1.3, 1.4, 2.2c, 2.3ROW, etc. In some embodiments described herein, software version 604 may be used as a software version indicator and may be in standard (e.g., Figure 3 The software version indicator is used in the standard shown. In other embodiments, the software version indicator may take the form of format version code 606. In this embodiment, code 606 includes four characters, for example, 0, 2, 6 and □, where the last character represents a null character before \r\n when the command returns. Figure 6 and / or Figure 7 Any one or more of the characters, codes, or indicators shown may be used in the standards described herein. Figure 6 and Figure 7 The format version code includes the first two digits 608 and the last two digits 610. The first two digits 608 indicate or indicate a major software release, and the last two digits 610 indicate or indicate a minor software release.

[0037] In some implementations, two datasets sharing the same first digit will be compatible. If the two digits used for the primary release match, the dataset uploader computer will distribute the dataset to the pump even if the two digits used for the secondary release do not match. In some implementations, compatibility means that the pump can only receive datasets with a lower and / or equal minor version, but not datasets with a higher minor version.

[0038] In some implementations, the following algorithm can be used to program the server computer 20 as a standard for the application software version to determine whether the dataset should be distributed to the pump system, method, or apparatus.

[0039] If dataset_pump_type == pump_type

[0040] And dataset_cfv_major==pump_cfv_major

[0041] Furthermore, (dataset_cfv_minor == pump_cfv_minor or dataset_cfv_minor is close to the inferior value of pump_cfv_minor)

[0042] And dataset_dfv_major == pump_dfv_major

[0043] Furthermore, (dataset_dfv_minor == pump_dfv_minor or dataset_dfv_minor is close to the inferior value of pump_dfv_minor)

[0044] Then the dataset needs to be distributed to the pump.

[0045] In one example, when a Dose Error Reduction System (DERS) product (e.g., a pharmacy computer, server computer 20, or other computer) wants to create a dataset (e.g., a drug library) compatible with a specific pump, the dataset can include data from... Figure 6 and Figure 7The DFV / CFV code pair corresponding to the target pump is selected from the table. In this way, all codes within the software version indicator will be equal. When the dataset uploader product or an uploader component as part of the product needs to distribute a dataset file suitable for a patient device, the uploader product reads the DFV / CFV pair in the data file itself and sends the dataset file to one or more target pumps based on the read DFV / CFV pair. The server computer 20 can also use the DFV / CFV pair to add the pump to the server computer's memory (e.g., register the pump with the server computer 20). The server computer 20 reads the DFV / CFV pair and reads the pump ID and / or generates a pump ID to store in memory. In another example, when new software is released for a specific pump type, the programmer writes or selects a new DFV / CFV pair and adds the new DFV / CFV pair to the... Figure 6 and Figure 7 The new DFV / CFV pairs can be stored in memory 24 and / or connected to network 12 ( Figure 2 (In other computers that communicate.)

[0046] Now refer to Figure 9 This section describes a method for determining whether a dataset should be distributed to a patient device. At box 900, the distribution server's memory is configured to receive the dataset via network interface circuitry. This dataset includes parameters to be used by software on the patient device to perform patient-related functions. The dataset may include a software version indicator as part of a dataset file. The memory may also be configured to receive the current software version of the patient device.

[0047] At box 902, the server computer and / or patient device can be configured to determine when it is time for a dataset update. In some examples, the initial installation of the dataset occurs when the location (e.g., hospital, clinic, doctor's office, etc.) has not previously used the patient device and / or associated drug library / dataset. After installation, updates can occur periodically and / or irregularly (e.g., weekly updates, monthly updates, updates on triggers and / or when needed, etc.). For example, updates may occur more frequently at locations where a particular dataset has never been used before; updates may occur less frequently if the location has used previous versions of datasets from the same or different vendors and is aware of the dataset's settings, preferences, etc.

[0048] If the server computer and / or patient device determine that it is time to update the dataset on the patient device, the server computer (box 904) is configured to compare the software version indicator of the dataset with the current software version of the patient device. As described herein, the comparison may be against one or more portions of the software version indicator, such as major and / or minor software change indicators, codes for one or more different portions of the software controlling different functions, codes for expressions such as "Revision 1.1, Revision 1.2, etc.", numerical codes (13, 23, etc.), or other codes or data. Furthermore, any number of different criteria may be applied at step 904, such as equality, inequality, numerical relationships, non-numerical relationships, or other criteria.

[0049] At branch 905, the server computer determines, based on the comparison in box 904, not to distribute the dataset to the patient device. In this case, processing proceeds to box 908 (with optional additional processing between boxes 905 and 908). At box 908, the server computer determines whether the pump software has been updated to now meet the criteria in box 904. The server computer can be configured to receive an indication that the patient device has an updated software version, which can be conveyed by the patient device in response to a query from the server computer or otherwise, in ad hoc communication to the server. Without receiving manual user input, the server computer 20 automatically compares the software version indicator of the dataset with the updated software version by returning to box 904. In this case, based on the comparison with the updated software version, it determines (e.g.) Figure 5 In scenario 2 described above, line 74) requires the dataset to be distributed to the patient device. At box 906, the server computer distributes the dataset to the patient device based on the determination that it needs to be distributed to the patient device.

[0050] As shown in box 904, after branch 909, if there is a discrepancy between the software version indicator of the dataset and the updated software version, the processing circuitry of server computer 20 determines to distribute the dataset to the patient device.

[0051] In some implementations, the memory is configured to store multiple datasets, each with a corresponding software version indicator, and the processing circuitry is configured to identify at least two datasets compatible with the patient device. In this case, the processing circuitry is configured to distribute one of the two datasets that has a larger software version indicator (or a more recent software release date) compared to the other dataset.

[0052] In various embodiments, the dataset also includes a device type indicating the type of patient device, wherein the software version indicator of the dataset and the updated software version of the patient device each include a first software version code and a second software version code. The dataset is distributed to the patient device based on the determination that the first software version codes are equal and the second software version codes are unequal.

[0053] Figure 8 This is a block diagram of processing circuit components, one or more of which can be used in computing devices described herein (e.g., server computers, pharmacy computers, patient devices, uploader computers, etc.). In alternative implementations, 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 computing resources. Server 20 and patient device 10 may include analog and / or digital circuit components forming processing circuitry configured to perform the steps described herein. The processing circuitry may include discrete circuit elements and / or programmable 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 may each include network interface circuitry configured to provide communication with each other and / or with other devices via one or more networks. The network interface circuitry may 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 (WANs), local area networks (LANs) or personal area networks (PANs), private networks (PLANs), or standards-based networks. These networks can include networks such as Ethernet networks, networks operating according to Bluetooth, IEEE 802.11x, cellular (TDMA, CDMA, GSM) networks, or other network protocols.

[0054] Figure 8 This is a block diagram of an example processor platform 800 capable of executing the instructions described herein and / or used to implement 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 smartphone, or a tablet computer such as an iPad). TM Personal digital assistants (PDAs), internet applications, or any other type of computing device.

[0055] The processor platform 800 shown in the example includes a processor 812. The processor 812 in the example shown 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 example shown, the processor 812 is configured with components programmed to implement the functions described herein (e.g., components applying standards to software version indicators).

[0056] The processor 812 of the illustrated example includes local memory 813 (e.g., cache). The processor 812 of the illustrated example communicates via bus 818 with main memory, which includes volatile memory 814 and non-volatile memory 816. Volatile memory 814 may be implemented using synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. Non-volatile memory 816 may be implemented using flash memory and / or any other desired type of memory device. Access to main memory 814, 816 is controlled by a memory controller.

[0057] The processor platform 800 shown in the example also includes interface circuitry 820. Interface circuitry 820 can be implemented using any type of interface standard (e.g., the interface standard described above).

[0058] In the example shown, one or more input devices 822 are connected to interface circuitry 820. Input devices 822 allow users to input data and commands into processor 812. Input devices can be implemented, for example, audio sensors, microphones, cameras (still or video), keyboards, buttons, mice, touchscreens, touchpads, trackballs, and / or voice recognition systems.

[0059] One or more output devices 824 are also connected to the interface circuitry 820 of the illustrated example. The output devices 824 may be implemented, for example, by display devices (e.g., light-emitting diodes (LEDs), organic light-emitting diodes (OLEDs), liquid crystal displays, cathode ray tube displays (CRTs), touchscreens, haptic output devices, printers, and / or speakers). Therefore, the interface circuitry 820 of the illustrated example typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

[0060] The interface circuit 820 shown in the example also includes communication devices, such as a transmitter, receiver, transceiver, modem, and / or a network interface card (e.g., Ethernet connection, digital subscriber line (DSL), telephone line, coaxial cable, cellular telephone system, etc.) for facilitating data exchange with external machines (e.g., any kind of computing device) via network 826.

[0061] The processor platform 800 shown in the example also includes one or more mass storage devices 828 for storing software and / or data. Examples of such mass storage devices 828 include floppy disk drives, hard disk drives, compact disk drives, Blu-ray disc drives, RAID systems, and digital multifunction disc (DVD) drives.

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

[0063] Some embodiments are conceived of methods, systems, and computer program products for implementing the above-described functions on any tangible machine-readable medium. For example, some embodiments may be implemented using existing computer processors, or by dedicated computer processors combined for this or another purpose, or by hardwired and / or firmware systems.

[0064] Articles containing some or all, or a portion thereof, of the aforementioned systems, devices, and / or manufactured components may be implemented using instructions, code, and / or other software and / or firmware stored on tangible machine-accessible or readable media and executable by, for example, a processor system. Tangible computer-readable media include memory storing software and / or firmware, DVDs, CDs, etc., but do not include transmission signals.

[0065] Alternatively or alternatively, the example processing described herein may be implemented using coded instructions (e.g., computer-readable instructions) stored on a non-transitory computer-readable medium—such as a hard disk drive, flash memory, read-only memory, compact disk, digital multifunction disk, cache, random access memory, and / or any other storage medium in which information is stored for any duration (e.g., extended time periods, permanent, brief instances, for temporary buffering and / or caching of information).

[0066] Some embodiments described herein may omit one or more method steps and / or perform the steps in a different order than listed. For example, in some embodiments, certain steps may not be performed. As a further example, certain steps may be performed in a different chronological order than listed above—including simultaneous execution.

[0067] Although exemplary embodiments have been described with reference to infusion pumps, the teachings herein can be applied to other medical devices, such as blood separation devices (e.g., plasma separation, blood therapy, etc.) or other invasive or non-invasive devices that interact with a human patient via needles through the patient's skin, insulin pumps (e.g., intracavitary or external), and 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 mobile phones, tablet computers, or other computers configured to operate while held in a person's hand, laptop computers, personal computers, and other networked computers.

[0068] Certain examples facilitate the administration of medical devices, including blood collection or separation devices, infusion pumps, drug delivery pumps, and / or other medical devices. For example, an infusion pump delivers fluids, medications, or nutrients into a patient. Infusion pumps can be used intravenously, subcutaneously, in arterially, and / or epidurally, for example. Infusion pumps can deliver injections at various rates (e.g., particularly small injection volumes for intravenous (IV) infusions (e.g., 0.1 ml per hour), injections per minute, injections with repeated boluses, patient-controlled injections reaching a maximum hourly volume, or injections of fluids whose volume varies throughout the day, etc.).

[0069] In some examples, an operator (e.g., a technician, nurse, etc.) provides input to the patient device regarding the type, mode, and / or other device parameters of the infusion. For example, continuous infusion provides small infusion pulses (e.g., between 500 nanoliters and 10 milliliters), where the pulse rate is based on a programmed infusion rate. Intermittent infusion, for example, utilizes a timing mechanism that can be programmed to keep the cannula open, alternating between high and low infusion rates. Patient-controlled infusion provides an infusion on demand with a pre-programmed upper limit to prevent patient toxicity. For example, the infusion rate can be controlled via a pressure pad or button that can be activated by the patient. Infusion pumps can include high-volume pumps (e.g., for feeding patients with nutrient solutions), low-volume pumps (e.g., for drug delivery), etc.

[0070] Some examples identify and / or update data with medical device data management systems (e.g., Fenwald by Fresenius Kabi). TM Fenwal DXT manufactured TM A dataset distribution strategy associated with a data management system. If a dataset distribution strategy has been created, new or updated datasets (e.g., new or updated drug libraries) can be distributed to one or more medical devices even if one or more of the target medical devices are currently operating (e.g., a pump is currently infusing drugs into a patient). Therefore, dataset distribution does not affect pump activity.

[0071] In some examples, a dataset defines a drug library and / or instruction set for medical devices such as “smart” infusion pumps, blood separators, etc. For instance, 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 dosages and delivery rates. A drug library is a database or dataset used to store drug dosing information, such as 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.

[0072] The distribution of datasets to medical devices can occur directly at the device and / or remotely via a network (e.g., from a data management system to multiple medical devices).

[0073] In some examples, the pharmacy controls the dataset and its distribution, and instead of giving decision-making authority to end users (e.g., nurses, technicians, etc.), the end users must accept the dataset to continue using the device. The device management system issues the dataset, and the receiving device is configured to activate the new dataset upon the next restart. For example, downloaded datasets are stored in a download buffer, and once the device is powered on, it programs the dataset into active memory. The user is then notified of the new dataset and instructed to use or shut down the device, but it is not possible to revert to a previous version of the dataset.

[0074] Although embodiments have been described with reference to certain details, those skilled in the art will understand that various changes and substitutions can be made without departing from the scope described herein. Furthermore, many modifications can be made to adapt particular situations or materials to the teachings without departing from the scope described herein. Therefore, the teachings herein are intended to be limited to the specific embodiments disclosed, but to include other embodiments falling within the scope of the appended claims.

Claims

1. A distribution server for downloading datasets to patient devices, comprising: A network interface circuit configured to communicate with the patient device via a network; A memory coupled to the network interface circuitry, the memory being configured to receive a dataset via the network interface circuitry, the dataset including parameters to be used by software on the patient device to perform patient-related functions, the dataset including a software version indicator of the dataset, wherein the software version indicator indicates compatibility between the dataset and one or more specific versions of the software on the patient device, the memory also being configured to receive the current software version of the patient device; and processing circuitry configured to: compare the software version indicator of the dataset with the current software version of the patient device; determine that there is an inequality between the software version indicator of the dataset and the current software version of the patient device; and based on the determination of the inequality, distribute the dataset to the patient device. The processing circuit determines that there is an inequality if the software version indicator of the dataset is numerically less than or equal to the current software version of the patient device.

2. The distribution server according to claim 1, wherein, The patient device is a clinician-programmable infusion pump, wherein the dataset includes hard and soft constraints on the parameters to be programmed by the clinician.

3. The distribution server according to claim 1, wherein, The software version indicator of the dataset and the current software version of the patient device each include a first software version code and a second software version code, wherein the dataset is distributed to the patient device based on the determination that the first software version codes are equal and the second software version codes are not equal.

4. The distribution server according to claim 3, wherein, The first software version code is the major software version code, and the second software version code is the minor software version code.

5. The distribution server according to claim 3, wherein, The primary software version code indicates an update to the pump control or pump mechanics, while the secondary software version code indicates an update to pump functionality unrelated to the dataset.

6. The distribution server according to claim 1, wherein, The software version indicator of the dataset and the current software version of the patient device each include a first function code associated with software running a first set of functions on the patient device and a second function code associated with software running a second set of functions on the patient device.

7. The distribution server according to claim 6, wherein, The dataset is distributed to the patient device based on the determination that both the first function code and the second function code are unequal.

8. The distribution server according to claim 1, wherein, The processing circuitry is configured to: receive an indication that the patient device has an updated software version; compare the updated software version with a plurality of datasets in the memory, each dataset having a different software version indicator; determine at least one dataset having a software version indicator that is numerically less than or equal to the updated software version; and distribute the dataset to the patient device based on the determination that the software version indicator is numerically less than or equal to the updated software version.

9. The distribution server according to claim 8, wherein, The processing circuitry is configured to compare, determine, and distribute as described in claim 8, without requiring manual user input.

10. A distribution server for downloading datasets to patient devices, comprising: A network interface circuit configured to communicate with the patient device via a network; A memory coupled to the network interface circuitry, configured to receive a dataset via the network interface circuitry, the dataset including parameters to be used by software on the patient device to perform patient-related functions, the dataset including a software version indicator indicating compatibility between the dataset and one or more specific versions of the software on the patient device, the memory also configured to receive the current software version of the patient device; and processing circuitry configured to: compare the software version indicator of the dataset with the current software version of the patient device; determine, based on the comparison, not to distribute the dataset to the patient device; receive an indication that the patient device has a newer software version; automatically compare the software version indicator of the dataset with the newer software version without receiving manual user input; determine, based on the comparison with the newer software version, to distribute the dataset to the patient device; and distribute the dataset to the patient device based on the determination to distribute the dataset to the patient device. Specifically, the processing circuit determines to distribute the dataset to the patient device if there is a discrepancy between the software version indicator of the dataset and the updated software version. The processing circuit determines that there is an inequality if the software version indicator of the dataset is numerically less than or equal to the updated software version.

11. The distribution server according to claim 10, wherein, The patient device is a clinician-programmable infusion pump, wherein the dataset includes hard and soft constraints on the parameters to be programmed by the clinician.

12. The distribution server according to claim 10, wherein, The memory is configured to store multiple datasets, each dataset having a corresponding software version indicator, wherein the processing circuitry is configured to identify at least two datasets compatible with the patient device, wherein the processing circuitry is configured to issue one of the two datasets having a larger software version indicator than the other of the two datasets.

13. The distribution server according to claim 10, wherein, The dataset also includes a device type indicating the type of patient device, wherein the software version indicator of the dataset and the updated software version of the patient device each include a first software version code and a second software version code, wherein the dataset is distributed to the patient device based on determining that the first software version codes are equal and the second software version codes are not equal.

Images