阅读说明：本技术 单采血设备车队管理系统和方法 (Single blood sampling equipment fleet management system and method ) 是由 M·谭 于 2019-08-26 设计创作，主要内容包括：车队管理系统包括单采血设备和远离单采血设备并与之通信的车队管理设备。每个单采血设备具有控制器、固件和固件设置。车队管理设备包括允许用户与车队管理设备进行交互的界面、服务器和处理器。服务器从用户和/或远程储存库接收关于每个单采血设备的固件/固件设置和固件文件的信息。处理器处理该信息,以确定哪个单采血设备需要更新固件/固件设置。然后,服务器将固件文件分发到需要更新的每个单采血设备。该系统还可以为一个或多个捐献中心开发车队模型,该模型包括针对(一个或多个)位置的推荐的设备数量和/或是否应将设备从一个位置移动到另一个位置。(The fleet management system includes a apheresis device and a fleet management device remote from and in communication with the apheresis device. Each apheresis device has a controller, firmware, and firmware settings. The fleet management device includes an interface, a server, and a processor that allow a user to interact with the fleet management device. The server receives information about the firmware/firmware settings and firmware files for each apheresis device from the user and/or a remote repository. The processor processes this information to determine which blood collection set alone needs to update the firmware/firmware settings. The server then distributes the firmware file to each apheresis device that needs to be updated. The system may also develop a fleet model for one or more donation centers that includes a recommended number of devices for the location(s) and/or whether the devices should be moved from one location to another.)

1. A fleet management system, comprising:

a first plurality of single blood collection devices, each of the first plurality of single blood collection devices having a controller, firmware, and firmware settings;

a fleet management device remote from and in communication with each of the first plurality of single blood collection devices, the fleet management device comprising:

an interface configured to allow a user to interact with the fleet management device;

a server configured to receive information about firmware and firmware settings for each of the first plurality of apheresis devices and configured to receive firmware files from a user and/or a remote repository; and

a processor configured to process information received from each of the first plurality of apheresis devices to determine which of the first plurality of apheresis devices requires updating of firmware and/or firmware settings, the server configured to distribute a firmware file to each of the first plurality of apheresis devices requiring updating.

2. The fleet management system of claim 1, further comprising a second plurality of single blood collection devices remote from and in communication with the fleet management device.

3. The fleet management system of claim 2, wherein:

the server is further configured to receive information regarding firmware and firmware settings of each of the second plurality of single blood drawing devices, an

The processor is further configured to process information received from each of the second plurality of single blood drawing devices to determine which of the second plurality of single blood drawing devices requires an update to firmware and/or firmware settings, the server configured to distribute a firmware file to each of the second plurality of single blood drawing devices requiring an update.

4. The fleet management system of claim 2, wherein the first plurality of single blood collection devices is located at a first donation center and the second plurality of single blood collection devices is located at a second donation center.

5. The fleet management system of claim 1, wherein the fleet management device is configured to allow a user to remotely manage and/or monitor firmware files and/or firmware settings of each of the first plurality of apheresis devices.

6. The fleet management system of claim 5, wherein the fleet management device is configured to: alerting a user if the firmware file and/or firmware settings file is successfully or unsuccessfully installed on at least one of the first plurality of apheresis devices.

7. The fleet management system of claim 1, wherein the fleet management device is configured to gather additional information from each of the first plurality of apheresis devices.

8. The fleet management system of claim 7, wherein the collected additional information includes information selected from the group consisting of: the apheresis procedure performed, productivity information, utilization information, number of apheresis devices within the donation center, performance data, and inventory data.

9. The fleet management system of claim 1, wherein the processor is configured to analyze information regarding firmware and firmware settings of each of the first plurality of apheresis devices to determine whether there is a difference in firmware version or firmware setting values for each of the first plurality of apheresis devices.

10. The fleet management system of claim 9, wherein the fleet management device is configured to notify a user of the discrepancy.

11. The fleet management system of claim 1, wherein the fleet management device is configured to generate a fleet model for one or more donor centers.

12. The fleet management system of claim 11, wherein the fleet model is based at least in part on information selected from the group consisting of: productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and other performance or production data thereof.

13. The fleet management system of claim 11, wherein the fleet model includes a recommended number of apheresis devices for one or more donor centers, the server configured to notify a user of the fleet model and the recommended number of apheresis devices.

14. The fleet management system of claim 1, wherein the fleet management device includes a data storage device configured to store information received from the first plurality of apheresis devices.

15. A fleet management device, comprising:

an interface configured to allow a user to interact with the fleet management device;

a server in communication with a first plurality of apheresis devices remote from the fleet management device, the server configured to receive information regarding firmware and firmware settings for each of the first plurality of apheresis devices, and configured to receive firmware files from a user and/or a remote repository; and

a processor configured to process information received from each of the first plurality of apheresis devices to determine which of the first plurality of apheresis devices requires updating of firmware and/or firmware settings, the server configured to distribute a firmware file to each of the first plurality of apheresis devices requiring updating.

16. The fleet management device of claim 15, wherein the server is further in communication with a second plurality of single blood collection devices remote from the fleet management device.

17. The fleet management device of claim 16, wherein:

the server is further configured to receive information regarding firmware and firmware settings of each of the second plurality of single blood drawing devices, an

The processor is further configured to process information received from each of the second plurality of single blood drawing devices to determine which of the second plurality of single blood drawing devices requires an update to firmware and/or firmware settings, the server configured to distribute a firmware file to each of the second plurality of single blood drawing devices requiring an update.

