Patent Description:
Document <CIT>, which is deemed to represent the closest prior art, discloses a user interface to navigate a cardiac catheter during a surgery. This document is however silent about the definition of the user input, in particular of the localization of said input on the handle of the catheter.

The present disclosure is generally directed to devices, systems, and methods of facilitating a physician's interactions with a graphical user interface associated with a medical procedure being performed by the physician. For example, the devices, systems, and methods of the present disclosure can facilitate the physician's ability to modify a representation of a three-dimensional model on the graphical user interface autonomously (e.g., without assistance from a second person), without interfering with the physician's ability to control the catheter during the medical procedure. By way of non-limiting example and for the sake of clarity of explanation, the devices, systems, and methods of the present disclosure are described with respect to the use of a catheter in a heart cavity of a patient during a medical procedure (e.g., cardiac ablation). However, it should be appreciated that, unless otherwise specified or made clear from the context, the systems and methods of the present disclosure can be used for any of various different medical procedures in which it is desirable for a physician to interact with a graphical user interface autonomously while simultaneously maintaining control over the medical device used as part of the medical procedure.

As used herein, the term "physician" should be considered to include any type of medical personnel who may be directly interacting with a catheter as part of a medical procedure and is used interchangeably herein with the term "user. " The term "treatment" should be considered to include any manner and type of medical procedure involving the use of a catheter and, therefore, should be considered to include diagnosis, treatment, and combinations thereof, unless otherwise specified or made clear from the context.

In the following description, it is understood that terms such as "first," "second," "top," "bottom," "up," "down," "right," "left," and the like, are words of convenience and are not to be construed as limiting terms.

<FIG> is a schematic representation of a system <NUM> during a cardiac treatment (e.g., an ablation treatment) performed on a patient <NUM>. The system <NUM> can include a catheter interface unit <NUM> in communication (e.g., wired or wireless communication) with a catheter <NUM>, a first input device <NUM>, and a second input device <NUM>. For example, the catheter interface unit <NUM> can be in communication with the catheter <NUM> via an extension cable <NUM> and, additionally or alternatively, in wireless communication with one or more of the first input device <NUM> and the second input device <NUM>. The catheter interface unit <NUM> can include a processing unit <NUM>, a non-transitory, computer readable storage medium <NUM>, and a graphical user interface <NUM>. The processing unit <NUM> can be a controller including one or more processors, and the storage medium <NUM> can have stored thereon computer executable instructions for causing the one or more processors of the processing unit <NUM> to carry out one or more of the various methods described herein. In certain implementations, the catheter interface unit <NUM> can include additional features, including, without limitation, one or more of the following: current generation; magnetic field generation; magnetic field sensing, and the like.

The first input device <NUM> can be a computer (e.g.. , a desktop computer, a laptop computer, or both), or other, similar input device. The first input device <NUM> can be operated, for example, by a technician outside of a sterile field, while the second input device <NUM> can include a simple interface suitable for operation by the physician within the sterile field. As described in greater detail below, the catheter interface unit <NUM> can receive one or more input commands from the first input device <NUM> and from the second input device <NUM>, in response to respective input options on the graphical user interface <NUM>. Based on the received one or more input commands, the catheter interface unit <NUM> can modify a three-dimensional model of a heart cavity of the patient <NUM> displayed on the graphical user interface <NUM>.

The input options available to be controlled by the second input device <NUM> on the graphical user interface <NUM> can be state-dependent, as also described in greater detail below, such that the second input device <NUM> can be used to interact extensively with the graphical user interface <NUM> through the use of only a few input sources (e.g., buttons) on the second input device <NUM>. That is, the input options corresponding to the input sources on the second input device <NUM> at any given time during a medical procedure can be displayed on the graphical user interface <NUM>. Advantageously, as also described in greater detail below, these input options can change according to a state of a state machine, which itself can change according to context (e.g., based on one or more previous actions, a current state, or a combination of both) and/or inputs. Thus, for example, the meaning of pressing a particular input source (e.g., pressing an "up" button) can change based on the state of the state machine, and the meaning of the particular input source at any given time can be displayed to the physician via the graphical user interface <NUM>. Accordingly, as compared to systems in which controller actions are displayed on a handle of a device or on the controller itself and/or are otherwise fixed, the dynamic interaction between the second input device <NUM> and the graphical user interface <NUM> can facilitate the use of the state machine which, in turn, can facilitate achieving a given level of control over the graphical user interface <NUM> using fewer input sources on the second input device <NUM>. With fewer input sources, the second input device <NUM> can be made into a form factor suitable for integration into a medical device such as the catheter <NUM>, as described in further detail below.

It should be appreciated that, in implementations in which the second input device <NUM> includes only a few input sources, a physician can use the second input device <NUM> to interact with the graphical user interface <NUM> while maintaining control over the catheter <NUM> during the medical procedure and, thus, while remaining in a sterile field. In such implementations, it should be further appreciated that the limited number of input sources on the second input device <NUM> can make it easier for the physician to use the second input device <NUM> to interact with the graphical user interface <NUM> with less of a need to switch focus between the graphical user interface <NUM> and the second input device <NUM>. Thus, for example, because the second input device <NUM> includes only a few input sources, the physician has less of a need to look at the second input device <NUM> during operation of the second input device <NUM>. For at least this reason, the simplified inputs of the second input device <NUM> can facilitate continuous manipulation of the catheter <NUM> by the physician, particularly in instances in which the physician must look at the graphical user interface <NUM> to manipulate the catheter <NUM> during a medical procedure.

Referring now to <FIG> and <FIG>, the catheter <NUM> can include a catheter shaft <NUM>, a handle portion <NUM>, and a tip portion <NUM>. The catheter shaft <NUM> includes a proximal end region <NUM> and a distal end region <NUM>. The handle portion <NUM> is coupled to the proximal end region <NUM> and the tip portion <NUM> is coupled to the distal end region <NUM>. The second input device <NUM> can be coupled to the handle portion <NUM> and can communicate with the graphical user interface <NUM> such that the second input device <NUM> should be understood to be a graphical user interface (GUI) controller according to all aspects of the present disclosure. An articulation controller <NUM> can also, or instead, be supported on the handle portion <NUM>. Thus, as described in greater detail below, the second input device <NUM> can be operated to communicate with the catheter interface unit <NUM> (e.g., with the processing unit <NUM>) such that commands received by the catheter interface unit <NUM> from the second input device <NUM> can form the basis of one or more changes to a three-dimensional model of a heart cavity of the patient <NUM> displayed on the graphical user interface <NUM> while the articulation controller <NUM> can be operated to move the tip portion <NUM> of the catheter <NUM> in the heart cavity.

The second input device <NUM> can be in remote communication with the graphical user interface <NUM> and, for example, can include a transmitter (e.g., a wired transmitter, a wireless transmitter, or both) for such remote communication. In implementations in which the second input device <NUM> includes a wired transmitter, communication between the second input device <NUM> and the catheter interface unit <NUM> can be via wires <NUM> extending from the catheter <NUM> to the catheter interface unit <NUM>. In addition, or in the alternative, in implementations in which the second input device <NUM> includes a wireless transmitter, communication between the second input device <NUM> and the catheter interface unit <NUM> can include communication via any of various different known wireless communication protocols. An example of such a wireless communication protocol is Bluetooth®, a wireless standard available from Bluetooth SIG, Inc. While a standardized communication protocol, such as Bluetooth®, may be useful for pairing off-the-shelf hardware components, it should be appreciated that a customized communication protocol can be useful for avoiding interference with the communication between the second input device <NUM> and the catheter interface unit <NUM>.

The form factor of the second input device <NUM> can be based on one or more of the size of the handle portion <NUM> and the orientation of the second input device <NUM> relative to the articulation controller <NUM>. Thus, a small form factor of the second input device <NUM> can be desirable for sizing the handle portion <NUM>, for example, for ease of operation by the physician (e.g., one-handed operation). To achieve a small form factor, the second input device <NUM> can include a small number of input options (e.g., less than ten) arranged relative to one another in a space-efficient and, or instead, intuitive manner. Additionally, or alternatively, it can be desirable to include a small number of input options on the second input device <NUM> to provide a simple interface that can be operated by the physician with little to no need for the physician's attention to move back and forth from the graphical user interface <NUM> to the second input device <NUM>. That is, the simple interface provided by the second input device <NUM> can, in certain instances, be used by the physician without requiring the physician to look at the second input device <NUM>, making it easier for the physician's attention to remain on the graphical user interface <NUM> during a medical procedure. It should be appreciated, however, that providing a physician with access to a diverse set of actions on the graphical user interface <NUM> can additionally, or alternatively, be desirable. To manage these competing design considerations, as described in greater detail below, the simple interface of the second input device <NUM> can cooperate with the graphical user interface <NUM> to provide the physician with state-dependent functionality, on the graphical user interface <NUM>, which can be both useful for a given state of the medical procedure and easily navigated using the small number of inputs on the second input device <NUM>.

The second input device <NUM> can include inputs 130a, 130b, 130c, 130d, 130e spatially arranged relative to one another to facilitate intuitive navigation, using the second input device <NUM>, through one or more menus on the graphical user interface <NUM>. The inputs 130a, 130b, 130c, 130d, can be discrete navigation inputs separate from one another. Thus, by way of non-limiting example, the navigation inputs 130a, 130b, 130c, 130d can be arranged in a right (130a), left (130b), up (130c), and down (130d) configuration relative to one another such that pressing the right navigation input 130a corresponds to navigation to the right in a menu displayed on the graphical user interface <NUM>, pressing the left navigation input 130b corresponds to navigation to the left in a menu displayed on the graphical user interface <NUM>, etc. Additionally, or alternatively, the input 130e can be an "enter" input and can be arranged, for example, substantially in the middle of the navigation inputs 130a, 130b, 130c, 130d. Further in addition, or further in the alternative, the press time and/or number of presses (e.g., single click versus double click) associated with pressing one or more of the inputs 130a, 130b, 130c, 130d, and 130e can be used to achieve further functionality of the second input device <NUM> using a limited number of inputs. For example, a long press time of one or more of the inputs 130a, 130b, 130c, 130d, and 130e can change a high level state of the state machine controlled by the second input device <NUM> while a short press time of one or more of the inputs 130a, 130b, 130c, 130d, and 130e can scroll through a lower level state of the state machine controlled by the second input device <NUM>.

