Integrated fluoroscopic surgical navigation and workstation with command protocol

Abstract

In a medical diagnostic imaging system, a communication protocol for providing bi-directional communication between a medical imaging subsystem and a medical navigational subsystem, the communication protocol including a plurality of navigation subsystem to imaging subsystem messages; and a Begin Imaging and an End Imaging message for synchronizing image acquisition with navigation coordinate determination, the Begin Imaging and End Imaging messages included in imaging subsystem to the navigation subsystem messages.

Description

RELATED APPLICATIONS

[0001] The present application is a division of U.S. Ser. No. 09/649,071, filed Apr. 26, 2000, entitled "Integrated Fluoroscopic Surgical Navigation and Workstation with Command Protocol," which is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

[0002] The preferred embodiments of the present invention relate to surgical navigation systems and techniques. In particular, the preferred embodiments of the present invention relate to an integrated surgical navigation system and fluoroscopic X-ray system.

[0003] Medical imaging techniques including X-ray, CAT (Computerized Axial Tomography), MRI (Magnetic Resonance Imaging), and ultrasound are well established. These techniques provide an examining physician with high resolution images useful for subsequent detailed study and diagnosis. Recently, however, surgical navigation techniques have been proposed that use pre-operative images for improving inter-operative visualization of patient anatomy. To that end, one or more of the pre-operative images are displayed for the surgeon during an operation, with a surgical tool superimposed on the image in the correct location.

[0004] The navigational challenges associated with using pre-operative images during surgery include establishing a known coordinate system with respect to the patient, registering pre-operative images in the coordinate system, and tracking surgical tool movement through the coordinate system. In the past, navigation systems, attempting to meet these challenges, were developed as separate and independent add-on systems to be connected to separate and independent imaging systems. The add-on navigation systems were designed as separate navigation units, and generally did not adhere to a standard or consistent communications protocol for communicating with the imaging system.

[0005] As a result, prior navigation systems 1) required significant additional floor-space (in an already overcrowded operating room environment), 2) did not support high speed digital data transfer to the imaging system, and 3) had no bi-directional command and control interface with the imaging system. The lack of bi-directional command and control with the imaging system make it difficult, if not impossible, to ensure that position information from the navigation system actually corresponded to the moment in time that the image was acquired. As a result, tracking errors arise, for example, in a C-arm type X-ray system performing fluoroscopy, when the C-arm moves. The tracking error may arise during the time interval between the point in time at which image acquisition is finished and the point in time at which the navigation information was obtained. Any tracking error is undesirable in surgical navigation.

[0006] Additionally, the external output ports of prior imaging systems were generally limited to NTSC or PAL video outputs. An NTSC or PAL video output represents an immediate reduction in resolution and dynamic range in comparison with the original digital image read out of an X-ray detector (e.g., a 1024.times.1024 image). Thus, as a separate system, conventional navigation systems were limited to using a frame grabber connected to the imaging system output port to acquire lower resolution images for later surgical navigation. Furthermore, where DICOM was used to transfer images between the imaging system and navigation system, the DICOM overhead limited throughput to as little as one image every twelve seconds.

[0007] A need has long existed for a method and apparatus for fluoroscopic surgical navigation that addresses the problems noted above, and other problems previously experienced.

SUMMARY OF THE INVENTION

[0008] A preferred embodiment of the present invention provides a medical diagnostic imaging system. The medical diagnostic imaging system includes an X-ray source and X-ray detector, sensors tracking a position of at least one of a surgical instrument and the X-ray detector, and an integrated imaging and navigation workstation. The integrated imaging and navigation workstation includes at least one processor executing fluoroscopic imaging based on an output of the X-ray detector and navigation tracking of positions of a surgical instrument and positions of an X-ray detector with respect to a coordinate system. The integrated imaging and navigation workstation also includes an input receiving surgical instrument tracking signals from the sensors, an input receiving detector tracking signals from the sensors, and a display for displaying fluoroscopic images with a displayed instrument superimposed. In particular, one or more relations of the displayed instrument with respect to the fluoroscopic image (e.g., coordinate location and rotation) corresponds to the relation of the surgical instrument to the patient.

[0009] Another preferred embodiment of the present invention provides a diagnostic imaging system communication protocol. The communication protocol implements bi-directional communication between a medical imaging subsystem and a medical navigational subsystem. The communication protocol includes a set of navigation subsystem to imaging subsystem messages as well as a set of imaging subsystem to navigation subsystem messages. The imaging subsystem to navigation subsystem messages include a start imaging and end imaging message. The messages may include Ping response time messages, system configuration, file request, image request, and image reply messages, as examples.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

[0010] FIG. 1 shows a high level block diagram of a medical diagnostic imaging system.