18. The fleet management device of claim 16, wherein the first plurality of single blood collection devices is located at a first donation center and the second plurality of single blood collection devices is located at a second donation center.

19. The fleet management device of claim 15, wherein the fleet management device is configured to allow a user to remotely manage and/or monitor firmware files and/or firmware settings of each of the first plurality of apheresis devices.

20. The fleet management device of claim 19, wherein the server is configured to: alerting a user if the firmware file and/or firmware settings file is successfully or unsuccessfully installed on at least one of the first plurality of apheresis devices.

21. The fleet management device of claim 15, wherein the server is configured to receive additional information from each of the first plurality of single blood collection devices.

22. The fleet management device of claim 21, wherein the additional information includes information selected from the group consisting of: the apheresis procedure performed, productivity information, utilization information, number of apheresis devices within the donation center, performance data, and inventory data.

23. The fleet management device of claim 15, wherein the processor is configured to analyze information regarding firmware and firmware settings of each of the first plurality of apheresis devices to determine whether there is a difference in firmware version or firmware setting values for each of the first plurality of apheresis devices.

24. The fleet management device of claim 23, wherein the server is configured to notify a user of the discrepancy.

25. The fleet management device of claim 15, wherein the server and/or the processor is configured to generate a fleet model for one or more donor centers.

26. The fleet management device of claim 25, wherein the fleet model is based at least in part on information selected from the group consisting of: productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and other performance or production data thereof.

27. The fleet management device of claim 25, wherein the fleet model includes a recommended number of apheresis devices for one or more donor centers, the server configured to notify a user of the fleet model and the recommended number of apheresis devices.

28. The fleet management device of claim 15, further comprising a data storage device configured to store information received from the first plurality of apheresis devices.

29. A method for managing a fleet of apheresis devices, comprising:

remotely connecting to a first plurality of apheresis devices, each of the apheresis devices having a controller, firmware, and firmware settings;

receiving, in a server of a fleet management device, information regarding firmware and firmware settings for each of the first plurality of apheresis devices;

receiving, in the server of the fleet management device, firmware files from a user and/or a remote repository;

processing, in the processor of the fleet management device, information received from each of the first plurality of apheresis devices to determine which of the first plurality of apheresis devices requires updating firmware and/or firmware settings; and

distributing, using the server of the fleet management device, a firmware file to each of the first plurality of apheresis devices in need of updating.

30. The method of claim 29, further comprising connecting to a second plurality of single blood collection devices remote from the fleet management device.

31. The method of claim 30, further comprising:

receiving, in the server of the fleet management device, information regarding firmware and firmware settings for each of the second plurality of single lancing devices;

processing, using the processor of the fleet management device, the information received from each of the second plurality of single blood collection devices to determine which of the second plurality of single blood collection devices requires updating firmware and/or firmware settings; and

distributing, using the server of the fleet management device, a firmware file to each of the second plurality of single blood collection devices that requires updating.

32. The method of claim 30, wherein said first plurality of single blood drawing devices is located at a first donation center and said second plurality of single blood drawing devices is located at a second donation center.

33. The method of claim 29, further comprising:

managing firmware files and/or firmware settings for each of the first plurality of single blood collection devices using the fleet management device.

34. The method of claim 33, further comprising:

alerting a user if the firmware file and/or firmware settings file is successfully or unsuccessfully installed on at least one of the first plurality of apheresis devices.

35. The method of claim 29, further comprising:

additional information is collected from each of the first plurality of apheresis devices.

36. The method of claim 35, wherein the collected additional information comprises information selected from the group consisting of: blood collection procedures performed, productivity information, utilization information, number of apheresis devices in the donation center, performance data, and inventory data.

37. The method of claim 29, further comprising:

analyzing, using the processor, information regarding firmware and firmware settings of each of the first plurality of apheresis devices to determine whether there is a difference in firmware version or firmware setting values for each of the first plurality of apheresis devices.

38. The method of claim 37, further comprising notifying a user of the difference.

39. The method of claim 29, further comprising generating a fleet model for one or more donor centers.

40. The method of claim 39, wherein the fleet model is based at least in part on information selected from the group consisting of: productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and other performance or production data thereof.

41. The method of claim 39, wherein the fleet model comprises a recommended number of apheresis devices for one or more donation centers, the method further comprising notifying a user of the fleet model and the recommended number of apheresis devices.

42. The method of claim 29, further comprising:

storing information received from the first plurality of apheresis devices in a data storage device in the fleet management device.

Technical Field

The present invention relates to managing single blood collection (apheresis) devices, and more particularly to supervising and managing multiple single blood collection devices from a remote location and methods thereof.

Background

Apheresis is a process in which individual blood components can be separated and collected from whole blood drawn from a subject, and apheresis devices are medical devices designed and intended to perform apheresis procedures. A donation center typically owns more than one single blood collection device, and each device is typically configured to operate in exactly the same manner to comply with the standard operating procedures of the donation center and to comply with regulatory requirements. The configuration of a single blood collection device is determined by embedded software (also referred to as device firmware) and a different set of firmware settings in the device to dictate how each feature of the device operates and performs.

To change or update the firmware version of a single blood collection device, a user must currently locally access the device through the device's built-in controller, input methods, and display output. The user then downloads the firmware file to a single device and performs the firmware update from within the internal device controller (i.e., at each device). In order to perform the same process on multiple single blood collection devices, the above process must be repeated locally for each device.

