PDF
ePub
Citation
Print
I. Introduction
Health information exchange (HIE) [1] enables the exchange and interoperability of healthcare data or information by allowing the secure and integrated sharing of information among numerous stakeholders to improve healthcare quality and efficiency [2]. HIE facilitates the movement of clinical information between hospitals, laboratories, radiology centers, pharmacies, payers, public health departments, and other clinical providers. With the cross-organizational data exchange, clinicians can gather more information and thus provide better clinical diagnosis and treatment, which results in better patient care.
Among the various types of clinical information that are shared in HIE, we focused on the sharing of medical imaging documents. Imaging documents are generated by various technologies, such as computed tomography, positron emission tomography, magnetic resonance imaging, ultrasound, X-ray radiography, biomagnetic, laser surface scan, and nuclear medicine. A picture archiving and communication system (PACS) [3,4] provides the mechanism to digitize and store the images acquired from imaging equipment or modality, transmit the images over a network, and display the images for diagnosis or other medical use. PACS makes the use of radiology films obsolete and has been evolving over time to be the de facto medical imaging solution in hospitals and clinics. On the contrary, PACS implementation can vary among vendors. To provide a standard method especially in the transfer of medical images and the associated information over a network and across various PACS implementations, the National Electrical Manufacturers Association assembled a committee tasked with publishing Digital Imaging and Communication in Medicine (DICOM) standards [5,6]. A PACS implementation that is compliant with the DICOM specifications shall be interoperable with other DICOM-compliant PACS solutions developed by other vendors.
PACS enables the interconnection of medical imaging devices and applications via DICOM networking, a point-to-point network protocol that is based on TCP/IP. A PACS application is identified by an Application Entity (AE) title. It can communicate with another system in a DICOM network if the other party's AE title is also known and recognized as a legitimate peer. This requirement in practice constrains PACS use to the departmental level since imaging data cannot be easily shared with other departments without establishing an exclusive point-to-point communication channel. On the other hand, however, the data stored in the PACS archive are effectively insulated from public exposure and are thus protected from access by an unauthorized system. Taking into account the needs for imaging data sharing in HIE, the consequence is twofold. First, an intermediary is needed to mediate secure imaging data sharing between a PACS and an HIE. Secondly, it is desirable to base the mediation on existing standards or protocols so that a similar approach can be adopted in other similar environments, thus reducing the time to develop a tailored solution on a case-by-case basis.
This report introduces the cross-enterprise document sharing for imaging (XDS-I) gateways developed for the purpose of integrating legacy PACS solutions installed at the Gil Hospital and its affiliate branches with an HIE that is also being tested across the hospital network. Emphasis is placed on building the gateway mediation capability by utilizing the healthcare interoperability standard published by the Integrating Healthcare Enterprise (IHE) initiative.
II. Case Description
1. HIE Establishment at Gil Hospital
Gachon University Gil Hospital (henceforth, Gil Hospital) operates six affiliate hospitals and is connected with several clinics. A community HIE is projected to be developed that will enable health data sharing across Gil Hospital, the affiliate branches, and the clinics. Prior to rolling out a full-scale HIE, an early staging environment is created to test the functionalities of various HIE components. For the imaging document data sharing capability, three facilities are designated to participate in the testing: Gil Hospital and two affiliate branches identifiable as Dong-Incheon Gil Hospital and Namdong Gil Hospital.
Each participating facility has PACS infrastructure installed and operated on a day-to-day basis. The operation of the PACS is managed independently by each facility. When a patient is admitted to a facility for the first time, he/she should register his/her personal information. The patient credential is local, associated only with the facility where the registration occurs. This signifies that patient information can be different in other facilities. Every time a patient is examined at a facility, the imaging data acquired from the modality equipment will then be stored in the PACS archive storage installed in the respective facility. The mechanism for image data retrieval from the PACS storage can differ for each facility. A PACS solution in one facility, for example, provides image retrieval service via a non-DICOM standard interface and restricts DICOM Storage and Query/Retrieve services via DICOM networks. Therefore, it is important to address configurability and flexibility issues in the imaging gateway design so that it can be interfaced with a multitude of PACS solutions.
Network connectivity with the server applications of the PACS solutions installed in all facilities can only be established via a DICOM network interface. None of the PACS server applications provides an alternative interface, for example the web interface referred to as Web Access to DICOM Persistent Objects (WADO) has been specified in the DICOM standard. Having no alternative imaging data interface enforces heavyweight image retrieval by a display client since the image should be transported over the network in a DICOM file format. A binary in DICOM format can be large, on the order of megabytes, especially if it contains numerous image frames. This is problematic in the case of a slow network or when a preview of a multi-frame image is needed for display. Hence, it is also important for the imaging gateway to provide an interface that can be configured to be accessible from an external network, while ensuring the security of the image transfer and taking care of the performance aspect of the transferrable image payload.
Besides PACS, each participating facility also operates an order communication system (OCS). OCS is a computer application that is used to enter diagnostic and therapeutic patient care orders [7]. Like PACS, the OCS application is managed independently by each facility. This reflects the absence of information sharing between the OCS applications operated across the facilities. Interestingly, the Gil Hospital OCS was developed with additional functionalities that supplement the prescription input system. It can also handle orders for the medical image information system, remote service system, resource management system, and electronic medical card system [8]. It can be concluded that, in case of Gil Hospital, the OCS is the entry point to patient care and management continuum.
An order for medical image examination is initially recorded in the OCS. Subsequently, an examination will be performed using the respective medical equipment. The medical image will be stored by the PACS. Each medical image contains various types of metadata that are referenced to identify and describe the image. The PACS operator uses patient information provided by the OCS, including patient ID, patient name, patient gender, patient birthdate, and patient demographics, when embedding patient-related metadata into the image. Figure 1 shows a diagram of the staging environment for PACS-HIE connectivity. As shown in the picture, each of the affiliated hospitals operates PACS and OCS. In addition, Gil Hospital also manages a datacenter. All the facilities can be connected securely via a virtual private network (VPN).
2. Imaging Gateway Development
The imaging gateway has been developed as the imaging document sharing enabler in the Gil Hospital HIE infrastructure. On the HIE-facing facade of the gateway, it implements the document sharing for imaging workflow that is specified in IHE IT Infrastructure (IHE-ITI) and IHE Radiology Technical Frameworks (IHE-RAD TF) [9]. On the PACS-facing facade, several modules are developed to address the characteristics of PACS solutions operated in the environment while leaving enough flexibility to deploy the gateway in other types of setup.
1) Cross-enterprise document sharing for imaging workflow
Figure 2 illustrates the imaging document sharing workflow as specified in the IHE-RAD TF. As seen in the figure, imaging document sharing involves several participating components, which are also referred to as "actors". The imaging document source is a component that provides imaging documents to be shared into the HIE. The document repository is an actor that stores cross-enterprise documents ranging from text, hypertext, images, multimedia files, and so forth. The document registry maintains the metadata of the documents that have been stored in the document repository. A document consumer retrieves an XDS document from HIE to be shown on a display interface. Specific to imaging documents, the retrieval is handled by an imaging document consumer.
Based on the workflow in Figure 2, we implemented the gateway as follows. The imaging document source is the gateway that intermediates the legacy PACS with HIE. It is capable of providing and registering imaging documents to the document repository to be included in the shared document listings in the HIE. When providing and registering the images to the document repository, it utilizes the RAD-68 transaction specification of the IHE-RAD TF. In this transaction, images are grouped into sets and only image manifests or references are registered to the document repository instead of the original DICOM images. Image manifests are embedded as an attachment to a SOAP request and then sent via HTTP to a SOAP Web service endpoint of the document repository that is responsible for receiving XDS document registration. The SOAP request body contains additional metadata whose format is specified in the RAD-68 transaction. Metadata values are populated by the imaging document source based on the content of the image manifest.
After an image manifest file is provided and registered into the document repository, its metadata will then be registered to the document registry. The mechanism is explained in ITI-42 transaction of the IHE-ITI TF, which is used in tandem with IHE-RAD TF in the imaging document sharing workflow. A document that has been registered in the registry will be visible to the entire HIE; thus, it is retrievable across various organizations in the HIE. If a document consumer invokes an ITI-18 transaction request to the registry, it can recognize if a new document has been submitted to the HIE and obtain the repository address from which the document can be retrieved. Subsequently, by invoking an ITI-43 transaction, the document consumer can fetch the document from the repository. As images are shared in the HIE in the form of manifest files, the imaging consumer part of the document consumer should properly parse a manifest file and retrieve the original image file from an address provided by the imaging document source.
The gateway provides a WADO interface for image reretrieval. The WADO image retrieval mechanism is defined in RAD-55 transaction of the IHE-RAD TF. In this transaction, an imaging document consumer can obtain an image by accessing a certain HTTP URL. The consumer provides the necessary parameters, which at least include the study instance universal ID (UID), series instance UID, and object instance UID of the image, and appends these parameters to an HTTP GET query request. If the image can be found, a response is sent back to the consumer containing the requested image in DICOM or JPEG format. The consumer is responsible for extracting the image from the response and displays it on its interface according to its display mechanism.
The imaging document sharing workflow also enlists other mechanisms of image retrieval. The imaging gateway currently does not implement those mechanisms since XDS-I document retrieval via WADO suffices for the current setup. However, the gateway is designed to have sufficient flexibility to extend the image retrieval mechanisms it supports.
2) Imaging gateway modules
The imaging gateway application is built on top of Java Enterprise Edition 7. It is deployable as a binary in a Linux environment. The application is designed to be modular to ease future addition to its components and features. The following modules have been developed to compose the entire imaging gateway application:
(1) HIS interface module
This module manages the connectivity between the imaging gateway and the existing hospital information system. For the staging environment, the HIS application is represented with the OCS. The gateway publishes a RESTful Web service address that can be accessed by Gil Hospital OCS. The OCS initiates the imaging document sharing workflow by invoking an image sharing request to the web service address. The request contains patient information and additional metadata. Upon receiving this request, the gateway will perform some validation and then pass the request to the image sharing queue.
(2) Image acquisition and processing module
This module pulls an image sharing request from the queue and performs image acquisition and processing. The image acquisition method can vary, depending on the interface that is provided by the target PACS. The gateway is capable of switching between several acquisition methods that include standard DICOM Query/Retrieve and Store and non-standard ones, such as File Transfer Protocol (FTP) access. After an image is acquired by the gateway, some processing will take place. The processing includes creation of a snapshot JPEG image that represents a single/multi frame DICOM image and creation of a key object selection (KOS) manifest that will be later submitted to the document repository.
(3) Image retrieval module
This module manages WADO HTTP endpoints that can be accessed by an imaging document consumer to retrieve an image. Two endpoints are provided: non-secure HTTP and secure HTTP with Secure Socket Layer (SSL) channel encryption. By providing a secure WADO endpoint, the gateway minimizes the possibility of man-in-the-middle attack and ensures that imaging data is encrypted and securely transmitted over the network transport channel.
(4) HIE integration module
This module handles the interactions or transactions between the gateway and HIE. There are two primary types of transactions that are managed by this module. The first one is patient demographics queries (PDQ). This type of transaction is also referred to as ITI-21. In this transaction, the module requests the global patient ID that is used for the entire HIE and additional demographics data from the master patient index server. The master patient index keeps the map of local IDs and the corresponding global ID of a patient. It is capable of resolving a global patient ID given a local patient ID and vice versa. Local patient identification including a patient's demographic data is supplied by the OCS application in each facility by sending the proper HL7 Admit Discharge Transfer (ADT) message to the designated port of the master patient index server.
The demographics data received from the master patient index server is used in composing a RAD-68 request. Noticeably, the other transaction is provide-and-register-imaging-document-set transaction or RAD-68. The module periodically checks its index to find if there are image sets that have not been submitted to the document repository. If one or several image sets are found, the module will sequentially register all available sets to the document repository. Each set is associated with one KOS manifest file. This indicates that, for each registration of an image set, one KOS manifest file will be registered to the document repository.
3. PACS-HIE Connectivity Testing in the Gil Hospital's Staging Environment
As explained earlier, three facilities are designated in the staging environment. To test connectivity, each facility PACS was connected to one instance of the imaging gateway. This setup enables each gateway to operate independently. Additionally, having one gateway on each facility enables asymmetric imaging document sharing workflow initiation. Each facility can independently initiate the workflow from the entry system, which is represented by the OCS.
Sample patient data were used in the test. For every test patient in each facility, the OCS sends a request to the gateway to start the imaging document sharing workflow. After validating the request, the gateway handles the necessary logic to find patient identification in the HIE, processes images acquired from PACS, generates image manifest file, and registers the manifest file to Gil Hospital HIE for XDS. To view images that correspond to a patient, an XDS viewer has been developed and used. It is run from the browser, thus minimizing additional software installation at the client side. The viewer can properly parse the manifest file and display the images in a set in sequence.
Figure 3 shows three samples of image sets taken from computed tomography (CT), computed radiography (CR), and ultrasound (US) modalities. The image sets correspond to abdomen studies with 22 images, colon studies with 50 images, and thyroid gland studies with 6 images, respectively. Samples are chosen from available population sets to represent variations in image sizes. For all images in each set, equivalent JPEG image caches are generated from the acquired DICOM files. By generating cache files, the gateway can immediately provide a representative image requested by the viewer without conducting image preprocessing every time. As seen in the figure, the JPEG caches are significantly smaller in size compared to the original DICOM files, thus enabling the viewer to display images in a timely manner. For CT images, the average JPEG-DICOM ratio is 7.42%, the minimum ratio is 7.15%, and the maximum ratio is 7.62%. CR images have an average JPEG-DICOM ratio of 4.4% with a minimum ratio of 3.73% and a maximum ratio of 5.94%. Finally, US images correspond to an average JPEG-DICOM ratio of 12.07%, a minimum ratio of 4.84%, and a maximum ratio of 13.51%. These ratios are specific to the sample images used in the tests and can vary for different examination images across different modalities.
The DICOM image objects are loaded by the viewer by invoking WADO calls. An insecure WADO call is channeled through HTTP while a secure WADO call uses HTTPS as the transport protocol. Figure 4 shows the average loading time of test images in JPEG format when loaded from both WADO HTTP and WADO HTTPS addresses. As shown in Figure 3, the generated JPEG images converge to a certain size for each modality. The average loading time is then determined by aggregating the loading time measures of each image in HTTP and HTTPS to obtain the statistical average. As seen in Figure 4, some performance penalty is incurred when image objects are loaded securely from their WADO HTTPS addresses. This is expected since the image objects have to be encrypted at the gateway side prior to transmission over the network, and the decryption process should take place at the viewer side before the image objects are displayed to the user.
Another interesting finding in Figure 4 is the similarity of loading time for sample images in US and CT modalities despite the different average JPEG image sizes. The JPEG image samples from the US modality have an average size of 100.6 kB, a minimum size of 87.7 kB, a maximum size of 113 kB, and a standard deviation of 5.21. On the contrary, the JPEG image samples from the CT modality have an average size of 38.15 kB, a minimum size of 36.76 kB, a maximum size of 39.16 kB, and a standard deviation of 0.73. The size of a TCP packet underlying both HTTP and HTTPS protocols is normally at 64 kB. This implies that each US image is fragmented into two packets, whereas a CT image is transmitted as a single packet. Based on this implication, it can be argued that the transmission time did not differ significantly for one or two TCP packets in the network where the test was conducted. However, this argument cannot be generalized to other networks. Furthermore, it was also observed that when the number of packets grows significantly as exemplified by the CR images, the transmission time properly increases.
In the current approach, the XDS-I gateway offloads DICOM image processing tasks to the client side. A user action that changes the presentation of an image, such as changing image window level or zooming into an image, propels the DICOM image file download to the client side so that it can be processed by the viewer. Figure 5 shows the loading time measures for DICOM images with different sizes loaded by the viewer on Chrome31 and IE9 browsers that are installed on a Windows7 64-bit workstation with 3.2 GHz quad-core processor and 8 GB RAM. As seen in the figure, the browsers under test exhibited variations in performance. On average, Chrome was four times faster in each test when processing and loading the DICOM image file to be viewed by the user. Nonetheless, it is important to note that conducting image processing on the browser can be a suboptimal approach. For example, changing the window image level of a 16-bit channel DICOM image with a size of around 13 MB takes almost 6 seconds in Chrome31 and 23 seconds in IE9. Such loading time indicates degradation of serviceability that necessitates a revisit to the image processing approach. A different approach can be devised, such as hybrid client-server image processing. However, this is beyond the scope of this article.
III. Discussion
In the testing, we successfully share images stored in all facilities to the HIE and the shared images were retrieved by an XDS viewer. In the staging environment created for testing, the gateway was deployed in each facility. It is reasonable to question the feasibility of deploying only a single gateway for all facilities. From our perspective, this is feasible but not in all cases. A single gateway fits the deployment setup better if there is only one or an integrated input mechanism for the imaging data sharing request. For example, if a portal that coordinates all facilities exists, input can be given from the portal to the gateway. The gateway will then be responsible for discovering a patient from the list of PACS it mediates and completing the whole imaging document sharing workflow.
Valente et al. [10] proposed a RESTful image gateway that provides image retrieval capability from multiple backend PACS. In their approach, images can be retrieved at study level, series level, or instance level, depending on the service address that is called by the Web service client. This approach eliminates the single instance image retrieval disadvantage incurred by WADO retrieval. By offering the capability to retrieve images in bulk, an imaging document consumer may constitute a better strategy for image display. Despite the benefit, this approach may suffer from future interoperability issue since the service definitions are nonstandard. A more desirable route can be taken by implementing Supplement 161 of the DICOM specification, which outlines the mechanism for WADO retrieval via RESTful Web services.
Security is also an important aspect in the gateway implementation. We have addressed the security concern from the perspectives of node security, network security, and data security. The gateway application is hosted on an authenticated node. Communication between a node and PACS can occur only if each entity can recognize its counterpart as a legitimate peer. By mutually recognizing the peer, a node with obscure security is prevented from interacting with the system. To safeguard the gateway from network threats, the gateway node is placed in a private network. Access to this node from another facility is achievable via a VPN. Finally, data security is addressed by providing a Transmission Layer Security (TLS) channel for image data transmission that ensures end-to-end data encryption, thus preventing an eavesdropper from correctly interpreting the data while it is being transmitted over the network.
XML Download