[0011] FIG. 2 illustrates a block diagram of an integrated fluoroscopic surgical navigation and imaging workstation.

[0012] FIG. 3 shows an example of a C-arm that may be used for integrated fluoroscopic surgical navigation.

[0013] FIG. 4 shows a diagnostic imaging system communication protocol message format.

[0014] FIG. 5 illustrates a flow diagram for sending data according to a diagnostic imaging system communication protocol.

[0015] FIG. 6 depicts a flow diagram for receiving data according to a diagnostic imaging system communication protocol.

[0016] FIG. 7 shows the format for transmitting the patient name of "Jane Doe" to a navigation computer.

[0017] The foregoing summary, as well as the following detailed description of certain embodiments of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings, certain embodiments. It should be understood, however, that the present invention is not limited to the arrangements and instrumentalities shown in the attached drawings.

DETAILED DESCRIPTION OF THE INVENTION

[0018] FIG. 1 illustrates a block diagram of a medical diagnostic imaging system 100. The imaging system 100 includes an integrated imaging and navigation workstation 102 that in turn includes a navigation subsystem 104 and an imaging subsystem 106 (shown in FIG. 1 as a fluoroscopic imaging subsystem). The navigation subsystem 104 includes a navigation computer 108 and a tracker module 110, while the imaging subsystem includes an imaging computer 112.

[0019] The imaging system 100 further includes a workstation surgical tool tracking sensor input port 114, a workstation X-ray-detector fixture tracking sensor input port 116, a workstation dynamic reference frame transmitter control output port 118, and a workstation X-ray exposure output port 120 (that communicates with a foot switch activated exposure module 132). The X-ray detector fixture connects to an image intensifier (or solid state flat panel detector) on the C-arm 130. The tool sensor input port 114 allows the imaging system 100 to be coupled to a tool location sensor 123 on a medical (e.g., surgical) tool 122. The medical tool 122 may be, for example, an aspirating device such as that disclosed in U.S. Pat. No. 5,873,822, an orthopedic drill, awl, or probe, and the like. The transmitter control output port 118 connects the imaging system 100 to the location transmitter 124. The detector tracking sensor input 116 allows the imaging system to receive tracking signal inputs from an X-ray detector position sensor 126 that detects the position of an image X-ray detector. The X-ray exposure output port 120 allows the imaging system 100 to communicate with the exposure module 132 and to read images from the X-ray detector. The exposure module 132, in turn, provides a physician with foot switch activated X-ray exposure control.

[0020] The imaging system 100 also provides a navigation display 132 (attached to a movable display arm) for displaying images output by the navigation subsystem 104 as well as an imaging display 134 for displaying images output by the imaging subsystem 106. The navigation subsystem 104, imaging subsystem 106, and displays 132-134 are preferably placed in a self contained mobile cart system.

[0021] The sensors 123 and 126 output pulsed signals representative of the sensor's location. The tracker module 110 implements coordinate determination from location pulses received via the detector tracking sensor input 116 and the tool sensor input 114 using the predetermined coordinate system typically associated with the location transmitter 124 and referenced to patient anatomy. The coordinates may include, for example, X, Y, and Z locations as well as roll, pitch, and yaw angles.

[0022] To the end, the location transmitter 124 may be implemented, for example, as a field generator that includes three orthogonally disposed magnetic dipoles (e.g., current loops or electromagnets). Electromagnetic fields generated by each of the dipoles are distinguishable from one another in phase, frequency, time division multiplexing, and the like. The near-field characteristics of the electromagnetic fields may be used for coordinate determination as generally described, for example, in U.S. Pat. No. 4,054,881, which is incorporated by reference herein in its entirety. Alternate embodiments of the location transmitter 124 may employ ultrasonic or optical fields. Alternatively, more than one location transmitter 124 may be used in a coordinate determination system based on triangulation of signals. Commercially available position detection units, including the 3 Space.RTM.Fastrak.TM. system from Polhemus, Incorporated of Colchester, Vt. may also be used.

[0023] Additional details of coordinate determination using a location transmitter and associated reception sensors may be found in U.S. Pat. No. 5,873,822.

[0024] Turning next to FIG. 2, that figure presents a block diagram of an integrated fluoroscopic surgical navigation and imaging workstation 200. The workstation 200 includes the navigation computer 108 and the imaging computer 112. The navigation computer includes a navigation processor 202, program/data memory 204, and a navigation network interface 206. The navigation network interface 206 implements a high speed digital communication interface (e.g., two or more 1024.times.1024.times.16 images per second). The images may be cropped in accordance with a circular blanking window to approximately 980.times.980 resolution. In other words, the navigation computer 108 receives full resolution digital images directly from the imaging computer 112 without the need for NTSC or PAL image grabbers, conversion to NTSC or PAL format, or the associated loss of resolution and dynamic range. The navigation network interface 206 may be, for example, a 100BaseT Ethernet network card. The navigation computer is preferably implemented as a Sun UltraSparc 10 running Solaris 2.6 with an un-interruptable power supply (UPS). A second network interface 208 may be provided in the navigation computer 108 for forwarding packets to other destinations.