Similarly, to change or update the firmware settings of a single blood collection device, the user must also locally access the device through the device's built-in controller, input methods, and display output. This in turn enables the user to access the firmware settings and allow the user to change the firmware setting value(s) by manual manipulation or by reading, entering or scanning pre-encoded firmware settings. In order to perform the same procedure on a plurality of single lancing devices, the user must again locally repeat the procedure for each device.

In addition to having to update each device individually, the user must also have local access to each device to simply check whether the device is configured to operate in exactly the same manner. Thus, after a user accesses the apheresis device through the device's built-in controller, input method, and display output, the user can check the firmware version and firmware settings of the respective device. This can be performed on each device individually by physically manipulating the controls of a single lancing device and viewing the values set by each firmware. Depending on the number of devices in a given donation center, this can be a very time consuming task.

Disclosure of Invention

In various embodiments of the present invention, a company employee may use a computer system from a remote location to supervise and manage at least one apheresis device in a company fleet (fleet). From this remote location, the user can manage the apheresis device firmware files, firmware settings, and perform a check of the firmware settings without any physical manipulation of controls on the built-in apheresis device controller itself. The system may be connected to a plurality of apheresis devices from a central location or a remote location. The connection may be persistent or may be intermittent.

The system may receive a firmware file from a user or from an external repository, and the file may be distributed to at least one single blood collection device for installation on the device. The system may alert the user when the firmware file has been installed successfully or unsuccessfully. Alternatively, the user may also check the firmware version of the single blood collection device using the system to confirm whether the firmware file has been installed successfully or unsuccessfully.

The system may receive firmware settings from a user, from an external repository, or from an apheresis device. The firmware profile may be used to configure a plurality of apheresis devices in a corporate fleet (e.g., within a donation center or multiple donation centers). The firmware profile may be distributed to the apheresis device(s) so that the device applies the changes represented in the firmware profile. The system may alert the user when the firmware setting change has been applied successfully or unsuccessfully. Alternatively, the user may also check the firmware settings of the single blood collection device using the system to confirm whether the changes to the firmware settings file were applied successfully or unsuccessfully.

In some embodiments, the system may use connections to apheresis devices in a fleet to gather information from various devices in the fleet regarding firmware versions or firmware settings. The system may then aggregate, combine, and analyze the information to determine if there are any differences in firmware versions or firmware settings between the apheresis devices. The system may also create a notification, such as an email to the user, when the system detects a firmware version or firmware setting difference.

In still further embodiments, the system may use heuristics to create a fleet model based on the locations of the apheresis devices in the fleet and productivity information from those locations. Fleet modeling may determine the best number of devices for a profile for a location and may provide instructions to a user to add or remove devices from the location. The system may use information based on productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and/or other performance or production data thereof to determine an optimal fleet model for each location. The system may also use the location data of the apheresis device to determine a plasma hub location that will require modification of the placement of the device to meet the requirements of a new fleet model, and may provide guidance to the user, possibly in a digitally assisted form, with instructions to adjust the placement of the apheresis device at a particular plasma hub location in the company.

Additionally or alternatively, the system may monitor for firmware version differences or firmware setting differences using connections to apheresis devices in the fleet. Unexpected discrepancies (i.e., changes) between apheresis devices may be tracked, recorded, and reported to corporate users or users of a corporation. Alternatively, the system may self-correct any changes between individual blood collection devices by sending a firmware file of the firmware setup file to update on an off-standard blood collection device.

According to a further embodiment, a fleet management system includes a first plurality of apheresis devices and a fleet management device. Each individual lancing device can have a controller, firmware, and firmware settings. The fleet management device may be remote from and in communication with each of the apheresis devices. The fleet management device may include an interface, a server, and a processor. The interface may allow a user to interact with the fleet management device, and the server may receive information about firmware and firmware settings from each individual blood collection device, and may receive firmware files from the user and/or a remote repository. The processor may process information received from the apheresis device to determine which apheresis device requires an update to the firmware and/or firmware settings. The server may then distribute the firmware file to each apheresis device that needs to be updated.

The fleet management system can also include a second plurality of single blood collection devices remote from and in communication with the fleet management device. The server may also receive information about firmware and firmware settings from each of the second plurality of single blood collection devices, and the processor may process the information to determine which of the single blood collection devices requires an update to the firmware and/or firmware settings. The server may then distribute the firmware file to each device that needs to be updated. The first plurality of single blood collection devices may be located at a first donation center, and the second plurality of single blood collection devices may be located at a second donation center.

In other embodiments, the fleet management device may allow a user to remotely manage the firmware files and/or firmware settings of each apheresis device. For example, the fleet management device may alert the user whether the firmware files and/or firmware settings files were successfully or unsuccessfully installed on a single blood collection device. The fleet management device may also collect additional information from each apheresis device, such as data related to the apheresis procedure performed, productivity information, utilization information, the number of apheresis devices in the donation center, performance data, and/or inventory data. The processor may analyze the information (or other information) regarding the firmware and firmware settings of each apheresis device to determine whether there is a difference in the firmware version or firmware setting values of each apheresis device. In such embodiments, the fleet management device may notify the user of the discrepancy.

In further embodiments, the fleet management device may generate a fleet model for one or more donor centers. For example, a fleet model may be based at least in part on information regarding productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and other performance or production data thereof. The fleet model may include recommended apheresis device changes for one or more donation centers, and the server may notify the user of the fleet model and the recommended apheresis device changes. The fleet management device may also include a data storage device that stores information received from the apheresis device.

