Introduction

In the early 2000s, Picture Archiving and Communications System (PACS) penetration in Dutch hospitals reached nearly 100%. The transition from analogue to digital imaging not only led to significant process improvements within the imaging departments, but also triggered widespread adoption of image accessibility through PACS workstations and enterprise wide digital image viewers. Although the DICOM standard was quickly and widely adopted, the transition to digital imaging introduced new challenges, such as when sharing medical images with other healthcare providers. Midway the 2000s, the emerging IHE profiles XDS and XDS-I quickly gained interest in the Netherlands and provided a solid basis to set up open and standard-based information sharing infrastructures. In this article the authors will describe the developments that have led to nationwide exchange of diagnostic images in the Netherlands, and discuss some lessons learned throughout this journey.

2000–2005: Developing the Need

By the late 1990s of the previous century, Dutch hospitals had either procured a Picture Archiving and Communications System (PACS), or were involved in a tender to procure one. Some of the early PACS adopters were starting to explore options to replace their first-generation PACS, and vendors like Philips, Agfa, Sectra, and Carestream were busy selling and implementing their PACS solutions. Since the main focus of hospitals was to satisfy enterprise access to radiology images, solutions to enable the exchange of diagnostic images with other healthcare providers were not considered top priority. To satisfy the then only sparse need for image exchange, the DICOM CD/DVD silently replaced film by way of physical media information exchange. Still, the Dutch government anticipated that the future of information exchange would be electronic rather than physical when they started a national EHR initiative around that time. In 2004 the Dutch chapter of the international “Integrating the Healthcare Enterprise” (IHE) was founded as a joint initiative of PACS vendors and the Dutch Association of Radiologist. Since IHE was firmly rooted in the radiology domain, from a very early stage the emerging IHE XDS [1] profile was considered to be a viable answer to the challenges associated with sharing radiology images between PACSs from different vendors.

2005–2010: IHE XDS Is Gaining Momentum

Despite the need to exchange radiology information the first image sharing project using IHE XDS emerged in the cardiology domain. Since at that time interventional cardiology and thoracic surgery was limited to a few specialized centers, general hospitals had a need to streamline the referring process for their cardiac patients that required interventional treatment. Having their patient’s information available in the multidisciplinary team meeting on the same day could speed up the entire treatment episode by days, saving on costly medium-care beds. The general hospitals in the northern province of Friesland joined forces with their intervention center at Medical Center Leeuwarden [2] as well as the University Medical Center Groningen and implemented a cardiac information exchange using IHE XDS-I infrastructure that enabled the quick and efficient exchange of angiographic images, reports, EKG’s and function tests, patient summaries, and other relevant information. This XDS-based sharing infrastructure was implemented in less than a year, and led to quite some interest from other cardiac departments and hospitals throughout the Netherlands.

Among the factors that drove the popularity of the XDS(-I) profile was that XDS itself was easy to understand by clinical informaticians, architects, and to some extent the hospital C-suite. Each of the “actors” in the XDS profile [1] can be easily mapped to real-world systems such as PACS, EMRs, and other clinical information systems playing a role in the exchange of diagnostic information. The XDS transactions to publish, query, and retrieve images were firewall friendly and, as opposed to the traditional DICOM protocol, suited for Wide Area Networks. The fact that XDS is agnostic to the information being shared added to its popularity since the profile allows for any type of diagnostic information to be shared.

Although from a practical point of view XDS elegantly solved the information sharing problem, a legal discussion started on the information ownership and related governance responsibilities of the XDS Registry and Repository actors. Where hospital IT departments were well equipped to handle enterprise (clinical) IT infrastructure, maintaining IT infrastructure that is used by external healthcare providers led to discussions about service level agreements, (registry) data ownership, and liabilities. These new challenges were quickly picked up by regional health information exchange (HIE) organizations. HIE legal entities such as Gerrit, RijnmondNet, and ZorgnetOost considered IHE XDS as an opportunity, and took ownership of the XDS Registries and Repositories and provided information exchange as a service to their stakeholders.