[0025] The imaging computer 112 includes the imaging processor 210, program/data memory 212, and imaging network interface 214. The imaging computer 112 is preferably implemented as an Intel x86 platform, for example, a Pentium.TM. processor based PC with 32-128 Megabytes of memory. The imaging network interface 214 is compatible with, and is generally implemented in the same manner as, the navigation network interface 206. The network interfaces 206, 208, 214 are used not only as a high speed digital communication bus, but also as a command and control bus that the imaging computer 112 and the navigation computer 108 may use to coordinate their functions (particularly image acquisition with coordinate determination as noted below).

[0026] Note that tool configuration updates may be performed using a floppy disk (or other storage media or TFPT protocol) interface in the imaging computer 112. In addition, the operating system and application software may be accomplished using a CDROM interface with keyboard and mouse control. Operating system and application software updates may be accomplished through the imaging network interface 214 using FTP, telnet, the Sun Sparc.TM. pkgadd command, and the like. The network addresses assigned to the network interfaces 206, 208, and 214 may be reconfigured in a similar fashion using telnet, the vi editor, and ifconfig, as examples.

[0027] The workstation 200 shown in FIG. 2 provides a private network for the imaging computer 112 and the navigation computer 108 to communicate. The imaging computer 112 and the navigation computer 108 communicate, preferably, using a socket-based command protocol over TCP/IP. The private network is assigned an Internet Protocol (IP) address which is allocated strictly to private networks (e.g. 192.168.0.0/24) and is generally not routed over the Internet. Hence, each workstation 200 shipped can use the same internal network address if desired. Note also that DICOM Ethernet traffic from the imaging computer 112 may pass through the navigation computer 108, which forwards the DICOM traffic to the second network interface 208.

[0028] The workstation 200 may access external networks by using a Network Address Translation (NAT) at the navigation computer 108 to translate the IP address of the packets coming from the workstation 200 to a host IP address assigned to the system. In addition, a firewall may be implemented with an IP filter to prevent unnecessary external network traffic from reaching the private network between the Navigation Computer and Workstation. The firewall may be configured, for example, to block all inbound traffic from an external network except for ping, traceroute, FTP, and telnet commands. In addition, external outbound initiated traffic is allowed only for the duration of the required connection.

[0029] In one embodiment, the workstation 200 sets the IP address to "network. 1" (e.g., 192.168.0.1) for the imaging computer 112 and the net mask to 255.255.255.0. The workstation 200 also sets the default route to "network.2" (e.g. 192.168.0.2, assigned to the navigation computer 108). In other words, the navigation network interface 206 is preferably assigned an IP address of "network 2" or 192.168.0.2. The second network interface 208 (connected to external networks) is assigned an IP address allocated by a third party. The imaging network interface 214 is preferably assigned an IP address of 192.168.0.1 and is translated to and from the third party specified IP address.

[0030] On boot-up and when changed, the workstation 200 preferably sends the following to the navigation computer 108: Host IP address and sub-net mask, Gateway Address (e.g., obtained from DICOM store, print, and query screens), Date and Time, Language Configuration (e.g., English, French, German, Spanish, or Italian).

[0031] In operation, the imaging computer 112 monitors the connection 215 through the network interfaces 206 and 214 for network protocol commands and responds synchronously. For example, the imaging computer 112 may respond to Ping requests to check the connection between the imaging computer 112 and the navigation computer 108, Request Image requests (e.g., to request transfer of the left display image from imaging computer 112 without patient information), and Request Configuration requests. The imaging computer 112 generally sends network protocol commands to the navigation computer 108 asynchronously, including a Ping command to check a connection, Imaging Begin and End commands to delineate, for example, live X-ray exposure periods, a New Exam command to tell the navigation computer 108 that the current patient is no longer valid, and an Update Patient command to update the current patient information. Thus, responses from the imaging computer 112 are generated synchronous to a predetermined timing source, while original commands may be sent asynchronously. Additionally, the imaging computer 112 monitors for File Transfer commands and responds by retrieving the appropriate file and forwarding it to the navigation computer 108.

