Introduction

E-mail is one of the most important Internet services. Leading e-mail service providers report more than 100 million users each [1]. E-mail is platform independent, easy to use and serves an excellent interoperability. Therefore it is frequently used for communication in the medical community and most physicians have access to e-mail communication. In many cases e-mail communication is the only way to transfer digital data between hospitals without media exchange. In most institutions, e-mail traffic is checked to prevent the transport of malicious content into the internal networks.

If standard e-mail clients are used for the transfer of personalized patient information additional measures are needed to reassure data security and integrity. For the transmission of radiological images the data files can be added manually as attachments, followed by a PGP or S/MIME e-mail encryption with free software plug-ins [2]. However, the clinical use of such an encrypted e-mail solution is diminished by the poor integration into the image workflow. Additionally, many e-mail clients designed for “regular use” cannot properly handle large amounts of data as required for the transmission of DICOM studies.

The DICOM protocol is the de facto communication standard for the transfer of biomedical diagnostic and therapeutic information between modalities and information systems inside a hospital [3]. The DICOM Supplement 54 [4], published in 2002, and the registered DICOM MIME type allow the transfer of DICOM objects using standard e-mail transport mechanisms.

The combination of such e-mails with additional encryption according to the OpenPGP standard is referred as DICOM-e-mail in this article. The national German standard for teleradiology as defined by the German Radiology Society in 2004 is also based on this protocol [5–7]. DICOM-e-mail is a legacy free protocol and allows the secure exchange of DICOM images and other file based information using standard Internet connections and mailboxes.

To reassure ease of use and reliability and for integration into daily routine automated converters and workstation applications with the support of DICOM interfaces are needed. To date seven commercial and three Open Source products with the support of DICOM-e-mail are available [8].

Since 2002 the DICOM-e-mail protocol is in use in the Rhein-Neckar region in Germany. A growing number of hospitals and other institutions are part of the network [9–11]. To date over 60 institutions have integrated the DICOM-e-mail solution in their workflow.

The DICOM-e-mail teleradiology protocol is used in different applications:

  • Emergency consultations

  • Tele-guided examinations

  • Cooperative work

  • Expert consultations

  • Scientific cooperation

  • Image and report distribution

  • On-call services at home

The aim of this project was the integration of different teleradiology applications into the workflow of more than 60 partners. This article describes the analysis of the organisational and technical needs for the different types of teleradiology applications. It demonstrates the developed concepts for an integration of DICOM-e-mail based teleradiology services into the DICOM workflow inside a hospital.

It points out advantages and disadvantages of the DICOM-e-mail protocol based on the experiences of three years of use.

Materials and methods

Protocol

The DICOM-e-mail protocol is described in detail in [6]. In summary it is based on the exchange of standard e-mails with an additional encryption according to the OpenPGP standard [12, 13]. DICOM images are attached according to the DICOM Supplement 54 [4], while other attachments (text and graphic formats such as pdf, jpg, rtf, etc.) are allowed, as long as they represent a valid MIME-type. The built-in zip compression of the OpenPGP standard is used. E-mail exchange is performed over standard e-mail server protocols POP3, IMAP4 and SMTP.

Test equipment

For the performance tests the following data and installations were used: Test dataset CT head scan: 30 CT images 512 matrix, 2 scout images and a protocol image. The test workstation was equipped with Pentium 4 2.6 GHz, 512 MB RAM, internal transfers using fast Ethernet 100 MBit, GnuPG 1.4.2, Thunderbird 1.0.6, and WindowsXP Pro SP2.

Network

The DICOM-e-mail network in the Rhein-Neckar-Triangle consists of over 20 hospitals including four “level one” trauma centres and 17 district and city hospitals [9]. It also includes over 40 other neighboured partners such as private practice radiologists, offices for quality assurance and homework installations for radiologists in three German states. The DICOM-e-mail network is currently being extended into the state of Baden-Württemberg, where more than 50 hospitals will be included in 2006.

