SmartWADO: an Extensible WADO Middleware for Regional Medical Image Sharing

Abstract

Medical image sharing is an important problem in modern radiology, with wide applications in Internet and mobile devices. Some important features need to be added and optimized to medical image sharing. In this paper, we present an extensible Web Access to DICOM Persistent Objects (WADO) middleware based on image cache and real-time Web monitor technology for regional medical image sharing. We first develop the extension method of WADO standard and workflow of extended WADO service. Then, we design a medical image cache method to improve the performance of medical image on-demand transmission. Using the real-time monitor can discover the performance bottlenecks and optimized critical points. The experimental results show that the middleware effectively delivers medical images and reports to Web clients over the Internet, regardless of the platform used for access. It can be deployed in one hospital to provide WADO service to medical workers and also can be applied to regional picture archiving and communication systems (PACS) to transmit medical images and reports to Internet users in a way that is transparent to end-user applications.

Introduction

Medical imaging technology has become the primary method of diagnosis [1]. Due to the large size and increasing information of medical images, storing and sharing the information are becoming increasingly important [1–3]. Cloud-based picture archiving and communication systems (PACS) are efficient for archiving medical images, allowing Web clients to access images and reports from anywhere, over wireless networks, regardless of the platform used for access [4]. With popularity of the Internet and mobile devices, remotely accessing and presenting medical images through the Web are important for modern radiology [5]. Digital Imaging and Communications in Medicine (DICOM) is widely used for reviewing images and performing primary diagnosis within radiology and other imaging departments, by means of PACS [6]. Web Access to DICOM Persistent Objects (WADO), which is another DICOM Internet extension, specifies Web-based service for accessing and presenting DICOM persistent objects such as images and reports from PACS [7]. Despite the fact that WADO has some disadvantages, it is widely applied to integration and sharing of medical images and is also included in other medical information exchange standards as a retrieve service. The IHE cross-enterprise document sharing for imaging (XDS-I) and cross-community access for imaging (XCA-I) integration profiles include components common to the WADO standard [8], which are considered to be the most likely future standard for medical image exchange.

WADO service has become an important component of modern PACS to ensure that medical images will be easily accessible within Web-based applications through open standard. Many Web PACS or middleware based on WADO have been presented and developed to solve medical image sharing and accessing over the Web [5, 9, 11–13], which have provided alternative approaches. Paper [5] compares medical image access and presentation system (MIAPS) with eRAD PACS, MERGE eFilm, AGFA IMPAX, and DIPACS from “Retrieval methods,” “Tile-based transmission,” “Image prefetching,” “System architecture,” “Platform independent,” “Mobile terminal support,” and “Security and privacy protection.” From Figure 20 in this paper, we can see that MIAPS provides two unique functions: multiple DICOM image retrieval methods and tile-based transmission of single-slice DICOM images [5]. But several important features need to be added and optimized to enhance the capabilities of WADO service: (1) absence of a mechanism to support multiple PACS simultaneously, (2) absence of performance monitor and analysis method to the key points of WADO service, (3) inability to provide a real-time dynamic performance monitor screen, and (4) a need for the image cache performance to be further optimized [5, 9].

To overcome these shortages, this paper presents an extensible WADO service framework (SmartWADO) based on image cache and real-time Web monitor technology, which is specially designed as a cost-efficient service middleware allowing for accessing, sharing, and visualizing DICOM persistent objects from anywhere and anytime over the Internet. The proposed system includes three highlights: (1) an extension method base on a routing table to support multiple PACS simultaneously, (2) a Web-based real-time monitor method to discover the performance bottlenecks and optimized critical points, and (3) a medical image cache method base on key-value to improve the performance of medical image on-demand transmission.