The navigation inputs 130a, 130b, 130c, 130d can be, in certain instances, buttons that are pressed to provide input to the second input device <NUM>. Additionally, or alternatively, the second input device <NUM> can include a capacitive touch portion such that, for example, a sliding motion (e.g., of a finger) across the capacitive touch portion can be a navigation input transmitted by the second input device <NUM> to the graphical user interface <NUM>. The capacitive touch portion can be arranged, in certain instances, as a circle such that a sliding motion detected around the circle is interpreted as a navigation input corresponding to scrolling (e.g., through a menu on the graphical user interface <NUM>). Additionally, or alternatively, the capacitive touch portion can include any one or more of the inputs 130a, 130b, 130c, 130d, 130e. More generally, the inputs 130a, 130b, 130c, 130d, 130e can be any of various different types, alone or in combination with one another and can, in addition or optionally, be of any number useful for navigating through one or more menus displayed on the graphical user interface <NUM>.

In some implementations, a combination of the number, size, and shape of the inputs 130a, 130b, 130c, 130d, 130e is such that the user can distinguish the buttons by feel. For example, given that the inputs 130a, 130b, 130c, 130d, 130e are in a constant position relative to one another and in a relatively constant position with respect to an axis defined by the catheter <NUM> (e.g., with respect to an axis defined by the catheter shaft <NUM>). Accordingly, the inputs 130c and 130d are typically to the physician's right and left as the physician grips the handle <NUM>. The inputs 130a and 130b can be in similarly predictable positions with respect to the physician's hand, given that the inputs 130a and 130b are in a fixed positon relative to the inputs 130c and 130d.

In certain implementations, the second input device <NUM> can include an orientation feature <NUM> extending from a surface of the second input device <NUM>. For example, the orientation feature <NUM> can extend from a surface of the up navigation input 130c. The orientation feature <NUM> can provide tactile feedback to the physician regarding the position of the physician's hand with respect to the second input device <NUM>. Thus, in use, the physician can use tactile feedback from the orientation feature <NUM> to discern, without needing to look at the second input device <NUM>, the position of the physician's hand with respect to the inputs 130a, 130b, 130c, 130d, 130e. This can be useful, for example, for facilitating switching back and forth, by the physician, between the operation of the articulation controller <NUM> and the second input device <NUM>.

In general, the second input device <NUM> can be disposed relative to the articulation controller <NUM> along the handle portion <NUM>. More generally, according to any one or more of the various different arrangements of the second input device <NUM> relative to the articulation controller <NUM> described herein, the physician can operate the second input device <NUM> to modify the graphical user interface <NUM> to achieve a desired view of the tip portion <NUM> of the catheter <NUM> on the graphical user interface <NUM> and, based on this desired view on the graphical user interface <NUM>, can operate the articulation controller <NUM> to move the tip portion <NUM> of the catheter <NUM> to a desired location (e.g., into contact with tissue). In certain instances, the physician can control (e.g., maintain in place) the distal end region <NUM> of the catheter shaft <NUM> while simultaneously manipulating the second input device <NUM> according to any one or more of the methods described herein. Accordingly, it should be understood that such relative positioning of the articulation controller <NUM> relative to the second input device <NUM> along the handle portion <NUM> can include any of various different configurations that advantageously facilitate coordinated operation of the articulation controller <NUM> and the second input device <NUM>.

In certain implementations, the second input device <NUM> can be disposed relative to the articulation controller <NUM> along the handle portion <NUM> such that the physician can manipulate the second input device <NUM> and the articulation controller <NUM> through one-handed operation. As used herein, one-handed operation should be understood to include manipulating the second input device <NUM> substantially simultaneously with manipulation of the articulation controller <NUM> using any combination of fingers of a single hand of the physician while the single hand of the physician maintains the same grip of the handle portion <NUM>), leaving the physician with a free hand during the medical procedure. Such one-handed operation of the second input device <NUM> and the articulation controller <NUM> can be useful, for example, for allowing the physician to grip the catheter shaft <NUM> with a free hand to maintain the distal end region <NUM> in place in the heart cavity of the patient <NUM>.

As an example, the second input device <NUM> can be coupled to the handle portion <NUM> at a position distal to the articulation controller <NUM> to facilitate operation of the articulation controller <NUM> with a thumb and manipulation of the second input device <NUM> with an index finger of the same hand while that hand maintains a natural grip of the handle portion <NUM>.

Additionally, or alternatively, the second input device <NUM> can be coupled to the handle portion <NUM> along an axial position at which the articulation controller <NUM> is positioned on the handle portion <NUM>. The articulation controller <NUM> can be movable, in certain instances, along a plane substantially perpendicular to a direction of movement of one or more of the inputs 130a, 130b, 130c, 130d, 130e. Such an orientation of the articulation controller <NUM> relative to the inputs 130a, 130b, 130c, 130d, 130e can be useful directing forces associated with manipulation of the articulation controller <NUM> in a direction different from a direction of forces associated with the one or more inputs 130a, 130b, 130c, 130d, 130e, which can facilitate substantially simultaneous but substantially independent operation of the articulation controller <NUM> and the one or more inputs 130a, 130b, 130c, 130d, 130e.

Further or instead, one or more inputs 130a, 130b, 130c, 130d, 130e can be positioned to facilitate other types of one-handed operation. For example, the one or more inputs 130a, 130b, 130c, 130d, 130e can be positioned relative to the catheter shaft <NUM> such that the one or more inputs 130a, 130b, 130c, 130d, 130e are manipulatable by a hand of the user while the same hand of the user applies an axial force to the catheter shaft <NUM> (e.g., through gripping the catheter shaft <NUM> between a thumb and another finger of a single hand). As an additional or alternative example, the one or more inputs 130a, 130b, 130c, 130d, 130e can be positioned relative to the catheter shaft <NUM> such that one or more inputs 130a, 130b, 130c, 130d, 130e are manipulatable by a hand of the user while the same hand of the user applies torque to the handle portion <NUM>.

In some implementations, the second input device <NUM> can be rotatably coupled to the handle portion <NUM> such that the second input device <NUM> is rotatable about a circumference of the catheter shaft <NUM>. In such implementations, operation of the second input device <NUM> and the articulation controller <NUM> can include rotating the second input device <NUM> relative to the catheter shaft <NUM> and, thus, relative to the articulation controller <NUM> to bring the second input device <NUM> into proximity to the articulation controller <NUM> and/or to the physician's hand during a procedure. Accordingly, it should be appreciated that rotation of the second input device <NUM> relative to the catheter shaft <NUM> can, in certain instances, facilitate one-handed operation of the second input device <NUM> and the articulation controller <NUM>.

The second input device <NUM> can be, for example, rotatable (e.g., between zero degrees and about <NUM> degrees) about the circumference of the catheter shaft <NUM>. As a more specific example, the second input device <NUM> can rotate freely about the circumference of the catheter shaft <NUM> such that the second input device <NUM> can be moved unimpeded about the circumference of the catheter shaft <NUM> through multiple rotations in any given direction. Such free rotation of the second input device <NUM> can facilitate moving the second input device <NUM> quickly into a desired position. For example, the physician can spin the second input device <NUM> into a desired position. Additionally, or alternatively, with free rotation about the catheter shaft <NUM>, the physician can move the second input device <NUM> into place using any finger that might not otherwise be engaged during a medical procedure.

In some implementations, the second input device <NUM> can be releasably coupled to the handle portion <NUM>. For example, a releasable coupling between the second input device <NUM> and the handle portion <NUM> can include a pin-and-socket configuration in which electrical communication and mechanical coupling between the second input device <NUM> and the handle portion <NUM> are established at substantially the same time as pins extending from the second input device <NUM> are inserted into corresponding sockets defined by the handle portion <NUM>.

The second input device <NUM> can be sterilizable. For example, the second input device <NUM> can be formed of components compatible with sterilization according to one or more of the following sterilization techniques: ethylene oxide sterilization, autoclave sterilization, gamma radiation, gas-plasma sterilization. In implementations in which the second input device <NUM> is releasably coupled to the handle portion <NUM>, the second input device <NUM> can be sterilizable separately from the handle portion <NUM>. Further, or instead, the second input device <NUM> can be reusable such that the second input device <NUM> can be sterilized between uses and secured to a new handle portion <NUM> for each use.

The articulation controller <NUM> can be in mechanical communication with the catheter shaft <NUM>. In operation, the articulation controller <NUM> can modify the position of the distal end region <NUM> of the catheter shaft <NUM> and, thus, modify the position of the tip portion <NUM> of the catheter <NUM>. As an example, one or more pull wires (not shown) can couple the articulation controller <NUM> to the catheter shaft <NUM> as is known in the art.

Operation of the articulation controller <NUM> can move one or more of the pull wires in a proximal direction to create a deflection force at the distal end region <NUM> of the catheter shaft <NUM>. For example, the articulation controller <NUM> can include one or more levers rotatable about an axis substantially perpendicular to an axis defined by the handle portion <NUM>, with the rotation of the articulation controller <NUM> moving one or more of the pull wires to deflect the distal end region <NUM> of the catheter shaft <NUM>. Additionally, or alternatively, the articular controller <NUM> can include a plunger (e.g., proximal or distal to the handle portion <NUM>) movable along an axis substantially parallel to an axis defined by the handle portion <NUM>, with proximal and distal movement of the articulation controller <NUM> moving one or more pull wires to move the distal end region <NUM> of the catheter shaft between a deflected position and a straight position. Because the tip portion <NUM> is coupled to the distal end region <NUM> of the catheter shaft <NUM>, the deflection force at the distal end region <NUM> of the catheter shaft <NUM> can deflect the tip portion <NUM>. While the articulation controller <NUM> has been described as being in mechanical communication with the catheter shaft <NUM> via one or more pull wires, it should be appreciated the articulation controller <NUM> can additionally, or alternatively, be in mechanical communication with the catheter shaft <NUM> through any one or more methods known in the art (e.g., through torque transmitted via a rotating member).

The catheter <NUM> can further, or instead, include a magnetic position sensor <NUM> along the distal end region <NUM> of the catheter shaft <NUM>. The magnetic position sensor <NUM> can be any of various magnetic position sensors well known in the art and can be positioned at any point along the distal end region <NUM>. The magnetic position sensor <NUM> can, for example, include one or more coils that detect signals emanating from magnetic field generators. One or more coils for determining position with five or six degrees of freedom can be used.

