MADO, published by Example Publisher. 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/oijauregui/MADO-through-FHIR-Publisher/ and changes regularly. See the Directory of published versions

MADO Profile Documentation

MADO Profile Documentation

Introduction to this Supplement

Introduction to MADO Supplement

Manifest-based Access to DICOM Objects (MADO)

This supplement describes the Manifest-based Access to DICOM Objects (MADO) profile for the IHE Radiology Technical Framework.

Purpose

The MADO profile defines mechanisms for manifest-based access to DICOM objects, enabling efficient retrieval and management of imaging studies through standardized manifest structures.

Document Status

• Revision: 0.4 – Draft in Preparation for Public Comment
• Date: August 18, 2025
• Author: IHE-HL7 Europe Sub-team on imaging manifest

Note: This document is prepared to become a future supplement to the IHE Radiology Technical Framework. It anticipates the acceptance of a new profile proposal submitted on July 20th 2025 to the IHE Radiology 2025-2026 Cycle. It is developed by the IHE-HL7 Europe Working Group on Imaging with the goal to use this new profile in the context of the EHDS use case on the sharing of imaging studies and related imaging reports.

FHIR Information

• HL7® FHIR® STU x: Using Resources at FMM Level n-n

Document Development Context

This supplement is intended to be a supplement to the IHE Radiology Technical Framework V22.0. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.

For review and comment only. DO NOT implement this public comment version.

Profile Overview

The profile structure includes:

1. Volume 1: Profile overview in terms of Actor/Transactions, the overall use case and associated scenarios. Volume 1 states the required and optional transactions, as well as the required/optional grouping.

   • Document Creator Actor: Produces the Imaging Manifest with a "convey manifest content" transaction to a "Document Consumer Actor"
   • Convey Manifest Transaction with two options:
     • DICOM KOS Based Manifest option
     • FHIR Based Manifest option
   • Imaging Document Consumer Actor: Issues the WADO Retrieve Transaction to the Imaging Document Source Actor

2. Volume 2: Chapter on the WADO-RS Retrieve Transaction

3. Volume 3: Chapter on the Manifest content including:

   • Section A: DICOM KOS based Manifest
   • Section B: FHIR based Manifest
   • Section C: Mapping between A and B (for information)

Links and References

• General IHE Information: IHE.net
• IHE Radiology Domain: IHE Domains
• Current Radiology Technical Framework: Radiology Technical Framework
• Public Comments: Radiology Public Comments

Comment Period

This supplement is published for Public Comment. Comments are invited and must be received by the specified deadline to be considered in development of the Trial Implementation version of the supplement.

Volume 1 – Profiles

Manifest-based Access to DICOM Objects (MADO) Profile

59.1 MADO Actors, Transactions, and Content Modules

The MADO profile defines the following actors, transactions, and content modules for manifest-based access to DICOM objects.

Actors

The MADO profile includes the following actors:

• Content Creator: Creates and manages imaging manifests
• Content Consumer: Consumes and processes imaging manifests
• Imaging Document Consumer: Retrieves imaging documents based on manifest information
• Imaging Document Source: Provides imaging documents for retrieval

Transactions

The MADO profile defines the following transactions:

• Convey Manifest Content [RAD-TBD]: Transaction for conveying manifest content between Content Creator and Content Consumer
• WADO-RS Get Instances [RAD-1xy]: Transaction for retrieving DICOM instances

Content Modules

The profile defines content modules for:

• DICOM Key Object Selection (KOS) based manifests
• FHIR-based manifests
• Mapping specifications between DICOM and FHIR formats

Actor Descriptions and Requirements

Content Creator

The Content Creator actor is responsible for:

• Creating imaging manifests in either DICOM KOS format or FHIR format
• Managing manifest content and metadata
• Conveying manifest content to Content Consumer actors

Profile Requirements: The Content Creator shall support at least one of the manifest format options (DICOM KOS or FHIR).

Content Consumer

The Content Consumer actor is responsible for:

• Receiving and processing imaging manifests
• Interpreting manifest content for subsequent imaging retrieval operations
• Supporting both DICOM KOS and FHIR manifest formats as applicable

Profile Requirements: The Content Consumer shall be grouped with an Imaging Document Consumer for actual image retrieval.

Imaging Document Consumer