The rest of this paper is organized as follows: “Related Works” provides a brief overview of PACS and WADO service. Some of their shortcomings are pointed out. “System Description and Computational Methods” details the architecture, workflow, relative computational methods, and implementation. First, we provide an overview of system architecture. Second, the extension method of the WADO standard and the workflow of extended WADO service are depicted. Third, the on-demand medical image cache structure and method are described. Fourth, a memory-based real-time monitor method and Web-based interface are shown. Finally, we report the implementation of SmartWADO. “System Evaluation” demonstrates the evaluation of functionality and performance. Salient points are given in “Discussion.” Finally, we conclude our work and present the future work in “Conclusion.”

Related Works

In modern medical systems, huge amount of text, words, images, and videos are produced and stored in PACS, and the medical domain strongly feels the need to share information and to make it easily accessible to other physicians [10]. DICOM WADO and WADO via Web services are two important stepping stones to ensure that medical images will be easily accessible within these Web-based applications through open standard [8]. In this context, there are many research works on the WADO standard and WADO via Web services, which are mainly polarized into three approaches:

1. WADO service is integrated into Web-based PACS to provide service for a specific PACS. Several Web-based PACS architectures and systems based on WADO are presented and implemented to request and transmit images and reports from archives to Internet users [11–13]. The authors of [14] present a fast flash-based Web PACS viewer for displaying large DICOM images, and WADO service is exploited with the goal of retrieving small image tiles to compose an image on the client side. Paper [15] explores the current state of the art in bringing radiological images to modern mobile phones and draws a conclusion that mobile Web browsers can be used to read DICOM images from PACS archive with WADO, and mobile Web-based radiological applications can satisfy basic and advanced requirements of radiologists in everyday medical image analysis.

2. Extending the WADO standard to provide more useful functions. There have been published efforts to propose extensions to WADO such as the Web access to DICOM archives (WADA) service [16]. The WADA service introduces a query and reporting extension to the WADO standard. It can access all levels of DICOM hierarchy and process requests for medical reports related to series and studies.

3. Integrating and sharing medical images using the WADO standard through the Internet. In [17], the authors described how XDS-I can be used in conjunction with WADO and DICOM transfer syntax for JPEG 2000 Interactive Protocol (JPIP) to enable streaming of medical images directly from EHR-connected imaging sources to image processing workstations. MIAPS is a Web-based system developed in [5] for medical images sharing and teleradiology through the Internet. A RESTful image gateway for multiple medical image repositories is developed in [9] to provide transparent bridging between PACS-DICOM and Web universes.

These studies gave a big boost to the development of the WADO standard, which offers alternative solutions for integrating, sharing, accessing, and visualizing images and medical reports from anywhere and anytime over the Internet. However, it is desirable to provide access to more than a single PACS [9]; WADO service only queries or retrieves DICOM persistent objects from one PACS simultaneously because of missing remote application entity (AE) information of remote PACS in a WADO request. The current implementation of WADO service is difficult to position the performance bottlenecks and optimize key points immediately, because they do not provide performance monitor and analysis method to the key points of a WADO response. The real-time performance of current systems cannot be found directly because the Web-based real-time monitor and visualization display are not supported. The cache performance needs to be further optimized because image caching structures and algorithms are relatively simple [5, 9].

System Description and Computational Methods

System Architecture

The SmartWADO is implemented as a service middleware and the architecture is depicted in Fig. 1. The Web client, usually a Web browser, connects to the SmartWADO via wired or wireless (Wi-Fi, 3G, 4G) networks with HTTP/HTTPs protocol over the Internet to access images and medical reports. The SmartWADO connects to PACS servers with DICOM protocol or WADO to query or retrieve DICOM persistent objects, which will be parsed and converted to a specific format according to the WADO request. The whole procedure can be monitored and displayed in the Web page, especially as regards the performance of key points.

Fig. 1.

Architecture of SmartWADO

As shown in Fig. 1, the SmartWADO consists of WADO service, cache service, and monitor service. As a core component of SmartWADO, the WADO service provides a Web interface to access medical images and reports which may come from more than one PACS. The cache service stores recently requested images to accelerate image transmission. The monitor service records the response time of every key point, and the results will be displayed via a Web page with dynamic curve.