Project group

The discussion of the technical and organisational needs was based on a previous survey [14, 15]. The necessary updates and details were discussed and fixed within the project group, which consisted of the central project leader and 12 local project leaders together with a number of physicians from the participating hospitals.

Teleradiology applications

Different teleradiology applications were needed within the network; they cover most of the possible applications including [16, 17]:

  1. 1.

    Emergency consultations (neurosurgery, neurology, neuroradiology, heart surgery, orthopaedic surgery)

  2. 2.

    Tele-guided examinations (without a radiologist at the location of examination)

  3. 3.

    Expert consultations (oncologic surgery, abdominal surgery)

  4. 4.

    On-call services at home for radiologists

  5. 5.

    Cooperative work (for example, cardiology and heart surgery in different hospitals, exchange of image data between hospitals and private practice radiologists, exchange of data for quality assurance measures)

  6. 6.

    Scientific cooperation between university hospitals, universities and research centers

  7. 7.

    Image and report distribution

  8. 8.

    Integration of images and reports into an electronic patient record (EPR)

  9. 9.

    Demonstration of image data and online-conferences

  10. 10.

    External archiving services

Results

The data presented is a result of the use of the described technology in the Rhein-Neckar region in southwest Germany.

Technical and organisational needs

The project group defined the six main applications required in the network and analysed them for their technical and organisational needs.

The topics were the availability and stability of the teleradiology systems, the needed speed of transfer for a complete examination, the need of a detailed workflow definition between all partners for that specific application and the level of data security needed for these applications (Table 1).

Table 1 Relevance of parameters (needs, requirements) for different teleradiology applications: +++ (very important), ++ (important), + (less important)
Full size table

For emergency consultations availability and speed of transfer are the crucial points. Since there are a lot of ad hoc transfers with direct personal communication between the partners the workflow definition often is of minor interest.

For tele-guided examinations availability and speed of transfer are of high importance. Workflow definitions are essential to reassure the quality of the examinations, where no radiologist is present at the location of the examination.

For homework the availability was regarded as partially less important because of the possibility of returning to the hospital in case of a failure of the teleradiology connection.

The data security was regarded as very important for all applications with the use of personalized patient data. It was regarded as “less important” for scientific cooperation because only anonymized or pseudonymized data is used for these transfers of image data. Some consultations of experts is also done with anonymized or pseudonymized patient data.

Local integration of teleradiology services

The communication partners represented a wide range of different infrastructures (no PACS, PACS from various different vendors, DICOM workstations from different vendors). All CT scanners and MR scanners were DICOM compatible. Three different types of integration of DICOM-e-mail based teleradiology services were used for these institutions:

  • Standalone teleradiology workstation or DICOM workstation with integrated teleradiology functionality

  • Server based teleradiology gateway

  • Upgrade of an existing DICOM workstation with a DICOM-e-mail converter service

Standalone teleradiology workstation

The easiest way to connect to the DICOM-e-mail teleradiology network for partners without an existing PACS and without a DICOM workstation is a dedicated workstation with built-in support for the DICOM-e-mail protocol (Fig. 1). Such a workstation can be addressed by any DICOM modality and allows the viewing and reporting of the received images. For data delivery, the studies or images of interest can be selected, text information can be entered and additional data such as JPG images or PDF files can be attached to the DICOM images. The whole dataset will be converted to encrypted E-mails and sent to the corresponding partner. The teleradiology images received are displayed in the normal patient list, related information such as JPG or PDF files can be viewed together with other patient data.

Fig. 1
figure 1

Integration of a DICOM-e-mail teleradiology workstation

Full size image

This type of teleradiology integration usually requires an additional manual user interaction for sending images over the teleradiology network (manual selection of the images and of the corresponding partner).

