Telecommunications and control systems for robotic interventional procedures.

Abstract

To provide a remote communications and control system for devices used in robotic interventional procedures.SOLUTION: A method for using a control center at a remote site to control operation of a robotic medical device system at a local site includes transmitting a control signal from the control center to the robotic medical device system, determining a delay in transmission of the control signal, and operating the robotic medical device system based on comparing the delay to a threshold delay value.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Application No. 62 / 719,757, filed August 20, 2018, and entitled "Remote Communication and Control System for Robotic Medical Devices," and U.S. Application No. 62 / 673,307, filed May 18, 2018, and entitled "Remote Communication and Control System for Robotic Medical Devices," both of which are incorporated by reference in their entireties.

[0002] The present invention relates generally to the field of robotic medical procedure systems, and more particularly to remote communication and control systems for devices used in robotic interventional procedures. [Background technology]

[0003] Catheters (and other elongated medical devices) can be used for many minimally invasive medical procedures aimed at the diagnosis and treatment of various vascular diseases, including neurovascular intervention (NVI), also known as neurointerventional surgery, percutaneous coronary intervention (PCI), and peripheral vascular intervention (PVI). These procedures typically involve navigating a guidewire through the vasculature and advancing a working catheter over the guidewire to perform the treatment. A catheterization procedure begins by gaining access to an appropriate vessel, such as an artery or vein, through a sheath or guide catheter using standard percutaneous techniques. The sheath or guide catheter is then advanced over the diagnostic guidewire to a primary location, such as the internal carotid artery for NVI, the coronary ostium for PCI, or the superficial femoral artery for PVI. A guidewire appropriate for the vasculature is then guided through the sheath or guide catheter to the target location within the vasculature. In certain situations, such as tortuous anatomy, a support catheter or microcatheter is inserted over the guidewire to aid in guiding the guidewire. A physician or operator can use an imaging system (e.g., fluoroscope) to obtain a cine with contrast injection to select a fixed frame to use as a roadmap for guiding the guidewire or catheter to a target location, such as a lesion. The contrast images are obtained while the physician delivers the guidewire or catheter device so the physician can verify that the device is moving along the correct path to the target location. Using fluoroscopy to view the anatomy, the physician manipulates the proximal end of the guidewire or catheter to guide the distal tip into the appropriate vessel and toward the lesion while avoiding progression into side branches.

[0004] Robotic catheterization systems have been developed that are used to assist physicians in performing catheterization procedures such as NVI, PCI, and PVI. Examples of neurovascular intervention (NVI) catheterization procedures include coil embolization of aneurysms, liquid embolization of arteriovenous malformations, and mechanical thrombectomy of large vessel occlusions in the setting of acute ischemic stroke. In NVI, physicians use robotic systems to manipulate neurovascular guidewires and microcatheters to gain access to the lesion to perform treatment and restore normal blood flow. This access is made possible by a sheath or guide catheter, but intermediate catheters may be required for more distal areas or to provide adequate support for the microcatheter and guidewire. The distal tip of the guidewire is guided into or through the lesion, depending on the type and treatment of the lesion. For treatment of an aneurysm, a microcatheter is advanced into the lesion, the guidewire is removed, and several coils are deployed through the microcatheter into the aneurysm and used to embolize the aneurysm. For treatment of an arteriovenous malformation, a liquid embolic agent is injected into the malformation via the microcatheter. Mechanical thrombectomy to treat vascular occlusion can be accomplished by aspiration or by the use of a stented embolic retriever. Aspiration can be performed directly through a microcatheter or with a large bore aspiration catheter. Once the aspiration catheter reaches the lesion, negative pressure is applied through the catheter to remove the thrombus. Alternatively, the thrombus may be removed by deploying a stented embolic retriever through the microcatheter. Once the thrombus is integrated into the stented embolic retriever, it is retrieved by retracting the stented embolic retriever and microcatheter back into the guide catheter.

[0005] In PCI, physicians use a robotic system to manipulate a coronary guidewire to gain access to the lesion, perform treatment, and restore normal blood flow. This access is achieved by placing a guide catheter at the coronary ostium. The distal tip of the guidewire is guided through the lesion, and due to complex anatomy, a microcatheter is used to properly support the guidewire. Blood flow is restored by delivering and deploying a stent or balloon at the lesion. The lesion requires preparation prior to stent placement, either by delivering a balloon to pre-dilatate the lesion or by performing atherectomy using, for example, a laser or rotational atherectomy catheter and balloon over the guidewire. Imaging and physiological measurements can also be performed by using an imaging catheter or FFR measurements to determine the appropriate treatment.

[0006] In PVI, physicians use a robotic system to restore blood flow by performing treatment using techniques similar to NVI. The distal tip of a guidewire is guided through the lesion, and a microcatheter is used to give the guidewire adequate support to target the complex anatomy. Blood flow is restored by delivering and deploying a stent or balloon to the lesion. As with PCI, pretreatment of the lesion and diagnostic imaging may also be used.

[0007] An operator of a robotic system used in a medical procedure typically has a location in the same room or adjacent to the patient and the robotic system. However, it may be desirable to allow an operator located in a remote location (e.g., in a different building, different city) to operate the robotic system and perform the medical procedure. A system that allows an operator in a remote location to control and operate the robotic medical procedure system, for example, gives patients in small communities access to specialists that may not be available in their area. In addition, patients who need emergency medical treatment can be treated at a local hospital by a specialist in a remote location, thereby reducing the time to perform an interventional procedure. For example, to treat a patient with an acute ischemic stroke due to a large vessel occlusion (LVO) or to treat a patient with an ST-segment elevation myocardial infarction (STEMI) as soon as possible, it is advantageous to complete the interventional procedure. Various telesurgery systems have been developed for general vascular, cardiac, and urological procedures. For example, telesurgery systems have been used for laparoscopic procedures. There are many challenges to developing a system in which an operator performs a medical procedure remotely. A secure network connection over a network (e.g., the Internet) needs to be established and maintained. Delays and jitter in the transmission of control signals and images affect the safety of the procedure as well as the stability of the system. Deadlocks regarding the control of the local medical treatment system may occur between local and remote locations. There may also be challenges in providing a many-to-many configuration that allows multiple remote locations to connect to and operate the local medical treatment system. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] US Patent Application Publication No. 2011 / 0306986 (A1) [Patent Document 2] U.S. Pat. No. 8,340,819 [Patent Document 3] US Patent Application Publication No. 2012 / 0191464 (A1) Summary of the Invention

[0009] According to one embodiment, a method using a control center at a remote site to control operation of a robotic medical device system at a local site includes transmitting a control signal from the control center to the robotic medical device system, determining a delay in transmitting the control signal, and operating the robotic medical device system based on a comparison of the delay to a threshold delay value.

[0010] According to another embodiment, a method using a control center at a remote site to control operation of an elongated medical device in a robotic medical device system at a local site includes receiving a control signal from a control center, determining a delay in transmitting the control signal, determining a threshold delay value based on at least one parameter of the robotic medical device system, comparing the delay to the threshold delay value, and adjusting operation of the elongated medical device based on the comparison of the delay to the threshold delay value.