Despite the growing interest in IHE XDS, establishing health information sharing networks only progressed slowly. In 2009 the National Breast Cancer Screening network [3] RFP turned out to be a game changer. With the screening [4] network being the responsibility of the Dutch Public Health Institute (RIVM), both the image acquisition and diagnostic reporting are carried out in an independent, dedicated screening PACS (Fig 1). On suspicion of breast cancer, women are referred [5] to a hospital of their choice for further treatment. This referral pattern introduced a nationwide challenge to somehow make all screening images and reports available to every radiologist working in any Dutch hospital.

Fig. 1
figure 1

Dedicated screening PACS

Full size image

In 2009 the University Medical Center of Utrecht (UMCU), the Antonius Hospital in Nieuwegein, and the Diakonessenhuis in Utrecht engaged in a pilot [6] to exchange this screening data using XDS(-I). In many ways, this pilot identified the challenges with IHE XDS-based information sharing that had to be tackled in the years to come.

2010–2015: The Rise and Fall (Almost) of XDS(-I)

In parallel to the mostly regionally developed sharing infrastructures a national debate had started in the Dutch parliament about the realization of a National EHR system [7]. Driven by political ambitions the Dutch Ministry of Health had developed a plan for creating a national IT infrastructure allowing the exchange of medical information in general. By 2011 the debate had heatened up, and narrowed down to a discussion about privacy. On April 5 the Dutch Senate voted for a motion [8] to immediately halt the National EHR program since it was not convinced these privacy concerns were adequately addressed. The following years it turned out that this ruling had both positive and negative effects on the adoption of IHE-based exchanges in the Netherlands.

Since establishing any kind of central information exchange infrastructure on a national level was no longer possible because of the Senate ruling, hospitals started to explore alternative solutions to efficiently exchange medical information. This led to a growing interest in IHE. As a result, XDS-based regional health information exchange networks quickly emerged across the Netherlands.

One of the accelerating growth factors that IHE had anticipated was a quick and widespread adoption of IHE profiles by vendors, as IHE was a joint initiative of users and vendors. Unfortunately, vendors of PACS and EMR systems were either slow to adopt or incomplete to implement the full set of IHE profiles that were required for safe and secure cross-enterprise information exchange. As a result, radiology users suffered from suboptimal (workflow) experiences when publishing or retrieving information from XDS-based infrastructures. Despite initial studies showing positive business cases [9, 10], PACS vendors did not give priority to improve these experiences, rather pushing for their own proprietary sharing solutions [11,12,13]. This “lack of priority” meant that exchanging images via an XDS infrastructure did not fit in well with clinical processes. That caused resistance among radiologists and PACS administrators, while clearing a path for a variety of proprietary image exchange alternatives.

Meanwhile, as a result of the Senate ruling on the national EHR a fierce public debate led to the notion that query-based, “pull”-type exchange networks such as XDS required informed patient consent to be explicitly obtained before any information could be exchanged. For “push”-type, point-to-point information exchange (e.g., DICOM Mail) on the other hand, implicit consent would be sufficient to share information with peer healthcare providers. In 2013 this was so articulated in the EGIZ Code of Conduct [14]. Obtaining informed patient consent in a clinical setting turned out to be an organizational challenge for hospitals. That factor led to situations where clinical information was available for sharing in XDS networks but was not accessible for peer healthcare providers because of missing or insufficient patient consent.

By 2015 a number or regional networks joined forces in the “RSO Netherlands” organization [15] to address these concerns and obstacles [16].

Onward: IHE XDS as a Service

Despite these legal and organizational obstacles, the market matured and more and more hospitals adopted IHE XDS, either by joining a regional XDS-based HIE network or by implementing their own XDS network [17, 18]. Another development was that more -ologies started using this novel form of information exchange, with referring patterns requiring more and more cross-regional information exchange. The traditional boundaries of a traditional HIE (or region) started to fade. In parallel, regulations for privacy and consent stabilized with the introduction of the GDPR [19].

