Interface to access image data from within and outside of the hospital

Once the data are stored in the image archive and are well identified, it is necessary that they can be accessed in a convenient way from within and outside of the hospital.

The DICOM is designed to be run in a secure department subnet and to be accessed only by few trusted peers. The security and authentication management services available in DICOM are limited and do not allow for user-role based approach typical for more advanced access policies. Also the Query Retrieve Service Class of DICOM is designed in a way, that the client (Application Entity Title) requesting the retrieval of the data has to be known to the DICOM server on which the data is stored. Thus in general it is not optimal to have DICOM client at every clinical workstation throughout the hospital querying and retrieving the images from the image archive of the corresponding PACS. A concept of some kind of proxy server of web server is usually used to access the data from outside of the department that provides the necessary security and shields the image archive from the rest of the world. A corresponding client is integrated into communicated peers, that accesses the proxy to actually retrieve and display the images at target clinical station.

There are several design options concerning the way in which the proxy element accesses the image archive:

• Database and proprietary access – the proxy mechanism can be proprietary for the individual image archive implementation and access directly the database and filesystem underlying the implementation. In many cases the proxy mechanism is incorporated into the image archive solution itself – some systems feature rich web clients to query and display data stored on them – in which case the tight integration is appropriate and very usual. But often this “database to database” interface is used also by separate systems or by systems proprietary written to extend the functionality of the image archive to support the proxy mechanism. The disadvantage of this approach is that with the change of the image archive implementation the whole mechanism has to change.

• DICOM access – the proxy mechanism can connect to the image archive using DICOM means. The DICOM supports some query mechanisms using DICOM Query/Retrieve Service Class which enables querying of stored DICOM objects, the actual data can be pulled from the DICOM server using the DICOM WADO (Web Access to DICOM objects) Service, which enables for retrieve of images stored in the archive via HTTP protocol. DICOM WADO supports a range of formats (in DICOM these are called Transfer Syntaxes) in which to acquire the images ranging from DICOM uncompressed files to standard JPEG files. The obvious advantage is that such proxy mechanism can easily be used on any DICOM server that further supports DICOM WADO. Therefore this solution is much more general, reusable and eventually allows for more coexistent PACS systems of the institution to be accessed in a uniform fashion.

The implemented proxy mechanism uses the DICOM access mechanism. The data pulled from the server in one of supported formats using this way are served to a specialized client using proprietary communication protocol. The proxy element in the process is represented by the application server inside the department that accesses the Image Archive using DICOM

patient documentation, for which a specialized module for communication and displaying radiology image documentation was written.

The advantage of using specialized encrypted protocol for transferring data into this client is that it can be easily used from within and outside of the hospital. Thus the same strategy can be used for accessing data from other affiliated hospitals that send their patients to target department for examination. This solution also enables for working-from-home mode of work for reporting physicians.

In case some specialized display capabilities are requested by the physician requesting the images, it is possible to download a zip-ball of target study in uncompressed DICOM which can be imported into any standard DICOM viewer that the physician is used to work with.

The one missing piece in the scenario is the access to the images via hospital intranet. The above mentioned solution based on the specialized client application for accessing and managing medical patient documentation covers most of the use cases; however enabling the intranet based access for the simplest way of access is still a task that needs to be solved to achieve complete integration. Very recently (beginning of December 2007) a new web-viewer extension to dcm4chee became available that could prove valuable enabling for image display via internet.

IHE makes use of the XDS (Cross-enterprise Data Sharing) and XDS-I (Cross-enterprise Data Sharing for Imaging) standards for image data sharing. Without doubt it is the most sophisticated way to share images and medical image related data, offering most complete feature set. The XDS is very complex standard understanding of which is another challenging task. Currently a new (and most likely the first and only) open-source XDS registry/repository making use of dcm4che platform was released by the MARiS project team ([MARIS]).

Further inquiries into XDS are in plan, however currently the developed approach is preferable – it integrates seamlessly with the rest of medical documentation, it is well established and is the simple way forward. The open source repository was only released as recently as 9.7.2007!

It is good to note that the service for enabling cross-enterprise sharing of medical images can also be purchased. Both source and target hospital need to connect into existing infrastructure provided by the service vendor – this usually requires a dedicated proxy node inside the PACS (such is the case with the biggest provider of such service in Czech – the ePACS project ([EPACS])). This way can be considered an alternative to offering a full fledged secure interface for foreign users. In current situation however this approach is rather disadvantageous – it does not allow for the complete eHR of the corresponding patient to be accessed (even though partial information could be added to the images using DICOM Structured Reporting). Other issues are the cost, possible further integration issues, dependency on the vendor of that service and ease of use – as some of the physicians viewing the images may not have a DICOM enabled full fledged clinical workstation at hand.