[0011] According to another embodiment, a method using a control center at a remote site to control operation of a robotic medical device system at a local site includes receiving a control signal from the control center, determining a delay in transmitting the control signal, comparing the delay to a threshold delay value and adjusting a velocity of a medical device of the robotic medical device system based on the delay if the delay is less than the threshold delay value, and setting the velocity of the medical device to zero if the delay is greater than the threshold delay value.

[0012] According to another embodiment, a system for controlling a medical device includes a control center having a location at a remote site. The control center includes a control console andconnection a first command and control module, and a connection and a first clock configured to receive time data from a reference time source using a precision time protocol, the first clock being configured to receive time data from a reference time source. The system further includes a robotic medical device system at a local site, the robotic medical device system being in communication with the control center. The robotic medical service system includes at least one medical device ... connection a second command and control module for communicating with the first command and control module; connection and a second clock using the precision time protocol; The second The clock is configured to receive time data from a reference time source. The control center and the remote medical device communicate via a secure tunnel. A control console in the control center is configured to communicate with and control at least one medical device. do.

[0013] According to another embodiment, a system for managing control of at least one medical device by a remote site and a local site includes a control center having a location at the remote site, a robotic medical device system in communication with the control center at the local site, and a virtual control token that determines a control state of the control center and the robotic medical device system, the location of the virtual control token determining the control state.

[0014] According to another embodiment, a method for reducing bandwidth of data transmission from a robotic medical device system at a local site to a control center at a remote site, the control center configured to control operation of the robotic medical device system, includes generating a display of data at the robotic medical device system, the data including at least one image and non-image patient information, the method further includes selecting a section of the generated display, transmitting the selected section of the display to a control center, and displaying the selected section on a display of the control center. [Brief description of the drawings]

[0015] The present invention will become more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which like reference numerals refer to like elements and in which:

[0016] [Figure 1] FIG. 1 is a perspective view of an exemplary catheter treatment system according to one embodiment. [Diagram 2] FIG. 1 is a schematic block diagram of an exemplary catheter treatment system according to one embodiment. [Diagram 3] FIG. 1 is a block diagram of a communication and control system of a robotic medical device system according to one embodiment. [Figure 4] FIG. 1 is a block diagram of a communication and control system of a robotic medical device system according to one embodiment. [Diagram 5] 1 illustrates a method for controlling the operation of a robotic medical device system according to one embodiment. [Figure 6] 1 illustrates an exemplary graphical user interface of a control center according to one embodiment. [Figure 7] 1 illustrates an exemplary graphical user interface of a robotic medical device system according to one embodiment. [Figure 8] 1 illustrates an exemplary display of data and images for a robotic medical device system at a local site according to one embodiment. [Figure 9] 1 illustrates an exemplary display of a control center at a remote site with hemodynamic data according to one embodiment. [Figure 10] 1 illustrates an exemplary display of a control center at a remote site according to one embodiment. [Figure 11] 1 illustrates an exemplary user interface when neither the control center nor the robotic medical device system is in control of a robotic medical device according to one embodiment. [Figure 12] 1 illustrates an exemplary user interface when the robotic medical device system is in control of a robotic medical device according to one embodiment. [Figure 13] 1 illustrates an exemplary user interface when the control center is in control of a robotic medical device according to one embodiment. [Figure 14] 1 illustrates an exemplary display of a control center at a remote site according to one embodiment. [Figure 15] 1 illustrates an exemplary display of a control center at a remote site according to one embodiment. [Figure 16] FIG. 1 is a block diagram of a many-to-many configuration of multiple control centers and multiple robotic medical device systems according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] FIG. 1 is a perspective view of an exemplary catheter treatment system according to one embodiment. In FIG. 1, the catheter treatment system 100 can be used to perform catheter-based medical procedures, such as percutaneous interventional procedures, such as percutaneous coronary intervention (PCI), neurovascular interventional procedures (e.g., treatment of large vessel occlusion (LVO)), PCI for ST-elevation myocardial infarction, peripheral vascular interventional procedures, and the like. Catheter-based medical procedures can include diagnostic catheter procedures in which one or more catheters (or other elongated medical devices) are used to aid in diagnosing a patient's disease. For example, during one embodiment of a catheter-based diagnostic procedure, contrast is injected through a catheter into one or more coronary arteries and images of the patient's heart are taken. Catheter-based medical procedures can also include catheter-based therapeutic procedures (e.g., angioplasty, stenting, treatment of peripheral vascular disease, etc.), during which catheters (or other elongated medical devices) are used to treat a disease. However, it should be noted that one skilled in the art would recognize that certain specific percutaneous interventional devices or components (e.g., type of guidewire, type of catheter, etc.) are selected based on the type of procedure being performed. The catheter procedure system 100 can perform any number of catheter-based medical procedures, with minor adjustments to accommodate the specific percutaneous interventional device used in the procedure. In particular, while the embodiments of the catheter procedure system 100 described herein are primarily described in connection with diagnosing and / or treating coronary artery disease, the catheter procedure system 100 may be used to diagnose and / or treat any type of disease or condition suitable for diagnosis and / or treatment via a catheter-based procedure.

[0018] The catheterization system 100 includes a laboratory unit 106 and a workstation 116. The catheterization system 100 includes a robotic catheterization system, shown as a bedside system 110, located adjacent to a patient 102 in the laboratory unit 106. The patient 102 is supported on a table 108. In general, the bedside system 110 is equipped with suitable percutaneous interventional devices or other components (e.g., guidewires, guide catheters, working catheters such as balloon catheters and stent delivery systems, contrast agents, drugs, diagnostic catheters, etc.) that allow a user to perform a catheter-based medical procedure via the robotic system by manipulating various controls, such as controls located at the workstation 116. The bedside system 110 may include any number and / or combination of components to provide the bedside system 110 with the functionality described herein. The bedside system 110 may include, among other things, a robotic arm, 112 A drive assembly supported by 111 The drive assembly 111 includes a cassette mounted to a robotic drive 113 that can be used to drive an elongated medical device 115, such as a catheter or guidewire. 114 For example, the drive assembly 111 may be used to automatically feed a guidewire into a guide catheter placed in an artery of the patient 102.

[0019] The bedside system 110 is in communication with the workstation 116, and signals generated by user input at the workstation 116 can be transmitted to the bedside system 110 to control various functions of the bedside system 110. The bedside system 110 may also provide feedback signals (e.g., operating conditions, warning signals, error codes, etc.) to the workstation 116. The bedside system 110 may be connected to the workstation 116 via a communication link 140 (shown in FIG. 2), which may be a wireless connection, a cable connection, or any other means by which communication can occur between the workstation 116 and the bedside system 110.

[0020] The workstation 116 is a catheterization system. 100 A user interface configured to receive user input to operate various components or systems of the 126 The user interface 126 includes a controller 118 that allows a user to control the bedside system 110 to perform a catheter-based medical procedure. For example, the controller 118 can be configured to cause the bedside system 110 to perform various tasks using various percutaneous interventional devices (e.g., elongated medical devices) that may be equipped with the bedside system 110 (e.g., to advance, retract or rotate a guidewire, advance, retract or rotate a working catheter, advance, retract or rotate a guide catheter, inflate or deflate a balloon disposed in a catheter, position and / or deploy a stent, inject contrast into a catheter, inject a drug into a catheter, or perform any other function that may be performed as part of a catheter-based medical procedure). The drive assembly 111 includes various drive mechanisms that effect movement (e.g., axial and rotational movement) of components of the bedside system 110, including the percutaneous interventional devices.

