Background

Emergency services in Germany are challenged by heterogeneous equipment in different regions. These regions consist of both large metropolitan cities, and rural areas. After accidents with severely injured persons in rural areas, patients often have to be transported for a period of time, while the risk of dying increases every minute. Therefore, it is important to reduce transport times. To accomplish this target, special structures for emergency medical services are founded or planned across the world, for example in Australia [1], in New Zealand [2], in the Netherlands [3], in the United Kingdom [4] or the USA [5]. Most of these networks are created to improve communication between the emergency service and the hospitals as well as between two hospitals. To achieve this goal, regional trauma networks have been founded in Germany [6–10]. Within these networks, hospitals are graded into three categories: Local trauma centers (level 3), regional trauma centers (level 2) and supra-regional trauma centers (level 1). With regular meetings and workshops, standardized workflows and mechanisms for faster patient transfers, these networks try to speed up the care of severely traumatized patients. Additionally, the networks in Germany are required to establish a digital workflow to exchange radiological images in cases of patient transfers between the participating hospitals.

One trauma networks is the TraumaNetwork NorthWest (TNNW) located in North-West Germany. It currently consists of 27 hospitals located in Lower Saxony, Northrhine-Westphalia and the Netherlands. Besides optimization of the rescue chain, the networks founded a national register for trauma cases to improve the evaluation and benchmarking of trauma care. To optimize the data flow in the rescue chain within in the TNNW, two software systems were developed. The H.E.L.P. (Hospital Emergency Location Phone) is a special smart phone application to support the emergency physician at the accident site.[11, 12] H.E.L.P. displays the distances to the next hospitals, the trauma care level of the hospital and signalizes if a hospital is currently not able to take care of a patient. Furthermore, it allows the emergency physician to call the physician on duty within the clinic directly.

The second application Med ical S ecure I mage E x change (MedSix) is capable of transferring radiological image data from one hospital to another in cases where a secondary transfer of the patient is required. After creating a case and selecting a target hospital, the physician is able to upload DICOM objects either from a compact disc or imported from the PACS (Pictures Archiving and Computing System) of the clinic.

Up until now, there are only a few studies dealing with the evaluation of the IT-support in the rescue chain with the focus on image transfer. Nerlich et al. examined in 2000 the feasibility of DICOM transfer via ISDN and showed that DICOM transfers are able to save money [13]. In 2005, Kämmerer et al. showed that a simple ISDN-connection with 128kbit/s is enough for transferring cranial images within a reasonable time [14]. Chakera evaluated the use of DICOM image transfer for second opinions and hat connection bandwidths between 10 and 100 Mbit/s [15].

Objectives

Our objectives were

  • To establish an electronic transfer of radiological images (DICOM) between hospitals with heterogeneous software and hardware equipment,

  • To examine the speed and volume of typical transfers,

  • To analyze how the transfer volume could be decreased by different compression algorithms,

  • To evaluate the overall transfer flow between the hospitals, especially to analyze transfer frequencies and communications structures.

Methods

Image transfer system

To support hospitals in exchange, a web-based application called “MedSix”, which transmits radiological images over the internet independent of a patient’s transport, was developed. [16, 17] In contrast to direct connections between two PACS over a VPN connection, the data transfer for MedSix is completely web-based. Therefore, no firewall or proxy system has to be altered locally at the hospitals. Only HTTPs-connections to the MedSix-Server must be allowed. This setting is quite typical for a standard workstation in clinical environments. Proxy systems between workstations and the internet do affect MedSix. Furthermore, MedSix works with every operating system where a major web browser (e.g. Internet Explorer, Google Chrome, Mozilla Firefox, Safari, etc.) and a Java Virtual Machine for executing Java Applets are present.

After login, the system presents a list of currently active transfers. (Figure 1) Creating new transfers is simply done by entering information like the patient name, a callback phone number, a note and a receiving hospital.