Extension for the WADO Standard

We present a simple method to extend the WADO standard. As already mentioned, the WADO service only retrieves DICOM persistent objects from one PACS simultaneously because of missing AE information of remote PACS in the WADO request. However, it is desirable to provide access to more than a single PACS [9], especially in the environment of regional medical image sharing. The extension method is that we add a remote PACS routing table on the server side.

In SmartWADO, we establish a mapping between StudyUID and remoteAE. SmartWADO gets the value of StudyUID from the WADO request and retrieves DICOM persistent objects from the corresponding remoteAE. The details of StudyUID and remoteAE are stored in the routing table on the server side, where $\mathrm{routing}\mathrm{table}=\left\{\stackrel{\mathrm{routeKey}}{\overbrace{\mathrm{StudyUID}}},\stackrel{\mathrm{AEConfig}}{\overbrace{\mathrm{remoteAE},\left\{\mathrm{hostName},\mathrm{port},\mathrm{retrieveType},\mathrm{wadoContext},\mathrm{wadoPort},\mathrm{aeStatus}\right\}}}\right\}$. The values of the attributes in the routing table are maintained by SmartWADO. After SmartWADO starts, available routing information (aeStatus = 1) is loaded into a hash table in memory. Each routing record in the hash table is denoted by a unique key, which corresponds to a unique value object that consists of remoteAE, hostName, port, retrieveType, wadoContext, wadoPort, and aeStatus.

Figure 2 shows the workflow of extension. First, SmartWADO gets the value of StudyUID from the WADO request sent by the Web client. Second, SmartWADO gets the details of a corresponding remoteAE from the routing table and retrieves DICOM persistent objects from this remoteAE. If no remoteAE is found, SmartWADO retrieves DICOM persistent objects from default PACS.

Fig. 2.

Workflow of extension for WADO

Extended WADO Service

The Web client sends query parameters to the WADO service through the HTTP GET method. The WADO service first retrieves DICOM persistent objects from the remote PACS according to remoteAE. Then, the object is converted to an image or report (a recently requested image is obtained from cache). Finally, the WADO service responds to the Web client by seeding one or more objects in a proper Multipurpose Internet Mail Extension (MIME) type. Figure 3 depicts the flowchart of the WADO service. The detailed procedure of the extended WADO service is as follows:

• Step 1The Web client sends a WADO request to SmartWADO.
• Step 2The WADO service determines the content type. If the content type is not an image type (image/jpeg, image/png), then go to step 4.
• Step 3The cache service retrieves the requested image from cache. If the image is null, then go to step 4; otherwise, go to step 9.
• Step 4The WADO service determines the retrieve type of the request. If retrieve type is WADO, then go to step 8.
• Step 5The WADO service downloads the DICOM persistent object from the remote PACS via C-MOVE or C-GET.
• Step 6The WADO service parses and coverts the DICOM file to a specific format according to the content type. If the content type is not an image (image/jpeg, image/png) then go to step 9.
• Step 7The cache service puts the image to cache; then, go to step 9.
• Step 8The WADO service sends the WADO request to the remote PACS and gets a response. If the content type is an image type (image/jpeg, image/png), then go to step 7.
• Step 9The WADO service returns the image or report to the Web client.

Fig. 3.

Flowchart of the extended WADO service

Image Cache Service

Cache service is an important component to accelerate image transmission, which stores recently requested images to the cache server. For the next request, the cached image is directly delivered to the Web client without retrieving from the remote PACS and decoding from the DICOM persistent object.

Figure 4 shows the cache structure. It consists of a cache index and a cache file; the former is used to store the cache index to quickly locate the cache file, and the latter is used to store cache files. Cache indexes are stored in memory and cache files are stored on disk. The cache index consists of a key and a value, which is implemented as a hash table and stored in memory. Each index in the cache is denoted by a unique key, where

Fig. 4.

Cache structure in cache service