[0021] In one embodiment, the controller 118 includes a touch screen 124, one or more joysticks 128, and buttons 130, 132. The joystick 128 can be configured to advance, retract, or rotate various components of a percutaneous intervention device, such as a guidewire, a guide catheter, or a working catheter. The buttons 130, 132 can include, for example, an emergency stop button and a multiplier button. When the emergency stop button is pressed, a relay is triggered to cut off power to the bedside system 110. The multiplier button acts to increase or decrease the speed at which an associated component is moved in response to manipulation of the controller 118. In one embodiment, the controller 118 can include one or more controls or icons (not shown) displayed on the touch screen 124 that, when activated, cause the operation of a component of the catheter procedure system 100. The controller 118 can also include balloon or stent controls configured to inflate or deflate the balloon and / or stent. Each controller can include one or more buttons, joysticks, touch screen, etc., as desired to control the particular component to which the controller is dedicated. In addition, the touch screen 124 may display one or more icons (not shown) associated with various portions of the controller 118 or with various components of the catheter procedure system 100 .

[0022] The user interface 126 is a first monitor. (or display) 120 and the second monitor (or display)122. In other embodiments, the user interface 126 may include one display or more than two displays. The first monitor 120 and the second monitor 122 may be configured to display information or patient-specific data to a user having a location at the workstation 116. For example, the first monitor 120 and the second monitor 122 may be configured to display image data (e.g., x-ray images, MRI images, CT images, ultrasound images, etc.), hemodynamic data (e.g., blood pressure, heart rate, etc.), patient record information (e.g., medical history, age, weight, etc.). In addition, the first monitor 120 and the second monitor 122 may be configured to display procedure-specific information (e.g., procedure time, catheter or guidewire position, amount of drug or contrast agent delivered, etc.). The monitor 120 and the monitor 122 may be configured to display information regarding the position of the guide catheter. Additionally, 1. Monitor 120 and Second Monitor 122 may be configured to display information providing functionality (shown in FIG. 3) associated with controller 134. In another embodiment, user interface 126 includes a single screen of sufficient size to display one or more of the display and / or touch screen components described herein.

[0023] The catheter procedure system 100 also includes an imaging system 104 disposed within the laboratory unit 106. The imaging system 104 may be any medical imaging system that may be used in conjunction with a catheter-based medical procedure (e.g., non-digital x-ray, digital x-ray, CT, MRI, ultrasound, etc.). In an exemplary embodiment, the imaging system 104 is a digital x-ray imager in communication with a workstation 116. In one embodiment, the imaging system 104 may include a C-arm (not shown) that allows the imaging system 104 to partially or fully rotate around the patient 102 to obtain images at different angular positions relative to the patient 102 (e.g., sagittal, caudal, anterior-posterior, etc.).

[0024] The imaging system 104 may be configured to capture x-ray images of appropriate regions of the patient 102 during a particular procedure. For example, the imaging system 104 may be configured to capture one or more x-ray images of the heart to diagnose a cardiac condition. The imaging system 104 may also be configured to capture one or more x-ray images (e.g., real-time images) during a catheter-based medical procedure to assist a user of the workstation 116 in properly positioning a guidewire, guide catheter, stent, etc., during the procedure. One or more images may be displayed on the first monitor 120 and / or the second monitor 122. In particular, the images may be displayed on the first monitor 120 and / or the second monitor 122 to allow a user to accurately maneuver, for example, a guide catheter to an appropriate position.

[0025] Referring to FIG. 2, a block diagram of a catheter treatment system 100 according to an exemplary embodiment is shown. The catheter treatment system 100 may include a controller 134. The controller 134 may be part of the workstation 116 (shown in FIG. 1). The controller 134 may generally be an electronic control unit suitable for providing the catheter treatment system 100 with the various functions described herein. For example, the controller 134 may be an embedded system, a dedicated circuit, a general-purpose system programmed with the functionality described herein, etc. The controller 134 may control one or more of the bedside system 110, the control device 118, the medical device 116, the medical ... 1. Monitor 120 and Second Monitor 122, the imaging system 104, and patient sensors 136 (e.g., an electrocardiogram ("ECG") device, an electroencephalogram ("EEG") device, a blood pressure monitor, a temperature monitor, a heart rate monitor, a respiratory monitor, etc.). In one embodiment, the controller 134 may also be in communication with a contrast injection system 152 and an intravascular ultrasound (IVUS) system 154. The controller 134may also be in communication with other medical systems 156, such as an OCT system, an FFR system, or an aspiration pump. In various embodiments, the controller 134 is configured to generate control signals based on a user's interaction with the control device 118 and / or based on information accessible to the controller 134 so that a medical procedure can be performed using the catheter procedure system 100. Additionally, the controller 134 may be in communication with a hospital data management system or hospital network 142, and one or more additional output devices 138 (e.g., a printer, a disk drive, a CD / DVD burner, etc.).

[0026] Communication between the various components of the catheter procedure system 100 may be accomplished via a communication link 140. The communication link 140 may be a dedicated line or a wireless connection. The communication link 140 may represent communication over a network. The catheter procedure system 100 may be connected or configured to include any other systems and / or devices not expressly shown. For example, the catheter procedure system 100 may include an image processing engine, a data storage and archiving system, an automated balloon and / or stent expansion system, a drug injection system, a drug tracking and / or recording system, a user log, an encryption system, a system for limiting access or use of the catheter procedure system 100, etc.

[0027] As mentioned above, the controller 134 is in communication with the bedside system 110 and can provide control signals to the bedside system 110 to control the operation of motors and drive mechanisms used to drive percutaneous interventional devices (e.g., guidewires, catheters, etc.). The bedside system 110 can include, for example, a guidewire axial drive mechanism to provide advancement and / or retraction of a guidewire, a working catheter axial drive mechanism to provide advancement and / or retraction of a working catheter, and a guidewire rotational drive mechanism configured to rotate the guidewire about its longitudinal axis. In one embodiment, the various drive mechanisms are implemented as a drive assembly 111 (shown in Figure 1).

[0028] A robotic medical device system, such as the example catheterization system described above with respect to Figs. 1 and 2, is remotely controlled. Fig. 3 is a block diagram of a communication and control system for a robotic medical device system according to one embodiment. The communication and control system 10 includes a control center 12 at a remote or local site and a robotic medical device system 14 at a local site or location. As used herein, a local site is the location of the robotic medical device system and the patient or subject, and a remote site is the location of the operator (e.g., doctor) and control center used to remotely control the robotic medical device system. The control center 12 and the robotic medical device system 14 communicate via a network 16, such as the Internet. In one embodiment, the remote site and the local site are separate from each other, for example, different rooms in the same building, different buildings in the same city, different cities, or other different locations where the remote site does not have physical access to the robotic medical device system or patient at the local site. The control center 12 and the robotic medical device system 14 communicate (e.g., data, images, commands, and control signals) via the network 16. An operator at a remote site can use the control center 12 to control and operate the robotic medical device systems 14 at a local site to perform a medical procedure. In one embodiment, multiple control centers 12 can communicate with one robotic medical device system 14 via the network 16, with each control center 12 being used to control a robotic medical device system 14 from a separate location. In another embodiment, multiple control centers 12 can communicate with multiple robotic medical device systems 14 via the network 16, with each control center 12 being used to control a respective one of the robotic medical device systems 14.