Fig. 1
figure 1

The upload screen of MedSix. On the left hand side the patients are presented. On the right hand side the upload applet is shown. A configuration with a connection to the local PACS system is demonstrated. The user is able to search for the patient’s name and birth date. Filtering by acquisition date is possible

Full size image

It is possible to create a short time account valid for 24 h to transfer image material from hospitals or physicians not connected to the trauma network. An owner of a short time account is only able to send images to the hospital s/he is invited by.

The upload process itself is done with a simple Java applet. Besides the import of DICOM-CDs and DICOM-data from the hard disk, the applet is capable of retrieving data directly from a configured PACS system. The user is able to search for the patient’s name and birth date. The search can be limited to a specific time range.

The system is centralized. Images are captured from local PACS systems and uploaded by the Java applet to the MedSix-Server (Fig. 2). After that, the download is done by a specialized applet. The data can be directly transferred to a local PACS system. Firewalls and proxy systems do not affect MedSix as long as they do not interfere with HTTPs-connections.

Fig. 2
figure 2

Data flow of MedSix. Hospital networks are connected to the internet with firewall systems. The data is uploaded on the sender’s side to the MedSix server and then downloaded to the receiving hospital

Full size image

Data collection and analysis

Audit trail data between January 1st and December 31st of 2012 was analyzed for this evaluation. To archive actions done by users, we implemented a combined audit-trail for MedSix and H.E.L.P. The data of the audit-trail is saved in a MySQL5-table as structured text with its timestamp and the ID of the user who triggered the action. The log was parsed by a PHP5-script with the help of regular expressions. The results were written to a different MySQL5-database for diagram generation. Different transfer-parameters like sending and receiving clinic and image details like original and compressed size, hash of the file and transfer time were extracted. While parsing, no patient-related data was copied to the second database. Thus, the data used for the analysis was completely anonymized.

After July 1, we added the volume size and compression rate of the images transferred to the audit log to improve the evaluation.

A transfer consists of a series of images uploaded within 15 min. If the user waits more than 15 min between when the upload of the first dataset is done and when the next dataset is started, the new one is counted as new transfer.

Compression

The DICOM images could be compressed to improve bandwidth usage and transfer speed. Different algorithms were compared on compressing DICOM test data provided by the dicomtk project [18]. The test data provided by the project had a total size of 2,3GB. These images consist of a mix of conventional, CT, MR and sonographic images. The test images were copied to a ramdisk created by ramfs under Linux, the output file was written to this ramdisk as well to exclude possible delays created by hard drives. The UNIX-tool ‘time’ measured the time used by the compression; the user time was taken as reference providing the information about how much CPU time a process took. The computer used had an Intel Core i5-2400 CPU with 12GB memory and a standard harddisk attached. A simple tar without compression was used as reference. The compared algorithms were tar with bzip2 (version 1.0.6), tar with gzip (version 1.5), zip with all DICOM data in one archive (version 3.0), rar with all DICOM data in one archive (version 4.20) and ZIP with one archive for each DICOM file. The time used was calculated as an average value with three runs.

In MedSix, the images are finally compressed by using a simple lossless ZIP-compression. ZIP is originally based on Deflate, a freely available lossless compression algorithm [19]. Therefore, the data can be opened without any external software on windows systems; free software for other operating systems is available.

The compression for the upload takes place on the workstation which uploads the data. The upload applet compresses every image before transferring. The server unpacks the images to store them for 72 h. When the receiving clinic requests the data, the server compresses it again. To limit the number of HTTP-connections, the server compresses all images of a study to one archive. The download applet unpacks it on the workstation in order to transfer the images to the clinic PACS afterwards. The archive can also be downloaded manually if the images should only be viewed on one workstation and should not be archived in the PACS.

Results

Physicians of 12 hospitals participating in the trauma network used the system to send or receive image data for 87 transfers. The short time account feature was used 14 times in 2012 and therefore for 16 % of the transfers.

