The invention relates to server-client architectures in medical imaging, and in particular to processing of medical image data in a network environment.
Computer networks allow peripheral devices, data and computing applications to be shared amongst a number of users. This allows centralized management of a computing environment, helps reduce unnecessary duplication of computer resources, and can aid collaboration between users. For example, in a hospital or similar environment, it is common for patient data, e.g. medical image data, to be stored in a central data store from where it may be retrieved and subsequently processed, analyzed, viewed etc. by users working at computer workstations at different locations in the hospital (or working remotely over an appropriate link). This approach avoids the need for data to be stored locally to each of the users who might require it. Accordingly, the overall storage requirement of the computing system is much reduced. Furthermore, because there is only a single active copy of the data (there may be back-up copies), the integrity of the data and access control are easier to manage. This can be especially important in medical imaging applications, for example, to help reduce the likelihood that a clinician looks at a tampered, incomplete or accidentally modified version of the patient's medical data, or that an unauthorized person gains access to at the patient's data.
There are a number of different ways in which computing resources (e.g. memory and processors) can be distributed among clients and servers in a computer network environment. One way (and the more traditional for medical imaging applications) is the so-called “thick” client architecture, and another way is the so called “thin” client architecture.
FIG. 1 schematically shows a thick-client computer network 2 used in a hospital for processing and viewing medical image data. The network 2 comprises a server computer (“server”) 4 and a series of (in this case four) client computer workstations (“clients”) 6a-d. The server 4 and clients 6a-d communicate via a network interconnection 8, in this case a conventional a local area network (LAN) interconnection is used.
The server 4 includes a data store 10 in which medical image data are stored. This may be the central data store of the hospital providing long-term storage for all data, or it may be a limited-time or limited-purpose data store for a specific department such as radiology. In either case, the data store makes data accessible to the network 2. The server 4 further includes a data loader (not shown) which is operable to retrieve data from the data store 10 and to supply it to the network interconnection 8 through a server network-interface.
The client workstations 6a-d are identical to each other and comprise a display 12a-d and a client computer 14a-d. Each client computer 14a-d includes a client (or “local”) processor 16a-d and a client (or “local”) short-term storage memory 18a-d. The client processors 16a-d have sufficient processing power to run the applications the network supports, and each client memory 18a-d is large enough to store the amount of patient data required by these applications. The client computers 14a-d further include processing capability to perform tasks such as driving the display, receiving and processing user inputs from attached input devices (e.g. keyboards and mouse pointers), and network communication.
FIG. 2 schematically shows a typical workflow in the thick-client network shown in FIG. 1. All four of the client workstations are active in processing medical image data. There are three main stages to the workflow which are relevant here.
Firstly, the server 4 sends patient data from its data store 10 to the local memories 18a-d of each client workstation 6a-d. This is shown schematically in FIG. 2 by arrows labeled W1, and also by shading of the client memories 18a-18d indicating that they contain patient data. The transfer of patient data is preferably done ahead of the time that the data is needed by a user of one of the client workstations 6a -d, for example during the previous night. Because the client memories 18a-d are smaller than the size of the server's data store, data to be transferred in advance are selected in accordance with certain rules. For example, data selected for ahead-of-time transfer to a given client workstation can be based on the clinical specialty of the user of the client workstation, the location of the client workstation in the hospital, recently accessed data for that workstation, or simply a random distribution of data from different patients, for example.
Secondly, when users at each of workstations 6a-d wish to work with data associated with a particular case, the relevant patient data is loaded from the associated local memory to the corresponding client processor 16a-d (which is running the imaging application being used by the user). This is schematically shown in FIG. 2 by the arrows labeled W2. The client processors 16a-d are shown shaded in FIG. 2 to indicate that they are processing data. If the required data are not already in the local memory 18a-d, they must be retrieved from the server's data store 10 over the network interconnection 8. This can take a significant amount of time due to the large size of typical medical imaging data sets.
Thirdly, images generated by the various client processors running the imaging application are displayed to the user on the displays. This step is schematically indicated in FIG. 2 by arrows labeled W3.
In brief summary, in a thick-client medical imaging network such as shown in FIGS. 1 and 2, the intensive computational tasks associated with generating images, e.g. image rendering, are performed locally on locally stored copies of data obtained from the server data store 10.
The main drawback of the thick-client approach is the reliance on transferring patient data ahead of time to each client workstation. This limits the flexibility of the user's workflow (e.g. by requiring them to indicate the day before what work they will be doing the following day), and cannot cope with emergencies, such as an emergency medical case. As noted above, it is possible to download a patient's data on demand from the server when a user requests to open a patient study that is not contained in the current locally stored data. However, this is undesirable because the patient data for any given study is large (from hundreds of megabytes up to a few gigabytes) and thus transmitting patient data on demand requires the user to wait up to several minutes for the data to arrive over the network.
FIG. 3 schematically shows a thin-client computer network 22 used in a hospital for processing and viewing medical image data. To some extent this may be considered to operate in an opposite manner to the thick-client network of FIGS. 1 and 2. The thin-client network 22 comprises a server computer (“server”) 24 and a series of (again four) client computer workstations (“clients”) 26a-d. The server 24 and clients 26a-d communicate via a network interconnection 28, again this is a conventional LAN.
The server 24 includes a data store 30 in which medical image data are stored. As with the network 2 shown in FIGS. 1 and 2, this may be the central data store of the hospital or a short term or departmental data store. The server 24 further includes processing capability which is shown schematically in FIG. 3 as four discrete processors 36a-d. The server processors 36a-d each have sufficient processing power to run the imaging applications the network supports. The server 24 further includes a data loader (not shown) operable to retrieve data from the memory 30 and a server network-interface (not shown) allowing results of an application executed by the server processors (typically a succession of two-dimensional (2D) image frames rendered from three-dimensional (3D) medical image data) to be supplied to the network interconnection 28.
The client workstations 26a-d are identical to each other and comprise a display 32a-d and a client computer 34a-d. Each client computer 34a-d includes sufficient processing power to provide for a client network-interface and a display driver which together allow the client computers to receive the results of applications executed by the server processors (e.g. rendered images) and display them. The client computers are further able to receive and process user inputs from attached input devices and forward corresponding instructions to the server processor 36a-d so that a user can interact with the software application running, Commonly the client workstations may lack either the processing power, specialist processing resources such as a Graphics Processing Unit (GPU), or the memory to run the imaging application the network supports. I he client workstations may be conventional low-spec “desktop” PCs, or dedicated “dumb” terminals, for example.
FIG. 4 schematically shows a typical workflow in the thin-client network 22 shown in FIG. 3. There are two main stages to the workflow relevant here.
Firstly, in response to a request from a user of one of the workstations 26a-d to study a particular patient's data using a particular software application, the software application is initialized in one the server processors 36a-d, and the relevant patient data is retrieved from the data store 30 and loaded to the server processor. This is shown schematically in FIG. 4 for all four client workstations by arrows labeled V1.
Secondly, for each client workstation, the server processors process the data as appropriate under control of the software application and generate corresponding results, e.g. rendered images. The server processors 36a-d are shown shaded in FIG. 4 to indicate that they are working on processing data. The results of the processing are supplied via the server network-interface across the network interconnection 28 to the client network-interface of the various client workstations as appropriate. The client workstations then displays the results of the processing to the users on their displays. This is schematically shown in FIG. 4 by the arrows labeled V2. The arrows V2 are shown connecting directly from the server processors to the displays to indicate that the client is not playing a significant (in terms of processing resources) role in processing the data.
Because the resulting images to be displayed will often be much smaller (in terms of bytes) than the patient data from which they are derived, the thin-client approach is less prone to delays associated with network traffic. The thin-client scheme can be implemented by establishing a communication between the server and the client using a remote display protocol such as X11 or VNC, for example, or by establishing a proprietary communication with a program running on the client computer.
The thin-client network may still be heavily loaded (e.g. because a relatively low bandwidth network interconnection is employed), but the loading will be relatively continuous. This situation is often easier to engineer compared to a network that is frequently under utilized but has high peak bandwidth requirements (e.g. associated with data transfer in a thick-client network). Furthermore, because the server is aware of the activity of all users, it can more effectively employ predictive loading techniques to retrieve patient data from the data store 30 before they are needed.
Thus in a thin-client medical imaging network, the intensive computational tasks associated with generating images, e.g. image rendering, are performed at the server, with only the resulting images being transferred across-the network interconnection for display to a user. A key advantage of this approach is that the data path from the data store 30 to the server processors 36a-d can be a dedicated fast connection so that the server processors can quickly initiate processing of patient data from the data store on demand. Once the processing is complete, the resulting images can be transferred quickly for display to the user due to their small size.
The two alternative client-server architectures discussed above (i.e. thick-and thin-clients) each have their advantages and disadvantages, which are largely complementary. In the thick-client architecture, if the rules for distributing data ahead of time are not adequately effective, the user has to wait an objectionable amount of time for patient data to be sent to the client when demanded. In the thin-client architecture, the system is able to access patient data quickly, but as the number of clients increases, the server begins to encounter scalability limitations (i.e. difficulty adding more client workstations to an existing network or implementing a new network with a large number of client) in respect of both processing power and network bandwidth (because the server is doing the work for all clients and the network is continually transferring results to the clients). Thus it is not possible to keep adding client workstations as demand increases without decreasing performance for each user. Furthermore, because in a thin-client network the data processing that happens in response to user's input occurs remotely from the client workstation, there can be significant latency in responding to user inputs. This makes the system appear to be slow and unresponsive and can be frustrating for users.
Thus when implementing a network, deciding between a thick-or a thin-client architecture involves a trade off between potentially long waiting times to open a study (thick-client) and problems with scalability and latency during use (thin-client).
An approach between the above described extremes of “pure” thick-client and “pure” thin-client network architectures for image rendering is proposed in U.S. Pat. No. 6,384,821 [1] and U.S. Pat. No. 6,377,257 [2]. These propose a scheme in which rendering tasks are split between a server and a client. The proposed scheme is for rendering synthetic data comprising a plurality of 3D geometric models representing different image objects to be rendered, with some objects (e.g. foreground objects) being rendered at the client in accordance with the thick-client approach and other objects (e.g. background objects) being rendered in lesser quality at the server, in accordance with the thin client approach. A composite of the separate renderings is then displayed to the user. However, this approach is primarily applicable to rendering synthetic images represented by a plurality of different geometric models which may each be rendered independently, such as when rendering a computer animated scene for a motion picture, computer game, or flight simulator. The approach is not practically applicable to rendering medical image data because medical imaging data typically comprise a continuous array of voxels representing a patient's body, or part thereof, that does not present any obviously advantageous decompositions between parts that can be rendered on the server and parts that can be rendered on the client. It is possible to separately render arbitrarily selected parts of the data on the client and parts on the server (possibly at different resolutions), but this is simply an example of parallel decomposition of the rendering task, and at best achieves a compromise between the goals of thin-client and thick-client configurations.