Patent Application
20140276379
Automated fluid delivery systems find many applications in medicine, veterinary practice, and animal research. The number of possible procedures, fluids, recipients, and conditions for fluid delivery may vary markedly. Procedures may include fluid delivery of antibiotics, saline, radiological contrast fluid, radioactive tracers, bone cement, gels, and gene therapy. The fluids may also include small molecules, macromolecules, gels, particles, cells, and viruses in any number of combinations. Recipients may include small rodents such as mice and rats, medium sized animals such as pigs and dogs, and humans. Volumes of injectate may range from about 1000 ml or more to less than about 1 nl, and delivery times may range from over about 1000 seconds (about 20 minutes) or more to less than 1 msec.
It is apparent that the variety of uses for fluid delivery systems suggests a variety of different systems, each optimized for the procedure, recipient, fluid, and/or condition for its intended use. It may be appreciated, both from the user's perspective as well as from the manufacturer's perspective, that the large number of possible fluid delivery systems may prove inconvenient. As one example, a small hospital may not be able to afford separate fluid delivery devices for antibiotic administration and the delivery of radiological contrast solutions for CT imaging. As another example, a medical researcher using animal models for human diseases may not wish to devote needed laboratory space to the number of injectors necessary to cover the wide variety of test animals including mice, dogs, and pigs. From the perspective of a manufacturer, it may be inefficient to develop one fluid delivery system to inject genetic material into a dog liver and then develop from scratch a second system to deliver radiological contrast material to a patient, since both systems are merely specific examples of a general system for introducing a fluid into a recipient.
It may, therefore, be appreciated that an intelligent and configurable fluid delivery system may reduce excess cost, space, and development time for both users and manufacturers, and provide flexibility to researchers to allow the development of new procedures that are not presently available with current equipment.
In an embodiment, a configurable fluid delivery system may include a fluid delivery unit having at least one delivery unit data source, a fluid actuator unit in reversible mechanical communication with the fluid delivery unit, in which the fluid actuator unit has an actuator unit data source, and a control unit. The control unit may include a computing device having a non-transitory, computer-readable storage medium in operable communication with the computing device, the computing device further being in reversible or two way data communication with the fluid delivery unit and the fluid actuator unit, and an output device in operable communication with the computing device. Additionally, the computer-readable storage medium may contain one or more programming instructions that, when executed, may cause the computing device to receive delivery unit data from the delivery unit data source and actuator unit data from the actuator unit data source, determine a mechanical compatibility status between the fluid delivery unit and the fluid actuator unit based, at least in part, on the delivery unit data and the actuator unit data, transmit, to the output device, an output related to the mechanical compatibility status, determine a communication integrity status between two or more of the fluid delivery unit, the fluid actuator unit, and the control unit, transmit, to the output device, an output related to the communication integrity status, and transmit, to the output device, an output configuration of a graphical display, wherein the output configuration is dependent, at least in part, on one or more of the delivery unit data and the actuator unit data.
In an embodiment, a method of assembling a configurable fluid delivery device includes selecting a fluid delivery unit from one or more fluid delivery units, selecting a fluid actuator unit from one or more fluid actuator units, placing the fluid actuator unit in reversible mechanical communication with the fluid delivery unit, placing a control unit in reversible data communication with one or more of the fluid delivery unit and the actuator unit, transmitting, by the control unit to an output device, mechanical status data related to the reversible mechanical communication between the fluid actuator unit and the fluid delivery unit, and transmitting, by the control unit to an output device, communication status data related to the reversible data communication between one or more of the fluid delivery unit and the control unit, and the fluid actuator unit and the control unit.
In an embodiment, a fluid delivery device or system may incorporate a high crack pressure valve between a fluid pressurizing device and one or more fluid path elements conducting fluid to the patient or fluid recipient.
FIGS. 6A,B illustrate examples of a spool-type high crack pressure valve in accordance with the present disclosure.
In a broad sense, a fluid delivery device may include a fluid delivery unit, such as a cradle element to hold a syringe, a disposable unit, such as a syringe, a fluid actuator unit, such as a linear driven piston and drive elements, which together are operated and controlled by a control unit to provide an injection. The control unit may present a user with information regarding setting up an injection protocol, ongoing status during the injection, and additional information regarding the injection procedure. In one example, the information may be presented as a graphical interface specific to the type of injection protocol being used. Additionally, the control unit may receive information from the user via an input device regarding parameters necessary for setting up the injection protocol.
A typical design cycle for such a fluid delivery device may have separate portions dedicated to the development of the actuator unit, the fluid delivery unit, the disposable unit, and the control unit. The design of the control unit, in particular, may require detailed knowledge of the fluid delivery unit, the fluid actuator unit, and the disposable unit. The control unit may include programming to incorporate safety features to prevent any one of the components from being damaged or operated outside its design specifications. Such safety features, such as maximum fluid delivery rate, total fluid delivery volume, and maximum fluid delivery pressure, may depend on the capabilities of the fluid delivery device's components. Additionally, the control unit may present a graphical interface to the user specific to the type of procedure for which the fluid delivery device may be used and may be designed to provide the optimum information regarding that procedure. The graphical interface may also be designed to receive only the information relevant to that injection procedure and include safeguards to prevent a user from entering information outside the appropriate bounds for operating the fluid delivery unit during that protocol.
It may, therefore, be appreciated that significant programming may be involved in the design of a control unit. Although any one type of fluid delivery device may differ from another type of fluid delivery device, nevertheless, there may be control components that are similar across a number of devices. One method for streamlining the control unit design may be for developers to have a library of routines (re-usable code) from which specific control routines may be incorporated into the control unit software during development. A difficulty with this method of software development may lie with potential upgrades and changes to hardware components of the fluid delivery device. If hardware is replaced on a fluid delivery device that is already in operation or available for sale, novel features in the upgraded hardware may not be reflected in the original control software, and thus may go unused. Alternatively, an upgrade in the device hardware may then require an equivalent upgrade in the control unit software to take advantage of the new features.
One method of addressing possible unequal development cycles of control unit software and delivery unit hardware may include the addition of intelligence within the separate hardware components associated with the fluid delivery device. In one embodiment, each fluid delivery unit, each actuator unit, and each disposable unit may have identification information included in the hardware itself. Such identification information may then be read by the control unit as a means to identify each of the components included in the fluid delivery device. The control unit software may then use the identification information to determine which of a variety of pre-programmed steps to take. In another embodiment, some or all of the fluid delivery unit components may include not only identification information, but executable software code (for example in small flash memory units) that may be downloaded by the control unit for execution. In this manner, the original control unit programming may not be restricted to the original programming, but may be able to incorporate updated programming associated with the individual hardware components necessary. Alternatively, each of the fluid delivery unit components may include a unit specific control unit that may present a standardized interface to the system control unit.
Disclosed below are a general outline of generic components that may be used in such an intelligent and configurable fluid delivery device and system, as well as a few specific examples of the types of fluid delivery devices that may be developed from it. It may be appreciated that a wide variety of individual devices may be produced from such a system, and that the examples disclosed below include merely a small number of possible devices. It may be further appreciated that where a singular component—such as a fluid delivery unit, a fluid actuator unit, a disposable unit or, an interface device—is disclosed, multiple components may also be considered incorporated within the scope of the disclosure.
As illustrated in
The fluid delivery unit 110 may include at least one delivery unit data source. In some non-limiting embodiments, the delivery unit data source may include one or more of the following: a delivery unit sensor, a delivery unit ID device, and a delivery unit data storage device. In some other non-limiting embodiments, the delivery unit data source may include one or more of the following: a delivery unit temperature sensor, a delivery unit pressure sensor, a motor current sensor, a force sensor, a delivery unit fluid flow sensor, a delivery unit fluid flow acceleration sensor, a delivery unit fluid flow deceleration sensor, a delivery unit particle-counting sensor, a delivery unit fluid viscosity sensor, and a delivery unit fluid leak sensor. In other non-limiting embodiments, the delivery unit data source may include one or more of the following: a linear bar code, a matrix bar code, and an RFID device. Additional non-limiting embodiments of the delivery unit data source may include one or more of the following: a flash drive device, a readable solid state memory device, a magnetic memory strip, a disk drive, and a programmable/readable solid state memory device.
Delivery unit data, associated with any one or more of the delivery unit data sources, may include without limitation any one or more of the following: delivery unit sensor unit data, delivery unit identifier data, and delivery unit data from a delivery unit data storage device. In some embodiments, the delivery unit data may include one or more of the following: a delivery unit product ID code, a delivery unit model number, a delivery unit serial number, a delivery unit date of manufacture, a time of fluid injection, a software version identifier, a firmware version identifier, calibration data, operational capability data, and a delivery unit place of manufacture. Additional non-limiting examples of delivery unit data may further include one or more of the following: delivery unit configuration data, delivery unit use data, actuator unit compatibility data, a time of fluid injection, and delivery unit function instructional code. Descriptions of exemplary data associated with one or more fluid path elements may be found in U.S. Pat. No. 5,739,508 to Uber which is hereby incorporated by reference in its entirety.
The fluid delivery unit 110 may also be configured to be in reversible mechanical communication with a disposable device. The disposable device may include, as non-limiting examples, one or more of the following: a cannula that may include a needle, a contrast-containing syringe, a pharmaceutical-containing syringe, a cell fluid containing syringe, a gene therapy containing syringe, a flushing-fluid containing syringe, an empty syringe, a high-pressure fluid syringe, a micro-syringe, a transfer tube, a one-way valve, a manually controllable multi-port valve, an automatically controllable multi-port valve, and one or more pieces of tubing or conduit that together may form a fluid path.
The disposable device may also include, as non-limiting examples, one or more of the following: at least one disposable device identification device, at least one disposable device sensor, and at least one disposable device data storage device. The fluid delivery unit 110 may be configured to receive disposable unit data from one or more of the following: a disposable device identification device, a disposable device sensor, and a disposable device data storage device. Non-limiting examples of disposable unit data may further include one or more of the following: disposable identification data, disposable temperature data, disposable pressure data, disposable fluid leak data, and disposable multiple use data.
It may be appreciated that control and/or sensor data transmitted by any of the sensors or function control devices associated with the disposable unit as disclosed above may be received by any one or more of the fluid delivery system components, including without limitation, the fluid delivery unit 110, the fluid actuator unit 120, and/or the control unit 130. Similarly, control and/or sensor data received by any of the sensors or function control devices associated with the disposable unit as disclosed above may be transmitted by any one or more of the fluid delivery system components, including without limitation, the fluid delivery unit 110, fluid actuator unit 120, and/or control unit 130. Similarly, control and/or sensor data received by the fluid delivery unit 110 from any of the sensors or function control devices associated with the disposable unit as disclosed above may be transmitted to any one or more of the remaining fluid delivery system components, including without limitation, the fluid actuator unit 120 and/or control unit 130.
Returning to
The actuator unit data source may provide actuator unit data that may be available to one or more of the fluid delivery unit 110 and the control unit 130. The actuator unit data may include, as non-limiting examples, one or more of the following: activator unit sensor unit data, actuator unit identifier data, and actuator unit data from an actuator unit data storage device. Additionally, the actuator unit data may further include one or more of the following: an actuation unit product ID code, an actuation unit model number, an actuation unit serial number, an actuation unit date of manufacture, a software version identifier, a firmware version identifier, and an actuation unit place of manufacture. The actuator unit data may also include one or more of the following: actuation unit configuration data, actuation unit use data, delivery unit compatibility data, calibration data, operational capability data, and actuation unit function instructional code.
The fluid actuator unit 120 may further be configured to receive delivery unit data from one or more delivery unit data sources. Additionally, the fluid actuator unit 120 may be configured to be in reversible fluid communication with a fluid source.
Although mechanical communication 115 may refer solely to the arrangement of the physical components, it may be understood that the communication may also incorporate data communication between the fluid delivery unit 110 and the fluid actuator unit 120. Such data communication between the fluid delivery unit 110 and the fluid actuator unit 120 may be embodied in the same physical connector as the mechanical communication connector (such as a “plug and play” connection), or the data communication between the two units may be accomplished using one or more separate electrical connectors. In one non-limiting embodiment, the actuator unit 120 and the delivery unit 110 may simply “snap together”. In an alternative non-limiting embodiment, the actuator unit 120 and the delivery unit 110 may additionally be affixed onto a mechanical or electro-mechanical base 105 that may assist in stabilizing the actuator unit and the delivery unit in their functional relationship. It may be appreciated that fluid delivery units 110 and fluid actuator units 120 may be designed specifically for use as part of the fluid delivery system. Alternatively, one or more “translation pods” may permit a commercially available fluid delivery unit 110 or fluid actuator unit 120 to be incorporated into the fluid delivery system. Such “translation pods” may include simple electronic pass-through components to permit data exchange with the control unit 130. Alternatively, the “translation pods” may include microprocessors, non-volatile and volatile storage media and other intelligent electronics along with program instructions to translate instructions issued by the control unit 130 into commands and data native to the commercial fluid delivery units 110 or fluid actuator units 120. The “translation pods” may similarly convert data from the commercial components into data and information readily usable by the control unit 130. Alternatively, a commercially available fluid delivery unit 110 or fluid actuator unit 120 may include the data and interface connections pre-configured to exchange data with control unit 130 without the need for a “translation pod”.
It may be appreciated further that the mechanical communication 115 between the fluid actuator unit 120 and the fluid delivery unit 110 may be reversible. Such a feature may be useful if the fluid actuator unit 120 and/or the fluid delivery unit 110 suffer a failure during use requiring a replacement part to be substituted for the failed unit. A failure condition of the fluid actuator unit 120 and/or the fluid the delivery unit 110 may be communicated to the user by the control unit 130 via any of a number of possible output devices. The failure notification may be based at least in part on mechanical status data received by the control unit 130 from the fluid delivery unit 110 and/or the fluid actuator unit 120. The replacement part for either the fluid deliver unit 110 or fluid actuator unit 120 may be of the same type as the original (failed) unit, or may be of a different type such as an upgraded part.
The fluid delivery unit 110 and the fluid actuator unit 120 may further be in data communication with the controller unit 130. The fluid delivery unit 110 may have a fluid delivery unit communication link 127 with the control unit 130, while the fluid actuator unit 120 may have a separate fluid actuator unit communication link 125 with the control unit. Alternatively, the fluid delivery unit 110 and the fluid actuator unit 120 may communicate with the control unit 130 over the same data communication link. The communication links may be reversible, so that the control unit 130 may both receive data from and transmit data to the fluid delivery unit 110 and/or the fluid actuator unit 120. It may be appreciated that more than a single fluid delivery unit 110 and fluid actuator unit 120 may be associated with the fluid delivery system. As one non-limiting example, a control unit 130 may be in data communication with a plurality of fluid delivery units 110 and associated fluid actuator units 120. Such a configuration may be useful for a veterinary research application in which a number of experimental animals are each infused with one or more medications according to a protocol specifically designed for each animal. The control unit 130 may permit a user to control and monitor each fluid delivery unit 110 separately, and provide information from each combination of a fluid delivery unit 110 and a fluid actuator unit 120.
As disclosed above, the fluid delivery unit 110 may be in reversible communication with a controller unit 130 over a fluid delivery unit communication link 127. Non-limiting examples of data to be communicated may include fluid delivery unit data and/or disposable device data. Similarly, the fluid actuator unit 120 may be in reversible communication with the controller unit 130 over a fluid actuator unit communication link 125. Non-limiting examples of data to be communicated may include actuator and/or control signals to activate the fluid actuator. Some non-limiting examples of such control signals may include one or more of the following: a fluid delivery unit rate signal, a fluid delivery unit volume signal, a fluid delivery unit pressure signal, a fluid delivery unit particle-counting signal, and a fluid delivery unit acceleration/deceleration signal. In addition, the controller unit 130 may receive input data over an input communication link 137 from an input device 140, and provide output data over an output communication link 135 to an output device 150. It may be appreciated that the input device 140 and the output device 150 may be the same physical device. Consequently, the input communication link 137 and the output communication link 135 may be the same physical device.
Control unit 130 may include any number of components. In some non-limiting embodiments, the control unit may include a non-transitory, computer-readable storage medium in operable communication with a computing device. In some embodiments, the control unit 130 may also include the output device 150 in operable communication 135 with the computing device as well as the input device 140 in operable communication 137 with the computing device. Alternatively, one or both of the output device 150 and the input device 140 may be separate devices from the control unit 130. Additionally, the control unit 130 may include any one or more of the following: an internet communication interface, a serial communication interface, a parallel communication interface, a local network interface, a wide range network interface, an optical interface, a wireless communications interface, a gesture-driven interface, a voice-activated interface, and an RF interface. Such communication interfaces may be in communication with, as non-limiting examples, hospital information systems, radiology information systems, imaging systems, workstations, PACS systems, and service or monitoring systems. Non-limiting examples of output devices 150 may include: a computer, a work station, a laptop computer, an iPad, a tablet, a phablet, a Blackberry device, a PDA, and a cellular telephone. Non-limiting examples of input devices 140 may include: a keyboard, a mouse, a joystick, an optical character reader, an RF device interface, a voice recognition interface, a touch screen, and a motion tracking device.
The non-transitory, computer-readable storage medium, in operable communication with a computing device as part of the control unit 130, may contain one or more programming instructions that, when executed, cause the computing device to: receive delivery unit data from the delivery unit data source and actuator unit data from the actuator unit data source; determine a mechanical compatibility status between the fluid delivery unit 110 and the fluid actuator unit 120 based, at least in part, on the delivery unit data and the actuator unit data; transmit, to the output device 150, an output related to the mechanical compatibility status; determine a communication integrity status between two or more of the fluid delivery unit 110, the fluid actuator unit 120, and the control unit 130; and transmit, to the output device 150, an output related to the communication integrity status. In addition, the one or more programming instructions may cause the computing device to transmit, to the output device 150, an output configuration of a graphical display that depends on the output configuration, at least in part, on one or more of the delivery unit data and the actuator unit data. The output display information may be chosen by the control unit 130 from among display data preloaded in the non-transitory memory. In one non-limiting embodiment, the specific display may be based at least in part on the fluid delivery unit data, the disposable data, and/or the fluid actuator data. In another non-limiting embodiment, the specific display may be based at least in part on a procedure entered by the user via the input device 140. Alternatively, a user may choose a specific display from a library of displays. In another embodiment, a user may create a custom display from graphical primitives provided by the control unit 130.
It may be appreciated that the control unit 130 may also receive programming instructions specific to the fluid delivery unit 110 from one or more delivery unit data sources. Similarly, the control unit 130 may receive programming instructions specific to the fluid actuator unit 120 from one or more actuator unit data sources. In yet another alternative, the control unit 130 may receive programming instructions over a communications link from another device including, but not limited to, a computer, a laptop, a tablet, a cell phone, or any other source of electronic data. Additional data related to the fluid delivery unit 110, disposable devices, the fluid actuator unit 120, or any other component of the fluid delivery system may be received by the control unit 130 over a communications link from another device including, but not limited to, a computer, a laptop, a tablet, a cell phone, or any other source of electronic data. Such additional data may include without limitation software or firmware upgrades for any of the fluid delivery system components or information related to user displays.
The computing device, along with its associated volatile and non-volatile storage media, may additionally serve to retain, track, organize, analyze, and log performance and/or activity data from any of the fluid delivery system components. Such performance and/or activity data may be downloaded by a user at the fluid delivery system or remotely. Locally downloaded performance and/or activity data may be presented to the user as part of a user display on the output device 150 or as hard copy. In some embodiments, a user may further enter instructions over the input device 140 or remotely cause the computing device to analyze the performance and/or activity data according to a user directed method. In some non-limiting examples, the computing device may include a library of possible analysis or reporting routines from which the user may choose.
It may be appreciated that control unit 130 may represent a single device or may represent multiple devices among which the various functions of the control unit as previous disclosed may be dispersed. For example, if a standalone fluid delivery system is used as fluid delivery unit 110 and/or a fluid actuating unit 120, the standalone fluid delivery system may already include some internal control functions as well as some user interface and data communication capability. Thus, control unit 130 may include higher level control functions capable of controlling and communicating with such independent units. The functions of control unit 130 may include coordinating the actions of such independent units by receiving from or transmitting to them the data and/or other information to coordinate their activities.
In addition, if the fluid delivery unit 110 and/or fluid actuating unit 120 lack real time or sufficient or continuous safety checks to confirm proper and safe delivery of the fluid to the patient, such safety checks may be included among the functions of the control unit 130 or of the “translation pods.” If the fluid delivery unit 110 and/or fluid actuating unit 120 are incorporated into a base 105, the base may also include one or more safety checking functions. Such safety checking may be performed, for example. by an independent computer system incorporated in the base 105. The base 105 may be adapted to communicate with fluid delivery unit 110, fluid actuating unit 120, and/or the control unit 130. Alternatively, for configurations lacking a base 105, the control unit 130, on detecting unsafe operation during an injection, may instruct the fluid delivery unit 110 and/or fluid actuating unit 120 to stop delivery via electronic or software commands. In one alternative non-limiting example, the control unit 130 may remove power from the one or more failing units so that their operations cease.
The user may place 415 a control unit in reversible data communication with the one or more fluid delivery units and/or actuator units. Again, it may be appreciated that the method and components associated with the communication of data among the fluid delivery unit, the fluid activator unit, and the control unit may allow the data communication to be initiated, maintained, and dissociated. It may be understood that the order of the assembly process is not limiting. In one non-limiting alternative order of steps, the control unit may initially be connected to the delivery unit first, and then the actuator unit may be connected to the delivery unit and the control unit.
Once the three units are connected together, both mechanically and electronically, the control unit may transmit 420 mechanical status data related to the reversible mechanical communication between the fluid actuator unit and the fluid delivery unit to an output device. The control unit may also transmit 425 communication status data to the output device. The communication status data may be related to the reversible data communication between the fluid delivery unit and the control unit, and/or the fluid actuator unit and the control unit.
Given the configurable nature of the fluid delivery system, it may be appreciated that the output transmitted by the control unit related to the mechanical status data may be in a format determined at least in part on (i) fluid delivery unit data received by the control unit and/or (ii) fluid actuator unit data received by the control unit. Thus, as a non-limiting example, a GUI presented by the output device may be determined by the type of fluid delivery unit and/or the actuator unit, indicating status information specific to one or more of the units. Similarly, the output transmitted by the control unit related to communication status data may be in a format determined at least in part on (i) fluid delivery unit data received by the control unit and/or (ii) fluid actuator unit data received by the control unit.
The method may also include a user selecting a disposable unit and placing the disposable unit in reversible mechanical communication and data communication with the fluid delivery unit. Alternatively, the user may place the disposable unit in reversible data communication with the actuator unit or with the control unit. It may further be appreciated that the control unit may transmit to an output unit the mechanical status data related to the reversible mechanical communication between the disposable unit and the fluid delivery unit. In addition, the control unit may transmit to an output unit communication status data related to a reversible data communication between the disposable unit and one or more of the fluid delivery unit, the fluid actuator unit, and the control unit, depending on the unit receiving the communication data from the disposable unit. As one example of the use of the output status data by a user, the mechanical status data displayed on the output unit may indicate a fault in the connectivity between the fluid delivery unit and the actuator unit. As a result, the user may attempt to repair a faulty mechanical connection by altering the connection between the fluid delivery unit and the fluid actuator unit.
The control unit may display 520 a list of possible fluid actuator units to the user according to the chosen procedure. The user may choose an actuator unit and couple it to the fluid delivery unit. The control unit, in data connection with both the installed fluid delivery unit and fluid actuator unit, may receive the fluid delivery unit data and fluid actuator data, to determine if the actuator is appropriate for the delivery unit and is correctly mechanically attached to it. Again, the control may notify 525 the user if the actuator unit is improper or if the mechanical connection between the two units is faulty. It may be understood that the order of attachment of the fluid delivery unit and fluid actuator unit to the base and/or the control unit may be arbitrary.
Once the delivery unit, actuator unit, and control unit are assembled, the system may use the data from the user (type of procedure) and the delivery and actuator units, to display 530 one or more possible pre-programmed fluid delivery protocols. In one embodiment, the user may respond to the protocol prompts generated by the controller and enter 535 one selected from the list. In one alternative embodiment, the user may wish to program a new protocol based on the procedure and assembled components. Such a protocol may be entered by the user into the control unit by means of any of the above disclosed input methods. The control unit may display 540 on the output unit a list of possible disposable units consistent with the procedure, delivery unit, actuator, and protocol information previously provided. The user may attach a disposable unit to the delivery unit. Data from the delivery unit, available to the control unit, may be checked by the control unit for applicability. As previously described, the control unit may notify 545 the user if the disposable unit is inappropriate for the application or if the disposable unit is not in proper mechanical contact with the fluid delivery unit.
At the end of the mechanical and data connection sequence, the control unit may provide a final system-wide check to assure that an appropriate delivery unit, actuator unit, and disposable unit have been chosen by the user and have been correctly assembled. The control unit may notify 550 the user of any mechanical or electronic faults in the completed assembly. After the fluid delivery system has been assembled and tested, the control unit may display 555 an output, such as a GUI, to the user that may be specific to the procedure, components, and protocol as assembled by the user.
As one non-limiting example, the configurable system may be used to assemble a dual-injection device, composed of two syringes, each associated with a syringe drive actuator. Such a dual-syringe system is schematically presented in
A challenge associated with fluid delivery using a flexible injection system of this invention that delivers multiple fluids is that when the system and fluid path is being pressurized during the delivery of a first fluid, that first fluid may drive other fluids in a reverse flow direction, even if their pressurizing means are designed to resist or prevent movement. This reverse flow may be caused by mechanical capacitance, defined as C=V/P. As the capacitance, C, increases, a volume change, V, for a given pressure, P, also increases. Metal components tend to have significantly less capacitance than plastic components. However, many disposable fluid path elements are plastic because of other benefits that plastics may provide. In addition, tubing, syringe barrels, and rubber covers may also have significant capacitance.
In
One embodiment to reduce or essentially eliminate this reverse flow is to include valves 396 and 398. In this embodiment, valves 396 and 398 may be check valves that allow flow in one direction with a relatively low pressure drop. However, when only a partial volume of the syringe or fluid is to be delivered, undesirable behavior may result even with check valves. When the first syringe moves to pressurize the first fluid, a pressure is developed along the fluid path. With check valve 396 in place, the pressure drives little or no fluid into the second line. When the first syringe stops moving, the second syringe may begin to move. When the pressure in the second line becomes greater than the pressure in the first line, fluid may flow through check valve 396. At this point in the delivery, both syringes may be pressurized, but only the second fluid may flow. When fluid delivery is complete and the syringes stop their motion, the pressure may decrease as the fluid exits the disposable unit into the patient. As long as a pressure difference exists, fluid may continue to flow or dribble out of the two syringes into the fluid path and possibly the patient. This additional flow may result from the capacitance of the fluid path elements. Disposable syringes have particularly high capacitance due to the rubber covers. Long lengths of flexible disposable tubing may also have a relatively high capacitance. One solution is to incorporate valves 396 and 398 having a high opening or cracking pressure that may be above or near the maximum operating pressure of the system. One embodiment of such a high cracking pressure valve may include a spool valve having an internal sliding element that can block fluid flow. The valve may include a resistive force element, such as a spring or a pressurized bladder, to resist the movement of the sliding element.
In operation, when the fluid pressure against the sliding element is greater than the force from the force element, the sliding element may move to open an exit segment of the valve, thereby permitting fluid flow. When the pressure against the sliding element drops below the pressure required to counter the force element, the sliding element may return to its original position, thereby preventing fluid flow through the valve. In non-limiting examples, the sliding element may be made of rubber or a thermoplastic elastomer. The force element may be a metal spring or also be an elastomer, which may be manufactured as an integral part of the sliding element.
A second non-limiting embodiment may be composed of a compressible tube and an asymmetric pressure element to compress the tube. The asymmetric pressure element may be designed to compress the tube completely at one segment, compress the tube partially at a second segment, and not compress the tube at a third segment. The force of compression can be created by a variety of methods including, for example, a spring, a bladder, an electromechanical actuator, or a magnetic actuator. As the pressure in the third segment increases, the downward force of the pressure element may be counteracted by the fluid pressure in the second segment. An increase in fluid pressure may result in the force of the pressure element at the first segment being overcome, and fluid may flow through the valve.
In yet another embodiment, valves 396 and 398 may be actively controlled by the control unit by means of control data transmitted by the control unit over lines 397 and 399, respectively. The control unit may adjust the state of either or both of valves 396 and 398 based on data received from one or more pressure sensors associated with the disposable unit. In one non-limiting embodiment, such pressure sensors may be disposed with one upstream of each valve and optionally one downstream of each valve. It may be appreciated that the cracking pressure to open automated control of valves 396 and 398 may be configured by the control unit, and may be adjusted according to the procedure and protocol for which the device may be used. It may be recognized that an actively controlled valve may be controllably opened to relieve the pressure in the syringes when the procedure is completed. Alternatively, pressure can be relieved mechanically if the syringe piston or actuator is moved in the reverse (i.e. non-dispensing) direction. In yet another alternative example, a stopcock or other manually controlled valve may be used to bleed off the pressure. In still another alternative example, the valve 396 may incorporate a mechanical lever, rod, or handle to allow for manual actuation to release the pressure.
In a non-limiting example, a high crack pressure valve may be placed in the fluid path from the fluid delivery unit 110, which may include a bellows or collapsible syringe or container. Descriptions of exemplary collapsible syringes and/or bladders may be found in U.S. Provisional Patent Ser. No. 61/636,049 to Uber et al., U.S. Published Patent Application No. 2012/0209111 to Cowan et al., and PCT Patent Application Serial No. PCT/US2011/57701 to Cowan et al., each of which is hereby incorporated by reference in its entirety. In syringes of this type, the syringe capacitance may be increased as a result of the folds of the bellows or flexibility of the collapsing member or rolling diaphragm. When the bellows syringe is operated at low pressure, the relationship between piston position and output of fluid may have one functional relationship. When the bellows is being maximally compressed by operating with a pressure at or near its maximum capability, the folds may significantly distend or distort before a significant amount of fluid is dispensed. Thus, the relationship between piston position and output of fluid may have a very different functional relationship. For discharge pressures that are intermediate between these two, the amount of collapse may be intermediate and the functional relationship between piston position and output of fluid will have a different functional relationship as well. It may be difficult to accurately or reproducibly determine the relationship between the amount of motion of the syringe plunger and the amount of fluid delivered. Accurate and consistent control of fluid delivery may require a consistent relationship between piston or pump motion and fluid volume delivery. If the syringe discharges the fluid through a high crack pressure check valve, the pressure on the fluid container may be repeatable and known. Thus, a known relationship between piston or pump motion and fluid volume may be used by the controller unit 130 to accurately and consistently provide the desired fluid delivery.
A first embodiment of a high crack pressure check valve, such as valve 396 in
In operation, when the pressure in segment 611 reaches a value of P-open, the force on the slide 613, due to the fluid pressure being greater than the force from the force element 615, may cause the slider to move to the left, opening the exit segment 612 and allowing fluid to flow through the valve. When the pressure in segment 611 drops below P-open, the slider may move to the right and fluid flow out of or into segment 611 may be prevented.
In the case where this valve is used in a medical device, the fluid path elements may be made from plastic, such as polycarbonate or PVC. The slider 613 may be made of rubber or a thermoplastic elastomer. The force element 615 may include a metal spring or an elastomer, or optionally made as an integral part of the slider 613. For use in sterile situations, this design may require that all the elements that contact the fluid be sterilized or be disposable.
A second embodiment of a high crack pressure check valve, such as valve 396 in
In this second embodiment, there may be a segment 701d, which may be on the outflow side and may also be partially compressed by pressure element 703, due to the stiffness and shape of the tube. Thus there may be a small force on pressure element 703 produced by pressure in tube segment 701d. If the area of segment 701d is much less than the area of segment 701b, the effect of this non-ideal situation can be minimized or made insignificant.
In another non-limiting example, an inline high crack pressure valve may be used with a pulsatile pump such as a diaphragm or peristaltic pump. Accumulators, for example, a spring or pressure biased reservoir, can be placed on the output of such pumps to attempt to smooth the flow, but accumulators may operate effectively only within a limited pressure range. By placing a high crack pressure valve downstream of the accumulator, the accumulator may consistently operate at a pressure in the same range as the high crack pressure valve, independent of the downstream pressure fluctuations. As a result, potential oscillations in fluid flow due to the operation of the pump may be damped. The respective pressure ranges of the accumulator and the high crack pressure valve, in addition to the accumulator volume, may depend at least in part on the operating pressure of the pump, the specifics of the fluid path, the fluid volumes and flow rates for delivery, and the pump output pulsatility. Additionally, a high crack pressure valve may be as useful with single fluid delivery devices as with multiple fluid delivery devices.
In some situations, such as CT contrast delivery, the pressure developed by the pumps during normal injections can approach or exceed 300 psi. In such cases, an opening or crack pressure may be about 350 psi or more. In angiography, an opening or crack pressure may be over 1000 psi. In alternative procedures, such as a fluid injection into a mouse, the injected volume may be small, on the order of 50 microliters, and the injection pressures involved may be on the order of 10's of psi. Therefore, for procedures using small animals, a crack pressure of 50 psi or even 20 psi may be sufficient. In one non-limiting example, each application may have associated with it a specific high pressure crack valve having a set and procedure specific P-open. In an alternative non-limiting example, a single high pressure crack valve having an adjustable P-open pressure may be used among a variety of procedures. One embodiment of an adjustable high pressure crack valve may include a user-adjustable screw to compress a spring. In another embodiment of an adjustable high pressure crack valve, an adjustable electromechanical actuator may be used to apply the variable clamping force. Such automated adjustable high pressure crack valves may be useful for real time modification by the system controller. In one non-limiting example, the control unit may alter the variable clamping force based at least in part upon data received by the control unit from one or more pressure sensors in the system.
The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated in this disclosure, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is also to be understood that the terminology used in this disclosure is for the purpose of describing particular embodiments only, and is not intended to be limiting.
With respect to the use of substantially any plural and/or singular terms in this disclosure, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth in this disclosure for sake of clarity.
It will be understood by those within the art that, in general, terms used in this disclosure, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). While various compositions, methods, and devices are described in terms of “comprising” various components or steps (interpreted as meaning “including, but not limited to”), the compositions, methods, and devices can also “consist essentially of” or “consist of” the various components and steps, and such terminology should be interpreted as defining essentially closed-member groups.
It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.”
From the foregoing, it will be appreciated that various embodiments of the present disclosure have been described for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various embodiments disclosed are not intended to be limiting, with the true scope and spirit being indicated by the following claims.