According to further embodiments, the fleet management device may include an interface that allows a user to interact with the fleet management device and a server in communication with the first plurality of apheresis devices. The single blood collection devices may be located remotely from the fleet management device, and the server may receive information about firmware and firmware settings from each single blood collection device and firmware files from a user and/or a remote repository. The processor may process the information received from each apheresis device to determine which apheresis device needs to update the firmware and/or firmware settings. The server may then distribute the firmware file to each apheresis device that needs to be updated.

The server may also be in communication with a second plurality of single blood collection devices located remotely from the fleet management device. In such embodiments, the server may also receive information about firmware and firmware settings from each of the second plurality of single blood collection devices, and the processor may process the received information to determine which single blood collection device needs to be updated. The server may then distribute the firmware file to each of a second plurality of single blood drawing devices that need to be updated.

The fleet management device may allow a user to remotely manage and/or monitor firmware files and/or firmware settings for each of the first plurality of apheresis devices, and the server may alert the user whether the firmware files and/or firmware settings files were successfully or unsuccessfully installed. Additionally or alternatively, the server may receive additional information (e.g., the performed apheresis procedure, production rate information, utilization information, number of apheresis devices within the donation center, performance data, and inventory data) from each of the first plurality of apheresis devices.

In some embodiments, the processor may determine whether there is a difference in firmware version or firmware setting values for the apheresis device by analyzing information about the firmware and firmware settings for each apheresis device. The server may notify the user of any discrepancies. Additionally or alternatively, the server and/or processor may generate a fleet model for one or more donor centers. The fleet model may be based on information about productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and other performance or production data thereof. The fleet model may include recommended apheresis device changes for one or more donation centers, and the server may notify the user of the fleet model and the recommended apheresis device changes. Device changes may include the number of devices that should be within a given donation center, the location of the devices, and whether one or more devices should be moved from one center to another.

According to further embodiments, a method for managing a fleet of apheresis devices includes remotely connecting to a first plurality of apheresis devices and receiving, in a server of the fleet management device, (1) information regarding firmware and firmware settings for each of the first plurality of apheresis devices (e.g., from the apheresis devices), and (2) firmware files (e.g., from a user and/or a remote repository). The method may then process the information received from the apheresis devices in a processor of the fleet management device to determine which apheresis device requires an update to the firmware and/or firmware settings. The method may then distribute the firmware file to each of the first plurality of single blood collection devices requiring updating using a server of the fleet management device.

In some embodiments, the method may further include connecting to a second plurality of single blood collection devices remote from the fleet management device, and receiving, in a server of the fleet management device, information related to firmware and firmware settings of each of the second plurality of single blood collection devices. The method may then (1) process, using a processor of the fleet management device, the information received from each of the second plurality of single blood collection devices to determine which of the second plurality of single blood collection devices require an update of the firmware and/or firmware settings, and (2) distribute, using a server of the fleet management device, the firmware file to each of the second plurality of single blood collection devices requiring an update.

Additionally, the method may use the fleet management device to manage and/or monitor the firmware files and/or firmware settings of each of the first plurality of apheresis devices and/or generate a reminder to a user whether the firmware files and/or firmware settings files have been successfully or unsuccessfully installed on the apheresis device. The method may also collect and store (e.g., within a data storage device) additional information from each of the first plurality of apheresis devices. For example, the method may collect information about the blood collection process performed, productivity information, utilization information, the number of apheresis devices in the donation center, performance data, and inventory data. The method may also use a processor to analyze information about the firmware and firmware settings of each apheresis device to determine whether there is a difference in firmware version or firmware setting values for each apheresis device. If a discrepancy exists, the method may notify the user of the discrepancy.

In further embodiments, the method may generate a fleet model for one or more donor centers. The fleet model may be based at least in part on information related to productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and other performance or production data thereof. The fleet model may include recommended apheresis device changes for one or more donor centers, and the method may notify the user of the fleet model and the recommended apheresis device changes. The method may also store information received from the apheresis device in a data storage device in the fleet management device.

Drawings

The foregoing features of the embodiments will be more readily understood by reference to the following detailed description, taken with reference to the accompanying drawings, in which:

fig. 1 schematically illustrates a perspective view of a blood processing system according to some embodiments of the present invention.

Fig. 2 schematically illustrates a top view of the blood processing system of fig. 1, according to some embodiments of the present invention.

Fig. 3 schematically illustrates a disposable set installed within the blood processing system of fig. 1, according to some embodiments of the present invention.

Fig. 4 schematically illustrates an apheresis device and its associated firmware and firmware settings according to some embodiments of the invention.

Fig. 5 schematically illustrates fleet management providing supervision of a plurality of apheresis devices at a plurality of plasma center locations, according to some embodiments of the invention.

Fig. 6 schematically illustrates fleet management modeling to determine optimal number and placement of apheresis devices at a plasma center location, according to some embodiments of the invention.

Detailed Description

In an illustrative embodiment, a fleet management system has a fleet management device that is remote from and in communication with several apheresis devices. The fleet management device can receive information regarding firmware and firmware settings and firmware files from each of the first plurality of single blood collection devices. The device may then process this information to determine which apheresis device needs to be updated, and then distribute the firmware file to each apheresis device that needs to be updated, e.g., to ensure that each apheresis device has the same firmware and firmware settings.