The Imaging Document Consumer actor is responsible for:

• Issuing WADO-RS retrieve transactions based on manifest information
• Managing the retrieval of DICOM instances and rendered content
• Processing retrieved imaging content

Profile Requirements: This actor shall be grouped with a Content Consumer actor.

Imaging Document Source

The Imaging Document Source actor is responsible for:

• Responding to WADO-RS retrieve requests
• Providing DICOM instances and rendered imaging content
• Supporting various retrieve options and formats

MADO Actor Options

Option Name

[Options to be defined based on specific implementation requirements]

MADO Required Actor Groupings

The following actor groupings are required:

• Content Consumer shall be grouped with Imaging Document Consumer
• Additional groupings may be defined based on implementation scenarios

MADO Overview

Concepts

Intra-community Sharing Infrastructure

The MADO profile operates within intra-community sharing infrastructures to enable efficient access to imaging studies through manifest-based approaches.

Imaging Reports

The profile considers the relationship between imaging manifests and associated imaging reports, enabling comprehensive access to imaging-related information.

DICOMweb Study Service Retrieve Transaction URI

The profile leverages DICOMweb standards for study service retrieve operations, providing standardized URIs for accessing imaging content.

Use Cases

Use Case #1: DICOM Instance Retrieval

Instance Retrieval Use Case Description

This use case describes the process of retrieving DICOM instances based on manifest information.

Actors Involved:

• Content Creator
• Content Consumer
• Imaging Document Consumer
• Imaging Document Source

Basic Flow:

1. Content Creator generates an imaging manifest
2. Content Consumer receives and processes the manifest
3. Imaging Document Consumer uses manifest information to request specific DICOM instances
4. Imaging Document Source provides the requested instances

Instance Retrieval Process Flow

Pre-conditions

• Imaging studies are available in the Imaging Document Source
• Content Creator has access to study metadata for manifest creation
• Network connectivity exists between all actors

Main Flow

1. Manifest Creation: Content Creator creates an imaging manifest containing references to relevant DICOM instances
2. Manifest Transmission: Content Creator transmits the manifest to Content Consumer via Convey Manifest Content transaction
3. Manifest Processing: Content Consumer processes the manifest and extracts instance reference information
4. Instance Retrieval: Imaging Document Consumer issues WADO-RS Get Instances requests to Imaging Document Source
5. Instance Delivery: Imaging Document Source responds with requested DICOM instances

Post-conditions

• Requested DICOM instances are successfully retrieved
• Content Consumer has access to both manifest information and actual imaging content
• Audit logs are generated as appropriate

MADO Security Considerations

The MADO profile shall address the following security considerations:

• Authentication and authorization for manifest access
• Secure transmission of manifest content
• Access control for imaging document retrieval
• Audit logging of manifest and retrieval operations
• Privacy protection for patient information in manifests

MADO Cross Profile Considerations

The MADO profile may interact with other IHE profiles including:

• XDS/XCA: For document sharing infrastructure
• ATNA: For audit and security requirements
• PIX/PDQ: For patient identity management
• XUA: For user authentication assertions

Additional considerations for cross-profile interactions will be defined based on implementation requirements.

Volume 2 – Transactions

MADO Transactions

3.1xy WADO-RS Get Instances [RAD-1xy]

3.1xy.1 Scope

This transaction is used by the Imaging Document Consumer to retrieve DICOM instances from the Imaging Document Source using WADO-RS (Web Access to DICOM Objects - RESTful Services).

3.1xy.2 Actor Roles

3.1xy.3 Referenced Standards

• DICOM PS3.18: Web Services
• RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
• RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
• RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
• RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
• RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
• RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication

3.1xy.4 Messages

This transaction involves the following message exchanges:

1. Get Instances Request/Response
2. Get Rendered Instances Request/Response

3.1xy.4.1 Get Instances Request Message

3.1xy.4.1.1 Trigger Events

The Imaging Document Consumer triggers this message when:

• A manifest indicates the need to retrieve specific DICOM instances
• The consumer needs to access raw DICOM data for processing
• Clinical workflow requires access to original imaging data

3.1xy.4.1.2 Message Semantics

The Get Instances Request follows the DICOM WADO-RS specification for instance retrieval.

HTTP Method: GET