[0029] The robotic medical device system 14 may be, for example, a catheterization system or other medical device system that may be robotically controlled to perform a procedure. In one embodiment, the network 16 is a secure network, such as a virtual private network. The control center 12 may include, for example, a workstation having a user interface. In one embodiment, the control center 12 includes a user interface similar to the user interface provided in the robotic medical device system 14. For example, if the robotic medical device system 14 is a catheterization system, such as the system described above with respect to FIGS. 1 and 2, the control center 12 may include a workstation having a user interface and controller similar to the workstation 116, the user interface 126, and the controller 118 of the catheterization system 100. In another embodiment, the control center 12 includes a workstation or user interface that is part of a robotic medical device system at a remote site. The control center 12 is configured to allow an operator to operate various components of the robotic medical device system 14 from a remote site. Information such as data, images, and command and control signals are transmitted from the control center 12 to the robotic medical device systems 14 via the network 16, and information such as data and images are transmitted from the robotic medical device systems 14 to the control center 12 via the network 16.

[0030] 4 is a block diagram of a communication and control system of a robotic medical device system according to one embodiment. The communication and control system 200 includes a control center 202 at a remote site and a robotic medical device system 204 at a local site. The control center 202 and the robotic medical device system 204 communicate via a network 206. In one embodiment, the network 206 is a secure network with a remote firewall 208 established in the control center 202 and a local firewall 210 established in the robotic medical device system 204. For example, the network 206 may be a virtual private network (VPN). The network 206 is configured to transmit and receive data, images, and command and control signals. As shown in FIG. 4, Communication and Control Systems In 200, one control center 202 and one robotic medical device system 204 are shown. In one embodiment, multiple control centers 202 may communicate with one robotic medical device system 204 via a network 206, with each control center 202 communicating with the robotic medical device system. 204 Robot system inside 245 1. In one embodiment, the robotic medical device system 204 may be used to control one or more medical devices 246 from a separate location using a control center 202. The robotic system 245 may be, for example, a robotic arm, a robotic drive, and / or other robotic device that may be used to drive a medical device. In one embodiment, where the robotic medical device system is a catheter system, the robotic system 245 may be the robotic arm 112 and drive assembly 111 described above with respect to FIG. 1. In another embodiment, multiple control centers 202 may communicate with multiple robotic medical device systems 204 via the network 206, where each control center 202 may communicate with each robotic medical device system. 204 Using the robotic system 245, one or more medical devices 246 can be used to control

[0031] The control center 202 also 208 The firewall 208 also includes a remote command and control module 212 and a remote controller 216 coupled to and communicating with the remote command and control module 212. In one embodiment, the remote firewall 208, the remote command and control module 212, and the remote controller 216 are implemented on separate hardware (e.g., computer systems). In another embodiment, the remote firewall 208, the remote command and control module 212, and the remote controller 216 are implemented as separate software components or logical subsystem components on the same computer system. The software components or logical subsystem components may be achieved using, for example, a microkernel, a virtual machine, or a conventional operating system with real-time extensions. In another embodiment, the remote controller 216 and the remote firewall 208 may be implemented as a software program executing on the remote command and control module 212. The remote command and control module 212 is integrated into a control center 206. of The control center 236 receives command and control signals from a control console 236, which is configured to receive user input from an operator at a remote site for operation of the robotic medical device system 204 and other systems and devices at the local site. For example, the control console 236 may include displays and controls such as a touch screen, one or more joysticks, and buttons. 202 In Display 240 may be coupled to the remote command and control module 212 and used to display data and images received from the robotic medical device system 204. The remote command and control module 212 may be configured to decompress images received from the robotic medical device system 204.

[0032] The remote command and control module 212 is also coupled to a time-synchronized reference clock, such as a remote reference clock 220, from which it receives time information. The remote reference clock 220 may be, for example, a grandmaster clock. As described further below, the time information may be used to calculate delays in the transmission of signals and data (e.g., command and control signals, and images) between the remote site and the local site. The remote reference clock 220 is coupled to an antenna 232 to receive time information from an external time source, such as a satellite-based time source or an external network, and to provide time stamp information to the remote command and control module 212. In one embodiment, the time information is provided from a Global Positioning System (GPS). In another embodiment, the time information is provided from a Satellite Time Location (STL) system. The remote switch 224 may be coupled to the remote reference clock 220. In one embodiment, the remote reference clock 220, the remote switch 224, and the remote command and control module 212 use a Precision Time Protocol (PTP) network. The remote command and control module 212 uses the time stamp information from the remote reference clock 220 to time stamp command and control signals received from the control console 236. The time stamped command and control signals are transmitted over the network 206 to the robotic medical device system. 204 Local command and control module in 214The local command and control module 214 is configured to provide the command and control signals over the network 206, for example, to a robotic system 245 in the robotic medical device system 204 to control the operation of the medical device 246. The timestamps provided by the remote command and control module 212 on the command and control signals based on information from the remote reference clock 220 are used to monitor and control delays in the transmission of the command and control signals over the network 206 during a medical procedure performed using the medical device 246. The local command and control module 214 is configured to determine a delay in receiving the command and control signals from the control center 202 based on the timestamps, and to take appropriate action based on the amount of delay, as described below with respect to FIG.

[0033] The local command and control module 214 and the local controller 218 are coupled to and in communication with the local firewall 210. In one embodiment, the local firewall 210, the local command and control module 214, and the local controller 218 are implemented on separate hardware (e.g., computer systems). In another embodiment, the local firewall 210, the local command and control module 214, and the local controller 218 are implemented as separate software components or logical subsystem components on the same computer system. The software components or logical subsystem components may be accomplished using, for example, a microkernel, a virtual machine, or a conventional operating system with real-time extensions. In another embodiment, the local controller 218 and the local firewall 210 may be implemented as a software program executing on the local command and control module 214. The local command and control module 214 may also be integrated into the robotic medical device system. ofThe local controller 218 may receive command and control signals from a control console 238 that is configured to receive user input from an operator at the local site for operation of the robotic medical device system 204 at the local site. For example, the control console 238 may include a display and controls such as a touch screen, one or more joysticks, and buttons. A display 241 is coupled to the local command and control module 214 and may be used to display data and images. The local command and control module 214 also receives images from an imaging system 248 and hemodynamic data from a patient sensor 250. In one embodiment, where the robotic medical device system 204 is the catheterization system described above with respect to FIGS. 2 and 3, the local controller 218: 1st and 2nd monitors 120, 122 or touch screen 124. Images from the imaging system 248 may be captured and scaled using a first video capture and scaling device 242 and hemodynamic data may be captured and scaled using a second video capture and scaling device 244. The local command and control module 214 may be configured to compress the image data before transmitting to the control center 202 and the local controller 218 may be configured to compress the hemodynamic data before transmitting to the control center 202. In another embodiment, the local command and control module 214 is coupled to and receives data from an intravascular ultrasound (IVUS) system 254. The data from the IVUS system 254 is transmitted to the control center 202.

