Manifest-based Access to DICOM Objects (MADO), published by IHE Radiology Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/RAD.MADO/ and changes regularly. See the Directory of published versions

Manifest Envelopes for IHE-MHD

The following MHD DocumentReferences SHALL be used when distributing a MADO Imaging Manifest in an IHE-ITI-MHD environment:

• MADO FHIR Minimal DocumentReference for FHIR Manifests
• MADO DICOM KOS Minimal DocumentReference for DICOM KOS Manifests

An IHE-MHD infrastructure may choose to implement an mapping service between the two manifest formats. When such a mapping service is supported, the address field in the unsupported DocumentReference MAY include a fully populated url to the mapping service that will return the translated document.

In the case the manifest is available in multiple formats, the Document Consumer SHOULD show to the user a single entry chosen by the implementation.

As is stated in section X.6.1, Manifest Creators SHALL create the manifest in the format of their choice. The selection is made at deployment time (see section X.6.1 for more detail).

The figure below shows the MHD DocumentReferences including the most relevant restrictions and its relationship with the manifests and each other.

The main choices illustrated in the figure are:

• There are two different DocumentReferences, one for the FHIR and one for the DICOM KOS representation. When both are present, the relatesTo field points to the other representation.
• FHIR manifest:
  • A FHIR manifest is represented as a FHIR json encoded FHIR Bundle following the profile MADO FHIR Bundle. This Bundle contains the ImagingStudy resource as well other resources such as the Patient and various Endpoints.
  • The FHIR DocumentReference SHALL have the identifier of the MADO FHIR Bundle as masterIdentifier.
• DICOM KOS manifest:
  • A KOS manifest is represented as a application/dicom encoded DICOM instance (see 8.7.3.1 Instance Media Types) following the MADO KOS profile.
  • The KOS manifest DocumentReference SHALL have include the SOPInstanceUid of the KOS instance as masterIdentifier.
• The masterIdentifier SHALL be part of the identifier list as well.

The FHIR-manifest can be translated into the KOS-manifest and vice-versa allowing applications to change the representation when needed.

Related FHIR profiles

Capability Statements

Imaging specific search parameters

Imaging specific search parameters include:

The expression below uses these search parameters to search for a FHIR manifest with StudyInstanceUid=324.232.5.5.324.2.

DocumentReference/?study-instance-uid=urn:oid:324.232.5.5.324.2&format=urn:ihe:rad:MADO:fhir-manifest:2026

This uses the optional study-instance-uid search parameter. An alternative with standard search params would be. As the study instance uid is an OID, in the identifier it is prefixed with urn:oid:.

DocumentReference/?related:identifier=urn:oid:324.232.5.5.324.2&format=urn:ihe:rad:MADO:fhir-manifest:2026

A similar query searching for DICOM KOS Manifests with accession number 12345 would look like:

DocumentReference/?related:identifier="12345"&format=1.2.840.10008.5.1.4.1.1.88.59

an alternative using the accession-number query is:

DocumentReference/?accession-number="12345"&format=1.2.840.10008.5.1.4.1.1.88.59

DocumentReference examples

The list below presents various examples of MADO DocumentReferences.

The DocumentReference Example for FHIR manifests with transform example contains a FHIR MADO DocumentReference. The content section does not point to a FHIR file but to a transform service. The content.attachment section is presented below

{
  "contentType" : "application/fhir+json",
  "language" : "de-DE",
  "url" : "http://kos2FhirTranformService.example.com/transform?url=http://mhdserver.example.com/Binary/mado-kos-manifest-binary",
  "creation" : "2025-05-08T00:00:00Z"
}

The url points to a transform service and passes the link to the KOS manifest. This is just one example of such service. This specification does not specify the interface. Alternative implementations could could pass the StudyInstanceUID and wado URL parameters, or some other set of data.