Request URL Format:

{service}/studies/{studyUID}/series/{seriesUID}/instances/{instanceUID}

Query Parameters:

• accept: Specifies the acceptable media types for the response
• transferSyntax: Optionally specifies the desired transfer syntax

HTTP Headers:

• Accept: Specifies acceptable content types (e.g., application/dicom)
• Authorization: Contains authentication credentials if required

3.1xy.4.1.2.1 Example of a Get Instances Request Message

GET /wado-rs/studies/1.2.840.113619.2.55.3.604688119.971.1234567890.123/series/1.2.840.113619.2.55.3.604688119.971.1234567890.456/instances/1.2.840.113619.2.55.3.604688119.971.1234567890.789 HTTP/1.1
Host: example-pacs.hospital.org
Accept: application/dicom
Authorization: Bearer <token>
User-Agent: MADO-Client/1.0

3.1xy.4.1.3 Expected Actions

The Imaging Document Consumer shall:

1. Construct a valid WADO-RS GET request URL
2. Include appropriate Accept headers for DICOM content
3. Handle authentication as required by the Imaging Document Source
4. Process the response according to HTTP status codes
5. Validate received DICOM instances

3.1xy.4.2 Get Instances Response Message

3.1xy.4.2.1 Trigger Events

The Imaging Document Source generates this response upon receiving a valid Get Instances Request.

3.1xy.4.2.2 Message Semantics

HTTP Status Codes:

• 200 OK: Instance successfully retrieved
• 206 Partial Content: Partial instance content (if range requests are used)
• 400 Bad Request: Invalid request parameters
• 401 Unauthorized: Authentication required or failed
• 403 Forbidden: Access denied
• 404 Not Found: Requested instance not found
• 500 Internal Server Error: Server error occurred

Response Headers:

• Content-Type: application/dicom or multipart/related
• Content-Length: Size of the response body
• ETag: Entity tag for caching support

Response Body:

• DICOM instance data in the requested format

3.1xy.4.2.3 Expected Actions

The Imaging Document Source shall:

1. Validate the request parameters
2. Authenticate the requester if required
3. Authorize access to the requested instance
4. Return the DICOM instance in the requested format
5. Generate appropriate audit logs

3.1xy.4.3 Get Rendered Instances Request Message

3.1xy.4.3.1 Trigger Events

The Imaging Document Consumer triggers this message when:

• Rendered imaging content is needed for display purposes
• The consumer requires images in web-friendly formats
• Clinical applications need processed/rendered image data

3.1xy.4.3.2 Message Semantics

HTTP Method: GET

Request URL Format:

{service}/studies/{studyUID}/series/{seriesUID}/instances/{instanceUID}/rendered

Query Parameters:

• accept: Specifies acceptable media types (e.g., image/jpeg, image/png)
• viewport: Specifies the viewport dimensions
• window: Specifies window/level parameters
• quality: Specifies compression quality for JPEG

HTTP Headers:

• Accept: Specifies acceptable image formats
• Authorization: Contains authentication credentials if required

3.1xy.4.3.2.1 Example of a Get Rendered Instances Request Message

GET /wado-rs/studies/1.2.840.113619.2.55.3.604688119.971.1234567890.123/series/1.2.840.113619.2.55.3.604688119.971.1234567890.456/instances/1.2.840.113619.2.55.3.604688119.971.1234567890.789/rendered?viewport=512,512&window=350,40 HTTP/1.1
Host: example-pacs.hospital.org
Accept: image/jpeg
Authorization: Bearer <token>
User-Agent: MADO-Client/1.0

3.1xy.4.3.3 Expected Actions

The Imaging Document Consumer shall:

1. Construct a valid WADO-RS GET request for rendered content
2. Specify appropriate rendering parameters
3. Handle various image format responses
4. Process rendered images for display or further processing

3.1xy.4.4 Get Rendered Instances Response Message

3.1xy.4.4.1 Trigger Events

The Imaging Document Source generates this response upon receiving a valid Get Rendered Instances Request.

3.1xy.4.4.2 Message Semantics

HTTP Status Codes: Similar to Get Instances Response

Response Headers:

• Content-Type: Image media type (e.g., image/jpeg, image/png)
• Content-Length: Size of the image data

Response Body:

• Rendered image data in the requested format