[0034] The local command and control module 214 is also coupled to a time synchronization reference clock, such as a local reference clock 226, to receive time information from the local reference clock 226. The local reference clock may be, for example, a grandmaster clock. The time information may be used to calculate delays in the transmission of signals and data (e.g., command and control signals, and images) between the remote site and the local site. The local reference clock 226 is coupled to an antenna 234 to receive time information from an external time source, such as a satellite-based time source, and provide time stamp information to the local command and control module 214. In one embodiment, the time information is provided from a Global Positioning System (GPS). In another embodiment, the time information is provided from a Satellite Time Location (STL) system. The local switch 230 may be coupled to the local reference clock 226. In one embodiment, the local reference clock 226, the local switch 230, and the local command and control module 212 use a precision time protocol network. The local command and control module 214 uses the time stamp information from the local reference clock 226 to time stamp image data received from the first video capture and scaling device 242. In another embodiment, the local controller 218 uses the time stamp information from the local reference clock 226 to time stamp image data received from the second video capture and scaling device 242. and The hemodynamic data received from the scaling device 244 may be time-stamped. The time-stamped images and hemodynamic data may be transmitted to the control center 206 via the network 206. 202 Remote command and control module in 212 The remote command and control module 212 can transmit the images to a control center. 202 Display in 240 and provides hemodynamic data to the display 240 or other display in the control center 202. 226 A local command and control module based on information from 214The timestamps that the control center 202 provides to the image and hemodynamic data may be used to monitor and control delays in the transmission of the image and hemodynamic data over the network 206 during medical procedures performed using the control center 202 to control the robotic system 245 and the medical device 246. Based on delays in the transmission of the image and / or hemodynamic data, Communication and Control Systems Various components of 200 or system control passing between control center 202 and robotic medical device system 204 may be paused or halted.

[0035] As mentioned above, the control center 202 includes a remote reference clock 220 that may use the Precision Time Protocol, and the robotic medical device system 204 includes a local reference clock 226 that may use the Precision Time Protocol. The remote reference clock 220 and the local reference clock 226 may communicate with a common external time source, e.g., a satellite-based time source such as GPS or STL, to receive time information. This embodiment advantageously allows the control center 202 and the robotic medical device system 204 to communicate via a secure tunnel over the network 206 (e.g., the Internet) and calculate command delays and round trip delays to ensure safe and secure operation. Each site uses a dedicated reference clock (e.g., reference clocks 220, 226, respectively) and an independent Ethernet network for time synchronization. This embodiment may use either NTP (Network Time Protocol) or PTP for synchronization purposes. However, a PTP network may allow better synchronization than NTP. Another advantage of using a dedicated reference clock at each site on an isolated network is that it eliminates the attack surface for network attacks targeting Internet-accessible time references. Such vulnerabilities include, but are not limited to, denial of service (DoS) that renders the GMC unavailable, and stack overflows that place the command and control module under the control of an attacker. As further described below with reference to Figure 16, in one embodiment, for a high level of security and minimal latency impact on communications, a firewall can be used to establish an IPSec encryption tunnel with dedicated hardware between two nodes that have a private key.

[0036] In another embodiment, the control center 202 and the robotic medical device systems 204 may not include their own reference clocks. Rather, the control center 202 and the robotic medical device systems 204 are configured to utilize NTP and communicate with a single network grandmaster clock to receive time information. As described above, the time information can be used to generate time stamps for the command and control signals and other data (e.g., image and hemodynamic data). In one embodiment, the time stamps are provided by a common time source (e.g., GPS or STL) to determine the delay in the transmission of the sum of the command and control signals. In another embodiment, the time stamps are provided by a single time source (e.g., a network master clock or internal clock) to determine the delay in the transmission of the sum of the command and control signals. In this embodiment, a time stamp from a "remote" site is used, and then when this time stamp is received back from the image transmission from the "local" site, the round trip command and control signal and image delays are calculated.

[0037] As mentioned above, the control center 202 may be used by an operator at a remote site to operate and control the robotic medical device system 204 and other systems and devices at the local site. In one embodiment, the control center 202 communicates with the imaging system 248 or Contrast Injection System 252. For example, the control center 202 may be used to control image capture by the imaging system 248. In another example, the control center 202 may be used to control contrast injection by the contrast injection system 252. In another example, the control center 202 may be used to control the operation of an aspiration pump or the deployment of a stent-type embolus retriever.

[0038] The control center 202 includes a telepresence module 260, and the robotic medical device system 204 includes a telepresence module 262. The telepresence modules 260, 262 are each configured to provide audio and video communication (e.g., telepresence, teleconferencing) between an operator at a remote site and a user or local staff at a local site. In one embodiment, as shown in FIG. 4, the telepresence modules 260, 262 are standalone modules and may be coupled to the remote firewall 208 and the local firewall 210, respectively. In another embodiment, the elements of the telepresence modules 260, 262 may be software programs executed in the remote controller 216 or the local controller 218, respectively. The telepresence modules 260 and 262 may include, for example, a video camera, a monitor, a speaker, and a microphone. In one embodiment, a video conference can be established between the telepresence module 260 at the remote site and the telepresence module 262 at the local site. As a result, the robotic system at the local site can communicate with the operator at the remote site and with the local staff at the local site. In one embodiment, the telepresence modules 260, 262 may be standalone modules and coupled to the remote firewall 208 and the local firewall 210, respectively. In another embodiment, the elements of the telepresence modules 260, 262 may be software programs executed in the remote controller 216 or the local controller 218, respectively. The telepresence modules 260, 262 may include, for example, a video camera, a monitor, a speaker, and a microphone. In one embodiment, a video conference can be established between the telepresence module 260 at the remote site and the telepresence module 262 at the local site. 245 Using medical devices 246 An operator at the remote site using the control center 202 to operate the device can view the procedure room and devices as the procedure is performed and can communicate via audio and video with personnel supporting the procedure at the local site (e.g., technicians, doctors, etc.). In one embodiment, audio and video communications can be established between the telepresence module 260 at the remote site and the telepresence module 262 at the local site using a dedicated audio and video communications system that establishes secure communications over a computer network (e.g., a cloud network). For example, the telepresence module 260 at the remote site may be configured to transmit audio (e.g., talking) and video from the remote site in an encrypted format (e.g., SRTP / AES-128) and receive and decrypt audio (e.g., talking) and video from the telepresence module 262 at the local site. The telepresence module 262 at the local site may be configured to transmit audio (e.g., talking) and video from the local site in an encrypted format (e.g., SRTP / AES-128) and receive and decrypt audio (e.g., talking) and video from the telepresence module 260 at the remote site. Signaling and routing between the telepresence module 260 and the telepresence module 262 may be established using a cloud network. In one embodiment, the encrypted audio and video data may be transmitted between the remote firewall 208 and the local firewall 210 without further encryption (e.g., the audio and video data may be whitelisted).