[0032] Generally, when the navigation computer 108 is on a private network, it is not available for communication for a few seconds (e.g., 90 seconds) after the imaging computer 112 boots. During this time period, the imaging computer 112 may display an error message such as "Navigation Computer not responding, Power Off, wait 10 seconds, then Power On". If communication fails between the imaging computer 112 and navigation computer 108 after a connection is established, the imaging computer 112 may timeout, for example, after 2 seconds, close the connection between the navigation computer 108 and the imaging computer 112, and display an error message such as "Communication Failure with Navigation Computer".

[0033] Preferably, the navigation computer 108 and the imaging computer 112 have different power-down strategies. The imaging computer 112 may be powered down at any time by removing the AC power without notifying the operating system of a shutdown. Conversely, the navigation computer 108 preferably executes a shutdown procedure before removing AC power. To this end, the un-interruptible power supply (UPS) is used to hold power with battery backup while the navigation computer 108 shuts down. The UPS provides the power status on a serial port, which is used to signal the navigation computer 108 of a power loss.

[0034] Generally, the navigation computer 108 may be booted simultaneously with the imaging computer 112, a UPS background (e.g., a daemon) process shall monitor the serial port for a power loss, including imaging computer 112 power switch status. Upon receiving a power loss signal, the navigation computer 108 initiates an operating system shutdown, following which the navigation computer 108 is powered off.

[0035] The navigation computer 108 and the imaging computer 112 may be implemented using a single processor executing both navigation and imaging software. Alternatively, a multi-processor system, under the coordination of an symmetric multiprocessing operating system (e.g., Windows NT) may be used to allow a single set of processors to execute the navigation and imaging software. However, as described below, the navigation computer 108 and the imaging computer 112 may also be implemented as separate processing units, coupled together with the network interfaces 206, 214 and communicating with the diagnostic imaging system communication protocol set forth below.

[0036] Turning next to FIG. 3, that figure shows an exemplary C-arm apparatus 10 that may be used with the medical diagnostic imaging system 100. The apparatus 10 includes a C-arm 12 having inner and outer circumferences 14 and 16, respectively, a back convex portion 40, and terminating in opposing upper and lower distal ends 18a and 18b. The C-arm 12 preferably has a uniformly circular C-shape, but may alternatively comprise any arc-shaped member.

[0037] The C-arm 12 is held in a suspended position by support means such as structure, generally designated at 20, which includes a support arm 22 mounted upon a wheeled base 24. The support arm 22 provides for rotational movement of the C-arm 12 about an axis of lateral rotation 30, either by a bearing assembly between the support arm 22 and the C-arm 12, or by the support 22 itself being rotatably mounted with respect to the base 24. The apparatus 10 may also be provided with rotational capacity for rotational movement about an axis 60.

[0038] The wheeled base 24 enables transport of the C-arm 12 from a first location to a second location. As such, the wheels of the base operate as transporting means coupled to the support structure 20 for transporting the support arm 22 and the C-arm 12 from a first location to a second location. It is often highly advantageous to be able to move X-ray equipment from one room to another conveniently. The mobile nature of the apparatus 10 as provided by the wheeled base 24 offers the advantage of increased access by patients in many different rooms of a hospital, for example.

[0039] The support arm 22 is slidably mounted to the outer circumference 16 of the C-arm 12 and the support structure 20 includes structure and mechanisms necessary to enable selective, sliding orbital motion of the C-arm about an axis of orbital rotation 26 to a selected position. The axis 26 preferably coincides with a center of curvature of the C-arm 12 and with the axis of lateral rotation 30. It will be appreciated that the sliding orbital motion causes the C-arm 12 to move through various sliding points of attachment 28 to the support arm 22. It will be appreciated that in practice, the support arm is essentially attached to the C-arm over an area 29 and not a single point, although a "point" may be a large area or a small site. The support structure 20 further includes mechanisms known in the art for laterally rotating the support arm 22 selectable amounts about an axis of lateral rotation 30 to a selected lateral position. The combination of sliding orbital motion and lateral rotation enables manipulation of the C-arm in two degrees of freedom, i.e. about two perpendicular axes. This provides a kind of spherical quality to the movability of the C-arm 12. The sliding orbital motion and lateral rotation enable an X-ray source 32 coupled to the C-arm to be moved to substantially any latitude/longitude point on a lower hemisphere of an imaginary sphere about which the C-arm is moveable.