3.1xy.4.4.3 Expected Actions

The Imaging Document Source shall:

1. Render the DICOM instance according to request parameters
2. Return the rendered image in the requested format
3. Apply appropriate image processing (windowing, scaling, etc.)
4. Generate audit logs for rendered content access

3.1xy.5 Protocol Requirements

• Transport Protocol: HTTP/1.1 or HTTP/2
• Security: TLS 1.2 or higher for secure communications
• Authentication: Support for standard HTTP authentication mechanisms
• Content Types: Support for application/dicom and standard image formats

3.1xy.6 Security Considerations

3.1xy.6.1 Security Audit Considerations

All WADO-RS transactions shall be audited according to ATNA requirements:

• Event ID: DICOM Instance Retrieved
• Event Action Code: Read (R)
• Event Outcome: Success/Failure indication
• User Identity: Identity of the requesting user/system
• Patient Identity: Patient associated with retrieved instances
• Study Identity: Study UID of retrieved instances

3.1xy.6.2 Imaging Document Consumer Specific Security Considerations

The Imaging Document Consumer shall:

• Implement secure authentication mechanisms
• Validate server certificates when using TLS
• Protect retrieved DICOM data according to organizational policies
• Implement appropriate access controls for manifest-driven retrieval

3.1xy.6.3 Imaging Document Source Specific Security Considerations

The Imaging Document Source shall:

• Implement robust authentication and authorization
• Validate all request parameters to prevent injection attacks
• Log all access attempts and their outcomes
• Implement rate limiting to prevent abuse
• Ensure proper handling of patient privacy information

Volume 3 – Content Modules

MADO Content Modules

5 IHE Namespaces, Concept Domains and Vocabularies

5.1 IHE MADO Namespaces

The MADO profile defines the following namespaces:

5.2 IHE MADO Concept Domains

The following concept domains are defined for the MADO profile:

5.3 IHE MADO Format Codes and Vocabularies

5.3.1 IHE Format Codes

5.3.2 IHEActCode Vocabulary

5.3.3 IHERoleCode Vocabulary

5.3.4 Imaging Study Manifest Search Metadata

The following metadata elements support searching for imaging study manifests:

7 MADO DICOM Content Definitions

7.1 Conventions

7.1.1 DICOM Structured Report

The MADO profile utilizes DICOM Key Object Selection (KOS) documents as one format for imaging manifests. These documents follow the DICOM Structured Report framework.

7.1.2 Display Requirements

DICOM manifests shall support appropriate display mechanisms for human-readable presentation of manifest content.

7.2 General Definitions

Imaging Manifest: A document that contains references to one or more imaging studies, series, or instances, along with relevant metadata for retrieval and processing.

Key Object Selection (KOS): A DICOM object that identifies and describes a set of DICOM objects (studies, series, instances) for a specific purpose.

Manifest Consumer: An entity that processes imaging manifests to facilitate subsequent imaging retrieval operations.

7.3 IOD Definitions

7.3.1 Key Object Selection Document IODs

7.3.1.1 Key Object Selection Document IOD

7.3.1.1.1 Key Object Selection Document IOD MADO Context

####### 7.3.1.1.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions
• DICOM PS3.4: Service Class Specifications
• DICOM PS3.6: Data Dictionary

####### 7.3.1.1.1.2 IOD Definition

The Key Object Selection Document IOD for MADO purposes shall include the following modules:

Legend: M = Mandatory, U = User Defined, C = Conditional

7.4 Module Definitions

7.4.1 Key Object Selection Document Modules

7.4.1.1 Patient Module

7.4.1.1.1 Patient Module MADO Context

####### 7.4.1.1.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions, Section C.7.1.1

####### 7.4.1.1.1.2 Module Definition

Type Legend: 1 = Required, 2 = Required if known, 3 = Optional

Additional MADO Requirements:

• Patient ID shall be present for manifest-based retrieval scenarios
• Patient demographics should be consistent across referenced studies

7.4.1.2 General Study Module

7.4.1.2.1 General Study Module MADO Context

####### 7.4.1.2.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions, Section C.7.2.1

####### 7.4.1.2.1.2 Module Definition

MADO Requirements:

• Study Instance UID is mandatory for manifest-based retrieval
• Study metadata should support efficient filtering and selection