The magnetic field detected by the magnetic position sensor <NUM> can be used to determine the position of the distal end region <NUM> of the catheter shaft <NUM> according to one or more methods commonly known in the art such as, for example, methods based on using a sensor, such as the magnetic position sensor <NUM>, to sense magnetic fields and using a look-up table to determine location of the magnetic position sensor <NUM>. Because the tip portion <NUM> is coupled to the distal end region <NUM> of the catheter shaft <NUM> in a known, fixed relationship to the magnetic position sensor <NUM>, the magnetic position sensor <NUM> can provide the location of the tip portion <NUM>. While the location of the tip portion <NUM> is described as being determined based on magnetic position sensing, other position sensing methods can additionally or alternatively be used. For example, the location of the tip portion <NUM> can be additionally, or alternatively, based on impedance, ultrasound, and/or imaging (e.g., real time MRI or fluoroscopy).

The tip portion <NUM> can be one or more of a diagnostic tip and a treatment tip for directing energy (e.g., RF energy, ultrasound energy, chemical energy) toward tissue of the heart cavity. For example, the tip portion <NUM> can include at least one electrode mechanically coupled (e.g., directly coupled or indirectly coupled) to the distal end region <NUM> of the catheter shaft <NUM>. The at least one electrode can be, additionally or alternatively, disposed along an expandable element coupled to the distal end region <NUM> of the catheter shaft <NUM>.

Referring now to <FIG>, in use, the tip portion <NUM> can be inserted into a heart cavity <NUM> of the patient <NUM> (<FIG>) as part of the medical procedure. In certain implementations, the tip portion <NUM> can interact with a surface <NUM> of the heart cavity <NUM> as part of a medical procedure. For example, the tip portion <NUM> can deliver energy to the surface <NUM> for the purpose of treatment, diagnosis, or both. The energy delivered through the tip portion <NUM> can include any manner and form of energy known in the art and, therefore, can include RF energy.

The location of the tip portion <NUM> relative to the surface <NUM> of the heart cavity <NUM> can be known (e.g., based on a signal received from the magnetic position sensor <NUM> of <FIG>). Further, or in the alternative, the shape of the surface <NUM> of the heart cavity <NUM> can be known based on any of various different methods, including methods based on known locations visited by the tip portion <NUM> within the heart cavity <NUM>. Accordingly, as described in greater detail below, the graphical user interface <NUM> can represent the location of the tip portion <NUM> relative to the surface <NUM> on the graphical user interface <NUM>. Thus, in medical procedures in which direct visualization of the tip portion <NUM> in the heart cavity <NUM> is not possible, or is at least impractical, a physician can use the graphical user interface <NUM> as a tool for visualization of the tip portion <NUM> and/or the heart cavity <NUM> during a medical procedure.

Referring now to <FIG>, the graphical user interface <NUM> can include any of various different types of two-dimensional and/or three-dimensional displays known in the art. Thus, for example, the graphical user interface <NUM> can include a computer monitor or another similar type of two-dimensional display. Additionally, or alternatively, the graphical user interface <NUM> can include an augmented reality environment, a virtual reality environment, or combinations thereof.

The graphical user interface <NUM> can include a first portion <NUM> and a second portion <NUM> spatially delineated from the first portion <NUM>. In general, the spatial delineation between the first portion <NUM> and the second portion <NUM> can facilitate accommodating two different use cases on the graphical user interface <NUM> at the same time. For example, the second portion <NUM> can work in cooperation with the limited inputs of the second input device <NUM> to provide the physician with a robust interface while the first portion <NUM> can cooperate with more expansive input options available through the first input device <NUM> (e.g., input options compatible with a full keyboard, a mouse, or combinations thereof). In general, these use cases are not interchangeable with one another as efficient input solutions. That is, it would be inefficient to use the second input device <NUM>, with limited input options, to operate the first portion <NUM> of the graphical user interface <NUM>, and the opposite case of operating the first input device <NUM>, with multiple input options, to navigate through a state machine represented on the second portion <NUM> of the graphical user interface <NUM> is also an inefficient input solution. Accordingly, the spatial delineation between the first input portion <NUM> and the second input portion <NUM> can be useful for providing different users with user interface elements that are appropriate for a given use case associated with the respective user.

In certain implementations, spatial delineation of the first portion <NUM> from the second portion <NUM> can be useful for facilitating switching focus between the first portion <NUM> and the second portion <NUM> by a physician during a medical procedure. For example, because the second portion <NUM> is in a readily identifiable location (e.g., centered on the graphical user interface <NUM>) relative to the first portion <NUM> on the graphical user interface <NUM>, the physician can easily switch focus back and forth between the first portion <NUM> and the second portion <NUM> with little time and effort expended to locate or relocate the physician-specific interface on the second portion <NUM> of the graphical user interface <NUM>. Further, or in the alternative, such spatial delineation of the first portion <NUM> from the second portion <NUM> can facilitate concurrent, or substantially concurrent, use of the graphical user interface <NUM> by two different users, as described in greater detail below.

The first portion <NUM> of the graphical user interface <NUM> can include a first set of input options <NUM> and, further or instead, a graphical representation <NUM> of the heart cavity <NUM>. As used herein, the graphical representation <NUM> of the heart cavity <NUM> can include partial depictions of the heart cavity <NUM>, such as those that may be generated in implementations in which the graphical representation <NUM> is built based on known locations of the catheter <NUM>. The first set of input options <NUM> can correspond to permissible modifications and/or display settings of the graphical representation <NUM>. Such modifications and/or display settings of the graphical representation <NUM> can correspond to one or more input commands based on the first set of input options <NUM> and received in preparation for and/or during a medical procedure.

The graphical representation <NUM> can be based, for example, on the shape of the surface <NUM> of the heart cavity <NUM> such that the graphical representation <NUM> can include at least one two-dimensional projection of a three-dimensional model of the heart cavity <NUM>. Additionally, or alternatively, the graphical representation <NUM> can include a depiction of a portion of the catheter <NUM> (e.g., the tip portion <NUM>), which can be useful for locating the portion of the catheter <NUM> relative to the heart cavity <NUM>. As shown in <FIG>, the graphical representation <NUM> can include, for example, more than one two-dimensional projection of a three-dimensional model of the heart cavity <NUM>, with each two-dimensional projection projected to a different image plane and, thus, corresponding to a different view of the three-dimensional model of the heart cavity <NUM>.

The second portion <NUM> of the graphical user interface <NUM> can include a second set of input options <NUM>. The second set of input options <NUM> can advantageously be different from the first set of input options <NUM>, as described in greater detail below. In general, the second set of input options <NUM> can correspond to permissible modifications and/or display settings associated with the graphical representation <NUM> in the first portion <NUM> of the graphical user interface <NUM>. Such modifications of the graphical representation <NUM> can correspond to one or more input commands based on the second set of input options <NUM> and received in preparation for and/or during a medical procedure.

The first input device <NUM> can be in communication with the first portion <NUM> of the graphical user interface <NUM> while the second input device <NUM> can be in communication with the second portion <NUM> of the graphical user interface <NUM>. In general, a first user (e.g., a technician outside of a sterile field) can use the first input device <NUM> to interact with the first set of input options <NUM> on the graphical user interface <NUM>, and a second user (e.g., a physician within a sterile field) can use the second input device <NUM> to interact with the second set of input options <NUM> on the graphical user interface <NUM> while concurrently, or substantially concurrently, manipulating the catheter <NUM>. Because the second user can be constrained (e.g., by requirements for maintaining the sterile field and/or the need to manipulate the catheter <NUM>), the second set of input options <NUM> can advantageously be state-dependent to facilitate navigation of the second set of input options <NUM> using only a limited number of inputs, such as the inputs 130a, 130b, 130c, 130d, 130e, of the second input device <NUM>.

As used herein, the term "state-dependent" is inclusive of a state machine in which the second set of input options <NUM> can be in one of a set number of conditions, or states, based on one or more previous states and on previous inputs, with state transitions in such a state machine depending on the present state and the present inputs. Examples of a state-machine associated with the second set of input options <NUM> are described in greater detail below. In general, however, the second set of input options <NUM> can be state-dependent such that, although a given state of the second set of input options <NUM> may be a reduced set of options as compared to the first set of input options <NUM>, the combination of the states of the second set of input options <NUM> can offer functionality equivalent or similar to the functionality available through all or a subset of the first set of input options <NUM>.

The second portion <NUM> of the graphical user interface <NUM> can include, for example, a banner section <NUM> and a menu section <NUM>. In combination, the banner section <NUM> and the menu section <NUM> can present the second set of input options <NUM> corresponding to the current state of a plurality of states of the state machine. Also, or instead, the combination of the banner section <NUM> and the menu section <NUM> can provide the physician with visual context for navigating to other states of the state machine. Such visual context can facilitate, for example, efficient navigation to the various states of the state machine (e.g., as necessitated during the medical procedure) using only a limited number of inputs, such as the inputs 130a, 130b, 130c, 130d, 130e of the second input device <NUM>.

<FIG> is a schematic representation of an example of a state machine <NUM> implemented on the catheter interface unit <NUM> (<FIG>). For the sake of clarity of representation, the states of the state machine <NUM> are generally represented relative to one another in two-dimensions in <FIG>. Each arrow between states of the state machine <NUM> represents a navigation input command that will move the state machine <NUM> from one state to another. Thus, in the example shown in <FIG>, right/left navigation commands received from the second input device <NUM> (<FIG>) move to the right or left, as the case may be, of a given state, and up/down navigation commands received from the second input device <NUM> (<FIG>) move up or down, as the case may be, relative to a given state. It should be appreciated, however, that additional or alternative relationships between navigations inputs from the second input device <NUM> (<FIG>) can be used to navigate through the states of the state machine <NUM>. As an example, the press time (e.g., a long press time) associated with a navigation input command from the second input device <NUM> can be used to skip to a particular state in the state machine <NUM>.

Referring now to <FIG>, as described in further detail below, the current state of the state machine <NUM> can be represented on the second portion <NUM> of the graphical user interface <NUM>, and an adjacent state or states of the state machine <NUM> can be represented on the second portion <NUM> of the graphical user interface <NUM> (e.g., as a preview) to facilitate navigation from one state to another.

The state machine <NUM> can have any of various different configurations, which can depend on, among other things, the configuration of the second input device <NUM>, the configuration of the second set of input options <NUM>, the functionality to be provided to the physician, and/or the application to which the state machine is being applied. Accordingly, while specific implementations of the state machine <NUM> are described herein by way of example, further or alternative implementations of the state machine <NUM> are additionally or alternatively possible.