Image transfer characteristics

110,879 lines with audit events for H.E.L.P. and MedSix were collected and evaluated in 2012. In this year, 87 patient cases were created and 23,778 images transferred. On average, each case had 273 images with a median of 129. For some patients, only one image was transferred, the maximum number was 3,894.

The results show that 35.6 % of the transfers contain between 1 and 200 images and less than a fifth, 18.4 %, had more than 500 images (Fig. 3).

Fig. 3
figure 3

Number of transferred images per patient. 31 patients had 200 or less images, only for five patients more than 1000 images were transferred

Full size image

We analyzed the size of the images between August 1st 2012 and December 31st 2012 and found out that 72 % of the images had a size between 500 and 550 kB. This is typical for images made by CTs. On average they were 632 kB, with a median of 518.8 kB. 57.9 % of the transfers are below 100 MB and 81.6 % are below 200 MB. Only 5 % need more than 500 MB space. (Fig. 4) The biggest transfer had a size of 524 MB.

Fig. 4
figure 4

Data transfer volume per patient. 22 patients required 100 MB or less, 9 between 100 and 200 MB. Only 2 needed a data volume more than 500 MB

Full size image

The transfer times per hospital (Fig. 5) seems to be independent from the bandwidth of the hospital’s connection. On average, the images were transferred with 270kB per second with a median of 268kB/s.

Fig. 5
figure 5

Some hospitals shared a large variation of between approximately 10 kB/s and 5000 kB/s (for example hospital 6) while other had more stable transfer speeds. The transfer speeds of the short accounts represent different participants. Short time accounts were issued to different hospitals, therefore these data represent a mixture of sites with different connections

Full size image

The time needed per transfer (Fig. 6) is on average 1,164 s (19.4 min). The median time used by a transfer is 157 s, about 3 min. More than 87 % of the transfers needed less than 15 min to be complete.

Fig. 6
figure 6

Time needed per transfer process from first to last image. Only few transfers needed more than 1000 s

Full size image

Compression efforts

Different lossless algorithms were compared on test data to choose the best. As shown in Table 1, Tar created an archive with a compression ratio of 1 due to the fact that no compression was used, it used 0.07 s to compress the images with a size of 2.28GB. Tar, in combination with bzip2, created the best compression ratio with 0.38, slightly ahead of rar with a ratio of 0.40. Both algorithms used the longest time, 286.7 and 285.8 s. Tar with gzip and zip used resulted in nearly the same ratio of 50.3 % with runtimes of 119.4 and 129.3 s. Creating one archive per DICOM file increased the compression ratio slightly to 50.4 % and the runtime to 130.74 s.

Table 1 Comparison between the different lossless compression algorithms. The original size of the images was 2.28GB. Tar was used as reference; it created an archive without any compression (100 % of the original size) in under 1 s. Tar.gz and zip created nearly the same results because the underlying algorithm is very similar. There is only a small difference between one zip-archive for all DICOM data and the compression into a single zip-archive for every file. Better algorithms like tar.bz2 and rar create smaller files but need about double the time compared to tar.gz and zip
Full size table

MedSix ZIP-compression saved on average 52 % of the size of the image (Fig. 7). Images within one transfer have similar compression rates, but the compression rate itself does not seem to be predictable (Fig. 8). Adding more than one file to a ZIP does not improve compression rates because ZIP compresses the files within one archive file by file.

Fig. 7
figure 7

Relative size of compressed images. The line marks the average value of 47.7 % of the original data size. Several clusters of images with the same original size can be identified, for example a cluster with image sizes around 512kB

Full size image
Fig. 8
figure 8

Relative size of compressed data by patient. Efficiency varies strongly both within each patient and between different patients

Full size image

Communication structure

Our analysis shows that communication takes place mostly between specific partners. Within the TNNW, one hospital with maximum care possibilities receives about 69.9 % of all transfers but sends images to only one other hospital (Fig. 9).