[0039] FIG. 5 illustrates a method for controlling the operation of a robotic medical device system according to one embodiment. Referring to FIGS. 4 and 5, in block 302, command and control signals are received from a control center 202 at a remote site, for example by a local command and control module 214 at a local site. In block 304, a delay in receiving the command and control signals is determined, for example by the local command and control module 214, based on timestamp information. In block 306, the delay is compared to a threshold. In one embodiment, the threshold is a predefined value based on what is perceptible to a user, such as 250 ms. In another embodiment, described further below, the threshold is determined in block 316 based on at least one parameter of the robotic medical device system, for example, the procedure being performed by the robotic medical device system, the patient's anatomy, the type of medical device, and the location of the medical device. If the delay is greater than the threshold in block 308, corrective action may be performed in block 314. In one embodiment, Robotic Medical Device SystemThe medical devices 246 and other components of 204 may be paused or stopped. In one example of pausing, if the delay is greater than a threshold value and then the delay falls below the threshold, the device or component is paused. It can then resume movement once the delay exceeds the threshold. In another example, if the delay is too great, the movement of the device or component can be paused until the delay is small enough to resume operation. In another embodiment, the speed or velocity (e.g., while moving forward, backward, or rotating) of the components of the robotic medical device system can be slowed. If the network connection is lost or the speed of the network 206 becomes slower than a predefined speed, the control center 202 may return control of the robotic system 245 and medical devices 246 to the robotic medical device system 204. An emergency stop may also be provided to allow a user at a local site to stop the procedure in an emergency. In one embodiment, the threshold is a range of thresholds. If the control center 202 has control of the robotic system 245 and the medical device 246 and the delay in command and control signals is greater than a first threshold but less than a second threshold, the control console 236 (e.g., a joystick) of the control center 202 may be disabled, but the control console 236 maintains control of the robotic system 245 and the medical device 246. If the control center 202 has control of the robotic system 245 and the medical device 246 and the delay in command and control signals is greater than a second threshold, the control center 202 may be disabled.

[0040] In block 308, when the control center 202 has control of the robotic system 245 and the medical device 246 if the delay of the command and control signals is less than the threshold, the control console 236 of the control center 202 is used to control and operate the robotic medical device system 204, including the robotic system 245 and the medical device 246, in block 310. blockAt 312, the speed of the medical device 246 when being controlled by the control center 202 can be adjusted based on the delay of the command and control signals. If the control center 202 has control of the robotic system 245 and the medical device 246 and adjusts the delay of the command and control signals (t delay ) is the default amount (t predetermined ) but greater than zero, the commanded velocity (v command ) as the delay increases towards a given amount Medical Devices 246 speed (v device ) is scaled to decrease. Medical Devices The velocity is given by: [Formula (1)] JPEG0007612735000001.jpg10168 For example, delay t delay is the default quantity t predetermined If the device speed v is equal to half device is the command speed v command The delay t delay With the increase in Medical Devices Slowing down 246 will ensure system stability and mitigate the risks associated with device control, e.g. Medical Devices The delay t can be used to avoid excessive advancement or retreat of the delay is the default quantity t predetermined If it is greater than (block 308), Medical Devices The speed of v device has become zero Medical Devices The movement of 246 is stopped (block 314). Medical Devices The speed of v device may be adjusted based on the total network delay, which is the delay of the command and control signals t delay , and the delay t imagedelay The speed of the device is given by: [Formula (2)] JPEG0007612735000002.jpg10170Total network delay ttotal =(t delay +t imagedelay ) based on Medical Devices The command speed (v command ) Medical Devices Stable operation and robust performance for position control of the actuator can be ensured. The various command rate scaling embodiments described above can be tuned to ensure stability regardless of any total delay. If the delay is unknown, instability may occur if it is too large. The frequency response of the open loop system under a fixed total delay is given as follows: [Formula (3)] JPEG0007612735000003.jpg11165The Nyquist stability criterion states that for direct proportional feedback, the total network delay must satisfy the following constraint: t total ≦π / 2 seconds. Using the scaling of equation (2) above, t predetermined When = π / 2, we get the following frequency response: [Formula (4)] JPEG0007612735000004.jpg15168 In another embodiment, t predetermined Other optimal values ​​for may be calculated and used in scaling equation (2). From equation (4), stability for proportional direct feedback may be ensured since the gain margin is now infinite for direct proportional feedback. Other methods to ensure stability may also be used in a similar manner with knowledge of the feedback delay. Medical DevicesAn example of an approach using wave variables to ensure stability without knowledge of feedback delays, similar to the case of using velocity commands to control the position of a motor, is described in “Design of Networked Control Systems Using Passivity”, N. Kottenstette, JF Hall, X. Koutsoukos, J. Sztipanovits and P. Antsaklis, IEEE Transactions on Control Systems Technology, vol. 21, no. 3, pp. 649-665, May 2013, which is incorporated herein by reference in its entirety.

[0041] As described above, in block 316, the delay threshold may be determined based on at least one parameter of the robotic medical device system 204, including, for example, the procedure being performed by the robotic medical device system. For example, the robotic medical device system 204 may be a catheterization procedure system that controls the movement and operation of an elongated medical device (e.g., a catheter, a guidewire, a balloon catheter, a microcatheter, etc.). The amount of acceptable delay may vary depending on various parameters of the catheterization procedure system. The delay threshold (i.e., the amount of acceptable delay) may be based, for example, on the type of procedure being performed, the patient's anatomy, the type of elongated medical device (e.g., a catheter, a balloon catheter, a guide catheter, a guidewire, a microcatheter), the location of the elongated medical device, the distance between the elongated medical device (e.g., the tip or distal end of the device) and the target location, or the type of movement (e.g., advance, rotate, retract) performed by the elongated medical device. For example, a longer delay may be acceptable if the elongate medical device (e.g., the tip of the elongate medical device) is further away from the target location, if the elongate medical device is being retracted, or if the elongate medical device is a device that travels over a wire (e.g., a microcatheter or balloon catheter) or guidewire.

[0042] In one embodiment, the remote controller 216 (shown in FIG. 4 ) and the local controller 218 (shown in FIG. 4 ) each generate and display similar graphical user interfaces. FIG. 6 shows an exemplary graphical user interface for a control center according to one embodiment, and FIG. 7 shows an exemplary graphical user interface for a robotic medical device system according to one embodiment. In FIGS. 6 and 7 , the illustrated graphical user interfaces 460, 462 are intended for control of an exemplary catheter procedure system. The graphical user interface 460 for the control center and the graphical user interface 462 for the robotic medical device system are configured to show, for example, the same measurements, speeds, stored settings, and which controls of the control console are activated at the active site (i.e., either the control center at the remote site or the robotic medical device system at the local site). Each graphical user interface 460, 462 displays image delays 464, 466 transmitted from the robotic medical device system to the control console, and command and control signal delays 468, 470 from the control center to the robotic medical device system.