7.4.1.3 Key Object Document Series Module

7.4.1.3.1 Key Object Document Series Module MADO Context

####### 7.4.1.3.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions, Section C.17.6.1

####### 7.4.1.3.1.2 Module Definition

MADO Specifications:

• Modality shall be set to "KO" for Key Object Selection documents
• Series Instance UID shall be unique for each manifest document

7.4.1.4 General Equipment Module

7.4.1.4.1 General Equipment Module MADO Context

####### 7.4.1.4.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions, Section C.7.5.1

####### 7.4.1.4.1.2 Module Definition

MADO Requirements:

• Equipment information should identify the system creating the manifest

7.4.1.5 Key Object Document Module

7.4.1.5.1 Key Object Document Module MADO Context

####### 7.4.1.5.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions, Section C.17.6.2

####### 7.4.1.5.1.2 Module Definition

Current Requested Procedure Evidence Sequence Items:

Referenced Series Sequence Items:

Referenced SOP Sequence Items:

MADO Specifications:

• Current Requested Procedure Evidence Sequence shall contain all studies referenced in the manifest
• Referenced SOP Sequence may be used to specify individual instances when needed

7.4.1.6 SR Document Content Module

7.4.1.6.1 SR Document Module MADO Context

####### 7.4.1.6.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions, Section C.17.3

####### 7.4.1.6.1.2 Module Definition

MADO Content Structure:

• Root content item shall have concept name "MADO Manifest"
• Child content items shall describe manifest purpose and scope
• Referenced studies and selection criteria should be documented

7.4.1.7 SOP Common Module

7.4.1.7.1 SOP Common Module MADO Context

####### 7.4.1.7.1.1 Referenced Standards

• DICOM PS3.3: Information Object Definitions, Section C.12.1

####### 7.4.1.7.1.2 Module Definition

MADO Requirements:

• SOP Class UID shall be "1.2.840.10008.5.1.4.1.1.88.59" (Key Object Selection Document Storage)
• SOP Instance UID shall be unique for each manifest document

8 MADO HL7 FHIR Content Definitions

The MADO profile supports FHIR-based manifests using the following resource types:

8.1 ImagingStudy Resource

The ImagingStudy resource is used to represent imaging studies referenced in FHIR-based manifests.

Key Elements:

• identifier: Study identifiers including Study Instance UID
• status: Status of the imaging study
• subject: Reference to the Patient
• encounter: Reference to the encounter context
• started: Date/time when study was started
• series: Series within the study
• endpoint: DICOM endpoints for retrieval

8.2 List Resource

The List resource serves as the primary manifest container for FHIR-based implementations.

Key Elements:

• status: Status of the manifest list
• mode: Mode of the list (typically "working")
• title: Human-readable title for the manifest
• code: Code identifying this as an imaging manifest
• subject: Reference to the Patient
• date: Date the manifest was created
• source: Creator of the manifest
• entry: References to ImagingStudy resources

8.3 Endpoint Resource

The Endpoint resource defines DICOM endpoints for image retrieval.

Key Elements:

• status: Endpoint status
• connectionType: Type of connection (e.g., DICOM WADO-RS)
• address: Base URL for the endpoint
• payloadType: Supported payload types

9 MADO DICOM – FHIR Manifest Mapping Specification

9.1 Overview

This section defines the mapping between DICOM KOS-based manifests and FHIR-based manifests to enable interoperability between the two formats.

9.2 DICOM to FHIR Mapping

9.3 FHIR to DICOM Mapping

9.4 Mapping Implementation Considerations

• Identifier Handling: Ensure consistent identifier mapping between formats
• Date/Time Conversion: Handle timezone and precision differences appropriately
• Reference Resolution: Maintain referential integrity across format boundaries
• Extension Handling: Define extensions for FHIR elements without DICOM equivalents

Appendices

Appendices to MADO Profile

Appendix A – Implementation Examples

A.1 DICOM KOS Manifest Example

A.1.1 Sample DICOM KOS Document Structure

The following example shows the structure of a DICOM Key Object Selection document used as an imaging manifest in the MADO profile:

