Introduction

In this era of growing bandwidth and ubiquitous Internet access [1], it is relatively simple to exchange information, data, and images and almost any information is readily available at any given time. Besides using big sharing platforms that silo data, it is also possible to communicate data directly, thus staying in control of the data flow. The medical world is just starting to use communication and sharing systems, as is commonly the case with non-medical data.

In today’s medical system, we produce, collect, and enter large amounts of data that are sometimes compiled multiple times because easy sharing is not possible, and information that the data have already been gathered is missing or data cannot be accessed within reasonable time. Especially in Radiology and Oncology, it is important to see the development of the patient over a period of time and to access his full medical record including all previous images to obtain a holistic representation of the patient and evaluate the treatment process. While there are lots of standards and standardization initiatives such as Digital Imaging and Communications in Medicine (DICOM) [2], Health Level Seven (HL7) [3] or the Integrating the Healthcare Enterprise (IHE) [4, 5], it is still difficult to share data in a medical environment in a secure and private way.

In Germany, there is a number of teleradiology networks used for sending dedicated images and data. The purpose of these networks is to exchange information, for instance to gain a second opinion without having to move the patient to a different location. In the past, the communication within some of these networks such as the regional “Teleradiologie-Projekt Rhein-Neckar-Dreieck” [6, 7] has been solely based on DICOM E-Mail and the whitepaper “Recommendation or a Standardized Teleradiology Transmission Format” [8]. This whitepaper, developed by the Working Group on Information Technology of the German Radiology SocietyFootnote 1 @GIT, offers a minimal standard to exchange DICOM data between known partners [9, 10] and following the German regulations for constancy testing [11,12,13]. A different method for ad hoc communication between anyone within the network has been built by the academy for trauma surgeryFootnote 2 AUC. In this tele-cooperation networkFootnote 3 (TKmed), individuals are able to send DICOM and non-DICOM data to any registered physician, department or hospital that is part of the network. Participants are able to exchange data with medical colleagues [14,15,16,17].

Neither the evolved e-Health systems [18] nor the existing networks are able to meet all demands of communicators in the medical world who need to access all of a patient’s available data, preferably displayed in one system, at any time and without delay for data transmission. The current systems and networks are limited such that only active sharing between known entities is possible and each connection between partners needs to be secured, e.g., via VPN, requiring a substantial administrative effort. In case of DICOM E-Mail, this can be reduced by using e-mail servers as a mediator between sender and receiver and by exchanging encryption keys using the administrative extensions of the @GIT whitepaper [19]. Unfortunately, the use of e-mail servers and the special base64 encoding for mail attachments (which increases the size of the transferred data by about 37%) decelerates the transfer. Besides the slow speed and the complexity for proper encryption, the existing networks focus mainly on the images of a patient for one dedicated occasion. So far, it is not possible to gather and share images as well as other data that may become important in the future.

The IHE approach of Cross-Enterprise Document Sharing (XDS/XDS-I) offers a solution to this problem. In this concept, any communicator may function as a Document Source, respectively, Imaging Document Source and may deposit documents and images for Document Consumers not yet known [20].

The authors of this paper designed and implemented the image management of a patient oriented sharing system for the clinical routine that allows different partners to exchange data securely and according to the medical privacy standards. The INFOPAT project (INFOrmation technology for PATient-centered healthcare in the Metropolitan Rhine-Neckar Region in Germany) [21, 22] was co-founded by the German Federal Ministry of Education and ResearchFootnote 4 [23] over a 4-year period. Since the end of the project phase in 2016/2017, the system has been used in clinical routine. The goal is to connect more hospitals in the future and to improve patient integration into the workflow by granting patients more authority over their data.

This paper discusses the concept for image and data sharing in an IHE environment and the findings of 5 years’ experience with this approach. The design of such a system is developed, specified, and implemented. The shortcomings and limitations of an IHE only system are presented. Alternatives that were created to improve the user experience in a hospital IT system requiring special rules and security mechanisms will also be discussed.

Design considerations