As shown in fig. 1 and 2, the blood processing system 100 includes a cabinet 110, the cabinet 110 housing the major components (e.g., non-disposable components) of the system 100. Within cabinet 110, system 100 may include a first/blood pump 232 and a second/anticoagulant pump 234, first/blood pump 232 drawing whole blood from the subject, and second/anticoagulant pump 234 pumping anticoagulant through system 100 and into the drawn whole blood. Further, the system 100 may include a plurality of valves that may be opened and/or closed to control fluid flow through the system 100. For example, the system 100 may include a donor valve 120 that may be opened and closed to selectively prevent and allow fluid flow through the donor line 218 (e.g., inlet line; fig. 3), and a plasma valve 130 that selectively prevents and allows fluid flow through the outlet/plasma line 222 (fig. 3). Some embodiments may also include a brine valve 135, the brine valve 135 selectively preventing and allowing brine to flow through the brine line 223.

To facilitate connection and mounting of disposable devices and support corresponding fluid containers, system 100 may include anticoagulant rod 150 and saline rod 160, anticoagulant solution container 210 (fig. 3) may be suspended from anticoagulant rod 150, and saline solution container 217 (fig. 3) may be suspended from saline rod 160 (e.g., if the procedure being performed requires the use of saline). Furthermore, in some applications, it may be necessary and/or desirable to filter whole blood drawn from a subject for processing. To this end, the system 100 may include a blood filter holder 170, in which blood filter (on a disposable set) may be placed in the blood filter holder 170.

As discussed in more detail below, the apheresis system 100 according to embodiments of the present invention uses a blood pump 232 to draw whole blood from a subject through the venous access device 206 (fig. 3). When the system 100 draws whole blood from a subject, the whole blood enters a blood component separation device 214, such as a Latham-type centrifuge (other types of separation chambers and devices may be used, such as, but not limited to, integrally blow-molded centrifuge drums as described in U.S. Pat. Nos. 4,983,158 and 4,943,273, which are incorporated herein by reference). The blood component separation device 214 separates the whole blood into its constituent components (e.g., red blood cells, white blood cells, plasma, and platelets). Thus, to facilitate operation of separation device 214, system 100 may also include a well 180 in which separation device 214 may be placed and in which separation device 214 rotates (e.g., to create the centrifugal force required to separate whole blood).

To allow the user/technician to monitor the system operation and control/set various parameters of the process, the system 100 may include a user interface 190 (e.g., a touch screen device) that displays the operating parameters, any reminder messages, and buttons that the user/technician may press to control the various parameters. Additional components of the blood processing system 100 are discussed in more detail below (e.g., with respect to system operation).

Fig. 3 is a schematic block diagram of a blood processing system 100 and a disposable collection device 200 (having an inlet disposable device 200A and an outlet disposable device 200B) that may be loaded onto/into the blood processing system 100 in accordance with the present invention. The collection device 200 includes a venous-access device 206 (e.g., a phlebotomy needle) for drawing blood from a donor's arm 208, an anticoagulant container 210, a centrifuge bowl 214 (e.g., a blood component separation device), a saline container 217, and a final plasma collection bag 216. A blood/inlet line 218 couples the venous access device 206 to an inlet port 220 of the bowl 214, a plasma/outlet line 222 couples an outlet port 224 of the bowl 214 to the plasma collection bag 216, and a saline line 223 connects the outlet port 224 of the bowl 214 to a saline container 217. Anticoagulant line 225 connects anticoagulant container 210 to inlet line 218. In addition to the components mentioned above and shown in fig. 3, the blood processing system 100 also includes a controller 226, a motor 228, and a centrifugal chuck 230. The controller 226 is operably coupled to two pumps 232 and 234, and to a motor 228, the motor 228 in turn driving a chuck 230. The controller 226 may be operatively coupled to the user interface 190 and in communication with the user interface 190.

In operation, the disposable collection devices 200 (e.g., the inlet disposable device 200A and the outlet disposable device 200B) may be loaded onto/into the blood processing system 100 prior to blood processing. In particular, blood/inlet line 218 is routed through blood/first pump 232 and anticoagulant line 225 from anticoagulant container 210 is routed through anticoagulant/second pump 234. Centrifuge bowl 214 may then be securely loaded into chuck 230. Once the bowl 214 is secured in place, the technician may install the outlet disposable set 200B. For example, the technician may connect the bowl connector 300 to the outlet 224 of the bowl 214, mount the plasma container 216 to the weight sensor 195, pass the saline line 223 through the valve 135, and pass the plasma/outlet line 222 through the valve 130 and line sensor 185. Once the disposable set 200 is installed and the anticoagulant and saline containers 210/217 are connected, the system 100 is ready to begin blood processing.

The blood processing system 100 (e.g., an apheresis device) and/or various hardware components of the blood processing system 100 may include firmware 420 and firmware settings 430A-C that control various components of the blood processing system 100 (see fig. 4) and the operation of the system 100. At various times, firmware 420 and/or firmware settings 430A/B/C may become obsolete or otherwise need to be updated. To this end, controller 226 and input devices and display 190 of device 100 may allow a user to access device 100, for example, to view and/or update firmware 420 and/or firmware settings 430A/B/C.