The reception of images is usually done automatically by the workstation: polling the mail server, decryption of data, checking of signatures, detachment of attachments, storing of original DICOM data in the local database and perhaps auto routing to another DICOM target. Some vendors offer integrated auto routers which send incoming DICOM data automatically to another site depending on certain rules, such as DICOM port, AET, day of the week or even time of day.

Server based teleradiology gateway

Integration of the DICOM-e-mail solution into a DICOM workflow with or without a PACS can be seamless using an automatic DICOM-e-mail gateway (Fig. 2). This gateway is addressed like any other DICOM device with DICOM send. Unfortunately the DICOM protocol does not include a forwarding procedure, any DICOM device is regarded as an endpoint. A DICOM network device is defined by three parameters: network port, network IP-address and Called Application Entity Title (AET). One solution to enable forwarding of DICOM images over the gateway from any standard DICOM device is to use the CalledAET to define the final destination of sent images. The DICOM receiver of the gateway is listening to a specific port and IP-address and will interpret the CalledAET given by the sending DICOM device. For each communication partner a different CalledAET will be used. Inside the gateway the relationships between these AETs and the corresponding e-mail addresses and public keys needs to be defined. This can be done with a local lookup table or using a LDAP server. Then all DICOM images received by this gateway for a certain AET will be automatically converted into mail attachments, encrypted with the corresponding public key and sent to the corresponding mail address. This method enables an automatic DICOM to DICOM-e-mail gateway for sending images out of the hospital without manual interaction and can be used for an unlimited number of partners.

Fig. 2
figure 2

Integration of a DICOM-e-mail gateway into the internal DICOM workflow shown in the ‘send’ direction. The ‘receive’ direction is identical to the process in Fig. 1

Full size image

Receiving DICOM-e-mails is similar. The teleradiology gateway can be configured for different users with their own mailboxes and private keys, e.g. neurosurgery, radiology and neurology. The gateway will periodically check all mailboxes and fetch all mail. The DICOM-e-mails are decrypted automatically (with the private keys stored in the local key ring) and the DICOM objects are routed to a user specific workstation, the PACS or both. Any other attachments such as JPG or PDF files can be forwarded to an in-house mail server as unencrypted mail. Commercial gateways also allow the integration of these non-DICOM attachments into the DICOM workflow using a web server. DICOM images and non-DICOM attachments are joined with these solutions, as long as they are encoded using the X-tags according to the German national DICOM-e-mail standard [5, 6].

Therefore, integration of the DICOM-e-mail protocol using an automatic gateway is possible as long as the modalities, workstations and the PACS support the standard DICOM protocol. Usually no additional manual interaction is needed. Complete software solutions with this functionality are available as Open Source as well as commercial implementations [8, 18, 19].

Upgrade of an existing DICOM workstation with a DICOM-e-mail converter service

Virtually any existing DICOM workstation can be used for DICOM-e-mail if the basic DICOM to DICOM-e-mail converter software is installed on the same computer (if allowed by the vendor of that workstation). Since converter software is available for all major operating systems and communication between the converter software and the DICOM workstation software is based on internal TCP/IP communication this solution should work with any available DICOM workstation. To receive DICOM-e-mails the converter software will check the mailboxes periodically, poll the e-mails, decrypt them and send them via DICOM to the workstation software over the internal TCP/IP connection.

To send DICOM-e-mails the required partner information (e-mail addresses, GPG key ID, CalledAET) has to be configured in the converter software and their public keys have to be imported. The converter software will start a DICOM receive service for the communication with the workstation software. For each partner a DICOM entry is then added in the workstation software. Now images can be sent to each teleradiology partner using the same workflow of the workstation software used for in-house DICOM transfers.

Security concept

Public key infrastructure

The secret keys are not linked to a person but to specific computer hardware. Within the network all GnuPG key pairs are generated by the local system administrators or by the field engineers of the software vendors. The secret keys are stored locally, the public keys are forwarded to all partners in the network.

Mail server communication