[0040] The apparatus 10 includes an X-ray source 32 and an image receptor 34 as known generally in the X-ray diagnostic art, mounted upon opposing locations, respectively, on the C-arm 12. The X-ray detector position sensor 126 is generally located inside the camera assembly of the image receptor 34 (which may further include registration fiducials and the like that may be used to compensate for image pincushioning and other effects imposed by the image receptor). The X-ray source 32 and the image receptor 34 (including a rear portion 34a, and a power supply 34b) may be referred to collectively as the X-ray source/image receptor 32/34. The image receptor 34 can be an image intensifier or the like. The orbital and laterally rotational manipulation of the C-arm enables selective positioning of the X-ray source/image receptor 32/34 with respect to the width and length of a patient located within interior free space 36 of the C-arm 12. The sliding orbital movement of the C-arm causes the X-ray source/image receptor 32/34 to move along respective arcuate movement paths. The image receptor 34 is preferably secured to the inner circumference 14 of the C-arm 12 and the X-ray source 32 may also be secured to said inner circumference 14. A high voltage cable assembly 50 supplies power to the X-ray source/image receptor 32/34.

[0041] The mounted positions of the image receptor 34 and the C-arm 12 result in the axis of lateral rotation 30 substantially coinciding with the point of attachment 28 of the C-arm 12 to the support arm 22 for substantially any position of the C-arm 12. Thus, rotation of the support arm 22 does not introduce eccentric lateral moment-arm action so as to provide a more stabile, balanced support structure. In one preferred embodiment, the center of mass of the C-arm 12 coincides with the axis 30 for any position of the C-arm.

[0042] An additional aspect of the C-arm includes the location of a power supply 34b of the image receptor 34. By locating the power supply 34b toward the C-arm opening, the image receptor 34 and the X-ray source 32 can be moved closer to the center of curvature 26, thereby reducing the distance 46 and thus improving overall balance of the apparatus 10. Balancing is enhanced by having a distance 46 between a line of alignment 48 and the intersection of the axes 26 and 30. The line of alignment 48 refers to alignment of a central beam produced by the X-ray source 32, and the image receptor 34. Note also that for a given desired distance 44 between the X-ray source/image receptor 32/34, a larger C-shape can be used for the C-arm 12 without substantially increasing the overall machine height.

[0043] A diagnostic imaging system communication protocol is defined to implement bi-direction communication between the imaging computer 112 and the navigation computer 108. Tables 1 shows the messages provided for communication from the navigation computer 108 to the imaging computer 112.

1TABLE 1 From Navigation Computer to Workstation Message Data Ping no data Request Image no data Request no data Configuration Request File filename (e.g., using TFTP)

[0044] Table 2 shows the messages provided for communication from the imaging computer 112 to the navigation computer 108.

2TABLE 2 From Imaging Computer To Navigation Computer Message Data Ping no data Image (e.g., no data Fluoro) Begin Image (e.g., no data Fluoro) End New Exam no data Update Patient e.g., patient name, birth date, sex, patient ID, physician name, procedure, accession number Image Reply e.g., image width, height, bytes per pixel, endian, field of view, negation, subtraction, flip backward/upside- down, rotation, pixel data Configuration e.g., system model, intensifier diameter, C-arm type, Reply software version File Reply file data (e.g., using TFTP) Language Sync e.g., "echo FRENCH > /usr/vti/resource.file" or "sed " (e.g., using rexec) Time Sync e.g., "date 051614502000.34" (e.g., using rexec) Set IP Address e.g., "ifconfig hme0 <customer IP> netmask <mask>" (e.g., using rexec) Route Add e.g., "route add <destination IP> -netmask <mask> < gateway IP>" (e.g., using rexec)

[0045] With regard to FIG. 4, that figure shows a diagnostic imaging system communication protocol message format 400. The message format 400 is used with the diagnostic imaging system protocol to implement, preferably, a bi-directional connection-oriented TCP-based data transfer protocol. Once a connection is accepted and established (e.g., by monitoring port 8500), the client (i.e., message sender) and server (i.e., message receiver) threads keep the connection open. The server thread preferably blocks (i.e., waits or loops without performing other actions) waiting for the next message which will indicate a command to perform. Then, the server executes the command and returns a reply message (which may contain data) to the client. The server continues in a loop waiting for the next message.

[0046] The communication protocol generally processes one particular message at a time. That is, at the moment when a particular message is sent, the sender does not send any other message until a corresponding reply message is received. The message format 400 includes a fixed-length header 402 followed by the data section 404 associated with the message (if any). The same message header format 400 is used for the initial message and the reply.

[0047] Illustrated in FIG. 4 are a 1-byte Code field 406, a 1-byte Type field 408, a 1-byte Flag field 410, and a 1-byte Status field 412. A 4-byte Data Length field 414 is also provided. The Code field 406 and Type field 408 are defined for each message below. The Flag field 410 generally uses bit 0 as a reply flag (1: reply, 0: otherwise), bit 1 as a request flag (1: request for data, 0: otherwise), and bit 2 as an Endian indicator (1: big, 0: little). The Status field 412 provides status codes (as additionally explained below), for example, (0: OK, non-0: ERROR). The Data Length field 414 provides an unsigned 4-byte length of data to follow in the data section 404.