Fig. 5 schematically illustrates a fleet management system that may remotely update firmware 420 and/or firmware settings 430A/B/C of one or more blood processing systems/apheresis devices 100. For example, the fleet management system 510 may be a remote computer system that oversees and manages some or all of the apheresis devices 520A-F in a fleet of companies. The management system 510 may include a number of components that assist the system 510 in monitoring, communicating with, and updating the firmware of various apheresis devices. For example, the management system/device 510 may include a processor 530 that monitors the status (e.g., settings, versions, etc.) of each of the apheresis device(s) 520A-F and firmware, and a memory 540 (e.g., a data storage device) for storing information related to the apheresis device(s) 520A-F (e.g., firmware version, firmware settings, last update date, any issues with firmware and/or firmware settings, etc. for each device). Additionally, the system 510 may include a server 550 in communication with the apheresis devices 520A-F (and possibly other remote devices/systems) and a controller interface/display 560 that provides information to the user/operator.

As shown in FIG. 5, the apheresis devices 520A-F may be located in a single donation center 530A or multiple donation centers 530A/B. The fleet management system 510 allows a user to remotely manage the apheresis device firmware files 420, firmware settings 430A-C, and perform various checks of the firmware settings for each apheresis device 520A-F. For example, and as discussed in more detail below, the server 550 may communicate with each of the apheresis devices 520A-F to monitor and download data regarding the firmware and firmware settings of each of the devices 520A-F. Processor 530 (or server 550) may then process the received information/data to determine whether each device 520A-F needs to update firmware 420 and/or firmware settings 430A-C.

It is important to note that because the fleet management system 510 allows a user to remotely manage each of the single blood collection devices 520A-F, the user need not physically present at each device 520A-F to manipulate the built-in controls on each single blood collection device (e.g., the user need not physically interact with the controller 226 of each device). The connection/communication between the fleet management system 510 and each of the apheresis devices 520A-F may be persistent/continuous or the fleet management system 510 may be connected to the apheresis devices 520A-F only when needed (e.g., when a user wishes to monitor or manage a particular device). For example, the fleet management system 510 may continuously receive information/data related to the firmware of each of the apheresis devices 520A-F (as well as other information about the devices 520A-F), or the fleet management system 510 may only receive the firmware information/data periodically (e.g., at predetermined intervals, when prompted by a user, only when there are updates to be distributed, only when prompted by the server 550 or the system 510, etc.).

As described above, the fleet management system 510 may manage a plurality of individual blood collection devices 520A-F as needed. To this end, the fleet management system 510 (e.g., server 550) may receive firmware files from a user or from an external repository (or other remote device/database). If the system 510 has not received firmware information/data from each of the devices 520A-F (e.g., via a continuous connection or a recent periodic connection/update), the server 550 may then connect to each of the devices 520A-F and download firmware information/data (including the current firmware version, firmware settings, and any firmware issues) for each of the devices 520A-F. Upon receiving this information, processor 530 may then determine which device 520A-F needs to update firmware 420 and/or firmware settings 430A-C, and system 510 (e.g., server 550) may distribute the firmware file(s) to any of devices 520A-F that need the new firmware file(s) to be installed.

In addition to sending the update (s)/new firmware file(s) to each of the devices 520A-F that needs it, the system 510 may also monitor the progress of the installation and/or firmware update and provide a reminder to the user when the firmware file has been successfully installed and/or if the installation is unsuccessful. If the installation is unsuccessful, the system 100 may provide the user with an option to retry the download and installation. Additionally or alternatively, fleet management system 510 may allow a user to manually check the firmware version of each of the individual blood collection devices 520A-F to confirm whether the firmware files have been successfully or unsuccessfully installed. For example, the system 510 may display (on the interface/display 560) each of the devices 520A-F to which the system 510 is connected/maintained, and possibly current firmware information for each of the devices 520A-F. The user may then select a device of interest in devices 520A-F to obtain additional information about the device, including but not limited to the location of the device, the service and usage history of the device, firmware 420 and firmware settings 430A-C information, the date of the most recent update, any recent error messages, and/or the progress of any ongoing installation. It should be noted that the system 510 may display the devices 520A-F in any number of ways, including, but not limited to, a list of devices or a plan view of each plasma center 530A/B with icons depicting each device 520A-F in place.

In some embodiments, a user may not wish to update firmware 420 and/or firmware settings 430A-C when using a single blood drawing device 520A-F. Thus, any updates may be performed after the normal donation time of plasma hub 530A/B. Alternatively, the system 510 (e.g., server 550) may receive information regarding the operational status of each device 520A-F (e.g., whether it is in use) and/or whether the devices 520A-F are scheduled for apheresis procedures. Management system 510 may then decide whether to update firmware 420 and/or firmware settings 430A-C based on the operational information. For example, if a single blood collection device 520A-F is in the middle of a procedure or is to be used for a procedure, the system 510 may wait to distribute a firmware update to that device 520A-F. In a similar manner, when a given device 520A-F is scheduled to update, the system 510 may notify the plasma center 530A/B to ensure that the device 520A-F is not assigned to the process until the update is complete.