Facing IT-infrastructural difficulties with sharing diagnostic images and reports across HIEs combined with the wish of hospitals to have more individual control over their information sharing strategy, hospitals started to redefine the definition of an XDS affinity domain. In 2015 the hospitals in and around Eindhoven chose to form a network [20] in which each hospital maintained their own XDS affinity domain linked via XCA [21] with the other hospitals.

On top of that, these hospitals chose to outsource their XDS affinity domain infrastructure to their XDS vendor. These two changes offered a few clear advantages over the traditional XDS Affinity Domain setup with an XDS Registry shared among several healthcare providers. Publication of sensitive patient information to the registry became a non-issue given the 1-on-1 relation between the hospital and the XDS Affinity Domain. Replacing XDS query and retrieve transactions with XCA equivalents made it easier to respond to an external request since patient consent could easily be enforced locally. Furthermore, outsourcing the entire XDS infrastructure to the XDS vendor made it easier to maintain a secure, trusted, scalable, and extensible network among the hospitals.

Rapidly all Dutch XDS vendors turned their XDS solutions into cloud-based offerings lowering the effort to onboard hospitals to their sharing infrastructures. Hospitals started to move their on premise XDS infrastructures to hosted environments provided by different vendors.

The learnings from both the initial hospitals choosing to go with cloud-based alternatives and the regional HIE networks have led to new insights and definition of an interoperability model [22].

Results

One HIE network in particular stands out in the Netherlands. The 3 northern provinces (of which one was the first adopter of XDS in the Netherlands) organized themselves into a health information exchange connecting 9 hospitals [23]. With a combined population of approximately 1.6 million inhabitants the exchange volume of XDS(-I) documents grew from 76,000 in 2015 to (an estimated) 1,000,000 by the end of 2021. Initially only DICOM studies were exchanged. Over time radiology reports, discharge, and mental health summaries were added (Fig. 2).

Fig. 2
figure 2

Exchange volume XDS Network North Netherlands

Full size image

Further learnings from this HIE are that the smaller hospitals in the network account for the (relative) majority of the shared DICOM study volume. This may not be unexpected as image referral patterns in the Netherlands are predominantly from smaller to larger hospitals (Table 1).

Table 1 Relative exchange volume by hospital size
Full size table

2020: Connecting the Dots

In March 2020 at the onset of the COVID pandemic in the Netherlands the available IHE XDS-based infrastructure showed its value as an IHE XDS-based National COVID-19 Patient Exchange Portal [24]. The National Portal was set up within 2 weeks, connecting to 95% of the Dutch hospitals in that period.

At the same time the COVID pandemic acted as a catalyst to technically interconnect each and every XDS Affinity Domain with one another. The initiative to do this came from the Dutch XDS vendors, since creating the opportunity to quickly enable information exchange between any and all hospitals was not only an advantage for the users (the healthcare providers) but also the vendors themselves since they had to initiate a lengthy and difficult project for each such interconnection.

To achieve this goal, the vendors joined forces under the umbrella of the “Taskforce Samen Vooruit” [25], where they harmonized connection requirements on a “minimal viable product” level, subsequently documented in a Technical Agreement (TA). The TA was published early 2021 and the infrastructure work was completed by September 2021.

Discussion–Lessons Learned

A number of lessons can be learned from the past 20 years of experience with IHE-XDS based information sharing in the Netherlands.

Lesson #1 — Do not focus on image sharing per se when you are building a HIE

Diagnostic images are only one of the many clinical information objects that are relevant when providing patient care. Hence, when setting up and investing in sharing infrastructures it makes sense to choose for a design that is agnostic to the type of information being shared. IHE XDS with its service oriented and distributed architecture appears to be a good fit. However, the XDS profile is still limited to mostly the infrastructure and application aspects of a sharing infrastructure leaving many information governance aspects unaddressed. This “gap” has led to the development of the Dutch “Interoperability framework” (Michiel Sprenger [22]) and the “Interoperability Guide” (Nictiz [26]). The framework is derived from the European Interoperability Framework [27] and identifies 6 “layers” that need to be addressed before successful exchange of clinical information can be achieved. The layers influence each other and need to be addressed as a whole. The interoperability framework has become the de facto model when designing information exchange infrastructures in the Netherlands (Fig. 3).