When building documentation systems for medical patient data, all possible manifestations can be attributed to three different concepts of sharing systems [24]: Electronic Case Record (ECR), Electronic Health/Patient Record (EHR) and the Personal Electronic Health/Patient Record (PEHR).

Electronic Case Record (ECR)

In the Electronic Case Record concept, data are assigned to a single case (e.g., one patient’s admittance to a hospital) and can only be viewed in this context and are only available for a limited time. After the patient is released from hospital or the case is closed, data can no longer be accessed. This approach is suitable for intersectoral communication and is designed to gather documents from different sources.

Electronic Health/Patient Record (EHR)

In the second scenario, the Electronic Health/Patient Record is used to store patient specific rather than case specific data. The EHR is managed by medical professionals and the patient may grant access to personnel of an entire facility.

Personal Electronic Health/Patient Record (PEHR)

The third option is the Personal Electronic Health/Patient Record. A patient, a primary hospital system or a document source might gather or upload data related to the treatment process. Using this kind of health record enables large collections of patient data such as reports, lab results, DICOM images, JPEGs, scanned documents or medication plans. The patient is always in charge of his data and can decide which clinic, department or physician may view his data. Under certain circumstances, the patient may delete some of the information shared previously. The advantage of this concept is that all data are available to the physicians who may decide which information is relevant for treatment. At the time when information is shared, the patient might not know if the data may become relevant in the future.

INFOPAT project

During the INFOPAT project, a platform for medical records in the metropolitan area Rhine-Neckar has been created. The PEHR/PEPA (German: Persönliche einrichtungsübergreifende Gesundheits- und Patientenakte) approach of building a patient-centered [25,26,27] sharing platform to connect all partners in the region was used to improve the treatment process [28] and give patients access to their data [29] by building a structured repository for all medical data.

In the project phase of INFOPAT, the system was built and evaluated with two different use cases, respectively, medical questions in mind. The first use case consisted of patients with diabetes mellitus as a common comorbidity disease [30]. The second use case consisted of patients with colorectal carcinoma [31], a form of cancer that is treated at the University Hospital Heidelberg and the specialized National Center For Tumor Diseases Heidelberg (NCT), and patients often are transferred between these facilities. Data also have to be shared with physicians in private practices and pharmacies. In either case, large amounts of data in the form of laboratory results, reports, radiological and non-radiological images are gathered.

While the health economics evaluation is not part of this paper and was performed in the sub-project GESIS [32], the main goal of this paper is to build and evaluate a sharing system using standardized workflows to create interoperability and enhance processes when needed to gain performance and adapt to a real-world hospital network in Germany.

Working with different partners and an existing hospital infrastructure within the project, the use of established standards was mandatory. The new workflows had to be IHE compliant and had to be based on existing IHE profiles. Thus, DICOM and HL7 standards were used for communication with all medical sub-systems.

The designed system should use current security mechanisms and encryption to ensure privacy between all communicating partners. In existing network designs, esp. in hospitals, security is basically provided by firewalls to block traffic from the outside and systems in the inner network can communicate without any encryption or security measures. The existing infrastructure and network layout had to be respected, and existing security such as demilitarized zones (DMZ) must be used and enhanced by additional security measurements. To ensure data and patient safety, the network should be auditable using a global audit repository logging all access to any data concerning Patient Health Information (PHI). All non-IHE ready sub-system, esp. the Picture Archiving and Communication System (PACS), must be enabled to participate by building IHE adapters. Last but not least the system should be accessible from anywhere so web-based technologies for the EHR and in particular the DICOM Viewer must be provided.

Security

The system adheres to high security standards by using state-of-the-art encryption and two-factor authentication for external access. Single-sign-on between the systems was developed according to the IHE Cross-Enterprise User Assertion Profile (XUA) specifications.

Data and patient safety

Patient and personal information is valuable data that must be strongly protected. Therefore, all connections between the systems must be encrypted and access to data should be logged globally to enable security audits. Because of this, the IHE profile Audit Trail and Node Authentication (ATNA) [33] was implemented. To enforce the patient’s privacy rights and someone else’s permission to view documents and data, the IHE profile Advanced Patient Privacy Consents (APPC) was respected [34].

Primary hospital systems