At various times, the plasma hub 530A/530B may receive new apheresis devices 520A-F and/or replace existing devices 520A-F, and these new devices may need to be initially configured so that their firmware and firmware settings match with other devices within the hub 530A/B. To this end, the system 510 may configure these new devices (and/or configure/reconfigure the existing devices 520A-F). In a manner similar to that described above, the system 510 may receive firmware profiles from a user, from an external repository, or from at least one apheresis device 520A-F, and the fleet management system 510 may use the firmware profiles to configure some or all of the apheresis devices 520A-F in a corporate fleet. For example, the system 510 may display the devices 520A-F that require configuration on the interface/display 560, and the user may select which of the devices 520A-F to configure (or the system 510 may automatically configure the devices without input from the user). The system 510 (e.g., server 550) may then distribute the firmware profile to the appropriate apheresis device(s) 520A-F so that each device receiving the firmware profile may apply the changes represented in the firmware profile. Again, the system 510 may alert the user when the firmware setting change has been successfully applied and/or if the update is unsuccessful (e.g., an error occurs). Additionally or alternatively, as described above, the user may also use the system 510 to manually check the firmware settings of the apheresis device(s) 520A-F to confirm whether the firmware setting file changes were applied successfully or unsuccessfully.

In some cases, it may be beneficial to ensure that each of the single blood collection devices 520A-F within the fleet and/or within the plasma centers 530A/B all operate with the same firmware version 420 and firmware settings 430A-C. Thus, in addition to updating and sending firmware updates to each of the apheresis devices 520A-F, the fleet management system 510 may also gather information about the firmware version 420 or firmware settings 430A-C from each of the devices 520A-F in the fleet. The system 510 (e.g., processor 530) may then aggregate, combine, and/or analyze the data to determine whether there are any differences in firmware versions 420 or firmware settings 430A-C between apheresis devices 520A-F within the fleet and/or within a particular plasma center 530A/B.

If there are differences between firmware version 420 and/or firmware settings 430A-C, system 510 may notify the user. For example, the system 210 may create and send an email notification to the user or display the notification on the interface 560 when it detects a firmware version or firmware setting discrepancy. The system 510 may then give the user an opportunity to correct the discrepancy by downloading/distributing the appropriate firmware version 420 and/or settings 430A-C to the appropriate apheresis device 520A-F (or downloading/distributing a new firmware version and/or new firmware settings to all of the device apheresis devices 520A-F). Alternatively, the system 510 may automatically distribute the firmware file or firmware setup file to a single blood collection device to correct for discrepancies.

When planning the type and number of single blood collection devices 520A-F, the various plasma hubs 530A/B must take into account a number of factors (e.g., geographic location, expected donor participation, cost of the single blood collection devices 520A-F, maintenance costs of the single blood collection devices 520A-F, size of the plasma hubs 530A/B, type of donation and single blood collection process to be performed at the donor hubs, amount of collection required over a given period of time, etc.) to ensure that they have enough single blood collection devices 520A-F to service the expected number of donors and achieve the target collection amount without having too many unused single blood collection devices 520A-F at any given time. Thus, in addition to updating the firmware 420 and firmware settings 430A-C on the devices 520A-F, in some embodiments and as shown in FIG. 6, the fleet management system 510 may assist the plasma center 530A/B in determining an optimal number of apheresis devices 520A-F to meet its expected demand and achieve its target volume without an excessive number of apheresis devices 520A-F. For example, in such embodiments, the system 510 may also download/receive information from the plasma hub 530A/B (and each of the apheresis devices 520A-F) regarding apheresis procedures performed at the plasma hub 530A/B, productivity information from the plasma hub 530A/B, and possibly information regarding donor flow rates and plasma hub 530A/B goals. The system 510 (e.g., processor 530) may then process and analyze the information data, for example, using heuristics based on the locations of the apheresis devices in the fleet and the production rate information from those locations, to create a fleet model for the plasma center 530A.

The fleet model determines the optimal number of apheresis devices 520A-F for a profile of a location, and the system 510 may provide instructions to the user to add or remove devices from that location based on the fleet model. For example, if the fleet model indicates that the plasma hub 530A/B does not have a sufficient number of apheresis devices 520A-F to meet the demand/number of donors and/or to achieve a target collection volume for the hub 530A/B, the system 510 will notify the user that the plasma hub 530A/B should add additional apheresis devices 520A-F. Alternatively, as shown in FIG. 6, if the fleet model determines that plasma center 530A/B has too many apheresis devices 520A-F, system 510 may instruct the user to remove one or more of apheresis devices 520A-F (e.g., remove apheresis devices 520E and 520F).

The system 510 may use various information including, but not limited to, productivity, utilization, telemetry, inventory, quantity, consumption, cost, timing, averages, rates, speed data, and/or other performance or production data thereof when generating an optimal fleet model for one or more locations. The system 510 may also use the single blood collection device location data to determine a plasma center location that may require modification of device placement to meet the requirements of a new fleet model. Once a new fleet model is generated, the system 510 may provide guidance to the user in the form of digital assistance with instructions to adjust the placement of the apheresis devices 520A-F at a particular plasma hub location 530A/B in the company. For example, if the system 510 determines that the plasma center 530A has too many apheresis devices 520A-F, but the plasma center 530B does not have enough apheresis devices, the system 510 may instruct the user to move/position one or more machines from the plasma center 530A to the plasma center 530B.

While in many cases it may be expected that firmware 420 and firmware settings 430A-C will be out of date (e.g., if a firmware update is issued), in other cases firmware 420 and firmware settings 430A-C may be accidentally corrupted and/or changed. To this end, the system 510 may monitor for firmware version differences or firmware setting differences using connections to the apheresis devices 520A-F in the fleet. The system 510 may then track, log, and report (e.g., to a company or user) any unexpected differences/variations between the individual blood drawing devices 520A-F. The system 510 may maintain a history/record of the differences/changes (as well as any other information received from the apheresis devices 520A-F or generated by the system 510) in the data storage device 440.