$\mathrm{Key}=\left\{\begin{array}{l}\mathrm{studyUID}\cup \mathrm{seriesUID}\cup \mathrm{objectUID}\cup \mathrm{rows}\cup \mathrm{columns}\cup \mathrm{region}\cup \mathrm{windowWidth}\cup \\ \mathrm{windowCenter}\cup \mathrm{imageQuality}\cup \mathrm{frameNumber}\cup \mathrm{contentType}\end{array}\right\}$. The parameters in the key (studyUID, seriesUID, objectUID, rows, columns, region, windowWidth, windowCenter, imageQuality, contentType, and frameNumber) are defined by the WADO request. Each index in the cache corresponds to a unique value used to store the information of the cache file, where Value = {filePath, imgSize, accCount, lastAccTime}.

Value update follows the LRFU (Least Recently/Frequently Used) policy: When the storage space of cache indexes or cache files exceeds a predetermined threshold, the least recently used or least frequently used cache file is firstly replaced by a new image file. The LRFU policy uses a value, called CRF, to quantify the likelihood that a block will be referenced in the near future. Each reference to a block in the past contributes to this value, and a reference’s contribution is determined by a weighing function F(x), where x is the time span from the reference in the past to the current time. The theoretical model for the algorithm is as the follows [18]:

$$C_{t_{\mathrm{base}}}\left(b\right)={\displaystyle \sum _{i=1}^{k}F\left(t_{\mathrm{base}}-{t_b}_{{}_i}\right)}$$ 1

where the CRF value of a block b at time t_base is denoted by $C_{t_{\mathrm{base}}}\left(b\right)$, F(x) is a weighing function, and $\left\{t_{b_1},t_{b_2},t_{b_3},\cdots ,t_{b_k}\right\}$ are the reference times of block b and $t_{b_1}<t_{b_2}\cdots <t_{b_k}<t_{\mathrm{base}}$.

In fact, F(x) = (1/p)^λx is used as an adequate weighting function, where x is the difference between the current time and the time of a reference in the past, p ≥ 2, and λ ranges from 0 to 1. The theoretical model is simplified as follows:

$$C_{t_{b_k}}\left(b\right)=F\left(0\right)+F\left(\delta \right)C_{t_{b_{k-1}}}\left(b\right)$$ 2

where $\delta =t_{b_k}-t_{b_{k-1}}$.

As for implementation, we realize four methods to manage cache service. The method called searchIndex searches index from the hash table and quickly locates the cache file. The getFromCache method gets the image file from the cache server according to the index. The writeToCache puts recently requested images to the cache server, including the index and image file. The least recently/frequently used file is replaced with the new requested image file using the updateCache method when the storage space of cache indexes or cache files exceeds the predetermined threshold.

Real-Time Monitor Service

We propose a memory-based real-time monitor method and implement a Web-based interface for displaying the performance of SmartWADO. The former is used to monitor response time of key points, and the latter displays monitor data via a Web page with dynamic curve. We can timely detect performance bottlenecks and optimized critical points of the WADO service. Meanwhile, monitor data will be written to a log file.

There are four performance key points in the response of the WADO service: content type validation, DICOM file downloading, DICOM object parsing and conversion, and cache access. The response time and file size (cache size) of these key points are monitored and recorded in a memory object named monitorObject, where

$$\mathrm{monitorObject}=\left\{\mathrm{reqCount},\stackrel{\mathrm{download}‐\mathrm{dicom}‐\mathrm{file}‐\mathrm{from}‐\mathrm{PACS}}{\overbrace{\mathrm{fileSize},\mathrm{validateTime},\mathrm{loadTime},\mathrm{parseTime}}},\stackrel{\mathrm{get}‐\mathrm{image}‐\mathrm{from}‐\mathrm{cache}‐\mathrm{server}}{\overbrace{\mathrm{cacheCount},\mathrm{cacheTime},\mathrm{cacheSize}}}\right\}$$

