MADO: the imaging manifest becomes its own document

What was published

IHE Radiology has published Manifest-based Access to DICOM Objects. It reached Trial Implementation on 16 March 2026, and the current text is revision 1.2, dated 20 August 2026, active on the publications site from 3 September. The FHIR implementation guide beside it is version 1.0.0, marked trial-use, built on R4.

It did not arrive the usual way. The profile was drafted inside EURIDICE, a joint effort of HL7 Europe and IHE-Europe, at the request of the Xt-EHR joint action, which had been asked to turn the European Health Data Space into technical specifications. The supplement says so in its own scope: the need for this profile was identified as part of the sharing of imaging studies and related reports as required under the EHDS Regulation.

That is worth holding onto. MADO is a European regulatory artefact that happens to be a good general-purpose profile, rather than a general-purpose profile Europe later adopted.

The seam it cuts

A clinical imaging report is a statement about a patient, made by a named person, at a moment in time. It is signed, it is registered, and it does not change: when the finding changes, a new version is issued and the old one is kept. A retrieve address is the opposite kind of fact. It changes whenever an archive is migrated, a hostname is re-pointed, a data centre is consolidated or a vendor is replaced.

Put both in the same signed payload and every infrastructure change becomes a document event. The bytes that were signed have changed, so the signature over them no longer verifies, and the document has to be re-issued and re-registered. The number of documents affected is the number of studies in the archive.

MADO makes the manifest a document in its own right. The report says what was found. The manifest says what exists and where it can be fetched from. They are linked, versioned independently, and the one that changes when infrastructure changes is the one that was cheap to change.

There is a second consequence, and it shows up in a support queue rather than in an architecture review. When the content of a shared study is updated to add or remove instances, the Content Creator shall publish a new manifest and deprecate the previous one. A manifest is a claim about a moment, and saying so is what stops a consumer treating a two-year-old inventory as current.

Three actors, one transaction

The profile is unusually small. A Content Creator produces the manifest, deciding which part of the local study to publish and guaranteeing that everything it references is available when it publishes. An Imaging Document Consumer parses a manifest, picks what it wants and issues the retrieve. An Imaging Document Source answers it, and may return only what was published even when the request names a whole study.

There is deliberately no Content Consumer actor. The supplement says why: the Imaging Document Consumer is the consuming partner of the Content Creator, which keeps the profile small and matches what XDS-I.b already did.

The single transaction is WADO-RS Retrieve, [RAD-107], required in the Requester role on the consumer and the Responder role on the source. Everything else the profile does, it does through the shape of the content rather than through new messages on the wire.

Read the first two rows together. A producer has to be able to do both encodings; a consumer only has to do one. The cost of the dual-format world sits on the side that publishes, which is the side that can afford it, and a consumer product can implement the format its ecosystem actually uses without failing conformance.

What the manifest carries

An XDS-I.b manifest is close to a bare list of identifiers: study, series and SOP instance UIDs, and a retrieve location. It answers which objects exist and little else, so a consumer that wants to know which of nine series is worth pulling finds out by pulling them.

The MADO manifest extends that definition with modalities, anatomic regions, accession and placer order numbers, procedure codes, series number, description and date-time, instance and frame counts, and the Key Image Note title code that flags the significant images. The stated purpose is retrieval economics: identify the series and instances of interest, and retrieve those instead of the whole study.

Put that in units. A multi-phase CT is routinely several gigabytes across a dozen series. A manifest that lets a consumer identify the two series it needs turns a multi-gigabyte transfer into a few hundred megabytes. Across a regional network that is not a performance optimisation. It is the difference between a workflow people use and one they abandon.

Two encodings, and the mapping between them

MADO defines the same manifest in two formats and specifies the transformation in both directions.

The DICOM KOS-based format encodes it as a Key Object Selection document in the PS3.10 file format. It is what an existing imaging estate can produce today, and it is backward compatible with the XDS-I.b manifest. In an XDS-I.b deployment it is not a choice: the format the Content Creator uses must be the KOS-based one, which constrains the Imaging Document Source in that community to match.

The FHIR-based format encodes it as a Bundle of type document. That is the format that fits a network already speaking MHD, and the one a browser client can read without a DICOM library.

Neither is a migration path away from the other. They are two views of one object, which is the pragmatic answer to a two-decade transition: a hospital does not have to pick the year it becomes FHIR-native.

{
  "system": "urn:dicom:uid",
  "value": "1.2.840.113619.2.55.3.2831183778"
}

{
  "type": { "coding": [{ "code": "ACSN" }] },
  "system": "urn:oid:1.2.3.4.5",
  "value": "A-2026-0099413"
}

{
  "subject": { "reference": "Patient/pat-1" }
}

{
  "url": ".../StructureDefinition/anatomical-region",
  "valueCodeableConcept": {
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "774007",
      "display": "Structure of head and/or neck"
    }]
  }
}