Fig. 3
figure 3

The Dutch Interoperability Framework (original version)

Full size image

Lesson #2 — Get your agreements in place

The increased focus on security and privacy that resulted from the Senate ruling to abandon the Dutch National EHR made it very clear that organizations sharing clinical information had to comply with regulations concerning these two factors. With the European GDPR coming into effect in May 2018 the importance of sharing agreements between HIE stakeholders only grew. HIE organizations are an important party in creating and enforcing such sharing agreements. Common elements in these agreements are (1) establishment or definition of a shared patient identifier, (2) definition and appointment of trusted (user) identities, (3) base model for patient consent (opt-in/opt-out), and (4) authorization profiles that determine who may access which types of information.

Lesson #3 — Building trust in your network

Any sharing infrastructure can only be successful if there is trust among the participants. Without this trust, security and privacy concerns will block sharing of information. In addition to legally binding sharing agreements between HIE participants the IT infrastructure and application used for information sharing need to provide all necessary functionality to support establishing this trust.

The following picture details the required trust relationship between a clinical “user” (e.g., medical doctor), requesting access to a medical information “resource” (e.g., DICOM study, report, discharge summary), and the patient “subject” (Fig. 4). When the user, resource, and subject are all managed by the same clinical system the “trust relation” between these three objects is owned by that system. In a health information exchange setting the challenge is that the user and resource are “owned” by different systems (e.g., the requesting PACS and the responding PACS). Trust is created when the responding system holding the resource can unambiguously identify the user initiating a request. This trust is strengthened in case the patient, via consent, can influence the decision by the responding system to provide a response to the request.

Fig. 4
figure 4

The required trust relationship between a clinical “user” (e.g., medical doctor), requesting access to a medical information “resource” (e.g., DICOM study, report, discharge summary), and the patient “subject”

Full size image

Within its ITI domain IHE provides a number of integration profiles that facilitate establishing this trust. The HIE networks in the Netherlands have shown that these profiles (IHE ATNA, XUA, and BPPC) are extremely useful. IHE ATNA enables the creation of a secure network with trusted nodes that are allowed to communicate. The XUA profile adds the exchange of authenticated user identities enabling a clinical data custodian to properly evaluate a request for exchanging information. Since the authenticated identity includes well-formed information about the actual user and the actual context of the request (i.e., emergency or planned care), it is also very helpful to audit the exchange transactions. Lastly, IHE BPPC closes the chain of trust as it provides a way to electronically capture patient consent in a machine-processable form. The latter is important since it allows the patient consent to become an element in an access control decision a data custodian is required to make before granting access to clinical information.

Lesson #4 — Interoperability is a mindset.

Despite the fact that IHE offers practical solutions to implement a health information exchange the Dutch Interoperability Framework and Interoperability Guide have shown that still many finer details remain to be agreed upon by all stakeholders within the HIE. It is therefore of utmost importance that these stakeholders actively seek to find common ground. The Dutch “Technical Agreement” for Image Sharing [28] is a good example. Another is the Dutch Twiin [29] program.

Conclusions

The authors of this article have tried to provide insights into the development and achievements of IHE-based health information exchange networks in the Netherlands, and have derived a number of learnings gained throughout this journey. IHE-XDS(-I) and related integration profiles including ATNA, XUA, BPPC, and XUA have demonstrated to be mature and well suited to build real-world health information exchange infrastructures. However, restricting the definition of interoperability to the infrastructure and applications does not warrant successful (clinical) information exchange. Equally important are the legal, process, and information aspects of the exchange in order to build trust between HIE participants. Building trust among participants is accelerated by open specifications and guidelines.