In general, the state machine <NUM> can include a top-level <NUM> and one or more sublevels <NUM>. The functionality described herein with respect to the top-level <NUM> and the one or more sublevels <NUM> is by way of example and not limitation. Further, it should be appreciated that the state machine <NUM> can include a layer above the top-level <NUM> through which access to the state machine <NUM> is gained. For example, the state machine <NUM> can include one or more layers above the top-level <NUM> to allow the physician to choose between an ablation mode and a mode in which the physician can work with the state machine <NUM> to modify the graphical representation <NUM>.

In the exemplary state machine <NUM>, the top-level <NUM> includes a build state 154a, a view state 156a, and a tag state 158a (sometimes collectively referred to herein as "top-level states" and sometimes individually referred to herein as a "top-level state"). One or more sublevel state can be below each top-level state. For the sake of clarity, the hierarchy of states of the state machine <NUM> is represented in <FIG> such that each top-level state has an element number ending with "a," each sublevel state below the respective top-level state is represented with the same element number ending with "b" (in the case of a first sublevel state), and the input options corresponding to a given sublevel state are represented with the same element number ending with "c".

Navigation through the states of the state machine <NUM> can be represented in the second portion <NUM> of the graphical user interface <NUM> (e.g., as a change in the state highlighted in the second portion <NUM>). In general, one or more of the inputs 130a, 130b, 130c, 130d, 130e of the second input device <NUM> can be used to send navigation commands to the catheter interface unit <NUM> to navigate through the states of the state machine <NUM> and one or more of the inputs 130a, 130b, 130c, 130d, 130e can be used to provide one or more input commands to the catheter interface unit <NUM> to select a particular state of the state machine <NUM>. As navigation commands are sent to the catheter interface unit <NUM>, the representation of the states of the state machine <NUM> on the second portion <NUM> of the graphical user interface <NUM> can change accordingly. For example, the second portion <NUM> of the graphical user interface <NUM> can highlight or otherwise accentuate the current navigation position of the state machine <NUM>. In certain implementations, a received input command can select the current navigation position as the state of the state machine <NUM>. Thus, as used herein, a "navigation command" should be understood to include an input sent from one or more of the inputs 130a, 130b, 130c, 130d, 130e to the catheter interface unit <NUM> to change a display of one or more states on the second portion <NUM> of the graphical user interface <NUM>, with the change of the display of the one or more states corresponding to navigation through the states of the state machine <NUM>. Additionally, or alternatively, an "input command" should be understood to include an input sent from one or more of the inputs 130a, 130b, 130c, 130d, 130e to the catheter interface unit to make a selection in the one or more displayed states on the second portion <NUM> of the graphical user interface <NUM>.

Respective icons for the build state 154a, the view state 156a, and the tag state 158a can be displayed in the banner section <NUM> of the second portion <NUM> of the graphical user interface <NUM>. These respective icons can advantageously provide a visual indication of the contents of the corresponding sublevel state displayed in the menu section <NUM> below the corresponding top-level state. For example, if an icon associated with the build state 154a is highlighted in the banner section <NUM>, the physician can readily assess that the sublevel state shown in the menu section <NUM> corresponds to the build state 154a.

In use, the inputs 130a and 130b (right/left) can be used to provide navigation commands to scroll across the sublevel states in the state machine <NUM>. It should be appreciated that scrolling across the sublevel states in the state machine <NUM> can be advantageous for efficient navigation at least because such scrolling reduces the need to use also the inputs 130c and 130d (up/down) to navigate to other sublevel states of the state machine <NUM>. For example, the physician can use single button operation (e.g., using only the input 130a (right) or only the input 130b (left)) to scroll across the sublevel states. Scrolling across the sublevel states can be represented as a change in the sublevel state shown or highlighted in the menu section <NUM>. Optionally, a corresponding change in the display of the icons of the top-level state can be shown in the banner section <NUM>.

The inputs 130c and 130d (up/down) can be used to scroll through input options within a given sublevel state of the state machine <NUM>, with the scrolling within the sublevel state represented as a change in the sublevel state option shown or highlighted in the menu section <NUM>. For example, the inputs 130c and 130d (up/down) can be used to scroll through first build input options 154c' in the first build sublevel state 154b', second build input options 154c" in the second build sublevel, first view input options 156c' in the first view sublevel state, second view input options 156c" in the second view sublevel state 156b", and tag input options 158c in the tag sublevel state 158b.

As an example of navigation of the state machine <NUM>, the physician can use the inputs 130a and 130b (right/left) to scroll from the tag sublevel state 158b to the view sublevel state 156b" to see options for adjusting the graphical representation <NUM> on the first portion <NUM> of the graphical user interface <NUM>. This may be desirable, for example, for better visualization of the graphical representation <NUM> and, thus, for more accurate placement of tags on the graphical representation <NUM>. As the physician scrolls from the tag sublevel state 158b to the view sublevel state 156b", the highlighted icon in the banner section <NUM> can change accordingly to provide the physician with a visual indication of the top-level state corresponding to the second set of input options <NUM>. The physician can select the desired sublevel state, which is the view sub level state 156b" in this example, by providing an input command, such as an enter command via input 130e. With the desired sublevel state selected, the physician can use the inputs 130c and 130d (up/down) to scroll through input options associated with the selected sublevel state. It should be appreciated that other transitions between states of the state-machine <NUM> are additionally, or alternatively, possible and can similarly facilitate execution of the medical procedure by the physician.

The build state 154a can have a first build sublevel state 154b' and a second build sublevel state 154b". The state machine <NUM> can be in one or the other of the first build sublevel state 154b' and the second build sublevel state 154b", depending on whether a build procedure is in progress. As used herein, the build procedure can include formation of a three-dimensional model of the heart cavity <NUM> used to form the graphical representation <NUM> displayed on the graphical user interface <NUM>. For example, the build procedure can be based on received locations of the tip portion <NUM> of the catheter <NUM> in the heart cavity <NUM>.

The first build sublevel state 154b' can correspond to the build procedure being stopped. Accordingly, the first build sublevel state 154b' can include an input for starting the build procedure, which can be displayed in the menu section <NUM> of the second portion <NUM> of the graphical user interface <NUM>. When the physician selects the input to start the build procedure, the current state of the state machine <NUM> can switch to the second build sublevel state 154b".

The second build sublevel state 154b" can correspond to the build procedure being in progress. Accordingly, the second build sublevel state 154b" can include an input for stopping the build procedure, which can be displayed in the menu section <NUM> of the second portion <NUM> of the graphical user interface <NUM>. When the physician selects the input to stop the build procedure, the current state of the state machine <NUM> can switch to the first build level state 154b'. Thus, the state machine <NUM> moves between sublevel states (the first build sublevel state 154b' and the second build sublevel state 154b", in this example) to present the physician with input options that represent the next logical step or steps in the medical procedure, given the current state of the state machine <NUM>.

The view state 156a can correspond to control of the graphical representation <NUM> on the first portion <NUM> of the graphical user interface <NUM>. For the sake of clarity of explanation, the state machine <NUM> is described with respect to the view state 156a controlling a single view of the graphical representation <NUM>. It should be appreciated, however, that the view state 156a can include multiple states, each corresponding to control of a different view of the graphical representation <NUM> on the first portion <NUM> of the graphical user interface <NUM>. For example, in instances in which a first view of the graphical representation <NUM> is displayed on the left side of the graphical user interface <NUM> and a second view of the graphical representation <NUM> is displayed on the right side of the graphical user interface <NUM>, the view state 156a can include states corresponding to the respective views on the left side and right side of the graphical user interface <NUM>.

The view state 156a can include a first view sublevel state 156b' and a second view sublevel state 156b". While the view state 156a is described as having two sublevels, it should be appreciated that the view state 156a can have any of various different sublevels. In general, the sublevels associated with the view state 156a can depend on the amount of control to be provided to the physician with respect to the graphical representation <NUM> on the first portion <NUM> of the graphical user interface <NUM>. Accordingly, the number of sublevels associated with the view state 156a can depend on the particular implementation. For example, in the case of implementations related to visualization of a medical procedure performed on the heart cavity <NUM> of the patient <NUM>, the view state 156a can include a sublevel associated with rotation of the graphical representation <NUM> and a sublevel associated with one or more fixed views of the graphical representation <NUM>.

The state machine <NUM> can be in one or the other of the first view sublevel state 156b' and the second view sublevel state 156b", depending on which of various, different view control features is selected. An example of a view control feature can be a fixed view mode in which a plurality of fixed views (e.g., left-anterior oblique (LAO), right-anterior oblique (RAO), etc.) are displayed in the menu section <NUM> such that the physician can scroll through the fixed views and select a desired view. Additionally, or alternatively, a view control feature can be an adjustable view mode (e.g., in which the physician can adjust a view parameter such as tilt). Accordingly, in implementations in which the first view sublevel state 156b' corresponds to a fixed view mode and the second view sublevel state 156b" corresponds to an adjustable view mode, the physician can switch between the fixed view mode and the adjustable view mode as desired (e.g., by scrolling across the sublevel states).

The tag state 158a can have, for example, a single tag sublevel state 158b including a selection of identifiers corresponding to anatomic features of the heart cavity. Thus, for example, when the top-level state of the state machine corresponds to the tag state 158a, the identifiers of the tag sublevel state 158b can be displayed in the menu section <NUM> of the second portion <NUM> of the graphical user interface <NUM>. In use, the physician can navigate through the identifiers displayed in the menu section <NUM> using, for example, the inputs 130a, 130b, 130c, 130d and can select an identifier using the input 130e. As a result of this selection, an appropriate tag can appear on the graphical representation <NUM> shown on the first portion <NUM> of the graphical user interface <NUM>. As an example, the appropriate tag can appear on the graphical representation <NUM> at a location based on the location of the catheter tip <NUM>.

The tags available in the tag sublevel state 158b can be a function of the global state of the state machine <NUM> and, thus, can themselves be state dependent. For example, if the state machine <NUM> is in an "ablation" mode, the tags available in the tag sublevel state 158b can include tags related to marking the location of one or more ablations on the graphical representation <NUM>. As an additional or alternative example, if the state machine <NUM> is in an "anatomy" mode, the tags available in the tag sublevel state 158b can correspond to marking anatomic features on the graphical representation <NUM>. In cardiac implementations, the tags available in the tag sublevel state 158b can be dependent on the chamber of the heart in which the catheter <NUM> is inserted. For example, information regarding the chamber can be received from the first input device <NUM> and/or the second input device <NUM>, and the tags in the tag sublevel state 158b can be updated accordingly.