The numerical values of the attributes in monitorObject (reqCount, validateTime, loadTime, parseTime, fileSize, cacheCount, cacheTime, cacheSize) are automatically calculated by summing.

How to display these values is another problem. The Web interface displays the statistical value in each interval. We regularly get monitor data from the memory object and calculate the value of each monitored attribute.

Let n is the number of requests for time period t, m is the cache count in t, $p_{{\mathrm{time}}_{\mathrm{i}}}$ presents the ith request response time of the jth critical point, $f_{{\mathrm{size}}_{\mathrm{i}}}$ is the file size of the ith request, $c_{{\mathrm{time}}_k}$ is the cache response time of the kth request, and $c_{{\mathrm{size}}_k}$ is the cache image size of the kth request. The calculations are as follows:

Average size of file and cache transfer:

$$\mathrm{transSize}=\left\{\left({\displaystyle \sum _{i=1}^{n-m}{f_{\mathrm{size}}}_{{}_i}}\right)/\left(n-m\right),\left({\displaystyle \sum _{i=1}^m{c_{\mathrm{size}}}_{{}_j}}\right)/m\right\}$$ 3

Average rate of file and cache transfer:

$$\mathrm{transRate}=\left\{\left({\displaystyle \sum _{i=1}^{n-m}{f}_{{\mathrm{size}}_i}}\right)/t,\left({\displaystyle \sum _{j=1}^m{c}_{{\mathrm{size}}_j}}\right)/t\right\}$$ 4

Average response time of each point:

$$\begin{array}{l}\begin{array}{c}\hfill \mathrm{avgTime}=\left\{\mathrm{validateTime},\mathrm{loadTime},\mathrm{parseTime},\mathrm{cacheTime}\right\}=\left\{\left({\displaystyle \sum _{i=1,j=1}^{n-m}{p}_{{\mathrm{time}}_{ij}}}\right)\right./\left(n-m\right),\hfill \\ \hfill \left.\left({\displaystyle \sum _{i=1,j=2}^{n-m}{p}_{{\mathrm{time}}_{ij}}}\right)/\left(n-m\right),\left({\displaystyle \sum _{i=1,j=3}^{n-m}{p}_{{\mathrm{time}}_{ij}}}\right)/\left(n-m\right),\left({\displaystyle \sum _{j=1}^m{c_{\mathrm{time}}}_{{}_j}}\right)/m\right\}\hfill \end{array}\\ \end{array}$$ 5

Cache hit rate:

$$\mathrm{cacheRate}=\frac{m}{n}$$ 6

Average overall response time:

$$\mathrm{overallTime}=\left({\displaystyle \sum _{i=1}^{n-m}{\displaystyle \sum _{j=1}^3{p}_{{\mathrm{time}}_{ij}}}}+{\displaystyle \sum _{j=1}^m{c_{\mathrm{time}}}_{{}_j}}\right)/n$$ 7

As for implementation, we use the open-source package HighChart [19] to dynamic display monitor data via the Web interface. HighChart is a charting library written in pure JavaScript, offering an easy way of adding interactive charts to the Web application. First, a program defined in the Web page gets monitor data from memory in each interval. Second, monitor data is calculated using the above methods (Eqs. (3–7)). Third, front-end dynamic updates the HighChart curve in the Web page using these data. In addition, server memory usage, CPU usage, and memory usage of the Web container are also monitored, and the high-usage metrics will be alarmed.

Implementation of SmartWADO

We implemented the SmartWADO mainly with Java technologies for portability and interoperability reasons. DICOM communication is provided through the dcm4che2 toolkit, which is a robust implementation of DICOM standard based on Java [20]. We use open-source PACS, namely dcm4chee, which is an implementation for image manager archive based on dcm4che2 library, to provide DICOM archives for storage and retrieval of DICOM images [20]. The SmartWADO is pre-packaged and deployed within the Tomcat application server.