[0048] The Code field 406 of the message header 402 represents the message code that is common to both imaging and navigation computers. The Type field 408 represents a type that is a variation on the message code. The Flag field 410 represents the message flags that are used by the imaging and navigation computers to resolve the necessary action to be taken for each message. The specific cases of sending data versus requesting data are illustrated in FIGS. 5 and 6, respectively. For every message received, the returned message preferably has the same code as the sent message and the flags are incremented by one (reply flag is set high). The Status field 412 is used by the reply to indicate error conditions. The Data Length field 414 specifies the length of data following the header.

[0049] The Data Length field 414 is encoded big endian (encoded with the most significant byte first, to the least significant last) or little endian (encoded with the least significant byte first, to the most significant last). The Endian flag (bit 2 in the Flag field 410) specifies the endian encoding used for the rest of the message. This includes the Data Length field 414 in the message header 402 and any fields over one byte in the data field 404 of the message 400. With the use of the endian flag, the image data can be sent in the "endian" native to a particular machine without byte swapping each pixel greater than one byte in an image.

[0050] Turning briefly to FIG. 5, that figure illustrates a flow diagram 500 for sending data according to the diagnostic imaging system communication protocol. At step 502, the sender sends data (after formatting the header according to the header format 400) to a receiver. The receiver (which has been waiting and listening for a message) receives the data at step 504. The receiver responds at step 506 by sending an appropriate reply to the sender (formatted according to the header format 400, with the Flag field set as noted above). At step 508, the sender receives the reply and checks the status set by the receiver.

[0051] Similarly in FIG. 6, a flow diagram 600 for receiving data according to the diagnostic imaging system communication protocol is shown. At step 602, the sender sends a data request message (after formatting the header according to the header format 400) to the receiver. The receiver receives the message at step 604 and responds at step 508 by retrieving the requested data and sending an appropriate reply message (with the data) to the sender (formatted according to the header format 400, with the Flag field set as noted above). At step 508, the sender receives the reply message and may process or otherwise use the data provided in the reply message.

[0052] The messages are distributed into four general classifications: Event, Update Patient, Request Image, and Request Configuration classifications as shown in Table 3 below.

3TABLE 3 Message Description Code Flags Event Send an event, e.g., Fluoro, New Exam, Ping 1 0 (no-data) Update Imaging computer 112 sends patient 2 0 Patient information to Navigation computer 108 (data) Request Navigation computer 108 requests an image 3 2 Image from Imaging computer 112 (data in reply) Request Navigation computer 108 requests 4 2 Confi- configuration from Imaging computer 112 guration (data in reply)

[0053] Exemplary messages for use with the communication protocol are set forth below. Note that the first 8 bytes (0-7) of the message constitute the header (code, type, flags, status, and the data length) as shown in FIG. 4.

[0054] Name: Event

[0055] Description: Send an event to the peer

[0056] Message Direction: Bi-directional

[0057] Date Format: See below

[0058] Header:

[0059] Byte 0: Code (1)

[0060] Byte 1: Type (see Table 4)

4TABLE 4 Type Description 1 Ping (no-operation) 2 Imaging (e.g., Fluoro) Begin 3 Imaging (e.g., Fluoro) End 4 New Exam

[0061] Byte 2: Flags (initial=0, reply=1)

[0062] Byte 3: Status (0)

[0063] Byte 4-7: Data Length (0)

[0064] Data: None.

[0065] Name: Update Patient

[0066] Description: Send the patient data to the Navigation computer

[0067] Message Direction: Imaging computer to Navigation computer

[0068] Data Format: A concatenation of the patient fields where the first byte is the length of the field to follow. The patient fields are grouped, for example, in the following order: patient name, birth date, sex, patient ID, physician name, procedure, and accession number. The name encoding may be that used by the DICOM standard, Part 5, Section 6.2 Value Representation. For example, a patient name of "Jane Doe" would be sent as shown in FIG. 7.

[0069] Header:

[0070] Byte 0: Code (2)

[0071] Byte 1: Type (0)

[0072] Byte 2: Flags (initial=0, reply=1)

[0073] Byte 3: Status (initial=0, reply=see Table 5)

5TABLE 5 Status Description 0 OK 1 ERROR

[0074] Byte 4-7. Data Length (initial=data payload size in bytes, reply=0)

[0075] Data (initial message only):

[0076] Bytes 8-end: Concatenation of the patient fields

[0077] Each field is a preferably string of ASCII characters prefixed by a byte indicating the length:

