Radiology built the network. Cardiology shouldn't need another one.

A few years ago, I wrote with Alex Settels and Maarten Festen about the development of IHE-based medical information exchange in the Netherlands.

The story started with the digitization of radiology. As medical imaging became digital, hospitals needed ways to exchange those images beyond their own organizations. Over time, regional networks based on Cross-Enterprise Document Sharing (XDS) and Cross-Enterprise Document Sharing for Imaging (XDS-I), profiles developed by IHE, became part of the infrastructure for sharing medical information between hospitals.

One of the conclusions we drew at the time was that successful exchange depends on much more than technology. Standards are important, but so are governance, processes, alignment, and trust.

Today, I think there is another question we need to ask. Hospitals are under pressure to get more value from existing IT investments while managing costs with limited technical capacity. Every additional exchange environment adds something to operate, maintain and govern. Extending infrastructure that is already in place across more clinical domains can therefore increase the value of that investment while reducing the need to manage parallel approaches.

Are we making enough use of the infrastructure we have already built?

Different specialty, same infrastructure question.

Radiology is already connected to XDS in many hospitals. Cardiology often isn't.

Instead, cardiology studies may move through a separate exchange environment, with its own integrations and operational processes.

There are good reasons why cardiology and radiology have developed differently. Their clinical workflows are different. Their systems and applications can be different. Cardiologists and their teams have different requirements. But a different clinical workflow does not automatically require a different exchange infrastructure.

That distinction matters.

When a hospital needs to exchange images from another specialty, the first question can easily become: what additional solution do we need?

From an architecture, operational and value perspective, I think we should start somewhere else

Can the infrastructure we already operate support this new clinical data stream?

Don't confuse the workflow with the network.

XDS is often closely associated with radiology because radiology was an important driver behind its adoption. But the underlying infrastructure is standards-based and vendor neutral.

That gives hospitals an opportunity to separate two things that are sometimes treated as one: the clinical workflow and the infrastructure through which information is made available and shared.The key message here is to separate the data from the process. Cardiology can continue to use the clinical tools and workflows their cardiologists need. Using XDS does not mean turning cardiology into a radiology workflow.

For hospitals already operating an XDS-based exchange infrastructure, cardiology can connect and benefit in the same way as radiology does. The same underlying exchange infrastructure and governance model support other imaging domains rather than introducing a parallel exchange environment.

This changes the architectural discussion.

The objective isn't consolidation for its own sake. It is deciding deliberately which parts of the architecture genuinely need to be specialty-specific and which can be shared.

The value of using what is already there.

This is where the argument becomes practical for healthcare IT teams.

A parallel environment means another stack to run and support. It can also mean another system to license and maintain, alongside separate processes for exchanging studies.

Bringing cardiology onto existing XDS infrastructure takes a different approach.

For hospitals already using Founda for radiology, the network, consent and retrieval paths are already there. The platform is already being operated, secured, patched, and governed. The new element is the cardiology PACS connection.

Through Founda's Integration Engine (formerly forConnect), the cardiology PACS can connect to the existing XDS environment rather than requiring another exchange stack. Radiology and cardiology can then use the same underlying platform and retrieval paths while retaining the clinical tools and workflows appropriate to each specialty.

This is also where governance becomes important.

Cardiology can operate with the same consent and audit mechanisms already supporting radiology. Founda's Mitz Connector integrates consent verification into data availability workflows, while the existing ATNA audit trail supports the same approach to auditing access and exchange.

The clinical experience does not have to change either. The existing tools and EHR remain in place, without introducing another login simply to support the exchange.

This reflects a broader principle behind Founda's approach to Image Availability: different imaging workflows can make use of a shared, standards-based infrastructure rather than requiring the exchange layer to be rebuilt around each individual use case.

The objective isn't to consolidate for the sake of consolidation.

It is to make deliberate choices about what needs to remain specific to a clinical workflow and what can be shared across the organization or network.

What does that look like in practice?

St.Antonius Hospital provides a useful example.

The hospital brought cardiology image exchange onto its existing XDS infrastructure.

They started with the clinical requirement: working with their cardiologists to understand what needed to be shared, with whom, and how.

From there, the relevant processes and data flows were identified. Connecting the cardiology PACS then became largely a matter of configuring and testing those flows against the existing XDS environment.

It is a structured extension of the existing architecture.

And the transition does not need to happen through a single cutover. Existing and new routes can operate in parallel during the transition, with the existing route retired once sufficient coverage is in place.

This is still an implementation journey. It should be presented as such. But it demonstrates that the architectural choice is a practical one, not simply a theoretical discussion about consolidation.

The next requirement will not be the last.

Ca

Cardiology is the immediate use case, but I think the larger architectural question is more important. Healthcare IT infrastructure has to support requirements that continue to evolve.

Today, the question might be how to make cardiology images available across organizations. Tomorrow's requirements include supporting secondary use, preparing for EHDS, and exploring how imaging data can be made available to AI workflows.

We should be careful not to suggest that one architectural decision solves all of those challenges. It doesn't.

But the direction matters.

If every new requirement results in another exchange environment, healthcare organizations will definitely be challenged to reach a sufficient level of scale that justifies the efforts, investments and costs. What I believe is important is that hospitals develop a vision on how to move from their current exchange solutions towards an interoperability platform that can grow with changing demands and requirements.

That is why I think cardiology is an interesting test of a much broader principle.

Before building another road, look at the one you already have.

For hospitals already using Founda and XDS for radiology image exchange, the question should not automatically be:

What new platform do we need for cardiology?

A better question would be:

How much of this can be achieved with the infrastructure we already operate?

This is an important part of how we think about data availability at Founda. Standards-based and vendor neutral infrastructure should provide a foundation that can be extended as new data, systems, and workflows need to connect, or when interoperability requirements change. Rather than requiring another isolated exchange solution for every new use case.

For hospitals already connected to the Dutch XDS infrastructure via Founda, cardiology is a practical example of that principle. The existing network, governance, and retrieval paths can support another imaging domain, while cardiologists continue working with the clinical tools and workflows they need.

Radiology helped build the network. Now cardiology can benefit and build on that foundation

We are hosting a webinar on September 8th to share exactly this. Join us with our colleagues from St. Antonius to discuss how and why they are bringing cardiology image exchange onto their existing XDS infrastructure, including the architectural choices, connection process, and implementation considerations behind the approach.