Even though all transferred e-mails are encrypted an additional line encryption is used for the communication between the e-mail-clients and the mail servers; therefore, the encrypted variants of the mail protocols, POP3/S, IMAP4/S and SMTP/S are used. In addition the SMTP authentication according to RFC 2554 is used [20] and the mail relay is deactivated for two of the three central mail servers used for emergency teleradiology. Therefore only users with an account on the same mail server are able to send e-mails to the other partners. These two mail servers block Internet e-mail from general e-mail accounts. Every partner in the network can be reached by Internet mail over the third mail server.

Fall-back strategies

Each teleradiology client has e-mail accounts on all three central mail servers to receive images. These three mailboxes are all checked periodically. The content of these mailboxes is not synchronized between the mail servers; the mail servers are running independently. In case of a malfunction of one of the mail servers a sending teleradiology client can therefore switch to the mailbox of another mail server to reach the recipient. Some of the commercial clients allow the assignment of multiple mailboxes to a recipient and this switching between the three mailboxes is done automatically without user interaction. In the Open Source solutions a repeated manual sending of the images to the other mail server is needed, if a transfer to one mail server failed. One of the central mail servers does provide a dial-in router for ISDN lines in addition to its Internet connections. This is used by some clients for a fallback in case of a failure of the local Internet line. The teleradiology client also manages this fallback between Internet line and ISDN dial-in automatically without user interaction.

Local handling of e-mails

In the four major hospitals the DICOM-e-mail gateways were equipped with antivirus software to check all attachments. Due to the encrypted content the central standard mail gateways from the university hospitals are not able to do this check during the forwarding process.

Measures for availability

All partners use at least two mailboxes on different mail servers. The emergency accounts of the major hospitals use three different mailboxes, which are polled automatically. The clients and gateways within the hospitals always pull all mail accounts; therefore, the failure of a single mail server can be overcome using another mail server to send the images. There is no duplication of mail between the mail servers.

Speed of transfer

To define the needed bandwidth for the applications mentioned the process of sending images with the DICOM-e-mail protocol was analyzed (Table 2).

Table 2 Analysis of the transfer process using the DICOM-e-mail-protocol; dataset and workstation as described in the Materials and Methods section. One image per email was used
Full size table

The image files received are stored on the workstation as DICOM objects and converted into e-mail attachments. This conversion increases the size by 15% due to the limited character set used within e-mails. During the encryption process the built-in zip compression decreases the size of the files, the resulting size of the dataset is about 24% lower than the original size. These values differ depending on the image content.

Transmission mode

The DICOM-e-mail protocol allows single or multiple attachments. Thus, some of the available clients sent the DICOM test study as a single e-mail with 33 attachments while other clients generated 33 separate e-mails with single attachments. This results in a different transfer process (Fig. 3).

Fig. 3
figure 3

Blockwise vs. interleaved DICOM-e-mail protocol. Left: block-wise transport, waiting for end of DICOM association, single e-mail with 33 attachments. Right: interleaved transport, processing of each DICOM file after storage, 33 e-mails with single attachments

Full size image

The slowest process, the e-mail sending process, dominates the total speed of transfer. The interleaved transport is about 10% faster and the first image is viewable after less than 10 seconds, compared to 2 minutes when using the blockwise protocol.

Running the converter software on current hardware, the encryption and decryption processes for large datasets are about 50 times faster than the send process for this dataset using the standard connection speed for a peripheral hospital with ADSL lines (256 kBit). Even with 2 MBit SDSL lines the encryption and decryption processes cause no relevant delay. Therefore the selection of the hardware for DICOM-e-mail converters is not critical.

Line types

