It can be challenging for unaffiliated hospitals to share diagnostic images when they reside in different storage archives. A DICOM relay system to make queries and retrievals of images in PACS using cloud services easy and transparent has been developed and successfully tested.
A research team at the Universidade de Aveiro has described its DICOM bridge and router in an article published online on 9 August in the International Journal of Computer Assisted Radiology and Surgery. The DICOM-compliant bridge works transparently with cloud service providers and can be integrated with any PACS-DICOM infrastructure. It does not require complex network setups or dedicated communication channels, according to doctoral candidate and lead author Luís A. Bastião Silva and colleagues.
Luís A. Bastião Silva from Aveiro.Interinstitutional usage of the DICOM standard is mainly supported by virtual private network (VPN) connections. DICOM-Part 18 (WADO: Web Access to DICOM Persistent Objects) is Web 2.0-compliant, allowing image retrieval over the Internet, but storage and search functions are unsupported, according to the authors. Use of commercial cloud services is proliferating, but some healthcare institutions are concerned they do not provide rigorous enough security.
The as-yet-unnamed DICOM bridge runs on top of cloud services and follows the Web 2.0 paradigm that services are available anywhere and anytime through HTTP connections. The developers have developed a middleware to cloud storage and notification systems with a plug-in based mechanism that provides a transparent interface to cloud providers.
Architecture
The system includes a DICOM cloud router and a DICOM bridge router. The router has the main responsibility of handling DICOM services and forwarding messages to the correct place. It has the ability to support as many devices as are online in a WAN DICOM network. It uses HTTP or HTTPS communication from inside an institution to the outside, and does not require opening any additional firewall service.
The DICOM bridge router works as a relay mechanism between different DICOM cloud routers dispersed over several locations. It stores the session key used to cipher DICOM messages of an association. It stores information about all devices and corresponding services supporter, and contains accounts from routers and a list of cloud provider credentials. It is the main component of the architecture because it manages the relay service, storing only a reduced amount of information during the data flow.
The bridge router can be deployed in several places. These include a private server or cloud used by a medical institution or a public cloud provider.
Using the system
To provide DICOM services for two or more private networks, the password-protected account of each participating router needs to be authenticated by the DICOM bridge. It will load a list of internal DICOM services to share with the WAN, load available services from other private networks, start DICOM services, and sign on to a designated cloud association channel. The bridge will notify routers at other hospitals or hospital enterprise locations to activate and await requests for information.
When an image residing in one healthcare institution's archive is requested, it can be retrieved and transmitted to another medical institution. External cloud providers are used to store information in transit, reducing the bridge overload. The bridge references the image to the external cloud location, at which point the remote recipient router takes the images and sends them to the remote archive, which will send a response upon completed receipt.
Testing the performance
The team tested the performance with two different geographically separate networks with 24 Mbps bandwidth availability. They placed a router at one location, a PACS server archive at another location, and used several third-party client workstations to test the cloud relay service.
Through experiments, the research team compared performance with that of using a VPN. It was apparent that having a robust Internet connection for each party was necessary to achieve good performance. Performance time was slower than desired. The routing process needs more optimization.
The team did not address the problem of different patient identifiers that presumably will be encountered by unrelated healthcare institutions retrieving images from each other. They said this could be resolved with use of a patient identifier cross referencing (PIX) standard or another conversion mechanism.
The key benefit is supporting standard interoperability between remote medical imaging devices. The other benefit is that there is no complexity to set up DICOM cloud router software when an institution wants to share its PACS server. The system is secure because only validated routers over the bridge will be able to exchange DICOM services. Finally, the required infrastructure is not excessive because it supports its main resources on the cloud.
Silva has advised that the development team entered an agreement with BMD Software for the company to commercialize the product. He said the commercialized system is in use at one hospital enterprise with a regional PACS serving two imaging centers located 35 kilometers apart. The archive is hosted in a private cloud infrastructure and the DICOM cloud router supports storage, query, and retrieval functions from radiologists.