It should be noted that although the above embodiments relate to a plasma collection device and a plasma apparatus, various embodiments of the present invention may be used with other fleet of apparatuses. For example, various embodiments of the present invention may be used in other types of donation centers (e.g., whole blood donation centers, platelet donation centers, etc.) and other types of apheresis devices. Furthermore, embodiments of the present invention may be used in other medical and non-medical settings.

It should also be noted that terms such as "controller," "processor," and "server" may be used herein to describe devices that may be used in certain embodiments of the invention, and should not be construed to limit the invention to any particular device type or system unless the context requires otherwise. Thus, a system may include, but is not limited to, a client, a server, a computer, an appliance, or other type of device. Such devices typically include one or more network interfaces for communicating over a communication network and a processor (e.g., a microprocessor with memory and other peripherals and/or dedicated hardware) that is accordingly configured to perform device and/or system functions. The communication network may generally comprise a public and/or private network; may include a local area network, a wide area network, a metropolitan area network, a storage network, and/or other types of networks; and may employ communication technologies including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking technologies, and internetworking technologies.

The individual components of the control program may be implemented individually or in combination. For example, each component may be implemented, or a dedicated server or a group of servers may be configured in a distributed manner.

It should also be noted that devices may use communication protocols and messages (e.g., messages created, transmitted, received, stored, and/or processed by a system), and such messages may be conveyed by a communication network or medium. The present invention should not be construed as limited to any particular communication message type, communication message format, or communication protocol unless the context requires otherwise. Thus, a communication message may generally include, but is not limited to, a frame, a packet, a datagram, a user datagram, a cellular, or other type of communication message. Unless the context requires otherwise, references to particular communication protocols are exemplary, and it should be understood that alternative embodiments may employ variations of such communication protocols as appropriate (e.g., modifications or extensions to the protocols that may be made from time to time) or other protocols known or developed in the future.

It should also be noted that a logic flow may be described herein to demonstrate various aspects of the present invention and should not be construed as limiting the present invention to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e.g., programs, modules, interfaces, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the invention. In general, logic elements may be added, modified, omitted, performed in a different order, or implemented using different logic constructs (e.g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing from the true scope of the invention.

The invention can be implemented in many different forms, including, but not limited to, computer program logic for use with a processor (e.g., a microprocessor, microcontroller, digital signal processor, or general purpose computer), programmable logic for use with a programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or other Programmable Logic Device (PLD)), discrete components, integrated circuitry (e.g., an Application Specific Integrated Circuit (ASIC)), or any other component, including any combination thereof. In some embodiments of the invention, substantially all of the described logic is implemented as a set of computer program instructions that are converted into a computer executable form, stored as such in a computer readable medium, and executed by a microprocessor under the control of an operating system.

Computer program logic implementing all or part of the functionality previously described herein may be embodied in various forms, including, but in no way limited to, source code forms, computer executable forms, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator). The source code may include a series of computer program instructions implemented in any of a variety of programming languages (e.g., object code, assembly language, or a high-level language such as FORTRAN, C + +, JAVA, or HTML) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in computer-executable form (e.g., via an interpreter), or the source code may be converted into computer-executable form (e.g., via a translator, assembler, or compiler).

The computer program may be fixed in any form (e.g., source code form, computer executable form, or intermediate form) either permanently or temporarily in a tangible storage medium, such as a semiconductor memory device (e.g., RAM, ROM, PROM, EEPROM or flash programmable RAM), a magnetic memory device (e.g., floppy or fixed disk), an optical memory device (e.g., CD-ROM), a PC card (e.g., PCMCIA card), or other memory device. The computer program may be fixed in any form as a signal that can be transmitted to a computer using any of a variety of communication techniques, including, but not limited to, analog techniques, digital techniques, optical techniques, wireless techniques, networking techniques, and internetworking techniques. The computer program may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system, e.g., on system ROM or fixed disk, or distributed from a server or electronic bulletin board over the communication system (e.g., the internet or world wide web).

Hardware logic implementing all or part of the functionality previously described herein, including programmable logic used with programmable logic devices, may be designed using conventional manual methods, or may be designed, captured, simulated or documented electronically using various tools, such as Computer Aided Design (CAD), hardware description languages (e.g., VHDL or AHDL), or PLD programming languages (e.g., PALASM, ABEL, or CUPL).

Programmable logic may be fixed permanently or temporarily in a tangible storage medium such as a semiconductor memory device (e.g., RAM, ROM, PROM, EEPROM, or flash programmable RAM), a magnetic memory device (e.g., a floppy disk or fixed disk), an optical memory device (e.g., a CD-ROM), or other memory device. Programmable logic may be fixed in a signal that may be transmitted to a computer using any of a variety of communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies (e.g., bluetooth), networking technologies, and internetworking technologies. Programmable logic may be distributed as a removable storage medium with an accompanying printed or electronic document (e.g., shrink-wrapped software), pre-loaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic device bulletin board over the communication system (e.g., the internet or world wide web). Indeed, some embodiments may be implemented in a software as a service model ("SAAS") or cloud computing model. Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the invention are implemented as entirely hardware, or entirely software.

The embodiments of the invention described above are intended to be exemplary only; many variations and modifications will be apparent to those of ordinary skill in the art. All such variations and modifications are intended to fall within the scope of the present invention as defined by any appended claims.