Key Object Selection Document
├── Patient Module
│   ├── Patient's Name: "DOE^JOHN"
│   ├── Patient ID: "12345"
│   ├── Patient's Birth Date: "19800101"
│   └── Patient's Sex: "M"
├── General Study Module
│   ├── Study Instance UID: "1.2.840.113619.2.55.3.604688119.971.1234567890.123"
│   ├── Study Date: "20250819"
│   ├── Study Time: "143000"
│   └── Accession Number: "ACC12345"
├── Key Object Document Series Module
│   ├── Modality: "KO"
│   ├── Series Instance UID: "1.2.840.113619.2.55.3.604688119.971.1234567890.456"
│   └── Series Number: "1"
├── Key Object Document Module
│   └── Current Requested Procedure Evidence Sequence
│       └── Study Instance UID: "1.2.840.113619.2.55.3.604688119.971.1234567890.123"
│           └── Referenced Series Sequence
│               ├── Series Instance UID: "1.2.840.113619.2.55.3.604688119.971.1234567890.789"
│               └── Referenced SOP Sequence
│                   ├── Referenced SOP Class UID: "1.2.840.10008.5.1.4.1.1.2"
│                   └── Referenced SOP Instance UID: "1.2.840.113619.2.55.3.604688119.971.1234567890.101"
└── SR Document Content Module
    └── Content Item: "MADO Manifest for Emergency Review"

A.2 FHIR Manifest Example

A.2.1 Sample FHIR List Resource for Imaging Manifest

{
  "resourceType": "List",
  "id": "mado-manifest-example",
  "meta": {
    "profile": [
      "http://ihe.net/fhir/mado/StructureDefinition/ImagingManifestList"
    ]
  },
  "status": "current",
  "mode": "working",
  "title": "Emergency Imaging Review Manifest",
  "code": {
    "coding": [
      {
        "system": "http://ihe.net/fhir/mado",
        "code": "imaging-manifest",
        "display": "Imaging Manifest"
      }
    ]
  },
  "subject": {
    "reference": "Patient/patient-example"
  },
  "date": "2025-08-19T14:30:00Z",
  "source": {
    "reference": "Device/manifest-creator"
  },
  "entry": [
    {
      "item": {
        "reference": "ImagingStudy/chest-ct-study"
      }
    }
  ]
}

Associated ImagingStudy Resource:

{
  "resourceType": "ImagingStudy",
  "id": "chest-ct-study",
  "identifier": [
    {
      "use": "official",
      "system": "urn:dicom:uid",
      "value": "urn:oid:1.2.840.113619.2.55.3.604688119.971.1234567890.123"
    }
  ],
  "status": "available",
  "subject": {
    "reference": "Patient/patient-example"
  },
  "started": "2025-08-19T10:00:00Z",
  "numberOfSeries": 1,
  "numberOfInstances": 150,
  "series": [
    {
      "uid": "1.2.840.113619.2.55.3.604688119.971.1234567890.789",
      "modality": {
        "system": "http://dicom.nema.org/resources/ontology/DCM",
        "code": "CT"
      },
      "numberOfInstances": 150,
      "endpoint": [
        {
          "reference": "Endpoint/wado-rs-endpoint"
        }
      ]
    }
  ]
}

Appendix B – Security Considerations

B.1 Authentication Methods

The MADO profile supports the following authentication methods:

B.1.1 Bearer Token Authentication

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

B.1.2 Basic Authentication

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

B.1.3 Certificate-based Authentication

Client certificates may be used for mutual TLS authentication in high-security environments.

B.2 Access Control Patterns

B.2.1 Role-Based Access Control (RBAC)

• Radiologist: Full access to all imaging content
• Referring Physician: Access to studies for their patients
• Technologist: Access to create and modify manifests
• Administrator: System configuration and audit access

B.2.2 Attribute-Based Access Control (ABAC)

Access decisions based on:

• User attributes (role, department, location)
• Resource attributes (study type, patient consent)
• Environmental attributes (time of access, network location)

B.3 Audit Requirements

All MADO transactions shall generate audit events including:

• Manifest Creation: Who created what manifest, when
• Manifest Access: Who accessed which manifest, when
• Image Retrieval: What images were retrieved based on manifest
• Access Denied: Failed access attempts and reasons

B.3.1 Sample Audit Event