[0078] Patient Name--This field consists of three components in the following order of occurrence: a) Family Name, b) Given Name, c) Middle Name. The components are delimited by the caret `` character. Interior null components require delimiters. Trailing null components, including delimiters, may be omitted.

[0079] Birth Date, e.g., a Text string

[0080] Sex, e.g., a Text string (typically `M` or `F`)

[0081] Patient ID, e.g., a Text string

[0082] Physician Name, e.g., using the same encoding as Patient Name

[0083] Procedure, e.g., a Text string

[0084] Accession Number, e.g., a Text string

[0085] Name: Request Image (and Reply)

[0086] Description: Request an image from the Workstation computer

[0087] Message Direction: from the navigation computer to the imaging computer

[0088] Data Format: An invalid image (test pattern, recalled image, or swap) is notified by an error in the reply message status. No data follows. A valid image is returned with a data payload.

[0089] Header:

[0090] Byte 0: Code (3)

[0091] Byte 1: Type (see Table 6)

6TABLE 6 Type Description 1 Left Display, 980x980x8-bit (typically used) 2 Right Display, 980x980x8-bit 3 Filter Memory, 980x980x12-bit 4 Image Memory, 980x980x12-bit 5 Mask, 980x980x12-bit

[0092] Byte 2: Flags (initial=2, reply=3)

[0093] Byte 3: Status (initial=0, reply, see Table 7)

7TABLE 7 Status Description 0 OK -image valid 1 INVALID -image is invalid i.e. test pattern, recalled image, or swap

[0094] Byte 4-7 Data Length (initial=0, reply=data payload size in bytes)

[0095] Data (reply only):

[0096] Byte 8-9: Image header length--offset from here, byte 8, to the image data

[0097] The value is typically 12 unless a different alignment of image data is needed. (16-bit unsigned integer)

[0098] Bytes 10-11: Image width in pixels (16-bit unsigned integer)

[0099] Bytes 12-13: Image height in pixels (16-bit unsigned integer)

[0100] Byte 14: Bytes per pixel allocated, typically 1 or 2 (8-bit unsigned integer)

[0101] Byte 15: Bits per pixel stored, assumes LSB at bit 0 (8-bit unsigned integer)

[0102] Byte 16: Image flags that specify image features:

[0103] Bit 0: Negation (1: yes, 0: no)

[0104] Bit 1: Subtraction (1: yes, 0: no)

[0105] Bit 2: Flip Backward (1: yes, 0: no)

[0106] Bit 3: Flip Upside-down (1: yes, 0: no)

[0107] Bits 4-5: Magnification Mode (10: 2.times., 01: 1.times., 00: norm)

[0108] Bit 6-7: Reserved

[0109] Byte 17: Reserved

[0110] Bytes 18-19: Degrees of Rotation 0-360 (16-bit unsigned integer)

[0111] Flip is applied before rotation transform

[0112] Bytes start-end: Image data--The start is determined from Header Length (bytes 8-9).

[0113] The image data length is determined by multiplying the image width, height, and bytes per pixel allocated.

[0114] Name: Request Configuration (and Reply)

[0115] Description: Request configuration information from the Workstation

[0116] Message Direction: from the navigation computer to the imaging computer

[0117] Data Format: See below.

[0118] Header:

[0119] Byte 0: Code (4)

[0120] Byte 1: Type (0)

[0121] Byte 2: Flags (initial=2, reply=3)

[0122] Byte 3: Status (initial=0, reply=see Table 8)

8TABLE 8 Status Description 0 OK 1 ERROR

[0123] Byte 4-7. Data Length (initial=0, reply=data payload size in bytes)

[0124] Data (reply only):

[0125] Bytes 8-end: Concatenation of the configuration fields

[0126] Each field is preferably a string of ASCII characters prefixed by a byte indicating the length. All data fields combined will not exceed 512 bytes total.

[0127] System--(e.g. "9800")

[0128] Image Intensifier Diameter--(e.g. "9", or "12")

[0129] Software Version--(e.g. "PN180130-08.sub.--7.1.2") The software version will preferably contain two numbers delimited by the under-bar `_` character. The first number is the OEC part number for the software (PN180130-08). The second number after the `_` is the version (7.1.2).

[0130] A magnification mode message is also defined to communicate the current magnification mode of an X-ray detector (e.g., an image intensifier). To that end, as examples, the magnification mode may specify one of a 12 inch, 9 inch, and 6 inch magnification mode for a 12 inch image intensifier or one of a 9 inch, 6 inch, and 4.5 inch magnification mode for a 9 inch image intensifier. Thus, the present imaging system allows navigation in several different magnification modes.

