INTRAVASCULAR BLOOD PUMPS AND CONTROL THEREOF
20230166096 · 2023-06-01
Inventors
- Adnan Merchant (Fremont, CA)
- Ari RYAN (Sunnyvale, CA, US)
- Joshua WALLIN (San Jose, CA, US)
- Gerald LYONS (Saratoga, CA, US)
- Daniel VARGHAI (Campbell, CA, US)
Cpc classification
A61M60/13
HUMAN NECESSITIES
International classification
A61M60/13
HUMAN NECESSITIES
Abstract
Intravascular blood pump systems that include a catheter assembly and an external console assembly. The catheter assembly may be in one or more of fluidic or electrical communication. The catheter assembly may include a controller with an executable method stored therein, wherein the executable method may be configured to receive sensed information that is indicative of a sensed characteristic of fluid in a fluid pathway, at least a portion of the fluid pathway disposed within the catheter assembly, and cause an alert if any of the sensed information is indicative that the external console assembly is not functioning properly.
Claims
1-24. (canceled)
25. An intravascular blood pump system, comprising: a catheter assembly including, a handle portion, a catheter portion extending distally from the handle portion, and a pump portion disposed at a distal end of the catheter portion; and an external console assembly, the catheter assembly and the external console assembly adapted and configured to be put into fluidic communication, the handle portion sized and configured to be held by a user, the handle portion comprising a controller with an executable method stored therein, the executable method configured to receive sensed information that is indicative of a sensed characteristic of fluid in a fluid pathway, at least a portion of the fluid pathway disposed within the catheter assembly, and cause an alert if any of the sensed information is indicative that the external console assembly is not functioning properly.
26. The system of claim 25, further comprising a pressure sensor disposed in the fluid pathway, the sensed characteristic indicative of fluid pressure in the fluid pathway.
27. The system of claim 26, wherein the pressure sensor is disposed within the external console assembly.
28. The system of claim 26, wherein the pressure sensor is disposed within the catheter assembly.
29. The system of claim 28, wherein the pressure sensor is disposed within the handle portion.
30. The system of claim 28, wherein the pressure sensor is disposed within the catheter portion.
31. The system of claim 25, wherein the fluid pathway is a clean purge fluid pathway.
32. The system of claim 25, wherein the fluid pathway is a return fluid pathway.
33. The system of claim 25, wherein the fluid pathway is a sheath fluid pathway that includes a section disposed between an outer axially movable sheath and an outer surface of an inner catheter shaft.
34. The system of claim 25, further comprising a fluid pump in the external console assembly, the fluid pump adapted and positioned to pump fluid in the fluid pathway, wherein the executable method is configured to cause an alert if the fluid pump is not functioning properly.
35. The system of claim 34, wherein the fluid pump is adapted and positioned to pump fluid in a clean purge fluid pathway.
36. The system of claim 34, wherein the fluid pump is adapted and positioned to pump fluid in a sheath fluid pathway that includes a section between an outer sheath and an outer surface of a catheter shaft of the catheter portion.
37. The system of claim 25, wherein receiving sensed information that is indicative of a sensed characteristic of fluid in a fluid pathway comprises receiving sensed information that is indicative of a sensed fluid pressure amplitude.
38. The system of claim 25, wherein receiving sensed information that is indicative of a sensed characteristic of fluid in a fluid pathway comprises receiving sensed information that is indicative of a sensed fluid pressure waveform over time.
39. The system of claim 25, wherein the handle portion comprises an indicator that is adapted to communicate the alert.
40. The system of claim 25, wherein the external console assembly comprises an indicator that is adapted to communicate the alert.
41. The system of claim 25, wherein the causing step comprises comparing the sensed information to stored information that is stored in the controller, and initiating an output based on the result of the comparing step.
42. The system of claim 41, wherein the stored information is indicative of a stored sensed pressure amplitude.
43. The system of claim 41, wherein the stored information is indicative of a stored pressure waveform over time.
44. The system of claim 41, wherein the stored information is indicative of a fluid pressure threshold.
45. The system of claim 44, wherein the stored information is indicative of a low fluid pressure threshold or a high fluid pressure threshold.
46. The system of claim 25, wherein the external console assembly comprises an operating system adapted to be in direct or indirect control one or more fluid pumps in the external console assembly, one of the one or more pumps positioned and adapted to pump fluid in the pathway.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0009]
[0010]
[0011]
[0012]
[0013]
[0014]
[0015]
[0016]
[0017]
[0018]
[0019]
[0020]
DETAILED DESCRIPTION
[0021]
[0022] In some embodiments, risk mitigation may be accomplished by performing one or more actions with the intravascular blood pump. For example, without limitation, a controller or control unit disposed in, on, or otherwise carried by the intravascular blood pump (e.g., within a handle portion thereof) may be configured to receive information and perform one or more actions or events in response to the received information. A controller herein may comprise any number of software and/or hardware components alone or together that are associated with one or more components of the intravascular blood pump.
[0023] An exemplary benefit of exemplary systems herein in which one or more aspects of system monitoring or control are not under direct control of software or firmware controlling the external console (e.g., not controlled by an OS on the console) is that it is possible for the system to be able check or verify that the one or more aspects of the system are functioning properly when a part of the system that controls the aspect has stopped performing optimally or stopped functioning altogether (e.g., an OS on the console crashes). This may generally be referred to herein as being adapted to provide risk mitigation. For example, if software on the console (e.g., an OS) stops functioning, it may prevent one or more applications stored on the console from functioning. In some particular embodiments, an application on the console may be in control of hardware associated with the console (e.g., a peristaltic pump(s), a flow regulator(s), a valve), and if the console cannot control the application, the console may be unable to control the hardware on the console. Additionally, it may not be apparent to a user that control of the system component has stopped or become intermittent, which may create a serious risk to the patient's health. Some aspects of the systems herein provide risk mitigation by providing a different part of the system that can initiate (or cause) an output if there is an indication that part of the system is not performing as intended. There are a variety of ways in which to implement the risk mitigating functionality described herein.
[0024]
[0025]
[0026]
[0027]
[0028] Depending on the particular design of the catheter portion, the catheter portion may include one or more fluid pathways to facilitate fluid flow in and through one or more annular spaces between components of the catheter portion 3608. For example, clean fluid (e.g., clean saline) may flow (e.g., by being pumped with a pump in the external console assembly) toward the blood pump 3602 via a sheath fluid pathway 3630 between the sheath 3626 and an outer surface of catheter shaft 3624. Fluid flow through the sheath fluid pathway 3630 may prevent blood from stagnating and forming clots in the annular space between the sheath 3626 and the catheter shaft 3624 at a distal end of the sheath 3626. Fluid from the sheath fluid pathway 3630 may enter the patient's body with no substantial return fluid pathway. Clean purge fluid (e.g., saline pumped from a saline bag disposed outside the patient) may also flow (e.g., by being pumped) toward the blood pump 3602 via a catheter clean fluid pathway 3632 between the catheter shaft 3624 and the driveshaft tube 3622. Some or all of the fluid in the catheter clean fluid pathway 3632 may return from the blood pump 3602 via a return fluid pathway 3634 (which may be referred to in any embodiment herein as a waste fluid pathway). Flowing fluid through the catheter fluid pathway 3632 and return fluid pathway 3634 may cool and/or lubricate moving components (e.g., the rotating driveshaft 3620 and bearings) within the blood pump 3602. The catheter clean fluid pathway 3632 and return fluid pathway 3634 may flush and keep possible debris (e.g., from wear of rotating components) from entering the patient's body. In some examples, where a wall of the driveshaft 3620 has some porosity, fluid within the return fluid pathway 3634 may passively enter the inner lumen of the driveshaft 3620.
[0029] In any of the embodiments herein, a driveshaft, a driveshaft tube, a catheter shaft and optionally an outer sheath may all be co-axial.
[0030] Optionally, clean fluid for the sheath fluid pathway 3630 and the catheter fluid pathway 3632 may be provided by a console 3606, which may include one or more clean fluid sources (e.g., saline bags) and a pump assembly (e.g., peristaltic pump assembly) for moving clean fluid distally toward the blood pump 3602. In some examples, the clean fluid may be provided to the catheter portion 3608 through a catheter fluid inlet and a sheath fluid inlet between the motor assembly 3604 and the blood pump 3602. In some cases, one or both of the catheter fluid inlet and the sheath fluid inlet are part of (or connected to) the motor assembly 3604. In some examples, the return fluid pathway 3634 may flow through a motor assembly (not shown) and toward a waste reservoir, which optionally may be connected to (or part of) such as by being secured to, a console assembly.
[0031] Any controller or control unit herein (e.g., the controller shown in
[0032] In some particular exemplary embodiments, the blood pump systems are adapted with risk mitigation functionality to detect if one or more aspects of the console is not performing as intended. For example, some systems may be adapted to determine if fluid (e.g., clean fluid, return fluid, sheath fluid) is not flowing in a fluid pathway as intended or desired, or there is otherwise some problem with the fluid pathway. In some embodiments, the system is adapted to create or cause an output or alert or notification if fluid is not being controlled in a desired or intended manner. For example without limitation, some systems may include a fluid return pathway from the intravascular blood pump, the pathway including one or more fluid lines. An exemplary fluid pathway may be a purge fluid return pathway or a clean purge pathway, and in the case of a return pathway, at least a portion of purge fluid that is delivered to the blood pump moves away from the blood pump after passing through at least a portion of the blood pump. By way of example only, a system may include or more features that are adapted to modify flow in a fluid pathway, such as from switching from fluid flow to no fluid flow. Exemplary features in this regard include software on the console and/or hardware on the console such as a peristaltic pump.
[0033] In an exemplary implementation of
[0034] In some embodiments of the system, one or more sensors (e.g., pressure sensors, flow sensors) are in communication (directly or indirectly) with the blood pump controller. For example, without limitation, the controller may be in communication with one or more sensors that provide information indicative of one or more sensed characteristics of fluid in a fluid pathway extending from the handle (such as any of the pathways shown in
[0035]
[0036] In some implementations, the blood pump system may be adapted to cause or initiate an output when received information indicates that one or more sensed characteristics of fluid in a fluid path (e.g., clean purge fluid, return fluid, sheath fluid, etc.) is indicative of a fluid path flow regulator that is not functioning properly. Malfunctioning as described here may be due to hardware error, such as a pump that is no longer working and/or a software error, such as a console operating system error. In some implementations, the system is adapted to create an output (e.g., an output from an algorithm) if an aspect of flow in a fluid pathway is not, or diverges from, an expected aspect of the flow. In some implementations, the system is adapted to create an output if an aspect of flow changes from a current state to a different state. Fluid flows aspects, or characteristics, that may be indicative of a problem include information indicative of, but are not limited to, a flow rate amplitude (an example of which is shown in
[0037] In exemplary particular risk mitigation implementations, the system may alternatively or in addition to, be adapted to cause or create an output (e.g., from an algorithm) if an aspect of fluid pressure in one or more fluid pathways (e.g., purge fluid return) is not, or diverges from, an expected aspect (e.g., stored in memory) of the flow. In some implementations, the system is adapted to create an output if an aspect of fluid pressure changes from a current state to a different state. Fluid pressure aspects, or characteristics, that may be indicative of a problem include information indicative of, but are not limited to, a pressure amplitude (e.g., as shown in
[0038] An exemplary additional advantage of some of the methods herein that receive information indicative of sensed information is that the methods may ease the burden on accuracy requirements of one or more sensors. For example, the methods herein can be adapted to determine if sensed signals are within an expected window, which may be easier to implement than if looking for sensed signals at more discrete values.
[0039] Any of the characteristics of fluid herein (which includes information that is indicative of the fluid characteristics), such as fluid flow characteristics and fluid pressure characteristics may be stored in one or more system memory units that are outside of the direct control of the external console. In some implementations, the stored characteristics may be stored in a blood pump controller, such as the controller associated with the blood pump handle shown in
[0040] The exemplary ways in which the systems herein are adapted to determine if one or more aspects of fluid are not, or if they diverge from, an expected aspect of fluid flow or fluid pressure are exemplary and do not limit the general concepts and processes herein.
[0041]
[0042] In any of the embodiments herein, the return fluid pathway or line may also include one or more of pressure sensor(s) or flow sensor(s) at any location(s) along the fluid pathway to sense a characteristic of fluid in the line, the sensed information from which may be communicated to a controller in the handle as is described in more detail herein. Any of the sensors herein may be in electrical communication (directly or indirectly) with the blood pump controller. Fluid cable or connect 408 may be connected with the cassette 404 before or after cassette 404 in engaged and secured to the external console.
[0043] One of the optionally three catheter assembly input lines shown to the left in
[0044] Optional flow regulator 428 may be, or may be part of, a pulsatile pump to provide flow, and may be driven by a stepper motor in the external console (not shown). The pump may optionally be adapted to operate at one or more fixed speeds, with or without a speed feedback loop. Optional pressure sensor 420 may be configured to detect one or more of fluid pathway blockages, overpressure conditions, or underpressure conditions that may be indicative of a leak in the fluid pathway.
[0045]
[0046]
[0047] In some exemplary embodiments, a blood pump controller (an example of which is shown in
[0048] The risk mitigation benefits herein may include the system performing or taking one or more actions if there is an indication that one or more sensed characteristics of fluid in a fluid path indicate that an aspect of an external console is not functioning properly (i.e., a triggering event). For example, an action may be performed if there is an indication that a fluid flow controller in an external console is not functioning properly, such as a fluid flow controller that is adapted to control or cause fluid flow through one or more fluid pathways herein.
[0049] In some embodiments, the action may include an output generated by a process such as an algorithm (e.g., firmware, software, etc.). The action may include providing or causing an alert that can provide an indication that one or more aspects of the external console assembly (e.g., one or more of software, firmware, or hardware) is not functioning properly. For example, a blood pump controller (an example of which is shown in
[0050] In some embodiments, an alert or notification may be provided by the blood pump. For example, the blood pump may include any number of indicators that are adapted to provide an indication of the detected event. In some exemplary embodiments the blood pump may include any number of visual indicators (e.g., lights, such as LED(s), audible indicators (e.g., a sound such as a beep), and/or tactile indicators (e.g., vibratory) that are adapted to provide or indicate a notification or alert. In some embodiments, the blood pump is adapted to initiate a communication to an external device (e.g., an external console) to provide alert of the detected event. Any communications between the blood pump and the console may be wired or wireless.
[0051] The external console may be adapted to provide a notification or alert of the event. For example, an aspect of the console outside of the control of the operating system may be configured to provide a notification of the event, such as any of the indicators herein: visual (e.g., on a display, LED); audio (e.g., a sound), tactile (e.g., vibration), etc.
[0052]
[0053] The blood pump may include one or more pressure sensors that are adapted to sense pressure at one or locations in the intravascular blood pump. For example, a pump portion of the blood pump may include one or more pressure sensors, such as at or adjacent to one or both of an inflow and/or an outflow. One or more pump portion pressure sensors are generally indicated by the pressure sensor on the right in
[0054] Any of the pressure sensors herein may be in wired communication with a controller, or any of the pressure sensors herein may be in wireless communication with a controller.
[0055] In some exemplary implementations, an external console and a catheter assembly may be put into operable communication with each other (e.g., as shown in
[0056] In any of the embodiments herein, the blood pump controller may be adapted to receive and utilize information indicative of both fluid flow and/or fluid pressure. For example, in some merely exemplary embodiments, the controller may receive information indicative of sensed fluid flow and sensed fluid pressure, and compare the information with stored information indicative of flow and pressure, such as without limitation, indicative of one or more of expected amplitude, expected duration of a phase, etc.
[0057] Any of the processes or systems herein may include an intravascular blood pump with one or more processes initially stored in a blood pump controller. For example, a blood pump may include a controller with firmware on which one or more process are stored, such as for example without limitation, a timing protocol for hardware control, such as a flow regulator (e.g., a pump, a switch). After the blood pump and external console are put in operable communication, information (e.g., one or more algorithms) may be communicated from the catheter assembly and stored on the external console. The console may then have stored thereon one or more processes to control one or more hardware features on the console (e.g., one or more peristaltic pumps).
[0058] In some instances, one or more blood pumps may have different operating conditions stored thereon in one or more memory units. The operating conditions may be stored in the blood pump prior to being put into operable communication with the console, such as when a microcontroller with firmware stored thereon is coupled to electronics of a blood pump. For example, a first blood pump may have operating conditions stored thereon that are different than one or more operating conditions of a second blood pump (or second type of blood pump). Blood pumps with different operating conditions may have one or differences, such as without limitation, number of impellers, expanded diameter size, fluid conduit length, application, etc. Operating conditions that may be different for different blood pumps may include any of, for example without limitation, expected characteristics of flow, expected characteristics of pressure, operating conditions of hardware on an external console (e.g., peristaltic pumps, flow regulator(s)) operating conditions of hardware on the blood pump (e.g., motor). Implementations that include one or more blood pump characteristics stored on the blood pump that are communicated to an external console once coupled together provides for the benefit of being able to communicate any number of protocols or procedures to the external console for any number of blood pumps, and once communicated the console may then be able to control one or more console features in a manner that may be specific to the blood pump, patient, application, setting, etc. For example, there may be several different blood pump models, each of which may have different timing information. Passing (optionally automatically) this information from the blood pump to the console may allow the console to know to which blood pump it is connected/talking to.
[0059]
[0060] One optional aspect of the disclosure may be related to preventing blood from entering the catheter and/or contacting the drive assembly. In some implementations the aspect can use the delivery of purge fluid through the blood pump to prevent blood from entering into one or more spaces in the blood pump (other than through the fluid conduit, through which blood is pumped). That is, purge fluid can be pumped through and out of the catheter to prevent blood from entering into one or more purge fluid paths. In some illustrative examples, the pump portion includes one or more pressure sensors (e.g., one or both of an inflow and outflow sensors), schematically illustrated in
[0061] In any of the embodiments herein, a flow regulator in the console may be any type of suitable flow regulator. In
[0062] The disclosure herein describes exemplary systems in which a blood pump may receive sensed information and may utilize that in risk mitigation processes. In some more generalized implementations, a blood pump may expect to receive information from an external console, and if that information is not received, it may indicate that one or more functions of the console are not functioning properly. For example, a blood pump controller may be adapted to expect a periodic signal/communication from an external console. If the controller does not receive the signal/communication as or when expected, the controller may then provide an output (such as any of those herein) that causes any number of actions to take place that indicate the discrepancy.
[0063] Even if not specifically indicated, one or more techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware or any combination thereof. For example, various aspects of the techniques or components may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programmable logic circuitry, or the like, either alone or in any suitable combination. The term “processor,” “controller,” “control unit,” or derivatives thereof may generally refer to any of the foregoing circuitry, alone or in combination with other circuitry, or any other equivalent circuitry.
[0064] Such hardware, software, or firmware may be implemented within the same device or within separate devices to support various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components.
[0065] When implemented in software, functionality ascribed to systems, devices and techniques described in this disclosure may be embodied as instructions on a computer-readable medium such as random access memory (RAM), read only memory (ROM), non-volatile RAM (NVRAM), electrically erasable programmable ROM (EEPROM), Flash memory, and the like. The instructions may be executed by a processor to support one or more aspects of functionality described in this disclosure.
[0066] The Detailed Description includes an Appendix section. Any suitable aspect of the Detailed Description included in either the Appendix portion or the non-Appendix portion may be incorporated with aspects of the other portion of the Detailed Description, including without limitation devices, components, parts, portions, and method steps including methods of deployment and use. For example, any of the exemplary pump portions in the Appendix section may also include any suitable aspect described in the non-Appendix portion, such as, without limitation, methods executable by a processor. Reference numbers or figures in the non-Appendix portion of the Detailed Description figures, even if they are duplicative of reference numbers or figures in the Appendix section, are understood to apply to the non-Appendix section of the Detailed Description.