[0043] As discussed above with respect to FIG. 4, the display 240 of the control center 202 can be used to display data and images received from the robotic medical device system 204 via the network 206. FIG. 8 illustrates an exemplary display of data and images for a robotic medical device system according to one embodiment. The display 500 includes data and images captured at the robotic medical device system 204, such as hemodynamic data 502, reference images 506, and live images 508, associated with the operation of the robotic medical device to perform a procedure. More specifically, in the embodiment illustrated in FIG. 8, the data and images relate to a catheter procedure. The robotic medical device system 204 is connected to a control center at a remote site. 202 Display for sending to 500The display 500 may be configured to select a section or region of interest of the hemodynamic data 502, the reference image 506, and the live image 508. Thus, the display 500 may be cropped, for example, such that the hemodynamic data 502, the reference image 506, and the live image 508 are transmitted separately. The selected section or region of interest may have any shape to capture the desired information for transmission. Cropping the display 500 may reduce the bandwidth required to transmit the images and data. FIG. 9 illustrates an exemplary display for a remote site control center with a selected region of interest including hemodynamic data according to one embodiment. In FIG. 9, the display 600 includes hemodynamic data received from the robotic medical device system 204. In another embodiment, the remote controller 216 and display 240 may be configured to allow an operator to selectively circularly buffer up to a predefined time (e.g., 10 seconds) of live image data (e.g., fluoroscopic image data for a catheter procedure), as shown in FIG. 10. For example, a user may activate a control to initiate capture and create a circular buffer of the predefined time for playback. In the embodiment shown in FIG. 10, the reconstructed image shown on the display 700 is scaled to the same scale as the live image 704 . Playback image 702 may be real-time at a preset number of frames per second. In one embodiment, controls are provided that allow the operator to pause, step forward, and step back the playback image 702. The playback image may be used, for example, to facilitate the generation of a roadmap to capture the progression of the case.

[0044] In another embodiment, the display of the image at the remote site (e.g., on the display 240 shown in FIG. 4) may be configured to display the image delay time and the command and control signal delay time, as shown in FIG. 14. In FIG. 14, the display 1100 includes a replayed image 1102 and a live image 1104. The display of the live image includes a display of the delay 1106 of the image transmitted from the robotic medical device system to the control console, and the delay 1108 of the command and control signals from the control center to the robotic medical device system. In another embodiment, the display of the image at the remote site (e.g., on the display 240 shown in FIG. 4) may be configured to display the total delay, as shown in FIG. 15. The total delay is the sum of the image delay time and the command and control signal delay time. In FIG. 15, the display 1200 includes a replayed image 1202 and a live image 1204, which may include additional live information about the procedure, such as the total delay and frame rate of the images acquired by the imaging system associated with the robotic medical device system 204 at the local site. In one embodiment, playback image 1202 may be scrolled to the area of ​​interest after the image is captured. The display of live image 1204 includes an indication of total delay 1206 and frame rate 1208. Frame rate 1208 may be calculated in terms of received frames per second. Total delay 1206 and frame rate 1208 may be updated in real time and / or filtered to appropriate bandwidths to improve the viewer's perception of these values.

[0045] 4, the communication and control system 200 is configured to allow an operator (e.g., a physician) at a remote site to control and operate the robotic medical device system 204 at a local site. The communication and control system 200 is also configured to allow an operator at a local site to control and operate the robotic medical device system 204. A control management process is provided to manage whether the control center 202 or the robotic medical device system 204 has control of the robotic system 245 and the medical devices 246. The control management system is configured to prevent deadlocks between the remote site and the local site, for example. In one embodiment, the control center 202 or the robotic medical device system 204 controls the operation of performing a procedure. (i.e. control)A control token is used to determine whether a system has a control token. The control token is a virtual token implemented in software. The system (e.g., either the control center 202 or the robotic medical device system 204) that owns the control token is given control of the robotic system 245 and medical devices 246 of the robotic medical device system 204, and other systems are disabled and prevented from controlling the robotic system 245 and medical devices 246. In a first state, the control token is "free" and can be acquired by either the control center 202 or the robotic medical device system 204. FIG. 11 illustrates an exemplary user interface when neither the control center nor the robotic medical device system is controlling the robotic medical device, according to one embodiment. The illustrated graphical user interfaces 802, 804 are intended for control of an exemplary catheterization system (e.g., the catheterization system 100 shown in FIGS. 2 and 3). When the control token is "FREE", the robotic medical device system is without a control token and can obtain a control token and gain control, for example, by activating an "All Enabled" button in the graphical user interface 802 for the robotic medical device system. The control center is also without a control token and can gain control, for example, by activating a "RCL Disabled" button for the robotic medical device system in the graphical user interface 804 for the control center. In one embodiment, the "All Enabled" button in the graphical user interface 804 may be shown with a background or color indicating that the control center does not have control, for example, the button text and background may be grayed out.

[0046] In a second state, the control token has been acquired by the robotic medical device system 204. FIG. 12 illustrates an exemplary user interface when the robotic medical device system is controlling a robotic medical device, according to one embodiment. The illustrated graphical user interfaces 902, 904 are intended for control of an exemplary catheterization system (e.g., the catheterization system 100 shown in FIGS. 2 and 3). When the control token is received by the robotic medical device system, the robotic medical device system is given control and can be used to operate the robotic medical device. In FIG. 12, when the robotic medical device system gains control with the control token, the "Enable All" button is disabled and changes to "Disable All" in the graphical user interface 902 for the robotic medical device system. The operator can return the control token to "Free" by activating the "Disable All" button. In the graphical user interface 904 for the control center, the "Disable" button for the robotic medical device system is disabled. In one embodiment, the “Enable All” and “Enable RCL” buttons in the graphical user interface 904 may be shown with a background or color indicating that the control center has no control, for example, the button text and background may be grayed out.

[0047] In a third state, the control token has been received by the control center 202. FIG. 13 illustrates an exemplary user interface when the control center is controlling the robotic medical device, according to one embodiment. The illustrated graphical user interfaces 1002, 1004 are intended for control of an exemplary catheterization system (e.g., the catheterization system 100 shown in FIGS. 2 and 3). Once the control token is received by the control center, the control center is given control and can be used to operate the robotic medical device. In FIG. 13, when the control center gains control via the control token, the “Enable All” button is enabled in the graphical user interface 1004 for the control center. Additionally, “Disable RCL” in the graphical user interface 1004 for the control center is enabled. In one embodiment, the “Disable RCL” button in the graphical user interface 1004 may be shown with a highlight, background, or color indicating that the control center has control. For example, the graphical user interface 1004 is shown with an underline under “Disable RCL.” In other embodiments, the "Disable RCL" button is shown in a color, such as green. When the "Enable All" button is disabled in the graphical user interface 1002 for the robotic medical device system, the robotic medical device system cannot receive control tokens. In one embodiment, the "Enable All" button in the graphical user interface 1002 may be shown with a background or color indicating that the robotic medical device system does not have control, for example, the button text and background may be grayed out.

[0048] In one embodiment, in the second and third states where either the control center or the robotic medical device system has a control token, the site without the control token may have a request token or a forced request token. The request token or the forced request token are virtual tokens implemented in software. The request token and the forced request token may be used to request control or to force a change in control. For example, if the control center has the control token, the robotic medical device system may send a request token to the control center to request that the control token be made "free" so that the robotic medical device system can receive the control token. In response to receiving the request token, the control center may, for example, make the control token "free", choose to hold the control token or time out, and hold the control token. In another example, if the control center has the control token, the robotic medical device system may send a forced request token to the control center to request that the control token be made "free" so that the robotic medical device system can obtain the control token. In response to the forced request token, the control center may, for example, make the control token "free", choose to hold the control token or time out, and let go of the control token.

