MADO and DICOMweb: Understanding the new proposal for Manifest-based DICOM access

For the last decade, DICOMweb has been the quiet workhorse of modern medical imaging interoperability. It gave the industry what it badly needed: a simple, web-native way to query, retrieve and store medical images using HTTP instead of bespoke DICOM network protocols.

Recently, IHE published a draft supplement called Manifest-based Access to DICOM Objects (MADO). The draft supplement is available here: IHE RAD Suppl MADO (public comment). The document claims to fill a gap in imaging interoperability by introducing a standardised, manifest-based way to access imaging studies.

At first glance, that claim deserves scrutiny. After all, retrieving studies and images is exactly what DICOMweb already does. So what problem is MADO actually trying to solve?

To answer that, it is worth stepping back to explain how DICOMweb works, what it does not define, and where that leaves gaps in real-world exchange.

A Very Short Primer on DICOMweb

Traditional DICOM networking uses long-lived TCP connections and specialised protocols like C-FIND, C-MOVE and C-STORE. These work well inside hospital networks but are awkward across firewalls, clouds and organisations.

DICOMweb modernised this by defining RESTful APIs over HTTP:

• QIDO-RS allows you to query for studies, series or individual images based on metadata
• WADO-RS allows you to retrieve images, series or entire studies once you know their identifiers
• STOW-RS allows you to upload images

If you want a study, you typically query the archive to discover what studies exist, inspect the results to decide which series or images you want, and then retrieve those objects directly.

Inside a single organisation, or between tightly coupled systems, this model works extremely well.

What DICOMweb Does Not Address

DICOMweb is low-level and stateless. It assumes the client is allowed to see the archive, allowed to query it freely, and capable of deciding what to retrieve. It does not define:

• How discovery should work across organisations
• How consent or purpose-of-use should constrain retrieval
• How to represent a "snapshot" of what was shared at a specific time
• How imaging should integrate with document-centric or FHIR-based exchange models

DICOMweb focuses on transport and access. It does not address coordination or governance.

That is where MADO enters the picture.

What MADO Does

MADO introduces the concept of a manifest as a first-class object in imaging exchange.

A manifest is simply a structured list of the imaging objects that constitute "the study" for a given purpose. It can be expressed in two ways: as a DICOM Key Object Selection (KOS) document, or as a FHIR ImagingStudy resource.

The manifest is created upstream, typically by a system that has already performed discovery, authorisation, consent checks and policy enforcement.

The consumer does not query the imaging archive to discover content. Instead, it receives a manifest and uses it as the authoritative instruction set for retrieval. DICOMweb is still used, but only to execute the retrieval described by the manifest.

In other words, MADO does not replace DICOMweb. It constrains and orchestrates it.

Discovery Happens Elsewhere

In cross-enterprise exchange, discovery is often the hardest problem.

Many environments explicitly forbid external systems from running arbitrary queries against imaging archives. Network access may be indirect, mediated by brokers, national platforms or document registries. In these cases, discovery happens elsewhere, not at the archive.

MADO formalises that pattern. Discovery happens upstream. Retrieval happens downstream. The manifest is the contract between the two.

Without a standard for this, every platform invents its own way of handing around lists of SOP Instance UIDs, series identifiers or imaging metadata. MADO attempts to standardise that handoff.

FHIR and the ImagingStudy Resource

FHIR has become the lingua franca for clinical data exchange, but it has never been a good fit for large binary imaging objects.

The ImagingStudy resource sits in an awkward middle ground. It describes studies and series, but it is not a retrieval protocol. It also does not, by itself, define what is authoritative, complete or immutable.

MADO effectively says: a FHIR ImagingStudy can be more than descriptive metadata. It can be the manifest that defines exactly what images are to be retrieved.

This is important in FHIR-first ecosystems, where imaging needs to slot into workflows alongside referrals, reports and care plans. MADO is trying to align imaging with the document and resource-oriented mental model that already exists elsewhere in healthcare IT.

Immutability, Audit and Legal Defensibility

Another subtle problem MADO addresses is change over time.

DICOMweb queries are live views of an archive. Studies can be amended, series reprocessed, instances deprecated or replaced. If you retrieve "the study" today and again tomorrow, you may not get the same bytes.

A manifest represents a snapshot. It says "these exact objects, at this moment, were what was shared", and that matters for audit, medico-legal review, research reproducibility and regulatory compliance.

DICOMweb alone does not give you that guarantee.

MADO Is Only One Part of a Discovery and Access Layer

Many modern imaging platforms already operate this way. They perform discovery, consent and policy checks internally, and then hand downstream systems a curated list of objects to retrieve. The only difference is that the list is usually handed around implicitly, using proprietary APIs or undocumented conventions.

From that perspective, MADO is not introducing a new capability. It is attempting to standardise an existing pattern that emerges naturally once you move beyond simple PACS-to-viewer workflows.

The key insight is that retrieval is rarely the hard part. Coordination is.

Whether MADO becomes widely adopted or not, the underlying architectural shift is real. Imaging exchange is moving away from "query whatever you can see" toward "retrieve exactly what you are authorised to receive". MADO is one attempt to codify that shift, but it is only one part of what a complete discovery and access layer needs.

What Else Is Needed

If you take MADO at face value as a manifest format and retrieval contract, you still need the systems around it that create that contract, distribute it, and enforce it.

• Discovery services (or registries) that can tell you what exists, where it lives, and which organisation is responsible for it
• Patient and provider identity resolution, because cross-enterprise discovery without matching is usually not usable in practice
• Access control, consent, and purpose-of-use enforcement, because the manifest is only meaningful if it is issued under a policy that can be defended later
• A mechanism for credential and endpoint handoff (tokens, signed URLs, or equivalent), because "use DICOMweb" is not a security model on its own
• Audit, provenance, and retention rules that define how manifests and retrieval events are logged and how long that evidence needs to exist

This is also why MADO should be read as a layer component rather than a complete architecture. It describes one of the artefacts you need to move imaging between organisations safely, but it does not remove the need for the rest of the plumbing.

MADO in Harmony

At Runbeam, we sit squarely in the space MADO is targeting: cross-boundary imaging exchange, mediated connectivity, and policy-aware data movement.

We have already advocated for, and fully support, a manifest-based transfer mechanism for DICOM in the form of the JMIX protocol. JMIX also supports full data exchange, encryption, signing, and other security layers that are out of scope for MADO, and there is likely some work to be done to make the two approaches compatible at the manifest level.

In practical terms, Harmony already supports DICOM-to-DICOMweb bridging and transformation, which means you can implement a MADO-style flow today by generating a FHIR ImagingStudy manifest upstream and then using Harmony to drive downstream retrieval through DICOMweb.

---

Christopher Skene is the Co-Founder and CTO of Runbeam.