Since all data are produced or stored in hospital systems (such as Hospital Information System (HIS), Radiology Information System (RIS), Laboratory Information System (LIS) or PACS), these systems are the primary data source. Thus, all sub-systems need to be connected by implementing the IHE XDS Document Source, respectively, Imaging Document Source. In order for all systems to become part of the IHE workflow, adapters and interfaces had to be created.

Existing infrastructure

The existing infrastructure of hospitals is often protected against (cyber-) attacks by means of security measurements such as firewalls, demilitarized zones (DMZ), and virtual private networks (VPN). The new systems should employ the existing security mechanisms and enable the connection to the sharing system without compromising the security already in place.

Web-based viewing

To increase user and hospital acceptance, we refrained from installing additional client software to view reports and images, avoiding software installation on the hospital’s hardware infrastructure by using web-based components.

Scope of this work

This paper specifically covers image sharing and management in an XDS environment. The mechanisms of the patient record system, respectively, XDS Repository, Registry, MPI, and the Audit Repository and Patient Privacy Consents Management are not included in this document but are essential for a functional XDS network.

Description of methods and systems

The PEPA system was built by using existing and tested IHE profiles for the main workflow. First of all, the Cross-Enterprise Document Sharing (XDS) profile was used to build the base functionality with XDS Repository, Registry, Document Sources and Document Consumer. To identify patient data coming from different locations, a master patient index (MPI) and the Patient Identifier Cross-Referencing (PIX) profiles were used. In order to observe security, auditability, single-sign-on and patient privacy consents, the IHE profiles Audit Trail and Node Authentication (ATNA), Cross-Enterprise User Assertion (XUA) and Advanced Patient Privacy Consent (APPC) were applied.

Since MPI, ATNA, XUA and APPC can easily be implemented, this paper focuses on the Cross-Enterprise Document Sharing for Images profile. DICOM images are of special interest because they account for a major part of the data volume and because they require different treatments.

Cross-enterprise document sharing (XDS)

The setup of an IHE XDS sharing system consists of four actors and their IHE transactions [35, 36] as outlined simplified in Fig. 1 [37]. A Document Source creates documents and provides them to a Document Repository for storage (ITI-41). The Repository stores the documents and registers them at a global Registry (ITI-42) that can be queried by Document Consumers searching specific patient documents (ITI-18). In case of the INFOPAT project, the Document Registry and Document Repository were combined into one single system forming the core of the sharing system and acting as an EHR with a web front end that healthcare professionals with the appropriate user rights may search for patient information and that allows them to view all registered documents. Any non-DICOM document can be retrieved (ITI-43) and read by regular Document Consumers without requiring dedicated software.

Fig. 1
figure 1