[0049] As discussed above with respect to Figures 3 and 4, multiple control centers 202 may communicate with multiple robotic medical device systems 204 via a network 206 (e.g., a many-to-many configuration). Figure 16 is a block diagram of a many-to-many configuration of multiple control centers and multiple robotic medical device systems according to one embodiment. In Figure 16, a first control center 1302, a second control center 1304, a first robotic medical device system 1306, and a second robotic medical device system 1308 communicate via a network 1350. In one embodiment, each site (i.e., first control center 1302, Seconda control center 1304, a first robotic medical device system 1306, and Second The first control center 1302 is at a first remote site, the second control center 1304 is at a second remote site, the first robotic medical device system 1306 is at a first local site, and the second robotic medical device system 1308 is at a second local site. The first control center 1302 can be used to control either the first robotic medical device system 1306 or the second robotic medical device system 1308. The second control center 1304 can be used to control either the first robotic medical device system 1306 or the second robotic medical device system 1308. The first control center 1302 includes a first remote firewall 1310, the second control center 1304 includes a second remote firewall 1312, the first robotic medical device system 1306 includes a first local firewall 1314, and the second robotic medical device system 1308 includes a second local firewall 1316. The first remote firewall 1310 provides a first remote controller 1318 with connection The second remote firewall 1312 is then connected to the second remote controller 1320. connection The first local firewall 1314 is connected to the first local controller 1322. connection The second local firewall 1316 is connected to the second local controller 1324. connection The first remote firewall 1310 includes a LAN port 1334 and a WAN port 1336. The second remote firewall 1312 includes a LAN port 1332 and a WAN port 1330. The first local firewall 1314 includes a LAN port 1340 and a WAN port 1338. The second local firewall 1316 includes a LAN port 1326 and a WAN port 1328.

[0050] The firewalls 1310, 1312, 1314, and 1316 are configured to establish secure connections with other sites and to disconnect secure connections with other sites. Preferably, the control and management of establishing and disconnecting secure connections is handled automatically by each firewall, maintaining isolation from other hardware and software functions at each site. In one embodiment, a command line interface (CLI) and a secure shell (SSH) protocol are used to establish a secure connection between the two sites. In this embodiment, each firewall 1310, 1312, 1314, and 1316 has a unique static IP address. Although the following description describes establishing a secure connection between the second control center 1304 and the second robotic medical device system 1308, the methods described herein may be used to establish and disconnect connections between any combination of multiple sites in a many-to-many configuration. In one embodiment, a centralized approach is used. In the centralized approach, the second control center 1304 WAN port 1330 and a second robotic medical device system. 1308 WAN port 1328 is opened for SSH login. In this configuration, either site (e.g., the second control center 1304 and the second robotic medical device system 1308) can create a tunnel through its local firewall LAN port and the other site's WAN port. For example, the second robotic medical device system 1308 The second local controller 1324 The second local firewall 1316 Local LAN port 1326 The second local controller 1324 can be connected to the second control center 1322 via SSH. 1304 WAN port of the second remote firewall 1312 133013 to establish a tunnel. In another example of a centralized approach, the second remote controller 1320 of the second control center 1304 can SSH connect to the WAN port 1328 of the second local firewall 1316 of the second robotic medical device system 1308, and the second remote controller 1320 of the second control center 1304 can SSH connect to the local LAN port 1332 of the second remote firewall 1312. In another embodiment, a distributed approach is used. In the distributed approach, the WAN port 1330 of the second control center 1304 and the WAN port 1328 of the second robotic medical device system 1308 do not allow SSH login. In this embodiment, each site launches a corresponding tunnel connection through the LAN port of its respective local firewall so that the WAN port can remain closed to SSH login for added security. For example, a second local controller 1324 can be SSH connected to a LAN port 1326 and a second remote controller 1320 can be SSH connected to a LAN port 1332 .

[0051] In another embodiment, a secure connection can be established using patch panel direct routing where direct physical wiring is used between all sites (or nodes) on a patch panel. When a specific site needs to be connected, the connected port can be switched. In yet another embodiment, a secure connection can be established by using two static IP addresses for all sites (or nodes). The same two static IP addresses are reserved in the routers of all sites. Only one site is plugged (by the user) into the system when in use and unplugged (by the user) from the Ethernet port when not in use. In another embodiment, a secure connection can be established using the same static IP address for all sites (or nodes). The static IP addresses and Ethernet port mapping can be manually reconfigured on the routers.

[0052] In another embodiment, the secure tunnel established between the two firewalls is a secure virtual private network, such as an IPSec tunnel. To establish an IPSec tunnel, in one example, the first control center 1302 and the first robotic medical device system 1306 have a shared key. The first local firewall 1314 of the first robotic medical device system 1306 launches a tunnel to the first remote firewall 1310 of the first control center 1302. The first remote firewall 1310 then launches a tunnel to the first local firewall 1314. In this example, neither site has a WAN port open to accept SSH logins. In another example, to establish an IPSec tunnel, the first local firewall 1314 allows SSH logon. The first remote firewall 1310 logs on to the first local firewall 1314 using SSH. The first remote firewall 1310 then launches the first local firewall 1314 at the end of the tunnel to the first remote firewall 1310. The first remote firewall 1310 directs the tunnel to the first local firewall 1314. The first remote firewall 1310 can then determine keys for both sites. In one embodiment, there is an a priori network topology map so that all local and remote sites know their network locations.

[0053] In another embodiment, the management of multiple systems and connections in a many-to-many configuration can be managed using cloud computing. For example, a cloud-based infrastructure management solution can be used to manage the firewalls at each site (or node). Each firewall (e.g., first remote firewall 1310, second remote firewall 1312, first local firewall 1314, and second local firewall 1316 shown in FIG. 16) is connected to the Internet and to a cloud that is used for management. Cloud-based management allows the firewalls to be monitored and managed by an operator at one of the sites or by operators at separate locations from the various sites.

[0054] Computer executable instructions for the communication and control system according to the above-described method may be stored in the form of computer readable media. Computer readable media includes volatile and non-volatile, removable, and non-removable media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules, or other data. Computer readable media may be used in the form of random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disc ROM (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or other storage medium that may be used to store the desired instructions, including access to the Internet or other forms of computer networks. Communication and Control Systems This includes, but is not limited to, other media that can be accessed by 10 (shown in FIG. 1).

[0055] This written description uses examples to disclose the invention, including the best mode, and to enable any person skilled in the art to make and use the invention. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements that do not differ substantially from the literal language of the claims. The order and sequence of any process or method steps may be changed or rearranged according to alternative embodiments.

[0056] Many other changes and modifications can be made to the present invention without departing from the spirit or scope of the invention, the scope of these and other modifications will become apparent from the appended claims.

Claims

1. A system for managing control of at least one medical device between a robotic medical device system located at a local site and capable of driving the at least one medical device, and a control center located at a remote site physically separated from the local site and capable of remotely operating the robotic medical device system, comprising: Manage control rights over the at least one medical device using a virtual control token; configured to allow the control center or the robotic medical device system that has acquired the virtual control token to hold the control right; a control state in which the control center has the virtual control token is a first control state, in which the control center having the control right can control the at least one medical device through the robotic medical device system; A system in which the control state in which the robotic medical device system has the virtual control token is a second control state, and in this second control state, the robotic medical device system that holds the control right can control the at least one medical device.

2. The system of claim 1 , wherein the robotic medical device system in the first control state or the control center in the second control state has a virtual request token to request the control.

3. The system of claim 1 , wherein the robotic medical device system in the first control state or the control center in the second control state has a virtual forcing request token for forcing the change of control.

Images