The present invention relates to medical systems, and more particularly to multi-modality networks for providing access to different medical devices through a common interface.
A laboratory or operating room is a place where several minimally invasive procedures may be routinely performed. Consequently, several medical devices are needed to support the many different interventional and diagnostic procedures that may be performed. Therefore, there is a desire to decrease setup time and improve workflow by performing different procedures through a common interface. At the same time, there is a desire to decrease the time to market and the financial investment in integrating these different procedures by exploiting the common design and development process for a common interface.
Described herein are systems and methods for multi-modality networks that provide access to different medical devices though a common interface.
In an example embodiment, a multi-modality network comprises a host computer and a plurality of medical devices. The medical devices may support different diagnostic and/or therapeutic modalities. The host computer communicates with the medical devices through a communications network. In one embodiment, the host computer includes a display and a control console that allow the physician or operator to control the different medical devices and view images and measurements from the different medical devices through a common interface. Further, the host computer may provide computing resources, e.g., a general purpose image processor, that can be shared among the different modalities.
In another example embodiment, the host computer communicates with the medical devices through a standard network interface using standard communications protocols, e.g., Ethernet. This example embodiment simplifies communications between the host computer and medical devices and eliminates the need for device-specific driver cards on the host computer.
In another example embodiment, the host computer is coupled to the medical devices through a network hub. In one embodiment, the network hub electrically isolates the medical devices from one another and/or the host computer, while providing patient safety barrier. The network hub may also provide power to the medical devices and/or a ground connection for the medical devices.
In another example embodiment, the common interface includes one or more touch screen control panels that display a set of controls that the operator can select by touching the touch screen. In one embodiment, each medical device has one or more sets of controls associated with it, which can be displayed on the one or more touch screens when the operator selects the medical device.
In another example embodiment, the host computer comprises a plurality of programs (e.g., software and/or firmware) for interacting with different medical devices over the communications network. In this embodiment, a newly added medical device sends an identifier to the host computer which the host computer uses to recognize the medical device and determine the appropriate program or software path to interact with the device. Alternatively or in addition, a newly added medical device may send a program to the host computer instructing the host computer how to interact with the medical device. The program may specify the layout of controls for the medical device on a touch screen, commands and data structures for the medical device, a workflow for performing a procedure, layout of the graphical data to present to the user on the user display, etc. The host computer may also comprise a set of standard data structures, controls, display layouts, program modules (e.g., for common routines), etc. that can be utilized by the program. The set of standards can be used to simplify the program for a medical device while providing flexibility to customize a presentation for the medical device.
Other systems, methods, features and advantages of the invention will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims.
In order to better appreciate how the above-recited and other advantages and objects of the present inventions are obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof, which are illustrated in the accompanying drawings. It should be noted that the components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like reference numerals designate corresponding parts throughout the different views. However, like parts do not always have like reference numerals. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely.
The network hub 30 is coupled to the host computer 15 via communications link 23 and to the medical devices 35-1 to 35-3 via communications links 27-1 to 27-3. In the example shown, the network hub 30 is coupled to each medical device 35-1 to 35-3 by a separate point-to-point link 27-1 to 27-3. Alternatively, the medical devices 35-1 to 35-3 may be coupled to the network hub 30 over a shared transmission line as shown in
The medical devices 35-1 to 35-3 may comprise devices employing different imaging modalities, e.g., intravascular ultrasound, ultrasound array beamformer, optical coherence tomography (OCT), Raman spectroscopy, MRI, and the like. A more detailed discussion of example medical devices is given below. The network 10 advantageously allows a physician to access different medical devices 35-1 to 35-3 on the network using a common interface (e.g., monitor 25 and control panel 20 coupled to the computer 15). For example, the network 10 allows a physician to acquire images from devices using different imaging modalities and view the images on a common interface. Further, using a common interface allows a medical device manufacturer or vender to manufacture a medical device without a control console and/or display, thereby reducing development, manufacturing, and equipment costs. Alternatively, a medical device may have a simplified control console and/or display compared with a standalone medical device with an understanding that the physician will access the device primarily through the common control console and/or will only need to access a subset of the controls at the medical device.
In the preferred embodiment, a monitor (e.g., LCD monitor) and a touch screen control panel 20 are coupled to the computer 15. The monitor 25 is used to display images and/or measurements received from the medical devices 35-1 to 35-3. The touch screen control panel 20 displays controls that allow the physician to interface with the computer 15 and issue commands to the medical devices 35-1 to 35-3 via the computer 15. An advantage of using a touch screen control panel 20 is that it can display different sets of controls corresponding to the different medical devices 35-1 to 35-3. For example, the touch screen control panel 20 may display a set of controls corresponding to medical device 35-1 when the physician selects medical device 35-1. The touch screen control panel 20 may display a set of icons where each icon represents one of the medical devices 35-1 to 35-3 currently coupled to the network. In this embodiment, the physician selects one of the medical devices 35-1 to 35-3 by touching the corresponding icon on the control panel 20. Thus, the physician can choose the medical device according to clinical need. Also, the selected medical device may be automatically activated when the physician selects the device.
An example touch screen control panel is shown in
The host computer 15 may be a PC-based computer with software and/or firmware for interacting with the medical devices 35-1 to 35-3 over the network 10, processing data from the medical devices 35-1 to 35-3, and/or controlling the control panel 20. The computer 15 may interact with the medical device 35-1 to 35-3 using interaction protocols that run on top of the communications protocols (e.g., standard Ethernet protocols). For the example of Ethernet, the Ethernet protocols would handle data transport and control access to the network, while the interaction protocols would specify, e.g., commands and data structures sent between the host computer 15 and the medical devices 35-1 to 35-3. As an example, the host computer 15 may send a command to one of the medical devices 35-1 to 35-3 to acquire one or more images and in response, the medical device 35-1 to 35-3 acquires the image and sends corresponding image data to the host computer 15. A more detailed discussion of example interaction protocols is given below.
The computer 15 may also comprise a network interface card (e.g., Ethernet card) for interfacing to the network 10, a display driver, a graphics processor, and a storage medium for storing and archiving images and other data from the acquisition devices 35-1 to 35-3. The storage medium may include a hard drive, a removable storage device, DVD, or the like. The computer 15 may be coupled to a Local Area Network (LAN) or the Internet for exporting data to another computer, e.g., in the same hospital for offline diagnosis.
An advantage of the host computer 15 is that it provides shared computing resources for processing data received from the different medical devices 35-1 to 35-3. For example, the host computer 15 may provide a graphics and image processor that can be used for processing image data from different imaging modalities. This may eliminate or simplify the image processor required on a medical device, thereby reducing the cost and/or development time of the medical device.
The electrical isolation couplers 145-1 to 145-3 may comprise optical couplers, transformers, capacitive couplers, or the like. An optical coupler provides electrical isolation by converting an electrical signal at one end into an optical signal and converting the optical signal back into an electrical signal at the other end. The optical coupler may comprise one or more LEDs in each direction of communication for converting an electrical signal into an optical signal and a photo detector for converting the optical signal back into an electrical signal. An electrical isolation coupler may also comprise an electrical surge detector coupled to a switch that disconnects the corresponding device from the network 10 when an electrical surge is detected by the electrical surge detector.
The network hub 30 may comprise couplers only between devices where there is a danger of an electrical surge instead of a coupler between each pair of devices coupled to the network 30. For example, the network hub 30 may comprise one coupler between the host computer 15 and all of the medical devices 130-1 to 103-3 coupled to the hub.
The network hub 30 may also comprise a switching network 143, e.g., for disconnecting and isolating a faulty device from the network 10 through a switch. The switching network may also be used to route signals from a source device only to a destination device on the network 30. The network hub 30 may also provide power to the medical devices 35-1 to 35-3 through power transmission lines 130-1 to 130-3, each power transmission line 130-1 to 130-3 coupled at one end to one of the medical devices 35-1 to 35-3 and at the other end to a power connector 132-1 to 132-3 of the network hub 30. Each power transmission line 130-1 to 130-3 may include a ground wire to connect to a ground via the network hub 30. The network hub 30 may supply power from a power outlet or other power source (not shown) via power line 160. The network hub 30 may also comprise a power adapter 155 for adapting power from the power source into power suitable for the corresponding medical device 35-1 to 35-3. For example, the power adapter 155 may, e.g., convert AC power from the power source into DC power, change voltage levels, or the like. The power adapter may also include one or more surge protectors (not shown) for protecting the medical devices 35-1 to 35-3 from electrical surges. The power adapter may also include medical grade isolation transformers with double or reinforced insulation to provide patient safety barrier from a single fault condition from a local power source.
Each power transmission line 130-1 to 130-3 may be bundled with the corresponding communications link 27-1 to 27-3 in the same physical cable. For example, some Ethernet cables include additional wires that may be used to transmit power.
Providing power to the medical devices 35-1 to 35-3 from the network hub 30 has the advantage of reducing the size of the medical devices by eliminating the need to provide a battery and/or separate power supply on the medical device 35-1 to 35-3.
The above examples are intended only to aid in the illustration of the various network configurations that are possible. Since a large number of configurations are possible, it is not intended that the network be limited to the example embodiments described or depicted herein.
To image within a blood vessel, the catheter is advanced to a desired region within the blood vessel. To obtain a two-dimensional cross-sectional image of a blood vessel, the MDU 415 rotates the imaging core 433 allowing the transducer 440 to scan a rotational cross-section of the blood vessel. Typically, the transducer 440 is rotated one revolution to acquire one cross-sectional image. To scan a volume of the blood vessel, the MDU 415 incrementally pulls back the imaging core 433 along the blood vessel allowing the imaging core 433 to obtain a series of cross-sectional images along the blood vessel. These cross-sectional images can be stacked to form a three-dimensional image of the blood vessel. The acquisition processor 418 controls the MDU 415 and imaging core 433 according to the desired imaging procedure. For example, the acquisition processor 418 may control the MDU 415 and imaging core 433 according to a desired pullback length, pullback rate, and image frame rate where each image frame corresponds to one cross-sectional image (typically one revolution of the imaging core).
In this embodiment, the imaging device 405 comprises a network interface 420 for interfacing the acquisition processor 418 to the network via a link 427. In a preferred embodiment, the network interface 420 uses an industry standard, e.g., Ethernet, for sending and receiving information to and from the host computer 15 via the network. In this example, the acquisition processor 418 may receive commands from the host computer 15 using command protocols that run on top of the communications protocols (e.g., Ethernet protocols). The network interface 420 and acquisition processor 418 may be implemented in a PC-based computer or other computer that is coupled to the MDU 415 by a control/data link.
As an example, the host computer 15 may send commands to the acquisition processor via the network to perform an imaging procedure, in which the commands may specify the pullback length, pullback rate, and/or image frame rate of the imaging procedure. In response, the acquisition processor 418 acquires the image frames, and sends the image frame data to the host computer 15. The acquisition processor 418 may send the image data for the frames to the host computer 15 serially (i.e., one frame at a time). The data for each frame may include a number indicating the order of the frame in the series of frames. The acquisition processor 418 may also send status indicators to the host computer 15. The status indicators may indicate when the imaging device has stared and/or finished the imaging procedure, or that the imaging device is not ready. The acquisition processor 418 may also send an error code to the host computer 15 when the MDU is not functioning properly.
In a preferred embodiment, the network is flexible in that medical devices can be added to and removed from the network, e.g., according to available medical devices. For example, the network eases the installation of new medical devices and the replacement of old devices with new devices. In a preferred embodiment, the medical devices in the network are accessed through a common control console at the host computer. This eliminates the need for each medical device to have its own control console, display and/or image processor, thereby reducing manufacturing and equipment costs. The network also improves workflow for performing different procedures by allowing the physician to access the different modalities though a common interface.
In one embodiment, the host computer comprises a plurality of programs (e.g., software and/or firmware) for interacting with a plurality of different medical devices that may be coupled to the network. In this embodiment, when an medical device is added to the network, the medical device sends an identifier to the host computer identifying the medical device. For example, the identifier may include the manufacturer, model number, and/or device type (e.g., OCT, IVUS, MRI, etc.) of the medical device. When the host computer receives the identifier, the host computer uses the identifier to recognize the medical device and determine which program or software path to use to interact with the medical device. If the host computer does not recognize the medical device, then the host computer may display a message to the operator (e.g., on the monitor) indicating that it does not recognize the medical device. The message may include the manufacturer, model number, and/or device type of the medical device so that the operator can identify the medical device. In this case, the operator may load software for the medical device onto the host computer (e.g., from a removable storage medium) or download the software from a LAN or the Internet.
In another embodiment, the host computer may reserve a predetermined network address and/or a network link for a certain medical device. When the medical device is coupled to the network via the predetermined network address and/or network link, the host computer can automatically recognize and select the medical device without having the medical device send an identifier to the host computer.
In another embodiment, the program (e.g., software) for interacting with the medical device may be stored in memory on the medical device (e.g., in ROM, Flash memory, etc.). In this embodiment, when the medical device is added to the network, the medical device may upload the program to the host computer. This provides the network with plug-and-play capabilities, e.g., for a new medical device that is manufactured after the host computer. In an embodiment, the host computer may already comprise a plurality of program modules (e.g., for performing common functions or routines) that can be used. In this embodiment, the program from the medical device may instruct the host computer which existing program modules on the host computer to use and/or parameters to input into the program modules. This simplifies the amount of program code that needs to be uploaded. This can also ease software development by the medical device vendor by allowing the vendor to utilize program modules already on the host computer.
Further, the host computer may detect the addition and removal of medical devices from the network and update a list of available medical devices accordingly. The host computer may display the list as a plurality of icons on the touch screen, where each icon represents one of the available devices that the operator can select by touching the icon.
Preferably, the program for a medical device is adapted for the host computer to interact with the medical device. For example, the program for a device may include instructions for displaying a set of controls that are adapted to fit within the touch screen coupled to the host computer. The layout of the controls on the touch screen may be specified using an industry standard, e.g., Extensible Markup Language (XML). The layout of the controls may also be specified using a standard (e.g., defined by the host computer manufacturer) that provides a format for specifying the shape and/or size of control buttons on the touch screen, the positions (e.g., coordinates) of the control buttons on the touch screen, the appearance of text boxes, and the like. Such a standard may also include a set of standard controls, templates, control layouts, etc. that can be utilized by the program for the medical device. For example, the standard may include a set of standard controls for a type of imaging modality (e.g., IVUS). The standard advantageously provides a common format and a set of standard controls, templates, etc. that medical device manufacturers or vendors can use to specify the controls and layout of the controls on the touch screen. The standard may be used to provide a degree of uniformity or similar look-and-feel to the controls for the medical device to aid the operator in learning to use the different medical devices.
The controls displayed on the touch screen may also include, e.g., numeric buttons for entering numbers, a knob that can be turned by circular motion of a finger on the touch screen, a pointer on a scale that can be slide to different values along the scale by sliding a finger on the touch screen, and the like. The program for a medical device may select a knob and/or scale from a set of standard knobs and scales, and specify the increments for the knob and/or scale (e.g., how much a parameter value changes for each increment on the scale).
A control button may also include an image representing the function performed by the control. In this example, the program for a medical device may include an image fie of the image, e.g., bitmap or other standard image fie format. The program may also include an icon representing the corresponding medical device. The host computer can display this icon with the icons of other medical devise to allow the operator to select a desired medical device, e.g., by touching the corresponding icon on the touch screen.
The program may also include instructions for specifying how images and/or measurements are displayed on the monitor. For example, the program may include instructions specifying the sizes and/or positions of images and/or measurements and analysis results on the monitor. In another example, the host computer may comprise a plurality of different display formats or templates and the instructions may specify which of the display formats to use.
The program may also include instructions for a set of commands that are associated with the set of controls. The commands may be specified, e.g., by a string of characters that the host computer sends on top of the communications protocols to the medical device when the operator selects the associated control(s). The commands may also include parameters selected by the operator or default parameters. For example, if a command or sequence of commands specifies a pullback imaging procedure, then the parameters may include a pullback length, a pullback rate, and/or a frame rate. In this example, the operator may select the parameters from a set of values displayed on the touch screen and/or enter the parameters using numeric buttons displayed on the touch screen. A command or sequence of commands for a pullback procedure may also have predefined parameters understood by the medical device, in which case the parameters do not need to sent to the medical device.
The program may also include instructions instructing the host computer what data to expect from the medical device in response to a particular command or sequence of commands. For the example of the pullback imaging procedure, the software may include instructions instructing the host computer to receive and record a series of image frames from the corresponding medical device. The instructions may also include a data structure for the image frames instructing the host computer how to process the image frame data from the medical device into images. The host computer may comprise a set of standard data structures for different imaging modalities. In this example, the program may instruct the host computer which of the standard data structures to use to process the image frames. After receiving the image frames, the host computer may use the received image frames and the parameters for the pullback procedure, e.g., to construct and display a three-dimensional image of the blood vessel, display a video of the pullback procedure, playback a selected range of the frames in a continuous loop, and the like.
The program may also specify a workflow for different procedures that the physician may select. For example, the workflow for a particular procedure may comprise a plurality of steps for performing the procedure with rules defining the relationships among the steps. For example, a rule may specify which step comes after the current step based on an input, output and/or state of the current step. As an example, the workflow for an imaging procedure may include a sequence of parameters that have to be entered by the physician. In this example, when the physician enters one of the required parameters, the software may instruct the host computer to display a request for the next parameter to be entered by the physician. Thus, the host computer may walk the physician through the parameters that need to be entered. As another example, the workflow for an imaging procedure may specify what step is performed by the host computer based on data and/or status information received by a medical device. For example, the host computer may receive a preview image from the medical device, after which the host computer may display the preview image to the physician and give the physician the option of continuing the current imaging procedure. The workflow may be modeled using a state model and/or a domain model. The host computer may also comprise a set of standard workflows for different modalities that the program for a medical device can utilize. The standard workflows may be used to provide workflows that conform to good medical practice.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. For example, the reader is to understand that the specific ordering and combination of process actions described herein is merely illustrative, and the invention can be performed using different or additional process actions, or a different combination or ordering of process actions. As a further example, each feature of one embodiment can be mixed and matched with other features shown in other embodiments. Additionally and obviously, features may be added or subtracted as desired. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/050,132, filed May 2, 2008, the entire contents of which is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61050132 | May 2008 | US |