Basic IHE XDS actors and transactions [The complete workflow for all IHE XDS actors and transactions can be found at https://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing#Systems_Affected (last access: 30.04.2018)]

Full size image

In this scenario, a Document Source may be the hospital’s HIS, RIS, LIS or any other sub-system that produces data for the Repository. Patients may also upload their data via a patient portal after registration at the system and using two-factor authentication for additional security.

Cross-enterprise document sharing for images (XDS-I)

As stated above, DICOM images require special treatment. Since regular image viewers are rarely capable of displaying DICOM images and due to their large size, it is not advisable to duplicate the data in a central Repository. Therefore, the Imaging Document Source which is combined with the primary source of images (e.g., the PACS, modality, etc.) generates a recap of the images and provides this Key Object Selection (KOS) to the Repository using a Provide & Register Imaging Document Set Transaction (RAD-68) [38]. The Repository then registers the KOS at the Registry (ITI-42) as shown simplified in Fig. 2 [39]. A KOS is a special and small DICOM object without pixel data referencing the shared images.

Fig. 2
figure 2

Basic IHE XDS actors and transactions for imaging data [The complete workflow for all IHE XDS-I actors and transactions can be found at https://wiki.ihe.net/index.php/Cross-enterprise_Document_Sharing_for_Imaging#Systems_Affected (last access: 30.04.2018)]

Full size image

When the Imaging Document Consumer queries the Registry (ITI-18) for imaging documents, the location of the KOS is provided which is subsequently retrieved from the corresponding Repository (ITI-43). With the information from the KOS the Consumer knows the original location of the DICOM images, respectively, the Imaging Document Source (e.g., the primary PACS system) where data are stored and may retrieve the images from the source (RAD-16) [40] for display in a dedicated DICOM viewer.

The advantage of this mechanism is that the DICOM objects always remain in the primary systems and are only retrieved by systems that can display them properly as needed. The disadvantage is delayed image display for large DICOM studies that are transferred over the network.

Integration process and current status

To overcome the limitations stated above, the Imaging Document Source and Imaging Document Consumer were combined into an Imaging Cache as outlined in Fig. 3. The Imaging Cache has a dedicated storage for DICOM images. The size of the cache may be adjusted depending on the allocated storage time.

Fig. 3
figure 3

Image storage using a dedicated Imaging Cache (only main transactions are displayed)

Full size image

Imaging cache

In the current workflow (Fig. 3), the cache is prefilled by the hospital’s primary PACS system. Whenever a patient approves of his data being added to his PEHR (via the IHE APPC transactions), a HL7 message is sent to the Imaging Cache acknowledging the patient’s consent. In the next step, the RIS generates a radiological report and stores it in the PEHR. The Imaging Cache then receives the report as HL7 ORM message, triggering the related images to be retrieved from the PACS via DICOM Query/Retrieve (Q/R). After retrieval and storage of the DICOM study in the cache, a DICOM KOS is created, stored, and registered at the Document Repository, respectively, Document Registry.

In the INFOPAT project, the Document Registry and Document Repository are combined into one single system representing the EHR. Because of this union, the communication between these two actors can be simplified if needed while the IHE functionality will still be available if others Document Repositories, Sources or Consumers should be enabled to participate in the network. This EHR has a dedicated user interface to display documents to the user and special methods to extract information from its back-end without the need to use the Registry Stored Query (ITI-18) transaction. To display DICOM data, a special viewer, delivered on demand by the Imaging Cache server, is included (Fig. 4).

Fig. 4
figure 4

Image retrieval and display using a dedicated Imaging Cache and a combined Document Registry and Document Repository (only main transactions are displayed)

Full size image

Whenever DICOM studies of a patient are needed later on, the regular XDS workflow is substituted by a remote call to the Imaging Cache server requesting a web-based viewer containing the selected study. This is achieved by using the document id of the registered XDS Document Set. The Imaging Cache now retrieves the specified KOS from the Document Repository. The KOS references the exact images that will be presented to the user. If they are present in the cache, they will be immediately delivered to the user. If the images have already been deleted from the cache, they will be retrieved again from the PACS which may require some time. The cache is organized such that images will be deleted according to their study date and time of last access. This guarantees that most recent and frequently accessed studies will always be available in the cache for quicker access.

Streaming access

In addition to the caching functionality, the combination of Imaging Document Source and Imaging Document Consumer was enhanced with image streaming functionality. In a regular XDS workflow, the Imaging Document Consumer would have to retrieve the entire study via DICOM Q/R or a Web Access to DICOM Persistent Objects (WADO) call before it could be displayed. While this is still possible and conforms to IHE XDS profile, the Caching Server is able to produce a fully featured and flexible DICOM viewer that streams only the particular part of the study currently displayed or more precisely, only the region of the image which is viewable to the user, e.g., during zooming and panning of images. This largely impacts performance and acceptance by the user.

Table 1 shows the number of successful retrieves (at study level) for the six most frequently used types of modalities during 2017. The duration of a retrieve varies between a few seconds to over 1 h with an average time of 1:52 min for CT studies.

Table 1 Duration of successful retrieves per modality in 2017 (retrieve time measured in ms)
Full size table

When analyzing CT studies (Table 2) performed in 2017, only 9617 studies from a total count of 14,510 were retrieved successfully. Retrieves failed due to the following reasons: DICOM connection or network problems or reasons within the hospital PACS the cause of which could not be determined.

Table 2 Transfer size of retrieved studies per modality in 2017 (transfer size measured in byte)
Full size table

Table 3 indicates the average loading time for images already in the system that do not need to be retrieved. The average loading time for a single image is 50 ms, and an average CT study with 935 images could be loaded within 46.8 s. Since only the viewable part of the image has to be streamed, the difference in display times between a CT image (average size: 0.3 MB) and a CR image (average size: 6.27 MB) is negligible.

Table 3 Average loading time for streamed images (loading time measured in ms)
Full size table

In most instances, the study does not need to be loaded entirely as only the requested series or images need to be streamed to the client for display. This significantly improves performance.

Multiple sites

One of the main goals was using this concept with streaming services in an XDS Affinity Domain with multiple locations. Since the users of the system do not always connect from the same security segment as the PEHR or even the Internet, special measures had to be put in place.

All connections to the PEHR are filtered by a proxy server and a Web Application Firewall (WAF). This service is located inside the DMZ of the main system for security purposes (see Fig. 5).

Fig. 5
figure 5

Simplified imaging workflow using a Request Broker for streaming access (components in oval are non-IHE actors enabling enhanced workflow)

Full size image

To allow the streaming of data from different sites or hospitals, the concept of a Request Broker was introduced. Instead of handing the viewer request directly to the Imaging Document Consumer, the Request Broker handles connections to the Document Repository and preprocesses the KOS. Apart from the referenced studies and images, the KOS also contains the original study source. After reading the source from the KOS, the Request Broker produces a viewer for the user with the properly configured Imaging Cache and then streams all data between client and server through the Reverse Proxy and WAF allowing only connections to the DMZ, never directly to the individual site’s caching server.

Data export to primary systems

All data can be viewed in the PEHR for reasons of traceability. Furthermore, it was also necessary to allow physicians to transfer data from the Imaging Cache directly to the primary PACS system if they base their diagnosis or radiological reporting upon these images. This is absolutely essential, since due to the concept of the PEHR it is conceivable that patients might withdraw the viewing rights for shared documents. In addition, radiologist prefer to work in their familiar environment with all tools available and sometimes need all images of a patient, including prior studies for comparison in one system. This is also essential for tumor boards where studies and images need to be specially prepared for effective viewing and comparison.

Experience within the clinical routine

Starting with real patients over a 4-year period ranging from 2014 until the end of 2017, a total of 119,563 DICOM studies have been processed and registered in the XDS Document Registry during the INFOPAT project (Fig. 6).

Fig. 6
figure 6

Registered DICOM studies between 2014 and 2017

Full size image

The number of patients that approved of the registration of their images in the PEHR increased from 3962 in 2014 to 6443 in 2017 (Fig. 7).

Fig. 7
figure 7

Participating patients between 2014 and 2017

Full size image

Compared to the patients who refused to approve, this seems to be a very low number. The numbers are generated by reading HL7 MDM messages carrying the approval flag with a missing flag being interpreted as lack of approval. Since the server receives all HL7 MDM messages from the entire hospital network through the communication server, also messages from systems and departments which do not participate in the network (the projects initial use cases, respectively) or had not been rolled out yet are received and evaluated. A small survey was conducted that evaluates patient’s approval at the HIS in two participating departments (Fig. 8).

Fig. 8
figure 8

Approval of patients (left: University Hospital Heidelberg, right: Thoraxklinik Heidelberg)

Full size image

In both hospitals, the number of patients who did not approve is less than 2%, whereas the number of patients who did not specify varied between 10 and 27%. This is due to the fact that patients currently have to fill out paper forms that are later entered into the HIS. If a patient does either not fill out the form or it is lost (or is never entered), this counts as refusing to participate. Additionally, the Thoraxklinik has a central admission system with more guidance for patients when filling out the participation forms.

Lessons learned

A fast and flexible sharing system for patient and image data in a hospital network was established. The system enables easy sharing of all types of documents and in particular DICOM images related to one patient. During the project, the system had to be constantly adapted to the needs of users and their habits.

Cache size and speed

The concept of the Imaging Cache was developed in an early project stage but had to be adapted multiple times over the course of the project. Initially, the cache was designed to store images for a few weeks only. Images could always be retrieved from the original source, allowing all images to be available at any time but the loading speed would vary. While loading studies from the cache would only take milliseconds for the first image to be displayed in the viewer, it would take up to 1 h until a study is retrieved from the source and made available in the cache again. Because of this, the size of the cache was increased to hold image data for at least half a year. The oldest images not accessed where removed from the cache when space was needed. This increased the loading speed for current studies dramatically and improved the users’ experience.

Reference to DICOM studies

Key Object Selections are designed to identify the selected object by DICOM Study, Series and ImageInstanceUID, i.e., every individual image of a study is referenced in a KOS. This is suitable to reference only selected key images of a study, e.g., for reporting. When this mechanism is used to share entire studies containing thousands of images, loading might be delayed. Whenever the image viewer on the cache server was used to display the referenced objects, every single image had to be checked. Since the cache was organized to store and delete data on study level only, the loading process could be improved by only testing the first images of a study before delivering the viewer to the user and continuing to load the study in the background. If at a later point in the loading process images were missing from the cache for any reason, they were retrieved individually from the Document Source.

Postprocessing and other secondary DICOM objects

After using the system in production, it became clear that primary systems often enhanced the original DICOM studies with postprocessing data such as Structured Reports (SR) or other Secondary Capture (SC) objects at a later date. This triggered a registration of the newly created objects, using the same StudyInstanceUID. To prevent these duplicates, a filter, based on the StudyInstanceUID and Modality, was implemented to avoid registering these secondary objects as they always belong to an original study. The mechanism described in 6.2 ensured that the whole study, including postprocessing objects, was loaded and presented to the user without loss of information.

Duplicates

Since the network is mainly used to share data of patients that were transferred between hospitals, some of their images are stored in more than one primary PACS. Whenever the patient agreed to share his data with the PEHR, these studies created duplicates in the system. As DICOM data is not available in the XDS system, the Document Repository could not be checked for duplicates by querying with the unique StudyInstanceUID. The combination of PatientID and DICOM AccessionNumber (or mapped XDS ReferenceID) could not be used either because every site creates its own set of IDs. This problem was solved by creating a query for duplicated entries by Modality (mapped to XDS TypeCodes), StudyDate/Time (XDS CreationTime), and global PatientID from the MPI. This solution proved successful and is now used to avoid duplicates in the network.

Conclusions

In today’s fast changing world of information technologies, it is essential to rely on established standards such as DICOM, HL7, and HTTP/S to keep systems connected and use well-proven frameworks and transactions such as IHE XDS/XDS-I to build robust, secure, and interconnected systems and networks. While initiatives such as IHE and their Technical Frameworks are important to achieve maximum interconnectivity and standardization, they neglect user experience. After meeting basic needs, the user experience and especially the connection speed must be addressed to increase acceptance of such a sharing system.

As outlined in this paper, a state-of-the-art sharing system used in a productive clinical environment was build and is able to grow with additional partners. While adaptations of the IHE workflow were necessary to increase the performance and acceptance of the system, all participants work in compliance with standard IHE transactions. Participants could be decoupled at any time to support the standardized workflow, and other participants using only the regular transactions of the IHE Technical Framework could be connected which is essential to keep interconnectivity with other partners.

The described system is the basis for an elaborated interdisciplinary collaboration where data, and in particular images, can now be shared between medical professionals in a fast and reliable way.

Perspective/future plans

At the end of the project phase, the system runs soundly in daily routine and is continuously improved considering the users’ needs. Currently, the plan is to add another hospital site to the sharing network. Because of the generic IHE approach and standardization, it is feasible to connect the entire network to other XDS Affinity Domains, creating an even larger network in the future.

The patient portal has not been fully developed during the project and will be refined and advanced in the future. This offers an opportunity to add a zero-footprint viewer to the Imaging Cache, enabling quick access for patients. This functionality has already been developed but has not been integrated yet.

During the duration of the project, other networks using equal technologies and techniques were enabled and the system is already working in routine to connect different locations of a German clinic network. The emergence of different XDS networks in Germany will benefit mutual development and increase the user experience and usability of such sharing system in the future.