The function of SmartWADO consists of configuration, cache management, system monitor, and service engine. The Web interface of core configuration is shown in Fig. 5. After SmartWADO start-up, the detailed configuration of the remote PACS registered to the routing table via the Web interface is given in Fig. 5a. DICOM listener service must be started when the retrieve type is C-MOVE; AE and port are configured in Fig. 5b. Cache management provides some functions relative to cache service. Some parameters which are used to guide cache service are maintained in Fig. 5c. All of the configuration information is performed through an XML file named server-config.xml.

Fig. 5.

Web interface of core configuration. a Configuration of the remote PACS routing table. b Configuration of the DICOM listener. c Configuration of the cache parameter

After these configurations, SmartWADO is started up and provides WADO service to Web clients. Service engines are some programs that run in the background, such as WADO service, cache service, monitor service, DICOM conversion service, and DICOM listener service. The monitor service will monitor all WADO requests and display monitor data via a Web page with dynamic curve. Figure 6 illustrates six different dynamic monitor curves.

Fig. 6.

a–f Web interface of the real-time monitor

From left to right, up to down, Fig. 6a shows the usage of CPU, memory, and Tomcat memory. The high-usage metrics will be alarmed. The average transfer size and rate in each interval are depicted in Fig. 6b, c; the value of the former is calculated by Eq. (3), and that of the latter is obtained by Eq. (4). The average response time of key points is displayed in Fig. 6d, and the value is calculated by Eq. (5). Figure 6e displays cache hit rate in each interval, and the value is calculated by Eq. (6). The overall response time is shown in Fig. 6f, and the value is calculated by Eq. (7).

System Evaluation

Functionality Evaluation

To demonstrate functionality and performance, SmartWADO is installed in the Hospital of Traditional Chinese Medicine and Intelligent System Laboratory in our university. There are two servers, five PCs, one iPad, and one smart phone in our network. One server is used to deploy SmartWADO to provide WADO service over the Internet. The other is used as PACS to store and retrieve DICOM files. The open-source PACS (dcm4chee), which contains 20 GB of DICOM files (more than 9.6 million images), is deployed on this server. The five PCs are used as workstation or Web browser to retrieve images or reports. All servers and PCs are connected by a gigabit switch. The iPad and smart phone are used to access images or reports over wireless connections, such as Wi-Fi, 3G, 4G, or WiMax. Figure 7 shows the scenario wherein SmartWADO is accessed via different devices.

Fig. 7.

SmartWADO accessed via devices with different resolutions. a Smart phone. b iPad. c Web browser

Performance Evaluation

Performance Estimation of Key Points

We evaluate the performance of the four key points as mentioned above to discover the performance bottlenecks; the fetching times of the key points for seven different concurrent retrieval requests were measured. We read all log files in the selected folder, analyze the data, and display results. Figure 8 depicts the average response time and trends of the key points.

Fig. 8.

Average response time of the key points

From Fig. 8, the average response time to download DICOM files is far higher than that of the other three key points. With the increase of requests, the average response time to download DICOM files witnesses a trend of increase by leaps and bounds and that of the other three key points reveals a general trend of slight rise, especially for cache response time.

Image Cache Hit Rate Analysis

We analyze image cache hit rate with seven different concurrent retrieval requests in a steady state. The data from log files is analyzed and displayed in Fig. 9.

Fig. 9.

Image cache hit rate

As can be seen from Fig. 9, the image cache hit rate reveals a general trend of slight rise, from 57 to 64 %, with the increase of concurrent requests. There are some slight fluctuations in 15 concurrent requests. The reason is that some of the requests are generated by a program in a random way. This procedure cannot simulate practical scenarios, and it needs to be further optimized.

Overall Performance Evaluation

To evaluate the overall performance of SmartWADO with different concurrent retrieval requests, real-time response time (no cache), cache response time, and overall response time for the seven different concurrent retrieval requests are evaluated. Real-time response time consists of content type validation time, DICOM file download time, and DICOM object parsing and conversion time. Figure 10 shows the average response time and trends of the four indicators.