Analysis of the regional communication partners according to their needs for teleradiology communications (as defined by the six different applications) led to four different groups of partners (Table 3). To define the appropriate connection type the communication needs must be separated into upload and download directions. The affordable ADSL connections are restricted to very limited upload speeds (128 kBit for the standard connection). Due to the fast download speed they can be used for homework (like radiologists on call at home), and even for urgent examinations. Partners with frequent and urgent uploads (like peripheral hospitals with a need for neurosurgical and neurological expert consultations and in-house CT scanners) are forced to use ADSL lines with boosted upload rates (up to 384 kBit) or switch to SDSL or cable connections. For major hospitals (e.g. the four “level one” trauma centres in the region) which do provide expert services for the peripheral hospitals and use the Internet for teleradiology services for their consultants on call, a cable connection with large upload and download bandwidth to the teleradiology mail servers and the in-house clients is needed and fallback strategies are recommended.

Table 3 Recommended line types for the different communication partners in the regional network. For private practice radiologists using the teleradiology system for image and report distribution to their clinical partners the upload rate is frequent; otherwise, the use of the system is rare for both directions for these partners
Full size table

Discussion

Teleradiology applications

The vast majority of the teleradiology applications (eight out of the nine teleradiology applications mentioned in the Materials and methods section) are realized in the teleradiology project in the Rhein-Neckar region using the DICOM-e-mail teleradiology protocol. To support all applications and reach all partners in the network only one outgoing connection to the central mail servers is needed. No incoming connections and no open ports at the hospital firewalls are needed. This protocol proved to be fast, reliable and secure.

The missing application “demonstration of image data and online-conferences”, e.g. using screen synchronisation or mouse pointer synchronisation is not possible using this protocol due to its asynchronous setup. Since only a very limited number of partners demanded this functionality it was subsequently incorporated with vendor dependent protocols and was therefore available only to the users of this software in the network. This functionality requires a direct connection of the two partners; additional changes in the corresponding hospital firewalls are necessary with IP ports open to the Internet or the setup of a virtual private network VPN.