{
  "resourceType": "AuditEvent",
  "type": {
    "system": "http://dicom.nema.org/resources/ontology/DCM",
    "code": "110100",
    "display": "Application Activity"
  },
  "action": "R",
  "recorded": "2025-08-19T14:30:00Z",
  "outcome": "0",
  "agent": [
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/extra-security-role-type",
            "code": "humanuser"
          }
        ]
      },
      "who": {
        "identifier": {
          "value": "radiologist@hospital.org"
        }
      }
    }
  ],
  "source": {
    "site": "MADO-System",
    "identifier": {
      "value": "urn:oid:1.2.3.4.5.6.7.8.9.10"
    }
  },
  "entity": [
    {
      "what": {
        "identifier": {
          "value": "1.2.840.113619.2.55.3.604688119.971.1234567890.123"
        }
      },
      "type": {
        "system": "http://terminology.hl7.org/CodeSystem/audit-entity-type",
        "code": "2",
        "display": "System Object"
      },
      "role": {
        "system": "http://terminology.hl7.org/CodeSystem/object-role",
        "code": "1",
        "display": "Patient"
      }
    }
  ]
}

Appendix C – Implementation Guidelines

C.1 Performance Considerations

C.1.1 Manifest Size Optimization

• Selective References: Include only necessary studies/series/instances
• Metadata Filtering: Include only essential metadata elements
• Compression: Use appropriate compression for large manifests

C.1.2 Caching Strategies

• Manifest Caching: Cache frequently accessed manifests
• Metadata Caching: Cache study/series metadata separately
• Image Caching: Implement tiered caching for images

C.2 Error Handling

C.2.1 Common Error Scenarios

C.2.2 Error Response Format

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "not-found",
      "details": {
        "text": "Referenced study 1.2.3.4.5 not found"
      },
      "location": [
        "ImagingStudy.identifier"
      ]
    }
  ]
}

C.3 Testing and Validation

C.3.1 Manifest Validation

• Structure Validation: Verify DICOM/FHIR conformance
• Reference Validation: Ensure all references are valid
• Metadata Validation: Check required metadata presence

C.3.2 Integration Testing

• End-to-End Workflows: Test complete manifest-to-retrieval workflows
• Cross-Format Testing: Validate DICOM-FHIR interoperability
• Performance Testing: Verify performance under load

C.3.3 Conformance Testing

Systems implementing MADO shall support:

• Standard conformance testing suites
• Interoperability testing events
• Certification processes as defined by IHE

Appendix D – Use Case Scenarios

D.1 Clinical Decision Support

Scenario: A clinical decision support system needs to retrieve relevant prior imaging studies for comparison with current studies.

Flow:

1. CDS system creates manifest with relevant prior studies
2. Manifest includes selection criteria and study priorities
3. Imaging consumer retrieves studies based on manifest
4. Studies are presented in context of current case

D.2 Multi-Site Case Review

Scenario: A radiologist needs to review cases from multiple imaging sites for a tumor board meeting.

Flow:

1. Case coordinator creates manifest including studies from multiple sites
2. Manifest includes access credentials for each site
3. Review system retrieves studies from all sites
4. Studies are presented in unified interface

D.3 Research Data Collection

Scenario: Researchers need to collect imaging data matching specific criteria for a study.

Flow:

1. Research system creates manifest based on search criteria
2. Manifest includes anonymization requirements
3. Data collection system retrieves and processes studies
4. Anonymized data is delivered to research repository

D.4 Emergency Access

Scenario: Emergency department needs immediate access to patient's recent imaging studies.

Flow:

1. ED system creates urgent manifest for patient
2. Manifest bypasses normal authorization checks
3. Critical studies are retrieved with high priority
4. Emergency team has immediate access to imaging

Appendix E – Glossary

DICOM: Digital Imaging and Communications in Medicine - Standard for medical imaging information

FHIR: Fast Healthcare Interoperability Resources - HL7 standard for health information exchange

ImagingStudy: FHIR resource representing a collection of imaging series

Key Object Selection (KOS): DICOM object that references other DICOM objects for a specific purpose

List: FHIR resource that represents a collection of other resources

Manifest: Document containing references to imaging studies or instances

WADO-RS: Web Access to DICOM Objects - RESTful Services for accessing DICOM content

Endpoint: FHIR resource representing a network service for accessing resources