Fig. 10.

Average overall response time of SmartWADO

As indicated in Fig. 10, the real-time response time is far higher than the cache response time. The former reveals a trend of dramatic increase while the latter witnesses a trend of slight rise. The reason is that real-time response needs to retrieve DICOM persistent objects from the remote PACS and convert it to a specific format according to Web clients, yet cache response directly delivers the image to the Web browser from the cache. Although, the overall response time is also on the rise, but it is much lower than the real-time response time. The overall response time is no larger than 4 s due to contributions of cache service.

Discussion

Many teleradiology systems have been implemented and deployed worldwide in recent years. Paper [5] compares the properties of MIAPS with those of other systems and the details are depicted in Figure 20 in this paper. As can be seen from the paper, compared with the above systems, our paper provides three advantages. The first advantage stems from the extension to the WADO standard. We present a simple method to extend the WADO standard for regional PACS. The method adds a remote PACS routing table on the server side. The second is associated with image cache service, which proposes an on-demand medical image cache and transmission method based on key-value. The last is that we propose a memory-based real-time monitor method and implement a Web-based interface for dynamic displaying of the value of performance.

The first and third features are not found in the above systems. Medical image cache has been implemented in paper [5] and paper [9]; the former presents a cache structure based on key-value and replacement algorithm follows the FIFO scheme, and the latter uses Least Recently Used (LRU) as the replacement mechanism. The above method improves the performance of image transmission. However, those structures and replacement policies are relatively simple. The cache structure proposed in our paper is also based on key-value, but only cache indexes are stored in the main memory; cache files are stored on disk. This structure not only can quickly determine whether the request has been cached but also can quickly locate cache files. Our replacement mechanism follows the LRFU policy which inherits the benefits of the two policies (Least Recently/Frequently Used) and allows a flexible trade-off between recency and frequency of references in basing the replacement decision [18]. From Fig. 8, we can draw the following conclusions: (1) Average response time directly related to concurrent request number. With the increase of the concurrent request number, the average response time also increases, though margins of the rises varied. The reason is that more requests exert more pressure on SmartWADO and remote PACS. (2) To download DICOM files is the key to performance. As can be seen from Fig. 9, the image cache hit rate reveals a general trend of slight rise. Figure 10 shows that the proposed cache structure and method contribute a lot to the overall performance of SmartWADO.

Currently, SmartWADO provides function and workflow to access and share medical images and reports, which can be easily integrated with other existing systems, such as PACS, EMR (electronic medical record) system, HER (electronic health record) system, or PHR (personal health record). In this version, we only implement the WADO-URI communication model and cannot provide a query mechanism. The query mechanism is a novel function that modern DICOM Web service should support. In addition, cache service only cache medical images; the other formats, such as DICOM files, medical reports, or videos, cannot be cached.

Conclusion

In this paper, we present SmartWADO which is an extensible WADO middleware based on image cache and real-time Web monitor technology for regional medical image sharing. The extension for the WADO standard, real-time Web monitor, and image cache are the major novel features. SmartWADO is designed as an abstraction layer over deployed PACS, which can retrieve DICOM persistent objects from multiple PACS simultaneously. The experimental results show that the middleware effectively delivers medical images and reports to Web clients over the Internet, regardless of the platform used for access. SmartWADO can be deployed in a hospital, which retrieves DICOM persistent objects from a single PACS, to provide WADO service to medical workers. It also can be applied to work across various institutions, which retrieves DICOM persistent objects from multiple PACS simultaneously, to transmit medical images and reports to Internet users in a way that is transparent to end-user applications.

In future work, we will further improve the system as follows: The first is that we will reconstruct the system and implement the rest of the communication modes (WADO-WS, WADO-RS, QIDO-RS, and STOW-RS) according to the WADO standard (2014 edition) [21]. Then, we plan to further optimize cache service; all persistent object types will be taken into account and a pre-fetching method may be implemented.