There are also platform and vendor independent protocols available for basic screen synchronisation (like Virtual Network Computing VNC, http://www.realvnc.com), but they also need the setup of a direct connection between the synchronised partners.

The asynchronous setup is a distinct advantage in the communication between partners such as private practice physicians because sending images to a partner is still possible even with a disconnected or turned off receiver system (many computer systems in private practice are turned off regularly during evenings or weekends). Therefore images and reports distributed to a private practice physician can be collected by his DICOM-e-mail client during the time it is able to connect to the mail server.

Local integration of teleradiology services

The integration into almost any DICOM based environment is possible using the commercial or Open Source DICOM-e-mail solutions. Gateways allow a flexible and customized image and information distribution of the received data within the local network. Currently seven companies do provide DICOM workstations or gateways with built-in support of the DICOM-e-mail protocol as described in this article, the latest list of vendors can be viewed online [8]. Since a viewing station for medical images needs to follow the European laws about medical products [21] an Open Source package for a DICOM viewing station with DICOM-e-mail support cannot be offered by the developers. Nevertheless the combination of available Open Source DICOM viewers and the Open Source converter software is possible by the user, e.g. a local system administrator in a hospital.

Additional partners and services

Due to the single-point network access the integration of additional partners is simple and the setup of one gateway allows the connection to each partner. Therefore duties like the routine transfer of images to the state Medical Offices for Quality Assurance can be switched to filmless and medialess data transfers with minimal effort. This is already working for the state of Hessen and is in progress for the state Baden-Württemberg in Germany. It can help to reduce costs of labour in the hospitals and offices. The integration into routine system checks and maintenance procedures is also possible.

The connection to other teleradiology-networks with different techniques can also be achieved by using a single gateway. This was realized to connect a VPN based network with six district hospitals and one university hospital to the existing DICOM-e-mail network. A single DICOM-e-mail to DICOM gateway in the university hospital was able to route the traffic between the DICOM-e-mail partners and the hospitals within the VPN network in both directions. No additional software was needed inside the VPN network to allow point to point data transfer between all partners in both networks.

The protocol allows the secure transfer of all file types. Therefore it can be used to connect to other telemedicine projects such as electronic patient records or to deliver other medical data between partners without the setup of additional software or gateways.

Security concept

Since the communication does make use of standard Internet connections there are some potential security problems:

  1. 1.

    Receiving unwanted mail (spam mail)

  2. 2.

    Receiving malicious content (virus mail, Trojans)

  3. 3.

    Eavesdropping of mail

  4. 4.

    Denial of Service DoS attacks to the public mail servers

If all mentioned measures of security are combined (content encryption, SSL protocols only, user authentication, dedicated mail servers, no mail received over relays), then the level of security is comparable to a Virtual private network. In such a closed network the security problems 1, 2 and 3 are very unlikely. To reassure the availability of the mail servers (and prevent security problem 4) the mail servers are protected by firewalls, and a professional server support company handles updates and patches.

Some partners of the teleradiology project in the Rhein-Neckar region were not able to connect directly to the mail servers using the SMTP/S and IMAP/S protocols. Their security guidelines or their Internet service providers only allowed access to their own SMTP gateways. The integration of these partners was achieved by accepting mail relays in one of the three central mail servers. Since this mail server accepts any mail sent to the correct address by standard Internet mail servers, spam and virus mail is possible. All clients in use would ignore spam or virus mail since the clients automatically process only encrypted content. Nevertheless we did not register a single incorrect e-mail in 2 years of use with more than 20 partners. This may be due to the fact that the e-mail addresses are not available to the public, they are exchanged from person to person or via the project administrators. All available clients do not execute any e-mail content; therefore, Trojans and viruses are unlikely to be harmful in this environment.

Sources of errors

During the last three years with more than 1,000,000 e-mails transferred different errors were encountered. In the initial phase, human errors (e.g. wrong use of the software, selection of wrong partner entries, switching off parts of the teleradiology systems by accident) dominated over technical errors (hardware or software failure such as power supply crashes, crashing client software or system processes due to corrupt mails). The human errors can be lowered substantially by an integration of the teleradiology solution into daily routine workflow. Therefore the optimal solution is a PACS or PACS-workstation with built-in teleradiology functionality. Such installations can be used for the daily routine work of the radiologist and teleradiology as well.

Written workflow definitions available at the workstation and regular on-site training are also needed to reduce human errors.

Emergency teleradiology

If the DICOM-e-mail protocol is used for emergency teleradiology some general aspects need to be taken into account. The technical equipment should be upgraded to failsafe versions. The bandwidth of the Internet connections should be at least 256 kBit (if solely used for teleradiology) or higher (if used concurrently or if radiological examinations with many images are frequently transferred). Using affordable high-bandwidth Internet lines with 2 MBit the majority of transmissions are completed in less than one minute; therefore, lossy compression [22, 23] or the selection of key images [24] is not needed.

An interleaved transmission process with single attachments should be used to reassure the visibility of the first images as soon as they are received and before the transmission process for the whole examination is completed. The interleaved transmission process uses one attachment per e-mail only.

The workflow should be simple and solutions with integration into the daily routine workflow are preferred. The availability of clients and servers should be monitored continuously to prevent malfunctions prospectively.

One disadvantage of the DICOM-e-mail protocol is the approximately 20% lower transmission speed due to the 7 bit e-mail-conversion compared to direct DICOM connections. Nevertheless the bandwidth can be upgraded more easily compared to other solutions and the resulting speed of inexpensive ADSL lines is much higher compared to affordable dial-up lines.

Conclusion

The DICOM-e-mail protocol is a flexible and powerful protocol that can be used for a variety of teleradiology applications. It can meet the conditions for emergency applications but is limited if synchronous applications like teleconferences are needed. The presented concepts allow the integration of this protocol into various environments. Its use is cost effective, setup is simple and a wide range of software applications compatible to the standard is available, including Open Source solutions.