The computer executable instructions stored on the computer readable storage medium <NUM> can cause the processing unit <NUM> to receive inputs from the first input device <NUM> and the second input device <NUM> to modify the graphical representation <NUM> according to one or more of the following exemplary methods. For example, the computer executable instructions stored on the storage medium <NUM> and executable by the processing unit <NUM> can be an application built using Visualization Toolkit, an open-source 3D computer graphics toolkit, available at www. Unless otherwise indicated or made clear from context, each of the following exemplary methods can be implemented using the system <NUM> and/or one or more components thereof.

<FIG> is a flowchart of an exemplary method <NUM> of controlling a graphical representation on a graphical user interface. The graphical representation and the graphical user interface can be, for example, any of the various different graphical representations and graphical user interfaces described herein. Accordingly, the exemplary method <NUM> can control the display of the graphical representation <NUM> (<FIG>) on the graphical user interface <NUM> (<FIG> and <FIG>).

The exemplary method <NUM> can include receiving <NUM> a signal indicative of location of a cardiac catheter in a cavity of a patient's heart, displaying <NUM> a graphical representation of the cavity of the patient's heart, receiving 166a a first input command based on a first set of input options, receiving 166b a second input command based on a second set of input options, and modifying <NUM> the graphical representation based on the first input command and on the second input command. The graphical representation can be based on the received <NUM> signal indicative of location of the cardiac catheter and can be displayed on a first portion of a graphical user interface, along with the first set of input options. The second set of input options can be displayed, for example, on a second portion of the graphical user interface.

Receiving <NUM> the signal indicative of location of the cardiac catheter in the cavity of the patient's heart can include any of the various different methods described herein for determining a location of a cardiac catheter in a heart cavity. For example, receiving <NUM> the signal indicative of location of the cardiac catheter in the cavity of the patient's heart can include receiving a signal from a sensor such as the magnetic position sensor <NUM> (<FIG>). Further, it should be appreciated that the received <NUM> signal can be indicative of any predetermined location of the cardiac catheter in the heart cavity. Accordingly, the received <NUM> signal can be indicative of a tip portion (e.g., tip portion <NUM>) of the cardiac catheter.

In certain implementations, displaying <NUM> the graphical representation of the cavity of the patient's heart can include projecting a model (e.g., a three-dimensional model) of either or both of the cardiac catheter and the cavity to an image plane corresponding to the graphical user interface. Further, or alternatively, displaying <NUM> the graphical representation can include displaying the cavity of the patient's heart in one or more views in the first portion of the graphical user interface. Such multiple views can be useful, for example, for visualizing movement of the cardiac catheter relative to one or more surfaces of the cavity.

In certain implementations, displaying <NUM> the graphical representation can include displaying only a graphical representation of the cardiac catheter initially, while a graphical representation of the heart cavity is being built. As the graphical representation of the heart cavity is built, displaying <NUM> the graphical representation can include updating the graphical representation to show the gradual generation of the graphical representation of the heart cavity.

Displaying <NUM> the graphical representation can be based on the received 166a first input command and the received 166b second input command. That is, in general, displaying <NUM> the graphical representation can be based on inputs received from two different sources. Such multiple inputs can be useful, for example, for facilitating receiving input directly from a physician while allowing a technician to provide additional or alternative inputs for controlling the graphical representation.

Receiving 166a the first input command from the first input device and receiving 166b the second input command from the second input device can occur concurrently. For example, receiving 166a the first input command can be along a first communication channel and receiving 166b the second input command can be along a second communication channel, different from the first communication channel. Each communication channel can be associated with a respective portion of the graphical user interface such that the first communication channel can be associated with the first portion of the graphical user interface, upon which the first set of input options is displayed and, similarly, the second communication channel can be associated with the second portion of the graphical user interface, upon which the second set of input options is displayed. It should be appreciated that during concurrent communication, one of the first communication channel or the second communication channel can have a predetermined priority over the other. For example, the second communication channel can be given priority over the first communication channel such that communication from the second input device associated with the physician is given priority over communication from the first input device.

One or both of receiving 166a the first input command from the first input device and receiving 166b the second input command from the second input device can include wireless or wired communication according to any of the various different communication systems and methods described herein. Further, one of the receiving 166a the first input command from the first input device and receiving 166b the second input command from the second input device can include wireless communication while the other includes wired communication.

Receiving 166a the first input command from the first input device can include receiving an input command from any of various different input devices known in the art, including, for example, one or more of a keyboard, a mouse, a touchscreen, etc. In general, the first input command can be received 156a from a technician, or other similar personnel, who is ordinarily not in the sterile field and, thus, ordinarily has full use of both hands to manipulate the first input device. Accordingly, the second set of input options can be a subset of the first set of input options such that the technician may have access to certain input options that are not available to the physician as the physician operates the second input device during the medical procedure. That is, the technician can have access to input options associated with functions that are more efficiently carried out by the technician than by the physician, who must also manipulate the catheter during the medical procedure.

The first set of input options from which the received 166a first input command is derived can be displayed along a portion of the graphical user interface that is ordinarily not an area of focus for the physician. For example, the first set of input options can be on the first portion of the graphical user interface and, optionally, set off to one side of the graphical representation of the heart cavity. It should be appreciated that such orientation of the first set of input options can be useful for efficient use of the space available on the graphical user interface. For example, because the first set of input options are not associated with the second input device operated by the physician, placing the first set of input options in a non-central location, or an otherwise deemphasized location, on the graphical user interface can facilitate presentation of the most relevant information to the physician during a medical procedure. That is, the second portion of the graphical user interface, upon which the second set of input options is displayed, can be substantially centrally positioned on the graphical user interface.

In general, receiving 166b the second input command can include receiving one or more commands from a remote device. As used herein, the term "remote device" includes an input device that is spatially separated from the first input device, from the graphical user interface, and/or from a processing unit of a catheter interface unit. In general, such spatial separation can be delineated by a sterile field such that the term "remote device" is inclusive of a device that transmits one or more input commands from within a sterile field to one or more portions of the system outside of the sterile field. Accordingly, it should be appreciated that remote communication using the remote device can offer certain advantages for communicating with a processing unit or other portions of a catheter interface unit while maintaining the sterile field.

Receiving 166b the second input command from the remote device can include receiving an input command from any of the various different remote devices described herein. Thus, for example, receiving 166b the second input command from the remote device can include receiving an input command from a second input device disposed on a handle portion of a catheter (e.g., the second input device <NUM> disposed on the handle portion <NUM> of the catheter <NUM> as described with respect to <FIG>). Further, or in the alternative, receiving 166b the second input command from the remote device can include receiving an input command from a second input device that is separate from a catheter, as described in greater detail below.

Receiving 166b the second input command can include receiving a discrete selection command. The discrete selection command can include a click, or other similar discrete input appropriate for the second input device, corresponding to selection of one of the second set of input options. For example, the discrete selection command can include an input such as the input 130e arranged as an "enter" input as described with respect to <FIG>. The instruction corresponding to the discrete selection command can vary depending on the state of a state machine represented in the second portion of the graphical user interface. More generally, the instruction corresponding to the discrete selection command can be based on the context of a particular portion of the medical procedure and, thus, can change over the course of the medical procedure.

In certain implementations, the exemplary method <NUM> can further include receiving <NUM> navigation commands for moving, within the second portion of the graphical user interface, between the options in the second set of options. As an example, the received <NUM> navigation commands can include discrete direction commands (e.g., left, right, up, and down corresponding to input from one or more of inputs 130a, 130b, 130c, 130d, and 130e) in the second portion of the graphical user interface. Because the physician may have to manipulate the catheter while providing the navigation commands, such discrete direction commands can facilitate navigating through the second portion of the graphical user interface through a simplified user interface manipulated, for example, through one-handed operation by the physician.

The navigation commands can be received before and/or concurrently with receiving 156b the second input command. For example, one or more of the received <NUM> navigation commands and the received 156b second input command can be used to navigate through the various different states of a state machine according to any one or more of the systems and methods described herein and, in particular, with respect to <FIG>.

At least one of the received <NUM> navigation commands can scroll through the second set of input options displayed as an infinite wheel. That is, repeated receipt <NUM> of a particular navigation command (e.g., a "left" command) can cycle through the second set of input options continuously. Such continuous cycling in response to repeated receipt <NUM> of a particular navigation command can facilitate one-handed operation of the second input device to navigate the second set of input options. For example, if the physician inadvertently scrolls past a desired input option, the physician can continue to press the same navigation input (e.g., input 130a, 130b, 130c, 130d of <FIG>) until the desired input appears again in the second portion of the graphical user interface.

In some implementations, the exemplary method <NUM> can further include detecting <NUM> receipt of an initial command. The initial command can be the received 166b second input command. By way of non-limiting example, the detected <NUM> receipt of the initial command can follow a period of inactivity and/or a predetermined change in the second portion of the graphical user interface. Additionally, or alternatively, the initial command can be one of the received <NUM> navigation commands.

In general, the first portion is viewable on the graphical user interface at the same time that the second portion is viewable on the graphical user interface, and it can be useful to delineate between the first portion and the second portion during the medical procedure. As an example of such a delineation between the first portion and the second portion, one or more display features of the second portion of the graphical user interface can be changed based on the detected <NUM> receipt of the initial command. Such a change in the second portion of the graphical user interface can advantageously provide the physician with feedback regarding proper operation of the second input device. That is, as the one or more display features of the second portion of the graphical user interface change, the change in the second portion of the graphical user interface can be perceived by the physician and, thus, serve as an indication that the commands from the second input device are being reflected in the second portion of the graphical user interface.

Changes to the one or more display features of the second portion of the graphical user interface can include displaying additional input options of the second set of input options (e.g., displaying additional input options related to a current state of the state machine such as the state machine <NUM> described with respect to <FIG>). For example, detecting <NUM> receipt of the initial command can result in expansion of a menu to provide the physician with a visual representation of additional options. Additionally, or alternatively, detecting <NUM> receipt of the initial command can result in displaying one or more menus to provide the physician with a preview of menus that are adjacent to a current menu to facilitate navigation to an appropriate menu in the second portion of the graphical user interface.