[0131] In particular, the Image End message may be used to synchronize image acquisition and coordinate determination. The command and control information provided over the network interfaces 206, 208, 214 allows the imaging computer 112 to inform the navigation computer 108 that image acquisition just completed. At that instant in time, the navigation computer 108 may obtain coordinate information from the x ray detector tracking sensor input port 116 to locate the image without intervening C-arm 130 movement and associated location error.

[0132] Thus, the present integrated fluoroscopic surgical navigation and imaging workstation provides a high speed digital communication interface between the navigation subsystem and the imaging subsystem, as well as a bi-directional command and control interface. As a result, full resolution digital images are quickly transferred, and the navigation system is coordinated with the imaging system to maintain accurate tracking of surgical tools. Furthermore, the present command protocol provides a standard communication protocol that may be used by any supporting navigation system to communication with any supporting imaging system. Additional components required by "Add-on" type systems (e.g., carts, monitors, monitor arms, power supplies, cabling, and the like) are eliminated, resulting in less crowding in the operating environment.

[0133] While the invention has been described with reference to a preferred embodiment, those skilled in the art will understand that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular step, structure, or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.

Claims

1. In a medical diagnostic imaging system, a communication protocol for providing bi-directional communication between a medical imaging subsystem and a medical navigational subsystem, the communication protocol comprising: a plurality of navigation subsystem to imaging subsystem messages; and a Begin Imaging and an End Imaging message for synchronizing image acquisition with navigation coordinate determination, the Begin Imaging and End Imaging messages included in imaging subsystem to the navigation subsystem messages.

2. The communication protocol of claim 1, wherein the communication protocol includes a magnification mode message specifying a magnification mode of an X-ray detector.

3. The communication protocol of claim 2, wherein the magnification mode specifies one of a 12 inch, 9 inch, and 6 inch magnification mode for a 12 inch image intensifier or one of a 9 inch, 6 inch, and 4.5 inch magnification mode for a 9 inch image intensifier.

4. The communication protocol of claim 1, wherein the navigation subsystem to imaging subsystem messages include an image request message, the imaging subsystem to navigation subsystem messages include an image reply message, and the image reply message comprises image width, image height, and pixel data.

5. The communication protocol of claim 4, wherein the image reply message further comprises bytes-per-pixel, field of view, and image rotation.

6. The communication protocol of claim 1, wherein at least one of the navigation subsystem to imaging subsystem messages and the imaging subsystem to navigation subsystem messages include a Ping response time message.

7. The communication protocol of claim 1, wherein the navigation subsystem to imaging subsystem messages include a system configuration request message.

8. The communication protocol of claim 1, wherein the imaging subsystem to navigation subsystem messages include a system configuration reply message.

9. The communication protocol of claim 8, wherein the system configuration reply message comprises a system model and software revision.

10. The communication protocol of claim 1, wherein the navigation subsystem to imaging subsystem messages include a file request message specifying a filename to transfer.

11. The communication protocol of claim 10, wherein the imaging subsystem to navigation subsystem messages include a file reply message with responsive data from a file identified by the filename.

12. The communication protocol of claim 1, wherein the imaging subsystem to navigation subsystem messages include a patient information message specifying at least patient name, sex, and patient ID.

13. The communication protocol of claim 1, wherein the imaging subsystem to navigation subsystem messages include a navigation subsystem network address selection message.

14. A method for communication in a bi-directional diagnostic imaging system between a medical imaging subsystem and a medical navigational subsystem, the method comprising: realizing in a navigation subsystem a plurality of navigation subsystem to imaging subsystem messages; realizing in the imaging subsystem a Begin Imaging and an End Imaging message for synchronizing image acquisition with navigation coordinate determination, the Begin Imaging and End Imaging messages included in imaging subsystem to navigation subsystem messages; and formatting the End Imaging message according to a predetermined message header format common to a plurality of the navigation subsystem to imaging subsystem messages and the imaging subsystem to navigation subsystem messages; and transmitting the End Imaging message from the imaging subsystem to the navigation subsystem.

15. The method of claim 14, wherein transmitting comprises transmitting over a high speed network connection.

16. The method of claim 14, wherein transmitting comprises transmitting over an Ethernet network connection.

17. The method of claim 14, wherein transmitting comprises transmitting according to the TCP/IP protocol.

18. The method of claim 14, further comprising: formatting an image request message according to the predetermined message header format; transmitting the image request message from the imaging subsystem to the navigation subsystem; formatting an image reply message according to the predetermined message header format; and transmitting the image reply message with image data from the imaging subsystem to the navigation subsystem.

19. The method of claim 14, wherein transmitting comprises transmitting across a private network between the navigation subsystem and the imaging subsystem.

20. The method of claim 14, further comprising transmitting a magnification mode message specifying a magnification mode of an X-ray detector.