{
  "uid": "1.2.840.113619.2.55.3.2831183778.1",
  "modality": {
    "system": "http://dicom.nema.org/resources/ontology/DCM",
    "code": "CT"
  },
  "numberOfInstances": 412
}

{
  "endpoint": [{ "reference": "#wado-1" }],
  "resource": {
    "resourceType": "Endpoint",
    "address": "https://example.org/dcm4chee-arc/aets/DCM4CHEE/rs"
  }
}

The document, opened

The FHIR encoding is a Bundle with type fixed to document. That is not cosmetic. A FHIR document is a closed, self-contained set: the first entry must be a Composition, everything it refers to travels inside it, and the whole thing can be signed as one object. It is a snapshot, which is what a manifest is.

The Composition is easy to read as ceremony around the real payload, and it is the opposite. Its narrative is what a system with no imaging integration at all still renders for a clinician: patient, date, modalities, regions. It is the difference between a manifest that degrades gracefully in a mixed estate and one that is inert outside the systems built for it.

Retrieval asks for less than you expect

MADO reuses an existing transaction rather than inventing one, and then asks less of it than the profiles beside it do. WADO-RS Retrieve defines four request and response pairs. A Requester shall support at least one; a Responder shall support all four, as defined in DICOM. Each profile then narrows that, and MADO narrows it hardest.

The supplement is explicit that MADO does not require retrieval of Metadata, Pixel Data or Bulk Data resources at all. One message pair against three resource levels is the whole obligation. Anyone writing a tender should notice: demanding the full four specifies a different profile than the one they meant.

Two details cost implementers real time. First, a consumer shall implement both ways of getting the base URI: the Retrieve URL carried in the manifest, and the Retrieve Location UID resolved through a lookup service that sits outside the profile. Second, a consumer requesting a series or study resource shall handle a larger or smaller number of instances than it expected. The manifest is a snapshot and the archive is live. Code that treats a count mismatch as an error will raise one against a correctly behaving system, in the first week.

What Europe adds, and what is still moving

The EHDS Regulation makes medical imaging studies and related imaging reports one of its priority categories, in Article 14. The dates are staged, and the staging is the part that gets misreported: the Regulation starts to apply on 26 March 2027, the first group of categories and the secondary use provisions land on 26 March 2029, and imaging, laboratory results and discharge reports follow on 26 March 2031.

Five years is not breathing room. It is roughly one procurement cycle plus one replacement cycle for a regional archive, so the estates that are ready in 2031 are the ones writing MADO into tenders in 2027. The systems being bought now are the systems that will be running then.

The European layer on top of the profile is less settled than the coverage suggests. The HL7 Europe EU extensions guide is a continuous build, version 0.2.1-build, carrying the standard warning that it changes regularly and is not an authorised publication. An earlier HL7 Europe R5 draft of the same profile says outright that it is not yet recommended for production use, and that it is being transferred to IHE Radiology.

Two specific divergences are worth knowing about, because they produce validator failures that look like implementation bugs. The IHE profile fixes identifier.system to urn:dicom:uid and carries the bare study UID as the value; the HL7 Europe R5 draft adds an invariant requiring that value to begin ihe:urn:oid:, a prefix that appears nowhere in the IHE text. And the anatomical region extension, which several summaries report as escalated in Europe to mandatory with a required binding, is 0..* preferred in the IHE base and 0..1 with an example binding in the R5 draft. That is looser, not tighter.

None of which is a reason to wait. It is a reason to build against the IHE supplement, pin revision numbers rather than guide names, and re-validate on every revision.

What to do about it now

The profile was tested at IHE-Europe Connectathon Week in Brussels from 23 to 27 March 2026, with the Xt-EHR Projectathon inside it from the 24th to the 26th, days after the Trial Implementation was published. The next European test week is 19 to 23 April 2027 in The Hague. That is the calendar an implementation plan hangs off.

Before then, five questions decide whether an estate is in a position to take part at all. None of them is a maturity score. Each is an obligation the supplement places on an actor.

The short version for anyone deciding where to spend attention: the retrieve endpoint is the hard prerequisite, the dual-encoding capability is the conformance trap, and the manifest lifecycle is the thing nobody budgets for and everybody needs. Discovery is somebody else in your organisation, and if it is nobody, the chain has no first link.

Then read the supplement. It is free, sixty-six pages, and specific, and the difference between shall support all four message pairs and shall support Get Instances is the difference between two procurement documents.

If you want the whole profile in one place, MADO 101: The Manifest Becomes Its Own Document is the paper behind this piece. It works through the actors and their obligations, both encodings and the mapping between them, the FHIR document and the KOS document attribute by attribute, cross-community retrieval, the EHDS dates, and nine failure modes worth writing into a test plan. It is free at /resources/mado-101.