In certain implementations, changing one or more display features of the second portion of the graphical user interface can include changing one or more display features of the second portion of the graphical user interface, relative to the first portion of the graphical user interface, between a baseline configuration and a modified configuration. As an example, such a change can include changing the size of the second portion of the graphical user interface relative to the size of the first portion of the graphical user interface. Thus, in such instances, detecting <NUM> receipt of the initial command can result in the second portion of the graphical user interface increasing in size relative to the first portion of the graphical user interface. This change in size can make the second portion of the graphical user interface easier to perceive by the physician and, thus, can facilitate navigation through one or more menus displayed on the second portion of the graphical user interface.

In addition to, or as an alternative to, changing the size of the second portion of the graphical user interface in response to detecting <NUM> receipt of the initial command, changing the one or more display features of the second portion of the graphical user interface can include changing opacity of the second portion of the graphical user interface relative to the opacity of the first portion of the graphical user interface. As an example, the baseline configuration of the second portion of the graphical user interface can be relatively opaque prior to detecting <NUM> receipt of the initial command and can become less opaque upon detecting <NUM> receipt of the initial command. Such a change in opacity of the second portion of the graphical user interface can make the second portion of the graphical user interface more easily perceivable by the physician.

Further in addition, or further in the alternative, changing one or more display features of the second portion of the graphical user interface relative to the first portion of the graphical user interface can include changing the position of the second portion of the graphical user interface relative to the position of the first portion of the graphical user interface. An example of such a change in position can include displaying the second portion of the graphical user interface as a pop-up window. For example, the pop-up window can appear in front of the first portion of the graphical user interface. More generally, a change in position of the second portion of the graphical user interface relative to the first portion of the graphical user interface can facilitate prominently displaying the second portion of the user interface for improved perceptibility by the physician during the medical procedure.