Fig. 9
figure 9

Communication structure within the Trauma Network North West. Every square represents one hospital. The bigger the arrow, the more transfers were conducted. The box at the bottom represents short time accounts

Full size image

Six hospitals are using the system only for transmitting data to this specific hospital, while other clinics are using it for transmitting images mutually. Four of them are only sending to one hospital. Every participating hospital created at least one transfer to the hospital with maximum care possibilities. 19.9 % of the transfers were created by holders of short time accounts.

Discussion

One of the big challenges while developing such an image transfer system was to estimate the data volume for typical DICOM transfers before implementation. Similarly, analysis, especially with a focus on data size, compression ratio and transfer patterns for emergency transfers are unknown to us until now.Footnote 1

Data collection and usage

The system has been used for 87 emergency cases in 2012. Although the number of transfers is not as high as expected, the system was considered as very useful in a user evaluation which was done in the end of 2012. Especially the short time account feature was used frequently with 16 % of the transfers.

Communication bridges to other image transfer systems like the system of the German Trauma Society [20] or Dicom @GIT-based [21] systems would be useful to improve the possibility to exchange data with external hospitals. Even if it is not possible to use one free communication standard for all networks, it would be helpful to establish a minimal clearing protocol between them.

Bandwidth consumption and data size

According to Fig. 4, the size of the data of one patient is usually less than 200 MB. This is less than a third of a compact disc and less than we expected. The upload bandwidth of the clinic has to be faster than 1,8 Mbit/s to upload the data within 15 min [22]. This is possible due to the fact that even a normal end-user VDSL-connections with 25Mbit has an upstream speed with about 5Mbit/s. On average, the upload speed was about 270 kB/s, this is 2,2Mbit/s. This shows that transferring DICOM-data between hospitals is challenging but feasible.

To transfer more than 200 MB in less than 15 min seems to be a challenge which needs the data to be compressed or advanced transference algorithms to be used. Transporting more than one image per HTTP-request would be a possibility to improve transfer speed. With a normal image size of 512kB for a CT image the overhead of a request needed to transfer one image takes significant time. Nielsen et al. measured about 3 to 8 % overhead while transferring files with a size of 200kB [23]. Transferring data with more than one connection at a time would be another option to improve speed.

Using both techniques would increase transfer speed for the hospitals where the delay, and not the bandwidth of the connection, is the limiting factor. Therefore, even though the hospitals do have connections with different bandwidths, the time needed to transfer radiological data does currently not really differ (Fig. 5).

Nevertheless, Fig. 6 shows that 86 % of the transfers need less than 15 min without further improvements. The maximal time used for transferring data of one patient is 51 h, but this transfer only contained two images that were uploaded on two different days in separate sessions.

Role of compression techniques

Although transfers often had a volume lower than 200 MB, the data can be compressed further with lossless or lossy algorithms. For example, Peterson et al. showed that it is possible to extremely compress DICOM images using mpeg4-algorithms because the images of a computer tomography only differ in small parts from each other [24]. In 2009, the German radiological society decided to evaluate different lossy compression algorithms and their effect on the recognizability [25]. They stated out, that JPEG and especially JPEG2000 compression could reduce the image size to 25 % of the original size without losing too much information for diagnosis purposes. Hoshasen et al. concluded in 2002, that the compression ratio using JPEG has to be at least 50 % for diagnosis purposes.[26] Ivetic et. Al used JPEG2000 compression to transfer DICOM images to mobile devices [27].

Unfortunately, in Germany strict requirements for using lossy algorithms are inforced by legal provisions, especially the German X-ray Act (RöV) and the Medical Devices Act (MPG). The data must not be altered on the transport; otherwise, the system had to be officially certified and approved. Therefore using a lossless compression algorithm was the only way for MedSix to save bandwidth. Using lossy algorithms for preview purposes would be a trade-off between legal compliance and the need to allow fast first impressions.