In some implementations, changing the one or more display features of the second portion of the graphical user interface relative to the first portion of the graphical user interface can include changing the second portion of the graphical user interface from the modified configuration to the baseline configuration if a time between receipt <NUM> of the initial command and receipt of a subsequent input command exceeds a predetermined inactivity threshold period. For example, the predetermined inactivity threshold period can be programmable (e.g., by the physician according to the physician's preference). Such a period of inactivity can coincide with the physician moving the catheter within the heart cavity. Accordingly, during this period, the second portion of the graphical user interface can be advantageously deemphasized in favor of a more prominent display of the first portion of the graphical user interface, which includes the graphical representation of the heart cavity.

In certain implementations, changing the one or more display features of the second portion of the graphical user interface relative to the first portion of the graphical user interface between the baseline configuration and the modified configuration can include changing the second portion of the graphical user interface from the modified configuration to the baseline configuration based on a received input command of the second set of input commands. Further, or in the alternative, a received input command of the second set of input commands can toggle between the modified configuration and the baseline configuration. Toggling between the modified configuration and the baseline configuration can, for example, provide the physician with control over the display of the second portion of the graphical user interface. Such control can be useful for deemphasizing the second portion of the graphical user interface on command to facilitate observation of the first portion of the graphical user interface by the physician (e.g., during a particular portion of the medical procedure).

In general, modifying <NUM> the displayed graphical representation in the first portion of the graphical user interface can include any one or more of various different changes to the displayed graphical representation that may improve visualization of the graphical representation by the physician. For example, modifying <NUM> the displayed graphical representation can include building a graphical representation of the heart cavity, altering a display view of the graphical representation, and/or tagging one or more anatomic features on the graphical representation. Because modifying <NUM> the displayed graphical representation can be based on the received 166a first input command from the first input device and the received 166b second input command from the second input device, it should be appreciated that relatively simple modifications <NUM> of the displayed graphical representation can be implemented through the second input device operated by the physician while more complex modifications <NUM> of the displayed graphical representation can be implemented through the first input device operated by the technician.

Modifying <NUM> the displayed graphical representation in the first portion of the graphical user interface can include, for example, modifying a pose of the graphical representation including one or more of a translation and an orientation. For example, the pose can include two rotation angles. The pose can correspond to one or more predetermined poses of the graphical representation. Further, or in the alternative, the pose can be customizable according to one or more inputs from one or both of the first input device and the second input device. In certain implementations, modifying <NUM> the displayed graphical representation can include adjusting an orientation of a displayed view of the graphical representation of the heart cavity such as, for example, by rotating the graphical representation of the heart cavity about an axis.

In certain implementations, modifying <NUM> the displayed graphical representation in the first portion of the graphical user interface can include adjusting the displayed graphical representation according to the order in which the first input command the second input command are received. Such modification <NUM> of the displayed graphical representation can allow the physician to undo or otherwise modify an input command provided by the technician through the first input device. More generally, the fist input command and the second input command can operate in concert to modify <NUM> the displayed graphical representation.

The exemplary method <NUM> can include receiving <NUM> a signal indicative of a location of a catheter tip in a cavity of a patient's heart, displaying <NUM>, on a graphical user interface, a graphical representation of the location of the catheter tip in the cavity of the patient's heart, receiving 174a a first input command from a first input device, receiving 174b navigation commands and a second input command from a second input device, and modifying <NUM> the displayed graphical representation based on the first input command and the second input command. The first input command can be responsive to a first set of input options displayed on the graphical user interface, and the second input command can be responsive to a second set of input options displayed on the graphical user interface.

Receiving <NUM> the signal indicative of the location of the catheter tip in the cavity of the patient's heart can include any one or more of the various different methods of receiving location information described herein. For example, receiving <NUM> the signal indicative of location of the cardiac catheter in the cavity of the patient's heart can include receiving a signal from a sensor such as the magnetic position sensor <NUM> (<FIG>). Further, it should be appreciated that the received <NUM> signal can be indicative of any predetermined location of the cardiac catheter in the heart cavity. Accordingly, the received <NUM> signal can be indicative of a location of a tip portion (e.g., tip portion <NUM>) of the cardiac catheter.

Displaying <NUM> the graphical representation of the cavity of the patient's heart on the graphical user interface can include any of the various different methods of displaying the graphical representation described herein. Accordingly, as an example, displaying <NUM> the graphical representation can include displaying a two-dimensional projection of a three-dimensional model of the cavity of the patient's heart. Additionally, or alternatively, displaying <NUM> the graphical representation of the cavity of the patient's heart on the graphical user interface can include displaying one or more views of the graphical representation.

The first input command can be received 174a from the various different devices and systems described herein with respect to the first input device and, additionally or alternatively, according to any one or more of the various different methods described herein with respect to sending and receiving a first input command from the first input device. Thus, for example, the first input command can be received 174a by a catheter interface unit via wired or wireless communication with a keyboard and/or mouse operated by a technician (e.g., outside of a sterile field). The first input command can be received 174a from among the first set of input options, which can be a full complement of possible input commands available for modifying the displayed <NUM> graphical representation of the cavity of the patient's heart. Additionally, or alternatively, the first set of input options can be displayed on a dedicated portion of a graphical user interface, away from the second set of input options, according to any of the various different methods described herein. Accordingly, the first set of input options can be displayed on the first portion of the graphical user interface, and the second set of input options on a second portion of the graphical user interface.

The navigation commands and/or the second input command can be received 174b from the various different devices and systems described herein with respect to the second input device and, additionally or alternatively, according to any one or more of the various different methods described herein with respect to sending and receiving navigation commands and/or a second input command from the second input device. For example, the navigation commands and the second input command can be received 174b by a catheter interface unit in wired or wireless communication with a second input device operated by a physician. The second input device can be any of the various different second input devices described herein.

In general, the second input device can include relatively few inputs as compared to the first input device, with the functionality of the second input device being a function of the representation of a state machine on the graphical user interface. For example, the second set of input options displayed on the graphical user interface can be based at least in part on the current state of the state machine and, additionally or alternatively, can include available transitions of a state machine. Continuing with this example, the navigation input commands received 174b from the second input device can be used to navigate through the transitions of the state machine and an input command received 174b from the second input device can be used to select a particular state of the state machine. Accordingly, it should be appreciated that the changing state of the state machine can impart additional functionality to the inputs of the second input device. That is, the result produced by a given received 174b input command can vary according to the state of the state machine at the time the input command is received 174b.

Receiving 174b the navigation commands and the second input command from the second input device can include receiving discrete commands. For example, the discrete commands can include commands for moving through the second set of input options. Examples of such discrete directional commands can include commands corresponding to right, left, up, and down navigation through the second set of input commands displayed in the second portion of the graphical user interface.

Also, or instead, receiving 174b the navigation commands and the second input command from the second input device can include receiving one or more analog commands. As an example, one or more inputs of the second input device can include a capacitive touch sensor that produces an analog input command. This analog command can be used, in certain instances, for navigating through the second set of input options. For example, in implementations in which the capacitive touch sensor is arranged as a scroll wheel, the scroll wheel can be used to scroll through the second set of input options.

The second set of input options can be arranged in an infinite wheel according to any of the arrangements described herein. In such implementations, receiving 174b the navigation commands can include receiving a scroll command (e.g., a discrete command, an analog command, or a combination thereof) for moving through the states of the infinite wheel. Thus, for example, a physician can press a single input on the second input device repeatedly, or by holding down the single input, to continually move through the infinite wheel until a desired input command is highlighted and can be selected.

Modifying <NUM> the displayed graphical representation can include any one or more of the various different modifications described herein. Accordingly, as an example, modifying <NUM> the displayed graphical representation can be based on the order in which the first input command and the second input command are received. Thus, in this example, the second input command can override a modification made based on the first input command and, in this way, can provide the physician with a mechanism for overriding a change made by the technician. Also, or instead, in instances in which the first input command and the second input command are received at the same time or substantially the same time, the second input command can override the first input command to reduce the likelihood that the second input command (associated with the physician) is inadvertently overwritten or otherwise undone by the first input command.

In some implementations, the exemplary method <NUM> can further include modifying <NUM> one or more display features of the second set of input options based on the received 174b navigation command and/or second input command. Modifying <NUM> the one or more display features of the second set of input options can be based, for example, on detecting an initial navigation or initial input command (e.g., after some predetermined period of inactivity). Additionally, or alternatively, modifying <NUM> the one or more display features of the second set of input options can include changing the second set of input options from the modified configuration to the baseline configuration if a time between receipt of a first input command and receipt of a second input command exceeds a predetermined inactivity threshold period.

In general, modifying <NUM> the one or more display features of the second set of input options can include changing between a baseline configuration and a modified configuration of the display features according to any of the various different methods described herein. Thus, for example, the relative size of the displayed second set of input options to the size of the displayed first set of input options can be greater in the modified configuration than in the baseline configuration to facilitate reading the second set of input options by the physician. In addition, or in the alternative, the opacity of the displayed second set of input options compared to the opacity of the first set of input options can be greater in the modified configuration than in the baseline configuration to facilitate drawing the physician's attention to the appropriate location on the graphical user interface. Additionally, or alternatively, the position of the second set of input options relative to the first set of input options on the graphical user interface can be different in the modified configuration than in the baseline configuration, with the change in position, for example, advantageously drawing the physician's attention toward the second set of input options.

While certain implementations have been described, other implementations are additionally or alternatively possible.

For example, while a second input device has been described as being disposed along a handle of a catheter, other implementations are additionally or alternatively possible. As an example, referring now to <FIG>, a system <NUM>' can include a second input device <NUM> separate from a catheter <NUM>'. For the sake of efficient and clear description, elements designated by prime (') element numbers in <FIG> should be understood to be analogous to elements with unprimed element numbers described herein, unless otherwise indicated or made clear from the context, and, thus, are not described separately from primed or unprimed counterparts, except to highlight certain aspects. Thus, for example, element number <NUM>' in <FIG> should be understood to be a graphical user interface analogous to the graphical user interface <NUM> (<FIG> and <FIG>), unless otherwise indicated or made clear from the context.

The second input device <NUM> can be, for example, in communication with the catheter interface unit <NUM>' to transmit navigation commands and/or input commands to a second portion of the graphical user interface <NUM>' according to any of the various different methods described herein. Because the second input device <NUM> is not disposed along the catheter <NUM>', the second input device <NUM> can be advantageously in wireless communication with the catheter interface unit <NUM>' to reduce the number of wires in the vicinity of the physician during the medical procedure.

In general, the second input device <NUM> can be manually operable by the physician while the physician manipulates the catheter <NUM>'. For example, the physician may pick up the second input device <NUM> as needed, and then put the second input device <NUM> down if both hands are needed for manipulation of the catheter <NUM>'.

As another example, while the second input device has been described as being disposed along the handle of the catheter or as separate from the catheter, other implementations are additionally or alternatively possible. For example, referring now to <FIG>, a system <NUM>" can include a second input device <NUM> securable to a catheter shaft <NUM>" of a catheter <NUM>". For the sake of efficient and clear description, elements designated by double prime (") element numbers in <FIG> should be understood to be analogous to elements with unprimed and/or primed element numbers described herein, unless otherwise indicated or made clear from the context, and, thus, are not described separately from primed or unprimed counterparts, except to highlight certain aspects. Thus, for example, element number <NUM>" in <FIG> should be understood to be a catheter analogous to the catheter <NUM> (<FIG> and <FIG>) and the catheter <NUM>' (<FIG>), and element number <NUM>" in <FIG> should be understood to be a catheter shaft analogous to the catheter shaft <NUM> (<FIG> and <FIG>) and the catheter shaft <NUM>' (<FIG>), unless otherwise indicated or made clear from the context.

The second input device <NUM> can be in communication (e.g., wireless communication) with the catheter interface unit <NUM>" to transmit navigation commands and/or input commands to a second portion of the graphical user interface <NUM>" according to any of the various different methods described herein. As described in greater detail below, securing the second input device <NUM> to the catheter shaft <NUM>" of the catheter <NUM>" can facilitate locating the second input device <NUM> by the physician without requiring the physician to divert his or her attention from the medical procedure. Additionally, or alternatively, as also described in greater detail below, securing the second input device <NUM> to the catheter shaft <NUM>" can facilitate single-handed operation of the second input device <NUM> during a medical procedure.

In general, the second input device <NUM> can include a user interface <NUM>, a wireless transmitter <NUM>, and a housing <NUM> carrying the user interface <NUM> and the wireless transmitter <NUM>. The user interface <NUM> can include one or more inputs 130a", 130b", 130c", 130d", and 130e", which can be any one or more of the various different inputs described herein. In use, the physician can depress or otherwise engage the one or more inputs 130a", 130b", 130c", 130d", and 130e", and the wireless transmitter <NUM> can be in communication with the user interface <NUM> to send one or more navigation and/or control commands to a remote processor, such as the processing unit <NUM>", according to any one or more of the various different methods described herein. Thus, for example, the physician can manipulate the user interface <NUM> to send one or more navigation and/or control commands to the processing unit <NUM>" based on input options displayed on a portion of a graphical user interface, such as the graphical user interface <NUM>", according to any of the various different methods described herein.

The second input device <NUM> can be at least one of electrically and fluidically isolated from a handle <NUM>" and the catheter shaft <NUM>" to facilitate, for example, robust operation of the second input device <NUM> throughout the medical procedure, independent of the catheter <NUM>". For example, the housing <NUM> can define a volume, and the wireless transmitter <NUM> can be disposed within the volume defined by the housing <NUM>. The one or more inputs 130a", 130b", 130c", 130d", and 130e" can be at least partially disposed outside of the volume defined by the housing <NUM> such that the one or more inputs 130a", 130b", 130c", 130d", 130e" form at least a portion of an outer surface of the second input device <NUM> and are accessible by the physician. In certain instances, the volume defined by the housing <NUM> can be substantially resistant to fluid ingress such that the wireless transmitter <NUM> is protected from fluid that may contact the second input device <NUM> during a medical procedure. Additionally, or alternatively, the one or more inputs 130a", 130b", 130c", 130d", 130e" can be arranged relative to the housing <NUM> to reduce the likelihood of fluid ingress into the volume defined by the housing <NUM>.

In certain implementations, the housing <NUM> can be securable to an outer circumference of the catheter shaft <NUM>" with the user interface <NUM> partially constrained in at least one direction relative to the catheter shaft <NUM>". Such constrained movement of the user interface <NUM> relative to the catheter shaft <NUM>" can, for example, facilitate locating the user interface <NUM> by the physician during a medical procedure. That is, given that the user interface <NUM> is at least partially constrained in at least one direction relative to the catheter shaft <NUM>", the physician can find the user interface <NUM> by moving his or her hand along the catheter shaft <NUM>" to find the user interface <NUM>. Thus, the catheter shaft <NUM>" itself can act as a guide for the physician, which can reduce the need for the physician to divert his or her attention away from the graphical user interface <NUM>" to find the user interface <NUM> of the second input device <NUM>.

As an example, with the housing <NUM> secured to the outer circumference of the catheter shaft <NUM>", the user interface <NUM> can be at least partially constrained in a radial direction relative to the catheter shaft <NUM>". As used herein, partial constraint in the radial direction can include movement of less than about <NUM> (e.g., less than about <NUM>) and, therefore, can include complete constraint in the radial direction. In certain implementations, the user interface <NUM> can be movable along an axis defined by the catheter shaft <NUM>" and, thus, partial constraint in the radial direction can include radial movement sufficient to allow the housing <NUM> and the user interface <NUM> to move along the axis defined by the catheter shaft <NUM>". It should be appreciated that, in such implementations in which the housing <NUM> and the user interface <NUM> are movable along the axis defined by the catheter shaft <NUM>", the housing <NUM> and the user interface <NUM> can be movable between the handle <NUM>" of the catheter <NUM>" and a sheath at the insertion site of the catheter <NUM>" into the patient.

Additionally, or alternatively, the housing <NUM> can be securable in a fixed axial position relative to the catheter shaft <NUM>". For example, an interference fit between the outer circumference of the catheter shaft <NUM>" and the housing <NUM> can hold the housing <NUM> in a fixed axial position relative to the catheter <NUM>" during a medical procedure. The fixed axial position can be any of various different axial positions along the catheter shaft <NUM>". For example, the housing <NUM> can be secured to a proximal end region <NUM>" of the catheter shaft <NUM>" with the housing <NUM> extending distal to the handle <NUM>" of the catheter <NUM>". Additionally, or alternatively, the housing <NUM> can be secured to the proximal end region <NUM> of the catheter shaft <NUM>" such that the housing <NUM> is adjacent to the handle <NUM>".

With the housing <NUM> at least partially constrained in at least one direction relative to the catheter shaft <NUM>", the user interface <NUM> can be rotatable about the catheter shaft <NUM>" and, optionally, rotatable about the handle <NUM>" coupled to the catheter shaft <NUM>". For example, the user interface <NUM> can be rotatable about an axis of rotation coaxial with an axis defined by the catheter shaft <NUM>" (e.g., freely rotatable <NUM> degrees about the axis of rotation such that the user interface <NUM> is rotatable through multiple revolutions about the axis of rotation). Rotation of this type can facilitate, for example, single-handed operation of the second input device <NUM> by the physician. That is, the physician can rotate the user interface <NUM> as necessary to align the user interface <NUM> in a desired radial orientation.

The housing <NUM> can be at least partially formed of a material compatible with sterilization (e.g., any of the various different sterilization techniques described herein) and, in some instances, the housing <NUM> can be sterilized prior to being secured to the catheter shaft <NUM>". Additionally, or alternatively, the second input device <NUM> can include a cover enclosing the housing <NUM> and the user interface <NUM>, and the cover can be formed of a material compatible with sterilization such as any of the various sterilization techniques described herein. A cover separable from the housing <NUM> can be useful, for example, in implementations in which the housing <NUM> carries one or more components (e.g., batteries) that are not readily compatible with sterilization. In such instances, the cover can be sterilized apart from the second input device <NUM> and then used to cover the second input device <NUM> prior to securing the second input device <NUM> to the catheter shaft <NUM>".

In general, the housing <NUM> can be securable to the catheter shaft <NUM>" without the use of tools. The ability to secure the housing <NUM> to the catheter shaft <NUM>" in this way can for example, facilitate securing the housing <NUM> to the catheter shaft <NUM>" by the physician or other medical personnel in the sterile field.

As an example, the housing <NUM> can include a first section <NUM> and a second section <NUM>, each defining a portion (e.g., substantially half) of a recess <NUM>. The first section <NUM> and the second section <NUM> can be releasably engageable with one another to position the recess <NUM> about at least a portion of an outer circumference of the catheter shaft <NUM>". The releasable engagement between the first section <NUM> and the second section <NUM> can be achieved through an interference fit between mating features of the first section <NUM> and the second section <NUM>. Further, or instead, the first section <NUM> can include a first material and the second section <NUM> can include a second material magnetically attracted to the first material such that placing the first section <NUM> and the second section <NUM> in proximity to one another results in coupling the first section <NUM> to the second section <NUM> through the magnetic force between the first material and the second material.

In certain instances, the first section <NUM> and the second section <NUM> can be coupled to one another at a hinge <NUM> pivotable to move the first section <NUM> and the second section <NUM> in a clamshell arrangement into engagement with each other to position the recess <NUM> about the catheter shaft <NUM>". The hinge <NUM> can be useful, for example, for accounting for manufacturing tolerances associated with the outer circumference of the catheter shaft <NUM>". Additionally, or alternatively, the hinge <NUM> can be useful for reducing the number of parts needed to be manipulated by the physician or other medical personnel in the sterile field to secure the second input device <NUM> to the catheter shaft <NUM>".

As an additional, or alternative, example, the housing <NUM> can include a clip defining the recess <NUM> and positionable about at least a portion of the outer circumference of the catheter shaft <NUM>". For example, the clip may be "U-shaped" such that the recess <NUM> is defined by legs that are movable away from one another to accept the catheter shaft <NUM>" and biased back toward one another to hold the second input device <NUM> about the outer circumference of the catheter shaft <NUM>".

The recess <NUM> can be sized, for example, to fit about a standard catheter size such that the second input device <NUM> can be securable to any of various different catheters of a given standard catheter size, including catheters made by different manufacturers. Additionally, or alternatively, the recess <NUM> can be sized to account for manufacturing tolerances associated with a given standard catheter size.

With the housing <NUM> secured to the outer circumference of the catheter shaft <NUM>", the user interface <NUM> can be suitable for single-handed operation by the physician during a medical procedure. Such single-handed operation can facilitate, for example, simultaneous or substantially simultaneous operation of the user interface <NUM> with one hand while the physician holds the catheter shaft <NUM>" or the handle <NUM>" with the other hand. Additionally, or alternatively, the remote communication device <NUM> can be secured to the outer circumference of the catheter shaft <NUM>" at a position distal to an articulation controller <NUM>" of the catheter <NUM>". The articulation controller <NUM>" can be, for example, any of the various different articulation controllers described herein to modify a distal end region <NUM>" of the catheter shaft <NUM>". In certain implementations, the physician can operate the articulation controller <NUM>" with one hand while simultaneously or substantially simultaneously operating the user interface <NUM> with the other hand.

In general, with the housing <NUM> secured to the outer circumference of the catheter shaft <NUM>", the one or more inputs 130a", 130b", 130c", 130d", 130e" can be arranged relative to the catheter shaft <NUM>" such that manipulation of the one or more inputs 130a", 130b", 130c", 130d", 130e" does not cause unintended movement of the housing <NUM> relative to the catheter shaft <NUM>". For example, the one or more inputs 130a", 130b", 130c", 130d", 130e" of the user interface <NUM> can be any of the various different inputs described herein and can be depressible or otherwise engageable in a direction parallel to the at least one partially constrained direction of the user interface <NUM> such that the constrained movement of the user interface <NUM> can counter the force exerted on the one or more inputs 130a", 130b", 130c", 130d", and 130e" and, thus, restricts undesired movement of the second input device <NUM> as one or more inputs are received. Additionally, or alternatively, in implementations in which the user interface <NUM> is rotatable about an axis defined by the catheter shaft <NUM>", the one or more inputs 130a", 130b", 130c", 130d", 130e" can be depressible in a direction transverse to the axis of rotation of the user interface <NUM> such that providing an input is less likely to result in inadvertent rotation of the user interface <NUM> about the catheter shaft <NUM>". It should be appreciated from these examples that such an arrangement of forces can facilitate single-handed operation of the second input device <NUM>. That is, the physician can use a single hand to depress the one or more inputs 130a", 130b", 130c", 130d", 130e" without requiring the use of a second hand to hold the user interface <NUM> in place as input is provided at the one or more inputs 130a", 130b", 130c, 130d", 130e".

In certain implementations, the second input device <NUM> can further include a power source <NUM> carried by the housing <NUM> and in electrical communication with the wireless transmitter <NUM> to power the wireless transmitter <NUM>. The power source <NUM> can be for example one or more batteries. Additionally, or alternatively, the power source <NUM> can be releasably coupled to the housing to facilitate replacement or recharging of the power source <NUM> (e.g., during or in between medical procedures).

In some implementations, the second input device <NUM> can further include a processor <NUM> in communication with the user interface <NUM> and the wireless transmitter <NUM>. For example, the processor <NUM> can receive a signal from the one or more inputs 130a", 130b", 130c", 130d", 130e" and send a corresponding signal to the wireless transmitter <NUM> for transmission. In addition to, or instead of, the processor <NUM>, the second input device <NUM> can include circuitry to receive a signal from the one or more inputs 130a", 130b", 130c", 130d", 130e" and send a corresponding signal to the wireless transmitter <NUM>.

While second input devices have been described as including housings that can be clamped onto a shaft of a catheter, other implementations are additionally or alternatively possible. For example, a second input device can include a housing through which a distal end region of a catheter can be moved. Through such movement of the distal end region of the catheter through the housing, the second device can be disposed about a shaft of the catheter. Thus, in certain implementations, the distal end region of the catheter can be introduced into a patient through the housing of the second input device. For example, the housing of the second input device can include an introducer sheath positionable, as is known in the art, in vasculature of the patient and through which the distal end region of the catheter can be introduced into the vasculature of the patient during a procedure. Additionally, or alternatively, the housing of the second input device can include an insertion sleeve positionable relative to the introducer sheath, as is also known in the art. In use, the distal end region of the catheter can be moved through the insertion sleeve and into vasculature of the patient via an introducer sheath positioned in the vasculature of the patient.

While second input devices have been described as being hand operated, other implementations are additionally or alternatively possible. For example, a second input device can include a foot pedal operable by the physician tapping one or more inputs on the foot pedal to navigate through a second portion of a graphical user interface according to one or more of the methods described herein.

While second input devices have been described as being physical devices manipulated by the physician, other implementations are additionally or alternatively possible. For example, a second input device can be implemented through a virtual reality system (such as Leap Motion available from Leap Motion, Inc. of San Francisco, California). In such an implementation, a physician's hand or hands can interact with a virtual reality environment to navigate and provide inputs to the second portion of the graphical user interface according to any one or more of the methods described herein.

While second input devices have been described as being operated with one or more of a physician's limbs, other implementations are additionally or alternatively possible. For example, the second input device can be responsive to one or more voice commands (e.g., "up," "down," "right," "left," and "enter") to navigate and provide inputs to the second portion of the graphical user interface according to any one or more of the methods described herein. Such a second input device responsive to voice commands can, for example, reduce the need for separate hardware in the sterile field with the physician.

The above systems, devices, methods, processes, and the like may be realized in hardware, software, or any combination of these suitable for a particular application. The hardware may include a general-purpose computer and/or dedicated computing device. This includes realization in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable devices or processing circuitry, along with internal and/or external memory. This may also, or instead, include one or more application specific integrated circuits, programmable gate arrays, programmable array logic components, or any other device or devices that may be configured to process electronic signals.

It will further be appreciated that a realization of the processes or devices described above may include computer-executable code created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software. In another aspect, the methods may be embodied in systems that perform the steps thereof, and may be distributed across devices in a number of ways. At the same time, processing may be distributed across devices such as the various systems described above, or all of the functionality may be integrated into a dedicated, standalone device or other hardware. In another aspect, means for performing the steps associated with the processes described above may include any of the hardware and/or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

Embodiments disclosed herein may include computer program products comprising computer-executable code or computer-usable code that, when executing on one or more computing devices, performs any and/or all of the steps thereof. The code may be stored in a non-transitory fashion in a computer memory, which may be a memory from which the program executes (such as random access memory associated with a processor), or a storage device such as a disk drive, flash memory or any other optical, electromagnetic, magnetic, infrared or other device or combination of devices.

In another aspect, any of the systems and methods described above may be embodied in any suitable transmission or propagation medium carrying computer-executable code and/or any inputs or outputs from same.

The method steps of the implementations described herein are intended to include any suitable method of causing such method steps to be performed, consistent with the patentability of the following claims, unless a different meaning is expressly provided or otherwise clear from the context. So, for example performing the step of X includes any suitable method for causing another party such as a remote user, a remote processing resource (e.g., a server or cloud computer) or a machine to perform the step of X. Similarly, performing steps X, Y and Z may include any method of directing or controlling any combination of such other individuals or resources to perform steps X, Y and Z to obtain the benefit of such steps. Thus, method steps of the implementations described herein are intended to include any suitable method of causing one or more other parties or entities to perform the steps, consistent with the patentability of the following claims, unless a different meaning is expressly provided or otherwise clear from the context. Such parties or entities need not be under the direction or control of any other party or entity, and need not be located within a particular jurisdiction.

It should further be appreciated that the methods above are provided by way of example. Absent an explicit indication to the contrary, the disclosed steps may be modified, supplemented, omitted, and/or re-ordered without departing from the scope of this disclosure.

Claim 1:
A method comprising:
receiving a signal from a cardiac catheter, the signal indicative of a location of the cardiac catheter in a cavity of a patient's heart;
at the same time, displaying (i) a graphical representation of the cavity of the patient's heart on a first portion of a graphical user interface, (ii) a first set of input options on the first portion of the graphical user interface, and (iii) a second set of input options on a second portion of the graphical user interface,
wherein the graphical representation is based on the received location signal from the cardiac catheter;
receiving, from a first input device, a first input command based on the first set of input options; wherein the first input device is a computer; wherein the first input device is operated by a first user;
receiving, from a second input device, a second input command based on the second set of input options and navigation commands for moving, within the second portion of the graphical user interface, between the options in the second set of input options;
wherein the second input device is a remote device and receiving the second input command includes receiving an input command from the remote device; wherein the second input device is operated by a second user, the second user being a physician; wherein the second input device is coupled to a handle of the cardiac catheter;
wherein the second set of input options represented on the second portion of the graphical user interface correspond to a current state of a state machine having a plurality of states;
wherein the input of the second input device is used to send navigation commands to a catheter interface unit (<NUM>) to navigate through the states of the state machine and the input of the second input device is used to provide one or more input commands to the catheter interface unit to select a particular state of the state machine;
wherein each state of the state machine is associated with different input options; and
based on the first input command and the second input command, modifying the graphical representation in the first portion of the graphical user interface.