But our results show that even with these methods, a practical bandwidth savage can be achieved. As displayed in Table 1, it is possible to improve the compression rates with algorithms like tar in combination with bzip2 or rar. We did not implement this at the beginning because it would need special software on the workstations in the hospitals to deal with bzip2 and rar archives as even Windows XP is able to decompress ZIP-archives without extra software needed. Furthermore, the runtime of these algorithms is double as high as for ZIP archives.

Because of the fact that compressing the DICOM data file by file is resulting in only a negligible increase of the ratio, we used this for the upload process. This gives MedSix the possibility to resume failed upload processes and to display data to the physician at the receiving hospital while the transfer is still running.

The tests of different algorithms showed that the CPU time needed to compress images is minimal. Only about 2 min were needed to compress 2.28GB of data with ZIP to a size of 1.15GB. Therefore the compression saved 1.13GB. On the one hand, this data would be transferrable within 2 min with a bandwidth of about 100Mbit/s. This means that compression would not make much sense if the target system is located within the local area network where the clients are connected with more than 100Mbit/s. On the other hand, using compression techniques in the settings described by Nerlich et.al. in 2000 (with an ISDN connection [13]), Chakera et.al. in 2009 (with connections between 10 and 100 Mb/s [15]) or Obrul et al. in 2012 (using progressive transfer techniques [28]) would definitely be of value.

Communication structure

The observed communication structure shows that mainly small hospitals transfer data and patients to hospitals with advanced possibilities. The centralized care of severely injured patients in level 1 trauma centers does not always seems to be the best option [29]. For some patients, fast transport to the nearest trauma unit may be beneficial compared to a longer transport to a distance level-1 trauma centre. However, after initial stabilization in the nearest hospital, these patients often require transfer to a cooperating level-1 trauma centre [30].

Transporting patients from level 1 trauma centers back to level 2 or level 3 centers is not common. Transfers from level 1 trauma centers are often directed to rehabilitation centers. Patients are admitted to local trauma centers and then, after initial diagnostic and therapy, forwarded to hospitals with advanced therapeutic possibilities. After their treatment, they are directed to rehabilitation centers to complete their therapy.

Sometimes it was needed to receive a transfer from a hospital which was not integrated in the trauma network yet. The feature to create short time accounts was used by the receiving hospital in nearly a fifth of the transfers. Nevertheless, it was one of the prerequisite by many hospitals to avoid a possible lock-in to one proprietary system.

Limitations

There are other systems targeting the transportation of DICOM-Data with other protocols on the market. Engelmann et al. are using the DICOM-E-Mail protocol which has the advantage of being asynchronous and standardized, too [31]. E-Mails could be sent and retrieved in parallel. The main problem of using e-mails for transportation of binary data is the lack of universally accepted cryptography and compression on the mail server. There are efforts to establish end-to-end-encryption within the “@Git”-standard [21].

Using DICOM Send/Receive over VPN seems to be the standard solution to share radiological images between two hospitals. This lacks the support of scalability. For every new hospital within the network, every other hospital has to create and maintain an additional VPN-connection.

Future work

More evaluation, especially regarding clinical outcomes, has to be done. This would be important to prove the positive effect of radiological image transfers by internet to patient care.

But even the system itself can be improved in different ways. Using a lossy compression algorithm can speed up the transfer by a factor of at least two.[25] Furthermore, system administrators of bigger hospitals wish additional components for automatic downloads of transfers to a local temporary PACS system with no need for any user interaction.

Conclusions

HTTP-transfer of DICOM data in emergency cases is feasible. The typical bandwidth of a normal DSL-connection is enough to transmit the typical volume of a trauma patient within an acceptable time. Further time saving can be achieved through advanced compression techniques. Even a lossless compression speeds up the transfer significantly. For system rollout it should be considered that most transfers occur from low to high level hospitals.